Re: I-D Action:draft-ietf-dccp-udpencap-00.txt

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

 



Hi Pasi,

See inline...

Tom P.

> -----Original Message-----
> From: Pasi Sarolahti [mailto:pasi.sarolahti@xxxxxx]
> Sent: Thursday, February 18, 2010 5:54 PM
> To: DCCP working group
> Cc: Phelan, Tom
> Subject: Fwd:  I-D Action:draft-ietf-dccp-udpencap-00.txt
> 
> Hi,
> 
> Thanks, Tom, for submitting the the draft. Everyone, please take a
> look at this version and send comments.
> 
> Checksum calculation was discussed on the list last November to quite
> some extent. What do people think, is the current version (i.e.,
> applying UDP length for partial checksum calculation logic, always
> include UDP/DCCP header) acceptable?
> 
> In addition, to perform some primitive issue tracking, I think the
> following points were raised earlier on the mailing list, but
> according to my reading are not addressed yet:
> 
> * make a note this mode is not valid for IPv6
>    -- Gorry / 2009-11-20
>    (PS: I'm not sure if "this mode" referred to checksums, or the
draft
>    overall, and not sure I understand what "not valid" means.
Hopefully
>    UDP encapsulation is not necessary with IPv6, but technically it
>    could be done, right?)
> 
[Tom P.] I'm not sure what this refers to either.  Gorry?

> * worth considering a straight UDP encapsulation that does not adjust
>    the position and order of the fields.
>    -- Gorry / 2009-11-20
> 
[Tom P.] Worth considering, but since there are already two
implementations of the existing encapsulation I'm going to resist this.

> * essential that any encapsulation draft also notes the drawbacks of
>    this mode, and hence advocates native transport were possible
>    (e.g. No currently defined support for ECN, No currently defined
>    support for shared PMTUD, Restricted support for partial coverage)
>    -- Gorry / 2009-11-20
> 
[Tom P.] Does anyone want to take a stab at noting the drawbacks?

> (please shout if there was something in the past discussion I missed)
> 
> Tom (& others), do you have opinions about the points above?
> 
> - Pasi
> 
> 
> Begin forwarded message:
> 
> > From: Internet-Drafts@xxxxxxxx
> > Date: February 11, 2010 9:15:02 AM PST
> > To: i-d-announce@xxxxxxxx
> > Cc: dccp@xxxxxxxx
> > Subject:  I-D Action:draft-ietf-dccp-udpencap-00.txt
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the Datagram Congestion Control
> > Protocol Working Group of the IETF.
> >
> >
> > 	Title           : Datagram Congestion Control Protocol (DCCP)
> > Encapsulation for NAT Traversal (DCCP-NAT)
> > 	Author(s)       : T. Phelan
> > 	Filename        : draft-ietf-dccp-udpencap-00.txt
> > 	Pages           : 11
> > 	Date            : 2010-02-11
> >
> > This document specifies an alternative encapsulation of the Datagram
> > Congestion Control Protocol (DCCP), referred to as DCCP-NAT.  This
> > encapsulation will allow DCCP to be carried through the current
> > generation of Network Address Translation (NAT) middleboxes without
> > modification of those middleboxes.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-dccp-udpencap-00.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.


[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