ipv6 next-hop link-local
gert at space.net
Sat Feb 19 10:41:22 CET 2011
On Fri, Feb 18, 2011 at 11:08:13PM +0100, Francis Dupont wrote:
> I think both the RFC and the Cisco implementation are stupid, because
> => can I kindly ask you to read the RFC before saying it is stupid?
Well, re-reading the RFC 3 times, and trying to fully understand it, I
need to modify this statement - this RFC is actually trying to clean up
the problems caused by architectural designs (so apologies to the
It doesn't help, though, as it still says (section 3):
"A BGP speaker shall advertise to its peer in the Network Address of
Next Hop field the global IPv6 address of the next hop, potentially
followed by the link-local IPv6 address of the next hop.
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."
well, there you go, and this is exactly what happened in the scenario
we've seen - link-local nexthop advertised, Cisco peers using the LL
next-hop, Juniper peers using the global next-hop. Global next-hop was
working (obviously!, as otherwise the BGP session would not have been
established), link-local ND was broken - Juniper peers worked, Cisco
peers had black-holing.
(Unfortunately, I can't seem to find the text reference anymore that
says that receivers are basically free to decide which nexthop type to
use - RFC4760 seems to tell me that a conforming implementation must
only ever send a single next-hop in MP_REACH_NLRI, so maybe that was in
one of the previous versions of [BGP-4])
After reading the RFC two more times, I seem to understand where the
initial idea comes from - networks that share eBGP routers and "other
stuff", and where you want to send ICMP redirects and/or RIPng updates
with a next-hop pointing to "other routers".
Our operational problems come from networks that only have eBGP
speakers - namely, exchange point meshes - and link-local next-hops
have no reason for existance there. No RIPng, no ICMP redirects.
So what I would have wished for is some strong words in this RFC
that discourage use of received link-local next-hop, unless other
protocols are in use that require them. Or something that would
encourage router vendors to add a switch to their implementation
to give the network admin the choice...
(Basically, this is what I hoped to find in the Cisco BGP implementation
- a switch like "neighbour 2001:db8::1 always-use-global-nexhop", but that
one doesn't exist)
did you enable IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 306 bytes
Desc: not available
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20110219/1f83b605/attachment.bin
More information about the ipv6-ops