Subject: Re: [v6ops] I-D Action: draft-gont-v6ops-ipv6-addressing-considerations-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Sun, 20 Dec 2020 17:44:27 +1300

Hi,

Thanks for this draft.

> 3.1.  Legacy Specifications and Schemes

I don't think that section is complete without mentioning site-local and why it was scrapped (RFC3879).

> 3.2.  Unique Local IPv6 Unicast Addresses (ULAs)
...
>    However, the only reasons
>    for which these addresses are considered to have "global scope" are:
> 
>    o  given two different networks that employ ULAs, it's unlikely that
>       they will employ the same ULA prefix

Not at all. The reason they formally have global scope is because when site-local was scrapped (as being meaningless and unenforcable, see RFC3879), only two scopes were left: link-local and global. There was no other choice. What that means is that protocols treat them *exactly the same* as RIR-assigned prefixes. That applies to all protocols: ND, RA, DHCPv6, and every routing protocol. They are only treated differently by policy, such as address selection policy or boundary router policy. And, if you like, the pseudo-random prefix assignment mechanism is also a policy, by making prefix collision highly unlikely. ULA-C would be a different policy, by making prefix registration compulsory.

> 
>    o  the ULA address block formally belongs to the Global Unicast
>       Address (GUA) address block
...
>    The ULA address block has been carved out of the GUA address block,

This statement seems misleading to me. GUA is not actually defined very well in RFC4291. True, the table in section 2.4 says "Global Unicast (everything else)" and none of the formal updates to RFC4291 change that. But the choice of fc00::/7 by RFC4193 makes it clear that these are not normal GUAs; by definition they are not assigned by the RIRs or announced on the public Internet. They are listed in the IANA Special-Purpose IP Address registry and discussed explicitly in RFC8190, so the claim that they are part of the GUA block seems very dubious.

(I think it's a bug in RFC4193 that it didn't make an update to RFC3513, the predecessor of RFC4291, which actually foresaw such a case:
"Future specifications may redefine one or more sub-ranges of the
 global unicast space for other purposes, but unless and until that
 happens, implementations must treat all addresses that do not start
 with any of the above-listed prefixes as global unicast addresses.")

>    Therefore, ULAs are not globally meaningful and thus, for most (if
>    not all) practical purposes, ULAs can be considered to have non-
>    global scope.  For this reason, ULAs are treated as non-global scope
>    addresses, even when from a specifications point of view they have
>    global scope.

I don't accept that. I believe we've had that discussion and the consensus
is in RFC8190 and the IANA registry already.

Later in the draft you say:

>    In the same light, a ULA prefix
>    generated by a local router will be, by definition, provider
>    independent.  However, a router might also be leased an ULA sub-
>    prefix from its upstream, in which case this prefix would be
>    "provider dependent".

Exactly. This illustrates that as far as protocols go, ULA prefixes behave exactly like RIR-assigned prefixes. They are global in protocol terms, but not globally routed in operational terms. These are orthogonal properties.

Regards
   Brian

On 12-Dec-20 05:00, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>         Title           : IPv6 Addressing Considerations
>         Authors         : Fernando Gont
>                           Guillermo Gont
> 	Filename        : draft-gont-v6ops-ipv6-addressing-considerations-00.txt
> 	Pages           : 27
> 	Date            : 2020-12-11
> 
> Abstract:
>    IPv6 addresses can differ in a number of properties, such as scope,
>    stability, and intended usage type.  This document analyzes the
>    impact of these properties on aspects such as security, privacy,
>    interoperability, and network operations.  Additionally, it
>    identifies challenges and gaps that currently prevent systems and
>    applications from leveraging the increased flexibility and
>    availability of IPv6 addresses.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-addressing-considerations/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-gont-v6ops-ipv6-addressing-considerations-00
> https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-addressing-considerations-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 24 Dec 2020 02:50:58 -0300

Hello, Brian,

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

On 20/12/20 01:44, Brian E Carpenter wrote:
[....]
> and why it was scrapped (RFC3879).

Will do.

Comment/question (since I wasn't participating in 6man when RFC3879 was 
published, and I've never used site-locals myself):

There seem to be two main issues with site-locals:

1) use of the zone index ("%___")

2) "ambiguitiy" of the addresses.

Regarding #1:
My understanding is that site-locals where expected to be used with a 
zone index (as we normally do for e.g. link-locals) in the case the same 
prefix is employed on two different networks.

Now, my question is: why do this in the first place? What I would expect 
is that you simply use the address. Then, if the same node attaches to 
two networks that employ the same prefix, that's a configuration 
problem. Period. *If* in such scenario, *and for debugging purposes* you 
want to be able to specify which interface to use to send packets to a 
site-local address (that looks like "on-link" on two different 
interfaces), then you use the zone index -- but that's for *debugging* 
purposes, since having two subnets employ the same site-local prefix 
would be an error.

Regarding #2:
Modulo the above, for the most part non-global addresses *are* 
ambiguous. So this is kind of a feature.

With the minor consideration in #1, site-locals do not seem to be a lot 
different than ULAs. -- Yes, you are supposed to randomize the ULA 
prefix ( which I don't when using them in labs, since I don't want 
ugly-looking addresses :-) ).. but you might also argue than when using 
site-locals you better made sure that you didn't  employ the same 
site-local prefix in to interconnected networks, anyway.

Am I missing something?

>> However, the only reasons for which these addresses are considered 
>> to have "global scope" are:
>> 
>> o  given two different networks that employ ULAs, it's unlikely 
>> that they will employ the same ULA prefix
> 
> Not at all. The reason they formally have global scope is because 
> when site-local was scrapped (as being meaningless and unenforcable, 
> see RFC3879), only two scopes were left: link-local and global.
> There was no other choice.

Why not, say, "IPv6 Private Address Space"? -- Yes, in the light of 
"ipv6 is all about the global addresses", mimicking IPv4's private 
addresses probably wasn't "sexy", but IMO the concept is useful, and 
well understood.

> What that means is that protocols treat
> them *exactly the same* as RIR-assigned prefixes. That applies to
> all protocols: ND, RA, DHCPv6, and every routing protocol. They are
> only treated differently by policy, such as address selection policy
> or boundary router policy. 

Wouldn't this also be the case if they were redefined as "IPv6 private 
address space"?  i.e., from the point of routing, modulo the link-local 
prefixes, you simply have prefixes that you distribute information 
about.  i.e. "Private address space" (i.e., non-global) shouldn't be 
treated differently by routing protocols.

> And, if you like, the pseudo-random
> prefix assignment mechanism is also a policy, by making prefix
> collision highly unlikely. ULA-C would be a different policy, by
> making prefix registration compulsory.

Comment/question (rather than "objection"): since the "scope" is
essentially defined as the region of the network topology where an
address is meaningful, it would seem to me that claiming "ULAs" are
global-scope is at odds with the fact that ULAs prefixes are
locally-generated.

Put another way: when you analyze what "scope" means, ULAs really have 
nothing of "global scope". ULAs are not centrally managed, and as such 
are ambiguous.

(I guess you could argue that ULA-C could be global for some meaning of 
the concept. But then I don't see much of a point for such a thing. -- 
just use global addresses, and filter where appropriate.)

> This statement seems misleading to me. GUA is not actually defined 
> very well in RFC4291. True, the table in section 2.4 says "Global 
> Unicast (everything else)" and none of the formal updates to RFC4291 
> change that.

Yes, that was my rationale.

> But the choice of fc00::/7 by RFC4193 makes it clear 
> that these are not normal GUAs; by definition they are not assigned 
> by the RIRs or announced on the public Internet. They are listed in 
> the IANA Special-Purpose IP Address registry and discussed
> explicitly in RFC8190, so the claim that they are part of the GUA
> block seems very dubious.

FWIW, I think that RFC4193 should have formally updated RFC4291 (or, 
well, since probably they were published together, RFC4291 could have 
marked the ULA space in the addressing architecture, and point to 
RFC4193 for further details).

BTW, there are no macros that would distinguish ULAs them from regular 
global addresses: https://tools.ietf.org/html/rfc2553#section-6.7

> (I think it's a bug in RFC4193 that it didn't make an update to 
> RFC3513, the predecessor of RFC4291, which actually foresaw such a 
> case: "Future specifications may redefine one or more sub-ranges of 
> the global unicast space for other purposes, but unless and until 
> that happens, implementations must treat all addresses that do not 
> start with any of the above-listed prefixes as global unicast 
> addresses.")

Ok, it looks like we are on the same page. :-)

>> global scope.  For this reason, ULAs are treated as non-global 
>> scope addresses, even when from a specifications point of view
>> they have global scope.
> 
> I don't accept that. I believe we've had that discussion and the 
> consensus is in RFC8190 and the IANA registry already.

Sorry: what we *meant* here is that, throughout our document, when we 
refer to "non-global addresses" we are also thinking about ULAs.

(e.g., the "possible isolation provided by the address scope" applies 
(to different degrees) to both e.g. link-locals and ULAs...)

>> In the same light, a ULA prefix generated by a local router will 
>> be, by definition, provider independent.  However, a router might 
>> also be leased an ULA sub- prefix from its upstream, in which case 
>> this prefix would be "provider dependent".
> 
> Exactly. This illustrates that as far as protocols go, ULA prefixes 
> behave exactly like RIR-assigned prefixes.

Couldn't one also argue that ULAs are, e.g., "IPv6 private address 
space" and that, as with the RFC1918 space,  no special provisions are 
needed in routing protocols -- other than one filtering prefixes 
when/where deemed appropriate?

> They are global in 
> protocol terms, but not globally routed in operational terms. These 
> are orthogonal properties.

Sorry for insisting on this one -- I'm bringing up this issues because I 
found myself trying to provide an explanation for "global in protocol 
terms", without a lot of success. :-)

It would seem to me that virtually every use of "global" for ULAs 
(modulo ULA-C, I guess) is, conceptually speaking, kind of cumbersome 
and incorrect. -- and creates expectations that, at the end of the day, 
are probably not going to be fulfilled.

Wouldn't the most natural thing be to flag ULAs as "IPv6 Private Address 
Space", where e.g. from the point of view of protocols, the same 
considerations as for RFC1918 apply (no, I wouldn't *say* this in a 
spec), and we simply have the additional feature in the spec that we 
recommend how to generate the ULAs prefixes to avoid possible hassles 
when merging two different networks?

Or, to put in a different way: RFC1918 is private address space, and we 
don't need to call it "global" in any way to flag the fact that 
addresses from that private address space are not treated in any special 
way by e.g. routing protocols     -- for instance, why should they?

Thanks!

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Dec 2020 11:15:35 +1300

Hi Fernando,

> purposes, since having two subnets employ the same site-local prefix 

If you read RFC4007 you will *not* find that a zone index is formally
equated to an interface index. The "zone" terminology is confusing since
it did originally assume a nested scope model, link-local inside site-local
inside global. By some magic the host was supposed to understand enough
of the network topology to use a single value "zone index" to capture
the topology and tell the drivers which interface to use. See diagrams
at https://sites.google.com/site/bcabrc/miscellany . 
Slides 3 and 4 show scenarios that simply can't be captured
by a one-dimensional zone index. In practice, of course, the zone index
is only meaningful within the host. So the whole concept of a zone
index for nested scopes was a mistake. With hindsight, we should
have cleaned that up more definitively in RFC4007.

(And this problem is still a problem:
https://bugzilla.mozilla.org/show_bug.cgi?id=700999 was opened
9 years ago and still gets traffic despite being formally "closed"
5 years ago.)

> ambiguous. So this is kind of a feature.

Yes, but not a *good* feature since it leads to the problems
in my slides 3 and 4.
 
> site-local prefix in to interconnected networks, anyway.

But the design didn't provide for that, whereas the ULA design does
(and no, using pretty ULA prefixes is not OK).

RFC3513 was seriously broken, because it suggests using "the same
subnet IDs for site-local and global prefixes", which doesn't
make much sense and certainly doesn't provide a high probability
of uniqueness.

> addresses probably wasn't "sexy", but IMO the concept is useful, and 

I think that adds confusion. They are only private because of the
requirement to block them in border routers; it's not a property
of the address itself. (Thumbs down to the Python ipaddress module
by the way, which has invented an "is_private" property and gets
"is_global" wrong for ULAs.)

> treated differently by routing protocols.

It's true, but that's what the "global" property means, and it's different
from "globally reachable". It's not ideal terminology, of course, since the
design process had a false start with "site-local".

Happy holidays!

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Dec 2020 14:04:05 +1300

There's now a better version of my diagrams at https://www.cs.auckland.ac.nz/~brian/scope6.pdf

Regards
   Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 29 Dec 2020 12:00:27 -0300

Hi, Brian,

Thanks for following up! In-line.....

On 24/12/20 19:15, Brian E Carpenter wrote:
[....]
> If you read RFC4007 

I had read RFC4007 in the past -- *years* ago. So I've just given it a 
fresh read.

Some initial questions:

* Any reason why this document is a separate/stand-alone document rather 
than part of RFC4291 (or RFC3513)?  Or, at the very least, any reasons 
why it does not even *update* one of those? (RFC3513, since RFC4007 
obviously predates RFC4291)  (particularly since it's Std Track)

* Section 5 states:
    Each interface belongs to exactly one zone of each possible scope.
    Note that this means that an interface belongs to a scope zone
    regardless of what kind of unicast address the interface has or of
    which multicast groups the node joins on the interface.

This would seem to imply that an interface cannot employ two different 
ULA prefixes? -- Why?  (unless their scope is considered global, and all 
ULAs plus GUAs are all considered to be part of the same global scope zone)

> you will *not* find that a zone index is formally
> inside global. 

(me thinking out loud) It seems that it *cannot* be equated, since an 
interface may (and usually will) belong to multiple zones.

So the zone index somehow ends up being the combination of "address" + 
"interface index", where the implementation infers the scope from the 
"address"?    (this isn't really a "zone index", though).

> By some magic the host was supposed to understand enough
> is only meaningful within the host. 

Isn't this the case *by definition*?

> So the whole concept of a zone

You mean that it's problematic for the node to *automatically* determine 
which zone an address belongs to?

If so, yes -- that seems unfeasible. The best you can hope is the 
"default zone index" (which can indeed fail), or manual specification of 
the "zone index".

> Yes, but not a *good* feature since it leads to the problems

But... are site-locals special in this respect?  -- As with link-locals 
on multi-interface nodes, you either manually pick the outgoing 
interface (and hence the zone), or your rely on the default zone index 
(and cross your fingers :-) ).

[....]
> of the address itself. 

In a way, isn't that the case for all non-global addresses?  e.g. for 
link-locals as Destination Addresses it's kind of hardcoded. But for 
link-locals employed as Src Address, you also need the requirement for 
routers to drop the packets to prevent these addresses from leaking out 
of their zone. (But yes, for link-locals this check can also be hardocded).

> (Thumbs down to the Python ipaddress module

Assuming ULAs are flagged as "global", I guess that's a consequence of 
RFC4291 (or it's antecessor) not being updated by the ULA spec?

> from "globally reachable". 

You mean "global" as in "global scope"?

Section 4 of RFC4007 says:
    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 you noted in a previous email, this is probably unlikely for 40-bit 
global IDs (but should compute the birthday problem for this case) -- 
this might improve with RFC7217 (assuming randomized secret_keys for the 
algorithm)... but you could still have manually configured IIDs. So in 
that sense, I wouldn't consider ULAs as "global scope", either.

(must admit had to go through RFC8190 and friends a few times...)

Thanks, and Happy Holidays!

Regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 31 Dec 2020 14:00:33 +1300

Hi,

Fernando and I have been chatting off-list, so rather than responding in
detail below, here are just a few general observations:

1. We have a problem with the formal definition of "global". All it really
means in the IPv6 addressing architecture is "not link-local", which is
not "global" in the normal English sense. It really seems too late to
change that, but it's unfortunate.

2. The "globally reachable" term added by RFC 8190 isn't perfect either.
All it really means is "potentially globally reachable" because prefixes
don't *have* to be advertised in BGP4.

3. If we're picky, "local" in ULA isn't perfect either, since there's
nothing in the laws of physics to prevent a ULA prefix being advertised
in BGP4.

4. The following table attempts to show some of the distinctions
involved (simplified). View in a fixed-width font. You may not
agree with it...

Unicast       Prefix      IID        Routeable   Announced
address       assigned    assigned
types         by          by
-----------------------------------------------------------
Link-local    fixed       host       no          no
              by RFC
  
ULA           user/RA     host or    yes         IGP only
              (random)    DHCPv6

GUA           IANA/RIR/   host or    yes         IGP,
              ISP/user/RA DHCPv6                 BGP4 by policy

Regards
   Brian

---

From: Gert Doering <[email-masked]>
Date: Thu, 31 Dec 2020 11:30:10 +0100

Hi,

> address       assigned    assigned

Indeed, I am not agreeing - as there is nothing that prevents ULAs from 
being transported by BGP.

We use ULAs for "services that must never reachable from the Internet",
and our routing being what it is, everything is transported by BGP - only
loopbacks in OSPF.  The difference is "do we announce it to other ASes?"

So maybe this should be "generally expected to be visible by other
networks on the Internet" (ULA: no, GUA: yes).

But that's neither precise nor does "expected" mandate anything - I might
want to announce our ULA prefix to our sister company, using eBGP, and
I might decide to not announce our GUA IPv6 PI /48 that we use for our
backbone infra "because people are not supposed to send packets there"...

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: Brian E Carpenter <[email-masked]>
Date: Fri, 1 Jan 2021 08:47:31 +1300

Gert,

> being transported by BGP.

Indeed, nothing in the laws of physics, but it's default-forbidden by
an RFC ;-). Exactly how to express that in a short table is tricky.

I think we all agree about this; what Fernando's draft shows is that it
is quite hard to describe, and the word "global" is confusing.
(Really for the same reason that URLs were renamed from "universal"
to "uniform" in 1994. But renaming "global" at this stage seems almost
impossible.)

   Brian