[ppml] IPv6 assignment - proposal for change to nrpm

[briand at ca.afilias.info]

Leo Bicknell wrote:
> In a message written on Sun, Oct 21, 2007 at 10:08:25PM -0400,
> briand at ca.afilias.info wrote:

> Thus it would seem to me the risk is small, probably well less than
> 500 ISP's, and likely under 100 who would need a second prefix in
> any reasonable amount of time.  That's hardly table bloat.

The issue I'm trying to point out is:
The consensus in the community is that dual-stack will be around for
a long time, with 10 to 20 years being the predominate view.

And, IPv4 prefix counts will not decrease by any significant amount
during that period.

Dual-stack means the combined prefix counts of IPv4 and IPv6 are
the issue. Bloat of even a small amount in IPv6 may be enough to cause
problems for significant numbers of ISPs who might be adversely affected
at a financial level.

So, if we can adopt policies which avoid causing problems for members
of ARIN, when those policies do not themselves introduce problems, it
would seem like a wise course of action.

>> Static assignments and DHCPv6 assignments, for prefixes > /64, are not
>> only
>> possible, but fully compatible with the IETF specifications.
>
> However, they do preclude the use of IPv6 autoconfiguration.

> It is for that reason I can't support any ARIN policies requiring
> an ISP to allocate longer than /64 prefixes.

I'm pretty sure the way I worded my proposal was the encouragement of,
not the requirement of, ISPs allocating longer prefixes.

I will go further in the details of what I will propose as a recommendation:
that ISPs give out /64's or shorter, only when a customer *specifically*
requests such with justification showing a network plan using auto-v6.
It isn't a question of saying "never"; it's just a question of saying,
let's not always assume auto-v6, and instead ask customers about their
needs/plans. (Ideally, this would be a nice intro/wiki kind of thing.)

> But back to your current goal.  Get the IETF to deprecate IPv6
> auto-configuration; which will remove the /64 boundary as sacred.
> At that point I'd be willing to talk about prefixes longer than a
> /64 being required, until then it's premature.

I'm working on them. Having support from the operator community, which
says in principal, "We endorse the removal of /64 as a sacred boundary,
and would like to see whatever revisions are needed to accomplish that
implemented, ASAP", would go a long way to achieving that result.

Like ARIN, the IETF is receptive to overwhelming support for proposals. :-)

Brian