IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft)

[David Kessens <]

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@localhost  Mon Feb 15 04:57:10 1999
> Message-ID: <36C7EE30.3A84DFB3@localhost
> Date: Mon, 15 Feb 1999 09:51:44 +0000
> From: Brian E Carpenter brian@localhost
> Organization: IBM Internet Division
> X-Mailer: Mozilla 4.04 [en] (Win95; I)
> MIME-Version: 1.0
> To: Daniel.Karrenberg@localhost, Mirjam Kuehne mir@localhost, kimh@localhost,
>         Anne Lord anne@localhost, pwilson@localhost
> CC: IAB iab@localhost
> 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.
---