FW: UDP encaps for SCTP and SCCP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Resending as I wasn't subscribed to dccp and it bounced - followups across tsvwg and tsv-area as well, please.

Lloyd Wood
http://tinyurl.com/lloydwood-ccsr
________________________________________
From: tsv-area-bounces@xxxxxxxx [tsv-area-bounces@xxxxxxxx] On Behalf Of L.Wood@xxxxxxxxxxxx [L.Wood@xxxxxxxxxxxx]
Sent: 22 April 2010 11:50
To: tsvwg@xxxxxxxx; dccp@xxxxxxxx
Cc: tsv-area@xxxxxxxx
Subject: RE: UDP encaps for SCTP and SCCP

I looked through all the drafts Lars indicated.

The tuexen draft doesn't discuss checksum issues at all; for SCTP, which has its own checksum, this matters. The dccp udpencap draft does discuss checksum issues, but I suspect having a UDP checksum across an entire payload that has its own stronger checksum (as SCTP does), is not useful. The pseudo-header check is still useful and needed on demux, though. This appears to be an application suitable for UDP-lite, covering the headers and providing the pseudo-header check - not UDP.

http://tools.ietf.org/html/draft-ietf-dccp-udpencap-00#section-3.3

section 3.3 of the draft and its use of UDP as UDP-lite -- despite UDP-lite being given a different protocol number because consensus was that messing with UDP checksum and length fields in this way was not compatible with established UDP implementation use - makes me very very uneasy. (The earlier phelan draft had a hack around using a UDP zero checksum, which is arguably worse.) This draft cannot go forwards. Or it should use UDP-lite. This is a workgroup draft? Seriously? Section 5 of RFC3828 and tsvwg experience indicates why this is a bad idea. Is expedience more important?

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...

Does DCCP have any applications using it?

Note that I am NOT expressing a preference for any particular draft here. We should not follow either approach.

Lloyd Wood
http://sat-net.com/L.Wood
________________________________________
From: tsv-area-bounces@xxxxxxxx [tsv-area-bounces@xxxxxxxx] On Behalf Of Lars Eggert [lars.eggert@xxxxxxxxx]
Sent: 22 April 2010 10:57
To: tsvwg@xxxxxxxx; DCCP working group
Cc: TSV Area
Subject: UDP encaps for SCTP and SCCP

Hi,

as most of you probably know, there are two different proposals for how to encapsulate SCTP and DCCP inside UDP.

One approach proposes two protocol-specific encapsulation schemes (described in draft-tuexen-sctp-udp-encaps and draft-ietf-dccp-udpencap).

The second approach proposes a generic encapsulation scheme that can be applied to both SCTP and DCCP (draft-manner-tsvwg-gut).

As a community, we do need to come to consensus on which of these two approaches we want to follow when it comes to UDP encapsulation of SCTP and DCCP. I believe it would be very confusing if we were to standardize both approaches.

I'd hence like to ask folks to read the three documents and post their views to the tsvwg@xxxxxxxx list. I'm personally especially interested in hearing from folks who aren't on the author lists of the documents, but obviously, the authors expert opinions do matter.

Thanks,
Lars

PS: I'm pushing on this topic, because UDP encapsulation is the last remaining work item in the DCCP working group before it can close...


[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux