Subject: [MEXT] Defense of Link-Local address by the HA when the MN/MR is away from home [Was: Re: DHCPv6 relay co-located with the DHCPv6 client at the MR for DHCPv6PD in NEMO]

From: Jean-Michel Combes <[email-masked]>
Date: Wed, 16 Jun 2010 15:55:31 +0200

Hi,

IMHO, such a proposal should not work all the time.
Explanations:
- If at home, the MR uses "classical" DHCP-PD.
- That means that the IP source address for DHCP messages sent by the
MR MUST be its Link-Local address (cf. RFC 3315) unless the DHCP
server has sent a Server Unicast option to the DHCP client (cf. RFC
3633, section 8)
- A Link-Local address has an infinite lifetime (cf. RFC 4862, section
5.3) and so one the MR has performed DAD for this one, it will never
check the uniqueness of this address, especially when the MR comes
back to its home link
- When the MR is away from home, and if the Link-Layer Address
Compatibility (L) flag is set to 1 in the BU, the HA MUST defend the
MR's Link-Local address (cf. draft-ietf-mext-rfc3775bis, section
10.4.1) to keep the uniqueness of this address on the home link.

But, I must admit I didn't find text when the IIDs for the Link-Local
address and the one for the Home Address are not the same (i.e. L flag
set to 0). So, I may assume that the HA doesn't defend the MR's
Link-Local address and so that can impact protocols where this address
is used (e.g. NDP, DHCP).

Did I miss something?

Thanks in advance for your replies.

Best regards.

JMC.

2010/4/16 Carlos Jesús Bernardos Cano <[email-masked]>:
> Hi all,
>
> Resulting from the discussion we are having on the nemo-pd draft, I'd
> like to ask the WG if they consider OK to describe only the following
> approach in the draft:
>
> - "DHCPv6 Relay Agent for transmission of DHCPv6 messages" While not at
> home, the MR uses a DHPCv6 relay agent function co-located in the MR
> with the DHCPv6 client function is used to send the DHCPv6 signalling
> through the MR-HA tunnel. This avoids us to make use of the exception
> formulated in Section 10.4.4 of RFC3775 about the processing of DHCPv6
> traffic (the tunnel is used instead of RH2 for that particular case).
> The relay function would be deactivated when the MR is at home.
>
> I'm fine with this change, but I'd like to know the opinion of the WG
> before implementing it.
>
> Thanks,
>
> Carlos
>
> --
> Carlos Jesús Bernardos Cano     http://www.netcoms.net
> GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
>
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>
>

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 17 Jun 2010 01:53:51 +0200

Hi Jean-Michel,

> check the uniqueness of this address, especially when the MR comes

If I understand correctly RFC3775bis, the MN/MR performs Duplicate
Address Detection on its link-local address every time it detects an L3
handover (section 11.5.1). If that is the case, there would be no
problem with current NEMO-PD draft, right?

Carlos

---

From: Jean-Michel Combes <[email-masked]>
Date: Thu, 17 Jun 2010 13:14:01 +0200

Hi Carlos,

> problem with current NEMO-PD draft, right?

Correct: that was the text I missed :) Thanks!

Now, I must admit I don't understand so the goal of the L flag in the BU ...

Best regards.

JMC.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 23 Jun 2010 11:31:02 +0200

Le 17/06/2010 13:14, Jean-Michel Combes a écrit :
> Hi Carlos,
>
> 2010/6/17 Carlos Jesús Bernardos Cano<[email-masked]>:
>> Hi Jean-Michel,
>>
>>> Explanations: - If at home, the MR uses "classical" DHCP-PD. -
>>> That means that the IP source address for DHCP messages sent by
>>> the MR MUST be its Link-Local address (cf. RFC 3315) unless the
>>> DHCP server has sent a Server Unicast option to the DHCP client
>>> (cf. RFC 3633, section 8) - A Link-Local address has an infinite
>>> lifetime (cf. RFC 4862, section 5.3) and so one the MR has
>>> performed DAD for this one, it will never check the uniqueness of
>>> this address, especially when the MR comes back to its home link
>>
>> Address Detection on its link-local address every time it detects
>> an L3 handover (section 11.5.1). If that is the case, there would
>> be no problem with current NEMO-PD draft, right?
>

I don't know it either, but people may say that the L flag is used when
we want HA to replay the MH/MR behaviour of some other protocols relying
on the link-layer address (when MH/Mr not at home).  Which protocol?
MLD?  OSPF?  It is not  clear to me, I haven't seen examples.

Alex

>>> Compatibility (L) flag is set to 1 in the BU, the HA MUST defend
>>> the MR's Link-Local address (cf. draft-ietf-mext-rfc3775bis,
>>> section 10.4.1) to keep the uniqueness of this address on the
>>> home link.
>>>
>>> But, I must admit I didn't find text when the IIDs for the
>>> Link-Local address and the one for the Home Address are not the
>>> same (i.e. L flag set to 0). So, I may assume that the HA doesn't
>>> defend the MR's Link-Local address and so that can impact
>>> protocols where this address is used (e.g. NDP, DHCP).
>>>
>>> Did I miss something?
>>>
>>> 2010/4/16 Carlos Jesús Bernardos Cano<[email-masked]>:
>>>> Hi all,
>>>>
>>>> Resulting from the discussion we are having on the nemo-pd
>>>> draft, I'd like to ask the WG if they consider OK to describe
>>>> only the following approach in the draft:
>>>>
>>>> - "DHCPv6 Relay Agent for transmission of DHCPv6 messages"
>>>> While not at home, the MR uses a DHPCv6 relay agent function
>>>> co-located in the MR with the DHCPv6 client function is used to
>>>> send the DHCPv6 signalling through the MR-HA tunnel. This
>>>> avoids us to make use of the exception formulated in Section
>>>> 10.4.4 of RFC3775 about the processing of DHCPv6 traffic (the
>>>> tunnel is used instead of RH2 for that particular case). The
>>>> relay function would be deactivated when the MR is at home.
>>>>
>>>> I'm fine with this change, but I'd like to know the opinion of
>>>> the WG before implementing it.
>>>>
>>>> Thanks,
>>>>
>>>> Carlos
>>>>
>>>> -- Carlos Jesús Bernardos Cano     http://www.netcoms.net GPG
>>>> FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
>>>>
>>>> _______________________________________________ MEXT mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/mext
>>>>
>>>>
>>
>> -- Carlos Jesús Bernardos Cano     http://www.netcoms.net GPG FP:
>> D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
>>
> _______________________________________________ MEXT mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/mext
>