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