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

[Nick Buraglio <[e-mail]>]

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. This change is far more tactical 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
** Operator uses the same names *internally* for GUA and ULA. Source tries
w/ IPv6 ULA -> ULA first. All works.
** 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.
** 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.
** 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.


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