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.

Thanks,
Wes George

-----Original Message-----
From: Thomas Magill [mailto:tmag...@providecommerce.com]
Sent: Monday, May 24, 2010 2:22 PM
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?



Thomas Magill
Network Engineer

Office: (858) 909-3777

Cell: (858) 869-9685
mailto:tmag...@providecommerce.com <mailto:tmag...@providecommerce.com>


provide-commerce
4840 Eastgate Mall

San Diego, CA  92121



ProFlowers <http://www.proflowers.com/>  | redENVELOPE
<http://www.redenvelope.com/>  | Cherry Moon Farms
<http://www.cherrymoonfarms.com/>  | Shari's Berries
<http://www.berries.com/>





This e-mail may contain Sprint Nextel Company 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.


Reply via email to