Re: Implementation of the LISP protocol (GSOC 2010)

[Patrick McHardy <kaber@trash.net>]

Alex Lorca wrote:
> 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?

You can use an encapsulation socket - check out udp_queue_rcv_skb().

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

L2TP.