[ppml] IPv6 addressing, allocation, and subnets

[Scott Leibrand]

Brian,

Do I understand your argument correctly that you perceive the primary 
driver for IPv6 addressing plans to be compatibility with (and 
similarity to) the existing IPv4 plans?  If so, then your argument that 
we need to do things similarly to how we do them in IPv4 applies, 
because your goal is to have everything as similar as possible to the 
IPv4 setup.

An alternative, however, would be to set your IPv6 addressing plans up 
to be independent of your IPv4 addressing plan (which, as you outlined, 
often comes with a lot of cruft due to networks and subnets being too 
small to accommodate growth).  In such a scenario, you could choose to 
have all subnets be /64 (to accommodate currently-deployed 
autoconfiguration methods as well as addressing methods like HBA and 
CGA).  There is no reason for an IPv6 subnet to be larger than /64: just 
because you assign a /64 for a LAN with an IPv4 /29 doesn't mean you 
need a /63 for a LAN that got a /28.

If you don't want/need autoconfiguration, HBA, or CGA, you're free to 
deploy subnets smaller than /64.  However, doing so comes with risks, as 
you may decide in the future that you really do need extra host bits.   
If those risks (or your renumbering costs) are negligible, that's fine.  
However, I think it's a mistake to encourage people to simply bit-map 
their IPv4 addressing architecture into IPv6 without considering whether 
such an addressing plan is ideal given the new capabilities of IPv6.

In summary, I think you have correctly identified bit-mapping from IPv4 
as one possible IPv6 addressing plan.  However, I think it would be a 
mistake to encourage (or worse, require) networks to do such mapping, 
thereby incorporating complexity from their IPv4 addressing plan into 
their IPv6 network, without carefully considering whether a new 
addressing plan would be more appropriate for the IPv6 portion of their 
network.

-Scott

Brian Dickson wrote:
> [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
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
>