idnits 2.17.1 draft-carpenter-behave-referral-object-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 20, 2009) is 5301 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 normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-10) exists of draft-ymbk-aplusp-04 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 4091 (Obsoleted by RFC 5245) -- Obsolete informational reference (is this intentional?): RFC 4092 (Obsoleted by RFC 5245) -- Obsolete informational reference (is this intentional?): RFC 5201 (Obsoleted by RFC 7401) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GROBJ BOF B. Carpenter, Ed. 3 Internet-Draft Univ. of Auckland 4 Intended status: Standards Track M. Boucadair 5 Expires: April 23, 2010 France Telecom 6 J. Halpern 7 Ericsson 8 S. Jiang 9 Huawei Technologies Co., Ltd 10 K. Moore 11 Network Heretics 12 October 20, 2009 14 A Generic Referral Object for Internet Entities 15 draft-carpenter-behave-referral-object-01 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on April 23, 2010. 40 Copyright Notice 42 Copyright (c) 2009 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents in effect on the date of 47 publication of this document (http://trustee.ietf.org/license-info). 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. 51 Abstract 53 The purpose of a referral is to enable a given entity in a multiparty 54 application to pass information to another party. This memo 55 specifies a Generic Referral Object (GRO) to be used in the context 56 of referrals. The proposed object is compact and is application- 57 independent. Both IPv4 and IPv6 schemes are supported, as well as 58 upper layer identifiers. Additional information to characterise an 59 enclosed reference is also described. To allow proper interpretation 60 of referrals, a new notion of scope identifiers is introduced. 62 Table of Contents 64 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 66 1.2. Normative Notation . . . . . . . . . . . . . . . . . . . . 6 67 2. Summary of Requirements . . . . . . . . . . . . . . . . . . . 6 68 3. Referral Semantics and Scope Identifiers . . . . . . . . . . . 7 69 4. Generic Referral Object Format . . . . . . . . . . . . . . . . 11 70 4.1. End of Qualifiers (EOQ) . . . . . . . . . . . . . . . . . 12 71 4.2. IPv4 and IPv6 Addresses (references) . . . . . . . . . . . 12 72 4.3. FQDN (reference) . . . . . . . . . . . . . . . . . . . . . 13 73 4.4. HIT (reference) . . . . . . . . . . . . . . . . . . . . . 13 74 4.5. HI (reference) . . . . . . . . . . . . . . . . . . . . . . 13 75 4.6. IPv4 and IPv6 Masks (qualifiers) . . . . . . . . . . . . . 13 76 4.7. Ref_lifetime (qualifier) . . . . . . . . . . . . . . . . . 13 77 4.8. Ref_source (qualifier) . . . . . . . . . . . . . . . . . . 14 78 4.9. Ref_scope (qualifier) . . . . . . . . . . . . . . . . . . 14 79 4.10. ScopeID (qualifier) . . . . . . . . . . . . . . . . . . . 15 80 4.11. Port_number (qualifier) . . . . . . . . . . . . . . . . . 15 81 4.12. Port_range_contig (qualifier) . . . . . . . . . . . . . . 16 82 4.13. Transport_protocol (qualifier) . . . . . . . . . . . . . . 16 83 4.14. Port_source (qualifier) . . . . . . . . . . . . . . . . . 16 84 4.15. Extensibility . . . . . . . . . . . . . . . . . . . . . . 16 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 88 8. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 91 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 92 Appendix A. Example Use Cases . . . . . . . . . . . . . . . . . . 21 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 95 1. Introduction and Motivation 97 A frequently occurring situation is that one entity A connected to 98 the Internet (or to some private network using the Internet protocol 99 suite) needs to inform another entity B how to reach either A itself 100 or some third-party entity C. This is known as a referral. 102 In the original design of the Internet, IP addresses were global, 103 unique, and quasi-permanent. Also any differentiation beyond that 104 provided by an IP address was done by protocol and port numbers. 105 Referrals were therefore performed simply by passing an IP address 106 and possibly protocol and port numbers. In fact simple referrals 107 (the first case above, sometimes called first-party referrals) were 108 never needed since B could simply use A's address. Third-party 109 referrals were trivial: A would tell B about C's address. Thus, it 110 became common practice to pass raw addresses between entities. A 111 classical example is the FTP PORT command [RFC0959]. 113 Unfortunately, this simple approach to referrals often fails in 114 today's Internet. As has been known for some time [RFC2101], 115 addresses no longer all have global scope, often have limited 116 reachability, and may have limited lifetime. It is no longer 117 reasonable to assume that a host with a fixed location has a fixed 118 address, or even a stable address. 120 We also encounter multi-interfaced hosts whose reachability is bound 121 to a particular (logical/physical) interface. Furthermore, in the 122 context of IPv4 address exhaustion, several solutions have emerged to 123 share a single public IPv4 address between several customers 124 simultaneously. Consequently, an IPv4 address often no longer 125 identifies a single customer/user/host. Other information (e.g., 126 port range) is required to identify unambiguously a given customer/ 127 user/host. 129 Both addresses and port numbers may be different on either side of a 130 NAT or some other middlebox [RFC3234], and firewalls may block them. 131 It is no longer reasonable to assume that an address for host H, 132 which allows a given peer to reach that host in one location, also 133 works from a different location - even if H is reachable from the 134 second location. Also, the Internet now has two co-existing address 135 formats for IPv4 and IPv6. Sending an out-of-scope or expired 136 address, or one of the wrong format, as a referral will fail. 138 In some cases, this problem may be readily solved by passing a Fully 139 Qualified Domain Name (FQDN) instead of an IP address. Indeed, that 140 is an architecturally preferred solution [RFC1958]. However, it is 141 not sufficient in many cases of dynamic referrals. Experience shows 142 that an application cannot use a domain name in order to reliably 143 find useable address(es) of an arbitrary peer. Domain names work 144 fairly well to find the addresses of public servers, as in web 145 servers or SMTP servers, because operators of such servers take pains 146 to make sure that their domain names work. But DNS records are not 147 as reliably maintained for arbitrary hosts such as might need to be 148 contacted in peer-to-peer applications, or for servers within 149 corporate networks. Many small networks do not even maintain DNS 150 entries for their hosts, and for some networks that do list local 151 hosts in DNS, the listings may well be unusable from a remote 152 location, because of two-faced DNS, or because the A record contains 153 a private address. These cases may even be intentional as part of a 154 security ring-fence, where w3.example.com only resolves within the 155 corporate boundary, and/or resolves to IP addresses which are only 156 reachable within the corporate administrative boundaries. In such 157 contexts, incoming connections are usually filtered by the corporate 158 firewall. 160 Furthermore, an FQDN may not be sufficient to establish successful 161 communications involving heterogeneous peers (i.e., IPv4 and IPv6) 162 since A and AAAA records may not be consistently provisioned. There 163 are known cases where a server has one name that produces an A record 164 (e.g., www.example.com) and another name that produces an AAAA record 165 (e.g., ipv6.example.com). 167 In such cases, an IP address either cannot be derived from an FQDN, 168 or if so derived, cannot be accessed from an arbitrary location in 169 the Internet. 171 A related problem is that an application does not have a reliable way 172 of knowing its own domain name - or to be more precise, a way of 173 knowing a domain name that will allow the application to be reached 174 from another location. 176 There are wider systemic problems with the DNS as a reliable way to 177 find a useable address, which are somewhat out of scope here, but can 178 be summarised: 179 o In large networks, it is now quite common that the DNS 180 administrator is out of touch with the applications user or 181 administrator, and as a result, that the DNS is out of sync with 182 reality. 183 o DNS was never designed to accommodate mobile or roaming hosts, 184 whose locator may change rapidly. 185 o DNS has never been satisfactorily adapted to isolated, 186 transiently-connected, or ad hoc networks. 187 o It is no longer reasonable to assume that all addresses associated 188 with a DNS name are bound to a single host. One result is that 189 the DNS name might suffice for an initial connection, but a 190 specific address is needed to rebind to the same peer, say, to 191 recover from a broken connection. 192 o It is no longer reasonable to assume that a DNS query will return 193 all usable addresses for a host. 195 For all the above reasons, the problem of address referrals cannot be 196 solved simply by recommending the use of FQDNs instead. The 197 guideline in [RFC1958] is in fact too simple for today's network. 198 Something more elaborate than an IP address or an FQDN appears to be 199 needed in the general case of application referrals. 201 The first motivation for this draft is the observation that unless 202 the parties involved have reached an understanding about the scope, 203 lifetime, and format of the elements in a referral through some other 204 means, that information must be passed with the referral. This is 205 required so that the receiving entity can determine whether or not 206 the referral is useful. The referral therefore needs to consist of a 207 fully-fledged data structure. 209 When a referral fails, good design suggests that the receiving entity 210 should attempt to correct the situation. For example, if 211 communication fails to be established using an IP address, it would 212 often be appropriate to attempt a DNS lookup, despite the 213 difficulties mentioned above. The second motivation for this draft 214 is that it may be helpful to the entity receiving a referral to also 215 receive information about the source of the referral, such as an 216 FQDN, if that is known to the sender of the referral. The receiving 217 entity can then attempt to recover a valid address (and possibly port 218 number) for the referred entity. 220 The third motivation is to allow a referral to contain alternatives 221 to an IP address or an FQDN, when any such alternatives exist. 223 We observe that we have outlined two separate requirements above: the 224 need to define address scope more precisely, and the need for a 225 generic referral object. Below, the two requirements are made more 226 precise and a GRO format is defined. 228 It should be noted that partial or application-specific solutions to 229 this problem abound. A non-normative Appendix gives examples, in the 230 form of use cases. The objective of this specification is to define 231 a generic and extensible solution, to allow more robust application 232 design. It is an open question whether existing applications will 233 benefit from retro-fitting GROs, or whether they will mainly be of 234 use for new applications. 236 1.1. Terminology 238 This document makes use of the following terms: 239 o "Generic Referral Object (GRO)": the data object defined by this 240 specification. 241 o "Entity": we use this rather than "application" to describe any 242 software component embedded in a host, not just a specific 243 application, that sends, receives or makes use of GROs. Also, in 244 case of dynamic load sharing or failover, an entity might even 245 migrate between hosts. 246 o "Referral": the act of one entity informing another entity how to 247 contact a specific entity. 248 o "Reference": the actual data (name, address, identitifier, 249 locator, pointer, etc.) that is the basis of a referral. 250 o "Scope Identifier (ScopeID): an identifier for the scope of 251 reachability of a reference. 252 o "Qualifier": a data item that gives additional information about a 253 Reference. 254 o "Referring entity": the entity that sends a referral. 255 o "Receiving entity": the entity that receives a referral. 256 o "Referenced entity": the entity described in a GRO. 258 1.2. Normative Notation 260 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 261 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 262 document are to be interpreted as described in [RFC2119]. 264 2. Summary of Requirements 266 A GRO should be self-describing; that is to say, even if it is 267 forwarded several times across the network, the ultimate receiving 268 entity should be able to extract and interpret all the information 269 inserted by the original referring entity. 271 A GRO should be compact (i.e., binary encoded) and designed for 272 efficient processing. 274 The GRO format must not be specific to a given IP version and must 275 not be application-specific. 277 A GRO should contain information that the referring entity can 278 provide about the scope, lifetime, format and source of the referral, 279 encoded in a universal format. 281 The GRO format should be extensible with well-defined backwards 282 compatibility. 284 A damaged GRO would be useless. However, to maintain efficiency, 285 intrinsic error detection or correction for GROs should not be 286 mandatory. Therefore, GROs SHOULD be sent over a channel supporting 287 error detection or correction. 289 A forged GRO would be at least as dangerous as a forged IP address. 290 However, to maintain efficiency, intrinsic cryptographic 291 authentication of GROs should not be mandatory. The use of an 292 authenticated channel to transmit GROs is RECOMMENDED. 294 An intercepted GRO would be at least as revelatory as an intercepted 295 IP address. However, to maintain efficiency, intrinsic encryption of 296 GROs should not be mandatory. The use of an encrypted channel to 297 transmit GROs is RECOMMENDED. 299 3. Referral Semantics and Scope Identifiers 301 The principal purpose of a referral is to enable one entity in a 302 multi-party application to pass information to another party involved 303 in the same application. This specification makes no assumptions 304 about whether the entities are acting as clients, servers, peers, 305 super-nodes, relays, proxies, etc., as far as the application is 306 concerned. Neither does it take a position as to how the various 307 entities become aware of the need to send a referral; this depends 308 entirely on the structure of the application. 310 It is the responsibility of the referring entity to construct a GRO 311 on the basis of information in its possession. It is the 312 responsibility of the receiving entity to interpret and check this 313 information. Due to the fluidity of connectivity in today's 314 Internet, the referring entity cannot guarantee that the referenced 315 entity can be reached. This can only be checked by the receiving 316 entity. In the event of a reachability problem, information in the 317 GRO may assist the receiving entity to find an alternative path. 319 Since the most fundamental quantity likely to be conveyed in a GRO is 320 an IP address, (and possibly a port number) its scope is a key 321 question. Address scope is not a simple concept, as shown by the 322 discussion in [RFC4007] and the practical difficulties caused by 323 [RFC3484]. Even the concept of link-local scope is complicated by 324 the existence of multi-link subnets [RFC4903]. For the purpose of 325 referrals, it seems that previous formalisations of the concept of 326 scope are inadequate. Assuming that a GRO is trustworthy, one 327 question that a receiving entity must answer is: "can the address in 328 this GRO be reached from here?" That question is not answered by 329 knowing only the scope (in the sense of [RFC4007]) as defined at the 330 location of the referring entity. For that reason, scope is 331 represented in a new way in GROs. Firstly, the scope is qualified 332 (to the best of the referring entity's knowledge) as follows: 333 o Null. The address is known not to be applicable outside the 334 referring host (e.g., a loopback address). This option is 335 provided mainly for completeness. There is no value in such a 336 GRO, and for privacy reasons it should not be communicated anyway. 337 o Link. Apart from the standard Ethernet-like view of link 338 locality, this scope would also apply to point-to-point links and 339 to fragments of a multi-link subnet. Although on-link referrals 340 should be trivial, this case is included to allow for uniform 341 design of applications utilising GROs, so that link-local does not 342 become a special case. 343 o Limited. The address has applicability beyond the link, but it is 344 known not to have global applicability. Examples include IPv4 345 private addresses [RFC1918] and IPv6 Unique Local Addresses 346 (ULAs)[RFC4193]. Other cases include addresses on subnets which 347 the referring entity knows to be obstructed by firewalls, network 348 address translators, or other barriers to transparency [RFC2775]. 349 A typical case is the set of subnets sharing a single set of 350 border routers connecting them to the Internet. 351 o Global. The address has applicability beyond the link, and is 352 believed to have global applicability within its address family. 354 However, particularly in the case of limited scope, this is 355 insufficient for the receiving entity to decide whether the address 356 is applicable in the receiving entity's context. The scopes above 357 are described as if they were a set of concentric circles, but 358 reality is more complex, and limited scopes might overlap each other 359 in an arbitrary way, for example when multiple VPNs are formed. A 360 case in point is a VPN constructed between two independent sites, 361 over which only those two sites' ULAs are routed. This would allow a 362 complex pattern of overlapping scopes. For example, hosts in site A 363 might potentially have addresses in three different scopes (global, 364 Site_A_only, ULA_A+B). Similarly, site B might also recognize three 365 scopes (global, Site_B_only, ULA_A+B). Which hosts can send packets 366 to each other will depend on the combination of addresses and scopes 367 available. For example, a host which only has an address in scope 368 Site_A_only cannot send a packet to a host which only has an address 369 in scope ULA_A+B. Hosts in scope ULA_A+B can send packets between 370 sites A and B over the VPN. This can readily be encoded in routing 371 configurations, but application software is generally unaware of it. 373 Thus, a referring entity may or may not be aware that the receiving 374 entity and the referenced entity are within a link scope or limited 375 scope that does not contain the referring entity. Therefore, a GRO 376 may also include a scope identifier (ScopeID), which is an arbitrary 377 label for a region of the network within which certain link or 378 limited scope addresses are applicable. 380 We cannot assume that the referring entity knows the scopes that are 381 accessible to the receiving entity. For this reason, all available 382 information SHOULD be included in a GRO. 384 [[ Discussion invited: Should we also define optional preference 385 information for each reference in a GRO, or alternatively require 386 that references be listed in order of preference? Here is some 387 tentative text, not followed up in the strawman GRO format below. ]] 389 A preference order (or reachability trust level?) MAY be associated 390 with enclosed objects but the receiving entity is not obliged to 391 follow that order since this may induce conflicts with local policies 392 (sometime on per interface basis). 394 There needs to be a high level of assurance that ScopeIDs are unique, 395 or at least that a GRO will never be forwarded outside a region in 396 which ScopeIDs are unique. Also, all referring and receiving 397 entities need to be aware of the ScopeID(s) that apply to them. 398 However, it is clearly undesirable to create a new global 399 registration scheme for ScopeIDs. 401 The delimiter of a limited scope will in many cases be the device 402 (firewall or NAT) that obstructs transparency. A tempting solution 403 would be to use some unique identifier of that device as the unique 404 ScopeID. Unfortunately, this cannot be an IP address of the device, 405 since in the case of nested NATs, all its addresses may be ambiguous. 406 Neither can we rely on such a device having its own FQDN, or on that 407 FQDN being known to all entities within the scope concerned. 408 Finally, some limited scopes may not be hidden behind a single such 409 device; for example, a limited scope might consist of a company's 410 network and selected VPN connections to subsets of several business 411 partners' networks. Alternatively, multiple limited scopes might be 412 hidden behind the same device. Device addresses are therefore not 413 suitable as ScopeIDs. 415 Therefore, a limited scope can best be defined as whatever set of 416 referring and receiving entities have been configured (statically or 417 dynamically) to accept a given ScopeID in some unambiguous namespace 418 (see Section 4.10). 420 Methods for configuring, advertising and discovering ScopeIDs are not 421 defined in this document. However, in their absence, it is extremely 422 hard for receiving entities to interpret and use information about 423 limited scopes. To the extent possible, all entities involved in 424 referrals should determine what scope is shared between the referred 425 entity and the receiving entity, by any means. Those means are not 426 covered in this document, but may include use of external services, 427 agreement on scope identifiers, or direct negotiation. 429 o If shared scope (or set of scopes) is determined, a referral 430 should ideally only include information useful in that scope or 431 set of scopes. 432 o If shared scope is uncertain, a referral should include all 433 information that might be useful, taking privacy considerations 434 into account. 436 In general, the referring entity cannot know the scope in which the 437 GRO will be interpreted. For example, the initial receiving entity 438 may itself be behind a NAT, unknown to the referring entity, or the 439 receiving entity may send the GRO onwards to another host in yet 440 another scope. In practice, we have to leave the receiver to decide 441 whether certain information is useful or not. In the case of a 442 ScopeID in particular, the referring entity is not required to know 443 which ScopeIDs apply to the receiving entity. 445 Discovery or negotiation of ScopeIDs between referring, referenced 446 and receiving entities is certainly a possibility, but may be 447 expensive, and is not assumed by this specification. 449 A referring entity may obtain the address and port number for the 450 referenced entity in various ways, and knowledge about this may help 451 the receiving entity when combined with scope information. For 452 example, if the receiving entity is aware that the address has been 453 translated, and that it has global scope, it may choose to use it 454 without further checks. If it is not marked as translated, and has 455 limited scope, the receiving entity may then verify whether it has a 456 suitable ScopeID. 458 To enable such logic, a GRO may describe the source of an address or 459 port number. How knowledge of this source is obtained is outside the 460 scope of the present specification, but ICE [I-D.ietf-mmusic-ice] is 461 an example method. It is also out of scope here to describe exactly 462 how the receiving entity uses the information; for example GRO 463 semantics do not include or imply preferences or priorities when 464 multiple addresses are provided. The receiving entity may choose to 465 use a predefined policy, apply general logic as sketched in the 466 previous paragraph, or follow application-specific logic, all based 467 on the data provided in a GRO. 469 Obviously, a GRO is no use unless it contains at least one item that 470 can be used to find a path to the referred entry. One option would 471 be to make the presence of at least one IP address mandatory. 472 However, there are alternatives, the most obvious one being an FQDN. 473 Any form of identifier-locator separation, with HIP [RFC5201] as an 474 example, may also offer an alternative. Therefore, we do not require 475 a GRO to include an IP address, even though its inclusion is a very 476 likely case. 478 4. Generic Referral Object Format 480 [[ Note: This section is a strawman approach to make the ideas more 481 concrete. It is entirely open for discussion. ]] 483 A GRO is composed of a sequence of binary-encoded type-length-value 484 fields (TLVs) transmitted in network byte order. The TLV format is 485 as follows: 487 0 1 2 3 488 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.. 490 | GRType |Q| GRLength | GRValue ... 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.. 493 A GRO MUST include at least one reference that allows a receiving 494 entity to attempt to establish a path to the referred entity. A 495 typical case is an IPv4_address or IPv6_address TLV. Multiple 496 references may be present, and their order is not significant. 498 Apart from this, all TLVs are OPTIONAL. 500 [[ Discusssion invited: At the moment, there is no total length field 501 or end flag for the whole GRO, assuming that GROs will be sent in 502 some kind of container. Opinions among the authors vary about 503 whether this is OK. ]] 505 GRType: Specifies the type of the current TLV. GRType is encoded in 506 7 bits. The initially specified types are, in decimal: 507 0: EOQ. 508 1: IPv4_address. 509 2: IPv6_address. 510 3: FQDN. 511 4: HIT. 512 5: HI. 513 65: IPv4_mask. 514 66: IPv6_mask. 515 67: Ref_lifetime. 516 68: Ref_source. 517 69: Ref_scope. 518 70: ScopeID. 519 71: Port_number. 520 72: Port_range_contig. 521 73: Transport_protocol. 523 74: Port_source. 524 127: reserved. 526 A receiving entity MUST silently ignore any TLV with an unknown or 527 reserved GRType. 529 Each TLV is classified semantically as a reference or as a qualifier. 530 A qualifier provides extra information about a reference or another 531 qualifier.. 533 [[ Discusssion invited: Do we need a syntactic method of 534 distinguishing references from qualifiers? Since unknown TLVs are 535 always discarded, why would that be needed? ]] 537 Q bit: If this bit is set to 1, the current TLV is followed by one or 538 more TLVs that qualify it. 540 GRLength: The length in bytes of the GRValue field. Thus, the total 541 length of the TLV is GRLength+2 bytes. 543 GRValue: The content and encoding depend on GRType. Any padding 544 required to fill an integral number of bytes MUST consist of a 545 sequence of zero bits at the end of the content. 547 4.1. End of Qualifiers (EOQ) 549 This TLV follows the last TLV that qualifies a TLV whose Q bit is set 550 to 1. Its GRLength must be set to 0. 552 The Q bit and EOQ MAY be used recursively, so that qualifiers may 553 themselves be qualified if that proves to be useful. 555 Example (GT=GRType): 557 GT Q|GT Q|GT Q|GT Q|GT Q|GT Q|GT Q|GT Q 558 A 1|xx 0|xx 0|B 1|xx 0|xx 0|EOQ 0|EOQ 0 559 <-------> Qualifiers of B 560 <----------------------------> Qualifiers of A 562 The Q bit MUST NOT be set in an EOQ TLV. 564 4.2. IPv4 and IPv6 Addresses (references) 566 IPv4 and IPv6 addresses are encoded in their normal binary form, with 567 GRLength being 4 and 16 respectively. 569 When multiple addresses are provided, their order does not imply an 570 order of preference. The receiving entity SHOULD apply a local 571 policy and mechanism to choose between alternative addresses, using 572 other information included in the GRO appropriately. This document 573 does not describe such policies and mechanisms, which could be 574 application specific. 576 4.3. FQDN (reference) 578 The Fully Qualified Domain Name of the referenced entity in ASCII 579 format according to [RFC1035]. 581 The GRLength is variable (maximum 63). 583 [[ Discussion invited: Is there also value in a generic URI item? 584 See section on Extensibility below for a related discussion point. ]] 586 4.4. HIT (reference) 588 The Host Identity Tag of the referenced entity [RFC5201]. 590 The GRLength must be set to 16. 592 4.5. HI (reference) 594 The Host Identifier of the referenced entity [RFC5201]. 596 The GRLength is variable. 598 [[ Discussion invited: Is this necessary in order to run the HIP base 599 exchange? The HI is a large object to include in a GRO. Also, do we 600 need a more precise definition of what the HI is (see section 5.2.8 601 of RFC5201)? ]] 603 4.6. IPv4 and IPv6 Masks (qualifiers) 605 IPv4 and IPv6 masks are encoded in their normal binary form, with 606 GRLength being 4 and 16 respectively. 608 4.7. Ref_lifetime (qualifier) 610 Remaining lifetime in seconds of the reference that it qualifies, 611 encoded as a 32 bit binary number in the format of an IPv6 Valid 612 Lifetime [RFC4861]. GRLength must be set to 4. 614 If the lifetime is absent, or if it indicates an infinite lifetime 615 [RFC4861], the receiving entity MUST assign a lifetime of one day to 616 the corresponding reference. 618 The receiving entity MUST count down a received lifetime 619 appropriately. If the GRO is forwarded to an additional receiving 620 entity, the lifetime MUST be updated appropriately. 622 [[ Discussion invited: would it be better to specify an expiry 623 timestamp? ]] 625 [[ Discussion invited: is the default of one day reasonable? ]] 627 4.8. Ref_source (qualifier) 629 This is a single byte indicating the source of the reference that it 630 qualifies. GRLength must be set to 1. The following values may be 631 used: 632 0: source was static configuration 633 1: source was DNS lookup 634 2: source was DHCP or DHCPv6 635 3: source was SLAAC 636 4: relayed address (e.g. from TURN [I-D.ietf-behave-turn] or 637 SOCKS) 638 5: translated address. ("server reflexive" in ICE 639 [I-D.ietf-mmusic-ice] terminology.) 640 6: source was DNS64 synthesis. 642 A receiving entity MUST silently ignore unknown values. 644 4.9. Ref_scope (qualifier) 646 This is a single byte indicating the scope of the reference that it 647 qualifies. GRLength must be set to 1. The scopes are explained in 648 Section 3. The currently defined values are as follows: 649 0: Null 650 1: Link 651 2: Limited 652 7: Global. Note that some unused values precede this value, in 653 case of future changes. 655 A receiving entity MUST silently ignore unknown values. 657 References qualified with the Null value SHOULD NOT be sent and MUST 658 be silently ignored by a receiving entity. 660 When a receiving entity receives a reference qualified with a Link or 661 Limited Ref_scope, and without a ScopeID, it should take locally 662 defined steps to check whether the reference is in fact within a 663 reachable scope. 665 4.10. ScopeID (qualifier) 667 A ScopeID, if present, is a label for the scope of the reference that 668 it qualifies. 670 When a receiving entity receives a reference qualified with a 671 Ref_scope and a ScopeID, it should verify the ScopeID against a list 672 of ScopeIDs known to be reachable and if not, take other locally 673 defined steps to check whether the reference is in fact within a 674 reachable scope. 676 ScopeIDs should be reasonably certain to be unique, yet require no 677 new system for central administration. 679 [[ Discusssion invited: It isn't clear to the authors that a single 680 syntax for ScopeID is sufficient. Should we allow for subtypes, so 681 that (e.g.) ULA format and FQDN format would both be possible? 682 Should we consider a URI format? The following proposal is 683 tentative. ]] 685 The proposed method is that each organisation that needs to define a 686 ScopeID will first generate a ULA prefix as defined in [RFC4193], and 687 then form a specific IPv6 address using that ULA prefix. It is 688 RECOMMENDED to form an address using a valid universal EUI-64 689 interface identifier according to [RFC4291], and this EUI-64 690 identifier MAY be the same one as used in the RFC4193 procedure. 692 The GRLength must be set to 16. The GRValue is the ScopeID in the 693 format of an IPv6 address, although it will be treated entirely as an 694 opaque binary value in the GRO referring and receiving entities. 696 4.11. Port_number (qualifier) 698 The inbound TCP/UDP/SCTP/DCCP port number associated with the 699 reference that it qualifies. The port number may be bound to a 700 specific transport protocol. 702 The GRLength must be set to 2. 704 The GRValue is a 16-bit port number. 706 This TLV MAY be qualified by Transport_protocol or Port_source TLVs. 707 An IP address may be qualified by zero, one or several Port_number 708 TLVs. 710 4.12. Port_range_contig (qualifier) 712 A contiguous range of TCP/UDP/SCTP/DCCP port numbers associated with 713 the reference that it qualifies. The port range may be bound to a 714 specific transport protocol (see Transport_protocol item). 716 The GRLength is 4. 718 The GRValue is two 16-bit port numbers, defining the lower and upper 719 bounds of the port range. 721 This TLV MAY be qualified by Transport_protocol or Port_source TLVs. 722 An IP address may be qualified by zero, one or several 723 Port_range_contig TLVs. 725 Defining this TLV is motivated by the need to define a compact object 726 instead of listing all port numbers that are part of a port range 727 [I-D.boucadair-port-range], [I-D.ymbk-aplusp]. Use cases for this 728 qualifier still need to be defined. 730 4.13. Transport_protocol (qualifier) 732 This is a single byte indicating the IPv4 protocol number or IPv6 733 Next Header value used with the reference or Port_number or 734 Port_number_contig that it qualifies. GRLength must be set to 1. 736 A receiving entity MUST silently ignore unknown values. 738 4.14. Port_source (qualifier) 740 This is a single byte indicating the source of the Port_number that 741 it qualifies. GRLength must be set to 1. Accepted values are: 742 0: direct (i.e. known to be the original port number used by the 743 referenced entity) 744 4: relayed port (e.g. from TURN [I-D.ietf-behave-turn] or SOCKS) 745 5: translated port. ("server reflexive" in ICE 746 [I-D.ietf-mmusic-ice] terminology.) 748 [[ Discussion invited: Is this distinction usfeul? ]] 750 The assigned values were chosen to align with those for Ref_source. 751 A receiving entity MUST silently ignore unknown values. 753 4.15. Extensibility 755 Additional GRTypes may be assigned in the range up to 126 by IANA 756 action as defined in Section 6. The documentation of a new GRType 757 must specify its name, define its GRLength, and describe the contents 758 and meaning of its GRValue, including whether it is a reference or a 759 qualifier. 761 This extensibility is not intended to allow a GRO to grow enough to 762 contain every possible kind of application-layer identifier that 763 could ever be used in a referral, because then it would be too hard 764 to write a generic "please connect me to the peer at this GRO" 765 function. Thus, additional GRTypes SHOULD NOT be assigned except for 766 generic purposes that will apply to multiple applications. 767 Similarly, additional sub-types for Address_source, Address_scope, 768 Transport_protocol, and Port_source SHOULD NOT be assigned except for 769 generic purposes. 771 [[ Discussion invited: Sheng Jiang suggested that there should be a 772 generic 'Application-specific ID' GRType, for example in URI format. 773 A problem with this is that it might end up as a catch-all like a DNS 774 TXT record, and threaten interoperability as a result. ]] 776 The reserved GRType value 127 is intended to be used to define an 777 extended range of GRTypes in the highly unlikely event that this 778 becomes necessary. 780 5. Security Considerations 782 It should be noted that GROs cannot function as a way to nullify the 783 effect of a firewall or any other security mechanism. If the 784 receiving entity chooses a particular reference in the GRO and 785 attempts to send packets to the corresponding IP address, whether 786 they are delivered or not will depend on the existing security 787 mechanisms, whatever they may be. 789 Nevertheless, if a site security policy requires it, certain 790 references MAY be excluded from GROs sent to certain destinations. 791 This would require a security policy mechanism to be added to the 792 process of generating GROs and is not further specified here. 794 Forged or intercepted GROs would enable a wide variety of attacks. 795 Although not fundamentally different from attacks based on forged or 796 observed IP addresses or FQDNs, no doubt GROs would allow such 797 attacks to be more ingenious, simply because they provide more 798 information than an address or FQDN alone. As noted in Section 2, 799 GROs SHOULD be transmitted through authenticated and encrypted 800 channels. Since this is a requirement of the channel and not of the 801 GRO, and the channel used depends on a specific use case, it is not 802 further elaborated here. 804 Conceivably, an extension to the GRO format could be defined which 805 would allow it to carry security information (for example, some sort 806 of handle or nonce to authorise firewall penetration). Any such 807 extension MUST be adequately encrypted, in such a way that only a 808 receiving entity in possession of a given key can decrypt it. This 809 is necessary even if the GRO is transmitted through a secure channel. 811 GROs are variable length objects with no defined maximum length. It 812 is possible that a malicious GRO could be constructed, with harmful 813 code masquerading as legitimate or unknown GRType items. All 814 implementations of receiving entities MUST guard against buffer 815 overflows, as well as obeying the rules about ignoring unknown values 816 in Section 4. 818 Unknown TLVs in GROs are to be ignored by the receiving entity. 819 However, GROs may be forwarded to additional receiving entities, in 820 which case the unknown TLVs will be forwarded too. A receiving 821 entity MAY remove unknown TLVs before forwarding a GRO, as a 822 precaution against malicious use. 824 GROs raise potential privacy issues, which are not explored in this 825 document. For example, in the SIP context, mechanisms such as 826 [RFC3323] and [I-D.ietf-sip-ua-privacy] are available to hide 827 information that might identify end-points. Usage scenarios for GROs 828 MUST ensure that they do not unintentionally defeat privacy 829 solutions. 831 6. IANA Considerations 833 IANA is requested to established a Generic Referral Object (GRO) 834 registry, containing sub-registries for GRType, Ref_source, 835 Ref_scope, and Port_source. The range and initial assignments are 836 defined in Section 4. 838 New values in this registry are to be assigned according to the 839 Specification Required policy defined in [RFC5226], which implies 840 review by a Designated Expert according to Section 4.15. 842 [[ Discussion invited: It has been suggested to define a (small) 843 registry for Global ScopeIDs, instead of assuming that "global" for 844 IPv4 and IPv6 is unambiguous. ]] 846 7. Acknowledgements 848 This document originated from a Thai Lunch BOF (a variant of a Bar 849 BOF) at IETF74. Scott Brim contributed substantially to the first 850 version. Valuable comments and contributions were made by Dan Wing, 851 Andrew Sullivan, ... 853 This document was produced using the xml2rfc tool [RFC2629]. 855 8. Change log 857 draft-carpenter-referral-object-00: original version, 2009-05-11 859 draft-carpenter-referral-object-01: updated after discussion in 860 BEHAVE WG at IETF75 and on GROBJ BOF mailing list, 2009-10-20 862 9. References 864 9.1. Normative References 866 [RFC1035] Mockapetris, P., "Domain names - implementation and 867 specification", STD 13, RFC 1035, November 1987. 869 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 870 Requirement Levels", BCP 14, RFC 2119, March 1997. 872 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 873 Addresses", RFC 4193, October 2005. 875 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 876 Architecture", RFC 4291, February 2006. 878 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 879 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 880 September 2007. 882 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 883 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 884 May 2008. 886 9.2. Informative References 888 [I-D.boucadair-port-range] 889 Boucadair, M., Levis, P., Bajko, G., and T. Savolainen, 890 "IPv4 Connectivity Access in the Context of IPv4 Address 891 Exhaustion: Port Range based IP Architecture", 892 draft-boucadair-port-range-02 (work in progress), 893 July 2009. 895 [I-D.boucadair-sipping-ipv6-atypes] 896 Boucadair, M., Noisette, Y., and A. Allen, "The atypes 897 media feature tag for Session Initiation Protocol (SIP)", 898 draft-boucadair-sipping-ipv6-atypes-02 (work in progress), 899 July 2009. 901 [I-D.ietf-behave-turn] 902 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 903 Relays around NAT (TURN): Relay Extensions to Session 904 Traversal Utilities for NAT (STUN)", 905 draft-ietf-behave-turn-16 (work in progress), July 2009. 907 [I-D.ietf-mmusic-ice] 908 Rosenberg, J., "Interactive Connectivity Establishment 909 (ICE): A Protocol for Network Address Translator (NAT) 910 Traversal for Offer/Answer Protocols", 911 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 913 [I-D.ietf-sip-ua-privacy] 914 Munakata, M., Schubert, S., and T. Ohba, "UA-Driven 915 Privacy Mechanism for SIP", draft-ietf-sip-ua-privacy-08 916 (work in progress), May 2009. 918 [I-D.ymbk-aplusp] 919 Bush, R., "The A+P Approach to the IPv4 Address Shortage", 920 draft-ymbk-aplusp-04 (work in progress), July 2009. 922 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 923 STD 9, RFC 959, October 1985. 925 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 926 E. Lear, "Address Allocation for Private Internets", 927 BCP 5, RFC 1918, February 1996. 929 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 930 RFC 1958, June 1996. 932 [RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4 933 Address Behaviour Today", RFC 2101, February 1997. 935 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 936 June 1999. 938 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 939 February 2000. 941 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 942 Issues", RFC 3234, February 2002. 944 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 945 Initiation Protocol (SIP)", RFC 3323, November 2002. 947 [RFC3484] Draves, R., "Default Address Selection for Internet 948 Protocol version 6 (IPv6)", RFC 3484, February 2003. 950 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 951 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 952 March 2005. 954 [RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network 955 Address Types (ANAT) Semantics for the Session Description 956 Protocol (SDP) Grouping Framework", RFC 4091, June 2005. 958 [RFC4092] Camarillo, G. and J. Rosenberg, "Usage of the Session 959 Description Protocol (SDP) Alternative Network Address 960 Types (ANAT) Semantics in the Session Initiation Protocol 961 (SIP)", RFC 4092, June 2005. 963 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 964 June 2007. 966 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 967 "Host Identity Protocol", RFC 5201, April 2008. 969 Appendix A. Example Use Cases 971 [[ This appendix is incomplete and preliminary. ]] 973 Referrals may be used to add an entity to a multi-party conversation, 974 or they may be used (in applications such as telephony) as the first 975 step of transferring one end of a conversation from the referring 976 entity to the receiving entity. [[ Say more? ]] 978 TBD: FTP/PORT, HTTP referrals... text needed 980 BitTorrent is a distributed file sharing infrastructure. It is based 981 on P2P techniques for exchanging files between connected users. 982 Three parties are involved in a BitTorrent architecture: (1) The 983 server into which, has been uploaded the torrent file. (2) The 984 Tracker which maintains a list of clients which have the file or some 985 portions of that file. (3) Entities which are downloading and/or 986 uploading portions of the file. In order to download a given file, a 987 BitTorrent client needs to obtain the corresponding torrent file 988 (i.e. a file which includes the meta-data information of the file to 989 be shared: the file name, its length, a hash and the URL of the 990 tracker.). Then, it connects to the tracker to retrieve a list of 991 lechers (clients which are currently downloading the file but do not 992 yet detain all the portions of the file) and seeders (clients which 993 detain all the portions of the file and are uploading them to other 994 requesting clients). The client connects to those machines and 995 downloads the available portions of the requested file. 997 In a GRO for Skype purposes, if the address fails, you'd have to fall 998 back to the Skype ID instead of an FQDN. This is a case where 999 allowing an application-specific ID might be valuable. Another case 1000 would be Lotus Domino databases - if both IP address and FQDN fail to 1001 find the relevant server, the server name and the database name could 1002 be used as fallback identifiers. 1004 In SIP environments, a SIP Proxy Server intervenes in the placement 1005 of SIP sessions between two UAs. Particularly, the SDP part of 1006 relayed SIP messages includes required information for establishment 1007 of RTP sessions (particularly IP address and port number). A media 1008 description may be unidirectional or symmetric. ICE and ANAT allow 1009 listing several network types and addresses in the same SDP offer. 1011 ANAT: ANAT [RFC4091],[RFC4092] is a procedure used by Dual Stack UAs 1012 to provide both IPv4 and IPv6 addresses in the context of a single 1013 logical media stream. This helps interworking as, whatever the 1014 distant UA version is (IPv4/IPv6-only or Dual-Stack) provided that 1015 this latter is able to understand at least one of the offers. ANAT 1016 semantic does not allow to characterize the IP address(es) it 1017 carries. For instance, no indication if the UA is behind a 1018 translator or not is supported by ANAT (or even ICE). ICE deprecates 1019 ANAT attribute. 1021 Atypes [I-D.boucadair-sipping-ipv6-atypes]: atypes is a SIP media 1022 feature tag which indicates the IP address type capabilities of the 1023 UA (User Agent) and can aid the routing process and ease the 1024 invocation of required functions (e.g. SIP-ALG, NAT64, NAT46) when 1025 heterogeneous (i.e. IPv4 and IPv6) parties are involved in a given 1026 SIP session. Atypes can be used jointly with GRO (also with ICE and 1027 ANAT) to optimise the media path as experienced between involved 1028 parties (especially when Dual-stacks UAs are involved). 1030 Authors' Addresses 1032 Brian Carpenter (editor) 1033 Department of Computer Science 1034 University of Auckland 1035 PB 92019 1036 Auckland, 1142 1037 New Zealand 1039 Email: brian.e.carpenter@gmail.com 1041 Mohamed Boucadair 1042 France Telecom 1043 3, Avenue Francois Chateaux 1044 Rennes 35000 1045 France 1047 Email: mohamed.boucadair@orange-ftgroup.com 1049 Joel M. Halpern 1050 Ericsson 1051 P. O. Box 6049 1052 Leesburg, VA 20178 1053 US 1055 Email: jhalpern@redback.com 1057 Sheng Jiang 1058 Huawei Technologies Co., Ltd 1059 KuiKe Building, No.9 Xinxi Rd., 1060 Shang-Di Information Industry Base, Hai-Dian District, Beijing 1061 P.R. China 1063 Email: shengjiang@huawei.com 1065 Keith Moore 1066 Network Heretics 1068 Email: moore@network-heretics.com