<?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-ietf-dhc-conn-status-00" ipr="trust200902">
  <front>
    <title abbrev="Connectivy Status Notification">IP Connectivity Status
    Notifications for DHCPv6</title>

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

          <city>Rennes</city>

          <region></region>

          <code>35000</code>

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

        <email>mohamed.boucadair@orange.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>

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

    <date />

    <workgroup>DHC Working Group</workgroup>

    <abstract>
      <t>This specification extends DHCPv6 so that a DHCPv6 Relay Agent can
      dynamically inform the DHCPv6 server about the IP connectivity status of
      a host. The IP connectivity status information is also triggered by any
      change in the connectivity as provided to the host. The DHCPv6 server
      uses this information as an input to its decision-making about
      configuration parameters to be conveyed to that host.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>Some networks are expected to support IPv4-only, dual-stack, and
      IPv6-only hosts at the same time. Due to devices capabilities and
      available connectivity types, providing generic configuration from a
      DHCP server to connected hosts is sub-optimal in most cases, and may
      even break functionality in some cases. The network infrastructure is
      usually well equipped to be aware of the connectivty delivered to
      connected hosts. The network can also track and detect transitions from
      single to dual-stack or vice-versa.</t>

      <t>This document specifies a DHCPv6 extension for relay agents to
      indicate status of hosts connectivity to remote DHCPv6 servers. The
      information passed by a relay is generic and a DHCPv6 server can
      interpret and process this information to make a more informed decision
      on the configuration parameters that a client is to receive.</t>

      <t>The DHCPv6 server can either be configured or have built-in logic to
      use this information as desired, which is outside the scope of this
      document.</t>

      <t><xref target="dns"></xref> describes a typical problem that can be
      solved owing to the mechanism described in this specification. A DHCPv6
      server prioritizes the DNS servers to be sent back to a requesting
      client based on host connectivity characteristics provided by the DHCPv6
      relay agent.</t>

      <t>While the host stack can be upgraded to send this information to the
      DHCPv6 server on its own, a generalized upgrade of all DHCPv6 client
      implementations on all operating systems is extremely difficult.</t>

      <t><list style="empty">
          <t>[DISCUSSION NOTE: A companion solution could be to define a
          container that can be used to return per-AF specific configuration
          parameters to the client. In such a scheme, the server blindly
          returns all pieces of configuration and it is up to the client to
          make use of the appropriate set of parameters according to its
          available connectivity. This alternative assumes an update at the
          dhcp client's side. This approach can be seen as complimentary to
          the one defined in this specification. The document will be updated
          to reflect consensus of the WG on whether the additional option is
          to be specified.]</t>
        </list></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>Dual-Stack host: Denotes a host that is configured with both an IPv4
      address and IPv6 prefix and is reachable using both IPv4 and IPv6
      connectivity.</t>
    </section>

    <section anchor="dns"
             title="Problem Statement: Focus on DNS Reconfiguration">
      <t>Default address selection rules specified in <xref
      target="RFC6724"></xref> prefers IPv6 over IPv4. If a dual-stack host is
      configured to use a DNS64 server <xref target="RFC6147"></xref>, it will
      send its DNS queries to that DNS64 server which will synthesize a AAAA
      response if no A records are found. Thus, a dual-stack host will always
      use IPv6 if a DNS lookup was involved, even if IPv4 could have been used
      more optimally.</t>

      <t>In some deployments, if NAT44 <xref target="RFC3022"></xref> and
      NAT64 <xref target="RFC6146"></xref> are deployed within 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.</t>

      <t>A DHCPv6 relay agent can observe host characteristics on a network to
      determine if a host is IPv4-only, dual-stack, or IPv6-only and also
      detect transitions from single to dual-stack or vice-versa. This
      information can be used by the DHCPv6 relay agent to influence the
      DHCPv6 server to send appropriately prioritized DNS Servers to the
      client. The DHCPv6 server can implement the following based on
      connectivity information received from the DHCPv6 relay agent.</t>

      <t><list style="symbols">
          <t>IPv6-only transition to Dual-Stack: In case a host is IPv6-only,
          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 <xref
          target="RFC6977"></xref> to the DHCPv6 server indicating that the
          host needs to be provided with a regular DNS server. In lieu of this
          mechanism, the host would continue to use the DNS64 server until the
          host stack reinitializes.</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
          change and send a RECONFIGURE_REQUEST message to the DHCPv6 server
          indicating that the host needs to be assigned a DNS64 server only.
          In lieu of this mechanism, the host would continue to use the
          regular DNS Server which is inaccessible and eventually time out to
          fail over to the DNS64 Server. The host will take additional time to
          fully initialize causing delays in connection.</t>
        </list></t>
    </section>

    <section title="Host Connectivity Status Option">
      <t>The option (<xref target="fig_dyn_reconfigure"></xref>) includes an
      8-bit status code that indicates specific host connectivity
      characteristics. The option can be included by a DHCPv6 relay agent in
      RELAY-FORW and RECONFIGURE-REQUEST.</t>

      <t><figure anchor="fig_dyn_reconfigure"
          title="Relay Agent Host Connectivity 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_HOST_CONNECTIVITY    |          option-len           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    status     |                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    option-code   OPTION_HOST_CONNECTIVITY (TBA).
    option-len    1.
    status        8-bit field indicating IP family connectivity status
                  of a host. The following codes are defined:
                  +------+----------+
                  |  Bit | Status   |
                  +----- +----------+
                  |  1   | IPv4     |
                  |  2   | IPv6     | 
                  | 3..8 | Reserved |
                  +------+----------+                                   ]]></artwork>
        </figure><list style="symbols">
          <t>IPv4 : The host that is configured with an IPv4 address and is
          reachable using IPv4.</t>

          <t>IPv6 : The host that is configured with an IPv6 prefix and is
          reachable using IPv6.</t>

          <t>If both bits are enabled, the host is dual-stack i.e the host
          that is configured with both an IPv4 address and IPv6 prefix and is
          reachable using both IPv4 and IPv6 connectivity.</t>
        </list></t>
    </section>

    <section anchor="relay_agent" title="DHCPv6 Relay Agent Behavior">
      <t>DHCPv6 relay agents that implement this specification MUST be
      configurable for tracking host connectivity and inserting the
      OPTION_HOST_CONNECTIVITY option in RELAY-FORW and RECONFIGURE-REQUEST
      messages.</t>

      <t>To be able to notify details of hosts' connectivity, a DHCPv6 relay
      agent must be able to track host connectivity. A DHCPv6 relay agent can
      detect host connectivity type using mechanisms discussed in <xref
      target="snooping"></xref>. The DHCPv6 relay agent then includes this
      information in the appropriate DHCPv6 message.</t>

      <t>DHCPv6 relay agents need to maintain connectivity state of each host
      it can track. This ensures that notifications to the DHCPv6 server,
      especially DHCPv6 RECONFIGURE_REQUEST, are accurately sent when there is
      a change in status. If a DHCPv6 relay agent loses state due to some
      reason (e.g., during restart events), it will build state again using
      the mechanisms described in <xref target="snooping"></xref> and then
      send appropriate notifications to the server. Such notifications are
      redundant and a DHCPv6 server can choose to ignore such redundant
      notifications from the DHCPv6 relay agent. Redundant notifications are
      also possible when DHCPv6 relay agents are deployed in fault tolerant
      mode.</t>

      <section title="Relay Forward">
        <t>DHCPv6 relay agents that implement this specification MAY include
        the option OPTION_HOST_CONNECTIVITY in the RELAY_FORW to indicate
        status of host connectivity.</t>
      </section>

      <section title="Reconfigure Request">
        <t>DHCPv6 relay agents that implement this specification MUST be
        configurable for sending the RECONFIGURE_REQUEST message. The DHCPv6
        relay agent generates a Reconfigure-Request <xref
        target="RFC6977"></xref> anytime status of host connectivity changes
        by including OPTION_HOST_CONNECTIVITY in the request.</t>
      </section>
    </section>

    <section anchor="dhcp_server_behaviour" title="DHCPv6 Server Behavior">
      <t>A DHCPv6 server that supports OPTION_HOST_CONNECTIVITY may either
      have specific configuration or built-in logic to process information
      available in the option and send configuration parameters in DHCPv6
      responses. How the server consumes and acts on the information obtained
      in the option is outside the scope of this document.</t>

      <t>The DHCPv6 server may use this connectivity information, if
      available, in addition to other DHCPv6 relay agent option data, other
      options included in the DHCPv6 client messages, server configuration,
      and physical network topology information in order to assign appropriate
      configuration to the client.</t>

      <t>The server MUST ignore the option if it doesn't recognize the status
      in the OPTION_HOST_CONNECTIVITY option. The server SHOULD maintain the
      latest status received from the DHCPv6 relay agent. The server can use
      this state to match against subsequent notifications and only further
      process if there is change in status. A DHCPv6 relay agent could, for
      reasons such as restart, fault-tolerant mode etc, send redundant
      notifications and matching of status at the server will avoid
      unnecessary processing and message exchanges.</t>

      <section title="Relay Forward">
        <t>Upon receiving a RELAY-FORW message containing
        OPTION_HOST_CONNECTIVITY, the server can send appropriate
        configuration in the RELAY-REPLY response. The server MUST NOT return
        this option in a RELAY-REPLY message.</t>
      </section>

      <section title="Reconfigure Request">
        <t>Upon receiving a RECONIFURE-REQUEST message containing an
        OPTION_HOST_CONNECTIVITY option, the server MUST follow the mechanism
        described in <xref target="RFC6977"></xref> to create and send
        Reconfigure message. The server MUST NOT return this option in a
        RECONFIGURE-REPLY message.</t>
      </section>
    </section>

    <section anchor="snooping" title="Host Tracking">
      <t>DHCPv6 relay agents can actively keep track of all IPv4/IPv6
      addresses and associated lease times assigned to hosts via the
      respective DHCP servers. DHCPv6 relay agents can therefore detect
      transitions from single to dual-stack and vice-versa efficiently. In
      addition to this technique, DHCPv6 relay agents closest to the client
      can detect transitions using snooping mechanisms. Network devices today
      use mechanisms such as ARP and NDP snooping (bindings learnt by snooping
      all NDP traffic, NS, NA, RS, RA) to determine host characteristics such
      as IPv4/IPv6 - MAC - DUID bindings. IPv4/IPv6 and MAC counters are also
      used to determine host liveliness.</t>

      <t>First hop devices that implement first hop security features can also
      track IP address bindings and determine binding updates such as
      temporary addresses, deprecated addresses, etc. Existing work such as
      <xref target="I-D.ietf-savi-dhcp"></xref> and <xref
      target="I-D.levy-abegnoli-savi-plbt"></xref> also aim to active current
      host bindings, all of which can be leveraged to track host
      addresses.</t>

      <t>These mechanisms help determine if a particular IP address family is
      inactive, has reverted to using a single stack even though it initially
      had dual-stack capabilities and detect active dual-stack usage after
      long periods of single-stack activity.</t>

      <t>Other techniques to track host connectivity can be envisaged. It is
      out of scope of this document to provide an exhaustive list of host
      tracking techniques.</t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>This document describes an application of the mechanism specified in
      <xref target="RFC6977"></xref>. </t>

      <t>Host tracking mechanisms MUST be reliable. If a DHCPv6 relay agent is
      compromised, it may be used to force an uncompromised DHCPv6 server
      abuse DHCPv6 clients by triggering repetitive reconfigurations. Security
      considerations described in <xref target="RFC6977"></xref> are
      applicable to this specification.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>IANA is requested to assign the following new DHCPv6 Option Code in
      the registry maintained in http://www.iana.org/assignments/
      dhcpv6-parameters:<list style="symbols">
          <t>OPTION_HOST_CONNECTIVITY</t>
        </list></t>
    </section>
  </middle>

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

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

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

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

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

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

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

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

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

      <?rfc include='reference.I-D.ietf-savi-dhcp'
?>

      <?rfc include="reference.I-D.levy-abegnoli-savi-plbt"?>

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