Re: [v6tc] Issue 1: Could we live with UDP encapsulation always on?
Jeroen Massar <jeroen@unfix.org> Fri, 17 December 2004 10:19 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01339;
Fri, 17 Dec 2004 05:19:29 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
by ietf-mx.ietf.org with esmtp (Exim 4.33)
id 1CfFLV-0007SF-GH; Fri, 17 Dec 2004 05:28:25 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1CfFBs-0007FT-EB; Fri, 17 Dec 2004 05:18:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1CfF6j-0005zo-Hr
for v6tc@megatron.ietf.org; Fri, 17 Dec 2004 05:13:09 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00774
for <v6tc@ietf.org>; Fri, 17 Dec 2004 05:13:07 -0500 (EST)
Received: from noc.sixxs.net ([213.197.29.32] ident=postfix)
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfFFB-0007Gb-C9
for v6tc@ietf.org; Fri, 17 Dec 2004 05:22:03 -0500
Received: from localhost (localhost [127.0.0.1])
by noc.sixxs.net (Postfix) with ESMTP id DE7D92400C;
Fri, 17 Dec 2004 11:12:51 +0100 (CET)
Received: from noc.sixxs.net ([127.0.0.1])
by localhost (noc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
id 24786-02; Fri, 17 Dec 2004 11:12:51 +0100 (CET)
Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45])
(using SSLv3 with cipher RC4-MD5 (128/128 bits))
(No client certificate requested)
by noc.sixxs.net (Postfix) with ESMTP id E558124008;
Fri, 17 Dec 2004 11:12:50 +0100 (CET)
Subject: Re: [v6tc] Issue 1: Could we live with UDP encapsulation always on?
From: Jeroen Massar <jeroen@unfix.org>
To: Alain Durand <Alain.Durand@sun.com>
In-Reply-To: <6D2CE1A0-5011-11D9-81E4-00039358A080@sun.com>
References: <6D2CE1A0-5011-11D9-81E4-00039358A080@sun.com>
Organization: Unfix
Date: Fri, 17 Dec 2004 11:12:49 +0100
Message-Id: <1103278369.25975.57.camel@firenze.zurich.ibm.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 (2.0.2-6)
X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc: v6tc@ietf.org
X-BeenThere: v6tc@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: v6tc.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/v6tc>,
<mailto:v6tc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/v6tc>
List-Post: <mailto:v6tc@ietf.org>
List-Help: <mailto:v6tc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/v6tc>,
<mailto:v6tc-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1678583960=="
Sender: v6tc-bounces@ietf.org
Errors-To: v6tc-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
On Fri, 2004-12-17 at 01:52 -0800, Alain Durand wrote: > Obviously the first thing to consider is the UDP overhead. When the > payload is large,there isn't much difference, but when it is small, there is a non > negligible impact. > > Another point to consider is that UDP encapsulation might force packets > to go to the slow path on the tunnel end-point unless special code is > added > in the forwarding plane. > > Also, IPv6/UDP/IPv4 has not generally been implemented so far, so we > have a deployment problem. Not implemented or deployed? I wonder why Freenet6 has their special NAT traversal code and why SixXS have AYIYA then ;) > Also, tons of PCs have now teredo, so there may > be some compatibility issues and/or some potential code to leverage. Teredo basically is one of the main three (are there others?) versions of IPv6/UDP/IPv4 protocol. The only thing being that it is more a p2p like application in that it not uses a pre-configured or out-of-band managed designated server. It is possible to configure that though (it is something like: netsh set teredo <relay>...) Byte-wise you could easily 'live' with UDP encaps btw. Especially as proto-41 is non-authenticated and very spoof sensitive, oh hmm so is the protocol which is proposed in the new draft. AYIYA, which looks somewhat quite like the proposed protocol, does not have this issue btw... With people downloading movies etc, do 3 bytes per packet extra hurt? The target is getting IPv6 deployed and available to the masses (Longhorn in 2006 will come default with IPv6 and you can turn of IPv4 ;) Who does this or how does not really matter as long as it is done and people can enjoy the freedom of enough addresses and thus end-2-end connectivity. Why is there a checksum in that newly proposed protocol anyway? There was a reason why checksumming was removed from the IPv6 headers ;) Greets, Jeroen PS: The mailinglist archives don't work...
_______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc
- [v6tc] Issue 1: Could we live with UDP encapsulat… Alain Durand
- Re: [v6tc] Issue 1: Could we live with UDP encaps… Jeroen Massar
- Re: [v6tc] Issue 1: Could we live with UDP encaps… Pekka Savola
- Re: [v6tc] Issue 1: Could we live with UDP encaps… Jeroen Massar
- Re: [v6tc] Issue 1: Could we live with UDP encaps… Alain Durand
- Re: [v6tc] Issue 1: Could we live with UDP encaps… Alain Durand
- Re: [v6tc] Issue 1: Could we live with UDP encaps… Jeroen Massar
- Re: [v6tc] Issue 1: Could we live with UDP encaps… Alain Durand