<?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-dhc-dns-reconfigure-00"
     ipr="trust200902">
  <front>
    <title abbrev="dynamic_dhc_dns_reconfig">DHCPv6 Dynamic DNS
    Reconfiguration</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/>

          <street/>

          <city>Bangalore</city>

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

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

    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street/>

          <city>Rennes</city>

          <region/>

          <code>35000</code>

          <country>France</country>
        </postal>

        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>

    <date/>

    <workgroup>DHC 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.</t>

      <t>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="RFC6724"/> prefers
      IPv6 over IPv4. If a dual-stack host is configured to use a DNS64 server
      <xref target="RFC6147"/>, 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 <xref target="RFC6146"/> are deployed
      on the same network, it is preferable to use NAT44 over NAT64 for
      various reasons such as application incompatibility issues (e.g., FTP)
      <xref target="RFC6384"/> or for NAT dimensioning considerations. At the
      same time, native IPv6 can still be preferred over IPv4.</t>

      <t>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. The
      DHCPv6 Relay Agent can also be controlled by an external entity (e.g.,
      RADIUS server) about the connectivity type of a given connected host.
      This document proposes 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"/>.</t>

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

    <section anchor="mechanism" title="Mechanism">
      <t>This document describes a new DHCPv6 Option that can be used along
      with the DHCPv6 RECONFIGURE_REQUEST <xref
      target="I-D.ietf-dhc-triggered-reconfigure"/> by the DHCPv6 Relay Agent
      to indicate to the DHCPv6 Server 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>IPv6-only transition to dual-stack: In case a host is IPv6-only
          to start off, it is provided with a DNS64 Server. When transitioning
          to dual-stack, an IPv4 DNS Server is assigned as a consequence of
          obtaining an IPv4 Address. The DHCPv6 Relay Agent can detect this
          and send a RECONFIGURE_REQUEST message to the DHCPv6 Server
          indicating that the host needs to be provided with a regular 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>Dual-stack to IPv6-only: In case a host is dual-stack, it is
          provided with a regular DNS server followed by DNS64 server. When
          transitioning to IPv6-only, the DHCPv6 Relay Agent can detect this
          and send a RECONFIGURE_REQUEST 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 regular 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>Dual-stack to IPv4-only: In case a host is dual-stack, it is
          provided with a regular DNS server followed by DNS64 server. When
          transitioning to IPv4-only, no change is required because the host
          continues to use regular DNS server.</t>
        </list></t>
    </section>

    <section title="DNS_RECONFIG option">
      <t>The DNS_RECONFIG option is to be used only in a RECONFIGURE_REQUEST
      message and identifies the query being performed. The option includes a
      flag that determines the DNS server list to be provided by the DHCPv6
      server to the respective client.</t>

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

      <figure anchor="fig_dns_reconfigure"
              title="DNS 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_DNS_RECONFIG          | option-len                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Info-flags |              Reserved1                        |
-----------------------------------------------------------------
]]></artwork>
      </figure>

      <t/>

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

      <figure anchor="fig_values" 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><list style="hanging">
          <t hangText="IPV6_DNS64_SERV_ONLY:">Provide only DNS64 address list
          to the client.</t>

          <t hangText="IPV6_DNS64_SERV_ONLY:">Provide DNS address list in this
          order to the client - first regular DNS servers, second DNS64
          servers.</t>
        </list></t>
    </section>

    <section anchor="relay_agent" title="DHCPv6 Relay Agent Behaviour">
      <t>DHCPv6 relay agents that implement this specification MUST be
      configurable for sending the RECONFIGURE_REQUEST message. The Relay
      Agent MUST set the "msg-type" field to RECONFIGURE_REQUEST. The Relay
      Agent detects host characteristics using mechanisms discussed in <xref
      target="snooping"/>. 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.</t>

      <t>The content of OPTION_DNS_RECONFIG MAY also be tweaked by an external
      entity.</t>
    </section>

    <section anchor="dhcp_server_behaviour" title="DHCPv6 Server Behaviour">
      <t>Upon receiving RECONFIGURE_REQUEST message containing the
      DNS_RECONFIG Option, the DHCPv6 server processing is described below
      depending on the Info-flag values:</t>

      <t><list style="symbols">
          <t>IPV6_DNS64_SERV_ONLY: 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>IPV6_HIG_PROI_NORM_SERV: The DHCPv6 server will select DNS
          servers in this order, first is the regular 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"/> thus ensuring higher priority for regular DNS
          server list followed by DNS64 servers.</t>
        </list>DHCPv6 server will follow the mechanism described <xref
      target="I-D.ietf-dhc-triggered-reconfigure"/> 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>Security considerations described in <xref
      target="I-D.ietf-dhc-triggered-reconfigure"/>are applicable to this
      mechanism.</t>
    </section>

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

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

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

      <?rfc include="reference.I-D.ietf-dhc-triggered-reconfigure"?>

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

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

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

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

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