Oh, I understand now. So this just wastes CPU cycles to get transparency? > -----Original Message----- > From: Jukka Manner [mailto:jukka.manner@xxxxxx] > Sent: Tuesday, April 13, 2010 10:46 AM > To: Phelan, Tom > Cc: Colin Perkins; DCCP working group > Subject: Re: I-D Action:draft-ietf-dccp-udpencap-00.txt > > No, because the outer UDP checksum protects the tunneled part, right? > > Jukka > > On 04/13/2010 05:28 PM, Phelan, Tom wrote: > > Hi Jukka, > > > > Are you saying that the receiving GUT recalculates the DCCP checksum? > > But the only effect that would have is to make any errors introduced on > > the way undetectable. > > > > Tom P. > > > >> -----Original Message----- > >> From: Jukka Manner [mailto:jukka.manner@xxxxxx] > >> Sent: Tuesday, April 13, 2010 12:58 AM > >> To: Phelan, Tom > >> Cc: Colin Perkins; DCCP working group > >> Subject: Re: I-D Action:draft-ietf-dccp-udpencap-00.txt > >> > >> Yes, that's right. Except that GUT itself recalculates the checksum > >> before the packet hits the DCCP receiver. Thus, the UDP-encapsulated > >> DCCP flow never needs to do anything - it never even sees that GUT was > >> there. > >> > >> regards, > >> Jukka > >> > >> On 12.4.2010 23:17, Phelan, Tom wrote: > >>> Hi Jukka, > >>> > >>> Well, I guess one of us misunderstands something, because it looks > > to me > >>> like GUT doesn't work. Taking your example in section 3.3 of the > > draft: > >>> > >>> We start out with a DCCP packet encapsulated in IP as: > >>> Dest addr (DA): B > >>> Src addr (SA): A > >>> DCCP Ports : E and F (I assume that's what your notation > > means) > >>> DCCP checksum calculated over contents of DCCP packet and IP > >>> pseudo header with DA/SA = B/A > >>> > >>> This packet gets GUT'd as: > >>> DA: B > >>> SA: A > >>> UDP Ports: E and GUT > >>> DCCP packet unchanged > >>> > >>> This packet gets NAT'd as: > >>> DA: B > >>> SA: C > >>> UDP Ports: P and GUT > >>> DCCP Packet unchanged > >>> > >>> This packet arrives at the remote host and gets un-GUT'd as: > >>> DA: B > >>> SA: C (!) > >>> DCCP packet unchanged > >>> > >>> And this packet fails DCCP checksum because the Source Address (C) > > is > >>> different now than when the checksum was calculated initially (with > > SA = > >>> A). > >>> > >>> What am I missing? > >>> > >>> Tom P. > >>> > >>> > >>>> -----Original Message----- > >>>> From: Jukka Manner [mailto:jukka.manner@xxxxxx] > >>>> Sent: Monday, April 12, 2010 3:21 PM > >>>> To: Phelan, Tom > >>>> Cc: Colin Perkins; DCCP working group > >>>> Subject: Re: I-D Action:draft-ietf-dccp-udpencap-00.txt > >>>> > >>>> > >>>> DCCP wouldn't need to care about checksums if we had a generic > >>>> encapsulation scheme, such as the one we have been discussing on > > the > >>> TSV > >>>> list, the Generic UDP Tunneling scheme GUT. > >>>> > >>>> Jukka > >>>> > >>>> On 04/12/2010 06:05 PM, Phelan, Tom wrote: > >>>>> Hi All, > >>>>> > >>>>> OK, I'll accept the apparent consensus and make the DCCP header > > the > >>> same > >>>>> format in both encapsulations. Note that a DCCP implementation is > >>> still > >>>>> going to need to know whether this came in with UDP encap or STD > >>> encap > >>>>> -- the checksum processing needs to be different at least. > >>>>> > >>>>> Tom P. > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Colin Perkins [mailto:csp@xxxxxxxxxxxxx] > >>>>>> Sent: Sunday, April 11, 2010 5:55 AM > >>>>>> To: Phelan, Tom > >>>>>> Cc: Pasi Sarolahti; DCCP working group > >>>>>> Subject: Re: I-D Action:draft-ietf-dccp-udpencap-00.txt > >>>>>> > >>>>>> On 7 Apr 2010, at 15:14, Phelan, Tom wrote: > >>>>>>>> -----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 > >>>>>> ... > >>>>>>>> * 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. > >>>>>> > >>>>>> > >>>>>> We're early enough in the life of DCCP that I'd prefer we get > > this > >>>>>> right, than preserve running code that has minimal deployment. > >>>>>> > >>>>>> -- > >>>>>> Colin Perkins > >>>>>> http://csperkins.org/ > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> -- > >>>> Jukka MJ Manner, Professor, PhD. Phone: +358+(0)9+470 22481 > >>>> Aalto University Mobile: +358+(0)50+5112973 > >>>> Department of Communications Fax: +358+(0)9+470 22474 > >>>> and Networking (Comnet) Office: G320a (Otakaari 5A) > >>>> P.O. Box 13000, FIN-00076 Aalto E-mail: jukka.manner@xxxxxx > >>>> Finland www.netlab.hut.fi/~jmanner/ > > -- > Jukka MJ Manner, Professor, PhD. Phone: +358+(0)9+470 22481 > Aalto University Mobile: +358+(0)50+5112973 > Department of Communications Fax: +358+(0)9+470 22474 > and Networking (Comnet) Office: G320a (Otakaari 5A) > P.O. Box 13000, FIN-00076 Aalto E-mail: jukka.manner@xxxxxx > Finland www.netlab.hut.fi/~jmanner/
