Subject: RE: [mobile-ip] How to handle RoutingHeader Type zero

From: "Pascal Thubert" <[email-masked]>
Date: Mon, 2 Sep 2002 12:53:20 +0200

We considered the same question for Nemo in:

http://www.ietf.org/internet-drafts/draft-thubert-nemo-reverse-routing-header-00
.txt

Since RH type 0 is to be used in the infrastructure and RH type 2 is to be used
within the remote mobile extremity (Mobile node or Mobile Network), we suggested
the following:
"
4.3 Extension Header order

   (...)  If a RH type 0 is present in the packet, then the RH type 2 is
   placed immediately after the RH type 0, and the RH type 0 MUST be
   consumed before the RH type 2.
"

Note that our draft extends RH type 2 to be multihop within the mobile network,
with updated semantics and checkings. I cannot see how the RH type 2 as defined
in MIP could deprecate or replace the RH type 0 since it's not multihop, so I
exclude c and d. Our extension requires specific checkings, and can not
deprecate RH 0 either.

Pascal

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Francis Dupont
Sent: Saturday, August 31, 2002 3:29 PM
To: Jari Arkko
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: [mobile-ip] How to handle RoutingHeader Type zero

   There's an open question, however.

=> no, RFC 2460 stands (RHs are processed in order).

   What does this mean for RH0.
   Possible interpretations:

      (a) Orthogonal. For some other purpose, RH0 may also be used. If
          so, we may need some rules on how RH0 and RH2 work if they
          are applied together, and perhaps also some rules on
          home addresses appeaering in RH0.

      (b) Not at the same time. Forbid RH0 if RH2 appears in the packet.
          If for some obscure reason someone wants to use RH0, then
          the use of RO is not possible at the same time.

      (c) Not by MIPv6 MNs and CNs. Devices supporting MIPv6 CN or MN
          functionality may no longer support RH0 at all.

      (d) Deprecate. Thou shall not use RH0 at all.

   Personally, I think the last one is the really right action but

=> I strongly disagree because we can need RH0 one day. So the proper
action is (a) and Mobile IPv6 has nothing to specify.

   I realize this isn't going to be agreed upon now ;-) Perhaps
   the second option would be the way to go. Other opinions?

=> I can't see a problem with multiple RHs even this case has no
usage today. So let just apply RFC 2460 which gives (a).

Regards

[email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Tue, 03 Sep 2002 13:30:53 +0300

So it looks like we want to pick alternative (a), i.e., that the
RH0 and RH2 are orthogonal and could even appear in the same packet.

Francis argues that this is sufficient, and no special rules
will be needed. I suspected in my e-mail that we might need
some rules, and Pascal described rules he used in Nemo context
for the same problem.

Section 6.4.1 of our document already specifies that RH2 must
be the last RH, i.e., a rule similar to Pascal's rule. As
Francis points out, processing order follows from placement
order.

It appears that the existing rule is necessary, as the
home address verification check is rather meaningless if the
packet is immediately going to be forwarded elsewhere. The
rule seems sufficient, because doing RH2 last avoids opening
up any holes in the MIPv6 processing rules with an additional
RH0.

Ok? If yes, the only text change needed would be to remove the
imprecise language in 9.6:

    ...
    for this address, the sending node SHOULD use a Routing header to
    route the packet to this mobile node (the destination node) by way
    of the care-of address in the binding recorded in that Binding Cache
    entry.  For example, assuming use of a Type 2 Routing header (see
    Section 6.4), if no other use of a Routing header is involved in
    the routing of this packet, the mobile node sets the fields in the
    packet's IPv6 header and Routing header as follows:

=>

    for this address, the sending node SHOULD use a Type 2 Routing header
    to route the packet to this mobile node (the destination node) by way
    of its care-of address. Assuming there are no additional Routing
    headers in this packet beyond those needed by Mobile IPv6, the
    mobile node sets the fields in the packet's IPv6 header and Routing
    header as follows:

Jari