[ppml] IPv6 addressing, allocation, and subnets

[Tony Hain]

Brian,

Clearly you have yourself wedged into the mindset where you don't want to
deploy /64 subnets. That is fine, and no one is requiring you to. It is also
clear that smart people can come up with cases where the existing IPv6
design is not optimal. The error of their ways though is when they try to
turn these corner cases into something bigger than they are. 

http://www.isoc-au.org.au/06ipv6summit/talks/Ron_Broersma.pdf  shows on
slide 22 that trivial mappings between IPv4 & IPv6 are possible, and the
fact that this has been deployed for years in a non-trivial environment
shows that it does scale, even with /64 subnets. DREN does not do the
trivial 1:1 mapping of host id between versions, but that would be possible
for organizations that find any differences in numbers to be a challenge. 

You are arguing to redesign the protocol in the wrong forum, and the wrong
decade. The time to have made your points was 1995, and even then similar
proposals were considered and rejected. It is time to let this bad idea
go...

Tony

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of
> Brian Dickson
> Sent: Friday, November 16, 2007 1:03 PM
> To: Scott Leibrand
> Cc: ppml at arin.net
> Subject: Re: [ppml] IPv6 addressing, allocation, and subnets
> 
> 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
> _______________________________________________
> 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.