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

[Ted Lemon <[e-mail]>]

On Jan 7, 2021, at 6:49 AM, Philip Homburg <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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?