dhcp6c.conf man page on DragonFly

Man page or keyword search:  
man Server   44335 pages
apropos Keyword Search (all sections)
Output format
DragonFly logo
[printable version]

DHCP6C.CONF(5)		    BSD File Formats Manual		DHCP6C.CONF(5)

NAME
     dhcp6c.conf — DHCPv6 client configuration file

SYNOPSIS
     /usr/local/etc/dhcp6c.conf

DESCRIPTION
     The dhcp6c.conf file contains configuration information for KAME's DHCPv6
     client, dhcp6c.  The configuration file consists of a sequence of state‐
     ments terminated by a semi-colon (`;').  Statements are composed of
     tokens separated by white space, which can be any combination of blanks,
     tabs and newlines.	 In some cases a set of statements is combined with a
     pair of brackets, which is regarded as a single token.  Lines beginning
     with ‘#’ are comments.

Interface specification
     There are some statements that may or have to specify interface.  Inter‐
     faces are specified in the form of "name unit", such as fxp0 and gif1.

DHCPv6 options
     Some configuration statements take the description of a DHCPv6 option as
     an argument.  The followings are the format and description of available
     DHCPv6 options.
     domain-name-servers
	     means a Domain Name Server option.
     domain-name
	     means a domain name option.
     ntp-servers
	     means an NTP server option.  As of this writing, the option type
	     for this option is not officially assigned.  dhcp6c will reject
	     this option unless it is explicitly built to accept the option.
     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 (see below about
	     identity associations).
     ia-na ID
	     means an IA_PD (Identity Association for Non-temporary Addresses)
	     option.  ID is a decimal number of the IAID (see below about
	     identity associations).
     rapid-commit
	     means a rapid-commit option.
     authentication authname
	     means an authentication option.  authname is a string specifying
	     parameters of the authentication protocol.	 An authentication
	     statement for authname must be provided.

Interface statement
     An interface statement specifies configuration parameters on the inter‐
     face.  The generic format of an interface statement is as follows:
     interface interface { substatements };
	     The followings are possible substatements in an interface state‐
	     ment.
	     send send-options ;
		     This statement specifies DHCPv6 options to be sent to the
		     server(s).	 Some options can only appear in particular
		     messages according to the specification, in which case
		     the appearance of the options is limited to be compliant
		     with the specification.

		     send-options is a comma-separated list of options, each
		     of which should be specified as described above.  Multi‐
		     ple send statements can also be specified, in which case
		     all the specified options will be sent.

		     When rapid-commit is specified, dhcp6c will include a
		     rapid-commit option in solicit messages and wait for an
		     immediate reply instead of advertisements.

		     When ia-pd is specified, dhcp6c will initiate prefix del‐
		     egation 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.
	     request request-options;
		     This statement specifies DHCPv6 options to be included in
		     an option-request option.	request-options is a comma-
		     separated list of options, which can consist of the fol‐
		     lowing options.
		     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 option is
			     not officially assigned.  dhcp6c will reject this
			     option unless it is explicitly built to accept
			     the option.
		     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
			     can only be specified when sent with information-
			     request messages; dhcp6c will ignore this option
			     for other messages.
		     Multiple request statements can also be specified, in
		     which case all the specified options will be requested.
	     information-only;
		     This statement specifies dhcp6c to only exchange informa‐
		     tional configuration parameters with servers.  A list of
		     DNS server addresses is an example of such parameters.
		     This statement is useful when the client does not need
		     stateful configuration parameters such as IPv6 addresses
		     or prefixes.
	     script "script-name";
		     This statement specifies a path to script invoked by
		     dhcp6c on a certain condition including when the daemon
		     receives a reply message.	script-name must be the abso‐
		     lute path from root to the script file, be a regular
		     file, and be created by the same owner who runs the dae‐
		     mon.

Identity association statement
     Identity association (IA) is a key notion of DHCPv6.  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.

     An identity association statement defines a single IA with some client-
     side configuration parameters.  Its format is as follows:
     id-assoc type [ID] { substatements };
	     type is a string for the type of this IA.	The current implemen‐
	     tation supports ‘na’ (non-temporary address allocation) ‘pd’
	     (prefix delegation) for the IA type.  ID is a decimal number of
	     IAID.  If omitted, the value 0 will be used by default.
	     substatements is a sequence of statements that specifies configu‐
	     ration parameters for this IA.  Each statement may or may not be
	     specific to the type of IA.

	     The followings are possible 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.  Multiple addresses can be
		     specified, each of which is described as a separate
		     address substatement.  dhcp6c will include all the
		     addresses (and related parameters) in Solicit messages,
		     as an IA_NA prefix option encapsulated in the correspond‐
		     ing IA_NA option.	Note, however, that the server may or
		     may not respect the specified prefix parameters.  For
		     parameters of the address substatement, see
		     dhcp6s.conf(5).

	     The followings are possible substatements for an IA of type pd.
	     prefix_interface_statement
		     specifies the client's local configuration of how dele‐
		     gated prefixes should be used (see below).
	     prefix ipv6-prefix pltime [vltime];
		     specifies a prefix and related parameters that the client
		     wants to be delegated.  Multiple prefixes can be speci‐
		     fied, each of which is described as a separate prefix
		     substatement.  dhcp6c will include all the prefixes (and
		     related parameters) in Solicit messages, as an IA_PD pre‐
		     fix option encapsulated in the corresponding IA_PD
		     option.  Note, however, that the server may or may not
		     respect the specified prefix parameters.  For parameters
		     of the prefix substatement, see dhcp6s.conf(5).

Prefix interface statement
     A prefix interface statement specifies configuration parameters of pre‐
     fixes on local interfaces that are derived from delegated prefixes.  A
     prefix interface statement can only appear as a substatement of an iden‐
     tity association statement with the type pd.  The generic format of an
     interface statement is as follows:
     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.
	     Possible substatements are as follows:
	     sla-id ID ;
		     This statement specifies 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).  For example, 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.
	     sla-len length ;
		     This statement specifies 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.

Authentication statement
     An authentication statement defines a set of authentication parameters
     used in DHCPv6 exchanges with the server(s).  The format of an authenti‐
     cation statement is as follows:
     authentication authname { substatements };
	     authname is a string which is unique among all authentication
	     statements in the configuration file.  It will specify a particu‐
	     lar set of authentication parameters when authentication option
	     is specified in the interface statement.  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.
	     algorithm authalgorithm ;
		     specifies the algorithm for this authentication.  Cur‐
		     rently, 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 authenti‐
		     cation.  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.  The format of a keyinfo statement is as
     follows:
     keyinfo keyname { substatements };
	     keyname is an arbitrary string.  It does not affect client's
	     behavior but is provided for readability of log messages.	Possi‐
	     ble 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.
	     expire "expiration-time" ;
		     specifies the expiration time of this key.
		     "expiration-time" should be formatted in one of the fol‐
		     lowings: 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 key‐
		     word 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.

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 exe‐
     cute the openssl(1) command (when available) as follows,

     % openssl rand -base64 16

     and copy the output to the dhcp6c.conf file.

     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.

KAME				 July 29, 2004				  KAME
[top]

List of man pages available for DragonFly

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net