[Snac] Re: Moving DNS64 (RFC6147) to Internet Standard

[[e-mail]]

Hi Ted,

Just out of curiosity, where is in current spec the MUST DNS64 you are referring to?

Thank you.

Cheers,
Med (without my AD Fez)

De : Ted Lemon <[e-mail]>
Envoyé : lundi 13 avril 2026 13:04
À : Esko Dijk <esko.dijk=[e-mail]>
Cc : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; [e-mail]
Objet : Re: [Snac] Moving DNS64 (RFC6147) to Internet Standard



It is perhaps worth noting that the normative requirements in the document do not match what is specified for Thread, which is a major exemplar of the SNAC spec, do not follow the current text in the SNAC spec. Thread decided that DNS64 synthesis should be done on-device. This makes sense because it's a greenfield environment, so there's no installed base of devices that can't do synthesis on their own, and importantly, doing synthesis is not burdensome.

So I actually question whether this is the right direction to go. At the very least, given that our one existing exemplar for SNAC doesn't behave this way, making this behavior a MUST in the SNAC document is a bit weird. But secondly, is this even the right approach to specify as a default behavior? What's the use case for this? I'm not saying this is necessarily wrong, but if we think it should be required for some SNAC configuration, we should be explicit about what that configuration is and why.

E.g., if it's the SNAC WiFi-to-WiFi use case, perhaps it makes sense for the same reason that NAT64 makes sense generally. But what end devices can't do synthesis on-host that are likely to show up on such a network? If we want to make this a normative requirement, we should be able to answer that question. Otherwise, it's certainly an interesting tool in the toolbox of the next exemplar of SNAC, but we aren't really qualified to say whether that use case actually requires it if we don't know what it is.


On 13 Apr 2026, at 12:34, Esko Dijk <esko.dijk=[e-mail]<mailto:esko.dijk=[e-mail]>> wrote:


Agree, propose to add both references in this PR: https://github.com/ietf-wg-snac/draft-ietf-snac-simple/pull/179

Esko


On 4/9/26 18:47, [e-mail]<mailto:[e-mail]> wrote:
Hi all,

Forwarding this message as SNAC is one "consumer" of DNS64.

BTW, draft-ietf-snac-simple does not have a normative reference to RFC6147, while it should be. Idem for RFC6146. That's an easy comment to address in the next iteration of simple-snac ;-)

Cheers,
Med

De : [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>
Envoyé : jeudi 9 avril 2026 18:19
À : IPv6 Operations <[e-mail]><mailto:[e-mail]>; dnsop <[e-mail]><mailto:[e-mail]>; Brian E Carpenter <[e-mail]><mailto:[e-mail]>
Objet : [v6ops] Moving DNS64 (RFC6147) to Internet Standard

Hi DNSOP/V6OPS,

V6OPS is in the process of progressing several widely deployed IPv6-related features into Internet Standard (e.g., [1]). There is an ongoing WGLC for NAT64 (RFC6146) to move it to IS. Although there is no strong dependency between NAT64 and DNS64 (RFC6147), DNS64 is usually deployed in networks that host NAT64.

Brian raised a question about the plan for RFC 6147 [2]. Given that DNS64 is also widely implemented and deployed and that there is only one minor erratum that does not impact interop [3], I think that we can proceed with a status change for RFC6147 and progress NAT64/DNS64 as a set this round as well.

Please share you thoughts on this plan by 23/04/2026.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/v6ops/x1UNhtW1qkMpBh_27a1G_4JctHU/

[2] https://mailarchive.ietf.org/arch/msg/v6ops/G35ha3lL_tK2hSWVATiTnPXLaKc/

[3] https://www.rfc-editor.org/errata/eid2975


____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.


--
Snac mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.