From owner-v6ops@ops.ietf.org Thu Feb 3 11:38: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 LAA13155 for ; Thu, 3 Feb 2005 11:38:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cwjxc-0003Bd-LW for v6ops-data@psg.com; Thu, 03 Feb 2005 16:36:04 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cwjxa-0003BJ-1m for v6ops@ops.ietf.org; Thu, 03 Feb 2005 16:36:02 +0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j13Ga0808073 for ; Thu, 3 Feb 2005 18:36:00 +0200 (EET) X-Scanned: Thu, 3 Feb 2005 18:45:56 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j13GjuKl004488 for ; Thu, 3 Feb 2005 18:45:56 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00v1qQVs; Thu, 03 Feb 2005 17:30:23 EET 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 j13Etrx05823 for ; Thu, 3 Feb 2005 16:55:53 +0200 (EET) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 3 Feb 2005 16:55:52 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 3 Feb 2005 16:55:50 +0200 Received: from 172.21.224.112 ([172.21.224.112]) by esebe100.NOE.Nokia.com ([172.21.138.118]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 Feb 2005 14:55:50 +0000 Received: from essat-vlan154-2-224112.ntc.nokia.com by ESEBE100.noe.nokia.com; 03 Feb 2005 16:55:50 +0200 Subject: Re: [Fwd: I-D ACTION:draft-vandevelde-v6ops-nap-01.txt] From: "Soininen Jonne (Nokia-NET/Helsinki)" To: v6ops@ops.ietf.org In-Reply-To: <41F76476.9020304@zurich.ibm.com> References: <41F76476.9020304@zurich.ibm.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1107442549.7471.68.camel@essat-vlan154-2-224112.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 03 Feb 2005 16:55:50 +0200 X-OriginalArrivalTime: 03 Feb 2005 14:55:50.0038 (UTC) FILETIME=[73492B60:01C50A00] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 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 Hello everybody, I read the draft in question an I found it rather good already. I think it really does hit a spot. I had some mostly minor comments that I think are more a matter of taste than substantial. However, I would like to raise them for discussion: General comment: I think the audience of the paper are people who are already true believers of IPv6 and then people that are just trying to find the functionality that they need, or think they need from NATs. I think neither of these people groups actually need any health warnings on NATs themselves or are even interested in the problems of NATs. Discussion about these issues just distract people. I would propose to remove most of the problems of NAT and put them in an annex if they are not absolutely necessary in the text. I don't think the idea of the paper is to say NATs are bad, but to inform how the things can be done in IPv6 without NATs and even better! Some comments about the text itself: The title of 2.1 ("Simple Gateway..."). Maybe a different name would be better than "Simple Gateway". Maybe virtually zeroconfig gateway, or easy to configure, etc. NAT is maybe actually not that simple, but deploying it is simple for the user. 2.2. Simple security, if the issues of NATs have to be listed in the body of the document, maybe it is also worth while then mentioning that private addressing does not actually always mean that the network would be that private. For instance, my provider has this bizarre configuration where there is NAT in the network but there is one-to-one mapping between the private address and the public address. So, it doesn't save any addresses, protect you at all, etc. In addition, if you have an operator provided NAT (for a reason or another) there still might be attackers within the private address space. Continuing in 2.2 " In some cases, NAT operators (including domestic users) may be obliged to configure quite complex port mapping rules to allow external access to local applications such as a multi-player game or web servers. In this case the NAT actually adds management complexity compared to a simple router. In situations where 2 or more devices need to host the same application this complexity shifts from difficult to impossible." This does not raise the issue that complex configuration may turn into security threats. If that wasn't even the idea, I don't think this is a security issue and shouldn't be here in the first place. It kind of sounds like you have remembered another bad thing about NAT, and just add it where you were typing at that time... ;) Section 2.3, I have often heard that NATs are good, because they give you control on what can be done through your network. So, if you don't want people to surf on certain sites, you just add NATs and that's it. Maybe the "operator/provider/administrator control" should be added as a perceived benefit. Section 4.1, there is discussion about DHCP-PD and how simple it is and you don't have to run any routing protocol. I think this is fine, but does not quite answer the whole question. It might be good to add some words about when your home or whatever gateway can get a prefix of its own, it does not _have to_ give private addresses, but it can give real public addresses. This is in practice not possible in IPv4. So basically, you don't need private addresses. So, these were my comments - for now... Cheers, Jonne. On Wed, 2005-01-26 at 11:35, ext Brian E Carpenter wrote: > -------- Original Message -------- > Subject: I-D ACTION:draft-vandevelde-v6ops-nap-01.txt > Date: Tue, 25 Jan 2005 16:05:42 -0500 > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : IPv6 Network Architecture Protection > Author(s) : G. Van de Velde, et al. > Filename : draft-vandevelde-v6ops-nap-01.txt > Pages : 30 > Date : 2005-1-25 > > Although there are many perceived benefits to Network Address > Translation (NAT), the primary benefit of "amplifying" available > address space is not needed in IPv6. In addition to its many serious > disadvantages there is a perception that other benefits exist, such > as a variety of management and security reasons that could be useful > for an Internet Protocol. IPv6 does not support NAT by design and > this document shows how Network Architecture Protection (NAP) using > IPv6 can provide the benefits without the need for NAT. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-vandevelde-v6ops-nap-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-vandevelde-v6ops-nap-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-vandevelde-v6ops-nap-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. -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Thu Feb 3 14:06: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 OAA27015 for ; Thu, 3 Feb 2005 14:06:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwmHF-000MHf-Nz for v6ops-data@psg.com; Thu, 03 Feb 2005 19:04:29 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwmHB-000MGw-WC for v6ops@ops.ietf.org; Thu, 03 Feb 2005 19:04:26 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j13J4Oj25797 for ; Thu, 3 Feb 2005 21:04:24 +0200 Date: Thu, 3 Feb 2005 21:04:24 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: Please review section 3 of Enterprise analysis 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 Folks, (co-chair hat on) Only one person sent comments on enterprise analysis within the week. We *do* need more eyeballs especially on section 3. The authors really need your feedback on the direction of the work. Please provide your thoughts ASAP. (hat off) On Wed, 26 Jan 2005, Pekka Savola wrote: > (co-chair hat on) > > There haven't been comments since the revision of Enterprise Analysis doc was > published, so asking explicitly. > > Please review section 3 of the Enterprise analysis, and send your comments on > the list. Please try to do this within about a week, by 2nd February. > > Thanks! > > (hat off) > > ---------- Forwarded message ---------- > Date: Mon, 10 Jan 2005 15:50:07 -0500 > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > Cc: v6ops@ops.ietf.org > Subject: I-D ACTION:draft-ietf-v6ops-ent-analysis-01.txt > > 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 : IPv6 Enterprise Network Analysis > Author(s) : J. Bound > Filename : draft-ietf-v6ops-ent-analysis-01.txt > Pages : 29 > Date : 2005-1-10 > > This document analyzes the transition to IPv6 in enterprise > networks. These networks are characterized as a network that has > multiple internal links, one or more router connections, to one or > more Providers, and is managed by a network operations entity. The > analysis will focus on a base set of transition notational networks > and requirements expanded from a previous Enterprise Scenarios > document. Discussion is provided on a focused set of transition > analysis required for the enterprise to transition to IPv6, > assuming a dual IP layer (IPv4 and IPv6) network and node > environment, within the enterprise. Then a set of transition > mechanisms are recommended for each notational network. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-analysis-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-ent-analysis-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-ent-analysis-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. > -- 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 Thu Feb 3 15:58:38 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08086 for ; Thu, 3 Feb 2005 15:58:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cwo2J-000BYN-J9 for v6ops-data@psg.com; Thu, 03 Feb 2005 20:57:11 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cwo2I-000BY6-Ha for v6ops@ops.ietf.org; Thu, 03 Feb 2005 20:57:10 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07974; Thu, 3 Feb 2005 15:57:07 -0500 (EST) Message-Id: <200502032057.PAA07974@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-natpt-to-exprmntl-00.txt Date: Thu, 03 Feb 2005 15:57:07 -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=AWL,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 : Reasons to Move NAT-PT to Experimental Author(s) : C. Aoun, E. Davies Filename : draft-ietf-v6ops-natpt-to-exprmntl-00.txt Pages : 24 Date : 2005-2-3 This document discusses issues with the specific form of IPv6-IPv4 protocol translation mechanism implemented by the Network Address Translator - Protocol Translator (NAT-PT) defined in RFC 2766. These issues are sufficiently serious that recommending RFC 2766 as a general purpose transition mechanism is no longer desirable, and this document requests that the IETF reclassifies RFC 2766 from Standards Track to Experimental status. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-natpt-to-exprmntl-00.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-natpt-to-exprmntl-00.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-natpt-to-exprmntl-00.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-2-3154715.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-natpt-to-exprmntl-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-natpt-to-exprmntl-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-3154715.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri Feb 4 11:50: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 LAA13790 for ; Fri, 4 Feb 2005 11:50:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cx6cl-000Ks4-S4 for v6ops-data@psg.com; Fri, 04 Feb 2005 16:48:03 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1Cx6ci-000Krf-UW for v6ops@ops.ietf.org; Fri, 04 Feb 2005 16:48:01 +0000 Received: (qmail 31683 invoked by uid 417); 4 Feb 2005 16:48:00 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 4 Feb 2005 16:48:00 -0000 Received: from XPNERICK ([132.70.220.24]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Fri, 04 Feb 2005 09:47:58 -0700 Message-ID: <000201c50ad9$47eaac30$0201a8c0@ttitelecom.com> From: "EricLKlein" To: v6ops@ops.ietf.org References: <41F76476.9020304@zurich.ibm.com> <1107442549.7471.68.camel@essat-vlan154-2-224112.ntc.nokia.com> Subject: Re: [Fwd: I-D ACTION:draft-vandevelde-v6ops-nap-01.txt] Date: Fri, 4 Feb 2005 18:45:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 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 Speaking for myself, as one of the Authors - see comments below. Thanks for the serious read through and comments. Eric ----- Original Message ----- Soininen Jonne wrote: > I read the draft in question an I found it rather good already. I think > it really does hit a spot. Thank you. > General comment: I think the audience of the paper are people who are > already true believers of IPv6 and then people that are just trying to > find the functionality that they need, or think they need from NATs. I > think neither of these people groups actually need any health warnings > on NATs themselves or are even interested in the problems of NATs. Actually when I got involved with writing this it was for the IPv6 nay sayers who felt that NAT was the mos timportant feature in the IP world. I spoke with people in network security and network administration roles and when they hear that we had depriciated RFC1918 like addressed in IPv6 they compleatly freaked out. They felt that NAT was needed for site security, or for seperation of subnets, or other of the "percieved values" that we put into the paper. So in short my goal was a paper that could be used by the IPv6 true belivers to either explain to newbies or disbelivers why their NAT was not being upgraded with the rest of the addresses and networking. > Discussion about these issues just distract people. I would propose to > remove most of the problems of NAT and put them in an annex if they are > not absolutely necessary in the text. I don't think the idea of the > paper is to say NATs are bad, but to inform how the things can be done > in IPv6 without NATs and even better! We tried to not do too much NAT bashing, but there were so many misconceptions as to why a network "just has to have NAT" that the explinations made the rest seem to make sense to us. If there is a real problem and the WG all agrees, we can review moving these. > Some comments about the text itself: > 2.2. Simple security, if the issues of NATs have to be listed in the > body of the document, maybe it is also worth while then mentioning that > private addressing does not actually always mean that the network would > be that private. For instance, my provider has this bizarre > configuration where there is NAT in the network but there is one-to-one > mapping between the private address and the public address. So, it > doesn't save any addresses, protect you at all, etc. In addition, if you > have an operator provided NAT (for a reason or another) there still > might be attackers within the private address space. > If your provider is doing this (and it is not the first time I have heard of this configuration) then are you using NAT after the fixed address to share the connection between multiple hosts? Thus making it: Fixed address (Carreir to carrier) <-> NAT (Carrier to Customer) <-> NAT Customer Network <-> Host If so then it is you that are saving the IP addresses not the carrier (this is why we have many diffrent catagories in section 5). As to the security concerns, where I have seen this done the carriers are usually using NAT to subnet their network (as described in 5.4) so that they have one large block and are using it to reduce problems in their administration network. But you are right to you there is still no security benifit. > Continuing in 2.2 > " In some cases, NAT operators (including domestic users) may be > obliged to configure quite complex port mapping rules to allow > external access to local applications such as a multi-player game or > web servers. In this case the NAT actually adds management > complexity compared to a simple router. In situations where 2 or > more devices need to host the same application this complexity shifts > from difficult to impossible." > > This does not raise the issue that complex configuration may turn into > security threats. If that wasn't even the idea, I don't think this is a > security issue and shouldn't be here in the first place. It kind of > sounds like you have remembered another bad thing about NAT, and just > add it where you were typing at that time... ;) Not all that is bad with NAT is limited to security. > > Section 2.3, I have often heard that NATs are good, because they give > you control on what can be done through your network. So, if you don't > want people to surf on certain sites, you just add NATs and that's it. > Maybe the "operator/provider/administrator control" should be added as a > perceived benefit. > Good point. > Section 4.1, there is discussion about DHCP-PD and how simple it is and > you don't have to run any routing protocol. I think this is fine, but > does not quite answer the whole question. It might be good to add some > words about when your home or whatever gateway can get a prefix of its > own, it does not _have to_ give private addresses, but it can give real > public addresses. This is in practice not possible in IPv4. So > basically, you don't need private addresses. > Also a good point. > From owner-v6ops@ops.ietf.org Fri Feb 4 23:42:51 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12568 for ; Fri, 4 Feb 2005 23:42:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CxHkI-0006CF-KQ for v6ops-data@psg.com; Sat, 05 Feb 2005 04:40:34 +0000 Received: from [210.84.237.125] (helo=ubu.nosense.org) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CxHkG-0006Bz-1L for v6ops@ops.ietf.org; Sat, 05 Feb 2005 04:40:33 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id B843D62AAE for ; Sat, 5 Feb 2005 15:10:28 +1030 (CST) Date: Sat, 5 Feb 2005 15:10:28 +1030 From: Mark Smith To: v6ops@ops.ietf.org Subject: Re: [Fwd: I-D ACTION:draft-vandevelde-v6ops-nap-01.txt] Message-Id: <20050205151028.79561460.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <41F76476.9020304@zurich.ibm.com> References: <41F76476.9020304@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=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Firstly, I also agree, this document is good and useful. A few comments. "2.4 Privacy and topology hiding" I'm a bit confused by the last paragraph, which looks to be a general description of what port scanning is. Is it trying to say that in a number of IPv4 NAT scenarios (e.g., 1 to 1 or 1 to many, as described by a few of the earlier paragraphs), that once the public IP address(es) of the NAT devices have been identified, port scanning can take place against the hosts behind the NAT device (which in reality is the NAT device itself) ? If that is generally the intention, then I'd suggest (a) moving the paragraph to a bit earlier in the section. To me, it would seem better placed directly after the 2nd paragraph, which finishes with "At the same time a NAT creates a smaller pool of addresses for a much more focused point of attack." (b) it is probably worth distinguishing between configured "server port mappings" and ephemeral port mappings on the NAT device, and then briefly describing the possible attacks based on either type of port mapping. The text seems to be only describing launching a port scan against NAT boxes with configured server port mappings, and then using those results to launch a targetted application attack. Pro-NAT people will argue that that is a far less common scenario than ephemeral port mappings for servers on the Internet and clients behind the NAT box, and therefore isn't a major concern. Suggestion (b) might be a bit too detailed for this RFC. On the other hand, I think it would be useful if an RFC such as this one could be read "stand alone", meaning that it also incorporates brief discussion of the issues as well as a reference to more informative RFCs on the particular topic. I think it would be useful to say "just read this (single) RFC" as to why IPv6 eliminates the need for NAT." "3.4 Untraceable IPv6 addresses" I'm probably going slightly off topic ... I seem to remember some concern on the IPv6 ML with ISPs assigning /127s to PtoP links, and it causing problems related to multicast or anycast capabilities. Admittedly I don't fully understand the issues, although I also wonder whether they exist if /128s are assigned to hosts and host routes used in the method described in this section. "4.3 User/Application tracking" I first read this in horror ( :-) ), as the ability to track usage is anti-privacy. Then I remembered that it serving one of the perceived benefits of IPv4+NAT for network managers, as discussed in section 2.3. I think this is a relatively uncommon use of IPv4+NAT, so I think it might be useful to mention again in this section that IPv4+NAT is sometimes used for this purpose, just to placate people who've also forgotten about section 2.3, as I did while reading through the ID. The next section addresses my default privacy concern. As an alternative to my previous suggestion, maybe there would be value in reversing the order of the "User/Application tracking" and "Privacy and topology hiding using IPv6" sections in both main sections 2 and 4. "4.5 Independent control of addressing in a private network" I'd suggest clarifying the following a bit further : When using IPv6, the need to ask for more address space will become far less likely due to the increased size of the subnets. These subnets typically allow 2^64 hosts per subnet and an enterprise will typically receive a /48 which allows segmentation into at least 2^16 different subnets. 2^16 subnets is only possible if flat routing is used, and I'm not aware that this is possible with current IGPs, or hierarchial addressing is used with the network topology perfectly matching the addressing hierarchy levels. I think the "at least" implies a minimum in common scenarios, and I wouldn't think this will be the case. More than 2^16 subnets within a single /48 would require bits to be stolen from the IID section of the global address. If this is the scenario that the "at least" is implying, I think it should be clarified a bit more. Regards, Mark. -- "This signature intentionally left blank." From owner-v6ops@ops.ietf.org Sat Feb 5 12:12: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 MAA15463 for ; Sat, 5 Feb 2005 12:12:20 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CxTPw-000FfO-Fe for v6ops-data@psg.com; Sat, 05 Feb 2005 17:08:20 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CxTPv-000Ff1-27 for v6ops@ops.ietf.org; Sat, 05 Feb 2005 17:08:19 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j15H8CE15689 for ; Sat, 5 Feb 2005 19:08:13 +0200 Date: Sat, 5 Feb 2005 19:08:12 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: Take ISP BB scenarios as WG document? 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 Hi, (co-chair hat on) There seems to be consensus to take this as WG items. Authors, please submit the next version as draft-ietf-v6ops-bb-deployment-scenarios-00.txt Thanks, and keep the reviews coming! (hat off) On Fri, 21 Jan 2005, Pekka Savola wrote: > (co-chair hat on) > > The authors have asked if the following document would be adopted as WG item: > > "ISP IPv6 Deployment Scenarios in Broadband Access Networks" > http://www.ietf.org/internet-drafts/draft-asadullah-v6ops-bb-deployment-scenarios-02.txt > > Please say what you think. Silence DOES NOT indicate consent. If new work > items are to be adopted, there must be active support for doing it, and there > must be people willing to review and work on the draft. > > The deadline for comments is in 2 weeks, on February 4th. > > (hat off) > > -- 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 Feb 6 13:21: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 NAA13694 for ; Sun, 6 Feb 2005 13:21:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CxqyY-0006UH-MO for v6ops-data@psg.com; Sun, 06 Feb 2005 18:17:38 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CxqyU-0006Sc-Si for v6ops@ops.ietf.org; Sun, 06 Feb 2005 18:17:34 +0000 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 06 Feb 2005 10:18:13 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from sasad-w2k01.cisco.com (sjc-vpn5-196.cisco.com [10.21.88.196]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j16IHTYP000243; Sun, 6 Feb 2005 10:17:30 -0800 (PST) Message-Id: <4.3.2.7.2.20050206100601.02b5bad8@ce-nfs-1.cisco.com> X-Sender: sasad@ce-nfs-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 06 Feb 2005 10:16:38 -0800 To: Pekka Savola From: Salman Asadullah Subject: Re: Take ISP BB scenarios as WG document Cc: v6ops@ops.ietf.org, Adeel Ahmed , cpopovic@cisco.com, sraza@cisco.com, Patrick Grossetete In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_520502292==_.ALT" 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_30_40, HTML_MESSAGE autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=====================_520502292==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hello Pekka & All, We would like to thank you and every one in the work group who have helped us to make this draft better and finally approving it. We will work on integrating all the new comments/feedback and submit the next version soon. We would appreciate any more feedback. Regards, Salman At 07:08 PM 2/5/2005 +0200, Pekka Savola wrote: >Hi, > >(co-chair hat on) > >There seems to be consensus to take this as WG items. Authors, please >submit the next version as draft-ietf-v6ops-bb-deployment-scenarios-00.txt > >Thanks, and keep the reviews coming! > >(hat off) > >On Fri, 21 Jan 2005, Pekka Savola wrote: >>(co-chair hat on) >> >>The authors have asked if the following document would be adopted as WG item: >> >>"ISP IPv6 Deployment Scenarios in Broadband Access Networks" >>http://www.ietf.org/internet-drafts/draft-asadullah-v6ops-bb-deployment-scenarios-02.txt >> >>Please say what you think. Silence DOES NOT indicate consent. If new work >>items are to be adopted, there must be active support for doing it, and >>there must be people willing to review and work on the draft. >> >>The deadline for comments is in 2 weeks, on February 4th. >> >>(hat off) >> > >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --=====================_520502292==_.ALT Content-Type: text/html; charset="us-ascii" Hello Pekka & All,

We would like to thank you and every one in the work group who have helped us to make this draft better and finally approving it.

We will work on integrating all the new comments/feedback and submit the next version soon.

We would appreciate any more feedback.

Regards,
Salman

At 07:08 PM 2/5/2005 +0200, Pekka Savola wrote:
Hi,

(co-chair hat on)

There seems to be consensus to take this as WG items. Authors, please submit the next version as draft-ietf-v6ops-bb-deployment-scenarios-00.txt

Thanks, and keep the reviews coming!

(hat off)

On Fri, 21 Jan 2005, Pekka Savola wrote:
(co-chair hat on)

The authors have asked if the following document would be adopted as WG item:

"ISP IPv6 Deployment Scenarios in Broadband Access Networks"
http://www.ietf.org/internet-drafts/draft-asadullah-v6ops-bb-deployment-scenarios-02.txt

Please say what you think. Silence DOES NOT indicate consent. If new work items are to be adopted, there must be active support for doing it, and there must be people willing to review and work on the draft.

The deadline for comments is in 2 weeks, on February 4th.

(hat off)


--
Pekka Savola                "You each name yourselves king, yet the
Netcore Oy                   kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--=====================_520502292==_.ALT-- From owner-v6ops@ops.ietf.org Sun Feb 6 16:43: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 QAA00581 for ; Sun, 6 Feb 2005 16:43:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1Cxu9S-0004gR-SG for v6ops-data@psg.com; Sun, 06 Feb 2005 21:41:06 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1Cxu9P-0004ft-Dp for v6ops@ops.ietf.org; Sun, 06 Feb 2005 21:41:03 +0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j16Lf1O07680; Sun, 6 Feb 2005 23:41:01 +0200 (EET) X-Scanned: Sun, 6 Feb 2005 23:49:41 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j16Lnfk2009727; Sun, 6 Feb 2005 23:49:41 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00MxBhw1; Sun, 06 Feb 2005 23:49:38 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j16LJXx01728; Sun, 6 Feb 2005 23:19:33 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 6 Feb 2005 23:19:27 +0200 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 6 Feb 2005 23:19:27 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 6 Feb 2005 23:19:26 +0200 Received: from 10.162.253.174 ([10.162.253.174]) by esebe100.NOE.Nokia.com ([172.21.138.118]) with Microsoft Exchange Server HTTP-DAV ; Sun, 6 Feb 2005 21:19:25 +0000 Received: from localhost.localdomain by ESEBE100.noe.nokia.com; 06 Feb 2005 23:19:26 +0200 Subject: Re: [Fwd: I-D ACTION:draft-vandevelde-v6ops-nap-01.txt] From: "Soininen Jonne (Nokia-NET/Helsinki)" To: ext EricLKlein Cc: v6ops@ops.ietf.org In-Reply-To: <000201c50ad9$47eaac30$0201a8c0@ttitelecom.com> References: <41F76476.9020304@zurich.ibm.com> <1107442549.7471.68.camel@essat-vlan154-2-224112.ntc.nokia.com> <000201c50ad9$47eaac30$0201a8c0@ttitelecom.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1107724766.4616.14.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 06 Feb 2005 23:19:26 +0200 X-OriginalArrivalTime: 06 Feb 2005 21:19:26.0980 (UTC) FILETIME=[89B10C40:01C50C91] 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 Eric, thanks for your comments, I'll try to address your comments/questions below: On Fri, 2005-02-04 at 18:45, ext EricLKlein wrote: > Speaking for myself, as one of the Authors - see comments below. > > > General comment: I think the audience of the paper are people who are > > already true believers of IPv6 and then people that are just trying to > > find the functionality that they need, or think they need from NATs. I > > think neither of these people groups actually need any health warnings > > on NATs themselves or are even interested in the problems of NATs. > > Actually when I got involved with writing this it was for the IPv6 nay > sayers who felt that NAT was the mos timportant feature in the IP world. I > spoke with people in network security and network administration roles and > when they hear that we had depriciated RFC1918 like addressed in IPv6 they > compleatly freaked out. They felt that NAT was needed for site security, or > for seperation of subnets, or other of the "percieved values" that we put > into the paper. > > So in short my goal was a paper that could be used by the IPv6 true belivers > to either explain to newbies or disbelivers why their NAT was not being > upgraded with the rest of the addresses and networking. What I meant was: the true believers already know NATs are bad - they don't need the repetition, and the people that think that NATs are the best things since sliced bread are not going to believe it anyways. Important story of the document is that IPv6 can provide you the functionality that you think you are getting from NATs, but only better. Anyways, that was just my opinion, and I don't feel very strongly about it. [Snip] > > > Some comments about the text itself: > If your provider is doing this (and it is not the first time I have heard of > this configuration) then are you using NAT after the fixed address to share > the connection between multiple hosts? Thus making it: > > Fixed address (Carreir to carrier) <-> NAT (Carrier to Customer) <-> NAT > Customer Network <-> Host > > If so then it is you that are saving the IP addresses not the carrier (this > is why we have many diffrent catagories in section 5). > As to the security concerns, where I have seen this done the carriers are > usually using NAT to subnet their network (as described in 5.4) so that they > have one large block and are using it to reduce problems in their > administration network. But you are right to you there is still no security > benifit. Actually, I don't have NAT in my network. The setup is strange, because there is this interesting thing going on: My IP access is provided by a company that provides me access (with a VPN) to my company. However, to get access to Internet I need a second provider. There are multiple providers I can choose from and I have a contract with one of them. To access the Internet I have to "activate" the access, by first choosing my provider from a web menu and then giving the credentials (username, password). After that I have Internet access. However, as by the time I boot my computer it is not known which provider's access I'm going to use they cannot give me the real IP addresses. When I then activate the Internet access they would have to renumber my computer's IP address it is easier to NAT. I actually can connect up to five computers to the Internet and really all private addresses seem to correspond to an individual public address... > > Not all that is bad with NAT is limited to security. I know, but this section is about security. I think the point is valid, but it just seems to be in the wrong place. Cheers, Jonne. -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Mon Feb 7 03: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 DAA06431 for ; Mon, 7 Feb 2005 03:45:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1Cy4Tl-000BRy-5x for v6ops-data@psg.com; Mon, 07 Feb 2005 08:42:45 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1Cy4Tj-000BRc-Tp for v6ops@ops.ietf.org; Mon, 07 Feb 2005 08:42:44 +0000 Received: (qmail 8095 invoked by uid 417); 7 Feb 2005 08:42:42 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 7 Feb 2005 08:42:42 -0000 Received: from XPNERICK ([193.17.42.1]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Mon, 07 Feb 2005 01:42:41 -0700 Message-ID: <000e01c50cf0$fc9e14f0$6b081eac@ttitelecom.com> From: "EricLKlein" To: v6ops@ops.ietf.org References: <41F76476.9020304@zurich.ibm.com> <1107442549.7471.68.camel@essat-vlan154-2-224112.ntc.nokia.com> <000201c50ad9$47eaac30$0201a8c0@ttitelecom.com> <1107724766.4616.14.camel@localhost.localdomain> Subject: Re: [Fwd: I-D ACTION:draft-vandevelde-v6ops-nap-01.txt] Date: Mon, 7 Feb 2005 10:42:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1255"; 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.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 Jonne >> If so then it is you that are saving the IP addresses not the carrier >> (this >> is why we have many diffrent catagories in section 5). >> As to the security concerns, where I have seen this done the carriers are >> usually using NAT to subnet their network (as described in 5.4) so that >> they >> have one large block and are using it to reduce problems in their >> administration network. But you are right to you there is still no >> security >> benifit. > > Actually, I don't have NAT in my network. The setup is strange, because > there is this interesting thing going on: My IP access is provided by a > company that provides me access (with a VPN) to my company. However, to > get access to Internet I need a second provider. There are multiple > providers I can choose from and I have a contract with one of them. To > access the Internet I have to "activate" the access, by first choosing > my provider from a web menu and then giving the credentials (username, > password). After that I have Internet access. However, as by the time I > boot my computer it is not known which provider's access I'm going to > use they cannot give me the real IP addresses. When I then activate the > Internet access they would have to renumber my computer's IP address it > is easier to NAT. > I actually can connect up to five computers to the Internet and really > all private addresses seem to correspond to an individual public > address... This is an interesting configuration, I have seen 2 diffrent implementation models for what you describe and I am courious which your provider is using: 1. Access provider provides actual real IP address and then acts as a pass through to the ISP via the login dashboard. 2. Access provider continues to use NAT address and sets up VPN to ISP after the login dashboard, and you get a real IP address from the ISP. Have you looked to see which model you have? Thanks for the feedback, Eric Klein TTI Telecom From owner-v6ops@ops.ietf.org Mon Feb 7 04:54: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 EAA11286 for ; Mon, 7 Feb 2005 04:54:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1Cy5aI-000N15-Kv for v6ops-data@psg.com; Mon, 07 Feb 2005 09:53:34 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1Cy5aG-000N0T-GB for v6ops@ops.ietf.org; Mon, 07 Feb 2005 09:53:33 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j179rUS00570 for ; Mon, 7 Feb 2005 11:53:30 +0200 Date: Mon, 7 Feb 2005 11:53:30 +0200 (EET) From: Pekka Savola To: IPv6 Operations Subject: Re: [Fwd: I-D ACTION:draft-vandevelde-v6ops-nap-01.txt] In-Reply-To: <41F76476.9020304@zurich.ibm.com> Message-ID: References: <41F76476.9020304@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 Hi, A couple of personal comments. In short I think the doc is in pretty good shape. I think the target audience of this document is mainly out-of-the-IETF folks who may not be all that v6-savvy. I call this a "techno-political document", and hence important. substantial ----------- 11. References 11.1 Normative References 11.2 Informative References ==> Normative references section should nonempty. I suggest moving at least RFC1918, RFC2663, RFC2461, RFC3022, RFC2993, RFC3027, RFC3041, RFC3315, RFC3484, RFC3633, draft-ietf-v6ops-renumbering-procedure and draft-ietf-ipv6-unique-local-addr up there. semi-editorial -------------- However, if a site is connected to its ISPs via NAT boxes, only those boxes need to deal with multihoming and renumbering issues. ==> s/only/sometimes only/ -- for small SOHOs the above is typically true, but if you put e.g. servers inside the NAT, you will need to deal with these issues in other boxes as well..? While the primary implementation and source of randomized RFC 3041 addresses is expected to be from end systems running stateless autoconfiguration, there is nothing that prevents a DHCP server from running the RFC 3041 algorithm for any new IEEE identifier it hears, then remembering that for future queries. This would allow using them in DNS for registered services since the assumption of a server based deployment would be a persistent value that minimizes DNS churn. ==> I'm not sure what the last sentence tries to say, in any case, I think it's at least partially incorrect. You can do DNS updates with RFC3041 addresses without DHCP as well. This sentence seems to be hinting that DHCP provides some exceptional otherwise unttainable features with RFC3041 addresses. ULAs have the following characteristics: o Globally unique prefix * Allows networks to be combined or privately interconnected without creating any address conflicts or requiring renumbering of interfaces using these prefixes * If accidentally leaked outside of a network via routing or DNS, there is no conflict with any other addresses ==> it should be clarified that this Globally unique prefix characteristic is *compared to RFC1918*, not compared to IPv6 global prefixes! It is not clear whether you're comparing against IPv4 privates or IPv6 globals.. There is no reason that rack mounted devices shouldn't be considered mobile nodes to mask the internal topology. It looks equivalent to running a VPN to a central server, however it does not involve any encryption or significant overhead. ==> s/shouldn't/couldn't/ otherwise this looks weird?? ==> this does raise some SPoF concerns however.. o The technology to enable source-routing on a network infrastructure has been enhanced to allow this feature to function, without impacting the processing power of intermediate network devices. The only devices impacted with the source-routing will be the source and destination node and the intermediate source-routed nodes. This impact behavior is different if IPv4 is used, because then all intermediate devices would have had to look into the source-route header. ==> again, this is not correct AFAIK. IPv4 source routing can be used in a similar "loose" mode as IPv6, so there is no technical differenceto IPv6 source routing. editorial --------- components. The longterm solution is a single network without usage ==> s/longterm/long term/ routing prefix subnet-id part (SID) and an interface identifier part ==> s/prefix/prefix,/ Randomizing the IID, as defined in RFC 3041, only precludes tracking of the lower 64 bits of the IPv6 address. Masking of the subnet ID will require additional approaches as discussed below in 3.4. Additional considerations are discussed in [17]. Providing privacy for a subnet ID will require different technology. ==> there seems to be duplication with the last two sentences? Just remove the last one? device like a Mobile IPv6 Home Gateway. ==> s/Gateway/Agent/ As a simple gateway, the device has the role of managing both packet Routing and local address management. ==> s/Routing/routing/ What one does when topology probing is to get an idea of the available hosts inside an enterprise. ==> this sentence is hard to parse, and can be written simpler. Reword. masked node using the ULA as a COA This truly masks the internal ==> s/COA/COA./ o The third is the IP addresses (single or blocks) that they assign to customers. These can be registered addresses (usually given to category a and b and sometimes c) ==> you didn't spell out which category is which? Not sure what you're referring to.. devices. When looking in chapter 2.3 of RFC3314 'Recommendations for IPv6 in 3GPP Standards September 2002' [9] it is found that the IPv6 ==> remove "September 2002" ? As an alternative some work in Mobile IP to define a policy message where a mobile node would learn from the home agent that it should not even try to inform its correspondent about route optimization (and thereby expose its real location) would allow a border home agent using internal tunneling to the logically mobile node (potentially rack mounted) to completely mask all internal topology while avoiding the strain from a large number of host routes in the IGP. ==> that's one helluva long sentence. Split to 2-3 ? o Initial section of -00 draft 2.6 and 4.6 have been aggregated into a new Qcase studyR section 5. ==> weird chars around "case study" -- 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 Feb 7 05:12: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 FAA12483 for ; Mon, 7 Feb 2005 05:12:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1Cy5sL-0000cI-VY for v6ops-data@psg.com; Mon, 07 Feb 2005 10:12:13 +0000 Received: from [144.254.15.119] (helo=strange-brew.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1Cy5sK-0000c2-KV for v6ops@ops.ietf.org; Mon, 07 Feb 2005 10:12:13 +0000 Received: from gvandeve-w2k01.cisco.com (ams-clip-vpn-dhcp285.cisco.com [10.61.65.29]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id j17AC5126456; Mon, 7 Feb 2005 11:12:05 +0100 (CET) Message-Id: <4.3.2.7.2.20050207110042.0269fc80@strange-brew> X-Sender: gvandeve@strange-brew X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 07 Feb 2005 11:11:46 +0100 To: Pekka Savola From: "Gunter Van de Velde (gvandeve)" Subject: Re: [Fwd: I-D ACTION:draft-vandevelde-v6ops-nap-01.txt] Cc: IPv6 Operations , ev@cisco.com In-Reply-To: References: <41F76476.9020304@zurich.ibm.com> <41F76476.9020304@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 Hi Pekka, Thanks for input. Before further digestion of the feedback have a look at the thoughts below. At 11:53 7/02/2005 +0200, Pekka Savola wrote: > o The technology to enable source-routing on a network > infrastructure has been enhanced to allow this feature to > function, without impacting the processing power of intermediate > network devices. The only devices impacted with the > source-routing will be the source and destination node and the > intermediate source-routed nodes. This impact behavior is > different if IPv4 is used, because then all intermediate devices > would have had to look into the source-route header. > >==> again, this is not correct AFAIK. IPv4 source routing can be used in a >similar "loose" mode as IPv6, so there is no technical differenceto IPv6 >source routing. I expected this comment to pop-up ;-), thus i did further research on this with the help of Eric. IETF STD5 about the IP protocol itself specifically states that the source route option is used by gateways (and not only by end node): on page 18: The loose source and record route (LSRR) option provides a means for the source of an internet datagram to supply routing information to be used by the gateways in forwarding the datagram to the destination, and to record the route information. and later on page 21: When an internet module routes a datagram it checks to see if the record route option is present. If it is, it inserts its own internet address as known in the environment into which this datagram is being forwarded into the recorded route begining at the octet indicated by the pointer, and increments the pointer by four. My understanding of this is that all routers MUST have a look at the IPv4 options if LSRR is available, and this is different with IPv6. Cheers, G/ From owner-v6ops@ops.ietf.org Mon Feb 7 06:23: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 GAA17299 for ; Mon, 7 Feb 2005 06:23:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1Cy6xg-000D6f-T3 for v6ops-data@psg.com; Mon, 07 Feb 2005 11:21:48 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1Cy6xb-000D5i-88 for v6ops@ops.ietf.org; Mon, 07 Feb 2005 11:21:45 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j17BLWu02672; Mon, 7 Feb 2005 13:21:32 +0200 Date: Mon, 7 Feb 2005 13:21:32 +0200 (EET) From: Pekka Savola To: "Gunter Van de Velde (gvandeve)" cc: IPv6 Operations , ev@cisco.com Subject: Re: [Fwd: I-D ACTION:draft-vandevelde-v6ops-nap-01.txt] In-Reply-To: <4.3.2.7.2.20050207110042.0269fc80@strange-brew> Message-ID: References: <41F76476.9020304@zurich.ibm.com> <41F76476.9020304@zurich.ibm.com> <4.3.2.7.2.20050207110042.0269fc80@strange-brew> 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 Hei, On Mon, 7 Feb 2005, Gunter Van de Velde (gvandeve) wrote: > I expected this comment to pop-up ;-), thus i did further research on this > with the help of Eric. The issue is that IPv4 couples _record route_ and _source route_ functionality. IPv6 does not support record route. However, even if the routers do not look to the IPv4 options, I see no reason why the source route part of IPv4 could not still work without the routers looking at the header. However, I did make a test with this. At least Cisco replies with ICMP source route failed at the first router which has 'no ip source-route' configured. So, while it might be that the routers might not _have_ to record the route, it's probable that most implementations disable all the source routing when they have something like 'no ip source-route' set. > > IETF STD5 about the IP protocol itself specifically states that the source > route option is used by gateways (and not only by end node): > > on page 18: > > The loose source and record route (LSRR) option provides a means > for the source of an internet datagram to supply routing > information to be used by the gateways in forwarding the > datagram to the destination, and to record the route > information. > > and later on page 21: > > When an internet module routes a datagram it checks to see if > the record route option is present. If it is, it inserts its > own internet address as known in the environment into which this > datagram is being forwarded into the recorded route begining at > the octet indicated by the pointer, and increments the pointer > by four. > > > > My understanding of this is that all routers MUST have a look at the > IPv4 options if LSRR is available, and this is different with IPv6. -- 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 Feb 7 09:38: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 JAA03708 for ; Mon, 7 Feb 2005 09:38:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1Cy9zS-000EIZ-LX for v6ops-data@psg.com; Mon, 07 Feb 2005 14:35:50 +0000 Received: from [210.84.224.227] (helo=ubu.nosense.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1Cy9zQ-000EIL-WD for v6ops@ops.ietf.org; Mon, 07 Feb 2005 14:35:49 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 8B94762AAE for ; Tue, 8 Feb 2005 01:05:45 +1030 (CST) Date: Tue, 8 Feb 2005 01:05:45 +1030 From: Mark Smith To: v6ops@ops.ietf.org Subject: [draft-vandevelde-v6ops-nap-01.txt] Suggested addition to Appendix A Message-Id: <20050208010545.3c06c2d7.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <41F76476.9020304@zurich.ibm.com> References: <41F76476.9020304@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, RCVD_IN_SORBS_WEB autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Another thing that could be added to Appendix A is the ability to deploy new transport layer protocols without having to upgrade intermediary devices. To demonstrate that this may be a useful property in the near future, a couple of upcoming transport protocol examples could be * SCTP, which, besides its original telephony signalling use, could also be useful for Instant Messaging e.g., use the separate message boundary capability to allow file transfers to be carried over the same SCTP connection as the human typed text. * DCCP Regards, Mark. -- "This signature intentionally left blank." From owner-v6ops@ops.ietf.org Mon Feb 7 13:59:59 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00348 for ; Mon, 7 Feb 2005 13:59:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyE4D-000KMc-EM for v6ops-data@psg.com; Mon, 07 Feb 2005 18:57:01 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyE48-000KLt-BY for v6ops@ops.ietf.org; Mon, 07 Feb 2005 18:56:56 +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 md50000765429.msg for ; Mon, 07 Feb 2005 19:58:13 +0100 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 07 Feb 2005 19:56:26 +0100 Subject: Call for Papers - Next Global IPv6 Summit in Spain From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable 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, Mon, 07 Feb 2005 19:58:16 +0100 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_50, MIME_QP_LONG_LINE,RCVD_IN_SORBS_WEB,TO_ADDRESS_EQ_REAL autolearn=no version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, As indicated in the email below, the next Global IPv6 Summit in Spain, the bigger IPv6 European event, in its 4th edition (after a very successful organization and broad international attendance in 2001, 2002 and 2003), will be organized this time in Barcelona, next June 2005, with a expected audience over 2.600 key decisions makers from ICT sectors. The main target of the event is business oriented talks, as well as talks oriented to policy makers, information/knowledge society, education and public sectors. This Call for Papers doesn't require that you submit a complete paper (which is welcome also), but instead, a short plain text abstract of your presentation topic, by email. Talks regarding deployment experiences, new services and applications will be of key interest for the expected attendance, and hence highly encouraged. We believe that key topics will be also those regarding: 1) IPv6 and business 2) IPv6 and Broadband 3) New IPv6-based services and applications 4) IPv6 and the Digital Home 5) IPv6 and Multimedia, Voice/Video applications 6) IPv6, Mobility, Wireless and 3G 7) IPv6 and Ambient Intelligence/Ubiquitous Computing/Distributed Systems 8) IPv6 and GRIDs 9) IPv6 and logistics, transport and eSafety 10) IPv6 for eHealth, eGoverment, eLearning and other "e-whatever" 11) IPv6 and gamming 12) IPv6 and peer-to-peer 13) IPv6 and security 14) IPv6 and Open Source 15) IPv6 and marketing/branding Also topics regarding Standards, Research, Development and Innovation experiences are welcome, including R&D projects results. The Agenda will be drafted early in March, so the dead-line for submitting your topic is only until 25th February, but as said only a short abstract is required. If you're interested in participating, or you have any special idea, even if your topic is not in the list above, please don't hesitate to contact me (jordi.palet@consulintel.es) ASAP, so we can work out any options. Regards, Jordi PS: Please, feel free to circulate this email among your contacts. ------ Mensaje reenviado De: JORDI PALET MARTINEZ Responder a: Fecha: Mon, 07 Feb 2005 18:25:42 +0100 Para: "members@ipv6forum.com" , Asunto: Next Global IPv6 Summit in Spain Hi all, As I already informed a few weeks ago, the next Global IPv6 Summit in Spain will be held this time in Barcelona next June (instead of Madrid in March as previously forecasted). This will happen starting on June 6th, with a tutorial in the morning, the opening ceremony in the afternoon, with some keynotes and then 2-3 days of IPv6 conference, depending on the success of the call for papers. If required we can extend our event up to Friday 10th (total 4 days, plus opening ceremony, plus half day tutorial). In this occasion, we will try a completely new model, integrating the IPv6 conference in a bigger event, more business oriented, even when technical sessions will be still present. The "umbrella" event is Internet Global Congress (IGC), with has been organized in Barcelona already during the 6 previous years. The Internet Global Congress, the leading Internet and New Technologies congress in Spain, is organized by the Fundaci=F3 Barcelona Digital, a non-profit organization, which also provides space for exhibition and delivers the IGC awards for Digital Innovation (aimed to students and professionals with embryonic Internet projects, aims to be a launch platform for all those people involved in research and innovation in the field of Internet and the New Technologies). IGC provides us all the infrastructure for organizing the Global IPv6 Summit track, and we only need to manage our own agenda, and consequently our own call for papers (see next email). They also they care about all the issues related to registration, proceedings and publicity, at no cost for us. We expect that this will be the bigger IPv6 event in Europe during 2005, with an expected attendance over 2.600 people, which of course, will be able to attend not just to the IPv6 track but also to other IT tracks (already depicted at http://www.igcweb.net, then click at Program). The attendance is mainly CTOs, CEOs and other key decision makers related to ICT, so its a very nice opportunity for IPv6 in Europe to meet a large audience which probably has not been in touch with IPv6 until now. I count with the support from all of you, and please do not hesitate to let me know any ideas that you may have to make an even more successful event that what for sure we will have in a so nice city as Barcelona. More information will be soon available at http://www.ipv6-es.com and http://www.igcweb.net. Regards, Jordi ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line 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 Wed Feb 9 13:14: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 NAA23274 for ; Wed, 9 Feb 2005 13:14:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CywJV-0009HO-R3 for v6ops-data@psg.com; Wed, 09 Feb 2005 18:11:45 +0000 Received: from [131.228.20.22] (helo=mgw-x2.nokia.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CywJT-0009G3-Oh for v6ops@ops.ietf.org; Wed, 09 Feb 2005 18:11:44 +0000 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j19IBfc15609; Wed, 9 Feb 2005 20:11:41 +0200 (EET) X-Scanned: Wed, 9 Feb 2005 20:10:59 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j19IAxa8007971; Wed, 9 Feb 2005 20:10:59 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00eCFyoI; Wed, 09 Feb 2005 20:09:53 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j19HlhM07093; Wed, 9 Feb 2005 19:47:43 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 9 Feb 2005 19:47:40 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 9 Feb 2005 19:47:43 +0200 Received: from 172.21.224.112 ([172.21.224.112]) by esebe100.NOE.Nokia.com ([172.21.138.118]) with Microsoft Exchange Server HTTP-DAV ; Wed, 9 Feb 2005 17:47:32 +0000 Received: from essat-vlan154-2-224112.ntc.nokia.com by ESEBE100.noe.nokia.com; 09 Feb 2005 19:47:40 +0200 Subject: Re: [Fwd: I-D ACTION:draft-vandevelde-v6ops-nap-01.txt] From: "Soininen Jonne (Nokia-NET/Helsinki)" To: ext EricLKlein Cc: v6ops@ops.ietf.org In-Reply-To: <000e01c50cf0$fc9e14f0$6b081eac@ttitelecom.com> References: <41F76476.9020304@zurich.ibm.com> <1107442549.7471.68.camel@essat-vlan154-2-224112.ntc.nokia.com> <000201c50ad9$47eaac30$0201a8c0@ttitelecom.com> <1107724766.4616.14.camel@localhost.localdomain> <000e01c50cf0$fc9e14f0$6b081eac@ttitelecom.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1107971259.13722.260.camel@essat-vlan154-2-224112.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 09 Feb 2005 19:47:39 +0200 X-OriginalArrivalTime: 09 Feb 2005 17:47:43.0405 (UTC) FILETIME=[750295D0:01C50ECF] 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 Erik, On Mon, 2005-02-07 at 10:42, ext EricLKlein wrote: > Jonne > > This is an interesting configuration, I have seen 2 diffrent implementation > models for what you describe and I am courious which your provider is using: > 1. Access provider provides actual real IP address and then acts as a pass > through to the ISP via the login dashboard. > 2. Access provider continues to use NAT address and sets up VPN to ISP after > the login dashboard, and you get a real IP address from the ISP. > > Have you looked to see which model you have? It is something toward the model 2 that you describe. Cheers, Jonne. > > Thanks for the feedback, > > Eric Klein > TTI Telecom > -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Wed Feb 9 15:33: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 PAA10757 for ; Wed, 9 Feb 2005 15:33:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyyUM-0002jl-8o for v6ops-data@psg.com; Wed, 09 Feb 2005 20:31:06 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyyUL-0002jQ-3J for v6ops@ops.ietf.org; Wed, 09 Feb 2005 20:31:05 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10359; Wed, 9 Feb 2005 15:31:01 -0500 (EST) Message-Id: <200502092031.PAA10359@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-renumbering-procedure-04.txt Date: Wed, 09 Feb 2005 15:31:01 -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 : Procedures for Renumbering an IPv6 Network without a Flag Day Author(s) : F. Baker, et al. Filename : draft-ietf-v6ops-renumbering-procedure-04.txt Pages : 25 Date : 2005-2-9 This document describes a procedure that can be used to renumber a network from one prefix to another. It uses IPv6's intrinsic ability to assign multiple addresses to a network interface to provide continuity of network service through a "make-before-break" transition, as well as addressing naming and configuration management issues. It also uses other IPv6 features to minimize the effort and time required to complete the transition from the old prefix to the new prefix. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-renumbering-procedure-04.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-renumbering-procedure-04.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-renumbering-procedure-04.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-2-9150422.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-renumbering-procedure-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-renumbering-procedure-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-9150422.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Mon Feb 14 13:53:09 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01774 for ; Mon, 14 Feb 2005 13:53:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D0lIh-000Gh9-Hc for v6ops-data@psg.com; Mon, 14 Feb 2005 18:50:27 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D0lIe-000Gg9-BK for v6ops@ops.ietf.org; Mon, 14 Feb 2005 18:50:25 +0000 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 14 Feb 2005 14:02:25 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,84,1107752400"; d="scan'208"; a="36928596:sNHT30554040" Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1EIoAhF007648; Mon, 14 Feb 2005 13:50:11 -0500 (EST) Received: from cpopovic-w2k01.cisco.com (dhcp-64-102-39-102.cisco.com [64.102.39.102]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BFH80900; Mon, 14 Feb 2005 10:50:09 -0800 (PST) Message-Id: <4.3.2.7.2.20050214133755.027d3b90@fruitpie.cisco.com> X-Sender: cpopovic@fruitpie.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Feb 2005 13:50:09 -0500 To: Pekka Savola From: Ciprian Popoviciu Subject: Re: Take ISP BB scenarios as WG document? Cc: v6ops@ops.ietf.org In-Reply-To: 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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello Pekka, First of all, once again thank you for your thorough review and suggestions. We integrated most of the suggestions you and the other folks on the list made and submitted the updated version of the draft last night: draft-ietf-v6ops-bb-deployment-scenarios-001.txt There are a few items you highlighted that we are still investigating. We should have everything clarified soon and we will send a complete response to all your suggestions and the suggestions we received from other people on the list. We did not consolidate some of the sections yet as you proposed because we feel like we need a bit more time to find the best way to do this. We agree that in some areas this will optimize the draft but we want to make sure that we do not loose the correlation between the information presented and the context in which it was presented. This is something we are still working on. So please stay tuned for our detailed reply. Thank you everyone for the valuable feedback provided. Chip At 12:04 PM 1/31/2005 +0200, Pekka Savola wrote: >On Fri, 21 Jan 2005, Pekka Savola wrote: >>"ISP IPv6 Deployment Scenarios in Broadband Access Networks" >>http://www.ietf.org/internet-drafts/draft-asadullah-v6ops-bb-deployment-scenarios-02.txt >> >>Please say what you think. Silence DOES NOT indicate consent. If new >>work items are to be adopted, there must be active support for doing it, >>and there must be people willing to review and work on the draft. >> >>The deadline for comments is in 2 weeks, on February 4th. > >(personal comments, without any hats, of course) > >First, I'd like to thank the authors for this important work. I support >this being taken as WG item and moved forward. > >I'll note that I've personally felt that the document would be better split >to separate documents, but WG participants felt otherwise, so it's OK >because this was not a big issue for me as long as the document is kept >consistent. > >I also thought that it would be useful to merge some text in a "generic" >section, which the other sections could then refer and add to if >necessary. There was also some pushback for this, but because I feel this >is important, let me try to state this again: > a) subsctions "Multicast, QoS, Security Considerations and Network >Management" are 95% common across all the scenarios and could be better put >in one "Generic" section, and referred to and expanded in the >scenario-specific sections. > b) Some parts of different deployment models could possibly be put in such a >generic section. This is a much trickier to get right, of course.. but in >"Addressing" and "Routing" subsubsections there is a lot of common text. > >Maybe a) at least is worth considering? > >substantial >----------- > >0) I've sent some comments off-list; the most important of them was that >there is some work needed especially with DSL RBE-like approach to provide >means for sane bulk DSL usage. Currently you have to configure each >interface for each customer separately, instead of using a template. This >will require an implementation modification to generate a RA prefix based >on the VLAN or PVC id. This should be discussed in the memo. > >1) Many different scenarios talk about dual-stacking (or not) of the edge >router. Is it sufficiently clear in the text that if the SP so desires, it >can use separate edge routers for v4 and v6? > >2) One thing that struct me that is missing as an access network is HomePNA >(sigh). I don't think this is a major deployment model though, so it's OK >to leave it out as well. I think it is basically the same as Ethernet, >except Instead of access swithch, you have a HomePNA switch. I don't know >to which degree those would need to be IPv6-aware; probably not at all >unless one would want it to snoop multicast. > >3) The draft refers extensively to draft-mickles-v6ops-isp-cases-05.txt >(probably at my badly worded suggestion), which is not going to be >published. So, you should not depend on text in that document -- everything >that should be known by the reader should be available here. However, it is >still a good idea to keep the reference still in the Acknowledgements >section. > >4) In WLAN scenario, the document should probably talk a bit about host >authentication at hotspots. If done with 802.11x, then this probably needs >little with Ipv6. If done with web redirection, those services obviously >would need to support IPv6 hijacking as well... > > >semi-editorial >-------------- > > B. Native IPv6 Deployment: The Access Provider routers are upgraded > to support IPv6 and can become dual-stack. In a dual-stack network > an IPv6 IGP such as OSPFv3 or IS-IS is enabled, usually mapping the > IGP deployed for IPv4. The most important thing to remember in this > case is that the device resources are now shared between IPv4 and > IPv6 processes. This problem could be elimnated with the use of > ISIS-MT (multi-topology) where a single database and SPF is used for > IPv4 and IPv6. > >==> the last part of the sentence is slightly inaccurate, and potentially >confusing. As this has been discussed extensively in the soon-to-be-RFC, >maybe th ewhole discussion of which IGP to select and what thay might imply >should be just referred to the other document? > > The native approach has the advantage of supporting IPv6 > multicast traffic but it implies a significant impact on the IPv4 > operational network from software, configuration and possibly > hardware upgrade perspective. > >==> s/implies/may imply/ -- whether this is the case depends a lot on your >hardware, your current status of software, etc.! > > multicast or not), routing protocols used (GRE is the only tunnel > type which can transport layer 2 messages as well), manage-ability > and scalability (dynamic versus static tunnels). > >==> well, I guess in principle you could do L2TP as well, so being 100% >accurate, the statement about GRE is not entirely true. Minor tweaking? > > > Some of the factors that hinder deployment of native IPv6 in current > cable networks include: > >==> it is not 100% clear which of these apply in the bridged cmts model, and >which in the routed cmts model. Clarify. > > A. Problems with IPv6 Neighbor Discovery (ND) on CM and CMTS. These > devices rely on IGMP join messages to track membership of hosts that > are part of a particular IP Multicast group. In order to support ND > the CM and CMTS will need to support IGMPv3/MLDv2 snooping. > >==> the last sentence is not entirely true. For ND, you just need MLDv1 >snooping, though MLDv2 would be preferable for SSM support. But as said, >you only need MLDv1 .. and that only in those devices which actually would >otherwise block the v6 multicasts..? > > C. Changes need to be made to the DOCSIS specification to include > support for IPv6 on the CM and CMTS. This is imperative for > deploying native IPv6 over cable networks. > >==> this is not clear. The only reason I could think of is to be able to >manage CM/CMTS over v6, which seems hardly imperative, so there must be >something else. Clarify? > >6.2.1.2.2 IP Addressing for Hosts > > If there is no GWR connected to the CM, all the hosts behind the CM > will belong to the same /64 subnet that is assigned using stateless > auto-configuration or DHCPv6. > >==> this is slightly confusing, because if DHCPv6 is used, these hosts don't >need to belong ti the same subnet? Actually, I would prefer tailing down >this paragraph, as the next ones more accurately describe the situation. > >.2.1.3 Data Forwarding > > The CM and CMTS must be able to bridge native IPv6 unicast and > multicast traffic. The CMTS must provide IP connectivity between > hosts attached to CMs and must do so in a way that meets the > expectation of Ethernet attached customer equipment. In order to do > that, the CMTS must either forward Neighbor Discovery (ND) packets > or provide a proxy ND service. > >==> the good question to ask here would be, "why wouldn't you then enable >IPv6 on CMTS? instead of proxying?" This requires no changes to _DOCSIS_ >part of CMTS -- just that it implements basic v6 router functionality.. >(in many places) > > > Communication between hosts behind different CMs is always forwarded > by the CMTS. > >==> as the CMTS is layer 2 (right?) maybe this should be "forwarded >through" or "bridged through" ? > > In order to support IPv6 multicast applications across DOCSIS cable > networks, the CM and bridging CMTS need to support IGMPv3/MLDv2 > snooping. MLD is identical to IGMP in IPv4, only the name and numbers > are changed. > >==> I'd reword the latter sentence to like, "MLD is almost identical to IGMP >in IPv4". (many places) > >6.2.1.4 Routing > > The hosts install a default route that points to the ER or the GWR. > No routing protocols are needed on these devices which have > limited resources. If there is a GWR present it will also use static > default route to the ER. > >==> I suggest removing "on these devices which have limited resources". >That is pretty subjective. The same under all the scenarios. > >==> further, in these sections, I'd be a bit more informative about how >exactly the default route is configured. Typically learned from DHCPv4, I'd >guess. > > 2. IPv4 Cable (HFC) Network, GWR at Customer Site > > In this case the cable network, including the CM and CMTS remain > IPv4 devices. The host, GWR and ER are upgraded to dual-stack. This > scenario is also easy to deploy since the cable operator just needs > to add GWR at the customer site. > >==> easy to deploy, but also typically unfeasible to deploy :-/... because >this requires investment and deployment/maintance of/on a new IPv6-capable >GWR. For larger deployments, this would probably be a non-starter, and it >might be better to try to either to tunnel to hosts directly (cheaper ;-), >or just dual-stack the existing box. > >6.2.2.1.2 Addressing > > The only device that needs to be assigned an IPv6 address at customer > site is the host. Host address assignment can be done statically as > there is no mechanism to transport ND messages or DHCPv6 messages > over the IPv4 cable network. > >==> As you're suggesting using tunneling here, I'd suspect getting IPv6 >addresses is tunneling mechanism specific; depending on the mechanism, this >might be automatic or it might require manual configuration. > > The host will use its IPv4 address to source the tunnel to the > ER. All IPv6 traffic will be forwarded to the ER, encapsulated in > IPv4 packets. The intermediate IPv4 nodes will forward this traffic > as regular IPv4 packets. The ER will need to terminate the tunnel > and/or provide other IPV6 services [for example 6to4 relay, tunnel > broker etc.]. > >==> see the substantial issue above -- is it clear enough that the tunnel >box need not be the (v4) ER?. s/IPV6/IPv6/, and remove the stuff in []'s. > > The GWR will use its global IPv4 address to source the tunnel to > the ER. The tunnel endpoint will be the IPv4 global address of the > ER. All IPv6 traffic will be forwarded to the ER, encapsulated in > IPv4 packets. The intermediate IPv4 nodes will forward this traffic > as regular IPv4 packets. In case of 6to4 tunneling, the ER will need > to support 6to4 relay functionality in order to provide IPV6 > Internet connectivity to the GWR and hence the hosts connected to the > GWR. > >==> "global address" is assumptive of deployment, and see the comment above >on service support on ER.. > > If using manual tunneling, the GWR and ER can use static routing or > they can also configure RIPng. The RIPng updates can be transported > over a manual tunnel, which does not work when using 6to4 tunneling. > > Customer routes can be carried to the ER using RIPng updates. The ER > can advertise these routes in its IGP. Prefix summarization should be > done at the ER. > >==> this is the only section that still mentions RIPng, and it should IMHO >be removed. Really. :-) > >6.2.2.3.1 IPv6 Related Infrastructure Changes > > Since the CM still acts as a Layer-2 bridge, it does not need to > be dual-stack. The CM will need to support bridging of IPv6 unicast > and multicast traffic and IGMPv3/MLDv2 snooping which requires > changes in the DOCSIS specification. > >==> as said before, MLDv2 snooping is not a strict requirement :) > > The hosts can receive their IPv6 address via DHCPv6 with the CMTS > acting as a DHCPv6 relay agent. If address assignment on hosts is > done via stateless autoconfiguration, > >==> this is phrased in an odd way. I'd say that the assumption is that >statless address autoconfiguration is used almost always, and DHCPv6 is the >exception (except when you delegate a prefix.) This applies to all the >access types, and could use maybe switching the order of sentences and >tuning the text a bit. (In many places..) > > If using DHCPv6 the CMTS will need to act as DHCPv6 relay agent. The > host and CM/GWR will receive IPv6 addresses from pools of /64 > prefixes configured on the DHCPv6 server. The CMTS will need to glean > pertinent information from the DHCP Offer messages, sent from the > DHCP server to the DHCP clients (host and CM/GWR), much like it does > today in DHCPv4. All CM/GWR connected to the same cable interface on > the CMTS belong to same /64 prefix. The hosts connected to the same > cable interface on the CMTS may belong to different /64 prefixes as > the CMTS will have multiple /64 prefixes configured under its cable > interfaces. > >==> I'm not sure what to make of this, due to the different assumption above >about the usage of DHCPv6. > >Currently the DHCP-PD functionality cannot be > implemented if the DHCP-PD server is not the Edge Router. If the > DHCP-PD messages are relayed, the Edge Router does not have a > mechanism to learn the assigned prefixes and thus install the proper > routes to make that prefix reachable. Work is being done to address > this issue, one idea being to provide the Edge Router with a snooping > mechanism. > >==> it is worth considering, however, whether a solution is *really* needed >here (maybe this problem could be shorter in the sections, and longer in the >gap analysis). I mean, why would one even want to have DHCPv6 server >somewhere else? It's nicely fate-sharing with the service if it's at ER, >and using Radius you can separate the user policy from the server. The only >point is that if the ER does not offer DHCPv6 functionality, but in that >case, I'd be doubtful if it offered this snooping hack either... > >6.2.2.5.4 Routing > > The CM/GWR can use a static default route pointing to the CMTS/ER or > it can run a routing protocol such as RIP-ng or OSPFv3 between itself > and the CMTS. Customer routes from behind the CM/GWR can be carried > to the CMTS using routing updates. > > If DHCP-PD is used for address assignment a static route is > automatically installed on the CMTS/ER for each delegated /48 prefix. > The static routes need to be redistributed into the IGP at the > CMTS/ER so there is no need for a routing protocol between the > CMTS/ER and the GWR. > >==> the end of 1st para is RIPng fragment and should be removed IMHO. In any >case, this seems to be conflicting with the end of the 2nd paragraph :) > >ASM is however an option that is > discussed in section 7.3.1. The "SSM safe reporting" problem for IPv4 > does not exist in IPv6 multicast because the use of SSM in IPv6 is > well defined and uses un-contentious address ranges. > >==> I'm not sure what you mean by "SSM safe reporting", so it would be good >if you could add a reference here. > >The CM, GWR and > CMTS/ER will need to be enabled with PIM-SSM, which requires the > definition and support for IGMPv3/MLDv2 snooping, in order to track > join/leave messages from the hosts. The Layer 3 next hop for the > hosts support MLD. > >==> this appears to be slightly mixed up. If CM acts as a bridge, it won't >need any support for PIM-SSM. Likely CM does not even need MLD snooping >because it should probably just pass everything through (depending on >whether non-joined flooded multicast traffic in the ethernet segment is >considered a problem or not). > > The CMTS/ER should protect the ISP network and the other subscribers > against attacks by one of its own customers. For this reason uRPF and > ACLs should be used on all interfaces facing subscribers. Filtering > should be implemented with regard for the operational requirements of > IPv6 (ICMPv6 types). > >==> spell out and refer to uRPF (e.g., RFC3704). >==> spell out what exactly you mean with the latter. It seems you are >vaguely saying "you should figure out which kind of ACLs are OK, in >particular, which ICMPv6 types are really needed and should not be >filtered". This is rather vague, though I'm not sure whether this is the >right place to specify what to filter or not... > > DSL Modem: It can be a stand alone device, it can be incorporated > in the host, and it can incorporate router functionalities. > > Customer Premises Router: It is used to provide layer 3 services > for customer premises networks. It is usually use to provide > firewalling functions and segment broadcast domains for a Small > business. > >==> maybe it would be worth saying that VERY often, DSL modem includes the >capbility to act as CPE router (whether it does or not is a matter of >configuration, i.e., whether it runs in bridged or routed mode). > > C. Terminate the PVC at layer 3, each PVC has its own prefix. This is > the approach that seems more suitable for IPv6 and presented in 7.2.1 > In none of these cases the CPE (DSL Modem) has to be upgraded. > >==> you're assumingi that the CPE would not have router functionalities, but >would be just a bridge, yes? > > B. It dynamically acquires through stateless autoconfiguration the > address for the link between itself and the Edge Router. This step > is followed by a DHCP-PD [RFC 3633] request for a prefix shorter then > /64 that in turn is divided in /64s and assigned to its interfaces > connecting the hosts on the customer site. > >==> the first sentence is interesting, and there were already comments about >this. Maybe this should be put last in this paragraph with a bit of >rewording. Actually, there is nothing requiring the router to do this >stuff.. it can run DHCPv6 very well without a global address in its upstream >interface! So, AFAIK, the whole suggestion could be removed, but if it >isn't, it should be put in proper perspective. (In very many places..) > > The Edge Router has a /64 prefix configured for each subscriber VLAN. > >==> in a couple of places, you talked about PVCs, and some others, VLANs. >Maybe synch the terminology a bit? > >7.2.3.1 IPv6 Related Infrastructure Changes > > In this scenario the BRAS is layer-3 aware and it has to be upgraded > to support IPv6. > >==> it was not clear to me why in this case it is required to update BRAS. >You know, at least based on the figures, the PPP sessions go straight >through it, and it shouldn't be knowing anything about v6.. or...? > > This allows the ERs > (LNSs) to aggregate the addresses handed out to the customers. In the > case of IPv6, an important constraint that likely will be enforced is > that the customer should keep its own address regardless of the ER > (LNS) it connects to. This could significantly reduce the prefix > aggregation capabilities of the ER (LNS). > > >==> this seems to have the hidden assumption that v6 addresses/prefixes will >be stable, while v4 addresses are currently dynamic. I welcome that >situation personally, but if you describe this as an issue, you probably >should spell out this assumption about different deployment models. > > In some cases service providers manage equipment located on > customers LANs. > >==> this appears to be mentioned a couple of times, and is IMHO redundant >and out of scope for this draft. If you really really want to say >something, maybe at most "The management of equipment at customers' LANs is >out of scope of this memo." > > WLAN enables subscribers to connect to the Internet from various > locations without the restriction of staying indoors. WLAN is > standardized by IEEE 802.11x. > >==> the last sentence is wrong, maybe the wrong letter? 11x is just the >authentication part of it.. > > offers maximum transmission speed from 1 or 2 Mbps, IEEE 802.11b > offers 11 Mbps and IEEE 802.11a offers up to 54 Mbps. > >==> maybe mention 11g as well, because that's getting pretty popular at the >expense of 11a.. > > C. Section 7 stated that current RBE based IPv4 deployment might not > be the best approach for IPv6. The addressing space available gives > the SP the opportunity to separate the users on different subnets. > If however, support is found for a deployment similar to IPv4, > and if the SP chooses to let subscribers talk amongst themselves > directly, then special consideration should be give to the ND > operation at the Edge Router. > >==> this should probably be a bit clearer what is the gap here, and what >would need more work. > > > > > > >editorial >--------- > > As the number of devices per BB users increase exponentially > >==> s/users/user/ ? > > range [RFC 3513] of IPv6. Other benefits of IPV6 include the > >==> s/IPV6/IPv6/ > > IPv6 where possible. Deployment of tunneling solutions are simpler, > easier and more economical to start the IPv6 services, as they > >==> s/are/is/ ? > > At this point IPv6 based services are seen as a differentiator that >... > this year for its ADSL and FTTH subscribers, under the name of ... > network and at this point does not provide connectivity to the > >==> when this doc ages, 'this' may no longer be accurate. > > The Access Provider can deploy a Layer2 network and perform no > >==> s/Layer2/Layer 2/ ? > > core can involve various technologies such as Ethernet, ATM and etc. > >==> remove "and" ? > > C. MPLS 6PE Deployment [6PE]: If the Access Provider is running MPLS > in its IPv4 core it could use 6PE to forward IPv6 traffic over its. > In this case only a subset of routers close to the edge of the > network needs to be IPv6 aware. With this approach BGP becomes > important in order to support 6PE. Its deployment will most likely > leverage the Route Reflector structure used with the IPv4 deployment. > >==> the last sentence seems to be out of scope for this draft, and maybe >should be removed? > > is planed. As an example, 6to4 tunnels do not support IPv6 multicast > >==> s/planed/planned/ > > 1. Bridged CMTS Network > > In this scenario, both the CM and CMTS bridge all data traffic. > Traffic to/from host devices is forwarded through the cable network > to the ER. The ER then routes traffic through the ISP network to the > Internet. The CM and CMTS support some Layer-3 functionality for > management purposes. > >==> would it be easy to indent paragraphs like this by a couple of spaces >(would increase the readability a lot) >==> s/some/a certain degree of/ ? > > Layer-3 next hop. If there is a GWR behind the CM it can acts as a > >==> s/can acts/can act/ (in many places) > > connected to the MSO network for management functions. During the > >==> spell out MSO ? > > Implementation work on CM/CMTS should be minimal because the only > significant difference between IPv4 IGMPv3 and IPv6 MLDv2 are the > longer addresses in the protocol. > >==> "difference" in singular, so s/are/is/ ? > > In today cable networks the CM receives a private IPv4 address > >==> s/today/today's/ (a couple of times) > > Security in a DOCSIS cable network is provided using Baseline Privacy > Plus (BPI+). The only part that is dependent on IP addresses is > encrypted multicast. Semantically, multicast encryption would work > the same way in an IPv6 environment as in the IPv4 network. However, > appropriate enhancements will be needed in the DOCSIS specification > to support encrypted IPv6 multicast. The other aspect of security > enhancement is mandated IPSec support in IPv6. The IPv6 > >==> split to next paragraph at "The other aspect". > > through statefull DHCPv6 [RFC 3315] and stateless DHCPv6 [RFC 3736]. > >==> s/statefull/stateful/ (in very many places) > > and PPPoE [RFC 2516]). The PPP sessions are initiated by Customer > Premise Equipment and it is terminated at the BRAS. The BRAS > >==> sessions ... it is -- singular/plural? > > > The operation of PPPoE is similar to PPPoA with the exception that > with PPPoE multiple session can be supported over the same PVC thus > >==> s/session/sessions/ > > > The PPP session can be initiated by a host or by a Customer Router. > In the later case, once the session is established with the Edge > >==> s/later/latter/ > > It is important to note here a signifcant difference between this > >==> s/signif/signifi/ > >7.2.4.1 IPv4 in LAA Model and IPv6 in PTA Model > > The coexistence of the two PPP based models, PTA and LAA, is > relatively straight forward. It is a straight forward overlap of the > two deployment models. The PPP sessions are terminated on > different network devices for the IPv4 and IPv6 services. > >==> the middle sentence appears to be mostly redundant.. the only novel word >there is "overlap" :) > > Subscribers might use a set-top box that is responsible for the > control piece of the multicast service (does group joins/leaves). > The subscriber hosts can also join desired multicast groups as long > as they are enabled to support MLDv1 or MLDv2. If a customer premise > router is used then it has to be enabled to support MLDv1 and MLDv2 > > in order to process the requests of the hosts. It has to be enabled > to support PIM-SSM in order to send PIM joins/leaves up to its > Layer-3 next hop whether it is the BRAS or the Edge router. When > enabling this functionality on a customer premises router, its > limited resources should be taken into consideration. > > The router that is the Layer-3 next hop for the subscriber (BRAS in > the PTA model or the Edge router in the LAA and Point-to-Point > model) has to be enabled to support MLDv1 and MLDv2 in order to > process the requests coming from subscribers without customer > premises routers. It has to be enabled for PIM-SSM in order to > receive joins/leaves from customer routers and send joins/leaves > to the next hop towards the multicast source (Edge router or the > NSP core). > >==> remove the extra empty line (this happened in a couple of places AFAIR). >==> there appears to be a fair amount of duplication in these paragraphs? > > On the BRAS or the Edge Router the subscriber facing interfaces have > to be configure to police the inbound customer traffic and shape the > >==> s/configure/configured/ > > network management tools that could provide trace-ability of the > >==> s/trace-/trace/ > > +--------+ | +------+ | > +--+Agg E | | > +--------+ |Switch+-+ >+-----+ |Access| +--+ | >|Hosts|--+Switch +-+ +------+ > >==> figure 8.1 is a bit screwed up.. > > In order to maintain the deployment concepts and business models > proven and used with existent revenue generating IPv4 services, > >==> it is questionable how much revenue these BB services generated in >highly competed markets, and it's irrelevant to this draft in any case, so >suggest rewording /existent revenue generating/existing/ > >This deployment > types do not fit in the typical Hot Spot concept but they rather > address fixed customers. > >==> in this kind of document, "address" in this context may be slightly >confusing, so rewording it might be useful. > > > The IETF draft [IPv6 over 802.11] mentions some of the concerns > related to running IPv6 multicast over WLAN links. Potentially > these are same kind of issues when running any Layer3 protocol > over a WLAN link that has a high loss-to-signal ratio, certain > frames that are multicast based are dropped when settings are not > adjusted properly. > >==> s/The/An/ >==> s/certain/where certain/ ? > >[RFC 3041] > T. Narten and R. Draves, "Privacy Extensions for Stateless Address > Autoconfiguration in IPv6," RFC 3041, April 2001. > >==> s/[RFC 3041]/[RFC3041]/ (for consistency) > >[6PE] De Clercq J., et al., "Connecting IPv6 Islands across IPv4 > Clouds with BGP:, draft-ietf-ngtrans-bgp-tunnel-04.txt, July 2002 > >==> the latest version is draft-ooms-v6ops-bgp-tunnel (AFAIR) > > Savola, P. "IPv6 Multicast Deployment Issues", > draft-savola-v6ops-multicast-issues-03.txt, February 2004 > >==> draft-mboned-ipv6-multicast-issues now > >-- >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 Tue Feb 15 03:43: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 DAA06686 for ; Tue, 15 Feb 2005 03:43:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D0yFW-00072W-Rm for v6ops-data@psg.com; Tue, 15 Feb 2005 08:40:02 +0000 Received: from [131.116.28.200] (helo=maild.telia.se) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D0yFN-00071A-T5 for v6ops@ops.ietf.org; Tue, 15 Feb 2005 08:39:54 +0000 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by maild.telia.se with InterScan Messaging Security Suite; Tue, 15 Feb 2005 09:39:21 +0100 Received: from TMS061MB.tcad.telia.se ([131.115.230.181]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Feb 2005 09:39:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: RE: Take ISP BB scenarios as WG document Date: Tue, 15 Feb 2005 09:39:43 +0100 Message-ID: <31ACB1372B7F274B8EDEBF21AD8795A0E05C9D@TMS061MB.tcad.telia.se> Thread-Topic: Take ISP BB scenarios as WG document Thread-Index: AcUMeodhBHDGJUNPQHuZoPDwkWghTgGvNCYg From: To: Cc: , , , , X-OriginalArrivalTime: 15 Feb 2005 08:39:43.0793 (UTC) FILETIME=[E5B67210:01C51339] X-imss-version: 2.019 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:2 C:1 M:3 S:1 R:2 (0.1500 0.1500) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Level: * X-Spam-Status: No, score=1.2 required=5.0 tests=BAYES_00,NO_REAL_NAME, RCVD_IN_DSBL autolearn=no version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, First off I think it is an interesting document and it's good that it = has been taken on as a WG item. What I think it needs is an addition of = emerging broadband scenarios. I'm especially thinking of Ethernet based = broadband networks, LAN or DSL, where neither VLAN/PVC nor PPPoE is = used. This is a rather complicated scenario for introducing IPv6 and as = it still is under development/deployment an IPv6 recommendation would be = very useful.=20 Regards, Mikael ________________________________________ From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On = Behalf Of Salman Asadullah Sent: den 6 februari 2005 19:17 To: Pekka Savola Cc: v6ops@ops.ietf.org; Adeel Ahmed; cpopovic@cisco.com; = sraza@cisco.com; Patrick Grossetete Subject: Re: Take ISP BB scenarios as WG document Hello Pekka & All, We would like to thank you and every one in the work group who have = helped us to make this draft better and finally approving it. We will work on integrating all the new comments/feedback and submit the = next version soon. We would appreciate any more feedback. Regards, Salman At 07:08 PM 2/5/2005 +0200, Pekka Savola wrote: Hi, (co-chair hat on) There seems to be consensus to take this as WG items. Authors, please = submit the next version as = draft-ietf-v6ops-bb-deployment-scenarios-00.txt Thanks, and keep the reviews coming! (hat off) On Fri, 21 Jan 2005, Pekka Savola wrote: (co-chair hat on) The authors have asked if the following document would be adopted as WG = item: "ISP IPv6 Deployment Scenarios in Broadband Access Networks" http://www.ietf.org/internet-drafts/draft-asadullah-v6ops-bb-deployment-s= cenarios-02.txt Please say what you think. Silence DOES NOT indicate consent. If new = work items are to be adopted, there must be active support for doing it, = and there must be people willing to review and work on the draft. The deadline for comments is in 2 weeks, on February 4th. (hat off) --=20 Pekka Savola=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "You each name = yourselves king, yet the Netcore Oy=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 kingdom = bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Feb 15 05:29: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 FAA14769 for ; Tue, 15 Feb 2005 05:29:02 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D0zvj-000KFd-Pd for v6ops-data@psg.com; Tue, 15 Feb 2005 10:27:43 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D0zvc-000KEy-72 for v6ops@ops.ietf.org; Tue, 15 Feb 2005 10:27:36 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1FAQVd17856; Tue, 15 Feb 2005 12:26:31 +0200 Date: Tue, 15 Feb 2005 12:26:31 +0200 (EET) From: Pekka Savola To: Mikael.Lind@teliasonera.com cc: sasad@cisco.com, v6ops@ops.ietf.org, adahmed@cisco.com, cpopovic@cisco.com, sraza@cisco.com, pgrosset@cisco.com Subject: RE: Take ISP BB scenarios as WG document In-Reply-To: <31ACB1372B7F274B8EDEBF21AD8795A0E05C9D@TMS061MB.tcad.telia.se> Message-ID: References: <31ACB1372B7F274B8EDEBF21AD8795A0E05C9D@TMS061MB.tcad.telia.se> 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, On Tue, 15 Feb 2005 Mikael.Lind@teliasonera.com wrote: > What I think it needs is an > addition of emerging broadband scenarios. I'm especially thinking of > Ethernet based broadband networks, LAN or DSL, where neither > VLAN/PVC nor PPPoE is used. This is a rather complicated scenario > for introducing IPv6 and as it still is under development/deployment > an IPv6 recommendation would be very useful. Mikael, I think you'll need to elaborate a bit about this scenario :) -- which scenario/deployment model you have in mind? Has this been deployed with IPv4 yet? -- 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 Tue Feb 15 10:12: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 KAA09611 for ; Tue, 15 Feb 2005 10:12:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D14Ks-00030h-CD for v6ops-data@psg.com; Tue, 15 Feb 2005 15:09:58 +0000 Received: from [131.116.28.200] (helo=maild.telia.se) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D14Kn-00030B-N6 for v6ops@ops.ietf.org; Tue, 15 Feb 2005 15:09:54 +0000 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by maild.telia.se with InterScan Messaging Security Suite; Tue, 15 Feb 2005 16:09:11 +0100 Received: from TMS061MB.tcad.telia.se ([131.115.230.181]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Feb 2005 16:09:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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: Take ISP BB scenarios as WG document Date: Tue, 15 Feb 2005 16:09:33 +0100 Message-ID: <31ACB1372B7F274B8EDEBF21AD8795A0E05D45@TMS061MB.tcad.telia.se> Thread-Topic: Take ISP BB scenarios as WG document Thread-Index: AcUTSNFhYnfycD35SXWv6THs48CzzQAI9cBg From: To: Cc: , , , , , X-OriginalArrivalTime: 15 Feb 2005 15:09:33.0423 (UTC) FILETIME=[5B04BFF0:01C51370] X-imss-version: 2.019 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:2 C:1 M:3 S:1 R:2 (0.1500 0.1500) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Pekka, What I'm referring to is access networks where DHCP snooping and IP filters in the first access switch are the main anti spoofing mechanisms and where there is no logical separation between customers. This requires IP awareness further out in the network and therefore IPv6 support is needed as well. The scenario is similar to the example 2 in 8.2 in the isp scenarios-analysis document. I know this doesn't describe it very well but I'm willing to provide input to the BB scenarios document if needed.=20 =20 Yes it has been deployed in IPv4 and seems to be picking up as an access network design offered by many different vendors.=20 /Mikael >=20 > Hi, >=20 > On Tue, 15 Feb 2005 Mikael.Lind@teliasonera.com wrote: > > What I think it needs is an > > addition of emerging broadband scenarios. I'm especially thinking of > > Ethernet based broadband networks, LAN or DSL, where neither > > VLAN/PVC nor PPPoE is used. This is a rather complicated scenario > > for introducing IPv6 and as it still is under development/deployment > > an IPv6 recommendation would be very useful. >=20 > Mikael, I think you'll need to elaborate a bit about this scenario :) > -- which scenario/deployment model you have in mind? Has this been > deployed with IPv4 yet? >=20 From owner-v6ops@ops.ietf.org Tue Feb 15 10:33: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 KAA14253 for ; Tue, 15 Feb 2005 10:33:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D14hR-00067s-8w for v6ops-data@psg.com; Tue, 15 Feb 2005 15:33:17 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D14hP-00067U-P7 for v6ops@ops.ietf.org; Tue, 15 Feb 2005 15:33:16 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14021; Tue, 15 Feb 2005 10:33:11 -0500 (EST) Message-Id: <200502151533.KAA14021@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-00.txt Date: Tue, 15 Feb 2005 10:33:10 -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=AWL,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-00.txt Pages : 0 Date : 2005-2-14 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-00.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-00.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-00.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-2-15103747.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-bb-deployment-scenarios-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-bb-deployment-scenarios-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-15103747.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Tue Feb 15 11:04: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 LAA24765 for ; Tue, 15 Feb 2005 11:04:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D15BO-000BjK-6L for v6ops-data@psg.com; Tue, 15 Feb 2005 16:04:14 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D15BI-000BiY-W8 for v6ops@ops.ietf.org; Tue, 15 Feb 2005 16:04:09 +0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 15 Feb 2005 08:04:28 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from sasad-w2k01.cisco.com (sjc-vpn2-436.cisco.com [10.21.113.180]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j1FG44wO015074; Tue, 15 Feb 2005 08:04:05 -0800 (PST) Message-Id: <4.3.2.7.2.20050215080052.02868e68@ce-nfs-1.cisco.com> X-Sender: sasad@ce-nfs-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Feb 2005 08:04:04 -0800 To: From: Salman Asadullah Subject: RE: Take ISP BB scenarios as WG document Cc: , , , , , In-Reply-To: <31ACB1372B7F274B8EDEBF21AD8795A0E05D45@TMS061MB.tcad.telia .se> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_683229001==_.ALT" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 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 --=====================_683229001==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 04:09 PM 2/15/2005 +0100, Mikael.Lind@teliasonera.com wrote: >Hi Pekka, >What I'm referring to is access networks where DHCP snooping and IP >filters in the first access switch are the main anti spoofing mechanisms >and where there is no logical separation between customers. This >requires IP awareness further out in the network and therefore IPv6 >support is needed as well. The scenario is similar to the example 2 in >8.2 in the isp scenarios-analysis document. I know this doesn't describe >it very well but I'm willing to provide input to the BB scenarios >document if needed. Hello Mikael, We would love to work with you to understand the further details and include it in the next revision of this IETF draft if needed. Regards, Salman > >Yes it has been deployed in IPv4 and seems to be picking up as an access >network design offered by many different vendors. > >/Mikael > > > > > Hi, > > > > On Tue, 15 Feb 2005 Mikael.Lind@teliasonera.com wrote: > > > What I think it needs is an > > > addition of emerging broadband scenarios. I'm especially thinking of > > > Ethernet based broadband networks, LAN or DSL, where neither > > > VLAN/PVC nor PPPoE is used. This is a rather complicated scenario > > > for introducing IPv6 and as it still is under development/deployment > > > an IPv6 recommendation would be very useful. > > > > Mikael, I think you'll need to elaborate a bit about this scenario :) > > -- which scenario/deployment model you have in mind? Has this been > > deployed with IPv4 yet? > > --=====================_683229001==_.ALT Content-Type: text/html; charset="us-ascii"
At 04:09 PM 2/15/2005 +0100, Mikael.Lind@teliasonera.com wrote:
Hi Pekka,
What I'm referring to is access networks where DHCP snooping and IP
filters in the first access switch are the main anti spoofing mechanisms
and where there is no logical separation between customers. This
requires IP awareness further out in the network and therefore IPv6
support is needed as well. The scenario is similar to the example 2 in
8.2 in the isp scenarios-analysis document. I know this doesn't describe
it very well but I'm willing to provide input to the BB scenarios
document if needed.

Hello Mikael,

We would love to work with you to understand the further details and include it in the next revision of this IETF draft if needed.

Regards,
Salman


 
Yes it has been deployed in IPv4 and seems to be picking up as an access
network design offered by many different vendors.

/Mikael

>
> Hi,
>
> On Tue, 15 Feb 2005 Mikael.Lind@teliasonera.com wrote:
> > What I think it needs is an
> > addition of emerging broadband scenarios. I'm especially thinking of
> > Ethernet based broadband networks, LAN or DSL, where neither
> > VLAN/PVC nor PPPoE is used. This is a rather complicated scenario
> > for introducing IPv6 and as it still is under development/deployment
> > an IPv6 recommendation would be very useful.
>
> Mikael, I think you'll need to elaborate a bit about this scenario :)
> -- which scenario/deployment model you have in mind? Has this been
> deployed with IPv4 yet?
>
--=====================_683229001==_.ALT-- From owner-v6ops@ops.ietf.org Fri Feb 18 15:13: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 PAA06401 for ; Fri, 18 Feb 2005 15:13:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2ERP-000Ok3-LZ for v6ops-data@psg.com; Fri, 18 Feb 2005 20:09:31 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2ERE-000Og6-E3 for v6ops@ops.ietf.org; Fri, 18 Feb 2005 20:09:20 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1IK9Eh02388; Fri, 18 Feb 2005 22:09:14 +0200 Date: Fri, 18 Feb 2005 22:09:14 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: jonne.soininen@nokia.com Subject: very drafty v6ops agenda for IETF62 Message-ID: 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, (co-chair hat on) Here's a very drafty agenda for the next IETF meeting. Requests for agenda items, etc. are still welcome. Especially if there are operational topics to bring up or discuss, it would be interesting to hear proposals. Please contanct chairs off-list. (hat off) ... Wednesday 9th March -- 0900-1130 ================================ (The date & time is still tentative.) Introduction, agenda bashing, document status - 5 mins, Chairs/Savola - Scribes! (Jabber also?) Enterprise Analysis Discussion, 15 mins, Bound(?) - draft-ietf-v6ops-ent-analysis-01.txt (or a revision?) - GOAL: discuss issues and the path forward 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 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 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 ISP IPv6 Deployment Scenarios in Broadband Access Networks, 15 mins, Popoviciu(?) - draft-ietf-v6ops-bb-deployment-scanarios-00.txt - GOAL: discuss changes and future direction; prepare for WG LC after 1-2 revisions 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 Things to think about when renumbering, 10 mins, Thompson (?) - draft-chown-v6ops-renumber-thinkabout-01.txt (to be submitted) - GOAL: introduce the draft, solicit feedback for next revision 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 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. -END- From owner-v6ops@ops.ietf.org Fri Feb 18 16:08: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 QAA15699 for ; Fri, 18 Feb 2005 16:08:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2FLY-000COe-2P for v6ops-data@psg.com; Fri, 18 Feb 2005 21:07:32 +0000 Received: from [66.93.39.75] (helo=smtp-e.tycool.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2FLX-000COQ-8z for v6ops@ops.ietf.org; Fri, 18 Feb 2005 21:07:31 +0000 Received: from [192.168.1.100] (unknown [192.168.1.100]) by smtp-e.tycool.net (Postfix) with ESMTP id 03C75C; Fri, 18 Feb 2005 13:08:32 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <62457852804ba3dc7e6849c410ab43cd@tycool.net> Content-Transfer-Encoding: 7bit Cc: jonne.soininen@nokia.com, v6ops@ops.ietf.org From: Alain Durand Subject: Re: very drafty v6ops agenda for IETF62 Date: Fri, 18 Feb 2005 13:07:30 -0800 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=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Feb 18, 2005, at 12:09 PM, Pekka Savola wrote: > Hi, > > (co-chair hat on) > > Here's a very drafty agenda for the next IETF meeting. Requests for > agenda items, etc. are still welcome. > > Especially if there are operational topics to bring up or discuss, it > would be interesting to hear proposals. Please contanct chairs > off-list. > > (hat off) I would like to see some time on the agenda to discuss what to do with the following drafts: draft-ietf-v6ops-v6onbydefault-03.txt draft-ietf-v6ops-onlinkassumption-02.txt - Alain. From owner-v6ops@ops.ietf.org Sun Feb 20 09:59:00 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08083 for ; Sun, 20 Feb 2005 09:59:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2sTg-0006Ec-9j for v6ops-data@psg.com; Sun, 20 Feb 2005 14:54:32 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2sTf-0006EK-8b for v6ops@ops.ietf.org; Sun, 20 Feb 2005 14:54:31 +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 j1KEsTi3007672 for ; Sun, 20 Feb 2005 14:54:29 GMT 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 OAA04232 for ; Sun, 20 Feb 2005 14:54:24 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j1KEsO826481 for v6ops@ops.ietf.org; Sun, 20 Feb 2005 14:54:24 GMT Date: Sun, 20 Feb 2005 14:54:24 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: very drafty v6ops agenda for IETF62 Message-ID: <20050220145424.GD26238@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <62457852804ba3dc7e6849c410ab43cd@tycool.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <62457852804ba3dc7e6849c410ab43cd@tycool.net> 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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, Feb 18, 2005 at 01:07:30PM -0800, Alain Durand wrote: > > I would like to see some time on the agenda to discuss what to do with > the following drafts: > draft-ietf-v6ops-v6onbydefault-03.txt > draft-ietf-v6ops-onlinkassumption-02.txt This would seem valuable. -- Tim From owner-v6ops@ops.ietf.org Tue Feb 22 02:48: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 CAA20950 for ; Tue, 22 Feb 2005 02:48:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3Ujy-0009uo-TE for v6ops-data@psg.com; Tue, 22 Feb 2005 07:45:54 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3Ujv-0009tS-PJ for v6ops@ops.ietf.org; Tue, 22 Feb 2005 07:45:52 +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 md50000800253.msg for ; Tue, 22 Feb 2005 08:47:31 +0100 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 22 Feb 2005 08:45:43 +0100 Subject: RV:I-D ACTION:draft-palet-v6ops-ipv6security-02.txt From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: In-Reply-To: <200502212036.PAA12643@ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable 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, Tue, 22 Feb 2005 08:47:32 +0100 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=AWL,BAYES_00, MIME_QP_LONG_LINE,RCVD_IN_SORBS_WEB,TO_ADDRESS_EQ_REAL autolearn=no version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable FYI. Inputs welcome. Regards, Jordi ------ Mensaje reenviado De: "Internet-Drafts@ietf.org" Responder a: "Internet-Drafts@ietf.org" Fecha: Mon, 21 Feb 2005 15:36:07 -0500 Para: Asunto: I-D ACTION:draft-palet-v6ops-ipv6security-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 distributed security requirements Author(s) : J. Palet, et al. Filename : draft-palet-v6ops-ipv6security-02.txt Pages : 14 Date : 2005-2-21 =20 The security policies currently applied in Internet with IPv4, doesn=C6t longer apply for end-to-end security models which IPv6 will enable.=20 Today, each network is often secured by a unique device (i.e. security gateway or firewall), that becomes a bottleneck for the end- to-end security model with IPv6. In addition, users and devices start to be nomadic, moving between different networks that could have different security policies. A distributed and dynamic approach is consequently required, as already described by [1]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-palet-v6ops-ipv6security-02.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. =20 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-palet-v6ops-ipv6security-02.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-palet-v6ops-ipv6security-02.txt". =20 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. =20 =20 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2005-2-21151545.I-D@ietf.org> _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------ Fin del mensaje reenviado ************************************ Barcelona 2005 Global IPv6 Summit Call for Papers and 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 Feb 22 02:48: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 CAA20975 for ; Tue, 22 Feb 2005 02:48:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3Ukb-0009yA-AO for v6ops-data@psg.com; Tue, 22 Feb 2005 07:46:33 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3UkZ-0009xw-NQ for v6ops@ops.ietf.org; Tue, 22 Feb 2005 07:46: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 md50000800258.msg for ; Tue, 22 Feb 2005 08:48:11 +0100 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 22 Feb 2005 08:46:21 +0100 Subject: RV:I-D ACTION:draft-vives-v6ops-ipv6-security-ps-03.txt From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: In-Reply-To: <200502212036.PAA12663@ietf.org> 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, Tue, 22 Feb 2005 08:48:13 +0100 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, RCVD_IN_SORBS_WEB,TO_ADDRESS_EQ_REAL autolearn=no version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit FYI. Inputs welcome. Regards, Jordi ------ Mensaje reenviado De: "Internet-Drafts@ietf.org" Responder a: "Internet-Drafts@ietf.org" Fecha: Mon, 21 Feb 2005 15:36:28 -0500 Para: Asunto: I-D ACTION:draft-vives-v6ops-ipv6-security-ps-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Security Problem Statement Author(s) : A. Vives, et al. Filename : draft-vives-v6ops-ipv6-security-ps-03.txt Pages : 19 Date : 2005-2-21 Today, each network is often secured by a unique device (i.e. security gateway or firewall) that becomes a bottleneck for the end-to-end security model with IPv6. The deployment of IPv6 enabled devices and networks bring some issues, which must be addressed by security administrators in order to guarantee at least the same level of security that is obtained nowadays with IPv4 and network-based (including perimetral-based) security schemes, allowing at the same time all the IPv6 advantages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vives-v6ops-ipv6-security-ps-03.tx t 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-vives-v6ops-ipv6-security-ps-03.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-vives-v6ops-ipv6-security-ps-03.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. Content-Type: text/plain Content-ID: <2005-2-21151551.I-D@ietf.org> _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------ Fin del mensaje reenviado ************************************ Barcelona 2005 Global IPv6 Summit Call for Papers and 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 Wed Feb 23 11:29:38 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05721 for ; Wed, 23 Feb 2005 11:29:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3zM4-000FzB-6C for v6ops-data@psg.com; Wed, 23 Feb 2005 16:27:16 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3zM2-000Fyx-5u for v6ops@ops.ietf.org; Wed, 23 Feb 2005 16:27:14 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1NGRCw02400; Wed, 23 Feb 2005 18:27:12 +0200 Date: Wed, 23 Feb 2005 18:27:12 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: jonne.soininen@nokia.com Subject: Re: very drafty v6ops agenda for IETF62 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 Hi, (Bcc:ing agenda@ietf.org.) On Fri, 18 Feb 2005, Pekka Savola wrote: > (co-chair hat on) > > Here's a very drafty agenda for the next IETF meeting. Requests for agenda > items, etc. are still welcome. > > Especially if there are operational topics to bring up or discuss, it would > be interesting to hear proposals. Please contanct chairs off-list. > > (hat off) Attached is the draft agenda for v6ops -- two additions. Updates are still possible. * DRAFT * DRAFT * DRAFT * Wednesday 9th March -- 0900-1130 ================================ (The date & time is still tentative.) Introduction, agenda bashing, document status - 5 mins, Chairs/Savola - Scribes! (Jabber also?) Enterprise Analysis Discussion, 15 mins, Bound(?) - draft-ietf-v6ops-ent-analysis-01.txt (or a revision?) - GOAL: discuss issues and the path forward 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 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 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 ISP IPv6 Deployment Scenarios in Broadband Access Networks, 15 mins, Popoviciu(?) - draft-ietf-v6ops-bb-deployment-scanarios-00.txt - GOAL: discuss changes and future direction; prepare for WG LC after 1-2 revisions 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 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 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 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 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. 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 From owner-v6ops@ops.ietf.org Sun Feb 27 11:14: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 LAA09557 for ; Sun, 27 Feb 2005 11:14:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5R0z-000DtS-6D for v6ops-data@psg.com; Sun, 27 Feb 2005 16:11:29 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5R0v-000Dt7-Te for v6ops@ops.ietf.org; Sun, 27 Feb 2005 16:11:26 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1RGBO007029; Sun, 27 Feb 2005 18:11:24 +0200 Date: Sun, 27 Feb 2005 18:11:23 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: v6ops agenda for IETF62 Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-534936762-1109520683=:6956" 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 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1589707168-534936762-1109520683=:6956 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Hi, (agenda@ietf.org bcc:'ed) Attached is a pretty much final agenda for IETF62, until something comes up at the last minute. --1589707168-534936762-1109520683=:6956 Content-Type: TEXT/plain; charset=US-ASCII; name="v6ops-agenda.txt" Content-ID: Content-Description: Content-Disposition: attachment; filename="v6ops-agenda.txt" Content-Transfer-Encoding: BASE64 V2VkbmVzZGF5IDl0aCBNYXJjaCAtLSAwOTAwLTExMzANCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09DQoNCkludHJvZHVjdGlvbiwgYWdlbmRh IGJhc2hpbmcsIGRvY3VtZW50IHN0YXR1cyAtIDUgbWlucywgQ2hhaXJzL1Nh dm9sYQ0KICAtIFNjcmliZXMhIChKYWJiZXIgYWxzbz8pDQoNCkNoYXJ0ZXIg RGlzY3Vzc2lvbiAtIDIwIG1pbnMsIENoYWlycy9XRw0KIC0gZGlzY3VzcyB0 aGUgcGVuZGluZyBjaGFydGVyIHVwZGF0ZSwgaWYgbm90IGZpbmFsaXplZCB5 ZXQNCiAtIEdPQUw6IGRpc2N1c3MgdGhlIHNjb3BlIG9mIHY2b3BzIFdHIHdv cms7IGdhaW4gY29uc2Vuc3VzIG9uIHRoZSB3YXkgZm9yd2FyZA0KDQpFbnRl cnByaXNlIEFuYWx5c2lzIERpc2N1c3Npb24sIDE1IG1pbnMsIEJvdW5kKD8p DQogLSBkcmFmdC1pZXRmLXY2b3BzLWVudC1hbmFseXNpcy0wMS50eHQgKG9y IGEgcmV2aXNpb24/KQ0KIC0gR09BTDogZGlzY3VzcyBpc3N1ZXMgYW5kIHRo ZSBwYXRoIGZvcndhcmQNCg0KUmVhc29ucyB0byBjbGFzc2lmeSBOQVQtUFQg dG8gRXhwZXJpbWVudGFsLCAxMCBtaW5zLCBEYXZpZXMNCiAtIGRyYWZ0LWll dGYtdjZvcHMtbmF0cHQtdG8tZXhwcm1udGwtMDAudHh0IA0KIC0gR09BTDog ZGlzY3VzcyBjaGFuZ2VzLCBzb2xpY2l0IGNvbW1lbnRzIGJlZm9yZSBnb2lu ZyBmb3IgV0cgTEMNCg0KSVNQIElQdjYgRGVwbG95bWVudCBTY2VuYXJpb3Mg aW4gQnJvYWRiYW5kIEFjY2VzcyBOZXR3b3JrcywgMTUgbWlucywgUG9wb3Zp Y2l1KD8pDQogLSBkcmFmdC1pZXRmLXY2b3BzLWJiLWRlcGxveW1lbnQtc2Nl bmFyaW9zLTAwLnR4dA0KIC0gR09BTDogZGlzY3VzcyBjaGFuZ2VzIGFuZCBm dXR1cmUgZGlyZWN0aW9uOyBwcmVwYXJlIGZvciBXRyBMQyBhZnRlciAxLTIN CiAgIHJldmlzaW9ucw0KDQpVcGRhdGVzIG9uIHRoZSBJUHY2IEZpeCBQcm9q ZWN0LCA1LTEwIG1pbnMsIEppbm1laQ0KIC0gaHR0cDovL3Y2Zml4Lm5ldC93 aWRlLWRyYWZ0LXY2Zml4LWVuDQogLSBHT0FMOiBzaGFyZSB0aGUgcmVzdWx0 cyBvZiByZWNlbnQgZXhwZXJpbWVudHMsIGRpc2N1c3MgbmV4dCBzdGVwcw0K DQpTdGF0dXMgYW5kIGdvaW5nIGZvcndhcmQgd2l0aCBJUHY2LW9uLWJ5LURl ZmF1bHQgd29yaywgNS0xMCBtaW5zLCBDaGFpcnMvU2F2b2xhDQogLSBkcmFm dC1pZXRmLXY2b3BzLXY2b25ieWRlZmF1bHQtMDMudHh0DQogLSBkcmFmdC1p ZXRmLXY2b3BzLW9ubGlua2Fzc3VtcHRpb24tMDIudHh0DQogLSBHT0FMOiBk aXNjdXNzIHRoZSBvcHRpb25zIGhvdyB0byBtb3ZlIGZvcndhcmQNCg0KSVB2 NiBOZXR3b3JrIEFyY2hpdGVjdHVyZSBQcm90ZWN0aW9uLCAxMC0xNSBtaW5z LCBWYW4gZGUgVmVsZGUoPykNCiAtIGRyYWZ0LXZhbmRldmVsZGUtdjZvcHMt bmFwLTAxLnR4dA0KIC0gR09BTDogZGlzY3VzcyBjaGFuZ2VzIGFuZCB0aGUg YXBwcm9hY2g7IGFzayBmb3IgV0cgaXRlbSBhZG9wdGlvbg0KDQpIb3cgdG8g c2VjdXJlIGRyYWZ0LWlldGYtdjZvcHMtbWVjaC12MiB0dW5uZWwgd2l0aCBJ UHNlYywgMTAgbWlucywgVHNjaG9mZW5pZyg/KQ0KIC0gZHJhZnQtdHNjaG9m ZW5pZy12Nm9wcy1zZWN1cmUtdHVubmVscy0wMy50eHQgKG9yIHJldmlzZWQp IA0KIC0gR09BTDogZGlzY3VzcyBjaGFuZ2VzLCBzb2xpY2l0IGZlZWRiYWNr OyBhc2sgZm9yIFdHIGFkb3B0aW9uDQoNClRoaW5ncyB0byB0aGluayBhYm91 dCB3aGVuIHJlbnVtYmVyaW5nLCAxMCBtaW5zLCBDaG93bg0KIC0gZHJhZnQt Y2hvd24tdjZvcHMtcmVudW1iZXItdGhpbmthYm91dC0wMS50eHQgKHRvIGJl IHN1Ym1pdHRlZCkNCiAtIEdPQUw6IGludHJvZHVjZSB0aGUgZHJhZnQsIHNv bGljaXQgZmVlZGJhY2sgZm9yIG5leHQgcmV2aXNpb24NCg0KSVB2NiBTZWN1 cml0eSBPdmVydmlldyAtIDUtNyBtaW5zLCBEYXZpZXMNCiAtIGRyYWZ0LXNh dm9sYS12Nm9wcy1zZWN1cml0eS1vdmVydmlldy0wMy50eHQNCiAtIEdPQUw6 IHRhbGsgYWJvdXQgZGlmZmVyZW5jZXMsIHNvbGljaXQgbW9yZSBmZWVkYmFj azsgYXNrIGZvciBXRyBhZG9wdGlvbg0KDQpWTEFOIHVzYWdlIGZvciB0cmFu c2l0aW9uLCA1IG1pbnMsIENob3duDQogLSBkcmFmdC1jaG93bi12Nm9wcy12 bGFuLXVzYWdlLTAyLnR4dA0KICAgKHRoaXMgaXMgYWxyZWFkeSBhIFdHIGl0 ZW0sIGp1c3Qgbm90IHJlc3VibWl0dGVkIHlldCkNCiAtIEdPQUw6IGRpc2N1 c3MgaXNzdWVzLCBpZiBhbnk7IHNvbGljaXQgZmVlZGJhY2suICBQcmVwYXJl IGZvciBXRyBMQyBzb29uLg0KDQpJUHY2IERpc3RyaWJ1dGVkIFNlY3VyaXR5 IFByb2JsZW0gc3RhdGVtZW50LCA1IG1pbnMsIFBhbGV0DQogLSBkcmFmdC12 aXZlcy12Nm9wcy1pcHY2LXNlY3VyaXR5LXBzLTAzLnR4dA0KIC0gR09BTDog YWxlcnQgdGhlIFdHIHRvIHRoZSB1cGRhdGVkIGRyYWZ0IGFuZCBzb2xpY2l0 IGZlZWRiYWNrDQo= --1589707168-534936762-1109520683=:6956-- From owner-v6ops@ops.ietf.org Sun Feb 27 14:38: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 OAA24998 for ; Sun, 27 Feb 2005 14:38:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5UDE-000CeF-CN for v6ops-data@psg.com; Sun, 27 Feb 2005 19:36:20 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5UDC-000Cdu-5u for v6ops@ops.ietf.org; Sun, 27 Feb 2005 19:36:18 +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 md50000813143.msg for ; Sun, 27 Feb 2005 20:38:05 +0100 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sun, 27 Feb 2005 20:35:47 +0100 Subject: RV:Call for Papers - Next Global IPv6 Summit in Spain From: JORDI PALET MARTINEZ To: "ietf@ietf.org" , "v6ops@ops.ietf.org" , "ipv6@ietf.org" , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable 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, 27 Feb 2005 20:38:10 +0100 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_50, MIME_QP_LONG_LINE,RCVD_IN_SORBS_WEB autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, Several people requested an extension of the deadline for the submission of the short abstracts for their presentations. So we decided to extend the deadline until midnight of March 4th. Please make sure to not miss it this time. We only require a title for your presentation and 3-4 lines short abstract. The final agenda will be announced at the end of the following week. Regards, Jordi Hi all, As indicated in the email below, the next Global IPv6 Summit in Spain, the bigger IPv6 European event, in its 4th edition (after a very successful organization and broad international attendance in 2001, 2002 and 2003), will be organized this time in Barcelona, next June 2005, with a expected audience over 2.600 key decisions makers from ICT sectors. The main target of the event is business oriented talks, as well as talks oriented to policy makers, information/knowledge society, education and public sectors. This Call for Papers doesn't require that you submit a complete paper (which is welcome also), but instead, a short plain text abstract of your presentation topic, by email. Talks regarding deployment experiences, new services and applications will be of key interest for the expected attendance, and hence highly encouraged. We believe that key topics will be also those regarding: 1) IPv6 and business 2) IPv6 and Broadband 3) New IPv6-based services and applications 4) IPv6 and the Digital Home 5) IPv6 and Multimedia, Voice/Video applications 6) IPv6, Mobility, Wireless and 3G 7) IPv6 and Ambient Intelligence/Ubiquitous Computing/Distributed Systems 8) IPv6 and GRIDs 9) IPv6 and logistics, transport and eSafety 10) IPv6 for eHealth, eGoverment, eLearning and other "e-whatever" 11) IPv6 and gamming 12) IPv6 and peer-to-peer 13) IPv6 and security 14) IPv6 and Open Source 15) IPv6 and marketing/branding Also topics regarding Standards, Research, Development and Innovation experiences are welcome, including R&D projects results. The Agenda will be drafted early in March, so the dead-line for submitting your topic is only until 25th February, but as said only a short abstract is required. If you're interested in participating, or you have any special idea, even if your topic is not in the list above, please don't hesitate to contact me (jordi.palet@consulintel.es) ASAP, so we can work out any options. Regards, Jordi PS: Please, feel free to circulate this email among your contacts. ------ Mensaje reenviado De: JORDI PALET MARTINEZ Responder a: Fecha: Mon, 07 Feb 2005 18:25:42 +0100 Para: "members@ipv6forum.com" , Asunto: Next Global IPv6 Summit in Spain Hi all, As I already informed a few weeks ago, the next Global IPv6 Summit in Spain will be held this time in Barcelona next June (instead of Madrid in March as previously forecasted). This will happen starting on June 6th, with a tutorial in the morning, the opening ceremony in the afternoon, with some keynotes and then 2-3 days of IPv6 conference, depending on the success of the call for papers. If required we can extend our event up to Friday 10th (total 4 days, plus opening ceremony, plus half day tutorial). In this occasion, we will try a completely new model, integrating the IPv6 conference in a bigger event, more business oriented, even when technical sessions will be still present. The "umbrella" event is Internet Global Congress (IGC), with has been organized in Barcelona already during the 6 previous years. The Internet Global Congress, the leading Internet and New Technologies congress in Spain, is organized by the Fundaci=F3 Barcelona Digital, a non-profit organization, which also provides space for exhibition and delivers the IGC awards for Digital Innovation (aimed to students and professionals with embryonic Internet projects, aims to be a launch platform for all those people involved in research and innovation in the field of Internet and the New Technologies). IGC provides us all the infrastructure for organizing the Global IPv6 Summit track, and we only need to manage our own agenda, and consequently our own call for papers (see next email). They also they care about all the issues related to registration, proceedings and publicity, at no cost for us. We expect that this will be the bigger IPv6 event in Europe during 2005, with an expected attendance over 2.600 people, which of course, will be able to attend not just to the IPv6 track but also to other IT tracks (already depicted at http://www.igcweb.net, then click at Program). The attendance is mainly CTOs, CEOs and other key decision makers related to ICT, so its a very nice opportunity for IPv6 in Europe to meet a large audience which probably has not been in touch with IPv6 until now. I count with the support from all of you, and please do not hesitate to let me know any ideas that you may have to make an even more successful event that what for sure we will have in a so nice city as Barcelona. More information will be soon available at http://www.ipv6-es.com and http://www.igcweb.net. Regards, Jordi ------ Fin del mensaje reenviado ************************************ Barcelona 2005 Global IPv6 Summit Call for Papers and 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.