[ppml] Proposed Policy: Proposal to amend ARIN IPv6 assignment and utilisation requirement

[Rich Emmings]

I've been trying to get some time to give this the time it needs.

>> Does this proposal help with a short term problem, or promote
>> the adoption of IPv6?
>
> Since the potential problem is long term, we shouldn't do
> anything about it?

/56 or /48 today doesn't effect things in the long term, as we can adapt 
when needed to those, (or to a /60 or /52) once we have a track record
and more real world experience.

>
>> Large scale introduction of /56 addresses may also increase
>> the global routing table size.
>
> How?  It might increase your local routing table size, but
> ISPs (LIRs) will still aggregate at their borders, unless
> leaking is required, and even then, a /56 doesn't take up
> more router slots than a /48.
>

I'm guessing announcement of the longest prefixes will continue to happen in 
IPv6 for several reasons.  I'll concede that it doesn't matter what the 
least prefix size is, /56 or /48, with regard to this, but my guts are 
telling me the smaller the prefixes out there, the more routes that will be 
there.

>
>> End site assignment of a /48 is a recommendation and nothing
>> prohibits the assignment of a /56 downstream where appropriate.
>
> http://www.arin.net/policy/nrpm.html#six54 :
> --
> 6.5.4. Assignment
>
> LIRs must make IPv6 assignments in accordance with the following
> provisions.
>
> 6.5.4.1. Assignment address space size
>
> Assignments are to be made in accordance with the existing guidelines
> (RFC3177,RIRs-on-48), which are summarized here as:
>
> - /48 in the general case, except for very large subscribers
>

'general case' makes it a little soft for me, they could have used 'must' as above.
but I'm not unwilling to concede it's a mandate.


> So you advocate setting policy based on the .001% case?  No
> network left behind?

No, more "let's get on with it" and deal with changes that are needed to 
implement, not keep polishing the cannonball.

>> Changes slow implementation.  That some of these changes are
>> necessary doesn't alter the impact.
>> At this time, this is an unnecessary change, so let's skip it
>> and move on to implementation issues.
>
> I'm in favor of building right the first time, and in assigning
> appropriate levels of resources.
>

There are 5 /3 blocks left reserved, all the size as 2000::/3.  Less than 
half of 2000::/3 is allocated to RIR's.  Once that space is allocated we'll 
have more real world information with which to backup decisions.

There's a lot of space out there.  I don't think many people fathom the 
concepts of 2^128.  Even a mere billion dollars would take you over 10 years 
to spend at $10,000 per hour.

No system will be perfect, we have room to adjust it later, and there's 
enough space out there that we're not at risk of running out over the short 
term.

Perhaps table things for a year, or, until we need to think about issuing 
4000::/3, and see what real world experiences suggest then?