[ppml] IPv6 addressing, allocation, and subnets
briand at ca.afilias.info
Fri Nov 16 14:53:16 EST 2007
[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
- 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
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
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
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?
More information about the ARIN-PPML