[arin-ppml] v6 AFI over v4 BGP (was Preemptive IPv6 assignment)

[George, Wes E IV [NTK]]

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Michael Richardson
> Sent: Tuesday, October 12, 2010 3:27 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Preemptive IPv6 assignment
>
> I just wish that BGP4 announced both IPv4 and IPv6 prefixes on either
> v4
> or v6 transports.  I think that there isn't anything preventing it in
> the protocol, but all the routers I've seen announce
> v4-over-v4-transport and s/4/6/.
>

[WES] Change of subject line to reflect new topic.
This does work. It just doesn't work particularly *well* because a number of router vendors have implemented next-hop handling strangely, where the route announcement gets dropped by the neighboring router because it's announced with a v4-mapped v6 next-hop or a link-local next-hop, both seen as invalid by the upstream router due to no route to next-hop. We're using a single IPv4 BGP session for both IPv4 and IPv6 unicast AFs for our iBGP sessions, but as it was we had to add route-policies to force the correct next-hop to be set (pending resolution of a couple of bugs), and configuring next-hop-self doesn't always fix. Because we have no way of knowing whether $CPE_vendor supports it correctly in the combination of software and hardware that our customers are running, we default to separate BGP sessions per AF for eBGP.

That said, I don't think it would be as simple as you paint it, because even if you assume that the PTP link addresses sort themselves out automagically, if you're doing BGP, how do you determine what next-hop to announce the routes with? Even if the bugs I detailed above are fixed, they assume that you have a routable next-hop to announce IPv6 routes with. What about BGP filters and max prefix limits that your upstream normally applies to your session? Ultimately, just like with IPv4, a customer is going to have to talk to their provider to get IPv6/BGP set up, there's really no way to completely avoid coordination and have it "just work."

I'm not convinced that this would fundamentally change the speed of deployment anyway. Setting up BGP with your upstream to support IPv6 is easy in comparison to actually having an upstream that supports it and getting all of the devices in your enterprise to be able to do something with that prefix you got.

Wes George

________________________________

This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.