Commentary in-line, minor nits on GitHub incoming.
Thanks,
Tommy
On 8/1/25 20:03, Nick Buraglio wrote:
[no hat]
Thank you for writing this document. It is well written,
comprehensive, and solves a problem.
Along with what Phillip wrote, which I agree with, here are my notes
from reading the latest version.
Section 4:
|With the final exhaustion of IPv4 pools in RIRs, e.g., [RIPEV4], and
the progressing deployment of IPv6, there no longer is a "preferred"
IP version. |
The use of the term "preferred" could be confusing here and I would
argue that defining it is very context specific. Suggest quantifying
"preferred" to add some context or re-wording that sentence. While
perhaps a somewhat edge case, I could see someone reading that and
applying the context of source address selection and being confused by
behavior. You clarify this a bit in section 4.3, but perhaps it could
be clarified higher in the doc?
Section 4.2
|If a recursive DNS resolver runs in a network that uses XLAT
[RFC6877], and the recursive DNS resolver is aware of the used PREF64
[RFC6146], it SHOULD synthesize mapped IPv6 addresses for remote |
Suggest re-wording this to something like
|If a recursive DNS resolver operates in a network that uses
XLAT [RFC6877], and the recursive DNS resolver is aware of the
PREF64 [RFC6146] in use in its administrative domain, .... |
Section 4.3
|(DHCPv4, DHCPv6, SLAAC). |
Should these be defined, referenced, or at least explained? PREF64 and
XLAT RFC are referenced in section 4.2.
Always a fan of definition references, especially as I was reminded of
this by the RFC Editor yesterday for a different draft.
On Tue, Jul 29, 2025 at 7:51 AM Tobias Fiebig
<[email protected]> wrote:
Moin,
> Section 3.2:
> - The draft suggests to use an MSS of 1240 bytes for IPv4 and 1220
> bytes
> for IPv6 to avoid MTU blackholes on TCP, but in the next
paragraph
> also mentions the problems that may arise due to the use of
NAT64.
> Why not always use an MSS of 1220 and be safe?
> -> Same argument also applies to Section 4.1
This kind of makes sense. I will change it in the working copy for
now.
However, it would be nice to hear some more opinions on this from the
list.
I support this change also.
> Section 4.1:
> - While there still are people using transition technology like
> Teredo,
> 6to4 or ISATAP, I would prefer having no IPv6 authoritative DNS
> over one realized using any of these. Especially ISATAP allows to
> build
> interesting circular dependencies.
> Should the draft recommend only using native IPv6 for
authoritative
> DNS servers?
> - Does it make sense tor recommend the same for IPv4?
I would pick this up for only v6 for now; v4 is messy enough
already...
I put in: "Authoritative DNS servers <bcp14>SHOULD NOT</bcp14> use
addresses from IPv6 transition technologies to be reachable." for now.
I agree with the spirit of the change but find this sentence a little
confusing. Noting I tend to prefer verbosity, I'd suggest but not insist
on something like: "Authoritative DNS servers <bcp14>SHOULD</bcp14> use
native IPv6 addresses instead of IPv6 addresses synthesized using IPv6
transition technologies to avoid reachability issues."
> Section 4.3:
> - The recommendation about preferring IPv6 recursive resolvers
> does not match the implemented base, which usually prefers
> resolvers
> learned over DHCP over resolvers learned through SLAAC.
Yes, this is very much an implementation question; Also, e.g., if a v4
and v6 resolver have been learned via DHCPv4 and DHCPv6 respectively
etc.
I would argue that preferring non-synthesized v6 over synthesized v6
(only of known to the client!) is still a reasonable recommendation
going forward.
> - The recommendations for the NAT64/PREF64/IPv6-mostly case seem
> reasonable,
> but could use some untangling between PREF64, IPv6-mostly NAT64, …
> I would suggest talking about NAT64 connectivity discovered
through
> PREF64 or RFC7050.
I just went over the text and aligned this a bit more, also using more
similar text for the stub/full resolver cases. Please take a look in
the git repo.
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]
_______________________________________________
DNSOP mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
