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

[Brian E Carpenter <[e-mail]>]

David,
On 03-May-22 03:03, David Farmer wrote:
> 
> 
> On Mon, May 2, 2022 at 7:32 AM Mark Smith <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> 
>     On Mon, 2 May 2022, 13:51 David Farmer, <farmer=[e-mail] <mailto:[e-mail]>> wrote:
> 
>         ...
>         I believe RFC 6724 is correct, ULAs that are not known to be local, 
> 
> 
>     If a host is given a ULA as a candidate DA, then it is to be considered local and reachable, because per RFC4193, ULA addresses are not to appear in global DNS.
> 
> 
> So IFF, the ULA addresses are not learned from DNS, 

That is, I think, irrelevant. All we are really talking about is the order in which results are returned by getaddrinfo(), which is what RFC6724 determines. At present, you will get this back from getaddrinfo() for a locally defined DNS entry (in Pythonic format):

(<AddressFamily.AF_INET: 2>, 0, 0, '', ('10.1.0.10', 0))
(<AddressFamily.AF_INET6: 23>, 0, 0, '', ('fdee:face:fade::a', 0, 0, 0))

and 99% of app programmers will use the first entry.

Of course, the desired behaviour is to get:

(<AddressFamily.AF_INET6: 23>, 0, 0, '', ('fdee:face:fade::a', 0, 0, 0))
(<AddressFamily.AF_INET: 2>, 0, 0, '', ('10.1.0.10', 0))


> and I'm not sure that is a safe assumption. For example, RFC 5220 section 2.2.2 seems to imply ULAs within the DNS, which is one of the referenced sections in the first paragraph of 10.6.
> 
> Further, as noted in RFC 5220 section 2.1.4, again one of the 
referenced sections in the first paragraph of 10.6;
> 
>     If the ULA is used for internal communication, packets with the ULA 
need to be filtered at the Router.
> 
> 
> That being the router at the Internet boundary for the local network. Your statement also assumes such filtering is present, and again that doesn't seem to be a safe assumption.

Yes it is, in the case of unmanaged domestic and SOHO networks with COTS equipment. Where it might be unsafe is in badly managed enterprise networks. If a network is badly managed *and* puts a faulty AAAA record in local DNS, yes, there might be a black hole.  Or anything else could go wrong, because the network is badly managed.

> So, IFF ULAs are not in the DNS, and ULAs are filtered at the Internet boundary for the local network, can a host assume a ULA given as a candidate DA, is in fact local and not a remote ULA address.

Yes, unless there is a gross misconfguration.

> And at least in my personal experience and the problems as stated in RFC 5220, 

That's a very old document now and it triggered the work on RFC3484 --> RFC6724.

> seems to indicate those conditions are not reliably the case. Put another way, the assumption that a ULA given as a candidate DA is in fact 
a local ULA, and not a remote ULA, is probably only true for well-run and 
well-configured networks.  And I for one would like IPv6 to operate as robustly as possible and work even when a network is misconfigured in some way(s).

Yes, but there are limits. I don't see that we can ever deal with a gross 
ULA misconfiguration that leads to non-local ULAs appearing in the local DNS. Possibly a monitoring system could detect it and issue a warning, but there is no way to prevent a human error leading to it. My example above was produced by patching bogus entries into my hosts file plus four lines of Python:

import socket
gai = socket.getaddrinfo('printer.mynet.example.com', None)
for x in gai:
     print(x)

> 
> Remember, RFC 6724 was intended to deal with issues that caused traffic 
to be black-holed when IPv6 was enabled, and as a result, many people were simply disabling IPv6, so let's be careful not to go back to those days.
> 
>         should be considered remote and GUA IPv6 and IPv4(both GUA and RFC 1918) should be considered more reliable than any possibly/probably remote ULA prefix. Where RFC 6724 failed, is not to require the known to be local ULAs to be added to the table, so ULA will function as intended.

Right. We need to work on that.

Regards
     Brian