[ppml] IPv6 addressing, allocation, and subnets

[Stephen Sprunk]

Thus spake Brian Dickson
> 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.

I see nothing in ARIN policy that prevents the use of subnets longer than 
/64 within an end site's assignment.  I can't recall having seen any 
proposals to change that, either.  Finally, I have no objection to people 
doing so if that's what floats their boat.

However, I do have a serious problem with ARIN potentially allowing LIRs to 
assign prefixes longer than /64 to end sites.  If an end site wants to use 
/65 or longer subnets, that's fine with me, but they can take them out of 
the /64, /56, or /48 that they got from their LIR.

ARIN policy should be about the minimum efficiency bar, and everyone should 
be measured according to that standard -- and that standard is a /64 per 
subnet.  If you want to be more efficient, in your view, than that, we do 
not need to change the policy to "allow" it.

> Let's presume that the mapping scheme for one recipient involves
> a large umber 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.

I wasn't aware people were trying to manage their addresses that way.

If you really want to maintain mapped addresses, rather than taking 
advantage of a clean start with IPv6, how about taking a /96 from your /64 
(or whatever) and postpending the entire IPv4 address?  It doesn't get any 
simpler than that.

> 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.)

I don't see why you need the ability to assign a prefix longer than /64 _in 
ARIN's database_.  If the site doesn't want to use all their bits, give them 
a /64 anyways and who cares what they do inside of it?  Why make it ARIN's 
business to know?  There is absolutely _no_ shortage of /64s.

Simply put, I don't care what you do to the right of the /64 boundary, and 
neither should ARIN.  What I object to is making staff pay attention to 
anything past that boundary, and that's what your proposal would do.  And, 
as stated previously, the "guidelines" are bad policy and need to be removed 
from the NRPM in the first place, not enlarged.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking