- ipv6-wg - mailman.ripe.net

(IPng 7431) I-D ACTION:draft-ietf-msdp-mibdraft--00.txt (fwd)
by Thomas Trede 27 Apr '99

27 Apr '99

FYI. Regards, Thomas Trede ---------- Forwarded message ---------- Date: Thu, 22 Apr 1999 09:18:10 -0400 From: Internet-Drafts(a)ietf.org To: IETF-Announce: ; Cc: ipng(a)sunroof.eng.sun.com Subject: (IPng 7431) I-D ACTION:draft-ietf-msdp-mibdraft--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 : Multicast Source Discovery protocol MIB Author(s) : B. Fenner, D. Thaler Filename : draft-ietf-msdp-mibdraft-00.txt Pages : 22 Date : 21-Apr-99 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Multicast Source Discovery Protocol (MSDP) [17] speakers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msdp-mibdraft--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-msdp-mibdraft--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-msdp-mibdraft--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

(IPng 7430) I-D ACTION:draft-ietf-ion-nhrp-mib-06.txt (fwd)
by Thomas Trede 27 Apr '99

27 Apr '99

FYI. Regards, Thomas Trede ---------- Forwarded message ---------- Date: Thu, 22 Apr 1999 09:18:01 -0400 From: Internet-Drafts(a)ietf.org To: IETF-Announce: ; Cc: ipng(a)sunroof.eng.sun.com Subject: (IPng 7430) I-D ACTION:draft-ietf-ion-nhrp-mib-06.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 : Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP) Author(s) : M. Greene, J. Cucchiara, J. Luciani Filename : draft-ietf-ion-nhrp-mib-06.txt Pages : 67 Date : 21-Apr-99 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for the Next Hop Resolution Protocol (NHRP) as defined in RFC 2332. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ion-nhrp-mib-06.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-ion-nhrp-mib-06.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-ion-nhrp-mib-06.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

draft agenda (v1) for IPv6 working group RIPE33
by David Kessens 27 Apr '99

27 Apr '99

Hi, Below follows the first version of the IPv6 wg agenda. Note that on tuesday, we have scheduled, in addition to the regular wg session on wednesday, a tutorial about IPv6 (see the RIPE website for details). I anticipate that we will (and should) use most of our time for discussing the new IPv6 allocation draft. I would like to advise everybody to read the document: http://www.ripe.net/lir/registries/ipv6.html in order to allow us to have a focussed discussion. Note that we can give the most valuable input to the registries if we can come up with alternatives for pieces that we don't like, instead of telling them that we don't like something. Things to keep in mind when coming up with alternate proposals are: routability, conservation, verification of criteria, administrative overhead. Please let me know if you have other items that need to be discussed, David K. --- Proposed Agenda (draft v1) for the IPv6 Working Group Meeting RIPE33, May 1999, Vienna A. Administrative stuff (David Kessens) - appointment of scribe - agenda bashing B. Status of 6bone (David Kessens) C. IPv6 in practice (Jan Czmok) D. European developments/initiatives regarding IPv6 (input from the audience) E. IPv6 allocation progress (RIPE NCC): http://www.ripe.net/lir/registries/ipv6.html Z. AOB ---

1 0

(IPng 7426) Request to Advance "IPv6 Jumbograms" (fwd)
by Thomas Trede 21 Apr '99

21 Apr '99

FYI. Regards, Thomas Trede ---------- Forwarded message ---------- Date: Wed, 21 Apr 1999 08:58:54 -0700 From: Bob Hinden <hinden(a)iprg.nokia.com> To: narten(a)raleigh.ibm.com, nordmark(a)eng.sun.com Cc: scoya(a)cnri.reston.va.us, deering(a)cisco.com, ipng(a)sunroof.eng.sun.com Subject: (IPng 7426) Request to Advance "IPv6 Jumbograms" 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 a Proposed Standard: Title : IPv6 Jumbograms Author(s) : D. Borman, S. Deering, R. Hinden Filename : draft-ietf-ipngwg-jumbograms-00.txt Pages : 8 Date : 01-Mar-99 A working group last call for this document was completed on April 7, 1999. 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

(IPng 7427) Request to Advance "Router Renumbering for IPv6" (fwd)
by Thomas Trede 21 Apr '99

21 Apr '99

FYI. Regards, Thomas Trede ---------- Forwarded message ---------- Date: Wed, 21 Apr 1999 09:03:02 -0700 From: Bob Hinden <hinden(a)iprg.nokia.com> To: narten(a)raleigh.ibm.com, nordmark(a)eng.sun.com Cc: scoya(a)cnri.reston.va.us, deering(a)cisco.com, ipng(a)sunroof.eng.sun.com Subject: (IPng 7427) Request to Advance "Router Renumbering for IPv6" 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 a Proposed Standard: Title : Router Renumbering for IPv6 Author(s) : M. Crawford Filename : draft-ietf-ipngwg-router-renum-08.txt Pages : 30 Date : 01-Mar-99 A working group last call for this document was completed on April 7, 1999. This version of the document reflects comments received during an earlier IETF last call and IESG review. 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

(IPng 7428) Request to Advance "Multicast Listener Discovery (MLD) for IPv6" (fwd)
by Thomas Trede 21 Apr '99

21 Apr '99

FYI. Regards, Thomas Trede ---------- Forwarded message ---------- Date: Wed, 21 Apr 1999 09:04:22 -0700 From: Bob Hinden <hinden(a)iprg.nokia.com> To: narten(a)raleigh.ibm.com, nordmark(a)eng.sun.com Cc: scoya(a)cnri.reston.va.us, deering(a)cisco.com, ipng(a)sunroof.eng.sun.com Subject: (IPng 7428) Request to Advance "Multicast Listener Discovery (MLD) for IPv6" 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 a Proposed Standard: Title : Multicast Listener Discovery (MLD) for IPv6 Author(s) : S. Deering, B. Fenner, B. Haberman Filename : draft-ietf-ipngwg-mld-01.txt Pages : 20 Date : 01-Mar-99 A working group last call for this document was completed on April 7, 1999. 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

(ngtrans) I-D ACTION:draft-ietf-ngtrans-introduction-to-ipv6-trans ition-00.txt (fwd)
by Thomas Trede 21 Apr '99

21 Apr '99

FYI. Regards, Thomas Trede ---------- Forwarded message ---------- Date: Wed, 21 Apr 1999 13:10:42 -0400 From: Internet-Drafts(a)ietf.org To: IETF-Announce: ; Cc: ngtrans(a)sunroof.eng.sun.com Subject: (ngtrans) I-D ACTION:draft-ietf-ngtrans-introduction-to-ipv6-transition-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Generation Transition Working Group of the IETF. Title : A Guide to the Introduction of IPv6 in the IPv4 World Author(s) : W. Biemolt, M. Kaat, R. van der Pol, H. Steenman Filename: draft-ietf-ngtrans-introduction-to-ipv6-transition-00.txt Pages : 26 Date : 20-Apr-99 This document is a guide to the introduction of IPv6 in the current IPv4 based Internet or Intranets. Several general issues to start IPv6 networking in a predominantly IPv4 world are discussed, such as how to obtain IPv6 address space, IPv6 DNS and routing issues. Short descriptions are given of the different translation and migration tools that translate between IPv6 and IPv4 and/or tunnel IPv6 over IPv4. The remainder of the document describes how IPv6 can be introduced in various environments, such as ISPs, Internet Exchanges and end user environments and suggestions are given on the use of the different translation and migration tools. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-introduction-to-ipv6… 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-ngtrans-introduction-to-ipv6-transition-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-ngtrans-introduction-to-ipv6-transition-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

(IPng 7429) I-D ACTION:draft-ietf-ipngwg-hbh-ext-csi-00.txt (fwd)
by Thomas Trede 21 Apr '99

21 Apr '99

FYI. Regards, Thomas Trede ---------- Forwarded message ---------- Date: Wed, 21 Apr 1999 09:38:22 -0400 From: Internet-Drafts(a)ietf.org To: IETF-Announce: ; Cc: ipng(a)sunroof.eng.sun.com Subject: (IPng 7429) I-D ACTION:draft-ietf-ipngwg-hbh-ext-csi-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 : Connection/Link Status Investigation (CSI) for IPv6 IPv6 Hop-by-Hop option and ICMPv6 messages Extension Author(s) : H. Kitamura Filename : draft-ietf-ipngwg-hbh-ext-csi-00.txt Pages : 24 Date : 20-Apr-99 This document proposes a new mechanism whereby status information is collected for nodes along both the outgoing and incoming paths. This mechanism is called 'Connection/Link Status Investigation (CSI).' In order to realize the CSI mechanism, one new IPv6 Hop-by-Hop option and three new ICMPv6 messages are proposed as extensions. The CSI mechanism is as simple as the 'ping' mechanism and is also efficient, because ideally the status information of the nodes is collected with a pair of 'request/reply' ICMPv6 messages. By using the CSI mechanism, more efficient and reliable 'traceroute' type functions can be realized. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-hbh-ext-csi-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-hbh-ext-csi-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-hbh-ext-csi-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

IPv6 tutorial
by David Kessens 16 Apr '99

16 Apr '99

Hi, I promised earlier that I would try to organize a tutorial regarding IPv6 for the next RIPE meeting. After sending them a request, Marc Blanchet and Florent Parent, both at Viaginie Inc., CA, were willing to give such a tutorial. The tutorial is scheduled for tuesday, May 5. Attached below is a description. David K. --- ============================================== IPv6 primer IPv6, the next generation IP protocol, is designed to improve scalability, security, ease-of-configuration, and network management. The tutorial will give a brief overview of IPv6 protocol including address architecture, autoconfiguration and management (DNS, routing). We will also discuss about the transition mechanisms have been designed to ease the upgrade to IPv6. An overview of the configuration for routers and workstations with examples will be given: Cisco, FreeBSD, Sun, Windows NT, as well as the Merit MRTd. The tutorial will go over the different steps required to get connected on the 6BONE, including address configuration, routing and the 6BONE registry. The tunnel server is a service that provides a simple way to get connected to the 6BONE. The architecture of the server and examples will be presented. A description of the 6REN initiative, an IPv6 transit service, and the 6TAP project, a service for interconnecting early IPv6 networks, will be presented. This tutorial is not focused on the theory behind the protocol but more on the practical considerations for using and deploying IPv6, so the intended audience is tcp/ip engineers, architects and network admins that want to understand IPv6 and to be able to deploy it. The tutorial will be presented by Marc Blanchet and Florent Parent, both at Viaginie inc., a consulting firm working on network architectures, security and internationalization. Viaginie inc. is responsible with Dalhousie University of the deployment of IPv6 in Canada. Viaginie 6bone site has been on the 6bone since more than 2 years now, is one of the backbone sites and maintains IPv6 links with many international organisations ; it also runs the mirror of the 6bone whois server, the IPv6 mirror of the www.6bone.net, www.6ren.net sites. Viaginie also designed a tunnel server implementation available at http://www.freenet6.net. Marc Blanchet wrote a internet-draft on a flexible method for IPv6 address assignments, soon to be published as an informational RFC and is the author of the concept of the 6tap exchange. ---

2 3

IPv6 Assignment and Allocation Policy Document
by Paula Caslav 16 Apr '99

16 Apr '99

Dear colleagues, The RIPE NCC is pleased to make available the latest draft "IPv6 Assignment and Allocation Policy Document" for your information. This document http://www.ripe.net/lir/registries/ipv6.html is the result of a collaborative effort of all the Regional Internet Registries (APNIC, ARIN, and RIPE NCC) and aims to provide a responsible, globally consistent framework for the management of IPv6 address space. This new version takes into consideration suggestions and comments made by the RIPE community on the ipv6-wg mailing list and at the last RIPE meeting, as well as comments made by other communities (such as the ARIN and APNIC members, the IETF and the IAB). IPv6 address space is a public resource and, therefore, its management involves developing policies which achieve the best possible balance of the needs of all members of the Internet community. The RIPE NCC encourages you, as a member of the Internet community, to read this document and consider its implications. We invite you to make any comments you feel would be constructive to the development of a further draft. In order to ensure global consensus, the discussion of this draft will take place on the 6bone mailing list. This way the comments are all collected in one place, and interested parties from all regions/communities can participate. To join this list, please refer to http://www.6bone.net/6bone_email.html. If you would prefer to make private comments about this document, please contact Paula Caslav <paula(a)ripe.net>. Kind regards, Paula Caslav RIPE NCC IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (5th draft 16 April 1999) [* Important note: Throughout this draft, several sections require numerical values to be specified, pending further discussion and comment from the Internet community. In such cases the variable "X*" has been used in place of the numerical value. Where relevant the variable is accompanied by a suggested value range, such as "range=3-6".] TABLE OF CONTENTS Abstract 1. Scope 2. IPv6 Address Space and the Internet Registry System 2.1 The Internet Registry System Hierarchy 2.2 Goals of the Internet Registry System 3. IPv6 Technical Framework 3.1 IPv6 Addressing Hierarchy 3.2 Initial IPv6 Addressing Hierarchy 4. Addressing Policies 4.1 IPv6 Addresses Not to be Considered Property 4.2 Allocations 4.3 Assignments 4.4 Reclamation Methods/Conditions 5. Organizations Operating in More than One Region 6. DNS and Reverse Address Mapping 7. Glossary 8. List of References ABSTRACT This document describes the registry system for distributing globally unique unicast IPv6 address space. IPv6 address space is distributed in a hierarchical manner (as is IPv4 address space), managed by the IANA and further delegated by the Regional Internet Registries (Regional IRs) as described in RFC 1881. In the case of IPv6, the Regional IRs allocate Top-Level Aggregation Identifiers (TLAs) to organizations, which, as TLA Registries, in turn allocate or assign address space to other Internet Service Providers (ISPs) and end users. ISPs then serve as Next Level Aggregation (NLA) Registries for their customers. This document describes the responsibilities, policies, and procedures associated with IPv6 address space management, to be followed by all organizations within the allocation hierarchy. The intention of this document is to provide a framework for clear understanding and consistent application of those responsibilities, policies, and procedures throughout all layers of the hierarchy. 1. SCOPE This document first describes the global Internet Registry system for the distribution of IPv6 address space (as defined in RFC 2374) and the management of that address space. It then describes the policies and guidelines governing the distribution of IPv6 address space. The policies set forth in this document should be considered binding on all organizations that receive allocations or assignments of IPv6 address space either directly or indirectly from a Regional IR. This document describes the primary operational policies and guidelines in use by all Regional IRs. Regional IRs may implement supplementary policies and guidelines to meet the specific needs of the Internet communities within their regions. These policies and guidelines are subject to change based upon the development of operational experience and technological innovations, which together emerge as Internet best practice. The structure of this document is as follows: Section 2, "IPv6 Address Space and the Internet Registry System", describes the hierarchical structure of responsible organizations within the Internet Registry system and the explicit goals that determine the framework of policies for allocation and assignment of IPv6 address space. Section 3, "IPv6 Technical Framework", explains the IPv6 addressing format and describes the differences between TLA, NLA, and SLA blocks. Section 4, "Addressing Policies", describes the requirements for applying for a TLA allocation and the policies that apply to such allocations. It discusses how TLA registries can allocate space to other ISPs (NLA blocks) and assign address space to end-users (SLAs). Section 5, "Organizations Operating in More than One Region", describes the requirements for organizations operating in more than one IR region requesting address space. Section 6, "DNS and Reverse Address Mapping", describes the role of the Regional IRs in providing reverse delegation and explains how the Regional IRs can manage subsidiary reverse delegation of allocated/assigned address space. Section 7, "Glossary", provides a listing of terms used in this document along with their definitions. Section 8, "List of References", provides a list of documents referenced in this document. 2 IPv6 ADDRESS SPACE AND THE INTERNET REGISTRY SYSTEM IPv6 unicast addresses are aggregatable with contiguous bit-wise masks used to define routable prefixes, using a method similar to that used for IPv4 addresses under CIDR. With IPv6, scarcity of address space is assumed to no longer exist for the end-user. However, inefficient assignments of address space and rapid expansion of routing tables remain as serious potential impediments to the scalability of the Internet. The Internet Registry system exists to ensure that IPv6 address space is managed in a globally consistent, fair, and responsible manner that minimizes wastage, and maximizes aggregation within the routing structure. 2.1 The Internet Registry System Hierarchy The hierarchical Internet Registry system exists to enable the goals described in this document to be met. In the case of IPv6, this hierarchy consists of the following levels, as seen from the top down: IANA, Regional Internet Registries, TLA, NLA Registries, and end-sites. 2.1.1 IANA The Internet Assigned Numbers Authority (IANA) has authority over all IP number spaces used in the Internet, including IPv6 address space. IANA allocates parts of the IPv6 address space to Regional Internet Registries (Regional IRs) according to their established needs. 2.1.2 Regional Internet Registries Regional IRs operate in large geographical regions such as continents. Currently, three Regional IRs exist: ARIN serving North and South America, the Caribbean, and sub-Saharan Africa; RIPE NCC serving Europe, the Middle East, and parts of Africa; and APNIC serving the Asia Pacific region. These Regional IRs also serve areas beyond their core service areas to ensure that all parts of the globe are covered. Additional Regional IRs may be established in the future, although their number will remain relatively low. Service areas will be of continental dimensions. Regional IRs are established under the authority of the IANA. This requires consensus within the Internet community and among the ISPs of the respective region. 2.1.3 TLA Registries TLA Registries are established under the authority of the appropriate Regional IR to enable "custodianship" of a TLA or sub-TLA block of IPv6 addresses. TLA Registries perform roles and bear responsibilities which are analogous and consistent with those of the Regional IR within their designated network services and infrastructures. 2.1.4 NLA Registries [to be written] 2.1.5 End-sites [to be written] 2.2 Goals of the Internet Registry System The goals described in this section have been formulated by the Internet community with specific reference to IPv6 address space. They reflect the mutual interest of all members of that community in ensuring that the Internet is able to function and grow to the maximum extent possible. It is the responsibility of every IR to ensure that all assignments and allocations of IPv6 address space are consistent with these goals. These goals will occasionally be in conflict with the interests of individual ISPs or end-users. Therefore, IRs evaluating requests for allocations and assignments must carefully analyze all relevant considerations and must seek to balance the needs of individual applicants with the needs of the Internet community as a whole. The policies and guidelines described in this document are intended to help IRs balance these needs in consistent and equitable ways. Full documentation of, and transparency within, the decision making process must also be maintained in order to achieve this result. 2.2.1 Uniqueness Each IPv6 unicast address must be globally unique. This is an absolute requirement for guaranteeing that every host on the Internet can be uniquely identified. 2.2.2 Aggregation IPv6 addresses must be distributed in a hierarchical manner, permitting the aggregation of routing information and limiting the number of routing entries advertised into the Internet. This is necessary to ensure proper operation of Internet routing and to maximize the routing system's ability to meet the demands of both likely and unforeseeable future increases in both size and topological complexity. In IPv6, aggregation of internal and external routes is the primary goal. This goal is motivated by the problems which arose in IPv4 network addressing. IPv4 address allocations have not been sufficiently hierarchical to ensure efficient routing across the Internet. Inefficient use of classful allocations led to an excess of routing entries appearing in the default-free routing table. Furthermore, increased complexity of network topologies led to IPv4 prefixes being announced many times via different routes. Responsible policies and guidelines must limit the number of top level prefixes that are announced on the Internet so as to ensure that the problems of IPv4 are not repeated in IPv6. Such policies and guidelines will always reflect the constraints of current router technology and will be subject to reevaluation as that technology advances. Furthermore, such policies and guidelines will be reviewed according to a model consistent with that provided in RFC 2374 and RFC 2450. Under this model, a threshold is set significantly below the number of default-free routing table entries considered to be currently supportable. If the number of entries reaches that threshold, then allocation criteria are to be reviewed (see section 4.4). 2.2.3 Efficient Address Usage Although IPv6 address resources are abundant, the global Internet community must be careful to avoid repeating the problems that arose in relation to IPv4 addresses. Specifically, even though "conservation" of IPv6 addresses is not a significant concern, registries must implement policies and guidelines that prevent organizations from stockpiling addresses. IPv6 addressing architecture allows considerable flexibility for end-users; however, all registries must avoid wasteful use of TLA and NLA address space by ensuring that allocations and assignments are made efficiently and based on demonstrated need. 2.2.4 Registration Every assignment and allocation of IPv6 Internet address space must be registered in a publicly accessible database. This is necessary to ensure uniqueness and to provide information for Internet trouble shooting at all levels. It also reflects the expectation of the Internet community that all custodians of public resources, such as public address space, should be identifiable. As is the case with IPv4 addresses, each of the Regional IRs will maintain a public database where all IPv6 allocations and assignments are entered. 3. IPv6 TECHNICAL FRAMEWORK 3.1 IPv6 Addressing Hierarchy RFC 2374 specifies that aggregatable addresses are organized into a topological hierarchy, consisting of a public topology, a site topology, and interface identifiers. These in turn map to the following: | 3| 13 | 8 | 24 | 16 | 64 bits | +--+-----+---+--------+--------+----------------------------+ |FP| TLA |RES| NLA | SLA | Interface ID | | | ID | | ID | ID | | +--+-----+---+--------+--------+----------------------------+ |-- public topology---| site | Interface | | |topology| | +---------------------+--------+----------------------------+ | | | |-------- network portion----->+<-----host portion----------| | /64 | |-----------------------------------------------------------| The site topology is represented by a /48, giving each site 16 bits to create their local topology. The host portion is represented by the last 64 bits of the address. A /64 is the minimum network prefix that can be assigned within a site. Additional subnets would require assignment of additional prefixes of the same size or shorter. Because all interface IDs are required to be in the EUI-64 format (as specified in RFC 2373 and RFC 2374) the boundary between the network and host portions is "hard" and ID address space cannot be further sub-divided. Also, in order to facilitate multihoming, the boundary between the public topology and the site topology division at the /48 is also hard. (RFC 2374 explains this more completely.) 3.2 Initial IPv6 Addressing Hierarchy A modified version of the addressing hierarchy described in section 3.1 will be used for the initial IPv6 allocations. The first TLA prefix (TLA 0x0001) has been divided into further blocks, called "sub-TLAs", with a 13-bit sub-TLA identifier. Part of the reserved space and the NLA space have been used for this purpose. This modified addressing hierarchy has the following format and prefix boundaries: Format boundaries | 3| 13 | 13 | 6 | 13 | 16 | 64 bits | +--+----------+---------+---+--------+--------+--------------------+ |FP| TLA | sub-TLA |Res| NLA | SLA | Interface ID | | | ID | | | ID | ID | | +--+----------+---------+---+--------+--------+--------------------+ Prefix boundaries (starting at bit 0) number of the number of the ID left-most right-most longest length bit bit prefix (in bits) ************ ************ ******* ******** TLA ID 3 15 /16 13 sub-TLA ID 16 28 /29 13 Reserved 29 34 NLA ID 35 47 /48 13 SLA ID 48 63 /64 16 For purposes of a "slow start" of a sub-TLA, the first allocation to a TLA Registry will be a /35 block (representing 13 bits of NLA space). The Regional IR making the allocation will reserve an additional six bits for the sub-TLA registry. When the TLA Registry has fully used the first /35 block, the Regional IR will use the reserved space to make subsequent allocations (see section 4.2.5). All router interfaces are required to have at least one link-local unicast address or site-local address. It is recommended that site-local addresses be used for all point-to-point links, loopback addresses, and so forth. As these are not required to be visible outside the site's network, they do not require public address space. Any global unicast address space assigned must not be used for link-local or site-local purposes as there is address space reserved for these purposes. (Note that "all 1s" and "all 0s" are valid unless specifically excluded through reservation. See list of reserved addresses in RFC 2373.) 4. ADDRESSING POLICIES As described above, Regional IRs make IPv6 allocations to requesting organizations that qualify for a sub-TLA (TLA Registries). TLA Registries then allocate NLA space to ISPs that are their customers (NLA Registries). NLA Registries in turn assign SLA space to end-users. TLA Registries may also assign SLA space directly to end-users. TLA Registries and NLA Registries also use SLA space to address their own networks. This hierarchical structure of allocations and assignments is designed to maximize the aggregation of routing information. 4.1 IPv6 Addresses not to be considered property All allocations and assignments of IPv6 address space are made on the basis that the holder of the address space is not to be considered the "owner" of the address space, and that all such allocations and assignments always remain subject to the current policies and guidelines described in this document. Holders of address space may potentially be required, at some time in the future, to return their address space and renumber their networks in accordance with the consensus of the Internet community in ensuring that the goals of aggregation and efficiency continue to be met. 4.1.1 Terms of allocations and assignments to be specified At the time of making any allocation or assignment of IPv6 address space, Registries should specify the terms upon which the address space is to be held and the procedures for reviewing those terms in the future. Such terms and procedures should be consistent with the policies and guidelines described in this document. 4.2 Allocations In order to meet the goal of aggregation (section 2.2.2) Regional IRs will only allocate sub-TLA address space to organizations that meet the criteria specified in one or more of the following sections: 4.2.1 "General Criteria for Initial Sub-TLA Allocation" and 4.2.2 "Criteria for sub-TLA Allocations in Transitional 'Bootstrap' Phase". The criteria for an initial allocation to an organization are different from the criteria that apply for subsequent allocations. Whereas the requirements for an initial allocation are based on technical considerations, requests for additional address space are evaluated solely on the basis of the usage rate of the initial allocation. The following criteria for sub-TLA allocations reflect the intentions of the authors of the IPv6 addressing architecture (see RFC 2374, RFC 2373, and RFC 2950), namely that addressing policies must promote the goal of aggregation. The basis of these criteria is that it is primarily the organizations acting as transit providers or exchange points that will be involved in the top-level routing hierarchy and that other Service Providers should receive NLA address space from these organizations. 4.2.1 General Criteria for Initial Sub-TLA Allocation Subject to sections 4.2.2, and 4.2.3, Regional IRs will only make an initial allocation of sub-TLA address space to organizations that meet criterion (a) AND at least one part of criterion (b), as follows: a. The requesting organization's IPv6 network must have BGP peering relationships with the IPv6 networks of at least three other organizations that have a sub-TLA allocated to them. AND either b(i). The requesting organization must have reassigned IPv6 addresses received from its upstream provider or providers to [X*: range=30-50] SLA customer sites with routed networks connected by permanent or semi-permanent links. OR b(ii). The requesting organization must demonstrate a clear intent to provide IPv6 service within [X*: range=6-12] months after receiving allocated address space. This must be substantiated by such documents as an engineering plan or deployment plan. 4.2.2 Criteria for sub-TLA Allocations in Transitional "Bootstrap" Phase By requiring BGP peering relationships with at least three other IPv6 networks, section 4.2.1 creates a problem during the initial period of transition to IPv6 network addressing, namely that too few organizations will meet the general criteria during this phase (referred to as the "bootstrap phase"). The criteria in this section provide an interim mechanism for eligibility that will only apply during the bootstrap phase, that is until the number of organizations operating IPv6 networks is considered sufficient for the general criteria to operate. (See section 4.2.2.1 "Duration of Bootstrap Phase".) Notwithstanding section 4.2.1, during the bootstrap phase, Regional IRs will make an initial allocation of sub-TLA address space to organizations that meet criterion (a) AND criterion (b) AND either criterion (c) OR criterion (d). a. The requesting organization's network must have BGP peering relationships with at least three other public Autonomous Systems in the default-free zone. AND b. The requesting organization must show that it plans to provide production IPv6 service within [X*: range=6-12] months after receiving allocated address space. This must be substantiated by such documents as an engineering plan or a deployment plan. AND either c. The requesting organization must be an IPv4 transit provider and must show that it already has issued IPv4 address space to [X*: range=30-50] customer sites that can meet the criteria for a /48 IPv6 assignment. In this case, the organization must have an up-to-date routing policy registered in one of the databases of the Internet Routing Registry, which the Regional IR may verify by checking the routing table information on one of the public looking glass sites). OR d. The requesting organization must demonstrate that it has experience with IPv6 through active use of a pseudo-TLA (pTLA) registered to it for at least six months prior to requesting a sub-TLA. The regional IRs may require documentation of acceptable 6Bone routing policies and practice from the requesting organization. 4.2.2.1 Duration of Bootstrap Phase The eligibility criteria in this section will only apply until 100 requesting organizations have received allocations of sub-TLA address space, provided that no more than 60 of these organizations are located in one Regional IR's region. After this threshold has been reached, the bootstrap phase will be considered to be over and Regional IRs will only make allocations to organizations that meet the general criteria in section 4.2.1. If 60 organizations have been allocated sub-TLAs within one region (but less than 100 have been allocated worldwide) then the bootstrap phase within that region will be considered to be over. Additional applications from that region must satisfy the general criteria in section 4.2.1, while applications from other regions need only satisfy the bootstrap criteria. When 100 sub-TLA registries are formed worldwide, there will be enough choices for new prospective sub-TLAs to find others to connect to and the bootstrap phase can end. The regional limitation on bootstrapping is intended to prevent one region consuming all available bootstrap opportunities before IPv6 deployment has started in other regions. 4.2.3 Special considerations 4.2.3.1 Exchange Points It is expected that some exchange points will play a new role in IPv6, by acting as a sub-TLA registry for ISPs that connect to the exchange point. Because there is little information available about such exchange points and how they will operate, they have not been considered during development of sub-TLA eligibility criteria. As these exchange points are established, the Regional IRs will evaluate whether special criteria are required. It is expected that the Regional IRs will request from the exchange point information about the nature of the contracts they enter with the ISPs seeking IPv6 address space. 4.2.3.2 Multihomed Sites [to be written] 4.2.4 Size for Initial Allocation: "Slow-Start" Mechanism Regional IRs will adopt a "slow start" mechanism when making initial allocations of sub-TLA space to eligible organizations. By this mechanism, the initial allocation will allow 13 bits worth of NLA IDs to be used by the organization unless the requesting organization submits documentation to the Regional IR to justify an exception based on topological grounds. This initial allocation allows the organization to create a hierarchy within the allocation depending on their customer type (ISP or end-site) and the topology of their own network. For example, an organization may receive 8,192 SLAs (a /48 each). (See section 4.3 for policies relating to assignments.) The slow-start mechanism for sub-TLA allocations is important to the development of IPv6 addressing hierarchies for several reasons. One significant reason is that it allows the Regional IRs to set relatively low entrance criteria for organizations seeking a sub-TLA allocation. This makes the process fair to all organizations requesting sub-TLA space by giving everybody the same (relatively small) amount and basing future allocations on track record. Furthermore, the effect of this process will be to create a range of different prefix lengths which, in the event that routing table growth requires it, will allow the ISP industry to make rational decisions about which routes to filter. Another important reason for adopting the slow-start mechanism is to allow Regional IRs to maintain contact with TLA Registries as they develop, thereby providing a level of support and training that will help ensure that policies and practices are implemented consistently. Without a slow start mechanism, TLA Registries receiving large initial allocations may not have formal contact with the Regional IR for several years. The slow-start mechanism helps Regional IRs to meet the goals of registration and efficiency, by providing a process that enables them to monitor whether the TLA Registries are properly registering assignments in the database and correctly applying the policies for NLA and SLA assignments contained in this document. 4.2.5 Criteria for Subsequent Sub-TLA Allocations Regional IRs will not make subsequent allocations of sub-TLA address space to a TLA Registry unless the TLA Registry has used at least 80 percent of its previously allocated address space. In this context, the address space is considered to be "used" if the TLA Registry has made all of its allocations and assignments of that address space in accordance with the policies and guidelines specified in this document. The size of the subsequent allocation depends on the demonstrated usage rate of the previous allocation. 4.2.5.1 Contiguous allocations The subsequent allocation will be contiguous with the previously allocated range to allow for aggregation of routing information. When a Regional IR makes an initial allocation to TLA Registry, it will reserve the full sub-TLA from which this allocation was made. Subsequent allocations to that TLA Registry will be made from the reserved sub-TLA. If no further growth is possible within that sub-TLA range, the Regional IR may allocate a full TLA. (Note, this practice may eventually lead to a situation in which no empty sub-TLAs are available, but the existing sub-TLAs are not fully utilised. If this occurs, then the provisions of section 4.4 will apply.) 4.2.6 Registering and Verifying Usage Each TLA Registry is responsible for the usage of the sub-TLA address space it receives and must register all end-site assignments and ISP allocations in the database of the Regional IR in its region. The Regional IR may verify whether all assignments are registered in the database. In addition to the database entries, the Regional IR may ask for periodic reports specifying how the addresses are being used. Registered end-sites must be connected and reachable. To verify this, the relevant Regional IR is entitled to ping /48s within end-sites. Filtering holes should be negotiated by the Regional IR and the organization holding the addresses in question. Therefore, it is suggested that end-sites use anycast cluster addresses on their border routers to enable this. It is expected that one /48 SLA block is enough address space per end-site. If an end-site requests an additional SLA, the TLA Registry must send the request to the Regional IR for a second opinion. 4.2.7 Renumbering It is possible that circumstances could arise whereby sub-TLA address space becomes scarce. This could occur, for example, due to inefficient use of assigned address space, or to an increase in the number of organizations holding both TLA and sub-TLA space. If such circumstances arise, it may be necessary for Regional IRs to require that previously allocated address space be renumbered into different ranges. If a Regional IR requires a TLA Registry to renumber its own network, this will also have an impact on all of its customers' networks. Therefore, it is recommended that TLA Registries and NLA Registries enter contractual arrangements with their customers at the time of the first allocation or assignment. Such arrangements should clarify that the address space might have to be returned, requiring all end-sites to be renumbered. If renumbering is required, then TLA Registries should inform their customers as soon as possible. Regional IRs requiring a TLA Registry to renumber will allow that Registry at least[X*: 12-24] months to return the sub-TLA space. [Note that the granted renumbering time may depend on the prefix length returned. The draft document <http://search.ietf.org/internet-drafts/draft-ietf-ipngwg-router-renum-0 8.txt> describes the issues involved in and methods used for renumbering IPv6 networks.] [Note that site-local addresses are not affected by renumbering the global unicast IPv6 addresses.] 4.2.8 Allocations to NLA Registries TLA Registries with ISP customers may use their 13 bits of NLA address space to create an addressing hierarchy for those ISPs. Each of the TLA Registry's own end-user organizations would receive a /48 (see section 4.3); however, the ISP customers (NLA Registries) could be "allocated" additional bits in order to aggregate the ISP's customers internally. A slow-start mechanism will be used for these NLA allocations. The NLA block is an allocation to the NLA Registry and not an assignment. Therefore, if the NLA Registry does not use it fully within a certain period of time, [X* time to be specified here?] the TLA Registry may require it to be returned. Once an NLA Registry has assigned at least 80 percent of its allocation, it may request an additional block from the TLA Registry. This block can be any size, depending on the NLA Registry's usage rate for its first block. A TLA Registry receiving a request for subsequent NLA allocations must submit the request to the relevant Regional IR for a second opinion. Each NLA allocation must be registered in the Regional IR's database. All end-user assignments must also be registered in the Regional IR's database. The same procedures for these end-user assignments apply for the end-user assignments made by the TLA Registry to their customers directly. Ultimately, the TLA Registry is responsible for management of all address space it allocates and should, therefore, appropriately monitor all assignments made by the NLA Registries to which it allocates. The Regional IR can at any time ask for additional information about the allocations and assignments being made. 4.3 Assignments 4.3.1 Assignments to End-users The minimum assignment to end-user organizations that have a need to create subnets in their network is a /48 (80 bits of address space). Within this /48, 16 bits are an SLA block used for subnetting and further 64 bits are used per interface. TLA Registries must submit all requests they receive for additional assignments to the relevant Regional IR for evaluation (a "second opinion"). All such requests must document the full use of the initial SLA and must be accompanied by an engineering plan justifying the need for additional address space. Dial-up lines are considered part of an ISP's infrastructure and, therefore, addresses for such purposes should be assigned from the SLA block of that ISP. It is expected that longer prefixes be used for non-permanent, single-user connections. 4.4 Reclamation Methods/Conditions Allocations are valid only as long as the criteria for allocations continue to be met. Consistent with the goal of aggregation described in section 2.2.2, the criteria for allocations may be reviewed with regard to current routing technology. The current threshold point for reviewing the allocation criteria is [X*: range=4,000-8,000] default-free entries in the global routing table. If this threshold is reached and current routing technology then allows additional route entries, the number of possible TLAs and sub-TLAs may be increased accordingly. However, if the limit is reached current routing technology then is not able to support additional routing entries, all allocations made up to that point will be reviewed. TLA Registries with a very low usage rate [X*: to be defined] or that do not meet the new criteria may have their sub-TLA space revoked. These Registries will be required to renumber their networks and return their previous allocation within a maximum of [X*: range=6-12] months. During the period that routing technology is being investigated, the Regional IRs will continue allocating address space even if the number of "possible" routes are reached. 5. ORGANIZATIONS OPERATING IN MORE THAN ONE REGION Organizations requesting sub-TLA space that operate in more than one region, and that need separate sub-TLA blocks for routing purposes, may request the address space from more than one of the Regional IRs, provided that the organization's networks meet the criteria for allocation of sub-TLA address space in each of the relevant regions. 6. DNS AND REVERSE ADDRESS MAPPING [To be written..] 7. GLOSSARY Allocation - The provision of IP address space to ISPs that reassign their address space to customers. Assignment - The provision of IP address space to end-user organizations. End-user - An organization receiving reassignments of IPv6 addresses exclusively for use in operational networks. Interface Identifiers - A 64-bit IPv6 unicast address identifier that identifies an interface on a link. NLA ID - Next-Level Aggregation Identifier. NLA Registry - Internet Service Providers receiving IPv6 address allocations from a TLA Registry. Public Topology - The collection of providers and exchanges who provide public Internet transit service. Regional Internet Registries - Organizations operating in large geographical regions such as continents which are responsible for fair distribution of globally unique Internet address space and for documenting address space allocation and assignment. Site - A location, physical or virtual, with a network backbone connecting various network equipment and systems together. There is no limit to the physical size or scope of a site. Site Topology - A local, specific site or organization which does not provide public transit service to nodes outside the site. SLA ID - Site-Level Aggregation Identifier. Slow Start - The efficient means by which addresses are allocated to TLA Registries and to NLA ISPs. This method involves issuing small address blocks until the provider can show an immediate requirement for larger blocks. TLA ID - Top-Level Aggregation Identifier. TLA Registry - Organizations receiving TLA/sub-TLA ID from Regional IRs to reassign to customers. Unicast - An identifier for a single interface. A packet sent to a unicast address is delivered to the interface identified by that address. Note that the definition of an IPv4 host is different from an IPv6 identifier. One physical host may have many interfaces, and therefore many IPv6 identifiers. 8. LIST OF REFERENCES

1 0