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

Fri Apr 14 17:22:28 EDT 2006

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.