<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=text/html;charset=iso-8859-1 http-equiv=Content-Type> <META name=GENERATOR content="MSHTML 8.00.7600.16722"></HEAD> <BODY style="PADDING-LEFT: 10px; PADDING-RIGHT: 10px; PADDING-TOP: 15px" id=MailContainerBody leftMargin=0 topMargin=0 CanvasTabStop="true" name="Compose message area"> <DIV><FONT face=Calibri>This implies that if assigning prefixes shorter than /32 is not possible, then other transition protocols such as TSP or L2TP can be used to enable rapid IPv6 transition. </FONT></DIV> <DIV><FONT face=Calibri></FONT> </DIV> <DIV><FONT face=Calibri>TSP in particular is quite easy to deploy over any type IPv4 access network and with existing CPEs as it can work behind the ISP access modem.</FONT></DIV> <DIV><FONT face=Calibri></FONT><FONT face=Calibri></FONT> </DIV> <DIV><FONT face=Calibri>Regards,</FONT></DIV> <DIV><FONT face=Calibri>-Ahmed</FONT></DIV> <DIV><FONT face=Calibri></FONT> </DIV> <DIV><FONT face=Calibri></FONT> </DIV> <DIV style="FONT: 10pt Tahoma"> <DIV><BR></DIV> <DIV style="BACKGROUND: #f5f5f5"> <DIV style="font-color: black"><B>From:</B> <A title=remi.despres@free.fr href="mailto:remi.despres@free.fr">R�mi Despr�s</A> </DIV> <DIV><B>Sent:</B> Sunday, March 13, 2011 11:22 AM</DIV> <DIV><B>To:</B> <A title=ahmed@tamkien.com href="mailto:ahmed@tamkien.com">Ahmed Abu-Abed</A> </DIV> <DIV><B>Cc:</B> <A title=address-policy-wg@ripe.net href="mailto:address-policy-wg@ripe.net">RIPE Address Policy</A> </DIV> <DIV><B>Subject:</B> Re: [address-policy-wg] IPv6 allocations for 6RD</DIV></DIV></DIV> <DIV><BR></DIV><BR>Le 13 mars 2011 � 07:26, Ahmed Abu-Abed a �crit :<BR><BR>> 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. <BR>> <BR>> 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.<BR><BR>Agreed.<BR>Assigning prefixes shorter than /32 to ISP's that accelerate IPv6 deployment with 6rd is IMHO the right choice to promote IPv6 with native addresses.<BR><BR>Regards,<BR>RD<BR><BR>> <BR>> Regards,<BR>> -Ahmed<BR>> <BR>> <BR>> From: R�mi Despr�s<BR>> Sent: Thursday, March 10, 2011 9:10 PM<BR>> To: Gert Doering<BR>> Cc: Kurt Smolderen ; <A href="mailto:address-policy-wg@ripe.net">address-policy-wg@ripe.net</A><BR>> Subject: Re: [address-policy-wg] IPv6 allocations for 6RD<BR>> <BR>> <BR>> Le 28 f�vr. 2011 � 15:20, Gert Doering a �crit :<BR>> <BR>> > Hi,<BR>> > <BR>> > On Mon, Feb 28, 2011 at 10:13:51AM +0100, Kurt Smolderen wrote:<BR>> >> I strongly support the idea of assigning a smaller prefix to ISPs<BR>> >> which are in a state of deploying IPv6 but need to use transitional<BR>> >> mechanism for (some of) their customers. Mark has described one of<BR>> >> the problems very clear in his email: if an ISP has only a /32<BR>> >> prefix and needs to use all 32 IPv4 bits in the 6rd configuration,<BR>> >> only a /64 can be delivered to the home instead of the desired /56<BR>> >> or /48. Needing all 32 bits is for instance the case when an ISP<BR>> >> offers internet connectivity to some of its customers via a partnership<BR>> >> with another ISP.<BR>> > <BR>> > Without commenting on the general idea of allocating a larger chunk of<BR>> > addresses to ISPs, I want to make sure that the underlying facts are<BR>> > presented correctly.<BR>> > <BR>> > While RFC 5569 (the 6rd RFC) takes the "naive" approach of blindly mapping<BR>> > IPv4 <-> IPv6 using the whole 32bits, it doesn't *have* to be that way<BR>> <BR>> It doesn't have to, right.<BR>> 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.<BR>> For ISPs that have been assigned several IPv4 prefixes (as many have been), the "naive" approach remains the simplest one to operate.<BR>> <BR>> Regards,<BR>> RD<BR>> <BR>> <BR><BR></BODY></HTML>