- ipv6-wg - mailman.ripe.net

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

Fw: RFC 2928 on Initial IPv6 Sub-TLA ID Assignments
by Thomas Trede 30 Sep '00

30 Sep '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: "RFC Editor" <rfc-ed(a)ISI.EDU> To: <IETF-Announce: ;> Cc: <rfc-ed(a)ISI.EDU>; <ipng(a)sunroof.eng.sun.com> Sent: Saturday, September 30, 2000 2:11 AM Subject: RFC 2928 on Initial IPv6 Sub-TLA ID Assignments > > A new Request for Comments is now available in online RFC libraries. > > > RFC 2928 > > Title: Initial IPv6 Sub-TLA ID Assignments > Author(s): R. Hinden, S. Deering, R. Fink, T. Hain > Status: Informational > Date: September 2000 > Mailbox: hinden(a)iprg.nokia.com, deering(a)cisco.com, > rlfink(a)lbl.gov, tonyhain(a)microsoft.com > Pages: 7 > Characters: 11882 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-ipngwg-iana-tlal-03.txt > > URL: ftp://ftp.isi.edu/in-notes/rfc2928.txt > > > This document defines initial assignments of IPv6 Sub-Top-Level > Aggregation Identifiers (Sub-TLA ID) to the Address Registries. It is > intended as technical input to the Internet Assigned Numbers Authority > (IANA) from the Internet Engineering Task Force (IETF) Internet > Protocol Next Generation (IPNG) and Next Generation Transition > (NGTRANS) working groups, as an input to the process of developing > guidelines for the allocation of IPv6 addresses. > > This document was originally developed to provide advice to IANA in > the fall of 1998 and is being published at this time for the > historical record. The Internet Architecture Board (IAB) subsequently > requested that the IANA delegate these assignments to the Address > Registries. The IANA did this and the Address Registries are now > using them to assign IPv6 addresses. > > This document is a product of the IPNG Working Group of the IETF. > > This memo provides information for the Internet community. It does > not specify an Internet standard of any kind. Distribution of this > memo is unlimited. > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST(a)IETF.ORG. Requests to be > added to or deleted from the RFC-DIST distribution list should > be sent to RFC-DIST-REQUEST(a)RFC-EDITOR.ORG. > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to rfc-info(a)RFC-EDITOR.ORG with the message body > help: ways_to_get_rfcs. For example: > > To: rfc-info(a)RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to RFC-Manager(a)RFC-EDITOR.ORG. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution.echo > Submissions for Requests for Comments should be sent to > RFC-EDITOR(a)RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC > Authors, for further information. > > > Joyce K. Reynolds and Sandy Ginoza > USC/Information Sciences Institute > > ... > > Below is the data which will enable a MIME compliant Mail Reader > implementation to automatically retrieve the ASCII version > of the RFCs. >

1 0

Fw: I-D ACTION:draft-ietf-dnsext-message-size-01.txt
by Thomas Trede 29 Sep '00

29 Sep '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: <Internet-Drafts(a)ietf.org> To: <IETF-Announce: ;> Cc: <namedroppers(a)ops.ietf.org>; <ipng(a)sunroof.eng.sun.com> Sent: Friday, September 29, 2000 1:01 PM Subject: I-D ACTION:draft-ietf-dnsext-message-size-01.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the DNS Extensions Working Group of the IETF. > > Title : DNSSEC and IPv6 A6 aware server/resolver message size > requirements > Author(s) : O. Gudmundsson > Filename : draft-ietf-dnsext-message-size-01.txt > Pages : 6 > Date : 28-Sep-00 > > This document mandates support for EDNS0 in DNS entities claiming to > support DNS Security Extensions and A6 records. This requirement is > necessary because these new features increase the size of DNS > messages. If EDNS0 is not supported fallback to TCP will happen, > having a detrimental impact on query latency and DNS server load. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-message-size-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-dnsext-message-size-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-dnsext-message-size-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: I-D ACTION:draft-ietf-ipngwg-uni-based-mcast-00.txt
by Thomas Trede 28 Sep '00

28 Sep '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, September 28, 2000 12:45 PM Subject: I-D ACTION:draft-ietf-ipngwg-uni-based-mcast-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 : Unicast-Prefix-based IPv6 Multicast Addresses > Author(s) : B. Haberman, D. Thaler > Filename : draft-ietf-ipngwg-uni-based-mcast-00.txt > Pages : 5 > Date : 27-Sep-00 > > This specification defines an extension to the multicast addressing > architecture of the IP Version 6 protocol. The extension presented > in this document allows for unicast-prefix-based allocation of > multicast addresses. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-uni-based-mcast-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-uni-based-mcast-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-uni-based-mcast-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

Routing protocols?
by Niall Murphy 27 Sep '00

27 Sep '00

Hi folks, I am looking at doing some IPv6 routing and I'm wondering what the status of the various routing protocols is: 1) RIP is working I've been told (but I don't want to use it) 2) Is BGP working/defined? 3) What about IS-IS? 4) Who is doing production v6 routing at the moment? Thanks for any comments you might have. Niall -- Enigma Consulting

5 4

Fw: Last Call: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 to Proposed Standard
by Thomas Trede 27 Sep '00

27 Sep '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: Monday, September 25, 2000 8:25 PM Subject: Last Call: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 to Proposed Standard > > The IESG has received a request from the IPNG Working Group to consider > Privacy Extensions for Stateless Address Autoconfiguration in IPv6 > <draft-ietf-ipngwg-addrconf-privacy-03.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 October 9, 2000. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addrconf-privacy-03.tx t > -------------------------------------------------------------------- > 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