Network Working Group D. Crocker Internet Draft Brandenburg draft-crocker-multiaddr-analysis-01.txt InternetWorking 12dc.doc October 19, 2003 Expires: <4-04> CHOICES FOR MULTIADDRESSESING 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. COPYRIGHT NOTICE Copyright (C) The Internet Society (2003). All Rights Reserved. ABSTRACT An IP Address serves the dual roles as references to a "place" on the Internet and to a host on the Internet, labeled "locator" and "identifier", respectively. Systems that use IP Addresses as identifiers cannot support dynamic changes in the mapping between the identifier and the locator. For a system 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 this limitation, through different approaches at different places in the Internet architecture. This paper reviews the basic requirements for support of multiaddressing (mobility and multihoming), and the efforts to support them. Barriers to adoption, administrative overhead, and operational efficiency are of particular concern. CONTENTS 1. Introduction 1.1. Scenarios 1.2. IETF Background 1.3. Discussion Venue 1.4. Document History 2. Terminology 2.1. Recommended 2.2. Deprecated 3. Considerations 3.1. Mobility 3.2. Multihoming 3.3. Security 3.4. Implementation 3.5. Deployment and Use 3.6. Matters of State 3.7. Endpoint Identifiers 3.8. Signaling 3.9. Operation Through NATs 4. Internet Stack Placement Proposals 4.1. IP Infrastructure 4.2. Transport-Level 4.3. Session-Level 4.4. Application-Level 4.5. IP Endpoint 5. Security Considerations Appendix A.1. Acknowledgements A.2. References A.3. Author's Adress A.4. Full Copyright Statement 1. INTRODUCTION "We need a way for sites to be internally stable even when their relationship to the world around them changes for whatever reason." -- E. Lear An IP Address serves as references to a "place" on the Internet and to a host on the Internet. These two roles are generally labeled "locator" and "identifier", respectively. Systems that use IP Addresses as identifiers typically cannot support dynamic changes in the mapping between the identifier and the locator. For example, TCP includes a single source/destination IP Address pair in its definition of a connection. Hence its transport association is tied to that pair. This is problematic for hosts that are multihomed or mobile. Both have access to multiple IP Addresses, but they are prevented from using more than one within an existing context, because the context is named by that pair. For a system 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 this limitation, through different approaches at different places in the Internet architecture. Some approaches 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. The primary goal of these multiaddressing efforts is to preserve established connections when an IP Address changes. Each of the existing proposals has notable limitations in functionality, implementation, deployment or use. This paper reviews the basic requirements for support of multiaddressing (mobility and multihoming), and the efforts to support them. Barriers to adoption, administrative overhead, and operational efficiency are of particular concern. In addition, the analysis considers enhanced functionality that is possible from the use of multiaddressing, such as performance-based load- sharing, across the different locators available to a multihomed host. 1.1. Scenarios What are the situations and concerns that affect design and use of a mechanism for the support of multiaddressing? Section 3 of [MOBMH], has an excellent discussion of these issues. It is included here by reference without section 3.2. Section 3.2 covers an interesting topic that appears to be independent of multiaddressing. The included text comprises the following sub- sections: 3. Usage scenarios 3.1 End-host mobility 3.2 Location privacy à 3.3 End-host multi-homing 3.4 Site multi-homing 3.5 Combined mobility and multi-homing 3.6 Network renumbering 3.7 Combined all 1.2. IETF Background Historically, IETF focus on mobility has split between initial attachment configurations, into an otherwise static environment such as by using DHCP, versus forwarding mechanisms, such as by modifying the IP infrastructure with Mobile IP. Multihoming has largely been ignored, except in routing protocol work. Recent efforts are pursuing direct enhancements to transport or insertion of a mapping layer between IP and transport. There has also been adjunct activity, relevant to this topic. The following summary of IETF activities draws on text from the Abstracts of documents for those activities. In addition, there is a useful analysis of the different architectural and protocol efforts is in Section 3, "Internet Stack Placement" in [NSRG]. Specification efforts are discussed in more detail in Section The Name Space Research Group [NSRG] considered modifications to the Internet architecture, including whether an additional level of naming is needed, above layer 3 but below the application layer. Purpose-Built Keys [PBK] specifies a template for the use of specially generated public/private key pairs, to provide assurance that successive messages in the communication come from the same source. This is accomplished without the use of external certification authorities. Hence it ensures authentic continuity during a session, but does not provide "global" or "absolute" authentication. Stream Control Transmission Protocol [SCTP] is a reliable transport protocol for multiplexed data streams. It includes modern mechanisms for safe initiation of a connection, as well as the necessary tools for reliability and congestion control. It also has a mechanism for communication access to multiple IP Addresses between the participation host pair. [TCP-MH] uses TCP options to support multihoming. Datagram Congestion Control Protocol [DCCP] is a proposal for a network-friendly, unreliable transport-level datagram delivery service. Mobile IP work has divided between IPv4 and IPv6. [MIP4] and [MIP6] allow a node to continue using its "permanent" home address as it moves around the internet. Host Identity Protocol [HIP] is used to establish a rapid authentication between two hosts and to provide continuity of communications between those hosts independent of the networking layer. The [LIN6] protocol defines a layer that supports multiple locators, between IPv6 and transport. Multiple Address Service for Transport [MAST] supports association of multiple IP Addresses during the life of any transport instantiation, by defining a layer between IP and transport. It operates only in the endpoints and works with IPv4 and IPv6. 1.3. Discussion Venue Discussion and commentary are encouraged about the topics presented in this document. The preferred forum is the <mailto:multi6@ops.ietf.org> mailing list, for which archives and subscription information are available at <http://ietf.org/html.charters/multi6-charter.html>. NOTE: The early drafts of a review document, like this, are certain to have significant errors. The author strongly requests guidance for clarifying and correcting any problematic text. In particular, those working on the proposals and specifications discussed here are encouraged to provide corrections and additional text, to ensure accuracy. 1.4. Document History -00 Derived from draft-crocker-mast-proposal-00. Extended discussions about alternative proposals and architectural issues, separated from the - proposal- draft. -01 Substantial revisions to all sections. More complete review of efforts. More extensive terminology definitions. Section 3 renamed to "Considerations". Material that evaluates proposals is moved out of it, to the next section. Later versions need cleaner separation of topics, such as requirements and definition of what multi- addressing support really means in different situations. Need to add a chart that compares the proposals. Need to incorporate the remainder of Marcelo's suggested changes. Need to discuss enhancements made possible by multiaddressing support. NOTE: D. Crocker has put forward the MAST proposal. That may have colored the perspectives in this discussion paper. 2. TERMINOLOGY This paper discusses requirements and methods for enabling an endpoint to use multiple locators during single application associations. This topic does not yet have a stable, core set of terms in general use. The following definitions are intended to remedy that deficiency; they are taken from existing definitions, when available. Work on multiaddress enhances existing infrastructure capabilities. This work is uncovering ambiguities to terms that have been used. For multiaddressing, it is therefore confusing to use some common terms, notably "address". Hence they SHOULD NOT be used. 2.1. Recommended Agent refers to a third-party that is handling something on behalf of one or more other parties. The term indicates the separateness of the entity, as well as its key relationship to the other entities. In multiaddressing, it refers to an intermediary service that represents an endpoint, for the purposes of referral and/or relaying. Association refers to an established communication context between endpoints, such as a TCP connection. Endpoint refers to "the fundamental agent of end-end communication" [EID]. It is an end-system that participates in an association. Endpoints are distinguished from intermediate, infrastructure nodes and hosts. Identifier refers to a unique label for an endpoint. The label is used simply for distinguishing one endpoint from another. Because a locator is usually globally unique, it might be able to serve as an identifier. However this use will often suffer administrative and referential limitations as a global identifier for mobile endpoints. This is exemplified by the current problems experienced with the dual role of IP Addresses. Initiator refers to an endpoint that initiates contact with a target endpoint. In client/server architecture it is the client. IP Address specifies a topological network access point. The term is usually considered to specify an endpoint interface. However discussions about mobility are notably clarified by viewing the value as belonging to the network (interface) rather than to the endpoint. Locator refers to a "the name of a network attachment point" [SALT], usually in terms of the network's topology. Locators typically facilitate mapping into routes, such as by indicating a topological hierarchy. IP Addresses specify a topological network access point. They usually are considered to specify an endpoint interface. However discussions about mobility are enhanced by viewing the value as belonging to the network (interface) rather than to the endpoint. Mobility refers to an endpoint's having different locators over time. This may even include discontinuities, during which an endpoint has no valid locators. In addition, the nature of a transition from one locator to another may include overlapping availability of locators. Interestingly, this looks the same as multihoming. Mobility may be for a single endpoint or for the subnetwork to which the endpoint is attached. In the latter case, the endpoint connection is stable, with respect to its sub-network, but the sub-network propogates connectivity change information to the endpoint. Multiaddressing refers to an endpoint's having more than one locator available, over the lifetime of an association. It encompasses both multihoming and mobility. The core requirement for multiaddressing is preservation of established communications, across the use of different locators. Multihoming refers to the availability of multiple endpoint locators at the same endpoint, simultaneously. It is typically used to refer to multiple network attachments for a host, but works equally well for multiple upstream network attachments by the local network, when the different upstream locators are visible to the host. Interestingly, multihomed environments often must support dynamic changes, such as when adding a new upstream provider. Therefore, multihoming can include mobility features and mobility can include multihoming features. When needing to renumber a network, due to changes in up- stream service, the process can be operated as dynamic multihoming. Path discovery provides a sender with the means for learning about the locators from which they can send. Path selection is required when more than one locator is available to the sender. Although the sender is limited to specifying an locator, rather than a path, it appears that thinking of it as path selection aids consideration of solutions. In effect, it formulates the selection task as being similar to the job of routers. Route formulation is mature technology, so that this aspect of multiaddress processing will be tractable, if not straightforward. Referral permits an initiator to obtain a locator for a target, such as a client being referred to a server. A third-party process is required for referral, in the absence of an association. For existing associations, participating endpoints might be able to supply their own referrals. The primary Internet mechanism for referral has been the Domain Name Service (DNS). The DNS uses long, variable-length strings (names) and is tailored for large-scale referral with identifiers and locators (mappings) that change infrequently. Referral Agent refers to the function that maintains the mapping between a mobile node's identifier and its locator(s). [LIN6] calls this a Mapping Agent. Rehoming refers to an endpoint's changing an association from one locator to another, Relaying refers to the redirection of packets, on behalf of an endpoint. Other endpoints see a stable locator for the endpoint obtaining the relaying service. Relaying Agent refers to an agent that performs packet forwarding (relaying) on behalf of an endpoint. The Relaying Agent thereby persents a stable locator to the Internet, for the endpoint. For mobility, the agent resides on an endpoint's "home" network and relays datagrams to the endpoint's actual location on the Internet. The endpoint is modified to support this forwarding technique. Rendezvous refers to one endpoint making contact with an explicitly identified other endpoint. Target refers to an endpoint that receives contact from an Initiator endpoint. In a client/server architecture, this is the server. 2.2. Deprecated Address Refers to "the name of some network attachment point." [SALT] The term has become a problematic because addresses often are used for two, distinct functions. Hence the term should not be used by itself, for these discussions, except with reference to particular protocol specifications, such as "IP Address". Instead, use "identifer" and "locator", as appropriate. Connection A state of association between two endpoints. Because the term is typically used for to refer to transport-layer state, discussions about multiaddressing should use the more general term "association", except with reference to particular protocol specification, such as "TCP Connection". 3. CONSIDERATIONS The core requirement for multiaddressing is continuity of access within an association. However applications having this as a compelling requirement have not yet been evident on the Internet. Hence there ius some risk that proposed mechanisms to solve the requirement will not correctly ancitipate the details of the requirement. This section is a general discussion of requirements, constraints and concerns. It does not attempt to offer a formal set of requirements or recommendations. 3.1. Mobility Mobility is time-varying access to multiple locators for the same endpoint. Key parameters to mobility are scope of change, rate of change and source(s) of the change. Over what portion of the Internet topology might a change take place; how often will changes occur; and which of the participants will change their locators? 3.1.1. Rapid, Local Initiators It is generally accepted that rapid, local changes should be handled by a layer below IP. These changes are therefore invisible to IP and above, so that associations are automatically preserved across change. 3.1.2. Rare, Distant Initiators For initiator endpoints that are subject to occasional detachment and eventual reconnection, the current set of technologies is probably sufficient. These require reconfiguration, such as through DHCP, and establishing new associations. Applications wishing to retain association state, across these transitions, do so above the transport layer. They are capable of establishing new transport associations, as needed. 3.1.3. Periodic, Moderate What is missing from the operational Internet is support for initiator and target systems that move over the course of minutes or hours and need to maintain existing transport associations or need to maintain their availability for new associations. The difference between mobility prior to initial contact and mobility during an existing association is significant. In the latter case, the mobile host can use the association state when needing to inform the other endpoint about the change. Prior to an association -- or when both endpoints are mutually mobile -- an independent referral service is required. The difference between initiator mobility and target mobility is also significant, with respect to initial contact. In particular the initiator needs to be able to obtain a valid locator for the target. Again, this requires a referral mechanism, such as having the routing system map from identifiers to routes, rather than locators to routes. Either it must be provided implicitly within the network or there must be an external "referral" mechanism. For static servers, the DNS already provides this referral quite well. However current DNS use does not support frequent locator changes over short periods. Hence enhancements are needed to support referral with a mobile target. 3.2. Multihoming The Internet already supports a number of types of "indirect" multihoming. 3.2.1. Infrastructure The core of dynamic packet-switched routing entails exploitation of alternative routes, so that the path between endpoints might vary considerable over the course of an association. 3.2.2. Site For networks with multiple attachments to a backbone, external routing technology already permits propagation of alternate routing information. However it does not make these alternatives visible to endpoints. Further a domain name may have multiple locator records that point to the same network. However there is no indication whether the same records are, instead, pointing to different, redundant systems; on the other hand the importance of this ambiguity is not clear. 3.2.3. Endpoint What is notably missing is a means for an existing association to directly use multiple paths, in particular when the paths terminate at one of the endpoints. Here, the fact that classic Internet transport services rely on single, specific IP Addresses is the barrier. Endpoint support of multihoming can be useful for robustness and throughput. The former makes loss of a path transparent to the association. The latter increases the effective bandwidth for an association. In general, the former goal is dominating current work. At the least, using multiple paths for increased bandwidth ensures a high degree of out-of-order arrivals. This usually reduces target endpoint performance, rather than increasing it. 3.3. Security The level of security built into IP is minimal. Some would say it is non-existent. However, classic transport services rely on having a significant degree of correlation between the IP Address in the source field of an IP datagram and the likelihood that the IP datagram came from that locator. The context of repeated exchanges between source and destination locators is taken as a validation of this correlation. Permitting the IP Address of a source to vary during an association is an invitation to connection hijacking, and related attacks. Hence, any support for multiple locators within an association must contain a strong anti-hijacking mechanism. All other security concerns are independent of multiaddressing. They may already be handled by additional mechanisms, such as [IPSec] and [TLS]. There is no indication that any of these other mechanisms need to be changed, to support multiaddressing. Once there is an effort to design protection against hijacking, it is easy to consider adding more protections, such as privacy or, perhaps, other kinds of authentication. Although such mechanisms obviously would be useful, they are not essential to the basic requirements of multiaddressing. Further, they might be redundant with mechanisms provided elsewhere in the architecture. Any effort related to multiaddress support, which goes beyond preventing hijacking, needs to have explicit discussion about its relationship to other security mechanisms and the need for attaching these additional capabilities to multiaddress support. As with any opportunity for adding features to a design effort, there should be concern about causing unnecessary design complexity, delays to the specification effort, and difficulty in implementation. 3.4. Implementation The software that supports IP and classic transport services is mature. Usually it is highly tuned and highly robust. Often it is also complex. Hence it can be risky to introduce modifications to one or more of these modules. On the other hand, attempting to introduce multiaddress support through additional modules runs the risk of being awkward and inefficient. 3.5. Deployment and Use However difficult it is to have vendors make major modifications to mature software, it is far more difficult to deploy the changes to a global, installed base of hundreds of millions of platforms. Changes to support multiaddressing need to consider barriers to adoption by users and operators, both ISPs and enterprises. What is the effort needed to deploy the changes? What is the effort needed to use it? How broad must the adoption be before users can obtain benefit? What dependencies do the changes have on existing or new services? Making one new service depend upon the reliable performance of another new service greatly increases the riskiness of the effort. Making a change require modification to the Internet's infrastructure typically creates a long delay before it is useful. In particular, early adopters of the mechanism gain no immediate benefit from their efforts; this acts as a disincentive for adoption. Everyone waits for others to take the first step. 3.6. Matters of State Support for multiple locators requires adding a conceptual layer of referential indirection. Beyond simple use of the DNS, endpoints currently use individual endpoint locators within an association. In order to use multiple locators, to refer to the same endpoint, some type of aggregation and mapping mechanism must be added. The mechanism defines a relationship between the referenced endpoint and a set of locators. Where should this state information be placed in the Internet architecture? If the major lesson of the Internet is scaling, the major embodiment of that lesson is to place complexity in the edges, rather than the infrastructure. Generally, this does not mean that there is a balanced debate between the choices. Rather, there is an assumption that a change should be made to the edges rather than the infrastructure. It is made in the infrastructure only when there is a clear agreement that doing otherwise will seriously reduce the utility of the change. This methodology can even be applied to some infrastructure changes. A change that will clearly have an infrastructure impact might be introduced incrementally, via endpoint modifications. Two major examples of this are DNS and MIME. Both were added to operational, infrastructure services -- the IP Internet and the Internet Mail service, respectively -- but were added in a fashion that made no immediate changes to existing services. Rather, edge systems independently chose to adopt the changes. Any two endpoints wishing to exploit the change, for interacting with each other, immediately benefited from the adoption. Over time, adoption became sufficiently broad-based to make the change effectively part of the infrastructure service. Although the IP network works well without the DNS, end-user utility of the Internet, without the DNS, would be nil. Similarly the ability to use attachments has become a fundamental part of the Internet Mail experience. Addition of support for multiaddressing faces a similar type of choice. Should the change be made above the transport layer, in the transport layer, in the IP layer, or perhaps between IP and transport? How is the aggregation established and how is it maintained? Do IP (or TCP, or...) packets contain the mappings or are they maintained in the endpoints or, perhaps, in the IP infrastructure? The answers to these questions need to be determined by their effect on barriers to adoption, operational overhead, and administrative convenience. 3.7. Endpoint Identifiers Historically, IP Addresses have served the dual role of network interface locator and endpoint identifier (EID). Adding support for multiaddressing serves to highlight the need for splitting these two roles. IP Addresses work quite well as network interface locators. However their topological dependence makes them work poorly as identifiers, in the richer world of multiaddressing. Does an EID need to be assigned by a registry or can it be dynamically computed? Does it need to be publicly visible across the Internet or can it be kept private to individual associations? Does it need to be used frequently, such as in every datagram, or is it needed only for specific transactions, such as initiating or recovering an association? It is appealing to define an EID to be publicly registered and carried in every datagram. This provides the maximum amount of decoupling from locatoring and appears to offer an especially clean modification to the transport layer interface. Transport header calculation "merely" needs to switch to use of the EID, rather than the locator. With sufficiently strong protection against hijacking, this approach probably will make the locator irrelevant to the transport layer. However there still must be a mapping between EID and locators, so the IP service knows where to send the datagram. Hence, the state information of an EID/locator "routing table" must reside somewhere. Unless the IP infrastructure is modified to support EIDs directly, this state information is most probably in the endpoints. Having a public EID means that a new, global registration service must be developed and operated. Some believe network operators will not mind this additional work; others disagree. Having an EID in every datagram means that the string must be as short as possible. Even then it will add significant overhead to datagram header size. However given the need to process multiaddressing, having the EID in every datagram probably will not alter datagram processing overhead, in the endpoints, from any other approach to using EIDs. If an EID is used only occasionally, one candidate is a domain name. Domain names already have an administrative structure, and they are well engrained into Internet use. Their length is not a problem, when they are need only periodically. One objection to using domain names is that they are already used in a number of ways that do not suit the role of EID. It is unclear how the fact that domain names serve multiple roles prevents their serving the role of EID. One observation is that the ability of a domain name to map to multiple IP Addresses makes it problematic to ensure that the name will later map to the same IP Address as was initially selected. At the least, resolution of this concern requires careful specification and even more careful administration. 3.8. Signaling How does an endpoint learn its own locators, so that it can inform another endpoint, during an association? The notable challenge is when a NAT modifies the locator an endpoint uses directly, to a different locator that is visible to the rest of the network. How does an endpoint communicate that available set of locators to another endpoint? DNS is currently useful for registering essentially static sets. More dynamic or tailored communication requires a signaling exchange between endpoints. This can be done through a distinct signaling protocol, such as is done with [MAST], or inline -- that is, as a sub-exchange -- within an existing protocol, such as is done with [TCP-MH]. 3.9. Operation Through NATs A Network Locator Translation [NAT] device maps between one set of locators, and another. In typical cases, locators from the interior of a network are mapped to different ports on a single, public locator on the outside of the network. This mapping task must be performed with knowledge of transport protocol details because it must adjust transport headers, as well as IP-level locators. Stateless NATs are likely to work with most multihoming solutions and some mobility solutions. The NAT will simply do its usual task of replacing IP Addresses and adjusting dependent headers of common transport protocols, accordingly. However, there is the basic question of whether a multiaddressed initiator correctly knows its own locators. Typically it will not. Given the prevalence of NATs, a solution to multiaddressing needs to deal with this scenario. Some solutions require that NATs be upgraded to support the solution. This is another example of an infrastructure dependency. 4. INTERNET STACK PLACEMENT PROPOSALS From a purely technical standpoint, multiAddressesing can be supported through a number of different mechanisms. This section discusses the possible venues within the Internet stack, and existing efforts that are pursuing these choices. The current architecture for transport use of IP Addresses makes a direct linkage to a specific IP Addresses pair: Connection (IP.a, Port.l, IP.y, Port.r) +-------------------+ | Port.l | Port.r +---+---+ +---+---+ | TCP | | TCP | +---+---+ +---+---+ | IP.a | IP.y +---+---+ +---+---+ | IP | | IP | +-+---+-+ +-+---+-+ | | | | IP.a IP.f IP.q IP.y This example shows each host being multihomed. However a given association must choose a single IP Addresses, at each end, and bind the connection to it. 4.1. IP Infrastructure In the classic Internet infrastructure model, a datagram contains topological references to the source and destination network interfaces. The network knows nothing about higher-level issues, such as whether two interfaces are attached to the same endpoint. This design derives from the explicit desire to keep the Internet infrastructure as simple as possible, by putting as much functionality as possible into the endpoints rather than in the Internet's switching devices. Connection (IP.f, Port.l, IP.q, Port.r) +--------------------------+ | Port.l | Port.r +---+---+ +---+---+ | TCP | | TCP | +---+---+ +---+---+ | IP.f | +---+---+ | | IP-ES | | +---+---+ | IP.a| | +---+---+ +-------+ +---+---+ | IP-IS | | Agent | | IP-IS | +---+---+ +---+---+ +---+---+ | | | +------------+-------------+ IP.a IP.f IP.q 4.1.1. Dynamic DNS For maintaining target availability during an association, DNS dynamic update [DNSDYN] is a plausible mechanism to obtain new locator information. Although this would probably not be helpful for transitions during an association, it could suffice for referrals to establish initial rendezvous. However it is not widely deployed and the typical DNS record lifetime settings and client caching behaviors suggest that existing DNS use is better tailored for changes over days, rather than hours. Separately the core role of DNS for Internet infrastructure operations suggests avoiding major changes to its operational model. Supporting potentially high volumes of rapid changes probably require very different software and administration than are used for the current DNS. 4.1.2. MIP The Mobile IP [MIP4, MIP6] efforts provide an encapsulation-based forwarding service. A "home" relaying agent intercepts datagrams using an original destination IP Addresses, and then forwards the datagram to the target's current IP Addresses. An optimization supported in the IPv6 version permits direct transmission to the new venue, if initial use of the home agent. The encapsulation tunnels the original IP datagram inside a new one. Direct exchanges carry both locator and endpoint identifier values. [HOWIE] provides an interesting discussion of MIPv6 adoption and use issues. A major benefit to this approach is that use of the home agent requires no direct support by the non-mobile endpoint. A multiaddressed endpoint must be modified to support this capability, but the other side of an association need not be modified. This places the requirement for change onto systems with the incentive to use it. Conceptually, the biggest problem with this approach is that it attempts to take topology-related information -- the IP Addresses -- and use it as the basis for contacting an endpoint non- topologically. Operationally, the biggest problems with this approach are that it requires adoption by an infrastructure service, and forwarding services are inefficient and often complex. This approach changes the infrastructure and changes the IP datagram. Hence it changes multiple, different aspects of the Internet architecture, with each change potentially constituting a significant barrier to adoption, reliability or efficiency. 4.2. Transport-Level Recent transport protocols, such as [SCTP], [TCP-MH] and the proposal for [DCCP], use multiple IP Addresess directly in the transport association. These efforts have primarily focused on multihoming, with the time-varying nature of mobility being ignored or retrofitted.TCP-MH notably uses TCP options for inline signaling of multihoming information between the endpoints; its current specification appears to have weak protection against hijacking but this can be remedied. A transport-level approach has the benefit of placing the necessary functionality only in end-systems and avoiding possible locators translation problems. It also has the considerable benefit of leaving the IP infrastructure unchanged. Given the complexity and robustness of that infrastructure, as well as the considerable time and effort that was needed to achieve its stability, any design that avoids changing the infrastructure is to be commended. Connection (IP.?, Port.l, IP.?, Port.r) +--------------------------+ | Port.l | Port.r +- --+----+ +-- -+----+ | TCP | | TCP | +---+-+---+ +---+-+---+ IP.a | | IP.f IP.q | | IP.y +---+-+---+ +---+-+---+ | IP | | IP | +--+---+--+ +--+---+--+ | | | | | | | | IP.a IP.f IP.q IP.y The fact that the functionality is applicable across all transport services suggests that there might be benefit in having IP multiAddressesing functionality reside in a single architectural module, separate from any specific transport service. In any case these new transport protocol efforts cannot affect the considerable installed base of services using older transport protocols, such as TCP and UDP. Given that multiAddressesing is directly visible to the transport level, it is not clear how to formally define a connection. Are "virtual" locators used? Is one of the locators used? Is a separate, formal "identifier" used? 4.2.1. SCTP Stream Control Transmission Protocol (SCTP) provides reliable delivery of multiple message streams. It supports multihoming, with the exchange of multiple locators for each SCTP association endpoint, at the start of the association. Current specification use the additional locators to provide reliability if the primary locator ceases to be useful. Enhancements are being discussed to support mobility. Basic security for SCTP control exchange relies on the usual reliability of mapping a locator to an Internet route. An ephemeral association identifier is also used, to prevent "blind" attacks on the association. 4.2.2. TCP-MH TCP-MH uses a TCP option to support multihoming, by specifying multiple IPv4 and/or IPv6 locator pairs that can be used during the same TCP connection. A simple transaction serial number is used to prevent hijacking. TCP-MH manages its pool of locators with individual locator add/delete operations. This style of exchange can lose synchronization between the copies of locator lists maintained by the two endpoints. 4.2.3. DCCP Datagram Congestion Control Protocol (DCCP) establishes an transport connection for the unreliable delivery of datagrams. It has an option to support multihoming. An ephemeral identifier is used to prevent hijacking. 4.3. Session-Level The session layer provides functionality above transport and below the application. In effect it is a way of institutionalizing application-level support. The merit of placing multiAddressesing support at the session layer is that it can use multiple transport services. +---------+ +---------+ | App | | App | +----+----+ +----+----+ | | +----+----+ +----+----+ | Session | | Session | +---+-+---+ +---+-+---+ IP.a | | IP.f IP.q | | IP.y +---+-+---+ +---+-+---+ | TCP | | TCP | +---+-+---+ +---+-+---+ IP.a | | IP.f IP.q | | IP.y +---+-+---+ +---+-+---+ | IP | | IP | +--+---+--+ +--+---+--+ | | | | | | | | IP.a IP.f IP.q IP.y The problem with this approach is that a full session layer typically replicates substantial portions of the transport service, in order to ensure reliability and in-order data sequencing. This makes the session-level approach notably complicated and inefficient. 4.4. Application-Level Applications often provide themselves with enhanced infrastructure support services, to compensate for limitations in the lower protocol, or to optimize functionality and performance according to the peculiarities of the specific application. A typical example is with reliable data transfer, when using an unreliable datagram service. The obvious difficulty with this approach is that it burdens each new application with re-creating these (common) underlying services. +-------+ +-------+ | App | | App | +--+-+--+ +--+-+--+ CP.1 | | TCP.2 TCP.1 | | TCP.2 +--+-+--+ +--+-+--+ | TCP | | TCP | +--+-+--+ +--+-+--+ IP.a | | IP.f IP.q | | IP.y +--+-+--+ +--+-+--+ | IP | | IP | +-+---+-+ +-+---+-+ | | | | | | | | IP.a IP.f IP.q IP.y There well might be some benefit in permitting applications to discover details about multiaddressing capabilities, and possibly in permitting them to specify some details of their use, through an enhanced API. However the prevalence of multiAddressesing dictates its support in lower layers. 4.5. IP Endpoint A recent approach to multiAddressesing defines a new "convergence" layer that exists only in the endpoint systems (hosts) and operates between classic IP and the transport layer. Hence these capabilities are invisible to the IP relaying infrastructure and can be invisible to the transport layer. However they may specify new or modified adjunct infrastructure services, especially to obtain full rendezvous capabilities. This type of approach can be viewed as using a "shim" or "wedge" partial-layer, between IP and transport, or it can be viewed as partitioning IP, between a lower, relaying module that is common to all IP nodes, versus an upper module that performs IP-related functions specific to endpoints. The remainder of this sub-section considers these architectural views and then discusses the three IP Endpoint proposals. 4.5.1. Choosing an IP Endpoint Model 4.5.1.1 Shim Model For the Shim, or wedge, approach, a portion of functionality is intercepted and modified by the shim module: Connection (IP.a, Port.l, IP.y, Port.r) +--------------------------+ | Port.l | Port.r +---+---+ +---+---+ | TCP | | TCP | +---+---+ +---+---+ IP.a | | IP.y /--+--\ /--+--\ < shim > < shim > \-+-+-/ \-+-+-/ IP.a | | IP.f IP.q | | IP.y +--+-+--+ +--+-+--+ | IP | | IP | +-+---+-+ +-+---+-+ | | | | IP.a IP.f IP.q IP.y The transport layer is presented with the same service -- including the same apparent "addressing" model -- as previously. However the address is actually used as an identifier that maps to a set of locators. In the shim model, the identifier may be one of the valid locators. 4.5.1.2 IP/Transport Convergence Layer Model Rather than viewing this type of service as being ad hoc, it can be seen as an example of IP-level services that reside only in the endpoint. That is, there is a distinction between the relaying activities in every "intermediate" system (IP-IS), versus IP functions that are needed only in the end-systems at the endpoints (IP-ES). For multiAddressesing, the architectural impact is embodied by using an Endpoint IDentifier [EID] in the interface between IP-ES and the transport layer, rather than using an endpoint locators. Significantly, the EID might be private to the endpoint(s), rather than needing to be globally registered. IPSec is another example of and IP-ES service. Note that this architectural change also must affect the upper-layer access to DNS, since DNS Address records must be converted to EIDs. Connection (IP.eid1, Port.l, IP.eid2, Port.r) +-------------------------+ | Port.l | Port.r +-------+ +-------+ | TCP | | TCP | +---+---+ +---+---+ | IP.eid1 IP.eid2 | +---+---+ +---+---+ | IP-ES | | IP-ES | +--+-+--+ +--+-+--+ IP.a | | IP.f IP.q | | IP.y +--+-+--+ +-------+ +--+-+--+ | IP-IS | | IP-IS | | IP-IS | +-+---+-+ +-+---+-+ +-+---+-+ | | | | | | | +--------+ +---------+ | IP.a IP.f IP.q IP.y 4.5.2. Host Identity Protocol (HIP) HIP works with IPv4 and IPv6. Also, it: * Creates a new, globally unique name space * Uses strong, cryptographically based protocol details, overloading some HIP functionality with security functionality * Is tied significantly to [IPSEC] * Creates a new DNS RR entry * Requires a Rendezvous (referral) server for mobility support * Requires that NATs be aware of HIP Many of the HIP features are appealing, such as the cleanliness of the architectural model depicted in Section 4 of the HIP architecture document. Were the Internet stack being created now, HIP well might be an excellent approach. However retrofitting this approach into the existing, deployed Internet entails serious barriers to adoption, such as its dependence on IPSec. In general, addition of a DNS SRV record can be useful for achieving efficient rendezvous, with or without mobility. It permits participants to know whether a service is supported by its partner, without requiring a probe packet. While beneficial, this enhancement to DNS data structures is not required for multihoming or client (initiator) mobility. 4.5.3. LIN6 LIN6 defines a clean separation between identifier and locator, all within an IPv6 Address format. It defines a new, globally unique 64-bit endpoint identifier that is used by upper layers. This is then mapped to one or more IPv6 IP-layer locators. The LIN6 specification also provides for the referral function (mapping agent), using DNS for basic name resolution and a separate, dynamically updated service to provide accurate information about rapidly changing locators. LIN6 differs from HIP in that it: * Is limited to IPv6 but integrates into IPv6 numbering * Adds a transient "presence" service to DNS lookup, for dynamic locator mapping 4.5.4. MAST MAST is a control protocol for the exchange of IP Addresses notification and authorization, to use additional IP Addresses in a given host-pair context. The primary MAST exchange transmits: * A list of current IP Addresses supported by the sender Support exchanges: * Establish a host-pair context * Establish relevant authentication between the pair MAST takes a more modest approach than HIP or LIN6. It does not define a new identifier space, has a simpler specification, permits easier implementation and adoption, and works equally with IPv4 and IPv6. MAST has the unusual characteristic of permitting its application to a transport association to begin after the association is underway. Referral to a mobile target is provided as an adjunct function. Initial referral and rendezvous identification reliy on domain names. For mobile endpoints, dynamic locator information is obtain through an associated presence service. New locator information is communicted during an association by the control protocol; security relies on use of a statistically unique, emphemeral identifier. MAST differs from the list of HIP requirements in that it: * Uses a name space that is transient and local to the host-pair * Treats referral as an adjunct requirement and has no special requirements on DNS, in the base service * Is transparent to NATs MAST differs from LIN6 requirements in that it: * Uses a name space that is transient and local to the host-pair * Treats referral as an adjunct requirement * Works with IPv4, as well as IPv6 5. SECURITY CONSIDERATIONS This is a discussion paper and specifies no actions. Hence it has no security impact, except in terms of generally discussing security issues for the IP architecture. An excellent discussion about the types of attacks that are relevant to multiaddressing mechanisms is contained in [WEAK]. Notably it discusses the use of association-specific ephemeral keys, without needing a global certificate service. APPENDIX A.1. Acknowledgements Funding for the RFC Editor function is currently provided by the Internet Society. Marcelo Bagnulo has contributed extensively to this draft. He would be listed as a co-author, but he was not given an opportunity to review it, due to the impending IETF I-D deadline. Commenters on this text include: Marcelo Bagnulo, Fred Baker, Iljitsch van Beijnum, Vint Cerf, Spencer Dawkins, Robert Honore, James Kempf , Eugene Kim, Eliot Lear, Pekka Nikander, Erik Nordmark, Tim Shepard, Randall R. Stewart, Fumio Teraoka, and Bob Hinden. Networking history scholars may note that some terms used in the paper echo from the ancient times of OSI. Apologies are offered. Alas, that effort produced some useful architectural references and terminology, in spite of its problematic protocol specification work. Use of those terms, here, is a matter of pragmatics, not religion. The Internet community lacks broad use of some necessary terminology. Those objecting to any of the terms used here are encouraged to offer others, and to get community support for them. A.2. References Non-Normative [DCCP] Kohler, E., M. Handley, S. Floyd, J. Padhye, "Datagram Congestion Control Protocol (DCCP)", draft-ietf-dccp-spec-04.txt, 30 June 2003 [DNSDYN] Vixie, P., Thomson, S., Rekhter, Y., Bound, J., Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC2136, April 1997 Wellington , B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000 [EID] Chiappa, J.N., "Endpoints and Endpoint Names: A Proposed Enhancement to the Internet Architecture", <http://users.exis.net/~jnc/tech/endpoints.txt>, 1999 [ETCP] Zhang, B., Zhang, B., Wu, I., "Extended Transmission Control Protocol (ETCP) Project-- Extension to TCP for Mobile IP Support", <http://www.cs.ucla.edu/~bzhang/etcp/report.html > [HIP] Moskowitz, R., "Host Identity Protocol Architecture", < http://www.ietf.org/internet- drafts/draft-moskowitz-hip-arch-03.txt > Moskowitz, R., "Host Identity Protocol", <ietf- id: draft-moskowitz-hip-07> [HOWIE] Howie, D., "Consequences of using MIPv6 to Achieve Mobile Ubiquitous Multimedia", http://www.mediateam.oulu.fi/publications/pdf/38 4.pdf [IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998 [LIN6] Teraoka, F., Ishiyama, M., Kunishi, M., "LIN6: A Solution to Mobility and Multi-Homing in IPv6", draft-teraoka-ipng-lin6-02.txt, 24 June 2003 [MOBMH] Nikander, P., "End-Host Mobility and Multi- Homing with Host Identity Protocol", < http://www.ietf.org/internet-drafts/draft- nikander-hip-mm-00.txt> [NAT] Egevang, K., and P. Francis, "The IP Network Locators Translator (NAT)", RFC1631, May 1994 [NSRG] Lear, E., Droms, R., "What's In A Name: Thoughts from the NSRG", draft-irtf-nsrg-report-10.txt, September 2003 [MAST] Crocker, D., "Multiple Locators Service for Transport (MAST): An Extended Proposal", draft-crocker-mast- proposal-00.txt, September 13,2003 [MIP4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002 MIP4 Working Group, < http://www.ietf.org/html.charters/mip4- charter.html> [MIP6] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6", draft-ietf-mobileip-ipv6- 24.txt, June 30, 2003 Bagnulo, M., Garcia-Martinez, A., Soto, I., "Application of the MIPv6 protocol to the multi- homing problem", draft-bagnulo-multi6-mnm-00, February 25, 2003 MIP6 Working Group, < http://www.ietf.org/html.charters/mip6- charter.html> [PBK] Bradner, S., Mankin, AS., Schiller, J., "A Framework for Purpose-Built Keys (PBK)", draft- bradner-pbk-frame-06.txt, June 2003 [SALT] Saltzer, J., " On the Naming and Binding of Network Destinations", RFC 1498, A ugust 1993 [SCTP] L. Ong, and J. Yoakum "An Introduction to the Stream Control Transmission Protocol (SCTP)", RFC 3286, May 2002 R. Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., Paxson, V., "Stream Control Transmission Protocol", RFC 2960, October 2000 R. Stewart, et al, "Stream Control Transmission Protocol (SCTP) Dynamic Locators Reconfiguration", draft-ietf-tsvwg-addip-sctp- 07.txt, February 26, 2003 [TCP-MH] Matsumoto, A. Kozuka, M., Fujikawa, K., Okabe, Y., "TCP Multi-Home Options", draft-arifumi-tcp- mh-00.txt, 10 Sep 2003 [TLS] Dierks, T., C. Allen , "The TLS Protocol Version 1.0", RFC 2246, January 1999. [WEAK] Arko, J., Nikander, P., "Weak Authentication: How to Authenticate Unknown Principals without Trusted Third Parties", , <http://www.tml.hut.fi/~pnr/publications/cam2002 b.pdf> A.3. Author's Adress Dave Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 USA tel: +1.408.246.8253 dcrocker@brandenburg.com A.4. Full Copyright Statement Copyright (C) The Internet Society (2003). 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 assigns. 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.