> [...] IPv6, where routers communicate using link-local addresses. For
> what it's worth, Babel is quite able to establish adjacencies before
> addressing is up as well as in pure IPv4 networks.
I've received a few questions about this by private mail, so please let me
lecture a little. The chairs will let me know if that's too much of an
off-topic for this list.
Take a traditional single-stack routing protocol for IPv4, say RIPv2 or
OSPFv2:
1. your neighbour database is indexed by (interface, IPv4) pairs;
2. your routes' next hops are (interface, IPv4) pairs.
This means that you need to wait for an IPv4 address before you can do
anything. You can work around that by putting a (site-local) static IPv4
on the loopback interface, but that involves some administrative overhead,
and hence is not applicable to Homenet.
Compare this with an IPv4 routing protocol that is layered directly above
802.2, say a pure IPv4 implementation of ISIS:
1. your neighbour database is indexed by (interface, MAC) pairs;
2. your routes' next hops are (interface, IPv4) pairs.
Since MAC addresses always exist, you can establish neighbour relationships
as soon as the interface is up -- no need to wait for global addresses to
be assigned. If you're link state, you can start flooding as soon as the
adjacency is up, which is pretty cool. However, since next hops are IPv4
addresses, you still cannot route until both you and your neighbour get
assigned addresses.
Now take the simple same single-stack protocol and port it to IPv6 (RIPng
or OSPFv3):
1. your neighbour database is indexed by (interface, link-local IPv6);
2. your routes' next hops are (interface, link-local IPv6) pairs.
If link-local IPv6 exist soon enough after the link is up, you get all of
the benefits of a stable neighbour identifier -- you establish adjacencies
and start flooding as soon as the interface is up and has a link-local
IPv6. In addition, since your next hops exist, you can start routing as
soon as the interface is up -- a big win if the address distribution
protocol is slow or unreliable. Finally, you don't need to do anything
special when you renumber, the next hops use stable identifiers.
Consider now a double-stack protocol running over IPv6, such as Babel:
1. your neighbour database is indexed by (interface, link-local IPv6);
2. your routes' next hops are (interface, link-local IPv6) or
(interface, IPv4) pairs, depending on the address family.
Here, for IPv6 you're just like the previous case; for IPv4, you need an
address before you can route. The effect is that a Babel router starts
routing IPv6 as soon as the interface is up, but needs to delay installing
IPv4 routes until both neighbouring interfaces have an IPv4 address. In
effect, when the address configuration protocol has a hiccup, IPv6 routing
remains stable but IPv4 needs to reconverge.
In summary, by running your routing protocol over IPv6, you get the
advantages of the ISIS approach, but in addition you gain:
(1) the ability to run over GRE tunnels and OpenVPN in "tun" mode;
(2) much simpler implementation on Unix -- no need to use raw sockets,
just plain RFC 3493.
What you don't get is the conceptual elegance of proper layering.
-- Juliusz
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
