idnits 2.17.1 draft-nordmark-multi6dt-refer-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 11. -- Found old boilerplate from RFC 3978, Section 5.5 on line 427. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 404. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 411. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 417. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 433), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 33. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 3) being 68 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-irtf-nsrg-report-09 -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) == Outdated reference: A later version (-02) exists of draft-ietf-ipv6-ula-central-00 Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Erik Nordmark 2 Oct 15, 2004 Sun Microsystems 3 Multi6 Application Referral Issues 4 6 Status of this Memo 8 By submitting this Internet-Draft, I certify that any applicable 9 patent or other IPR claims of which I am aware have been disclosed, 10 and any of which I become aware will be disclosed, in accordance with 11 RFC 3668. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet Draft expires April 15, 2005. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 In order to fully solve the scalable multihoming problem there is a 38 need to separate the current IP address functionality into 39 identifiers (which are used to identify e.g., TCP connections) and 40 locators which are used to forward packets in the routing system. 41 Such a separation has an impact on the current use of IP address in 42 the application layer. 44 This document presents these issues for the purposes of stimulating 45 discussions. 47 Contents 49 1. INTRODUCTION............................................. 2 50 1.1. Current IP address usage in applications............ 3 51 1.2. Problem Statement................................... 3 53 2. ALTERNATIVES............................................. 5 54 2.1. FQDN instead of IP addresses........................ 5 55 2.2. Single IP address................................... 6 56 2.3. Full set of IP addresses............................ 6 58 3. FUTURE EVOLUTION......................................... 7 60 4. RECOMMENDATIONS.......................................... 8 62 5. ACKNOWLEDGMENTS.......................................... 9 64 6. REFERENCES............................................... 9 65 6.1. Normative References................................ 9 66 6.2. Informative References.............................. 9 68 AUTHOR'S ADDRESSES........................................... 10 70 1. INTRODUCTION 72 The goal of the IPv6 multihoming work is to allow a site to take 73 advantage of multiple attachments to the global Internet without 74 having a specific entry for the site visible in the global routing 75 table. Specifically, a solution should allow hosts to use multiple 76 attachments in parallel, or to switch between these attachment points 77 dynamically in the case of failures, without an impact on the 78 transport and application layer protocols. 80 This document assumes a particular approach to solving this which is 81 based on there being multiple locators (recorded in the DNS using 82 AAAA records) for a host, and for a given transport connection a pair 83 consisting of a local and a peer locator are chosen as part of the 84 identification of the connection. Thus this approach does not 85 introduce any new identifier name space, instead the applications and 86 transports "see" what looks like just an IP address even though some 87 multi6 layer below provides survivability when one of the multiple 88 locators become unreachable. Some more aspects about this approach 89 is specified in [M6SHIM]. For example,the NOID proposal [NOID] used 90 this model, and NOID defined a term AID, for "Application 91 Identifier", for the locator that is chosen to be part of the 92 identification of the transport connection. The AID term is less 93 than ideal; in this document we use the term "ULID" for upper-layer 94 identifier for lack of a better one, for this concept. 96 Effectively this approach implies that while a single IP address (the 97 ULID) is presented to the applications at the API, this IP address 98 serves as a handle for the set of IP addresses/locators for the peer. 100 1.1. Current IP address usage in applications 102 For the purposes of understanding the impact of multi6 on 103 applications we here attempt to categorize the usage of IP addresses 104 in applications: 106 - Short-lived local handle. The IP addresses is never retained by 107 the application. The only usage is for the application to pass it 108 from the DNS APIs (e.g., getaddrinfo()) and the API to the 109 protocol stack (e.g., connect() or sendto()). 111 - Long-lived application associations. The IP address is retained 112 by the application for several instances of communication. 114 - Callbacks. The application at one end retrieves the IP address of 115 the peer and uses that to later communicate "back" to the peer. 117 - Referrals. In an application with more than two parties, party B 118 takes the IP address of party A and passes that to party C. After 119 this party C uses the IP address to communicate with A. 121 - "Identity" comparison. Some applications might retain the IP 122 address, not as a means to initiate communication as in the above 123 cases, but as a means to compare whether a peer is the same as 124 another peer. While this is insecure in general, it might be 125 something which is used e.g., when TLS is used. 127 1.2. Problem Statement 129 The use of a single locator as a handle for the set of locators for 130 the peer at the API impacts the applications as typified above except 131 for the case of the short-lived handle. This case is simple because 132 in fact the IP address, when not used for anything in the application 133 itself, is just a handle that is carried between the DNS API and the 134 TCP/UDP APIs, hence having it effectively be a handle on the set of 135 locators does not introduce any effect on the applications. 137 The long-lived local handle, callbacks, and referrals cases can 138 continue to work in limited ways, but such applications will not be 139 able to take advantage of the multiple locators of the peers. This 140 limitation seems rather natural given that the only name space we 141 will have with this approach that would name a node using a single 142 name is a FQDN (even though FQDNs have issues as will be discussed 143 below), and to name a node using IP addresses would require using the 144 entire set of locators. Thus unless we introduce a new 128-bit name 145 space for node identifiers (or "stack names" in [NSRG]) there would 146 need to be some changes to applications with these types of IP 147 address usage. 149 Using an IP address for "identity comparison" is problematic today 150 due to the lack of security, but also because hosts, such as large 151 servers, might be multihomed even in IPv4 resulting in there not 152 being a single IP address that can identify the host. The 153 introduction of site multihoming using different locator prefixes 154 will make this even more prevalent. Thus we need to understand to 155 what extent IP addresses are used today for "identity comparison" in 156 applications; perhaps this is a non-issue. 158 In this approach, the upper level protocols will operate on ULIDs 159 which are mere locators. Thus as long as a site hasn't renumbered, 160 the ULID can be used to either send packets to the host, or (e.g. if 161 that locator isn't working) it is possible for an application to do a 162 reverse lookup plus forward lookup of the ULID to get the set of 163 locators for the peer. 165 Once a site has been renumbered, the ULIDs which contain the old 166 prefix will no longer be useful. Hence applications must try to 167 honor the DNS TTL somehow. But this is a renumbering issue and not 168 an effect of the multihoming support. 170 Applications, which map the peer's IP address to a domain name, today 171 perform a reverse lookup in the DNS (e.g., using the getnameinfo() 172 API). The approach [M6SHIM] doesn't add or subtract to neither the 173 benefits nor the issues associated with performing such reverse 174 lookups. 176 Applications which today either retain a peer's IPv6 address for 177 future use, such as connecting back to that peer ("callbacks"), or 178 pass a peer's IPv6 address to a third party ("referrals") will not 179 break with this multihoming support; they will end up retaining 180 and/or passing the ULID instead of an IPv6 address. Since the ULID 181 is a locator things will still work as long as that locator is 182 reachable. 184 Should the locator which is the ULID not be reachable, the 185 application/host will fail to communicate with the peer. If the DNS 186 is maintained, a reverse plus forward lookup of the ULID can be used 187 to determine the other locators. Whether these lookups can be hidden 188 from the application, or whether the applications need to be modified 189 to make the callbacks and referrals take full advantage of the 190 multihoming is for further study. 192 Alternatively, the applications can be modified to either pass a 193 domain name, or pass the set of locators, when performing referrals. 194 Such an approach would handle multihoming, but not necessarily site 195 renumbering. 197 2. ALTERNATIVES 199 Given that multihoming will at least introduce multiple 200 addresses/locators for a given host, continuing to use a single 201 address for the long-lived local handle, callbacks, and referrals 202 cases isn't likely to be optimal. 204 2.1. FQDN instead of IP addresses 206 Applications where it is possible to use FQDNs (or protocol elements 207 which embed FQDNs such as URIs) should definitely do so because that 208 would hide the multiple addresses from the core of the application. 210 However, it is far from clear that this is feasible for all 211 applications in all deployments. Reasons why FQDNs are problematic 212 include 214 - Client hosts typically do not have a FQDN which is resolvable in 215 the DNS today. 217 - Even if the bullet above is addressed somehow, the introduction of 218 RFC 3041 temporary addresses for improved privacy adds to the 219 burden. Today there is no mechanism for a host with temporary 220 addresses to create temporary FQDNs that resolve to those 221 addresses, and temporary FQDNs are necessary to preserve the 222 difficulty of correlating these addresses with more permanent 223 identifiers of the host. 225 - At the server end a FQDN is often used, not as a host name, but as 226 an identifier of a service, where the service might be implemented 227 by multiple hosts. In some cases the individual servers might 228 have their own host name as well (such as www17.example.com) but 229 it isn't clear how common this is. 231 2.2. Single IP address 233 As stated above a single address can't in general represent all the 234 locators of a host, and all the locators are needed for the 235 application to take advantage of the multiple paths offered by 236 multihoming. However, in the specific case where the DNS forward and 237 reverse maps for a host are maintained, a single address is 238 sufficient. 240 In this case it is possible to perform a reverse lookup of the single 241 IP address to find out the FQDN, followed by a forward lookup of the 242 FQDN to find all the AAAA records. This method finds all the 243 locators registered in the DNS but assumes that both the reverse tree 244 and the forward tree are maintained. This is not likely be the case 245 for RFC 3041 temporary addresses [RFC3041], and will be problematic 246 for "home multihoming" where a small site is multihomed using 247 multiple ISPs and each ISP provides the forward and reverse DNS for 248 the IP addresses it provides to the site but there is no place to 249 have a single FQDN which maps to both the IP addresses with matching 250 entries in the reverse tree, unless the reverse tree is delegated to 251 the subscriber. 253 Hence this is not recommended except as a transitional measure. 255 2.3. Full set of IP addresses 257 When FQDNs can not be used, the second most attractive approach to 258 handle the general case of multihoming with multiple locators per 259 host is to make the applications that use long-lived handles, perform 260 callbacks, or referrals, use the full set of IP addresses for their 261 peers and themselves. 263 This approach requires APIs by which the applications can retrieve 264 the locators used. For example, at the socket API layer, such APIs 265 could be getmylocators(int socket, ...) and getpeerlocators(int 266 socket, ...) which return the set of locators for the local and 267 remote end of the communication represented by a socket. 269 Together with the existing getsockname() and getpeername() API calls, 270 which return the identifier used by the transport protocol (the 271 ULID), such new APIs would allow the applications to retrieve the 272 transport layer identifiers, whether or not they are locators, and 273 the locator sets. 275 3. FUTURE EVOLUTION 277 There are two things which might have an impact on long-lived 278 sessions, callbacks and referrals in the near future. The first in 279 using unreachable locators, for instance centrally-assigned Unique 280 local addresses [ULA], as ULIDs. The second is the possibility of 281 introducing a scheme with a separate 128-bit identifier name space 282 and lookup functions, where [HIP] is the best current example. 284 Unique local addresses could be treated following approach as just 285 another locator which is known to be unreachable (at least when 286 outside the site to which it is assigned), thus there might be some 287 performance optimizations that can be applied. But the fact that the 288 identifier is centrally assigned means that it is reasonable to 289 maintain reverse and forward DNS entries for at least the /48 prefix. 290 Depending on issues like RFC 3041 addresses, it may or may not be 291 reasonable to expect reverse and forward DNS entries for the full 292 ULA. But in any case, this doesn't seem to have an impact on how 293 referrals would take place; passing a FQDN or the list of locators 294 would work in any case. However, should the unreachable ULA not be 295 treated as a locator but instead solely as a ULID, then the referrals 296 would need to carry a ULID plus the list of locators. 298 As currently defined HIP uses a 128-bit hash of a public key (the 299 HIT) at the socket API and in the transport protocols, which has 300 quite different implications than using one of the locators which is 301 the focus of this document. 303 A question is whether there are some minimum things that can be done 304 that would cause less future obstacles to adopt HIP on a large scale, 305 should that come to pass. The thing that is an obvious issue in 306 terms of this proposal is the assumption that the ULID is one of the 307 locators. As a result of this, the recommendations below suggest 308 that the ULID be carried together with the list of locators, so that 309 should the ULID not be one of the locators the application mechanism 310 will at least not loose track of the ULID. 312 This clearly doesn't solve the issue of referrals etc for HIP, since 313 a general solution would require some way to lookup a HIT which does 314 not yet exist. But it does at least ensure that the applications 315 would contain both the ULID=HIT and the set of locators. 317 4. RECOMMENDATIONS 319 The applications that are not already using FQDNs, and can't be 320 converted to use FQDNs, seem to be best served by carrying a list 321 locators plus the ULID where these applications today carry a single 322 IP address. 324 Carrying the ULID in addition to the list of locators means that the 325 applications is more likely to be able to move to a possible future 326 world where the ULID is not necessarily one of the locators. 328 This requires the definition and implementation of new APIs for the 329 applications to retrieve the set of peer and local locators from the 330 protocol stack, as exemplified in the section above with the made up 331 getpeerlocators() and getmylocators() API calls. But it also 332 requires a mechanism by which the application can pass that 333 information to the protocol stack so that the multi6 protocol layer 334 has all the alternate locators available when establishing 335 communication. Thus we need to study the implications of a 336 setpeerlocators() type of API. 338 Note that the multihoming approach we are discussing, and as a result 339 these recommendations for applications, does not necessarily handle 340 the all the cases of renumbering any better than we handle them today 341 in the IPv4 Internet. For instance, when renumbering the set of 342 locators for a host will change. If a peer retains the set of 343 locators, as long as at least one of those remain valid after the 344 renumbering (and that locator doesn't experience a temporary routing 345 failure), the peer will be able to contact the host. But should all 346 the locators be renumbered, the stale set of locators retained by the 347 peer will be useless. Hence the ULID plus the set of locators will 348 not serve as some long-term stable "identifier" for a host, but they 349 do allow applications to take full advantage of the multiple paths 350 available when multihoming is used. 352 5. ACKNOWLEDGMENTS 354 This document was originally produced of a MULTI6 design team 355 consisting of (in alphabetical order): Jari Arkko, Iljitsch van 356 Beijnum, Marcelo Bagnulo Braun, Geoff Huston, Erik Nordmark, Margaret 357 Wasserman, and Jukka Ylitalo. 359 6. REFERENCES 361 6.1. Normative References 362 6.2. Informative References 364 [M6SHIM] Nordmark, E, and M. Bagnulo, Multihoming L3 Shim Approach, 365 draft-nordmark-multi6dt-shim-00.txt 367 [NSRG] Lear, E., and R. Droms, "What's In A Name: Thoughts from the 368 NSRG", draft-irtf-nsrg-report-09.txt (work in progress), 369 March 2003. 371 [RFC3041] T. Narten and Draves, R, "Privacy Extensions for 372 Stateless Address Autoconfiguration in IPv6", January 2001. 374 [NOID] Erik Nordmark, "Multihoming without IP Identifiers", Oct 27, 375 2003, 377 [ULA] R. Hinden, and B. Haberman, Centrally Assigned Unique Local 378 IPv6 Unicast Addresses, draft-ietf-ipv6-ula-central-00.txt 380 [HIP] Pekka Nikander, "Considerations on HIP based IPv6 multi- 381 homing", 23-Jan-04, 383 AUTHOR'S ADDRESSES 385 Erik Nordmark 386 Sun Microsystems, Inc. 387 17 Network Circle 388 Mountain View, CA 389 USA 391 phone: +1 650 786 2921 392 fax: +1 650 786 5896 393 email: erik.nordmark@sun.com 395 Intellectual Property Statement 397 The IETF takes no position regarding the validity or scope of any 398 Intellectual Property Rights or other rights that might be claimed to 399 pertain to the implementation or use of the technology described in 400 this document or the extent to which any license under such rights 401 might or might not be available; nor does it represent that it has 402 made any independent effort to identify any such rights. Information 403 on the procedures with respect to rights in RFC documents can be 404 found in BCP 78 and BCP 79. 406 Copies of IPR disclosures made to the IETF Secretariat and any 407 assurances of licenses to be made available, or the result of an 408 attempt made to obtain a general license or permission for the use of 409 such proprietary rights by implementers or users of this 410 specification can be obtained from the IETF on-line IPR repository at 411 http://www.ietf.org/ipr. 413 The IETF invites any interested party to bring to its attention any 414 copyrights, patents or patent applications, or other proprietary 415 rights that may cover technology that may be required to implement 416 this standard. Please address the information to the IETF at 417 ietf-ipr@ietf.org. 419 Disclaimer of Validity 421 This document and the information contained herein are provided on an 422 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 423 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 424 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 425 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 426 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 427 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 429 Copyright Statement 431 Copyright (C) The Internet Society (2004). This document is subject 432 to the rights, licenses and restrictions contained in BCP 78, and 433 except as set forth therein, the authors retain all their rights. 435 Acknowledgment 437 Funding for the RFC Editor function is currently provided by the 438 Internet Society.