Subject: [netlmm] Comments on DHCP section in draft-ietf-netlmm-pmip6-ipv4-support

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 23 Oct 2008 11:41:53 -0700

Sri, Ryuji,

A few more comments on the DHCP section.

>    o  The DHCP server or the DHCP relay agent configured on the mobile
>       access gateway is required to have an IPv4 address for exchanging
>       the DHCP messages with the mobile node.  This address can be
>       either the IPv4 Proxy Care-of Address or the mobile node's
>       default-router address provided by the local mobility anchor.
>       Optionally, all the DHCP servers co-located with the mobile access
>       gateways in the Proxy Mobile IPv6 domain can be configured with a
>       fixed IPv4 address.  This fixed address can be potentially an IPv4
>       link-local address [RFC-3927] that can be used for the DHCP
>       protocol communication on any of the access links.  This address
>       will be used as the server identifier in the DHCP messages.

We are already ensuring that the mobile node sees the same default 
router IP address for the MAGs, by carrying this information in 
PBU/PBAck messages. All the MAGs in the PMIPv6 domain use the same 
default router IP address. Why can't this default router address be used 
for DHCP server address too? Why do we need another optional mechanism 
to use a virtual address for DHCP server IP address? This "virtual DHCP 
address" is also mentioned in section 3.4.2 (page 28). Am I missing 
something?

>       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 hardware identifier should be fine.

>    When the DHCP client goes into the DHCP RENEWING state [RFC-2131], it
>    directly unicasts the DHCPREQUEST message to the DHCP server that
>    currently provided the DHCP lease.  However, if the mobile node
>    changed its point of attachment and is attached to a new mobile
>    access gateway, it is required that the mobile node updates the DHCP
>    server address and uses the address of the DHCP server that is on co-
>    located on the new mobile access gateway.  Any of the following
>    approaches can be adopted for forcing the DHCP server address change.
> 
> 
>    1. The use of fixed DHCP server address on all DHCP servers
>      MN   oMAG(DHCP-S) nMAG(DHCP-S)
>       |       :        |
>     RENEW------------->|    1. DHCPREQUEST (IPv4 HoA)
>     BOUND<-------------|    2. DHCPACK or DHCPNACK
>       |       :        |
> 
>    2. The use of FORCERENEW message to notify the address change
>      MN prev-MAG (DHCP-S) new-MAG (DHCP-S)
>       |       :        |
>     RENEW------------->|    1. DHCPREQUEST*a (IPv4 HoA)
>       |<---------------|    2. FORCERENEW
>       |--------------->|    3. DHCPREQUEST*b (IPv4 HoA)
>     BOUND<-------------|    4. DHCPACK or DHCPNACK
>       |       :        |
>                             *a DHCPREQUEST sent to oMAG
>                             *b DHCPREQUEST sent to nMAG
> 
>    3. The use of different address on different DHCP servers
>      MN prev-MAG (DHCP-S) new-MAG (DHCP-S)
>       |       :        |
>     RENEW------------->|    1. DHCPREQUEST (IPv4 HoA)
>       |       :        |     (discarding & timeout)
>     REBINDING--------->|    2. DHCPDISCOVER
>       |<---------------|    3. DHCPOFFER  (IPv4 HoA)
>       |--------------->|    4. DHCPREQUEST(IPv4 HoA)
>     BOUND<-------------|    5. DHCPACK    (IPv4 HoA)
>       |       :        |

Why can't we just say, use approach (1). If the default router IP 
address is used as the DHCP server address, then we only have approach 
(1), right? We wouldn't need approaches (2) and (3).

>    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 even without the "Agent Remote ID Sub-option"? Am I 
missing something again?

Vijay

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

---

From: [email-masked]
Date: Fri, 24 Oct 2008 16:28:22 +0900

Hi Vijay

At Thu, 23 Oct 2008 11:41:53 -0700,
> address" is also mentioned in section 3.4.2 (page 28). Am I missing 

Good point.  One possible issue is that if default router address is
changed per mobile node, MAG might uses multiple DHCP addresses for
mobile nodes. In DHCP, the DHCP address is also picked us DHCP server ID.
IMO, using multiple different IP addresses per mobile node is not good idea.

> case using the hardware identifier should be fine.

Do you mean two HNPs for two interfaces here?

> (1), right? We wouldn't need approaches (2) and (3).

right. If we can agree to have fixed DHCP server address on all DHCP servers, 
I would remove 2 and 3.

> address again even without the "Agent Remote ID Sub-option"? Am I 

The IPv4 address pool is managed by LMA. DHCP is just doing signaling
to assign the LMA assigned address to MN. Therefore, MAG should check
the address status with LMA at the RENEW stage. 

regards,
ryuji

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 24 Oct 2008 13:24:15 -0400

Hi Ryuji,

[email-masked] wrote:
>>>    o  The DHCP server or the DHCP relay agent configured on the
>>>       mobile access gateway is required to have an IPv4 address for
>>>       exchanging the DHCP messages with the mobile node.  This
>>>       address can be either the IPv4 Proxy Care-of Address or the
>>>       mobile node's default-router address provided by the local
>>>       mobility anchor. Optionally, all the DHCP servers co-located
>>>       with the mobile access gateways in the Proxy Mobile IPv6
>>>       domain can be configured with a fixed IPv4 address.  This
>>>       fixed address can be potentially an IPv4 link-local address
>>>       [RFC-3927] that can be used for the DHCP protocol
>>>       communication on any of the access links. This address will
>>> be used as the server identifier in the DHCP messages. 
>> 
>> default router IP address. Why can't this default router address be
>> used for DHCP server address too? Why do we need another optional
>> mechanism to use a virtual address for DHCP server IP address? This
>> "virtual DHCP address" is also mentioned in section 3.4.2 (page 28).
>> Am I missing something?
> 

Why would the default router address change per mobile node? For a
certain IPv4 prefix, I expect the MAG to use the same default router IP
address for all mobile nodes that get an IPv4 home address from that
prefix. 

>>>       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. 
>> 
>>        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 hardware identifier should be fine.
> 

Right. A multi-homed mobile node could use the hardware addresses for
each of the interfaces and get a different HNP for each interface. If
the mobile node wants the same address/HNP across two interfaces, then
it should use a "stable client identifier" as described above. Instead,
the existing text is saying, a multi-homed mobile node should not use
the hardware address.

>>>    When the DHCP client goes into the DHCP RENEWING state
>>>    [RFC-2131], it directly unicasts the DHCPREQUEST message to the
>>>    DHCP server that currently provided the DHCP lease.  However, if
>>>    the mobile node changed its point of attachment and is attached
>>>    to a new mobile access gateway, it is required that the mobile
>>>    node updates the DHCP server address and uses the address of the
>>>    DHCP server that is on co- located on the new mobile access
>>>    gateway.  Any of the following approaches can be adopted for
>>> forcing the DHCP server address change. 
>>> 
>>> 
>> address is used as the DHCP server address, then we only have
>> approach (1), right? We wouldn't need approaches (2) and (3).
> 

Ok.

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

This section talks about DHCP relay co-located with the MAG. I don't
understand why the MAG has to check if the MN is requesting the right
IPv4 home address every time it renews the DHCP lease. Supporting this
is not trivial, as can be seen in the document.

Vijay

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sat, 25 Oct 2008 08:56:07 +0900

Hi Vijay,

> address for all mobile nodes that get an IPv4 home address from that

This is your expectation. OPerator can have different IPv4 default  
router's address per MN.
We can mention that if operator uses the same default router's  
address, they can use this address as a virtual DHCP address.

> the existing text is saying, a multi-homed mobile node should not use

OK, this is term issue. We will accurate the multi-homed MN part.
We assume the case that MN want the same HNP across two interfaces.

> is not trivial, as can be seen in the document.

Which DHCP entity will verify the assigned IP address at RENEW?
I don't think DHCP server will contact to LMA to confirm the address  
assignment.
MAG (DHCP-relay) should handle confirmation of assigned address by  
using PBU/PBA.

If we skip this verification completely, we might face the conflicts  
of address assignment
between DHCP server and LMA.

regards,
ryuji

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 24 Oct 2008 20:21:34 -0400

Ryuji Wakikawa wrote:

>>>> "virtual DHCP address" is also mentioned in section 3.4.2 (page
>>>> 28). Am I missing something?
>>> 
>> certain IPv4 prefix, I expect the MAG to use the same default router
>> IP address for all mobile nodes that get an IPv4 home address from
>> that prefix.
> 

Why would *anyone* do this? What are you basing this statement on? It
makes no sense for the MAG to pick a different default router address
for each mobile node. There would one default router address for the MAG
per IPv4 prefix.

> We can mention that if operator uses the
> same default router's address, they can use this address as a virtual
> DHCP address. 

Not "can". We have to use at least "SHOULD".

>>>> 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 even without the "Agent Remote ID
>>>> Sub-option"? Am I missing something again?
>>> 
>>> 
>>> The IPv4 address pool is managed by LMA. DHCP is just doing
>>> signaling to assign the LMA assigned address to MN. Therefore, MAG
>>> should check the address status with LMA at the RENEW stage.
>> 
>> IPv4 home address every time it renews the DHCP lease. Supporting
>> this is not trivial, as can be seen in the document.
> 
> assignment. MAG (DHCP-relay) should handle confirmation of assigned
> address by using PBU/PBA. 
> 
> of address assignment between DHCP server and LMA.

There shouldn't be a conflict. The DHCP server would assign the same
address it assigned before. Not a new one. During the initial attach,
the LMA, the MAG and the DHCP server allocate *one* IPv4 home address
for the mobile node. Every time the mobile node does a renew with the
DHCP server, the DHCP server would be giving the same address back. If
the mobile wants a new IPv4 home address, it obviously has to go through
the attach procedure again. Otherwise it won't get mobility support for
the new IPv4 home address. The LMA and the MAG would not be aware of the
address. 

The "verification step" comes at a cost - MAG either going into a
promiscuous mode to look at DHCP packets or implement yet another
extension, RFC 5107. You have to justify why this verification step at
the MAG is required.

Ideally, 

Vijay

---

From: "Premec, Domagoj" <[email-masked]>
Date: Mon, 27 Oct 2008 17:03:21 +0100

Hi Vijay, Ryuji,

A note related to the comment on multihoming and handover across interfaces...

> Right. A multi-homed mobile node could use the hardware 
> addresses for each of the interfaces and get a different HNP 
> for each interface. If the mobile node wants the same 
> address/HNP across two interfaces, then it should use a 
> "stable client identifier" as described above. Instead, the 
> existing text is saying, a multi-homed mobile node should not 
> use the hardware address.

I don't think that this document should state anything about handovers across interfaces. This will affect the MAG and the LMA and we haven't even started this discussion for the v6 case, so going into the details of how this might work in a v4 case seems premature. IMO this document is not the right place to talk about handovers across interfaces. 

domagoj

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 27 Oct 2008 09:22:52 -0700 (PDT)

Hi Domagoj,

> I don't think that this document should state anything about handovers across interfaces. This will affect the MAG and the LMA and we haven't even started this discussion for the v6 case, so going…

The support for handoff between interfaces exists in the base Proxy
Mobile IPv6 specification. It allows the mobile to perform an handoff
of an IPv6 session between two interfaces. Now, if the same interface
has IPv4 address as well, we have to explain how that works. Vijay's
was suggesting a slight rewording on the text related to the use
of client-id for DHCP based address configuration. If the hardware-id
is used, that coupling prevents the handoff (HI=2) and the session
will break and hence the comment on the use of stable id for DHCP
address binding. So, we have to cover this point.

Regards
Sri

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 27 Oct 2008 12:48:04 -0400

Hello,
 
> > I don't think that this document should state anything 
> about handovers across interfaces. This will affect the MAG 
> and the LMA and we haven't even started this discussion for 
> the v6 case, so going into the details of how this might work 
> in a v4 case seems premature. IMO this document is not the 
> right place to talk about handovers across interfaces.
> >
> 

I agree with Sri. The IPv4 support document should say what the mobile
node needs to do so that it gets the same IPv4 address using DHCP when
there is a handover across interfaces. RFC 5213, after all, does cover
handover across interfaces.

Vijay

---

From: "Premec, Domagoj" <[email-masked]>
Date: Mon, 27 Oct 2008 18:29:48 +0100

> I agree with Sri. The IPv4 support document should say what 
> the mobile node needs to do so that it gets the same IPv4 
> address using DHCP when there is a handover across 
> interfaces.

Could it also use the Requested IP Address option to indicate the address it wants?

> RFC 5213, after all, does cover handover across 
> interfaces.

hmm... I agree that it provides some parts of the solution, but I don't think that this is enough. I guess we have different opinions here. I hope there will be an additional RFC that describes how handovers across interfaces work in the netlmm domain.

domagoj

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: 27. listopad 2008 17:48
> To: Sri Gundavelli; Premec, Domagoj
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [netlmm] Comments on DHCP sectionin 
> draft-ietf-netlmm-pmip6-ipv4-support
> 
> Hello,
>  
> addresses 
> > >> for each of the interfaces and get a different HNP for each 
> > >> interface. If the mobile node wants the same address/HNP 
> across two 
> > >> interfaces, then it should use a "stable client identifier" as 
> > >> described above. Instead, the existing text is saying, a 
> > >> multi-homed mobile node should not use the hardware address.
> > >
> > about handovers across interfaces. This will affect the MAG and the 
> > LMA and we haven't even started this discussion for the v6 case, so 
> > going into the details of how this might work in a v4 case seems 
> > premature. IMO this document is not the right place to talk about 
> > handovers across interfaces.
> > >
> > 
> > was suggesting a slight rewording on the text related to the use of 
> > client-id for DHCP based address configuration. If the 
> hardware-id is 
> > used, that coupling prevents the handoff (HI=2) and the 
> session will 
> > break and hence the comment on the use of stable id for 
> DHCP address 
> > binding. So, we have to cover this point.
> 
> I agree with Sri. The IPv4 support document should say what 
> the mobile node needs to do so that it gets the same IPv4 
> address using DHCP when there is a handover across 
> interfaces. RFC 5213, after all, does cover handover across 
> interfaces.
> 
> Vijay
>

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 27 Oct 2008 13:32:35 -0400

Hi Domagoj, 

> hmm... I agree that it provides some parts of the solution, 
> but I don't think that this is enough. I guess we have 
> different opinions here. I hope there will be an additional 
> RFC that describes how handovers across interfaces work in 
> the netlmm domain.

It was proposed during NETLMM charter. NETEXT might work on it.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 27 Oct 2008 12:42:45 -0700 (PDT)

Hi Domagoj,

On Mon, 27 Oct 2008, Premec, Domagoj wrote:

>> address
using DHCP when there is a handover across
> Could it also use the Requested IP Address option to indicate the address it wants?

That wont be sufficient, the DHCP server will look at them as two
different bindings and will not preempt the other binding associated
with the hardware id of the prev interface, even if the Requested IP
Address option is present. So, choosing a stable id which is not
interface specific will help.

Regards
Sri

---

From: "Premec, Domagoj" <[email-masked]>
Date: Mon, 27 Oct 2008 21:21:04 +0100

Hi Sri,

well... the stable client identifier identifes the host, but it doesn't say if that host would like to be multihomed (two different IP addresses) or if it would like to perform the handover across interfaces (one IP address). One way to address this would be to use the Client identifer to identfiy the host, and then additionaly to look at the Requested IP address option. If that option is present and if it contains the address that the host is already using (possibly on its other interface), then that same address should be assigned to the host. If the Requested IP address option is not present (or contains a different IP address), then a different IP address should be assigned to host. Would that work?

domagoj

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: 27. listopad 2008 20:43
> To: Premec, Domagoj
> Cc: Vijay Devarapalli; [email-masked]; 
> [email-masked]; [email-masked]
> >> I agree with Sri. The IPv4 support document should say what the 
> >> mobile node needs to do so that it gets the same IPv4 address
> That wont be sufficient, the DHCP server will look at them as 
> two different bindings and will not preempt the other binding 
> associated with the hardware id of the prev interface, even 
> if the Requested IP Address option is present. So, choosing a 
> stable id which is not interface specific will help.
> 
> 
> Regards
> Sri
> 
>

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 27 Oct 2008 13:44:17 -0700 (PDT)

Hi Domagoj,

> well... the stable client identifier identifes the host, but it doesn't say if that host would like to be multihomed (two different IP addresses) or if it would like to perform the handover across…

Confirming to 2131 or related extensions, the choice of the client
identifier is based on the following:

1.) When there is virtual interface support on the host, abstracting
multiple physical interfaces, use an identifier which is neutral and
non-interface specific. This is the ONLY requirement and thats all we
tried to capture and nothing specific to this protocol.

2.) For all other cases, where the inter-tech handoff is not allowed,
a hardware id which is interface specific is sufficient. No issue
there.

This will allow multi-homed hosts with no inter-tech handoff support
and as well other normal multi-homed hosts, to obtain IP address for
the interfaces as desired.

Regards
Sri

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 28 Oct 2008 21:59:59 -0800

Folks,

WiMAX supports both DHCP Relay and DHCP proxy model for PMIPv4.
Both will be supported for PMIPv6 as well.
And yes, WiMAX has decided to adopt PMIP6, in fact long time ago, and
currently working on writing the specs.
Unless there is a major technical issue, leaving out the DHCP proxy model
for PMIP6 is not a good idea.

Alper