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

From: Fred Baker <[email-masked]>
Date: Fri, 12 Feb 2021 14:37:26 -0800

> On Jan 5, 2021, at 5:20 PM, Fernando Gont <[email-masked]> wrote:
> 
> 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).

I think I might describe it using the phrase "routing scope" or something akin to it. An address, any address, is usable within the range it is advertised to in routing, router advertisements, and so on - and it is unreasonable to expect routers to actively limit that apart from some form of configuration to do so. So to my mind, statements to the effect that ULAs should or should not be limited to (or from) some domain are not instructions to routing implementations per se, but instructions to people that configure BGP accordingly. Link-local addresses are confined to a given LAN not because someone said so in an RFC, but because routing implementations do not advertise a certain prefix off-LAN, and ULAs are confined to a given domain not because someone wrote it in an RFC, but because routers are not configured to (are configured to not) advertise them to external BGP peers and (hopefully) BGP peers refuse them if inappropriately advertised to them.

We're trying very hard to construct a useful definition of "site-local" without saying so, and it might be worthwhile to actually say so.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 12 Feb 2021 20:12:33 -0300

Hi, Fred,

On 12/2/21 19:37, Fred Baker wrote:
>> 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).
> 
> I think I might describe it using the phrase "routing scope" or 
> something akin to it. An address, any address, is usable within the 
> range it is advertised to in routing,

Indeed --- which is always smaller than the scope of the address in
terms of uniqueness.

Both the uniqueness scope and the routing scope of ULAs are smaller than
that of GUAs.

 > configure BGP accordingly. Link-local addresses are confined to a
 > given LAN not because someone said so in an RFC, but because routing
 > implementations do not advertise a certain prefix off-LAN,

There's a mix of things for ULAs:
1) Their uniqueness scope is the local link. So those addresses are 
meaningless out of the link.

2) Because of #1, even if you wanted to route link-locals, if you have a 
router with multiple interfaces you wouldn't known on which of them you 
should forward the packet.

3) The RFCs do prohibit that such packets are forwarded across links

 > and ULAs
 > are confined to a given domain not because someone wrote it in an RFC,
 > but because routers are not configured to (are configured to not)
 > advertise them to external BGP peers and (hopefully) BGP peers refuse
 > them if inappropriately advertised to them.

The question is: if you wanted to route ULAs globally -- could you?

i.e., who's acceptable as a origin AS for a ULA prefix? And, what if the 
same prefix is used by multiple parties?  (the ULA spec only considers 
the case where a handful of ULA-based addresses are interconnected --- 
but that's quite different from ULAs having uniqueness global scope... 
since this would imply that *all* ULA prefixes employed by *all* 
networks are unique)

> We're trying very hard to construct a useful definition of 
> "site-local" without saying so, and it might be worthwhile to 
> actually say so.

I seem to agree with you :-)

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 12 Feb 2021 18:29:52 -0500

> Both the uniqueness scope and the routing scope of ULAs are smaller than

This is true, but the distinction is that there is no automatic mechanism specified for knowing whether a particular ULA is in scope for a link. It’s perfectly valid to use the default route to forward to a ULA destination. If a host were to automatically not do this, things would break all over the place.

IOW, what Fred said is perfectly correct and sensible, but the sense in which ULAs are global is that you should (MUST?) use the default route to route them unless there is a more specific route that matches.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 12 Feb 2021 20:50:42 -0300

Hi, Ted,

On 12/2/21 20:29, Ted Lemon wrote:
> On Feb 12, 2021, at 6:12 PM, Fernando Gont <[email-masked] 
> <mailto:[email-masked]>> wrote:
> This is true, but the distinction is that there is no automatic 
> mechanism specified for knowing whether a particular ULA is in scope for 
> a link.

Well, that's because the scope of ULAs is loosely-defined. As Fred, it's 
essentially "site local", with site-local meaning whatever you want it 
to mean (or, IOW, whatever it means based on hor far such packets can be 
routed and the area where such addresses are meaningful).

> It’s perfectly valid to use the default route to forward to a 
> ULA destination. If a host were to automatically not do this, things 
> would break all over the place.

Well, but that's essentially true for anything that is not link-local -- 
because link local is the only scope that is tightly defined.

Global: Valid in all networks
Link-local: only valid within this network segement.

For the rest (e.g. ULAs), you forward them "just in case", because you 
don't really know where the scope ends.

> IOW, what Fred said is perfectly correct and sensible, but the sense in 
> which ULAs are global is that you should (MUST?) use the default route 
> to route them unless there is a more specific route that matches.

This, in away, is the question that this document somewhat raises:

* What's "global scope" anyway?

* And, given what we have right now, either the definition of scope is 
flawed (as in the scoped addressing architecture), or ULAs are not 
global, or both. :-)

Thanks,

---

From: Ted Lemon <[email-masked]>
Date: Fri, 12 Feb 2021 19:04:09 -0500

> * What's "global scope" anyway?

Global scope is “you can forward it to the default route.”

> * And, given what we have right now, either the definition of scope is flawed (as in the scoped addressing architecture), or ULAs are not global, or both. :-)

RFC 4007 has a concept of “interfaces belonging to a zone,” and has a nice diagram with several organizations that we might say is a non-overlapping Venn diagram. But ULAs don’t have to have a non-overlapping Venn diagram. So they are global. And indeed there is no way to automatically determine (without configuration) which zone any given address belongs to. So in effect the only two scopes that can be automatically determined are “link local” and “global.” There can be no other scope, in the sense of a scope that can be automatically determined.

This doesn’t mean that RFC 4007 is useless, but what it does mean is that when we assign a scope to “ULA,” the only scope that makes sense is “global.”

So maybe a better question to ask is, why are we discussing this? What problem are we trying to solve?

---

From: Fernando Gont <[email-masked]>
Date: Fri, 12 Feb 2021 21:29:17 -0300

On 12/2/21 21:04, Ted Lemon wrote:
> On Feb 12, 2021, at 6:50 PM, Fernando Gont <[email-masked] 

That's certainly not the definition of "global" we currently have.

(draft-gont-6man-ipv6-ula-scope points to the relevant places)

Me, I wouldn't use the "default route" in the definition of "global". 
 From a routing pov the default route is simply yet another route, 
albeit with a zero-len mask.

Addresses need to be able to identify the intended sender/recipient. So 
the area where they can do that limit their scope.

Now, if I use fd00:1234:5678:abcd::/64 on my net, and you use the same 
prefix on yours, and both usages are legitimate, then that's an 
indication that the scope of ULAs cannot be global.

> RFC 4007 has a concept of “interfaces belonging to a zone,” and has a 
> nice diagram with several organizations that we might say is a 
> non-overlapping Venn diagram. But ULAs don’t have to have a 
> non-overlapping Venn diagram. So they are global.

Please define "global". :-)

> And indeed there is no 
> way to automatically determine (without configuration) which zone any 
> given address belongs to. So in effect the only two scopes that can be 
> automatically determined are “link local” and “global.” There can be no 
> other scope, in the sense of a scope that can be automatically determined.
> 
> This doesn’t mean that RFC 4007 is useless, but what it does mean is 
> that when we assign a scope to “ULA,” the only scope that makes sense is 
> “global.”

This is the definition of "scope" and "global scope" from RFC4007:

    [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"

ULAs can certainly NOT be used in the Internet-wide span, and they 
certainly do not "uniquely identify interfaces anywhere in the Internet".

> problem are we trying to solve?

As per the above, either the definition in the scoped addressing 
architecture is wrong, or flagging ULAs as "global scope" is incorrect.

The problem I'm trying to solve is one of architecture, so to speak.

Thanks,
-- 
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: Fri, 12 Feb 2021 21:35:21 -0300

On 12/2/21 21:29, Fernando Gont wrote:
[...]
> The problem I'm trying to solve is one of architecture, so to speak.

The expectation to have a registry for ULAs (as discussed recently on 
6man@ ) is, in a way, closely related to this; the expectation that they 
can uniquely identify networks and interfaces at an Internet-wide span, 
when they actually can't.

(Besides the fact that if we are going to have an architecture in the 
first place, it better matches the protocol spec... or the other way 
around).

Thanks,

---

From: Ted Lemon <[email-masked]>
Date: Fri, 12 Feb 2021 19:53:02 -0500

On Feb 12, 2021, at 7:29 PM, Fernando Gont <[email-masked]> wrote:
> As per the above, either the definition in the scoped addressing architecture is wrong, or flagging ULAs as "global scope" is incorrect.
> 

RFC 4007 only defines two scopes for unicast addresses: “link local” and “global.” In this taxonomy, ULA is clearly and unambiguously global, so there is no mistake.

But you think there’s a problem. In order for us to know what to do about this problem, you need to be able to articulate it in a way that makes sense to us. The best way to do so is to point to a case where the behavior of some system will be incorrect because this was not specified correctly. Can you point to such a case?

---

From: Fred Baker <[email-masked]>
Date: Fri, 12 Feb 2021 17:51:55 -0800

> On Feb 12, 2021, at 4:53 PM, Ted Lemon <[email-masked]> wrote:
> 

I think the thing Fernando is getting at would be the dictionary definition of "global", as in "anywhere on the globe". A ULA, as noted in the name, is a "local" address in the sense that it is only unique within a local context. It is "global" in scope only in the sense that if you get one from some other domain (which might legally happen if there were an agreement between the two AS's), the scope extends to include a domain other than the local one.

I commented that I think of it as a variant of site-local scope as defined in RFC 3513 in the sense that a site-local prefix was one assigned to a "site", whatever that actually was, and was only meaningful within that site. Should the packet cross into some other domain, the prefix would refer to the "site" of the domain it entered, which is a different "site" than the original. A ULA is similarly a prefix assigned to a local routing domain, and addresses within it are only meaningful or useful within that routing domain. If there is a difference, it is that (a) when it crosses a domain boundary, the new domain might not actually contain that prefix, unless the routing domain were be extended across ASN boundaries by prior arrangement. So it's not *exactly* the same as a site-local, but it bears (at least to my dense mind) strong similarities.

I made the observation because I'm watching several people struggle with the idea that something is global in "scope" but not globally understood. I view that as a poor definition of the scope. If we're trying to identify the scope, it has to be something meaningful. We shouldn't have to struggle with it.

---

From: Fred Baker <[email-masked]>
Date: Fri, 12 Feb 2021 17:55:17 -0800

> On Feb 12, 2021, at 4:04 PM, Ted Lemon <[email-masked]> wrote:
> 

No. Global scope, per the RFC  you're quoting, is "Global scope, for uniquely identifying interfaces anywhere in the Internet."

---

From: Ted Lemon <[email-masked]>
Date: Fri, 12 Feb 2021 21:13:33 -0500

On Feb 12, 2021, at 8:55 PM, Fred Baker <[email-masked]> wrote:
> No. Global scope, per the RFC  you're quoting, is "Global scope, for uniquely identifying interfaces anywhere in the Internet.”

If you’re referring to RFC 4007, and talking about unicast addresses, then the document is unequivocal on this point: an address is either global or link-local. Those are the only two options. I think here “global” means “there is no context in which this address is, by definition, out of scope.”

I agree that there’s a terminology question here, and perhaps that is a problem to solve, but I don’t see any way to solve it. I think the following things are all true:

ULA addresses are, in principle, VALID in any scope.

They are not, in principle, UNIQUE to a particular link: it’s entirely possible to have two instances of the same ULA referring to different interfaces connected to different links.

In principle, the set of all networks which can route a packet to a particular instance of a ULA /48 MUST be DISJOINT from the set of all networks which can route a packet to some other instance of that ULA /48.

In practice, the randomness of ULAs gives us some reasonable assurance that the principle will hold.

However, users of ULAs that are routed beyond an individual site had better have some policies and procedures in place to make sure that this is true.

Internet backbone routers should never accept BGP advertisements for ULA prefixes.

Sites connecting to the Internet should never, by default, route ULAs northbound of their connection to their ISP.

The last four lines are points of practice, not points of definition of terms.

But the bottom line is that if the term “global” is confusing as it applies to ULAs, it shouldn’t be that hard to clarify what we mean by global.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 12 Feb 2021 23:46:33 -0300

On 12/2/21 23:13, Ted Lemon wrote:
>> No. Global scope, per the RFC  you're quoting, is "Global scope,
>> for uniquely identifying interfaces anywhere in the Internet.”
> 
> 
> If you’re referring to RFC 4007, and talking about unicast addresses,
> then the document is unequivocal on this point: an address is either
> global or link-local. Those are the only two options. 

RFC4007 does not limit the possible scopes to only two options. For 
instance, there's a definition of scope:

and of "global scope" in particular:

ULAs certainly have a scope larger than link-local, but also certainly 
do not comply with the above definition of "global scope".

> I think here
> “global” means “there is no context in which this address is, by
> definition, out of scope.”

But that's a circular definition ;-)   So, what's the definition of 
"scope", in the first place?

> I agree that there’s a terminology question here, and perhaps that is
> a problem to solve, but I don’t see any way to solve it. I think the
> following things are all true:
> 
> They are not, in principle, UNIQUE to a particular link: it’s
> entirely possible to have two instances of the same ULA referring to
> different interfaces connected to different links.
> 
> In principle, the set of all networks which can route a packet to a
> particular instance of a ULA /48 MUST be DISJOINT from the set of all
> networks which can route a packet to some other instance of that ULA
> /48.

These last two are essentially at odds with the definition of "global 
scope" from RFC4007.

OTOH, these two items apply perfectly fine for real GUAs.

> But the bottom line is that if the term “global” is confusing as it
> applies to ULAs, it shouldn’t be that hard to clarify what we mean by
> global.

My pov is that the definitions in RFC4007, are sensible. However, these 
are at odds with the definition of ULAs as global addresses.

(Bottom-line here is that this thread has shown that the terminology 
employed is confusing -- if not incorrect -- even for us involved with 
the stds.  So I'd expect that to be even more the case for "newcomers". 
  In fact, this issue partly came up while explaining the ipv6 
addressing architecture to other folks... )

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Feb 2021 16:08:00 +1300

OK, I have deleted all the content (but basically I agree with Ted Lemon). IMHO:

ULAs SHOULD be treated exactly like GUAs for all practical purposes (including using a default router for them), with the exception that they MUST be filtered by border routers at a domain boundary that is defined administratively. The only extra requirement is that ULA prefixes MUST be unique within that domain boundary. That's all, I think.

As for the word "scope" and the phrase "global scope" it may be best to not use them at all. We originally had a false notion of concentric rings of address scope, but reality is a very complex Venn diagram. Even link-local may stop being very meaningful as we see more and more mesh networks. That will be much harder to handle than any aspect of ULAs.

Regards
   Brian Carpenter

---

From: Fernando Gont <[email-masked]>
Date: Sat, 13 Feb 2021 00:13:00 -0300

On 12/2/21 21:53, Ted Lemon wrote:
> On Feb 12, 2021, at 7:29 PM, Fernando Gont <[email-masked] 
> <mailto:[email-masked]>> wrote:
> RFC 4007 only defines two scopes for unicast addresses: “link local” and 
> “global.” In this taxonomy, ULA is clearly and unambiguously global, so 
> there is no mistake.

Global scope, as per RFC4007:

Of course, ULAs don't "uniquely identify interfaces anywhere in the 
Internet".

(you only have a low-probability of collisions if/when a limited number 
of ULA-based networks are interconnected -- but that's quite different 
from the above definition)

> But you think there’s a problem. In order for us to know what to do 
> about this problem, you need to be able to articulate it in a way that 
> makes sense to us. The best way to do so is to point to a case where the 
> behavior of some system will be incorrect because this was not specified 
> correctly. Can you point to such a case?

The problem is in the scoped addressing architecture and the definition 
of "scopes" vs. the definition of ULAs.

Since it's a problem with the architecture you probably won't see a 
direct problem arising from it.

You might argue that architecture is not important (I'd disagree with 
that :-) ), but, at the end of the day, if it's not important, why 
pretend to have one in the first place? (in particular when there's no 
consistency with the actual protocols)

As noted, the only practical implications I've seen have been:

* Folks willing to have a registry for ULAs, on the expectations that
   they are indeed unique -- whcih they are not!

* Folks having a hard time understanding the addressing architecture --
   in particular the scoped addressing architecture (RFC4007) and how
   that applies to actual specs (e.g., definition of ULAs)

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 13 Feb 2021 00:17:28 -0300

On 13/2/21 00:08, Brian E Carpenter wrote:
> ULAs SHOULD be treated exactly like GUAs for all practical purposes
> (including using a default router for them), with the exception that
> they MUST be filtered by border routers at a domain boundary that is
> defined administratively. The only extra requirement is that ULA
> prefixes MUST be unique within that domain boundary. That's all, I
> think.

FWIW, in the context of draft-ietf-6man-slaac-renum, it has been argued 
that: "only phase out GUAs if you hear of new GUAs, and only phase out 
ULAs if you hear of new ULAs" -- i.e., that they should be treated 
differently.

(Note: I'm not necessarily arguing in favor of this.)

> As for the word "scope" and the phrase "global scope" it may be best
> to not use them at all. We originally had a false notion of
> concentric rings of address scope, but reality is a very complex Venn
> diagram. Even link-local may stop being very meaningful as we see
> more and more mesh networks. That will be much harder to handle than
> any aspect of ULAs.

Deprecate/rev RFC4007? :-)

Thanks,

---

From: Michael Richardson <[email-masked]>
Date: Fri, 12 Feb 2021 22:53:49 -0500

Ted Lemon <[email-masked]> wrote:
    >> Both the uniqueness scope and the routing scope of ULAs are smaller
    >> than that of GUAs.

    > mechanism specified for knowing whether a particular ULA is in scope
    > for a link. It’s perfectly valid to use the default route to forward to
    > a ULA destination. If a host were to automatically not do this, things

Agreed.

And the potential leak is now by default much less as the DHCPv6-PD mechanism in
OpenWRT creates SADR default routes that look like:
   from 2001:db8:1234::/48 default via dev ...

plus, of course, ISP use of BCP38.

    > to route them unless there is a more specific route that matches.

+1

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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 12 Feb 2021 22:55:41 -0500

> prefixes MUST be unique within that domain boundary. That's all, I

But, that's pretty much always just BCP38, right?

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Feb 2021 17:42:45 +1300

> But, that's pretty much always just BCP38, right?

Yes, I think so. While Fernando is correct that our terminology is a bit
dubious, I don't think there's an actual operational problem here. It's more
that the terminology makes things hard to explain.

    brian

---

From: Ted Lemon <[email-masked]>
Date: Fri, 12 Feb 2021 23:51:28 -0500

On Feb 12, 2021, at 10:13 PM, Fernando Gont <[email-masked]> wrote:
> You might argue that architecture is not important (I'd disagree with that :-) ), but, at the end of the day, if it's not important, why pretend to have one in the first place? (in particular when there's no consistency with the actual protocols)
> 
> 

The thing is, the meaning of the architecture document as it pertains to ULAs is plain to me, and it’s just what Brian said.

So who is confused? Are you having operational issues, or just speculating? I don’t mean to minimize your concern—just trying to get a sense of why this has come up. Do you not know how to operate in the presence of ULAs? Have you been getting questions from customers that you can’t answer to their satisfaction? Have you run into routing issues?

---

From: Fernando Gont <[email-masked]>
Date: Sat, 13 Feb 2021 02:19:36 -0300

> But, that's pretty much always just BCP38, right?

Not really. BCP38 means that you don't allow packets to enter your 
network if they are employing the address space of your network (i.e., 
traffic that could only originate from your network). And you only allow 
packets out of your network if they are sourced from your own address space.

In the case of ULAs,  you'd probably want to drop incoming/outgoing 
packets that employ ULAs at e.g. your CPE router -- regardless of 
whether they employ your own ULA prefix or not (I consider my home 
network to be a different domain than, say, my ISP network). But that's 
certainly not BCP38.

OTOH, my ISP seems to employ ULAs in their infrastructure... so 
filtering ULAs at my CPE router would "break" traceroute.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 13 Feb 2021 02:11:41 -0300

On 13/2/21 01:51, Ted Lemon wrote:
> On Feb 12, 2021, at 10:13 PM, Fernando Gont <[email-masked] 
> The thing is, the meaning of the architecture document as it pertains to 
> ULAs is plain to me, and it’s just what Brian said.

If by "plain" you mean "clear", then this discussion should be an 
indication that it's not. We have a definition of scope in RFC4007 which 
doesn't match RFC4193... and then it should be clear that we all have a 
different understanding of what "scope" and "global scope" (in 
particular) mean.

> So who is confused? 

Well, I certainly have my own take on the topic. The fact that most of 
the folks that have participated in this thread have their own and 
different take, probably means something.

> Are you having operational issues, or just speculating? 

There are certainly no operational issues that I know of. (But we also 
don't really leverage IPv6 addressing anyway, so...)

As noted, I believe that the confusing terminology does have concrete 
implications. e.g. see:

---- 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 one is documented in our draft, but credit goes to Brian for 
spotting it).

Are the is_private and is_global attributes employed by such library 
correct? Do they match our specs? Do they match the obvious 
interpretation of such attributes?  Should they be changed? Why, or why not?

> I don’t mean to minimize your concern—just trying to get a 
> sense of why this has come up. Do you not know how to operate in the 
> presence of ULAs? Have you been getting questions from customers that 
> you can’t answer to their satisfaction? 

I have got questions from customers that I wasn't able to answer with 
*my* own satisfaction -- let alone theirs, so to speak. :-)

Explain the scoped addressing architecture (even the very definition of 
"scope" means.) Then introduce ULAs, and note that they are global 
scope. Both cannot be right.

Somewhat related:

in the context of draft-ietf-6man-slaac-renum, some argued that one 
should differentiate between GUAs and ULAs. And that you should only 
phase out stale ULAs if you have fresh ULAs. And that you should only 
phase out stale GUAs if you know of fresher GUAs.

The rationale of this has a lot to do with whether GUAs and ULAs are a 
different sort of animal.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 13 Feb 2021 01:54:55 -0300

On 13/2/21 01:42, Brian E Carpenter wrote:
[...]
> that the terminology makes things hard to explain.

Exactly.  And when explaining things, pointing to the documents that 
should shed light and be the authoritative references actually leads to 
more confusion than clarification.

If we plan for IPv6 to be with us for a while, it'd be nice that these 
things are consistent (whether as a result of deprecating/revising 
RFC4007, changing the definition of ULAs are globals, or others).

Thanks,

---

From: Ted Lemon <[email-masked]>
Date: Sat, 13 Feb 2021 00:46:54 -0500

Okay. Consider the clarifications I suggested a while back:

---

---

Do you think anything I’ve said here is wrong, not in the sense of contradicting RFC 4007, but in the sense that it is incorrect?

Is there anything missing?

I’m not trying to win an argument here—the reason I wrote the above is that I think it’s correct, and I was trying to figure out whether it was in any way consistent with the problem you have.

I think Brian has said that the “scoped architecture” is just not how things actually work in real life, with which I agree, so the fact that you can’t explain it to anyone is not a big shock. I think RFC 4007 says some interesting and useful things. It might be worthwhile to write a new document that’s a sort of Talmudic commentary on RFC 4007.

What I do not want to see is some kind of effort to rationalize ULAs into something other than what they are at present, which is quite useful.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 13 Feb 2021 03:54:49 -0300

Hi, Ted,

> Okay. Consider the clarifications I suggested a while back:

Ok. I will comment on each of them.

> ULA addresses are, in principle, VALID in any scope.

This begs the question: what's a scope?

> They are not, in principle, UNIQUE to a particular link: it’s entirely 
> possible to have two instances of the same ULA referring to different 
> interfaces connected to different links.

This breaks the definition of scope and global scope from RFC4007.

> networks which can route a packet to some other instance of that ULA /48.

Agreed. But this is at odds with the definition of global scope from 
RFC4007.

Agreed.

> However, users of ULAs that are routed beyond an individual site had 
> better have some policies and procedures in place to make sure that this 
> is true.
> 

Agreed on both.

> Sites connecting to the Internet should never, by default, route ULAs 
> northbound of their connection to their ISP.

I'd generally agree. But this is somewhat relative and, as Brian noted, 
it boils down to what you define as an administrative domain.

e.g. filtering all ULAs at my CPE router would break part of the 
tracereoute output I normally get, since my ISP employs ULAs in their 
infrastructure.

In any case, even if I wanted to block them, I'd need to treat them 
differently from GUAs.

In cases where you actually DHCPv6-PD ULAs (as I'm told some community 
networks do), it becomes even tricker.

(But yeah, there's probably no debate that, at the very least they 
shouldn't appear in the DMZ. And they also wouldn't survive your ISP if 
you sourced packets from your locally-generated ULAs, since your ISP 
won't have routes for them)

(Probably, all these considerations are exactly the same than for 
RFC1918 space --- which probably tells something).

I guess yet another question would be: If your ISP, for some reason, 
offered you a ULA prefix (along with a GUA prefix), should you also 
propagate it on the LAN-side? (i.e., advertise via SLAAC on the 
LAN-side). I guess you might argue (and I'd agree) that in general, you 
shouldn't. But then again ULAs would be a special case, and trated 
differently from GUAs.

Agreed.

> applies to ULAs, it shouldn’t be that hard to clarify what we mean by 

This is indeed the point I was trying to make.

I personally think that the definition of "scope" and "global scope" 
from RFC4007 is a good one. And, as per the above, I'm inclined to say 
that the problem is in flagging ULAs as "global scope" (rather than on 
the definition of "global scope" itself).

But, preferences aside, the bottom-line is that as long as it's clear 
what the terminology means, I don't mind a lot what we use.

> Do you think anything I’ve said here is wrong, not in the sense of 
> contradicting RFC 4007, but in the sense that it is incorrect?

The above seems indeed correct.

> I’m not trying to win an argument here—the reason I wrote the above is 
> that I think it’s correct, and I was trying to figure out whether it was 
> in any way consistent with the problem you have.

Indeed, we're on the same page regarding our idea of ULAs -- and 
probably most of us are.

The problems comes from the terminology and definitions that we employ, 
from current RFCs.

> I think Brian has said that the “scoped architecture” is just not how 
> things actually work in real life, with which I agree, so the fact that 
> you can’t explain it to anyone is not a big shock. I think RFC 4007 says 
> some interesting and useful things. It might be worthwhile to write a 
> new document that’s a sort of Talmudic commentary on RFC 4007.

I don't mind that. But that would still leave us with a Proposed 
Standard "IPv6 Scoped Addressing Architecture" (RFC4007) that is at odds 
with other specs (e.g., RFC4291/RFC4193).

> What I do not want to see is some kind of effort to rationalize ULAs 
> into something other than what they are at present, which is quite useful.

I do agree that ULAs are useful, indeed. And the intent is certainly 
*not* to change what ULAs are, but rather to have consistent terminology 
and documents.

Clarifying the terminology would probably also help e.g. direct 
libraries or language macros in how they should consider ULA's attributes.

Thanks,

---

From: David Farmer <[email-masked]>
Date: Sat, 13 Feb 2021 03:00:36 -0600

On Fri, Feb 12, 2021 at 4:37 PM Fred Baker <[email-masked]> wrote:

>
> I think I might describe it using the phrase "routing scope" or something
> akin to it. An address, any address, is usable within the range it is
> advertised to in routing, router advertisements, and so on - and it is
> unreasonable to expect routers to actively limit that apart from some form
> of configuration to do so. So to my mind, statements to the effect that
> ULAs should or should not be limited to (or from) some domain are not
> instructions to routing implementations per se, but instructions to people
> that configure BGP accordingly. Link-local addresses are confined to a
> implementations do not advertise a certain prefix off-LAN, and ULAs are
> confined to a given domain not because someone wrote it in an RFC, but
> because routers are not configured to (are configured to not) advertise
> them to external BGP peers and (hopefully) BGP peers refuse them if
> inappropriately advertised to them.
>
> We're trying very hard to construct a useful definition of "site-local"
> without saying so, and it might be worthwhile to actually say so.
>

I don't think "site-local" is the right idea at all. First, let's set aside
ULA for a moment, and look at some other entries in the IANA IPv6
Special-Purpose Address Registry;

Address Block Name RFC Allocation Date Termination Date Source Destination
Forwardable Globally Reachable Reserved-by-Protocol

64:ff9b::/96 IPv4-IPv6 Translat. [RFC6052 <https://www.iana.org/go/rfc6052>]
2010-10 N/A True True True True False
64:ff9b:1::/48 IPv4-IPv6 Translat. [RFC8215
<https://www.iana.org/go/rfc8215>] 2017-06 N/A True True True False False
100::/64 Discard-Only Address Block [RFC6666
<https://www.iana.org/go/rfc6666>] 2012-06 N/A True True True False False

2001:2::/48 Benchmarking [RFC5180 <https://www.iana.org/go/rfc5180>][RFC
Errata 1752 <http://www.rfc-editor.org/errata_search.php?eid=1752>] 2008-04
N/A True True True False False

2001:4:112::/48 AS112-v6 [RFC7535 <https://www.iana.org/go/rfc7535>] 2014-12
N/A True True True True False

2620:4f:8000::/48 Direct Delegation AS112 Service [RFC7534
<https://www.iana.org/go/rfc7534>] 2011-05 N/A True True True True False
fc00::/7 Unique-Local [RFC4193 <https://www.iana.org/go/rfc4193>] [RFC8190
<https://www.iana.org/go/rfc8190>] 2005-10 N/A True True True False [4
<https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml#note4>
] False
fe80::/10 Link-Local Unicast [RFC4291 <https://www.iana.org/go/rfc4291>]
2006-02 N/A True True False False True

I want to call your attention to the Local-Use IPv4/IPv6 Translation
Prefix (not the WKP), the Discard-Only Prefix, and the IPv6 Benchmarking
Prefix, they are not Globally Reachable but are Forwardable. Since they are
Forwardable they can't be "Link-Local Scope". But, they can't be "Global
Scope" either, there will most certainly be other interfaces on the
Internet that have the same address, and that is acceptable as they are
intended to be administratively limited and their uniqueness is the
responsibility of an administrator.

So, I think we need a third scope, I propose the "Admin Scope", or the
"Admin-Limited Scope", but I'm open to other ideas for the name. However,
it can't be Site-Local, we deprecated that. Further, this third scope,
while in many cases will be a Site, it also needs to cover multi-site
enterprises and even confederations and cooperating Autonomous Systems,
which go well beyond any reasonable definition of a Site.

How do we define this third scope; this scope exists logically between the
Link-Local and Global Scopes, with a local administrator defining the
precise boundary between it and the Global Scope, including, but not
limited to a site boundary, with the local administrator ensuring the
uniqueness within the scope they define.

Now if we agree a third scope is necessary, then ULA most logically belongs
in this new third scope that is in between Link-Local and Global. Yes, if
the administrator randomly selects the ULA prefix as defined in RFC4193, it
is highly unlikely there will be an overlap, however, the administrator
still has the responsibility to reject any overlapping randomly selected
prefix to ensure uniqueness within the scope that they are administratively
defining.

Note, the IPv4/IPv6 Translation Well-Known Prefix and the AS112 Prefixes
included above, are Global Scope, but more accurately they are Anycast
Global Scope Prefixes.

Thanks

-- 
===============================================
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: Fernando Gont <[email-masked]>
Date: Sat, 13 Feb 2021 06:19:44 -0300

Hello, David,

On 13/2/21 06:00, David Farmer wrote:

> I don't think "site-local" is the right idea at all. First, let's set 
> aside ULA for a moment, and look at some other entries in the IANA IPv6 
[....]
> Prefix, they are not Globally Reachable but are Forwardable. Since they 
> are Forwardable they can't be "Link-Local Scope". But, they can't be 
> "Global Scope" either, there will most certainly be other interfaces on 
> the Internet that have the same address, and that is acceptable as they 
> are intended to be administratively limited and their uniqueness is the 

Good grief!

> "Admin-Limited Scope", but I'm open to other ideas for the name. 
> However, it can't be Site-Local, we deprecated that

"Admin-limited scope" seems fine -- and conveys the intended meaning, it 
seems.

[...]
> How do we define this third scope; this scope exists logically between 
> the Link-Local and Global Scopes, with a local administrator defining 
> the precise boundary between it and the Global Scope, including, but not 
> Now if we agree a third scope is necessary,

Well, whether we call it out or not, as per RFC4007:

               scope(LL) < scope(ULA) < scope(GUA)

So it's more about acknowledging facts than about introducing or needing 
a new scope.  The same applies to the addresses you mentioned before.

> then ULA most logically 
> belongs in this new third scope that is in between Link-Local and 
> Global. Yes, if the administrator randomly selects the ULA prefix as 
> defined in RFC4193, it is highly unlikely there will be an overlap, 
> however, the administrator still has the responsibility to reject any 
> overlapping randomly selected prefix to ensure uniqueness within the 
> scope that they are administratively defining.

Agreed.

Thanks,

---

From: Ted Lemon <[email-masked]>
Date: Sat, 13 Feb 2021 09:54:50 -0500

On Feb 13, 2021, at 4:19 AM, Fernando Gont <[email-masked]> wrote:
> So it's more about acknowledging facts than about introducing or needing a new scope.  The same applies to the addresses you mentioned before.

No. scope(LL) < scope(ULA) and scope(LL) < scope(GUA) but scope(ULA) ? scope(GUA). That is, any particular ULA may or may not be global in scope.

The problem with admin scope is that it’s not a definitional scope, but rather an operational scope. Which may be the problem—we are using the term “scope” when that’s not specific enough—we could mean “by definition” or “in practice” scope, but we aren’t making that clear.  Of course, these are illustrative terms—I’m not saying we should switch to this terminology.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 13 Feb 2021 13:09:43 -0300

Hi, Ted,

On 13/2/21 11:54, Ted Lemon wrote:
> On Feb 13, 2021, at 4:19 AM, Fernando Gont <[email-masked] 
>> So it's more about acknowledging facts than about introducing or 
>> needing a new scope.  The same applies to the addresses you mentioned 
>> before.
> 
> No. scope(LL) < scope(ULA) and scope(LL) < scope(GUA) but scope(ULA) ? 
> scope(GUA). That is, any particular ULA may or may not be global in scope.

You cannot attest that any ULA is globally unique. They are randomized, 
in a de-centralized manner, without any sort of coordination (i.e., no 
global registry).

If they were "global scope", the "topological span" would be "the 
Internet". And when you compute the birthday paradoz for *all* ULA-based 
networks in the Internet, you actually get sort of a guarantee that your 
prefix is being used elsewhere.

> The problem with admin scope is that it’s not a definitional scope, but 
> rather an operational scope.

But it still plays nicely with the above definition of scope....

> Which may be the problem—we are using the 
> term “scope” when that’s not specific enough—we could mean “by 
> definition” or “in practice” scope, but we aren’t making that clear. 

The definition of scope (and of global scope) are quite clear in 
RFC4007: "uniqueness of the address in the topological span that 
represents the scope"

Cheers,

---

From: Michael Richardson <[email-masked]>
Date: Sat, 13 Feb 2021 13:30:12 -0500

Fernando Gont <[email-masked]> wrote:
    >> Brian E Carpenter <[email-masked]> wrote: > ULAs SHOULD
    >> be treated exactly like GUAs for all practical purposes > (including
    >> using a default router for them), with the exception that > they MUST
    >> be filtered by border routers at a domain boundary that is > defined
    >> administratively. The only extra requirement is that ULA > prefixes
    >> MUST be unique within that domain boundary. That's all, I > think.
    >>

    > network if they are employing the address space of your network (i.e.,

That's not what I think of BCP38.
And that's not what BCP38 section 3 says.

It has nothing to do with what your address space is, and everything to do
what your routes to their address says.
What you describe is a subset of BCP38, applicable to stub networks only.

BCP38 means that you don't accept packets with source addresses that you
could not route back in that direction.
It doesn't work in the DFZ, and at peering points.
The rule you cited can also be useful, but it's not the same thing.

Either way, it does catch a huge amount of stuff, including keeping
ULAs from escaping.

    > filtering ULAs at my CPE router would "break" traceroute.

1) I think your ISP is broken, but...
2) If your default route is unadorned with a source address restriction, and
   since it points to your ISP, they aren't incorrect.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 13 Feb 2021 13:34:50 -0500

David Farmer <farmer=[email-masked]> wrote:
    > "Admin-Limited Scope", but I'm open to other ideas for the
    > name. However, it can't be Site-Local, we deprecated that. Further,
    > this third scope, while in many cases will be a Site, it also needs to
    > cover multi-site enterprises and even confederations and cooperating
    > Autonomous Systems, which go well beyond any reasonable definition of a
    > Site.

I am happy with Admin Scope.
RFC7346 also clarified Realm Scope for multicast.

We needed this (Realm) in LLNs that use different kinds of L2s, (such as
BTLE+802.15.4, or wifi+wired) but wished to multicast across it all.

---

From: David Farmer <[email-masked]>
Date: Sat, 13 Feb 2021 13:25:50 -0600

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

> So it's more about acknowledging facts than about introducing or needing a
> new scope.  The same applies to the addresses you mentioned before.
>
>

Wait a minute! It doesn't say SOME addresses in the global scope are
globally unique, it says ALL addresses in the global scope are globally
unique. Unless each and every ULA address is globally unique, then ULA
can't be global scope.

And by what definition of global scope are the Local-Use IPv4/IPv6
Translation Prefix, the Discard-Only Prefix, and the IPv6 Benchmarking
Prefix global scope?

If all IPv6 addresses except the unspecified address, the loopback address,
and Link-Local addresses are global scope, then either the words "scope" or
"unique" are meaningless.

> rather an operational scope. Which may be the problem—we are using the term
> “scope” when that’s not specific enough—we could mean “by definition” or
> “in practice” scope, but we aren’t making that clear.  Of course, these are
> illustrative terms—I’m not saying we should switch to this terminology.
>

I think you are saying the idea of "IPv6 address scope" is meaningless
then, at least using the current interface uniqueness criterion.

Furthermore, since ANY GUA can be an Anycast address even GUA technically
fails the uniqueness criterion as stated.

If you are going to insist there is no third scope in between Link-Local
and Global Scope, then we should simply discard the uniqueness criterion as
any meaningful part of the definition of IPv6 address scope.

Thanks

---

From: Ted Lemon <[email-masked]>
Date: Sat, 13 Feb 2021 14:32:10 -0500

On Feb 13, 2021, at 2:25 PM, David Farmer <[email-masked]> wrote:
> Wait a minute! It doesn't say SOME addresses in the global scope are globally unique, it says ALL addresses in the global scope are globally unique. Unless each and every ULA address is globally unique, then ULA can't be global scope.
> 
> And by what definition of global scope are the Local-Use IPv4/IPv6 Translation Prefix, the Discard-Only Prefix, and the IPv6 Benchmarking Prefix global scope?

I think we agreed that RFC 4007 makes some statements that seem incomplete or inapplicable to the present-day networks we all work with. One way to fix it is to add more scopes. Another way is to tweak the definition of the described scopes.

The problem with things like “admin scope” is that it doesn’t help me. Suppose an address is “admin scope.” Okay, how does my behavior change? Can you clearly state a rule that describes what my behavior should be?

If not, I claim it’s useless to define that scope.

Of course “my” could mean end systems, or routers, or users, or administrators, so that’s another terminology discussion to have…

So what I think “global scope” means is “there isn’t some context in which, by definition, this address is invalid.”

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 14 Feb 2021 09:03:40 +1300

> (Note: I'm not necessarily arguing in favor of this.)

I think it makes sense, since the basic scenario is to have one ULA
for local communication and one GUA for Internet-wide communication.
Having more than one ULA prefix on a link is rather unnatural.
 
> Deprecate/rev RFC4007? :-)

I think we'd have a lot of documents to touch if we wanted to resolve
this rather than just live with it

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 14 Feb 2021 09:18:32 +1300

> (this one is documented in our draft, but credit goes to Brian for 

The fact is that I spotted it due to an issue with running code.
Just for fun, here is the test for ULAness according to the Python
ipaddress module's semantics:

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)

> interpretation of such attributes?  Should they be changed? Why, or why not?

A bit off topic, but I think the .is_private attribute is a very poor
choice, because it might be misunderstood as implying privacy properties.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Sat, 13 Feb 2021 17:15:41 -0300

On 13/2/21 16:32, Ted Lemon wrote:
> On Feb 13, 2021, at 2:25 PM, David Farmer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>> globally unique, it says ALL addresses in the global scope are 
>> globally unique. Unless each and every ULA address is globally unique, 
>> then ULA can't be global scope.
>>
[....]
> 
> The problem with things like “admin scope” is that it doesn’t help me. 
> Suppose an address is “admin scope.” Okay, how does my behavior change? 
> Can you clearly state a rule that describes what my behavior should be?

RFC6724 (Source Addr Selection).

It has a rule based on address scopes.

(Unfortunately, the rule for ULAs needs to be conveyed via a prefix, 
because of the current definition of the ULA scope).

> So what I think “global scope” means is “there isn’t some context in 
> which, by definition, this address is invalid.”

Well, other addresses also share the same property -- they are valid, 
but they identify a different thing -- an interface in a different 
subnet.  e.g., address fe80::1 is valid on avery single network segment 
-- but the issue is that, en each of them, it most likely identifies a 
different thing. -- and that comes from the uniqueness property.

So you can think of global scope as implying "being globally unique", or 
as "the address identifies the same thing, regardless of where the 
address is processed".

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 13 Feb 2021 17:18:40 -0300

> Having more than one ULA prefix on a link is rather unnatural.

BUt that's again ULAs being special. And they usually have properties of 
"private" addresses -- e.g., can generally be expected to be valid if 
your link to your ISP goes down, are more unlikely of being renumbered, etc.

> this rather than just live with it

On a quick though, it would seem to me the necessary documents are 
RFC4291, RFC4007, and RFC4193.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 13 Feb 2021 17:33:00 -0300

Hi, Brian,

On 13/2/21 17:18, Brian E Carpenter wrote:
[....]
>               and not a.is_unspecified)

IIRC, I don't remember seeing a "is_ula" attribute. -- will recheck.

> choice, because it might be misunderstood as implying privacy properties.

I believe the name attribute is borrowed from the IPv4 world (i.e., 
RFC1918).

Thanks,

---

From: Ted Lemon <[email-masked]>
Date: Sat, 13 Feb 2021 15:45:20 -0500

On Feb 13, 2021, at 3:15 PM, Fernando Gont <[email-masked]> wrote:
> Well, other addresses also share the same property -- they are valid, but they identify a different thing -- an interface in a different subnet.  e.g., address fe80::1 is valid on avery single network segment -- but the issue is that, en each of them, it most likely identifies a different thing. -- and that comes from the uniqueness property.

Yes, but a local address is never valid to forward, by definition. That’s what I mean by “by definition.”

---

From: Ted Lemon <[email-masked]>
Date: Sat, 13 Feb 2021 15:47:07 -0500

On Feb 13, 2021, at 3:18 PM, Fernando Gont <[email-masked]> wrote:
> BUt that's again ULAs being special. And they usually have properties of "private" addresses -- e.g., can generally be expected to be valid if your link to your ISP goes down, are more unlikely of being renumbered, etc.

If your link is numbered with ULAs, then you’ll choose a ULA whenever you’re communicating with another ULA, because of the longest match rule.

Source address selection is below the level of naming, so you’ve already picked your destination address by the time you start doing it.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 14 Feb 2021 10:11:00 +1300

> IIRC, I don't remember seeing a "is_ula" attribute. -- will recheck.

No, there isn't. But I needed it in my code, so I wrote the function.
(It was a bit purist to write it that way rather than using the fc00::/7 mask)

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Sat, 13 Feb 2021 18:03:03 -0300

On 13/2/21 17:47, Ted Lemon wrote:
> On Feb 13, 2021, at 3:18 PM, Fernando Gont <[email-masked] 
>> BUt that's again ULAs being special. And they usually have properties 
>> of "private" addresses -- e.g., can generally be expected to be valid 
>> if your link to your ISP goes down, are more unlikely of being 
>> renumbered, etc.
> 
> If your link is numbered with ULAs, then you’ll choose a ULA whenever 
> you’re communicating with another ULA, because of the longest match rule.

Scope rule is # 2.Longest match rule is #8.

So you don't necessarily get the same outcome.

> Source address selection is below the level of naming, so you’ve already 
> picked your destination address by the time you start doing it.

For Dst Addr selection, the scope comparison is, again, rule #2 & rule 
#8, while longest-matching prefix is rule #9.

The proper scopes would probably also benefit the other address "types" 
that David pointed out....

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 13 Feb 2021 18:11:47 -0300

On 13/2/21 17:45, Ted Lemon wrote:
> On Feb 13, 2021, at 3:15 PM, Fernando Gont <[email-masked] 
>> subnet.  e.g., address fe80::1 is valid on avery single network 
>> segment -- but the issue is that, en each of them, it most likely 
>> identifies a different thing. -- and that comes from the uniqueness 
>> property.
> 

Then the definition of scope would become related with what you can or 
cannot do with the address, which seems much more cumbersome that the 
clear definition of scope that we currently have in RFC4007.

And if you want to get into that, then you'd have tricky cases such as a 
host using fe80::1 on two different interfaces and implementing the weak 
end-host mode (RFC1122). Say you have a socket bound to only one address 
on one interface, and receive a packet for that (address, port) but *on 
the other interface*:  Should the node accept the packet? -- Based on 
your definition of scope, it might well do it (because as long as it 
doesn't forward the packet, it's okay).

However, based on the current definition of scope, it shouldn't, because 
each of the interfaces is in a different zone.

I think the change you propose makes things way more complicated that 
simply keeping the scope definitions from RFC4007, and simply 
reclassifying ULAs et al.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 14 Feb 2021 10:17:40 +1300

On 13-Feb-21 22:19, Fernando Gont wrote:
...
>                scope(LL) < scope(ULA) < scope(GUA)

And there's the fallacy. This inequality only makes sense if reachability is strictly a matter of concentric circles. It isn't. Nice math, but not reality.

Slide 4 of https://www.cs.auckland.ac.nz/~brian/scope6.pdf

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Sat, 13 Feb 2021 18:33:05 -0300

> Slide 4 of https://www.cs.auckland.ac.nz/~brian/scope6.pdf

I don't follow. In all of your slides Area(link-local) < Area(ULA) < 
Area(global)....

---

From: Ted Lemon <[email-masked]>
Date: Sat, 13 Feb 2021 16:52:42 -0500

On Feb 13, 2021, at 4:11 PM, Fernando Gont <[email-masked]> wrote:
> I think the change you propose makes things way more complicated that simply keeping the scope definitions from RFC4007, and simply reclassifying ULAs et al.

We seem to be talking in circles. There are two scopes: global and link-local. ULAs are currently global. I am not proposing to change this. We can’t reclassify ULAs as link-local—they would no longer work. The problem is that the definition of global doesn’t match the other details of the definition of ULA, despite that ULAs are defined to be global.

>> On Feb 13, 2021, at 3:18 PM, Fernando Gont <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:

But ULAs are global in scope, so the scope doesn’t come into play if you are choosing between a ULA and a GUA. It only comes into play if your destination is link-local.

> For Dst Addr selection, the scope comparison is, again, rule #2 & rule #8, while longest-matching prefix is rule #9.
> 
> The proper scopes would probably also benefit the other address "types" that David pointed out….

Again, though, ULA is the same scope as GUA, so if there’s a LLA<->LLA choice, you’ll pick that, but otherwise the priority rule (rule 6) prefers a GUA to a ULA as a destination address absent a policy table entry.

This is actually the part that could be problematic, since if we want connections to survive the lost of the ISP uplink, we want to use ULAs for on-network communication (for a single link, LLA will be preferred, so this is only a problem for a multi-subnet home). However, the RFC actually addresses this by suggesting that if a ULA is valid on-link, a policy table entry could be added for that specific ULA /48. The document is not as clear as I’d like about what that policy table entry should look like, and I have to admit that I haven’t thought this through, so I don’t know either.

It’s perhaps worth noticing that in the presence of Happy Eyeballs and gethostbyname(), I don’t know how many applications are actually using the destination address sorting rules.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 13 Feb 2021 18:53:25 -0300

On 13/2/21 18:33, Fernando Gont wrote:
>> And there's the fallacy. This inequality only makes sense if 
>> reachability is strictly a matter of concentric circles. It isn't. 
>> Nice math, but not reality.
>>

I assume that the "site" refers to the (deprecated) "site-local" 
addresses, and what you try to point out in slide #4  is that it's at 
odda with RFC4007, which specifies there can only be one zone for each 
scope.

However, I consider *that* requirement rather flawed.

Slide #4 could indeed be the case where a node attaches to a subnet 
where .e.g two different routers advertise different ULA prefixes -- and 
one or the two of them also advertises global prefixes.

Each shaded "site" constitutes a different layer (as in John Day's PNA).
In principle, hosts on each of the shaded sites cannot reach hosts on 
the other shaded site (since they are in different layers).

But all can communicate via the global layer.

Not sure what'd be the problem with that...

---

From: Fernando Gont <[email-masked]>
Date: Sat, 13 Feb 2021 19:08:06 -0300

On 13/2/21 18:52, Ted Lemon wrote:
> On Feb 13, 2021, at 4:11 PM, Fernando Gont <[email-masked] 
> We seem to be talking in circles. There are two scopes: global and 
> link-local. ULAs are currently global. I am not proposing to change 
> this. We can’t reclassify ULAs as link-local—they would no longer work. 
> The problem is that the definition of global doesn’t match the other 
> details of the definition of ULA, despite that ULAs are defined to be 
> global.

We can introduce a new scope, "admin local" (or whatever), and mark the 
ULA space as such. -- That's what David and myself propose.

>>> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>> BUt that's again ULAs being special. And they usually have 
>>>> properties of "private" addresses -- e.g., can generally be expected 
>>>> to be valid if your link to your ISP goes down, are more unlikely of 
>>>> being renumbered, etc.
> But ULAs are global in scope, so the scope doesn’t come into play if you 
> are choosing between a ULA and a GUA. It only comes into play if your 
> destination is link-local.

The scope definition for ULAs is flawed. It doesn't follow RFC4007.

> Again, though, ULA is the same scope as GUA, so if there’s a LLA<->LLA 
> choice, you’ll pick that, but otherwise the priority rule (rule 6) 
> prefers a GUA to a ULA as a destination address absent a policy table entry.

You had asked if there was any use in fixing the scope definition (i.e., 
whether there'd would be any practical implications from it). My answer 
was "yes, if you fix it, it will be considered by RFC6724, which 
compares the scope of addresses).

> This is actually the part that could be problematic, since if we want 
> connections to survive the lost of the ISP uplink, we want to use ULAs 
> for on-network communication (for a single link, LLA will be preferred, 
> so this is only a problem for a multi-subnet home).

If a new scope was created such that scope(LL) < scope(ULA) < 
scope(GUA),  this rule in Dest Address selection would prefer ULAs:

    Rule 8: Prefer smaller scope.
    If Scope(DA) < Scope(DB), then prefer DA.  Similarly, if Scope(DA) >
    Scope(DB), then prefer DB.

> It’s perhaps worth noticing that in the presence of Happy Eyeballs and 
> gethostbyname(), I don’t know how many applications are actually using 
> the destination address sorting rules.

All but browsers? Or am I missing something?

Thanks,

---

From: Ted Lemon <[email-masked]>
Date: Sat, 13 Feb 2021 17:14:50 -0500

On Feb 13, 2021, at 17:08, Fernando Gont <[email-masked]> wrote:
> If a new scope was created such that scope(LL) < scope(ULA) < scope(GUA),  this rule in Dest Address selection would prefer ULAs:
> 
> 

No, rule 6 would already have chosen the GUA. 

> All but browsers? Or am I missing something?

Any application that doesn’t have a library that does dest addr selection is going to just pick the first address it finds, or try them all, or something like that.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 14 Feb 2021 11:25:44 +1300

> I don't follow. In all of your slides Area(link-local) < Area(ULA) < 

I probably need to add the case that isn't shown, i.e. "GUA" prefixes *not* being routed Internet-wide, at which point the scope difference between a ULA prefix and a "GUA" prefix sort of vanishes. Area(global) isn't really a thing, just as the BGP4 default-free zone isn't really a thing. And when Area(ULA1) overlaps with Area(ULA2) you suddenly have another scope that is Area(ULA1+ULA2). 

So guess what I'm trying to say is the inequality isn't the least bit useful.

    Brian

---

From: David Farmer <[email-masked]>
Date: Sat, 13 Feb 2021 18:45:45 -0600

On Sat, Feb 13, 2021 at 3:17 PM Brian E Carpenter <
[email-masked]> wrote:

> And there's the fallacy. This inequality only makes sense if reachability
> is strictly a matter of concentric circles. It isn't. Nice math, but not
> reality.
>

I think I'm hearing,

1. Rewrite RFC4007 to only discuss zone indexes for the Link-Local address
on an interface, maybe rename then too. Junk the rest, it only confuses
things.

2. Rewrite RFC4291 to only refer to Link Scope (for Link-Local Addresses
and the Loop-Back Address) and Global Scope for all other Unicast addresses
except the unspecified address, eliminate all inference to other unicast
scopes and the size of scopes. All uniqueness for Link-Local address comes
from IID uniqueness provided by DAD, and there should be no discussion of
uniqueness regarding Global Scope in RFC4291, it is only discussed in
RFC4007. Also, eliminate the discussion of IID scope. Leaving Multicast
scope alone.

However, unless we can agree on how to deal with the 64-bit boundary, or
not to touch it, touching RFC4291 will only end in flames.

Is it possible to do anything with RFC4007 without ending in flames?

---

From: Fernando Gont <[email-masked]>
Date: Sun, 14 Feb 2021 03:00:53 -0300

On 13/2/21 19:25, Brian E Carpenter wrote:
> I probably need to add the case that isn't shown, i.e. "GUA" prefixes *not* being routed Internet-wide, at which point the scope difference between a ULA prefix and a "GUA" prefix

I think the scope is defined by the area where the address is meaningful 
(unambiguous). Then, there are lots of reasons for which packets might 
not get routed here or there. -- whether a security policy, or anything 
else.

The point of GUAs having global scope is that the address itself does 
not limit where the addresses can be employed (they are unviversally 
unambiguous, so to speak). Whereas ULA only have local significance 
(with "local" being whatever your deployments make it to mean )

> sort of vanishes. Area(global) isn't really a thing, just as the BGP4 default-free zone isn't really a thing. And when Area(ULA1) overlaps with Area(ULA2)
 >  you suddenly have another scope that is Area(ULA1+ULA2).

IMO, if the areas overlap, the scope ofa ULA1 and ULA2 are still the 
same. One scope is Area(ULA1): all the area where ULA1 addresses are 
unique and can be actively employed. The other one is Area(ULA2).

The intersection of the two areas is part of the scope of each of the 
two ULAs (because in that region both ULA1 and ULA2 are unambiguous)

This is not that different from the overlap of e.g. link-locals and GUAs 
on a local link....

> So guess what I'm trying to say is the inequality isn't the least bit useful.

Well, a scope that is not link-local or global (but something in 
between) doesn't say much other than allowing for some rough 
expectations. e.g., you cannot expect to browse the web with ULAs, the 
services you run on ULAs won't be reaachable by the vast majory of nodes 
connected to the Internet, etc.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 14 Feb 2021 10:43:03 -0500

On Feb 14, 2021, at 1:00 AM, Fernando Gont <[email-masked]> wrote:
> IMO, if the areas overlap, the scope ofa ULA1 and ULA2 are still the same. One scope is Area(ULA1): all the area where ULA1 addresses are unique and can be actively employed. The other one is Area(ULA2).
> 
> The intersection of the two areas is part of the scope of each of the two ULAs (because in that region both ULA1 and ULA2 are unambiguous)

Since you still haven’t clearly articulated what you mean by “scope” with respect to ULA, it doesn’t make sense to say that one ULA has the same or a different scope than another. In any case, what you are describing here is precisely what the “label” entry in an RFC 6724 policy table does. Which is to say, you are not talking about scopes.

> This is not that different from the overlap of e.g. link-locals and GUAs on a local link….

Since the different treatment of GUAs and LLAs on a link is something that can be known by definition, and thus be handled by if-then-else statements rather than by table lookups, I would say that they are quite different.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Feb 2021 08:39:34 +1300

On 15-Feb-21 04:43, Ted Lemon wrote:
> On Feb 14, 2021, at 1:00 AM, Fernando Gont <[email-masked] <mailto:[email-masked]>> wrote:

Exactly. The reachability of a given routeable prefix is defined *only* by the contents of the forwarding tables in a set of interconnected routers, and by definition those tables must not include any LL prefix.

At this point I'm thinking that we'd be better off not using the word "scope" at all. It's an abstraction that doesn't seem to describe anything in the real world.

   Brian

---

From: Ted Lemon <[email-masked]>
Date: Sun, 14 Feb 2021 14:57:18 -0500

On Feb 13, 2021, at 7:45 PM, David Farmer <farmer=[email-masked]> wrote:
> I think I'm hearing, 
> 
> 1. Rewrite RFC4007 to only discuss zone indexes for the Link-Local address on an interface, maybe rename then too. Junk the rest, it only confuses things.
> 
> 2. Rewrite RFC4291 to only refer to Link Scope (for Link-Local Addresses and the Loop-Back Address) and Global Scope for all other Unicast addresses except the unspecified address, eliminate all inference to other unicast scopes and the size of scopes. All uniqueness for Link-Local address comes from IID uniqueness provided by DAD, and there should be no discussion of uniqueness regarding Global Scope in RFC4291, it is only discussed in RFC4007. Also, eliminate the discussion of IID scope. Leaving Multicast scope alone.
> 
> However, unless we can agree on how to deal with the 64-bit boundary, or not to touch it, touching RFC4291 will only end in flames.
> 

From my perspective at least, this conversation has been really useful, but I don’t see a cause to rewrite any documents. Being forced to confront my assumptions as a result of Fernando’s questions resulted in me discovering that a lot of things I hadn’t realized were clearly specified are actually clearly specified. The dissonance between RFC 4193 and RFC 4007 is interesting, but RFC 6724 addresses this dissonance quite satisfactorily. It’s possible that there’s an opportunity to write a small ops document here to make clear how to populate the policy table automatically based on prefixes seen on an interface, but I don’t think we have a Really Big Problem to solve here.

If people are confused, it’s probably because they haven’t read these documents.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 14 Feb 2021 17:27:45 -0300

Hi, Ted,

On 14/2/21 12:43, Ted Lemon wrote:
> Since you still haven’t clearly articulated what you mean by “scope” 
> with respect to ULA, it doesn’t make sense to say that one ULA has the 
> same or a different scope than another.

Scope is "scope" as defined in RFC4007:

For ULA, that means the site or organization that you have 
administrative control (since that's the only way in which you can 
guaranteed ULAs to be unambiguous)

> In any case, what you are 
> describing here is precisely what the “label” entry in an RFC 6724 
> policy table does. Which is to say, you are not talking about scopes.

How could you possibly an inconsistency in RFC4194 and RFC4007 with a 
"source address selection" document?

> Since the different treatment of GUAs and LLAs on a link is something 
> that can be known by definition, and thus be handled by if-then-else 
> statements rather than by table lookups, I would say that they are quite 
> different.

The fact that things "work" in practice doesn't imply rhar the 
architecture or it's definitions are correct.

Again, this discussion boils down to:

But ULAs, and several other prefixes raised by David ar considered 
"global scope" by RFC4291. Isn't the inconsistency clear?

Thanks,

---

From: Ted Lemon <[email-masked]>
Date: Sun, 14 Feb 2021 15:39:02 -0500

On Feb 14, 2021, at 3:27 PM, Fernando Gont <[email-masked]> wrote:
> But ULAs, and several other prefixes raised by David ar considered "global scope" by RFC4291. Isn't the inconsistency clear?

No. I think you’re getting confused between theory and practice.

In theory, a GUA is globally unique. But there’s no mechanism for ensuring that this is in fact the case. I could configure a GUA prefix on my local network that’s also in use somewhere else. The “architecture” does not guarantee that I have not done so. The mechanism for ensuring that GUAs are unique is delegation; this is a fairly solid mechanism, but what actually makes GUAs unique is the practicality that if you screw up the allocation and wind up with two GUAs identifying two different interfaces on two different links, you may experience communication difficulties.

In theory, a ULA is unique, because 40 bits of randomness is a lot, and the likelihood of a collision is small. There is no mechanism to enforce uniqueness other than the requirement that ULA prefixes be generated using a random number generator; uniqueness is assumed, just as it is with GUAs.

So in fact in terms of architecture there is no difference between ULAs and GUAs. They are both global in scope. It’s true that our system for ensuring the uniqueness of GUAs is less likely to produce a collision than our system for ensuring the uniqueness of ULAs, but the meaning of “global” is the same in both cases.

The architectural globalness of ULAs and GUAs does not provide any guarantee. Rather, it is a statement of intent: this is what we intend to be true about GUAs and ULAs.

The reason that RFC 6724 solves this for me is that it explains how, practically, to manage ULAs and GUAs so that the architectural intention of the appearance of global uniqueness is not violated.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 14 Feb 2021 15:40:45 -0500

This would have made a lot more sense if I’d said, as I intended:

>  if you screw up the allocation and wind up with a single GUA identifying two different interfaces on two different links on two different hosts, you may experience communication difficulties.

---

From: David Farmer <[email-masked]>
Date: Sun, 14 Feb 2021 15:00:29 -0600

On Sun, Feb 14, 2021 at 1:57 PM Ted Lemon <[email-masked]> wrote:

> From my perspective at least, this conversation has been really useful,
> but I don’t see a cause to rewrite any documents. Being forced to confront
> my assumptions as a result of Fernando’s questions resulted in me
> discovering that a lot of things I hadn’t realized were clearly specified
> are actually clearly specified. The dissonance between RFC 4193 and RFC
> 4007 is interesting, but RFC 6724 addresses this dissonance quite
> satisfactorily. It’s possible that there’s an opportunity to write a small
> ops document here to make clear how to populate the policy table
> automatically based on prefixes seen on an interface, but I don’t think we
> have a Really Big Problem to solve here.
>

Actually, I think you are correct, complete rewrites are unnecessary.

I still would like to suggest we tighten up the language regarding scope in
RFC4291 once it eventually gets rewritten. As for RFC4007 a minor update
clearing up one point I think would really help. But, let me summarize from
the beginning first;

Prior to RFC3979, there with three (3) IPv6 Address Scopes, Link, Site, and
Global (AKA Internet). The Link and Site Scopes require Zone Indexes or
Zone Identifiers to distinguish an address between Zones of the same Scope
because the same address can exist in each of Zone of a Scopes. For the
Global Scope, Zone Indexes or Zone Identifiers are unnecessary as there is
only one instance or Zone of the Global Scope by definition.

RFC3979 deprecated Site-Local addresses and effectively deprecating the
Site Scope too.

RFC4193 created ULA and specified them as part of the Global Scope, meaning
that Zone Indexes or Zone Identifiers are not associated with ULA addresses
like other addresses within the Global Scope, and nothing more than that.

However, as Fernando points out, ULA cannot be unique across the
entirety of the Internet, and they are only unique within a local domain of
coordination, coordinated by or among local administrator(s). Furthermore,
the reachability of ULA, and other special-use IPv6 addresses intended for
local-use, SHOULD be restricted to this local domain of coordination only.

Whereas, GUA is unique across the entirety of the Internet and is
coordinated by the Internet Registry System, as described in RFC7020.
The reachability of GUA is unrestricted, however, it is subject to the
routing policies of ISPs and other network operators.

As the Internet does not guarantee universal reachability for GUA and only
local reachability is intended for ULA, and other special-use IPv6
addresses intended for local-use, therefore, there is no universal view or
understanding of what is included or contained within the Global Scope.

So I recommend a small update to RFC4007, further quantify the necessary
uniqueness;

Global scope, for uniquely identifying interfaces anywhere in the Internet
*or within the span of reachability for local-use addresses.*

Thanks

---

From: Fernando Gont <[email-masked]>
Date: Sun, 14 Feb 2021 18:14:02 -0300

On 14/2/21 17:39, Ted Lemon wrote:
> On Feb 14, 2021, at 3:27 PM, Fernando Gont <[email-masked] 
> In theory, a GUA is globally unique. But there’s no mechanism for 
> ensuring that this is in fact the case. I could configure a GUA prefix 
> on my local network that’s also in use somewhere else.

That's not a legitimate use for GUAs.  Whereas in the case of ULAs, that 
the *intended* usage.

(the "mechanisms to guarantee" of course only apply to cooperating parties)

The ULA prefix is randomized such that *if you interconnect of ULA-bsed 
networks*, the *prefixes for such networks don't collide*. Global scope 
implies that *all* addresses to be considered, rather than the subset 
you want to employ for interconnection.

> In theory, a ULA is unique, because 40 bits of randomness is a lot, and 
> the likelihood of a collision is small.

This statement is incorrect.

It's only correct if you consider *a subset* of ULA prefixes. But for 
ULAs to be unique, you should be considering *all ULAs* in the Internet.
And when you compute the birthday paradox for that, you get a 
probability of ~1 of getting collisions.

> There is no mechanism to enforce 
> uniqueness other than the requirement that ULA prefixes be generated 
> using a random number generator; uniqueness is assumed, just as it is 
> with GUAs.

In ULAs, it's not assumed. Think about all the machinery and paperwork 
it's needed for you to receive a GUA prefix at home -- that's what it 
takes for your GUA address to be unique.

> So in fact in terms of architecture there is no difference between ULAs 
> and GUAs. They are both global in scope. 

PLease review the definition of scope and global scope from RFC4007, and 
also compute the birthday paradox for ULAs.

> It’s true that our system for 
> ensuring the uniqueness of GUAs is less likely to produce a collision 
> than our system for ensuring the uniqueness of ULAs, but the meaning of 
> “global” is the same in both cases.

Less likely? Everyone that employs IPv6 on the internet does so with 
unique GUAs.  OTOH, as noted, ULAs are almost guaranteed to collide at 
blobal scale.

> The architectural globalness of ULAs and GUAs does not provide any 
> guarantee. Rather, it is a statement of intent: this is what we intend 
> to be true about GUAs and ULAs.

I'm lost here....

> The reason that RFC 6724 solves this for me is that it explains how, 
> practically, to manage ULAs and GUAs so that the architectural intention 
> of the appearance of global uniqueness is not violated.

IMO, RFC6724 has nothing to do with the architecture. When it comes to 
ULAs, they are only spelled out because, since they are currently 
flagged as global, then only way you can do something special with them 
is to cherry-pick them via their associated prefix. Whereas if the scope 
was properly definied, they would be handled automagically as, e.g., 
link locals. (see Section 10.4 of RFC 10.4 of RFC6724).

Thanks,

---

From: Ted Lemon <[email-masked]>
Date: Sun, 14 Feb 2021 16:32:33 -0500

On Feb 14, 2021, at 4:00 PM, David Farmer <[email-masked]> wrote:
> So I recommend a small update to RFC4007, further quantify the necessary uniqueness;
> 
> Global scope, for uniquely identifying interfaces anywhere in the Internet *or within the span of reachability for local-use addresses.*

I think this whole discussion may have something to do with why site-local was deprecated, although I’m just guessing because I didn’t participate in that discussion.

My question to you is this: how does your proposed update help anybody to understand?

If we were to update the text, I would suggest something like this:

Global scope, for uniquely identifying interfaces anywhere on the Internet. Note that when we say an address is “globally unique,” this is a definitional assertion: such an address is to be treated as globally unique by hosts and routers. Mechanisms for ensuring that this definitional assertion is not violated exist for each type of globally scoped address, and in some cases rather than ensuring that a globally /scoped/ address is in fact unique, these mechanisms ensure that the use of such addresses is constrained to contexts in which they are /known/ to be unique.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 14 Feb 2021 16:34:01 -0500

On Feb 14, 2021, at 4:14 PM, Fernando Gont <[email-masked]> wrote:
> That's not a legitimate use for GUAs.  Whereas in the case of ULAs, that the *intended* usage.

Untrue. ULAs are intended to be globally unique. Your practical objections are correct, but have nothing to do with the architecturally defined scope of a ULA.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 14 Feb 2021 18:52:56 -0300

On 14/2/21 18:32, Ted Lemon wrote:
[...]
> Global scope, for uniquely identifying interfaces anywhere on the 
> Internet. Note that when we say an address is “globally unique,” this is 
> a definitional assertion: such an address is to be treated as globally 
> unique by hosts and routers. Mechanisms for ensuring that this 
> definitional assertion is not violated exist for each type of globally 
> scoped address, and in some cases rather than ensuring that a globally 
> /scoped/ address is in fact unique, these mechanisms ensure that the use 
> of such addresses is constrained to contexts in which they are /known/ 
> to be unique.

If the definition of scope is that of RFC4007:

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

ULAs can't be global.

So, either ULAs (and others) are not global, or scope means something 
different than what's in RFC4007.

i.e. the key is in the definition of "scope".

Since I find the definition of scope in RFC4007 quite succint and clear, 
my take is/was that the easier and simpler fix is that ULAs are not global.

Thanks,

---

From: David Farmer <[email-masked]>
Date: Sun, 14 Feb 2021 15:54:18 -0600

On Sun, Feb 14, 2021 at 3:32 PM Ted Lemon <[email-masked]> wrote:

> I think this whole discussion may have something to do with why site-local
> was deprecated, although I’m just guessing because I didn’t participate in
> that discussion.
>
> Internet. Note that when we say an address is “globally unique,” this is a
> definitional assertion: such an address is to be treated as globally unique
> by hosts and routers. Mechanisms for ensuring that this definitional
> assertion is not violated exist for each type of globally scoped address,
> and in some cases rather than ensuring that a globally /scoped/ address is
> in fact unique, these mechanisms ensure that the use of such addresses is
> constrained to contexts in which they are /known/ to be unique.
>
>
So when I read "uniquely identifying interfaces anywhere on the Internet",
that suggests to me the entirety of the Internet, basically anywhere and
everywhere, whether or not I can actually successfully get packets there or
not.  I think that statement needs to be qualified or limited by
reachability in some way. It doesn't need to specifically mention
local-use, but I think it clarifies the issue.  The fact that someone else
on the other side of the planet or even across the street is using the same
ULA prefixes as me doesn't really matter because I can't get packets there,
but that isn't that what that statement says.

Thanks

---

From: Fernando Gont <[email-masked]>
Date: Sun, 14 Feb 2021 18:54:26 -0300

On 14/2/21 18:34, Ted Lemon wrote:
> On Feb 14, 2021, at 4:14 PM, Fernando Gont <[email-masked] 
> Untrue. ULAs are intended to be globally unique. 

Could you compute the birthday paradox for *all ULAs* on the internet, 
and share the math/results?

Thanks,

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Sun, 14 Feb 2021 22:25:53 +0000

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

> ULAs can't be global.

I think we've been going around and around on this.

Maybe it's good to compare the ULA situation with RFC 1918 private IPv4 addresses. In such a comparison, it is clear that RFC 1918 addresses "can't be global," and must be used only within some admin domain. But it is also clear that the intention, or hope, of ULAs, is that they be globally unique.

Yes, in practice, we know that there is a non-zero probability that ULAs won’t be globally unique, but at the same time, it is false to claim that ULAs "can’t be" globally unique. No one is telling us, "Go ahead and duplicate your ULAs, among admin domains, because they will be filtered out at border routers anyway."

At most, I'd add somewhere a notion of "only guaranteed within an administrative domain," and be done with it. I just don’t see how that is so confusing for anyone.

Bert

---

From: Ted Lemon <[email-masked]>
Date: Sun, 14 Feb 2021 17:38:30 -0500

On Feb 14, 2021, at 4:54 PM, David Farmer <[email-masked]> wrote:
> So when I read "uniquely identifying interfaces anywhere on the Internet", that suggests to me the entirety of the Internet, basically anywhere and everywhere, whether or not I can actually successfully get packets there or not.  I think that statement needs to be qualified or limited by reachability in some way. It doesn't need to specifically mention local-use, but I think it clarifies the issue.  The fact that someone else on the other side of the planet or even across the street is using the same ULA prefixes as me doesn't really matter because I can't get packets there, but that isn't that what that statement says.

The problem is, then you have to say what “local” means, and it doesn’t mean anything specific. And, specifically, scope right now can be used as a definitional meaning. If you add “site scope,” it doesn’t work, because it’s no longer definitional—it’s operational. Trying to do the same thing with ULA will have the same outcome.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 14 Feb 2021 17:38:56 -0500

On Feb 14, 2021, at 4:54 PM, Fernando Gont <[email-masked]> wrote:
> Could you compute the birthday paradox for *all ULAs* on the internet, and share the math/results?

The word “intend” means something different than the phrase “is in fact.”

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Feb 2021 11:40:57 +1300

> and share the math/results?

I'm not Ted, and my preferred formulation is:

   ULAs are intended to be globally unique for all practical purposes.

Although there is a high probability of some ULA prefixes somewhere
being equal, the probability of your ULA prefix being equal to your
next-door neighbour's is extremely small.

There's no equivalent statement that can be made for RFC 1918 addresses,
nor for the deprecated IPv6 Site Local addresses.

BTW, RFC 4193 seems very clear on this to me:

>>       - Globally unique prefix (with high probability of uniqueness).
...
>>       - In practice, applications may treat these addresses like global
>>         scoped addresses.

    Brian

---

From: David Farmer <[email-masked]>
Date: Sun, 14 Feb 2021 17:51:18 -0600

On Sun, Feb 14, 2021 at 15:34 Ted Lemon <[email-masked]> wrote:

> Untrue. ULAs are intended to be globally unique. Your practical objections
> are correct, but have nothing to do with the architecturally defined scope
> of a ULA.
>

Ok, ULAs clearly belong in the Global Scope, we don’t want to use Zone
Indexes or Identifiers with them. Also, I agree that ULAs are “intended” to
be globally unique, and from all practical and architecture perspectives
they are, with two important caveats, both clearly stated in RFC4193, they
are not intended to be globally reachable and their uniqueness is
probabilistic.

Meaning there are no mathematical or procedural guarantees of uniqueness
for ULAs, especially across the entirety of the Internet. However, since
ULAs SHOULD NOT be globally reachable, from a practical and architectural
perspective, this detail, and inconvenient fact, is irrelevant.

---

From: David Farmer <[email-masked]>
Date: Sun, 14 Feb 2021 18:02:07 -0600

On Sun, Feb 14, 2021 at 4:38 PM Ted Lemon <[email-masked]> wrote:

> The problem is, then you have to say what “local” means, and it doesn’t
> mean anything specific. And, specifically, scope right now can be used as a
> definitional meaning. If you add “site scope,” it doesn’t work, because
> it’s no longer definitional—it’s operational. Trying to do the same thing
> with ULA will have the same outcome.
>

Ok, don't talk about "local" then, but I think we need to caveat "uniquely
identifying interfaces anywhere on the Internet", with reachability in some
way, this is an important caveat for RFC4193. I don't see what it huts
include it in RFC4007. How about "uniquely identifying interfaces anywhere
reachable on the Internet".

---

From: Fernando Gont <[email-masked]>
Date: Sun, 14 Feb 2021 21:12:52 -0300

>     ULAs are intended to be globally unique for all practical purposes.

That's tricky. :-)

ULAs are unique in the topologial span where they are employed.

The thing is that, in *that* topological span, they are unique.

Otherwise, "globally unique for all practical purposes" means "in that 
part of the topology where I care"  (where's "global" implies 
Internet-wide span).

> next-door neighbour's is extremely small.

Doesn't it follow from that that they are intended for some sort of 
org-local, site-local, or admin-defined scope, rather than global?

(same can be said about other prefixes noted by David)

> BTW, RFC 4193 seems very clear on this to me:

Agreed on this.

The question is how RFC4193 fits in RFC4007.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 14 Feb 2021 21:19:41 -0300

On 13/2/21 17:45, Ted Lemon wrote:
> Yes, but a local address is never valid to forward, by definition. 

That's not correct. SIte-local were indeed forward-dable.

You're probably thinking about link-locals.
(Small detail aside: IIRC they seem to be actually forwardable if they 
are forwarded onto the same link (but not across links)).

---

From: Fernando Gont <[email-masked]>
Date: Sun, 14 Feb 2021 21:24:20 -0300

>     ULAs are intended to be globally unique for all practical purposes.

FWIW, in that light, link-locals are also "globally-unique for all 
practical purposes" -- but we don't consider them global-scope.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 14 Feb 2021 21:32:59 -0300

On 14/2/21 20:51, David Farmer wrote:
> 
> 
> On Sun, Feb 14, 2021 at 15:34 Ted Lemon <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Untrue. ULAs are intended to be globally unique. Your practical
>     objections are correct, but have nothing to do with the
>     architecturally defined scope of a ULA.
> 
> 
> Indexes or Identifiers with them. 

For ULAs you might need zone indexes or otherwise specify the interface 
to employ, particularly if you're sending to a ULA address, and you 
don't have any ULAs configured. or, if you have e.g. two interfaces, 
each of which employing ULAs, but you're sending packets to a totally 
different ULA prefix.  Depending on which interface you choose you might 
or might not be able to reach there.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 15 Feb 2021 11:44:55 +1100

> On 15 Feb 2021, at 11:32, Fernando Gont <[email-masked]> wrote:
> 
>> On Sun, Feb 14, 2021 at 15:34 Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
>> Ok, ULAs clearly belong in the Global Scope, we don’t want to use Zone Indexes or Identifiers with them. 
> 
> For ULAs you might need zone indexes or otherwise specify the interface to employ, particularly if you're sending to a ULA address, and you don't have any ULAs configured. or, if you have e.g. two interfaces, each of which employing ULAs, but you're sending packets to a totally different ULA prefix.  Depending on which interface you choose you might or might not be able to reach there.

How’s that different from being in disjoint GUA spaces?  The node in disjoint GUA spaces needs routing information so it should run a routing daemon.  ULA is not special in this respect.

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

-- 
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: Sun, 14 Feb 2021 20:23:34 -0600

> (same can be said about other prefixes noted by David)

They are intended for local-use within the Global Scope this is clearly
stated RFC4193, as well as the blocks I talked about.

> The question is how RFC4193 fits in RFC4007.

All I think we really need to do is qualify the uniqueness with
reachability in RFC4007, which is consistent with RFC4193.

Something like, "uniquely identifying interfaces anywhere reachable on the
Internet", works for me.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 14 Feb 2021 21:24:01 -0500

On Feb 14, 2021, at 19:17, Fernando Gont <[email-masked]> wrote:
> Doesn't it follow from that that they are intended for some sort of org-local, site-local, or admin-defined scope, rather than global?

I think this is the essence of the disconnect. What you are describing is what is handled in policy tables using labels. You are using the term “scope” to mean something it can’t mean.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 15 Feb 2021 01:41:45 -0300

> How’s that different from being in disjoint GUA spaces?  The node in disjoint GUA spaces needs routing information so it should run a routing daemon.  ULA is not special in this respect.

Only difference is that ULAs are kind of guaranteed to be disjoint. BUt 
yes, you're right.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 15 Feb 2021 01:43:57 -0300

> I think this is the essence of the disconnect. What you are describing is what is handled in policy tables using labels. You are using the term “scope” to mean something it can’t mean.

I'm using the scope definition in RFC4007.

OTOH, the explanation for why ULAs are global imply changing the 
definition of scope or global scope from RFC4007.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 15 Feb 2021 02:03:17 -0300

> Maybe it's good to compare the ULA situation with RFC 1918 private IPv4 addresses. In such a comparison, it is clear that RFC 1918 addresses "can't be global," and must be used only within some adm…

The intention is that, *given a subset of ULAs* the probability of 
collision is low.

> Yes, in practice, we know that there is a non-zero probability that ULAs won’t be globally unique, but at the same time, it is false to claim that ULAs "can’t be" globally unique. 

Please compute the birthday paradox assuming that each CPE in the world 
locally-generates a ULA prefix, and share the math with us. (that's what 
global scope means as per RFC4007)

Spoiler: P~1

> No one is telling us, "Go ahead and duplicate your ULAs, among admin domains, because they will be filtered out at border routers anyway."
> 

As per RFC4007:

scope means: topological span where the address is unique.
global means: Internet-wide span

Then we have this notion of "ULAs are 'global scope'", in which "global" 
meaning something different than what "global scope" means as per 
RFC4007. -- Hence the incongruence.

e.g., if "global" means "an administrative domain", then that's not 
global -- unless you're also keen to argue that link-locals can be 
considered "global scope".

Thanks,

---

From: Ted Lemon <[email-masked]>
Date: Mon, 15 Feb 2021 08:37:45 -0500

Fernando, I’m not going to retread this argument again. It’s clear that you and I disagree about what “global” means. You seem to want it to be some kind of guarantee, but it’s not. What’s also clear is that there isn’t any kind of consensus that there’s a problem here of the magnitude that you are suggesting. Your sole basis for saying that there’s a problem is that the definition of “global” in RFC 4007 doesn’t match the use of “global” in RFC 4193. I agree with you that this is the case, but this is not a problem statement that requires standards action. If someone is confused, you already know how to explain it to them.

I’m not going to participate in this discussion any further unless it becomes clear that the working group wants to take some action that will make things worse, in which case I will participate in the sense of opposing such action.

> On Feb 15, 2021, at 12:03 AM, Fernando Gont <[email-masked]> wrote:
> 
> The intention is that, *given a subset of ULAs* the probability of collision is low.
> 
> 
> 
> Please compute the birthday paradox assuming that each CPE in the world locally-generates a ULA prefix, and share the math with us. (that's what global scope means as per RFC4007)
> 
> Spoiler: P~1
> 
> 
> Then we have this notion of "ULAs are 'global scope'", in which "global" meaning something different than what "global scope" means as per RFC4007. -- Hence the incongruence.
> 
> e.g., if "global" means "an administrative domain", then that's not global -- unless you're also keen to argue that link-locals can be considered "global scope".
> 
> Thanks,
> -- 
> Fernando Gont
> SI6 Networks
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Philip Homburg <[email-masked]>
Date: Mon, 15 Feb 2021 16:11:55 +0100

>No. Global scope, per the RFC  you're quoting, is "Global scope, for
>uniquely identifying interfaces anywhere in the Internet."

I think it is time to revisit this definition.

Anycast is widely used on the internet. In some deployments, a single anycast
address is announced from multiple ASes.

A bit earlier in RFC 4007 we have 'scope; that is, a topological span within
which the address may be used as a unique identifier for an interface or
set of interfaces.'

What does that even mean? From a maths point of view, if we have two sites
that use the same ULA, then the ULA address is a unique identifer for a set of
interfaces. How does that help?

In the case of anycast, a GUA may refer to a set of interfaces, but that
set does not need to be stable (as112 for example) 

Effectively the only thing we know about global addresses is that they
are not link local (and not multicast or unspecified)

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Mon, 15 Feb 2021 21:49:57 +0000

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

Perhaps the argument that "scope" doesn’t mean what you are trying to make it mean is a good argument, although it doesn’t do it for me. What does it for me is, what you have stated above, that is not how ULAs are meant to be formed. That is how RFC 1918 addresses are meant to be used. Nothing says that it's okay to reuse the same ULAs, in separate admin domains.

Your mention of birthday paradox depends on how many organizations use ULAs. If not many do, then the likelihood of global uniqueness goes up.

Bert

---

From: Fernando Gont <[email-masked]>
Date: Mon, 15 Feb 2021 18:59:34 -0300

On 15/2/21 18:49, Manfredi (US), Albert E wrote:
> Perhaps the argument that "scope" doesn’t mean what you are trying to make it mean is a good argument, although it doesn’t do it for me. What does it for me is, what you have stated above, that is not how ULAs are meant to be formed. 

Note: I'm using the definition of "scope" and "global scope" as per 
RFC4007. --- I'm certainly *not* using my own definition, or my own 
interpretation of the existing definition.

Thanks,

---

From: Ted Lemon <[email-masked]>
Date: Mon, 15 Feb 2021 17:05:42 -0500

> Your mention of birthday paradox depends on how many organizations use ULAs. If not many do, then the likelihood of global uniqueness goes up.

There are also different uses for ULA. ULA can be used for internal addressing by large orgs, and there there’s potential for overlaps, if for no other reason than that large orgs sometimes merge.

Another use for ULAs is on home networks. In this case, we don’t expect ULAs to ever need to cross the router. So the set of networks on which home network ULAs need to work is very tightly constrained, and we don’t need to worry about ambiguities.

Another use for ULAs is stub networks. In this case, again we do not expect the ULA to ever make it past the adjacent infrastructure link (the link to which the stub network is attached).

So chasing after global uniqueness is not necessary in most cases; even in the case where it is possible that there will be conflicts, /global/ uniqueness is not really the issue. In a case where two orgs are merging, the likelihood of a ULA collision, assuming they used a real RNG to generate the ULA, is small, and if it happens, the worst case scenario is that one or both of the orgs need to renumber before they merge. This is not something that’s going to just randomly cause a problem.

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Mon, 15 Feb 2021 22:26:05 +0000

From: Ted Lemon <[email-masked]> 

> So chasing after global uniqueness is not necessary in most cases; even in the case where it is possible that there will be conflicts, /global/ uniqueness is not really the issue. In a case where t…

Okay, I agree with those points. Still, to my mind, what is most convincing is how *I*, a user of ULAs, have to go about defining these, and how that would differ from RFC 1918 usage.

RFC 4007 says this much:

   Every IPv6 address other than the unspecified address has a specific
   scope; that is, a topological span within which the address may be
   used as a unique identifier for an interface or set of interfaces.

As an individual net designer, for the fd00::/8 block at least, I cannot allow myself to reuse the ULA prefixes, no matter how isolated my separate nets might be. I have to shoot for uniqueness. Instead, no problem at all using duplicated RFC 1918 addresses, among mutually isolated networks. So, as a designer, this puts an extra burden on me, when using ULAs vs RFC 1918.

And furthermore, for the fc00::/8 block, these ULAs might actually be guaranteed to be globally unique, even if they have to remain inside an admin domain.

Chasing after actual global uniqueness is not necessary, for fd00::/8 ULAs, but it's still what individuals who define these have to shoot for. To me, that's what matters, and it's not very confusing.

Bert

---

From: Ted Lemon <[email-masked]>
Date: Mon, 15 Feb 2021 17:31:23 -0500

> Chasing after actual global uniqueness is not necessary, for fd00::/8 ULAs, but it's still what individuals who define these have to shoot for. To me, that's what matters, and it's not very confusi…

Yes. Exactly.

---

From: Bob Hinden <[email-masked]>
Date: Mon, 15 Feb 2021 19:16:55 -0800

Hi Ted,

> On Feb 15, 2021, at 2:05 PM, Ted Lemon <[email-masked]> wrote:
> 

As a datapoint for this, I own two home style routers from different vendors.   Both generate ULA prefixes automatically.   Vendors seem to have figured this out.

Bob

---

From: Mark Smith <[email-masked]>
Date: Tue, 16 Feb 2021 14:35:43 +1100

On Tue, 16 Feb 2021, 14:17 Bob Hinden, <[email-masked]> wrote:

> >> Your mention of birthday paradox depends on how many organizations use
> ULAs. If not many do, then the likelihood of global uniqueness goes up.
> >
> > There are also different uses for ULA. ULA can be used for internal
> addressing by large orgs, and there there’s potential for overlaps, if for
> no other reason than that large orgs sometimes merge.
> >
> > Another use for ULAs is on home networks. In this case, we don’t expect
> ULAs to ever need to cross the router. So the set of networks on which home
> network ULAs need to work is very tightly constrained, and we don’t need to
> worry about ambiguities.
>
> As a datapoint for this, I own two home style routers from different
> vendors.   Both generate ULA prefixes automatically.   Vendors seem to have
> figured this out.
>

+1

My sister's home CPE was announcing a random ULA /64 in RAs a few years
ago, even though her ISP wasn't providing IPv6.

I'm also looking at some IPv6 home CPE. It doesn't enable ULAs by default,
however, if enabled, the default prefix option is randomly generated, with
a static override available.

Regards,
Mark.

> Bob
>
>
> >
> > Another use for ULAs is stub networks. In this case, again we do not
> expect the ULA to ever make it past the adjacent infrastructure link (the
> link to which the stub network is attached).
> >
> > So chasing after global uniqueness is not necessary in most cases; even
> in the case where it is possible that there will be conflicts, /global/
> uniqueness is not really the issue. In a case where two orgs are merging,
> the likelihood of a ULA collision, assuming they used a real RNG to
> generate the ULA, is small, and if it happens, the worst case scenario is
> that one or both of the orgs need to renumber before they merge. This is
> not something that’s going to just randomly cause a problem.
> >

---

From: Fernando Gont <[email-masked]>
Date: Tue, 16 Feb 2021 01:05:05 -0300

> As a datapoint for this, I own two home style routers from different vendors.   Both generate ULA prefixes automatically.   Vendors seem to have figured this out.

FWIW, I don't think this issue has lead to interoperability problems. 
For the most part, the issue has to do with terminology/architecture, 
rather than whether things work in practice.

My hope was/is that terminology can be clarified in a way that folks 
reading the different addressing documents (RFC4291, RFC4193, RFC4007) 
don't find conflicting definitions or terminology.

Some of this clarification might have a side-effect in things like 
programming-language macros and libraries, as e.g. has proven to be the 
case for Python.

Thanks,

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Feb 2021 08:54:30 -0500

On Feb 15, 2021, at 11:05 PM, Fernando Gont <[email-masked]> wrote:
> Some of this clarification might have a side-effect in things like programming-language macros and libraries, as e.g. has proven to be the case for Python.

Python apparently wrongly identifies a ULA as non-global. Reading the ULA specification would have helped with that. Following RFC 6724 would have helped with that. Implementors not reading both RFCs carefully is what resulted in the problem Brian discovered.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 16 Feb 2021 12:09:42 -0300

On 16/2/21 10:54, Ted Lemon wrote:
> On Feb 15, 2021, at 11:05 PM, Fernando Gont <[email-masked] 
>> programming-language macros and libraries, as e.g. has proven to be 
>> the case for Python.
> 
> Python apparently wrongly identifies a ULA as non-global. Reading the 
> ULA specification would have helped with that. 

But reading the "ipv6 scoped addressing architecture" (RFC4007) would 
have suggested that what they did is correct.

That's the problem with conflicting or confusing definitions.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Feb 2021 10:17:48 -0500

On Feb 16, 2021, at 10:09 AM, Fernando Gont <[email-masked]> wrote:
> But reading the "ipv6 scoped addressing architecture" (RFC4007) would have suggested that what they did is correct.

RFC 4007 doesn’t mention ULAs, so they wouldn’t have differentiated them from other addresses on the basis of RFC 4007.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 16 Feb 2021 16:20:14 +0100

>have suggested that what they did is correct.

In my opinion, ULA is sufficiently different from rfc1918 that mapping them
to the same concept in a programming language will only lead to issues
that are hard to resolve.

In today's internet, an RFC 1918 address is likely behind NAT. So you can
use the address as source address to communicate with the wider IPv4 internet.
You may need to use NAT traversal tools. It is very unlikely that there will
be another IPv4 address available.

With ULA, using the ULA as source address is not going to connect you the
wider IPv6 internet. NAT is unlikely. But there is a good chance that there
is another IPv6 address that can reach the rest of the internet.

In other words, though both RFC 1918 and ULA have some sort of 'local' aspect,
they differ in just about every other aspect.

---

From: Gert Doering <[email-masked]>
Date: Tue, 16 Feb 2021 16:27:29 +0100

Hi,

> is another IPv6 address that can reach the rest of the internet.

I would not codify this.

Given the failure of dual-GUA multihoming, I expect to see quite a bit
of ULA + double-NPT6 multihoming in the not-so-far-future.

(And yes, it pains me, and I'm happy to be proven wrong.  But my gut
has lots of experience now with "will people use this perfect solution
which is only 80% implemented yet" vs "will they do something that smells
bad, but works right away"...)

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: Fernando Gont <[email-masked]>
Date: Tue, 16 Feb 2021 12:28:57 -0300

On 16/2/21 12:17, Ted Lemon wrote:
> On Feb 16, 2021, at 10:09 AM, Fernando Gont <[email-masked] 
> RFC 4007 doesn’t mention ULAs, so they wouldn’t have differentiated them 
> from other addresses on the basis of RFC 4007.

It doesn't mention ULAs, because it predates it.

But it is an *architecture* document (that what it claims to be). Hence, 
you'd assume that protocols reflect the architecture.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Feb 2021 10:51:23 -0500

> of ULA + double-NPT6 multihoming in the not-so-far-future.

That’s an absurd way to solve the problem. Of course, it might happen anyway, but I don’t think we should base an architecture on the assumption that this is the right solution.

---

From: Gert Doering <[email-masked]>
Date: Tue, 16 Feb 2021 17:01:25 +0100

Hi,

On Tue, Feb 16, 2021 at 10:51:23AM -0500, Ted Lemon wrote:
> That???s an absurd way to solve the problem. 

I cannot comment this in any way that is not full of negativism about
the achievements of IETF work in the area of SoHo multihoming.  Sorry.

Gert Doering
        -- NetMaster

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Feb 2021 11:06:59 -0500

> the achievements of IETF work in the area of SoHo multihoming.  Sorry.

Actually, RFC 8028 seems to address this problem correctly at least for the single-link model:

   Default Router Selection (Section 6.3.6 of [RFC4861] <https://tools.ietf.org/html/rfc4861#section-6.3.6>) is extended as
   follows: A host SHOULD select default routers for each prefix it is
   assigned an address in.  Routers that have advertised the prefix in
   their Router Advertisement message SHOULD be preferred over routers
   that do not advertise the prefix, regardless of Default Router
   Preference.  Note that this document does not change the way in which
   default router preferences are communicated [RFC4191 <https://tools.ietf.org/html/rfc4191>].

---

From: Philip Homburg <[email-masked]>
Date: Tue, 16 Feb 2021 17:20:30 +0100

>    On Feb 16, 2021, at 11:01 AM, Gert Doering <[1][email-masked]>
>    wrote:
> 
>      I cannot comment this in any way that is not full of negativism
>      about the achievements of IETF work in the area of SoHo
>      multihoming.  Sorry.
> 
>    Default Router Selection ([2]Section 6.3.6 of [RFC4861]) is
>    extended as follows: A host SHOULD select default routers for
>    each prefix it is assigned an address in.  Routers that have
>    advertised the prefix in their Router Advertisement message
>    SHOULD be preferred over routers that do not advertise the
>    prefix, regardless of Default Router Preference.  Note that this
>    document does not change the way in which default router
>    preferences are communicated [[3]RFC4191].

We have a lot of protocol already. I have played extensively with moving
hosts from one upstream to another or what you can do with flash renumbering.

One big problem is that if you add it all up it becomes very complex. 
Certainly for people with an IPv4 background it is hard to figure out how
things should work. So the obvious way forward for them is to insert some
kind of NAT.

>From an application point of view, if you have to support IPv4 and NAT, is
it hard to support NAT for IPv6 as well?

---

From: Gert Doering <[email-masked]>
Date: Tue, 16 Feb 2021 17:20:36 +0100

Hi,

> for the single-link model:

Maybe the message hasn't been reached the OS stack vendors... but as
of last week, we didn't find any OS that does this correctly.

Linux, for example, will just pick one default gateway, usually "the one 
from the RA received last".

Of course we did not test all available IPv6 stacks, so I would be happy
to learn about implementations that get this right.

(And yes, while technically "not an IETF fault", the aspect that this
was only standardized about 20 years after people had their IPv6 stacks 
written *is*)

Gert Doering
        -- NetMaster

---

From: Philip Homburg <[email-masked]>
Date: Tue, 16 Feb 2021 17:34:38 +0100

>from the RA received last".

I think Linux also honours the priority of the default router. Playing
with default router priorities and the preference value of slaac prefixes
allows routers to steer traffic.

Of course that requires routers to coordinate...

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Feb 2021 11:52:28 -0500

> Of course that requires routers to coordinate... 

Yeah, that doesn’t solve the problem, then. :)

But I’m curious, has anybody tried to get Linux to adopt RFC 8028? It seems like a pretty easy sell—the behavior without 8028 is clearly wrong.

---

From: Gert Doering <[email-masked]>
Date: Tue, 16 Feb 2021 18:02:13 +0100

Hi,

On Tue, Feb 16, 2021 at 05:34:38PM +0100, Philip Homburg wrote:
> I think Linux also honours the priority of the default router. 

It does, but that does not help much in the scenario "Router A connects
to ISP A, announces prefix from A, Router B connects to ISP B, and
announces prefix from B, and packets sourced from A or B needs to go
to the respective router".

> Playing

... and solves a different scenario ("primary ISP, backup ISP")...

The true greatness of dual-prefix multihoming, in my opinion, is 
"hosts get to decide which ISP to use", so a given host can decide
"I want to use ISP A for my web traffic, and ISP B for my voice traffic"
(by picking the corresponding source address).

Of course this is not there yet, because there is no guidance *how* to 
pick a proper source address in that scenario (and that leads to the
other problem of no guidance how to deal with "I picked GUA source A,
and can't reach my destination, so should I try GUA source B next?").

... and if we can't have the nice things, just using GUA + NPT66 on
the router will achieve the basic "I want to have two ISPs with failover
for my web traffic" just fine.

Gert Doering
        -- NetMaster

---

From: Bob Hinden <[email-masked]>
Date: Tue, 16 Feb 2021 09:14:08 -0800

Fernando,

> On Feb 15, 2021, at 8:05 PM, Fernando Gont <[email-masked]> wrote:
> 
> FWIW, I don't think this issue has lead to interoperability problems. For the most part, the issue has to do with terminology/architecture, rather than whether things work in practice.

I am having a hard time seeing value updating a lot of specifications (even assuming we could agree about what to change) if there is not an interoperability problem.   What we have now appears to be adequate in-order to implement and use ULAs.

The whole reason for standards is to create interoperability.

Bob

> 
> My hope was/is that terminology can be clarified in a way that folks reading the different addressing documents (RFC4291, RFC4193, RFC4007) don't find conflicting definitions or terminology.
>

---

From: David Farmer <[email-masked]>
Date: Tue, 16 Feb 2021 11:23:09 -0600

> you'd assume that protocols reflect the architecture.

And since RFC4193 neither updates RFC4007 or RFC 3513 (nor was it
referenced in RFC4291) there are no breadcrumbs to follow either. This is
the biggest issue I have and if anything comes out of this discussion, can
we please get reasonable breadcrumbs in place. There is several possible
ways to solve this.

Thanks

---

From: Fernando Gont <[email-masked]>
Date: Tue, 16 Feb 2021 14:45:29 -0300

Hi, Bob,

On 16/2/21 14:14, Bob Hinden wrote:
[...]
>> 
>> FWIW, I don't think this issue has lead to interoperability
>> problems. For the most part, the issue has to do with
>> terminology/architecture, rather than whether things work in
>> practice.
> 
> I am having a hard time seeing value updating a lot of specifications
> (even assuming we could agree about what to change) if there is not
> an interoperability problem. 

There's a mismatch between a protocol spec (RFC4291/RFC4193 saying that 
ULAs are global) and RFC4007 defining scope and global scope.

RFC4007 is an architecture document -- so you want get interoperability 
issues there, since an architecture is mostly abstract.

That said, there are pieces of code (the referenced Python library) that 
do make use of such specifications an architecture.

If one wanted to direct Python's folk to change their library, one would 
need to provide some basis for that. BUt at the time of this writing, 
such basis is contradictory: because RFC4193/RFC4291 says ULAs are 
global, while de "global scope" definition of RFC4007 says it's not.

I ran into this issue when I wanted to offer this explanation myself -- 
but ended up finding conflicting specs.

If the "IPv6 scoped addressing architecture" (RFC4007) is important 
enough to have it -- and assuming we're going to have IPv6 for a long 
time (which I think we all do), it's certainly good to have specs and 
architecture aligned. Otherwise, if the architecture document is not 
important, one might as well fix the issue by simply obsoleting it.

Thanks,

---

From: Philip Homburg <[email-masked]>
Date: Tue, 16 Feb 2021 19:28:27 +0100

>(by picking the corresponding source address).

We see that hosts don't even implement the basics, so this seems
to be a bit of a pipe seeam,

>and can't reach my destination, so should I try GUA source B next?").

If you know how to express the diffence in the two upstreams, put it in
Ole's generic RA option, hosts can take it out and use it in
source address selection and you are done. Just a simple matter of
programming.

A generalized Happy eyeballs works fine for unreachable destinations.

>=2E.. and if we can't have the nice things, just using GUA + NPT66 on

For faulover, you don't need NAT.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Feb 2021 13:32:31 -0500

On Feb 16, 2021, at 1:28 PM, Philip Homburg <[email-masked]> wrote:
> to be a bit of a pipe dream,

Indeed, I have no idea how a host would know.

It might be nice to be able to somehow configure the network to treat one link as preferred over another, e.g. if one connection is expensive. Of course, since the user isn’t likely to know to configure that, it needs to be automatic, and I don’t think an automatic mechanism has been specified.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 16 Feb 2021 17:57:26 -0300

> bad, but works right away"...)

You are being overly optimistic. At least multi-prefix/multi-router IPv6 
networking is rather.... *broken*.

Unless I've missed any recent widespread implementation and deployment 
of RFC8028...

Thanks,

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Tue, 16 Feb 2021 22:14:40 +0000

From: ipv6 <[email-masked]> On Behalf Of Ted Lemon

> It might be nice to be able to somehow configure the network to treat one link as preferred over another, e.g. if one connection is expensive. Of course, since the user isn’t likely to know to conf…

This was a quite deliberate aspect of ATM, at least, the intention was. PNNI to set up a route that took into account the QoS needs for that session.

https://www.ece.nus.edu.sg/stfpage/eletck/papers/TSL_ICON2000.pdf

One of the reasons that the simplicity of IP won out, eh?

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Feb 2021 11:40:31 +1300

On 17-Feb-21 05:52, Ted Lemon wrote:
> On Feb 16, 2021, at 11:34 AM, Philip Homburg <[email-masked] <mailto:[email-masked]>> wrote:

The IETF is not good at this sort of thing (working with the
developer community). But see RFC 8504 (node requirements):

"Hosts that may be deployed in such multihomed environments SHOULD
 follow the guidance given in [RFC8028]."

so this ought to show up on the conformance radar.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 16 Feb 2021 20:11:07 -0300

[...]
> so this ought to show up on the conformance radar.

I must say that, in retrospective, this should have been a MUST. THings 
do break without RFC8028.

Thanks,

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Feb 2021 18:33:42 -0500

On Feb 16, 2021, at 5:40 PM, Brian E Carpenter <[email-masked]> wrote:
> follow the guidance given in [RFC8028].”

That’s maybe not so helpful since the reader might think “may be deployed in multihomed environments” is exceptional and unusual, rather than the default expectation. It might be better to say "hosts SHOULD unless <I’m not sure what>."

---

From: Yucel Guven <[email-masked]>
Date: Wed, 17 Feb 2021 17:57:52 +0300

+1.
Exactly, that was the "war" between ATM and IP . The arguments were
'simplicity' and 'data overhead'. And IP won.
However, most of the modern networks today have these properties. One
link/card/hware/etc. is always standby for the other active one.
Always? Yeah ok, we may say 'proportional' to the budget.

Yucel

---

From: Ted Lemon <[email-masked]>
Date: Wed, 17 Feb 2021 11:14:45 -0500

>> This was a quite deliberate aspect of ATM, at least, the intention was. PNNI to set up a route that took into account the QoS needs for that session.

This wasn’t really what I meant. QoS is kind of notorious for not being deployed anywhere except inside of walled gardens because it’s too hard to operate in a way that doesn’t get gamed. It’s certainly not something that could be done automatically.

When I think about how to deploy this on a home network, that’s exactly the calculus that comes up: suppose I advertise a backup router that’s for critical traffic. How do I ensure that only critical traffic is sent over it? Well, first I need to know what “critical traffic” is. Who’s going to tell me? The user? Not likely. The service provider? Yes, definitely. Their traffic is definitely critical. And at this point in the calculus I realize that this is one of those strange games where the only winning move is not to play…