IETF Logo Mail Archive

RE: [v6tc] Issue 1: Could we live with UDP encapsulation always o n?

Pekka Savola <pekkas@netcore.fi> Wed, 22 December 2004 15:18 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 KAA02746; Wed, 22 Dec 2004 10:18:39 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ch8Pq-0001Nn-3O; Wed, 22 Dec 2004 10:28:43 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ch8Dd-0005lC-NT; Wed, 22 Dec 2004 10:16:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ch7ye-0002ko-QF for v6tc@megatron.ietf.org; Wed, 22 Dec 2004 10:00:36 -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 KAA29671 for <v6tc@ietf.org>; Wed, 22 Dec 2004 10:00:34 -0500 (EST)
Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ch88K-0000cW-5b for v6tc@ietf.org; Wed, 22 Dec 2004 10:10:37 -0500
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iBMF02w31083; Wed, 22 Dec 2004 17:00:02 +0200
Date: Wed, 22 Dec 2004 17:00:02 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: "Karen E. Nielsen (AH/LMD)" <karen.e.nielsen@ericsson.com>
Subject: RE: [v6tc] Issue 1: Could we live with UDP encapsulation always o n?
In-Reply-To: <C26BB8276599A44B85D52F9CE41035E1050B9904@esealnt944.al.sw.ericsson.se>
Message-ID: <Pine.LNX.4.61.0412221656550.30824@netcore.fi>
References: <C26BB8276599A44B85D52F9CE41035E1050B9904@esealnt944.al.sw.ericsson.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
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>
Sender: v6tc-bounces@ietf.org
Errors-To: v6tc-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a

On Wed, 22 Dec 2004, Karen E. Nielsen (AH/LMD) wrote:
> In routers (here tunnel servers) the next header value often
> determines whether the packet is sent to the control plane for higher layer processing.
> With UDP encapsulation either
> an additional UDP filtering step must be implemented in the forwarding
> plane or the packets will be sent
> to slow path processing. Neither of these alternatives are really
> promising (either they result in bad performance or in excessive development costs).

I'm not sure if I understand what you're saying.

Whether or not the router should process the packet depends on the 
destination address or if it has router alert hop-by-hop option.

Or are you referring to router implementations which perform 
IPv6-in-IPv4 in hardware (without control plane), but could not do the 
same to IPv6-in-IPv4[UDP] ?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
v6tc mailing list
v6tc@ietf.org
https://www1.ietf.org/mailman/listinfo/v6tc

v2.8.7 | Report a Bug | By Email