Hey guys,

I've been working closely with @jack9603301 on testing ndp-proxy (ndppd) and his stateless nat66 code. We've tested SNAT prefix translation and DNAT address translation.

Here's some update:

• With NFT SNAT prefix translation, the address is not a 1:1 mapping. For example, if we have source prefix 2001:db8:1::/64 and translation prefix of 2001:db8:2::/64, the source address 2001:db8:1::1 will not translate to 2001:db8::2::1. The nftables translation calculates a new address which prevents the 1:1 host address mapping.
• SNAT Prefix translation is working
• DNAT address translation is working

In the case of building a DNAT rule, the operator needs to figure out what nftables has assigned the new snat host address. I do not know how nftables determines this, so without first enabling an SNAT rule, and then getting the public IP address, and then building the DNAT ruleset with this calculated host address number.

set nat66 source rule 1 outbound-interface 'eth3'
set nat66 source rule 1 source prefix 'fc00:dead:beef::/64'
set nat66 source rule 1 translation prefix '2001:xxxx:16:24::/64'

set nat66 destination rule 1 destination address '2001:xxxx:16:24::2ae8:926b'
set nat66 destination rule 1 inbound-interface 'eth3'
set nat66 destination rule 1 translation address 'fc00:dead:beef::25'

To get this to actually work, ndppd deb package is installed with the following config file built manually

ndppd.conf:

route-ttl 30000

proxy eth3 {
        router yes
        timeout 500
        ttl 30000
        rule 2001:xxxx:16:24::/64 {
                static
        }
}

proxy eth4 {
        router yes
        timeout 500
        ttl 30000
        rule fc00:dead:beef::/64  {
                static
        }
}

The next steps need input from devs - should ndppd be operationally hooked into the nat66 ruleset? That is, with the data we have from nat66 rules, should we just have ndppd config managed automatically? Or - provide config options for nat66 AND separate ndp arp proxy parameters? Alone, stateless nat66 cannot work in all (most?) network topologies. I think there may be use cases where ndp arp proxy is needed, but nat66 is not.

With NFT SNAT prefix translation, the address is not a 1:1 mapping. For example, if we have source prefix 2001:db8:1::/64 and translation prefix of 2001:db8:2::/64, the source address 2001:db8:1::1 will not translate to 2001:db8::2::1. The nftables translation calculates a new address which prevents the 1:1 host address mapping.

I'm thinking about a problem. In fact, now nat66 may have met the one-to-one unique mapping, but the host segment of its mapped address after conversion is not equal to the host segment of the address before conversion

The example of H3C shows that the conversion is also asymmetric. I don't know the effect of other devices, but it seems that this is normal

As long as the address is unique, it should meet the design requirements

I must disagree, prefix translation means only the prefix is translated and the interface identifier keeps the same. Meaning fc00::1111:2222:3333:4444/64 should be translated to 2001:db8::1111:2222:3333:4444/64.

Well, at present, the nat66 prefix conversion of nftables has not found a way to not change the interface identifier. Maybe other people in the community can provide some suggestions?

I think about it carefully. What if the user inputs two unequal prefixes? For example, the prefix 56 is converted to the prefix 64, or vice versa

Do other community members test the behavior of other devices?

prefix translation should only be done on equal sized prefixes. This can be easily checked in verify() stage.

nftables nat66 seems to be the best solution that can be done now, I am still exploring a better implementation, do you have any suggestions?

We are not forced to nftables and still use iptables6 if its not supported properly.

Thank you for your suggestion. I am considering how to implement peer-to-peer translation without modifying the interface identifier. According to some information on the Internet, the support of ipv6 nat is divided into peer address and non-equivalent address. The standard https://tools.ietf.org/html/rfc6296 display does not indicate the interface identifier. The symbol cannot be modified, but only stipulates that the address mapping conforms to the one-dimensional linear equation relationship (that is, an address mapping is unique.

Searching for related solutions is continuing

@c-po The map66 solution last released on July 25th, 2015 does not seem to have been explored. It can work with iptables. I am not sure if it has stopped maintenance. I am considering whether to consider it, but it means that it needs to be compiled, installed and generated deb package , Otherwise vyos cannot install it

I don’t really want to use an old or even obsolete solution, which means we can’t receive its updates to ensure normal maintenance, but if possible, we can maintain it ourselves

https://sourceforge.net/projects/map66/

Hi, everyone, I have been looking for a way to handle the 1-to-1 address prefix symmetry mapping. I contacted the IRC channel of the official community. According to the official information, it seems to be resolved in the 5.8 kernel version, otherwise the patch needs to be backported To 4.19.

The official community tells me that I only need to change snat to into snat prefix to, but need to operate on the kernel above 5.8,otherwise the patch needs to be backported To 4.19.

patch:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3ff7ddb

In linux kernel version 5.8 and above, you can start symmetric translation of ipv6 address prefix by changing snat to to snat prefix to in the policy (without changing the interface identifier), but this function cannot be used before vyos upgrade 5.9 , This patch is not a back-portable patch, so this feature cannot be used in 4.19. There are now 3 solutions:

a) Wait for the kernel to be upgraded to 5.9 merge, and only support symmetric mapping

b) Add compatibility switch to switch between two mapping methods

c) Waiting for the kernel to be upgraded to 5.9 merge, but support 2 different mapping modes at the same time

ps: The function still depends on the NDP proxy

Also come back to this question?

In T2518#76031, @JessterSB wrote:

The next steps need input from devs - should ndppd be operationally hooked into the nat66 ruleset? That is, with the data we have from nat66 rules, should we just have ndppd config managed automatically? Or - provide config options for nat66 AND separate ndp arp proxy parameters? Alone, stateless nat66 cannot work in all (most?) network topologies. I think there may be use cases where ndp arp proxy is needed, but nat66 is not.

NDP Proxy has been implemented in T2898. For nat66 to work normally, proxy-ndp must be operated in static mode.

When the merger of nat66 and proxy-ndp is completed, consider adding the function of nat66 auto-proxy-ndp to realize automatic configuration of proxy-ndp

PR:https://github.com/vyos/vyos-1x/pull/520

Note that because the test requirements are not met for the time being (vyos does not use the linux kernel with a kernel version of 5.8+ for the time being), it cannot be tested well. The merged code has not undergone any testing. Please upgrade the vyos linux kernel to 5.8+ , Let me know that I can perform related tests, and merge after testing

PR: https://github.com/vyos/vyos-1x/pull/520

Since the current branch uses the kernel Linux 5.10+, I began to pay attention to the implementation of NPT again. At present, I have completed the following features:

• SNPT 1:1 mapping
• DNPT single address mapping
• DNPT 1:1 mapping

I have finished the test of nat66 in GNS lab

Test case topology:

SNPT test case:

GNS Router configuration:

set interfaces ethernet eth0 address 'fc00::1/64'
set interfaces ethernet eth1 address 'fc01::1/64'
set nat66 source rule 1 outbound-interface 'eth0'
set nat66 source rule 1 source prefix 'fc01::/64'
set nat66 source rule 1 translation prefix 'fc00::/64'
set service router-advert interface eth0 prefix ::/0
set service router-advert interface eth1 prefix ::/0

SNPT test results (packet capture at router output port):

DNPT test case:

GNS Router configuration:

set interfaces ethernet eth0 address 'fc00::1/64'
set interfaces ethernet eth1 address 'fc01::1/64'
set nat66 destination rule 1 destination address 'fc00::/64'
set nat66 destination rule 1 inbound-interface 'eth0'
set nat66 destination rule 1 translation address 'fc01::/64'
set service router-advert interface eth0 prefix ::/0
set service router-advert interface eth1 prefix ::/0

DNPT test results (fc00::/64 requests SSH):

PR:

• https://github.com/vyos/vyos-1x/pull/762
• https://github.com/vyos/vyatta-cfg-system/pull/139

PR: https://github.com/vyos/vyos-1x/pull/771

Is there a way to get this to work with a dynamically assigned /64 PD from my ISP?

set nat66 destination rule 10 inbound-interface 'eth1'
set nat66 destination rule 10 translation address 'fc00::/64'

set nat66 source rule 10 outbound-interface 'eth1'
set nat66 source rule 10 source prefix 'fc00::/64'
set nat66 source rule 10 translation address '2603:xxxx:xxxx:6f01::/64'

but 2603:xxxx:xxxx:6f01::/64 is assigned dynamically through eth1

@ajgnet If you have a way to limit the dynamic prefix to a known prefix, then using 1:1 NAT66 prefix translation should work (only the host segment is dynamic)

In T2518#127884, @jack9603301 wrote:

@ajgnet If you have a way to limit the dynamic prefix to a known prefix, then using 1:1 NAT66 prefix translation should work (only the host segment is dynamic)

Yes, would be great to fully support dynamic prefix when the prefix is not known

Yeah, in my case as well, NPTv6 is mostly only useful if it it works with a dynamic (from DHCPv6-PD) prefix, since that's how my ISP provides addresses (AFAIK I'd have to pay for a business connection to get a static prefix, though I haven't actually called and asked myself). I'm tempted to play with hacking something together by building from source myself with some tweaks to auto-update the nat rules when it gets a new PD prefix.