SHIM6 WG E. Nordmark Internet-Draft Sun Microsystems Expires: August 17, 2008 M. Bagnulo UC3M February 14, 2008 Shim6: Level 3 Multihoming Shim Protocol for IPv6 draft-ietf-shim6-proto-10.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 other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months 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 August 17, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Nordmark & Bagnulo Expires August 17, 2008 [Page 1] Internet-Draft Shim6 Protocol February 2008 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 properties, without assuming that a multihomed site will have a provider independent IPv6 address prefix 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 13 2.2. Notational Conventions . . . . . . . . . . . . . . . . . 16 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 17 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 19 4.1. Context Tags . . . . . . . . . . . . . . . . . . . . . . 21 4.2. Context Forking . . . . . . . . . . . . . . . . . . . . . 21 4.3. API Extensions . . . . . . . . . . . . . . . . . . . . . 22 4.4. Securing Shim6 . . . . . . . . . . . . . . . . . . . . . 22 4.5. Overview of Shim Control Messages . . . . . . . . . . . . 23 4.6. Extension Header Order . . . . . . . . . . . . . . . . . 24 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 26 5.1. Common Shim6 Message Format . . . . . . . . . . . . . . . 26 5.2. Payload Extension Header Format . . . . . . . . . . . . . 27 5.3. Common Shim6 Control header . . . . . . . . . . . . . . . 27 5.4. I1 Message Format . . . . . . . . . . . . . . . . . . . . 29 5.5. R1 Message Format . . . . . . . . . . . . . . . . . . . . 30 5.6. I2 Message Format . . . . . . . . . . . . . . . . . . . . 32 5.7. R2 Message Format . . . . . . . . . . . . . . . . . . . . 34 5.8. R1bis Message Format . . . . . . . . . . . . . . . . . . 35 5.9. I2bis Message Format . . . . . . . . . . . . . . . . . . 37 5.10. Update Request Message Format . . . . . . . . . . . . . . 39 5.11. Update Acknowledgement Message Format . . . . . . . . . . 40 5.12. Keepalive Message Format . . . . . . . . . . . . . . . . 41 Nordmark & Bagnulo Expires August 17, 2008 [Page 2] Internet-Draft Shim6 Protocol February 2008 5.13. Probe Message Format . . . . . . . . . . . . . . . . . . 42 5.14. Error Message Format . . . . . . . . . . . . . . . . . . 42 5.15. Option Formats . . . . . . . . . . . . . . . . . . . . . 43 5.15.1. Responder Validator Option Format . . . . . . . . . 46 5.15.2. Locator List Option Format . . . . . . . . . . . . . 46 5.15.3. Locator Preferences Option Format . . . . . . . . . 48 5.15.4. CGA Parameter Data Structure Option Format . . . . . 50 5.15.5. CGA Signature Option Format . . . . . . . . . . . . 50 5.15.6. ULID Pair Option Format . . . . . . . . . . . . . . 51 5.15.7. Forked Instance Identifier Option Format . . . . . . 52 5.15.8. Keepalive Timeout Option Format . . . . . . . . . . 52 6. Conceptual Model of a Host . . . . . . . . . . . . . . . . . 53 6.1. Conceptual Data Structures . . . . . . . . . . . . . . . 53 6.2. Context STATES . . . . . . . . . . . . . . . . . . . . . 55 7. Establishing ULID-Pair Contexts . . . . . . . . . . . . . . . 57 7.1. Uniqueness of Context Tags . . . . . . . . . . . . . . . 57 7.2. Locator Verification . . . . . . . . . . . . . . . . . . 57 7.3. Normal context establishment . . . . . . . . . . . . . . 58 7.4. Concurrent context establishment . . . . . . . . . . . . 58 7.5. Context recovery . . . . . . . . . . . . . . . . . . . . 60 7.6. Context confusion . . . . . . . . . . . . . . . . . . . . 62 7.7. Sending I1 messages . . . . . . . . . . . . . . . . . . . 63 7.8. Retransmitting I1 messages . . . . . . . . . . . . . . . 64 7.9. Receiving I1 messages . . . . . . . . . . . . . . . . . . 64 7.10. Sending R1 messages . . . . . . . . . . . . . . . . . . . 65 7.10.1. Generating the R1 Validator . . . . . . . . . . . . 66 7.11. Receiving R1 messages and sending I2 messages . . . . . . 66 7.12. Retransmitting I2 messages . . . . . . . . . . . . . . . 67 7.13. Receiving I2 messages . . . . . . . . . . . . . . . . . . 68 7.14. Sending R2 messages . . . . . . . . . . . . . . . . . . . 69 7.15. Match for Context Confusion . . . . . . . . . . . . . . . 70 7.16. Receiving R2 messages . . . . . . . . . . . . . . . . . . 70 7.17. Sending R1bis messages . . . . . . . . . . . . . . . . . 71 7.17.1. Generating the R1bis Validator . . . . . . . . . . . 72 7.18. Receiving R1bis messages and sending I2bis messages . . . 72 7.19. Retransmitting I2bis messages . . . . . . . . . . . . . . 73 7.20. Receiving I2bis messages and sending R2 messages . . . . 74 8. Handling ICMP Error Messages . . . . . . . . . . . . . . . . 76 9. Teardown of the ULID-Pair Context . . . . . . . . . . . . . . 79 10. Updating the Peer . . . . . . . . . . . . . . . . . . . . . . 80 10.1. Sending Update Request messages . . . . . . . . . . . . . 80 10.2. Retransmitting Update Request messages . . . . . . . . . 80 10.3. Newer Information While Retransmitting . . . . . . . . . 81 10.4. Receiving Update Request messages . . . . . . . . . . . . 81 10.5. Receiving Update Acknowledgement messages . . . . . . . . 83 11. Sending ULP Payloads . . . . . . . . . . . . . . . . . . . . 85 11.1. Sending ULP Payload after a Switch . . . . . . . . . . . 85 12. Receiving Packets . . . . . . . . . . . . . . . . . . . . . . 87 Nordmark & Bagnulo Expires August 17, 2008 [Page 3] Internet-Draft Shim6 Protocol February 2008 12.1. Receiving payload without extension headers . . . . . . . 87 12.2. Receiving Payload Extension Headers . . . . . . . . . . . 87 12.3. Receiving Shim Control messages . . . . . . . . . . . . . 88 12.4. Context Lookup . . . . . . . . . . . . . . . . . . . . . 88 13. Initial Contact . . . . . . . . . . . . . . . . . . . . . . . 91 14. Protocol constants . . . . . . . . . . . . . . . . . . . . . 92 15. Implications Elsewhere . . . . . . . . . . . . . . . . . . . 93 15.1. Congestion Control Considerations . . . . . . . . . . . . 93 15.2. Middle-boxes considerations . . . . . . . . . . . . . . . 93 15.3. Operation and Management Considerations . . . . . . . . . 94 15.4. Other considerations . . . . . . . . . . . . . . . . . . 95 16. Security Considerations . . . . . . . . . . . . . . . . . . . 97 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 101 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 103 Appendix A. Possible Protocol Extensions . . . . . . . . . . 104 Appendix B. Simplified STATE Machine . . . . . . . . . . . . 106 Appendix B.1. Simplified STATE Machine diagram . . . . . . . . 111 Appendix C. Context Tag Reuse . . . . . . . . . . . . . . . . 113 Appendix C.1. Context Recovery . . . . . . . . . . . . . . . . 113 Appendix C.2. Context Confusion . . . . . . . . . . . . . . . . 113 Appendix C.3. Three Party Context Confusion . . . . . . . . . . 114 Appendix D. Design Alternatives . . . . . . . . . . . . . . . 115 Appendix D.1. Context granularity . . . . . . . . . . . . . . . 115 Appendix D.2. Demultiplexing of data packets in Shim6 communications . . . . . . . . . . . . . . . . . 115 Appendix D.2.1. Flow-label . . . . . . . . . . . . . . . . . . . 116 Appendix D.2.2. Extension Header . . . . . . . . . . . . . . . . 118 Appendix D.3. Context Loss Detection . . . . . . . . . . . . . 119 Appendix D.4. Securing locator sets . . . . . . . . . . . . . . 121 Appendix D.5. ULID-pair context establishment exchange . . . . 124 Appendix D.6. Updating locator sets . . . . . . . . . . . . . . 125 Appendix D.7. State Cleanup . . . . . . . . . . . . . . . . . . 125 Appendix E. Change Log . . . . . . . . . . . . . . . . . . . 128 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 135 19.1. Normative References . . . . . . . . . . . . . . . . . . 135 19.2. Informative References . . . . . . . . . . . . . . . . . 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 137 Intellectual Property and Copyright Statements . . . . . . . . . 138 Nordmark & Bagnulo Expires August 17, 2008 [Page 4] Internet-Draft Shim6 Protocol February 2008 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 [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 [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 [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 [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 Nordmark & Bagnulo Expires August 17, 2008 [Page 5] Internet-Draft Shim6 Protocol February 2008 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 this might cause load to be spread unevenly, thus we use the term "load spreading" instead of "load balancing". This capability might enable some forms of traffic engineering, but the details for traffic engineering, including what requirements can be satisfied, are not specified in this document, and form part of a potential extensions to this protocol. 1.2. Non-Goals The assumption is that the problem we are trying to solve is site multihoming, with the ability to have the set of site prefixes change over time due to site renumbering. Further, we assume that such changes to the set of locator prefixes can be relatively slow and managed; slow enough to allow updates to the DNS to propagate (since the protocol defined in this document depends on the DNS to find the appropriate locator sets). Note, however that it is an explicit non- goal to make communication survive a renumbering event (which causes all the locators of a host to change to a new set of locators). This proposal does not attempt to solve the related problem of host mobility. However, it might turn out that the Shim6 protocol can be a useful component for future host mobility solutions, e.g., for route optimization. Finally, this proposal also does not try to provide a new network level or transport level identifier name space distinct from the current IP address name space. Even though such a concept would be useful to Upper Layer Protocols (ULPs) and applications, especially if the management burden for such a name space was negligible and there was an efficient yet secure mechanism to map from identifiers to locators, such a name space isn't necessary (and furthermore doesn't seem to help) to solve the multihoming problem. The Shim6 proposal doesn't fully separate the identifier and locator functions that have traditionally been overloaded in the IP address. However, throughout this document the term "identifier", or more specifically, Upper Layer Identifier (ULID) refers to the identifying function of an IPv6 address, and "locator" to the network layer routing and forwarding properties of an IPv6 address. 1.3. Locators as Upper-layer IDentifiers (ULID) The approach described in this document does not introduce a new identifier name space but instead uses the locator that is selected Nordmark & Bagnulo Expires August 17, 2008 [Page 6] Internet-Draft Shim6 Protocol February 2008 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 [8]. Some extensions are needed to RFC 3484 to try different source addresses, whether or not 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 [18] for further discussion of the application implications. There has been some discussion of using non-routable addresses, such 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 existing, non-Shim6 aware, IPv6 hosts potentially trying to 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 Nordmark & Bagnulo Expires August 17, 2008 [Page 7] Internet-Draft Shim6 Protocol February 2008 different than the situation with widely implemented ingress 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 [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 locator of the receiver. 1.5. Renumbering Implications As stated above, this approach does not try to make communication survive renumbering in the general case. When a host is renumbered, the effect is that one or more locators become invalid, and zero or more locators are added to the host's network interface. This means that the set of locators that is used in the shim will change, which the shim can handle as long as not all the original locators become invalid at the same time and depending on the time that is required to update the DNS and for those updates to propagate. But IP addresses are also used as ULIDs, and making the communication survive locators becoming invalid can potentially cause some confusion at the upper layers. The fact that a ULID might be used with a different locator over time open up the possibility that communication between two ULIDs might continue to work after one or both of those ULIDs are no longer reachable as locators, for example due to a renumbering event. This opens up the possibility that the ULID (or at least the prefix on which it is based) is reassigned to another site while it is still being used (with another locator) for existing communication. In the worst case we could end up with two separate hosts using the same ULID while both of them are communicating with the same host. Nordmark & Bagnulo Expires August 17, 2008 [Page 8] Internet-Draft Shim6 Protocol February 2008 This potential source for confusion is avoided requiring that any communication using a ULID MUST be terminated when the ULID becomes invalid (due to the underlying prefix becoming invalid). This behavior can be accomplished by explicitly discarding the shim state when the ULID becomes invalid. The context recovery mechanism will then make the peer aware that the context is gone, and that the ULID is no longer present at the same locator(s). 1.6. Placement of the shim ----------------------- | Transport Protocols | ----------------------- ------ ------- -------------- ------------- IP endpoint | AH | | ESP | | Frag/reass | | Dest opts | sub-layer ------ ------- -------------- ------------- --------------------- | Shim6 shim layer | --------------------- ------ IP routing | IP | sub-layer ------ Figure 1: Protocol stack The proposal uses a multihoming shim layer within the IP layer, i.e., below the ULPs, as shown in Figure 1, in order to provide ULP independence. The multihoming shim layer behaves as if it is associated with an extension header, which would be placed after any routing-related headers in the packet (such as any hop-by-hop options, or routing header). However, when the locator pair is the ULID pair there is no data that needs to be carried in an extension header, thus none is needed in that case. Layering AH and ESP above the multihoming shim means that for a native implementation of IPsec, IPsec can be made to be unaware of locator changes the same way that transport protocols can be unaware. A "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation is layered in the same place as the application of IPsec in security gateways. In that case there might be separate security associations for different locators. Layering the fragmentation header above the multihoming shim makes reassembly robust in the case that there is broken multi-path routing Nordmark & Bagnulo Expires August 17, 2008 [Page 9] Internet-Draft Shim6 Protocol February 2008 which results in using different paths, hence potentially different source locators, for different fragments. Thus, effectively the multihoming shim layer is placed between the IP endpoint sublayer, which handles fragmentation, reassembly, and IPsec, and the IP routing sublayer, which selects which next hop and interface to use for sending out packets. Applications and upper layer protocols use ULIDs which the Shim6 layer map to/from different locators. The Shim6 layer maintains state, called ULID-pair context, per ULID pair (that is, applies to all ULP connections between the ULID pair) in order to perform this mapping. The mapping is performed consistently at the sender and the receiver so that ULPs see packets that appear to be sent using ULIDs from end to end. This property is maintained even though the packets travel through the network containing locators in the IP address fields, and even though those locators may be changed by the transmitting Shim6 layer. The context state is maintained per remote ULID i.e. approximately per peer host, and not at any finer granularity. In particular, it is independent of the ULPs and any ULP connections. However, the forking capability enables shim-aware ULPs to use more than one locator pair at a time for an single ULID pair. ---------------------------- ---------------------------- | Sender A | | Receiver B | | | | | | ULP | | ULP | | | src ULID(A)=L1(A) | | ^ | | | dst ULID(B)=L1(B) | | | src ULID(A)=L1(A) | | v | | | dst ULID(B)=L1(B) | | multihoming shim | | multihoming shim | | | src L2(A) | | ^ | | | dst L3(B) | | | src L2(A) | | v | | | dst L3(B) | | IP | | IP | ---------------------------- ---------------------------- | ^ ------- cloud with some routers ------- Figure 2: Mapping with changed locators The result of this consistent mapping is that there is no impact on the ULPs. In particular, there is no impact on pseudo-header checksums and connection identification. Conceptually, one could view this approach as if both ULIDs and locators are being present in every packet, and with a header Nordmark & Bagnulo Expires August 17, 2008 [Page 10] Internet-Draft Shim6 Protocol February 2008 compression mechanism applied that removes the need for the ULIDs to be carried in the packets once the compression state has been established. In order for the receiver to recreate a packet with the correct ULIDs there is a need to include some "compression tag" in the data packets. This serves to indicate the correct context to use for decompression when the locator pair in the packet is insufficient to uniquely identify the context. There are different types of interactions between the Shim6 layer and other protocols. Those intereactions are influenced by the usage of the addresses that these other protocols do and the impact of the Shim6 mapping on these usages. A detailed analysis of the interactions of different portocols, including SCTP, MIP and HIP can be found in [19]. Moreover, some applications may need to have a richer interaction with the Shim6 sub-layer. In order to enable that, a API [23] has been defined to enable greater control and information exchange for those applications that need it. 1.7. Traffic Engineering At the time of this writing it is not clear what requirements for traffic engineering make sense for the Shim6 protocol, since the requirements must both result in some useful behavior as well as be implementable using a host-to-host locator agility mechanism like Shim6. Inherent in a scalable multihoming mechanism that separates the locator function of the IP address from identifying function of the IP address is that each host ends up with multiple locators. This means that at least for initial contact, it is the remote peer application (or layer working on its behalf) needs to select an initial ULID, which automatically becomes the initial locator. In the case of Shim6 this is performed by applying RFC 3484 address selection. This is quite different than the common case of IPv4 multihoming where the site has a single IP address prefix, since in that case the 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 does not by itself exist "multiple prefix multihoming" such as Shim6. It is conceivable that extensions allowing site or provider guidance of host-based mechanisms could be developed. But t should be noted that traffic engineering via BGP, MPLS or other similar techniques can still be applied for traffic on each individual prefix; Shim6 does not remove the capability for this. It does provide some additional Nordmark & Bagnulo Expires August 17, 2008 [Page 11] Internet-Draft Shim6 Protocol February 2008 capabilities for hosts to choose between prefixes. These capabilities also carry some risk for non-optimal behaviour when more than one mechanism attempts to correct problems at the same time. However, it should be noted that this is not necessarily a situation brought about by Shim6. A more constrained form of this capability already exists in IPv6 itself via its support of multiple prefixes and address selection rules for starting new communications. Even IPv4 hosts with multiple interfaces may have limited capabilities to choose interfaces on which they communicate. Similarly, upper layers may choose different addresses. In general, it is expected that Shim6 is applicable in relatively small sites and individual hosts where BGP-style traffic engineering operations are unavailable, unlikely or, if run with provider independent addressing, might even be harmful considering the growth rates in the global routing table. 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 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. Nordmark & Bagnulo Expires August 17, 2008 [Page 12] Internet-Draft Shim6 Protocol February 2008 2. Terminology 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 protocols being "tunneled" over (i.e., encapsulated in) IP such as IPX, AppleTalk, or IP itself. interface A node's attachment to a link. address An IP layer name that contains both topological significance and acts as a unique identifier for an interface. 128 bits. This document only uses the "address" term in the case where it isn't specific whether it is a locator or an identifier. locator An IP layer topological name for an interface or a set of interfaces. 128 bits. The locators are carried in the IP address fields as the packets traverse the network. identifier An IP layer name for an IP layer endpoint. The transport endpoint name is a function of the transport protocol and would typically include the IP identifier plus a port number. NOTE: This proposal does not specify any new form of IP layer identifier, but still separates the identifying and locating properties of the IP addresses. Nordmark & Bagnulo Expires August 17, 2008 [Page 13] Internet-Draft Shim6 Protocol February 2008 upper-layer identifier (ULID) An IP address which has been selected for communication with a peer to be used by the upper layer protocol. 128 bits. This is used for pseudo-header checksum computation and connection identification in the ULP. Different sets of communication to a host (e.g., different connections) might use different ULIDs in order to enable load spreading. Since the ULID is just one of the IP locators/ addresses of the node, there is no need for a separate name space and allocation mechanisms. address field The source and destination address fields in the IPv6 header. As IPv6 is currently specified this fields carry "addresses". If identifiers and locators are separated these fields will contain locators for packets on the wire. FQDN Fully Qualified Domain Name ULID-pair context The state that the multihoming shim maintains between a pair of Upper-layer identifiers. The context is identified by a context tag for each direction of the communication, and also identified by the pair of ULID and a Forked Instance Identifier (see below). Context tag Each end of the context allocates a context tag for the context. This is used to uniquely associate both received control packets and payload extension headers as belonging to the context. Current locator pair Each end of the context has a current locator pair which is used to send packets to the peer. The two ends might use different current locator pairs though. Nordmark & Bagnulo Expires August 17, 2008 [Page 14] Internet-Draft Shim6 Protocol February 2008 Default context At the sending end, the shim uses the ULID pair (passed down from the ULP) to find the context for that pair. Thus, normally, a host can have at most one context for a ULID pair. We call this the "default context". Context forking A mechanism which allows ULPs that are aware of multiple locators to use separate contexts for the same ULID pair, in order to be able use different locator pairs for different communication to the same ULID. Context forking causes more than just the default context to be created for a ULID pair. Forked Instance Identifier (FII) In order to handle context forking, a context is identified by a ULID-pair and a forked context identifier. The default context has a FII of zero. Initial contact We use this term to refer to the pre-shim 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 [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 [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 [2], [4]. Nordmark & Bagnulo Expires August 17, 2008 [Page 15] Internet-Draft Shim6 Protocol February 2008 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(A) is a context tag assigned by A. STATE (in uppercase) refers to the the specific state of the state machine described in Section 6.2 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. Nordmark & Bagnulo Expires August 17, 2008 [Page 16] Internet-Draft Shim6 Protocol February 2008 3. Assumptions The design intent is to ensure that the Shim6 protocol is capable of handling path failures independently of the number of IP addresses (locators) available to the two communicating hosts, and independently of which host detects the failure condition. Consider, for example, the case in which both A and B have active Shim6 state and where A has only one locator while B has multiple locators. In this case, it might be that B is trying to send a packet to A, and has detected a failure condition with the current locator pair. Since B has multiple locators it presumably has multiple ISPs, and consequently likely has alternate egress paths toward A. B cannot vary the destination address (i.e., A's locator), since A has only one locator. However, B may need to vary the source address in order to ensure packet delivery. In many cases normal operation of IP routing may cause the packets to follow a path towards the correct (currently operational) egress. In some cases it is possible that a path may be selected based on the source address, implying that B will need to select a source address corresponding to the currently operating egress. The details of how routing can be accomplished is beyond the scope of this document Also, 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. In the case that one egress path has failed but another is operating correctly, it may be necessary for the packet's source (node B in the previous paragraph) to select a source address that corresponds to the operational egress, in order to pass the ISP's ingress filters. 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 Nordmark & Bagnulo Expires August 17, 2008 [Page 17] Internet-Draft Shim6 Protocol February 2008 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. Nordmark & Bagnulo Expires August 17, 2008 [Page 18] Internet-Draft Shim6 Protocol February 2008 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 [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. As a result of this exchange, both A and B will know a list of locators for each other. If the context establishment exchange fails, the initiator will then know that the other end does not support Shim6, and will continue with standard (non-Shim6) behavior for the session. o Communication continues without any change for the ULP packets. In particular, there are no shim extension headers added to the ULP packets, since the ULID pair is the same as the locator pair. In addition, there might be some messages exchanged between the shim sub-layers for (un)reachability detection. o At some point in time something fails. Depending on the approach to reachability detection, there might be some advice from the ULP, or the shim (un)reachability detection might discover that there is a problem. At this point in time one or both ends of the communication need to probe the different alternate locator pairs until a working pair is found, and switch to using that locator pair. Nordmark & Bagnulo Expires August 17, 2008 [Page 19] Internet-Draft Shim6 Protocol February 2008 o Once a working alternative locator pair has been found, the shim will rewrite the packets on transmit, and tag the packets with Shim6 Payload extension header, which contains the receiver's context tag. The receiver will use the context tag to find the context state which will indicate which addresses to place in the IPv6 header before passing the packet up to the ULP. The result is that from the perspective of the ULP the packet passes unmodified end-to-end, even though the IP routing infrastructure sends the packet to a different locator. o The shim (un)reachability detection will monitor the new locator pair as it monitored the original locator pair, so that subsequent failures can be detected. o In addition to failures detected based on end-to-end observations, one endpoint might know for certain that one or more of its locators is not working. For instance, the network interface might have failed or gone down (at layer 2), or an IPv6 address might have become deprecated or invalid. In such cases the host can signal its peer that this address is no longer recommended to try. This triggers something similar to a failure handling and a new working locator pair must be found. The protocol also has the ability to express other forms of locator preferences. A change in any preferences can be signaled to the peer, which will have made the peer record the new preferences. A change in the preferences might optionally make the peer want to use a different locator pair. In this case, the peer follows the same locator switching procedure as after a failure (by verifying that its peer is indeed present at the alternate locator, etc). o When the shim thinks that the context state is no longer used, it can garbage collect the state; there is no coordination necessary with the peer host before the state is removed. There is a recovery message defined to be able to signal when there is no context state, which can be used to detect and recover from both premature garbage collection, as well as complete state loss (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 Nordmark & Bagnulo Expires August 17, 2008 [Page 20] Internet-Draft Shim6 Protocol February 2008 known to the shim sub-layer) to determine when the state is likely to no longer be used. 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. 4.1. Context Tags A context between two hosts is actually a context between two ULIDs. The context is identified by a pair of context tags. Each end gets to allocate a context tag, and once the context is established, most Shim6 control messages contain the context tag that the receiver of the message allocated. Thus at a minimum the combination of have to uniquely identify one context. But since the Payload extension headers are demultiplexed without looking at the locators in the packet, the receiver will need to allocate context tags that are unique for all its contexts. The context tag is a 47-bit number (the largest which can fit in an 8-octet extension header), while preserving one bit to differentiate the Shim6 signalling messages from the Shim6 header included in data packets, allowing both to use the same protocol number. The mechanism for detecting a loss of context state at the peer assumes that the receiver can tell the packets that need locator rewriting, even after it has lost all state (e.g., due to a crash followed by a reboot). This is achieved because after a rehoming event the packets that need receive-side rewriting, carry the Payload extension header. 4.2. Context Forking It has been asserted that it will be important for future ULPs, in particular, future transport protocols, to be able to control which locator pairs are used for different communication. For instance, host A and host B might communicate using both VoIP traffic and ftp traffic, and those communications might benefit from using different locator pairs. However, the basic Shim6 mechanism uses a single current locator pair for each context, thus a single context cannot accomplish this. Nordmark & Bagnulo Expires August 17, 2008 [Page 21] Internet-Draft Shim6 Protocol February 2008 For this reason, the Shim6 protocol supports the notion of context forking. This is a mechanism by which a ULP can specify (using some API not yet defined) that a context for e.g., the ULID pair should be forked into two contexts. In this case the forked-off context will be assigned a non-zero Forked Instance Identifier, while the default context has FII zero. The Forked Instance Identifier (FII) is a 32-bit identifier which has no semantics in the protocol other then being part of the tuple which identifies the context. For example, a host might allocate FIIs as sequential numbers for any given ULID pair. No other special considerations are needed in the Shim6 protocol to handle forked contexts. Note that forking as specified does NOT allow A to be able to tell B that certain traffic (a 5-tuple?) should be forked for the reverse direction. The Shim6 forking mechanism as specified applies only to the sending of ULP packets. If some ULP wants to fork for both directions, it is up to the ULP to set this up, and then instruct the shim at each end to transmit using the forked context. 4.3. API Extensions Several API extensions have been discussed for Shim6, but their actual specification is out of scope for this document. The simplest one would be to add a socket option to be able to have traffic bypass the shim (not create any state, and not use any state created by other traffic). This could be an IPV6_DONTSHIM socket option. Such an option would be useful for protocols, such as DNS, where the 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. The actual API extensions are defined in [23]. 4.4. Securing Shim6 The mechanisms are secured using a combination of techniques: 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 [5]) before a new locator is used as the destination, in order to prevent 3rd party flooding attacks. Nordmark & Bagnulo Expires August 17, 2008 [Page 22] Internet-Draft Shim6 Protocol February 2008 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 attacks, and to prevent off-path attackers from interfering with the establishment. 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 any potential attacker 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. 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 [20].] 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 dynamic. For this reason there are Update Request and Update Acknowledgement messages, and a Locator List option. Even when the list of locators is fixed, a host might determine that 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 Nordmark & Bagnulo Expires August 17, 2008 [Page 23] Internet-Draft Shim6 Protocol February 2008 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 [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 [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 [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 extensions header, routing header, a destinations options header which precedes a routing header). When tunneling is used, whether IP-in-IP tunneling or the special form of tunneling that Mobile IPv6 uses (with Home Address Options and Routing header type 2), there is a choice whether the shim applies inside the tunnel or outside the tunnel, which affects the location of the Shim6 header. In most cases IP-in-IP tunnels are used as a routing technique, thus it makes sense to apply them on the locators which means that the sender would insert the Shim6 header after any IP-in-IP encapsulation; this is what occurs naturally when routers apply IP- in-IP encapsulation. Thus the packets would have: o Outer IP header o Inner IP header o Shim6 extension header (if needed) o ULP Nordmark & Bagnulo Expires August 17, 2008 [Page 24] Internet-Draft Shim6 Protocol February 2008 But the shim can also be used to create "shimmed tunnels" i.e., where an IP-in-IP tunnel uses the shim to be able to switch the tunnel endpoint addresses between different locators. In such a case the packets would have: o Outer IP header o Shim6 extension header (if needed) o Inner IP header o ULP In any case, the receiver behavior is well-defined; a receiver processes the extension headers in order. However, the precise interaction between Mobile IPv6 and Shim6 is for further study, but it might make sense to have Mobile IPv6 operate on locators as well, meaning that the shim would be layered on top of the MIPv6 mechanism. Nordmark & Bagnulo Expires August 17, 2008 [Page 25] Internet-Draft Shim6 Protocol February 2008 5. Message Formats The Shim6 messages are all carried using a new IP protocol number [to be assigned by IANA]. The Shim6 messages have a common header, defined below, with some fixed fields, followed by type specific fields. The Shim6 messages are structured as an IPv6 extension header since the Payload extension header is used to carry the ULP packets after a locator switch. The Shim6 control messages use the same extension header formats so that a single "protocol number" needs to be allowed through firewalls in order for Shim6 to function across the firewall. 5.1. Common Shim6 Message Format The first 17 bits of the Shim6 header is common for the Payload extension header and the control messages and looks as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len |P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Next Header: The payload which follows this header. Hdr Ext Len: 8-bit unsigned integer. Length of the Shim6 header in 8-octet units, not including the first 8 octets. P: A single bit to distinguish Payload extension headers from control messages. Shim6 signalling packets may not be larger than 1280 bytes, including the IPv6 header and any intermediate headers between the IPv6 header and the Shim6 header. One way to meet this requirement is to omit part of the locator address information if with this information included, the packet would become larger than 1280 bytes. Another option is to perform option engineering, dividing into different Shim6 messages the information to be transmitted. An implementation may impose administrative restrictions to avoid excessively large Shim6 packets, such as a limitation on the number of locators to be used. Nordmark & Bagnulo Expires August 17, 2008 [Page 26] Internet-Draft Shim6 Protocol February 2008 5.2. Payload Extension Header Format The payload extension headers is used to carry ULP packets where the receiver must replace the content of the source and/or destination fields in the IPv6 header before passing the packet to the ULP. Thus this extension header is required when the locators pair that is used is not the same as the ULID pair. 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 | 0 |1| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Receiver Context Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Next Header: The payload which follows this header. Hdr Ext Len: 0 (since the header is 8 octets). P: Set to one. A single bit to distinguish this from the Shim6 control messages. Receiver Context Tag: 47-bit unsigned integer. Allocated by the receiver for use to identify the context. 5.3. Common Shim6 Control header The common part of the header has a next header and header extension length field which is consistent with the other IPv6 extension headers, even if the next header value is always "NO NEXT HEADER" for the control messages. The Shim6 headers must be a multiple of 8 octets, hence the minimum size is 8 octets. Nordmark & Bagnulo Expires August 17, 2008 [Page 27] Internet-Draft Shim6 Protocol February 2008 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 |P| Type |Type-specific|S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Type-specific format | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Next Header: 8-bit selector. Normally set to NO_NXT_HDR (59). Hdr Ext Len: 8-bit unsigned integer. Length of the Shim6 header in 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. 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 having to change the checksum. Type-specific: Part of message that is different for different message types. Nordmark & Bagnulo Expires August 17, 2008 [Page 28] Internet-Draft Shim6 Protocol February 2008 +------------+-----------------------------------------------------+ | Type Value | Message | +------------+-----------------------------------------------------+ | 1 | I1 (first establishment message from the initiator) | | | | | 2 | R1 (first establishment message from the responder) | | | | | 3 | I2 (2nd establishment message from the initiator) | | | | | 4 | R2 (2nd establishment message from the responder) | | | | | 5 | R1bis (Reply to reference to non-existent context) | | | | | 6 | I2bis (Reply to a R1bis message) | | | | | 64 | Update Request | | | | | 65 | Update Acknowledgement | | | | | 66 | Keepalive | | | | | 67 | Probe Message | | | | | 68 | Error Message | +------------+-----------------------------------------------------+ Table 1 5.4. I1 Message Format The I1 message is the first message in the context establishment exchange. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 59 | Hdr Ext Len |0| Type = 1 | Reserved1 |0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum |R| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Initiator Context Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiator Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Options + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Nordmark & Bagnulo Expires August 17, 2008 [Page 29] Internet-Draft Shim6 Protocol February 2008 Fields: Next Header: NO_NXT_HDR (59). Hdr Ext Len: At least 1, since the header is 16 octets when there are no options. Type: 1 Reserved1: 7-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt. R: 1-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt. Initiator Context Tag: 47-bit field. The Context Tag the initiator has allocated for the context. Initiator Nonce: 32-bit unsigned integer. A random number picked by the initiator which the responder will return in the R1 message. 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 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, without creating any state specific to the initiator. Nordmark & Bagnulo Expires August 17, 2008 [Page 30] Internet-Draft Shim6 Protocol February 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 59 | Hdr Ext Len |0| Type = 2 | Reserved1 |0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiator Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Responder Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Options + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Next Header: NO_NXT_HDR (59). Hdr Ext Len: At least 1, since the header is 16 octets when there are no options. Type: 2 Reserved1: 7-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt. Reserved2: 16-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt. 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. 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. Nordmark & Bagnulo Expires August 17, 2008 [Page 31] Internet-Draft Shim6 Protocol February 2008 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 exchange. The initiator sends this in response to a R1 message, after checking the Initiator Nonce, etc. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 59 | Hdr Ext Len |0| Type = 3 | Reserved1 |0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum |R| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Initiator Context Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiator Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Responder Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Options + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Next Header: NO_NXT_HDR (59). Hdr Ext Len: At least 2, since the header is 24 octets when there are no options. Type: 3 Reserved1: 7-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt. R: 1-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt. Nordmark & Bagnulo Expires August 17, 2008 [Page 32] Internet-Draft Shim6 Protocol February 2008 Initiator Context Tag: 47-bit field. The Context Tag the initiator has allocated for the context. Initiator Nonce: 32-bit unsigned integer. A random number picked by the initiator which the responder will return in the R2 message. 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. 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 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: 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: This option MUST be included in the I2 message when some of the locators in the list use CGA (and not HBA) for verification. Nordmark & Bagnulo Expires August 17, 2008 [Page 33] Internet-Draft Shim6 Protocol February 2008 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 same time and the I1 messages cross in flight. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 59 | Hdr Ext Len |0| Type = 4 | Reserved1 |0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum |R| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Responder Context Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiator Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Options + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Next Header: NO_NXT_HDR (59). Hdr Ext Len: At least 1, since the header is 16 octets when there are no options. Type: 4 Reserved1: 7-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt. R: 1-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt. Responder Context Tag: 47-bit field. The Context Tag the responder has allocated for the context. Nordmark & Bagnulo Expires August 17, 2008 [Page 34] Internet-Draft Shim6 Protocol February 2008 Initiator Nonce: 32-bit unsigned integer. Copied from the I2 message. The following options are defined for this message: Locator List: Optionally sent when the responder immediately wants to tell the initiator 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 Signature: Included when the 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.8. R1bis Message Format Should a host receive a packet with a shim Payload extension header or Shim6 control message with type code 64-127 (such as an Update or Probe message), and the host does not have any context state for the received context tag, then it will generate a R1bis message. This message allows the sender of the packet referring to the non- existent context to re-establish the context with a reduced context establishment exchange. Upon the reception of the R1bis message, the receiver can proceed reestablishing the lost context by directly sending an I2bis message. Nordmark & Bagnulo Expires August 17, 2008 [Page 35] Internet-Draft Shim6 Protocol February 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 59 | Hdr Ext Len |0| Type = 5 | Reserved1 |0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum |R| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Packet Context Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Responder Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Options + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Next Header: NO_NXT_HDR (59). Hdr Ext Len: At least 1, since the header is 16 octets when there are no options. Type: 5 Reserved1: 7-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt. R: 1-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt. Packet Context Tag: 47-bit unsigned integer. The context tag contained in the received packet that triggered the generation of the R1bis message. Responder Nonce: 32-bit unsigned integer. A number picked by the responder which the initiator will return in the I2bis 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 I2bis message is indeed sent in response to a R1bis message. Future protocol extensions might define additional options for this Nordmark & Bagnulo Expires August 17, 2008 [Page 36] Internet-Draft Shim6 Protocol February 2008 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.9. I2bis Message Format The I2bis message is the third message in the context recovery exchange. This is sent in response to a R1bis message, after checking that the R1bis message refers to an existing context, etc. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 59 | Hdr Ext Len |0| Type = 6 | Reserved1 |0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum |R| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Initiator Context Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiator Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Responder Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Packet Context Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Options + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Next Header: NO_NXT_HDR (59). Hdr Ext Len: At least 3, since the header is 32 octets when there are no options. Type: 6 Reserved1: 7-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt. Nordmark & Bagnulo Expires August 17, 2008 [Page 37] Internet-Draft Shim6 Protocol February 2008 R: 1-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt. Initiator Context Tag: 47-bit field. The Context Tag the initiator has allocated for the context. Initiator Nonce: 32-bit unsigned integer. A random number picked by the initiator which the responder will return in the R2 message. Responder Nonce: 32-bit unsigned integer. Copied from the R1bis message. Reserved2: 49-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt. (Note that 17 bits are not sufficient since the options need start on a multiple of 8 octet boundary.) Packet Context Tag: 47-bit unsigned integer. Copied from the Packet Context Tag contained in the received R1bis. The following options are defined for this message: Responder Validator: Variable length option. Just a copy of the Responder Validator option in the R1bis 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. 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 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. Nordmark & Bagnulo Expires August 17, 2008 [Page 38] Internet-Draft Shim6 Protocol February 2008 CGA Signature: Included when the 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.10. Update Request Message Format The Update Request Message is used to update either the list of locators, the locator preferences, and both. When the list of locators is updated, the message also contains the option(s) necessary for HBA/CGA to secure this. The basic sanity check that prevents off-path attackers from generating bogus updates is the context tag in the message. The update message contains options (the Locator List and the Locator Preferences) that, when included, completely replace the previous locator list and locator preferences, respectively. Thus there is no mechanism to just send deltas to the locator list. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 59 | Hdr Ext Len |0| Type = 64 | Reserved1 |0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum |R| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Receiver Context Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Options + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Next Header: NO_NXT_HDR (59). Hdr Ext Len: At least 1, since the header is 16 octets when there are no options. Type: 64 Nordmark & Bagnulo Expires August 17, 2008 [Page 39] Internet-Draft Shim6 Protocol February 2008 Reserved1: 7-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt. R: 1-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt. Receiver Context Tag: 47-bit field. The Context Tag the receiver has allocated for the context. Request Nonce: 32-bit unsigned integer. A random number picked by the initiator which the peer will return in the acknowledgement message. The following options are defined for this message: Locator List: The list of the sender's (new) locators. The locators might be unchanged and only the preferences have changed. Locator Preferences: Optionally sent when the locators don't all have equal preference. CGA Parameter Data Structure (PDS): Included when the locator list is included and the PDS was not included in the I2/ I2bis/R2 messages, 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. 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.11. Update Acknowledgement Message Format This message is sent in response to a Update Request message. It implies that the Update Request has been received, and that any new locators in the Update Request can now be used as the source locators of packets. But it does not imply that the (new) locators have been verified to be used as a destination, since the host might defer the verification of a locator until it sees a need to use a locator as the destination. Nordmark & Bagnulo Expires August 17, 2008 [Page 40] Internet-Draft Shim6 Protocol February 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 59 | Hdr Ext Len |0| Type = 65 | Reserved1 |0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum |R| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Receiver Context Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Options + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Next Header: NO_NXT_HDR (59). Hdr Ext Len: At least 1, since the header is 16 octets when there are no options. Type: 65 Reserved1: 7-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt. R: 1-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt. Receiver Context Tag: 47-bit field. The Context Tag the receiver has allocated for the context. Request Nonce: 32-bit unsigned integer. Copied from the Update 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 [5]. The message is used to ensure that when a peer is sending ULP packets Nordmark & Bagnulo Expires August 17, 2008 [Page 41] Internet-Draft Shim6 Protocol February 2008 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 [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. 5.14. Error Message Format The Error Message is generated by a Shim6 receiver upon the reception of a Shim6 message containing critical information that cannot be processed properly. In the case that a Shim6 node receives a Shim6 packet which contains information that is critical for the Shim6 protocol that is not supported by the receiver, it sends an Error Message back to the originator of the Shim6 message. The Error Message is unacknowledged. In addition, Shim6 Error messages defined in this section can be used to identify problems with Shim6 implementations. In order to do that, a range of Error Code Types is reserved for that purpose. In particular, implementations may generate Shim6 Error messages with Code Type in that range instead of silently discarding Shim6 packets during the debugging process. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 59 | Hdr Ext Len |0| Type = 68 | Error Code |0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Packet in error + | | Nordmark & Bagnulo Expires August 17, 2008 [Page 42] Internet-Draft Shim6 Protocol February 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Next Header: NO_NXT_HDR (59). Hdr Ext Len: At least 1, since the header is 16 octets. Depends on the specific Error Data. Type: 68 Error Code: 7-bit field describing the error that generated the Error Message. See Error Code list below Pointer: 16-bit field.Identifies the octet offset within the invoking packet where the error was detected. Packet in error: As much of invoking packet as possible without the Error message packet exceeding the minimum IPv6 MTU. The following Error Codes are defined: +---------+---------------------------------------------------------+ | Code | Description | | Value | | +---------+---------------------------------------------------------+ | 0 | Unknown Shim6 message type | | | | | 1 | Critical Option not recognized | | | | | 2 | Locator verification method failed (Pointer to the | | | inconsistent Verification method octet) | | | | | 3 | Locator List Generation number out of sync. | | | | | 4 | Error in the number of locators in a Locator Preference | | | option | | | | | 120-127 | Reserved for debugging purposes | +---------+---------------------------------------------------------+ Table 2 5.15. Option Formats The format of the options is a snapshot of the current HIP option format [20]. However, there is no intention to track any changes to the HIP option format, nor is there an intent to use the same name Nordmark & Bagnulo Expires August 17, 2008 [Page 43] Internet-Draft Shim6 Protocol February 2008 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 added padding bytes MUST be zeroed by the sender, and their values SHOULD NOT be checked by the receiver. Consequently, the Length field indicates the length of the Contents field (in bytes). The total length of the TLV parameter (including Type, Length, Contents, and Padding) is related to the Length field according to the following formula: Total Length = 11 + Length - (Length + 3) mod 8; The Total Length of the option is the smallest multiple of 8 bytes that allows for the 4 bytes of option header and the option itself. The amount of padding required can be calculated as follows: padding = 7 - ((Length + 3) mod 8) And: Total Length = 4 + Length + padding 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 |C| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ ~ Contents ~ ~ +-+-+-+-+-+-+-+-+ ~ | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type: 15-bit identifier of the type of option. The options defined in this document are below. Nordmark & Bagnulo Expires August 17, 2008 [Page 44] Internet-Draft Shim6 Protocol February 2008 C: Critical. One if this parameter is critical, and MUST be recognized by the recipient, zero otherwise. An implementation might view the C bit as part of the Type field, by multiplying the type values in this specification by two. Length: Length of the Contents, in bytes. Contents: Parameter specific, defined by Type. Padding: Padding, 0-7 bytes, added if needed. +------+------------------------------+ | Type | Option Name | +------+------------------------------+ | 1 | Responder Validator | | | | | 2 | Locator List | | | | | 3 | Locator Preferences | | | | | 4 | CGA Parameter Data Structure | | | | | 5 | CGA Signature | | | | | 6 | ULID Pair | | | | | 7 | Forked Instance Identifier | | | | | 10 | Keepalive Timeout Option | +------+------------------------------+ Table 3 Future protocol extensions might define additional options for the Shim6 messages. The C-bit in the option format defines how such a new option will be handled by an implementation. If a host receives an option that it does not understand (an option that was defined in some future extension to this protocol) or is not listed as a valid option for the different message types above, then the Critical bit in the option determines the outcome. o If C=0 then the option is silently ignored, and the rest of the message is processed. o If C=1 then the host SHOULD send back a Shim6 Error Message with Error Code=1, with the Pointer referencing the first octet in the Nordmark & Bagnulo Expires August 17, 2008 [Page 45] Internet-Draft Shim6 Protocol February 2008 Option Type field. When C=1 the rest of the message MUST NOT be processed. 5.15.1. Responder Validator Option Format The responder can choose exactly what input is used to compute the validator, and what one-way function (such as MD5, SHA1) it uses, as long as the responder can check that the validator it receives back in the I2 or I2bis message is indeed one that: 1)- it computed, 2)- it computed for the particular context, and 3)- that it isn't a replayed I2/I2bis message. Some suggestions on how to generate the validators are captured in Section 7.10.1 and Section 7.17.1. 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 = 1 |0| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Validator ~ ~ +-+-+-+-+-+-+-+-+ ~ | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Validator: Variable length content whose interpretation is local to the responder. Padding: Padding, 0-7 bytes, added if needed. See Section 5.15. 5.15.2. Locator List Option Format The Locator List Option is used to carry all the locators of the sender. Note that the order of the locators is important, since the Locator Preferences refers to the locators by using the index in the list. Note that we carry all the locators in this option even though some of them can be created automatically from the CGA Parameter Data Structure. Nordmark & Bagnulo Expires August 17, 2008 [Page 46] Internet-Draft Shim6 Protocol February 2008 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 = 2 |0| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator List Generation | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num Locators | N Octets of Verification Method | +-+-+-+-+-+-+-+-+ | ~ ~ ~ +-+-+-+-+-+-+-+-+ ~ | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Locators 1 through N ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Locator List Generation: 32-bit unsigned integer. Indicates a generation number which is increased by one for each new locator list. This is used to ensure that the index in the Locator Preferences refer to the right version of the locator list. Num Locators: 8-bit unsigned integer. The number of locators that are included in the option. We call this number "N" below. Verification Method: N octets. The i'th octet specifies the verification method for the i'th locator. Padding: Padding, 0-7 bytes, added if needed so that the Locators start on a multiple of 8 octet boundary. NOTE that for this option there is never a need to pad at the end, since the locators are a multiple of 8 octets in length. This internal padding is included in the length field. Locators: N 128-bit locators. The defined verification methods are: Nordmark & Bagnulo Expires August 17, 2008 [Page 47] Internet-Draft Shim6 Protocol February 2008 +-------+----------+ | Value | Method | +-------+----------+ | 0 | Reserved | | | | | 1 | HBA | | | | | 2 | CGA | | | | | 3-255 | Reserved | +-------+----------+ 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 [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. The locators are not included in the preference list. Instead, the first element refers to locator that was in the first element in the Locator List option. The generation number carried in this option and the Locator List option is used to verify that they refer to the same version of the locator list. Nordmark & Bagnulo Expires August 17, 2008 [Page 48] Internet-Draft Shim6 Protocol February 2008 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 = 3 |0| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator List Generation | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Element Len | Element[1] | Element[2] | Element[3] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ ~ +-+-+-+-+-+-+-+-+ ~ | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Case of Element Len = 1 is depicted. Fields: Locator List Generation: 32-bit unsigned integer. Indicates a generation number for the locator list to which the elements should apply. Element Len: 8-bit unsigned integer. The length in octets of each element. This specification defines the cases when the length is 1, 2, or 3. Element[i]: A field with a number of octets defined by the Element Len field. Provides preferences for the i'th locator in the Locator List option that is in use. Padding: Padding, 0-7 bytes, added if needed. See Section 5.15. When the Element length equals one, then the element consists of only a one octet flags field. The currently defined set of flags are: BROKEN: 0x01 TRANSIENT: 0x02 The intent of the BROKEN flag is to inform the peer that a given locator is known to be not working. The intent of TRANSIENT is to allow the distinction between more stable addresses and less stable addresses when Shim6 is combined with IP mobility, when we might have more stable home locators, and less stable care-of-locators. When the Element length equals two, then the element consists of a 1 octet flags field followed by a 1 octet priority field. The priority Nordmark & Bagnulo Expires August 17, 2008 [Page 49] Internet-Draft Shim6 Protocol February 2008 has the same semantics as the priority in DNS SRV records. When the Element length equals three, then the element consists of a 1 octet flags field followed by a 1 octet priority field, and a 1 octet weight field. The weight has the same semantics as the weight in DNS SRV records. 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 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 [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. Nordmark & Bagnulo Expires August 17, 2008 [Page 50] Internet-Draft Shim6 Protocol February 2008 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 = 5 |0| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ CGA Signature ~ ~ +-+-+-+-+-+-+-+-+ ~ | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: CGA Signature: A variable-length field containing a PKCS#1 v1.5 signature, constructed by using the sender's private key over the following sequence of octets: 1. The 128-bit CGA Message Type tag [CGA] value for Shim6, 0x4A 30 5662 4858 574B 3655 416F 506A 6D48. (The tag value has been generated randomly by the editor of this specification.). 2. The Locator List Generation value of the correspondent Locator List Option. 3. The subset of locators included in the correspondent Locator List Option which verification method is set to CGA. The locators MUST be included in the order they are listed in the Locator List Option. Padding: Padding, 0-7 bytes, added if needed. See Section 5.15. 5.15.6. ULID Pair Option Format I1, I2, and I2bis messages MUST contain the ULID pair; normally this is in the IPv6 source and destination fields. In case that the ULID for the context differ from the address pair included in the source and destination address fields of the IPv6 packet used to carry the I1/I2/I2bis message, the ULID pair option MUST be included in the I1/ I2/I2bis message. Nordmark & Bagnulo Expires August 17, 2008 [Page 51] Internet-Draft Shim6 Protocol February 2008 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 = 6 |0| Length = 36 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Sender ULID + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Receiver ULID + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Reserved2: 32-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt. (Needed to make the ULIDs start on a multiple of 8 octet boundary.) Sender ULID: A 128-bit IPv6 address. Receiver ULID: A 128-bit IPv6 address. 5.15.7. Forked Instance Identifier Option Format 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 = 7 |0| Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 [5]. Nordmark & Bagnulo Expires August 17, 2008 [Page 52] Internet-Draft Shim6 Protocol February 2008 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. 6.1. Conceptual Data Structures The key conceptual data structure for the Shim6 protocol is the ULID pair context. This is a data structure which contains the following information: o The state of the context. See Section 6.2. o The peer ULID; ULID(peer) o The local ULID; ULID(local) o The Forked Instance Identifier; FII. This is zero for the default context i.e., when there is no forking. o The list of peer locators, with their preferences; Ls(peer) 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 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 current local locator, is the locator used as source address when sending packets; Lp(local) Nordmark & Bagnulo Expires August 17, 2008 [Page 53] Internet-Draft Shim6 Protocol February 2008 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. 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 [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 Nordmark & Bagnulo Expires August 17, 2008 [Page 54] Internet-Draft Shim6 Protocol February 2008 6.2. Context STATES The STATES that are used to describe the Shim6 protocol are as follows: +---------------------+---------------------------------------------+ | STATE | Explanation | +---------------------+---------------------------------------------+ | IDLE | State machine start | | | | | I1-SENT | Initiating context establishment exchange | | | | | I2-SENT | Waiting to complete context establishment | | | exchange | | | | | I2BIS-SENT | Potential context loss detected | | | | | | | | ESTABLISHED | SHIM context established | | | | | E-FAILED | Context establishment exchange failed | | | | | NO-SUPPORT | ICMP Unrecognized Next Header type | | | (type 4, code 1) received indicating | | | that Shim6 is not supported | +---------------------+---------------------------------------------+ Nordmark & Bagnulo Expires August 17, 2008 [Page 55] Internet-Draft Shim6 Protocol February 2008 In addition, in each of the aforementioned STATES, the following state information is stored: +---------------------+---------------------------------------------+ | STATE | Information | +---------------------+---------------------------------------------+ | IDLE | None | | | | | I1-SENT | ULID(peer), ULID(local), [FII], CT(local), | | | INIT nonce, Lp(local), Lp(peer), Ls(local) | | | | | I2-SENT | ULID(peer), ULID(local), [FII], CT(local), | | | INIT nonce, RESP nonce, Lp(local), Lp(peer),| | | Ls(local), Responder Validator | | | | | ESTABLISHED | ULID(peer), ULID(local), [FII], CT(local), | | | CT(peer), Lp(local), Lp(peer), Ls(local) | | | Ls(peer), INIT nonce?(to receive late R2) | | | | | I2BIS-SENT | ULID(peer), ULID(local), [FII], CT(local), | | | CT(peer), Lp(local), Lp(peer), Ls(local) | | | Ls(peer), CT(R1bis), RESP nonce, | | | INIT nonce, Responder validator | | | | | E-FAILED | ULID(peer), ULID(local) | | | | | NO-SUPPORT | ULID(peer), ULID(local) | +---------------------+---------------------------------------------+ Nordmark & Bagnulo Expires August 17, 2008 [Page 56] Internet-Draft Shim6 Protocol February 2008 7. Establishing ULID-Pair Contexts ULID-pair contexts are established using a 4-way exchange, which allows the responder to avoid creating state on the first packet. As part of this exchange each end allocates a context tag, and it shares this context tag and its set of locators with the peer. In some cases the 4-way exchange is not necessary, for instance when both ends try to setup the context at the same time, or when recovering from a context that has been garbage collected or lost at one of the hosts. 7.1. Uniqueness of Context Tags As part of establishing a new context, each host has to assign a unique context tag. Since the Payload Extension headers are demultiplexed based solely on the context tag value (without using the locators), the context tag MUST be unique for each context. 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 unstructured tag name space reserved for randomly assigned context tag values,(e.g. following the 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 i