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

[Hesham Soliman <[e-mail]>]

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

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.

Hesham

> 
> Alex
> 
> 
>> 
>> Hesham
>> 
>> 
>> 
>> 
>> 
> 
>