BGP4+ for IPv6

[Francis Dupont]

 In your previous mail you wrote:

   	there are couple of questions on RFC2545.  not sure if this is the
   	right forum to talk about this, but anyway, i'll try.
   
=> obviously this is not the right forum but the 6bone community is
where most BGP4+ for IPv6 experience is...

   	there are three addresses in BGP4+ configuration - you may want to
   	clarify more.
   	- TCP endpoint address
   		RFC2545 says: this can be IPv4 or IPv6 (section 4, 1st
   		paragraph).
   		Q: is it okay if we use link-locals? (it can be good for EBGP
   		   peering, we need no global address on IX, we are free from
   		   renumber on IX segment)
   		Q: site-local?

=> I'd like to answer any address that works then a link-local for eBGP
seems reasonable.

   	- first address in next hop field
   		RFC2545 says: global IPv6 address (mandatory)

=> this must be a not-link-local address because of BGP constraints.

   	- second address in next hop field

=> you should understand why the first address is not enough in some
situations: BGP deals with global addresses and some implementations
use *only* link-local addresses for gateways. Both are right but
something is needed in order to make them to work together.

   		RFC2545 says: linklocal IPv6 address (optional), only if
   		two routers are adjacent (on-link)

=> the RFC2545 is more accurate.

   		Q: onlink determination rule? (some reference should be enough)

=> the RFC2545 suggests "share a common subnet prefix", this works
if there are no multi-link prefix (as it is the case today).

   		Q: is it really necessary?
   
=> yes, without a link-local address you can't deal with some common cases:
 - eBGP with more than one peer on a shared link (IX Ethernet, ...)
 - IGP interaction when two iBGP peers are "too close".

   	we need some more rules documented, to help implementers, regarding
   	to IGP interaction, like:
   	- if the first address in next hop field is a global address, and
   	  second address is not avaliable,

=> this should not happen, ie. if a link-local address is needed then
it must be available.

          how should we pick the next hop
   	  field for IPv6 routing table (should/must be a link-local due to
   	  ICMPv6 issues)
   
=> can I answer to the question by another question. RFC 2545 specifies
(the statement is hairy but very accurate):
   The link-local address shall be included in the Next Hop field if and
   only if the BGP speaker shares a common subnet with the entity
   identified by the global IPv6 address carried in the Network Address
   of Next Hop field and the peer the route is being advertised to.
Do you know a case of this is wrong?

   	also, from operational perspective, we may want to use addresses
   	that are not eui64-based (to cope with ethernet card replacement).
   	not sure if this needs to be documented or not.
   
=> I agree (both it is a good idea in some cases and this doesn't need
to be documented).

   	i bet jinmei and some other folks have more comment...
   
=> I'd like to know if something important needs to be changed in RFC2545.
It has been used for years and as far as I know nobody has found a problem
with it even if the context has changed (today we have a real IGP, OSPFng,
and we can use capabilities in order to send IPv6 NLRIs to an IPv4 BGP
speaker without crashing it, ie. we can negociate before :-).

Thanks

Francis.Dupont@enst-bretagne.fr

PS: I believe you have an implementation (bgpd) I should add in my list.
Have you any idea about its usage? In France we use Ciscos and a little
number of GateD (less and less because we are moving to native IPv6 over
ATM with dedicated PVC and routers).
PPS: the hairy & accurate statement is far easier to implement than
to understand (:-)!