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

[Mark Smith <[e-mail]>]

On Tue, 28 Nov 2023 at 05:04, Nick Buraglio
<[e-mail]> wrote:
>
>
>
> On Mon, Nov 27, 2023 at 11:24 AM Mark Smith <[e-mail]> wrote:
>>
>>
>>
>> On Tue, 28 Nov 2023, 03:56 Kyle Rose, <[e-mail]> wrote:
>>>
>>> On Mon, Nov 27, 2023 at 11:46 AM Mark Smith <[e-mail]> wrote:
>>>>
>>>> I think more in an enterprise/service provider context and scale by default, so for robustness and end-user friendliness (technical and non-technical), I would put both ULA and GUA addresses for hosts in internal DNS for the same DNS name.
>>>>
>>>> Robustness means if the ULA or GUA address is unreachable, the alternative address becomes a fall back.
>>>>
>>>> End-user friendliness means end-users use the same domain name to reach a host regardless of if they're internal or external to the network. The less end-users have to remember special or different cases the better.
>>>
>>>
>>> All valid justifications for offering both address classes under the same names, but it occurs to me that what you proposed doesn't actually solve any problems. The actual issue is the GUA PD changing: no matter what DNS says, if the GUA prefixes change, connections using those addresses break and need to be reestablished. If you offer only GUA, that means 100% of such connections. If you offer ULA in addition to GUA, that means either 0% are broken (if ULA->ULA is preferred)
>>
>>
>> Which is why I say ULAs need to be preferred over GUAs
>>
>> Which is why RFC 4193 implies ULAs are preferred over GUAs.
>>
>> Which was why site-locals were preferred over GUAs.
>>
>>
>>> or 100% are broken (if GUA->GUA is preferred).
>>
>>
>> Yes, which is why I have such a big problem with preferring GUAs over ULAs.
>>
>> If GUAs end up being preferred over ULAs, then I'm going to write up a draft that ultimately will remove a huge amount of complexity from SA and DA selection.
>>
>> - LLAs can only be used for ICMPv6 and DHCPv6, not any applications (sorry Dentists).
>>
>> - ULAs are only for private, isolated, non-Internet connected networks such as IoT networks e.g. electricity smart meter networks.
>>
>> GUAs are used for networks that are connected to the Internet.
>>
>>
>> A much simpler model of IPv6 addressing would have saved months of discussion about this ULA preference update and 100s of emails.
>>
>> Given some recent IPv6 deployment experiences, it'll also be easier for people coming from IPv4 to understand.
>>
>> It would have also likely avoided the issue that RFC 6724 created because it would have been even more obvious that ULA addresses should not be put in global DNS, and nor would people now be trying to optimise for an error case of ULA in global DNS - the only reason to prefer GUA over ULA.
>>
>> It will also simplify RFCs that have had to deal with multiple candidate SAs or DAs e.g. ND if I recall correctly.
>
>
> This I agree with, there should be a smarter SA/DA selection process and we should work on that, for sure.

I'm saying the opposite above. SA/DA selection should be much
*simpler* as a better alternative to breaking a main use case of ULAs
with this ID.

> This change is far more tactical

Tactical would be to update RFC 6724 to how it should have updated RFC
3484 and nothing more - effectively replace site-locals with ULAs and
leave it as that, because the use case of ULA is the same as
site-locals (so global GUA renumbering doesn't disrupt internal
communications).

I don't entirely understand why ULAs ended up with a global scope,
however they really have a "local-network" scope, and that local
network scope is smaller than global scope. The DA scope comparison
step, Rule 8: Prefer smaller scope, would prefer the local-network
scope (ULA) over global scope (GUA).

> and opportunistic. Anything more is a very large lift outside of the scope for this draft (by design). In whatever this next selection process becomes, it should appropriately and elegantly address the addressing differences in a less rigid way allowing for "best value" rather than class based selections.
>
> Circling back to the draft, much of this discussion seems to come down to how DNS is implemented in a given network, which I strongly believe is a parallel problem space, and even more subjective than the address selection process.
>
> Under the proposed model in the update:
>
> * Operator deploys ULA and GUA
> ** Operator chooses to use split DNS - no problems. All works as designed internal hosts use ULA, external connections use GUA as those are the only options presented to them

That needs to be specifically articulated in the ID if that is the
case. In other words, there need to be *specific* instructions on how
to operate DNS in the context of default IPv6 address selection if
default address selection is going to rely on the deployment model
you've documented.

As I said before I'd both ULA and GUA addresses in the internal split
DNS domain for connectivity robustness, and rely on this text in RFC
6724 (an expansion on what is in RFC 3484) to provide this robustness:

   Well-behaved applications SHOULD NOT simply use the first address
   returned from an API such as getaddrinfo() and then give up if it
   fails.  For many applications, it is appropriate to iterate through
   the list of addresses returned from getaddrinfo() until a working
   address is found.  For other applications, it might be appropriate to
   try multiple addresses in parallel (e.g., with some small delay in
   between) and use the first one to succeed.


> ** Operator uses the same names *internally* for GUA and ULA. Source tries w/ IPv6 ULA -> ULA first. All works.

Well it wouldn't be trying ULA first, there is no GUA DA to try second
in your deployment model. It would be *only* trying ULA.

> ** Operator uses different domain names for ULA and GUA on the same server / resource. Either user chooses manually or a search domain fills in per policy. Clients connect as designed.

So again we now have the possibility of an unreachable DA. Isn't that
what almost everybody is trying hardest to avoid?

> ** Operator puts ULA and GUA in global DNS. - External connectivity will fail to either GUA or IPv4. I assert this is a broken model and a misconfiguration and we should not try to policy around edge case misconfigurations.

I certainly agree it is a broken model and a misconfiguration, however
unreachable DAs do not only occur because a private/local network
address is put in global DNS.

They can also occur because of network faults, such as link or device
failures, or network misconfigurations.

That's actually the origin of Happy Eyeballs. It was created because
one IPv6 CPE implementation (Fritzbox) at the time didn't return
ICMPv6 Destination Unreachables to hosts at all when IPv6 wasn't
available or enabled on the CPE WAN link, yet was available on the LAN
(via LLAs by default, or ULA prefix being advertised as well). End
users encountered long transport layer connection delays in that case.

I was doing quite a lot of testing of IPv6 CPE back at that time,
other IPv6 CPE that did return IPv6 Dest Unreachables in this
situation did cause hosts to fall back to using IPv4 within less than
a few 100 milliseconds - I could detect the delay in a web browser,
however it wasn't a bad user experience with long, 10s of seconds
switchover delay. (AusNOG Presentation on it -
https://www.ausnog.net/sites/default/files/ausnog-05/presentations/ausnog-05-d02p02-mark-smith.pdf)

Hosts have to deal with transient failures of the network, meaning
packet loss, via timeouts and retransmissions. An unreachable DA in
global DNS is really just a form of transient packet loss until the
unreachable DA is removed from global DNS.

> ** Operator forces all users to use IPv4/IPv6 literals - all works as designed.
> ** Operator has only GUA on hosts and only ULA on servers / resources - works as designed host resolves AAAA and connects from GUA to ULA
>
> Obviously all of these problems are solved by using GUA everywhere, which for whatever reason may simply not be an option. Perhaps I am mis-understanding, but I don't believe we should be trying to solve DNS policy here.
>

"** Operator chooses to use split DNS - no problems. All works as
designed internal hosts use ULA, external connections use GUA as those
are the only options presented to them"

That's DNS policy to make DA/SA selection work. It is tightly coupling
how DNS is operated and configured to work with default IPv6 address
selection.

That hasn't been a requirement since RFC 3484 and then RFC 6724,
because of the "Well-behaved applications SHOULD NOT simply use the
first address returned from an API such as getaddrinfo() and then give
up if it fails ..." dealt with broken and unreachable DAs being
provided by DNS. Happy Eyeballs is a more advanced parallel
implementation of that RFC 3484/6724 advice.

Multicast DNS can return LLA, ULA and GUA addresses of another host on
the network (link). mDNS will need to be updated too to avoid
returning both a ULA and GUA DA if you want to follow that internal
DNS, ULA only; global DNS, GUA only model.

Regards,
Mark.

>>
>>
>> Regards,
>> Mark.
>>
>>
>>
>>> Telling operators to deprecate all ULA prefixes when a valid GUA is available and GUA->GUA is preferred over ULA->ULA does nothing to improve the situation.
>>>
>>> If I misunderstood, then please help me to understand what problem you're trying to solve with that proposed recommended practice.
>>> Kyle
>>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------