[arin-ppml] Simplified IPv6 policy

[Scott Leibrand]

On Wed, Dec 23, 2009 at 1:40 PM, William Herrin <bill at herrin.us> wrote:

> On Wed, Dec 23, 2009 at 4:05 PM, Scott Leibrand <scottleibrand at gmail.com>
> wrote:
> > On 12/23/2009 10:52 AM, William Herrin wrote:
> >> There is no IPv6 equivalent to a multihomed IPv4 /24 PA cutout. Not in
> >> this proposal with its classifications that enable strong disaggregate
> >> filtering. Not in existing IPv6 policy that enables less effective
> >> prefix filtering. Not in the IETF's recommendations.
> >>
> >> Further, suggesting that policy can't fix it is a cop-out. Policy did
> >> fix it in IPv4: by authorizing /24 cutouts for multihomed entities
> >> regardless of size based on the knowledge that /24's are generally
> >> routable.
> >>
> >
> > I'm not sure what you think makes /24 PA in IPv4 special, then.  It's not
> > because ARIN policy allows ISPs to give them out: IPv6 PA /48s can be
> given
> > out even more easily.  Is it just because we have a swamp of legacy class
> > C's that can't be filtered?
>
> Hi Scott,
>
> It's because of 4.2.3.6 -combined with- the accurate expectation that
> /24's are individually routable. Only in combination do these two
> elements result in a functional technical solution. Even then it's
> suboptimal; we'd be better off if ARIN gave out the /24. Some things
> in BGP have subtle differences when its a cutout instead of a distinct
> block. But I digress...
>
> There is no expectation that a /48 cutout will be individually
> routable and the policy appears to be evolving further from that sort
> of use. Thus ARIN IPv6 policy needs an element functionally comparable
> to the combination of 4.2.3.6 and IPv4 prefix filtering best
> practices.
>

Got it, thanks.


>
> >> Successful ARIN IPv6 policy will have to create an IPv6 equivalent to
> >> a multihomed IPv4 /24 PA cutout or else leave a well-funded class of
> >> users with a solid technical basis for actively opposing IPv6
> >> deployment.
> >
> > I proposed (and we adopted) policy 2007-21
> > (https://www.arin.net/policy/proposals/2007_21.html) to address the
> issue of
> > the class of users with legacy /24s who couldn't get IPv6 PI space.
>  Maybe
> > once I understand what aspects of IPv4 PA /24s need to be replicated in
> > IPv6, I can better understand where current policy (and current
> proposals)
> > fall short.
>
> I remember having something to do with that. ;) Hopefully my
> explanation above helps.
>

Heh.  I thought you might've been, but couldn't remember.  :-)


>
> > On the other hand, the only thing I can see preventing ISPs from
> accepting
> > PA /48s is the lack of market pressure to do so.
>
> It all comes back to filtering. When I see a disaggregate /48 cut out
> of an ISP's /32, I can't tell whether it's a multihomed customer (that
> I need to carry) or traffic engineering (which will work out OK even
> if I drop it).
>
> The price for strong TE filtering is that multihomed PA cutouts have
> to be replaced with PI. Can't have both. That's just the character of
> the technology.
>
> IMHO, the potential for TE filtering is too valuable to give up and PA
> cutouts never worked very well to begin with. They should be replaced
> with PI.
>

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...

Thanks,
Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20091223/15dba7d1/attachment.htm>