Hi Med,

Thank you for your comments, and I'm sorry for not responding earlier.

On Tue, Nov 25, 2025 at 7:10 PM <mohamed.boucadair@orange.com> wrote:
> Please find below some comments, as contributor:
>
> # We may remember that the restriction was part of the deployment guidelines, not main normative part to the algo
>
> ==RFC 6052:
> 3.  Deployment Guidelines   <=========================
>
> 3.1.  Restrictions on the Use of the Well-Known Prefix
> ========

I’m not sure I understand the proposed action here.. The restriction
uses the normative MUST NOT and dictates the behavior we believe is
undesirable in the modern deployment scenarios. Do you have a proposed
text, or is this OK as is?

> # Simplify the problem statement
>
> I think that the problem statement can be simplified to basically ask for the ability of an operator to control whether a given NAT64 instance can serve internal services reachable with private IPv4 addresses. Whether the same or distinct NAT64 instance is used is definitely deployment-specific.

I think it would make a great abstract. For the Intro/problem
statement I think it’s important to explain what use cases are broken
with the current state of affairs and, more importantly, why the
approach proposed in RFC6052 doesn’t fully solve the issue.

>
> I'm afraid the current text in the draft over-justify the need with some weak arguments IMO. See examples below.
>
> (1) Mention of CLAT is not justified here as source address (with private IPv4) synthesis is done with the local prefix, not NAT64 one
>
> CURRENT:
>    However, this requirement introduces significant
>    operational challenges for systems that do not rely on DNS64 and
>    instead use local synthesis such as CLAT (Customer-side Translator,
>    [RFC6877]), or similar approaches.

 It’s not about the source, but about the destination addresses in
this case.  For outgoing packets, CLAT synthesises the destination
IPv6 address using the NAT64 prefix. For example, the scenario when a
CLAT-enabled IPv6-only host needs to communicate to an internal server
which has a private IPv4 address.


> (2) Private IPv4 addresses and Public DNS64
>
> CURRENT:
>    Enterprise and other closed networks often require IPv6-only nodes to
>    communicate with both internal (e.g., using RFC1918 addresses) and
>    external (Internet) IPv4-only destinations.  The restriction in
>    Section 3.1 of RFC6052 prevents such networks from utilizing the WKP
>    and, consequently, from relying on public DNS64 servers which utilize
>    the WKP in order to maximize compatibility.
>
> I don't quite understand the deployment model here: this is mixing reaching internal services (not to be leaked outside) and the use of a public infrastructure.

Agree, this needs to be clarified. The case here is when the local
zones are served by an enterprise DNS server, while everything else is
forwarded to a public DNS. We will add more text to address this.

>
> (3) Seems like an incomplete analysis:
>
> CURRENT:
>    According to Section 3 of [RFC7050], a node must use all learned
>    prefixes when performing local IPv6 address synthesis.  Consequently,
>    if a node discovers both the WKP and the NSP, it will use both
>    prefixes to represent global IPv4 addresses.  This duplication
>    significantly complicates security policies, troubleshooting, and
>    other operational aspects of the network.
>
> I think the more relevant section in rfc7050#section-5.1, which
>
>                       NAT64 "A" ----- IPv4-only servers in a data center
>                      /
>    IPv6-only node---<
>                      \
>                       NAT64 "B" ----- IPv4 Internet
>
>                  Figure 2: NAT64s with IPv4 Address Ranges
>
>                       NAT64 "A" ----- IPv4-only servers in a data center
>                      /
>    IPv6-only host---router
>                      \
>                        NAT64 "B" ----- IPv4 Internet
>
>                   Figure 3: NAT64s with Assisting Router
>
> Which requires some hack because of the 7050 approach.
>
> Things would be straightforward of the destination-based prefix was supported.

Since RFC7050 requires all discovered prefixes to be used (and RFC8781
inherited it), having per-destination NAT64 prefix requires a lot of
changes on endpoints and APIs. Additionally, it would require
deprecating RFC8781 and developing a new RA option. I’m not convinced
it’s worth the effort and the risk. This draft proposes a much easier
way forward.


> # A proposal to relax the constraint to accommodate specific deployments while keeping backward compatibility:
>
> CURRENT:
>    The Well-Known Prefix MAY be used to represent non-global IPv4
>    addresses, such as those defined in [RFC1918] or listed in Section 3
>    of [RFC5735].  By default, address translators MUST translate packets
>    in which an address is composed of the Well-Known Prefix and a non-
>    global IPv4 address; they MUST NOT drop these packets unless
>    configured to do so.
>
> NEW:
>    By default, the Well-Known Prefix MUST NOT be used to represent non-global IPv4
>    addresses, such as those defined in [RFC1918] or listed in Section 3
>    of [RFC5735]. In such case, address translators MUST NOT translate packets in
>    which an address is composed of the Well-Known Prefix and a non-
>    global IPv4 address; they MUST drop these packets. Translators SHOULD
>    provide a configuration parameter to enable representing non-global IPv4
>    addresses using WKP.

To be honest I do not think it’s a good idea. Your suggestion makes
sense for PLATs but not for CLATs (as the vast majority of them are
not managed).

There are two things here:

1. What translators are allowed to do and what they are not. This
should be unified standardized behaviour.
2. What is the default behaviour for managed devices. This might - and
should be - different for managed PLATs and unmanaged CLAT devices.

This document is mostly focused on #1, while your comment is about #2.

How about the following text:

The Well-Known Prefix MAY be used to represent non-global IPv4
addresses, such as those defined in [RFC1918] or listed in Section 3
of [RFC5735].  Address translators MUST translate packets in which an
address is composed of the Well-Known Prefix and a non- global IPv4
address unless configured otherwise.
Implementations MAY choose not to translate such packets by default.
Such implementation SHOULD have a configuration knob to enable
translation for such packets.


> # Need to call out operational implications of relaxing the restriction
>
> There are cautions that we need to call out, such as:
>
> * risk of leak of internal information outside a domain,
> * risk of forwarding errors with overlapping ranges
> * Need for policies when the same instance is used for both internal and external realms

Agree, text will be added in the next revision.

> > -----Message d'origine-----
> > De : internet-drafts@ietf.org <internet-drafts@ietf.org>
> > Envoyé : mardi 25 novembre 2025 01:05
> > À : i-d-announce@ietf.org
> > Cc : v6ops@ietf.org
> > Objet : I-D Action: draft-ietf-v6ops-nat64-wkp-1918-00.txt
> >
> >
> > Internet-Draft draft-ietf-v6ops-nat64-wkp-1918-00.txt is now
> > available. It is a work item of the IPv6 Operations (V6OPS) WG of
> > the IETF.
> >
> >    Title:   NAT64 WKP
> >    Authors: Warren Kumari
> >             Jen Linkova
> >    Name:    draft-ietf-v6ops-nat64-wkp-1918-00.txt
> >    Pages:   7
> >    Dates:   2025-11-24
> >
> > Abstract:
> >
> >    This document removes the requirement introduced in Section 3.1
> > of
> >    RFC6052 that the NAT64 Well-Known Prefix 64:FF9B::/96 MUST NOT
> > be
> >    used to represent non-global IPv4 addresses, such as those
> > defined in
> >    [RFC1918] or listed in Section 3 of [RFC5735].
> >
> > The IETF datatracker status page for this Internet-Draft is:
> > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > datatracker.ietf.org%2Fdoc%2Fdraft-ietf-v6ops-nat64-wkp-
> > 1918%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C6e5bfc6df7
> > 22489f1c3008de2bb677c3%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%
> > 7C638996259852248150%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd
> > WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%
> > 3D%3D%7C0%7C%7C%7C&sdata=PDUVs3RVt0G8ZCJ5t1mMoyr7AoPaGk005F0GB%2Be
> > LzOw%3D&reserved=0
> >
> > There is also an HTML version available at:
> > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > www.ietf.org%2Farchive%2Fid%2Fdraft-ietf-v6ops-nat64-wkp-1918-
> > 00.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C6e5bfc6df7
> > 22489f1c3008de2bb677c3%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%
> > 7C638996259852278079%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd
> > WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%
> > 3D%3D%7C0%7C%7C%7C&sdata=GrW%2BM4uLXqpzm8GZhkPKtMREmFvrY3GsFofbttJ
> > Bz6g%3D&reserved=0
> >
> > Internet-Drafts are also available by rsync at:
> > rsync.ietf.org::internet-drafts
> >
> >
> > _______________________________________________
> > I-D-Announce mailing list -- i-d-announce@ietf.org To unsubscribe
> > send an email to i-d-announce-leave@ietf.org
> ____________________________________________________________________________________________________________
> 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.
>
> _______________________________________________
> v6ops mailing list -- v6ops@ietf.org
> To unsubscribe send an email to v6ops-leave@ietf.org



-- 
Cheers, Jen Linkova