Date: Thu, 20 Nov 2008 08:00:11 -0500 From: Randall Stewart <rrs@lakerest.net> To: Julian Elischer <julian@elischer.org> Cc: freebsd-net <freebsd-net@freebsd.org> Subject: Re: Thinking about UDP and tunneling Message-ID: <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> In-Reply-To: <49249443.8050707@elischer.org> References: <D72E9703-C8E7-4A21-A71E-A4B4C2D7E8F4@lakerest.net> <49245EE3.2000700@elischer.org> <B08E77C5-CF11-42EE-9F9A-5E428CECF284@lakerest.net> <49247BEE.4040201@elischer.org> <905A5B58-54D2-4B79-A1B4-44C6D5136691@lakerest.net> <49249443.8050707@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 19, 2008, at 5:33 PM, Julian Elischer wrote: >>> >> Its not new, its the same ip header.. >> Its just you go into the mbuf chain and take out >> the udp header... > > well you can't do that at the socket buffer becasue you've discarded > the IP header. It may not even be in the mbufs you have. (though it's > unlikely). After you've processed the UDP part the IP part is gone so > you'd need to intercept the packet way earlier and then do your > own UDP processing, (or maybe attach the IP header onto it with a > tag). > > One would definitely have to do some work in udp_input() not a lot from what I can tell... but it would take some work. Maybe good course is to use the socket(9) stuff, but add an option that can set a "by-pass function" if the socket is udp... right after you establish the INP the packet goes to, if the function is set, you engage the bypass... >>> >>> >>>> And sends it into the transport_input() (same one called by >>>> ip_input). >>>> This then makes a clean and easy way to have "tunneled UDP" >>>> transport protocols >>>> work in kernel. The input side looks the same. Output is pretty >>>> easy.. easy to >>>> drop a UDP header in out output... >>>> Netgraph would have to be watching every UDP packet always.. >>> >>> just those that go to that ksocket. we hook on at the socketbuf >>> point. >> Hmm sounds plausible.. > > what you are suggesting is UDP header injection, between the > existing IP header and existing SCTP header, then on reception, > stripping it out. > > > We'd have to do a bit of hacking to do that.. it's kind of 'unusual' You need to take a look at some of the activities in tsvwg and the transport area open area meeting in the IETF. Not counting Jonathan's Rosenburgs IAB presentation an IETF or two ago claiming that "all new transports must tunnel via UDP". This seems to be a more and more common theme in the IETF. Now I personally do not agree that new transports cannot be deployed without UDP tunneling.. however there will always be the need for this IMO.. since you will often have NAT's that don't know about the new transport "yet"... Jonathan (and others claims is that the "yet" is really a "never".. here I disagree). Having infrastructure so we can do UDP tunneling of a new transport easily is IMO a good idea. Netgraph, looks interesting.. but I am afraid is not in GENERIC.. so you end up with a solution that only sometimes works. What I am thinking is a clean way to have kernel sockets(9) extended a bit so that we can better support tunneling input... Let me chew on this a while and come up with a working solution ... using socket(9) as much as possible... I think a couple of tweaks will be needed.. but I think its quite feasible and will be a benefit for not just SCTP but also DCCP and some of the other transports on the horizon... R > > > in-kernel UDP encapsulation is easy but we don't have header > injection.. > > I can see how one would do it > but I was wrong before, you'd need to do some work. > >> R >>> > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?76CF7D15-251F-4E43-86BE-AD96F48AF123>