[ppml] IPv6 assignment - proposal for change to nrpm

Mon Oct 22 11:09:11 EDT 2007

Speaking as an ISP..  albeit a small one, my plan (when customers start
asking for IPv6) is to grant all customers who request more than a host
subnet a minimum of a /120, and to be very liberal in allowing shorter
lengths.  I will have no problem giving a customer a shorter prefix if
they tell me they have a couple thousand toasters in need of IP
addresses.  

Kevin

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of briand at ca.afilias.info
> Sent: Saturday, October 20, 2007 1:37 PM
> To: Keith Medcalf
> Cc: ppml at arin.net
> Subject: Re: [ppml] IPv6 assignment - proposal for change to nrpm
> 
> >
> > 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.
> >>
> >
> >
> >
> >
> 
> 
> _______________________________________________
> 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.
> 