Hi, This behaviour is intended. As in, "working as designed". But we can argue if it’s correct or particularly useful. It’s for an isolated NAT64 instance, where all traffic you’d send to it is expected to be translated.
As a workaround you can add an addition check in nat64_not_translate() for a match with the expected translation prefix. Longer term I am thinking of doing a NAT44/NAT64 that supports sharing of IPv4 pool as well as a cleaner handling of matching on IPv6 traffic. Preferably using the new SASC infrastructure. This would be for a CPE / IPv6 mostly use case. If you’d like to contribute let me know. That would certainly be appreciated! Best regards, Ole ([email protected] <mailto:[email protected]>) > On 7 Nov 2025, at 10:25, mjoffre via lists.fd.io > <[email protected]> wrote: > > Hi VPP team, > I'm currently trying to setup a full IPv6 network, and while everything's > working fine by now, I'm trying to implement NAT64 to give a compatibility > layer for my services using VPP. > I don't clearly understand why, but it seems when you set an interface as > "in" it is interpreted as all the traffic within the interface will be NAT64 > translated, regardless of whether the destination matches the configured > NAT64 prefix. Even though I specify the prefix explicitly (e.g., > 64:ff9b::/96), it doesn't help - ALL IPv6 traffic gets translated. > Expected behavior: > Only IPv6 packets with destinations matching the configured NAT64 prefix > (e.g., 64:ff9b::192.0.2.1) should be translated to IPv4. Other IPv6 traffic > should pass through normally. > Actual behavior: > ALL IPv6 traffic on the interface is translated, extracting an IPv4 address > from the destination regardless of the prefix. > Code evidence: > I see there's the following code in nat64_in2out.c (lines 1080-1084): > if (nat64_not_translate (sw_if_index0, ip60->dst_address)) > { > next0 = NAT64_IN2OUT_NEXT_IP6_LOOKUP; > goto trace0; > } > This is the ONLY check before translation occurs, and it only verifies if the > destination is a local interface address. There's no verification that the > destination IPv6 address actually matches the configured NAT64 prefix. > Then the translation unconditionally calls (line 227): > nat64_extract_ip4 (&old_daddr.ip6, &new_daddr, fib_index); > This function (nat64_extract_ip4 in nat64.c lines 1324-1386) blindly extracts > 32 bits from the IPv6 address based solely on the prefix LENGTH, without ever > verifying that the prefix itself matches: > void > nat64_extract_ip4 (ip6_address_t * ip6, ip4_address_t * ip4, u32 > fib_index) > { > nat64_main_t *nm = &nat64_main; > nat64_prefix_t *p, *gp = 0; > u8 plen = 0; > vec_foreach (p, nm->pref64) > { > if (p->fib_index == fib_index) > { > plen = p->plen; // Only gets the LENGTH, not the prefix itself > break; > } > // ... > }; > // Extracts IPv4 based on length, no prefix matching > switch (plen) > { > case 96: > ip4->as_u32 = ip6->as_u32[3]; // Just takes last 32 bits > break; > // ... other cases > } > } > Impact: > With a /96 prefix configured, ANY IPv6 destination (e.g., 2001:db8::1.2.3.4) > will have its last 32 bits extracted as the IPv4 address (1.2.3.4), even > though the prefix is 2001:db8:: instead of 64:ff9b::. > Workaround attempt: > The only workaround I can see is to add a Loopback interface in my VRF, set > it as "in" for NAT64, and add an entry to route only the NAT64 prefix traffic > to that interface. I tried this approach but I wasn't able to make it works. > Question: > Is this the intended behavior? If so, how can I configure NAT64 to only > translate traffic matching the specific prefix while allowing other IPv6 > traffic to pass through normally? > If this is a bug, the fix would likely involve adding prefix matching logic > in the packet processing path before calling nat64_extract_ip4(). > Thank you for your help! > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#26494): https://lists.fd.io/g/vpp-dev/message/26494 Mute This Topic: https://lists.fd.io/mt/116167893/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
