[ppml] IPv6 assignment - proposal for change to nrpm

[Scott Leibrand]

Brian,

If you can get the protocol experts at the IETF to agree to your 
autoconf change, then I'd consider revising the guidelines to suggest 
reassigning prefixes longer than /64 to end sites.  Until then, I for 
one don't feel like I'm enough of a protocol expert to override their 
guidance on the subject.

-Scott

P.S. As a general rule, please try to keep things simple, unless there's 
a really good reason to add complexity.  That's a good principle to 
follow in engineering, but it's also necessary when making policy.

briand at ca.afilias.info wrote:
>> Brian,
>>
>> This change is not wise.  For better or worse, IPv6 was designed with
>> the last 64 bits as the "host" portion of the address, and there are a
>> number of IPv6 features (such as address autoconfiguration and
>> cryptographically generated addresses) that need those bits to
>> function.  We should not be issuing guidelines that encourage ISPs to
>> assign addresses in such a way as to eliminate the ability to use such
>> features.
>>     
>
> I have given this a lot of consideration...
> (As far as I have been able to find out, those two are in fact the only
> two which depend specifically on /64.)
>
> And, in fact, this is a two-pronged approach at present.
>
> I have a proposal with the IETF to modify the relevant RFCs, so as to
> allow use of /80 prefixes for autoconfiguration, and to tolerate the use
> of /N (instead of fixed value of N=64) for the crypto stuff.
>
> BTW - the /64 comes from EUI-64, which was chosen in anticipation of the
> use of 64-bit MAC instead of 48-bit MAC. Only IEEE-1394 currently uses
> this, whereas 802.* uses 48-bit EUI-48 (aka MAC-48). So, making a change
> to the IPv6 specifications for autoconfiguration is something that will
> support all 802.* devices with hard-coded MACs - although it will still
> require vendor implementation and end-user upgrades.
>
> That proposal, in case anyone is interested in following or participating
> in the IETF discussions around it, is:
>
>     draft-dickson-v6man-new-autoconf-00
>
> and can be found at:
>
> https://datatracker.ietf.org/drafts/draft-dickson-v6man-new-autoconf/
>
> I see what you're saying, but feel that the ability to scale IPv6 usage,
> beyond the short-medium term (1-3 to 3-5 years respectively), is something
> important to the general health of a diverse membership at ARIN (and other
> RIRs as well).
>
> Which is why, rather than let the IPv6 autoconfiguration spec adversely
> affect the global allocation policies, I have chosen to address this
> head-on, by pushing for the IPv6 specs to be *very slightly* changed.
>
> And, even without changing the IETF specs, I think allowing AC to drive
> address space wastage, is poor policy. Yes, we have lots of space, but
> only if we use it wisely. Encouraging end sites to use DHCPv6 instead
> of autoconfiguration, IMHO is a wise recommendation, and will result
> in more conservative levels of allocation - even while being excessively
> generous to end-sites.
>
> Those who allow historical elements to sway technical decisions, are
> as foolish as those who are ignorant of history and thus doomed to
> repeat it. :-)
>
> Respectfully,
>
> Brian Dickson
>   
>> While I don't oppose allowing ISPs to issue /120's to their subscribers'
>> cell phones if they control the technology and know what they are doing,
>> we should *not* be encouraging such behavior as a general practice for
>> consumer ISPs, who do not and should not know or care what kinds of
>> devices the consumer attaches to the network.
>>
>> -Scott
>>
>> briand at ca.afilias.info wrote:
>>     
>>> 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.
>>>
>>>       
>
>
>