Re: [IPv6] RFC 6724 shouldn't prefer partial reachability over reachability

[Ole Troan <[e-mail]>]

Ted,

> Well, e.g. in a stub network with DHCPv6 PD, if the customer site is multi-homed for resiliency, it would be nice if that worked. This would require the device on the stub network to try both source prefixes, so it probably doesn’t work at the moment, but we are talking about what remains to do to make it work. 
> It’s not clear to me that this is the killer app, or even the right approach, but I don’t see the problem that you do with exploring this: my motivation certainly isn’t to avoid paying for enterprise-grade routers other than in the sense that clearly they wouldn’t make economic sense in this application.
> 
> I do realize that if we made this work in the home, it would have implications for the enterprise market in the long run, but that’s a path we’ve all trod many times before, and I don’t think we should factor that concern into our evaluation of what the right approach to the problem is. 

The problem here is that for this to work you need to make it work for _all_ hosts in the network.
I don’t doubt that you can make it work for a single host stack.
I do doubt that you will make it work well even for that host (well being defined by the multihoming requirements RFC), since most applications do not deal with failing over to different SA,DA pairs well.

You are basically putting a burden on every host and application implementation for the relatively small return of sub-par multihoming.

Compare that to something as simple to deploy as NPTv6. Or PI multi-homing. Or provider assisted multi-homing…

The best approach I can think of is to deploy MHMP as a completely separate network for each provider. Separate SSID and separate interfaces/VLANs. That leaves you with an equally awkward interface as mobile phones typically have, where you manually switch between the providers. Can’t quite see how we can get my light switch to deal with that.

We have tried this for a couple of decades. Time to admit failure.

O.