Re: [v6ops] ULA precedence [Thoughts about wider operational input]

[Vasilenko Eduard <[e-mail]>]

Hi Erik,
Thanks for the feedback.
I believe that solution that you have described below would not work in some corner cases.
You effectively said below:
1. Prioritize ULA (as a separate /48, but it does not matter - possible to prioritize the whole FC/7 by changing the default)
2. Attach a special Label (redundant action because FC/7 already has unique Label=13)

Imagine the situation where only one router on the link announces ULA PIO, but the other one - GUA PIO.
(Routers are not in sync for announcements).
Then we know that the default behavior of source address selection is to choose the next-hop first (bad! See below).
If the first router is chosen for the next-hop (it is round-robin by the current RFC 4861) then the GUA source would never be possible to choose
Because Rule 5.5 (Prefer addresses in a prefix advertised by the next-hop) is above Rule 6 (Prefer matching label).
If the second router is chosen by next-hop then ULA source is never possible for the same logic.

The root cause why it should not work: next-hop is chosen before the source address.
(by the way, it is a very big problem that prevents MHMP too - we will publish the document soon.
Hence, it is better to reverse this order anyway, section 7 of RFC 6724 has good comments about it - it just needs to be expanded)

Eduard
-----Original Message-----
From: v6ops [mailto:[e-mail]] On Behalf Of Erik Auerswald
Sent: Sunday, April 24, 2022 8:28 PM
To: Nick Buraglio <[e-mail]>
Cc: v6ops list <[e-mail]>; 6man list <[e-mail]>
Subject: Re: [v6ops] ULA precedence [Thoughts about wider operational input]

Hi Nick,

I saw your Internet-Draft draft-buraglio-v6ops-ula on "The Daily Dose of IETF" <https://tools.ietf.org/dailydose/>, issue 4085 from 2022-04-22.  I found the title of interest to me, because some years ago I tried to deploy ULA and came to the conclusion that this resulted in more problems than solutions.  But my experience differs markedly from what I read in the draft.

What I have experienced is implementing ULA addressing inside an organization some years ago.  But back then IPv6 ULA was preferred over IPv4, and NAT for IPv6 was not widely available.
We did have NAT for IPv4, but not for IPv6.  But with ULA treated the same as GUA, connections to external hosts with both IPv4 and GUA IPv6 addresses were attempted with ULA source addresses.
This obviously did not work.  Additionally, we encountered address selection problems where some host would prefer a ULA source address to reach external GUA destinations, even though it could have used a GUA source address.  We then reverted to only using GUA for IPv6.

The policy table from RFC 6724 Section 2.1 addresses all of the above problems.  RFC 6724 also describes extensions for specific use cases, including that of preferring ULA for use inside an organization (or lab).

Section 2.1 of RFC 6724 contains:

 "An implementation MAY automatically add additional site-specific
  rows to the default table based on its configured addresses,
  such as for Unique Local Addresses (ULAs) [RFC4193] [...] (see
  Sections 10.6 [...])."

Section 3.1 of RFC 6724 contains:

 "Also, note that ULAs are considered as global, not site-local,
  scope but are handled via the prefix policy table as discussed
  in Section 10.6."

Section 10.6 of RFC 6724 contains:

 "By default, global IPv6 destinations are preferred over
  ULA destinations, since an arbitrary ULA is not necessarily
  reachable[.]"

 "However, a site-specific policy entry can be used to cause ULAs
  within a site to be preferred over global addresses as follows."

Then the site specific ULA /48 prefix is inserted into the policy table, with precedence higher than that of GUA, and with a different label.  Because of the higher precedence, ULA is preferred over GUA.
Because of the different labels of ULA and GUA, connections to GUA destinations prefer GUA source addresses over ULA.

This can be done automatically, as described in the same section:

 "Since ULAs are defined to have a /48 site prefix, an implementation
  might choose to add such a row automatically on a machine with
  a ULA."

The result is that only the local ULA prefix, i.e., exactly the local IPv6 addresses, are preferred over IPv4 (and IPv6 GUA).
This should be exactly what is needed to use ULA addresses inside an organization, or for a lab.

It seems to me as if RFC 6724 already includes the general solution for the problem described in your draft, i.e., adding the locally used ULA /48 prefix with appropriate precedence and label to the address selection policy table.

Implementing the non-normative suggestion from Section 10.6 of RFC
6724 would in all likelihood result in making ULA usable for local tests and even first steps in deploying IPv6.  ULA addresses would only be used locally.  Existing IPv4 based Internet access would not be impaired by adding IPv6 ULA.

Application layer gateways could be deployed with ULA on the inside and GUA on the outside.

Local servers with external IPv6 services only available via GUA, but without IPv4, would be reachable using ULA source addresses.
This would allow to, e.g., host an IPv6 web page using a DNS entry without A record as part of those first steps towards implementing IPv6, and transparently combine it with ULA on local clients, without negatively affecting said clients' Internet access which is still based on IPv4 (often private addresses with NAT).

In order to keep IPv6 deployment similar to IPv4, IPv6 NAT could be considered.  To make this work as intended, the address selection policy table could be adjusted to contain the local ULA prefix with precedence greater or equal to GUA and the same label as GUA.
The automatic ULA row addition from RFC 6724 should then be disabled using the "Automatic Row Additions flag" from RFC 6724 Section 2, if it were implemented and enabled otherwise.

After gaining some experience with IPv6, one has a better basis to decide how to proceed, i.e., if GUA addresses shall be used for Internet access, or ULA + NAT instead.  This experience gathering process might include deploying IPv6 NAT, GUA on client subnets,
IPv6 ALGs, or a combination of those.

If after the first steps in IPv6 use one should decide that ULA + NAT shall be used instead of GUA without NAT, local policy could be implemented by adjusting the address selection policy table as described above.  Such adjustments are within the possibilities provided by RFC 6724.

It might be helpful to ask operating system vendors for full support of RFC 6724, including section 10.6, i.e., automatically adding a local ULA /48 prefix with appropriate precedence and label to the address selection policy table.

It might also be helpful to ask operating system vendors for improved administrative tools to ease adjustment of the address selection policy.  To support testing different variants, such adjustments should be possible dymanically, without needing to restart processes or reboot systems.  As such the GNU C Library
(glibc) implementation that is not thread safe and thus discourages use of its "reload" functionality seems to show potential for improvement (https://man7.org/linux/man-pages/man5/gai.conf.5.html).

It might even be helpful to ask operating system vendors to implement a simple toggle to enable or disable an address selection policy that caters towards ULA with IPv6 NAT (e.g., removing the policy table entry for fc00::/7, or changing both preference and label to be identical to the GUA entry ::/0).

With kind regards,
Erik
--
Dipl.-Inform. Erik Auerswald
Gesellschaft für Fundamental Generic Networking mbH
Geschäftsführung: Volker Bauer, Jörg Mayer
Gerichtsstand: Amtsgericht Kaiserslautern - HRB: 3630

_______________________________________________
v6ops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops