[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mip6 over shim6 (was: Re: shim - mip interaction)
Hi Marcelo,
Please find my comments inline. Note that I am not trying to push
MIPv6 over SHIM6, but trying to clarify if it really does make sense
or not :)
On Mon, 27 Mar 2006 13:18:32 +0300
marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:
> Hi Shinta,
>
> El 24/03/2006, a las 15:52, Shinta Sugimoto escribis:
>
> > 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.
I agree that SHIM6 over MIPv6 is certainly an interesting scenario
and its technically feasible. On the other hand, I would also like to
understand what about the case in MIPv6 over SHIM6. When it comes to
feasibility, I understand how it may work. Now I am trying to see
if its really meaningful/useful, but after reading your response
and some exploration, I came to think that SHIM6 over MIPv6 is more
preferable and provides more benefits than the other way around.
> > 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.
Yes. But as the ULID pair does not match in the first try (as the context
database is looked up with ULID<CoA_MN, HA>).
> 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.
Yes.
> 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.
Right.
>
> 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?
Yes, finally.
> > 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.
You are right. The case I described above provides fault tolerance
against failures which may occur between the path (CN and MN's CoA)
in a limited way.
In comparison to the SHIM base RO mode (in case of SHIM6 over MIPv6),
the problem is that application referral to identify the MN (HoA)
has nothing to do with the ULID stored in the associated context.
It may not be easy for application to access the context via SHIM6
API. So, establishing context based on ULID<MN's CoA, CN> may not
be useful.
> 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)
Right.
> 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...
Yes, understood.
> > 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
Ok, I see.
>
> > 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
Right. I came to understand what you mean by shim based RO mode.
In SHIM6 over MIPv6 scenario, MN and CN can just establish ULID-pair
context and which can be used for RO by using Lp(MN) as MN's CoA.
I agree that it's efficient and presumably useful.
> > 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?
I meant selection of the ULID of MN. So, on CN side, Lp(peer).
>
> 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
That makes sense. I will look into more on Locator Preference Option
in the proto-04 document. Thanks for your clarification.
Regards,
Shinta