[address-policy-wg] IPv6 allocations for 6RD

If simplicity in IPv6 transition means initially offering IPv6-over-IPv4 to subscribers while meeting 2 fundamental requirements, namely end-user prefix delegation and commercial hardware CPE support, then there are 3 protocols that can be used depending on the service provider requirements: 6rd, TSP and L2TP. 

If implementing 6rd, service providers may need an allocation larger than /32 as the 6rd protocol embeds the users IPv4 address, or part there of, in their IPv6 address. 

Regards,
-Ahmed



From: Rémi Després 
Sent: Thursday, March 10, 2011 9:10 PM
To: Gert Doering 
Cc: Kurt Smolderen ; address-policy-wg at ripe.net 
Subject: Re: [address-policy-wg] IPv6 allocations for 6RD



Le 28 févr. 2011 à 15:20, Gert Doering a écrit :

> Hi,
> 
> On Mon, Feb 28, 2011 at 10:13:51AM +0100, Kurt Smolderen wrote:
>> I strongly support the idea of assigning a smaller prefix to ISPs
>> which are in a state of deploying IPv6 but need to use transitional
>> mechanism for (some of) their customers. Mark has described one of
>> the problems very clear in his email: if an ISP has only a /32
>> prefix and needs to use all 32 IPv4 bits in the 6rd configuration,
>> only a /64 can be delivered to the home instead of the desired /56
>> or /48. Needing all 32 bits is for instance the case when an ISP
>> offers internet connectivity to some of its customers via a partnership
>> with another ISP.
> 
> Without commenting on the general idea of allocating a larger chunk of
> addresses to ISPs, I want to make sure that the underlying facts are
> presented correctly.
> 
> While RFC 5569 (the 6rd RFC) takes the "naive" approach of blindly mapping
> IPv4 <-> IPv6 using the whole 32bits, it doesn't *have* to be that way

It doesn't have to, right.
But, if being native permits to deploy good IPv6 service to the masses before other means to do it are available, being naive is better than being overly purist.
For ISPs that have been assigned several IPv4 prefixes (as many have been), the "naive" approach remains the simplest one to operate.

Regards,
RD


-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20110313/77b01ad4/attachment.html>