Re: Non routable IPv6 registry proposal

Nick Hilliard <> Fri, 22 January 2021 14:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9778F3A1302 for <>; Fri, 22 Jan 2021 06:18:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.162
X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id otuW78tfV9YY for <>; Fri, 22 Jan 2021 06:18:35 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 150CB3A11F6 for <>; Fri, 22 Jan 2021 06:18:34 -0800 (PST)
Received: from crumpet.local ( []) (authenticated bits=0) by (8.16.1/8.16.1) with ESMTPSA id 10MEISPH017893 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jan 2021 14:18:28 GMT (envelope-from
X-Authentication-Warning: Host [] claimed to be crumpet.local
Subject: Re: Non routable IPv6 registry proposal
To: Phillip Hallam-Baker <>
Cc: IETF Discussion Mailing List <>
References: <> <> <> <> <> <> <> <> <> <>
From: Nick Hilliard <>
Message-ID: <>
Date: Fri, 22 Jan 2021 14:18:27 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.45
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Jan 2021 14:18:44 -0000

Phillip Hallam-Baker wrote on 22/01/2021 01:13:
> Deregistration cannot take place in my technology model.

this wasn't fully clear either from your previous descriptions.  There's 
plenty of address space to be able to do this sort of thing, but 
building a registry on this basis is a design choice which commits to 
ensuring long-term registry inaccuracy due to inability to perform 
garbage collection.

A traditional registry would normally be designed on the basis of 
providing an accurate mapping between resource and resource holder.  If 
that mapping is broken, then one of the core components of the registry 
function is no longer present.  The ietf would want some fairly 
unambiguous and clearly articulated reasons to justify why this was a 
wise long-term approach to finite resource allocation, and whether the 
term "registry" was applicable.