From owner-v6ops@ops.ietf.org Mon Dec 1 07:53:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08633 for ; Mon, 1 Dec 2003 07:53:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AQnTY-000GDV-N7 for v6ops-data@psg.com; Mon, 01 Dec 2003 12:48:28 +0000 Received: from [144.254.74.5] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AQnTM-000GCs-6o for v6ops@ops.ietf.org; Mon, 01 Dec 2003 12:48:16 +0000 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 01 Dec 2003 13:45:29 +0100 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB1Cm0g4003615; Mon, 1 Dec 2003 13:48:01 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 1 Dec 2003 12:48:13 +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: ND model for routers Date: Mon, 1 Dec 2003 12:48:11 -0000 Message-ID: Thread-Topic: ND model for routers Thread-Index: AcOz4Gl2zcO39qAMRhOW3oceJGmToQEJwOMg From: "Pascal Thubert (pthubert)" To: "Mark Smith" Cc: , , , X-OriginalArrivalTime: 01 Dec 2003 12:48:13.0497 (UTC) FILETIME=[62013A90:01C3B809] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Exactly :) Seems to me that the "ROUTERS" vs. "routers" discussion had the wrong focus, as Pekka mentioned. The question may not be about the definition of a router, but rather how does a box with forwarding/redistributing capabilities present that to the network at ND level.=20 ND seems to say routers send RAs and the rest of the hosts send NAs. And the real world shows us nodes that do not wish to comply with the ND model. Proposal is to extend ND, not to change the world. Pascal > -----Original Message----- > From: Mark Smith [mailto:ipv6@c753173126e0bc8b057a22829880cf26.nosense.org] > Sent: mercredi 26 novembre 2003 06:45 > To: Pascal Thubert (pthubert) > Cc: he@uninett.no; ftemplin@iprg.nokia.com; ipv6@ietf.org; v6ops@ops.ietf.org > Subject: Re: "ROUTERS" vs. "routers" >=20 > On Tue, 25 Nov 2003 15:22:43 -0000 > "Pascal Thubert (pthubert)" wrote: >=20 > > - A PC with multiple Network addressable entities such as storage media >=20 > I had the maybe not so strange idea a while back of having all components within a PC have an > IPv6 address, or at least represented within the OS by an IPv6 eg keyboard, mouse, HDD etc. > I'm not necessarily suggesting that inter-device communication occurs over TCP or UDP though. > Just IPv6 addresses for management, and possibly other uses that I haven't thought of. >=20 > You could then do tricks such as if the user complains that their HDD has stopped working, > you could ping it over the network. Or have SNMP agents issue traps when eg. the keyboard > stops working. >=20 > I don't know whether this model would make the PC a router, or just that the PC's interface > to the network acts as a proxy for all the device's "internal" IPv6 addresses, performing > things such as DAD on their behalf. >=20 >=20 > Regards, > Mark. From owner-v6ops@ops.ietf.org Mon Dec 1 15:34:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27891 for ; Mon, 1 Dec 2003 15:34:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AQui7-000CVV-9m for v6ops-data@psg.com; Mon, 01 Dec 2003 20:31:59 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AQugT-000CPB-NW for v6ops@ops.ietf.org; Mon, 01 Dec 2003 20:30:17 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27300; Mon, 1 Dec 2003 15:30:03 -0500 (EST) Message-Id: <200312012030.PAA27300@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-ops-04.txt Date: Mon, 01 Dec 2003 15:30:02 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 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 : Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Author(s) : P. Nesser II, A. Bergstrom Filename : draft-ietf-v6ops-ipv4survey-ops-04.txt Pages : 0 Date : 2003-12-1 This document seeks to document all usage of IPv4 addresses in currently deployed IETF Operations & Management Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-ops-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ipv4survey-ops-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-ops-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-1152307.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-ops-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-ops-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-1152307.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Mon Dec 1 15:35:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27914 for ; Mon, 1 Dec 2003 15:35:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AQugb-000CQ1-KO for v6ops-data@psg.com; Mon, 01 Dec 2003 20:30:25 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AQugO-000COt-7E for v6ops@ops.ietf.org; Mon, 01 Dec 2003 20:30:12 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27280; Mon, 1 Dec 2003 15:29:57 -0500 (EST) Message-Id: <200312012029.PAA27280@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-trans-04.txt Date: Mon, 01 Dec 2003 15:29:57 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 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 : Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Author(s) : P. Nesser II, A. Bergstrom Filename : draft-ietf-v6ops-ipv4survey-trans-04.txt Pages : 0 Date : 2003-12-1 This document seeks to document all usage of IPv4 addresses in currently deployed IETF Transport Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-trans-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ipv4survey-trans-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-trans-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-1152247.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-trans-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-trans-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-1152247.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Mon Dec 1 15:35:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27939 for ; Mon, 1 Dec 2003 15:35:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AQuh2-000CS6-04 for v6ops-data@psg.com; Mon, 01 Dec 2003 20:30:52 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AQugi-000CQx-6D for v6ops@ops.ietf.org; Mon, 01 Dec 2003 20:30:32 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27343; Mon, 1 Dec 2003 15:30:17 -0500 (EST) Message-Id: <200312012030.PAA27343@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-subip-04.txt Date: Mon, 01 Dec 2003 15:30:17 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 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 : Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Author(s) : P. Nesser II, A. Bergstrom Filename : draft-ietf-v6ops-ipv4survey-subip-04.txt Pages : 0 Date : 2003-12-1 This document seeks to document all usage of IPv4 addresses in currently deployed IETF Sub-IP Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-subip-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ipv4survey-subip-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-subip-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-1152332.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-subip-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-subip-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-1152332.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Mon Dec 1 15:35:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27961 for ; Mon, 1 Dec 2003 15:35:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AQuiN-000CWe-DB for v6ops-data@psg.com; Mon, 01 Dec 2003 20:32:15 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AQugb-000CPy-To for v6ops@ops.ietf.org; Mon, 01 Dec 2003 20:30:26 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27323; Mon, 1 Dec 2003 15:30:11 -0500 (EST) Message-Id: <200312012030.PAA27323@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-sec-03.txt Date: Mon, 01 Dec 2003 15:30:10 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 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 : Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Author(s) : P. Nesser II, A. Bergstrom Filename : draft-ietf-v6ops-ipv4survey-sec-03.txt Pages : 0 Date : 2003-12-1 This document seeks to document all usage of IPv4 addresses in currently deployed IETF Security Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Sandards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-sec-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ipv4survey-sec-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-sec-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <2003-12-1152321.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-sec-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-sec-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-1152321.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Tue Dec 2 01:29:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22160 for ; Tue, 2 Dec 2003 01:29:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AR3y5-000DPe-Ro for v6ops-data@psg.com; Tue, 02 Dec 2003 06:25:05 +0000 Received: from [192.11.222.163] (helo=ihemail2.firewall.lucent.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AR3xp-000DO4-US for v6ops@ops.ietf.org; Tue, 02 Dec 2003 06:24:49 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hB26Ok025625 for ; Tue, 2 Dec 2003 00:24:46 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Tue, 2 Dec 2003 07:24:44 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155030C8B5F@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: v6ops@ops.ietf.org Subject: FW: Document Action: 'Unmanaged Networks IPv6 Transition Scenari os' to Informational RFC Date: Tue, 2 Dec 2003 07:24:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Congrats and thanks to the WG. Pls keep moving closer to the end (as opposed to "futher from the beginning") Thanks, Bert -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: woensdag 26 november 2003 23:06 To: IETF-Announce Cc: Internet Architecture Board; RFC Editor; v6ops@ops.ietf.org Subject: Document Action: 'Unmanaged Networks IPv6 Transition Scenarios' to Informational RFC The IESG has approved following document: - 'Unmanaged Networks IPv6 Transition Scenarios ' as an Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact person is Bert Wijnen. RFC-Editor note: - On page 2, please replace text OLD: Between the subnet and the ISP access link is a gateway, which may or may not perform NAT and firewall functions. A key point of this configuration is that the gateway is typically not "managed". In most cases, it is a simple "appliance", which incorporates some static policies. However, there are many cases in which the gateway is procured and configured by the ISP, and there are also some common cases in which we find two gateways back to back, one managed by the ISP and the other added by the owner of the unmanaged network. NEW: Between the subnet and the ISP access link is a gateway, which may or may not perform NAT and firewall functions. A key point of this configuration is that the gateway is typically not "managed". In most cases, it is a simple "appliance", which incorporates some static policies. There are many cases in which the gateway is procured and configured by the ISP. Note that there are also some cases in which we find two gateways back to back, one managed by the ISP and the other added by the owner of the unmanaged network. They are not covered in this memo because most of them either require some management, or the gateway added by the user can function as a L2 switch. From owner-v6ops@ops.ietf.org Tue Dec 2 14:14:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02854 for ; Tue, 2 Dec 2003 14:14:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARFuJ-00069j-7Z for v6ops-data@psg.com; Tue, 02 Dec 2003 19:09:59 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARFu5-00068u-Fp for v6ops@ops.ietf.org; Tue, 02 Dec 2003 19:09:45 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hB2J9hE19163; Tue, 2 Dec 2003 21:09:43 +0200 Date: Tue, 2 Dec 2003 21:09:43 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: jonne.soininen@nokia.com, Subject: draft minutes from IETF58 in Minneapolis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Draft minutes from v6ops sessions at IETF58 in Minneapolis are now available, with presentations, at: http://www.6bone.net/v6ops/minutes/ Please review these and send updates/changes/etc. either on the list (if major) or directly to the chairs. Note: it's important that the minutes are accurate, as they are about the only official record on what happens in the face-to-face meetings. Thanks, Pekka, Jonne & Bob From owner-v6ops@ops.ietf.org Tue Dec 2 16:09:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11237 for ; Tue, 2 Dec 2003 16:09:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARHjB-000CSa-Sg for v6ops-data@psg.com; Tue, 02 Dec 2003 21:06:37 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARHiz-000CR1-P5 for v6ops@ops.ietf.org; Tue, 02 Dec 2003 21:06:25 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hB2L67D21851; Tue, 2 Dec 2003 23:06:07 +0200 Date: Tue, 2 Dec 2003 23:06:07 +0200 (EET) From: Pekka Savola To: bwijnen@lucent.com cc: v6ops@ops.ietf.org, Subject: Request to Advance "IPv4 Address Usage in Standards" Documents Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On behalf of the v6ops WG, we'd like to request that the following documents be published as Informational RFCs: Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards That is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-intro-05.txt http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-apps-03.txt http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-ops-04.txt http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-int-03.txt http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-routing-02.txt http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-sec-03.txt http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-subip-04.txt http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-trans-04.txt (Note: a minor issue has been noticed in each of trans-04 and routing-02, and they will be revised within a week, but this should not "stop the press".) Working group last calls for these documents were completed between August 12th and November 7th, and the revisions take the comments into account. The documents have also been extensively reviewed in the respective areas, and all the issues have been resolved. Thanks, Pekka, Jonne & Bob v6ops WG co-chairs From owner-v6ops@ops.ietf.org Wed Dec 3 00:57:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05048 for ; Wed, 3 Dec 2003 00:57:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARPx0-000FrK-9p for v6ops-data@psg.com; Wed, 03 Dec 2003 05:53:26 +0000 Received: from [192.11.222.163] (helo=ihemail2.firewall.lucent.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARPwn-000Fqd-Mu for v6ops@ops.ietf.org; Wed, 03 Dec 2003 05:53:13 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hB35r9011694 for ; Tue, 2 Dec 2003 23:53:10 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Wed, 3 Dec 2003 06:53:08 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155030C8DD7@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Pekka Savola , bwijnen@lucent.com Cc: v6ops@ops.ietf.org Subject: RE: Request to Advance "IPv4 Address Usage in Standards" Document s Date: Wed, 3 Dec 2003 06:53:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-v6ops@ops.ietf.org Precedence: bulk OK, on my plate. Will try to get it on Dec 18th telechat. But if you DO want that to happen, pls make sure that the 2 revisions you talk about get to internet-drafts at the very latest next week Tuesday. Thanks, Bert > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: dinsdag 2 december 2003 22:06 > To: bwijnen@lucent.com > Cc: v6ops@ops.ietf.org; iesg-secretary@ietf.org > Subject: Request to Advance "IPv4 Address Usage in Standards" > Documents > > > Hi, > > On behalf of the v6ops WG, we'd like to request that the following > documents be published as Informational RFCs: > > Introduction to the Survey of IPv4 Addresses in Currently > Deployed IETF Standards > Survey of IPv4 Addresses in Currently Deployed IETF > Application Area Standards > Survey of IPv4 Addresses in Currently Deployed IETF > Operations & Management Area Standards > Survey of IPv4 Addresses in Currently Deployed IETF Internet > Area Standards > Survey of IPv4 Addresses in Currently Deployed IETF Routing > Area Standards > Survey of IPv4 Addresses in Currently Deployed IETF Security > Area Standards > Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP > Area Standards > Survey of IPv4 Addresses in Currently Deployed IETF Transport > Area Standards > > That is: > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4surve y-intro-05.txt http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-apps-03.txt http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-ops-04.txt http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-int-03.txt http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-routing-02.txt http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-sec-03.txt http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-subip-04.txt http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-trans-04.txt (Note: a minor issue has been noticed in each of trans-04 and routing-02, and they will be revised within a week, but this should not "stop the press".) Working group last calls for these documents were completed between August 12th and November 7th, and the revisions take the comments into account. The documents have also been extensively reviewed in the respective areas, and all the issues have been resolved. Thanks, Pekka, Jonne & Bob v6ops WG co-chairs From owner-v6ops@ops.ietf.org Thu Dec 4 15:44:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13747 for ; Thu, 4 Dec 2003 15:44:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AS0FX-0005iA-4G for v6ops-data@psg.com; Thu, 04 Dec 2003 20:38:59 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AS0FJ-0005h8-4Z for v6ops@ops.ietf.org; Thu, 04 Dec 2003 20:38:45 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13388; Thu, 4 Dec 2003 15:38:29 -0500 (EST) Message-Id: <200312042038.PAA13388@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-trans-05.txt Date: Thu, 04 Dec 2003 15:38:28 -0500 X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com 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 : Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Author(s) : P. Nesser II, A. Bergstrom Filename : draft-ietf-v6ops-ipv4survey-trans-05.txt Pages : 0 Date : 2003-12-4 This document seeks to document all usage of IPv4 addresses in currently deployed IETF Transport Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-trans-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ipv4survey-trans-05.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-ipv4survey-trans-05.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: <2003-12-4154811.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-trans-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-trans-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-4154811.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri Dec 5 15:34:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24006 for ; Fri, 5 Dec 2003 15:34:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ASMb9-000ADa-Ac for v6ops-data@psg.com; Fri, 05 Dec 2003 20:30:47 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ASMaA-000A0Q-SD for v6ops@ops.ietf.org; Fri, 05 Dec 2003 20:29:47 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23735; Fri, 5 Dec 2003 15:29:31 -0500 (EST) Message-Id: <200312052029.PAA23735@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-isp-scenarios-analysis-00.txt Date: Fri, 05 Dec 2003 15:29:30 -0500 X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com 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 : Scenarios and Analysis for Introducing IPv6 into ISP Networks Author(s) : M. Lind Filename : draft-ietf-v6ops-isp-scenarios-analysis-00.txt Pages : 26 Date : 2003-12-5 This document first describes different scenarios for the introduction of IPv6 into an existing IPv4 ISP network without disrupting the IPv4 service. Then, this document analyses these scenarios and evaluates the suitability of the already defined transition mechanisms in this context. Known challenges are also identified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-isp-scenarios-analysis-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-isp-scenarios-analysis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-isp-scenarios-analysis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-5150816.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-isp-scenarios-analysis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-isp-scenarios-analysis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-5150816.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri Dec 5 15:35:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24068 for ; Fri, 5 Dec 2003 15:35:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ASMac-000A7H-2c for v6ops-data@psg.com; Fri, 05 Dec 2003 20:30:14 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ASMaF-000A1c-UV for v6ops@ops.ietf.org; Fri, 05 Dec 2003 20:29:52 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23752; Fri, 5 Dec 2003 15:29:35 -0500 (EST) Message-Id: <200312052029.PAA23752@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-routing-03.txt Date: Fri, 05 Dec 2003 15:29:35 -0500 X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com 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 : Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Author(s) : C. Olvera, P. Nesser II Filename : draft-ietf-v6ops-ipv4survey-routing-03.txt Pages : 17 Date : 2003-12-5 This investigation work seeks to document all usage of IPv4 addresses in currently deployed IETF Routing Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-routing-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ipv4survey-routing-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-routing-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <2003-12-5150828.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-routing-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-routing-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-5150828.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Mon Dec 8 04:25:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02217 for ; Mon, 8 Dec 2003 04:25:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATHYk-000F22-EO for v6ops-data@psg.com; Mon, 08 Dec 2003 09:20:06 +0000 Received: from [144.254.74.5] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATHYW-000F0X-Vx for v6ops@ops.ietf.org; Mon, 08 Dec 2003 09:19:53 +0000 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Dec 2003 10:16:58 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB89JaDC023966; Mon, 8 Dec 2003 10:19:37 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 8 Dec 2003 09:19:50 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C3BD6C.6DF8D7CA" Subject: FW: I-D ACTION:draft-ietf-v6ops-isp-scenarios-analysis-00.txt Date: Mon, 8 Dec 2003 09:19:49 -0000 Message-ID: X-MS-Has-Attach: yes Thread-Topic: I-D ACTION:draft-ietf-v6ops-isp-scenarios-analysis-00.txt Thread-Index: AcO7b2g1jeX9SkC0TSS0FDhPCXq1fAB9/lRg From: "Francois Le Faucheur (flefauch)" To: , , , Cc: , X-OriginalArrivalTime: 08 Dec 2003 09:19:50.0472 (UTC) FILETIME=[6E834480:01C3BD6C] X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3BD6C.6DF8D7CA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Thanks for having taken into account earlier suggestions on "scenarios" = draft. A few suggestions on this version: "=20 A workaround is to use BGP for signaling and/or to perform IPv6- over-IPv4/MPLS or IPv6-over-IPv4-over-IPv4/MPLS encapsulation, for=20 example, as described in [BGPTUNNEL]. " I suggest replacing "workaround" by "an alternative approach". This is = not a workaround. It is a very fine solution for those who do not wish = to upgrade the core to IPv6 right away, which is what this section is = all about. " There seem to be multiple=20 possibilities, some of which may be more preferable than others. " I suggest replacing "may be more preferable than others" by something = like "may be more preferable than others depending on the specific = considered environement".=20 " More analysis is needed in order to determine which are the best=20 approach(es): " I suggest replacing "the best approach(es)" by "the best approach(es) = for a specific environment". " =20 1) require that MPLS networks deploy native IPv6 support or=20 use configured tunneling for IPv6.=20 =20 2) require that MPLS networks support setting up IPv6 LSPs,=20 and IPv6 connectivity is set up using them, or configured = tunneling is used.=20 =20 3) use only configured tunneling over the IPv4 LSPs; this =20 seems practical with small-scale deployments when the=20 number of tunnels is low.=20 =20 4) use something like [BGPTUNNEL] to perform IPv6-over-=20 IPv4/MPLS encapsulation for IPv6 connectivity.=20 " Without suggesting any specific text for the "analysis in order to = determine which are the best approach(es) for a specific environment", = it seems that: - 1) and 2) may be attractive where the operator is willing to perform = significant control plane upgrade in the core. - 3) may be attractive where the operator wants to avoid upgrade in the = core AND has a small-scale deployment for IPv6 -4) may be attractive where the operator wants to avoid any upgrade in = the core AND has small or large scale deployment of IPv6 Do we agree? Cheers Francois >> -----Original Message----- >> From: owner-v6ops@ops.ietf.org=20 >> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of=20 >> Internet-Drafts@ietf.org >> Sent: vendredi 5 d=E9cembre 2003 21:30 >> Cc: v6ops@ops.ietf.org >> Subject: I-D ACTION:draft-ietf-v6ops-isp-scenarios-analysis-00.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line=20 >> Internet-Drafts directories. >> This draft is a work item of the IPv6 Operations Working=20 >> Group of the IETF. >>=20 >> Title : Scenarios and Analysis for=20 >> Introducing IPv6 into ISP Networks >> Author(s) : M. Lind >> Filename : draft-ietf-v6ops-isp-scenarios-analysis-00.txt >> Pages : 26 >> Date : 2003-12-5 >> =09 >> This document first describes different scenarios for the=20 >> introduction of IPv6 into an existing IPv4 ISP network without=20 >> disrupting the IPv4 service. Then, this document analyses these=20 >> scenarios and evaluates the suitability of the already defined=20 >> transition mechanisms in this context. Known challenges are also=20 >> identified. >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-isp-scen arios-analysis-00.txt To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the = message. 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-isp-scenarios-analysis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-isp-scenarios-analysis-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C3BD6C.6DF8D7CA Content-Type: application/octet-stream; name="draft-ietf-v6ops-isp-scenarios-analysis-00.URL" Content-Description: draft-ietf-v6ops-isp-scenarios-analysis-00.URL Content-Disposition: attachment; filename="draft-ietf-v6ops-isp-scenarios-analysis-00.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLXY2b3BzLWlzcC1zY2VuYXJpb3MtYW5hbHlzaXMtMDAudHh0DQo= ------_=_NextPart_001_01C3BD6C.6DF8D7CA-- From owner-v6ops@ops.ietf.org Wed Dec 10 08:35:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11267 for ; Wed, 10 Dec 2003 08:35:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AU4No-0002fb-3Z for v6ops-data@psg.com; Wed, 10 Dec 2003 13:28:04 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AU4Na-0002dG-Ei for v6ops@ops.ietf.org; Wed, 10 Dec 2003 13:27:50 +0000 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBADRmn09174 for ; Wed, 10 Dec 2003 15:27:49 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 10 Dec 2003 15:27:48 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 10 Dec 2003 15:27:48 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: 3gpp-analysis-07: (semi-)editorial issues Date: Wed, 10 Dec 2003 15:27:46 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F020CE0C9@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis-07: (semi-)editorial issues Thread-Index: AcOrdN0ArUE5d+hzT/mBcSLgGvHVtQTqJvOg From: To: , X-OriginalArrivalTime: 10 Dec 2003 13:27:48.0560 (UTC) FILETIME=[675ED500:01C3BF21] X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Pekka and others! Thanks for these comments, Pekka! Finally starting to go through the = rest of the comments: -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On Behalf Of ext Pekka Savola semi-substantial ---------------- 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes In this scenario, the dual stack UE is capable of communicating with both IPv4 and IPv6 nodes. It is recommended to activate an IPv6 PDP context when communicating with an IPv6 peer node and an IPv4 PDP context when communicating with an IPv4 peer node. If the 3GPP network supports both IPv4 and IPv6 PDP contexts, the UE activates the appropriate PDP context depending on the type of application it has started or depending on the address of the peer host it needs to communicate with. =3D=3D> I think it would be useful to state that (because PDP context = activation is a time-consuming process) it might make sense to activate both PDP context in advance, just in case they're used, as long as there are any applications for the opened PDP context? Maybe reword the last sentence = and add a bit: If the 3GPP network supports both IPv4 and IPv6 PDP contexts, the UE may activate the appropriate PDP context depending on the type of application it has started; it may also make sense to open both PDP contexts in advance, before they are used, because the activation of a context may take a relatively long time. .. somehow I don't think activating PDP context based on the peer = address is a realistic option right? JW: in later discussion (Karim, Pekka, et co), this was the text = suggested:=20 "If the 3GPP network supports both IPv4 and IPv6 PDP contexts, the = UE may activate the appropriate PDP context depending on the type of application it has started; it may also make sense to open both PDP contexts in advance, before they are used, because the activation of a context may take a relatively long time. However, if=20 the appropriate PDP context has not been activated before trying to=20 communicate with a peer, the application may trigger the activation = of=20 the required PDP context type." Only thing that somehow worries me is activating PDP contexts that may = not be needed, i.e. extra usage of network resources. Should we add some = note on that, e.g. draft-elmalki-sipping... states that " Another important requirement is to minimize the number of active PDP Contexts a host has on any given time. A reason for this is that there are practical constraints on the number of PDP Contexts which a 3GPP host may establish. If a host uses many PDP Contexts it consumes extra resources in the 3GPP network. That is because each PDP Context requires a state to be maintained in the 3GPP network. In addition, each PDP Context would normally require radio signaling and a new radio channel to be established to the 3GPP host. Therefore each additional PDP Context also consumes extra radio resources required to establish the radio channel. For these reasons, any transition solution should support the case where a 3GPP host utilises only one IPv6 PDP Context, without the need to activate additional IPv4 PDP Contexts." If IPv6 PDP contexts are available and IPv6-in-IPv4 tunneling is needed, it is recommended to activate an IPv6 PDP context and perform tunneling in the network. This case is described in more detail in section 3.2. =3D=3D> I don't understand this at all. If IPv6 PDP context is = available, it is available natively. The UE doesn't know about v6-in-v4 tunneling in the first place. So, isn't there some confusion here? Or did the text mean = to say something like, "If both v6 or v4 can be used, v6 should be = preferred"?=20 Not sure if that's needed, but if so, consider e.g.: If an application can use both IPv4 and IPv6, and IPv6 PDP contexts = are available, it is preferable to try IPv6 communication first. ... but this is already stated in the "As a general guideline..." -paragraph, so seems redundant? JW: The current text is just saying that if IPv6 PDP contexts are = available and IPv6-in-IPv4 tunneling is still needed somewhere between = the UE and its peer node, it is better to activate IPv6 PDP context and = do the tunneling in the network (instead of activating IPv4 PDP context = and making tunneling in the UE). Anyway, the suggested way to go is not = visible to the terminal at all, and communciation looks like native IPv6 = communication to it. An application running on a UE can identify whether the endpoint is an IPv4 or IPv6 capable node by examining the destination address. Alternatively, if a user supplies a name to be resolved, the DNS may contain records sufficient to identify which protocol should be used to initiate the connection with the endpoint. In dual stack networks, one of the main concerns of an operator is the correct address space and routing management. The operator must maintain address spaces for both protocols. Public IPv4 addresses are often a scarce resource for the operator and typically it is not possible for a UE to have a globally unique IPv4 address (continuously) allocated for its use. Use of private IPv4 addresses means use of NATs when communicating with a peer node outside the operator's network. In large networks, NAT systems can become very complex, expensive and difficult to maintain. =3D=3D> I don't see a direct relation of this paragraph to the = recommendations in this document: the first part describes (incorrectly) how to get the address of the peer; the second part describes dual-stack = considerations; the last part describes IPv4 NAT's. I suggest removing it. The one = thing that may make to preserve in some form is that the 3GPP operators = typically use the private IPv4 addresses. JW: Yep, rewording and text removal looks necessary. The first part can = be removed, but I would like to retain some description on private = address spaces and NAT. That should be described in our document (at = least as a motivation to start to use IPv6). semi-editorial -------------- can typically access both IPv4 and IPv6 services without additional translators in the network. However, it is good to remember that public IPv4 addresses are a scarce resource and in many cases IPv4 NATs are deployed. Public/global IP addresses are also needed for peer-to-peer services: the node needs a public/global IP address =3D=3D> s/a scarce resource/hard to come by/ (they aren't really scarce as such, but it takes just a huge amount of paperwork etc. to get them..) JW: No problems with that kind of wording, but I still would like to = keep "scarce resource" term there. If you think about the growth rate of = mobile phones, it is an impossible task to get a public IPv4 address for = all of them. If not today, after some time it certainly will be = impossible... Note that this scenario is comparable to 6bone [6BONE] network operation. =3D=3D> remove this; 6bone is being run down for good, and no other = alternative reference is out there. We can live without it.. JW: Ack. 11. Changes from draft-ietf-v6ops-3gpp-analysis-06.txt =3D=3D> add here something like: [[ RFC-editor note: remove the section prior to publication ]] JW: Roger. editorial --------- IMS scenarios are the following: - UE connecting to a node in an IPv4 network through IMS - Two IMS islands connected via IPv4 network =3D=3D> s/via/via an/ JW: Yep. "In order to preserve name space continuity, the following administrative policies are RECOMMENDED: - every recursive DNS server SHOULD be either IPv4-only or = dual stack, - every single DNS zone SHOULD be served by at least one = IPv4 =3D=3D> here there seem to be some odd extra spaces etc. -- cut'n'paste = error? JW: Hmm, seems to be... will fix that. In a 3GPP network, one IPv6 island can contain the GGSN while another island can contain the operator's IPv6 application servers. =3D=3D> s/can/may/ (twice) ? JW: OK. As a general guideline, IPv6-only UEs are not recommended in the early phases of transition until the IPv6 deployment has become so prevalent that direct =20 =3D=3D> split to a new paragraph, starting from "As a gene..." JW: OK. On the user data transport level, the translation is IPv4-IPv6=20 protocol translation, where the user data traffic transported is=20 translated from IPv6 to IPv4, and vice versa.=20 =3D=3D> there should have been an empty line before this paragraph, = missing somewhere? JW: An editing problem, will fix that. Thanks, -Juha- From owner-v6ops@ops.ietf.org Wed Dec 10 15:46:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15910 for ; Wed, 10 Dec 2003 15:46:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AUB8y-000OZy-0z for v6ops-data@psg.com; Wed, 10 Dec 2003 20:41:12 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AUB8F-000ONe-UV for v6ops@ops.ietf.org; Wed, 10 Dec 2003 20:40:28 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15293; Wed, 10 Dec 2003 15:40:21 -0500 (EST) Message-Id: <200312102040.PAA15293@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-application-transition-00.txt Date: Wed, 10 Dec 2003 15:40:21 -0500 X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com 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 : Application Aspects of IPv6 Transition Author(s) : M. Shin Filename : draft-ietf-v6ops-application-transition-00.txt Pages : 27 Date : 2003-12-10 As IPv6 networks are deployed and the network transition discussed, one should also consider how to enable IPv6 support in applications running on IPv6 hosts, and what is the best strategy to develop IP protocol support in applications. This document specifies scenarios and aspects of application transition. It also proposes guidelines on how to develop IP version-independent applications during the transition period. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-application-transition-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-application-transition-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-application-transition-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-10160035.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-application-transition-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-application-transition-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-10160035.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Dec 11 15:02:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17663 for ; Thu, 11 Dec 2003 15:02:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AUWvT-000Jxf-IJ for v6ops-data@psg.com; Thu, 11 Dec 2003 19:56:43 +0000 Received: from [192.11.223.161] (helo=auemail1.firewall.lucent.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AUWv9-000Jw9-VN for v6ops@ops.ietf.org; Thu, 11 Dec 2003 19:56:24 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBBJuJg12051 for ; Thu, 11 Dec 2003 13:56:20 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Thu, 11 Dec 2003 20:56:02 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155031D6F3B@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "V6ops (E-mail)" Subject: Minutes from IETF58 Date: Thu, 11 Dec 2003 20:56:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-v6ops@ops.ietf.org Precedence: bulk Need to be submitted to minutes@ietf.org no later than Friday 19th of December. Current status: 1 presentation file received, no minutes See: http://www.ietf.org/proceedings/03nov/index.html Thanks, Bert From owner-v6ops@ops.ietf.org Fri Dec 12 07:22:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05637 for ; Fri, 12 Dec 2003 07:22:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AUmDZ-0000ci-F5 for v6ops-data@psg.com; Fri, 12 Dec 2003 12:16:25 +0000 Received: from [195.212.29.154] (helo=mtagate5.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AUmDI-0000bj-Hr for v6ops@ops.ietf.org; Fri, 12 Dec 2003 12:16:08 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id hBCCG6Gs132586 for ; Fri, 12 Dec 2003 12:16:06 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hBCCG6SO089476 for ; Fri, 12 Dec 2003 13:16:06 +0100 Received: from zurich.ibm.com ([9.145.247.196]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA33574 for ; Fri, 12 Dec 2003 13:16:04 +0100 Message-ID: <3FD9B14D.BFDE19EF@zurich.ibm.com> Date: Fri, 12 Dec 2003 13:15:09 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: IPv6 Operations Subject: Re: I-D ACTION:draft-ietf-v6ops-ent-scenarios-00.txt References: <200310161930.PAA19049@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Some comments... > 3.2 Scenarios Characteristics ... > - Do any of the software functions store IP addresses? Should be "store, display, or allow input of IP addresses?" ... > - Do any of the hardware functions store IP addresses? ditto > 4.3 IPv6 communicating with IPv4 > > An IPv6 only node wants to communicate with an IPv4 only node. > > In cases where the IPv6 host cannot be a dual stack, in order to > continue support of communications with IPv4 nodes an IPv4/v6 > translator is required. Introduction of such translator will prevent > usage of end-to-end security and application carrying embedded IP > addressing information. There's a big hole here - i.e. the alternative solution which is an applications proxy. www.ipv6-test.ibm.com is running code. > > **Note to V6ops WG: Should we discuss porting of applications too in > the legacy section? No. That should remain a separate document. > 5.1 DNS > > DNS will now have to support both IPv4 and IPv6 DNS records and the > Enterprise will need to determine how the DNS is to be managed and > accessed, and secured. > > **Note to V6ops WG: Should we get into other DNS issues? Probably DNSOP should do some of that. But how DNS interacts with stateless and stateful autoconfiguration probably needs to be discussed here, for example. > 5.4 Security > > Current existing mechanisms used for IPv4 to provide security need to > be supported for IPv6 within the Enterprise. That's not true if NAT is viewed as a security mechanism. We need to describe how security-by-hiding is achieved in IPv6 - presumably by a combination of some form of local addressing in parallel with global addressing, and appropriate filters and ACLs in the firewall. > ...IPv6 should create no > new security concerns for IPv4. Is that certain? Where is the complete threat analysis? > > **Note to V6ops WG: Should we get into other security issues? Yes. Fears about security will be a major hurdle in enterprise deployment. We need much, much more about security - probably a complete BCP on its own. > 5.5 Applications > > Existing applications will need to be ported to support both IPv4 and > IPv6. s/ported/ported or proxyed/ > > **Note to V6ops WG: Should we get into other application issues? Not in this document. ... > **Note to V6ops WG: What other components are we missing? Multihoming. Brian From owner-v6ops@ops.ietf.org Fri Dec 12 07:45:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06125 for ; Fri, 12 Dec 2003 07:45:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AUmdX-0003BX-Iz for v6ops-data@psg.com; Fri, 12 Dec 2003 12:43:15 +0000 Received: from [195.212.29.155] (helo=mtagate6.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AUmdJ-0003AF-QU for v6ops@ops.ietf.org; Fri, 12 Dec 2003 12:43:02 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate6.de.ibm.com (8.12.10/8.12.10) with ESMTP id hBCCh0tM090742 for ; Fri, 12 Dec 2003 12:43:00 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hBCCgxmM282444 for ; Fri, 12 Dec 2003 13:43:00 +0100 Received: from zurich.ibm.com ([9.145.247.196]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA32458 for ; Fri, 12 Dec 2003 13:42:58 +0100 Message-ID: <3FD9B79B.54FB9EA@zurich.ibm.com> Date: Fri, 12 Dec 2003 13:42:03 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: IPv6 Operations Subject: Re: I-D ACTION:draft-ietf-v6ops-application-transition-00.txt References: <200312102040.PAA15293@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I have a couple of general comments and then some details. General: 1) The document still needs quite a lot of work on (minor) errors in English and so on. I have not tackled this. 2) I think there is a need to "spam" people with experience in porting applications for their comments on this draft. Details: > 2. Overview of IPv6 application transition > > The transition of an application can be classifed using four > different cases (excluding the first case when there is no IPv6 > support either in the application or the operating system), as > follows: > > +-------------------+ > | appv4 | (appv4 - IPv4-only applications) > +-------------------+ > | TCP / UDP | (transport protocols) > +-------------------+ > | IPv4 | IPv6 | (IP protocols supported/enabled in the OS) > +-------------------+ > > Case 1. IPv4 applications in a dual-stack node These days we have to consider SCTP, DCCP etc too. > 5.1 Presentation format for an IP address This section should refer to draft-main-ipaddr-text-rep-00.txt It should also mention the different format defined in RFC 2821 (i.e. [IPv6:...] ) > 5.4.3 Storage of IP addresses ... > Instead of using IP addresses, applications should use FQDNs. > Hence, applications delegate the resolution of the IP addresses to > the name resolution system, which will return the associated IP > address at the moment of the query. This makes it sound too easy. I think that in some contexts (such as massive peer to peer systems, or highly dynamic networking) this is bad advice. Even in normal situations, it may be appropriate to cache addresses for a considerable time. I would rewrite as When possible, applications should store names, such as FQDNs, instead of storing addresses. In this case applications are only bound to specific addresses at run time, or for the duration of a cache lifetime. Other types of application, such as massive peer to peer systems with their own rendez-vous and discovery mechanisms, may need to cache addresses for performance reasons, but cached addresses should not be treated as permanent, reliable information. In highly dynamic networks any form of name resolution may be impossible, and here again addresses must be cached. > 7. Transition mechanism considerations > > A mechanism, [NAT-PT], introduces a special set of addresses, > formed of NAT-PT prefix and an IPv4 address; this refers to IPv4 > addresses, translated by NAT-PT DNS-ALG. In some cases, one might > be tempted to handle these differently. > > However, IPv6 applications must not be required to distinguish > "normal" and "NAT-PT translated" addresses (or any other kind of > special addresses, including the IPv6-mapped IPv4-addresses): that > would be completely unscalable, and if such distinction must be > made, it must be done elsewhere (e.g. kernel, system libraries). I'm not sure why it would be unscalable - messy, yes, but not unscalable. Also, what if an application *wants* to treat a NAT-PT based session differently (i.e. implement some legacy features because it knows that the other end is IPv4)? Shouldn't the socket API be capable of telling the upper layer "this address was translated"? Brian From owner-v6ops@ops.ietf.org Tue Dec 16 05:59:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10613 for ; Tue, 16 Dec 2003 05:59:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AWCpt-0003iL-UN for v6ops-data@psg.com; Tue, 16 Dec 2003 10:53:53 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AWCpf-0003hE-52 for v6ops@ops.ietf.org; Tue, 16 Dec 2003 10:53:39 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hBGArYo29508; Tue, 16 Dec 2003 12:53:34 +0200 Date: Tue, 16 Dec 2003 12:53:34 +0200 (EET) From: Pekka Savola To: juha.wiljakka@nokia.com cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-07: (semi-)editorial issues In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834F020CE0C9@esebe005.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-v6ops@ops.ietf.org Precedence: bulk Sorry for the delay on getting back at this .. I was off email the last week.. Inline to a couple of issues that weren't maybe 100% clear.. On Wed, 10 Dec 2003 juha.wiljakka@nokia.com wrote: > JW: in later discussion (Karim, Pekka, et co), this was the text suggested: > > "If the 3GPP network supports both IPv4 and IPv6 PDP contexts, the UE may > activate the appropriate PDP context depending on the type of > application it has started; it may also make sense to open both PDP > contexts in advance, before they are used, because the activation of > a context may take a relatively long time. However, if > the appropriate PDP context has not been activated before trying to > communicate with a peer, the application may trigger the activation of > the required PDP context type." OK with me. > Only thing that somehow worries me is activating PDP contexts that > may not be needed, i.e. extra usage of network resources. Should we > add some note on that, e.g. draft-elmalki-sipping... states that I note that there are two cases here: 1) if you desire to operate the node as much in v6-only mode as possible (not opening v4 PDP context unless you have to), or 2) if you desire to operate the node as much in v4-only mode as possible (not opening v6 PDP contexts unless you intend to use apps which use v6). Which problem (or both?) are you worried of at this point? At this point, I think 1) is premature but could be triggered with the help of web proxies, etc. when the number of v6 users rises. I guess the main problem is how the vendor could devise an algorithm or a "hint" on when to start relying on IPvXX PDP contexts. This could be difficult. The latter may not be a problem, because either the node is explicitly v6-enabled, or it has some apps (e.g. IMS subsystem, etc.) which could trigger the activation of v6 PDP context. Is there more to it? Maybe there could be a need to spell it out a bit, but the elmalki-sipping-XXX text proposed below seems a bit too strong to me. > If IPv6 PDP contexts are > available and IPv6-in-IPv4 tunneling is needed, it is recommended > to activate an IPv6 PDP context and perform tunneling in the > network. This case is described in more detail in section 3.2. > > ==> I don't understand this at all. If IPv6 PDP context is available, it is > available natively. The UE doesn't know about v6-in-v4 tunneling in the > first place. So, isn't there some confusion here? Or did the text mean to > say something like, "If both v6 or v4 can be used, v6 should be preferred"? > Not sure if that's needed, but if so, consider e.g.: > > If an application can use both IPv4 and IPv6, and IPv6 PDP contexts are > available, it is preferable to try IPv6 communication first. > > ... but this is already stated in the "As a general guideline..." > -paragraph, so seems redundant? > > JW: The current text is just saying that if IPv6 PDP contexts are > available and IPv6-in-IPv4 tunneling is still needed somewhere > between the UE and its peer node, it is better to activate IPv6 PDP > context and do the tunneling in the network (instead of activating > IPv4 PDP context and making tunneling in the UE). Anyway, the > suggested way to go is not visible to the terminal at all, and > communciation looks like native IPv6 communication to it. Ok, then maybe reword to something like ? : IPv6 PDP contexts should be used even if that meant IPv6-in-IPv4 tunneling would be needed in the network (see section 3.2 for more details). Note that this is transparent to the UE. > An application running on a UE can identify whether the endpoint is > an IPv4 or IPv6 capable node by examining the destination address. > Alternatively, if a user supplies a name to be resolved, the DNS > may contain records sufficient to identify which protocol should be > used to initiate the connection with the endpoint. In dual stack > networks, one of the main concerns of an operator is the correct > address space and routing management. The operator must maintain > address spaces for both protocols. Public IPv4 addresses are often > a scarce resource for the operator and typically it is not possible > for a UE to have a globally unique IPv4 address (continuously) > allocated for its use. Use of private IPv4 addresses means use of > NATs when communicating with a peer node outside the operator's > network. In large networks, NAT systems can become very complex, > expensive and difficult to maintain. > > ==> I don't see a direct relation of this paragraph to the recommendations > in this document: the first part describes (incorrectly) how to get the > address of the peer; the second part describes dual-stack considerations; > the last part describes IPv4 NAT's. I suggest removing it. The one thing > that may make to preserve in some form is that the 3GPP operators typically > use the private IPv4 addresses. > > JW: Yep, rewording and text removal looks necessary. The first part > can be removed, but I would like to retain some description on > private address spaces and NAT. That should be described in our > document (at least as a motivation to start to use IPv6). Agreed, that should be good background material. > semi-editorial > -------------- > > can typically access both IPv4 and IPv6 services without additional > translators in the network. However, it is good to remember that > public IPv4 addresses are a scarce resource and in many cases IPv4 > NATs are deployed. Public/global IP addresses are also needed for > peer-to-peer services: the node needs a public/global IP address > > ==> s/a scarce resource/hard to come by/ > (they aren't really scarce as such, but it takes just a huge amount of > paperwork etc. to get them..) > > JW: No problems with that kind of wording, but I still would like to > keep "scarce resource" term there. If you think about the growth > rate of mobile phones, it is an impossible task to get a public IPv4 > address for all of them. If not today, after some time it certainly > will be impossible... I'm OK with both, even though I prefer "hard to come by" or something like that. There are still over a billion addresses left, so they aren't really that _scarce_ :-). The registries keep saying that there is no shortage of address space. I'd actually *like* to have a mobile operator request public v4 space for all of its devices instead of doing NAT. :-) -- 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 Dec 18 12:53:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05537 for ; Thu, 18 Dec 2003 12:53:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AX2EV-000H6r-TI for v6ops-data@psg.com; Thu, 18 Dec 2003 17:46:43 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AX2EH-000H5G-DX for v6ops@ops.ietf.org; Thu, 18 Dec 2003 17:46:29 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hBIHkNY21464; Thu, 18 Dec 2003 19:46:25 +0200 Date: Thu, 18 Dec 2003 19:46:23 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: IPv6 Operations Subject: Re: I-D ACTION:draft-ietf-v6ops-application-transition-00.txt In-Reply-To: <3FD9B79B.54FB9EA@zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Thanks for comments, Brian; more in-line -- responding as co-author.. On Fri, 12 Dec 2003, Brian E Carpenter wrote: > General: > > 1) The document still needs quite a lot of work on (minor) errors in > English and so on. I have not tackled this. Yep.. > 2) I think there is a need to "spam" people with experience in porting applications > for their comments on this draft. Agreed, if we could find fresh new forums to send this to. Suggestions are still welcome :-) > > 2. Overview of IPv6 application transition > > > > The transition of an application can be classifed using four > > different cases (excluding the first case when there is no IPv6 > > support either in the application or the operating system), as > > follows: > > > > +-------------------+ > > | appv4 | (appv4 - IPv4-only applications) > > +-------------------+ > > | TCP / UDP | (transport protocols) > > +-------------------+ > > | IPv4 | IPv6 | (IP protocols supported/enabled in the OS) > > +-------------------+ > > > > Case 1. IPv4 applications in a dual-stack node > > These days we have to consider SCTP, DCCP etc too. Agreed. I think we should do the following: 1) replace "TCP / UDP" to "TCP / UDP / others" (or something like that). 2) contact SCTP and DCCP WGs or some knowledgeable folks to ping whether the document requires more extensive changes due to these protocols. (If the changes were too extensive, we could also decree them out of scope, but that would remain to be seen.) Myung-Ki, maybe you could try to do this as the editor? 3) do a little bit of review if some other whether some minor wording changes would be needed to take non-TCP/UDP cases in the consideration better. > > 5.1 Presentation format for an IP address > > This section should refer to draft-main-ipaddr-text-rep-00.txt > > It should also mention the different format defined in RFC 2821 > (i.e. [IPv6:...] ) Seems sensible. > > 5.4.3 Storage of IP addresses > ... > > Instead of using IP addresses, applications should use FQDNs. > > Hence, applications delegate the resolution of the IP addresses to > > the name resolution system, which will return the associated IP > > address at the moment of the query. > > This makes it sound too easy. I think that in some contexts (such as > massive peer to peer systems, or highly dynamic networking) this is bad > advice. Even in normal situations, it may be appropriate to cache addresses > for a considerable time. I would rewrite as > > When possible, applications should store names, such as FQDNs, instead > of storing addresses. In this case applications are only bound to specific > addresses at run time, or for the duration of a cache lifetime. Other types > of application, such as massive peer to peer systems with their own > rendez-vous and discovery mechanisms, may need to cache addresses for > performance reasons, but cached addresses should not be treated as permanent, > reliable information. In highly dynamic networks any form of name resolution > may be impossible, and here again addresses must be cached. Agreed -- this would seem to make sense. > > 7. Transition mechanism considerations > > > > A mechanism, [NAT-PT], introduces a special set of addresses, > > formed of NAT-PT prefix and an IPv4 address; this refers to IPv4 > > addresses, translated by NAT-PT DNS-ALG. In some cases, one might > > be tempted to handle these differently. > > > > However, IPv6 applications must not be required to distinguish > > "normal" and "NAT-PT translated" addresses (or any other kind of > > special addresses, including the IPv6-mapped IPv4-addresses): that > > would be completely unscalable, and if such distinction must be > > made, it must be done elsewhere (e.g. kernel, system libraries). > > I'm not sure why it would be unscalable - messy, yes, but not unscalable. Maybe we're using different words to describe the same issue. I call this unscalable because I do not want to see every application to implement it's own version of this (about 50% of them being probably incorrect or otherwise wrong :-). > Also, what if an application *wants* to treat a NAT-PT based session differently > (i.e. implement some legacy features because it knows that the other end > is IPv4)? Shouldn't the socket API be capable of telling the upper layer > "this address was translated"? Maybe yes, but the point is that APIs do not provide these *today*. If they did, I don't think there would be all that many problems having something like this implemented as part of APIs. -- 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 Dec 19 09:23:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10036 for ; Fri, 19 Dec 2003 09:23:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AXLSO-00097m-Jm for v6ops-data@psg.com; Fri, 19 Dec 2003 14:18:20 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AXLSB-000978-Hh for v6ops@ops.ietf.org; Fri, 19 Dec 2003 14:18:07 +0000 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBJEI3017120 for ; Fri, 19 Dec 2003 16:18:04 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 19 Dec 2003 16:17:59 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 19 Dec 2003 16:17:58 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: 3gpp-analysis-07: (semi-)editorial issues Date: Fri, 19 Dec 2003 16:17:55 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F020CE0FB@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis-07: (semi-)editorial issues Thread-Index: AcPDwt4sKCtJaf+RQoScEiUZ9wmadACdKYFQ From: To: Cc: X-OriginalArrivalTime: 19 Dec 2003 14:17:58.0962 (UTC) FILETIME=[E76D7920:01C3C63A] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Pekka and others! -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 16 December, 2003 12:54 Inline to a couple of issues that weren't maybe 100% clear.. On Wed, 10 Dec 2003 juha.wiljakka@nokia.com wrote: =20 > Only thing that somehow worries me is activating PDP contexts that > may not be needed, i.e. extra usage of network resources. Should we > add some note on that, e.g. draft-elmalki-sipping... states that I note that there are two cases here: 1) if you desire to operate the node as much in v6-only mode as=20 possible (not opening v4 PDP context unless you have to), or 2) if you desire to operate the node as much in v4-only mode as=20 possible (not opening v6 PDP contexts unless you intend to use apps=20 which use v6). Which problem (or both?) are you worried of at this point? =20 JW: In my opinion, this sentence can be problematic: "it may also make = sense to open both PDP contexts in advance, before they are used, = because the activation of a context may take a relatively long time." =20 It can lead to a situation in which we have activated hundreds of = thousands extra, unused PDP contexts in the network and this is not good = from network resource usage point of view. PDP context usage is quite = much defined by used applications and I think we shouldn't write "open = both types of PDP contexts in advance" recommendation. My recommendation = is to leave the PDP context activation policy decided by the = implementers / application developers. At this point, I think 1) is premature but could be triggered with the help of web proxies, etc. when the number of v6 users rises. I guess=20 the main problem is how the vendor could devise an algorithm or a=20 "hint" on when to start relying on IPvXX PDP contexts. This could be=20 difficult. The latter may not be a problem, because either the node is explicitly=20 v6-enabled, or it has some apps (e.g. IMS subsystem, etc.) which could=20 trigger the activation of v6 PDP context. > If IPv6 PDP contexts are > available and IPv6-in-IPv4 tunneling is needed, it is recommended > to activate an IPv6 PDP context and perform tunneling in the > network. This case is described in more detail in section 3.2. >=20 > =3D=3D> I don't understand this at all. If IPv6 PDP context is = available, it is > available natively. The UE doesn't know about v6-in-v4 tunneling in = the > first place. So, isn't there some confusion here? Or did the text = mean to > say something like, "If both v6 or v4 can be used, v6 should be = preferred"?=20 > Not sure if that's needed, but if so, consider e.g.: >=20 > If an application can use both IPv4 and IPv6, and IPv6 PDP = contexts are > available, it is preferable to try IPv6 communication first. >=20 > ... but this is already stated in the "As a general guideline..." > -paragraph, so seems redundant? >=20 > JW: The current text is just saying that if IPv6 PDP contexts are > available and IPv6-in-IPv4 tunneling is still needed somewhere > between the UE and its peer node, it is better to activate IPv6 PDP > context and do the tunneling in the network (instead of activating > IPv4 PDP context and making tunneling in the UE). Anyway, the > suggested way to go is not visible to the terminal at all, and > communciation looks like native IPv6 communication to it. Ok, then maybe reword to something like ? : IPv6 PDP contexts=20 should be used even if that meant IPv6-in-IPv4 tunneling would be=20 needed in the network (see section 3.2 for more details). Note=20 that this is transparent to the UE. JW: Looks quite ok. Maybe changing used -> preferred.=20 > An application running on a UE can identify whether the endpoint = is > an IPv4 or IPv6 capable node by examining the destination address. > Alternatively, if a user supplies a name to be resolved, the DNS > may contain records sufficient to identify which protocol should = be > used to initiate the connection with the endpoint. In dual stack > networks, one of the main concerns of an operator is the correct > address space and routing management. The operator must maintain > address spaces for both protocols. Public IPv4 addresses are often > a scarce resource for the operator and typically it is not = possible > for a UE to have a globally unique IPv4 address (continuously) > allocated for its use. Use of private IPv4 addresses means use of > NATs when communicating with a peer node outside the operator's > network. In large networks, NAT systems can become very complex, > expensive and difficult to maintain. >=20 > =3D=3D> I don't see a direct relation of this paragraph to the = recommendations > in this document: the first part describes (incorrectly) how to get = the > address of the peer; the second part describes dual-stack = considerations; > the last part describes IPv4 NAT's. I suggest removing it. The one = thing > that may make to preserve in some form is that the 3GPP operators = typically > use the private IPv4 addresses. >=20 > JW: Yep, rewording and text removal looks necessary. The first part > can be removed, but I would like to retain some description on > private address spaces and NAT. That should be described in our > document (at least as a motivation to start to use IPv6). Agreed, that should be good background material. JW: Yup, I will leave some "NAT problem" text. > semi-editorial > -------------- >=20 > can typically access both IPv4 and IPv6 services without = additional > translators in the network. However, it is good to remember that > public IPv4 addresses are a scarce resource and in many cases IPv4 > NATs are deployed. Public/global IP addresses are also needed for > peer-to-peer services: the node needs a public/global IP address >=20 > =3D=3D> s/a scarce resource/hard to come by/ > (they aren't really scarce as such, but it takes just a huge amount of > paperwork etc. to get them..) >=20 > JW: No problems with that kind of wording, but I still would like to > keep "scarce resource" term there. If you think about the growth > rate of mobile phones, it is an impossible task to get a public IPv4 > address for all of them. If not today, after some time it certainly > will be impossible... I'm OK with both, even though I prefer "hard to come by" or something=20 like that. There are still over a billion addresses left, so they=20 aren't really that _scarce_ :-). The registries keep saying that there is no shortage of address space. =20 I'd actually *like* to have a mobile operator request public v4 space for all of its devices instead of doing NAT. :-) JW: Right.. It is more related to the allocation policy today, but will = become even bigger problem in the future. Anyway, the fact is that = private IPv4 addresses are used in most (at least European) GPRS nws. = But no problems, I can use "hard to come by". Next steps with 3GPP Analysis: because other tasks have kept me very = busy during last couple of weeks, I will make revision -08 in January (I = try to do that by mid-January). There are still some comments that I = need to go through and reply to on the mailing list. Merry x'mas! -Juha- From owner-v6ops@ops.ietf.org Sun Dec 21 14:59:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02728 for ; Sun, 21 Dec 2003 14:59:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AY9dH-0002Ul-VB for v6ops-data@psg.com; Sun, 21 Dec 2003 19:52:55 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AY9cw-0002TM-HR for v6ops@ops.ietf.org; Sun, 21 Dec 2003 19:52:34 +0000 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBLJqW013787 for ; Sun, 21 Dec 2003 21:52:33 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 21 Dec 2003 21:52:32 +0200 Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 21 Dec 2003 21:52:31 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: v6ops: Thank you for this year and new energy for the next! Date: Sun, 21 Dec 2003 21:52:32 +0200 Message-ID: <2D3EB51EAED985419D54AB340A9D0195B15CC6@esebe024.ntc.nokia.com> Thread-Topic: v6ops: Thank you for this year and new energy for the next! Thread-Index: AcPGUSQAtSpP1uz+Rb+i1rFCd2VoOQ== From: To: Cc: , , X-OriginalArrivalTime: 21 Dec 2003 19:52:31.0648 (UTC) FILETIME=[F881CA00:01C3C7FB] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello v6ops, the year is coming to an end and it is time to check on the results of = the year, and look at the situation for the coming new year. We = understand that the year has been long and the progress seems slow. = Looking at the actual results of this year, it is true: The progress on = the scenarios/analysis documents has been slower than anticipated, but = we are really getting somewhere: 1) 3GPP scenarios were approved during this year, and the analysis = document is about done. We hope that the Juha would have still the = stamina to publish the new version of the I-D so we can get it to the = IESG. Juha can you get it out by mid-January? 2) Unmanaged networks scenarios are waiting already in the RFC Editor's = queue and the analysis document can be last called as soon as they are = published. Hopefully, Christian has not lost all his hope and still = helps us finish this. 3) Enterprise scenarios doc is a WG ID. This was a big milestone for the = extremely difficult task.=20 4) Combined ISP scenarios/analysis is also a WG document now!=20 5) The IPv4 survey documents are finally at the IESG! Thank you for the = great effort to everybody who contributed to the work! 6) The basic transition mechanism is almost done thanks to the efforts = of Erik. Probably we can get it forward as soon as the next version is = published 7) We have been expanding to new areas in IPv6 operations and are = starting really some operational work. There are quite many new items as = WG IDs and we are getting some results on this area! So, for the new year, and new work. As the 3GPP and unmanaged network = analysis work is getting stable it is only logical that next year we = will be focusing on the solutions for these areas. This means that we = would officially like to see some discussion on the solutions of this = work and get some protocol proposals to fill in the gaps that the = documents identify. In addition, we hope that we can get the enterprise = and the ISP work to the same point as soon as possible. Thank you everybody for the hard work in 2003 and we hope that you have = still some energy left for 2004 to do the new work as well! v6ops chairs & the AD, Bob, Jonne, Pekka & Bert --------------------- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com=20 From owner-v6ops@ops.ietf.org Mon Dec 22 09:46:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18544 for ; Mon, 22 Dec 2003 09:46:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AYRCl-0004Gd-N1 for v6ops-data@psg.com; Mon, 22 Dec 2003 14:38:43 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AYQeg-0000Lx-6c for v6ops@ops.ietf.org; Mon, 22 Dec 2003 14:03:30 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hBM7lZ031094; Mon, 22 Dec 2003 09:47:35 +0200 Date: Mon, 22 Dec 2003 09:47:35 +0200 (EET) From: Pekka Savola To: juha.wiljakka@nokia.com cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-07: (semi-)editorial issues In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834F020CE0FB@esebe005.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,DATE_IN_PAST_06_12 autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Inline to one remaining bigger issue.. On Fri, 19 Dec 2003 juha.wiljakka@nokia.com wrote: > > Only thing that somehow worries me is activating PDP contexts that > > may not be needed, i.e. extra usage of network resources. Should we > > add some note on that, e.g. draft-elmalki-sipping... states that > > I note that there are two cases here: > 1) if you desire to operate the node as much in v6-only mode as > possible (not opening v4 PDP context unless you have to), or > 2) if you desire to operate the node as much in v4-only mode as > possible (not opening v6 PDP contexts unless you intend to use apps > which use v6). > > Which problem (or both?) are you worried of at this point? > > JW: In my opinion, this sentence can be problematic: "it may also > make sense to open both PDP contexts in advance, before they are > used, because the activation of a context may take a relatively long > time." It can lead to a situation in which we have activated > hundreds of thousands extra, unused PDP contexts in the network and > this is not good from network resource usage point of view. PDP > context usage is quite much defined by used applications and I think > we shouldn't write "open both types of PDP contexts in advance" > recommendation. My recommendation is to leave the PDP context > activation policy decided by the implementers / application > developers. I think the wording above, "may also make sense", seems informative enough, not forcing the operators/vendors behave like suggested if they have good reasons. But that aside, I think it may make sense to discuss one assumption different people seem to be making in a different fashion. When you say "used applications", what are you referring to? The whole IMS subsystem, some IP applications installed on a node (SSH client, web browser, ftp client, peer-to-peer application, etc.)? These bring on two points which have been raised in the past: PDP context activation takes time (maybe like 5 seconds or so, at least?), so activating it when trying to contact a peer could lead to long waiting and unsatisfied users. Similarly, with some applications, it is not known in advance which kind of peer nodes it will connect to (e.g., the client apps above). IMS subsystem is an exception here: you always know it's v6-only. Maybe you have that in mind? So, if the UEs include (or could include) apps like SSH/telnet clients, web browsers, etc. (especially if those are not proxied by the 3GPP operator), it might make sense to open PDP contexts in advance (or at the latest when the application is started). Some of this justification should probably go in the document in some form. > Ok, then maybe reword to something like ? : > > IPv6 PDP contexts > should be used even if that meant IPv6-in-IPv4 tunneling would be > needed in the network (see section 3.2 for more details). Note > that this is transparent to the UE. > > JW: Looks quite ok. Maybe changing used -> preferred. Fine with me. > Next steps with 3GPP Analysis: because other tasks have kept me very > busy during last couple of weeks, I will make revision -08 in > January (I try to do that by mid-January). There are still some > comments that I need to go through and reply to on the mailing list. Thanks a lot Juha for the work! -- 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 Dec 22 15:37:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06658 for ; Mon, 22 Dec 2003 15:37:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AYWkO-000OIE-MC for v6ops-data@psg.com; Mon, 22 Dec 2003 20:33:48 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AYWk2-000OEt-VS for v6ops@ops.ietf.org; Mon, 22 Dec 2003 20:33:27 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06260; Mon, 22 Dec 2003 15:33:24 -0500 (EST) Message-Id: <200312222033.PAA06260@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-sec-04.txt Date: Mon, 22 Dec 2003 15:33:24 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 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 : Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Author(s) : P. Nesser II, A. Bergstrom Filename : draft-ietf-v6ops-ipv4survey-sec-04.txt Pages : 0 Date : 2003-12-22 This document seeks to document all usage of IPv4 addresses in currently deployed IETF Security Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Sandards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-sec-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ipv4survey-sec-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-sec-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-22143520.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-sec-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-sec-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-22143520.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Mon Dec 22 15:37:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06717 for ; Mon, 22 Dec 2003 15:37:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AYWjy-000OE5-Rk for v6ops-data@psg.com; Mon, 22 Dec 2003 20:33:22 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AYWjm-000OC2-GX for v6ops@ops.ietf.org; Mon, 22 Dec 2003 20:33:10 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06197; Mon, 22 Dec 2003 15:33:07 -0500 (EST) Message-Id: <200312222033.PAA06197@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-intro-06.txt Date: Mon, 22 Dec 2003 15:33:07 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 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 : Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Author(s) : P. Nesser II, A. Bergstrom Filename : draft-ietf-v6ops-ipv4survey-intro-06.txt Pages : 0 Date : 2003-12-22 This document is a general overview and introduction to the v6ops IETF workgroup project of documenting all usage of IPv4 addresses in currently deployed IETF documented standards. It is broken into seven documents conforming to the current IETF areas. It also describes the methodology used during documentation, which type of RFCs that has been documented, and a concatenated summary of results. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-intro-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ipv4survey-intro-06.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-ipv4survey-intro-06.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: <2003-12-22143444.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-intro-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-intro-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-22143444.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Mon Dec 22 15:38:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06832 for ; Mon, 22 Dec 2003 15:38:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AYWkD-000OGs-DW for v6ops-data@psg.com; Mon, 22 Dec 2003 20:33:37 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AYWjr-000OD0-Qa for v6ops@ops.ietf.org; Mon, 22 Dec 2003 20:33:15 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06223; Mon, 22 Dec 2003 15:33:12 -0500 (EST) Message-Id: <200312222033.PAA06223@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-apps-04.txt Date: Mon, 22 Dec 2003 15:33:12 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 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 : Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Author(s) : P. Nesser II Filename : draft-ietf-v6ops-ipv4survey-apps-04.txt Pages : 55 Date : 2003-12-22 The transition from an all IPv4 network to an all IPv6 network requires several interim steps, being one of them the evolution of current IPv4 dependent specifications to a format independent of the type of IP addressing schema used. Hence, it is hoped that specifications will be re-designed and re-implemented to become network address independent, or at least to dually support IPv4 and IPv6. To achieve that step, it is necessary to survey and document all IPv4 dependencies experienced by current standards - Full, Draft, and Proposed - and Experimental RFCs. Hence, this document describes IPv4 addressing dependencies that deployed IETF Application Area documented Standards may experience. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-apps-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ipv4survey-apps-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-apps-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-22143453.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-apps-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-apps-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-22143453.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Mon Dec 22 15:38:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06973 for ; Mon, 22 Dec 2003 15:38:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AYWkf-000OJs-8k for v6ops-data@psg.com; Mon, 22 Dec 2003 20:34:05 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AYWjw-000ODb-M0 for v6ops@ops.ietf.org; Mon, 22 Dec 2003 20:33:20 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06245; Mon, 22 Dec 2003 15:33:17 -0500 (EST) Message-Id: <200312222033.PAA06245@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-ops-05.txt Date: Mon, 22 Dec 2003 15:33:17 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 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 : Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Author(s) : P. Nesser II, A. Bergstrom Filename : draft-ietf-v6ops-ipv4survey-ops-05.txt Pages : 0 Date : 2003-12-22 This document seeks to document all usage of IPv4 addresses in currently deployed IETF Operations & Management Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-ops-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ipv4survey-ops-05.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-ipv4survey-ops-05.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: <2003-12-22143506.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-ops-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-ops-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-22143506.I-D@ietf.org> --OtherAccess-- --NextPart--