From owner-v6ops@ops.ietf.org Mon Jan 3 08:57:17 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28557 for ; Mon, 3 Jan 2005 08:57:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1ClSeQ-000MCI-Fg for v6ops-data@psg.com; Mon, 03 Jan 2005 13:53:38 +0000 Received: from [131.228.20.22] (helo=mgw-x2.nokia.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1ClSeM-000MBZ-4k for v6ops@ops.ietf.org; Mon, 03 Jan 2005 13:53:34 +0000 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j03DrVq12481; Mon, 3 Jan 2005 15:53:32 +0200 (EET) X-Scanned: Mon, 3 Jan 2005 15:53:22 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j03DrMAM017219; Mon, 3 Jan 2005 15:53:22 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00A8sUgm; Mon, 03 Jan 2005 15:53:20 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j03DrJU27246; Mon, 3 Jan 2005 15:53:19 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 3 Jan 2005 15:53:16 +0200 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 3 Jan 2005 15:53:17 +0200 Received: ESEBE054.noe.nokia.com 172.21.143.44 from 172.21.154.154 172.21.154.154 via HTTP with MS-WebStorage 6.0.6249 Received: from essrv103nok154154.ntc.nokia.com by ESEBE054.noe.nokia.com; 03 Jan 2005 15:53:16 +0200 Subject: Interest to have as an WG item: draft-tschofenig-v6ops-secure-tunnels-03.txt From: "Soininen Jonne (Nokia-NET/Helsinki)" To: ext Pekka Savola Cc: v6ops@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1104760395.4819.244.camel@essrv103nok154154.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 03 Jan 2005 15:53:15 +0200 X-OriginalArrivalTime: 03 Jan 2005 13:53:17.0580 (UTC) FILETIME=[93D744C0:01C4F19B] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_40 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello v6ops WG, first of all, happy new year to everybody, and it is time to get back to work. (Chair hat on) The authors of draft-tschofenig-v6ops-secure-tunnels have requested the draft to be adopted as a WG item. I would like to give two (2) weeks of time for the discussion, putting the deadline to 18.1.2005. The draft can be found at http://www.ietf.org/internet-drafts/draft-tschofenig-v6ops-secure-tunnels-03.txt (Chair hat off) Cheers, Jonne -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Mon Jan 3 11:42:46 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12092 for ; Mon, 3 Jan 2005 11:42:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1ClVFc-000DDh-Be for v6ops-data@psg.com; Mon, 03 Jan 2005 16:40:12 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1ClVFU-000DCS-SP for v6ops@ops.ietf.org; Mon, 03 Jan 2005 16:40:05 +0000 Received: from [10.10.10.101] ([217.126.187.160]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000688455.msg for ; Mon, 03 Jan 2005 17:40:03 +0100 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 03 Jan 2005 17:39:30 +0100 Subject: Re:Interest to have as an WG item: draft-tschofenig-v6ops-secure-tunnels-03.txt From: JORDI PALET MARTINEZ To: Message-ID: In-Reply-To: <1104760395.4819.244.camel@essrv103nok154154.ntc.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Mon, 03 Jan 2005 17:40:29 +0100 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,RCVD_IN_SORBS_WEB autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Jonne, I'm ok with this document being accepted as WG item. I will suggest a couple of changes: 1) There are several mentions to 6-over-4 and IPv6-over-IPv4 or similar (including the document title !), which should be 6-in-4/IPv6-in-IPv4, to avoid confusion between 6in4 and 6over4. 2) A minor one, there are several places in the document where all-upper case is used for referring to both IPv4 and IPv6. I think it will be better to use the normal casing (IPv4 and IPv6 instead of IPV4 and IPV6), specially to be consistent across all the document. A more substantial comment, not negative to this document, but the WG process itself, which is demonstrated by your question to the WG on getting this document accepted as WG item. Is once more very funny and unfair that getting a document as WG item or not is a closed thing, instead of an open procedure for any author when the work is clearly in the scope of the charter. I still remember that there was a decision, not clear for me and which I don't agree at all, 2 or 3 IETF meetings ago, by which all the work was put "on-hold" and no more work accepted as WG item. Clearly, now this has been changed, so I understand that the fair way to go now, will be that the rest of the authors can ask the same question on those documents that are within the charter scope. Right ? Regards, Jordi > De: "Soininen Jonne (Nokia-NET/Helsinki)" > Responder a: > Fecha: Mon, 03 Jan 2005 15:53:15 +0200 > Para: ext Pekka Savola > CC: > Asunto: Interest to have as an WG item: > draft-tschofenig-v6ops-secure-tunnels-03.txt > > Hello v6ops WG, > > first of all, happy new year to everybody, and it is time to get back to > work. > > (Chair hat on) > The authors of draft-tschofenig-v6ops-secure-tunnels have requested the > draft to be adopted as a WG item. I would like to give two (2) weeks of > time for the discussion, putting the deadline to 18.1.2005. > > The draft can be found at > http://www.ietf.org/internet-drafts/draft-tschofenig-v6ops-secure-tunnels-03.t > xt > > (Chair hat off) > > Cheers, > > Jonne > > > -- > Jonne Soininen > Nokia > > Tel: +358 40 527 46 34 > E-mail: jonne.soininen@nokia.com > ********************************** 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 Thu Jan 6 21:49:41 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20554 for ; Thu, 6 Jan 2005 21:49:41 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cmk9A-0004NW-EG for v6ops-data@psg.com; Fri, 07 Jan 2005 02:46:40 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cmk96-0004Kp-NP for v6ops@ops.ietf.org; Fri, 07 Jan 2005 02:46:37 +0000 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j072kVg25419 for ; Fri, 7 Jan 2005 04:46:35 +0200 (EET) X-Scanned: Fri, 7 Jan 2005 04:46:03 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j072k3oq009402 for ; Fri, 7 Jan 2005 04:46:03 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00CP9GtZ; Fri, 07 Jan 2005 04:46:01 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j072k0U09921 for ; Fri, 7 Jan 2005 04:46:00 +0200 (EET) Received: from dadhcp-172019068136.americas.nokia.com ([172.19.68.138]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 7 Jan 2005 04:45:56 +0200 Received: from dadhcp-172019068136.americas.nokia.com (localhost.localdomain [127.0.0.1]) by dadhcp-172019068136.americas.nokia.com (8.12.11/8.12.11) with ESMTP id j072jtKu022676 for ; Thu, 6 Jan 2005 18:45:55 -0800 Received: (from david@localhost) by dadhcp-172019068136.americas.nokia.com (8.12.11/8.12.11/Submit) id j072js7V022675 for v6ops@ops.ietf.org; Thu, 6 Jan 2005 18:45:55 -0800 Date: Thu, 6 Jan 2005 18:45:54 -0800 From: David Kessens To: v6ops@ops.ietf.org Subject: Feedback on proposed charter from the IESG Message-ID: <20050107024554.GJ6867@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-OriginalArrivalTime: 07 Jan 2005 02:45:57.0196 (UTC) FILETIME=[039088C0:01C4F463] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I sent the following mail to the list before I went on a vacation trip for the holidays. However, my mail didn't make it to the list for unknown reasons, therefore I am trying it again. David Kessens --- From david.kessens@nokia.com Thu Dec 16 17:43:31 2004 Date: Thu, 16 Dec 2004 17:43:31 -0800 From: David Kessens To: v6ops@ops.ietf.org Subject: Feedback on proposed charter from the IESG The IESG discussed the proposed recharter for v6ops. I did not ask the IESG for approval yet since I felt that the charter still needs a bit more review from the community and the upcoming holidays is a suboptimal period for community review (I will be out of the office myself for example). The feedback that I received so far (and that I agree with) is the following: The charter is still a bit open ended. What is really missing is good criteria on how to make decisions on documents that will be accepted and which will not. For example, the list of proposed milestones is rather extensive and we were not entirely convinced that every single document on the list really needs to be worked on in the v6ops working group. As is not uncommon in the Operations Area, this working group will have some topics in the charter that will be somewhat open ended. However, that doesn't mean that we should take on any work that has remotely something to do with the operational aspects of running an ipv6 Internet network. Questions that come to my mind that are important to ask are: Is there really an audience that needs a particular document (eg. not just a very specific audience but a broad group of users)? Is there expertise in the working group to work on the topic (eg. more than just a few people should have a good understanding) ? Did the people that express willingness to work on a topic actually read the proposed internet draft ? Are there more than a few people willing to contribute, and an even larger group to review the document ? I hope that this helps to guide the discussion to get a solid new charter in place. David Kessens --- From owner-v6ops@ops.ietf.org Mon Jan 10 15:53:27 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23948 for ; Mon, 10 Jan 2005 15:53:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Co6UQ-000CLh-RW for v6ops-data@psg.com; Mon, 10 Jan 2005 20:50:14 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Co6UN-000CKw-Ef for v6ops@ops.ietf.org; Mon, 10 Jan 2005 20:50:13 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23639; Mon, 10 Jan 2005 15:50:07 -0500 (EST) Message-Id: <200501102050.PAA23639@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-ent-analysis-01.txt Date: Mon, 10 Jan 2005 15:50: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 : 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. --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-1-10153241.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ent-analysis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ent-analysis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-10153241.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Tue Jan 11 01:56: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 BAA09032 for ; Tue, 11 Jan 2005 01:56:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CoFuO-000OOt-8v for v6ops-data@psg.com; Tue, 11 Jan 2005 06:53:40 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CoFuM-000OOZ-CE for v6ops@ops.ietf.org; Tue, 11 Jan 2005 06:53:38 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0B6ral25176 for ; Tue, 11 Jan 2005 08:53:36 +0200 Date: Tue, 11 Jan 2005 08:53:36 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: Feedback on proposed charter from the IESG In-Reply-To: <20050107024554.GJ6867@nokia.com> Message-ID: References: <20050107024554.GJ6867@nokia.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 Folks, (co-chair hat on) Your input is needed. The WG needs to form an opinion the charter. It seems that charter was considered too open-ended (and I personally agree with it, I just can't think of ways to make it less so, without severely restricting the work that could be pursued by the WG). Do you have suggestions for, e.g.: - what classes of documents are such that we should be working on (with sufficient specifity so it doesn't seem open-ended), - good criteria on how to make decisions on documents that will be accepted and which will not, or - anything which SHOULD NOT be in the charter? The proposed charter was posted on the list on Dec 21st, but I'm also attaching it here. Please send your thoughts, preferably this week. (hat off) On Thu, 6 Jan 2005, David Kessens wrote: [...] > The charter is still a bit open ended. What is really missing is good > criteria on how to make decisions on documents that will be accepted > and which will not. > > For example, the list of proposed milestones is rather extensive and > we were not entirely convinced that every single document on the list > really needs to be worked on in the v6ops working group. > > As is not uncommon in the Operations Area, this working group will > have some topics in the charter that will be somewhat open ended. > However, that doesn't mean that we should take on any work that has > remotely something to do with the operational aspects of running an > ipv6 Internet network. > > Questions that come to my mind that are important to ask are: > > Is there really an audience that needs a particular document (eg. not > just a very specific audience but a broad group of users)? Is there > expertise in the working group to work on the topic (eg. more than > just a few people should have a good understanding) ? Did the people > that express willingness to work on a topic actually read the proposed > internet draft ? Are there more than a few people willing to > contribute, and an even larger group to review the document ? > > I hope that this helps to guide the discussion to get a solid new > charter in place. > > David Kessens > --- ============== Description of Working Group: The global deployment of IPv6 is underway, creating an IPv4/IPv6 Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and nodes. This deployment must be properly handled to avoid the division of the Internet into separate IPv4 and IPv6 networks while ensuring addressing and connectivity for all IPv4 and IPv6 nodes. The IPv6 Operations Working Group (v6ops) develops guidelines for the operation of a shared IPv4/IPv6 Internet and provides guidance for network operators on how to deploy IPv6 into existing IPv4-only networks, as well as into new network installations. The main focus of the v6ops WG is to look at the immediate deployment issues; more advanced stages of deployment and transition are a lower priority. The goals of the v6ops working group are: 1. Solicit input from network operators and users to identify operational issues with the IPv4/IPv6 Internet, and determine solutions or workarounds to those issues. These issues will be documented in Informational or BCP RFCs, or in Internet-Drafts. This work should primarily be conducted by those areas and WGs which are responsible and best fit to analyze these problems, but v6ops may also cooperate in focusing such work. 2. Publish Informational or BCP RFCs that identify potential security risks in the operation of shared IPv4/IPv6 networks, and document operational practices to eliminate or mitigate those risks. This work will be done in cooperation with the Security area and other relevant areas or working groups. 3. As a particular instance of (1) and (2), provide feedback to the IPv6 WG regarding portions of the IPv6 specifications that cause, or are likely to cause, operational or security concerns, and work with the IPv6 WG to resolve those concerns. This feedback will be published in Internet-Drafts or RFCs. 4. Publish Informational or BCP RFCs that identify and analyze solutions for deploying IPv6 within common network environments, such as ISP Networks (including Core, HFC/Cable, DSL & Dial-up networks), Enterprise Networks, Unmanaged Networks (Home/Small Office), and Cellular Networks. These documents should serve as useful guides to network operators and users on possible ways how to deploy IPv6 within their existing IPv4 networks, as well as in new network installations. These documents should not be normative guides for IPv6 deployment, and the primary intent is not capture the needs for new solutions, but rather describe which approaches work and which do not. IPv6 operational and deployment issues with specific protocols or technologies (such as Applications, Transport Protocols, Routing Protocols, DNS or Sub-IP Protocols) are the primary responsibility of the groups or areas responsible for those protocols or technologies. However, the v6ops WG may provide input to those areas/groups, as needed, and cooperate with those areas/groups in reviewing solutions to IPv6 operational and deployment problems. Specifying any protocols or transition mechanisms is out of scope of the WG. Goals and Milestones: Nov 04 Adopt document describing how to use IPsec with draft-ietf-v6ops-mech-v2 as WG item Nov 04 Adopt document describing issues with NAT-PT as WG item Dec 04 Adopt IPv6 Security Overview as WG item Dec 04 Adopt IPv6 deployment using VLANs as WG item Jan 05 Adopt ISP IPv6 Deployment Scenarios in Broadband Access Networks as WG item Jan 05 Adopt IPv6 Network Architecture Protection as WG item Feb 05 Ensure draft-ietf-v6ops-v6onbydefault keeps going forward for RFC publication Feb 05 Submit IPv6 deployment using VLANs to IESG for Info Mar 05 Submit document on IPsec w/ draft-ietf-v6ops-mech-v2 to IESG for Info Mar 05 Submit document describing issues with NAT-PT to IESG for Info Apr 05 Submit Enterprise Deployment Analysis to IESG for Info Apr 05 Submit IPv6 Network Architecture Protection to IESG for Info May 05 Submit IPv6 Security Overview to IESG for Info May 05 Submit ISP IPv6 Deployment Scenarios in Broadband Access Networks to IESG for Info ================= From owner-v6ops@ops.ietf.org Tue Jan 11 09:09:25 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25095 for ; Tue, 11 Jan 2005 09:09:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CoMfh-000Gfn-OD for v6ops-data@psg.com; Tue, 11 Jan 2005 14:06:57 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CoMfg-000GfW-1R for v6ops@ops.ietf.org; Tue, 11 Jan 2005 14:06:56 +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 j0BE6ji3020822 for ; Tue, 11 Jan 2005 14:06:45 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 OAA22835 for ; Tue, 11 Jan 2005 14:06:53 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j0BE6rC05331 for v6ops@ops.ietf.org; Tue, 11 Jan 2005 14:06:53 GMT Date: Tue, 11 Jan 2005 14:06:53 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Feedback on proposed charter from the IESG Message-ID: <20050111140653.GT26813@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <20050107024554.GJ6867@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 It seems to be a bit of a catch-22. The charter needs to be open ended such that any operational issue not specifically relevant to another WG can be adopted, yet the IESG wants to reduce the scope of what can be adopted, without knowing in advance what those items might be. I say we should run with this charter for now, and refine it if the IESG can cite specific examples of hwere it thinks we (you :) are going wrong in adopting 'inappropriate' items. Of all the questions the IESG asks, the key one is "is there really an audience that needs a particular document?", and I feel if we can answer yes to that *and* there is connsesus to adopt and people to work on it, and it isn't the domain of another existing WG, then we do so. Tim On Tue, Jan 11, 2005 at 08:53:36AM +0200, Pekka Savola wrote: > Folks, > > (co-chair hat on) > > Your input is needed. The WG needs to form an opinion the charter. > It seems that charter was considered too open-ended (and I personally > agree with it, I just can't think of ways to make it less so, without > severely restricting the work that could be pursued by the WG). > > Do you have suggestions for, e.g.: > - what classes of documents are such that we should be working on > (with sufficient specifity so it doesn't seem open-ended), > - good criteria on how to make decisions on documents that will be > accepted and which will not, or > - anything which SHOULD NOT be in the charter? > > The proposed charter was posted on the list on Dec 21st, but I'm also > attaching it here. > > Please send your thoughts, preferably this week. > > (hat off) > > On Thu, 6 Jan 2005, David Kessens wrote: > [...] > >The charter is still a bit open ended. What is really missing is good > >criteria on how to make decisions on documents that will be accepted > >and which will not. > > > >For example, the list of proposed milestones is rather extensive and > >we were not entirely convinced that every single document on the list > >really needs to be worked on in the v6ops working group. > > > >As is not uncommon in the Operations Area, this working group will > >have some topics in the charter that will be somewhat open ended. > >However, that doesn't mean that we should take on any work that has > >remotely something to do with the operational aspects of running an > >ipv6 Internet network. > > > >Questions that come to my mind that are important to ask are: > > > >Is there really an audience that needs a particular document (eg. not > >just a very specific audience but a broad group of users)? Is there > >expertise in the working group to work on the topic (eg. more than > >just a few people should have a good understanding) ? Did the people > >that express willingness to work on a topic actually read the proposed > >internet draft ? Are there more than a few people willing to > >contribute, and an even larger group to review the document ? > > > >I hope that this helps to guide the discussion to get a solid new > >charter in place. > > > >David Kessens > >--- > > ============== > Description of Working Group: > > The global deployment of IPv6 is underway, creating an IPv4/IPv6 > Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and > nodes. This deployment must be properly handled to avoid the division > of the Internet into separate IPv4 and IPv6 networks while ensuring > addressing and connectivity for all IPv4 and IPv6 nodes. > > The IPv6 Operations Working Group (v6ops) develops guidelines for the > operation of a shared IPv4/IPv6 Internet and provides guidance for > network operators on how to deploy IPv6 into existing IPv4-only > networks, as well as into new network installations. > > The main focus of the v6ops WG is to look at the immediate > deployment issues; more advanced stages of deployment and transition > are a lower priority. > > The goals of the v6ops working group are: > > 1. Solicit input from network operators and users to identify > operational issues with the IPv4/IPv6 Internet, and > determine solutions or workarounds to those issues. These issues > will be documented in Informational or BCP RFCs, or in > Internet-Drafts. > > This work should primarily be conducted by those areas and WGs > which are responsible and best fit to analyze these problems, but > v6ops may also cooperate in focusing such work. > > 2. Publish Informational or BCP RFCs that identify potential security > risks in the operation of shared IPv4/IPv6 networks, and document > operational practices to eliminate or mitigate those risks. > > This work will be done in cooperation with the Security area and > other relevant areas or working groups. > > 3. As a particular instance of (1) and (2), provide feedback to > the IPv6 WG regarding portions of the IPv6 specifications that > cause, or are likely to cause, operational or security concerns, > and work with the IPv6 WG to resolve those concerns. This feedback > will be published in Internet-Drafts or RFCs. > > 4. Publish Informational or BCP RFCs that identify and analyze solutions > for deploying IPv6 within common network environments, such as > ISP Networks (including Core, HFC/Cable, DSL & Dial-up networks), > Enterprise Networks, Unmanaged Networks (Home/Small Office), and > Cellular Networks. > > These documents should serve as useful guides to network > operators and users on possible ways how to deploy IPv6 within their > existing IPv4 networks, as well as in new network installations. > > These documents should not be normative guides for IPv6 deployment, > and the primary intent is not capture the needs for new solutions, > but rather describe which approaches work and which do not. > > IPv6 operational and deployment issues with specific protocols or > technologies (such as Applications, Transport Protocols, Routing > Protocols, DNS or Sub-IP Protocols) are the primary responsibility of > the groups or areas responsible for those protocols or technologies. > However, the v6ops WG may provide input to those areas/groups, as > needed, and cooperate with those areas/groups in reviewing solutions > to IPv6 operational and deployment problems. > > Specifying any protocols or transition mechanisms is out of scope of > the WG. > > Goals and Milestones: > > Nov 04 Adopt document describing how to use IPsec with > draft-ietf-v6ops-mech-v2 as WG item > Nov 04 Adopt document describing issues with NAT-PT as WG item > Dec 04 Adopt IPv6 Security Overview as WG item > Dec 04 Adopt IPv6 deployment using VLANs as WG item > Jan 05 Adopt ISP IPv6 Deployment Scenarios in Broadband Access Networks > as WG item > Jan 05 Adopt IPv6 Network Architecture Protection as WG item > Feb 05 Ensure draft-ietf-v6ops-v6onbydefault keeps going forward for RFC > publication > Feb 05 Submit IPv6 deployment using VLANs to IESG for Info > Mar 05 Submit document on IPsec w/ draft-ietf-v6ops-mech-v2 to IESG for > Info > Mar 05 Submit document describing issues with NAT-PT to IESG for Info > Apr 05 Submit Enterprise Deployment Analysis to IESG for Info > Apr 05 Submit IPv6 Network Architecture Protection to IESG for Info > May 05 Submit IPv6 Security Overview to IESG for Info > May 05 Submit ISP IPv6 Deployment Scenarios in Broadband Access Networks > to IESG for Info > ================= -- Tim From owner-v6ops@ops.ietf.org Tue Jan 11 09:29:29 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26787 for ; Tue, 11 Jan 2005 09:29:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CoN0l-000KBT-3E for v6ops-data@psg.com; Tue, 11 Jan 2005 14:28:43 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CoN0W-000KAK-RM for v6ops@ops.ietf.org; Tue, 11 Jan 2005 14:28:29 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j0BESSVu024153 for ; Tue, 11 Jan 2005 07:28:28 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IA500AJSPJGJI@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Tue, 11 Jan 2005 07:28:29 -0700 (MST) Received: from [192.168.1.2] ([83.193.69.12]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IA500029PJC8A@mail.sun.net> for v6ops@ops.ietf.org; Tue, 11 Jan 2005 07:28:28 -0700 (MST) Date: Tue, 11 Jan 2005 06:28:24 -0800 From: Alain Durand Subject: Re: Feedback on proposed charter from the IESG In-reply-to: <20050111140653.GT26813@login.ecs.soton.ac.uk> To: Tim Chown Cc: v6ops@ops.ietf.org Message-id: <0D637960-63DD-11D9-A94C-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20050107024554.GJ6867@nokia.com> <20050111140653.GT26813@login.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=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Of course, one could have the exact opposite point of view. We put the wg in sleep mode and when a new issue comes up we recharter to that purpose... That would ensure that an adequate level of review is made before any new work is started. Of course, this requires a very reactive IESG so that no extra delays are introduced... - Alain. On Jan 11, 2005, at 6:06 AM, Tim Chown wrote: > It seems to be a bit of a catch-22. The charter needs to be open ended > such that any operational issue not specifically relevant to another WG > can be adopted, yet the IESG wants to reduce the scope of what can be > adopted, without knowing in advance what those items might be. > > I say we should run with this charter for now, and refine it if the > IESG > can cite specific examples of hwere it thinks we (you :) are going > wrong > in adopting 'inappropriate' items. > > Of all the questions the IESG asks, the key one is "is there really an > audience that needs a particular document?", and I feel if we can > answer > yes to that *and* there is connsesus to adopt and people to work on it, > and it isn't the domain of another existing WG, then we do so. > > Tim > > On Tue, Jan 11, 2005 at 08:53:36AM +0200, Pekka Savola wrote: >> Folks, >> >> (co-chair hat on) >> >> Your input is needed. The WG needs to form an opinion the charter. >> It seems that charter was considered too open-ended (and I personally >> agree with it, I just can't think of ways to make it less so, without >> severely restricting the work that could be pursued by the WG). >> >> Do you have suggestions for, e.g.: >> - what classes of documents are such that we should be working on >> (with sufficient specifity so it doesn't seem open-ended), >> - good criteria on how to make decisions on documents that will be >> accepted and which will not, or >> - anything which SHOULD NOT be in the charter? >> >> The proposed charter was posted on the list on Dec 21st, but I'm also >> attaching it here. >> >> Please send your thoughts, preferably this week. >> >> (hat off) >> >> On Thu, 6 Jan 2005, David Kessens wrote: >> [...] >>> The charter is still a bit open ended. What is really missing is good >>> criteria on how to make decisions on documents that will be accepted >>> and which will not. >>> >>> For example, the list of proposed milestones is rather extensive and >>> we were not entirely convinced that every single document on the list >>> really needs to be worked on in the v6ops working group. >>> >>> As is not uncommon in the Operations Area, this working group will >>> have some topics in the charter that will be somewhat open ended. >>> However, that doesn't mean that we should take on any work that has >>> remotely something to do with the operational aspects of running an >>> ipv6 Internet network. >>> >>> Questions that come to my mind that are important to ask are: >>> >>> Is there really an audience that needs a particular document (eg. not >>> just a very specific audience but a broad group of users)? Is there >>> expertise in the working group to work on the topic (eg. more than >>> just a few people should have a good understanding) ? Did the people >>> that express willingness to work on a topic actually read the >>> proposed >>> internet draft ? Are there more than a few people willing to >>> contribute, and an even larger group to review the document ? >>> >>> I hope that this helps to guide the discussion to get a solid new >>> charter in place. >>> >>> David Kessens >>> --- >> >> ============== >> Description of Working Group: >> >> The global deployment of IPv6 is underway, creating an IPv4/IPv6 >> Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and >> nodes. This deployment must be properly handled to avoid the division >> of the Internet into separate IPv4 and IPv6 networks while ensuring >> addressing and connectivity for all IPv4 and IPv6 nodes. >> >> The IPv6 Operations Working Group (v6ops) develops guidelines for the >> operation of a shared IPv4/IPv6 Internet and provides guidance for >> network operators on how to deploy IPv6 into existing IPv4-only >> networks, as well as into new network installations. >> >> The main focus of the v6ops WG is to look at the immediate >> deployment issues; more advanced stages of deployment and transition >> are a lower priority. >> >> The goals of the v6ops working group are: >> >> 1. Solicit input from network operators and users to identify >> operational issues with the IPv4/IPv6 Internet, and >> determine solutions or workarounds to those issues. These issues >> will be documented in Informational or BCP RFCs, or in >> Internet-Drafts. >> >> This work should primarily be conducted by those areas and WGs >> which are responsible and best fit to analyze these problems, but >> v6ops may also cooperate in focusing such work. >> >> 2. Publish Informational or BCP RFCs that identify potential security >> risks in the operation of shared IPv4/IPv6 networks, and document >> operational practices to eliminate or mitigate those risks. >> >> This work will be done in cooperation with the Security area and >> other relevant areas or working groups. >> >> 3. As a particular instance of (1) and (2), provide feedback to >> the IPv6 WG regarding portions of the IPv6 specifications that >> cause, or are likely to cause, operational or security concerns, >> and work with the IPv6 WG to resolve those concerns. This feedback >> will be published in Internet-Drafts or RFCs. >> >> 4. Publish Informational or BCP RFCs that identify and analyze >> solutions >> for deploying IPv6 within common network environments, such as >> ISP Networks (including Core, HFC/Cable, DSL & Dial-up networks), >> Enterprise Networks, Unmanaged Networks (Home/Small Office), and >> Cellular Networks. >> >> These documents should serve as useful guides to network >> operators and users on possible ways how to deploy IPv6 within their >> existing IPv4 networks, as well as in new network installations. >> >> These documents should not be normative guides for IPv6 deployment, >> and the primary intent is not capture the needs for new solutions, >> but rather describe which approaches work and which do not. >> >> IPv6 operational and deployment issues with specific protocols or >> technologies (such as Applications, Transport Protocols, Routing >> Protocols, DNS or Sub-IP Protocols) are the primary responsibility of >> the groups or areas responsible for those protocols or technologies. >> However, the v6ops WG may provide input to those areas/groups, as >> needed, and cooperate with those areas/groups in reviewing solutions >> to IPv6 operational and deployment problems. >> >> Specifying any protocols or transition mechanisms is out of scope of >> the WG. >> >> Goals and Milestones: >> >> Nov 04 Adopt document describing how to use IPsec with >> draft-ietf-v6ops-mech-v2 as WG item >> Nov 04 Adopt document describing issues with NAT-PT as WG item >> Dec 04 Adopt IPv6 Security Overview as WG item >> Dec 04 Adopt IPv6 deployment using VLANs as WG item >> Jan 05 Adopt ISP IPv6 Deployment Scenarios in Broadband Access >> Networks >> as WG item >> Jan 05 Adopt IPv6 Network Architecture Protection as WG item >> Feb 05 Ensure draft-ietf-v6ops-v6onbydefault keeps going forward >> for RFC >> publication >> Feb 05 Submit IPv6 deployment using VLANs to IESG for Info >> Mar 05 Submit document on IPsec w/ draft-ietf-v6ops-mech-v2 to IESG >> for >> Info >> Mar 05 Submit document describing issues with NAT-PT to IESG for >> Info >> Apr 05 Submit Enterprise Deployment Analysis to IESG for Info >> Apr 05 Submit IPv6 Network Architecture Protection to IESG for Info >> May 05 Submit IPv6 Security Overview to IESG for Info >> May 05 Submit ISP IPv6 Deployment Scenarios in Broadband Access >> Networks >> to IESG for Info >> ================= > > -- > Tim > > > From owner-v6ops@ops.ietf.org Tue Jan 11 09:53:50 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28253 for ; Tue, 11 Jan 2005 09:53:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CoNOb-000OHE-2r for v6ops-data@psg.com; Tue, 11 Jan 2005 14:53:21 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1CoNOX-000OGb-17 for v6ops@ops.ietf.org; Tue, 11 Jan 2005 14:53:17 +0000 Received: (qmail 9497 invoked by uid 417); 11 Jan 2005 14:53:16 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 11 Jan 2005 14:53:16 -0000 Received: from XPNERICK ([193.17.42.1]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Tue, 11 Jan 2005 07:53:15 -0700 Message-ID: <006801c4f7ed$25bf2450$6b081eac@ttitelecom.com> From: "EricLKlein" To: v6ops@ops.ietf.org References: <20050107024554.GJ6867@nokia.com> <20050111140653.GT26813@login.ecs.soton.ac.uk> <0D637960-63DD-11D9-A94C-00039358A080@sun.com> Subject: Re: Feedback on proposed charter from the IESG Date: Tue, 11 Jan 2005 16:52:16 +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=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I prefer Tim's version as there are still too many open items that we need to resolve and finalize to be put into "sleep mode." With the understanding that every new item we take on is checked more carefully for the audience and people willing to work on it. As It appears to me, we need to be active or ended. Sleep mode is a sure way to make sure nothing gets done. Eric ----- Original Message ----- From: "Alain Durand" To: "Tim Chown" Cc: Sent: 11 January, 2005 4:28 PM Subject: Re: Feedback on proposed charter from the IESG > Of course, one could have the exact opposite point of view. > We put the wg in sleep mode and when a new issue comes up > we recharter to that purpose... > > That would ensure that an adequate level of review is made > before any new work is started. Of course, this requires > a very reactive IESG so that no extra delays are introduced... > > - Alain. > > > On Jan 11, 2005, at 6:06 AM, Tim Chown wrote: > > > It seems to be a bit of a catch-22. The charter needs to be open ended > > such that any operational issue not specifically relevant to another WG > > can be adopted, yet the IESG wants to reduce the scope of what can be > > adopted, without knowing in advance what those items might be. > > > > I say we should run with this charter for now, and refine it if the > > IESG > > can cite specific examples of hwere it thinks we (you :) are going > > wrong > > in adopting 'inappropriate' items. > > > > Of all the questions the IESG asks, the key one is "is there really an > > audience that needs a particular document?", and I feel if we can > > answer > > yes to that *and* there is connsesus to adopt and people to work on it, > > and it isn't the domain of another existing WG, then we do so. > > > > Tim > > > > On Tue, Jan 11, 2005 at 08:53:36AM +0200, Pekka Savola wrote: > >> Folks, > >> > >> (co-chair hat on) > >> > >> Your input is needed. The WG needs to form an opinion the charter. > >> It seems that charter was considered too open-ended (and I personally > >> agree with it, I just can't think of ways to make it less so, without > >> severely restricting the work that could be pursued by the WG). > >> > >> Do you have suggestions for, e.g.: > >> - what classes of documents are such that we should be working on > >> (with sufficient specifity so it doesn't seem open-ended), > >> - good criteria on how to make decisions on documents that will be > >> accepted and which will not, or > >> - anything which SHOULD NOT be in the charter? > >> > >> The proposed charter was posted on the list on Dec 21st, but I'm also > >> attaching it here. > >> > >> Please send your thoughts, preferably this week. > >> > >> (hat off) > >> > >> On Thu, 6 Jan 2005, David Kessens wrote: > >> [...] > >>> The charter is still a bit open ended. What is really missing is good > >>> criteria on how to make decisions on documents that will be accepted > >>> and which will not. > >>> > >>> For example, the list of proposed milestones is rather extensive and > >>> we were not entirely convinced that every single document on the list > >>> really needs to be worked on in the v6ops working group. > >>> > >>> As is not uncommon in the Operations Area, this working group will > >>> have some topics in the charter that will be somewhat open ended. > >>> However, that doesn't mean that we should take on any work that has > >>> remotely something to do with the operational aspects of running an > >>> ipv6 Internet network. > >>> > >>> Questions that come to my mind that are important to ask are: > >>> > >>> Is there really an audience that needs a particular document (eg. not > >>> just a very specific audience but a broad group of users)? Is there > >>> expertise in the working group to work on the topic (eg. more than > >>> just a few people should have a good understanding) ? Did the people > >>> that express willingness to work on a topic actually read the > >>> proposed > >>> internet draft ? Are there more than a few people willing to > >>> contribute, and an even larger group to review the document ? > >>> > >>> I hope that this helps to guide the discussion to get a solid new > >>> charter in place. > >>> > >>> David Kessens > >>> --- > >> > >> ============== > >> Description of Working Group: > >> > >> The global deployment of IPv6 is underway, creating an IPv4/IPv6 > >> Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and > >> nodes. This deployment must be properly handled to avoid the division > >> of the Internet into separate IPv4 and IPv6 networks while ensuring > >> addressing and connectivity for all IPv4 and IPv6 nodes. > >> > >> The IPv6 Operations Working Group (v6ops) develops guidelines for the > >> operation of a shared IPv4/IPv6 Internet and provides guidance for > >> network operators on how to deploy IPv6 into existing IPv4-only > >> networks, as well as into new network installations. > >> > >> The main focus of the v6ops WG is to look at the immediate > >> deployment issues; more advanced stages of deployment and transition > >> are a lower priority. > >> > >> The goals of the v6ops working group are: > >> > >> 1. Solicit input from network operators and users to identify > >> operational issues with the IPv4/IPv6 Internet, and > >> determine solutions or workarounds to those issues. These issues > >> will be documented in Informational or BCP RFCs, or in > >> Internet-Drafts. > >> > >> This work should primarily be conducted by those areas and WGs > >> which are responsible and best fit to analyze these problems, but > >> v6ops may also cooperate in focusing such work. > >> > >> 2. Publish Informational or BCP RFCs that identify potential security > >> risks in the operation of shared IPv4/IPv6 networks, and document > >> operational practices to eliminate or mitigate those risks. > >> > >> This work will be done in cooperation with the Security area and > >> other relevant areas or working groups. > >> > >> 3. As a particular instance of (1) and (2), provide feedback to > >> the IPv6 WG regarding portions of the IPv6 specifications that > >> cause, or are likely to cause, operational or security concerns, > >> and work with the IPv6 WG to resolve those concerns. This feedback > >> will be published in Internet-Drafts or RFCs. > >> > >> 4. Publish Informational or BCP RFCs that identify and analyze > >> solutions > >> for deploying IPv6 within common network environments, such as > >> ISP Networks (including Core, HFC/Cable, DSL & Dial-up networks), > >> Enterprise Networks, Unmanaged Networks (Home/Small Office), and > >> Cellular Networks. > >> > >> These documents should serve as useful guides to network > >> operators and users on possible ways how to deploy IPv6 within their > >> existing IPv4 networks, as well as in new network installations. > >> > >> These documents should not be normative guides for IPv6 deployment, > >> and the primary intent is not capture the needs for new solutions, > >> but rather describe which approaches work and which do not. > >> > >> IPv6 operational and deployment issues with specific protocols or > >> technologies (such as Applications, Transport Protocols, Routing > >> Protocols, DNS or Sub-IP Protocols) are the primary responsibility of > >> the groups or areas responsible for those protocols or technologies. > >> However, the v6ops WG may provide input to those areas/groups, as > >> needed, and cooperate with those areas/groups in reviewing solutions > >> to IPv6 operational and deployment problems. > >> > >> Specifying any protocols or transition mechanisms is out of scope of > >> the WG. > >> > >> Goals and Milestones: > >> > >> Nov 04 Adopt document describing how to use IPsec with > >> draft-ietf-v6ops-mech-v2 as WG item > >> Nov 04 Adopt document describing issues with NAT-PT as WG item > >> Dec 04 Adopt IPv6 Security Overview as WG item > >> Dec 04 Adopt IPv6 deployment using VLANs as WG item > >> Jan 05 Adopt ISP IPv6 Deployment Scenarios in Broadband Access > >> Networks > >> as WG item > >> Jan 05 Adopt IPv6 Network Architecture Protection as WG item > >> Feb 05 Ensure draft-ietf-v6ops-v6onbydefault keeps going forward > >> for RFC > >> publication > >> Feb 05 Submit IPv6 deployment using VLANs to IESG for Info > >> Mar 05 Submit document on IPsec w/ draft-ietf-v6ops-mech-v2 to IESG > >> for > >> Info > >> Mar 05 Submit document describing issues with NAT-PT to IESG for > >> Info > >> Apr 05 Submit Enterprise Deployment Analysis to IESG for Info > >> Apr 05 Submit IPv6 Network Architecture Protection to IESG for Info > >> May 05 Submit IPv6 Security Overview to IESG for Info > >> May 05 Submit ISP IPv6 Deployment Scenarios in Broadband Access > >> Networks > >> to IESG for Info > >> ================= > > > > -- > > Tim > > > > > > > > > From owner-v6ops@ops.ietf.org Tue Jan 11 09:58: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 JAA28456 for ; Tue, 11 Jan 2005 09:58:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CoNTF-000PFx-2S for v6ops-data@psg.com; Tue, 11 Jan 2005 14:58:09 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CoNTD-000PFd-Rq for v6ops@ops.ietf.org; Tue, 11 Jan 2005 14:58:08 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0BEw4D03340; Tue, 11 Jan 2005 16:58:04 +0200 Date: Tue, 11 Jan 2005 16:58:04 +0200 (EET) From: Pekka Savola To: EricLKlein cc: v6ops@ops.ietf.org Subject: Re: Feedback on proposed charter from the IESG In-Reply-To: <006801c4f7ed$25bf2450$6b081eac@ttitelecom.com> Message-ID: References: <20050107024554.GJ6867@nokia.com> <20050111140653.GT26813@login.ecs.soton.ac.uk> <0D637960-63DD-11D9-A94C-00039358A080@sun.com> <006801c4f7ed$25bf2450$6b081eac@ttitelecom.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 11 Jan 2005, EricLKlein wrote: > I prefer Tim's version as there are still too many open items that we need > to resolve and finalize to be put into "sleep mode." With the understanding > that every new item we take on is checked more carefully for the audience > and people willing to work on it. > > As It appears to me, we need to be active or ended. Sleep mode is a sure way > to make sure nothing gets done. Well.. there is a middle ground: charter certain work items *now* and specify that adding new work items requires rechartering. That should be enough for the next year or so, though potential new items could not be adopted, without having to go to complete sleep. -- 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 Jan 11 10:23:49 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00803 for ; Tue, 11 Jan 2005 10:23:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CoNqx-0004hv-19 for v6ops-data@psg.com; Tue, 11 Jan 2005 15:22:39 +0000 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CoNqw-0004hi-3o for v6ops@ops.ietf.org; Tue, 11 Jan 2005 15:22:38 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0BFMbdt026401 for ; Tue, 11 Jan 2005 08:22:37 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IA5000FKS1P6U@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Tue, 11 Jan 2005 08:22:38 -0700 (MST) Received: from [192.168.1.2] ([83.193.69.12]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IA500751S1NOK@mail.sun.net> for v6ops@ops.ietf.org; Tue, 11 Jan 2005 08:22:37 -0700 (MST) Date: Tue, 11 Jan 2005 07:22:34 -0800 From: Alain Durand Subject: Re: Feedback on proposed charter from the IESG In-reply-to: <006801c4f7ed$25bf2450$6b081eac@ttitelecom.com> To: EricLKlein Cc: v6ops@ops.ietf.org Message-id: <9E988E5A-63E4-11D9-80ED-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20050107024554.GJ6867@nokia.com> <20050111140653.GT26813@login.ecs.soton.ac.uk> <0D637960-63DD-11D9-A94C-00039358A080@sun.com> <006801c4f7ed$25bf2450$6b081eac@ttitelecom.com> 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 Jan 11, 2005, at 6:52 AM, EricLKlein wrote: > I prefer Tim's version as there are still too many open items that we > need > to resolve and finalize to be put into "sleep mode." I guess I should have been clearer. I meant sleep after current work items are completed. - Alain. From owner-v6ops@ops.ietf.org Tue Jan 11 10:23:50 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00819 for ; Tue, 11 Jan 2005 10:23:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CoNqU-0004e2-TL for v6ops-data@psg.com; Tue, 11 Jan 2005 15:22:10 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1CoNqT-0004bz-T6 for v6ops@ops.ietf.org; Tue, 11 Jan 2005 15:22:10 +0000 Received: (qmail 817 invoked by uid 417); 11 Jan 2005 15:22:09 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 11 Jan 2005 15:22:09 -0000 Received: from XPNERICK ([193.17.42.1]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Tue, 11 Jan 2005 08:22:08 -0700 Message-ID: <009101c4f7f1$2e7e3aa0$6b081eac@ttitelecom.com> From: "EricLKlein" To: v6ops@ops.ietf.org References: <20050107024554.GJ6867@nokia.com> <20050111140653.GT26813@login.ecs.soton.ac.uk> <0D637960-63DD-11D9-A94C-00039358A080@sun.com> <006801c4f7ed$25bf2450$6b081eac@ttitelecom.com> Subject: Re: Feedback on proposed charter from the IESG Date: Tue, 11 Jan 2005 17:21:09 +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 Ok, so there are currently 4 options (roughly summarized as follows): 1. Keep taking new items until told we have overstepped (Open ended approach proposed by Tim) 2. Keep current items, and make new items fit stricter acceptance process (active middle approach proposed by Eric) 3. Keep current items, and specify that adding new work items requires re-chartering (middle approach proposed by Pekka) 4. Keep Current items and re-charter as new issues come up (Sleep mode as proposed by Alain) Have I got all of the contenders straight? From owner-v6ops@ops.ietf.org Tue Jan 11 12:19:34 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10093 for ; Tue, 11 Jan 2005 12:19:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CoPeG-000Mm1-4b for v6ops-data@psg.com; Tue, 11 Jan 2005 17:17:40 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CoPeE-000MlS-2s for v6ops@ops.ietf.org; Tue, 11 Jan 2005 17:17:39 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0BHHTA07345; Tue, 11 Jan 2005 19:17:34 +0200 Date: Tue, 11 Jan 2005 19:17:29 +0200 (EET) From: Pekka Savola To: EricLKlein cc: v6ops@ops.ietf.org Subject: Re: Feedback on proposed charter from the IESG In-Reply-To: <009101c4f7f1$2e7e3aa0$6b081eac@ttitelecom.com> Message-ID: References: <20050107024554.GJ6867@nokia.com> <20050111140653.GT26813@login.ecs.soton.ac.uk> <0D637960-63DD-11D9-A94C-00039358A080@sun.com> <006801c4f7ed$25bf2450$6b081eac@ttitelecom.com> <009101c4f7f1$2e7e3aa0$6b081eac@ttitelecom.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 11 Jan 2005, EricLKlein wrote: > 2. Keep current items, and make new items fit stricter acceptance process > (active middle approach proposed by Eric) No problem there, but the key point remains -- what would be that stricter acceptance process? :) > 3. Keep current items, and specify that adding new work items requires > re-chartering (middle approach proposed by Pekka) > 4. Keep Current items and re-charter as new issues come up (Sleep mode as > proposed by Alain) I think these are basically the same. If there are no new items after done with those currently being chartered (and we still would need to discuss which those would be), the WG either goes to sleep or is shut down.. we don't have to decide which at this point. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Jan 12 08:26:16 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11288 for ; Wed, 12 Jan 2005 08:26:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CoiT8-0002a7-Vz for v6ops-data@psg.com; Wed, 12 Jan 2005 13:23:26 +0000 Received: from [195.212.29.134] (helo=mtagate1.uk.ibm.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CoiT5-0002Zm-2q for v6ops@ops.ietf.org; Wed, 12 Jan 2005 13:23:23 +0000 Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j0CDNJVQ284716 for ; Wed, 12 Jan 2005 13:23:19 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1507.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0CDNhP9069668 for ; Wed, 12 Jan 2005 13:23:43 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j0CDNIFq024782 for ; Wed, 12 Jan 2005 13:23:18 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j0CDNIIN024777; Wed, 12 Jan 2005 13:23:18 GMT Received: from zurich.ibm.com (sig-9-146-218-169.de.ibm.com [9.146.218.169]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA56908; Wed, 12 Jan 2005 14:23:16 +0100 Message-ID: <41E524C3.6040302@zurich.ibm.com> Date: Wed, 12 Jan 2005 14:23:15 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Pekka Savola CC: EricLKlein , v6ops@ops.ietf.org Subject: Re: Feedback on proposed charter from the IESG References: <20050107024554.GJ6867@nokia.com> <20050111140653.GT26813@login.ecs.soton.ac.uk> <0D637960-63DD-11D9-A94C-00039358A080@sun.com> <006801c4f7ed$25bf2450$6b081eac@ttitelecom.com> <009101c4f7f1$2e7e3aa0$6b081eac@ttitelecom.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > On Tue, 11 Jan 2005, EricLKlein wrote: > >> 2. Keep current items, and make new items fit stricter acceptance process >> (active middle approach proposed by Eric) > > > No problem there, but the key point remains -- what would be that > stricter acceptance process? :) > >> 3. Keep current items, and specify that adding new work items requires >> re-chartering (middle approach proposed by Pekka) >> 4. Keep Current items and re-charter as new issues come up (Sleep mode as >> proposed by Alain) > > > I think these are basically the same. If there are no new items after > done with those currently being chartered (and we still would need to > discuss which those would be), the WG either goes to sleep or is shut > down.. we don't have to decide which at this point. I would suggest a 2.5 approach: Make the charter obviously in two parts: First part: general statement of purpose, maybe a bit shorter than the current version, plus a new bit that sets the level for new work items, e.g. Future work items within this scope will be adopted by the WG only if there is a substantial expression of interest from the operational community and if the work clearly does not fit elsewhere in the IETF. Second part: the menu of currently chartered work items (not just the list of milestones). And yes, adding work items and milestones will be a charter update, involving the AD and perhaps the IESG. That's what they are "paid" for. Brian From owner-v6ops@ops.ietf.org Wed Jan 12 11:19: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 LAA25556 for ; Wed, 12 Jan 2005 11:19:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1ColBe-0006tL-SE for v6ops-data@psg.com; Wed, 12 Jan 2005 16:17:34 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1ColBU-0006sK-MY for v6ops@ops.ietf.org; Wed, 12 Jan 2005 16:17:25 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 1DFF852E6; Wed, 12 Jan 2005 11:17:24 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Jan 2005 11:17:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Feedback on proposed charter from the IESG Date: Wed, 12 Jan 2005 11:17:30 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0832FFF4@tayexc13.americas.cpqcorp.net> Thread-Topic: Feedback on proposed charter from the IESG Thread-Index: AcT3qtWRujPua1hcTDWGW4gRKgpiOwBE/Z/A From: "Bound, Jim" To: "Pekka Savola" , X-OriginalArrivalTime: 12 Jan 2005 16:17:23.0978 (UTC) FILETIME=[3336A6A0:01C4F8C2] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Pekka, My responses below. I essentially support what Tim stated and as Alain suggested when we are done with items and no new work meets the bar we set we enter sleep mode. So support Tim+Alain as caveat to my inline response.=20 > Do you have suggestions for, e.g.: > - what classes of documents are such that we should be working on > (with sufficient specifity so it doesn't seem open-ended), I believe current input is good and basically needs of the operational community for deployment. But I want to note what "operational community" means and maybe we need to call that out from v6ops view very clearly: Operational Community: 1. Providers (telco, ISPs, IXs, Mobile Greenfield to deploy 3G IMS et al they are all different) 2. Enterprises that require operational work from within the IETF for Enterprise operation. 3. Liaison consortias for deployment that provide v6ops via IETF operational requirements. Examples are IPv6 Forum, ICANN, NANOG, Registries, ATIS www.atis.org, NCOIC www.ncoic.org, etc. So I would like to see operational requirements defined at least for our charter. > - good criteria on how to make decisions on documents that will be > accepted and which will not, or > - anything which SHOULD NOT be in the charter? I think that is work we need to do in the WG now and should have its own mail thread topic is my input. So won't list it in this response. .] > > The charter is still a bit open ended. What is really=20 > missing is good=20 > > criteria on how to make decisions on documents that will be=20 > accepted=20 > > and which will not. Suggest you as chair begin separate mail thread as I state above for this discussion. It is to important to embed in this subject title is my suggestion. > > > > For example, the list of proposed milestones is rather=20 > extensive and=20 > > we were not entirely convinced that every single document=20 > on the list=20 > > really needs to be worked on in the v6ops working group. > > > > As is not uncommon in the Operations Area, this working group will=20 > > have some topics in the charter that will be somewhat open ended. > > However, that doesn't mean that we should take on any work that has=20 > > remotely something to do with the operational aspects of running an > > ipv6 Internet network. > > > > Questions that come to my mind that are important to ask are: > > > > Is there really an audience that needs a particular=20 > document (eg. not=20 > > just a very specific audience but a broad group of users)? Is there=20 > > expertise in the working group to work on the topic (eg. more than=20 > > just a few people should have a good understanding) ? Did=20 > the people=20 > > that express willingness to work on a topic actually read=20 > the proposed=20 > > internet draft ? Are there more than a few people willing to=20 > > contribute, and an even larger group to review the document ? I think the answer to the current work to all of the above is yes both here in v6ops and in the v6ops understanding of the operational community. > > > > I hope that this helps to guide the discussion to get a solid new=20 > > charter in place. I think the IESG gave us good feedback to think about. > Description of Working Group: >=20 > The global deployment of IPv6 is underway, creating an=20 > IPv4/IPv6 Internet consisting of IPv4-only, IPv6-only and=20 > IPv4/IPv6 networks and nodes. This deployment must be=20 > properly handled to avoid the division of the Internet into=20 > separate IPv4 and IPv6 networks while ensuring addressing and=20 > connectivity for all IPv4 and IPv6 nodes. I think the above needs re-wording. Suggested replacement text: The global deployment of IPv6 is in process. As the deployment evolves some basic operational requirements will exist, and new operational requirements will be learned. The IPv6 Operations Working Group is an IETF working group to work on these operational requirements. To scope the work for the IPv6 Operations Working Group we define and provide examples of work within the scope of operational requirements. [This is the mail thread discussion I suggest above to fill out the above sentence] Define operational community, and then criteria in that mail thread as WG discussion. >=20 > The IPv6 Operations Working Group (v6ops) develops guidelines=20 > for the operation of a shared IPv4/IPv6 Internet and provides=20 > guidance for network operators on how to deploy IPv6 into > existing IPv4-only networks, as well as into new network=20 > installations. Above replace and state: "provides operational guidance"=20 Remove "network operators" our work is useful to Managers, Architects, et al who will deploy IPv6.=20 Re-write below: The IPv6 Operations Working Group (v6ops) develops guidelines=20 for the operation of a shared IPv4/IPv6 Internet and provides=20 Operational guidance on how to deploy IPv6 into existing IPv4-only networks, as well as into new network=20 installations. =20 >=20 > The main focus of the v6ops WG is to look at the immediate=20 > deployment issues; more advanced stages of deployment and=20 > transition are a lower priority. I would suggest this is premature if we are to have a criteria discussion. I think it will hold but lets check. >=20 > The goals of the v6ops working group are: >=20 > 1. Solicit input from network operators and users to identify > operational issues with the IPv4/IPv6 Internet, and > determine solutions or workarounds to those issues. These issues > will be documented in Informational or BCP RFCs, or in > Internet-Drafts. >=20 > This work should primarily be conducted by those areas and WGs > which are responsible and best fit to analyze these problems, but > v6ops may also cooperate in focusing such work. >=20 > 2. Publish Informational or BCP RFCs that identify potential security > risks in the operation of shared IPv4/IPv6 networks, and document > operational practices to eliminate or mitigate those risks. >=20 > This work will be done in cooperation with the Security area and > other relevant areas or working groups. >=20 > 3. As a particular instance of (1) and (2), provide feedback to > the IPv6 WG regarding portions of the IPv6 specifications that > cause, or are likely to cause, operational or security concerns, > and work with the IPv6 WG to resolve those concerns. This feedback > will be published in Internet-Drafts or RFCs. >=20 > 4. Publish Informational or BCP RFCs that identify and=20 > analyze solutions > for deploying IPv6 within common network environments, such as > ISP Networks (including Core, HFC/Cable, DSL & Dial-up networks), > Enterprise Networks, Unmanaged Networks (Home/Small Office), and > Cellular Networks. >=20 > These documents should serve as useful guides to network > operators and users on possible ways how to deploy IPv6=20 > within their > existing IPv4 networks, as well as in new network installations. >=20 > These documents should not be normative guides for IPv6 deployment, > and the primary intent is not capture the needs for new solutions, > but rather describe which approaches work and which do not. I think the above are useful results in response to needs to us based on the criteria which is what is missing in our charter. >=20 > IPv6 operational and deployment issues with specific=20 > protocols or technologies (such as Applications, Transport=20 > Protocols, Routing Protocols, DNS or Sub-IP Protocols) are=20 > the primary responsibility of the groups or areas responsible=20 > for those protocols or technologies. > However, the v6ops WG may provide input to those=20 > areas/groups, as needed, and cooperate with those=20 > areas/groups in reviewing solutions to IPv6 operational and=20 > deployment problems. This is important to do within the IETF community of interests I agree. >=20 > Specifying any protocols or transition mechanisms is out of=20 > scope of the WG. I am not happy about this but that is fine lets move on. I do think authors of transition mechanism should send them to this list so they know they exist. >=20 > Goals and Milestones: >=20 > Nov 04 Adopt document describing how to use IPsec=20 > with draft-ietf-v6ops-mech-v2 as WG item > Nov 04 Adopt document describing issues with NAT-PT as WG item > Dec 04 Adopt IPv6 Security Overview as WG item > Dec 04 Adopt IPv6 deployment using VLANs as WG item > Jan 05 Adopt ISP IPv6 Deployment Scenarios in Broadband=20 > Access Networks as WG item > Jan 05 Adopt IPv6 Network Architecture Protection as WG item > Feb 05 Ensure draft-ietf-v6ops-v6onbydefault keeps going=20 > forward for RFC publication > Feb 05 Submit IPv6 deployment using VLANs to IESG for Info > Mar 05 Submit document on IPsec w/=20 > draft-ietf-v6ops-mech-v2 to IESG for Info > Mar 05 Submit document describing issues with NAT-PT to=20 > IESG for Info > Apr 05 Submit Enterprise Deployment Analysis to IESG for Info > Apr 05 Submit IPv6 Network Architecture Protection to IESG for Info > May 05 Submit IPv6 Security Overview to IESG for Info > May 05 Submit ISP IPv6 Deployment Scenarios in Broadband=20 > Access Networks to IESG for Info = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I support all of the above being completed as work items for v6ops. Thanks for asking, /jim From owner-v6ops@ops.ietf.org Wed Jan 12 12:43: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 MAA01293 for ; Wed, 12 Jan 2005 12:43:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1ComUc-0001zv-U7 for v6ops-data@psg.com; Wed, 12 Jan 2005 17:41:14 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1ComUb-0001zV-0k for v6ops@ops.ietf.org; Wed, 12 Jan 2005 17:41:13 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0CHfBV01614 for ; Wed, 12 Jan 2005 19:41:11 +0200 Date: Wed, 12 Jan 2005 19:41:11 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: what to go (or not) to the charter? 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, Jim raised a good point that this should be discussed in a separate thread... (co-chair hat on) There are two separate issues: 1) [good] criteria on how to make decisions on documents that should be accepted and which should not, and This is more important issue to settle, because otherwise we'd likely need to require re-chartering to add new work items. 2) what would be the list of documents "kickstart" the new WG? a) anything in particular which SHOULD NOT be in the charter? *) b) anything particularly important, now missing, which should be explicitly in the charter at this point (note that the following list should be enough for WG's plate already) ? Other related comments are also welcome. .... *) a list of potential items was in the proposed charter, but here it is again: (never mind the dates..) Feb 05 Submit IPv6 deployment using VLANs to IESG for Info Mar 05 Submit document on IPsec w/ draft-ietf-v6ops-mech-v2 to IESG for Info Mar 05 Submit document describing issues with NAT-PT to IESG for Info Apr 05 Submit Enterprise Deployment Analysis to IESG for Info Apr 05 Submit IPv6 Network Architecture Protection to IESG for Info May 05 Submit IPv6 Security Overview to IESG for Info May 05 Submit ISP IPv6 Deployment Scenarios in Broadband Access Networks to IESG for Info Remember that we also have the following older on-going projects: - draft-ietf-v6ops-mech-v2 [waiting for AD's decision] - draft-ietf-v6ops-{onlinkassumption,v6onbydefault} [waiting for fixes to get in or to move forward otherwise] - draft-ietf-v6ops-renumbering-procedure [waiting author revision] - draft-ietf-v6ops-ent-analysis [author revision/WG followup] (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 Thu Jan 13 12:02:57 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26404 for ; Thu, 13 Jan 2005 12:02:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cp8KB-000IEb-0V for v6ops-data@psg.com; Thu, 13 Jan 2005 16:59:55 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cp8K9-000IEJ-Lc for v6ops@ops.ietf.org; Thu, 13 Jan 2005 16:59:54 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id j0DGxqbP197750 for ; Thu, 13 Jan 2005 16:59:52 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0DH0OLM127856 for ; Thu, 13 Jan 2005 18:00:24 +0100 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j0DGxp72020376 for ; Thu, 13 Jan 2005 17:59:52 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j0DGxpEa020362; Thu, 13 Jan 2005 17:59:51 +0100 Received: from zurich.ibm.com (dyn-9-13-126-72.ge.ch.ibm.com [9.13.126.72]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA70420; Thu, 13 Jan 2005 17:59:50 +0100 Message-ID: <41E6A903.2030806@zurich.ibm.com> Date: Thu, 13 Jan 2005 17:59:47 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org Subject: Re: what to go (or not) to the charter? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > Hi, > > Jim raised a good point that this should be discussed in a separate > thread... > > (co-chair hat on) > > There are two separate issues: > > 1) [good] criteria on how to make decisions on documents that should > be accepted and which should not, I already suggested this: Future work items within this scope will be adopted by the WG only if there is a substantial expression of interest from the operational community and if the work clearly does not fit elsewhere in the IETF. It's very hard to be much more detailed and objective than that, IMHO. Brian From owner-v6ops@ops.ietf.org Fri Jan 14 06:33:08 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02372 for ; Fri, 14 Jan 2005 06:33:07 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CpPed-000Mrt-C1 for v6ops-data@psg.com; Fri, 14 Jan 2005 11:30:11 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CpPeb-000MrX-Lt for v6ops@ops.ietf.org; Fri, 14 Jan 2005 11:30:10 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0EBU8X25580 for ; Fri, 14 Jan 2005 13:30:08 +0200 Date: Fri, 14 Jan 2005 13:30:07 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: Interest to have as an WG item: draft-tschofenig-v6ops-secure-tunnels-03.txt In-Reply-To: <1104760395.4819.244.camel@essrv103nok154154.ntc.nokia.com> Message-ID: References: <1104760395.4819.244.camel@essrv103nok154154.ntc.nokia.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 Folks, There has been only one comment about this. Please speak up your thoughts. On Mon, 3 Jan 2005, Soininen Jonne (Nokia-NET/Helsinki) wrote: > Hello v6ops WG, > > first of all, happy new year to everybody, and it is time to get back to > work. > > (Chair hat on) > The authors of draft-tschofenig-v6ops-secure-tunnels have requested the > draft to be adopted as a WG item. I would like to give two (2) weeks of > time for the discussion, putting the deadline to 18.1.2005. > > The draft can be found at > http://www.ietf.org/internet-drafts/draft-tschofenig-v6ops-secure-tunnels-03.txt > > (Chair hat off) > > Cheers, > > Jonne > > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Jan 14 08:08:07 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11212 for ; Fri, 14 Jan 2005 08:08:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CpR9v-0007pN-9I for v6ops-data@psg.com; Fri, 14 Jan 2005 13:06:35 +0000 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CpR9t-0007oj-MK for v6ops@ops.ietf.org; Fri, 14 Jan 2005 13:06:34 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0ED6Xdt014343 for ; Fri, 14 Jan 2005 06:06:33 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IAB00H9G5QWZU@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Fri, 14 Jan 2005 06:06:33 -0700 (MST) Received: from [192.168.1.2] ([83.193.196.106]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAB007W65QTOK@mail.sun.net> for v6ops@ops.ietf.org; Fri, 14 Jan 2005 06:06:32 -0700 (MST) Date: Fri, 14 Jan 2005 05:06:28 -0800 From: Alain Durand Subject: Re: Interest to have as an WG item: draft-tschofenig-v6ops-secure-tunnels-03.txt In-reply-to: To: Pekka Savola Cc: v6ops@ops.ietf.org Message-id: <1A40D58C-662D-11D9-A440-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <1104760395.4819.244.camel@essrv103nok154154.ntc.nokia.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Well, I'm not a security expert, far from that, so I'm not sure I can comment on the quality of the security assertions. However, at fist glance, it seems that this is a tutorial on ikev1 & ikev2 in the context of IPv6... I other words, it is unclear to me why we need this document in v6Ops and why it is not homed in a security related wg IF there is a need for such a document. On another note, some of the techniques described here may be useful in the context of v6tc... - Alain. From owner-v6ops@ops.ietf.org Fri Jan 14 09:10:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15999 for ; Fri, 14 Jan 2005 09:10:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CpS86-000GdR-Mj for v6ops-data@psg.com; Fri, 14 Jan 2005 14:08:46 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CpS7x-000Gcj-EP for v6ops@ops.ietf.org; Fri, 14 Jan 2005 14:08:37 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0EE8Yi29504; Fri, 14 Jan 2005 16:08:35 +0200 Date: Fri, 14 Jan 2005 16:08:34 +0200 (EET) From: Pekka Savola To: Alain Durand cc: v6ops@ops.ietf.org Subject: Re: draft-tschofenig-v6ops-secure-tunnels-03.txt In-Reply-To: <1A40D58C-662D-11D9-A440-00039358A080@sun.com> Message-ID: References: <1104760395.4819.244.camel@essrv103nok154154.ntc.nokia.com> <1A40D58C-662D-11D9-A440-00039358A080@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 14 Jan 2005, Alain Durand wrote: > Well, I'm not a security expert, far from that, so I'm not sure I > can comment on the quality of the security assertions. However, at > fist glance, it seems that this is a tutorial on ikev1 & ikev2 in > the context of IPv6... I other words, it is unclear to me why we > need this document in v6Ops and why it is not homed in a security > related wg IF there is a need for such a document. Please take a bit closer look; it's not just a tutorial on IKE with IPv6, it describes how to use IKE and IPsec to set up IPv6-in-IPv4 tunnels. The background here is that: 1) trans-mech RFC basically said, "use IPsec if you need security"; this is no longer considered sufficient, and it is required to describe how exactly you use IPsec if you propose to use it. 2) draft-ietf-v6ops-mech-v2 was revised to just say, "we describe the use of IPsec for v6-in-v4 tunnels in another document" [this one]. 3) Steve Bellovin, while he was security AD, requested description of IPsec usage (or this document) at his review of draft-ietf-mech-v2-xx; he wouldn't want to let draft-ietf-mech-v2 go forward to the RFC editor's queue before this is done, so draft-ietf-v6ops-mech-v2 has been practically stalled from completion for the last 4 months or so. Moreover, - it is the responsibility of the WG producing a protocol to document how its security works, not the security area (i.e., the security area does not have the responsibility to document how to use IPsec to secure v6-in-v4 configured tunnels) - I suggested that this work could also be done as an individual submission to Steve (while he was still AD), but he thought v6ops was a better idea . So, there is quite a bit of history why this document came to be, and why it has been proposed in v6ops, not somewhere else. However, it may not have been clear enough why exactly it _seems_ that there is no other option than to do it here. Does this change your view on the document? Any comments from the others? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Jan 14 09:16:17 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16267 for ; Fri, 14 Jan 2005 09:16:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CpSEz-000HvZ-48 for v6ops-data@psg.com; Fri, 14 Jan 2005 14:15:53 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CpSEy-000HvL-2m for v6ops@ops.ietf.org; Fri, 14 Jan 2005 14:15:52 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j0EEFpVu014373 for ; Fri, 14 Jan 2005 07:15:51 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IAB00GR78YEKT@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Fri, 14 Jan 2005 07:15:51 -0700 (MST) Received: from [192.168.1.2] ([83.193.196.106]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAB006SZ8YB44@mail.sun.net> for v6ops@ops.ietf.org; Fri, 14 Jan 2005 07:15:50 -0700 (MST) Date: Fri, 14 Jan 2005 06:15:45 -0800 From: Alain Durand Subject: Re: draft-tschofenig-v6ops-secure-tunnels-03.txt In-reply-to: To: Pekka Savola Cc: v6ops@ops.ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <1104760395.4819.244.camel@essrv103nok154154.ntc.nokia.com> <1A40D58C-662D-11D9-A440-00039358A080@sun.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Jan 14, 2005, at 6:08 AM, Pekka Savola wrote: > So, there is quite a bit of history why this document came to be, and > why it has been proposed in v6ops, not somewhere else. > > However, it may not have been clear enough why exactly it _seems_ that > there is no other option than to do it here. > > Does this change your view on the document? Any comments from the > others? Yes, it does change my opinion. A boilerplate explaining the history of this document would be useful. - Alain. From owner-v6ops@ops.ietf.org Fri Jan 14 09:33:17 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17262 for ; Fri, 14 Jan 2005 09:33:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CpSVJ-000L60-Li for v6ops-data@psg.com; Fri, 14 Jan 2005 14:32:45 +0000 Received: from [192.35.17.28] (helo=goliath.siemens.de) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CpSVH-000L5j-5S for v6ops@ops.ietf.org; Fri, 14 Jan 2005 14:32:43 +0000 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j0EEWeVi025049; Fri, 14 Jan 2005 15:32:40 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j0EEWe3r009348; Fri, 14 Jan 2005 15:32:40 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Fri, 14 Jan 2005 15:32:40 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F05649B30@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Alain Durand , Pekka Savola Cc: v6ops@ops.ietf.org Subject: RE: Interest to have as an WG item: draft-tschofenig-v6ops-secure -tunnels-03.txt Date: Fri, 14 Jan 2005 15:32:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable hi alain,=20 thanks for your comment. to show you the difference between a document that describes how to use ikev1/ikev2 (and ipsec) to provide security of something you might also = want to look at the mip6 working group where documents exist that describe = how ikev1/ipsec is used to secure the mipv6 signaling between the mn and = the ha (and the same for ikev2):=20 http://www.ietf.org/rfc/rfc3776.txt http://www.ietf.org/internet-drafts/draft-ietf-mip6-ikev2-ipsec-00.txt the v6ops-secure-tunnels document is of this type. we are, however, not extendig ikev2 (luckily).=20 a tutorial (as a comparison) looks like:=20 http://ftp.iasi.rdsnet.ro/mirrors/nis.nsf.net/internet-drafts/draft-ietf= -ips ec-ikev2-tutorial-01.txt ciao hannes =20 > -----Original Message----- > From: Alain Durand [mailto:Alain.Durand@Sun.COM]=20 > Sent: Freitag, 14. J=E4nner 2005 14:06 > To: Pekka Savola > Cc: v6ops@ops.ietf.org > Subject: Re: Interest to have as an WG item:=20 > draft-tschofenig-v6ops-secure-tunnels-03.txt >=20 > Well, I'm not a security expert, far from that, so I'm not=20 > sure I can comment on the quality of the security assertions. > However, at fist glance, it seems that this is a tutorial on ikev1 & > ikev2 > in the context of IPv6... > I other words, it is unclear to me why we need this document=20 > in v6Ops and why it is not homed in a security related wg IF=20 > there is a need for such a document. >=20 > On another note, some of the techniques described here may be=20 > useful in the context of v6tc... >=20 > - Alain. >=20 >=20 From owner-v6ops@ops.ietf.org Tue Jan 18 15:12: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 PAA26950 for ; Tue, 18 Jan 2005 15:12:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cqzeg-0009nD-En for v6ops-data@psg.com; Tue, 18 Jan 2005 20:08:46 +0000 Received: from [81.187.81.52] (helo=smtp.aaisp.net.uk) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CqzeX-0009jf-2c for v6ops@ops.ietf.org; Tue, 18 Jan 2005 20:08:37 +0000 Received: from [81.187.254.249] (helo=study.dial.pipex.com) by smtp.aaisp.net.uk with esmtp (Exim 4.42) id 1CqzeU-0005BE-0B for v6ops@ops.ietf.org; Tue, 18 Jan 2005 20:08:34 +0000 Message-Id: <6.2.0.14.0.20050118194343.01ee5c38@imap.dial.pipex.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 18 Jan 2005 20:11:09 +0000 To: v6ops@ops.ietf.org From: Elwyn Davies Subject: Comments on draft-tschofenig-v6ops-secure-tunnels-03.txt 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=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi. This seems a useful guide to using v6 in v4 tunnels in conjunction with IPsec. I have a few comments (but not much in the way of contributions to the open issues): S3.2: Last para: A bit more explanation of the alternative solution would help. S3.2: Some mention of potential scalability issues here - if i understand correctly a tunnel and SA per host in the site is needed. S5.1 (and elsewhere): The acronyms IDc1 and IDcr may need expansion S5 (all sections): My understanding (which may be wrong) is that SAs carry either unicast or multicast traffic... some of the SAs defined in the SPD seem to be intended to carry both unicast neighbor discovery/SAAC and the associated MLD Join messages. If this is true separate SAs will be needed but they can be more tightly defined ... the unicast ones are link local to link local and the multicast ones have a restricted set of multicast groups (All Nodes, All Routers, DHCP groups and Solicited Node groups). S5: Where the SPD rule applies to a prefix, it might be clearer to use a different operator (like ~) to indicate prefix matching rather than equality (=). S5:the packet format piece at the end of the section probably deservces a separate section. I have also made a number of editorial suggestions directly to the document editor. Regards, Elwyn From owner-v6ops@ops.ietf.org Tue Jan 18 16:52:02 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11059 for ; Tue, 18 Jan 2005 16:52:02 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cr1BX-0000cC-Hh for v6ops-data@psg.com; Tue, 18 Jan 2005 21:46:47 +0000 Received: from [203.254.224.24] (helo=mailout1.samsung.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cr1BU-0000au-ST for v6ops@ops.ietf.org; Tue, 18 Jan 2005 21:46:45 +0000 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IAJ00E018HXHU@mailout1.samsung.com> for v6ops@ops.ietf.org; Wed, 19 Jan 2005 06:46:45 +0900 (KST) Received: from ep_ms3_bk (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IAJ00CYO8HXUW@mailout1.samsung.com> for v6ops@ops.ietf.org; Wed, 19 Jan 2005 06:46:45 +0900 (KST) Received: from localhost (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with SMTP id <0IAJ00F5Q8HWAG@ms3.samsung.com> for v6ops@ops.ietf.org; Wed, 19 Jan 2005 06:46:44 +0900 (KST) Date: Tue, 18 Jan 2005 21:46:41 +0000 (GMT) From: Daniel Park Subject: (RFC2766) NATPT-BIS X-Sender: =?euc-kr?B?U2Ftc3VuZyBFbGVjdHJvbmljc6HnTW9iaQ==?= =?euc-kr?B?bGUgUGxhdGZvcm0gTGFioedFbmdpbmVlcg==?= To: v6ops@ops.ietf.org, soohong.park@samsung.com Reply-to: soohong.park@samsung.com Message-id: <7063510.1106084790943.JavaMail.weblogic@ep_ml16> MIME-version: 1.0 Content-type: text/plain; charset=euc-kr Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20050118214630940@soohong.park X-MTR: 20050118214630940@soohong.park X-EPLocale: en_US.euc-kr X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,PRIORITY_NO_NAME, SUBJ_ALL_CAPS autolearn=no version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Hello v6ops folks. Senthil, Pyda, Tony and myself did a new bis-work and below NATPT-bis was proposed. http://www.ietf.org/internet-drafts/draft-daniel-natpt-bis-00.txt Major changes are as follows; o Removed all ALG stuff (DNS-ALG, FTP-ALG) and added a new section as "Support for application level transparency" to be considered a protocol carrying the IP address and port in its payload for the data session require ALG. o Added "Static address mapping within NAT-PT" section to support bi- directional NAT-PT operation. o Added a section on use case scenarios to help readers understood the rationale behind NAT-PT deployments. o Specified and reorganized translation phase within NAT-PT. All comments are highly welcome. Thanks. Daniel (Soohong Daniel Park) Mobile Platform Laboratory. SAMSUNG Electronics From owner-v6ops@ops.ietf.org Wed Jan 19 04:34: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 EAA24336 for ; Wed, 19 Jan 2005 04:34:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CrCC2-000IAH-Bk for v6ops-data@psg.com; Wed, 19 Jan 2005 09:32:02 +0000 Received: from [81.187.81.51] (helo=smtp.aaisp.net.uk) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CrCC0-000I9w-3I for v6ops@ops.ietf.org; Wed, 19 Jan 2005 09:32:00 +0000 Received: from [81.187.254.249] (helo=study.dial.pipex.com) by smtp.aaisp.net.uk with esmtp (Exim 4.42) id 1CrCBx-0005hJ-1O for v6ops@ops.ietf.org; Wed, 19 Jan 2005 09:31:57 +0000 Message-Id: <6.2.0.14.0.20050119092531.01ebfe18@imap.dial.pipex.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 19 Jan 2005 09:34:27 +0000 To: v6ops@ops.ietf.org From: Elwyn Davies Subject: Comments on draft-tschofenig-v6ops-secure-tunnels-03.txt - updated 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=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Thinking further about these comments, i realised I had not been thinking clearly about the S5 issue on unicast vs multicast SAs. The SA is of course for the tunnel which is strictly unicast, so the issue I raised is a red herring. However, it also occurred to me that the specifications intended to cope with neighbor discovery and SAAC may be unnecessarily wide since the only relevant traffic is between the two tunnel end points which constitute the (point-to-point) link in these cases. Regards, Elwyn ============================== Comments copied from original message: Hi. This seems a useful guide to using v6 in v4 tunnels in conjunction with IPsec. I have a few comments (but not much in the way of contributions to the open issues): S3.2: Last para: A bit more explanation of the alternative solution would help. S3.2: Some mention of potential scalability issues here - if i understand correctly a tunnel and SA per host in the site is needed. S5.1 (and elsewhere): The acronyms IDc1 and IDcr may need expansion [Deleted point about need for multicast SAs] S5: Where the SPD rule applies to a prefix, it might be clearer to use a different operator (like ~) to indicate prefix matching rather than equality (=). S5:the packet format piece at the end of the section probably deserves a separate section. I have also made a number of editorial suggestions directly to the document editor. Regards, Elwyn From owner-v6ops@ops.ietf.org Wed Jan 19 07:31: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 HAA07022 for ; Wed, 19 Jan 2005 07:31:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CrExJ-000MCh-SD for v6ops-data@psg.com; Wed, 19 Jan 2005 12:29:01 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CrExG-000MBi-Jg for v6ops@ops.ietf.org; Wed, 19 Jan 2005 12:28:59 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0JCSuc08797; Wed, 19 Jan 2005 14:28:56 +0200 Date: Wed, 19 Jan 2005 14:28:56 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: jonne.soininen@nokia.com Subject: Send in requests for agenda slots 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) We're probably scheduling one 2h or 2.5h session for IETF62. Please send in agenda requests to the co-chairs. Describe at least: - the title of the talk - the amount of time you'd want - which draft (or other) would be basis for discussion [operational presentations would also be OK] - who would be presenting/leading the discussion - what is the goal of the agenda item - (if relevant) how this relates to the business of the WG Thanks! (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 Wed Jan 19 11:51:34 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27816 for ; Wed, 19 Jan 2005 11:51:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CrJ19-000P4s-Eh for v6ops-data@psg.com; Wed, 19 Jan 2005 16:49:15 +0000 Received: from [131.228.20.22] (helo=mgw-x2.nokia.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CrJ15-000P4W-T3 for v6ops@ops.ietf.org; Wed, 19 Jan 2005 16:49:12 +0000 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0JGn8l20334 for ; Wed, 19 Jan 2005 18:49:09 +0200 (EET) X-Scanned: Wed, 19 Jan 2005 18:49:04 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j0JGn4XI007784 for ; Wed, 19 Jan 2005 18:49:04 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00WuAmRH; Wed, 19 Jan 2005 18:49:00 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 j0JGmiU29761 for ; Wed, 19 Jan 2005 18:48:44 +0200 (EET) Received: from essat-vlan154-2-22418.ntc.nokia.com ([172.21.224.18]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 19 Jan 2005 18:48:38 +0200 Subject: Conclusion: RE: Interest to have as an WG item: draft-tschofenig-v6ops-secure -tunnels-03.txt From: "Soininen Jonne (Nokia-NET/Helsinki)" To: v6ops@ops.ietf.org In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F05649B30@mchp905a.mch.sbs.de> References: <2A8DB02E3018D411901B009027FD3A3F05649B30@mchp905a.mch.sbs.de> Content-Type: text/plain; charset=UTF-8 Message-Id: <1106153316.4713.417.camel@essat-vlan154-2-22418.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 19 Jan 2005 18:48:38 +0200 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 19 Jan 2005 16:48:38.0418 (UTC) FILETIME=[B95BBF20:01C4FE46] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello, (chair hat on) there was not an overly enthusiastic response during the two week period. Though, the interest seems to have risen toward the end of the period, still very few people responded.=20 I would conclude that there was not enough consensus to take the document as WG item at this point. I hope, however, the authors of the document could continue the work. And I would like to people read the document and comment. Let's check the situation later if more interest raises. Cheers, Jonne. On Fri, 2005-01-14 at 16:32, ext Tschofenig Hannes wrote: > hi alain,=20 >=20 > thanks for your comment. >=20 > to show you the difference between a document that describes how to use > ikev1/ikev2 (and ipsec) to provide security of something you might also w= ant > to look at the mip6 working group where documents exist that describe how > ikev1/ipsec is used to secure the mipv6 signaling between the mn and the = ha > (and the same for ikev2):=20 > http://www.ietf.org/rfc/rfc3776.txt > http://www.ietf.org/internet-drafts/draft-ietf-mip6-ikev2-ipsec-00.txt >=20 > the v6ops-secure-tunnels document is of this type. we are, however, not > extendig ikev2 (luckily).=20 >=20 > a tutorial (as a comparison) looks like:=20 > http://ftp.iasi.rdsnet.ro/mirrors/nis.nsf.net/internet-drafts/draft-ietf-= ips > ec-ikev2-tutorial-01.txt >=20 > ciao > hannes > =20 >=20 > > -----Original Message----- > > From: Alain Durand [mailto:Alain.Durand@Sun.COM]=20 > > Sent: Freitag, 14. J=C3=A4nner 2005 14:06 > > To: Pekka Savola > > Cc: v6ops@ops.ietf.org > > Subject: Re: Interest to have as an WG item:=20 > > draft-tschofenig-v6ops-secure-tunnels-03.txt > >=20 > > Well, I'm not a security expert, far from that, so I'm not=20 > > sure I can comment on the quality of the security assertions. > > However, at fist glance, it seems that this is a tutorial on ikev1 & > > ikev2 > > in the context of IPv6... > > I other words, it is unclear to me why we need this document=20 > > in v6Ops and why it is not homed in a security related wg IF=20 > > there is a need for such a document. > >=20 > > On another note, some of the techniques described here may be=20 > > useful in the context of v6tc... > >=20 > > - Alain. > >=20 > >=20 --=20 Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Wed Jan 19 12:59:10 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06302 for ; Wed, 19 Jan 2005 12:59:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CrK5T-0006rW-DD for v6ops-data@psg.com; Wed, 19 Jan 2005 17:57:47 +0000 Received: from [66.163.170.1] (helo=smtp815.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1CrK5Q-0006qu-A6 for v6ops@ops.ietf.org; Wed, 19 Jan 2005 17:57:44 +0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp815.mail.sc5.yahoo.com with SMTP; 19 Jan 2005 17:57:43 -0000 Message-ID: <005d01c4fe50$610ce3d0$861167c0@adithya> From: "Mohan Parthasarathy" To: , "Elwyn Davies" References: <6.2.0.14.0.20050118194343.01ee5c38@imap.dial.pipex.com> Subject: Re: Comments on draft-tschofenig-v6ops-secure-tunnels-03.txt Date: Wed, 19 Jan 2005 09:57:44 -0800 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.3 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 Elwyn, Thanks for your comments.. > > This seems a useful guide to using v6 in v4 tunnels in conjunction with IPsec. > > I have a few comments (but not much in the way of contributions to the open > issues): > S3.2: Last para: A bit more explanation of the alternative solution would help. Ok. > S3.2: Some mention of potential scalability issues here - if i understand > correctly a tunnel and SA per host in the site is needed. Yes, we can mention that in the next revision. > S5.1 (and elsewhere): The acronyms IDc1 and IDcr may need expansion Ok. > S5 (all sections): My understanding (which may be wrong) is that SAs carry > either unicast or multicast traffic... some of the SAs defined in the SPD > seem to be intended to carry both unicast neighbor discovery/SAAC and the > associated MLD Join messages. If this is true separate SAs will be needed Yes. But the intention is to have fewer SPD entries and protect most of the link-local traffic. Otherwise, you need to have more SPD entries to protect the different types of link-local traffic between the two end points. > but they can be more tightly defined ... the unicast ones are link local > to link local and the multicast ones have a restricted set of multicast > groups (All Nodes, All Routers, DHCP groups and Solicited Node groups). > > S5: Where the SPD rule applies to a prefix, it might be clearer to use a > different operator (like ~) to indicate prefix matching rather than > equality (=). Okay. > S5:the packet format piece at the end of the section probably deservces a > separate section. > Okay. > I have also made a number of editorial suggestions directly to the document > editor. > Thanks mohan > Regards, > Elwyn > > > From owner-v6ops@ops.ietf.org Wed Jan 19 13:17:10 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07928 for ; Wed, 19 Jan 2005 13:17:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CrKNv-00096Z-Kx for v6ops-data@psg.com; Wed, 19 Jan 2005 18:16:51 +0000 Received: from [81.187.81.51] (helo=smtp.aaisp.net.uk) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CrKNu-000968-7P for v6ops@ops.ietf.org; Wed, 19 Jan 2005 18:16:50 +0000 Received: from [81.187.254.249] (helo=study.dial.pipex.com) by smtp.aaisp.net.uk with esmtp (Exim 4.42) id 1CrKNt-00030J-1l; Wed, 19 Jan 2005 18:16:49 +0000 Message-Id: <6.2.0.14.0.20050119181818.01ec30d8@imap.dial.pipex.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 19 Jan 2005 18:19:25 +0000 To: "Mohan Parthasarathy" , From: Elwyn Davies Subject: Re: Comments on draft-tschofenig-v6ops-secure-tunnels-03.txt In-Reply-To: <005d01c4fe50$610ce3d0$861167c0@adithya> References: <6.2.0.14.0.20050118194343.01ee5c38@imap.dial.pipex.com> <005d01c4fe50$610ce3d0$861167c0@adithya> 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=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk OK.. good. But see my subsequent email on the link local/multicast story... i was totally wrong in this one! Elwyn At 17:57 19/01/2005, Mohan Parthasarathy wrote: > Elwyn, > >Thanks for your comments.. > > > > > This seems a useful guide to using v6 in v4 tunnels in conjunction with > IPsec. > > > > I have a few comments (but not much in the way of contributions to the > open > > issues): > > S3.2: Last para: A bit more explanation of the alternative solution > would help. > >Ok. > > > S3.2: Some mention of potential scalability issues here - if i understand > > correctly a tunnel and SA per host in the site is needed. > >Yes, we can mention that in the next revision. > > > S5.1 (and elsewhere): The acronyms IDc1 and IDcr may need expansion > >Ok. > > > S5 (all sections): My understanding (which may be wrong) is that SAs carry > > either unicast or multicast traffic... some of the SAs defined in the SPD > > seem to be intended to carry both unicast neighbor discovery/SAAC and the > > associated MLD Join messages. If this is true separate SAs will be needed > >Yes. But the intention is to have fewer SPD entries and protect most of the >link-local traffic. Otherwise, you need to have more SPD entries to >protect the different types of link-local traffic between the two end points. > > > but they can be more tightly defined ... the unicast ones are link local > > to link local and the multicast ones have a restricted set of multicast > > groups (All Nodes, All Routers, DHCP groups and Solicited Node groups). > > > > S5: Where the SPD rule applies to a prefix, it might be clearer to use a > > different operator (like ~) to indicate prefix matching rather than > > equality (=). > >Okay. > > > S5:the packet format piece at the end of the section probably deservces a > > separate section. > > >Okay. > > > I have also made a number of editorial suggestions directly to the > document > > editor. > > >Thanks >mohan > > > Regards, > > Elwyn > > > > > > From owner-v6ops@ops.ietf.org Thu Jan 20 05:34:22 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14006 for ; Thu, 20 Jan 2005 05:34:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CrZaQ-000Ev8-O5 for v6ops-data@psg.com; Thu, 20 Jan 2005 10:30:46 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CrZaM-000Eul-G8 for v6ops@ops.ietf.org; Thu, 20 Jan 2005 10:30:43 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0KAUet09506; Thu, 20 Jan 2005 12:30:40 +0200 Date: Thu, 20 Jan 2005 12:30:40 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: jim.bound@hp.com Subject: RE: Feedback on proposed charter from the IESG In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0832FFF4@tayexc13.americas.cpqcorp.net> Message-ID: References: <9C422444DE99BC46B3AD3C6EAFC9711B0832FFF4@tayexc13.americas.cpqcorp.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-1782308367-1106217040=:8776" 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-1782308367-1106217040=:8776 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Hi, Attached is an attempt to rephrase the charter slightly, mainly taking Brian's suggestion with a slight edit. Htmlwdiff is at: http://www.netcore.fi/pekkas/ietf/temp/v6ops-dow-20050120-diff.html Comments? Inline I respond to two of Jim's points I didn't apply at this point. On Wed, 12 Jan 2005, Bound, Jim wrote: >> Do you have suggestions for, e.g.: >> - what classes of documents are such that we should be working on >> (with sufficient specifity so it doesn't seem open-ended), > > I believe current input is good and basically needs of the operational > community for deployment. > > But I want to note what "operational community" means and maybe we need > to call that out from v6ops view very clearly: > > Operational Community: > > 1. Providers (telco, ISPs, IXs, Mobile Greenfield to deploy 3G IMS et al > they are all different) > > 2. Enterprises that require operational work from within the IETF for > Enterprise operation. > > 3. Liaison consortias for deployment that provide v6ops via IETF > operational requirements. Examples are IPv6 Forum, ICANN, NANOG, > Registries, ATIS www.atis.org, NCOIC www.ncoic.org, etc. Do these need to go in charter? I think everyone agrees on the first two, but the third is likely trickier, because the IETF has a formal liaison only with ICANN (a technical liaison group). Obviuously, anyone from those consortias or forums can come and speak up in the mailing-list, contact the IETF in a more formal manner, etc. >> Description of Working Group: >> >> The global deployment of IPv6 is underway, creating an >> IPv4/IPv6 Internet consisting of IPv4-only, IPv6-only and >> IPv4/IPv6 networks and nodes. This deployment must be >> properly handled to avoid the division of the Internet into >> separate IPv4 and IPv6 networks while ensuring addressing and >> connectivity for all IPv4 and IPv6 nodes. > > I think the above needs re-wording. > > Suggested replacement text: > > The global deployment of IPv6 is in process. As the deployment evolves > some basic operational requirements will exist, and new operational > requirements will be learned. The IPv6 Operations Working Group is an > IETF working group to work on these operational requirements. > > To scope the work for the IPv6 Operations Working Group we define and > provide examples of work within the scope of operational requirements. I'm a bit hesitant about this for a couple of reasons: 1) people will ask, "_what_ operational requirements?", 2) the text can be read to mean "v6ops defines operational requirements document(s)" which is probably undesirable, and 3) operational requirements from operators etc. are currently a source of where new initiatives for new work come from, not the only one. Therefore I'm hesitant to writing this about operational requirements. Obviously, however, if operators etc. present us with _their_ operational requirements, the WG should take those into serious consideration.. but I don't see why that would need to be in the charter. --1589707168-1782308367-1106217040=:8776 Content-Type: TEXT/plain; charset=US-ASCII; name="v6ops-dow-20050120.txt" Content-ID: Content-Description: Content-Disposition: attachment; filename="v6ops-dow-20050120.txt" Content-Transfer-Encoding: BASE64 RGVzY3JpcHRpb24gb2YgV29ya2luZyBHcm91cDoNCg0KVGhlIGdsb2JhbCBk ZXBsb3ltZW50IG9mIElQdjYgaXMgdW5kZXJ3YXksIGNyZWF0aW5nIGFuIElQ djQvSVB2Ng0KSW50ZXJuZXQgY29uc2lzdGluZyBvZiBJUHY0LW9ubHksIElQ djYtb25seSBhbmQgSVB2NC9JUHY2IG5ldHdvcmtzIGFuZA0Kbm9kZXMuICBU aGlzIGRlcGxveW1lbnQgbXVzdCBiZSBwcm9wZXJseSBoYW5kbGVkIHRvIGF2 b2lkIHRoZSBkaXZpc2lvbg0Kb2YgdGhlIEludGVybmV0IGludG8gc2VwYXJh dGUgSVB2NCBhbmQgSVB2NiBuZXR3b3JrcyB3aGlsZSBlbnN1cmluZw0KYWRk cmVzc2luZyBhbmQgY29ubmVjdGl2aXR5IGZvciBhbGwgSVB2NCBhbmQgSVB2 NiBub2Rlcy4NCg0KVGhlIElQdjYgT3BlcmF0aW9ucyBXb3JraW5nIEdyb3Vw ICh2Nm9wcykgZGV2ZWxvcHMgZ3VpZGVsaW5lcyBmb3IgdGhlDQpvcGVyYXRp b24gb2YgYSBzaGFyZWQgSVB2NC9JUHY2IEludGVybmV0IGFuZCBwcm92aWRl cyBvcGVyYXRpb25hbA0KZ3VpZGFuY2Ugb24gaG93IHRvIGRlcGxveSBJUHY2 IGludG8gZXhpc3RpbmcgSVB2NC1vbmx5IG5ldHdvcmtzLA0KYXMgd2VsbCBh cyBpbnRvIG5ldyBuZXR3b3JrIGluc3RhbGxhdGlvbnMuDQoNClRoZSBtYWlu IGZvY3VzIG9mIHRoZSB2Nm9wcyBXRyBpcyB0byBsb29rIGF0IHRoZSBpbW1l ZGlhdGUNCmRlcGxveW1lbnQgaXNzdWVzOyBtb3JlIGFkdmFuY2VkIHN0YWdl cyBvZiBkZXBsb3ltZW50IGFuZCB0cmFuc2l0aW9uDQphcmUgYSBsb3dlciBw cmlvcml0eS4NCg0KVGhlIGdvYWxzIG9mIHRoZSB2Nm9wcyB3b3JraW5nIGdy b3VwIGFyZToNCg0KMS4gU29saWNpdCBpbnB1dCBmcm9tIG5ldHdvcmsgb3Bl cmF0b3JzIGFuZCB1c2VycyB0byBpZGVudGlmeQ0KICBvcGVyYXRpb25hbCBp c3N1ZXMgd2l0aCB0aGUgSVB2NC9JUHY2IEludGVybmV0LCBhbmQNCiAgZGV0 ZXJtaW5lIHNvbHV0aW9ucyBvciB3b3JrYXJvdW5kcyB0byB0aG9zZSBpc3N1 ZXMuICBUaGVzZSBpc3N1ZXMNCiAgd2lsbCBiZSBkb2N1bWVudGVkIGluIElu Zm9ybWF0aW9uYWwgb3IgQkNQIFJGQ3MsIG9yIGluDQogIEludGVybmV0LURy YWZ0cy4NCg0KICBUaGlzIHdvcmsgc2hvdWxkIHByaW1hcmlseSBiZSBjb25k dWN0ZWQgYnkgdGhvc2UgYXJlYXMgYW5kIFdHcw0KICB3aGljaCBhcmUgcmVz cG9uc2libGUgYW5kIGJlc3QgZml0IHRvIGFuYWx5emUgdGhlc2UgcHJvYmxl bXMsIGJ1dA0KICB2Nm9wcyBtYXkgYWxzbyBjb29wZXJhdGUgaW4gZm9jdXNp bmcgc3VjaCB3b3JrLg0KDQoyLiBQdWJsaXNoIEluZm9ybWF0aW9uYWwgb3Ig QkNQIFJGQ3MgdGhhdCBpZGVudGlmeSBwb3RlbnRpYWwgc2VjdXJpdHkNCiAg cmlza3MgaW4gdGhlIG9wZXJhdGlvbiBvZiBzaGFyZWQgSVB2NC9JUHY2IG5l dHdvcmtzLCBhbmQgZG9jdW1lbnQNCiAgb3BlcmF0aW9uYWwgcHJhY3RpY2Vz IHRvIGVsaW1pbmF0ZSBvciBtaXRpZ2F0ZSB0aG9zZSByaXNrcy4NCg0KICBU aGlzIHdvcmsgd2lsbCBiZSBkb25lIGluIGNvb3BlcmF0aW9uIHdpdGggdGhl IFNlY3VyaXR5IGFyZWEgYW5kDQogIG90aGVyIHJlbGV2YW50IGFyZWFzIG9y IHdvcmtpbmcgZ3JvdXBzLg0KDQozLiBBcyBhIHBhcnRpY3VsYXIgaW5zdGFu Y2Ugb2YgKDEpIGFuZCAoMiksIHByb3ZpZGUgZmVlZGJhY2sgdG8NCiAgdGhl IElQdjYgV0cgcmVnYXJkaW5nIHBvcnRpb25zIG9mIHRoZSBJUHY2IHNwZWNp ZmljYXRpb25zIHRoYXQNCiAgY2F1c2UsIG9yIGFyZSBsaWtlbHkgdG8gY2F1 c2UsIG9wZXJhdGlvbmFsIG9yIHNlY3VyaXR5IGNvbmNlcm5zLA0KICBhbmQg d29yayB3aXRoIHRoZSBJUHY2IFdHIHRvIHJlc29sdmUgdGhvc2UgY29uY2Vy bnMuICBUaGlzIGZlZWRiYWNrDQogIHdpbGwgYmUgcHVibGlzaGVkIGluIElu dGVybmV0LURyYWZ0cyBvciBSRkNzLg0KDQo0LiBQdWJsaXNoIEluZm9ybWF0 aW9uYWwgb3IgQkNQIFJGQ3MgdGhhdCBpZGVudGlmeSBhbmQgYW5hbHl6ZSBz b2x1dGlvbnMNCiAgZm9yIGRlcGxveWluZyBJUHY2IHdpdGhpbiBjb21tb24g bmV0d29yayBlbnZpcm9ubWVudHMsIHN1Y2ggYXMNCiAgSVNQIE5ldHdvcmtz IChpbmNsdWRpbmcgQ29yZSwgSEZDL0NhYmxlLCBEU0wgJiBEaWFsLXVwIG5l dHdvcmtzKSwNCiAgRW50ZXJwcmlzZSBOZXR3b3JrcywgVW5tYW5hZ2VkIE5l dHdvcmtzIChIb21lL1NtYWxsIE9mZmljZSksIGFuZA0KICBDZWxsdWxhciBO ZXR3b3Jrcy4NCg0KICBUaGVzZSBkb2N1bWVudHMgc2hvdWxkIHNlcnZlIGFz IHVzZWZ1bCBndWlkZXMgdG8gbmV0d29yaw0KICBvcGVyYXRvcnMgYW5kIHVz ZXJzIG9uIHBvc3NpYmxlIHdheXMgaG93IHRvIGRlcGxveSBJUHY2IHdpdGhp biB0aGVpcg0KICBleGlzdGluZyBJUHY0IG5ldHdvcmtzLCBhcyB3ZWxsIGFz IGluIG5ldyBuZXR3b3JrIGluc3RhbGxhdGlvbnMuDQoNCiAgVGhlc2UgZG9j dW1lbnRzIHNob3VsZCBub3QgYmUgbm9ybWF0aXZlIGd1aWRlcyBmb3IgSVB2 NiBkZXBsb3ltZW50LA0KICBhbmQgdGhlIHByaW1hcnkgaW50ZW50IGlzIG5v dCBjYXB0dXJlIHRoZSBuZWVkcyBmb3IgbmV3IHNvbHV0aW9ucywNCiAgYnV0 IHJhdGhlciBkZXNjcmliZSB3aGljaCBhcHByb2FjaGVzIHdvcmsgYW5kIHdo aWNoIGRvIG5vdC4NCg0KSVB2NiBvcGVyYXRpb25hbCBhbmQgZGVwbG95bWVu dCBpc3N1ZXMgd2l0aCBzcGVjaWZpYyBwcm90b2NvbHMgb3INCnRlY2hub2xv Z2llcyAoc3VjaCBhcyBBcHBsaWNhdGlvbnMsIFRyYW5zcG9ydCBQcm90b2Nv bHMsIFJvdXRpbmcNClByb3RvY29scywgRE5TIG9yIFN1Yi1JUCBQcm90b2Nv bHMpIGFyZSB0aGUgcHJpbWFyeSByZXNwb25zaWJpbGl0eSBvZg0KdGhlIGdy b3VwcyBvciBhcmVhcyByZXNwb25zaWJsZSBmb3IgdGhvc2UgcHJvdG9jb2xz IG9yIHRlY2hub2xvZ2llcy4NCkhvd2V2ZXIsIHRoZSB2Nm9wcyBXRyBtYXkg cHJvdmlkZSBpbnB1dCB0byB0aG9zZSBhcmVhcy9ncm91cHMsIGFzDQpuZWVk ZWQsIGFuZCBjb29wZXJhdGUgd2l0aCB0aG9zZSBhcmVhcy9ncm91cHMgaW4g cmV2aWV3aW5nIHNvbHV0aW9ucw0KdG8gSVB2NiBvcGVyYXRpb25hbCBhbmQg ZGVwbG95bWVudCBwcm9ibGVtcy4NCg0KRnV0dXJlIHdvcmsgaXRlbXMgd2l0 aGluIHRoaXMgc2NvcGUgd2lsbCBiZSBhZG9wdGVkIGJ5IHRoZSBXRyBvbmx5 IGlmDQp0aGVyZSBpcyBhIHN1YnN0YW50aWFsIGV4cHJlc3Npb24gb2YgaW50 ZXJlc3QgZnJvbSB0aGUgY29tbXVuaXR5IGFuZA0KaWYgdGhlIHdvcmsgY2xl YXJseSBkb2VzIG5vdCBmaXQgZWxzZXdoZXJlIGluIHRoZSBJRVRGLg0KDQpT cGVjaWZ5aW5nIGFueSBwcm90b2NvbHMgb3IgdHJhbnNpdGlvbiBtZWNoYW5p c21zIGlzIG91dCBvZiBzY29wZSBvZg0KdGhlIFdHLg0KDQpHb2FscyBhbmQg TWlsZXN0b25lczoNCg0KIE1hciAwNQkgQWRvcHQgZG9jdW1lbnQgZGVzY3Jp YmluZyBob3cgdG8gdXNlIElQc2VjIHdpdGggZHJhZnQtaWV0Zi12Nm9wcy1t ZWNoLXYyIGFzIFdHIGl0ZW0NCiBNYXIgMDUgIEFkb3B0IElQdjYgU2VjdXJp dHkgT3ZlcnZpZXcgYXMgV0cgaXRlbQ0KIE1hciAwNSAgU3VibWl0IGRvY3Vt ZW50IGRlc2NyaWJpbmcgaXNzdWVzIHdpdGggTkFULVBUIHRvIElFU0cgZm9y IEluZm8NCiBNYXIgMDUgIFN1Ym1pdCBJUHY2IGRlcGxveW1lbnQgdXNpbmcg VkxBTnMgdG8gSUVTRyBmb3IgSW5mbw0KIEFwciAwNSAgQWRvcHQgSVNQIElQ djYgRGVwbG95bWVudCBTY2VuYXJpb3MgaW4gQnJvYWRiYW5kIEFjY2VzcyBO ZXR3b3JrcyBhcyBXRyBpdGVtDQogQXByIDA1ICBBZG9wdCBJUHY2IE5ldHdv cmsgQXJjaGl0ZWN0dXJlIFByb3RlY3Rpb24gYXMgV0cgaXRlbQ0KIEFwciAw NSAgRW5zdXJlIGRyYWZ0LWlldGYtdjZvcHMtdjZvbmJ5ZGVmYXVsdCBrZWVw cyBnb2luZyBmb3J3YXJkIGZvciBSRkMgcHVibGljYXRpb24NCiBNYXkgMDUg IFN1Ym1pdCBkb2N1bWVudCBvbiBJUHNlYyB3LyBkcmFmdC1pZXRmLXY2b3Bz LW1lY2gtdjIgdG8gSUVTRyBmb3IgSW5mbw0KIE1heSAwNSAgU3VibWl0IEVu dGVycHJpc2UgRGVwbG95bWVudCBBbmFseXNpcyB0byBJRVNHIGZvciBJbmZv DQogSnVuIDA1ICBTdWJtaXQgSVB2NiBOZXR3b3JrIEFyY2hpdGVjdHVyZSBQ cm90ZWN0aW9uIHRvIElFU0cgZm9yIEluZm8NCiBKdWwgMDUgIFN1Ym1pdCBJ UHY2IFNlY3VyaXR5IE92ZXJ2aWV3IHRvIElFU0cgZm9yIEluZm8NCiBKdWwg MDUgIFN1Ym1pdCBJU1AgSVB2NiBEZXBsb3ltZW50IFNjZW5hcmlvcyBpbiBC cm9hZGJhbmQgQWNjZXNzIE5ldHdvcmtzIHRvIElFU0cgZm9yIEluZm8NCg0K --1589707168-1782308367-1106217040=:8776-- From owner-v6ops@ops.ietf.org Thu Jan 20 15:36: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 PAA03663 for ; Thu, 20 Jan 2005 15:36:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Crj0n-000CRa-0U for v6ops-data@psg.com; Thu, 20 Jan 2005 20:34:37 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Crj0j-000CIl-8K for v6ops@ops.ietf.org; Thu, 20 Jan 2005 20:34:33 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0KKYVP25940 for ; Thu, 20 Jan 2005 22:34:31 +0200 Date: Thu, 20 Jan 2005 22:34:31 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: RFC 3974 on SMTP Operational Experience in Mixed IPv4/v6 Environments (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Content-ID: 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 FYI (this was reviewed but not a product of this WG). ---------- Forwarded message ---------- Date: Thu, 20 Jan 2005 10:37:42 -0800 From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org Cc: rfc-editor@rfc-editor.org Subject: RFC 3974 on SMTP Operational Experience in Mixed IPv4/v6 Environments A new Request for Comments is now available in online RFC libraries. RFC 3974 Title: SMTP Operational Experience in Mixed IPv4/v6 Environments Author(s): M. Nakamura, J. Hagino Status: Informational Date: January 2005 Mailbox: motonori@media.kyoto-u.ac.jp, itojun@iijlab.net Pages: 10 Characters: 22729 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-motonori-dualstack-smtp-requirement-01.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3974.txt This document discusses SMTP operational experiences in IPv4/v6 dual stack environments. As IPv6-capable SMTP servers are deployed, it has become apparent that certain configurations of MX records are necessary for stable dual-stack (IPv4 and IPv6) SMTP operation. This document clarifies the existing problems in the transition period between IPv4 SMTP and IPv6 SMTP. It also defines operational requirements for stable IPv4/v6 SMTP operation. This document does not define any new protocol. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. From owner-v6ops@ops.ietf.org Fri Jan 21 02:27: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 CAA12824 for ; Fri, 21 Jan 2005 02:27:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CrtAV-0006sx-L6 for v6ops-data@psg.com; Fri, 21 Jan 2005 07:25:19 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CrtAT-0006sc-0H for v6ops@ops.ietf.org; Fri, 21 Jan 2005 07:25:17 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0L7PAD07999 for ; Fri, 21 Jan 2005 09:25:10 +0200 Date: Fri, 21 Jan 2005 09:25:09 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Take ISP BB scenarios as WG document? 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) 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 Fri Jan 21 03:24: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 DAA17863 for ; Fri, 21 Jan 2005 03:24:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cru4s-000GZA-1q for v6ops-data@psg.com; Fri, 21 Jan 2005 08:23:34 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cru4n-000GVa-Ke for v6ops@ops.ietf.org; Fri, 21 Jan 2005 08:23:30 +0000 Received: from [172.19.99.137] ([80.25.193.196]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000721320.msg for ; Fri, 21 Jan 2005 09:24:20 +0100 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 21 Jan 2005 09:23:06 +0100 Subject: Re:Conclusion: RE: Interest to have as an WG item: draft-tschofenig-v6ops-secure -tunnels-03.txt From: JORDI PALET MARTINEZ To: "owner-v6ops@ops.ietf.org" Message-ID: In-Reply-To: <1106153316.4713.417.camel@essat-vlan154-2-22418.ntc.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-MDRemoteIP: 80.25.193.196 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Fri, 21 Jan 2005 09:24:22 +0100 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_QP_LONG_LINE autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Jonne, all, This is exactly what I think is unfair and I tried to describe several times. In other occasions, other documents with similar level of inputs (or even lower !) have been accepted as WG items. Where is the limit between something being accepted and not ? If we don't have a clear rule, then we have nothing ;-) So are we going then to apply the same rule to those documents that have already being accepted ? Or in the other way around, are we going to accept this document now ? Regards, Jordi > De: "Soininen Jonne (Nokia-NET/Helsinki)" > Responder a: "owner-v6ops@ops.ietf.org" > Fecha: Wed, 19 Jan 2005 18:48:38 +0200 > Para: > Asunto: Conclusion: RE: Interest to have as an WG item: > draft-tschofenig-v6ops-secure -tunnels-03.txt >=20 > Hello, >=20 > (chair hat on) > there was not an overly enthusiastic response during the two week > period. Though, the interest seems to have risen toward the end of the > period, still very few people responded. >=20 > I would conclude that there was not enough consensus to take the > document as WG item at this point. >=20 > I hope, however, the authors of the document could continue the work. > And I would like to people read the document and comment. >=20 > Let's check the situation later if more interest raises. >=20 > Cheers, >=20 > Jonne. >=20 > On Fri, 2005-01-14 at 16:32, ext Tschofenig Hannes wrote: >> hi alain,=20 >>=20 >> thanks for your comment. >>=20 >> to show you the difference between a document that describes how to use >> ikev1/ikev2 (and ipsec) to provide security of something you might also want >> to look at the mip6 working group where documents exist that describe how >> ikev1/ipsec is used to secure the mipv6 signaling between the mn and the ha >> (and the same for ikev2): >> http://www.ietf.org/rfc/rfc3776.txt >> http://www.ietf.org/internet-drafts/draft-ietf-mip6-ikev2-ipsec-00.txt >>=20 >> the v6ops-secure-tunnels document is of this type. we are, however, not >> extendig ikev2 (luckily). >>=20 >> a tutorial (as a comparison) looks like: >> http://ftp.iasi.rdsnet.ro/mirrors/nis.nsf.net/internet-drafts/draft-ietf-ips >> ec-ikev2-tutorial-01.txt >>=20 >> ciao >> hannes >> =20 >>=20 >>> -----Original Message----- >>> From: Alain Durand [mailto:Alain.Durand@Sun.COM] >>> Sent: Freitag, 14. J=E4nner 2005 14:06 >>> To: Pekka Savola >>> Cc: v6ops@ops.ietf.org >>> Subject: Re: Interest to have as an WG item: >>> draft-tschofenig-v6ops-secure-tunnels-03.txt >>>=20 >>> Well, I'm not a security expert, far from that, so I'm not >>> sure I can comment on the quality of the security assertions. >>> However, at fist glance, it seems that this is a tutorial on ikev1 & >>> ikev2 >>> in the context of IPv6... >>> I other words, it is unclear to me why we need this document >>> in v6Ops and why it is not homed in a security related wg IF >>> there is a need for such a document. >>>=20 >>> On another note, some of the techniques described here may be >>> useful in the context of v6tc... >>>=20 >>> - Alain. >>>=20 >>>=20 > --=20 > Jonne Soininen > Nokia >=20 > Tel: +358 40 527 46 34 > E-mail: jonne.soininen@nokia.com >=20 >=20 ********************************** 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 Fri Jan 21 03:34:06 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18669 for ; Fri, 21 Jan 2005 03:34:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CruE5-000I7a-75 for v6ops-data@psg.com; Fri, 21 Jan 2005 08:33:05 +0000 Received: from [140.113.23.5] (helo=mail.cis.nctu.edu.tw) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CruDz-000I78-Tf for v6ops@ops.ietf.org; Fri, 21 Jan 2005 08:33:00 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.cis.nctu.edu.tw (8.12.10/8.12.9) with ESMTP id j0L8Wwu9009003 for ; Fri, 21 Jan 2005 16:32:58 +0800 (CST) (envelope-from ace@speed.cis.nctu.edu.tw) Received: from mail.cis.nctu.edu.tw ([127.0.0.1]) by localhost (mail.cis.nctu.edu.tw [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 02310-20 for ; Fri, 21 Jan 2005 16:32:58 +0800 (CST) Received: from TW1190501 (61-219-64-135.HINET-IP.hinet.net [61.219.64.135]) (authenticated bits=0 as gis89514 with LOGIN) by mail.cis.nctu.edu.tw (8.12.10/8.12.9) with ESMTP id j0L8WvMe008981 for ; Fri, 21 Jan 2005 16:32:58 +0800 (CST) (envelope-from ace@speed.cis.nctu.edu.tw) Message-Id: <200501210832.j0L8WvMe008981@mail.cis.nctu.edu.tw> From: "Alan Chang" To: Subject: RE: Take ISP BB scenarios as WG document? Date: Fri, 21 Jan 2005 16:32:57 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: Thread-Index: AcT/jHBua0QRkAwsRSuIrIYHrZRYEAABTl0A X-Virus-Scanned: by amavisd-new at cis.nctu.edu.tw 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, I have read 01 revision and just focus what I'm interested in 02. At page 26, If a Customer Router is present: 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. Does this mean the router can do stateless autoconfiguration? From what I can remember, a node can be only a host (receive RA) or a router (send RA). Thanks. -Alan -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola Sent: Friday, January 21, 2005 3:25 PM To: v6ops@ops.ietf.org Subject: Take ISP BB scenarios as WG document? Hi, (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-scen arios-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 Fri Jan 21 05:39:46 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26381 for ; Fri, 21 Jan 2005 05:39:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Crw9q-000FfG-6B for v6ops-data@psg.com; Fri, 21 Jan 2005 10:36:50 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Crw9n-000Fez-KW for v6ops@ops.ietf.org; Fri, 21 Jan 2005 10:36:48 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id j0LAaiV8038764 for ; Fri, 21 Jan 2005 10:36:45 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0LAbhPG130364 for ; Fri, 21 Jan 2005 11:37:43 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j0LAaijo023543 for ; Fri, 21 Jan 2005 11:36:44 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j0LAahPg023523; Fri, 21 Jan 2005 11:36:43 +0100 Received: from zurich.ibm.com (sig-9-146-217-181.de.ibm.com [9.146.217.181]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA64962; Fri, 21 Jan 2005 11:36:42 +0100 Message-ID: <41F0DB37.3050807@zurich.ibm.com> Date: Fri, 21 Jan 2005 11:36:39 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org Subject: Re: Take ISP BB scenarios as WG document? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think this is useful work Brian Pekka Savola wrote: > Hi, > > (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) > From owner-v6ops@ops.ietf.org Fri Jan 21 05:49: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 FAA27101 for ; Fri, 21 Jan 2005 05:49:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CrwLg-000Hws-9L for v6ops-data@psg.com; Fri, 21 Jan 2005 10:49:04 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CrwLd-000HuI-OR for v6ops@ops.ietf.org; Fri, 21 Jan 2005 10:49: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 j0LAmwc29140; Fri, 21 Jan 2005 12:48:58 +0200 (EET) X-Scanned: Fri, 21 Jan 2005 12:53:59 +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 j0LArxte021636; Fri, 21 Jan 2005 12:53:59 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 003saCko; Fri, 21 Jan 2005 12:51:28 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0LAg2x18424; Fri, 21 Jan 2005 12:42:02 +0200 (EET) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 21 Jan 2005 12:42:00 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 21 Jan 2005 12:41:59 +0200 Received: from 172.21.155.64 ([172.21.155.64]) by esebe100.NOE.Nokia.com ([172.21.138.118]) with Microsoft Exchange Server HTTP-DAV ; Fri, 21 Jan 2005 10:41:58 +0000 Received: from essrv103nok15564.ntc.nokia.com by ESEBE100.noe.nokia.com; 21 Jan 2005 12:41:58 +0200 Subject: Re: Re:Conclusion: RE: Interest to have as an WG item: draft-tschofenig-v6ops-secure -tunnels-03.txt From: "Soininen Jonne (Nokia-NET/Helsinki)" To: jordi.palet@consulintel.es Cc: "owner-v6ops@ops.ietf.org" In-Reply-To: References: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-Id: <1106304117.4619.24.camel@essrv103nok15564.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 21 Jan 2005 12:41:58 +0200 X-OriginalArrivalTime: 21 Jan 2005 10:41:59.0100 (UTC) FILETIME=[D591B7C0:01C4FFA5] 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: quoted-printable Jordi, On Fri, 2005-01-21 at 10:23, ext JORDI PALET MARTINEZ wrote: > Hi Jonne, all, >=20 > This is exactly what I think is unfair and I tried to describe several > times. I'm sorry that you find it unfair. However, I think it is fair to check if there is support and it was not clear that there was. >=20 > In other occasions, other documents with similar level of inputs (or even > lower !) have been accepted as WG items. For example? >=20 > Where is the limit between something being accepted and not ? If we don't > have a clear rule, then we have nothing ;-) I think it is difficult to quantify exactly how many people you need to have something to be accepted. However, when you actually have only one person supporting the document (you) and the other comment (from Alain) was a bit hesitant - it does not seem that there is good support in the WG.=20 Maybe the reason for that is that people have to read it. I hope people would read it and discuss it in the mailing list. Then when there is support we can have it in the WG as an item. >=20 > So are we going then to apply the same rule to those documents that have > already being accepted ? Or in the other way around, are we going to acce= pt > this document now ? I don't think we have added anything to the WG items by having just one person supporting it. I believe that the document has to have some support in the WG (multiple people speaking up and already discussion in the mailing list). It seems that there is now some discussion started on the mailing list, and maybe the support for the document is going to be there soon. However, in this case there was not much support. Cheers, Jonne. >=20 > Regards, > Jordi >=20 >=20 >=20 >=20 > > De: "Soininen Jonne (Nokia-NET/Helsinki)" > > Responder a: "owner-v6ops@ops.ietf.org" > > Fecha: Wed, 19 Jan 2005 18:48:38 +0200 > > Para: > > Asunto: Conclusion: RE: Interest to have as an WG item: > > draft-tschofenig-v6ops-secure -tunnels-03.txt > >=20 > > Hello, > >=20 > > (chair hat on) > > there was not an overly enthusiastic response during the two week > > period. Though, the interest seems to have risen toward the end of the > > period, still very few people responded. > >=20 > > I would conclude that there was not enough consensus to take the > > document as WG item at this point. > >=20 > > I hope, however, the authors of the document could continue the work. > > And I would like to people read the document and comment. > >=20 > > Let's check the situation later if more interest raises. > >=20 > > Cheers, > >=20 > > Jonne. > >=20 > > On Fri, 2005-01-14 at 16:32, ext Tschofenig Hannes wrote: > >> hi alain,=20 > >>=20 > >> thanks for your comment. > >>=20 > >> to show you the difference between a document that describes how to us= e > >> ikev1/ikev2 (and ipsec) to provide security of something you might als= o want > >> to look at the mip6 working group where documents exist that describe = how > >> ikev1/ipsec is used to secure the mipv6 signaling between the mn and t= he ha > >> (and the same for ikev2): > >> http://www.ietf.org/rfc/rfc3776.txt > >> http://www.ietf.org/internet-drafts/draft-ietf-mip6-ikev2-ipsec-00.txt > >>=20 > >> the v6ops-secure-tunnels document is of this type. we are, however, no= t > >> extendig ikev2 (luckily). > >>=20 > >> a tutorial (as a comparison) looks like: > >> http://ftp.iasi.rdsnet.ro/mirrors/nis.nsf.net/internet-drafts/draft-ie= tf-ips > >> ec-ikev2-tutorial-01.txt > >>=20 > >> ciao > >> hannes > >> =20 > >>=20 > >>> -----Original Message----- > >>> From: Alain Durand [mailto:Alain.Durand@Sun.COM] > >>> Sent: Freitag, 14. J=C3=A4nner 2005 14:06 > >>> To: Pekka Savola > >>> Cc: v6ops@ops.ietf.org > >>> Subject: Re: Interest to have as an WG item: > >>> draft-tschofenig-v6ops-secure-tunnels-03.txt > >>>=20 > >>> Well, I'm not a security expert, far from that, so I'm not > >>> sure I can comment on the quality of the security assertions. > >>> However, at fist glance, it seems that this is a tutorial on ikev1 & > >>> ikev2 > >>> in the context of IPv6... > >>> I other words, it is unclear to me why we need this document > >>> in v6Ops and why it is not homed in a security related wg IF > >>> there is a need for such a document. > >>>=20 > >>> On another note, some of the techniques described here may be > >>> useful in the context of v6tc... > >>>=20 > >>> - Alain. > >>>=20 > >>>=20 > > --=20 > > Jonne Soininen > > Nokia > >=20 > > Tel: +358 40 527 46 34 > > E-mail: jonne.soininen@nokia.com > >=20 > >=20 >=20 >=20 >=20 >=20 > ********************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on line at: > http://www.ipv6-es.com >=20 > This electronic message contains information which may be privileged or c= onfidential. The information is intended to be for the use of the individua= l(s) named above. If you are not the intended recipient be aware that any d= isclosure, copying, distribution or use of the contents of this information= , including attached files, is prohibited. >=20 >=20 --=20 Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Fri Jan 21 11:45:04 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25863 for ; Fri, 21 Jan 2005 11:45:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cs1s7-0007Zz-8E for v6ops-data@psg.com; Fri, 21 Jan 2005 16:42:55 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cs1s3-0007YN-Hj for v6ops@ops.ietf.org; Fri, 21 Jan 2005 16:42:51 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0LGgn621783 for ; Fri, 21 Jan 2005 18:42:49 +0200 Date: Fri, 21 Jan 2005 18:42:49 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Internet-Draft Submission Cutoff Dates for the 62nd IETF Meeting in Minneapolis, MN (fwd) 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 FYI. ---------- Forwarded message ---------- Date: Fri, 21 Jan 2005 10:43:21 -0500 From: ietf-secretariat@ietf.org To: IETF-Announce@ietf.org Subject: Internet-Draft Submission Cutoff Dates for the 62nd IETF Meeting in Minneapolis, MN There are two (2) Internet-Draft cutoff dates for the 62nd IETF Meeting in Minneapolis, MN: February 14th: Cutoff Date for Initial (i.e., -00) Internet-Draft Submissions All initial Internet-Drafts (-00) must be submitted by Monday, February 14th at 9:00 AM ET. As always, all initial submissions (-00) with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. WG Chair approval must be received by Monday, February 7th at 9:00 AM ET. February 21st: Cutoff Date for Revised (i.e., -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (-01 and higher) must be submitted by Monday, February 21st at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced, and will have to be resubmitted. Please do not wait until the last minute to submit. The Secretariat will begin accepting Internet-Draft submissions starting Monday, March 7th at 9:00 AM ET, but may not post or announce them until Monday, March 14th. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 62nd IETF Meeting can be found at http://www.ietf.org/meetings/IETF-62.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From owner-v6ops@ops.ietf.org Sat Jan 22 02:06: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 CAA01823 for ; Sat, 22 Jan 2005 02:06:02 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CsFJ9-000GDY-ID for v6ops-data@psg.com; Sat, 22 Jan 2005 07:03:43 +0000 Received: from [202.249.10.124] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CsFJ6-000G8E-Ab for v6ops@ops.ietf.org; Sat, 22 Jan 2005 07:03:40 +0000 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:3d6e:d1b5:a3e7:491f]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 959CC15210; Sat, 22 Jan 2005 16:03:39 +0900 (JST) Date: Sat, 22 Jan 2005 16:04:06 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Alan Chang" Cc: Subject: Re: Take ISP BB scenarios as WG document? In-Reply-To: <200501210832.j0L8WvMe008981@mail.cis.nctu.edu.tw> References: <200501210832.j0L8WvMe008981@mail.cis.nctu.edu.tw> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII 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 >>>>> On Fri, 21 Jan 2005 16:32:57 +0800, >>>>> "Alan Chang" said: > At page 26, > If a Customer Router is present: > 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. > Does this mean the router can do stateless autoconfiguration? >> From what I can remember, a node can be only a host (receive RA) or a router > (send RA). (I've not gone through the document, so I may miss something in the context, but) isn't the autoconfigured address (between the "Customer Router" and the "Edge Router") a link-local address? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp p.s. I happen to find a typo in the original text: in the sentence beginning with "This step is ...", "shorter then /64" should be "shorter than /64". (i.e., s/then/than/) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-v6ops@ops.ietf.org Sun Jan 23 01:28: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 BAA07993 for ; Sun, 23 Jan 2005 01:28:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CsbC1-0005nA-8A for v6ops-data@psg.com; Sun, 23 Jan 2005 06:25:49 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CsbBw-0005mo-7d for v6ops@ops.ietf.org; Sun, 23 Jan 2005 06:25:44 +0000 Received: from [216.244.152.70] ([216.244.152.70]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000724238.msg for ; Sun, 23 Jan 2005 07:26:35 +0100 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 22 Jan 2005 21:36:19 +0100 Subject: Re:Take ISP BB scenarios as WG document? From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MDRemoteIP: 216.244.152.70 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, 23 Jan 2005 07:26:40 +0100 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,TO_ADDRESS_EQ_REAL autolearn=no version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I agree, this work should be a WG item. I'm still trying to find some time to add PLC considerations, hopefully in 1-2 weeks maximum. Regards, Jordi > De: Pekka Savola > Responder a: > Fecha: Fri, 21 Jan 2005 09:25:09 +0200 (EET) > Para: "v6ops@ops.ietf.org" > Asunto: Take ISP BB scenarios as WG document? > > Hi, > > (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-scenar > ios-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 > ********************************** 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 Sun Jan 23 01:28:41 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08013 for ; Sun, 23 Jan 2005 01:28:41 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CsbCT-0005pG-2q for v6ops-data@psg.com; Sun, 23 Jan 2005 06:26:17 +0000 Received: from [217.126.187.160] (helo=consulintel.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CsbCP-0005om-QC for v6ops@ops.ietf.org; Sun, 23 Jan 2005 06:26:14 +0000 Received: from consulintel.es by consulintel.com (Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000164889.msg for ; Sun, 23 Jan 2005 07:25:16 +0100 Received: from [216.244.152.70] ([216.244.152.70]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000724237.msg for ; Sun, 23 Jan 2005 07:26:35 +0100 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 22 Jan 2005 21:35:05 +0100 Subject: Re:Feedback on proposed charter from the IESG From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Sun, 23 Jan 2005 07:26:37 +0100 X-Authenticated-Sender: consulintel.es X-MDRemoteIP: 213.172.48.142 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.com, Sun, 23 Jan 2005 07:25:19 +0100 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,TO_ADDRESS_EQ_REAL autolearn=no version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I radically disagree with: "The main focus of the v6ops WG is to look at the immediate deployment issues; more advanced stages of deployment and transition are a lower priority." We know how long takes the IETF process, so if we put in lower priority "more advanced stages", then we are endangering the deployment. Furthermore, where is the bar for what is advanced for you or for me ? For example, we are now deploying IPv6-only networks. Is that advanced or not ? Also: "1. Solicit input from network operators and users to identify", I'm not a network operator, but do the work for some of them. So this will actually exclude my input. Should be reworded. Then, if we say "ISP Networks (including Core, HFC/Cable, DSL & Dial-up networks),", we should mention all the technologies (for example PLC), otherwise is better to just say "including Core and any kind of access network). Right ? If we say "Enterprise Networks, Unmanaged Networks (Home/Small Office), and Cellular Networks.", somehow we are limiting to those scenarios. Tomorrow we can come up with a new one. Consequently, it will be better to finish this sentence with something like: "..., cellular networks, or other unforeseen scenarios which may become relevant and are not covered by the previous ones". Regards, Jordi > De: Pekka Savola > Responder a: > Fecha: Thu, 20 Jan 2005 12:30:40 +0200 (EET) > Para: "v6ops@ops.ietf.org" > CC: > Asunto: RE: Feedback on proposed charter from the IESG > > Hi, > > Attached is an attempt to rephrase the charter slightly, mainly taking > Brian's suggestion with a slight edit. Htmlwdiff is at: > http://www.netcore.fi/pekkas/ietf/temp/v6ops-dow-20050120-diff.html > > Comments? > > Inline I respond to two of Jim's points I didn't apply at this point. > > On Wed, 12 Jan 2005, Bound, Jim wrote: >>> Do you have suggestions for, e.g.: >>> - what classes of documents are such that we should be working on >>> (with sufficient specifity so it doesn't seem open-ended), >> >> I believe current input is good and basically needs of the operational >> community for deployment. >> >> But I want to note what "operational community" means and maybe we need >> to call that out from v6ops view very clearly: >> >> Operational Community: >> >> 1. Providers (telco, ISPs, IXs, Mobile Greenfield to deploy 3G IMS et al >> they are all different) >> >> 2. Enterprises that require operational work from within the IETF for >> Enterprise operation. >> >> 3. Liaison consortias for deployment that provide v6ops via IETF >> operational requirements. Examples are IPv6 Forum, ICANN, NANOG, >> Registries, ATIS www.atis.org, NCOIC www.ncoic.org, etc. > > Do these need to go in charter? I think everyone agrees on the first > two, but the third is likely trickier, because the IETF has a formal > liaison only with ICANN (a technical liaison group). Obviuously, > anyone from those consortias or forums can come and speak up in the > mailing-list, contact the IETF in a more formal manner, etc. > >>> Description of Working Group: >>> >>> The global deployment of IPv6 is underway, creating an >>> IPv4/IPv6 Internet consisting of IPv4-only, IPv6-only and >>> IPv4/IPv6 networks and nodes. This deployment must be >>> properly handled to avoid the division of the Internet into >>> separate IPv4 and IPv6 networks while ensuring addressing and >>> connectivity for all IPv4 and IPv6 nodes. >> >> I think the above needs re-wording. >> >> Suggested replacement text: >> >> The global deployment of IPv6 is in process. As the deployment evolves >> some basic operational requirements will exist, and new operational >> requirements will be learned. The IPv6 Operations Working Group is an >> IETF working group to work on these operational requirements. >> >> To scope the work for the IPv6 Operations Working Group we define and >> provide examples of work within the scope of operational requirements. > > I'm a bit hesitant about this for a couple of reasons: > 1) people will ask, "_what_ operational requirements?", > 2) the text can be read to mean "v6ops defines operational > requirements document(s)" which is probably undesirable, and > 3) operational requirements from operators etc. are currently a > source of where new initiatives for new work come from, not the only > one. > > Therefore I'm hesitant to writing this about operational requirements. > Obviously, however, if operators etc. present us with _their_ > operational requirements, the WG should take those into serious > consideration.. but I don't see why that would need to be in the > charter. ********************************** 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 Sun Jan 23 01:28:49 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08031 for ; Sun, 23 Jan 2005 01:28:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CsbC6-0005nw-Fo for v6ops-data@psg.com; Sun, 23 Jan 2005 06:25:54 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CsbC3-0005nO-Nn for v6ops@ops.ietf.org; Sun, 23 Jan 2005 06:25:52 +0000 Received: from [216.244.152.70] ([216.244.152.70]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000724239.msg for ; Sun, 23 Jan 2005 07:26:40 +0100 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 22 Jan 2005 21:41:43 +0100 Subject: Re:Conclusion: RE: Interest to have as an WG item: draft-tschofenig-v6ops-secure -tunnels-03.txt From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: In-Reply-To: <1106304117.4619.24.camel@essrv103nok15564.ntc.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-MDRemoteIP: 216.244.152.70 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, 23 Jan 2005 07:26:47 +0100 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_QP_LONG_LINE,TO_ADDRESS_EQ_REAL autolearn=no version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Jonne, I'm not saying is not fair to check, on the other way around, I'm saying that other documents never got the opportunity to check it. There have been also some documents, as I recall, which have been accepted as WG items with small support. For example, more emails from the same people doesn't mean more support. But also for me doesn't make difference to have support from 2 people or from 5. How many we are in this WG ? Should we have support at least from a 10% or may be a 25% ? Definitively not just from a 2-3% ! You don't think so ? Oh yes, the question, who counts for "how many we are in this WG?" ... Is just those that speak up from time to time in the list ? Then we are less than 15-20 people ? Or is everybody subscribed ? Or everybody attending the meetings ? If we don't define clear rules, nothing is fair, I guess :-( Regards, Jordi > De: "Soininen Jonne (Nokia-NET/Helsinki)" > Responder a: > Fecha: Fri, 21 Jan 2005 12:41:58 +0200 > Para: > CC: "owner-v6ops@ops.ietf.org" > Asunto: Re: Re:Conclusion: RE: Interest to have as an WG item: > draft-tschofenig-v6ops-secure -tunnels-03.txt >=20 > Jordi, >=20 > On Fri, 2005-01-21 at 10:23, ext JORDI PALET MARTINEZ wrote: >> Hi Jonne, all, >>=20 >> This is exactly what I think is unfair and I tried to describe several >> times. >=20 > I'm sorry that you find it unfair. However, I think it is fair to check > if there is support and it was not clear that there was. >=20 >>=20 >> In other occasions, other documents with similar level of inputs (or even >> lower !) have been accepted as WG items. > For example? >=20 >>=20 >> Where is the limit between something being accepted and not ? If we don't >> have a clear rule, then we have nothing ;-) >=20 > I think it is difficult to quantify exactly how many people you need to > have something to be accepted. However, when you actually have only one > person supporting the document (you) and the other comment (from Alain) > was a bit hesitant - it does not seem that there is good support in the > WG.=20 > Maybe the reason for that is that people have to read it. I hope people > would read it and discuss it in the mailing list. Then when there is > support we can have it in the WG as an item. >=20 >>=20 >> So are we going then to apply the same rule to those documents that have >> already being accepted ? Or in the other way around, are we going to accept >> this document now ? >=20 > I don't think we have added anything to the WG items by having just one > person supporting it. I believe that the document has to have some > support in the WG (multiple people speaking up and already discussion in > the mailing list). It seems that there is now some discussion started on > the mailing list, and maybe the support for the document is going to be > there soon. However, in this case there was not much support. >=20 > Cheers, >=20 > Jonne. >=20 >>=20 >> Regards, >> Jordi >>=20 >>=20 >>=20 >>=20 >>> De: "Soininen Jonne (Nokia-NET/Helsinki)" >>> Responder a: "owner-v6ops@ops.ietf.org" >>> Fecha: Wed, 19 Jan 2005 18:48:38 +0200 >>> Para: >>> Asunto: Conclusion: RE: Interest to have as an WG item: >>> draft-tschofenig-v6ops-secure -tunnels-03.txt >>>=20 >>> Hello, >>>=20 >>> (chair hat on) >>> there was not an overly enthusiastic response during the two week >>> period. Though, the interest seems to have risen toward the end of the >>> period, still very few people responded. >>>=20 >>> I would conclude that there was not enough consensus to take the >>> document as WG item at this point. >>>=20 >>> I hope, however, the authors of the document could continue the work. >>> And I would like to people read the document and comment. >>>=20 >>> Let's check the situation later if more interest raises. >>>=20 >>> Cheers, >>>=20 >>> Jonne. >>>=20 >>> On Fri, 2005-01-14 at 16:32, ext Tschofenig Hannes wrote: >>>> hi alain,=20 >>>>=20 >>>> thanks for your comment. >>>>=20 >>>> to show you the difference between a document that describes how to use >>>> ikev1/ikev2 (and ipsec) to provide security of something you might also >>>> want >>>> to look at the mip6 working group where documents exist that describe how >>>> ikev1/ipsec is used to secure the mipv6 signaling between the mn and the ha >>>> (and the same for ikev2): >>>> http://www.ietf.org/rfc/rfc3776.txt >>>> http://www.ietf.org/internet-drafts/draft-ietf-mip6-ikev2-ipsec-00.txt >>>>=20 >>>> the v6ops-secure-tunnels document is of this type. we are, however, not >>>> extendig ikev2 (luckily). >>>>=20 >>>> a tutorial (as a comparison) looks like: >>>>=20 http://ftp.iasi.rdsnet.ro/mirrors/nis.nsf.net/internet-drafts/draft-ietf-ip>>>> s >>>> ec-ikev2-tutorial-01.txt >>>>=20 >>>> ciao >>>> hannes >>>> =20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Alain Durand [mailto:Alain.Durand@Sun.COM] >>>>> Sent: Freitag, 14. J=E4nner 2005 14:06 >>>>> To: Pekka Savola >>>>> Cc: v6ops@ops.ietf.org >>>>> Subject: Re: Interest to have as an WG item: >>>>> draft-tschofenig-v6ops-secure-tunnels-03.txt >>>>>=20 >>>>> Well, I'm not a security expert, far from that, so I'm not >>>>> sure I can comment on the quality of the security assertions. >>>>> However, at fist glance, it seems that this is a tutorial on ikev1 & >>>>> ikev2 >>>>> in the context of IPv6... >>>>> I other words, it is unclear to me why we need this document >>>>> in v6Ops and why it is not homed in a security related wg IF >>>>> there is a need for such a document. >>>>>=20 >>>>> On another note, some of the techniques described here may be >>>>> useful in the context of v6tc... >>>>>=20 >>>>> - Alain. >>>>>=20 >>>>>=20 >>> --=20 >>> Jonne Soininen >>> Nokia >>>=20 >>> Tel: +358 40 527 46 34 >>> E-mail: jonne.soininen@nokia.com >>>=20 >>>=20 >>=20 >>=20 >>=20 >>=20 >> ********************************** >> Madrid 2003 Global IPv6 Summit >> Presentations and videos on line at: >> http://www.ipv6-es.com >>=20 >> 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. >>=20 >>=20 > --=20 > Jonne Soininen > Nokia >=20 > Tel: +358 40 527 46 34 > E-mail: jonne.soininen@nokia.com >=20 ********************************** 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 Sun Jan 23 02:40: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 CAA26506 for ; Sun, 23 Jan 2005 02:40:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CscKm-0002WU-Ae for v6ops-data@psg.com; Sun, 23 Jan 2005 07:38:56 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1CscKj-0002W7-P9 for v6ops@ops.ietf.org; Sun, 23 Jan 2005 07:38:53 +0000 Received: (qmail 19389 invoked by uid 417); 23 Jan 2005 07:38:53 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 23 Jan 2005 07:38:53 -0000 Received: from XPNERICK ([193.17.42.1]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Sun, 23 Jan 2005 00:38:50 -0700 Message-ID: <001201c5011e$74f99ed0$6b081eac@ttitelecom.com> From: "EricLKlein" To: v6ops@ops.ietf.org, ipv6@ietf.org Subject: White Paper - The Challenges of Next Generation IP Address Management Date: Sun, 23 Jan 2005 09:37:55 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C5012F.374497A0" 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=-1.3 required=5.0 tests=AWL,BAYES_50,HTML_40_50, HTML_MESSAGE autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C5012F.374497A0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable (cross posted to IPv6 and V6 Ops) In case any of you would like to see how some of this is being = implemented here is a nice (free) white paper from Lucent (it is a = little vendor biased, but still valid). Eric The Challenges of Next Generation IP Address Management=20 The concept of managing two parallel IP spaces and the interaction = between them is somewhat foreign and comes with its own set of = complexities and challenges. This paper will address the challenges of = adopting IPv6, as well as managing, monitoring and streamlining your = next generation networks.=20 http://www.fattail.com/redir/redirect.asp?CID=3D94032 ------=_NextPart_000_000F_01C5012F.374497A0 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

(cross posted to IPv6 and V6 Ops)

In case any of you would like to see how some of this is being = implemented=20 here is a nice (free) white paper from Lucent (it is a little = vendor=20 biased, but still valid).

Eric

The Challenges of Next Generation IP Address = Management

The concept of managing two parallel IP spaces and the interaction = between=20 them is somewhat foreign and comes with its own set of complexities and=20 challenges. This paper will address the challenges of adopting IPv6, as = well as=20 managing, monitoring and streamlining your next generation networks. =

http://www.fattail.com/redir/redirect.asp?CID=3D94032=

------=_NextPart_000_000F_01C5012F.374497A0-- From owner-v6ops@ops.ietf.org Sun Jan 23 03:04: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 DAA27348 for ; Sun, 23 Jan 2005 03:04:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CscjV-000ABd-7y for v6ops-data@psg.com; Sun, 23 Jan 2005 08:04:29 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1CscjU-000AAe-4F for v6ops@ops.ietf.org; Sun, 23 Jan 2005 08:04:28 +0000 Received: (qmail 11541 invoked by uid 417); 23 Jan 2005 08:04:27 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 23 Jan 2005 08:04:27 -0000 Received: from XPNERICK ([193.17.42.1]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Sun, 23 Jan 2005 01:04:26 -0700 Message-ID: <003001c50122$08650080$6b081eac@ttitelecom.com> From: "EricLKlein" To: v6ops@ops.ietf.org References: Subject: Re: Re:Feedback on proposed charter from the IESG Date: Sun, 23 Jan 2005 10:03:31 +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.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 From: "JORDI PALET MARTINEZ" > Then, if we say "ISP Networks (including Core, HFC/Cable, DSL & Dial-up > networks),", we should mention all the technologies (for example PLC), > otherwise is better to just say "including Core and any kind of access > network). Right ? > I would prefer phrasing like "including Core and all types of access networks." From owner-v6ops@ops.ietf.org Sun Jan 23 03:23: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 DAA28292 for ; Sun, 23 Jan 2005 03:23:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Csd1a-000FUB-Hx for v6ops-data@psg.com; Sun, 23 Jan 2005 08:23:10 +0000 Received: from [216.168.239.71] (helo=falcon.verisign.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Csd1Z-000FTv-8J for v6ops@ops.ietf.org; Sun, 23 Jan 2005 08:23:09 +0000 Received: from VSVAPOSTALGW1.vcorp.ad.vrsn.com (vsvapostalgw1.vcorp.ad.vrsn.com [10.170.12.38]) by falcon.verisign.com (8.12.10/8.12.10) with ESMTP id j0N8IMop008309; Sun, 23 Jan 2005 03:18:22 -0500 (EST) Received: by vsvapostalgw1.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sun, 23 Jan 2005 03:23:07 -0500 Message-ID: From: "Hannigan, Martin" To: "'EricLKlein'" , v6ops@ops.ietf.org Subject: RE: Re:Feedback on proposed charter from the IESG Date: Sun, 23 Jan 2005 03:23:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" 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 > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of EricLKlein > Sent: Sunday, January 23, 2005 3:04 AM > To: v6ops@ops.ietf.org > Subject: Re: Re:Feedback on proposed charter from the IESG > > > From: "JORDI PALET MARTINEZ" > > Then, if we say "ISP Networks (including Core, HFC/Cable, > DSL & Dial-up > > networks),", we should mention all the technologies (for > example PLC), > > otherwise is better to just say "including Core and any > kind of access > > network). Right ? > > > > I would prefer phrasing like "including Core and all types of access > networks." If you go beyond "ISP network" people will get confused. "Including x and y, but you didn't mention dispersion radio ISP NCI....etc.". I think you'd be better served with "ISP network". It's an understood and time defined phrase. -M< From owner-v6ops@ops.ietf.org Sun Jan 23 17:47:04 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15802 for ; Sun, 23 Jan 2005 17:47:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CsqTO-0008J6-IQ for v6ops-data@psg.com; Sun, 23 Jan 2005 22:44:46 +0000 Received: from [168.103.150.210] (helo=hestia.native6.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CsqTM-0008Hw-6j for v6ops@ops.ietf.org; Sun, 23 Jan 2005 22:44:44 +0000 Received: from JSN6LT (c-24-16-64-144.client.comcast.net [24.16.64.144]) (authenticated bits=0) by hestia.native6.com (8.12.8/8.12.8) with ESMTP id j0NMiaBp030680; Sun, 23 Jan 2005 14:44:37 -0800 Message-Id: <200501232244.j0NMiaBp030680@hestia.native6.com> From: "John Spence, CCSI, CCNA, CISSP" To: Subject: DHCPv6 and Relay-to-Server Multicasting ... Date: Sun, 23 Jan 2005 14:44:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcUBnR0zhvVjbTC7Qj+/P/d5DUPpNQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I posted this question on the IETF DHC Working Group list, but got no response - thought I might ask here as well. ---------- question --------- Does DHCPv6, using site-local multicast support for the relay-to-server traffic (FF05::1:3), assume that the servers are running MLD, and that there is a multicast RP in the network - as would be common for more traditional multicast applications (like one-to-many video streaming)? I see in the RFC that the relays *may* be configured with the unicast addresses of the servers, but they need not be - and the default is to use the site-local multicast capability. I'm envisioning this scenario. Suppose we have 1000 DHCPv6 clients, and a 100 vLAN network, with DHCPv6 servers in the core and relays around the edges. Suppose we have 100 relays and 3 servers, and we'll assume that the relay support is not built into the routers - the relays are standalone platforms. I do not see any way to get site-local multicast packets from the relays to the servers without an end-to-end traditional MLD/PIM multicast-enabled infrastructure. Is that right, or is there another mechanism at work here, or another document that covers how DHCPv6 and IPv6 multicast are related? ----end----- Thanks for any clues or pointers. John Spence ---------------------------------------------------- John Spence, CCSI, CCNA, CISSP Native6, Inc. IPv6 Training and Consulting jspence@PLEASENOSPAMnative6.com www.native6.com ---------------------------------------------------- From owner-v6ops@ops.ietf.org Sun Jan 23 23:05: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 XAA10798 for ; Sun, 23 Jan 2005 23:05:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CsvRk-000IxP-OU for v6ops-data@psg.com; Mon, 24 Jan 2005 04:03:24 +0000 Received: from [140.113.23.5] (helo=mail.cis.nctu.edu.tw) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CsvRh-000Iwj-Hh for v6ops@ops.ietf.org; Mon, 24 Jan 2005 04:03:21 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.cis.nctu.edu.tw (8.12.10/8.12.9) with ESMTP id j0O42Du9035013; Mon, 24 Jan 2005 12:02:13 +0800 (CST) (envelope-from ace@speed.cis.nctu.edu.tw) Received: from mail.cis.nctu.edu.tw ([127.0.0.1]) by localhost (mail.cis.nctu.edu.tw [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 25586-29; Mon, 24 Jan 2005 12:02:13 +0800 (CST) Received: from TW1190501 (61-219-64-135.HINET-IP.hinet.net [61.219.64.135]) (authenticated bits=0 as gis89514 with LOGIN) by mail.cis.nctu.edu.tw (8.12.10/8.12.9) with ESMTP id j0O429Me034996; Mon, 24 Jan 2005 12:02:12 +0800 (CST) (envelope-from ace@speed.cis.nctu.edu.tw) Message-Id: <200501240402.j0O429Me034996@mail.cis.nctu.edu.tw> From: "Alan Chang" To: =?big5?B?J0pJTk1FSSBUYXR1eWEgLyCvq6n6uUardic=?= Cc: , Subject: RE: Take ISP BB scenarios as WG document? Date: Mon, 24 Jan 2005 12:02:09 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcUAUIpxlY+vUqTCScaZE0jiTw9bcABdvOgA In-Reply-To: X-Virus-Scanned: by amavisd-new at cis.nctu.edu.tw X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, I think the term "stateless autoconfiguration" refers to RFC 2642. My questions are: If yes, does this mean the router can do stateless autoconfiguration? If no, how does a CPE router set its address and default route except = using manual configuration. Thanks. -Alan=20 -----Original Message----- From: JINMEI Tatuya / =AF=AB=A9=FA=B9F=ABv = [mailto:jinmei@isl.rdc.toshiba.co.jp]=20 Sent: Saturday, January 22, 2005 3:04 PM To: Alan Chang Cc: v6ops@ops.ietf.org Subject: Re: Take ISP BB scenarios as WG document? >>>>> On Fri, 21 Jan 2005 16:32:57 +0800, "Alan Chang"=20 >>>>> said: > At page 26, > If a Customer Router is present: > 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. > Does this mean the router can do stateless autoconfiguration? >> From what I can remember, a node can be only a host (receive RA) or a = >> router > (send RA). (I've not gone through the document, so I may miss something in the = context, but) isn't the autoconfigured address (between the "Customer Router" and = the "Edge Router") a link-local address? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp p.s. I happen to find a typo in the original text: in the sentence = beginning with "This step is ...", "shorter then /64" should be "shorter than = /64". (i.e., s/then/than/) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-v6ops@ops.ietf.org Mon Jan 24 08: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 IAA05733 for ; Mon, 24 Jan 2005 08:08:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Ct3uI-0004aX-WE for v6ops-data@psg.com; Mon, 24 Jan 2005 13:05:27 +0000 Received: from [128.244.197.23] (helo=jhuapl.edu) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Ct3uF-0004Zq-Py for v6ops@ops.ietf.org; Mon, 24 Jan 2005 13:05:23 +0000 Received: from ([128.244.124.185]) by pilot.jhuapl.edu with ESMTP id KP-VXL34.12176602; Mon, 24 Jan 2005 08:04:51 -0500 In-Reply-To: <200501232244.j0NMiaBp030680@hestia.native6.com> References: <200501232244.j0NMiaBp030680@hestia.native6.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--584327185; protocol="application/pkcs7-signature" Message-Id: <88B297B4-6E08-11D9-A1EB-000D93330CAA@innovationslab.net> Cc: From: Brian Haberman Subject: Re: DHCPv6 and Relay-to-Server Multicasting ... Date: Mon, 24 Jan 2005 08:04:51 -0500 To: "John Spence, CCSI, CCNA, CISSP" X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --Apple-Mail-2--584327185 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi John, The use of a site-local multicast address will require a multicast infrastructure. That could be something as complex as managing an RP-based multicast routing infrastructure. It could also be done using MLDv2 and SSM routing. And in one scenario, I have seen *static* multicast routes for DHCPv6 servers. So, in short, a multicast infrastructure is needed when using FF-5::1:3. It is up to the deployer to determine the complexity of that infrastructure. Regards, Brian On Jan 23, 2005, at 17:44, John Spence, CCSI, CCNA, CISSP wrote: > > I posted this question on the IETF DHC Working Group list, but got no > response - thought I might ask here as well. > > ---------- question --------- > > Does DHCPv6, using site-local multicast support for the relay-to-server > traffic (FF05::1:3), assume that the servers are running MLD, and that > there > is a multicast RP in the network - as would be common for more > traditional > multicast applications (like one-to-many video streaming)? I see in > the RFC > that the relays *may* be configured with the unicast addresses of the > servers, but they need not be - and the default is to use the > site-local > multicast capability. > > I'm envisioning this scenario. Suppose we have 1000 DHCPv6 clients, > and a > 100 vLAN network, with DHCPv6 servers in the core and relays around the > edges. Suppose we have 100 relays and 3 servers, and we'll assume > that the > relay support is not built into the routers - the relays are standalone > platforms. > > I do not see any way to get site-local multicast packets from the > relays to > the servers without an end-to-end traditional MLD/PIM multicast-enabled > infrastructure. Is that right, or is there another mechanism at work > here, > or another document that covers how DHCPv6 and IPv6 multicast are > related? > > ----end----- > > Thanks for any clues or pointers. > > John Spence > ---------------------------------------------------- > John Spence, CCSI, CCNA, CISSP > Native6, Inc. > IPv6 Training and Consulting > jspence@PLEASENOSPAMnative6.com > www.native6.com > ---------------------------------------------------- > --Apple-Mail-2--584327185 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwMTI0MTMwNDUxWjAjBgkqhkiG9w0B CQQxFgQU1aB1hhBKeAnETwj4TjPbHpkRfX0weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEApmkz7KvyvVMs+NVWldm2H+wgNcUBXXMFGgeP0wBFEEibsKvyRyfvRztj/EXaRhX3mYE5 2Xuw07L8eRdJbeE6/dWXXGXd5Sax8960xpXiuruTP06cycUdtC0B4VkfBCon6y+w65QLF8FOlcEZ EIxwM+Xqs0FkWRihKgK43+h1WdxDZJwnepm4hd9MebRAMFxgbNzUlsrT+4RHqbYKUTCdAD+oAYls hKoRNRK6MwBnaPh0ytAV8Aj2oklpMu/Avih+lOGveuyWqLr2hGGIHPCHuGpMaYZ+2MtMIh/9KwnR JoVUJ7iDZPtw9UJLRcHm/96uKt/NC5qVqjakz0aGfNpuQgAAAAAAAA== --Apple-Mail-2--584327185-- From owner-v6ops@ops.ietf.org Mon Jan 24 10:31:43 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21699 for ; Mon, 24 Jan 2005 10:31:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Ct69r-0008gu-MN for v6ops-data@psg.com; Mon, 24 Jan 2005 15:29:39 +0000 Received: from [193.6.222.240] (helo=mail.ki.iif.hu) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Ct69m-0008gL-3v for v6ops@ops.ietf.org; Mon, 24 Jan 2005 15:29:34 +0000 Received: by mail.ki.iif.hu (Postfix, from userid 1003) id 6A3955576; Mon, 24 Jan 2005 16:29:33 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 679C55568; Mon, 24 Jan 2005 16:29:33 +0100 (CET) Date: Mon, 24 Jan 2005 16:29:33 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: sasad@cisco.com, cpopovic@cisco.com, adahmed@cisco.com Cc: v6ops@ops.ietf.org Subject: Re: Take ISP BB scenarios as WG document? In-Reply-To: Message-ID: <20050121100629.P4545@mignon.ki.iif.hu> 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=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi All, On Fri, 21 Jan 2005, Pekka Savola wrote: > Hi, > > (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. It is a very good architectural review about the IPv6 deployment scenarios for Access networks. I recommend to move forward. However I have question regarding the document or IPv6 access architecture itself. In the 7.2.3.1 section the document states that BRAS Layer 3 aware in the L2TP Access Aggregation (LAA) Model scenario. I don't really understand why BRAS should be Layer 3 aware (or IPv6 enabled). 1. The CPE initiates the connection to BRAS via PPPoA or PPPoE. 2. The PPP starts the negotiation phase, but since the the PPP belongs to a different domain the PPP session forwarded and terminated at the LNS via L2TP. IPCP and IPV6CP done between CPE and LNS. 3. The responsibility of the BRAS only to encapsulate the PPP packets to L2TP packets and forward to LNS. 4. LNS decapsulates the L2TP and PPP protocol and the final protocol (in the case of IPv6 - the IPv6 packet) 5. If BRAS gets a packet encapsulated into an L2TP tunnel it has to remove the L2TP tunnel header and encapsulate into a PPPoE or PPPoA packet the rest of the packet and forward to the CPE. I don't see any L3 awareness of BRAS (or LAC) here. Where I miss a point? Kindest Regards, Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 From owner-v6ops@ops.ietf.org Tue Jan 25 01:44: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 BAA17347 for ; Tue, 25 Jan 2005 01:44:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CtKNW-0008Ft-7c for v6ops-data@psg.com; Tue, 25 Jan 2005 06:40:42 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CtKNU-0008Et-Ly for v6ops@ops.ietf.org; Tue, 25 Jan 2005 06:40:41 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0P6da604056; Tue, 25 Jan 2005 08:39:37 +0200 Date: Tue, 25 Jan 2005 08:39:36 +0200 (EET) From: Pekka Savola To: JORDI PALET MARTINEZ cc: "v6ops@ops.ietf.org" Subject: Re:Feedback on proposed charter from the IESG In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, 22 Jan 2005, JORDI PALET MARTINEZ wrote: > I radically disagree with: > > "The main focus of the v6ops WG is to look at the immediate > deployment issues; more advanced stages of deployment and transition > are a lower priority." > > We know how long takes the IETF process, so if we put in lower priority > "more advanced stages", then we are endangering the deployment. Furthermore, > where is the bar for what is advanced for you or for me ? For example, we > are now deploying IPv6-only networks. Is that advanced or not ? Yes, many people have been deploying IPv6-only networks for some time now. But we have to try to prioritize the work somehow. I think most will agree that it is more important to get dual-stack implications figured out before using a lot of effort to think about what issues IPv6-only would bring. That said, this might be something that might change in the next rechartering, depending on how the work gets done. > Also: "1. Solicit input from network operators and users to identify", I'm > not a network operator, but do the work for some of them. So this will > actually exclude my input. Should be reworded. It doesn't say anything about excluding any input, from anywhere :-). It just says that this WG should go to the network operators and users and ask them to list their issues. If they tell those "voluntarily", that's fine. If someone else tells about an issue, that's also fine. Feel free to suggest a rewording, now or at the charter review stage later on. > Then, if we say "ISP Networks (including Core, HFC/Cable, DSL & Dial-up > networks),", we should mention all the technologies (for example PLC), > otherwise is better to just say "including Core and any kind of access > network). Right ? I removed everything in ()'s. > If we say "Enterprise Networks, Unmanaged Networks (Home/Small Office), and > Cellular Networks.", somehow we are limiting to those scenarios. Tomorrow we > can come up with a new one. Consequently, it will be better to finish this > sentence with something like: "..., cellular networks, or other unforeseen > scenarios which may become relevant and are not covered by the previous > ones". This is unnecessary, because the text already says "common network environments, such as"; the list is not exclusive (emphasis below mine): Publish Informational or BCP RFCs that identify and analyze solutions for deploying IPv6 within common network environments, *such as* ISP Networks, Enterprise Networks, Unmanaged Networks (Home/Small Office), and Cellular Networks. -- 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 Jan 25 07:59:28 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00714 for ; Tue, 25 Jan 2005 07:59:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CtQG7-000LzY-8X for v6ops-data@psg.com; Tue, 25 Jan 2005 12:57:27 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1CtQG4-000LzE-O9 for v6ops@ops.ietf.org; Tue, 25 Jan 2005 12:57:25 +0000 Received: (qmail 8549 invoked by uid 1007); 25 Jan 2005 12:57:22 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=NdoebR6khH0s2GzPIj89DgRBHky7MBxaNut2yd3UOW9aty5tk46zu5ZirWjPgg88 ; Date: Tue, 25 Jan 2005 13:57:22 +0100 From: Gert Doering To: Alan Chang Cc: "'JINMEI Tatuya / ?????F?v'" , v6ops@ops.ietf.org, sasad@cisco.com Subject: Re: Take ISP BB scenarios as WG document? Message-ID: <20050125125722.GI84850@Space.Net> References: <200501240402.j0O429Me034996@mail.cis.nctu.edu.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501240402.j0O429Me034996@mail.cis.nctu.edu.tw> User-Agent: Mutt/1.4.1i X-NCC-RegID: de.space 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 Hi, On Mon, Jan 24, 2005 at 12:02:09PM +0800, Alan Chang wrote: > My questions are: > If yes, does this mean the router can do stateless autoconfiguration? > If no, how does a CPE router set its address and default route except using > manual configuration. Existing router implementations can indeed do stateless autoconfiguration. cisco25(config-if)#ipv6 address ? WORD General prefix name X:X:X:X::X IPv6 link-local address X:X:X:X::X/<0-128> IPv6 prefix autoconfig Obtain address using autoconfiguration but the question remains "how useful is this feature?". Yes, the router can autoconfigure its "external" IPv6 address, but it cannot use stateless autoconfiguration to setup his "internal" network interface(s), and thus provide stateless autoconf to network clients. For that part, one could use DHCP prefix delegation, though, and with the combination of both, you can get a fully autoconfiguring IPv6 (CPE) router. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From owner-v6ops@ops.ietf.org Tue Jan 25 08:03: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 IAA00971 for ; Tue, 25 Jan 2005 08:03:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CtQM2-000NB4-Dm for v6ops-data@psg.com; Tue, 25 Jan 2005 13:03:34 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1CtQLy-000N9k-9T for v6ops@ops.ietf.org; Tue, 25 Jan 2005 13:03:30 +0000 Received: (qmail 9347 invoked by uid 1007); 25 Jan 2005 13:03:29 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=sDF6hw4f/zJd0eGamvL67TJ1+cmJenDTbQOyk51Gs4U8xN8T3xEXcPbNUCpjzdzv ; Date: Tue, 25 Jan 2005 14:03:29 +0100 From: Gert Doering To: Mohacsi Janos Cc: sasad@cisco.com, cpopovic@cisco.com, adahmed@cisco.com, v6ops@ops.ietf.org Subject: Re: Take ISP BB scenarios as WG document? Message-ID: <20050125130329.GJ84850@Space.Net> References: <20050121100629.P4545@mignon.ki.iif.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050121100629.P4545@mignon.ki.iif.hu> User-Agent: Mutt/1.4.1i X-NCC-RegID: de.space 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 Hi, On Mon, Jan 24, 2005 at 04:29:33PM +0100, Mohacsi Janos wrote: > I don't see any L3 awareness of BRAS (or LAC) here. Where I miss a point? Eventually it might be desireable to run L2TP over IPv6. But I'm not sure whether this is what the original authors aim at. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From owner-v6ops@ops.ietf.org Tue Jan 25 09:09: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 JAA05616 for ; Tue, 25 Jan 2005 09:09:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CtRMZ-0007jh-FY for v6ops-data@psg.com; Tue, 25 Jan 2005 14:08:11 +0000 Received: from [193.6.222.240] (helo=mail.ki.iif.hu) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CtRMX-0007jO-Rw for v6ops@ops.ietf.org; Tue, 25 Jan 2005 14:08:10 +0000 Received: by mail.ki.iif.hu (Postfix, from userid 1003) id 1DFD2557E; Tue, 25 Jan 2005 15:08:09 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 1BD2A557D; Tue, 25 Jan 2005 15:08:09 +0100 (CET) Date: Tue, 25 Jan 2005 15:08:09 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Gert Doering Cc: sasad@cisco.com, cpopovic@cisco.com, adahmed@cisco.com, v6ops@ops.ietf.org Subject: Re: Take ISP BB scenarios as WG document? In-Reply-To: <20050125130329.GJ84850@Space.Net> Message-ID: <20050125145107.K17471@mignon.ki.iif.hu> References: <20050121100629.P4545@mignon.ki.iif.hu> <20050125130329.GJ84850@Space.Net> 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=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 25 Jan 2005, Gert Doering wrote: > Hi, > > On Mon, Jan 24, 2005 at 04:29:33PM +0100, Mohacsi Janos wrote: >> I don't see any L3 awareness of BRAS (or LAC) here. Where I miss a point? > > Eventually it might be desireable to run L2TP over IPv6. Hi, I think this is an option if Network Access Providers upgrading their networks to support IPv6. Thanks for the comment. Regards, Janos Mohacsi From owner-v6ops@ops.ietf.org Tue Jan 25 14:28: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 OAA29991 for ; Tue, 25 Jan 2005 14:28:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CtWKv-0006gb-O4 for v6ops-data@psg.com; Tue, 25 Jan 2005 19:26:49 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CtWKu-0006gO-NA for v6ops@ops.ietf.org; Tue, 25 Jan 2005 19:26:48 +0000 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 25 Jan 2005 14:26:48 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from adahmed-w2k07.cisco.com (adahmed-w2k07.cisco.com [64.101.146.186]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0PJQdW1029693; Tue, 25 Jan 2005 14:26:39 -0500 (EST) Message-Id: <4.3.2.7.2.20050125132308.02172438@cactus> X-Sender: adahmed@cactus X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 25 Jan 2005 13:26:38 -0600 To: "Alan Chang" From: Adeel Ahmed Subject: RE: Take ISP BB scenarios as WG document? Cc: In-Reply-To: <200501210832.j0L8WvMe008981@mail.cis.nctu.edu.tw> 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=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Alan, Thanks for reviewing the document. Yes, the customer router should be able to do stateless autoconfiguration as already pointed out by Gert Doering. Kind Regards, Adeel Ahmed. At 04:32 PM 1/21/2005 +0800, Alan Chang wrote: >Hi, > >I have read 01 revision and just focus what I'm interested in 02. > >At page 26, > > If a Customer Router is present: > > 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. > >Does this mean the router can do stateless autoconfiguration? > >From what I can remember, a node can be only a host (receive RA) or a router >(send RA). > >Thanks. > >-Alan > >-----Original Message----- >From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf >Of Pekka Savola >Sent: Friday, January 21, 2005 3:25 PM >To: v6ops@ops.ietf.org >Subject: Take ISP BB scenarios as WG document? > >Hi, > >(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-scen >arios-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 Tue Jan 25 14:31:10 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00194 for ; Tue, 25 Jan 2005 14:31:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CtWOw-0007Gr-S6 for v6ops-data@psg.com; Tue, 25 Jan 2005 19:30:58 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CtWOr-0007G8-Ga for v6ops@ops.ietf.org; Tue, 25 Jan 2005 19:30:54 +0000 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 25 Jan 2005 14:39:29 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from adahmed-w2k07.cisco.com (adahmed-w2k07.cisco.com [64.101.146.186]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0PJUnW1001392; Tue, 25 Jan 2005 14:30:50 -0500 (EST) Message-Id: <4.3.2.7.2.20050125132709.0218fe28@cactus> X-Sender: adahmed@cactus X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 25 Jan 2005 13:30:49 -0600 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Adeel Ahmed Subject: Re: Take ISP BB scenarios as WG document? Cc: "Alan Chang" , In-Reply-To: References: <200501210832.j0L8WvMe008981@mail.cis.nctu.edu.tw> <200501210832.j0L8WvMe008981@mail.cis.nctu.edu.tw> 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=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Jinmei, The autoconfigured address on the link between Customer Router and Edge Router is intended to be a global IPv6 address. We will also correct the typo you pointed out. Thanks for reviewing this document and providing feedback. Kind Regards, Adeel Ahmed. At 04:04 PM 1/22/2005 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > >>>>> On Fri, 21 Jan 2005 16:32:57 +0800, > >>>>> "Alan Chang" said: > > > At page 26, > > > If a Customer Router is present: > > > 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. > > > Does this mean the router can do stateless autoconfiguration? > >> From what I can remember, a node can be only a host (receive RA) or a > router > > (send RA). > >(I've not gone through the document, so I may miss something in the >context, but) isn't the autoconfigured address (between the "Customer >Router" and the "Edge Router") a link-local address? > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > >p.s. I happen to find a typo in the original text: in the sentence >beginning with "This step is ...", "shorter then /64" should be >"shorter than /64". (i.e., s/then/than/) > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp From owner-v6ops@ops.ietf.org Tue Jan 25 16:36:31 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12059 for ; Tue, 25 Jan 2005 16:36:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CtYKf-0001Cj-Dk for v6ops-data@psg.com; Tue, 25 Jan 2005 21:34:41 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CtYKe-0001CU-IG for v6ops@ops.ietf.org; Tue, 25 Jan 2005 21:34:40 +0000 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 25 Jan 2005 16:43:17 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from adahmed-w2k07.cisco.com (adahmed-w2k07.cisco.com [64.101.146.186]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0PLYaW1011963; Tue, 25 Jan 2005 16:34:37 -0500 (EST) Message-Id: <4.3.2.7.2.20050125152852.021ec730@cactus> X-Sender: adahmed@cactus X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 25 Jan 2005 15:34:36 -0600 To: Mohacsi Janos From: Adeel Ahmed Subject: Re: Take ISP BB scenarios as WG document? Cc: Gert Doering , sasad@cisco.com, cpopovic@cisco.com, adahmed@cisco.com, v6ops@ops.ietf.org In-Reply-To: <20050125145107.K17471@mignon.ki.iif.hu> References: <20050125130329.GJ84850@Space.Net> <20050121100629.P4545@mignon.ki.iif.hu> <20050125130329.GJ84850@Space.Net> 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=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello Janos, Gert, Section 7.2.3.1 does state that the L2TPv2 tunnel between the LAC and LNS could run over IPv6 or IPv4. Obviously we would like to encourage providers to upgrade their networks to support IPv6, this will also enable them to run IPv6 IGP between the BRAS and the Edge Router. Thanks for reviewing this document and providing feedback. Kind Regards, Adeel. At 03:08 PM 1/25/2005 +0100, Mohacsi Janos wrote: >On Tue, 25 Jan 2005, Gert Doering wrote: > >>Hi, >> >>On Mon, Jan 24, 2005 at 04:29:33PM +0100, Mohacsi Janos wrote: >>>I don't see any L3 awareness of BRAS (or LAC) here. Where I miss a point? >> >>Eventually it might be desireable to run L2TP over IPv6. >Hi, > I think this is an option if Network Access Providers upgrading > their networks to support IPv6. Thanks for the comment. > >Regards, > > Janos Mohacsi From owner-v6ops@ops.ietf.org Tue Jan 25 21:17: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 VAA09320 for ; Tue, 25 Jan 2005 21:17:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CtciD-000JGJ-8H for v6ops-data@psg.com; Wed, 26 Jan 2005 02:15:17 +0000 Received: from [140.113.23.5] (helo=mail.cis.nctu.edu.tw) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CtciA-000JG0-2U for v6ops@ops.ietf.org; Wed, 26 Jan 2005 02:15:14 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.cis.nctu.edu.tw (8.12.10/8.12.9) with ESMTP id j0Q2F5u9091209; Wed, 26 Jan 2005 10:15:05 +0800 (CST) (envelope-from ace@speed.cis.nctu.edu.tw) Received: from mail.cis.nctu.edu.tw ([127.0.0.1]) by localhost (mail.cis.nctu.edu.tw [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 87091-17; Wed, 26 Jan 2005 10:15:05 +0800 (CST) Received: from TW1190501 (61-219-64-135.HINET-IP.hinet.net [61.219.64.135]) (authenticated bits=0 as gis89514 with LOGIN) by mail.cis.nctu.edu.tw (8.12.10/8.12.9) with ESMTP id j0Q2ExMe091128; Wed, 26 Jan 2005 10:14:59 +0800 (CST) (envelope-from ace@speed.cis.nctu.edu.tw) Message-Id: <200501260214.j0Q2ExMe091128@mail.cis.nctu.edu.tw> From: "Alan Chang" To: "'Gert Doering'" Cc: "'JINMEI Tatuya / ?????F?v'" , , , Subject: RE: Take ISP BB scenarios as WG document? Date: Wed, 26 Jan 2005 10:14:59 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcUC3W42cqqeKqHWReCVVwJD1Xcf9AAbyWig In-Reply-To: <20050125125722.GI84850@Space.Net> X-Virus-Scanned: by amavisd-new at cis.nctu.edu.tw 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 Gert & Adeel, Thanks for your detail explanation. I know the mechanism of stateless autoconfiguration and DHCP-PD. I just wonder if this (a node can send/receive RA simultaneously) obeys any RFC. Thanks. -Alan -----Original Message----- From: Gert Doering [mailto:gert@Space.Net] Sent: Tuesday, January 25, 2005 8:57 PM To: Alan Chang Cc: 'JINMEI Tatuya / ?????F?v'; v6ops@ops.ietf.org; sasad@cisco.com Subject: Re: Take ISP BB scenarios as WG document? Hi, On Mon, Jan 24, 2005 at 12:02:09PM +0800, Alan Chang wrote: > My questions are: > If yes, does this mean the router can do stateless autoconfiguration? > If no, how does a CPE router set its address and default route except > using manual configuration. Existing router implementations can indeed do stateless autoconfiguration. cisco25(config-if)#ipv6 address ? WORD General prefix name X:X:X:X::X IPv6 link-local address X:X:X:X::X/<0-128> IPv6 prefix autoconfig Obtain address using autoconfiguration but the question remains "how useful is this feature?". Yes, the router can autoconfigure its "external" IPv6 address, but it cannot use stateless autoconfiguration to setup his "internal" network interface(s), and thus provide stateless autoconf to network clients. For that part, one could use DHCP prefix delegation, though, and with the combination of both, you can get a fully autoconfiguring IPv6 (CPE) router. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From owner-v6ops@ops.ietf.org Tue Jan 25 21:21:06 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09626 for ; Tue, 25 Jan 2005 21:21:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CtcnY-000K9P-Hd for v6ops-data@psg.com; Wed, 26 Jan 2005 02:20:48 +0000 Received: from [140.113.23.5] (helo=mail.cis.nctu.edu.tw) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CtcnX-000K99-1P for v6ops@ops.ietf.org; Wed, 26 Jan 2005 02:20:47 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.cis.nctu.edu.tw (8.12.10/8.12.9) with ESMTP id j0Q2Kdu9094708; Wed, 26 Jan 2005 10:20:39 +0800 (CST) (envelope-from ace@speed.cis.nctu.edu.tw) Received: from mail.cis.nctu.edu.tw ([127.0.0.1]) by localhost (mail.cis.nctu.edu.tw [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 91312-14; Wed, 26 Jan 2005 10:20:39 +0800 (CST) Received: from TW1190501 (61-219-64-135.HINET-IP.hinet.net [61.219.64.135]) (authenticated bits=0 as gis89514 with LOGIN) by mail.cis.nctu.edu.tw (8.12.10/8.12.9) with ESMTP id j0Q2KcMe094676; Wed, 26 Jan 2005 10:20:39 +0800 (CST) (envelope-from ace@speed.cis.nctu.edu.tw) Message-Id: <200501260220.j0Q2KcMe094676@mail.cis.nctu.edu.tw> From: "Alan Chang" To: "'Pekka Savola'" , Subject: RE: Take ISP BB scenarios as WG document? Date: Wed, 26 Jan 2005 10:20:38 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcT/jHBua0QRkAwsRSuIrIYHrZRYEADwQ70Q In-Reply-To: X-Virus-Scanned: by amavisd-new at cis.nctu.edu.tw X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I think the work is solid and valuable for deployment of IPv6 broadband access networks. -Alan -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola Sent: Friday, January 21, 2005 3:25 PM To: v6ops@ops.ietf.org Subject: Take ISP BB scenarios as WG document? Hi, (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-scen arios-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 Wed Jan 26 04: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 EAA05047 for ; Wed, 26 Jan 2005 04:38:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Ctjac-000Ak8-QP for v6ops-data@psg.com; Wed, 26 Jan 2005 09:35:54 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Ctjab-000Aju-Bw for v6ops@ops.ietf.org; Wed, 26 Jan 2005 09:35:53 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j0Q9ZpvU164694 for ; Wed, 26 Jan 2005 09:35:51 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0Q9Zp3C131604 for ; Wed, 26 Jan 2005 10:35:51 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j0Q9ZpSn011513 for ; Wed, 26 Jan 2005 10:35:51 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j0Q9Zo2D011507 for ; Wed, 26 Jan 2005 10:35:50 +0100 Received: from zurich.ibm.com (sig-9-146-217-210.de.ibm.com [9.146.217.210]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA63574 for ; Wed, 26 Jan 2005 10:35:49 +0100 Message-ID: <41F76476.9020304@zurich.ibm.com> Date: Wed, 26 Jan 2005 10:35:50 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: IPv6 Operations Subject: [Fwd: I-D ACTION:draft-vandevelde-v6ops-nap-01.txt] Content-Type: multipart/mixed; boundary="------------000307070807070808010502" 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 This is a multi-part message in MIME format. --------------000307070807070808010502 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit -------- 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. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM --------------000307070807070808010502 Content-Type: Message/External-body; name="draft-vandevelde-v6ops-nap-01.txt" Content-Disposition: inline; filename="draft-vandevelde-v6ops-nap-01.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-1-25163231.I-D@ietf.org> --------------000307070807070808010502 Content-Type: text/plain; name="file:///C|/DOCUME%7E1/BRC/LOCALS%7E1/TEMP/nsmail.txt" Content-Disposition: inline; filename="file:///C|/DOCUME%7E1/BRC/LOCALS%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------000307070807070808010502-- From owner-v6ops@ops.ietf.org Wed Jan 26 07:14: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 HAA16267 for ; Wed, 26 Jan 2005 07:14:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Ctm1Y-000DbN-0z for v6ops-data@psg.com; Wed, 26 Jan 2005 12:11:52 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Ctm1S-000DYV-Sc for v6ops@ops.ietf.org; Wed, 26 Jan 2005 12:11:48 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0QCBfN09857 for ; Wed, 26 Jan 2005 14:11:41 +0200 Date: Wed, 26 Jan 2005 14:11:41 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Please review section 3 of Enterprise analysis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Content-ID: 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 Hi, (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. From owner-v6ops@ops.ietf.org Wed Jan 26 07:25:35 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17248 for ; Wed, 26 Jan 2005 07:25:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CtmEV-000FbM-Ju for v6ops-data@psg.com; Wed, 26 Jan 2005 12:25:15 +0000 Received: from [193.6.222.240] (helo=mail.ki.iif.hu) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CtmEU-000Fb2-9H for v6ops@ops.ietf.org; Wed, 26 Jan 2005 12:25:14 +0000 Received: by mail.ki.iif.hu (Postfix, from userid 1003) id 8F4235550; Wed, 26 Jan 2005 13:25:13 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 8D3F7553A; Wed, 26 Jan 2005 13:25:13 +0100 (CET) Date: Wed, 26 Jan 2005 13:25:13 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Pekka Savola Cc: v6ops@ops.ietf.org Subject: Re: Take ISP BB scenarios as WG document? In-Reply-To: Message-ID: <20050126130320.G41254@mignon.ki.iif.hu> 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=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Dear All, I strongly recommend to adopt this document as a WG document. It has lots of important architectural insights. Regards, Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 On Fri, 21 Jan 2005, Pekka Savola wrote: > Hi, > > (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 Wed Jan 26 07:56:35 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20055 for ; Wed, 26 Jan 2005 07:56:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Ctmi0-000LAl-RU for v6ops-data@psg.com; Wed, 26 Jan 2005 12:55:44 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Ctmhz-000LAU-Pg for v6ops@ops.ietf.org; Wed, 26 Jan 2005 12:55:44 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0QCswN11090; Wed, 26 Jan 2005 14:54:58 +0200 Date: Wed, 26 Jan 2005 14:54:58 +0200 (EET) From: Pekka Savola To: Adeel Ahmed cc: Mohacsi Janos , Gert Doering , sasad@cisco.com, cpopovic@cisco.com, v6ops@ops.ietf.org Subject: Re: Take ISP BB scenarios as WG document? In-Reply-To: <4.3.2.7.2.20050125152852.021ec730@cactus> Message-ID: References: <20050125130329.GJ84850@Space.Net> <20050121100629.P4545@mignon.ki.iif.hu> <20050125130329.GJ84850@Space.Net> <4.3.2.7.2.20050125152852.021ec730@cactus> 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 Hi, On Tue, 25 Jan 2005, Adeel Ahmed wrote: > Section 7.2.3.1 does state that the L2TPv2 tunnel between the LAC and LNS > could run over IPv6 or IPv4. > > Obviously we would like to encourage providers to upgrade their networks to > support IPv6, this will also enable them to run IPv6 IGP between the BRAS and > the Edge Router. Maybe the document needs to spell out a bit more for which reasons IPv6 support is needed in those pieces of equipment. (In this case, the optional L2TP over IPv6?) That way, the reader can better judge whether IPv6 is really, really needed in their particular case right now, or longer down the road. -- 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 Jan 27 04:04:08 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04518 for ; Thu, 27 Jan 2005 04:04:07 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cu5X3-0001LE-FS for v6ops-data@psg.com; Thu, 27 Jan 2005 09:01:41 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cu5X1-0001Kp-Vx for v6ops@ops.ietf.org; Thu, 27 Jan 2005 09:01:40 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0R91cn08885 for ; Thu, 27 Jan 2005 11:01:38 +0200 Date: Thu, 27 Jan 2005 11:01:38 +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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk 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. > (hat off) I took a look mainly at the revised section 3. Below are my *personal* comments, to get the commenting started. I've mainly three kind of concerns/suggestions for improvement: 1) terminology clarifications, so that we're talking about the same thing 2) the model how the enterprise should go about deciding which cases to support, implying how we should present the cases 3) input on the matrix and classification of different cases ..... First, I'd like to note a few terminology/scope issues. - What is the more precise definition of 'host X network'? Does that mean the IP capabilities supported by routers on the link(s) where the host plugs into, IP capabilities of the particular (geopgraphical) site ("whole network") or what? This has *major* impact on how to read the table, and how to think about the scenarios in general. I've assumed the latter. - The first paragraphs restricts this disucussion only to dealing with communications between different parts of the same enterprise, e.g., different branch offices at different countries etc. I think this restriction may be useful (though it's difficult to say), but this is the first time I've seen it. However, it is worth observing that I'd suspect a major goal for an enterprise would be to also publish some services to the outside, or use outside services. According to this scope, these would be out of scope? ..... The document states that it focuses on L3 issues. That's OK as such, as long as it's clear where those L3 decisions come from. That is, AFAICS, typically the v6 deployers should ask two main questions: 1) "which kinds of applications [v4-only, ds, v6-only] do we want to provide [to whom -- v4-only, ds, v6-only?] or use ourselves?" 2) "are there any constraints on which network topologies should or should not be supported?" Based on that, you could take 1) as a basis, strike out or underline those cases reflected by 2), and then go through and consider the rest of the cases and every time ask the question, "is this something we want to support; are there workarounds to avoid this scenario?" The classification I presented below is an attempt to make that decision easier from the _application_ perspective.. ..... I still have issues figuring out how to understand the matrix. For example, 5 first cases are "IPv6/DualIP" app/host scenarios, with IPv4 or dual IP in the middle. But my arithmetrics says there must be 2^3 = 8 different cases -- what's missing? dual-dual-dual (network-provider-network), which is trivial; v4-v4-v4 which is non-trivial; dual-v4-v4 (v4-v4-dual is there though) which is also non-trivial. This makes me think that there must be some clearer methodology for dealing with these cases. What I could think of was breaking up the section to different, higher-level cases, in free-flowing text, which could then refer back to a part of a matrix if needed. I also observe that there should be two cases which are likely relatively similar, whether you look at this from the "server" or "client" perspective (as above: dual-v4-v4 and v4-v4-dual may not be 100% the same, but it might make sense to try to group these together and see where that goes) What I came up with were (with some thoughts on potential solutions in [[]]'s: 1) "IPv4-only legacy application communicating with newer IPv6-only app" (this is currently excluded from analysis, on purpose..) a) the v4-only app's host or network is dual-IP [[ * translation at the host or "close" network? ]] b) the v4-only app's network is v4-only [[ * avoid this case if possible! * the only choice would be translation at SP or "remote" network]] 2) "IPv4-only application is used through a non-IPv4 network" a) host providing the application is dual-IP - host's network is v6-only - peer's network is v6-only [[ * in both cases, tunnel to SP, peer nw, or peer host? ]] b) host providing the application is v4-only - host's network is v6-only [[ * avoid this case if possible! * otherwise, would have to do double translation at SP or peer network..]] - host's network is dual-IP [[ * straightforward tunneling, similar to 2.a) ]] 3) "Dual-stack applications on dual-stack hosts" a) It just works (TM) when networks are any kind of mix of dual-IP and v4-only. However are two pathological cases.. b) "local network v6-only, SP v4-only, peer network v6-only" [[ * straightforward tunneling. ]] c) "local network v6-only, SP v4-only or dual-IP, peer network v4-only" [[ * similar to 2.a) ]] 4) "IPv6-only application on Dual-IP hosts through v4/dual-IP networks" a) networks support dual-IP, but the SP is v4-only [[ * straightforward tunneling between the networks ]] b) networks are v4-only, the SP is v4-only or dual-IP [[ * tunneling between the hosts, or via the SP in the middle ]] c) one network dual-IP, the other v4-only; the SP is either v4 or dual-IP [[ * another case of host-to-network tunneling, like 2.a) ]] d) both networks and the SP are dual-IP [[ * trivial native v6 case ]] 5) "IPv6-only application on Dual-IP hosts through v6-only networks" a) "just works" if both networks are v6-only, SP is dual-IP Otherwise.. b) the same as 3.b) c) the same as 3.c) This is a slightly different way of presenting a (longer, more exhaustive) matrix -- I'm sure there are probably better ways, but at least to me, this is MUCH easier than looking at the matrix and trying to figure out the differences between different options and what they mean in practice.. This doesn't mean the matrix couldn't be there, but that maybe it could be something different cases from a classification like above could refer to somehow. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Jan 28 02:44:49 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01156 for ; Fri, 28 Jan 2005 02:44:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CuQlf-000KEW-Hw for v6ops-data@psg.com; Fri, 28 Jan 2005 07:42:11 +0000 Received: from [24.30.218.95] (helo=rrmailer.rr.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CuGFi-000LXk-H5 for v6ops@ops.ietf.org; Thu, 27 Jan 2005 20:28:30 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: draft-asadullah-v6ops-bb-deployment-scenarios-02.txt Date: Thu, 27 Jan 2005 15:29:16 -0500 Message-ID: <5D200A6BB92BB54F8E2FED8E4A28D76303A2B051@RRMAILER.rr.com> Thread-Topic: draft-asadullah-v6ops-bb-deployment-scenarios-02.txt Thread-Index: AcUDKD03Wr6XKm6ySdKQdwS3Cyt3DwBhLlKw From: "da Silva, Ron" To: "Adeel Ahmed" , , "ciprian Popoviciu" Cc: , "Williams, Chris" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Perhaps a scenario not captured in this draft (unless I missed it) that would be good to capture in the cable BB section is IPv6 enabled on the CM, CMTS, ER for management purposes. Portions of the cable infrastructure have traditionally used RFC1918 IPv4 addresses; however, there are a finite number of those. Thus, IPv6 could have utility in the cable space implemented on the control plane initially rather than focused on the data plane for end user services. Nice draft! -ron From owner-v6ops@ops.ietf.org Fri Jan 28 04:21: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 EAA10517 for ; Fri, 28 Jan 2005 04:21:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CuSHT-0007St-Lf for v6ops-data@psg.com; Fri, 28 Jan 2005 09:19:07 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CuSHP-0007S1-KS for v6ops@ops.ietf.org; Fri, 28 Jan 2005 09:19:03 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j0S9J3Vu002749 for ; Fri, 28 Jan 2005 02:19:03 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IB0008L3SJO2F@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Fri, 28 Jan 2005 02:19:03 -0700 (MST) Received: from [192.168.1.2] ([83.193.4.37]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IB0000WZSJL8A@mail.sun.net> for v6ops@ops.ietf.org; Fri, 28 Jan 2005 02:19:00 -0700 (MST) Date: Fri, 28 Jan 2005 01:18:57 -0800 From: Alain Durand Subject: Re: draft-asadullah-v6ops-bb-deployment-scenarios-02.txt In-reply-to: <5D200A6BB92BB54F8E2FED8E4A28D76303A2B051@RRMAILER.rr.com> To: "da Silva, Ron" Cc: "Williams, Chris" , v6ops@ops.ietf.org, ciprian Popoviciu , Adeel Ahmed , sasad@cisco.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <5D200A6BB92BB54F8E2FED8E4A28D76303A2B051@RRMAILER.rr.com> 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 Jan 27, 2005, at 12:29 PM, da Silva, Ron wrote: > Perhaps a scenario not captured in this draft (unless I missed it) that > would be good to capture in the cable BB section is IPv6 enabled on the > CM, CMTS, ER for management purposes. Portions of the cable > infrastructure have traditionally used RFC1918 IPv4 addresses; however, > there are a finite number of those. Thus, IPv6 could have utility in > the cable space implemented on the control plane initially rather than > focused on the data plane for end user services. Nice draft! This idea was circulated a few years back when a big cable ISP of the time was running out of v4 addresses in net 10 for its internal control plane... Not sure what happened to it. - Alain. From owner-v6ops@ops.ietf.org Fri Jan 28 10:27:16 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08645 for ; Fri, 28 Jan 2005 10:27:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CuXz6-0005wT-FM for v6ops-data@psg.com; Fri, 28 Jan 2005 15:24:32 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CuXz5-0005wG-G0 for v6ops@ops.ietf.org; Fri, 28 Jan 2005 15:24:31 +0000 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 28 Jan 2005 07:25:30 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from adahmed-w2k07.cisco.com (rcdn-vpn-cluster-1-36.cisco.com [10.89.16.36]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j0SFOR1N023682; Fri, 28 Jan 2005 07:24:28 -0800 (PST) Message-Id: <4.3.2.7.2.20050128092306.0219aca0@cactus> X-Sender: adahmed@cactus X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 28 Jan 2005 09:24:28 -0600 To: "da Silva, Ron" From: Adeel Ahmed Subject: Re: draft-asadullah-v6ops-bb-deployment-scenarios-02.txt Cc: "Adeel Ahmed" , , "ciprian Popoviciu" , , "Williams, Chris" In-Reply-To: <5D200A6BB92BB54F8E2FED8E4A28D76303A2B051@RRMAILER.rr.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.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Ron, Thanks for reviewing the draft and providing feedback. We will incorporate your suggestions in the next version of this draft. Kind Regards, Adeel Ahmed. At 03:29 PM 1/27/2005 -0500, da Silva, Ron wrote: >Perhaps a scenario not captured in this draft (unless I missed it) that >would be good to capture in the cable BB section is IPv6 enabled on the >CM, CMTS, ER for management purposes. Portions of the cable >infrastructure have traditionally used RFC1918 IPv4 addresses; however, >there are a finite number of those. Thus, IPv6 could have utility in >the cable space implemented on the control plane initially rather than >focused on the data plane for end user services. Nice draft! > >-ron From owner-v6ops@ops.ietf.org Sat Jan 29 02:08:46 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08508 for ; Sat, 29 Jan 2005 02:08:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CumfE-000EZ8-QO for v6ops-data@psg.com; Sat, 29 Jan 2005 07:05:00 +0000 Received: from [24.30.218.95] (helo=rrmailer.rr.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CuY4n-0006o9-S9 for v6ops@ops.ietf.org; Fri, 28 Jan 2005 15:30:25 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-asadullah-v6ops-bb-deployment-scenarios-02.txt Date: Fri, 28 Jan 2005 10:31:11 -0500 Message-ID: <5D200A6BB92BB54F8E2FED8E4A28D76303AD2B22@RRMAILER.rr.com> Thread-Topic: draft-asadullah-v6ops-bb-deployment-scenarios-02.txt Thread-Index: AcUFGogoFEhicHhnQW+Ifs1fN9wk2AAM6gTA From: "da Silva, Ron" To: Cc: "Williams, Chris" , , "ciprian Popoviciu" , "Adeel Ahmed" , X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > This idea was circulated a few years back when a big cable ISP > of the time was running out of v4 addresses in net 10 for its > internal control plane... Not sure what happened to it. Perhaps they simply moved to v4 registered space since dual-stack v6 support wasn't ubiquitously available yet across their platform? -ron From owner-v6ops@ops.ietf.org Sun Jan 30 21:57:06 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24961 for ; Sun, 30 Jan 2005 21:57:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CvRgq-0001d5-NV for v6ops-data@psg.com; Mon, 31 Jan 2005 02:53:24 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CvRgn-0001cb-NC for v6ops@ops.ietf.org; Mon, 31 Jan 2005 02:53:21 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 3AEB8AF4A for ; Sun, 30 Jan 2005 21:53:21 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Sun, 30 Jan 2005 21:53:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: FW: Take ISP BB scenarios as WG document? Date: Sun, 30 Jan 2005 21:53:25 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B084F991F@tayexc13.americas.cpqcorp.net> Thread-Topic: Take ISP BB scenarios as WG document? Thread-Index: AcUE0L5yen51bdkfRsK6aPOu+SJufACbx94A From: "Bound, Jim" To: X-OriginalArrivalTime: 31 Jan 2005 02:53:21.0118 (UTC) FILETIME=[0613A7E0:01C50740] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I support this as a WG item. It is well prepared to address broadband and important for this WG to review and work on. Regards, /jim =09 Hi, =09 (co-chair hat on) =09 The authors have asked if the following document would be adopted as WG item: =09 "ISP IPv6 Deployment Scenarios in Broadband Access Networks" =09 http://www.ietf.org/internet-drafts/draft-asadullah-v6ops-bb-deployment- scenarios-02.txt =09 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. =09 The deadline for comments is in 2 weeks, on February 4th. =09 (hat off) =09 --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Jan 31 05:07: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 FAA08211 for ; Mon, 31 Jan 2005 05:07:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CvYPm-00009z-GS for v6ops-data@psg.com; Mon, 31 Jan 2005 10:04:14 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CvYPh-00009O-M3 for v6ops@ops.ietf.org; Mon, 31 Jan 2005 10:04:11 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j0VA47V06269 for ; Mon, 31 Jan 2005 12:04:07 +0200 Date: Mon, 31 Jan 2005 12:04:07 +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=-1.4 required=5.0 tests=AWL,BAYES_05 autolearn=ham version=3.0.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk 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 Mon Jan 31 14:22:16 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09605 for ; Mon, 31 Jan 2005 14:22:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cvh5O-0002vz-CV for v6ops-data@psg.com; Mon, 31 Jan 2005 19:19:46 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cvh5L-0002vj-Jq for v6ops@ops.ietf.org; Mon, 31 Jan 2005 19:19:43 +0000 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 31 Jan 2005 11:19:49 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from sasad-w2k01.cisco.com (sjc-vpn4-327.cisco.com [10.21.81.71]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j0VJJZ1N003505; Mon, 31 Jan 2005 11:19:36 -0800 (PST) Message-Id: <4.3.2.7.2.20050131111558.02ce49e8@ce-nfs-1.cisco.com> X-Sender: sasad@ce-nfs-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 31 Jan 2005 11:19:33 -0800 To: Pekka Savola From: Salman Asadullah Subject: Re: Take ISP BB scenarios as WG document? Cc: v6ops@ops.ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_5832005==_.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 --=====================_5832005==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed 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. Thanks for your recommendation and detailed feedback again ! We will review all the feedback (yours and others) we have received and integrate in our next revision. We will get back to you for any clarifications off the list. Regards, Salman >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 --=====================_5832005==_.ALT Content-Type: text/html; charset="us-ascii" 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.

Thanks for your recommendation and detailed feedback again !

We will review all the feedback (yours and others) we have received and integrate in our next revision.

We will get back to you for any clarifications off the list.

Regards,
Salman


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
--=====================_5832005==_.ALT--