idnits 2.17.1 draft-ietf-multi6-architecture-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1836. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1813. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1820. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1826. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 10, 2005) is 7008 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) -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Multi6 G. Huston 2 Internet-Draft APNIC 3 Expires: August 11, 2005 February 10, 2005 5 Architectural Approaches to Multi-Homing for IPv6 6 draft-ietf-multi6-architecture-04.txt 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 11, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This memo provides an analysis of the architectural aspects of 42 multi-homing support for the IPv6 protocol suite. The purpose of 43 this analysis is to provide a taxonomy for classification of various 44 proposed approaches to multi-homing. It is also an objective of this 45 exercise to identify common aspects of this domain of study, and also 46 to provide a framework that can allow exploration of some of the 47 further implications of various architectural extensions that are 48 intended to support multi-homing. 50 Document Revision Notes 52 [RFC Editor: Please remove this section prior to publication.] 54 The following changes have been made to the draft: 56 draft-ietf-multi6-architecture-04: 58 Spell and Grammar check 59 A number of changes of spelling and grammar errors arising from 60 IESG review. 62 Section 5.1 Multi-Homing: Routing 63 Added text relating to the risks to transport layer 64 surviveability when routing convergence gnerates unstable 65 temporary path states, and takes an indeterminate time to 66 complete. 68 Section 6.3.1 Triggering Locator Switches 69 Added note about different trigger responses being required 70 from different transport sessions, arising from IESG review. 72 Section 6.3.4 Session Startup and Maintenance 73 Note that the search for a viable locator set expands to a 74 pairwise search if both the local and remote end are 75 multi-homed. 77 Section 7.2 Rehoming Triggers 78 Added questions regarding transport considerations, arising 79 from IESG review. 81 draft-ietf-multi6-architecture-03: 83 Section 2 Terminology 84 Added a Terminology section. 86 Section 6.3.1 Triggering Locator Switches 87 Added a section on link indication triggers. 89 Section 5.3 Multi-homing: Identity Considerations 90 Rewording of first sentence. 92 Section 3 The Multi-homing Space 93 Rewording of paragraphs concerning objectives to clarify the 94 difference between session surviveability and session 95 establishment objectives, and rewording of paragraph relating 96 to traffic engineering objectives. 98 draft-ietf-multi6-architecture-02: 100 Minor nits 101 Added null IANA Considerations, section. Minor grammatical 102 correction to the abstract, Sections 4.2, 5,and 5.2 . 104 Section 6.3.3 Layering Identity 105 Additional text regarding requirement for additional 106 information to be passed between transport, internet and 107 identity protocol elements. 109 draft-ietf-multi6-architecture-01: 111 Section 5.2: Multi-homing: Mobility 112 New section added based on contribution from Marcelo Bagnulo. 114 0 115 Section 6.2: Persistent, Opportunistic and Ephemeral Identities 116 Additional text added about considerations if id/locator split 117 in persistent identities and the requirements of multi-homing. 119 Appendix A:Notes on Various approaches 120 This section removed, to be replaced by a new WG document. 122 draft-ietf-multi6-architecture-00: 124 Notes: IPv6 125 Added text outlining the MIPv6 return routeability tests and 126 the implications of this approach with multi-homing. 128 Section 3: The Multi-Homing Space 129 Added text on session initiation by the local host in the 130 circumstance of degraded 131 Section 6.3.1 Triggering Locator Switches 132 Added a section on link indication triggers. 134 Section 5.3 Multi-homing: Identity Considerations 135 Rewording of first sentence. 137 Section 3 The Multi-homing Space 138 Rewording of paragraphs concerning objectives to clarify the 139 difference between session surviveability and session 140 establishment objectives, and rewording of paragraph relating 141 to traffic engineering objectives. 143 path connectivity. 145 Section 5.2: Multi-homing: Identity Considerations 146 Added text on session initiation by the local host in the 147 circumstance of degraded path connectivity. Also added text to 148 cover the case that the remote host may need to discover the 149 need to perform a locator switch for the multi-homed host in 150 ways other than direct notification from the local end. 152 Section 5.4: Multi-homing: Modified Protocol Element 153 Change "single endpoint-to-endpoint session" to "single 154 endpoint to single endpoint communication". 156 Section 5.5: Modified Site-Exit and Host Behaviors 157 Change NAT analysis reference to the multi6-threats draft. 159 Section 6.1 Endpoint Identity Structure 160 Added a qualification about unstructured identities and their 161 utility as a resolution key. 163 Section 6.3.2 Locator Selection 164 Added this section which describes the considerations of 165 traffic engineering in the context of locator selection. 167 Section 6.3.3 Layering Identity 168 Added qualification about use of transport (session) identities 169 for UDP. 171 Section 7.1 Establishing Session State 172 Qualified the use of "transport" to be "identity protocol 173 element", indicating that this may be transport, IP of a wedge 174 layer, and edited the text to reflect multi-homing capabilities 175 in the protocol stack. Added text on locator discovery and 176 selection in the functional decomposition of session 177 establishment. 179 draft-huston-multi6-architectures-01: 181 Section 3: The Multi-Homing Space 182 Added text to include consideration of session initiation in 183 the face of changes to the connectivity topology, and a note 184 about the potential to consider traffic engineering across 185 multiple paths. 187 Section 4: Functional Goals and Considerations 188 Changed 'requirements' to 'goals'. 190 Section 6.1 Endpoint Identity Structure 191 Added consideration of disambiguating locators and identities 192 when identities are drawn from the same address space as 193 locators. Added text about identities drawn from PA space and 194 the problems this raises. Also added text about disambiguating 195 DNS FQDN pseudo-anycast from DNS-based multi-homing with 196 equivalent locator sets. 198 Section 6.2 Persistent, Opportunistic and Ephemeral Identities 199 New section added to the draft considering the implications of 200 these three approaches to identity. 202 Section 6.3.1 Triggering Locator Switches 203 Added section on ICMP triggers. 205 Section 6.3.3 Layering Identity 206 New section added, considering the implications of placing 207 endpoint identity functionality in the transport or 208 internetwork protocol elements, or as a wedge element, 209 conceptually placed between these two elements. 211 Section 7. Functional Decomposition of Multi-Homing Approaches 212 New section added. 214 Table of Contents 216 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7 217 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 218 3. The Multi-Homing Space . . . . . . . . . . . . . . . . . . . . 9 219 4. Functional Goals and Considerations . . . . . . . . . . . . . 11 220 5. Approaches to Multi-Homing . . . . . . . . . . . . . . . . . . 11 221 5.1 Multi-Homing: Routing . . . . . . . . . . . . . . . . . . 12 222 5.2 Multi-Homing: Mobility . . . . . . . . . . . . . . . . . . 13 223 5.3 Multi-homing: Identity Considerations . . . . . . . . . . 15 224 5.4 Multi-homing: Identity Protocol Element . . . . . . . . . 18 225 5.5 Multi-homing: Modified Protocol Element . . . . . . . . . 19 226 5.6 Modified Site-Exit and Host Behaviors . . . . . . . . . . 20 227 6. Approaches to Endpoint Identity . . . . . . . . . . . . . . . 21 228 6.1 Endpoint Identity Structure . . . . . . . . . . . . . . . 22 229 6.2 Persistent, Opportunistic and Ephemeral Identities . . . . 24 230 6.3 Common Issues for Multi-Homing Approaches . . . . . . . . 27 231 6.3.1 Triggering Locator Switches . . . . . . . . . . . . . 27 232 6.3.2 Locator Selection . . . . . . . . . . . . . . . . . . 30 233 6.3.3 Layering Identity . . . . . . . . . . . . . . . . . . 31 234 6.3.4 Session Startup and Maintenance . . . . . . . . . . . 32 235 6.3.5 Dynamic Capability Negotiation . . . . . . . . . . . . 34 236 6.3.6 Identity Uniqueness and Stability . . . . . . . . . . 35 237 7. Functional Decomposition of Multi-Homing Approaches . . . . . 36 238 7.1 Establishing Session State . . . . . . . . . . . . . . . . 36 239 7.2 Rehoming Triggers . . . . . . . . . . . . . . . . . . . . 36 240 7.3 Rehoming Locator Pair Selection . . . . . . . . . . . . . 37 241 7.4 Locator Change . . . . . . . . . . . . . . . . . . . . . . 37 242 7.5 Removal of Session State . . . . . . . . . . . . . . . . . 37 243 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 244 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 245 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 246 11. Informative References . . . . . . . . . . . . . . . . . . . 38 247 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 39 248 Intellectual Property and Copyright Statements . . . . . . . . 40 250 1. Introduction 252 The objective of this analysis is to allow various technical 253 proposals relating to the support of multi-homing environment in IPv6 254 to be placed within an architectural taxonomy. This is intended to 255 allow these proposals to be classified and compared in a structured 256 fashion. It is also an objective of this exercise to identify common 257 aspects across all proposals within this domain of study, and also to 258 provide a framework that can allow exploration of some of the further 259 implications of various architectural extensions that are intended to 260 support multi-homing. The scope of this study is limited to the IPv6 261 protocol suite architecture, although reference is made to IPv4 262 approaches as required. 264 2. Terminology 266 Care of Address (CoA) 267 A unicast routeable address associated with a mobile node while 268 visiting a foreign link; the subnet prefix of this IP address is a 269 foreign subnet prefix. Among the multiple care-of addresses that 270 a mobile node may have at any given time (e.g., with different 271 subnet prefixes), the one registered with the mobile node's home 272 agent for a given home address is called its "primary" care-of 273 address. 275 Correspondent Node (CN) 276 A peer node with which a mobile node is communicating. The 277 correspondent node may be either mobile or stationary. 279 Endpoint 280 The term "endpoint" is used as the identity for a network host. 281 This is normally assumed to be a constant or long-lived 282 association. 284 Endpoint Identity Protocol Stack Element (EIP) 285 The Endpoint Identity Protocol Stack Element refers to an added 286 element in a protocol stack model that explicitly manages the 287 association of locators to endpoints. 289 Home Address (HoA) 290 A unicast routeable address assigned to a mobile node, used as the 291 permanent address of the mobile node. This address is within the 292 mobile node's home link. Standard IP routing mechanisms will 293 deliver packets destined for a mobile node's home address to its 294 home link. Mobile nodes can have multiple home addresses, for 295 instance when there are multiple home prefixes on the home link. 297 Lower Layer Protocol (LLP) 298 Lower Layer Protocol refers to the lower level protocol in the 299 protocol stack model relative to the protocol layer being 300 considered. In the Internet Protocol architecture, the LLP of the 301 Transport Protocol is the Internet Protocol, and the LLP of the 302 Application Protocol is the Transport Protocol. 304 Locator 305 The term "locator" is used as the location token for a network 306 host. This is a network level address that can be used as a 307 destination field for IP packets. 309 Mobile Node 310 A node that can change its point of attachment from one link to 311 another, while still being reachable via its home address. 313 Multi-Homed Site 314 A "multi-homed" site is one with more than one transit provider. 315 "Site multi-homing" is the practice of arranging a site to be 316 multi-homed such that the site may use any of the transit 317 providers for connectivity services. 319 Re-homing 320 The term "re-homing" denotes a transition of a site between two 321 states of connectedness due to a change in the connectivity 322 between the site and its transit providers. 324 Site 325 A "site" is an entity autonomously operating a network using IP. 327 Site-Exit Router 328 A "site-exit router" is a boundary router of the site that 329 provides the site's interface to one or more transit providers. 331 Transit Provider 332 A "transit provider" operates a site that directly provides 333 connectivity to the Internet to one or more external sites. The 334 connectivity provided extends beyond the transit provider's own 335 site. A transit provider's site is directly connected to the 336 sites for which it provides transit. 338 Upper Layer Protocol (ULP) 339 Upper Layer Protocol refers to the upper level protocol in the 340 protocol stack model relative to the protocol layer being 341 considered. In the Internet Protocol architecture the ULP of the 342 Internet Protocol is the Transport Protocol, and the ULP of the 343 Transport Protocol is the Application Protocol. 345 3. The Multi-Homing Space 347 A simple formulation of the site multi-homing environment is 348 indicated in Figure 1. 350 +------+ 351 |remote| 352 | host | 353 | R | 354 +------+ 355 | 356 + - - - - - - - - - - - + 357 | Internet Connectivity | 358 + - - - - - - - - - - - + 359 / \ 360 +---------+ +---------+ 361 | ISP A | | ISP B | 362 +---------+ +---------+ 363 | Path A | Path B 364 + - - - - - - - - - - - - - - - - - - - - + 365 | multi- | | | 366 homed +------+ +------+ 367 | site | site | | site | | 368 | exit | | exit | 369 | |router| |router| | 370 | A | | B | 371 | +------+ +------+ | 372 | | 373 | local site connectivity | 374 | 375 | +-----------+ | 376 |multi-homed| 377 | | host | | 378 +-----------+ 379 + - - - - - - - - - - - - - - - - - - - - + 381 The Multi-Homed Domain 383 Figure 1 385 The environment of multi-homing is one that is intended to provide 386 sufficient support to local hosts so as to allow local hosts to 387 exchange IP packets with remote hosts, such that this exchange of 388 packets is to be transparently supported across dynamic changes in 389 connectivity. Session resilience implies that if a local 390 multi-homed-aware host establishes an application session with the 391 remote host using "Path A", and this path fails, the application 392 session should be mapped across to "Path B" without requiring any 393 application-visible re-establishment of the session. In other words, 394 the application session should not be required to be explicitly aware 395 of underlying path changes at the level of packet forwarding paths 396 chosen by the network. Established sessions should survive dynamic 397 changes in network-level reachability. 399 There are also considerations of providing mechanisms to support 400 sustained site visibility to support session establishment. 401 Sustained site visibility implies that external attempts to initiate 402 a communication with hosts within the site will succeed as long as 403 there is at least one viable path between the external host and the 404 multi-homed site. This also implies that local attempts to initiate 405 a communication with remote hosts should take into account the 406 current connectivity state in undertaking locator selection and 407 setting up initial locator sets. 409 In addition there is the potential consideration of being able to 410 distribute the total traffic load across a number of network paths 411 according to some pre-determined policy objective. This may be to 412 achieve a form of traffic engineering, support for particular quality 413 of service requirements, or localized load balancing across multiple 414 viable links. 416 This simple multi-homing scenario also includes "site-exit" routers, 417 where the local site interfaces to the upstream Internet transit 418 providers. The nature of the interactions between the external 419 routing system and the site-exit routers, and interactions between 420 the site-exit routers and the local multi-homed host, and the 421 interactions between local connectivity forwarding and the local host 422 and site exit routers are not defined a priori in this scenario, as 423 they form part of the framework of interaction between the various 424 multi-homing components. 426 The major characteristic of this simple site multi-homing scenario is 427 that the address space used by, and advertised as reachable by, ISP A 428 is distinct from the address space used by ISP B. 430 This simple scenario is intended to illustrate the basic multi-homing 431 environment. Variations may include additional external providers of 432 transit connectivity to the local site, complex site requirements and 433 constraints, where the site may not interface uniformly to all 434 external transit providers, sequential rather than simultaneous 435 external transit reachability, communication with remote multi-homed 436 hosts, multi-way communications, use of host addresses in a 437 referential context (third party referrals) and the imposition of 438 policy constraints on path selection. However, the basic simple site 439 multi-homing scenario is sufficient to illustrate the major 440 architectural aspects of support for multi-homing, so this simple 441 scenario will be used as the reference model for this analysis. 443 4. Functional Goals and Considerations 445 RFC 3582 [RFC3582] documents some goals that a multi-homing approach 446 should attempt to address. These goals include: 447 * redundancy 448 * load sharing 449 * traffic engineering 450 * policy constraints 451 * simplicity of approach 452 * transport-layer survivability 453 * DNS compatibility 454 * packet filtering capability 455 * scaleability 456 * legacy compatibility 458 The reader is referred to [RFC3582] for a complete description of 459 each of these goals. 461 In addition, [thinks] documents further considerations for IPv6 462 multi-homing. Again, the reader is referred to this document for the 463 detailed enumeration of these considerations. The general topic 464 areas considered in this study include: 465 * interaction with routing systems, 466 * aspects of a split between endpoint-identifier and forwarding 467 locator, 468 * changes to packets on the wire, and 469 * the interaction between names, endpoints and the DNS. 471 In evaluating various approaches, further considerations also 472 include: 473 * the role of helpers and agents in the approach, 474 * modifications to host behaviours, 475 * the required trust model to support the interactions, and 476 * the nature of potential vulnerabilities in the approach. 478 5. Approaches to Multi-Homing 480 There appear to be five generic forms of architectural approaches to 481 this problem, namely: 483 Routing 484 Use the IPv4 multi-homing approach 486 Mobility 487 Use the IPv6 Mobility approach 489 New Protocol Element 490 Insertion of a new element in the protocol stack that manages a 491 persistent identity for the session 493 Modify a Protocol Element 494 Modify the Transport or IP protocol stack element in the host 495 in order to support dynamic forwarding locator change 497 Modified Site-Exit Router / Local Host interaction 498 Modify the site-exit router and local forwarding system to 499 allow various behaviours including source-based forwarding, 500 site-exit hand-offs, and address rewriting by site-exit routers 502 These approaches will be described in detail in the following 503 sections. 505 5.1 Multi-Homing: Routing 507 The approach used in IPv4 for multi-homing support is to preserve the 508 semantics of the IPv4 address as both an endpoint identifier and a 509 forwarding locator. For this to work in a multi-homing context it is 510 necessary for the transit ISPs to announce the local site's address 511 prefix as a distinct routing entry in the inter-domain routing 512 system. This approach could be used in an IPv6 context, and, as with 513 IPv4, no modifications to the IPv6 architecture are required to 514 support this approach. 516 The local site's address prefix may be a more specific address prefix 517 drawn from the address space advertised by one of the transit 518 providers, or from some third party provider not current directly 519 connected to the local site. Alternatively the address space may be 520 a distinct address block obtained by direct assignment from a 521 Regional Internet Registry as Provider Independent space. Each host 522 within the local site is uniquely addressed from the site's address 523 prefix. 525 All transit providers for the site accept a prefix advertisement from 526 the multi-homed site, and advertise this prefix globally in the 527 inter-domain routing table. When connectivity between the local site 528 and an individual transit provider is lost, normal operation of the 529 routing protocol will ensure that the routing advertisement 530 corresponding to this particular path will be withdrawn from the 531 routing system, and those remote domains who had selected this path 532 as the best available will select another candidate path as the best 533 path. Upon restoration of the path, the path is re-advertised in the 534 inter-domain routing system. Remote domains will undertake a further 535 selection of the best path based on this re-advertised reachability 536 information. Neither the local nor the remote host need to have 537 multiple addresses, nor undertake any form of address selection. The 538 path chosen for forward and reverse direction path flows is a 539 decision made by the routing system. 541 This approach generally meets all the goals for multi-homing 542 approaches with one notable exception: scaleability. Each site that 543 multi-homes in this fashion adds a further entry in the global 544 inter-domain routing table. Within the constraints of current 545 routing and forwarding technologies it is not clearly evident that 546 this approach can scale to encompass a population of multi-homed 547 sites of the order of, for example, 10**7 such sites. The 548 implication here is that this would add a similar number of unique 549 prefixes into the inter-domain routing environment, which in turn 550 would add to the storage and computational load imposed on 551 inter-domain routing elements within the network. This scale of 552 additional load is not supportable within the current capabilities of 553 the IPv4 global Internet, nor is it clear at present that the routing 554 capabilities of the entire network could be expanded to manage this 555 load in a cost-effective fashion, within the bounds of the current 556 inter-domain routing protocol architecture. 558 One other goal, that of transport-layer surviveability, is 559 potentially at risk in this approach. Dynamic changes within the 560 network trigger the routing system to converge to a new stable 561 distributed forwarding state. This process of convergence within the 562 distributed routing system may include the network generating 563 unstable transient forwarding paths, as well as taking an 564 indeterminate time to complete. This in term may trigger upper level 565 protocol timeouts and, possible session resets. 567 5.2 Multi-Homing: Mobility 569 Preserving established communications through movement is similar to 570 preserving established communications through outages in multi-homed 571 sites as both scenarios require the capability of dynamically 572 changing the locators used during the communication while 573 maintaining, unchanged, the endpoint identifier used by Upper Layer 574 Protocol (ULP). Since MIPv6 protocol [RFC3775] already provides the 575 required support to preserve established communications through 576 movement, it seems worthwhile to explore whether it could also be 577 used to provide session survivability in multi-homed environments. 579 MIPv6 uses a preferred IP address, the Home Address (HoA), as a 580 stable identifier for the mobile node (MN). This identifier is then 581 dynamically mapped to a valid locator (Care-of Address, or CoA) that 582 corresponds to the current attachment point within the network 583 topology. When the MN is at the Home Network, the HoA is used both 584 as locator and as identifier. When the MN is not at the Home 585 Network, the HoA is used as an identifier, and the CoA is used as 586 locator. A relaying agent (Home Agent) placed in the Home Network is 587 used to forward packets addressed to the HoA to the current location, 588 specified by the CoA. After each movement, the MN must inform its 589 Home Agent of the new CoA, and optionally inform those entities with 590 which it has established communications with (Correspondent Nodes, or 591 CNs). The mapping information between the HoA and the current CoA is 592 conveyed using Binding Update (BU) messages. When the BU message is 593 exchanged between the MN and the Home Agent, it is possible to assume 594 the existence of a pre-established Security Association that can be 595 used to protect the binding information. However, when the BU 596 message is exchanged between the MN and the CN, it is not possible to 597 assume the existence of such Security Association. In this case, it 598 is necessary to adopt an alternative mechanism to protect the binding 599 information contained in the message. The selected mechanism is 600 called Return Routeability procedure and the background for its 601 design is detailed in [rosec]. The goal of the mechanism is to allow 602 the CN to verify that the MN that is claiming that a HoA is currently 603 located at a CoA is entitled to make such claim, which essentially 604 means that the HoA was assigned to the MN, and that the MN is 605 currently located at the CoA. In order to verify these updates the 606 CN sends two different secrets, one to the claimed HoA and another 607 one to the claimed CoA. If the MN receives both secrets, this means 608 that the Home Agent located at the Home Network has a trust 609 relationship with the MN and it has forwarded the secret sent to the 610 HoA, and that the MN is receiving packets sent to the CoA. So, by 611 including authorisation information derived from both secrets within 612 the BU message, the MN will be able to prove to the CN that the 613 claimed binding between the HoA and the CoA is valid. 615 The lifetime of the binding that is created in the CN using 616 authorisation information obtained through the Return Routeability 617 procedure is limited to 7 minutes, in order to prevent time-shifted 618 attacks [rosec]. In a time-shifted attack, an attacker located along 619 the path between the CN and the MN forges the Return Routeability 620 packet exchange. The result of such attack is that the CN will 621 forward all the traffic addressed to the HoA to the CoA selected by 622 the attacker. The attacker can then leave the position along the 623 path but the effects of the attack will remain until the binding is 624 deleted, shifting in time the effect of the attack. By limiting the 625 lifetime of the binding in the CN, the effect of this attack is 626 reduced to 7 minutes, because after that period a new Return 627 Routeability procedure is needed to extend the binding lifetime. It 628 should be noted that the Return Routeability procedure is vulnerable 629 to "Man-In-The-Middle" attacks, since an attacker located along the 630 path between the CN and the MN can forge the periodic Return 631 Routeability packet exchange. 633 The possible application of the MIPv6 protocol to the multi-homing 634 problem would be to use BU messages to convey information in advance 635 about alternative addresses that could be used following an outage in 636 the path associated with the currently used address. 638 In this scenario, the multi-homed host adopts the MN role and the 639 host outside the multi-homed site adopts the CN role. When a 640 communication is established between the multi-homed host and the 641 external host, the address used for initiating the communication is 642 used as a HoA. The communication continues using this address as 643 long as no outage occurs. If an outage occurs and the HoA becomes 644 unreachable, an alternative address of the multi-homed node is used 645 as a CoA. In this case, the multi-homed node sends a BU message to 646 the external host, informing about the new CoA to be used for the 647 HoA, so that the established communication can be preserved using the 648 alternative address. However, such BU message has to be validated 649 using authorisation information obtained through the Return 650 Routeability procedure, which implies that the binding lifetime will 651 be limited to a fixed period of no more than 7 minutes. The result 652 is that the binding between the HoA and the new CoA will expire after 653 this interval has elapsed, and then the HoA will be used for the 654 communication. Since the HoA is unreachable because of the outage, 655 the communication will be interrupted. It should be noted that it is 656 not possible to acquire new authorisation information by performing a 657 new Return Routeability procedure, because it requires communication 658 through the HoA, which is no longer reachable. Consequently, a 659 mechanism based on the MIPv6 BU messages to convey information about 660 alternative addresses will preserve communications only for 7 661 minutes. 663 The aspect of MIPv6 which appears to present issues in the context of 664 multi-homing is the return routeability mechanism. In MIPv6 identity 665 validity is periodically tested by return routeability of the 666 identity address. This regular use of a distinguished locator as the 667 identity token cannot support return reachability in the multi-homing 668 context in the event of extended path failure of the path that is 669 associated with the identity locator. 671 5.3 Multi-homing: Identity Considerations 673 The intent of multi-homing in the IPv6 domain is to achieve an 674 outcome that is comparable to that of multi-homed IPv4 sites using 675 routing to support multi-homing, without an associated additional 676 load being imposed on the IPv6 routing system. The overall intent of 677 IPv6 is to provide a scalable protocol framework to support the 678 deployment of communications services for an extended period of time, 679 and this implies that the scaling properties of the deployment 680 environment remain tractable within projections of size of deployment 681 and underlying technology capabilities. Within the inter-domain 682 routing space, the basic approach used in IPv4 and IPv6 is to attempt 683 to align address deployment with network topology, so that address 684 aggregation can be used to create a structured hierarchy of the 685 routing space. 687 Within this constraint of topological-based address deployment and 688 provider aggregateable addressing architectures, the local site that 689 is connected to multiple providers is delegated addresses from each 690 of these providers' address blocks. In the example network in Figure 691 1, the local multi-homed host will conceivably be addressed in two 692 ways: one using transit provider A's address prefix and the other 693 using transit provider B's address prefix. 695 If remote host R is to initiate a communication with the local 696 multi-homed host, it would normally query the DNS for an address for 697 the local host. In this context the DNS would return 2 addresses 698 (One using the A prefix and the other using the B prefix). The 699 remote host would select one of these addresses and send a packet to 700 this destination address. This would direct the packet to the local 701 host along a path through A or B, depending on the selected address. 702 If the path between the local site and the transit provider fails, 703 then the address prefix announced by the transit provider to the 704 inter-domain routing system will continue to be the provider's 705 address prefix. The remote host will not see any change in routing, 706 yet packets sent to the local host will now fail to be delivered. 707 The question posed by the multi-homing problem is: "If the remote 708 host is aware of multi-homing, how could it switch over to using the 709 equivalent address for the local multi-homed host that transits the 710 other provider?" 712 If the local multi-homed host wishes to initiate a session with 713 remote host R, it needs to send a packet to R with a valid source and 714 destination address. While the destination address is that of R, 715 what source address should the local host use? There are two 716 implications for this choice. Firstly the remote host will, by 717 default use this source address as the destination address in its 718 response, and hence this choice of source address will direct the 719 reverse path from R to the local host. Secondly, the ISPs A and B 720 may be using some form of reverse unicast address filtering on source 721 addresses of packets passed to the ISP, as a means of prevention of 722 source address spoofing. This implies that if the multi-homed 723 address selects a source address from address prefix A, and the local 724 routing to R selects a best path via ISP B, then ISP B's ingress 725 filters will discard the packet. 727 Within this addressing structure there is no form of routing-based 728 repair of certain network failures. If the link between the local 729 site and ISP A fails, there is no change in the route advertisements 730 made by ISP A to its external routing peers. Even though the multi- 731 homed site continues to be reachable via ISP B, packets directed to 732 the site using ISP A's prefix will be discarded by ISP A as the 733 destination is unreachable. The implication here is that if the 734 local host wishes to maintain a session across such events it needs 735 to communicate to remote host R that it is possible to switch to 736 using a destination address for the multi-homed host that is based on 737 ISP B's address prefix. In the event that the local host wishes to 738 initiate a session at this point, then it may need to use an initial 739 source locator that reflects the situation that the only viable 740 destination address to use is the one that is based on ISP B's 741 address prefix. It may be the case that the local host is not always 742 aware of this return routeability constraint, or it may not be able 743 to communicate this information directly to R, in which case R needs 744 to discover or be passed this information in other ways. 746 In an aggregated routing environment multiple transit paths to a host 747 imply multiple address prefixes for the host, where each possible 748 transit path is identified by an address for the host. The 749 implication of this constraint on multi-homing is that paths being 750 passed to the local multi-homed site via transit provider ISP A must 751 use a forwarding-level destination IP address drawn from ISP A's 752 advertised address prefix set that maps to the multi-homed host. 753 Equally, packets being passed via the transit of ISP B must use a 754 destination address drawn from ISP B's address prefix set. The 755 further implication here is that path selection (ISP A vs. ISP B 756 transit for incoming packets) is an outcome of the process of 757 selecting an address for the destination host. 759 The architectural consideration here is that in the conventional IP 760 protocol architecture the assumption is made that the transport-layer 761 endpoint identity is the same identity used by the internet-layer 762 forwarding layer, namely the IP address. 764 If multiple forwarding paths are to be supported for a single 765 transport session, and path selection is to be decoupled from the 766 functions of transport session initiation and maintenance, then the 767 corollary of this requirement in architectural terms appears to be 768 that some changes are required in the protocol architecture to 769 decouple the concepts of identification of the endpoint and 770 identification of the location and associated path selection for the 771 endpoint. This is a fundamental change in the semantics of an IP 772 address in the context of the role of the endpoint address within the 773 end-to-end architectural model [e2e]. This change in the protocol 774 architecture would permit a transport session to use an invariant 775 endpoint identity value to initiate and maintain a session, while 776 allowing the forwarding layer to dynamically change paths and 777 associated endpoint locator identities without impacting on the 778 operation of the session, nor would such a decoupled concept of 779 identities and locators add any incremental load to the inter-domain 780 routing system. 782 Some generic approaches to this form of separation of endpoint 783 identity and locator value are described in the following sections. 785 5.4 Multi-homing: Identity Protocol Element 787 One approach to this objective is to add a new element into the model 788 of the protocol stack. 790 The presentation to the upper level protocol stack element (ULP) 791 would use endpoint identifiers to uniquely identify both the local 792 stack and the remote stack. This will provide the ULP with stable 793 identifiers for the duration of the ULP session. 795 The presentation to the lower level protocol stack element (LLP) 796 would be of the form of a locator. This implies that the protocol 797 stack element would need to maintain a mapping of endpoint identifier 798 values to locator values. In a multi-homing context one of the 799 essential characteristics of this mapping is that it needs to be 800 dynamic, in that environmental triggers should be able to trigger a 801 change in mappings, which in turn would correspond to a change in the 802 paths (forward and/or reverse) used by the endpoints to traverse the 803 network. In this way the ULP session is defined by a peering of 804 endpoint identifiers that remain constant throughout the lifetime of 805 the ULP session, while the locators may change to maintain end-to-end 806 reachability for the session. 808 The operation of the new protocol stack element (termed here the 809 "endpoint identity protocol stack element", or "EIP") is to establish 810 a synchronised state with its remote counterpart. This would allow 811 the stack elements to exchange a set of locators that may be used 812 within the context of the session. A change in the local binding 813 between the current endpoint identity value and a locator will cause 814 a change in the source locator value used in the forwarding level 815 packet header. The actions of the remote EIP upon receipt of this 816 packet with the new locator is to firstly recognise this locator as 817 part of an existing session, and, upon some trigger condition, to 818 change its session view of the mapping of the remote endpoint 819 identity to the corresponding locator, and use this locator as the 820 destination locator in subsequent packets passed to the LLP. 822 From the perspective of the IP protocol architecture there are two 823 possible locations to insert the EIP into the protocol stack. 825 One possible location is at the upper level of the transport 826 protocol. Here the application program interface (API) of the 827 application level protocols would interface to the EIP element, and 828 use endpoint identifiers to refer to the remote entity. The EIP 829 would pass locators to the API of the transport layer. 831 The second approach is to insert the EIP between the transport and 832 internet protocol stack elements, so that the transport layer would 833 function using endpoint identifiers, and maintain a transport session 834 using these endpoint identifiers. The IP or internetwork layer would 835 function using locators, and the mapping from endpoint identifier to 836 locator is undertaken within the EIP stack element. 838 5.5 Multi-homing: Modified Protocol Element 840 As an alternative to insertion of a new protocol stack element into 841 the protocol architecture, an alternative approach is to modify an 842 existing protocol stack element to include the functionality 843 performed by the EIP element. This modification could be undertaken 844 within the transport protocol stack element, or within the 845 internetworking stack element. The functional outcome from these 846 modifications would be to create a mechanism to support the use of 847 multiple locators within the context of a single endpoint to single 848 endpoint communication. 850 Within the transport layer, this functionality can be achieved, for 851 example, by the binding of a set of locators to a single session, and 852 then communicating this locator set to the remote transport entity. 853 This would allow the local transport entity to switch the mapping to 854 a different locator for either the local endpoint or the remote 855 endpoint while maintaining the integrity of the ULP session. 857 Within the IP level this functionality could be supported by a form 858 of dynamic rewriting of the packet header as it is processed by the 859 protocol element. Incoming packets with the source and destination 860 locators in the packet header are mapped to packets with the 861 equivalent endpoint identifiers in both fields, and the reverse 862 mapping is performed to outgoing packets passed from the transport 863 layer. Mechanisms that support direct rewriting of the packet header 864 are potential candidates in this approach, as are various forms of 865 packet header transformations of encapsulation, where the original 866 endpoint identifier packet header is preserved in the packet and an 867 outer-level locator packet header is wrapped around the packet as it 868 is passed through the internetworking protocol stack element. 870 In all these scenarios, there are common issues of what state is 871 kept, by which part of the protocol stack, how state is maintained 872 with additions, removals of locator bindings, and does only one piece 873 of code have to be aware of the endpoint / locator split or do 874 multiple protocol elements have to be modified? For example, if the 875 functionality is added at the internetworking (IP) layer, there is no 876 context of an active transport session, so that removal of identity / 877 locator state information for terminated sessions needs to be 878 triggered by some additional mechanism from the transport layer to 879 the internetworking layer. 881 5.6 Modified Site-Exit and Host Behaviors 883 The above approaches all assume that the hosts are explicitly aware 884 of the multi-homed environment and use modified protocol behaviour to 885 support multi-homing functionality. A further approach to this 886 objective is to split this functionality across a number of network 887 elements and potentially perform packet header rewriting from a 888 persistent endpoint identity value to a locator value at a remote 889 point. 891 One possible approach proposes the use of site-exit routers to 892 perform some form of packet header manipulation as packets are passed 893 out from the local multi-homed site to a particular transit provider. 894 The local site routing system will select the best path to a 895 destination host based on the remote hosts's locator value. The 896 local host will write its endpoint identity as the source address of 897 the packet. When the packet reaches a site-exit router, the 898 site-exit router will rewrite the source field of the packet to a 899 corresponding locator that selects a reverse path through the same 900 transit ISP when the locator is used as a destination locator by the 901 remote host. In order to preserve session integrity there is a need 902 for a corresponding reverse transformation to be undertaken on 903 incoming packets, where the destination locator has to be mapped back 904 to the host's endpoint identifier. There are a number of 905 considerations whether this is best performed at the site exit router 906 when the packet is passed into the site, or by the local host. 908 Packet header rewriting by remote network elements has a large number 909 of associated security considerations, and any packet rewriting 910 mechanism has to provide proper protection against the attacks 911 described in [threats], in particular against redirection attacks. 913 An alternative for packet header rewriting at the site-exit point is 914 for the host to undertake the endpoint-to-locator mapping, using one 915 of the approaches outlined above. The consideration here is that 916 there is some significant deployment of unicast reverse path 917 filtering in Internet environments as a counter-measure to source 918 address spoofing. Using the example in Figure 1, if a host selects a 919 locator drawn from the ISP B address prefix, and local routing 920 directs that packet to site-exit router A, then if the packet is 921 passed to ISP A, this would be discarded by such filters. Various 922 approaches have been proposed to modify the behaviour of the site 923 forwarding environment all with the end effect that packets using a 924 source locator drawn from the ISP B address prefix are passed to 925 site-exit router B. These approaches include forms of source address 926 routing and site-exit router hand-over mechanisms, as well as 927 augmentation of the routing information between site-exit routers and 928 local multi-homed hosts, so that the choice of locator by the local 929 host for the remote host is consistent with the current local routing 930 state for the local site to reach the remote host. 932 6. Approaches to Endpoint Identity 934 Both the approach of the addition of an identity protocol element and 935 the approach of modification of an existing protocol element assume 936 some form of exchange of information that allows both parties to the 937 communication to be aware of the other party's endpoint identity and 938 the associated mapping to locators. There are a number of choices in 939 terms of the way in which this information exchange can be 940 implemented. 942 The first such possible approach is termed here a 'conventional' 943 approach, where the mode of operation is in terms of encapsulating 944 the protocol data unit (PDU) passed from the ULP with additional data 945 elements that specifically refer to the function of the endpoint 946 identity protocol stack element. The compound data element is passed 947 to the LLP as its PDU. The corresponding actions on receipt of a PDU 948 from a LLP is to extract the fields of the data unit that correspond 949 to the EIP function, and pass the remainder of the PDU to the ULP. 950 The EIP operates in an "in-band" mode, communicating with its remote 951 peer entity through additional information wrapped around the ULP 952 PDU. This is equivalent to generic tunnelling approaches where the 953 outer encapsulation of the transmitted packet contains location 954 address information, while the next level packet header contains 955 information that is to be exposed and used at the location endpoints, 956 being, in this case, identity information. 958 Another approach is to allow the EIP to communicate using a separate 959 communications channel, where the EIP generates dedicated messages 960 that are directed to its peer EIP, and passes these PDUs to the LLP 961 independently of the PDUs that are passed to the EIP from the ULP. 962 This allows the EIP to exchange information and synchronise state 963 with the remote EIP semi-independently of the ULP protocol exchange. 964 As one part of the EIP function is to transform the ULP PDU to 965 include locator information, there is an associated requirement to 966 ensure that the EIP peering state remains synchronised to the 967 exchange of ULP PDUs so that the remote EIP can correctly recognise 968 the locator to endpoint mapping for each active session. 970 Another potential approach here is to allow the endpoint to locator 971 mappings to be held at a third party point. This model is already 972 used for supporting the name to IP address mappings performed by the 973 Domain Name system, where the mapping is obtained by reference to a 974 third party, namely a DNS resolver. A similar form of third party 975 mapping between endpoints and a locator set could be supported 976 through the use of the DNS, or a similar third party referential 977 mechanism. Rather than have each party exchange endpoint to locator 978 mappings, this approach would see this mapping being obtained as a 979 result of a lookup for a DNS Endpoint to Locator set map contained as 980 DNS Resource Records, for example. 982 6.1 Endpoint Identity Structure 984 The previous section has used the term "endpoint identity" without 985 examining what form this identity may take. There are a number of 986 salient considerations regarding the structure and form of this 987 identity that should be enumerated within an architectural overview 988 of this space. 990 One possible form of an identity is the use of identity tokens lifted 991 from the underlying protocol's "address space". In other words an 992 endpoint identity is a special case instance of an IPv6 protocol 993 address. There are a number of advantages in using this form of 994 endpoint identity, observing that the suite of IP protocols and 995 associated applications already manipulate IP addresses. The 996 essential difference in a domain that distinguishes between endpoint 997 identity and locator is that the endpoint identity parts of the 998 protocol would operate on those addresses that assume the role of 999 endpoint identities, and the endpoint identity / locator mapping 1000 function would undertake a mapping from an endpoint "address" to a 1001 set of potential locator "addresses", and also undertake a reverse 1002 mapping from a locator "address" to the distinguished endpoint 1003 identifier "address". The address space is hierarchically 1004 structured, permitting a suitably efficient mapping to be performed 1005 in both directions, and the underlying semantics of addresses in the 1006 context of public networking includes the necessary considerations of 1007 global uniqueness of endpoint identity token values. 1009 It is possible to take this approach further and allow the endpoint 1010 identifier to also be a valid locator. This would imply the 1011 existence of a 'distinguished' or 'home' locator, and other locators 1012 could be dynamically mapped to this initial locator peering as 1013 required. The drawback of this approach is that the endpoint 1014 identifier is now based on one of the transit provider's address 1015 prefixes, and a change of transit provider would necessarily require 1016 a change of endpoint identifier values within the multi-homed site. 1018 An alternative approach for address-formatted identifiers is to use 1019 distinguished identity address values which are not part of the 1020 global unicast locator space, allowing applications and protocol 1021 elements to distinguish between endpoint identity values and locators 1022 based on address prefix value. 1024 It is also possible to allow the endpoint identity and locator space 1025 to overlap, and distinguish between the two identity realms by the 1026 context of usage rather than by a prefix comparison. However, this 1027 reuse of the locator token space as identity tokens has the potential 1028 to create the anomalous situation where a particular locator value is 1029 used as an identity value by a different endpoint. It is not clear 1030 that the identity and locator contexts can be clearly disambiguated 1031 in every case, which is a major drawback to this particular approach. 1033 If identity values are to be drawn from the protocol's address space 1034 it would appear that the basic choice is to either draw these 1035 identity values from a different part of the address space, or use a 1036 distinguished or home address as both a locator and an identity. 1037 This latter option, that of using a locator as the basis of an 1038 endpoint identity on a locator, when coupled with a 1039 provider-aggregated address distribution architecture leads to the 1040 outcome of a multi-homed site using a provider-based address prefix 1041 as a common identity prefix. As with locator addresses in the 1042 context of a single-homed network, a change of provider connectivity 1043 implies a consequent renumbering of identity across the multi-homed 1044 site. If avoiding such forced renumbering is a goal here, there 1045 would be a preference in drawing identity tokens from a pool that is 1046 not aligned with network topology. This may point to a preference 1047 from this sector to use of identity token values that are not drawn 1048 from the locator address space. 1050 It is also feasible to use the fully qualified domain name (FQDN) as 1051 an endpoint identity, undertaking a similar mapping as described 1052 above, using the FQDN as the lookup "key". The implication here is 1053 that there is no default 'address' that is to be associated with the 1054 endpoint identifier, as the FQDN can be used in the context of 1055 session establishment, and a DNS query used to establish a set of 1056 initial locators. Of course it is also the case that there may not 1057 necessarily be a unique endpoint associated with a FQDN, and in such 1058 cases if there were multiple locator addresses associated with the 1059 FQDN via DNS RRs, shifting between locators may imply directing the 1060 packet to a different endpoint where there is no knowledge of the 1061 active session on the original endpoint. 1063 The syntactic properties of these two different identity realms have 1064 obvious considerations in terms of the manner in which these 1065 identities may be used within PDUs. 1067 It is also an option to consider a new structured identity space 1068 which is not generated through the reuse of IPv6 address values nor 1069 drawn from the FQDN. Given that the address space would need to be 1070 structured in such a fashion that permits it to be used as a lookup 1071 key to obtain the corresponding locator set, the obvious question in 1072 such an option is what additional or altered characteristics would be 1073 used in such an endpoint identity space that would distinguish it 1074 from either of the above approaches? 1076 Instead of structured tokens that double as lookup keys to obtain 1077 mappings from endpoint identities to locator sets, the alternative is 1078 to use an unstructured token space, where individual token values are 1079 drawn opportunistically for use within a multi-homed session context. 1080 If such unstructured tokens are used in a limited context then the 1081 semantics of the endpoint identity are subtly changed. The endpoint 1082 identity is not a persistent alias or reference to the identity of 1083 the endpoint, but a means to allow the identity protocol element to 1084 confirm that two locators are part of the same mapped locator set for 1085 a remote endpoint. In this context the unstructured opportunistic 1086 endpoint identifier values are used in determining locator 1087 equivalence rather than in some form of lookup function. 1089 6.2 Persistent, Opportunistic and Ephemeral Identities 1091 The consideration in the previous section highlights one of the major 1092 aspects of variance in the method of supporting a split between 1093 identity and location information. 1095 One form uses a persistent identity field, by which it is inferred 1096 that the same identity value is used in all contexts where this form 1097 of identity is required, in support of concurrent sessions, and in 1098 support of sequential sessions. This form of identity is intended to 1099 remain constant over time and over changes in the underlying 1100 connectivity. It may also be the case that this identity is 1101 completely distinct from network topology, so that the same identity 1102 is used irrespective of the current connectivity and locator 1103 addressing used by the site and the host. In this case the identity 1104 is persistent, and the identity value can be used as a reference to 1105 the endpoint stack. This supports multi-party referrals, where if 1106 parties A and B establish a communication, B can pass A's identity to 1107 a third party C, who can then use this identity value to be the 1108 active party in establishing communication to A. 1110 If persistent identifiers are to be used to initiate a session, then 1111 it follows that the identity is used as a lookup key to establish a 1112 set of locators that are associated with the identified endpoint. It 1113 is desirable that this lookup function be deterministic, reliable, 1114 robust, efficient and trustable. The implication of this is that 1115 such identities must be uniquely assigned, and experience in identity 1116 systems points to a strong preference for a structured identity token 1117 space that has an internal hierarchy of token components. These 1118 identity properties have significant commonality with those of 1119 unicast addresses and domain names. The further implication here is 1120 that persistent structured identities also rely on the adoption of 1121 well-ordered distribution and management mechanisms to preserve their 1122 integrity and utility. Such mechanisms generally imply a significant 1123 overhead in terms of administrative tasks. 1125 As noted in the previous section, an alternative form of identity is 1126 an unstructured identity space, where specific values are drawn from 1127 the space opportunistically. In this case the uniqueness of any 1128 particular identity value is not assured in all cases. The use of 1129 such identities as a lookup key to establish locators is also 1130 altered, as the unstructured nature of the space has implications 1131 relating to the efficiency of the lookup, and the authenticity of the 1132 lookup is weakened due to the inability to assure uniqueness of the 1133 identity key value. A conservative approach to unstructured 1134 identities limits their scope of utility, such as per-session 1135 identity keys. In this scenario the scope of the selected identity 1136 is limited to the parties who are communicating, and limited to the 1137 duration of the communication session. The implication of this 1138 limitation is that the identity is a session-level binding point to 1139 allow multiple locators to be bound to the session, and the identity 1140 cannot be used as a reference to an endpoint beyond the context of 1141 the session. Such opportunistic identities with explicitly limited 1142 scope do not require the adoption of any well-ordered mechanisms of 1143 token distribution and management. 1145 Another form of identity is an ephemeral form, where a session 1146 identity is a shared state between the endpoints, established without 1147 the exchange of particular token values that take the role of 1148 identity keys. This could take the form of a defined locator set, or 1149 the form of a session key derived from some set of shared attributes 1150 of the session, as two examples here. In this situation there is no 1151 form of reference or use of an identifier as a means of initiating a 1152 session. The ephemeral identity value has a very limited role in 1153 terms of allowing each end to reliably determine the semantic 1154 equivalence of a set of locators within the context of membership of 1155 a particular session. 1157 The latter two forms of identity represent an approach to identity 1158 that minimises management overhead, and provides mechanisms that are 1159 limited in scope to supporting session integrity. This implies that 1160 support for identity functions in other contexts and at other levels 1161 of the protocol stack, such as within referrals, in the use of 1162 identities within an application's data payload, or as a key used to 1163 initiate a communication session with a remote endpoint would need to 1164 be supported by some other identity function. Such per-session 1165 limited scope identities imply that the associated multi-homing 1166 approaches must use existing mechanisms for session startup, and the 1167 adoption of a session-based identity and associated locator switch 1168 agility becomes a negotiated session capability. On the other hand, 1169 the use of a persistent identity as a session initiation key implies 1170 that identity is part of the established session state, and locator 1171 agility can be an associated attribute of the session, rather than a 1172 subsequent negotiated capability. In a heterogeneous environment 1173 where such identity capability is not uniformly deployed this would 1174 imply that if a session cannot be established with a split identity 1175 locator binding, the application should be able to back off to a 1176 conventional session startup by mapping the identity to a specific 1177 locator value and initiating a session using such a value. The 1178 reason why the application may want to be aware of this distinction 1179 is that if the application wishes to use self-referential mechanisms 1180 within the application payload, it would appear to be appropriate to 1181 use an identity-based self-reference only in the context of a session 1182 where the remote party was aware of the semantic properties of this 1183 referential tag. 1185 In terms of functionality and semantics opportunistic identities form 1186 a superset of ephemeral identities, although their implementation is 1187 significantly different. Persistent identities support a superset of 1188 the functionality of opportunistic identities, and again the 1189 implementations will differ. 1191 In the context of support for multi-homing configurations, use of 1192 ephemeral identities that are used in the context of locator 1193 equivalence appears to represent a viable approach which allows a 1194 negotiated use of multiple locators within the context of 1195 communication between a pair of hosts in most contexts of 1196 multi-homing. However ephemeral identities offer little more in 1197 terms of functionality. They cannot be used in referential contexts, 1198 cannot be used to initiate communications, and provide limited means 1199 of support for various forms of mobility, and impose some constraints 1200 on the class of multi-homed scenarios that can be supported. 1201 Ephemeral identities are generated in the context of an established 1202 communication state, and the implication in terms of multi-homing is 1203 that the two end points need to have discovered through existing 1204 mechanisms a viable pair of locators prior to generating an ephemeral 1205 identity binding. The implication is that there is some form of 1206 static 'home' for the end points which is discovered by conventional 1207 referential lookup. 1209 The use of a persistent identity space that supports dynamic 1210 translation between an equivalent set of locators and one or more 1211 equivalent identity values offers the potential for greater 1212 flexibility in application, extending beyond the multi-homing 1213 configuration to various contexts of nomadism and mobility, as well 1214 as extending into service-specific functions, depending on how the 1215 mapping between identities and locators is managed. However it 1216 remains an open question as to the nature of secure mapping 1217 mechanisms that would need to be used in the more general context of 1218 identity to locator mapping, and it is also an open question how the 1219 mapping function would relate to viable endpoint-to-endpoint 1220 connectivity. It is a common aspect of identity realms that the most 1221 critical aspect of the realm is the nature of the resolution of the 1222 identity into some other attribute space. 1224 It appears reasonable to observe that, within certain constraints, 1225 multi-homing does not generically require the overhead of the 1226 introduction of a fully distinct persistent identity space and the 1227 associated identity resolution functionality, and if the nature of 1228 the multi-homing space in this context is one of the use of a token 1229 to allow efficient detection of locator equivalence for session 1230 surviveability, then ephemeral identities appear to be an adequate 1231 mechanism for this role. 1233 6.3 Common Issues for Multi-Homing Approaches 1235 The above overview encompasses a very wide range of potential 1236 approaches to multi-homing, and each particular approach necessarily 1237 has an associated set of considerations regarding its applicability. 1239 There are, however, a set of considerations that appear to be common 1240 across all approaches, and they are examined in further detail in 1241 this section. 1243 6.3.1 Triggering Locator Switches 1245 Ultimately, regardless of the method of generation, a packet 1246 generated from a local multi-homed host to a remote host must have a 1247 source locator in the IP packet that is passed into the transit 1248 network. In a multi-homed situation the local multi-homed host has a 1249 number of self-referential locators that are equivalent aliases in 1250 almost every respect. The difference between locators is the 1251 inference that at the remote end the choice of locator may determine 1252 the path used to send a packet back to the local multi-homed host. 1253 The issue here is how does the local host make a selection of the 1254 "best" source locator to use? Obviously the parameters of this 1255 selection include the objective to select a locator that represents a 1256 currently viable path from the remote host to the local multi-homed 1257 host. Local routing information for the multi-homed host does not 1258 include this reverse path information. Equally, the local host does 1259 not necessarily know of any additional policy constraints that apply 1260 to the remote host that may result in a remote host's preference to 1261 use one locator over another for the local host. Considerations of 1262 unicast reverse path forwarding filters also indicate that the 1263 selection of a source locator should result in the packet being 1264 passed to a site-exit router that is connected to the associated ISP 1265 transit provider, and that the site-exit router passes the packet to 1266 the associated ISP. 1268 If the local multi-homed host is communicating with a remote 1269 multi-homed host, the local host may have some discretion in the 1270 choice of a destination locator. The considerations relating to the 1271 selection of a destination locator include considerations of local 1272 routing state (to ensure that the chosen destination locator reflects 1273 a viable path to the remote endpoint), policy constraints that may 1274 determine a "best" path to the remote endpoint. In such situations 1275 it may also be the case that the source address selection should also 1276 be considered in relation to the destination locator selection. 1278 Another common issue is the consideration of the point when a locator 1279 is not considered to be viable, and the consequences to the transport 1280 session state. 1281 o Transport Layer Triggers 1283 A change in state for a currently used path to another path could 1284 be triggered by indications of packet loss along the current path 1285 transport-level signalling, or by transport session timeouts, 1286 assuming an internal signalling mechanism between the transport 1287 stack element and the locator pool management stack element. 1289 o ICMP Triggers 1291 Path failure within the network may generate an ICMP Destination 1292 Unreachable ICMP packet being directed back to the sender. Rather 1293 than sending this signal to the transport level as an indicator of 1294 session failure, the IP layer should redirect the notification 1295 identity module as a trigger for a locator switch. 1297 o Routing Triggers 1299 Alternatively, in the absence of local transport triggers, the 1300 site exit router could communicate failure of the outbound 1301 forwarding path in the case where the remote host is multi-homed 1302 with an associated locator set. Conventional routing would be 1303 incapable of detecting a failure in the inbound forwarding path, 1304 so there are some limitations in the approach of using routing 1305 triggers to change locator bindings. 1307 o Heartbeat Triggers 1309 An alternative to these approaches is the use of a session 1310 heartbeat protocol, where failure of the heartbeat would cause the 1311 session to seek a new locator binding that would re-establish the 1312 heartbeat. 1314 o Link Triggers 1316 Where supported, link layer triggers could be used as a direct and 1317 immediate signal of link availability, where a 'Link Down' 1318 indication indicates the unavailability of a particular link 1319 [draft-iab-link]. The limitation of this approach is that a link 1320 level indication is not a network broadcast event, and only the 1321 link's immediately connected devices receive the link transition 1322 signal. While this approach may be relevant to the degenerate 1323 case of a multi-homed site composed of a single host, in the case 1324 of a multi-host site the link indication would need to be used by 1325 the site-exit router to generate one of the above indications for 1326 the host to be triggered for a locator change. In this case this 1327 is a conventional form of router detection of link status. 1329 The sensitivity of the locator-switch trigger is a consideration 1330 here. A very fine-grained sensitivity of the locator switch trigger 1331 may generate false triggers arising from short-term transient path 1332 congestion, while coarse-grained triggers may impose an undue 1333 performance penalty on the session due to an extended time to detect 1334 a path failure. The objectives for sensitivity to triggers may be 1335 very different depending on the transport session being used. 1336 There's no doubt that any session would need a trigger to rehome if 1337 its path to the locator fails, but for some transports, moving, and 1338 triggering transport-related changes, may be far less desireable than 1339 reducing the sensitivity of the trigger and waiting to see if the 1340 triggering stimulus achieves a threshold level. 1342 This problem is only partly solved by models with an internal 1343 signaling mechanism between the transport stack element and the 1344 locator pool management stack element because of non-failure triggers 1345 coming from other stacks, and because of transport issues such as use 1346 of resource reservation. As an example here, consider the case of a 1347 session with reservations established by RSVP or NSIS, when a routing 1348 change has just caused adaptive updates to the reservation state in a 1349 number of elements along its path. The transport using the path is 1350 likely to see some delays or timeouts, and its reaction to these 1351 events may be a trigger for a locator change, which is likely to mean 1352 another reservation update. This chaining of reservation updates may 1353 represent a high overhead. The implication here is that individual 1354 transports may have to tune any feedback they give as a locator 1355 change trigger, so that they don't respond to certain forms of 1356 transient routing change delays (not knowing their cause) with a 1357 locator change trigger. It should also be noted that different 1358 transports have rather different behaviors and hooks for management. 1360 6.3.2 Locator Selection 1362 The selection of a locator to use for the remote end is obviously 1363 constrained by the current state of the topology of the network, and 1364 the primary objective of the selection process is to select a viable 1365 locator that allows the packet to reach the intended destination 1366 point. The selection of a source locator can be considered as an 1367 indication of preference to the remote end of a preferred locator to 1368 use for the local end. However, where there are two or more viable 1369 locators that could be used, the selection of a particular locator 1370 may be influenced by a set of additional considerations. 1372 The selection of a particular locator from a viable locator set 1373 implies a selection of one particular network path in preference to 1374 other viable paths. An implication of this host-based locator 1375 selection process is that path selection and, by inference, traffic 1376 engineering functions, are not constrained to a network-based 1377 operation of path manipulation through adjustment of forwarding state 1378 within network elements. There is a consequent interaction between 1379 the locator selection process and traffic engineering functions. The 1380 use of an address selection policy table, as described in RFC 3484 1381 [RFC3484] are relevant to the selection process. 1383 The element that performs the locator selection, either as a protocol 1384 element within the host or a selection undertaken at a site-exit 1385 router, also determines traffic policy, so the choice of using remote 1386 packet locator rewriting or host based locator selection shifts the 1387 policy capability from one element to the other. 1389 If hosts perform this policy determination, then a more fine grained 1390 outcome may be achievable, particularly if the anticipated traffic 1391 characteristics of the application can be signalled to the locator 1392 selection process. A further consideration here appears to be that 1393 hosts may require additional information if they are to make locator 1394 address selection decisions based on some form of metric of relative 1395 load currently being imposed on select components of a number of 1396 end-to-end network paths. These considerations raise the broader 1397 issue of traffic engineering being a network function entirely 1398 independent of host function or an outcome of host interaction with 1399 the network. In the latter case there is also the consideration of 1400 whether the host is to interact with the network, and, if so, how 1401 this interaction is to be signalled to hosts. 1403 6.3.3 Layering Identity 1405 The consideration of triggering locator switch highlights the 1406 observation that differing information and context is present in each 1407 layer of the protocol stack. This impacts on how identity / locator 1408 bindings are established, maintained and expired. 1410 These impacts include questions of what amount of state is kept, by 1411 which element of the protocol stack, at what level of context 1412 (dynamic or fixed, and per session or per host). It also includes 1413 considerations of state maintenance, such as how stale or superfluous 1414 state information is detected and removed. Does only one piece of 1415 code have to be aware of this identity/locator binding or do multiple 1416 transport protocols have to be altered to support this functionality? 1417 If so, are such changes common across all transport protocols, or do 1418 different protocols require different considerations in their 1419 treatment of this functionality? 1421 It is noted that the set of approaches considered here include 1422 proposals to place this functionality within the IP layer, with the 1423 end-to-end transport protocol layer and as a shim between the IP and 1424 transport protocol layer. 1426 Placing this identity functionality at the transport protocol layer 1427 implies that the identity function can be tightly associated with a 1428 transport session. In this approach session startup can trigger the 1429 identity / locator initial binding actions and transport protocol 1430 timeouts can be used as triggers for locator switch actions. Session 1431 termination can trigger expiration of local identity / locator 1432 binding state. Where per-session opportunistic identity token values 1433 are being used, the identity information can be held within the 1434 overall session state. In the case of persistent identity token 1435 values the implementation of the identity can also choose to use 1436 per-session state, or may choose to pool this information across 1437 multiple sessions in order to reduce overheads of dynamic discovery 1438 of identity / locator bindings for remote identities in the case of 1439 multiple sessions to the same remote endpoint. 1441 One of the potential drawbacks of placing this functionality within 1442 the transport protocol layer is that it is possible that each 1443 transport protocol will require a distinct implementation of identity 1444 functionality. This is a considerable constraint in the case of UDP, 1445 where the UDP transport protocol has no inherent notion of a session 1446 state. 1448 An alternative approach is to use a distinct protocol element placed 1449 between the transport and internet layers of the protocol stack. The 1450 advantage of this approach is that it would offer a consistent form 1451 of mapping between identities and locators for all forms of transport 1452 protocols. However this protocol element would not be explicitly 1453 aware of sessions and would either have to discover the appropriate 1454 identity / locator mapping for all identity-addressed packets passed 1455 from the transport protocol later, irrespective of whether such a 1456 mapping exists and whether this is part of a session context, or have 1457 an additional mechanism of signalling to determine when such a 1458 mapping is to be discovered and applied. At this level there is also 1459 no explicit knowledge of when identity / locator mapping state is no 1460 longer required, as there is no explicit signalling of when all flows 1461 to and from a particular destination have stopped and resources 1462 consumed in supporting state can be released. Also, such a protocol 1463 element would not be aware of transport level timeouts, so that 1464 additional functionality would need to be added to the transport 1465 protocol to trigger a locator switch at the identity protocol level. 1466 Support of per-session opportunistic identity structure is more 1467 challenging in this environment, as the transport protocol layer is 1468 used to store and manipulate per-session state. In constructing an 1469 identity element at this level of the protocol stack it would appear 1470 necessary to ensure that an adequate amount of information is being 1471 passed between the transport, internet protocol and identity protocol 1472 elements in order to ensure that the identity protocol element is not 1473 forced into making possibly inaccurate assumptions about the current 1474 state of active sessions or end-to-end network paths. 1476 It is also possible to embed this identity function within the 1477 internet protocol layer of the protocol stack. As noted in the 1478 previous section, per session information is not readily available to 1479 the identity module, so that opportunistic per-session identity 1480 values would be challenging to support in this approach, as well as 1481 determining when identity / locator state information should be set 1482 up and released. It would also appear necessary to signal transport 1483 level timeouts to the identity module as a locator switch trigger. 1484 Some attention needs to be given in this case to synchronising 1485 locator switches and IP packet fragmentation, and consideration of 1486 IPSec is necessary in this case, in order to avoid making changes to 1487 the address field in the IP packet header that trigger a condition at 1488 the remote end where the packet is not recognisable in the correct 1489 context. 1491 6.3.4 Session Startup and Maintenance 1493 The next issue is that of the difference between the initial session 1494 startup mode of operation and the maintenance of the session state. 1496 In a split endpoint identifier / locator environment there needs to 1497 be at least one initial locator associated with an endpoint 1498 identifier in order to establish an initial connection between the 1499 two hosts. This locator could be loaded into the DNS in a 1500 conventional fashion, or, if the endpoint identifier is a 1501 distinguished address value, the initial communication could be 1502 established using the endpoint identifier in the role of a locator 1503 (i.e. using this as a conventional address). 1505 The initial actions in establishing a session would be similar. If 1506 the session is based on specification of a FQDN, the FQDN is first 1507 mapped to an endpoint identity value, and this endpoint identity 1508 value could then be mapped to a locator set. The locators in this 1509 set are then candidate locators for use in establishing an initial 1510 synchronised state between the two hosts. Once the state is 1511 established it is then possible to update the initial locator set 1512 with the current set of useable locators. This update could be part 1513 of the initial synchronisation actions, or deferred until required. 1515 This leads to the concept of the use of a 'distinguished' locator 1516 that acts as the endpoint identifier, and a pool of alternative 1517 locators that are associated with this 'home' locator. This 1518 association may be statically defined, using referential pointers in 1519 a third party referral structure (such as the DNS), or dynamically 1520 added to the session through the actions of the endpoint identity 1521 protocol stack element, or both. 1523 If opportunistic identities are used where the identity is not a 1524 fixed discoverable value but one that is generated in the context of 1525 a session then additional actions must be performed at session 1526 startup. In this case there is still the need for defined locators 1527 that are used to establish a session, but then an additional step is 1528 required to generate session keys and exchange these values in order 1529 to support the identity equivalence of multiple locators within the 1530 ensuing session. This may take the form of a capability exchange and 1531 an additional handshake and associated token value exchange within 1532 the transport protocol if an in-band approach is being used, or it 1533 may take the form of a distinct protocol exchange at the level of the 1534 identity protocol element, performed out-of-band from the transport 1535 session. 1537 Some approaches are capable of a further distinction, namely that of 1538 initial session establishment and that of establishment of additional 1539 shared state within the session to allow multiple locators to be 1540 treated as being bound to a common endpoint identity. It is not 1541 strictly necessary that such additional actions be performed at 1542 session startup, but it appears that such actions need to be 1543 performed prior to any loss of end-to-end connectivity on the 1544 selected initial locator, so that any delay in this additional state 1545 exchange does increase the risk of session disruption due to 1546 connectivity changes. 1548 This raises a further question of whether the identity / locator 1549 split is a capability negotiation performed per session or per remote 1550 end, or whether the use of a distinguished identity value by the 1551 upper level application to identify the remote end triggers the 1552 identity / locator mapping functionality further down in the protocol 1553 stack at the transport level, and that this is performed without any 1554 further capability negotiation within the session. 1556 Within the steps related to session startup there is also the 1557 consideration that the passive end of the connection follows a 1558 process where it may need to verify the proposed new address 1559 contained in the source address of incoming packets before using it 1560 as a destination address for outgoing packets. It is not necessarily 1561 the case that the sender's choice of source address reflects a valid 1562 path from the receiver back to the source. While using this offered 1563 address appears to offer a low overhead response to connection 1564 attempts, if this response fails the receiver may need to discover 1565 the full locator set of the remote end through some locator discovery 1566 mechanism in order to establish whether there is a viable locator 1567 that can use a forwarding path that reaches the remote end. 1569 Alternatively, the passive end would use the initially offered 1570 locator and if this is successful leave it to the identity modules in 1571 each stack to exchange information to establish the current complete 1572 locator set for each end. This approach implies that the active end 1573 of a communication needs to cycle through all of its associated 1574 locators as source addresses until it receives a response or exhausts 1575 its locator set. If the other end is also multi-homed (and therefore 1576 has multiple locators) then the active end may need to cycle through 1577 all possible destination locators for each source locator. While 1578 this may extend the time to confirm that no path exists to the remote 1579 end, it has the potential to improve the characteristics of the 1580 initial exchange against denial of service attacks that could force 1581 the remote end to engage in a high volume of spurious locator 1582 lookups. 1584 6.3.5 Dynamic Capability Negotiation 1586 The common aspect of these approaches is that they all involve 1587 changes to the end-to-end interaction, as both ends of the 1588 communication need to be aware of this separation. The implication 1589 is that this form of support for multi-homing is relatively sweeping 1590 in its scope, as the necessary changes to support multi-homing extend 1591 beyond changes to the hosts and/or routers within the multi-homed 1592 site and encompass changes to the IPv6 protocol itself. It would be 1593 prudent when considering these changes to evaluate associated 1594 mechanisms that allow the communicating endpoints to discover each 1595 other's capabilities and only enable this form of split identity / 1596 locator functionality when it is established that both ends can 1597 support it. 1599 It is a corollary of this form of negotiated capability that it is 1600 not strictly necessary that only one form of functionality can be 1601 negotiated in this way. If the adoption of a particular endpoint 1602 identity / locator mapping scheme is the outcome of a negotiation 1603 between the endpoints then it would be possible to negotiate to use 1604 one of a number of possible approaches. There is some interaction 1605 between the approach used and the form of endpoint identity, and some 1606 care needs to be taken that any form of acceptable outcome of the 1607 endpoint identity capability negotiation is one that allows the upper 1608 level application to continue to operate. 1610 6.3.6 Identity Uniqueness and Stability 1612 When considering the properties of long-lived identities, it is 1613 reasonable to assume that the identity assignation is not necessarily 1614 one that is permanent and unchangeable. In the case of structured 1615 identity spaces the identity value reflects a distribution hierarchy. 1616 There are a number of circumstances where a change of identity value 1617 is appropriate. For example, if an endpoint device is moved across 1618 administrative realms of this distribution hierarchy it is likely 1619 that the endpoint's identity value will be re-assigned to reflect the 1620 new realm. It is also reasonable to assume that an endpoint may have 1621 more than one identity at any point in time. RFC 3014 [RFC3041] 1622 provides a rationale for such a use of multiple identities. 1624 If an endpoint's identity can change over time, and if an endpoint 1625 can be identified by more than one identity at any single point in 1626 time, then some further characteristics of endpoint identifiers 1627 should be defined. These relate to the constancy of an endpoint 1628 identity within an application, and the question of whether a 1629 transport session relies on a single endpoint identity value, and, if 1630 so, whether an endpoint identity can be changed within a transport 1631 session, and under what conditions the old identity can continue to 1632 be used following any such change. If the endpoint identity is a 1633 long-lived reference to a remote endpoint, and if multiple identities 1634 can exist for a single unique endpoint, then the question arises as 1635 to whether applications can compare identities for equivalence, and 1636 whether it is necessary for applications to recognise the condition 1637 where different identities refer to the same endpoint. These 1638 identities may be used within applications within a single host, or 1639 may be identifies being used on applications on different hosts. 1641 7. Functional Decomposition of Multi-Homing Approaches 1643 The following sections provide a framework for the characterisation 1644 of multi-homing approaches through a decomposition of the functions 1645 associated with session establishment, maintenance and completion in 1646 the context of a multi-homed environment. 1648 7.1 Establishing Session State 1650 What form of token is passed to the transport layer from the upper 1651 level protocol element as an identification of the local protocol 1652 stack? 1654 What form of token is passed to the transport layer from the upper 1655 level protocol element as an identification of the remote session 1656 target? 1658 What form of token is used by the upper level protocol element as 1659 a self-identification mechanism for use within the application 1660 payload? 1662 Does the identity protocol element need to create a mapping from 1663 the upper level protocol's local and remote identity tokens into 1664 an identity token that identifies the session? If so, then is this 1665 translation performed before or after the initial session packet 1666 exchange handshake? 1668 How does the session initiator establish that the remote end of 1669 the session can support the multi-homing capabilities in its 1670 protocol stack? If not, does the multi-homing capable protocol 1671 element report a session establishment failure to the upper level 1672 protocol, or silently fall back to a non-multi-homed protocol 1673 operation? 1675 How do the endpoints discover the locator set available for each 1676 other endpoint (locator discovery)? 1678 What mechanisms are used to perform locator selection at each end 1679 for the local selection of source and destination locators? 1681 What form of mechanism is used to ensure that the selected site 1682 exit path matches the selected packet source locator? 1684 7.2 Rehoming Triggers 1686 What are common denominator goals of rehoming triggers? What are 1687 the objectives that triggers conservatively should meet across all 1688 types of sessions? 1689 Are there transport session-selective triggers? If so, then what 1690 state changes within the network path should be triggers for all 1691 transport sessions, what state changes are triggers only for 1692 selected transport sessions? 1694 What triggers are used to identify that a switch of locators is 1695 desirable? 1697 Are the triggers based on the end-to-end transport session and/or 1698 on notification of state changes within the network path from the 1699 network? 1701 What triggers can be used to indicate the direction of the failed 1702 path in order to trigger the appropriate locator repair function? 1704 7.3 Rehoming Locator Pair Selection 1706 What parameters are used to determine the selection of a locator 1707 to use to reference the local endpoint? 1709 If the remote endpoint is multi-homed, what parameters are used to 1710 determine the selection of a locator to use to reference the 1711 remote endpoint? 1713 Must a change of an egress site exit router be accompanied by a 1714 change in source and / or destination locators? 1716 How can new locators be added to the locator pool of an existing 1717 session? 1719 7.4 Locator Change 1721 What are the preconditions that are necessary for a locator 1722 change? 1724 How can the locator change be confirmed by both ends? 1726 What interactions are necessary for synchronisation of locator 1727 change and transport session behaviour? 1729 7.5 Removal of Session State 1731 How is identity / locator binding state removal synchronised with 1732 session closure? 1734 What binding information is cached for possible future use? 1736 8. IANA Considerations 1738 [RFC Editor: Please remove this section prior to publication.] 1739 This document has no associated IANA actions. 1741 9. Security Considerations 1743 There are a significant number of security considerations that result 1744 from the action of distinguishing within the protocol suite endpoint 1745 identity and locator identity. 1747 It is not proposed to enumerate these considerations in detail within 1748 this document, but to reference a distinct document that describes 1749 the security considerations of this domain [threats]. 1751 10. Acknowledgements 1753 The author acknowledges the assistance from the following reviewers: 1754 Brian Carpenter, Kurtis Lundqvist, Erik Nordmark, Iljitsch van 1755 Beijnum, Marcelo Bagnulo, John Loughney, Thierry Ernst, Joe Touch, 1756 Michael Patton, Ted Hardie and Allison Mankin. 1758 11 Informative References 1760 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 1761 Stateless Address Autoconfiguration in IPv6", RFC 3041, 1762 January 2001. 1764 [RFC3484] Draves, R., "Default Address Selection for Internet 1765 Protocol version 6 (IPv6)", RFC 3484, February 2003. 1767 [RFC3582] Abley, J., Black, B. and V. Gill, "Goals for IPv6 1768 Site-Multihoming Architectures", RFC 3582, August 2003. 1770 [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support 1771 in IPv6", RFC 3775, June 2004. 1773 [draft-iab-link] 1774 Aboba, B., Ed., "Architectural Implications of Link Layer 1775 Indications", Work in progress: Internet Drafts 1776 draft-iab-link-indications-01.txt, January 2005. 1778 [e2e] Saltzer, J., Reed, D. and D. Clark, "End-to-End Arguments 1779 in System Design", ACM TOCS Vol 2, Number 4, pp 277-288, 1780 November 1984, 1781 . 1784 [rosec] Nikander, P., Arkko, J., Aura, T., Montenegro, G. and E. 1785 Nordmark, "Mobile IP version 6 Route Optimization Security 1786 Design Background", Work in progress: Internet Drafts 1787 draft-ietf-mip6-ro-sec-02.txt, October 2004. 1789 [thinks] Lear, E., "Things MULTI6 Developers should think about", 1790 Work in progress: Internet Drafts 1791 draft-ietf-multi6-things-to-think-about-01.txt, January 1792 2005. 1794 [threats] Nordmark, E. and T. Li, "Threats relating to IPv6 1795 multi-homing solutions", Work in progress: Internet Drafts 1796 draft-ietf-multi6-multihoming-threats-03.txt, January 1797 2005. 1799 Author's Address 1801 Geoff Huston 1802 APNIC 1804 Intellectual Property Statement 1806 The IETF takes no position regarding the validity or scope of any 1807 Intellectual Property Rights or other rights that might be claimed to 1808 pertain to the implementation or use of the technology described in 1809 this document or the extent to which any license under such rights 1810 might or might not be available; nor does it represent that it has 1811 made any independent effort to identify any such rights. Information 1812 on the procedures with respect to rights in RFC documents can be 1813 found in BCP 78 and BCP 79. 1815 Copies of IPR disclosures made to the IETF Secretariat and any 1816 assurances of licenses to be made available, or the result of an 1817 attempt made to obtain a general license or permission for the use of 1818 such proprietary rights by implementers or users of this 1819 specification can be obtained from the IETF on-line IPR repository at 1820 http://www.ietf.org/ipr. 1822 The IETF invites any interested party to bring to its attention any 1823 copyrights, patents or patent applications, or other proprietary 1824 rights that may cover technology that may be required to implement 1825 this standard. Please address the information to the IETF at 1826 ietf-ipr@ietf.org. 1828 Disclaimer of Validity 1830 This document and the information contained herein are provided on an 1831 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1832 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1833 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1834 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1835 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1836 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1838 Copyright Statement 1840 Copyright (C) The Internet Society (2005). This document is subject 1841 to the rights, licenses and restrictions contained in BCP 78, and 1842 except as set forth therein, the authors retain all their rights. 1844 Acknowledgment 1846 Funding for the RFC Editor function is currently provided by the 1847 Internet Society.