Subject: Implementation of the LISP protocol (GSOC 2010)

From: Alex Lorca <[email-masked]>
Date: Fri, 14 May 2010 17:26:16 -0400

Hi

My name is Alex Lorca and I'm working in the implementation of LISP
[0] in Linux for the Google Summer of Code 2010 program, so I'll be
bothering the list with silly questions for the next months. Any
feedback is much appreciated.

Basically, LISP is somewhat of a tunneling protocol that creates
tunnels on demand between routers called Ingress Tunnel Router (ITR)
and Egress Tunnel Router (ETR). ITRs encapsulate normal traffic
appending a special header and send it to ETRs where it gets
decapsulated. The purpose of this is to forward packets from hosts
behind then ITR to hosts behind the ETR because they can't reach
each other directly using their public IPs (more info in [0]). The
encapsulation is done like this:

 IP | UDP | LISP | IP | ...

The idea is to implement something like ipip or ip_gre: a virtual
interface that takes care of the LISP packets, creating and
maintaining tunnels, decapsulating/encapsulating and forwarding
packets. This includes also the userspace tools for administration.
Ideally, for the implementation to be useful, the process has to have
as lowest latency as possible since almost all the traffic directed to
the LISP interface is to be forwarded.

I've come across the first problem: since the IP protocol number field
in the LISP packets is UDP (17) I can't send the packet to a layer 4
handler function via the registered protocols table. The only thing
that comes to my mind is just replace the l4 handler for UDP (udp_rcv)
in the protocol table. Is there a cleaner way to do this?

Also, is there others tunnel like implementations in linux, aside from
ipip, gre and sit?

Regards

[0] http://www.lisp4.net/

-- 
Alex Lorca