Prioritizing known-local IPv6 ULAs through address selection policy
draft-ietf-6man-rfc6724-update-25

Thanks to Ned Smith for their secdir review.  And to the ADs who balloted on v20.

I was a little unsure what was intended by the word "operator", but I see other comments that would address this.

Please expand/define GUA and ULA when first mentioned in section 1 (suing the definition supplied in section 2.

If I understand, the text of section 3 introduces the motivation, but does not make a normative change. I would have much preferred this text to become a part of section 1, to separate the motivation/background from the update to  the specification. I think this also could be true of the text in section 4? If so, the same comment applies to section 4.

I had one transport-related query for which I'd like to know the answer, and which may be useful to state in the document: I tried to figure-out what actually is required to happen to a TCP stack when you note "transport layer timeouts (e.g., TCP) can be avoided.", is this the hard error processing defined in RFC 5461, or something else? A reference for the example would be helpful.

Many thanks for preparing this document,

Gorry Fairhurst,
WIT AD

# Gunter Van de Velde, RTG AD, comments for draft-ietf-6man-rfc6724-update-20

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-6man-rfc6724-update-20.txt

# Many thanks for an easy to read well written document and a good summary shepherd writeup

# i only have few non-blocking questions and observations on this draft

# Detailed Review
# ===============

13	Abstract
14
15	   This document draws on several years of operational experience to
16	   update the recommended process of Default Address Selection for
17	   Internet Protocol Version 6 (IPv6) defined in RFC6724, defining the
18	   concept of "known-local" Unique Local Address (ULA) prefixes that
19	   enable ULA-to-ULA communications within fd00::/8 to become preferred
20	   over both IPv4-IPv4 and GUA-to-GUA (Global Unicast Addresses) for
21	   local use.  The document defines the means by which nodes can both
22	   identify and insert such prefixes into their address selection policy
23	   table.  It also clarifies the mandatory, unconditional requirement
24	   for support for Rule 5.5 defined in Section 5 of RFC6724 and demotes
25	   the preference for 6to4 addresses.  These changes to default behavior
26	   improve supportability of common use cases, including automatic /
27	   unmanaged scenarios, and makes preference for IPv6 over IPv4
28	   consistent in local site networks for both ULA and GUA prefixes.  It
29	   is recognized that some less common deployment scenarios may require
30	   explicit configuration or custom changes to achieve desired
31	   operational parameters.


GV> Maybe add a pointer that "fd00::/8" is a range specified by IANA for ULA (RFC4193) usage

GV> my perception is the abstract is not written in the most elegant style. What about:

"
This document updates the default address selection algorithm for Internet Protocol Version 6 (IPv6), originally specified in RFC 6724, based on accumulated operational experience. It introduces the concept of "known-local" Unique Local Address (ULA) prefixes within the fd00::/8 block and specifies that ULA-to-ULA communications using such prefixes should be preferred over both IPv4-to-IPv4 and GUA-to-GUA (Global Unicast Address) communications in local use scenarios. The document defines mechanisms for nodes to identify and incorporate known-local prefixes into their address selection policy tables. It further clarifies the unconditional requirement for implementing Rule 5.5 of RFC 6724 and reduces the default preference for 6to4 addresses. These updates enhance the supportability of typical deployment environments, including automatic and unmanaged configurations, and promote consistent IPv6-over-IPv4 preference behavior for both ULA and GUA within local networks. The document acknowledges that certain atypical deployment models may require explicit configuration to achieve intended operational outcomes.
"

175	   Known-local ULA: A ULA prefix that an individual organization/site
176	   has determined to be local to a given node/network

GV> At the risk of stepping into eternal concept discussions, is this not about single administrative domains instead of networks? WHat does network exactly mean in the intended context?


186	   With multi-addressing being the norm for IPv6, more so where nodes

GV> i think a reader can assume what is seen as multi-addressing, it can be useful to explicit formally define what it means in the contect of this document. (i.e. multiop addresses of multiple address families (afi's) of the same safi (unicast)).

238	   The first change is an update to the default policy table to elevate
239	   the preference for ULAs prefixes such that ULAs, like GUAs, carry a
240	   higher precedence than all IPv4 addresses, making IPv6 precedence
241	   over IPv4 consistent for both ULAs and GUAs.
242
243	   The second change is the introduction of the concept of known-local
244	   ULAs.  RFC6724 includes a method by which nodes MAY provide more
245	   fine-grained support for further elevating the preference for
246	   specific ULA prefixes, while leaving other general ULA prefixes at
247	   the precedence described in the previous paragraph.  This document
248	   elevates the requirement for specific ULA prefixes to be inserted
249	   into the policy table to be a MUST, but only for observed prefixes
250	   that are known to be local, i.e., known-local ULAs.  Nodes
251	   implementing this behavior will see ULA prefixes known to be local to
252	   the node's site having precedence over IPv4 addresses and also over
253	   IPv6 GUA addresses, such that they can use ULA addresses
254	   independently of global prefixes within their site and continue to
255	   use GUA-GUA address pairs to talk to destinations external to their
256	   site.

GV> sometimes 'precedence' is used and sometimes 'preference'. Is this intentional?
I see that the text mostly uses 'preference' in the onward sections

273	   the policy table to the same precedence as carried by the Teredo

GV> is there a reference for Teredo?

303	                                     $known_local/48       45    14 (**)

GV> should it be called out that '14' is now assigned as Label for known_local ULAs?
At first glance it looks as a new assigned allocation

333	   This document removes that exception and elevates the requirement to
334	   prefer addresses in a prefix advertised by a next-hop router to a
335	   MUST for all nodes.

GV> What is exactly assumed with the term 'next-hop' router? based upon the technology used, this could be a node that is directly connected via a link (for example a fiber) or it could be a router multiple router hops away terminating a tunnel, or a BGP next-hop. 

352	   it can provide differential treatment for those over general ULAs,

GV> Maybe add for explicit clarity in the list of definitions that 'general ULAs' are ULAs that are not known-local ULAs. 

434	   limit will depend on other Options that are used.  So while this is

GV> Is there a reason why Options is written with uppercase 'O'? 

665	9.  Following ULA operational guidelines in RFC4193

GV> I am not sure how this section aids with the known-local addresses? it re-states procedure which was already described. Can this section be cut away and reduce the size of the document?

Many thanks for this document,

Gunter Van de Velde,
Routing AD

Most of my comments have already been brought up by other reviewers. Therefore, I have chosen to just add color to those comments rather than duplicate them.

Section 1, paragraph 0
>    Since its publication in 2012, Default Address Selection for Internet
>    Protocol Version 6 (IPv6) [RFC6724] has become an important mechanism
>    by which nodes can perform address selection, deriving the most
>    appropriate source and destination address pair to use from a
>    candidate set by following the procedures defined in the RFC.  Part
>    of the process involves the use of a policy table, where the
>    precedence and labels for address prefixes are listed, and for which
>    a default policy table is defined.

Adding to Gunter's point of "precedence" vs "preference", I went to look for the difference between the two, and here is what I found:

"Precedence is generally considered more formal than preference, as it is often used in professional or legal contexts where rules and regulations are involved. Preference is more informal and can be used in both formal and informal contexts."

It would be worthwhile taking a pass through the document where "preference" is used to see if the use of "precedence" would be better than the use of "preference".

Section 3, paragraph 6
>    With multi-addressing being the norm for IPv6, more so where nodes
>    are dual-stack, the ability for a node to pick an appropriate address
>    pair for communication is very important.
> 
>    Where getaddrinfo() as referenced in [RFC3493], or a comparable API
>    is used, the sorting behavior should take into account both the
>    source addresses of the requesting node as well as the destination
>    addresses returned, and sort the candidate address pairs following
>    the procedures defined in RFC6724.
> 
>    The current default policy table leads to preference for use of IPv6
>    GUAs over IPv4 globals, which is widely considered preferential
>    behavior to support greater use of IPv6 in dual-stack environments.
>    This helps in allowing sites to phase out IPv4 as its evidenced use
>    becomes ever lower.
> 
>    However, there are two issues with preference, or rather non-
>    preference, for ULAs as originally defined in RFC6724.
> 
>    One is that the same default policy table also puts IPv6 ULAs below
>    all IPv4 addresses, including [RFC1918] addresses, such that
>    IPv4-IPv4 address pairs are favored over ULA-ULA address pairs.  For
>    many site operators this behavior will be counter-intuitive, given
>    the IPv6 GUA preference, and may create difficulties with respect to
>    planning, operational, and security implications for environments
>    where ULA addresses are used in IPv4/IPv6 dual-stack network
>    scenarios.  The expected default prioritization of known-local IPv6
>    traffic over IPv4 by default, as happens with IPv6 GUA addresses,
>    does not happen for ULAs.
> 
>    As a result, the use of ULAs is not a viable option for dual-stack
>    networking transition planning, large scale network modeling, network
>    lab environments or other modes of large scale networking that run
>    both IPv4 and IPv6 concurrently with the expectation that IPv6 will
>    be preferred by default.  Local preference of ULAs over IPv4 is thus
>    important to assist operators in phasing out IPv4 from dual-stack
>    environments and is an important enabler for sites seeking to move
>    from dual-stack to IPv6-only networking.
> 
>    The other issue is that where nodes in a dual-stack site are
>    addressed from both ULA and GUA prefixes, RFC6724 will see GUA-GUA
>    address pairs chosen over ULA-ULA.  One goal of ULA addresses was to
>    allow local communications to be independent of the availability of
>    external connectivity and addresses, such that persistent ULAs can be
>    used even when the global prefix made available to a site is
>    withdrawn or changes.

I tend to agree with Gorry that this section is mixing motivation with normative changes that this document is proposing. The change in mind would be to move the motivation part captured here, into Introduction or a section of its own, leaving the rest of this section to describe the normative changes that follow or maybe even move them into Section 5.

The IANA review of this document seems to not have concluded yet.

No reference entries found for these items, which were mentioned in the text:
[RFC7078].

Possible DOWNREF from this Standards Track doc to [ANDROID]. If so, the IESG
needs to approve it.

Possible DOWNREF from this Standards Track doc to [RAIO-ULA-PY]. If so, the
IESG needs to approve it.

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Reference [RFC6555] to RFC6555, which was obsoleted by RFC8305 (this may be on
purpose).

Reference [RFC3484] to RFC3484, which was obsoleted by RFC6724 (this may be on
purpose).

Section 5.1, paragraph 4
> Pv4, with ::ffff:0:0/96 now set to precedence 20. 5.2. Rule 5.5 The heuristic
>                                    ^^^^^^^^^^
Did you mean "precedent"?

Section 5.3, paragraph 17
> implify management, filtering rules, etc, and to overcome the issue with the 
>                                      ^^^
In American English, abbreviations like "etc." require a period.

Section 10, paragraph 3
> DROID]. It was last updated in April of 2024, and does not include the capab
>                                ^^^^^^^^^^^^^
When specifying a month and year, "of" is unnecessary.

Section 11, paragraph 2
> as needed. It was last updated in May of 2024. 14. Security Considerations Th
>                                   ^^^^^^^^^^^
When specifying a month and year, "of" is unnecessary.

Well-written document, thank you. I have a few small comments that should be easy to address:

Throughout, please use proper references and cross-references rather than just the number of the RFC.

At the end of 5.3, "where you might be using someone else's compliant prefix" can simply be deleted; the sentence says the same thing without the unnecessary second-person language.

In Section 9.2, your quote and the section reference are both incorrect. The sentence in question is in Section 4.4 of RFC4193, and reads "AAAA and PTR records for locally assigned local IPv6 addresses are not recommended to be installed in the global DNS." Also in this section, "no longer a concern" seems like an overstatement; perhaps "a less serious concern" would be better?

In Section 11, is the reference to something being "widely recognized in the IETF 6man WG" needed? Is there a document or study that can be cited for this assertion instead? Also, "Other approaches ... also helps" => "Other approaches ... also help"

I would remove the claim in Section 14 that there are no "direct" security considerations in this document. It corrects a divergence from operator expectations which could lead to security vulnerabilities, as the next paragraph states.

Hi Nick, all,

Thank you for changes made so far [1] to address my review [2]. Noted your explanation about the limit of 17 route options is motivated by providing ops guidance. Better to present that explicitly as such instead of mixing it with the selection steps.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-6man-rfc6724-update-20&url2=draft-ietf-6man-rfc6724-update-22&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/ipv6/wDx4U9eI76nvm87sQs128evn6kk/

Thank you to Elwyn Davies for the GENART.