[ppml] IPv6 assignment - proposal for change to nrpm

[Scott Leibrand]

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.

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