From owner-v6ops@ops.ietf.org Fri Apr 1 15:29:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06998 for ; Fri, 1 Apr 2005 15:29:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHSiY-000L53-7m for v6ops-data@psg.com; Fri, 01 Apr 2005 20:26:10 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DHSiX-000L4o-6h for v6ops@ops.ietf.org; Fri, 01 Apr 2005 20:26:09 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06085; Fri, 1 Apr 2005 15:26:04 -0500 (EST) Message-Id: <200504012026.PAA06085@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-bb-deployment-scenarios-01.txt Date: Fri, 01 Apr 2005 15:26:04 -0500 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : ISP IPv6 Deployment Scenarios in Broadband Access Networks Author(s) : S. Asadullah, et al. Filename : draft-ietf-v6ops-bb-deployment-scenarios-01.txt Pages : 70 Date : 2005-4-1 This document provides detailed description of IPv6 deployment and integration methods and scenarios in today's Service Provider (SP) Broadband (BB) networks in coexistence with deployed IPv4 services. Cable/HFC, BB Ethernet, xDSL and WLAN are the main BB technologies that are currently deployed, and discussed in this document. In this document we will discuss main components of IPv6 BB networks and their differences from IPv4 BB networks and how IPv6 is deployed and integrated in each of these BB technologies using tunneling mechanisms and native IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-bb-deployment-scenarios-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-bb-deployment-scenarios-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-bb-deployment-scenarios-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-4-1155106.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-bb-deployment-scenarios-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-bb-deployment-scenarios-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-1155106.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Sat Apr 2 05:05:56 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10528 for ; Sat, 2 Apr 2005 05:05:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHfSA-000NlL-On for v6ops-data@psg.com; Sat, 02 Apr 2005 10:02:06 +0000 Received: from [210.84.225.147] (helo=ubu.nosense.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DHfS7-000Nkx-7c for v6ops@ops.ietf.org; Sat, 02 Apr 2005 10:02:03 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 4E56862AAE; Sat, 2 Apr 2005 19:32:00 +0930 (CST) Date: Sat, 2 Apr 2005 19:32:00 +0930 From: Mark Smith To: "EricLKlein" Cc: v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-nap-00.txt Message-Id: <20050402193200.080bb5ec.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <002801c535da$0fcbe310$0201a8c0@ttitelecom.com> References: <200503291601.LAA13050@ietf.org> <002801c535da$0fcbe310$0201a8c0@ttitelecom.com> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Eric, On Thu, 31 Mar 2005 12:11:51 +0200 "EricLKlein" wrote: > just prior to this being published as draft-ietf-v6ops-nap-00 there was some > WG discussion about adding proxies to raft-vandevelde-v6ops-nap-01. > > > Are there strong feelings about adding this section? If so I will start to > draft some text based on the comments from the WG that will be aimed at > inclusion in the -01 version and will submit them to the list. > > I personally would prefer not to see a section on proxies. In the prior discussion, proxies were being advocated as another topology hiding method, potentially useful in IPv6. I don't think they are that useful for that function, as they only support topology hiding for the protocols they support. For example, a HTTP proxy will only hide the identity of devices making HTTP requests through the proxy. Assuming those same devices have public addresses, they will still be vulnerable to any other topology discovery techniques that don't specifically involve HTTP. NAT is a better topology hiding method than proxies, and, of course, this Draft is saying NAT isn't necessary in IPv6 for that either. Regards, Mark. -- The Internet's nature is peer to peer. From owner-v6ops@ops.ietf.org Sat Apr 2 11:26:02 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02172 for ; Sat, 2 Apr 2005 11:26:01 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHlOj-000Pvl-4v for v6ops-data@psg.com; Sat, 02 Apr 2005 16:22:57 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DHlOi-000PvZ-Bs for v6ops@ops.ietf.org; Sat, 02 Apr 2005 16:22:56 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 02 Apr 2005 08:22:56 -0800 X-IronPort-AV: i="3.91,143,1110182400"; d="scan'208"; a="244589353:sNHT23203932" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j32GMpDr028027 for ; Sat, 2 Apr 2005 08:22:52 -0800 (PST) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id BDO91678; Sat, 2 Apr 2005 08:22:52 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <3D1C81E7AA3CD64FA20B04D269FEF7F40DC3CF@xmb-rtp-213.amer.cisco.com> References: <3D1C81E7AA3CD64FA20B04D269FEF7F40DC3CF@xmb-rtp-213.amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8e40962e049d85320776907a801ad09f@cisco.com> Content-Transfer-Encoding: 7bit From: Baker Fred Subject: draft-ietf-v6ops-bb-deployment-scenarios-01.txt Date: Sat, 2 Apr 2005 08:22:51 -0800 To: v6ops@ops.ietf.org X-Mailer: Apple Mail (2.619.2) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Folks: We have a new draft of the broadband deployment scenarios draft. I would appreciate folks taking the time to read it and comment to the list. Thanks From owner-v6ops@ops.ietf.org Sat Apr 2 12:54:46 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09256 for ; Sat, 2 Apr 2005 12:54:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHmne-000BcG-EX for v6ops-data@psg.com; Sat, 02 Apr 2005 17:52:46 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.44 (FreeBSD)) id 1DHmnb-000Bbd-Jy for v6ops@ops.ietf.org; Sat, 02 Apr 2005 17:52:43 +0000 Received: from [10.10.10.100] ([217.126.187.160]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.3.R) with ESMTP id md50000889447.msg for ; Sat, 02 Apr 2005 19:55:29 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 02 Apr 2005 19:52:12 +0200 Subject: Re: draft-ietf-v6ops-bb-deployment-scenarios-01.txt From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: In-Reply-To: <8e40962e049d85320776907a801ad09f@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00, TO_ADDRESS_EQ_REAL autolearn=no version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, Yes, please, we will appreciate further inputs ! Also, you will discover a new section 10, related to the deployment of IPv6 in Power Line Communications (PLC, also called BPL in North America, which stands for Broadband Power Line). But we have also integrated the latest inputs and comments received from several people. It will be great to have as many inputs and comments as possible in the next weeks. Please ignore the nits and editorial issues, next version will be using XML instead of plain editors, so all them should go by then. Regards, Jordi PS: Direct link to the document as usual at http://www.ietf.org/internet-drafts/draft-ietf-v6ops-bb-deployment-scenarios -01.txt > De: Baker Fred > Responder a: > Fecha: Sat, 2 Apr 2005 08:22:51 -0800 > Para: "v6ops@ops.ietf.org" > Asunto: draft-ietf-v6ops-bb-deployment-scenarios-01.txt > > Folks: > > We have a new draft of the broadband deployment scenarios draft. I > would appreciate folks taking the time to read it and comment to the > list. > > Thanks > From owner-v6ops@ops.ietf.org Sun Apr 3 03:33:26 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00926 for ; Sun, 3 Apr 2005 03:33:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHzXx-000GUX-1k for v6ops-data@psg.com; Sun, 03 Apr 2005 07:29:25 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DHzXt-000GTY-Mi for v6ops@ops.ietf.org; Sun, 03 Apr 2005 07:29:22 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id j337TJFa082566 for ; Sun, 3 Apr 2005 07:29:19 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j337TJVo184344 for ; Sun, 3 Apr 2005 09:29:19 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j337TJjY012486 for ; Sun, 3 Apr 2005 09:29:19 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j337TIvZ012476; Sun, 3 Apr 2005 09:29:18 +0200 Received: from zurich.ibm.com (sig-9-145-254-103.de.ibm.com [9.145.254.103]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA25216; Sun, 3 Apr 2005 09:29:16 +0200 Message-ID: <424F9B40.5000405@zurich.ibm.com> Date: Sun, 03 Apr 2005 09:29:04 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Mark Smith CC: EricLKlein , v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-nap-00.txt References: <200503291601.LAA13050@ietf.org> <002801c535da$0fcbe310$0201a8c0@ttitelecom.com> <20050402193200.080bb5ec.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20050402193200.080bb5ec.ipng@69706e6720323030352d30312d31340a.nosense.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I agree with Mark. There is nothing specific to IPv6 about proxies; they work equally well for IPv4. As a matter of fact a proxy can be a very useful v4/v6 coexistence tool. I prefer that they should be mentioned in a few words in the NAP draft, but nothing more. Brian Mark Smith wrote: > Hi Eric, > > On Thu, 31 Mar 2005 12:11:51 +0200 > "EricLKlein" wrote: > > >>just prior to this being published as draft-ietf-v6ops-nap-00 there was some >>WG discussion about adding proxies to raft-vandevelde-v6ops-nap-01. >> >> >>>Are there strong feelings about adding this section? If so I will start to >> >>draft some text based on the comments from the WG that will be aimed at >>inclusion in the -01 version and will submit them to the list. >> >> > > > I personally would prefer not to see a section on proxies. > > In the prior discussion, proxies were being advocated as another topology > hiding method, potentially useful in IPv6. > > I don't think they are that useful for that function, as they only > support topology hiding for the protocols they support. For example, a > HTTP proxy will only hide the identity of devices making HTTP requests > through the proxy. Assuming those same devices have public addresses, > they will still be vulnerable to any other topology discovery techniques > that don't specifically involve HTTP. > > NAT is a better topology hiding method than proxies, and, of course, this > Draft is saying NAT isn't necessary in IPv6 for that either. > > Regards, > Mark. > From owner-v6ops@ops.ietf.org Sun Apr 3 13:44:39 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12761 for ; Sun, 3 Apr 2005 13:44:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DI953-000FP8-0C for v6ops-data@psg.com; Sun, 03 Apr 2005 17:40:13 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DI951-000FNf-St for v6ops@ops.ietf.org; Sun, 03 Apr 2005 17:40:12 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j33Hdnd08255; Sun, 3 Apr 2005 20:39:51 +0300 Date: Sun, 3 Apr 2005 20:39:49 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter cc: Mark Smith , EricLKlein , v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-nap-00.txt In-Reply-To: <424F9B40.5000405@zurich.ibm.com> Message-ID: References: <200503291601.LAA13050@ietf.org> <002801c535da$0fcbe310$0201a8c0@ttitelecom.com> <20050402193200.080bb5ec.ipng@69706e6720323030352d30312d31340a.nosense.org> <424F9B40.5000405@zurich.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sun, 3 Apr 2005, Brian E Carpenter wrote: > I agree with Mark. There is nothing specific to IPv6 about proxies; > they work equally well for IPv4. As a matter of fact a proxy > can be a very useful v4/v6 coexistence tool. I prefer that they > should be mentioned in a few words in the NAP draft, but nothing > more. There are actually enterprises (v4) today that do not allow any communication between "inside" and "outside" except using explicitly defined proxies. (E.g., maybe just HTTP(S), nothing more). That is, especially in strictly controlled environments where the nodes actually don't have global v6 addresses or wouldn't use them, using proxies might fulfill the topology hiding (and maybe other) perceived requirements. In any case, proxies become a necessity when ULAs are used. The situation differs because in v4 you can use NAT ("implicit proxy") instead. These issues might warrant some amount of discussion, especially if (IETF) work needs to happen on how the client machines are configured to use the right proxies. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Apr 4 01:18:07 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00511 for ; Mon, 4 Apr 2005 01:18:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIJuO-000K9a-DT for v6ops-data@psg.com; Mon, 04 Apr 2005 05:13:56 +0000 Received: from [210.84.225.147] (helo=ubu.nosense.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DIJuK-000K9G-S8 for v6ops@ops.ietf.org; Mon, 04 Apr 2005 05:13:53 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 9434162ADD; Mon, 4 Apr 2005 14:43:49 +0930 (CST) Date: Mon, 4 Apr 2005 14:43:49 +0930 From: Mark Smith To: Pekka Savola Cc: brc@zurich.ibm.com, ericlklein@softhome.net, v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-nap-00.txt Message-Id: <20050404144349.1676cdbf.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: References: <200503291601.LAA13050@ietf.org> <002801c535da$0fcbe310$0201a8c0@ttitelecom.com> <20050402193200.080bb5ec.ipng@69706e6720323030352d30312d31340a.nosense.org> <424F9B40.5000405@zurich.ibm.com> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pekka, On Sun, 3 Apr 2005 20:39:49 +0300 (EEST) Pekka Savola wrote: > > In any case, proxies become a necessity when ULAs are used. The > situation differs because in v4 you can use NAT ("implicit proxy") > instead. > I've understood that the intended, most common use of ULAs would be to deploy them in parallel with globals, rather than instead of globals. I wouldn't think a proxy would be a necessity in that scenario. Or have I misunderstood what you're saying ? In a ULA only scenario, a proxy would be necessary to access external content. It's use as a topology hiding mechanism wouldn't be of much value though, as the ULA addressed topology would be unreachable over the public Internet anyway. (Unless, in the case of a HTTP proxy, the proxy had be missconfigured and was able to proxy internal intranet sites for external HTTP clients. Apparently this is how Adrian Lamo exploited Worldcom a few years back. For details : http://www.securityfocus.com/news/296 ) Regards, Mark. -- The Internet's nature is peer to peer. From owner-v6ops@ops.ietf.org Mon Apr 4 06:54:01 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16947 for ; Mon, 4 Apr 2005 06:54:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIP8Q-000Jgb-GP for v6ops-data@psg.com; Mon, 04 Apr 2005 10:48:46 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DIP8O-000JgN-VP for v6ops@ops.ietf.org; Mon, 04 Apr 2005 10:48:45 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j34AmCY26323; Mon, 4 Apr 2005 13:48:12 +0300 Date: Mon, 4 Apr 2005 13:48:12 +0300 (EEST) From: Pekka Savola To: Mark Smith cc: brc@zurich.ibm.com, ericlklein@softhome.net, v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-nap-00.txt In-Reply-To: <20050404144349.1676cdbf.ipng@69706e6720323030352d30312d31340a.nosense.org> Message-ID: References: <200503291601.LAA13050@ietf.org> <002801c535da$0fcbe310$0201a8c0@ttitelecom.com> <20050402193200.080bb5ec.ipng@69706e6720323030352d30312d31340a.nosense.org> <424F9B40.5000405@zurich.ibm.com> <20050404144349.1676cdbf.ipng@69706e6720323030352d30312d31340a.nosense.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 4 Apr 2005, Mark Smith wrote: >> In any case, proxies become a necessity when ULAs are used. The >> situation differs because in v4 you can use NAT ("implicit proxy") >> instead. > > I've understood that the intended, most common use of ULAs would be to > deploy them in parallel with globals, rather than instead of globals. I > wouldn't think a proxy would be a necessity in that scenario. Or have > I misunderstood what you're saying ? That's correct, but I suspect the situation may be different in some cases. There will certainly be large deployments which only have ULA addresses, I suspect. > In a ULA only scenario, a proxy would be necessary to access external > content. It's use as a topology hiding mechanism wouldn't be of much > value though, as the ULA addressed topology would be unreachable over > the public Internet anyway. The users who wish to hide the topology likely also want to hide non-routable topology. Thus, using a proxy is benefit because by definition the local topology (whether non-routable or not) cannot be discerned. As said, using proxies in ULA-only case (note that it could be that some nodes are ULA-only [but still need to have controlled access out] and some may be ULA+global) might fulfill some other perceived requirements rather than just topology hiding -- e.g., NAT-like security. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Apr 4 07:02:45 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17552 for ; Mon, 4 Apr 2005 07:02:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIPKv-000LZ7-NG for v6ops-data@psg.com; Mon, 04 Apr 2005 11:01:41 +0000 Received: from [168.103.150.210] (helo=hestia.native6.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DIPKt-000LYT-GF for v6ops@ops.ietf.org; Mon, 04 Apr 2005 11:01:39 +0000 Received: from JSN6LT (host-66-202-104-251.col.choiceone.net [66.202.104.251]) (authenticated bits=0) by hestia.native6.com (8.12.8/8.12.8) with ESMTP id j34B1Ypm012050 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 4 Apr 2005 04:01:36 -0700 Message-Id: <200504041101.j34B1Ypm012050@hestia.native6.com> From: "John Spence, CCSI, CCNA, CISSP" To: Subject: RE: draft-ietf-v6ops-nap-00.txt Date: Mon, 4 Apr 2005 04:01:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcU42QOj2fTCvaXuSmKSnwSjPQjl5QALBwsw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 In-Reply-To: <20050404144349.1676cdbf.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark, Pekka, Brian, et. al.; I do not have strong feelings on how much information on proxies goes into the draft. I do believe the most compelling arguments supporting the elimination of NAT in the IPv6 architecture need a discussion of what you can achieve - and what you give up - if you deploy proxies. As a practical matter, even considering the peer-to-peer IPv6 Internet of the future, in the near and middle term the continued use of stateful firewalls (breaks end-to-end) and proxy servers (breaks end-to-end) will be a reality. I think a reasonable deployment model for the enterprise is giving "internal use only" nodes ULA addresses. Any node needing Internet access would have both a ULA (for internal use and, most likely, HTTP via the proxy) *and* a global-scope address (for peer-to-peer applications). Other nodes may use a ULA and the proxy to obtain a "basic" Internet capability (unable to be a full Internet peer). That allows security managers to continue to use a model they are comfortable with for most traffic, and arguably does provide benefits (caching, policy enforcement, topology hiding), but also allows an enterprise to roll out peer-to-peer services as a matter of course as needed. By using IPv6 and eliminating NAT, enterprise network managers gain great flexibility - even if they continue to use proxies to fulfill some needs. I just think that is the reality, and to try to push a model that eliminates NAT *and* proxy (and probably some people would like to eliminate stateful edge firewalls even at this early stage) will result in some feeling that the NAP draft doesn't go far enough in recognizing the need for continuity from today's network. ---------------------------------------------------- John Spence, CCSI, CCNA, CISSP Native6, Inc. IPv6 Training and Consulting jspence@native6.com www.native6.com ---------------------------------------------------- From owner-v6ops@ops.ietf.org Mon Apr 4 07:25:16 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19380 for ; Mon, 4 Apr 2005 07:25:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIPgf-000OJt-Sg for v6ops-data@psg.com; Mon, 04 Apr 2005 11:24:09 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1DIPgc-000OJe-Lk for v6ops@ops.ietf.org; Mon, 04 Apr 2005 11:24:06 +0000 Received: (qmail 22541 invoked by uid 417); 4 Apr 2005 11:24:06 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 4 Apr 2005 11:24:06 -0000 Received: from XPNERICK ([132.70.218.18]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Mon, 04 Apr 2005 05:24:04 -0600 Message-ID: <001901c53910$f96f0630$0201a8c0@ttitelecom.com> From: "EricLKlein" To: v6ops@ops.ietf.org References: <200504041101.j34B1Ypm012050@hestia.native6.com> Subject: Re: draft-ietf-v6ops-nap-00.txt Date: Mon, 4 Apr 2005 14:22:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit John Spence wrote: > I just think that is the reality, and to try to push a model that eliminates > NAT *and* proxy (and probably some people would like to eliminate stateful > edge firewalls even at this early stage) will result in some feeling that > the NAP draft doesn't go far enough in recognizing the need for continuity > from today's network. > In listening to the (few) comments on proxies I tend to agree with John that Proxies should be left out of this document. If they are to addressed it should be in a separate security document. Eric From owner-v6ops@ops.ietf.org Mon Apr 4 15:02:58 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11789 for ; Mon, 4 Apr 2005 15:02:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIWnw-0005No-LS for v6ops-data@psg.com; Mon, 04 Apr 2005 19:00:08 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DIWnv-0005NZ-O7 for v6ops@ops.ietf.org; Mon, 04 Apr 2005 19:00:07 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 04 Apr 2005 12:00:07 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j34J03Dr022747; Mon, 4 Apr 2005 12:00:03 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id BDQ04036; Mon, 4 Apr 2005 12:00:04 -0700 (PDT) In-Reply-To: <200504041101.j34B1Ypm012050@hestia.native6.com> References: <200504041101.j34B1Ypm012050@hestia.native6.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: From: Baker Fred Subject: Re: draft-ietf-v6ops-nap-00.txt Date: Mon, 4 Apr 2005 12:00:03 -0700 To: "John Spence, CCSI, CCNA, CISSP" X-Mailer: Apple Mail (2.619.2) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Apr 4, 2005, at 4:01 AM, John Spence, CCSI, CCNA, CISSP wrote: > I do believe the most compelling arguments supporting the elimination > of NAT > in the IPv6 architecture need a discussion of what you can achieve - > and > what you give up - if you deploy proxies. Speaking for myself, I very much agree. The big marketing thing for IPv6 is the end to end architecture. What ULAs do is summarily discard that, and what proxies do when so configured is what NATs do automatically. Think about it this way. Right now, with IPv4, someone that wants to implement wireless in their home buys a Linksys box at the store, screws it to the wall, and applies power. Job done. With IPv6, they will be able to do the same thing some day in the future when ISPs distribute a /64 to each house via DHCP and when Linksys sees enough market to put IPv6 into the system. Until then, you can manually configure a ULA and a proxy. Given the options, what does T.C. Mits install in his house? I submit that he installs IPv4 and a NAT. It is easier and gets him what he thought he was buying. If we think ULAs are going to commonly *replace* end to end addressing, that is something that somebody needs to analyze, and since that is yet another variation on a NAT, it seems like it should go here. From owner-v6ops@ops.ietf.org Mon Apr 4 16:00:23 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23265 for ; Mon, 4 Apr 2005 16:00:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIXjI-000Cko-QV for v6ops-data@psg.com; Mon, 04 Apr 2005 19:59:24 +0000 Received: from [66.93.39.75] (helo=smtp-e.tycool.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DIXjI-000CkZ-4r for v6ops@ops.ietf.org; Mon, 04 Apr 2005 19:59:24 +0000 Received: by smtp-e.tycool.net (Postfix, from userid 1001) id F370D147; Mon, 4 Apr 2005 12:59:53 -0700 (PDT) To: v6ops@ops.ietf.org Subject: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] Message-Id: <20050404195953.F370D147@smtp-e.tycool.net> Date: Mon, 4 Apr 2005 12:59:53 -0700 (PDT) From: alain@tycool.net (Alain Durand) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I've been reading again section 2.2 2.2 Simple security due to stateful filter implementation I think this section is a bit weak. If someone install a NAT box at home, by default, it will prevent incoming connections, and this is widely percieved as a security function. The point that trojan horses do exist and that the dynamic mapping does not provide real security is true. However, the classic counter arguments come in two flavor: - oh, but the NAT boxes are labeled security devices so it must be true. - "defense in depth" is what more knowledgebla people would answer. So you expect to convince home user and IT department that they should then give up on what they considered as "state of the art security", you are facing an uphill batttle and you will need much more than the current text in section 2.2. - Alain. From owner-v6ops@ops.ietf.org Mon Apr 4 16:53:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07430 for ; Mon, 4 Apr 2005 16:53:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIYYt-000Itk-CK for v6ops-data@psg.com; Mon, 04 Apr 2005 20:52:43 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DIYYs-000ItD-Bu for v6ops@ops.ietf.org; Mon, 04 Apr 2005 20:52:42 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j34KqZX06216; Mon, 4 Apr 2005 23:52:35 +0300 Date: Mon, 4 Apr 2005 23:52:35 +0300 (EEST) From: Pekka Savola To: Baker Fred cc: "John Spence, CCSI, CCNA, CISSP" , v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-nap-00.txt In-Reply-To: Message-ID: References: <200504041101.j34B1Ypm012050@hestia.native6.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 4 Apr 2005, Baker Fred wrote: > On Apr 4, 2005, at 4:01 AM, John Spence, CCSI, CCNA, CISSP wrote: >> I do believe the most compelling arguments supporting the elimination of >> NAT >> in the IPv6 architecture need a discussion of what you can achieve - and >> what you give up - if you deploy proxies. > > Speaking for myself, I very much agree. The big marketing thing for IPv6 is > the end to end architecture. What ULAs do is summarily discard that, and what > proxies do when so configured is what NATs do automatically. Sure, but the main difference from the IPv6 and end-to-end perspective is that proxies are explicitly configured. They aren't "automatic"; they don't apply to all the traffic trying to outsmart it, or just hope it doesn't break any protocol in the process due to translation. I would hope that when the admin sets up a proxy, the proxy will be able to interpret that particular protocol because, hey... the proxies are typically protocol-specific. Or, if it isn't, I would hope that the admin has made a knowing & conscious decision that the protocol is so simple, proxying "just works". Using NATs, implicit or automatic proxies, etc. rips all of that away. Because of this, explicit proxies are the next best thing (ro the end-to-end communication) from the end-to-end perspective. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Apr 4 18:20:08 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19070 for ; Mon, 4 Apr 2005 18:20:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIZtY-0002SY-KK for v6ops-data@psg.com; Mon, 04 Apr 2005 22:18:08 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DIZtX-0002SJ-NI for v6ops@ops.ietf.org; Mon, 04 Apr 2005 22:18:07 +0000 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 04 Apr 2005 18:18:04 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j34MHr1j020882; Mon, 4 Apr 2005 18:17:54 -0400 (EDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id BDQ29472; Mon, 4 Apr 2005 15:17:52 -0700 (PDT) In-Reply-To: References: <200504041101.j34B1Ypm012050@hestia.native6.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: v6ops@ops.ietf.org From: Baker Fred Subject: Re: draft-ietf-v6ops-nap-00.txt Date: Mon, 4 Apr 2005 15:17:51 -0700 To: Pekka Savola X-Mailer: Apple Mail (2.619.2) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Apr 4, 2005, at 1:52 PM, Pekka Savola wrote: > Using NATs, implicit or automatic proxies, etc. rips all of that away. > Because of this, explicit proxies are the next best thing (ro the > end-to-end communication) from the end-to-end perspective. You won't get any argument from me. I'm looking at the houses up and down the street and asking what their occupants might think... From my perspective, if the sum of this document is "you don't need no stinkin' NAT because if you just type enough highly technical gibberish into your whizbang thingie you can get something that accomplishes about the same thing", you lost before you started. My daughter will happily buy a NAT that plugs and for the most part plays. What we need to come out of this document is a reasoned analysis of the issues in play, and a set of recommendations that will allow the likes of Linksys, Microsoft, etc to target their default configurations so that IPv6 products in fact plug and play, as opposed to mostly plugging and mostly playing. At the end of the day, you want IPv6 to be a solution that my daughter can adopt without knowing or caring and find simply works, as opposed t having the application limitations and so on that she presently enjoys (or doesn't). So from my perspective, yes, this document wants to cover proxies. Not in detail, perhaps, but enough to say what works, what doesn't, and give advice on how to make them work well, or advice on how to protect them better than a NAT does. From owner-v6ops@ops.ietf.org Mon Apr 4 21:57:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05704 for ; Mon, 4 Apr 2005 21:57:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIdI4-0003CX-0B for v6ops-data@psg.com; Tue, 05 Apr 2005 01:55:40 +0000 Received: from [168.103.150.210] (helo=hestia.native6.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DIdI3-0003C7-1C for v6ops@ops.ietf.org; Tue, 05 Apr 2005 01:55:39 +0000 Received: from JSN6LT (host-66-202-104-251.col.choiceone.net [66.202.104.251]) (authenticated bits=0) by hestia.native6.com (8.12.8/8.12.8) with ESMTP id j351hKpt015157 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 4 Apr 2005 18:55:34 -0700 Message-Id: <200504050155.j351hKpt015157@hestia.native6.com> From: "John Spence, CCSI, CCNA, CISSP" To: Subject: RE: draft-ietf-v6ops-nap-00.txt Date: Mon, 4 Apr 2005 18:43:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <001901c53910$f96f0630$0201a8c0@ttitelecom.com> Thread-Index: AcU5CxBA7SR4z5voT+a39GwPxgx0qAAZp3UA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eric; Just to be clear - I think the document should discuss proxies. Not as a recommended practice, but a tool that has a place in IPv6 deployment. We should be clear about what feature of proxies are attractive, what side-effects are not attractive, and how to trade off the two. The coverage should be brief and straightforward. Spence > -----Original Message----- > From: owner-v6ops@ops.ietf.org > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of EricLKlein > Sent: Monday, April 04, 2005 5:22 AM > To: v6ops@ops.ietf.org > Subject: Re: draft-ietf-v6ops-nap-00.txt > > John Spence wrote: > > > > I just think that is the reality, and to try to push a > model that eliminates > > NAT *and* proxy (and probably some people would like to eliminate > > stateful edge firewalls even at this early stage) will > result in some > > feeling that the NAP draft doesn't go far enough in recognizing the > > need for continuity from today's network. > > > > In listening to the (few) comments on proxies I tend to agree > with John that Proxies should be left out of this document. > If they are to addressed it should be in a separate security document. > > Eric > > From owner-v6ops@ops.ietf.org Mon Apr 4 22:17:57 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07138 for ; Mon, 4 Apr 2005 22:17:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIdd8-00066P-2m for v6ops-data@psg.com; Tue, 05 Apr 2005 02:17:26 +0000 Received: from [168.103.150.210] (helo=hestia.native6.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DIdd7-000665-5x for v6ops@ops.ietf.org; Tue, 05 Apr 2005 02:17:25 +0000 Received: from JSN6LT (host-66-202-104-251.col.choiceone.net [66.202.104.251]) (authenticated bits=0) by hestia.native6.com (8.12.8/8.12.8) with ESMTP id j351hKpw015157 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 4 Apr 2005 19:17:22 -0700 Message-Id: <200504050217.j351hKpw015157@hestia.native6.com> From: "John Spence, CCSI, CCNA, CISSP" To: Subject: RE: draft-ietf-v6ops-nap-00.txt Date: Mon, 4 Apr 2005 18:56:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <001901c53910$f96f0630$0201a8c0@ttitelecom.com> Thread-Index: AcU5CxBA7SR4z5voT+a39GwPxgx0qAAZp3UA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eric; Just to be clear - I think the document should discuss proxies. Not as a recommended practice, but a tool that has a place in IPv6 deployment. We should be clear about what feature of proxies are attractive, what side-effects are not attractive, and how to trade off the two. The coverage should be brief and straightforward. Spence > -----Original Message----- > From: owner-v6ops@ops.ietf.org > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of EricLKlein > Sent: Monday, April 04, 2005 5:22 AM > To: v6ops@ops.ietf.org > Subject: Re: draft-ietf-v6ops-nap-00.txt > > John Spence wrote: > > > > I just think that is the reality, and to try to push a > model that eliminates > > NAT *and* proxy (and probably some people would like to eliminate > > stateful edge firewalls even at this early stage) will > result in some > > feeling that the NAP draft doesn't go far enough in recognizing the > > need for continuity from today's network. > > > > In listening to the (few) comments on proxies I tend to agree > with John that Proxies should be left out of this document. > If they are to addressed it should be in a separate security document. > > Eric > > From owner-v6ops@ops.ietf.org Mon Apr 4 22:49:42 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09393 for ; Mon, 4 Apr 2005 22:49:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIe7m-0009xB-Qc for v6ops-data@psg.com; Tue, 05 Apr 2005 02:49:06 +0000 Received: from [210.84.225.147] (helo=ubu.nosense.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DIe7k-0009wv-7C for v6ops@ops.ietf.org; Tue, 05 Apr 2005 02:49:04 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 6947062ADD; Tue, 5 Apr 2005 12:19:02 +0930 (CST) Date: Tue, 5 Apr 2005 12:19:02 +0930 From: Mark Smith To: "John Spence, CCSI, CCNA, CISSP" Cc: v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-nap-00.txt Message-Id: <20050405121902.4a1aad76.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <200504050217.j351hKpw015157@hestia.native6.com> References: <001901c53910$f96f0630$0201a8c0@ttitelecom.com> <200504050217.j351hKpw015157@hestia.native6.com> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 4 Apr 2005 18:56:42 -0700 "John Spence, CCSI, CCNA, CISSP" wrote: > > Eric; > > Just to be clear - I think the document should discuss proxies. Not as a > recommended practice, but a tool that has a place in IPv6 deployment. We > should be clear about what feature of proxies are attractive, what > side-effects are not attractive, and how to trade off the two. The coverage > should be brief and straightforward. > > Spence > > I'm starting to wonder whether this Draft is "dual-scoped", with the scopes not quite matching. Alternatively, some of the discussion regarding this Draft seems to have unintentionally widened the understood scope of this Draft. The Draft currently seems to be addressing the union of two topics : (a) "network architecture protection" eg end-to-end, etc. (b) how NAT is not required for NAP, and why not If the Draft was purely discussing (a), then there might be a place for proxies in it, as per John's suggestion above. On the other hand, if it is restricted to a scope of the union of NAT and NAP ( (a) and (b) ), then I'd think proxies shouldn't be in it, unless they specifically provide an IPv6 oriented alternative to one or more of the functions IPv4 NAT provides. Should the scope of this Draft be widened ? Or should some of these other issues, e.g., proxy deployment in an IPv6 environment, be addressed in other Drafts / RFCs. I haven't read them, however, I've seen a few v6ops Drafts / RFC titles recently which I'd think either do or should cover the wider issues, but not specifically the union of NAT and NAP. Regards, Mark. -- The Internet's nature is peer to peer. From owner-v6ops@ops.ietf.org Tue Apr 5 06:47:33 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05153 for ; Tue, 5 Apr 2005 06:47:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIlXI-000H8w-TT for v6ops-data@psg.com; Tue, 05 Apr 2005 10:43:56 +0000 Received: from [144.254.15.118] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DIlXG-000H8d-Nz for v6ops@ops.ietf.org; Tue, 05 Apr 2005 10:43:55 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j35AhrL17390; Tue, 5 Apr 2005 12:43:53 +0200 (CEST) Received: from gvandeve-w2k01.cisco.com (dhcp-ams-cam-wvlan22-144-254-199-240.cisco.com [144.254.199.240]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j35AhqK01450; Tue, 5 Apr 2005 12:43:52 +0200 (CEST) Message-Id: <4.3.2.7.2.20050405112424.04ff0e50@strange-brew> X-Sender: gvandeve@strange-brew X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 05 Apr 2005 12:43:49 +0200 To: Mark Smith From: "Gunter Van de Velde (gvandeve)" Subject: Re: draft-ietf-v6ops-nap-00.txt Cc: "John Spence, CCSI, CCNA, CISSP" , v6ops@ops.ietf.org In-Reply-To: <20050405121902.4a1aad76.ipng@69706e6720323030352d30312d313 40a.nosense.org> References: <200504050217.j351hKpw015157@hestia.native6.com> <001901c53910$f96f0630$0201a8c0@ttitelecom.com> <200504050217.j351hKpw015157@hestia.native6.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Mark, The initial intention of the draft was to look at NAT and see why people are using address translation technology (basically to identify the perceived NAT benefits). Once identified, the next step would be to propose native IPv6 alternatives to these perceived benefits. I don't believe there is dual scope here. Brgds, G/ At 12:19 5/04/2005 +0930, Mark Smith wrote: >On Mon, 4 Apr 2005 18:56:42 -0700 >"John Spence, CCSI, CCNA, CISSP" wrote: > > > > > Eric; > > > > Just to be clear - I think the document should discuss proxies. Not as a > > recommended practice, but a tool that has a place in IPv6 deployment. We > > should be clear about what feature of proxies are attractive, what > > side-effects are not attractive, and how to trade off the two. The > coverage > > should be brief and straightforward. > > > > Spence > > > > > >I'm starting to wonder whether this Draft is "dual-scoped", with the >scopes not quite matching. Alternatively, some of the discussion >regarding this Draft seems to have unintentionally widened the >understood scope of this Draft. > >The Draft currently seems to be addressing the union of two topics : > >(a) "network architecture protection" eg end-to-end, etc. > >(b) how NAT is not required for NAP, and why not > >If the Draft was purely discussing (a), then there might be a place for >proxies in it, as per John's suggestion above. > >On the other hand, if it is restricted to a scope of the union of NAT >and NAP ( (a) and (b) ), then I'd think proxies shouldn't be in it, >unless they specifically provide an IPv6 oriented alternative to one or >more of the functions IPv4 NAT provides. > >Should the scope of this Draft be widened ? Or should some of these >other issues, e.g., proxy deployment in an IPv6 environment, be >addressed in other Drafts / RFCs. I haven't read them, however, I've >seen a few v6ops Drafts / RFC titles recently which I'd think either do >or should cover the wider issues, but not specifically the union of NAT >and NAP. > >Regards, >Mark. > >-- > > The Internet's nature is peer to peer. From owner-v6ops@ops.ietf.org Tue Apr 5 08:30:03 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14536 for ; Tue, 5 Apr 2005 08:30:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIn76-00063k-AA for v6ops-data@psg.com; Tue, 05 Apr 2005 12:25:00 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DIn74-00062Y-QP for v6ops@ops.ietf.org; Tue, 05 Apr 2005 12:24:59 +0000 Received: from d12nrmr1707.megacenter.de.ibm.com (d12nrmr1707.megacenter.de.ibm.com [9.149.167.81]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id j35COu96120696 for ; Tue, 5 Apr 2005 12:24:56 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1707.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j35COuWq067132 for ; Tue, 5 Apr 2005 14:24:56 +0200 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j35COtXp020502 for ; Tue, 5 Apr 2005 14:24:55 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j35COtZ9020485; Tue, 5 Apr 2005 14:24:55 +0200 Received: from zurich.ibm.com (sig-9-145-254-159.de.ibm.com [9.145.254.159]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA58386; Tue, 5 Apr 2005 14:24:54 +0200 Message-ID: <42528394.3090304@zurich.ibm.com> Date: Tue, 05 Apr 2005 14:24:52 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Alain Durand CC: v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] References: <20050404195953.F370D147@smtp-e.tycool.net> In-Reply-To: <20050404195953.F370D147@smtp-e.tycool.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I've never understood why a non-NAT domestic router can't be set up with exactly the same default behavior by having default port filtering in place (just like "personal firewall" software that most people run on their PCs). A domestic IPv6 router should indeed be shipped with port filtering on by default, imho. We can write this. Brian Alain Durand wrote: > I've been reading again section 2.2 > > 2.2 Simple security due to stateful filter implementation > > I think this section is a bit weak. > > If someone install a NAT box at home, by default, > it will prevent incoming connections, and this > is widely percieved as a security function. > > The point that trojan horses do exist and that the dynamic > mapping does not provide real security is true. > However, the classic counter arguments come in two flavor: > - oh, but the NAT boxes are labeled security devices > so it must be true. > - "defense in depth" is what more knowledgebla people > would answer. > > So you expect to convince home user and IT department that > they should then give up on what they considered as > "state of the art security", you are facing an uphill > batttle and you will need much more than the current > text in section 2.2. > > - Alain. > > From owner-v6ops@ops.ietf.org Tue Apr 5 11:35:43 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01402 for ; Tue, 5 Apr 2005 11:35:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIq22-000L23-BN for v6ops-data@psg.com; Tue, 05 Apr 2005 15:31:58 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DIq20-000L1o-Cx for v6ops@ops.ietf.org; Tue, 05 Apr 2005 15:31:56 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 05 Apr 2005 08:31:30 -0700 X-IronPort-AV: i="3.91,152,1110182400"; d="scan'208"; a="245772601:sNHT826980884" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j35FVRZV000726; Tue, 5 Apr 2005 08:31:28 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id BDQ88560; Tue, 5 Apr 2005 08:31:27 -0700 (PDT) In-Reply-To: <42528394.3090304@zurich.ibm.com> References: <20050404195953.F370D147@smtp-e.tycool.net> <42528394.3090304@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: v6ops@ops.ietf.org, Alain Durand From: Fred Baker Subject: Re: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] Date: Tue, 5 Apr 2005 08:31:25 -0700 To: Brian E Carpenter X-Mailer: Apple Mail (2.619.2) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Apr 5, 2005, at 5:24 AM, Brian E Carpenter wrote: > I've never understood why a non-NAT domestic router can't be set up > with exactly the same default behavior by having default port > filtering in place (just like "personal firewall" software that most > people run on their PCs). A domestic IPv6 router should indeed be > shipped with port filtering on by default, imho. We can write this. At the risk of sounding proprietary, Cisco has a rather nice capability for this. You might read http://www.cisco.com/en/US/products/sw/secursw/ps1018/ products_tech_note09186a0080094e8b.shtml http://www.cisco.com/en/US/products/sw/secursw/ps1018/ products_white_paper09186a0080094658.shtml http://www.cisco.com/en/US/products/sw/secursw/ps1018/ products_configuration_example09186a0080094111.shtml Simply stated, it defines an "inside" and an "outside" interface (and in that last, a DMZ). The "outside interface" is configured with an ACL of what to allow to cross, which one might expect to include a pretty limited configuration. The for my home office allows for dynamic creation of a VPN among the home workers on my network at Cisco, which uses DMVPN and IPSEC, and also runs NTP and derives its IP address from the ISP. ip access-list extended fw_acl remark ---- DMVPN Firewall ---- permit udp any any eq isakmp permit udp any eq isakmp any permit udp any eq non500-isakmp any permit esp any any permit gre any any permit udp host 192.5.41.40 eq ntp any permit udp host 192.5.41.41 eq ntp any permit ip 10.34.250.96 0.0.0.31 10.32.244.216 0.0.0.7 permit tcp 128.107.0.0 0.0.255.255 any eq 22 permit tcp 128.107.0.0 0.0.255.255 any eq telnet permit udp any any eq bootpc deny icmp any any packet-too-big permit icmp any any deny ip any any The one on my home router (Cisco information security guidelines require a home office to be on a separate network from the home) I use a much simpler one: access-list 105 deny ip 192.168.1.0 0.0.0.255 any access-list 105 deny icmp any any packet-too-big access-list 105 permit icmp any any access-list 105 permit udp any any eq bootpc access-list 105 permit udp any any eq bootps If this were sitting in front of a SOHO, one could readily imagine also application-specific holes for incoming traffic. access-list 105 permit tcp any host www.example.com eq http access-list 105 permit tcp any host smtp.example.com eq smtp access-list 105 permit tcp any host ftp.example.com eq ftp Now, in addition to packets permitted by the ACL, the "inside" interface notes new packets sent out and adds their response to a dynamic ACL added to that "outside" ACL, which permits devices beyond the firewall to respond to sessions initiated from behind the firewall. This is a very simple port-specific firewall that requires a minimum of management - I configured it once and basically forgot it - that provides most of what one would want at layer 3 in a SOHO solution. I would suggest that this is a pretty strong basis for the solution you suggest. From owner-v6ops@ops.ietf.org Tue Apr 5 19:37:13 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01131 for ; Tue, 5 Apr 2005 19:37:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIxZZ-000Pep-Cp for v6ops-data@psg.com; Tue, 05 Apr 2005 23:35:05 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DIxZY-000PeS-G3 for v6ops@ops.ietf.org; Tue, 05 Apr 2005 23:35:04 +0000 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 05 Apr 2005 16:35:05 -0700 Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id j35NYr3T028319; Tue, 5 Apr 2005 16:34:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4b0b7f3167c75500b1dcb4d912f974e0@cisco.com> Content-Transfer-Encoding: 7bit Cc: Lindqvist Erik Kurt , David Kessens From: Fred Baker Subject: Tunneling and Transition Drafts Date: Tue, 5 Apr 2005 16:34:52 -0700 To: v6ops@ops.ietf.org X-Mailer: Apple Mail (2.619.2) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I need a consensus of the WG. In what I am about to say, someone might possibly feel their toes stepped on. Apologies in advance - and get used to it. I have big feet, and I often put them in my mouth. In taking over the working group, Kurt and I basically were presented with the following scenario: - this group is for operational questions (not protocols) - this group seeks to conform to RFC 1958 (we are not here to bless very lame solution that comes along) - transition mechanisms are generally out of scope. As I understand it, v6tc (which was intended to take over all the tunneling stuff, which is to say a large proposition of the transition stuff) is dead in the water. The expectation was that all the tunneling/transition stuff would move there, but the BOF was a non-event. There isn't likely to be a v6tc WG. (Dear AD: if you disagree, this would be a good time to say so). That said, there are roughly 80 gazillion different transition solutions out there, including at least silkroad, teredo, DSTM, secure tunnels, etc. To deploy IPv6 in a network that is in parts IPv4-only, in parts IPv6-only, in parts dual, and in parts what Jim Bound calls "IPv6-dominant" (which is not a bad term, btw), which I think I would say is ipv6-only in its service but might use IPv4 internally, it seems to me that one needs six things said or defined: - "please turn IPv6 on by default in your end systems" - "please turn IPv6 on in your enterprise network" - "please turn IPv6 on in your access/ISP network" - how to tunnel IPv6 through an IPv4-only/dominant network between IPv6-only/dominant hosts or networks key attribute: static or dynamic IPv6/IPv4 tunnels between tunnel endpoints, and appropriate routing through the IPv4 domain to determine what the appropriate tunnel endpoint router would be. Could be done with a DNS name not unlike a reverse lookup for the IPv6 address but delivering an IPv4 "A" record. Could also be done through simple routing if the tunnels sty up or use a concept like RFC 1793. - how to tunnel IPv4 through an IPv6-only/dominant network between IPv4-only/dominant hosts or networks key attribute: static or dynamic IPv4/IPv6 tunnels between tunnel endpoints, and appropriate routing through the IPv4 domain to determine what the appropriate tunnel endpoint router would be. Could be done with a DNS name not unlike a reverse lookup for the IPv4 address but delivering an IPv6 "AAAA" record. Could also be done through simple routing if the tunnels sty up or use a concept like RFC 1793. - how to translate IPv6->IPv4 and IPv6-IPv4 between an IPv6-only/dominant and an IPv4-only/dominant domain key attribute: translation system captures DNS lookups and re-advertises its own address in some way, so that IPv4 hosts seeking IPv6 peers connect to it and it translates, and IPv6 hosts connect to it and it translates. Note that I didn't say what kind of tunnel. GRE, MPLS, IP/IP, IPSEC, L2TP, who knows what else - they all must be addressed. I have a fairly large number of ways to do those - silkroad, teredo, dstm, and a list of others. Each one, when it looks at the others, says "but mine is better" or "my customers want to deploy mine now". I have no idea how this transition is going to happen if we can't sound a clear signal on how to do it. Which brings me to my question. I am being asked by various proponents of various things what the working group wants to do with their approach. I need to know what the game plan for this working group is: let a thousand flowers bloom (they can all ask for informational status from the RFC Editor and the probability that the transition will happen in an orderly fashion rapidly approaches zero), or I need a consensus statement from the working group that every single approach on the table will be set aside and the working group will actively work on providing a single solution that meets all those needs that the IETF can look at and say "yes, that will accomplish an orderly transition in a timely fashion and *I*will*support*that*in*favor*of*all*others". Opinions? From owner-v6ops@ops.ietf.org Tue Apr 5 20:32:39 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05187 for ; Tue, 5 Apr 2005 20:32:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIySM-0005Zp-BV for v6ops-data@psg.com; Wed, 06 Apr 2005 00:31:42 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.44 (FreeBSD)) id 1DIyRv-0005Xs-Px for v6ops@ops.ietf.org; Wed, 06 Apr 2005 00:31:37 +0000 Received: from [10.10.10.100] ([217.126.187.160]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.3.R) with ESMTP id md50000896054.msg for ; Wed, 06 Apr 2005 02:34:23 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 06 Apr 2005 02:30:53 +0200 Subject: Re: Tunneling and Transition Drafts From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" CC: "v6tc@ietf.org" Message-ID: In-Reply-To: <4b0b7f3167c75500b1dcb4d912f974e0@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Wed, 06 Apr 2005 02:34:27 +0200 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00, TO_ADDRESS_EQ_REAL autolearn=no version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Fred, all, First of all, I think is a very good question to know if the v6tc is really dead, or what, unless I've missed something, there was not any message about this. I was about to ask soon in v6tc list (copied now). Then regarding the rest of your email, without entering into many details at this point, basically agree with your view. When I started looking into the tunneling/transition work (with several documents such as TED auto-discovery and solution, auto-transition, zero-tunneling-configuration, etc.), my main goal was precisely to be able to pick up those gazillion existing mechanism and: 1) Try to automate the mechanism selection and configuration process as much as possible (and probably this doesn't need a new protocol but some guidelines about how to use existing things to do it). The idea is that this could be done even w/o modifying the existing mechanisms. I think the work here is almost done (but has not received for some of the documents, almost any feedback from the WG, specially for proposed solutions). 2) Define a new mechanism, which actually takes advantage of existing ones and a lot of deployment experience (including IPv6-dominant environments, which I'm already deploying for some customers, so there is a real need here). Clearly the deployment experience that we have now is not all what we need, but is much more than what we had when we started working in the existing mechanism (at least some of them). The point is probably to consider two basic environments narrow-band and broad-band networks (for example 3GPP or ISDN and xDSL/WLAN), but have a single mechanism, a kind of one-fits-all (or very close to that), which can self-adapt, starting from the "worst" situation (so it fits for 3GPP folks, with limited features, but no new network requirements/devices), but can improve the features offered in case there is a better link (example WLAN). For example I see the point of a cellular phone with 3GPP and WLAN, moving from one network to another. Why we need to have different mechanisms in that device, if instead we can have one which can "self-adapt" (even using different encapsulation if required, automatically). For 2) We have a draft document (even a set of slides) which depict our idea on this (our team worked the last 3-4 months on this already, in addition to all the work done in 1) and v6tc documents). If this sounds a good idea, we will be able to have an initial i-d probably in 10-15 days (may be earlier, but need to recheck some other priorities). The important thing that we have kept in mind always while working on 2) has been also to avoid designing something completely new, but instead, looking into all the existing mechanism to see which one seems to fit better and modify it a bit to match the "one-fits-all". So, insisting a bit, the point was here not to "mine is better" but "take the best and try to put it together". Our view not necessarily is perfect, of course, but we don't want to be 100% as good as native IPv6, and of course, if we start working on this in the WG, we really need a lot of input to be able to reach a consensus. Obviously choice 1) somehow exist in some OSs, but could be improved and will also support choice 2). We also need to understand that existing implementations may decide not to go quickly or 2), so some parallel work here is good and required. So answering your final question, I will opt for the consensus, and actually will like to continue our work on this (in the WG if possible), and I think it can be done in a short time if the WG contributes a bit (just a bit more than now !). Despite that, I would not exclude that some of the mechanisms want to follow their actual process and go for informational, in a parallel. At the end, depending on timing, results of 2), market will take the decision, but at least we will be able in the position, as IETF, to provide a good solution. Regards, Jordi > De: Fred Baker > Responder a: > Fecha: Tue, 5 Apr 2005 16:34:52 -0700 > Para: "v6ops@ops.ietf.org" > CC: Lindqvist Erik Kurt , David Kessens > > Asunto: Tunneling and Transition Drafts > > I need a consensus of the WG. > > In what I am about to say, someone might possibly feel their toes > stepped on. Apologies in advance - and get used to it. I have big feet, > and I often put them in my mouth. > > In taking over the working group, Kurt and I basically were presented > with the following scenario: > - this group is for operational questions (not protocols) > - this group seeks to conform to RFC 1958 (we are not here to bless > very lame solution that comes along) > - transition mechanisms are generally out of scope. > > As I understand it, v6tc (which was intended to take over all the > tunneling stuff, which is to say a large proposition of the transition > stuff) is dead in the water. The expectation was that all the > tunneling/transition stuff would move there, but the BOF was a > non-event. There isn't likely to be a v6tc WG. (Dear AD: if you > disagree, this would be a good time to say so). > > That said, there are roughly 80 gazillion different transition > solutions out there, including at least silkroad, teredo, DSTM, secure > tunnels, etc. To deploy IPv6 in a network that is in parts IPv4-only, > in parts IPv6-only, in parts dual, and in parts what Jim Bound calls > "IPv6-dominant" (which is not a bad term, btw), which I think I would > say is ipv6-only in its service but might use IPv4 internally, it seems > to me that one needs six things said or defined: > > - "please turn IPv6 on by default in your end systems" > > - "please turn IPv6 on in your enterprise network" > > - "please turn IPv6 on in your access/ISP network" > > - how to tunnel IPv6 through an IPv4-only/dominant network between > IPv6-only/dominant hosts or networks > > key attribute: static or dynamic IPv6/IPv4 tunnels between tunnel > endpoints, and appropriate routing through the IPv4 domain to > determine what the appropriate tunnel endpoint router would be. > Could be done with a DNS name not unlike a reverse lookup for > the IPv6 address but delivering an IPv4 "A" record. Could also > be done through simple routing if the tunnels sty up or use a > concept like RFC 1793. > > - how to tunnel IPv4 through an IPv6-only/dominant network between > IPv4-only/dominant hosts or networks > > key attribute: static or dynamic IPv4/IPv6 tunnels between tunnel > endpoints, and appropriate routing through the IPv4 domain to > determine what the appropriate tunnel endpoint router would be. > Could be done with a DNS name not unlike a reverse lookup for > the IPv4 address but delivering an IPv6 "AAAA" record. Could > also be done through simple routing if the tunnels sty up or use > a concept like RFC 1793. > > - how to translate IPv6->IPv4 and IPv6-IPv4 between an > IPv6-only/dominant > and an IPv4-only/dominant domain > > key attribute: translation system captures DNS lookups and > re-advertises its own address in some way, so that IPv4 hosts > seeking IPv6 peers connect to it and it translates, and IPv6 > hosts connect to it and it translates. > > Note that I didn't say what kind of tunnel. GRE, MPLS, IP/IP, IPSEC, > L2TP, who knows what else - they all must be addressed. > > I have a fairly large number of ways to do those - silkroad, teredo, > dstm, and a list of others. Each one, when it looks at the others, says > "but mine is better" or "my customers want to deploy mine now". > > I have no idea how this transition is going to happen if we can't sound > a clear signal on how to do it. > > Which brings me to my question. I am being asked by various proponents > of various things what the working group wants to do with their > approach. I need to know what the game plan for this working group is: > let a thousand flowers bloom (they can all ask for informational status > from the RFC Editor and the probability that the transition will happen > in an orderly fashion rapidly approaches zero), or I need a consensus > statement from the working group that every single approach on the > table will be set aside and the working group will actively work on > providing a single solution that meets all those needs that the IETF > can look at and say "yes, that will accomplish an orderly transition in > a timely fashion and *I*will*support*that*in*favor*of*all*others". > > Opinions? > ************************************ Barcelona 2005 Global IPv6 Summit Registration open. Information available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Tue Apr 5 20:50:27 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06444 for ; Tue, 5 Apr 2005 20:50:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIyjC-00079E-K2 for v6ops-data@psg.com; Wed, 06 Apr 2005 00:49:06 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DIyjA-00078x-SS for v6ops@ops.ietf.org; Wed, 06 Apr 2005 00:49:04 +0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 05 Apr 2005 17:49:04 -0700 Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id j360n1gT017273; Tue, 5 Apr 2005 17:49:02 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <144826f4710aa69d457773a8c3862a53@cisco.com> Content-Transfer-Encoding: 7bit Cc: "v6tc@ietf.org" , "v6ops@ops.ietf.org" From: Fred Baker Subject: Re: Tunneling and Transition Drafts Date: Tue, 5 Apr 2005 17:49:00 -0700 To: jordi.palet@consulintel.es X-Mailer: Apple Mail (2.619.2) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Apr 5, 2005, at 5:30 PM, JORDI PALET MARTINEZ wrote: > Despite that, I would not exclude that some of the mechanisms want to > follow > their actual process and go for informational I obviously have no problem with informational notes. Teredo is going that route, Silkroad is going through the Chinese Standards Agency, DSTM appears to be opting for "just do it", and so on. I'm trying to figure out what, if anything, the IETF is going to do. From owner-v6ops@ops.ietf.org Tue Apr 5 22:09:02 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12847 for ; Tue, 5 Apr 2005 22:09:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIzwe-000FMX-Np for v6ops-data@psg.com; Wed, 06 Apr 2005 02:07:04 +0000 Received: from [168.103.150.210] (helo=hestia.native6.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DIzwd-000FMH-Pg for v6ops@ops.ietf.org; Wed, 06 Apr 2005 02:07:03 +0000 Received: from JSN6LT (host-66-202-104-251.col.choiceone.net [66.202.104.251]) (authenticated bits=0) by hestia.native6.com (8.12.8/8.12.8) with ESMTP id j3626rpm020034 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 5 Apr 2005 19:07:00 -0700 Message-Id: <200504060207.j3626rpm020034@hestia.native6.com> From: "John Spence, CCSI, CCNA, CISSP" To: Subject: RE: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] Date: Tue, 5 Apr 2005 19:06:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <42528394.3090304@zurich.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Thread-Index: AcU534+fsV7C1f3GSx6sVJJbbGt23gAa6MXA X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a good discussion - I'm refining my views on this based on all your comments. -------- on edge firewalls and proxies ... If you are proposing that an edge firewall running a stateful protocol filter provides a good alternative to NAT, I completely agree. By advocating using stateful edge firewalls or port filtering, you are also proposing breaking end-to-end, or peer-to-peer, because you are preventing the "protected" systems from being reachable from the Internet. Of course - that's what you want. Only an unprotected IPv6 node is truly peer-to-peer - capable of being contacted by any process from any other node - which would be crazy on today's public network. Even with distributed (host) firewalls, breaking end-to-end is actually a goal - just a selective goal. I break end-to-end for some connection types and call it "protection" - other peer-to-peer services I allow. IMHO, what we want to provide is "managed peer-to-peer". With NAT, I simply cannot provide internal nodes with peer-to-peer - I do not have enough addresses. With NAP, I can allow peer-to-peer selectively for any node, allowing me to "protect them", but also "selectively expose them" - where I expose them to be peers for other nodes I specify or specific services I authorize. And, to return to the "proxies" point, that is another "peer-to-peer management tool". I can allow a protected node to get HTTP access via a proxy (for example), where I can use my proxy device tools (content inspection, topology hiding, caching, policy enforcement) to enhance security for that node. I can also, since I have IPv6 and plenty of addresses, implement my edge firewall rules to allow it to be a true peer of some other nodes on the network when peer-to-peer is the way the application works best. Managed protection for internal nodes, use of proxies for some types of connections, when they provide advantages, and true peer-to-peer where that's the right connection type for a given application. Seems like the best of both worlds to me. Spence From owner-v6ops@ops.ietf.org Tue Apr 5 23:04:19 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16089 for ; Tue, 5 Apr 2005 23:04:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJ0pE-000K4X-2H for v6ops-data@psg.com; Wed, 06 Apr 2005 03:03:28 +0000 Received: from [210.84.225.147] (helo=ubu.nosense.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DJ0pB-000K41-5L for v6ops@ops.ietf.org; Wed, 06 Apr 2005 03:03:26 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 42C2962AE5; Wed, 6 Apr 2005 12:33:23 +0930 (CST) Date: Wed, 6 Apr 2005 12:33:22 +0930 From: Mark Smith To: "John Spence, CCSI, CCNA, CISSP" Cc: v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] Message-Id: <20050406123322.13307cb8.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <200504060207.j3626rpm020034@hestia.native6.com> References: <42528394.3090304@zurich.ibm.com> <200504060207.j3626rpm020034@hestia.native6.com> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi John, On Tue, 5 Apr 2005 19:06:47 -0700 "John Spence, CCSI, CCNA, CISSP" wrote: > > This is a good discussion - I'm refining my views on this based on all your > comments. > > -------- on edge firewalls and proxies ... > Even with distributed (host) firewalls, > breaking end-to-end is actually a goal - just a selective goal. I break > end-to-end for some connection types and call it "protection" - other > peer-to-peer services I allow. > (not sure if this is off topic for the list, apologies if it is) While it might appear to be a semantic argument, I don't think host firewalls are breaking end-to-end. In simple terms, I think that end-to-end is another way of expressing the classic cliche, "If you want something done properly, you need to do it yourself." When it comes to reliable data delivery, trustworthy security, or service availability limitations (e.g., firewalling) the node which "wants the job done properly" the most is the end-node itself. Intermediary devices, such as routers, usually service more than one end-node, and therefore generally can't be trusted to have the same interest "in the job being done properly" as each of the end nodes themselves. Additionally, they usually don't have enough information to be sure that they are doing the "proper job". In the case of host based firewalling, the host itself is the most knowledgable regarding what its firewalling requirements are, and therefore is the best device to perform that firewalling. An additional advantage of host based firewalling is that it is network topology independant. This is going to matter more and more as mobile devices, such as laptops, have multiple wired and wireless interfaces. This may sound theoretical; interestingly, host based firewalling capability is pretty much already a reality today. All major OSes (*nix, MS, Apple, etc.,) are coming with a firewalling capability out of the box, commonly defaulted to "on". Additionally, it is in every "desktop" OS, rather than just special nodes such as servers, as the OS "manufacturer" couldn't be sure that there would be an upstream, intermediary firewalling device. OS manufacturers have decided that each and every individual device has to be responsible for its own firewalling. Firewalling is already evolving towards the end-to-end model. (Arguably, even host based firewalling isn't true end-to-end. In reality, it is the applications themselves that have more knowledge of their security requirements than the Host OS, and therefore they should be executing security functions themselves. For example, SSH implements security within the application, and therefore host or network firewalling, based on network IP(v4|v6) identity or location and transport layer port numbers, isn't really that necessary for SSH) Regards, Mark. -- The Internet's nature is peer to peer. From owner-v6ops@ops.ietf.org Tue Apr 5 23:17:41 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17035 for ; Tue, 5 Apr 2005 23:17:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJ10h-000LWw-Kw for v6ops-data@psg.com; Wed, 06 Apr 2005 03:15:19 +0000 Received: from [168.103.150.210] (helo=hestia.native6.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DJ10g-000LWi-Mv for v6ops@ops.ietf.org; Wed, 06 Apr 2005 03:15:18 +0000 Received: from JSN6LT (host-66-202-104-251.col.choiceone.net [66.202.104.251]) (authenticated bits=0) by hestia.native6.com (8.12.8/8.12.8) with ESMTP id j363FFpm020258 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 5 Apr 2005 20:15:17 -0700 Message-Id: <200504060315.j363FFpm020258@hestia.native6.com> From: "John Spence, CCSI, CCNA, CISSP" To: Subject: RE: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] Date: Tue, 5 Apr 2005 20:15:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20050406123322.13307cb8.ipng@69706e6720323030352d30312d31340a.nosense.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Thread-Index: AcU6VTejXqvsRCEMRLyjSd2hzJXLiQAAGlBQ X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark; Good points all. I agree, host firewall is evolving fast, and will be more and more commonly deployed in the future. But are you suggesting that the NAP draft, in an effort to push peer-to-peer "all the way", advocate removing edge firewalls and ACL in favor of only deploying distributed firewalls? I think that would be going way to far. The best way to pry NAT out of the hands of IPv4-oriented security managers is to make the case *for* stateful firewalls over NAT routers - not to try to suggest, at this stage, that even the stateful firewalls should be pulled in favor of having the end nodes use host firewalls to support peer-to-peer networking in the purest sense. Spence ---------------------------- > While it might appear to be a semantic argument, I don't > think host firewalls are breaking end-to-end. > > In simple terms, I think that end-to-end is another way of > expressing the classic cliche, "If you want something done > properly, you need to do it yourself." > > When it comes to reliable data delivery, trustworthy > security, or service availability limitations (e.g., > firewalling) the node which "wants the job done properly" the > most is the end-node itself. Intermediary devices, such as > routers, usually service more than one end-node, and > therefore generally can't be trusted to have the same > interest "in the job being done properly" as each of the end > nodes themselves. > Additionally, they usually don't have enough information to > be sure that they are doing the "proper job". > > In the case of host based firewalling, the host itself is the > most knowledgeable regarding what its firewalling requirements > are, and therefore is the best device to perform that > firewalling. An additional advantage of host based > firewalling is that it is network topology independent. This > is going to matter more and more as mobile devices, such as > laptops, have multiple wired and wireless interfaces. > > This may sound theoretical; interestingly, host based > firewalling capability is pretty much already a reality > today. All major OSes (*nix, MS, Apple, etc.,) are coming > with a firewalling capability out of the box, commonly > defaulted to "on". Additionally, it is in every "desktop" > OS, rather than just special nodes such as servers, as the OS > "manufacturer" couldn't be sure that there would be an > upstream, intermediary firewalling device. OS manufacturers > have decided that each and every individual device has to be > responsible for its own firewalling. Firewalling is already > evolving towards the end-to-end model. > > (Arguably, even host based firewalling isn't true end-to-end. > In reality, it is the applications themselves that have more > knowledge of their security requirements than the Host OS, > and therefore they should be executing security functions > themselves. For example, SSH implements security within the > application, and therefore host or network firewalling, based > on network IP(v4|v6) identity or location and transport layer > port numbers, isn't really that necessary for SSH) > > Regards, > Mark. > > -- > > The Internet's nature is peer to peer. From owner-v6ops@ops.ietf.org Tue Apr 5 23:58:18 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19889 for ; Tue, 5 Apr 2005 23:58:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJ1fV-000POZ-6j for v6ops-data@psg.com; Wed, 06 Apr 2005 03:57:29 +0000 Received: from [210.84.225.147] (helo=ubu.nosense.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DJ1fS-000PO9-KB for v6ops@ops.ietf.org; Wed, 06 Apr 2005 03:57:27 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 37A5C62AE5; Wed, 6 Apr 2005 13:27:25 +0930 (CST) Date: Wed, 6 Apr 2005 13:27:24 +0930 From: Mark Smith To: "John Spence, CCSI, CCNA, CISSP" Cc: v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] Message-Id: <20050406132724.361136e8.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <200504060315.j363FFpm020258@hestia.native6.com> References: <20050406123322.13307cb8.ipng@69706e6720323030352d30312d31340a.nosense.org> <200504060315.j363FFpm020258@hestia.native6.com> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi John, On Tue, 5 Apr 2005 20:15:10 -0700 "John Spence, CCSI, CCNA, CISSP" wrote: > > Mark; > > Good points all. I agree, host firewall is evolving fast, and will be more > and more commonly deployed in the future. > > But are you suggesting that the NAP draft, in an effort to push peer-to-peer > "all the way", advocate removing edge firewalls and ACL in favor of only > deploying distributed firewalls? I think that would be going way to far. > The best way to pry NAT out of the hands of IPv4-oriented security managers > is to make the case *for* stateful firewalls over NAT routers - not to try > to suggest, at this stage, that even the stateful firewalls should be pulled > in favor of having the end nodes use host firewalls to support peer-to-peer > networking in the purest sense. Yes and no :-) Yes, because I think that as the move to IPv6 is relatively disruptive ("disruptive" in the sense that deploying a new technology on a large scale is usually disruptive no matter how well it is done - it is always a significant change) it is a good opportunity also (re)introduce ideas that we know in the long term will be beneficial. I think the introduction of IPv6 is also an opportunity to change the way people think and do things with and in their network. For example, as I mentioned, modern OSes have firewalling out of the box. From what I'm aware of, the only component missing, at least in the commercial space i.e., products you can buy, for scalable host based firewalling is mechanisms to deploy the (corporate) firewalling policy to the host. I think it just may be around the corner though - server based authentication services obviously exist, user "login scripts" that are pushed to the users host after authentication have been around a for a long time, its just a matter of a commercially available mechanism to push firewall policy to the user host in a similar manner to login scripts. No, because I realise that people don't necessarily like change, and also like to apply existing and understood models of operation to new environments or technologies. Summarising, I'd like to see IPv6 used as an opporunity to introduce and promote new thinking (well old, but new to most IPv4 people), and provide "new" models of deployment. However, for those who are more resistant to new thinking, identify "old" IPv4 mechanisms and how they can work with IPv6 as a "fall back" alternative to new thinking or as part of a migrationary path to "new thinking". Regards, Mark. -- The Internet's nature is peer to peer. From owner-v6ops@ops.ietf.org Wed Apr 6 00:11:43 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20964 for ; Wed, 6 Apr 2005 00:11:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJ1sY-0000u8-Ee for v6ops-data@psg.com; Wed, 06 Apr 2005 04:10:58 +0000 Received: from [210.84.225.147] (helo=ubu.nosense.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DJ1sX-0000tu-8v for v6ops@ops.ietf.org; Wed, 06 Apr 2005 04:10:57 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 2510B62AE5; Wed, 6 Apr 2005 13:40:52 +0930 (CST) Date: Wed, 6 Apr 2005 13:40:51 +0930 From: Mark Smith To: jspence@native6.com, v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] Message-Id: <20050406134051.3288e316.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20050406132724.361136e8.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <20050406123322.13307cb8.ipng@69706e6720323030352d30312d31340a.nosense.org> <200504060315.j363FFpm020258@hestia.native6.com> <20050406132724.361136e8.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 6 Apr 2005 13:27:24 +0930 Mark Smith wrote: > Yes and no :-) > > Summarising, I'd like to see IPv6 used as an opporunity to introduce and > promote new thinking (well old, but new to most IPv4 people), and > provide "new" models of deployment. However, for those who are more > resistant to new thinking, identify "old" IPv4 mechanisms and how they > can work with IPv6 as a "fall back" alternative to new thinking or as > part of a migrationary path to "new thinking". > To clarify, I'm making broad statements about IPv6 deployment, rather than specifically the NAP draft. Some of my comments would apply to the NAP Draft though. Regards, Mark. -- The Internet's nature is peer to peer. From owner-v6ops@ops.ietf.org Wed Apr 6 01:24:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25889 for ; Wed, 6 Apr 2005 01:24:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJ30K-0007i4-VM for v6ops-data@psg.com; Wed, 06 Apr 2005 05:23:04 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DJ30K-0007hs-AK for v6ops@ops.ietf.org; Wed, 06 Apr 2005 05:23:04 +0000 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Tue, 5 Apr 2005 22:22:59 -0700 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Tue, 5 Apr 2005 22:22:59 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Apr 2005 22:22:58 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Tue, 5 Apr 2005 22:22:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] Date: Tue, 5 Apr 2005 22:22:58 -0700 Message-ID: Thread-Topic: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] Thread-Index: AcU6XZZ4RDkxngXfT963W1B5O1LrSQACrUZA From: "Christian Huitema" To: "Mark Smith" , "John Spence, CCSI, CCNA, CISSP" Cc: X-OriginalArrivalTime: 06 Apr 2005 05:22:59.0061 (UTC) FILETIME=[B232CA50:01C53A68] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > For example, as I mentioned, modern OSes have firewalling out of the > box. From what I'm aware of, the only component missing, at least in the > commercial space i.e., products you can buy, for scalable host based > firewalling is mechanisms to deploy the (corporate) firewalling policy > to the host.=20 Actually, the firewall in Windows XP/SP2 "professional" can be controlled by "group policy", automatically applying the firewall policy defined by the (windows) domain administrator. -- Christian Huitema From owner-v6ops@ops.ietf.org Wed Apr 6 01:52:54 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27961 for ; Wed, 6 Apr 2005 01:52:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJ3Sh-000Atr-JN for v6ops-data@psg.com; Wed, 06 Apr 2005 05:52:23 +0000 Received: from [210.84.225.147] (helo=ubu.nosense.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DJ3Sg-000Atb-G9 for v6ops@ops.ietf.org; Wed, 06 Apr 2005 05:52:22 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 3E87262AE5; Wed, 6 Apr 2005 15:22:16 +0930 (CST) Date: Wed, 6 Apr 2005 15:22:16 +0930 From: Mark Smith To: "Christian Huitema" Cc: jspence@native6.com, v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] Message-Id: <20050406152216.6b07928a.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 5 Apr 2005 22:22:58 -0700 "Christian Huitema" wrote: > > For example, as I mentioned, modern OSes have firewalling out of the > > box. From what I'm aware of, the only component missing, at least in > the > > commercial space i.e., products you can buy, for scalable host based > > firewalling is mechanisms to deploy the (corporate) firewalling policy > > to the host. > > Actually, the firewall in Windows XP/SP2 "professional" can be > controlled by "group policy", automatically applying the firewall policy > defined by the (windows) domain administrator. > That's interesting, I wasn't aware of that. With MS's market share, I suppose that that means that end-node firewall policy deployment is already "mainstream". Thanks, Mark. -- The Internet's nature is peer to peer. From owner-v6ops@ops.ietf.org Wed Apr 6 02:14:58 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13354 for ; Wed, 6 Apr 2005 02:14:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJ3nD-000DHr-Hr for v6ops-data@psg.com; Wed, 06 Apr 2005 06:13:35 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DJ3nB-000DHX-PM for v6ops@ops.ietf.org; Wed, 06 Apr 2005 06:13:34 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j366DOQ10072; Wed, 6 Apr 2005 09:13:24 +0300 Date: Wed, 6 Apr 2005 09:13:24 +0300 (EEST) From: Pekka Savola To: Fred Baker cc: v6ops@ops.ietf.org, Lindqvist Erik Kurt , David Kessens Subject: Re: Tunneling and Transition Drafts In-Reply-To: <4b0b7f3167c75500b1dcb4d912f974e0@cisco.com> Message-ID: References: <4b0b7f3167c75500b1dcb4d912f974e0@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 5 Apr 2005, Fred Baker wrote: > As I understand it, v6tc (which was intended to take over all the tunneling > stuff, which is to say a large proposition of the transition stuff) is dead > in the water. The expectation was that all the tunneling/transition stuff > would move there, but the BOF was a non-event. There isn't likely to be a > v6tc WG. (Dear AD: if you disagree, this would be a good time to say so). No, "[v6tc] intended to take over all the tunneling stuff" was *never* the goal of v6tc. Many months ago (maybe it's at about a year now), when we first discussed how to move around with all the work that keeps coming to v6ops, one of the first proposals was to create "v6tuns" working group, working on the tunneling mechanisms. The idea was rejected in the relatively short order, and has not been seen since. We don't need another ngtrans, specifying all the transition mechanisms people come up with. (However, one, slightly better idea was to create a maintenance WG to move 6to4 to Draft Standard, figure out what to do with so-called 6over4, move rfc2893(bis) to DS, etc. -- but there would undoubtedly be a big slippery slope there, and it may be a bit too early for this activity.) > - how to tunnel IPv6 through an IPv4-only/dominant network between > IPv6-only/dominant hosts or networks > > key attribute: static or dynamic IPv6/IPv4 tunnels between tunnel > endpoints, and appropriate routing through the IPv4 domain to > determine what the appropriate tunnel endpoint router would be. > Could be done with a DNS name not unlike a reverse lookup for > the IPv6 address but delivering an IPv4 "A" record. Could also > be done through simple routing if the tunnels sty up or use a > concept like RFC 1793. The DNS lookup (after you know what you're looking for -- including "discovery" part is trickier) is not a hard problem. The real problem, which v6tc set out primarily to solve was how to set up the tunnel at both endpoints without requiring manual configuration (especially the endpoint addresses) at both ends -- and running a routing protocol between the two is a non-starter. > - how to translate IPv6->IPv4 and IPv6-IPv4 between an IPv6-only/dominant > and an IPv4-only/dominant domain > > key attribute: translation system captures DNS lookups and > re-advertises its own address in some way, so that IPv4 hosts > seeking IPv6 peers connect to it and it translates, and IPv6 > hosts connect to it and it translates. This must be badly worded because that you're saying is basically NAT-PT with DNS-ALG, which is exactly what we just decided was a bit.. um.. problematic, and requested reclassification as Experimental. > Which brings me to my question. I am being asked by various proponents of > various things what the working group wants to do with their approach. I need > to know what the game plan for this working group is: let a thousand flowers > bloom (they can all ask for informational status from the RFC Editor and the > probability that the transition will happen in an orderly fashion rapidly > approaches zero), or I need a consensus statement from the working group that > every single approach on the table will be set aside and the working group > will actively work on providing a single solution that meets all those needs > that the IETF can look at and say "yes, that will accomplish an orderly > transition in a timely fashion and If I read this correctly, you see two options: 1) let the authors publish their stuff as RFC-ed informational, if they want to, or 2) produce a Grand Unified Mechanism somewhere (here or some other WG) which solves all the needs (and hopefully world hunger besides). [This is a bit challenging as those needs include tunneling in every possible way, translation, etc.] These are a bit polarized. What I think we should do is: - obviously, allow 1) if that's what people want - not use the v6ops meeting time etc. on these proposals; short pointers on the list may be OK, but lengthy discussions should be elsewhere (discretion of the chairs to rule out stuff as out of scope, as always) - if a mechanism comes along that a lot of people actually want to work on, ask that they create a BOF, and then see if it gains sufficient momentum or not. - or the authors can obviously try to reach ADs and ask sponsoring the work; or use appropriate other WGs if the work is in scope there (e.g., 6PE (bgp tunneling) work has moved over to IDR wg) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Apr 6 03:57:07 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11576 for ; Wed, 6 Apr 2005 03:57:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJ5O1-000OPc-Rd for v6ops-data@psg.com; Wed, 06 Apr 2005 07:55:41 +0000 Received: from [193.49.159.8] (helo=mail1.renater.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DJ5O0-000OOv-Ga for v6ops@ops.ietf.org; Wed, 06 Apr 2005 07:55:40 +0000 Received: from [193.49.159.162] (helo=[193.49.159.162]) by mail1.renater.fr with esmtp (Exim 4.50) id 1DJ5Nm-0007qR-DG; Wed, 06 Apr 2005 09:55:27 +0200 Message-ID: <425395F8.50501@renater.fr> Date: Wed, 06 Apr 2005 09:55:36 +0200 From: Jerome Durand User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jordi.palet@consulintel.es CC: "v6ops@ops.ietf.org" , "v6tc@ietf.org" Subject: Re: [v6tc] Re: Tunneling and Transition Drafts References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>Opinions? I am not sure I share the view that the BOF was a non-event. There was an agreement from a *large majority* of people in the room to say that the WG should take TSP that fulfills all requirements presented, and make it a standard. Now I guess it's time to move on in that direction. Jerome From owner-v6ops@ops.ietf.org Wed Apr 6 04:02:14 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12206 for ; Wed, 6 Apr 2005 04:02:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJ5Tr-000PAW-38 for v6ops-data@psg.com; Wed, 06 Apr 2005 08:01:43 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DJ5Tq-000PAA-0I for v6ops@ops.ietf.org; Wed, 06 Apr 2005 08:01:42 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j3681bD11961; Wed, 6 Apr 2005 11:01:37 +0300 Date: Wed, 6 Apr 2005 11:01:37 +0300 (EEST) From: Pekka Savola To: Jerome Durand cc: jordi.palet@consulintel.es, "v6ops@ops.ietf.org" , "v6tc@ietf.org" Subject: Re: [v6tc] Re: Tunneling and Transition Drafts In-Reply-To: <425395F8.50501@renater.fr> Message-ID: References: <425395F8.50501@renater.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 6 Apr 2005, Jerome Durand wrote: >>> Opinions? > > I am not sure I share the view that the BOF was a non-event. There was an > agreement from a *large majority* of people in the room to say that the WG > should take TSP that fulfills all requirements presented, and make it a > standard. Now I guess it's time to move on in that direction. It will be interesting to see BoF minutes, because I didn't see large majority. For what it's worth, my recollection was: I saw less than about 5-10 people supporting TSP. I saw less than about 5-10 people supporting doing something new. I saw less than about 5-10 people being comfortable with existing mechanisms (like L2TP). Bottom line is that if we don't need to care about the RTT and overhead concerns at all, I can't clearly see real benefits for TSP instead of just using L2TP. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Apr 6 04:22:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13475 for ; Wed, 6 Apr 2005 04:22:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJ5nc-0002Co-9b for v6ops-data@psg.com; Wed, 06 Apr 2005 08:22:08 +0000 Received: from [193.6.222.240] (helo=mail.ki.iif.hu) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DJ5nb-0002Cb-34 for v6ops@ops.ietf.org; Wed, 06 Apr 2005 08:22:07 +0000 Received: by mail.ki.iif.hu (Postfix, from userid 1003) id 0EA785581; Wed, 6 Apr 2005 10:22:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 0C701557D; Wed, 6 Apr 2005 10:22:04 +0200 (CEST) Date: Wed, 6 Apr 2005 10:22:03 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Mark Smith Cc: Christian Huitema , jspence@native6.com, v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-nap-00.txt & NAT security [2.2] In-Reply-To: <20050406152216.6b07928a.ipng@69706e6720323030352d30312d31340a.nosense.org> Message-ID: <20050406101942.I52492@mignon.ki.iif.hu> References: <20050406152216.6b07928a.ipng@69706e6720323030352d30312d31340a.nosense.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 6 Apr 2005, Mark Smith wrote: > On Tue, 5 Apr 2005 22:22:58 -0700 > "Christian Huitema" wrote: > >>> For example, as I mentioned, modern OSes have firewalling out of the >>> box. From what I'm aware of, the only component missing, at least in >> the >>> commercial space i.e., products you can buy, for scalable host based >>> firewalling is mechanisms to deploy the (corporate) firewalling policy >>> to the host. >> >> Actually, the firewall in Windows XP/SP2 "professional" can be >> controlled by "group policy", automatically applying the firewall policy >> defined by the (windows) domain administrator. >> > > That's interesting, I wasn't aware of that. With MS's market share, I > suppose that that means that end-node firewall policy deployment is > already "mainstream". > I agree, but capabilities of Windows XP+SP2 firewall are rather limited. You can control only incoming traffics and there is no stateful capabilities, that helps you a lot. Regards, Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 From owner-v6ops@ops.ietf.org Wed Apr 6 05:34:30 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19445 for ; Wed, 6 Apr 2005 05:34:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJ6tu-0009c8-25 for v6ops-data@psg.com; Wed, 06 Apr 2005 09:32:42 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.44 (FreeBSD)) id 1DJ6tr-0009bf-T3 for v6ops@ops.ietf.org; Wed, 06 Apr 2005 09:32:40 +0000 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j369WTG01850; Wed, 6 Apr 2005 12:32:30 +0300 (EET DST) X-Scanned: Wed, 6 Apr 2005 12:31:47 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j369Vl6A005729; Wed, 6 Apr 2005 12:31:47 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00ccSVQj; Wed, 06 Apr 2005 12:29:47 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j369ThM11673; Wed, 6 Apr 2005 12:29:43 +0300 (EET DST) Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 6 Apr 2005 12:29:37 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Apr 2005 12:29:37 +0300 Received: from 172.21.154.156 ([172.21.154.156]) by esebe100.NOE.Nokia.com ([172.21.138.118]) with Microsoft Exchange Server HTTP-DAV ; Wed, 6 Apr 2005 09:29:37 +0000 Received: from essrv103nok154156.ntc.nokia.com by ESEBE100.noe.nokia.com; 06 Apr 2005 12:29:37 +0300 Subject: Re: [v6tc] Re: Tunneling and Transition Drafts From: "Soininen Jonne (Nokia-NET/Helsinki)" To: ext Fred Baker Cc: jordi.palet@consulintel.es, "v6ops@ops.ietf.org" , "v6tc@ietf.org" In-Reply-To: <144826f4710aa69d457773a8c3862a53@cisco.com> References: <144826f4710aa69d457773a8c3862a53@cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1112779776.5681.149.camel@essrv103nok154156.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 06 Apr 2005 12:29:37 +0300 X-OriginalArrivalTime: 06 Apr 2005 09:29:37.0814 (UTC) FILETIME=[26F14B60:01C53A8B] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Fred, On Wed, 2005-04-06 at 03:49, ext Fred Baker wrote: > On Apr 5, 2005, at 5:30 PM, JORDI PALET MARTINEZ wrote: > > > Despite that, I would not exclude that some of the mechanisms want to > > follow > > their actual process and go for informational > > I obviously have no problem with informational notes. Teredo is going > that route, Silkroad is going through the Chinese Standards Agency, > DSTM appears to be opting for "just do it", and so on. Just a simple correction: Teredo is going to Proposed as individual submission. ISATAP on the other hand is going to Informational. > > I'm trying to figure out what, if anything, the IETF is going to do. Tell me as well, if you find out... ;) Cheers, Jonne. > > _______________________________________________ > v6tc mailing list > v6tc@ietf.org > https://www1.ietf.org/mailman/listinfo/v6tc -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Wed Apr 6 09:58:54 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13312 for ; Wed, 6 Apr 2005 09:58:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJB0u-000FRd-GT for v6ops-data@psg.com; Wed, 06 Apr 2005 13:56:12 +0000 Received: from [193.252.22.27] (helo=smtp4.wanadoo.fr) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DJB0q-000FQu-Oh for v6ops@ops.ietf.org; Wed, 06 Apr 2005 13:56:09 +0000 Received: from me-wanadoo.net (unknown [127.0.0.1]) by mwinf0409.wanadoo.fr (SMTP Server) with ESMTP id 2E9D91C00347 for ; Wed, 6 Apr 2005 15:56:07 +0200 (CEST) Received: from Rmi (APuteaux-112-1-1-226.w80-11.abo.wanadoo.fr [80.11.214.226]) by mwinf0409.wanadoo.fr (SMTP Server) with ESMTP id 833631C003AB; Wed, 6 Apr 2005 15:56:06 +0200 (CEST) X-ME-UUID: 20050406135606537.833631C003AB@mwinf0409.wanadoo.fr Message-ID: <01aa01c53ab0$5f653310$fd2ffea9@Rmi> From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= To: "Baker Fred" Cc: "Elwyn B Davies" , "Cedric Aoun" , "Bound, Jim" , "v6ops" References: <9C422444DE99BC46B3AD3C6EAFC9711B0895C762@tayexc13.americas.cpqcorp.net> <005101c52884$2c713d20$fd2ffea9@Rmi> <2d7ec483fdd1b687dc19b6e2d51ab198@cisco.com> Subject: Re: WG last call on NAT-PT to Experimental Date: Wed, 6 Apr 2005 15:55:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit >----- Original Message ----- ... >From: "Baker Fred" >To: "Rémi Després" >Sent: Monday, March 14, 2005 1:20 PM >Subject: Re: WG last call on NAT-PT to Experimental ... >I'm not opposed to necessary work being done, but I'm not so sure what work >needs to *be* done. We seem to have a lot of transition efforts around, but >there must be a way to bring them together into a single simple solution. >Bring us that one simple path, and then we'll talk. What I am discussing can become a piece of any "simple solution" which integrates ISATAP. The issue can be restated as follows: GOAL? : is it desirable that IPv4-only devices, at IPv4 fixed addresses in dual-stack sites, can be called in a standard way, at least for applications which are compatible with IPv4-NATs, by ordinary IPv6-capable hosts which consult the DNS? SOLUTION? : Is there a solution for this GOAL, if accepted, which is compatible with all currently recommended IETF specifications, and simple to implement and to operate ? IMHO the answer is YES to both questions. Discussing in IETF details of the SOLUTION, while no consensus is available on (1) would be premature. The FIRST QUESTION to be answered should then be: "Is the above GOAL found generic enough by enough people to deserve IETF attention? And if yes, where should it be discusssed?" Yet, just for information at this stage (please skip if there is not any interest for the GOAL), here is, after having studied a few other schemes, my preferred SOLUTION, based on a simple extension of ISATAP: - The fact that a called device is IPv4-only, as opposed to an ordinary ISATAP host, is recognizable at site entrance by a Host Protocol Indicator (HPI) in the called IPv6 address itself. - The HPI is proposed to be in a bit which is always a 0 in current ISATAP addresses (set to 1 for IPv4-only devices). The proposed bit is the low order one in the first octet of the ISATAP IPv4-address field. (This bit is 0 in all IPv4 private prefixes defined in RFC 1918. Thus, 10/8, 172.16/12 and 192.168/16 prefixes, used for IPv6-capable hosts, become 11/8, 172.17/12 and 192.169/16 for IPv4-only ones). - For IPv4-only called devices, a "NAT6to4" function performs the required translation between IPv6, outside, and IPv4, inside. - This NAT6to4 function is a quite simplified version of the generic NAT-PT: No ALG, in particular no DNS ALG; no fragmentation support; not even port translation assuming that enough local IPv4 addresses, being in the private space, can be allocated to NAT6to4. (With these simplifications, NAT6to4 is not subject to operational problems of NAT-PT identified in draft-ietf-v6ops-natpt-to-exprmntl-00.txt.) Regards, Rémi From owner-v6ops@ops.ietf.org Wed Apr 6 10:02:11 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13610 for ; Wed, 6 Apr 2005 10:02:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJB6S-000GEH-8S for v6ops-data@psg.com; Wed, 06 Apr 2005 14:01:56 +0000 Received: from [193.49.159.8] (helo=mail1.renater.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DJB6R-000GDJ-Ba for v6ops@ops.ietf.org; Wed, 06 Apr 2005 14:01:55 +0000 Received: from [193.49.159.162] (helo=[193.49.159.162]) by mail1.renater.fr with esmtp (Exim 4.50) id 1DJB6C-0001s5-Q0; Wed, 06 Apr 2005 16:01:42 +0200 Message-ID: <4253EBCF.8030800@renater.fr> Date: Wed, 06 Apr 2005 16:01:51 +0200 From: Jerome Durand User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: "v6ops@ops.ietf.org" , "v6tc@ietf.org" Subject: Re: [v6tc] Re: Tunneling and Transition Drafts References: <425395F8.50501@renater.fr> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Well, on my notes I have the question Alain asked at the end that was: "Who would be happy if TC just take TSP and make it an RFC?" You don't mention this question that had a large majority of yes. Then I would be happy to get the "official" minutes as well :) Jerome Pekka Savola wrote: > On Wed, 6 Apr 2005, Jerome Durand wrote: > >>>> Opinions? >> >> >> I am not sure I share the view that the BOF was a non-event. There was >> an agreement from a *large majority* of people in the room to say that >> the WG should take TSP that fulfills all requirements presented, and >> make it a standard. Now I guess it's time to move on in that direction. > > > It will be interesting to see BoF minutes, because I didn't see large > majority. For what it's worth, my recollection was: > > I saw less than about 5-10 people supporting TSP. > I saw less than about 5-10 people supporting doing something new. > I saw less than about 5-10 people being comfortable with existing > mechanisms (like L2TP). > > Bottom line is that if we don't need to care about the RTT and overhead > concerns at all, I can't clearly see real benefits for TSP instead of > just using L2TP. > From owner-v6ops@ops.ietf.org Thu Apr 7 12:27:48 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11153 for ; Thu, 7 Apr 2005 12:27:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJZnh-0003Cz-Kw for v6ops-data@psg.com; Thu, 07 Apr 2005 16:24:13 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DJZnc-0003CM-61 for v6ops@ops.ietf.org; Thu, 07 Apr 2005 16:24:08 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 7D56188; Thu, 7 Apr 2005 12:24:07 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 12:24:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [v6tc] Re: Tunneling and Transition Drafts Date: Thu, 7 Apr 2005 12:24:06 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B08C656AD@tayexc13.americas.cpqcorp.net> Thread-Topic: [v6tc] Re: Tunneling and Transition Drafts Thread-Index: AcU6fux+IUjxYLlATS2qtLY+xkOAagAthQcw From: "Bound, Jim" To: "Pekka Savola" , "Jerome Durand" Cc: , X-OriginalArrivalTime: 07 Apr 2005 16:24:07.0296 (UTC) FILETIME=[38B8D800:01C53B8E] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I agree strongly with Pekka. I still see no strong argument for a vtc working group. /jim=20 > -----Original Message----- > From: v6tc-bounces@ietf.org [mailto:v6tc-bounces@ietf.org] On=20 > Behalf Of Pekka Savola > Sent: Wednesday, April 06, 2005 4:02 AM > To: Jerome Durand > Cc: v6ops@ops.ietf.org; v6tc@ietf.org > Subject: Re: [v6tc] Re: Tunneling and Transition Drafts >=20 > On Wed, 6 Apr 2005, Jerome Durand wrote: > >>> Opinions? > > > > I am not sure I share the view that the BOF was a=20 > non-event. There was an=20 > > agreement from a *large majority* of people in the room to=20 > say that the WG=20 > > should take TSP that fulfills all requirements presented,=20 > and make it a=20 > > standard. Now I guess it's time to move on in that direction. >=20 > It will be interesting to see BoF minutes, because I didn't see large=20 > majority. For what it's worth, my recollection was: >=20 > I saw less than about 5-10 people supporting TSP. > I saw less than about 5-10 people supporting doing something new. > I saw less than about 5-10 people being comfortable with existing > mechanisms (like L2TP). >=20 > Bottom line is that if we don't need to care about the RTT and=20 > overhead concerns at all, I can't clearly see real benefits for TSP=20 > instead of just using L2TP. >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 > _______________________________________________ > v6tc mailing list > v6tc@ietf.org > https://www1.ietf.org/mailman/listinfo/v6tc >=20 From owner-v6ops@ops.ietf.org Thu Apr 7 12:27:52 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11185 for ; Thu, 7 Apr 2005 12:27:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJZnt-0003DX-7H for v6ops-data@psg.com; Thu, 07 Apr 2005 16:24:25 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DJZnc-0003CW-QJ for v6ops@ops.ietf.org; Thu, 07 Apr 2005 16:24:09 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 7866A30DE; Thu, 7 Apr 2005 12:24:08 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 12:24:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [v6tc] Re: Tunneling and Transition Drafts Date: Thu, 7 Apr 2005 12:24:08 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B08C656AE@tayexc13.americas.cpqcorp.net> Thread-Topic: [v6tc] Re: Tunneling and Transition Drafts Thread-Index: AcU6i79dV0AWS+cTSw2tQXnLRIpzTwAqWGOg From: "Bound, Jim" To: "Soininen Jonne (Nokia-NET/Helsinki)" , "ext Fred Baker" Cc: , X-OriginalArrivalTime: 07 Apr 2005 16:24:08.0409 (UTC) FILETIME=[3962AC90:01C53B8E] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable DSTM will send its draft in as experimental and standardize it out of the IETF. We are working that process now and it will become a deployment standard. Teredo, ISATAP, and others are welcome to this process too send me private eamil and I will explain. /jim=20 > -----Original Message----- > From: v6tc-bounces@ietf.org [mailto:v6tc-bounces@ietf.org] On=20 > Behalf Of Soininen Jonne (Nokia-NET/Helsinki) > Sent: Wednesday, April 06, 2005 5:30 AM > To: ext Fred Baker > Cc: v6ops@ops.ietf.org; v6tc@ietf.org > Subject: Re: [v6tc] Re: Tunneling and Transition Drafts >=20 > Fred, >=20 >=20 > On Wed, 2005-04-06 at 03:49, ext Fred Baker wrote: > > On Apr 5, 2005, at 5:30 PM, JORDI PALET MARTINEZ wrote: > >=20 > > > Despite that, I would not exclude that some of the=20 > mechanisms want to=20 > > > follow > > > their actual process and go for informational > >=20 > > I obviously have no problem with informational notes.=20 > Teredo is going=20 > > that route, Silkroad is going through the Chinese Standards Agency,=20 > > DSTM appears to be opting for "just do it", and so on. >=20 > Just a simple correction: Teredo is going to Proposed as individual > submission. ISATAP on the other hand is going to Informational.=20 >=20 > >=20 > > I'm trying to figure out what, if anything, the IETF is going to do. >=20 > Tell me as well, if you find out... ;) >=20 > Cheers, >=20 > Jonne. >=20 > >=20 > > _______________________________________________ > > v6tc mailing list > > v6tc@ietf.org > > https://www1.ietf.org/mailman/listinfo/v6tc > --=20 > Jonne Soininen > Nokia >=20 > Tel: +358 40 527 46 34 > E-mail: jonne.soininen@nokia.com >=20 > _______________________________________________ > v6tc mailing list > v6tc@ietf.org > https://www1.ietf.org/mailman/listinfo/v6tc >=20 From owner-v6ops@ops.ietf.org Thu Apr 7 14:57:58 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26949 for ; Thu, 7 Apr 2005 14:57:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJcAh-000KeD-Rc for v6ops-data@psg.com; Thu, 07 Apr 2005 18:56:07 +0000 Received: from [32.97.182.146] (helo=e6.ny.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DJcAS-000KbY-7R for v6ops@ops.ietf.org; Thu, 07 Apr 2005 18:55:52 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j37Itpdl001060 for ; Thu, 7 Apr 2005 14:55:51 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j37Itpck087126 for ; Thu, 7 Apr 2005 14:55:51 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j37Itokb019390 for ; Thu, 7 Apr 2005 14:55:50 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.211.15]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j37ItoP9019364 for ; Thu, 7 Apr 2005 14:55:50 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j37IseAu006430 for ; Thu, 7 Apr 2005 14:54:42 -0400 Message-Id: <200504071854.j37IseAu006430@rotala.raleigh.ibm.com> Date: Thu, 07 Apr 2005 14:54:40 -0400 From: Thomas Narten Subject: Re: [v6tc] Re: Tunneling and Transition Drafts X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,MISSING_HEADERS autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk ------- Blind-Carbon-Copy To: jordi.palet@consulintel.es cc: "v6tc@ietf.org" Subject: Re: [v6tc] Re: Tunneling and Transition Drafts In-Reply-To: Message from jordi.palet@consulintel.es of "Wed, 06 Apr 2005 02:30:53 +0200." Date: Thu, 07 Apr 2005 14:54:40 -0400 From: Thomas Narten Note: v6ops bcc'ed, followups in v6tc please. > First of all, I think is a very good question to know if the v6tc is really > dead, or what, unless I've missed something, there was not any message about > this. I was about to ask soon in v6tc list (copied now). To be honest, I'm not entirely sure myself. And this is after a rather lot of hallway conversation in Minneapolis. Truth in advertising: I've always been a bit skeptical of this work, and probably continue to be, with the main reason being that I do not see a clear/easy/obvious solution here and I worried alot (while I still wore an AD hat) about starting a WG that wouldn't be able to actually come to closure and complete useful work. It is not enough to want a solution -- a solution must also be achievable. (This comment applies mostly the "tunnel endpoint discovery problem".) I do detect that there are folk that want to form a WG and that there are some that believe there is a problem here to be solved (that needs solving), but so far (AFAIK) the problem hasn't been articulated clearly and (still) strikes me as a bit of a moving target. One (big!) example. There was lots of talk at the BOF and in the presentation about the need for low latency, i.e., it was a "requirement". And I hear "wireless" mentioned and "3G" at approximately the same time. But, my understanding is that 3GPP has already decided to go with ISATAP. So, they aren't a customer for this work. But if that is the case, where is the real requirement for low latency coming from? Is my understanding correct in this regard? Thomas ------- End of Blind-Carbon-Copy From owner-v6ops@ops.ietf.org Thu Apr 7 20:10:26 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21904 for ; Thu, 7 Apr 2005 20:10:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJh2g-0004mn-OW for v6ops-data@psg.com; Fri, 08 Apr 2005 00:08:10 +0000 Received: from [66.93.39.75] (helo=smtp-e.tycool.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DJh2f-0004mO-Kt for v6ops@ops.ietf.org; Fri, 08 Apr 2005 00:08:09 +0000 Received: from [192.168.1.2] (unknown [192.168.1.2]) by smtp-e.tycool.net (Postfix) with ESMTP id E84EAEB; Thu, 7 Apr 2005 17:08:32 -0700 (PDT) In-Reply-To: <4b0b7f3167c75500b1dcb4d912f974e0@cisco.com> References: <4b0b7f3167c75500b1dcb4d912f974e0@cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7bd115f41406aa432a1e1854a3b48495@tycool.net> Content-Transfer-Encoding: 7bit Cc: Lindqvist Erik Kurt , David Kessens , v6ops@ops.ietf.org From: Alain Durand Subject: Re: Tunneling and Transition Drafts Date: Thu, 7 Apr 2005 17:08:08 -0700 To: Fred Baker X-Mailer: Apple Mail (2.619.2) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Apr 5, 2005, at 4:34 PM, Fred Baker wrote: > > In taking over the working group, Kurt and I basically were presented > with the following scenario: > - this group is for operational questions (not protocols) > - this group seeks to conform to RFC 1958 (we are not here to bless > very lame solution that comes along) > - transition mechanisms are generally out of scope. > > As I understand it, v6tc (which was intended to take over all the > tunneling stuff, which is to say a large proposition of the transition > stuff) is dead in the water. The expectation was that all the > tunneling/transition stuff would move there, but the BOF was a > non-event. There isn't likely to be a v6tc WG. (Dear AD: if you > disagree, this would be a good time to say so). Is TC going to be chartered or not, I do not know yet, we are still talking about that. That said, as Pekka mentioned, TC was never meant to pick up all the left-overs from the NGtrans days that were not adopted by v6Ops, it was meant to be a very focused wg. I'll send later the minutes of the meeting, but what I got (and all the people I talk to after shared the same feeling) is that: - We are very late in the game, folks have started to deploy their own ad-hoc solutions, if we do anything, time to market will be critical - What is being deployed is either not documented or not standardized (i.e. not been through community review) - The focus on latency was to try to get a common solution that will fit the wired and wireless case, it seems that this may not be the best approach. > Which brings me to my question. I am being asked by various proponents > of various things what the working group wants to do with their > approach. I need to know what the game plan for this working group is: > let a thousand flowers bloom (they can all ask for informational > status from the RFC Editor and the probability that the transition > will happen in an orderly fashion rapidly approaches zero), or I need > a consensus statement from the working group that every single > approach on the table will be set aside and the working group will > actively work on providing a single solution that meets all those > needs that the IETF can look at and say "yes, that will accomplish an > orderly transition in a timely fashion and > *I*will*support*that*in*favor*of*all*others". let's get into the time machine... Spring 1999. Grenoble IPng & NGtrans interim meeting. Topic: we have too many transition mechanisms, can we converge on one and only one? Summer 2002. Yokohama IETF. Topic: too many transition mechanisms, shut down NGtrans and focus on scenarios in v6ops Spring 2005. now. Topic: too many transition mechanisms, can we converge on one and only one? See a pattern here? - Alain. From owner-v6ops@ops.ietf.org Thu Apr 7 20:35:20 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23419 for ; Thu, 7 Apr 2005 20:35:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJhSG-0007Dk-Gc for v6ops-data@psg.com; Fri, 08 Apr 2005 00:34:36 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.44 (FreeBSD)) id 1DJhSC-0007DS-61 for v6ops@ops.ietf.org; Fri, 08 Apr 2005 00:34:32 +0000 Received: from [10.10.10.100] ([217.126.187.160]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.3.R) with ESMTP id md50000902140.msg for ; Fri, 08 Apr 2005 02:37:30 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 08 Apr 2005 02:32:30 +0200 Subject: Re: Tunneling and Transition Drafts From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: In-Reply-To: <7bd115f41406aa432a1e1854a3b48495@tycool.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Fri, 08 Apr 2005 02:37:48 +0200 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, TO_ADDRESS_EQ_REAL autolearn=no version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Alain, I see the pattern ... But I don't think we actually tried to look into a single solution, and that may be why we haven't moved forward. By the way, I don't agree that the approach on a single solution for wired and wireless isn't the best approach. The point is that it may be or not, depending on the actual solution ;-) Regards, Jordi > De: Alain Durand > Responder a: > Fecha: Thu, 7 Apr 2005 17:08:08 -0700 > Para: Fred Baker > CC: Lindqvist Erik Kurt , David Kessens > , "v6ops@ops.ietf.org" > Asunto: Re: Tunneling and Transition Drafts > > > On Apr 5, 2005, at 4:34 PM, Fred Baker wrote: >> >> In taking over the working group, Kurt and I basically were presented >> with the following scenario: >> - this group is for operational questions (not protocols) >> - this group seeks to conform to RFC 1958 (we are not here to bless >> very lame solution that comes along) >> - transition mechanisms are generally out of scope. >> >> As I understand it, v6tc (which was intended to take over all the >> tunneling stuff, which is to say a large proposition of the transition >> stuff) is dead in the water. The expectation was that all the >> tunneling/transition stuff would move there, but the BOF was a >> non-event. There isn't likely to be a v6tc WG. (Dear AD: if you >> disagree, this would be a good time to say so). > > Is TC going to be chartered or not, I do not know yet, we are still > talking about that. > That said, as Pekka mentioned, TC was never meant to pick up all the > left-overs > from the NGtrans days that were not adopted by v6Ops, it was meant to > be a very > focused wg. > > I'll send later the minutes of the meeting, but what I got (and all the > people I talk to after > shared the same feeling) is that: > - We are very late in the game, folks have started to deploy their own > ad-hoc solutions, > if we do anything, time to market will be critical > - What is being deployed is either not documented or not standardized > (i.e. not been through > community review) > - The focus on latency was to try to get a common solution that will > fit the wired and wireless case, > it seems that this may not be the best approach. > > >> Which brings me to my question. I am being asked by various proponents >> of various things what the working group wants to do with their >> approach. I need to know what the game plan for this working group is: >> let a thousand flowers bloom (they can all ask for informational >> status from the RFC Editor and the probability that the transition >> will happen in an orderly fashion rapidly approaches zero), or I need >> a consensus statement from the working group that every single >> approach on the table will be set aside and the working group will >> actively work on providing a single solution that meets all those >> needs that the IETF can look at and say "yes, that will accomplish an >> orderly transition in a timely fashion and >> *I*will*support*that*in*favor*of*all*others". > > let's get into the time machine... > > Spring 1999. Grenoble IPng & NGtrans interim meeting. > Topic: we have too many transition mechanisms, can we converge on one > and only one? > > Summer 2002. Yokohama IETF. > Topic: too many transition mechanisms, shut down NGtrans and focus on > scenarios in v6ops > > Spring 2005. now. > Topic: too many transition mechanisms, can we converge on one and only > one? > > See a pattern here? > > - Alain. > > ************************************ Barcelona 2005 Global IPv6 Summit Registration open. Information available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Fri Apr 8 00:26:01 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10691 for ; Fri, 8 Apr 2005 00:26:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJl2B-0007RI-6Z for v6ops-data@psg.com; Fri, 08 Apr 2005 04:23:55 +0000 Received: from [203.254.224.33] (helo=mailout3.samsung.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DJl28-0007R3-BA for v6ops@ops.ietf.org; Fri, 08 Apr 2005 04:23:52 +0000 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IEM00H0A1JQ66@mailout3.samsung.com> for v6ops@ops.ietf.org; Fri, 08 Apr 2005 13:23:50 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IEM001U91JQ09@mailout3.samsung.com> for v6ops@ops.ietf.org; Fri, 08 Apr 2005 13:23:50 +0900 (KST) Received: from daniel ([168.219.198.108]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IEM00BU71JPLY@mmp2.samsung.com> for v6ops@ops.ietf.org; Fri, 08 Apr 2005 13:23:50 +0900 (KST) Date: Fri, 08 Apr 2005 13:23:28 +0900 From: Soohong Daniel Park Subject: RE: [v6tc] Re: Tunneling and Transition Drafts In-reply-to: <9C422444DE99BC46B3AD3C6EAFC9711B08C656AE@tayexc13.americas.cpqcorp.net> To: "'Bound, Jim'" , "'Soininen Jonne (Nokia-NET/Helsinki)'" , "'ext Fred Baker'" Cc: v6ops@ops.ietf.org, v6tc@ietf.org Message-id: <000001c53bf2$b723ac60$6cc6dba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT >DSTM will send its draft in as experimental and standardize it out of >the IETF. We are working that process now and it will become a >deployment standard. Teredo, ISATAP, and others are welcome to this >process too send me private eamil and I will explain. Sounds good, and I believe DSTM will be success since it has already explicit applicable domain. I am trying to search for NATPT explicit domain like DSTM to be alive and many efforts are in progress... Thanks. ------------------------------------------- Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. From owner-v6ops@ops.ietf.org Fri Apr 8 07:36:58 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06187 for ; Fri, 8 Apr 2005 07:36:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJrkj-00054H-Bs for v6ops-data@psg.com; Fri, 08 Apr 2005 11:34:21 +0000 Received: from [194.138.12.133] (helo=mxs2.siemens.at) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DJrkg-00053u-5h for v6ops@ops.ietf.org; Fri, 08 Apr 2005 11:34:18 +0000 Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs2.siemens.at with ESMTP id j38BVYgI010582 for ; Fri, 8 Apr 2005 13:31:34 +0200 Received: from zagh102a.zag.siemens.hr ([158.226.129.98]) by vies1k7x.sie.siemens.at (8.12.11/8.12.1) with ESMTP id j38BYDvo009580 for ; Fri, 8 Apr 2005 13:34:14 +0200 Received: by zagh102a.zag.siemens.hr with Internet Mail Service (5.5.2653.19) id <2G076VSY>; Fri, 8 Apr 2005 13:30:10 +0200 Message-ID: From: Bilajbegovic Damir To: v6ops@ops.ietf.org Subject: DNS and IPv6 (transition) Date: Fri, 8 Apr 2005 13:30:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, The question is little bit offtopis but I hope that you will forgive me. DNS responce contain additional records there could be some additional informations that DNS server sends to the client. The case is that DNS is dual stack and the user is the IPv4 only (it does not know what IPv6 is). In the additional informations is part with IPv6 address and AAAA. Will the client ignore such information if it does not know what they are (and not so importannt) or what? Best Regards, Damir From owner-v6ops@ops.ietf.org Fri Apr 8 11:01:29 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29821 for ; Fri, 8 Apr 2005 11:01:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJuwj-0004G4-Iq for v6ops-data@psg.com; Fri, 08 Apr 2005 14:58:57 +0000 Received: from [81.187.81.51] (helo=smtp.aaisp.net.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DJuwg-0004F4-Q6 for v6ops@ops.ietf.org; Fri, 08 Apr 2005 14:58:55 +0000 Received: from [81.187.254.247] (helo=elwynslaptop) by smtp.aaisp.net.uk with esmtp (Exim 4.42) id 1DJuwM-00053z-17; Fri, 08 Apr 2005 15:58:34 +0100 From: "Elwyn davies" To: "'Fernando Gont'" , Cc: , Subject: RE: Security considerations of the ICMPv6 draft Date: Fri, 8 Apr 2005 15:59:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-reply-to: <4.3.2.7.2.20050408081914.00db3c10@server.frh.utn.edu.ar> thread-index: AcU8Ls537v3tooQ4RUqZqi9tLsTgDAAGlSGw X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,URIBL_SBL autolearn=no version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit Hi, Fernando, Looking back at the ICMPv6 draft, in the light of this, there are a number of sanity checks that could be performed on returning error messages to minimise security risks. For example: In draft-gont-tcpm-icmp-attacks-03.txt, the 'port unreachable' error is cited as possibly being classified as a 'hard error' and provoking a reset. This error message should only be generated by the destination node (not an intermediate node) so a check could be added to ensure that the ICMPv6 source was equal to the original packet destination, thus requiring address spoofing (which you suggest is otherwise not necessary because of the rules in 2.2). This would slightly cramp the style of would be hackers. Likewise, getting a spurious 'fragment reassembly time execeeded' message for a packet which wasn't fragmented in the first place. And a number of others. There is also a significant chance that ICMPv6 packets related to TCP coming from outside a firewall would be junked by the firewall, especially if they weren't from the destination address (but usually anyway). Some of this is discussed in the IPv6 Security Overview draft: draft-savola-v6ops-security-overview-03.txt It's very late in the day to modify the ICMPv6 draft but we could put some extra stuff into the security overview as recommendations (I am currently editing this and could add some thoughts on this stuff). What is the community view? - Add some comments and additional sanity checks to the ICMPv6 spec, or - Update the security overview, or - Combination, or - Neither? Regards, Elwyn > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Fernando Gont > Sent: 08 April 2005 12:44 > To: ipv6@ietf.org > Cc: Mukesh.K.Gupta@nokia.com > Subject: Security considerations of the ICMPv6 draft > > Folks, > > I sent some comments off-list to Mukesh, and he suggested to raise them on > the list. > > I think the ICMPv6 draft should add some words to raise awareness about > ICMP-based attacks that can be performed against transport protocols. > > For example, the current draft suggest IPsec, or no checks at all on the > received ICMP error mesasges. > > As pointed out by Pekka: > > >By the way, one additional ICMP attack that could possibly be included in > 5.2: > > > > 6. As the ICMP messages are passed to the upper-layer processes, it > > is possible to perform attacks on the upper layer protocols > > (e.g., TCP) with ICMP [TCP-attack]. Protecting the upper layer > > with IPsec mitigates this problem, though the upper layers may > > also perform some form of validation of ICMPs on their own. > > > >Where [TCP-attack] is an informative reference to > >draft-gont-tcpm-icmp-attacks-03.txt. > > > Another issue that may be worth considering is suggesting that the > so-called "hard errors" should not necessarily be considered "hard". While > there's no RFC 1122 for IPv6 (and thus you might say there's no such thing > as "hard errors" and "soft errors" in v6), I think everyone will > extrapolate RFC 1122's statements on soft and hard errors to the ICMPv6 > specification. > > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From owner-v6ops@ops.ietf.org Fri Apr 8 19:02:12 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19856 for ; Fri, 8 Apr 2005 19:02:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DK2RG-000GMt-5v for v6ops-data@psg.com; Fri, 08 Apr 2005 22:58:58 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DK2RF-000GMg-E8 for v6ops@ops.ietf.org; Fri, 08 Apr 2005 22:58:57 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 08 Apr 2005 15:58:57 -0700 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j38MwrDr002188 for ; Fri, 8 Apr 2005 15:58:54 -0700 (PDT) From: fred@cisco.com Received: (fred@localhost) by irp-view7.cisco.com (8.11.2/CISCO.WS.1.2) id j38MwtT18417 for v6ops@ops.ietf.org; Fri, 8 Apr 2005 15:58:55 -0700 (PDT) Date: Fri, 8 Apr 2005 15:58:55 -0700 (PDT) Message-Id: <200504082258.j38MwtT18417@irp-view7.cisco.com> To: v6ops@ops.ietf.org Subject: draft-ietf-v6ops-nap-00.txt X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk A month ago, many in the working group raised their hasnd to say they would read this document and comment. You know who you are... From owner-v6ops@ops.ietf.org Fri Apr 8 19:08:05 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20184 for ; Fri, 8 Apr 2005 19:08:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DK2Ze-000HdG-3B for v6ops-data@psg.com; Fri, 08 Apr 2005 23:07:38 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DK2Zd-000Hd4-CB for v6ops@ops.ietf.org; Fri, 08 Apr 2005 23:07:37 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 08 Apr 2005 16:07:37 -0700 X-IronPort-AV: i="3.92,90,1112598000"; d="scan'208"; a="247800432:sNHT24338120" Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j38N7XDr007495 for ; Fri, 8 Apr 2005 16:07:34 -0700 (PDT) From: fred@cisco.com Received: (fred@localhost) by irp-view7.cisco.com (8.11.2/CISCO.WS.1.2) id j38N7ZY01275 for v6ops@ops.ietf.org; Fri, 8 Apr 2005 16:07:35 -0700 (PDT) Date: Fri, 8 Apr 2005 16:07:35 -0700 (PDT) Message-Id: <200504082307.j38N7ZY01275@irp-view7.cisco.com> To: v6ops@ops.ietf.org Subject: draft-tschofenig-v6ops-secure-tunnels-03.txt X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Per the minutes, the new chairs are supposed to determine on the list whether there is support for bringing this draft into the working group, or whether it should continue as a personal submission. So I'm asking. If I get private or public emails from 10 people that are not authors in support of it, and little or no objection, I will consider it to have passed that hurdle. Please advise From owner-v6ops@ops.ietf.org Fri Apr 8 19:17:19 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20546 for ; Fri, 8 Apr 2005 19:17:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DK2iF-000Isk-Tt for v6ops-data@psg.com; Fri, 08 Apr 2005 23:16:31 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DK2iB-000Is2-Pg for v6ops@ops.ietf.org; Fri, 08 Apr 2005 23:16:27 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 08 Apr 2005 16:16:28 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j38NGMDr011206; Fri, 8 Apr 2005 16:16:22 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j38N88ZP003900; Fri, 8 Apr 2005 16:08:08 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4c1ae81060c9275187957cb67bae1a3f@cisco.com> Content-Transfer-Encoding: 7bit Cc: v6ops@ops.ietf.org From: Baker Fred Subject: Draft v6ops minutes for IETF62 - for comment by all and update by the chairs Date: Fri, 8 Apr 2005 16:16:22 -0700 To: proceedings@ietf.org X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1113001688.928438"; x:"432200"; a:"rsa-sha1"; b:"nofws:11718"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"b725R4Y1aZiwZHSp5FZSlmG/7xknjYcZmhraN+VldiSp0ukvhSvwxjy4Vh8Hl1d6kmSdAG8p" "Xk7+jrvcF5ULFCLZ5nVN+U5wpCjZJZ9r5BCskepWbXu1Uqkd/QsUsMKla3s2zqJymcwSp+P4F8l" "fjICX7s+IFzilRsyNrK+SRCk="; c:"From: Baker Fred "; c:"Subject: Draft v6ops minutes for IETF62 - for comment by all and upd" "ate by the chairs"; c:"Date: Fri, 8 Apr 2005 16:16:22 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Note to secretariat: presentations used during the meeting are at http://netcore.fi/pekkas/ietf/62/ ------------------------------------------------------------------------ ---------------------------------------- Minutes of IPv6 Operations WG (v6ops) Wednesday, March 9 at 0900-1130 =============================== CHAIRS: Pekka Savola Soininen Jonne - Scribes: Fred Baker Mikael Lind Introduction, agenda bashing, document status - 5 mins, Chairs/Savola - Scribes! (Jabber also?) no comments were logged against the agenda. The chair reviewed the status of a number of documents. This is displayed in the slides used during the meeting. Charter Discussion - 20 mins, Chairs/WG - discuss the pending charter update, if not finalized yet - GOAL: discuss the scope of v6ops WG work; gain consensus on the way forward Kurtis Lindqvist presented a discussion of the proposed working group charter. This is discussed in the slides used during the meeting. Work has a tendency to drag. A statement in the charter gives to opportunity for the chairs to get rid of a topic. Hopefully things will go faster. Kurtis thinks the charter is fine and should be sent to David Kessens for AD processing. The key charter change from the working group discussion makes individual submissions to the working group into working group charter items earlier, rather than going through several iterations as individual submissions, resubmission as a working group item, and immediate approval. Enterprise Analysis Discussion, 15 mins, Bound(?) - draft-ietf-v6ops-ent-analysis-01.txt (or a revision?) - GOAL: discuss issues and the path forward Jim Bound discussed the status of the Enterprise Analysis discussion. This is under review by the IESG and has been held up in that dialog. Key changes include limiting the discussion to dual stack networks and nodes, and updating the matrix of common use cases. Discussion is limited to enterprise needs within the coming 18 months (2005 and 2006). Discussion of transport and higher layers and of multihoming was removed, as the application layer scenarios became complex. The reason is that there are few if any networks that are not being run at least partially using IPv4. There are a number of dual stack networks, and a number of networks that are using IPv4 only for internal management, but none that are literally IPv6-only. There needs to be further discussion of sections 3 and 5 of the draft. Section 6 needs work discussing the difference between "IPv6 only" and "IPv6 dominant". Serious work needs to be done in section 7. Section 8 was dropped, as it recommended transition mechanisms; it may be rewritten in a manner that makes no recommendations. The question Jim placed before the house is whether this document remains of interest to the working group, or should be replaced by documents such as the Japan IPv6 Promotional Council IPv6 Deployment Guide? The sense of the room was that the working group would review the draft intended to be posted by 28 April and make a determination. A question was raised about the authorship - there are five authors, which may be excessive. Jim's sense is that all five authors have been important to the draft and deserve listing. In wireless networks, some issues are arising in neighbor discovery and autoconfiguration. This may become a separate draft. Reasons to classify NAT-PT to Experimental, 10 mins, Davies - draft-ietf-v6ops-natpt-to-exprmntl-00.txt - GOAL: discuss changes, solicit comments before going for WG LC Elwyn Davies discussed changes to the previous proposal, which was to deprecate NATPT, to become making the capability experimental and listing the issues in the algorithm. The key recommendation is to use protocol translators and encapsulators as appropriate. These will need to be discussed in a protocol development working group. draft-daniel-natpt-bis-00.txt discusses such a proposal (NAT-PT without DNS-ALG), but has not at this point been extensively discussed. ISP IPv6 Deployment Scenarios in Broadband Access Networks, 15 mins, Popoviciu(?) - draft-ietf-v6ops-bb-deployment-scenarios-00.txt - GOAL: discuss changes and future direction; prepare for WG LC after 1-2 revisions Adeel Ahmed (for Ciprian Popoviciu) discussed broadband deployment issues. Key changes that have occurred in the drafts related to cable deployment in access networks in the US: Time Warner and Comcast. Updates have related to QoS for encrypted traffic and bulk subscriber provisioning. Added discussion of Wireless LANs in the security section, related to host authentication. The authors solicit suggestions on how to combine or improve the sections on multicast, network management, QoS, and security. The working group is requested to post comments to the authors or to the list by 27 March 2005. The working group is expected to last-call the draft when posted. Updates on the IPv6 Fix Project, 5-10 mins, Jinmei - draft-v6fix-en">http://v6fix.net/wide-draft-v6fix-en - GOAL: share the results of recent experiments, discuss next steps This work is not presented as an internet draft, but as a web page, as it describes a project of the Japanese WIDE project. The objective is to address issues that obstruct transition from IPv4 to IPv6. Key activities include collecting incident reports, network measurement, implementation behavior analysis, and requesting updates from relevant vendors. Practically speaking, the *BSD, Linux, MacOS X, SOlaris, and Windows XP implementations were tested, and work-arounds developed for issues uncovered. The general finding is that implementations are "not bad". These results are summarized at the project site. DNS Misbehavior is being directly studies with JPRS, the JPNIC domain registry. Of domains implementing the AAAA proposal, an automated test of names of the form www.*.co.jp showed that 0.04% of the domains and 0.11% of the servers had detectable problems. These operators are being contacted and the issues addressed. Network quality is also being directly tested. This is based on ping RTT between key measurement points in Japan at WIDE and IIJ, and in Spain, and comparison between IPv6 and IPv4 route testing. Most sites are good for both IPv4 and IPv6. Issues that arise are further tested using traceroute and other tools. There is a plan for feedback to site administrators addressing issues noted. Next steps include firewall testing, working with vendors on improvements, and a public mailing list on issues. Suggestions from the floor included tying into RIPE network path testing, including tunnel detection and mutual ping RTT testing. Status and going forward with IPv6-on-by-Default work, 5-10 mins, Chairs/Savola - draft-ietf-v6ops-v6onbydefault-03.txt - draft-ietf-v6ops-onlinkassumption-02.txt - GOAL: discuss the options how to move forward Pekka Savola presented work relating to the "on-link assumption" and "on by default" work. This addresses a fundamental flaw in DNS lookup mechanisms, that have implementations try with IPv6 before attempting with IPv4. A key issue with this document is that it discusses work in progress, making that work normative for it. The documents were resubmitted removing those references, and the working groups were asked to light a fire under their proposed solutions. The on-link assumption draft will be published with draft-ietf-ipv6-rfc2461bis, which removes that assumption. other issues relate to - TCP soft errors (TCPM considering), - SCTP and SCCP soft-errors (no progress), - default address selection for unreachable destinations (no work done yet), - and application robustness (transition document done). There are three possible ways forward for draft-ietf-v6ops-v6onbydefault-03.txt. One is to leave the normative references, which we have chosen to not do. Another is to simply document the problems; another is to document fixes as they appear. There was quite a bit of discussion by the Chairs, Alain Durand, David Kessens, Jinmei, Tony Hain, and others regarding the working group process. In essence, the question was whether we need to document all the problems that had to be fixed in the process of getting something out, or could that discussion die as the problems were fixed? The sense of the AD was that this document need not be published at all if all the problems were fixed, and the working group was perhaps best served by a blog or website listing current open issues. The sense of others was that the discussion needed to occur, and drafts drove that. The upshot was essentially to punt the matter to the new chairs; David indicated that he would return both documents to the working group. The final question relates to the future of draft-ietf-v6ops-v6onbydefault-03.txt. It could be left as a living document listing the issues. A general suggestion is to use blogging or a web site to manage the temporary information and write an RFC descibing the general class of problem and general solutions. IPv6 Network Architecture Protection, 10-15 mins, Van de Velde(?) - draft-vandevelde-v6ops-nap-01.txt - GOAL: discuss changes and the approach; ask for WG item adoption Tony Hain presented a discussion of network technologies, notably stateful firewalls and similar middleware, designed to meet market needs currently addressed using NAT technology. The new version contains a list of such market requirements; if additional market requirements are known, the authors would like text describing them. The document also covers a gap analysis of issues - ULAs, renumbering, hiding subnet topology, multihoming, and traceability. It is not intended to be all-encompassing. There was wide support in the working group, with many volunteering to read and comment on the updated draft. It will be a working group document. How to secure draft-ietf-v6ops-mech-v2 tunnel with IPsec, 10 mins, Tschofenig(?) - draft-tschofenig-v6ops-secure-tunnels-03.txt (or revised) - GOAL: discuss changes, solicit feedback; ask for WG adoption This is discussion of how to carry out draft-ietf-v6ops-mech-v2-06.txt using IPsec tunnels. Commentary has been towards document clean-up, and the question whether all traffic should be encrypted or only the link-local traffic? It is simpler if one encrypts everything. However if the target is protection of traffic (authentication), then maybe authentication of control traffic makes sense. The new chairs will post a consensus call to v6ops on picking this work up; if consensus does not develop, the work will be allowed to continue as a personal submission. Things to think about when renumbering, 10 mins, Chown - draft-chown-v6ops-renumber-thinkabout-01.txt (to be submitted) - GOAL: introduce the draft, solicit feedback for next revision This draft represents observations and ruminations resulting from testing of the renumbering procedure document and general network practice. Many of these are site-specific issues. Scenarios include those with and without a flag day. Much of this relates to IPv6 features related to renumbering. This includes multi-addressing, multicast, mobile IPv6, and ULAs. The principal use of ULAs in renumbering is a semi-flag-day; one might use them to retain local application support while introducing a flag day outside of your network. Many administrative issues came up which need to be looked at. These relate to router advertisement lifetimes, filters (especially firewall/border filters), renumbering frequency, delay-related considerations, scaling features, and dual stack issues, and application issues. The authors feel that the content is fairly complete, and this will give operators and future workers information relevant to the topic. IPv6 Security Overview - 5-7 mins, Davies - draft-savola-v6ops-security-overview-03.txt - GOAL: talk about differences, solicit more feedback; ask for WG adoption Elwyn's slides pretty much indicate what he said... The folks in the room generally supported the work, and had comments on the floor. Two key discussions were had. One regarded moving the document work working group status. There was no opposition; there was also no comment. The other regarded the place of "privacy" addresses. The authors' comment was that while "security by obscurity" doesn't work well in the Internet, obscurity helps, and could be described as one of the principal functions of a firewall. On the other hand, obscurity only exists for systems that act only as clients; any system that must be addressed by another system must have a predictable address, whether by naming (DNS), announcement (a router), or a priori. This is intended to be a working group item. VLAN usage for transition, 5 mins, Chown - draft-chown-v6ops-vlan-usage-02.txt (this is already a WG item, just not resubmitted yet) - GOAL: discuss issues, if any; solicit feedback. Prepare for WG LC soon. The working group seems to have lost interest in the document. It may be appropriate to send it as a personal submission to the RFC Editor. IPv6 Distributed Security Problem statement, 5 mins, Palet - draft-vives-v6ops-ipv6-security-ps-03.txt - GOAL: alert the WG to the updated draft and solicit feedback Look at a firewall-based security (which it calls a network-based model), and proposes what it calls a host-based model (which centers on host-host exchange of policy and authentication). Key issues relate to the trust model between the network and the host and the complexity of security in the host. The document probably wants to move in the direction of the security area. It also needs a current threat analysis, and an analysis of current security models (including intrusion detection systems, mediation VLANs, the use of 802.1X, etc) in addition to the use of host-based security. The authors plan to update the document with any new comments received. From owner-v6ops@ops.ietf.org Fri Apr 8 19:39:04 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21937 for ; Fri, 8 Apr 2005 19:39:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DK33M-000LNg-3Q for v6ops-data@psg.com; Fri, 08 Apr 2005 23:38:20 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DK33J-000LNQ-5y for v6ops@ops.ietf.org; Fri, 08 Apr 2005 23:38:17 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 08 Apr 2005 16:36:15 -0700 X-IronPort-AV: i="3.92,90,1112598000"; d="scan'208"; a="627086752:sNHT4767333596" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j38NaCZV024392; Fri, 8 Apr 2005 16:36:13 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j38NRt7r004032; Fri, 8 Apr 2005 16:27:55 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <47ac0c0e5afd2cc2232aa5f76ac51a54@cisco.com> Content-Transfer-Encoding: 7bit Cc: v6ops@ops.ietf.org From: Baker Fred Subject: v6ops minutes ietf #62 Date: Fri, 8 Apr 2005 16:36:09 -0700 To: proceedings@ietf.org X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1113002875.949900"; x:"432200"; a:"rsa-sha1"; b:"nofws:11757"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"q6K9mqiYU43ZBW51bsWXmTQ9x8Wnma5SLvFgvlJAT2fWJ/eq501AUWrXExYDsvMU7WjxUsXS" "M+n6UZFuGYOWHBL9py4+v78Q5G8PXOR+R0VC4MAYsZEfr+4TYe+W+r1PQDVpZE/yWUvA2eimo8V" "GVWzuBpO+b3RdT09OJnN4DG4="; c:"From: Baker Fred "; c:"Subject: v6ops minutes ietf #62"; c:"Date: Fri, 8 Apr 2005 16:36:09 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit oops - sending with corrected subject line... Note to secretariat: presentations used during the meeting are at http://netcore.fi/pekkas/ietf/62/ ------------------------------------------------------------------------ ---------------------------------------- Minutes of IPv6 Operations WG (v6ops) Wednesday, March 9 at 0900-1130 =============================== CHAIRS: Pekka Savola Soininen Jonne - Scribes: Fred Baker Mikael Lind Introduction, agenda bashing, document status - 5 mins, Chairs/Savola - Scribes! (Jabber also?) no comments were logged against the agenda. The chair reviewed the status of a number of documents. This is displayed in the slides used during the meeting. Charter Discussion - 20 mins, Chairs/WG - discuss the pending charter update, if not finalized yet - GOAL: discuss the scope of v6ops WG work; gain consensus on the way forward Kurtis Lindqvist presented a discussion of the proposed working group charter. This is discussed in the slides used during the meeting. Work has a tendency to drag. A statement in the charter gives to opportunity for the chairs to get rid of a topic. Hopefully things will go faster. Kurtis thinks the charter is fine and should be sent to David Kessens for AD processing. The key charter change from the working group discussion makes individual submissions to the working group into working group charter items earlier, rather than going through several iterations as individual submissions, resubmission as a working group item, and immediate approval. Enterprise Analysis Discussion, 15 mins, Bound(?) - draft-ietf-v6ops-ent-analysis-01.txt (or a revision?) - GOAL: discuss issues and the path forward Jim Bound discussed the status of the Enterprise Analysis discussion. This is under review by the IESG and has been held up in that dialog. Key changes include limiting the discussion to dual stack networks and nodes, and updating the matrix of common use cases. Discussion is limited to enterprise needs within the coming 18 months (2005 and 2006). Discussion of transport and higher layers and of multihoming was removed, as the application layer scenarios became complex. The reason is that there are few if any networks that are not being run at least partially using IPv4. There are a number of dual stack networks, and a number of networks that are using IPv4 only for internal management, but none that are literally IPv6-only. There needs to be further discussion of sections 3 and 5 of the draft. Section 6 needs work discussing the difference between "IPv6 only" and "IPv6 dominant". Serious work needs to be done in section 7. Section 8 was dropped, as it recommended transition mechanisms; it may be rewritten in a manner that makes no recommendations. The question Jim placed before the house is whether this document remains of interest to the working group, or should be replaced by documents such as the Japan IPv6 Promotional Council IPv6 Deployment Guide? The sense of the room was that the working group would review the draft intended to be posted by 28 April and make a determination. A question was raised about the authorship - there are five authors, which may be excessive. Jim's sense is that all five authors have been important to the draft and deserve listing. In wireless networks, some issues are arising in neighbor discovery and autoconfiguration. This may become a separate draft. Reasons to classify NAT-PT to Experimental, 10 mins, Davies - draft-ietf-v6ops-natpt-to-exprmntl-00.txt - GOAL: discuss changes, solicit comments before going for WG LC Elwyn Davies discussed changes to the previous proposal, which was to deprecate NATPT, to become making the capability experimental and listing the issues in the algorithm. The key recommendation is to use protocol translators and encapsulators as appropriate. These will need to be discussed in a protocol development working group. draft-daniel-natpt-bis-00.txt discusses such a proposal (NAT-PT without DNS-ALG), but has not at this point been extensively discussed. ISP IPv6 Deployment Scenarios in Broadband Access Networks, 15 mins, Popoviciu(?) - draft-ietf-v6ops-bb-deployment-scenarios-00.txt - GOAL: discuss changes and future direction; prepare for WG LC after 1-2 revisions Adeel Ahmed (for Ciprian Popoviciu) discussed broadband deployment issues. Key changes that have occurred in the drafts related to cable deployment in access networks in the US: Time Warner and Comcast. Updates have related to QoS for encrypted traffic and bulk subscriber provisioning. Added discussion of Wireless LANs in the security section, related to host authentication. The authors solicit suggestions on how to combine or improve the sections on multicast, network management, QoS, and security. The working group is requested to post comments to the authors or to the list by 27 March 2005. The working group is expected to last-call the draft when posted. Updates on the IPv6 Fix Project, 5-10 mins, Jinmei - draft-v6fix-en">http://v6fix.net/wide-draft-v6fix-en - GOAL: share the results of recent experiments, discuss next steps This work is not presented as an internet draft, but as a web page, as it describes a project of the Japanese WIDE project. The objective is to address issues that obstruct transition from IPv4 to IPv6. Key activities include collecting incident reports, network measurement, implementation behavior analysis, and requesting updates from relevant vendors. Practically speaking, the *BSD, Linux, MacOS X, SOlaris, and Windows XP implementations were tested, and work-arounds developed for issues uncovered. The general finding is that implementations are "not bad". These results are summarized at the project site. DNS Misbehavior is being directly studies with JPRS, the JPNIC domain registry. Of domains implementing the AAAA proposal, an automated test of names of the form www.*.co.jp showed that 0.04% of the domains and 0.11% of the servers had detectable problems. These operators are being contacted and the issues addressed. Network quality is also being directly tested. This is based on ping RTT between key measurement points in Japan at WIDE and IIJ, and in Spain, and comparison between IPv6 and IPv4 route testing. Most sites are good for both IPv4 and IPv6. Issues that arise are further tested using traceroute and other tools. There is a plan for feedback to site administrators addressing issues noted. Next steps include firewall testing, working with vendors on improvements, and a public mailing list on issues. Suggestions from the floor included tying into RIPE network path testing, including tunnel detection and mutual ping RTT testing. Status and going forward with IPv6-on-by-Default work, 5-10 mins, Chairs/Savola - draft-ietf-v6ops-v6onbydefault-03.txt - draft-ietf-v6ops-onlinkassumption-02.txt - GOAL: discuss the options how to move forward Pekka Savola presented work relating to the "on-link assumption" and "on by default" work. This addresses a fundamental flaw in DNS lookup mechanisms, that have implementations try with IPv6 before attempting with IPv4. A key issue with this document is that it discusses work in progress, making that work normative for it. The documents were resubmitted removing those references, and the working groups were asked to light a fire under their proposed solutions. The on-link assumption draft will be published with draft-ietf-ipv6-rfc2461bis, which removes that assumption. other issues relate to - TCP soft errors (TCPM considering), - SCTP and SCCP soft-errors (no progress), - default address selection for unreachable destinations (no work done yet), - and application robustness (transition document done). There are three possible ways forward for draft-ietf-v6ops-v6onbydefault-03.txt. One is to leave the normative references, which we have chosen to not do. Another is to simply document the problems; another is to document fixes as they appear. There was quite a bit of discussion by the Chairs, Alain Durand, David Kessens, Jinmei, Tony Hain, and others regarding the working group process. In essence, the question was whether we need to document all the problems that had to be fixed in the process of getting something out, or could that discussion die as the problems were fixed? The sense of the AD was that this document need not be published at all if all the problems were fixed, and the working group was perhaps best served by a blog or website listing current open issues. The sense of others was that the discussion needed to occur, and drafts drove that. The upshot was essentially to punt the matter to the new chairs; David indicated that he would return both documents to the working group. The final question relates to the future of draft-ietf-v6ops-v6onbydefault-03.txt. It could be left as a living document listing the issues. A general suggestion is to use blogging or a web site to manage the temporary information and write an RFC descibing the general class of problem and general solutions. IPv6 Network Architecture Protection, 10-15 mins, Van de Velde(?) - draft-vandevelde-v6ops-nap-01.txt - GOAL: discuss changes and the approach; ask for WG item adoption Tony Hain presented a discussion of network technologies, notably stateful firewalls and similar middleware, designed to meet market needs currently addressed using NAT technology. The new version contains a list of such market requirements; if additional market requirements are known, the authors would like text describing them. The document also covers a gap analysis of issues - ULAs, renumbering, hiding subnet topology, multihoming, and traceability. It is not intended to be all-encompassing. There was wide support in the working group, with many volunteering to read and comment on the updated draft. It will be a working group document. How to secure draft-ietf-v6ops-mech-v2 tunnel with IPsec, 10 mins, Tschofenig(?) - draft-tschofenig-v6ops-secure-tunnels-03.txt (or revised) - GOAL: discuss changes, solicit feedback; ask for WG adoption This is discussion of how to carry out draft-ietf-v6ops-mech-v2-06.txt using IPsec tunnels. Commentary has been towards document clean-up, and the question whether all traffic should be encrypted or only the link-local traffic? It is simpler if one encrypts everything. However if the target is protection of traffic (authentication), then maybe authentication of control traffic makes sense. The new chairs will post a consensus call to v6ops on picking this work up; if consensus does not develop, the work will be allowed to continue as a personal submission. Things to think about when renumbering, 10 mins, Chown - draft-chown-v6ops-renumber-thinkabout-01.txt (to be submitted) - GOAL: introduce the draft, solicit feedback for next revision This draft represents observations and ruminations resulting from testing of the renumbering procedure document and general network practice. Many of these are site-specific issues. Scenarios include those with and without a flag day. Much of this relates to IPv6 features related to renumbering. This includes multi-addressing, multicast, mobile IPv6, and ULAs. The principal use of ULAs in renumbering is a semi-flag-day; one might use them to retain local application support while introducing a flag day outside of your network. Many administrative issues came up which need to be looked at. These relate to router advertisement lifetimes, filters (especially firewall/border filters), renumbering frequency, delay-related considerations, scaling features, and dual stack issues, and application issues. The authors feel that the content is fairly complete, and this will give operators and future workers information relevant to the topic. IPv6 Security Overview - 5-7 mins, Davies - draft-savola-v6ops-security-overview-03.txt - GOAL: talk about differences, solicit more feedback; ask for WG adoption Elwyn's slides pretty much indicate what he said... The folks in the room generally supported the work, and had comments on the floor. Two key discussions were had. One regarded moving the document work working group status. There was no opposition; there was also no comment. The other regarded the place of "privacy" addresses. The authors' comment was that while "security by obscurity" doesn't work well in the Internet, obscurity helps, and could be described as one of the principal functions of a firewall. On the other hand, obscurity only exists for systems that act only as clients; any system that must be addressed by another system must have a predictable address, whether by naming (DNS), announcement (a router), or a priori. This is intended to be a working group item. VLAN usage for transition, 5 mins, Chown - draft-chown-v6ops-vlan-usage-02.txt (this is already a WG item, just not resubmitted yet) - GOAL: discuss issues, if any; solicit feedback. Prepare for WG LC soon. The working group seems to have lost interest in the document. It may be appropriate to send it as a personal submission to the RFC Editor. IPv6 Distributed Security Problem statement, 5 mins, Palet - draft-vives-v6ops-ipv6-security-ps-03.txt - GOAL: alert the WG to the updated draft and solicit feedback Look at a firewall-based security (which it calls a network-based model), and proposes what it calls a host-based model (which centers on host-host exchange of policy and authentication). Key issues relate to the trust model between the network and the host and the complexity of security in the host. The document probably wants to move in the direction of the security area. It also needs a current threat analysis, and an analysis of current security models (including intrusion detection systems, mediation VLANs, the use of 802.1X, etc) in addition to the use of host-based security. The authors plan to update the document with any new comments received. From owner-v6ops@ops.ietf.org Fri Apr 8 19:46:35 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22389 for ; Fri, 8 Apr 2005 19:46:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DK3B5-000MkK-1R for v6ops-data@psg.com; Fri, 08 Apr 2005 23:46:19 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DK3Av-000Mhx-CC for v6ops@ops.ietf.org; Fri, 08 Apr 2005 23:46:09 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j38Nk5H17687; Sat, 9 Apr 2005 02:46:06 +0300 Date: Sat, 9 Apr 2005 02:46:05 +0300 (EEST) From: Pekka Savola To: Bilajbegovic Damir cc: v6ops@ops.ietf.org Subject: Re: DNS and IPv6 (transition) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 8 Apr 2005, Bilajbegovic Damir wrote: > Hi, > The question is little bit offtopis but I hope that you will forgive > me. > > DNS responce contain additional records there could be some additional > informations that DNS server sends to the client. The case is that DNS is > dual stack and the user is the IPv4 only (it does not know what IPv6 is). In > the additional informations is part with IPv6 address and AAAA. Will the > client ignore such information if it does not know what they are (and not so > importannt) or what? "DNS is dual stack" is not specific enough. The DNS server doesn't send anything that the user's application (through a resolver) does not request. [Note that an application can request PF_UNSPEC even if IPv6 was not enabled, which results in getaddrinfo() obtaining both A and AAAA results.] I suggest you study draft-ietf-dnsop-ipv6-dns-issues-10.txt -- it should provide the pointers to answer your DNS query. :) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Apr 8 19:54:34 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22849 for ; Fri, 8 Apr 2005 19:54:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DK3IV-000Nwm-TH for v6ops-data@psg.com; Fri, 08 Apr 2005 23:53:59 +0000 Received: from [66.93.39.75] (helo=smtp-e.tycool.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DK3IT-000Nuw-A3 for v6ops@ops.ietf.org; Fri, 08 Apr 2005 23:53:57 +0000 Received: from [192.168.1.2] (unknown [192.168.1.2]) by smtp-e.tycool.net (Postfix) with ESMTP id 7659ADF; Fri, 8 Apr 2005 16:54:24 -0700 (PDT) In-Reply-To: <0af6ef342cbf8a44b60c1a5ab81b7cb8@tycool.net> References: <42522B33.7010005@Sun.COM> <0af6ef342cbf8a44b60c1a5ab81b7cb8@tycool.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/alternative; boundary=Apple-Mail-19--594237166 Message-Id: Cc: v6ops@ops.ietf.org From: Alain Durand Subject: Re: [Fwd: draft-ietf-v6ops-onlinkassumption and draft-ietf-v6ops-v6onbydefault] Date: Fri, 8 Apr 2005 16:53:52 -0700 To: Lindqvist Erik Kurt , sebastien roy , David Kessens , Jim Paugh , Fred Baker X-Mailer: Apple Mail (2.619.2) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --Apple-Mail-19--594237166 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit [resent for wrong v6ops list address] The tracker says: "[david] The working group has to decide whether this document really needs to published. In any case it needs more work by the working group before it can be published." I can understand the first part, but not the second. Could the AD or the chairs clarify what further work is necessary? - Alain. > -------- Original Message -------- > > Subject: > draft-ietf-v6ops-onlinkassumption and draft-ietf-v6ops-v6onbydefault > > Date: > Mon, 28 Mar 2005 08:13:02 -0800 > > From: > Baker Fred > > To: > alain.durand@sun.com , james.paugh@eng.sun.com > , sebastien.roy@eng.sun.com > > > CC: > Lindqvist Erik Kurt , David Kessens > , "v6ops@ietf.org" > > > > The IESG has returned the onlinkassumption and v6onbydefault drafts to > the working group, asking us whether it really needs to be published, > and if so to finish them. > > https://datatracker.ietf.org/public/pidtracker.cgi? > command=view_id&dTag=11066&rfc_flag=0 > https://datatracker.ietf.org/public/pidtracker.cgi? > command=view_id&dTag=11045&rfc_flag=0 > --Apple-Mail-19--594237166 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit [resent for wrong v6ops list address] The tracker says: "Arial0000,0000,FFFD[david] The working group has to decide whether this document really needs to published. In any case it needs more work by the working group before it can be published." I can understand the first part, but not the second. Could the AD or the chairs clarify what further work is necessary? - Alain. -------- Original Message -------- Subject: draft-ietf-v6ops-onlinkassumption and draft-ietf-v6ops-v6onbydefault Date: Mon, 28 Mar 2005 08:13:02 -0800 From: Baker Fred 0000,0000,EEEC< To: 0000,0000,EEECalain.durand@sun.com 0000,0000,EEEC<, 0000,0000,EEECjames.paugh@eng.sun.com 0000,0000,EEEC<, 0000,0000,EEECsebastien.roy@eng.sun.com 0000,0000,EEEC< CC: Lindqvist Erik Kurt 0000,0000,EEEC<, David Kessens 0000,0000,EEEC<, 0000,0000,EEEC"v6ops@ietf.org" 0000,0000,EEEC< The IESG has returned the onlinkassumption and v6onbydefault drafts to the working group, asking us whether it really needs to be published, and if so to finish them. 0000,0000,EEEChttps://datatracker.ietf.org/public/pidtracker.cgi? command=view_id&dTag=11066&rfc_flag=0 0000,0000,EEEChttps://datatracker.ietf.org/public/pidtracker.cgi? command=view_id&dTag=11045&rfc_flag=0 --Apple-Mail-19--594237166-- From owner-v6ops@ops.ietf.org Fri Apr 8 19:57:13 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23082 for ; Fri, 8 Apr 2005 19:57:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DK3LO-000OVu-B1 for v6ops-data@psg.com; Fri, 08 Apr 2005 23:56:58 +0000 Received: from [66.93.39.75] (helo=smtp-e.tycool.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DK3LN-000OVg-CC for v6ops@ops.ietf.org; Fri, 08 Apr 2005 23:56:57 +0000 Received: from [192.168.1.2] (unknown [192.168.1.2]) by smtp-e.tycool.net (Postfix) with ESMTP id A0E0EDF; Fri, 8 Apr 2005 16:57:24 -0700 (PDT) In-Reply-To: <47ac0c0e5afd2cc2232aa5f76ac51a54@cisco.com> References: <47ac0c0e5afd2cc2232aa5f76ac51a54@cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <65a4fe51632a69b1c9e86199381325bf@tycool.net> Content-Transfer-Encoding: 7bit Cc: v6ops@ops.ietf.org From: Alain Durand Subject: Re: v6ops minutes ietf #62 Date: Fri, 8 Apr 2005 16:56:52 -0700 To: Baker Fred X-Mailer: Apple Mail (2.619.2) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Apr 8, 2005, at 4:36 PM, Baker Fred wrote: > Status and going forward with IPv6-on-by-Default work, 5-10 mins, > Chairs/Savola > - draft-ietf-v6ops-v6onbydefault-03.txt > - draft-ietf-v6ops-onlinkassumption-02.txt > - GOAL: discuss the options how to move forward > > Pekka Savola presented work relating to the "on-link assumption" and > "on by default" work. This addresses a fundamental flaw in DNS lookup > mechanisms, that have implementations try with IPv6 before attempting > with IPv4. A key issue with this document is that it discusses work in > progress, making that work normative for it. The documents were > resubmitted removing those references, and the working groups were > asked to light a fire under their proposed solutions. > > The on-link assumption draft will be published with > draft-ietf-ipv6-rfc2461bis, which removes that assumption. draft-ietf-ipv6-rfc2461bis remove the on-link assumption text but does not provide the rationale for the change. - Alain. From owner-v6ops@ops.ietf.org Fri Apr 8 19:58:18 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23112 for ; Fri, 8 Apr 2005 19:58:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DK3MU-000Ogw-5D for v6ops-data@psg.com; Fri, 08 Apr 2005 23:58:06 +0000 Received: from [66.93.39.75] (helo=smtp-e.tycool.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DK3MT-000Ogd-6A for v6ops@ops.ietf.org; Fri, 08 Apr 2005 23:58:05 +0000 Received: from [192.168.1.102] (unknown [192.168.1.1]) by smtp-e.tycool.net (Postfix) with ESMTP id 7714DDF for ; Fri, 8 Apr 2005 16:58:32 -0700 (PDT) Message-ID: <42571A92.9000601@tycool.net> Date: Fri, 08 Apr 2005 16:58:10 -0700 From: Alain Durand User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: comment on draft-ietf-v6ops-bb-deployment-scenarios-01.txt on the cabe modem section Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I have some comments on the cable modem scenario. - the various sub-scenarios have a lot in common. The way there are described in full one by one makes that there is a lot of redundant text. Grouping commonalities in one section and ten, for each sub-case, describing what is different would make the document easier to read. - There is something not obvious on why IGMPv3/MLDv2 is needed. the CM amd CMTS are L2 bridges, so they could just forward any multicast traffic. This is especially true for the CM, which has only 2 interfaces. I reckon it may be different for the CMTS is one wants to make sure multicast traffic for one customer does not accidentally flows to another. In any case, I'd like to see some more text why MLD is needed. Actually the current text is a bit ambiquous, it some places it says that MLD is mandatory, in other it just says that the absence of MLD "could" break ND... - If a cable operator decides to roll out v6 for management purpose, then all the scenarios about using tunnels are moot, unless the home GWR does not support v6. - If v6 multicast is important, support for MLD proxy or PIM-SM is critical in the GWR. If it is not there, is there a work around? - Alain. From owner-v6ops@ops.ietf.org Fri Apr 8 20:43:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25549 for ; Fri, 8 Apr 2005 20:43:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DK42x-00044h-7U for v6ops-data@psg.com; Sat, 09 Apr 2005 00:41:59 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DK42v-00044U-W3 for v6ops@ops.ietf.org; Sat, 09 Apr 2005 00:41:58 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 08 Apr 2005 17:41:57 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j390fqgE006997; Fri, 8 Apr 2005 17:41:53 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j390XbX2004335; Fri, 8 Apr 2005 17:33:38 -0700 In-Reply-To: <0af6ef342cbf8a44b60c1a5ab81b7cb8@tycool.net> References: <42522B33.7010005@Sun.COM> <0af6ef342cbf8a44b60c1a5ab81b7cb8@tycool.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/alternative; boundary=Apple-Mail-1--591357614 Message-Id: <04ffd92600bcb30784b8711b705d65ba@cisco.com> Cc: Lindqvist Erik Kurt , sebastien roy , David Kessens , Jim Paugh , "'v6ops@ops.ietf.org '" From: Fred Baker Subject: Re: [Fwd: draft-ietf-v6ops-onlinkassumption and draft-ietf-v6ops-v6onbydefault] Date: Fri, 8 Apr 2005 17:41:52 -0700 To: Alain Durand X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1113006818.605764"; x:"432200"; a:"rsa-sha1"; b:"nofws:3968"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"ILo/3Y3Ob4cE41wCqKxvhCqndlC0LVuq/pdfw6e7Bv/twxoCo7eHgCzH4l/JV0+eyZNkHeJb" "1POMvXYz1c+Y4L5QbJzO/bHNPJsZxPA0OxROLaVIAZV8WKo5lxEuPK6t6eQoIKxDHslSzYIDcQ7" "HChRYTmNGsJZF00TO5sd7W7A="; c:"From: Fred Baker "; c:"Subject: Re: [Fwd: draft-ietf-v6ops-onlinkassumption and draft-ietf-" "v6ops-v6onbydefault]"; c:"Date: Fri, 8 Apr 2005 17:41:52 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --Apple-Mail-1--591357614 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Apr 8, 2005, at 4:39 PM, Alain Durand wrote: > I can understand the first part, but not the second. Could the AD or > the chairs clarify what further work is necessary? I have asked David and not gotten a reply. In the working group meeting in March, both my minuted and Mikael's note that David stated that he felt that publication of these drafts were unnecessary once the problems they addressed were fixed in the network. Your comment in the same discussion was that documenting the issues had validity beyond the scope of the timeline. As you note in response to the minutes, >> The on-link assumption draft will be published with >> draft-ietf-ipv6-rfc2461bis, which removes that assumption. > > draft-ietf-ipv6-rfc2461bis remove the on-link assumption text but does > not provide the rationale for the change. Let me play devil's advocate for a moment: draft-ietf-ipv6-rfc2462bis-07.txt is right now awaiting an updated draft (see https://datatracker.ietf.org/public/pidtracker.cgi? command=view_id&dTag=11541&rfc_flag=0 for comments ). If this is the primary reason for publishing this document, then maybe some text (comparable to Allison's other 'discuss' questions) could simply be handled there? If not, please advise specifically what additional issues are covered? From my perspective, I don't have a problem sending on-link-assumption back with an appropriate report and publishing it with rfc2461bis. But I think I need to ask you to compare notes with the authors of the other and ensure that the two drafts are entirely in sync. v6onbydefault is rather another story from my perspective. Many end systems are now coming with IPv6 on by default, and software images are available from most common routers (even Linksys, which normally doesn't do anything without a groundswell customer demand). For routers, one also wants to design the network and appropriately configure them, so they don't usually come with even IPv4 on by default in a routing configuration. So if you were presenting arguments for doing so, the arguments are OBE. Willing to be told otherwise, but here my advice would be to take "yes" as an answer form the equipment and OS folks... --Apple-Mail-1--591357614 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit On Apr 8, 2005, at 4:39 PM, Alain Durand wrote: ArialI can understand the first part, but not the second. Could the AD or the chairs clarify what further work is necessary? I have asked David and not gotten a reply. In the working group meeting in March, both my minuted and Mikael's note that David stated that he felt that publication of these drafts were unnecessary once the problems they addressed were fixed in the network. Your comment in the same discussion was that documenting the issues had validity beyond the scope of the timeline. As you note in response to the minutes, The on-link assumption draft will be published with draft-ietf-ipv6-rfc2461bis, which removes that assumption. draft-ietf-ipv6-rfc2461bis remove the on-link assumption text but does not provide the rationale for the change. Let me play devil's advocate for a moment: draft-ietf-ipv6-rfc2462bis-07.txt is right now awaiting an updated draft (see https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11541&rfc_flag=0 for comments ). If this is the primary reason for publishing this document, then maybe some text (comparable to Allison's other 'discuss' questions) could simply be handled there? If not, please advise specifically what additional issues are covered? From my perspective, I don't have a problem sending on-link-assumption back with an appropriate report and publishing it with rfc2461bis. But I think I need to ask you to compare notes with the authors of the other and ensure that the two drafts are entirely in sync. v6onbydefault is rather another story from my perspective. Many end systems are now coming with IPv6 on by default, and software images are available from most common routers (even Linksys, which normally doesn't do anything without a groundswell customer demand). For routers, one also wants to design the network and appropriately configure them, so they don't usually come with even IPv4 on by default in a routing configuration. So if you were presenting arguments for doing so, the arguments are OBE. Willing to be told otherwise, but here my advice would be to take "yes" as an answer form the equipment and OS folks... --Apple-Mail-1--591357614-- From owner-v6ops@ops.ietf.org Sat Apr 9 02:40:50 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11960 for ; Sat, 9 Apr 2005 02:40:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DK9bt-000JfO-FZ for v6ops-data@psg.com; Sat, 09 Apr 2005 06:38:25 +0000 Received: from [66.93.39.75] (helo=smtp-e.tycool.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DK9br-000Jf9-3H for v6ops@ops.ietf.org; Sat, 09 Apr 2005 06:38:23 +0000 Received: from [192.168.1.100] (unknown [192.168.1.100]) by smtp-e.tycool.net (Postfix) with ESMTP id CC38ADF; Fri, 8 Apr 2005 23:38:45 -0700 (PDT) In-Reply-To: <04ffd92600bcb30784b8711b705d65ba@cisco.com> References: <42522B33.7010005@Sun.COM> <0af6ef342cbf8a44b60c1a5ab81b7cb8@tycool.net> <04ffd92600bcb30784b8711b705d65ba@cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Lindqvist Erik Kurt , sebastien roy , v6ops@ops.ietf.org, David Kessens , Jim Paugh From: Alain Durand Subject: Re: [Fwd: draft-ietf-v6ops-onlinkassumption and draft-ietf-v6ops-v6onbydefault] Date: Fri, 8 Apr 2005 23:38:17 -0700 To: Fred Baker X-Mailer: Apple Mail (2.619.2) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Apr 8, 2005, at 5:41 PM, Fred Baker wrote: > >>> The on-link assumption draft will be published with >>> draft-ietf-ipv6-rfc2461bis, which removes that assumption. >> >> draft-ietf-ipv6-rfc2461bis remove the on-link assumption text but >> does not provide the rationale for the change. > > Let me play devil's advocate for a moment: > draft-ietf-ipv6-rfc2462bis-07.txt is right now awaiting an updated > draft (see > https://datatracker.ietf.org/public/pidtracker.cgi? > command=view_id&dTag=11541&rfc_flag=0 for comments ). If this is the > primary reason for publishing this document, then maybe some text > (comparable to Allison's other 'discuss' questions) could simply be > handled there? If not, please advise specifically what additional > issues are covered? I'm not sure I follow you... The change is in 2461bis, not 2462bis. > >From my perspective, I don't have a problem sending > on-link-assumption back with an appropriate report and publishing it > with rfc2461bis. But I think I need to ask you to compare notes with > the authors of the other and ensure that the two drafts are entirely > in sync. The relevant change in rfc2461bis is the deletion of the following sentence in the 2nd paragraph of section 5.2: --> If the Default Router List is empty, the sender assumes that the destination is on-link. as is suggested in the onlink asumption draft... One think we could do is re-spin the draft to change the tense of some sentences to make it more sound "this is why it was done" rather "this is how and why it should be done" As the draft has expired, a new rev is needed anyway. > v6onbydefault is rather another story from my perspective. Many end > systems are now coming with IPv6 on by default, and software images > are available from most common routers (even Linksys, which normally > doesn't do anything without a groundswell customer demand). For > routers, one also wants to design the network and appropriately > configure them, so they don't usually come with even IPv4 on by > default in a routing configuration. So if you were presenting > arguments for doing so, the arguments are OBE. Willing to be told > otherwise, but here my advice would be to take "yes" as an answer form > the equipment and OS folks... Well, I used to work for an OS vendor, and my co-author still do. Maybe it is a conservative, risk adverse one, but we were worried that shipping our stack with v6 on by default would generate a large number of service call, so all necessarily precautions needed to be taken. We wrote the draft in that spirit. Let's look at the table of content and see what is still relevant There are essentially two parts in the document: Things that need to be resolved in the host stacks: 2. No IPv6 Router . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Problems with Default Address Selection for IPv6 . . . . . 3 -> still an issue, but maybe this should be redirected as a separate document toward an update of RFC3484. 2.2 Neighbor Discovery's On-Link Assumption Considered Harmful . . . . . . . . . . . . . . . . . . . . . . . . . 5 -> may be obe by onlinkasuption draft 2.3 Transport Protocol Robustness . . . . . . . . . . . . . . 6 -> Still an open issue, but addressed in the transport wg Things that need to be resolved in the network: 3. Other Problematic Scenarios . . . . . . . . . . . . . . . . . 6 3.1 IPv6 Network of Smaller Scope . . . . . . . . . . . . . . 6 3.1.1 Alleviating the Scope Problem . . . . . . . . . . . . 7 3.2 Poor IPv6 Network Performance . . . . . . . . . . . . . . 7 3.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1 Mitigating Security Risks . . . . . . . . . . . . . . 8 4. Application Robustness . . . . . . . . . . . . . . . . . . . . 9 Those last 2 sections are highlighting general deployment problems, not something special for v6 on by default. I can be convinced that if we put the issue with RFC3483 aside, the first part is now largely obe. Maybe we could re-focus the id on this second part if the wg thinks there is value here... - Alain. From owner-v6ops@ops.ietf.org Sat Apr 9 17:23:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08847 for ; Sat, 9 Apr 2005 17:23:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DKNHi-00024X-41 for v6ops-data@psg.com; Sat, 09 Apr 2005 21:14:30 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DKNHh-00024L-02 for v6ops@ops.ietf.org; Sat, 09 Apr 2005 21:14:29 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 09 Apr 2005 14:14:28 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j39LEIgE027304; Sat, 9 Apr 2005 14:14:19 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j39L641D007235; Sat, 9 Apr 2005 14:06:05 -0700 In-Reply-To: References: <42522B33.7010005@Sun.COM> <0af6ef342cbf8a44b60c1a5ab81b7cb8@tycool.net> <04ffd92600bcb30784b8711b705d65ba@cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5148dc570db40b15f8284268fa6f07ef@cisco.com> Content-Transfer-Encoding: 7bit Cc: Lindqvist Erik Kurt , sebastien roy , v6ops@ops.ietf.org, David Kessens , Jim Paugh From: Fred Baker Subject: Re: [Fwd: draft-ietf-v6ops-onlinkassumption and draft-ietf-v6ops-v6onbydefault] Date: Sat, 9 Apr 2005 14:14:22 -0700 To: Alain Durand X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1113080766.79214"; x:"432200"; a:"rsa-sha1"; b:"nofws:3704"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"b4C9ozek68OO2XCidus8HXZL7xl6MkGDnlKt0VfiPlhOXJp4lUF/b25JdQ7qe4xpDGRkSQJ8" "xi71ga0H78wPbvkrkRTGzpNduhzREPg7bFPNHfUlFfPS5DQeRmUdaWlhYZDCAQmz6CyEwRHlqnB" "10h5Q3BbLUB1qGmpQKxAbFWc="; c:"From: Fred Baker "; c:"Subject: Re: [Fwd: draft-ietf-v6ops-onlinkassumption and draft-ietf-" "v6ops-v6onbydefault]"; c:"Date: Sat, 9 Apr 2005 14:14:22 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Apr 8, 2005, at 11:38 PM, Alain Durand wrote: > I'm not sure I follow you... The change is in 2461bis, not 2462bis. Sorry, you're correct. That said, this merely amplifies the question - and understand that I am simply asking a question. In English, we often say that "there is more than one way to skin a cat". David is saying that wiith 2461bis and adoption of the proposal in it by various vendors, there may be no real need to publish this document. Is there another way to document the information that might be superior? Or is publishing this one the superior process? That's the question. So 2461bis has not even been submitted to the ADs (2462bis has been submitted and sent back for revision). Your assertion is that at least part of the problem is that 2461bis doesn't contain a discussion of why a certain change was made. Well, would it be worthwhile to put that discussion into 2461bis, perhaps in an appendix? Or are there other reasons to publish specifically this document? As to the following, yes, the 3484 comment might go in a separate document and then refocus v6onbydefault to the second topic if the remainder of the first part is OBE. I'm not sure the tense change in on-link-assumption is worth the effort. I would focus on publishing it or not publishing it - unless someone else in the WG has a different perspective. >> >From my perspective, I don't have a problem sending >> on-link-assumption back with an appropriate report and publishing it >> with rfc2461bis. But I think I need to ask you to compare notes with >> the authors of the other and ensure that the two drafts are entirely >> in sync. > > The relevant change in rfc2461bis is the deletion of the following > sentence in the 2nd paragraph of section 5.2: > --> If the Default Router List is empty, the sender assumes that the > destination is on-link. > as is suggested in the onlink asumption draft... > > One think we could do is re-spin the draft to change the tense of some > sentences > to make it more sound "this is why it was done" rather "this is how > and why it should be done" > As the draft has expired, a new rev is needed anyway. > >> v6onbydefault is rather another story from my perspective. Many end >> systems are now coming with IPv6 on by default, and software images >> are available from most common routers (even Linksys, which normally >> doesn't do anything without a groundswell customer demand). For >> routers, one also wants to design the network and appropriately >> configure them, so they don't usually come with even IPv4 on by >> default in a routing configuration. So if you were presenting >> arguments for doing so, the arguments are OBE. Willing to be told >> otherwise, but here my advice would be to take "yes" as an answer >> form the equipment and OS folks... > > Well, I used to work for an OS vendor, and my co-author still do. > Maybe it is a conservative, risk adverse one, but we were worried > that shipping our stack with v6 on by default would generate > a large number of service call, so all necessarily precautions needed > to be taken. We wrote the draft in that spirit. > > Let's look at the table of content and see what is still relevant > There are essentially two parts in the document: > > Things that need to be resolved in the host stacks: > 2. No IPv6 Router . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2.1 Problems with Default Address Selection for IPv6 . . . . . > 3 > -> still an issue, but maybe this should be redirected > as a separate document toward an update of RFC3484. > 2.2 Neighbor Discovery's On-Link Assumption Considered > Harmful . . . . . . . . . . . . . . . . . . . . . . . . . > 5 > -> may be obe by onlinkasuption draft > 2.3 Transport Protocol Robustness . . . . . . . . . . . . . . > 6 > -> Still an open issue, but addressed in the transport wg > > Things that need to be resolved in the network: > 3. Other Problematic Scenarios . . . . . . . . . . . . . . . . . > 6 > 3.1 IPv6 Network of Smaller Scope . . . . . . . . . . . . . . > 6 > 3.1.1 Alleviating the Scope Problem . . . . . . . . . . . . > 7 > 3.2 Poor IPv6 Network Performance . . . . . . . . . . . . . . > 7 > 3.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . > 8 > 3.3.1 Mitigating Security Risks . . . . . . . . . . . . . . > 8 > 4. Application Robustness . . . . . . . . . . . . . . . . . . . . > 9 > > Those last 2 sections are highlighting general deployment problems, > not something special > for v6 on by default. > > I can be convinced that if we put the issue with RFC3483 aside, > the first part is now largely obe. > Maybe we could re-focus the id on this second part if the wg thinks > there is value here... > > - Alain. > From owner-v6ops@ops.ietf.org Sat Apr 9 20:20:22 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19030 for ; Sat, 9 Apr 2005 20:20:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DKQ81-000L9P-O0 for v6ops-data@psg.com; Sun, 10 Apr 2005 00:16:41 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.44 (FreeBSD)) id 1DKQ7y-000L8z-ND for v6ops@ops.ietf.org; Sun, 10 Apr 2005 00:16:39 +0000 Received: from [10.10.10.100] ([217.126.187.160]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.3.R) with ESMTP id md50000906495.msg for ; Sun, 10 Apr 2005 02:18:52 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sun, 10 Apr 2005 02:15:25 +0200 Subject: Re: draft-tschofenig-v6ops-secure-tunnels-03.txt From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: In-Reply-To: <200504082307.j38N7ZY01275@irp-view7.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Sun, 10 Apr 2005 02:19:58 +0200 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, TO_ADDRESS_EQ_REAL autolearn=no version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think I already did some time ago ... But just in case was not clear, this is an important work in the scope of the WG and consequently should be adopted as a WG item. I've just one comment regarding to the document title. Using over is confusing, as it may be mixed up with a deprecated protocol (6over4). So I will suggest to submit the next version as: "Using IPsec to Secure IPv6-in-IPv4 Tunnels" (this was already a general comment across the previous version and has been corrected, but I guess that it was not noticed in the title). Regards, Jordi > De: > Responder a: > Fecha: Fri, 8 Apr 2005 16:07:35 -0700 (PDT) > Para: "v6ops@ops.ietf.org" > Asunto: draft-tschofenig-v6ops-secure-tunnels-03.txt > > Per the minutes, the new chairs are supposed to determine on the list whether > there is support > for bringing this draft into the working group, or whether it should continue > as a personal > submission. So I'm asking. > > If I get private or public emails from 10 people that are not authors in > support of it, and > little or no objection, I will consider it to have passed that hurdle. > > Please advise > > ************************************ Barcelona 2005 Global IPv6 Summit Registration open. Information available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Sun Apr 10 03:27:57 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29363 for ; Sun, 10 Apr 2005 03:27:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DKWp4-000CKu-La for v6ops-data@psg.com; Sun, 10 Apr 2005 07:25:34 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DKWp3-000CKe-3k for v6ops@ops.ietf.org; Sun, 10 Apr 2005 07:25:33 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j3A7Oq922020; Sun, 10 Apr 2005 10:24:52 +0300 Date: Sun, 10 Apr 2005 10:24:52 +0300 (EEST) From: Pekka Savola To: Fred Baker cc: Alain Durand , Lindqvist Erik Kurt , sebastien roy , v6ops@ops.ietf.org, David Kessens , Jim Paugh Subject: Re: [Fwd: draft-ietf-v6ops-onlinkassumption and draft-ietf-v6ops-v6onbydefault] In-Reply-To: <5148dc570db40b15f8284268fa6f07ef@cisco.com> Message-ID: References: <42522B33.7010005@Sun.COM> <0af6ef342cbf8a44b60c1a5ab81b7cb8@tycool.net> <04ffd92600bcb30784b8711b705d65ba@cisco.com> <5148dc570db40b15f8284268fa6f07ef@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, 9 Apr 2005, Fred Baker wrote: > So 2461bis has not even been submitted to the ADs (2462bis has been submitted > and sent back for revision). Your assertion is that at least part of the > problem is that 2461bis doesn't contain a discussion of why a certain change > was made. Well, would it be worthwhile to put that discussion into 2461bis, > perhaps in an appendix? Or are there other reasons to publish specifically > this document? IMHO, the description is too long to be contained in the appendix. However, I do think that 2461bis appendix should mention that the assumption was removed and refer to this document. I think it is important to document this kind of background, so that vendors realize why they should be removing the onlink assumption (when updating their 2461 implementation to 2461bis they might not bother or even notice it otherwise). A document like this also serves as a way to document the arguments if someone later on brings this up again. But see below. > As to the following, yes, the 3484 comment might go in a separate document > and then refocus v6onbydefault to the second topic if the remainder of the > first part is OBE. I'm not sure the tense change in on-link-assumption is > worth the effort. I would focus on publishing it or not publishing it - > unless someone else in the WG has a different perspective. I believe it is useful to have a document which provides brief discussion / pointers as well (first category). I don't have strong preference whether onlink-assumption could be covered in this document, not a separate document. But it seems to me that the log of major changes / issues that v6ops has brought up should be described somewhere. >> Those last 2 sections are highlighting general deployment problems, >> not something special for v6 on by default. >> >> I can be convinced that if we put the issue with RFC3483 aside, the >> first part is now largely obe. Maybe we could re-focus the id on >> this second part if the wg thinks there is value here... As above, I think there is value in also describing the background and/or providing points to issues which have been fixed or are in the process of being fixed. This could be used by a user with an older implementation so see whether he's experiencing any of the issues described in the document. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Apr 10 15:12:49 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12187 for ; Sun, 10 Apr 2005 15:12:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DKhpF-000ERj-NI for v6ops-data@psg.com; Sun, 10 Apr 2005 19:10:29 +0000 Received: from [128.244.26.33] (helo=jhuapl.edu) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DKhpE-000ERQ-Ey for v6ops@ops.ietf.org; Sun, 10 Apr 2005 19:10:28 +0000 Received: from ([128.244.96.116]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.10335545; Sun, 10 Apr 2005 15:10:01 -0400 In-Reply-To: <5148dc570db40b15f8284268fa6f07ef@cisco.com> References: <42522B33.7010005@Sun.COM> <0af6ef342cbf8a44b60c1a5ab81b7cb8@tycool.net> <04ffd92600bcb30784b8711b705d65ba@cisco.com> <5148dc570db40b15f8284268fa6f07ef@cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--438467615; protocol="application/pkcs7-signature" Message-Id: <399cd3c9d892937a9ae0e8f0036c2ed1@innovationslab.net> Cc: David Kessens , v6ops@ops.ietf.org From: Brian Haberman Subject: Re: [Fwd: draft-ietf-v6ops-onlinkassumption and draft-ietf-v6ops-v6onbydefault] Date: Sun, 10 Apr 2005 15:10:01 -0400 To: Fred Baker X-Mailer: Apple Mail (2.619.2) X-esp: ESP<8>=RBL:<0> RDNS:<0> SHA:<8> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Phishing:<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --Apple-Mail-1--438467615 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi Fred, On Apr 9, 2005, at 17:14, Fred Baker wrote: > On Apr 8, 2005, at 11:38 PM, Alain Durand wrote: >> I'm not sure I follow you... The change is in 2461bis, not 2462bis. > > Sorry, you're correct. That said, this merely amplifies the question - > and understand that I am simply asking a question. In English, we > often say that "there is more than one way to skin a cat". David is > saying that wiith 2461bis and adoption of the proposal in it by > various vendors, there may be no real need to publish this document. > Is there another way to document the information that might be > superior? Or is publishing this one the superior process? That's the > question. > > So 2461bis has not even been submitted to the ADs (2462bis has been > submitted and sent back for revision). Your assertion is that at least > part of the problem is that 2461bis doesn't contain a discussion of > why a certain change was made. Well, would it be worthwhile to put > that discussion into 2461bis, perhaps in an appendix? Or are there > other reasons to publish specifically this document? I would like to see the rationale for the change documented in some form. My preference would be to include it in 2461bis as an appendix (in a less verbose form). That way, people will be able to see why the change was made so we don't re-visit the issue over and over and over... And as co-chair of IPv6 WG, I can help coordinate that work if the v6ops determines that is the path we want to follow. Regards, Brian --Apple-Mail-1--438467615 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNDEwMTkxMDAyWjAjBgkqhkiG9w0B CQQxFgQU03sE5s9F07hfeWIPskCrlSRpPyQweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAYtmMG5+bHQFsJZoM5/e4VNo6Y+KptiC34x6HwPLSmZRaXCHuJwcxNm+ffn6P/S7FoeFR Jt6ysGBq8z9bAYU9VKdg0zG1f3EwW5XoORwxBcLhYsJqjymeojVM1MYnj5ySvDbWt145q0DOjsMe oXYr2zg/P7Vq7C8C22KoZUAayzdmgxvJrZW4BCzEymhfZ7F47PupQH60NMpZZkwyoiKK50ijwdn7 KQFFEoEzsnt+C9wL2WsFMjryVXEBGO7K1NDQSo42DQMRgIlY6LAnXzP4rzL63NPnoYQCh1lKvGMM pUdlq7PRBhfdCCw4U4q894n47+WrYt46XbJdQc2lFcIDTAAAAAAAAA== --Apple-Mail-1--438467615-- From owner-v6ops@ops.ietf.org Mon Apr 11 01:50:50 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22480 for ; Mon, 11 Apr 2005 01:50:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DKrlL-000413-7B for v6ops-data@psg.com; Mon, 11 Apr 2005 05:47:07 +0000 Received: from [203.254.224.24] (helo=mailout1.samsung.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DKrlH-00040a-PV for v6ops@ops.ietf.org; Mon, 11 Apr 2005 05:47:03 +0000 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IER00JIFPDA5M@mailout1.samsung.com> for v6ops@ops.ietf.org; Mon, 11 Apr 2005 14:46:22 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IER001EQP394G@mailout1.samsung.com> for v6ops@ops.ietf.org; Mon, 11 Apr 2005 14:40:22 +0900 (KST) Received: from Radhakrishnan ([107.108.71.58]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IER009YEP34CU@mmp2.samsung.com> for v6ops@ops.ietf.org; Mon, 11 Apr 2005 14:40:21 +0900 (KST) Date: Mon, 11 Apr 2005 11:09:31 +0530 From: Radhakrishnan Suryanarayanan Subject: Re: [Fwd: draft-ietf-v6ops-onlinkassumption and draft-ietf-v6ops-v6onbydefault] To: Brian Haberman Cc: V6OPS WG Reply-to: Radhakrishnan Suryanarayanan Message-id: <03b001c53e58$dbd487b0$3a476c6b@sisodomain.com> Organization: SAMSUNG India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <42522B33.7010005@Sun.COM> <0af6ef342cbf8a44b60c1a5ab81b7cb8@tycool.net> <04ffd92600bcb30784b8711b705d65ba@cisco.com> <5148dc570db40b15f8284268fa6f07ef@cisco.com> <399cd3c9d892937a9ae0e8f0036c2ed1@innovationslab.net> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Hi all, The following text in RFC 2461bis Appendix A will also need changes for onlink assumption: " If a multihomed host fails to receive Router Advertisements on one or more of its interfaces, it will not know (in the absence of configured information) which destinations are on-link on the affected interface(s). This leads to a number of problems: 1) If no Router Advertisement is received on any interfaces, a multihomed host will have no way of knowing which interface to send packets out on, even for on-link destinations. Under similar conditions in the non-multihomed host case, a node treats all destinations as residing on-link, and communication ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ proceeds. " ----- Original Message ----- From: "Brian Haberman" To: "Fred Baker" Cc: "David Kessens" ; Sent: Monday, April 11, 2005 12:40 AM Subject: Re: [Fwd: draft-ietf-v6ops-onlinkassumption and draft-ietf-v6ops-v6onbydefault] > Hi Fred, > > On Apr 9, 2005, at 17:14, Fred Baker wrote: > > > On Apr 8, 2005, at 11:38 PM, Alain Durand wrote: > >> I'm not sure I follow you... The change is in 2461bis, not 2462bis. > > > > Sorry, you're correct. That said, this merely amplifies the question - > > and understand that I am simply asking a question. In English, we > > often say that "there is more than one way to skin a cat". David is > > saying that wiith 2461bis and adoption of the proposal in it by > > various vendors, there may be no real need to publish this document. > > Is there another way to document the information that might be > > superior? Or is publishing this one the superior process? That's the > > question. > > > > So 2461bis has not even been submitted to the ADs (2462bis has been > > submitted and sent back for revision). Your assertion is that at least > > part of the problem is that 2461bis doesn't contain a discussion of > > why a certain change was made. Well, would it be worthwhile to put > > that discussion into 2461bis, perhaps in an appendix? Or are there > > other reasons to publish specifically this document? > > I would like to see the rationale for the change documented in some > form. > My preference would be to include it in 2461bis as an appendix (in a > less > verbose form). That way, people will be able to see why the change was > made so we don't re-visit the issue over and over and over... > > And as co-chair of IPv6 WG, I can help coordinate that work if the v6ops > determines that is the path we want to follow. > > Regards, > Brian From owner-v6ops@ops.ietf.org Mon Apr 11 03:05:21 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16756 for ; Mon, 11 Apr 2005 03:05:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DKsxd-000Ci6-0q for v6ops-data@psg.com; Mon, 11 Apr 2005 07:03:53 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.44 (FreeBSD)) id 1DKsxZ-000CgS-T9; Mon, 11 Apr 2005 07:03:50 +0000 Received: from portatilalvaro by consulintel.es (MDaemon.PRO.v7.2.3.R) with ESMTP id md50000907309.msg; Mon, 11 Apr 2005 09:07:06 +0200 Reply-To: From: "Alvaro Vives" To: , Subject: RE: draft-tschofenig-v6ops-secure-tunnels-03.txt Date: Mon, 11 Apr 2005 09:07:03 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <200504082307.j38N7ZY01275@irp-view7.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcU9Qbw5euXm2o+yRhiSs3WJUPpp9wBIylYQ X-Authenticated-Sender: alvaro.vives@consulintel.es X-MDRemoteIP: 10.0.0.158 X-Return-Path: alvaro.vives@consulintel.es Message-ID: X-MDAV-Processed: consulintel.es, Mon, 11 Apr 2005 09:07:09 +0200 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_20,MIME_QP_LONG_LINE autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I support it as a WG item. Alvaro=20 > -----Mensaje original----- > De: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] En nombre de fred@cisco.com > Enviado el: s=E1bado, 09 de abril de 2005 1:08 > Para: v6ops@ops.ietf.org > Asunto: draft-tschofenig-v6ops-secure-tunnels-03.txt >=20 > Per the minutes, the new chairs are supposed to determine on=20 > the list whether there is support for bringing this draft=20 > into the working group, or whether it should continue as a=20 > personal submission. So I'm asking. >=20 > If I get private or public emails from 10 people that are not=20 > authors in support of it, and little or no objection, I will=20 > consider it to have passed that hurdle. >=20 > Please advise >=20 >=20 >=20 ************************************ Barcelona 2005 Global IPv6 Summit Registration open. Information available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Mon Apr 11 20:27:58 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16501 for ; Mon, 11 Apr 2005 20:27:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DL9CD-000I2c-D5 for v6ops-data@psg.com; Tue, 12 Apr 2005 00:24:01 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DL9CC-000I2Q-N8 for v6ops@ops.ietf.org; Tue, 12 Apr 2005 00:24:00 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 11 Apr 2005 17:24:00 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j3C0NuJd017512; Mon, 11 Apr 2005 17:23:56 -0700 (PDT) Received: from [210.72.28.232] (tky-vpn-client-230-112.cisco.com [10.70.230.112]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j3C0EI2Q022663; Mon, 11 Apr 2005 17:15:26 -0700 In-Reply-To: References: <42522B33.7010005@Sun.COM> <0af6ef342cbf8a44b60c1a5ab81b7cb8@tycool.net> <04ffd92600bcb30784b8711b705d65ba@cisco.com> <5148dc570db40b15f8284268fa6f07ef@cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Lindqvist Erik Kurt , Alain Durand , v6ops@ops.ietf.org, sebastien roy , David Kessens , Jim Paugh From: Fred Baker Subject: Re: [Fwd: draft-ietf-v6ops-onlinkassumption and draft-ietf-v6ops-v6onbydefault] Date: Sun, 10 Apr 2005 10:07:56 -0700 To: Pekka Savola X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1113264929.573517"; x:"432200"; a:"rsa-sha1"; b:"nofws:533"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"eRdIoMbi32WerM1uhKUxk7FcfRZjWHIy2cnqGMeKIGBPVKZL7Az5EKAd54+d0jLWVlCHxPR8" "/Zw9DSL64QXtZ5HEEKPCm1czu4LU4Aei9xLCtTOuqsLQW7LqSYoz1jv9omMnz7rX8IEZRIYnaGe" "RsqnAUunHsjSz3a1rRT52HUI="; c:"From: Fred Baker "; c:"Subject: Re: [Fwd: draft-ietf-v6ops-onlinkassumption and draft-ietf-" "v6ops-v6onbydefault]"; c:"Date: Sun, 10 Apr 2005 10:07:56 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_24_48 autolearn=no version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Apr 10, 2005, at 12:24 AM, Pekka Savola wrote: > I think it is important to document this kind of background, so that > vendors realize why they should be removing the onlink assumption > (when updating their 2461 implementation to 2461bis they might not > bother or even notice it otherwise). A document like this also serves > as a way to document the arguments if someone later on brings this up > again. OK. Lets make sure that the normative document and the explanatory document point to each other and send them in together. I will coordinate with Bob+Margaret on coordination if you folks would be so kind as to get the document sorted out. From owner-v6ops@ops.ietf.org Mon Apr 11 20:31:01 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16757 for ; Mon, 11 Apr 2005 20:31:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DL9Ig-000Ieu-Ru for v6ops-data@psg.com; Tue, 12 Apr 2005 00:30:42 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DL9Ig-000Iei-5I for v6ops@ops.ietf.org; Tue, 12 Apr 2005 00:30:42 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 11 Apr 2005 17:30:42 -0700 X-IronPort-AV: i="3.92,95,1112598000"; d="scan'208"; a="248053604:sNHT27807068" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3C0UT7T028259; Mon, 11 Apr 2005 17:30:29 -0700 (PDT) Received: from [210.72.28.232] (tky-vpn-client-230-112.cisco.com [10.70.230.112]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j3C0M2tp022728; Mon, 11 Apr 2005 17:22:03 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6f8ca56e436c767d9a1f28cf7e0ec2cf@cisco.com> Content-Transfer-Encoding: 7bit Cc: "'v6ops@ops.ietf.org '" From: Fred Baker Subject: Re: draft-tschofenig-v6ops-secure-tunnels-03.txt Date: Tue, 12 Apr 2005 08:30:27 +0800 To: X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1113265324.717901"; x:"432200"; a:"rsa-sha1"; b:"nofws:117"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"raV1oV81riun/g1IalLFOL+kIJbVFoYBGQob+9biE2ZbK008xKmGPKpv5ADjdOo5AfHXRqHT" "tWQTpP8XdEldSK233uqj57UYBW93nI2UGYE6SZ6iDi3J1UeAtaXHHsT1omj4nCzPNXIz98mrGNK" "tEsu+9rEkRFgTDfC8dBplc0s="; c:"From: Fred Baker "; c:"Subject: Re: draft-tschofenig-v6ops-secure-tunnels-03.txt"; c:"Date: Tue, 12 Apr 2005 08:30:27 +0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Apr 11, 2005, at 3:07 PM, Alvaro Vives wrote: > I support it as a WG item. Thanks - that makes two folks (you and Jordi). Any other supporters? From owner-v6ops@ops.ietf.org Tue Apr 12 03:06:02 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01916 for ; Tue, 12 Apr 2005 03:06:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DLFR0-000GUU-5V for v6ops-data@psg.com; Tue, 12 Apr 2005 07:03:42 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.44 (FreeBSD)) id 1DLFQx-000GSn-2D for v6ops@ops.ietf.org; Tue, 12 Apr 2005 07:03:39 +0000 Received: from miguelangel01 by consulintel.es (MDaemon.PRO.v7.2.3.R) with ESMTP id md50000910381.msg for ; Tue, 12 Apr 2005 09:07:01 +0200 Message-ID: <004401c53f2d$c027d000$1900a8c0@consulintel.es> From: "Miguel Angel Diaz" To: References: <6f8ca56e436c767d9a1f28cf7e0ec2cf@cisco.com> Subject: Re: draft-tschofenig-v6ops-secure-tunnels-03.txt Date: Tue, 12 Apr 2005 09:03:36 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-RFC2646: Format=Flowed; Response X-Authenticated-Sender: miguelangel.diaz@consulintel.es X-MDRemoteIP: 62.174.245.37 X-Return-Path: miguelangel.diaz@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: miguelangel.diaz@consulintel.es X-MDAV-Processed: consulintel.es, Tue, 12 Apr 2005 09:07:04 +0200 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I also support it as WG item. Regards Miguel ----- Original Message ----- From: "Fred Baker" To: Cc: Sent: Tuesday, April 12, 2005 2:30 AM Subject: Re: draft-tschofenig-v6ops-secure-tunnels-03.txt > > On Apr 11, 2005, at 3:07 PM, Alvaro Vives wrote: > >> I support it as a WG item. > > Thanks - that makes two folks (you and Jordi). Any other supporters? > > ************************************ Barcelona 2005 Global IPv6 Summit Registration open. Information available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Tue Apr 12 04:25:47 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08034 for ; Tue, 12 Apr 2005 04:25:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DLGh3-0000z5-1T for v6ops-data@psg.com; Tue, 12 Apr 2005 08:24:21 +0000 Received: from [155.54.212.105] (helo=xenon2.telemat.um.es) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DLGh1-0000yg-0U for v6ops@ops.ietf.org; Tue, 12 Apr 2005 08:24:19 +0000 Received: from localhost (localhost [127.0.0.1]) by xenon2.telemat.um.es (Postfix) with ESMTP id C259723C354 for ; Tue, 12 Apr 2005 10:24:17 +0200 (CEST) Received: from xenon2.telemat.um.es ([127.0.0.1]) by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 30557-01-97 for ; Tue, 12 Apr 2005 10:24:17 +0200 (CEST) Received: from [172.18.253.246] (vpn37.rem.um.es [155.54.194.37]) by xenon2.telemat.um.es (Postfix) with ESMTP id 8877F23C351 for ; Tue, 12 Apr 2005 10:24:17 +0200 (CEST) Message-ID: <425B8648.3080601@dif.um.es> Date: Tue, 12 Apr 2005 10:26:48 +0200 From: =?ISO-8859-1?Q?=22Antonio_F=2E_G=F3mez_Skarmeta=22?= Organization: Universidad de Murcia User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: es-es, es MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: Re: draft-tschofenig-v6ops-secure-tunnels-03.txt References: <200504082307.j38N7ZY01275@irp-view7.cisco.com> In-Reply-To: <200504082307.j38N7ZY01275@irp-view7.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit fred@cisco.com escribió: >Per the minutes, the new chairs are supposed to determine on the list whether there is support >for bringing this draft into the working group, or whether it should continue as a personal >submission. So I'm asking. > >If I get private or public emails from 10 people that are not authors in support of it, and >little or no objection, I will consider it to have passed that hurdle. > > > I support it regards, Antonio >Please advise > > > > -- ------------------------------------------------------------ Antonio F. Gómez Skarmeta Dept. Ingeniería de la Información y las Comunicaciones Facultad de Informática Universidad de Murcia Apartado 4021 30001 Murcia Telf: +34-968-364607 fax: +34-968-364151 From owner-v6ops@ops.ietf.org Tue Apr 12 05:07:24 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11074 for ; Tue, 12 Apr 2005 05:07:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DLHLm-0006jd-Nh for v6ops-data@psg.com; Tue, 12 Apr 2005 09:06:26 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.44 (FreeBSD)) id 1DLHLi-0006hi-01 for v6ops@ops.ietf.org; Tue, 12 Apr 2005 09:06:22 +0000 Received: from olvera02 by consulintel.es (MDaemon.PRO.v7.2.3.R) with ESMTP id md50000910892.msg for ; Tue, 12 Apr 2005 11:09:43 +0200 From: "Cesar Olvera" To: Subject: RE: draft-tschofenig-v6ops-secure-tunnels-03.txt Date: Tue, 12 Apr 2005 11:09:38 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <425B8648.3080601@dif.um.es> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcU/Ob7/68VBYNSpQbOlvY6+z/WZ9gABUErw X-Authenticated-Sender: cesar.olvera@consulintel.es X-MDRemoteIP: 10.0.0.170 X-Return-Path: cesar.olvera@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: cesar.olvera@consulintel.es Message-ID: X-MDAV-Processed: consulintel.es, Tue, 12 Apr 2005 11:09:48 +0200 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >Per the minutes, the new chairs are supposed to determine on the list >whether there is support for bringing this draft into the working >group, or whether it should continue as a personal submission. So I'm asking. > >If I get private or public emails from 10 people that are not authors >in support of it, and little or no objection, I will consider it to have passed that hurdle. > > > Fred, All, I support for bringing this draft into the WG. Best Regards, Cesar Olvera ************************************ Barcelona 2005 Global IPv6 Summit Registration open. Information available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Tue Apr 12 07:21:49 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20168 for ; Tue, 12 Apr 2005 07:21:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DLJPh-000EdN-SI for v6ops-data@psg.com; Tue, 12 Apr 2005 11:18:37 +0000 Received: from [134.76.81.12] (helo=s2.ifi.informatik.uni-goettingen.de) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.44 (FreeBSD)) id 1DLJPf-000Ecx-0y for v6ops@ops.ietf.org; Tue, 12 Apr 2005 11:18:35 +0000 Received: from [217.167.116.101] ([::ffff:217.167.116.101]) (AUTH: LOGIN fu) by s2.ifi.informatik.uni-goettingen.de with esmtp; Tue, 12 Apr 2005 13:18:32 +0200 id 0004BE35.425BAE88.00003614 Message-ID: <425BAE64.60406@cs.uni-goettingen.de> Date: Tue, 12 Apr 2005 13:17:56 +0200 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en, de, en-gb, de-de, zh-cn MIME-Version: 1.0 To: cesar.olvera@consulintel.es CC: Fred Baker , v6ops@ops.ietf.org Subject: Re: draft-tschofenig-v6ops-secure-tunnels-03.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I also read it and support to move progress. Xiaoming Cesar Olvera wrote: > >>Per the minutes, the new chairs are supposed to determine on the list >>whether there is support for bringing this draft into the working >>group, or whether it should continue as a personal submission. So I'm > > asking. > >>If I get private or public emails from 10 people that are not authors >>in support of it, and little or no objection, I will consider it to have > > passed that hurdle. > >> >> > > > Fred, All, > > I support for bringing this draft into the WG. > > Best Regards, > > Cesar Olvera > > > > > > ************************************ > Barcelona 2005 Global IPv6 Summit > Registration open. Information available at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Tue Apr 12 10:33:40 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04561 for ; Tue, 12 Apr 2005 10:33:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DLMQ5-000DbF-Ad for v6ops-data@psg.com; Tue, 12 Apr 2005 14:31:13 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DLMQ3-000Dav-PV for v6ops@ops.ietf.org; Tue, 12 Apr 2005 14:31:12 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j3CEV0i3007331; Tue, 12 Apr 2005 15:31:00 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id PAA11842; Tue, 12 Apr 2005 15:30:54 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j3CEUse32045; Tue, 12 Apr 2005 15:30:54 +0100 Date: Tue, 12 Apr 2005 15:30:54 +0100 From: Tim Chown To: Jerome Durand Cc: Pekka Savola , "v6ops@ops.ietf.org" , "v6tc@ietf.org" Subject: Re: [v6tc] Re: Tunneling and Transition Drafts Message-ID: <20050412143053.GQ22380@login.ecs.soton.ac.uk> Mail-Followup-To: Jerome Durand , Pekka Savola , "v6ops@ops.ietf.org" , "v6tc@ietf.org" References: <425395F8.50501@renater.fr> <4253EBCF.8030800@renater.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4253EBCF.8030800@renater.fr> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Apr 06, 2005 at 04:01:51PM +0200, Jerome Durand wrote: > Well, on my notes I have the question Alain asked at the end that was: > "Who would be happy if TC just take TSP and make it an RFC?" You don't > mention this question that had a large majority of yes. Then I would be > happy to get the "official" minutes as well :) > > Jerome Jerome, I took rough notes (which I sent to Thomas and Kurtis). The key thing was that half the room voted 'yes' to taking forward v6tc work for 6-in-4 and 4-in-6 (and not for general tunnels, for non IPv6 uses). Here are the lines from my notes where I counted votes, rest of session notes snipped. My feeling is the questions were not well thought out in advance, which is a shame as the rest of the v6tc session was very useful and (apparently :) well prepared. After the first few questions, I think people in the room lost interest/focus... we didn't have 3 or 4 well considered questions prepared. -- (Durand) How many people interested in TC work for 6 in 4 or 4 in 6 only? - Maybe 50% (Durand) For any kind of tunnels? - Maybe 10 (Narten) Worried if we're short-sighted like this (Meyer) Would be to everyone's benefit to find balance of IPv6 need and generic solution for other uses. (Kurtis) We don't know enough yet. Getting a consolidated effort across WGs doing this would be useful. (Ron Boniker?) Suggest rule out any solution that can't be generalised to other domains. (Savola) Need to analyse generic issue if we go wider, else lose IPv6 deadlines (Hinden) Have a zillion tunnel protocols and I don't see advantage of new generic one. I vote for limited scope. Concerned that we are reinventing deployed solutions? (broker?) (Durand) (hat off) Schizophrenia or IETF - requirements analysis vs desire to be generic... ball going back and forth. Chances of success higher if we stay focused on IPv6. (Townsley) Naive to think we'd create something to kill other protocols. (Narten) Brokers are being shipped - why is that not good enough? (Narten) Go with TSP as is? - 10 people (Durand) Is TSP good enough to get by on? - about 10 people (Durand) Need something more? - 10 people (???) Is there a crying demand for this by the ISPs? (Durand) Common implementations would be nice (Narten) Which ISPs need to solve this problem? - 4 people (Durand) Which ISPs think all is done? No problem? - ??? (JDurand) I'm happy with TSP. (Durand) Happy if just do TSP to RFC? (Parent) TSP is just a draft - need expert review (Thaler) Maybe L2TP is enough? TSP doesn't solve TEP discovery. (Durand) Who wants TEP discovery solved? - 12 yes (Durand) And not? - none From owner-v6ops@ops.ietf.org Tue Apr 12 14:47:15 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24475 for ; Tue, 12 Apr 2005 14:47:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DLQNc-000Hia-Gc for v6ops-data@psg.com; Tue, 12 Apr 2005 18:44:56 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DLQNb-000HiN-EA for v6ops@ops.ietf.org; Tue, 12 Apr 2005 18:44:55 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 12 Apr 2005 11:44:55 -0700 X-IronPort-AV: i="3.92,96,1112598000"; d="scan'208,217"; a="248530776:sNHT33473232" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j3CIiqJd013970; Tue, 12 Apr 2005 11:44:53 -0700 (PDT) Received: from [210.72.28.195] (tky-vpn-client-230-23.cisco.com [10.70.230.23]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j3CIaLcg030091; Tue, 12 Apr 2005 11:36:22 -0700 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <20050412143053.GQ22380@login.ecs.soton.ac.uk> References: <425395F8.50501@renater.fr> <4253EBCF.8030800@renater.fr> <20050412143053.GQ22380@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <23ec6165fdb2ab7b2f3946e45caef796@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [v6tc] Re: Tunneling and Transition Drafts Date: Wed, 13 Apr 2005 02:44:49 +0800 To: v6tc@ietf.org, "'v6ops@ops.ietf.org '" X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1113330983.753699"; x:"432200"; a:"rsa-sha1"; b:"nofws:3280"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"IIqjPMRHdivuSf634/tvxxaP6vTzu+rzPZNkkhN6bUpPpvlkeXPJjcT1R5VTDAEtojYTuOor" "bB3AzUPuTYunIHjM44Vc9N5GyixZFKYINbqMYL1RKiFnO25PePfNW29M8fomaPaE7xJC8NGX5bj" "BVr65YAUGt0WS8yU+KkvM9Dk="; c:"From: Fred Baker "; c:"Subject: Re: [v6tc] Re: Tunneling and Transition Drafts"; c:"Date: Wed, 13 Apr 2005 02:44:49 +0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Apr 12, 2005, at 10:30 PM, Tim Chown wrote: > (Hinden) Have a zillion tunnel protocols and I don't see advantage of > new generic one. I vote for limited scope. Concerned that we are > reinventing deployed solutions? (broker?) > (Durand) (hat off) Schizophrenia or IETF - requirements analysis vs > desire to be generic... ball going back and forth. Chances of > success higher if we stay focused on IPv6. My sense is that this sort of hits the point, but in fact misses it pretty widely. The issues with IPv4/IPv6 transition and coexistence boil down, I think, to the questions of rendezvous and how/when to use a tunnel vs a translation mechanism. The discussion of "do we need yet-another-GRE-format" is beside the point - we *don't* need another GRE, but we need to know how and when to use the one we have, and in that case which one to use, and when the only option is to translate (NAT-PT or whatever). The key question is how one enables two systems to talk with each other. This is trivial if we have a parallel implementation - dual stacks in both hosts and the entire network. In that case, pick one and go with it, and those systems that have not yet turned on IPv6 use IPv4. That is already a pretty strong recommendation. But it also misses something basic - the value that IPv6 brings to the party is mostly related to increasing the address pool. If that is not true, if we have enough IPv4 addresses that we can build parallel networks everywhere, then we don't need a new protocol in the first place. If it is true (and it is) then you have to assume that there will be edge networks and service networks that are IPv6-only or IPv6-dominant pretty early - pick your reason. Once you have an IPv6-only/dominant service network, you have the question of IPv4 hosts having to use it to communicate over it, IPv6-only/dominant hosts needing to communicate over IPv4-only/dominant networks, and IPv6-only hosts needing to communicate with IPv4-only hosts. At that point we have to solve a rendezvous problem. When two of one kind of host need to communicate over a network of the other kind, we obviously want to tunnel. We can do this using static tunnels, but that is a lot of manual configuration. What we really want is some kind of auto-tunneling, which means some kind of automated tunnel-endpoint location. We could do it by routing, which some proposals suggest: inject one type of routes into the other type of network using an interesting addressing scheme and make it all automagic. We could do it by naming - have what amount do DNS translators and tunnel brokers that insert the local-form-addresses of gateways into networks, and as a result both communicate to systems of one type of the address of the translator/tunnel endpoint and communicate to systems of the other type who to route a tunnel to. There are probably other approaches. But if we do this in multiple ways, we create a new layer of problems - how does a Teredo gateway talk to a Silkroad gateway talk to a DSTM gateway talk to a ...? We really need, I think, to pick *one*. and make it work well for 90+% of the cases. Note I don't say "cover every case". I'd like to, but I also wonder at what point doing so slows down getting the protocol out or slows down the transition itself. I'm perfectly happy to standardize on existing types of tunnels - IPsec, GRE, IPv4/IPv6, IPv4/IPv4, IPv6/IPv4, IPv6/IPv6, L2TP, or whatever. If we don't solve the rendezvous problem (and btw communicate to the peer what kind of tunnel a given gateway is willing to support) we have not *touched* the transition problem. And what I would like to see happen is for someone, somewhere - and note that I am very willing to do this in v6ops if people want and also willing to send it to v6tc or wherever else - to solve that rendezvous problem. As a result, I would like to see the various competing transition strategies all rendered OBE and get everyone to converge on a single transition approach. From owner-v6ops@ops.ietf.org Tue Apr 12 15:06:28 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26085 for ; Tue, 12 Apr 2005 15:06:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DLQhe-000Ky2-3d for v6ops-data@psg.com; Tue, 12 Apr 2005 19:05:38 +0000 Received: from [195.20.121.7] (helo=mail1.cluenet.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DLQha-000KxP-QL for v6ops@ops.ietf.org; Tue, 12 Apr 2005 19:05:34 +0000 Received: by mail1.cluenet.de (Postfix, from userid 500) id 705A7178B1; Tue, 12 Apr 2005 21:05:33 +0200 (CEST) Date: Tue, 12 Apr 2005 21:05:33 +0200 From: Daniel Roesen To: v6ops@ops.ietf.org Subject: New international IPv6 operators forum Message-ID: <20050412190533.GA18627@srv01.cluenet.de> Mail-Followup-To: v6ops@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi folks, as suggested by Pekka, I'm posting this announcement here too... people were missing a global mailing list (not regional RIR/NOG) dedicated to _operational_ matters of the global IPv6 (production, not 6BONE) Internet. To fill this void I've created such a mailing list: http://lists.cluenet.de/mailman/listinfo/ipv6-ops/ So if you're taking part in IPv6 BGP or are interested in global IPv6 operational matters, feel more than invited to join the list! We'll try to get IPv6 ops people from all regions on board to foster exchange of experience and resolve problems which require someone non-local coordination. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From owner-v6ops@ops.ietf.org Tue Apr 12 16:26:44 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06835 for ; Tue, 12 Apr 2005 16:26:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DLRwi-0006X8-NN for v6ops-data@psg.com; Tue, 12 Apr 2005 20:25:16 +0000 Received: from [213.136.24.43] (helo=purgatory.unfix.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DLRwf-0006Wo-2r for v6ops@ops.ietf.org; Tue, 12 Apr 2005 20:25:13 +0000 Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 1B6CC8687; Tue, 12 Apr 2005 22:25:08 +0200 (CEST) Subject: Re: [v6tc] Re: Tunneling and Transition Drafts From: Jeroen Massar To: Fred Baker Cc: v6tc@ietf.org, "'v6ops@ops.ietf.org '" In-Reply-To: <23ec6165fdb2ab7b2f3946e45caef796@cisco.com> References: <425395F8.50501@renater.fr> <4253EBCF.8030800@renater.fr> <20050412143053.GQ22380@login.ecs.soton.ac.uk> <23ec6165fdb2ab7b2f3946e45caef796@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-LnwAzdPXsS6PlxThkM3y" Organization: Unfix Date: Tue, 12 Apr 2005 22:25:03 +0200 Message-Id: <1113337503.25395.80.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=-LnwAzdPXsS6PlxThkM3y Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-04-13 at 02:44 +0800, Fred Baker wrote: > I'm perfectly happy to standardize on existing types of tunnels -=20 > IPsec, GRE, IPv4/IPv6, IPv4/IPv4, IPv6/IPv4, IPv6/IPv6, L2TP, or=20 > whatever. If we don't solve the rendezvous problem (and btw communicate=20 > to the peer what kind of tunnel a given gateway is willing to support)=20 > we have not *touched* the transition problem. L2TP seems to cover the hole quite well. Except for the fact that there is no discovery and the datastream of L2TPv2, as LTPv3 has some magic stuff to fix it, can easily be spoofed, just like proto-41. IPSec can solve this, but requires authentication and external setup again. L2TP covers imho 90% of the cases. But... if you don't have a PPP infra it will be (harder) to setup. And it doesn't allow for quick mobility like in AYIYA or proto41+heartbeat. Thus when switching IP addresses (walking to another floor with your wireless) the tunnel needs to notice (L2TP StopCCN) that it is failing and renegotiate, which takes a few secs, not more, but might give a different IP etc as it will do RA's again or DHCPv6, which might take a bit longer and most likely will break your SSH session if you like this. But we are not standardizing Mobile IP here ;) It might be, according to some that L2TP+PPP is heavy code, including definitions about 2k lines of code for a minimal implementation that works. Overhead of a L2TP tunnel including PPP is minimal. At least it won't be noticed much when you are streaming video's over your neato G3's or whatever cellphone. Btw, anonymous tunnels in L2TP can be solved by not letting the server request authentication and letting it reject auth attempts from the client. Though I have not been able to verify how many servers support this. TSP or a similar protocol is IMHO a must, because L2TP simply can't be deployed everywhere and better, not everybody wants it: Market::Decide() TSP is handy in all cases, it can also have a template pointing to a L2TP server etc. Next to that there is a client available for all platforms. As for the point made in the minutes that there is only one implementation, AICCU will support TSP too as an option in the near future. > And what I would like to see happen is for someone, somewhere - and=20 > note that I am very willing to do this in v6ops if people want and also=20 > willing to send it to v6tc or wherever else - to solve that rendezvous=20 > problem. As a result, I would like to see the various competing=20 > transition strategies all rendered OBE and get everyone to converge on=20 > a single transition approach. I've finally submitted my "_service" draft to the secretariat, it should appear shortly in dnsop. I'll forward it to v6ops + v6tc when it is there. In "short": Anycast prefix 1.2.3.0/24, on which on 1.2.3.53 there is a DNS server listening. This is a (caching) recursive server which can be used for looking up anything (www.google.com www.ietf.org etc). It is also authoritive for the "_service." domain, in which we stick SRV records. Usually _service is a DNAME to _service.example.net. Which fulfills the searchpath, if the user does not have this special DNS server configured, but does have it's ISP's domain in the searchpath, then the resolver will come to _service.example.net because of the searchpath. Thus, client gets turned on, it gets connectivity, it needs to lookup something, resolver is default configured to 1.2.3.53, resolving thus works. The prefix is anycasted by it's or another ISP, who can filter on wish etc. If user needs a service, eg SMTP, it resolves the SMTP SRV records, which can specify load balancing and other stuff. Same for POP3, IMAP, or lookup eg help.www._service which returns a TXT record to the URL of the servicedesk of the ISP you are using. For the v6ops/v6tc case a client can first try l2tp.ipv6._service if that exists, use it, then try tsp.ipv6._service, if that exists, use that one. Discovery solved in the most generic way. It does indeed take a couple of resolves, but hey people want it automatically. As for the ones screaming "but I don't want a default thing" then configure the client you are using for doing this. Of course a similar prefix for IPv6 so that this also solves dns configuration. Another good thing is that, assuming you have connectivity you will always have the closest dns server, also ISP's can then nicely block all the RFC1918 registrations in those, but that is most likely just a good hope from me, most don't even filter... Greets, Jeroen --=-LnwAzdPXsS6PlxThkM3y Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBCXC6fKaooUjM+fCMRAlB0AKCZp3HAlVnHsxo08hihz3xNKppSiACfYdUK C1LjqBDiT42H5j0mKxKByjY= =W+nC -----END PGP SIGNATURE----- --=-LnwAzdPXsS6PlxThkM3y-- From owner-v6ops@ops.ietf.org Tue Apr 12 16:37:28 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08156 for ; Tue, 12 Apr 2005 16:37:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DLS80-0007lM-9c for v6ops-data@psg.com; Tue, 12 Apr 2005 20:36:56 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DLS7z-0007l8-22 for v6ops@ops.ietf.org; Tue, 12 Apr 2005 20:36:55 +0000 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 12 Apr 2005 13:36:54 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j3CKap05017665; Tue, 12 Apr 2005 13:36:52 -0700 (PDT) Received: from [210.72.28.195] (tky-vpn-client-230-23.cisco.com [10.70.230.23]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j3CKSJTN031231; Tue, 12 Apr 2005 13:28:20 -0700 In-Reply-To: <1113337503.25395.80.camel@firenze.zurich.ibm.com> References: <425395F8.50501@renater.fr> <4253EBCF.8030800@renater.fr> <20050412143053.GQ22380@login.ecs.soton.ac.uk> <23ec6165fdb2ab7b2f3946e45caef796@cisco.com> <1113337503.25395.80.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-10--260463903" Message-Id: <0df7389c7b1b0e371b1693d86bda2fef@cisco.com> Content-Transfer-Encoding: 7bit Cc: v6tc@ietf.org, "'v6ops@ops.ietf.org '" From: Fred Baker Subject: Re: [v6tc] Re: Tunneling and Transition Drafts Date: Wed, 13 Apr 2005 04:36:45 +0800 To: Jeroen Massar X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1113337701.984318"; x:"432200"; a:"rsa-sha1"; b:"nofws:4464"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"CFd3Nyp0+q2B+QH2UOJj8o46gHUE2bDekvdPI4NenUjKnjbeBtbghQQO56CQPuVbWGWJz1SJ" "+iOkrkWnoOmDWBfutiSf1ON5q+M1iGZuUW3DFweeon3HGcVBZEHE3DQgWSciTAJDmc/eXEm8tOS" "PJY4++QcPsNbgJrvdR0tkrZA="; c:"From: Fred Baker "; c:"Subject: Re: [v6tc] Re: Tunneling and Transition Drafts"; c:"Date: Wed, 13 Apr 2005 04:36:45 +0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --Apple-Mail-10--260463903 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Realistically, I think all of the various tunneling technologies will in fact be used. The important question is the rendezvous problem. On Apr 13, 2005, at 4:25 AM, Jeroen Massar wrote: > On Wed, 2005-04-13 at 02:44 +0800, Fred Baker wrote: > >> I'm perfectly happy to standardize on existing types of tunnels - >> IPsec, GRE, IPv4/IPv6, IPv4/IPv4, IPv6/IPv4, IPv6/IPv6, L2TP, or >> whatever. If we don't solve the rendezvous problem (and btw >> communicate to the peer what kind of tunnel a given gateway is >> willing to support) we have not *touched* the transition problem. > > L2TP seems to cover the hole quite well. Except for the fact that > there is no discovery and the datastream of L2TPv2, as LTPv3 has some > magic stuff to fix it, can easily be spoofed, just like proto-41. > IPSec can solve this, but requires authentication and external setup > again. > > L2TP covers imho 90% of the cases. But... if you don't have a PPP > infra it will be (harder) to setup. And it doesn't allow for quick > mobility like in AYIYA or proto41+heartbeat. Thus when switching IP > addresses (walking to another floor with your wireless) the tunnel > needs to notice (L2TP StopCCN) that it is failing and renegotiate, > which takes a few secs, not more, but might give a different IP etc as > it will do RA's again or DHCPv6, which might take a bit longer and > most likely will break your SSH session if you like this. But we are > not standardizing Mobile IP here ;) > > It might be, according to some that L2TP+PPP is heavy code, including > definitions about 2k lines of code for a minimal implementation that > works. Overhead of a L2TP tunnel including PPP is minimal. At least it > won't be noticed much when you are streaming video's over your neato > G3's or whatever cellphone. > > Btw, anonymous tunnels in L2TP can be solved by not letting the server > request authentication and letting it reject auth attempts from the > client. Though I have not been able to verify how many servers support > this. > > TSP or a similar protocol is IMHO a must, because L2TP simply can't be > deployed everywhere and better, not everybody wants it: > Market::Decide() TSP is handy in all cases, it can also have a > template pointing to a L2TP server etc. Next to that there is a client > available for all platforms. > > As for the point made in the minutes that there is only one > implementation, AICCU will support TSP too as an option in the near > future. > >> And what I would like to see happen is for someone, somewhere - and >> note that I am very willing to do this in v6ops if people want and >> also willing to send it to v6tc or wherever else - to solve that >> rendezvous problem. As a result, I would like to see the various >> competing transition strategies all rendered OBE and get everyone to >> converge on a single transition approach. > > I've finally submitted my "_service" draft to the secretariat, it > should appear shortly in dnsop. I'll forward it to v6ops + v6tc when > it is there. > > In "short": > > Anycast prefix 1.2.3.0/24, on which on 1.2.3.53 there is a DNS server > listening. This is a (caching) recursive server which can be used for > looking up anything (www.google.com www.ietf.org etc). It is also > authoritive for the "_service." domain, in which we stick SRV records. > Usually _service is a DNAME to _service.example.net. Which fulfills > the searchpath, if the user does not have this special DNS server > configured, but does have it's ISP's domain in the searchpath, then > the resolver will come to _service.example.net because of the > searchpath. > > Thus, client gets turned on, it gets connectivity, it needs to lookup > something, resolver is default configured to 1.2.3.53, resolving thus > works. The prefix is anycasted by it's or another ISP, who can filter > on wish etc. If user needs a service, eg SMTP, it resolves the SMTP > SRV records, which can specify load balancing and other stuff. Same > for POP3, IMAP, or lookup eg help.www._service which returns a TXT > record to the URL of the servicedesk of the ISP you are using. > > For the v6ops/v6tc case a client can first try l2tp.ipv6._service if > that exists, use it, then try tsp.ipv6._service, if that exists, use > that one. Discovery solved in the most generic way. It does indeed > take a couple of resolves, but hey people want it automatically. As > for the ones screaming "but I don't want a default thing" then > configure the client you are using for doing this. > > Of course a similar prefix for IPv6 so that this also solves dns > configuration. Another good thing is that, assuming you have > connectivity you will always have the closest dns server, also ISP's > can then nicely block all the RFC1918 registrations in those, but that > is most likely just a good hope from me, most don't even filter... > > Greets, > Jeroen > --Apple-Mail-10--260463903 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCXDFdbjEdbHIsm0MRAtPgAKD1rizcQhQMK+q6I5euM62CXpdVQwCgsvGg bSENMyTVeCZbQvM5pzwa+Fo= =thwz -----END PGP SIGNATURE----- --Apple-Mail-10--260463903-- From owner-v6ops@ops.ietf.org Tue Apr 12 16:40:56 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08603 for ; Tue, 12 Apr 2005 16:40:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DLSBe-00089Y-QM for v6ops-data@psg.com; Tue, 12 Apr 2005 20:40:42 +0000 Received: from [213.136.24.43] (helo=purgatory.unfix.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DLSBd-00088y-Uf for v6ops@ops.ietf.org; Tue, 12 Apr 2005 20:40:42 +0000 Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 538648687; Tue, 12 Apr 2005 22:40:37 +0200 (CEST) Subject: Re: [v6tc] Re: Tunneling and Transition Drafts From: Jeroen Massar To: Fred Baker Cc: v6tc@ietf.org, "'v6ops@ops.ietf.org '" In-Reply-To: <0df7389c7b1b0e371b1693d86bda2fef@cisco.com> References: <425395F8.50501@renater.fr> <4253EBCF.8030800@renater.fr> <20050412143053.GQ22380@login.ecs.soton.ac.uk> <23ec6165fdb2ab7b2f3946e45caef796@cisco.com> <1113337503.25395.80.camel@firenze.zurich.ibm.com> <0df7389c7b1b0e371b1693d86bda2fef@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-YRIarwF9YNMnd9ZvKZQ3" Organization: Unfix Date: Tue, 12 Apr 2005 22:40:35 +0200 Message-Id: <1113338435.25395.83.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=-YRIarwF9YNMnd9ZvKZQ3 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-04-13 at 04:36 +0800, Fred Baker wrote: > Realistically, I think all of the various tunneling technologies will=20 > in fact be used. The important question is the rendezvous problem. Full ack. Which is why I decided to stick most of them into AICCU ;) Has a BSD-alike license so vendors can abuse it if they want to. Greets, Jeroen --=-YRIarwF9YNMnd9ZvKZQ3 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBCXDJDKaooUjM+fCMRAsrSAJ99H/atdgKeiiVX/K5q+ArVv5KPFwCfSkRN Ixy8lW0kioKAtvnLlPK9oM4= =0TLj -----END PGP SIGNATURE----- --=-YRIarwF9YNMnd9ZvKZQ3-- From owner-v6ops@ops.ietf.org Tue Apr 12 18:41:57 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20277 for ; Tue, 12 Apr 2005 18:41:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DLU34-000OPR-6C for v6ops-data@psg.com; Tue, 12 Apr 2005 22:39:58 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DLU33-000OPE-4V for v6ops@ops.ietf.org; Tue, 12 Apr 2005 22:39:57 +0000 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 12 Apr 2005 18:49:36 -0400 X-IronPort-AV: i="3.92,97,1112587200"; d="scan'208,217"; a="44297254:sNHT53146932" Received: from adahmed-w2k07.cisco.com ([64.101.172.254]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j3CMdreY017856; Tue, 12 Apr 2005 18:39:54 -0400 (EDT) Message-Id: <4.3.2.7.2.20050412172828.02240420@cactus> X-Sender: adahmed@cactus X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Apr 2005 17:39:53 -0500 To: Alain Durand From: Adeel Ahmed Subject: Re: comment on draft-ietf-v6ops-bb-deployment-scenarios-01.txt on the cabe modem section Cc: v6ops@ops.ietf.org, ciprian Popoviciu In-Reply-To: <42571A92.9000601@tycool.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_723489843==_.ALT" X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [64.101.172.254] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_10_20, HTML_MESSAGE autolearn=no version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=====================_723489843==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hello Alain, Thank you for reviewing our draft and providing feedback. Please see my responses inline with @@@@@: At 04:58 PM 4/8/2005 -0700, Alain Durand wrote: >I have some comments on the cable modem scenario. > >- the various sub-scenarios have a lot in common. The way there are >described in full one by one makes >that there is a lot of redundant text. Grouping commonalities in one >section and ten, for each sub-case, >describing what is different would make the document easier to read. @@@@@ This issue has been discussed in the past and per agreement from the WG we would like to keep the format of the different sections as is. @@@@@ >- There is something not obvious on why IGMPv3/MLDv2 is needed. > the CM amd CMTS are L2 bridges, so they could just forward any > multicast traffic. > This is especially true for the CM, which has only 2 interfaces. I > reckon it may be > different for the CMTS is one wants to make sure multicast traffic for > one customer > does not accidentally flows to another. In any case, I'd like to see > some more > text why MLD is needed. Actually the current text is a bit ambiquous, > it some > places it says that MLD is mandatory, in other it just says that the > absence of MLD "could" > break ND... @@@@@ We will add more text to explain why IGMPv3/MLDv2 or v1 snooping is needed on the CM. Basically the DOCSIS specification mandates use of IGMPv2 snooping on the CM in order to track join/leave messages from hosts connected to its LAN interface. The CM is not allowed to pass any multicast traffic from its cable interface to the LAN interface unless there is a host on its LAN interface which is part of that multicast group. This breaks IPv6 ND in cable networks. For IPv6 the CM will need to support IGMPv3/MLDv2 or v1 snooping for ND to work. @@@@@ >- If a cable operator decides to roll out v6 for management purpose, then >all the scenarios > about using tunnels are moot, unless the home GWR does not support v6. @@@@@ The native IPv6 solution is valid as long as the cable operator wants to manage only the CM. The CM management traffic does not face the DOCSIS limitations regarding IPv6. The native solution is not feasible in managing IPv6 devices behind the CM. This later case, as discussed in the cable case studies, is not possible today with native IPv6 deployment and can be implemented only with the help of tunnels. @@@@@ >- If v6 multicast is important, support for MLD proxy or PIM-SM is critical > in the GWR. If it is not there, is there a work around? @@@@@ It is recognized that the GWR is a device with limited resources and it supports a limited set of features. For this reason two options were offered for it in order to support a multicast service: PIM-SM or MLD Proxy. If neither is supported by the GWR then the user interested in the multicast service has two options: 1. Change the GWR to one that supports one of the two features, 2. Remove the GWR and use an appliance (behind the CM) to handle the control aspects of the multicast service. @@@@@ Kind Regards, Adeel. > - Alain. --=====================_723489843==_.ALT Content-Type: text/html; charset="us-ascii" Hello Alain,

Thank you for reviewing our draft and providing feedback. Please see my responses inline with @@@@@:

At 04:58 PM 4/8/2005 -0700, Alain Durand wrote:
I have some comments on the cable modem scenario.

- the various sub-scenarios have a lot in common. The way there are described in full one by one makes
that there is a lot of redundant text. Grouping commonalities in one section and ten, for each sub-case,
describing what is different would make the document easier to read.

@@@@@
This issue has been discussed in the past and per agreement from the WG we would like to keep the format of the different sections as is.
@@@@@


- There is something not obvious on why IGMPv3/MLDv2 is needed.
  the CM amd CMTS are L2 bridges, so they could just forward any multicast traffic.
  This is especially true for the CM, which has only 2 interfaces. I reckon it may be
   different for the CMTS is one wants to make sure multicast traffic for one customer
   does not accidentally flows to another. In any case, I'd like to see some more
   text why MLD is needed. Actually the current text is a bit ambiquous, it some
   places it says that MLD is mandatory, in other it just says that the absence of MLD "could"
   break ND...

@@@@@
We will add more text to explain why IGMPv3/MLDv2 or v1 snooping is needed on the CM. Basically the DOCSIS specification mandates use of IGMPv2 snooping on the CM in order to track join/leave messages from hosts connected to its LAN interface. The CM is not allowed to pass any multicast traffic from its cable interface to the LAN interface unless there is  a host on its LAN interface which is part of that multicast group. This breaks IPv6 ND in cable networks. For IPv6 the CM will need to support IGMPv3/MLDv2 or v1 snooping for ND to work.
@@@@@


- If a cable operator decides to roll out v6 for management purpose, then all the scenarios
 about using tunnels are moot, unless the home GWR does not support v6.

@@@@@
The native IPv6 solution is valid as long as the cable operator wants to manage only the CM. The CM management traffic does not face the DOCSIS limitations regarding IPv6. The native solution is not feasible in managing IPv6 devices behind the CM. This later case, as discussed in the cable case studies, is not possible today with native IPv6 deployment and can be implemented only with the help of tunnels. 
@@@@@

- If v6 multicast is important, support for MLD proxy or PIM-SM is critical
 in the GWR. If it is not there, is there a work around?

@@@@@
It is recognized that the GWR is a device with limited resources and it supports a limited set of features. For this reason two options were offered for it in order to support a multicast service: PIM-SM or MLD Proxy. If neither is supported by the GWR then the user interested in the multicast service has two options: 1. Change the GWR to one that supports one of the two features, 2. Remove the GWR and use an appliance (behind the CM)  to handle the control aspects of the multicast service.
@@@@@

Kind Regards,
Adeel.


   - Alain.
--=====================_723489843==_.ALT-- From owner-v6ops@ops.ietf.org Tue Apr 12 19:58:17 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26737 for ; Tue, 12 Apr 2005 19:58:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DLVF9-0007x5-B4 for v6ops-data@psg.com; Tue, 12 Apr 2005 23:56:31 +0000 Received: from [66.93.39.75] (helo=smtp-e.tycool.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DLVF8-0007wr-IA for v6ops@ops.ietf.org; Tue, 12 Apr 2005 23:56:30 +0000 Received: from [192.168.1.2] (unknown [192.168.1.2]) by smtp-e.tycool.net (Postfix) with ESMTP id 758C5D; Tue, 12 Apr 2005 16:56:50 -0700 (PDT) In-Reply-To: <4.3.2.7.2.20050412172828.02240420@cactus> References: <4.3.2.7.2.20050412172828.02240420@cactus> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5e87d69f6b31f094d6e9f8566a2ca8af@tycool.net> Content-Transfer-Encoding: 7bit Cc: ciprian Popoviciu , v6ops@ops.ietf.org From: Alain Durand Subject: Re: comment on draft-ietf-v6ops-bb-deployment-scenarios-01.txt on the cabe modem section Date: Tue, 12 Apr 2005 16:56:25 -0700 To: Adeel Ahmed X-Mailer: Apple Mail (2.619.2) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Apr 12, 2005, at 3:39 PM, Adeel Ahmed wrote: > Hello Alain, > > Thank you for reviewing our draft and providing feedback. Please see > my responses inline with @@@@@: > > At 04:58 PM 4/8/2005 -0700, Alain Durand wrote: > > I have some comments on the cable modem scenario. > > - the various sub-scenarios have a lot in common. The way there are > described in full one by one makes > that there is a lot of redundant text. Grouping commonalities in one > section and ten, for each sub-case, > describing what is different would make the document easier to read. > > @@@@@ > This issue has been discussed in the past and per agreement from the > WG we would like to keep the format of the different sections as is. > @@@@@ I understand that you'd like to keep the different sections as independent ones. My comment is targeted at the cable section itself and its sub-sections. I will strongly encourage you and the wg to revisit your position as this particular section is real hard to read as it is now. - Alain. From owner-v6ops@ops.ietf.org Wed Apr 13 01:28:12 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19846 for ; Wed, 13 Apr 2005 01:28:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DLaO6-000JNT-Uz for v6ops-data@psg.com; Wed, 13 Apr 2005 05:26:06 +0000 Received: from [131.228.20.22] (helo=mgw-x2.nokia.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.44 (FreeBSD)) id 1DLaO3-000JMp-Qw for v6ops@ops.ietf.org; Wed, 13 Apr 2005 05:26:04 +0000 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j3D5PxO07487; Wed, 13 Apr 2005 08:26:00 +0300 (EET DST) X-Scanned: Wed, 13 Apr 2005 08:25:50 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j3D5PoVq016645; Wed, 13 Apr 2005 08:25:50 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00vev5XJ; Wed, 13 Apr 2005 08:25:49 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j3D5PnU16745; Wed, 13 Apr 2005 08:25:49 +0300 (EET DST) Received: from dadhcp-172019068136.americas.nokia.com ([10.241.59.73]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 13 Apr 2005 08:25:46 +0300 Received: from dadhcp-172019068136.americas.nokia.com (localhost.localdomain [127.0.0.1]) by dadhcp-172019068136.americas.nokia.com (8.12.11/8.12.11) with ESMTP id j3D5PgBS005817; Tue, 12 Apr 2005 22:25:42 -0700 Received: (from david@localhost) by dadhcp-172019068136.americas.nokia.com (8.12.11/8.12.11/Submit) id j3D5PT73005816; Tue, 12 Apr 2005 22:25:29 -0700 Date: Tue, 12 Apr 2005 22:25:27 -0700 From: David Kessens To: Alain Durand Cc: Lindqvist Erik Kurt , sebastien roy , Jim Paugh , Fred Baker , v6ops@ops.ietf.org Subject: Re: [Fwd: draft-ietf-v6ops-onlinkassumption and draft-ietf-v6ops-v6onbydefault] Message-ID: <20050413052527.GB5417@nokia.com> References: <42522B33.7010005@Sun.COM> <0af6ef342cbf8a44b60c1a5ab81b7cb8@tycool.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-OriginalArrivalTime: 13 Apr 2005 05:25:47.0551 (UTC) FILETIME=[3F8492F0:01C53FE9] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Alain, On Fri, Apr 08, 2005 at 04:53:52PM -0700, Alain Durand wrote: > > "[david] The working group has to decide whether this document really needs to > published. > In any case it needs more work by the working group before it can be > published." > > I can understand the first part, but not the second. Could the AD or the chairs clarify > what further work is necessary? The revision should be focussed on making it more clear that this is document contains background/historic information on why this change was made. It basically needs adaptation to the new current situation. For example, it has a section 'Proposal for change' while we are not talking about a proposal anymore. I understand that documenting this kind of things are very nice to have. However, I could also imagine that you (and the working group) rather spend time on more pressing technical issues that are still in actual need of resolution. As documented in the tracker, this decision needs to be made by the working group, not by me. I hope this helps, David Kessens --- From owner-v6ops@ops.ietf.org Wed Apr 13 05:04:34 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07423 for ; Wed, 13 Apr 2005 05:04:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DLdlI-0007FA-4Z for v6ops-data@psg.com; Wed, 13 Apr 2005 09:02:16 +0000 Received: from [145.100.24.109] (helo=rvdp.sara.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DLdlE-0007Dr-N5 for v6ops@ops.ietf.org; Wed, 13 Apr 2005 09:02:13 +0000 Received: from rvdp.sara.nl (localhost [127.0.0.1]) by rvdp.sara.nl (8.13.3/8.12.11) with ESMTP id j3D91XdT016969; Wed, 13 Apr 2005 11:01:33 +0200 (CEST) Received: (from rvdp@localhost) by rvdp.sara.nl (8.13.3/8.12.11/Submit) id j3D91WCx007835; Wed, 13 Apr 2005 11:01:32 +0200 (CEST) Date: Wed, 13 Apr 2005 11:01:32 +0200 From: Ronald.vanderPol@rvdp.org To: Fred Baker Cc: v6tc@ietf.org, "'v6ops@ops.ietf.org '" Subject: Re: [v6tc] Re: Tunneling and Transition Drafts Message-ID: <20050413090132.GD28016@sara.nl> References: <425395F8.50501@renater.fr> <4253EBCF.8030800@renater.fr> <20050412143053.GQ22380@login.ecs.soton.ac.uk> <23ec6165fdb2ab7b2f3946e45caef796@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23ec6165fdb2ab7b2f3946e45caef796@cisco.com> User-Agent: Mutt/1.4.2.1i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Apr 13, 2005 at 02:44:49 +0800, Fred Baker wrote: > The key question is how one enables two systems to talk with each > other. This is trivial if we have a parallel implementation - dual > stacks in both hosts and the entire network. In that case, pick one and > go with it, and those systems that have not yet turned on IPv6 use > IPv4. That is already a pretty strong recommendation. Right. > But it also misses something basic - the value that IPv6 brings to the > party is mostly related to increasing the address pool. If that is not > true, if we have enough IPv4 addresses that we can build parallel > networks everywhere, then we don't need a new protocol in the first > place. If it is true (and it is) then you have to assume that there > will be edge networks and service networks that are IPv6-only or > IPv6-dominant pretty early - pick your reason. Once you have an > IPv6-only/dominant service network, you have the question of IPv4 hosts > having to use it to communicate over it, IPv6-only/dominant hosts > needing to communicate over IPv4-only/dominant networks, and IPv6-only > hosts needing to communicate with IPv4-only hosts. You seem to assume also that upgrading the IPv4-only network to dual stack is not an option. > At that point we have to solve a rendezvous problem. When two of one > kind of host need to communicate over a network of the other kind, we > obviously want to tunnel. The 6bone ended up in a useless tunnel mess. Keep it simple has always turned out to be the best approach. I think a dual-stack network is easier to manage than a tunneled network. When users on an IPv4-only network want to use IPv6-only services, they should convince the network managers to upgrade to dual-stack. Otherwise, the tunnel mess will stay forever, because there is no incentive to upgrade to dual-stack. Isn't the main reason for tunneling the fact that too few networks are deploying IPv6? Trying to force IPv6 deployment by creating complicated tunnel overlays seems to me like wrong engineering. rvdp From owner-v6ops@ops.ietf.org Wed Apr 13 05:32:43 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09127 for ; Wed, 13 Apr 2005 05:32:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DLeDP-000Ccr-MZ for v6ops-data@psg.com; Wed, 13 Apr 2005 09:31:19 +0000 Received: from [213.136.24.43] (helo=purgatory.unfix.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DLeDM-000Cc4-CG for v6ops@ops.ietf.org; Wed, 13 Apr 2005 09:31:16 +0000 Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 2224A897B; Wed, 13 Apr 2005 11:31:11 +0200 (CEST) Subject: Re: [v6tc] Re: Tunneling and Transition Drafts From: Jeroen Massar To: Ronald.vanderPol@rvdp.org Cc: v6tc@ietf.org, "'v6ops@ops.ietf.org '" In-Reply-To: <20050413090132.GD28016@sara.nl> References: <425395F8.50501@renater.fr> <4253EBCF.8030800@renater.fr> <20050412143053.GQ22380@login.ecs.soton.ac.uk> <23ec6165fdb2ab7b2f3946e45caef796@cisco.com> <20050413090132.GD28016@sara.nl> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-DIXyZ/AbBfHrirQfpy9M" Organization: Unfix Date: Wed, 13 Apr 2005 11:31:09 +0200 Message-Id: <1113384669.3801.32.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=-DIXyZ/AbBfHrirQfpy9M Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-04-13 at 11:01 +0200, Ronald.vanderPol@rvdp.org wrote: > On Wed, Apr 13, 2005 at 02:44:49 +0800, Fred Baker wrote: > > At that point we have to solve a rendezvous problem. When two of one=20 > > kind of host need to communicate over a network of the other kind, we=20 > > obviously want to tunnel. >=20 > The 6bone ended up in a useless tunnel mess. Keep it simple has always > turned out to be the best approach. I think a dual-stack network is > easier to manage than a tunneled network. When users on an IPv4-only > network want to use IPv6-only services, they should convince the network > managers to upgrade to dual-stack. Otherwise, the tunnel mess will stay > forever, because there is no incentive to upgrade to dual-stack. Of course dual-stack is the way to go, but the biggest reason that people do not upgrade to dual-stack is the lack of support in their hardware. If they where able to dual-stack stuff, they would not even bother with tunneling. Also we are talking about tunneling inside the same AS here, not like the 6bone globally. A packet over a tunnel will thus have 90% the same path it would take when being native. See my traceroutes below, I'll post the diffs to the native path when it becomes native as my ISP indeed moved to their own ATM trunk and now can provide it natively, before they couldn't as the technology didn't allow for it. > Isn't the main reason for tunneling the fact that too few networks are > deploying IPv6? Trying to force IPv6 deployment by creating complicated > tunnel overlays seems to me like wrong engineering. No, the main reason seems to be support and stability. Also, they don't earn money selling IPv6 thus they are not allowed politically to deploy it. Greets, Jeroen -- IPv4: jeroen@purgatory:~$ traceroute www.bit.nl traceroute to http-unix.bip.bit.nl (213.136.12.232), 64 hops max, 40 byte packets 1 213-136-24-1.adsl.bit.nl (213.136.24.1) 12 ms 11 ms 11 ms 2 i49.ge-0-1-0.jun1.kelvin.network.bit.nl (213.136.31.33) 11 ms 22 ms 11 ms 3 http.lb.network.bit.nl (213.136.12.232) 12 ms 11 ms 11 ms IPv6: jeroen@purgatory:~$ traceroute6 www.bit.nl traceroute to http-unix.bip.bit.nl (2001:7b8:3:5::80:1) from 2001:7b8:300:0:290:27ff:fe24:c19f, 30 hops max, 16 byte packets 1 gw-1.ede-01.nl.sixxs.net (2001:7b8:2ff::1) 16.866 ms 13.277 ms 13.863 ms 2 sixxs-gw.ipv6.network.bit.nl (2001:7b8:3:4f:290:6900:4fc6:d81f) 13.697 ms 13.612 ms 19.932 ms 3 2001:7b8:3:5::80:1 (2001:7b8:3:5::80:1) 12.444 ms 19.834 ms 13.277 ms And just in case one is wondering, the tunnel box is found over this path: jeroen@purgatory:~$ traceroute nlede01.sixxs.net traceroute to nlede01.sixxs.net (193.109.122.244), 64 hops max, 40 byte packets 1 213-136-24-1.adsl.bit.nl (213.136.24.1) 12 ms 11 ms 11 ms 2 i49.ge-0-1-0.jun1.kelvin.network.bit.nl (213.136.31.33) 11 ms 11 ms 11 ms 3 nlede01.sixxs.net (193.109.122.244) 13 ms 11 ms 10 ms Which explains the 1ms difference in latency ;) --=-DIXyZ/AbBfHrirQfpy9M Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBCXObdKaooUjM+fCMRAleKAJ9EAXkzVMtm19dyTuJb/bYCbbi5IQCeN/Dp 3OpV8/hza4X6/4GpUbi6Ok4= =s13A -----END PGP SIGNATURE----- --=-DIXyZ/AbBfHrirQfpy9M-- From owner-v6ops@ops.ietf.org Wed Apr 13 05:45:14 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09876 for ; Wed, 13 Apr 2005 05:45:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DLeQI-000FhW-OR for v6ops-data@psg.com; Wed, 13 Apr 2005 09:44:38 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DLeQH-000Fh2-Fa for v6ops@ops.ietf.org; Wed, 13 Apr 2005 09:44:37 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j3D9iTi3000413; Wed, 13 Apr 2005 10:44:29 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA16726; Wed, 13 Apr 2005 10:44:28 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j3D9iSd27831; Wed, 13 Apr 2005 10:44:28 +0100 Date: Wed, 13 Apr 2005 10:44:28 +0100 From: Tim Chown To: v6tc@ietf.org, "'v6ops@ops.ietf.org '" Subject: Re: [v6tc] Re: Tunneling and Transition Drafts Message-ID: <20050413094428.GE26674@login.ecs.soton.ac.uk> Mail-Followup-To: v6tc@ietf.org, "'v6ops@ops.ietf.org '" References: <425395F8.50501@renater.fr> <4253EBCF.8030800@renater.fr> <20050412143053.GQ22380@login.ecs.soton.ac.uk> <23ec6165fdb2ab7b2f3946e45caef796@cisco.com> <20050413090132.GD28016@sara.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050413090132.GD28016@sara.nl> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Apr 13, 2005 at 11:01:32AM +0200, Ronald.vanderPol@rvdp.org wrote: > > > But it also misses something basic - the value that IPv6 brings to the > > party is mostly related to increasing the address pool. If that is not > > true, if we have enough IPv4 addresses that we can build parallel > > networks everywhere, then we don't need a new protocol in the first > > place. If it is true (and it is) then you have to assume that there > > will be edge networks and service networks that are IPv6-only or > > IPv6-dominant pretty early - pick your reason. Once you have an > > IPv6-only/dominant service network, you have the question of IPv4 hosts > > having to use it to communicate over it, IPv6-only/dominant hosts > > needing to communicate over IPv4-only/dominant networks, and IPv6-only > > hosts needing to communicate with IPv4-only hosts. > > You seem to assume also that upgrading the IPv4-only network to dual > stack is not an option. Between networks the "enough IPv4 addresses that we can build parallel networks everywhere" argument works, for the ISP systems. In end user or customer systems, I would expect we'll see a lot of dual stack that is IPv4+NAT alongside global IPv6. From the ISP perspective what they might see now is a handul of users achieving that by using a tunnel broker (probably not one run by the ISP itself) and the challenge is offering (native, dual-stack) IPv6 from the ISP infrastructure directly. -- Tim/::1 From owner-v6ops@ops.ietf.org Wed Apr 13 05:54:16 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10702 for ; Wed, 13 Apr 2005 05:54:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DLeYN-000He3-3G for v6ops-data@psg.com; Wed, 13 Apr 2005 09:52:59 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DLeYL-000HdQ-6H for v6ops@ops.ietf.org; Wed, 13 Apr 2005 09:52:57 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 13 Apr 2005 02:52:57 -0700 X-IronPort-AV: i="3.92,97,1112598000"; d="scan'208"; a="628392404:sNHT30954752" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j3D9qsJd007859; Wed, 13 Apr 2005 02:52:54 -0700 (PDT) Received: from [61.48.216.25] (sjc-vpn2-135.cisco.com [10.21.112.135]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j3D9iKKe003668; Wed, 13 Apr 2005 02:44:21 -0700 In-Reply-To: <20050413090132.GD28016@sara.nl> References: <425395F8.50501@renater.fr> <4253EBCF.8030800@renater.fr> <20050412143053.GQ22380@login.ecs.soton.ac.uk> <23ec6165fdb2ab7b2f3946e45caef796@cisco.com> <20050413090132.GD28016@sara.nl> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: v6tc@ietf.org, "'v6ops@ops.ietf.org '" From: Fred Baker Subject: Re: [v6tc] Re: Tunneling and Transition Drafts Date: Wed, 13 Apr 2005 17:52:51 +0800 To: Ronald.vanderPol@rvdp.org X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1113385462.661561"; x:"432200"; a:"rsa-sha1"; b:"nofws:1498"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"MU4j9m9NQar4m5gbvflNJrpMhtHd9pp6Ah1y/RAl73DSAilabVvEk8wxXqGF7Nw3OIM46zSg" "sjs8UKDX6jUs/90urGu2Hmc18VuHkzdttg/WiupEodClqAUdtegrVt4vnvkU4I7jpU/qcdGvuhC" "iwzOKh3ZoruB9Bj/aDsNmGr4="; c:"From: Fred Baker "; c:"Subject: Re: [v6tc] Re: Tunneling and Transition Drafts"; c:"Date: Wed, 13 Apr 2005 17:52:51 +0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Apr 13, 2005, at 5:01 PM, Ronald.vanderPol@rvdp.org wrote: >> But it also misses something basic - the value that IPv6 brings to >> the party is mostly related to increasing the address pool. If that >> is not true, if we have enough IPv4 addresses that we can build >> parallel networks everywhere, then we don't need a new protocol in >> the first place. If it is true (and it is) then you have to assume >> that there will be edge networks and service networks that are >> IPv6-only or IPv6-dominant pretty early - pick your reason. Once you >> have an IPv6-only/dominant service network, you have the question of >> IPv4 hosts having to use it to communicate over it, >> IPv6-only/dominant hosts needing to communicate over >> IPv4-only/dominant networks, and IPv6-only hosts needing to >> communicate with IPv4-only hosts. > > You seem to assume also that upgrading the IPv4-only network to dual > stack is not an option. No. I presume that it is optional, and I know of a number of networks that as we speak are deploying in a form that Jim Bound at the March meeting described as "ipv6-only"or "ipv6-dominant". IPv6-only is what it sounds like; IPv6-dominant is the case where a network deploys dual stacked but offers no IPv4 service to its customers. > Isn't the main reason for tunneling the fact that too few networks are > deploying IPv6? Trying to force IPv6 deployment by creating > complicated tunnel overlays seems to me like wrong engineering. In the discussion I had with a university network this afternoon, it was to connect the IPv4 islands over the central IPv6 infrastructure. Yes, we had that discussion too, and continue to have it. But I have never particularly noticed that the fact that I thought my customer was doing something unnecessarily self-limiting ever made much of a dent. From owner-v6ops@ops.ietf.org Wed Apr 13 06:20:36 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12028 for ; Wed, 13 Apr 2005 06:20:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DLexe-000O4d-Lk for v6ops-data@psg.com; Wed, 13 Apr 2005 10:19:06 +0000 Received: from [145.100.24.109] (helo=rvdp.sara.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DLexb-000O3u-ML for v6ops@ops.ietf.org; Wed, 13 Apr 2005 10:19:03 +0000 Received: from rvdp.sara.nl (localhost [127.0.0.1]) by rvdp.sara.nl (8.13.3/8.12.11) with ESMTP id j3DAIUl4009133; Wed, 13 Apr 2005 12:18:30 +0200 (CEST) Received: (from rvdp@localhost) by rvdp.sara.nl (8.13.3/8.12.11/Submit) id j3DAIUlg027262; Wed, 13 Apr 2005 12:18:30 +0200 (CEST) Date: Wed, 13 Apr 2005 12:18:29 +0200 From: Ronald.vanderPol@rvdp.org To: v6tc@ietf.org, "'v6ops@ops.ietf.org '" Subject: Re: [v6tc] Re: Tunneling and Transition Drafts Message-ID: <20050413101829.GE28016@sara.nl> References: <425395F8.50501@renater.fr> <4253EBCF.8030800@renater.fr> <20050412143053.GQ22380@login.ecs.soton.ac.uk> <23ec6165fdb2ab7b2f3946e45caef796@cisco.com> <20050413090132.GD28016@sara.nl> <20050413094428.GE26674@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050413094428.GE26674@login.ecs.soton.ac.uk> User-Agent: Mutt/1.4.2.1i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Apr 13, 2005 at 10:44:28 +0100, Tim Chown wrote: > Between networks the "enough IPv4 addresses that we can build parallel > networks everywhere" argument works, for the ISP systems. In end user > or customer systems, I would expect we'll see a lot of dual stack that > is IPv4+NAT alongside global IPv6. From the ISP perspective what they > might see now is a handul of users achieving that by using a tunnel broker > (probably not one run by the ISP itself) and the challenge is offering > (native, dual-stack) IPv6 from the ISP infrastructure directly. I fully agree with this. I was not suggesting to hand out more IPv4 addresses. I was suggesting to hand out more IPv6 addresses and give them them native IPv6 access instead of tunneled access. rvdp From owner-v6ops@ops.ietf.org Thu Apr 14 00:20:11 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07828 for ; Thu, 14 Apr 2005 00:20:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DLvmJ-000A3S-Gj for v6ops-data@psg.com; Thu, 14 Apr 2005 04:16:31 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DLvmH-000A2z-MV for v6ops@ops.ietf.org; Thu, 14 Apr 2005 04:16:29 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 13 Apr 2005 21:16:29 -0700 X-IronPort-AV: i="3.92,100,1112598000"; d="scan'208"; a="249465060:sNHT32110900" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3E4GMfb010037; Wed, 13 Apr 2005 21:16:23 -0700 (PDT) Received: from [64.104.176.88] (dhcp-64-104-176-88.cisco.com [64.104.176.88]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j3E47k3H012071; Wed, 13 Apr 2005 21:07:49 -0700 In-Reply-To: <200504082307.j38N7ZY01275@irp-view7.cisco.com> References: <200504082307.j38N7ZY01275@irp-view7.cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Lindqvist Erik Kurt , internet-drafts@ietf.org, David Kessens , "'v6ops@ops.ietf.org '" From: Fred Baker Subject: Re: draft-tschofenig-v6ops-secure-tunnels-03.txt Date: Thu, 14 Apr 2005 09:53:18 +0800 To: hannes.tschofenig@siemens.com, psavola@funet.fi, mohanp@sbcglobal.net, rfg@acm.org X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1113451671.135186"; x:"432200"; a:"rsa-sha1"; b:"nofws:808"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"qREeuFDulp+oiS7j7dTisHoaqL+WIDnJmghw/eLfM0VxRy8jv82QdNgLAn4j1H94tI+TsXlQ" "M9HFGl7Lt6dd34hIta9li83ZarVQa9gKwifhUx8w1jAgkLUbtzimT2pdLuosJjs803ZO/Dks936" "T4MecaHajt80kJt9VKQJNWH4="; c:"From: Fred Baker "; c:"Subject: Re: draft-tschofenig-v6ops-secure-tunnels-03.txt"; c:"Date: Thu, 14 Apr 2005 09:53:18 +0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I have received a variety of public and private commentary supporting the draft. I do believe that the draft is of operational significance, and makes valuable recommendations. Therefore, yes, let's bring this into the working group. Please repost this with the moniker draft-ietf-v6ops-secure-tunnels-00.txt. Those of you who wrote in support: I would very much appreciate it if each of you would send detailed comments on this version of the draft to the list, so that the authors can make the best possible progress. On Apr 9, 2005, at 7:07 AM, fred@cisco.com wrote: > Per the minutes, the new chairs are supposed to determine on the list > whether there is support for bringing this draft into the working > group, or whether it should continue as a personal submission. So I'm > asking. > > If I get private or public emails from 10 people that are not authors > in support of it, and little or no objection, I will consider it to > have passed that hurdle. > > Please advise