- ipv6-wg - mailman.ripe.net

Fw: I-D ACTION:draft-ietf-ipngwg-dns-lookups-08.txt
by Thomas Trede 18 May '00

18 May '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: <Internet-Drafts(a)ietf.org> To: <IETF-Announce: ;> Cc: <ipng(a)sunroof.eng.sun.com> Sent: Thursday, May 18, 2000 12:54 PM Subject: I-D ACTION:draft-ietf-ipngwg-dns-lookups-08.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 : DNS Extensions to Support IPv6 Address Aggregation and > Renumbering > Author(s) : M. Crawford, . Huitema, S. Thomson > Filename : draft-ietf-ipngwg-dns-lookups-08.txt > Pages : 20 > Date : 17-May-00 > > This document defines changes to the Domain Name System to support > renumberable and aggregatable IPv6 addressing. The changes include > a new resource record type to store an IPv6 address in a manner > which expedites network renumbering and updated definitions of > existing query types that return Internet addresses as part of > additional section processing. > > For lookups keyed on IPv6 addresses (often called reverse lookups), > this document defines a new zone structure which allows a zone to be > used without modification for parallel copies of an address space > (as for a multihomed provider or site) and across network > renumbering events. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-dns-lookups-08.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-dns-lookups-08.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-dns-lookups-08.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-00.txt
by Thomas Trede 12 May '00

12 May '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, May 12, 2000 4:56 PM Subject: I-D ACTION:draft-ietf-ipngwg-rfc2553bis-00.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-00.txt > Pages : 34 > Date : 11-May-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-00.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-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(a)ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ipngwg-rfc2553bis-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. >

1 0

final agenda for IPv6 working group RIPE36
by David Kessens 12 May '00

12 May '00

Hi, Below follows the final version of the IPv6 wg agenda. Please let me know if you have any other topics that you want to have discussed or if you have other comments. Despite being the final version of the agenda, we still have the freedom to add more topics during the agenda bashing. I am still looking for volunteers to cover some of the topics as proposed in the agenda. Please let me know if you are willing to take care of one of these. I have asked for a one hour time slot this time since we are already providing an IPv6 tutorial on tuesday (see RIPE NCC website for details). In addition, Bill Manning will give a presentation on DNS and IPv6 to the dns working group. In order to allow you to attend this presentation, I have asked the meeting organization to make sure that the DNS working group session and IPv6 working group session will not fall into the same time slot. At this point I still haven't heard whether the registries will be ready before the meeting with the draft revision of the IPv6 allocation guidelines. I will try to get more time allocated to us and the local ir working group in case they are able to get the draft out just before the meeting. Thanks and see you at the meeting, David K. --- Agenda for the IPv6 Working Group Meeting RIPE36, May 2000, Budapest A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Status of 6bone (David Kessens) C. News from the IPv6 forum (Juergen Rauschenbach) D. Summary of the Birmingham IPv6 event (Stuart Prevost) E. European developments/initiatives regarding IPv6 (input from the audience) F. Reports on on-going projects, success & failures stories on IPv6 (I am looking for volunteers who are willing to share their experiences) G. Future plans for the working group (input from the audience) tutorials, topics for next meeting, call for volunteers Z. AOB ---

1 0

draft agenda (v1) for IPv6 working group RIPE36
by David Kessens 01 May '00

01 May '00

Hi, Below follows the first draft of the IPv6 wg agenda. Please let me know if you have any other topics that you want to have discussed or if you have other comments on this first draft of the agenda. I am still looking for volunteers to cover some of the topics as proposed in the agenda. Please let me know if you are willing to take care of one of these. I have asked for a one hour time slot this time since we are already providing an IPv6 tutorial on tuesday (see RIPE NCC website for details). In addition, Bill Manning will give a presentation on DNS and IPv6 to the dns working group. In order to allow you attend this presentation, I have asked the meeting organization to make sure that the DNS working group session and IPv6 working group session will not fall into the same time slot. At this point it is still unclear whether the registries will be ready before the meeting with the draft revision of the IPv6 allocation guidelines. I will try to get more time allocated to us and the local ir working group in case they are able to get the draft out in time. Thanks, David K. --- Proposed Agenda (draft v1) for the IPv6 Working Group Meeting RIPE36, May 2000, Budapest A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Status of 6bone (David Kessens) C. News from the IPv6 forum and meeting in Telluride (Juergen Rauschenbach/Thomas Trede ?!?) D. European developments/initiatives regarding IPv6 (input from the audience) E. Reports on on-going projects, success & failures stories on IPv6 (I am looking for volunteers who are willing to share their experiences) Z. AOB ---

1 0

Fw: New version of "Mobility Support in IPv6" draft
by Thomas Trede 28 Apr '00

28 Apr '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Dave Johnson" <dbj(a)cs.cmu.edu> To: <mobile-ip(a)standards.nortelnetworks.com>; <ipng(a)sunroof.eng.sun.com> Sent: Thursday, April 27, 2000 8:57 PM Subject: New version of "Mobility Support in IPv6" draft > I just submitted a revised version of the Internet-Draft "Mobility > Support in IPv6", which corrects a number of minor problems and adds > several clarifications over the previous version of the draft. Here > is a list of some of the changes since the previous version: > > - Moved the definition of IPsec requirements for Binding Updates > and Binding Acknowledgements to Section 4.4), giving this > important information its own specific section with a section > title (IPsec Requirements for Mobile IPv6 Destination Options) > that will be identifiable in the table of contents for this > document. This makes these requirements harder to miss than > where they were defined in Sections 5.1 and 5.2, mixed in with > the definition of the format of these destination options. > > - In Section 4.6, added a precise definition of Sequence Number > value comparison modulo 2**16. Also added a reference to this > definition in each other place where Sequence Number comparison > is discussed. > > - Added a statement in Section 9.5 to clarify the sending of a > Neighbor Advertisement message by the home agent on behalf of the > mobile node in order to intercept packets addressed to the mobile > node. Except for the specific fields defined there, all fields > in each such Neighbor Advertisement SHOULD be set in the same > way they would be set by the mobile node itself if sending this > Neighbor Advertisement while at home [17]. > > - In Section 10.6, specified that the Lifetime in the Binding > Update sent by a mobile node to its home agent SHOULD be less > than or equal to the remaining lifetime of the home address and > the care-of address specified for the binding. > > - In Section 10.8, modified the specification that was there > about the correct setting of the Lifetime in the Binding > Update sent by a mobile node to a correspondent node. The > original specification stated that the Lifetime value MUST be no > greater than the remaining lifetime of the mobile node's home > registration of its primary care-of address at its home agent. > However, there should be no necessary relationship between the > remaining lifetime of a home registration and the lifetime of > a binding at a correspondent node. Instead, as with the home > registration Binding Update, the Lifetime in the Binding Update > sent by a mobile node to a correspondent node SHOULD be less than > or equal to the remaining lifetime of the home address and the > care-of address specified for the binding. > > - In Section 5.4, added a statement that a packet MUST NOT contain > more than one Home Address option, except that an encapsulated > packet [4] MAY contain a separate Home Address option associated > with each encapsulating IP header. > > - In Section 4.6, added a new field in the Binding Update List > entry format to record the initial value of the Lifetime field > sent in that Binding Update. > > - In Section 10.12, defined a new step in processing a received > Binding Acknowledgement: if the value specified in the Lifetime > field in the Binding Acknowledgement is less than the Lifetime > value sent in the Binding Update being acknowledged, then the > mobile node MUST subtract the difference between these two > Lifetime values from the remaining lifetime for the binding > as maintained in the corresponding Binding Update List entry. > The effect of this step is to correctly manage the mobile > node's view of the binding's remaining lifetime (as maintained > in the corresponding Binding Update List entry) so that it > correctly counts down from the Lifetime value given in the > Binding Acknowledgement, but with the timer countdown beginning > at the time that the Binding Update was sent. This change also > affected Section 10.8 in sending Binding Updates, to record both > the original lifetime and the remaining lifetime in the Binding > Update List. > > - In Sections 5.1 and 9.3, clarified that the Duplicate Address > Detection performed by the home agent if the Duplicate Address > Detection (D) bit is set in the Binding Update, is performed > before returning the Binding Acknowledgement for that Binding > Update. > > - In Section 5.1, clarified that the mobile node SHOULD set the > Duplicate Address Detection (D) bit in its home registration > Binding Updates based on any requirements for Duplicate Address > Detection that would apply to the mobile node if it were at > home [17, 27]. > > - In Section 9.3, specified that a home agent, when performing > Duplicate Address Detection for a mobile node when the > Duplicate Address Detection (D) bit is set in a received > Binding Update, SHOULD NOT delay sending the initial Neighbor > Solicitation message of Duplicate Address Detection by the random > delay specified for normal processing of Duplicate Address > Detection [17, 27]. > > - In Section 10.5, defined special considerations for a mobile > node's use of Duplicate Address Detection upon forming a new > care-of address. In particular, the mobile node MAY begin > using the new care-of address without performing Duplicate > Address Detection, and MAY optionally bypass Duplicate Address > Detection or begin Duplicate Address Detection asynchronously > when it begins use of the address, allowing the Duplicate > Address Detection procedure to complete in parallel with > normal communication using the address. In addition, the > mobile node SHOULD NOT delay sending the initial Neighbor > Solicitation message of Duplicate Address Detection by the random > delay specified for normal processing of Duplicate Address > Detection [17, 27], unless the mobile node is initializing after > rebooting. > > - In Section 4.6, added a clarification to the definition of the > Binding Update List, that for multiple Binding Updates sent to > the same destination address, the Binding Update List contains > only the most recent Binding Update (i.e., with the greatest > Sequence Number value) sent to that destination. This was > already noted in previous versions of the draft in the sending of > Binding Updates, as defined in Section update-corresp, but was > not previously stated explicitly in the definition of the Binding > Update List conceptual data structure. > > - In Section 9.3, added a specification that the lifetime for the > Binding Cache entry (and thus the Lifetime value returned in the > Binding Acknowledgement) MUST NOT be greater than the Lifetime > value specified in the Binding Update. Also added a similar > specification (and clarification) in Section 8.3 for the Binding > Cache entry in a correspondent node. > > - In Section 10.6, added a clarification that, when sending a > Binding Update to its home agent, the mobile node MUST also > create or update the corresponding Binding Update List entry, as > specified in Section 10.8. > > The official announcement of the draft should appear on the mailing > lists shortly, but you can get a copy of the new draft now from > > http://www.monarch.cs.cmu.edu/internet-drafts/draft-ietf-mobileip-ipv6-12.tx t > > We expect to go to Last Call on this version of the draft shortly. > Please send any comments on the draft to the Mobile IP mailing list at > mobile-ip(a)standards.nortelnetworks.com. > > Thanks. > > Dave > > -- > David B. Johnson dbj(a)cs.cmu.edu > Associate Professor http://www.cs.cmu.edu/~dbj/ > Computer Science Department http://www.monarch.cs.cmu.edu/ > Carnegie Mellon University Phone: (412) 268-7399 > 5000 Forbes Avenue Fax: (412) 268-5576 > Pittsburgh, PA 15213-3891 > > -------------------------------------------------------------------- > 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: UNH Cthon, Forum results
by Thomas Trede 11 Apr '00

11 Apr '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Ray LaRocca" <rglr(a)iol.unh.edu> To: <ipng(a)sunroof.eng.sun.com> Cc: "Ray LaRocca" <rglr(a)iol.unh.edu> Sent: Monday, April 10, 2000 9:11 PM Subject: UNH Cthon, Forum results > Hello All, > > The following are the results of the UNH testing at Connectathon 2000 and > the IPv6 Forum meeting in Telluride. > > Connectathon 2000: > 1. 15 IPv6 implementations were present (5 times as many as last year) > 2. We tested Mobile IPv6, RIPng and BGP4+ interoperability (as well as > some conformance testing) > > IPv6 Forum, Telluride: > 1. 7 IPv6 implementations were present > 2 We tested RIPng, BGP4+, and tunneling interoperability (some conformance > testing here also) > > --------------------------------------------------------------- > Mobility testing at Connectathon: > --------------------------------------------------------------- > Participants: > ENST Bretagne, Ericsson, Ericsson-Telebit, Microsoft Research, NEC, Nokia > > Implementations present: > 5 home agents, 3 mobile nodes, 4 correspondent nodes > > Testing Highlights: > Approximately 20 interoperability tests were run over the course of the 3 > days of testing. We had a moderate level of interoperability even though > the implementations were in various stages of development (version 8, 9, > and 10 of the spec were present). The participants spent much of the time > debugging and modifying their code. > > Testing Topology: > 4 networks connected via a single mobile unaware v6 router. > > Testing Scenarios: > (A) > 1. A home agent, mobile node pair begin on the home network with a > correspondent node residing on a foreign network. > 2. The mobile node moves from the home network to a foreign network while > pinging the correspondent node. > 3. The mobile node then moves from a foreign network to another foreign > network continuing to ping the correspondent node. > 4. The mobile node then moves to the foreign network where the > correspondent node resides (still pinging) > 5. The mobile node returns home. > > (B) > The same as above except with a telnet session open between the mobile > node and the correspondent node. > > We were able to achieve success in both of the above scenarios. > > Issues/Questions: > 1. Versions 8, 9, and 10 of the spec were present. > 2. There were issues involving DAD when the mobile node returned home > (this has been addressed in version 11 of the spec) > 3. Issues with option ordering in the packet have also been addressed in > version 11 of the spec > 4. There was an implementation incorrectly detecting movement by detecting > the different EUI-64 of the router. In our setup the router was using the > same EUI-64 for each of its interfaces thus causing difficulty for that > implementation to detect movement. This issue was presented to Dave > Johnson and he has addressed this issue to the mobileip working group. > > What Next? > 1. We need to have an interoperability test event within 6 months to > include Mobile IPv4, DIAMETER, and Mobile IPv6, with IPsec interaction. (TBD) > 2. UNH IOL has developed Mobile IPv6 conformance tests and is currently > providing the testing service. > > --------------------------------------------------------------- > Routing and conformance testing at both Connectathon and IPv6 Forum > --------------------------------------------------------------- > Participants: 3Com, Cisco, COMPAQ, Ericsson-Telebit, HP, Hitachi, KAME, > Microsoft Research, NOKIA, Nortel, SCO, SGI, SUN > > RIPng: > 1. 14 implementations with nearly 100% interoperability > 2. Some minor issues that were implementation-specific > 3. The basic setup was all routers on the same network with some > configured routes being advertised. > 4. 1 question regarding advertising a prefix for a network on the actual > network was posted to the ipng mailing list. Implementations were doing > one of 3 things: advertise the prefix with metric 1, metric 16, or not > advertise it at all. > > BGP4+: > 1. 9 implementations with nearly 100% interoperability > 2. Some minor issues that were implementation-specific > 3. The basic setup was all routers on the same network establishing both > internal and external peer sessions with other routers. > > > --------------------------------------------------------------- > > > > > > > > > -------------------------------------------------------------------- > 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-site-prefixes-04.txt
by Thomas Trede 10 Apr '00

10 Apr '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: <Internet-Drafts(a)ietf.org> To: <IETF-Announce: ;> Cc: <ipng(a)sunroof.eng.sun.com> Sent: Monday, April 10, 2000 1:34 PM Subject: I-D ACTION:draft-ietf-ipngwg-site-prefixes-04.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 : Site prefixes in Neighbor Discovery > Author(s) : E. Nordmark > Filename : draft-ietf-ipngwg-site-prefixes-04.txt > Pages : 22 > Date : 06-Apr-00 > > This document specifies extensions to IPv6 Neighbor Discovery to > carry site prefixes. The site prefixes are used to reduce the effect > of site renumbering by ensuring that the communication inside a site > uses site-local addresses. > This protocol requires that all IPv6 implementations, even those that > do not implement this protocol, ignore all site-local addresses that > they retrieve from the DNS when the AAAA or A6 RRset contain both > global and site-local addresses. If the RRset contains only site- > local addresses those addresses can be used. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-site-prefixes-04.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-site-prefixes-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(a)ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ipngwg-site-prefixes-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. >

1 0

Re: [FYI] announcement of NTT's IPv6 trial in Europe
by Juergen Rauschenbach 28 Mar '00

28 Mar '00

Dear Mr. Nomura, thank you very much - this is a great opportunity! I will cc this information to the IPv6Forums member list and to the RIPE IPv6 WG. Regards, Juergen Rauschenbach, DFN At 17:13 28.03.00 +0100, Kenji NOMURA wrote: >Dear Dr.Rauschenbach, > >FYI, NTT Europe made an announcement of global IPv6 commercial trial in >Europe. >Visit our web site which includes the press release as well. >http://ipv6.uk.ntt.net > >Regards, > ># Kenji NOMURA @ IP Task Force, NTT Europe Limited >

1 0

Fw: Request to Advance "Initial IPv6 Sub-TLA ID Assignments"
by Thomas Trede 28 Mar '00

28 Mar '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Bob Hinden" <hinden(a)iprg.nokia.com> To: <narten(a)raleigh.ibm.com>; "Jeffrey Burgan" <burgan(a)corp.home.net> Cc: <scoya(a)ietf.org>; <deering(a)cisco.com>; <ipng(a)sunroof.eng.sun.com> Sent: Tuesday, March 28, 2000 3:10 AM Subject: Request to Advance "Initial IPv6 Sub-TLA ID Assignments" > Jeff, 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 > Informational RFC: > > Title : Initial IPv6 Sub-TLA ID Assignments > Author(s) : B. Hinden, S. Deering, B. Fink, T. Hain > Filename : draft-ietf-ipngwg-iana-tla-03.txt > Pages : 5 > Date : 14-Jan-00 > > This document was discussed at the Washington, DC IETF meeting and is being > submitted to document the initial IPv6 Sub-TLA ID assignments. > > 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: W.G. Last Call on "IP Version 6 Addressing Architecture"
by Thomas Trede 28 Mar '00

28 Mar '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Bob Hinden" <hinden(a)iprg.nokia.com> To: <ipng(a)sunroof.eng.sun.com> Sent: Tuesday, March 28, 2000 3:04 AM Subject: W.G. Last Call on "IP Version 6 Addressing Architecture" > This is a IPng working group last call for comments on advancing the > following document as a Draft Standard: > > Title : IP Version 6 Addressing Architecture > Author(s) : R. Hinden, S. Deering > Filename : draft-ietf-ipngwg-addr-arch-v3-00.txt > Pages : 25 > Date : 15-Mar-00 > > Please send substantive comments to the ipng mailing list, and minor > editorial comments to the authors. This last call period will end two > week from today on April 10, 2000. > > Bob Hinden / Steve Deering > > > -------------------------------------------------------------------- > 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