Subject: [netlmm] AD review of draft-ietf-netlmm-pmip6-ipv4-support (part 3)

From: Jari Arkko <[email-masked]>
Date: Sun, 15 Feb 2009 23:13:16 +0200

I am continuing my review, now reading from page 22 to page 30. Please 
see the issues below. I'm CCing Bernard and Ralph as this relates in 
part to issues they raised or are experts in.

> 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 <http://tools.ietf.org/html/rfc3927>] 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.
>   

I'm not sure I understand. If the address is used as a server 
identifier, what implications does the use of the IPv4 proxy care-of 
address imply for a moving mobile node? It sees a server identifier 
change, no? I don't know how that impacts DNAv4 or the ability of the 
mobile node to retain its address.

> Thus, it is
> recommended that the DHCP client on the mobile node, which
> performs mobility session handoff across interfaces in a Proxy
> Mobile IPv6 domain, is configured to use a stable client
> identifier that does not change during the active life of its DHCP
> session.
>   

Three issues with this:

1) Remember that the goal of the proxy mobility protocol is to avoid 
host changes. Indeed, hosts do not have any special support for it 
today, so if we start making requirements then this will cause 
significant problems. E.g., laptops connected to 4G modems might not 
work, etc.

I would phrase the above differently.

When the mobile node uses different interfaces, by default it gets 
different addresses for them, even in a Proxy MIP domain. In some 
configurations it can retain the same address (but see below).

2) What if the DHCP client uses two interfaces _simultaneously_ and has 
the same client id? I hope this does not mean that the PMIP domain 
silently disables the other interface... that would not be allowed. PMIP 
can not break existing functionality.

3) How does all this relate to the complex handoff rules we have in the 
base spec? Perhaps the handoff rules are the ones that should be 
followed, not the client identifier, at least not if current DHCP 
clients can use the same ID on multiple interfaces...

> o  After a successful completion of the Proxy Mobile IPv6 signaling
>    and upon acquiring the mobile node's IPv4 home address from the
>    local mobility anchor, the DHCP server on the mobile access
>    gateway will send a DHCPOFFER message [RFC-2131 <http://tools.ietf.org/html/rfc2131>] to the mobile
>    node.  The offered address will be the mobile node's IPv4 home
>    address, assigned by the local mobility anchor.  The server
>    address, 'siaddr' field of the DHCPOFFER message, will be set to
>    the mobile node's default-router address.  The DHCPOFFER message
>    will be unicasted to the mobile node.
>   

Is the last sentence a new requirement over RFC 2131? I'd start from the 
point of view that there is no new DHCP behaviour, just interactions 
between PMIP and DHCP. And I do not see any problem with the DHCPOFFER 
being treated exactly the same way as RFC 2131 already describes (which 
involves choices between sending to giaddr/ciaddr and broadcast...) 
E.g., what if there's a DHCP relay on the client end?

> Initial IPv4 Home Address Assignment:
>
> o When the mobile node sends a DHCPDISCOVER message [RFC-2131 <http://tools.ietf.org/html/rfc2131>], the
>   DHCP server co-located with the mobile access gateway will trigger
>   the mobile access gateway to complete the Proxy Mobile IPv6
>   signaling.  This is the required interaction between these two
>   protocols.  I
RFC 5213 does not place a strict ordering (or causal?) requirement 
between an RS and the PBU. I do not believe this spec should either. In 
the typical cellular deployment, by the time the mobile node arrives at 
your router, you already know where it came from, who it is, and 
probably also whether it uses IPv4 or IPv6 or both; in any case, after 
attachment you can already ask for the relevant setup from the LMA.

But you already mentioned earlier that the order is significant here 
either, so perhaps you can reformulate the above text a bit.

>    2. The use of FORCERENEW message to notify the address change
>      MN prev-MAG (DHCP-S) new-MAG (DHCP-S)
>   

As was pointed out in the review by Bernard Aboba (posted to the authors 
separately), FORCERENEW requires the use of DHCP authentication, which 
in turn has never been deployed.

I would strike this option from the spec.

By the way, why did you not include option 3, simply letting the client 
figure out that it needs to find a new server? This is fine too as a 
backup, albeit a slow one...

The spec should also at least mention DNAv4 and explain how it works 
with PMIP.

> o  When the mobile access gateway receives a DHCPDISCOVER message
>    from a mobile node, it can check if there is already an assigned
>    IPv4 home address for the mobile node from the local mobility
>    anchor.
This may need more detail on what is a "the mobile node". Identified 
how, by the RFC 5213 means, through the hwaddr in DHCP, through 
client-id in DHCP, or what? And what if these pieces of information 
disagree?

> o  If the Proxy Binding Update message is rejected by the local
>    mobility anchor for any reason, the local mobility anchor will
>    discard the DHCPDISCOVER messages from the mobile node.
>
>   
This text is from the relay case. Interestingly, in the co-located 
server case you had said a different thing. Namely that IPv4 service 
must not be provided. I now realize that the earlier text should have 
been more explicit. Must not provide how? What messages are involved?

Also, is it appropriate to not answer the messages? Would it be better 
to respond with a NAK? Or does that depend on whether the MAG is 
operating as a server or as a relay?

> To achieve this, all the mobile access gateways needs to
> have route towards the DHCP server.
>   

have a route

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

This is problematic, because it would intercept, and incorrectly process 
all DHCP packets, including the ones that are directed to external 
networks, e.g., use of DHCPINFORM.

At the minimum you should require "intercept all IPv4 DHCP packets 
destined to the set of addresses used within the PMIP domain as DHCP 
addresses."

Jari

---

From: Sri Gundavelli <[email-masked]>
Date: Sun, 15 Feb 2009 23:20:43 -0800 (PST)

Hi Jari,

Please see inline.

On Sun, 15 Feb 2009, Jari Arkko wrote:

> I am continuing my review, now reading from page 22 to page 30. Please see 
> the issues below. I'm CCing Bernard and Ralph as this relates in part to 
> issues they raised or are experts in.
>
> I'm not sure I understand. If the address is used as a server identifier, 
> what implications does the use of the IPv4 proxy care-of address imply for a 
> moving mobile node? It sees a server identifier change, no? I don't know how 
> that impacts DNAv4 or the ability of the mobile node to retain its address.
>

We want the mobile node to see the same server id on any link. This can be
an address per 3927, an IPv4 address with non routable properties and one
that can be used by all MAG's. This can also be the default-router
address. We also said, this can be a proxy-coa, assuming there are
mechanism available for the MAG on the new link to update this address.
Probably, to avoid any DNA or other issues as you pointed out, we should
just require it to be a fixed address.

> 1) Remember that the goal of the proxy mobility protocol is to avoid host 
> changes. Indeed, hosts do not have any special support for it today, so if we 
> start making requirements then this will cause significant problems. E.g., 
> laptops connected to 4G modems might not work, etc.
>
> When the mobile node uses different interfaces, by default it gets different 
> addresses for them, even in a Proxy MIP domain. In some configurations it can 
> retain the same address (but see below).
>
> 2) What if the DHCP client uses two interfaces _simultaneously_ and has the 
> same client id? I hope this does not mean that the PMIP domain silently 
> disables the other interface... that would not be allowed. PMIP can not break 
> existing functionality.
>
> 3) How does all this relate to the complex handoff rules we have in the base 
> spec? Perhaps the handoff rules are the ones that should be followed, not the 
> client identifier, at least not if current DHCP clients can use the same ID 
> on multiple interfaces...
>

We want the mobile node to present a fixed identifier to the DHCP server
infrastructure. We do not want the client to present an identifier which
is a link-layer address. For performing inter-tech handoffs, we (PMIP)
system allows address mobility across interfaces and any time the Address
to Interface association changes, we do not want the DHCP server to be
aware of this.

This requirement is not a protocol change, its a simple configuration
setting and all DHCP clients seem to allow the user to specify the
client identifier. This is true for Windows, Mac OS and Linux.

Now, to the specific concern on other scenario, of simultaneous
attachment, what should be the client identifier. The client should
expose a unique and a fixed identifier for each of the bindings.
A given binding when created may have been attached to Interface-1
and later after inter-tech handoff, it may be attached to Interface-2,
but the DHCP server should see a fixed client-id for this binding. So,
just as in today, the DHCP server sees a unique client-id for each
binding, just that we dont want this to be a link-layer id, that will
cause problems, as we allow address mobility across interfaces.

The handoff rules in base spec alone will be sufficient for the PMIP
elements to handle all scenarios. But, when delivering address to
the mobile node using DHCP, we need some unique identifer for each
binding and that can be the client identifier.

>>     gateway will send a DHCPOFFER message [RFC-2131
>>     <http://tools.ietf.org/html/rfc2131>] to the mobile
> point of view that there is no new DHCP behaviour, just interactions between 
> PMIP and DHCP. And I do not see any problem with the DHCPOFFER being treated 
> exactly the same way as RFC 2131 already describes (which involves choices 
> between sending to giaddr/ciaddr and broadcast...) E.g., what if there's a 
> DHCP relay on the client end?
>

Its not a new requirement. This can be just per 2131. Will clarify this.

>>  o When the mobile node sends a DHCPDISCOVER message [RFC-2131
>>  <http://tools.ietf.org/html/rfc2131>], the
> RFC 5213 does not place a strict ordering (or causal?) requirement between an 
> RS and the PBU. I do not believe this spec should either. In the typical 
> cellular deployment, by the time the mobile node arrives at your router, you 
> already know where it came from, who it is, and probably also whether it uses 
> IPv4 or IPv6 or both; in any case, after attachment you can already ask for 
> the relevant setup from the LMA.
>
> But you already mentioned earlier that the order is significant here either, 
> so perhaps you can reformulate the above text a bit.
>

Sure. In 5213, we said, the trigger for the PMIP signaling can be an RS
message, trigger from the network, such as from the prev MAG, or a
network element such as MME. We can state the same here. However, one
concern would be, should we allocate an IPv4 address, when we dont have
an explicit trigger from the mobile node. In any case, we can relax the
language on the strict dependency to DHCP messages, to possibly allow
intelligent triggers from the network.

> separately), FORCERENEW requires the use of DHCP authentication, which in 
> turn has never been deployed.
>

We listed as one of the few approaches. We can remove the reference
if this can be an issue.

> figure out that it needs to find a new server? This is fine too as a backup, 
> albeit a slow one...
>
> The spec should also at least mention DNAv4 and explain how it works with 
> PMIP.
>

Sure. We dont think this should break the DNA optimizations. The MN-AR
link is a p2p link and we try to make the link characterstics to remain
same from L3 perspective, same peers and with the same link-layer and
transport addresses.

> This may need more detail on what is a "the mobile node". Identified how, by 
> the RFC 5213 means, through the hwaddr in DHCP, through client-id in DHCP, or 
> what? And what if these pieces of information disagree?
>

Sure. The PMIP protocol would use the interface id/HoA to identify the
session. But, when this is presented to DHCP, the client id would come
into place. We need to add few lines on that coupling.

> This text is from the relay case. Interestingly, in the co-located server 
> case you had said a different thing. Namely that IPv4 service must not be 
> provided. I now realize that the earlier text should have been more explicit. 
> Must not provide how? What messages are involved?
>

The MAG can tear down the link, or it can drop all IPv4 packets received
from that p2p link.

> Also, is it appropriate to not answer the messages? Would it be better to 
> respond with a NAK? Or does that depend on whether the MAG is operating as a 
> server or as a relay?
>

Sure. Will follow 2131 rules carefully.

>>  have route towards the DHCP server.

Sure

> This is problematic, because it would intercept, and incorrectly process all 
> DHCP packets, including the ones that are directed to external networks, 
> e.g., use of DHCPINFORM.
>
> At the minimum you should require "intercept all IPv4 DHCP packets destined 
> to the set of addresses used within the PMIP domain as DHCP addresses."
>

Sure.

Thanks
Sri

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

---

From: Sri Gundavelli <[email-masked]>
Date: Sun, 15 Feb 2009 23:28:51 -0800 (PST)

Hi Bernard,

Thanks for your comments. Please see inline.

On Sun, 15 Feb 2009, Bernard Aboba wrote:

>
>> 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.
>
> A couple of issues with this.  First, IPv4 Link Local addresses
> are not fixed, since this can greatly increase the probability
> of conflict, which is naturally high.  Secondly, these addresses
> are only assigned *after* DHCP has been attempted and has
> failed, and are not used for DHCP protocol communication.
>

The link betweent the mobile node and the mobile access gateways is
a point-to-point link. We are inheriting this requirement from the
base specification, RFC-5213. There are only two nodes on the link,
the MAG and the mobile node, so there should not be any potential
address conflicts between these two nodes, and when using 3927
addresse with non-routable properties.

> DNAv4 only probes the local gateways, not servers.  So use of
> an address as a server identifier shouldn't affect DNAv4.
>

I think so as well. This should not break DNAv4, specially given the link
is a p2p link.

> Existing 4G networks such as WiMAX are already proving quite brittle
> due to their assumptions about host behavior.  So it has often proven
> difficult to adapt to host address acquisition behavior, let alone to
> change it.
>
> We have seen networks which attempt to use the same client id on
> multiple interfaces simultaneously.  The problem is that some
> operating systems can't handle having the same address assigned
> on two interfaces simultaneously.
>

>From PMIP perspective:

- We allow address mobility across interfaces. What is assigned to
Interface-1 may be at Interface-2 at a later point of time, assuming
client knows how to deal with it.

- We allow the mobile to have attachment to the network, via multiple
interfaces and simultaneouslly, or multihoming rather.

For the DHCP server to treat each of the bindings, distinctly, we
require a stable client id, which is not tied to a link-layer.

Regards
Sri

---

From: Jari Arkko <[email-masked]>
Date: Mon, 16 Feb 2009 13:14:35 +0200

Bernard,

> an address as a server identifier shouldn't affect DNAv4. 

Good, so at least that part of my worry goes away.

> on two interfaces simultaneously.  

Right, let alone silently disabling one of them (and risk the host using 
the disabled one).

But have you seen clients use the same client ID on two different 
networks? My read of the client configuration files in the Linux system, 
for instance, indicates that this should be possible... and if the two 
networks do not try to do anything funny (like assign the same address), 
it should all work...

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 16 Feb 2009 14:37:45 +0200

Sri,

>>>    link-local address [RFC-3927 
>>> <http://tools.ietf.org/html/rfc3927>] that
>>>    can be used for the DHCP

It _may_ also work with different addresses; all I am saying is that you 
need to do the work to find out if there are any problems. Bernard's 
mail seems to indicate that DNA is not a problem.

>> 2) What if the DHCP client uses two interfaces _simultaneously_ and 
>> has the same client id? I hope this does not mean that the PMIP 
>> domain silently disables the other interface... that would not be 
>> allowed. PMIP can not break existing functionality.
>>
>> 3) How does all this relate to the complex handoff rules we have in 
>> the base spec? Perhaps the handoff rules are the ones that should be 

I understand that you are modifying just configs, not code. 
Nevertheless, such changes are still requirements on hosts that may or 
may not be realistic in all situations.

But here's my fundamental problem: RFC 5213 works for IPv6 hosts without 
any client identifiers from the host. The network uses L2 and 
authentication information to identify clients. With some network & L2 
support for handovers, you can even support some inter-access handover 
cases. Why is IPv4 different?

>> Is the last sentence a new requirement over RFC 2131? I'd start from 
>> the point of view that there is no new DHCP behaviour, just 
>> interactions between PMIP and DHCP. And I do not see any problem with 
>> the DHCPOFFER being treated exactly the same way as RFC 2131 already 
>> describes (which involves choices between sending to giaddr/ciaddr 
>> and broadcast...) E.g., what if there's a DHCP relay on the client end?
>>
>

OK, good.

>> between an RS and the PBU. I do not believe this spec should either. 
>> In the typical cellular deployment, by the time the mobile node 
>> arrives at your router, you already know where it came from, who it 
>> is, and probably also whether it uses IPv4 or IPv6 or both; in any 
>> case, after attachment you can already ask for the relevant setup 
>> from the LMA.
>>
> network element such as MME. We can state the same here.

OK

> However, one
> an explicit trigger from the mobile node.

In terms of possibly burning an IPv4 address unnecessarily? I'd say that 
we won't see IPv6-only clients except for special APNs (IMS, perhaps) 
for quite some time. And you'll get an RFC 1918 address anyway, so I 
wouldn't worry too much about this.

> In any case, we can relax the
>> As was pointed out in the review by Bernard Aboba (posted to the 
>> authors separately), FORCERENEW requires the use of DHCP 
>> authentication, which in turn has never been deployed.
>>

OK

>> By the way, why did you not include option 3, simply letting the 
>> client figure out that it needs to find a new server? This is fine 
>> too as a backup, albeit a slow one...
>>
> Sure. We dont think this should break the DNA optimizations. 

Good. Bernards seems to think so too.

> The MN-AR

I think this is the fundamental issue that I had above; lets solve that 
first (how you identify IPv4 nodes and why do you need anything new 
beyond RFC 5213).

>> Also, is it appropriate to not answer the messages? Would it be 
>> better to respond with a NAK? Or does that depend on whether the MAG 
>> is operating as a server or as a relay?
>>
>

OK

But note that I'm not suggesting any specific action; not sure what the 
right thing to do is. But I want you to be consistent and complete in 
the spec.

>> This is problematic, because it would intercept, and incorrectly 
>> process all DHCP packets, including the ones that are directed to 
>> external networks, e.g., use of DHCPINFORM.
>>
OK

Jari

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 15 Feb 2009 22:27:49 -0800

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 16 Feb 2009 03:49:41 -0800

> same from L3 perspective, same peers and with the same link-layer and

As long as the gateway address is routable (e.g. not in 169.254/16) this should work. 
Remember that not all clients even carry a route for 169.254/16 unless they themselves
have a 169.254/16 address.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 16 Feb 2009 04:01:33 -0800

> addresses with non-routable properties.

169.254/16 addresses are *not* randomly chosen, so the probability
of a conflict could be 100 percent for a given node (e.g. the algorithm
used could lead the host to always choose a given 169.254/16
address). From RFC 3927, Section 2.1:

   The pseudo-random number generation algorithm MUST be chosen so that
   different hosts do not generate the same sequence of numbers.  If the
   host has access to persistent information that is different for each
   host, such as its IEEE 802 MAC address, then the pseudo-random number
   generator SHOULD be seeded using a value derived from this
   information.  This means that even without using any other persistent
   storage, a host will usually select the same IPv4 Link-Local address
   each time it is booted, which can be convenient for debugging and
   other operational reasons.  Seeding the pseudo-random number
   generator using the real-time clock or any other information which is
   (or may be) identical in every host is NOT suitable for this purpose,
   because a group of hosts that are all powered on at the same time
   might then all generate the same sequence, resulting in a never-
   ending series of conflicts as the hosts move in lock-step through
   exactly the same pseudo-random sequence, conflicting on every address
   they probe.

This is why RFC 3927, Section 1.4 advises against against manual configuration:

   Note that addresses in the 169.254/16 prefix SHOULD NOT be configured
   manually or by a DHCP server.  Manual or DHCP configuration may cause
   a host to use an address in the 169.254/16 prefix without following
   the special rules regarding duplicate detection and automatic
   configuration that pertain to addresses in this prefix.

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 16 Feb 2009 09:35:12 -0800 (PST)

Hi Bernard,

> address). From RFC 3927, Section 2.1:

Ok. Thanks for this information. Should we use RFC-1918 addresses instead,
(192.168 block). These restrictions on manual configuration does not
appear to be there and most CPE devices are shipped with the pre
configured addresses from this block. We just need a non-routable address
for the server-id.

Regards
Sri

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 17 Feb 2009 03:33:10 +0900

Hi Jari,

On 2009/02/16, at 21:37, Jari Arkko wrote:
>>> 1) Remember that the goal of the proxy mobility protocol is to  
>>> avoid host changes. Indeed, hosts do not have any special support  
>>> for it today, so if we start making requirements then this will  
>>> cause significant problems. E.g., laptops connected to 4G modems  
>>> might not work, etc.
>>>
>>> 2) What if the DHCP client uses two interfaces _simultaneously_  
>>> and has the same client id? I hope this does not mean that the  
>>> PMIP domain silently disables the other interface... that would  
>>> not be allowed. PMIP can not break existing functionality.
>>>
>>> 3) How does all this relate to the complex handoff rules we have  
>>> in the base spec? Perhaps the handoff rules are the ones that  
>>> should be followed, not the client identifier, at least not if  
>>> current DHCP clients can use the same ID on multiple interfaces...
>>>
>>
> Nevertheless, such changes are still requirements on hosts that may  
> or may not be realistic in all situations.
>
> But here's my fundamental problem: RFC 5213 works for IPv6 hosts  
> without any client identifiers from the host. The network uses L2  
> and authentication information to identify clients. With some  
> network & L2 support for handovers, you can even support some inter- 
> access handover cases. Why is IPv4 different?

I'm not sure network uses L2 and authentication info for client  
identification.

RFC5213 said
o Once the mobile node obtains address(es), moves to a different link,  
and sends a DHCP request (at any time) for extending the DHCP lease,  
the DHCP relay agent on the new link will set the link-address field  
in the DHCP Relay Forward message to one of the mobile node's home  
network prefixes. The DHCP server will       identify the client from  
the Client-DUID option and will identify the link from the link- 
address option present in the request and will allocate the same  
address(es) as before.

If we follow RFC5213, we should use DUID specified in RFC4361.

regards,
ryuji

---

From: Jari Arkko <[email-masked]>
Date: Mon, 16 Feb 2009 20:45:38 +0200

Ryuji,

> the Client-DUID option and will identify the link from the 
> link-address option present in the request and will allocate the same 
> address(es) as before.
>

I had forgotten about that. Still, my question is: why does DHCP-based 
allocation require a new client identifier, when stateless 
autoconfiguration can do without?

Jari

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 17 Feb 2009 04:06:15 +0900

Jari,

On 2009/02/17, at 3:45, Jari Arkko wrote:

>> o Once the mobile node obtains address(es), moves to a different  
>> link, and sends a DHCP request (at any time) for extending the DHCP  
>> lease, the DHCP relay agent on the new link will set the link- 
>> address field in the DHCP Relay Forward message to one of the  
>> mobile node's home network prefixes. The DHCP server will        
>> identify the client from the Client-DUID option and will identify  
>> the link from the link-address option present in the request and  
>> will allocate the same address(es) as before.
>>
> I had forgotten about that. Still, my question is: why does DHCP- 
> based allocation require a new client identifier, when stateless  

DHCP requires client ID. If we can modify DHCP server, we may have  
more options. But, AFAIK, this is not our approach.
The stateless autoconfiguration is local operation (no server exists),  
a client ID is not required.

regards,
ryuji

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 16 Feb 2009 11:27:47 -0800 (PST)

Hi Jari,

On Mon, 16 Feb 2009, Jari Arkko wrote:

> It _may_ also work with different addresses; all I am saying is that you need 
> to do the work to find out if there are any problems. Bernard's mail seems to 
> indicate that DNA is not a problem.
>

Ok. Sure, we will check if this introduces any issues. So far, we did not
see any issues, but will check further.

> I understand that you are modifying just configs, not code. Nevertheless, 
> such changes are still requirements on hosts that may or may not be realistic 
> in all situations.
>

Ok. We can try to avoid this requirement.

> But here's my fundamental problem: RFC 5213 works for IPv6 hosts without any 
> client identifiers from the host. The network uses L2 and authentication 
> information to identify clients. With some network & L2 support for 
> handovers, you can even support some inter-access handover cases. Why is IPv4 
> different?
>

3315 has much richer semantics than 2131. The client DUID option is not
tied to the link-layer. Probably we are requiring just the same, in the
form of a neutral client id. On thinking further, when supporting
inter-tech handoffs, if the client has a virtual interface implementation,
then the identifier that is seen for a given binding can be indeed a
link-layer id of this virtual interface. But, to your larger concern on
stating this requirement, thinking how we can make this work without
requiring this. On a side note, Ryuji has pointed me to 4361, this
seems to have fixed some issues with respect to client id, in 2131/2132
and should help us here.

> In terms of possibly burning an IPv4 address unnecessarily? I'd say that we 
> won't see IPv6-only clients except for special APNs (IMS, perhaps) for quite 
> some time. And you'll get an RFC 1918 address anyway, so I wouldn't worry too 
> much about this.
>

Ok.

> I think this is the fundamental issue that I had above; lets solve that first 
> (how you identify IPv4 nodes and why do you need anything new beyond RFC 
> 5213).
>

This needs to be further explored, per the other thread.

> But note that I'm not suggesting any specific action; not sure what the right 
> thing to do is. But I want you to be consistent and complete in the spec.
>

Sure, will ensure this.

Thanks
Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 16 Feb 2009 18:22:59 -0800

Hello,

> mobile node to retain its address.

I suggest removing the link local address option for the fixed DHCP 
server address. I think we should also remove the option to use the IPv4 
proxy CoA as the DHCP server address. I have suggested this in the past 
many times, just one option to use the default router IP address as the 
DHCP server address is sufficient. The fewer options, the better, IMO.

> significant problems. E.g., laptops connected to 4G modems might not 

Jari, for a PMIPv6 handover across interfaces we already require some 
additional work on the mobile node. The mobile node must be able to 
withdraw the address from one interface and assign the same to the new 
interface during the handover.

Note that for a regular PMIPv6 handover, no host modifications are 
required. Each interface with which the mobile node is attached to the 
PMIPv6 domain, it will get a separate address.

The main applicability for this inter-access technology handovers is 
3GPP-non-3GPP handovers. The requirement to have  the same the client id 
for two interfaces involved in a handover for such a client is 
justified, IMO.

> destined to the set of addresses used within the PMIP domain as DHCP 

This is very difficult to implement on the fast path. I don't think the 
fast path should be made aware of the DHCP addresses in a PMIP domain.

BTW, Jari, we had a long discussion on this earlier. It still has not 
been completely addressed yet. My preference was to remove this 
altogether since it is unnecessary. The MAG should not have to intercept 
any unicast DHCPREQUEST message when the DHCPREQUEST message is sent to 
the server for renewing the address. The authors refused. So as a 
compromise, we have it optional. :)

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 16 Feb 2009 22:42:15 -0800

Bernard Aboba wrote:
> Getting rid of link local addresses in favor of private address space is 
> a good
> idea.  Use of link local addresses could generate a conflict between the 
> DHCP
> server address and a client address, which could be nasty.  Picking a 
> private
> address for the DHCP server, and ensuring that the DHCP server only handed
> out addresses guaranteed not to conflict with its own address would be
> cleaner.

Note that the IPv4 address for the mobile node is allocated by the LMA. 
In the above, we are discussing a scenario where the DHCP server is 
co-located with the MAG.

When the DHCP server is co-located with the LMA with the DHCP relay 
agent functionality on the MAG, the above issue does not arise. A 
handover between MAGs does not result in a change of DHCP server.

Vijay

---

From: Julien Laganier <[email-masked]>
Date: Tue, 17 Feb 2009 23:33:12 +0100

Vijay Devarapalli wrote:
>> Getting rid of link local addresses in favor of private address space 
>> is a good
>> idea.  Use of link local addresses could generate a conflict between 
>> the DHCP

Which is incidentally the single method for DHCPv6 stateful address 
allocation specified by the base PMIPv6 document [RFC5213], i.e. DHCPv6 
relay co-located with MAG and DHCPv6 server co-located with LMA. I still 
do not understand why we are treating the IPv4 case differently...

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 17 Feb 2009 14:43:00 -0800 (PST)

On Tue, 17 Feb 2009, Julien Laganier wrote:

>>  Note that the IPv4 address for the mobile node is allocated by the LMA. In
>>  the above, we are discussing a scenario where the DHCP server is
>>  co-located with the MAG.
>>
>>  When the DHCP server is co-located with the LMA with the DHCP relay agent
>>  functionality on the MAG, the above issue does not arise. A handover
>>  between MAGs does not result in a change of DHCP server.
>
> allocation specified by the base PMIPv6 document [RFC5213], i.e. DHCPv6 relay 
> co-located with MAG and DHCPv6 server co-located with LMA. I still do not 
> understand why we are treating the IPv4 case differently...
>

Which was discussed in the WG and the consensus to support both the
cases was adopted. Sure, this may not be required in 3GPP CT4, but
the need to support both the cases was suggested by many folks. Also
reflected was that protocol definitions should not be too rigid in
deployment models, as where to configure a DHCP server in a IP network,
that choice is for operators.

Sri

---

From: Julien Laganier <[email-masked]>
Date: Wed, 18 Feb 2009 00:00:14 +0100

Sri Gundavelli wrote:
>>> > >  server address. I think we should also remove the option to use 
>>> the >  IPv4
>>> > >  proxy CoA as the DHCP server address. I have suggested this in 
>>> the >  past
>>> > >  many times, just one option to use the default router IP address 
>>> as >  the
>>> > >  Getting rid of link local addresses in favor of private address 
>>> space is >  a good
>>> >  idea.  Use of link local addresses could generate a conflict 
>>> between the >  DHCP
>>> >  server address and a client address, which could be nasty.  
>>> Picking a >  private
>>> >  address for the DHCP server, and ensuring that the DHCP server 
>>> only >  handed
>>> agent
>> allocation specified by the base PMIPv6 document [RFC5213], i.e. 
>> DHCPv6 relay co-located with MAG and DHCPv6 server co-located with 
>> LMA. I still do not understand why we are treating the IPv4 case 
>> differently...
>>
> 

Sri, my statement is entirely unrelated to whatever requirements 3GPP 
CT4 might have; If I'm not mistaken, I posted a message to the mailing 
list of an IETF working group, didn't I?

I was simply saying I still do not understand the choice of supporting 
two modes of stateful address allocation for IPv4 while we support only 
one with  IPv6 (relay in MAG and server in LMA)

As to the point of flexibility, let me observe that in a deployment of 
PMIPv6 offering DHCPv6 stateful address allocation to MNs, as per 
RFC5213 there will be a DHCPv6 relay in the MAG and a DHCPv6 server in 
the LMA. In light of this, the additional flexibility of being able to 
configure a DHCPv4 server in the MAG seems of little value, IMHO.

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 17 Feb 2009 15:13:01 -0800 (PST)

>>  that choice is for operators.

Hi Julien,

> Sri, my statement is entirely unrelated to whatever requirements 3GPP CT4 
> might have; If I'm not mistaken, I posted a message to the mailing list of an 
> IETF working group, didn't I?
>

Fair enough, Yes.

> I was simply saying I still do not understand the choice of supporting two 
> modes of stateful address allocation for IPv4 while we support only one with 
> IPv6 (relay in MAG and server in LMA)
>

This was discussed though. WiMAX has adopted models of collocated
DHCP on the gateway when it comes to IPv4, and many did not want PMIP6
not to be made adoptable. There are differences when we supporting
a protocol for forward looking time frame, with the much more
design choices, vs, supporting a legacy infrastructure.

> As to the point of flexibility, let me observe that in a deployment of PMIPv6 
> offering DHCPv6 stateful address allocation to MNs, as per RFC5213 there will 
> be a DHCPv6 relay in the MAG and a DHCPv6 server in the LMA. In light of 
> this, the additional flexibility of being able to configure a DHCPv4 server 
> in the MAG seems of little value, IMHO.
>

With the choice of auth-configuration in IPv6, the need for DHCP is
minimal, compared to IPv4, thats the only way we deliver the address
to the mobile, not talking about IPCP or IKEv2. So, we have to allow
the basic minimum possible configuration models, given these
considerations. But, I agree with your sentiment in just taking one
single approach, ideally, but at the same time we have to provide
some flexibility given that the given model in question is in place
in some system architectures. Hope this convinces you ..

Sri

---

From: "Soininen, Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 18 Feb 2009 16:35:31 +0200

Hello everybody,

> in some system architectures. Hope this convinces you ..

I think I agree more with Julien. It seems that having this second solution
with the server in MAG creates a load of issues. I think it would be much
easier to have just one method that works out of the box, rather than trying
to hack a solution that clearly has multiple issues. As I think Bernard
already said all systems are fragile enough - we don't have to make them any
more fragile.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 16 Feb 2009 10:46:26 -0800

> configured addresses from this block. We just need a non-routable address

Private addresses (doesn't have to be 192.168) would be a much better choice. 
As an aside, DNAv4 works fine with gateways that have private addresses
(though not with ones that have 169.254/16 addresses).

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 16 Feb 2009 22:30:54 -0800

> DHCP server address is sufficient. The fewer options, the better, IMO.

Getting rid of link local addresses in favor of private address space is a good
idea.  Use of link local addresses could generate a conflict between the DHCP
server address and a client address, which could be nasty.  Picking a private
address for the DHCP server, and ensuring that the DHCP server only handed
out addresses guaranteed not to conflict with its own address would be
cleaner.

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 18 Feb 2009 08:38:33 -0800 (PST)

> out addresses guaranteed not to conflict with its own address would be

Thanks Bernard.

The use of RFC-1918 addresses in place of IPv4 link local addresses is
perfectly fine, as agreed earlier. As the restrictions on static
configuration do not exist and it does not introduce any DNA issues. We
will replace the reference from RFC-3927 to RFC-1918. I assume this
resolves this specific comment.

Regards
Sri