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@hursley.ibm.com> To: Daniel.Karrenberg@ripe.net, Mirjam Kuehne <mir@ripe.net>, kimh@arin.n et, Anne Lord <anne@apnic.net>, pwilson@apnic.net cc: IAB <iab@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