(usagi-users 03709) Re: shim6 implementation

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.

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

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.

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

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

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

Regards,

Sébastien.

-- 
Sébastien Barré
Researcher,
CSE department, UCL, Belgium