Subject: Re: [RPSEC] issue: coverage IPv6

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 2 Apr 2006 23:07:04 +0200

My apologies for replying to a year old message, but if my searches  
aren't misleading me this issue hasn't been further discussed  
subsequently, so here goes...

On 11-mrt-2005, at 16:45, Francis Dupont wrote:

> => there were some proposals for link-local addresses only in  
> special cases
> but IMHO in the context of RPSEC global addresses are required... So
> this IPv6 feature (narrow scope addresses) can be ignored and general
> considerations for IPv4 apply to IPv6 directly.

My understanding of the presence of link local next hop addresses in  
multiprotocol BGP for IPv6 is that all IPv6 routing protocols are  
required to exchange link local addresses so that proper redirects  
can be generated. Redirects for off-link destinations are required to  
be towards link local addresses as per the IPv6 specs. This probably  
means that link local next hop addresses in IPv6 multiprotocol BGP  
can't be ignored for RPSEC purposes. However, since this is a  
attribute that doesn't propagate across ASes or even routers, this  
shouldn't be too problematic.

I've dabled a bit with modifying these addresses in route maps under  
IOS and Zebra with various results, but I can't really say to what  
extent different implementations actually use them in one way or  
another.

Other than the link local next hop address issue and the fact that  
all the IPv6 stuff is wrapped inside multiprotocol extensions, there  
aren't any differences between IPv4 and IPv6 routing for unicast in  
BGP as far as I know. However, things get interesting when IPv6  
routes are exchanged over IPv4 transport or the other way around  
because the next hop address for the non-transport address family may  
not point to anything valid. In my new book, I recommend that people  
use separate IPv4 and IPv6 eBGP sessions to carry the respective  
routes, and I think pretty much everyone does this (although  
sometimes routes of an unexpected address family propagate  
unintentionally) but not for iBGP, my view is that it makes more  
sense to carry both address families over one session here. (No next  
hop address issues in this case and it saves on additional loopback  
addresses and redistrution of same in the additional (IPv6) IGP.) I  
don't know how people generally handle this, though, as the  
difference isn't visible from the outside.

Just 352 messages to go.  :-)

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec