Page MenuHomeVyOS Platform

Support NDP proxy
Open, NormalPublicFEATURE REQUEST

Description

During the test of ipv6 Source nat66 (NPT), a problem was discovered, that is, the prefix conversion is expected behavior, but the upstream cannot reply from its interface. The root cause is that vyos cannot respond to the NDP query request of the translated prefix. To support stateless Source NAT66 (SNPT), it is necessary to support NDP proxy function.
The ndp proxy relies on the ndppd package to achieve

Nptv6 of Vyos 1.2 has the same problem

a)

Here are some examples

set  service proxy-ndp interface <interface> prefix <prefix> mode static  # vyos defaults to static. valid values: "auto","static", and "iface"
set  service proxy-ndp interface <interface> prefix <prefix> iface <interface>  # Specify when the free mode is iface
set service proxy-ndp interface <interface> timeout 500 # Controls how long ndppd will wait for a Neighbor Advertisement message after forwarding a Neighbor Solicitation message according to the rule. This is in milliseconds, and the default value is 500
set service proxy-ndp interface <interface> ttl 30000 # This is in milliseconds, and the default value is 30000 (30 seconds)
set service proxy-ndp interface <interface> router <yes|no> # Controls if ndppd should send the router bit when sending Neighbor Advertisement messages. The default value here is yes.

b)

Here are some examples

set  interface ethernet <interface> ipv6 proxy-ndp prefix <prefix> mode static  # vyos defaults to static. valid values: "auto","static", and "iface"
set  interface ethernet <interface> ipv6 proxy-ndp prefix <prefix> iface <interface>  # Specify when the free mode is iface
set interface ethernet <interface> ipv6 proxy-ndp timeout 500 # Controls how long ndppd will wait for a Neighbor Advertisement message after forwarding a Neighbor Solicitation message according to the rule. This is in milliseconds, and the default value is 500
set interface ethernet <interface> ipv6 proxy-ndp ttl 30000 # This is in milliseconds, and the default value is 30000 (30 seconds)
set interface ethernet <interface> ipv6 proxy-ndp router <yes|no> # Controls if ndppd should send the router bit when sending Neighbor Advertisement messages. The default value here is yes.

Decided to choose a plan

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

Details

Difficulty level
Hard (possibly days)
Version
-
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Feature (new functionality)

Related Objects

Event Timeline

Beeing stateless or statefull both should work. We can add a CLI node for the proxy.ndp option like we have for proxy arp on ipv4, no big deal.

In T2518, you mentioned arp proxy, I want to know where the cli node is implemented?

jack9603301 triaged this task as Normal priority.

set interfaces ethernet eth0 ip proxy-arp. Isn‘t the Kernel sysctl interface enough? Do we really need a daemon?

I think we do need it, we can’t let users manage all IP manually unless we implement stateful NAT66

Otherwise we may need to manually perform the following operations

sysctl -w net.ipv6.conf.all.proxy_ndp=1
sudo ip -6 neigh add proxy 2001:xxxx:16:24::e686:9490 dev eth3

Please see T2518#75584

set interfaces ethernet eth0 ip proxy-arp

The more suitable position may be set protocol ndp-proxy

I can't find how to enable ipv6 connection tracking. Recompiling and modifying the linux kernel switch does not seem to see the module loaded. I think the current nat66 has completed 90%, and only need to implement ndp proxy to make it work normally.

vyos 1.2 seems to have the same problem

jack9603301 changed the task status from Open to In progress.Sep 19 2020, 9:39 AM
jack9603301 updated the task description. (Show Details)

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

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

Do you recommend the following method? @c-po seems to recommend this too:

set interfaces ethernet eth0 ipv6 proxy-ndp rules <rule> auto

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

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

@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

@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

I'll be honest I personally don't have much of a problem on where it's put. I was just more referencing on how I remember it being configured on Junos.

https://www.juniper.net/documentation/en_US/junos/topics/topic-map/proxy-arp.html
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/ndp-dad-proxy.html

If the decision is made to put it under protocols, I'm ok with it. I was just trying to keep it consistent with a system that's already in place...

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

@c-po I am thinking about a problem. Placing proxy-ndp under the child node of interface may generate redundant implementation code and is intrusive. In fact, for proxy-ndp, only one configuration file is needed. Is this Reasonable? I don't even know how to fully test whether the intrusive code affects the basic functions of the router.

Write redundant and intrusive code for all interface types, which may introduce unknown errors (I can’t guarantee 100% accuracy without testing)

Already basically ready to merge

Still wondering why ndp-proxy can not be part of the nat66 tree.
When a NAT66 translation is added we know the prefix (src and dst), the in/out-bound interface - so another CLI option (ndp-proxy) could probably be added to not open up an additional service node.

Can you please help to clarify this need of an individual node for us?

At this stage, I can't realize the automatic configuration of NDP proxy. On the other hand, although I don't know what additional application scenarios will be in addition to nat66, I hope to give full play to the full potential of NDP proxy, so I don't want to bind it to nat66 artificially.

After the nat66 merge is complete, I will add a switch to automatically generate and configure proxy-ndpwhen configuring nat66

I'm thinking about the possibility that this can support automatic configuration, but if users need to, they can also manually configure it independently instead of binding to nat66

There seems to be a separate NDP proxy option, at least in other devices

Another advantage of this is that I can continue to explore whether vyos1.2 only needs an NDP proxy. If so, then the NDP proxy can be artificially enabled to enable nptv6 to work (but I did not find that there is a real conversion from vyos1.2 to NPT from the packet capture)

@c-po I am thinking, although it is not possible to incorporate NAT66, whether we can prioritize how to improve and incorporate NDP Proxy

I still have the opinion that NDP proxy should be automatically configured when configuring nat66 as by then all interfaces and directions of the translation are known and the user must not configure any additional daemon.

I can consider migrating to the implementation of nat66, but I'm not sure if there is a case where the nat66 feature does not need to be enabled, but NDP proxy needs to be enabled

That's why I've been hesitant

That we can deal with later on when it‘s needed

Okay, then I can merge this service into NAT66

Try to port NDP Proxy to the NAT66 code of T2518 and automatically generate it

In T2898#80264, @c-po wrote:

That we can deal with later on when it‘s needed

May I respectfully ask this be reopened? I have used ndppd on VyOS for quite a long time for virtual routers serving as firewall for VMs, where the only ranges I get are routed only to the physical server rather than the router VM. In such a situation, rather than settle for an ugly bridge router, I use the following setup (notice that router addresses are the same on both interfaces to conserve limited IP addresses, only the netmasks change):

set interfaces ethernet eth0 address '198.51.100.34/29'
set interfaces ethernet eth0 address '2001:db8:fefe:c0c0:1234::fa/64'
set interfaces ethernet eth0 address description '*** hypervisor-side interface ***'
set interfaces ethernet eth0 ip enable-proxy-arp
set interfaces ethernet eth1 address '198.51.100.34/32'
set interfaces ethernet eth1 address '2001:db8:fefe:c0c0:1234::fa/96'
set interfaces ethernet eth1 address description '*** server vms-side interface ***'
set interfaces ethernet eth1 ip enable-proxy-arp
set protocols static route 0.0.0.0/0 next-hop 198.51.100.33
set protocols static route 198.51.100.35/32 interface eth1
set protocols static route 198.51.100.36/32 interface eth1
set protocols static route 198.51.100.37/32 interface eth1
set protocols static route6 ::/0 next-hop 2001:db8:fefe:c0c0::1
set service proxy-ndp interface eth0 prefix 2001:db8:fefe:c0c0:1234::/96 iface 'eth1'
set service proxy-ndp interface eth0 prefix 2001:db8:fefe:c0c0:1234::/96 mode 'iface'
set service proxy-ndp interface eth1 prefix 2001:db8:fefe:c0c0::/64 iface 'eth0'
set service proxy-ndp interface eth1 prefix 2001:db8:fefe:c0c0::/64 mode 'iface'

This setup obviously requires proxy ARP _and_ proxy NDP. Unfortunately, that broke when the new NAT66 was added since it commandeers the ndppd configuration file. I've been able to shoehorn the support for separate commands back in, but I would prefer not to have to carry another patch if possible...

@c-po What do you think?

@wsapplegate Have you finished a patch yet?

@wsapplegate Have you finished a patch yet?

Well, sort of. I mean, yes, but it was a quick'n'dirty job to make it work for me, and I don't like it one bit (for instance, it has _both_ src/conf_mode/nat66.py and src/conf_mode/proxy_ndp.py grab each other's configuration and overwrite /run/ndppd/ndppd.conf, which is really nasty, and the resulting Jinja2 template is quite ugly, too). So I'm unsure how to rewrite that in a clean way, and I would appreciate your and @c-po's opinions on the subject. One idea I have is to write each rule in its own file in some directory (like /run/ndppd/conf.d/{interface}) and then generate the final ndppd.conf from those snippets, but it seems complicated, too, and I'm still unsure what to do if there's a NAT-generated rule _and_ a manual one for the same prefix...

So I'm unsure how to rewrite that in a clean way, and I would appreciate your and @c-po's opinions on the subject

@wsapplegate I used to write the NDP proxy alone, but after the merge, I seem to have removed this part of the code. If you want to rewrite it, all you need to do is complete the proxy-ndp configuration and then write a migration to convert the configuration tree of nat66 source to proxy-ndp. (Note that nat66 source uses static mode only.)

If both the configuration and the migrator work, we can remove the code in the NAT66 configurator that generates the ndppd configuration file

Viacheslav changed Difficulty level from Unknown (require assessment) to Hard (possibly days).Feb 22 2021, 11:18 AM
erkin set Issue type to Feature (new functionality).Aug 29 2021, 1:02 PM
erkin removed a subscriber: Active contributors.