Network Working Group P. Nikander Internet-Draft Ericsson Research Nomadic Lab Intended status: Informational February 26, 2007 Expires: August 30, 2007 Identifier / Locator Separation: Exploration of the Design Space (ILSE) draft-nikander-ram-ilse-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 30, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Implementing the so called identifier / locator separation may have far-reaching consequences to the Internet architecture, depending very much on how exactly it is implemented. That is, here as in many other cases, the devil lies very much in the details. In this document, we attempt to outline the various aspects of the design space. We briefly discuss six main aspects: identifiers, dynamic traffic management, end-to-end issues, security, economics, Nikander Expires August 30, 2007 [Page 1] Internet-Draft ILSE February 2007 and deployment. In this initial version of the document, we still lack many details. This document is a reaction to the problem statement effort at the Amsterdam IAB Routing and Addressing Workshop (RAWS). Nikander Expires August 30, 2007 [Page 2] Internet-Draft ILSE February 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Identifiers, resolution, and routing . . . . . . . . . . . 6 3.1. Identifier uniqueness and stability . . . . . . . . . . . 7 3.1.1. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.2. Stability or persistence . . . . . . . . . . . . . . . . . 8 3.2. Resolution vs. identifier-based routing . . . . . . . . . 9 3.2.1. Resolving identifiers into locators . . . . . . . . . . . 9 3.2.2. Identifier-based routing . . . . . . . . . . . . . . . . . 10 3.2.3. Mapping security . . . . . . . . . . . . . . . . . . . . . 11 3.3. Backwards compatibility . . . . . . . . . . . . . . . . . 12 3.3.1. API compatibility . . . . . . . . . . . . . . . . . . . . 12 3.3.2. Host-Router interface . . . . . . . . . . . . . . . . . . 13 3.4. Identifier syntax and structure . . . . . . . . . . . . . 13 4. Dynamics and policy: Mobility, Multi-homing, and Traffic Engineering . . . . . . . . . . . . . . . . . . . 14 4.1. Spatial scoping of identifiers . . . . . . . . . . . . . . 14 4.2. Identifier layering and dynamic resolution . . . . . . . . 14 4.3. TBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4. Route converge . . . . . . . . . . . . . . . . . . . . . . 14 5. Transport and other end-to-end issues . . . . . . . . . . 14 5.1. Interactions with middle boxes . . . . . . . . . . . . . . 15 5.2. Alternative paths and congestion . . . . . . . . . . . . . 15 6. Trust models, security, and privacy . . . . . . . . . . . 15 6.1. Trust models . . . . . . . . . . . . . . . . . . . . . . . 15 6.2. Threat analysis . . . . . . . . . . . . . . . . . . . . . 15 6.3. Known security mechanisms . . . . . . . . . . . . . . . . 15 6.4. Privacy aspects . . . . . . . . . . . . . . . . . . . . . 15 7. Economic aspects . . . . . . . . . . . . . . . . . . . . . 15 7.1. Peering and transit agreements . . . . . . . . . . . . . . 15 7.2. Computational mechanism design of protocols . . . . . . . 15 7.3. Cost and compensation . . . . . . . . . . . . . . . . . . 15 7.3.1. Routing and forwarding table sizes . . . . . . . . . . . . 15 8. Deployment . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Incremental deployment . . . . . . . . . . . . . . . . . . 15 8.2. Incentives . . . . . . . . . . . . . . . . . . . . . . . . 15 8.3. Handling legacy sites . . . . . . . . . . . . . . . . . . 15 9. Open issues . . . . . . . . . . . . . . . . . . . . . . . 15 10. Security considerations . . . . . . . . . . . . . . . . . 15 11. IANA considerations . . . . . . . . . . . . . . . . . . . 16 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 16 13. Informative references . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . 18 Nikander Expires August 30, 2007 [Page 3] Internet-Draft ILSE February 2007 1. Introduction The so called identifier / locator separation has been under heavy debate within the IETF community for the last 10 year or so. Many people have argued for its desirability, and a number of proposals of implementing it, in one or another way, have been produced [3], [6]. More recently, as a result of the 2006 IAB Routing and Addressing workshop [7], the discussion has gained more momentum but simultaenously focused mostly on the immediate need of relieving pressures on the routing tables. In this document, we attempt to take to take a wider and hopefully more balanced look at various design aspects, and their consequences. Our goal is to make the community more aware of the opportunities the identifier / locator separation potentially provides to the architecture and its further development. The rest of this document is organised as follows. First, in Section 2 give give a brief summary of the background thinking for the uninitiated reader. In Section 3 we discuss design issues related to the identifier space itself, and especially to how to resolve identifiers to locators or perform (overlay) routing directly with the identifiers. Next, in Section 4, we discuss issues related to the dynamic nature of the network and policies involved, including mobility, multi-homing, and traffic engineering. In Section Section 5 we briefly cover a few transport end end-to-end issues; however, as the present authors include now transport-layer expert, this discussion is necessarily scanty at the moment. Section Section 6 is devoted to security, trust, and privacy. Section Section 7 covers a number of non-security-related economic aspects of networking, including peering agreements, computational mechanism design in protocol design, and overall cost and cost distribution of the network. Finally, Section 8 covers a number of deployment issues not covered before, and Section 9 discusses a few open issues not fitting elsewhere. 2. Background TBD: This section is a skeleton, needing more work. As early as 1982, it was recognised that the current Internet architecture provides insufficient means to identify services and users [1]. Since then the community has rampantly discussed [5] the need or non-need of adding a separate name space (identifier space) for network nodes, as opposed for network attachment points (locators), with wildly varying opinions even about the state of reality. Nikander Expires August 30, 2007 [Page 4] Internet-Draft ILSE February 2007 In late 1990s, the more academic or theoretical part of the community had converged to the stance that some sort of an end-point name space were needed [14]. That notion resulted, among other things, to the development of the HIP architecture [3], which then later on had quite a lot of influence to the development of the SHIM6 protocol [6]. At the same time, the idea was studied extensively in the academia (TBD: add a representative small number of references). Most recently, triggering the current flock of activity, the IAB held a workshop on Addressing and Routing (RAWS) in October 2006, identifying the current semantic overloading of IP addresses as one problem area, and briefly discussing a few proposals in the identifier / locator separation solution space [7]. In the resulting discussion at the IAB initiated architecture-discuss [12] and ram [13] mailing lists, has led to the following tentative conclusions: o There are two almost orthogonal aspects when implementing the identifier / locator separation: 1. A more architectural aspect of where, in the layering sense, to implement the separation. That is, when considering the vertical stacking order of the protocol layers, where in this stacking order the separation is placed. 2. A more implementational aspect of where, in the real-world sense, to implement the separation. That is, when considering the various devices needed to implement a communications path, including the host proper, device driver, and routers and other middle boxes, where in this implementational sense the separation is placed. These two aspects are considered only almost independent since the higher in the stack the separation is located in the architectural sense, the harder it is to implement it closer to or within the network (middle boxes). Such within-the-network implementation is considered beneficial and important due to deployment reasons, in order to help supporting legacy hosts [8]. o Architecturally, the vertical locations within-the-stack where the separation may be implemented can be roughly divided into three different categories: A. The separation may be implemented above the current transport layer, mainly TCP and UDP. In practise, many applications do implement a primitive kind of the separation already themselves. In theory, a library could implement the Nikander Expires August 30, 2007 [Page 5] Internet-Draft ILSE February 2007 separation, giving legacy applications the illustration of them being still connected to stable IP locators while in practise using some sort of identifiers. B. The separation may be implemented at or below the transport (i.e. below the socket API) but above the routing part of the IP layer. There are a plenty of proposals in this space, including SCTP extensions [10], the Host Identity Protocol (HIP) [3], and the SHIM6 protocol [6]. C. The separation may be implemented below the host-part of the IP layer. Again, there are a number of proposals in this space, of which the [9] has recently gained some attention. What is noteworthy here is that, as argued in [8] in more detail, there is considerable freedom in the implementational aspect independent of the architectural choice. That is, even the application layer approaches can be implemented within the network with the help of proxies, if so desired. Conversely, implementations mainly targeted to be implemented within the network, such as [9], may be implemented within the host stack. Consequently, as we will argue in more detail below, it is not the architectural nor the implementation location of the separation that matters most, but other aspects, such as the nature of identifiers, the ability to handle network dynamics and policy, and the trust model. They will have fundamental consequences in the future ability of the network to evolve to support new functions and features. We hope that this, as well as its consequences, will become clearer below. Finally, we will passingly note that there is a parallel, longer- reaching discussion going on the exact semantic nature of host identifiers, i.e., whether the notion of host identifiers should be extended to also include other types of hosts but nodes, including all kinds of aggretable coalitions of application names, including but not limited to virtual and distributed hosts. However, since that discussion is only likely to confuse the average uninitiated reader, we will pursue that not any further. Instead, throughout the rest of this document, we take the simplifying assumption that node names are needed just as such, as discussed in [1], unless explicitly noted otherwise. 3. Identifiers, resolution, and routing In this section, we discuss the perhaps most important aspect of the proposed separation: the nature of the identifiers. Unfront, we take the stance the it must be possible to represent the identifiers in a backwards compatible way to legacy applications and hosts; this Nikander Expires August 30, 2007 [Page 6] Internet-Draft ILSE February 2007 aspect is explored more in Section 3.3 and Section 8, below. In the following subsections, we will cover three distinct aspects related to identifiers, as follows. However, this is by no means an exhaustive list; it is just a choice of aspects that seem most relevant to the current discussion. o In Section 3.1, we consider the identifiers more from the applications point of view, focusing on their uniqueness and stability. o Next, in Section 3.2, we consider by-system-provided function of mapping the identifiers to a (set of) locator(s). o As a third aspect, in Section 3.3, we consider backwards compatibility of the identifiers. o Based on the discussion in the first three subsections, in Section 3.4, we consider the syntax and structure of identifiers and their representations. When reading what follows, it is important to remember that the representation of the identifiers in a backwards compatible way need not be the native form of the identifiers. For example, while HIP represents the identifiers as 128-bits long Host Identity Tags or 32- bits long Local Scope Identifiers for backwards compatibility, the only defined native form of HIP identifiers are public cryptographic keys. 3.1. Identifier uniqueness and stability From an applications point of view, it is very desirable to have genuinely unique and temporarly stable identifiers. If the identifiers by themselves do not provide enough of means for contacting and identifying the peers over space and time, the applications need other means to achieve their identification goals, partially foiling the very purpose of the identifiers. (That is, the identifiers may still be very useful for the network and for initiating communication.) 3.1.1. Uniqueness The very word identifier (stemming from late Lat. identitas, in turn stemming from early Lat. idem et idem, "same and same" or "again and again", or "identidem", repeatedly) implies uniqueness, the ability to uniquely identify an identity based on the identifier; a naturally very desirable property. However, on a closer look the situation may not be that black and white. Nikander Expires August 30, 2007 [Page 7] Internet-Draft ILSE February 2007 Technically, absolute uniqueness implies assurance that a given identity will under no circumstances be used, even accidentally, by more than on entity. Of course, in a large and decentrally administered network such assurance is impossible to achieve. Consequently, any realistic system must include measures to handle the odd situation where more than one entities claim the same identity, by accident or malice. Based on the above observation, it has been suggested that maybe even aiming for absolute uniqueness is undesirable due to its likely administrative cost. As an alternative, it might be more profitable to use long enough pseudo-random identifiers so that the statistical probability of collisions becomes sufficiently low. Furthermore, if the construction of the identifiers uses a suitably constructed cryptographically strong one-way function on data that is guaranteed to carry enough of entropy, one can virtually eliminate the potential of collisions due to malice or human error, leaving randomness as the only source of collisions; see e.g. [2]. As a counter-argument, it has been stated that in order to reach low enough probability of collisions, the identifiers become too long. Depending on the context of identifier interpretation, this may well be true for very short identifier fields, such as entities of IPv4 address size, 32 bits or 4 octets; see Section 3.3. However, roughly 60 bits or more seems to provide enough of statistical uniqueness for many practical purposes (see, e.g., [15] or [2]), and 256 bits (32 octets) seems large enough for even the most demanding cases. In the case of statistical uniqueness being impossible due to the short length of identifiers or undesirable, for example, due to human factors, the only other proven way to ensure identifier uniqueness is through a centrally delegated hierarchical administration, in the manner IP addresses and DNS names are assigned today. That has the known problem of creating an artificial monopoly point, requiring explicit regulation. 3.1.2. Stability or persistence Historically, most concern on identifier stability in the Internet has been a result of increased node mobility. In the current system, where IP addresses are used both as locators and as identifiers, node mobility leads to cumbersome mechanisms where the same name space (IP addresses) are used for two semantically different purposes, leading to the aliasing problem, well known from programming language data flow analysis. Unfortunately, to our knowledge, the effects of this problem to distributed systems have not been formally analysed. Generalising slightly, there are also other networking phenomena that Nikander Expires August 30, 2007 [Page 8] Internet-Draft ILSE February 2007 easily lead to issues with identifier stability. For example, as discussed in Section 4.3 below, certain aspects of multi-homing and traffic engineering may be easier to solve if the locators can be easily changes. Conversely, the current desire to keep IP addresses stable in order not to require administrative changes unnecessarily complicates the existing practises, leading demonstratably to some routing table growth. Extending the argument, we can state that it is desirable to shield applications from unnecessary changes of identifiers while allowing the network to change locators as it needs. 3.2. Resolution vs. identifier-based routing Separating the identifier and locator roles of IP addresses necessitates a means for maintaining mappings from identifiers to locators. There are two basic approaches to this: resolution and identifier-based routing. 3.2.1. Resolving identifiers into locators The better known way of maintaining name-to-address mappings is resolution. Resolution is familiar from the Domain Name System (DNS). In resolution, the client sends an explicit query message to a server, the query message containing the to-be-resolved name. The server responds with a reply containing both the name and the corresponding address or addresses. When considering the identifier / locator separation, it would feel natural to resolve the identifiers into locators in the same way: using an explicit server and a query-response system. However, while that model is familiar, it has a couple of potential architectural drawbacks: o Almost by necessity, controlling access to the information must be implemented separately from the primary entities that the information concerns. That is, in this model it is natural that the name servers control whom may access the information, without involving the identified nodes at all. o Compared to the identifier-based-routing model (below), the resolution model includes a separate resolution step while the identifier-based-routing model folds this step into very operation of initiating communication. It can be well argued if the latter is a drawback or benefit. At one hand, it may be considered as a source of inefficiency. At the other hand, it allows one to find the current set of locators without Nikander Expires August 30, 2007 [Page 9] Internet-Draft ILSE February 2007 initiating communication at all. 3.2.2. Identifier-based routing An alternative to explicit resolution is to combine identifier-based routing with locator determination. In this approach, the first (or first few) packet is send over a routing infrastructure that can route based on identifiers (as opposed to locators). Depending on the details, such a routing infrastructure can be the same as the one for locators (as in LISP1 [9], PASH1 [11], or SHIM6 [6]), can be parallel to the regular routing one (as in LISP1.5 or PASH1.5), or can be an overlay one, e.g., based on Distributed Hash Tables (DHTs). There are plenty of examples of the last approach, including Berkeley i3 [16]. The basic idea here goes as follows: 1. The first packet is sent essentially as such, over the identifier-routing-capable infrastructure. Optionally, the packet may be tagged with the sender's locators, allowing the recipient to learn them. 2. Once the packet is received by the recipient, it processes it and decides whether to respond. If the first message did not include the initiator's locators, also the second packet must be passed over the identifier-routing-capable infrastructure. 3. At some point, typically during the first few packets, the hosts reveal their locators to their peers, allowing all further communication to pass directly over the locator-based routing infrastructure. In many incarnations of this idea, the identity-routing infrastructure is a magnitude or more less efficient than the locator-routing infrastructure; for one data point, see [17]. In practise, this is usually not a problem since only one or a few initial packets will be routed over the identity-routing infrastructure and the rest over the more efficient locator-routing infrastructure. There are a few potential benefits of this approach, when compared to explicit identifier resolution: o Both host have full control of when to reveal their locators to their peers. Conversely, the hosts may continue to communicate over the identity-routing infrastructure, trading routing efficiency for increased privacy and resiliance. Nikander Expires August 30, 2007 [Page 10] Internet-Draft ILSE February 2007 o The identity-routing infrastructure can often provide better resiliance properties than explicit resolution, mostly due to different time dynamics. o Initial communication may take place more efficiency than in the resolution model, since the infrastructure can pass the first data packet directly to the recipient instead of waiting for the reply to reach the initiator, which then in turn sends the first data packet to the recipient. 3.2.3. Mapping security The security aspects of the identifier-to-locator mapping have been extensively studied in the context of mobility protocols (see e.g. [4] and [18]). The basic types of attacks can be enumerated as follows: 1. Attacks against locator "owners", including stealing of known future locators, attacks against secrecy and integrity of data, and basic forms of denial-of-service (blackholing). 2. Attacks against other network nodes or links, i.e., the so called flooding attacks. These attacks are often ignored by naive protocol designers, as they are not as obvious as the attacks in the first category. 3. Attacks against whatever security mechanisms are used to mitigate the two first classes of attacks. At the time of this writing, the common wisdom of measures effective countering the attacks include the following ones: a. Return routability is currently the only known effective way of countering against flooding attacks. Basically, in return routability the verifying node checks that the peer can receive and reply to messages sent to the claimed locators. Return routability also helps with many of the attacks against address "owners." However, it must be noted that return routability is not effective against on-path or intrastructure-spoofing attackers. b. Careful design of the protocol used to create and maintain mappings helps against the third type of threats. In practise, this means using cryptographic checks. Note, however, that traditional key distribution is typically NOT needed. Instead, more primitive methods, such as hash chains, can usually be safely used. Nikander Expires August 30, 2007 [Page 11] Internet-Draft ILSE February 2007 c. Reverifying the mapping state often (e.g. every few minutes) helps against time-related attacks (e.g. future location steal.) This adds signalling load but typically avoids the need for extra infrastructure. d. Self-certifying identifiers, e.g., using public cryptographic keys as primary identifiers, helps with solving many "ownership" attacks, but seems to be by no means a necessity, at least in many situations. 3.3. Backwards compatibility During the last year or so, quite a lot of network-related research has focused on the so called clean slate approaches, aiming for new types of networking going far beyond to what the current Internet is able to achieve. Consequently, for a relatively modest architectural change, as compared to clean slate, such as the identifier locator separation, it is even more important than before to be backwards compatible. Considering the current Internet architecture, there seems to be two interfaces where the backwards compatibility issues condense: the host-to-router interface over the local wire, and the stack-to- application interface over the local API. In both cases, there organisations and individuals responsible for the behaviour at one side of the inferface are typically completely different from the ones at the other side, e.g., representing different vendors from different vendor communities. As outlined in [8], there are two main options for implementing different kinds of identifier locator separation: within-the-stack, or within-the-network. In an in-the-stack approach, the host-to- router interface continues to use locators and the stack-to- application interface is converted to use identifiers. In an in-the- network approach both of these interfaces are converted to use identifiers, and locators are used only deeper in the network. Consequently, an in-the-network approach appears to have more stringent backwards compatibility requirements, i.e., it needs to preserve more of the current address semantics when replacing them with identifiers than the in-the-stack approach needs to do. 3.3.1. API compatibility Let us consider the stack-to-application API interface first. While there are more advanced APIs, the majority of todays applications use some variation of the so called Berkeley sockets interface. Furthermore, while a large fraction of the solutions have been carefully written to be able to deal with different sorts of Nikander Expires August 30, 2007 [Page 12] Internet-Draft ILSE February 2007 addressings, even beyond IPv4 and IPv6 addresses, almost none of them have actually ever been tested with anything else but IP addresses. And, of course, there exists important legacy applications that know of nothing else but IPv4 addresses, but their use is often confined to organisational-internal use. For most applications, the IP addresses are simple binary blobs. (Diagnostic applications are a prime counterexample, but they will need to be modified anyway for any realistic identifier locator separation approach.) Given an IP address, a typical application assumes that it can either create TCP connections or send UDP packets to a corresponding application hosted at the given address, and receive replies from the same address, no more or no less. Hence, this appears to be the most important piece of semantics to preserve. Unfortunately, there appears to be a number of important applications that assume more. Basically, they assume that they can hand the address (either as a binary blob or encoded as an ascii string) to any other host and that host will also be able to use the address in the same way. This is the so called referral problem. Fortunately, for the present discussion, this property has already been largely broken by the prevalence of NATs and firewalls, and therefore is not that important any more than it once was. 3.3.2. Host-Router interface TBD: This section needs to be written. 3.4. Identifier syntax and structure The main forces affecting identifier syntax seem to be the following: Uniqueness; see Section 3.1. Here there seems to be a tension between the hierarchical and pseudo-random assignment approaches. Routability; see Section 3.2. Here a big question is the scope of routability. If the identifier locator separation is implemented within the host stack or if the identifiers are routed through a completely separate infrastructure, the identifier structure may be determined without any routability considerations. If the separation is implemented as on optional feature, as it may in the very beginning, it may be necessary for the identifiers to be fully routable in the traditional IP sense of the world. In some other cases, a simple routable prefix may suffice. Nikander Expires August 30, 2007 [Page 13] Internet-Draft ILSE February 2007 Security; see Section 3.2.3. The desirable self-certifying property necessarily means that at least some part of the identifier would be cryptographic in nature, and therefore random looking. Size, including backwards compatibility issues. Obviously, the smaller the better, and if the identifiers, or some representation of them, can be fitted into legacy IPv4 and IPv6 address sizes, even better. Additional potential requirements that we do not discuss here, on purpose, include human friendliness, ... Based on that, we would tentatively recommend a two-pronged strategy: 1. Leave the actual structure and syntax of the to-be-identifiers as open as possible for as long as possible. That is, try to avoid building syntax-dependencies in the rest of the design. 2. Plan early on for suitable backwards-compatible representations. Here a major focus should be in determining the contexts within which the representations will be interpreted, as that will affect the requirements on uniqueness. Furthermore, try also to determine if the referral problem is really an Internet-wide phenomenon or do less stringent backwards compatibility suffice. 4. Dynamics and policy: Mobility, Multi-homing, and Traffic Engineering In this section, we consider the design from the point of view of dynamic events and policies controlling the network behaviour. The rest of this document is an outline for future work. 4.1. Spatial scoping of identifiers 4.2. Identifier layering and dynamic resolution 4.3. TBD TBD: Add here material from Elwyn Davies note on the architectural similarities between multi-homing and traffic engineering. 4.4. Route converge 5. Transport and other end-to-end issues Nikander Expires August 30, 2007 [Page 14] Internet-Draft ILSE February 2007 5.1. Interactions with middle boxes 5.2. Alternative paths and congestion 6. Trust models, security, and privacy 6.1. Trust models 6.2. Threat analysis 6.3. Known security mechanisms 6.4. Privacy aspects 7. Economic aspects 7.1. Peering and transit agreements 7.2. Computational mechanism design of protocols 7.3. Cost and compensation 7.3.1. Routing and forwarding table sizes 8. Deployment 8.1. Incremental deployment 8.2. Incentives 8.3. Handling legacy sites 9. Open issues 10. Security considerations At this stage, we haven't worked out all the security details. Some security aspects have been discussed in Section Section 6. Nikander Expires August 30, 2007 [Page 15] Internet-Draft ILSE February 2007 11. IANA considerations This document has no actions for IANA. 12. Acknowledgments We have shamelessly borrowed text from Elwyn Davies' posting to the RAM mailing list for the discussion about the relationship between multi-homing and traffic engineering, in Section 4.3. 13. Informative references [1] Saltzer, J., "On the Naming and Binding of Network Destinations", RFC 1498, August 1993. [2] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [3] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. [4] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4225, December 2005. [5] Lear, E. and R. Droms, "What's In A Name:Thoughts from the NSRG", draft-irtf-nsrg-report-10 (work in progress), September 2003. [6] Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim protocol", draft-ietf-shim6-proto-06 (work in progress), October 2006. [7] Meyers, D., "Report from the IAB Workshop on Routing and Addressing", draft-iab-raws-report-00 (work in progress), December 2006. [8] Nikander, P., "Generic Proxying as a Deployment Tool (GEPROD)", draft-nikander-ram-generix-proxying-00 (work in progress), January 2007. [9] Farinacci, D., "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp-00 (work in progress), January 2007. [10] Stewart, R., "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", Nikander Expires August 30, 2007 [Page 16] Internet-Draft ILSE February 2007 draft-ietf-tsvwg-addip-sctp-09 (work in progress), June 2004. [11] Nikander, P. and K. Slavov, "Proxying Approach to SHIM6 and HIP", draft-nikander-ram-pash-00 (work in progress), February 2007. [12] IAB, "Architecture-discuss -- open discussion forum for long/ wide-range architectural issues". [13] IAB, "RAM -- Routing and Addressing Mailing List". [14] Chiappa, J., "Endpoints and Endpoint Names: A Proposed Enhancement to the Internet Architecture", URL http://www.chiappa.net/~jnc/tech/endpoints.txt, 1999. [15] Montenegro, G. and C. Castelluccia, "Statistically Unique and Cryptographically Verifiable (SUCV) Identifiers and Addresses", URL http://www.isoc.org/isoc/conferences/ndss/02/proceedings/ papers/monten.pdf, 2002. [16] Stoica, I., Atkins, D., Zhuang, S., Shenker, S., and S. Surana, "Internet Indirection Infrastructure (i3)", URL http://i3.cs.berkeley.edu/, 2002. [17] Gurtov, A., Korzun, D., and P. Nikander, "Hi3: An Efficient and Secure Networking Architecture for Mobile Hosts", URL http:// www.tml.tkk.fi/~pnr/publications/ HIIT_gurtov_hi3_report_2005.pdf, 2005. [18] Aura, T., Nikander, P., and G. Camarillo, "Effects of Mobility and Multihoming on Transport-Layer Security", URL http:// www.tml.tkk.fi/~pnr/publications/ aura-nikander-camarillo-ssp04.pdf, 2004. Author's Address Pekka Nikander Ericsson Research Nomadic Lab JORVAS FIN-02420 FINLAND Phone: +358 9 299 1 Email: pekka.nikander@nomadiclab.com Nikander Expires August 30, 2007 [Page 17] Internet-Draft ILSE February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Nikander Expires August 30, 2007 [Page 18]