Subject: [netlmm] I-D Action:draft-ietf-netlmm-pmip6-ipv4-support-08.txt

From: [email-masked]
Date: Mon, 19 Jan 2009 00:00:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network-based Localized Mobility Management Working Group of the IETF.

	Title           : IPv4 Support for Proxy Mobile IPv6
	Author(s)       : R. Wakikawa, S. Gundavelli
	Filename        : draft-ietf-netlmm-pmip6-ipv4-support-08.txt
	Pages           : 48
	Date            : 2009-01-18

This document specifies extensions to Proxy Mobile IPv6 protocol for
adding IPv4 protocol support.  The scope of IPv4 protocol support is
two-fold: 1) enable IPv4 home address mobility support to the mobile
node. 2) allowing the mobility entities in the Proxy Mobile IPv6
domain to exchange signaling messages over an IPv4 transport network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netlmm-pmip6-ipv4-support-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: Joel Hortelius <[email-masked]>
Date: Mon, 19 Jan 2009 10:55:42 +0000

Thanks for the update Sri;

A reflection though;

The 'default-router' option seems to mix a bit between MUST & MAY. When
processing the ack it seems to be MAY but when sending it, it MUST be
provided.

Am I correct in interpreting the text relating to the Home Address Ack
option, that the prefix length value in this draft is indeed the number
of bits in the HoA's netmask, and not as in the DSMIPv6 draft always 32?

/J.

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 19 Jan 2009 10:19:34 -0800 (PST)

Hi Joel,

> processing the ack it seems to be MAY but when sending it, it MUST be

Ok. We will check and reword as needed, along with the AD review comments.

> of bits in the HoA's netmask, and not as in the DSMIPv6 draft always 32?

I never responded to this I guess. Sorry. We are leveraging the option 
from DSMIP, that's all. The prefix length content needs to be interpreted 
as specified here. Its not 32 as in DSMIP6. I wish, we had defined our own 
option, but we some how used the option from DSMIP.

Sri

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 19 Jan 2009 20:46:26 -0500

Sri, Ryuji,

The wrong paragraph got modified. My objections were to the following
text in pages 30 and 31.

  IPv4 Home Address Renewal to the same DHCP server: (No Handover)

   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, any of the following
      approaches can be adopted.

      *  The DHCP relay agent can intercept all the DHCP packets
         regardless of the destination address.  Since the link between
         a mobile node and a mobile access gateway is the point-to-point
         link, the mobile access gateway will be in path for all the
         messages.

      *  The DHCP relay agent can use the DHCP Server Identifier
         Override Sub-option [RFC-5107] to be in path for all the DHCP
         message flows.  The DHCP client uses the DHCP server address
         which is overridden by the DHCP relay agent address as a
         destination address of DHCPREQUEST.  The DHCP Server Identifier
         Override Sub-option is recommended only when the fixed DHCP
         relay address is configured on all the mobile access gateways.
         Otherwise, the DHCP relay agent address is changed when the
         mobile node changes the attached mobile access gateway.

   o  The DHCP Relay agent on detecting the DHCPREQUEST message from the
      mobile node, will verify if the address in the DHCPREQUEST message
      is the address assigned by the local mobility anchor for that
      mobile node.  If the requesting IPv4 home address is not
      registered to the local mobility anchor, the mobile access gateway
      will drop the packet.  Once the address verification is
      successfully completed, the DHCP relay agent will forward the
      DHCPREQUEST message to the DHCP server.

The MAG should not have to perform the check on the DHCPREQUEST message
from the mobile node, if the DHCP server and the LMA are co-located. I
wanted some text that explicitly says the LMA would do the check while
processing the DHCPREQUEST and the MAG does not. 

Instead you have introduced a new paragraph where the MAG performs a
check on the DHCPOFFER message from the LMA in the "Initial IPv4 Home
Address Assignment:" section. This was not there before. Please fix
this.

Vijay

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Monday, January 19, 2009 12:00 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [netlmm] I-D 
> Action:draft-ietf-netlmm-pmip6-ipv4-support-08.txt
> 
> This draft is a work item of the Network-based Localized 
> Mobility Management Working Group of the IETF.
> 
>

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 20 Jan 2009 11:30:14 -0800 (PST)

There is explicit text that suggests, the MAG is not required to
perform the check if the LMA and the DHCP server are co-located.
Its in the first part of Section 3.4.2 and that broadly applies
to all DHCP flows, including DHCP address renewal. Clearly the
intent is to say, it is not required when both are co-located,
excluding the fact that this entire text is non-normative. This
can be stated again, but this text broadly covers that.

       However, the mobile access gateway is not required to perform this
       check, if the DHCP server is co-located with the local mobility
       anchor, as that check will be performed by the local mobility
       anchor in such scenario.  The mobile access gateway can determine
       the co-location of the DHCP server and the local mobility anchor
       by comparing the source address of the DHCPOFFER message with the
       address of the mobile node's local mobility anchor.

Sri

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 20 Jan 2009 14:36:10 -0500

Here is the entire paragraph.

   o  On receiving a DHCPOFFER message from the DHCP server, the mobile
      access gateway will ensure the assigned address is currently
      assigned by the local mobility anchor to that mobile node.  If
      this address is different from what is assigned to the mobile
      node, then the mobile access gateway will drop the DHCPOFFER
      message and an administrative error message will be logged.
      However, the mobile access gateway is not required to perform this
      check, if the DHCP server is co-located with the local mobility
      anchor, as that check will be performed by the local mobility
      anchor in such scenario.  The mobile access gateway can determine
      the co-location of the DHCP server and the local mobility anchor
      by comparing the source address of the DHCPOFFER message with the
      address of the mobile node's local mobility anchor. 

How can you deduce from the above paragraph that the MAG can skip the
check on DHCPREQUEST message sent for renewing the address? :) The above
paragraph clearly talks about the DHCPOFFER message. 

Note that version 07 had nothing about the MAG performing such a check
on the DHCPOFFER message during the initial registration. You introduced
the check in version 08 and then added text that says the MAG can skip
the check if the DHCP server and the LMA are co-located.

All along my concern was about the MAG performing the check on the
DHCPREQUEST for renewing the IPv4 home address. Not the DHCPOFFER from
the LMA.

Vijay

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Tuesday, January 20, 2009 11:30 AM
> To: Vijay Devarapalli
> Cc: Ryuji Wakikawa; [email-masked]
> Subject: Re: Comments on draft-ietf-netlmm-pmip6-ipv4-support-08
> 
> Hi Vijay,
>

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 20 Jan 2009 14:15:13 -0800 (PST)

On Tue, 20 Jan 2009, Vijay Devarapalli wrote:

> Sri,

Ok. I can move the text related to skip, to the DHCP renewals section.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 20 Jan 2009 14:19:04 -0800

> Ok. I can move the text related to skip, to the DHCP renewals section.

Thanks. I would like to see the new version submitted before the 
document is sent to the IESG.

Vijay