Re: [PATCH v2] babel: Add support for dual-stack v4/v6 operation
Ondrej Zajicek <santiago@crfreenet.org> writes:
On Tue, May 30, 2017 at 03:20:42PM +0200, Toke Høiland-Jørgensen wrote:
This adds support for dual-stack v4/v6 operation to the Babel protocol. Routing messages will be exchanged over IPv6, but IPv4 routes can be carried in the messages being exchanged. This matches how the reference Babel implementation (babeld) works.
Hi
Merged. I did some minor modifications. First, adding 'active' next_hop fields to struct babel_iface, so value in babel_iface_config is kept unmodified. Second, adding next_hop fields instead of just next_hop_seen fields to struct babel_write_state, so it is ready for third-party next hops.
Right, fair enough. Your changes look good to me.
BTW, are third-party next hops allowed in Babel? I checked RFC 6126 but found nothing.
Hmm, third-party next hops as in a next hop that is on a different node than the one running the routing protocol? There's no explicit support for it, but I guess you could do that (i.e., there's nothing that explicitly forbids it either). Not sure how babeld will react to non-LL next hop addresses...
Also note that the new next hop options are missing its documentation. Perhaps you could send following patch with that?
Ah yes, sorry about that. Was going to add that in v2, but guess I must have forgotten. Will send a separate patch that updates the documentation :) -Toke
On Thu, Jun 08, 2017 at 02:06:11PM +0200, Toke Høiland-Jørgensen wrote:
BTW, are third-party next hops allowed in Babel? I checked RFC 6126 but found nothing.
Hmm, third-party next hops as in a next hop that is on a different node than the one running the routing protocol?
Yes, using the original next-hop/via (as the route is exported to the protocol). Generally it is restricted to cases where the next-hop is on the same link/iface.
There's no explicit support for it, but I guess you could do that (i.e., there's nothing that explicitly forbids it either). Not sure how babeld will react to non-LL next hop addresses...
Note that it supposes that link level reachability is transitive, which is true for regular networks, but is not be true for ad-hoc wireless networks (and some other obscure types of networks). Also note that third-party next hops still may be link-local (say from OSPFv3) but also global (say from static protocol).
Also note that the new next hop options are missing its documentation. Perhaps you could send following patch with that?
Ah yes, sorry about that. Was going to add that in v2, but guess I must have forgotten. Will send a separate patch that updates the documentation :)
Thanks -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
BTW, are third-party next hops allowed in Babel? I checked RFC 6126 but found nothing.
They're not forbidden, but I don't think they are useful. There's no reason I can see why they wouldn't work, but I haven't actually tested.
Not sure how babeld will react to non-LL next hop addresses...
They're allowed. RFC 6126 4.4.8 says AE The encoding of the Address field. This SHOULD be 1 or 3 and MUST NOT be 0. This means that the next-hop SHOULD be either IPv4 or link-local IPv6, but may also be a global IPv6 address. I don't think I've ever tested babeld with global IPv6 next-hops, but if it doesn't work, it's a bug. -- Juliusz
participants (3)
-
Juliusz Chroboczek -
Ondrej Zajicek -
Toke Høiland-Jørgensen