dhcpcd-discuss

Hi Nicholas

On Thursday 28 January 2016 16:43:10 Nicholas Williams wrote:
> 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.)

I myself have an EdgeRouter Lite.
For reference, I didn't like the stock OS at all (but really really love the 
hardware) so I replaced it with NetBSD.
Currently working very well for my needs :)

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

Sure.

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

OK, lets lay some things on the table.
For stock ISC dhclient, there is literally no upside to >1 instance.
No instance will talk to each other, each instance will apply it's own ideas 
about how the interface and routing will look at the time it's run, but for 
routing it will generally not overwrite routes. IP addresses and DNS are for 
example, fair game.

Of course, this is somewhat manageable with custom a dhclient-script but still 
not trivial and very race prone. For example, if eth0 and eth1 both have 
DHCPv4 configured and are both plugged in, there is no guarantee which will set 
the default route or DNS, both could potentially be plugged into different 
networks.

dhcpcd on the other hand likes to be single instance for all interfaces and 
protocols. Of course, it can also be run the dhclient way which sadly also 
results in the same problems, just slightly worse as each dhcpcd instance WILL 
configure the interface, routing and DNS as best it can.
But as a single instance, it can prefer interfaces over another, based on 
automatic and configurable metrics to ensure regardless of which interface and 
protocol's get data first, the end result is always deterministic.

Now, to allay your fears you can do this:
# start dhcpcd in master mode
dhcpcd -M
# edit the config to make a change to eth1
vim /etc/dhcpcd.conf
# notify dhcpcd of the change to eth1
dhcpcd -n eth1

Now, to be truthful, the last step does work, it's just not very well tested.
For example, I don't recall if you can stop a protocol once it's started.

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

There is no technical reason why you cannot do this.

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

Almost right.
sla_id 0 is reserved for when you're delegated a /64 and want to divvy out a 
/64 - you can only do that without altering the prefix so obviously for only 
one interface

  ia_pd 2/::/60 eth1/1/64 eth2/2/64 eth3/3/64

Is fine.
But this is better

  ia_pd 2 eth1 eth2 eth3


dhcpcd will default to incrementing the sla_id as needed (may not always be 
1,2,3, depends on prefix and interface indexes for starters) and will default 
to a 64 prefix unless bigger is needed. In this case it uses the smallest prefix 
inside what we're delegating to.

The DHCPv6 protocol does not require you to request a specific prefix, or 
length, but the first example I gave shows you how to request a blank address 
(ie, not requested, but the config requires it) and a prefix length. From 
memory, some Comcast customers who posted here said they did not need to 
specify a /60 - some even got a /56

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

So don't deny it :)
denyinterfaces basically means dhcpcd will never use that interface (unless a 
ia_pd actively touches it or instructed to from the command-line)

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

Interesting.
We've not talked about slaac at all and I see it just now.
What does it mean in this context?

> I look forward to your advice and assistance in this project.

Hope it works out for you!

Roy