idnits 2.17.1 draft-huston-l3shim-arch-00.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 678. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 654. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 661. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 667. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 15 instances of too long lines in the document, the longest one being 13 characters in excess of 72. ** The abstract seems to contain references ([ID.FUNC], [ID.L3SHIM], [ID.HBA], [ID.REFER], [ID.ARCH]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 11, 2005) is 7014 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'ID.L3SHIM' on line 624 looks like a reference -- Missing reference section? 'ID.REFER' on line 629 looks like a reference -- Missing reference section? 'ID.FUNC' on line 616 looks like a reference -- Missing reference section? 'ID.HBA' on line 620 looks like a reference -- Missing reference section? 'ID.ARCH' on line 608 looks like a reference -- Missing reference section? 'RFC3484' on line 636 looks like a reference -- Missing reference section? 'ID.FAIL' on line 613 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission G. Huston 3 Internet-Draft APNIC 4 Expires: August 12, 2005 February 11, 2005 6 Architectural Commentary on Site Multi-homing using Level 3 7 Shim 8 draft-huston-l3shim-arch-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all 13 provisions of section 3 of RFC 3667. By submitting this 14 Internet-Draft, each author represents that any applicable 15 patent or other IPR claims of which he or she is aware have 16 been or will be disclosed, and any of which he or she become 17 aware will be disclosed, in accordance with RFC 3668. 19 Internet-Drafts are working documents of the Internet 20 Engineering Task Force (IETF), its areas, and its working 21 groups. Note that other groups may also distribute working 22 documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use 27 Internet-Drafts as reference material or to cite them other 28 than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed 34 at http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 12, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document provides a commentary of the Level 3 Shim 45 approach to site Multi-homing (L3Shim) as described in 46 [ID.L3SHIM], [ID.REFER], [ID.FUNC], and [ID.HBA], using as a 47 framework for this analysis the approach described in 48 [ID.ARCH]. 50 Notes 52 This initial draft has been prepared as a commentary on the L3 53 Shim proposal as developed by a Design Team of the Multi6 54 Working Group. The document attempts to provide a commentary 55 on the proposal according to the framework described in the 56 multi-homing architecture document. 58 The L3 Shim specification is an initial pass, and there are 59 areas where the documentation is incomplete. This commentary 60 is also incomplete, and will require further revision as the L3 61 Shim approach is refined. 63 In addition this initial draft does not analyze the properties 64 of the HBA and CGA address types, and their role in providing 65 some resilience against various forms of third party attacks. 66 This analysis should be included in future revisions of this 67 document. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Summary of L3Shim . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Endpoint Identity . . . . . . . . . . . . . . . . . . . . . . 7 74 4. Functional Decomposition . . . . . . . . . . . . . . . . . . . 8 75 4.1 Establishing Session State . . . . . . . . . . . . . . . . 8 76 4.2 Rehoming Triggers . . . . . . . . . . . . . . . . . . . . 10 77 4.3 Rehoming Locator Pair Selection . . . . . . . . . . . . . 11 78 4.4 Locator Change . . . . . . . . . . . . . . . . . . . . . . 12 79 4.5 Removal of Session State . . . . . . . . . . . . . . . . . 13 80 5. Additional Comments . . . . . . . . . . . . . . . . . . . . . 13 81 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 15 83 6.2 Informative References . . . . . . . . . . . . . . . . . . . 15 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 85 Intellectual Property and Copyright Statements . . . . . . . . 17 87 1. Introduction 89 As noted in the general architectural overview of approached to 90 Multi-homing in IPv6 [ID.ARCH] document, there are a number of 91 general approaches to supporting site Multi-homing. These 92 include the use of the routing system, use of mobility 93 mechanisms, modification of existing elements in the protocol 94 stack, or the introduction of a new protocol stack element, and 95 the modification of behaviours of hosts and site-exit routers. 97 This document provides an commentary of the Level 3 Shim 98 approach to site Multi-homing (L3Shim) as described in 99 [ID.L3SHIM], [ID.REFER], [ID.FUNC], and [ID.HBA], using as a 100 framework for this analysis the approach as described in 101 [ID.ARCH]. 103 2. Summary of L3Shim 105 The approach used by "Level 3 Shim" (L3Shim) is, as the name 106 suggests, one that is based on the modification of the Internet 107 Protocol stack element within the protocol stack of the 108 endpoint. The modification is in the form of an additional 109 functionality block, as indicated in Figure 1. 111 +-----------------------------------------------------------------+ 112 | Transport Protocols | 113 +-----------------------------------------------------------------+ 114 +-----------------------------------------------------------------+ 115 | IP Protocol s | 116 | | 117 | IP Endpoint ------ ------- -------------- ------------- | 118 | sub-layer | AH | | ESP | | Frag/reass | | Dest opts | | 119 | ------ ------- -------------- ------------- | 120 | | | 121 | Multi6 ===================== | 122 | sub-layer ========> || multi6 shim layer || | 123 | ===================== | 124 | | | 125 | IP Routing ------- | 126 | sub-layer | IP | | 127 | ------- | 128 | | 129 +-----------------------------------------------------------------+ 131 L3 Shim Protocol Stack (From [ID.L3SHIM] 132 Figure 1 134 Above the L3Shim protocol element the protocol stack uses 135 constant endpoint identities to refer to both itself and to the 136 remote protocol stack. The shim layer provider a set of 137 associations between endpoint identity pairs and locator sets. 139 As packets are passed from the IP Endpoint sub-layer to the IP 140 Routing sub-layer, the endpoint identities are mapped to a 141 current pair of locators. The reverse mapping is applied to 142 incoming packets, where the incoming locator pair is stripped 143 off the packet, and the associated endpoint identity pair is 144 associated with the packet which is then passed to the IP 145 Endpoint sub-layer. Demultiplexing the IP packet to the 146 appropriate transport session is based on the endpoint 147 identities. In this L3Shim approach the endpoint identities 148 and the locators are both IP addresses. The endpoint 149 identities are the initial addresses used between the two 150 hosts. The locators are the set of IP addresses that are 151 associated with the endpoint. 153 The intention of this approach is to minimise the amount of 154 change required to support dynamic locator agility in the 155 protocol stack, and support dynamic locator agility as a 156 negotiated endpoint-to-endpoint capability. An application can 157 initiate a session with a remote host by using an entirely 158 conventional lookup of the host's domain name in the DNS, and 159 open up a session with the remote endpoint using one of its 160 addresses as the destination address. The application can 161 continue to exchange packets with this remote host for the 162 duration of the session by continuing to use this destination 163 address. If the local host subsequently opens up a new session 164 with the same remote host, the same destination address may be 165 used, or if the local host passes a reference to a third party 166 as a referral, the same destination address may be used. In 167 terms of semantics and functionality this represented no change 168 to the use of addresses as endpoint identifiers in the IPv6 169 architecture. 171 The Layer 3 shim operates as a per-host header address mapping 172 function. When the shim locator mapping function is activated 173 for a remote endpoint packets passed from the IP endpoint 174 sub-layer to the shim sub-layer have the packet's headers 175 source and destination addresses rewritten with the currently 176 selected locator pair. Incoming packets passed from the IP 177 Routing sub-layer undergo a similar lookup using the locator 178 pair. The packet header is rewritten with the mapped endpoint 179 identifier pair is there is an active mapping entry. This 180 functionality is indicated in Figure 2. Here the endpoint 181 identities are referred to as Upper Layer Identifiers (ULIDs), 182 and the packet header addresses are referred to as Locators 183 (L). The L3Shim element contains a context state, associating 184 a ULID pair (in this case the pair [ULID(A),ULID(B)] with a set 185 of locators for A and a set of locators for B. The shim 186 elements are synchronised such that complementary mappings are 187 performed at each end of the connection. 189 ---------------------------- ---------------------------- 190 | Sender A | | Receiver B | 191 | | | | 192 | ULP | | ULP | 193 | | | | ^ | 194 | | src ULID(A) | | | src ULID(A) | 195 | | dst ULID(B) | | | dst ULID(B) | 196 | v | | | | 197 |---L3Shim-----------------| |---L3Shim-----------------| 198 | | | | ^ | 199 | | src L(A) | | | src L(A) | | 200 | | dst L(B) | | | dst L(A) | 201 | v | | | | 202 | IP | | IP | 203 ---------------------------- ---------------------------- 204 | ^ 205 --------------- network path -- ------- 207 Mapping with changed locators.(From [ID.L3SHIM] 209 Figure 2 211 The implication of the decision to place the endpoint 212 identity-to-locator mapping protocol element within the IP 213 element is that this mapping function is not implicitly aware 214 of session start and tear down. At this level of the protocol 215 stack there is no information to indicate wither this packet is 216 a single datagram, or the start of an extended packet exchange 217 with a remote entity. Similarly there is no explicit 218 information provided to the shim protocol element to indicate 219 when a session is complete, at which point the mapping state 220 information could be discarded and the associated host 221 resources reclaimed. This is offset by the advantages of this 222 approach in that there is no explicit need to alter the 223 function of any transport protocol, as the shim element 224 continues to present constant endpoint identities to the upper 225 protocol levels, irrespective of the current endpoint/locator 226 mapping being used between the two hosts. 228 Assuming that the initial choice of a ULID corresponds to a 229 viable network path, the initial state of the L3Shim is a null 230 mapping, as the ULID is also a viable locator. The use of 231 alternate locators by the L3Shim is a triggered response, based 232 on a network path unreachability signal. 234 3. Endpoint Identity 236 There are a number of options in the choice of an endpoint 237 identity realm, including the use of existing addresses as an 238 identity tokens, the use of distinguished (possibly 239 non-routeable) addresses as tokens, or the use of tokens drawn 240 from a different realm (such as use of a fully qualified domain 241 name). 243 L3Shim uses the first of these options, and the endpoint 244 identity for a host is one of the locator addresses that are 245 normally associated with the host. The particular locator 246 address selected to be the endpoint identity (or ULID) is 247 specified in [RFC3484]. L3Shim does not mandate the use of 248 distinguished addresses as identities, although the use 249 non-routeable distinguished addresses in this context is 250 described as an option in this approach. 252 The L3Shim approach defines the initial selector of the locator 253 addresses pair is to be the same as the ULID pair. 254 Accordingly, the initial state of the multi6 shim element is a 255 null transform. This allows the initial establishment of a 256 transport session without the requirement to perform a multi6 257 capability negotiation. 259 The choice of a locator as the endpoint identity for the upper 260 protocol layers implies there is no impact in terms of implied 261 changes to transport protocols or the upper level applications. 262 Applications can continue to resolve fully qualified domain 263 names to a set of addresses, and then open a session with the 264 remote party specifying a selected address as the address of 265 the remote party. The addresses used as source and destination 266 identifiers can continue to be used in the context of 267 pseudo-header checksums, session demultiplexing, packet 268 reassembly contexts following fragmentation, IPSEC security 269 associations, callbacks and referrals, all without alteration. 270 The use in callbacks and referrals can be further generalised 271 to the use of these address in the application payload. 272 Irrespective of any subsequent change in the locator pair, the 273 protocol stack above the Level 3 shim element will continue to 274 use the original ULID pair, and any use of these values in 275 payloads will continue to match the endpoint identities. 277 4. Functional Decomposition 279 4.1 Establishing Session State 281 What form of token is passed to the IP layer from the upper 282 level protocol element as an identification of the local 283 protocol stack? 285 There is no requirement to change the conventional 286 behaviour of the protocol stack. The upper protocol 287 level may use a specified address as a source address, or 288 the upper level may explicitly defer the selection of a 289 source address to the IP level. Conventionally, the 290 selected source address is the IP address of the outbound 291 interface that the IP protocol will use to send the 292 packet towards the destination address. In the case of 293 an L3Shim-enabled stack, the source address selection 294 function would need to consult a local state as to 295 whether the destination address is associated with a 296 currently active M6 state (interpreting the destination 297 address as a ULID). In this case the selected source 298 address, as seen by the upper level protocol stack 299 element is the ULID of the stored state associated with 300 the destination ULID. Otherwise the selected source 301 address is a selected IP address from the set of 302 addresses associated with the particular host interface 303 that will be used to send the packet, as happens in a 304 conventional IPv6 protocol stack. 306 What form of token is passed to the IP layer from the upper 307 level protocol element as an identification of the remote 308 session target? 310 The token passed to the IP layer as the ULID of the 311 destination is the address of the destination host. If 312 the initial identification of the remote host is via a 313 domain name, then this approach assumes that there are a 314 one or more locators held in the DNS. The local host to 315 performs a name-to-address DNS lookup to obtain a set of 316 locators (recorded in the DNS using AAAA resource 317 records). The host then performs a selection from this 318 set of locators and uses the selected address as the 319 identification of the remote host. This implies no 320 change to the conventional behaviour of the IP protocol 321 stack element. 323 What form of token is used by the upper level protocol 324 element as a endpoint identification mechanism for use 325 within the application payload? 327 There is no change to the existing behaviour in this 328 approach. The upper level protocol element may use a 329 domain name, or an IP address as an identification token. 331 Does the identity protocol element need to create a mapping 332 from the upper level protocol's local and remote identity 333 tokens into an identity token that identifies the session? 334 If so, then is this translation performed before or after 335 the initial session packet exchange handshake? 337 In looking at the interface between the application level 338 and the transport level of the protocol stack, there is 339 no requirement to create a mapping between the upper 340 level identifiers and the session identifiers, as the 341 session identifiers are the same upper level identifiers. 342 In looking at the interface between the transport and 343 internet protocol stack elements, then the L3 Shim 344 element has to check if there is an already established 345 L3 Shim state that is associated with the ULIDs of the 346 packet being sent. If so, then the translation from the 347 ULID pair to the currently active locator pair is 348 performed by the L3Shim protocol element. If not, then 349 no state is created and no mapping is performed. This 350 infers that an initial session packet exchange handshake 351 is supported without the requirement to establish an 352 identity to locator mapping state. 354 How does the session initiator establish that the remote end 355 of the session can support the multi-homing capabilities in 356 its protocol stack? If not, does the multi-homing capable 357 protocol element report a session establishment failure to 358 the upper level protocol, or silently fall back to a 359 non-multi-homed protocol operation? 361 The session initiator determines the ability of the 362 remote end to support the L3Shim protocol via explicit 363 negotiation. The L3Shim protocol will continue to 364 operate in a conventional mode if the capability 365 negotiation fails for L3Shim support. The nature of the 366 communication exchange to determine the capability to use 367 L3Shim support is not described in [ID.L3SHIM]. 369 How do the endpoints discover the locator set available for 370 each other endpoint (locator discovery)? 371 The mechanism is by explicit exchange of locator sets 372 between the hosts. The L3Shim description does not 373 describe the precise mechanism. Section 6 of [ID.L3SHIM] 374 notes that once the initial capability exchange has 375 completed "both ends know a set of locators for the peer 376 that are acceptable as the source in received packets." 377 This explicit exchange of locators is not necessarily 378 aligned to multiple AAAA Resource records in the DNS. 380 What mechanisms are used to perform locator selection at 381 each end for the local selection of source and destination 382 locators? 384 The initial choice of source and destination locators 385 matches the initial choice of upper level identifiers, 386 namely the initial addresses used as the upper level 387 identifiers. The remote address is obtained using 388 conventional DNS lookup. The local address is based on 389 an address selection from the addresses associated with 390 the outbound interface, using the procedure described in 391 [RFC3484]. 393 What form of mechanism is used to ensure that the selected 394 site exit path matches the selected packet source locator? 396 This is not described in the current L3Shim description. 398 4.2 Rehoming Triggers 400 What triggers are used to identify that a switch of locators is 401 desirable? 403 The L3Shim documentation covers a number of options, but 404 does not provide definitive answers to this question. The 405 [ID.FAIL] notes four approaches: namely positive feedback 406 from the upper level sessions, negative feedback from the 407 upper level sessions, explicit reachability tests and ICMP 408 error messages. 409 From the discussion in this draft it appears that negative 410 feedback from upper layer transport sessions in the form of 411 ACK timeouts is the preferred locator change trigger 412 mechanism. 414 Are the triggers based on the end-to-end transport session 415 and/or on notification of state changes within the network path 416 from the network? 418 [ID.FAIL] argues that network path-based triggers, in the 419 form of received ICMP errors messages are prone to spoofing, 420 and should only be used "as a hint to perform an explicit 421 reachability test". Triggers are based on explicit negative 422 information being passed from an active transport session 423 (ACK timeouts). There is also the possibility of using 424 positive feedback from the transport sessions, where a 425 timeout of positive indication is an indication of a 426 reachability problem. In this case, as with ICMP, an 427 explicit reachability test is required to confirm the 428 indication of locator failure. 430 What triggers can be used to indicate the direction of the 431 failed path in order to trigger the appropriate locator repair 432 function? 434 The [ID.FAIL] description does not provide a description of 435 detection of the failed path. The L3Shim approach attempts 436 to treat path failure as a failure of the locator pair, 437 rather than failure of a single locator, so the direction of 438 the failure is not necessarily critical information in the 439 search for a new functional pair. 441 4.3 Rehoming Locator Pair Selection 443 What parameters are used to determine the selection of a 444 locator to use to reference the local endpoint? 446 The selection of a locator is based on the application of 447 the tables as described in RFC 3484 [RFC3484]. The approach 448 also allows local policy settings to place a preference for 449 particular locator pairs. Selection of a specific locator 450 pair is based on the successful outcome of a return 451 reachability test between the two endpoints. 453 If the remote endpoint is multi-homed, what parameters are used 454 to determine the selection of a locator to use to reference the 455 remote endpoint? 457 Same as the previous response. 459 Must a change of an egress site exit router be accompanied by a 460 change in source and / or destination locators? 461 This appears to be an area for further study. The situation 462 is not explicitly addressed in the L3Shim documentation. 464 How can new locators be added to the locator pool of an 465 existing session? 467 The explicit L3Shim capability negotiation allows the two 468 endpoints to exchange a set of locators as part of the 469 initial setup. This set is then tested, as required, using 470 explicitly reachability tests when the endpoints are 471 searching for a viable locator pair. The outcome of locator 472 pair reachability tests are stored in an ageing local cache. 473 This allows recently tested pairs that passed the 474 reachability test to be used in preference to untested 475 locator pairs. 476 [ID.FAIL] describes a set of abstract message exchanges for 477 L3Shim locator set maintenance that includes explicit "add" 478 and Delete" commands to allow a host to instruct the remote 479 end to add or remove locators from its locator set. 481 4.4 Locator Change 483 What are the preconditions that are necessary for a locator 484 change? 486 The preconditions necessary is that there has been a 487 successful establishment of packets between the two hosts, 488 L3Shim capabilities have been successfully negotiated and 489 locator sets have been exchanged, and there is an explicit 490 trigger for a locator change that has been generated by an 491 active transport session. IN addition reception of a packet 492 where the locator par is a member of the locator set for 493 this host pair implies a remotely-triggered locator change. 495 How can the locator change be confirmed by both ends? 497 The approach proposed here is by using a return reachability 498 test, where a host searches through locator pair selections 499 until it receives an explicit acknowledgement of a poll. 501 What interactions are necessary for synchronisation of locator 502 change and transport session behaviour? 503 As noted in [ID.FAIL], there is consideration that any 504 locator change in the Layer 3 shim should trigger a 505 notification to the transport layer protocol. In the case 506 of TCP this notification would be used to trigger a 507 resetting of the TCP congestion state to slow start, 508 corresponding to the selection of a new network path. 510 4.5 Removal of Session State 512 How is identity / locator binding state removal synchronised 513 with session closure? 515 As this is a layer 3 function there is no explicit concept 516 of sessions. A L3 Shim mapping state needs to be maintained 517 for as long as there is packet activity in either direction. 518 The removal of state would most likely be associated with a 519 removal eligibility condition associated with a packet 520 activity timeout, and an eligible state removal pass being 521 undertaken by the L3 Shim statement management module. 523 What binding information is cached for possible future use? 525 The L3 Shim state information is the association of a ULID 526 pair with a set of local and remote locators. This 527 information may require periodic refreshing with the 528 exchange of locator sets with the remote host in order to 529 ensure that the remote host is also maintaining a L3 Shim 530 state, and the locator sets are synchronised. 532 5. Additional Comments 534 The approach of using a IP layer mapping between upper level 535 endpoint identity and lower level locators has a number of 536 specific issues that have yet to be fully specified in the 537 L3Shim documentation. Some of these are listed here. 539 The signalling interface between the L3 Shim and the upper 540 layers pf the protocol stack requires further consideration. 541 The decision to initiate a L3Shim capability negotiation with a 542 remote host may benefit from an explicit upper layer signal to 543 the shim protocol element. In turn this could allow 544 applications to signal a desire to initiate this capability 545 negotiation at the start of an extended communication session. 546 Equally, it may be of benefit for the upper level protocol to 547 be ab;e to query the L3 state for a particular remote host, to 548 establish whether there has been a capability negotiation 549 performed, and if successful, the current active locator and 550 the full locator set. 552 It may also be useful to allow the upper level protocol to 553 explicitly indicate that any form of L3 functionality should 554 not be applied to this session. The implication of this 555 functionality is that incoming packets need to provide some 556 form of positive indication that the incoming locator pair 557 should be mapped to an equivalent ULID pair, while packets 558 without this indication should be processed in a conventional 559 fashion with any L3 Shim packet header mapping. The L3 560 documentation suggests that some form of explicit tagging 561 should be performed in the IPv6 Flow Id field, but further 562 details have not been provided. 564 The potential use of unreachable ULIDs as the initial choice of 565 ULIDs and the consequent requirement to undertake a reachable 566 locator search, capability negotiation and establishment of a 567 L3 Shim mapping state is mentioned in the L3 Shim documents, 568 but at a relatively abstract level. This requires further 569 consideration in terms of the potential failures, and the 570 appropriate signalling to be passed back to the ULP in such 571 cases. 573 The issue of ambiguity of demultiplexing may require further 574 consideration. If there are multiple AAAA resource records in 575 the DNS, or the resource records change over the lifetime of 576 active communication, it is possible to have multiple L3 Shim 577 states set up for the same remote host, with distinct ULIDs for 578 the remote host. An incoming packet with a given locator pair 579 will, according to the L3Shim documentation, need to use the 580 locator pair as a lookup key into the L3 Shim state information 581 to establish the associated ULID pair. In the case of multiple 582 active ULIDs for the same remote host this lookup will result 583 in multiple ULIDs. 585 The treatment of trigger conditions for locator change also 586 requires further consideration. As noted in [ID.ARCH], 587 different upper level transports may have different sensitivity 588 requirements to locator triggers. When the mapping is 589 performed on a host=-by-host basis rather than per transport 590 session, there is a consequent requirement to balance the 591 relative levels of sensitivity to locator change across all 592 concurrently active transport session. It may be necessary to 593 explore the concept of associating a L3 Shim state to 594 particular transport sessions, allowing each session to 595 establish its preferred level of sensitivity to network events 596 that may trigger a locator change. 598 The interaction between locator pair selection, local 599 forwarding decision, site exit routers and packet ingress 600 filters on the immediately adjacent upstream provider routers 601 does not appear to be considered in the current l3 Shim 602 documentation. 604 6. References 606 6.1 Normative References 608 [ID.ARCH] Huston, G., "Architectural Approaches to 609 Multi-Homing for IPv6", Work in progress: Internet 610 Drafts draft-ietf-multi6-architecture-03.txt, 611 January 2005. 613 [ID.FAIL] , J., "", Work in progress: Internet Drafts 614 draft-arkko-multi6dt-failure-detection-00.txt, 2004. 616 [ID.FUNC] , M. and J. , "Functional Decomposition of the M6 617 protocol", Work in progress: Internet Drafts 618 draft-ietf-multi6-functional-dec-00.txt, 2005. 620 [ID.HBA] , M., "Hash Based Addresses (HBA)", Work in 621 progress: Internet Drafts 622 draft-ietf-multi6-hba-00.txt, 2004. 624 [ID.L3SHIM] 625 , E. and M. , "Multihoming L3 Shim Approach", Work 626 in progress: Internet Drafts 627 draft-ietf-multi6-l3shim-00.txt, 2005. 629 [ID.REFER] 630 , E., "Multi6 Application Referral Issues", Work in 631 progress: Internet Drafts 632 draft-ietf-multi6-app-refer-00.txt, 2005. 634 6.2 Informative References 636 [RFC3484] Draves, R., "Default Address Selection for Internet 637 Protocol version 6 (IPv6)", RFC 3484, February 2003. 639 Author's Address 641 Geoff Huston 642 APNIC 644 Intellectual Property Statement 646 The IETF takes no position regarding the validity or scope of 647 any Intellectual Property Rights or other rights that might be 648 claimed to pertain to the implementation or use of the 649 technology described in this document or the extent to which 650 any license under such rights might or might not be available; 651 nor does it represent that it has made any independent effort 652 to identify any such rights. Information on the procedures 653 with respect to rights in RFC documents can be found in BCP 78 654 and BCP 79. 656 Copies of IPR disclosures made to the IETF Secretariat and any 657 assurances of licenses to be made available, or the result of 658 an attempt made to obtain a general license or permission for 659 the use of such proprietary rights by implementers or users of 660 this specification can be obtained from the IETF on-line IPR 661 repository at http://www.ietf.org/ipr. 663 The IETF invites any interested party to bring to its attention 664 any copyrights, patents or patent applications, or other 665 proprietary rights that may cover technology that may be 666 required to implement this standard. Please address the 667 information to the IETF at ietf-ipr@ietf.org. 669 Disclaimer of Validity 671 This document and the information contained herein are provided 672 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 673 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET 674 SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 675 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 676 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 677 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 678 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 680 Copyright Statement 682 Copyright (C) The Internet Society (2005). This document is 683 subject to the rights, licenses and restrictions contained in 684 BCP 78, and except as set forth therein, the authors retain all 685 their rights. 687 Acknowledgment 689 Funding for the RFC Editor function is currently provided by 690 the Internet Society.