Moin,
On Thu, 2025-11-20 at 17:54 +0100, Marco Davids (IETF) wrote:
> I generally support this document, with two concerns:
Thanks!
> Section 3.2 mentions "Broken IPv6 Connectivity at the Resolver". Why
> does this paragraph has a focus on IPv6 while dismissing possible
> IPv4 issues?
The notion in the WG and wider community over the history of the
document so far was more along the lines of 'IPv4 has no issue, IPv6 is
the issue' (not my opinion); As such, the text focuses on IPv6.
At the mic at 124, Lorenzo elaborated on IPv4 issues experienced in
deployments, making DNS over IPv4 difficult. I would be happy to add
more context there (and believe it would be useful).
However, I would like to hear some more opinions from the list on this
point given earlier discussions.
> With regard to section 4.1 "IPv6 adoption" - I would change the
> SHOULD into a MUST in: "authoritative DNS servers SHOULD use native
> IPv6 addresses instead of IPv6 addresses synthesized"
I personally disagree here; I certainly see the reasoning behind this
suggestion, and agree that in an 'ideal world', this <bcp14>MUST
</bcp14> not happen.
However, I also think that <bcp14>SHOULD</bcp14> is sufficiently strong
here, and a <bcp14>MUST</bcp14> would possibly prevent use-cases that
might be reasonable in the overall context (not desirable, but for
operational conditions reasonable):
- Use of NAT64 as inbound transition technology:
- Esp. smaller setups, where there is no native IPv6
available,
and, instead, an (possibly offsite) NAT64 is configured
- Enterprise setups where the change process of rolling out
native IPv6 has been dragging forever, and it is easier to
do NAT64 on the (stateful anyway) ingress firewall to the
DMZ
is the easier solution to get through a Change Mgmt. Board
- Cloud setups / Containers
- IIRC several larger cloud providers do some form of NAT64/66
to enable IPv6 on hosts
- Especially for OpenStack i heard that this can be 'messy'
- I have no idea how this would reflect on
$all_those_container
-things; There is also an awful lot of translation going on
- General testability:
- As an operator, even though forbidden, nobody prevents me
from using 2001:db8:fae5:80ac:4a68:4aff:fe91:4407 to NAT64
inbound packets to 198.51.100.23 instead of just going for
2001:db8:6464::c633:6417 (PREF64=2001:db8:6464::/96).
- Similar, I could be using 2001:db8:6464::c633:6417 without
any NAT64 in the way. Just native on the box.
- If we make this a <bcp14>MUST</bcp14>, I would argue that
registries would have to check for it. Or, at least, some
would decide to do so. Given the above, I'd argue that that
can only end in a 'huge mess'; But you are likely in a
better
position to comment on that, than me.
That being said, if there is a strong lean towards a <bcp14>MUST
</bcp14> on the ML, I would not make this a hill i'd die on.
Thoughts?
With best regards,
Tobias
--
Dr.-Ing. Tobias Fiebig
T +31 616 80 98 99
M [email protected]
Pronouns: he/him/his
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
