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