idnits 2.17.00 (12 Aug 2021) /tmp/idnits23007/draft-carpenter-referral-ps-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (February 23, 2011) is 4098 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2775' is defined on line 568, but no explicit reference was found in the text == Outdated reference: draft-ietf-behave-v6v4-xlate-stateful has been published as RFC 6146 -- 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 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational S. Jiang 5 Expires: August 27, 2011 Huawei Technologies Co., Ltd 6 Z. Cao 7 ChinaMobile 8 February 23, 2011 10 Problem Statement for Referral 11 draft-carpenter-referral-ps-02 13 Abstract 15 The purpose of a referral is to enable a given entity in a multiparty 16 Internet application to pass information to another party. It 17 enables a communication initiator to be aware of relevant information 18 of its destination entity before launching the communication. This 19 memo discusses the problems involved in referral scenarios. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 27, 2011. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Goals of Referral . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Reachability . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Path Selection . . . . . . . . . . . . . . . . . . . . . . 4 60 3.2.1. An Example: Triangle Path Optimization . . . . . . . . 4 61 3.3. Interface Selection . . . . . . . . . . . . . . . . . . . 5 62 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 63 4.1. IP Addresses are not sufficient . . . . . . . . . . . . . 6 64 4.2. FQDNs are not sufficient . . . . . . . . . . . . . . . . . 7 65 4.3. Relevant Information is lacking . . . . . . . . . . . . . 9 66 4.4. Extra complexity from ID-Locator Split Mechanisms . . . . 9 67 5. A Generic Referral Mechanism is needed . . . . . . . . . . . . 10 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 71 9. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 10. Informative References . . . . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 75 1. Introduction 77 A frequently occurring situation is that one entity A connected to 78 the Internet (or to some private network using the Internet protocol 79 suite) needs to be aware of the information of another entity B in 80 order to reach it. The information can be obtained from B itself or 81 some third-party entity C. This is known as a referral. 83 Referral is the act whereby one entity informs another entity how to 84 contact a specific entity. It enables a communication initiator to 85 be aware of relevant information of its destination entity in order 86 to launch a communication channel. This referral information can be 87 obtained through an existing communication channel between these two 88 entities or from thrid-party entities. 90 In the original design of the Internet, IP addresses were global, 91 unique, and quasi-permanent. Also any differentiation beyond that 92 provided by an IP address was done by protocol and port numbers. 93 Referrals were therefore performed simply by passing an IP address 94 and possibly protocol and port numbers. In fact simple referrals 95 (the first case above, sometimes called first-party referrals) were 96 never needed since A could simply use B's address. Third-party 97 referrals were trivial: C would tell A about B's address. Thus, it 98 became common practice to pass raw addresses between entities. A 99 classical example is the FTP PORT command [RFC0959]. 101 2. Terminology 103 This document makes use of the following terms: 104 o "Entity": we use this rather than "application" to describe any 105 software component embedded in an Internet host, not just a 106 specific application, that sends, receives or makes use of 107 referrals. Also, in case of dynamic load sharing or failover, an 108 entity might even migrate between hosts. 109 o "Referral": the act of one entity informing another entity how to 110 contact a specific entity. 111 o "Reference": the actual data (name, address, identitifier, 112 locator, pointer, etc.) that is the basis of a referral. 113 o "Referring entity": the entity that sends a referral. 114 o "Receiving entity": the entity that receives a referral. 115 o "Referenced entity": the target entity of a reference. 116 o "Scope": the region or regions of the Internet within which a 117 given reference is applicable to reach the referenced entity. 119 3. Goals of Referral 121 The principal purpose of referral is to enable one entity in a multi- 122 party application to pass information to another party involved in 123 the same application. This document makes no assumptions about 124 whether the entities are acting as clients, servers, peers, super- 125 nodes, relays, proxies, etc., as far as the application is concerned. 126 Neither does it take a position as to how the various entities become 127 aware of the need to send a referral; this depends entirely on the 128 structure of the application. 130 3.1. Reachability 132 The primary goals of referral is to enable a communication initiator 133 to reach its destination entity. Referral is a best effort 134 mechanism. It does not guarantee actual reachability, since the 135 referring entity has no general way of knowing which paths exist 136 between the receiving entity and the referenced entity. Even if a 137 reference is theoretically in scope, and within its defined lifetime, 138 it may have become unreachable since it was sent. A receiving entity 139 should always be prepared for reachability failures and associated 140 retry and failover mechanisms, which are out of scope for the 141 referral mechanism itself. 143 3.2. Path Selection 145 A reference might carry multiple references for the same target. 146 These may lead to multiple possible paths from the receiving entity 147 to the referenced entity. This scenario is particularly generic when 148 the destination or/and source entity has multiple interfaces or is 149 multi-homed. 151 The referring entity is not likely to know which path is best. The 152 receiving entity will need to make a choice, possibly by local policy 153 (e.g. [RFC3484]) or possibly by trial and error (e.g. [RFC4038], 154 [RFC5534]). This choice is also out of scope for the referral 155 mechanism itself. 157 3.2.1. An Example: Triangle Path Optimization 159 In application scenarios, the triangular path shown below is common. 160 Both Host A and Host B connect to an application server and the 161 application server forwards traffic as a relay agent. A slightly 162 more complicated scenario is when the two hosts connect to different 163 application servers individually and application servers talk to each 164 other's relay agents. In SIP, this is often called the "SIP 165 trapezoid". 167 +------------------------------+ 168 | application server | 169 +--+------------------------+--+ 170 / \ 171 | | 172 | referral information | 173 | | 174 | | 175 +-+-+ +-+-+ 176 | A +----------------------+ B | 177 +---+ direct communication +---+ 179 By passing A's reference to B, B can try to communicate directly with 180 A, using the communication line at the bottom. If the direct 181 communication is established successfully, the triangle path gets 182 optimized. Both the application server and network bandwidth can be 183 benefit from this operation. 185 3.3. Interface Selection 187 We also encounter multi-interfaced hosts whose reachability is bound 188 to a particular (logical/physical) interface. More information is 189 required to indicate which interface may be used under different 190 circumstances. The multi-interface problem is defined and studied by 191 the IETF MIF WG. Here referral can provide host A's multi-interface 192 information to host B; accordingly, host B can select one of the 193 interfaces to establish a connection. 195 +------------+ Path 1 +------------+ 196 |Interface A1+----------------+Interface B1| 197 | Host A | | Host B | 198 |Interface A2|----------------+Interface B2| 199 +------------+ Path 2 +-----------+ 201 For example, as shown in the above figure, Host A has connected to 202 Host B through Path 1. They can exchange references through Path 1. 203 They may disciver that Path 2, using different interfaces, is better 204 than Path 1, maybe cheaper, faster or more stable. Then, they can 205 switch to Path 2. For example, Host A has interface A1 as broadband 206 access, almost free; and interface A2 is 3G access, which costs 0.1 $ 207 per MB. Both of them are avaible for incoming connections. If this 208 information is passed to host B, through referral, then host B should 209 choose the A1 interface to reach host A. Such information is useful 210 to express a host's status or preference. 212 In order to choose between different interfaces, not only the 213 connectivity information of these interfaces, but also some additonal 214 information may be helpful, such as bandwidth, financial cost, 215 latency, etc. This additional information may also be provided 216 through referral. However, this additional information, even if 217 accurate when sent by the referring entity, may nevertheless be 218 invalid at the location of the receiving entity. 220 4. Problem Statement 222 Unfortunately, the simple approach to referrals, passing an IP 223 address, often fails in today's Internet. As has been known for some 224 time [RFC2101], hosts' IP addresses no longer all have global scope. 225 They often have limited reachability, and may have limited lifetime. 226 They are not sufficient to establish communication in many cases of 227 dynamic referrals, for a variety of reasons. FQDNs may be used 228 instead in some scenarios. However, FQDNs also have their own 229 limitations and may fail in some scenarios. 231 4.1. IP Addresses are not sufficient 233 It is no longer reasonable to assume that a host with a fixed 234 location has a fixed IP address, or even a stable IP address. 236 Furthermore, in the context of IPv4 address exhaustion, several 237 solutions have emerged to share a single public IPv4 address between 238 several customers simultaneously. Consequently, a public IPv4 239 address often no longer identifies a single customer/user/host, while 240 a private IPv4 address is meaningless out of the private network 241 scope. Other information (e.g., port range) is required to identify 242 unambiguously a given customer/user/host. Both IP addresses and port 243 numbers may be different on either side of a NAT or some other 244 middlebox [RFC3234], and firewalls may block them. It is no longer 245 reasonable to assume that an IP address for a host, which allows a 246 given peer to reach that host in one location, also works from a 247 different location - even if that host is reachable from the second 248 location. 250 Also, the Internet now has two co-existing address formats for IPv4 251 and IPv6. Direct communication can only be established when both 252 peers use the same IP version. Having the address of the source and 253 destination in the same IP version does not necessarily mean that the 254 path will be using that IP version. Simple approaches may cause 255 unnecessary double translation [I-D.boucadair-softwire-cgn-bypass]. 256 Some addresses may even be the result of translation between IPv4 and 257 IPv6, with severe limitations on their scope and lifetime. Sending 258 an out-of-scope or expired address, or one of the wrong format, as a 259 referral will fail. 261 A specific problem of this kind may be caused by NAT64 262 [I-D.ietf-behave-v6v4-xlate-stateful]. If an IPv6-only host behind a 263 NAT64 obtains a synthetic IPv6 address for an IPv4-only host, it can 264 communicate successfully via the NAT64. However, if the synthetic 265 address is referred to another IPv6 host, it may or may not work 266 correctly. We can consider four cases: 268 1. If the receiving entity is behind the same NAT64 as the referring 269 entity, all should be well. 270 2. If the referring entity and the receiving entity are behind 271 different NAT64 devices, both using the defined Well Known Prefix 272 [RFC6052], all should be well, because the same synthetic address 273 will work in both cases. 274 3. If the receiving entity is behind a different NAT64 that uses a 275 Network Specific Prefix [RFC6052], the synthetic address will be 276 meaningless and communication will fail. The only way to avoid 277 this failure is for the original NAT64's Network Specific Prefix 278 to be globally reachable, which seems highly unlikely for 279 operational and security reasons. 280 4. If the receiving entity is a dual stack node that is not behind a 281 NAT64, the synthetic address will be meaningless. Although there 282 is an IPv4 path to the target host, the receiving entity will not 283 know how to find it. Again, the only way to avoid this failure 284 is for the original NAT64's prefix to be globally reachable. 286 In the last two cases, even if connectivity failure is avoided, the 287 path taken by the packets will be far from optimal, traversing the 288 original NAT64. 290 IP addresses today may have an implied "context" (VPN, VoIP VC, IP 291 TV, etc.): the reachability of such an address depends on that 292 context. 294 An implication of these issues is that there is no clean definition 295 of the scope of an address (especially an IPv4 address, due to the 296 prevalence of NAT). It is impossible to determine algorithmically, 297 by inspecting the bits of an address, what its scope of reachability 298 is. Resolving this problem would greatly clarify the general problem 299 of referrals. 301 4.2. FQDNs are not sufficient 303 In some cases, this problem may be readily solved by passing a Fully 304 Qualified Domain Name (FQDN) instead of an IP address. Indeed, that 305 is an architecturally preferred solution [RFC1958]. However, it is 306 not sufficient in many cases of dynamic referrals. Experience shows 307 that an application cannot use a domain name in order to reliably 308 find usable address(es) of an arbitrary peer. Domain names work 309 fairly well to find the addresses of public servers, as in web 310 servers or SMTP servers, because operators of such servers take pains 311 to make sure that their domain names work. But DNS records are not 312 as reliably maintained for arbitrary hosts such as might need to be 313 contacted in peer-to-peer applications, or for servers within 314 corporate networks. Many small networks do not even maintain DNS 315 entries for their hosts, and for some networks that do list local 316 hosts in DNS, the listings may well be unusable from a remote 317 location, because of two-faced DNS, or because the A record contains 318 a private address. These cases may even be intentional as part of a 319 security ring-fence, where w3.example.com only resolves within the 320 corporate boundary, and/or resolves to IP addresses which are only 321 reachable within the corporate administrative boundaries. In such 322 contexts, incoming connections are usually filtered by the corporate 323 firewall. 325 An additional issue with FQDNs is the very common situation where 326 multiple hosts are hidden behind a NAT, but they share one FQDN which 327 is in fact a dummy name, created automatically by the ISP so that 328 reverse DNS lookup will succeed for the NAT's public IPv4 address. 329 Such FQDNs are useless for identifying specific hosts. 331 Furthermore, an FQDN may not be sufficient to establish successful 332 communications involving heterogeneous peers (i.e., IPv4 and IPv6) 333 since A and AAAA records may not be consistently provisioned. There 334 are known cases where a server has one name that produces an A record 335 (e.g., www.example.com) and another name that produces an AAAA record 336 (e.g., ipv6.example.com). An additional complication is that some 337 answers from DNS may be synthetic IP addresses, e.g., AAAA records 338 sent by DNS64. The host may have no means to detect that such an 339 address represents an IPv4 host. These addresses should not be 340 interpreted as native IPv6 address. 342 In such cases, an IP address either cannot be derived from an FQDN, 343 or if so derived, cannot be accessed from an arbitrary location in 344 the Internet. 346 A related problem is that an application does not have a reliable way 347 of knowing its own domain name - or to be more precise, a way of 348 knowing a domain name that will allow the application to be reached 349 from another location. 351 There are wider systemic problems with the DNS as a reliable way to 352 find a usable address, which are somewhat out of scope here, but can 353 be summarised: 354 o In large networks, it is now quite common that the DNS 355 administrator is out of touch with the applications user or 356 administrator, and as a result, that the DNS is out of sync with 357 reality. 358 o DNS was never designed to accommodate mobile or roaming hosts, 359 whose locator may change rapidly. 360 o DNS has never been satisfactorily adapted to isolated, 361 transiently-connected, or ad hoc networks. 362 o It is no longer reasonable to assume that all addresses associated 363 with a DNS name are bound to a single host. One result is that 364 the DNS name might suffice for an initial connection, but a 365 specific address is needed to rebind to the same peer, say, to 366 recover from a broken connection. 367 o It is no longer reasonable to assume that a DNS query will return 368 all usable addresses for a host. 369 o Hosts may be identified by a different URI per service: no unique 370 URI scheme, meaning no single FQDN, will apply. 372 For all the above reasons, the problem of address referrals cannot be 373 solved simply by recommending the use of FQDNs instead. The 374 guideline in [RFC1958] is in fact too simple for today's network. 375 Something more elaborate than an IP address or an FQDN appears to be 376 needed in the general case of application referrals. 378 4.3. Relevant Information is lacking 380 Neither an IP address nor an FQDN gives complete information about 381 the referenced entity. For example, IP addresses normally have 382 associated lifetimes (derived from DHCP, SLAAC or the relevant DNS 383 TTL), so they should be treated as invalid after their lifetimes 384 expire. A referral that does not convey the lifetime associated with 385 an address is problematic. As mentioned above, the scope of a 386 reference also affects its usefulness. These are examples of 387 additional information that is necessary to correctly interpret a 388 referral; therefore part of the problem is conveying such information 389 along with the reference. 391 4.4. Extra complexity from ID-Locator Split Mechanisms 393 Additional complexity for referrals would come from the deployment of 394 any technology that separates locators from identifiers, rather than 395 combining the two as an IP address. Since a very wide range of such 396 solutions have been proposed (e.g. HIP, LISP, ILNP and Name-based 397 Sockets) [I-D.ubillos-name-based-sockets], it is difficult to define 398 the resulting problems precisely. 400 However, to consider the example of Name-based Sockets, if a referral 401 was made based on the IP address being used at a given instant for a 402 Name-based Socket, that address might be useless by the time the 403 referral was completed, because the socket suddenly migrated to a 404 different IP address. 406 The SHIM6 protocol [RFC5533] and the Multiple Interfaces (MIF) 407 Working Group may produce similar difficulties, since they also 408 consider scenarios where the IP address in use for some purpose may 409 change unexpectedly. 411 Any referral mechanism must be able to deal with situations where the 412 locator corresponding to a given identifier is subject to change. 414 5. A Generic Referral Mechanism is needed 416 The first motivation is the observation that unless the parties 417 involved have reached an understanding about the scope, lifetime, and 418 format of the elements in a referral through some other means, that 419 information must be passed with the referral. This is required so 420 that the receiving entity can determine whether or not the referral 421 is useful. The referral therefore needs to consist of a fully- 422 fledged data structure, or to be made using a mutually agreed 423 referral protocol. 425 When an attempt to establish a communication channel based on certain 426 referral information fails, good design suggests that the receiving 427 entity should attempt to correct the situation. For example, if 428 communication fails to be established using an IP address, it would 429 often be appropriate to attempt a DNS lookup, despite the 430 difficulties mentioned above. The second motivating problem is that 431 it may be helpful to the entity receiving a reference to also receive 432 information about the source of the reference, such as an FQDN, if 433 that is known to the sender of the reference. The receiving entity 434 can then attempt to recover a valid address (and possibly port 435 number) for the referred entity. 437 The third motivating problem is to allow a reference to contain 438 alternatives to an IP address or an FQDN, when any such alternatives 439 exist. 441 Additional arguments for a generic referral mechanism include: 442 1. Allow for general mechanisms that can be used by any application 443 to handle references and understand the meaning of referral 444 information, such as IP address, possibly protocol and port 445 numbers. However, there is an open question whether this 446 standard referral design should be used for new applications 447 only, or extended to existing applications. 448 2. Simplify ALG design during middlebox traversal. There are 449 middleboxes, like firewalls and translators, especially in the 450 mobile network, which require application layer gateways ALG. 451 The cost of ALG functions is huge for the mobile operator in 452 terms of implementation, performance. Standard references could 453 simplify ALG implementation during middlebox traversal in the 454 mobile network. 455 3. Simplify packet inspection. Operators sometimes need to inspect 456 information or details during communication for administration 457 reasons. If referral mechanism is standardized, it is easier for 458 an operator to capture and investigate the required information. 460 We observe that we have identified two general requirements: the need 461 to define address scope more precisely, and the need to communicate 462 references in a generic way. 464 It should be noted that partial or application-specific solutions to 465 these problems abound, because any multi-party distributed 466 application must solve them. The best documented example is ICE 467 [RFC5245], which is an active protocol specific to applications 468 mediated by SDP [RFC4566]. ICE "works by including a multiplicity of 469 IP addresses and ports in SDP offers and answers, which are then 470 tested for connectivity by peer-to-peer connectivity checks." The 471 question raised here is whether we can define requirements for a 472 generic solution that can be used by future applications, and 473 possibly be retro-fitted to existing applications. 475 One approach could be a "SuperICE" designed to be completely general 476 and not tied to the SDP model. Another approach is the idea of a 477 generic referral object. Such an object could be passed between the 478 entities of a multi-party application, but without defining a 479 specific protocol for that purpose. Some applications might choose 480 to send it in-band as a raw binary object, others might use a simple 481 ASCII encoding, and still others might prefer to encode it in XML, 482 for example. Finally, it might also be used as part of SuperICE. 484 6. Security Considerations 486 It should be noted that referral should not function as a way to 487 nullify the effect of a firewall or any other security mechanism. If 488 the receiving entity chooses a particular reference and attempts to 489 send packets to the corresponding IP address, whether they are 490 delivered or not will depend on the existing security mechanisms, 491 whatever they may be. 493 Nevertheless, if a site security policy requires it, certain 494 references may be excluded from referral information sent to certain 495 destinations. This would require a security policy mechanism to be 496 added to the process of generating referral information. 498 Forged or intercepted referral information would enable a wide 499 variety of attacks. Although not fundamentally different from 500 attacks based on forged or observed IP addresses or FQDNs, no doubt 501 referral would allow such attacks to be more ingenious, simply 502 because they provide more information than an address or FQDN alone. 503 Referral information should be transmitted through authenticated and 504 encrypted channels. It is not further elaborated here. 506 Referral may raise potential privacy issues, which are not explored 507 in this document. For example, in the SIP context, mechanisms such 508 as [RFC3323] and [RFC5767] are available to hide information that 509 might identify end-points. Referral usage scenarios must ensure that 510 they do not unintentionally defeat privacy solutions. 512 7. IANA Considerations 514 This document requests no action by IANA. 516 8. Acknowledgements 518 Bo Zhou, formerly with China Mobile, was an original author of this 519 document. His contributions are gratefully acknowledged. 521 Valuable comments and contributions were made by Mohamed Boucadair, 522 Dan Wing, Keith Moore and others. 524 This document was produced using the xml2rfc tool [RFC2629]. 526 9. Change log 528 draft-carpenter-referral-ps-00: original version, 2010-06-21. 530 draft-carpenter-referral-ps-01: add content regarding to ID-Locator 531 Split Mechanisms, 2010-08-30. 533 draft-carpenter-referral-ps-02: add content regarding NAT64, 534 2011-02-23. 536 10. Informative References 538 [I-D.boucadair-softwire-cgn-bypass] 539 Boucadair, M., Jacquenet, C., Song, J., and Q. Niu, 540 "Procedure to bypass DS-Lite AFTR", 541 draft-boucadair-softwire-cgn-bypass-03 (work in progress), 542 October 2010. 544 [I-D.ietf-behave-v6v4-xlate-stateful] 545 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 546 NAT64: Network Address and Protocol Translation from IPv6 547 Clients to IPv4 Servers", 548 draft-ietf-behave-v6v4-xlate-stateful-12 (work in 549 progress), July 2010. 551 [I-D.ubillos-name-based-sockets] 552 Ubillos, J., Xu, M., Ming, Z., and C. Vogt, "Name-Based 553 Sockets Architecture", draft-ubillos-name-based-sockets-03 554 (work in progress), September 2010. 556 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 557 STD 9, RFC 959, October 1985. 559 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 560 RFC 1958, June 1996. 562 [RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4 563 Address Behaviour Today", RFC 2101, February 1997. 565 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 566 June 1999. 568 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 569 February 2000. 571 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 572 Issues", RFC 3234, February 2002. 574 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 575 Initiation Protocol (SIP)", RFC 3323, November 2002. 577 [RFC3484] Draves, R., "Default Address Selection for Internet 578 Protocol version 6 (IPv6)", RFC 3484, February 2003. 580 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. 581 Castro, "Application Aspects of IPv6 Transition", 582 RFC 4038, March 2005. 584 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 585 Description Protocol", RFC 4566, July 2006. 587 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 588 (ICE): A Protocol for Network Address Translator (NAT) 589 Traversal for Offer/Answer Protocols", RFC 5245, 590 April 2010. 592 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 593 Shim Protocol for IPv6", RFC 5533, June 2009. 595 [RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and 596 Locator Pair Exploration Protocol for IPv6 Multihoming", 597 RFC 5534, June 2009. 599 [RFC5767] Munakata, M., Schubert, S., and T. Ohba, "User-Agent- 600 Driven Privacy Mechanism for SIP", RFC 5767, April 2010. 602 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 603 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 604 October 2010. 606 Authors' Addresses 608 Brian Carpenter 609 Department of Computer Science 610 University of Auckland 611 PB 92019 612 Auckland, 1142 613 New Zealand 615 Email: brian.e.carpenter@gmail.com 617 Sheng Jiang 618 Huawei Technologies Co., Ltd 619 Huawei Building, No.3 Xinxi Rd., 620 Shang-Di Information Industry Base, Hai-Dian District, Beijing 621 P.R. China 623 Email: jiangsheng@huawei.com 625 Zhen Cao 626 China Mobile 627 Unit2, 28 Xuanwumenxi Ave,Xuanwu District 628 Beijing, 100053 629 P.R. China 631 Email: caozhenpku@gmail.com