From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: Implementation of the LISP protocol (GSOC 2010) Date: Fri, 14 May 2010 23:34:21 +0200 Message-ID: <4BEDC1DD.6070807@trash.net> References: <87ocgijhtz.wl%alex.lorca@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: netdev , Johannes Berg To: Alex Lorca Return-path: Received: from stinky.trash.net ([213.144.137.162]:53251 "EHLO stinky.trash.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754072Ab0ENVeX (ORCPT ); Fri, 14 May 2010 17:34:23 -0400 In-Reply-To: <87ocgijhtz.wl%alex.lorca@gmail.com> Sender: netdev-owner@vger.kernel.org List-ID: 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.