idnits 2.17.1 draft-iab-identities-02.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.1.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1848. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1825. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1832. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1838. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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 uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 == Line 459 has weird spacing: '...dresses may n...' -- 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 (December 14, 2004) is 7070 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) -- Obsolete informational reference (is this intentional?): RFC 2141 (ref. '6') (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 2396 (ref. '7') (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '8') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '9') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2915 (ref. '10') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) -- Obsolete informational reference (is this intentional?): RFC 2916 (ref. '11') (Obsoleted by RFC 3761) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '12') (Obsoleted by RFC 4941) == Outdated reference: A later version (-38) exists of draft-kunze-ark-08 Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Architecture Board P. Faltstrom, Ed. 3 Internet-Draft G. Huston, Eds., Ed. 4 Expires: June 14, 2005 IAB 5 December 14, 2004 7 A Survey of Internet Identities 8 draft-iab-identities-02.txt 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on June 14, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). 41 Abstract 43 This memo provides an overview of the various realms of 44 identification used within the Internet protocol suite, with a view 45 to noting the interdependencies of the different identifiers and 46 consequent implications for updating their specifications or changing 47 their infrastructures' operations. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1 Desirable properties of Internet Identities . . . . . . . 3 53 2. A Hierarchy of Identities . . . . . . . . . . . . . . . . . 5 54 2.1 Media Access Addresses . . . . . . . . . . . . . . . . . . 6 55 2.1.1 Summary . . . . . . . . . . . . . . . . . . . . . . . 8 56 2.2 IP Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 57 2.2.1 Summary . . . . . . . . . . . . . . . . . . . . . . . 9 58 2.3 Service and Session Identities . . . . . . . . . . . . . . 10 59 2.3.1 Summary . . . . . . . . . . . . . . . . . . . . . . . 12 60 2.4 Routing and Forwarding Identities . . . . . . . . . . . . 13 61 2.4.1 Summary . . . . . . . . . . . . . . . . . . . . . . . 14 62 2.5 Mobile Identities . . . . . . . . . . . . . . . . . . . . 15 63 2.5.1 Summary . . . . . . . . . . . . . . . . . . . . . . . 15 64 2.6 Opportunistic Identities . . . . . . . . . . . . . . . . . 16 65 2.6.1 Summary . . . . . . . . . . . . . . . . . . . . . . . 17 66 2.7 Domain Names . . . . . . . . . . . . . . . . . . . . . . . 17 67 2.7.1 Summary . . . . . . . . . . . . . . . . . . . . . . . 18 68 2.8 Uniform Resource Identifiers . . . . . . . . . . . . . . . 19 69 2.8.1 Summary for URLs . . . . . . . . . . . . . . . . . . . 22 70 2.9 Uniform Resource Names . . . . . . . . . . . . . . . . . . 23 71 2.9.1 Summary . . . . . . . . . . . . . . . . . . . . . . . 23 72 2.10 Human Friendly Strings . . . . . . . . . . . . . . . . . 24 73 2.10.1 Summary . . . . . . . . . . . . . . . . . . . . . . 25 74 3. Issues with Identities . . . . . . . . . . . . . . . . . . . 25 75 3.1 Overloading the IP Address . . . . . . . . . . . . . . . . 25 76 3.2 Dynamic DNS Updates and Nomadism . . . . . . . . . . . . . 27 77 3.3 URLs and Persistent Identifiers . . . . . . . . . . . . . 28 78 4. The DNS in Identity Spaces . . . . . . . . . . . . . . . . . 31 79 4.1 The role of the DNS . . . . . . . . . . . . . . . . . . . 32 80 4.2 Changing the DNS . . . . . . . . . . . . . . . . . . . . . 32 81 4.3 The DNS is a strict lookup service . . . . . . . . . . . . 33 82 4.4 Coherency of the DNS . . . . . . . . . . . . . . . . . . . 34 83 4.5 The DNS as an Identity Glue . . . . . . . . . . . . . . . 35 84 5. Security Considerations . . . . . . . . . . . . . . . . . . 36 85 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 86 7. Informative References . . . . . . . . . . . . . . . . . . . 36 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38 88 A. IAB Members . . . . . . . . . . . . . . . . . . . . . . . . 39 89 Intellectual Property and Copyright Statements . . . . . . . 40 91 1. Introduction 93 In any communications domain where two parties wish to conduct a 94 conversation across a network each party must specify to the network 95 sufficient information for the network to identify the other party. 96 When the conversation refers to a resource or service that is 97 accessible through the network, the only effective way to refer to 98 such a resource of service is to use an identifier that can 99 subsequently be passed to the network to perform the access. 101 Some networks use a single identifier domain to identity all parties 102 and services. Other networks use a collection of discrete identifier 103 domains, where each identifier domain has a specific realm of 104 discourse or application. The Internet is an example of a 105 multiple-identifier domain network, where there are a number of 106 identity domains, each referring to a particular function or area of 107 application. In terms of routing and forwarding IP packets the 108 identity domain used is that of IP addresses, while in terms of 109 identifying particular services or resources the URI form of identity 110 is commonly used. In terms of human use of identities, the most 111 common form of identity in the Internet is based upon the domain 112 name. 114 This memo examines the role of identities and identifiers, together 115 with an overview of the various realms of identity that are used in 116 the Internet. The document then looks in more detail at the Domain 117 Name System (DNS) and examines its role in relation to these identity 118 realms. 120 One of the characteristics of the Internet's multiple identifier 121 systems is their heavy interdependence. This memo notes those 122 interrelationships and provides some observations on implications for 123 technical or operational evolution of their specifications. 125 1.1 Desirable properties of Internet Identities 127 Before exploring the set of Internet-based identity realms, its 128 useful to enumerate a set of desirable characteristics of any useful 129 identity system. The following list is of characteristics and some 130 related questions related to properties of the identifier is proposed 131 as a useful, although not comprehensive, collection of identity 132 attributes: 134 Uniqueness: 136 In what realm is the identifier unique? 138 Can the same identifier be associated with two or more distinct 139 objects within the domain of a single realm? 141 Can multiple identifiers in a single realm be associated with the 142 same object? 144 An identifier can only be used reliably and deterministically 145 when there is a unique association with an object. An identity 146 realm is generally useful when the association between 147 identities and objects is a relationship where each unique 148 identifier references a single unique object. Note that there 149 is no requirement in the reverse direction, in that it 150 typically makes little difference to the utility of an identity 151 realm if a unique object is associated with multiple 152 identities. In other words it can lead to ambiguities in 153 identity resolution if an identity is associated with two or 154 more distinct objects, but it generally is not as critical if 155 an object is associated with multiple identities (i.e. 156 multiple identity aliases for a unique object). 158 Consistency: 160 Is the identity asserted within a consistent identifier space? 162 This avoids an assertion of identity being interpreted by 163 another party in an unintended manner. 165 Persistence: 167 Does the identity remain constant, or are gratuitous changes in 168 the mapping from the identifier to the referenced object avoided? 170 Constantly changing identities are, at the very least, 171 difficult to track. 173 Trust: 175 Can a particular identity withstand a challenge as to its 176 validity? 178 Other parties who would like to use this identity would like to 179 be reassured that they are not being deceived. 'Use' in this 180 context is a generic term that includes actions such as 181 resolution to the object identified by the identity value, 182 storage of the identity value for subsequent 'use', referral, 183 where the token is passed to another party for their 'use'. 185 Robustness: 187 Is the identity realm capable of withstanding deliberate or 188 unintentional attempts to corrupt it in various ways? 189 A robust identity system should be able to withstand efforts to 190 undertake identity theft or identity fraud. 192 Withholding: 194 If the identity is composed of a number of components, are only 195 those components of the identity that are essential to support the 196 communication exposed to other parties? 197 Compound identity systems should not reveal those components of 198 the identity structure that are not relevant to the identity 199 operation being performed. 201 Referential Consistency: 203 If the identity is used in the context of a reference, then when 204 the referenced object is altered or relocated, does the identifier 205 remain a valid reference to the object? 206 Referential consistency refers not only to the constancy of the 207 reference in the face of changes to the referenced object, but 208 also consistemncy when one entity passed the identity value to 209 another. The identity resolution should remain constant in 210 such cases. 212 Structure: 214 Is the token space from which identity values are drawn structured 215 or unstructured? 217 Structured token spaces allow various forms of retrieval 218 operations based on the identity value to be undertaken 219 efficiently, while unstructured token spaces allow for more 220 flexible generation and use of identities within more 221 restrictive realms of discourse. 223 This list is not attempting to be a complete enumeration of required 224 identifier properties, but instead list the most important desireable 225 properties of identifier realms in the context of the Internet. 227 2. A Hierarchy of Identities 229 In networking models there is a conceptual layering of functionality, 230 starting at the layer of bits on the wire at the media access level 231 and moving up a stack of layers through internetworking, end-to-end 232 transport and application levels. Each one of these layers creates 233 at least one context in which identifiers are used for the 234 communication. It would appear that from this perspective an 235 identity within the Internet is not just a single identity, but an 236 collection of various identities, used in a variety of contexts. 238 2.1 Media Access Addresses 240 There are two generic types of base media in this realm. One is a 241 point-to-point medium, a bilateral communications system where all 242 Protocol Data Units (PDUs) generated by one party are passed to the 243 other party. In such environments use of media access addresses are 244 not strictly required. The other form of environment is a 245 multi-access environment, where a number of parties can communicate 246 directly using a common medium. In this environment the sender must 247 specify the intended recipient of the PDU, and to achieve this all 248 connected entities must use a unique media access address. The most 249 common of these multi-access media are encompassed within the IEEE 250 802 collection of media standards. 252 These IEEE 802 technologies share a common structure of Media Access 253 Control layer address (MAC address) to uniquely identity devices 254 connected within a LAN. There are two forms of this identity space, 255 one using a 48 bit identity space (EUI-48 [21]), and the other a 64 256 bit space (EUI-64 [22]). Both identity spaces can be considered as 257 partially-structured identity spaces, where a number of bits within 258 this MAC address determines whether the address has been globally or 259 locally assigned. Globally assigned values are globally unique, but 260 are structured in such a way that there is no imposed hierarchy 261 within the address that could be used for efficient searching, in 262 contexts such as, for example, a routing or forwarding application. 264 A global MAC address identity certainly passes one of the more basic 265 tests of an identity domain, that of uniqueness. Two parties cannot 266 assume the same MAC address value and use this same value as a unique 267 identity. So in a LAN context, a collection of devices can 268 distinguish between each other by virtue of this unique MAC address. 269 A manufacturer of Ethernet devices is assigned a manufacturer's block 270 of Ethernet MAC addresses and uniquely places one address in each 271 device. The end consumer has no need to reconfigure the device with 272 a new address, nor is there any need to alter existing MAC addresses 273 each time the LAN changes with new devices being added, and the 274 address is intended to be globally unique. 276 Beyond these attributes there are some real weaknesses in using a MAC 277 address as an identity outside the context of a LAN environment. The 278 identity space, while globally unique, has few other distinguishing 279 properties. The structure of the identity space does not reflect its 280 current location within a particular network topology, so its of no 281 assistance as a location token. In the context of equating a device 282 identity to this network interface identity, the identity has limited 283 persistence, in that it follows the interface hardware, not the host 284 computer or its use. For example, switching a device from a wireless 285 to a wired connection changes its MAC identity. The identity has no 286 capability to express any linkage to any other identity domain. It 287 has no internal structure of sub-fields that could be interpreted as 288 pointers into other identity fields. Its precise semantics are to 289 define an interface to a network rather than the device itself. This 290 issue of identifier scope comes up in link layer security discussions 291 where it may not be the best possible approach to bind master session 292 keys to MAC addresses, rather than some other identity. Another 293 example, in IEEE 802.11i it is possible for a host to have multiple 294 interfaces and therefore there is a significant difference between 295 binding an Master Session Key to a MAC address and binding to a host 296 identity. 298 This lack of a direct association between an interface's MAC address 299 and a host device has undesirable effects when it has been assumed 300 that a MAC address equates to a host identity. In "Authentication 301 for DHCP Messages " [13] where the MAC address takes on the role of 302 the DHCP client-identifier, or in the administrative model of IEEE 303 802.11-1999 Wired Equivalent Privacy (WEP) [23] it can be an 304 administrative burden to keep track of all the network interface 305 cards, their MAC addresses and their associated secrets. 307 Even despite these limitations, the MAC address is regarded as a 308 useful identity mechanism in the context of an identity space. The 309 original 48 bit identity specification has been augmented with 16 310 padding bits in order to be incorporated into the IEEE 64-bit EUI-64 311 global identifier structure, which in turn has been incorporated into 312 the IPv6 address architecture as the interface identifier component 313 of the unicast address [9]. 315 It should be noted that this latter action of embedding one identity 316 (a MAC address) in another (the IPv6 address) lifts the original 317 identity outside its original context. There have been some concerns 318 noted where public disclosure of the MAC address within every IPv6 319 address also discloses both the unique identifier and, potentially, 320 the role of the device. For example, a device manufactured by a 321 specialized storage manufacturer is more likely to be a very 322 expensive storage subsystem housing mission-critical data. This may 323 not be information that is intended to be made public, and a 324 follow-up proposal advocated the ability for the interface identifier 325 within an IPv6 address to be a temporary randomized value [12]. This 326 is illustrative of one of the side-effects of identity 327 interdependence where one identity realm is embedded in another. 329 2.1.1 Summary 331 Uniqueness: 332 MAC addresses are globally unique 334 Consistency: 335 Mac addresses are intended to be a unique token for a network 336 interface. Within this limited scope they are consistent. 338 Persistence: 339 MAC addresses are associated with an interface, in the hardware, 340 and, as such, are persistent. There are uses of MAC addresses 341 that do not assume permanence, but that has more to do with the 342 impermanence of binding that address to some other identifier 343 (e.g., IP address) than anything else. 345 Trust, Robustness: 346 Both Trust and Robustness seem to be tied to the use of the MAC 347 address, as there is no Internet infrastructure for assigning or 348 reporting them. This raises the question of whether the process 349 that asserts the MAC address of a hardware element and the 350 transmission of that assertion is trustable, and whether the the 351 manufacturing process that embeds MAC addresses into hardware is 352 always reliable. 354 Withholding: 355 MAC addresses are not decomposed, and are completely exposed. 357 Referential Consistency: 358 The MAC address refers to an interface, rather than a device or an 359 endpoint of an application. If the hardware component is moved 360 then the the MAC address is still a valid identifier for the 361 interface. However, from the perspective of dependent identifier 362 systems, there may be some consistency issues, in that another 363 system may no longer be able to see the interface identified by 364 the MAC address. 366 Structure: 367 MAC addresses are unstructured. 369 2.2 IP Addresses 371 Moving up one level in the protocol stack model provides an identity 372 based on the internetworking layer, namely the IP address. The IPv4 373 address is a 32 bit field providing each Internet-connected interface 374 with a unique value. IPv6 uses effectively the same construct, using 375 a 128 bit identity domain rather than a 32 bit domain. In both cases 376 the IP address is a structured identity space where there is a 377 globally significant prefix that is used in the context of routing 378 and forwarding outside of a particular local domain, and a local part 379 that is used to deliver the packet to the correct interface of the 380 associated device within the local network. The fact that the 381 structure of the address is based on the requirements of routing, and 382 is therefore topologically sensitive, implies that the underlying 383 semantics of the IP identity can be most reasonably assumed to be 384 temporal rather than persistent. 386 As an identity token, an IP address should be unique. It is 387 structured to be useful to forward packets to the addressed device, 388 and it's well known, in that it's not a secret value. 390 An IP address is not everything one could hope for in an identity. 391 The IP address identifies an interface, not a device or its user. A 392 device with multiple active interfaces has multiple IP addresses, and 393 while it's obvious to the device itself that it has multiple 394 identities, no remote party can tell that the multiple identities are 395 in fact pseudonyms, and that the multiple addresses simply reflect 396 the potential for multiple paths to reach the same endpoint. 398 Furthermore, the IP address is an information-bearing identifier, 399 which is structured in such a way that it can be used in routing and 400 forwarding. This is helpful in the sense that there is no need to 401 deploy a second identity system that refers only to locality within a 402 network, however it compromises the use of the address as an 403 identity, since in some circumstances a change in the connectivity of 404 a local network will require a renumbering of that network, such that 405 the address of each individual device will change. 407 This is a specific example of the more generic observation about IP 408 addresses, namely that the IP address carries both the identity of 409 the endpoint in the IP realm and the location of the endpoint in the 410 IP network. It is a matter of longstanding study that continues 411 today as to the merits of delineating these two roles of identity at 412 the IP level, creating one identity realm as a means of uniquely 413 identifying an instance of a protocol stack within an end device 414 (variously called a " stack identifier" or "endpoint identifier" in 415 previous studies) and a second identity realm that is used to 416 identify the current location of the identity element within the 417 network (typically called a "locator" identity) [1][25][5]. 419 2.2.1 Summary 421 Uniqueness: 422 With the exception of certain identified special cases, such as 423 private addresses [4], IP unicast addresses are globally unique. 424 In the context of anycast use of IP addresses, an IP anycast 425 address represents a collection of individual entities that 426 undertake an equivalent function. In the context of multicast IP 427 addresses, an IP multicast address represents a set of many 428 independent hosts. 430 Consistency: 431 Mostly consistent; private addresses are known by convention, not 432 by any internal identifier structure. 434 Persistence: 435 IP addresses are intended to be persistent. Becuase of the 436 duality of the address as representing both identity and location, 437 a change in location, such as in a mobile device, often triggers a 438 change in IP address. 440 Trust: 441 There is no systematic method of validating an assertion of an IP 442 address. 444 Robustness: 445 Attempting to hijack an IP address also requires some form of 446 corruption of the routing system on order for other system to be 447 informed of the updated location of the corrupted address. 449 Withholding: 450 IP addresses cannot be decomposed, and are completely exposed. 452 Referential Consistency: 453 It is normally the case that IP addresses are referentially 454 consistent, and one party can pass a reference to a correspondant 455 party to any other party by means of passing the IP address. One 456 caveat is that where the IP address is deliberately corrupted, by 457 viture of the use of a NAT device, or in the case of dynamically 458 addigned addresses, then IP addresses lose their referential 459 consistency. As noted above, anycast addresses may not preserve 460 precise referential integrity. 462 Structure: 463 The structure of an IP address refers to a structure of topology 464 in a locational context. In order to provide effective 465 summarization tools in the context of routing, the IP address is 466 structured such that adjacent devices use adjacent address, such 467 that a common address prefix can be used to summarize the location 468 of a local network of addressed devices. 470 2.3 Service and Session Identities 472 In the TCP/IP protocol suite the next level of identity is that of 473 the transport session. In order for a system to advertise a 474 particular service that is a point of attachment for clients it 475 combines three fields: IP server address, transport protocol 476 identity, and the address of the local service identity (port number) 477 into a compound identity that describes a particular service port on 478 a particular device. 480 The port address concept, used in TCP and UDP, represent generic 481 identities for service rendezvous points. When combined with an IP 482 address they become particular service points, or, identified service 483 points, and these compound identification objects (IP address, 484 Transport Protocol, Port) are service identifiers. 486 The identity concept for transport is further extended by including 487 the sender's IP address and port address. The corresponding 5-tuple 488 of (Source IP address, Destination IP address, Transport Protocol, 489 Source Port, Destination Port) is an identifier for a particular 490 instance of a session. Not only is this 5-tuple used at the 491 destination point to correctly de-multiplex an incoming packet stream 492 and send each packet to the correct local instance of the 493 application, the session identity can also be used within the network 494 to recognize a 'flow' of packets that require identical forwarding 495 treatment and may require identical service treatment, if so 496 configured. In the latter case the session identity is being used to 497 trigger a particular service response within the network, and the 498 assumption being made within such contexts is that this 5-tuple is 499 sufficiently unique to identify particular sessions to the relevant 500 network elements. (SCTP also has a port address, but uses a set of 501 IP addresses to identify the remote end. At the network level a 502 'flow' or 'stream' is identified as a collection of 5-tuples, rather 503 than as a single 5-tuple.) 505 There are circumstances where the complete 5-tuple is not visible to 506 the network, such as in the use of IPSEC [8]. It is an objective 507 when using the Encapsulating Security Payload (ESP) protocol when 508 confidentiality is enabled to hide session information. The 509 objective of the deliberate attempt to occlude these details is in 510 order to impede traffic analysis or greatly reduce the information 511 obtainable via traffic analysis. When using IPSEC with ESP the user 512 has choices about how ESP is deployed. One choice is to use a 513 separate Security Association for each flow, while another choice is 514 to use a single Security Association for multiple flows to hide that 515 flow information. It is not uncommon to use multiple already 516 encrypted flows and re-encrypt them together using a common Security 517 Association. This technique is very effective in impeding or 518 preventing traffic analysis. The triple (source IP, dest IP, 519 Security Parameter Index (SPI)) will identify the full flow 520 granularity that the user intended to reveal. Of course, the SPI 521 value will change at key rollover time, but usually the packet 522 patterns (size, frequency of transmission, etc) will reveal which new 523 SPI value corresponds with which previous SPI value. So if an entity 524 is trying to identify flows, it is best to use that natural triple in 525 the case of IPSEC with ESP. 527 Session identities are intended to be unique at any single point in 528 time, in that two distinct sessions will not share a common session 529 identity. However, this identity is temporal, in that once the 530 session is finished the identifier is no longer of direct relevance, 531 and at a subsequent time a different session may use the same 532 5-tuple. As well as impermanence, session level identifiers exhibit 533 a very fine level of granularity, and as such are often at a level of 534 detail which is too fine to be a useful general identity token across 535 the entire Internet realm. One use is to allow a session to 536 construct an identity that refers to itself or its correspondent that 537 can then be handed into a quality of service policy controller to 538 request a specialized service response for the session. Other uses 539 of session identities can be found in filters, firewalls and network 540 address translators, as well as various forms of middleware 541 applications. 543 2.3.1 Summary 545 Uniqueness: 546 A session identity is unique in a very limited context, such that 547 the session identity is only unique between the communicating 548 endpoints, and only unique for the lifetime of the session. 550 Consistency: 551 A session identity is intended to be consistent within the scope 552 of the IP-level multiplexing and demultiplexing function performed 553 in the endpoints of the session. Some forms of active middleware 554 attempt to use this session level identity as a means of session 555 identification. This use out of intended context is not always 556 reliable. 558 Persistence: 559 Session identities are not persistent 561 Trust: 562 Session identities are not necessarily trustable. Additional 563 mechanisms would be required to improve the trust attributes of 564 session identities. 566 Robustness: 567 Session identities are not robust, and some other form of session 568 context is required to minimize the risk of session hijacking. 570 Withholding: 571 Session identities are an instance of withholding, in that an end 572 point session state includes a number of additional information 573 items relating to packet sequence numbers and endpoint protocol 574 state. These items are withheld from the explicit protocol 575 exchange and are inferred at each end from the protocol exchange. 577 Referential Consistency: 578 Session identities are not referentially consistent. 580 Structure: 581 Session identities have a number of components, but each component 582 is is not internally structured. 584 2.4 Routing and Forwarding Identities 586 As mentioned above, IP addresses provide information required by 587 routing and forwarding systems. Forwarding is undertaken using the 588 entire address as the lookup function into a forwarding table, using 589 the best match of the address against a table entry as the basis of 590 the forwarding decision (where 'best' refers to a precise match 591 across the longest sequence of leading bits). Routing within the 592 Internet uses a hierarchy of environments, ranging from a non-routed 593 multi-access local network, through a set of locally routed networks 594 where routing is based on comprehensive knowledge of local network 595 topology, through to the interdomain routing environment, where 596 routing is based on a sequence of edge-to-edge transits across 597 domains. 599 This hierarchy of routing is reflected in the structure of addresses. 600 At any point in the routing hierarchy an address is divided into two 601 parts, a routing network part and a subnet address part. Early 602 definitions of this address structure used a fixed division, while 603 later refinements of classless IPv4 addresses and IPv6 both use an 604 explicit prefix length value that is combined with an IP address 605 prefix to form the routing identifier. 607 Interdomain IP routing incorporates both routing identifiers and 608 routing domains, or "autonomous systems". Within a given routing 609 domain, IP routing is performed using only routing identifiers. 610 However for routing between domains, IP routing is performed using a 611 new identity, the Autonomous System number. The most common 612 implementation of inter-domain routing is a distance vector 613 distributed computation of inter-domain topology using vectors of AS 614 numbers as both a loop detection and a path preference mechanism. 615 The AS identity space is an unstructured space of numeric values, 616 allocated from a single 16-bit identifier space. 618 An IP address is located within a routing system by identifying the 619 most specific enclosing routing identifier. Forwarding a packet to a 620 specific IP address involves an algorithm of locating the associated 621 routing identifier and undertaking the forwarding action associated 622 with that object. Coherency of the routing system demands that 623 routing identifiers are managed in a consistent fashion. The 624 overloading of an IP address as both an IP identity and a component 625 of a routing identifier implies that a device's location is 626 implicitly described by its IP address. As noted earlier, relocating 627 a device to a new network location, or relocating a network to a 628 different point in the overall Internet topology necessarily implies 629 associating a new IP address with the device. In the absence of any 630 other mechanisms, this new IP address replaces the previous IP 631 address, changing the device's IP identity, the device's service 632 identities and the device's session identities. 634 2.4.1 Summary 636 Uniqueness: 637 Routing identities are intended to be unique, deriving their 638 uniqueness from the underlying properties of the IP address space. 640 Consistency: 641 Routing identities are intended to be a unique token within the 642 context of a routing realm. 644 Persistence: 645 Routing identities are not persistent, and have a liketime 646 associated with connectivity of the described entity within the 647 routing realm. 649 Trust: 650 There is no systematic method of validating an assertion of a 651 routing identity. 653 Robustness: 654 The identity structure does not inherantly prevent various forms 655 of corruption of routing identities 657 Withholding: 658 An inter-domain routing identity is a compund entiy consisting of 659 an address prefix and an autonomous system number. There is no 660 withholding of elements of this identity. 662 Referential Consistency: 663 Routing identities are intended to be consistent within a routing 664 realm, and the operation of routing protocols rely on this 665 referential consistency of routing identities. 667 Structure: 668 Routing identities are not internally structured. 670 2.5 Mobile Identities 672 Device and network mobility adds an additional dimension to identity, 673 in that mobility implies some level of decoupling of the notion of 674 location with that of identity. In one form of approach to this 675 generic space, that of device mobility, a device has an additional IP 676 address that acts as a 'current locator' that describes the device's 677 current location within the network, while the device also retains a 678 constant 'home address' that in effect acts as the device's constant 679 identity and also acts as the discovery service point for its current 680 location. With this approach a 'home agent' acts as a proxy agent 681 for the device when it is roaming beyond the confines of its local 682 network. The home agent tunnels traffic sent to the home address to 683 an address at the host's current topological location, called the 684 'care of' address in Mobile IP. The host is responsible for updating 685 the binding between the home address and the care of address in the 686 home agent, by sending a binding update message when the care of 687 address changes. The mechanism involved in mapping between the home 688 address and care of address is very similar to the mechanism used on 689 the local link for the ARP neighbour cache, except IP addresses are 690 involved for both. 692 This approach raises a critical issue for identities, namely that of 693 robustness. Approaches to mobility need to be aware of a potentially 694 hostile environment where third parties may attempt to subvert the 695 implicit redirection of traffic by assuming the identity of the 696 mobile element through the generation of false updates of the current 697 location. 699 2.5.1 Summary 701 Uniqueness: 702 A mobile identity is a compound entity using two IP addresses: a 703 'home' address that functions as an endpoint identifier and a 704 'core of' address, which functions as a current endpoint location 705 identifier. A mobile identity is intended to be unique. 707 Consistency: 708 A mobile identity is consistent within the realm of mobile IP 709 protocols. 711 Persistence: 712 A mobile identity is not persistent,. The endpoint identity value 713 is intended to be persistent, while the endpoint location 714 identifier is only intended to be valid while the mobile entity is 715 located at the specified 'care of' location. 717 Trust: 718 Of itself a mobile identity is not trustable. Mobile IP protocols 719 add additional communication exchnages between the mobile entity 720 and 'agent' entities in order to create trust in a mobile 721 identity. 723 Robustness: 724 A mobile identity is not intrinsically robust. The protocol 725 exchanges between the mobile entity and its agents can create a 726 robust mobile identities. 728 Withholding: 729 Manipulation of mobile identities can include deliberate 730 withholding of the current location information, or the persistent 731 identity information. 733 Referential Consistency: 734 Becuase of the temporal nature of the location identifier, mobile 735 identities are not consistent over time. 737 Structure: 738 The structure of a mobile identity is derived fromt he structure 739 of the underlying IP address space. 741 2.6 Opportunistic Identities 743 This concept of maintaining some form of identity association in the 744 face of a communicating within a potentially hostile environment has 745 lead to a proposal for an identity token that has its roots in the 746 public / private key pairs. In this approach the identity token is 747 associated with the public key value of a public / private key pair. 748 A message encrypted with a private key can be passed to the other 749 party where only the originating party's publicly asserted identity 750 (or public key) can decrypt the message. 752 Such identity realms can serve to support a reliable assertion that 753 the received message originated from the same party that originated 754 the communication and that the message has not been tampered with 755 while in transit. The identity systems are opportunistic in that 756 they are self- generated identities, and have no external structure. 757 The implication is that such identities have no particular structure 758 and may not be completely unique. For this reason their utility in 759 other identity applications where persistence or referential 760 integrity is required, such as acting as a persistent reference to 761 other attributes of a named object, is limited. 763 2.6.1 Summary 765 Uniqueness: 766 Opportunistic identities are not unique. 768 Consistency: 769 Opportunistic identities may not be consistent. 771 Persistence: 772 Opportunistic identities are not necessarily persistent. 774 Trust: 775 Opportunistic identities are not trustable in general. There may 776 be limited contexts in which an opportunistic identity may be 777 considered trustable.. 779 Robustness: 780 Oppostunistic identities are normally robust in the sense that 781 they are not generally divulged, are generated in a manner that is 782 systematically predictable by a third party, and are often drawn 783 from a sufficient large space that they are resilient to guessing 784 techniques. In this sense an opportunistic identity can be 785 considered to be robust. 787 Withholding: 788 Opportunistic identities can be simple or compound tokens. 789 Withholding is possible in the case of compound identity realms. 791 Referential Consistency: 792 Opportunistic identities are normally bounded by a particular 793 context of use, and are not referentially consistent outside of 794 this context. 796 Structure: 797 Opportunistic identities may not necessarily be structured. 799 2.7 Domain Names 801 The set of identities described so far have no particular 802 human-visible aspects of their function. The identity tokens are 803 structured to meet a particular purpose, and are not intended, as 804 their primary purpose, to be manipulated by humans nor are they 805 intended to be used primarily within the realm of human discourse. 806 By contrast, the Domain Name System (DNS) was specifically intended 807 to be a name realm that is suitable to be included in human 808 discourse, yet at the same time to admit enough structure to be 809 manipulated by computer applications in a deterministic fashion. 811 The DNS is essentially a hierarchical name space, where the 812 hierarchical name structure allows the space to be efficiently 813 searched and managed in a distributed fashion, but also supports one 814 of the most desirable attributes for an identity space, namely 815 uniqueness. The explicit hierarchy also assists in ensuring 816 uniqueness, as DNS names are intended to be unique across the entire 817 name string rather than just at the first component, so that "a.b.c" 818 is a different identifier to "a.d.e " even though the first token in 819 the domain names, "a", is the same in both cases. 821 The most common use of the DNS is to map domain names to IP 822 addresses, but other uses are possible via mapping a name to a number 823 of other defined 'resources'. The core functionality of the DNS is 824 that of a unique, structured, name space and a mapping capability 825 that allows a query to be performed to retrieve the mapping 826 information for a DNS name for a particular class of resource 827 mapping. 829 The Domain Name System is more than a set of syntactic rules for 830 constructing a well-formed DNS name. The resultant name, if well 831 constructed and properly implemented, can be used as a referral token 832 to a service environment. In this fashion the DNS encompasses a 833 translation service that maps from domain names to defined resources, 834 including IP addresses. For example, given a well formed DNS name, a 835 DNS lookup can query for a corresponding IP address. The DNS 836 describes a data model, a set of relationships between data objects 837 as well as a protocol used to send queries and receive answers. 839 As DNS names provide a mapping from a name to a resource, the name 840 does not need to change when the resource changes location or some 841 other identifying attribute. The mapping changes, but the name 842 remains constant, and for this reason domain names can be considered 843 to be stable unique identifiers, residing within a structured space 844 that can be efficiently searched and managed in a highly distributed 845 manner. 847 2.7.1 Summary 848 Uniqueness: 849 DNS identifiers are unique. 851 Consistency: 852 DNS identifiers are intended to be consistent. There are a number 853 of issues relating to character equivalence within various 854 languages that impinge upon consistency of interpretation in some 855 contexts. 857 Persistence: 858 DNS identities are intended to be persistent. 860 Trust: 861 The trustability of a DNS identity is based on the integrity of 862 delegation within the hierarchy of the DNS identity. 864 Robustness: 865 The DNS is implemented as a distributed name database, and the 866 robustness of the DNS is based on the robustness of this database. 868 Withholding: 869 DNS identities are capable of wothholding. A DNS identity can be 870 regarded as a DNS name, and an associated set of resource records. 871 Resource record values are withheld unless explicitly requested as 872 part of a resolution query. 874 Referential Consistency: 875 DNS identities are intended to the referentially consistent. 877 Structure: 878 The DNS name space uses a hierarchical structure. 880 2.8 Uniform Resource Identifiers 882 When communicating, applications often need more information than a 883 domain name. For electronic mail, for example, the sending 884 application must use a combination of the domain name, the TCP 885 protocol, the mail delivery or mail agent's service port and the 886 mailbox name of the recipient. Other applications require different 887 compound identification objects, in accordance with their 888 characteristics. This compound identity may be specified in the 889 format of a Uniform Resource Locator, or URL. 891 Uniform Resource Locators (URLs) are a subset of a more generic form 892 of resource identification, Uniform Resource Identifiers (URIs). As 893 an identity space, the URI space is very loosely defined, and it's 894 quite remarkable as to the extent to which it has spread across the 895 world as a form of object identifier, or identity token. URLs refer 896 to the subset of URIs that identify resources via a representation of 897 their primary access mechanism. Other forms of URIs provide resource 898 identification through a name scheme or by other attributes of the 899 resource. 901 There are few syntax rules to the Universal Resource Identifier 902 space, and only a small amount of common semantic structure. The 903 original IETF documentation, RFC 1630 [2], refers quite simply to a 904 syntax of a prefix word, a colon, and a following string. Where 905 there is hierarchy in the following string, slashes are used to 906 delineate the hierarchical levels, and the hierarchy runs from left 907 to right. The current generic syntax of URIs is described in RFC 908 2396 [7], and the only change to this generic syntax is to refer to 909 'schemes', as in ":". 911 The common usage of URIs has been more structured than this general 912 specification, and most URI schemes do not provide a single string 913 that is an alias for an identity, but instead form an identity from 914 the instructions that specify how to access the resource, in the same 915 way as a postal address is often constructed from the instructions as 916 to how to deliver a postal letter to you. This form of a URI, which 917 can be viewed as a location specification, is the basis of the URL 918 scheme. In other words such protocol-scheme URLs consist of what 919 could be interpreted as a device selector, an application selector 920 and an application-specific string that acts as an object reference. 922 Within such protocol-scheme URLs the scheme prefix is an identifier 923 that uniquely identifies the service being referenced, or in terms of 924 access it references the protocol and port address to be used. The 925 first, or top, level of the hierarchical following string is either 926 the DNS name of the server, or the DNS name coupled with some 927 specific qualification, such as a mail address. Any subsequent 928 hierarchical components represent service-specific instructions to be 929 specified that lead you to the referenced object. Thus we have 930 "mailto:user@domain.example.com" for a mail specification, where the 931 scheme prefix "mailto" identifies the use of the TCP transport 932 protocol, a port address of 25 and a protocol of SMTP. The following 933 string, "user@domain.example.com" references the mail agent (a DNS 934 lookup of "domain.example.com" for an MX resource record) and a value 935 to be used in the protocol exchange (delivery to the mailbox 936 "user@domain. example.com"). Similarly, 937 "http://www.example.com/directory/hierarchy/index.html" for a 938 specific web page uses "http" as a scheme identifier for TCP, port 939 80, protocol HTTP, the initial part of the following string to 940 reference the server (a DNS lookup for an A or AAAA resource record 941 for "www.example.com") and an HTTP protocol request for 942 "www.example.com/directory/hierarchy/index.html". 944 In this form of the URL identity system uniqueness is keyed from the 945 general use of a DNS name within the URL, and the wrapping around the 946 DNS string is taking the general form of the DNS as an alias for an 947 IP address, and, additionally, specifying a service point, and then 948 arguments that are needed to provide to this service point in order 949 to retrieve the referenced resource. In that way a protocol-scheme 950 URL is closer to a description of an algorithm than to an identifier 951 whose structure of the identifier is adapted to tasks such as 952 sorting, searching or equivalence operations. There are issues with 953 consistency here in that while the hierarchically structured string 954 set makes sense to one application it may not make any sense in the 955 context of a different application. 957 The persistence of protocol-scheme URLs is also an issue, in that the 958 resource may change location over time, and the corresponding 959 algorithm to locate the resource, or URL, must necessarily change as 960 well. The other major difference between a structured identifier 961 space and the protocol-scheme URL approach is that the structured 962 identifier space requires some form of lookup to apply the identity 963 into a retrieval system. By changing the outcomes from the lookup 964 operation, the identity owner can track changes in the location of 965 the resource. In the protocol-scheme URL approach there is no way to 966 understand how widely the identity has circulated, and it is not 967 possible to update the in-circulation copies of the URL. The 968 property of the DNS is that in itself, the DNS identities are simple 969 structured tokens, and they require a lookup operation to be 970 performed in order to produce an algorithm that allows an application 971 to refer to a particular object. While such protocol-scheme URLs are 972 widely used as service and resource identities, they pale in 973 significance, persistence and utility when compared with DNS names. 974 In other words URLs specify "how" to access a service, while generic 975 DNS names can be interpreted as identity tokens that can be used to 976 identify a resource that may host a service (or "who"). 978 It is also not surprising from this perspective to see the emergence 979 of DNS resource records that refer to URLs, as in NAPTR records [10]. 980 In this approach the first DNS lookup retrieves one or more URLs that 981 have been associated with the DNS name, and a second lookup is used 982 to resolve any DNS names as may be referenced in the URL strings. In 983 this framework a service may change its location, or the access 984 algorithm may be altered (and by necessity, the URL changed), but the 985 DNS identity that maps to this URL remains constant. This is one of 986 the clearer forms of delineating identity from access mechanisms. 988 This mapping can also be used for service discovery. Given the name 989 of a domain it is possible to look up NAPTR records to discover what 990 URLs can be used for communication with that domain. This is for 991 example used in the ENUM specification [11]. In ENUM a lookup in DNS 992 of NAPTR records for a domain name created from an E.164 number is 993 via transformation turned into a list of URLs. This give an ability 994 to know what URLs one can use in order to contact the entity referred 995 to by a given E.164 number. The more general form of this approach 996 can use NAPTR resource records to associate a DNS name with one or 997 more resources. The name that has the NAPTR records can be 998 considered as an identity token, while the associated NAPTR records 999 provide a mapping from this identity to the instantiation of the 1000 identified service. This approach has been used in the Archive 1001 Resource Key (ARK) proposal [26]. 1003 Of course not all URIs are protocol-scheme URLs of the form outlined 1004 above. URIs are a very general construct where the initial "scheme" 1005 part of the URI determines the structure and semantics of the 1006 remainder of the URI string. The next section examines that class of 1007 URIs where persistence of the identity is a specific feature of the 1008 identity realm, the Uniform Resource Name. 1010 2.8.1 Summary for URLs 1012 This summary section explicity refers to URLs rather than URIs. The 1013 more general case of URIs is one that, in the general case, is 1014 unclear on all these desireable identity attributes. 1016 Uniqueness: 1017 URLs are intended to be unique. 1019 Consistency: 1020 URLs are not necessarily consistent. A URL typically includes the 1021 specification of an application, an enpoint and some additional 1022 arguments for the application to apply to the application instance 1023 on the nominated endpoint. Inconsistent interpretation of URL 1024 components by other applications is possible. 1026 Persistence: 1027 URLs are not necessarily persistent, as they implicitly identify 1028 how to access a resource or service, rather than identifying the 1029 resource or service per se. If the service or resource changes 1030 location, a new URL is required to reference the new location. 1031 In the case where URIs use a DNS identifier as part of the URI 1032 scheme, as in URLs, for example, such URIs also depend on the 1033 persistence of the underlying DNS identity for persistence of the 1034 URL. 1036 Trust: 1037 URLs are not necessarily trustable. 1039 Robustness: 1040 URLs are not necessarily robust. 1042 Withholding: 1043 URLs are not capable of withholding elements of the URL identity. 1045 Referential Consistency: 1046 URLs are intended to be referentially consistent, but are limited 1047 in terms of their persistence. 1049 Structure: 1050 URLs are a structured identity space. 1052 2.9 Uniform Resource Names 1054 To solve the problem of lack of long term stability for references, 1055 URNs can be used as an alternative to recursive references into the 1056 DNS. URNs are generally considered not to be entirely within a human 1057 realm as they often include what would appear to be long random 1058 combination of characters. URNs are intended to be globally unique, 1059 and never reused. As long as a named object exists, it retains that 1060 name. An object can have many names. The object may cease to exist, 1061 in which case the URN can no longer be resolved, because the 1062 resolution service (from URN to URI) is no longer working, but, as 1063 the name exists (virtually), a new service can be created and the 1064 object re-established if there is need for it. RFC 3305 [14] 1065 describes in more detail the different views that exist on the 1066 relationship between URIs, URLs and URNs. 1068 2.9.1 Summary 1070 Uniqueness: 1071 URNs are intended to be unique. 1073 Consistency: 1074 URNs are indended to be consistent. 1076 Persistence: 1077 URNs are intended to be persistent. 1079 Trust: 1080 It is unclear how trust relationships are formed with URNs. 1082 Robustness: 1083 As with trust relationships, the robustness properties of URNs are 1084 unclear. 1086 Withholding: 1087 It is unlikely that URNs can withold parts of the URN. 1089 Referential Consistency: 1090 URNs are intended to be referentially consistent. 1092 Structure: 1093 URNs included unstructured components. 1095 2.10 Human Friendly Strings 1097 URIs have a problem that URNs didn't solve, and that is the ability 1098 for humans to remember them. Humans act in a context, so global 1099 uniqueness is not important at this level of abstraction. Instead, 1100 when a human uses a name, they normally want a resolution service 1101 that "does what they want". In this realm the context of the name is 1102 an important factor in resolving the name to an object, and global 1103 uniqueness is neither necessary nor assumed. 1105 This area of human friendly strings is a topic of ongoing work. One 1106 possible goal for a working system is to be able to handle the 1107 so-called "side of the bus" problem. A human sees something in an 1108 advertisement on the side of a bus, remembers it (or remembers part 1109 of it), and when they come to a computer they try to get more 1110 information about what they have seen. This involves complex 1111 language and localization (and internationalization) problems. 1113 There has been various ideas connected to "layers above DNS", for 1114 example mentioned in RFC 3467 [19] (subject of the SIREN Research 1115 Group in the IRTF). This topic encompasses an effort to decouple the 1116 naming realms that makes sense to humans, with their various forms of 1117 implied context for resolution, from the naming realms that work for 1118 computers, with the implication of explicit specification of 1119 resolution, and define a mapping between them. The DNS can't handle 1120 the types of names that often make sense to people, because people 1121 always work in a context (such as a geographical context of 1122 'locality'), and it's no longer sufficient for people to fit their 1123 needs into what DNS can handle. For a some time it was considered 1124 possible to overload the semantics of the DNS label 1125 (machine-parseable, vaguely human-recognizable) but it is becoming 1126 evident that this is not a tenable approach, and some distinction 1127 needs to be drawn between DNS names and context-sensitive 1128 human-friendly strings. 1130 No real human friendly naming system exists today on the Internet. 1132 2.10.1 Summary 1134 Uniqueness: 1135 HFS are intended to be unique within a context of discourse. 1137 Consistency: 1138 Unclear. 1140 Persistence: 1141 Unclear, although it would appear to be a desireable attribute in 1142 this context. 1144 Trust: 1145 Unclear. 1147 Robustness: 1148 Unclear. 1150 Withholding: 1151 Unclear. 1153 Referential Consistency: 1154 Desireable. 1156 Structure: 1157 Unclear. 1159 3. Issues with Identities 1161 3.1 Overloading the IP Address 1163 An IP address suffers from semantic overload in attempting to carry 1164 both location and some form of constant identity. If a network or 1165 individual device changes access providers then this is, in effect, a 1166 change in network location, and if provider-based address aggregation 1167 is being used, then the local IP address will change. The same issue 1168 applies with mobile devices. This implies that an IP address is not 1169 necessarily a permanent or truly persistent association with a 1170 device, and such impermanence is a weakness in any persistent 1171 identity system. 1173 Another issue with IP addresses, at least in version 4 of the 1174 protocol, is that of their total span. While 32 bits is still a 1175 large size, encompassing some 4.4 billion unique addresses, there is 1176 an inevitable level of wastage in deployment, and a completely 1177 exhausted 32 bit address space may only encompass a connectivity 1178 realm of perhaps only 1 or 2 billion IP devices. When this is 1179 coupled with a world of embedded IP devices in all kinds of 1180 industrial and consumer applications, 1 or 2 billion addresses is 1181 insufficient to provide unique addressing to every possible device. 1183 In response to these address pressures there has been the 1184 introduction of a number of technologies that dilute the strong 1185 binding of IP address with identity. Such approaches tend to treat 1186 the IP address purely as a routing and forwarding token without any 1187 of the other attributes of identity, including persistence and public 1188 association. For example, DHCP, or address-lending, is a commonly 1189 used method of extending a fixed pool of IP addresses over a domain 1190 where not every device is connected to the network at any given time, 1191 or when devices enter and leave a local network over time and need 1192 addresses only for the time they are within the local network's 1193 domain. In this form of identity, the association of the device with 1194 a particular IP address is temporary, and hence there is some 1195 weakening of the identity concept, as the dynamically-assigned IP 1196 address is being used primarily for routing and forwarding. This has 1197 been taken a further step with the use of dynamic Network Address 1198 Translation (NAT) approaches, where a single device has a pool of 1199 public addresses to use, and maps a privately used address to one of 1200 its public addresses when the private device initiates a session with 1201 a remote public device. The private-side device has no direct 1202 knowledge of the public address that the NAT edge will use for the 1203 session, nor does the corresponding public-side device necessarily 1204 know that it is using a temporary identity association to address the 1205 private device. 1207 These forms of changes to the original semantics of an IP address are 1208 significant architectural changes to the concept of identity at the 1209 level of IP, particularly in the presence of NATs. The widespread 1210 deployment of such approaches continues to underline the concept that 1211 as an identity token there is a lack of persistence in an IP address, 1212 and the various forms of aliasing weaken its utility as an identity 1213 system. The conclusion drawn from these observations is that, 1214 increasingly, an IP address, in the world of the IPv4 Internet, is 1215 being seen primarily as a locality token with a very weak association 1216 with some form of identity. 1218 Version 6 of IP represents an effort to restructure the address 1219 field, and the 128 bits of address space represents a very large 1220 space in which to attempt to place structure. One of the more 1221 innovative concepts that was discussed within the development of IPv6 1222 was extending the concept of the IPv6 interface identifier field of 1223 the address to be a globally unique identifier. This had some 1224 obvious connotations in being able to identify when the connectivity 1225 for a device has changed, as in such cases the globally unique 1226 interface identifier could remain constant while the routing prefix 1227 may have changed. There was also some potential applications in the 1228 area of supporting multi-homed networks, where a local network could 1229 be seen via different routing prefixes. At present these aspects of 1230 IPv6 address architecture are the topic of ongoing work in the IETF. 1231 One of the fundamental issues with this form of approach is 1232 management of an interface identifier space that is globally unique 1233 and persistent, as well as being adequately robust. Current 1234 directions of activity in this area indicate that the self-assertion 1235 of identity using this field within IPv6 are insufficiently robust to 1236 prevent various forms of redirection attacks. Approaches currently 1237 being investigated are looking deeper into various aspects of 1238 mechanisms that are intended to provide corroboration of identity 1239 assertion in the face of locator change and additional protocol 1240 mechanisms appear to be a common feature of the current proposals 1241 relating to multi-homing and aspects of mobility. 1243 3.2 Dynamic DNS Updates and Nomadism 1245 An alternative mechanism to revising the semantics of the IP address 1246 is looking at the concept of moving the role of completing the 1247 transition of persistent identity into the DNS. Here the constant 1248 identity of the device is its DNS name. In a mobile context, as the 1249 device or network it roams across the network, and by using a 1250 sequence of secure dynamic incremental updates to the DNS, update the 1251 association of the constant DNS name to the new local IP address. 1252 This approach has possible applications in various multi-homing 1253 scenarios. 1255 However, this approach is not without attendant considerations. Much 1256 of the leverage of the DNS as an efficient lookup mechanism is based 1257 on extensive use of local caching of DNS information. Increasing the 1258 responsiveness of the DNS to dynamic updates implies that the extent 1259 to which cached information can be retained is compromised, and any 1260 cache has to refer more frequently to the primary source to refresh 1261 the currency of the local cached copy. The tradeoff here is greater 1262 DNS traffic loads and increased DNS server query loads in order to 1263 get a more responsive name system. Such a mechanism also requires an 1264 "always available" primary DNS server to accept the incremental 1265 updates, so that the failure backup mechanism of the DNS with primary 1266 and secondary servers is compromised in this nomadic model with the 1267 requirement for primary server availability in order to undertake an 1268 authoritative update to the DNS. 1270 An alternative approach is to equip the DNS with an additional 1271 resource record that contains an identity value in addition to the 1272 current A or AAAA address values. This approach can be used in 1273 conjunction with an additional element within the protocol stack that 1274 could allow the transport layer to operate using this identity field, 1275 and a new stack element provides a dynamic mapping between this 1276 identity and a 'current' locator value, where the equivalent current 1277 locator is passed into the IP protocol element. 1279 An alternative to this approach of changing mappings is to place the 1280 responsibility for the redirection into the application protocol. 1281 For example, with SIP, the mobile node could use the REGISTER method 1282 to change its registration for session setup. This may not be fast, 1283 but may be faster than dynamic DNS updates and perhaps even fast 1284 enough for handling initiating new sessions. A mobile HTTP server, 1285 on the other hand, would have to use HTTP Redirect from a fixed 1286 server whose address was in the DNS. 1288 3.3 URLs and Persistent Identifiers 1290 URLs are, as their name suggests, locators rather than location 1291 independent identifiers. When the resource is relocated, or when 1292 multiple copies of the same resource exist, the URL scheme cannot 1293 persist across the change. Despite the almost universal use of the 1294 URL within web browsers, URLs are not an ideal candidate for a 1295 persistent identity. 1297 This weakness in the URL scheme has lead to the consideration of many 1298 alternate naming schemes, although the underlying requirements for 1299 any candidate naming scheme is that it is cleanly mappable into a 1300 URI-styled format and that there is a robust resolution system 1301 associated with the name scheme. Resolution is a critical factor 1302 here, as without the ability operate in a predictable, robust, 1303 scalable, trustable and reliable manner when translating an 1304 identifier into a resource, entity or service access description, the 1305 identifier scheme is of dubious value. 1307 The requirement for persistent identifiers is not intended to 1308 dispense with URLs, or similar forms of locators and service 1309 descriptors, but to separate the notions of identification and 1310 location, and to use distinct label space for each concept, and to 1311 use a resolution mechanism to map from the identifier to the location 1312 descriptor. 1314 Work on the development of a unique permanent identifier space has 1315 proceeded concurrently with the formalization of URL schemes, using 1316 the name of URN (Uniform Resource Name) schemes. A specification 1317 outlining the minimum requirements of the URN can be found at [3]. 1318 The syntax of the URN as expressed in [6] is as follows: 1320 urn:: 1321 The NID ensures the global uniqueness of the identifier. The NSS 1322 can take any form specified by the naming authority provided that 1323 it is unique within that namespace. 1325 The simple structure of the identifier reflects recognition of the 1326 need to accommodate different requirements and different schemes. 1327 Because the local, or namespace specific, string can be in any form, 1328 the identifier structure allows maximum flexibility in the identifier 1329 while providing a mechanism to assure global uniqueness and 1330 facilitating interoperability between discrete systems. 1332 There is a need to distinguish between naming schemes and resolution 1333 systems. A naming scheme, as a procedure for creating unique URNs 1334 that conform to a specific syntax, is independent of the resolution 1335 service which resolves the URN to locate the resource. Ideally, a 1336 naming scheme should not be tied to any specific resolution system 1337 and a resolution service should be capable of resolving a URN from 1338 any given name scheme. 1340 This objective is consistent with the intentions behind the 1341 development of the URN. A persistent identifier, especially when 1342 used for archival data must of necessity be capable of outlasting any 1343 systems and protocols that are currently in use. However the lack of 1344 a commonly agreed upon resolution system is also a major obstacle to 1345 the wide deployment of URNs. 1347 A variety of solutions have been proposed, including the NAPTR 1348 (Naming Authority PoinTeR) DNS resource record [10], that provides 1349 rules for mapping parts of URIs to domain names and then using these 1350 domain names as DNS lookup queries to find mapped URIs. This was 1351 specification has been further refined as the Dynamic Delegation 1352 Discovery System (DDDS) [15][16][17][18]. As noted in RFC3404 [18]: 1354 "For the short term, the Domain Name System (DNS) is the obvious 1355 candidate for the resolution framework, since it is widely 1356 deployed and understood. However, it is not appropriate to use 1357 DNS to maintain information on a per-resource basis. First of 1358 all, DNS was never intended to handle that many records. Second, 1359 the limited record size is inappropriate for catalogue 1360 information. Third, domain names are not appropriate as URNs. 1361 Therefore our approach is to use the DDDS to locate "resolvers" 1362 that can provide information on individual resources, potentially 1363 including the resource itself." 1365 There appears to be some residual issues over the status of URNs. 1366 For URNs to achieve widespread deployment, not only is consensus on 1367 functional requirements and syntax needed, but the ability to 1368 recognize and resolve URNs should be incorporated into the 1369 application realm. For example, it would be a reasonable objective 1370 to incorporate URN support in standard Web browsers. However a 1371 pre-requisite for this step is the definition and construction of the 1372 necessary resolving infrastructure, developed either by leveraging 1373 off the existing Domain Name System or by some other route. As long 1374 as application developers are uncertain of what is to be accepted as 1375 a standard resolution mechanism, and while naming scheme developers 1376 are uncertain of how to register their name and resolution schemes 1377 these issues will not be fully resolved. 1379 Until the resolution issues are clarified and there is clear 1380 consensus to adopt a particular specification, implementation of URN 1381 systems will require some form of application level assistance by way 1382 of proxy servers. The implication is that use of URNs will require 1383 encapsulation in a URL in order to specify the appropriate proxy 1384 server address. 1386 This approach has already been undertaken in the specification of 1387 PURLS [24], which is a naming scheme that incorporates within the 1388 PURL a conventional URL reference to a resolver to specify a PURL 1389 resolution service and a name part of the URL that the resolution 1390 service translates to the resource URL. In a web-based context this 1391 is handed back to the client as an HTTP redirect. The dependency of 1392 the identifier scheme on the behavior of a particular application 1393 (namely HTTP in this case) is not the most desireable of attributes 1394 for an identity scheme. If the PURL was to be used in a different 1395 context by a different application, a comparable redirection 1396 mechanism would be required to support the desired outcome. 1398 In comparison, the Handle system [20] uses a non-URL name scheme, and 1399 resolution in applications requires modification of the application. 1400 The 'handle' itself is a persistent identifier consisting of two 1401 parts. The syntax is a two part identifier of "/< 1402 name>" where the naming authority is an administrative unit 1403 authorized to create and maintain handles and the name of the 1404 resource is a string which must be unique to that authority but which 1405 has no prescribed syntax. Use of handles can be through standard web 1406 browsers using a plug-in, or through unmodified web clients using 1407 proxy servers and embedding the handle within a URL that specifies a 1408 handle resolver in a manner similar to the PURL approach. The 1409 specification of a distinct handle syntax allows handles to be used 1410 in a broader set of contexts than web browsing as there is 1411 independence of the identifier to a particular access protocol and 1412 server location. 1414 The issue of resolution of the compound identifiers remains 1415 problematic, and the use of embedding the URN into a proxy URL to 1416 undertake redirection can be argued as defeating the purpose of 1417 having location and protocol independent identifiers, since the 1418 resultant identifier includes the location of the proxy agent. The 1419 full value of persistent identifiers to ensure persistence in 1420 citations can only be realized if they are actually useful when 1421 citing documents and objects. In order to use them, the user must 1422 know that there is a persistent identifier and must be able to 1423 discover what it is and how to resolve the identity. At present this 1424 is difficult because of the nature of the redirects used in most 1425 existing systems. 1427 4. The DNS in Identity Spaces 1429 How good are any of these identities? Which one should be used in 1430 which context? 1432 Each of these digital identities have a context of usage, or realm of 1433 discourse, and outside of that realm they tend to break down as a 1434 cohesive and useful identity tool. Offering a MAC address as an 1435 email point of contact makes little sense, even though it could 1436 conceivably be used to form a unique identity in the mail realm. 1437 Offering an identification at the appropriate level of abstraction 1438 that provides a description of the mode of contact and identity in a 1439 form that matches the actions at this level is often used to 1440 distinguish between identities. At the level of human interaction we 1441 commonly identify email addresses using a domain and user name part. 1442 We do this because this is what you need to enter into your mail 1443 application in order to send me a message. 1445 There are considerations when generating identity spaces based on 1446 generic descriptions of algorithms of how to access the specific 1447 resource, trigger the particular application or contact a particular 1448 individual or role's network point of presence. These 1449 considerations, commonly found in conjunction with URI's, raise 1450 consideration of maintaining referential integrity, allowing 1451 efficient searching and persistence of the identity. The human 1452 world, and its digital counterpart, is far from static. Any identity 1453 system that aspires to be useful in a human space needs to be able to 1454 support a maintenance function that allows any implicit reference 1455 that is contained in an identity space to be updated and refreshed in 1456 a reliable, trustable and timely manner. Knowing who you were is a 1457 less important piece of information as compared to knowing who you 1458 are right now. That leads to consideration of structured identity 1459 spaces whose two major attributes are: 1460 o sufficient structure to ensure that specific instances of the 1461 identity are unique, and 1463 o appropriate structure to allow rapid lookup of the identity to be 1464 able to retrieve the current set of associated pointers within 1465 various specified realms. 1467 There is a good match between these desired attributes and those of 1468 the DNS, and one perspective to be drawn from this is that the major 1469 underpinning of useful and lasting digital identities rests within 1470 the framework of the DNS. In other words any useful identity space 1471 is highly likely to have managerial and operational characteristics 1472 that would largely parallel that of the DNS. 1474 4.1 The role of the DNS 1476 Different identities are used in the Internet for different purposes. 1477 IP addresses are essential at the level of forwarding protocol data 1478 units across the network, but are unwieldy to use in the context of 1479 naming resources and services at the level of human operation of 1480 applications. In the context of URIs, the use of a DNS identity 1481 within a URI ensures that the identity of a service doesn't have to 1482 be changed when the IP address changes. The domain name creates an 1483 abstraction layer above the IP addresses that allows a service to be 1484 identified without particular reference to its current location 1485 within the Internet, and using a name realm that has better 1486 properties for human use. 1488 We could use something else, like static tables, databases or more 1489 similar systems like X.500. But, none of these alternatives have 1490 been able to prove they scale as well as DNS. Both the protocol 1491 itself and the data model with the distributed delegation has proven 1492 to be extremely efficient (even though some things could be 1493 "better"). 1495 The perspective being espoused here is that we don't have any current 1496 viable alternative to the DNS in terms of a structured identity space 1497 that supports mapping across identity realms. Even if we stop using 1498 domain names in URI's and instead using something else, deploying a 1499 translation service from this other name to IP addresses would 1500 inevitably involve recreating much of the functionality of the DNS. 1502 4.2 Changing the DNS 1504 Because DNS is the service we use for mapping between many of the 1505 namespaces we use on the Internet, it is extremely important it 1506 works. Because of this, changes to DNS must be made with care. This 1507 refers to both changes to the protocol as well as the DNS data model. 1509 Example of changes to the protocol include the need for DNSSEC 1510 (signed record sets) which makes it possible for a recipient of a DNS 1511 response to verify whether it comes from an authoritative source. 1512 This has been discussed in the IETF for some years, and is 1513 illustrative of the required level of care in the design of changes 1514 to the DNS. 1516 Example of a change to the database structure include a move from an 1517 hierarchical to a flatter namespace. The result might be a 1518 disruptive change of DNS traffic on the global Internet which in turn 1519 might make further scaling difficult. Another similar change is 1520 allocation of names which are not registered properly. Especially in 1521 the root zone, this leads to problems such as the inability to later 1522 allocate and set a policy for the domain, and increased number of 1523 queries for non-existing names in the root zone when leakage of names 1524 happens from presumed to be closed networks. Example of the former 1525 are the very large TLDs like .com and .de. Example of the latter is 1526 the use of the pseudo TLDs '.local' and '.gprs' which are being used 1527 in private or enterprise contexts without any proper definition or 1528 registration and their consequent leakage of queries into the 1529 'public' DNS. 1531 4.3 The DNS is a strict lookup service 1533 When sending a query to a server, the server is to send the same data 1534 back regardless of context. Further, the server should send either a 1535 "match" which consists of one or more resource records, or a 1536 "failure" which include the special response "no such domain". 1538 This implies that two users sending the same query from two different 1539 locations at the same time should receive the same data in response. 1540 Or, the same user using two different computers with different 1541 operating system should receive the same data. 1543 Having the DNS server doing a "search", undertaking "fuzzy matching" 1544 or inferring some additional context to a query that guides the 1545 server to choose a particular response is ill-advised. The DNS 1546 server can not know the context of the query, nor should it guess 1547 what the DNS response is to be used for. It is always tempting to 1548 assume that the response is to be used by the most popular operating 1549 system for the most popular application of the day. It must though 1550 be remembered that other operating systems and other applications 1551 might break when fuzzy matching happens. For example, instead of 1552 giving back a "no such response" it is conceivable to give back 1553 something which pushes a potential error to the application layer by 1554 returning a synthesized answer that has resource records pointing to 1555 some form of application- level service. This implies the DNS server 1556 must know what application layer protocol is in use, and that a "no" 1557 at the application layer has the same semantics as a "no" on the DNS 1558 (naming) layer. Often TCP is used at the application layer which 1559 implies a "no" might only be signalled to the other end by not 1560 accepting the connection, which means the querying client cannot 1561 differentiate between "no such (dns) name" and "no response in 1562 application protocol". 1564 4.4 Coherency of the DNS 1566 DNS is a bootstrap mechanism that publishes your data in a manner 1567 that allows queries from others to be answered. If you make mistakes 1568 in your local DNS configuration then you don't destroy the utility of 1569 the DNS for yourself, but you destroy the ability for others to 1570 contact you. Someone trying to reach your webpage might not be able 1571 to do so as they can not find the proper translation from your domain 1572 name to the IP address of the web server. It is also the case that 1573 mis-configurations most often happen in the glue between parent zone 1574 and child zone, and not in the child zone itself. Because of this, 1575 if you know where your nameserver is, you might not see the errors, 1576 as they have to do with finding the nameserver, and not the content 1577 of it. 1579 As mentioned before, it is very important the same response is sent 1580 back regardless of from where it is sent. The assumption within the 1581 DNS is that you should be able to pass a URI with an embedded domain 1582 name in it to all of your friends, and they all should be able to 1583 resolve it in an identical fashion. It is extremely important the 1584 domain names are globally unique, and lead to the same result every 1585 time, and from every location. 1587 Part of the coherence requirement is that the servers must be able to 1588 give back the same response to the same query. The implication is 1589 that all servers have to use the same matching algorithms when 1590 attempting to locate a match between a query and the local data used 1591 to form a response. What matching algorithm is used when looking in 1592 the data cannot change between servers because then they will give 1593 back different results for the same query. 1595 Complications arise when considering this in the context of use of 1596 various character sets within the DNS. Having each server use a 1597 local set of rules that defines equivalence of characters generates 1598 the situation of the same query generating different responses. The 1599 implication is that the consideration of different matching/equality 1600 rules can be solved by creating "bundles" of characters which are to 1601 be treated as equal, and solving the problem at the time of 1602 registration. This gives a greater choice for the registrant, and it 1603 can also give a higher freedom regarding context, as the bundles 1604 possibly look differently depending on such things like (parent) 1605 domain and language. 1607 4.5 The DNS as an Identity Glue 1609 When comparing the desired attributes of a useful identity system to 1610 the properties of the DNS it is evident that there is a reasonable 1611 level of fit between the DNS and a generic identity realm. The DNS 1612 provides a namespace that ensures uniqueness, is consistent, can 1613 support persistence, and referential consistency. The space is 1614 structured in a manner that supports relatively efficient lookup over 1615 a large name space that has both hierarchical structuring and within 1616 that some areas of large flat name spaces. The DNS can support trust 1617 models in terms of being able to validate the authenticity of 1618 responses. The DNS can support a variety of resource records that 1619 allow a DNS name token to be used as a search object that can map to 1620 related values drawn from other identifier realms, as well as 1621 supporting indirect self-reference through the use of NAPTR records 1622 and URIs. 1624 There are obvious trade-offs in the design, protocol and deployment 1625 of the DNS in terms of resiliency, dynamic behaviours and 1626 scalability. While it is not argued here that the DNS represents the 1627 only optimal trade-off between these properties, it is argued that 1628 any other identity space with similar properties will be faced with 1629 precisely the same set of trade-offs. It is also probable that any 1630 similar identity space faced with the same requirements of 1631 scalability, operational performance, accuracy and validity of 1632 responses and flexibility of mapping the identity space to related 1633 objects in other identity realms would find a resolution between 1634 these requirements in a manner that would not differ markedly from 1635 the DNS. 1637 The salient observation here is that an identity system acts 1638 generically as a reference to an initial point of rendezvous in a 1639 communication transaction. In this vein the role of the identity 1640 system is to identify how other parties in the network can refer to 1641 the identified element using an identity token that is persistent, 1642 with associated referential mappings into other identity realms that 1643 reflect the current status of the element. Once a communications 1644 state has been established using the rendezvous points, if there are 1645 characteristics of the application that require the subsequent 1646 exchange of information (such as location changes in a mobility 1647 environment, or a server hand-over at the application level) this is 1648 generally the task of components within the protocol stack, using a 1649 trust relationship between the communicating parties to alter the 1650 identity elements used within the stack to match the changing 1651 characteristics. 1653 5. Security Considerations 1655 Any identity system that provides a mapping from an identity value 1656 within one realm to an identity value (or set of values) within 1657 another realm will present a number of considerations with respect to 1658 security. The trust model for an identity system is that the mapping 1659 supported by the identity system is authentic, and that when the 1660 identity value is used as a key in a query operation, the response 1661 should be an accurate response that correctly represents the mapping 1662 originally provided by the assigned holder of that identity value. 1664 Equally, it is necessary to correctly report responses where an 1665 invalid or unassigned identity value is used, providing the query 1666 agent with a clear indication that the identity value is not 1667 assigned. 1669 In a hierarchically structured identity space there are a number of 1670 potential weak points in the identity space, where vulnerabilities 1671 exist for third parties to intercept queries and substitute a 1672 non-authentic response. This could involve misrepresentation of the 1673 of the root servers for the hierarchy, or misrepresentation of 1674 delegation points, as well as misrepresentation of responses for 1675 particular mapping queries. 1677 Any design of an identity space resolution service should be 1678 resilient to these forms of attack, by using appropriate mechanisms 1679 to reduce the risks of interception and misrepresentation in identity 1680 resolution operations. However, recognizing the lack of absolute 1681 assurances that a resolution system is resilient to all forms of 1682 attack, a resolution services should also be capable of exposing the 1683 trust model that exists within the identity space, and allow a user 1684 of the resolution service the ability to validate the response 1685 against the trust model. In other words authenticity should be a 1686 verifiable quality of the identity realm, rather than simply being an 1687 assertion that is interpretable only as a article of faith. 1689 6. Acknowledgements 1691 The editors acknowledge the contributions made by Ran Atkinson, Brian 1692 Carpenter, Vint Cerf, Leslie Daigle, Joel Halpern and James Kempf in 1693 the preparation of this document. 1695 7 Informative References 1697 [1] Saltzer, J., "On the Naming and Binding of Network 1698 Destinations", RFC 1498, August 1993. 1700 [2] Berners-Lee, T., "Universal Resource Identifiers in WWW: A 1701 Unifying Syntax for the Expression of Names and Addresses of 1702 Objects on the Network as used in the World-Wide Web", RFC 1703 1630, June 1994. 1705 [3] Sollins, K. and L. Masinter, "Functional Requirements for 1706 Uniform Resource Names", RFC 1737, December 1994. 1708 [4] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. 1709 Lear, "Address Allocation for Private Internets", BCP 5, RFC 1710 1918, February 1996. 1712 [5] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address 1713 Behaviour Today", RFC 2101, February 1997. 1715 [6] Moats, R., "URN Syntax", RFC 2141, May 1997. 1717 [7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1718 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1719 1998. 1721 [8] Kent, S. and R. Atkinson, "Security Architecture for the 1722 Internet Protocol", RFC 2401, November 1998. 1724 [9] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1725 Specification", RFC 2460, December 1998. 1727 [10] Mealling, M. and R. Daniel, "The Naming Authority Pointer 1728 (NAPTR) DNS Resource Record", RFC 2915, September 2000. 1730 [11] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 1731 2000. 1733 [12] Narten, T. and R. Draves, "Privacy Extensions for Stateless 1734 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 1736 [13] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 1737 RFC 3118, June 2001. 1739 [14] Mealling, M. and R. Denenberg, "Report from the Joint W3C/IETF 1740 URI Planning Interest Group: Uniform Resource Identifiers 1741 (URIs), URLs, and Uniform Resource Names (URNs): Clarifications 1742 and Recommendations", RFC 3305, August 2002. 1744 [15] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 1745 One: The Comprehensive DDDS", RFC 3401, October 2002. 1747 [16] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 1748 Two: The Algorithm", RFC 3402, October 2002. 1750 [17] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 1751 Three: The Domain Name System (DNS) Database", RFC 3403, 1752 October 2002. 1754 [18] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 1755 Four: The Uniform Resource Identifiers (URI)", RFC 3404, 1756 October 2002. 1758 [19] Klensin, J., "Role of the Domain Name System (DNS)", RFC 3467, 1759 February 2003. 1761 [20] Sun, S., Lannom, L. and B. Boesch, "Handle System Overview", 1762 RFC 3650, November 2003. 1764 [21] IEEE, "Guidelines for use of a 48-bit Global Identifier 1765 (EUI-48)", December 2003, 1766 . 1768 [22] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 1769 Registration Authority", December 2003, 1770 . 1772 [23] IEEE, "802.11 Wireless", December 2003, 1773 . 1775 [24] OCLC, "PURLS: Persistent Uniform Resource Locators", December 1776 1995, . 1778 [25] Shoch, J., "Internetwork Naming, Addressing, and Routing", 1779 Proceedings of the 17th IEEE Computer Society International 1780 Conference pp. 72-79, December 1978. 1782 [26] Kunze, J. and R. Rodgers, "The ARK Persistent Identifier 1783 Scheme", draft-kunze-ark-08 (work in progress), July 2004. 1785 Authors' Addresses 1787 Patrik Faltstrom (editor) 1788 Internet Architecture Board 1790 EMail: paf@cisco.com 1792 Geoff Huston (editor) 1793 Internet Architecture Board 1795 EMail: gih@telstra.net 1797 Appendix A. IAB Members 1799 Internet Architecture Board Members at the time this document was 1800 drafted were: 1802 Bernard Aboba 1803 Harald Alvestrand 1804 Rob Austein 1805 Leslie Daigle 1806 Patrik Faltstrom 1807 Sally Floyd 1808 Jun-ichiro Itojun Hagino 1809 Mark Handley 1810 Geoff Huston 1811 Pete Resnick 1812 Bob Hinden 1813 Eric Rescorla 1814 Jonathan Rosenberg 1816 Intellectual Property Statement 1818 The IETF takes no position regarding the validity or scope of any 1819 Intellectual Property Rights or other rights that might be claimed to 1820 pertain to the implementation or use of the technology described in 1821 this document or the extent to which any license under such rights 1822 might or might not be available; nor does it represent that it has 1823 made any independent effort to identify any such rights. Information 1824 on the procedures with respect to rights in RFC documents can be 1825 found in BCP 78 and BCP 79. 1827 Copies of IPR disclosures made to the IETF Secretariat and any 1828 assurances of licenses to be made available, or the result of an 1829 attempt made to obtain a general license or permission for the use of 1830 such proprietary rights by implementers or users of this 1831 specification can be obtained from the IETF on-line IPR repository at 1832 http://www.ietf.org/ipr. 1834 The IETF invites any interested party to bring to its attention any 1835 copyrights, patents or patent applications, or other proprietary 1836 rights that may cover technology that may be required to implement 1837 this standard. Please address the information to the IETF at 1838 ietf-ipr@ietf.org. 1840 Disclaimer of Validity 1842 This document and the information contained herein are provided on an 1843 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1844 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1845 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1846 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1847 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1848 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1850 Copyright Statement 1852 Copyright (C) The Internet Society (2004). This document is subject 1853 to the rights, licenses and restrictions contained in BCP 78, and 1854 except as set forth therein, the authors retain all their rights. 1856 Acknowledgment 1858 Funding for the RFC Editor function is currently provided by the 1859 Internet Society.