Page MenuHomePhabricator

VyOS lacks DHCPv6-PD (Prefix delegation) length / IA_PD support
Open, NormalPublicBUG

Description

Original bug filed by compaq963 on 2013-12-31 in Bugzilla, copied here so that it doesn't get lost/forgotten (will also copy in comments):

It would be great to see Prefix delegation support in VyOS. Prefix delegation is needed for IPv6 with many ISPs because this is how they hand out prefixes.

Also, It would be great to allow you set a custom IA_PD prefix. An example is my ISP will hand out a /60 to you with a custom IA_PD prefix. If you just accpet the default you get a /64.

One solution is using WIDE-DHCPv6. The project page is at http://wide-dhcpv6.sourceforge.net/

Details

Difficulty level
Hard (possibly days)
Version
1.1.x
Why the issue appeared?
Will be filled on close

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Comment by Ryan Holt posted on 2014-09-02:

Would love to see this added as well.

Comment by @dmbaturin on 2014-10-07:

Not right now, but probably soon.

Comment by @beamerblvd on 2015-03-03:

Yes, I need this badly. I didn't realize until I found this bug that this feature was missing from VyOS–I've been looking for it. I don't know whether it'll matter much, but Ubiquity Networks' EdgeMax fork of Vyatta (a VyOS "competitor") has already added support for DHCPv6-PD, which means it's already ahead of VyOS (and I'd sure prefer to stick with VyOS).

As it stands right now, it appears I have a choice between switching to EdgeMax (if I can) or not having full IPv6 support (Comcast uses DHCPv6-PD).

As a good starting place, https://community.ubnt.com/t5/EdgeMAX/IPv6-DHCPv6-and-DHCPv6-PD/td-p/1115361 has some sample configuration for how DHCPv6-PD might work.

I'd love to do what I can to help get this implemented ASAP, but C/C++ is one of my weaker areas and I wouldn't know where to begin taking code changes I've made on my git clones and applying them to my router for testing. I'm happy to take suggestions from the PTB on ways I could make this happen faster.

Comment by @beamerblvd on 2015-03-05:

I understand that there are good arguments either way, but after much frustration, research, troubleshooting, TCP dumping, and debugging, I'd like to propose that this issue be converted from an "enhancement" to a major defect. Here's my well-thought-out reasoning:

Comcast, it turns out, supports either DHCPv6 _or_ DHCPv6-PD depending on what your router requests. If your router requests DHCPv6-PD, Comcast will assign a /128 in a /64 subnet to the WAN interface and delegate a /60 (for sixteen /64 subnets) for you to use on your LAN. If, however, your router only requests DHCPv6, Comcast will only assign it a single /128 in a /64 subnet. This has the effect of making it impossible to get more than a single IPv6 address for your entire network on Comcast if you don't request DHCPv6-PD, and that applies to both residential and business class accounts because Comcast doesn't yet offer static IPv6 delegations.

VyOS does not yet support DHCPv6-PD, so the ultimate outcome is that VyOS is unusable for IPv6 on Comcast. If you can only get a single IPv6 address, it's impractical (arguably impossible) to use IPv6 for a fully-dual-stack network. This is very unfortunate as it makes VyOS unusable for IPv6 on the largest ISP in the country.

Comment by Kouak on 2015-03-05:

If you can manage to produce a valid isc dhcp client configuration file, I guess we easily tweak the VyOS CLI to make it work.

beamerblvd added a comment.EditedOct 11 2017, 6:51 PM

Comment by @beamerblvd on 2015-03-06:

The version of ISC currently in VyOS does not support DHCPv6-PD. More recent versions _do_ support it, to an extent. The newer versions still don't support breaking up a /60 (for example) and assigning it to inside interfaces, so significant script work is required to find the logged prefix information and assign it to inside interfaces. Ubiquity Networks (EdgeMax) realized this and, instead of trying to get ISC's inferior client to work, dumped ISC's dhclient in their fork of Vyatta and replaced it with wide-dhcpv6-client. wide-dhcpv6-client fully supports all aspects of DHCPv6-PD, including breaking up prefixes and assigning subnets to other interfaces. This is what we need.

I attempted to research and hack at it for several hours and came to the conclusion that there is no possibility, at this time, of creating a working ISC config file for DHCPv6-PD. If ISC is chiseled in stone, significant work is required in VyOS to make it work—more work than I even know what to do with. If ISC can be replaced with wide-dhcpv6-client in VyOS, it appears that it will be _much_ simpler to get DHCPv6-PD working. Additionally, it also appears that wide-dhcpv6-client should be a fairly seamless drop-in replacement for everything for which we are currently using ISC's dhclient.

References:

https://community.ubnt.com/t5/EdgeMAX/IPv6-DHCPv6-and-DHCPv6-PD/td-p/1115361
http://www.ipcalypse.ca/?p=204
http://serverfault.com/questions/585405/dhcpv6-passing-delegated-prefix-to-local-ra
https://archive.mgm51.com/sources/pd-pref.html
https://lists.isc.org/pipermail/dhcp-users/2012-July/015720.html
https://lists.isc.org/pipermail/dhcp-users/2010-November/012703.html

Comment by Kouak on 2015-03-18:

ISC isn't able to assign a prefix to an interface as far as I know but is able to send a proper PD request.

Could you try to run isc-dhcp client with -P flag and paste the output of /var/lib/dhcp3/dhclient_v6_INTERFACE.leases ?

beamerblvd added a comment.EditedOct 11 2017, 6:52 PM

Comment by Aaron Von Gauss on 2015-03-27:

DHCPv6-PD support really has three aspects in my opinion:

  1. Sending the prefix delegation request - ISC DHCLIENT can do this. You had asked this of Nick, but here is a sample /var/lib/dhcp3/dhclient_v6_eth1.leases file with the "-P" option specified (using the VyOS-livecd-1503270000-1cc1084-amd64 dev image).
default-duid "\000\001\000\001\034\247\231'\016qp\000\000\001";
lease6 {
  interface "eth1";
  ia-pd 70:00:00:01 {
    starts 1427430885;
    renew 172643;
    rebind 276228;
    iaprefix 2601:3:100:a1c::/64 {
      starts 1427430885;
      preferred-life 345286;
      max-life 345286;
    }
  }
  option dhcp6.client-id 0:1:0:1:1c:a7:99:27:e:71:70:0:0:1;
  option dhcp6.server-id 0:1:0:1:15:55:76:92:84:2b:2b:fe:ab:d4;
  option dhcp6.name-servers 2001:558:feed::1,2001:558:feed::2;
}
  1. The second aspect is being able to send a prefix hint in the delegation request to control the size of the prefix sent back by the server. ISC DHCLIENT I believe still does not officially have a supported mechanism for doing this. Someone has created a patch for ISC ( https://archive.mgm51.com/sources/pd-pref.html ) to do this, but I don't think its been accepted.
  1. Third, being able to do something useful with the delegated prefix. A lot of this will be subjective since VyOS is used in a variety of different ways in many different types of environments I would imagine. I think this last aspect is what really drove projects to use alternate implementations such as wide dhcp. Some will want to automagically assign relative prefixes to other interfaces while others just need the delegation performed.

Comment by @darkdragon-001 on 2015-04-19:

Would love to see this implemented!

Comment by @dmbaturin on 2015-05-03:

EdgeOS people say WIDE PD client is not quite production ready.
Moving to the next branch for now.

Comment by Aaron Von Gauss on 2015-05-03:

That's a strange position for EdgeOS to take, considering I am having to use an EdgeOS device to supplement VyOS's lack of DHCPv6-PD support.

Comment by Steve Froelich on 2015-08-21:

I want to add my support to Nick's call to address this issue.

VyOS is too important of a tool to lack native IPv6 support from Comcast.

if the quickest path forward is to use wide-dhcpv6client in VyOS, that seems the best recommendation. VyOS should work at least as well as Ubuiquity.

Has any progress been made?

Comment by Jeremy Church on 2015-08-24:

I believe support for both client and server side prefix delegation is a critical component of any router. IPv6 is still ramping up, but as more networking professionals look into IPv6 implementation, IPv6 prefix delegation could easily become an important component in any large network.

I have written much native perl code specific to IPv4 and IPv6 networking. I use it for my own purposes, but would be willing to extend what I have as needed and incorporate the code into VyOS if it helps the implementation of DHCPv6-PD and IA_PD. If I knew how to use git properly, I may have already attempted to do just that.

There are many features surrounding DHCPv6 that would add value to VyOS, but I do not know how to go about adding those features. Though I am not a developer, I am in networking and love the concept of VyOS.

This is my first comment, so please excuse any errors in submission.

Comment by Patrick van Staveren on 2015-09-25:

I might be able to take on this work. My new ISP does dual stack and supports PD; I'm currently working on fixing PPPoE IPv6 first.

Comment by Jason Nadeau on 2015-09-27:

I am using the built in ISC client in VyOS 1.1.5 to ask for IPv6 Prefix Delegation. It does gather a prefix from my ISP (Time Warner Cable) but as others have said this does not get assigned to my "private" interface on the VyOS router. I am willing to put work in concert with someone with more experience in creating CLI elements so we can do this from VyOS configuration rather than native linux.

According to the man on dhclient "Note: it is not recommended to mix queries of different types together or even to share the lease file between them." So I run two copies of dhclient one for normal address query and another for prefix delegation. I don't know if that is the correct way to do it, but it works for me with some bugs. The primary bug is that which ever dhclient is started last appears to be the only one that will renew it's DHCP lease. So if my IPv6 normal query runs last then my router "outside" interface will continue to renew the address while the prefix lease will eventually expire without renewal. This leads to my ISP dropping the route for my prefix with next hop of my outside address. In reverse my prefix will continue to be leased but my "outside" address will not be renewed and will expire. This bug I addressed by restarting both dhclient processes with cron on Wednesday mornings. This is not an ideal solution, but works for me because my ISP lends addresses for 8 days.

Here are my dhclient start commands and settings.

# Prefix request with own conf, lease, and pid file
/sbin/dhclient -6 -P -nw -cf /var/lib/dhcp3/dhclient_v6_eth0-P.conf -pf /var/lib/dhcp3/dhclient_v6_eth0-P.pid -lf /var/lib/dhcp3/dhclient_v6_eth0-P.leases eth0

# Prefix request conf file

vyatta@vyatta:~$ cat /var/lib/dhcp3/dhclient_v6_eth0-P.conf
# This file was auto-generated by the Vyatta
# configuration sub-system.  Do not edit it.

#   Generated on Wed Jul 29 14:52:25 2015 by root
#
interface "eth0" {
}


# Prefix request lease file

vyatta@vyatta:~$ cat /var/lib/dhcp3/dhclient_v6_eth0-P.leases
default-duid "\000\001\000\001\035 t\355\000\001\300\010\237g";
lease6 {
  interface "eth0";
  ia-pd c0:08:9f:67 {
    starts 1442988302;
    renew 193741;
    rebind 309985;
    iaprefix !!REMOVED!!::/64 {
      starts 1442988302;
      preferred-life 387482;
      max-life 387482;
    }
  }
  option dhcp6.client-id 0:1:0:1:1d:20:74:ed:0:1:c0:8:9f:67;
  option dhcp6.server-id 0:1:0:1:17:4:95:13:0:50:56:9d:0:68;
}








# IPv6 request, built by VyOS with "set interfaces ethernet eth0 address dhcpv6"
/sbin/dhclient -6 -nw -cf /var/lib/dhcp3/dhclient_v6_eth0.conf -pf /var/lib/dhcp3/dhclient_v6_eth0.pid -lf /var/lib/dhcp3/dhclient_v6_eth0.leases eth0

# Normal address configuration file

vyatta@vyatta:~$ cat /var/lib/dhcp3/dhclient_v6_eth0.conf
# This file was auto-generated by the Vyatta
# configuration sub-system.  Do not edit it.

#   Generated on Fri Sep 25 23:33:55 2015 by root
#
interface "eth0" {
}


# Normal address lease file

vyatta@vyatta:~$ cat /var/lib/dhcp3/dhclient_v6_eth0.leases
default-duid "\000\001\000\001\034\366@\262\000\001\300\010\237g";
lease6 {
  interface "eth0";
  ia-na c0:08:9f:67 {
    starts 1442876930;
    renew 206514;
    rebind 330423;
    iaaddr !!REMOVED!! {
      starts 1442876930;
      preferred-life 413029;
      max-life 413029;
    }
  }
  option dhcp6.client-id 0:1:0:1:1c:f6:40:b2:0:1:c0:8:9f:67;
  option dhcp6.server-id 0:1:0:1:17:4:95:13:0:50:56:9d:0:68;
}

Comment by Brett Lykins on 2015-09-28:

Jason,

As you can see in your Lease file, you're still only getting a /64 from your provider.

At issue here, is the ability to request a larger prefix (/56 for example) and chop it out into /64's inside your network.

As outlined by Aaron on 2015-03-27, there are three key components to what this request entails:

  1. Being able to send IPv6-Prefix Delegation messages (ISC's client CAN do this).
  1. Being able to specify the values of the PD message (ISC's client CAN NOT do this), as outlined in RFC 3633 Section 10 [http://tools.ietf.org/html/rfc3633#section-10] this should be a common function. This is where people have looked at Wide-DHCPv6 and other packages that have this capability. Please see this article by Major Hayden for some more detailed information on getting Wide-DHCPv6 to do this: https://major.io/2015/09/11/time-warner-road-runner-linux-and-large-ipv6-subnets/
  1. Being able to then somewhat-automatically divvy up the delegated prefix into smaller prefixes for the "Internal" interfaces (radvd can take care of the advertisements, but it is still a manual configuration).

This is the last major blockage to me personally moving from a Cisco router on the edge to VyOS. Both Comcast and Time Warner (major ISPs in the US) are utilizing this method for distribution of IPv6 addresses to their customers, so we can't really ignore it too much longer.

For comparison and more context for what we're discussing, here's the same functions in Cisco IOS parlance. Note the following:

  1. I specify a PD Hint prefix size and assign it a meaningful name on the interface facing my ISP.
  2. I then use this same named entity to carve out subnets for the interior networks.
  3. RA's are automatically sent out on the interior interfaces once an IPv6 address is configured on the interface.
interface g0/0/0
 description TWC-SAN-ANTONIO
 !
 ! Get a DHCPv6 address for this interface
 ipv6 address dhcp
 !
 ! Auto-configure default route for IPv6
 ipv6 address autoconfig default
 !
 ! Enable IPv6 on the interface
 ipv6 enable
 !
 ! Send PD hint size of /56
 ipv6 dhcp client pd hint ::/56
 !
 ! Assign the delegated prefix a name of "twc-prefix"
 ipv6 dhcp client pd twc-prefix


interface g0/0/1
 description INSIDE
 !
 ! Assign a subnet and an address to this interface using the newly delegated prefix
 ipv6 address twc-prefix ::/64 eui-64
 !
 ! Enable IPv6 on the interface
 ipv6 enable

interface g0/1/0
 description DMZ
 !
 ! Assign a subnet and an address to this interface using the newly delegated prefix
 ipv6 address twc-prefix 0:0:0:1::/64 eui-64
 !
 ! Enable IPv6 on the interface
 ipv6 enable

It seems to me there are two options to resolve this issue.

  1. Hack in our own fixes to the ISC client and contribute them upstream.
  2. Switch to another DHCP client for IPv6 only.

Being new to the community, I'm not sure what the feasibility of these or our preference between the two options would be. I'll pop up in the IRC channel on Freenode and see if this is something I can stir up.

Thanks!

Comment by Daniel Corbe on 2016-01-12:

There is a third option for a DHCPv6-PD client that isn't WIDE or ISC.

http://roy.marples.name/projects/dhcpcd/index

beamerblvd added a comment.EditedOct 11 2017, 7:04 PM

The above completes the migration of content and all comments for Bugzilla issue 112.

Note the relevant mailing list archive:

https://www.mail-archive.com/vyos-developers@lists.tuxis.nl/msg00108.html

Also note this official knowledge base article from ISC:

https://kb.isc.org/article/AA-01141/0/How-to-workaround-IPv6-prefix-length-issues-with-ISC-DHCP-clients.html

This makes it clear that they have no intention of supporting prefix length any time soon, making the stock ISC client a non-viable option for standards-compliant routers. We will either need to update-and-patch our fork of the ISC client, or we will need to switch our DHCP client entirely.

In my opinion, this bug is extremely critical. It makes VyOS unusable for IPv6 purposes on the largest broadband internet service provider in the United States: Comcast.

darkdragon-001 mentioned this in Unknown Object (Ponder Answer).Oct 12 2017, 11:52 AM
syncer added a subscriber: syncer.Oct 12 2017, 6:43 PM

Thanks for transfering this.
it looks like good candidate
https://packages.debian.org/jessie/dhcpcd5
@dmbaturin already looked at it last year, but it seems it was without pd support than
Now, however, it looks like they added support for it and we maybe should consider it as main candidate

@syncer, yep, looks like that is the Deb package for https://roy.marples.name/projects/dhcpcd. This is the client that Daniel Corbe and I had recommended be switched to.

I actually started work switching VyOS from ISC to DHCPCD back in 2015, but I had to abandon my efforts when I got really down into the weeds and realized I no longer had any idea which VyOS systems I was affecting with my changes. It's just too involved of a task for someone not very familiar with the VyOS source code to work on.

I want to stress again how critical I think this lack of functionality is. As mentioned above, IPv6 is not mainstream rather than experimental, and you still can't use it with Comcast through VyOS, which is a huge problem, IMO. As someone who has frequently contributed to OSS, I recognize that, if I feel that strongly about it, I should be willing to put in the effort to fix it. And I have surely tried, I just got hopelessly lost. I just don't think it's feasible for someone who isn't a VyOS veteran to work on.

This is definitely very important. I'm on AT&T UVerse, and I can't plausibly use VyOS for my network without support for DHCPv6-PD. I don't even need auto-configuration of RAs on the LAN ports if that would be difficult, but I at least need the support to request the prefixes in order to get them routed to my internal router.

Does "set nat nptv6" not work for you? You can configure your inside interface with a private /64 block, then prefix translate that to the /64 obtained set nat nptv6 rule 10 inside-prefix

via dhcpv6 from your isp. The only issue is you need to reconfigure if the dhcpv6 block changes.

We could possibly add something like "set nat nptv6 rule 10 outside-prefix dhcpv6" to have vyos automatically change the nptv6 config when the dhcpv6 address renews.

@carl.byington Works great for outgoing connections, but isn't sufficient for hosting services behind a VyOS router from what I understand, as it needs to request the prefix over DHCPv6-PD for my gateway to know to route incoming packets to it.

I don't have a setup to test this, but it seems that if it works at all for outgoing connections, it should also work for incoming connections. Suppose you have been assigned external::1111/64 as your ipv6 address, and you have an internal network running on internal::/64, with nptv6 converting from internal::/64 to external::/64. Now a machine on internal::1234 will appear to be external::1234, and your router will send the outgoing packets to the external gateway. But when the response packets come back, the ISP will need to do neighbor discovery to find your external::1234. If that works at all, it should also work for incoming connections.

So, one thing to note: Comcast doesn't give you a /64 at the very beginning (I didn't understand this fully at the time this was originally reported/discussed). It gives you a /128 (one address). You can then ask for a prefix of any size from a /64 to a /60, and it will give it to you. If you don't ask at all, it won't give you anything. If you ask for a prefix, but without a prefix length, it will give you a /64. (I'm not refuting anything said here; just making sure everyone understands how these are assigned.)

At the time I was actively struggling with this, I tried natv6. It did not work. I do not know whether this was because of Comcast or VyOS (I suspect VyOS). There weren't errors; I just couldn't reach the outside world, and I couldn't figure out why. It's possible there's something here that VyOS could fix, but let's be clear: NATv6 is a controversial technology, because many (like me) don't believe it should even exist. NAT was created due to the limited set of available IPv4 addresses. This is not an issue with IPv6, and there should be no NATv6 (in my opinion and in the opinion of many others; however, I do not object to VyOS supporting it, since it does exist). DHCPv6-PD is the correct way to deal with this, and it should be supported fully.

@carl.byington It works for incoming response packets, but nothing on the outside can initiate connections as far as I'm aware. Hence, my webserver would be inaccessible.

@beamerblvd While slightly tangential, I would like to point out that regardless of your opinion of "traditional" NAT, (single external IP, multiple internal IP) NPTv6 makes a LOT of sense for anyone that wants to host services like DNS or web (even just internally) but is on an ISP that doesn't offer static prefixes. It has no issues that I'm aware of past the slight complication of configuration for a network admin, everything good about IPv6 still works with it. (Like the privacy extensions)

oddboy added a subscriber: oddboy.Nov 14 2017, 10:03 PM
syncer triaged this task as Normal priority.Dec 21 2017, 9:37 PM
swerth added a subscriber: swerth.EditedMay 18 2018, 6:53 PM

As promised on #vyos here is an description about how to implement DHCPv6-PD on OpenBSD v6.3 amd64 with XS4ALL as ISP. I am willing to test changes done in VyOS to make this work. Also I am willing to answer questions about my setup. As this is a private project, testing and answering will be primarily done at weekends. I have at my home a FTTH connection from XS4ALL. The purpose of the here described process is to tell XS4ALL that my network is willing to process IPv6 packets so that IPv6 can enable a route to my IPv6 subnet in their routing table. XS4ALL tells me my IPv6 subnet and prefix at their website. This information is needed during this process. XS4ALL has given me an plain Modulater-Demodulater (MoDem) also called a media converter. This modem converts the fiber to ethernet and nothing more. Here is the process on OpenBSD v6.3 to setup an IPv4 and IPv6 enabled connection with XS4ALL.

In my network I got the following interfaces:

WAN = em3
LAN = em0
DMZ = em1
  1. Enable routing in sysctl.conf:
net.inet.ip.forwarding=1
net.inet6.ip6.forwarding=1
  1. Bring em3 administratively up
  2. Create an 802.1Q VLAN with em3 as parent.
  3. Create an PPPoE interface with the previously created VLAN interface as parent.
  4. Your IPv4 setup is done.
  5. Install DHCPCd
  6. Let the pppoe0 interface request over ICMP an link-local (fe80::/10) address and default gateway in the link-local address space.
  7. Add the following lines to the firewall config in pf.conf:
wan_if = "pppoe0"
lan_if = "em0"
dmz_if = "em1"

pass out quick on $wan_if inet6 proto udp from port 546 to port 547
pass in quick on $wan_if inet6 proto udp from port 547 to port 546
pass quick on {$lan_if, $dmz_if} inet6 proto icmp6 
pass quick on $wan_if inet6 proto icmp6 from any to any

The first two passing gules enable the DHCP-PD traffic. The last two rules enable the request of link-local addresses with ICMPv6.

  1. Now it's time to configure DHCPCd. Here is dhcpcd.conf:
noipv6rs
ipv6only
persistent
nohook lookup-hostname, resolv.conf
allowinterfaces pppoe0

interface pppoe0
iaid 1
ia_pd 2

These config requests through pppoe0 an IPv6 lease by XS4ALL. It does nog configure any public routable IPv6 addresses. DHCPCd should be started at boot.

  1. The em0 and em1 interfaces get a static IPv6 address assigned.
  2. Then I enable RTADVd at the em0 and em1 interfaces and let RTADVd be started at boot.
  3. Here is rtadvd.conf:
em0:\
        :addrs#1:addr="2001:????:????:0::":prefixlen#64:rltime#1800:tc=ether:
em1:\
        :addrs#2:addr="2001:????:????:1::":prefixlen#64:rltime#1800:tc=ether:

RTADVd is not relevant for XS4ALL and could easily be replaced with an IPv6 server at the LAN and DMZ side.

Hope this helps the devs to add DHCP-PD in VyOS. And as said, I am willing to help and test.

oddboy added a comment.Sep 8 2018, 8:44 PM

my ISP supports PD, and I'm also willing to test. Can't help too much on the coding side. I'd love to have PD working.

badboy added a subscriber: badboy.Sep 30 2018, 6:01 PM
pasik added a subscriber: pasik.Oct 1 2018, 9:53 AM
gadams added a subscriber: gadams.Oct 17 2018, 4:30 AM

A long time ago (before Oct 2016) I built Roy Marples' dhcpcd and hacked
/opt/vyatta/etc/config/scripts/vyatta-postconfig-bootup.script to install, configure, and start it up. I've been running with this config for over two years, and it's pretty stable. I'd love for this to be built into VyOS, rather than a local config hack.

My dhcpcd.conf is very similar to what swerth posted back in May (but with more details, since I have a number of internal IPv6 subnets), so it's really not very complex. The trick is really just associating each prefix with a network interface, and that should be a reasonably easy matter of config parameters.

I am a software engineer, but I'm not really familiar with how things are implemented in VyOS. I can probably help if someone points me in the right direction for each of what I imagine are the necessary steps:

  • Adding dhcpcd to the build configuration so that the binary is built and included in the OS image
  • Working out how all the existing configuration knobs for VyOS's configuration of ISC's client would map to configuration in /etc/dhcpcd.conf
  • Arranging for dhcp client configuration to start dhcpcd instead of ISC's client
  • Extending the existing configuration syntax to support the new DHCPv6-PD features
  • Eventually removing ISC's client

Is any of this documented?

did some dirty "hacking" to get this working for myself. I use Cogeco in Canada, and I can get *either* a dhcpv6 lease on my outside interface, *or* a /56 prefix delegation.

https://github.com/oddboy/vyos-cogeco-ipv6

These scripts and dirty, crappy, ugly, whatever you want to call it, but it works OK for me.

Feel free to take/modify/fix/make better if you find a use for these.

That's very interesting. Thanks for sharing.

(I think that instead of rewriting config.boot, your scripts should just update the interface addresses. Also, as you noted, it should be done via dhclient hooks.)

But the key to what you've done is to look in the leases file to find the delegated network, and then you apply that to the internal interfaces yourself. This works around the lack of support in the ISC dhcp client for making use of the delegated prefix. That's clever. I wonder how much we can rely on the exact format of the leases file over time, though, or if there's a different officially supported way that we should be obtaining the delegation. (It seems like there should be a supported way to get it--otherwise why would there be a mechanism to request a delegated prefix?) Maybe the lease file is it.

The main thing that seems to be missing is a way to specify how the delegated prefix is to be carved out and apportioned to any of the various attached interfaces. But that will need to be specified in the VyOS config, in any event, so it could just be read from the config and applied whenever the delegation changes. The same VyOS configuration syntax would work both for this method of pulling the delegated prefix out of the leases file and distributing portions of it amongst interfaces and for specifying the distribution policy to Roy Marples' dhcpcd.

I'm going to have to look into this idea a bit more...

Aha! Looking into it a bit more, the hook scripts are given the environment variables new_ip6_prefix and old_ip6_prefix, so that's where we should get the delegated prefix (and remove an old one, as appropriate). So, all we need to do is add some configuration settings to request PD and to indicate a subnet number within the delegated prefix to assign out to any desired interfaces. Then, it's a simple matter of exit-hook scripting to set this all up.

I think this task just got a lot easier! I'll hack on it soon and come up with a proposal for the config syntax. Presumably, it should look a lot like the Ubiquiti dhcpv6-pd syntax, unless anyone has reasons to do it differently.

@gadams, now you're really making me look lazy!

(ok, it's true :)

Glad this was helpful. Excited to see the capability added to Vyos!

gadams claimed this task.Nov 27 2018, 5:03 AM

Hey, laziness is a programmer virtue, remember!

I'm hacking on the config language right now. It'll take more than one evening, because I have a lot to learn about some of the VyOS internals, but I think we have all the pieces we need, now.

Thanks a lot for the kick in the right direction!

oddboy added a comment.EditedNov 27 2018, 4:43 PM

I've also started to hack a bit on configuring dhcpd on my router(s) so that upon delegation or update of a prefix delegation, I can re-configure dhcpd to provide delegated prefixes to other devices on my network as I have a few routers "inside" my network, and I'd like all devices to get addressed with proper v6 addresses.

So far, I'm having trouble with getting the vyos commands to work to create the delegation scope, but I have it working if I write the /opt/vyatta/etc/dhcpdv6.conf file myself.

Not sure if this capability belongs here, or on it's own thread... but basically, using the scripts I posted on github, I'm taking a /64 out of my /56 and carving it into /79's. Then, I update the dhcpdv6.conf file with Start and End networks and the subnet mask, as:

# This file is auto-generated by the Vyatta configuration sub-system.
# Do not edit it by hand.
# Auto-generated by: root
# Auto-generated on: Mon Nov 26 21:10:04 UTC 2018
#

subnet6 2001:1970:4d26:c900::1/128 {
        prefix6 fd30:fbac:1c6e:12fd:: fd30:fbac:1c6e:12fd:001e:: /79;
}
# subnet6 section added by hand
# prefix6 addresses added from RFC 4193 "almost unique" v6 addresses as part of proof of concept.  Eventually, these will be created from a /64 out of the delegated /56 network.

...but I have to do this by hand in a hacky way...

anyway, i'll update the github scripts when I have it sorted -- though I'm sure Geoff will have a more elegant solution to this problem (if it is a required / desirable feature).

OK! I'm happy to say that I have prefix delegation working with ISC dhclient, now, using a dhclient exit hook to collect the delegated prefix and farm out chunks of it to local interfaces. Now I'm tnhinking about the configuration syntax.

Ubiquiti EdgeOS does it using a separate dhcpv6-pd node within the interface, a peer of the dhcpv6-options node. That makes sense, but it might be slightly confusing to have the dhcpv6 client options spread among both of those and the address dhcpv6 node. (It's reasonable to request temporary addresses and to set the duid, both of which are in dhcpv6-options, when using dhcpv6-pd.) But it's already spread between two nodes, now, so this is probably fine.

I think the configuration language can support pulling the relevant bits together to start up the dhclient daemon appropriately, so this should really be a matter of how we want the configuration to look. Here's how the dhcpv6-pd configuration might look:

interfaces {
  ethernet eth0 {
    ...
    description WAN
    dhcpv6-pd {
      interface eth1 {
        host-address ::1
        sla-id 1
        prefix-length 64
      }
      interface eth2 {
        host-address ::1
        sla-id 2
        prefix-length 64
      }
      prefix-length 60
    }
    ipv6 {
      address {
        autoconf
      }
  }
  ethernet eth1 {
    address 172.16.1.1
    description LAN1  
    ipv6 {
      router-advert {
        prefix ::/64
      }
    }   
  }
  ethernet eth2 {
    address 172.16.2.1
    description LAN2     
    ipv6 {
      router-advert {
        prefix ::/64
      }
    }   
  }
}

Does that seem reasonable?

I have now implemented the syntax I described above. There are still some edge cases, mostly because of the fact that dhclient is started in a whole bunch of places, and making it all consistent is tricky. Perhaps refactoring /opt/vyatta/sbin/vyatta-dhcpv6-client.pl (probably rewriting it in Python) is in order. I may not do that right now, though.

Two remaining questions I have:

  1. Presumably, we should allow starting the dhclient requesting a delegated prefix on interfaces other than ethernet interfaces, such as bridges or bonded interfaces, etc. Does that mean that I really need to duplicate the templates/interfaces/ethernet/node.tag/dhcpv6-pd/... files into several other templates/interfaces/other-types/node.tag, too? I imagine so.
  2. Is there a way, in the embedded shell scripts in a node.def file, to get the type of the interface? I need to look up the dhcpv6-pd configuration nodes programmatically (in a Python program I've called /usr/libexec/vyos/conf_mode/dhcpv6_pd.py), so I need the path, such as 'interfaces ethernet eth0 dhcpv6-pd'. I can get the 'eth0' part as $VAR(../@), but how can I get the 'ethernet' part? Or is there a way to get to the dhcpv6-pd without it?
memchk added a subscriber: memchk.Dec 15 2018, 11:54 AM

@gadams:

In T421#27132, @gadams wrote:
  1. Is there a way, in the embedded shell scripts in a node.def file, to get the type of the interface? I need to look up the dhcpv6-pd configuration nodes programmatically (in a Python program I've called /usr/libexec/vyos/conf_mode/dhcpv6_pd.py), so I need the path, such as 'interfaces ethernet eth0 dhcpv6-pd'. I can get the 'eth0' part as $VAR(../@), but how can I get the 'ethernet' part? Or is there a way to get to the dhcpv6-pd without it?

If I understand correctly (mind I am a complete noob to VyOS dev), you would need to enumerate the config using the 'exists/list_nodes/return_value' functions on the config object. In addition, I don't think you need to pass anything as an argument, by enumerating it from the config object I think you can simply figure out which interfaces have the appropriate config tree set and go from there. How cleanly this all interfaces to the leagcy cfg stuff in vyatta-cfg-system is beyond me however.

Is your changes public anywhere currently? I am interested in helping out as this problem effects me, and it would be a fun way to get started contributing.

Hey! Sorry I was out for a bit. But I'm back now. Time to catch up.

Thanks for the suggestion for how to enumerate the list. It seems like that still has the potential problem of interface name collision if the names under different interface types aren't unique. But perhaps that never happens (you wouldn't find an 'eth0' under the 'bridge' type, for instance) so maybe it's not a problem.

The thing that this would let me do is fix some bugs that already exists. For instance, if I recall correctly, when you remove dhcpc6 config from an interface, the daemon isn't killed.

But even without doing this, what I have works just fine. It's been running solidly for the past month and a half. I think it's time to submit this, even if it's not perfect, yet. It touches parts that are in both the old and new configuration styles, so it's a lot to bundle up. Once the ethernet config nodes are moved to the new config system, this will be cleaned up quite a bit.

I'll work on collecting my files and getting a pull request together. It seems like the way the config system works, there's a lot of duplication. I'm hoping that there's a part of the build system that I haven't discovered, yet.

You rock Geoff!

Will this be a 1.2 feature or will it also be applied to 1.8?

Cheers,

Joel

Well, I've been developing it against the 1.2.0 branch. It might work back-ported to 1.1.8, but that's not my focus.

swerth removed a subscriber: swerth.Feb 10 2019, 8:13 PM
gadams added a comment.EditedFeb 13 2019, 8:53 AM

A quick progress update: I have fixed a bug (that may or may not have been present before) that prevented renew dhcpv6 interface eth3 (or whatever interface) from working outside of an active configuration session. I imagine most uses of dhcp lease renewal would occur in a normal router login session.

I'm working on getting a suitable build environment set up now. I should have my patches tested and ready to submit in a few days.

Oy. Turns out that other routers (like those that found in ISP-provided cable modems) can have subtle quirks in their DHCPv6-PD implementations. I've worked around another one.

In this one, the cable modem forgets that it has delegated a prefix sometimes, and then it ignores DHCPv6 Rebind messages from the ISC dhclient. Unfortunately, that's all dhclient will send until the lease expires, so the delegation will be effectively dead until then. This may be improved in a newer dhclient. In the meantime, I've added a dhclient -r invocation in vyatta-dhcpv6-client.pl that will at least allow renew dhcpv6 ... to get you out of that bind.

Lots a bunch of time to this one.

I've learned a lot about building ISO images over the past couple weeks. I have a first version of my change ready; it's in two commits currently:

https://github.com/gsadams/vyos-1x/commit/9dc320b026d29e1c6e290346b8be53a6f5a74a11
and
https://github.com/gsadams/vyatta-cfg-system/commit/5c1900015fe5f0c65810bdbbefa0c61cd118cc6d

and also likely requires the fix I proposed in T1059 (which appears not to have been merged, yet), depending on your particular configuration.

If you'd like to test it, I have built an image from the latest Crux branch plus those three changes, here: http://www.avernus.com/~gadams/vyos-crux.201902250834.dhcpv6pd-amd64.iso

I'm currently running that image, myself. It'd be nice if anyone who wants to get DHCPv6-PD working could give it a try and let me know whether it works for you, what you think of the config syntax, or anything glaring that it's missing. The configuration syntax is basically what I described up above. You'll need to enable the DHCPv6 client on the appropriate interface (the one connected to your ISP, presumably), and specify how you want the delegated prefix farmed out to other interfaces.

One known limitation is that the DHCPv6-PD configuration can currently only be applied to an ethernet interface. That's not because of any technical limitation; it's just that applying it to other interfaces will require copying a bunch of files, so I thought I'd try to get it right in one place, first.

hlmtre added a subscriber: hlmtre.Feb 26 2019, 3:16 AM
In T421#33183, @gadams wrote:

I've learned a lot about building ISO images over the past couple weeks. I have a first version of my change ready; it's in two commits currently:
https://github.com/gsadams/vyos-1x/commit/9dc320b026d29e1c6e290346b8be53a6f5a74a11
and
https://github.com/gsadams/vyatta-cfg-system/commit/5c1900015fe5f0c65810bdbbefa0c61cd118cc6d
and also likely requires the fix I proposed in T1059 (which appears not to have been merged, yet), depending on your particular configuration.
If you'd like to test it, I have built an image from the latest Crux branch plus those three changes, here: http://www.avernus.com/~gadams/vyos-crux.201902250834.dhcpv6pd-amd64.iso
I'm currently running that image, myself. It'd be nice if anyone who wants to get DHCPv6-PD working could give it a try and let me know whether it works for you, what you think of the config syntax, or anything glaring that it's missing. The configuration syntax is basically what I described up above. You'll need to enable the DHCPv6 client on the appropriate interface (the one connected to your ISP, presumably), and specify how you want the delegated prefix farmed out to other interfaces.
One known limitation is that the DHCPv6-PD configuration can currently only be applied to an ethernet interface. That's not because of any technical limitation; it's just that applying it to other interfaces will require copying a bunch of files, so I thought I'd try to get it right in one place, first.

Hi @gadams, I'm going to be running your image shortly. Are there any gotchas you've run into? Can you post your relevant dhcpv6-pd config? Thanks much!

Great! I'll look forward to hearing how it works for you.

The one major gotcha at the moment--and I forgot to mention this--is that it only handles prefixes on 4-bit boundaries. I can fix that with a bit of reworking (translating some shell scripting into python), but I suspect that many people will actually be using /56, /60, and /64 prefixes, so it might be good enough to start with.

I have my IPv6 upstream on eth3, so my config looks like this:

ethernet eth3 {
    address 10.1.11.3/24
    description OUTSIDE-v6
    dhcpv6-pd {
        interface br0 {
            sla-id 1
        }
        interface eth2.2 {
            sla-id 2
        }
        interface eth2.4 {
            sla-id 4
        }
        interface eth2.6 {
            sla-id 6
        }
    }
    duplex auto
    firewall { ... }
    hw-id ...
    ipv6 {
        address {
            autoconf
        }
        dup-addr-detect-transmits 1
    }
    smp-affinity auto
    speed auto
}

My ISP theoretically delegates a /56 to me, of which (for some reason) the upstream router actually delegates only the uppermost /60 to my VyOS router. My delegated prefix looks like this: aaaa:bbbb:cccc:b9f0::/60. (The upstream ISP router assigns aaaa:bbbb:cccc:b900::/64 for the link between the two routers, and advertises that to me via router advertisement, not DHCPv6.) Given the sla-ids I've assigned to br0 and the VLANs on eth2, I end up with these addresses on each of those interfaces:

br0:    aaaa:bbbb:cccc:b9f1::1/64
eth2.2: aaaa:bbbb:cccc:b9f2::1/64
eth2.4: aaaa:bbbb:cccc:b9f4::1/64
eth2.6: aaaa:bbbb:cccc:b9f6::1/64

In addition to sla-id, you can specify a prefix-length (64 is the default) and a host-address (::1 is the default). So, this would be an equivalent config:

dhcpv6-pd {
    interface br0 {
        sla-id 1
    }
    interface eth2.2 {
        prefix-length 64
        sla-id 2
    }
    interface eth2.4 {
        sla-id 4
    }
    interface eth2.6 {
        host-address ::1
        sla-id 6
    }
}

You should get error messages if the host-address part is too big, or the prefix-len plus the delegated prefix length doesn't leave enough room for the sla-id, and so on.

For each local interface, I enable router advertisement with something like this:

ethernet eth2 {
    ...
    vif 4 {
        ...
        ipv6 {
            router-advert {
                name-server aaaa:bbbb:cccc:b9f4::1
                name-server aaaa:bbbb:cccc:b9f1::abcd:abcd:abcd:abcd
                prefix ::/64 { }
            }
        }
    }
}

And that's it! The IPv6 packets flow.

hlmtre added a comment.EditedFeb 26 2019, 4:47 AM

You wouldn't happen to be on Comcast, would you? The supposed-/56 that's offered when instead it's a /60 is a behavior I'm familiar with on Comcast.

OH and thanks so much for the rapid (and thorough) response. I'll give this a shot tomorrow (after I can reboot the router overnight to apply the new image - other people I live with are selfishly using the internet).

Indeed, this is on Comcast Business. At least they're consistent in their oddity, eh?

c-po added a subscriber: c-po.Feb 26 2019, 7:17 AM

I‘m on Telekom FTTH (Germany) and could test an ISO, too.

I remember they offer /56 prefix

Great! The one I built last night is still available here: http://www.avernus.com/~gadams/vyos-crux.201902250834.dhcpv6pd-amd64.iso

A range of ISPs would be ideal, naturally, since they all probably implement things slightly differently.

Rebooted the router and configured following your instructions and got assigned an IPv6 address on my LAN interface! I'd never managed to get this far with pfSense (I could only get it to assign me addresses on the external interface) or on EdgeOS (probably over a year ago). Thanks so much!

I did get lots of debug output, and it did blow up and require two commits to un-set address dhcpv6 on the WAN interface, then set the dhcpv6-pd component, but it worked.

full debugging output available if you'd like

Yeah, I still have a bit of debug output in there. Easy enough to remove.

What blew up? Can you give a sequence of steps to reproduce it? I admit I haven't messed around with address dhcpv6 much, so there may still be some rough edges there.

Glad it worked for you! Let's try to polish the experience,

hlmtre added a comment.EditedFeb 27 2019, 1:32 AM

The commit failed and had to be ctrl+C'd. However, delete interfaces ethernet eth1 address dhcpv6; commit; then a second commit making the dhcpv6-pd changes work. So instead of the single step working, it had to be broken into two.

In order to run into this, you have to first have address dhcpv6 set on the interface you're trying to convert to dhcpv6-pd.

I am running into a small problem when advertising the prefix to my LANs. The devices are immediately setting themselves addresses in the correct scope, with the correct gateways and DNS servers, so all that works fine - but they can make no connections to the outside world with IPv6. They can actually do DNS lookups but cannot ping anywhere. I think I have a firewall issue (or some setting on the Comcast Business modem set wrong).

I can ping from my VyOS router, but only when sourced from its WAN address. Sourced from the address it's been assigned to its LAN interface (or from any client on that LAN) fails. Any ideas? My working theories are firewall on the VyOS box (though I have what I think are no rules preventing it to get out via IPv6) or the modem is dropping traffic from the delegated prefixes because they're not within the /64 that it's assigning via DHCPv6 (which I can't turn off - it re-enables itself upon hitting Apply changes).

https://i.imgur.com/yNl3JcS.png

Ah, interesting. I'll see if I can reproduce the address dhcpv6 problem.

The other problem you're having, where packets on the delegated prefix are not being forwarded, but packets on the WAN /64 are forwarded is a familiar one. It may be firewall settings, as you've suggested, but more likely it's because you've touched something on the Comcast router and hit 'Apply Changes.' In my experience, when you hit 'Apply Changes,' it will reboot, and promptly forget that it's delegated the prefix to you. You'll need to renew the lease from the client (VyOS router) side by doing something like renew dhcpv6 interface eth1. That will re-request the delegation, and then the Comcast router will forward packets again.

I don't think there's anything we can do about this on our side; it's just a failure of the Comcast firmware. It's forgetful. The best advice I have is to set it up and leave it alone. Unfortunately, if it ever reboots itself for any reason, then your IPv6 traffic will stop flowing until the downstream (VyOS) router renews the lease, either because it's nearing expiration or because you manually intervene. Fortunately, this happens very rarely for me.

I suppose setting a short lease time on the Comcast router would minimize the downtime. Or perhaps there's an option in dhclient to renew more often. That might be worth looking into.

I haven't made any 'Apply changes' to the modem and unfortunately it still won't forward my IPv6 traffic. You don't happen to have a firewall rule handy for being extremely permissive with IPv6 outgoing traffic, do you?

I do have one of the newer Comcast Business modems - according to its own hardware model reporting, a CGA4131COM. By Technicolor.

Oh, and one final question: you don't have a static IPv4 address, do you? Just trying to sort out any possibilities.

Hmmm. My next guess would be that you could be inadvertently blocking neighbor discovery (which happens on the link-local addresses). Can you try turning off the IPv6 firewall long enough to test whether it's the firewall at all? Another thing to try would be tcpdump on the LAN and WAN interfaces, as well as putting another machine (like a laptop) on the link between the two routers, to see where the packets are appearing and not appearing. You should see lots of link-local traffic between the LAN hosts and the VyOS router, as well as between the two routers.

I do have static IPv4 addresses, but only on the other link. (For historical reasons, I have separate upstream routers for the IPv4 and IPv6 links. My network is somewhat unconventional.) My IPv6 link has a dynamic global IPv4 address that I never concern myself with. I also set static addresses in net 10 for inter-router communication.

Also, I never knew that Technicolor was a brand of networking gear. Amusing! (I have a Netgear cablemodem for IPv6 and an SMC for v4.)

I've reproduced the hang you described on a test router. It looks like this:

[ interfaces ethernet eth0 dhcpv6-pd ]
dhcpv6-pd: ifname is eth0
Stopping daemon...
Killed old client process
Deleting related files...
Releasing any existing lease...
^C

I see where it's hanging, and I'll fix it, but I won't get a chance to build a new image until the weekend. In the meantime, let me know any other problems you discover!

I've turned off the IPv6 firewall, and run tcpdumps on my LAN and WAN interfaces (eth1 and eth0, respectively). I see loads of tcp retransmissions, and all my icmpv6 requests have an error message of 'no response found!' in the Wireshark output.

I do see the router advertisements as expected on the WAN capture, and the neighbor solicitations one expects on the LAN. I can ping the IPv6 address on my LAN interface from inside my network, and can apparently do DNS lookups (here), but nothing makes it through the router.

Since I'm just about out of ideas, I'm posting as much relevant config as I can find:

firewall {
     all-ping enable
     broadcast-ping disable
     config-trap disable
     ipv6-receive-redirects enable
     ipv6-src-route enable
     ip-src-route disable
     log-martians enable
     name OUTSIDE-IN {
         default-action drop
         rule 10 {
             action accept
             state {
                 established enable
                 related enable
             }
         }
     }
     name OUTSIDE-LOCAL {
         default-action drop
         rule 10 {
             action accept
             state {
                 established enable
                 related enable
             }
         }
         rule 20 {
             action accept
             icmp {
                 type-name echo-request
             }
             protocol icmp
             state {
                 new enable
             }
         }
         rule 30 {
             action drop
             destination {
                 port 22
             }
             protocol tcp
             recent {
                 count 4
                 time 60
             }
             state {
                 new enable
             }
         }
         rule 31 {
             action accept
             destination {
                 port 22
             }
             protocol tcp
             state {
                 new enable
             }
         }
     }
     receive-redirects disable
     send-redirects enable
     source-validation disable
     syn-cookies enable
     twa-hazards-protection disable
 }
 interfaces {
     ethernet eth0 {
         address <redacted>
         description WAN
         dhcpv6-pd {
             interface eth1 {
                 sla-id 1
             }
             interface ether1.4 {
                 sla-id 2
             }
         }
         duplex auto
         firewall {
             in {
                 name OUTSIDE-IN
             }
             local {
                 name OUTSIDE-LOCAL
             }
         }
         ipv6 {
             address {
                 autoconf
             }
         }
         smp-affinity auto
         speed auto
         traffic-policy {
             out upload
         }
     }
     ethernet eth1 {
         address 192.168.6.1/24
         description LAN
         duplex auto
         ipv6 {
             router-advert {
                 name-server 2001:558:feed::1
                 name-server 2001:558:feed::2
                 other-config-flag false
                 prefix ::/64 {
                 }
                 send-advert true
             }
         }
         smp-affinity auto
         speed auto
         traffic-policy {
             out download
         }
         vif 4 {
             address 192.168.4.1/24
             description "vlan 4"
         }
     }
     ethernet eth2 {
         duplex auto
         hw-id ac:1f:6b:48:63:ea
         smp-affinity auto
         speed auto
     }
     ethernet eth3 {
         duplex auto
         hw-id ac:1f:6b:48:63:eb
         smp-affinity auto
         speed auto
     }
     loopback lo {
     }
 }
 nat {
     source {
         rule 001 {
             outbound-interface eth0
             translation {
                 address masquerade
             }
         }
     }
 }
 service {
     mdns {
         repeater {
             interface eth0
             interface eth1
         }
     }
 }
 system {
     name-server 192.168.6.4
     name-server 1.1.1.1
     name-server 8.8.8.8
     name-server 2606:4700:4700::1111
     ntp {
         server 0.pool.ntp.org {
         }
         server 1.pool.ntp.org {
         }
         server 2.pool.ntp.org {
         }
     }
 }

Hmmm. I'll try to help you debug this issue offline (look for my message).

In the meantime, I did actually manage to update the code and build a new ISO that fixes the hang on commit and removes the debugging output: http://www.avernus.com/~gadams/vyos-crux.201902280714.dhcpv6pd-amd64.iso

c-po added a comment.Feb 28 2019, 8:27 PM

Interesting,

as soon as I did

set interfaces ethernet eth3 pppoe 0 enable-ipv6
set interfaces ethernet eth3 pppoe 0 ipv6 address autoconf

My dialer interface is no longer called pppoe0, it is named ppp0. In the past it was always renamed from ppp0 to pppoe0.

I'm interested in using VyOS to replace a Ubiquiti USG, but I absolutely need dhcpv6-pd on ATT Fiber.

Will this make the upcoming release?

c-po added a comment.Apr 2 2019, 5:52 AM

@gadams can we find your modifications somewhere?

just thought I'd ask... did this make it into 1.2 yet? 1.2.1?

Thanks again gadams!

CRCinAU added a subscriber: CRCinAU.Jul 2 2019, 6:30 PM

So in my testing of VyOS - after tinkering with an edgerouter, this is a kinda major feature to be lacking...

My APU2 was previously running Fedora 30 - and I managed to get PD's running fine via the following scripting:

LEASEFILE=/var/lib/dhclient/dhclient6.leases
INTERFACE=ppp0
dhclient -x -pf /var/run/dhclient6.pid || true
rm -f $LEASEFILE
## Genreate a unique seed.
myhwaddr=`ip add | grep link/ether | cut -f 6 -d \ | tail -n 1 | sed s/:/\\\\\\\\x/g`
echo "default-duid \"\\x00\\x03\\x00\\x01\\x$myhwaddr\";" > $LEASEFILE
dhclient -6 -v -P -pf /var/run/dhclient6.pid -lf $LEASEFILE $INTERFACE

Sadly, this doesn't work in vyos - an error is returned: Unsupported device type 512 for "pppoe0"

I note that the VyOS version of isc-dhclient is 4.3.1. The Fedora 30 version is 4.3.6.

However, I also note that I don't get any IPv6 address on pppoe0 in vyOS either, which worked perfectly in Fedora 30.