Re: [sidr] [Errata Held for Document Update] RFC7115 (4973)

Sandra Murphy <> Mon, 27 March 2017 17:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 80D07127077; Mon, 27 Mar 2017 10:35:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OhB7GZriAXhp; Mon, 27 Mar 2017 10:35:36 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A7DE7124BFA; Mon, 27 Mar 2017 10:35:36 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id D62DB28B003B; Mon, 27 Mar 2017 13:35:35 -0400 (EDT)
Received: from [] (localhost.localdomain []) by (Postfix) with ESMTP id 83C071F8036; Mon, 27 Mar 2017 13:35:35 -0400 (EDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/signed; boundary="Apple-Mail=_04B4C98E-8AE7-4E29-87A4-899CA9A47743"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: Sandra Murphy <>
In-Reply-To: <>
Date: Mon, 27 Mar 2017 13:35:30 -0400
Cc: Sandra Murphy <>, RFC Errata System <>,,,
Message-Id: <>
References: <> <>
To: Randy Bush <>
X-Mailer: Apple Mail (2.2104)
Archived-At: <>
Subject: Re: [sidr] [Errata Held for Document Update] RFC7115 (4973)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Mar 2017 17:35:38 -0000

We’ve run into problems with the RFC5737 documentation examples not being suitable for the types of exampes we needed.

Previously, the suggestion was to put that explanation in the draft, to prevent recurrence of a complaint. e.g.

However, the errata in this case is not posed as a complaint about the failure to use the documentation cases.  The errata says

	666 is not a valid octet for an ipv4 address

That is a true statement.

Randy’s previous response was:

	666 was not accidental.

That is a true statement.

But I believe a  short note to explain the non-accidental use of 666 is something like:

In some cultures, the number 666 is supposed to be the number of “the beast”, i.e. the devil, and therefore a sign of evil.  The text chooses this number 666 in the prefix 10.0.666.0/24 with the intent to imply that the announcement is deliberately evil, disregarding the fact that 666 is not a legitimate ipv4 prefix octet.

Of course, I’m not the author, so I could be wrong.


> On Mar 25, 2017, at 7:36 AM, Randy Bush <> wrote:
>> I am marking this report as "Held for Document Update" [1], which
>> means that the author might consider its merits for a future update.
>> If the use of the "666" octet was intentional, then a short note
>> explaining might be appropriate to avoid further confusion.
> problem is it's not a short note.
>    In the current internet routing ecology, a /24 is the longest prefix
>    which has a good chance at global propagation.  The prefix allocated
>    by RFC 5737, with much verbosity, are three non-contiguous /24s.
>    The result is that documents which want to discuss routable prefixes
>    which involve subnetting can not use space from RFC 5737.  This is a
>    general problem which someone (else) should fix.
>    In RFC 7115, the subject of this erratum, routeable and subnettable
>    examples were needed.  So the well-known private network 10/8, see
>    RFC 1918, was used in the examples.  To indicate that it was not
>    really intended to be used, an impossible octet, 666, was chosen.
> this was explained a number of times as this rfc went through the
> original sausage factory.
> randy
> _______________________________________________
> sidr mailing list