Subject: [Mip4] RFC3344biz Dynamic HoA bug ?

From: "O'Neill Alan" <[email-masked]>
Date: Wed, 24 Mar 2004 21:03:26 -0500

Wg,

I think I may have discovered a hole / corner case in RFC3344biz, but I
thought a bit of discussion might be beneficial before putting it into the
tracker.

A MN places 0.0.0.0 into the Home Address field of the RREQ to trigger
assignment by the Home Agent. The address allocation lifetime is assumed to
be the MIP binding lifetime because no other information exists, and
permanent allocations are of course not good. However, what then happens when
the MN returns home ?

The MN cancels the binding, and according to the spec ceases to use MIP
signaling. However, if the address lifetime is tied to the binding lifetime
then the MN just lost its address. I assume this might not have been spotted
before because we are mostly focusing on cellular systems where the MN has a
virtual home network, and hence cannot ever get home, but given the scope of
RFC3344 this 'hole', if people concur, needs to be filled. The following
options spring to mind.

a) We define a Home Address Lease Grant (HALG) Extension which is optionally
returned by the HA in addition to the binding lifetime. The extension
specifies an allocation lifetime that is greater than the binding lifetime
(clearly cannot be less, and there is no point using it, if it is equal). A
MN that returns home is then able to cancel its binding, but can maintain the
use of the home address to avoid session disruption. Specifically, one can
imagine the HA adding this extension during that deregistration. Note also
that this separation of binding lifetime from address allocation lifetime
also enables a MN to terminate MIP bindings in a foreign network (ie for
efficiency) yet still maintain the home address at the HA, so that it can
later restart MIP with the same HoA and HA.

b) We might also want to consider defining a Home Address Lease Request
(HALR) Extension, with the MN requesting a lease-time and the HA reducing it
to an acceptable value, with lease termination being signaled by requesting a
zero lease-time (by analogy with binding lifetime processing).

c) The MN could then continue to use MIP to refresh this home address lease
by periodically resending RREQs with binding CoA=HoA and lifetime=0, such
that the HA can then return a new lease. Alternatively, the MN can report,
and then maintain, the home address via DHCP (assuming some HA/DHCP back-end
link), with these two options (and maybe others) being distinguished by flags
in the HALG.

	Now in terms of RFC3344biz progression, as a first alternative we
could minimally add clarification text that states that a MN that has been
dynamically assigned a Home Address via MIP, will explicitly lose that
address when it deregisters. This means that deregistered MNs that return
home cannot maintain sessions, and must then go to DHCP (or whatever) to get
a new address for local connectivity. Whilst non-ideal technically, it at
least lets RFC3344biz progress with clarity. We could then define HALG, HALR
and associated processing in a new document. 

	The second alternative is to remove dynamic home address allocation
from RFC3344biz, and put that into the new doc along with the HALG and HALR
work, so that RFC3344biz does not go forward with the corner case of
returning home.

	The third option is to wrap the HALG, and minimal associated
processing, into RFC3344biz to support the MN returning home, and hence to
fix the corner case. The HALR can then be left to the new doc. 

	The fourth option is of course that I am mistaken about the corner
case and we can all sleep soundly.

Thoughts ?

Alan

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Bjorn Andersson <[email-masked]>
Date: Thu, 25 Mar 2004 09:19:46 +0200

> permanent allocations are of course not good. However, what then happens when

This has been discussed before on this list and I think that this is
really a problem that we should solve before we have n proprietery
solutions. Good that you brought up the discussion again! There
have been at least two drafts that have been addressing this
problem. Without any further digging I found these:
- draft-glass-mobileip-agent-dhcp-proxy
- draft-thuel-mobileip-tt

> RFC3344 this 'hole', if people concur, needs to be filled. The following

I have been focusing on non-cellular systems for a number of years and
come across this problem several times in real deployment scenarios. So
far this can only be solved with proprietery solutions and I really
support standardizing a solution. Something along the lines with your
proposed HALG/HALR sounds reasonable. I think this is the way to go.

  Bjorn

-- 
Bjorn Andersson <[email-masked]>
PGP id 5AFC144B

---

From: Kent Leung <[email-masked]>
Date: Thu, 25 Mar 2004 09:37:27 -0800

Yes, this is a known problem for many years.  :)  In addition, 
draft-mccann-mobileip-sessionid 's
Address Management section attempted to covered this issue as well.

We haven't addressed this since most SP deployments have not had the need to
return to home network.  And for Enterprise environment where DHCP is 
prevalent,
Steve Glass's draft-glass-mobileip-agent-dhcp-proxy made sense.

I agree with Hasse that 3344bis should just state that when MN returns 
home, the dynamically
assigned address needs to remain associated with the MN.  The details to be 
covered in another
draft.

Kent

---

From: "Charles E.Perkins" <[email-masked]>
Date: Thu, 25 Mar 2004 10:43:47 -0800

Hello folks,

Honestly, I do not think there is a specification
issue here for rfc3344bis.

O'Neill Alan wrote:

> signaling.

Check.  This is fine.

>          However, if the address lifetime is tied to the binding lifetime
> then the MN just lost its address.

No, by Mobile IP protocol signaling, the mobile node lost its
care-of address.  The lifetime for the home address should
_never_ be tied to the lifetime of its binding to the care-of
address, and no Mobile IP standards track document ever made
any such correspondence.

If the address allocation makes the correspondence, without
additional protocol (not Mobile IP), then the address allocation
system has a bug.

> returned by the HA in addition to the binding lifetime.
                       .......
> zero lease-time (by analogy with binding lifetime processing).

I think it is a mistake to undertake these matters as part
of rfc3344bis, because it essentially amounts to bundling
address allocation details into Mobile IP (which is not an
address allocation protocol).

There are too many details, and it is appropriate to do this
as a separate task which can normatively reference the
finalized rfc3344bis document.

> work, so that RFC3344biz does not go forward with the corner case of

As mentioned above, this "corner case" results from a bug in a
program not directly related to Mobile IP, and so I think it is
not needed to change the existing rfc3344bis (<--- note, not 'z').

Regards,
Charlie P.

---

From: Kent Leung <[email-masked]>
Date: Thu, 25 Mar 2004 11:14:12 -0800

Hi Charlie.

The issue is when a mobility binding for an MN is deleted (either lifetime 
expired
or deregistered from foreign/home network), the HA does not have any 
information
to know if MN still needs to maintain the HoA.

Here are some cases to consider.  For DHCP, as long as the MN knows about
the DHCP server and client ID, it can be responsible to maintain the HoA
after deregistration on home network.  For cases where HA manages the HoA,
such as proxy DHCP client mode, local pool, etc., the protocol used to trigger
address assignment is Mobile IP.  However, when the mobility binding is no
longer needed (which is maintained by registrations), there's a lack of 
signaling
to keep the HoA for MN while it's at home.

This issue came with RFC 2794 when dynamic HoA started.  The mobility binding
and address management is coupled.  The Proxy DHCP draft has some information
to decouple the 2 functions but specific to DHCP.  We can separate the 
functions
provided some address management information is introduced in the 
signaling, which
is basically what the listed drafts and Alan's proposal are based on.

I agree this is not 3344bis specific problem.  But I believe that Mobile IP 
does not
address dynamically-assigned-HoA MN returning home in today's RFCs.

Kent

---

From: "Charles E.Perkins" <[email-masked]>
Date: Thu, 25 Mar 2004 11:31:09 -0800

Hello Kent,

Kent Leung wrote:

> expired or deregistered from foreign/home network), the HA does not have
> any information to know if MN still needs to maintain the HoA.

That information is not part of Mobile IP.  If a mobile node has
a home address, that address is supposed to be routable to the home
network.  If the mobile node has a care-of address, the home
address is still routable to the home network, but the home agent
acts on behalf of the mobile node to deliver the packets.  The
packets are still routable to the home network, one way or the
other.  De-registering the care-of address does not change the
fact that the home address is still routable to the home network,
unless there is a bug somewhere.   (***)

>           ............      For DHCP, as long as the MN knows about
> address assignment is Mobile IP.

How one uses the internal signaling flow related to Mobile IP
is not a priori a matter that has to be worked out as part
of the Mobile IP specification.  For instance, when a node
gets a care-of address, it might want to make some user
interface changes (I don't know why!).  We can't specify
all of those contingencies in the Mobile IP document.

>                           However, when the mobility binding is no
> signaling to keep the HoA for MN while it's at home.

That's not a Mobile IP problem.  I refer back to my previous
paragraph (***).
 
> is basically what the listed drafts and Alan's proposal are based on.

It is fine for the other drafts to make proposals, and for the
problem discussion to proceed.  However, I hope to point out that
the problem discussion has not identified a Mobile IP problem.

> I agree this is not 3344bis specific problem.

Thanks!

> But I believe that Mobile IP does not

rfc3344bis does not solve all problems related to dynamic
address assignment -- and specifically, not all problems
related to dynamic address assignment of home addresses.

There are related efforts, using AAA I believe, to work
out some more of the details.  As one example, if one has
a dynamically allocated address, and a security engine
that depends upon the value of one's IP address, then
there is work needed to get the security engine started.

All of these things can be neatly solved in ways that should
be external to rfc3344bis.  The solutions can normatively
reference the result of rfc3344bis document develop.

Regards,
Charlie P.

---

From: Kent Leung <[email-masked]>
Date: Thu, 25 Mar 2004 16:26:40 -0800

Hi Charlie.  The home address is still routable to the home network.  That
is not the problem.  It's _who_ is actually receiving the packet, as the home
address may be relinquished and assigned to another MN.  It's not typical
that the home address is assigned to the same MN infinitely.

I think we're in agreement that 3344bis does not solve dynamic home
address assignment.  The solution should be addressed in other RFCs.
But what started this thread was reference in 3344bis on dynamic
home address assignment and that returning home is a gap (as I
said in RFC 2794).

I assume this text is the culprit?

>    If the mobile node is not configured with a home address, it MAY use
>    the Mobile Node NAI extension [6] to identify itself, and set the
>    Home Address field of the Registration Request to 0.0.0.0.  In this
>    case, the mobile node MUST be able to assign its home address after
>    extracting this information from the Registration Reply from the home
>    agent.

Kent

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 25 Mar 2004 16:38:36 -0800

Hello Kent,

Kent Leung wrote:

> is not the problem.

Check.

>   It's _who_ is actually receiving the packet, as the home

But, it's not prohibited either, and if additional support mechanisms
are needed for the dynamic case, they can be specified in another
document.  In fact, I reckon there will be more than one way in
use, so there will be multiple documents.

> home address assignment and that returning home is a gap (as I

My participation came in response to a suggestion that the extra
specification should be put into rfc3344bis.  If that doesn't happen,
then I am much happier.

>>    extracting this information from the Registration Reply from the home
This doesn't necessarily imply anything about dynamic allocation,
and it doesn't imply that the address has a lifetime.

Regards,
Charlie P.

---

From: Kent Leung <[email-masked]>
Date: Thu, 25 Mar 2004 18:02:50 -0800

Hi Charlie.

>use, so there will be multiple documents.

It's not, but the problem arises when lifetime of HoA is not infinite,
which is a common case.  We cannot assume that HoA is always
associated with particular MN.

So we're in agreement that there is an outstanding issue with
dynamic HoA in regards to returning home?  And that can be
solved by new drafts or revised old drafts?

My point has been that it doesn't matter which type of address
management scheme is used, we need some more information
in Mobile IP protocol to allow MN to communicate how it wants
to maintain the HoA when at home.  Mobile IP lacks this today.

>specification should be put into rfc3344bis.  If that doesn't happen,

Now looking at RFC 3344, I see only minor reference to dynamic
home address assignment.  Since spec does not describe how this
is accomplished, I don't see value in documenting any flaws or
gaps of a scheme covered elsewhere.  Maybe it may have been
better if base protocol spec did not contain any dynamic home address
assignment reference and let that be completely covered in other
specifications? Purely MHO.

Anyways, given the text today, I would vote for no additional text
in 3344bis.  Just one vote though.  :)  The reason is that we would
be clarifying an issue that's actually in RFC 2794, not specific to
RFC 3344.

>and it doesn't imply that the address has a lifetime.

I read it as a mechanism to be assigned a home address dynamically.  I was
just pointing out that there are references to dynamic HoA assignment in 
3344bis.
The lifetime issue is what's not addressed in existing dynamic HoA scheme, that
others seek clarifications.

Kent

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 25 Mar 2004 18:28:48 -0800

Hello Kent,

> solved by new drafts or revised old drafts?

I'd rather say that, if the assignment mechanism in rfc3344bis
is used, and the allocation is dynamic, then the method by which
the address lifetimes are communicated to the mobile node
are not specified in rfc3344bis.  But, nothing in rfc3344bis
requires or prevents the address from being statically allocated,
or dynamically allocated, either way.  And, I am convinced that
rfc3344bis is not the correct draft for creating those specifications.

> to maintain the HoA when at home.  Mobile IP lacks this today.

I'd be happy if you would delete "in Mobile IP protocol" in the
above paragraph, and replace the last sentence by:
"Solving this problem is out of scope for rfc3344bis".

Regards,
Charlie P.

---

From: Kent Leung <[email-masked]>
Date: Fri, 26 Mar 2004 10:34:04 -0800

Hi Charlie.

When I said, "Mobile IP protocol", that meant the set of RFCs pertaining
to Mobile IP.  And "3344bis" is specific to the draft.  So I meant what I
said.  :)

Kent

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 26 Mar 2004 11:10:01 -0800

Hello Kent,

Well, I'm not meaning to refute your overall point that
additional lifetime information is needed by the mobile
node when dealing with dynamically allocated addresses.
But, the _subject_ of this thread has to do with
rfc3344bis, and that is a document I am working on.
So, I am being very picky to try to understand what
needs to go into that document, and I really want to
make sure there is not a bug in that document.

Sorry if I wasn't clear about that.

Regards,
Charlie P.

---

From: Kent Leung <[email-masked]>
Date: Fri, 26 Mar 2004 11:34:12 -0800

Hi Charlie.  OK.  I was tackling the general issue from both
Mobile IP and 3344bis perspective and was trying to be clear
from which perspective each statement was about.  Some of
the other discussions were also commenting on their
preferences on work items for 3344bis and in general for WG...

Sorry, if I strayed too far from 3344bis specifics...

Kent

---

From: Hans Sjöstrand <[email-masked]>
Date: Thu, 25 Mar 2004 11:03:53 +0100

Alan,

I do agree that you have spotted a corner case and it's quite possibly 
are a worthwhile area to have a complementary RFC to describe a solution 
to. Also, your proposal sounds like a good starting point for such a draft.

But I would like to add an alternative in terms of RFC3344bis 
progression since I think that this problem is not neccesarily linked 
into what 3344 should describe. The problem is more linked into how the 
HA allocates the home address for the MN. This is outside the scope 3344 
since it may be a multitude of ways that all are deployment specific. 
E.g. DHCP server, WINS server, Radius Server, Active Directory or a 
local address pool, just to mention a some.

It might be beneficial to add a explanatory text in some section that 
clarifies that the HA, in order to maintain the MN sessions in handovers 
to the home network, should allocate an address that the MN will 
maintain also when deregistered in the home network. Of course, the text 
should be written by someone more verbal and with better English than me.

I believe your alternative 1 and 2 are destructive, since they break 
whats already are working out there, namely compliant implementations 
that handle roaming to the home network. Alternative 3 are a bad choice 
since it precludes the proper problem investigation and solution that a 
real draft would address.

My suggested alternative is to do nothing to 3344bis, possibly with some 
explanatory text along the lines with the proposal in the previous section.

Best regards
/// Hasse