idnits 2.17.1 draft-crocker-celp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 9, 2004) is 7380 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) == Outdated reference: A later version (-01) exists of draft-crocker-mast-analysis-00 -- Possible downref: Normative reference to a draft: ref. 'CHOICE' == Outdated reference: A later version (-13) exists of draft-ietf-dccp-spec-05 == Outdated reference: A later version (-09) exists of draft-moskowitz-hip-08 -- Possible downref: Normative reference to a draft: ref. 'HIP' -- Possible downref: Normative reference to a draft: ref. 'LIN6' -- Possible downref: Normative reference to a draft: ref. 'MAST' ** Obsolete normative reference: RFC 2960 (ref. 'SCTP') (Obsoleted by RFC 4960) -- Possible downref: Normative reference to a draft: ref. 'TCP-MH' == Outdated reference: A later version (-02) exists of draft-nordmark-multi6-threats-00 ** Downref: Normative reference to an Informational draft: draft-nordmark-multi6-threats (ref. 'THREATS') Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Crocker 3 Internet-Draft Brandenburg InternetWorking 4 Expires: August 9, 2004 A. Doria 5 ETRI 6 February 9, 2004 8 Framework for Common Endpoint Locator Pools 9 draft-crocker-celp-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 9, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 Classic Internet transport protocols use a single source IP Address 40 and a single destination IP Address, as part of the identification 41 for an individual transport data flow. This is problematic for 42 multihomed hosts and for mobile hosts, collectively needing 43 "multiaddressing" support. The basic goal, then, is to find a method 44 for multiaddressing that makes the smallest possible change to the 45 architecture and to current systems, while maintaining flexibility 46 for different emerging solutions. This draft proposes a framework 47 for methods for creating Common Endpoint Locator Pools that can be 48 used by and among the proposed solutions. 50 Acknowledgment 52 Thanks go to those who participated in the original SLAP discussion, 53 many of whose ideas and words on the list have been borrowed for this 54 draft. The contributors include Brian Carpenter, Spenser Dawkins, 55 Christian Huitema, and Pekka Nikander. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.2 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Basic Proposal . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1 Variable Granularity . . . . . . . . . . . . . . . . . . . . . 5 65 3.2 Security Threats . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.3 Changes elsewhere in the architecture . . . . . . . . . . . . 6 67 3.4 Pool synchronization . . . . . . . . . . . . . . . . . . . . . 6 68 3.5 Endpoint Congestion Management . . . . . . . . . . . . . . . . 6 69 3.6 Coordination with other efforts . . . . . . . . . . . . . . . 6 70 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 72 Intellectual Property and Copyright Statements . . . . . . . . 9 74 1. Introduction 76 This draft attempts to capture and expand upon the discussion on 77 Shared Locator Address Pool (SLAP) that was held on the Multi6 78 mailing list. 80 Classic Internet transport protocols use a single source IP Address 81 and a single destination IP Address, as part of the identification 82 for an individual transport data flow. For example, TCP includes 83 these in its definition of a connection and its calculation of the 84 header checksum. Hence a classic transport association is tied to a 85 particular IP Address pair. This is problematic for multihomed hosts 86 and for mobile hosts, collectively needing "multiaddressing" support. 87 Both have access to multiple IP Addresses -- a "pool" of 88 topologically-related locators -- but they are prevented from using 89 more than one within an existing transport exchange. For a host to 90 use a different IP Address pair, participants must initiate a new 91 exchange. In the case of TCP, this means a new connection. 93 In recent years, there have been efforts to overcome many of these 94 limitations, through different approaches at different places in the 95 Internet architecture. Some modify the IP infrastructure, with 96 embedded redirection services. Some define transport enhancements to 97 support a set of locators directly, and some define a layer between 98 classic IP and classic transport. Each of the existing proposals has 99 notable limitations in functionality, implementation, deployment or 100 use. A discussion of the architectural choices and summary of 101 existing multiaddressing projects is in [CHOICE]. The locator schemes 102 offered in these efforts comes in two varieties; transport based and 103 wedge based. In the former, multiaddressing support is made an 104 integral part of a particular transport service. In the wedge based 105 approach, multiaddressing support resides in a functional layer 106 between IP and transport. 108 Transport-based locator-pool schemes ( [SCTP], [DCCP], [TCP-MH] ) 109 multiplex their control exchange in with data traffic. Also, the 110 transport layer can naturally obtain information on the quality of 111 different paths. For example, SCTP can perform measurements across 112 several paths simultaneously, and can then map flows on one or 113 another path. TCP-MH can detect that the current path has stopped 114 working well, for example if the frequency of repetition becomes too 115 high, and can decide to try another path. Wedge-layer approaches ( 116 [HIP], [LIN6], [MAST], [MIP6] ) must conduct their control exchange 117 on a separate logical channel. If a host must do this exchange on a 118 separate channel, with every other host it talks to, the aggregate 119 overhead can be high. Hence transport based schemes have an the 120 potential advantage of saving on number of packets. 122 On the other hand, wedge based approaches can maintain 123 multiaddressing information across transport associations and can 124 maintain pools with different referential granularity. That is, they 125 can have a pool for all associations between two hosts or they can 126 subdivide into different pools for different activities between the 127 hosts. The logical terminus for these pools with a more narrow scope 128 is called an "endpoint". Hence the next transport activity between 129 two endpoints may well be able to use multiaddressing immediately and 130 with no further administrative overhead. Further, wedge-based locator 131 exchange protocols can be incorporated without necessitating 132 modification to any host's IP or transport modules. Wedge protocols 133 may be invoked at any time, before or during a transport association. 134 A host may initiate and conduct a classic, single IP-pair TCP 135 connection. It may then separately query for remote host support of 136 the wedge protocols and initiate a endpoint locator exchange to be 137 used by that connectivity. Either participant is then free to add or 138 remove endpoint locators. Of course, use of a wedge protocol may 139 instead be performed before a transport context is established, so 140 that future contexts immediately have access to multiple endpoint 141 locators. Because many associations are short, initiation of a wedge 142 protocol can be deferred entirely, choosing to apply it only for 143 persistent associations. 145 The objective of this framework is to permit benefits for all 146 participants. A wedge layer scheme shares "enhanced" transport 147 service's lower-cost locator pool control exchange largess. A 148 transport scheme shares the control exchange the wedge layer has 149 already done, before the transport association is initiated. 151 1.1 Terminology 153 Work on multiaddressing is forcing significant changes and greater 154 precision, in the use of some common networking terminology. In this 155 document, the term "address" is used in the introduction, for its 156 familiarity, and then is restricted to be part of the label "IP 157 Address", to refer to that protocol's locator values. Similarly use 158 of the term "host" is restricted to refer to the assignee of one or 159 more IP Addresses. For discussing multiaddressing pools, the term 160 "endpoint" is used to refer to a pool with potentially smaller scope. 161 In general, this document takes its terminology from [CHOICE]. 163 1.2 Discussion Venue 165 Discussion and commentary are encouraged about the topics presented 166 in this document. The preferred forum is the 167 mailing list, for which archives and 168 subscription information are available at . 171 2. Basic Proposal 173 The basic proposal can be described in the following three 174 propositions: 176 1. An endpoint runs endpoint Locator Pools (LP) as a resource shared 177 among different consumer services at the endpoint -- for example, 178 a wedge layer service and an enhanced transport service -- 179 potentially with multiple maintainers. LPs might vary in their 180 granularity. Bigger grains makes it more likely that the pool 181 will be shared. A pool that is the finest grain (Connection) 182 can't be shared, of course. 183 2. A Common Endpoint Locator Address Pool (CELP) capability is used 184 by the different maintenance services, over different 185 communication channels (for example, multiplexed on the transport 186 channel, versus over an independent control channel.) The 187 maintenance services also might use different "configurations", 188 such as peer-to-peer exchange, versus third-party agent 189 mediation. 190 3. Enhanced transport services access the pool directly. Legacy 191 transport services access the pool via the IP wedge layer 192 service. If an enhanced transport is one of the participants, 193 then there really is no need for a wedge-layer service to conduct 194 an exchange. This saves packets. Hence the wedge layer serves to 195 use the information provided by the transport scheme and apply it 196 to legacy transport and application services. 198 3. Issues 200 3.1 Variable Granularity 202 One transport activity may wish (or need) to share its 203 multiaddressing fate with another. Or it may wish to avoid the 204 problems with that sharing, and tolerate the limitations that ensue. 205 These choices can be achieved by having LPs with different scope. 206 At the widest scope, all multiaddressing between a host-pair is 207 shared by all transport associations between them. Hence, the common 208 pool is characterized by: 210 {local, remote} 212 For finer-grained sharing, the pool can be characterized with a 213 variety of additional attributes. For example, and IPv6 flow might be 214 used: 216 {local, remote, flow label} 218 or all activity for a specific application service might share the 219 pool. This could be characterized by: 221 {local, remote, IP protocol, Well-known port} 223 or a single transport association might wish to have its own pool, as 224 characterized by the classic connection identifier: 226 {local, remote, IP protocol, local port, remote port} 228 3.2 Security Threats 230 As described in [THREATS] there are redirection threats that may 231 occur when multihoming is used. A CELP solution will need to respond 232 to those threats as well to any exacerbation of DOS and other 233 flooding attacks. 235 3.3 Changes elsewhere in the architecture 237 In order to support a CELP solution, will other entities in the 238 network need to modified? For example will changes be required in 239 DNS, network management, or trace mechanisms? Additionally, there is 240 the need to determine whether third-party mediation services are 241 required or even warranted. 243 3.4 Pool synchronization 245 If several protocols are 'maintaining' the pool there arises a 246 concern about synchronization of the state information in the pool. 247 One consideration is the creation of a protocol to maintain CELP 248 state. It is unclear whether this will be necessary. 250 3.5 Endpoint Congestion Management 252 With a CELP mechanism, the transport may not see the locator 253 information, instead seeing only an identifier. However, differential 254 congestion control is needed at the locator level. This indicates 255 that bringing congestion control into the core of the pool mechanism 256 as part of creating pools may be necessary. 258 3.6 Coordination with other efforts 260 Given the number of efforts in the IETF at the moment that are 261 suggesting modification to the transport layer and below, it is 262 necessary to coordinate with these efforts. 264 References 266 [CHOICE] Crocker, D., "Choices for Support of Multiaddressing", 267 draft-crocker-mast-analysis-00.txt (work in progress), Oct 268 2003. 270 [DCCP] Handley, M., Floyd, S. and J. Padhye, "Datagram Congestion 271 Control Protocol (DCCP)", draft-ietf-dccp-spec-05.txt 272 (work in progress), Oct 2003. 274 [HIP] Moskowitz, R., Nikander, P. and Henderson, "Host Identity 275 Protocol", draft-moskowitz-hip-08.txt (work in progress), 276 Oct 2003. 278 [LIN6] Teraoka, F., Ishiyama, M. and M. Kunishi, "LIN6: A 279 Solution to Mobility and Multi-Homing in IPv6", 280 draft-teraoka-ipng-lin6-02.txt (work in progress), June 281 2003. 283 [MAST] Crocker, D., "MULTIPLE ADDRESS SERVICE FOR TRANSPORT 284 (MAST): AN EXTENDED PROPOSAL", 285 draft-crocker-mast-proposal-01.txt (work in progress), 286 Sept 2003. 288 [MIP6] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support 289 in IPv6", draft-ietf-mobileip-ipv6-24.txt (work in 290 progress), June 2003. 292 [SCTP] Stewart, R., Xie, Q., Schwarzbauer, K., Morneault, K., 293 Sharp, C., Taylor, T., Rytina, I., Kalla, M., Zhang, L. 294 and V. Paxson, "Stream Control Transmission Protocol", RFC 295 2960 RFC 2960, Oct 2000. 297 [TCP-MH] Matsumoto, A., Kozuka, M., Fujikawa, K. and Y. Okabe, "TCP 298 Multi-Home Options", draft-arifumi-tcp-mh-00.txt (work in 299 progress), Oct 2003. 301 [THREATS] Nordmark, E. and T. Li, "", 302 draft-nordmark-multi6-threats-00.txt (work in progress), 303 Oct 2003. 305 Authors' Addresses 307 D. Crocker 308 Brandenburg InternetWorking 309 675 Spruce Drive 310 Sunnyvale 94086 311 USA 313 Phone: +1.408.246.8253 314 EMail: dcrocker@brandenburg.com 315 URI: http://brandenburg.com/ 317 Avri Doria 318 ETRI 320 EMail: avri@acm.org 321 URI: psg.com/~avri 323 Intellectual Property Statement 325 The IETF takes no position regarding the validity or scope of any 326 intellectual property or other rights that might be claimed to 327 pertain to the implementation or use of the technology described in 328 this document or the extent to which any license under such rights 329 might or might not be available; neither does it represent that it 330 has made any effort to identify any such rights. Information on the 331 IETF's procedures with respect to rights in standards-track and 332 standards-related documentation can be found in BCP-11. Copies of 333 claims of rights made available for publication and any assurances of 334 licenses to be made available, or the result of an attempt made to 335 obtain a general license or permission for the use of such 336 proprietary rights by implementors or users of this specification can 337 be obtained from the IETF Secretariat. 339 The IETF invites any interested party to bring to its attention any 340 copyrights, patents or patent applications, or other proprietary 341 rights which may cover technology that may be required to practice 342 this standard. Please address the information to the IETF Executive 343 Director. 345 Full Copyright Statement 347 Copyright (C) The Internet Society (2004). All Rights Reserved. 349 This document and translations of it may be copied and furnished to 350 others, and derivative works that comment on or otherwise explain it 351 or assist in its implementation may be prepared, copied, published 352 and distributed, in whole or in part, without restriction of any 353 kind, provided that the above copyright notice and this paragraph are 354 included on all such copies and derivative works. However, this 355 document itself may not be modified in any way, such as by removing 356 the copyright notice or references to the Internet Society or other 357 Internet organizations, except as needed for the purpose of 358 developing Internet standards in which case the procedures for 359 copyrights defined in the Internet Standards process must be 360 followed, or as required to translate it into languages other than 361 English. 363 The limited permissions granted above are perpetual and will not be 364 revoked by the Internet Society or its successors or assignees. 366 This document and the information contained herein is provided on an 367 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 368 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 369 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 370 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 371 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 373 Acknowledgment 375 Funding for the RFC Editor function is currently provided by the 376 Internet Society.