Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

Tom Herbert <> Thu, 27 February 2020 22:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C4F703A0D5D for <>; Thu, 27 Feb 2020 14:07:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hv7koIBFZHri for <>; Thu, 27 Feb 2020 14:07:47 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E27653A0D5A for <>; Thu, 27 Feb 2020 14:07:46 -0800 (PST)
Received: by with SMTP id v28so873751edw.12 for <>; Thu, 27 Feb 2020 14:07:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gtaCzPNatFatNGHtsYfFZYlBn7leRTn7/ueo3rL75aY=; b=eNB7IMlgdv+a9c/Q61OOnTUBHiF+wn2K+09q9tipWQ+nuDYpFUgJOVXOW/eT5IWKLN bl6+8TXd99/5g+kzFgBOGdof6CKI0zHOCJ0OBpEeJl8solw01jwdRMndEzmpVW/Jkc1N Qz3hZu1+LpxZYjZnxu/sQ94LEHhj6QLESNLPbPRd0UiiDpLEecWau1sTmMwols7dnW+R W5N50Me/z4Elkk/TWy3l5Go8QvwuXPQzQ8SEvaiC/3QCCmytckubAnFFe7qXf+ecuuwL o6DhO9jbkg5wGk87QWT63kH3vxJ4a7UjIchBJUokPgbHldfgX3bZ4xvWiJiG6Wxe4pzX QaAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gtaCzPNatFatNGHtsYfFZYlBn7leRTn7/ueo3rL75aY=; b=IZgQaZAiaLZsb4r0TwOJXo5MsnO8yhiV4Dqdo6BLwNUFVtfPtbrKFQkeRT41O9K5Ky 6StYw1WvvLcF56JsSaTyIFz2/bO5SjIS07Bbs5dLUDNzgWz8H/uIgjTT3zt//6Ognhlo 1dAQ8iNy6958e+iDx3JmYRymEG6VdFEo0JFkT5hnQrbjj29TmWtRD5lI9CIiX6qzdh6F uP6R7qqgcce+Ir7u5B3bqdLCBTbpoKcsm93drgbz45nfmLOwi15fQRndS6u7fkCLwAV4 nju/LeTUcnlS46DHAKYGCnX1a7M8Qnz0Buv8Z0IoIX6X8O4esoahlBjZSeP94zb5Q8U3 2JRA==
X-Gm-Message-State: APjAAAVtJtB9zh1OMtZZeHnvrcmcfV5t1NmB1N8dn9Ffw7g4HGLaW3CA ybEmlE7xl8oKHW605wpfQNIhX9373pCemG3uQipGMw==
X-Google-Smtp-Source: APXvYqw1WBrsgdCUzoDt9RClPlKtOlzkEg0VekjqRvuv+jC8U015UnBEnCWX+a6pzHyqeB2B4mbIwWUuITwXOWVNNe4=
X-Received: by 2002:a17:906:4b10:: with SMTP id y16mr1080440eju.304.1582841265095; Thu, 27 Feb 2020 14:07:45 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Thu, 27 Feb 2020 14:07:33 -0800
Message-ID: <>
To: Fernando Gont <>
Cc: "" <>, Internet Architecture Board <>, Internet Area <>,
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Feb 2020 22:07:50 -0000


I think we need to be careful that IETF is labeled as a collection of
inflexible architectural purists. We know that standards conformance
is voluntary and we haven't seen the last time that someone, possibly
even a major vendor, will circumvent the system for their own
purposes. IMO extension header insertion is a great example of that.
On one hand we have people quoting IPv6 saying that it isn't allowed
per RFC8200-- period! And on other side there are proponents that see
a real need for it and believe they have clear use case-- at one
presentation in IETF a proponent bluntly stated that regardless of any
discussion in IETF they're going to do it! IMO, what we haven't seen,
was a real attempt to resolve and work out the engineering issues.
That's not for lack of trying-- for instance I proposed a direction to
try for an engineering compromise in draft-herbert-6man-eh-attrib-00,
but saw little discussion on that.


On Thu, Feb 27, 2020 at 1:43 PM Fernando Gont <> wrote:
> Folks,
> If you haven't been following recent developments in the Spring WG, you
> may be surprised about some of the work that is being pursued (or was
> being pursued)-
> Such work has included proposing that some IPv6 routers insert and
> remove routing headers en-route to the final destination.
> After many very heated and lengthy debates, some of this work was
> dropped, but other remains (e.g. routers removing IPv6 EHs from packets
> en-route to their final destination, part of what they call "PSP"). For
> the most part, the proponents have argued that "we have implemented it,
> and the industry wants it" -- as if we just have to rubberstamp what
> they have done.
> On the technical side, the proponents have argued that:
>      If a packet employs source routing (and hence its Destination
>      Address is modified en-route to direct the packet through each
>      of these "waypoints"), then any of such "waypoint" routers are
>      free to add or remove IPv6 extension headers at will. (No, not
>      encap/decap, but rather add/remove EHs from the IPv6 header
>      chain).
> That seems to me like a very major deviation from what's supposed to be
> our current "architecture", where IPv6 is an end to end protocol.
> Besides, it should be obvious that removal/insertion of EHs en-route
> error reporting (since host typically check that the ICMP errors they
> receive correspond to something that they actually sent).
> A number of us have raised this a number of times, and at least some of
> us feel that our concerns are being ignored.
> It would seem to me that these documents and decisions have a concrete
> impact on our architecture, and that they are being pursued without any
> proper oversight. There is also a widespread feeling that having one or
> a few big vendors pushing these ideas might be playing a role here.
> (See, for instance:
> *
> *
> )
> What I would expect is that all thes major changes to our existing
> architecture and protocols would only done by formally updating existing
> standards *if* deemed appropriate, as opposed to just trying to sneak
> changes "when nobody is watching", or by having very curious
> interpretations of our protocols and standards.
> I've raised the topic to our AD (Suresh), to the IAB, and on the arch-d
> list before, but so far haven't been lucky or seen anything meaningful
> happen in this area.
> I have also submitted an errata to make RFC8200 even more clear on the
> topic, but it remains unprocessed.
> So my questions are:
> * On the technical area:
>   + Is IPv6 an End To End protocol?  Or is the IETF's stance that
> routers are free to mangle with the packet structure as they please?
>   + Was IPv6 designed that way? And if it wasn't, when/how was the
> architecture changed?
> * On the procedural area:
>    + Where/how should IETF WGs seek for architecture-related advice?
>    + What do do in situations like the above?  Wait and see how things
>      evolve, and upon any formal decisions, just submit formal Appeals
>      if deemed necessary?  (and after way too much energy consumed from
>      everyone)
>      I would have expected that as soon as these issues were raised,
>      the offending text would be removed rightaway. But that wasn't
>      the case. And when the changes did happen, it wasn't without
>      an extraordinary waste of time and energy from all of us.
>      For instance, any work on IPv6 header insertion/deletion wouldn't
>      seem to fit within the charters of the 6man or spring wgs.
>      FWIW, this is not the first instance of issues surrounding the same
>      topic. It goes back to the rfc2460bis effort, when a similar set of
>      folks (too many from one big vendor) got to have 6man ship
>      what became RFC8200 with a noted "ambiguity", just to be able
>      to have some playground for EH insertion/deletion. And we only got
>      to improve on that during IETF LC:
>     (see:
> Thoughts or advice on the technical and/or procedural aspects will be
> appreciated.
> Thanks!
> Cheers,
> Fernando
> -------- Forwarded Message --------
> Subject: Errata #5933 for RFC8200
> Date: Thu, 27 Feb 2020 17:07:36 -0300
> From: Fernando Gont <>
> To: Suresh Krishnan <>
> CC: <>
> Suresh,
> Two months ago I filled an errata on RFC8200 regarding the processing of
> IPv6 extension headers. The errata is available here:
> While I believe that folks with a knowledge of Internet Protocols would
> be able to interpret what is in RFC8200, given recent discussions on the
> topic, and upon a re-read of the text, I believe a clarification is
> warranted, such that we allow all sorts of curious interpretations of
> the text.
> I send a heads-up on the 6man mailing list
> (,
> and the proposed text received the review of at least Brian Carpenter,
> Ron Bonica, and Mark Smith. Their reviews are available on such thread.
> In the light that some folks seem to be pretending to leverage "the lack
> of clarify" in RFC8200 (an Internet Standard) to violate it, I'd
> appreciate that the reported errata be processed.
> Processing the aforementioned errata is key to many of the discussions
> this and other WGs are having.
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail:
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> _______________________________________________
> Int-area mailing list