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

From: Jari Arkko <[email-masked]>
Date: Tue, 01 Apr 2003 09:28:50 +0300

Vijay Devarapalli wrote:

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

Yes. And we have discussed this before. And all the details
or the right way to estabish and check the tunnel would have
to be specified (yes, it could be done but it has not been
done yet). And the special cases would have to be handled.

Considering all this leads to one conclusion: its an
interesting discussion, but pretty academic at this point.
Lets face it, there are multiple possible ways Mobile IPv6
(and other) protocols could be encoded in bits. But we need
one standard way so implementations can talk to each other.
There's no need to switch formats, particularly when they
look pretty equal from the 10,000 ft perspective. [Perhaps
we could work on something interesting, such as a
zero-byte encoding but lets do that later.]

Jari

---

From: [email-masked]
Date: Tue, 1 Apr 2003 12:58:06 +0100

Your correction seems to contradict the statement in Section 5.5
(draft-ietf-mobileip-ipv6-21.txt).

".......Mobile IPv6 introduces the Home Address destination option,
   a routing header, and tunneling headers in the payload packets.  ...."

It reads to me that the HAO and RTH2 are NOT standard   IPv6 extension headers
but rather part of the IPv6 payload packet. So "IPSec-b" in transport mode
should include the HAO and RTH2.

Xiaobao Chen

Orange PCS

Email: [email-masked]

"Keiichi SHIMA / 

島慶一" <[email-masked]> on 01/04/2003 12:12:30

To:   [email-masked]
cc:   [email-masked]
      [email-masked] (bcc: Xiaobao CHEN/EN/HTLUK)

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

Hi,

From: Markku Savela <[email-masked]>

> a) nodes protect the traffic between each other using IPSEC
> b) nodes use IPSEC between care addressess (maybe behind security gateways)
> c) node is at home
> d) node is away from home
>
> and any combinations of above.
>
> Analysing combo a + b + d. With (d) alone the current MIP6 gives
>
> IP: dst=CN-care address
>     src=my-care address
>     RTH2: CN-home address
>     HAO: my-home address
>     <other ext headers>
>     Payload
>
> When adding a + b (on outbound, I run IPSEC both before and after
> MIP6), where should the IPSEC headers go? Seems only way is
>
> IP: dst=CN-care address
>     src=my-care address
>     IPSEC-b
>     RTH2: CN-home address
>     HAO: my-home address
>     IPSEC-a
>     <other ext headers>
>     Payload

No. If you want protect packets using transport mode IPsec between
nodes, the packets look like:

IP: dst=CN-care address
    src=my-care address
    RTH2: CN-home address
    HAO: my-home address
    IPSEC-a
    <other ext headers>
    Payload

IPsec is applied against the below packet:

IP: dst=CN-home address
    src=my-home address
    RTH2: CN-care address
    HAO: my-care address
    <other ext headers>
    Payload

After you have gotten an IPseced packet, you should exchange addresses
(HoA and CoA, CN-home and CN-care).

I'm not sure what kind network you are thinking of.  Maybe the network
graph is helpful for this discussion.

---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
KAME Project <[email-masked]>

*******************************************************************************
Important.
Confidentiality: This communication is intended for the above-named person and
may be confidential and/or legally privileged. Any opinions expressed in this
communication are not necessarily those of the company. If it has come to you
in error you must take no action based on it, nor must you copy or show it to
anyone; please delete/destroy and inform the sender immediately.

Monitoring/Viruses
Orange may monitor all incoming and outgoing emails in line with current
legislation.  Although we have taken steps to ensure that this email and
attachments are free from any virus, we advise that in keeping with good
computing practice the recipient should ensure they are actually virus free.

Orange PCS Limited is a subsidiary of Orange SA and is registered in England No
2178917, with its address at St James Court, Great Park Road, Almondsbury Park,
Bradley Stoke, Bristol BS32 4QJ.
*******************************************************************************

---

From: Mika Liljeberg <[email-masked]>
Date: 01 Apr 2003 23:22:39 +0300

Ed,

On Tue, 2003-04-01 at 00:03, Ed Remmell wrote:
> Ahhh, but here is perhaps a small fly in the ointment:

> 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).

I see the fly.

Our stack architecture is rather different and doesn't represent tunnels
as interfaces, so we don't have this particular problem (not in this
exact form, that is).

>  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.

Yeah, that would be pretty ugly.

I suppose an alternative solution would be to encapsulate the packet at
the point where you currently insert the HAO and/or RTH2 destination
option headers. However, I can see how this would be less attractive
than simply reusing the tunneling code as is.

>  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)?

I think you have it reversed. CN would have the tunnel route keyed with
MNs home address and the ND cache entry keyed with the MNs CoA. However,
MN would have problems, since its tunnel route and the ND cache entry
for the CN would have the same keys.

Actually, there would be a route recursion problem in the MN anyway,
when trying to tunnel towards CN, since the inner and outer destination
addresses would be the same. Bummer.

>  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.

You could probably get around the above problems by extending the route
entry key in some way, but that has its performance implications as
well.

Cheers,

	MikaL