[art] Re: [v6ops] Re: draft-ietf-v6ops-rfc6146-bis-07 ietf last call Artart review

[John R Levine <[e-mail]>]

On Tue, 30 Jun 2026, Brian E Carpenter wrote:
>> Regarding the inclusion of DNS64/DNSSEC in the security section, I’m not 
>> convinced this is good, as it is a DNS64 issue and in some situations NAT64 
>> can be used without DNS64 (with a penalty in overall performance, extra 
>> delays, etc.). That said, I’m happy to include a “conditional” paragraph 
>> referring to that if you agree, something in the line of “Note that if 
>> DNS64 is used in some cases DNSSEC validation may fail. This is not a NAT64 
>> issues, but a DNS64 one and it is discussed in RFC6147 section ….”.
>
> Or just say "If DNS64 is used, also see the Security Considerations of 
> [RFC6147]."

That would be OK but I would prefer to at least give a hint that the 
problem is with DNSSEC.

R's,
John

>>> El 28 jun 2026, a las 20:51, John Levine via Datatracker 
>>> <[e-mail]> escribió:
>>> 
>>> Document: draft-ietf-v6ops-rfc6146-bis
>>> Title: Stateful NAT64: Network Address and Protocol Translation from IPv6 
>>> Clients to IPv4 Servers
>>> Reviewer: John Levine
>>> Review result: Ready with Issues
>>> 
>>> ARTART last call review of draft-ietf-v6ops-rfc6146-bis
>>> 
>>> Reviewer: John Levine
>>> 
>>> Overall: Ready with Issues
>>> 
>>> Figure 1 is scrambled. It looks like it was intended to be two large
>>> boxes representing IPv6 and IPv4 networks connected by smaller boxes
>>> for DNS64 and NAT64. But the right edge of the IPv6 box runs through
>>> the middle of the small boxes. There is a vertical line under the k in
>>> "IPv6 network" that might have been intended to be the right edge of
>>> the IPv6 box but isn't. This figure is unchanged from RFC 6146 where
>>> it was equally scrambled, which makes me wonder when was the last time
>>> somone really looked at it.
>>> 
>>> Both this figure and Figure 2, which appears correct but is complex
>>> and confusing, could benefit from being redrawn as real figures using
>>> SVG tools.
>>> 
>>> The security considerations should say something about DNS64 and
>>> DNSSEC, since the synthesized AAAA records are not and cannot be
>>> signed. There are workarounds but none of them are great. RFC 6147
>>> Section 3 discusses this issue so it could refer there.
>>> 
>>> I have looked at Tony Li's review and while I am not as sceptical of
>>> IPv6 as he is, I generally agree with the changes he proposed.
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> art mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>> 
>> 
>> **********************************************
>> IPv4 is over
>> Are you ready for the new Internet ?
>> http://www.theipv6company.com
>> The IPv6 Company
>> 
>> This electronic message contains information which may be privileged or 
>> confidential. The information is intended to be for the exclusive use of 
>> the individual(s) named above and further non-explicilty authorized 
>> disclosure, copying, distribution or use of the contents of this 
>> information, even if partially, including attached files, is strictly 
>> prohibited and will be considered a criminal offense. If you are not the 
>> intended recipient be aware that any disclosure, copying, distribution or 
>> use of the contents of this information, even if partially, including 
>> attached files, is strictly prohibited, will be considered a criminal 
>> offense, so you must reply to the original sender to inform about this 
>> communication and delete it.
>> 
>> 
>> 
>> _______________________________________________
>> v6ops mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>

Regards,
John Levine, [e-mail], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly