- ipv6-wg - mailman.ripe.net

IPv6 Assignment and Allocation Policy Document
by Paula Caslav 02 Mar '99

02 Mar '99

Hello all, This is a draft version of the IPv6 assignment guidelines that we have been working on with the other Regional Registries. We would like your feedback on this at the RIPE meeting, and on this mailing list. The other Registries are now also discussing this with their communities. Please note that when refering to the global adressing authority, we use the name IANA in this draft for now, but we will update this as soon as the ICANN developments progress. Kind regards, Paula Caslav RIPE NCC - --------------------begin included draft---------------------------- IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft) 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 Allocations 4.2 Assignments 4.3 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 the distribution of globally unique IPv6 address space, which follows a hierarchical distribution as it does with IPv4. The distribution of IPv6 address space is managed by the IANA (formerly IANA) and further delegated by the Regional Internet Registries (IRs) as described in RFC 1881. The Regional IRs assign Top-Level Aggregation Identifiers (TLAs) to organizations, which in turn assign address space to other Internet Service Providers (ISPs) and end users. This document describes the policies and procedures associated with IPv6 address space management that must be followed by the organizations that hold Top-Level Aggregate IDs. Since ISPs essentially will be serving as NLA Registries for their customers, creating additional "layers" to the Registry system, it is crucial that responsibilities, procedures, and policies are well understood and consistently applied. 1. SCOPE This document first describes the global Internet Registry system for the distribution of globally unique unicast IPv6 address space, as defined in RFC 2374, and its operation, then describes the rules and guidelines governing the distribution of this address space. The rules set forth in this document are binding for all organizations that have IPv6 address space allocated and assigned via a Regional IR. This document does not describe private IPv6 address space, or anycast and multicast address space distribution. It also does not describe regional and local refinements of the global rules and guidelines. This document serves as the base set of operational guidelines in use by all Regional IRs. Additional guidelines may be imposed by a particular Regional IR as appropriate. As experience is gained in allocating IPv6 addresses, these rules and guidelines may change. The remaining sections of this document are presented as follows: Section 2, IPv6 Address Space and the Internet Registry System, explains the goals used in assigning IPv6 addresses and outlines the hierarchical structure of the responsible Internet Registry system organizations used to achieve those goals. Section 3, IPv6 Technical Framework, explains the IPv6 addressing format and outlines the difference between a TLA, NLA, and SLA block. 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 end-users (SLAs). Section 5, Organizations Operating in More than One Region, describes the process for requesting address space for organizations operating in more than one IR region. 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 similar to IPv4 addresses under CIDR. With IPv6, scarcity of address space is assumed to no longer exist for the end-user. However, routing table explosion and the efficient assignment of address space are still of great concern. Thus, aggregation and efficiency (conservation) of prefix allocations are explicit goals of the Internet registry system. 2.1 The Internet Registry System Hierarchy In order to achieve the goals of the Internet Registry system, a hierarchy was established which consists of the following levels as seen from the top down: IANA, Regional Internet Registries, and TLA Registries. 2.1.1 IANA The Internet Corporation for Assigned Names and Numbers (IANA) has authority over all number spaces used in the Internet, including IPv6 address space. IANA allocates parts of the IPv6 address space to Regional Internet Registries (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 are established: ARIN serving North and South America, the Caribbean, and sub-Saharan Africa; RIPE NCC serving Europe, the Middle East, and parts of Asia and Africa; and APNIC serving Asia and Pacific regions. These regional IRs also serve areas beyond their core service areas to ensure that all regions around the globe are covered. Additional Regional IRs may be established in the future, but it is expected that the number of Regional IRs will remain relatively small. Service areas will be of continental dimensions. Regional IRs are established under the authority of the IANA. This requires consensus within the Internet community of the region and may require consensus of ISPs in that region. 2.1.3 TLA Registries TLA Registries are established under the authority of the Regional IR. These Registries have the same roles and responsibilities as a Regional IR within their designated service areas. 2.2 Goals of the Internet Registry System The remainder of this document is primarily concerned with the management of public IPv6 address space. Every assignment of IPv6 addresses should be made with the following goals in mind for it is in the interest of the Internet community as a whole that these goals be pursued. It is worth noting that "conservation" and "aggregation" are often conflicting goals, and therefore each assignment must be evaluated carefully. Moreover, these goals may occasionally be in conflict with the interests of individual end users or ISPs. In such cases, careful analysis and judgement are necessary to find an appropriate compromise. The rules and guidelines in this document are intended to help Regional IRs, ISPs, and end-users in their search for effective solutions. 2.2.1 Uniqueness Each public IPv6 address worldwide must be unique. This is an absolute requirement which guarantees that every host on the Internet can be uniquely identified. 2.2.2 Aggregation Public IPv6 addresses are distributed in a hierarchical manner, permitting the aggregation of routing information. This is necessary to ensure proper operation of Internet routing. IPv4 addresses were not as hierarchical as needed for efficient routing across the Internet. Problems arose in IPv4 network addresses with classful allocations and inefficient use of them. This led to too many routing entries appearing in the default-free core of the Internet. To overcome this problem, the number of global routes must be limited according to technical restrictions. These technical constraints will have to be reevaluated as router technology changes. Until new paramaters are defined, however, the policies described in this document will remain valid. 2.2.3 Conservation Although IPv6 network address resources appear to be endless, care must be taken to avoid repetition of the IPv4 problems and instead focus on demonstrated need. These precautions will help manage and conserve IPv6 network addresses for future use. In order to mitigate this problem in use of IPv6, conservation is one of the main goals. It should be noted however, that the IPv6 addressing architecture allows end-sites a great amount of flexibility. Eighty bits out of a total of 128 bits available in an IPv6 address are used for addressing an end-site. Address space can be conserved only by carefully evaluating the requirements from TLAs and NLAs and allocating address space on the basis of demonstrated need. Experience has shown that the growth and the consequences of growth were never anticipated with IPv4. The Regional IRs will apply the lessons from the IPv4 experience to ensure that conservative policies are implemented from the beginning. 2.2.4 Registration In response to the rapid growth of Internet activity, a public registry system was established to document address space allocation and assignment. This was necessary to ensure uniqueness of Internet addresses and to provide information for Internet trouble-shooting at all levels. As with IPv4 addresses, each of the Regional IRs maintains a public database where all IPv6 assignments and reassignments are entered so that network operators can identify other network organizations. 3. IPv6 TECHNICAL FRAMEWORK 3.1 IPv6 Addressing Hierarchy RFC 2373 specifies that aggregatable addresses are organized into a topological hierarchy which consists of a public topology, a site topology, and interface identifiers. These in turn map into 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. Each site has a potential for 65,535 subnets as specified in RFC 2374. The network portion is represented by the first 64 bits. 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 additional prefixes of the same size or shorter to be assigned. Note that the boundaries are "hard" between the network and host portions and that the ID address space cannot be further sub-divided as all interface ID's are required to be in the EUI-64 format as per RFC 2373/4. The boundaries are also hard between the public topology and the site topology division at the /48. The technical motivation for this is given in RFC 2374 in order to facilitate multi-homing. In IPv6, the following prefix boundaries are suggested: number of the number of the ID left-most right-most longest length bit boundary bit boundary prefix (in bits) ************ ************ ******* ******** TLA ID 4 16 /16 13 Reserved 17 24 N/A 8 NLA ID 25 48 /48 24 SLA ID 49 64 /64 16 3.2 Initial IPv6 Addressing Hierarchy A slightly modified version of the above (a special case of TLA 0x0001) derives a sub-TLA portion from principally the reserved address space. This has been described in RFC 2450. This has the following format and prefix boundaries: | 3| 13 | 13 | 19 | 16 | 64 bits | +--+----------+---------+---------+--------+--------------------+ |FP| TLA | sub-TLA | NLA | SLA | Interface ID | | | ID | | ID | ID | | +--+----------+---------+---------+--------+--------------------+ For this TLA, this means that there are the following prefix boundaries: number of the number of the ID left-most right-most longest length bit boundary bit boundary prefix (in bits) ************ ************ ******* ******** TLA ID 4 16 /16 13 sub-TLA ID 17 29 /29 13 NLA ID 30 48 /48 19 SLA ID 49 64 /64 16 For purposes of a slow start of a sub-TLA, however, a first sub-TLA allocation would actually always be a /35 block (13 bits instead of 19). All router interfaces are required to have at least one link-local unicast address or site-local address. Site-local will 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 the link-local or site-local purpose as there is reserved address space for these addresses. (Note that all 1's and all 0's are valid unless specifically excluded through reservation. See list of reserved addresses in RFC 2373.) 4. ADDRESSING POLICIES 4.1 Allocations Regional IRs make allocations to requesting organizations that qualify for a sub-TLA. Those organizations further allocate NLA space to ISP customers who in turn assign SLA space to end-sites. Sub-TLA holders can also assign SLA space directly to end-users, and sub-TLA and NLA holders will use SLA space to address their own networks. This hierarchical allocation structure allows aggregation of routing information. 4.1.1 Requirements for Allocating a Sub-TLA In order to meet the conservation and aggregation goals discussed above, only requesting organizations that meet certain requirements will be allocated sub-TLA space. The requirements for an initial allocation to an organization are different from the requirements that have to be met once the initial allocation has been used and additional address space is requested. Whereas the requirements for an initial allocation are based on technical considerations, all additional address space is purely based on the utilization of the initial allocation. In order to meet the aggregation goal, requests for an initial allocation of a sub-TLA have to be carefully evaluated. It is not necessary for every requesting organization to obtain sub-TLA space. The following requirements must be met in order to obtain an initial allocation of sub-TLA address space: The requesting organization's IPv6 network must be interconnected with the IPv6 networks of at least three other organizations that have a sub-TLA allocated to them, and either: -- The requesting organization must have reassigned IPv6 addresses received from its upstream provider or providers to 100 SLA customer sites with routed networks. Dial-in customers do not count toward the 100 IPv6 customer sites. Customers currently using IPv4 host addresses for dial-up should not be assigned an NLA or an SLA, or -- The requesting organization must demonstrate a clear intent to provide IPv6 service within 3 months after receiving allocated address space. This must be substantiated by such documents as an engineering plan or deployment plan. The above criterion that requires interconnection with at least three other sub-TLAs creates a bootstrapping problem which can be resolved by the following requirements that have been defined for a bootstrapping period: The requesting organization's network must have BGP peering relationships with at least three other public Autonomous Systems in default-free zones, The requesting organization must show that it already has issued IPv4 address space to 100 customer sites that can meet the criteria for a /48 IPv6 reassignment, and The requesting organization must demonstrate a clear intent to provide IPv6 service within 3 months after receiving allocated address space. This must be substantiated by such documents as an engineering plan or deployment plan. The first 50 requesting organizations who obtain a sub-TLA must fulfill either the criteria for the bootstrapping or the general criteria. Only 30 out of these 50 networks/organizations can be located in one region. After 50 sub-TLAs have been allocated, the bootstrap criteria will no longer apply. Once 30 organizations have been allocated sub-TLAs within one region, additional applications from that region must satisfy the general criteria, while applications from other regions may only have to satisfy the bootstrap criteria. This is because the first group of registries would not be able to fulfill the first criteria of being connected to three other sub-TLA networks, since there would be few sub-TLA networks at the start. After 50 sub-TLA registries are formed, there will be enough choices for new prospective sub-TLAs to find others to connect to and the bootstrapping phase can end. It has been decided to further limit the amount per region (an area covered by one Regional IR), so that one region will not have an unfair advantage over another. NOTE - Those who qualify for TLA or sub-TLA (whether during bootstrap or later) and who then fail to demonstrate ongoing utilization, will have their allocation revoked (defined further in section 4.3). 4.1.2 Size for Initial Allocation/Slow-Start Mechanism The initial allocation of sub-TLA space will allow 13 bits worth of NLA IDs to be utilized by the organization receiving the /35 reserved from the sub-TLA unless the requesting organization submits documentation to the Regional IR to justify an exception. 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: this allows the organization to receive 8,192 NLAs (a /48 each). The making of assignments (to ISPs or end-sites) is covered in section 4.2 in more detail. The size of the initial allocation has been set to 13 bits because this allows the TLA Registry some freedom in creating an addressing hierarchy. If it has other Service Providers as customers (who in turn have their own end-user customers), this allows the TLA Registry to sub-allocate smaller blocks to each of them. 4.1.3 Requirements for Next Allocation Once an organization has used 80% of the sub-TLA address space, the organization may contact the Regional IR in its region to request that another range of addresses be allocated. The size of the next range depends on the utilization rate of the previous allocation. It must be stressed that it is not enough to have allocated 80% of the sub-TLA address space. The addresses must also be assigned and in use by end-sites. This means that sub-TLA holders must be careful and conservative in their allocations to their ISP customers. Address space must be allocated and assigned based on actual need. Administrative convenience or internal routing table size can not be a reason to allocate or assign additional address space. It is expected that sub-TLA holders also apply a slow-start mechanism as described in section 4.2.2 to their ISP customers. The next allocation may be another range of sub-TLA space with a shorter prefix than the previous one. If growth is no longer possible in the sub-TLA space, it is expected that a full TLA will be allocated. In order to justify a new range of sub-TLA or TLA space, the utilization of the previous allocation must be demonstrated. This is described below. 4.1.3.1 Verification of Utilization All assignments to end-sites must be registered in the database of the Regional IR in the region the sub-TLA holder operates. The TLA Registry is responsible for the utilization of the sub-TLA and the registration of the end-site assignments and ISP allocations in the database. The Regional IR will verify whether all assignments are registered in the database. In addition to the database entries, the Regional IR may ask for periodic reports describing the utilization of the addresses to be sent. It is required that the end-sites be connected and reachable. The Regional IR has the right to ping end-sites' /48s. Filtering holes should be negotiated by the Regional IR and the organization with the addresses. 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 sub-TLA holder must send the request to the Regional IR for a second opinion. The information provided below shows address boundaries and their corresponding amount of address space. a TLA = /16 of address space an NLA = /48 of address space an SLA = /64 of address space TLA block = 13 bits of address space NLA block = 19 bits of address space SLA block = 16 bits of address space 4.1.3.2 Renumbering Once it has been decided to allocate additional TLA space to a sub-TLA holder, the previously allocated sub-TLA must be returned to the Regional IR. The sub-TLA holder must then renumber its own network. This of course has an impact on all of its customers and customers' networks. Therefore, it is recommended that the sub-TLA holder and its ISP customers make contractual arrangements with their customers at the time of the first assignment. These arrangements should clarify that the address space will have to be returned in the event the sub-TLA holder requests a full TLA, in which case, all end-sites must be renumbered. The sub-TLA holder should inform its customers early on regarding the upcoming need to renumber. The sub-TLA will have 3 months to return the sub-TLA space after the next TLA has been allocated. Renumbering in IPv6 is considerably easier than in IPv4. Once the provider has informed its customer about the address range to be used in the future, the customer's network (end-site) will have two sets of addresses for a certain period of time. Hosts learn prefixes from router advertisements. With each prefix, there is a "valid lifetime" and a "preferred lifetime" designation. New sessions should be initiated with the preferred address, but existing ones can continue with the old (valid but not preferred) address. A mechanism called Router Renumbering (RR) allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of Neighbor Discovery and Address Autoconfiguration works for hosts. It provides a means for a network manager to make updates to the prefixes used and advertised by IPv6 routers throughout a site. (M. Crawford, work in progress) Note that site-local addresses are not affected by renumbering the global unicast IPv6 addresses. 4.2 Assignments 4.2.1 Assignments to End-users Every end-user organization receives a /48 worth of address space (80 bits). Out of this, 16 bits are an SLA block used for subnetting and another 64 bits are used per interface. All requests for additional address space from the same TLA Registry must be submitted to the Regional IR for evaluation (a second opinion). In this case the full utilization of the initial SLA must be documented. The need for additional address space must be presented in the form of an engineering plan. Since the SLA part of the end-user's assignment allows for creating 65,536 subnets, the organization must show in what way this was not sufficient for their network, and must present a plan showing where each of the 65,536 subnets is used and why new subnets are necessary. Only end-user organizations with a need to create subnets in their network should be assigned a full /48. Dial-up lines are considered part of the ISP's infrastructure and should be assigned from the SLA of that ISP. 4.2.2 Assignments and Allocations to Other ISPs If the TLA Registry has ISP customers (who in turn have end-users), the TLA Registry could use the 13 bits of NLA address space to create an addressing hierarchy for them. Each of the TLA Registry's own end-users would receive a /48 as specified above, however, the ISP customers (NLAs) 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 would be an allocation to the ISP and not an assignment. Therefore, if the ISP does not fully utilize it in a certain period of time, the range will have to be returned. Also, the sub-TLA organization should be careful about making these sub-allocations because they will get a new sub-TLA only when 80% of their entire sub-TLA block is assigned, not just allocated. Therefore, if they have many sub-allocations that are not fully used, they might ask the ISPs to give back some of the address space to use for other customers. Once an NLA ISP has used up its allocation, it may request an additional block from the TLA Registry. This block can be any size, depending on how quickly it took the ISP to use up its first block. Any additional requests for NLA allocations should be submitted to the Regional IR for a second opinion. Each NLA allocation must be registered in the Regional IR database. All end-user assignments must also be registered in the Regional IR database. The same procedures for these end-user assignments apply for the end-user assignments made by the TLA Registry to their customers directly. In the end, the TLA Registry is responsible for how the address space is handled and should have an overview of all the assignments being made by the NLA Service Providers. TLA Registries will not be permitted to assign static IPv6 addresses to dial-up customers. The Regional IR can at any time ask for additional information about the allocations and assignments being made (see /draft-ietf-dhc-dhcpv6-13.txt). 4.3 Reclamation Methods/Conditions Allocations are valid only as long as the original criteria are still met. The criteria for allocating TLA address space may change over time depending on routing technology. The current target is to limit the global routing space to roughly 8,000 entries. If 50% of this limit is reached, routing technology and allocation criteria will be reviewed. If routing technology allows additional route entries, the number of possible TLAs and sub-TLAs may be increased. If it turns out that routing technology at that time does not allow additional routing entries, the allocations made up to that point will be reviewed. Sub-TLA holders with a very low usage rate (to be defined before publication) or sub-TLA holders that do not meet the new criteria may have their sub-TLA space revoked. These organizations will have to renumber and return the sub-TLA within a maximum of 3 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 If an organization requesting sub-TLA space operates in more than one region, and needs separate sub-TLA blocks for routing purposes, it should request the address space for its entire network from only one of the Regional IRs. It can apply for an initial allocation that is larger than 13 bits if it can show that its network is divided into several components with each needing its own sub-TLA route (each component individually needs to fulfill the criteria for being a TLA Registry). The size of the allocation would depend on how many top-level routes are needed. For example, if a multinational transit provider can show that it needs three top-level routes, it would initially receive 15 bits of NLA space (a /33). It could then allocate a /35 to each of the top-level parts of the network and route each one separately. Each of these sub-allocations would need to be entered in the database of the Regional IR individually. 6. DNS AND REVERSE ADDRESS MAPPING TBD 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 ISP - 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 - --------------------end included draft---------------------------- ------- End of Forwarded Message

2 1

Fw: (ngtrans) I-D ACTION:draft-ietf-ngtrans-natpt-05.txt
by Thomas Trede 26 Feb '99

26 Feb '99

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: ngtrans(a)sunroof.Eng.Sun.COM <ngtrans(a)sunroof.Eng.Sun.COM> Date: Donnerstag, 25. Februar 1999 01:46 Subject: (ngtrans) I-D ACTION:draft-ietf-ngtrans-natpt-05.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 : Network Address Translation - Protocol Translation (NAT-PT] > Author(s) : G. Tsirtsis, P. Srisuresh > Filename : draft-ietf-ngtrans-natpt-05.txt > Pages : 16 > Date : 22-Feb-99 > > This document specifies a transition mechanism in addition to those > already specified in [TRANS]. The new mechanism provides an > end-to-end solution to allow IPv6-only hosts to communicate with > IPv4-only hosts and vice versa using Network Address Translation > and Protocol Translation. The scheme described does not require du- > al-stack hosts; nor does it mandate any routing related changes on > the hosts. The scheme is based on a combination of address transla- > tion theme as described in [NAT-TERM] and V6/V4 protocol transla- > tion theme as described in [SIIT]. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-natpt-05.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-ngtrans-natpt-05.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-natpt-05.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-ngtrans-natpt-05.txt

1 0

It's a small step for TLAs but has huge impact on Stub-ISPs
by Hannes R. Boehm 23 Feb '99

23 Feb '99

Hello, i am concerned about the current draft for IPv6 adress assignment. Specificaly I am worried about the consequences of the aggregateble global unicast address scheme for smaller ISPs. I see the following problems for non-TLA "Users" which run a Multihomed environment: (Please correct me or point me to the corresponding documents) 1) Multihoming does not reward you with more stability anymore Since each Interface gets two or more IPv6 addresses, a existing TCP connection breaks if the Line on which the packets come in goes down. Of course this could be solved with a new version of TCP, but if you look at the time it took to develop IPv6 this is in the very distant future (not including the time it takes for deployment) (I guess it's the same with UDP - once a programm has choosen a destination IP address, it uses it for the whole transaction - if the link fails, the transaction stops ) AND: If the DNS still announces the TLA-1::SLA: Addresses when the Line to TLA-1 is down, then some connections fail even if the Path via TLA-2 is still up and running. -> so: there must be a probing of the connection !within! the application I fear that the loss of topology information with the TLA scheme will introduce more problems than those which are obvious at first sight. 2) Load balancing gets harder If a station outside your domain opens a connection to the address TLA-1::Interface you cant decide which line the incoming traffic should go. It should be possible to do a weighted DNS round robin to decide which prefix is prepended to the SLA:IntID. But with DNS caching this is only a very unprecise tool. I did not find any documents addressing these problems. Are there any ? Or did only those ISPs that do qualify for TLA assignments write those drafts ;-) ? with kind regards Hannes -- -------------------------------------------------------------------- | Hannes R. Boehm debis Systemhaus EDVg | | Network Engineer Hofmuehlgasse 3-5 | | hannes.boehm(a)debis.at 1060 Wien | | AUSTRIA | --------------------------------------------------------------------

2 1

IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft)
by David Kessens 23 Feb '99

23 Feb '99

Hi, Included below are the comments from the IAB on the 'IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft)'. I personnally think that the IAB's comments are pretty close to the suggestions that the wg decided on during the RIPE IPv6 wg session in Amsterdam. I welcome your input, including endorsements of the changes suggested by the IAB. David K. --- Forwarded message: > From brian(a)hursley.ibm.com Mon Feb 15 04:57:10 1999 > Message-ID: <36C7EE30.3A84DFB3(a)hursley.ibm.com> > Date: Mon, 15 Feb 1999 09:51:44 +0000 > From: Brian E Carpenter <brian(a)hursley.ibm.com> > Organization: IBM Internet Division > X-Mailer: Mozilla 4.04 [en] (Win95; I) > MIME-Version: 1.0 > To: Daniel.Karrenberg(a)ripe.net, Mirjam Kuehne <mir(a)ripe.net>, kimh(a)arin.net, > Anne Lord <anne(a)apnic.net>, pwilson(a)apnic.net > CC: IAB <iab(a)iab.org> > Subject: Re IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft) > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > Dear colleagues, > > Re IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft) > > The IAB has been looking at this draft and here are our comments > (which are not confidential in any way). > > It's very good to see the registries working actively on this > important topic. However there are two points of concern about > the current version, one political and one technical. > > The political one is easy to fix. Referring to ICANN is contentious > in this context, and referring to IANA is not contentious. > So please replace all reference to ICANN by IANA. It doesn't > change anything but it will reduce argument. > > The technical one is more tricky. Basically the draft errs too > much on the side of address conservation. While it is important > to be prudent and to avoid creating an IPv6 toxic waste dump, > we do have a lot more freedom than with IPv4. The draft doesn't > take full advantage of this, with the paradoxical effect that > aggregation is harmed and unnecessary renumbering is forced. > We can afford to be more generous with subTLA space and less > restrictive with slow start. The detailed comments below almost > all relate to this point. > > > > > IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft) > ... > > > > > > ABSTRACT > > > > > > This document describes the registry system for the distribution of > > > globally unique IPv6 address space, which follows a hierarchical > > > distribution as it does with IPv4. The distribution of IPv6 address > > > space is managed by the IANA (formerly IANA) and further delegated by > > ...space is managed by the IANA and... > > (it is managed by IANA and only by IANA.) > > ... > > > This document does not describe private IPv6 address space, or anycast > > There is no such thing as private IPv6 address space. There > are site-local and link-local IPv6 addresses defined architecturally. > > ... > > > 2.1.1 IANA > > > > > > The Internet Corporation for Assigned Names and Numbers (IANA) has > > Remove all mention of ICANN which is a red rag to many bulls. > The Authority lies with IANA. > > > > authority over all number spaces used in the Internet, including IPv6 > > > address space. IANA allocates parts of the IPv6 address space to > > > Regional Internet Registries (IRs) according to their established > > > needs. > > ... > > > 2.2 Goals of the Internet Registry System > > > > > > The remainder of this document is primarily concerned with the > > > management of public IPv6 address space. Every assignment of IPv6 > > > addresses should be made with the following goals in mind for it is in > > > the interest of the Internet community as a whole that these goals be > > > pursued. It is worth noting that "conservation" and "aggregation" are > > > often conflicting goals, and therefore each assignment must be > > > evaluated carefully. > > This is IPv4 thinking. Aggregation is what matters for IPv6. > Conservation is not a major goal; avoidance of profligacy is > the goal, which is much weaker. Suggested rewrite of the > last sentence: > > Each assignment must be evaluated carefully to ensure good > aggregation without being profligate with address usage. > > > > Moreover, these goals may occasionally be in > > > conflict with the interests of individual end users or ISPs. > > They will be in conflict. Suggested rewrite: > > In the case of IPv4, the necessary heavy emphasis on address > conservation, and the attempt to retrofit aggregation, have > combined to cause frequent conflict betwen the interests > of end users and smaller ISPs with those of the network as > a whole. It has also favoured the use of private address > space with its unfortunate architectural side effects. > IPv6 allows this conflict to be avoided in future. > > > > In such > > > cases, careful analysis and judgement are necessary to find an > > > appropriate compromise. > > Delete this sentence; this compromise is not needed for v6. > > ... > > > 2.2.3 Conservation > > The word "Conservation" should be replaced by "Avoidance of > profligacy" in the title and everywhere else. Don't misunderstand > this as being against conservation: but this draft goes overboard. > > ... > > > For purposes of a slow start of a sub-TLA, however, a first sub-TLA > > > allocation would actually always be a /35 block (13 bits instead of > > > 19). > > There is no need to slow-start sub-TLAs; in fact it makes no sense. > A sub-TLA is always going to be allocated to a single operator; > backbone ISPs will certainly not want to see /35 announcements - > We expect they will filter anything longer than /29. > > Sub-TLAs should be fully allocated. (To put it another way, Sub-TLAs > *are* the slow-start mechanism.) > > ... > > > 4.1.1 Requirements for Allocating a Sub-TLA > > > > > > In order to meet the conservation and aggregation goals discussed > > > above, only requesting organizations that meet certain requirements > > > will be allocated sub-TLA space. The requirements for an initial > > > allocation to an organization are different from the requirements that > > > have to be met once the initial allocation has been used and > > > additional address space is requested. > > > > > > Whereas the requirements for an initial allocation are based on > > > technical considerations, all additional address space is purely based > > > on the utilization of the initial allocation. In order to meet the > > > aggregation goal, requests for an initial allocation of a sub-TLA have > > > to be carefully evaluated. It is not necessary for every requesting > > > organization to obtain sub-TLA space. The following requirements must > > > be met in order to obtain an initial allocation of sub-TLA address > > > space: > > > > > > The requesting organization's IPv6 network must be interconnected with > > > the IPv6 networks of at least three other organizations that have a > > > sub-TLA allocated to them, and either: > > > > > > -- The requesting organization must have reassigned IPv6 > > > addresses received from its upstream provider or providers > > > to 100 SLA customer sites with routed networks. Dial-in > > > customers do not count toward the 100 IPv6 customer sites. > > This is far too high a bar for at least three reasons > > 1. nobody can meet it during the early stages of IPv6 deployment > 2. there are many examples of non-profit networks, and certainly some > for-profit networks, that do not achieve this scale, but must have > at least a sub-TLA to avoid horrendous aggregation problems due to > multihoming. This guideline definitely hurts aggregation. > 3. this criterion also makes it very unlikely that metropolitan > internet exchanges would qualify, yet metro exchanges are > prime candidates for TLA or sub-TLA allocation (again to > enable multihoming). > > We suggest reducing the 100 to 10. > > > > Customers currently using IPv4 host addresses for dial-up > > > should not be assigned an NLA or an SLA, or > > > This seems redundant and gratuitous. > > > > > > -- The requesting organization must demonstrate a clear intent > > > to provide IPv6 service within 3 months after receiving > > > allocated address space. This must be substantiated by such > > > documents as an engineering plan or deployment plan. > > We think 3 months is too short, even in our business. Change > to 6 months. > > > > > > > The above criterion that requires interconnection with at least three > > > other sub-TLAs creates a bootstrapping problem which can be resolved > > > by the following requirements that have been defined for a > > > bootstrapping period: > > > > > This seems to say that it's impossible to try to bootstrap an > IPv6-only ISP. That's restraint of trade. Anyway, given your second > option above (intent to provide service) why do we need the > bootstrapping mechanism at all? Intent to supply service allows > bootstrapping. > > > > The requesting organization's network must have BGP peering > > > relationships with at least three other public Autonomous Systems in > > > default-free zones, > > > > > > The requesting organization must show that it already has issued IPv4 > > > address space to 100 customer sites that can meet the criteria for a > > > /48 IPv6 reassignment, and > > 100 is too high as noted above. > > > > > > > The requesting organization must demonstrate a clear intent to provide > > > IPv6 service within 3 months after receiving allocated address space. > > > This must be substantiated by such documents as an engineering plan or > > > deployment plan. > > > > 3 months is too short as noted above. > > > > The first 50 requesting organizations who obtain a sub-TLA must > > > fulfill either the criteria for the bootstrapping or the general > > > criteria. Only 30 out of these 50 networks/organizations can be > > > located in one region. After 50 sub-TLAs have been allocated, the > > > bootstrap criteria will no longer apply. > > We suggest 100 instead of 50, and lose the regional restriction > and the next paragraph. We don't need this level of prudence. > > ... > > > > > > 4.1.2 Size for Initial Allocation/Slow-Start Mechanism > > > > > > The initial allocation of sub-TLA space will allow 13 bits worth of > > > NLA IDs to be utilized by the organization receiving the /35 reserved > > > from the sub-TLA unless the requesting organization submits > > > documentation to the Regional IR to justify an exception. > > As noted above this is a totally inappropriate restriction. > We do not need to conserve addresses to this extent. Sub-TLA > assignees should get the full /29. All of the following text > and the notion of extending sub-TLA allocations should be > simplified and reworked to remove this whole notion. > > > > ...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: this allows the > > > organization to receive 8,192 NLAs (a /48 each). The making of > > > assignments (to ISPs or end-sites) is covered in section 4.2 in more > > > detail. > > > > > > The size of the initial allocation has been set to 13 bits because > > > this allows the TLA Registry some freedom in creating an addressing > > > hierarchy. If it has other Service Providers as customers (who in turn > > > have their own end-user customers), this allows the TLA Registry to > > > sub-allocate smaller blocks to each of them. > > > There is no need to do this and it hurts aggregation. > This is IPv4-centric thinking. > > > > 4.1.3 Requirements for Next Allocation > > > > > > Once an organization has used 80% of the sub-TLA address space, the > > > organization may contact the Regional IR in its region to request that > > > another range of addresses be allocated. The size of the next range > > > depends on the utilization rate of the previous allocation. > > The only reasonable step is from a complete sub-TLA (/29) to > a shorter prefix. Here there are two models that the IETF probably > needs to look at - the next step is a complete TLA (/16), or > it is new form of sub-TLA somewhere betwen /16 and /29. > However this is far-future and should be left for further study. > > Simplify all this: allocate complete sub-TLAs and leave everything > beyond this for further study. Just delete most of 4.1.3 for now. > > ... > > > > > > 4.1.3.2 Renumbering > > This section is useful, unlike the rest of 4.1.3. > > However, we will not be short of subTLAs or TLAs for many years. > While it is good to make all allocations temporary, there is no > need to recover subTLAs within 3 months of allocating a TLA > to the same operator. Some would say this recovery should not > be done at all in the early years; if it is to be done, the > overlap period should be much longer, say 24 months. A minimum > of 12 months should be guaranteed in perpetuity. > > ... > > > 4.2 Assignments > > > > > > 4.2.1 Assignments to End-users > > > > > > Every end-user organization receives a /48 worth of address space (80 > > > bits). Out of this, 16 bits are an SLA block used for subnetting and > > > another 64 bits are used per interface. All requests for additional address > > > space from the same TLA Registry must be submitted to the Regional IR > > > for evaluation (a second opinion). In this case the full utilization > > > of the initial SLA must be documented. The need for additional address > > > space must be presented in the form of an engineering plan. Since the > > > SLA part of the end-user's assignment allows for creating 65,536 > > > subnets, the organization must show in what way this was not > > > sufficient for their network, and must present a plan showing where > > > each of the 65,536 subnets is used and why new subnets are necessary. > > This is plain wrong. The reason we went for 16 bits was not to allow > for 65k subnets. It was to allow complex corporate networks to > use the SLA space as an aggregatable address space. The last sentence > should be something like > > Since the SLA part of the end-user's assignment allows for > a 16-bit aggregatable subnet addressing scheme, the organization > must show why their network topology cannot be accommodated > within a 16-bit addressing scheme. > > ... > > > 4.2.2 Assignments and Allocations to Other ISPs > > > > > > If the TLA Registry has ISP customers (who in turn have end-users), > > > the TLA Registry could use the 13 bits of NLA address space to create > > This should be 19 bits as noted above. > > > > an addressing hierarchy for them. > > > > Each of the TLA Registry's own > > > end-users would receive a /48 as specified above, however, the ISP > > > customers (NLAs) 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. > > We agree with slow-start in this context. > ... > > > 4.3 Reclamation Methods/Conditions > > > > > > Allocations are valid only as long as the original criteria are still > > > met. The criteria for allocating TLA address space may change over > > > time depending on routing technology. The current target is to limit > > > the global routing space to roughly 8,000 entries. If 50% of this > > > limit is reached, routing technology and allocation criteria will be > > > reviewed. If routing technology allows additional route entries, the > > > number of possible TLAs and sub-TLAs may be increased. > > 8000 is very modest. Who set this goal? It is also wrong; > we can have about 8k TLAs and 8k sub-TLAs, so 16k is the correct > value (and extremely conservative in terms of router technology). > > Also this section should actually say that if the 50% limit (of 16k) > is reached, the routing issues will be referred to the IETF. > > > > If it turns out that routing technology at that time does not allow > > > additional routing entries, > > This won't happen, and in any case why worry about it today? > Leave it all TBD. > > ... > > > 5. ORGANIZATIONS OPERATING IN MORE THAN ONE REGION > > > > > > If an organization requesting sub-TLA space operates in more than one > > > region, and needs separate sub-TLA blocks for routing purposes, it > > > should request the address space for its entire network from only one > > > of the Regional IRs. It can apply for an initial allocation that is > > > larger than 13 bits if it can show that its network is divided into > > > several components with each needing its own sub-TLA route (each > > > component individually needs to fulfill the criteria for being a TLA > > > Registry). The size of the allocation would depend on how many > > > top-level routes are needed. > > > > > > For example, if a multinational transit provider can show that it > > > needs three top-level routes, it would initially receive 15 bits of > > > NLA space (a /33). It could then allocate a /35 to each of the > > > top-level parts of the network and route each one separately. Each of > > > these sub-allocations would need to be entered in the database of the > > > Regional IR individually. > > This doesn't compute. We don't expect to see /35 or even /33 > announcements at the default-free level. The goal is aggregation > at TLA and subTLA level, with nothing smaller being advertised. > We'd even expect such a provider to be multihomed with several /29s. > Again, we just don't have to conserve to this degree. > > Regards > > Brian Carpenter > IAB Chair > David K. ---

2 2

Comments on...IPv6 Address Allocation Plan
by Jim Fleming 22 Feb '99

22 Feb '99

Paula, Here are my comments on the various proposals below: 1. I hope we agree that your planning has nothing to do with IPv8 and/or IPv16 address allocations. 2. I am curious why plans are not being made for MORE registries, more jobs, more sharing of the wealth. 3. You mention other discussions are taking place. Can you describe where ? 4. The whole thing looks like a large multi-level-marketing (MLM) structure. 5. Are your plans compatible with the IRS laws in the U.S. regarding non-profit companies ? Jim Fleming Unir Corporation vPC + C+@ + IPv8 + 2,048 TLDs...this network solution is simple... @@@@@@@@@@@@@@@@@@@@@@@@@@@ Policy draft To: ipv6-wg(a)ripe.net Subject: Policy draft From: Paula Caslav <paula(a)ripe.net> Date: Thu, 04 Feb 1999 10:52:47 +0100 Sender: owner-ipv6-wg(a)ripe.net ---------------------------------------------------------------------------- ---- Hi all, This is just to let you know that we decided at the ipv6 working group session at RIPE 32 that people would be given 2 weeks on the mailing list to send their comments about the draft IPv6 Assignment guidelines. If you already made comments at the working group itself, we have noted them down and will consider them. A copy of the draft is in the mailing list archives: http://www.ripe.net/mail-archives/ipv6-wg/current/msg00019.html Kind regards, Paula Caslav RIPE NCC @@@@@@@@@@@@@@@@@@@@@@@@@@@@@

1 0

IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT
by Francis Dupont 20 Feb '99

20 Feb '99

IAB comments addressed my main concern about the document: a too large part given to "Conservation" but I still have minor comments: - 4.1.3.1 Verification of Utilization it is not reasonable to ask that all assignments to end-sites must be registered in the public database: ISPs need some kind of confidentiality in their business (cf Ruediger Volk). - same sub^3 section ping doesn't work well with anycast destinations - 4.2.1 Assignments to End-users I'd like to see conditions of assignment for: * an address (128 bit "prefix") * a subnet (64 bit prefix) * a site (48 bit prefix) Today one of more nasty problems is for a dial-up user it is hard (or expensive) to get more than one (dynamic) address then many people install NATs for that not technical reason. Of course we don't want to see the same thing with IPv6 then this point must be clear and there will be a FAQ about the "connected dentist office" (technically easy, it is a case where RIPng is well suit!) - I can't understand second opinion requirements (a must for users and a should for ISPs). I am impatient to read the next version of the document... Francis.Dupont(a)inria.fr

1 0

Re: IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft)
by Bernard.Tuy＠urec.cnrs.fr 18 Feb '99

18 Feb '99

| Date: Wed, 17 Feb 1999 16:45:46 -0700 | From: David Kessens <david(a)Qwest.net> | | Included below are the comments from the IAB on the 'IPv6 ASSIGNMENT | AND ALLOCATION POLICY DOCUMENT (3rd draft)'. | | I personnally think that the IAB's comments are pretty close to the | suggestions that the wg decided on during the RIPE IPv6 wg session in | Amsterdam. ====BT: If I agree with David's comment above and with the IAB answer to the document, a question remains : -what will be now the procedure(s) to get an "operational" document ? Do we have -still- to wait a long time, before official allocation will start ? One could argue nothing is urgent still no networks are ready to deploy for production traffic yet. But it's again a "chicken & egg" problem ... ? Regards, +bernard Tuy.

2 1

IAB comments on IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT
by Mirjam Kuehne 18 Feb '99

18 Feb '99

Dear colleagues, Please find below comments we received from the IAB on the draft "IPv6 Assignment and Allocation Policy Document". Kind Regards, Mirjam Kuehne ------- Forwarded Message Date: Mon, 15 Feb 1999 09:51:44 +0000 From: Brian E Carpenter <brian(a)hursley.ibm.com> To: Daniel.Karrenberg(a)ripe.net, Mirjam Kuehne <mir(a)ripe.net>, kimh(a)arin.n et, Anne Lord <anne(a)apnic.net>, pwilson(a)apnic.net cc: IAB <iab(a)iab.org> Subject: Re IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft) Dear colleagues, Re IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft) The IAB has been looking at this draft and here are our comments (which are not confidential in any way). It's very good to see the registries working actively on this important topic. However there are two points of concern about the current version, one political and one technical. The political one is easy to fix. Referring to ICANN is contentious in this context, and referring to IANA is not contentious. So please replace all reference to ICANN by IANA. It doesn't change anything but it will reduce argument. The technical one is more tricky. Basically the draft errs too much on the side of address conservation. While it is important to be prudent and to avoid creating an IPv6 toxic waste dump, we do have a lot more freedom than with IPv4. The draft doesn't take full advantage of this, with the paradoxical effect that aggregation is harmed and unnecessary renumbering is forced. We can afford to be more generous with subTLA space and less restrictive with slow start. The detailed comments below almost all relate to this point. > > IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft) ... > > > > ABSTRACT > > > > This document describes the registry system for the distribution of > > globally unique IPv6 address space, which follows a hierarchical > > distribution as it does with IPv4. The distribution of IPv6 address > > space is managed by the IANA (formerly IANA) and further delegated by ...space is managed by the IANA and... (it is managed by IANA and only by IANA.) ... > > This document does not describe private IPv6 address space, or anycast There is no such thing as private IPv6 address space. There are site-local and link-local IPv6 addresses defined architecturally. ... > > 2.1.1 IANA > > > > The Internet Corporation for Assigned Names and Numbers (IANA) has Remove all mention of ICANN which is a red rag to many bulls. The Authority lies with IANA. > > authority over all number spaces used in the Internet, including IPv6 > > address space. IANA allocates parts of the IPv6 address space to > > Regional Internet Registries (IRs) according to their established > > needs. > ... > > 2.2 Goals of the Internet Registry System > > > > The remainder of this document is primarily concerned with the > > management of public IPv6 address space. Every assignment of IPv6 > > addresses should be made with the following goals in mind for it is in > > the interest of the Internet community as a whole that these goals be > > pursued. It is worth noting that "conservation" and "aggregation" are > > often conflicting goals, and therefore each assignment must be > > evaluated carefully. This is IPv4 thinking. Aggregation is what matters for IPv6. Conservation is not a major goal; avoidance of profligacy is the goal, which is much weaker. Suggested rewrite of the last sentence: Each assignment must be evaluated carefully to ensure good aggregation without being profligate with address usage. > > Moreover, these goals may occasionally be in > > conflict with the interests of individual end users or ISPs. They will be in conflict. Suggested rewrite: In the case of IPv4, the necessary heavy emphasis on address conservation, and the attempt to retrofit aggregation, have combined to cause frequent conflict betwen the interests of end users and smaller ISPs with those of the network as a whole. It has also favoured the use of private address space with its unfortunate architectural side effects. IPv6 allows this conflict to be avoided in future. > > In such > > cases, careful analysis and judgement are necessary to find an > > appropriate compromise. Delete this sentence; this compromise is not needed for v6. ... > > 2.2.3 Conservation The word "Conservation" should be replaced by "Avoidance of profligacy" in the title and everywhere else. Don't misunderstand this as being against conservation: but this draft goes overboard. ... > > For purposes of a slow start of a sub-TLA, however, a first sub-TLA > > allocation would actually always be a /35 block (13 bits instead of > > 19). There is no need to slow-start sub-TLAs; in fact it makes no sense. A sub-TLA is always going to be allocated to a single operator; backbone ISPs will certainly not want to see /35 announcements - We expect they will filter anything longer than /29. Sub-TLAs should be fully allocated. (To put it another way, Sub-TLAs *are* the slow-start mechanism.) ... > > 4.1.1 Requirements for Allocating a Sub-TLA > > > > In order to meet the conservation and aggregation goals discussed > > above, only requesting organizations that meet certain requirements > > will be allocated sub-TLA space. The requirements for an initial > > allocation to an organization are different from the requirements that > > have to be met once the initial allocation has been used and > > additional address space is requested. > > > > Whereas the requirements for an initial allocation are based on > > technical considerations, all additional address space is purely based > > on the utilization of the initial allocation. In order to meet the > > aggregation goal, requests for an initial allocation of a sub-TLA have > > to be carefully evaluated. It is not necessary for every requesting > > organization to obtain sub-TLA space. The following requirements must > > be met in order to obtain an initial allocation of sub-TLA address > > space: > > > > The requesting organization's IPv6 network must be interconnected with > > the IPv6 networks of at least three other organizations that have a > > sub-TLA allocated to them, and either: > > > > -- The requesting organization must have reassigned IPv6 > > addresses received from its upstream provider or providers > > to 100 SLA customer sites with routed networks. Dial-in > > customers do not count toward the 100 IPv6 customer sites. This is far too high a bar for at least three reasons 1. nobody can meet it during the early stages of IPv6 deployment 2. there are many examples of non-profit networks, and certainly some for-profit networks, that do not achieve this scale, but must have at least a sub-TLA to avoid horrendous aggregation problems due to multihoming. This guideline definitely hurts aggregation. 3. this criterion also makes it very unlikely that metropolitan internet exchanges would qualify, yet metro exchanges are prime candidates for TLA or sub-TLA allocation (again to enable multihoming). We suggest reducing the 100 to 10. > > Customers currently using IPv4 host addresses for dial-up > > should not be assigned an NLA or an SLA, or > This seems redundant and gratuitous. > > > > -- The requesting organization must demonstrate a clear intent > > to provide IPv6 service within 3 months after receiving > > allocated address space. This must be substantiated by such > > documents as an engineering plan or deployment plan. We think 3 months is too short, even in our business. Change to 6 months. > > > > The above criterion that requires interconnection with at least three > > other sub-TLAs creates a bootstrapping problem which can be resolved > > by the following requirements that have been defined for a > > bootstrapping period: > > This seems to say that it's impossible to try to bootstrap an IPv6-only ISP. That's restraint of trade. Anyway, given your second option above (intent to provide service) why do we need the bootstrapping mechanism at all? Intent to supply service allows bootstrapping. > > The requesting organization's network must have BGP peering > > relationships with at least three other public Autonomous Systems in > > default-free zones, > > > > The requesting organization must show that it already has issued IPv4 > > address space to 100 customer sites that can meet the criteria for a > > /48 IPv6 reassignment, and 100 is too high as noted above. > > > > The requesting organization must demonstrate a clear intent to provide > > IPv6 service within 3 months after receiving allocated address space. > > This must be substantiated by such documents as an engineering plan or > > deployment plan. > > 3 months is too short as noted above. > > The first 50 requesting organizations who obtain a sub-TLA must > > fulfill either the criteria for the bootstrapping or the general > > criteria. Only 30 out of these 50 networks/organizations can be > > located in one region. After 50 sub-TLAs have been allocated, the > > bootstrap criteria will no longer apply. We suggest 100 instead of 50, and lose the regional restriction and the next paragraph. We don't need this level of prudence. ... > > > > 4.1.2 Size for Initial Allocation/Slow-Start Mechanism > > > > The initial allocation of sub-TLA space will allow 13 bits worth of > > NLA IDs to be utilized by the organization receiving the /35 reserved > > from the sub-TLA unless the requesting organization submits > > documentation to the Regional IR to justify an exception. As noted above this is a totally inappropriate restriction. We do not need to conserve addresses to this extent. Sub-TLA assignees should get the full /29. All of the following text and the notion of extending sub-TLA allocations should be simplified and reworked to remove this whole notion. > > ...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: this allows the > > organization to receive 8,192 NLAs (a /48 each). The making of > > assignments (to ISPs or end-sites) is covered in section 4.2 in more > > detail. > > > > The size of the initial allocation has been set to 13 bits because > > this allows the TLA Registry some freedom in creating an addressing > > hierarchy. If it has other Service Providers as customers (who in turn > > have their own end-user customers), this allows the TLA Registry to > > sub-allocate smaller blocks to each of them. > There is no need to do this and it hurts aggregation. This is IPv4-centric thinking. > > 4.1.3 Requirements for Next Allocation > > > > Once an organization has used 80% of the sub-TLA address space, the > > organization may contact the Regional IR in its region to request that > > another range of addresses be allocated. The size of the next range > > depends on the utilization rate of the previous allocation. The only reasonable step is from a complete sub-TLA (/29) to a shorter prefix. Here there are two models that the IETF probably needs to look at - the next step is a complete TLA (/16), or it is new form of sub-TLA somewhere betwen /16 and /29. However this is far-future and should be left for further study. Simplify all this: allocate complete sub-TLAs and leave everything beyond this for further study. Just delete most of 4.1.3 for now. ... > > > > 4.1.3.2 Renumbering This section is useful, unlike the rest of 4.1.3. However, we will not be short of subTLAs or TLAs for many years. While it is good to make all allocations temporary, there is no need to recover subTLAs within 3 months of allocating a TLA to the same operator. Some would say this recovery should not be done at all in the early years; if it is to be done, the overlap period should be much longer, say 24 months. A minimum of 12 months should be guaranteed in perpetuity. ... > > 4.2 Assignments > > > > 4.2.1 Assignments to End-users > > > > Every end-user organization receives a /48 worth of address space (80 > > bits). Out of this, 16 bits are an SLA block used for subnetting and > > another 64 bits are used per interface. All requests for additional address > > space from the same TLA Registry must be submitted to the Regional IR > > for evaluation (a second opinion). In this case the full utilization > > of the initial SLA must be documented. The need for additional address > > space must be presented in the form of an engineering plan. Since the > > SLA part of the end-user's assignment allows for creating 65,536 > > subnets, the organization must show in what way this was not > > sufficient for their network, and must present a plan showing where > > each of the 65,536 subnets is used and why new subnets are necessary. This is plain wrong. The reason we went for 16 bits was not to allow for 65k subnets. It was to allow complex corporate networks to use the SLA space as an aggregatable address space. The last sentence should be something like Since the SLA part of the end-user's assignment allows for a 16-bit aggregatable subnet addressing scheme, the organization must show why their network topology cannot be accommodated within a 16-bit addressing scheme. ... > > 4.2.2 Assignments and Allocations to Other ISPs > > > > If the TLA Registry has ISP customers (who in turn have end-users), > > the TLA Registry could use the 13 bits of NLA address space to create This should be 19 bits as noted above. > > an addressing hierarchy for them. > > Each of the TLA Registry's own > > end-users would receive a /48 as specified above, however, the ISP > > customers (NLAs) could be "allocated" additional bits in order to > > aggregate the ISP's customers internally. A slow-start mechanism will be u sed > > for these NLA allocations. We agree with slow-start in this context. ... > > 4.3 Reclamation Methods/Conditions > > > > Allocations are valid only as long as the original criteria are still > > met. The criteria for allocating TLA address space may change over > > time depending on routing technology. The current target is to limit > > the global routing space to roughly 8,000 entries. If 50% of this > > limit is reached, routing technology and allocation criteria will be > > reviewed. If routing technology allows additional route entries, the > > number of possible TLAs and sub-TLAs may be increased. 8000 is very modest. Who set this goal? It is also wrong; we can have about 8k TLAs and 8k sub-TLAs, so 16k is the correct value (and extremely conservative in terms of router technology). Also this section should actually say that if the 50% limit (of 16k) is reached, the routing issues will be referred to the IETF. > > If it turns out that routing technology at that time does not allow > > additional routing entries, This won't happen, and in any case why worry about it today? Leave it all TBD. ... > > 5. ORGANIZATIONS OPERATING IN MORE THAN ONE REGION > > > > If an organization requesting sub-TLA space operates in more than one > > region, and needs separate sub-TLA blocks for routing purposes, it > > should request the address space for its entire network from only one > > of the Regional IRs. It can apply for an initial allocation that is > > larger than 13 bits if it can show that its network is divided into > > several components with each needing its own sub-TLA route (each > > component individually needs to fulfill the criteria for being a TLA > > Registry). The size of the allocation would depend on how many > > top-level routes are needed. > > > > For example, if a multinational transit provider can show that it > > needs three top-level routes, it would initially receive 15 bits of > > NLA space (a /33). It could then allocate a /35 to each of the > > top-level parts of the network and route each one separately. Each of > > these sub-allocations would need to be entered in the database of the > > Regional IR individually. This doesn't compute. We don't expect to see /35 or even /33 announcements at the default-free level. The goal is aggregation at TLA and subTLA level, with nothing smaller being advertised. We'd even expect such a provider to be multihomed with several /29s. Again, we just don't have to conserve to this degree. Regards Brian Carpenter IAB Chair ------- End of Forwarded Message

1 0

Re: IPv6 Assignment and Allocation Policy Document
by Poul-Henning Kamp 17 Feb '99

17 Feb '99

[ Moderator note: changed local-ir(a)ripe.net -> ipv6-wg(a)ripe.net ] Could somebody take the time to explain how multi-homing works in this setup ? I have either not grasped it or not found the place where it is described. Lets take a small ISP who have "upstream" connections to one TLA and two sub-TLA entities. Are they required to become a sub-TLA ? if yes: What if they don't meet one of the formal requirements for that ? Would failing to become a sub-TLA prevent them from opening "general" peerings with one or more of these (sub-)TLAs ? (in other words: will these policies discourage and prevent multihoming ?) if no: Which IPv6 numbers will they use ? How will route-aggregation work in this case ? Will each host have 3 IPv6 numbers listed in DNS ? Sorry if these are stupid questions, but I'm probably not the only one being unenlightened in this area... -- Poul-Henning Kamp FreeBSD coreteam member phk(a)FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far!

3 2

Re: Policy draft
by Alain Durand 16 Feb '99

16 Feb '99

I would like to comment on the IPv6 assignment and allocation policy document 1. Terminology. ------------------- I would suggest that this document use the same terminology as the one used in the various IPv6 related RFC, e.g. site local addresses instead of private addresses Also in section 2.2.3, this document refers to 80 bits available for addressing end sites. I would suggest to say at this point that this is 16 + 64 bits. Same total, but the usage is different. 2. Sites and /48 prefixes ------------------------------ I would like this document to define precisely sites. This will make it clear who can (or not) claim a /48 prefix. The document says in section 4.2.1: Only end-user organizations with a need to create subnets in their network should be assigned a full /48. Dial-up lines are considered part of the ISP's infrastructure and should be assigned from the SLA ofthat ISP. I disagree there. The network in my house may be composed of several subnets and still be connected to my ISP via dial-up. (again, we have to define precisely sites) All end-user organization requesting to be a site should get a /48. Address conservation is good practice, but, there, it's asking too much. 3. 80% Requirements for next allocation -------------------------------------------------- in 4.1.3: Once an organization has used 80% of the sub-TLA address space, the organization may contact the Regional IR in its region to request that another range of addresses be allocated I would suggest the document to be more precise about this. This can not be 80% of the all address space of the sub-TLA. A sub-TLA being /35, the total address space is 103 bits long! So, there must be a limit somewhere, for example say it's 80% of the address space in between bit 36 and bit 48. This is correct if a sub-TLA is only servicing sites and not NLAs. If a sub-TLA is servicing NLAs, requesting that all NLAs must use 80% of their address space before the sub-TLA may ask for a full TLA is, IMHO, too strong a requirement. I fear that sub-TLA will then be reluctant to allocate NLA. 4. Router interfaces ------------------------ in section 3.2: All router interfaces are required to have at least one link-local unicast address or site-local address. Site-local will 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. Interfaces are required to have a link local address. Not site local. Their use is at the discretion of sites. Some may like them, some not. For administrative reasons, as site borders are often crossed, they are valid cases where router interfaces (and point-to-point links) MUST have global addresses. If I want to ping , from my host, to a router I'm responsible for, on one particular interface and if that router in not within my site borders, I need to find a global address for that particular interface. Any global unicast address space assigned must not be used for the link-local or site-local purpose as there is reserved address space for these addresses. Again, I disagree. This is NOT because two hosts are within the same site that they MUST use site local addresses. This requirement is not acceptable. Some sites may want to implement this, some not. It requires a lot of techniques to do it, including source address selection, DNS tricks and others. 5. General comments -------------------------- This document is focusing heavily on address conservation. Learning IPv4 mistake is a reasonable goal, but IPv6 addresses are so structurally different from IPv4 ones that address conservation should not be so restrictive. Also, the document specificaly ask that all special SLA request MUST be approved by the regional registries. IMHO, those issues should be better resolved at a lower level, NLA and/or SLA. Multi-homing will be more and more frequent. The way ISP will implement multi-homing in IPv6 may have a big impact on aggregation. I would like to see a section on this particular topic in this document. - Alain Durand.

1 0