Re: Non routable IPv6 registry proposal

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 21 January 2021 02:08 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 024A03A16A5 for <ietf@ietfa.amsl.com>; Wed, 20 Jan 2021 18:08:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 eImHe7YQRR6D for <ietf@ietfa.amsl.com>; Wed, 20 Jan 2021 18:08:44 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 958B03A16A4 for <ietf@ietf.org>; Wed, 20 Jan 2021 18:08:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9DCD938BA3; Wed, 20 Jan 2021 21:10:42 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id v9KUpo4c2NZa; Wed, 20 Jan 2021 21:10:40 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9493138B69; Wed, 20 Jan 2021 21:10:40 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D15374AB; Wed, 20 Jan 2021 21:08:39 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Phillip Hallam-Baker <phill@hallambaker.com>, Nick Hilliard <nick@foobar.org>, IETF Discussion Mailing List <ietf@ietf.org>
Subject: Re: Non routable IPv6 registry proposal
In-Reply-To: <CAMm+Lwif4fB_kr7F=hR_nzPhESbqk55E2ZF6o51vC3tDmGCfEw@mail.gmail.com>
References: <CAMm+LwjNiE0P7RAVqzKMypNbh3=9BeqiWn_hGv3E=zX7-YmSXQ@mail.gmail.com> <abdac3dd-f601-1fae-8c9f-fbe393930558@foobar.org> <e9a49b69-b629-356b-c33a-4d49794c3e89@gmail.com> <CAMm+Lwh7nQRm=4fLkOKOgQA9L9TS_wh3qSmmV_Ko+N+afDtw+Q@mail.gmail.com> <7f73201d-7f28-92ff-875f-12133e278f94@foobar.org> <CAMm+Lwif4fB_kr7F=hR_nzPhESbqk55E2ZF6o51vC3tDmGCfEw@mail.gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Wed, 20 Jan 2021 21:08:39 -0500
Message-ID: <13999.1611194919@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Vu7Kv296wb3br_YUaSYSRiJLpDY>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jan 2021 02:08:47 -0000

There is a different argument, other than collision rate, for having a
registry.  Whois and reverse DNS.

I have debugged numerous networks where there are leaks of RFC1918 addresses
from other places.  Given a flat multi-city L2 "WAN", it's very difficult to
debug unless you have homogenous equipent with all of that vendor's
management stuff.  Yes, SNMP ought to work, and sometimes it does.

The first time that I was called to debug this, it was because we had just
put one institution on the internet (I'm talking 1994 here).  The default
route injected into the WAN attracted all sorts of packets with wrong source
addresses.  But, it was early, and RFC1918^WRFC1597 wasn't as ubiquitous,
and whois identified the other class Bs that we were seeing.
{how did this happen back in 1994?  common subcontractor ran all those networks on the
same set of T1s, charging each customer for the full fare.   Yes, there was
a lot of embarassed people}

While ULAs and privacy enhanced addresses have important uses for individual
privacy, when it comes to non-moving business/enterprise infrastructure,
audit and accountability is much more important, and ULA-R does not satisfy
that.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide