mip6 over shim6 (was: Re: shim - mip interaction)

[Shinta Sugimoto <shinta@sfc.wide.ad.jp>]

Hi,

In relation to the discussion on interaction between SHIM6
and MIPv6, let me try to address how should they work cooperatively.
There are mainly two scenarios: SHIM6 runs over MIPv6, and MIPv6
runs over SHIM6.  The former case is well addressed in
draft-bagnulo-shim6-mip-00.txt, in which MIPv6 home address(es) are
treated as locator from SHIM6 perspective.  In the latter case,
it should be possible to run MIPv6 over SHIM6 keeping MIPv6
completely unaware of underlying shim layer.  Let me expand a
little bit more on the latter case:

1. Shimming HA-MN bi-directional tunnel

In order to do this, MN and HA ought to establish SHIM6 context
with ULID pair of MN's CoA and HA's address.  MIPv6 is completely
unaware of the presence of shim layer and it just operates normally.
The packet which appears on the wire should look like below.  The
HA will first demux the shimmed packet based on the associated
context.  Decapsulation of IP-in-IP tunneled packet will follow.

shimmed packet from MN to CN:

	[Outer IPv6 Header]
		src=L(MN), dst=L(HA)
	[SHIM6 Ext Header]
	[Inner IPv6 Header]
		src=MN_HoA, dst=CN
	[Payload]


2a. Shimming RO path between MN and CN

In MIPv6, it is possible for MN and CN to optimize the routing
path between the nodes by utilizing IPv6 extension headers
(Home Address Destination Option and Routing Header Type 2)
specific for MIPv6.  Semantically the route optimized path can
be regarded as a virtual tunnel between the nodes although the
mechanism of delivering IP packet is different in each direction.
ULID pair should be MN's CoA and CN's address.

shimmed packet from MN to CN:

	[IPv6 Header]
		src=L(MN), dst=L(CN)
	[SHIM6 Ext Header]
	[DSTOPT]
		HAO=MN_HoA

shimmed packet from CN to MN:

	[IPv6 Header]
		src=L(CN), dst=L(MN)
	[SHIM6 Ext Header]
	[RTHDR2]
		addr=MN_HoA


2b. Shimming RO path between MN and CN

If the CN happens to be a mobile too (no matter if it is served
by the same HA of the MN), CN and MN may establish RO path
in slightly more complicated way.  In order to avoid confusion
let MN and CN be denoted  as MN0 and MN1, respectively.  Assuming
that MN0 and MN1 mutually established MIPv6 corresponding binding
(MN0 stores binding of MN1, and MN1 stores binding of MN0),
in order to shim RO-path between MN0 and MN1, they need to
establish a SHIM6 context based on ULID pair of their CoAs.

shimmed packet from MN0 to MN1:

	[IPv6 Header]
		src=L(MN0), dst=L(MN1)
	[SHIM6 Ext Header]
	[RTHDR2]
		addr=MN1_HoA
	[DSTOPT]
		HAO=MN0_HoA

Note that packet format provided in above scenarios 2a and 2b
are slightly contradict with what is stated in Section 4.6 of
shim6-proto-04 saying that shim6 extension header should
appear after any routing header.  But RTHDR2 can be treated as
an exceptional case as it is meant to be processed only by the
final destination, IMO.

There are some requirement and issues in above scenarios:

First of all, it should be noted that the above scenarios are
directly related to the work being done in the Monami6 WG.
Duplication of the work should be avoided from IETF perspective,
but at first the mechanism how it (MIPv6 over SHIM6) works
should be clearly understood, IMO.

One requirement in above scenarios is that MIPv6 CoA should be CGA.
Otherwise there would be another security mechanism required to
prevent reflection attacks (as we assume that MN changes CoA
frequently).  In the scenario where SHIM6 runs over MIPv6,
HBA would help to assure legitimate locator update among the
the locator set (=MIPv6 HoAs).  But not in the scenarios described
above.

Besides, I see an issue how the ULID pair can be determined by
SHIM6 who has no knowledge on MIPv6 binding information.  As MN's
local address namely CoA is unpredictable, it may be hard for SHIM6
to determine when and with which address should the ULID pair
context should be established/updated in order to shimming the MIPv6
tunnel.

Any comments ?


Regards,
Shinta