--- 1/draft-ietf-shim6-proto-08.txt 2007-11-01 19:12:11.000000000 +0100 +++ 2/draft-ietf-shim6-proto-09.txt 2007-11-01 19:12:11.000000000 +0100 @@ -1,17 +1,19 @@ SHIM6 WG E. Nordmark Internet-Draft Sun Microsystems -Expires: November 2, 2007 M. Bagnulo +Expires: April 3, 2008 M. Bagnulo UC3M + October 2007 + Shim6: Level 3 Multihoming Shim Protocol for IPv6 - draft-ietf-shim6-proto-08.txt + draft-ietf-shim6-proto-09.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -22,21 +24,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on November 2, 2007. + This Internet-Draft will expire on April 3, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines the Shim6 protocol, a layer 3 shim for providing locator agility below the transport protocols, so that multihoming can be provided for IPv6 with failover and load sharing @@ -55,169 +57,169 @@ 1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Locators as Upper-layer IDentifiers (ULID) . . . . . . . 6 1.4. IP Multicast . . . . . . . . . . . . . . . . . . . . . . 7 1.5. Renumbering Implications . . . . . . . . . . . . . . . . 8 1.6. Placement of the shim . . . . . . . . . . . . . . . . . . 9 1.7. Traffic Engineering . . . . . . . . . . . . . . . . . . . 11 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 12 2.2. Notational Conventions . . . . . . . . . . . . . . . . . 15 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 17 - 4.1. Context Tags . . . . . . . . . . . . . . . . . . . . . . 19 - 4.2. Context Forking . . . . . . . . . . . . . . . . . . . . . 19 - 4.3. API Extensions . . . . . . . . . . . . . . . . . . . . . 20 - 4.4. Securing Shim6 . . . . . . . . . . . . . . . . . . . . . 20 - 4.5. Overview of Shim Control Messages . . . . . . . . . . . . 21 - 4.6. Extension Header Order . . . . . . . . . . . . . . . . . 22 - 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 24 - 5.1. Common Shim6 Message Format . . . . . . . . . . . . . . . 24 - 5.2. Payload Extension Header Format . . . . . . . . . . . . . 25 - 5.3. Common Shim6 Control header . . . . . . . . . . . . . . . 25 - 5.4. I1 Message Format . . . . . . . . . . . . . . . . . . . . 27 - 5.5. R1 Message Format . . . . . . . . . . . . . . . . . . . . 28 - 5.6. I2 Message Format . . . . . . . . . . . . . . . . . . . . 30 - 5.7. R2 Message Format . . . . . . . . . . . . . . . . . . . . 32 - 5.8. R1bis Message Format . . . . . . . . . . . . . . . . . . 33 - 5.9. I2bis Message Format . . . . . . . . . . . . . . . . . . 34 - 5.10. Update Request Message Format . . . . . . . . . . . . . . 36 - 5.11. Update Acknowledgement Message Format . . . . . . . . . . 38 - 5.12. Keepalive Message Format . . . . . . . . . . . . . . . . 39 - 5.13. Probe Message Format . . . . . . . . . . . . . . . . . . 39 - 5.14. Error Message Format . . . . . . . . . . . . . . . . . . 40 - 5.15. Option Formats . . . . . . . . . . . . . . . . . . . . . 41 - 5.15.1. Responder Validator Option Format . . . . . . . . . 43 - 5.15.2. Locator List Option Format . . . . . . . . . . . . . 44 - 5.15.3. Locator Preferences Option Format . . . . . . . . . 46 - 5.15.4. CGA Parameter Data Structure Option Format . . . . . 48 - 5.15.5. CGA Signature Option Format . . . . . . . . . . . . 48 - 5.15.6. ULID Pair Option Format . . . . . . . . . . . . . . 49 - 5.15.7. Forked Instance Identifier Option Format . . . . . . 50 - 5.15.8. Keepalive Timeout Option Format . . . . . . . . . . 50 - 6. Conceptual Model of a Host . . . . . . . . . . . . . . . . . 51 - 6.1. Conceptual Data Structures . . . . . . . . . . . . . . . 51 - 6.2. Context States . . . . . . . . . . . . . . . . . . . . . 52 - 7. Establishing ULID-Pair Contexts . . . . . . . . . . . . . . . 54 - 7.1. Uniqueness of Context Tags . . . . . . . . . . . . . . . 54 - 7.2. Locator Verification . . . . . . . . . . . . . . . . . . 54 - 7.3. Normal context establishment . . . . . . . . . . . . . . 55 - 7.4. Concurrent context establishment . . . . . . . . . . . . 55 - 7.5. Context recovery . . . . . . . . . . . . . . . . . . . . 57 - 7.6. Context confusion . . . . . . . . . . . . . . . . . . . . 59 - 7.7. Sending I1 messages . . . . . . . . . . . . . . . . . . . 60 - 7.8. Retransmitting I1 messages . . . . . . . . . . . . . . . 61 - 7.9. Receiving I1 messages . . . . . . . . . . . . . . . . . . 61 - 7.10. Sending R1 messages . . . . . . . . . . . . . . . . . . . 62 - 7.10.1. Generating the R1 Validator . . . . . . . . . . . . 63 - 7.11. Receiving R1 messages and sending I2 messages . . . . . . 63 - 7.12. Retransmitting I2 messages . . . . . . . . . . . . . . . 64 - 7.13. Receiving I2 messages . . . . . . . . . . . . . . . . . . 64 - 7.14. Sending R2 messages . . . . . . . . . . . . . . . . . . . 66 - 7.15. Match for Context Confusion . . . . . . . . . . . . . . . 66 - 7.16. Receiving R2 messages . . . . . . . . . . . . . . . . . . 67 - 7.17. Sending R1bis messages . . . . . . . . . . . . . . . . . 68 - 7.17.1. Generating the R1bis Validator . . . . . . . . . . . 69 - 7.18. Receiving R1bis messages and sending I2bis messages . . . 69 - 7.19. Retransmitting I2bis messages . . . . . . . . . . . . . . 70 - 7.20. Receiving I2bis messages and sending R2 messages . . . . 70 - 8. Handling ICMP Error Messages . . . . . . . . . . . . . . . . 73 - 9. Teardown of the ULID-Pair Context . . . . . . . . . . . . . . 75 - 10. Updating the Peer . . . . . . . . . . . . . . . . . . . . . . 76 - 10.1. Sending Update Request messages . . . . . . . . . . . . . 76 - 10.2. Retransmitting Update Request messages . . . . . . . . . 76 - 10.3. Newer Information While Retransmitting . . . . . . . . . 77 - 10.4. Receiving Update Request messages . . . . . . . . . . . . 77 - 10.5. Receiving Update Acknowledgement messages . . . . . . . . 79 - 11. Sending ULP Payloads . . . . . . . . . . . . . . . . . . . . 80 - 11.1. Sending ULP Payload after a Switch . . . . . . . . . . . 80 - 12. Receiving Packets . . . . . . . . . . . . . . . . . . . . . . 82 - 12.1. Receiving payload without extension headers . . . . . . . 82 - 12.2. Receiving Payload Extension Headers . . . . . . . . . . . 82 - 12.3. Receiving Shim Control messages . . . . . . . . . . . . . 83 - 12.4. Context Lookup . . . . . . . . . . . . . . . . . . . . . 83 - 13. Initial Contact . . . . . . . . . . . . . . . . . . . . . . . 86 - 14. Protocol constants . . . . . . . . . . . . . . . . . . . . . 87 - 15. Implications Elsewhere . . . . . . . . . . . . . . . . . . . 88 - 15.1. Congestion Control Considerations . . . . . . . . . . . . 88 - 15.2. Middle-boxes considerations . . . . . . . . . . . . . . . 88 - 15.3. Other considerations . . . . . . . . . . . . . . . . . . 89 - 16. Security Considerations . . . . . . . . . . . . . . . . . . . 91 - 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 94 - 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 96 - Appendix A. Possible Protocol Extensions . . . . . . . . . . 97 - Appendix B. Simplified State Machine . . . . . . . . . . . . 99 - Appendix B.1. Simplified State Machine diagram . . . . . . . . 104 - Appendix C. Context Tag Reuse . . . . . . . . . . . . . . . . 106 - Appendix C.1. Context Recovery . . . . . . . . . . . . . . . . 106 - Appendix C.2. Context Confusion . . . . . . . . . . . . . . . . 106 - Appendix C.3. Three Party Context Confusion . . . . . . . . . . 107 - Appendix D. Design Alternatives . . . . . . . . . . . . . . . 108 - Appendix D.1. Context granularity . . . . . . . . . . . . . . . 108 + 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 18 + 4.1. Context Tags . . . . . . . . . . . . . . . . . . . . . . 20 + 4.2. Context Forking . . . . . . . . . . . . . . . . . . . . . 20 + 4.3. API Extensions . . . . . . . . . . . . . . . . . . . . . 21 + 4.4. Securing Shim6 . . . . . . . . . . . . . . . . . . . . . 21 + 4.5. Overview of Shim Control Messages . . . . . . . . . . . . 22 + 4.6. Extension Header Order . . . . . . . . . . . . . . . . . 23 + 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 25 + 5.1. Common Shim6 Message Format . . . . . . . . . . . . . . . 25 + 5.2. Payload Extension Header Format . . . . . . . . . . . . . 26 + 5.3. Common Shim6 Control header . . . . . . . . . . . . . . . 26 + 5.4. I1 Message Format . . . . . . . . . . . . . . . . . . . . 28 + 5.5. R1 Message Format . . . . . . . . . . . . . . . . . . . . 29 + 5.6. I2 Message Format . . . . . . . . . . . . . . . . . . . . 31 + 5.7. R2 Message Format . . . . . . . . . . . . . . . . . . . . 33 + 5.8. R1bis Message Format . . . . . . . . . . . . . . . . . . 34 + 5.9. I2bis Message Format . . . . . . . . . . . . . . . . . . 36 + 5.10. Update Request Message Format . . . . . . . . . . . . . . 38 + 5.11. Update Acknowledgement Message Format . . . . . . . . . . 39 + 5.12. Keepalive Message Format . . . . . . . . . . . . . . . . 40 + 5.13. Probe Message Format . . . . . . . . . . . . . . . . . . 41 + 5.14. Error Message Format . . . . . . . . . . . . . . . . . . 41 + 5.15. Option Formats . . . . . . . . . . . . . . . . . . . . . 42 + 5.15.1. Responder Validator Option Format . . . . . . . . . 45 + 5.15.2. Locator List Option Format . . . . . . . . . . . . . 45 + 5.15.3. Locator Preferences Option Format . . . . . . . . . 47 + 5.15.4. CGA Parameter Data Structure Option Format . . . . . 49 + 5.15.5. CGA Signature Option Format . . . . . . . . . . . . 49 + 5.15.6. ULID Pair Option Format . . . . . . . . . . . . . . 50 + 5.15.7. Forked Instance Identifier Option Format . . . . . . 51 + 5.15.8. Keepalive Timeout Option Format . . . . . . . . . . 51 + 6. Conceptual Model of a Host . . . . . . . . . . . . . . . . . 52 + 6.1. Conceptual Data Structures . . . . . . . . . . . . . . . 52 + 6.2. Context States . . . . . . . . . . . . . . . . . . . . . 54 + 7. Establishing ULID-Pair Contexts . . . . . . . . . . . . . . . 56 + 7.1. Uniqueness of Context Tags . . . . . . . . . . . . . . . 56 + 7.2. Locator Verification . . . . . . . . . . . . . . . . . . 56 + 7.3. Normal context establishment . . . . . . . . . . . . . . 57 + 7.4. Concurrent context establishment . . . . . . . . . . . . 57 + 7.5. Context recovery . . . . . . . . . . . . . . . . . . . . 59 + 7.6. Context confusion . . . . . . . . . . . . . . . . . . . . 61 + 7.7. Sending I1 messages . . . . . . . . . . . . . . . . . . . 62 + 7.8. Retransmitting I1 messages . . . . . . . . . . . . . . . 63 + 7.9. Receiving I1 messages . . . . . . . . . . . . . . . . . . 63 + 7.10. Sending R1 messages . . . . . . . . . . . . . . . . . . . 64 + 7.10.1. Generating the R1 Validator . . . . . . . . . . . . 65 + 7.11. Receiving R1 messages and sending I2 messages . . . . . . 65 + 7.12. Retransmitting I2 messages . . . . . . . . . . . . . . . 66 + 7.13. Receiving I2 messages . . . . . . . . . . . . . . . . . . 66 + 7.14. Sending R2 messages . . . . . . . . . . . . . . . . . . . 68 + 7.15. Match for Context Confusion . . . . . . . . . . . . . . . 68 + 7.16. Receiving R2 messages . . . . . . . . . . . . . . . . . . 69 + 7.17. Sending R1bis messages . . . . . . . . . . . . . . . . . 70 + 7.17.1. Generating the R1bis Validator . . . . . . . . . . . 71 + 7.18. Receiving R1bis messages and sending I2bis messages . . . 71 + 7.19. Retransmitting I2bis messages . . . . . . . . . . . . . . 72 + 7.20. Receiving I2bis messages and sending R2 messages . . . . 72 + 8. Handling ICMP Error Messages . . . . . . . . . . . . . . . . 75 + 9. Teardown of the ULID-Pair Context . . . . . . . . . . . . . . 77 + 10. Updating the Peer . . . . . . . . . . . . . . . . . . . . . . 78 + 10.1. Sending Update Request messages . . . . . . . . . . . . . 78 + 10.2. Retransmitting Update Request messages . . . . . . . . . 78 + 10.3. Newer Information While Retransmitting . . . . . . . . . 79 + 10.4. Receiving Update Request messages . . . . . . . . . . . . 79 + 10.5. Receiving Update Acknowledgement messages . . . . . . . . 81 + 11. Sending ULP Payloads . . . . . . . . . . . . . . . . . . . . 83 + 11.1. Sending ULP Payload after a Switch . . . . . . . . . . . 83 + 12. Receiving Packets . . . . . . . . . . . . . . . . . . . . . . 85 + 12.1. Receiving payload without extension headers . . . . . . . 85 + 12.2. Receiving Payload Extension Headers . . . . . . . . . . . 85 + 12.3. Receiving Shim Control messages . . . . . . . . . . . . . 86 + 12.4. Context Lookup . . . . . . . . . . . . . . . . . . . . . 86 + 13. Initial Contact . . . . . . . . . . . . . . . . . . . . . . . 89 + 14. Protocol constants . . . . . . . . . . . . . . . . . . . . . 90 + 15. Implications Elsewhere . . . . . . . . . . . . . . . . . . . 91 + 15.1. Congestion Control Considerations . . . . . . . . . . . . 91 + 15.2. Middle-boxes considerations . . . . . . . . . . . . . . . 91 + 15.3. Other considerations . . . . . . . . . . . . . . . . . . 92 + 16. Security Considerations . . . . . . . . . . . . . . . . . . . 94 + 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 97 + 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 99 + Appendix A. Possible Protocol Extensions . . . . . . . . . . 100 + Appendix B. Simplified State Machine . . . . . . . . . . . . 102 + Appendix B.1. Simplified State Machine diagram . . . . . . . . 107 + Appendix C. Context Tag Reuse . . . . . . . . . . . . . . . . 109 + Appendix C.1. Context Recovery . . . . . . . . . . . . . . . . 109 + Appendix C.2. Context Confusion . . . . . . . . . . . . . . . . 109 + Appendix C.3. Three Party Context Confusion . . . . . . . . . . 110 + Appendix D. Design Alternatives . . . . . . . . . . . . . . . 111 + Appendix D.1. Context granularity . . . . . . . . . . . . . . . 111 Appendix D.2. Demultiplexing of data packets in Shim6 - communications . . . . . . . . . . . . . . . . . 108 - Appendix D.2.1. Flow-label . . . . . . . . . . . . . . . . . . . 109 - Appendix D.2.2. Extension Header . . . . . . . . . . . . . . . . 111 - Appendix D.3. Context Loss Detection . . . . . . . . . . . . . 112 - Appendix D.4. Securing locator sets . . . . . . . . . . . . . . 114 - Appendix D.5. ULID-pair context establishment exchange . . . . 117 - Appendix D.6. Updating locator sets . . . . . . . . . . . . . . 118 - Appendix D.7. State Cleanup . . . . . . . . . . . . . . . . . . 118 - Appendix E. Change Log . . . . . . . . . . . . . . . . . . . 121 - 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 127 - 19.1. Normative References . . . . . . . . . . . . . . . . . . 127 - 19.2. Informative References . . . . . . . . . . . . . . . . . 127 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 130 - Intellectual Property and Copyright Statements . . . . . . . . . 131 + communications . . . . . . . . . . . . . . . . . 111 + Appendix D.2.1. Flow-label . . . . . . . . . . . . . . . . . . . 112 + Appendix D.2.2. Extension Header . . . . . . . . . . . . . . . . 114 + Appendix D.3. Context Loss Detection . . . . . . . . . . . . . 115 + Appendix D.4. Securing locator sets . . . . . . . . . . . . . . 117 + Appendix D.5. ULID-pair context establishment exchange . . . . 120 + Appendix D.6. Updating locator sets . . . . . . . . . . . . . . 121 + Appendix D.7. State Cleanup . . . . . . . . . . . . . . . . . . 121 + Appendix E. Change Log . . . . . . . . . . . . . . . . . . . 124 + 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 130 + 19.1. Normative References . . . . . . . . . . . . . . . . . . 130 + 19.2. Informative References . . . . . . . . . . . . . . . . . 130 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 132 + Intellectual Property and Copyright Statements . . . . . . . . . 133 1. Introduction This document describes a layer 3 shim approach and protocol for providing locator agility below the transport protocols, so that multihoming can be provided for IPv6 with failover and load sharing - properties [16], without assuming that a multihomed site will have a + properties [11], without assuming that a multihomed site will have a provider independent IPv6 address which is announced in the global IPv6 routing table. The hosts in a site which has multiple provider allocated IPv6 address prefixes, will use the Shim6 protocol specified in this document to setup state with peer hosts, so that the state can later be used to failover to a different locator pair, should the original one stop working (the term locator is defined in Section 2). The Shim6 protocol is a site multihoming solution in the sense that it allows existing communication to continue when a site that has multiple connections to the internet experiences an outage on a subset of these connections or further upstream. However, Shim6 processing is performed in individual hosts rather than through site- wide mechanisms. We assume that redirection attacks are prevented using Hash Based - Addresses (HBA) as defined in [8]. + Addresses (HBA) as defined in [4]. The reachability and failure detection mechanisms, including how a new working locator pair is discovered after a failure, are specified - in a separate document [9]. This document allocates message types + in a separate document [5]. This document allocates message types and option types for that sub-protocol, and leaves the specification of the message and option formats as well as the protocol behavior to that document. 1.1. Goals The goals for this approach are to: o Preserve established communications in the presence of certain classes of failures, for example, TCP connections and UDP streams. o Have minimal impact on upper layer protocols in general and on transport protocols and applications in particular. - o Address the security threats in [20] through the combination of - the HBA/CGA approach specified in a separate document [8] and + o Address the security threats in [15] through the combination of + the HBA/CGA approach specified in a separate document [4] and techniques described in this document. o Not require extra roundtrip up front to setup shim specific state. Instead allow the upper layer traffic (e.g., TCP) to flow as normal and defer the setup of the shim state until some number of packets have been exchanged. o Take advantage of multiple locators/addresses for load spreading so that different sets of communication to a host (e.g., different connections) might use different locators of the host. Note that @@ -265,40 +267,40 @@ The approach described in this document does not introduce a new identifier name space but instead uses the locator that is selected in the initial contact with the remote peer as the preserved Upper- Layer Identifier (ULID). While there may be subsequent changes in the selected network level locators over time in response to failures in using the original locator, the upper level protocol stack elements will continue to use this upper level identifier without change. This implies that the ULID selection is performed as today's default - address selection as specified in RFC 3484 [13]. Some extensions are + address selection as specified in RFC 3484 [8]. Some extensions are needed to RFC 3484 to try different source addresses, whether or not - the Shim6 protocol is used, as outlined in [14]. Underneath, and + the Shim6 protocol is used, as outlined in [9]. Underneath, and transparently, the multihoming shim selects working locator pairs with the initial locator pair being the ULID pair. If communication subsequently fails the shim can test and select alternate locators. A subsequent section discusses the issues when the selected ULID is not initially working hence there is a need to switch locators up front. Using one of the locators as the ULID has certain benefits for applications which have long-lived session state or performs callbacks or referrals, because both the FQDN and the 128-bit ULID work as handles for the applications. However, using a single 128- bit ULID doesn't provide seamless communication when that locator is - unreachable. See [23] for further discussion of the application + unreachable. See [18] for further discussion of the application implications. There has been some discussion of using non-routable addresses, such - as Unique-Local Addresses (ULAs) [19], as ULIDs in a multihoming + as Unique-Local Addresses (ULAs) [14], as ULIDs in a multihoming solution. While this document doesn't specify all aspects of this, it is believed that the approach can be extended to handle the non- routable address case. For example, the protocol already needs to handle ULIDs that are not initially reachable. Thus the same mechanism can handle ULIDs that are permanently unreachable from outside their site. The issue becomes how to make the protocol perform well when the ULID is known a priori to be not reachable (e.g. the ULID is a ULA), for instance, avoiding any timeout and retries in this case. In addition one would need to understand how the ULAs would be entered in the DNS to avoid a performance impact on @@ -306,28 +308,28 @@ communicate to the (unreachable) ULA. 1.4. IP Multicast IP Multicast requires that the IP source address field contain a topologically correct locator for interface that is used to send the packet, since IP multicast routing uses both the source address and the destination group to determine where to forward the packet. In particular, it need to be able to do the RPF check. (This isn't much different than the situation with widely implemented ingress - filtering [11] for unicast.) + filtering [7] for unicast.) While in theory it would be possible to apply the shim re-mapping of the IP address fields between ULIDs and locators, the fact that all the multicast receivers would need to know the mapping to perform, makes such an approach difficult in practice. Thus it makes sense to have multicast ULPs operate directly on locators and not use the - shim. This is quite a natural fit for protocols which use RTP [15], + shim. This is quite a natural fit for protocols which use RTP [10], since RTP already has an explicit identifier in the form of the SSRC field in the RTP headers. Thus the actual IP address fields are not important to the application. In summary, IP multicast will not need the shim to remap the IP addresses. This doesn't prevent the receiver of multicast to change its locators, since the receiver is not explicitly identified; the destination address is a multicast address and not the unicast @@ -483,36 +485,37 @@ peer performs no destination address selection. Thus in "single prefix multihoming" the site, and in many cases its upstream ISPs, can use BGP to exert some control of the ingress path used to reach the site. This capability can't easily be recreated in "multiple prefix multihoming" such as Shim6. The protocol provides a placeholder, in the form of the Locator Preferences option, which can be used by hosts to express priority and weight values for each locator. This is intentionally made - identical to the DNS SRV [10] specification of priority and weight, - so that DNS SRV records can be used for initial contact and the shim - for failover, and they can use the same way to describe the - preferences. But the Locator Preference option is merely a place - holder when it comes to providing traffic engineering; in order to - use this in a large site there would have to be a mechanism by which - the host can find out what preference values to use, either - statically (e.g., some new DHCPv6 option) or dynamically. + identical to the DNS SRV [6] specification of priority and weight, so + that DNS SRV records can be used for initial contact and the shim for + failover, and they can use the same way to describe the preferences. + But the Locator Preference option is merely a place holder when it + comes to providing traffic engineering; in order to use this in a + large site there would have to be a mechanism by which the host can + find out what preference values to use, either statically (e.g., some + new DHCPv6 option) or dynamically. Thus traffic engineering is listed as a possible extension in Appendix A. 2. Terminology - This document uses the terms MUST, SHOULD, RECOMMENDED, MAY, SHOULD - NOT and MUST NOT defined in RFC 2119 [1]. + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [1]. 2.1. Definitions This document introduces the following terms: upper layer protocol (ULP) A protocol layer immediately above IP. Examples are transport protocols such as TCP and UDP, control protocols such as ICMP, routing protocols such as OSPF, and internet or lower-layer @@ -608,46 +611,46 @@ communication when some ULP decides to start communicating with a peer by sending and receiving ULP packets. Typically this would not invoke any operations in the shim, since the shim can defer the context establishment until some arbitrary later point in time. Hash Based Addresses (HBA) A form of IPv6 address where the interface ID is derived from a cryptographic hash of all the - prefixes assigned to the host. See [8]. + prefixes assigned to the host. See [4]. Cryptographically Generated Addresses (CGA) A form of IPv6 address where the interface ID is derived from a cryptographic hash of the public - key. See [6]. + key. See [2]. CGA Parameter Data Structure (PDS) The information that CGA and HBA exchanges in order to inform the peer of how the interface ID - was computed. See [6]., [8]. + was computed. See [2], [4]. 2.2. Notational Conventions A, B, and C are hosts. X is a potentially malicious host. FQDN(A) is the Fully qualified Domain Name for A. Ls(A) is the locator set for A, which consists of the locators L1(A), L2(A), ... Ln(A). The locator set in not ordered in any particular way other than maybe what is returned by the DNS. ULID(A) is an upper-layer ID for A. In this proposal, ULID(A) is always one member of A's locator set. - CT(X) is a context tag assigned by X. + CT(A) is a context tag assigned by A. This document also makes use of internal conceptual variables to describe protocol behavior and external variables that an implementation must allow system administrators to change. The specific variable names, how their values change, and how their settings influence protocol behavior are provided to demonstrate protocol behavior. An implementation is not required to have them in the exact form described here, so long as its external behavior is consistent with that described in this document. See Section 6 for a description of the conceptual data structures. @@ -682,39 +685,52 @@ In addition, when the site's ISPs perform ingress filtering based on packet source addresses, Shim6 assumes that packets sent with different source and destination combinations have a reasonable chance of making it through the relevant ISP's ingress filters. This can be accomplished in several ways (all outside the scope of this document), such as having the ISPs relax their ingress filters, or selecting the egress such that it matches the IP source address prefix. - Further discussion of this issue is captured in [21]. + Further discussion of this issue is captured in [16]. The Shim6 approach assumes that there are no IPv6-to-IPv6 NATs on the paths, i.e., that the two ends can exchange their own notion of their IPv6 addresses and that those addresses will also make sense to their peer. + The security of the Shim6 protocol relies on the usage of Hash Based + Addresses (HBA) [4] and/or Cryptographically Generated Addresses + (CGA) [2]. In the case that HBAs are used, all the addresses + assigned to the host that are included in the Shim6 protocol (either + as a locator or as a ULID) must be part of the same HBA set. In the + case that CGAs are used, the address used as ULID must be a CGA but + the other addresses that are used as locators do not need to be + neither CGAs nor HBAs. It should be noted that it is perfectly + acceptable to run the Shim6 protocol between a host that has multiple + locators and another host that has a single IP address. In this + case, the address of the host with a single address does not need to + be an HBA nor a CGA. + 4. Protocol Overview The Shim6 protocol operates in several phases over time. The following sequence illustrates the concepts: o An application on host A decides to contact an application on host B using some upper-layer protocol. This results in the ULP on host A sending packets to host B. We call this the initial contact. Assuming the IP addresses selected by Default Address - Selection [13] and its extensions [14] work, then there is no - action by the shim at this point in time. Any shim context - establishment can be deferred until later. + Selection [8] and its extensions [9] work, then there is no action + by the shim at this point in time. Any shim context establishment + can be deferred until later. o Some heuristic on A or B (or both) determine that it is appropriate to pay the Shim6 overhead to make this host-to-host communication robust against locator failures. For instance, this heuristic might be that more than 50 packets have been sent or received, or a timer expiration while active packet exchange is in place. This makes the shim initiate the 4-way context establishment exchange. The purpose of this heuristic is to avoid setting up a shim context when only a small number of packets is exchanged between two hosts. @@ -782,21 +798,21 @@ (crash and reboot) of a peer. The exact mechanism to determine when the context state is no longer used is implementation dependent. For example, an implementation might use the existence of ULP state (where known to the implementation) as an indication that the state is still used, combined with a timer (to handle ULP state that might not be known to the shim sub-layer) to determine when the state is likely to no longer be used. - NOTE: The ULP packets in Shim6 can be carried completely unmodified + NOTE 1: The ULP packets in Shim6 can be carried completely unmodified as long as the ULID pair is used as the locator pair. After a switch to a different locator pair the packets are "tagged" with a Shim6 extension header, so that the receiver can always determine the context to which they belong. This is accomplished by including an 8-octet Shim6 Payload Extension header before the (extension) headers that are processed by the IP endpoint sublayer and ULPs. If subsequently the original ULIDs are selected as the active locator pair then the tagging of packets with the Shim6 extension header is no longer necessary. @@ -867,24 +883,24 @@ application has its own failover mechanism (multiple NS records in the case of DNS) and using the shim could potentially add extra latency with no added benefits. Some other API extensions are discussed in Appendix A 4.4. Securing Shim6 The mechanisms are secured using a combination of techniques: - o The HBA technique [8] for verifying the locators to prevent an + o The HBA technique [4] for verifying the locators to prevent an attacker from redirecting the packet stream to somewhere else. - o Requiring a Reachability Probe+Reply /defined in [9]) before a new + o Requiring a Reachability Probe+Reply /defined in [5]) before a new locator is used as the destination, in order to prevent 3rd party flooding attacks. o The first message does not create any state on the responder. Essentially a 3-way exchange is required before the responder creates any state. This means that a state-based DoS attack (trying to use up all of memory on the responder) at least provides an IPv6 address that the attacker was using. o The context establishment messages use nonces to prevent replay @@ -900,21 +916,21 @@ result is that through this technique, the Shim6 protocol is protected against off-path attackers. 4.5. Overview of Shim Control Messages The Shim6 context establishment is accomplished using four messages; I1, R1, I2, R2. Normally they are sent in that order from initiator and responder, respectively. Should both ends attempt to set up context state at the same time (for the same ULID pair), then their I1 messages might cross in flight, and result in an immediate R2 - message. [The names of these messages are borrowed from HIP [26].] + message. [The names of these messages are borrowed from HIP [19].] R1bis and I2bis messages are defined, which are used to recover a context after it has been lost. A R1bis message is sent when a Shim6 control or Payload extension header arrives and there is no matching context state at the receiver. When such a message is received, it will result in the re-creation of the Shim6 context using the I2bis and R2 messages. The peers' lists of locators are normally exchanged as part of the context establishment exchange. But the set of locators might be @@ -925,34 +941,34 @@ some preferences might have changed. For instance, it might determine that there is a locally visible failure that implies that some locator(s) are no longer usable. This uses a Locator Preferences option in the Update Request message. The mechanism for (un)reachability detection is called Forced Bidirectional Communication (FBD). FBD uses a Keepalive message which is sent when a host has received packets from its peer but has not yet sent any packets from its ULP to the peer. The message type is reserved in this document, but the message format and processing - rules are specified in [9]. + rules are specified in [5]. In addition, when the context is established and there is a subsequent failure there needs to be a way to probe the set of locator pairs to efficiently find a working pair. This document reserves a Probe message type, with the packet format and processing - rules specified in [9]. + rules specified in [5]. The above probe and keepalive messages assume we have an established ULID-pair context. However, communication might fail during the initial contact (that is, when the application or transport protocol is trying to setup some communication). This is handled using the mechanisms in the ULP to try different address pairs as specified in - [13] [14]. In the future versions of the protocol, and with a richer + [8] [9]. In the future versions of the protocol, and with a richer API between the ULP and the shim, the shim might be help optimize discovering a working locator pair during initial contact. This is for further study. 4.6. Extension Header Order Since the shim is placed between the IP endpoint sub-layer and the IP routing sub-layer, the shim header will be placed before any endpoint extension headers (fragmentation headers, destination options header, AH, ESP), but after any routing related headers (hop-by-hop @@ -1076,21 +1092,21 @@ the control messages. The Shim6 headers must be a multiple of 8 octets, hence the minimum size is 8 octets. The common shim control message header is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Next Header | Hdr Ext Len |0| Type |Type-specific|0| + | Next Header | Hdr Ext Len |P| Type |Type-specific|S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Type-specific format | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Next Header: 8-bit selector. Normally set to NO_NXT_HDR (59). @@ -1098,23 +1114,23 @@ 8-octet units, not including the first 8 octets. P: Set to zero. A single bit to distinguish this from the Shim6 payload extension header. Type: 7-bit unsigned integer. Identifies the actual message from the table below. Type codes 0-63 will not trigger R1bis messages on a missing context, while 64- 127 will trigger R1bis. - 0: A single bit (set to zero) which allows Shim6 and HIP - to have a common header format yet telling Shim6 and - HIP messages apart. + S: A single bit set to zero which allows Shim6 and HIP to + have a common header format yet telling Shim6 and HIP + messages apart. Checksum: 16-bit unsigned integer. The checksum is the 16-bit one's complement of the one's complement sum of the entire Shim6 header message starting with the Shim6 next header field, and ending as indicated by the Hdr Ext Len. Thus when there is a payload following the Shim6 header, the payload is NOT included in the Shim6 checksum. Note that unlike protocol like ICMPv6, there is no pseudo-header checksum part of the checksum, in order to provide locator agility without @@ -1195,21 +1211,21 @@ The following options are defined for this message: ULID pair: When the IPv6 source and destination addresses in the IPv6 header does not match the ULID pair, this option MUST be included. An example of this is when recovering from a lost context. Forked Instance Identifier: When another instance of an existent context with the same ULID pair is being created, a - Forked Instance Identifier option is included to + Forked Instance Identifier option MUST be included to distinguish this new instance from the existent one. Future protocol extensions might define additional options for this message. The C-bit in the option format defines how such a new option will be handled by an implementation. See Section 5.15. 5.5. R1 Message Format The R1 message is the second message in the context establishment exchange. The responder sends this in response to an I1 message, @@ -1248,24 +1264,25 @@ Initiator Nonce: 32-bit unsigned integer. Copied from the I1 message. Responder Nonce: 32-bit unsigned integer. A number picked by the responder which the initiator will return in the I2 message. The following options are defined for this message: - Responder Validator: Variable length option. Typically a hash - generated by the responder, which the responder uses - together with the Responder Nonce value to verify that - an I2 message is indeed sent in response to a R1 + Responder Validator: Variable length option. This option MUST be + included in the R1 message. Typically it contains a + hash generated by the responder, which the responder + uses together with the Responder Nonce value to verify + that an I2 message is indeed sent in response to a R1 message, and that the parameters in the I2 message are the same as those in the I1 message. Future protocol extensions might define additional options for this message. The C-bit in the option format defines how such a new option will be handled by an implementation. See Section 5.15. 5.6. I2 Message Format The I2 message is the third message in the context establishment @@ -1317,46 +1334,50 @@ Responder Nonce: 32-bit unsigned integer. Copied from the R1 message. Reserved2: 32-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt. (Needed to make the options start on a multiple of 8 octet boundary.) The following options are defined for this message: - Responder Validator: Variable length option. Just a copy of the - Responder Validator option in the R1 message. + Responder Validator: Variable length option. This option MUST be + included in the I2 message and MUST be generated + copying the Responder Validator option received in the + R1 message. ULID pair: When the IPv6 source and destination addresses in the IPv6 header does not match the ULID pair, this option MUST be included. An example of this is when recovering from a lost context. Forked Instance Identifier: When another instance of an existent context with the same ULID pair is being created, a - Forked Instance Identifier option is included to + Forked Instance Identifier option MUST be included to distinguish this new instance from the existent one. Locator list: Optionally sent when the initiator immediately wants to tell the responder its list of locators. When it is sent, the necessary HBA/CGA information for verifying the locator list MUST also be included. Locator Preferences: Optionally sent when the locators don't all have equal preference. - CGA Parameter Data Structure: Included when the locator list is - included so the receiver can verify the locator list. + CGA Parameter Data Structure: This option MUST be included in the I2 + message when the locator list is included so the + receiver can verify the locator list. - CGA Signature: Included when the some of the locators in the list use - CGA (and not HBA) for verification. + CGA Signature: This option MUST be included in the I2 message when + some of the locators in the list use CGA (and not HBA) + for verification. Future protocol extensions might define additional options for this message. The C-bit in the option format defines how such a new option will be handled by an implementation. See Section 5.15. 5.7. R2 Message Format The R2 message is the fourth message in the context establishment exchange. The responder sends this in response to an I2 message. The R2 message is also used when both hosts send I1 messages at the @@ -1699,32 +1719,32 @@ Request message. No options are currently defined for this message. Future protocol extensions might define additional options for this message. The C-bit in the option format defines how such a new option will be handled by an implementation. See Section 5.15. 5.12. Keepalive Message Format - This message format is defined in [9]. + This message format is defined in [5]. The message is used to ensure that when a peer is sending ULP packets on a context, it always receives some packets in the reverse direction. When the ULP is sending bidirectional traffic, no extra packets need to be inserted. But for a unidirectional ULP traffic pattern, the shim will send back some Keepalive messages when it is receiving ULP packets. 5.13. Probe Message Format - This message and its semantics are defined in [9]. + This message and its semantics are defined in [5]. The goal of this mechanism is to test whether locator pairs work or not in the general case. In particular, this mechanism is to be able to handle the case when one locator pair works in from A to B, and another locator pair works from B to A, but there is no locator pair which works in both directions. The protocol mechanism is that as A is sending probe messages to B, B will observe which locator pairs it has received from and report that back in probe messages it is sending to A. @@ -1796,21 +1816,21 @@ | | option | | | | | 120-127 | Reserved for debugging pruposes | +---------+---------------------------------------------------------+ Table 2 5.15. Option Formats The format of the options is a snapshot of the current HIP option - format [26]. However, there is no intention to track any changes to + format [19]. However, there is no intention to track any changes to the HIP option format, nor is there an intent to use the same name space for the option type values. But using the same format will hopefully make it easier to import HIP capabilities into Shim6 as extensions to Shim6, should this turn out to be useful. All of the TLV parameters have a length (including Type and Length fields) which is a multiple of 8 bytes. When needed, padding MUST be added to the end of the parameter so that the total length becomes a multiple of 8 bytes. This rule ensures proper alignment of data. If padding is added, the Length field MUST NOT include the padding. Any @@ -2003,21 +2023,21 @@ Table 4 5.15.3. Locator Preferences Option Format The Locator Preferences option can have some flags to indicate whether or not a locator is known to work. In addition, the sender can include a notion of preferences. It might make sense to define "preferences" as a combination of priority and weight the same way that DNS SRV records has such information. The priority would provide a way to rank the locators, and within a given priority, the - weight would provide a way to do some load sharing. See [10] for how + weight would provide a way to do some load sharing. See [6] for how SRV defines the interaction of priority and weight. The minimum notion of preferences we need is to be able to indicate that a locator is "dead". We can handle this using a single octet flag for each locator. We can extend that by carrying a larger "element" for each locator. This document presently also defines 2-octet and 3-octet elements, and we can add more information by having even larger elements if need be. @@ -2086,38 +2106,40 @@ This document doesn't specify the format when the Element length is more than three, except that any such formats MUST be defined so that the first three octets are the same as in the above case, that is, a of a 1 octet flags field followed by a 1 octet priority field, and a 1 octet weight field. 5.15.4. CGA Parameter Data Structure Option Format This option contains the CGA Parameter Data Structure (PDS). When HBA is used to verify the locators, the PDS contains the HBA - multiprefix extension. When CGA is used to verify the locators, in - addition to the PDS option, the host also needs to include the - signature in the form of a CGA Signature option. + multiprefix extension in addition to the PDS mandatory fields and + other extensions unrelated to Shim6 that the PDS might have. When + CGA is used to verify the locators, in addition to the PDS option, + the host also needs to include the signature in the form of a CGA + Signature option. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 4 |0| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ CGA Parameter Data Structure ~ ~ +-+-+-+-+-+-+-+-+ ~ | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: CGA Parameter Data Structure: Variable length content. Content - defined in [6] and [8]. + defined in [2] and [4]. Padding: Padding, 0-7 bytes, added if needed. See Section 5.15. 5.15.5. CGA Signature Option Format When CGA is used for verification of one or more of the locators in the Locator List option, then the message in question will need to contain this option. @@ -2200,21 +2222,21 @@ | Forked Instance Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Forked Instance Identifier: 32-bit field containing the identifier of the particular forked instance. 5.15.8. Keepalive Timeout Option Format - This option is defined in [9]. + This option is defined in [5]. 6. Conceptual Model of a Host This section describes a conceptual model of one possible data structure organization that hosts will maintain for the purposes of Shim6. The described organization is provided to facilitate the explanation of how the Shim6 protocol should behave. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with that described in this document. @@ -2239,31 +2261,33 @@ o The generation number for the most recently received, verified peer locator list. o For each peer locator, the verification method to use (from the Locator List option). o For each peer locator, a flag whether it has been verified using HBA or CGA, and a bit whether the locator has been probed to verify that the ULID is present at that location. - o The preferred peer locator - used as destination; Lp(peer) + o The current peer locator, is the locator used as destination + address when sending packets; Lp(peer) o The set of local locators and the preferences; Ls(local) o The generation number for the most recently sent Locator List option. - o The preferred local locator - used as source; Lp(local) - + o The current local locator, is the locator used as source address + when sending packets; Lp(local) o The context tag used to transmit control messages and payload extension headers - allocated by the peer; CT(peer) + o The context to expect in received control messages and payload extension headers - allocated by the local host; CT(local) o Timers for retransmission of the messages during context establishment and update messages. o Depending how an implementation determines whether a context is still in use, there might be a need to track the last time a packet was sent/received using the context. @@ -2260,24 +2284,24 @@ o The context to expect in received control messages and payload extension headers - allocated by the local host; CT(local) o Timers for retransmission of the messages during context establishment and update messages. o Depending how an implementation determines whether a context is still in use, there might be a need to track the last time a packet was sent/received using the context. - o Reachability state for the locator pairs as specified in [9]. + o Reachability state for the locator pairs as specified in [5]. o During pair exploration, information about the probe messages that - have been sent and received as specified in [9]. + have been sent and received as specified in [5]. o During context establishment phase, Init Nonce, Responder Nonce, Responder Validator and timers related to the different packets sent (I1,I2, R2), as described in Section 7 6.2. Context States The states that are used to describe the Shim6 protocol are as follows: @@ -2352,53 +2376,53 @@ It is important that context tags are hard to guess for off-path attackers. Therefore, if an implementation uses structure in the context tag to facilitate efficient lookups, at least 30 bits of the context tag MUST be unstructured and populated by random or pseudo- random bits. In addition, in order to minimize the reuse of context tags, the host SHOULD randomly cycle through the unstrucutred tag name space reserved for randomly assigned context tag values,(e.g. following the - guidelines described in [18]). + guidelines described in [13]). 7.2. Locator Verification The peer's locators might need to be verified during context establishment as well as when handling locator updates in Section 10. There are two separate aspects of locator verification. One is to verify that the locator is tied to the ULID, i.e., that the host which "owns" the ULID is also the one that is claiming the locator "ownership". The Shim6 protocol uses the HBA or CGA techniques for doing this verification. The other is to verify that the host is indeed reachable at the claimed locator. Such verification is needed both to make sure communication can proceed, but also to prevent 3rd - party flooding attacks [20]. These different verifications happen at + party flooding attacks [15]. These different verifications happen at different times, since the first might need to be performed before packets can be received by the peer with the source locator in question, but the latter verification is only needed before packets are sent to the locator. Before a host can use a locator (different than the ULID) as the source locator, it must know that the peer will accept packets with that source locator as being part of this context. Thus the HBA/CGA verification SHOULD be performed by the host before the host acknowledges the new locator, by sending an Update Acknowledgement message, or an R2 message. Before a host can use a locator (different than the ULID) as the destination locator it MUST perform the HBA/CGA verification if this was not performed before upon the reception of the locator set. In addition, it MUST verify that the ULID is indeed present at that locator. This verification is performed by doing a return- - routability test as part of the Probe sub-protocol [9]. + routability test as part of the Probe sub-protocol [5]. If the verification method in the Locator List option is not supported by the host, or if the verification method is not consistent with the CGA Parameter Data Structure (e.g., the Parameter Data Structure doesn't contain the multiprefix extension, and the verification method says to use HBA), then the host MUST ignore the Locator List and the message in which it is contained, and the host SHOULD generate a Shim6 Error Message with Error Code=2, with the Pointer referencing the octet in the Verification method that was found inconsistent. @@ -2807,24 +2831,25 @@ Validator option that was in the R1 message. The I2 message MUST include the ULID pair; normally in the IPv6 source and destination fields. If a ULID-pair option was included in the I1 message then it MUST be included in the I2 message as well. In addition, if the Forked Instance Identifier value for this context is non-zero, the I2 message MUST contain a Forked Instance Identifier Option carrying this value. Besides, the I2 message contains an Initiator Nonce. This is not required to be the same than the one included in the previous I1 message. - The I2 message also includes the Initiator's locator list and the CGA - parameter data structure. If CGA (and not HBA) is used to verify the - locator list, then Initiator also signs the key parts of the message - and includes a CGA signature option containing the signature. + The I2 message may also include the Initiator's locator list. If + this is the the case, then it must also include the CGA Parameter + Data Structure. If CGA (and not HBA) is used to verify one or more + fo the locators included in the locator list, then Initiator must + also include a CGA signature option containing the signature. When the I2 message has been sent, the state is set to I2-SENT. 7.12. Retransmitting I2 messages If the initiator does not receive an R2 message after I2_TIMEOUT time after sending an I2 message it MAY retransmit the I2 message, using binary exponential backoff and randomized timers. The Responder Validator option might have a limited lifetime, that is, the peer might reject Responder Validator options that are older than @@ -2909,27 +2934,28 @@ the peer's locator set at this point in time as specified in Section 7.2. The context state remains unchanged. 7.14. Sending R2 messages Before the host sends the R2 message it MUST look for a possible context confusion i.e. where it would end up with multiple contexts using the same CT(peer) for the same peer host. See Section 7.15. When the host needs to send an R2 message, the host forms the message - using its locators and its context tag, copies the Initiator Nonce - from the triggering message (I2, I2bis, or I1), and includes the - necessary options so that the peer can verify the locators. In - particular, the R2 message includes the Responder's locator list and - the PDS option. If CGA (and not HBA) is used to verify the locator - list, then the Responder also signs the key parts of the message and - includes a CGA Signature option containing the signature. + its context tag, copies the Initiator Nonce from the triggering + message (I2, I2bis, or I1). In addition, it may include alternative + locators and the the necessary options so that the peer can verify + them. In particular, the R2 message may include the Responder's + locator list and the PDS option. If CGA (and not HBA) is used to + verify the locator list, then the Responder also signs the key parts + of the message and includes a CGA Signature option containing the + signature. R2 messages are never retransmitted. If the R2 message is lost, then the initiator will retransmit either the I2/I2bis or I1 message. Either retransmission will cause the responder to find the context state and respond with an R2 message. 7.15. Match for Context Confusion When the host receives an I2, I2bis, or R2 it MUST look for a possible context confusion i.e. where it would end up with multiple @@ -3089,21 +3115,26 @@ it. For that, the host leaves CT(peer) unchanged in the context state, transitions to I2BIS-SENT state, and sends a I2bis message, including the computed Responder Validator option, the Packet Context Tag, and the Responder Nonce received in the R1bis message. This I2bis message is sent using the locator pair included in the R1bis message. In the case that this locator pair differs from the ULID pair defined for this context, then an ULID option MUST be included in the I2bis message. In addition, if the Forked Instance Identifier for this context is non-zero, then a Forked Instance Identifier option carrying the instance identifier - value for this context MUST be included in the I2bis message. + value for this context MUST be included in the I2bis message. The + I2bis message may also include a locator list. If this is the the + case, then it must also include the CGA Parameter Data Structure. + If CGA (and not HBA) is used to verify one or more fo the locators + included in the locator list, then Initiator must also include a + CGA signature option containing the signature. 7.19. Retransmitting I2bis messages If the initiator does not receive an R2 message after I2bis_TIMEOUT time after sending an I2bis message it MAY retransmit the I2bis message, using binary exponential backoff and randomized timers. The Responder Validator option might have a limited lifetime, that is, the peer might reject Responder Validator options that are older than VALIDATOR_MIN_LIFETIME to avoid replay attacks. In the case that the initiator decides not to retransmit I2bis messages or in the case @@ -3319,35 +3351,41 @@ list of locators (only possible when CGA is used to verify the locator(s)), as well as updating the preferences associated with each locator. 10.1. Sending Update Request messages When a host has a change in the locator set, then it can communicate this to the peer by sending an Update Request. When a host has a change in the preferences for its locator set, it can also communicate this to the peer. The Update Request message can include - just a Locator List option, to convey the new set of locators (which - requires a CGA signature option as well), just a Locator Preferences - option, or both a new Locator List and new Locator Preferences. + just a Locator List option, to convey the new set of locators, just a + Locator Preferences option, or both a new Locator List and new + Locator Preferences. Should the host send a new Locator List, the host picks a new random local generation number, records this in the context, and puts it in the Locator List option. Any Locator Preference option, whether send in the same Update Request or in some future Update Request, will use that generation number to make sure the preferences get applied to the correct version of the locator list. The host picks a random Request Nonce for each update, and keeps the same nonce for any retransmissions of the Update Request. The nonce is used to match the acknowledgement with the request. + The UPDATE message can also include a CGA Parameter Data Structure + (this is needed if the CGA PDS was not previously exchanged,). If + CGA (and not HBA) is used to verify one or more fo the locators + included in the locator list, then a CGA signature option containing + the signature must also be included in the UPDATE message. + 10.2. Retransmitting Update Request messages If the host does not receive an Update Acknowledgement R2 message in response to the Update Request message after UPDATE_TIMEOUT time, then it needs to retransmit the Update Request message. The retransmissions should use a retransmission timer with binary exponential backoff to avoid creating congestion issues for the network when lots of hosts perform Update Request retransmissions. Also, the actual timeout value should be randomized between 0.5 and 1.5 of the nominal value to avoid self-synchronization. @@ -3454,22 +3492,23 @@ recorded in the context. Once the Locator List option (if present) has been verified and any new locator list or locator preferences have been recorded, the host sends an Update Acknowledgement message, copying the nonce from the request, and using the CT(peer) in as the Receiver Context Tag. Any new locators, or more likely new locator preferences, might result in the host wanting to select a different locator pair for the context. For instance, if the Locator Preferences lists the current - Lp(peer) as BROKEN. The host uses the Probe message in [9] to verify - that the new locator is reachable before changing Lp(peer). + Lp(peer) as BROKEN. The host uses the reachability exploration + procedure described in [5] to verify that the new locator is + reachable before changing Lp(peer). 10.5. Receiving Update Acknowledgement messages A host MUST silently discard any received Update Acknowledgement messages that do not satisfy all of the following validity checks in addition to those specified in Section 12.3: o The Hdr Ext Len field is at least 1, i.e., the length is at least 16 octets. @@ -3520,21 +3559,21 @@ needs to verify whether context uses the ULIDs as locators, that is, whether Lp(peer) == ULID(peer) and Lp(local) == ULID(local). If this is the case, then packets can be sent unmodified by the shim. If it is not the case, then the logic in Section 11.1 will need to be used. There will also be some maintenance activity relating to (un)reachability detection, whether packets are sent with the original locators or not. The details of this is out of scope for - this document and is specified in [9]. + this document and is specified in [5]. 11.1. Sending ULP Payload after a Switch When sending packets, if there is a ULID-pair context for the ULID pair, and the ULID pair is no longer used as the locator pair, then the sender needs to transform the packet. Apart from replacing the IPv6 source and destination fields with a locator pair, an 8-octet header is added so that the receiver can find the context and inverse the transformation. @@ -3577,21 +3616,21 @@ packet must be passed to the Shim6 payload handling for rewriting. Otherwise, the packet is passed to the Shim6 control handling. 12.1. Receiving payload without extension headers The receiver extracts the IPv6 source and destination fields, and uses this to find a ULID-pair context, such that the IPv6 address fields match the ULID(local) and ULID(peer). If such a context is found, the context appears not to be quiescent and this should be remembered in order to avoid tearing down the context and for - reachability detection porpuses as described in [9]. The host + reachability detection porpuses as described in [5]. The host continues with the normal processing of the IP packet. 12.2. Receiving Payload Extension Headers The receiver extracts the context tag from the payload extension header, and uses this to find a ULID-pair context. If no context is found, the receiver SHOULD generate a R1bis message (see Section 7.17). Then, depending on the state of the context: @@ -3620,22 +3659,22 @@ there is no context. But the need for this depends on what heuristics the implementation has chosen. 12.3. Receiving Shim Control messages A shim control message has the checksum field verified. The Shim header length field is also verified against the length of the IPv6 packet to make sure that the shim message doesn't claim to end past the end of the IPv6 packet. Finally, it checks that the neither the IPv6 destination field nor the IPv6 source field is a multicast - address. If any of those checks fail, the packet is silently - dropped. + address nor the unspecified address. If any of those checks fail, + the packet is silently dropped. The message is then dispatched based on the shim message type. Each message type is then processed as described elsewhere in this document. If the packet contains a shim message type which is unknown to the receiver, then a Shim6 Error Message with Error Code=0 is generated and sent back. The Pointer field is set to point at the first octet of the shim message type. All the control messages can contain any options with C=0. If there is any option in the message with C=1 that isn't known to the host, @@ -3714,21 +3753,21 @@ as described in Section 2. At that point in time there is no activity in the shim. Whether the shim ends up being used or not (e.g., the peer might not support Shim6) it is highly desirable that the initial contact can be established even if there is a failure for one or more IP addresses. The approach taken is to rely on the applications and the transport protocols to retry with different source and destination addresses, consistent with what is already specified in Default Address - Selection [13], and some fixes to that specification [14] to make it + Selection [8], and some fixes to that specification [9] to make it try different source addresses and not only different destination addresses. The implementation of such an approach can potentially result in long timeouts. For instance, a naive implementation at the socket API which uses getaddrinfo() to retrieve all destination addresses and then tries to bind() and connect() to try all source and destination address combinations waiting for TCP to time out for each combination before trying the next one. @@ -3781,24 +3820,24 @@ etc. 15. Implications Elsewhere 15.1. Congestion Control Considerations When the locator pair currently used for exchanging packets in a Shim6 context becomes unreachable, the Shim6 layer will divert the communication through an alternative locator pair, which in most cases will result in redirecting the packet flow through an - alternative network path. In this case, it reccomended that the - Shim6 follows the reccomendation defined in [28] and it informs the + alternative network path. In this case, it recommended that the + Shim6 follows the recommendation defined in [20] and it informs the upper layers about the path change, in order to allow the congestion - control mechanisms of the upper layers can react accordingly. + control mechanisms of the upper layers to react accordingly. 15.2. Middle-boxes considerations Data packets belonging to a Shim6 context carrying the Shim6 Payload Header contain alternative locators other than the ULIDs in the source and destination address fields of the IPv6 header. On the other hand, the upper layers of the peers involved in the communication operate on the ULID pair presented by the Shim6 layer to them, rather on the locator pair contained in the IPv6 header of the actual packets. It should be noted that the Shim6 layer does not @@ -3853,21 +3892,21 @@ using the HBA/CGA verification themselves, which they can do without modifying any of the Shim6 packets they pass through. 15.3. Other considerations The general Shim6 approach, as well as the specifics of this proposed solution, has implications elsewhere, including: o Applications that perform referrals, or callbacks using IP addresses as the 'identifiers' can still function in limited ways, - as described in [23]. But in order for such applications to be + as described in [18]. But in order for such applications to be able to take advantage of the multiple locators for redundancy, the applications need to be modified to either use fully qualified domain names as the 'identifiers', or they need to pass all the locators as the 'identifiers' i.e., the 'identifier' from the applications perspective becomes a set of IP addresses instead of a single IP address. o Signaling protocols for QoS or other things that involve having devices in the network path look at IP addresses and port numbers, or IP addresses and Flow Labels, need to be invoked on the hosts @@ -3889,23 +3928,23 @@ to the path MTU mechanism to try a larger MTU? The fact that the shim will add an 8 octet Payload Extension header to the ULP packets after a locator switch, can also affect the usable path MTU for the ULPs. In this case the MTU change is local to the sending host, thus conveying the change to the ULPs is an implementation matter. 16. Security Considerations - This document satisfies the concerns specified in [20] as follows: + This document satisfies the concerns specified in [15] as follows: - o The HBA [6] and CGA technique [8] for verifying the locators to + o The HBA [2] and CGA technique [4] for verifying the locators to prevent an attacker from redirecting the packet stream to somewhere else. The minimum acceptable key length for public keys used in the generation of CGAs SHOULD be 1024 bits. Any implementation should follow prudent cryptographic practice in determining the appropriate key lengths. o Requiring a Reachability Probe+Reply before a new locator is used as the destination, in order to prevent 3rd party flooding attacks. @@ -3922,28 +3961,28 @@ o Every control message of the Shim6 protocol, past the context establishment, carry the context tag assigned to the particular context. This implies that an attacker needs to discover that context tag before being able to spoof any Shim6 control message. Such discovery probably requires to be along the path in order to be sniff the context tag value. The result is that through this technique, the Shim6 protocol is protected against off-path attackers. - Interaction with IPSec + Interaction with IPsec - The Shim6 sub-layer is implemented below the IPSec layer within the + The Shim6 sub-layer is implemented below the IPsec layer within the IP layer. This deserves some additional considerations for a couple of specific cases: First, it should be noted that the Shim6 approach - does not preclude using IPSEC tunnels on Shim6 packets within the - network transit path. Second, in case that IPSec is implemented as - Bump-In-The-Wire (BITW) [7], either the shim MUST be disabled, or the + does not preclude using IPsec tunnels on Shim6 packets within the + network transit path. Second, in case that IPsec is implemented as + Bump-In-The-Wire (BITW) [3], either the shim MUST be disabled, or the shim MUST also be implemented as Bump-In-The-Wire, in order to satisfy the requirement that IPsec is layered above the shim. Some of the residual threats in this proposal are: o An attacker which arrives late on the path (after the context has been established) can use the R1bis message to cause one peer to recreate the context, and at that point in time the attacker can observe all of the exchange. But this doesn't seem to open any new doors for the attacker since such an attacker can observe the @@ -3998,22 +4037,22 @@ new validator sending a I1 packet than performing all the computations required to determine the secret S. Nevertheless, it is recommended that the host changes the secret S periodically. 17. IANA Considerations IANA is directed to allocate a new IP Protocol Number value for the Shim6 Protocol. IANA is directed to record a CGA message type for the Shim6 Protocol - in the [CGA] namespace registry with the value 0x4A30 5662 4858 574B - 3655 416F 506A 6D48. + in the CGA Extension Type Tags registry with the value 0x4A30 5662 + 4858 574B 3655 416F 506A 6D48. IANA is directed to establish a Shim6 Parameter Registry with three components: Shim6 Type registrations, Shim6 Options registrations Shim6 Error Code registrations. The initial contents of the Shim6 Type registry are as follows: +------------+-----------------------------------------------------+ | Type Value | Message | +------------+-----------------------------------------------------+ @@ -4111,21 +4150,21 @@ brought up as important one to address, but are ones that do not need to be in the base protocol itself but can instead be done as extensions to the protocol. The key ones are: o As stated in the assumptions in Section 3, the in order for the Shim6 protocol to be able to recover from a wide range of failures, for instance when one of the communicating hosts is singly-homed, and cope with a site's ISPs that do ingress filtering based on the source IPv6 address, there is a need for the host to be able to influence the egress selection from its - site. Further discussion of this issue is captured in [21]. + site. Further discussion of this issue is captured in [16]. o Is there need for keeping the list of locators private between the two communicating endpoints? We can potentially accomplish that when using CGA but not with HBA, but it comes at the cost of doing some public key encryption and decryption operations as part of the context establishment. The suggestion is to leave this for a future extension to the protocol. o Defining some form of end-to-end "compression" mechanism that removes the need for including the Shim6 Payload extension header @@ -4182,21 +4221,21 @@ host". But if we don't expect more than a handful locators per host, then we don't need this added complexity. o ULP specified timers for the reachability detection mechanism (which can be useful particularly when there are forked contexts). o Pre-verify some "backup" locator pair, so that the failover time can be shorter. o Study how Shim6 and Mobile IPv6 might interact. There existing an - initial draft on this topic [22]. + initial draft on this topic [17]. Appendix B. Simplified State Machine The states are defined in Section 6.2. The intent is that the stylized description below be consistent with the textual description in the specification, but should they conflict, the textual description is normative. The following table describes the possible actions in state IDLE and their respective triggers: @@ -4693,21 +4732,21 @@ the communication and it also allows nodes to define at which stage of the communication they decide, based on their own policies, that a given communication requires to be protected by the shim. In order to cope with the identified limitations, an alternative approach that does not constraints the flow label values used by communications that are using ULIDs equal to the locators (i.e. no shim translation) is to only require that different flow label values are assigned to different shim contexts. In such approach communications start with unmodified flow label usage (could be zero, - or as suggested in [17]). The packets sent after a failure when a + or as suggested in [12]). The packets sent after a failure when a different locator pair is used would use a completely different flow label, and this flow label could be allocated by the receiver as part of the shim context establishment. Since it is allocated during the context establishment, the receiver of the "failed over" packets can pick a flow label of its choosing (that is unique in the sense that no other context is using it as a context tag), without any performance impact, and respecting that for each locator pair, the flow label value used for a given locator pair doesn't change due to the operation of the multihoming shim. @@ -4870,21 +4909,21 @@ a modified R1 message, so that the time required to perform the context establishment exchange can be reduced. Upon the reception of this modified R1 message, the end that still has the context state can finish the context establishment exchange and restore the lost context. Appendix D.4. Securing locator sets The adoption of a protocol like SHIM that allows the binding of a given ULID with a set of locators opens the doors for different types - of redirection attacks as described in [20]. The goal in terms of + of redirection attacks as described in [15]. The goal in terms of security for the design of the shim protocol is not to introduce any new vulnerability in the Internet architecture. It is a non-goal to provide additional protection than the currently available in the single-homed IPv6 Internet. Multiple security mechanisms were considered to protect the shim protocol. In this appendix we will present some of them. The simplest option to protect the shim protocol was to use cookies i.e. a randomly generated bit string that is negotiated during the @@ -4939,21 +4978,21 @@ is the usage of digital certificates. This implies that an IPsec based solution would require that the generation of digital certificates that bind the key and the ULID by a common third trusted party for both parties involved in the communication. Considering that the scope of application of the shim protocol is global, this would imply a global public key infrastructure. The major issues with this approach are the deployment difficulties associated with a global PKI. Finally two different technologies were selected to protect the shim - protocol: HBA [8] and CGA [6]. These two approaches provide a + protocol: HBA [4] and CGA [2]. These two approaches provide a similar level of protection but they provide different functionality with a different computational cost. The HBA mechanism relies on the capability of generating all the addresses of a multihomed host as an unalterable set of intrinsically bound IPv6 addresses, known as an HBA set. In this approach, addresses incorporate a cryptographic one-way hash of the prefix-set available into the interface identifier part. The result is that the binding between all the available addresses is encoded within the addresses themselves, providing hijacking protection. Any peer using @@ -5067,21 +5106,21 @@ In the unilateral approach, each node discards the information about the other node without coordination with the other node based on some local timers and heuristics. No packet exchange is required for this. In this case, it would be possible that one of the nodes has discarded the state while the other node still hasn't. In this case, a No-Context error message may be required to inform about the situation and possibly a recovery mechanism is also needed. A coordinated approach would use an explicit CLOSE mechanism, akin to - the one specified in HIP [26]. If an explicit CLOSE handshake and + the one specified in HIP [19]. If an explicit CLOSE handshake and associated timer is used, then there would no longer be a need for the No Context Error message due to a peer having garbage collected its end of the context. However, there is still potentially a need to have a No Context Error message in the case of a complete state loss of the peer (also known as a crash followed by a reboot). Only if we assume that the reboot takes at least the CLOSE timer, or that it is ok to not provide complete service until CLOSE timer minutes after the crash, can we completely do away with the No Context Error message. @@ -5127,20 +5166,42 @@ because premature garbage collection, but it does not prevent the same situations due to a crash and reboot of one of the involved hosts. The result is that even if we went for a coordinated approach, we would still need to deal with context confusion and provide the means to detect and recover from this situations. Appendix E. Change Log [RFC Editor: please remove this section] + The following changes have been made since draft-ietf-shim6-proto-08: + + o Clarified that the validator option must be included in R1 and I2 + messages + + o changed preferred peer/local locator to current peer/local locator + to align it with faliure detection draft + + o Reworded sections describing the generation and reception of + I2,I2bis, R2 and Update message to clarify that the CGA PDS may be + included in them + + o ruled out the unspcified address as posible address to be used in + shim6 control messages + + o added clarifyig note that explains that is possible that one of + the peers is not multiaddrssed and does not have CGA/HBA + + o added assumption explaining that ULIDs are HBAs or CGAs + + o Editorial changes + The following changes have been made since draft-ietf-shim6-proto-07: o New Error Message format added in the Format section o Added new registry for Error codes in the IANA considerations section o Changed the Format section so a Shim6 error message is sent back when a crtical option is not recognized (instead of an ICMP error message) @@ -5274,21 +5336,21 @@ o Replaced the Context Error message with the R1bis message. o Removed the Packet In Error option, since it was only used in the Context Error message. o Introduced a I2bis message which is sent in response to an I1bis message, since the responders processing is quite in this case than in the regular R1 case. o Moved the packet formats for the Keepalive and Probe message types - and Event option to [9]. Only the message type values and option + and Event option to [5]. Only the message type values and option type value are specified for those in this document. o Removed the unused message types. o Added a state machine description as an appendix. o Filled in all the TBDs - except the IANA assignment of the protocol number. o Specified how context recovery and forked contexts work together. @@ -5373,113 +5435,85 @@ o Added more background material and textual descriptions. 19. References 19.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) - Specification", RFC 2460, December 1998. - - [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery - for IP Version 6 (IPv6)", RFC 2461, December 1998. - - [4] Thomson, S. and T. Narten, "IPv6 Stateless Address - Autoconfiguration", RFC 2462, December 1998. - - [5] Conta, A. and S. Deering, "Internet Control Message Protocol - (ICMPv6) for the Internet Protocol Version 6 (IPv6) - Specification", RFC 2463, December 1998. - - [6] Aura, T., "Cryptographically Generated Addresses (CGA)", + [2] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. - [7] Kent, S. and K. Seo, "Security Architecture for the Internet + [3] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. - [8] Bagnulo, M., "Hash Based Addresses (HBA)", - draft-ietf-shim6-hba-02 (work in progress), October 2006. + [4] Bagnulo, M., "Hash Based Addresses (HBA)", + draft-ietf-shim6-hba-03 (work in progress), May 2007. - [9] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair + [5] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", - draft-ietf-shim6-failure-detection-07 (work in progress), - December 2006. + draft-ietf-shim6-failure-detection-09 (work in progress), + July 2007. 19.2. Informative References - [10] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for + [6] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. - [11] Ferguson, P. and D. Senie, "Network Ingress Filtering: + [7] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. - [12] Narten, T. and R. Draves, "Privacy Extensions for Stateless - Address Autoconfiguration in IPv6", RFC 3041, January 2001. - - [13] Draves, R., "Default Address Selection for Internet Protocol + [8] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. - [14] Bagnulo, M., "Updating RFC 3484 for multihoming support", + [9] Bagnulo, M., "Updating RFC 3484 for multihoming support", draft-bagnulo-ipv6-rfc3484-update-00 (work in progress), December 2005. - [15] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, + [10] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. - [16] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- + [11] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- Multihoming Architectures", RFC 3582, August 2003. - [17] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 + [12] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004. - [18] Eastlake, D., Schiller, J., and S. Crocker, "Randomness + [13] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. - [19] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast + [14] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. - [20] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming + [15] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming Solutions", RFC 4218, October 2005. - [21] Huitema, C., "Ingress filtering compatibility for IPv6 + [16] Huitema, C., "Ingress filtering compatibility for IPv6 multihomed sites", draft-huitema-shim6-ingress-filtering-00 (work in progress), September 2005. - [22] Bagnulo, M. and E. Nordmark, "SHIM - MIPv6 Interaction", + [17] Bagnulo, M. and E. Nordmark, "SHIM - MIPv6 Interaction", draft-bagnulo-shim6-mip-00 (work in progress), July 2005. - [23] Nordmark, E., "Shim6 Application Referral Issues", + [18] Nordmark, E., "Shim6 Application Referral Issues", draft-ietf-shim6-app-refer-00 (work in progress), July 2005. - [24] Bagnulo, M. and J. Abley, "Applicability Statement for the - Level 3 Multihoming Shim Protocol (Shim6)", - draft-ietf-shim6-applicability-02 (work in progress), - October 2006. - - [25] Huston, G., "Architectural Commentary on Site Multi-homing - using a Level 3 Shim", draft-ietf-shim6-arch-00 (work in - progress), July 2005. - - [26] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-07 - (work in progress), February 2007. - - [27] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", - draft-ietf-mobike-protocol-08 (work in progress), - February 2006. + [19] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, + "Host Identity Protocol", draft-ietf-hip-base-10 (work in + progress), October 2007. - [28] Schuetz, S., "TCP Response to Lower-Layer Connectivity-Change + [20] Schuetz, S., "TCP Response to Lower-Layer Connectivity-Change Indications", draft-schuetz-tcpm-tcp-rlci-01 (work in progress), March 2007. Authors' Addresses Erik Nordmark Sun Microsystems 17 Network Circle Menlo Park, CA 94025 USA