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

[Alexandru Petrescu <[e-mail]>]

Le 10/09/2010 11:30, Hesham Soliman a écrit :
>
>
>
> On 9/09/10 4:28 PM, "Alexandru
> Petrescu"<[e-mail]> wrote:
>
>> Le 09/09/2010 08:01, Hesham Soliman a écrit :
>>>
>>>
>>>
>>> On 9/09/10 3:54 PM, "Wassim Haddad"<[e-mail]>
>>> wrote:
>>>
>>>> On Sep 8, 2010, at 7:58 AM, Alexandru Petrescu wrote:
>>>>
>>>>> I agree mainly with the document draft-ietf-mext-nemo-pd.
>>>>>
>>>>> It is good and needed to dynamically assign a Mobile Network
>>>>>  Prefix to the NEMO-enabled Mobile Router.
>>>>>
>>>>> However, here are a couple of missing points.
>>>>>
>>>>> One missing point is about how will the Mobile Router
>>>>> configure its default route on the home link?  I thought
>>>>> Prefix Delegation would bring DHCP in the picture and would
>>>>> allow MR to synthesize a default route even though RAs are
>>>>> absent.  But I now realize that a DHCPv6-PD implementation
>>>>> (and std?) does not allow a router (MR) to synthesize its
>>>>> default route (neither RA does, nor DHCPv6-nonPD does).
>>>
>>> =>   I think the MR can easily act as a host on its egress
>>> interface and configure its default/next hop router that way. Of
>>> course the other alternative is to use routing protocols, but I
>>> think using ND should be sufficient.
>>
>> Hesham - when at home, the MR acts  as a router (ip_forward==1,
>> join all-routers group), as such ND is insufficient to obtain the
>> default route - it's a Router.
>>
>> When at home, and using DHCPv-PD, the MR also acquires its Home
>> Address with DHCPv6.  If so, then it doesn't use SLAAC to
>> auto-configure neither a Home Address nor a default route.
>>
>> In implementation it is of course possible to dynamically change MR
>> behaviour from Host to Router: be at home, first act as host
>> (fwd==0) to acquire the Home Address and default route, then set
>> fwd=1 and use DHCPv6-PD to acquire a prefix (but not the Home
>> Address) and take advantage of the default route acquired
>> previously as a Host.  This is one way of solving the issue.
>
> =>  Exactly.
>
> However it is not specified.
>
> =>  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.

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