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

[Hesham Soliman <[e-mail]>]

>> =>  That can work but I don't understand why you don't like the host
>>  on egress interface behaviour. The RFC seems inconsistent on its
>> requirements for the egress interface at home, but it's been a long
>> time since I read it so I may have forgotten some of the reasons. I
>> think it can work and at least it will lead to a consistent
>> implementation.
> 
> I am not sure which RFC you mean seem inconsistent?  If rfc3963 - yes,
> it says MR MAY use the received RAs on the egress interface to
> autoconfigure an address and form a default route.  However, I think in
> practice pure linux does not do it (or am I missing radvd procsys
> options?).  One would have to check the public NEMOv6 implementations
> too.  Without NEMOv6 implementation this does not work (i.e. that MAY is
> interpreted as a no on pure linux).  With it I don't know.

=> Ok but now you're talking about an implementation issue. 3963 allows the
router to act as a host on its egress at home. Either we change
implementations or the RFC needs to be changed. Kernel implementations need
ro change anyway to support nemov6.

> 
> I myself have forgotten many of the reasons.  I think I vaguely remember
> Pascal insisting of that being MR-autoconfigure an address as a MAY
> because IIRC a Cisco router would autoconfigure an address and a default
> route.  I am not very precise on this remembering.

=> I also think what he suggested makes sense. Which means the MR would act
the same way at home or on a visited link when it comes to listening to RAs.
So it adds little argument to the need for dhc extensions.

> 
> If you mean RFC4861 then I think it is consistent andgood it has this
> distinction between Host and Router (Router doesn't autoconfigure a
> default route, etc.).

=> I was talking about 3963. 4861 is fine in this respect.

Hesham