[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
BGP4+ for IPv6
- Subject: BGP4+ for IPv6
- From: [email protected] (Francis Dupont)
- Date: Mon, 11 Dec 2000 23:54:13 +0100
- In-reply-to: Your message of Tue, 12 Dec 2000 06:37:00 +0900. <[email protected]>
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
- TCP endpoint address
RFC2545 says: this can be IPv4 or IPv6 (section 4, 1st
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)
=> I'd like to answer any address that works then a link-local for eBGP
- 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
=> 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 :-).
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 (:-)!