I agree on that. And, as I said, I'm for "yuck" if it helps get DCCP
deployed!
On Nov 23, 2009, at 7:38 PM, Phelan, Tom wrote:
Hi Michael,
Yes, I agree on the "yuck" factor :-). But I think that there are
enough issues with the zero checksum solution that this sounds
better --
not just with header checksum protection, but also zero checksum is
specifically prohibited in UDPv6 so it won't work at all there (thanks
to Gorry for reminding us of this).
Tom P.
-----Original Message-----
From: Michael Welzl [mailto:michawe@xxxxxxxxxx]
Sent: Monday, November 23, 2009 11:54 AM
To: Phelan, Tom
Cc: gorry@xxxxxxxxxxxxxx; DCCP working group
Subject: Re: Partial checksum support in DCCP_NAT
On Nov 23, 2009, at 4:40 PM, Phelan, Tom wrote:
[Subject changed to focus on sub-thread]
Hi Michael,
I've been thinking about a slight variation of option 3 below for
dealing with partial checksums. Note that the intent of option 3
was
_not_ IP/UDP/UDP-Lite/DCCP as was mentioned in another thread. That
just creates a turtles-all-the-way-down problem -- you still have
the
top-level UDP checksum to work around. The intent of option 3 is to
I understood that "defining UDP-Lite-in-UDP" can't mean
just to put it into UDP, without playing any additional tricks.
I thought that this trick might be to use a checksum of
zero in UDP, and include the UDP header in the UDP-Lite
checksum ... but then there's the NAT problem again, of
course, if the ports are included. Sigh...
make UDP-Lite changes to UDP. Basically, just redefine the UDP
length
field to the semantics of the checksum coverage field in UDP-Lite.
The variation I'm thinking of is to say this -- when a UDP port is
offering the DCCP_NAT service, the length field is redefined to
checksum
coverage. To use DCCP partial checksum, set the (redefined) length
field to the portion of the datagram that needs protection, as
negotiated via the DCCP Partial Checksum feature. This might get
around
the giant can of worms that redefining the length field everywhere
would
open.
So what you say is "for the following port numbers, UDP becomes
UDP lite". Maybe feasible, but architecturally ugly, of course...
I don't know how far we can stretch this sort of ugliness for the
sake of deployability - given the current lack thereof, my tendency
is to agree to ugly solutions, just to make things happen.
I'm not sure what setting the length field to less than the total
packet
size would do to existing end system and NAT implementations.
Looking
at the Linux code, UDP and UDP-Lite are integrated, so it doesn't
barf
on UDP length less than packet length, but it looks like you can't
use
the socket option to accept less checksum coverage unless it's a
UDP-Lite socket.
But I don't think it matters if end systems and NATs need to be
upgraded
to support this, since links already need to be upgraded to
understand
partial checksums.
Opinions?
I'm all for it (but I say "yuck!").
Cheers,
Michael
