ipv6 next-hop link-local

[Gert Doering]

Hi,

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 
authors).  

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)

Gert Doering
        -- NetMaster
-- 
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
Type: application/pgp-signature
Size: 306 bytes
Desc: not available
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20110219/1f83b605/attachment.sig>