Subject: [mobile-ip] Mipv6 issue #158: When to start RO

From: Jari Arkko <[email-masked]>
Date: Tue, 26 Nov 2002 23:02:49 +0200

Based on the discussions in Atlanta and some private discussions, I'm
proposing the following as a solution to this issue.

The basic problem in this issue is that there are situations where
starting RR/RO has been specified as a SHOULD, which was seen as
too strong.

In order to fix this I believe we need to do the following:

1) In paragraph 7 of Section 11.7.2, we talk about the timing
    of RO/RR with respect to the home registrations. Here we
    should clarify that the SHOULD relates ONLY to existing
    bindings. I think we are already saying this but let's
    make it more clear. And we need to allow either a re-registration
    or de-registration as a result.

2) In paragraph 9 we talk about what to do if we see a packet
    from someone who apparently has no binding for us. A MAY
    is more appropriate here than a SHOULD.

3) Add a note describing that further experience will show
    more data exactly when RR/RO initiation is useful.

I'm working on text for the above. Is this all?

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 27 Nov 2002 13:10:55 +0200

Text proposal, a new beginning for the Section 11.7.2:

When the mobile node is assured that its home address is valid, it can
initiate a correspondent binding procedure with the purpose of
allowing the correspondent node to cache the mobile node's current
care-of address. This procedure consists of the return routability
procedure followed by a binding procedure.

This section defines when to initiate the correspondent binding
procedure, and rules to follow when performing it.

After the mobile node has sent a Binding Update to its home agent to
register a new primary care-of address (as described in Section ...),
the mobile node SHOULD initiate a correspondent binding procedure for
each node that already appears in the mobile node's Binding Update
List. This is necessary in order to ensure that correspondent nodes do
not have invalid information about the current location of the mobile
node. The initiated procedures can be used to either update or delete
binding information in the correspondent node.

For nodes that do not appear in the mobile node's Binding Update List,
the mobile node MAY initiate a correspondent binding procedure at any
time after sending the Binding Update to its home
agent. Considerations regarding when (and if) to initiate the
procedure depend on the specific movement and traffic patterns of the
mobile node and are outside the scope of this document.

In addition, when a mobile node receives a packet for which the mobile
node can deduce that the original sender of the packet has a stale
Binding Cache entry for the mobile node, the mobile node SHOULD
initiate a correspondent binding procedure. In addition, the mobile
node MAY initiate the procedure in response to receiving a packet that
meets all of the following tests:

- The packet was tunneled using IPv6 encapsulation.

- The Destination Address in the tunnel (outer) IPv6 header is
   equal to any of the mobile node's care-of addresses.

- The Destination Address in the original (inner) IPv6 header
   is equal to one of the mobile node's home addresses.

- The Source Address in the tunnel (outer) IPv6 header differs from
   the Source Address in the original (inner) IPv6 header.

The destination address to which the procedure should be initiated to
in response to receiving a packet meeting all of the above tests is
the Source Address in the original (inner) IPv6 header of the packet.
The home address used in the procedure should be the Destination
Address of the original (inner) packet.

A mobile node MAY also choose to keep its location private from
certain correspondent nodes, and thus need not initiate the
correspondent binding procedure.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 27 Nov 2002 11:53:16 -0800

Hello Jari,

I believe that it is a bit troublesome to demote route
optimization to MAY.  I believe it SHOULD be SHOULD, for
the following reasons.

1) It typically helps for almost all communications
   patterns.

2) "MAY" tends to demand a reason, when in fact the opposite
   is indicated by (1).

3) We need to get implementations doing the right thing
   as soon as possible, and this language could delay that.

4) It's easier in the kernel to just do it all the time or
   none of the time, and doing it all the time is going to
   almost never be harmful, whereas doing it none of the time
   is going to be harmful very often.

Your text:

>             Considerations regarding when (and if) to initiate the

applies equally well (speaking purely logically) whether or not
initating route optimization is a SHOULD or a MAY.  Maybe it would
be clearer if it were reformulated to say:

>         Considerations regarding when (and if) to defer or inhibit the

However, we can make definite statements about the probability that
a direct path is better than a bent path, and from the standpoint of
the routing topology the direct path is almost always better.

Regards,
Charlie P.

---

From: "Ed Remmell" <[email-masked]>
Date: Wed, 27 Nov 2002 13:45:25 -0700

Charlie -

That's a reasonable suggestion, I agree with changing the MAY to a SHOULD to
encourage the use of RO.

Thanks.
- Ed Remmell
Elmic Systems, USA

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Charles E.
> Perkins
> Sent: Wednesday, November 27, 2002 12:53 PM
> To: [email-masked]
> Cc: Mobile IPv6 mailling list; Thomas Narten
> Subject: Re: [mobile-ip] Mipv6 issue #158: When to start RO
>
>
> Hello Jari,
>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 27 Nov 2002 21:56:32 +0200

Hi Charlie. Let me just first state what I stated to someone else
privately as well: route optimization support is and stays a SHOULD for
CNs and a MUST for MNs (see reqs section). We have also stated that if
you know you have a binding or realize that a CN has a stale binding,
then starting RO immediately after home registration is a SHOULD. The
question is only about what to do if we don't have an existing binding...
should we start RO immediately or what? In all cases? Or only in some
cases? I guess claim was that we don't currently have enough
information to give the exact rules on when to do it and when
not.

>>mobile node and are outside the scope of this document.

I'm fine with this too.

> the routing topology the direct path is almost always better.

Yes, though there's an initial cost which might mean that I don't
want to initiate RO towards my DNS server, for instance.

Would you be happier if we crafted an additional SHOULD for,
e.g., long term communications but left the exact initiation
time open?

Jari