(usagi-users 03708) Re: shim6 implementation

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

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

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

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

Thanks again for your interesting report! Meanwhile, I will take
a closer look at your codes and documents.


Regards,
Shinta

On Mon, 11 Sep 2006 11:11:29 +0200
Sebastien Barre <[email protected]> wrote:

> Hi,
> 
> I am currently working on a shim6 implementation, within the IPv6
> stack. Shim6 is the multihoming solution currently developped by IETF
> (http://www.ietf.org/html.charters/shim6-charter.html). As this has
> rather strong implications on IPv6 implementation, I think it could be
> useful to have discussions here about this topic. I already have a
> working prototype for linux 2.6.15, which I did during my Master's
> thesis (available at
> http://gforge.info.ucl.ac.be/projects/shim6/). This prototype is fully
> documented in both theory and implementation in the Master's thesis
> (available on this same web site), in french (but comments in the code
> are in english). I'm now updating it for linux 2.6.17.
> Anyone interested in looking the code will easily find my
> modifications by searching the string "__sbarre__".
> 
> Now I will continue this work as part of a PhD. One aim is to end with an
> industry useable solution. For this to be done, I think it could be
> important to have a good interaction with the existing IPv6
> implementation, which is why I am mailing to this list (also to
> collect any useful idea/advice, of course).
> 
> Here is a (quick) summary of shim6 theory :
> 
> Shim6 is a host-centric multihoming solution for IPv6. It supposes
> that each host in a network owns multiple global addresses, one per
> provider, so that chosing a given address pair implies a path
> choice. Shim6 splits up the two semantics of an IPv6 address : An address
> is 1. a locator (used for IP routing), and 2. an identifier (known as
> ULID, Upper Layer IDentifier) for upper layers, used for example by
> TCP for identifying context states.
> The split is done by adding a new level in the TCP/IP stack, within
> the IP level. The new shim6 level provides a mapping between ULIDs and
> locators so that any locator can be used and changed (useful in case
> of failure) while ULIDs are kept constant, so that TCP states are saved.
> 
> Now, here is how the current implementation takes place in the kernel:
> (note that, as this mailing list is for IPv6 stack, i will only
> discuss the places in the existent code where I changed/added
> things. But any comment or question about other code (shim6 core) is 
> welcome)
> 
> - First, a general design rule i try to follow is to keep all shim6
>   code in dedicated files, giving the fewest changes i can to the
>   existing IPv6 implementation.
> 
> - In the current IPv6 implementation, when an outgoing packet
>   traverses the tranport layer, the routing table is consulted
>   (ip6_dst_lookup()). Because transport works with ULIDs but routing
>   works with locators, I've added a call to a shim6 function before
>   ip6_dst_lookup(), and another after this same function, to recover
>   the ULIDs for further processing in the transport layer. This is
>   done in tcp_ipv6.c, udp.c and raw.c
> 
> - Then, the packet goes through the IPv6 layer, and must experience
>   its final address translation before to be sent. This is done at the
>   very beginning of ip6_output2() (ip6_output.c).
> 
> - At packet reception, an incoming packet may have a shim6 extension
>   header. In my first version, I parsed this extension header 'by
>   hand'. Now, this will be changed : shim6 will be registered as a
>   protocol, the way it is done for other extension headers
>   (exthdrs.c).
>   Anyway, I need to modify ip6_input_finish() (ip6_input.c), because a
>   packet without shim6 extension header may nevertheless need shim6
>   attention. (shim6 uses extension headers only when ULIDs differ from
>   locators, so a normal packet may well be associated with a shim6
>   context state).
> 
> - I also use addrconf.c in a special way. The autoconf module has the
>   advantage of keeping information about the state of IPv6
>   locators. Shim6 gets informed about addition and removal of
>   addresses by mean of __ipv6_ifa_notify().
> 
> - Each time an exploration occurs (sending probes to various address
>   pairs), Shim6 scans through peer locators (locally stored) and local
>   locators. It would be a lost of space to manage a new store for
>   that, so I use the global addrconf hashtable (of course with careful
>   use of protection locks). For this to work, a few new fields are
>   added to struct inet6_ifaddr (if_inet6.h). This way it is possible
>   to use the global address hashtable, consulted using
>   ipv6_get_ifaddr(), which is more efficient.
> 
> 
> Well, this is what is done for the time being. Now it will probably
> change fastly. I'll be always listening to the mailing list, and try
> to take into account any good comment for my work.
> 
> I'll try to update frequently the gforge site 
> (http://gforge.info.ucl.ac.be/projects/shim6/).
> 
> As a final note, the current source code is NOT supposed to be
> perfect, nor perfectly clean (although i tried to meet this and hope
> it was at least a bit successful), but the aim is to do it converge
> until a stable, clean and beautiful solution :-).
> 
> 
> Thank you very much for any comment,
> 
> Sastien Barr
> 
> -- 
> Sastien Barr> Researcher,
> CSE department, UCL, Belgium