Re: Errata #5933 for RFC8200

Mark Smith <> Thu, 27 February 2020 21:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A550D3A0C0F for <>; Thu, 27 Feb 2020 13:10:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.598
X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qQtokabSQg2t for <>; Thu, 27 Feb 2020 13:10:24 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2BCD63A0BEA for <>; Thu, 27 Feb 2020 13:10:24 -0800 (PST)
Received: by with SMTP id p11so296237plq.10 for <>; Thu, 27 Feb 2020 13:10:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YRQtejIFHdSECE54dnZqjhh3aU3FsVAWTWESoo+JmF4=; b=WasYHhMeh/+RjD0I8gZxJlWgasiwoBhOC5Tqxuo227Dz/2azULAp/i3SaDp7sQ0xdQ OLJCkYRGBDoTGxta8EOIoCgwnWX0HiGFpGsj2WOgmSTOqcLWfcRFiVB+SOGAeISx7vBM HhV5r0Wyze3k8UfovyGBTQOU3L+3QCsEfPqjTIBh3IajrOfHJNBamz82I4EzS5RVDr07 6iL45cVsqraHKLZfjMi6ugOB3uPfXrQq9yW9CQZYB7zWMpqWUw2f0d3Z3wOLuj2JkOVI xb1FjOIlpnzZEhmB3GkaG5eHY8KNZhOH8RBxUMFHMXlOef8As0oNZ1wJl32rR/BjvV92 chdg==
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=YRQtejIFHdSECE54dnZqjhh3aU3FsVAWTWESoo+JmF4=; b=JyU6Lqll+IPGvgqhQKgmJ3EnqDhxb/tQDLx52Mkj45Gvb5rn+wj4XvlMol+80VPskX 2TmTjvBG0gDyRyHrCNyUd78Bn8n24kWmgMVUP5RNr3ybHDqhgRaHgj+N8eS7/elamig4 VI5jaPJzMDfZZJ6BREf3E3B5yVkZ6mE1vG+0afsCw1a9o2bfkidu426s3Jh/l+xLuImF UzONnyGANUQuahdNDJhml88YJF3TQIQ47fozj3meA+8+CuYukJ+HXTqdKlsf1wFf1j+m zck04k4UJe/rSClTxaNLWtcWYSpOSf2KFtOz9Yz0ZrGSzlpkA2yJKHEasIx6BX9BhRZc meHw==
X-Gm-Message-State: APjAAAWA/IdQWwHE++uVLx1lppqR7a03AsmxvYfykiu/Hr3/T6tVWEtN 42tocJHYdIm/J0ZYG5UWcdn1S+IiJMKCjHP7E42fOSCQ
X-Google-Smtp-Source: APXvYqzDqany4YWPghaJQNovywewED5Yc5F4QuWIMscO8eutp4ZC9fJ3WlEKr6xGw3c6KPFaJsiiNuIa9Ew7SFT1750=
X-Received: by 2002:a17:902:bd0a:: with SMTP id p10mr716948pls.198.1582837823563; Thu, 27 Feb 2020 13:10:23 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Mark Smith <>
Date: Fri, 28 Feb 2020 08:09:57 +1100
Message-ID: <>
Subject: Re: Errata #5933 for RFC8200
To: Fernando Gont <>
Cc: Suresh Krishnan <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Feb 2020 21:10:26 -0000

Hi Fernando, Suresh,

On Fri, 28 Feb 2020 at 07:08, Fernando Gont <> wrote:
> 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.

I think this text in the RH section also needs to be updated:

"The Routing header is used by an IPv6 source to list one or more
   intermediate nodes to be "visited" on the way to a packet's
   +*final* destination.  This function is very similar to IPv4's Loose Source
   and Record Route option."

I think this text may also further support which type of destination
is being referred to by the earlier EH text that Fernando is proposing
to clarify:

"Extension headers (except for the Hop-by-Hop Options header) are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node (or each of the set of nodes,
   in the case of multicast) identified in the Destination Address field
   of the IPv6 header."

If this text is implicitly saying that an operation at all is
permitted on EHs when the packet is at the device holding the packet's
DA, intermediate or final in the case of a Routing Header, then I
think it is also saying, due to the "(or each of the set of nodes, in
the case of multicast)" text, that intermediate DAs in an RH can be
multicast addresses.

Would it ever be useful or valid to have an RH that is listing
multicast addresses as the intermediate DAs for the packet to visit?

I think that would also mean that at those intermediate multicast DAs,
if there are downstream interested listeners, the packet would be
duplicated per multicast operations. Are there any applications for
that sort of thing? I think it is a possible packet amplification
attack vector (two intermediate multicast node addresses that point
towards each other could create an amplification loop I think).

If we came to the conclusion that it is impossible or too dangerous
for RH intermediate node DAs to be multicast addresses, and that
intermediate node addresses must be unicast addresses, then I think
that then further clarifies and supports that the earlier EH text -
"Extension headers [...] are not processed, inserted, or deleted [...]
identified in the Destination Address field of the IPv6 header." - is
only referring to the final destination address, not intermediate ones
in an RH, because only final DAs can be multicast addresses.

It might sound a bit like clutching at straws, however the RH text is
unambiguous about intermediate verses final node DAs, and that clarity
helps clarify what type of DA is being referred to in the earlier EH
no insertion, deletion etc. text.


> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail:
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------