From: Tomek Mrugalski <tomasz@isc.org>
Date: Thu, 5 Mar 2015 10:29:54 +0000 (+0100)
Subject: [3705] Documentation updated.
X-Git-Tag: kea-0.9.1~19^2~5
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=7c26c499ba401d227ad85a82925c0fbd42020e70;p=thirdparty%2Fkea.git

[3705] Documentation updated.
---

diff --git a/doc/examples/kea6/advanced.json b/doc/examples/kea6/advanced.json
index 9aaa947617..9e2a63769f 100644
--- a/doc/examples/kea6/advanced.json
+++ b/doc/examples/kea6/advanced.json
@@ -39,6 +39,16 @@
 # 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
diff --git a/doc/guide/dhcp6-srv.xml b/doc/guide/dhcp6-srv.xml
index b0b7fd7b6d..d46d3a168b 100644
--- a/doc/guide/dhcp6-srv.xml
+++ b/doc/guide/dhcp6-srv.xml
@@ -1368,6 +1368,43 @@ should include options from the isc option space:
         </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>
@@ -2421,7 +2458,8 @@ should include options from the isc option space:
             <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
@@ -2448,6 +2486,13 @@ should include options from the isc option space:
             <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>,