[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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