[ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Last Call

Sat Apr 15 10:31:13 EDT 2006

Hi Scott,

No, that's a broken concept. We need to keep the IPv6 property of /64 for
each subnet, in order to be able to use autoconfiguration, privacy, CGAs,
etc.

Regards,
Jordi

> De: Scott Leibrand <sleibrand at internap.com>
> Responder a: <sleibrand at internap.com>
> Fecha: Sat, 15 Apr 2006 09:14:44 -0400 (EDT)
> Para: JORDI PALET MARTINEZ <jordi.palet at consulintel.es>
> CC: "ppml at arin.net" <ppml at arin.net>
> Asunto: Re: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6
> assignment and utilisation requirement - Last Call
> 
> A meta-question:
> 
> If you end up needing more than 256 subnets for your house, and have a /56
> or even a /64, can you make your subnets /65's, /66's, etc?
> 
> -Scott
> 
> On 04/14/06 at 11:22pm +0200, JORDI PALET MARTINEZ
> <jordi.palet at consulintel...:
> 
>> Hi Scott,
>> 
>> See below, in-line.
>> 
>> Regards,
>> Jordi
>> 
>> 
>> 
>> 
>>> De: Scott Leibrand <sleibrand at internap.com>
>>> Responder a: <sleibrand at internap.com>
>>> Fecha: Fri, 14 Apr 2006 16:35:25 -0400 (EDT)
>>> Para: JORDI PALET MARTINEZ <jordi.palet at consulintel.es>
>>> CC: "ppml at arin.net" <ppml at arin.net>
>>> Asunto: Re: [ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6
>>> assignment and utilisation requirement - Last Call
>>> 
>>> On 04/14/06 at 10:23pm +0200, JORDI PALET MARTINEZ
>>> <jordi.palet at consulintel...:
>>> 
>>>> Hi,
>>>> 
>>>> While I don't agree with this proposal (I still believe a default /48
>>>> should
>>>> be assigned to any end-site if is non-portable space),
>>> 
>>> Why?  Do you think that a site with 65,000 subnets can claim to just be a
>>> non-business residential customer?
>> 
>> Yes I know from current research of services and products that will be in
>> the market in the next few years, that residential customers will need more
>> than 256 subnets.
>> 
>> I'm not so convinced about 65.000 subnets, but I'm given the choice in
>> between 256 subnets or 65.000 subnets, I much prefer to be sure than became
>> short.
>> 
>> And I'm still talking about homes (smart homes if you want to say), so
>> residential customers, not business customers. However, there is more and
>> more people working from their home, may be you want to consider them a
>> special case also ;-)
>> 
>>> 
>>>> I would accept it, if the final text of the policy make sure that an
>>>> end-site has the right to request to the LIR for being upgraded from the
>>>> /64 or /56 to the /48 without the need for a detailed justification (as
>>>> otherwise may go against the end-site right to privacy) and the end-site
>>>> can get that upgrade at no extra recurrent costs (a setup fee is
>>>> acceptable if it match real costs for that and a small recurrent cost
>>>> which match the *real* cost for that space as paid to the RIR will be
>>>> also acceptable).
>>> 
>>> This sounds to me like something *way* outside of ARIN's authority.
>> 
>> I'm not sure in the case of ARIN, but in other registries, the charging by
>> LIRs to end-customers is expected to be to cover their administrative costs,
>> not to make money out of the addresses and ASNs, which are a human property.
>> 
>> On the other way around, the LIRs need to understand that charging for the
>> addresses at the end is against their business. I've already talked about
>> this in other occasions. In Spain you pay typically 12 Euros for each IPv4
>> address per month (while the cost of the ADSL line is now 20 Euros,
>> including free national phone calls). Obviously the ISPs aren't making any
>> *real* business, because almost none of the 4.5 million broadband users in
>> the country pay for that. However, this makes almost impossible to the ISPs
>> to deploy easily new services and applications which can be charged for and
>> thus make much more profit than with the 12 Euros per address (not to say
>> the extra cost of running NAT and providing support for the problems caused
>> by NAT).
>> 
>> Unfortunately, most of the ISPs, still don't see that and I doubt that in
>> the short term they will see it. As said, I want to make sure that users
>> don't end up paying for that and ISPs realize that the business is in the
>> added value services and applications. Is the only way IPv6 will succeed.
>> 
>> But even if you don't agree with me about the cost issue, may be you agree
>> that the end-user don't need to justify why he needs more subnets and has
>> the right to keep his privacy. This is clearly part of ARIN authority.
>> 
>> Same with avoiding the renumbering, otherwise, we are unfair defining policy
>> that avoid renumbering to LIRs, right ?
>> 
>>> 
>>>> Is also important that the user upgrading from a /64 or /56 to a /48
>>>> don't need to renumber, so I will suggest that the ISP need to keep
>>>> reserved the complete /48.
>>>> 
>>>> For those that believe that reserving the /48 is a space waste, I will
>>>> suggest to understand that this can be changed in the future (possible in
>>>> hundreds of years, in my opinion) if we really come into a situation where
>>>> we have to use the reserved space, even if that means renumbering some or
>>>> all the end-sites (I'm considering that most of the end-sites that will
>>>> fall
>>>> into this situation will be residential customers). Renumbering once in
>>>> hundreds of years should not be considered as a trouble, as most probably,
>>>> residential users don't keep the same provider for so long time ...
>>>> 
>>>> What I'm trying to avoid here is the situation that we have today which
>>>> users being forced to NAT and a single dynamic IPv4 address, which can turn
>>>> in a few years from now in something similar if you only get a /64 and need
>>>> /56 or /48.
>>> 
>>> Do you think that a home network will need more than a million host
>>> addresses within "a few years from now"?  I don't.
>> 
>> Is not a question of how many addresses. It may be the case that we only use
>> a few addresses of each subnet. That's fine, is part of the design of IPv6
>> that we accepted, which has lots of advantages, like the capability to run
>> auto-configuration, privacy, CGAs, and for sure more to come.
>> 
>>> 
>>> I do agree that home users may want to run more than one subnet, and may
>>> want more than one /64.  Therefore I agree with the guideline that /64's
>>> should only be given out when it is known a priori that one and only one
>> 
>> Which I will interpret as almost never a /64 should be given out (may be
>> only for a cellular phone and only if it is not connecting other devices
>> with other interfaces, otherwise is a mobile router).
>> 
>>> subnet is needed, and that a /56 should be given out otherwise.  However,
>>> I think that anyone who actually needs a /48 really should be considered a
>>> business customer, not a residential customer.
>> 
>> As said, this is no longer the case if we look to the situation that can be
>> expected in a very few years.
>> 
>>> 
>>> -Scott
>>> 
>> 
>> 
>> 
>> 
>> **********************************************
>> The IPv6 Portal: http://www.ipv6tf.org
>> 
>> Barcelona 2005 Global IPv6 Summit
>> Slides available at:
>> http://www.ipv6-es.com
>> 
>> This electronic message contains information which may be privileged or
>> confidential. The information is intended to be for the use of the
>> individual(s) named above. If you are not the intended recipient be aware
>> that any disclosure, copying, distribution or use of the contents of this
>> information, including attached files, is prohibited.
>> 
>> 
>> 
>> _______________________________________________
>> PPML mailing list
>> PPML at arin.net
>> http://lists.arin.net/mailman/listinfo/ppml
>> 
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.