Best practices IPv4/IPv6 BGP (dual stack)

Chris Grundemann cgrundemann at
Fri May 2 22:07:05 UTC 2014

On Fri, May 2, 2014 at 1:47 PM, Jared Mauch <jared at> wrote:
> On May 2, 2014, at 3:44 PM, Deepak Jain <deepak at> wrote:
> >
> > 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?
> We use v4 transport for v4 routes and v6 transport for v6 routes only.


> This way if one plane is unstable the other is unaffected.

This is the key point I believe: No protocol fate sharing!

>From the draft BCOP on this topic[1]:
Establish new, IPv6-Only peering sessions parallel to existing IPv4
peering. Individual IPv4 and IPv6 BGP peering sessions should be
established between all BGP neighbors, particularly eBGP peers. While
it is possible to use Multiprotocol BGP (MP-BGP)[2] to carry IPv6
Network Layer Reachability Information (NLRI) over existing (or new)
IPv4 BGP peering sessions, this is not recommended. Both BGP sessions
MAY use the same logical circuit, or, a new port MAY be used for IPv6
(separate physical or logical connections is NOT a requirement).
   [removed image]
This maintains independent IPv6 and IPv4 topologies, rather than tying
the two together unnecessarily. It prevents black holing of IPv6
traffic in the event of a protocol outage because the IPv6 session
goes down when IPv6 reachability is lost. When an IPv4 BGP session
carries IPv6 NLRI, IPv6 routes are only withdrawn if IPv4 connectivity
is lost. Independent BGP sessions also facilitate protocol specific
maintenance because the IPv4 and IPv6 sessions don’t affect each other
(e.g. IPv6 can be “bounced” without effecting IPv4 and vice verse).
Finally, establishing new, IPv6-only peering creates better
operational clarity. It allows IPv4 and IPv6 configuration stanzas to
be independent and easily recognizable.


[1] -
[2] - Bates, T., Chandra, R., Katz, D., and Y. Rekhter, “Multiprotocol
Extensions for BGP-4”, RFC 4760, January 2007

> - Jared


More information about the NANOG mailing list