<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" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@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:0in;
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.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{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:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple style='word-wrap: break-word;
-webkit-nbsp-mode: space;-webkit-line-break: after-white-space'>
<div class=WordSection1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>This entire thread is basically hot air swirling after more hot
air...... While more traffic is good, this noise is a waste of everyone’s
time.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>1)
The 6rd policy needs to be really simple and easy to get NOW.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>2)
Assuring it goes away at some point requires appropriate feedback to drive
people away from it as soon as they can move.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Satisfying both of those should be easy. Establish a policy that
says anyone with IPv4 can get an IPv6 prefix between /16 & /24 as they see
fit, then set a proportional fee schedule with a *substantial* escalation
factor over time. <o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>You don’t need sunset clauses in the policy, and you
don’t need to complicate things by obsessing about ‘waste’.
What you do need is a policy that enables deployment TODAY. For those that need
6rd because they didn’t get their act together to enable a dual-stack
infrastructure, there is a cost to that delay, and the cost continues to grow
until they get past their legacy equipment. <o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The hardest part of that approach is that the fee for a provider
that is offering dual-stack /48 to each customer should be substantially less
than a 6rd deployment offering /60. It is not ARIN’s role to define
end product offerings, so differentiating the fee schedule for 2 ISPs
requesting a /28 based on how they plan to use it is probably out of the
question. That said, financial backpressure will be much more effective than
any proscriptive language that makes it past ppml. We just need to make sure
that there are no unintended consequences related to consumer network
innovation due to big players opting for blocks that are too small.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Tony<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> arin-ppml-bounces@arin.net
[mailto:arin-ppml-bounces@arin.net] <b>On Behalf Of </b>Owen DeLong<br>
<b>Sent:</b> Thursday, October 14, 2010 2:49 PM<br>
<b>To:</b> Mark Townsley<br>
<b>Cc:</b> arin-ppml@arin.net<br>
<b>Subject:</b> Re: [arin-ppml] Opposed to 2010-9 and 2010-12<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<div>
<p class=MsoNormal>On Oct 14, 2010, at 2:36 PM, Mark Townsley wrote:<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p>
<div>
<p class=MsoNormal>On 10/14/10 11:06 PM, Owen DeLong wrote: <o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<div>
<p class=MsoNormal>On Oct 14, 2010, at 1:51 PM, Lorenzo Colitti wrote:<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p>
<div>
<p class=MsoNormal>On Thu, Oct 14, 2010 at 8:02 AM, Owen DeLong <<a
href="mailto:owen@delong.com">owen@delong.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p class=MsoNormal>If you can get 6rd to fit in single /16, then, perhaps
we could consider allowing it to be permanent.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>However, if ~3,000 ARIN members deploy 6rd /24s, then,
you're talking about the vast majority of an entire /12 just in the ARIN
region.<o:p></o:p></p>
</div>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>Why not we make it a /28, and thus give the customer a /60?
The customer still gets 16 subnets for his house, and when 6rd goes away
(since, as you point out there are other disadvantages beyond address space use
compared to native IPv6), then the subnet will be /56 (since, following your
reasoning, that is what competitors with native IPv6 access will be providing).<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</div>
<p class=MsoNormal>/60s are horrible... They completely stifle any ability for
the customer to do PD-based topology<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>within the site.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-bottom:12.0pt'>I think you are assuming what
the PD-based topology mechanisms are going to be. They haven't really been
designed, and certainly haven't been coded and shipped yet. All we are doing at
this point is providing a playing field. Within that field:<br>
<br>
/60 is an *enormous* improvement over /64. Night and day.<br>
<br>
/56 is certainly better than /60, but not night and day as with /64 and /60. <br>
<br>
The point here is that if we design home routing and PD for 2^4 subnets, it's
not hard to take that and extend it for 2^8 or 2^16. Not so if you are starting
with 2^1.<o:p></o:p></p>
</div>
<p class=MsoNormal>With all due respect, I must strongly disagree here.
Whatever we decide here will likely impact and set the standards by which home
gateways are designed going forward.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>We agree that /64 is a non-starter.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>I strongly believe that the target should be /48. That 6rd
has such terrible deficiencies in its use of address space that we cannot
afford /48 and therefore must compromise to /56.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>Further compromising to /60 runs the risk of that becoming a
de facto industry standard which will potentially be very difficult to
overcome.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>You asked me to tell you if you are contradicting someone
from your organization... You are contradicting Tony<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>Hain here, or, at least my understanding of what Tony has
been saying.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'>Consumer products will be designed
to operate within the lowest common denominator of the above. If we can make
that /60 vs. /64, that's a big win and we might see some potential for upsell
into /56 for "bigger home networks". But, if we have to do a ton of
work to make networks work within a single /64 anyway, once we have done that,
it's hard to argue for supporting multiple subnets as well. I'm trying to avoid
having to do the work at all for /64, but that can only happen if I know the
minimum number of subnets in the home is greater than 1. <o:p></o:p></p>
</div>
<p class=MsoNormal>That is, indeed, the source of my concern. If consumer
products are developed only to the lowest common denominator,<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>we risk establishing /60 as that point. /56 is bad enough.
As I have said, we should strongly encourage /48 as the<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>standard around which development occurs while recognizing
/56 as a necessary limitation of 6rd.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>I don't think we are disagreeing here, and I don't think
anyone is advocating /64s. The AC has approved and forwarded<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>to last call policy which enables /56s for 6rd, but,
encourages treating those as temporary and transitional in nature.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>I think this is the best compromise.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>Owen<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'>- Mark<br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p>
<div>
<div>
<p class=MsoNormal>I would point out that the only ISP I am aware of that is
conducting residential trials of IPv6 seems to be talking about giving only a
/64 to the home by default due to CPE issues. To me, that is a much greater
problem than having a /60 instead of a /56, because with a /64 you can't do any
subnetting at all.<o:p></o:p></p>
</div>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<p class=MsoNormal>True... /64 should be even more discouraged than /60, but,
the reality is that we should look at<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>/56 as a temporary expedient due to inefficiencies in 6rd
and consider /48 the norm.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>Owen<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</div>
</body>
</html>