Subject: Re: [netlmm] [dhcwg] Review of draft-ietf-netlmm-pmip6-ipv4-support

From: Ralph Droms <[email-masked]>
Date: Tue, 3 Feb 2009 07:25:38 -0500

On Feb 3, 2009, at 12:25 AM 2/3/09, Sri Gundavelli wrote:

>
> Hi Ralph,
>
> Thanks for the review. Please see inline.
>
>
>
> On Mon, 2 Feb 2009, Sri Gundavelli wrote:
>
>>
>> From: Ralph Droms <[email-masked]>
>> To: Dhcwg WG <[email-masked]>
>> Sent: Monday, February 2, 2009 12:54:01 PM
>> Subject: [dhcwg] *THIRD TRY* Re: Review of draft-ietf-netlmm-pmip6- 
>> ipv4-support
>>
>> Here's my review of http://tools.ietf.org/html/draft-ietf-netlmm-pmip6-ipv4-support-09 
>>  ; Jari could use any additional comments in addition to my input.
>>
>> The idea behind Proxy Mobile IPv6 is to provide "transparent"  
>> mobility support for hosts, allowing them to switch attachment  
>> points without invoking IPv6 mobility on the host.  This draft  
>> suggests extensions to to Proxy Mobile IPv6 to allow the same sort  
>> of mobility for IPv4 hosts using the Proxy Mobile IPv6  
>> infrastructure.
>>
>> Focusing on the use of DHCP in the draft ... unless I misunderstand  
>> the way in which change-of-attachment/handoff will work, I think  
>> the text labeled "IPv4 Home Address Renewal with a different DHCP  
>> server (After Handoff):" in section 3.4.1 needs to be revised and a  
>> new section needs to be added to section 3.4.2.
>>
>
> Ok, We can organize it better, will try to break that into a section.

I don't see any text in 3.4.2 that addresses the problem of address  
renewal through a new relay agent (and, potentially, a new server).  I  
think that text needs to be added.  In general, the same scenarios  
apply to both sections 3.4.1 and 3.4.2, so I would expect both  
sections would be structured pretty much the same.

>> I don't think the scenario described under "IPv4 Home Address  
>> Renewal with a different DHCP server (After Handoff):" will ever  
>> occur, unless the mobile host can somehow switch attachment points  
>> without notifying the DHCP client to cause the client to go into  
>> INIT-REBOOT state.  Therefor, I think the associated text should be  
>> replaced with text that describes the scenario in which the mobile  
>> host has switched attachment points and broadcasts a DHCPREQUEST in  
>> INIT-REBOOT state.  Section 3.4.2 needs to be extended with similar  
>> text that describes the scenario in which the mobile host has  
>> switched attachment.
>>
>
> For the link-layers where this protocol be deployed will ensure the
> mobile does not detect a link change, Ex: when the access link is
> a PPP link, the handoff will ensure the mobile does not detect link
> change and so it should not go into INIT-REBOOT state, rather should
> perorm a DHCP renew.

Hm.  Well, OK, then that scenario should be described or a reference  
cited, as it wasn't obvious to me.  Will PPP always be in use - and if  
PPP is used, will DHCP still be used for address assignment?  If PPP  
is in use, where is the endpoint of the PPP tunnel?  To mask a switch  
of attachment points, wouldn't the PPP endpoint have to be in the  
mobile node?  Which, in turn, means that any DHCP traffic would  
traverse the PPP tunnel, bypassing the MAG?  Or am I totally confused?

In any event, if the mobile node can, in some scenarios, detect link  
attachment, text for the link reattachment case needs to be added.

>> Unless I just missed the text, it would be good to clarify that the  
>> "IPv4 Default-Router Address" received from the LMA needs to be  
>> forwarded through DHCP to the mobile host.  How does the DHCP  
>> server determine the subnet mask to send to the mobile host?  Might  
>> be helpful to add a table with the required options and the sources  
>> of the values for those options.
>>
>
> The prefix length is present in the IPv4 Home Address option. This
> is carried in the PMIP flows for allowing the MAG to be a default
> router. The assignment of the same in DHCP flows is assumed.

OK, for clarity I recommend adding text that explicitly lists what  
options are required in the DHCP exchange between the mobile node and  
the DHCP server and how those options such as Router, Subnet Mask, IP  
Address Lease Time and Server Identifier are determined.

I just noticed that this text from section 3.4.1 appears to be wrong:

       The server
       address, 'siaddr' field of the DHCPOFFER message, will be set to
       the mobile node's default-router address.

It should refer, I think, to the Router option, not the 'siaddr' field.

>> Editorial aside - and it may be too late to change at this point -  
>> why bother with "alignment"?  Is there really an advantage to  
>> putting data values on 32-bit boundaries these days in a control  
>> protocol?
>>
>
> I assume this is about the IPv4 Default-Router address option. We did
> not make any efforts to achieve that, just put the reserved field in
> between.

OK.

>> How does the MAG identify the LMA for the host?
>>
>
> This is from the policy profile, as specified in RFC-5213.

OK.

>> Sections 3.4.1 and 3.4.2 (Figures 6 and 7) show different orders  
>> for the DHCPDISCOVER and Proxy Mobile IPv6 signaling events.  The  
>> text for the figures explains that these messages can occur in any  
>> order.  In what situation would the Proxy Mobile IPv6 signaling  
>> begin before the DHCPDISCOVER is received?  If, in section 3.4.1,  
>> the Proxy Mobile IPv6 signaling can take place before the  
>> DHCPDISCOVER is received by the DHCP server, doesn't the DHCP  
>> server have to check to see if it already has an IPv4 address for  
>> the mobile host, as suggested in this text from section 3.4.2:  
>> "check if there is already an assigned IPv4 home address for the  
>> mobile node from the local mobility anchor"?
>>
>
>> How do DHCP address lease times and address assignments from LMAs  
>> interact?
>
> We probably should add a note on keeping the DHCP address lease time
> lower than the PMIPv6 binding life time, as we did in RFC-5213. We
> will add a note on this relation.

It might be possible to use T1 effectively here, to force the mobile  
node to confirm its lease in the case where the DHCP lease extends  
beyond the binding lifetime.

However, there are a couple of fundamental coordination problems.   
First, if DHCPFORCERENEW is not available, the DHCP address lease or  
T1 time must be coordinated to cause the mobile node to contact the  
DHCP service very soon after the potential binding lifetime  
expiration.  That is, the mobile node must poll the DHCP service soon  
after binding lifetime expires to minimize the time during which the  
mobile node continues to use the address with expired binding.

The second problem is coordinating the binding lifetimes and DHCP  
leases through the DHCP server.  You need to explain how the DHCP  
server is made aware of the binding lifetime so it returns the  
appropriate lease information to the mobile node.

>> Section 3.4.1 mentions the use of DHCPFORCERENEW, which is not  
>> universally implemented today.
>>
>
> Sure. We did take that into consideration and provided few alternative
> approaches of handling this.

I don't see any alternative to the use of DHCPFORCERENEW in the case  
where the binding lifetime is not extended (e.g., last paragraph of  
section 3.4.1).

This text in section 3.4.1 seems to assume the mobile node implements  
DHCPFORCERENEW:

    o  If the mobile access gateway on the access link receives any DHCP
       messages from the mobile node unicasted to a server address that
       is not locally configured, the mobile access gateway can unicast
       FORCERENEW message [RFC-3203] to the mobile node as shown in
       Figure 6-2).  This will force the mobile node to update the DHCP
       server address with the address of the mobile access gateway on
       the new link.  However, if the FORCERENEW message [RFC-3203] is
       also not supported by the DHCP server on the mobile access
       gateway, then that DHCPREQUEST message can be ignored.  This will
       force the mobile node to enter the DHCP REBINDING state  
[RFC-2131]
       and start the DHCPDISCOVER phase again.

...it mentions the case in which the server does not implement  
DHCPFORCERENEW, but does not mention the case in which the mobile node  
does not implement DHCPFORCERENEW.  The text also does not mention  
that the mobile node will not move to REBINDING state until time T2,  
which may be a significant delay.

That observation suggests a way to avoid DHCPOFORCERENEW - set time T2  
to be shortly after T1 to force the mobile node into REBINDING state  
quickly.  I would advise setting T2 to be one second later than T1 -  
in theory, T2 could be set to occur at the same time (or even before!)  
T1 ... but I won't guarantee that all DHCP clients will handle T2 <=  
T1 correctly.

I assume the binding can expire in the DHCP scenario described in  
section 3.4.2 as well; how will binding expiration be handled in that  
scenario?  Spec., how will the DHCP server know when the binding  
expires so it can send a DHCPFORCERENEW?

>> Does the text about DHCPRELEASE in section 3.4.2 also apply to  
>> section 3.4.1?
>
> Yes. In both the modes of operation, the MAG's behaviour of session
> disconnect when it detects the mobile node releasing the address
> is same.

OK, so the text in 3.4.2 should be pulled out to a section that  
applies to both scenarios, or it should be duplicated in section 3.4.1.

> Thanks again for the review.
>
> Regards
> Sri

Hope these comments are helpful...

- Ralph

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 12 Feb 2009 00:12:36 -0800 (PST)

Hi Ralph,

Sorry for the late reply. I seemed to have missed this... my error.
Please see inline.

On Tue, 3 Feb 2009, Ralph Droms wrote:

>> > Subject: [dhcwg] *THIRD TRY* Re: Review of 
>> > draft-ietf-netlmm-pmip6-ipv4-support
>> > 
>> > Here's my review of 
>> > http://tools.ietf.org/html/draft-ietf-netlmm-pmip6-ipv4-support-09 ; Jari 
>> > could use any additional comments in addition to my input.
>> > 
>> > The idea behind Proxy Mobile IPv6 is to provide "transparent" mobility 
>> > support for hosts, allowing them to switch attachment points without 
>> > invoking IPv6 mobility on the host.  This draft suggests extensions to to 
>> > Proxy Mobile IPv6 to allow the same sort of mobility for IPv4 hosts using 
>> > the Proxy Mobile IPv6 infrastructure.
>> > 
>> > Focusing on the use of DHCP in the draft ... unless I misunderstand the 
>> > way in which change-of-attachment/handoff will work, I think the text 
>> > labeled "IPv4 Home Address Renewal with a different DHCP server (After 
>> > Handoff):" in section 3.4.1 needs to be revised and a new section needs 
>> > to be added to section 3.4.2.
>> > 
>> 
> I don't see any text in 3.4.2 that addresses the problem of address renewal 
> through a new relay agent (and, potentially, a new server).  I think that 
> text needs to be added.  In general, the same scenarios apply to both 
> sections 3.4.1 and 3.4.2, so I would expect both sections would be structured 
> pretty much the same.
>

For both Section 3.4.1 and 3.4.2, Co-locoted Relay or Server mode, we have
covererd the cases of Initil Address Renewal, Address Renewal when no
handoff and Address renewal after the handoff. We have stated the
requirements on how to make it work, probably we need to add any text on
the potential issues. Sure, will add this.

>> > I don't think the scenario described under "IPv4 Home Address Renewal 
>> > with a different DHCP server (After Handoff):" will ever occur, unless 
>> > the mobile host can somehow switch attachment points without notifying 
>> > the DHCP client to cause the client to go into INIT-REBOOT state. 
>> > Therefor, I think the associated text should be replaced with text that 
>> > describes the scenario in which the mobile host has switched attachment 
>> > points and broadcasts a DHCPREQUEST in INIT-REBOOT state.  Section 3.4.2 
>> > needs to be extended with similar text that describes the scenario in 
>> > which the mobile host has switched attachment.
>> > 
>> 
> Hm.  Well, OK, then that scenario should be described or a reference cited, 
> as it wasn't obvious to me.  Will PPP always be in use - and if PPP is used, 
> will DHCP still be used for address assignment?  If PPP is in use, where is 
> the endpoint of the PPP tunnel?  To mask a switch of attachment points, 
> wouldn't the PPP endpoint have to be in the mobile node?  Which, in turn, 
> means that any DHCP traffic would traverse the PPP tunnel, bypassing the MAG? 
> Or am I totally confused?
>

If the underneath layer-2 technology, makes the mobile not detect the
handoff, the mobile after handoff should not reset any of its protocol
states. Depends on the access technology, PPP with PPP session context
transfer is one mode. We can state the requirements around this and else
the potential issue of client DHCP state reset. Will add some text.

> attachment, text for the link reattachment case needs to be added.

Sure

>> > Unless I just missed the text, it would be good to clarify that the "IPv4 
>> > Default-Router Address" received from the LMA needs to be forwarded 
>> > through DHCP to the mobile host.  How does the DHCP server determine the 
>> > subnet mask to send to the mobile host?  Might be helpful to add a table 
>> > with the required options and the sources of the values for those 
>> > options.
>> > 
>> 
> OK, for clarity I recommend adding text that explicitly lists what options 
> are required in the DHCP exchange between the mobile node and the DHCP server 
> and how those options such as Router, Subnet Mask, IP Address Lease Time and 
> Server Identifier are determined.
>

We probably discussed this a year back with you. By setting the siaddr
to the def-router address for that mobile, we are forcing the same address
for the server on any link.

>> > Editorial aside - and it may be too late to change at this point - why 
>> > bother with "alignment"?  Is there really an advantage to putting data 
>> > values on 32-bit boundaries these days in a control protocol?
>> > 
>> 
>> > Sections 3.4.1 and 3.4.2 (Figures 6 and 7) show different orders for the 
>> > DHCPDISCOVER and Proxy Mobile IPv6 signaling events.  The text for the 
>> > figures explains that these messages can occur in any order.  In what 
>> > situation would the Proxy Mobile IPv6 signaling begin before the 
>> > DHCPDISCOVER is received?  If, in section 3.4.1, the Proxy Mobile IPv6 
>> > signaling can take place before the DHCPDISCOVER is received by the DHCP 
>> > server, doesn't the DHCP server have to check to see if it already has an 
>> > IPv4 address for the mobile host, as suggested in this text from section 
>> > 3.4.2: "check if there is already an assigned IPv4 home address for the 
> It might be possible to use T1 effectively here, to force the mobile node to 
> confirm its lease in the case where the DHCP lease extends beyond the binding 
> lifetime.
>
> However, there are a couple of fundamental coordination problems.  First, if 
> DHCPFORCERENEW is not available, the DHCP address lease or T1 time must be 
> coordinated to cause the mobile node to contact the DHCP service very soon 
> after the potential binding lifetime expiration.  That is, the mobile node 
> must poll the DHCP service soon after binding lifetime expires to minimize 
> the time during which the mobile node continues to use the address with 
> expired binding.
>
> The second problem is coordinating the binding lifetimes and DHCP leases 
> through the DHCP server.  You need to explain how the DHCP server is made 
> aware of the binding lifetime so it returns the appropriate lease information 
> to the mobile node.
>

As in 5213, we can have this as a out of band requirement, to
ensure the lease lifetimes and binding lifetimes have relation. Even
other wise, for the case when the binding lifetime expires and even
when there is active DHCP lease, the MAG can pretty much tear down
the p2p link and force the client to reset its DHCP state.

> I don't see any alternative to the use of DHCPFORCERENEW in the case where 
> the binding lifetime is not extended (e.g., last paragraph of section 3.4.1).
>

Right after RFC page 27, we have listed two approaches, the use of fixed
DHCP server address and the Forcerenew option. I think, we need to
structure this sub sections, as you pointed out.

>      force the mobile node to enter the DHCP REBINDING state [RFC-2131]
> DHCPFORCERENEW, but does not mention the case in which the mobile node does 
> not implement DHCPFORCERENEW.  The text also does not mention that the mobile 
> node will not move to REBINDING state until time T2, which may be a 
> significant delay.
>
> That observation suggests a way to avoid DHCPOFORCERENEW - set time T2 to be 
> shortly after T1 to force the mobile node into REBINDING state quickly.  I 
> would advise setting T2 to be one second later than T1 - in theory, T2 could 
> be set to occur at the same time (or even before!) T1 ... but I won't 
> guarantee that all DHCP clients will handle T2 <= T1 correctly.
>
> I assume the binding can expire in the DHCP scenario described in section 
> 3.4.2 as well; how will binding expiration be handled in that scenario? 
> Spec., how will the DHCP server know when the binding expires so it can send 
> a DHCPFORCERENEW?
>

The MAG can tear the link down and force the client to init state. We will
add this for both 3.4.1 and 3.4.2

>> > Does the text about DHCPRELEASE in section 3.4.2 also apply to section 
>> > 3.4.1?
>> 
> OK, so the text in 3.4.2 should be pulled out to a section that applies to 
> both scenarios, or it should be duplicated in section 3.4.1.
>

Absolutely. Thanks for your review.

Regards
Sri