ipv6 next-hop link-local

[Gert Doering]

Hi,

On Sun, Feb 20, 2011 at 09:42:50PM +1030, Mark Smith wrote:
> > What I'm lobbying for is what Juniper already does: on an eBGP session
> > that's established between global addresses, do not install the link-local
> > next-hop in the FIB, but use the global next-hop.
> 
> I think I'd prefer to see the exact value of the NEXT_HOP attribute the
> peer supplied used in the RIB, be it a link local or a global address
> (leaving that as the peer's decision), with the underlying FIB
> mechanisms (e.g. CEF) then being used to resolve that down to a FIB
> entry specifying an outbound interface and possibly a link layer
> destination. 

Well, the problem is that there's *two* next hop values in the BGP
update, and the receiving peer gets to choose one.  Juniper uses the 
global address, Cisco uses the link-local - and the latter behaviour is not 
providing any benefits (that I could see), but is creating a new failure 
mode (which I consider non-useful).

Here's an example from a production IXP:

Cisco#sh bgp ipv6 2001:470::/32
BGP routing table entry for 2001:470::/32, version 11816664
Paths: (9 available, best #9, table Default)
...
  6939
    2001:7F8::1B1B:0:1 (FE80::20C:DBFF:FEFC:7F92) from 2001:7F8::1B1B:0:1 (216.218.252.174)
      Origin IGP, metric 1, localpref 100, valid, external, best
      Community: 5539:100
  6939, (received-only)
    2001:7F8::1B1B:0:1 (FE80::20C:DBFF:FEFC:7F92) from 2001:7F8::1B1B:0:1 (216.218.252.174)
      Origin IGP, metric 1, localpref 100, valid, external
...

  (before and after inbound route-map application, "soft in" enabled)

Cisco#sh ipv route 2001:470::1
Routing entry for 2001:470::/32
  Known via "bgp 5539", distance 20, metric 1, type external
  Route count is 1/1, share count 0
  Routing paths:
    FE80::20C:DBFF:FEFC:7F92, GigabitEthernet1/1
      MPLS label: none
      Last updated 7w0d ago

Cisco-F-III#sh ipv6 cef 2001:470::1
2001:470::/32
  nexthop FE80::20C:DBFF:FEFC:7F92 GigabitEthernet1/1



> The NEXT_HOP value doesn't have to be the same as either
> the link local or global address of the BGP peer announcing it - it can
> be used to announce routes on behalf of another router. I'm sure you're
> probably aware that is how route-servers in multilateral IXes avoid
> being in the traffic forwarding path between peers.

I am aware of that, and I can read the output of "show bgp" commands :-)

The route-server on this IXP is announcing 3rd-party next-hops, but will
not be "best path" for us if a direct eBGP session exists to a given 
peer AS.  It's showing the same effects, though.


[..]
> I'm actually thinking that using link locals as your eBGP end-points is
> where the benefits are. It minimises the attack surface for attacks
> like these -
> 
> http://tools.ietf.org/search/rfc4953#section-2.2

And it brings lots of new operational issues, like in "oh, I've seen 
a SNMP trap that fe80::aa:bb just went down".  Now - which exchange
point was that on?  Which router, which city, which interface?  Of course
this could all be solved by enhancing software and processes - but with
the same amount of effort, you could just roll out GTSM and MD5 everywhere,
and still have proper mapping of "ah, this address is on IXP <foo> and
belongs to peer <bar>".  Like, with DNS, and such.

But this is a completely different issue - if people want to do so, I wish 
them fun.  We looked at this option some 10 years ago and decided that this 
is not something we find particularily useful, so we're not doing it.

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/20110220/cb2072f3/attachment.sig>