Also come back to this question?

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:

So I was super lucky to pick the wrong characters!

The problem with that expression
https://github.com/vyos/vyatta-cfg-system/blob/current/scripts/install/install-image-existing#L271

For testing

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.

PR for crux https://github.com/vyos/vyos-1x/pull/550

The same bug with crux

I will test with the new release and report my results.
Thank you very much!

@diekos Will be fixed in the next rolling release, build after 23 Sep. Check, please.

PR https://github.com/vyos/vyatta-cfg-system/pull/128

PR for rolling https://github.com/vyos/vyatta-cfg-vpn/pull/39

@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

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.

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

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?

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

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

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 only know some python but that looks like the part that gets the gateway from the lease file.
My simple mind would say that the underscore needs to be replaced with a dot, but I have no idea if it really is that simple.

It looks like this code is to blame.
https://github.com/vyos/vyatta-cfg-system/blob/current/scripts/vyatta-dhcp-helper.pl#L21

Hey guys,

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

https://forum.vyos.io/t/limit-download-and-upload-on-wan-for-every-vlan/5608/51

PR for rolling https://github.com/vyos/vyatta-cfg-vpn/pull/38

It declared 2 times, because there is 2 checks

Thanks for testing @SrividyaA . As described in the commit you mentioned (https://phabricator.vyos.net/R12:aba26326537cca5b689e5a32f860608d2a9f8510), the additive keyword works correctly when the string is quoted, and it also works for large-communities, even though "additive" is not suggested in the tab completion for large-communities:

First create a vrf and bridge interface and add eth1 to the bridge:

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

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

Can you share some config snippets with real set commands? Sounds like a problem with the bridge validator.

@c-po If I want to be an interface-ethernet.xml.in Add custom configuration actions (such as proxy NDP) with certain extensibility (its configuration can be extended in other places). What should I do?

In T2898#75677, @jack9603301 wrote:

@Cheeze_It

I also take into account the specific situation of the ndp proxy, the configuration of this link prompts, the configuration format of the ndp proxy is like this.

https://manpages.debian.org/buster/ndppd/ndppd.conf.5.en.html