idnits 2.17.1 draft-iab-identities-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1293. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1299. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1315), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (March 16, 2004) is 7345 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC2915' on line 617 -- Looks like a reference, but probably isn't: 'RFC 2915' on line 887 -- Looks like a reference, but probably isn't: 'RFC3404' on line 892 -- Looks like a reference, but probably isn't: 'PURLS' on line 925 -- Looks like a reference, but probably isn't: 'Handles' on line 931 -- Obsolete informational reference (is this intentional?): RFC 2396 (ref. '3') (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '4') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2916 (ref. '5') (Obsoleted by RFC 3761) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '6') (Obsoleted by RFC 4941) == Outdated reference: A later version (-38) exists of draft-kunze-ark-07 Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Architecture Board P. Faltstrom 2 Internet-Draft G. Huston, Eds. 3 Expires: September 14, 2004 IAB 4 March 16, 2004 6 A Survey of Internet Identities 7 draft-iab-identities-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3667. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 14, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This memo provides an overview of the various realms of 40 identification used within the Internet protocol suite, with specific 41 observations on the role and purpose of the Domain Name System within 42 this environment. 44 1. Introduction 46 In any communications domain where two parties wish to conduct a 47 conversation across a network each party must specify to the network 48 sufficient information for the network to identify the other party. 50 When the conversation refers to a resource or service that is 51 accessible through the network, the only effective way to refer to 52 such a resource of service is to use an identifier that can 53 subsequently be passed to the network to perform the access. 55 Some networks use a single externally visible identifier structure 56 for all parties and services, such as the numbering scheme used in 57 the Public Switched Telephone Network (PSTN). Other networks use a 58 variety of identifier domains, where each domain has a specific realm 59 of discourse or application. The Internet is an example of a 60 multiple-identifier network, where there are a number of identity 61 realms, each referring to a particular function or area of 62 application. In terms of routing and forwarding IP packets the 63 identity realm used is that of IP addresses, while in terms of 64 identifying particular services or resources the URI form of identity 65 is commonly used. In terms of human use of identities, the most 66 common form of identity in the Internet is based upon the domain 67 name. 69 This document examines the role of identities and identifiers, 70 together with an overview of the various realms of identity that are 71 used in the Internet. The document then looks in more detail at the 72 Domain Name System (DNS) and examines its role in relation to these 73 identity realms. 75 1.1 Desirable properties of Internet Identities 77 Before exploring the set of Internet-based identity realms, its 78 useful to enumerate a set of desirable characteristics of any useful 79 identity system. The following list is of characteristics and some 80 related questions related to properties of the identifier is proposed 81 as a useful, although not comprehensive, collection of identity 82 attributes: 84 Uniqueness: 86 In what realm is the identifier unique? 88 Can the same identifier be associated with two or more distinct 89 objects? 91 Can multiple identifiers be associated with the same object? 93 An identifier can only be used reliably within the realm in 94 which it is unique, and uniqueness is most useful when the 95 association between identities and objects is a strict 1:1 96 relationship. 98 Consistency: 100 Is the identity asserted within a consistent identifier space? 102 This avoids an assertion of identity being interpreted by 103 another party in an unintended manner. 105 Persistence: 107 Does the identity remain constant, or are gratuitous changes in 108 the mapping from the identifier to the referenced object avoided? 110 Constantly changing identities are, at the very least, 111 difficult to track. 113 Trust: 115 Can a particular identity withstand a challenge as to its 116 validity? 118 Other parties who would like to use this identity would like to 119 be reassured that they are not being deceived. 121 Robustness: 123 Is the identity realm capable of withstanding deliberate or 124 unintentional attempts to corrupt it in various ways? 126 Withholding: 128 If the identity is composed of a number of components, are only 129 those components of the identity that are essential to support the 130 communication exposed to other parties? 132 Referential Consistency: 134 If the identity is used in the context of a reference, then when 135 the referenced object is altered or relocated, does the identifier 136 remain a valid reference to the object? 138 Structure: 140 Is the token space from which identity values are drawn structured 141 or unstructured? 143 Structured token spaces allow various forms of retrieval 144 operations based on the identity value to be undertaken 145 efficiently, while unstructured token spaces allow for more 146 flexible generation and use of identities within more 147 restrictive realms of discourse. 149 This list is not attempting to be a complete enumeration of required 150 identifier properties, but instead list the most important desireable 151 properties of identifier realms in the context of the Internet. 153 2. A Hierarchy of Identities 155 In networking models there is a conceptual layering of functionality, 156 starting at the layer of bits on the wire at the media access level 157 and moving up a stack of layers through internetworking, end-to-end 158 transport and application levels. Each one of these layers creates at 159 least one context in which identifiers are used for the 160 communication. It would appear that from this perspective an identity 161 within the Internet is not just a single identity, but an collection 162 of various identities, used in a variety of contexts. 164 2.1 Media Access Addresses 166 There are two generic types of base media in this realm. One is a 167 point- to-point media, a bilateral communications system where all 168 protocol data units (PDUs) generated by one party are passed to the 169 other party. In such environments use of media access addresses are 170 not strictly required. The other form of environment is a 171 multi-access environment, where a number of parties can communicate 172 directly using a common media. In this environment the sender must 173 specify the intended recipient of the PDU, and to achieve this all 174 connected entities use a unique media access address, and the PDU 175 contains the address of the intended recipient. The most common of 176 these multi-access media are encompassed within the IEEE 802 177 collection of media standards. 179 These IEEE 802 technologies share a common structure of Media Access 180 Control layer address (MAC address) to uniquely identity devices 181 connected within a LAN. There are two forms of this identity space, 182 one using a 48 bit identity space (EUI-48 [10]), and the other a 64 183 bit space (EUI-64 [11]). Both identity spaces can be considered as 184 partially-structured identity spaces, where a number of bits within 185 this MAC address determines whether the address has been globally or 186 locally assigned. Globally assigned values are globally unique, but 187 are structured in such a way that there is no imposed hierarchy 188 within the address that could be used for efficient searching, in 189 contexts such as, for example, a routing or forwarding application. 191 A global MAC address identity certainly passes one of the more basic 192 tests of an identity domain, that of uniqueness. Two parties cannot 193 assume the same MAC address value and use this same value as a unique 194 identity. So in a LAN context, a collection of devices can 195 distinguish between each other by virtue of this unique MAC address. 196 A manufacturer of Ethernet devices is assigned a manufacturer's block 197 of Ethernet MAC addresses and uniquely places one address in each 198 device. The end consumer has no need to reconfigure the device with a 199 new address, nor is there any need to alter existing MAC addresses 200 each time the LAN changes with new devices being added. The identity 201 space also has a high utilization capability, in that a manufacturer 202 can assign individual values to devices sequentially so that the 203 identity space can be tightly packed. 205 Beyond these attributes there are some real weaknesses in using a MAC 206 address as an identity outside the context of a LAN environment. The 207 identity space is structured so that it can be readily asserted to be 208 globally unique, but has few other distinguishing properties. The 209 structure of the identity space reflects the manufacturer of the 210 device, not its location within a particular network topology, so its 211 of no assistance as a location token. In the context of equating a 212 device identity to this network interface identity, the identity has 213 limited persistence, in that it follows the interface hardware, not 214 the host computer or its use. For example, switching a device from a 215 wireless to a wired connection changes its MAC identity. The identity 216 has no capability to express any linkage to any other identity 217 domain. It has no internal structure of sub-fields that could be 218 interpreted as pointers into other identity fields. Its precise 219 semantics are to define an interface to a network rather than the 220 device itself. This issue of identifier scope comes up in link layer 221 security discussions where it may not be the best possible approach 222 to bind master session keys to MAC addresses, rather than some other 223 identity. Another example, in IEEE 802.11i it is possible for a host 224 to have multiple interfaces and therefore there is a significant 225 difference between binding an Master Session Key to a MAC address and 226 binding to a host identity. 228 This lack of a direct association between an interface's MAC address 229 and a host device has undesirable effects when it has been assumed 230 that a MAC address equates to a host identity. In "Authentication for 231 DHCP Messages " [7] where the MAC address takes on the role of the 232 DHCP client-identifier, or in the administrative model of IEEE 233 802.11-1999 Wired Equivalent Privacy (WEP) [12] it can be an 234 administrative burden to keep track of all the network interface 235 cards, their MAC addresses and their associated secrets. 237 The use of a MAC address in the context of IP is when one node wants 238 to send a packet to another local node (with a given IP address). The 239 node uses a broadcast query packet with an enclosed address request 240 (an ARP request). This query can be interpreted as "Would the device 241 that has this particular IP address please respond so that I can 242 learn its MAC address". The resulting association of IP address to 243 MAC address can be cached for a short period of time, and for 244 communication over the LAN, using the MAC address is used. In other 245 words resolution of a MAC identity is via local dynamic discovery. 247 Even despite these limitations, the MAC address is regarded as a 248 useful identity mechanism in the context of an identity space. The 249 original 48 bit identity specification has been augmented with 16 250 padding bits in order to be incorporated into the IEEE 64-bit EUI-64 251 global identifier structure, which in turn has been incorporated into 252 the IPv6 address architecture as the interface identifier component 253 of the unicast address [4]. 255 It should be noted that this latter action of embedding one identity 256 (a MAC address) in another (the IPv6 address) lifts the original 257 identity outside its original context. There have been some concerns 258 noted where public disclosure of the MAC address within every IPv6 259 address also discloses both the unique identifier and, potentially, 260 the role of the device. For example, a device manufactured by a 261 specialized storage manufacturer is more likely to be a very 262 expensive storage subsystem housing mission-critical data. This may 263 not be information that is intended to be made public, and a 264 follow-up proposal advocated the ability for the interface identifier 265 within an IPv6 address to be a temporary randomized value [6]. 267 2.2 IP Addresses 269 Moving up one level in the protocol stack model provides an identity 270 based on the internetworking layer, namely the IP address. The IPv4 271 address is a 32 bit field providing each Internet-connected interface 272 with a unique value. IPv6 uses effectively the same construct, using 273 a 128 bit identity domain rather than a 32 bit domain. In both cases 274 the IP address is a structured identity space where there is a 275 globally significant prefix that is used in the context of routing 276 and forwarding outside to a particular local domain, and a local part 277 that is used to deliver the packet to the correct interface of the 278 associated device within the local network. The fact that the 279 structure of the address is based on the requirements of routing and 280 is therefore topologically sensitive implies that the underlying 281 semantics of the IP identity can be most reasonably assumed to be 282 temporal rather than persistent. 284 As an identity token, an IP address should be unique. It is 285 structured to be useful to forward packets to the addressed device, 286 and it's well known, in that it's not a secret value. 288 An IP address is not everything one could hope for in an identity. 289 The IP address identifies an interface, not a device or its user. A 290 device with multiple active interfaces has multiple IP addresses, and 291 while it's obvious to the device itself that it has multiple 292 identities, no remote party can tell that the multiple identities are 293 in fact pseudonyms, and that the multiple addresses simply reflect 294 the potential for multiple paths to reach the same endpoint. 296 Furthermore, the IP address is an information-bearing identifier, 297 which is structured in such a way that it can be used in routing and 298 forwarding. This is helpful in the sense that there is no need to 299 deploy a second identity system that refers only to locality within a 300 network, however it compromises the use of the address as an 301 identity, since in some circumstances a change in the connectivity of 302 a local network will require a renumbering of that network, such that 303 the address of each individual device will change. 305 This is a specific example of the more generic observation about IP 306 addresses, namely that the IP address carries both the identity of 307 the endpoint in the IP realm and the location of the endpoint in the 308 IP network. It is a matter of longstanding study that continues today 309 as to the merits of delineating these two roles of identity at the IP 310 level, creating one identity realm as a means of uniquely identifying 311 an instance of a protocol stack within an end device (variously 312 called a " stack identifier" or "endpoint identifier" in previous 313 studies) and a second identity realm that is used to identify the 314 current location of the identity element within the network 315 (typically called a "locator" identity) [1][13]. 317 2.3 Service and Session Identities 319 In the TCP/IP protocol suite the next level of identity is that of 320 the transport session. In order for a system to advertise a 321 particular service that is a point of attachment for clients it 322 combines three fields: IP server address, transport protocol 323 identity, and the address of the local service identity (port number) 324 into a compound identity that describes a particular service port on 325 a particular device. 327 The port address concept, used in TCP and UDP, represent generic 328 identities for service rendezvous points. When combined with an IP 329 address they become particular service points, or, identified service 330 points, and these compound identification objects (IP address, 331 Transport Protocol, Port) are service identifiers. 333 The identity concept for transport is further extended by including 334 the sender's IP address and port address. The corresponding 5-tuple 335 of (Source IP address, Destination IP address, Transport Protocol, 336 Source Port, Destination Port) is an identifier for a particular 337 instance of a session. Not only is this 5-tuple used at the 338 destination point to correctly de-multiplex an incoming packet stream 339 and send each packet to the correct local instance of the 340 application, the session identity can also be used within the network 341 to recognize a 'flow' of packets that require identical forwarding 342 treatment and may require identical service treatment, if so 343 configured. In the latter case the session identity is being used to 344 trigger a particular service response within the network, and the 345 assumption being made within such contexts is that this 5-tuple is 346 sufficiently unique to identify particular sessions to the relevant 347 network elements. (SCTP also has a port address, but uses a set of IP 348 addresses to identify the remote end. At the network level a 'flow' 349 or 'stream' is identified as a collection of 5-tuples, rathar than as 350 a single 5-tuple.) 352 Session identities are intended to be unique at any point in time, in 353 that two distinct sessions will not share a common session identity. 354 But their association over time is not unique, in that at a 355 subsequent time a different session may use the same 5-tuple. As well 356 as impermanence, session level identifiers exhibit a very fine level 357 of granularity, and as such are often at a level of detail which is 358 too fine to be a useful general identity token across the entire 359 Internet realm. One use is to allow a session to construct an 360 identity that refers to itself or its correspondant that can then be 361 handed into a quality of service policy controller to request a 362 specialized service response for the session. Other uses of session 363 identities can be found in filters, firewalls and network address 364 translators, as well as various forms of middleware applications. 366 2.4 Routing and Forwarding Identities 368 As mentioned above, IP addresses provide information required by 369 routing and forwarding systems. Forwarding is undertaken using the 370 entire address as the lookup function into a forwarding table, using 371 the best match of the address against a table entry as the basis of 372 the forwarding decision (where 'best' refers to a precise match 373 across the longest sequence of leading bits). Routing within the 374 Internet uses a hierarchy of environments, ranging from a non-routed 375 multi-access local network, through a set of locally routed networks 376 where routing is based on comprehensive knowledge of local network 377 topology, through to the interdomain routing environment, where 378 routing is based on a sequence of edge-to-edge transits across 379 domains. 381 This hierarchy of routing is reflected in the structure of addresses. 382 At any point in the routing hierarchy an address is divided into two 383 parts, a routing network part and a subnet address part. Early 384 definitions of this address structure used a fixed division, while 385 later refinements of classless IPv4 addresses and IPv6 both use an 386 explicit prefix length value that is combined with an IP address 387 prefix to form the routing identifier. 389 Interdomain IP routing incorporates both routing identifiers and 390 routing domains, or "autonomous systems". Within a given routing 391 domain, IP routing is performed using only routing identifiers. 392 However for routing between domains, IP routing is performed using a 393 new identity, the Autonomous System number. The most common 394 implementation of inter-domain routing is a distance vector 395 distributed computation of inter-domain topology using vectors of AS 396 numbers as both a loop detection and a path preference mechanism. 397 The AS identity space is an unstructured space of numeric values, 398 allocated from a single 16-bit identifier space. 400 An IP address is located within a routing system by identifying the 401 most specific enclosing routing identifier. Forwarding a packet to a 402 specific IP address involves an algorithm of locating the associated 403 routing identifier and undertaking the forwarding action associated 404 with that object. Coherency of the routing system demands that 405 routing identifiers are managed in a consistent fashion. The 406 overloading of an IP address as both an IP identity and a component 407 of a routing identifier implies that a device's location is 408 implicitly described by its IP address. As noted earlier, relocating 409 a device to a new network location, or relocating a network to a 410 different point in the overall Internet topology necessarily implies 411 associating a new IP address with the device. In the absence of any 412 other mechanisms, this new IP address replaces the previous IP 413 address, changing the device's IP identity, the device's service 414 identities and the device's session identities. 416 2.5 Mobile Identities 418 Device and network mobility adds an additional dimension to identity, 419 in that mobility implies some level of decoupling of the notion of 420 location with that of identity. In one form of approach to this 421 generic space, that of device mobility, a device has an additional IP 422 address that acts as a 'current locator' that describes the device's 423 current location within the network, while the device also retains a 424 constant 'home address' that in effect acts as the device's constant 425 identity and also acts as the discovery service point for its current 426 location. With this approach a 'home agent' acts as a proxy agent for 427 the device when it is roaming beyond the confines of its local 428 network. The home agent tunnels traffic sent to the home address to 429 an address at the host's current topological location, called the 430 'care of' address in Mobile IP. The host is responsible for updating 431 the binding between the home address and the care of address in the 432 home agent, by sending a binding update message when the care of 433 address changes. The mechanism involved in mapping between the home 434 address and care of address is very similar to the mechanism used on 435 the local link for the ARP neighbour cache, except IP addresses are 436 involved for both. 438 This approach raises a critical issue for identities, namely that of 439 robustness. Approaches to mobility need to be aware of a potentially 440 hostile environment where third parties may attempt to subvert the 441 implicit redirection of traffic by assuming the identity of the 442 mobile element through the generation of false updates of the current 443 location. 445 2.6 Opportunistic Identities 447 This concept of maintaining some form of identity association in the 448 face of a communicating within a potentially hostile environment has 449 lead to a proposal for an identity token that has its roots in the 450 public / private key pairs. In this approach the identity token is 451 associated with the public key value of a public / private key pair. 452 A message encrypted with a private key can be passed to the other 453 party where only the originating party's asserted identity (or public 454 key) can decrypt the message. 456 Such identity realms can serve to support a reliable assertion that 457 the received message originated from the same party that originated 458 the communication and that the message has not been tampered with 459 while in transit. The identity systems are opportunistic in that they 460 are self- generated identities, and have no external structure. The 461 implication is that such identities have no particular structure and 462 may not be completely unique. For this reason their utility in other 463 identity applications where persistence or referential integrity is 464 required, such as acting as a persistent reference to other 465 attributes of a named object, is limited. 467 2.7 Domain Names 469 The set of identities described so far have no particular 470 human-visible aspects of their function. The identity tokens are 471 structured to meet a particular purpose, and are not intended, as 472 their primary purpose, to be manipulated by humans nor are they 473 intended to be used primarily within the realm of human discourse. By 474 contrast, the Domain Name System (DNS) was specifically intended to 475 be a name realm that is suitable to be included in human discourse, 476 yet at the same time to admit enough structure to be manipulated by 477 computer applications in a deterministic fashion. In its original 478 incarnation the DNS was a simple replacement for the earlier ' 479 hosts.txt' file, a single replicated host file which was used in the 480 early Internet to map a every name in use to its associated IP 481 address. 483 The DNS is essentially a hierarchical name space, where the 484 hierarchical name structure allows the space to be efficiently 485 searched and managed in a distributed fashion, but also supports one 486 of the most desirable attributes for an identity space. The explicit 487 hierarchy also assists in ensuring uniqueness, as DNS names are 488 intended to be unique across the entire name string rather than just 489 at the first component, so that "a.b.c" is a different identifier to 490 "a.d.e " even though the first token in the domain names, "a", is the 491 same in both cases. 493 The most common use of the DNS is to map domain names to IP 494 addresses, but other uses are possible via mapping a name to a number 495 of other defined 'resources'. The core of the DNS is a unique name 496 space and a mapping capability that allows a query to be performed to 497 retrieve the mapping information for a DNS name for a particular 498 class of resource mapping. 500 The Domain Name System is more than a set of syntactic rules for 501 constructing a well-formed DNS name. The resultant name, if well 502 constructed and properly implemented, can be used as a referral token 503 to a service environment. In this fashion the DNS encompasses a 504 translation service that maps from domain names to defined resources, 505 including IP addresses. For example, given a well formed DNS name, a 506 DNS lookup can query for a corresponding IP address. The DNS 507 describes a data model, a set of relationships between data objects 508 as well as a protocol used to send queries and receive answers. 510 As DNS names provide a mapping from a name to a resource, the name 511 does not need to change when the resource changes location or some 512 other identifying attribute. The mapping changes, but the name 513 remains constant, and for this reason domain names can be considered 514 to be stable unique identifiers, residing within a structured space 515 that can be efficiently searched and managed in a highly distributed 516 manner. 518 2.8 Uniform Resource Identifiers 520 When communicating, applications often need more information than a 521 domain name. For electronic mail, for example, the sending 522 application must use a combination of the domain name, the TCP 523 protocol, the mail delivery or mail agent's service port and the 524 mailbox name of the recipient. Other applications require different 525 compound identification objects, in accordance with their 526 characteristics. 528 Uniform Resource Locators (URLs) are a subset of a more generic form 529 of resource identification, Uniform Resource Identifiers (URIs). As 530 an identity space, the URI space is very loosely defined, and it's 531 quite remarkable as to the extent to which it has spread across the 532 world as a form of object identifier, or identity token. URLs refer 533 to the subset of URIs that identify resources via a representation of 534 their primary access mechanism. Other forms of URIs provide resource 535 identification through a name scheme or by other attributes of the 536 resource. 538 There are few syntax rules to the Universal Resource Identifier 539 space, and only a small amount of common semantic structure. The 540 original IETF documentation, RFC 1630 [2], refers quite simply to a 541 syntax of a prefix word, a colon, and a following string. Where there 542 is hierarchy in the following string, slashes are used to delineate 543 the hierarchical levels, and the hierarchy runs from left to right. 544 The current generic syntax of URIs is described in RFC 2396 [3], and 545 the only change to this generic syntax is to refer to 'schemes', as 546 in ":". 548 The common usage of URIs has been more structured than this general 549 specification, and most URI schemes do not provide a single string 550 that is an alias for an identity, but instead form an identity from 551 the instructions that specify how to access the resource, in the same 552 way as a postal address is often constructed from the instructions as 553 to how to deliver a postal letter to you. This form of a URI, which 554 can be viewed as a location specification, is the basis of the URL 555 scheme. In other words such protocol-scheme URLs consist of what 556 could be interpreted as a device selector, an application selector 557 and an application-specific string that acts as an object reference. 559 Within such protocol-scheme URLs the scheme prefix is an identifier 560 that uniquely identifies the service being referenced, or in terms of 561 access it references the protocol and port address to be used. The 562 first, or top, level of the hierarchical following string is either 563 the DNS name of the server, or the DNS name coupled with some 564 specific qualification, such as a mail address. Any subsequent 565 hierarchical components represent service-specific instructions to be 566 specified that lead you to the referenced object. Thus we have 567 "mailto:user@domain.example.com" for a mail specification, where the 568 scheme prefix "mailto" identifies the use of the TCP transport 569 protocol, a port address of 25 and a protocol of SMTP. The following 570 string, "user@domain.example.com" references the mail agent (a DNS 571 lookup of "domain.example.com" for an MX resource record) and a value 572 to be used in the protocol exchange (delivery to the mailbox 573 "user@domain. example.com"). Similarly, " http://www.example.com/ 574 directory/hierarchy/index.html" for a specific web page uses "http" 575 as a scheme identifier for TCP, port 80, protocol HTTP, the initial 576 part of the following string to reference the server (a DNS lookup 577 for an A or AAAA resource record for "www.example.com") and an HTTP 578 protocol request for "www.example.com/directory/hierarchy/ 579 index.html". 581 In this form of the URL identity system uniqueness is keyed from the 582 general use of a DNS name within the URL, and the wrapping around the 583 DNS string is taking the general form of the DNS as an alias for an 584 IP address, and specifying a service point, and then arguments that 585 are needed to provide to this service point to retrieve the 586 referenced resource. In that way a protocol-scheme URL is closer to a 587 description of an algorithm than to an identifier whose structure of 588 the identifier is adapted to tasks such as sorting, searching or 589 equivalence operations. There are issues with consistency here in 590 that while the hierarchically structured string set makes sense to 591 one application it may not make any sense in the context of a 592 different application. 594 The persistence of protocol-scheme URLs is also an issue, in that the 595 resource may change location over time, and the corresponding 596 algorithm to locate the resource, or URL, must necessarily change as 597 well. The other major difference between a structured identifier 598 space and the protocol-scheme URL approach is that the structured 599 identifier space requires some form of lookup to apply the identity 600 into a retrieval system. By changing the outcomes from the lookup 601 operation, the identity owner can track changes in the location of 602 the resource. In the protocol-scheme URL approach there is no way to 603 understand how widely the identity has circulated, and it is not 604 possible to update the in-circulation copies of the URL. The property 605 of the DNS is that in itself, the DNS identities are simple 606 structured tokens, and they require a lookup operation to be 607 performed in order to produce an algorithm that allows an application 608 to refer to a particular object. While such protocol-scheme URLs are 609 widely used as service and resource identities, they pale in 610 significance, persistence and utility when compared with DNS names. 611 In other words URLs specify "how" to access a service, while generic 612 DNS names can be interpreted as identity tokens that can be used to 613 identify a resource (or "who"). 615 It is also not surprising from this perspective to see the emergence 616 of DNS resource records that refer to URLs, such as NAPTR records 617 [RFC2915]. In this approach the first DNS lookup retrieves one or 618 more URLs that have been associated with the DNS name, and a second 619 lookup is used to resolve any DNS names as may be referenced in the 620 URL strings. In this framework a service may change its location, or 621 the access algorithm may be altered (and by necessity, the URL 622 changed), but the DNS identity that maps to this URL remains 623 constant. This is one of the clearer forms of delineating identity 624 from access mechanisms. 626 This mapping can also be used for service discovery. Given the name 627 of a domain it is possible to look up NAPTR records to discover what 628 URLs can be used for communication with that domain. This is for 629 example used in the ENUM specification [5]. In ENUM a lookup in DNS 630 of NAPTR records for a domain name created from an E.164 number is 631 via transformation turned into a list of URLs. This give an ability 632 to know what URLs one can use in order to contact the entity referred 633 to by a given E.164 number. The more general form of this approach 634 can use NAPTR resource records to associate a DNS name with one or 635 more resources. The name that has the NAPTR records can be considered 636 as an identity token, while the associated NAPTR records provide a 637 mapping from this identity to the instantiation of the identified 638 service. This approach has been used in the Archive Resource Key 639 (ARK) proposal [14]. 641 Of course not all URIs are protocol-scheme URLs of the form outlined 642 above. URIs are a very general construct where the initial "scheme" 643 part of the URI determines the structure and semantics of the 644 remainder of the URI string. The next section examines that class of 645 URIs where persistence of the identity is a specific feature of the 646 identity realm, the Uniform Resource Name. 648 2.9 Uniform Resource Names 650 To solve the problem of lack of long term stability for references, 651 URNs can be used as an alternative to recursive references into the 652 DNS. URNs are generally considered not to be entirely within a human 653 realm as they often include what would appear to be long random 654 combination of characters. URNs are intended to be globally unique, 655 and never reused. As long as a named object exists, it retains that 656 name. An object can have many names. The object may cease to exist, 657 in which case the URN can no longer be resolved, because the 658 resolution service (from URN to URI) is no longer working, but, as 659 the name exists (virtually), a new service can be created and the 660 object re-established if there is need for it. RFC 3305 [8] talks in 661 more detail about the different views which exists on the 662 relationship between URIs, URLs and URNs. 664 2.10 Human Friendly Strings 666 URIs have a problem that URNs didn't solve, and that is the ability 667 for humans to remember them. Humans act in a context, so global 668 uniqueness is not important at this level of abstraction. Instead, 669 when a human uses a name, they normally want a resolution service 670 that "does what they want". In this realm the context of the name is 671 an important factor in resolving the name to an object, and global 672 uniqueness is neither necessary nor assumed. 674 This area of human friendly strings is a topic of ongoing work. One 675 possible goal for a working system is to be able to handle the 676 so-called "side of the bus" problem. A human sees something in an 677 advertisement on the side of a bus, remembers it (or remembers part 678 of it), and when they come to a computer they try to get more 679 information about what they have seen. This involves complex language 680 and localization (and internationalization) problems. 682 No real human friendly naming system exists today on the Internet. 684 There has been various ideas connected to "layers above DNS", for 685 example mentioned in RFC 3467 [9] (subject of the SIREN Research 686 Group in the IRTF). This topic encompasses an effort to decouple the 687 naming realms that makes sense to humans, with their various forms of 688 implied context for resolution, from the naming realms that work for 689 computers, with the implication of explicit specification of 690 resolution, and define a mapping between them. The DNS can't handle 691 the types of names that often make sense to people, because people 692 always work in a context (such as a geographical context of ' 693 locality'), and it's no longer sufficient for people to fit their 694 needs into what DNS can handle. For a long time, it was considered 695 possible to overload the semantics of the DNS label 696 (machine-parseable, vaguely human- recognizable) but it is becoming 697 evident that this is not a tenable approach, and some distinction 698 needs to be drawn between DNS names and context-sensitive 699 human-friendly strings. 701 3. Issues with Identities 703 3.1 Overloading the IP Address 705 An IP address suffers from semantic overload in attempting to carry 706 both location and some form of constant identity. If a network or 707 individual device changes access providers then this is, in effect, a 708 change in network location, and if provider-based address aggregation 709 is being used, then the local IP address will change. The same issue 710 applies with mobile devices. This implies that an IP address is not 711 necessarily a permanent or truly persistent association with a 712 device, and such impermanence is a weakness in any persistent 713 identity system. 715 Another issue with IP addresses, at least in version 4 of the 716 protocol, is that of their total span. While 32 bits is still a large 717 size, encompassing some 4.4 billion unique addresses, there is an 718 inevitable level of wastage in deployment, and a completely exhausted 719 32 bit address space may only encompass a connectivity realm of 720 perhaps only 1 or 2 billion IP devices. When this is coupled with a 721 world of embedded IP devices in all kinds of industrial and consumer 722 applications, 1 or 2 billion addresses is insufficient to provide 723 unique addressing to every possible device. 725 In response to these address pressures there has been the 726 introduction of a number of technologies that dilute the strong 727 binding of IP address with identity. Such approaches tend to treat 728 the IP address purely as a routing and forwarding token without any 729 of the other attributes of identity, including persistence and public 730 association. For example, DHCP, or address-lending, is a commonly 731 used method of extending a fixed pool of IP addresses over a domain 732 where not every device is connected to the network at any given time, 733 or when devices enter and leave a local network over time and need 734 addresses only for the time they are within the local network's 735 domain. In this form of identity, the association of the device with 736 a particular IP address is temporary, and hence there is some 737 weakening of the identity concept, as the dynamically-assigned IP 738 address is being used primarily for routing and forwarding. This has 739 been taken a further step with the use of dynamic Network Address 740 Translation (NAT) approaches, where a single device has a pool of 741 public addresses to use, and maps a privately used address to one of 742 its public addresses when the private device initiates a session with 743 a remote public device. The private-side device has no direct 744 knowledge of the public address that the NAT edge will use for the 745 session, nor does the corresponding public-side device necessarily 746 know that it is using a temporary identity association to address the 747 private device. 749 These forms of changes to the original semantics of an IP address are 750 significant architectural changes to the concept of identity at the 751 level of IP, particularly in the presence of NATs. The widespread 752 deployment of such approaches continues to underline the concept that 753 as an identity token there is a lack of persistence in an IP address, 754 and the various forms of aliasing weaken its utility as an identity 755 system. The conclusion drawn from these observations is that, 756 increasingly, an IP address, in the world of the IPv4 Internet, is 757 being seen primarily as a locality token with a very weak association 758 with some form of identity. 760 Version 6 of IP represents an effort to restructure the address 761 field, and the 128 bits of address space represents a very large 762 space in which to attempt to place structure. One of the more 763 innovative concepts that was discussed within the development of IPv6 764 was extending the concept of the IPv6 interface identifier field of 765 the address to be a globally unique identifier. This had some obvious 766 connotations in being able to identify when the connectivity for a 767 device has changed, as in such cases the globally unique interface 768 identifier could remain constant while the routing prefix may have 769 changed. There was also some potential applications in the area of 770 supporting multi-homed networks, where a local network could be seen 771 via different routing prefixes. At present these aspects of IPv6 772 address architecture are the topic of ongoing work in the IETF. One 773 of the fundamental issues with this form of approach is management of 774 an interface identifier space that is globally unique and persistent, 775 as well as being adequately robust. Current directions of activity 776 in this area indicate that the self- assertion of identity using this 777 field within IPv6 are insufficiently robust to prevent various forms 778 of redirection attacks. Mechanisms currently being investigated are 779 looking deeper into various aspects of mechanisms to provide 780 corroboration of identity assertion in the face of locator change and 781 additional protocol mechanisms appear to be a common feature of the 782 current proposals relating to multi-homing and aspects of mobility. 784 3.2 Dynamic DNS Updates and Nomadism 786 An alternative mechanism to revising the semantics of the IP address 787 is looking at the concept of moving the role of completing the 788 transition of persistent identity into the DNS. Here the constant 789 identity of the device is its DNS name. In a mobile context, as the 790 device or network it roams across the network, and by using a 791 sequence of secure dynamic incremental updates to the DNS, update the 792 association of the constant DNS name to the new local IP address. 793 This approach has possible applications in various multi-homing 794 scenarios. 796 However, this approach is not without attendant considerations. Much 797 of the leverage of the DNS as an efficient lookup mechanism is based 798 on extensive use of local caching of DNS information. Increasing the 799 responsiveness of the DNS to dynamic updates implies that the extent 800 to which cached information can be retained is compromised, and any 801 cache has to refer more frequently to the primary source to refresh 802 the currency of the local cached copy. The tradeoff here is greater 803 DNS traffic loads and increased DNS server query loads in order to 804 get a more responsive name system. Such a mechanism also requires an 805 "always available" primary DNS server to accept the incremental 806 updates, so that the failure backup mechanism of the DNS with primary 807 and secondary servers is compromised in this nomadic model with the 808 requirement for primary server availability in order to undertake an 809 authoritative update to the DNS. 811 An alternative approach is to equip the DNS with an additional 812 resource record that contains an identity value in addition to the 813 current A or AAAA address values. This approach can be used in 814 conjunction with an additional element within the protocol stack that 815 could allow the transport layer to operate using this identity field, 816 and a new stack element provides a dynamic mapping between this 817 identity and a 'current' locator value, where the equivalent current 818 locator is passed into the IP protocol element. 820 An alternative to this approach of changing mappings is to place the 821 responsibility for the redirection into the application protocol. 822 For example, with SIP, the mobile node could use the REGISTER method 823 to change its registration for session setup. This may not be fast, 824 but may be faster than dynamic DNS updates and perhaps even fast 825 enough for handling initiating new sessions. A mobile HTTP server, on 826 the other hand, would have to use HTTP Redirect from a fixed server 827 whose address was in the DNS. 829 3.3 URLs and Persistent Identifiers 831 URLs are, as their name suggests, locators rather than location 832 independent identifiers. When the resource is relocated, or when 833 multiple copies of the same resource exist, the URL scheme cannot 834 persist across the change. Despite the almost universal use of the 835 URL within web browsers, URLs are not an ideal candidate for a 836 persistent identity. 838 This weakness in the URL scheme has lead to the consideration of many 839 alternate naming schemes, although the underlying requirements for 840 any candidate naming scheme is that it is cleanly mappable into a 841 URI-styled format and that there is a robust resolution system 842 associated with the name scheme. Resolution is a critical factor 843 here, as without the ability operate in a predictable, robust, 844 scaleable, trustable and reliable manner when translating an 845 identifier into a resource, entity or service access description, the 846 identifier scheme is of dubious value. 848 The requirement for persistent identifiers is not to dispense with 849 URLs, or similar forms of locators and service descriptors, but to 850 separate the notions of identification and location, and to use 851 distinct label space for each concept, and to use a resolution 852 mechanism to map from the identifier to the location descriptor. 854 Work on the development of a unique permanent identifier space has 855 proceeded concurrently with the formalization of URL schemes, using 856 the name of URN (Uniform Resource Name) schemes. A specification 857 outlining the minimum requirements of the URN can be found at [RFC 858 1737]. The syntax of the URN as expressed in RFC 2141 is as follows: 859 urn:: 860 The NID ensures the global uniqueness of the identifier. The NSS 861 can take any form specified by the naming authority provided that 862 it is unique within that namespace. 864 The simple structure of the identifier reflects recognition of the 865 need to accommodate different requirements and different schemes. 866 Because the local, or namespace specific, string can be in any form, 867 the identifier structure allows maximum flexibility in the identifier 868 while providing a mechanism to assure global uniqueness and 869 facilitating interoperability between discrete systems. 871 There is a need to distinguish between naming schemes and resolution 872 systems. A naming scheme, as a procedure for creating unique URNs 873 that conform to a specific syntax, is independent of the resolution 874 service which resolves the URN to locate the resource. Ideally, a 875 naming scheme should not be tied to any specific resolution system 876 and a resolution service should be capable of resolving a URN from 877 any given name scheme. 879 This objective is consistent with the intentions behind the 880 development of the URN. A persistent identifier, especially when used 881 for archival data must of necessity be capable of outlasting any 882 systems and protocols that are currently in use. However the lack of 883 a commonly agreed upon resolution system is also a major obstacle to 884 the wide deployment of URNs. 886 A variety of solutions have been proposed, including the NAPTR 887 (Naming Authority PoinTeR) DNS resource record [RFC 2915], that 888 provides rules for mapping parts of URIs to domain names and then 889 using these domain names as DNS lookup queries to find mapped URIs. 890 This was specification has been further refined as the Dynamic 891 Delegation Discovery System (DDDS) [ RFC3401, RFC3402, RFC3403, 892 RFC3404]. As noted in [RFC3404], " For the short term, the Domain 893 Name System (DNS) is the obvious candidate for the resolution 894 framework, since it is widely deployed and understood. However, it is 895 not appropriate to use DNS to maintain information on a per-resource 896 basis. First of all, DNS was never intended to handle that many 897 records. Second, the limited record size is inappropriate for 898 catalogue information. Third, domain names are not appropriate as 899 URNs. Therefore our approach is to use the DDDS to locate "resolvers" 900 that can provide information on individual resources, potentially 901 including the resource itself." 903 There appears to be some residual issues over the status of URNs. For 904 URNs to achieve widespread deployment, not only is consensus on 905 functional requirements and syntax needed, but the ability to 906 recognise and resolve URNs should be incorporated into the 907 application realm. For example, it would be a reasonable objective to 908 incorporate URN support in standard Web browsers. However a 909 pre-requisite for this step is the definition and construction of the 910 necessary resolving infrastructure, developed either by leveraging 911 off the existing Domain Name System or by some other route. As long 912 as application developers are uncertain of what is to be accepted as 913 a standard resolution mechanism, and while naming scheme developers 914 are uncertain of how to register their name and resolution schemes 915 these issues will not be fully resolved. 917 Until the resolution issues are clarified and there is clear 918 consensus to adopt a particular specification, implementation of URN 919 systems will require some form of application level assistance by way 920 of proxy servers. The implication is that use of URNs will require 921 encapsulation in a URL in order to specify the appropriate proxy 922 server address. 924 This approach has already been undertaken in the specification of 925 PURLS [PURLS], which is a naming scheme that incorporates within the 926 PURL a conventional URL reference to a resolver to specify a PURL 927 resolution service and a name part of the URL that the resolution 928 service translates to the resource URL. In a web-based context this 929 is handed back to the client as an HTTP redirect. 931 In comparison, the Handle system [Handles] uses a non-URL name 932 scheme, and resolution in applications requires modification of the 933 application. The 'handle' itself is a persistent identifier 934 consisting of two parts. The syntax is a two part identifier of 935 "/< name>" where the naming authority is an 936 administrative unit authorised to create and maintain handles and the 937 name of the resource is a string which must be unique to that 938 authority but which has no prescribed syntax. Use of handles can be 939 through standard web browsers using a plug-in, or through unmodified 940 web clients using proxy servers and embedding the handle within a URL 941 that specifies a handle resolver in a manner similar to the PURL 942 approach. The specification of a distinct handle syntax allows 943 handles to be used in a broader set of contexts than web browsing as 944 there is independence of the identifier to a particular access 945 protocol and server location. 947 The issue of resolution of the compound identifiers remains 948 problematic, and the use of embedding the URN into a proxy URL to 949 undertake redirection can be argued as defeating the purpose of 950 having location and protocol independent identifiers, since the 951 resultant identifier includes the location of the proxy agent. The 952 full value of persistent identifiers to ensure persistence in 953 citations can only be realised if they are actually useful when 954 citing documents and objects. In order to use them, the user must 955 know that there is a persistent identifier and must be able to 956 discover what it is and how to resolve the identity. At present this 957 is difficult because of the nature of the redirects used in most 958 existing systems. 960 4. The DNS in Identity Spaces 962 How good are any of these identities? Which one should be used in 963 which context? 964 Each of these digital identities have a context of usage, or realm of 965 discourse, and outside of that realm they tend to break down as a 966 cohesive and useful identity tool. Offering a MAC address as an email 967 point of contact makes little sense, even though it could conceivably 968 be used to form a unique identity in the mail realm. Offering an 969 identification at the appropriate level of abstraction that provides 970 a description of the mode of contact and identity in a form that 971 matches the actions at this level is often used to distinguish 972 between identities. At the level of human interaction we commonly 973 identify email addresses using a domain and user name part. We do 974 this because this is what you need to enter into your mail 975 application in order to send me a message. 977 There are considerations when generating identity spaces based on 978 generic descriptions of algorithms of how to access the specific 979 resource, trigger the particular application or contact a particular 980 individual or role's network point of presence. These considerations, 981 commonly found in conjunction with URI's, raise consideration of 982 maintaining referential integrity, allowing efficient searching and 983 persistence of the identity. The human world, and its digital 984 counterpart, is far from static. Any identity system that aspires to 985 be useful in a human space needs to be able to support a maintenance 986 function that allows any implicit reference that is contained in an 987 identity space to be updated and refreshed in a reliable, trustable 988 and timely manner. Knowing who you were is a less important piece of 989 information as compared to knowing who you are right now. That leads 990 to consideration of structured identity spaces whose two major 991 attributes are: 992 o sufficient structure to ensure that specific instances of the 993 identity are unique, and 995 o appropriate structure to allow rapid lookup of the identity to be 996 able to retrieve the current set of associated pointers within 997 various specified realms. 999 There is a good match between these desired attributes and those of 1000 the DNS, and one perspective to be drawn from this is that the major 1001 underpinning of useful and lasting digital identities rests within 1002 the framework of the DNS. In other words any useful identity space is 1003 highly likely to have managerial and operational characteristics that 1004 would largely parallel that of the DNS. 1006 4.1 The role of the DNS 1008 Different identities are used in the Internet for different purposes. 1009 IP addresses are essential at the level of forwarding protocol data 1010 units across the network, but are unwieldy to use in the context of 1011 naming resources and services at the level of human operation of 1012 applications. In the context of URIs, the use of a DNS identity 1013 within a URI ensures that the identity of a service doesn't have to 1014 be changed when the IP address changes. The domain name creates an 1015 abstraction layer above the IP addresses that allows a service to be 1016 identified without particular reference to its current location 1017 within the Internet, and using a name realm that has better 1018 properties for human use. 1020 We could use something else, like static tables, databases or more 1021 similar systems like X.500. But, none of these alternatives have been 1022 able to prove they scale as well as DNS. Both the protocol itself and 1023 the data model with the distributed delegation has proven to be 1024 extremely efficient (even though some things could be "better"). 1026 The perspective being espoused here is that we don't have any current 1027 viable alternative to the DNS in terms of a structured identity space 1028 that supports mapping across identity realms. Even if we stop using 1029 domain names in URI's and instead using something else, deploying a 1030 translation service from this other name to IP addresses would 1031 inevitably involve recreating much of the functionality of the DNS. 1033 4.2 Changing the DNS 1035 Because DNS is the service we use for mapping between many of the 1036 namespaces we use on the Internet, it is extremely important it 1037 works. Because of this, changes to DNS must be made with care. This 1038 refers to both changes to the protocol as well as the DNS data model. 1040 Example of changes to the protocol include the need for DNSSEC 1041 (signed record sets) which makes it possible for a recipient of a DNS 1042 response to verify whether it comes from an authoritative source. 1043 This has been discussed in the IETF for some years, and is 1044 illustrative of the required level of care in the design of changes 1045 to the DNS. 1047 Example of a change to the database structure include a move from an 1048 hierarchical to a flatter namespace. The result might be a 1049 disruptive change of DNS traffic on the global Internet which in turn 1050 might make further scaling difficult. Another similar change is 1051 allocation of names which are not registered properly. Especially in 1052 the root zone, this leads to problems such as the inability to later 1053 allocate and set a policy for the domain, and increased number of 1054 queries for non-existing names in the root zone when leakage of names 1055 happens from presumed to be closed networks. Example of the former 1056 are the very large TLDs like .com and .de. Example of the latter is 1057 the use of the pseudo TLDs '.local' and '.gprs' which are being used 1058 in private or enterprise contexts without any proper definition or 1059 registration and their consequent leakage of queries into the 1060 'public' DNS. 1062 4.3 The DNS is a strict lookup service 1064 When sending a query to a server, the server is to send the same data 1065 back regardless of context. Further, the server should send either a 1066 "match" which consists of one or more resource records, or a 1067 "failure" which include the special response "no such domain". 1069 This implies that two users sending the same query from two different 1070 locations at the same time should receive the same data in response. 1071 Or, the same user using two different computers with different 1072 operating system should receive the same data. 1074 Having the DNS server doing a "search" or "fuzzy matching" is ill- 1075 advised, because the DNS server can not know the context of the 1076 query, nor what the DNS response is to be used for. It is always easy 1077 to guess that the response is to be used by the most popular 1078 operating system, for the most popular application. It must though be 1079 remembered that other operating systems and other applications might 1080 break when fuzzy matching happens. For example, instead of giving 1081 back a "no such response" it is conceivable to give back something 1082 which pushes a potential error to the application layer by returning 1083 a synthesized answer that has resource records pointing to some form 1084 of application- level service. This implies the DNS server must know 1085 what application layer protocol is in use, and that a "no" at the 1086 application layer has the same semantics as a "no" on the DNS 1087 (naming) layer. Often TCP is used at the application layer which 1088 implies a "no" might only be signalled to the other end by not 1089 accepting the connection, which means the querying client cannot 1090 differentiate between "no such (dns) name" and "no response in 1091 application protocol". 1093 4.4 Coherency of the DNS 1095 DNS is a bootstrap mechanism that publishes your data in a manner 1096 that allows queries from others to be answered. If you make mistakes 1097 in your local DNS configuration then you don't destroy the utility of 1098 the DNS for yourself, but you destroy the ability for others to 1099 contact you. Someone trying to reach your webpage might not be able 1100 to do so as they can not find the proper translation from your domain 1101 name to the IP address of the web server. It is also the case that 1102 mis-configurations most often happen in the glue between parent zone 1103 and child zone, and not in the child zone itself. Because of this, if 1104 you know where your nameserver is, you might not see the errors, as 1105 they have to do with finding the nameserver, and not the content of 1106 it. 1108 As mentioned before, it is very important the same response is sent 1109 back regardless of from where it is sent. The assumption within the 1110 DNS is that you should be able to pass a URI with an embedded domain 1111 name in it to all of your friends, and they all should be able to 1112 resolve it in an identical fashion. It is extremely important the 1113 domain names are globally unique, and lead to the same result every 1114 time, and from every location. 1116 Part of the coherence requirement is that the servers must be able to 1117 give back the same response to the same query. The implication is 1118 that all servers have to use the same matching algorithms when 1119 attempting to locate a match between a query and the local data used 1120 to form a response. What matching algorithm is used when looking in 1121 the data cannot change between servers because then they will give 1122 back different results for the same query. 1124 Complications arise when considering this in the context of use of 1125 various character sets within the DNS. Having each server use a local 1126 set of rules that defines equivalence of characters generates the 1127 situation of the same query generating different responses. The 1128 implication is that the consideration of different matching/equality 1129 rules can be solved by creating "bundles" of characters which are to 1130 be treated as equal, and solving the problem at the time of 1131 registration. This gives a greater choice for the registrant, and it 1132 can also give a higher freedom regarding context, as the bundles 1133 possibly look differently depending on such things like (parent) 1134 domain and language. 1136 4.5 The DNS as an Identity Glue 1138 When comparing the desired attributes of a useful identity system to 1139 the properties of the DNS it is evident that there is a reasonable 1140 level of fit between the DNS and a generic identity realm. The DNS 1141 provides a namespace that ensures uniqueness, is consistent, can 1142 support persistence, and referential consistency. There are a number 1143 of compromises that have, necessarily, been made in the design of the 1144 DNS. The space is structured in a manner that supports relatively 1145 efficient lookup over a large name space that has both hierarchical 1146 structuring and within that some areas of large flat name spaces. The 1147 DNS can support trust models in terms of being able to validate the 1148 authenticity of responses. The DNS can support a variety of resource 1149 records that allow a DNS name token to be used as a search object 1150 that can map to related values drawn from other identifier realms, as 1151 well as supporting indirect self-reference through the use of NAPTR 1152 records and URIs. 1154 There are obvious trade-offs in the design, protocol and deployment 1155 of the DNS in terms of resiliency, dynamic behaviours and 1156 scalability. While it is not argued here that the DNS represents the 1157 only optimal trade-off between these properties, it is argued that 1158 any other identity space with similar properties will be faced with 1159 precisely the same set of trade-offs. It is also probable that any 1160 similar identity space faced with the same requirements of 1161 scalability, operational performance, accuracy and validity of 1162 responses and flexibility of mapping the identity space to related 1163 objects in other identity realms would find a resolution between 1164 these requirements in a manner that would not differ markedly from 1165 the DNS. 1167 The salient observation here is that an identity system acts 1168 generically as a reference to an initial point of rendezvous in a 1169 communication transaction. In this vein the role of the identity 1170 system is to identify how other parties in the network can refer to 1171 the identified element using an identity token that is persistent, 1172 with associated referential mappings into other identity realms that 1173 reflect the current status of the element. Once a communications 1174 state has been established using the rendezvous points, if there are 1175 characteristics of the application that require the subsequent 1176 exchange of information (such as location changes in a mobility 1177 environment, or a server hand-over at the application level) this is 1178 generally the task of components within the protocol stack, using a 1179 trust relationship between the communicating parties to alter the 1180 identity elements used within the stack to match the changing 1181 characteristics. 1183 5. Security Considerations 1185 [To be completed. Topics include wrong domain, napping, grabbing 1186 misspellings, multiple roots, etc. ] 1188 [Also note that: identity realms need to operate with authenticity 1189 that can be verified in a trustable manner. DNNSEC is your friend.] 1191 6. Acknowledgements 1193 The editors acknowledge the contributions made by Leslie Daigle and 1194 James Kempf. 1196 Normative References 1198 Informative References 1200 [1] Saltzer, J., "On the Naming and Binding of Network 1201 Destinations", RFC 1498, August 1993. 1203 [2] Berners-Lee, T., "Universal Resource Identifiers in WWW: A 1204 Unifying Syntax for the Expression of Names and Addresses of 1205 Objects on the Network as used in the World-Wide Web", RFC 1206 1630, June 1994. 1208 [3] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1209 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1210 1998. 1212 [4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1213 Specification", RFC 2460, December 1998. 1215 [5] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 1216 2000. 1218 [6] Narten, T. and R. Draves, "Privacy Extensions for Stateless 1219 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 1221 [7] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 1222 RFC 3118, June 2001. 1224 [8] Mealling, M. and R. Denenberg, "Report from the Joint W3C/IETF 1225 URI Planning Interest Group: Uniform Resource Identifiers 1226 (URIs), URLs, and Uniform Resource Names (URNs): Clarifications 1227 and Recommendations", RFC 3305, August 2002. 1229 [9] Klensin, J., "Role of the Domain Name System (DNS)", RFC 3467, 1230 February 2003. 1232 [10] IEEE, "Guidelines for use of a 48-bit Global Identifier 1233 (EUI-48)", December 2003, . 1236 [11] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 1237 Registration Authority", December 2003, . 1240 [12] IEEE, "802.11 Wireless", December 2003, . 1243 [13] Shoch, J., "Internetwork Naming, Addressing, and Routing", 1244 Proceedings of the 17th IEEE Computer Society International 1245 Conference pp. 72-79, December 1978. 1247 [14] Kunze, J. and R. Rodgers, "The ARK Persistent Identifier 1248 Scheme", draft-kunze-ark-07 (work in progress), February 2004. 1250 Authors' Addresses 1252 Patrik Faltstrom 1253 Internet Architecture Board 1255 Geoff Huston 1256 Internet Architecture Board 1258 Appendix A. IAB Members 1260 Internet Architecture Board Members at the time this document was 1261 completed were: 1263 Bernard Aboba 1264 Harald Alvestrand 1265 Rob Austein 1266 Leslie Daigle 1267 Patrik Faltstrom 1268 Sally Floyd 1269 Jun-ichiro Itojun Hagino 1270 Mark Handley 1271 Geoff Huston 1272 Pete Resnick 1273 Bob Hinden 1274 Eric Rescorla 1275 Jonathan Rosenberg 1277 Intellectual Property Statement 1279 The IETF takes no position regarding the validity or scope of any 1280 Intellectual Property Rights or other rights that might be claimed to 1281 pertain to the implementation or use of the technology described in 1282 this document or the extent to which any license under such rights 1283 might or might not be available; nor does it represent that it has 1284 made any independent effort to identify any such rights. Information 1285 on the IETF's procedures with respect to rights in IETF Documents can 1286 be found in BCP 78 and BCP 79. 1288 Copies of IPR disclosures made to the IETF Secretariat and any 1289 assurances of licenses to be made available, or the result of an 1290 attempt made to obtain a general license or permission for the use of 1291 such proprietary rights by implementers or users of this 1292 specification can be obtained from the IETF on-line IPR repository at 1293 http://www.ietf.org/ipr. 1295 The IETF invites any interested party to bring to its attention any 1296 copyrights, patents or patent applications, or other proprietary 1297 rights that may cover technology that may be required to implement 1298 this standard. Please address the information to the IETF at 1299 ietf-ipr@ietf.org. 1301 Disclaimer of Validity 1303 This document and the information contained herein are provided on an 1304 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1305 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1306 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1307 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1308 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1309 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1311 Copyright Statement 1313 Copyright (C) The Internet Society (2004). This document is subject 1314 to the rights, licenses and restrictions contained in BCP 78, and 1315 except as set forth therein, the authors retain all their rights. 1317 Acknowledgment 1319 Funding for the RFC Editor function is currently provided by the 1320 Internet Society.