From: Thomas Magill [mailto:tmagill@providecommerce.com]
Sent: Monday, May 24, 2010 11:22 AM
To: nanog@nanog.org
Subject: Quick IP6/BGP question
>From the provider side, are most of you who are implementing IP6
peerings running BGP over IP4 and just using IP6 address families to
exchange routes or doing IP6 peering?
At Hurricane, most of our IPv6 peerings are exchanging over IPv6 addresses.
In general, most routers work better if you run IPv4 peering on IPv4 and IPv6
peering on IPv6. In many cases, this is because the configuration files are less
confusing more than any underlying dependency in the router OS.
YMMV, but, my recommendation is to peer v6 on v6 and v4 o v4.
I've never liked how you have to configure ::w.x.y.z/96 style
IPv4-compatible IPv6 addresses in order to use IPv6 NLRIs with IPv4
BGP sessions, so I've always used separate native IPv6 sessions.
Thanks (to you and everyone else that answered before). It sounds like
everyone is in agreement. I mostly ask because a customer of mine is
considering venturing into the ISP business and expressed interest in
offering IP6. If that is the case, I want to do it correctly from the
start.
We've done it both ways.
We've found that there are sometimes issues with announcing IPv6 NLRI over IPv4 BGP sessions depending on your chosen vendor and code version on both sides of the session. Specifically, we have seen some implementations where an IPv4-mapped IPv6 address (usually the IPv4 router-id or neighbor address) is announced as the next-hop, or a link-local address is used as the next-hop, or some random junk is announced as the next-hop, even with next-hop-self configured. All of these result in the receiving router dropping the announcements because it doesn't have a route to the next-hop. It's usually possible to work around this by using route policies to force the correct next-hop to be written on in/outbound announcements, and as we find it working improperly, we've been reporting bugs, but I thought it would be worth bringing this up as a caveat so that you can make sure your hardware/software of choice is behaving properly if you choose to go this route.
Also, I know of at least one vendor that didn't implement the converse functionality in CLI yet - it's impossible to configure an IPv6 neighbor address in the IPv4 address family in order to exchange IPv4 NLRI over an IPv6 BGP session.
Different sessions, one for v4, one for v6. This keeps config saner, therefore debugging easier. It means you can split out your v4 and v6 edge in the future should you want to, without having to renumber and split out the sessions then.
Most Internet Exchanges do not allow to mix on the same transport. So
IPv4 peering over IPv4 transport, IPv6 peering over IPv6 transport, you
can use the same interface though.
The separation also helps troubleshooting. So we always try to keep
peering and transport the same.
Most Internet Exchanges don't care what BGP protocol options consenting neighbours decide to use, in my experience. (If they cared, what could they do?)