ipoe daemon allows us to use this possibility. We need to add CLI commands.
Proposed commands:

set service ipoe-server client-ip-pool name POOL1 subnet 100.64.0.0/24

Radius attribute Framed-Pool.

Tested on VyOS 1.3-rolling-202006101523
SSTP, L2TP and PPPoE work as expected.
As for pptp, needs to create an additional bug report

https://github.com/vyos/vyatta-webproxy/pull/16

Fixed: https://github.com/vyos/ipaddrcheck/commit/27dd86068b1ab3204517b8950746aec7c1c294d0

@alexandrestein Note that vyos 1.2 (crux) does not implement DHCPv6 PD.

Thanks a lot for your time and knowledge on VyOS.
I will try with 1.2.

@alexandrestein Or, a disguised solution is to directly use iptables instruction rules to manually implement temporary nptv6 conversion. But I don't know when it will work. You can try it.
PS: because vyos uses nftables to implement NAT in 1.3, but because of the function limitation of nftables version, this function cannot be realized at present.

If you want NPT, you may have to wait for the time to come when conditions are right, and the community may implement NPT at that time.

@jack9603301, you look to have way more knowledge on IPv6 routing and the VyOS capabilities than I.

Also in 1.2.5

vyos@vyos:~$ show protocols bfd peer 10.203.42.1 
% Unknown command: show bfd     peer 10.203.42.1 local-address 10.203.42.254 vrf default
vyos@vyos:~$ 
vyos@vyos:~$ show protocols bfd peer 10.203.42.1 counters 
% Unknown command: show bfd     peer 10.203.42.1 local-address 10.203.42.254 vrf default counters
vyos@vyos:~$ 
vyos@vyos:~$ 
vyos@vyos:~$ show version 
Version:          VyOS 1.2.5

hello Thomas
What exactly do you need ?

hello Fabio, could you please show me how the vti interfaces are presented under Linux so I can fix the code. I thought I had properly ported the code from Perl to Python must I must have misunderstood something.

I'm pretty sure it's my failure to correctly handle an edge case. I'll look into it today, should be simple enough.

Clearly a workaround is the fastest way to "fix" VyOS, but the backend code should be fixed, too. This is either ipaddrcheck https://github.com/vyos/ipaddrcheck or libcidr.

i'm wondering if this is the right approach.
This works as a workaround, but this needs to be added to the ipaddrcheck validator as an allowed host-address and not be done in a shell script

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

https://phabricator.vyos.net/T2578

Proposed validator for host https://github.com/vyos/vyos-1x/blob/current/src/validators/ipv4-host

Do I need to do more to get the PR merged?

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

@alexandrestein Vyos1.3 's npt is temporarily unavailable, but vyos1.3 basically supports dhcpv6-pd,. If there is no special reason, you can consider using a global address instead of ULA, to obtain the delegation prefix directly from ISP and distribute it to the client (via RA), instead of using ULA+NPT.

Sorry.
It had some kind of persistency and I had to turn it on again to have it working.

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

NPTv6 is available in VyOS 1.2 (crux) and currently not implemented in 1.3 (equuleus) as nftables package should be updated to 0.9.5 to make use of netmap.

@zsdc can you please have a look? CHanges to FRR show commands introduced here: https://github.com/vyos/vyos-1x/commit/6492541b

@alexandrestein To be honest, I don't understand why NPTs work in your configuration. It seems to have nothing to do with NPTs.

You are right.

I suppose the problem is related to T2546 and the the op-mode: T2546: migrate show interfaces tunnel,input,pseudo-ethernet,… github commit

In fact, according to official comments and my retrospection of nptv6 code, vyos has not generated any code for nptv6 at present.

I made this works.

https://github.com/xebd/accel-ppp/issues/133

In T2321#66700, @c-po wrote:

@daniil that would work of course. You tested it manuslly that this works?

In this case, SSTP daemon trying to allocate RAM for ipv6 pool and router does not have enough RAM. Dynamic memory allocation is not implemented for ip-pools.
Maybe, in this case, we need to calculate before commit, and show commit fail message with reason?
Calculating:
2^64 bit = 18446744073709551616 bit or 2305843009213693952 byte
2305843009213693952 * 64 (structure size byte) = 147573952589676412928 byte or 137438953472 GB
Correct me if my calculation wrong.

Successfully able to create the vif-s 1234 per the above example without any issues on VyOS 1.3-rolling-202006070117:

This one works good too

Seems like this might be VRF related

@daniil that would work of course. You tested it manuslly that this works?

Can use systemd module file override?

Changed this around a bit to load the modules automatically if necessary. Only adds about half a second to initial execution

@jjakob. to clarify two points (for my sake as well), there are cases where config fails to the point where the config session can not be initialized, such that one can not enter a config session: here's an example --- say. during development, someone forgets to import a module in an early conf_mode script; config initialization is completely screwed --- this had occurred ages ago, and the only way I found it was that I had happened to be looking at their code a few moments previously and noticed ... that's what vyos-config-debug is for, and why it is hidden on a boot flag. You are talking about a much more reasonable case, where (I imagine) a specific configuration causes a partial failure, but one can still enter a config session. The checks in subtask T2568 may help restore the ability to debug by config/load/commit. Those checks are needed anyway.

https://github.com/vyos/vyos-1x/compare/current...jestabro:config-checks.patch

I think we can safely remove it indeed.