[ppml] IPv6 addressing, allocation, and subnets

[This message/thread is intended to provide further context for 
discussions on IPv6 allocation policies.
 I have one request: please refrain from discussion *of* those policies 
within this thread, if possible.]

Addressing schemes and allocation policies, *within* an organization, 
can and do vary substantially.

I would like to illustrate some non-trivial situations, which lead to 
some such schemes.

And, most importantly, how managing combined IPv4 and IPv6 addressing 
schemes is one area of special importance when considering policies 
specific to IPv6.

First, let's dispose of the trivial situations.

These would include, but are not limited to:
- greenfield networks doing IPv6 only
- client-only networks (e.g. consumer ISPs with dynamic IP address 
allocation only)
- sites using autoconfiguration only

(In fact, the greenfield situation isn't necessarily trivial, as we will 
discuss below; however, we don't want to add to the confusion just yet.)

So, we want to take a look at networks where:
- both IPv4 and IPv6 are in use, or will be in use
- some of the IP addresses are assigned to hosts, where the addresses 
assigned do not change
- there is more than one prefix in use within the site (otherwise, this 
too is a "trivial" set-up)

When there is more than one prefix in use at a site, in the IPv4 world, 
there are many possible reasons:
- growth - hosts needed to be added to a subnet, and renumbering was not 
feasible, so additional prefixes were added to the same physical LAN
- separation - the need to keep functional separation between sets of 
hosts (e.g. clients and servers, for security domain reasons)
- utilization - too much traffic existed on a single LAN, and the LAN 
was partitioned to accommodate the traffic
- portability - in anticipation of relocating servers or sets of 
servers, they were numbered from different prefixes from the outset, so 
that relocation would not require renumbering


Certainly, the last three (separation, utilization, portability) are 
invariant across IP versions - the same situation would exist under both 
IPv4 and IPv6.
Any of those reasons would require subnet usage, whether under IPv4 or IPv6.

As to growth, in the IPv6 world, *future* growth would likely be 
trivially accommodated within the sizes of subnets available.
And at some point, IPv4 growth will cease to be viable, so nearly all 
growth would need to be handled within IPv6 address blocks.
However, if a non-trivial amount of sub-netting due to growth existed in 
IPv4, the same rules for the other three subnet conditions are likely to 
apply.

When establishing a network plan for a dual-stack environment, where 
there is already a significant deployment of IPv4, and the above 
situations exist (separation, utilization, portability), management of 
the addressing scheme is an important consideration.

The easiest scheme is that of a direct mapping.
Treat the sub-netting scheme from one or more blocks, as a tree with a 
single root, and map that wholesale onto an IPv6 prefix.
The host portion of each subnet would be numbered identically, 
permitting very scalable management of the IP addressing for both IPv4 
and IPv6 for all such dual-stack hosts.

Advanced versions may introduce extra bits into the subnet scheme by 
left-shifting and zero-padding, by some number of bits, for the whole 
network plan.
For example, VLSM scheme consisting of  three /26's, a /27, and two 
/28's, numbered out of a single /24, instead of being mapped onto a 
/120, might be mapped onto a /12, expanding each prefix by 8 bits.
The prefixes would be three /114's, a /115, and two /116's. The hosts in 
the /27 (ranging from .1 to .31) would still have the same last 5 bits, 
but there would now be 13 bits of host on that prefix.

In the absence of the ability to assign prefixes longer than /64, the 
management of dual-stacked hosts becomes a nightmare.

Rather than treat the whole tree as a mapped entity, each prefix in the 
tree would need a corresponding mapped prefix.
This is something which demonstrably does not scale, and the larger the 
original prefix, the greater the pain.

Let's consider some examples of methods which can *only* work if 
assignments of subnets > /64 are possible.

Consider an ISP X, who has customers Y and Z. Both Y and Z have multiple 
IPv4 prefixes assigned to them by X, all of which are PA.
X intends on offering IPv6 service to Y and Z in addition to IPv4. These 
too will be PA assignments.

What X would like to do, is give Y and Z the easy way out - have IPv6 
blocks for each, suitable for mapping their non-continguous IPv4 
assignments.
This would be trivially possible by using a /96 for *each* of Y and Z, 
or even a larger block, such as a /88 or even a /80.

Mapping all of Y's existing IPv4 prefixes would be done by the trivial 
binary "OR" of the new IPv6 block for Y, call it Y::/96, and the 
existing 32-bit values for the IPv4 prefixes, Y1, Y2, ..., Yn, as 
128-bit values "::Yn".
The trees for Y and Z will be sparse, of course, but will have 1:1 
address mapping for all IPv4 and IPv6 addresses used by Y and Z.
(The trick is, the mapping is different for Y and for Z.)
The original blocks in IPv4 would contain intermingled Y and Z prefixes, 
within blocks assigned to X.
The mapped blocks would separate out the Y and Z components, within 
sparse copies of the mapped *entire* IPv4 space.
The number of blocks that X would need to maintain would be N, the 
number of customers of X, rather than M*N, the number of assignments 
made to all customers in the history of X.

If X is not able to make assignments > /64, or to register those 
assignments, all of this is impossible, or alternatively, must allocate 
a huge amount of space per customer to handle these mappings.

For example, of Y has prefixes as long as /29, and address space from 
both traditional class "A" and class "C" space, then 29 bits are needed 
for a mapping region.

The smallest prefix able to handle the whole range of Y's existing IPv4 
space, as a 1:1 single mapping into IPv6, would be a /(64-29) or a /35.

The only other options are for Y to be given multiple IPv6 assignments by X.
In other words, by making the IPv6 assignments the same as, or even 
worse than, the IPv4 assignments.
(Worse than, because every assignment would be a /64.)

If you were X, would you be in any rush to do this, until customers 
requested IPv6 space?

And would you even *try* to handle requests in any manner other than as 
new requests, rather than support customers wanting to do such mappings?

Brian Dickson