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

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, internet-drafts@ietf.org 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
> I-D-Announce@ietf.org
> 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
> 