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

From: [email-masked]
Date: Tue, 16 Dec 2008 21: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-07.txt
	Pages           : 49
	Date            : 2008-12-16

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-07.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: Thu, 18 Dec 2008 12:40:02 +0000

Hi;

Trying to apply this draft to my current implementation I've stumbled
over a couple of questions;

1. There exists a number of instances where the MAG explicitly MUST only
add one v4 home address option, with P=0. Shouldn't there be a
signalling consideration for the LMA verifying this, and what error
should be returned if the number of options > 1 or P=1.

2. In draft-ietf-mext-nemo-v4traversal-07 the method of selectively
de-registering a binding is by omitting that domain during a normal
registration; i.e removing the v4 home address options, and the v4 home
address registration will be removed. A request with lifetime 0 always
de-registers all bindings. In netlmm-pmip6-ipv4 its pretty much the
reverse, i.e. send a lifetime 0 and remove what it specifies. Would it
be possible to use the same path as v4traversal related to this, and
merely relax the v4traversal spec that the v6 information can't be
selectively de-registered?

3. The default gateway can be provided using the new opt; but the
netmask of the allocated/retrieved home address is unknown. I gather one
could require configuration of the hoa netmask on the MAG or that it'd
be retrieved by a process external to it. Would it be possible to
provide that information as part of the registration?

Regards,
Joel Hortelius.

---

From: Julien Laganier <[email-masked]>
Date: Thu, 18 Dec 2008 17:12:11 +0100

Hi Joel, all,

Some comments/questions below:

On Thursday 18 December 2008, Joel Hortelius wrote:
> 1. There exists a number of instances where the MAG explicitly MUST
> only add one v4 home address option, with P=0. Shouldn't there be a

What's the reason to limit a MN to only one v4 home address? Can't we 
just let the network deployment decide what they're up to?

> registration; i.e removing the v4 home address options, and the v4
> home address registration will be removed. A request with lifetime 0
> always de-registers all bindings. In netlmm-pmip6-ipv4 its pretty
> much the reverse, i.e. send a lifetime 0 and remove what it
> specifies. Would it be possible to use the same path as v4traversal
> related to this, and merely relax the v4traversal spec that the v6
> information can't be selectively de-registered?

I support keeping the semantic of PMIPv6 messages aligned with that of 
DSMIPv6, MIPv6, etc.

I think it is fine not to have a method to selectively deregister an 
IPv6 prefix since I do not see a usecase for that. This is contrast 
with the situation of IPv4 addresses where there's indeed a usecase 
because they are such a scarce resource and thus it makes sense to 
allocate them only when required. (FWIW 3GPP EPC doesn't do the former 
and requires the latter.)

> netmask of the allocated/retrieved home address is unknown. I gather
> one could require configuration of the hoa netmask on the MAG or that
> it'd be retrieved by a process external to it. Would it be possible
> to provide that information as part of the registration?

Since the link between the MN and the MAG is point to point, the MAG 
will not need to use the netmask to route packets to the MN, it simply 
uses the host route pointing to the right link. As to the MN, in case 
it needs the netmask, it can get it via DHCP.

--julien

---

From: Joel Hortelius <[email-masked]>
Date: Thu, 18 Dec 2008 17:37:09 +0000

Hi Again;

Comments inline;

> just let the network deployment decide what they're up to?

I don't mind having multipe v4 HoA's per node; I don't mind having
prefixes either, if one could find a use for them. But the draft in

3.2.3.1 Mobile Node Attachment and Initial Binding Registration

states twice "including exactly one instance of the IPv4 Home Address
option" and P=0

Thus my question regarding signalling considerations; if the draft
specifies that only one v4 HoA option may be added with P=0, then the
LMA by definition should verify it?

> it needs the netmask, it can get it via DHCP.

Ok; in my testsetup I use an emulated PPP, in which case the netmask
would have made life easier, but its not a requirement since I can
either calculate a working mask or retrieve it in the DHCP negotiation.

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 18 Dec 2008 10:15:47 -0800 (PST)

Hi Joel,

> should be returned if the number of options > 1 or P=1.

We had this (P) flag, since we are sharing the option from DSMIP spec.
May be we should have defined an option for this spec.

For the error scenario, we can add as how the LMA should handle this.
We can probably define a new error code to be used when there are more
than one IPv4 HoA options. If P flag is set, LMA can simple ignore this,
will add.

> selectively de-registered?

Not sure where is the difference. Even in this spec, the MAG can
re-register only addresses related to a specific address domain and
the other get de-registered. For selective dereg, there should be
a way for the MAG to perform de-reg, just as how we allow selective
addition. DSMIP also had some recent changes, from this spec point
of view, this capability to selective add/removal is needed, I dont
see why we should precent selective dereg of a given address domain.

> provide that information as part of the registration?

The mask is present in the IPv4 Address Ack option, pref-len field.

Regards
Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 18 Dec 2008 10:20:00 -0800 (PST)

> just let the network deployment decide what they're up to?

We had the support for multiple HoA's till -05 version of the document.
We had to take this out, as the general input from the WG that its not
needed and secondly DHCPv4 has no clear means to deliver multiple IPv4
addresses to the same interface.

Sri

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 18 Dec 2008 19:04:58 -0500

Sri,

I was under the impression you were going to remove the following text.
The MAG should not have to do this check. The LMA is not going to change
the IPv4 address given out to the mobile node in the middle of a
session. So this check is unnecessary. But I see that version 07 still
has this text.

   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.

      *  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.
 
Vijay

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Tuesday, December 16, 2008 9:00 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [netlmm] I-D 
> Action:draft-ietf-netlmm-pmip6-ipv4-support-07.txt
> 
> This draft is a work item of the Network-based Localized 
> Mobility Management Working Group of the IETF.
> 
>

---

From: Joel Hortelius <[email-masked]>
Date: Fri, 19 Dec 2008 10:00:13 +0000

Hi Sri;

Comments inline.

> than one IPv4 HoA options. If P flag is set, LMA can simple ignore this,

Ok, good. P flag set should probably generate an error as well though?
I.e. it would be a malformed request, asking for something not
provided/allowed by the spec?

> see why we should precent selective dereg of a given address domain.

Well, my opinion here is that by adding the selective de-reg, there's
suddenly two ways of accomplishing the same thing. The v4-traversal spec
already requires you to calculate the delta between different
registrations and update the binding accordingly. Adding a selective
de-reg would merely make the LMA more complex and not really add
anything when it comes to function as far as I can see.

My personal opinion is that pmip6-ipv4 should do binding updates the
same way the v4-traversal spec does, and merely relax the statement in 
v4-traversal 5.4.2.1.

> The mask is present in the IPv4 Address Ack option, pref-len field.

Unfortunately no. A v4 HoA ack in response to a HoA req with P=0 always
replies with a pref-len of 32. Had this discussion with the MEXT guys,
and they're unlikely to change that behaviour.