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

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/