(usagi-users 03703) shim6 implementation

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,

Sébastien Barré.

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