Crist, I am a contributor of RFC3077 and we will have a IETF meeting in Atlanta. I will discuss the issue which you wrote below at the UDLR-WG meeting. Now we are preparing a updated draft which support the operation the network employing RFC3077. Thank you. Jun Takei Crist J. Clark wrote:

On Fri, Nov 15, 2002 at 04:41:10PM +0100, Jurian van der Knaap wrote:

...

You might get some info out of the Linux DirecPC driver, or maybe the developers of the driver can help.

Find it at http://sourceforge.net/projects/direcpc

Hope this is of any help,

Yeah, this helped. It showed me that their protocol is totally broken.

They do an GRE- or IPIP-like encapsulation, but then set the protocol field to that of the encapsulated packet. Or if the encapsulated packet is not TCP, UDP, or ICMP, they set the outer protocol to TCP. This will totally break behind NAT when the NATing device changes the source IP address and then "fixes" the TCP or UDP checksum due to the pseudo-header change. Either the NATing device drops the packet when the intial checksum is wrong or it mangles the payload, which isn't really TCP.

Who designs these things? And what were they smoking when they did?