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

PR https://github.com/vyos/vyatta-ravpn/pull/16

This is the output of this line

@olofl if was an example with grep, I didn't want to show the complete routing table.
If you want to check the route, this commit exactly check 2 tables. Table 254 and table local
In your case it will be 2 checks:

The problem is that interface eth1 is exclusivly added to macsec1 as its lower interface. Thus you can not add it as a bridge member to br0.

Notice how my loopback interface with mask /32 does *not* show /32 in route table local.

@olofl it checks ip addresses assigned to the loopback interface which located in the table "local"

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:

@Viacheslav does that PR check for x.x.x.x/32 ? Because the ip route show table local does not contain the netmask /32. While ip route show table 254 actually shows the prefixes with /cidr notation.

It use different directions

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

Interesting post: https://serverfault.com/questions/152363/bridging-wlan0-to-eth0

Resolved via https://github.com/vyos/vyos-1x/commit/d1c9ee33f25e45cea0d01f9685f99c960ed4d7f8

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.

No arp proxy option is found in the configuration path, ndp proxy can manage multiple address rules under one interface

vyos@vyos# set interfaces ethernet eth0 ip 
Possible completions:
   arp-cache-timeout
                ARP cache entry timeout in seconds
   disable-arp-filter
                Disable ARP filter on this interface
   enable-arp-accept
                Enable ARP accept on this interface
   enable-arp-announce
                Enable ARP announce on this interface
   enable-arp-ignore
                Enable ARP ignore on this interface
   enable-proxy-arp
                Enable proxy-arp on this interface
 > ospf         Open Shortest Path First (OSPF) parameters
   proxy-arp-pvlan
                Enable private VLAN proxy ARP on this interface
 > rip          Routing Information Protocol (RIP)
   source-validation
                Policy for source validation by reversed path, as specified in RFC3704

Although I intended to think that it is easier to write scripts under the protocol, but from an intuitive point of view, it seems that this path is also a good choice (users can use the same command line as the arp proxy to configure) I have written it A sample, then only need to decide how to modify the cli

In T2898#75670, @Cheeze_It wrote:

In T2898#75656, @jack9603301 wrote:

set interfaces ethernet eth0 ip proxy-arp

The more suitable position may be set protocol ndp-proxy

I...really would like to not put it under "protocols" but to put it under the interface. It's *much* easier and more intuitive to see it under the interface/sub-interface than to see it in its' own stanza under "protocol" node.

Also, I'd argue it would be reasonable to separate ARP proxy and NDP proxy. That way one can pick and choose. Of course ARP proxy can't work without an IP address configured. NDP proxy can't be configured without an IPv6 address configured (those could be used as checks against configuring it on an empty interface).

If possible, give your suggested cli path for my reference

In T2898#75656, @jack9603301 wrote:

set interfaces ethernet eth0 ip proxy-arp

The more suitable position may be set protocol ndp-proxy