idnits 2.17.00 (12 Aug 2021) /tmp/idnits40192/draft-huston-multi6-architectures-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2, 2004) is 6592 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC3582' on line 185 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Individual Submission G. Huston 2 Internet-Draft Telstra 3 Expires: October 31, 2004 May 2, 2004 5 Architectural Approaches to Multi-Homing for IPv6 6 draft-huston-multi6-architectures-00.txt 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at http:// 23 www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 This Internet-Draft will expire on October 31, 2004. 30 Copyright Notice 32 Copyright (C) The Internet Society (2004). All Rights Reserved. 34 Abstract 36 This memo provides an analysis of the aspects of multi-homing support 37 for the IPv6 protocol suite. The purpose of this analysis is to 38 provide a taxonomy for classification of various proposed approaches 39 to multi-homing. It is also an objective of this exercise to identify 40 common aspects of this domain of study, and also to provide a 41 framework that can allow exploration of some of the further 42 implications of various architectural extensions that are intended to 43 support multi-homing. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. The Multi-Homing Space . . . . . . . . . . . . . . . . . . . 3 49 3. Requirements and Considerations . . . . . . . . . . . . . . 5 50 4. Approaches to Multi-Homing . . . . . . . . . . . . . . . . . 6 51 4.1 Multi-Homing: Routing . . . . . . . . . . . . . . . . . . . 6 52 4.2 Multi-homing: Identity Considerations . . . . . . . . . . . 7 53 4.3 Multi-homing: Identity Protocol Element . . . . . . . . . . 9 54 4.4 Multi-homing: Modified Protocol Element . . . . . . . . . . 11 55 4.5 Modified Site-Exit and Host Behaviors . . . . . . . . . . . 11 56 4.6 Approaches to Endpoint Identity . . . . . . . . . . . . . . 13 57 4.7 Endpoint Identity Structure . . . . . . . . . . . . . . . . 13 58 5. Common Issues for Multi-Homing Approaches . . . . . . . . . 15 59 5.1 Triggering Locator Switches . . . . . . . . . . . . . . . . 15 60 5.2 Session Startup and Maintenance . . . . . . . . . . . . . . 17 61 6. Security Considerations . . . . . . . . . . . . . . . . . . 17 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 63 Normative References . . . . . . . . . . . . . . . . . . . . 18 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . 18 65 A. Notes on Various approaches . . . . . . . . . . . . . . . . 18 66 A.1 Host Identity Protocol (HIP) . . . . . . . . . . . . . . . . 18 67 A.2 Multihoming without IP Identifiers (NOID) . . . . . . . . . 19 68 A.3 Common Endpoint Locator Pools (CELP) . . . . . . . . . . . . 20 69 A.4 Weak Identifier Multihoming Protocol (WIMP) . . . . . . . . 21 70 A.5 Host-Centric IPv6 Multihoming . . . . . . . . . . . . . . . 22 71 A.6 Summaries of Selected ID/LOC Separation Documents . . . . . 23 72 A.6.1 New or Updated Documents Since IETF58 . . . . . . . . . . . 24 73 A.6.2 Older Documents that Remain Active/Interesting . . . . . . . 26 74 A.6.3 Related Multi-Homing drafts, Status unknown . . . . . . . . 27 75 Intellectual Property and Copyright Statements . . . . . . . 30 77 1. Introduction 79 The objective of this exercise is to allow various technical 80 proposals relating to the support of multi-homing environment in IPv6 81 to be placed within an architectural taxonomy. This is intended to 82 allow these proposals to be classified and compared in a structured 83 fashion. It is also an objective of this exercise to identify common 84 aspects across all proposals within this domain of study, and also to 85 provide a framework that can allow exploration of some of the further 86 implications of various architectural extensions that are intended to 87 support multi-homing. The scope of this study is limited to the IPv6 88 protocol suite architecture, although reference is made to IPv4 89 approaches as required. 91 2. The Multi-Homing Space 93 The simplest formulation of the multi-homing environment is indicated 94 in Figure 1. 96 +------+ 97 |remote| 98 | host | 99 | R | 100 +------+ 101 | 102 + - - - - - - - - - - - + 103 | Internet Connectivity | 104 + - - - - - - - - - - - + 105 / \ 106 +---------+ +---------+ 107 | ISP A | | ISP B | 108 +---------+ +---------+ 109 | Path a | Path b 110 + - - - - - - - - - - - - - - - - - - - - + 111 | multi- | | | 112 homed +------+ +------+ 113 | site | site | | site | | 114 | exit | | exit | 115 | |router| |router| | 116 | A | | B | 117 | +------+ +------+ | 118 | | 119 | local site connectivity | 120 | 121 | +-----------+ | 122 |multi-homed| 123 | | host | | 124 +-----------+ 125 + - - - - - - - - - - - - - - - - - - - - + 127 The Multi-Homed Domain 129 Figure 1 131 The environment of multi-homing is one that is intended to provide 132 sufficient support to local hosts so as to allow local hosts to 133 exchange IP packets with remote hosts, such that this exchange of 134 packets is to be seamlessly supported across dynamic changes in 135 connectivity. This implies that if a local multi-homed-aware host 136 establishes an application session with the remote host using "Path 137 a", and this path fails, the application session should be mapped 138 across to "Path b" without requiring any application-visible 139 re-establishment of the session. In other words, the application 140 session should not be required to be explicitly aware of underlying 141 path changes at the level of packet forwarding paths chosen by the 142 network. 144 This simple multi-homing scenario also includes "site-exit' routers, 145 where the local site interfaces to the upstream Internet transit 146 providers. The nature of the interactions between the external 147 routing system and the site-exit routers, and interactions between 148 the site-exit routers and the local multi-homed host, and the 149 interactions between local connectivity forwarding and the local host 150 and site exit routers are not defined a priori in this scenario, as 151 they form part of the framework of interaction between the various 152 multi-homing components. 154 The major characteristic of this scenario is that the address space 155 used by, and advertised as reachable by, ISP A is distinct from the 156 address space used by ISP B. 158 This simple scenario is intended to illustrate the basic multi-homing 159 environment. Variations of this scenario include additional external 160 providers of transit connectivity to the local site, complex site 161 requirements and constraints, where the site may not interface 162 uniformly to all external transit providers, sequential rather than 163 simultaneous external transit reachability, communication with remote 164 multi-homed hosts, multi-way communications, use of host addresses in 165 a referential context (third party referrals) and the imposition of 166 policy constraints on path selection. However, the basic scenario is 167 sufficient to illustrate the major architectural aspects of support 168 for multi-homing, so this scenario will be used as the reference 169 model for this analysis. 171 3. Requirements and Considerations 173 RFC 3582 [RFC3582] documents some requirements that a multi-homing 174 approach should attempt to address. These requirements include: 175 o redundancy 176 o load sharing 177 o traffic engineering 178 o policy constraints 179 o simplicity of approach 180 o transport-layer survivability 181 o DNS compatibility 182 o packet filtering capability 183 o scaleability 184 o legacy compatibility 185 The reader is referred to [RFC3582] for a complete description of 186 each of these requirements. 188 In addition, work in progress 189 [draft-lear-multi6-things-to-think-about] documents further 190 considerations for IPv6 multi-homing. Again, the reader is referred 191 to this document for the detailed enumeration of these 192 considerations. The general topic areas considered in this study 193 include: 194 o interaction with routing systems, 195 o aspects of a split between end-point-identifier and forwarding 196 locator, 197 o changes to packets on the wire, and 198 o the interaction between names, endpoints and the DNS. 200 In considering various approaches, further consideration also 201 include: 202 o the role of helpers and agents in the approach, 203 o modifications to host behaviors, 204 o the required trust model to support the interactions, and 205 o the nature of potential vulnerabilities in the approach. 207 4. Approaches to Multi-Homing 209 There appear to be four generic forms of architectural approaches to 210 this problem, namely: 211 o Routing 212 Use the IPv4 multi-homing approach 213 o New Protocol Element 214 Insertion of a new element in the protocol stack that manages a 215 persistent identity for the session 216 o Modify a Protocol Element 217 Modify the Transport or IP protocol stack element in the host in 218 order to support dynamic forwarding locator change 219 o Modified Site-Exit Router / Local Host interaction 220 Modify the site-exit router and local forwarding system to allow 221 various behaviors including source-based forwarding, site-exit 222 hand-offs, and address rewriting by site-exit routers 224 These approaches will be described in detail in the following 225 sections. 227 4.1 Multi-Homing: Routing 229 The approach used in IPv4 for multi-homing support is to preserve the 230 semantics of the IPv4 address as both an endpoint identifier and a 231 forwarding locator. For this to work in a multi-homing context it is 232 necessary for the transit ISPs to announce the local site's address 233 prefix as a distinct routing entry in the inter-domain routing 234 system. This approach could be used in an IPv6 context, and, as with 235 IPv4, no modifications to the IPv6 architecture are required to 236 support this approach. 238 The local site's address prefix may be a more specific address prefix 239 drawn from the address space advertised by one of the transit 240 providers, or from some third party provider not current directly 241 connected to the local site. Alternatively the address space may be a 242 distinct address block obtained by direct assignment from a Regional 243 Internet Registry as Provider Independent space. Each host within the 244 local site is uniquely addressed from the site's address prefix. 246 All transit providers for the site accept a prefix advertisement from 247 the multi-homed site, and advertise this prefix globally in the 248 inter-domain routing table. When connectivity between the local site 249 and an individual transit provider is lost, normal operation of the 250 routing protocol will ensure that the routing advertisement 251 corresponding to this particular path will be withdrawn from the 252 routing system, and those remote domain domains who had selected this 253 path as the best available will select another candidate path as the 254 best path. Upon restoration of the path, the path is re-advertised in 255 the inter-domain routing system. Remote domains will undertake a 256 further selection of the best path based on this re-advertised 257 reachability information. Neither the local or the remote host need 258 to have multiple addresses, nor undertake any form of address 259 selection. The path chosen for forward and reverse direction path 260 flows is a decision made by the routing system. 262 This approach generally meets all the criteria for multi-homing 263 approaches with one noteable exception: scaleability. Each site that 264 multi-homes in this fashion adds a further entry in the global 265 inter-domain routing table. Within the constraints of current routing 266 and forwarding technologies it is not clearly evident that this 267 approach can scale to encompass a population of multi-homed sites of 268 the order of 10**7 such sites. The implication here is that this 269 would add a similar number of unique prefixes into the inter-domain 270 routing environment, which in turn would add to the storage and 271 computational load imposed on inter-domain routing routing elements 272 within the network. This scale of additional load is not supportable 273 within the current capabilities of the IPv4 global Internet, nor is 274 it clear at present that the routing capabilities of the entire 275 network could be expanded to manage this load in a cost-effective 276 fashion, within the bounds of the current inter-domain routing 277 protocol architecture. 279 4.2 Multi-homing: Identity Considerations 281 The intent of multi-homing in the IPv6 domain is to achieve a 282 comparable functional outcome for multi-homed sites without an 283 associated additional load being imposed on the routing system. The 284 overall intent of IPv6 is to provide a scaleable protocol framework 285 to support the deployment of communications services for an extended 286 period of time, and this implies that the scaling properties of the 287 deployment environment remain tractable within projections of size of 288 deployment and underlying technology capabilities. Within the 289 inter-domain routing space, the basic approach used in IPv4 and IPv6 290 is to attempt to align address deployment with network topology, so 291 that address aggregation can be used to create a structured hierarchy 292 of the routing space. 294 Within this constraint of topological-based address deployment and 295 provider aggregatable addressing architectures, the local site that 296 is connected to multiple providers is delegated addresses from each 297 of these providers' address blocks. In the example network in Figure 298 1, the local multi-homed host will concievably be addressed in two 299 ways: one using transit provider A's address prefix and the other 300 using transit provider B's address prefix. 302 If remote host R is to initiate a communication with the local 303 multi-homed host, it would normally query the DNS for an address for 304 the local host. In this context the DNS would return 2 addresses (One 305 using the A prefix and the other using the B prefix). The remote host 306 would select one of these addresses and send a packet to this 307 destination address. This would direct the pact to the local host 308 along a path through A or B, depending on the selected address. If 309 the path between the local site and the transit provider fails, then 310 the address prefix announced by the transit provider to the 311 inter-domain routing system will continue to be the provider's 312 address prefix. The remote host will not see any change in routing, 313 yet packets sent to the local host will now fail to be delivered. The 314 question posed by the multi-homing problem is: "If the remote host is 315 aware of multi-homing, how could it switch over to using the 316 equivalent address for teh local multi-homed host hat transits the 317 other provider?" 319 If the local multi-homed host wishes to initiate a session with 320 remote host R, it needs to send a packet to R with a valid source and 321 destination address. While the destination address is that of R, what 322 source address should the local host use? There are two implications 323 for this choice. Firstly the remote host will, by default use this 324 source address as the destination address in its response, and hence 325 this choice of source address will direct the reverse path from R to 326 the local host. Secondly, the ISPs A and B may be using reverse 327 unicast address filtering on source addresses of packets passed to 328 the ISP, as a means of prevention of source address spoofing. This 329 implies that if the multi-homed address selects a source address from 330 address prefix A, and the local routing to R selects a best path via 331 ISP B, then ISP B's ingress filters will discard the packet. 333 Within this addressing structure there is no form of routing-based 334 repair of certain network failues. If the link between the local site 335 and ISP A fails, there is no change in the route advertisements made 336 by ISP A to its external routing peers. Even though the multi-homed 337 sitines to be reachable via ISP B, packets directed to the site using 338 ISP A's prefix will be discarded by ISP A as the destination is 339 unreachable. The implication here is that if the local host wishes to 340 maintain a session across such events it needs to communicate to 341 remote host R that it is possible to switch to using a destination 342 address for the multi-homed host that is based on ISP B' address 343 prefix. 345 In an aggregated routing environment multiple transit paths to a host 346 imply multiple address prefixes for the host, where each possible 347 transit path is identified by an address for the host. The 348 implication of this constraint on multi-homing is that paths being 349 passed to the local multi-homed site via transit provider ISP A must 350 use a forwarding-level destination IP address drawn from ISP A's 351 advertised address prefix set that maps to the multi-homed host. 352 Equally, packets being passed via the transit of ISP B must use a 353 destination address drawn from ISP B's address prefix set. The 354 further implication here is that path selection (ISP A vs ISP B 355 transit for incoming packets) is an outcome of the process of 356 selecting an address for the destination host. 358 The architectural consideration here is that in the conventional IP 359 protocol architecture the assumption is made that the transport-layer 360 endpoint identity is the same identity used by the internet-layer 361 forwarding layer, namely the IP address. 363 If multiple forwarding paths are to be supported for a single 364 transport session, and path selection is to be decoupled from the 365 functions of transport session initiation and maintenance, then the 366 corollary of this requirement in architectural terms appears to be 367 that some changes are required in the protocol architecture to 368 decouple the concepts of identification of the endpoint and 369 identification of the location and associated path selection for the 370 endpoint. This change in the protocol architecture would permit a 371 transport session to use an invariant endpoint identity value to 372 initiate and maintain a session, while allowing the forwarding layer 373 to dynamically change paths and associated endpoint locator 374 identities without impacting on the operation of the session, nor 375 would such a decoupled concept of identities and locators add any 376 incremental load to the inter-domain routing system. 378 Some generic approaches to this form of separation of endpoint 379 identity and locator value are described in the following sections. 381 4.3 Multi-homing: Identity Protocol Element 383 One approach to this objective is to add a new element into the model 384 of the protocol stack. 386 The presentation to the upper level protocol stack element (ULP) 387 would use endpoint identifiers to uniquely identify both the local 388 stack and the remote stack. This will provide the ULP with stable 389 identifiers for the duration of the ULP session. 391 The presentation to the lower level protocol stack element (LLP) 392 would be of the form of a locator. This implies that the protocol 393 stack element would need to maintain a mapping of endpoint identifier 394 values to locator values. In a multi-homing context one of the 395 essential characteristics of this mapping is that it needs to be 396 dynamic, in that environmental triggers should be able to trigger a 397 change in mappings, which in turn would correspond to a change in the 398 paths (forward and/or reverse) used by the endpoints to traverse the 399 network. In this way the ULP session is defined by a peering of 400 endpoint identifiers that remain constant throughout the lifetime of 401 the ULP session, while the locators may change to maintain end-to-end 402 reachability for the session. 404 The operation of the new protocol stack element (termed here the 405 "endpoint identity protocol stack element", or "EIP") is to establish 406 a synchronized state with its remote counterpart. This would allow 407 the stack elements to exchange a set of locators that may be used 408 within the context of the session. A change in the local binding 409 between the current endpoint identity value and a locator will cause 410 a change in the source locator value used in the forwarding level 411 packet header. The actions of the remote EIP upon receipt of this 412 packet with the new locator is to firstly recognize this locator as 413 part of an existing session, and, upon some trigger condition, to 414 change its session view of the mapping of the remote endpoint 415 identity to the corresponding locator, and use this locator as the 416 destination locator in subsequent packets passed to the LLP. 418 From the perspective of the IP protocol architecture there are two 419 possible locations to insert the EIP into the protocol stack. 421 One possible location is at the upper level of the transport 422 protocol. Here the application program interface (API) of the 423 application level protocols would interface to the EIP element, and 424 use endpoint identifiers to refer to the remote entity. The EIP would 425 pass locators to the API of the transport layer. 427 The second approach is to insert the EIP between the transport and 428 internet protocol stack elements, so that the transport layer would 429 function using endpoint identifiers, and maintain a transport session 430 using these endpoint identifiers. The IP or internetwork layer would 431 function using locators, and the mapping from endpoint identifier to 432 locator is undertaken within the EIP stack element. 434 4.4 Multi-homing: Modified Protocol Element 436 As an alternative to insertion of a new protocol stack element into 437 the protocol architecture, an alternative approach is to modify an 438 existing protocol stack element to include the functionality 439 performed by the EIP element. This modification could be undertaken 440 within the transport protocol stack element, or within the 441 internetworking stack element. The functional outcome from these 442 modifications would be to create a mechanism to support the use of 443 multiple locators within the context of a single endpoint-to-endpoint 444 session. 446 Within the transport layer, this functionality can be achieved, for 447 example, by the binding of a set of locators to a single session, and 448 then communicating this locator set to the remote transport entity. 449 This would allow the local transport entity to switch the mapping to 450 a different locator for either the local endpoint or the remote 451 endpoint while maintaining the integrity of the ULP session. 453 Within the IP level this functionality could be supported by a form 454 of dynamic rewriting of the packet header as it is processed by the 455 protocol element. Incoming packets with the source and destination 456 locators in the packet header are mapped to packets with the 457 equivalent endpoint identifiers in both fields, and the reverse 458 mapping is performed to outgoing packets passed from the transport 459 layer. Mechanisms that support direct rewriting of the packet header 460 are potential candidates in this approach, as are various forms of 461 packet header transformations of encapsulation, where the original 462 endpoint identifier packet header is preserved in the packet and an 463 outer level locator packet header is wrapped around the packet as it 464 is passed through the internetworking protocol stack element. 466 In all these scenarios, there are common issues of what state is 467 kept, by which part of the protocol stack, how state is maintained 468 with additions, removals of locator bindings, and does only one piece 469 of code have to be aware of the endpoint / locator split or do 470 multiple protocol elements have to be modified? For example, if the 471 functionality is added at the internetworking (IP) layer, there is no 472 context of an active transport session, so that removal of identity / 473 locator state information for terminated sessions needs to be 474 triggered by some additional mechanism from the transport layer to 475 the internetworking layer. 477 4.5 Modified Site-Exit and Host Behaviors 479 The above approaches all assume that the hosts are explicitly aware 480 of the multi-homed environment and use modified protocol behavior to 481 support multi-homing functionality. A further approach to this 482 objective is to split this functionality across a number of network 483 elements and potentially perform packet header rewriting from a 484 persistent endpoint identity value to a locator value at a remote 485 point. 487 One possible approach proposes the use of site-exit routers to 488 perform some form of packet header manipulation as packets are passed 489 out from the local multi-homed site to a particular transit provider. 490 The local site routing system will select the best path to a 491 destination host based on the remote hosts's locator value. The local 492 host will write its endpoint identity as the source address of the 493 packet. When the packet reaches a site-exit router, the site-exit 494 router will rewrite the source field of the packet to a corresponding 495 locator that selects a reverse path through the same transit ISP when 496 the locator is used as a destination locator by the remote host. In 497 order to preserve session integrity there is a need for a 498 corresponding reverse transformation to be undertaken on incoming 499 packets, where the destination locator has to be mapped back to the 500 host's endpoint identifier. There are a number of considerations 501 whether this is best performed at the site exit router on packet 502 ingress to the site, or by the local host. 504 Packet header rewriting by remote network elements has a large number 505 of associated considerations, and documentation relating to the 506 considerations of the use of Network Address Translators ([NAT 507 Considerations] contains much of this material. 509 An alternative for packet header rewriting on site exit is for the 510 host to undertake the endpoint-to-locator mapping, using one of the 511 approaches outlined above. The consideration here is that there is 512 some significant deployment of unicast reverse path filtering in 513 Internet environments as a counter-measure to source address 514 spoofing. Using the example in Figure 1, if a host selects a locator 515 drawn from the ISP B address prefix, and local routing directs that 516 packet to site-exit router A, then if the packet is passed to ISP A, 517 the this would be discarded by such filters. Various approaches have 518 been proposed to modify the behavior of the site forwarding 519 environment all with the end effect that packets using a source 520 locator drawn from the ISP B address prefix are passed to site-exit 521 router B. These approaches include forms of source address routing 522 and site-exit router hand-over mechanisms, as well as augmentation of 523 the routing information between site-exit routers and local 524 multi-homed hosts, so that the choice of locator by the local host 525 for the remote host is consistent with the current local routing 526 state for the local site to reach the remote host. 528 4.6 Approaches to Endpoint Identity 530 Both of the above mechanisms assume some form of exchange of 531 information that allows both parties to the communication to be aware 532 of the remote endpoint identity and the associated mapping to 533 locators. There are a number of choices in terms of the way in which 534 this information exchange can be implemented. 536 The first such possible approach is termed here a 'conventional' 537 approach, where the mode of operation is in terms of encapsulating 538 the protocol data unit (PDU) passed from the ULP with additional data 539 elements that specifically refer to the function of the endpoint 540 identity protocol stack element. The compound data element is passed 541 to the LLP as its PDU. The corresponding actions on receipt of a PDU 542 from a LLP is to extract the fields of the data unit that correspond 543 to the EIP function, and pass the reminder of the PSU to the ULP. The 544 EIP operates in an "in-band" mode, communicating with its remote peer 545 entity through additional information wrapped around the ULP PDU. 547 Another approach is to allow the EIP to communicate using a separate 548 communications channel, where the EIP generates dedicated messages 549 that are directed to its peer EIP, and passes these PDUs to the LLP 550 independently of the PDUs that are passed top the EIP from the ULP. 551 This allows the EIP to exchange information and synchronize state 552 with the remote EIP semi-independently of the ULP protocol exchange. 553 As a part of the EIP function is to transform the ULP PDU to include 554 locator information there is an associated requirement to ensure that 555 the EIP peering state remains synchronized to the exchange of ULP 556 PDUs, so that the remote EIP can correctly recognize the locator to 557 endpoint mapping for each active session. 559 Another potential approach here is to allow the endpoint to locator 560 mappings to be held at a third party point. This model is already 561 used for supporting the name to IP address mappings performed by the 562 Domain Name system, where the mapping is obtained by reference to a 563 third party, namely a DNS resolver. A similar form of third party 564 mapping between endpoints and a locator set could be supported 565 through the use of the DNS, or a similar third party referential 566 mechanism. Rather than have each party exchange endpoint to locator 567 mappings, this approach would see this mapping being obtained as a 568 result of a lookup for a DNS Endpoint to Locator set map contained as 569 DNS Resource Records, for example. 571 4.7 Endpoint Identity Structure 573 The previous section has used the term "endpoint identity" without 574 examining what form this identity may take. There are a number of 575 salient considerations regarding the structure and form of this 576 identity that should be enumerated within an architectural overview 577 of this space. 579 One possible form of an identity is the use of identity tokens lifted 580 from the underlying protocol's "address space". In other words an 581 endpoint identity is a special case instance of an IPv6 protocol 582 address. There are a number of advantages in using this form of 583 endpoint identity, observing that the suite of IP protocols and 584 associated applications already manipulate IP addresses. The 585 essential difference in a domain that distinguishes between endpoint 586 identity and locator is that the endpoint identity parts of the 587 protocol would operate on those addresses that assume the role of 588 endpoint identities, and the EIP mapping function would undertake a 589 mapping from an endpoint "address" to a set of potential locator 590 "addresses", and also undertake a reverse mapping from a locator 591 "address" to the distinguished endpoint identifier "address". The 592 address space is hierarchically structured, permitting a suitably 593 efficient mapping to be performed in both directions, and the 594 underlying semantics of addresses in the context of public networking 595 includes the necessary considerations of global uniqueness of 596 endpoint identity token values. 598 It is possible to take this approach further and allow the endpoint 599 identifier to also be a valid locator. This would impliy the 600 existence of a 'distinguished' or 'home' locator, and other locators 601 could be dynamically mapped to this initial locator peering as 602 required. The drawback of this approach is that the endpoint 603 identifier is now based on one of the transit provider's address 604 prefix, and a change of transit provider would necessarily require a 605 change of endpoint identifier values within the multi-homed site. An 606 alternative approach for address-formatted identifiers is to use 607 address values which are not part of the global unicast locator 608 space, allowing applications and protocol elements to distinguish 609 between endpoint identity values and locators based on address prefix 610 value. It is also possible to allow the endpoint identity and locator 611 space to overlap, and distinguish between the two identity realms by 612 the context of usage rather than by a prefix comparison. 614 It is also feasible to use the fully qualified domain name (FQDN) as 615 an endpoint identity, undertaking a similar mapping as described 616 above, using the FQDN as the lookup "key". The implication here is 617 that there is no default 'address' that is to be associated with the 618 endpoint identifier. 620 The syntactic properties of these two different identity realms have 621 obvious considerations in terms of the manner in which these 622 identities may be used within PDUs. 624 It is also an option to consider a new structured identity space 625 which is not generated through the reuse of IPv6 address values nor 626 drawn from the FQDN. Given that the address space would need to be 627 structured in such a fashion that permits it to be used as a lookup 628 key to obtain the corresponding locator set, the obvious question in 629 such an option is what additional or altered characteristics would be 630 used in such an endpoint identity space that would distinguish it 631 from either of the above approaches? 633 Instead of structured tokens that double as lookup keys to obtain 634 mappings from endpoint identities to locator sets, the alternative is 635 to use an unstructured token space, where individual token values are 636 drawn opportunistically for use within a multi-homed session context. 637 Here the semantics of the endpoint identity are subtly changed. The 638 endpoint identity is not a persistent alias or reference to the 639 identity of the endpoint, but a means to allow an EIP to confirm that 640 two locators are part of the same mapped locator set for an endpoint. 641 In this context the unstructured opportunistic endpoint identifier 642 values are used in determining locator equivalence rather than in 643 some form of lookup function. 645 5. Common Issues for Multi-Homing Approaches 647 The above overview encompasses a very wide range of potential 648 approaches to multi-homing, and each particular approach necessarily 649 has an associated set of considerations regarding its applicability. 651 There are, however, a set of considerations that appear to be common 652 across all approaches, and they are examined in further detail in 653 this section. 655 5.1 Triggering Locator Switches 657 Ultimately, regardless of the method of generation, a packet 658 generated from a local multi-homed host to a remote host must have a 659 source locator in the IP packet that is passed into the transit 660 network. In a multi-homed situation the local multi-homed host has a 661 number of self-referential locators that are equivalent aliases in 662 almost every respect. The difference between locators is the 663 inference that at the remote end the choice of locator may determine 664 the path used to send a packet back to the local multi-homed host. 665 The issue here is how does the local host make a selection of the 666 "best" source locator to use? Obviously the parameters of this 667 selection include the objective to select a locator that represents a 668 currently viable path from the remote host to the local multi-homed 669 host. Local routing information for the multi-homed host does not 670 include this reverse path information. Equally, the local host does 671 not necessarily know of any additional policy constraints that apply 672 to the remote host that may result in a remote host's preference to 673 use one locator over another for the local host. Considerations of 674 unicast reverse path forwarding filters also indicate that the 675 selection of a source locator should result in the packet being 676 passed to a site-exit router that is connected to the associated ISP 677 transit provider, and that the site-exit router passes the packet to 678 the associated ISP. 680 If the local multi-homed host is communicating with a remote 681 multi-homed host, the local host may have some discretion in the 682 choice of a destination locator. The considerations relating to the 683 selection of a destination locator include considerations of local 684 routing state (to ensure that the chosen destination locator reflects 685 a viable path to the remote endpoint), policy constraints that may 686 determine a "best" path to the remote endpoint. In such situations it 687 may also be the case that the source address selection should also be 688 considered in relation to the destination locator selection. 690 Another common issue is the consideration of the point when a locator 691 is not considered to be viable, and the consequences to the transport 692 session state. 693 o Transport Layer Triggers 695 A change in state for a currently used path to another path could 696 be triggered by indications of packet loss along the current path, 697 or by transport session timeouts, assuming an internal signalling 698 mechanism between the transport stack element and the locator pool 699 management stack element. 700 o Routing Triggers 702 Alternatively, in the absense of local transport triggers, the 703 site exit router could communicate failure of the outbound 704 forwarding path in the case where the remote host is multi-homed 705 with an associated locator set. Conventional routing would be 706 incapable of detecting a failure in the inbound forwarding path, 707 so there are some limitations in the approach of using routing 708 triggers to change locator bindings. 709 o Heartbeat Triggers 711 An alternative to these approaches is the use of a session 712 heartbeat protocol, where failure of the heartbeat would cause the 713 session to seek a new locator binding that would re-establish the 714 heartbeat. 716 The sensitivity of the locator-switch trigger is a consideration 717 here. A very fine-grained sensitivity of the locator switch trigger 718 may generate false triggers arising from short-term transient path 719 congestion, while coarse-grained triggers may impose an undue 720 performance penalty on the session due to an extended time to detect 721 a path failure. 723 5.2 Session Startup and Maintenance 725 The next issue if that of the difference between the initial session 726 startup mode of operation and the maintenance of the session state. 728 In a split endpoint identifier / locator environment there needs to 729 be at least one initial locator associated with an endpoint 730 identifier in order to establish an initial connection between the 731 two hosts. This locator could be loaded into the DNS in a 732 conventional fashion, or, if the endpoint identifier is a 733 distinguished address value, the initial communication could be 734 established using the endpoint identifier in the role of a locator 735 (i.e. using this as a conventional address). 737 The initial actions in establishing a session would be simular. If 738 the session is based on specification of a FQDN, the FQDN is first 739 mapped to an endpoint identity value, and this endpoint identity 740 value could then be mapped to a locator set. The locators in this set 741 are then candidate locators for use in establishing an initial 742 synchronized state between the two hosts. Once the state is 743 established it is then possible to update the initial locator set 744 with the current set of useable locators. This update could be part 745 of the initial synchronization actions, or deferred until required. 747 This leads to the concept of the use of a 'distinguished' locator 748 that acts as the endpoint identifier, and a pool of alternative 749 locators that are associated with this 'home' locator. This 750 association may be statically defined, using referential pointers in 751 a third party referral structure (such as the DNS), or dynmically 752 added to the session through the actions of the endpoint identity 753 protocol stack element, or both. 755 6. Security Considerations 757 There are a significant number of security considerations that result 758 from the action of distinguishing within the protocol suite endpoint 759 identity and locator identity. 761 It is not proposed to enumerate these considerations in detail within 762 this draft, but to provide a distinct document that describes the 763 security considerations of this domain. Subsequent revisions of this 764 draft will refer the reader to this yet-to-be-drafted document. 766 7. Acknowledgements 768 The author acknowledges the exensive contribution of Margaret 769 Wasserman in preparing the original draft of the summary of current 770 approaches to multi-homing. 772 Normative References 774 Author's Address 776 Geoff Huston 777 Telstra 779 Appendix A. Notes on Various approaches 781 These notes were orginally drafted by Margaret Wasserman. The notes 782 on various approaches are non-exclusive, i.e. solutions not reviewed 783 or mentioned here are not ruled out of discussion. Also the review 784 comments are not comprehensive, and the selection reflects the time 785 constraints of the contributors to this section than any qualititive 786 judgement on any of the approaches. The author is desirous, in future 787 revisions of this draft, in augmenting this selection of reviewed 788 approaches. 790 A.1 Host Identity Protocol (HIP) 792 HIP is an ID/Locator separation mechanism intended to solve a much 793 wider problem space than site multi-homing. HIP uses cryptographic 794 identifiers termed Host Identity Tags (HITs) at the application 795 layer, which are mapped to locators (IP Addresses) by a HIP protocol 796 stack layer that interfaces between the transport layer and IP 797 internetwork layer. 799 The essential characteristic of HIP is it use of opportunistic 800 identity generation, as it uses a cyptographic host identifier as the 801 basis of the persistent identity. The transport session cab be agile 802 across locators, or even across IP protocol versions, as the HIT is 803 used to determine session integrity. allowing the hosts to determine 804 what packets legitimately form part of the session. 806 HIP is proposed as a new protocol element, located at layer 3.5 (i.e. 807 above the internetwork IP layer and below the transport layer). The 808 presentation to the transport layer uses 128 bit hash values (the 809 HIT) in place of IP addresses, while the presentation to the internet 810 layer uses conventional IP addresses. 812 Being opportunistic and unstructured, the HIT space is not an 813 efficient search space, nor can a HIT be used as a unique search key. 814 HITs are part of an an equivalence function, to allow each host to 815 determine that an incoming packet is part of an established session. 816 HITs cannot be used as an identity value in a conventional referral 817 sense (HostA wants to tell HostB to talk to HostC). While an 818 application could pass a HIT to a third-party (and legacy 819 applications would unknowingly do so), the third party would have no 820 way to map that HIT to a locator (an IP address) as HIP does not 821 include any global HIT->Locator mapping mechanism. 823 Summary: 824 o New Protocol Stack Element 825 o Layer 3.5 (Above IP, below Transport 826 o Unstructured, opportunistic identity values (non-referential) 827 o DNS rendezvous 828 o No Locator exchange protocol 830 Current IETF Documents: 831 o draft-moskowitz-hip-arch 832 o draft-moskowitz-hip 833 o draft-nikander-hip-mm 834 o draft-nikander-esp-beet-mode 836 A.2 Multihoming without IP Identifiers (NOID) 838 NOID proposes an approach for endpoint identifier and locator 839 separation where the endpoint identifier space is drawn from the 840 locator space. Instead of creating a new namespace for endpoint 841 identifiers, the endpoint identifier may be chosen from the set of 842 locators that can be used to reach a given endpoint. Until an event 843 occurs that modifies the list of usable locators, the initial 844 endpoint identifier value can serve as a locator. 846 NOID uses next-header values in the IPv6 header to indicate whether a 847 given packet should be processed by the NOID layer. At a conceptual 848 level, NOID adds a layer to the middle of IP above most IP 849 processing, but below IPSec, fragmentation and reassembly functions. 851 NOID makes use of the global DNS as a mapping system between IDs and 852 Locators. A node who wishes to communicate with another node can use 853 the FQDN to get a list of possible locators (IP Addresses). That node 854 will then choose one of the locators to use as an Application-level 855 ID (AID). 857 NOID offers some support for application referrals. If Host A passes 858 an AID to Host B that is supposed to point to Host C, Host B should 859 be able to do a reverse DNS lookup to map the AID to an FQDN and then 860 use the FQDN to get the complete set of locators. However, for this 861 to be effective, nodes would need to have both forward and reverse 862 DNS entries. There might also be a need to dynamically update the DNS 863 as a node becomes reachable or unreachable at certain locators. 865 Summary: 866 o New Protocol Stack Element 867 o Layer 3 (Inserted in the upper part of IP, below IPSEC and 868 fragementation / reassembly 869 o Identity values based on locator set 870 o DNS rendezvous 871 o Identity peering protocol 873 Current IETF Documents: 874 o draft-nordmark-multi6-noid 875 o draft-templin-isnoid 877 A.3 Common Endpoint Locator Pools (CELP) 879 CELP explores the concept of sharing information about locator 880 reachability between transport-layer "multi-addressing" mechanisms 881 (such as SCTP and DCCP) and Internet-layer multiaddressing 882 mechanisms, referred to in the draft as "wedge-layer approaches" 883 (such as NOID). (This concept was originally discussed on the MULTI6 884 mailing list under the name 'SLAP'.) 886 The motivation behind CELP is that muliple multiaddressing mechanisms 887 may be used (by different applications or for different connections) 888 on a single endpoint, and that it would beneficial for those 889 mechanisms to share information about the reachability of the IP 890 addresses in a given locator pool. If a transport-layer mechansim, 891 such as SCTP, could share its knowledge regarding the reachability of 892 a certain locator, it might be possible to minimize or elimate 893 Internet-layer control packets that are used to maintain that 894 information at the Internet layer. In some ways, this is similar to 895 IPv6 Neighbor Discovery's use of upper layer advice regarding 896 neighbor reachability to avoid sending unncecessary ND packets. 898 This document offers a definition of the term "endpoint" that refers 899 to a locator pool that may have a smaller scope than an entire IP 900 node (i.e. a given locator pool may only contain a subset of the 901 locators available on an IP node). 903 The CELP document is more of a consideration of approach than an 904 actual proposal for a solution. It doesn't specify in detail how it 905 would work with any particular transport-layer or Internet-layer 906 multiaddressing mechanisms. However, it is an approach that could be 907 applied to many combinations of solutions. 909 Summary: 910 o Considerations relating to sharing locator reachability 911 information across session instances. 913 Current IETF Documents: 914 o draft-crocker-celp 916 A.4 Weak Identifier Multihoming Protocol (WIMP) 918 WIMP is an endpoint identifier / locator separation protocol that is 919 heavily focused on mitigating the threats outlined in work in 920 progress on security threats in multi-homing scenarios 921 [draft-nordmark-multi6-threats-00.txt]. The WIMP approach uses 922 divided secrets and hash chaining to ensure that new locators are 923 supplied by the same node that supplied the original locator. 925 WIMP uses a separate name space for 128-bit non-routable IDs that are 926 never used in packets on the network. These IDs are locally generated 927 for both local and remote nodes by hashing a nonce (for the 928 initiator's endpoint identity) or the FQDN (for the responder's 929 endpoint identity). (The approach assumes a requirement that all 930 responders will have a FQDN.) 932 The WIMP protocol introduces a WIMP layer that maps between IDs and 933 locators based on internal state. The WIMP layer is conceptually 934 located within the network layer, above most IP processing and below 935 IPsec, fragmentation/reassembly and destination options, similar to 936 NOID. 938 Communication between two end-points requires establishment of a WIMP 939 session. Once the session is established, it can be used for multiple 940 simultaneous or sequential connections to the same end-point. During 941 WIMP session establishment, WIMP introduces a separate header into 942 the data packets, between the IP and TCP/UDP headers that contains 943 information about the WIMP session. The WIMP session establishment 944 packets can optionally be piggy-backed on data packets. WIMP does not 945 introduce a separate header into all IPv6 packets. Instead, once a 946 WIMP session is established, the IPv6 FlowID is used to hold an 947 identifier for the WIMP host-pair context associated with a given 948 packet. 950 WIMP is intended to provide a solution to some of the security 951 concerns, particularly regarding connection hijacking, that have been 952 raised for some other endpoint identity / locator separation 953 mechanisms. 955 Reviewers of WIMP have raised some questions of this approach, 956 particularly concerning the use of an optional header while operating 957 below IP fragmentation. The piggy-backing mechanism requires that the 958 packets not be fragmented, but it doesn't explain how upper layers 959 will become aware of the MTU limitations on those packets and/or how 960 this mechanism would interact with Path MTU discovery. Like HIP, WIMP 961 makes no provision to handle application-level referrals and does not 962 contain a mechanism for global endpoint identifier to locator 963 mapping. It has also been pointed out that it is interesting to 964 consider whether the WIMP approach to security, hash chaining, could 965 be applied to other endpoint identity / locator separations 966 mechanisms, such as NOID. 968 Summary: 969 o New Protocol Stack Element 970 o Layer 3 (Inserted in the upper part of IP, below IPSEC and 971 fragementation / reassembly 972 o Identity values based on hash of FQDN 973 o Identity peering protocol 975 Current IETF Documents: 976 o draft-ylitalo-multi6-wimp 978 A.5 Host-Centric IPv6 Multihoming 980 Host-Centric Multihoming is, in some ways, the simplest way to 981 address the IPv6 site multihoming problem. The concept is that every 982 host in the multihomed site is configured with multiple prefixes that 983 correspond to different service providers. Each host configures 984 addresses within those prefixes and selects among those addresses 985 when connecting to a remote host. This configuration is automated 986 using Router Renumbering and IPv6 Address Autoconfiguration. However, 987 this simple solution Layer 3 (inserted in the upper part of IP, below 988 IPSEC and fragementation / reassembly has several practical 989 limitations and drawbacks, and this draft attempt to address them. 991 In particular, the Host-Centric Multihoming proposal attempts to 992 address the "site exit issue". Hosts cannot control the exit path 993 that their packets will take from the local site, so hosts with 994 multiple addresses may use a source IP address from one ISP on 995 packets that end-up being routed through a different ISP. In many 996 cases, the ISPs will run ingress filtering and will discard those 997 packets. 999 One solution to the site exit problem is to changes the ISP ingress 1000 filters to accept all of the source address prefixes that are used 1001 within the site. Other approaches are to perform source-based routing 1002 within the site, to deploy a single site-exit router or to structure 1003 the network so that all exit routers are connected to a single DMZ 1004 network that employs source-based routing. A virtual DMZ can be 1005 constructed by configuring a mesh of tunnels between all exit 1006 routers, tunneling packets to the correct exit router based on source 1007 address. Each of these solutions has operational drawbacks and/or 1008 introduces inefficiencies. 1010 This proposal suggests another solution to the site exit problem 1011 called "source address discovery". Based on Path MTU discovery, this 1012 mechanism involves adding extra information to the ICMP Destination 1013 Unreachable message that the packet was discarded due to an ingress 1014 filter. This extra information indicates what address prefix should 1015 be used to pass the ingress filter. Rather than adding a field to the 1016 ICMP message, this extra information is communicated via the source 1017 address that the route Layer 3 (Inserted in the upper part of IP, 1018 below IPSEC and fragementation / reassembly). 1020 It also proposes a "superior" alternative called "exit router 1021 discovery", which allows hosts to specify which exit router will be 1022 used for each packet. Instead of sending ICMP error messages when 1023 ingress filtering causes packets to be discarded, the exit router 1024 will send the equivalent of a redirect message and future packets 1025 with the same source/destination address pair will be tunneled to the 1026 indicated exit router. This mechanism involves tunneling to a 1027 site-exit anycast address that is derived from the sites' prefixes. 1028 The draft primary focuses on the specification of this "superior" 1029 approach, largely ignoring some pertinent questions such as: Will 1030 residential and enterprise-level IPv6 routers reall support anycast 1031 routing? 1033 One important thing to note about the host-centric multihoming 1034 solution is that it doesn't appear to provide any ability for 1035 transport connections to survive a change in the topology that causes 1036 a host to become unreachable at an address that is currently used as 1037 a connection end-point. It also does not offer any support for legacy 1038 applications that do application-level referrals, requiring that a 1039 full set of locators be exchanged as part of the referral. 1041 A.6 Summaries of Selected ID/LOC Separation Documents 1043 This section summarizes a set of selected ID/Loc separation 1044 documents. The selection includes documents that appear to be active, 1045 and this section provides a very short summary of each one. The first 1046 sub-section lists documents that are new or updated since IETF 58 and 1047 the second sub-section lists older documents that remain active. The 1048 documents in each sub-section are listed alphabetically by draft 1049 filename. 1051 A.6.1 New or Updated Documents Since IETF58 1053 o TLC-FM: Transport Layer Common Framework for Multihoming 1054 draft-arifumi-multi6-tlc-fm 1055 This draft proposes a transport-layer mechanism for ID /Locator 1056 mapping. There is a conceptual layer within the transport layer 1057 that provides support for common multihoming functions. It is 1058 compatible with the use of Mobile IPv6 (MIP6) to provide 1059 mobility support. 1060 In TLC-FM, like SCTP, the ID consists of a collection of 1061 locators that may be used to reach a given host. It employs 1062 transport-level clues (such as TCP retransmissions) to decide 1063 when to switch locators. For UDP connections, ICMP error 1064 messages or application-level hints are necessary. 1065 This mechanism is not well enough specified to fully evaluate 1066 it, but it doesn't appear to offer any support for 1067 application-level referrals. 1069 o Multi-Homing Tunnel Broker (MHTB) 1070 draft-bagnulo-multi6-mhtb 1071 This document defines an enhancement to RFC 3178, IPv6 1072 Multihoming Support at Site Exit Routers, to reduce the 1073 administrative overhead of maintaining a configured tunnel for 1074 each multihoming association. However, this draft does not 1075 address another major drawback of the RFC 3178 approach, that 1076 it does not protect against the complete failure of one or more 1077 connected ISPs. 1079 o Framework for Common Endpoint Locator Pools (CELP) 1080 draft-crocker-celp 1081 Dave Crocker and Avri Doria's CELP draft, reviewed in the 1082 previous section. 1084 o Multi-Homing: the SCTP Solution 1085 draft-coene-multi6-sctp 1086 One confusing question about the direction of this work is why 1087 SCTP is being discussed as a "solution" to site multihoming, 1088 when a clear requirement for a site multihoming solutions is 1089 the ability to support existing TCP-based and UDP-based 1090 applications. This document isn't really a proposal, though -- 1091 it consists of answers to the questions posted in Eliot Lear's 1092 "Things MULTI6 Developers Should Think About" draft, and does 1093 not discuss how SCTP does (or doesn't) address the requirements 1094 outlined in the Multi6 requirements RFC. 1095 An interesting thing about this proposal is that it claims that 1096 SCTP is not an ID/Loc separation mechanism, however in some 1097 academic sense it actually is. The ID is the group of available 1098 IP addresses, and the locator is whichever address is currently 1099 being used for communication. SCTP also experiences the same 1100 complexities as other proposals (AKA NOID, CELP) that use a 1101 pool of locators as the ID -- How do you choose which locator 1102 to use? And how do you detect when a member of the pool becomes 1103 invalid for use as a locator? So, while it isn't actually a 1104 solution for site multihoming, SCTP may provide some useful 1105 experiences and mechanisms that may apply to a class of 1106 possible solutions. 1108 o Host Identity Protocol (HIP) Rendezvous Mechanisms 1109 draft-eggert-hip-rendezvous-00.txt 1110 This is an overview draft that discusses the concept of HIP 1111 rendezvous mechanisms to improve the applicability of HIP for 1112 mobility and multihoming. This is a survey document that 1113 outlines the problem and discusses different type of solutions 1114 to the problem. 1116 o Host-Centric IPv6 Multihoming 1117 draft-huitema-multi6-hosts 1118 Draft by Christian Huitema and others, described above. 1120 o Things MULTI6 Developers Should Think About 1121 draft-lear-multi6-things-to-think-about 1122 Eliot Lear's efforts to collect a set of practical questions 1123 that should be considered for all MULTI6 protocols. 1125 o Host Identity Protocol (HIP) 1126 draft-moskowitz-hip 1127 This is the base protocol specification for HIP. Along with the 1128 HIP architecture, these documents form the basis of the HIP 1129 work. 1131 o Consideration on HIP Based IPv6 Multi-Homing 1132 draft-nikander-multi6-hip 1133 Pekka Nikander's document that submits HIP as a solution for 1134 the MULTI6 problem space. 1136 o 8+8 Addressing for IPv6 End to End Multihoming 1137 draft-ohta-multi6-8plus8 1139 o Threats Relating to Transport Layer Protocols Handling Multiple 1140 Addresses 1141 draft-ohta-multi6-threats 1143 o Multihoming Using IPv6 Addressing Derived from AS Numbers 1144 draft-savola-multi6-asn-pi 1145 This draft provides a mechanism for organizations that have 1146 been assigned a 16-bit AS number to use that number to 1147 auto-generate a globally routable, provider-independent address 1148 prefix. 1150 o Problem Statement: HIP Operation over Network Address Translators 1151 draft-stiemerling-hip-nat 1152 Summarizes the problems with running HIP and IPsec-based data 1153 transmission across NATs. 1155 o Operational Approach to Achieve IPv6 Multihomed Network 1156 draft-toyama-multi6-operational-site-multihoming 1157 This document proposes to support site multihoming in IPv6 by 1158 assigning additional /32 prefixes and AS numbers to "groups" of 1159 providers who will provide multihomed /48 prefixes to their 1160 mutual customers. 1161 It is currently unclear to the reviewer how/if this proposal 1162 would work and/or scale since it seems to involve two different 1163 providers advertising the same /32 and the same AS number into 1164 the default free zone. It requires some type of peering "to 1165 share prefix assignments" between ISPs, and the diagram shows 1166 some type of connection between the ISPs, but I don't know what 1167 the details of that connection are. 1168 It also has the potential to more quickly exhaust the AS number 1169 space and to result in a substantially larger number of routes 1170 in default free routers, since the number of "groups" could 1171 scale exponentially with the number of providers. 1173 o Crypto Based Host Identifiers (CBHI) 1174 draft-van-beijnum-multi6-cbhi 1175 This draft defines a crytographic mechanism for generating host 1176 identifiers. It is intended for use with other protocols that 1177 require host identifiers, such as ODT (see below). 1179 o On Demand Tunneling for Multihoming (ODT) 1180 draft-van-beijnum-multi6-odt 1181 This draft discusses an automatic tunnelling-based solution for 1182 multihoming. 1184 o Weak Identifier Multihoming Protocol (WIMP) 1185 draft-ylitalo-multi6-wimp 1186 WIMP proposal, described above. 1188 A.6.2 Older Documents that Remain Active/Interesting 1190 o RFC 3582: Goals for IPv6 Site-Multihoming Architectures 1192 o Choices for Multiaddressing 1193 draft-crocker-mast-analysis 1195 o What's In a Name: Thoughts from the NSRG 1196 draft-irtf-nsrg-report 1198 o A Roadmap for Multihoming in IPv6 1199 draft-kurtis-multi6-roadmap 1201 o Host Identity Protocol (HIP) Architecture 1202 draft-moskowitz-hip-arch-05.txt 1204 o End-Host Mobility and Multi-Homing with Host Identity Protocol 1205 (HIP) 1206 draft-nikander-hip-mm 1208 o Threats Relating to IPv6 Multihoming Solutions 1209 draft-nordmark-multi6-threats-00.txt 1211 o Multihoming without IP Identifiers (NOID) 1212 draft-nordmark-noid 1213 Erik Nordmark's NOID specification, described above. 1215 A.6.3 Related Multi-Homing drafts, Status unknown 1217 This is a list of ID/Loc separation and/or MULTI6 documents, listed 1218 alphabetically by draft name. 1219 o Extension Header for Site-Multi-homing Support 1220 draft-bagnulo-multi6-mhexthdr 1222 o Application of the MIPv6 Protocol to the Multi-Homing Problem 1223 draft-bagnulo-multi6-mnm 1225 o Multiple Address Service for Transport (MAST): An Extended 1226 Proposal 1227 draft-crocker-mast-proposal 1229 o NAROS : Host-Centric IPv6 Multihoming with Traffic Engineering 1230 draft-de-launois-multi6-naros 1232 o Application and Use of the IPv6 Provider Independent Global 1233 Unicast Format 1234 draft-hain-ipv6-pi-addr-use 1236 o Simple Dual Homing Experiment 1237 draft-huitema-multi6-experiment-00.txt 1239 o Host-Centric IPv6 Multihoming 1240 draft-huitema-multi6-hosts 1242 o IPv4 Multihoming 1243 draft-ietf-multi6-v4-multihoming 1244 This documents how multi-homing is supported at present in the 1245 IPv4 protocol domain. 1247 o Multihoming in IPv6 by Multiple Announcement of Longer Prefixes 1248 draft-kurtis-multihoming-longprefix 1250 o Multihoming using 64-bit Crypto-based IDs 1251 draft-nordmark-multi6-cb64 1253 o Strong Identity Multihoming using 128-bit Identifiers (SIM/ 1254 CBID128) 1255 draft-nordmark-multi6-sim 1257 o IPv6 Address Assignment and Route Selection for End-to-End 1258 Multihoming 1259 draft-ohira-assign-select-e2e-multihome 1261 o Hierarchical IPv6 Subnet ID Autoconfiguration for Multi-Address 1262 Model Multi-Link Multihoming Site 1263 draft-ohira-multi6-multilink-auto-prefix-assign 1265 o Hierarchical IPv6 Subnet ID Autoconfiguration for Multi-Address 1266 Model Multi-Link Multihoming Site 1267 draft-ohira-multi6-multilink-auto-prefix-assign 1269 o The Architecture of End to End Multihoming 1270 draft-ohta-e2e-multihoming-05.txt 1272 o 8+8 Addressing for IPv6 End to End Multihoming 1273 draft-ohta-multi6-8plus8-00.txt 1275 o Threats Relating to Transport Layer Protocols Handling Multiple 1276 Addresses 1277 draft-ohta-multi6-threats-00.txt 1279 o Multihomed ISPs and Policy Control 1280 draft-ohta-multihomed-isps-00.txt 1282 o GAPI: A Geographically Aggregatable Provider Independent Address 1283 Space to Support Multihoming in IPv6 1284 draft-py-multi6-gapi 1286 o Multi Homing Translation Protocol (MHTP 1287 draft-py-multi6-mhtp-01.txt 1289 o Multihoming Using IPv6 Addressing Derived from AS Numbers 1290 draft-savola-multi6-asn-pi-01.txt 1292 o IPv6 Site Multihoming: Now What? 1293 draft-savola-multi6-nowwhat 1295 o Operation of NOID Multihoming Protocol on ISATAP Nodes 1296 draft-templin-isnoid 1298 o LIN6: A Solution to Multihoming and Mobility in IPv6 1299 draft-teraoka-multi6-lin6 1301 o Operational Approach to achieve IPv6 multihomed network 1302 draft-toyama-multi6-operational-site-multihoming-00.txt 1304 o Two Prefixes in One Address 1305 draft-van-beijnum-multi6-2pi1a-00.txt 1307 o Crypto Based Host Identifiers 1308 draft-van-beijnum-multi6-cbhi-00.txt 1310 o Provider-Internal Aggregation based on Geography to Support 1311 Multihoming in IPv6 1312 draft-van-beijnum-multi6-isp-int-aggr-01.txt 1314 o On Demand Tunneling For Multihoming 1315 draft-van-beijnum-multi6-odt-00.txt 1317 Intellectual Property Statement 1319 The IETF takes no position regarding the validity or scope of any 1320 intellectual property or other rights that might be claimed to 1321 pertain to the implementation or use of the technology described in 1322 this document or the extent to which any license under such rights 1323 might or might not be available; neither does it represent that it 1324 has made any effort to identify any such rights. Information on the 1325 IETF's procedures with respect to rights in standards-track and 1326 standards-related documentation can be found in BCP-11. Copies of 1327 claims of rights made available for publication and any assurances of 1328 licenses to be made available, or the result of an attempt made to 1329 obtain a general license or permission for the use of such 1330 proprietary rights by implementors or users of this specification can 1331 be obtained from the IETF Secretariat. 1333 The IETF invites any interested party to bring to its attention any 1334 copyrights, patents or patent applications, or other proprietary 1335 rights which may cover technology that may be required to practice 1336 this standard. Please address the information to the IETF Executive 1337 Director. 1339 Full Copyright Statement 1341 Copyright (C) The Internet Society (2004). All Rights Reserved. 1343 This document and translations of it may be copied and furnished to 1344 others, and derivative works that comment on or otherwise explain it 1345 or assist in its implementation may be prepared, copied, published 1346 and distributed, in whole or in part, without restriction of any 1347 kind, provided that the above copyright notice and this paragraph are 1348 included on all such copies and derivative works. However, this 1349 document itself may not be modified in any way, such as by removing 1350 the copyright notice or references to the Internet Society or other 1351 Internet organizations, except as needed for the purpose of 1352 developing Internet standards in which case the procedures for 1353 copyrights defined in the Internet Standards process must be 1354 followed, or as required to translate it into languages other than 1355 English. 1357 The limited permissions granted above are perpetual and will not be 1358 revoked by the Internet Society or its successors or assignees. 1360 This document and the information contained herein is provided on an 1361 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1362 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1363 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1364 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1365 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1367 Acknowledgment 1369 Funding for the RFC Editor function is currently provided by the 1370 Internet Society.