Re: [MEXT] Last Call: draft-ietf-mext-nemo-pd (DHCPv6 Prefix Delegation for NEMO) to Proposed Standard

[Hesham Soliman <[e-mail]>]

>> 
>> =>  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
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
>