IETF Logo Mail Archive

Re: [RTG-DIR] Hop-by-hop options [Re: Routing directorate review of draft-ietf-6man-rfc2460bis]

Tom Herbert <tom@herbertland.com> Thu, 02 March 2017 21:36 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E133129674 for <rtg-dir@ietfa.amsl.com>; Thu, 2 Mar 2017 13:36:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
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 CfpiM4JkGwJk for <rtg-dir@ietfa.amsl.com>; Thu, 2 Mar 2017 13:36:39 -0800 (PST)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F2F912967A for <rtg-dir@ietf.org>; Thu, 2 Mar 2017 13:36:38 -0800 (PST)
Received: by mail-qk0-x230.google.com with SMTP id 1so27430906qkl.3 for <rtg-dir@ietf.org>; Thu, 02 Mar 2017 13:36:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wbj4+3nQZOlUvjlj9E1rdHY/CoHAepBEQGTnaZyBhXI=; b=PFGzsTmPuDnHhCD1sYdFZpVUz8nCdJGSQIKJKKN/KTMZB9fLRIiBVlO+ytGGaByWHR D6a7dft+h4gjI4wXYLRbgQNw/3mIAz7bixfbscEsCzpDteRAJPpQmt09kDY9qFRzjBUp VpWyUTlGfAlMwPLH0D/zac2HlyWl/W/EHWbtP3YQJnOFer5eqJ01ZSR8U5S0THBEa6Xt RLPIH4wSSxZr9Imw773tkD8zlr+QhF2fKAYXXil13icq7JrpbUV4x649PmTHPyDm18Yp YvTwSPaQsp92fBVFHitobFvtR8Ajam1gZeB8ZJ0uKqfXoD/j2NZtOZF5G3L1+e2SEuuW YCsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wbj4+3nQZOlUvjlj9E1rdHY/CoHAepBEQGTnaZyBhXI=; b=OSxCj/Jj2KRoMeWF9D1pMXslM8Ep/jhgdrR5aHYpNMut4kFAuKWLwDff+aC0weDXfN djsZBrKHEhdv1SALN+pwV6v7oXjdmfYttzpz0m4UsWZbEJ9R0TAelj6AEpdBNmfIxyAb xSL5ewHHN80t7h+SRU8DJx7Y4zXHyQCMg4KrqkzuP4iwelMThDbrB8OOou5h6/Yml7lm 85ZD2/VIoH/s+RQxE04jZG68pWPU9+93+93Vpdam/TsXW/51nWjk7eh3f0EBryduUtzz tmt+CD4sNwFkJnn2kcYuaNYNtPc9cBpvJRJdR1LP4Th8lb9jeyJ1fUUlskxE6bA7fWep TUoQ==
X-Gm-Message-State: AMke39ny2HgyW16MFIhZkdPl4GbbPgQMdt62swE2fR04iCP+pKZisV8u2hm94D37GAko81rafyyiU0Q6vyhXyQ==
X-Received: by 10.55.7.7 with SMTP id 7mr17744274qkh.228.1488490597056; Thu, 02 Mar 2017 13:36:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.237.55.232 with HTTP; Thu, 2 Mar 2017 13:36:36 -0800 (PST)
In-Reply-To: <6a33c1d3-9a9a-674b-1fc7-a1bc17aafead@gmail.com>
References: <9C5FD3EFA72E1740A3D41BADDE0B461FC61A4621@szxema506-mbs.china.huawei.com> <84675BAA8C49154AB81E2587BE8BDF833D3556AD@FR711WXCHMBA07.zeu.alcatel-lucent.com> <84675BAA8C49154AB81E2587BE8BDF833D36EDAA@FR711WXCHMBA07.zeu.alcatel-lucent.com> <6a33c1d3-9a9a-674b-1fc7-a1bc17aafead@gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 02 Mar 2017 13:36:36 -0800
Message-ID: <CALx6S35DPToXd1eSXckWDmA1tX-xRy_F_jiOcCV5jQw1vA57pA@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/e0n0Msw3Zs6mvHqgxyXIq_KEwo4>
Cc: "rtg-ads@ietf.org" <rtg-ads@ietf.org>, "draft-ietf-6man-rfc2460bis.all@ietf.org" <draft-ietf-6man-rfc2460bis.all@ietf.org>, "Papadimitriou, Dimitri (Nokia - BE)" <dimitri.papadimitriou@nokia-bell-labs.com>, "ipv6@ietf.org" <ipv6@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
Subject: Re: [RTG-DIR] Hop-by-hop options [Re: Routing directorate review of draft-ietf-6man-rfc2460bis]
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Mar 2017 21:36:40 -0000

On Thu, Mar 2, 2017 at 1:25 PM, Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:
> On 03/03/2017 10:02, Papadimitriou, Dimitri (Nokia - BE) wrote:
> ...
>> Section 4.8: states "New hop-by-hop options are not recommended because nodes may be configured to ignore the Hop-by-Hop Option header, drop packets containing a hop-by-hop header" does this configuration change because options are new or old ? there seems to be confusion here between "new vs. existing" options and "intermediate nodes MAY be configured to ignore/drop packets with these options included".
>
> Middleboxes *might* be configured to do something sensible with existing HbH options (such as ignoring them) and something annoying with unknown new ones (such as kicking them to the slow path or dropping the packet). So yes, the situation is worse for new options than for ones that have been defined years ago. But they are both risky.
>
Right, but in the current state of things any EH has proven hard to
successfully deploy in practice. IMO it's more of an implementation
problem that needs to be addressed rather than a protocol
specification problem. If the recommendation is to not create new HBH
options because of this it seems like this affirms protocol
ossification and maybe we've lost the battle!

Tom

v2.23.0 | Report a Bug | By Email