[arin-ppml] Simplified IPv6 policy

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

> On Wed, Dec 23, 2009 at 4:05 PM, Scott Leibrand <scottleibrand at>
> 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 -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 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
> > ( 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...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>