Dear colleagues, Please see below comments the Co-Chairs of the IETF IPng Working Group and the NGTrans Working Group sent concerning the IPv6 Policy Document. Maybe this can be useful as input for the discussion at the RIPE Meeting. Kind Regards, Mirjam Kuehne RIPE NCC ---------- Forwarded message ---------- Date: Tue, 25 Jan 2000 16:26:24 -0800 To: Anne Lord <anne@apnic.net>, ipv6-registry@apnic.net From: Steve Deering <deering@cisco.com> Subject: Re: IPv6 Policy Document Review - Call for comments Cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Anne et al, Here are some comments on the Provisional IPv6 Assignment and Allocation Policy Document from the co-chairs of the IPng and NGTrans Working Groups. We very much appreciate your invitation for us to review the document. Let us first note that we are delighted that the IPv6 address allocation and assignment process has begun and seems to be functioning smoothly. The establishment of such a process was a critical requirement for production deployment of IPv6, and we would like to say thanks to you and your colleagues in the RIRs for all the work you have done to get the process up and running. Let us also point out that these comments are not based on us being customers of the allocation process -- we hope that those ISPs who have been allocated IPv6 address space under the existing process will separately comment on any difficulties they may have encountered or any suggestions for improvement they might have. Rather, these comments are based on our knowledge of the design goals and technical requirements of IPv6 addressing and our concerns about some potential negative consequences of the current allocation policy. Our primary concern with the current document is that it stresses unnecessary address conservation in a number of places, and in ways that are contrary to the intent of the protocol design. Specifically: (1) The third paragraph of section 4.3.1, regarding dial-up lines, is apparently motivated by a desire to conserve address space. Unfortunately, it is ambiguous and contradictory, and depending on how it is interpreted, it could impose an unnecessary and potentially harmful constraint on IPv6 address allocation to customer sites. o It is ambiguous because it seems to equate dial-up access with single-user access, while clearly those properties are distinct: a single dial-up line may well serve multiple users. And why is the number of users relevant to IP address allocation? A single user with multiple IP devices requires more IP addresses than multiple users sharing a single device. o It is contradictory because a dial-up customer (e.g., a residential or small-office customer) who has a need to create subnets is intended to receive a /48, according to the first paragraph of that section, and a longer prefix than /48, according to the third paragraph. o It is unnecessary because the size of the public topology part of the IPv6 address was explicitly chosen to be far more than enough to hierarchically assign a unique TLA+NLA (i.e., a unique /48) to every enterprise and every household in the world, for the foreseeable future and beyond, regardless of their type of access technology. We took into consideration the possibility that all dial-up users would one day migrate to always- on access, and we sized the public topology part of the IPv6 address accordingly. Thus there is no need to share a /48 among multiple customers, whether they use dial-up access or not. o It is potentially harmful because if ISPs interpret the policy to mean they should assign only a single /64 to each dial-up customer, given that at least some and possibly many dial-up customers will have a need to create subnets, we will almost certainly see one or both of the following harmful developments: - subdivision of the customer's 64-bit interface ID field into a subnet ID field and a smaller interface ID field, which would defeat the IPv6 goals of stateless address autoconfiguration and topologically-independent, globally-unique node identification that are achieved through the use of EUI-64-based interface IDs. - deployment of IPv6 NAT devices to allow the customer to have multiple /64 subnets behind a single /64 allocation, which would defeat the IPv6 goal of having a single, global address space for all IPv6 devices. Therefore, we recommend that the third paragraph of section 4.3.1 be deleted from the document, and that it be made clear to the RIRs and ISPs that it is perfectly legitimate and desirable that every end-user customer, including dial-up and residential customers, be assigned a static, unique /48 IPv6 address prefix. (2) The last paragraph of section 3.2, regarding address assignment to point-to-point links, also seems to be motivated by the desire to conserve address space. The recommendation against ISPs assigning global, public addresses to routers' point-to-point interfaces is both unnecessary and inappropriate. o It is unnecessary because it would have negligible impact on address space consumption if each ISP were to set aside one of its allocated NLA values (i.e., one /48), from which to assign global /64 prefixes to each of its point- to-point links. The IPv6 address space is, by design, big enough to allow all Internet device interfaces, including those of ISPs' routers, to have globally-unique, publicly visible addresses. o It is inappropriate because it is beyond the RIRs' mandate to determine that ISPs' router interfaces "do not require public address space". An ISP might well choose to assign global addresses to its point-to-point interfaces, for example to permit inter-ISP traceroute to work properly, and the RIRs have no business interfering in that operational decision. Therefore, we recommend that the last paragraph of section 3.2 be deleted. (However, the parenthetical comment at the end of that paragraph, concerning the validity of all 1s and all 0s field values, should be retained somewhere, or be promoted to being a paragraph of its own). (3) Though the document does not explicitly say so, a number of readers have interpreted the description of the slow-start mechanism in section 4.2.4 to mean that an ISP will normally start with a /35 allocation and then, as its IPv6 customer base grows, be required to come back to its RIR for each additional bit of address space, i.e., first for the enclosing /34, then for the enclosing /33, and so on, up to the sub-TLA allocation of /29. While that might be a reasonable approach if we were trying to force the ISPs to achieve maximal density of address usage, such aggressive address conservation is explicitly not a goal of the IPv6 allocation policy, and if it were in fact to be implemented that way, it would impose an unnecessary and undesirable burden on ISPs. For example, while an ISP might reasonably do flat routing for its first 6500 NLAs (80% of the NLAs in the initial /35), if it expected to enjoy any significant further growth, the next sensible step would be for it to establish an internal hierarchy for its subsequent NLA assignments. However, obtaining only a single bit of additional address space would not allow for any sort of long-term hierarchy to be established. Instead, we suggest that a reasonable expectation for any ISP that appears at all likely to grow into a full sub-TLA, and eventually a TLA, should be that they go from a /35 initial allocation to a /29 full sub-TLA allocation in one step. We do not believe this would be inconsistent with the purposes of slow start for IPv6 address allocation, which we understand to be: o prevention of flagrant wastage or stockpiling of IPv6 address space, o arranging that ISPs with significantly fewer customers have longer prefixes than others, and o forcing occasions for ISPs to receive guidance from their RIRs on acceptable address usage practices. Now perhaps our suggested approach is in fact what you have in mind -- we note that the document gives considerable (and sensible) flexibility for the RIRs to exercise their best judgement regarding how much additional space to grant. If that is the intent (and we hope it is), we would prefer that that be made much more explicit in the policy document, so that any legitimate ISP with serious plans for a large IPv6 deployment can know that it will not be subjected to many small "baby-step" allocations that would complicate its planning and possibly force it to impose otherwise unnecessary renumbering events on its earlier customers. We also suggest that you consider changing the criteria so that existing top-level IPv4 ISPs who already have a large installed infrastructure and IPv4 customer base, and who presumably require less guidance on prudent address allocation practices, be able to obtain a full /29 sub-TLA to start, rather than being required to slow start from a /35. Yes, that creates the risk of such an ISP obtaining a lot of IPv6 space and then never using it, but (a) the requirement that ISPs report their NLA allocations in a public database provides a separate mechanism for monitoring usage, and that could be used as input to a reclamation decision, should that become necessary, and (b) if existing large IPv4 ISPs fail to eventually acquire a significant number of IPv6 customers, that will almost certainly indicate an overall lack of demand for IPv6 service, in which case the issue of IPv6 address stockpiling will have become moot. (4) The very few words in the document regarding allocation of TLAs ("If no further growth is possible within that sub-TLA range, the Regional IR may allocate a full TLA.", in section 4.2.5.1), when read in the context of the other, unnecessary address conservation requirements above, give the impression that the RIRs will be very reluctant to allocate actual TLAs. In particular: o Why does it say "...*may* allocate a full TLA", rather than "...*will* allocate a full TLA" (or "...*will normally* allocate a full TLA", to allow for exceptions)? o What is the criterion for determining that "no further growth is possible" with a sub-TLA? The only reference to determining when a piece of address space is "full" is in the section on sub-TLA allocation, section 4.2.5, in which there is an "at least 80% used" requirement. That is a reasonable threshold for determining when a flat address space, or a single field of a hierarchical address (such as the 13-bit NLA field in an initial /35 allocation, handled as a flat space), is near capacity, but it is unreasonable and unachievable in practice in a hierarchically-structured address space (such as the 19-bit NLA space in a full sub-TLA). We recommend that the criteria for obtaining a TLA be made more explicit, and we suggest that you consider a metric such as the "H ratio" defined in RFC 1715, which takes into account the significantly reduced density achievable in a hierarchical address space. For example, specifying an H ratio of 0.26, which that RFC describes as "optimistic" based on past experience with other, similar address spaces, would yield a recommendation that an ISP be granted a TLA at the point that it has allocated about 87,000 NLA values to end-user customers and/or downstream ISPs. Perhaps you could round that number down to 75,000 or up to 100,000 to come up with a simple rule for when an ISP could expect to acquire a TLA. Our remaining comments, both substantive and editorial, are given below, following quotations of the relevant text:
ABSTRACT
This document describes the registry system for distributing globally unique unicast IPv6 address space.
Append to the end of that sentence: "under format prefix 001, as defined in RFC 2374", to make it clear that this policy does not necessarily apply to any future global unicast space that might be created under other format prefixes.
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.
The use of the terms "TLA Registry" and "NLA Registry" above, and throughout the document, are inconsistent and often counter-intuitive. For example, the above paragraph uses: - "TLA Registry" to refer to an organization to whom a TLA value has been assigned, but - "NLA Registry" to refer to an organization that assigns NLA values to others. We suggest that you consistently use: - TLA Registry only to refer to those organization that assign TLA and sub-TLA values, i.e., IANA, the RIRs, and subordinate registries (like JPNIC), if any. - NLA Registry only to refer to those organizations that assign NLA values, i.e., ISPs and Exchanges, and their subordinate ISPs, if any. - SLA Registry only to refer to those organizations that assign SLA values, i.e., end-user customers (and ISPs, for their own infrastructure).
2 IPv6 ADDRESS SPACE AND THE INTERNET REGISTRY SYSTEM
IPv6 unicast addresses are aggregatable with contiguous bit-wise masks used to define routable prefixes,...
The reference to "contiguous bit-wise masks" is obsolete and inapplicable to IPv6. In IPv6, prefixes are always specified by length (number of bits), never by mask.
...using a method similar to that used for IPv4 addresses under CIDR.
The method of aggregation is not just "similar" to that used for IPv4 under CIDR, it is the same.
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.
The goal is not to *minimize* wastage, nor is it to *maximize* aggregation. Rather, the goal is to *limit* wastage, and to achieve *adequate* aggregation to meet the demands of stable, global routing.
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.
Following our suggestion above for consistent usage of terms, remove "TLA," from the last sentence above. (IANA and the RIRs are the TLA registries.) And if you disagree with that, then at least add the word "Registries" after "TLA", for grammatical consistency.
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.
Following our terminology suggestion, this section would refer to NLA registries having custodianship over blocks of NLAs (that fall under specific TLA or sub-TLA values assigned by the RIRs), and the subsequent (currently empty) section 2.1.4 would be deleted. We would also like to see this same language about custodianship applied to the RIRs themselves, so that it is made clear the RIRs are also custodians, not owners, of the address space (blocks of TLAs and sub-TLAs) allocated to them by IANA.
2.1.5 End-sites
[to be written]
We assume the points to be made here are that: - end-site customers are not granted "ownership" of the address space they are assigned. - end-site customers are responsible for assigning SLA IDs (subnet numbers) and interface IDs to their own links and nodes.
2.2.1 Uniqueness
Each IPv6 unicast address must be globally unique.
After "unicast address", add the phrase "under format prefix 001", because the statement above is not true of *all* IPv6 unicast addresses (particularly site-local, link-local, and loopback unicast addresses).
This is an absolute requirement for guaranteeing that every host on the Internet can be uniquely identified.
Change "host" to "node". (In IPv6, the term "host" does not include routers, whereas "node" includes all IPv6 devices, both hosts and routers.)
2.2.2 Aggregation
IPv6 addresses must be distributed in a hierarchical manner,
In several places in the document, the term "distribution" is used, rather than "allocation" or "assignment". If "distribution" has a distinct meaning, or is meant to refer to the union of allocation and assignment, please include it in the glossary at the end, with an explanation of its meaning.
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 external routes is the primary goal.
In that last sentence, change "the primary goal" to "a primary goal". IPv6 has other primary goals, such as increasing the available address space.
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.
Change "Inefficient use of classful allocations" to "Allocations of non-hierarchical (classful) prefixes". It was not the inefficiency of classful allocation that led to large routing tables, but rather their lack of sufficient hierarchy.
Furthermore, increased complexity of network topologies led to IPv4 prefixes being announced many times via different routes.
The presence of this sentence, in the context of the paragraph in which it appears, would seem to imply that a goal is to reduce the complexity of network topologies, which is certainly not a goal of IPv6 addressing or the allocation policy.
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.
Add a hyphen to "trouble shooting".
3.2 Initial IPv6 Addressing Hierarchy
...
All router interfaces are required to have at least one link-local unicast address or site-local address.
As we explained in our earlier comments, we recommend that the paragraph containing this sentence be deleted. However, in case you decline to accept that recommendation, you should know that the above sentence is not exactly right. All router (and host) interfaces are required to have at least one link-local unicast address. *In addition*, they may be assigned site-local and/or global unicast addresses.
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.
Change "all such allocations and assignments" to "all allocations and assignments of addresses under format prefix 001". Perhaps change "in this document" to "in the most recent version of 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.
Perhaps change "that the goals of aggregation and efficiency be met" to "that the technically and operationally necessary levels of aggregation and efficiency be met".
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 exterior routing protocol peering relationships with the IPv6 networks of at least three other organizations that have a sub-TLA allocated to them.
In criterion (a), change "sub-TLA" to "sub-TLA or TLA".
AND either
b(i). The requesting organization must have reassigned IPv6 addresses received from its upstream provider or providers to 40 SLA customer sites with routed networks connected by permanent or semi-permanent links.
What's a semi-permanent link?
OR
b(ii). The requesting organization must demonstrate a clear intent to provide IPv6 service within 12 months after receiving allocated address space. This must be substantiated by such documents as an engineering plan or deployment plan.
So, what sort of organization would satisfy (a) AND b(ii)? Any ISP who could satisfy (a) would presumably already be providing IPv6 service, not just planning to do it.
4.2.2 Criteria for sub-TLA Allocations in Transitional "Bootstrap" Phase
...
a. The requesting organization's network must have exterior routing protocol peering relationships with at least three other public Autonomous Systems in the default-free zone.
Make it clearer that you are talking about *IPv4* peering arrangements, in this case.
AND
b. The requesting organization must show that it plans to provide production IPv6 service within 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 40 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 participation in the 6bone project for at least six months, during which time it operated a pseudo-TLA (pTLA) for at least three months. The Regional IRs may require documentation of acceptable 6Bone routing policies and practice from the requesting organization.
We understood that the 6bone pre-qualification process was to be independent of the other bootstrap criteria, i.e. sufficient on it own. It seems unlikely that many ISPs meeting criteria (a) would need to rely on criterion (d), rather than (c). The 6bone pre-qual was supposed to allow bootstrapping of IPv6 providers who are *not* established IPv4 providers, i.e., do not satisfy (a).
4.2.3.2 Multihomed Sites
[to be written]
What needs to be said here is that end-user sites connected to multiple ISPs are expected to receive an NLA assignment (i.e., a /48) from each of those ISPs, and therefore, each of such an end-user's nodes may have multiple, globally-unique addresses. However, it should also be explicitly said that nothing in this policy is intended to prevent or discourage a multi-homed end-user site from negotiating with any number of ISPs for the service of advertising and routing a /48 prefix obtained from another ISP.
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).
In that last sentence, change "8,192 SLAs" to "8,192 NLAs".
4.2.6 Registering and Verifying Usage
Each TLA Registry is responsible for the usage of the sub-TLA address space it receives...
Change "sub-TLA" to "sub-TLA or TLA". (And we would prefer that these be called NLA registries, because they register NLAs, not TLAs, as discussed above.)
Registered end-sites must be connected and reachable.
This is inconsistent with our recommendation that dial-up customers be able to obtain a /48, just like any other customers, so if our recommendation is accepted, this section will have to be reconsidered.
...Filtering holes should be negotiated by the Regional IR and the organization holding the addresses in question.
Explain what is meant by a "filtering hole".
...If an end-site requests an additional SLA, the TLA Registry must send the request to the Regional IR for a second opinion.
That should be "If an end-site requests an additional *NLA*, the *NLA* Registry must...".
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.
Change "inefficient" to "very inefficient".
Regional IRs requiring a TLA Registry to renumber will allow that Registry at least 12 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-08.txt describes the issues involved in and methods used for renumbering IPv6 networks.]
Just for your information, the IPng working group has an effort underway to produce a new document describing the renumbering process for a site, which will be more appropriate to cite here, once it has been published.
4.4 Reclamation Methods/Conditions
...
However, if the limit is reached and routing technology at that time is not able to support additional routing entries, Regional IRs will review all allocations made up to that point. In the course of this review, the Regional IRs may seek consensus of the Internet registry and engineering communities to set minimum acceptable usage rates or new criteria determining eligibility to hold sub-TLA space. Dependent upon such a consensus, the Regional IRs may revoke the sub-TLA allocations of any Registry not complying with those rates or criteria.
We wonder if you want to say "sub-TLA or TLA" in the two places above where you refer only to "sub-TLA".
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.
Change "are reached" to "is reached".
6.1 Allocation and Reverse Address Mapping
...
For each IPv6 address block allocated by a Regional IR to a member or customer, the Regional IR must set up NS records in the appropriate sub-domain within the "ip6.int" domain.
Just for your information, it is very likely that the "ip6.int" domain will be moved out of ".int" and into ".arpa". We expect this to be decided fairly soon, probably by Adelaide.
7. GLOSSARY
Allocation - The provision of IP address space to ISPs that reassign their address space to customers.
Change "ISPs" to "ISPs or exchanges".
End-user - An organization receiving reassignments of IPv6 addresses exclusively for use in operational networks.
Why "reassignments" instead of "assignments"? What is the point of using the phrase "operational networks"? Is this in contrast to experimental networks or non-operational networks? If this is actually intended to mean "not for offering public transit service to other organizations" or something like that, please say that.
Public Topology - The collection of providers and exchanges who provide public Internet transit service.
Change "who" to "that".
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.
Insert the word "geographic" before "scope"?
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.
IPv4 and IPv6 are *not* different in the way that this confusing text seems to suggest. In both protocols, addresses identify interfaces, not hosts, and in both kinds of addresses, the lowest-order field identifies an interface within a net or subnet (even though it is less precisely called the "host field" in IPv4). Finally, in the Call for Comments for the policy document, you said:
* Definition of 'transit provider'
A definition for the above term was not included in the current document. Comments and suggestions for an appropriate definition are encouraged.
We suggest that you *not* try to define that term, knowing what a slippery slope that is. We believe the criteria for allocation specified by the policy document (however it turns out after this review cycle) is, or ought to be, sufficient to indicate who is eligible to be assigned a sub-TLA or TLA value and who is not. Thanks again for requesting our feedback, and we apologize for the lateness and lengthiness of our response. We would be happy to set up a meeting to discuss any of these issues with you in person, if that would be helpful. Steve Deering & Bob Hinden, Co-Chairs, IPng Working Group Alain Durand, Bob Fink & Tony Hain, Co-Chairs, NGTrans Working Group