Re: [IPv6] Second Working Group Last Call for <draft-ietf-6man-rfc6724-update>

[Mark Smith <[e-mail]>]

On Fri, 12 Apr 2024, 00:45 Kyle Rose, <krose=[e-mail]>
wrote:

> On Thu, Apr 11, 2024 at 10:31 AM Ted Lemon <[e-mail]> wrote:
>
>> I don't disagree with you about this. It doesn't match my mental model
>> either. However, this just isn't relevant to this discussion—neither you
>> nor I have control of all DNS zones on the Internet, and that's probably a
>> good thing. So if we want to see better behavior when zone operators
>> violate our expectations, the only knob we have to turn is to improve host
>> implementations.
>>
>
> We're arguing about this because I'm opposed to any change that encourages
> operators to deploy what you and I agree is a misconfiguration.
>
> Right now with glibc, and under the proposed precedences, publishing ULA
> to global DNS would cause visible problems that service providers would
> then have an incentive to fix. Mandating known-local not only reduces this
> incentive, it actually encourages broader intentional deployment of this
> misconfiguration. That is the outcome I want to avoid. There is a long tail
> of existing devices attached to the network that will not ever implement
> known-local, and they will become less functional over time if the
> incentive to fix this is reduced or removed.
>

Trouble is, without known-local, the default of GUA over ULA strongly
discourages ULA deployment in parallel with GUAs, unless you burden a human
with performing the first step of each and every DA selection via giving
all nodes internal and external DNS names.

That's not an acceptable solution for non-technical users, and not for some
technical ones like me who don't want the mental load of deciding each and
every time I connect to something whether I want the internal or external
address of a node.

Assume the user is internal more often than external, so assume ULA works
more often than it won't, so prefer ULA over GUA (similar to how
site-locals were preferred over GUAs).

If you're worried about long connection establishment timeouts for
unreachable DAs, well that is the actual problem, and the actual solution
is a select(), poll() or similar call to reduce the duration of the
establishment delay.

Clients will always have to be able to cope with DNS returning unreachable
DAs, because DNS is not synchronised with the network's IP address
reachability, which can change based on link or node failure, and where the
client is currently attached to the network.

Regards,
Mark.


> BUT... I mostly want something published with the new precedences. I
> already said at the very top of the thread that I'm in favor of publishing
> the document. If I'm in the rough on this known-local issue, so be it. It's
> still a good document and will improve ULA and so encourage more IPv6
> adoption within enterprises, despite my reservations about known-local.
>
> Clear?
>
> Kyle
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>