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

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