Subject: Re: [netlmm] Comments on draft-ietf-netlmm-pmip6-ipv4-support-07

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 2 Jan 2009 11:37:57 -0800

Hi Vijay,
I have held off sending the document for AD review until another version of the draft is available with the comments and ID nits addressed.  Sri and Ryuji are working on a revision.  However, on the particular issue you mention, I'm not sure what needs to be clarified.  Do you have a problem with any normative text with respect to the consistency check on the IP address done by the MAG?  Reading the section, it doesn't appear to be normative.  As an optional consistency check, it seems fine to me.  Also, this doesn't appear to be a major issue to me (again, given the non-normative nature of the text).  

Let me know if I'm missing something. 

Vidya

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Wednesday, December 31, 2008 11:27 AM
> To: Narayanan, Vidya; [email-masked]
> Subject: RE: [netlmm] Comments on draft-ietf-netlmm-pmip6-ipv4-support-
> 07
> 
> Hi Vidya,
> 
> There is one major issue that I have raised twice so far. It has not
> been addressed yet. The document should not be sent to the IESG before
> that issue is addressed. The most recent email on this is at
> http://www.ietf.org/mail-archive/web/netlmm/current/msg05737.html
> 
> Vijay
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Narayanan, Vidya
> > Sent: Tuesday, December 30, 2008 3:39 PM
> > To: [email-masked]
> > Subject: [netlmm] Comments on draft-ietf-netlmm-pmip6-ipv4-support-07
> >
> > I read through the draft and it looks good overall.  I am
> > preparing the shepherding writeup to send the document for AD
> > review.  In the meantime, I enclose some comments I have in
> > this email.  These and a few other pending comments from the
> > mailing list can be addressed along with the AD review comments.
> >
> > * The document has a lot of forward references that make it
> > somewhat of a difficult read.  If possible, minimizing such
> > forward references would be helpful for the reader.
> >
> > * In section 3.3.1, is prefix length not needed?
> >
> > * Section 3.4 makes a recommendation for DHCP client
> > operation on the mobile node.  Since we cannot quite force a
> > particular behavior of an MN, it would be good to call out
> > the issues with changing client ids and leave it at that.
> >
> > * Section 3.4.1 should call out the impact to handoff latency
> > when the MAGs are configured with different DHCP server IP
> > addresses.  There is a latency impact when a FORCERENEW or a
> > timeout and re-negotiation of the full DHCP handshake has to
> > occur for the MN to renew its IP address.
> >
> > * In section 3.4.2, as part of Figure 7, the document notes
> > that steps 4 and 1-2 may occur in any order.  Is this really
> > true?  While the MN may send the DHCPDISCOVER before step 1
> > happens, shouldn't the MAG send the DHCPDISCOVER to the LMA
> > only after the tunnel is setup?
> >
> > * Section 5 is a bit confusing - I'm not sure why there is a
> > need for the configuration parameters.  Could the
> > encapsulation mode not be determined by the LMA, based on NAT
> > detection?  Further, on each one of those parameters, there
> > is no explanation on when it may be configured to be 0 or 1.
> > If these parameters must be present, some explanation to
> > clarify when what value makes sense is needed.
> >
> > * s/security associated/security association
> >
> > Thanks,
> > Vidya
> > _______________________________________________
> > netlmm mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/netlmm
> >
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 2 Jan 2009 14:53:32 -0500

Hi Vidya,

The checks proposed in the text that I pointed out are not optional.
Section 3.4.2 says

   o  When the DHCP client goes into the DHCP RENEW STATE [RFC-2131], it
      directly unicasts DHCPREQUEST message to the DHCP server.  The
      DHCP relay agent may not detect these unicasted DHCPREQUEST
      messages for renewing the address.  Thus, one of following
      operations is required.

So the MAG is required to implement one of the mechanisms described in
the next two paragraphs. Briefly, the MAG either needs to snoop all DHCP
messages on that data path or use RFC 5107, DHCP Server Identifier
Override Sub-option to force all subsequent DHCP messages to go through
the MAG always. 

> From: Narayanan, Vidya [mailto:[email-masked]] 
> Sent: Friday, January 02, 2009 11:38 AM
> To: Vijay Devarapalli; [email-masked]
> Subject: RE: [netlmm] Comments on 
> draft-ietf-netlmm-pmip6-ipv4-support-07
> 
> Hi Vijay,
> I have held off sending the document for AD review until 
> another version of the draft is available with the comments 
> and ID nits addressed.  Sri and Ryuji are working on a 
> revision.  However, on the particular issue you mention, I'm 
> not sure what needs to be clarified.  Do you have a problem 
> with any normative text with respect to the consistency check 
> on the IP address done by the MAG?  Reading the section, it 
> doesn't appear to be normative.  As an optional consistency 
> check, it seems fine to me.  Also, this doesn't appear to be 
> a major issue to me (again, given the non-normative nature of 
> the text).  

It is unlikely that the LMA allows the mobile node to request another
IPv4 address in the middle of a mobility session. When the LMA receives
a DHCP renew message with a different IP address from what was given to
the mobile node earlier (through the DHCP procedure and PBU/PBACK
exchange), it will reject the request. So I don't see what we gain out
of an optional check at the MAG. We either need a check at the MAG or we
don't. 

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 5 Jan 2009 00:40:57 -0800

Hi Vijay,

> Sent: Friday, January 02, 2009 11:54 AM
> the next two paragraphs. 

Technically, lowercase "required" is not an RFC 2119 keyword.  But, this can be ambiguous.  Perhaps this text can be reworded to avoid RFC2119 keywords entirely.  

> Briefly, the MAG either needs to snoop all
> DHCP

If we have text that says that the LMA MUST reject any requests for different IP addresses while a PMIP session is in progress, the check may not be needed.  Otherwise, there is a problem.  "Unlikely" is not good enough - protocol behavior must be deterministic.  "Unlikely" is the reason this check exists as optional, as far as I can tell.  

Vidya

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 5 Jan 2009 13:07:37 -0500

Hi Vidya, 

> >    o  When the DHCP client goes into the DHCP RENEW STATE 
> [RFC-2131],
> > it
> Technically, lowercase "required" is not an RFC 2119 keyword. 
>  But, this can be ambiguous.  Perhaps this text can be 
> reworded to avoid RFC2119 keywords entirely.  

The current text is pretty clear. It requires the MAG to perform the
check. You don't have to use "MUST" to mandate some behavior.

> > of an optional check at the MAG. We either need a check at 
> the MAG or
> > we
> > don't.
> > 
> 
> If we have text that says that the LMA MUST reject any 
> requests for different IP addresses while a PMIP session is 
> in progress, the check may not be needed.  Otherwise, there 
> is a problem.  "Unlikely" is not good enough - protocol 
> behavior must be deterministic.  "Unlikely" is the reason 
> this check exists as optional, as far as I can tell.  

Let me rephrase then. I shouldn't have used "unlikely". The LMA WOULD
NOT agree to change of the IPv4 address through the DHCP request in the
middle of a mobility session.

There is no statement in the draft currently that says the LMA MUST
reject the DHCP request if the request is for an address different from
the one that is allocated currently for the mobility session. I think we
should add this sentence. It is far easier to enforce this check at the
LMA. IMO, the LMA would have to check anyway. Otherwise it might end up
with inconsistent state.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 5 Jan 2009 12:24:33 -0800 (PST)

Hi Vidya,

> Technically, lowercase "required" is not an RFC 2119 keyword.  But, this can be ambiguous.  Perhaps this text can be reworded to avoid RFC2119 keywords entirely.

Ok. This can be reworded to clear such ambiguity. Clearly, its an optional
check and that is the intent.

Regards
Sri

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 6 Jan 2009 21:05:43 +0900

Hi Vijay and Vidya,

> LMA. IMO, the LMA would have to check anyway. Otherwise it might end  

Your proposal is applicable only when LMA and DHCP server are co- 
located.

Otherwise, LMA has no idea which address is requested by a mobile node.
The DHCP renew messages are directly sent to DHCP server and not via  
LMA.
To remove the message snooping and check at MAG, we need some  
interaction
between DHCP-server and LMA, which we would not  specify in our spec.

If LMA cannot verify the renewing address check, MAG needs to perform  
the address check
in order to avoid states conflicts between DHCP and PMIP.

But, let's not enforce the check at MAG when LMA and DHCP-server are  
co-located.
In that case, as you mentioned, LMA can perform the check on behalf of  
MAG.
MAG performs neither snooping DHCP renewing messages nor overwriting  
DHCP-server ID (RFC5107).
MAG can know the DHCP-Server and LMA co-location by comparing the  
source address
of DHCP message from DHCP server with LMA address.

regards,
ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 6 Jan 2009 21:21:57 +0900

Hi Vidya,

Thanks for your review.
On 2008/12/31, at 8:38, Narayanan, Vidya wrote:

> I read through the draft and it looks good overall.  I am preparing  
> the shepherding writeup to send the document for AD review.  In the  
> meantime, I enclose some comments I have in this email.  These and a  
> few other pending comments from the mailing list can be addressed  
> along with the AD review comments.
>
> * The document has a lot of forward references that make it somewhat  
> of a difficult read.  If possible, minimizing such forward  
> references would be helpful for the reader.
>

why? It's about default router. we don't need subnet mask to set a  
default route.

> * Section 3.4 makes a recommendation for DHCP client operation on  
> the mobile node.  Since we cannot quite force a particular behavior  
> of an MN, it would be good to call out the issues with changing  
> client ids and leave it at that.

We don't modify or recommend operations of DHCP clients. Which  
operation do you refer to?

>
> * Section 3.4.1 should call out the impact to handoff latency when  
> the MAGs are configured with different DHCP server IP addresses.   
> There is a latency impact when a FORCERENEW or a timeout and re- 
> negotiation of the full DHCP handshake has to occur for the MN to  
> renew its IP address.
>
> * In section 3.4.2, as part of Figure 7, the document notes that  
> steps 4 and 1-2 may occur in any order.  Is this really true?  While  
> the MN may send the DHCPDISCOVER before step 1 happens, shouldn't  
> the MAG send the DHCPDISCOVER to the LMA only after the tunnel is  
> setup?

DHCP messages are never relayed before proxy binding registration.This  
is already stated in the text.
o If the Proxy Binding Update message is rejected by the local  
mobility anchor for any reason, the local mobility anchor will discard  
the DHCPDISCOVER messages from the mobile node. o If the Proxy Binding  
Update message is accepted by the local mobility anchor and if there  
is an assigned IPv4 home address for the mobile node, the DHCP  
messages will be forwarded to the DHCP server.
o If the Proxy Binding Update message is accepted by the local  
mobility anchor and if there is an assigned IPv4 home address for the  
mobile node, the DHCP messages will be forwarded to the DHCP server.
We should update the notes in the Figure.

>
> * Section 5 is a bit confusing - I'm not sure why there is a need  
> for the configuration parameters.  Could the encapsulation mode not  
> be determined by the LMA, based on NAT detection?  Further, on each  
> one of those parameters, there is no explanation on when it may be  
> configured to be 0 or 1.  If these parameters must be present, some  
> explanation to clarify when what value makes sense is needed.

Compared to the regular DSMIP, operators can pre-know whether NAT is  
used or not in their PMIP domain.
Therefore, if NAT is not deployed in a PMIP domain, the NAT detection  
(Using IPv4-UDP encapsulated signaling) is just burden to them.
To avoid this, we have UseIPv4UDPEncapForSignalingMessages.
thanks,
ryuji

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 06 Jan 2009 10:59:02 -0800

Ryuji,

Ryuji Wakikawa wrote:
> Your proposal is applicable only when LMA and DHCP server are co-located.
> 
> The DHCP renew messages are directly sent to DHCP server and not via LMA.
> To remove the message snooping and check at MAG, we need some interaction

Note that a DHCP server cannot operate independently of the LMA in a 
PMIPv6 domain. There has to be some interaction between the DHCP server 
and the LMA for address assignment. IMO, the most likely deployment in 
the DHCP relay case, is for the LMA to act as a DHCP server. There might 
be another DHCP server that the LMA may contact for the actual address 
assignment, but the LMA would be processing the DHCP messages from the 
mobile node.

> In that case, as you mentioned, LMA can perform the check on behalf of MAG.
> MAG can know the DHCP-Server and LMA co-location by comparing the source 
> address

Sounds good to me.

Vijay