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

From: [email-masked]
Date: Tue, 23 Sep 2008 01:15:01 -0700 (PDT)

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-05.txt
	Pages           : 47
	Date            : 2008-09-23

This document specifies extensions to Proxy Mobile IPv6 protocol for
adding IPv4 protocol support.  The scope of IPv4 protocol support is
two-fold: 1) extending 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-05.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: "Premec, Domagoj" <[email-masked]>
Date: Tue, 30 Sep 2008 17:23:15 +0200

Hi Sri, Ryuji, 

I read the draft and I think it is in a good shape, please find some comments below:

- use of unsolicited DHCPNACK
At couple of places the draft requires the MAG to send unsolicited DHCPNACK to revoke the IPv4 HoA from the MN.  However, as far as I know this is not compliant with the DHCPv4 RFCs. The regular DHCPv4 client will simply ignore such unsolicited DHCPNACK and nothing will happen. The only way to revoke the IPv4 address via DHCPv4 is to use FORCERENEW.

- DHCPRELEASE
The description of the DHCPRELEASE message triggering the MAG to send the PBU with lifetime of zero for the IPv4 HoA is still missing. IMO it would be good to have a text along the following lines as part of the draft:

3.4.3 DHCP Release 

The mobile node may release its IPv4 home address at any time by sending the DHCPRELEASE message [RFC-2131]. When the MAG detects the DHCPRELEASE message sent by the mobile node and containing the mobile node's IPv4 home address, the MAG SHALL de-register the mobile node's IPv4 home address with the LMA. The MAG SHALL send the Proxy Binding Update message containing the IPv4 Home Address option set to the mobile node's IPv4 home address and the lifetime SHALL be set to zero. The Proxy Binding Update message SHALL NOT contain the Home Network Prefix option. The LMA SHALL remove the IPv4 home address from the binding cache entry and respond to the MAG with the Proxy Binding Acknowledgment message indicating success. If there was no IPv6 Home Network Prefix registered for the mobile node, the LMA and MAG SHALL remove their binding cache and binding update list entries for the mobile node. If the binding cache entry contains the IPv6 Home Network Prefix registered for the mobile node, the IPv6 Home Network Prefix and its lifetime remain unaffected by such Proxy Binding Update message.

When reading the draft I couldn't find an answer to following question: assuming the BCE contains both the HNP and IPv4 HoA and the MAG sends the PBU containing only the IPv4 HoA (but no HNP), what is the behaviour? Will the LMA reject such PBU, will it extend the lifetime of the IPv4 HoA and remove the HNP from the BCE... could you please add some text to clarify?

- anti-spoofing check by MAG
Would it make sense to require the MAG to do an anti-spoofing check for the MN's IPv4 HoA before tunneling packets to the LMA? This would make sure that the MAG and the MN are in sync about the MN's IPv4 HoA and is of relevance for cases where the MN obtains its IPv4 HoA via other means (static, IPCP or any other link-layer specific mechanism...)

editorial:

3.1.2.5
> [...] only the respective states with respect
> those addresses [...]

"with respect" -> "with respect to"

3.2.3.3
"exactly one instance if" -> "exactly one instance of"

>   o  If there is an IPv4 Default-Router Address option present in the
>      received Proxy Binding Acknowledgement message, the mobile access
>      gateway MAY configure this address on its interface and respond to
>      any ARP requests sent by the mobile node for resolving the
>      hardware address of the default-router.

Maybe the following sentence could be added:
"When the ARP is not used on the link between the mobile access gateway and the mobile node, the mobile access gateway MAY use the IPv4 Default-Router-Address as the source address for any datagrams sent to the mobile node and originated by the mobile access gateway itself. The mobile access gateway MAY use the IPv4 Default-Router-Address to fill in the DHCP Router option [RFC-2132]."

3.4.1
>   [...] that is on co-
>   located on [...]
remove the first "on"

domagoj

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: 23. rujan 2008 10:15
> To: [email-masked]
> Cc: [email-masked]
> Subject: [netlmm] I-D 
> Action:draft-ietf-netlmm-pmip6-ipv4-support-05.txt
> 
> This draft is a work item of the Network-based Localized 
> Mobility Management Working Group of the IETF.
> 
> 
> This document specifies extensions to Proxy Mobile IPv6 
> protocol for adding IPv4 protocol support.  The scope of IPv4 
> protocol support is
> two-fold: 1) extending 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.
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
>