<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-reddy-mif-dhcpv6-precedence-ops-02"
     ipr="trust200902">
  <front>
    <title abbrev="">Relay-Supplied DHCPv6 Precedence Options</title>

    <author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>Cessna Business Park, Varthur Hobli</street>

          <street>Sarjapur Marathalli Outer Ring Road</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560103</code>

          <country>India</country>
        </postal>

        <email>tireddy@cisco.com</email>
      </address>
    </author>

    <author fullname="Prashanth Patil" initials="P." surname="Patil">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>Cessna Business Park, Varthur Hobli</street>

          <street>Sarjapur Marthalli Outer Ring Road</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560103</code>

          <country>India</country>
        </postal>

        <email>praspati@cisco.com</email>
      </address>
    </author>

    <author fullname="Dan Wing" initials="D." surname="Wing">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>170 West Tasman Drive</street>

          <city>San Jose</city>

          <region>California</region>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <email>dwing@cisco.com</email>
      </address>
    </author>

    <date />

    <workgroup>MIF Working Group</workgroup>

    <abstract>
      <t>Network configuration of hosts is currently relatively static with
      little consideration of dynamic network characteristics. The network
      infrastructure is aware of dynamic network characteristics. This
      specification extends DHCPv6 so that the DHCPv6 relay agent can
      influence a host's configuration.</t>

      <!--
      <t>The network infrastructure is often aware of network characteristics
      such as IPv6 multihoming, security policies obtained as a consequence of
      authentication. Based on that information, better connectivity can be
      achieved by configuring hosts differently.</t>

      <t>This document defines new DHCPv6 Relay Options so that the network
      infrastructure can communicate network characteristics to the DHCPv6
      server, allowing the DHCPv6 server to configure the host using this
      additional information.</t>
-->
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>DHCPv6 allows relatively static information to be configured in
      hosts, which is somewhat limiting. On a dynamic network, the DHCPv6
      relay agent can observe characteristics of a network -- such as IPv6
      multihoming which might be temporarily unavailable or need load
      balancing of traffic towards each upstream ISPs. By including additional
      information in relayed DHCPv6 messages, the DHCPv6 relay agent can
      influence the DHCPv6 server to provide answers that are better suited to
      the host's configuration on the network.</t>

      <t>In this document we propose new DHCPv6 options to be added by the
      DHCPv6 relay agent when it generates a Relay-Forwarded message. <xref
      target="RFC6724"></xref> defines default address selection mechanisms
      for IPv6 that allow nodes to select appropriate address when faced with
      multiple source and/or destination addresses to choose between. An
      initial desire is to influence the DHCPv6 server's responses that modify
      the host's address policy table <xref
      target="I-D.ietf-6man-addr-select-opt"></xref> based on observed network
      characteristics.</t>
    </section>

    <section anchor="terminology" title="Terminology">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref target="RFC2119">
      </xref>.</t>
    </section>

    <section anchor="usage_scenarios" title="Usage Scenarios">
      <t>The DHCPv6 extension described in this document is useful with IPv6
      multihoming and with IP address-based authentication.</t>

      <section anchor="IPv6_multihoming" title="IPv6 Multihoming">
        <t><list style="symbols">
            <t>In Proxy Mobile IPv6 <xref target="RFC5213"></xref> where
            Mobile Node is assigned prefixes from both local access network
            and home network. This will allow selected traffic to go through
            the Mobile Packet Core and the rest through the Local access
            Network. When DHCPv6 Relay Agent is co-located with the mobile
            access gateway, the proposal is for the relay agent to influence
            the DHCPv6 Server in the home network by adding the Address
            Selection option. The relay agent can add an Address Selection
            option to the DHCPv6 request suggesting the local access network
            address selection policy table overiding the default address
            selection parameters and policy table. The DHCPv6 server in the
            home network will merge the policy received in Address Selection
            option with it's own policy table as explained in section 4.3 of
            <xref target="I-D.ietf-6man-addr-select-opt"></xref>. This updated
            policy table will be provided to the DHCPv6 client (MN) in Address
            Selection option (OPTION_ADDRSEL_TABLE). When the DHCPv6 Server is
            co-located with the mobile access gateway, the DHCPv6 Server in
            the local access network will receive the policy table from the
            DHCPv6 server in the home network using DHCPv6
            INFORMATION-REQUEST. The DHCPv6 server in local access network
            will merge the received policy table with it's local policy table.
            The following figure depicts this scenario. <figure
                anchor="Figure1" title="Proxy Mobile IPv6">
                <artwork align="center"><![CDATA[            _----_
          _(      )_
         ( Internet )
          (_      _)
            '----'
              |
              :
              :
              |
   .........................................................
              |                              |
   +--------+ |                   +---------------------+
   |  Local |-|                   | Operator Value      |
   |Services| |                   | Added Services      |
   +--------+ |                   |                     |  
              |                   +---------------------+
              |                              |
              |            _----_            |
           +-----+       _(      )_       +-----+
   [MN]----| MAG |======(    IP    )======| LMA |-- Internet
           +-----+       (_      _)       +-----+
                           '----'
                              . 
                              .
                              .
       [Access Network]       .        [Home Network]
   ..........................................................

MN - Mobile Node       ]]></artwork>
              </figure></t>
          </list></t>
      </section>

      <section anchor="temp_address"
               title="Disabling IPv6 Temporary Addresses">
        <section title="Avoiding Excessive IP-Based Authentication">
          <t>Some managed networks authenticate hosts with an authentication
          supplicant or for hosts lacking the supplicant perform address-based
          authentication. When Address-based authentication is used,
          re-authentication occurs for each address obtained by the host,
          which can create a lot of authentication transactions. To reduce
          this chatter, it can be useful to disable <xref
          target="RFC4941">IPv6 Privacy Addresses</xref> on those hosts using
          address-based authentication. In a managed network, this option will
          ensure that temporary addresses are disabled for hosts without
          authentication supplicant. This way managed networks can
          conditionally disable temporary addresses for only a set of
          hosts.</t>

          <t>The relay agent may be configured with the external prefixes that
          will be assigned to the host. In that case, the relay agent would
          use the Address Selection option. In the case where the relay agent
          is unaware of the external prefixes that will be assigned to the
          host, the relay agent uses the Relative Precedence option. Details
          for processing those options are described later in the
          document.</t>

          <t>Whenever either of those options is used, a DHCPv6 server that
          understands those options will ignore the IA_TA options in the
          DHCPv6 request, effectively disabling the use of temporary addresses
          for that host.</t>
        </section>

        <section title="Reducing Management Impact">
          <t>In addition, there are known issues in managing privacy
          extensions in certain scenarios. These are described in <xref
          target="I-D.gont-6man-managing-privacy-extensions">managing privacy
          extensions</xref>. In such scenarios, conditionally disabling
          temporary addresses allows administrators to better manage
          deployments.</t>
        </section>
      </section>
    </section>

    <section title="Options">
      <t>To realize the functions described above, this document defines new
      DHCPv6 option Relay-Supplied Prefix and updates the Address Selection
      option defined in <xref target="I-D.ietf-6man-addr-select-opt"></xref>.
      These DHCPv6 options are added by the DHCPv6 relay agent when it relays
      a DHCPv6 message, and both MAY appear together in the same DHCPv6
      message.</t>

      <figure anchor="fig_message_flow"
              title="Message Flow, Relay Agent adding Option">
        <artwork align="center"><![CDATA[
DHCPv6 Client        DHCPv6 Relay Agent           DHCPv6 Server
      |                    |                              |
      |------------------->|                              |
      |  DHCPv6 REQUEST    |                              |
      |                    |                              |
      |      (adds Relay-Supplied Prefix and/or           |
      |   Address Selection option to the request)        |
      |                    |                              |
      |                    |----------------------------->|
      |                    | DHCPv6 REQUEST with          |
      |                    | Relay-Supplied Prefix and/or |
      |                    | Address Selection Options    |
      |                    |                              |
      |                    |<-----------------------------|
      |                    | DHCPv6 REPLY                 |
      |<-------------------|                              |
      |  DHCPv6 REPLY      |                              |
]]></artwork>
      </figure>

      <t>Relay-Supplied Prefix option carries host and network information
      observed by the DHCPv6 relay agent such as host does not support 802.1x
      supplicant and will be subjected to web-authentication. The Address
      Selection option allows prioritizing among a list of prefixes the DHCPv6
      relay agent expects the DHCPv6 server to provide to the host.</t>

      <section title="Address Selection option">
        <t>The layout of the Address Selection option is below:</t>

        <figure anchor="fig_absolute_precedence"
                title="Option Type 1 message format">
          <artwork align="center"><![CDATA[
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  OPTION_ADDRSEL_TABLE         |          option-len           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved|N|A|P|                                               |
+-+-+-+-+-+-+-+-+      POLICY TABLE OPTIONS                     |
|                       (variable  length)                      | 
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <t>The fields are described below:<list style="hanging">
            <t hangText="option-code :">OPTION_ADDRSEL_TABLE defined in <xref
            target="I-D.ietf-6man-addr-select-opt"></xref></t>

            <t hangText="option-len:">Option Length</t>

            <t hangText="Reserved:">Must be 0 and ignored by the server.</t>

            <t hangText="N:">A value of 1 indicates that the relay agent wants
            the DHCPv6 server to ignore any IA_TA options in the DHCPv6
            request, as if the IA_TA options were not present. This
            effectively disables privacy extensions <xref
            target="RFC4941"></xref>. A value of 0 indicates the IA_TA
            options, if present in the DHCPv6 request, are processed normally
            by the DHCPv6 server. This value has no impact on destination
            prefixes.</t>

            <t hangText="A:">This flag MUST be set to 0 and ignored by the
            DHCPv6 server</t>

            <t hangText="P:">This flag MUST be set to 0 and ignored by the
            DHCPv6 server.</t>

            <t hangText="Prefix Table Options:">Zero or more Address Selection
            Policy Table options defined in <xref
            target="I-D.ietf-6man-addr-select-opt"></xref>.</t>
          </list></t>
      </section>

      <section title="Relay-Supplied Prefix Option">
        <t>The Relay-Supplied Prefix option is defined below:</t>

        <figure anchor="fig_Relay_supplied_Prefix"
                title="Option Type 2 message format">
          <artwork align="center"><![CDATA[
 0                   1                   2                     3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  OPTION_RS_PREFIX    |          option-len                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Policy flag   |         Reserved                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <t><list style="hanging">
            <t hangText="option-len:">Length of the option.</t>

            <t hangText="Policy flag: ">8-bit unsigned integer.</t>

            <t hangText="Reserved:">Must be 0 and ignored by the server.</t>
          </list></t>

        <t>The Policy Flag is defined below, and the actions taken by the
        DHCPv6 server based on this flag are described in <xref
        target="dhcp_server_behaviour"></xref>.</t>

        <figure anchor="fig_values" title="Policy flag Values">
          <artwork align="center"><![CDATA[
+------+------------------------------------------------------------+
|Value | Name               | Description                           |
+------+------------------------------------------------------------+
| 0x01 | IPV6_DIS_TEMP_ADDR | Disable IPv6 Temporary Address        |
+------+------------------------------------------------------------+
]]></artwork>
        </figure>
      </section>
    </section>

    <section anchor="relay_agent_beh" title="Relay Agent Behaviour">
      <t>DHCPv6 relay agents that implement this specification MUST be
      configurable for sending the Address Selection option and the
      Relay-Supplied Prefix option. Relay agents SHOULD have separate
      configuration for each option to determine if it is to be added to
      DHCPv6 request. A relay agent will include these options in the option
      payload of a Request message. DHCPv6 relay agent should set Address
      Selection option when there is a need to change the label/precedence
      value for prefixes in scenario's discussed in <xref
      target="IPv6_multihoming"></xref> and/or disable IPv6 temporary
      addresses for the host. <list style="empty">
          <t>Discussion: To reduce end-user configuration of the DHCPv6 relay
          agent, the DHCPv6 relay agent can use the mechanism specified in
          <xref target="RFC3633"></xref> to automatically learn the IPv6
          prefixes that will be delegated to DHCPv6 clients. DHCPv6 relay
          agent in future can use leasequery-like capability discussed in
          section 3.2 of RFC <xref target="RFC5007"></xref> to learn the
          prefix information from DHCPv6 server.</t>
        </list>DHCPv6 relay agent should set Relay-Supplied Prefix option when
      it receives DHCPv6 request from a host with specific characteristics
      like authenticated using address based mechanism. Relative Precedence
      option is used when the relay agent is unaware of the external prefixes
      to be assigned to the host.</t>
    </section>

    <section anchor="dhcp_server_behaviour" title="DHCPv6 Server Behaviour">
      <t>Upon receiving a DHCPv6 request containing the Address Selection
      option or the Relay-Supplied Prefix Option, the DHCPv6 server processing
      is described below:</t>

      <section title="Address Selection option">
        <t>Address Selection option - The DHCPv6 server should send a reply to
        the host with the prefixes received from DHCPv6 relay agent along with
        Precedence. The DHCPv6 server will merge the policy received in
        Address Selection option with it's own policy table as explained in
        section 4.3 of <xref
        target="I-D.ietf-6man-addr-select-opt"></xref>.</t>

        <t>If the option has "N" bit set to 1, the server SHOULD ignore the
        IA_TA options in the DHCPv6 request, effectively disabling the use of
        temporary addresses for that prefix. The DHCPv6 server will ignore the
        "N" bit for destination prefixes.</t>

        <t>Note : If DHCPv6 servers receives both options with conflicting
        flags IPV6_DIS_TEMP_ADDR and "N" bit then it SHOULD treat it as
        mis-configuration on the relay agent and discard these options.</t>
      </section>

      <section title="Relay-Supplied Prefix Option">
        <t>The Relay-Supplied Prefix Option contains flags that defines the
        characteristics of the host. <list style="numbers">
            <t>IPV6_DIS_TEMP_ADDR - This flag indicates that Temporary IPv6
            address allocation is to be disabled for the host. The DHCPv6
            server should ignore any IA_TA options in the DHCPv6 request.</t>
          </list></t>
      </section>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>Relay-Supplied Prefix is exchanged only between the DHCPv6 relay
      agent and DHCPv6 server and Address Selection option can originate
      either from the server or the relay agent, section 21.1 of <xref
      target="RFC3315"></xref> provides details on securing DHCPv6 messages
      sent between servers and relay agents. And, section 23 of <xref
      target="RFC3315"></xref> provides general DHCPv6 security
      considerations.</t>

      <t>It is possible for a DHCPv6 client to include the Relay-Supplied
      Prefix option or the Address Selection options, which would be received
      by a DHCPv6 server. This would cause the DHCPv6 client to receive a
      different DHCPv6 response than it would have otherwise received. .</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>IANA is requested to assign option code to OPTION_RS_PREFIX from the
      option-code space as defined in section "DHCPv6 Options" of <xref
      target="RFC3315"></xref>.</t>
    </section>

    <section title="Change History">
      <t>[Note to RFC Editor: Please remove this section prior to
      publication.]</t>

      <section title="Changes from draft-reddy-mif-dhcpv6-precedence-ops-00 to -01">
        <t><list style="symbols">
            <t>Added Proxy Mobile IPv6 with traffic offload use-case in
            Section 3.1.</t>

            <t>Updated Section 3.2.1 to highlight the ability to disable
            temporary addresses selectively.</t>
          </list></t>
      </section>

      <section title="Changes from draft-reddy-mif-dhcpv6-precedence-ops-01 to -02">
        <t><list style="symbols">
            <t>Updated usecase in section 3.1</t>

            <t>Changed Absolute Precedence Option</t>
          </list></t>
      </section>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.3315"?>

      <!--      <?rfc include="reference.RFC.3775"?> -->

      <!--      <?rfc include="reference.RFC.4862"?> -->

      <!--      <?rfc include="reference.RFC.4649"?> -->

      <?rfc include="reference.RFC.4941"?>

      <?rfc include="reference.RFC.5007"?>

      <?rfc include="reference.RFC.5213"?>

      <?rfc include="reference.RFC.6724"?>

      <?rfc include="reference.RFC.4291"?>

      <?rfc include='reference.I-D.ietf-6man-addr-select-opt'?>

      <?rfc include='reference.I-D.gont-6man-managing-privacy-extensions'?>

      <!--      <?rfc include="reference.I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat" ?> -->

      <!--      <?rfc include="reference.I-D.droms-dhc-dhcpv6-agentopt-delegate" ?> -->
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.3633'?>

      <!--      <?rfc include='reference.RFC.4861'?> 

      <?rfc include='reference.RFC.5220'?>

      <?rfc include='reference.RFC.5221'?>

      <?rfc include='reference.RFC.3587'?>


      <?rfc include='reference.I-D.draft-ietf-6man-addr-select-considerations-03'?>
-->
    </references>
  </back>
</rfc>
