[v6ops] Re: I-D Action: draft-ietf-v6ops-nat64-wkp-1918-01.txt

[Jen Linkova <[e-mail]>]

Hi Med,

On Sat, Feb 28, 2026 at 6:18 PM <[e-mail]> wrote:
> However, I'm still concerned about the main reco as we are reverting the default behavior to accommodate CLAT constraints, which is not great.
>
> No need to reiterate that I fully agree with having a relax clause, but let's step back a bit and re-examine what we have with a focus on CLAT:

I'd disagree that we need to focus on CLAT specifically.
CLAT is a band aid solution, and ideally applications shouldn't be
using it at all - the purpose of the CLAT is to allow legacy
applications to work (and also cover corner cases of raw socket usage,
like 'ping 8.8.8.8').
The problem which concerns me can arise with or w/o CLAT.

I do not think we want to solve a CLAT problem separately. We should
solve it for all translation cases once and for all.

> CURRENT (RFC 6052)
>    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.
>
> The translation here is obviously for IPv6 to IPv4 address translation.

To be honest I'd expect that IPv6 -> IPv4 and IPv4 -> IPv6 translation
rules to be consistent.
So if the algorithm allows (or prohibits) to translate a given IPv6
packet to IPv4, then the return packet shall be treated the same way.

Also, if you look at the previous sentence, it's more generic, and
doesn't specify the direction:
"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]."

>This text does not prevent a CLAT to build/forward an outgoing packet to an IPv4-only node when WKP is in use for the PLAT side.
>
> Unless I'm mistaken, you are concerned that the above text implies that incoming IPv6 packets with a source IPv6 address will be dropped if WKP is used. Translating the destination address is not an issue as the local node prefix is used for that one.
>
> You would like a guidance that says "always translate the source address matching WKP/non-global IPv4 unless configured otherwise". Right?

No, I want the translation to work in both directions. 6052 is
applicable to both stateless (CLAT, SIIT) and stateful (stateful NAT64
PLAT) cases.
>
> For the PLAT side, what I'd like we maintain is "always drop when the destination address matches WKP/non-global IPv4 unless configured otherwise".
> If my understanding is correct, can we consider a wording among these lines?

Hold on. I'm afraid I've failed to explain the scenario. Let me try again ;)

IPv6-ony host (2001:db8::2, clat address
2001:db8::c1a1)----PLAT(NAT64, pref=64:ff9b::, NAT pool
203.0.113.1)------dual-stack network

The host is trying to communicate with 10.0.0.1 located in the
dual-stack network.

1a. The ipv6-aware application sends a packet src=2001:db8::2,
dst=64:ff9b::10.0.01
1b. Ipv4-only application sends a packet via CLAT. CLAT translates it
to a packet src=2001:db8::c1a1,  dst=64:ff9b::10.0.01
(I still read 6052 as 'CLAT must drop those packets, but let's assume
your interpretation that "MUST drop" is only for 6->4 direction)

2. The packet arrives at the PLAT. I - as the network administrator -
wants the PLAT to translate those packets (src=2001:db8::/64,
dst=64:ff9b::10.0.0.1) to IPv4 packets src=203.0.113.1, dst=10.0.0.1

RFC6052 clearly prohibits that. So instead of "MUST drop" we are
saying "MUST translate unless configured otherwise" AND allow that
configuration to be a default one.

Now, we also need to allow the return traffic to be translated.
So PLAT must be able to translate packets src=10.0.0.1 dst=203.0.113.1
to IPV6 ones with dst=2001:db8::/64, src=64:ff9b::10.0.0.1
In case of 1a (native IPv6, dst=2001:db8::1) no more translation. In
case of CLAT (dst=2001:db8::c1a1, src=64:ff9b::10.0.0.1) we need to
ensure 6052 allows translation.

So, to sum it up, we have the following cases which are currently
prohibited by RFC6052:
1. IPv4-> IPv6:
    a) dst = 10.0.0.1 -> dst = 64:ff9::10.0.0.1 (outgoing packet on
the CLAT side)
    b) src = 10.0.0.1 -> src = 64:ff9b::10.0.0.1 (return packet
received by PLAT, destination either CLAT or native traffic)
2. IPv6 -> IPv4
   a) dst = 64:ff9::10.0.0.1 -> dst = 10.0.0.1 (outgoing packet on the
 PLAT, sent either by CLAT or a native application )
   b) src  = 64:ff9b::10.0.0.1 -> src = 10.0.0.1 (return packet on the
CLAT side)

We need to allow *all* those cases to work.

> > -----Message d'origine-----
> > De : [e-mail] <[e-mail]>
> > Envoyé : vendredi 27 février 2026 20:12
> > À : [e-mail]
> > Cc : [e-mail]
> > Objet : [v6ops] I-D Action: draft-ietf-v6ops-nat64-wkp-1918-01.txt
> >
> >
> > Internet-Draft draft-ietf-v6ops-nat64-wkp-1918-01.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-01.txt
> >    Pages:   8
> >    Dates:   2026-02-27
> >
> > 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 proposed
> > change
> >    enables IPv6-only nodes to reach IPv4-only services with non-
> > global
> >    addresses by leveraging the Well-Known Prefix.
> >
> > 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%7C0646540100
> > f743772f4108de76344377%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%
> > 7C639078164008673578%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd
> > WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%
> > 3D%3D%7C0%7C%7C%7C&sdata=xJwLcNvzcQ41L22iv3duRU%2FXeghqifokVy8d3ry
> > q1rk%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-
> > 01.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C0646540100
> > f743772f4108de76344377%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%
> > 7C639078164008693064%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd
> > WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%
> > 3D%3D%7C0%7C%7C%7C&sdata=jXDkH4izcyQvjoClBYLO9NB5hRcHftP1w5H1tbD8%
> > 2Fgw%3D&reserved=0
> >
> > A diff from the previous version is available at:
> > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > author-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-v6ops-nat64-
> > wkp-1918-
> > 01&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C0646540100f7437
> > 72f4108de76344377%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639
> > 078164008703722%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIl
> > YiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D
> > %7C0%7C%7C%7C&sdata=6SlSrQqaOcgZKldF9faGX8KwVy%2FD37yNC2xPvEFOyfw%
> > 3D&reserved=0
> >
> > Internet-Drafts are also available by rsync at:
> > rsync.ietf.org::internet-drafts
> >
> >
> > _______________________________________________
> > v6ops mailing list -- [e-mail]
> > To unsubscribe send an email to [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.
>
> _______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]



-- 
Cheers, Jen Linkova