<!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 Géza,</FONT></DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri>Given IPv4's imminent depletion at the RIR level, 
dual-stacking without tunneling or translation will be a short term solution 
too. Pure dual-stacking, up to the consumer's premise, assumes you are laying 
out dual-stack (with both IPv4 and IPv6 enabled) nodes from core up to 
the CPE, and the customer is getting both IPv6 and IPv4 public addresses, and 
the latter is very scarce. </FONT></DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri>So for v4 and v6 to coexist for the next 10 years or so 
we need tunneling, or some form of IPv6-only at the customers terminal with 
translation to IPv4 if needed.</FONT></DIV>
<DIV><FONT face=Calibri></FONT> </DIV>
<DIV><FONT face=Calibri>Hence my /32 endorsement for all IPv6 access 
methods.</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><BR></DIV>
<DIV style="BACKGROUND: #f5f5f5">
<DIV style="font-color: black"><B>From:</B> <A 
title="mailto:turchanyi.geza@gmail.com CTRL + Click to follow link" 
href="mailto:turchanyi.geza@gmail.com">Turchanyi Geza</A> </DIV>
<DIV><B>Sent:</B> Thursday, February 24, 2011 4:25 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>Cc:</B> <A title=mattias.gyllenvarg@bredband2.se 
href="mailto:mattias.gyllenvarg@bredband2.se">Wyatt Mattias Gyllenvarg</A> 
</DIV>
<DIV><B>Subject:</B> Re: [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 
6RD</DIV></DIV></DIV>
<DIV><BR></DIV>Hello Ahmed,<BR><BR>Many thanks for forwarding the comparison 
table.<BR><BR>Temporary solutions are usefull in the transition phase. However, 
I would prefere emphasize even in the address allocation mechanism if a solution 
is temporary and should go away in long term. Therefore I fully agree with 
János, the smallest address space the best in case of 6RD and other 
non-real-dual-stack method.<BR><BR>Géza<BR><BR>
<DIV class=gmail_quote>On Thu, Feb 24, 2011 at 2:48 PM, Ahmed Abu-Abed <SPAN 
dir=ltr><<A href="mailto:ahmed@tamkien.com">ahmed@tamkien.com</A>></SPAN> 
wrote:<BR>
<BLOCKQUOTE 
style="BORDER-LEFT: rgb(204,204,204) 1px solid; MARGIN: 0pt 0pt 0pt 0.8ex; PADDING-LEFT: 1ex" 
class=gmail_quote>
  <DIV style="PADDING-LEFT: 10px; PADDING-RIGHT: 10px; PADDING-TOP: 15px" 
  name="Compose message area">
  <DIV><FONT face=Calibri>Hello,</FONT></DIV>
  <DIV><FONT face=Calibri></FONT> </DIV>
  <DIV><FONT face=Calibri>I am new to the Address Policy WG and this seems like 
  quite an old discussion. I endorse assigning a /32 to LIRs regardless of 
  the IPv6 access method they use.</FONT></DIV>
  <DIV><FONT face=Calibri></FONT> </DIV>
  <DIV><FONT face=Calibri>Other than to 6RD, TSP is another protocol (RFC 
  5572) that can be used to enable IPv6 to end users rapidly over intermediate 
  IPv4 nodes. A useful comparison between TSP, 6RD and other IPv6 access 
  tunneling protocols is shown in </FONT><FONT face=Calibri><A 
  title="http://gogoware.gogo6.com/4105/file.asp?file_id=942 CTRL + Click to follow link" 
  href="http://gogoware.gogo6.com/4105/file.asp?file_id=942" 
  target=_blank>http://gogoware.gogo6.com/4105/file.asp?file_id=942</A></FONT></DIV>
  <DIV><FONT face=Calibri></FONT> </DIV>
  <DIV><FONT face=Calibri>As for IPv6 CPE and server 
  gateways availability, there are commercial solutions in the market that 
  implement 6RD and TSP for both sides of the tunnel.</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><BR></DIV>
  <DIV style="BACKGROUND: rgb(245,245,245)">
  <DIV><B>From:</B> <A 
  title="mailto:mattias.gyllenvarg@bredband2.se CTRL + Click to follow link" 
  href="mailto:mattias.gyllenvarg@bredband2.se" target=_blank>Wyatt Mattias 
  Gyllenvarg</A> </DIV>
  <DIV><B>Sent:</B> Wednesday, February 23, 2011 5:24 PM</DIV>
  <DIV><B>To:</B> <A title=address-policy-wg@ripe.net 
  href="mailto:address-policy-wg@ripe.net" 
  target=_blank>address-policy-wg@ripe.net</A> </DIV>
  <DIV><B>Subject:</B> RE: [ipv6-wg] RE: [address-policy-wg] IPv6 allocations 
  for 6RD</DIV></DIV></DIV>
  <DIV>
  <DIV></DIV>
  <DIV class=h5>
  <DIV><BR></DIV>Hi<BR><BR>We would like to weigh in here.<BR>We feel that it 
  should be RIPEs policy to allocate ONE /32 to any LIR <BR>who requests it for 
  6rd.<BR><BR>6rd is the only way for us to reach all our residential customers. 
  <BR>Especially those in Municipal Networks that are very slow to invest in 
  <BR>their networks and often do not have the competence and time to 
  <BR>impelment IPv6.<BR><BR>Also, Cisco has not yet implemented even a small 
  part of the protective <BR>mechanisms we rely on in IPv4 to secure our 
  residential networks. Many <BR>of these features are required to meet the 
  demands contracted with the <BR>customers. We cannot use native IPv6 until 
  Cisco implements these <BR>features and we have tested and rolled them out on 
  hundreds of switches.<BR><BR>6rd bypasses all these issues. IF we can get a 
  /32 for that purpuse.<BR><BR>-- <BR><BR>Med Vänliga Hälsningar - Best 
  regards<BR>Mattias Gyllenvarg<BR>Network Operations 
  Center<BR>Bredband2<BR><BR>---------------------- end of line 
  ---------------------------<BR></DIV></DIV></DIV></BLOCKQUOTE></DIV><BR></BODY></HTML>