Subject: [mobile-ip] Why not tunnel instead of RTH2 and HAO?

From: Markku Savela <[email-masked]>
Date: Mon, 31 Mar 2003 18:03:40 +0300

In draft-ietf-mobileip-ipv6-21.txt, chapter 9.3.2 it says that if node
has a binding cache entry for the destination, it uses routing header
type 2.

Additionally, I suppose that it can in such case assume other end has
also binding cache entry, and thus Home Address option is used. So,
the packet would look as

IP: dst=CN-care address
    src=my-care address
    RTH2: CN-home address
    HAO: my-home address
    Payload

Total header size: IP(40) + RTH2(24) + HAO(24) = 88

Now, I'm just wondering, why not just tunnel?

IP: dst=CN-care address
    src=my-care address
IP: CN-home-address
    my-home-address
    Payload

Total header size IP(40) + IP(40) = 80.

Tunneling would be at least 8 bytes shorter overhead? And scrapping
the HAO and RTH2 would make RFC many pages shorter? :-)

Am I missing something (still new on this mobile-IP 6 thingy)?

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 31 Mar 2003 07:53:25 -0800

>From draft 21, 4.1 Basic Operation on the advantages of route optimization:

"Routing packets directly to the mobile node's care-of address allows the
shortest communications path to be used.  It also eliminates congestion at
the mobile node's home agent and home link.  In addition, the impact of any
possible failure of the home agent or networks on the path to or from it is
reduced."

Thanks.
- Ed Remmell
Elmic Systems, USA

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Markku Savela
> Sent: Monday, March 31, 2003 7:04 AM
> To: [email-masked]
> Subject: [mobile-ip] Why not tunnel instead of RTH2 and HAO?
>
>

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 31 Mar 2003 08:52:53 -0800

Oops, sorry - someone else on the list clarified that Markku was not
referring to using the MN-to-HA tunnel, he was suggesting that in this case
the MN tunnel packets directly to the CN w/out using the type 2 routing
header.

> > Now, I'm just wondering, why not just tunnel?

I didn't read it thoroughly, I just read "why not just tunnel" and assumed
he meant using the MN-to-HA tunnel.

I believe this can be reduced to:
1) why does the MN use the HAO when it sends data packets to a CN instead of
just tunneling those packets?

- and -

2) why does the CN use the RTH2 when it sends data packets to a MN instead
of just tunneling those packets?

Thanks.
- Ed Remmell
Elmic Systems, USA

> [mailto:[email-masked]]On Behalf Of Ed Remmell
> Sent: Monday, March 31, 2003 7:53 AM
> To: Markku Savela; [email-masked]
> Subject: RE: [mobile-ip] Why not tunnel instead of RTH2 and HAO?
>
>

---

From: "James Kempf" <[email-masked]>
Date: Mon, 31 Mar 2003 09:18:53 -0800

I believe a solution like this was proposed last year and rejected by the WG
because we were too "close" to having the draft done.

            jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 31 Mar 2003 10:03:29 -0800

> of just tunneling those packets?

right. a constant 16 bytes overhead if a tunnel is used
when the CN is a fixed node.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 31 Mar 2003 10:02:03 -0800

Markku,

you are combining two things.

> Total header size: IP(40) + RTH2(24) + HAO(24) = 88

in this case the CN is also mobile. it is actually a mobile-mobile
communication.

if the CN was fixed and you always had to tunnel, then you will
always have an overhead of 40 bytes for a tunnel against 24
bytes for a routing header or a home address option.

> Now, I'm just wondering, why not just tunnel?

it can be done, but it will be a series of ugly hacks throughout 
the IP stack (in my implementation atleast). Home Address Option
is added when the destination figures in the binding update list.
Routing header is added when the destination figures in the 
binding cache.

> Tunneling would be at least 8 bytes shorter overhead? 

is 8 bytes worth it? it will be a constant 16 bytes overhead if
one of the nodes is a CN.

> Am I missing something (still new on this mobile-IP 6 thingy)?

you are new to mipv6? didnt you implement it 3 years back? :-)

Vijay

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 31 Mar 2003 10:51:03 -0800

> Routing header is added when the destination figures in the

I agree with Vijay, I wouldn’t want the extra complexity. There are some
MIPv6 requirements specific to using the HAO and RTH2 that affect the
implementation, for example:

CN, section 9.3.1 “Receiving Packets with Home Address Option”:
"Packets
   containing a Home Address option MUST be dropped if there is no
   corresponding Binding Cache entry.  A corresponding Binding Cache
   entry MUST have the same home address as appears in the Home Address
   destination option, and the currently registered care-of address MUST
   be equal to the source address of the packet.”
“If the packet is dropped due the above tests, the correspondent node
   MUST send the Binding Error message as described in Section 9.3.3.
   The Status field in this message should be set to 1 (unknown binding
   for Home Address destination option).”

So, these requirements would have to be rewritten to also allow the outer
tunnel header to specify the care-of address, in which case the HAO is not
needed. The CN would still need to do validation that it has an active
binding for that combination of home address and care-of address. This
raises an interesting question: how does the CN know that the tunneled
packet is sent by a MN using route optimization? So, how does the CN know
for sure to validate that there is an active binding in this case? The
inclusion of the HAO makes it obvious that the packet was sent by a MN that
expects the CN to have an active mobility binding for that home address. So,
essentially what you are proposing would circumvent the security provided by
return routability, either that or it would potentially affect other
tunneled packets besides just the ones tunneled by a MN using route
optimization.

Thanks.
- Ed Remmell
Elmic Systems, USA

---

From: Mika Liljeberg <[email-masked]>
Date: 31 Mar 2003 22:53:21 +0300

Hi Ed,

On Mon, 2003-03-31 at 21:51, Ed Remmell wrote:
> binding for that combination of home address and care-of address.

I agree.

>  This
> for sure to validate that there is an active binding in this case?

Any tunnel decapsulator has to do sanity checks on the inner packet
anyway. You could view the binding update + RR check as a tunnel setup
protocol that creates a tunnel endpoint in the CN.

So, assume the src and dst addresses of an incoming packet received by
CN match a tunnel endpoint created by MIPv6. The home address of the
peer is stored as an attribute of the tunnel endpoint. The decapsulation
rules simply check that there is a matching tunnel endpoint, decapsulate
the packet and verify the addresses of the inner packet: the destination
address must be one of the CN's own addresses; the source address must
match the stored Home Address attribute of the tunnel endpoint.

In effect, the configured tunnel endpoint would replace the function of
the binding cache entry.

>  The
> return routability,

I don't think so. Tunnel endpoints must do security checks also.

>  either that or it would potentially affect other

A tunnel endpoint could be defined in a general way as:

- local endpoint address
- peer endpoint address
- selector or address mask identifying the source addresses a peer may
use in the inner header
- selector or address mask identifying the destination addresses a peer
may use in the inner header
- [whatever else you want to check]

The above is completely independent of MIPv6 and could be used to
implement any configured tunnel. Another way of saying this is that
existing tunneling code could be fully reused.

Cheers,

	MikaL

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 31 Mar 2003 12:16:54 -0800

Mika -

> In effect, the configured tunnel endpoint would replace the function of

Well, I must say that I do like this alternative (actually, you still have a
binding cache entry in the CN, but it is implemented as a configured tunnel
in this case - the MN still needs to send a BU to the CN to create that
configured tunnel, and the CN still needs to age it, use it to validate
received packets, etc. - return routability and protection of BUs would not
be affected, however the way the binding cache is implemented on the CN
would be affected and also RTH2 and HAO between the MN and CN would be
replaced by the tunneling mechanism). But, unless it completely replaced the
existing method of RTH2 and HAO, I certainly would not want to have two
different ways to do the same thing (i.e. one using the existing RTH2 and
HAO, the other using the CN configured tunnel). Also, I'd expect it would
take an act of God ;-) to make such a significant and somewhat unnecessary
architectural change to the MIPv6 specification this late in the game.

> existing tunneling code could be fully reused.

Yes, I do like reuse. At the same time, as I said above I certainly would
not want to have two different ways to do the same thing. So, CN configured
tunnel would have to completely replace the current use of RTH2 and HAO to
do route optimization between the MN and CN, otherwise it isn't worth the
extra complexity of having to support two different mechanisms to do the
same thing.

Thanks.
- Ed Remmell
Elmic Systems, USA

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 31 Mar 2003 13:03:44 -0800

Ahhh, but here is perhaps a small fly in the ointment:

Connecthathon: Send ICMPv6 Param Problem and MH BE without BCE lookup
http://www.piuha.net./~jarkko/publications/mipv6/issues/issue274.txt

Also, clarification added per
http://www.piuha.net./~jarkko/publications/mipv6/issues/issue267.txt:
"The Home Test message MUST be sent to the home address of the mobile node
without route optimization, even when there is an existing binding for the
mobile node."

We had originally implemented our CN using a BSD-style routing tree, and we
had the CN add a host tunnel routing entry for the MN with the MN's home
address being the routing tree key (the outgoing interface selected by this
routing lookup was a special MIPv6 CN virtual tunnel interface that wouldn't
really do IPv6 tunneling, but instead would do degenerate tunneling by
adding the RTH2). But then we discovered that there are a number of
exceptions to route optimization (see above - HoT, ICMPv6 Parameter Problem
error message, Binding Error message must not be sent by the CN using route
optimization even if the CN has an active mobility binding for the final
destination). We were considering: well, temporarily remove this special
tunnel routing entry from the routing tree just so we can send this message
w/out route optimization, and then re-add it - that certainly wasn't a clean
solution, we quickly decided against it. Also, there was another scenario
that we couldn't work around: what if the MN just happens to be on the same
link as the CN yet they are using route optimization (in this case, if the
CN tried to directly send to the MN, it would have to do IPv6 Address
Resolution to create a Neighbor Cache entry for the MN, which in our
implementation is also a host routing entry with the same key as the MN's
host tunnel routing entry, so there would be a conflict)? In the end, we
gave up on using host tunnel routing entries for our CN implementation, and
now we just do a separate lookup in the Binding Cache prior to doing the
routing tree lookup when sending a packet. We use a special packet flag to
tell that code to bypass the Binding Cache lookup for these special types of
messages that must bypass route optimization.

Thanks.
- Ed Remmell
Elmic Systems, USA

> Sent: Monday, March 31, 2003 12:17 PM
> To: Mika Liljeberg
> Cc: Vijay Devarapalli; Markku Savela; [email-masked]