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

[Erik Auerswald <[e-mail]>]

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