Proposals on IPv6 Allocation policy

Hiya all,

Here are some thoughts on IPv6 allocation policy. Hopefully the resulting
discussion will be active and constructive, resulting in appropriate feedback,
policy, IETF-drafts, RFCs, etc.

If the text below gets corrupted then you should be able to view it at:
http://www.djp.net/ipv6/proposal.html

This concerns the LIR and IPv6 WG at RIPE and I4ve sent to both lists
accordingly. I suggest all replies/discussion be carried out primarily on the
IPv6 list.

Cheers
Dave
Viag Interkom GmbH

-----------------------------
Proposals on IPv6 Allocation policy

Hierarchy versus Address Conservation

The RIR allocation policies for IPv6 appear to be based on the
assumption that IPv6 addresses are a scarce resource that are about to
run out. This assumption is totally untrue. Instead RIR allocation
policies need to be focussed 90% on aggregation and hierarchy, and
optimising the global routing table. One of the worst mistakes an RIR
can make is to allocate too few addresses to an LIR, resulting in
later subsequent allocations and pollution of the global routing
table.


Classbased versus Convenience:

What is appropriate for an "alpine village" ISP is not appropriate for
a large global ISP. LIR should not therefore all receive the same
"standard prefix" but receive sensible allocations based on reasonable
long term expectations on use. We should aim so that only 10% or so of
LIR need to come back to ask for a second allocation within 5 years.

Dividing on strange bit boundaries (eg. /35) in combination with the
format of writing IPv6 addresses makes notation and calculation very
hard for most people and will result in many mistakes over time. In
such a large address space the benefits of always making allocations
on a 4 bit boundary are greater than the resulting inflexibility. This is
seen in the original TLA /16 and NLA /24 proposals.

Allocations should be at /16, /24 or /32 - possibly /20 /28. Sub
allocations by LIR to their customer ISPs should similarly be /32 /40,
or possibly /36 /44.


Present Allocation sizes:

Bit usage density should be allocated evenly over the addressing
hierarchy. I could use rfc1715's h-ratio here but refuse to use a
measurement unit where everything is squashed between 0 and 0.301.

At present a "site" has 80 bits (fixed at /48). Of these the average
usage is likely to be 10 to 100 nodes (ranging from 10k for a medium
corporation to 1-5 for the far more predominant home user). The usage
density is therefore approx: 2^80/100 or well over 1 in 10^20 !!!

can be certain there will not be more than around 100,000 top level
routes. Accordingly the usage density is 2^35/100,000 or approx 1 in
350,000.

An LIR with a present /35 and only a single customer (/48) has already
reached a density of 1 in 8192 !!!

Does anyone know why the service provider is treated differently ?


The need for hierarchy within an LIR:

In practise an LIR must introduce hierarchy to prevent excessive
routes. Global LIRs must do this at multiple levels.

Typically a Global LIR might have about 10 regions and about 10 areas
per region - although hopefully these would not all be fixed in
size. This hierarchy must be set at the outset, although a fraction
(say up to 2/3) could be reserved to provide additional resources to
areas/regions that grow faster than originally expected.

In each of these approx. 100 areas, the larger LIRs (national or
global) will have predominantly X customers who are small and/or medium
size ISP's. The smallest of these would typically expect to have
enough addresses to serve 256 customers - /40.

Accordingly a minimum allocation for such an LIR forseeable at the
outset is at least a /24.


Minimal initial allocation based on registered IPv4 usage

We must not allocate too few addresses to an LIR since this will cause
problems for us all, and especially him and his customers now and in
the future. Since addresses are not in short supply, and one of the
worst mistakes an RIR can make is to allocate too few addresses, a
minimum first allocation could be based on the customers current
REGISTERED IPv4 usage.

In fitting with the above sections a possible simple yet flexible
approach would be to adopt the following table:

Small          - /40
Medium         - /32
Large/National - /24
International  - /16

These categories also fit extremely well with the present RIPE
membership categories which could help reduce administrative checking
of claims to be Large/National, etc.

Until Multihoming issues are sorted (see also below) we must adopt a
similar approach to corporate LIRs. With the category used calculated
as if they were not a corporate LIR.

A side effect of this rule is that it will encourage owners of
historical non-registered allocations to register them with one of the
RIRs (if they want an appropriate IPv6 allocation).

These are minimum initial allocations. Larger initial allocations can
be requested if appropriately justified. For example a new 3G UMTS
consortium operating in a major european country but which has no LIR
background would typically qualify for the same prefix as a
large/national LIR


Usage requirements for additional allocations:

IPv4 addresses are in short supply, appropriately there is therefore a
rule stating that 80% of addresses at each level must be "used" before
additional addresses are "provided".

In IPv6 this rule is not only invalid, it just does not make
sense. Even more crazily, RFC2450 states 90% !!!

In order to prevent stupid wastage and bad network design, this rule
should not be relaxed below about 10% (I am reminded of a network I
came across using RFC1916 addresses where a /16 was assigned to each
of 100 sites - which varied from 5 to 10,000 nodes). In contrast 80%
or 90% is unnecessary and unreachable in IPv6 where addresses are
not a scarce resource.


Multihoming and allocations to non-service providers:

At the time of writing no fully satisfactory multihoming technique is
available. We must therefore provide current owners of globably routed
IPv4 address space with a TLA with an appropriate mask.

Failure to do this will actively discourage organisations considering
a move to IPv6. We must be pragmatic, and at the same time encourage
IPv6 use.