Thanks for getting back to us!

This is now resolved for us.

Alternatively, can you provide the contact information of NET-SNMP's PRIST? I can also contact him for vulnerability disclosure.

Yes, I also believe that this crash exists in all current versions of NET-SNMP. And I also found this vulnerability in the source code of the latest version of Net-SNMP( version 5.9.1), and I compiled and installed net-SNMP on Ubuntu to duplicate this vulnerability. But I can't find the contact information of NET-SNMP. It seems that only the cooperative manufacturer can contact him. Can you negotiate with them to disclose this vulnerability?

Fixed in https://github.com/vyos/vyos-1x/commit/358f0b481d8620cad4954e3fe418054b9a8c3ecd

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

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

Can I please check if this may have any resolution in the near future?
I am hoping to rely on this but at the moment it just load balances instead of fail over and that gets very very expensive when the backup is an ethernet port based 4G modem.

Any idea how you would like the CLI to look like for option 82 support?

I use Microsoft NPS and it feels correct for me:

I also have some of those APU4 devices and they work actually pretty good. The reasons for those "low" defaults are actually not from VyOS but from the Linux Kernel itself.

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

After the investigation, we figured out that it is possible to get the prefix and link-local address during the DHCP commit procedure.
The statement

log(info, binary-to-ascii(16, 8, ":", substring(option dhcp6.ia-pd, 24, 17)));

will give us the next info:

dhcpd[1568]: 40:20:1:ca:fe:11:11:ff:ff:0:0:0:0:0:0:0:0

So, a prefix can be extracted. Also, a link-local address may be generated from the MAC address extracted from the DHCP packet structure.

Possibly unrelated, but I'll leave it here

frr-reload output:   0 /usr/lib/frr/frr-reload.py:851: SyntaxWarning: "is not" with a literal. Did you mean "!="?
frr-reload output:   1   if line is not "exit-vrf":
frr-reload output:   2 2021-11-02 18:33:34,225  INF

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

set vpn sstp authentication local-users username foo password 'bar'
set vpn sstp authentication local-users username foo2 password 'bar2'
set vpn sstp authentication mode 'local'
set vpn sstp client-ipv6-pool prefix 2001:db8::/48
set vpn sstp gateway-address '192.168.122.14'
set vpn sstp ppp-options ipv4 'deny'
set vpn sstp ppp-options ipv6 'allow'
set vpn sstp ssl ca-cert-file '/config/user-data/sstp/ca.crt'
set vpn sstp ssl cert-file '/config/user-data/sstp/server.crt'
set vpn sstp ssl key-file '/config/user-data/sstp/server.key'

Check sessions:

vyos@r4-epa2:~$ show sstp-server s
sessions    statistics  
vyos@r4-epa2:~$ show sstp-server sessions 
ifname | username |          ip           |          ip6          | ip6-dp |   calling-sid   | rate-limit | state  |  uptime  | rx-bytes | tx-bytes 
--------+----------+-----------------------+-----------------------+--------+-----------------+------------+--------+----------+----------+----------
 sstp0  | foo2     | 2001:db8:0:0:200::/64 | 2001:db8:0:0:200::/64 |        | 192.168.122.222 |            | active | 00:00:09 | 735 B    | 506 B
vyos@r4-epa2:~$

Additional note: this, of course, breaks the 'red' vrf connectivity.
If I manually add, using vtysh, the

vrf red
 vni 3000

everything on the 'red' vrf works fine.

Yes, It seems that rfc doesn't work , also I found this issues :
https://github.com/FRRouting/frr/issues/5824

@zoenan7 Sorry for the late reply! Yes, I got your email and could reproduce the crash using your PoC.

Mentioned here (FRRouting):
BGP vpnv6 next hop address maybe error?

To enable IPv6 only it is required some new options in CLI, which are not presented in 1.3 yet