[ppml] IPv6 addressing, allocation, and subnets

[Brian Dickson]

Scott Leibrand wrote:
> 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.
>
No,  it's actually the converse of the above.
The problem I'm illustrating is the hammer/nail problem.
If it is not *possible* to do any kind of bit-mapped plan, then we are 
not supporting those who *might* choose to (or need to) do so.
*Allowing* someone to do something, or providing them the means, is very 
different from encouraging it.

On the other hand, if we make it impossible, we are taking away the 
option from anyone who may otherwise benefit from it. We take away all 
tools but the hammer.

And, I believe that those who have the greatest likelihood of having 
non-trivial network addressing under IPv4, and a need to maintain 
dual-stack for such, are those who we *most* want to encourage adoption 
of IPv6 - the content folks.

Making it as easy as possible to migrate to dual-stack as early as 
possible, should be something we keep in mind in considering policies 
for IPv6 allocation.
Even if it isn't ARIN policy (yet) to officially encourage IPv6 
adoption, it *is* policy among other similar groups, whose constituency 
has heavy overlap with ARIN.
> 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.
>
Again, let me emphasize, this has to do with ARIN policy, not my own plans.

Let's presume that the mapping scheme for one recipient involves a large 
number of subnets, more than what would reasonably be expected to have a 
hand-crafted subnet plan.
I'm not sure where you would draw the line, but imagine a case of 
several dozen, say about 80 subnets, of varying sizes, scattered over 
several IPv4 CIDR blocks.

The idea is ongoing management of combined IPv4 and IPv6 dual-stack 
hosts. This would presumably involve adding, removing, and changing 
addresses for hosts.
Having a bit-mapped structure for the management of the combined IPv4 
and IPv6 assignments, is considerably easy to manage than that of 
per-prefix mappings.

Per-prefix mapping scales badly, as it requires maintaining the mapping 
in both directions, for every prefix independently.
As soon as you get beyond double-digits of prefixes, it becomes 
unreasonable to expect anyone to embrace such a scheme.
(I would suggest even at double-digits, many would blanch at the idea.)
> 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.
>
If you read my original post, I did in fact discuss techniques for extra 
host bits - add those in the middle, by padding. Pad every host with M 
bits of zeros (or any value you care to use).
Map every prefix to (Y::) | ::(Yn<<M) (bit-shift each IPv4 prefix by M 
bits before mapping).
> 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.
This is neither about encouraging, nor about requiring, a particular 
plan. It is about *allowing* it, by providing the essential tools to 
support it.
The only tool needed, currently, is the ability to register allocations 
 >/64 - something I perceive the current policy to prohibit. (And now we 
stray into discussions about policy, rather than about the use cases.)

Brian