Best practices IPv4/IPv6 BGP (dual stack)

Fri May 2 20:35:00 UTC 2014

Subject: Best practices IPv4/IPv6 BGP (dual stack) Date: Fri, May 02, 2014 at 07:44:33PM +0000 Quoting Deepak Jain (deepak at ai.net):
> 
> Between peering routers on a dual-stacked network, is it considered best practices to have two BGP sessions (one for v4 and one for v6) between them? Or is it better to put v4 in the v6 session or v6 in the v4 session?

Like others, yes, two sessions, v6 over v6 and v4 over v4. only the native AF is active. 

> According to docs, obviously all of these are supported and if both sides are dual stacked, even the next-hops don't need to be overwritten.

It works, but might produce interesting side effects. I've had to resort
to it when peering between different IOS versions; but that might have
been the result of fat-fingering as well.

> Is there any community-approach to best practices here? Any FIB weirdness (e.g. IPv4 routes suddenly start sucking up IPv6 TCAM space, etc)  that results with one solution over the other?

If having MPLS bgp peers over v6 carrying vpnv4 routes all sorts of
strange things can happen. There is no standard for it; so one should
not expect it to work. But the failure modes are "interesting"; I've had
the next-hop for a v6-carried vpnv4 peering be the first 32 bits of the
v6 next-hop, interpreted as a v4 address.. It only works if there is a
v4 route to that made-up address.

This is a field where v4 next-hops are essential to make things
work. <rant>In that context, allocating 100.64.0.0/10 to CGN was
especially un-clever... </rant>

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Xerox your lunch and file it under "sex offenders"!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140502/80c1323c/attachment.sig>