Subject: [MOBILE-IP] IPv6 Mobility draft comments

From: "Alan O'Neill" <[email-masked]>
Date: Fri, 12 May 2000 13:42:41 +0100

Comments on the draft...Apologies if these have been discussed before but
I'm new to the list...

1) CN / MN forwarding path control.

On page 19 it states that 'When a mobile node receives a packet tunneled to
it from its
   home agent, the mobile node assumes that the original sending
   correspondent node has no Binding Cache entry for the mobile node,
   since the correspondent node would otherwise have sent the packet
   directly to the mobile node using a Routing header'

whilst on page 20 it states that  'Since correspondent nodes cache bindings,
it is expected that
   correspondent nodes usually will route packets directly to the mobile
   node's care-of address, so that the home agent is rarely involved
   with packet transmission to the mobile node'

This clearly gives the right for the CN to send to MN-HA whilst the MH
assumes it won't, leading to repeated (but rate limited) sending of BU's to
CN. This seems overly loose to me, and the MH shouldn't be guessing like
this. Would it not be better if the CN sent something like a BR to trigger
BU from MN ?

Given the discussion on the list wrt forwarding control, reverse tunnelling
etc this would also enable CN to indicate it's policy directly, whilst
giving the MN some opportunity to override this policy based on it's
configured policy (from Home operator etc).

I guess the counter argument though is that we will be legitimising hosts
(like large servers etc) that would rather conserve local resources
(Binding, IPSEC and Routing Header processing)than conserve net resources
(they can of course still do this with the existing spec but the tone of the
spec is clearly against this....

2) I couldn't find any specific reference to reverse tunneling support, or
it's reasons for not being included (maybe should be mentioned for
continuity reasons wrt MIP4). We may also given above need to re-install
reverse tunneling support as I strongly agree with Fred's position on
this...

3) Binding cancellation
On page 54  'If the Lifetime specified in the Binding Update is zero OR the
       specified Care-of Address matches the home address for the
       binding, then this is a request to delete the mobile node's
       cached binding.

10.13. Receiving Binding Requests
   Note, however, that the mobile node MAY choose to keep its current
   binding private from the sender of the Binding Request.  In this
   case, the mobile node instead SHOULD returns a Binding Update to the
   sender, in which the Lifetime field is set to zero and the care-of
   address is set to the mobile node's home address.

In the former, either condition is used whilst in the latter both are used.
Should we not be consistent or is there a good reason for this ?

4) HA reselection and discovery
On page 83 'It is possible that when the mobile node needs to send a Binding
   Update to its home agent to register its new primary care-of address,
   as described in Section 10.6, the mobile node may not know the
   address of any router on its home link that can serve as a home agent
   for it.'

Is it worth adding some text to describe how a MH detects that it's present
HA is unreacheable and whether it should then use another HA from it's list
or undertake Home Agent Discovery (or did I miss this text) ?

5)Forwarding Issues when changing CoA

'10.9. Establishing Forwarding from a Previous Care-of Address

   When a mobile node connects to a new link and forms a new care-of
   address, it MAY establish forwarding of packets from a previous
   care-of address to this new care-of address.  To do so, the mobile
   node sends a Binding Update to any home agent on the link on which
   the previous care-of address is located, indicating this previous
   care-of address as the home address for the binding, and giving its
   new care-of address as the binding's care-of address.'

On returning home whilst communicating, we may need to support forwarding
which I think that means that we need new text in 10.19, indicating that
the BU-HA = Previous CoA and Bu-CoA=MN-HA...(Bizarre I know but is it ok ?)

Also, in the case of rapid movement, policy or failed communication with HA,
the MN may still be receiving tunnelled packets when it changes CoA and
therefore won't we end up with multiple encapsulations ? It works but should
it be prevented...

Finally, the section does not mention how this forwarding state is
recommended to be eliminated (time-out or explicit cancel by MN). The latter
would seem better with the lifetime as a fail safe ?

6)Additional text in 10.19
Returning Home section also does not mention that we should send a binding
update to all CN's to
cancel the bindings to the care of address, and return to using the MN-HA.

7) General: Hand-over modes

The 10.9 Forwarding section deals with 'unplanned' hand-over whereby the MH
is now at the new CoA, remembers the old CoA and old HA, and so installs
forwarding. The draft does not however deal with planned hand-over (routed
at old HA as in cellular) which may be useful for the IP fast hand-over
work. In planned hand-over (see EMA draft), the 'system' knows where you are
going and can therefore install the temporary tunnel before you leave and
subsequently lose the link to the HA. Probably out of scope for this draft
(big divergence from model) but worth looking at the cellular equivalent
messaging for comparison.

Alan.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 12 May 2000 08:08:52 -0700

Hello Alan,

>      on page 20 it states that  'Since correspondent nodes cache bindings,
> it is expected that

This means the the correspondent nodes usually have valid bindings
for the mobile node, unless the mobile node wishes otherwise.

> this. Would it not be better if the CN sent something like a BR to trigger

With the interpretation above, the CN is not granted such rights.
Of course, we could not necessarily prevent the CN from abrogating
those rights anyway, but thems the breaks.  I would much prefer to
allow the mobile node to send unsolicited Binding Updates as it
is in the current specification.

> configured policy (from Home operator etc).

I didn't get the part about how CNs were involved with reverse
tunneling.

Furthermore, the mobile node should be able to execute whatever
protocols it wants to execute without getting explicit permission
from the Mobile IPv6 document.  Reverse tunneling in IPv6 does
not have sufficient interaction with Mobile IPv6 to merit inclusion
in that document.  If a node wishes to tunnel, I don't see that
Mobile IPv6 should cause it to ask permission from anyone.

> reverse tunneling support as I strongly agree with Fred's position on

I hope it is obvious from the above that I do not think we need
this.  And, especially, I do not think it has to be resolved before
we go to Proposed Standard.  If you would like to submit another
Internet Draft detailing a reverse tunneling procedure, then that
could be considered as a separate matter.

> the BU-HA = Previous CoA and Bu-CoA=MN-HA...(Bizarre I know but is it ok ?)

I couldn't parse this.  Does it mean that the mobile node should
tell the previous router that it has gone home?  In that case,
I reckon that the previous router still has to tunnel the packet
back to the mobile node, presumably with the tunnel destination
set equal to the home address.

> therefore won't we end up with multiple encapsulations ? It works but should

What is wrong with multiple encapsulations?  Are you suggesting that the
intermediate encapsulator should first decapsulate?  This seems like
it would be a nightmare to specify correctly.  Maybe this would also
be suitable for another draft, or for insertion when the draft goes
from Proposed Standard to Draft Standard.

> would seem better with the lifetime as a fail safe ?

I thought that the mobile node should typically make an explicit
determination to invalidate bindings at the appropriate correspondent
nodes.

> messaging for comparison.

I don't think that this belongs in the current Mobile IPv6 draft.
Furthermore, it is possible that cellular handovers will become
more initiated by the mobile nodes as IPv6 gains wider deployment.

Regards,
Charlie P.

---

From: Vincent Magret <[email-masked]>
Date: Fri, 12 May 2000 10:57:53 -0500

Hello,

I wasn't really following the discussion on mobile Ipv6, so some comments might
have  already been discussed. Anyway, here is one though and some comments

My friday though

I have a question on the mobile home address. Since IPv6 is designed to allow
dynamic address allocation, this means the host are mainly going to use this
feature, except may be in some corporate networks where they still want to
implement the old behavior (i.e. static address). So why should a mobile node have
a static address? It could be a useful feature to allow the mobile node to
discover its home address (at least in my opinion) and this could be done using
ICMP message similar to the one to discover the list of home agents.

comments

In section 10.9

Should we have  a "bullet" stating that the mobile node MAY request the home agent
on the previous link to send an acknowledgment?

In section 10.10

The section describes the behavior of the mobile node when requesting an
acknowledgment to its binding update message. What happens when the maximum number
of message has been sent? Should the mobile node considers itself in the
impossibility to have mobility support and thus should turn down its interface (or
something like that)? Should the mobile node turn down its mobile IP component?
Should the MN try the process again after a certain time?

In section 10.13

It is stated that the mobile node MAY decide to not inform the correspondent of
its current location and "the mobile node instead SHOULD returns a Binding Update
to the sender, in which the Lifetime field is set to zero and the care-of address
is set to the mobile node's home address". The packet will be sent using the
care-of address and the home address destination option to allow the packet to go
through ingress filtering router. Well with such message the correspondent (if its
goal is to learn the current location of the mobile) can learn the current
location by reading the source address of the binding update. I think the mobile
node should not send any response to the sender, and that implies that the sender
can only send a limited number of binding request messages.

Should we limited the number of binding requests? Or is it limited to a single
binding request? (section 8.6)

Section 10.19

ID excerpt : "... when the mobile node detects that its home subnet prefix is
again on-link. The mobile node SHOULD then send a Binding Update to its home
agent..."

Why don't we have a MUST?

Best regards.

Vincent Magret.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 12 May 2000 12:23:43 -0700

Hello Vincent,

> ICMP message similar to the one to discover the list of home agents.

The IPv6 address allocation philosophy seems to me more accurately described
as one of automatically allocated static addresses.  In other words, a node
will configure its address automatically, and keep it a while.

An IPv6 node should have a static address because that is the most
efficient way to establish end-to-end connectivity for applications.
Renumbering events are considered to be pretty rare, certainly not
happening every day unless some administrator is trying to prove a
point or test out some software.

> Should the MN try the process again after a certain time?

Maybe it would be time to do a home agent discovery operation.
I don't think the other questions are much different in spirit
from the question about whether to restart TCP connections that
don't work right the first time.

> can only send a limited number of binding request messages.

You are right that the mobile node should not try to invalidate a
previous binding when it decides that it wants to keep its current
care-of address private.  However, wouldn't that typically mean
that the mobile node didn't send its previous care-of address either?
Why would a mobile node want privacy in some domains, and not in
others?  The answer to this question might well imply a closer
entanglement between physical location and IP addressability than
heretofore has been considered germane to network-layer protocol
design.

If the mobile node has to use the Home Address option to satisfy
ingress filtering, and also use reverse tunneling to shield its
current location, then I guess the tunneling has to have the Home
Address option in the outer encapsulating IP header in order for
the operation to make sense.

> Why don't we have a MUST?

That would be fine with me.

Regards,
Charlie P.

---

From: Vincent Magret <[email-masked]>
Date: Mon, 15 May 2000 09:59:57 -0500

Hello Charles,

I don't want to create a controversial debate, but the concept of mobility on which the
group is working allows the mobile node to node have a home address (RFC 2794,
draft-ietf-mobileip-aaa-key-01.txt). And as you stated it a node acquires an address and
keeps it for while, not indefinitely.

So, why not having a similar feature for IPv6?

Regards,

Vincent.