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

[Erik Auerswald <[e-mail]>]

Hi Fred,

On Wed, May 04, 2022 at 10:53:58AM -0700, Fred Baker wrote:
> > On Apr 28, 2022, at 12:50 AM, Erik Auerswald <[e-mail]> wrote:
> > 
> > I'd say that _remote_ ULAs are less reliable than GUAs. Selecting
> > ULA source to reach GUA destination risks that the return
> > traffic would be sent to a _remote_ ULA (if the initial packet
> > even reaches the destination; it could be filtered because of
> > using a "wrong" source address).
> > 
> > The RFC 6724 default errs on the side of caution by assuming
> > that ULA are non-local, unless either auto-detected or configured
> > as local.
> 
> From a specification perspective, it seems to me that the two
> cases should be separated. If I have a local ULA address and a
> peer I want to communicate with has an address in the same prefix,
> then I probably should prefer to use that address pair unless I
> have a reason not to. In any other case, I should use my own GUA
> and send the message to my peer's GUA - I have no guarantee of
> connectivity otherwise.

Indeed they are separated.  The procedure from RFC 6724 section
10.6 distinguishes between local and remote ULA addresses.

RFC 6724 also distinguishes between GUA and ULA and does prefer to
use GUA source to reach GUA destination and ULA source to reach
ULA destination.  Section 10.6 describes how to automatically
distinguish between local and remote ULA.

The RFC 6724 section 10.6 procedure prefers local ULA over GUA when
selecting destination addresses.

Source address selection by default prefers the same kind of address,
e.g. GUA to reach GUA and ULA to reach ULA.  Following section 10.6
refines this to prefer local ULA to reach local ULA and remote ULA to
reach remote ULA.

For a host with ULA and GUA, when connecting to a host with only
ULA, when one of the hosts does not provide IPv4 as well, ULA
is preferred.

That is the situation Ted Lemon described at IETF 113 (slides at
https://datatracker.ietf.org/meeting/113/materials/slides-113-6man-source-address-selection-for-foreign-ulas-00)
As Ted described, when introducing a router that adds ULA addresses
where there were none before, and without integrating those new
addresses into the routing information bases of all routers, this
can lead to problems.

With the optional rule 5.5 from section 5, RFC 6724 already provides
a solution for the specific problem described by Ted.  No changes
to RFC 6724 needed.

> In fact, I'm not sure how I would know that my peer has an
> address that is not in my ULA prefix. It shouldn't be in DNS,
> as I recall (RFC 4193 section 4.4). That might mean a split DNS
> implementation...

Well, there is a difference between "that should usually not happen"
and "this is impossible" (and for the latter, theory and practice
too often differ).

To circle back to Nick's problem:

RFC 6724, describing default IPv6 address selection, does not
distinguish between different kinds of IPv4 addresses, only between
different kinds of IPv6 addresses.  But it does prefer using IPv4
destination addresses over remote (i.e., not known to be local)
ULA addresses.

This leads to the problems described in Nick's draft
(draft-buraglio-v6ops-ula):

- If two internal hosts have both IPv4 and ULA IPv6 addresses, where
  the ULA addresses are neither auto-detected as local (ref. RFC
  6724 section 10.6) nor configured as local, they prefer IPv4.
  But Nick would like them to prefer IPv6.

  This can be solved by local configuration to designate the local
  ULA /48 prefix as local.  This can also be solved by using hosts
  that implement RFC 6724 section 10.6.

- If an internal host with both IPv4 and ULA IPv6 addresses, where
  the ULA addresses are neither auto-detected as local (ref. RFC
  6724 section 10.6) nor configured as local, attempt a connection
  to a remote host with both IPv4 and GUA IPv6 addresses, it will
  prefer IPv4.  But Nick would like it to prefer IPv6.

  This can be solved by local configuration, i.e., changing the
  ULA entry in the address selection policy table from RFC 6724,
  as described in RFC 6724.

  Nick points out that readily available open-source operating
  systems (GNU/Linux in the example from the draft) do not make
  this as easy as one could wish for.

The latter point is where I disagree with Nick, because of my
bad experience with exactly the behavior Nick is asking for.

Communication with a remote IPv6 host over the Internet does not
work if the local system uses a ULA IPv6 address (return traffic
cannot be routed, and the outgoing packet should have been filtered
for using a ULA source address on the Internet).

For the latter to work, some kind of IPv6 NAT is required.

For Nick's implicit idea that Enterprises want to use IPv6 exactly
as they use IPv4, adding just one ULA address where they already
have one RFC 1918 address, without any additional configuration
(they don't need address selection policy configuration for IPv4),
and with NAT66 for Internet access, treating ULA identically to GUA,
as done in RFC 3484 which was obsoleted by RFC 6724, would work.
The refined RFC 6724 situation requires local configuration for
this to work.

But this did not work for the idea of using ULA only for local
connectivity in an RFC 3484 situation, as I experienced back when,
and thus described as reaction to Nick's draft.  I would not like to
see a regression to before RFC 6724.  I would like to see more of
RFC 6724 implemented in all kinds of hosts, including the example
from section 10.6 and the optional source address selection rule
5.5 from section 5.

Without NAT66, treating ULA identical to GUA, leads to longer
connection times (Happy Eyeballs) or connection failures (no Happy
Eyeballs) when attempting to reach dual-stack Internet hosts from
local dual-stack hosts with only ULA, but no GUA, IPv6 addresses.
This in turn results in disabling IPv6 again, because it causes
problems.  RFC 6724 solved that problem.

I think that RFC 6724 describes a useful default behavior, allows for
and describes useful extensions, and supports local configuration
to use a non-default behavior if required.  I do not think that
RFC 6724 is wrong.

I would like host implementations to be extended to comprise more
of RFC 6724 (e.g., dynamic address selection policy adjustments,
automatic addition of the local ULA prefix to this policy table
(this is section 10.6), and tracking which router advertised which
prefixes to enable source address selection rule 5.5).  Making the
existence and configuration of said address selection policy table
both more easily discoverable and configurable would most likely
improve the situation, too.

Thanks,
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