<?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-wing-behave-dhcpv6-reconfigure-01"
     ipr="trust200902">
  <front>
    <title abbrev="dhcpv6_dynamic_reconfig">DHCPv6 Dynamic
    Re-Configuration</title>

    <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>

    <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>

    <date />

    <workgroup>BEHAVE Working Group</workgroup>

    <abstract>
      <t>Some networks are expected to support IPv4-only, dual-stack, and
      IPV6-only hosts at the same time. This makes prioritizing the DNS
      servers for hosts tricky due to a heterogeneous mix of protocol stacks
      causing optimal behavior to occur only when the host stack
      re-initializes. The networks infrastructure is usually well equipped to
      be aware of single/dual-stack nature of hosts. This specification
      extends DHCPv6 so that the DHCPv6 Relay Agent can dynamically influence
      the priority of DNS servers provided to the host, so that the host can
      use the optimal DNS server for resolution.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>The default address selection rules <xref target="RFC3484"></xref>
      prefers IPv6 over IPv4. If a dual-stack host is configured to use a
      DNS64 server, that DNS64 server will synthesize a AAAA response if there
      is an A record. Thus, the dual-stack host will always use IPv6 if a DNS
      lookup was involved, even if IPv4 could have been used more optimally.
      If NAT44 and NAT64 are deployed on the same network, , it is preferable
      to use NAT44 over NAT64 because of scale, performance and application
      incompatibility issues (e.g., FTP) <xref target="RFC6384"></xref>. At
      the same time, native IPv6 can still be preferred over IPv4. The DHCPv6
      Relay Agent can observe host characteristics on a network to determine
      if the host is IPV4-only, dual-stack or IPV6-only and also determine
      transitions from single to dual-stack or vice-versa. In this document we
      propose a specification that allows the DHCPv6 Relay Agent to influence
      the DHCPv6 Server to send appropriately prioritized DNS Servers to the
      client as per host 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>

      <t>'normal' DNS server : DNS server using an IPv4-mapped IPv6 address
      (that is, an IPv6 address starting with ::ffff:/96 IPv4-mapped prefix).
      Hosts can communicate with 'normal' DNS server only using IPv4 packets
      <xref target="RFC6052"></xref>, section 4.2.</t>

      <t>DNS64 server : DNS server using a normal IPv6 address and synthesizes
      AAAA records from A records <xref target="RFC6147"></xref></t>

      <t></t>
    </section>

    <section anchor="mechanism" title="Mechanism">
      <t>This document describes a new DHCPv6 Message and Option that is to be
      used by the DHCPv6 Relay Agent to indicate to the DHCPv6 Server of the
      priority of DNS servers to be provided to the specified host. The DHCPv6
      Server then sends a Reconfigure message to the host providing
      updated/re-ordered DNS server list as suggested by the Relay Agent. The
      idea is for the DHCPv6 Relay Agent to dynamically send the reconfigure
      message based on host characteristics.</t>

      <t><list style="numbers">
          <t><spanx style="strong">IPv6-only transition to Dual-Stack</spanx>
          In case a host is IPv6-only to start off, it is provided a DNS64
          Server. When transitioning to dual-stack, a IPv4 DNS Server is
          assigned as a consequence of obtaining an IPv4 Address. The DHCPv6
          Relay Agent can detect this and send RELAY-RECONFIG message <xref
          target="relay_reconfig_msg"> </xref> to the DHCPv6 Server indicating
          that the host needs to be needs to be provided with "normal" DNS
          Server followed by DNS64 server. In lieu of this mechanism, the host
          would continue to use the DNS64 server until the host stack
          Re-initializes.</t>

          <t><spanx style="strong">Dual-Stack to IPv6-only</spanx> In case a
          host is dual-stack, it is provided with "normal" DNS followed by
          DNS64 server. When transitioning to IPv6-only, the DHCPv6 Relay
          Agent can detect this and send a RELAY-RECONFIG message to the
          DHCPv6 Server indicating that the host needs to be assigned a DNS64
          server only. Without this, the host will continue to use the
          "normal" DNS Server which is inaccessible and eventually time out to
          fail over to the DNS64 Server. This means that the host will take
          additional time to fully initialize causing delays in
          connection.</t>

          <t><spanx style="strong">IPv4-only transition to Dual-Stack</spanx>
          In case a host is IPv4-only to start off, it is provided IPv4 DNS
          Server. When transitioning to dual-Stack, DNS64 server is also
          provided as a consequence of obtaining IPv6 address(s). The DHCPv6
          Relay Agent can detect this and send RELAY-RECONFIG message to the
          DHCPv6 Server indicating that the host needs to be provided with
          "normal" DNS Server followed by DNS64 server.</t>

          <t><spanx style="strong">Dual-Stack to IPv4-only</spanx> In case a
          host is dual-stack, it is provided with "normal" DNS followed by
          DNS64 server. When transitioning to IPv4-only, no change is required
          because the host continues to use "normal" server.</t>
        </list></t>
    </section>

    <section title="Protocol overview">
      <t>To realize the mechanism described above, this document extends the
      DHCPv6 protocol allowing the DHCPv6 relay-agent to inform DHCPv6 server
      to initiate a reconfigure message with the client, resulting in the
      client to initiate Renew/Reply or information-request/Reply transaction
      with the server to receive updated/new configuration information.</t>

      <figure anchor="fig_message_flow" title="Message Flow">
        <artwork align="center"><![CDATA[
DHCPv6 Client        DHCPv6 Relay Agent           DHCPv6 Server
      |                    |                              |
      |                    |----------------------------->|
      |                    |  DHCPv6 Relay-supplied       |
      |                    |   Reconfigure message        |
      |                    |                              |
      |                    |                              |
      |<--------------------------------------------------|
      |                    | DHCPv6 Reconfigure           |
      |                    |                              |
      |--------------------|----------------------------->|                         
      |           DHCPv6 Information-request              |
      |                    |                              |
      |<--------------------------------------------------|
      |              DHCPv6 Reply                         |
      |                    |                              |
]]></artwork>
      </figure>

      <t></t>

      <section anchor="relay_reconfig_msg" title="Message">
        <t>The RELAY-RECONFIG message uses the Client/Server message formats
        described in <xref target="RFC3315"> </xref>, section 6.</t>

        <t>RELAY-RECONFIG - A Relay Agent sends a RELAY-RECONFIG message to
        DHCPv6 server so that server can update configuration information
        based on the details in the Relay Reconfigure option. DHCPv6 server
        will subsequently initiate Reconfigure message with the client to
        propagate the new configuration information.</t>
      </section>

      <section title="Relay Reconfigure option">
        <t>The Relay Reconfigure option is used only in a RELAY-RECONFIG
        message and identifies the query being performed. The option includes
        the reconf-type, client-key and option(s) to provide data needed for
        the DHCPv6 server to initiate Reconfigure message with the client.</t>

        <t>The Relay Reconfigure option is defined below:</t>

        <figure anchor="fig_Relay_supplied_Prefix"
                title="Relay Reconfigure option 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_RELAY_RECONF          | option-len                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reconf-type   |  client-key   |        Reserved               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                  client-key-options                           .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Info-flags |              Reserved1                        |
-----------------------------------------------------------------
]]></artwork>
        </figure>

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

            <t hangText="reconf-type: ">5 for Renew message, 11 for
            Information-request message.</t>

            <t hangText="client-key:">8-bit unsigned integer. The client-key
            indicates the key to identify the client.</t>

            <t hangText="client-key-options:">8-bit unsigned integer. This
            option can contain either OPTION_IAADDR or OPTION_CLIENTID. The
            server identifies the client either using IPv6 address assigned to
            the client using OPTION_IAADDR option or using DHCP Unique
            Identifier (DUID) of the client in OPTION_CLIENTID option <xref
            target="RFC3315"></xref>.</t>
          </list></t>

        <t>client-key values are defined below -</t>

        <figure anchor="fig_values_1" title="client-key values">
          <artwork align="center"><![CDATA[
+------+--------------------------------
|Value | Name                          |
+------+--------------------------------
| 0x01 | IDENTIFY_CLIENT_BY_ADDRESS    |
| 0x02 | IDENTIFY_CLIENT_BY_CLIENTID   | 
+------+--------------------------------
]]></artwork>
        </figure>

        <t></t>

        <t>Info-flag values are defined below -</t>

        <figure anchor="fig_values_2" title="Info-flag values">
          <artwork align="center"><![CDATA[
+------+--------------------------------
|Value | Name                          |
+------+--------------------------------
| 0x01 | IPV6_DNS64_SERV_ONLY          |
| 0x02 | IPV6_HIG_PROI_NORM_SERV       | 
+------+--------------------------------
]]></artwork>
        </figure>

        <t></t>

        <t><list style="format %d:">
            <t><spanx style="strong">IPV6_DNS64_DNS_SERV_ONLY</spanx> Provide
            only DNS64 address list to the client.</t>

            <t><spanx style="strong">IPV6_HIG_PROI_NORM_SERV</spanx> Provide
            DNS address list in this order to the client - first "normal" DNS
            servers, second DNS64 servers.</t>
          </list></t>
      </section>
    </section>

    <section anchor="relay_agent" title="DHCPv6 Relay Agent Behaviour">
      <t>Relay Agent and clients MUST discard any received RELAY-RECONFIG
      messages. DHCPv6 relay agents that implement this specification MUST be
      configurable for sending the RELAY-RECONFIG message. Relay agents SHOULD
      have separate configuration for client-key in OPTION_RELAY_RECONF option
      . The Relay Agent sets the "msg-type" field to RELAY-RECONFIG. The Relay
      Agent generates a transaction ID and inserts this value in the
      "transaction-id" field. The Relay Agent MUST include OPTION_RELAY_RECONF
      option and set the reconf-type, client-key, client-key-options
      accordingly. The Relay Agent detects host characteristics using
      mechanisms discussed in <xref target="snooping"></xref>. For host
      transition from IPv6-only to dual-Stack or IPv4-only to dual-stack Relay
      Agent will set Info-flags with IPV6_HIG_PROI_NORM_SERV and for host
      transition from dual-stack to IPv6 only Relay-Agent will set Info-flags
      with IPV6_DNS64_SERV_ONLY. The Relay Reconfigure option is a general and
      extendable frame work such that in future based on changes to
      host/network characteristics, Relay agent can dynamically inform the
      DHCPv6 server to update the host with other configuration
      information.</t>
    </section>

    <section anchor="dhcp_server_behaviour" title="DHCPv6 Server Behaviour">
      <t>Servers MUST discard any received RELAY-RECONFIG messages that meet
      any of the following conditions :</t>

      <t><list style="symbols">
          <t>the message does not include OPTION_RELAY_RECONF option.</t>

          <t>DUID or IPv6 address in client-key-options does not match server
          binding to identify the client.</t>
        </list></t>

      <t>Client will have to indicate with a Reconfigure Accept option in the
      Solicit message that it will accept the Reconfigure message. Server can
      have administrative policy that it will only respond to a client willing
      to accept a Reconfigure message. If the client does not indicate that it
      will accept Reconfigure message in the Solicit message then the server
      will discard the Solicit Message.</t>

      <t>Upon receiving RELAY-RECONFIG message containing the Relay
      Reconfigure Option, the DHCPv6 server processing is described below
      depending on the Info-flag values:</t>

      <t><list style="symbols">
          <t><spanx style="strong">IPV6_DNS64_SERV_ONLY</spanx> The DHCPv6
          server will select only IPv6 addresses list of DNS64 recursive name
          servers to be sent to the client. The DHCPv6 server would send
          Reconfigure message to inform the client that the server has updated
          configuration information and then the client would initiate
          Information-request/replay transaction with the server. The updated
          configuration will now be sent as part of Information-request reply
          by the DHCPv6 server.</t>

          <t><spanx style="strong">IPV6_HIG_PROI_NORM_SERV</spanx> The DHCPv6
          server will select DNS servers in this order, first is the normal
          DNS servers and the second is the DNS64 servers. The DHCPv6 server
          would send Reconfigure message to the client to inform the client
          that the server has updated configuration information and then the
          client would initiate Information-request/replay transaction with
          the server. The updated configuration will now be sent as part of
          Information-request reply by the DHCPv6 server. The order of DNS
          servers provided by option OPTION_DNS_SERVERS determines the
          preference for use by the DNS client resolver <xref
          target="RFC3646"></xref> thus ensuring higher priority for normal
          DNS server list followed by DNS64 servers.</t>
        </list>DHCPv6 server will use mechanism described <xref
      target="RFC3315"> </xref>, section 19.1 to create and send Reconfigure
      message.</t>
    </section>

    <section anchor="snooping" title="Host Tracking">
      <t>Relay Agents can actively keep track of all IPv4/IPv6 addresses and
      associated lease times assigned to hosts via the respective DHCP
      servers. This enables Relay Agents to detect transitions from single to
      dual-stack and vice-versa efficiently. In addition to this technique,
      which is to be primarily used, transitions can also be detected using
      snooping mechanisms. Network devices today use mechanisms such as ARP
      and NDP snooping to determine host characteristics such as IPv4/IPv6 -
      MAC bindings. IPv4/IPv6 and MAC counters are also used to determine host
      liveliness. These mechanisms help determine if a particular IP is
      inactive. Relay Agents can leverage these to potentially detect IP
      address inactivity to determine if a particular host has reverted to
      using a single stack even though it initially had dual-stack
      capabilities. Similarly, it can also detect active dual-stack usage
      after long periods of single-stack activity.</t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>The RELAY-RECONFIG is exchanged only between the DHCPv6 relay agent
      and DHCPv6 server, 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>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>IANA is requested to assign new DHCPv6 Message types to
      RELAY-RECONFIG from the msg-type space as defined in section "DHCP
      Message Types" of <xref target="RFC3315"></xref>. IANA is requested to
      assign new option codes to OPTION_RELAY_RECONF from the option-code
      space as defined in section "DHCPv6 Options" of <xref
      target="RFC3315"></xref>.</t>
    </section>
  </middle>

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

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

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

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

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

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

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

      <?rfc include="reference.RFC.6384"?>
    </references>

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

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

      <?rfc include='reference.I-D.wing-behave-dns64-config'?>

      <!---->
    </references>
  </back>
</rfc>
