Subject: [v6ops] Re: I-D Action: draft-ietf-v6ops-nat64-wkp-1918-00.txt
From: [email-masked]
To: "[email-masked]" <[email-masked]>
Date: Tue, 25 Nov 2025 08:09:33 +0000
List-Id: v6ops discussion list <v6ops.ietf.org>

Hi all, 

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
========

# 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'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.

(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. 

(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.

# 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.

# 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

Hope this helps.

Cheers,
Med (no AD fez)

> -----Message d'origine-----
> De : [email-masked] <[email-masked]>
> Envoyé : mardi 25 novembre 2025 01:05
> À : [email-masked]
> Cc : [email-masked]
> 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 -- [email-masked] To unsubscribe
> send an email to [email-masked]
____________________________________________________________________________________________________________
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.