Subject: [mobile-ip] MIPv6 Clarification to Type 0 & 2 Routing Header interop

From: Ville Nuorvala <[email-masked]>
Date: Wed, 15 Jan 2003 17:47:36 +0200 (EET)

Hi all!

Sorry I haven't brought this up earlier, but I think the spec needs to be
clearer on how to handle packets with both types of routing headers.

With the current wording an implementation that followed the spec blindly
would let the type 2 header override the type 0 header and route the packet
directly to the MN's care-of address.

The MN would encounter a type 0 routing header with Segments Left > 0 and
most probably discard it, but might perhaps even reroute it to its home
address through the listed routers to have it finally tunneled back to
itself by its HA.

I assume the correct behaviour is to let the type 0 routing header
deternine the next destination address and insert the care-of address in
its last hop address.

To avoid any confusion I propose this clarification to section 6.4:

6.4 Type 2 Routing Header

   Mobile IPv6 defines a new routing header variant, the type 2 routing
   header, to allow the packet to be routed directly from a
   correspondent to the mobile node's care-of address.  If no type 0
   routing header is present, the mobile node's care-of address is
   inserted into the IPv6 Destination Address field, otherwise it is
   inserted into the last hop address of the type 0 header.  Once the
   packet arrives at the care-of address, the mobile node retrieves its
   home address from the routing header, and this is used as the final
   destination address for the packet.

Regards,
Ville

--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: [email-masked], phone: +358 (0)9 451 5257

---

From: Brian Haley <[email-masked]>
Date: Wed, 15 Jan 2003 11:12:51 -0500

> directly to the MN's care-of address.

I don't think so, see below...

> address through the listed routers to have it finally tunneled back to

I believe it MUST discard it if it's not acting as a router.

>    destination address for the packet.

No, this isn't correct.  Section 6.4.1 in pre-20 says correctly:

  "If both a
   Type 0 and a type 2 routing header are present, the type 2 routing
   header should follow the other routing header."

Otherwise we'll defeat the purpose of Type 2 (Section 6.4):

  "All IPv6 nodes which process this routing header MUST verify that the
   address contained within is the node's own home address in order to
   prevent packets from being forwarded outside the node."

The Type 2 is basically a "reverse home address option".

-Brian

---

From: Vladislav Yasevich <[email-masked]>
Date: Wed, 15 Jan 2003 11:26:58 -0500

Ville

I disagree with your proposed text.  Type 0 Routing header should not
be used for mobility purposes.  That's what Type 2 RH is for.

As far as processing, the headers must be processed in order they
appear in the packet.  So if someone sends a packet

	IPv6 | RH Type 2 | RH Type 0

then a node will apply type 2 first and then Type 0 (but this order
is agains the recomendation of the MIPv6 spec)

> directly to the MN's care-of address.

I really can't see how that would happen.  Can you explain?

-vlad

-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tru64 UNIX - IPv6 Project Lead
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07

---

From: Ville Nuorvala <[email-masked]>
Date: Wed, 15 Jan 2003 19:03:34 +0200 (EET)

> I believe it MUST discard it if it's not acting as a router.

OK, perhaps I didn't phrase myself clearly enough. The thing is, you say
the same thing as I do, even though you might say it more eloquently. A MN
which is not a router will discard the packet (and a MN acting as a router
might reroute it).
> No, this isn't correct.  Section 6.4.1 in pre-20 says correctly:

Are you sure?
>    header should follow the other routing header."
I never proposed you drop the Routing Header 2, you append it as before.

> The Type 2 is basically a "reverse home address option".

The Routing Header Type 2 still works.

Let me show how the type 0 and 2 Routing Headers (should) work together.

CN demands traffic to MN is routed through routers A and B.
MN also has registered its care-of address CoA with CN.

CN sends:
dst: A
RH 0: B, CoA, segments left 2
RH 2: MN, segments left 1

A reroutes:
dst: B
RH 0: A, CoA, segments left 1
RH 2: MN, segments left 1

B reroutes:
dst: CoA
RH 0: A, B, segments left 0
RH 2: MN, segments left 1

MN recieves:
dst: CoA
RH 0: A, B, segments left 0 <- MN ignores this since it is done
RH 2: MN, segments left 1

MN rereceives:
dst: MN
RH 0: A, B, segments left 0
RH 2: CoA, segments left 0

So, what's the problem here?

Ville

---

From: Ville Nuorvala <[email-masked]>
Date: Wed, 15 Jan 2003 19:47:34 +0200 (EET)

> be used for mobility purposes.  That's what Type 2 RH is for.
OK, you could of course leave the the home address in the last hop address
of the RH Type 0, but then all packets would always be routed through the
home network, leading to triangular routing (assuming the CN got the
Destination Address right in the first place):

 CN -> HA -> MN
  A          |
  +----------+

> appear in the packet.  So if someone sends a packet
Yes and that is just the problem!

> 	IPv6 | RH Type 2 | RH Type 0

Who has proposed the RH Type 2 should be place before the RH Type 0?
> is agains the recomendation of the MIPv6 spec)

If someone does this he gets precisely what he deserves!

I already explained to Brian how RH Type 0 and 2 _should_ work, but I
guess I have to explain how they currently work (assuming you blindly
follow the spec):

CN sends:
dst: CoA
RH 0: B, MN, segments left 2 <- unaltered by MIPv6
RH 2: MN, segments left 1

MN recieves:
dst: CoA
RH 0: B, MN, segments left 2 <- MN not rtr, packet dropped, end of story
RH 2: MN, segments left 1       (normal scenario)

MN reroutes:
dst: B
RH 0: CoA, MN, segments left 1
RH 2: MN, segments left 1

B reroutes:
dst: MN
RH 0: CoA, B, segments left 0
RH 2: MN, segments left 1

HA intercepts and tunnels:
dst: CoA

MN receives:
dst: CoA

MN decapsulates:
dst: MN
RH 0: CoA, B, segments left 0
RH 2: MN, segments left 1

MN rereceives
dst: MN
RH 0: CoA, B, segments left 0
RH 2: MN, segments left 0

As a bonus the reply packets also bounce arond nicely if the MN reverses
the RH 0: MN -> B -> MN (CoA) -> CN

I've thought about this quite a bit, so would it have been too much asked
if you and Brian also had sat down and thought it through before
automatically dismissing my idea, at least since you two seem to have
missed my point.

If my wording in my proposed clarification was unclear, then I apologise
and must think of a better one, but I think my examples here have at least
illustrated the problem.

Ville

---

From: Vladislav Yasevich <[email-masked]>
Date: Wed, 15 Jan 2003 14:06:04 -0500

Hi Ville

> guess I have to explain how they currently work (assuming you blindly
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> follow the spec):
^^^^^^^^^^^^^^^^^^^^^

That is the statement that concerns me.  I've just looked at the spec
agains and I can not find any description from which you infer the
reasoning below.  The only stements I found are in Section 9.3.2.
A slight concern is that that description does not state what happens
in the presence of other the RTH Type 2, but the behavior should be the
same, i.e.  its a 2 step process: apply Tepe 2 header, and the apply Type 0.

Can you point me at the sections which the implementation would have to 
"blindly follow".

> RH 2: MN, segments left 1

I think some of the addresses are wrong (you are missing A).

> automatically dismissing my idea, at least since you two seem to have

The thing is, that we've thought about it and implemented it and it works.
In our reading of the draft, we did not see the problem that you discribe.
I appologize if I came across as harsh.

-vlad

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 15 Jan 2003 11:00:54 -0800

> RH 2: CoA, segments left 0

you are right. this is how it is intended to work. a packet from
CN to MN can have both type 0 and type 2 routing headers. the 
requirements are that

1. type 2 must follow type 0
2. when the packet reaches the MN and the seglefts in type 0
   routing header is not 0, then the MN drops the packet.
3. seglefts in type 2 routing header is set to 1 and the address
   in type 2 routing header is one of MN's home addresses. 
   otherwise the packet is dropped.

is this is not clear in the spec? if yes, it should be clarified. 

Vijay

---

From: Brian Haley <[email-masked]>
Date: Wed, 15 Jan 2003 14:09:20 -0500

Hi Ville,

> So, what's the problem here?

That looks correct, although the last step is unnecessary since
you already checked that the address in the Type 2 is one of
your home addresses.  Most implementations optimize this out.

I will describe how the packet will be built on our CN:

(initial packet, dst is MN)
dst: MN
RH 0: A, B
RH 2: COA

(addresses swapped in RH2)
dst: COA
RH 0: A, B
RH 2: MN

(addresses swapped in RH0)
dst: A
RH 0: B, COA
RH 2: MN

(packet transmitted)

It then follows what you show above.  Is it unclear that you should
swap the RH2 address first?  The email you sent to Vlad did not have
this correct.

Packets can take non-optimal routes through the network when a user
specifies strict source routing, that should not be our concern.

> automatically dismissing my idea, at least since you two seem to have

Sorry if we upset you, but we did think about this (separately) before
responding, our interpretation just differs from yours.

-Brian

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 15 Jan 2003 11:11:51 -0800

> RH 2: MN, segments left 1

which part of the MIPv6 spec says you have to construct a
packet like this?

if I take

> MN also has registered its care-of address CoA with CN.

and 

>    otherwise the packet is dropped.

I _would_ construct the following packet at the CN.

CN sends:
dst: A

regards
Vijay

---

From: Ville Nuorvala <[email-masked]>
Date: Wed, 15 Jan 2003 23:08:45 +0200 (EET)

> which part of the MIPv6 spec says you have to construct a
You get it by following the spec if the packet is built starting from the
IPv6 header and ending with the payload data. Linux does this with UDP and
raw sockets. At least in Linux unconnected sockets don't get the source
address before the data is passed to the IP-layer. Thus the UDP-checksum
can't be calculated beforehand. Even if the aforementioned sockets are
were connected the packets are built this way.

In this case you first append the RH 0 then the RH 2.

Then you would first get:

dst: A
RH 0: B, MN, segments left 2

before appending the RH 2, and after that:

dst: CoA
RH 0: B, MN, segments left 2
RH 2: MN, segments left 1

Which is incorrect.

If the packet is built backwards starting from the data ending in the IPv6
header, I guess you would get it right following the current spec. This
method can used by TCP in Linux, since the socket already has both source
and destination addresses set.

This method would give:

dst: CoA

before prepending the RH 0, and after that:

dst: A

Which is correct.

This turned out to be an IPv6 implementation specific problem!
Now I finally understand why we have had such great difficulty
understanding each other. Thanks Vijay!

Good thing we also have interop testing IRL! It's a much easier way to
notice things like this.

> I _would_ construct the following packet at the CN.
We also, and I guess HP the implementation too. Good if everyone got it
right!

> RH 2: MN, segments left 1

But what part of the current spec actually says the CoA is to be placed in
the  RH 0? :)

The only mention of RH 0 is:

"If both a Type 0 and a type 2 routing header are present, the type 2
routing header should follow the other routing header."

Since the order in which an IPv6 packet is built isn't mandated
anywhere AFAIK, we should probably make things as unambiguous as
possible, right?

The whole term of destination address is a bit dodgy if you have two
routing headers that modify it, as its value depends on the order in
which they are added. I would prefer terms like first hop, last hop and
final destination address.

I now realize my original wording of the clarification might have been a
bit confusing to some of you, but am too tired to think of a better one
than the one I sent in reply to Hema.

I do however think the spec should clearly say which address should be
where when the packet is complete, but without mandating in what manner
they get to their right places.

Ville

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 15 Jan 2003 13:36:15 -0800

> We also, and I guess HP the implementation too. Good if everyone got it

good.

> But what part of the current spec actually says the CoA is to be placed in

nowhere. but it is implicit. 

> they get to their right places.

would it be a good idea to include the example we were discussing?

Vijay

---

From: Vladislav Yasevich <[email-masked]>
Date: Wed, 15 Jan 2003 16:35:30 -0500

Hi Ville

> But what part of the current spec actually says the CoA is to be placed in

See beginning of page 68 (in draft 19, Section 9.3.2).  However, it's
limited to situations where only RH type 2 is present.

Maybe is should not be so limited?

-vlad-

---

From: Ville Nuorvala <[email-masked]>
Date: Wed, 15 Jan 2003 23:51:57 +0200 (EET)

Hi Brian and Vlad,

while I was answering Vijays email, I finally understood why we didn't
seem to understand each other. Turns out the result depends on
which order the packets are built up in.

Starting from the IPv6 header things go wrong, ending with the header things
go right!

Linux uses both methods and I was only thinking about the first case.

Since there might be other Operating Systems that behave in a similiar way
or other implementations besides MIPL for Linux, I suggest the spec should
more clearly say which addresses should be where in the final packet.

> your home addresses.  Most implementations optimize this out.
That's true, I'm not sure if MIPL does this or not (too tired/lazy to
check), but I was trying to be as clear as possible there.

> I will describe how the packet will be built on our CN:

Good thing everybody's implementations behave correctly! :)
> swap the RH2 address first?  The email you sent to Vlad did not have

It is in Linux, sometimes. The whole process is better explained in my
reply to Vijay...

> specifies strict source routing, that should not be our concern.
I just showed how for example UDP datagrams would be either dropped or
bounced around the net if a (as it turns out _Linux_) CN followed the spec
_blindly_.

> responding, our interpretation just differs from yours.
I didn't just understand how you didn't see this problem, when it was so
clear to me. :) Sorry if I in my turn upset you guys. It was all just a
big misunderstanding.

Ville

---

From: Ville Nuorvala <[email-masked]>
Date: Thu, 16 Jan 2003 00:45:46 +0200 (EET)

> nowhere. but it is implicit.

And I was just trying to make it explicit.

> would it be a good idea to include the example we were discussing?

It is a bit lengthly, so perhaps not in section 6.4. It would probably
be enough to state that care must be taken if other routing headers
are present and point to section 9.3.2 where the situation could be
explained more thoroughly, as Vlad kinda suggested.

How it exactly should be worded or visualized there is too much for
me at the moment, but I'll try to get back to it in the morning.

Good night,
Ville

---

From: gabriel montenegro <[email-masked]>
Date: Thu, 16 Jan 2003 01:57:13 +0100

Ville Nuorvala wrote:
> are present 

Yes,

> and point to section 9.3.2 where the situation could be

It seems to me that rather than concluding that the result depends
on the order in which one constructs the packet, one can conclude
that there is only one logical order of constructing the packet.
This is the order dictated by the fact that we're doing
successive protocol encapsulations (RH2 encapsulated by RH0).
This order being the inverse of the order in which the packet's
headers are processed at the destination.

So construct RH2 first, then RH0, and decapsulate in the
inverse order. Given that all other implementors got this
right, perhaps it was just an unfortunate confusion and
we don't have to do any change in the draft.

At most, perhaps a reference to "Nested Encapsulation"
in rfc2473 could suffice (I'm trying not to create unnecessary
work for Jari for rev20).

-gabriel

---

From: Ville Nuorvala <[email-masked]>
Date: Thu, 16 Jan 2003 11:42:58 +0200 (EET)

> we don't have to do any change in the draft.
Good if this has been self evident to all other implementors, but
the thing could be made even clearer by changing the sentence in
section 6.4.1:

to

"If both a Type 0 and a type 2 routing header are present, the type 2
routing header should be constructed first and placed after the other
routing header."

This would force the right logical ordering of the headers.

Ville

---

From: gabriel montenegro <[email-masked]>
Date: Thu, 16 Jan 2003 13:11:05 +0100

> This would force the right logical ordering of the headers.

I propose a slightly different (more explicit) wording for this
clarification. I have run this past Ville and he agrees with it:

"If both a type 0 and a type 2 routing header are present,
the type 2 routing header should follow the other routing header.
In such a nested encapsulation the inner (type 2) routing header
is constructed first and then treated as an original packet by
the outer (type 0) routing header construction process."

I'll assume this closes this (unnumbered) issue unless we hear
otherwise.

Remember we will close all remaining issues today at
3pm GMT.

thanks,

-gabriel