On 26 Apr 2010, at 20:07, Jukka Manner wrote: > Hi Lloyd, > > I have to object here. :) > > On 22.4.2010 13:50, L.Wood@xxxxxxxxxxxx wrote: > >> The GUT draft and recreating IP packets strikes me as problematic in implementation, just as much as NATs. I'd rather have a simple IP-in-IP-tunnel (or even GRE) and rely on decap at the endpoints... >> > > GUT is not problematic, nor difficult. We have it running on Linux and > works great. Next we'll put it on BSD (should be just a medium update to > the code). I'm hoping to release the implementation as open source > sometime in the future. > > Our draft could be much better in explaining the idea clearly. The fact > that we are "creating ip packets" is due to our implementation being a > separate piece of code, a separate service on the OS, easily installed. No. You are "_re_creating IP packets" in that you are not carrying the IP header end-to-end, but are carrying minimal state to recreate an approximation of the original IP header. That makes me nervous. (This is not link header compression.) You are not encapsulating the IP protocol header, but eviscerating it. You call that "reconstruct the native IP packet" or "rebuild the IP packet". http://tools.ietf.org/html/draft-manner-tsvwg-gut-01 (can I suggest a spelling checker for the typos?) The summary benefits you state in section 8 work for a normal UDP tunnel, and with rather less complexity. On a related note, I spent years dealing with proponents of SCTP, and yet never encountered any actual we-chose-to-use-SCTP end users. So, are there any actual DCCP users out there? All this effort to save a few bytes tunnelling complex protocols that still won't be used? Pointless. > The functionality could be as well be integrated into the IP stack, but > that would be somewhat more challenging. ...and won't happen. L. > > regards, > Jukka Lloyd Wood L.Wood@xxxxxxxxxxxx http://sat-net.com/L.Wood
