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

A note from the 6MAN session at 124: some coffee and hallway discussions have revealed that some folks might want to make a small adjustment to this draft.  Proposed text is TBD.

[Ballot comment]
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/

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-6man-rfc6724-update-20
CC @evyncke

Thank you for the work put into this document. As you may remember, I was not too happy with very first versions of this draft, and even if the changes in the document, I still cannot support it. Hence, my non-blocking ABSTAIN ballot (see comments about section 3 for more details on my position) as I do not want to go against the 6MAN WG and the IETF Last Call.

Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Jen Linkova for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

Please note that Tim Winters is the Internet directorate reviewer (at my request) and you may want to consider this int-dir review as well when it will be available (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6724-update/reviewrequest/22097/

Other thanks to Jim Reid, the DNS directorate reviewer, please consider this dns-dir review:
https://datatracker.ietf.org/doc/review-ietf-6man-rfc6724-update-20-dnsdir-telechat-reid-2025-06-03/ (2 nits worth considering)

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### Title

I am concerned that the title is only about ULA is preferred even if the actual document updates more than this aspect of RFC 6724 (e.g., 6to4 and rule 5.5).

### Section 1

Please expand ULA & GUA at first use even if defined in section 2.

### Section 3

I am not convinced by the justification of using ULA over global IPv4 and this is one cause of my ABSTAIN: `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.` and `ULAs, like GUAs, carry a higher precedence than all IPv4 addresses, making IPv6 precedence over IPv4 consistent for both ULAs and GUAs` (same ABSTAIN comment about section 7.4)

The well-known use of ULA to provide IPv6 address even of the delegated prefix is lost is perfectly fine but I am not convinced that ULA should be used when GUA is available, hence the second cause of my ABSTAIN `Nodes implementing this behavior will see ULA prefixes known to be local to the node's site having precedence over IPv4 addresses and also over IPv6 GUA addresses` (same ABSTAIN comment about sections 7.2 & 7.3).

### Section 4

s/internet/Internet/ ?

### Section 5.1

3ffe::/16 has been returned years ago by RFC 5156 (see also https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml), i.e., unsure whether it is worth mentioning this prefix (noting that RFC 6724 is also after RFC 5156).

### Section 5.2

Should this I-D formally update RFC 4861 and 4191 ? (tbh I was about to file a DISCUSS on this topic).

### Section 5.3

Explanations about why RA with the "SNAC bit" are ignored will be welcome.

### Section 9.1

s/Section 4.3/Section 4.3 of RFC4193/

### Section 10

With the change of preferences, is there any operational issues ? E.g., host A uses RFC 6724 and host B uses this updated policy table, the path/address selection will then depend on who is initiating the connection, i.e., more troubleshooting issues.

### Section 11

Unsure whether the last paragraph provides any added value.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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 is 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.

[Ballot comment]
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

[Ballot discuss]
Hi Nick, Tim, and Jeremy,

Thanks for the effort put into this specification.

Thanks to Niclas Comstedt for the OPSDIR review.

Overall, I think the text can be enhanced/shortened by avoiding many repeating and simply referencing text as appropriate instead of mirroring it here.

I plan to ballot Yes, but till then please find below some DISCUSS point, COMMENTs, and NITs.

# DISCUSS

## A rule is fine but we need justification/rationale

CURRENT:
  1.  Any RIO or PIO that is delivered in an RA in which the "SNAC
      Router" RA header flag bit [SNACBIT] is set MUST be ignored when
      considering the following rules.

  ..
  5.  ULA interface addresses from within fd00::/8, particularly ones
      not created by SLAAC, and not already covered by the known-local
      ULA list MUST be added to the list with an assumed prefix length
      of /48.  However, as with rule 1, if the ULA interface address
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      was generated on the basis of a PIO that has only been seen in
      RAs in which the SNAC router flag bit is set, this ULA prefix
      MUST NOT be used as described in this rule (rule 5).

I know that the WG spent some time discussing snac implications and so on. However, it is not obvious from the current spec what is the rationale/justification for this exception. Please add a justification. That is important to call out form an operational/implementation standpoint.

## RA Behavior

We do say in Section 3:

CURRENT:
  These changes aim to improve the default handling of address
  selection for common cases, and unmanaged / automatic scenarios

but then, we have the following in Section 5.3:

CURRENT:
  Section 4 of RFC4191 says "Routers SHOULD NOT send more than 17 Route
  Information Options in Router Advertisements per link.  This
  arbitrary bound is meant to reinforce that relatively few and
  carefully selected routes should be advertised to hosts."  The exact
  limit will depend on other Options that are used.  So, while this is
  not the practical limit discussed above, operators MUST take extra
  care not to cause the RA size to exceed the MTU when filling the RA
  with RA Options when exceeding this limit.

Why are we discussing this RA behavior here? What is specific to address selection?

Also, the scope of this document is about unmanaged networks, so which “operators” we are talking about here?

[Ballot comment]
# Consider adding an Applicability Scope Section

## The text clarifies the intended scope but that text is lost in the mass. We may consider adding a dedicated section where such matters are grouped.

That section can include the following

From Section 1:
  These changes aim to improve the default handling of address
  selection for common cases, and unmanaged / automatic scenarios
  rather than those where DHCPv6 is deployed. 

From Section 5.3

  The identification and insertion of known-local prefixes under
  fc00::/8 is not defined.

+

Summary of Section 11

## Although the text mentions residential, the reasoning to justify the change is enterprise-centric.

# Operational Considerations Section

The document includes several ops considerations but those are scattered in several locations and it is not easy to glue them together.

Please consider grouping these matters in one single place. Examples of text that can be moved to that sections are:


Section 4:
Leaving this entry in the default table will cause no
  problems and will help if any deployments still exist, and ensure
  6to4 prefixes are differentiated from general GUAs.


Section 14:
  Operators should be mindful of cases where communicating nodes have
  differing behaviors for address selection, e.g., RFC 3484 behavior,
  RFC 6724, the updated RFC 6724 behavior defined here, some other non-
  IETF-standardized behavior, or even no mechanism.  There may thus be
  inconsistent behavior for communications initiated in each direction
  between two nodes.  Ultimately all nodes should be made compliant to
  the updated specification described in this document.

Your current Section 6/7 can be positioned as subsection of that Ops cons section.

# Known-local ULA Definition

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

It seems to me this is not the definition used in the document, which is more about nodes making that call. I think the definition should be updated to be consistent with the use in the spec.

# Claimed issues

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

I’m afraid that some elaboration is needed for each of these points. For example, I don’t quite understand the planning issue let alone the security one. Independent of whether GUA/ULA is the communication will stay within a local network.

BTW, I don’t think that we need to over-justify the preference rule change.

# Operators

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

First, I guess this is similar to “administrator” in RFC6724. Maybe better to follow the same terminology here as well.

BTW, 6724 already allows for that in managed networks assuming a configuration knob is supported to tweak the ULA preference.

# Inappropriate use of normative language

OLD:
  The second change is the introduction of the concept of known-local
  ULAs.  RFC6724 includes a method by which nodes MAY provide more
  fine-grained support for further elevating the preference for
  specific ULA prefixes, while leaving other general ULA prefixes at
  the precedence described in the previous paragraph.  This document
  elevates the requirement for specific ULA prefixes to be inserted
  into the policy table to be a MUST, but only for observed prefixes
  that are known to be local, i.e., known-local ULAs. 

NEW:
  The second change is the introduction of the concept of known-local
  ULAs.  RFC6724 includes a method by which nodes may provide more
  fine-grained support for further elevating the preference for
  specific ULA prefixes, while leaving other general ULA prefixes at
  the precedence described in the previous paragraph.  This document
  elevates the requirement for specific ULA prefixes to be inserted
  into the policy table to be a “MUST”, but only for observed prefixes
  that are known to be local, i.e., known-local ULAs. 

# Redundant Behavior

Some behaviors are repeated several times in the document. For example,

  MUST, and third to require that nodes MUST insert observed known-
  local ULA prefixes into their policy table.

and

  This document thus elevates the MAY requirement above for insertion
  to a MUST for the specific case of known-local ULAs.

Please use the normative language only once and reword the other occurrences (better to simply avoid repeating).

There are other similar constructs. I trust the authors will check through the doc and update accordingly.

# I appreciate the sentence about the order of rows in the policy, but it is not convenient for readers. I suggest we sort them by preference similar to 6724.

CURRENT:
                    RFC6724                              Updated
Prefix      Precedence Label        Prefix        Precedence Label
::1/128              50    0        ::1/128              50    0
                                    $known_local/48      45    14 (**)
::/0                40    1        ::/0                  40    1
::ffff:0:0/96        35    4        ::ffff:0:0/96        20    4 (*)
2002::/16            30    2        2002::/16              5    2 (*)
2001::/32            5    5        2001::/32              5    5
fc00::/7              3    13        fc00::/7              30    13 (*)
::/96                1    3        ::/96                  1    3
fec0::/10            1    11        fec0::/10              1    11
3ffe::/16            1    12        3ffe::/16              1    12


The CURRENT comparison table can be moved to an appendix.

# Nits

## Please use appropriate references rather than plain labels. For example,

OLD: Section 5 of RFC6724
NEW: Section 5 of [RFC6724]

There are many such to fix in the document.

## Explicit references

Some citations are confusing as it is not clear which section is targeted by a given citation.

For example, consider making this change:

(1)

OLD:
  It was always expected that the default policy table may need to be
  changed based on operational experience; Section 2.1 says

NEW:
  It was always expected that the default policy table may need to be
  changed based on operational experience. Section 2.1 of [RFC6724] says

(2)

OLD:
  [RFC4193] defines ULAs within fc00::/7, where the L bit as detailed in
  Section 3.1, is set to 1 for locally assigned (generated) prefixes,

NEW:
  Section 3.1 of [RFC4193] defines ULAs within fc00::/7, where the L bit,
  is set to 1 for locally assigned (generated) prefixes,

(3)

OLD:
  Section 4.3 states "Site border routers and firewalls should be
  configured to not forward any packets with Local IPv6 source or
  destination addresses outside the site, unless they have been
  explicitly configured with routing information about specific /48 or
  longer Local IPv6 prefixes".

NEW:
  Section 4.3 of [RFC4193] states "Site border routers and firewalls should be
  configured to not forward any packets with Local IPv6 source or
  destination addresses outside the site, unless they have been
  explicitly configured with routing information about specific /48 or
  longer Local IPv6 prefixes".

There are several such uses in the draft that are confusing. Please double check.

# I guess I know what you meant by “IPv4 globals”, but that’s not a term I’m aware of. Consider “IPv4 global addresses” or something similar.

# An RFC is frozen, so consider:

* s/current RFC6724/[RFC6724]
* s/ The current default policy table leads/The [RFC6724] default policy table leads

# Section 4

s/public internet/public Internet

# Section 5.2: Distraction

CURRENT:
  The heuristic for address selection defined in Rule 5.5 of Section 5
  of RFC6724 to prefer addresses in a prefix advertised by a next-hop
  router has proven to be very useful.

I suggest to delete this text and focus on the updates. This claim is anyway redundant with the introduction.

# Section 5.3: Redundant text, again

CURRENT:
  The use of ULAs where L=0, i.e., prefixes
  under fc00::/8, is currently undefined.

While Section 1 has already:

  as detailed in
  Section 3.1, is set to 1 for locally assigned (generated) prefixes,
  with L=0 as yet undefined. 

# Section 7.3: nit

OLD:
  Host A has address ULA1::1 and GUA1:1::1 Host B has address ULA2::1
  and GUA1:2::1

NEW:
  Host A has address ULA1::1 and GUA1:1::1. Host B has address ULA2::1
  and GUA1:2::1

Cheers,
Med

[Ballot comment]
# 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

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-6man-rfc6724-update-18, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-04-02):

From: The IESG
To: IETF-Announce
CC: 6man-chairs@ietf.org, draft-ietf-6man-rfc6724-update@ietf.org, ek.ietf@gmail.com, furry13@gmail.com, ipv6@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Prioritizing known-local IPv6 ULAs through address selection policy) to Proposed Standard


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document: - 'Prioritizing known-local IPv6 ULAs
through address selection policy'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-04-02. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document draws on several years of operational experience to
  update RFC 6724, defining the concept of "known-local" ULA prefixes
  that enable ULA-to-ULA communications within fd00::/8 to become
  preferred over both IPv4-IPv4 and GUA-to-GUA for local use.  The
  document defines the means by which nodes can both identify and
  insert such prefixes into their address selection policy table.  It
  also clarifies the mandatory, unconditional requirement for support
  for Rule 5.5 and demotes the preference for 6to4 addresses.  These
  changes to default behavior improve supportability of common use
  cases, including automatic / unmanaged scenarios, and makes
  preference for IPv6 over IPv4 consistent in local site networks for
  both ULA and GUA prefixes.  It is recognized that some less common
  deployment scenarios may require explicit configuration or custom
  changes to achieve desired operational parameters.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6724-update/



No IPR declarations have been submitted directly on this I-D.

# Internet AD comments for draft-ietf-6man-rfc6724-update-17
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

## Comments

### S5.2

* I suspect it might be a bit more clear to reword as follows:

  "although the conceptual models ... have no such requirement"

  "despite the conceptual models ... having no such requirement"

  But this is only minor.  Just for your consideration.

### S5.3

* "router flag bit is set MUST NOT be used" ->
  "router flag bit is set, this ULA prefix MUST NOT be used"

* "operators MUST take extra care not to overflow the RA with RA Options" ->

  "operators MUST take extra care not to cause the RA size to exceed the
  MTU when filling the RA with RA Options"

  Perhaps? If I've misunderstood the intent, then happy to iterate towards
  the most correct text.

## Nits

### S1

* "where the prefixes conform to the definition in Section 3.1" ->
  "where the prefixes conform to the definition in Section 3.1 of RFC 4193"

  The text might mislead a reader to look for a section 3.1 of _this_
  document.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has been actively discussed in the WG mailing list and during 6MAN sessions,
with many participants expressing their opinions, comments and suggestions.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

While some topic (such as processing PIOs advertized by SNAC routers and
what prefix length to use for known-local ULAs) caused very active discussions on the list
and resulted in significant changes to the document, all issues were resolved to everyone's satisfaction.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There are two implementations of the proposed changes to RFC6724:

- Android implements the proposed changes to insert "known-local" ULAs into the policy table:
https://r.android.com/3046000
- The authors created a proof-of-concept implementation, available at https://github.com/jeremy-duncan/raio_ula

Those details are also reported in The "Implementation Status" section of the document.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The document doesn't impact/interact with technologies in other WGs/orgs.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A


7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document contains no YANG modules.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The document contains no such sections.


## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Absolutely!
The document introduces very useful tweaks for the default address selection algorithm.
With the proposed changes, ULAs can actually become useful and pave the road for IPv6 adopton in enterprise-like networks.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No issues have been identified for the document.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard, which is the proper type: this document updates RFC6724 (standard track).

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The authors are not aware of any IPRs:
https://mailarchive.ietf.org/arch/msg/ipv6/9O51DA2JWaOWLtuefscdvp-MLoc/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The document has 3 authors, and all of them are willing to be listed as such:
https://mailarchive.ietf.org/arch/msg/ipv6/9O51DA2JWaOWLtuefscdvp-MLoc/

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All other idnits issues on -17 are false positives.

No issues listed in the "Content Guidelines" have been identified.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No. During the shepherd's review of -16 all such references were identified and fixed.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No such references.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

See below (#18)


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

The document refers to a new RA flag defined in draft-ietf-6man-snac-router-ra-flag.
draft-ietf-6man-snac-router-ra-flag is in the RFC editors queue waiting for draft-ietf-snac-simple to be submitted for the publication, so there is a dependency here.
draft-ietf-snac-simple is expected to enter the WGLC soon.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

Yes, this document updated RFC6724, which is reflected in the document metadata.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document doesn't introduce any IANA considerations.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has been actively discussed in the WG mailing list and during 6MAN sessions,
with many participants expressing their opinions, comments and suggestions.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

While some topic (such as processing PIOs advertized by SNAC routers and
what prefix length to use for known-local ULAs) caused very active discussions on the list
and resulted in significant changes to the document, all issues were resolved to everyone's satisfaction.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There are two implementations of the proposed changes to RFC6724:

- Android implements the proposed changes to insert "known-local" ULAs into the policy table:
https://r.android.com/3046000
- The authors created a proof-of-concept implementation, available at https://github.com/jeremy-duncan/raio_ula

Those details are also reported in The "Implementation Status" section of the document.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The document doesn't impact/interact with technologies in other WGs/orgs.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A


7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document contains no YANG modules.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The document contains no such sections.


## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Absolutely!
The document introduces very useful tweaks for the default address selection algorithm.
With the proposed changes, ULAs can actually become useful and pave the road for IPv6 adopton in enterprise-like networks.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No issues have been identified for the document.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard, which is the proper type: this document updates RFC6724 (standard track).

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The authors are not aware of any IPRs:
https://mailarchive.ietf.org/arch/msg/ipv6/9O51DA2JWaOWLtuefscdvp-MLoc/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The document has 3 authors, and all of them are willing to be listed as such:
https://mailarchive.ietf.org/arch/msg/ipv6/9O51DA2JWaOWLtuefscdvp-MLoc/

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All other idnits issues on -17 are false positives.

No issues listed in the "Content Guidelines" have been identified.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No. During the shepherd's review of -16 all such references were identified and fixed.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No such references.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

See below (#18)


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

The document refers to a new RA flag defined in draft-ietf-6man-snac-router-ra-flag.
draft-ietf-6man-snac-router-ra-flag is in the RFC editors queue waiting for draft-ietf-snac-simple to be submitted for the publication, so there is a dependency here.
draft-ietf-snac-simple is expected to enter the WGLC soon.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

Yes, this document updated RFC6724, which is reflected in the document metadata.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document doesn't introduce any IANA considerations.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has been actively discussed in the WG mailing list and during 6MAN sessions,
with many participants expressing their opinions, comments and suggestions.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

While some topic (such as processing PIOs advertized by SNAC routers and
what prefix length to use for known-local ULAs) caused very active discussions on the list
and resulted in significant changes to the document, all issues were resolved to everyone's satisfaction.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

- Android implements the proposed changes to insert "known-local" ULAs into the policy table:
https://r.android.com/3046000
- The authors created a proof-of-concept implementation, available at https://github.com/jeremy-duncan/raio_ula

The authors have been asked to include the "Implementation Status" section to -17.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The document doesn't impact/interact with technologies in other WGs/orgs.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A


7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document contains no YANG modules.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The document contains no such sections.


## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Absolutely!
The document introduces very useful tweaks for the default address selection algorithm.
With the proposed changes, ULAs can actually become useful and pave the road for IPv6 adopton in enterprise-like networks.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No issues have been identified for the document.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard, which is the proper type: this document updates RFC6724 (standard track).

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The authors are not aware of any IPRs:
https://mailarchive.ietf.org/arch/msg/ipv6/9O51DA2JWaOWLtuefscdvp-MLoc/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The document has 3 authors, and all of them are willing to be listed as such:
https://mailarchive.ietf.org/arch/msg/ipv6/9O51DA2JWaOWLtuefscdvp-MLoc/

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

The idnits tool reports some non-ASCII characters, this is fixed by https://github.com/buraglio/draft-buraglio-6man-rfc6724-update/pull/45 and shall be included in -17.
All other idnits issues on -16 are false posivites.

No issues listed in the "Content Guidelines" have been identified.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

Yes, some chnages need to be made in Normative and Informative, shall be addressed in -17/


16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No such refeerences.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

See below (#18)


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

The document refers to a new RA flag defined in draft-ietf-6man-snac-router-ra-flag.
draft-ietf-6man-snac-router-ra-flag is in the RFC editors queue waiting for draft-ietf-snac-simple to be submitted for the publication, so there is a dependency here.
draft-ietf-snac-simple is expected to enter the WGLC soon.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

Yes, this document updated RFC6724, which is reflected in the document metadata.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document doesn't introduce any IANA considerations.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/