dhcpcd-discuss

> On Jan 28, 2016, at 7:08 PM, Roy Marples <roy@xxxxxxxxxxxx> wrote:
>> 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.

I don’t imagine that a scenario where multiple interfaces are getting DHCP addresses is very common for users of VyOS, but it’s certainly possible and supported. So how do you tell dhcpcd which interface to prefer over others for setting default routes and DNS? What will dhcpcd do if you //don’t// tell it which to prefer?

> 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

Okay. This is very useful information. I have some follow-up scenario questions:

- Can you start `dhcpcd -M` with a configuration that basically says “don’t do anything with an interface unless it’s specifically mentioned in this config file?” In essence, VyOS doesn’t always know about all interfaces unless they are configured, and even for those it does know about, it would be a complication to the config system is it had to explicitly exclude interfaces from DHCP configuration whenever configured without DHCP. It would be much easier to only add DHCPCD configuration for those interfaces that want DHCP, and simply ignore the ones that don’t. Is that possible? (I think denyinterfaces really messed up my thought process on this. Makes it seem like you have to explicitly disable DHCP for any interface that doesn’t want it.)

- If you notify dhcpcd of a change to an interface (`-n eth1`), it won’t bring all interfaces down and back up, right? It will only affect the interface that changed?

- If you notify dhcpcd of a change to an interface, and dhcpcd sees that, for example, the DHCPv4 configuration hasn’t changed (was and is on), but the DHCPv6 configuration did change (wasn’t on and is now), will dhcpcd bring down the entire interface and bring it back up? Or will it just make the v6 changes without affecting the still-valid v4 configuration?

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

So, if I understand it correctly, `dhcpcd -M` with per-interface notifications //will// work, but it’s not as well tested, and may have some issues, so the more-safe option is to do one-dhcpcd-instance-per-interface?

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

Beautiful. This means we can //let// them specify a prefix length if they really want to, but we can also omit it and useful defaults will prevail. I like it. Thanks!

Do I understand correctly that everything after `interface <name>` in the configuration file is configuration specific to that interface? So, for multiple interfaces, you’d do:

<global config options>
interface eth0
<eth0 config options>
interface eth1
<eth1 config options>

Can you have per-interface configuration files and import/combine them somehow, or point dhcpcd to a directory of them? That would make configuration much easier for us. What would that look like?

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

See my comment about this above. This sure makes it sound like you have to intentionally turn off dhcp for interfaces that don’t want it.

>> 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 need to think about this a bit more to be sure, but I don’t think `service slaac` is related to dhcpcd at all. It’s appropriate at that spot in the config, because it’s related to PD, but it’s actually a config telling the DHCP //server// to enable SLAAC on those interfaces.

>> I look forward to your advice and assistance in this project.
> 
> Hope it works out for you!
> 
> Roy

Thanks so much!

Nick