--- /dev/null
+
+
+
+ INTERNET-DRAFT S. Daniel Park
+ Expires: October 2003 Syam Madanapalli
+ File: SAMSUNG Electronics
+ draft-park-ipv6-extensions-dns-pnp-00.txt April 2003
+
+
+
+
+ IPv6 Extensions for DNS Plug and Play
+
+
+
+ Status of This Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ 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."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+
+
+ Abstract
+
+ This document proposes automatic configuration of domain name (FQDN)
+ for IPv6 nodes using Domain Name Auto-Configuration (called 6DNAC) as
+ a part of IPv6 plug and play feature. 6DNAC allows the automatic
+ registration of domain name and corresponding IPv6 Addresses with
+ the DNS server. In order to provide 6DNAC function, Neighbor Discovery
+ Protocol [2461] will be used. Moreover, 6DNAC does not require any
+ changes to the existing DNS system.
+
+
+ Table of Contents
+
+ 1. Introduction ............................................. 3
+ 2. Terminology .............................................. 3
+ 3. 6DNAC Design Principles .................................. 4
+ 4. 6DNAC Overview ........................................... 4
+ 5. 6DNAC Requirements ....................................... 5
+ 5.1. 6DANR Client Requirements ................................ 5
+ 5.2. 6DNAC Server Requirements ................................ 6
+
+Park & Madanapalli Expires October 2003 [Page 1]
+\f
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ 6. 6DNAC Messages and Option Formats ........................ 6
+ 6.1. Router Advertisement (RA) Message Format ................. 6
+ 6.2. Neighbor Solicitation (NS) Message Format ................ 7
+ 6.3. Neighbor Advertisement (NA) Message Format ............... 8
+ 6.4. Option Formats ........................................... 8
+ 6.4.1. DNS Zone Suffix Information Option Format ................ 8
+ 6.4.2. Domain Name (FQDN) Option Format ......................... 9
+ 6.4.3. Router Alert Option for 6DNAC ............................ 10
+ 7. 6DNAC Operation .......................................... 10
+ 7.1. 6DNAC Network Topology ................................... 11
+ 7.2. 6DNAC Operational Scenarios .............................. 12
+ 7.2.1. Domain Name Registration-Success Case .................... 12
+ 7.2.2. Domain Name Registration-with DupAddrDetectTransmits=2.... 14
+ 7.2.3. Domain Name Registration-Defend Case ..................... 16
+ 7.2.4. Domain Name Registration in Retry Mode ................... 19
+ 7.2.5. Domain Name Registration when DAD Fails .................. 20
+ 7.3. DNS Zone Suffix Discovery and FQDN Construction .......... 22
+ 7.3.1. Sending Router Advertisement Messages .................... 22
+ 7.3.2. Processing Router Advertisement Messages ................. 22
+ 7.3.3. FQDN Lifetime expiry ..................................... 23
+ 7.3.4. Host Naming Algorithm .................................... 23
+ 7.4. Duplicate Domain Name Detection .......................... 23
+ 7.4.1. DAD with All Nodes Multicast Address ..................... 24
+ 7.4.1.1. Sending Neighbor Solicitation Messages ................... 24
+ 7.4.1.2. Processing Neighbor Solicitation Messages ................ 24
+ 7.4.1.3. Sending Neighbor Advertisement Messages .................. 25
+ 7.4.1.4. Processing Neighbor Advertisement Messages ............... 25
+ 7.4.1.5. Pros and Cons ............................................ 25
+ 7.4.2. DAD with Router Alert Option for 6DNAC ................... 25
+ 7.4.2.1. Sending Neighbor Solicitation Messages ................... 25
+ 7.4.2.2. Processing Neighbor Solicitation Messages ................ 26
+ 7.4.2.3. Sending Neighbor Advertisement Messages .................. 26
+ 7.4.2.4. Processing Neighbor Advertisement Messages ............... 26
+ 7.4.2.5. Pros and Cons ............................................ 26
+ 7.4.3. Explicit Detection of Duplicate Domain Name .............. 26
+ 7.4.3.1. Sending Neighbor Solicitation Messages ................... 26
+ 7.4.3.2. Processing Neighbor Solicitation Messages ................ 26
+ 7.4.3.3. Sending Neighbor Advertisement Messages .................. 27
+ 7.4.3.4. Processing Neighbor Advertisement Messages ............... 27
+ 7.4.3.5. Pros and Cons ............................................ 27
+ 7.4.4. Retry Mode for Re-registering Domain Name ................ 27
+ 7.5. Domain Name Registration ................................. 27
+ 8. Security Consideration ................................... 27
+ 9. IANA Consideration ....................................... 28
+ 10. Acknowledgement .......................................... 28
+ 11. Intellectual Property .................................... 28
+ 12. Copyright ................................................ 28
+ 13. References ............................................... 29
+ 14. Author's Addresses ....................................... 30
+
+
+
+
+
+
+
+
+Park & Madanapalli Expires October 2003 [Page 2]
+\f
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ 1. Introduction
+
+ Today, most networks use DNS[1034][1035] for convenience. In case of
+ IPv6, DNS is more important element because of IPv6 long addresses
+ which are difficult to remember. In addition, small networks like home
+ networks using IPv6, should be able to make network easily without
+ manual configuration. Also, these small networks may not have DHCP
+ Server, DNS Server etc. that are used to configure the network. This
+ document discusses IPv6 Domain Name Auto-Configuration(6DNAC) procedure
+ for generating and registering the Domain Name and IPv6 addresses with
+ the DNS Server automatically. In order to use 6DNAC, IPv6 nodes are
+ required to implement lightweight functions specified in this document.
+ 6DNAC can be applied to all defined IPv6 unicast addresses except Link
+ local IPv6 addresses, viz: Site-local and Global addresses.
+
+ 6DNAC uses Neighbor Discovery Protocol [2461] with new additions
+ (defined in section 6) and DAD procedures for generating and
+ registering the Domain Name with the DNS server automatically.
+
+
+ 2. Terminology
+
+ 6DNAC - IPv6 Domain Name Auto Configuration. It can provide
+ IPv6 hosts with Domain Name Generation and
+ Registration automatically.
+
+ 6DNAC Client - An IPv6 node that can generate its own unique Domain
+ Name. Section 3 identifies the new requirements that
+ 6DNAC places on an IPv6 node to be a 6DNAC node.
+
+ 6DNAC Server - An IPv6 node that can collect and registrate Domain
+ Name and IPv6 addresses automatically. 6DNAC server
+ uses the information from the DAD operation messages
+ with newly defined options for the registration of the
+ Domain Name and IPv6 Addresses. Section 3 identifies
+ the new requirements that 6DNAC places on an IPv6
+ node to be a 6DNAC server. Also 6DNAC server can have
+ various other functions depending on network
+ environment and the network operator. For instance
+ 6DNAC Server can acts as a Gateway as well Home Server
+ in Home Networks.
+
+ DAD - Duplicate Address Detection (is defined [2461])
+
+ DFQDND - Duplicate Domain Name Detection
+
+ FQDN - Fully Qualified Domain Name - FQDN and Domain Name are
+ used interchangeably in this document.
+
+ NA - Neighbor Advertisement message (is defined [2461])
+
+ NS - Neighbor Solicitation message (is defined [2461])
+
+ RA - Router Advertisement message (is defined [2461])
+
+ SLAAC - Stateless Address Autoconfiguration [2462].
+
+Park & Madanapalli Expires October 2003 [Page 3]
+\f
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ 3. 6DNAC Design Principles
+
+ This section discusses the design principles of 6DNAC mechanism.
+
+ 1. The new procedures for plug and play DNS should not cause changes
+ to existing DNS system. 6DNAC requires lightweight functions to be
+ implemented only at the client side of the DNS system, and uses the
+ existing DDNS UPDATE [2136] to communicate with DNS Servers.
+
+ 2. Introducing a new protocol will always introduce new problems.
+ 6DNAC uses the existing protocols NDP [2461] with minor extensions
+ for generating and registering the domain name automatically
+ without defining a new protocol
+
+ 3. Reusing proven and well understood design principles/patterns
+ will always yield a robust system. 6DNAC is based on IPv6 Address
+ Auotoconfiguration principle, where routers advertise the prefix
+ and host adds the interface ID to the prefix and forms the IPv6
+ address. Domain Name (FQDN) also contains two parts: host name
+ and DNS zone suffix. Routers can advertise the DNS zone suffix
+ on a particular link in Router Advertisements (RA Messages) and
+ hosts can prefix their preferred host name to the DNS zone suffix
+ and form the fully qualified domain name. Also the detection of
+ duplicate domain name is similar to Duplicate Address Detection
+ (DAD) and can be part of DAD operation itself.
+
+
+ 4. 6DNAC Overview
+
+ 6DNAC proposes minor extensions to NDP [2461] for automatic generation
+ and registration of domain name with the DNS server. It introduces two
+ new options: DNS Zone Suffix and Fully Qualified Domain Name. DNS Zone
+ Suffix option is carried in Router Advertisement (RA) messages for
+ notifying IPv6 nodes about the valid DNS Zone Suffix on the link and
+ FQDN option in Neighbor Solicitation (NS) and Neighbor Advertisement
+ (NA) messages to detect duplicate domain name. 6DNAC consists of two
+ components: 6DNAC Client and 6DNAC Server. 6DNAC Clients generate the
+ domain name based on DNS Zone Suffix using Host Naming Algorithm (see
+ section 7.3.1) and 6DNAC Server collects and registers the DNS
+ information with the DNS Server on behalf of 6DNAC Clients.
+
+ The automatic configuration of domain name using 6DNAC consists of
+ three parts.
+
+ - DNS Zone Suffix Discovery and FQDN Construction:
+
+ IPv6 Nodes collect DNS Zone Suffix information from Router
+ Advertisements and constructs FQDN by prefixing host name to the
+ DNS Zone Suffix. The IPv6 Nodes are required to implement Host
+ Naming Algorithm for generating host part of the FQDN in the
+ absence of administrator.
+
+ Generation of node's FQDN within the node itself has advantages. Nodes
+ can provide forward and reverse name lookups independent of the DNS
+ System by sending queries directly to IPv6 nodes [NIQ]. Moreover Domain
+ Name is some thing that is owned by the node.
+
+Park & Madanapalli Expires October 2003 [Page 4]
+\f
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ - Duplicate Domain Name Detection
+
+ All nodes are expected to go for DAD for all new IPv6 unicast
+ addresses, regardless of whether they are obtained through
+ stateful, stateless or manual configuration. 6DNAC uses the DAD
+ messages with new option for carrying the Domain Name along with
+ the new IPv6 Address. 6DNAC Server captures this information and
+ updates DNS Server provided that the IPv6 Address and its domain
+ name are not duplicate. If the domain name is already in use,
+ the 6DNAC server replies to the sender with FQDN Option in NA
+ message indicating that the domain name is duplicate. Then the
+ node is expected to generate another domain name using host
+ naming algorithm and go for DAD. This time the DAD is only for
+ duplicate domain name detection (DFQDND). In order to avoid
+ confusion with the normal NDP processing, the target address
+ field of the NS message must carry the unspecified address
+ in retry mode. This can be repeated depending on number of
+ retries defined by the administrator in the host naming algorithm.
+
+
+ - Domain Name Registration
+
+ 6DNAC Server detects the DNS information (IPv6 Address and
+ corresponding FQDN) from DAD/DFQDND messages and updates DNS
+ Server using existing protocol DDNS UPDATE [2136] provided that
+ the IPv6 Address and its domain name are not duplicate.
+
+ If an IPv6 Address is duplicate, the IPv6 node cannot perform
+ stateless address autoconfiguration repeatedly. Unlike IPv6 stateless
+ address autoconfiguration, 6DNAC allows the automatic configuration of
+ domain name repeatedly if the domain name is duplicate depending on
+ number of retries defined by the administrator in the host naming
+ algorithm.
+
+
+ 5. 6DNAC Requirements
+
+ Depending on the 6DNAC functionality, the IPv6 nodes implement, they
+ are called either 6DNAC Clients or 6DNAC Servers. The following
+ sections lists the requirements that the 6DNAC Client and 6DNAC server
+ must support.
+
+
+ 5.1. 6DANC Client Requirements
+
+ - 6DNAC Client must recognize and process the following NDP
+ extensions
+
+ - DNS Zone Suffix option in RA messages for generating its
+ domain name (FQDN).
+
+ - Domain Name option in NS and NA messages for detecting
+ the duplicate domain name
+
+
+
+
+Park & Madanapalli Expires October 2003 [Page 5]
+\f
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ - It must generate its domain name (FQDN) based on the DNS
+ suffix that it got from the router advertisement. And it must
+ have a host naming algorithm for generating the host part of
+ the FQDN.
+
+ - If NA message is received with unspecified target address and
+ FQDN option, then the node must treat that the domain is
+ duplicate.
+
+
+ 5.2. 6DNAC Server Requirements
+
+ - 6DNAC Server must recognize and process the following NDP
+ extensions
+
+ - If the 6DNAC Server is a router on the link, then it
+ must advertise DNS Zone Suffix option in RA messages
+ for hosts to generate their domain name (FQDN).
+
+ - FQDN option in NS messages for detecting new DNS
+ information for of nodes on the link for which it
+ must update the AAAA RR and PTR RR in DNS Server.
+
+ - FQDN option in NA messages for notifying duplicate
+ domain name with unspecified target address.
+
+ - 6DNAC server must update the DNS Server (both AAAA RR and
+ PTR RR) dynamically using DDNS UPDATE [2136].
+
+ - 6DNAC server must cache this (newly detected) FQDN, Link
+ Layer Address, and IPv6 Address information, so that it can
+ decide whether it really needs to update DNS Server or not,
+ to avoid redundant updates. This information will also be
+ used for notifying the duplicate domain name.
+
+
+ 6. 6DNAC Messages and Option Formats
+
+ In order to achieve the plug and play DNS, 6DNAC proposes new
+ extensions to the NDP [2461]. This section specifies the new
+ additions to NDP messages and formats of new options.
+
+
+ 6.1. Router Advertisement (RA) Message Format
+
+ Routers send out Router Advertisement (RA) message periodically, or
+ in response to a Router Solicitation. 6DNAC does not modify the format
+ of the RA message, but proposes new option (DNS Zone Suffix Information)
+ to be carried in RA messages.
+
+
+
+
+
+
+
+
+Park & Madanapalli Expires October 2003 [Page 6]
+\f
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Code | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Cur Hop Limit |M|O| Reserved | Router Lifetime |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reachable Time |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Retrans Timer |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Options ... |
+ / /
+ | DNS Zone Suffix Information |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ <Figure: 1 RA message>
+
+
+
+ 6.2. Neighbor Solicitation (NS) Message Format
+
+ 6DNAC does not modify the format of the Neighbor Solicitation (NS)
+ message, but proposes new option (FQDN Option) to be carried in NS
+ messages. When a node is going for DAD, the node must include FQDN
+ option in NS message to participate in plug and play DNS. If the
+ node is going for Explicit Detection of Duplicate Domain Name, the
+ node must use FQDN option in NS message and unspecified address in
+ the target address field.
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Code | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | |
+ + Target Address +
+ | |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Options ... |
+ / /
+ | Domain Name |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ <Figure: 2 NS message>
+
+Park & Madanapalli Expires October 2003 [Page 7]
+\f
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ 6.3. Neighbor Advertisement (NA) Message Format
+
+ 6DNAC does not modify the format of the Neighbor Advertisement (NA)
+ message, but proposes new option (FQDN Option) to be carried in NA
+ messages. 6DNAC Server sends NA message with FQDN option to 6DNAC
+ Client that is performing duplicate domain name detection in case
+ the domain name found to be duplicate.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Code | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |R|S|O| Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | |
+ + Target Address +
+ | |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Options ... |
+ / /
+ | FQDN Option |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ <Figure: 3 NA message>
+
+
+ 6.4 Option Formats
+
+ 6.4.1. DNS Zone Suffix Information Option Format
+
+ IPv6 nodes require DNS Zone Suffix for constructing their FQDN.
+ 6DNAC introduces new option for routers to advertise the DNS Zone
+ Suffix Information for IPv6 nodes on the link. The suffix information
+ should be configured into routers manually.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Valid Lifetime |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ / DNS Zone Suffix /
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ <Figure: 4 DNS Zone Suffix Information>
+
+Park & Madanapalli Expires October 2003 [Page 8]
+\f
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ Type [TBD]
+
+ Length 8-bit unsigned integer. The length of the option
+ (including the type and length fields) in units of
+ 8 octets.
+
+ Reserved This field is unused. It must be initialized to zero
+ by the sender and must be ignored by the receiver.
+
+ Valid Life Time 32-bit signed integer. The maximum time, in
+ seconds, over which this suffix is valid. Nodes
+ should treat this as the life time for their domain
+ name. Nodes should contact the source of this
+ information before expiry of this time interval.
+ A value of all one bits (0xFFFFFFFF) represents
+ infinity.
+
+ DNS Zone Suffix The suffix part of the FQDN. The data in the DNS
+ Zone Suffix field should be encoded according to
+ DNS encoding rules specified in [1035].
+
+
+
+ 6.4.2. Domain Name (FQDN) Option Format
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Valid Lifetime |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | |
+ + FQDN Target Address +
+ | |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ / Domain Name /
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ <Figure: 5 FQDN Information>
+
+ Type [TBD]
+
+ Length 8-bit unsigned integer. The length of the option
+ (including the type and length fields) in units
+ of 8 octets. It must be greater than 3.
+
+
+
+Park & Madanapalli Expires October 2003 [Page 9]
+\f
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ Reserved This field is unused. It must be initialized to
+ zero by the sender and must be ignored by the
+ receiver.
+
+ Valid Life Time 32-bit signed integer. The maximum time, in
+ seconds, over which this domain name is valid
+ 6DNAC should deregister this domain name at
+ the expiry of this interval. 6DNAC clients
+ should send updates by the expiry of this
+ interval. A value of all one bits (0xFFFFFFFF)
+ represents infinity.
+
+ FQDN Target Address The Address for which the FQDN maps to. It
+ should be same as Target Address field of the
+ NS message in case of DAD & duplicate FQDN are
+ running in parallel.
+
+ Domain Name The domain name (FQDN) of the node. The data in
+ the domain name should be encoded according to
+ DNS encoding rules specified in [1035].
+
+
+ 6.4.3. Router Alert Option for 6DNAC
+
+ Router Alert Option for 6DNAC is new option within the IPv6 Hop-by-Hop
+ Header for using in NDP messages. The presence of this option in NS
+ message informs the router that this NS message is carrying Domain
+ Name information and must be processed by the 6DNAC Server on the router.
+ 6DNAC Clients can use this option for sending DAD packets instead
+ of addressing the DAD packets to the all-nodes multicast address
+ when 6DNAC Server is implemented on router.
+
+ The Router Alert option has the following format:
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0 0 0|0 0 1 0 1|0 0 0 0 0 0 1 0| Value (2 octets) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Length = 2
+
+ Values are registered and maintained by the IANA. For 6DNAC, the
+ value has to be assigned by IANA.
+
+ Further information about this option can be obtained from
+ IPv6 Router Alert Option [2711].
+
+
+ 7. 6DNAC Operation
+
+ 6DNAC provides mechanisms for automatic generation of domain name
+ and registering it with the DNS Server for IPv6 nodes. 6DNAC consists
+ of two components: 6DNAC Client and 6DNAC Server. All nodes that want
+ to participate in plug and play DNS are required to implement 6DNAC
+ Client functionality, and one of the IPv6 nodes is required to
+ implement 6DNAC Server functionality. The IPv6 node that implements
+ the 6DNAC Server functionality must know the location of the DNS
+ Server and must be a trusted node to send DDNS UPDATE [2136] messages.
+
+Park & Madanapalli Expires October 2003 [Page 10]
+\f
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ 7.1. 6DNAC Network Topology
+
+ This section identifies the possible locations for the 6DNAC Server.
+ Note that, all nodes are required to implement 6DNAC Client
+ functionality for constructing the domain name from the DNS Zone
+ Suffix Information advertised by the router. Figure 6 illustrates
+ IPv6 host (H4) implementing 6DNAC Server functionality. In this case
+ H4 can serve only one link (that it belongs to) for automatic
+ registration of domain name. H4 must observe the DAD packets on the
+ link to detect the DNS information, this requires all nodes on the
+ link must belong to same solicited node multicast address. In general,
+ this may not be the case. So the node that is going for DAD must use
+ all nodes multicast address for DAD packets, so that the 6DNAC Server
+ (H4) can observe the DAD packets, detects IPv6 address and
+ corresponding domain name, checks if this domain name is duplicate
+ and finally registers the domain name with the DNS Server.
+
+
+ 6DNAC Server
+ +---+ +---+ +----------+
+ | H1| | H4|<--- DDNS UPDATE --->|DNS Server|
+ +-+-+ +-+-+ +----+-----+
+ | | +----+ +---/
+ | | | | /
+ ---+-----+-----------+-----+-----------+ R1 +-----+
+ | | | |
+ | | +----+
+ +-+-+ +-+-+
+ | H2| | H3|
+ +---+ +---+
+
+
+ H1, H2, H3 - 6DNAC Clients
+ H4 - 6DNAC Server
+ R1 - Router
+
+
+ <Figure: 6 Example of 6DNAC Topology>
+
+
+ Figure 7 shows the 6DNAC Server implemented on a router R1. In this
+ case a single 6DNAC server can serve multiple links for automatic
+ configuration of the domain name. This topology also has flexibility
+ of using DAD packets with Router Alert option instead of sending DAD
+ packets to all nodes multicast address. The routers are required to
+ process all the packets with Router Alert option as per [2711].
+
+ In case of Home Networks, R1 is will acts as a Home Gateway (CPE)
+ connected to ISP. R1 delegates the prefix from the ISP edge router.
+ After delegating the prefix the CPE can advertise the DNS Zone suffix
+ along with the prefix information to the nodes on the links to which
+ the router is connected to. Note that the R1 must be configured with
+ the DNS Zone suffix Information manually.
+
+
+
+
+Park & Madanapalli Expires October 2003 [Page 11]
+\f
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ +---+ +---+
+ | H3+ | H4|
+ +-+-+ +-+-+
+ | |
+ | LINK2 |
+ +---+ ---+--------+--+-- +----------+
+ | H1| | |DNS Server|
+ +-+-+ | +----+-----+
+ | +--+-+ -------/
+ | LINK 1 | | /
+ ---+-----+------------------+ R1 +---------+
+ | | | DDNS UPDATE
+ | +----+
+ +-+-+ 6DNAC Server
+ | H2|
+ +---+
+
+
+ H1, H2 - 6DNAC Clients on Link1
+ H3, H4 - 6DNAC Clients on Link2
+ R1 - Router with 6DNAC Server, serving both Link1 and Link2
+
+
+ <Figure: 7 Example of 6DNAC Server serving multiple links>
+
+
+ 7.2. 6DNAC Operational Scenarios
+
+ This section provides message sequence charts for various 6DNAC
+ operational scenarios assuming that the 6DNAC Server is implemented
+ on a router. All the scenarios assume that the normal boot up time
+ stateless address autoconfiguration of Link Local address derived
+ from the Interface Identifier has been completed successfully. And
+ it is also assumed that the router is already configured with the
+ DNS Zone Suffix Information.
+
+
+ Legend:
+
+ 6DNAC-A, B, C : 6DNAC Clients
+ 6DNAC-S : 6DNAC Server/Router
+ DAD : Duplicate Address Detection
+ DFQDND : Duplicate Domain Name Detection
+ DNS-S : DNS Server
+
+
+ 7.2.1. Domain Name Registration-Successful Case
+
+ This scenario starts when a 6DNAC Client receives RA message with
+ DNS Zone Suffix and other parameters including address prefix as
+ specified in NDP [2461] and wants configure its IPv6 address (Global
+ or Site Local) and domain name. It is Assumed that the
+ DupAddrDetectTransmits is set to 1.
+
+
+
+
+Park & Madanapalli Expires October 2003 [Page 12]
+\f
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ +---------+ +---------+ +---------+
+ | 6DNAC-C | | 6DNAC-S | | DNS-S |
+ +----+----+ +----+----+ +----+----+
+ | | |
+ | RA with | |
+ | DNS Suffix Opt | |
+ |<---------------| |
+ | #1 | |
+ |---+ | |
+ Construct |#2 | |
+ FQDN | | |
+ |<--+ | |
+DAD/DFQDND Starts | |
+ | | |
+ | | |
+ | NS With | |
+ | FQDN Opt | |
+ |--------------->| |
+ | #3 | |
+ | | |
+ | |------+ |
+ | Create FQDN | #4 |
+ | <FQDN,C> | |
+ | |<-----+ |
+ | | |
+ | | Register FQDN |
+ | |--------------->|
+ | | #5 |
+ | #6 | |
+ |--------+ | |
+ No Response | | |
+ DFQDND-Success | | |
+ |<-------+ | |
+ | | |
+ | | |
+ v V v
+
+
+ <Figure: 8 Domain Name Generation and Registration>
+
+
+ #1. 6DNAC Server (Router) sends out router advertisement with DNS
+ Suffix information along with other parameters as specified in
+ NDP [2461].
+
+ #2. 6DNAC Client processes the router advertisement and constructs
+ the FQDN by prefixing hostname to the DNS Zone Suffix. It also
+ constructs IPv6 address from the autoconfiguration prefix
+ information option.
+
+ #3. 6DNAC Client starts duplicate address & FQDN detection for the
+ IPv6 address & FQDN constructed and sends out a Neighbor
+ Solicitation message with FQDN option.
+
+ Note that the DAD packets must be addressed to all nodes multicast
+ address if Router Alert option is not used.
+
+Park & Madanapalli Expires October 2003 [Page 13]
+\f
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ #4. 6DNAC Server processes the Neighbor Solicitation message sent by
+ 6DNAC Client as part of duplicate FQDN detection procedure and
+ creates a FQDN entry in its FQDN Cache (assuming that there is no
+ entry <FQDN,C>), where C is Link Layer Address of the 6DNAC Client.
+
+ #5. 6DNAC Server then registers FQDN and corresponding IPv6 address
+ through the existing protocol DDNS UPDATE.
+
+ #6. 6DNAC Client times out and observes that there is no response to
+ defend its duplicate FQDN detection procedure and the node is
+ successful in configuring its domain name.
+
+ Note that, Stateless Address Autoconfiguration DAD procedure is not
+ depicted in the following message sequence chart, which simultaneously
+ happens along with duplicate FQDN detection.
+
+
+ 7.2.2. Domain Name Registration-with DupAddrDetectTransmits=2
+
+ This scenario starts when a 6DNAC Client receives RA message with
+ DNS Zone Suffix and other parameters including address prefix as
+ specified in NDP [2461] and wants configure its IPv6 address (Global
+ or Site Local) and domain name. The node is configured with
+ DupAddrDetectTransmits = 2 for reliability in delivering DAD messages.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Park & Madanapalli Expires October 2003 [Page 14]
+\f
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ +---------+ +---------+ +---------+
+ | 6DNAC-C | | 6DNAC-S | | DNS-S |
+ +----+----+ +----+----+ +----+----+
+ | | |
+ | RA with | |
+ | DNS Suffix Opt | |
+ |<---------------| |
+ | #1 | |
+ |---+ | |
+ Construct |#2 | |
+ FQDN | | |
+ |<--+ | |
+DAD/DFQDND Starts | |
+ | | |
+ | | |
+ | NS With | |
+ | FQDN Opt | |
+ |--------------->| |
+ | #3 | |
+ | | |
+ | |------+ |
+ | Create FQDN | #4 |
+ | <FQDN,C> | |
+ | |<-----+ |
+ | | |
+ | | Register FQDN |
+ | |--------------->|
+ | | #5 |
+ | NS With | |
+ | FQDN Opt | |
+ |--------------->| |
+ | #6 | |
+ | | |
+ | Lookup FQDN |
+ | Entry exists |
+ | |------+ |
+ | Ignore | #7 |
+ | |<-----+ |
+ | #8 | |
+ |--------+ | |
+ No Response | | |
+ DFQDND-Success | | |
+ |<-------+ | |
+ | | |
+ | | |
+ v V v
+
+
+
+ <Figure: 9 Verification of duplicated Domain Name>
+
+
+ Steps from #1 to #5 are same as that of scenario.7.2.1.
+
+ #6. 6DNAC Client sends out second Neighbor Solicitation message with
+ FQDN option as part of duplicate FQDN detection.
+
+Park & Madanapalli Expires October 2003 [Page 15]
+\f
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ #7. 6DNAC Server receives and observes that the FQDN Cache exactly
+ matches with that of the NS information and ignores the NS message.
+
+ #8. 6DNAC Client times out and observes that there is no response to
+ defend its duplicate FQDN detection procedure and the node is
+ successful in configuring its domain name..
+
+
+ 7.2.3. Domain Name Registration-Defend Case
+
+ This scenario starts when two 6DNAC Client receive RA message with
+ DNS Zone Suffix and other parameters including address prefix as
+ specified in NDP [2461] and both the nodes want configure their IPv6
+ address (Global or Site Local) and domain name. In this scenario both
+ the nodes want to have same domain name.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Park & Madanapalli Expires October 2003 [Page 16]
+\f
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+
+
+ +---------+ +---------+ +---------+ +---------+
+ | 6DNAC-A | | 6DNAC-S | | 6DNAC-B | | DNS-S |
+ +----+----+ +----+----+ +----+----+ +----+----+
+ | | | |
+ | RA with | RA with | |
+ | DNS Suffix Opt | DNS Suffix Opt | |
+ |<---------------|--------------->| |
+ | #1 | #1 | |
+ |---+ | |---+ |
+ Construct | #2 | Construct | #2 |
+ FQDN | | FQDN | |
+ |<--+ | |<--+ |
+ DAD/DFQDND Starts | DAD/DFQDND Starts |
+ | | <DELAYED> |
+ | | | |
+ | NS with | | |
+ | FQDN Opt | | |
+ |--------------->| | |
+ | #3 | | |
+ | No Entry | |
+ | |------+ | |
+ | Create FQDN | #4 | |
+ | <FQDN,A> | | |
+ | |<-----+ | |
+ | | | |
+ | | Register FQDN #5 |
+ | |-------------------------------->|
+ | | | |
+ | | NS with | |
+ | | FQDN Opt | |
+ | |<---------------| |
+ | | #6 | |
+ | |------+ | |
+ | FQDN is in use| | |
+ | Defend DFQDND| #7 | |
+ | |<-----+ | |
+ | | | |
+ | | NA with | |
+ | | D-flag Set | |
+ | |--------------->| |
+ | | #8 | |
+ |------+ | |---+ |
+ No Response | #9 | Enter | #10 |
+ DFQDND Success| | Retry Mode| |
+ |<-----+ | |<--+ |
+ | | | |
+ v v v v
+
+
+ <Figure: 10 Multiple Hosts Requesting Same Domain Name>
+
+
+
+
+
+Park & Madanapalli Expires October 2003 [Page 17]
+\f
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ #1. 6DNAC Server (Router) sends out router advertisement with DNS
+ Suffix information.
+
+ #2. 6DNAC Clients A&B process the router advertisement and construct
+ their FQDN by prefixing hostname to the DNS Zone Suffix. They
+ also construct IPv6 address from the autoconfiguration prefix
+ information option.
+
+ When each host is trying to go for DAD, all hosts must have
+ random delay to avoid the traffic congestion according to [2461].
+ So here it is assumed that 6DNAC Client-A starts DAD first and
+ 6DNAC Client-B starts DAD later.
+
+ #3. 6DNAC Client-A starts duplicate address & FQDN detection for the
+ IPv6 address & FQDN constructed and sends out a Neighbor
+ Solicitation message with FQDN option.
+
+ #4. 6DNAC Server processes the Neighbor Solicitation message sent by
+ 6DNAC Client-A as part of duplicate FQDN detection procedure and
+ creates a FQDN entry in its FQDN Cache (assuming that there is no
+ entry <FQDN,A>), where A is Link Layer Address of the 6DNAC Client-A.
+
+ #5. 6DNAC Server then registers FQDN and corresponding IPv6 address
+ through the existing protocol DDNS UPDATE.
+
+ #6. 6DNAC Client-B starts duplicate address & FQDN detection for the
+ IPv6 address & FQDN constructed and sends out a Neighbor Solicitation
+ message with FQDN option.
+
+ #7. 6DNAC Server processes the Neighbor Solicitation message sent by
+ 6DNAC Client-B as part of duplicate FQDN detection procedure and
+ finds that the domain name is already in use by the 6DNAC Client-A.
+ Hence, concludes to defend the duplicate FQDN detection of 6DNAC
+ Client-B.
+
+ #8. 6DNAC Server sends out Neighbor Advertisement message with FQDN
+ option to 6DNAC Client-B to defend its duplicate FQDN detection.
+
+ #9. 6DNAC Client-A times out and observes that there is no response to
+ defend its duplicate FQDN detection procedure and the node is
+ successful in configuring its domain name.
+
+ #10. 6DNAC Client-B observes that there is a NA with FQDN option
+ indicating that the domain name is duplicate and enters Retry
+ Mode. In retry mode, 6DNAC Client constructs another FQDN based
+ on Host Naming Algorithm. The number of retries is defined by the
+ administrator and must be a configurable value.
+
+
+
+
+
+
+
+
+
+
+Park & Madanapalli Expires October 2003 [Page 18]
+\f
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ 7.2.4. Domain Name Registration in Retry Mode
+
+ Pre-Conditions:
+
+ 1. Duplicate Address Detection has succeeded
+ 2. Duplicate FQDN Detection FAILED
+ 3. FQDN is the first FQDN one constructed and FAILED
+ 4. FQDN2 is the second FQDN to be constructed
+ 5. The Neighbor Solicitation in the 'Retry Mode'
+ carries unspecified address in its target field (NS*).
+
+ +---------+ +---------+ +---------+
+ | 6DNAC-C | | 6DNAC-S | | DNS-S |
+ +----+----+ +----+----+ +----+----+
+ | | |
+ |--------+ | |
+ Construct | #1 | |
+ new FQDN2 | | |
+ |<-------+ | |
+ | | |
+ DFQDND Restarts | |
+ | | |
+ | | |
+ | NS* With | |
+ | FQDN Opt | |
+ |--------------->| |
+ | #2 | |
+ | | |
+ | No Entry |
+ | |------+ |
+ | Create FQDN | #3 |
+ | <FQDN2,C> | |
+ | |<-----+ |
+ | | |
+ | | Register FQDN2 |
+ | |--------------->|
+ | | #4 |
+ | | |
+ |--------+ | |
+ No Response | #5 | |
+ DFQDND-Success | | |
+ |<-------+ | |
+ | | |
+ v V v
+
+
+ <Figure: 11 Regeneration of Domain Name>
+
+
+
+
+
+
+
+
+
+
+Park & Madanapalli Expires October 2003 [Page 19]
+\f
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ #1. 6DNAC Client constructs the FQDN again as per Host Naming Algorithm,
+ the DNS Zone Suffix, and it is FQDN2.
+ #2. It then starts Duplicate Detection only for Domain Name. 6DNAC
+ Client sends out NS with FQDN option and unspecified target
+ address.
+
+ #3. 6DNAC Server processes the Retry Mode NS message and finds that
+ the FQDN2 is not in use and creates Cache entry as <FQDN2, C>.
+
+ #4. It then starts registration procedures with the DNS Server.
+
+ #5. Meanwhile, 6DNAC Client timesout and observes that there is no
+ defending NA for its DFQDND NS sent out and successfully
+ configures its domain name.
+
+
+ 7.2.5. Domain Name Registration when DAD Fails
+
+ Duplicate domain name detection and subsequent registration starts
+ if and only if the DAD for IPv6 address succeeds. If the DAD for
+ IPv6 address fails then no actions are taken for domain name. When
+ DAD fails for stateless address autoconfiguration, then the domain
+ configuration starts only when the address has been configured using
+ Stateful Address Configuration methods and the node is going on DAD
+ for this address.
+
+ This scenario starts when a 6DNAC Client receives RA message with
+ DNS Zone Suffix and other parameters including address prefix as
+ specified in NDP [2461] and wants configure its IPv6 address (Global
+ or Site Local) and domain name.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Park & Madanapalli Expires October 2003 [Page 20]
+\f
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ +---------+ +---------+ +---------+ +---------+
+ | 6DNAC-A | | 6DNAC-S | | 6DNAC-B | | DNS-S |
+ +----+----+ +----+----+ +----+----+ +----+----+
+ | | | |
+ | | | |
+ | RA with | | |
+ | DNS Suffix Opt | | |
+ |<---------------| | |
+ | #1 | | |
+ |-----+ | | |
+ Construct | | | |
+ FQDN& | #2 | | |
+ IPv6 Addr | | | |
+ |<----+ | | |
+ DAD/DFQDND Starts | | |
+ | | | |
+ | | | |
+ | NS with | | |
+ | FQDN Opt | | |
+ |--------------->+--------------->| |
+ | #3 | #3 | |
+ | No Entry | |
+ | |------+ | |
+ | Create FQDN | | |
+ | <FQDN,A> | #4 | |
+ | |<-----+ | |
+ | | | |
+ | | |------+ |
+ | | My IPv6 Addr| #5 |
+ | | |<-----+ |
+ | | Defend DAD | |
+ | | with NA | |
+ |<---------------+<---------------| |
+ | #6 | #6 | |
+ | Entry | |
+ | |------+ | |
+ | Delete FQDN | #7 | |
+ | |<-----+ | |
+ | | | |
+ |----+ | | |
+ DAD Failed | #8 | | |
+ Stop DFQDND | | | |
+ |<---+ | | |
+ | | | |
+ v v v v
+
+ <Figure: 12 DAD failure>
+
+ #1. 6DNAC Server sends out Router Advertisement to 6DNAC Client-A.
+
+ #2. 6DNAC Client-A constructs IPv6 Address based on the prefix and
+ FQDN as per Host Naming Algorithm.
+
+ #3. It then starts Duplicate address & FQDN Detection, for the newly
+ constructed IPv6 address and FQDN, and sends out DAD/DFQDND NS
+ with FQDN option.
+
+Park & Madanapalli Expires October 2003 [Page 21]
+\f
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ #4. 6DNAC Server processes the DAD/DFQDND NS message and finds
+ that there is no entry for the FQDN in its cache. And,
+ creates Cache entry as <FQDN, A> and starts a Registration
+ timer with RegistrationWaitTime seconds.
+
+ #5. 6DNAC Client-B finds that the DAD/DFQDND-NS target address is
+ in its unicast address list.
+
+ #6. It then starts defending DAD by sending NA to all-nodes multicast.
+
+ #7. 6DNAC Server finds that the DAD has failed for 6DNAC Client-A.
+ And, deletes its FQDN Cache entry <FQDN,A>.
+
+ #8. 6DNAC Client gets defending DAD-NA and desists from DAD.
+ And also, stops Duplicate FQDN Detection as well.
+ At this point the address must be configured using stateful
+ methods and the domain name registration starts with the DAD
+ for the newly constructed IPv6 address.
+
+ 7.3. DNS Zone Suffix Discovery and FQDN Construction
+
+ 7.3.1. Sending Router Advertisement Messages
+
+ Routers send out Router Advertisement message periodically,
+ or in response to a Router Solicitation. Router should include
+ the DNS Zone Suffix Option in their advertisements. If the DNS
+ Zone Suffix changes (similar to Site Renumbering), then it should
+ advertise the Old Zone Suffix with zero Valid Lifetime and New
+ Zone Suffix with proper non-zero Valid Lifetime. In any other
+ case, a router should not send this option twice in a single
+ router advertisement.
+
+ 7.3.2. Processing Router Advertisement Messages
+
+ For each DNS Zone Suffix Option in Router Advertisement,
+
+ a. 6DNAC node stores the Zone Suffix information in its local
+ database. Also, constructs FQDN as per Host Naming Algorithm.
+
+ b. If the node has not configured FQDN yet,
+
+ 1. If the node is going to perform DAD for either Site local or
+ Global Address, then it should include FQDN option to perform
+ Duplicate FQDN Detection in parallel with DAD.
+
+ 2. If the node has already got either Site local or Global
+ address, then it should send out NS with FQDN option and
+ unspecified target address to perform Duplicate FQDN
+ Detection.
+
+ c. If the node has already configured FQDN, and if the
+ advertisement carries two DNS Zone Suffix Options,
+ First DNS Zone Suffix should match with the configured FQDN
+ Suffix and its Valid Lifetime must be zero. Second DNS Zone
+
+
+
+Park & Madanapalli Expires October 2003 [Page 22]
+\f
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+
+ Suffix should have non-zero Valid Lifetime. In this case, the
+ node constructs new FQDN based on the new DNS Zone Suffix (from
+ second DNS Zone Suffix option), and perform Duplicate FQDN
+ Detection with unspecified target address. Also, it should
+ overwrite the old FQDN with the newly constructed FQDN.
+
+
+ 7.3.3. FQDN Lifetime expiry
+
+ 6DNAC Server:
+ It should delete the FQDN cache entry and should de-register from
+ the DNS Server.
+
+ 6DNAC Client:
+ It should send update to 6DNAC Server by restarting the Duplicate
+ FQDN Detection.
+
+ 7.3.4. Host Naming Algorithm
+
+ A node constructs FQDN by combining DNS Zone Suffix and the hostname
+ as depicted in the following diagram.
+
+ +------------------+----------------------------------+
+ | Host Name | Advertised Suffix |
+ +------------------+----------------------------------+
+
+ <Figure 13: Fully Qualified Domain Name format>
+
+ A node can choose Host Name using any of the following methods:
+
+ a. String form of random number generated from the Interface
+ Identifier.
+
+ b. List of configured Host Names provided by the administrator.
+
+
+ The number of retries must be specified in this algorithm in
+ case of domain name duplication.
+
+
+ 7.4. Duplicate Domain Name Detection
+
+ The procedure for detecting duplicated FQDNs uses Neighbor
+ Solicitation and Advertisement messages as described below.
+
+ If a duplicate FQDN is detected during the procedure, the
+ FQDN cannot be assigned to the node.
+
+ An FQDN on which the DFQDND Procedure is applied is said
+ to be tentative until the procedure has completed successfully.
+ A tentative FQDN is not considered "assigned to the node" in the
+ traditional sense. That is, the node must accept Neighbor
+ Advertisement message containing the tentative FQDN in the FQDN
+ Option.
+
+
+Park & Madanapalli Expires October 2003 [Page 23]
+\f
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+
+ It should also be noted that DFQDN must be performed prior to
+ registering with DNS Server to prevent multiple nodes from using
+ the same FQDN simultaneously. All the Duplicate Address Detection
+ Neighbor Solicitation messages must carry Source Link Layer Address
+ Option as specified in NDP [2461].
+
+ The detection of duplicate FQDN can be achieved through one of the
+ following three types of procedures.
+
+ 1. DAD with All Nodes Multicast Address
+ 2. DAD with Router Alert Option for 6DNAC.
+ 3. Explicit Detection of Duplicate Domain Name
+
+ Even though three solutions are listed, authors prefer only one
+ procedure to be followed in future based on further analysis and
+ comments received from others.
+
+ 7.4.1. DAD with All Nodes Multicast Address
+
+ 7.4.1.1. Sending Neighbor Solicitation Messages
+
+ 6DNAC Client sends Neighbor Solicitation Messages as part
+ of Duplicate Address Detection SLAAC [2462] with the following
+ extra information and modifications:
+
+ a. Include FQDN Option in the DAD Neighbor Solicitation Message
+ b. Destination Address is set to All Nodes Multicast Address
+
+ There may be a case where DAD has succeeded but DFQDND is in Retry
+ Mode. In such case, the Neighbor Solicitation must carry unspecified
+ address in the ICMP target address field and new domain name in FQDN
+ option to re-try the registration of the domain name.
+
+ 7.4.1.2. Processing Neighbor Solicitation Messages
+
+ 6DNAC Clients must ignore the FQDN option found in any of the
+ neighbor solicitation messages.
+
+ 6DNAC Server processes FQDN Option found in the Duplicate Address
+ Detection Neighbor Solicitation Messages as described below:
+
+ Lookup FQDN Cache for the domain name in FQDN Option.
+
+ If the entry exists and
+ i. Link Layer Address matches with SLLA option, this is the case,
+ where node has changed its IPv6 address or updating the valid
+ life time. 6DNAC Server updates its cache and also updates DNS
+ Server using DDNS-UPDATE. If there is no change in IPv6 address
+ or life time then no updates are sent to the DNS server.
+
+ ii. Link Layer Address differs with SLLA option, defend the duplicate
+ FQDN Detection by sending Neighbor Advertisement Message as
+ described in $7.4.1.3$.
+
+
+
+Park & Madanapalli Expires October 2003 [Page 24]
+\f
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+
+ else,
+ Lookup FQDN Cache for the Link Layer Address in SLLA Option.
+
+ If the entry exists, update the FQDN Cache and update DNS Server
+ using DDNS-UPDATE. This is the case, where node has changed its
+ domain name (similar to Site Re-numbering).
+
+ If then entry does not exists, then it means that this is the new
+ registration. It must create a cache entry and start Registration
+
+ timer with RegistrationWaitTime. At the expiry of the Registration
+ timer, it should update DNS Server with DDNS-UPDATE.
+
+ 7.4.1.3. Sending Neighbor Advertisement Messages
+
+ 6DNAC Server sends Neighbor Advertisement Messages as part
+ of Duplicate Address Detection SLAAC [2462] with the FQDN Option
+ in Neighbor Advertisement message to defend duplicate FQDN
+ detection.
+
+ There may be the case where defending of duplicate address detection
+ is not required but defending of FQDN is required. In such instance,
+ the defending Neighbor Advertisement must carry FQDN and unspecified
+ address in the ICMP target address field.
+
+ 7.4.1.4. Processing Neighbor Advertisement Messages
+
+ 6DNAC Server must ignore the any FQDN option found any of
+ the neighbor advertisement messages. If the Neighbor Advertisement
+ is a DAD defending, then it must delete its FQDN Cache entry created
+ on the reception of DAD Neighbor Solicitation message.
+
+ When 6DNAC Clients gets the duplicate address detection neighbor
+ advertisement messages with FQDN option set it means that its
+ duplicate FQDN detection failed and enters Retry Mode.
+
+ 7.4.1.5. Pros and Cons
+
+ The advantage of this procedure is that it does not need any
+ extension header options to be included. The disadvantage of this
+ procedure is that, it needs change in the existing DAD procedure.
+ The change is only that the DAD neighbor solicitations are to be
+ addressed to all nodes multicast address instead of solicited
+ node multicast address. The another disadvantage is that, it needs
+ the existence of Duplicate Address Detection Procedure to
+ perform duplicate FQDN detection.
+
+ 7.4.2. DAD with Router Alert Option for 6DNAC
+
+ 7.4.2.1. Sending Neighbor Solicitation Messages
+
+ 6DNAC Client sends Neighbor Solicitation Messages as part
+ of Duplicate Address Detection SLAAC [2462] with the following
+ extra information:
+
+
+Park & Madanapalli Expires October 2003 [Page 25]
+\f
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+
+ a. Include Hop-by-Hop extension Header with Router Alert Option
+ for 6DNAC as described in IPv6 Router Alert Option[2711].
+
+ b. Include FQDN Option in the DAD Neighbor Solicitation Message
+
+ 7.4.2.2. Processing Neighbor Solicitation Messages
+
+ This is same as described in $7.4.1.2$.
+
+ 7.4.2.3. Sending Neighbor Advertisement Messages
+
+ This is same as described in $7.4.1.3$.
+
+ 7.4.2.4. Processing Neighbor Advertisement Messages
+
+ This is same as described in $7.4.1.4$.
+
+ 7.4.2.5. Pros and Cons
+
+ The advantage of this procedure is that it does not disturb
+ the existing implementation and their way of processing the
+ packets. The disadvantage is that, it needs the existence
+ of Duplicate Address Detection Procedure to perform duplicate
+ FQDN detection. Another disadvantage is that this procedure
+ requires 6DNAC Server functionality to be implemented on Router.
+ However, in this case 6DNAC Server can serve multiple links.
+
+ 7.4.3. Explicit Detection of Duplicate Domain Name
+
+ In this procedure Duplicate FQDN Detection starts after completion
+ of successful Site local or Global Address configuration.
+
+ 7.4.3.1. Sending Neighbor Solicitation Messages
+
+ 6DNAC Client sends Neighbor Solicitation Messages as part
+ of Duplicate FQDN Detection with the following information:
+
+ a. Include FQDN Option in the Neighbor Solicitation Message
+
+ b. Destination Address is set to All Nodes Multicast Address
+ or uses Router Alert Option for 6DNAC, when 6DNAC Server is
+ implemented on router.
+
+ c. Target Address is set to Unspecified Address
+
+ d. Other fields are set as per DAD SLAAC [2462].
+
+ 7.4.3.2. Processing Neighbor Solicitation Messages
+
+ This is same as described in $7.4.1.2$.
+
+
+
+
+
+
+Park & Madanapalli Expires October 2003 [Page 26]
+\f
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+
+ 7.4.3.3. Sending Neighbor Advertisement Messages
+
+ This is same as described in $7.4.1.3$.
+
+ 7.4.3.4. Processing Neighbor Advertisement Messages
+
+ This is same as described in $7.4.1.4$.
+
+ 7.4.3.5. Pros and Cons
+
+ The advantage of this procedure is that it does not need the
+ existing duplicate address detection procedure. This is introduced
+ as the DAD procedure is found to be redundant in when IPv6 addresses
+ are constructed from the interface ID [DIID].
+
+ Note that, if 6DNAC Clients know the address of 6DNAC Server then
+ they can directly send DFQDND-NS to 6DNAC Server.
+
+ 7.4.4. Retry Mode for Re-registering Domain Name
+
+ In retry mode, nodes construct new FQDN as per Host Naming Algorithm.
+ Then they restart Duplicate FQDN Detection as described in $7.4.3$.
+
+
+ 7.5. Domain Name Registration
+
+ 6DNAC Server must be an authenticated to update the DNS Server.
+ 6DNAC Server must also be configured with the DNS Server
+ information.
+
+ 6DNAC Server detects the DNS information (IPv6 Address and
+ corresponding FQDN) from DAD/DFQDND messages and caches the
+ information. It also have an associated Registration Timer with
+ RegistrationWaitTime to wait for the successful completion of
+ DFQDND and update DNS Server using existing protocol DDNS UPDATE
+ [2136].
+
+
+ 8. Security Consideration
+
+ If someone wants to hijack correct Domain Name registration, they
+ could send a NS message with incorrect or same Domain Name to the
+ 6DNAC server repeatedly and server would start the Domain Name
+ registration through above mechanism, which is a security hole.
+ As described in [2461], a host can check validity of NDP messages.
+ If the NDP message include an IP Authentication Header, the message
+ authenticates correctly. For DNS UPDATE processing, secure DNS
+ Dynamic Update is described in [3007].
+
+
+
+
+
+
+
+
+Park & Madanapalli Expires October 2003 [Page 27]
+\f
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+
+ 9. IANA Consideration
+
+ Values in the Router Alert Option are registered and maintained by
+ IANA. For 6DNAC, the value has to be assigned by IANA. Also IANA is
+ required to assign the Type values for DNS Zone Suffix Information
+ option and FADN option.
+
+
+ 10. Acknowledgement
+
+ Special thanks are due to Badrinarayana N.S. and Christian Huitema for
+ many helpful suggestions and revisions.
+
+
+ 11. Intellectual Property
+
+ The following notice is copied from RFC 2026 [Bradner, 1996],
+ Section 10.4, and describes the position of the IETF concerning
+ intellectual property claims made against this document.
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use other technology described in
+
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication and any assurances
+ of licenses to be made available, or the result of an attempt made
+ to obtain a general license or permission for the use of such
+ proprietary rights by implementers or users of this specification
+ can be obtained from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+
+ 12. Copyright
+
+ The following copyright notice is copied from RFC 2026 [Bradner,
+ 1996], Section 10.4, and describes the applicable copyright for this
+ document.
+
+ Copyright (C) The Internet Society July 12, 2001. All Rights
+ Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+
+Park & Madanapalli Expires October 2003 [Page 28]
+\f
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph
+ are included on all such copies and derivative works. However, this
+
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assignees.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+ 13. References
+
+ [2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 2373, July 1998.
+
+ [2460] Deering, S. abd R. Hinden, "Internet Protocol,
+ Version 6 (IPv6) Specification", RFC 2460,
+ December 1998.
+
+ [2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
+ Discovery for IP version 6(IPv6)", RFC 2461, December
+ 1998.
+
+ [2462] S. Thomson and Narten T, "IPv6 Stateless Address Auto-
+ Configuration", RFC 2462, December 1998.
+
+ [2711] C. Patridge and A.Jackson, "IPv6 Router Alert Option",
+ RFC 2711, October 1999.
+
+ [1034] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND
+ FACILITIES", RFC 1034, November 1987.
+
+ [1035] P. Mockapetris, "Domain Names - Implementation and
+ Specification" RFC 1035, November 1987.
+
+ [2136] P. Vixie et al., "Dynamic Updates in the Domain Name
+ System (DNS UPDATE)", RFC2136, April 1997.
+
+ [3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic
+ Update", RFC 3007, November 2000.
+
+
+
+Park & Madanapalli Expires October 2003 [Page 29]
+\f
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+
+ [DIID] yokohama-dad-vs-diid.pdf
+ at http://playground.sun.com/ipng/presentations/July2002/
+
+ [DNSISSUES] Durand, A., "IPv6 DNS transition issues", draft-ietf-
+ dnsop-ipv6-dns-issues-00.txt, work in progress.
+
+ [PREFIX] S. Miyakawa, R. Droms, "Requirements for IPv6 prefix
+ delegation", draft-ietf-ipv6-prefix-delegation-
+ requirement-01.txt, work in progress.
+
+ [Autoreg] H. Kitamura, "Domain Name Auto-Registration for
+ Plugged-in IPv6 Nodes", draft-ietf-dnsext-ipv6-name-
+ auto-reg-00.txt, work in progress.
+
+ [NIQ] Matt Crawford, "IPv6 Node Information Queries", <draft-
+ ietf-ipngwg-icmp-name-lookups-09.txt>, work in progress.
+
+
+ 14. Author's Addresses
+
+ Soohong Daniel Park
+ Mobile Platform Laboratory, SAMSUNG Electronics, KOREA
+ Phone: +82-31-200-3728
+ Email:soohong.park@samsung.com
+
+ Syam Madanapalli
+ Network Systems Division, SAMSUNG India Software Operations, INDIA
+ Phone: +91-80-5550555
+ Email:syam@samsung.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Park & Madanapalli Expires October 2003 [Page 30]
projects / thirdparty / bind9.git / commitdiff
