Subject: [babel] What to do if we don't know the next hop?

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Sun, 10 Jun 2018 15:50:24 +0200

Hey everyone

Section 4.6.9 of 6126bis says this about next hops:

>  The next-hop address for this update is taken from the last preceding
>  Next Hop TLV with a matching address family (IPv4 or IPv6) in the
>  same packet even if it was otherwise ignored due to an unknown
>  mandatory sub-TLV; if no such TLV exists, it is taken from the
>  network-layer source address of this packet.

However, when carrying IPv4 prefixes over a v6 transport, no
network-layer source address exists. The document doesn't explicitly say
what to do about such prefixes. The obvious answer is just to drop them,
but should this be spelled out?

And more importantly, should there be a prohibition against *sending*
such TLVs? It is, evidently, quite possible to write an implementation
that will happily distribute v4 routes over IPv6 with no valid next hop
if configured to run on a link with no v4 addresses configured. I know
because I did just that; the Bird implementation currently will not skip
over v4 routes if it can't find a next hop. I'll get this fixed in the
implementation, of course, but should this also be discussed in the
spec?

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 10 Jun 2018 17:15:31 +0200

> such TLVs?

That's a tricky one.  In the case of BGP, RFC 5549 allows just that --
announcing an IPv4 route with an IPv6 next hop.  5549 is pretty vague, but
my understnading is that the forwarding plane would do an ND lookup for
the IPv6 address of the next hop, then send IPv4 packets to the MAC
address thus obtained.  (The intent is to avoid assigning IPv4 addresses
to transit links; it's a matter of preference whether to use an IPv6 next
hop or borrow an IPv4 address from another link, Cisco-style.)

More generally, RFC 6126bis is deliberately vague about the forwarding
plane.  The intent is that the protocol announces routes, you attempt to
install the routes you grok, and keep the others uninstalled.

  - if you have no IPv4 stack, you drop any IPv4 routes;
  - if you cannot deal with IPv4 routes whose next hop is not in the
    directly connected prefix, you drop any IPv4 routes whose next hop is
    not in the directly connected prefix (that's what the BSD/Mac OS
    X port of babeld does, and what the old Quagga port used to do);
  - if you cannot deal with IPv4 routes with an IPv6 next hop, you drop
    IPv4 routes with an IPv6 next hop;
  - if you cannot deal with IPv6 routes whose next hop is not a link
    local, you drop any IPv6 routes whose next hop is not a link local.

I don't think that these cases need to be made explicit in RFC 6126bis.
I'm not sure if it's useful to mention that if you failed to install
a route, you MUST NOT announce it.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 10 Jun 2018 17:18:06 +0200

> address thus obtained.

On the other hand, perhaps it would be better to explicitly require such
routes to be dropped, in order to avoid confusion.  If the feature is ever
required, we'll write an extension to that effect.

So:

  (1) leave it vague;
  (2) explicitly MUST DROP;
  (3) explicitly define meaning.

I'm open to (1) and (2), I'm opposed to (3).  Opinions?

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Sun, 10 Jun 2018 19:43:18 +0200

> I'm open to (1) and (2), I'm opposed to (3).  Opinions?

I think I'd prefer (2). I agree that we shouldn't open the can of worms
that (3) implies :)

-Toke

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 11 Jun 2018 01:41:50 +0000

> >> That's a tricky one.  In the case of BGP, RFC 5549 allows just that
> >> -- announcing an IPv4 route with an IPv6 next hop.  5549 is pretty
> >> vague, but my understnading is that the forwarding plane would do an
> >> ND lookup for the IPv6 address of the next hop, then send IPv4
> >> packets to the MAC address thus obtained.
> >
> > On the other hand, perhaps it would be better to explicitly require
> > such routes to be dropped, in order to avoid confusion.  If the
> > feature is ever required, we'll write an extension to that effect.
> >
> > So:
> >
> >   (1) leave it vague;
> I think I'd prefer (2). I agree that we shouldn't open the can of worms that (3)
> implies :)

I like the simplicity and consistent behavior of (2). 
Barbara

---

From: David Schinazi <[email-masked]>
Date: Mon, 11 Jun 2018 13:51:40 -0700

> I like the simplicity and consistent behavior of (2). 

I agree. "MUST DROP" reduces confusion now and allows us to safely define an extension later when the need arises.
I'd also add "MUST NOT SEND" as well, to be overturned by the hypothetical future extension.

David