Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard

Mark Smith <markzzzsmith@gmail.com> Mon, 13 February 2017 16:07 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCB21296D3; Mon, 13 Feb 2017 08:07:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.199
X-Spam-Level:
X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 aEy8DDhYRHFX; Mon, 13 Feb 2017 08:07:27 -0800 (PST)
Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (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 C335812951B; Mon, 13 Feb 2017 08:07:26 -0800 (PST)
Received: by mail-vk0-x22f.google.com with SMTP id k127so63415171vke.0; Mon, 13 Feb 2017 08:07:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=UFEs9j4O78SFDwCZ7bMHoMdtvnO6WDPC0ntQjkfN7mE=; b=fQtsXWvl8oBKwbbdgGTS3OpQSepj4CJU/H8TvoqZvkcnIWcfgO7tYek7npZ2gOKmOY pirIAD0fFaIMNk+2rFK9RWrgAhb4Nj04VNOeJhKT7pZxV2o5NvDh0PceaOQFqFevfVj5 +6hrayBD6Tb75xYL9rtpIzgy8YyV8VdKfVJGmtRkjCFupAVRCef14MNTijUdup1Z1KgK IbdUB0daF1RFJLJ7Jthu3tsvqW3+sdFNN2kAkYTz6Ete5DxEVpvSkio4mvKsS4zZSnK2 Mj+bVkN2bskmkteek83IuWbphQOjjvWo9AF3bRV4QSe/0CaRkGwNu6H+XFpProHiCt6t RLOQ==
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=UFEs9j4O78SFDwCZ7bMHoMdtvnO6WDPC0ntQjkfN7mE=; b=W/ljcdOC8VFcImHJDHoJFPBJKZc9oTkSudWe02x6cn/jSmVCtD2jxLlkMU2qaT6SUd 9zFWLa0iEJAnyhS4TUkdJj4SA7GYZpvNiPoDoDKwEHzFdPH4g1/4RgN4MAu0/5sbJD4K Bu6RMtIwRc4OnLNmat7HsaZQwVB/AAmEYhKihawtwbVvaZZ+9WsDCROh/DdNxgnWzUgK lIVBWg0Zl3N4JFnZqHPlwYJ7MndqoFzCaH2dO5BfIsxrR4YsP9GLNut74hGIbBIvDcnL Je5Szi1qzIaNdhOBVQZYbDEBq145IMxe3+x9iywmTqAh0YJZAr3tAij7jZkyc0C9cbR3 jv+g==
X-Gm-Message-State: AMke39mhFy8YXYSj0Prne3lQzCAX4flvrDDrVfnp9lAYP5+Dqd0XnYGxnA68LjtIBQ0x7k7eLVe7nFGmhxbrDQ==
X-Received: by 10.31.54.85 with SMTP id d82mr9524686vka.25.1487002045827; Mon, 13 Feb 2017 08:07:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.33.173 with HTTP; Mon, 13 Feb 2017 08:06:55 -0800 (PST)
In-Reply-To: <67ab3d39d55840c8a207e2104e6020cd@IL-EXCH01.marvell.com>
References: <67ab3d39d55840c8a207e2104e6020cd@IL-EXCH01.marvell.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Tue, 14 Feb 2017 03:06:55 +1100
Message-ID: <CAO42Z2zcc-wCtdbs4VFSu-yWUT0u2PX8r+wpe3Jsj-4vVZUwwg@mail.gmail.com>
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
To: Tal Mizrahi <talmi@marvell.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/vUtl4pI2HM756T0t8e08B1Pj8N4>
Cc: "draft-ietf-6man-rfc2460bis@tools.ietf.org" <draft-ietf-6man-rfc2460bis@tools.ietf.org>, "6man@ietf.org" <6man@ietf.org>, IETF Discussion list <ietf@ietf.org>, "6man-chairs@ietf.org" <6man-chairs@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 13 Feb 2017 16:07:27 -0000

Hi,



On 14 February 2017 at 00:43, Tal Mizrahi <talmi@marvell.com> wrote:
> Hi,
>
>
>
> Good discussion regarding the text about the hop-by-hop extension.
>
>
>
> In my opinion there is a valid use case for intermediate nodes that
> insert/remove/modify/process hop-by-hop extensions. Examples: IOAM, INT.
>
> Since there is a use case, I believe we need explicit text about
> intermediate handling of hop-by-hop extensions.
>


Imagine you sent a letter through the postal system, and the postal
system wanted to add information to that letter, that is then to be
removed before the letter arrives at its final destination.

The postal system have at least two choices as to how to add that
information. They could:

(a) unstick your envelope's seal, insert the information, reseal the
envelope so well you can't tell and send it on its way, some how
flagging to a destination device within the postal system that this
specific envelop needs to be openned, a specific page removed, and
then resealed.

(b) take a new envelope with new internal postal system source and
destination address information, insert your letter without touching
it in addition to the new information, and then sending it on its way.

Imagine that the information to be added by the postal system is
printed on the same type of paper and is written in the same font as
you've chosen to use to write your letter.

Have a think about these two methods, what could fail with each of
them, and what the consequences may be if any of those failures occur.
Have a think of the benefits of each method, and whether they're worth
it compared to the failure mode costs and consequences for the method.

>
>
> This [somewhat] reminds me of the discussion a few years ago about the
> IPv6/UDP zero checksum. The WG ended up defining that “Zero checksum is
> permitted in IPv6/UDP *if* [……..] and the possible consequences are [……..]”.
>
>

That is a far more trivial change to the packet - it is allowing a
value in an existing field that was formerly prohibited, and nodes
that did not understand that value would drop the packet because that
is what they had been specified to do if they received this prohibited
value. In other words, existing implementations ' behaviour when this
formerly unexpected value was encountered had already been specified
and deployed.


>
> I would argue that regarding hop-by-hop extension handling we also need to
> define that “Hop-by-hop extensions can be
> inserted/removed/modified/processed by intermediate nodes *if* [……..] and
> the possible consequences are [……..]”.
>

Some things that are possible to do in theory shouldn't be done in
practice, because the consequences when their implementations fail can
be severe and outweigh the benefits.

In theory, inserted EHs will be removed 100% of the time. In practice
they won't be, because implementations can have bugs and they can also
fail in unexpected ways e.g., hardware faults.

Regards,
Mark.