[apnic-talk] Re IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draf
Below are comments received on the 15th Feb from the IAB on the
draft "IPv6 Assignment and Allocation Policy Document". The first forward
attempt was truncated due to stray '.' characters in the mail.
---------- Forwarded message ----------
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
* APNIC-TALK: General APNIC Discussion List *
* To unsubscribe: send "unsubscribe" to apnic-talk-request at apnic dot net *