I ran RIP on ca. 50 multi-homed clients in the early 90'th wth /32 route injection for both addresses, which effectively was also used for what we'd call mobility today. Worked very good. Trying to remember the reconvergence time after link down... I think i had tuned down the RIP hello interval. Not quite sure. Stable & slow 10 Mbps ethernet + fast & flakey 100 Mbps FDDI or 155 Mbps ATM back then was the use-case. It did keep TCP connections running over link failures.
I would be a big fan of trying to use homenet to bring in a lightweigt version of something like this into standard OS host stacks. For real mobility, multi-homing redundancy and to enable anycasting. But then again, i have also been a fan hostroutes in ISO CLNS and have been jealous of only L2 switches being privileged to have host-routes for decades now. I probably would prefer not to use one of the real routing protocols, but something lightweight. RIP is a stupid routing protocol but just to announce aliveness of host interfaces it is pretty ook. And by not using your production routing protocol, any real router could easily distinguish those announcement from real routing protocol neighbor updates and accordingly apply different policies to them as needed. Of course something defined specific for this purpose (host address aliveness or the like) would be most clean IMHO. Wouldn't even bother about IPv4 anymore, so could be done on one of the IPv6 specific signaling protocols we have (ND ?). Having said this, the proliferation time of host stack improvements is so slow that i'd certainly not wanted to bet on having this in any IPv6 capable embedded clients in the home i might buy in the next 10 years, so the hacky way of the default-router proxying the creation of host routes is likely the necessary stopgap sollution if we want to go this route. Cheers toerless On Sat, Feb 21, 2015 at 03:41:47PM +0100, Juliusz Chroboczek wrote: > >>>> L3 - route injection (got a routing protocol there already, use it) > >>> > >>> This sounds like it needs at least a coordination protocol between the > >>> APs? > >> > >> NO, just between the first-hop (homenet) routers. Should work with > >> unchanged > >> of the shelf crap-APs as long as they're attached to a homenet router. > > > Could someone please explain to me how this is supposed to work? > > The client is running a stub implementation of the routing protocol. It's > performing the normal routing protocol activities, such as sending > periodic hellos and announcing routes or flooding LSPs. > > At any given time, the client has a default route through some > neighbouring Homenet router. It sends its outgoing traffic through that > router, which presumably knows how to deal with it. > > At any given time, the client is announcing a /128 route to itself to all > neighbouring Homenet routers. This route gets propagated through the > Homenet by the routing protocol, so that all Homenet routers know how to > route to the client. This assumes that the Homenet is not doing uRPF > internally. > > This approach has been extensively tested with Babel, with no link-layer > support, and the outage after roaming has been measured as 2 to 4 Hello > intervals, which is the time needed by the link quality estimator to yield > meaningful data. (Which, just between the two of us, is pretty annoying, > even if you're using Mosh.) > > -- Juliusz > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- --- Toerless Eckert, eck...@cisco.com _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
