- ipv6-wg - mailman.ripe.net

Fw: MLDv3 - Internet Draft
by Thomas Trede 09 Nov '00

09 Nov '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Vida Rolland" <Rolland.Vida(a)lip6.fr> To: <ipng(a)sunroof.eng.sun.com>; <ssm-interest(a)external.cisco.com>; "Supratik Bhattacharyya" <supratik(a)sprintlabs.com> Sent: Wednesday, November 08, 2000 6:30 PM Subject: MLDv3 - Internet Draft > Dear All, > > The revised IPng Working Group Charter published on the 5th of October > on the mailing list of the IPng WG contained a call for contribution on > "Extending MLD to include functionality of IGMPv3". > > Here is the abstract of an Internet Draft proposal, called "Multicast > Listener Discovery Version 3 (MLDv3) for IPv6" > (<draft-vida-mld-v3-00.txt>) > > ************* > Abstract: > > This document specifies Version 3 of the Multicast Listener Discovery > protocol, MLDv3. MLD is the protocol used by an IPv6 router to > discover the presence of multicast listeners (that is, nodes wishing > to receive multicast packets) on its directly attached links, and to > discover specifically which multicast addresses are of interest to > those neighboring nodes. > > MLDv3 is derived from version 3 of IPv4's Internet Group Management > Protocol, IGMPv3. Compared to the previous version, MLDv3 adds > support for "source filtering", that is, the ability for a node to > report interest in listening to packets *only* from specific source > addresses, or from *all but* specific source addresses, sent to a > particular multicast address. That information may be used by > multicast routing protocols to avoid delivering multicast packets > from specific sources to links where there are no interested > listeners. When compared to IGMPv3, one important difference > to note is that MLDv3 uses ICMPv6 (IP Protocol 58) message > types, rather than IGMP (IP Protocol 2) message types. > > ************ > > The full text of the draft can be found at: > http://www-rp.lip6.fr/~vida/draft-vida-mld-v3-00.txt > > We welcome any comments or suggestions on the text. > > Best regards, > > Rolland Vida, > LIP6, Paris, France. > > ----------------------------------------------------------------------- > "Not everything that can be counted counts, and not everything that > counts can be counted. " - Albert Einstein > Rolland Vida > Universite Paris VI "Pierre et Marie Curie" tel: +33 (0)144 277 126 > Laboratoire LIP6 - CNRS, C669 fax: +33 (0)144 277 495 > 8, Rue de Capitaine Scott, 75015, Paris mailto:vida@rp.lip6.fr > ----------------------------------------------------------------------- > > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo(a)sunroof.eng.sun.com > -------------------------------------------------------------------- >

1 0

Fw: I-D ACTION:draft-ietf-ipngwg-rfc2292bis-02.txt
by Thomas Trede 08 Nov '00

08 Nov '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: <Internet-Drafts(a)ietf.org> To: <IETF-Announce: ;> Cc: <ipng(a)sunroof.eng.sun.com> Sent: Wednesday, November 08, 2000 11:59 AM Subject: I-D ACTION:draft-ietf-ipngwg-rfc2292bis-02.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPNG Working Group of the IETF. > > Title : Advanced Sockets API for IPv6 > Author(s) : R. Stevens, M. Thomas, E. Nordmark > Filename : draft-ietf-ipngwg-rfc2292bis-02.txt > Pages : 74 > Date : 07-Nov-00 > > A separate specification [RFC-2553] contain changes to the sockets > API to support IP version 6. Those changes are for TCP and UDP-based > applications and will support most end-user applications in use > today: Telnet and FTP clients and servers, HTTP clients and servers, > and the like. > But another class of applications exists that will also be run under > IPv6. We call these 'advanced' applications and today this includes > programs such as Ping, Traceroute, routing daemons, multicast routing > daemons, router discovery daemons, and the like. The API feature > typically used by these programs that make them 'advanced' is a raw > socket to access ICMPv4, IGMPv4, or IPv4, along with some knowledge > of the packet header formats used by these protocols. To provide > portability for applications that use raw sockets under IPv6, some > standardization is needed for the advanced API features. > There are other features of IPv6 that some applications will need to > access: interface identification (specifying the outgoing interface > and determining the incoming interface) and IPv6 extension headers > that are not addressed in [RFC-2553]: The Routing header (source > routing), Hop-by-Hop options, and Destination options. This document > provides API access to these features too. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2292bis-02.txt > > 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-ipngwg-rfc2292bis-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv(a)ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ipngwg-rfc2292bis-02.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. >

1 0

Fw: Protocol Action: IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol to Proposed Standard
by Thomas Trede 28 Oct '00

28 Oct '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "The IESG" <iesg-secretary(a)ietf.org> To: <IETF-Announce: ;> Cc: "RFC Editor" <rfc-editor(a)isi.edu>; "IANA" <iana(a)iana.org>; "Internet Architecture Board" <iab(a)isi.edu>; <ipng(a)sunroof.eng.sun.com> Sent: Friday, October 27, 2000 6:55 PM Subject: Protocol Action: IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol to Proposed Standard > > > The IESG has approved the Internet-Draft 'IP Version 6 Management > Information Base for the Multicast Listener Discovery Protocol' > <draft-ietf-ipngwg-mld-mib-05.txt> as a Proposed Standard. This > document is the product of the IPNG Working Group. The IESG contact > persons are Erik Nordmark and Thomas Narten. > > > > > Technical Summary > > This document defines a portion of the Management Information Base > (MIB) for use with network management protocols in Internet Protocol > Version 6 internets. Specifically, this document is the MIB module > that defines managed objects for implementations of the Multicast > Listener Discovery Protocol (RFC2710). > > Working Group Summary > > There was consensus within the WG for this document, and no issues > were raised during IETF Last Call. > > Protocol Quality > > This protocol has been reviewed for the IESG by Juergen Schoenwaelder > and Thomas Narten. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo(a)sunroof.eng.sun.com > -------------------------------------------------------------------- >

1 0

Fw: I-D ACTION:draft-ietf-ipngwg-mld-mib-05.txt
by Thomas Trede 27 Oct '00

27 Oct '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: <Internet-Drafts(a)ietf.org> To: <IETF-Announce: ;> Cc: <ipng(a)sunroof.eng.sun.com> Sent: Friday, October 27, 2000 12:38 PM Subject: I-D ACTION:draft-ietf-ipngwg-mld-mib-05.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPNG Working Group of the IETF. > > Title : IP Version 6 Management Information Base for the > Multicast Listener Discovery Protocol > Author(s) : B. Haberman, R. Worzella > Filename : draft-ietf-ipngwg-mld-mib-05.txt > Pages : 14 > Date : 26-Oct-00 > > This document defines a portion of the Management Information Base > (MIB) for use with network management protocols in Internet Protocol > Version 6 internets. Specifically, this document is the MIB module > that defines managed objects for implementations of the Multicast > Listener Discovery Protocol [RFC2710]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-mld-mib-05.txt > > 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-ipngwg-mld-mib-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(a)ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ipngwg-mld-mib-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. >

1 0

Fw: I-D ACTION:draft-ietf-ipngwg-rfc2553bis-01.txt
by Thomas Trede 27 Oct '00

27 Oct '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: <Internet-Drafts(a)ietf.org> To: <IETF-Announce: ;> Cc: <ipng(a)sunroof.eng.sun.com> Sent: Friday, October 27, 2000 12:38 PM Subject: I-D ACTION:draft-ietf-ipngwg-rfc2553bis-01.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPNG Working Group of the IETF. > > Title : Basic Socket Interface Extensions for IPv6 > Author(s) : R. Gilligan, S. Thomson, J. Bound, W. Stevens > Filename : draft-ietf-ipngwg-rfc2553bis-01.txt > Pages : 31 > Date : 26-Oct-00 > > The de facto standard application program interface (API) for TCP/IP > applications is the 'sockets' interface. Although this API was > developed for Unix in the early 1980s it has also been implemented on a > wide variety of non-Unix systems. TCP/IP applications written using the > sockets API have in the past enjoyed a high degree of portability and we > would like the same portability with IPv6 applications. But changes are > required to the sockets API to support IPv6 and this memo describes > these changes. These include a new socket address structure to carry > IPv6 addresses, new address conversion functions, and some new socket > options. These extensions are designed to provide access to the basic > IPv6 features required by TCP and UDP applications, including > multicasting, while introducing a minimum of change into the system and > providing complete compatibility for existing IPv4 applications. > Additional extensions for advanced IPv6 features (raw sockets and access > to the IPv6 extension headers) are defined in another document [4]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2553bis-01.txt > > 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-ipngwg-rfc2553bis-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv(a)ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ipngwg-rfc2553bis-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >

1 0

Fw: SVRLOC WG last call: draft-ietf-svrloc-ipv6-11.txt
by Thomas Trede 18 Oct '00

18 Oct '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Erik Guttman" <Erik.Guttman(a)germany.sun.com> To: <srvloc(a)srvloc.org>; <ipng(a)sunroof.eng.sun.com> Cc: <erik.guttman(a)germany.sun.com>; "Thomas Narten" <narten(a)raleigh.ibm.com>; "Erik Nordmark" <Erik.Nordmark(a)eng.sun.com> Sent: Wednesday, October 18, 2000 10:06 AM Subject: SVRLOC WG last call: draft-ietf-svrloc-ipv6-11.txt > > The internet-draft "Service Location Protocol Modifications for IPv6" > is entering WG last call again. Comments from the preceding WG last > call gave rise to comments which required modifying the document. > > Please send comments to the srvloc(a)srvloc.org mailing list. This > document concerns the IPNG WG so the last call is being announced > on the IPNG mailing list. > > The last call period will end Nov 1, 2000. > > This document will be submitted to the IESG for consideration, to > be advanced as a proposed standard RFC. > > Erik Guttman > SVRLOC WG chair > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo(a)sunroof.eng.sun.com > -------------------------------------------------------------------- >

1 0

TLA...sub-TLA....etc...
by Okan Cimen 18 Oct '00

18 Oct '00

Hello, I started working on IPv6 and some points arent clear. I hope I can get a satisfying answer from you. My firm is currently a LIR but when we want to implement IPv6, shall we become a TLA or sub-TLA? What is the difference between these two? As far as I read, LIRs will be sub-TLA's... Am I wrong? Is there a document explaning these procedures? Best regards Okan

1 0

Fw: I-D ACTION:draft-ietf-ipngwg-addr-arch-v3-02.txt
by Thomas Trede 07 Oct '00

07 Oct '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: <Internet-Drafts(a)ietf.org> To: <IETF-Announce: ;> Cc: <ipng(a)sunroof.eng.sun.com> Sent: Friday, October 06, 2000 12:30 PM Subject: I-D ACTION:draft-ietf-ipngwg-addr-arch-v3-02.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPNG Working Group of the IETF. > > Title : IP Version 6 Addressing Architecture > Author(s) : B. Hinden, S. Deering > Filename : draft-ietf-ipngwg-addr-arch-v3-02.txt > Pages : 25 > Date : 05-Oct-00 > > This specification defines the addressing architecture of the IP > Version 6 protocol [IPV6]. The document includes the IPv6 addressing > model, text representations of IPv6 addresses, definition of IPv6 > unicast addresses, anycast addresses, and multicast addresses, and an > IPv6 node's required addresses. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-02.txt > > 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-ipngwg-addr-arch-v3-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv(a)ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v3-02.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. >

1 0

Fw: Request to Advance "IP Version 6 Addressing Architecture"
by Thomas Trede 07 Oct '00

07 Oct '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Bob Hinden" <hinden(a)iprg.nokia.com> To: <Erik.Nordmark(a)eng.sun.com>; <narten(a)raleigh.ibm.com> Cc: <scoya(a)ietf.org>; <deering(a)cisco.com>; <ipng(a)sunroof.eng.sun.com> Sent: Friday, October 06, 2000 10:57 PM Subject: Request to Advance "IP Version 6 Addressing Architecture" > Erik, Thomas, > > The chairs of the IP Next Generation working group, on behalf of the > working group, request that the following document be published as an Draft > Standard: > > Title : IP Version 6 Addressing Architecture > Author(s) : B. Hinden, S. Deering > Filename : draft-ietf-ipngwg-addr-arch-v3-02.txt > Pages : 25 > Date : 05-Oct-00 > > A working group last call for this document was completed on April 10, 2000 > and the document was discussed at the Adelaide IETF meeting. The -02 > version of the draft resolves issues raised during the working group last > call and subsequent discussion. > > This document will obsolete RFC2373. Changes from RFC2373 are listed in > Appendix B. > > Bob Hinden / Steve Deering > IPng Working Group Co-Chairs > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo(a)sunroof.eng.sun.com > -------------------------------------------------------------------- >

1 0

Fw: Revised IPng Working Group Charter
by Thomas Trede 05 Oct '00

05 Oct '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Bob Hinden" <hinden(a)iprg.nokia.com> To: "Thomas Narten" <narten(a)raleigh.ibm.com>; <Erik.Nordmark(a)eng.sun.com> Cc: <ipng(a)sunroof.eng.sun.com>; <scoya(a)ietf.org> Sent: Thursday, October 05, 2000 6:19 PM Subject: Revised IPng Working Group Charter > Thomas, Erik, > > Attached is the revised charter for the IPng working group. Updating the > charter was agreed to at the Grenoble and Minneapolis working group > meetings. This version has been discussed on the ipng mailing list and at > the Adelaide IETF meeting. > > The charter includes changing the name of the working group to the "IP > Version 6 Working Group", but will keep the acronym of "ipngwg". This will > avoid having to rename all current internet drafts. > > Bob Hinden / Steve Deering > > -------------------------------------------------------------------------- --- > > IP Version 6 Working Group (ipngwg) *** note: change of name but not acronym > > Chair(s): > > Bob Hinden <hinden(a)iprg.nokia.com> > Steve Deering <deering(a)cisco.com> > > Document Editor > > Bob Hinden (hinden(a)iprg.nokia.com) > > Internet Area Director(s): > > Thomas Narten <narten(a)raleigh.ibm.com> > Erik Nordmark <nordmark(a)eng.sun.com> > > Internet Area Advisor: > > Thomas Narten <narten(a)raleigh.ibm.com> > > Mailing Lists: > > General Discussion:ipng@sunroof.eng.sun.com > To Subscribe: majordomo(a)sunroof.eng.sun.com > In Body: in body: subscribe ipng > Archive: ftp://playground.sun.com/pub/ipng/mail-archive > > Description of Working Group: > > IP version 6 or IPv6 (also formerly known as IP Next Generation or IPng) > is intended to support the continued growth of the Internet, both in > size and capabilities, by offering a greatly increased IP address space > and other enhancements over IPv4. The working group was originally > chartered to implement the recommendations of the IPng Area Directors > as outlined at the July 1994 IETF meeting and in "The Recommendation > for the IP Next Generation Protocol," RFC1752, January 1995. Most of > the tasks in that original charter have been completed, and the core > IPv6 protocol specifications are now on the IETF standards track. > The working group's ongoing responsibilities are as follows: > > - Complete work from the original charter and follow-on work, as > outlined below. > > - Keep all IPv6 working group documents moving along publication / > standardization track. > > - Serve as a review board and body of competence and coordination for > IPv6 architectural issues that span multiple IETF working groups. > > - Provide a home for IPv6-related work that doesn't fit in an existing > IETF working group and doesn't merit a working group of its own. > > - Provide technical input to ICANN, Internet Address Registries, and > IANA with regard to IPv6 address allocation policies and procedures. > > - Provide technical input and review to IANA with regard to IPv6 > protocol and parameter assignments. > > The list of the working group's current work items is as follows: > > - Revise ICMPv6 spec (scope-exceeded err, no error to redirect, > editorial) > - Revise Generic Tunneling spec (add bidirectional tunnels) > - Update Basic and Advanced API specs > - Complete Scoped Address Architecture spec and any necessary revisions > to other working group drafts required to properly implement support > for IPv6 address scoping > - Complete work on recommended address-selection algorithms > - Work on new solutions to site-multihoming problems, possibly including > both host-based and router-based solutions. > - Complete work on local IPv6 networking as part of IPv6 plug-and-play > - Complete work on privacy extensions to stateless address configuration > - Document IPv6 renumbering model > - Complete the GSE Analysis document > - Complete the Inverse Neighbor Discovery spec > - Complete the IPv6 Node Information Queries spec > - Complete MIB specs as required by any working group protocol specs > > New work items not listed above require the approval of the working > group and Internet Area directors before they will be taken on by the > working group. > > The working group would welcome contributions on the following topics > (this is not an exhaustive list): > > - Flow label standardization > - Solutions to other multihoming issues, beyond those specific to > site-multihoming > - Integration of autoconfiguration, mobility, DNS, service discovery > and other technologies to enhance IPv6 plug-and-play > - IPv6 dial-up issues relating to address assignment, use of Neighbor > Discovery, etc. (not including AAA work) > - Specifications for IPv6 over additional media > - Extending MLD to include functionality of IGMPv3 > - Host use of anycast; TCP use of anycast > - Support for multi-link subnets (single subnet spans multiple links) > - Scope-name discovery > - IPv6 protocol extensions to accommodate mobile wireless networks. > > Goals and Milestones: > > Aug 2000 Complete MLD MIB and submit for Proposed Standard > > Sep 2000 Complete privacy extensions specification and submit for > Proposed Standard > > Nov 2000 Completed revision of GSE Analysis document and resubmit > for Informational > > Sep 2000 Complete the Inverse Neighbor Discovery specification > and submit for Proposed Standard > > Sep 2000 Complete IPv6 Multihoming with Route Aggregation and submit > for Informational. > > Dec 2000 Update ICMP document and resubmit for Draft Standard > > Dec 2000 Update Generic Tunneling specification and resubmit for > Proposed Standard > > Nov 2000 Complete updates to Basic and Advanced API specifications > and submit for Informational > > Dec 2000 Complete Scoped Address Architecture and submit for Proposed > Standard > > Dec 2000 Compete Address Selection specification and submit for Proposed > Standard > > Dec 2000 Complete Local IPv6 Networking Specification and submit for > Proposed Standard > > Dec 2000 Complete the IPv6 Node Information Queries specification > and submit for Proposed Standard > > Mar 2001 Complete IPv6 renumbering model document and submit for > Informational > > -------------------------------------------------------------------------- --- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo(a)sunroof.eng.sun.com > -------------------------------------------------------------------- >

1 0