Re: Requesting adoption of draft-krishnan-ipv6-exthdr-06.txt as wg item

[arno at natisbad.org (Arnaud Ebalard)]

Hi Erik,

"Erik Kline" <ek at google.com> writes:

> [snip]
>
>> In the end, instead of defining "An uniform format for IPv6 extensions
>> headers" using a new specific type, wouldn't it be easier to just force
>> future definitions of extension headers to follow the common layout
>> proposed below. What were the arguments raised privately or during
>> meetings not to follow that path?
>
> One of the issues is the "cross-pollution" of IPv6 header number space
> and IP protocol number space.

yes.

> IPv6 headers are indistinguishable from higher layer protocols.

In the network, they are. But at the end of the path, the destination
will make the distinction.

> I'm thinking of a new end-node header that a firewall might block for
> lack of recognition when in fact the higher layer protocol might be
> recognizable (TCP, UDP, ...).

I see your point, but ... if it is not able to parse an unknown
extension header before the upper layer, then, trying to interpret this
upper layer based on its *local and partial understanding of the
context* looks like a bad idea to me. Just consider the case of a
RH2-carried or HAO in DestOpt-carried TCP packet which has an invalid
checksum during transport. 

L4 is an E2E matter. Deep inspection in the network, like NAT, are
*usFrom ipv6-bounces at ietf.org  Thu Oct 16 07:04:51 2008
Return-Path: <ipv6-bounces at ietf.org>
X-Original-To: ipv6-archive at megatron.ietf.org
Delivered-To: ietfarch-ipv6-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id D7C083A6800;
	Thu, 16 Oct 2008 07:04:51 -0700 (PDT)
X-Original-To: ipv6 at core3.amsl.com
Delivered-To: ipv6 at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 5E2FC3A6BF6
	for <ipv6 at core3.amsl.com>; Thu, 16 Oct 2008 06:10:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id VjAsw59DLmWF for <ipv6 at core3.amsl.com>;
	Thu, 16 Oct 2008 06:10:29 -0700 (PDT)
Received: from moog.chdir.org (moog.chdir.org [88.191.42.160])
	by core3.amsl.com (Postfix) with ESMTP id 742ED3A6B84
	for <ipv6 at ietf.org>; Thu, 16 Oct 2008 06:10:29 -0700 (PDT)
Received: from cct.net8.nerim.net ([213.41.184.223] helo=oslo)
	by moog.chdir.org with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.63) (envelope-from <arno at natisbad.org>)
	id 1KqSd9-0000HA-Cw; Thu, 16 Oct 2008 15:11:07 +0200
From: arno at natisbad.org (Arnaud Ebalard)
To: "Erik Kline" <ek at google.com>
Subject: Re: Requesting adoption of draft-krishnan-ipv6-exthdr-06.txt as wg
	item
References: <48F519CC.6060103 at ericsson.com> <87d4i1gdq2.fsf at natisbad.org>
	<2e8c64260810160213h19be08c4m84d340719de06e9f at mail.gmail.com>
X-GnuPG-Key: 0x047A5026
Date: Thu, 16 Oct 2008 15:09:38 +0200
In-Reply-To: <2e8c64260810160213h19be08c4m84d340719de06e9f at mail.gmail.com>
	(Erik Kline's message of "Thu, 16 Oct 2008 02:13:31 -0700")
Message-ID: <cuotzbcr8j1.fsf at natisbad.org>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 16 Oct 2008 07:04:50 -0700
Cc: IETF IPv6 Mailing List <ipv6 at ietf.org>, Jim_Hoagland at symantec.com,
	Suresh Krishnan <suresh.krishnan at ericsson.com>
X-BeenThere: ipv6 at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request at ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ipv6>
List-Post: <mailto:ipv6 at ietf.org>
List-Help: <mailto:ipv6-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipv6-bounces at ietf.org
Errors-To: ipv6-bounces at ietf.org

Hi Erik,

"Erik Kline" <ek at google.com> writes:

> [snip]
>
>> In the end, instead of defining "An uniform format for IPv6 extensions
>> headers" using a new specific type, wouldn't it be easier to just force
>> future definitions of extension headers to follow the common layout
>> proposed below. What were the arguments raised privately or during
>> meetings not to follow that path?
>
> One of the issues is the "cross-pollution" of IPv6 header number space
> and IP protocol number space.

yes.

> IPv6 headers are indistinguishable from higher layer protocols.

In the network, they are. But at the end of the path, the destination
will make the distinction.

> I'm thinking of a new end-node header that a firewall might block for
> lack of recognition when in fact the higher layer protocol might be
> recognizable (TCP, UDP, ...).

I see your point, but ... if it is not able to parse an unknown
extension header before the upper layer, then, trying to interpret this
upper layer based on its *local and partial understanding of the
context* looks like a bad idea to me. Just consider the case of a
RH2-carried or HAO in DestOpt-carried TCP packet which has an invalid
checksum during transport. 

L4 is an E2E matter. Deep inspection in the network, like NAT, are
*usually* jually* just bad ideas that kill E2E (IMHO).

I understand the logic for having a common header format for IPv6
extension headers (parsing, code reuse, easier dissection when
debugging) and a different number space, but I just don't buy the FW
argument.

> With the introduction of a separation between the two more policy
> choices become possible.

yes.

Just to clarify my position, I think the draft is a good idea. It would
have been better to have that format for extensions defined that way
from the beginning in IPv6 specification ;-)

Cheers,

a+
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


ust bad ideas that kill E2E (IMHO).

I understand the logic for having a common header format for IPv6
extension headers (parsing, code reuse, easier dissection when
debugging) and a different number space, but I just don't buy the FW
argument.

> With the introduction of a separation between the two more policy
> choices become possible.

yes.

Just to clarify my position, I think the draft is a good idea. It would
have been better to have that format for extensions defined that way
from the beginning in IPv6 specification ;-)

Cheers,

a+
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------