Planning to switch VyOS from ISC dhclient to dhcpcd
Nicholas Williams
Thu Jan 28 22:43:11 2016
Hello!
Apologies for the long email, but I'm starting on a major project here and
need your help. I've recently become involved on the VyOS project [1], an
fantastic open source router/border router software that's a fork from the
now-defunct Vyatta Core. VyOS is also a sister fork with EdgeOS, a product
of Ubiquiti used for their router hardware. (Code has been know to float
back-and-forth between VyOS and EdgeOS.)
VyOS uses ISC's dhclient for setting up DHCP addresses on interfaces in the
router. We've been struggling for the past year with dhclient's lack of
support for DHCPv6 PD prefix length requests and delegation to internal
interfaces. EdgeOS abandoned dhclient a couple years ago and switched to
WIDE for just this reason. We are also looking at dumping dhclient. For a
myriad of reasons, we'd prefer to go the dhcpcd route for VyOS. I'm looking
for any general guidance / advice you can offer to help us be successful in
this project.
Before you can provide any advice on the best way for us to proceed, I
should probably tell you about how we're using dhclient, because it's weird
(or, at least, it seemed so to me). For many reasons (not all of which I
understand), we start an instance of dhclient for each v4 or v6
configuration for each interface. So, for example, if we have two
interfaces, and one of them just wants DHCPv4, and the other one wants
DHCPv4 and DHCPv6, we start //three// instances of dhclient—one for eth0
v4, one for eth1 v4, and one for eth1 v6.
What I'm not clear on is whether this is a recommended—or even valid—way to
use dhcpcd. The main upside to doing it this way (that I understand) is
that 1) committing changes to one interface doesn't cause another interface
to also be temporarily unavailable, and 2) changing IPv6 on eth0 doesn't
cause IPv4 on eth0 to be temporarily unavailable / get reconfigured, and
changing IPv4 on eth0 doesn't cause IPv6 on eth0 to be temporarily
unavailable / get reconfigured. I think that last one might be the most
important key. When, for example, DHCPv6 settings on an interface are
changed, only the dhclient instance for v6 for that interface gets
restarted. The dhclient instance for v4 for that interface keeps running,
so that interface is still available via an IPv4 address. If dhcpcd can't
do this (or can, but shouldn't be used this way), that's okay, I just need
to know sooner so that we don't go down the wrong path.
Another consideration is that we're //thinking about// continuing to use
dhclient for DHCPv4 and only switching to dhcpcd for DHCPv6. I know, this
sounds terrible. There //are// some good reasons—namely, that our entire
configuration stacks for IPv4 and IPv6 are separate, and we can
significantly minimize the risk for this project if we leave the
widely-used IPv4 stack alone and redo only the little-used IPv6 stack.
However, that reason might not be good enough. If it's going to be a Very
Bad Idea™ to run dhclient for v4 and dhcpcd for v6 on the same interface,
I'd like to know soon.
Finally is the configuration portion. The most common use case we see from
users is this:
"I'm running on [Comcast | Time Warner | some other cable provider] who
provides a single /128 by default but accepts PD prefix length requests for
additional addresses. They recommend requesting a /60 PD and delegating a
/64 from the assigned /60 to each internal interface. I have [2≤n≤99]
interfaces that all need IPv6 prefixes from this PD."
Importantly, it sounds like these ISPs support //only a single PD request//
(not multiple requests for smaller prefixes), so we need to get a /60 and
divvy it up. I could be wrong about this, but that's how I'm proceeding.
Taking a common use case (like mine in particular), I need to get a /128
for the single external-facing interface, and then have /64 prefixes for
each of my 3 internal interfaces, with the *::1 address from each prefix
assigned as the gateway for each internal interface. So, if we request a
/60 from Comcast through eth0, and Comcast gives us 2620:0:2d0:200::1/60,
we would assign 2620:0:2d0:200::1/64 to eth1, 2620:0:2d0:201::1/64 to eth2,
and 2620:0:2d0:202::1/64 to eth3. Given that, I //think// this would be the
correct dhcpcd configuration, but I just don't know for sure:
noipv6rs
interface eth0
ipv6rs
ia_na 1
ia_pd 2 eth1/0/64 eth2/1/64 eth3/2/64
Did I get this right? Are we on the right track? Will this request a /60
and divvy it up into three /64s for eth1-3?
I noticed that the ip_pd documentation in the man page for dhcpcd.conf
demonstrates also using `denyinterfaces eth2` in this case, but I'm not
sure what that accomplishes here, and we seem to be using eth2 essentially
the same way as eth1 and eth3. I would love some clarification on this.
As a further example, for the sake of context, this same dhcpcd config
would be generated using the following router config:
# show interfaces ethernet eth0 dhcpv6-pd
pd 1 {
interface eth1 {
service slaac
}
interface eth2 {
service slaac
}
interface eth3 {
service slaac
}
prefix-length 60
}
I look forward to your advice and assistance in this project.
Thanks,
Nick Williams
[1] http://vyos.net/wiki/Main_Page
Archive administrator: postmaster@marples.name