idnits 2.17.1 draft-ietf-dnsext-ipv6-name-auto-reg-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([ADDR-AUTO], [DYN-DNS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (23 July 2003) is 7583 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'IPv6' is defined on line 870, but no explicit reference was found in the text == Unused Reference: 'ND' is defined on line 873, but no explicit reference was found in the text == Unused Reference: 'DNS-SIG0' is defined on line 889, but no explicit reference was found in the text == Unused Reference: 'DYN-DNSSEC' is defined on line 892, but no explicit reference was found in the text == Unused Reference: 'DNSSEC' is defined on line 895, but no explicit reference was found in the text == Unused Reference: 'HTTP' is defined on line 905, but no explicit reference was found in the text == Unused Reference: 'TLS-HTTP' is defined on line 908, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. 'IPv6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (ref. 'ND') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. 'ADDR-AUTO') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2845 (ref. 'TSIG') (Obsoleted by RFC 8945) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 3008 (ref. 'DNSSEC') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 1905 (ref. 'SNMP') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3484 (ref. 'DEF-ADDR') (Obsoleted by RFC 6724) -- Possible downref: Non-RFC (?) normative reference: ref. 'NIQ' -- Possible downref: Non-RFC (?) normative reference: ref. 'DNS-DISC' Summary: 18 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT H. Kitamura 3 NEC Corporation 4 Expires in six months 23 July 2003 6 Domain Name Auto-Registration for Plugged-in IPv6 Nodes 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Abstract 29 This document describes a scheme of "Domain Name Auto-Registration 30 for Plugged-in IPv6 Nodes" mechanism that makes it possible to 31 register both regular and inverse domain name information of plugged- 32 in IPv6 nodes to DNS servers automatically. 34 Since IPv6 addresses are too long to remember and EUI64-based 35 addresses are too complicated to remember, there are strong 36 requirements to use logical names that are easy to remember instead 37 of IPv6 addresses to specify IPv6 nodes and to register domain name 38 information of plugged-in IPv6 nodes automatically. 40 In order to meet the requirements, a mechanism is proposed as one of 41 the IPv6 auto-configuration (plug and play) functions. After the 42 Address Autoconfiguration [ADDR-AUTO] has been executed, it works as 43 a succeeding plug and play mechanism. 45 This document clarifies problems that we meet when we apply the 46 Dynamic Updates in the DNS [DYN-DNS] to automatic domain name 47 information registration mechanisms. This document describes the 48 Domain Name Auto-Registration mechanism as a solution to these 49 problems. 51 The Domain Name Auto-Registration mechanism, in addition to its main 52 functionality, provides two types of additional benefits. 54 One is that IP address information that should be registered to the 55 DNS is collected automatically. The mechanism can also be used under 56 (non plug and play) manual configuration situations in a different 57 manner from its main functionality. Under such situations, network 58 administrators meet a problem that it is not easy to collect IP 59 address information to register to the DNS. The mechanism solves it. 61 The other is that a plugged-in IPv6 node can obtain its domain name 62 information (FQDN and DNS zone suffix) without having new functions 63 installed into it. By simply executing inverse DNS name resolving 64 procedures with its IPv6 address argument, the plugged-in IPv6 node 65 can obtain its FQDN and DNS zone suffix with ease. 67 1. Introduction 69 This document describes a scheme of "Domain Name Auto-Registration 70 for Plugged-in IPv6 Nodes" mechanism that makes it possible to 71 register both regular and inverse domain name information of plugged- 72 in IPv6 nodes to DNS servers automatically. 74 In order to specify destination nodes to communicate, SOME 75 identifiers are necessary for users. Since IPv6 addresses are too 76 long to remember and EUI64-based addresses are too complicated to 77 remember, they are not suitable for such identifiers. Logical names 78 are suitable identifiers because they are easy to remember. 79 Therefore, there are strong requirements to use logical names instead 80 of IPv6 addresses to specify IPv6 destination nodes and to register 81 domain name information of plugged-in IPv6 nodes automatically. 83 In order to meet the requirements, a mechanism is proposed as one of 84 the IPv6 auto-configuration (plug and play) functions. After the 85 Address Autoconfiguration [ADDR-AUTO] has been executed, it works as 86 a succeeding plug and play mechanism. 88 It is known that the Dynamic Updates in the DNS [DYN-DNS] have 89 already been defined and that they can help automatic domain name 90 information registration mechanisms. However, some problems need to 91 be solved to apply this idea to actual situations. 93 This document clarifies problems that we meet when we apply the 94 Dynamic Updates in the DNS [DYN-DNS] to automatic domain name 95 information registration mechanisms. This document describes the 96 Domain Name Auto-Registration mechanism as a solution to these 97 problems. 99 Basic target situations for the mechanism are plug and play 100 situations. Accordingly, it has been designed for plugged-in IPv6 101 nodes under plug and play situations. 103 We have to consider the following issues to design the "Domain Name 104 Auto-Registration for Plugged-in IPv6 Nodes" mechanism. 106 1. Plugged-in IPv6 nodes do not have sufficient capability to show 107 their preferences. In most cases, it is difficult for plugged-in 108 IPv6 nodes to show their preferences for their domain names. 110 2. Since it is not easy to install new function to all IPv6 nodes, it 111 is desirable to achieve the mechanism without installing new 112 functions into plugged-in IPv6 nodes. 114 3. It is essential to have (register) SOME domain name for a 115 plugged-in node. It is NOT main concern for a plugged-in node 116 which actual name is assigned to it. 118 Thus, the idea of "default domain name" is introduced. When a new 119 plugged-in IPv6 node appears, its appearance is automatically 120 detected and a default domain name is selected for it, and both 121 regular and inverse information of the default domain name are 122 registered to appropriate DNS servers. 124 This document does not deal with cases where IPv6 nodes want to 125 register domain names that they absolutely prefer. Such cases do not 126 fall within the target range of plug and play situations; they will 127 be supported under manual configuration situations. 129 There are various types of plugged-in IPv6 nodes that can/cannot show 130 their preferences for their domain names. In order to meet various 131 plug and play situations, this document considers several cases. 133 The Domain Name Auto-Registration mechanism is basically designed for 134 domain name registrations for global unicast addresses. By setting 135 the query scope of the target DNS server appropriately, the mechanism 136 will be able to be applied to domain name registrations for site- 137 local and link-local scope unicast addresses. 139 The Domain Name Auto-Registration mechanism, in addition to its main 140 functionality, provides two types of additional benefits. 142 One is that IP address information that should be registered to the 143 DNS is collected automatically. The mechanism can also be used under 144 (non plug and play) manual configuration situations in a different 145 manner from its main functionality. Under such situations where 146 network is maintained by administrators manually, administrators meet 147 a problem that it is not easy to collect IP address information to 148 register to the DNS. The mechanism solves the problem, and IP address 149 information to register to the DNS is collected automatically. 151 Under manual configuration situations, the automatic DNS registration 152 procedure that is the last procedure of the mechanism can be replaced 153 by the administrators' manual registration (not by the Dynamic 154 Updates). 156 The other is that a plugged-in IPv6 node can obtain its domain name 157 information (FQDN and DNS zone suffix) with ease. The plugged-in IPv6 158 nodes know its IPv6 address that are automatically configured by the 159 Address Autoconfiguration [ADDR-AUTO]. By simply executing inverse 160 DNS name resolving procedures with the IPv6 address argument, the 161 plugged-in IPv6 node can obtain information on its domain names (FQDN 162 and DNS zone suffix) easily. Since all IPv6 nodes have DNS name 163 resolving functions for both regular and inverse queries, this 164 procedure can be achieved without installing new functions into IPv6 165 nodes. 167 2. Problems in applying the Dynamic Updates mechanism 169 This section clarifies problems that we meet when we apply the 170 Dynamic Updates in the DNS [DYN-DNS] to automatic domain name 171 information registration mechanisms. 173 1: Ordinary DNS servers accept Dynamic Updates messages only from 174 trusted nodes. 176 Since it is difficult for plugged-in IPv6 nodes to become trusted 177 nodes of the DNS servers, Dynamic Updates messages from plugged-in 178 IPv6 nodes are usually not accepted by the DNS servers. 180 2: It is difficult for plugged-in IPv6 nodes to know the location of 181 the appropriate DNS server to register their domain name 182 information to. 183 ([DNS-DISC] discusses on issues of this type.) 185 3: It is difficult for plugged-in IPv6 nodes to prepare sufficient 186 domain name information to register. They need to know their DNS 187 zone suffix information to prepare FQDN for registration, but it 188 is difficult for them to acquire it. 189 ([DNS-DISC] also discusses on issues of this type.) 191 4: There is no explicit method to avoid duplicated, conflicting name 192 registrations. 194 When a DNS server receives Dynamic Updates messages that are 195 correctly formatted and authenticated, the server accepts them and 196 updates DNS database with them without checking for duplication. 197 (It is essentially difficult for a DNS server to distinguish 198 overwrite (update) registrations from duplicate registrations.) 200 5: Basically, there is no mechanism to control (restrict) the number 201 of issued Dynamic Updates messages for plugged-in nodes. 203 In order to minimize the effects of malicious or misconfigured 204 registration requests, it is necessary to control them. 206 6: It is not clear when domain name registration requests must be 207 issued. It is necessary to define trigger timings to start 208 registrations. 210 3. Basic Design of the Domain Name Auto-Registration 212 This section describes the basic design of the Domain Name Auto- 213 Registration mechanism. The mechanism solves all of the above- 214 mentioned problems. 216 3.1 Design Policies 218 The Domain Name Auto-Registration mechanism is composed of two new 219 functions. One is the "Detector" function, which detects appearances 220 of new plugged-in IPv6 nodes. The other is the "Registrar" function, 221 which registers detected domain name information to DNS servers. 222 These functions are introduced into the IPv6 network system to 223 achieve the mechanism. 225 There are several reasons why the mechanism is implemented as two 226 functions. 228 1. To make the mechanism easy to control 230 By concentrating administrative operations only on the Registrar 231 side, administrative costs are reduced and the mechanism is 232 basically maintained by administering only Registrars. 234 The number of DNS servers' trusted nodes that require much 235 administrative operation is reduced. 237 Since registration information is aggregated at Registrars, it 238 becomes easy to control registrations and minimize the effects of 239 malicious or misconfigured registration requests. 241 2. To make Detector easy to implement 243 There are certain constraints in placing Detectors on the IPv6 244 network. Thus, it is necessary for Detectors to be simple enough 245 to be installed on IPv6 nodes of any type. 247 This need is filled by putting all the intelligent operations into 248 Registrars. 250 Furthermore, the system becomes well balanced since intelligent 251 operations are not placed on each end link. 253 3. To make the mechanism flexible and enable it to be applied 254 to various environments (office networks, home networks, etc.) 256 If the mechanism is applied to home networks, Registrars can be 257 placed at the Provider side, and Detectors can be placed at the 258 User side. 260 Figure 1 and 2 show typical examples that indicate locations where 261 Detector and Registrar functions are placed on the IPv6 network. 263 Figure 1 shows a case for a single link, and Figure 2 shows a case 264 for multiple links. 266 | +------------+ 267 | | DNS Server | 268 +-+-+ %%%%%%%%%%%% ############# +------+-----+ 269 | R | % Detector % # Registrar # / 270 +-+-+ %%%%%%%%%%%% ############# +---+ 271 | | | / 272 ----+---------+-------+------+---------------+----- 273 | 274 +===========+ 275 | Plugged-in| 276 | IPv6 Node | 277 +===========+ 279 Fig. 1 Single-Link Case Example 280 +------------+ 281 | DNS Server | 282 ############# +------+-----+ 283 # Registrar # / 284 ############# +---+ 285 | / 286 ----+-----------+------------+-------+------ 287 | | 288 +-+-+ %%%%%%%%%%%%% +-+-+ %%%%%%%%%%%%% 289 | R1| % Detector1 % | R2| % Detector2 % 290 +-+-+ %%%%%%%%%%%%% +-+-+ %%%%%%%%%%%%% 291 | | | | 292 ----+-----+-----+----- ----+-----+-----+----- 293 | | 294 +===========+ +===========+ 295 | Plugged-in| | Plugged-in| 296 | IPv6 Node | | IPv6 Node | 297 +===========+ +===========+ 299 Fig. 2 Multiple-Link Case Example 301 One Registrar can take charge of multiple Detectors, and one 302 Registrar can cover multiple DNS zones. 304 Multiple Detectors can provide detected information for one DNS zone. 305 If the corresponding Registrars of these Detectors are different, 306 multiple Registrars can cover one DNS zone. 308 Therefore, Registrars must be designed to support both cases. 310 3.2 Detector Function 312 The role of a "Detector" is to detect appearances of new plugged-in 313 IPv6 nodes and to send the detected information to a "Registrar" 314 without applying any selection rules to it. 316 Detectors are NOT required to perform any "intelligent" operations. 318 A Detector knows the location of its corresponding Registrar. (This 319 location is configured manually.) Detected information must be sent 320 securely from the Detector to the Registrar by using some kind of 321 secure communication method (e.g., [TSIG]-like authentication, IPsec 322 (AH, ESP), [TLS]). 324 Since a Detector must be placed where appearances of new plugged-in 325 IPv6 nodes can be detected, the Detector location is restricted. 327 In typical cases, appearances are detected by watching for DAD 328 packets that are issued from plugged-in IPv6 nodes (see section 3.4). 329 So, the Detector must be placed where it can listen to link-local 330 scope multicast packets. In other words, a Detector must be placed on 331 each link to achieve the mechanism. 333 The Detector function can be implemented on routers, because its 334 operations are simple and lightweight and routers are located at 335 suitable places for listening to link-local scope multicast packets 336 that are issued from plugged-in IPv6 nodes. 338 In order to identify Detectors, each Detector must have its own 339 Detector ID. Since a Detector is placed on each link, the Detector's 340 IP address that is connected to its watching link can be used for the 341 Detector ID. (Default Address Selection for IPv6 [DEF-ADDR] algorithm 342 is also applied here.) When a Detector sends detected information to 343 a Registrar, the Detector ID is attached to it. 345 In order to meet "temporary address" [RFC3041] issues (see section 346 5), a link-layer address of a detected IP address is also attached to 347 detected information. 349 Some simple protocol is necessary to send detected information from 350 the Detector to the Registrar. In Appendix A, [HTTP]-based or [TLS- 351 HTTP]-based simple protocol is shown. 353 3.3 Registrar Function 355 The role of a "Registrar" is to prepare appropriate domain name 356 information for registration and to register it by sending Dynamic 357 Update messages to the corresponding "DNS servers". 359 Appropriate domain name information for registration is created from 360 detected information that is sent from the Detector. Some sort of 361 intelligent algorithm is necessary in such procedures. One of the 362 roles of the algorithm is to minimize the effects of malicious or 363 misconfigured registration requests. 365 Registrars are required to perform "intelligent" operations. 367 By using some sort of algorithm, the Registrar verifies (checks) 368 whether detected information must be registered (see section 3.5). 369 After the verification procedures are completed, the Registrar 370 selects a "default domain name" for the detected information. 372 In order to prepare appropriate domain name information, the 373 Registrar must know the appropriate DNS zone suffix for detected 374 information. (The suffix is configured manually.) The DNS zone suffix 375 depends on the Detector ID information. 377 A Registrar must know the locations of "DNS servers" that correspond 378 to detected information for registration (both regular DNS zone 379 prefix and its inverse zone). Registrars must be trusted nodes of the 380 DNS servers and Dynamic Update messages must be sent securely from 381 the Registrar to the DNS servers by using some sort of secure 382 communication methods. The [TSIG] technique would be suitable for 383 authenticating the messages. 385 A Registrar has a database table to manage such knowledge. The 386 following elements are managed in the database table: 387 Detector IDs, DNS zone suffixes, locations of DNS servers, applied 388 algorithms (naming rules, how to deal with link-local or site-local 389 scope addresses, etc.) and keys for secure communications. 391 A Registrar can be placed anywhere in the IPv6 network, because the 392 Registrar communicates only with Detectors and DNS servers, all 393 communications are unicast. 395 In order to optimize the communication path for packets between them, 396 the Registrar is usually placed in the network upstream from the 397 Detectors (see Fig.2). 399 Detected information that is sent from Detectors is aggregated at the 400 Registrar. 402 The Registrar may frequently execute inverse DNS name resolving 403 procedures to verify (check) whether detected information must be 404 registered. It is recommended to put a DNS cache server function on 405 the same node where the Registrar is placed to reduce inverse DNS 406 name resolving traffic (see section 3.5). 408 3.4 Methods of Detecting Appearances of New Plugged-in IPv6 Nodes 410 In order to detect appearances of new plugged-in IPv6 nodes, the 411 Detector must watch or receive packets from new plugged-in nodes. 412 Accordingly, detection methods on the Detector are categorized into 413 two types. 415 One is detection of the appearance of "standard" plugged-in nodes 416 that do not issue special packets to show their appearance. The other 417 is detection of the appearance of "active" plugged-in nodes that 418 issue special packets to show their appearance. 420 We can assume there will be complex cases in which standard and 421 active plugged-in nodes are mixed together. For purposes of 422 simplification, such cases are not discussed here. 424 3.4.1 Detecting Appearance of "Standard" Plugged-in IPv6 Nodes 426 In this case, plugged-in nodes do NOT issue special dedicated packets 427 to show their appearance. (Current standard networks are composed of 428 such nodes.) So, the Detector must watch for packets that are issued 429 somewhere from new plugged-in nodes. 431 The initial procedure for a standard plugged-in IPv6 node is to auto- 432 configure its address and do DAD (Duplicate Address Detection) [ADDR- 433 AUTO]. 435 DAD packets have sufficient characteristics for an appearance- 436 detection method, because they are issued only when IPv6 nodes are 437 plugged in, and address information for the plugged-in IPv6 nodes is 438 included in DAD packets. 440 By watching for only DAD packets, the Detector can detect appearances 441 of new plugged-in IPv6 nodes, and DAD packets become triggers to 442 start Domain Name Auto-Registration. 444 This method enables the mechanism to function without introducing new 445 protocols and without installing new functions into plugged-in IPv6 446 nodes. 448 DAD packets are issued not only for global addresses but also for 449 link-local or site-local scope addresses. All detected information is 450 sent to the Registrar, and the manner of dealing with information for 451 non-global addresses is determined by Registrar algorithms that are 452 indicated by Detector IDs of the detected information. 454 This method works effectively on ordinary IPv6 links where DAD 455 packets are issued. However, on extraordinary IPv6 links where DAD 456 packets are not issued, it does not work. On such links, there must 457 be another initial procedure that substitutes the DAD function. Such 458 a procedure can be used as a trigger for a detection method on 459 extraordinary IPv6 links. 461 (IP addresses can be assigned by other methods (e.g., DHCP). Domain 462 name registration mechanisms for such cases will be discussed further 463 in other documents.) 465 3.4.2 Detecting Appearance of "Active" Plugged-in Nodes 467 In this case, plugged-in nodes issue special dedicated packets to 468 show their appearance. The Detector must listen for and receive 469 packets from the new plugged-in nodes. 471 Since plugged-in nodes do not know the location of the Detector, 472 anycast or multicast packets are used for the special dedicated 473 packets. 475 In this method, plugged-in nodes can actively show their preference 476 for their domain names. However, it will be difficult to show their 477 preference under plug and play situations. 479 In order to achieve the method, new protocols must be defined and new 480 functions must be installed into plugged-in IPv6 nodes. 481 (This will be discussed further in other documents.) 483 3.5 Methods of Controlling Registration 485 If received Dynamic Update messages are correctly formatted and 486 authenticated, the DNS server accepts them without checking for any 487 duplication, because the DNS server can not distinguish overwrite 488 (update) registrations from duplicate registrations. It is difficult 489 to achieve a mechanism for avoiding duplicated registrations on the 490 DNS server side. 492 Therefore, registrations by the Dynamic Update messages must be 493 controlled on the Registrar side. This control mechanism also helps 494 to minimize the effects of malicious or misconfigured registration 495 requests. 497 Plugged-in nodes may switch on and off frequently and issue DAD 498 packets frequently. Since the Detector sends detected information 499 without applying any selection rules to it, all detected information 500 is sent to the Registrar. Thus, the Registrar must have some 501 information verification mechanism to avoid duplicated registrations. 503 All candidate information (detected addresses) for registration is 504 checked by using inverse DNS resolving queries of them. If there is 505 FQDN information that matches the detected address, such registration 506 candidates are not registered. 508 Only when FQDN information for it is NOT found and it is verified 509 that the detected information is based on first appearance of the 510 plugged-in node, appropriate domain name information for registration 511 is prepared and both regular and inverse domain name information for 512 it are registered to the DNS servers by the Dynamic Update messages. 514 By using this verification mechanism, the Registrar does not have to 515 have a local database to maintain the status of the detected 516 information and no DNS registration inconsistency problems are 517 caused. 519 By restricting the number of Dynamic Update messages that are sent 520 from the Registrar per unit of time, the effects of malicious or 521 misconfigured registration requests are minimized. 523 3.6 Naming Rules for Default Domain Names 525 This section describes a method of setting "default domain names" for 526 plugged-in nodes. 528 A fully qualified "default domain name" is composed of a node's 529 original prefix part and a DNS zone suffix part that is the same for 530 each site or link. 532 Since a DNS zone suffix is given to the Registrar manually, only the 533 naming rules for a node's original prefix are discussed here. A 534 naming rule algorithm for a node's prefix is given to the Registrar 535 manually. 537 It is not necessary to define naming rules for a node's prefix 538 explicitly in this document. Each site can define its own naming 539 rules (algorithms) per link according to site policy. 541 This document shows some example naming rules for a node's prefix 542 name. 544 1. Prefix Letter(s) + Number 546 This is the easiest rule. First, prefix letter(s) that depends on 547 each link (Detector ID) is/are selected, and the following number 548 is selected after that. 550 The following numbers comprise sequential numbers. In order to 551 achieve this, the Registrar must remember the last selected 552 number. 554 There are some situations where using sequential numbers is not 555 favorable because the next number could be easily predicted. In 556 those cases, random numbers can be used, which makes it necessary 557 to implement the Registrar with a duplicate number check 558 mechanism. 560 2. Predefined Names 562 The Registrar prepares predefined names (e.g., names of flowers) 563 that are used for prefix names for plugged-in nodes. Random or 564 sequential numbers can be used to prepare predefined names. 566 This method can be used for an environment where the number of 567 plugged-in nodes can be estimated and the number is not 568 excessively large. 570 3. Use Preferences of Plugged-in Nodes. 572 The Registrar inquires the preference or property of a plugged-in 573 node, and uses the obtained information as a hint to define a 574 prefix name for the plugged-in node. 576 There are two types of methods for plugged-in nodes to indicate 577 their preference or property. 579 One is "passive" indication. Plugged-in nodes do NOT become an 580 initiator to indicate their preferences. The Registrar becomes an 581 initiator and issues query packets to plugged-in nodes. Existing 582 protocol (e.g., Node Information Query [NIQ], SNMP) is used for 583 it. 585 For a detected global address, the Registrar can use Node 586 Information Query [NIQ] to obtain hint information to define a 587 name for the plugged-in node. 589 By using [SNMP], the Registrar can also obtain hint information to 590 define a name for the plugged-in node. Plugged-in nodes use parts 591 of MIB to indicate their preferences or properties. It is possible 592 to define a special MIB for this purpose. Also, some parts of 593 currently existing MIB can be used for it. Most plugged-in nodes 594 have already set some property information (OS type, version, 595 etc.) to their MIB when they are plugged in. Such information can 596 be used for a hint to define a prefix name. (The Registrar must 597 have an appropriate read access right to such MIB information.) 599 The other is "active" indication. Plugged-in nodes become an 600 initiator to indicate their preferences and issue special 601 dedicated packets for it. Since plugged-in nodes do not know the 602 location of the Detector or Registrar, anycast or multicast 603 packets are used for them. It is possible to attach name 604 preference information to packets that are used for showing the 605 appearance of plugged-in nodes. The Registrar can receive such 606 information via the Detector. 608 In order to achieve the "active" indication method, new protocols 609 must be defined and new functions must be installed into plugged- 610 in IPv6 nodes. 611 (This will be discussed further in other documents.) 613 4. Procedures of the Domain Name Auto-Registration 615 Figure 3 shows an example of typical Domain Name Auto-Registration 616 procedures at IPv6 links where DAD packets are issued. DAD packets 617 are used for the appearance detection method (for standard plugged-in 618 IPv6 nodes). 620 Plugged-in Router Detector Registrar DNS servers 621 IPv6 Node 622 | link local | | | | 623 (a)|---DAD NS--->----------->| | | 624 (b)| no NA | | | | 625 (c)| | |----------->| | 626 | | | | | 627 | global | | | | 628 (d)|(----RS--->)| | | | 629 (e)|<----RA-----| | | | 630 (f)|---DAD NS--->----------->| | | 631 (g)| no NA | | | | 632 (h)| | |----------->| | 633 | | | | | 634 (i)| | | |----------->| 635 (j)| | | |<-----------| 636 | | | | | 637 (k)|(<-----------------------------------)| | 638 (l)|(----------------------------------->)| | 639 | | | | | 640 (m)| | | |----------->| 641 (n)| | | |<-----------| 642 | | | | | 643 (o)| | | |----------->| 644 (p)| | | |<-----------| 645 (q)| | | |----------->| 646 (r)| | | |<-----------| 647 | | | | | 649 Fig. 3 Example of Typical Auto-Registration Procedures 651 (a) and (b) are DAD procedures for the link-local address of the 652 Plugged-in Node. (b) is a procedure to verify that there is no NA 653 (reply to NS) and the link-local address is not duplicated on the 654 link. 656 The Detector watches (a) and (b), and detects the appearance of new 657 plugged-in IPv6 nodes. (c) is a procedure for sending the detected 658 information, to which the Detector ID is attached. The scope of the 659 detected address is not checked at the Detector. 661 After the Registrar receives the detected information by the 662 procedure (c), the scope of the detected address and the decision 663 algorithm (which depends on the Detector ID) are checked on the 664 Registrar. 666 In typical cases, the decision algorithm shows that link-local 667 addresses are not candidates for registration. In such cases, the 668 detected information for the link-local address is discarded at this 669 point. 671 (d)(e)(f) and (g) are DAD procedures for the global address of the 672 Plugged-in Node. (d) is an optional procedure. (g) is a procedure to 673 verify that there is no NA (reply to NS) and that the global address 674 is not duplicated. 676 The Detector watches (f) and (g), and detects the appearance of new 677 plugged-in IPv6 nodes. (h) is a procedure for sending the detected 678 information, to which the Detector ID is attached. 680 After the Registrar receives the detected information by the 681 procedure (h), the scope of the detected address and decision 682 algorithm (which depends on Detector ID) are checked on the 683 Registrar. 685 In typical cases, the decision algorithm shows that global addresses 686 are candidates for registration. In such cases, check procedures to 687 avoid duplicated registrations are started at this point. 689 (i) and (j) are check procedures to verify that the detected address 690 is must be registered to the DNS. The Registrar checks for the 691 existence of FQDN information for the detected address by executing 692 "inverse DNS name resolving" procedures with the detected address 693 argument. 695 If the existence of FQDN information for the detected address is 696 verified, such detected address information for registration is 697 canceled and discarded at this point. 699 If the existence is not verified, the Registrar starts preparing 700 "default domain name" information for the candidate IPv6 address. DNS 701 zone suffix information that depends on the Detector ID is taken from 702 the Registrar's manually configured database table, and the naming 703 rule algorithm that depends on the Detector ID is also taken from it. 705 By following the defined naming rule algorithm, the plugged-in node's 706 prefix name is selected. 708 (k) and (l) are optional procedures for preparing "default domain 709 name." If the naming rule that is applied for the detected address 710 stipulates inquiring the preference or property of the node, (k) and 711 (l) are executed and such information is obtained by the Registrar. 712 The obtained information is used as a hint to select the prefix name 713 of the plugged-in node. 715 A candidate "default domain name" for the detected address is 716 prepared here. 718 (m) and (n) are check procedures to verify that the candidate 719 "default domain name" is not used by anyone. The Registrar checks for 720 the existence of the candidate "default domain name" by executing 721 "regular DNS name resolving" procedures with the candidate "default 722 domain name." 724 If the existence is not verified, it becomes fully qualified "default 725 domain name." If the existence is verified, the Registrar restarts 726 and repeats preparing a candidate "default domain name" for the 727 detected address. 729 After fully qualified "default domain name" information to register 730 is prepared, (o)(p)(q) and (r) are executed to register both regular 731 and inverse domain name information to the DNS servers by the Dynamic 732 Update messages. 734 (Under manual configuration situations, (o)(p)(q) and (r) procedures 735 are replaced by the administrators' manual registration (not by the 736 Dynamic Updates).) 738 5. Treatment of "Temporary Addresses" in the Mechanism 740 "Temporary address" is defined in [RFC3041]. Temporary addresses are 741 detected in this mechanism, because DAD packets are issued when 742 temporary address are generated. 744 There are two views whether domain names for temporary addresses 745 should be registered to the DNS or not. 747 One view is that domain names for temporary addresses should NOT be 748 registered to the DNS, because temporary addresses are temporary and 749 they are introduced to lessen privacy concerns. 751 The other view is domain names for temporary addresses should be 752 registered to the DNS. [RFC3041] discusses on this issue at section 4 753 of [RFC3041]. In order to meet conventional inverse-DNS-based 754 "authentication," nodes could register temporary addresses in the DNS 755 using random names. The Domain Name Auto-Registration mechanism can 756 provide a solution for this issue. 758 Since there are two views for domain names registration of temporary 759 addresses, which view should be chosen is depends on site policies. 761 5.1 How to Distinguish "Temporary Addresses" from Public Addresses 763 In order to apply above discussed policies, it is necessary to 764 distinguish "temporary addresses" from public addresses. 766 Only with IP address information, it is difficult to tell that a 767 detected address is a temporary address or a public addresses. So, 768 link-layer address information is utilized to achieve this operation 769 (see section 3.2). 771 By utilizing link-layer address information, we can easily tell that 772 a detected address is a EUI64-based address or not. (This operation 773 is called a "EUI64 check" operation.) 775 If a detected address is a EUI64-based, it is not a temporary 776 address. It is a normal target address for the Domain Name Auto- 777 Registration mechanism. 779 If not, it must be a either temporary address or manually configured 780 address. We can assume that a domain name for a manually configured 781 address must have been registered in the DNS manually. 783 In the mechanism, an IP address whose domain name has been already 784 registered does not become a candidate. It is verified by "inverse 785 DNS name resolving" check procedures (see (i) and (j) procedures in 786 Figure 3). 788 By applying a "EUI64 check" operation after "inverse DNS name 789 resolving" check procedures, we can assume that non EUI64-based 790 address must be a temporary address. Since temporary addresses are 791 distinguished from public addresses, we can apply above discussed 792 policies to temporary addresses. 794 6. Security Considerations 796 After the Address Autoconfiguration [ADDR-AUTO] has been executed, 797 the Domain Name Auto-Registration works as a succeeding of the plug 798 and play mechanism. The plugged-in IPv6 nodes' appearances detection 799 method is depend on the Address Autoconfiguration. 801 Thus, the items that are described in the Security Considerations 802 section of the Address Autoconfiguration [ADDR-AUTO] are also 803 applicable to this document. 805 In addition, the following security issues are considered. 807 Since the Detector must send detected information to the Registrar 808 securely, some sort of secure communication method (e.g., [TSIG]-like 809 authentication, IPsec (AH, ESP), [TLS]) must be used. 811 The Registrars must be trusted nodes of the DNS servers and Dynamic 812 Update messages must be sent securely from the Registrar to the DNS 813 servers by using some sort of secure communication method. The [TSIG] 814 technique would be suitable for authenticating the messages. 816 In order to minimize the effects of malicious or misconfigured 817 registration requests, the Registrar restricts the number of Dynamic 818 Update messages that are sent from the Registrar per unit of time. 820 Appendix A. HTTP-based simple protocol between Detector and Registrar 822 a. Design of HTTP parameters 824 - Request Parameters 825 method = 826 detectorID = 827 IP-address = 828 link-layer-address = 829 source = 830 time-detected = 832 - Response Parameters 833 result = 834 address = 835 hostname = 836 namehint = 837 error = 838 time-accepted = 840 b. Message Examples 842 - Request message 843 POST /cgi-bin/registrar.cgi HTTP/1.1 844 Host: registrar-host 845 Content-Length: mmm 846 User-Agent: DAD-detector 847 Content-type: application/x-pnp-dnar 849 method=register/2.0 850 detectorID=3ffe:xxxx::2a0:c9ff:fea6:7ff1 851 IP-address=3ffe:yyyy::202:b3ff:fe2d:68c0 852 link-layer-address=00:00:4c:zz:zz:zz 853 source=DAD-detector 854 time-detected=1013078377 856 - Response message 857 HTTP/1.1 200 OK 858 Content-Type : text/plain 859 Content-Length : nnn 860 Connection : close 862 result=REGISTER 863 address=3ffe:yyyy::202:b3ff:fe2d:68c0 864 hostname=host.example.com 865 namehint=none 866 time-accepted=1013078378 868 References 870 [IPv6] S. Deering, R. Hinden, "Internet Protocol, Version 6 871 (IPv6) Specification," RFC2460, December 1998. 873 [ND] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery 874 for IP Version 6 (IPv6)," RFC 2461, December 1998. 876 [ADDR-AUTO] S. Thomson, T. Narten, "IPv6 Stateless Address 877 Autoconfiguration," RFC2462, December 1998. 879 [DYN-DNS] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound, "Dynamic 880 Updates in the Domain Name System," RFC 2136, April 1997. 882 [TSIG] P. Vixie, O. Gudmundsson, D. Eastlake, D. and B. 883 Wellington, "Secret Key Transaction Signatures for DNS 884 (TSIG)," RFC 2845, May 2000. 886 [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", 887 RFC2246, January 1999 889 [DNS-SIG0] D. Eastlake, "DNS Request and Transaction Signatures 890 ( SIG(0)s)," RFC2931, September 2000. 892 [DYN-DNSSEC] B. Wellington, "Secure Domain Name System (DNS) Dynamic 893 Update," RFC3007, November 2000. 895 [DNSSEC] B. Wellington, "Domain Name System Security (DNSSEC) Signing 896 Authority," RFC 3008, November 2000. 898 [SNMP] J. Case, K. McCloghrie, M. Rose, S.Waldbusser, "Protocol 899 Operations for Version 2 of the Simple Network Management 900 Protocol (SNMPv2)," RFC1905, January 1996. 902 [RFC3041] T. Narten, R. Draves, "Privacy Extensions for Stateless 903 Address Autoconfiguration in IPv6," RFC3041, January 2001 905 [HTTP] R. Fielding, et al, "Hypertext Transfer Protocol -- HTTP/1.1" 906 RFC2616, June 1999 908 [TLS-HTTP] R. Khare, S. Lawrence, "Upgrading to TLS Within HTTP/1.1" 909 RFC2817, May 2000 911 [DEF-ADDR] R. Draves, "Default Address Selection for Internet 912 Protocol version 6 (IPv6)," RFC3484, February 2003 914 [NIQ] M. Crawford, "IPv6 Node Information Queries," 915 , June 2003 916 "work in progress" 918 [DNS-DISC] A. Durand, J. Hagino, D. Thaler, "Well known site local 919 unicast addresses to communicate with recursive DNS servers," 920 , October 2002 921 "work in progress" 923 Author's Address: 925 Hiroshi Kitamura 926 Network Development Laboratories, NEC Corporation 927 (Igarashi Building 4F) 11-5, Shibaura 2-Chome, 928 Minato-Ku, Tokyo 108-8557, JAPAN 930 Phone: +81 (3) 5476-1071 931 Fax: +81 (3) 5476-1005 932 Email: kitamura@da.jp.nec.com