# If mac-sources are not specified, a default value of 'any' is used.
"mac-sources": [ "client-link-addr-option", "duid", "ipv6-link-local" ],
+# RFC6422 defines a mechanism called relay-supplied options option. The relay
+# agent may insert certain options that the server will echo back to the
+# client, if certain criteria are met. One condition is that the option must
+# be RSOO-enabled (i.e. allowed to be echoed back). IANA maintains a list
+# of those options here:
+# http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#options-relay-supplied
+# However, it is possible to allow the server to echo back additional options.
+# This entry marks options 110, 120 and 130 as RSOO-enabled.
+ "relay-supplied-options": [ "110", "120", "130" ],"
+
# Addresses will be assigned with preferred and valid lifetimes
# being 3000 and 4000, respectively. Client is told to start
# renewing after 1000 seconds. If the server does not repond
</para>
</section>
+ <section id="dhcp6-rsoo">
+ <title>Relay-Supplied Options</title>
+ <para><ulink url="http://tools.ietf.org/html/rfc6422">RFC 6422</ulink>
+ defines a mechanism called Relay supplied options. In certain cases relay
+ agents are the only entities that may have specific information. They can
+ insert options when relaying messages from the client to the server. The
+ server will then do certain checks and copy those options to the response
+ that will be sent to the client.</para>
+
+ <para>There are certain conditions that must be met for the option to be
+ included. First, the server must not provide the option by itself. In
+ other words, if both relay and server provide an option, the server always
+ takes precedence. Second, the option must be RSOO-enabled. IANA mantains a
+ list of RSOO-enabled options here: <ulink url="http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#options-relay-supplied">List of RSOO-enabled options</ulink>.
+ However, there may cases when system administrators want to echo other
+ options. Kea can be instructed to treat other options as RSOO-enabled.
+ For example, to mark options 110, 120 and 130 as RSOO-enabled, the following
+ syntax may be used:
+<screen>
+"Dhcp6": {
+ <userinput>"relay-supplied-options": [ "110", "120", "130" ],</userinput>
+ ...
+}
+</screen>
+ </para>
+ <para>As of March 2015, the only option 65 is RSOO-enabled by IANA. This
+ option will always be treated as such and there's no need to explicitly
+ mark it. Also, when enabling standard options, it is possible to use their
+ names, rather than option code, e.g. (e.g. use
+ <command>dns-servers</command> instead of <command>23</command>). See
+ <xref linkend="dhcp6-std-options-list" /> for the names. In certain cases
+ it could also work for custom options, but due to the nature of the parser
+ code this may be unreliable and should be avoided.
+ </para>
+
+ </section>
+
<section id="dhcp6-client-classifier">
<title>Client Classification in DHCPv6</title>
<note>
<simpara><emphasis>Dynamic Host Configuration Protocol for IPv6</emphasis>,
<ulink url="http://tools.ietf.org/html/rfc3315">RFC 3315</ulink>:
Supported messages are SOLICIT,
- ADVERTISE, REQUEST, RELEASE, RENEW, REBIND, CONFIRM and REPLY.</simpara>
+ ADVERTISE, REQUEST, RELEASE, RENEW, REBIND, INFORMATION-REQUEST,
+ CONFIRM and REPLY.</simpara>
</listitem>
<listitem>
<simpara><emphasis>IPv6 Prefix Options for
<ulink url="http://tools.ietf.org/html/rfc4704">RFC 4704</ulink>:
Supported option is CLIENT_FQDN.</simpara>
</listitem>
+ <listitem>
+ <simpara><emphasis>Relay-Supplied DHCP Options</emphasis>,
+ <ulink url="http://tools.ietf.org/html/rfc6422">RFC 6422</ulink>:
+ Full functionality is supported: OPTION_RSOO, ability of the server
+ to echo back the options, checks whether an option is RSOO-enabled,
+ ability to mark additional options as RSOO-enabled.</simpara>
+ </listitem>
<listitem>
<simpara><emphasis>Client Link-Layer Address Option in
DHCPv6</emphasis>,