datatracker.ietf.org
Sign in
Version 5.7.4, 2014-11-12
Report a bug

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option
RFC 4704

Document type: RFC - Proposed Standard (October 2006; No errata)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 4704 (Proposed Standard)
Responsible AD: Margaret Wasserman
Send notices to: <ogud@ogud.com>, <okolkman@ripe.net>

Network Working Group                                            B. Volz
Request for Comments: 4704                           Cisco Systems, Inc.
Category: Standards Track                                   October 2006

   The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client
               Fully Qualified Domain Name (FQDN) Option

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document specifies a new Dynamic Host Configuration Protocol for
   IPv6 (DHCPv6) option that can be used to exchange information about a
   DHCPv6 client's Fully Qualified Domain Name (FQDN) and about
   responsibility for updating DNS resource records (RRs) related to the
   client's address assignments.

Volz                        Standards Track                     [Page 1]
RFC 4704             The DHCPv6 Client FQDN Option          October 2006

Table of Contents

   1. Introduction ....................................................3
   2. Terminology .....................................................3
   3. Models of Operation .............................................3
   4. The DHCPv6 Client FQDN Option ...................................4
      4.1. The Flags Field ............................................5
      4.2. The Domain Name Field ......................................6
   5. DHCPv6 Client Behavior ..........................................7
      5.1. Client Desires to Update AAAA RRs ..........................7
      5.2. Client Desires Server to Do DNS Updates ....................7
      5.3. Client Desires No Server DNS Updates .......................7
      5.4. Domain Name and DNS Update Issues ..........................8
   6. DHCPv6 Server Behavior ..........................................9
      6.1. When to Perform DNS Updates ................................9
   7. DNS RR TTLs ....................................................10
   8. DNS Update Conflicts ...........................................11
   9. IANA Considerations ............................................11
   10. Security Considerations .......................................12
   11. Acknowledgements ..............................................12
   12. References ....................................................13
      12.1. Normative References .....................................13
      12.2. Informative References ...................................13

Volz                        Standards Track                     [Page 2]
RFC 4704             The DHCPv6 Client FQDN Option          October 2006

1.  Introduction

   DNS ([2], [3]) maintains (among other things) the information about
   mapping between hosts' Fully Qualified Domain Names (FQDNs) [10] and
   IPv6 addresses assigned to the hosts.  The information is maintained
   in two types of Resource Records (RRs): AAAA and PTR [12].  The DNS
   update specification [4] describes a mechanism that enables DNS
   information to be updated over a network.

   The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [5]
   provides a mechanism by which a host (a DHCPv6 client) can acquire
   certain configuration information, along with its stateful IPv6
   address(es).  This document specifies a new DHCPv6 option, the Client
   FQDN option, which can be used by DHCPv6 clients and servers to
   exchange information about the client's fully qualified domain name
   and about who has the responsibility for updating the DNS with the
   associated AAAA and PTR RRs.

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

   Familiarity with the DNS Update protocol [4] and with DHCPv6 and its
   terminology, as defined in [5], is assumed.

3.  Models of Operation

   When a DHCPv6 client acquires an address, a site's administrator may
   desire that the AAAA RR for the client's FQDN and the PTR RR for the
   acquired address be updated.  Therefore, two separate DNS update
   transactions may occur.  Acquiring an address via DHCPv6 involves two
   entities: a DHCPv6 client and a DHCPv6 server.  In principle, each of

[include full document text]