<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:v = "urn:schemas-microsoft-com:vml" xmlns:o = 
"urn:schemas-microsoft-com:office:office" xmlns:w = 
"urn:schemas-microsoft-com:office:word" xmlns:m = 
"http://schemas.microsoft.com/office/2004/12/omml"><HEAD>
<META content=text/html;charset=iso-8859-1 http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.7600.16722">
<STYLE><!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {mso-style-priority:99;
        mso-style-link:"Balloon Text Char";
        margin:0cm;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0cm;
        margin-right:0cm;
        margin-bottom:0cm;
        margin-left:36.0pt;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
span.BalloonTextChar
        {mso-style-name:"Balloon Text Char";
        mso-style-priority:99;
        mso-style-link:"Balloon Text";
        font-family:"Tahoma","sans-serif";}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:324170496;
        mso-list-type:hybrid;
        mso-list-template-ids:1092138122 135462927 135462937 135462939 135462927 135462937 135462939 135462927 135462937 135462939;}
@list l0:level1
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l0:level2
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l0:level3
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
@list l0:level4
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l0:level5
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l0:level6
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
@list l0:level7
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l0:level8
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l0:level9
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
ol
        {margin-bottom:0cm;}
ul
        {margin-bottom:0cm;}
--></STYLE>
</HEAD>
<BODY style="PADDING-LEFT: 10px; PADDING-RIGHT: 10px; PADDING-TOP: 15px" 
id=MailContainerBody lang=NL-BE leftMargin=0 link=blue topMargin=0 vLink=purple 
CanvasTabStop="true" name="Compose message area">
<DIV><FONT face=Calibri>Hi Kurt,</FONT></DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri>In</FONT><FONT face=Calibri> 6RD, part of the 
IPv6 address takes the IPv4 address of the CPE, so there is an 
IPv4 dependency but only in the access side. Note that TSP is 
also supported by CPEs and edge servers solutions.</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><FONT size=3 face=Calibri></FONT><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 4:54 PM</DIV>
<DIV><B>To:</B> <A title=ahmed@tamkien.com href="mailto:ahmed@tamkien.com">Ahmed 
Abu-Abed</A> ; <A 
title="mailto:address-policy-wg@ripe.net CTRL + Click to follow link" 
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><FONT face=Calibri></FONT><BR></DIV>
<DIV class=WordSection1>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt" 
lang=EN-US>Hi Ahmed,<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt" 
lang=EN-US><o:p> </o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt" 
lang=EN-US>Do I understand correctly that you are actually saying that an 
organization should base its IPv6 addressing scheme upon its existing (legacy) 
IPv4 addressing scheme? As this seems to me what one would actually do if you 
drop native IPv6/ dual-stack implementation �in favor� of 6rd� If this is what 
you are pointing at, I really have to disagree as I don�t believe this is the 
way to go. IPv6 is different from IPv4 and so a different addressing plan makes 
sense. So let us give an organization the possibility to do its IPv6 address 
assignments right from the beginning and let�s not force them to get stuck in 
transition methods (as this will convert them into anti-transition mechanisms as 
suggested in a previous message in this thread).<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt" 
lang=EN-US><o:p> </o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt" 
lang=EN-US>Regarding your other remarks/ suggestions:<o:p></o:p></SPAN></P>
<P style="TEXT-INDENT: -18pt; mso-list: l0 level1 lfo1" 
class=MsoListParagraph><SPAN 
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt" 
lang=EN-US><SPAN style="mso-list: Ignore">1.<SPAN 
style="FONT: 7pt 'Times New Roman'">       
</SPAN></SPAN></SPAN><SPAN 
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt" 
lang=EN-US>I do agree 6rd has its limitations, but on the other hand, an 
organization might have some perfect good reasons to prefer 6rd above another 
transition protocol (for instance because it is � in contrary to other 
transition protocols � fully supported by both the CPE devices as well as the 
ISP�s edge routers).<o:p></o:p></SPAN></P>
<P style="TEXT-INDENT: -18pt; mso-list: l0 level1 lfo1" 
class=MsoListParagraph><SPAN 
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt" 
lang=EN-US><SPAN style="mso-list: Ignore">2.<SPAN 
style="FONT: 7pt 'Times New Roman'">       
</SPAN></SPAN></SPAN><SPAN 
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt" 
lang=EN-US>What I actually mean with native IPv6 is dual stack with the IPv6 
stack �free of tunnels� (sorry for the confusion). I do realize we cannot 
neglect the fact IPv4 will be around for a while and thus still needs native 
support as well.<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt" 
lang=EN-US><o:p> </o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt" 
lang=EN-US>Regards,<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt" 
lang=EN-US>Kurt<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt" 
lang=EN-US><o:p> </o:p></SPAN></P>
<DIV>
<DIV 
style="BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0cm; PADDING-LEFT: 0cm; PADDING-RIGHT: 0cm; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<P class=MsoNormal><B><SPAN 
style="FONT-FAMILY: 'Tahoma','sans-serif'; FONT-SIZE: 10pt" 
lang=EN-US>From:</SPAN></B><SPAN 
style="FONT-FAMILY: 'Tahoma','sans-serif'; FONT-SIZE: 10pt" lang=EN-US> Ahmed 
Abu-Abed [mailto:ahmed@tamkien.com] <BR><B>Sent:</B> maandag 28 februari 2011 
13:45<BR><B>To:</B> Kurt Smolderen; 
address-policy-wg@ripe.net<BR><B>Subject:</B> Re: [address-policy-wg] IPv6 
allocations for 6RD<o:p></o:p></SPAN></P></DIV></DIV>
<P class=MsoNormal><SPAN lang=EN-US><o:p> </o:p></SPAN></P>
<DIV>
<P class=MsoNormal><SPAN style="FONT-FAMILY: 'Calibri','sans-serif'">Hi 
Kurt,</SPAN><o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal> <o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal><SPAN style="FONT-FAMILY: 'Calibri','sans-serif'">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.</SPAN><o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal> <o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal><SPAN style="FONT-FAMILY: 'Calibri','sans-serif'">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.</SPAN><o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal> <o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal><SPAN style="FONT-FAMILY: 'Calibri','sans-serif'">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.</SPAN><o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal> <o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal><SPAN style="FONT-FAMILY: 'Calibri','sans-serif'">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.</SPAN><o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal> <o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Calibri','sans-serif'">Regards,</SPAN><o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Calibri','sans-serif'">-Ahmed</SPAN><o:p></o:p></P></DIV>
<DIV>
<P class=MsoNormal> <o:p></o:p></P></DIV>
<DIV>
<DIV>
<P class=MsoNormal><SPAN 
style="FONT-FAMILY: 'Tahoma','sans-serif'; FONT-SIZE: 10pt"><o:p> </o:p></SPAN></P></DIV>
<DIV>
<DIV>
<P style="BACKGROUND: whitesmoke" class=MsoNormal><B><SPAN 
style="FONT-FAMILY: 'Tahoma','sans-serif'; FONT-SIZE: 10pt">From:</SPAN></B><SPAN 
style="FONT-FAMILY: 'Tahoma','sans-serif'; FONT-SIZE: 10pt"> <A 
title=K.Smolderen@edpnet.net href="mailto:K.Smolderen@edpnet.net">Kurt 
Smolderen</A> <o:p></o:p></SPAN></P></DIV>
<DIV>
<P style="BACKGROUND: whitesmoke" class=MsoNormal><B><SPAN 
style="FONT-FAMILY: 'Tahoma','sans-serif'; FONT-SIZE: 10pt">Sent:</SPAN></B><SPAN 
style="FONT-FAMILY: 'Tahoma','sans-serif'; FONT-SIZE: 10pt"> Monday, February 
28, 2011 11:13 AM<o:p></o:p></SPAN></P></DIV>
<DIV>
<P style="BACKGROUND: whitesmoke" class=MsoNormal><B><SPAN 
style="FONT-FAMILY: 'Tahoma','sans-serif'; FONT-SIZE: 10pt">To:</SPAN></B><SPAN 
style="FONT-FAMILY: 'Tahoma','sans-serif'; FONT-SIZE: 10pt"> <A 
title=address-policy-wg@ripe.net 
href="mailto:address-policy-wg@ripe.net">address-policy-wg@ripe.net</A> 
<o:p></o:p></SPAN></P></DIV>
<DIV>
<P style="BACKGROUND: whitesmoke" class=MsoNormal><B><SPAN 
style="FONT-FAMILY: 'Tahoma','sans-serif'; FONT-SIZE: 10pt">Subject:</SPAN></B><SPAN 
style="FONT-FAMILY: 'Tahoma','sans-serif'; FONT-SIZE: 10pt"> RE: 
[address-policy-wg] IPv6 allocations for 
6RD<o:p></o:p></SPAN></P></DIV></DIV></DIV>
<DIV>
<P class=MsoNormal><o:p> </o:p></P></DIV>
<P class=MsoNormal>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<o:p></o:p></P></DIV></BODY></HTML>