Page MenuHomeVyOS Platform

Add support for IPv6 NAT (NPTv6)
Closed, ResolvedPublicFEATURE REQUEST

Assigned To
Authored By
jack9603301
May 26 2020, 1:30 PM
Referenced Files
F1119180: 图片.png
Jan 21 2021, 5:38 AM
F1119184: 图片.png
Jan 21 2021, 5:38 AM
F1119189: 图片.png
Jan 21 2021, 5:38 AM
F872747: 图片.png
Sep 23 2020, 1:49 PM
F872745: 图片.png
Sep 23 2020, 1:49 PM
F872743: 图片.png
Sep 23 2020, 1:49 PM
F872364: VyOS NAT66 NDPPD Ethernet Topology.png
Sep 22 2020, 5:33 PM
F861749: VyOS NAT66 Topology.png
Sep 16 2020, 10:50 PM

Description

At present, there are configuration options about NPT in vyos version, but they seem to have no effect. Does anyone know how to implement this feature.

Referring to H3C, NPT is also called nat66 technology. In fact, it is SNAT and DNAT implemented by IPv6. Different from IPv4, nat66 only supports 1-to-1 mapping of routing prefix, which will provide vyos with nat66 experimental support supporting SNPT and DNPT. This implementation needs to be tested. Please summarize all bugs and modification suggestions under this task for tracking.

set nat66 source rule <ruleid> description <description>
set nat66 source rule <ruleid> disable
set nat66 source rule <ruleid> log
set nat66 destination rule <ruleid> oinbound-interface <interface>
set nat66 source rule <ruleid> source prefix <prefix>
set nat66 source rule <ruleid> translation address <prefix>
set nat66 destination rule <ruleid> description <description>
set nat66 destination rule <ruleid> disable
set nat66 destination rule <ruleid> log
set nat66 destination rule <ruleid> outbound-interface <interface>|any
set nat66 destination rule <ruleid> destination address <ipv6-address>|<ipv6-network>
set nat66 destination rule <ruleid> translation address <ipv6-address>|<ipv6-network>

I refer to the configuration structure of H3C. In the original command structure, NPT does not support the division of SNAT and DNAT. In order to implement nat66, I separated it for the following reasons:

  1. I can modify it according to the existing script of NAT, and I can modify it less nat.py , I created nat66 and the independent nftables-nat66.tmpl to complete the implementation of nat66.
  2. It can fully support the configuration of SNPT and DNPT in nat66. If users do not need SNPT or DNPT, it should not take effect by default.

My initial implementation of npt is in:

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
  • SNPT Address Mapping
  • DNPT single address mapping
  • DNPT 1:1 mapping

Details

Version
-
Is it a breaking change?
Config syntax change (non-migratable)
Issue type
Unspecified (please specify)

Related Objects

StatusSubtypeAssignedTask
ResolvedFEATURE REQUESTjack9603301
ResolvedFEATURE REQUESTc-po
ResolvedFEATURE REQUESTn.fort

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

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.

图片.png (703×1 px, 125 KB)

图片.png (427×1 px, 41 KB)

图片.png (563×1 px, 79 KB)

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?

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
jack9603301 changed Version from vyos 1.3 to -.

I have finished the test of nat66 in GNS lab

Test case topology:

图片.png (410×903 px, 16 KB)

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):

图片.png (394×1 px, 100 KB)

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):

图片.png (587×980 px, 26 KB)

jack9603301 changed the task status from In progress to Needs testing.Jan 24 2021, 9:13 AM
jack9603301 moved this task from In Progress to Finished on the VyOS 1.3 Equuleus board.
jack9603301 changed the status of subtask T2898: Support NDP proxy from Open to In progress.Jan 13 2022, 7:40 PM

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)

n.fort changed the status of subtask T4598: nat66 - Add exclude options from In progress to Needs testing.Aug 9 2022, 10:39 AM

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

c-po set Issue type to Unspecified (please specify).
c-po moved this task from Need Triage to Finished on the VyOS 1.4 Sagitta (1.4.0) board.
c-po moved this task from Open to Finished on the VyOS 1.5 Circinus board.
dmbaturin renamed this task from Support NAT for ipv6(NPT) to Add support for IPv6 NAT (NPTv6).May 11 2024, 4:56 PM