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

[Nick Buraglio <[e-mail]>]

On Sun, Apr 24, 2022 at 12:28 PM Erik Auerswald <[e-mail]>
wrote:

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

Yes, this was basically what process I went through as ULA has become
increasingly mentioned as part of large IPv6 migrations I am involved with
right now.


>
> 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.
>
> Sure, I've done this just to see that it worked, but as stated in the
draft it is not a scalable or supportable solution since a great number of
implementations do not make this available. Embedded systems and other
speciality devices are particularly difficult here making it operationally
unviable.



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

The issue lies with the inconsistency. As the preference table is
inaccessible on many platforms, it becomes operationally untenable, and
since ULA operates differently than GUA by design, it imposes yet another
fairly large impediment to enterprise adoption, which will almost certainly
remain dual-stacked for the foreseeable future, looking to closely mirror
their IPv4 architectures.


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

My testing shows that IPv6 NAT options and this type of architecture works
in an IPv6 only environment, but without being able to address the IoT and
OT systems preference tables, it's stuck with IPv6-only. This works for
what I need right now, but that is an edge case for the vast majority of
other deployments that still require IPv4.

>
> 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).
>

With my operational hat on, that feels fairly over-complicated as it
requires double the overhead in most cases, therefore will almost always
solicit a "nope, not worth the effort" from the enterprise world.


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

While not my first choice, I recognize the high likelihood of environments
requiring address translation and have tested various forms of IPv6 NAT,
which do work, but it falls right back into the issue of the option to
update said table being unavailable, because it's not required anywhere so
dual stacking with ULA is a non-starter for any useful IPv6 dual stack
deployment that involves anything remotely out of the ordinary.


> 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).
>

Sure, but as noted in the draft (and the one of the main points we're
trying to make), is that there is a huge runway to get any usable options
in operational gear, and an impossibly long ramp up for anything ! =
mainstream Linux. Noting these shortcomings at least highlights the
significant operational gaps involved with ULA.


>
> 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
>
ᐧ