IPv6 internet broken, Verizon route prefix length policy

Tue Oct 13 02:51:04 UTC 2009

In a message written on Mon, Oct 12, 2009 at 07:13:04PM -0700, Seth Mattinen wrote:
> Leo Bicknell wrote:
> > Worse, the problem is being made worse at an alarming rate.  MPLS
> > VPN's are quicky replacing frame relay, ATM, and leased line circuits
> > adding MPLS lables and VPN/VRF routes to edge routers.  Various
> > RIR's are pushing "PI for all" in IPv6 based on addressing availbility.
> > Some networks are actually finally using multicast for IPTV services,
> > generating much larger number of entries than the global multicast table
> > would otherwise indicate.
> 
> It's not the RIR's fault. IPv6 wasn't designed with any kind of workable
> site multihoming. The only goal seems to have been to limit /32's to an
> "ISP" but screw you if you aren't one. There was no alternative and it's
> been how long now? PI, multihoming, multicast, etc. is reality because
> the internet is now Very Serious Business for many, many people.

I may have editorialized in a way that was not completely clear.

I agree that due to lack of an alternative "PI IPv6" is necessary
and effectively the only option we have right now.  Were IPv6 policy
to only allow those who could get IPv4 PI to get IPv6 PI I would
say the problem was "the same".

However, the reason I say it is being made worse is that there is
a subset of the RIR community who sees the lack of scarcity of
addres space as a reason to provide IPv6 PI to people who cannot
qualify for IPv4 PI.  My impression of the current RIR policy trends
are resulting in a situation that more folks will be able to get
IPv6 PI than can currently get IPv4 PI.  Hence why I put that in
the list of things making it worse.

> Yes, I know there's hacks like SHIM6 and I don't wish to go OT into a
> debate about them, so I'll just say that if there had been a viable
> alternative to multihoming as we know it I think it would have been
> given a go before policy got pushed to the RIR's to allow IPv6 PI.

The only idea I have seen that holds any promise is LISP.  There
is working code, and the idea is sound.  However, like squeezing a
balloon while it makes some issues better it then puts pressure in
other directions.  It trades off TCAM lookups for LOC/ID lookups
and caching.  It's not clear to me on an Internet scale system this
is better; but I do hope the folks doing that work continue on the
chance that it is...

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20091012/200400ca/attachment.sig>