ipv6 next-hop link-local

[Mark Smith]

Hi,

On Sun, 20 Feb 2011 10:36:13 +0100
Gert Doering <gert at space.net> wrote:

> Hi,
> 
> On Sun, Feb 20, 2011 at 10:35:50AM +1030, Mark Smith wrote:
> > > There's a fair bit of operational experience on the routing side of things
> > > (the IXPs we're connected to have offered IPv6 roughly since 2001).
> > 
> > I just wonder if those sorts of deployments have followed "IPv4
> > thinking". I think "IPv4 thinking" is "this is how we can do it and do
> > do it in IPv4, so we'll do it the same way in IPv6, because IPv6 is
> > similar enough to IPv4."
> 
> Well, partly it's "IPv4 thinking", of course.  OTOH, in certain areas,
> "IPv4 thinking" has gained 15+ years of experience in doing things since
> IPv6 was designed, and just because it's IPv4, it doesn't have to be
> "wrong".
> 

I never said it was "wrong". What "IPv4 thinking" does is
constraining peoples' view point, such that they potentially miss out
on benefits and opportunities that are only possible with IPv6. I'd
like them to realise that there are possibly more options available to
solve a problem than just the set that they're familiar with from
their IPv4 experience and history.

> Specifically the topic at hand, using link-locals at an IXP, has some
> benefits - and at the same time, serious operational drawbacks, like 
> "monitoring your eBGP peers in your NMS by IPv6 address" - now which 
> of the two IXPs I'm connected to is the fe80::ab:cd neighbour that just 
> went down?
> 

How about the one with the failed eBGP session, detected via SNMP BGP
MIB session state change or BGP session state change syslogs? I'm
presuming you'd already be monitoring BGP session state in this sort of
scenario.

> I've seen so much operational problems due to, well, inexperienced 
> router operators (or just "fat fingers") that anything that requires
> extra thinking or has the potential for extra breakage is something
> I see with certain doubts.
> 

I don't really accept that because a task can't be achieved
perfectly by 100% of people it is an unreasonable and unacceptable
task. People need to put effort into understanding IPv6 properly,
otherwise they'll make naive mistakes, with costs such as easily
avoidable service outages.

> [..]
> > I get concerned about people lobbying for removal of IPv6 features when
> > they seem to be doing it from an "IPv4 thinking" perspective. 
> 
> I'm actually not lobbying to take away the configuration option of
> consciously using link-local addresses - give people enough rope, etc. -
> (and I earn my living by fixing other people's networks).
> 
> 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.
> 
> Specifically, always use the scope of the eBGP endpoint address to
> decide upon the scope of the next-hop being used.
> 

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

> Using link-local next-hops on an eBGP session established between
> directly connected neighbours on an IXP using global addresses for
> the endpoints has a strong smell of "too much IPv6 thinking" to me, 
> bringing extra pitfalls with no benefits that I can see (maybe I'm 
> overlooking something).
> 

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

Regards,
Mark.