DHCP6C.CONF(5)

πŸ“¦
this version Β· 2 versions
, in debian bookworm, epel 10, epel 9, fedora 43, fedora 44, ubuntu jammy, ubuntu noble

πŸ’– DHCP6C.CONF(5) πŸ’–

okay bestie, gather round β€” this is the manual page for the DHCPv6 client configuration file, part of the File Formats Manual. Yes, it's DHCP6C.CONF(5), and yes, we're gonna make it make sense. 🫢


✨ NAME ✨

dhcp6c.conf β€” the DHCPv6 client configuration file, aka the vibe sheet your DHCPv6 client reads to know what it's supposed to be doing. πŸ¦‹


πŸŽ€ SYNOPSIS πŸŽ€

/etc/wide-dhcpv6/dhcp6c.conf

That's it. That's the whole synopsis. Slay. πŸ’…


🌸 DESCRIPTION 🌸

So dhcp6c.conf holds all the config info for KAME's DHCPv6 client, dhcp6c. Here's the whole grammar vibe, no cap:

  • The file is a sequence of statements, and every statement gets terminated by a semi-colon (`;`). Periodt. 😌
  • Statements are built out of tokens separated by white space β€” and "white space" means any combo of blanks, tabs and newlines. Mix and match, she doesn't care. ✨
  • Sometimes a whole set of statements gets wrapped in a pair of brackets, and the whole bracket blob counts as one single token. Iconic, honestly.
  • Any line that starts with `#` is a comment. Talk your talk, the parser isn't listening. πŸ’¬

πŸ¦‹ Interface specification πŸ¦‹

Some statements may specify an interface, and some have to. Rude but fair.

Interfaces get written in the form of "name unit", like fxp0 and gif1. So name, then space, then unit number. That's the whole format. πŸ’–


🌈 DHCPv6 options 🌈

Some config statements take a description of a DHCPv6 option as an argument. Here's every option format and what it means, in order, no skipping:

  • domain-name-servers β€” means a Domain Name Server option. 🌐
  • domain-name β€” means a domain name option. 🏷️
  • ntp-servers β€” means an NTP server option. ⚠️ Heads up: as of this writing, the option type for this one is not officially assigned, and dhcp6c will reject this option unless it's been explicitly built to accept it. So don't just assume it works, bestie.
  • sip-server-address β€” means a SIP Server address option. πŸ“ž
  • sip-server-domain-name β€” means a SIP server domain name option. πŸ“ž
  • nis-server-address β€” means a NIS Server address option. πŸ—‚οΈ
  • nis-domain-name β€” means a NIS domain name option. πŸ—‚οΈ
  • nisp-server-address β€” means a NIS+ Server address option. πŸ—‚οΈ
  • nisp-domain-name β€” means a NIS+ domain name option. πŸ—‚οΈ
  • bcmcs-server-address β€” means a BCMCS Server address option. πŸ“‘
  • bcmcs-server-domain-name β€” means a BCMCS server domain name option. πŸ“‘
  • ia-pd ID β€” means an IA_PD (Identity Association for Prefix Delegation) option. ID is a decimal number of the IAID β€” more on identity associations below, keep reading. 🫢
  • ia-na ID β€” means an IA_PD (Identity Association for Non-temporary Addresses) option. ID is a decimal number of the IAID β€” again, see below about identity associations. 🫢
ngl the page literally says IA_PD right there in the ia-na entry. I'm just the messenger, bestie. πŸ’€ Reproducing faithfully, that's the job.
  • rapid-commit β€” means a rapid-commit option. ⚑
  • authentication authname β€” means an authentication option. authname is a string specifying parameters of the authentication protocol. And real talk: an authentication statement for authname must be provided. No authname statement, no deal. πŸ”

πŸ’… Interface statement πŸ’…

An interface statement is where you specify configuration parameters on the interface. Generic format goes like this:

interface interface { substatements };

Now here's every possible substatement you can put inside an interface statement. πŸ‘‘

send send-options ;

This one specifies the DHCPv6 options to be sent to the server(s). πŸ“€

Some options can only appear in particular messages per the spec, and in that case the appearance of those options is limited so it stays compliant with the spec. Rules are rules.

send-options is a comma-separated list of options, and each one should be specified the way described above. You can also stack multiple send statements, and in that case all the specified options get sent. More is more. ✨

  • When rapid-commit is specified, dhcp6c will include a rapid-commit option in solicit messages and wait for an immediate reply instead of advertisements. No small talk, just business. ⚑
  • When ia-pd is specified, dhcp6c will initiate prefix delegation as a requesting router by including an IA_PD option with the specified ID in solicit messages. 🌐
  • When ia-na is specified, dhcp6c will initiate stateful address assignment by including an IA_NA option with the specified ID in solicit messages. 🏠
In either case, a corresponding identity association statement must exist with the same ID. This is not optional, bestie. It's giving "they have to match or nothing works". 😭

request request-options;

This statement specifies the DHCPv6 options to be included in an option-request option. πŸ™‹β™€οΈ

request-options is a comma-separated list of options, and it can consist of these:

  • domain-name-servers β€” requests a list of Domain Name Server addresses. 🌐
  • domain-name β€” requests a DNS search path. πŸ”
  • ntp-servers β€” requests a list of NTP server addresses. ⚠️ As of this writing, the option type for this one is not officially assigned, and dhcp6c will reject this option unless it's explicitly built to accept it.
  • sip-server-address β€” requests a list of SIP server addresses. πŸ“ž
  • sip-domain-name β€” requests a SIP server domain name. πŸ“ž
  • nis-server-address β€” requests a list of NIS server addresses. πŸ—‚οΈ
  • nis-domain-name β€” requests a NIS domain name. πŸ—‚οΈ
  • nisp-server-address β€” requests a list of NIS+ server addresses. πŸ—‚οΈ
  • nisp-domain-name β€” requests a NIS+ domain name. πŸ—‚οΈ
  • bcmcs-server-address β€” requests a list of BCMCS server addresses. πŸ“‘
  • bcmcs-domain-name β€” requests a BCMCS domain name. πŸ“‘
  • refreshtime β€” means an information refresh time option. πŸ• This one can only be specified when sent with information-request messages; dhcp6c will ignore this option for other messages. Don't try it, she's not gonna read it.

You can also stack multiple request statements, and in that case all the specified options will be requested. πŸ”₯

information-only;

This statement tells dhcp6c to only exchange informational configuration parameters with servers. A list of DNS server addresses is a classic example of such parameters. πŸ“‹

This one is a lifesaver when the client doesn't need stateful configuration parameters like IPv6 addresses or prefixes. Just vibes and info, no commitments. 🧚

script "script-name";

This statement specifies a path to a script invoked by dhcp6c on a certain condition β€” including when the daemon receives a reply message. πŸ“œ

script-name has requirements, and they are not negotiable:

  • it must be the absolute path from root to the script file, πŸ›£οΈ
  • it must be a regular file, πŸ“„
  • and it must be created by the same owner who runs the daemon. πŸ‘€
Get any of those wrong and it's not happening. The daemon said what it said. πŸ’€

πŸ‘‘ Profile statement πŸ‘‘

Some setups need to configure an interface independently from its name. That's literally what profiles are for. πŸŽ€

Profiles follow the same syntax as an interface statement β€” the only glow-up is that they can be arbitrarily named. Then you get to choose which profile to use for a given interface on the command line. Main character energy, honestly. ✨


πŸ’œ Identity association statement πŸ’œ

Identity association (IA) is a key notion of DHCPv6 β€” like, the whole concept, okay. Here's the tea:

  • An IA is uniquely identified in a client by a pair of IA type and IA identifier (IAID). πŸ†”
  • An IA is associated with configuration information dependent on the IA type. So the type decides what config comes along with it.

An identity association statement defines a single IA with some client-side configuration parameters. Format:

id-assoc type [ID] { substatements };

Breakdown time, bestie:

  • type is a string for the type of this IA. The current implementation supports β€˜na’ (non-temporary address allocation) and β€˜pd’ (prefix delegation) for the IA type. πŸ’«
  • ID is a decimal number of the IAID. And if you omit it, the value 0 will be used by default. Sneaky little default, but there it is.
  • substatements is a sequence of statements that specifies configuration parameters for this IA. Each statement may or may not be specific to the type of IA β€” depends on the statement.

🏠 substatements for an IA of type na

  • address ipv6-address pltime [vltime]; β€” specifies an address and related parameters that the client wants to be allocated. You can specify multiple addresses, each one written as its own separate address substatement. dhcp6c will include all the addresses (and related parameters) in Solicit messages, as an IA_NA prefix option encapsulated in the corresponding IA_NA option. 🌟
BUT β€” and this is the important part β€” the server may or may not respect the specified prefix parameters. You asked, it decides. That's the deal. 😭

For parameters of the address substatement, go look at dhcp6s.conf(5). πŸ“–

🌐 substatements for an IA of type pd

  • prefix_interface_statement β€” specifies the client's local configuration of how delegated prefixes should be used (see below). 🧩
  • prefix ipv6-prefix pltime [vltime]; β€” specifies a prefix and related parameters that the client wants to be delegated. You can specify multiple prefixes, each one written as its own separate prefix substatement. dhcp6c will include all the prefixes (and related parameters) in Solicit messages, as an IA_PD prefix option encapsulated in the corresponding IA_PD option. 🌟
Same warning as above, fr fr: the server may or may not respect the specified prefix parameters. She heard you, she just might not agree. πŸ’€

For parameters of the prefix substatement, see dhcp6s.conf(5). πŸ“–


✨ Prefix interface statement ✨

Okay so a prefix interface statement is the one that tells dhcp6c how to build the prefixes on your local interfaces out of the delegated prefixes it got handed πŸ’… It specifies configuration parameters of prefixes on local interfaces that are derived from delegated prefixes.

Heads up bestie: this one is only allowed to show up as a substatement of an identity association statement with the type pd. Nowhere else. It's giving exclusive.

The generic format is literally:

prefix-interface interface { substatements };

When an IPv6 prefix is delegated from a DHCPv6 server, dhcp6c will assign a prefix on the interface unless the interface receives the DHCPv6 message that contains the prefix with the delegated prefix and the parameters provided in substatements.

The possible substatements, bestie, are these:

  • sla-id ID ; β€” sets the identifier value of the site-level aggregator (SLA) on the interface. ID must be a decimal integer which fits in the length of SLA IDs (see below, iykyk). So like, if ID is 1 and the client is delegated an IPv6 prefix 2001:db8:ffff::/48, dhcp6c will combine the two values into a single IPv6 prefix, 2001:db8:ffff:1::/64, and will configure the prefix on the specified interface. Math but make it slay ✨
  • sla-len length ; β€” sets the length of the SLA ID in bits. length must be a decimal number between 0 and 128. If the length is not specified by this statement, the default value 16 will be used.
  • ifid ID ; β€” sets the interface id. ID must be a decimal integer. It will be combined with the delegated prefix and the sla-id to form a complete interface address. The default is to use the EUI-64 address of the interface.
  • ifid-random; β€” tells the client to generate a completely random interface id. This will override the ifid statement, if present. The resulting random interface id will be combined with the delegated prefix and the sla-id to form a complete interface address. Chaos, but organized πŸ’€

πŸ” Authentication statement

An authentication statement defines a set of authentication parameters used in DHCPv6 exchanges with the server(s). The format is:

authentication authname { substatements };

So authname is a string which is unique among all authentication statements in the configuration file. It will specify a particular set of authentication parameters when authentication option is specified in the interface statement.

The possible substatements of the authentication statement are as follows:

  • protocol authprotocol ; β€” specifies the authentication protocol. Currently, the only available protocol as authprotocol is delayed, which means the DHCPv6 delayed authentication protocol. That's it, that's the whole menu πŸŽ€
  • algorithm authalgorithm ; β€” specifies the algorithm for this authentication. Currently, the only available algorithm is HMAC-MD5, which can be specified as one of the followings: hmac-md5, HMAC-MD5, hmacmd5, or HMACMD5. This substatement can be omitted. In this case, HMAC-MD5 will be used as the algorithm.
  • rdm replay-detection-method ; β€” specifies the replay protection method for this authentication. Currently, the only available method is monocounter, which means the use of a monotonically increasing counter. If this method is specified, dhcp6c will use an NTP-format timestamp when it authenticates the message. This substatement can be omitted, in which case monocounter will be used as the method.

πŸ—οΈ Keyinfo statement

A keyinfo statement defines a secret key shared with the server(s) to authenticate DHCPv6 messages. Format goes:

keyinfo keyname { substatements };

keyname is an arbitrary string. It does not affect client's behavior but is provided for readability of log messages. So it's purely for the vibes of your logs, no cap 🫢

The possible substatements of the keyinfo statement are as follows:

  • realm "realmname" ; β€” specifies the DHCP realm. realmname is an arbitrary string, but is typically expected to be a domain name like "kame.net".
  • keyid ID ; β€” specifies the key identifier, ID, as a decimal number. A secret key is uniquely identified within the client by the DHCP realm and the key identifier.
  • secret "secret-value" ; β€” specifies the shared secret of this key. "secret-value" is a base-64 encoded string of the secret. Keep it safe bestie, it's giving classified πŸ‘‘
  • expire "expiration-time" ; β€” specifies the expiration time of this key. "expiration-time" should be formatted in one of the followings: yyyy-mm-dd HH:MM, mm-dd HH:MM, or HH:MM, where yyyy is the year with century (e.g., 2004), mm is the month, dd is the day of the month, HH is the hour of 24-hour clock, and MM is the minute, each of which is given as a decimal number. Additionally, a special keyword forever can be specified as expiration-time, which means the key has an infinite lifetime and never expires. This substatement can be omitted, in which case forever will be used by default. Immortal key behavior ✨

🌈 Examples

The followings are a sample configuration to be delegated an IPv6 prefix from an upstream service provider. With this configuration dhcp6c will send solicit messages containing an IA_PD option, with an IAID 0, on to an upstream PPP link, ppp0. After receiving some prefixes from a server, dhcp6c will then configure derived IPv6 prefixes with the SLA ID 1 on a local ethernet interface, ne0. Note that the IAID for the id-assoc statement is 0 according to the default.

interface ppp0 {
        send ia-pd 0;
};

id-assoc pd {
        prefix-interface ne0 {
                sla-id 1;
        };
};

If a shared secret should be configured in both the client and the server for DHCPv6 authentication, it would be specified in the configuration file as follows:

keyinfo kame-key {
        realm "kame.net";
        keyid 1;
        secret "5pvW2g48OHPvkYMJSw0vZA==";
};

One easy way of generating a new secret in the base64 format is to execute the openssl(1) command (when available) as follows,

% openssl rand -base64 16

and copy the output to the dhcp6c.conf file. Cheat code but legal πŸ’…

To include an authentication option for DHCPv6 authentication, the interface statement should be modified and an authentication statement should be added as follows:

interface ppp0 {
        send ia-pd 0;
        send authentication kame;
};

authentication kame {
        protocol delayed;
};

interface fxp0 {
        send ia-na 0;
};

πŸ‘€ SEE ALSO

dhcp6s.conf(5) dhcp6c(8)


πŸ“œ HISTORY

The dhcp6c.conf configuration file first appeared in the WIDE/KAME IPv6 protocol stack kit. Ancient lore fr fr 🧚


And that's a wrap on this absolute unit of a man page πŸ’– It's from the KAME crew, dated July 29, 2004, and it lives at DHCP6C.CONF(5) β€” go configure something iconic, bestie, you got this πŸ«Άβœ¨πŸ‘‘

πŸ“¦ where this page comes from