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

[marcelo bagnulo braun <[e-mail]>]

Hi Shinta,

El 24/03/2006, a las 15:52, Shinta Sugimoto escribió:

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

yes, but i think that it would make sense to define whether the shim is 
above or below the shim once and for all, so that we figure out how the 
stack is actually ordered, right?

Personally i think that at this point it makes sense to lay shim above 
mip, in order to support the most interesting scenarios.

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

this case is useful indeed.
However, in this particular case, i am not sure that this is strictly 
the case where MIP lays on top of the shim.
I mean, in this case we have tunnel interface, so basically we have the 
IP layer twice. So as i see it, shim can also be twice. The particular 
case that you are considering is when the shim of the IP layer of the 
tunnel interface is working. So it is below the MIP, since the MIP is 
associated to the other IP layer.

We can see it from a different p.o.v. if we consider that it would 
possible in this case to also have a shimed session between the CN and 
the MN, so and additional shim header associated to the upper IP layer 
would be also in place.

So, my point in this case is:
- SHIM is above MIP
- each IP layer may have a shim sublayer within
- in the case of tunneled interfaces, we have two IP layers and for 
each of these IP layers, we can have a shim layer.
- however, in all the cases, inside a given IP layer, shim is always 
above MIP

makes sense?



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

right this could be possible imho, but i am not sure if it would 
provide additional benefits than the case where shim is above mip.
I mean, in this case, you can only provide fault tolerance against 
failures in the currently used CoA. failure in the path with the HoA 
are sill affecting the communication both in the BT mode and the RO 
mode (because of the hoT/HoTI exchange)

So, even if i can see that some additional fault tolerance is achieved, 
i think that the case where shim is above mip provides more benefits...

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

I am not sure why do you think so... MONAMI is chartered to do very 
specific work, in particluar related to multiple CoA registration and 
flow policy
No work is chartered for fault tolerance, failure detection, multiple 
HoA support, which is what is being provided here

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

agree

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

agree
however, there seem to be the underlying assumption that in the case 
that shim is layered above mip, the shim can not be exposed to the 
CoAs. While this make sense, there is not yet defined if this is the 
best alternative. I mean, allowwing the shim to be aware of the coas 
may provide additional benefits, like some form of shim based ro mode

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

I am not sure i understand your point here: are you considering ULID 
selection or locator selection? are you considering the case when a 
node is selecting its owm addresses or when it is selecting the peer's 
addresses?

All these cases are quite different, but there is some support for this 
in RFC3484 (for ULID selection), and the flag field in the Locator 
preference option has a temporary flag to tell the peer that a given 
address is a CoA.
Additional guidance when selection local locators may be required though

Regards, marcelo



> Any comments ?
>
>
> Regards,
> Shinta
>
>