One other question -- looks like SLAAC is working with the router-advert, but I believe Windows clients need DHCPv6 to receive addresses. I believe that the auto-config of DHCPv6 based on assigned prefix is not included yet, correct? Is that the 'Assisted' or 'Managed' modes that pfSense/Opnsense has?

Windows 10 works with SLAAC like a charm.

Hey, @c-po, thanks for getting this moving again. As you may recall, I did a lot of development work on this some time ago that I never pushed to get merged. (I dropped the ball.) Unfortunately, you've had to re-do a lot of what I did, I'm sure. I'm happy to incorporate any of that past work or do some fresh development to polish this feature up.

So, I'm curious where things stand, in your estimation? What work needs to be done?

I suspect there are a few areas, which you may or may not already have addressed:

• Starting up dhclient (assuming that's what's still being used) when DHCPv6-PD is needed, but it's not otherwise already started.
• Distributing delegated addresses to other interfaces (I'd thought you already did this, but it sounds from some of the comments above that perhaps it's not done?)
• Ability to request specific prefix sizes
  • Does this refer to requesting from the DHCPv6 server, or:
  • when specifying the total prefix length of the delegated prefix + the sla id?
• Anything else?

Hi @gadams,

dhclient is not used, wide-dhcp client is started on demand. Also prefixes are properly assigned to interfaces, using this at home for pppoe. Specific prefix size request is implemented as of T2506.

This means you request a specific size from you ISP, sla-id just identifies a prefix (/64) from this assignment. You can refer to PPPoE documentation for more info https://docs.vyos.io/en/latest/interfaces/pppoe.html#ipv6

Currently I see no open topics - or I am not aware of any.

Thanks for the response.

In my case, I don't see wide-dhcp started. What piece of code is supposed to do this? I'd like to dig into this. Without this, of course, nothing else happens.

I'm glad to hear that the rest is implemented!

A couple suggestions:

• The docs say that the default sla-len is 16. It would seem more useful to default to whatever size would yield a total prefix length of 64. Also, it seems better to specify the final prefix length, rather than the length of the sla portion, for the reasons I mention in T421#65109.
• The docs should be moved out of the pppoe section. It seems strange to have DHCPv6-PD docs there, when the two are really completely independent. At first, when I saw it there, I thought it would only work in the context of pppoe, which thankfully is not the case.

Cheers!

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

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

This may and has actually caused problems with ipv6 routing.

(edit:I misunderstood. It seems that sometimes when PPPoE is restarted, or under certain circumstances, the address or route obtained by its delegation will be lost (or not available))

Because I usually choose to restart the router + restart PPPoE (another problem is that if I do not restart PPPoE after restarting the router, it will not be delegated), so I ignore this problem. It's a strange problem. I don't know how to solve it for the moment.

@gadams, please describe use case where wide does not start and include config with expected result and VyOS version. Sure config can be adjusted, luckily its an open Git repo so just send a PR.

I included all the bits I thought were relevant in T421#65109 (you'll need to click "Show older changes" at this point to see it).

I'd expect a DHCPv6 client to be started, an address delegation to be requested by it from the DHCP server upstream, and then subnet assigned to the relevant other interfaces according to the specified sla-ids. But no dhcp client of any sort is running after applying that config (and fixing the typo in interfaces-ethernet.py), so naturally none of the rest of it happens.

I'd really appreciate your thoughts about it. Thanks, @c-po.

One thought I have is that my local fix to interfaces-ethernet.py might be happening too late, or something. I should just do a fresh build, or wait for the fix to appear in a daily build.

@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 Trace the problem that the system cannot automatically perform prefix delegation after restarting:

After the restart, call the following command to get the prefix assignment:

sudo systemctl start dhcp6c@pppoe0

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 。

@jack9603301 your assumptions are invalid. I have a fully reboot-save PPPoE setup. Please stop making wrong assumptions! and search the code properly!

https://github.com/vyos/vyos-1x/blob/current/data/templates/pppoe/ipv6-up.script.tmpl#L47

@gadams your mentioned problem is already fixed in the latest rolling image

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

I'm sorry to say that with the current rolling release, still no dhcp6c is started when I add the PD configuration. Here is my test config:

interfaces {
    ethernet eth0 {
        address dhcp
        dhcpv6-options {
            prefix-delegation {
                interface eth0.3 {
                    address 1
                    sla-id 3
                }
            }
        }
        duplex auto
        ipv6 {
            address {
                autoconf
            }
        }
        smp-affinity auto
        speed auto
        vif 3 {
            description TEST-VLAN
            ipv6 {
                address {
                    autoconf
                }
                dup-addr-detect-transmits 1
            }
        }
    }
    loopback lo {
    }
}

And no client is started:

vyos@vyos:~$ sudo ps -afe | grep dhc
root      1170     1  0 05:30 ?        00:00:00 /sbin/dhclient -4 -nw -cf /var/lib/dhcp/dhclient_eth0.conf -pf /var/lib/dhcp/dhclient_eth0.pid -lf /var/lib/dhcp/dhclient_eth0.leases eth0

I notice that you pointed out the code that starts dhcp6c in the pppoe templaet: https://github.com/vyos/vyos-1x/blob/current/data/templates/pppoe/ipv6-up.script.tmpl#L47. Does this indicate that there are still some pppoe-specific assumptions in the code, or is there a comparable line for other interfaces?

I'll go looking...

https://github.com/vyos/vyos-1x/blob/current/python/vyos/ifconfig/dhcp.py#L113

@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

Aha! Thanks, @c-po. As I suspected, there is an assumption in ifconfig/interface.py that the DHCPv6 client need not be started if we're not getting our address via DHCPv6, which of course is not the case, here.

Working on a fix...

Maybe we should add new methods to the Interface or DHCP class to allow starting just DHCPv6-PD without assigning an address to it? The way it's done now is by assigning an address with the value "dhcpv6" to the interface through the add/del_addr methods of Interface class. There needs to be a separate method for DHCPv6-PD without addressing (and generate a dhcpc config that doesn't assign the address, of course).

Also was ISC dhclient replaced with Wide dhcp client for all cases or just dhcpv6?

Edit: in fact thinking about it, there's no harm in starting the daemon through add_/del_addr, just that it must be configured to not assign an address in that case.

Just my input: It seems there is some confusion about what DHCPv6-PD actually is. And this reflects in the endless discussions and questions here in the thread...

To me it is simple. The configuration should reflect the fact that PD is just one of the options of DHCPv6. So, when you want to receive a prefix for delegation, but don't want an address, then just set the no-address and no-temporary options (however they are called in the config). It's still DHCPv6 in the end. Now, in practice it doesn't really matter too much if the router gets an address or not (when using PD). But ok, you are right... an option to tell VyOS not to enable the address request would be useful. In fact, DHCPv6 RFC states that the client can make any (allowed) request and the server can ignore whatever it wants to ignore... so even when an ISP only hands out prefix, requesting an address should not break anything (the router will just never receive an address, but only a prefix).

Anyway :) Glad that at least the PD is now possible in VyOS.

@tbr thanks for clarifying that, I agree. So the way to do that would be to set 'address dhcpv6' and 'dhcpv6-options parameters-only'. That is slightly confusing at first, as the combination of those 2 options shouldn't actually assign an address. I haven't tried it but that's how I expect it should work, I don't use PD currently. If it does work my comments regarding new methods in scripts are entirely unneeded.

I have sent a pull request: https://github.com/vyos/vyos-1x/pull/437

I added a new method to the Interface class to start the DHCPv6 client in these cases. I would like to have had that class be more generic, and check for itself whether the interface's IPv6 addresses are being configured via DHCP, and start itself only when not, but that information isn't available at the right time there. So I left it up to the caller to decide. But that means that there is probably another interface or two outh there that will need this treatment.

@tbr: The problem is actually somewhat the opposite, if I'm understanding you correctly (this late at night). It's that the code there to start up the DHCP client predates the addition of DHCPv6-PD, so it only starts up the DHCP client when it's configured to get its addresses via DHCPv6. That may even work if someone has configured their router to get its router-to-router address via DHCPv6 as well, but honestly that seems like a probably rare configuration. In any event, with my change, the dhcp6c daemon actually starts, now. I'll do more testing tomorrow.

@gadams have you tried the above 2 settings: 'address dhcpv6' and 'dhcpv6-options parameters-only' without your patch to see if the client doesn't assign an address in that case?

@jjakob Yes, I tried dhcpv6-options parameters-only; it had no effect. I did not try 'address dhcpv6' simply because that doesn't seem like a great configuration. But it would have been worth testing, anyway. And while that would have been good to test, it would be a pretty awkward an unexpected workaround for regular users to think of it.

But in both cases, it probably wouldn't have worked, anyway, because there is currently a bug in the configuration parsing code in configdict.py that my pull request addresses.

I see that there are other, subtle issues. For instance, in the unusual case of delegating from a native (trunk) interface to a vlan interface nested within it, dhcp6c will fail to start, because it starts before the vif is created, so its config looks invalid. (I notices that because that's how I happened to set up my test router just now.) I can fix that with a quick pull request...

Actually, it looks like that change has been automatically included in my previous pull request.

Ah, I think I see what you, @tbr and @jjakob are getting at. If I want to do DHCPv6-PD, then I need to start the daemon. But if I don't want an address using the protocol, then I can explicitly turn it off.

But this does seem confusing to the user. In order to request a delegated prefix, I'd have to tell VyOS that I want to configure the interface address via DHCPv6 ('address dhcp'), but that I don't actually want that ('dhcpv6-options parameters-only') and also that I'd like to request a prefix. A bit awkward, even if that gets the desired outcome from the perspective of configuring the daemon.

However, the user isn't configuring the dhcp6c daemon; they're configuring VyOS, and VyOS is translating that configuration into the appropriate dhcp6c.{intf}.conf file and running state. From that perspective, there are (at least) three orthogonal things that the user might want via DHCPv6:

• An address (or addresses)
• A prefix delegation (or delegations)
• Other parameters (DNS servers, etc.)

It seems best to let the user choose which of those they want, and let VyOS build the configuration that delivers it. To that end, if the user only wants a delegated prefix, they shouldn't have to know the magic of turning on getting an address but then disabling it again.

I'll think about this more overnight.

@gadams I agree it's confusing, to change the syntax isn't hard, we just have to choose the best user-friendly syntax and behavior. It can be even accomplished without changing the syntax, by:
a) if 'dhcpv6-options delegate' is set, do the same as for 'parameters-only', plus start dhclient by add_addr('dhcpv6')
or
b) start dhclient if either 'dhcpv6-parameters' or 'address dhcpv6' is set but only assign an address in the 'address dhcpv6' case, may be the simplest option.

In addition to the address, we have to think about whether to set:

• routes
• search domain
• nameservers (this is already a setting in a different place, not necessary here)

@c-po

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

systemctl start dhcp6c@pppoe0

Modify to the following command:

systemctl restart dhcp6c@pppoe0

After restarting the system, it seems that the required error reporting output has been attempted:

May 28 18:40:27 vyos dhcp6c[2222]: cfdebug_print: <3>end of sentence [;] (1)
May 28 18:40:27 vyos dhcp6c[2222]: add_pd_pif: /run/dhcp6c/dhcp6c.pppoe0.conf:20 invalid interface (br1): No such device
May 28 18:40:27 vyos dhcp6c[2222]: clear_poolconf: called
May 28 18:40:27 vyos dhcp6c[2222]: main: failed to parse configuration file

Of course, this is still the fault exploration of dhcp6c, rather than making its patches, reading and reporting errors. When dhcp6c is started to perform delegation, its interfaces br1 and br2 are not created. However, how to solve this problem? Can anyone come up with a good way?

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.

In the current situation, using automatic recovery scripts for a specific service should avoid the problem of startup failure.

@jjakob Yes, exactly my thoughts, and what my last pull request starts. I'll try to catch the remaining cases later this evening my time (in 12 hours or so). I can imagine one case that might be a little tricky.

@c-po does it make more sense to open a new task for this? Also, would you mind looking at my pull request so far? I assume you have the power to accept it.

@gadams it makes no sense to use this as a catch-all thread. New requests/bugs should go into dedicated tasks.

Also from my perspective we could indeed somehow start dhcp6 if there is no interface address dhcpv6 defined combined by some voodoo in the background - I already have an idea.

I have not merged your PR as I had the same locally but not yet pushed - it is all integrated in the latest ISO now. enjoy!

Something else I realized last night: In general, it's not safe to start dhcp6c before all interfaces are configured, as long as PD is specified (whether 'address dhcpv6' is specified). That's because the prefix-delegation stanza can refer to any other interface on the system--even ones that haven't been set up, yet. That might include vif interfaces (such as I noticed last night) or any other virtual interface, like br or tun.

What we do now is start dhcp6c while configuring an interface that has 'address dhcpv6' or 'prefix-delegation' (with my pull request). This creates the dhcp6c.{intf}.conf file, including references to other interfaces, and then starts dhcp6c immediately. When dhcp6c sees the references to nonexistent interfaces, it fails, and that causes an exception which, on boot, even halts processing of config.boot, which leaves things in a pretty inconsistent-looking state. This is pretty bad.

Is there a way to defer starting dhcp6c until all interfaces are otherwise configured?

@jack9603301 I think what you're seeing is another case of exactly this, since you're delegating to br1, which doesn't exist, yet, when pppoe0 is initially configured.

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.

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

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

Restart=on-failure

StartLimitIntervalSec=0

RestartSec=10

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

Please merge this fix.

Recovery from failures does seem generally desirable, but it would also be preferable to discover errors in configuration while in conf code. For this reason, it seems like the best way to handle this would be to defer starting dhcp6c until the very end of configuring all the interfaces, if that's possible. Is there a mechanism already to do this, or should I look into restructuring things slightly.

Also, should this be a new Task? I'll be happy to create one. I'm just not sure the established best practices, here.

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.

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.

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.

Sure, a new task would be very welcome so there's less spam in this task.
Why do you want to postpone dhcp6c startup? All the requirements and dependencies are there when the interface scripts start it. The interface is brought up before it's started. Other than waiting for a pppoe connection, yes, that would be worthwile. Each interface script has a priority so that other interfaces they depend on are configured before the one that depends on them, that's set in the priority tag in the XML definitions and done by vyatta-cfg. They're started sequentially by their priority value, not all at once.

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.

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

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

I haven't looked at how dhcp6c gets started currently. VyOS uses systemd to manage the services, but none of them should be set to enabled, they're all started manually via VyOS scripts. It's possible it's done differently in this case, I'm not going to speculate on something I don't know. I assumed it got started the same, when the interface script starts it.
On the dependency problem, I don't know how dhcp6c behaves when it's started with configured nonexistent interfaces. If it does cause a failure to start, that is an issue that needs to be fixed via another way. I'm not the implementer of this code so I'm not going to speculate on the best way to do it.

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

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.

In T421#65476, @gadams wrote:

Recovery from failures does seem generally desirable, but it would also be preferable to discover errors in configuration while in conf code. For this reason, it seems like the best way to handle this would be to defer starting dhcp6c until the very end of configuring all the interfaces, if that's possible. Is there a mechanism already to do this, or should I look into restructuring things slightly.

Configuration errors can be discovered in config mode in the verify() sectiom of each Python script.

Defer starting until the end is not possible in the current design with the Vyatta backend. dhcpc6 is started individually on a per interface basis. I have no idea how the race against a non existing bond or vlan interface could be fixed currently.

Something like an async late callback would be nice where function calls could be registered.

@c-po if the interface dependency system that @jjakob describes works as I might imagine, then perhaps it's just a matter of adding the interfaces that appear in prefix-delegation configs to the dependency lists. (There would be some subtleties dealing with things like vifs within an interface, but that can be sorted out.)

So - just to refocus for a minute...

Originally, the reason DHCPv6-PD requests weren't implemented was that dhclient didn't support the -P flag - which has now been corrected - however it looks like the implementation has become something different now. Maybe on the wide client instead?

The problem is that the PD request can only be done when an interface is up - and is verified to be up. This seems to indicate that this action can only be performed as a post-hook type way.

A long time ago, I believe I posted in my code for using dhclient on pppoe interfaces - as a workaround for them not having a DUID - and the example hook I'm using for NetworkManager to handle this in my non-VyOS install, which is handled as a post hook executed AFTER the interface is up.

There will be race conditions everywhere if this isn't handled as an action *after* the interface is completely up - including a PPPoE connection started, but not authenticated and connected.

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.

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

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

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

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

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

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

Begging for a merge will not speed things up. You multiple times refused to adopt the patch to our guidelines and it is still unclear if this is the right path to go.

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

Because the change is too small, I use the web page to submit. I may not have thought of this problem before, and I can't see how many words there are in a single line.

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

Is this new DHCPv6-PD feature supposed to be working on Ethernet interfaces?

So far I've not been able to get it to work. I've tried VyOS 1.3 rolling releases each day since it was introduced early last week.

I get IPv4 addresses but not IPv6 addresses.

See T2510 for my configuration and the results.

Is there some "trick" to it or something in the configuration I've left out?

I thought all I had to do was just turn on DHCPv6.

Thanks for any information related to getting DHCPv6-PD to work on Ethernet interfaces.

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?

Note: this problem is invalid, which is the illusion caused by my own configuration error.

@dsummers I have been able to get the current nightly builds to work on Comcast Business, which is delivered via ethernet. In this particular case, there are some unfortunate gotchas to keep in mind, but no modification of VyOS is currently needed, at least in my case. Very cool!

For anyone else who comes across this (I have talked to a couple folks outside of this task, as well), here are the gotchas, the second one of which is Comcast-specific:

• You currently need to enable getting an IPv6 address on the ethernet interface, even though that's technically not required other than by the config syntax. Using parameters-only will prevent it from working, since WIDE dhcp6c will interpret that to mean that you also don't want delegated adresses.

In my experience, this causes only some small issues, but not failure. I am drafting a proposal to fix it, but it's slightly more complex than I guessed.

• You need to know that while the Comcast cablemodem receives a /56 from the network to delegate to you, it carves off the first (sla-id 0) /64 of that for the link between it and your router, and then only delegates out of the highest (/56 4-bit sla-id f) /60 to your router. This is odd, and I don't know why they do it that way. So, you need to know that you'll be getting a /60 delegated to you, and that you should use 4-bit SLAs.

I had to figure this out by looking at the DHCPv6 conversation on the wire some time ago.

The config syntax could help a lot here, but this seems to be limited a bit by WIDE dhcp6c's conf options.

In any event, here's a working config I'm using (well, simplified, but still enough to make it work):

interfaces {
    ...
    ethernet eth3 {
        address 10.1.11.3/24
        address dhcpv6
        description OUTSIDE-v6
        dhcpv6-options {
            prefix-delegation {
                interface br0 {
                    address 1
                    sla-id 1
                    sla-len 4
                }
                interface eth2.4 {
                    address 1
                    sla-id 4
                    sla-len 4
                }
                interface eth2.6 {
                    address 1
                    sla-id 6
                    sla-len 4
                }
            }
        }
        ...
    }
    ....
}
...
    router-advert {
        interface br0 {
            name-server 2603:....
            name-server 2603:....
            prefix ::/64 {
                valid-lifetime 2592000
            }
        }
    .... and so on for the other interfaces ...

(The address 1 bits aren't strictly necessary, but I like my routers having easily recignizable addresses when I'm looking over traffic flows and routes and so on.)

Happy v6 surfing!

@gadams Thanks for your reply.

I tried the latest (vyos-1.3-rolling-202006050117) and I still can't get an IPv6 address.

Could you take a look at my configuration in T2510 and see if you see any problems with it?

I can use vyos-1.2.5 and it correctly gets an IPv6 address, but vyos-1.3 won't get an IPv6 address.

Thanks!

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

@jack9603301 As stated a couple of times above, please see T2510 for my configuration.

In T421#66055, @gadams wrote:

@dsummers I have been able to get the current nightly builds to work on Comcast Business, which is delivered via ethernet. In this particular case, there are some unfortunate gotchas to keep in mind, but no modification of VyOS is currently needed, at least in my case. Very cool!

For anyone else who comes across this (I have talked to a couple folks outside of this task, as well), here are the gotchas, the second one of which is Comcast-specific:

• You currently need to enable getting an IPv6 address on the ethernet interface, even though that's technically not required other than by the config syntax. Using parameters-only will prevent it from working, since WIDE dhcp6c will interpret that to mean that you also don't want delegated adresses.

In my experience, this causes only some small issues, but not failure. I am drafting a proposal to fix it, but it's slightly more complex than I guessed.

• You need to know that while the Comcast cablemodem receives a /56 from the network to delegate to you, it carves off the first (sla-id 0) /64 of that for the link between it and your router, and then only delegates out of the highest (/56 4-bit sla-id f) /60 to your router. This is odd, and I don't know why they do it that way. So, you need to know that you'll be getting a /60 delegated to you, and that you should use 4-bit SLAs.

I had to figure this out by looking at the DHCPv6 conversation on the wire some time ago.

The config syntax could help a lot here, but this seems to be limited a bit by WIDE dhcp6c's conf options.

In any event, here's a working config I'm using (well, simplified, but still enough to make it work):

interfaces {
    ...
    ethernet eth3 {
        address 10.1.11.3/24
        address dhcpv6
        description OUTSIDE-v6
        dhcpv6-options {
            prefix-delegation {
                interface br0 {
                    address 1
                    sla-id 1
                    sla-len 4
                }
                interface eth2.4 {
                    address 1
                    sla-id 4
                    sla-len 4
                }
                interface eth2.6 {
                    address 1
                    sla-id 6
                    sla-len 4
                }
            }
        }
        ...
    }
    ....
}
...
    router-advert {
        interface br0 {
            name-server 2603:....
            name-server 2603:....
            prefix ::/64 {
                valid-lifetime 2592000
            }
        }
    .... and so on for the other interfaces ...

(The address 1 bits aren't strictly necessary, but I like my routers having easily recignizable addresses when I'm looking over traffic flows and routes and so on.)

Happy v6 surfing!

I'm trying to get this working with Comcast residential. I've used your exact configuration (I believe) except for the fact that I'm using my cable modem in bridge mode so I'm using "address dhcp" in place of your "address 10.1.11.3/24". I'm wondering if there is any other configuration you might have that you haven't listed that could account for why things work for you and don't work for me?

Also, when you look at your interfaces what exactly do you see? I assume your WAN interface has both a /128 ipv6 and a /60 ipv6 assigned to it (both <global>)? In my case I only see the /128. I don't see any <global> ipv6 range assigned to my LAN interface where I was expecting to see the /64 there. Is that correct?

Thanks for your help!

I seem to have figured out my problem. It seems like setting "set interfaces ethernet eth1 dhcpv6-options prefix-delegation length 60" is not working (eth1 is my WAN interface that's connected directly to my cable modem in bridge mode).

I found the auto-generated dhcp6c.eth1.conf and noticed that the "id-assoc pd 2" section did not have the prefix length hint section in it. I went ahead and edited the file and added "prefix ::/60 infinity;" to that section and then did a "renew dhcpv6 interface eth1" and my ipv6 started working network-wide.

Now I'm not sure if this is a bug that the prefix length hint configuration isn't working or if I'm just using it wrong?

Richardpowellus: I may be running into the same issue. What does your
id-assoc pd 2 { } section look like?

EDIT: A followup.

This configuration *should work*, and would, if my Comcast modem didn't have a very specific bug/misbehavior/brokenness. Static IPv4 and DHCPv6-PD is *broken* on Comcast CGA4131COM model modems. The modem forgets it delegated the prefix and simply drops packets coming from within that prefix.

@richardpowellus I've noted the exact same issue in T2551.

I think that's the only thing holding me off from being able to use this new feature.

Thanks for the clue of "renew dhcpv6 interface ethX". I'll try that and see if that enables me to further my testing.

Fixed in the rolling release from 20200606xx

@richardpowellus Yes, your work around fixed my problem and I'm now for the first time able to receive a /56 from my ISP and divvy it up between my interfaces.

@c-po fixed T2551 and I expect the next rolling release to have that fix in it and so therefore should fix this issue.

Thanks everyone! I'm very excited to now to get 1.3 stabilized and out the door for production work!

T2551 has now been fixed and confirmed working.

THANKS!

What was the reason for choosing WIDE dhcp6c and not keeping isc-dhcp? This has now caused T2590 which will require making a new set of dhclient scripts just for WIDE, so we'll be maintaining 2 separate scripts. If it was due to the support for prefix length hint, isc-dhcp has added that too, as I mentioned in this task before https://phabricator.vyos.net/T421#49842

Also the man page mentions this:

BUGS
is incomplete and violates DHCPv6 protocol spec, in several aspects. In particular, temporary address assignment is intentionally omitted.

Information Refresh Time Option is not recognized in Info-req mode, since terminates after it receives a REPLY message.

I imagine isc-dhcp is protocol compliant.

The purpose of choosing wide-dhcpv6 is to achieve DHCPv6 PD.

For details, you can ask @c-po.

@jack9603301 you're not the one that made the choice so you can't know why it was made.
ISC-DHCP can do prefix delegation too (not by itself, but with a helper script that others already made: https://wiki.debian.org/IPv6PrefixDelegation ) so that's not why WIDE was chosen.

@jjakob it was only choosen as it prooved to be "more simple" compared to ISC and that helper script. I have no affiliation with either implementation. I was not aware that it could cause other issue. If you need to change it to ISC you're free to go.

I have no need for PD for now, so this isn't an important issue for me. I just noticed that WIDE didn't run any scripts, so right now it can't set any nameservers obtained from DHCP. If anyone needs that, I guess it would be simplest to write a script (by using the existing dhclient-script hooks as a guide) just for vyos-hostsd, since PD is already done with WIDE. Switching to ISC would mean we'd need to improve that PD script I linked to, since it only supports a single interface, and we need multiple.

In the long run I'd prefer if the switch to ISC was made, not just for the standards compliance (as the WIDE dhcp6c man page mentions). The config syntax is now established so I imagine it wouldn't be that hard to switch backends, just time and work...

A config Syntax is always migratable. Wide also supports scripts, but ISC PD (as I‘ve seen it, and interpret it) seems to have some rough edges. If you find a guide I will definately have a look.