[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

BEHAVE Working Group                                             D. Wing
Internet-Draft                                                  T. Reddy
Intended status: Standards Track                                P. Patil
Expires: May 3, 2012                                               Cisco
                                                        October 31, 2011


                    DHCPv6 Dynamic Re-Configuration
                draft-wing-behave-dhcpv6-reconfigure-01

Abstract

   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.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 3, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Wing, et al.               Expires May 3, 2012                  [Page 1]


Internet-Draft           dhcpv6_dynamic_reconfig            October 2011


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Mechanism  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Protocol overview  . . . . . . . . . . . . . . . . . . . . . .  4
     4.1.  Message  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.2.  Relay Reconfigure option . . . . . . . . . . . . . . . . .  5
   5.  DHCPv6 Relay Agent Behaviour . . . . . . . . . . . . . . . . .  7
   6.  DHCPv6 Server Behaviour  . . . . . . . . . . . . . . . . . . .  7
   7.  Host Tracking  . . . . . . . . . . . . . . . . . . . . . . . .  8
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     10.1. Normative References . . . . . . . . . . . . . . . . . . .  9
     10.2. Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10



























Wing, et al.               Expires May 3, 2012                  [Page 2]


Internet-Draft           dhcpv6_dynamic_reconfig            October 2011


1.  Introduction

   The default address selection rules [RFC3484] 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) [RFC6384].  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.


2.  Terminology

   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 [RFC2119].

   '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 [RFC6052], section 4.2.

   DNS64 server : DNS server using a normal IPv6 address and synthesizes
   AAAA records from A records [RFC6147]


3.  Mechanism

   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.

   1.  *IPv6-only transition to Dual-Stack* 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



Wing, et al.               Expires May 3, 2012                  [Page 3]


Internet-Draft           dhcpv6_dynamic_reconfig            October 2011


       this and send RELAY-RECONFIG message Section 4.1 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.

   2.  *Dual-Stack to IPv6-only* 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.

   3.  *IPv4-only transition to Dual-Stack* 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.

   4.  *Dual-Stack to IPv4-only* 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.


4.  Protocol overview

   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.













Wing, et al.               Expires May 3, 2012                  [Page 4]


Internet-Draft           dhcpv6_dynamic_reconfig            October 2011


      DHCPv6 Client        DHCPv6 Relay Agent           DHCPv6 Server
            |                    |                              |
            |                    |----------------------------->|
            |                    |  DHCPv6 Relay-supplied       |
            |                    |   Reconfigure message        |
            |                    |                              |
            |                    |                              |
            |<--------------------------------------------------|
            |                    | DHCPv6 Reconfigure           |
            |                    |                              |
            |--------------------|----------------------------->|
            |           DHCPv6 Information-request              |
            |                    |                              |
            |<--------------------------------------------------|
            |              DHCPv6 Reply                         |
            |                    |                              |

                          Figure 1: Message Flow

4.1.  Message

   The RELAY-RECONFIG message uses the Client/Server message formats
   described in [RFC3315], section 6.

   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.

4.2.  Relay Reconfigure option

   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.

   The Relay Reconfigure option is defined below:













Wing, et al.               Expires May 3, 2012                  [Page 5]


Internet-Draft           dhcpv6_dynamic_reconfig            October 2011


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

             Figure 2: Relay Reconfigure option message format

   option-len:  Length of the option.

   reconf-type:   5 for Renew message, 11 for Information-request
      message.

   client-key:  8-bit unsigned integer.  The client-key indicates the
      key to identify the client.

   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 [RFC3315].

   client-key values are defined below -

                  +------+--------------------------------
                  |Value | Name                          |
                  +------+--------------------------------
                  | 0x01 | IDENTIFY_CLIENT_BY_ADDRESS    |
                  | 0x02 | IDENTIFY_CLIENT_BY_CLIENTID   |
                  +------+--------------------------------

                        Figure 3: client-key values

   Info-flag values are defined below -







Wing, et al.               Expires May 3, 2012                  [Page 6]


Internet-Draft           dhcpv6_dynamic_reconfig            October 2011


                  +------+--------------------------------
                  |Value | Name                          |
                  +------+--------------------------------
                  | 0x01 | IPV6_DNS64_SERV_ONLY          |
                  | 0x02 | IPV6_HIG_PROI_NORM_SERV       |
                  +------+--------------------------------

                        Figure 4: Info-flag values

   1:  *IPV6_DNS64_DNS_SERV_ONLY* Provide only DNS64 address list to the
       client.

   2:  *IPV6_HIG_PROI_NORM_SERV* Provide DNS address list in this order
       to the client - first "normal" DNS servers, second DNS64 servers.


5.  DHCPv6 Relay Agent Behaviour

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


6.  DHCPv6 Server Behaviour

   Servers MUST discard any received RELAY-RECONFIG messages that meet
   any of the following conditions :

   o  the message does not include OPTION_RELAY_RECONF option.

   o  DUID or IPv6 address in client-key-options does not match server
      binding to identify the client.




Wing, et al.               Expires May 3, 2012                  [Page 7]


Internet-Draft           dhcpv6_dynamic_reconfig            October 2011


   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.

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

   o  *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.

   o  *IPV6_HIG_PROI_NORM_SERV* 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 [RFC3646] thus
      ensuring higher priority for normal DNS server list followed by
      DNS64 servers.

   DHCPv6 server will use mechanism described [RFC3315], section 19.1 to
   create and send Reconfigure message.


7.  Host Tracking

   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



Wing, et al.               Expires May 3, 2012                  [Page 8]


Internet-Draft           dhcpv6_dynamic_reconfig            October 2011


   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.


8.  Security Considerations

   The RELAY-RECONFIG is exchanged only between the DHCPv6 relay agent
   and DHCPv6 server, section 21.1 of [RFC3315] provides details on
   securing DHCPv6 messages sent between servers and relay agents.  And
   section 23 of [RFC3315] provides general DHCPv6 security
   considerations.


9.  IANA Considerations

   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 [RFC3315].  IANA is requested to assign new option codes to
   OPTION_RELAY_RECONF from the option-code space as defined in section
   "DHCPv6 Options" of [RFC3315].


10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3484]  Draves, R., "Default Address Selection for Internet
              Protocol version 6 (IPv6)", RFC 3484, February 2003.

   [RFC3646]  Droms, R., "DNS Configuration options for Dynamic Host
              Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
              December 2003.

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
              October 2010.




Wing, et al.               Expires May 3, 2012                  [Page 9]


Internet-Draft           dhcpv6_dynamic_reconfig            October 2011


   [RFC6147]  Bagnulo, M., Sullivan, A., Matthews, P., and I. van
              Beijnum, "DNS64: DNS Extensions for Network Address
              Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
              April 2011.

   [RFC6384]  van Beijnum, I., "An FTP Application Layer Gateway (ALG)
              for IPv6-to-IPv4 Translation", RFC 6384, October 2011.

10.2.  Informative References

   [I-D.wing-behave-dns64-config]
              Wing, D., "IPv6-only and Dual Stack Hosts on the Same
              Network with DNS64", draft-wing-behave-dns64-config-03
              (work in progress), February 2011.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

   [RFC5007]  Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
              "DHCPv6 Leasequery", RFC 5007, September 2007.


Authors' Addresses

   Dan Wing
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, California  95134
   USA

   Email: dwing@cisco.com


   Tirumaleswar Reddy
   Cisco Systems, Inc.
   Cessna Business Park, Varthur Hobli
   Sarjapur Marathalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: tireddy@cisco.com









Wing, et al.               Expires May 3, 2012                 [Page 10]


Internet-Draft           dhcpv6_dynamic_reconfig            October 2011


   Prashanth Patil
   Cisco Systems, Inc.
   Cessna Business Park, Varthur Hobli
   Sarjapur Marthalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: praspati@cisco.com











































Wing, et al.               Expires May 3, 2012                 [Page 11]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/