<!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>Hi Kurt,</FONT></DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri>If you implement 6RD then an internal network can use
multiple /64s, with each /64 coming from one of the few IPv4 public
addresses such an internal network uses. And all this happens under one /32
assignment.</FONT></DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri>Note that the /64 limitation is specific to 6RD protocol
as I explained in an earlier email. Other transition protocols may not have this
limitation.</FONT></DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri>As for native IPv6 deployment, if you mean IPv6-only
(i.e. not Dual-Stack) then I doubt it has much use for the coming few years as
much of the content and applications are IPv4-only. New translation
protocols, to enable IPv6-only host reaching IPv4 content, are being developed
but they have their limitations.</FONT></DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri>Even deploying Dual-Stack (DS) end-to-end, without
tunneling, is not enough. The logic behind this is content will still be
mostly IPv4 for years to come, while public IPv4 addresses are in very short
supply. Thus one is forced to use private IPv4 addresses for end users, but
these are not routable. The solution is then to tunnel the private IPv4 in
public IPv6 addresses, hence DS-Lite protocol. But this assumes you have a full
Dual-Stack deployment end-to-end; if not then you need to overlay IPv6 over IPv4
using 6RD, TSP or L2TP as an interim solution.</FONT></DIV>
<DIV><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 style="FONT: 10pt Tahoma">
<DIV><FONT size=3 face=Calibri></FONT><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><FONT face=Calibri></FONT><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>