On Sun, Nov 05, 2006 at 02:23:11PM +0100, Gert Doering wrote:
> Besides that: David, could you go into a bit more details about your
> great GRE rewrite?  I don't claim to understand all the kernel IP 
> routing / interface details - but I'm always interested in IPv6-related
> work, and GRE tunnels are useful :-)

I am about ready to work on this.  Let me tell you what I have in mind.

Right now, gre(4) adds/removes encapsulating IP headers, it hooks
into protocol switches in order to "catch" packets sent to its IP
protocol numbers of interest, and it demultiplexes received packets.
We can do all of that with a socket.  I will make gre use one.

A socket hides such details of its implementation from gre(4) as the
encapsulation type (IPv4, IPv6, UDP), the protocol hooks, and the
demultiplexing, so I can simplify gre and remove its "hooks" from the
IPv4 stack.  Without adding new "hooks," I can add an IPv6 encapsulation
to gre---bonus!

Ok, so there is a catch: a raw IPv4 socket is not suitable for my purpose.
It is not "symmetrical": it removes the IPv4 header from received packets,
but it does not add the IPv4 header to transmitted packets.  No other
IPv4 socket is suitable.  I need to either add an option to the raw IPv4
socket that makes it supply the IPv4 header, or I need to introduce new,
symmetrical socket types---socket(PF_INET, SOCK_DGRAM, IPPROTO_GRE)?
I am inclined to add an option to the raw socket.

After I convert gre to use sockets, I will add to it the capability to
tunnel ethernet frames.

I believe gif(4) and etherip(4) deserve to be converted to use sockets,
too, but I may not tackle that.

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933