diff options
Diffstat (limited to 'doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt')
| -rw-r--r-- | doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt | 1830 |
1 files changed, 1830 insertions, 0 deletions
diff --git a/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt b/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt new file mode 100644 index 0000000..f9eaf26 --- /dev/null +++ b/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt @@ -0,0 +1,1830 @@ + + + + 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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] |