Note that OSPFv3 can also support advertisement of IPv4 prefixes - see RFC 5838.
Thanks, Acee -----Original Message----- From: Juliusz Chroboczek <[email protected]> Date: Sunday, June 1, 2014 6:07 AM To: "[email protected]" <[email protected]> Subject: [homenet] Routing over IPv6 [was: Single or Multiple Routing Protocols...] >> [...] 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 _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
