[ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes-InputRequested

JORDI PALET MARTINEZ jordi.palet at consulintel.es
Mon Jan 29 15:02:44 EST 2007


Hi David,

No, using address space from the upstream is not a solution. Example 1, this
ISP has 2 or more upstream providers. Example 2, it has only a dozen of big
customers with big networks, can't risk depending on the addressing space of
the actual upstream (he may decide to change it later and will need to
renumber all the customers).

Regards,
Jordi




> De: David Conrad <drc at virtualized.org>
> Responder a: <drc at virtualized.org>
> Fecha: Sun, 28 Jan 2007 11:08:09 -0800
> Para: <jordi.palet at consulintel.es>
> CC: <ppml at arin.net>
> Asunto: Re: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested
> changes-InputRequested
> 
> Jordi,
> 
> On Jan 27, 2007, at 1:08 AM, JORDI PALET MARTINEZ wrote:
>> A new ISP want to provide dual stack services. Under the current
>> policy, it
>> seems that he will need to have a plan for at least 200 /48.
> 
> That's 200 /48 over _five_ years, right?
> 
>> If the ISP
>> doesn't plan to have that number of customers, he is being forced
>> to lie,
>> otherwise it will not get the IPv6 block allocated.
> 
> If an ISP isn't going to have 200 customers within 5 years, the
> theory goes it should obtain its address space from its upstream
> service provider.  This is the same as with IPv4 and since IPv6 uses
> the same routing tecnology as IPv4, this would appear to make sense.
> 
>> I think this is not good. As said, it is an arbitrary barrier.
> 
> Given limited resources (in this case, it is the routing system),
> there will always be arbitrary barriers.
> 
> Rgds,
> -drc
> 




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

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

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.






More information about the ARIN-PPML mailing list