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

From: Fernando Gont <[email-masked]>
Date: Tue, 5 Jan 2021 22:20:55 -0300

Folks,

Based on the recent discussion on the v6ops list 
(https://mailarchive.ietf.org/arch/msg/v6ops/b7r35HgOb-6dfxsDoW8c4FtGnZo//), 
I've posted this new I-D, meant to discuss the scope of ULAs:

Title: "Scope of Unique Local IPv6 Unicast Addresses"
I-D: https://tools.ietf.org/id/draft-gont-6man-ipv6-ula-scope-00.txt

Short version of the story:

ULAs are formally part of the GUA space. However, the characteristics of 
ULAs do not seem to match the definition of global scope from RFC4007 
(IPv6 Scope Addr Architecture). ULA seem to have a scope of 
scope(link-local) < scope(ULA) < scope(GUA).

This is not only a terminology thing (which I think is nevertheless 
important to get right) but also has practical implications. For 
example, there's a python library that considers ULAs as "not global", 
and "private" -- contradicting the current RFC4291/RFC4193 specs.

Prior to posting this document, we had some on-list discussion (on the 
v6ops list) and also some off-list discussion with some of you (bcc'ed).

The opinions have been in one of these camps:

1) the current specs are coherent and there's no problem

2) There's a problem with the definition of "global scope" -- so ULAs 
*are* global scope, but global scope does not really stand for the 
definition in RFC4007.

3) The definitions in RFC4007 are correct, and thus the scope of ULAs is 
not really global, but scopee(link-local) < scope(ULAs) < scope(global)

While this document does propose a way out (it assumes #3 above, and 
acts accordingly), I believe the first step is to agree on what "global 
scope" means and, subsequently, whether ULAs are really "global scope" 
or not. Since opinions on the topic have vary a lot (as noted above), 
I've posted this I-D and I'm sending this note for further input from 
the WG.

Thanks!

Regards,
Fernando

-------- Forwarded Message --------
Subject: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt
Date: Tue, 05 Jan 2021 17:02:20 -0800
From: [email-masked]
To: Fernando Gont <[email-masked]>

A new version of I-D, draft-gont-6man-ipv6-ula-scope-00.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:		draft-gont-6man-ipv6-ula-scope
Revision:	00
Title:		Scope of Unique Local IPv6 Unicast Addresses
Document date:	2021-01-05
Group:		Individual Submission
Pages:		8
URL: 
https://www.ietf.org/archive/id/draft-gont-6man-ipv6-ula-scope-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-gont-6man-ipv6-ula-scope/
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-gont-6man-ipv6-ula-scope
Htmlized: 
https://tools.ietf.org/html/draft-gont-6man-ipv6-ula-scope-00

Abstract:
    Unique Local IPv6 Unicast Addresses (ULAs) are formally part of the
    IPv6 Global Unicast address space.  However, the semantics of ULAs
    clearly contradict the definition of "global scope".  This document
    discusses the why the terminology employed for the specification of
    ULAs is problematic, along with some practical consequences of the
    current specification of ULAs.  Finally, it formally updates RFC4291
    and RFC4193 such that the scope of ULAs is defined as "local".

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Mark Smith <[email-masked]>
Date: Wed, 6 Jan 2021 13:00:36 +1100

> not really global, but scopee(link-local) < scope(ULAs) < scope(global)

The thing that is really missing from "global scope" is what scope or
domain is being described? Forwarding scope? Uniqueness scope? Some other
scope (DNS visibility is probably another one). All of them?

ULAs are intended to be globally unique addresses, but not to be globally
(Internet) forwardable. Their forwarding scope is limited to non-global,
either within a single local network, or between a set of local networks
that have agreed to forward their respective ULA /48 prefixes between each
other, overriding the default of local networks only forwarding scope.
(Ethernet addresses are a similar example, globally unique addresses, link
only forwarding scope.)

GUAs also are intended to be globally unique addresses, but are intended to
be globally (Internet) forwardable.

There isn't really a ULA equivalent in IPv4, although I think a lot of the
arguments in RFC1627, "Network 10 Considered Harmful (Some Practices
Shouldn't be Codified)" would have been arguments for one e.g, "The lesson
that we learned was that every IP address ought to be globally unique,
independent of its attachment to the Internet." (There is a statement about
effectively everything attached to the Internet too, however that's 1994
Internet naivety, before DDoSes and Internet wide scanning for and
exploiting of vulnerabilities were much of a thing.)

Regards,
Mark.

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 5 Jan 2021 23:44:49 -0300

Hi, Mark,

Thanks a lot for your comments! In-line....

On 5/1/21 23:00, Mark Smith wrote:
[...]
> domain is being described? Forwarding scope? Uniqueness scope? Some 
> other scope (DNS visibility is probably another one). All of them?

FWIW, the definition of "scope" as per RFC4007 has to do with being able 
to being able to uniquely identify an interface. i.e., "uniqueness" from 
your list.

As such, forwarding scope should always be smaller than that (i.e., 
address: where the thing is, route: how to get there).

> ULAs are intended to be globally unique addresses, but not to be 
> globally (Internet) forwardable.

The math in RFC4193 for "uniqueness" considers *only a reduced number of 
uLA-based networks being inter-connected*. So, when computing global 
uniqueness, you should consider *all ULA prefixes in use*, not just 
those of networks you are interconnecting. And when you do that, you get 
a very high probability of collisions (~1).

> Their forwarding scope is limited to 
> non-global, either within a single local network, or between a set of 
> local networks that have agreed to forward their respective ULA /48 
> prefixes between each other, overriding the default of local networks 
> only forwarding scope. (Ethernet addresses are a similar example, 
> globally unique addresses, link only forwarding scope.)

Not really: Ethernet Addresses (when "U/L" bit set) are centrally 
assigned. When not set, they only have local significance, and are not 
globally unique.  The analogy is that ULAs are like local Ethernet 
addresses, whereas ULA-C would be similar to Universal/global Ethernet 
addresses.

> GUAs also are intended to be globally unique addresses, but are intended 
> to be globally (Internet) forwardable.

The birthday paradox tells you that with a 40-bit Global ID, you cannot 
really expect ULA prefixes to be globally-unique.

> There isn't really a ULA equivalent in IPv4,

ULAs are the equivalent of RFC1918, with the addition of:

1) More bits for the addresses (both the prefix, subnet id, and 
interface ID)

2) A requirement to generate ULA prefixes from a PRNG -- something that 
wouldn't have made sense for RFC1918, anyway, because you only have a 
limited number of bits for the addresses.

> although I think a lot of 
> the arguments in RFC1627, "Network 10 Considered Harmful (Some Practices 
> Shouldn't be Codified)" would have been arguments for one e.g, "The 
> lesson that we learned was that every IP address ought to be globally 
> unique, independent of its attachment to the Internet." 

How could you possibly achieve that without a central registry, and only 
40 bits (think birthday paradox)?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: David Farmer <[email-masked]>
Date: Tue, 5 Jan 2021 22:38:09 -0600

I think this is the right direction the previous draft indirectly defined a
new scope "non-global", I much prefer explicitly defining a new local scope.

I would add something like the following to better define the relationship
between the three scopes;

The boundary of the link-local scope is strongly defined, limiting the
extent of the link-local scope to an individual link. However, in contrast,
the boundary of the local scope is weakly defined, it is amorphous and
imprecise. In some instances, the extent of the local scope can be a single
site, in other instances, a group of unrelated sites, a single
organization, or even a cooperating group of organizations. Furthermore,
the extent of an individual instance of the local scope doesn't necessarily
remain constant, it may expand or contract over time as the local situation
dictates, for example when two organizations merge. Nevertheless, the
extent of the local scope doesn’t encompass the entirety of the Internet
which the global scope does.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Wed, 6 Jan 2021 04:45:21 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Fernando Gont

This is getting unnecessarily complicated, IMO. ULAs are more than just link-local, because an administrative domain, such as even an enterprise net, can use them, throughout that network. Within such a domain, the top /48 can be guaranteed to be unique, because the same admin computes those 40 random Global ID bits. Not so? Such as, use the same PRNG, document the seed, then pick your five random bytes to use for each site, from the long random sequence.

Now you can organize that enterprise net into separate /48 networks, or for that matter, even link various geo-separated sites, through tunnels, where each site gets one or more of those random /48 prefixes. The important point being, only route inside that enterprise, and use a consistent method to compute the Global ID bits.

I just object to equating this with link-local. It's way more than that.

Bert

---

From: Fernando Gont <[email-masked]>
Date: Wed, 6 Jan 2021 02:10:13 -0300

Hello, Bert,

On 6/1/21 01:45, Manfredi (US), Albert E wrote:
> -----Original Message----- From: ipv6 <[email-masked]> On
> Behalf Of Fernando Gont
> 
> those of networks you are interconnecting. And when you do that, you
> get a very high probability of collisions (~1).
> 
> This is getting unnecessarily complicated, IMO. ULAs are more than
> just link-local, 

Indeed, my draft argues that the scope of ULAs is larger than that of 
link-locals. They key point is that it also argues that scope(ULAs) < 
scope(GUAs).

> because an administrative domain, such as even an
> enterprise net, can use them, throughout that network. Within such a
> domain, the top /48 can be guaranteed to be unique,

How could you possibly guaranteed that if you're selecting the ULA 
prefix with a PRNG? Probabilities don't buy you any guarantees, except 
if P=1 or P=0, which is clearly not the case here.

Additionally, there's a difference between "the ULA prefix is 
probabilistically unique if you connect a limited number of networks" -- 
which is the math in Section 3.2.3 of RFC4193 -- versus being globally 
unique, which implies that the ULA prefix is unique among or ULA-based 
networks, whether you interconnected them or not.

> because the same
> admin computes those 40 random Global ID bits. Not so? Such as, use
> the same PRNG, document the seed, then pick your five random bytes to
> use for each site, from the long random sequence.

RFC4193 does not mandate a specific algorithm, but rather specified the 
requirements for the PRNG (good for the RFC4193 authors!). So, 
documenting the seed will serve no purpose, because other 
implementations might use a completely different algorithm for 
generating the ULA prefix.

> Now you can organize that enterprise net into separate /48 networks,
> or for that matter, even link various geo-separated sites, through
> tunnels, where each site gets one or more of those random /48
> prefixes. The important point being, only route inside that
> enterprise, 

This one seems, already, an indication of prefixes being non-global.

> and use a consistent method to compute the Global ID bits.

An this one is obviously non-enforceable, for multiple reasons, 
including the fact that RFC4193 doesn't mandate any specific algorithm.

> I just object to equating this with link-local. It's way more than

I don't think anybody has equated ULAs with link-locals. The argument 
has been, instead, that: scope(link-local) < scope(ULA) < scope(GUA)

In a way, the expectation of ULAs to be global-scope is probably what 
drove the recent discussion on the 6man list about a ULA registry -- 
which yes, is probably the only way in which ULAs could actually be GUAs 
(except that unless you can enforce the use of such registry, having a 
non-enforceable partial registry won't make the ULA prefixes global scope).

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 6 Jan 2021 02:28:36 -0300

Hello, David,

Thanks a lot for your feedback! In-line....

On 6/1/21 01:38, David Farmer wrote:
> I think this is the right direction the previous draft indirectly 
> defined a new scope "non-global", I much prefer explicitly defining a 
> new local scope.

Good point.

> I would add something like the following to better define the 
> relationship between the three scopes;
> 
>     The boundary of the link-local scope is strongly defined, limiting
>     the extent of the link-local scope to an individual link. However,
>     in contrast, the boundary of the local scope is weakly defined, it
>     is amorphous and imprecise. In some instances, the extent of the
>     local scope can be a single site, in other instances, a group of
>     unrelated sites, a single organization, or even a cooperating group
>     of organizations. Furthermore, the extent of an individual instance
>     of the local scope doesn't necessarily remain constant, it may
>     expand or contract over time as the local situation dictates, for
>     example when two organizations merge. 

Following the terminology in RFC4007, I wonder if this last bit should 
be expressed as:
"the extent of an individual instantiation of a local scope (i.e., a 
zone), does not necessarily remain constant..."?

>     Nevertheless, the extent of
>     the local scope doesn’t encompass the entirety of the Internet which
>     the global scope does.

A remaining item to figure out here is:

According to RFC4007, you can't have to instantiations of the same 
scope. One way to analyze this is

1) that this doesn't apply to ULAs, or,

2) That it's impossible to tell the specific extent of a local scope. As 
a result, all instantiations of local scopes are considered to be 
different zones, and hence you are free to have as many instantiations 
of "local scope" as you wish.

(RFC4007 defines "zone" to be an instantiation of "scope").

Thoughts?

Thanks!

Regards,

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Wed, 6 Jan 2021 05:53:45 +0000

Hi Fernando, let's follow the KISS principle.

-----Original Message-----
From: Fernando Gont <[email-masked]> 

Within an enterprise, the admin has a choice of which PRNG to use, and what seed to use. Think in terms of one guy, making that decision, and then documenting all the Global ID 40-bit sequences in use, in the various nets of the enterprise. The guy with this responsibility can certainly decide on which algorithm to use!

It is easy enough to guarantee uniqueness, in this case.

I am the enterprise admin, I'm tasked with administering the ULAs for the enterprise, and I enforce the rule. The admin of one enterprise network has no say in what other admins, of other enterprise networks, want to do. Nor is there any requirement for ULAs of different enterprise nets to be mutually unique.

Something like "single administrative domain scope," if that existed, makes sense to me. I think the problem is that today, it's either link local or global scope?

To me, that's a different discussion. That registry idea would probably be a necessity, but only for the fc00::/8 ULAs, which are for future use. When ULAs are not assigned by an individual admin, the problem of uniqueness is different, no? To me, that registry problem is a non-issue, unless and until we start using the fc00::/8 addresses. As of now, only fd00::/8 are being discussed.

Bert

---

From: Fernando Gont <[email-masked]>
Date: Wed, 6 Jan 2021 03:32:32 -0300

Hi, Bert,

> Hi Fernando, let's follow the KISS principle.

KISS *and* real, please ;-)

> -----Original Message----- From: Fernando Gont
> <[email-masked]>
> 
> Within an enterprise, the admin has a choice of which PRNG to use,
> and what seed to use. Think in terms of one guy, making that
> decision, and then documenting all the Global ID 40-bit sequences in
> use, in the various nets of the enterprise. The guy with this
> responsibility can certainly decide on which algorithm to use!
> 

Please do the math.

Being able to connect a few networks together does not mean the addreses
are unique. You can't normally connect  several 10.0.0.0/8 nets, too.

Global-scope, as per RFC4007 would imply that *the ULA prefixes are
globally unique*. *All, at the same time*.

> I am the enterprise admin, I'm tasked with administering the ULAs for
> the enterprise, and I enforce the rule. The admin of one enterprise
> network has no say in what other admins, of other enterprise
> networks, want to do. Nor is there any requirement for ULAs of
> different enterprise nets to be mutually unique.

Indeed, "global scope" would imply exactly that. Please check my I-D, 
which quotes the relevant text from RFC4193.

> Something like "single administrative domain scope," if that existed,
> makes sense to me. I think the problem is that today, it's either
> link local or global scope?

Exactly!  ULAs are not link-local, but not "global", either. They have a 
scope that lies somewhere in between link-local and global.

In my I-D, I called the ULA scope "local", but I don't mind changing 
that to "single administrative domain scope", "private scope", or 
anything else.

The point is, indeed, that ULAs are currently defined as global. BUt 
they are not -- their scope is certainly smaller than global.

> To me, that's a different discussion. That registry idea would
> probably be a necessity, but only for the fc00::/8 ULAs, which are
> for future use. When ULAs are not assigned by an individual admin,
> the problem of uniqueness is different, no? 

Indeed. When they are not centrally assigned, or not assigned by the 
same admin, you cannot expect them to be unique across different 
administrative domains. You can expect the probability of collisions 
*when interconnecting a reduced number of ULA-based networks* to be 
small.  But you can certainly not expect the ULA prefixes to be unique 
at a global scale. when you consider ~1M networks (not a big deal if you 
e.g. expect that each home will generate a ULA prefix) you actually have 
almost certainty that there's a collision.

> To me, that registry
> problem is a non-issue, unless and until we start using the fc00::/8
> addresses. As of now, only fd00::/8 are being discussed.

To me, it's also a non issue. But it looks like the proposal for a 
registry has been motivated by the expectation of ULAs being *globally 
unique* (as opposed to "unlikely to collide if you interconnect a 
handful of ULA-based networks").

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 6 Jan 2021 16:07:51 +0900

> (Ethernet addresses are a similar example, globally unique addresses, link

IMO defining ULAs as they are was a mistake. Global scope implies unique.
But probabilistic uniqueness doesn't work because humans choose ULAs
instead of generating them manually. Registry-based uniqueness doesn't work
(and, to be fair, was never tried by the IETF) because there is no registry
that has jurisdiction. Even if there were, there is no reason to keep
addresses unique if they don't have global reachability.

So I guess I'm somewhere between 1) and 3). The specs are consistent but
they fail to consider human behaviour, so they don't actually work in
practice. I don't know what to do about this though. If we say they're
non-global scope, then they are going to be the exact equivalent of RFC1918
addresses, with all the problems that that causes. If we continue to say
they're global scope, then the specs don't match reality. :-(

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 6 Jan 2021 02:30:31 -0500

On Wed, Jan 6, 2021 at 2:09 AM Lorenzo Colitti
<lorenzo=[email-masked]> wrote:
>> ULAs are intended to be globally unique addresses, but not to be globally (Internet) forwardable. Their forwarding scope is limited to non-global, either within a single local network, or between a set of local networks that have agreed to forward their respective ULA /48 prefixes between each other, overriding the default of local networks only forwarding scope. (Ethernet addresses are a similar example, globally unique addresses, link only forwarding scope.)
>
>
> IMO defining ULAs as they are was a mistake. Global scope implies unique. But probabilistic uniqueness doesn't work because humans choose ULAs instead of generating them manually. Registry-based uniqueness doesn't work (and, to be fair, was never tried by the IETF) because there is no registry that has jurisdiction. Even if there were, there is no reason to keep addresses unique if they don't have global reachability.
>
> So I guess I'm somewhere between 1) and 3). The specs are consistent but they fail to consider human behaviour, so they don't actually work in practice. I don't know what to do about this though. If we say they're non-global scope, then they are going to be the exact equivalent of RFC1918 addresses, with all the problems that that causes. If we continue to say they're global scope, then the specs don't match reality. :-(

option 4, deprecate ULA.
the best option (tm).

---

From: Fernando Gont <[email-masked]>
Date: Wed, 6 Jan 2021 04:38:23 -0300

On 6/1/21 04:07, Lorenzo Colitti wrote:
> On Wed, Jan 6, 2021 at 11:01 AM Mark Smith <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     globally (Internet) forwardable. Their forwarding scope is limited
>     to non-global, either within a single local network, or between a
>     set of local networks that have agreed to forward their respective
>     ULA /48 prefixes between each other, overriding the default of local
>     networks only forwarding scope. (Ethernet addresses are a similar
>     example, globally unique addresses, link only forwarding scope.)
> 
> 
> IMO defining ULAs as they are was a mistake. Global scope implies 
> unique. But probabilistic uniqueness doesn't work because humans choose 
> ULAs instead of generating them manually.

Not only that. At a global scale, the Birthday problem tells you that 
the ULA prefixes will also be non-unique. ~1.2M of house-hods generating 
their ULA prefixes already gives you P~1 that you have a collision at 
the global level. Indeed, the math in 
https://tools.ietf.org/html/rfc4193#section-3.2.3 already implicitly 
acknowledges this fact, because the probability of collision is computed 
on the basis of how many networks you interconnect -- that's certainly 
not what "global scope" means.

> Registry-based uniqueness 
> doesn't work (and, to be fair, was never tried by the IETF) because 
> there is no registry that has jurisdiction. Even if there were, there is 
> no reason to keep addresses unique if they don't have global reachability.

Fully agreed.

> practice.

If you look at the definition of scope and global scope from RFC4007, 
it's inconsistent with employing it for defining ULAs as global.

(Indeed, the *L* in ULA says it all ;-) )

> I don't know what to do about this though. If we say they're 
> non-global scope, then they are going to be the exact equivalent of 
> RFC1918 addresses, with all the problems that that causes. If we 
> continue to say they're global scope, then the specs don't match 
> reality. :-(

One can say that they are local scope, with the expectation that since 
the ULA prefix is meant to be randomly generated, then sites that comply 
with such requirement will have a small probability of prefix collisions 
if two ULA-based sites were to be merged/interconnected.

I think that's as real and factually correct as it can get.

Besides, this also means that libraries such as ipaddress match the 
specs. -- right now, they don't. And it would be hard to argue that 
libraries such as Python's ipaddress should be changed such that ULAs 
are flagged as both "global" and "public". -- something that would not 
only be wrong, but that can also not be done in a backwards compatible 
manner.  Also, if apps, for some reason, are checking such address 
attributes, it's certainly better that the attributes are set in an 
intuitive way (the current one, which doesn't match the specs), in the 
hopes that they can make something useful out of differentiating IPv6 
address properties.

Thanks,

---

From: Mark Smith <[email-masked]>
Date: Wed, 6 Jan 2021 19:16:27 +1100

On Wed, 6 Jan 2021, 18:30 Christopher Morrow, <[email-masked]>
wrote:

> globally (Internet) forwardable. Their forwarding scope is limited to
> non-global, either within a single local network, or between a set of local
> networks that have agreed to forward their respective ULA /48 prefixes
> between each other, overriding the default of local networks only
> forwarding scope. (Ethernet addresses are a similar example, globally
> unique addresses, link only forwarding scope.)
> >
> >
> ULAs instead of generating them manually. Registry-based uniqueness doesn't
> work (and, to be fair, was never tried by the IETF) because there is no
> registry that has jurisdiction. Even if there were, there is no reason to
> keep addresses unique if they don't have global reachability.
> >

If you want to destroy IPv6 by causing enterprises to replicate RFC1918s
via site-locals and use NAT66, do that.

ULAs exist because site-locals would have created that problem.

People are already deploying ULAs mostly correctly - I know of 4
electricity smart meter networks that have more than 2 million meters
attached that are using ULA addressing. The only relatively minor mistake
made was that the smartmeter vendor took the 4 network's ULA spaces out of
a single /48, using /52s if I recall correctly, rather than generating a
/48 for each one.

While probably prohibited by government, if any if those networks merged,
routing between them will be as simple as linking them together and trading
/52 routes.

If they'd used site-locals, merging would instead be either as complex as
renumbering, or as bad as NAT66, the latter being most likely.

---

From: Gert Doering <[email-masked]>
Date: Wed, 6 Jan 2021 11:54:45 +0100

Hi,

On Wed, Jan 06, 2021 at 04:07:51PM +0900, Lorenzo Colitti wrote:
> Registry-based uniqueness doesn't work
> that has jurisdiction. 

ULA-C was abandoned.  But that could be revived...

Find a registry is not hard.  Anyone could be the registry, if IETF gives
their blessing and says "there's a machine that spits out a guaranteeed 
unique ULA /48s for each $20 you feed in"...

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Jan 2021 07:17:33 -0500

On Jan 5, 2021, at 11:38 PM, David Farmer <farmer=[email-masked]> wrote:
> I think this is the right direction the previous draft indirectly defined a new scope "non-global", I much prefer explicitly defining a new local scope.

Actually, I think you’ve got it right here: the scope is “non-global.”

> I would add something like the following to better define the relationship between the three scopes;
> 
> The boundary of the link-local scope is strongly defined, limiting the extent of the link-local scope to an individual link. However, in contrast, the boundary of the local scope is weakly defined, it is amorphous and imprecise. In some instances, the extent of the local scope can be a single site, in other instances, a group of unrelated sites, a single organization, or even a cooperating group of organizations. Furthermore, the extent of an individual instance of the local scope doesn't necessarily remain constant, it may expand or contract over time as the local situation dictates, for example when two organizations merge. Nevertheless, the extent of the local scope doesn’t encompass the entirety of the Internet which the global scope does.

There is at least one obvious problem with this definition: the term “local.” ULAs aren’t really local, despite the name. Using the name “local” is what leads to this confusion. Consider this taxonomy:

GUA: “valid everywhere on the internet scope”
ULA: “not valid everywhere scope”
LLA: “valid only on this link scope”

Of course these names are awkward, but I hope they are clarifying. A ULA is “not valid everywhere.” That’s really all you can say about it. You can’t put a ULA prefix in a global routing domain. You can put it in a site routing domain. You can put it in a multi-site routing domain. You can not route it at all. All these uses are valid.

So I don’t really object to your text, but I do object to the name “local.” How about “explicit”? That is, the scope of a ULA is explicit, in the sense that it must be _made_ explicit by the user(s) of the ULA? If that doesn’t work, I’m sure we can come up with a more agreeable term, but please let it not be “local.” Sorry to be a sticky wicket. :)

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Jan 2021 07:33:12 -0500

> the best option (tm).

If that were an option, we wouldn’t be having this argument—nobody would care about ULAs. ULAs are a good idea. The terminology around them needs work, that’s all. 

For example, we use ULAs in the HomePod Mini to route between adjacent network links where IPv6 GUA delegation isn’t available. The ULA never winds up in the global routing topology. The Mini chooses it using a secure RNG, so the likelihood of collision is vanishingly small. ULAs are _much_ more flexible than RFC1918 addresses, simply by virtue of the process by which the /48 prefix is chosen.

I would have major wibbles about using RFC1918 addresses in the Mini the way we currently use ULAs, because we’d have (at best!) eight bits of randomness, and a strong likelihood of collisions with competing private network uses of the 10.0/8 space. Because ULA is specific about each prefix being a /48, and because a /48 is most likely enough for most use cases, the worries about this sort of collision are nonexistent: nobody is going to allocate the whole ULA space to a single site, and if they do, we can legitimately say that they are at fault for things not working.

We can’t and shouldn’t deprecate ULAs. I think clarifying what the name means makes sense, though, and perhaps the term should be CUA (collision-unlikely address) prefix rather than ULA prefix.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 6 Jan 2021 08:47:23 -0300

> unique ULA /48s for each $20 you feed in"...

Given what seems to be the fee for a /48 (not to mention that you can 
also get a /48 for free), not sure if such a registry would ever be 
attractive.

Anyway, that would still leave as with ULAs, as currently specified, 
marked as "global scope"...

Thanks,

---

From: Richard Patterson <[email-masked]>
Date: Wed, 6 Jan 2021 12:46:31 +0000

> the best option (tm).

Strongly disagree.
I think defining a new scope for ULA is a good idea and will help to
demystify and improve their use in the real world.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 06 Jan 2021 14:45:43 +0100

>I've posted this I-D and I'm sending this note for further input from 

In my opinion we should leave scope the way it is. Scope has a specific
meaning for link local. In the past we tried to define local scope similar
to how link-local scope is defined and it failed.

'local' scope is an operational reality. You don't see it at the protocol
level. So we need to keep it clearly separate from link-local where we do have
quite a bit of protocol and API specification.

If I look at the problem statement in this draft, the issue seems to be that
ULAs may not work if you connect two networks that independently picked ULAs.
It is at all clear to me how giving ULAs a 'non-global' label would change
any of that.

I'm not sure this is a relevant problem. Locally anybody can make sure their 
ULAs have enough randomness. This results in a failure chance when connecting
to other networks of one in 2^40. Of all the operational problems you can
get when connecting two networks, this seems to be a very remote one.
I doubt that we can solve all operational problems that have a chance of one in
2^40 of happening.

Of cource with badly chosen ULAs, then chance is higher. But then again, does
calling ULAs 'local' solve anything?

I don't see an immediate technical problem with ULAs, certainly not one that
needs to be addressed with a standards track document.

A practical point that is mentioned in Section 5.1 is what to call ULAs.
For example, we could call them 'private'. I think there is a need to
the group of addresses that includes both rfc1918 and ULA. A short
informational draft that addresses that point could be useful.

The main technical problem is that happens if you want to connect two
networks that both use ULAs. However, in my opinion this requires operational
guidance. I.e., use ULA if you expect to never connect to another network.
Use ULA if in the one in 2^40 chance of a collision you can renumber.
Do not use ULAs for security purposes, that will come back to bite you.

---

From: John Kristoff <[email-masked]>
Date: Wed, 6 Jan 2021 08:19:26 -0600

On Wed, 6 Jan 2021 11:54:45 +0100

> unique ULA /48s for each $20 you feed in"...

This reminds me of IEEE OUIs.  You would want a price high enough that
would provide some disincentive to having anyone and everyone
registering for one or multiple assignments just because they can.  In
addition, not every one or every organization will want to publicly
listed in a registry. akin to LAAs, I don't have a strong opinion on
the matter, but a prefix for locally assigned addresses aren't all bad
until they either leak or must join another network that may have
conflicting practices.  That seems like an operational problem that can
be dealt with in a fairly straightforward way.

John

---

From: Fernando Gont <[email-masked]>
Date: Wed, 6 Jan 2021 11:04:43 -0300

Hi, Ted,

On 6/1/21 09:17, Ted Lemon wrote:
> On Jan 5, 2021, at 11:38 PM, David Farmer 
> <farmer=[email-masked] 
> <mailto:farmer=[email-masked]>> wrote:

Indeed. But then, link-locals are non-global, too.

>>     unrelated sites, a single organization, or even a cooperating
>>     group of organizations. Furthermore, the extent of an individual
>>     instance of the local scope doesn't necessarily remain constant,
>>     it may expand or contract over time as the local situation
>>     dictates, for example when two organizations merge. Nevertheless,
>>     the extent of the local scope doesn’t encompass the entirety of
>>     the Internet which the global scope does.
> 
> There is at least one obvious problem with this definition: the term 
> “local.” ULAs aren’t really local, despite the name. 

FWIW, I suggested "local" as the scope as given the "L" in "ULA", it was 
the obvious choice. I don't mind using any other term. What really 
matters is to use consistent terminology.

So I guess possible options (other than "local scope") are:

* private scope?
* organizational scope?
* administrative scope?

> So I don’t really object to your text, but I do object to the name 
> “local.” How about “explicit”? That is, the scope of a ULA is explicit, 
> in the sense that it must be _made_ explicit by the user(s) of the ULA? 

mm.. not really. As a user of ULAs, it's impossible to tell if the scope 
ends up being just one link (think a CPE that locally generates a ULA 
prefix and advertises it in the only internal net/link), or multisite.

If not "local" or "explicit", maybe one of the others suggestions above 
would work?

Thanks!

Regards,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 6 Jan 2021 11:26:57 -0300

Hi, Philip,

On 6/1/21 10:45, Philip Homburg wrote:
[...]
> In my opinion we should leave scope the way it is. 

The current definition of global scope as per RFC4007 doesn't match the 
definition of ULAs as being global scope. Both of them can't be right.

> Scope has a specific

"scope" and "zone" are part of the architecture. So we have a IPv6 
Scoped Addressing Architecture, and then a definition ULAs that doesn't 
really comply with that definition.

[...]
> calling ULAs 'local' solve anything?

Changing the formal scope of ULAs does change the expectation when it 
comes to their usage: i.e., ULAs are not expected to be globally unique. 
They are just expected to have small chances of collision if you 
connected a limited number of ULA-based networks.

Besides, this does have an impact on current libraries (such as Python's 
ipaddress) and other libraries or macros that may have been defined for 
other languages, or that may be defined in the future.

This in turn probably affects the use such apps make of a list of 
addresses, when more than one is available.

> informational draft that addresses that point could be useful.

The problem is that for ULAs to be marked as "non-global" (whatever we 
call that), RFC4291 needs to be updated. Also, at least a part of 
RFC4193 needs to be updated.

Thanks,

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Jan 2021 09:36:54 -0500

On Jan 6, 2021, at 9:04 AM, Fernando Gont <[email-masked]> wrote:
> If not "local" or "explicit", maybe one of the others suggestions above would work?

“private” isn’t bad.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 06 Jan 2021 16:13:31 +0100

>definition of ULAs as being global scope. Both of them can't be right.

Some things don't need fixing even if they are not 100% correct.

Yes, we can define global scope (in the context of unicast) as anything that
is not link-local. And that would be nice for a bis document. But why
bother?

>really comply with that definition.

Effectively we have only two scopes: link-local and 'other'. What we need to
do is simply things, not create a bigger mess.

We don't need zone IDs that try to identify the scope of a ULA. All of this
was part of attempts to define local addresses. It didn't work.

We need to redefine zone IDs as interface IDs and clean up a lot of that
stuff.

(It is possible that multicast is different, I haven't done multicast beyond
a single subnet for ages)

>connected a limited number of ULA-based networks.

Networks don't just connect by themselves. Networks admins who connect two
networks are not going the read RFC 4007 and conclude from the definition of
scope that is safe to connect the networks.

People also connect RFC 1918 networks and have to deal with the consequences.
This is why operational documents could help.

>other languages, or that may be defined in the future.

The IETF does not define APIs for Python libraries, so I don't see why we would
need to change the scope of ULA to accomodate them.

We could call ULA 'private' if that would help python devs. But they can just
well call ULA 'private' without involving the IETF.

>addresses, when more than one is available.

Applications should not do widely different things if they encouter a ULA.

We have policy tables for source and destination address selection. Those
should be used to decide what to do. 

>RFC4193 needs to be updated.

They don't need to be marked 'non-global'. Changing the scope of ULA serves
no purpose.

---

From: Richard Patterson <[email-masked]>
Date: Wed, 6 Jan 2021 15:29:47 +0000

> Applications should not do widely different things if they encouter a ULA.
But they do.
Some OSes will see the presence of a ULA address on an interface, and start
sending AAAA queries, some will not.
Some applications will see a ULA destination address and simply ignore it,
preferring the IPv4 destination address returned.

We need to ask the question why this is happening, and if the answer is
"They're doing it wrong", great, let's point them at the existing RFCs and
educate them, but if not...... we need to do something, and I think this
I-D is a good starting point for WG discussion at least.

> should be used to decide what to do.

As above, it's not just about simple routing table lookups, or source
address selection. But I do also think there's room for improvement here as
well, with a new scope for ULA.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 6 Jan 2021 12:42:13 -0300

> Some things don't need fixing even if they are not 100% correct.

There's an architecture document, and a spec that doesn't follow it.

That's a bug. I don't know if that means 45% correct or 95.4% correct. 
But it does mean that we have defined terms, and that we don't use them 
in a consistent manner.

If we expect people to read our specs, and make sense out of them, we 
have fix them if we find issues.

And, as noted, there are concrete implications:
RFC4007 says ULAs are non-global, RFC4193 says that ULAs are global, and 
a Python library says ULAs are non-global. I don't think we want that.

> We need to redefine zone IDs as interface IDs and clean up a lot of that

You mean use interface IDs as zone IDs?

> scope that is safe to connect the networks.

It must be clear what ULAs are, and what they are not. Part of that is 
acknowledging that their scope is not global.

[...]
> need to change the scope of ULA to accomodate them.

You seem to be missing my original point:
The definition of ULAs as "global scope" contradicts the definition of 
"global scope" from RFC4007.

We don't need to change the scope of ULAs to accommodate them. We need 
to change the scope of ULAs such that we don't have specs that 
contradict with each other (consistency). Most likely, when we have 
that, we'll end up accommodating the Python library as a side effect.
They got it right, and we didn't.

> well call ULA 'private' without involving the IETF.

So.. from the pov of RFC4007 ULAs are non-global.
 From the pov of RFC4193 ULAs are global.

... and you don't mean to fix that, but still expect devolopers from 
multiple languages to get that right, and programmers to make sense out 
of the outcome?

> should be used to decide what to do.

That's a "one size fits all". There are valid reasons for which you 
mihgt *not* want to do that, (including using ULAs for services that are 
expected to be local-only, not binding temporary addresses to listening 
sockets, etc., etc., etc.)

> They don't need to be marked 'non-global'. Changing the scope of ULA serves

So what we do here is specifying protocols, and you argue that fixing 
inconsistencies when specs have conflicting definitions and usages serve 
no purpose?

Me, that's the least I'd expect from us....

---

From: Fernando Gont <[email-masked]>
Date: Wed, 6 Jan 2021 12:45:18 -0300

On 6/1/21 12:29, Richard Patterson wrote:
> On Wed, 6 Jan 2021 at 15:14, Philip Homburg 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
> 

And good for them that they do. The ones that don't are the ones that 
end up e.g. posting ULAs and link-locals on the public-facing DNS.

(I've had to do it myself when using dynamic DNS updates, for instance)

Cheers,

---

From: Philip Homburg <[email-masked]>
Date: Wed, 06 Jan 2021 16:52:12 +0100

>I-D is a good starting point for WG discussion at least.

This I-D doesn't seem to list anything that goes wrong in applications, 
let alone how applications are following the specs and getting it wrong.

So I don't see how this I-D helps.

We have a clear policy table for source and destination selection. I don't
see anything in the draft that suggests that the table is wrong.

---

From: Gert Doering <[email-masked]>
Date: Wed, 6 Jan 2021 16:56:42 +0100

Hi,

On Wed, Jan 06, 2021 at 07:17:33AM -0500, Ted Lemon wrote:
> Actually, I think you???ve got it right here: the scope is ???non-global.???

Indeed.  This sounds like a nice way to express the intended usage.

"It is not link-local, but definitely not intended or usable for global
usage, thus: 'non-global scope'"

Gert Doering
        -- NetMaster

---

From: Fernando Gont <[email-masked]>
Date: Wed, 6 Jan 2021 12:57:21 -0300

> let alone how applications are following the specs and getting it wrong.

Isn't it clear enough that the definition of ULAs as "global scope" 
contradicts the definition of global scope from RFC4007?

That, from starters, needs to be fixed.

Any library or macro that follows the definition of ULAs as being 
"global scope" will lead to ULAs leaking out of their zone, as e.g., 
posting them in the DNS. Because they are defined as "global scope", 
when they are not.

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Wed, 6 Jan 2021 13:01:59 -0300

> usage, thus: 'non-global scope'"

The only issue with using this term (non-global) is that it also applies 
to link-locals...

---

From: Philip Homburg <[email-masked]>
Date: Wed, 06 Jan 2021 17:13:50 +0100

>a Python library says ULAs are non-global. I don't think we want that.

RFC 4007 does not mention ULA. I don't see why python libraries are
relevant for what we do.

>You mean use interface IDs as zone IDs?

No, rewrite RFC 4007 and get rid of zone IDs. And the introduce interface IDs
to select the interface of an outgoing packet, whether link-local or global.

It doesn't change anything in practice, because that is what existing code
does.

>acknowledging that their scope is not global.

ULAs are not link-local addressses. That's the only thing we need to know.

Yes, we could update the definition of global scope in RFC 4007 such that
ULAs are included, but it strikes me as a waste of time. Unless, we are doing
a bis document.

>They got it right, and we didn't.

Like I said, the definition of global scope in RFC 4007 can be fixed if we
would care enough. 

>multiple languages to get that right, and programmers to make sense out 

Developers should not use scope to mean anything. Maybe some applications
need to do something special when they encouter certain addresses. In that
case they can directly list the prefixes that need special treatment.

There is no need to come up with convoluted library schemes that try to
classify addresses. That only causes operational nightmares.

>sockets, etc., etc., etc.)

Do you propose to introduce new scopes for temporary addresses?

The I-D we are discussion doesn't describe these issues in the problem
statement.

Maybe you want to go back to the problem statement and describe what you
really want to solve.

---

From: Gert Doering <[email-masked]>
Date: Wed, 6 Jan 2021 17:26:52 +0100

HI,

> a Python library says ULAs are non-global. I don't think we want that.

On a tangent, I wonder why this is relevant at all.

Why should applications, or anything that is not an admin, care if an
address is a ULA or a GUA?

(I can see the bit about "tools that enter GUAs in the global DNS",
but this is very special anyway - because "DNS" might not be "global",
so general "refuse to put ULA into DNS" is not correct behaviour either)

Consistent terminology is important, true, and if we just want to make
sure that something can properly flag a ULA different than a GUA, we
could just introduce

  "mid-range scoped"

or rename the scopes to be 0 (link-local), 5 (mid-range), 10 (global)...

Gert Doering
        -- NetMaster

---

From: Fernando Gont <[email-masked]>
Date: Wed, 6 Jan 2021 13:36:10 -0300

On 6/1/21 13:13, Philip Homburg wrote:
> RFC 4007 does not mention ULA. 

RFC4007 defines what "scope" and "global scope" are.

RFC4193 defines ULAs to be global scope.

But ULAs (defined in RFC4193 as global scope) contradict the definition 
of global scope from RFC4007.

Hence the connection between the two.

> to select the interface of an outgoing packet, whether link-local or global.

At the end of the day, when you do that, the interface is being employed 
as the zone ID.

> ULAs are not link-local addressses. That's the only thing we need to know.

*That is not how they are specified in RFC4193*!

[...]
> Like I said, the definition of global scope in RFC 4007 can be fixed if we

It's the definition of ULAs as global scope that is incorrect. NOt the 
other way around.

> case they can directly list the prefixes that need special treatment.

Applications should deal with prefixes. If anything, they should deal 
with address properties.

> classify addresses. That only causes operational nightmares.

You get operational nightmares when you get multi-scoped addresses and 
you have no clue about the differences and what to do with them.

Crawl Alexa's Top-1M sites, and look at the IPv6 addresses. You find 
anything from loopback, to unspecified address, to link-locals, and ULAs.

> Do you propose to introduce new scopes for temporary addresses?

Huh?

I'm saying:
"There are valid reasons for which you mihgt *not* want to do that, 
(including using ULAs for services that are expected to be local-only, 
not binding temporary addresses to listening sockets, etc., etc., etc.)"

that is: given a bunch of addresses with different properties, most 
likely applications do need to look at their properties to make 
appropriate use for them.

We're talking about the ULA scope being in contradiction with the 
"global scope definition".

> The I-D we are discussion doesn't describe these issues in the problem

Problem #1:
The IETF publishes protocol specifications.
We have two protocol specifications that contradict each other.

Someone that reads both RFC4007 and RFC4193 will have an interesting WTH 
moments. For the rest of the stuff, I said it already. THere's no point 
in re-hashing the same arguments over and over again.

---- cut here ----
5.1.  Address Attributes in Programming Languages

    Python's ipaddress library [Python-ipaddr] defines 'IPv6Address'
    objects that have a number of attributes, including:

    o  'True' if the address is allocated for private networks.

    o  'True' if the address is allocated for public networks.

    For ULAs, the is_private attribute is 'True', while the is_global
    attribute is 'False'.  This contradicts the definition of ULAs as
    having "global scope" [RFC4291] [RFC4193], but is in line with the
    specification update performed by this document (see Section 6).
---- cut here ----

This will be faced by every other library or macro in every other language.

---- cut here ----
6.  Specification Updates

    The ultimate goal is to employ coherent terminology and definitions
    throughout the relevant protocol specifications.  Probably the only
    option to achieve this goal is update the definition of ULAs as
    having "local scope", with "local scope" defined as "larger than
    link-local, and smaller than global" (based on ULAs being defined as
    "local addresses").
---- cut here ----

The least we can aim at is consistency among our own specs, right?

... and one should also add to the list "a clarification of the 
expectations regarding ULAs. Because many (including myself in the very 
recent past) had the assumption that ULAs are globally-unique, when they 
are not.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 6 Jan 2021 13:46:51 -0300

Hi, Gert,

> address is a ULA or a GUA?

I can report on my own case:

I have Raspberry Pis that deploy here and there. In order to be able to 
access them, they use dynamic DNS to post their addresses on their DNS.
If I don't look at the properties of the addresses, then I end up puting 
crap on the DNS. One straightforward consequence is that many apps that 
don't do Happy Eyeballs end up having an insane connection-establishment 
period, if they happen to try the unusable addresses first.

So "find all your IPv6 addresses and post them to the DNS" doesn't work.

> so general "refuse to put ULA into DNS" is not correct behaviour either)

What I do is:
For each node, I have one domain name for global addresses, and another 
for non-globals.

> or rename the scopes to be 0 (link-local), 5 (mid-range), 10 (global)...

Any of those options are totally fine. The point is that ULAs don't have 
the "global scope" properties described in RFC4007.

It is not acceptable to have folks that do their homework and read 
RFC4291/RFC4007, and then read other documents and are left scratching 
their heads.

If we can't fix specs when we have inconsistencies, I don't think we can 
expect people to make sense out of them.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Jan 2021 12:06:39 -0500

On Jan 6, 2021, at 11:26 AM, Gert Doering <[email-masked]> wrote:
> or rename the scopes to be 0 (link-local), 5 (mid-range), 10 (global)…

This implies concentric circles, which isn’t really valid. Different ULAs can have disjoint or overlapping applicability. I agree with a previous comment that talking about this in terms of scope doesn’t make much sense. I don’t know how to write code that takes into account the difference in scope between ULA and GUA, other than perhaps in routing protocols.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Jan 2021 12:10:26 -0500

On Jan 6, 2021, at 11:46 AM, Fernando Gont <[email-masked]> wrote:
> I have Raspberry Pis that deploy here and there. In order to be able to access them, they use dynamic DNS to post their addresses on their DNS.
> If I don't look at the properties of the addresses, then I end up puting crap on the DNS. One straightforward consequence is that many apps that don't do Happy Eyeballs end up having an insane connection-establishment period, if they happen to try the unusable addresses first.
> 

It is of course not even obvious how to solve this, because sometimes you do want ULA in DNS, and sometimes you don’t. And it depends on what DNS. If you are doing split DNS, then you can scope the DNS that advertises ULAs only to serve those networks where those ULAs are in-scope. The DNS that is advertised globally would of course contain no ULAs. How this is arranged is either a matter of local configuration or an interesting topic of future work, depending on how you look at it.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 Jan 2021 12:11:32 -0500

> If I don't look at the properties of the addresses, then I end up puting crap
    > on the DNS. One straightforward consequence is that many apps that don't do
    > Happy Eyeballs end up having an insane connection-establishment period, if
    > they happen to try the unusable addresses first.

    > So "find all your IPv6 addresses and post them to the DNS" doesn't work.

And, yet, for the case where some device is doing dynamic DNS update to a DNS
server that is within some ULA scope, posting the ULA to the DNS is actually
correct.
But, it's hard to know that without knowing what clients are expected to connect.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Jan 2021 12:20:54 -0500

> But, it's hard to know that without knowing what clients are expected to connect.

It seems straightforward that the client should send all the addresses it wants to advertise, and the DNS server should decide which ones to advertise in what scopes.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 6 Jan 2021 14:26:56 -0300

On 6/1/21 14:06, Ted Lemon wrote:
> On Jan 6, 2021, at 11:26 AM, Gert Doering <[email-masked] 
> <mailto:[email-masked]>> wrote:
> This implies concentric circles, which isn’t really valid. Different 
> ULAs can have disjoint or overlapping applicability. I agree with a 
> previous comment that talking about this in terms of scope doesn’t make 
> much sense. I don’t know how to write code that takes into account the 
> difference in scope between ULA and GUA, other than perhaps in routing 
> protocols.

e.g., for thinks like mDNS, you'd only bind() and listen on your ULAs, 
if any.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Jan 2021 12:33:00 -0500

On Jan 6, 2021, at 12:26 PM, Fernando Gont <[email-masked]> wrote:
> e.g., for thinks like mDNS, you'd only bind() and listen on your ULAs, if any.

mDNS is link-local, so you can actually use your LLA for that (and we do). But e.g. if you are using SRP (https://tools.ietf.org/html/draft-ietf-dnssd-srp-07), then it makes sense to push your GUA and your ULA and bind to both, or to INADDR_ANY (if you want to be globally reachable). I would expect the SRP server to do the work of figuring out on which DNS server to publish the ULA and on which to publish the GUA.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 Jan 2021 12:48:51 -0500

Ted Lemon <[email-masked]> wrote:
    > It is of course not even obvious how to solve this, because sometimes
    > you do want ULA in DNS, and sometimes you don’t. And it depends on what
    > DNS.
    > If you are doing split DNS, then you can scope the DNS that
    > advertises ULAs only to serve those networks where those ULAs are
    > in-scope.

Ideally.... but that's a lot of policy stuff to put into DNS.
I think that geolocated answers in DNS is already a bad thing.
We should be using a better anycast.

    > The DNS that is advertised globally would of course contain
    > no ULAs.

I'm not sure that I agree!  I think that ULAs often do belong.

There are potentially many GUA (2000::/3) addresses that could be in DNS,
which would not work for some originators due to ACLs, and yet a different
entry might work just fine.  Why would ULA be any different?

I think that happy eyeballs and source address selection ought to cut out
many possibilities.
It's just too bad that libcurl doesn't implement Happy Eyeballs...
     {ideally in a system-wide, privacy-preserving, maybe even LAN-wide
     [RFC2186-like] way}

(I also lament shim6, but feel that MPTCP and QUIC might give us something
equivalent.  Again... anycast)

    > How this is arranged is either a matter of local configuration
    > or an interesting topic of future work, depending on how you look at
    > it.

Also, is this an operational or architectural issue?

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 Jan 2021 12:51:11 -0500

> It seems straightforward that the client should send all the addresses
    > it wants to advertise, and the DNS server should decide which ones to
    > advertise in what scopes.

Ideally, yes.
If you ask from ULA xyz, and there is a ULA xyz answer, then clearly it
should be included.

But... caching and outsourcing of DNS servers and outsourcing of DNS resolvers.
I hate all of that: except for simpler (IoT) devices, which should always use
local DNS server to get local policy,  all this policy should be in the
client, not the server.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Jan 2021 13:04:30 -0500

> entry might work just fine.  Why would ULA be any different?

The usual case here would be through a VPN; in that case the VPN will specify some set of domains that should be resolved through the VPN’s name servers. You really don’t want the ULA advertised globally.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Jan 2021 13:08:59 -0500

> local DNS server to get local policy,  all this policy should be in the

Okay, if that’s possible, sure, but the way to do that sort of policy would be to say what server to contact for what domain. The VPN example is just one example; you could certainly also do this without a VPN. It’s pretty easy to do on the Mac—just add a scoped DNS resolver; not sure how hard it is on Linux.

The thing is, though, that somebody has to provide the intelligence to decide either who to ask or what address to use. I think that by default you should never see a ULA other than from the local resolver, because there’s just no way for someone who _doesn’t_ know that ULA to know whether it would work or not. So if there are some domains that you want treated specially, the easiest way to do that is to have a different resolver for those domains (a scoped resolver).

---

From: Fernando Gont <[email-masked]>
Date: Wed, 6 Jan 2021 14:34:13 -0300

On 6/1/21 14:10, Ted Lemon wrote:
> On Jan 6, 2021, at 11:46 AM, Fernando Gont <[email-masked] 
> <mailto:[email-masked]>> wrote:
>> I have Raspberry Pis that deploy here and there. In order to be able 
>> to access them, they use dynamic DNS to post their addresses on their DNS.
>> If I don't look at the properties of the addresses, then I end up 
>> puting crap on the DNS. One straightforward consequence is that many 
>> apps that don't do Happy Eyeballs end up having an insane 
>> connection-establishment period, if they happen to try the unusable 
>> addresses first.
>>
> DNS. If you are doing split DNS, then you can scope the DNS that 
> in-scope. The DNS that is advertised globally would of course contain no 
> ULAs. How this is arranged is either a matter of local configuration or 
> an interesting topic of future work, depending on how you look at it.

What I do is set up to different names. e.g.:

node.mydomain,com  for the global addresses, and,
node-local.mydomain.com for the non-global addresses.

In the case of apps that are expected to be available only to local 
nodes (e.g., mDNS) the daemon might want to explicitly bind() a ULA, 
rather than bind() the wildcard "address". So the app gets an extra 
layer of isolation as a result of the address scope. And probably also 
gets more stability, since in most cases the ULA prefix will be 
generated by the local router and thus be stable, while the global 
prefix may end up being dynamic.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 6 Jan 2021 14:35:29 -0300

On 6/1/21 14:20, Ted Lemon wrote:
> On Jan 6, 2021, at 12:11 PM, Michael Richardson <[email-masked] 
> <mailto:[email-masked]>> wrote:

FWIW, I didn't find that magic in BIND (even if it's there), so I had to 
deal with it on the client side.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 6 Jan 2021 14:46:04 -0300

On 6/1/21 14:33, Ted Lemon wrote:
> On Jan 6, 2021, at 12:26 PM, Fernando Gont <[email-masked] 
> mDNS is link-local, so you can actually use your LLA for that (and we 
> do). 

The problem with link-locals is that having to specify the "zone id" 
with the "Addr%iface" thing at times is nto friendly with some apps.

> But e.g. if you are using SRP 
> (https://tools.ietf.org/html/draft-ietf-dnssd-srp-07), then it makes 
> sense to push your GUA and your ULA and bind to both, or to INADDR_ANY 
> (if you want to be globally reachable). I would expect the SRP server to 
> do the work of figuring out on which DNS server to publish the ULA and 
> on which to publish the GUA.

... in which case the server would have to be able to infer address 
properties, using macros or libraries such as the one in 
https://tools.ietf.org/html/draft-gont-6man-ipv6-ula-scope-00#section-5.1

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Wed, 6 Jan 2021 19:04:21 +0000

From: ipv6 <[email-masked]> On Behalf Of Richard Patterson

>> On Wed, 6 Jan 2021 at 07:31, Christopher Morrow <mailto:[email-masked]> wrote:
>>
>> option 4, deprecate ULA.
>> the best option (tm).
>
> Strongly disagree.
> I think defining a new scope for ULA is a good idea and will help to demystify and improve their use in the real world.

+1. Emphatically. And, the same would also apply to RFC 1918.

Bert

---

From: Mark Smith <[email-masked]>
Date: Thu, 7 Jan 2021 06:46:22 +1100

> Actually, I think you’ve got it right here: the scope is “non-global.”

I

> So I don’t really object to your text, but I do object to the name “local.” How about “explicit”? That is, the scope of a ULA is explicit, in the sense that it must be _made_ explicit by the user(s…

I think "local" is close to, if not the right word.

I consider anything that is non-global or smaller than global to be "local".

I think "local" is a word that has the word's user's perspective and
the context of its use as part of its semantics. The perspective and
context defines what the "local" domain boundary is, and it is
possible that different people might have different definitions,
although they'll probably be pretty similar. People have their own
local perspective on the definition of the word "local" ;-)

When I'm at home, my "local" network is my home network.

When I'm at work, my "local" network is the ISP I work at's network. I
don't consider our customers' home networks "local" though, even
though they're all part of the network with the same AS number.

Some examples of "local" outside of networking.

I go for walks around my local neighbourhood. I ride my bike around
the local neighbourhood. As I can ride further than I can walk, my
local neighbourhood in the context of being on my bike is a greater
geographical area than my local neighbourhood when I walk.

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 7 Jan 2021 10:30:35 +1300

Portmanteau reply to multiple messages:

On 06-Jan-21 20:07, Lorenzo Colitti wrote:
...
> So I guess I'm somewhere between 1) and 3). The specs are consistent but they fail to consider human behaviour, so they don't actually work in practice.

I disagree. They work fine in practice.  The smart meter example is a good one. The ANIMA autonomic control plane is another. My TV has a ULA address. I have no idea whether it's used when I control it from my Android phone, because address selection does its job.

The problem is largely theoretical, and educational for people who train IPv4 users in IPv6 terminology and practices. As Fernando has pointed out, the use of the word "global" is confusing for something that has L for "local" in its name.

On 06-Jan-21 20:30, Christopher Morrow wrote:
...
> the best option (tm).

I can't see the least argument for that (no proven damage) and very strong arguments against (running code and operational deployments).

On 07-Jan-21 01:17, Ted Lemon wrote:
...
> LLA: “valid only on this link scope”

Friendly amendment:

GUA: valid everywhere
ULA: Unique Limited-domain Address
LLA: valid only on this link

("scope" is really a noise word, and "Internet" is too restrictive.)

On 07-Jan-21 02:45, Philip Homburg wrote:
...
> quite a bit of protocol and API specification.

That's why using "scope" is a noise word. It isn't an abstract property. Try to draw it and you get a mess. This really hasn't changed since https://tools.ietf.org/html/rfc3879. Or see https://www.cs.auckland.ac.nz/~brian/scope6.pdf.

On 07-Jan-21 04:13, Philip Homburg wrote:
...
> Some things don't need fixing even if they are not 100% correct.

+1

On 07-Jan-21 04:29, Richard Patterson wrote:
> Some OSes will see the presence of a ULA address on an interface, and start sending AAAA queries, some will not.
> Some applications will see a ULA destination address and simply ignore it, preferring the IPv4 destination address returned. 
> 
> We need to ask the question why this is happening, and if the answer is "They're doing it wrong", great, let's point them at the existing RFCs and educate them, but if not...... we need to do something, and I think this I-D is a good starting point for WG discussion at least.

FYI, we tried 6 years ago, but draft-ietf-v6ops-ula-usage-recommendations stalled.

On 07-Jan-21 05:13, Philip Homburg wrote:
...
> to select the interface of an outgoing packet, whether link-local or global.

Effectively that's what RFC3879 did. RFC4007 was a bit behind the curve. As far as I know, zone IDs and interface IDs are exactly equivalent (at least in POSIX and WinSock environments). IMHO this is *only* a terminology question.

> It doesn't change anything in practice, because that is what existing code

Really? Using the interface ID for non-link-local addresses?

On 07-Jan-21 05:26, Gert Doering wrote:
...
> address is a ULA or a GUA?

It depends on what you mean by "application". I've written code that explicitly prefers a ULA, and I could imagine a security spec saying "prefer ULA". But anyway, it's not really a problem, is it? (It's annoying to me that in Python, a ULA has .is_global == False, but I managed to code round that error.)

On 07-Jan-21 06:06, Ted Lemon wrote:
...
> This implies concentric circles, which isn’t really valid.

It really, really, really isn't valid. That's where we went wrong in 1995. Once the mid-range scopes start to overlap, the concentric circles model fails completely. That's the main reason we scrapped site-local.

On 07-Jan-21 07:04, Ted Lemon wrote:
...
> The usual case here would be through a VPN; in that case the VPN will specify some set of domains that should be resolved through the VPN’s name servers. You really don’t want the ULA advertised gl…

But neither do you want private-use 2000::/3 addresses advertised globally. I really don't see a difference between RIR-assigned and self-assigned (ULA) prefixes in this respect.

Regards
    Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 6 Jan 2021 19:23:49 -0300

On 6/1/21 18:30, Brian E Carpenter wrote:
> On 06-Jan-21 20:07, Lorenzo Colitti wrote: ...
>> So I guess I'm somewhere between 1) and 3). The specs are
>> consistent but they fail to consider human behaviour, so they don't
>> actually work in practice.
> 
[...]
> 
> The problem is largely theoretical, and educational for people who
> train IPv4 users in IPv6 terminology and practices. As Fernando has
> pointed out, the use of the word "global" is confusing for something
> that has L for "local" in its name.

There is indeed a terminology issue, which ends up making it complicated 
to explain e.g. the concept of "scope" as a result.

> On 07-Jan-21 01:17, Ted Lemon wrote: ...
>> GUA: “valid everywhere on the internet scope” ULA: “not valid
>> everywhere scope” LLA: “valid only on this link scope”
> 
> Friendly amendment:
> 
> GUA: valid everywhere ULA: Unique Limited-domain Address LLA: valid
> only on this link

Would certainly also work.

> On 07-Jan-21 04:13, Philip Homburg wrote: ...

My take is that if the topics is confusing for us, we cannot expect it 
to be any better for others.

> On 07-Jan-21 05:26, Gert Doering wrote: ...
>> Why should applications, or anything that is not an admin, care if
>> an address is a ULA or a GUA?
> 
> It depends on what you mean by "application". I've written code that
> explicitly prefers a ULA, and I could imagine a security spec saying
> "prefer ULA". But anyway, it's not really a problem, is it? (It's
> annoying to me that in Python, a ULA has .is_global == False, but I
> managed to code round that error.)

The question is: Is it an error?

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.

FWIW, I don't think there's a problem with how ULAs work. But I do think 
that the terminology problem does have ramifications.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 7 Jan 2021 15:51:23 +1300

> The question is: Is it an error?

According to the addressing architecture and the ULA definition, it's
an error. It's also a tricky one to fix, because who knows what running
code might depend on it?

A test for ULA-ness in Python, using only the address properties that the
ipaddress module already defines, is:

def is_ula(a):
    """Test for ULA"""
    return (a.is_private and not a.is_link_local
             and not a.is_loopback
             and not a.is_unspecified)

which also, not coincidentally, returns True for RFC1918 addresses.
(Of course you could equally well do a bit-mask test.)

> 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?
 
> that the terminology problem does have ramifications.

Yes.
   Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 7 Jan 2021 01:00:29 -0300

Hi, Brian,

On 6/1/21 23:51, Brian E Carpenter wrote:
[...]
> an error. 

But this is where we go back to the original question:
* RFC4007 says that global scope addresses are globally unique.

* RFC4193 aims to reduce the collision fo a number of ULA prefixes when 
grouped together, but certainly does *not* result in globally-unique 
prefixes. Still, RFC4193 claims that ULAs globals.

So from the pov of RFC4193, ULAs are globals. From the pov of RFC4007, 
they are not.

Which of the two (RFC4007 vs RFC4193) takes precedence?

> It's also a tricky one to fix, because who knows what running
> code might depend on it?
> 

    [RFC4007] defines the scope of an address as:

       "[the] topological span within which the address may be used as a
       unique identifier for an interface or set of interfaces"

    And defines the "global scope" to be used for:

       "uniquely identifying interfaces anywhere in the Internet"

Given ~1.2M ULA prefixes, you have a probability P~1 that there's a 
collision.

In that light, it's hard to assert that they are globally unique, and 
hence that they have global scope....

---

From: Michael Richardson <[email-masked]>
Date: Thu, 07 Jan 2021 00:22:19 -0500

> So from the pov of RFC4193, ULAs are globals. From the pov of RFC4007, they
    > are not.

    > Which of the two (RFC4007 vs RFC4193) takes precedence?

It really doesn't matter, because Global has many terms.

ULAs are globally unique (ideally), but are not globally routable.

Their lack of routability is not an architectural consideration, but a
bureaucratic RIR-based concern.  They don't get RPSL, RPKI, whois or reverse DNS.

{Whether you are convinced of the statistics of ULA-R being unique or not,
does not change the goal that they be unique}

RFC4007 defines a Global Scope. (Not Global Routing)
ULAs have Global Scope, and I see nothing in RFC4007 that contradicts that.

Unless, you live in IPv4 land, and think that everything that isn't RFC1918
must be routable. And I'm sure that you don't think that way.

This python library you mention is wrong, but being a python library, is
probably too opinionate to listen to reason.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 7 Jan 2021 03:03:36 -0300

> It really doesn't matter, because Global has many terms.

It does. RFC 4193 claims that they have global scope.

Global scope does have a meaning.

> ULAs are globally unique (ideally), but are not globally routable.

THey can't be globally routable, because they can't be globally unique.

> does not change the goal that they be unique}

But this is a key thing:
10-1000 nets with no ULAs -> low probability of colission != global scope!

You have 40 bits for the "global ID" -- how many networks before 
collisions?  And, at the global level, do you expet to be above or 
bellow that number of networks? If above, you won't have unique 
prefixes, and hence, per the definition of RFC4007, you don't hable 
global scope.

> must be routable. And I'm sure that you don't think that way.

They *can't* be globally routeable, because they are not globally unique.

Similarly, even if you removed bogon filters etc, you cannot use 
10.0.0.0/8 globally because they mean different things for each of us. 
-- they are not global scope.

ULAs are just bigger (and yes, have a recommended algorithm for 
generating prefixes) such that if you grab a few ULA prefixes together, 
it's unlikely that there will be collisions.

Thanks,

---

From: Mark Andrews <[email-masked]>
Date: Thu, 7 Jan 2021 18:38:12 +1100

> On 7 Jan 2021, at 02:45, Fernando Gont <[email-masked]> wrote:
> 
>> On Wed, 6 Jan 2021 at 15:14, Philip Homburg <[email-masked] <mailto:[email-masked]>> wrote:
> And good for them that they do. The ones that don't are the ones that end up e.g. posting ULAs and link-locals on the public-facing DNS.

Really AAAA records need to be replaced with something that identifies the zone the IPv6 address is applicable to.
A 128bit followed by a domain name would work.  System would need to which domain names where applicable to which links.  I would expect the could be done with a RA option.

e.g.
	www.andrews.example.id.au. SA 2001:DB8::1c59:17c:a2ce:e9ee .
	www.andrews.example.id.au. SA fd37:287a:df67::1 dv.andrews.example.id.au.
        www.andrews.example.id.au. SA fe80::14f4:ff53:6bfa:960b link1.dv.andrews.example.id.au.
	www.andrews.example.id.au. SA ::ffff:10.0.0.1 dv.andrews.example.id.au.

The above has global, ULA, link-local and RFC 1918 addresses for a fictional web server.  

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: David Farmer <[email-masked]>
Date: Thu, 7 Jan 2021 05:08:43 -0600

Sorry for the top post.

Fernando, you are correct that by the definition of global scope in
RFC4007, ULA is not global scope.

However, Brian and RFC4139 are also correct, given the intended
reachability domain for ULA, it has a uniqueness that is many many orders
of magnitude greater than is necessary for the task. So, while not
technically global scope as defined in RFC4007 it is effectively global
scope in any way that matters.

I have an idea for what to call ULA's scope without redefining global scope
in RFC4007, how about we call ULA's scope "pseudo-global" scope.

This gives us;

Link-Local > Site-Local >>>>>> Pseudo-Global > Global

Yes, Site-Local is deprecated, it is just there for comparison. I'm trying
to show that Link-Local and Site-Local are in the same neighborhood, and
pseudo-global and global are in a completely different neighborhood.

Calling ULA pseudo-global scope I believe conveys RFC4139's original intent
without conflicting with the definition of global scope in RFC4007, while
still allowing it to be treated effectively as if it is global scope.

What do other people think?

Thanks.

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 7 Jan 2021 11:26:48 +0000

> What do other people think?

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.

Nick

---

From: Philip Homburg <[email-masked]>
Date: Thu, 07 Jan 2021 12:41:35 +0100

> Effectively that's what RFC3879 did. RFC4007 was a bit behind the
> curve. As far as I know, zone IDs and interface IDs are exactly
> equivalent (at least in POSIX and WinSock environments). IMHO this
> is *only* a terminology question.
> 

It works on Linux and MacOS. On freebsd I get
'2001:67c:2e8:3::c100:a4%re0: Name does not resolve'
which suggests that they do an extra check in a library. I didn't check
if the kernel handles it.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 07 Jan 2021 12:49:11 +0100

> Really AAAA records need to be replaced with something that identifies
> the zone the IPv6 address is applicable to.  A 128bit followed by
> a domain name would work.  System would need to which domain names
> where applicable to which links.  I would expect the could be done
> with a RA option.
> 
> e.g.
> 	www.andrews.example.id.au. SA ::ffff:10.0.0.1 dv.andrews.example.id.au.

This looks nice, but I wonder how hard it is for this to get traction.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 07 Jan 2021 12:52:13 +0100

>What do other people think?

In my opinion we need to kill the RFC 4007 scope concept. 

We can define for example 'address types' that have no scope, but as a way
to label different types of addresses.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Jan 2021 08:08:05 -0500

> 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 <[email-masked]> 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.

> 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?

---

From: Philip Homburg <[email-masked]>
Date: Thu, 07 Jan 2021 15:55:21 +0100

>    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.

I can see a few benefits of Mark's proposal. One is that it is good to
have a standard representation of information. In particular,
Mark's proposal would make it possible to have a master zone file that has
both public and private DNS entries. Then a split-DNS server could serve
only the public data to the outside world. 

At the same time, I think it would be great if we can put link-local addresses
in DNS. 

There may be more applications, for example in the context of VPNs. 

It may tie in nicely with scope IDs in socket addresses. If a DNS
record specifies that is valid only on a VPN link, then maybe we can already
tie the address to that link. No need to change applications, it can be
hidden in the stub resolver.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Jan 2021 10:08:56 -0500

> only the public data to the outside world. 

That’s a good point, although it would still be a good point if this were just a feature of the zone file and not of the wire format.

> At the same time, I think it would be great if we can put link-local addresses

That sounds like a really heavy lift.

> hidden in the stub resolver.

Now we need to standardize a way to identify links. This is a Hard Problem. I say this based on experience, not supposition. HNCP tried to do this, not as successfully as I’d hoped. I’ve been working on it for the Thread Border Router work, and haven’t come up with a general solution. Sure, if you have a data center and a managed multi-subnet LAN, and you can just type in configurations, this works, but most networks aren’t like that.  I think the VPN case is probably tractable, but it’s really hard to see a path to broad adoption for this idea.

If there is a path to broad adoption, it probably involves bottom-up work, not top-down design. Most of the ideas I’ve had about this that I think are practicable are very context-dependent. E.g., you can identify that you are on the same link because you received a link-scoped multicast.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 07 Jan 2021 11:03:03 -0500

> That’s a good point, although it would still be a good point if this
    > were just a feature of the zone file and not of the wire format.

No, it has to get into the wire format, and it has to be cachable on the
client, and it has to evaluated on the client as close to the application as
possible.

Why? because caching is good, and throwing away your cache each time you have
a link up/down is dumb in my opinion.

Having said that, I think it's mostly too late to make a change like this.
Convince me wrong with deployed code :-)

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Jan 2021 12:00:42 -0500

> a link up/down is dumb in my opinion.

I don’t think this would help, because you’re assuming that the data would be correct, and that the host would be able to tell which view to use. This is Really Hard. I don’t think that relying on this operationally could ever be a good tradeoff to save a few round trips to the nearest cache.

Since we don’t have a way to reliably identify links, and for that matter to tell which link is in which zone, we can’t do the efficient thing you are talking about. In practice, all resolvers that I know of (admittedly, this is just one, mDNSResponder) do in fact throw away the cache whenever the link changes, for exactly the reason we are talking about: just because the info I got from the resolver was valid on the link I was previously on, doesn’t mean it’s valid on the link I’m currently on.

Remember, just because something is efficient in principle, doesn’t mean that it’s efficient in practice. :)

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Thu, 7 Jan 2021 19:37:56 +0000

From: ipv6 <[email-masked]> On Behalf Of David Farmer

> Link-Local > Site-Local >>>>>> Pseudo-Global > Global

Something like that, sure, although I would not use that term.

> What do other people think?

RFC 2365 defines something exactly along these same lines, for IPv4 multicast addresses that are meant to be used only inside a particular domain. So, there is at least this one precedent, and I don’t know that it causes any confusion. RFC 2365 is titled "Administratively Scoped IP Multicast."

In my view, there's no urgent need to make any changes. But if people feel this is just too confusing, then we can define this "admin scope" for IPv6 ULAs.

In practice, RFC 1918 addresses are the same thing. Administratively scoped, and they do not need to be limited to just one link.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 8 Jan 2021 09:23:51 +1300

> if the kernel handles it.

Thanks. It doesn't work on Winsock (Windows 10 version) either. It assigns
interface index 0 to all global addresses (including ULAs) regardless of
which physical interface they are on. There is no interface 0 on Windows;
it amounts to being the "default zone" defined by RFC4007.

There's nothing in RFC4007 suggesting that a non-default zone applies
to global addresses. Rather the opposite:

"And, when supported, the index value zero at each
scope SHOULD be reserved to mean "use the default zone"...
Those default indices can also be used
as the zone qualifier for an address for which the node is attached
to only one zone; e.g., when using global addresses."

So I'd say that Linux and MacOS have got it wrong, and FreeBSD
and Windows are right. Portable code certainly can't assume that
the interface ID can be used for global unicast.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 8 Jan 2021 09:31:48 +1300

> to label different types of addresses.

This.

Link-local needs an interface ID or interface index, which is meaningless outside the host.

All other unicast addresses are routeable, and do not require an associated interface ID. The range of reachability is always administratively defined, with default behaviours (ULA = limited domain reachability, GUA = global reachability).

We could have a greatly simplified RFC4007bis in that case.

    Brian

---

From: Mark Smith <[email-masked]>
Date: Fri, 8 Jan 2021 08:22:38 +1100

Hi Brian,

> Link-local needs an interface ID or interface index, which is meaningless

While I do agree that interface ID is much more closer to the truth, it
seems that one reason for zone rather than interface ID for link-locals in
RFC 4007 was to inform a multi-interface node that it had multiple
interfaces attached to the same link, informing it that the corresponding
interface link-local addresses are attached to the same link.

I don't know what the use case for that is or was expected to be (layer 3
inbound/outbound load balancing or redundancy?), however it sounds like it
would be useful for a host to continue to have the knowledge. It would be
lost with pure IPv6 interface enabled IDs. I don't think shared GUA/ULA
prefixes across interfaces could be entirely relied on to determine that,
as it is theoretically possible for multiple interfaces on the same host
attached to the same link to have different GUA and/or ULA prefixes
(perhaps by manual configuration because the received RAs don't PIOs with
the A bit enabled, or any PIOs).

Perhaps preserve the idea of a zone, that in most but not all cases would
also be the same as interface ID, but only for the link-local unicast
prefix (and for all scopes of multicast addresses).

Regards,
Mark.

> All other unicast addresses are routeable, and do not require an
> associated interface ID. The range of reachability is always
> administratively defined, with default behaviours (ULA = limited domain
> reachability, GUA = global reachability).
>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 7 Jan 2021 18:35:28 -0300

On 7/1/21 08:08, David Farmer wrote:
> reachability domain for ULA, it has a uniqueness that is many many 
> orders of magnitude greater than is necessary for the task. So, while 
> not technically global scope as defined in RFC4007 it is effectively 
> global scope in any way that matters.

BUt this is like a circular definition. Because it's kind of saying 
something like "ULAs are globally unique as long as the have local scope".

In order for them to have "global scope", they need to be globally 
unique. And you note that "they are essentially unique, gven an 
appropriate scope".

> I have an idea for what to call ULA's scope without redefining global 
> scope in RFC4007, how about we call ULA's scope "pseudo-global" scope.
> 
> This gives us;
> 

I don't think the site-local scope, in terms of network span, is 
necessarily larger than that of ULAs.

> Calling ULA pseudo-global scope I believe conveys RFC4139's 
> original intent without conflicting with the definition of global scope 
> in RFC4007, while still allowing it to be treated effectively as if it 
> is global scope.
> 

IMO, that'd keep the confusion. At the end of the day, if your nor going 
to call them "global scope", the specific name for the scope doesn't 
really matter... as long as it is properly defined, and used consistently.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 07 Jan 2021 22:38:34 +0100

>the interface ID can be used for global unicast.

I don't see any text that disallows accepting an interface ID on a GUA.
0 is the default zone. But that does not rule out other zones.

In my opinion this is a useful feature, that could be added to a bis
document as a MAY.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 07 Jan 2021 22:40:48 +0100

>interface link-local addresses are attached to the same link.

Are there any implementation that do this? And in particular how does
that work with the socket interface? I.e., with if_nametoindex and
if_indextoname.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Jan 2021 16:51:57 -0500

On Jan 7, 2021, at 4:35 PM, Fernando Gont <[email-masked]> wrote:
> In order for them to have "global scope", they need to be globally unique. And you note that "they are essentially unique, gven an appropriate scope”.

I think the disconnect here is that RFC 4007’s definition of “global scope” clearly contradicts the sense in which ULAs are “global.” So that’s a real problem.

At the same time, the next question to ask is in what sense “global scope” is actionable. People have been talking about zone identifiers as a way to determine scope, but in practice the way we do this is with routing table entries. The reason you have to specify a zone ID for a link-local address is that the route to the link-local prefix is present on all interfaces, but the address is valid on only one interface.

So you specify that interface with the zone ID. I use the term interface loosely here—in principle you could have two interfaces connected to the same link, and that would notionally mean that they both have the same zone ID, but there’s no safe way to make this determination in practice, so in practice the “zone IDs” will always be different.

The same situation does not apply for ULAs. You can (almost) just use routing table entries to deliver ULAs. I say (almost) because of course if you don’t have an explicit route to the ULA prefix, you can’t send the packet. So there’s a tendency to want to send the packet to the default route, but that doesn’t work if you have two interfaces and two default routers. This is why it’s tempting to then use the “zone ID” to resolve this problem. But that doesn’t work, because the host has no way to know which zone ID to use.

So it’s the network’s responsibility to provide enough information that the ULA can be correctly routed. There are two ways to do this that spring to mind:
1. Make assumptions
2. Only send to a ULA if you have a specific non-global route that points to it.
3. Use provisioning domains (https://tools.ietf.org/html/rfc6418)

Option 2 is probably the safest solution. If the route is present on two interfaces, and you have a collision, and not just two valid ways of reaching the same destination, then you will have a problem. This is why ULAs aren’t as fabulous as we might wish. But in practice, it’s entirely safe to do this.

Option 1 could work pretty well, e.g. on a cell phone. Not so well on a host with two network interfaces. It’s unlikely that a ULA is going to work on the global internet, so you never send it on the cellular interface. Problem solved. This is the sense in which I think it’s tempting to say that the scope of a ULA is not global, because here you can make a purely mechanical decision.

Option 3 would work quite well. Presumably if the name server for a provisioning domain gives you a ULA, then you can use the default router for that provisioning domain to reach that ULA (if it’s not on-link). So here you have effectively an explicit scope, which really doesn’t play well with the meaning of “scope” in RFC 4007.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 7 Jan 2021 18:55:38 -0300

>> to label different types of addresses.

Me, as long as the outcome is clear, I'm fine.

("scope", as a conceptual property of addresses doesn't seem bad.  You 
can talk about the scope of IPv5 addresses (link-local, private/local, 
global) in IPv4, too).

That said, removing the concept of "scope" would probably need more 
things to be re-worked -- not necessarily bad, though.

> All other unicast addresses are routeable, and do not require an associated interface ID. The range of reachability is always administratively defined, with default behaviours (ULA = limited domain…

Me thinking out loud:
What about the case where you have a host with two interfaces, each with 
one different ULA prefix, and you need to send packets to a destination 
ULA prefix, that is totally different from the two you're using?

Another similar case would be a host with two interfaces, global 
addresses on each, that has to send packets to a ULA prefix.

It would seem to me that in wuch cases, you'd need a way to specify an 
interface.

(Not sure if, conceuptually speaking, not having an address configured 
for the ULA prefix you're trying to communicate with, means that you're 
not part of the "zone", and hence, that you're on your own)

---

From: Fernando Gont <[email-masked]>
Date: Thu, 7 Jan 2021 19:13:36 -0300

On 7/1/21 18:51, Ted Lemon wrote:
> On Jan 7, 2021, at 4:35 PM, Fernando Gont <[email-masked] 
>> appropriate scope”.
> I think the disconnect here is that RFC 4007’s definition of “global 
> scope” clearly contradicts the sense in which ULAs are “global.” So 
> that’s a real problem.

Indeed!

> At the same time, the next question to ask is in what sense “global 
> scope” is actionable. People have been talking about zone identifiers as 
> a way to determine scope, but in practice the way we do this is with 
> routing table entries. The reason you have to specify a zone ID for a 
> link-local address is that the route to the link-local prefix is present 
> on all interfaces, but the address is valid on only one interface.

Agreed. Or: the address is not globally-unique. So the same address is 
actually valid on all interfaces, most-likely corresponding to different 
nodes .. and thus you need to specify which of all those possible 
instances of address FE80::X you are referring to.

> The same situation does not apply for ULAs. You can (almost) just use 
> routing table entries to deliver ULAs. I say (almost) because of course 
> if you don’t have an explicit route to the ULA prefix, you can’t send 
> the packet.

As noted to Brian, the case that might need a zone-id is that where you 
have a host with two interfaces, each with one different ULA prefix, and 
you need to send packets to a destination ULA that belongs to a whole 
different prefix than the ones for which you have configured addresses 
for your two interfaces.

Relying on your default route might not get your to where you want.

(Not sure if, conceptually speaking, not having an address configured 
for the ULA prefix you're trying to communicate with, means that you're 
not part of the "zone", and hence, that you're on your own)

> So there’s a tendency to want to send the packet to the 
> default route, but that doesn’t work if you have two interfaces and two 
> default routers. This is why it’s tempting to then use the “zone ID” to 
> resolve this problem. But that doesn’t work, because the host has no way 
> to know which zone ID to use.

That seems to be a similar case than the one I was noting above. I gues 
it could also be more complicate: even if you had a single interface, 
you might have multiple default routers. So rather than specifying an 
interface, you might actually need to specify "which next hope" to use.

Of course one cannot expect that.

> So it’s the network’s responsibility to provide enough information that 
> the ULA can be correctly routed. There are two ways to do this that 
> spring to mind:
> 1. Make assumptions

#2 would probably make cases that are currently supported, unsupported. 
e.g.: think of a case where your local router advertises a /64 ULA 
prefix on the local link, and you want to send a packet to an address of 
a different subnet of the same Global-ID. -- most likely your router is 
not sending RIOs for the ULA prefix you're employing....

> Option 1 could work pretty well, e.g. on a cell phone. Not so well on a 
> host with two network interfaces. It’s unlikely that a ULA is going to 
> work on the global internet, so you never send it on the cellular 
> interface. Problem solved. This is the sense in which I think it’s 
> tempting to say that the scope of a ULA is not global, because here you 
> can make a purely mechanical decision.

Agreed on this one.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 8 Jan 2021 11:40:23 +1300

> that work with the socket interface? I.e., with if_nametoindex and

The machine on which I am typing has interface 6 and interface 22
both up and running.
On interface 6,  the default router is fe80::2e3a:fdff:fea4:dde7%6
On interface 22, the default router is fe80::2e3a:fdff:fea4:dde7%22

Yes, they are the same thing because the default router is also a transparent
Ethernet-to-WiFi bridge. Interface 6 and interface 22 both connect to
the same LAN, but the IP stack has no way to know it.

The zone index as described in RFC4007 is a hallucination.

    Brian

---

From: Mark Andrews <[email-masked]>
Date: Fri, 8 Jan 2021 12:18:46 +1100

> On 8 Jan 2021, at 02:08, Ted Lemon <[email-masked]> wrote:
> 

My idea would be that there would also be a RA option(s) which advertised the names in the SA records that where applicable to the link.  Implicit to that is that there would be a API that allows getaddrinfo() to retrieve the
RA options for individual links and for all links on the node.  getaddrinfo() would use the later.  The former would be used to construct UPDATE requests for the DNS etc.  LLSANAME (link-local SA name), ULASANAM (ULA SA name), and perhaps others.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Jan 2021 20:43:25 -0500

Who determines what names to use?  What is the scope of the names? How is uniqueness guaranteed in that scope?

> On Jan 7, 2021, at 20:18, Mark Andrews <[email-masked]> wrote:
> 
> 
>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 8 Jan 2021 13:02:54 +1100

> On 8 Jan 2021, at 12:43, Ted Lemon <[email-masked]> wrote:
> 

One would recommend using suffix names that are already registered to the organisation, individual in the DNS.
The example names I used where using the individuals suffix (id.au) but the idea is to leverage the existing global DNS to provide uniqueness.  If you don’t have a domain name generate a random 160 bit number and base32 encode it (like NSEC3) or similar and append .home.arpa to it.  If you are publishing into the global DNS you have a registered name to use as a suffix.  If you aren’t publishing into the global DNS you need to ensure the names don’t clash with any in the global DNS, <label>.home.arpa qualifies.   If you don’t like home.arpa, register a another name to be the default suffix labels.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Jan 2021 21:04:27 -0500

On Jan 7, 2021, at 9:02 PM, Mark Andrews <[email-masked]> wrote:
> The example names I used where using the individuals suffix (id.au <http://id.au/>) but the idea is to leverage the existing global DNS to provide uniqueness. 

That works pretty well for ULAs, but not for LLAs. For LLAs you need to identify the link, and that’s just not a simple thing to do, as I explained earlier.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 8 Jan 2021 13:48:18 +1100

> On 8 Jan 2021, at 13:04, Ted Lemon <[email-masked]> wrote:
> 
>> The example names I used where using the individuals suffix (id.au) but the idea is to leverage the existing global DNS to provide uniqueness. 
> 

Actually you haven’t explained.  You have stated.  You said it was hard.  Hard is not intractable.

If you are willing for a link to have multiple names just have reach router generate its own random 160 bit base32 encoded label for each interface, append the well know suffix and advertise it.  You will get multiple SA records for the same interface if there are multiple routers but that should not be a issue.  With 160 random bits the need to do collision detection is really non-existent.  We’ve resolved this for NSEC3 and DNS changes 15 years ago.  This will scale into millions of router interfaces.

If you want to have a single link name then we need to define a protocol for the routers on the link to select one of the names.  This may end up being technology linked.  Router with smallest L-L address wins would be one solution to this.

Yes, I really do expect every machine to update its own addresses in the DNS.  We do know how to do that securely with SIG(0).

---

From: Mark Andrews <[email-masked]>
Date: Fri, 8 Jan 2021 13:53:08 +1100

> On 8 Jan 2021, at 13:48, Mark Andrews <[email-masked]> wrote:
> 
> 
> 

For those playing along at home we are talking about link names like

	RBS4LI8FAPU7LSBL3TLC14T2A7L7DB66.home.arpa.

they aren’t pretty buy they work.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Jan 2021 21:54:39 -0500

Right. That’s how you do it. And then what happens with the topology changes?  The random ids are no longer referring to the same links. Solving this problem adequately is way more work than it’s worth. The thrashing in the database would be brutal. 

> On Jan 7, 2021, at 21:48, Mark Andrews <[email-masked]> wrote:
> 
> 
>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 8 Jan 2021 14:02:06 +1100

> On 8 Jan 2021, at 13:54, Ted Lemon <[email-masked]> wrote:
> 

You publish updated records.  If you are changing topology the addresses of the nodes are almost certainly changing anyway. Publishing new L-L SA records along with new ULA and GUA is minimal extra expense.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 8 Jan 2021 14:18:38 +1100

> On 8 Jan 2021, at 14:02, Mark Andrews <[email-masked]> wrote:
> 
> 
> 

When you change topology the node will see new RAs and getaddrinfo() will filter out all the old addresses.  The node has a set of link identifiers for links it is attached to.  Remember machines don’t care about these names.  They are just ways to filter out the currently useful addresses.  Each node will maintain its own mapping from applicable names to sin6_scope_id which will be filled in by getaddrinfo() generated by the RAs it sees.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 8 Jan 2021 07:39:57 -0500

On Jan 7, 2021, at 10:18 PM, Mark Andrews <[email-masked]> wrote:
> When you change topology the node will see new RAs and getaddrinfo() will filter out all the old addresses.  The node has a set of link identifiers for links it is attached to.  Remember machines don’t care about these names.  They are just ways to filter out the currently useful addresses.  Each node
> will maintain its own mapping from applicable names to sin6_scope_id which will be filled in by getaddrinfo() generated by the RAs it sees.

I think link identifiers as you describe might be useful for some applications, but putting them in a database has a lot of issues. If every router on a link multicasts a link identifier to a link, then it’s not a link identifier—it’s a router interface identifier. That’s fine, but now my node has to track what router interface identifiers are present on the link, and publish its information on each identifier. Now suppose a router is unplugged from one link and plugged into another. It starts advertising its router interface identifier on the new link. Now you have stale information in the DNS, but the host doesn’t know, because there’s no positive indication that that router has gone.

You could track the router's reachability in the neighbor table, but now you have a different problem: it’s only going to be in the neighbor table if you’re using it, or if an RA has been received recently. So now you have a router link identifier that’s fluctuating. Do you update the database on every fluctuation?

Furthermore, DNS has TTLs. What’s the TTL on the data? How quickly does it fall out of your cache? Remember, you wanted to do this because Caching Is Good, so if you use a short TTL, your Good Caching isn’t happening.

What if you’re on an IPv4-only link? How do you publish your IPv6 LLA with a router link identifier? Your router isn’t giving you one. You can’t use the RFC1918 subnet prefix you got from DHCP as a link identifier, because they are non-unique.

This is what I mean when I say this isn’t practicable. Sure, it’s theoretically possible to imagine an environment where it would work. But it’s a tremendous amount of work that fails in ways that will create delay in many corner cases. And all it gets you is a hint from DNS as to which interface to use to communicate with a named host using its LLA. This isn’t much of a benefit.

If I just wanted hints, I could just do ND on every multicast-capable interface and get much more reliable hints: in most cases I’ll only get an answer on one interface, and then I can just send the packet on that interface and be much more assured of correctness than I could be based on stale data in the DNS.

Look at this from the other direction. A DNS full service resolver on your network can in many cases know where the query is coming from. BIND 9 already does this—I can define a set of prefixes that are “local” and allow queries from those prefixes, but refuse queries from other prefixes.

This generalizes well: I can do the same thing for ULAs. I could very easily mark some set of ULA prefixes as “reachable for hosts with addresses in prefixes on this list.” And then when I get an AAAA record query that has both ULA and GUA addresses, I can return just the GUA address for queries from prefixes that aren’t on the list, and I can return the ULA only for queries from prefixes that are in the list. Or ULA+GUA.

This works well because minor changes in topology aren’t relevant. We know who owns the ULA prefix. We don’t need to know the details of where sub-prefixes of that ULA prefix are being advertised. We know what GUAs we have. If our upstream renumbers us, we need to update the prefix list, but this is a very lightweight change. And particularly if we _only_ return ULAs when the ULA is valid, this prefix change doesn’t affect any host that has the answer cached: our upstream GUA prefix change doesn’t affect our internal ULAs.

So from an operational perspective, this is a really useful feature—it’s one that I’d dearly love to see in BIND.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 08 Jan 2021 17:55:45 +0100

>    I think link identifiers as you describe might be useful for
>    some applications, but putting them in a database has a lot of
>    issues. If every router on a link multicasts a link identifier
>    to a link, then it's not a link identifier--it's a router
>    interface identifier. That's fine, but now my node has to track
>    what router interface identifiers are present on the link, and
>    publish its information on each identifier. 

I'm confused here. I thought that one of the purposes of HNCP is to 
uniquely number each link with a /64.

If you have a unique 64 bit identifier, then it is trivial to compute
a unique domain name.

>    Furthermore, DNS has TTLs. What's the TTL on the data? How
>    quickly does it fall out of your cache? Remember, you wanted to
>    do this because Caching Is Good, so if you use a short TTL, your
>    Good Caching isn't happening.

What kind of topology changes are you thinking of that are faster than
typical DNS TTLs?

>    What if you're on an IPv4-only link? How do you publish your
>    IPv6 LLA with a router link identifier? Your router isn't giving
>    you one. You can't use the RFC1918 subnet prefix you got from
>    DHCP as a link identifier, because they are non-unique.

It seems to me that if you are doing homenet, you can just as well use 
RAs to distribute information. No need to do SLAAC.