Subject: [netlmm] IPv4 Document Reviews

From: "Narayanan, Vidya" <[email-masked]>
Date: Sun, 7 Dec 2008 23:06:28 -0800

All,
Could everyone who had sent last call comments on the IPv4 document please take a look at the latest version to see if all your comments had been addressed?  Please do so within the next 2-3 days and send an email with any comments still not addressed. 

Thanks,
Vidya
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 10 Dec 2008 18:35:35 -0800

Hi,

A couple of issues that I raised earlier were not addressed. I am 
sending them again. I also have couple of additional comments.

>>       If the client hardware address is used as the
>>       identifier and if the mobile node performs an handoff between two
>>       interfaces, this hardware identifier will change and the DHCP
>>       server will not be able to identify the mobile node.  Thus, it is
>>       recommended that the DHCP client in a multihomed mobile node is
>>       configured to use a stable client identifier that does not change
>>       during the active life of its DHCP session.
> 
> I think the last sentence should be re-worded to
> 
>        Thus, it is
>        recommended that the DHCP client, which is using PMIPv6 for a
>        handover across interfaces, is configured to use a stable client
>        identifier that does not change during the active life of its
>        DHCP session.
> 
> Multi-homing also involves using two interface simultaneously. In that 
> case using the different hardware identifiers should be fine.
> 
>>    o  When the DHCP client goes into the DHCP-RENEWING-STATE [RFC-2131],
>>       it directly unicasts DHCPREQUEST message to the DHCP server.  The
>>       DHCP relay agent cannot receive the DHCPREQUEST for renewing
>>       addresses.  Thus, one of following operations is required.
>> 
>>       *  The DHCP relay agent SHOULD 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, it is possible to check the DHCP packets at the interface
>>          by enabling the promiscuous mode.
>> 
>>       *  The cost of monitoring packets is not negligible.  Therefore,
>>          The DHCP relay agent MAY use the DHCP Server Identifier
>>          Override Sub-option [RFC-5107] to intercept DHCPREQUESTs for
>>          the address renewal.  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
>>          Virtual DHCP 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.  As a result, the DHCP relay agent MUST monitor DHCP
>>          packets by force as described above.
>> 
>>    o  Once the DHCP relay agent intercepts the DHCPREQUEST from the
>>       mobile node, it MUST verify the requesting IPv4 home address
>>       stored in the DHCPREQUEST message.  The verification is operated
>>       by checking it with the binding update list for the mobile node.
>>       If the requesting IPv4 home address is not registered to the local
>>       mobility anchor, the mobile access gateway MUST NOT relay the
>>       DHCPREQUEST and MUST discard it.
> 
> Why is this an issue? Why should the MAG have to check if the mobile 
> node is using the right IPv4 home address every time the mobile node 
> does a renew? Wouldn't the DHCP server allocate the same IPv4 home 
> address again? Am I missing something?

Additional comments...

>    o  The local mobility anchor and the mobile access gateway MUST be
>       configured with IPv6 global addresses, even when they are in IPv4-
>       only network.  When using IPv4 transport, it is not required that
>       there is IPv6 routing enabled between the local mobility anchor
>       and the mobile access gateway.  However, there must be IPv6
>       routing enabled for the configured address locally within the
>       host.

What does the last sentence mean? Is it trying to say that that the 
PMIPv6 node must be able to receive the packets sent to the IPv6 
address? i.e., the address needs to be configured on some interface 
internally? Moreover, that sentence should say "node" and not "host". 
Neither the MAG nor the LMA are hosts.

>    o  If there is no Home Network Prefix option(s) [RFC-5213] present in
>       the request, but if the Binding Cache entry associated with this
>       request has IPv6 home network prefix(es), the local mobility
>       anchor MUST consider this as a request to extend lifetime only for
>       the IPv4 home address and not for the IPv6 home network
>       prefix(es).  Hence, the local mobility anchor SHOULD release all
>       the IPv6 home network prefix(es) assigned to that mobile node and
>       for that specific attached interface.  Similar considerations
>       apply for the case where there is no IPv4 Home Address option [ID-
>       DSMIP6] present in the request, but if the Binding Cache entry
>       associated with that request has both IPv4 home address and IPv6
>       home network prefix(es).

So the absence of either the Home Network Prefix option or the IPv4 home 
address option amounts to an implicit de-registration of the IPv6 prefix 
and IPv4 address respectively. Why? Shouldn't there be explicit 
signaling? Was this discussed on the mailing list? I might have missed it.

The rest looks good.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 11 Dec 2008 09:17:18 -0800 (PST)

Vijay,

inline ...

>>         identifier that does not change during the active life of its

Ok. This can be reworded.

>>  Why is this an issue? Why should the MAG have to check if the mobile node
>>  is using the right IPv4 home address every time the mobile node does a
>>  renew? Wouldn't the DHCP server allocate the same IPv4 home address again?
>>  Am I missing something?
>

Its an error check. The MAG, MN and LMA needs to be in sync. If the LMA
allocated one address. MAG has set up the forwarding for that address, but
if the MN is using a different address, its an error case.

> What does the last sentence mean? Is it trying to say that that the PMIPv6 
> node must be able to receive the packets sent to the IPv6 address? i.e., the 
> address needs to be configured on some interface internally? Moreover, that 
> sentence should say "node" and not "host". Neither the MAG nor the LMA are 
> hosts.

"host" should be changed to "node". Yes, the LMA needs to be IPv6 aware,
it should be able to receive IPv6 packets on the configured interface,
it should be able to internally route packets after the IPv4 decap is
performed.

> address option amounts to an implicit de-registration of the IPv6 prefix and 
> IPv4 address respectively. Why? Shouldn't there be explicit signaling? Was 
> this discussed on the mailing list? I might have missed it.
>

Yes. This was added per the discussion. In a handoff scenario, if the tMAG
is interested only in partial set of addresses and is not even aware of
all the addresses that the mobile was using prior to handoff, the MAG
would send a PBU with all that it is interested in, the rest would be
implicitly de-registed. Instead of blindly updating the lifetime of all
the prior allocated addresses, that the current MAG is does not even know,
this allows a way to clear that up.

> The rest looks good.

Ok. Good.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 11 Dec 2008 12:01:43 -0800

Sri Gundavelli wrote:

>>> node

But why? The LMA is not going to change the IPv4 home address in the 
middle of a session. We should not required the MAG to intercept every 
DHCPREQUEST message in the relay mode for some error condition that 
might never happen. I think we should remove this requirement on the MAG.

> it should be able to internally route packets after the IPv4 decap is

What does "internally routing a packet" in a host mean? Here is the 
suggest re-write of the above paragraph

   o  The local mobility anchor and the mobile access gateway MUST be
      configured with IPv6 global addresses, even when they are in IPv4-
      only network.  When using IPv4 transport, it is not required that
      there is IPv6 routing enabled between the local mobility anchor
      and the mobile access gateway.  However, they must be able to
      receive the PMIPv6 signaling messages sent to the configured
      IPv6 address after IPv4 decapsulation.

>> So the absence of either the Home Network Prefix option or the IPv4 
>> home address option amounts to an implicit de-registration of the IPv6 
>> prefix and IPv4 address respectively. Why? Shouldn't there be explicit 
> Yes. This was added per the discussion. In a handoff scenario, 

What happens in the non-handoff scenario? Can sa MAG implicitly delete 
the binding for the IPv4 home address or for one or more IPv6 prefixes, 
by just not including them in a refresh PBU? I think we should use 
explicit signaling in this case at least.

> if the tMAG
> all the addresses that the mobile was using prior to handoff, 

What if there is a multiple interface handoff scenario, where the mobile 
node initially has both IPv4 home address and IPv6 HNP on IF1, performs 
a handover to IF2, but chooses to only move the IPv4 session to IF2? The 
session based on IPv6 HNP stays on IF1. The new MAG (to which IF2 is 
attached) would only send a PBU for the IPv4 home address. Would the LMA 
delete the binding for the IPv6 HNP? It seems like a bad idea to have 
implicit de-registration, unless I am missing something.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 11 Dec 2008 14:53:00 -0800 (PST)

On Thu, 11 Dec 2008, Vijay Devarapalli wrote:

> But why? The LMA is not going to change the IPv4 home address in the middle 
> of a session. We should not required the MAG to intercept every DHCPREQUEST 
> message in the relay mode for some error condition that might never happen. I 
> think we should remove this requirement on the MAG.
>

Its a consistent check. We can make this optional.

> What does "internally routing a packet" in a host mean? Here is the suggest 
> re-write of the above paragraph
>

The host should have the ability to forward IPv6 packets between different
interfaces/cards. That is internal routing. Some call it forwarding,
some call it routing, but its the hosts ability which is the requirement.
We will rephrase this, if the term is the problem.

> What happens in the non-handoff scenario? Can sa MAG implicitly delete the 
> binding for the IPv4 home address or for one or more IPv6 prefixes, by just 
> not including them in a refresh PBU? I think we should use explicit signaling 
> in this case at least.
>

I agree. No non-handff cases, the MAG should send all the prefixes 
associated to that session. The spec requires that.

> What if there is a multiple interface handoff scenario, where the mobile node 
> initially has both IPv4 home address and IPv6 HNP on IF1, performs a handover 
> to IF2, but chooses to only move the IPv4 session to IF2? The session based 
> on IPv6 HNP stays on IF1. The new MAG (to which IF2 is attached) would only 
> send a PBU for the IPv4 home address. Would the LMA delete the binding for 
> the IPv6 HNP? It seems like a bad idea to have implicit de-registration, 
> unless I am missing something.
>

Partial handoff is a new requirement. It should be handled some thing like
with a new handoff hint (HI=6). So far in 5213 and in this spec, the 
handoff does not create a new BCE, it only updates and existing BCE and
moves all the sessions. This text allows any such future extensions.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 11 Dec 2008 15:56:48 -0800

Hi Sri,

> Its a consistent check. We can make this optional.

We should remove it.

> We will rephrase this, if the term is the problem.

What about the text I suggested below?

> with a new handoff hint (HI=6).

"Partial Handoff" is a new term we are introducing. :)

Using a new value for the Handoff Indicator would work as we discussed
offline. For others, the idea is that when the HI=6, the LMA understands
that it is a partial handover, where some of the MN's sessions are moved to
IF2. The other mobility sessions continue on IF1. This requires some
extensions of course.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 11 Dec 2008 19:37:52 -0800 (PST)

Hi Vijay,

>> Its a consistent check. We can make this optional.

The DHCP flows are seen by the relay anyways. This check is to ensure,
there are no inconsistent states. But, I tend to agree with you, as it
may not occur. I'm fine taking this check out. Ryuji ?

> What about the text I suggested below?

Great. Looks good. But, it does not change much, IMO. But, lets move on.
I'm fine with the removal of the phrase, "internal routing' with the
rephrasing as you suggested.

> IF2. The other mobility sessions continue on IF1. This requires some

Yes.

Sri

---

From: Julien Laganier <[email-masked]>
Date: Mon, 15 Dec 2008 12:20:35 +0100

Hello Vijay,

On Thursday 11 December 2008, Vijay Devarapalli wrote:
> >>>        the request, but if the Binding Cache entry associated
> >>> with this request has IPv6 home network prefix(es), the local
> >>> mobility anchor MUST consider this as a request to extend
> >>> lifetime only for
> >>>        prefix(es).  Hence, the local mobility anchor SHOULD
> >>> release all the IPv6 home network prefix(es) assigned to that
> >>> mobile node and for that specific attached interface.  Similar
> >>> considerations apply for the case where there is no IPv4 Home
> >>> Address option [ID-
> >>>        DSMIP6] present in the request, but if the Binding Cache
> >>> entry associated with that request has both IPv4 home address and
> >>> IPv6 home network prefix(es).
> >>
> >> So the absence of either the Home Network Prefix option or the
> >> IPv4 home address option amounts to an implicit de-registration of
> >> the IPv6 prefix and IPv4 address respectively. Why? Shouldn't
> >> there be explicit signaling? Was this discussed on the mailing
> >> list? I might have missed it.
> >
> What happens in the non-handoff scenario? Can sa MAG implicitly
> delete the binding for the IPv4 home address or for one or more IPv6
> prefixes, by just not including them in a refresh PBU? I think we
> should use explicit signaling in this case at least.

A similar addition has been made to DSMIPv6 in the MEXT WG ro remove an 
IPv4 home address from a BCE without using "explict" signaling; see 
5.4.2.1. Removing Bindings in:

<http://tools.ietf.org/html/draft-ietf-mext-nemo-v4traversal-07>

I had no time to develop a very strong opinion about doing that sort of 
things one way or another, but at least we should try to keep the 
semantics of the various flavor of MIPv6 as clean as possible by being 
consistent in our design choices.

--julien

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 17 Dec 2008 14:50:24 +0900

Hi 

At Thu, 11 Dec 2008 19:37:52 -0800 (PST),
> may not occur. I'm fine taking this check out. Ryuji ?

The DHCP renew is operated with unciast. Without check, MAG cannot
block the wrong DHCP requests tunneled to LMA (DHCP-server). 

If these messages are automatically tunneled to LMA, it might be
security vulnerability. MAG should ensure to tunnel the DHCP messages
related to the right home address.

We can relax this operation as SHOULD or MAY, but I disagree on
removing this operation.

ryuji