In T421#61055, @tbr wrote:In T421#61020, @jack9603301 wrote:No, you misunderstood. I know that nptv6 is used for NAT work of ula and global IPv6 address prefixes, which may have nothing to do with DHCPv6 PD. But in fact, for a router that fully supports DHCPv6 Pd from ISP, I hope to complete the following functions:
- The router can directly use the prefix obtained by PD to subordinate devices and specific bridges, and use the prefix allocation of ISP for further classification.
- For those who use the ula intranet address, I hope to add a function option without requiring me to specify a fixed ISP assigned address (the PPPoE dial-up of ISP will generate a different address and prefix each time)
Yes, I agree... I think this can work. But baby steps first :)
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Feed All Stories
All Stories
All Stories
Apr 21 2020
Apr 21 2020
In T421#61020, @jack9603301 wrote:No, you misunderstood. I know that nptv6 is used for NAT work of ula and global IPv6 address prefixes, which may have nothing to do with DHCPv6 PD. But in fact, for a router that fully supports DHCPv6 Pd from ISP, I hope to complete the following functions:
- The router can directly use the prefix obtained by PD to subordinate devices and specific bridges, and use the prefix allocation of ISP for further classification.
- For those who use the ula intranet address, I hope to add a function option without requiring me to specify a fixed ISP assigned address (the PPPoE dial-up of ISP will generate a different address and prefix each time)
In T421#61005, @tbr wrote:In T421#60930, @CRCinAU wrote:Maybe I'm simplifying a bit too much - but shouldn't this just be a binary on / off and an optional preferred prefix delegation size (normally between a /56 and /64)?
It would make sense to offer this for any WAN connection type - I'm not sure there's a usage case for any other type...
Yes you're oversimplifying :) But I agree it is also not so mega complex either. It is indeed in practice just a setting to enable it on an interface.
The dhcpv6-pd option would only allow to receive a prefix on a given interface. Then, as a secondary step, the prefix can be used by the router via RA on internal interfaces for address assignment (SLAAC or DHCPv6).
But ok. I'm probably missing something here. I just want to sday that the EdgeMax routers can already do dhcpv6-pd for years, and I never had any issue with their way of configuring it. I think vyos could do a very similar configuration approach and be done with it... so, I'm going to attempt in adding this myself. I need to learn the specifics of vyos builds and workflows, but other than that I have plenty of experience. Only time is a major deal breaker :)
Australia's largest mobile carrier is currently moving to IPv6 only for mobile handsets with NAT64 at their edges....
For routers that support IPv6, it will be necessary to support DHCPv6 PD and better support for NPT to set Wan dynamic address forwarding. Although this is just a personal idea, IPv6 is the future trend, and vyos need to make better preparations for supporting IPv6!
Viacheslav added a parent task for T2342: Bridge l2tpv3 + ethX errors: T2353: Interface [conf_mode] errors parent task.
Viacheslav added a parent task for T2350: Interface geneve conf-mode error: T2353: Interface [conf_mode] errors parent task.
Viacheslav added a parent task for T2352: l2tpv3 conf_mode errors: T2353: Interface [conf_mode] errors parent task.
No, you misunderstood. I know that nptv6 is used for NAT work of ula and global IPv6 address prefixes, which may have nothing to do with DHCPv6 PD. But in fact, for a router that fully supports DHCPv6 Pd from ISP, I hope to complete the following functions:
In T421#60930, @CRCinAU wrote:Maybe I'm simplifying a bit too much - but shouldn't this just be a binary on / off and an optional preferred prefix delegation size (normally between a /56 and /64)?
It would make sense to offer this for any WAN connection type - I'm not sure there's a usage case for any other type...
In T421#60929, @tbr wrote:Well, I have been using EdgeMax routers for the past 7 years or so (from the day that the ER-3 Lite was released). I use dhcpv6-pd with them and I think the config is pretty solid. I would do it very similar, if not the same.
It is very close to what @gadams proposed (see above), where the dhcpv6-pd option is added under the interface that gets the delegated prefix. Then, that prefix can be advertised on other interfaces. Important is the possibility to subdivide an assigned prefix into various subnets on different interfaces (using the sla-id option). I think it makes sense to put the dhcpv6-pd under the interfaces, just like normal address assignment falls under an interface. Moreover, dhcpv6-pd and normal IPv6 address assignment can be combined (an IPv6 interface can get a prefix and an address at the same time).
For me personally, I was hoping to start using vyos for my routing/firewall. But without PD it is unusable for me. The alternatives (pfsense, untange, Mikrotik CHR) all have their limitations too. For vyos this feature would be a huge gain.
NPTv6 has nothing to do with PD. It's used to do NAT of IPv6 prefixes.
Can PD be used for nptv6?
I don't know, I just use wide-dhcpv6-client to get the prefix i get from my ISP routed to vyos.
c-po changed the status of T2351: Cleanup PPTP server implementation and CLI commands from Open to In progress.
thomas-mangin changed the status of T2274: Move the interface default values from the conf_mode file to the interface, a subtask of T2171: Unify creation and manipulation of interfaces, from Needs testing to Open.
thomas-mangin changed the status of T2274: Move the interface default values from the conf_mode file to the interface from Needs testing to Open.
In T421#60971, @danielpo wrote:I solved this myself by building my own vyos iso and just adding --custom-package "wide-dhcpv6-client". I configured wide-dhcpv6 myself.
It works fine for now.
Works for me ..
[ interfaces tunnel tun0 ] DEBUG/IFCONFIG cmd 'ip tunnel add tun0 mode gre local 127.0.0.1 remote 1.1.1.1 dev eth0 ttl 255 tos inherit'
I solved this myself by building my own vyos iso and just adding --custom-package "wide-dhcpv6-client". I configured wide-dhcpv6 myself.
It works fine for now.
Viacheslav renamed T2350: Interface geneve conf-mode error from Geneve conf-mode error to Interface geneve conf-mode error.
Can you refer to some experience of other devices supporting DHCPv6 PD!
GitHub <noreply@github.com> committed rVYOSONEX53090ac54cff: Merge pull request #365 from thomas-mangin/T2204 (authored by c-po).
thomas-mangin changed the status of T2274: Move the interface default values from the conf_mode file to the interface, a subtask of T2171: Unify creation and manipulation of interfaces, from Open to Needs testing.
thomas-mangin changed the status of T2274: Move the interface default values from the conf_mode file to the interface from Open to Needs testing.
In T421#60928, @c-po wrote:Maybe the VyOS fans in China can come up with something, too?
Maybe I'm simplifying a bit too much - but shouldn't this just be a binary on / off and an optional preferred prefix delegation size (normally between a /56 and /64)?
Well, I have been using EdgeMax routers for the past 7 years or so (from the day that the ER-3 Lite was released). I use dhcpv6-pd with them and I think the config is pretty solid. I would do it very similar, if not the same.
Maybe the VyOS fans in China can come up with something, too?
come on. I believe you can do it. The vyos fans in China are looking forward to you!
One of the open question is how the CLI should be designed. None of us found a proper solution yet.
GitHub <noreply@github.com> committed rVYOSONEX1f3f368aaa71: Merge pull request #364 from jjakob/dhcpv6-op-mode-fix (authored by c-po).
Next rolling will have the definitive fix :)
Keep in mind that this bug was originally filed on 2013-12-31 - so I certainly wouldn't hold your breath ;)
Thank you very much! I hope to get the restored rolling image tomorrow or in the next few days. If it is repaired, can you reply me through this list?
I also want to ask, I expect it to get full support. I think the reason why the official may add features in vyos1.3 is that it is in the need triage category of vyos1.3, and it is not removed or marked as invalid, but just closed. Of course, I'm not official, but I want full support!
My fix for that was merged 7 hours ago so your 202004210117 image doesn't contain it. https://github.com/vyos/vyos-1x/commit/c7d8e39be10a59d64be643cade2213c97f1e3639
Execute sudo systemctl status isc-dhcp-server6 output:
So, what is the status of this ticket? It seems the fundamentals are available to make DHCPv6 PD work, but is someone working on this to add it to vyos?
Unknown Object (User) edited the content of CLI Shell API.
Unknown Object (User) deleted CLI Shell API.
Unknown Object (User) created CLI Shell API.
jack9603301 renamed T2348: On IPv6 address distribution and DHCPv6 bugs from Unable to use DHCPv6 to On IPv6 address distribution and DHCPv6 bugs.
This is due to the bridge missing a link-local address. The bridge members also don't need link-local addresses (currently they have them) and IPv6 can be disabled entirely on them.
When the GNS emulator is running, new errors are found. For details:
Viacheslav closed T2255: DNS forwarding op-mode error, a subtask of T2322: CLI [op-mode] bugs. Root task, as Resolved.
GitHub <noreply@github.com> committed rVYOSONEXc7d8e39be10a: Merge pull request #363 from jjakob/dhcpv6-server-fix (authored by c-po).
jestabro updated the task description for T2347: During commit, any script output directed to stdout will contain path.
jestabro changed the status of T2347: During commit, any script output directed to stdout will contain path from Open to In progress.
jestabro triaged T2347: During commit, any script output directed to stdout will contain path as Normal priority.
That fixed it for me. Thanks!
Just tested this using 1.3-rolling-202004201924 and it still happens, so that doesn't appear to have worked.
Apr 20 2020
Apr 20 2020
This is a pretty serious bug. Is there any progress?
jjakob changed the status of T2339: OpenVPN: IPv4 no longer working after adding IPv6 support from In progress to Needs testing.
@c-po can you please test if this now works, if so the task can be closed. My testing showed that it does.
GitHub <noreply@github.com> committed rVYOSONEX3dfcc251b929: Merge pull request #361 from jjakob/openvpn-ipv6-proto-fix (authored by c-po).
jjakob changed the status of T2328: dhcpv6 server not starting (disable check reversed?) from Open to In progress.
GitHub <noreply@github.com> committed rVYOSONEXa972177723c5: Merge pull request #362 from thomas-mangin/T2320-fix (authored by c-po).
zsdc changed the status of T2343: Disable memory ballooning in VM templates from Open to In progress.
jjakob changed the status of T2339: OpenVPN: IPv4 no longer working after adding IPv6 support from Open to In progress.
Yeah, I missed that one. Thanks for fixing it c-po.