(usagi-users 03713) Re: shim6 implementation

Hi Sebastien,

Thanks for your comments. Please find my comments inline.

On Wed, 13 Sep 2006 17:46:05 +0200
Sebastien Barre <[email protected]> wrote:

> Hello Shinta,
> 
> Shinta Sugimoto wrote:
> 
> >Hello Sebastien,
> >
> >Thanks for a very interesting report! I am also working on
> >SHIM6 related R&D issues.  I am not sure if this ML is suitable
> >place for having SHIM6-specific discussions, but hope it's OK.
> >
> I posted to this mailing list to have discussions about interaction with 
> IPv6
> implementation. I will soon post also to the shim6 mailing list for more
> shim6 specific topics.

That's good.

> 
> >I had a couple of questions below:
> >
> >- I am interested in the placement of your SHIM6 hook (especially
> >for outbound packet processing). It is important to think where
> >should SHIM6 reside in the IP networking stack. In other words,
> >we should consider possible interactions between SHIM6 and other
> >IP protocols such as IPsec, Mobile IP, and so on. I would be nice
> >to have good harmonization of those protocols. According to your
> >explanation, it seems to me that you placed the SHIM6 hook (outbound)
> >before the route lookup (ip6_dst_lookup()). As you mentioned,
> >it's logical from a routing perspective as a route lookup should
> >be performed by the locator pairs. OTOH, we should also take care
> >what other protocols (especially IPsec) do so that SHIM6 could
> >fit into the whole networking stack nicely. In the current Linux
> >networking stack, the policy lookup of IPsec database (SPD) is
> >performed by xfrm_lookup(), which is performed after the route
> >lookup. If we expect that SHIM6 lays below the IPsec, the SPD
> >lookup should be performed by ULID pairs rather than locator pairs.
> >I am afraid that the placement of the SHIM6 hook you mentioned may
> >not allow coordination of SHIM6 and IPsec (assuming that SHIM6
> >lays below the IPsec).
> >
> 
> Yes, this is a problem i had to solve while designing my implementation.
> The compromise I have found is for each packet to go twice through the
> shim6 layer rather than once :
> - first time : ulids are converted to locators, just before 
> ip6_dst_lookup(),
> *but* they are converted back to ULIDs just after ip6_dst_lookup(), so that
> indeed xfrm_lookup works with ULIDs.
> - second time : Just before to leave the IP layer, the final translation 
> takes place.
> (I have still to think about the place of this second time, but that's a 
> single function
> call, which can easily be moved).

I see.

> Although I still have to investigate how to best place the second shim6 
> call, I think
> the first time (forward then reverse translation) is necessary : I see the
> ip6_dst_lookup() as a 'quick jump' into the IP layer, from transport 
> layer, so we also need
> a quick jump into shim6.

Ok. Another interesting approach to take (especially in case of Linux)
is to integrate SHIM6 into XFRM mechanism. The XFRM mechanism is primarily
designed for IPsec (as far as I understand it), but it can also be used
for other kinds of transformation. An example is MIP6; the MIPL2
implementation uses the XFRM mechanism (xfrm policy and state) to apply
MIP6 specific IP transformation in case of route optimization.
When we take a look at the transformation that needs to be done in SHIM6,
which is locator switching and inserting a SHIM6 payload ext header,
it should be possible for XFRM to handle this.

> 
> >
> >- I haven't tried your code yet, but I am curious how you made
> >the enforcement of the SHIM6 context establishment. I mean, how
> >would an initiator realize that it should initiate a SHIM6 context
> >establishment? Could you briefly explain what kind of mechanism
> >do you have (or used)?
> >
> In the draft, it is suggested to have some heuristic to decide when to 
> trigger a context establishment.
> In this first version it was decided to trigger a context establishment 
> when the first packet is sent to
> a new destination (still without a corresponding context). Here is how 
> it is done :
> - During the first call to shim6 (before ip6_dst_lookup()), a check is 
> done to see if there is already a
> context state associated with this ULID pair. If this does not exist a 
> new context state is created and
> a four-way exchange is triggered. I also designed it to correctly deal 
> with unspecified source address :
> at this step, the source address may be unspecified (::). In the normal 
> case it is defined following
> RFC3484 rules during call to ip6_dst_lookup(). The idea in my 
> implementation is to attach a new stream
> to an existing context state, when possible, by giving shim6 priority 
> over RFC3484 rules (another advantage of
> having a call to shim6 before ip6_dst_lookup()).
> - Later, other options will need to be added (such as waiting for n 
> packets to be sent to a same destination before
> to trigger a context establishment, or letting the user decide, by mean 
> of an API).

I see. Thanks for the explanation.

> 
> >
> >- Regarding the presence of the SHIM6 extension header in the data
> >packet, I don't think that the spec requires that the extension
> >header must exist only when the locator pair is different from the
> >ULID pair, under a given context. I mean, there should also be
> >a case where a SHIM6 ext header exists even if the locator pair
> >and ULID pair are identical, right?
> >
> Here is what is said in the draft (sec. 11) :
> --------------
> If there is a ULID-pair context for the ULID pair, then the sender
> needs to verify whether context uses the ULIDs as locators, that is,
> whether Lp(peer) == ULID(peer) and Lp(local) == ULID(local).
> If this is the case, then packets can be sent unmodified by the shim.
> If it is not the case, then the logic in Section 11.1 will need to be
> used.
> --------------
> As I understand it, it is allowed to put the shim6 extension header
> in data packets also if ULID and locators are equal, but I didn 't see
> special cases in the specs when this _should_ be done. However,
> there are discussions about locators rewriting by routers for TE
> support. This could be a case where shim6 ext header should be
> added, in order for the destination to attach the incoming packet to
> the correct context.

I completely agree. It is up to implementation/administrator whether
to put SHIM6 payload ext header when the ULID and locator pairs are
identical. I was clarifying that implementation *can* add SHIM6 payload
ext header in such case.

> 
> >
> >- As Miika questioned, I was also wondering why you want to
> >have most of the components inside the kernel. Yes, we certainly
> >need kernel modification to make the locator switching. But I
> >believe rest of the components (signaling mechanism, state
> >machines, REAP etc.) could be moved to userland. In general, it
> >is easier to have codes outside the kernel for maintenance
> >reasons. For instance, taking a look at existing HIP implementations,
> >to my knowledge, most of them are implemented mainly in userland.
> >It would be interesting to think to which extent the HBA/CGA
> >should be implemented inside/outside the kernel.
> >
> Well, you are now several people to suggest me a (partial) move to
> userland, as well as to have a look at HIP implementation (which I didn't
> learn about before). For HIP impl, I'll get informed, and regarding the 
> move to
> userland, I think this requires a careful architecture re-design. So i 
> will think
> about this re-design, and propose it here before to dive into the source 
> code.

Ok. This kind of discussion is fruitful and your input is very much
appreciated.


Regards,
Shinta