This isn't what you're asking, Gerrit, since you are (correctly)
worrying about UNEXPECTED differences that would only crop up in a
prototype, but here is a list of expected changes a kernel DCCP would
require to work with UDP encapsulation.
- Using a 6-tuple instead of a 4-tuple for flow identification.
- Header checksum processing changes (0 on send, required 0 on receive).
Any others come to mind?
Eddie
On 10/11/10 10:27 PM, Gerrit Renker wrote:
Hi Tom,
thank you for the clarifications. Without wanting to embark on wording details
and/or thought experiments, let me just restate what the comments aimed at.
|> The main point I did not understand is whether the aim is to
|> * encapsulate DCCP as a user-space protocol or
|> * encapsulate DCCP as an in-kernel protocol?
|>
| [TomP] The main point is neither, or rather the main point is orthogonal
| to these issues. The main point is to allow DCCP to pass through
| existing NAT devices.
|
What I am asking is whether the specification would work also with an
unmodified kernel that has DCCP already built in. That is, whether the draft
would require changes to the in-kernel protocol in order to make it work with
UDP-encapsulation. Whether the components could be plugged together, without
DCCP necessarily being aware that it is routed somewhere.
I think what would really be highly desirable is some kind of prototype.
For RFC 5596 there was a working prototype, which made discussion much easier
by ruling out impracticable things that would otherwise have complicated the
description.
I would be happy to help with working on a prototype (perhaps a little
later). It would be great if the specification remained not paperwork, but is
also easy and simple to put into practice.
Gerrit
