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.

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

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

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

Therefore when modifying the default boot image (either via 'add system image' or 'set system image default-boot') the script that modifies grub.cfg needs to add its own name to it (easiest to do by adding a comment line to grub.cfg with its menu entry number), so that the failsafe reboot knows into which image to reboot into (it parses out the entry number from the grub comment and sets the default entry to it).

Can you ask the user if you want to start the migration failure fallback mechanism on the first boot of the new image when upgrading, and if the user chooses to enable this mechanism, you should let the user select an old secure image (execute the mechanism only on the first boot)?

In fact, you may be able to switch the default startup item by simply trying to call the following command, and this corresponds to the following command:

I look forward to your success.

You can ask the user before the upgrade operation if you want to perform the fallback on failure function on the first boot after the upgrade, and select an old image that is safe when the migration fails.

The way the current bootup commit works, (I'm not 100% certain, I may be wrong in some parts) is that it first looks if any components of the config require syntax migration, if yes, it backs up config.boot to config.boot.pre-migration-$(date) and goes through the migrator scripts, each one modifying the configuration to bring the syntax up to date, then it saves the new component version string and new config into config.boot, and then commits it. Therefore the config.boot is already migrated to the new syntax even if the commit then fails, meaning you can't simply reboot into the old image and expect things to work, as the old image expects the old config syntax, but the config was already migrated to the new one. We need to replace config.boot with its .pre-migration version before rebooting into the old image.

Perhaps a good way is still for the user to choose whether to reconfigure or restart with the old image.

Sorry, I don't know if I understand it wrong, but please allow me to express my opinion, but when you install and add a new image from the old image for upgrading, it may occur that it can't be used normally at startup config.boot Configuration (especially rolling update), in which case, whether or not the old config.boot There is no intention to make any migration or modification Justice. Either the configuration syntax has been changed and errors still occur after migration, or some settings of the system image have problems. A better solution is to modify grub's default boot so that it can boot from the old normal system image, if it exists, but this requires user authorization.

@dsummers Obviously, this kind of output belongs to error report, prompt dhcp6c@eth0 Unable to start normally, measures should be taken to eliminate them. I once submitted a PR (not yet passed) that can try to restart when the service fails. The original intention is to recover from the failure when the first load fails after the restart (because some interfaces are not initialized). I don't know if this patch can help temporarily dhcp6c@eth0 Restart, and complete the startup normally after 10 seconds of failure. However, you can try it. In a word, you should take measures to eliminate such errors.

As required by the DHCPv6 PD function, the IPv6 part seems to be migrated from ISC DHCPv6 to wide-dhcpv6. According to your error log analysis, dhcp6c@eth0 Start failed.

Strange, I didn't test this problem again, but according to the T2449 problem I submitted before, DHCPv6 of IPv6 can get the address and route normally (the route depends on SLAAC). Isn't it ok now?

Where do you configure DHCPv6 PD?

@dsummers How is it possible, please give a configuration to facilitate others to check (this is a good habit)

When I'm done with the reboot dhcp6c@pppoe0 After the problem of possible startup failure, another strange problem was found, that is, every once in a while, the IPv6 route assigned by DHCPv6 PD will fail, and I can't find the reason yet. Can you help me find the reason?

Strangely, I found that under my use case dhcp6c@pppoe0 The prefix obtained cannot be routed the next day.

@c-po After thinking about it, maybe the only thing I can think of is the word limit of a single line. I submitted another commit.

Please merge the following PR, if there is a problem, please let me modify it.

If so, it's better to consider porting the 1.2 NPT implementation instead of using a new solution. Can they coexist? I'm just a suggestion.

If you think it's possible to delay dhcp6c, I'll start making patches.

@c-po @gadams I have a remedy in mind. Can I use the delay command to execute the delay startup in the startup service file?

@CRCinAU @c-po I have already submitted a PR, to repair the problems caused by the first load after boot, because the interface has not yet been initialized, but this completely depends on the automatic restart of systemctl for fault recovery. I think this is not enough. It is natural to recover from the failure, but if there is a mechanism and processing, it would be better to postpone it until all interfaces have been initialized.

@gadams Is there any way to dynamically increase the dependency list in vyos's current configuration?

There is no error in the configuration itself, and the key is the first boot load when rebooting. In this case, some of the interfaces are not initialized.

I've been trying to find the ultimate solution to this problem, and it seems that the best solution is to postpone dhcp6c until the end of all interfaces to start it. Before that. I have done enough testing, and the previous comments in the error log have been released.

@jjakob I understand what you mean, so let me explain to you carefully. Over the past two days, I have been trying to find out why the first automatic startup of dhcp6c fails (this is usually due to the automatic call when vyos automatically loads the configuration). At present, the root cause has been determined. I just call dhcp6c manually by the script of vyos, and I also understand this process, but because of the particularity of prefix delegation, such as my case, When pppoe completes the call to execute dhcp6c@pppoe0 execution prefix delegation, I give the prefix to br1 and br2, respectively, which are not created at the startup of their pppoe0 and dhcp6c@pppoe0, so the dhcp6c launcher will fail. I currently have a pudding configuration that when the vyos script manually invokes and starts dhcp6c and fails, it restarts at regular intervals until the service runs or the user stops it manually. But this is far from enough, it only depends on the recovery from the failure of the systemctl startup service to complete the recovery operation. As @gadams said, due to the particularity of dhcp6c's configuration file, when its prefix is delegated, its dependency will change from configuration to change, and its behavior allows it to depend on all interfaces. Therefore, it is a good idea to postpone the startup of dhcp6c to the last call (please note that fault exploration has been completed, the root cause of this failure has been determined, and its temporary patch configuration has been tested in the local environment. Therefore, we can first approve the patch configuration merge, and then discuss the issues related to the postponement of dhcp6c)

Of course, if there is a better way to solve this problem, you are welcome to put forward

When using dhcp6c for prefix delegation fetch, it can rely on any interface and should be called after all interfaces have finished starting

Because it is impossible to determine the user's dependence on the configuration interface of dhcp6c, the dependency problem has already occurred, which will cause the startup program of dhcp6c to fail after rebooting the system. I have made a patch configuration so that dhcp6c, can be restarted indefinitely in the event of failure, but this is still not the best way. Of course, the best solution may be to postpone the startup priority of dhcp6c.

Because I need to recover the fault first, so I made a patch. After all, I don't have a good way to postpone its processing.

I think this problem can consider setting up a new task list and studying how to postpone the processing of this. Fault recovery is usually desirable, but we should not push all possible priority-induced failures to recovery in the fault.

I still think the failure recovery mechanism needs to exist, but I agree with you. I think we should postpone the startup mechanism of dhcp6c until all interfaces have been initialized. A better idea is to execute dhcp6c processing uniformly after all interfaces have been initialized.

Please merge this fix.

https://github.com/vyos/vyos-1x/pull/438

The repair settings take effect on tests in the local environment.

@gadams Yes, I thought that since the system CTL automatic restart failed, I might need to write a script to perform the automatic recovery. Now it doesn't seem necessary. I will modify its service file.

OK, I have found the best recovery. I will submit PR immediately. I will modify the service settings of systemctl and use its failure to restart automatically to fix the problem. When dhcp6c service fails to start, it will restart according to the preset settings.

In general, there are several solutions:
a) Add the CLI option of auto repair daemons, and rely on cron to execute the repair program. In case of service failure, the service can be restarted automatically
b) Find the only way to solve the problem thoroughly
Generally, I prefer a + b, so that when the service fails to start in a single time, the daemons can complete the recovery execution.
But it's just an idea. If you have any other suggestions, please let me know.

I try to manually modify the contents of /etc/ppp/ipv6-up.d/1000-vyos-pppoe-pppoe0 , and change the following commands:

@gadams In my environment, oddly enough, after a reboot dhcp6c@pppoe0 Restart PPPoE 0 by using the vyos command or use systemctl to query and find that the service is manually restarted dhcp6c@pppoe0 Before that, the service was in a failed state and the Restart field of the service did not work. During the configuration loading process after system restart, I cannot make it start normally

@c-po It has to be said that this is really a troublesome problem. I'm still stuck in fault exploration, rather than making patches. Therefore, there may be some assumptions and verification processes, but it's really troublesome. When the system is restarted, the automatic operation of the service will fail, and I have to restart the service manually.

@c-po Strangely, after rebooting the system, I specifically dhcp6c@pppoe0 Query and find that this service is manually restarted by using the vyos command to restart PPPoE 0 or by using systemctl dhcp6c@pppoe0 Before, this service was in failure status, and your Restart field of the service didn't work. I can't make it start normally during the configuration loading process after the system is restarted 。

@c-po Trace the problem that the system cannot automatically perform prefix delegation after restarting:

@c-po I didn't find out where to call using wide DHCP. I intend to analyze the reason why restart can't automatically start allocating prefix in the 20200523 image.

@c-po @gadams In 20200523, I found several bug, although it will not affect my use too much (anyway, it can be restarted). For example, when pppoe is rebooted many times, the prefix will be reassigned, but the old prefix that has been assigned has not been deleted. Although I can keep it working, I still don't know how to solve it. I wonder whether restarting its interface can solve the problem when the current prefix allocation request is restarted.

I will track and test whether the dhcpv6-pd is functioning properly to see if the previous problems still exist in my environment.

Thank you @c-po. It's very good. I fully understand you. Like you, most of the open-source contributors are amateurs. I don't mean anything else. I think you may have misunderstood my remarks. Please don't be too sensitive. Anyway, thank you. In addition, you can take a look at the comments above and the two questions I raised. I don't know how to solve it for the time being. If you or someone else has a good solution, thank you.
Thanks again

However, there will still be other problems, such as those described in the comments above, and two small problems I have raised. For the moment, I can only guarantee that there will be no py syntax interpretation errors.

I have fixed the following error and submitted PR request for it, but it has not been passed yet.

it will be converted by some CPE to regular old ethernet,

@gadams Therefore, in order to use SLAAC and DHCPv6 PD in this case, the router below should receive RA from the superior router or CPE device?

Come on, I think I've got a patch for py error reporting ready before @c-po. I'll launch PR directly.

I should note that in setups for some very large ISPs in the US, and probably elsewhere, there is no need for a DHCPv6 client at all, except for doing DHCPv6-PD. The directly-connected IPv6 network gets its assignment via RA, and IPv4 addresses may be assigned statically.

@gadams Strange, in my environment, delegation requests are successful when PPPoE is used for dialing. When setting delegation on the non PPPoE interface, do you need the superior router to set DHCPv6 PD delegation and issue operations on the interface (this is not required here, I mainly obtain prefix delegation when ISP dials PPPoE)?

@gadams I am ready to fix the following problems. If @c-po doesn't understand what happened and solve it, I may submit PR request.

You can consider submitting a PR request in a rolling branch that has requested a merge.

However, no prefix delegation request appears to be sent and no configuration of delegated interfaces appears to be done. Indeed, no dhcp client appears to be running.

Usually this bug should reopen a bug report. The project management system can create subtasks, and you can usually consider opening a subtask

Of course, for the time being, I can only solve the specific code errors introduced by @c-po. Above, I have raised some of the existing minor problems of using delegation in pppoe. I think I may not know how to solve this problem for the time being. If you have this ability, you can consider solving it.

@gadams With regard to this question, I have specifically read the submission record of @c-po, and I think I have found out where the possible errors are (please read my comments above). Of course, I expect @c-po to solve the errors introduced by itself, because it seems very simple, if the problem @c-po is not resolved for a long time, I may consider submitting a pr request.

This work is done by @c-po, but according to my experiment, the current scrolling version is a 20200523 image, and dhcpv6-pd works basically fine in my ISP environment. But there may be some minor problems. Please read the comments on this list.

What does it mean? I'm sorry, I may not understand.

In addition, please pay attention to the previous question of another user feedback. I have read the relevant code you submitted, and you may have written it wrong.

a) I know it's not supposed to be like this, but it does show up with me.

@c-po In addition, I also feedback several questions (if this is not a problem, please tell me the correct understanding and use):

Prefix delegation is a very important function, which needs to be used to provide routable prefix segment allocation to users.

You can download 20200523 and later scrolling images to use this feature

Dhcpv6-pd can be used normally at present, and it works well in my ISP.

If this field is only the len, of prefix, there is no need to use prefix writing.

Thank you. Finally, RA was able to set and distribute all the new IPv6 64bits prefixes with the following instructions:

@c-po At present, through DHCPv6 PD, IP can be obtained on the bridge, but cannot be distributed to the client through SLAAC. Is it my configuration error?

@c-po I suspect that the problem has been found, but after I executed the restart PPPoE command, the default travel was lost. My configuration name wrote the following static route:

interface-route 0.0.0.0/0 {

next-hop-interface pppoe0 {
}

}
interface-route6 ::/0 {

next-hop-interface pppoe0 {
}

}
table 150 {

interface-route 0.0.0.0/0 {
    next-hop-interface pppoe0 {
    }
}
interface-route6 ::/0 {
    next-hop-interface pppoe0 {
    }
}

}

But it disappeared after disconnect interface pppoe0.

Although I wanted to try it out, it seems the best way is to try to upgrade to the latest stable version. From the perspective of version management, the higher version often fixes some existing bugs, while the stable version ensures sufficient testing to avoid 0days.

@jjakob I'm sorry, but I think you may have misunderstood me. I just summarized the problems that can be solved at present. Of course, this patch can finally be submitted to PDNS. Relatively speaking, the current solution to the problem may be the first priority, and there are only two main ways to solve the problem, either to solve it or to bypass it.

I can summarize the following solutions, and maybe there are other solutions:
a) Fix the bug yourself
b) Use other storage mechanisms to resolve records to bypass
c) Self parsing hosts

Alas, it's really a troublesome problem. If it's a bug, I haven't used pdns-recursor. I usually use ISC bind, but I have a solution different from the one you put forward. It is based on the independent maintenance of open source branches, looking for the code with problems and implementing the patch. @jjakob

You mean that when pdns-recursor forwards the query to the back-end recursive parsing service for the first time, after that, the static entries in query /etc/hosts will always return NODOMAIN.

via 'system static-host-mapping' return NXDOMAIN from 'service dns forwarding' after a request to a forwarded zone

in full agreement

In T421#64197, @jjakob wrote:

That's a case where having the ability to assign addreses from the received prefix via DHCPv6 on the internal interface would allow internal hosts to get managed addresses from the prefix automatically without the use of NPT or SLAAC. But that isn't implemented yet AFAIK.

Even if dhcpv6-pd is now supported, nptv6 may still be needed, and as a user's choice, the application user may need to use the ula address. In particular, if you do not use ula addresses, in some environments, users may not be able to obtain fixed address prefixes, and when users need internal IPv6 address prefixes that can only be assigned by themselves, NPT may be necessary.Like myself.

No one to follow up? I know this problem may be strange, but it does happen to me!

In T421#63999, @Azayaka wrote:

In T421#63962, @jack9603301 wrote:

@c-po What did you want? Configuration of DHCPv6 PD in vyos?? Didn't you update the document? How do you configure it?? I don't quite understand!

Please...This is just embarrassing. This comment might be off-topic, but it looks like our fellow Chinese user @jack9603301 need suggestions on how to use English in a proper manner. (Your current wording style can easily offend people.)
Here are my wording suggestions.

• Avoid double or tripple question marks.
• Avoid rhetorical questions.
• Use "Sorry", "Please", "Could you...", etc. for questions and requests.
• Avoid representing others if you are not entitled. For example, when *you* want some features, do not say "VyOS fans in China" want those features.

I can translated my points to Chinese if it can be better understood.

雖然你可能沒有意識到，但是你的英語行文很不禮貌，容易冒犯他人。以下是我的幾點建議：

• 避免使用多個問號。
• 避免反問他人。在中文語境下，反問也可以被認為是想吵架。
• 多用 "Sorry", "Please", "Could you..." 這種緩和語氣、表示禮貌的詞彙，特別是在提問或請求他人的時候。
• 不要輕易“代表”他人。

In T421#63999, @Azayaka wrote:

In T421#63962, @jack9603301 wrote:

@c-po What did you want? Configuration of DHCPv6 PD in vyos?? Didn't you update the document? How do you configure it?? I don't quite understand!

Please...This is just embarrassing. This comment might be off-topic, but it looks like our fellow Chinese user @jack9603301 need suggestions on how to use English in a proper manner. (Your current wording style can easily offend people.)
Here are my wording suggestions.

• Avoid double or tripple question marks.
• Avoid rhetorical questions.
• Use "Sorry", "Please", "Could you...", etc. for questions and requests.
• Avoid representing others if you are not entitled. For example, when *you* want some features, do not say "VyOS fans in China" want those features.

I can translated my points to Chinese if it can be better understood.

雖然你可能沒有意識到，但是你的英語行文很不禮貌，容易冒犯他人。以下是我的幾點建議：

• 避免使用多個問號。
• 避免反問他人。在中文語境下，反問也可以被認為是想吵架。
• 多用 "Sorry", "Please", "Could you..." 這種緩和語氣、表示禮貌的詞彙，特別是在提問或請求他人的時候。
• 不要輕易“代表”他人。

@c-po What did you want? Configuration of DHCPv6 PD in vyos?? Didn't you update the document? How do you configure it?? I don't quite understand!

Great, dhcpv6-pd is finally coming true!

In T421#63876, @Azayaka wrote:

Damn, I am so embarrassed by @jack9603301. From the avatar to the naive, rude comments... looks like a troll XD.

Another problem of the EdgeRouter-style configuration is that only one PD is possible at a time. Cisco IOS uses the concept of dhcp pool and pd name-tag to deal with multiple PDs (a possible scenario: 2 PDs from 2 different ISPs for redundancy). Not sure if it can be supported by dhclient though.

I prefer the IOS style, and here is an example.

ipv6 dhcp pool POOL-v6
 dns-server 2001:4860:4860::8888

interface GigabitEthernet0/0/0
 ipv6 address autoconfig default
 ipv6 enable
 ipv6 nd ra suppress all
 ipv6 dhcp client pd ISP-name
 ipv6 virtual-reassembly in

interface Vlan1
 ipv6 enable
 ipv6 address ISP-name ::1/64
 ipv6 nd other-config-flag
 ipv6 nd ra interval 180
 ipv6 dhcp server POOL-v6 rapid-commit

@jjakob @c-po Execute the following command. Although the default route can be generated automatically, it may be a bug in the current PPPoE function. In a specific environment, restarting PPPoE dialing will not maintain dialing status!

@c-po I suspect that the problem has been found, but after I executed the restart PPPoE command, the default travel was lost. My configuration name wrote the following static route: