[ppml] IPv6 assignment - proposal for change to nrpm

[briand at ca.afilias.info]

>
> This is a very bad idea.  The requirement that a "minumum" end-user site
> assignment of a /64 is the only thing that will permit many Legacy /24
> holders (such as myself) who are single-homed use IPv6 at all.

I'm interested in understanding this proposition.
Can you explain why you believe /24 Legacy holders would not be able to
use, for example, a /120?

Or any other prefix length in between /64 and /120?

I suggest /120, because as a /24 holder, the only viable addressing
options are static, and DHCP.

And for a /24, there are only 8 bits of host available for assignment.

Static and DHCP are both supported in IPv6, and 8 bits of host are
obviously supported with a /120.

This is not to say, that if you present an addressing plan that shows
you need 24 bits of address space (for whatever reason), that they would
not be able to, or would not be willing to, assign a /104.

> Either you have to require a minimum /64 PA end-user delegation by ISPs
> *or* you have to make it so that anyone who wants a /64 can qualify for a
> PIv6 /64 (or larger) direct assignment.

What is it, specifically, about /64 that you feel is the minimum
requirement, not just for you, but for *everyone*?

And besides, what makes you think that the existence of a smaller minimum,
will in any way affect the *maximum* size that an ISP will willingly
delegate to and end-site or end-user?

I think, given the vast amount of space any ISP will have, will encourage
the adoption of customer-responsive allocation policies, e.g. if you have
a given block /N from one ISP, that every other ISP you connect to will
be happy to give you a block of size /N, unless N << 64 - in which case
you would probably want to provide some kind of justification.

The purpose of recommendations is to give ISPs who don't have a handle
on IPv6, a rough idea on how many ways their customers *can* use it,
and what kinds of request they should expect to see. If neither the ISP
nor the ISP's customer has much IPv6 experience, the recommendations are
intended to give both an idea of what others in the industry generally do.

And the intent of *that*, is so that an end-user, in requesting space
from a second ISP (who is more IPv6-experienced) won't get any unpleasant
surprises.

It is, in effect, an early "best common practices" for a period in time
before there are *any* common practices, good or bad - with the intent
of ensuring that things don't go collectively to the dogs from day one.

> The purpose of ARIN is *not* to ensure the profitability of carriers and
> ISPs by imposing unreasonable limits on the availability and usability of
> the network.

That is true.

However, I think you would agree that anything which is bad for *all* ISPs
and carriers, is bad for the Internet.

And, for good or bad, ARIN does what its members tell it to. Those members
generally need to work towards consensus, and all benefit from policies
which benefit most (if not all) and harm none.

> Therefore I would very actively and vocally oppose any such attempted
> change to policy.

I see it as a clarification of policy, rather than a change.

The policy is quite old, and predates completed specification and available
implementations of the likes of DHCPv6.

But I, like most participating on PPML, am interested in hearing the voices
of those with whom we disagree - since without dialog, there can not be
consensus.

Brian

>> -----Original Message-----
>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On
>> Behalf Of briand at ca.afilias.info
>> Sent: Thursday, 18 October, 2007 19:18
>> To: ARIN PPML
>> Subject: [ppml] IPv6 assignment - proposal for change to nrpm
>>
>> I propose changes to the current text of 6.5.4.1:
>>
>> Currently, it reads:
>>
>> 6.5.4.1. Assignment address space size
>>
>> End-users are assigned an end site assignment from their LIR
>> or ISP. The
>> exact size of the assignment is a local decision for the LIR or ISP to
>> make, using a minimum value of a /64 (when only one subnet is
>> anticipated
>> for the end site) up to the normal maximum of /48, except in cases of
>> extra large end sites where a larger assignment can be justified.
>>
>> The following guidelines may be useful (but they are only guidelines):
>>
>>     * /64 when it is known that one and only one subnet is needed
>>     * /56 for small sites, those expected to need only a few
>> subnets over
>> the next 5 years.
>>     * /48 for larger sites
>>
>> For end sites to whom reverse DNS will be delegated, the
>> LIR/ISP should
>> consider making an assignment on a nibble (4-bit) boundary to simplify
>> reverse lookup delegation.
>> [...]
>>
>> -----
>>
>> I propose the following as a replacement for the text:
>>
>> 6.5.4.1. Assignment address space size
>>
>> End-users are assigned an end site assignment from their LIR
>> or ISP. The
>> exact size of the assignment is a local decision for the LIR or ISP to
>> make, using a minimum value of a /120 (when only one subnet
>> is anticipated
>> for the end site) up to the normal maximum of /48, except in cases of
>> extra large end sites where a larger assignment can be justified.
>>
>> The following guidelines may be useful (but they are only guidelines):
>>
>>     * /120 for a very small customer with one subnet, using static
>> assignments or DHCPv6
>>     * /116 for a small customer with a few subnets, using static
>> assignments or DHCPv6
>>     * /112 for a medium size customer with a significant
>> total number of
>> hosts and/or subnets, using static assignments and/or DHCPv6
>>     * /96 for large customers
>>     * /80 for very large customers, or for customers using a proposed
>> modified version of V6-autoconf
>>     * /64 when it is known that one and only one subnet is
>> needed, for a
>> customer that absolutely requires either traditional IPv6
>> autoconfiguration, or IPv6 host Interface Identifier cryptographic
>> generation
>>     * /60 for sites where a mix of IPv6-autoconfiguration and other
>> address assignment techiques are required
>>     * /56 for very large sites
>>     * /52 for very, very large sites
>>     * /48 for extremely large sites
>>
>> For end sites to whom reverse DNS will be delegated, the
>> LIR/ISP should
>> consider making an assignment on a nibble (4-bit) boundary to simplify
>> reverse lookup delegation.
>>
>> -----
>> The timeframe for the proposed change: immediate.
>>
>> The intent is to provide more current guidance, to both ARIN members,
>> and to ARIN staff, based on available IPv6 technology, and for the
>> encouragement of efficient assignment of IPv6 address space.
>>
>> Brian Dickson
>> Afilias
>>
>> _______________________________________________
>> 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.
>>
>
>
>
>