Subject: [netlmm] DHCP issue in IPv4 document - consensus call update

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 20 Apr 2009 12:57:30 -0700

We did see more people who were okay with keeping both options in the document than not.  However, one thing that became clear as a result of this consensus call is that the document needs far more clarity on this issue.  There is also quite a bit of difference in opinions on whether technically, the MAG even needs to stay synchronized on the DHCP state to begin with.

As a next step, I propose keeping the option in the document and describing the following: 

a) What happens when the MAG does nothing - i.e., if there is no synchronization of DHCP states at the MAG? 
b) What happens when the MAG does promiscuous packet capture to sync up DHCP states? 
c) How can RFC5107 be used for this purpose and what does it buy? 

With this clearly documented and RFC5107 being clearly noted as optional for implementation, we can move the document forward.  

Editors, please propose text to clarify the above.  We can revise the document with the text once the WG has had a chance to see it and move forward to IETF LC. 

Thanks,
Vidya

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 20 Apr 2009 13:28:22 -0700 (PDT)

Sure. We will clarify this and propose the text.

Thanks
Sri

On Mon, 20 Apr 2009, Narayanan, Vidya wrote:

> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm
>

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 21 Apr 2009 04:32:48 -0400

Hi,
 
I also brought up the need to include the case of handovers.
 
Thanks,
 
-Rajeev

________________________________

From: [email-masked] on behalf of Narayanan, Vidya
Sent: Mon 4/20/2009 12:57 PM
To: [email-masked]
Subject: [netlmm] DHCP issue in IPv4 document - consensus call update

Thanks,
Vidya

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 21 Apr 2009 10:54:43 -0700 (PDT)

> I also brought up the need to include the case of handovers.

Sure. The clarification will include this.

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 22 Apr 2009 22:58:37 -0700 (PDT)

These is the text related to the clarifications. If you have
any comments, let us know ...

New text related to handoff considerations, Rajeev's comment, this is
under the common section for both the modes, section 3.4.3

    o  When the mobile node performs an handoff from one mobile access
       gateway to the another, the mobile access gateway on the new link
       either upon detecting the mobile node on its access link, or upon
       receiving a handoff trigger from the network will initiate the
       Proxy Mobile IPv6 signaling with the local mobility anchor.  On
       completing the Proxy Mobile IPv6 signaling, the mobile access
       gateway has the proper IPv4 address state that the local mobility
       anchor has allocated for the mobile node.

    o  If the mobile node is DNAv4 [RFC-4436] capable and if it performs
       DNAv4 procedures after a handoff, it would however will always
       detect the same default-router on any of the access links in that
       Proxy Mobile IPv6 domain, as the mobile access gateway configures
       a fixed link-layer address on all the access links, as per the
       base Proxy Mobile IPv6 specification [RFC-5213].

    o  If the mobile node is not DNAv4 [RFC-4436] capable, after handoff
       it will enter INIT-REBOOT state [RFC-2131] and will send a
       DHCPREQUEST message.  The mobile node in both the configuration
       modes, specified in Section 3.4.1 and Section 3.4.2, will obtain
       the same address configuration as before, as the link change will
       not be transparent to the mobile node in that Proxy Mobile IPv6
       domain.

This is related to the MAG tracking the DHCP flows,, missing
2 points, one other point related to incorrect address is already
covered. Its in Section 3.4.2. Per Vidya's email.

   o   The mobile access gateway by being aware of the DHCP transactions
       between the mobile node and the local mobility anchor, using any
       of the above specified approaches, can ensure the IPv4 address
       configuration that the mobile node obtains from the DHCP server
       using DHCP protocol is the same as that it obtained using Proxy
       Mobile IPv6 signaling.  It can also be aware of the mobile node's
       address release events.

    o  At any time, the mobile access gateway detects that the mobile
       node has released its IPv4 address configuration, it can
       potentially de-register the IPv4 address configuration by sending
       a Proxy Binding Update message to the local mobility anchor.

One other editorial change, w.r.t moving couple of common points
from 3.4.1 and 3.4.2 to a common section 3.4.3, and avoid duplication.
This was also suggested by Ralph earlier, I missed it.

Sri

On Mon, 20 Apr 2009, Sri Gundavelli wrote:

>>  We did see more people who were okay with keeping both options in the
>>  document than not.  However, one thing that became clear as a result of
>>  this consensus call is that the document needs far more clarity on this
>>  issue.  There is also quite a bit of difference in opinions on whether
>>  technically, the MAG even needs to stay synchronized on the DHCP state to
>>  begin with.
>>
>>  a) What happens when the MAG does nothing - i.e., if there is no
>>  synchronization of DHCP states at the MAG?
>>  With this clearly documented and RFC5107 being clearly noted as optional
>>  for implementation, we can move the document forward.
>>
>>  Editors, please propose text to clarify the above.  We can revise the
>>  document with the text once the WG has had a chance to see it and move
>>  forward to IETF LC.
>>
>>  Thanks,
>>  Vidya