Re: [IPv6] I-D Action: draft-ietf-6man-rfc6724-update-04.txt

[Kyle Rose <[e-mail]>]

On Mon, Nov 27, 2023 at 7:29 PM Mark Smith <[e-mail]> wrote:

> Well I normally wouldn't in particular since I'm the author of this
> blog article on how to get ULA deployments right (apparently the most
> read IPv6 article in 2020, and at least 137 people have read it
> because that's how many ratings of it there are. I'll have to update
> it if it ends up being incorrect after this RFC 6724 update.)
>
> https://blog.apnic.net/2020/05/20/getting-ipv6-private-addressing-right/
>

You might want to issue a correction to that article now, because this
isn't true:

q(ULAs are preferred over GUAs, so when a host is presented with both a ULA
and GUA as possible ways to reach a destination, the host will select the
ULA. Once the ULA destination address is chosen, the host will then choose
its ULA as a source address to reach the ULA destination. This preference
of ULA addressing over GUA addressing is the mechanism that provides
internal network connectivity independence from concurrent external
Internet connectivity.)

according to the default policy table in any of 3484 (same precedence: 40),
6724 (precedence 3 < 40), or the bastardized gai.conf Debian distributes.


> However, if default address selection requires a very specific DNS
> deployment models to work (either different internal and external DNS
> names, or ULA only addresses for internal versions of names, and GUA
> only addresses for the external versions of names), tightly coupling
> the operation of default address selection to DNS configuration and
> operation,


Many different models will work fine, if they are configured correctly. As
I said, "you can lead a horse to water": we can and should write standards
that service owners and operators need to comply with for everything to
work, but we are not the protocol police and can't do much beyond telling
them what will work, what won't work, and why. Nothing you've proposed will
keep service owners from doing boneheaded things, and I am opposed to
crippling configuration options in a vain attempt to eliminate all possible
misconfigurations. Better to use all of these config options frequently, in
the spirit of GREASE, to make sure configuration errors are noticed and
fixed rather than becoming ossified and further constraining protocol and
deployment evolution.


> then I'd much rather people not be mislead about a level of
> independence between what DNS/getaddrinfo() returns, and it is hosts'
> responsibility to deal with unreachable DAs, that both RFC 3484/6724
> and RFC 4193 currently imply.
>

Yes, and mitigations are what Happy Eyeballs is for. (More on that below.)
That said, if some service provider publishes an unreachable address to
global DNS, they both deserve what they get *and* have the ability to fix
it. The only sympathy I have is for operators who are increasingly
powerless to fix problems unilaterally because they can't always filter
such bogus addresses out of DNS, and who will get complaints from users
that they can't directly resolve. The best strategy in this instance,
unsatisfying as it might be, is to inform users that the service is broken
and that they should direct their complaint at the service owner.

> I agree on the latter point, which is why I don't have much preference
> either way. Nonetheless, these kinds of misconfigurations are a "you can
> lead a horse to water" situation: as long as there have been standards,
> people have violated them, sometimes in error, sometimes out of ignorance,
> and sometimes intentionally.
>
> One interpretation I have for the second part of Postel's law (be
> liberal in what you accept) is to tolerate, up to a point, operational
> failures and misconfiguration in the interests of trying to provide
> useful connectivity when possible.
>

Agreed, but we might set that point differently. Postel's Law is not
normative for a reason. When maximal interoperability within a given
environment is your goal, it is a good approach. On the other hand, when
preserving maximal flexibility across time against protocol ossification is
your goal, it is exactly the wrong approach: specifically, when a
non-compliant implementation forces you to choose between immediate interop
and accommodating standards-violating behavior that constrains future
interop, choosing maximal interop now limits future protocol evolution.
Postel's Law is the reason why IPv6 extension headers don't work. Why ICMP
doesn't transit large parts of the IPv4 internet. Why HTTP header semantics
are such a mess. It's good for individual implementations at a given time
and bad for the evolution of the internet as a whole.

Because users really just want the internet to work, some degree of failure
mitigation is warranted, but those mitigations need to be carefully chosen
to avoid trade-offs that include promoting systematic misconfiguration that
constrains future standards development. I would argue Happy Eyeballs is a
mixed bag: it's good in that the burden of local misconfiguration is on
local users (increased connection setup latency), but it's bad in that
remote misconfiguration is rendered less visible to the service provider.
But also on the plus side, those remote misconfigurations are easily fixed
and don't constrain future standards development in any meaningful sense
beyond the limitations inherent to the slow-roll of IPv6 deployment to the
long tail. Thus I am in favor in this specific case.

Kyle