Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt)

Ted Lemon <> Thu, 07 January 2021 13:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B99C83A1086 for <>; Thu, 7 Jan 2021 05:08:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 8hupmRw9y1IN for <>; Thu, 7 Jan 2021 05:08:14 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8F8D03A1085 for <>; Thu, 7 Jan 2021 05:08:09 -0800 (PST)
Received: by with SMTP id t3so2507716ilh.9 for <>; Thu, 07 Jan 2021 05:08:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=HXOk9zpsltNr56BSv3WdZM/7EMy6eG3cO3azLkmWbzY=; b=s8YRhV7SLLm9qvgFs6GUhYBRTymnT0yIh1Or4NWHi0udhXxcNk1mc3evc4usppEWkl sRfjJ0VcNLjYSHjjnyBiFCHXWPJ6dBIbPOpGcWPHzLdZVHRIRuNJOl+Yv8dOtuIbnOIa Kh/fuD2fH7Xmdg+Vz5n2YNCR9sTzmTz22RDNUFmNXR7BIIFs0kXdoCVab/uKwEjOKNyD xsp/utOsazpAk69scWFLeDimROC+Fq77gvfTyir+vulYcNjB4hMD+JwsD8XmpsIggUhT hClFAKzfON6aXTNfXVJ8dHVUEvHwvhoagZxWGDeSdh/iAwBm+ybgagm8tT1GhuJhjpbQ 6/sA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=HXOk9zpsltNr56BSv3WdZM/7EMy6eG3cO3azLkmWbzY=; b=Yjqa0OyMRa8FhMZ/bkwQqxCGJ1JtfaBFvCkpTCFHulki1NIHhS5KymZbvFAnlmhl+4 61oeyTVIvUDIwptz2enh74FvRiEk38ZuUwX8kxXwuxshEiq98q7L3UD4XPBPT+0D0NdJ 4YcCNt+V1PRiC7xCASk5qIflAzKAifGuX2sf+ihSE1jdp+I3Qm+v+DNRSi9UvKhPv9bT /9lusQnn38XzeFspYW52RTTGfLYHJZtIcJkAmo0/mWuIi7h59yI9rj8Z14IxATX5PN+l ZZ3ZBOW0/2Ocs7KlXmmKrBfWGg4f12fg9iVsipBf/H0ZYiT4p+3eRDATvKRj+s1JVChh 95RQ==
X-Gm-Message-State: AOAM530O80pRBud4cJUC8JC8TrTKfHNotsIOQJvfHCCrqm0IoPnJmMWs OWO7DVxDcv187cc55+56FLkXOA==
X-Google-Smtp-Source: ABdhPJyexQvE2MSBunyO7opsHvBakyZHb+8tHdWd7Tful9L20a26Xbb237Tj1iv9VYJg0zhhQFYVIg==
X-Received: by 2002:a05:6e02:20cc:: with SMTP id 12mr9134824ilq.91.1610024888499; Thu, 07 Jan 2021 05:08:08 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id f20sm4442509ilj.14.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jan 2021 05:08:07 -0800 (PST)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DC93ABDD-F5B5-405A-BCB2-0DC40F61D11C"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Thu, 7 Jan 2021 08:08:05 -0500
In-Reply-To: <>
Cc: IPv6 List <>, IPv6 Operations <>, Mark Andrews <>
To: Philip Homburg <>
References: <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Jan 2021 13:08:18 -0000

On Jan 7, 2021, at 6:49 AM, Philip Homburg <> wrote:
> This looks nice, but I wonder how hard it is for this to get traction.

And for that matter how hard it would be to implement, and what the benefit would be, versus the drawbacks. Most of the time when people do split DNS, it’s because they want information behind the firewall to be invisible globally not so much for operational reasons (because they wouldn’t work) but because they don’t want to reveal the inner workings of the network behind the firewall. So even if this feature Mark’s proposing were widely implemented in host resolvers (which it would have to be to be useful), and even if we had the technology to actually populate this sort of information accurately in the DNS, I think most people who operate DNS servers that could in principle advertise non-global addresses this way would choose not to. So yeah, I’d predict not much uptake.

On Jan 7, 2021, at 6:26 AM, Nick Hilliard <> wrote:
> that ULA is a poor idea to start with, and that attempting to encapsulate its scope characteristics within 1, or 2, or even 3 words is unlikely to succeed in a way which encompasses its full subtlety.  We are better off sticking with a particular phrase (the exact choice of which will end up disappointing some or maybe lots of people) and then defining what that means in free-text.  This seems to be what draft-gont-6man-ipv6-ula-scope is attempting to do.

If you mean “the name ULA is a poor idea” then I would tend to agree, although not vehemently. I definitely agree that trying to mechanically define the scope of a ULA is impossible.

On Jan 6, 2021, at 9:51 PM, Brian E Carpenter <> wrote:
>> I've just checked the most "up to date" textbook that I have at hand on 
>> IPv6. Page 335 has a subsection entitled "Global addresses versus ULAs".
>> The discussion in the textbook is indeed fine.
>> Could one actually make the case that e.g. Python's library should 
>> change? If it did, it would be counter intuitive. It would match 
>> RFC4193/4291, but not RFC4007, e.g. the textbook I've checked, and the 
>> intuitive meaning of private/global.
> That's of course exactly why the term "globally reachable" was added
> by RFC8190. My objection to the Python library is not that it provides
> the property .is_private, which is very clear, but that it asserts that
> ipaddress.IPv6Address("fd63:45eb:dc14:0:8546:6ab7:1529:b435").is_global
> is False. Because according to the Proposed Standard RFCs,
> ULAs are both private and global.
> Unfortunately I don't think it's reasonable to ask for a non-backwards-
> compatible change in the Python library. If you were maintaining such
> a widely used library, would you want to break compatibility?

I’d be really curious to know how this is used, and whether it works. I suspect it works poorly, and hence backwards compatibility is not an issue, but without knowing how it’s actually used, who can really say? What does my code do if is_global is false? If it is true? Is it possible that because of this library, connections that could be made aren’t being made, because a valid, usable address is being ignored?