Re: Automatically connecting stub networks...

[Ted Lemon <[e-mail]>]

On Jul 10, 2020, at 10:46 AM, Richard Patterson <[e-mail]> wrote:
> Honest question here, does the term "stub router" preclude it from being multihomed? 
> i.e. it could be a stub router for multiple networks, as you suggest.

Let’s be careful with our terms here. “Multi-homed” is usually talking about connectivity to the Internet. A stub router that routes for multiple stub networks is a different use case, although equally valid.

How a stub router should handle the multi-homing problem is an interesting problem. E.g., should it advertise prefixes on both provider networks on the stub network? For a constrained network, that might not be desirable, and it’s probably not reasonable to expect constrained nodes to be able to decide appropriately which upstream to use.  I don’t actually know of a clean way to solve this problem, because as we’ve seen with the “slaac improvements” discussion, knowing For Sure what the status of a prefix is if we are just using RAs is not really possible.  Since we’re using prefix delegation, conceivably the delegating router could send a DHCP Reconfigure message, but that would be new behavior, and how it’s handled would need to vary based on whether or not the host is multi-homed.

How a stub router would handle multiple stub networks is actually pretty straightforward—for stub-to-stub routing, it’s just a normal router; for stub-to-infrastructure and back, the stub router can be treated conceptually as one stub router per stub network—it would have to acquire a prefix for each stub network, it would have to advertise routes to each stub network, and so on.  I guess we’d want to specify that all of the stub network-specific routes would be sent in a single RA.  So yeah, it’s probably worth talking about both of these problems in the document.