>> >> => 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. Hesham > > 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 >>> anyways. >>> >>> 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. > > Probably... > > Alex > >> >> Hesham >> >>> >>> Alex >>> >>> >>>> >>>> Hesham >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> >> > > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf