<!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>Greetings,</FONT></DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri>Compared to 6RD, the TSP protocol (RFC 5572) can also 
rapidly deploy IPv6, needing one /32 allocation while customer site prefixes can 
be /64, /56 or /48. Reason is TSP doesn't embed the customer's IPv4 address in 
its IPv6 address as 6RD does.</FONT></DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri>Being a hot topic nowadays, its worth mentioning 
customer site access gear (CPE) requirements are more relaxed with TSP as it 
doesn't need the Service Provider IPv4-only access modem to be changed or 
upgraded. A TSP client can run in a small hardware device (thru an Ethernet 
interface connection) or a software client in the home network behind the SP 
modem while enabling all v6 capable nodes with the assigned prefix by 
automatically establishing a tunnel to the SP TSP tunnel server.</FONT></DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri>Since TSP allows for static prefix assignment and larger 
prefixes than /64 without wasting v6 space, this would mimic a native deployment 
more closely. The stateful tunneling could be seen as any other encapsulation in 
the access, and a few service providers have it running already.</FONT></DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri>In the long term, both 6RD and TSP will give way to 
reverse tunneling i.e. v4-in-v6, as this is the only way (after IPv4 depletion) 
for both protocols to co-exist on a host while having a mix of v4-only and 
dual-stack accessible services/website. Reverse tunneling's current protocols, 
DS-Lite and DSTM, are very similar to TSP's concept so the same clients 
& servers supporting TSP can be adapted to support DS-Lite.</FONT></DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri>Unfortunately, until IPv4 disappears from web content, 
hosts and servers these coexistence mechanisms will be needed.</FONT></DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri>Regards,<BR>-Ahmed<BR></FONT></DIV>
<DIV><FONT face=Calibri> </DIV></FONT>
<DIV style="FONT: 10pt Tahoma">
<DIV><BR></DIV>
<DIV style="BACKGROUND: #f5f5f5">
<DIV style="font-color: black"><B>From:</B> <A title=K.Smolderen@edpnet.net 
href="mailto:K.Smolderen@edpnet.net">Kurt Smolderen</A> </DIV>
<DIV><B>Sent:</B> Monday, February 28, 2011 11:13 AM</DIV>
<DIV><B>To:</B> <A title=address-policy-wg@ripe.net 
href="mailto:address-policy-wg@ripe.net">address-policy-wg@ripe.net</A> </DIV>
<DIV><B>Subject:</B> RE: [address-policy-wg] IPv6 allocations for 
6RD</DIV></DIV></DIV>
<DIV><BR></DIV>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.<BR><BR>However, I want to point to an additional problem which 
appears when an ISP wants to deploy native IPv6 but needs to roll out 6rd (or 
any other transitional technique) as well. For native IPv6, the ISP will create 
an IPv6 addressing plan. This will normally include separate prefixes for the 
ISP's own servers, the ISP's backbone, the ISP's customers etc. For the 6rd 
domain, the full /32 range is however needed. So at this stage, the ISP has two 
options:<BR>1) Implement 6rd only<BR>2) Implement native IPv6 only and exclude 
some customers from being able to use IPv6 (those which would normally be 
connected through 6rd)<BR><BR>I strongly believe we all agree 6rd is only a 
temporary solution. So I can't imagine we would prefer skipping native IPv6 
deployments in favor of IPv6 transitional mechanisms.<BR>I also believe we all 
agree we should enable IPv6 for as much customers as we can, which makes me 
conclude the second 'option' is not really an option at all...<BR><BR>My primary 
concern is that any ISP - regardless of how small or big it is - can 
independently of other organizations/ ISPs move forward with IPv6 deployment. 
RIPE can support this by adapting a policy which - albeit for a limited time 
span - allows the assignment of a contiguous IPv6 prefix which size does not 
only depend on the amount of customers the ISP has, but also incorporates the 
needed technologies to 'IPv6-enable' as much customers as 
possible.<BR> <BR>Regards,<BR>-Kurt<BR></BODY></HTML>