=> Who cares, specify it in your product description. The IETF
doesn't specify how to build products.
Hmm... to me it is a very IETF sensitive issue the Router vs Host. For
example, an ND spec says distinctively what a Host and what a Router
does, e.g. a Host does not respond to Router Solicitation.
=> Yes and it does so on a per-interface basis, not on a per-machine basis.
In this same way a Router should dynamically be able to obtain a default
route, in addition to a Host doing so.
The products sold are neither Hosts nor Routers - they're BFRs, servers,
desktops, tablets, laptops.
If you want to solve this with protocols then use routing protocols.
Of course you need to solve the security issues when the MR moves.
But SLAAC (what you call ND) is not a routing protocol yet does deliver
a default route, only to Hosts. DHCPv6 is not a routing protocol either
but does not deliver a default route neither to Hosts nor to Routers.
(I am not clear whether the DHCPv6 spec forbids delivery of a default
route; or allows; I have to check; the implementation does not.)
I am not
sure how clean is it anyways to disregard that 'M' bit of RA
The alternative to using routing protocols (OSPF?) to communicate a
default route to the MR - I am not sure how this could work, never
seen it in practice.
=> For a good reason! You need to work out trust across domains.
Ietf mailing list