<div class="gmail_quote">On Wed, Dec 23, 2009 at 1:40 PM, William Herrin <span dir="ltr"><<a href="mailto:bill@herrin.us">bill@herrin.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Wed, Dec 23, 2009 at 4:05 PM, Scott Leibrand <<a href="mailto:scottleibrand@gmail.com">scottleibrand@gmail.com</a>> wrote:<br>
> On 12/23/2009 10:52 AM, William Herrin wrote:<br>
</div><div class="im">>> There is no IPv6 equivalent to a multihomed IPv4 /24 PA cutout. Not in<br>
>> this proposal with its classifications that enable strong disaggregate<br>
>> filtering. Not in existing IPv6 policy that enables less effective<br>
>> prefix filtering. Not in the IETF's recommendations.<br>
>><br>>> Further, suggesting that policy can't fix it is a cop-out. Policy did<br>
>> fix it in IPv4: by authorizing /24 cutouts for multihomed entities<br>
>> regardless of size based on the knowledge that /24's are generally<br>
>> routable.<br>
>><br>
><br>
> I'm not sure what you think makes /24 PA in IPv4 special, then.  It's not<br>
> because ARIN policy allows ISPs to give them out: IPv6 PA /48s can be given<br>
> out even more easily.  Is it just because we have a swamp of legacy class<br>
> C's that can't be filtered?<br>
<br>
</div>Hi Scott,<br>
<br>
It's because of 4.2.3.6 -combined with- the accurate expectation that<br>
/24's are individually routable. Only in combination do these two<br>
elements result in a functional technical solution. Even then it's<br>
suboptimal; we'd be better off if ARIN gave out the /24. Some things<br>
in BGP have subtle differences when its a cutout instead of a distinct<br>
block. But I digress...<br>
<br>
There is no expectation that a /48 cutout will be individually<br>
routable and the policy appears to be evolving further from that sort<br>
of use. Thus ARIN IPv6 policy needs an element functionally comparable<br>
to the combination of 4.2.3.6 and IPv4 prefix filtering best<br>
practices.<br></blockquote><div><br>Got it, thanks.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
>> Successful ARIN IPv6 policy will have to create an IPv6 equivalent to<br>
>> a multihomed IPv4 /24 PA cutout or else leave a well-funded class of<br>
>> users with a solid technical basis for actively opposing IPv6<br>
>> deployment.<br>
><br>
> I proposed (and we adopted) policy 2007-21<br>
> (<a href="https://www.arin.net/policy/proposals/2007_21.html" target="_blank">https://www.arin.net/policy/proposals/2007_21.html</a>) to address the issue of<br>
> the class of users with legacy /24s who couldn't get IPv6 PI space.  Maybe<br>
> once I understand what aspects of IPv4 PA /24s need to be replicated in<br>
> IPv6, I can better understand where current policy (and current proposals)<br>
> fall short.<br>
<br>
</div>I remember having something to do with that. ;) Hopefully my<br>
explanation above helps.<br></blockquote><div><br>Heh.  I thought you might've been, but couldn't remember.  :-)<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="im"><br>
> On the other hand, the only thing I can see preventing ISPs from accepting<br>
> PA /48s is the lack of market pressure to do so.<br>
<br>
</div>It all comes back to filtering. When I see a disaggregate /48 cut out<br>
of an ISP's /32, I can't tell whether it's a multihomed customer (that<br>
I need to carry) or traffic engineering (which will work out OK even<br>
if I drop it).<br>
<br>
The price for strong TE filtering is that multihomed PA cutouts have<br>
to be replaced with PI. Can't have both. That's just the character of<br>
the technology.<br>
<br>
IMHO, the potential for TE filtering is too valuable to give up and PA<br>
cutouts never worked very well to begin with. They should be replaced<br>
with PI.<br></blockquote><div><br>Ok, that's a good way to look at it.  In exchange for reasonably-assured TE filterability, we give out PI space to anyone who has a need to multihome, and they can be reasonably assured that those prefixes will mostly be accepted.  A grand bargain: I hope it would work.  Let me go see what I can do to make my proposal accomplish the policy portion of that...<br>
 <br></div>Thanks,<br>Scott<br></div>