- ipv6-wg - mailman.ripe.net

Fw: Protocol Action: DNS Extensions to Support IP Version 6 to Proposed Standard
by Thomas Trede 31 May '00

31 May '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Matt Crawford" <crawdad(a)fnal.gov> To: "The IESG" <iesg-secretary(a)ietf.org> Cc: "RFC Editor" <rfc-editor(a)isi.edu>; "Internet Architecture Board" <iab(a)isi.edu>; <ipng(a)sunroof.eng.sun.com> Sent: Wednesday, May 31, 2000 4:46 PM Subject: Re: Protocol Action: DNS Extensions to Support IP Version 6 to Proposed Standard > > The IESG has approved the Internet-Draft 'DNS Extensions to Support IP > > Version 6' <draft-ietf-ipngwg-dns-lookups-08.txt> as a Proposed > > Right draft, wrong title. > > > DNS Extensions to Support IPv6 Address Aggregation and Renumbering > <draft-ietf-ipngwg-dns-lookups-08.txt> > > -------------------------------------------------------------------- > 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: Protocol Action: DNS Extensions to Support IP Version 6 to Proposed Standard
by Thomas Trede 31 May '00

31 May '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>; "Internet Architecture Board" <iab(a)isi.edu>; <ipng(a)sunroof.eng.sun.com> Sent: Wednesday, May 31, 2000 4:14 PM Subject: Protocol Action: DNS Extensions to Support IP Version 6 to Proposed Standard > > > The IESG has approved the Internet-Draft 'DNS Extensions to Support IP > Version 6' <draft-ietf-ipngwg-dns-lookups-08.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 changes to the Domain Name System to support > renumberable and aggregatable IPv6 addressing. The changes include a > new resource record type (called A6) to store an IPv6 address in a > manner that expedites network renumbering and updated definitions of > existing query types that return Internet addresses as part of > additional section processing. A6 records can hold all or part of an > address, with pointers to other DNS names holding the remaining part > of the address. > > For lookups keyed on IPv6 addresses (often called reverse lookups), > this document defines a new zone structure that 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. > > Working Group Summary > > This document was discussed extensively in both the IPNG and DNSIND > working groups. Although concern has been raised that use of the A6 > records will increase the demands placed on the DNS when resolving > names to addresses, the goal of easing site renumbering was deemed > important and the mechanism described in this document was viewed as > the best approach. > > Protocol Quality > > This document has been reviewed for the IESG by Thomas Narten and Erik > Nordmark. > > -------------------------------------------------------------------- > 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: Last Call: Router Renumbering for IPv6 to Proposed Standard
by Thomas Trede 26 May '00

26 May '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "The IESG" <iesg-secretary(a)ietf.org> To: <IETF-Announce: ;> Cc: <ipng(a)sunroof.eng.sun.com> Sent: Thursday, May 25, 2000 9:12 PM Subject: Last Call: Router Renumbering for IPv6 to Proposed Standard > > The IESG has received a request from the IPNG Working Group to consider > Router Renumbering for IPv6 <draft-ietf-ipngwg-router-renum-10.txt> as > a Proposed Standard. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg(a)ietf.org or ietf(a)ietf.org mailing lists by June 8, 2000. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-router-renum-10.txt > > > -------------------------------------------------------------------- > 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

Slides from UK IPv6 Event are now available online
by stuart.prevost＠bt.com 21 May '00

21 May '00

F.Y.I. Please visit the IPv6 Forum website if you wish to see the presentations from the UK IPv6 event held on the 10th May. The URL for the website is www.ipv6forum.com and follow the link at the top of the page. Regards, Stuart Prevost

1 0

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: "Matt Crawford" <crawdad(a)fnal.gov> To: <ipng(a)sunroof.eng.sun.com> Cc: <namedroppers(a)ops.ietf.org> Sent: Thursday, May 18, 2000 3:50 PM Subject: Re: I-D ACTION:draft-ietf-ipngwg-dns-lookups-08.txt > Differences between -07 and -08 are: > > > > IP6.INT -> IP6.ARPA for new style (bit based rather than nibble > based) reverse lookups. > > > > + Implementers are reminded of the necessity to limit the > + amount of work a resolver will perform in response to a > + client request. This principle MUST be extended to also > + limit the generation of DNS requests in response to one > + name-to-address (or address-to-name) lookup request. > > > Fixed a misformatted references. > -------------------------------------------------------------------- > 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-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