comments on draft-baker-6man-hbh-header-handling
"C. M. Heard" <heard@pobox.com> Wed, 11 November 2015 04:07 UTC
Return-Path: <heard@pobox.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF2E1B3E39 for <ipv6@ietfa.amsl.com>; Tue, 10 Nov 2015 20:07:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.079
X-Spam-Level:
X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6B0m7BiL_ai2 for <ipv6@ietfa.amsl.com>; Tue, 10 Nov 2015 20:07:14 -0800 (PST)
Received: from sasl.smtp.pobox.com (pb-smtp0.int.icgroup.com [208.72.237.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 437A41B3EB0 for <ipv6@ietf.org>; Tue, 10 Nov 2015 20:07:13 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp0.pobox.com (Postfix) with ESMTP id 334CB2A23A for <ipv6@ietf.org>; Tue, 10 Nov 2015 23:07:12 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:content-type :content-transfer-encoding; s=sasl; bh=FbwkZ8wH4g+Gw8sFoeu5z8AgA B8=; b=VIPhE4VVHHGotLH0as1FyBHpWgB+eMnI9RqmM47sY0Es2qo7PkwD2Njba zjuFynzzfgPWJ5pu37PDNzClBw2Fsfj7aegmEKCy7BqNqPqRXaK/Wo4ZuCSiVIO7 rQuJHcKQFM2E8SDSLnv3YcfZNCsOTjwfOfHOGMXI3cRtBQuE8s=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:content-type :content-transfer-encoding; q=dns; s=sasl; b=pfcmdV3SaDHOe/GNEcD 2BWM1Sv4rXxK/qhtTG7BwH5NuThRh0UOdyYMwM1+EMVe/Z9xR0LUHLF+6O765swa V1W743sXykr+uIxoc+7eDj9y4m1Od3yn/K94onENql/Ku9ihP0udFMQh0AFzyO3i 6F2x/e0fFvIl/PoSCNfQ47oo=
Received: from pb-smtp0.int.icgroup.com (unknown [127.0.0.1]) by pb-smtp0.pobox.com (Postfix) with ESMTP id 2B0292A239 for <ipv6@ietf.org>; Tue, 10 Nov 2015 23:07:12 -0500 (EST)
Received: from mail-ob0-f180.google.com (unknown [209.85.214.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp0.pobox.com (Postfix) with ESMTPSA id C99FA2A237 for <ipv6@ietf.org>; Tue, 10 Nov 2015 23:07:06 -0500 (EST)
Received: by obbza9 with SMTP id za9so14194751obb.1 for <ipv6@ietf.org>; Tue, 10 Nov 2015 20:07:06 -0800 (PST)
X-Received: by 10.60.85.34 with SMTP id e2mr4108541oez.61.1447214826369; Tue, 10 Nov 2015 20:07:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.202.201.17 with HTTP; Tue, 10 Nov 2015 20:06:47 -0800 (PST)
From: "C. M. Heard" <heard@pobox.com>
Date: Tue, 10 Nov 2015 20:06:47 -0800
X-Gmail-Original-Message-ID: <CACL_3VHXVScv+5Arja-bP1bV-1hWQJK2vO3SP-JyjgoAj4mtzg@mail.gmail.com>
Message-ID: <CACL_3VHXVScv+5Arja-bP1bV-1hWQJK2vO3SP-JyjgoAj4mtzg@mail.gmail.com>
Subject: comments on draft-baker-6man-hbh-header-handling
To: 6man WG <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Pobox-Relay-ID: AC2D52EA-8829-11E5-B850-6BD26AB36C07-06080547!pb-smtp0.pobox.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/B478Vr9gwtjngUUWsQ_Qnsdeb8U>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Nov 2015 04:07:15 -0000
Regarding Section 2.3, Adding headers or options in transit: Use cases under current consideration take this a step further: a router or middleware process MAY add an extension header, MAY add an option to the header, which may extend the length of the Hop-by-Hop Extension Header, or MAY process such an option in a manner that extends both the length of the option and the Extension Header containing it. This seems to me to be a violation of the basic architectural assumptions of RFC 2460, and I don’t think that the 6man WG should go in that direction. I would prefer to see this section of the draft removed and for RFC 2460bis to state that processing at forwarding nodes MUST NOT alter the length of an IPv6 option or of the extension header in which it resides. Mike Heard