[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. On Tue, Jul 29, 2025 at 7:51 AM Tobias Fiebig <tobias= [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. > > > > 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. > > > 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 to [email protected]
