[ppml] IPv6 assignment - proposal for change to nrpm

Scott Leibrand sleibrand at internap.com
Thu Oct 18 21:22:35 EDT 2007


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



More information about the ARIN-PPML mailing list