Network Working Group D. Crocker Internet-Draft Brandenburg InternetWorking Expires: August 9, 2004 A. Doria ETRI February 9, 2004 Framework for Common Endpoint Locator Pools draft-crocker-celp-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 9, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Classic Internet transport protocols use a single source IP Address and a single destination IP Address, as part of the identification for an individual transport data flow. This is problematic for multihomed hosts and for mobile hosts, collectively needing "multiaddressing" support. The basic goal, then, is to find a method for multiaddressing that makes the smallest possible change to the architecture and to current systems, while maintaining flexibility for different emerging solutions. This draft proposes a framework for methods for creating Common Endpoint Locator Pools that can be used by and among the proposed solutions. Crocker & Doria Expires August 9, 2004 [Page 1] Internet-Draft CELP February 2004 Acknowledgment Thanks go to those who participated in the original SLAP discussion, many of whose ideas and words on the list have been borrowed for this draft. The contributors include Brian Carpenter, Spenser Dawkins, Christian Huitema, and Pekka Nikander. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . . 4 2. Basic Proposal . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 Variable Granularity . . . . . . . . . . . . . . . . . . . . . 5 3.2 Security Threats . . . . . . . . . . . . . . . . . . . . . . . 6 3.3 Changes elsewhere in the architecture . . . . . . . . . . . . 6 3.4 Pool synchronization . . . . . . . . . . . . . . . . . . . . . 6 3.5 Endpoint Congestion Management . . . . . . . . . . . . . . . . 6 3.6 Coordination with other efforts . . . . . . . . . . . . . . . 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . 9 Crocker & Doria Expires August 9, 2004 [Page 2] Internet-Draft CELP February 2004 1. Introduction This draft attempts to capture and expand upon the discussion on Shared Locator Address Pool (SLAP) that was held on the Multi6 mailing list. Classic Internet transport protocols use a single source IP Address and a single destination IP Address, as part of the identification for an individual transport data flow. For example, TCP includes these in its definition of a connection and its calculation of the header checksum. Hence a classic transport association is tied to a particular IP Address pair. This is problematic for multihomed hosts and for mobile hosts, collectively needing "multiaddressing" support. Both have access to multiple IP Addresses -- a "pool" of topologically-related locators -- but they are prevented from using more than one within an existing transport exchange. For a host to use a different IP Address pair, participants must initiate a new exchange. In the case of TCP, this means a new connection. In recent years, there have been efforts to overcome many of these limitations, through different approaches at different places in the Internet architecture. Some modify the IP infrastructure, with embedded redirection services. Some define transport enhancements to support a set of locators directly, and some define a layer between classic IP and classic transport. Each of the existing proposals has notable limitations in functionality, implementation, deployment or use. A discussion of the architectural choices and summary of existing multiaddressing projects is in [CHOICE]. The locator schemes offered in these efforts comes in two varieties; transport based and wedge based. In the former, multiaddressing support is made an integral part of a particular transport service. In the wedge based approach, multiaddressing support resides in a functional layer between IP and transport. Transport-based locator-pool schemes ( [SCTP], [DCCP], [TCP-MH] ) multiplex their control exchange in with data traffic. Also, the transport layer can naturally obtain information on the quality of different paths. For example, SCTP can perform measurements across several paths simultaneously, and can then map flows on one or another path. TCP-MH can detect that the current path has stopped working well, for example if the frequency of repetition becomes too high, and can decide to try another path. Wedge-layer approaches ( [HIP], [LIN6], [MAST], [MIP6] ) must conduct their control exchange on a separate logical channel. If a host must do this exchange on a separate channel, with every other host it talks to, the aggregate overhead can be high. Hence transport based schemes have an the potential advantage of saving on number of packets. Crocker & Doria Expires August 9, 2004 [Page 3] Internet-Draft CELP February 2004 On the other hand, wedge based approaches can maintain multiaddressing information across transport associations and can maintain pools with different referential granularity. That is, they can have a pool for all associations between two hosts or they can subdivide into different pools for different activities between the hosts. The logical terminus for these pools with a more narrow scope is called an "endpoint". Hence the next transport activity between two endpoints may well be able to use multiaddressing immediately and with no further administrative overhead. Further, wedge-based locator exchange protocols can be incorporated without necessitating modification to any host's IP or transport modules. Wedge protocols may be invoked at any time, before or during a transport association. A host may initiate and conduct a classic, single IP-pair TCP connection. It may then separately query for remote host support of the wedge protocols and initiate a endpoint locator exchange to be used by that connectivity. Either participant is then free to add or remove endpoint locators. Of course, use of a wedge protocol may instead be performed before a transport context is established, so that future contexts immediately have access to multiple endpoint locators. Because many associations are short, initiation of a wedge protocol can be deferred entirely, choosing to apply it only for persistent associations. The objective of this framework is to permit benefits for all participants. A wedge layer scheme shares "enhanced" transport service's lower-cost locator pool control exchange largess. A transport scheme shares the control exchange the wedge layer has already done, before the transport association is initiated. 1.1 Terminology Work on multiaddressing is forcing significant changes and greater precision, in the use of some common networking terminology. In this document, the term "address" is used in the introduction, for its familiarity, and then is restricted to be part of the label "IP Address", to refer to that protocol's locator values. Similarly use of the term "host" is restricted to refer to the assignee of one or more IP Addresses. For discussing multiaddressing pools, the term "endpoint" is used to refer to a pool with potentially smaller scope. In general, this document takes its terminology from [CHOICE]. 1.2 Discussion Venue Discussion and commentary are encouraged about the topics presented in this document. The preferred forum is the mailing list, for which archives and subscription information are available at . Crocker & Doria Expires August 9, 2004 [Page 4] Internet-Draft CELP February 2004 2. Basic Proposal The basic proposal can be described in the following three propositions: 1. An endpoint runs endpoint Locator Pools (LP) as a resource shared among different consumer services at the endpoint -- for example, a wedge layer service and an enhanced transport service -- potentially with multiple maintainers. LPs might vary in their granularity. Bigger grains makes it more likely that the pool will be shared. A pool that is the finest grain (Connection) can't be shared, of course. 2. A Common Endpoint Locator Address Pool (CELP) capability is used by the different maintenance services, over different communication channels (for example, multiplexed on the transport channel, versus over an independent control channel.) The maintenance services also might use different "configurations", such as peer-to-peer exchange, versus third-party agent mediation. 3. Enhanced transport services access the pool directly. Legacy transport services access the pool via the IP wedge layer service. If an enhanced transport is one of the participants, then there really is no need for a wedge-layer service to conduct an exchange. This saves packets. Hence the wedge layer serves to use the information provided by the transport scheme and apply it to legacy transport and application services. 3. Issues 3.1 Variable Granularity One transport activity may wish (or need) to share its multiaddressing fate with another. Or it may wish to avoid the problems with that sharing, and tolerate the limitations that ensue. These choices can be achieved by having LPs with different scope. At the widest scope, all multiaddressing between a host-pair is shared by all transport associations between them. Hence, the common pool is characterized by: {local, remote} For finer-grained sharing, the pool can be characterized with a variety of additional attributes. For example, and IPv6 flow might be used: {local, remote, flow label} or all activity for a specific application service might share the Crocker & Doria Expires August 9, 2004 [Page 5] Internet-Draft CELP February 2004 pool. This could be characterized by: {local, remote, IP protocol, Well-known port} or a single transport association might wish to have its own pool, as characterized by the classic connection identifier: {local, remote, IP protocol, local port, remote port} 3.2 Security Threats As described in [THREATS] there are redirection threats that may occur when multihoming is used. A CELP solution will need to respond to those threats as well to any exacerbation of DOS and other flooding attacks. 3.3 Changes elsewhere in the architecture In order to support a CELP solution, will other entities in the network need to modified? For example will changes be required in DNS, network management, or trace mechanisms? Additionally, there is the need to determine whether third-party mediation services are required or even warranted. 3.4 Pool synchronization If several protocols are 'maintaining' the pool there arises a concern about synchronization of the state information in the pool. One consideration is the creation of a protocol to maintain CELP state. It is unclear whether this will be necessary. 3.5 Endpoint Congestion Management With a CELP mechanism, the transport may not see the locator information, instead seeing only an identifier. However, differential congestion control is needed at the locator level. This indicates that bringing congestion control into the core of the pool mechanism as part of creating pools may be necessary. 3.6 Coordination with other efforts Given the number of efforts in the IETF at the moment that are suggesting modification to the transport layer and below, it is necessary to coordinate with these efforts. References Crocker & Doria Expires August 9, 2004 [Page 6] Internet-Draft CELP February 2004 [CHOICE] Crocker, D., "Choices for Support of Multiaddressing", draft-crocker-mast-analysis-00.txt (work in progress), Oct 2003. [DCCP] Handley, M., Floyd, S. and J. Padhye, "Datagram Congestion Control Protocol (DCCP)", draft-ietf-dccp-spec-05.txt (work in progress), Oct 2003. [HIP] Moskowitz, R., Nikander, P. and Henderson, "Host Identity Protocol", draft-moskowitz-hip-08.txt (work in progress), Oct 2003. [LIN6] Teraoka, F., Ishiyama, M. and M. Kunishi, "LIN6: A Solution to Mobility and Multi-Homing in IPv6", draft-teraoka-ipng-lin6-02.txt (work in progress), June 2003. [MAST] Crocker, D., "MULTIPLE ADDRESS SERVICE FOR TRANSPORT (MAST): AN EXTENDED PROPOSAL", draft-crocker-mast-proposal-01.txt (work in progress), Sept 2003. [MIP6] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-24.txt (work in progress), June 2003. [SCTP] Stewart, R., Xie, Q., Schwarzbauer, K., Morneault, K., Sharp, C., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960 RFC 2960, Oct 2000. [TCP-MH] Matsumoto, A., Kozuka, M., Fujikawa, K. and Y. Okabe, "TCP Multi-Home Options", draft-arifumi-tcp-mh-00.txt (work in progress), Oct 2003. [THREATS] Nordmark, E. and T. Li, "", draft-nordmark-multi6-threats-00.txt (work in progress), Oct 2003. Crocker & Doria Expires August 9, 2004 [Page 7] Internet-Draft CELP February 2004 Authors' Addresses D. Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale 94086 USA Phone: +1.408.246.8253 EMail: dcrocker@brandenburg.com URI: http://brandenburg.com/ Avri Doria ETRI EMail: avri@acm.org URI: psg.com/~avri Crocker & Doria Expires August 9, 2004 [Page 8] Internet-Draft CELP February 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Crocker & Doria Expires August 9, 2004 [Page 9] Internet-Draft CELP February 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Crocker & Doria Expires August 9, 2004 [Page 10]