- ipv6-wg - mailman.ripe.net

Fw: (IPng 6824) RFC 2464 on IPv6 Packets over Ethernet
by Thomas Trede 08 Dec '98

08 Dec '98

FYI. Regards, Thomas Trede -----Original Message----- From: RFC Editor (by way of Bob Hinden <hinden(a)iprg.nokia.com>) <rfc-ed(a)ISI.EDU> To: ipng(a)sunroof.Eng.Sun.COM <ipng(a)sunroof.Eng.Sun.COM> Date: Donnerstag, 3. Dezember 1998 19:00 Subject: (IPng 6824) RFC 2464 on IPv6 Packets over Ethernet > >A new Request for Comments is now available in online RFC libraries. > > > RFC 2464: > > Title: Transmission of IPv6 Packets over Ethernet > Networks > Author(s): M. Crawford > Status: Proposed Standard > Date: December 1998 > Mailbox: crawdad(a)fnal.gov > Pages: 7 > Characters: 12725 > Obsoletes: 1972 > I-D Tag: draft-ietf-ipngwg-trans-ethernet-04.txt > > > URL: ftp://ftp.isi.edu/in-notes/rfc2464.txt > >This document specifies the frame format for transmission of IPv6 >packets and the method of forming IPv6 link-local addresses and >statelessly autoconfigured addresses on Ethernet networks. It also >specifies the content of the Source/Target Link-layer Address option >used in Router Solicitation, Router Advertisement, Neighbor >Solicitation, Neighbor Advertisement and Redirect messages when >those messages are transmitted on an Ethernet. > >This document is a product of the IPNG Working Group of the IETF. > >This is now a Proposed Standard Protocol. > >This document specifies an Internet standards track protocol for >the Internet community, and requests discussion and suggestions >for improvements. Please refer to the current edition of the >"Internet Official Protocol Standards" (STD 1) for the >standardization state and status of this protocol. 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 Alegre Ramos >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. >Content-Type: text/plain >Content-ID: <981202153423.RFC(a)RFC-EDITOR.ORG> > >RETRIEVE: rfc >DOC-ID: rfc2464 > ><ftp://ftp.isi.edu/in-notes/rfc2464.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: (IPng 6825) RFC 2462 on IPv6 Stateless Address Autoconfiguration
by Thomas Trede 08 Dec '98

08 Dec '98

FYI. Regards, Thomas Trede -----Original Message----- From: RFC Editor (by way of Bob Hinden <hinden(a)iprg.nokia.com>) <rfc-ed(a)ISI.EDU> To: ipng(a)sunroof.Eng.Sun.COM <ipng(a)sunroof.Eng.Sun.COM> Date: Donnerstag, 3. Dezember 1998 19:00 Subject: (IPng 6825) RFC 2462 on IPv6 Stateless Address Autoconfiguration > >A new Request for Comments is now available in online RFC libraries. > > > RFC 2462: > > Title: IPv6 Stateless Address Autoconfiguration > Author(s): S. Thomson, T. Narten > Status: Draft Standard > Date: December 1998 > Mailbox: set(a)thumper.bellcore.com, narten(a)raleigh.ibm.com > Pages: 25 > Characters: 61210 > Obsoletes: 1971 > I-D Tag: draft-ietf-ipngwg-addrconf-v2-02.txt > > > URL: ftp://ftp.isi.edu/in-notes/rfc2462.txt > > >This document specifies the steps a host takes in deciding how to >autoconfigure its interfaces in IP version 6. The autoconfiguration >process includes creating a link-local address and verifying its >uniqueness on a link, determining what information should be >autoconfigured (addresses, other information, or both), and in the >case of addresses, whether they should be obtained through the >stateless mechanism, the stateful mechanism, or both. This document >defines the process for generating a link-local address, the process >for generating site-local and global addresses via stateless address >autoconfiguration, and the Duplicate Address Detection procedure. The >details of autoconfiguration using the stateful protocol are specified >elsewhere. > >This document is a product of the IPNG Working Group of the IETF. > >This is now a Draft Standard Protocol. > >This document specifies an Internet standards track protocol for >the Internet community, and requests discussion and suggestions >for improvements. Please refer to the current edition of the >"Internet Official Protocol Standards" (STD 1) for the >standardization state and status of this protocol. 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 Alegre Ramos >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. >Content-Type: text/plain >Content-ID: <981202153022.RFC(a)RFC-EDITOR.ORG> > >RETRIEVE: rfc >DOC-ID: rfc2462 > ><ftp://ftp.isi.edu/in-notes/rfc2462.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: (IPng 6826) RFC 2461 on Neighbor Discovery for IPv6
by Thomas Trede 08 Dec '98

08 Dec '98

FYI. Regards, Thomas Trede -----Original Message----- From: RFC Editor (by way of Bob Hinden <hinden(a)iprg.nokia.com>) <rfc-ed(a)ISI.EDU> To: ipng(a)sunroof.Eng.Sun.COM <ipng(a)sunroof.Eng.Sun.COM> Date: Donnerstag, 3. Dezember 1998 19:00 Subject: (IPng 6826) RFC 2461 on Neighbor Discovery for IPv6 > >A new Request for Comments is now available in online RFC libraries. > > > RFC 2461: > > Title: Neighbor Discovery for IP Version 6 (IPv6) > Author(s): T. Narten, E. Nordmark, W. Simpson > Status: Draft Standard > Date: December 1998 > Mailbox: narten(a)raleigh.ibm.com, nordmark(a)sun.com, > bsimpson(a)MorningStar.com > Pages: 93 > Characters: 222516 > Obsoletes: 1970 > I-D Tag: draft-ietf-ipngwg-discovery-v2-03.txt > > > URL: ftp://ftp.isi.edu/in-notes/rfc2461.txt > > >This document specifies the Neighbor Discovery protocol for IP >Version 6. IPv6 nodes on the same link use Neighbor Discovery to >discover each other's presence, to determine each other's link-layer >addresses, to find routers and to maintain reachability information >about the paths to active neighbors. > >This document is a product of the IPNG Working Group of the IETF. > >This is now a Draft Standard Protocol. > >This document specifies an Internet standards track protocol for >the Internet community, and requests discussion and suggestions >for improvements. Please refer to the current edition of the >"Internet Official Protocol Standards" (STD 1) for the >standardization state and status of this protocol. 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 Alegre Ramos >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. >Content-Type: text/plain >Content-ID: <981202152730.RFC(a)RFC-EDITOR.ORG> > >RETRIEVE: rfc >DOC-ID: rfc2461 > ><ftp://ftp.isi.edu/in-notes/rfc2461.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: (IPng 6823) RFC 2463 on ICMPv6 (ICMP for IPv6)
by Thomas Trede 08 Dec '98

08 Dec '98

FYI. Regards, Thomas Trede -----Original Message----- From: RFC Editor (by way of Bob Hinden <hinden(a)iprg.nokia.com>) <rfc-ed(a)ISI.EDU> To: ipng(a)sunroof.Eng.Sun.COM <ipng(a)sunroof.Eng.Sun.COM> Date: Donnerstag, 3. Dezember 1998 18:55 Subject: (IPng 6823) RFC 2463 on ICMPv6 (ICMP for IPv6) > >A new Request for Comments is now available in online RFC libraries. > > > RFC 2463: > > Title: Internet Control Message Protocol (ICMPv6) > for the Internet Protocol Version 6 (IPv6) > Specification > Author(s): A. Conta, S. Deering > Status: Draft Standard > Date: December 1998 > Mailbox: aconta(a)lucent.com, deering(a)cisco.com > Pages: 18 > Characters: 34190 > Obsoletes: 1885 > I-D Tag: draft-ietf-ipngwg-icmp-v2-02.txt > > > URL: ftp://ftp.isi.edu/in-notes/rfc2463.txt > > >This document specifies a set of Internet Control Message Protocol >(ICMP) messages for use with version 6 of the Internet Protocol >(IPv6). > >This document is a product of the IPNG Working Group of the IETF. > >This is now a Draft Standard Protocol. > >This document specifies an Internet standards track protocol for >the Internet community, and requests discussion and suggestions >for improvements. Please refer to the current edition of the >"Internet Official Protocol Standards" (STD 1) for the >standardization state and status of this protocol. 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 Alegre Ramos >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. >Content-Type: text/plain >Content-ID: <981202153227.RFC(a)RFC-EDITOR.ORG> > >RETRIEVE: rfc >DOC-ID: rfc2463 > ><ftp://ftp.isi.edu/in-notes/rfc2463.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

Minutes of IPv6-WG at RIPE 31
by Thomas Trede 06 Dec '98

06 Dec '98

Hello, since no more comments were received, here are the final minutes of the IPv6-WG at RIPE 31. Again, thanks to Sabrina and David! Regards, Thomas Minutes of IPv6 Working Group, 24th of Sept. 1998 1. Administrative stuff: Chair: David Kessens (Thomas Trede apologised) Minutes: Sabrina Waschke # Attendees: 81 2. Reports Report - 6Bone by David Kessens - Status report there are now about 300 IPv6 connected sites on the 6bone the trend is to connect natively instead of using tunnels (slides will be available at http://www.ripe.net/meetings/ripe/ripe-31/pres/) - Information on the 6bone can be found at: see <http://www.6bone.net> 3. Current status of RIPE regarding address assignments in IPv6 by Paula Caslav - RIPE NCC is in process of discussing the documentation, finding guidelines and procedures, by taking the IETF draft, looking at the criteria, what documentation will we need, working on details with other regional registries and will have a meeting with them, send then a draft to the relevant working groups and the RIPE community, final version will be published - Hopefully ready in January 1999 Question by: David Kessens: Could you give more detail in the time scale ? Paula Caslav: November 1998: first draft of procedures document ready to be discussed among the regional registries and RIPE January 1999: start allocating IPv6 addresses (depends on IANA to be ready to allocate to the regional registries and on the registries to get their databases and procedures compliant) All regional registries will start allocating at the same time. There will be no change in the fee structure for the next year. Question by David Kessens: Do you have any comments what will be different in the assignment guidelines for the TLA's in the IETF draft and yours ? Paula Caslav: We might do a slow start mechanism in meaning of allocating a sub TLA first. Mirjam Kuehne: We also need to define still how to determine if an organisation is a transit provider. Many details are still under discussion. Comment by the audience: It might be useful to have a document in this Working Group as soon as possible. Mirjam Kuehne: We are in the process of collecting input and will discuss it with the other Working Groups. We receive requests for IPv6 addresses, some are detailed, some are just general. We will see how we can implement this in the operations and procedures. Paula Caslav: If you have any ideas send them to us or the mailing list of this Working Group. 2.3. News about manufacturers implementation - input from the audience Bernard Tuy showed an overview of all vendors and what they currently support. For details see: http://phoebe.urec.fr/G6/ http://www.ipv6.urec.fr/G6/ 4. General Input from other Working Groups Routing WG presented by Joachim Schmitz (slides will be available at http://www.ripe.net/meeting/ripe/ripe31/pres/) Do we need an IRR for IPv6 ? Need for an IPv6 IRR: - due to the benefits: YES - plus: manage interface ipv4 _> ipv6 - time to early: NO We need an IPv6 routing registry ! <general acceptence without taking over any concrete initiative by the audience> Joachim Schmitz: Call for participation. He expects a gradual move over, requirements in the beginning are not very high, so one registry might be enough to start with. David Kessens: The regional registries also need to think about assignment policies for AS numbers, they might be different. David K: There are several ways to go to a IPv6 routing registry: 1. just replace IPv4 with IPv6 addresses in RPSL, and add IPv6 specific support later on 2. a special RPSLv6 draft with all bells and whistles that are required to do IPv6 routing registries What is better ? Joachim Schmitz: Both are needed, because RPSL took some time to be developed and we need something running soon. That's not sufficient but better than nothing. David Kessens: Coming out with an RPSL IPv6 version would make sense. 5. AOB: David Kessens: Keep this Working Group and move on because of the large interest (81 attendees). Discuss the allocation and assignment process in more detail. Action points: 31.1 RIPE NCC will start allocating IPv6 addresses by the next RIPE meeting in January. 31.2 send out to 1) experienced people draft documents about address registration and allocation 2) concerned WGs more finalized papers to stress the discussion and have working papers ready by the end of '98.

1 0

Fw: (IPng 6840) W.G. Last Call on "The IPv6 Jumbo Payload Option"
by Thomas Trede 04 Dec '98

04 Dec '98

FYI. Regards, Thomas Trede -----Original Message----- From: Bob Hinden <hinden(a)iprg.nokia.com> To: ipng(a)sunroof.Eng.Sun.COM <ipng(a)sunroof.Eng.Sun.COM> Date: Freitag, 4. Dezember 1998 03:36 Subject: (IPng 6840) W.G. Last Call on "The IPv6 Jumbo Payload Option" >This is a IPng working group last call for comments on advancing the >following document as a Proposed Standard: > > Title : The IPv6 Jumbo Payload Option > Author(s) : B. Hinden, S. Deering > Filename : draft-ietf-ipngwg-jumbo-00.txt > Pages : 5 > Date : 07-Aug-98 > >Please send substantive comments to the ipng mailing list, and minor >editorial comments to the authors. This last call period will end one >week from today on December 10, 1998. > >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

Fw: (IPng 6812) W.G. Last Call on "Initial IPv6 Sub-TLA ID Assignments"
by Thomas Trede 01 Dec '98

01 Dec '98

FYI. Regards, Thomas Trede -----Original Message----- From: Bob Hinden <hinden(a)iprg.nokia.com> To: ipng(a)sunroof.Eng.Sun.COM <ipng(a)sunroof.Eng.Sun.COM> Date: Dienstag, 1. Dezember 1998 19:45 Subject: (IPng 6812) W.G. Last Call on "Initial IPv6 Sub-TLA ID Assignments" >This is an IPng working group last call for comments on advancing the >following document as an Informational RFC: > > Title : Initial IPv6 Sub-TLA ID Assignments > Author(s) : B. Hinden, S. Deering, R. Fink, T. Hain > Filename : draft-ietf-ipngwg-iana-tla-00.txt > Pages : 5 > Date : 17-Nov-98 > >This document proposes initial assignments of IPv6 Sub-TLA Aggregation >Identifiers (Sub-TLA ID) to the Address Registries and continued management >of the IP6.INT domain. It is intended as input to the IANA from the IETF >IP Next Generation (IPNG) and Next Generation Transition (NGTRANS) working >groups as an aid in starting the process of allocating IPv6 addresses. It >is not intended for any official IETF status. > >The goal is to have the IPng w.g. advance this document so it can be >approved and sent to the IANA to help expedite the process of starting the >allocation of IPng addresses. > >Please send substantive comments to the ipng mailing list, and minor >editorial comments to the author. This last call period will end at the >Thursday IETF IPng session on December 10, 1998. > >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

Fw: (IPng 6786) Protocol Action: IPv6 over Non-Broadcast Multiple Access (NBMA) networks to Proposed Standard
by Thomas Trede 26 Nov '98

26 Nov '98

FYI. Regards, Thomas Trede -----Original Message----- From: The IESG (by way of Bob Hinden <hinden(a)iprg.nokia.com>) <iesg-secretary(a)ietf.org> To: ipng(a)sunroof.Eng.Sun.COM <ipng(a)sunroof.Eng.Sun.COM> Date: Mittwoch, 25. November 1998 17:39 Subject: (IPng 6786) Protocol Action: IPv6 over Non-Broadcast Multiple Access (NBMA) networks to Proposed Standard > > >The IESG has approved publication of the following Internet-Drafts as >Proposed Standards: > >o IPv6 over Non-Broadcast Multiple Access (NBMA) networks > <draft-ietf-ion-ipv6-02.txt> > >o IPv6 over ATM Networks > <draft-ietf-ion-ipv6-atm-03.txt> > >These documents are the product of the Internetworking Over NBMA >Working Group. The IESG contact persons are Jeffrey Burgan and Thomas >Narten. > > >Technical Summary > > The document "IPv6 over Non-Broadcast Multiple Access (NBMA) > networks" provides a framework for how to run IPv6 over NBMA > link types (e.g., ATM, Frame Relay, etc.). It provides a basis for > companion documents (e.g., "IPv6 over ATM Networks") to define > specific items that are by their nature link-layer specific. The > first document also defines how a client can use use Neighbor > Discovery to request NBMA shortcuts (i.e., to initiate NHRP > services). The MARS model is assumed, allowing Neighbor > Discovery to be used (Neighbor Discovery assumes multicast is > available on a specific link-layer.) The two documents together > define how to run IPv6 over ATM networks for both SVCs and PVCs. > >Working Group Summary > > There was consenus in the WG for this approach, and no issues were > raised during the Last Call. > >Protocol Quality > > This specification has been reviewed for the IESG by Thomas Narten > and Jeffrey Burgan. > > > >-------------------------------------------------------------------- >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: (IPng 6771) I-D ACTION:draft-ietf-ipngwg-esd-analysis-03.txt
by Thomas Trede 24 Nov '98

24 Nov '98

FYI. Regards, Thomas Trede -----Original Message----- From: Internet-Drafts(a)ietf.org <Internet-Drafts(a)ietf.org> To: "IETF-Announce:;;;;@ns.cnri.reston.va.us;"@Eng.Sun.COM;;; <"IETF-Announce:;;;;@ns.cnri.reston.va.us;"@Eng.Sun.COM;;;> Cc: ipng(a)sunroof.Eng.Sun.COM <ipng(a)sunroof.Eng.Sun.COM> Date: Dienstag, 24. November 1998 00:19 Subject: (IPng 6771) I-D ACTION:draft-ietf-ipngwg-esd-analysis-03.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 : Separating Identifiers and Locators > in Addresses: An Analysis of the GSE Proposal > for IPv6 > Author(s) : M. Crawford, A. Mankin, T. Narten, > J. Stewart, L. Zhang > Filename : draft-ietf-ipngwg-esd-analysis-03.txt > Pages : 50 > Date : 20-Nov-98 > > On February 27-28, 1997, the IPng Working Group held an interim > meeting in Palo Alto, California to consider adopting Mike O'Dell's > 'GSE - An Alternate Addressing Architecture for IPv6' proposal [GSE]. > In GSE, 16-byte IPv6 addresses are split into distinct portions for > global routing, local routing and end-point identification. GSE > includes the feature of configuring a node internal to a site with > only the local routing and end-point identification portions of the > address, thus hiding the full address from the node. When such a > node generates a packet, only the low-order bytes of the source > address are specified; the high-order bytes of the address are filled > in by a border router when the packet leaves the site. > > There is a long history of a vague assertion in certain circles that > IPv4 'got it wrong' by treating its addresses simultaneously as > locators and identifiers. Despite these claims, however, there was > never a complete proposal for a scaleable network protocol which > separated the functions. As a result, it wasn't possible to do a > serious analysis comparing and contrasting a 'separated' architecture > and an 'overloaded' architecture. The GSE proposal serves as a > vehicle for just such an analysis, and that is the purpose of this > paper. > > We conclude that an architecture that clearly separates locators and > identifiers in addresses introduces new issues and problems that do > not have an easy or clear solution. Indeed, the alleged > disadvantages of overloading addresses turn out to provide some > significant benefits over the non-overloaded approach. > >Internet-Drafts are 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-esd-analysis-03.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-esd-analysis-03.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nic.it > > Pacific Rim: munnari.oz.au > > US East Coast: ftp.ietf.org > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv(a)ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-ipngwg-esd-analysis-03.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-esd-analysis-03.txt

1 0

Fw: (IPng 6765) I-D ACTION:draft-ietf-ipngwg-iana-tla-00.txt
by Thomas Trede 20 Nov '98

20 Nov '98

FYI. Regards, Thomas Trede -----Original Message----- From: Internet-Drafts(a)ietf.org <Internet-Drafts(a)ietf.org> To: "IETF-Announce:;;;;@ns.cnri.reston.va.us;"@Eng.Sun.COM;;; <"IETF-Announce:;;;;@ns.cnri.reston.va.us;"@Eng.Sun.COM;;;> Cc: ipng(a)sunroof.Eng.Sun.COM <ipng(a)sunroof.Eng.Sun.COM> Date: Donnerstag, 19. November 1998 17:23 Subject: (IPng 6765) I-D ACTION:draft-ietf-ipngwg-iana-tla-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 : Initial IPv6 Sub-TLA ID Assignments > Author(s) : B. Hinden, S. Deering, R. Fink, T. Hain > Filename : draft-ietf-ipngwg-iana-tla-00.txt > Pages : 5 > Date : 17-Nov-98 > > This document proposes initial assignments of IPv6 Sub-TLA > Aggregation Identifiers (Sub-TLA ID) to the Address Registries and > continued management of the IP6.INT domain. It is intended as input > to the IANA from the IETF IP Next Generation (IPNG) and Next > Generation Transition (NGTRANS) working groups as an aid in starting > the process of allocating IPv6 addresses. It is not intended for any > official IETF status. > >Internet-Drafts are 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-iana-tla-00.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-iana-tla-00.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nic.it > > Pacific Rim: munnari.oz.au > > US East Coast: ftp.ietf.org > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv(a)ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-ipngwg-iana-tla-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. > ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-iana-tla-00.txt

1 0