draft-ietf-shim6-proto-11.txt   draft-ietf-shim6-proto-12.txt 
SHIM6 WG E. Nordmark SHIM6 WG E. Nordmark
Internet-Draft Sun Microsystems Internet-Draft Sun Microsystems
Intended status: Standards Track M. Bagnulo Intended status: Standards Track M. Bagnulo
Expires: June 18, 2009 UC3M Expires: August 10, 2009 UC3M
December 15, 2008 February 6, 2009
Shim6: Level 3 Multihoming Shim Protocol for IPv6 Shim6: Level 3 Multihoming Shim Protocol for IPv6
draft-ietf-shim6-proto-11.txt draft-ietf-shim6-proto-12.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 June 18, 2009. This Internet-Draft will expire on August 10, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2008 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. to this document.
Abstract Abstract
skipping to change at page 2, line 28 skipping to change at page 2, line 28
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . . . . . 14 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 14 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 13
2.2. Notational Conventions . . . . . . . . . . . . . . . . . 17 2.2. Notational Conventions . . . . . . . . . . . . . . . . . 16
2.3. Conceptual . . . . . . . . . . . . . . . . . . . . . . . 17 2.3. Conceptual . . . . . . . . . . . . . . . . . . . . . . . 16
3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 18 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 17
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 20 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 19
4.1. Context Tags . . . . . . . . . . . . . . . . . . . . . . 22 4.1. Context Tags . . . . . . . . . . . . . . . . . . . . . . 21
4.2. Context Forking . . . . . . . . . . . . . . . . . . . . . 22 4.2. Context Forking . . . . . . . . . . . . . . . . . . . . . 21
4.3. API Extensions . . . . . . . . . . . . . . . . . . . . . 23 4.3. API Extensions . . . . . . . . . . . . . . . . . . . . . 22
4.4. Securing Shim6 . . . . . . . . . . . . . . . . . . . . . 23 4.4. Securing Shim6 . . . . . . . . . . . . . . . . . . . . . 22
4.5. Overview of Shim Control Messages . . . . . . . . . . . . 24 4.5. Overview of Shim Control Messages . . . . . . . . . . . . 23
4.6. Extension Header Order . . . . . . . . . . . . . . . . . 25 4.6. Extension Header Order . . . . . . . . . . . . . . . . . 24
5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 27 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 26
5.1. Common Shim6 Message Format . . . . . . . . . . . . . . . 27 5.1. Common Shim6 Message Format . . . . . . . . . . . . . . . 26
5.2. Payload Extension Header Format . . . . . . . . . . . . . 28 5.2. Payload Extension Header Format . . . . . . . . . . . . . 27
5.3. Common Shim6 Control header . . . . . . . . . . . . . . . 28 5.3. Common Shim6 Control header . . . . . . . . . . . . . . . 27
5.4. I1 Message Format . . . . . . . . . . . . . . . . . . . . 30 5.4. I1 Message Format . . . . . . . . . . . . . . . . . . . . 29
5.5. R1 Message Format . . . . . . . . . . . . . . . . . . . . 31 5.5. R1 Message Format . . . . . . . . . . . . . . . . . . . . 30
5.6. I2 Message Format . . . . . . . . . . . . . . . . . . . . 33 5.6. I2 Message Format . . . . . . . . . . . . . . . . . . . . 32
5.7. R2 Message Format . . . . . . . . . . . . . . . . . . . . 35 5.7. R2 Message Format . . . . . . . . . . . . . . . . . . . . 34
5.8. R1bis Message Format . . . . . . . . . . . . . . . . . . 36 5.8. R1bis Message Format . . . . . . . . . . . . . . . . . . 35
5.9. I2bis Message Format . . . . . . . . . . . . . . . . . . 38 5.9. I2bis Message Format . . . . . . . . . . . . . . . . . . 37
5.10. Update Request Message Format . . . . . . . . . . . . . . 40 5.10. Update Request Message Format . . . . . . . . . . . . . . 39
5.11. Update Acknowledgement Message Format . . . . . . . . . . 41 5.11. Update Acknowledgement Message Format . . . . . . . . . . 40
5.12. Keepalive Message Format . . . . . . . . . . . . . . . . 42 5.12. Keepalive Message Format . . . . . . . . . . . . . . . . 41
5.13. Probe Message Format . . . . . . . . . . . . . . . . . . 43 5.13. Probe Message Format . . . . . . . . . . . . . . . . . . 42
5.14. Error Message Format . . . . . . . . . . . . . . . . . . 43 5.14. Error Message Format . . . . . . . . . . . . . . . . . . 42
5.15. Option Formats . . . . . . . . . . . . . . . . . . . . . 44 5.15. Option Formats . . . . . . . . . . . . . . . . . . . . . 43
5.15.1. Responder Validator Option Format . . . . . . . . . 47 5.15.1. Responder Validator Option Format . . . . . . . . . 46
5.15.2. Locator List Option Format . . . . . . . . . . . . . 47 5.15.2. Locator List Option Format . . . . . . . . . . . . . 46
5.15.3. Locator Preferences Option Format . . . . . . . . . 49 5.15.3. Locator Preferences Option Format . . . . . . . . . 48
5.15.4. CGA Parameter Data Structure Option Format . . . . . 51 5.15.4. CGA Parameter Data Structure Option Format . . . . . 50
5.15.5. CGA Signature Option Format . . . . . . . . . . . . 51 5.15.5. CGA Signature Option Format . . . . . . . . . . . . 50
5.15.6. ULID Pair Option Format . . . . . . . . . . . . . . 52 5.15.6. ULID Pair Option Format . . . . . . . . . . . . . . 51
5.15.7. Forked Instance Identifier Option Format . . . . . . 53 5.15.7. Forked Instance Identifier Option Format . . . . . . 52
5.15.8. Keepalive Timeout Option Format . . . . . . . . . . 53 5.15.8. Keepalive Timeout Option Format . . . . . . . . . . 52
6. Conceptual Model of a Host . . . . . . . . . . . . . . . . . 54 6. Conceptual Model of a Host . . . . . . . . . . . . . . . . . 53
6.1. Conceptual Data Structures . . . . . . . . . . . . . . . 54 6.1. Conceptual Data Structures . . . . . . . . . . . . . . . 53
6.2. Context STATES . . . . . . . . . . . . . . . . . . . . . 56 6.2. Context STATES . . . . . . . . . . . . . . . . . . . . . 55
7. Establishing ULID-Pair Contexts . . . . . . . . . . . . . . . 58 7. Establishing ULID-Pair Contexts . . . . . . . . . . . . . . . 57
7.1. Uniqueness of Context Tags . . . . . . . . . . . . . . . 58 7.1. Uniqueness of Context Tags . . . . . . . . . . . . . . . 57
7.2. Locator Verification . . . . . . . . . . . . . . . . . . 58 7.2. Locator Verification . . . . . . . . . . . . . . . . . . 57
7.3. Normal context establishment . . . . . . . . . . . . . . 59 7.3. Normal context establishment . . . . . . . . . . . . . . 58
7.4. Concurrent context establishment . . . . . . . . . . . . 59 7.4. Concurrent context establishment . . . . . . . . . . . . 58
7.5. Context recovery . . . . . . . . . . . . . . . . . . . . 61 7.5. Context recovery . . . . . . . . . . . . . . . . . . . . 60
7.6. Context confusion . . . . . . . . . . . . . . . . . . . . 63 7.6. Context confusion . . . . . . . . . . . . . . . . . . . . 62
7.7. Sending I1 messages . . . . . . . . . . . . . . . . . . . 64 7.7. Sending I1 messages . . . . . . . . . . . . . . . . . . . 63
7.8. Retransmitting I1 messages . . . . . . . . . . . . . . . 65 7.8. Retransmitting I1 messages . . . . . . . . . . . . . . . 64
7.9. Receiving I1 messages . . . . . . . . . . . . . . . . . . 65 7.9. Receiving I1 messages . . . . . . . . . . . . . . . . . . 64
7.10. Sending R1 messages . . . . . . . . . . . . . . . . . . . 66 7.10. Sending R1 messages . . . . . . . . . . . . . . . . . . . 65
7.10.1. Generating the R1 Validator . . . . . . . . . . . . 67 7.10.1. Generating the R1 Validator . . . . . . . . . . . . 66
7.11. Receiving R1 messages and sending I2 messages . . . . . . 67 7.11. Receiving R1 messages and sending I2 messages . . . . . . 66
7.12. Retransmitting I2 messages . . . . . . . . . . . . . . . 68 7.12. Retransmitting I2 messages . . . . . . . . . . . . . . . 67
7.13. Receiving I2 messages . . . . . . . . . . . . . . . . . . 69 7.13. Receiving I2 messages . . . . . . . . . . . . . . . . . . 68
7.14. Sending R2 messages . . . . . . . . . . . . . . . . . . . 70 7.14. Sending R2 messages . . . . . . . . . . . . . . . . . . . 69
7.15. Match for Context Confusion . . . . . . . . . . . . . . . 71 7.15. Match for Context Confusion . . . . . . . . . . . . . . . 70
7.16. Receiving R2 messages . . . . . . . . . . . . . . . . . . 71 7.16. Receiving R2 messages . . . . . . . . . . . . . . . . . . 70
7.17. Sending R1bis messages . . . . . . . . . . . . . . . . . 72 7.17. Sending R1bis messages . . . . . . . . . . . . . . . . . 71
7.17.1. Generating the R1bis Validator . . . . . . . . . . . 73 7.17.1. Generating the R1bis Validator . . . . . . . . . . . 72
7.18. Receiving R1bis messages and sending I2bis messages . . . 73 7.18. Receiving R1bis messages and sending I2bis messages . . . 72
7.19. Retransmitting I2bis messages . . . . . . . . . . . . . . 74 7.19. Retransmitting I2bis messages . . . . . . . . . . . . . . 73
7.20. Receiving I2bis messages and sending R2 messages . . . . 75 7.20. Receiving I2bis messages and sending R2 messages . . . . 74
8. Handling ICMP Error Messages . . . . . . . . . . . . . . . . 77 8. Handling ICMP Error Messages . . . . . . . . . . . . . . . . 76
9. Teardown of the ULID-Pair Context . . . . . . . . . . . . . . 80 9. Teardown of the ULID-Pair Context . . . . . . . . . . . . . . 79
10. Updating the Peer . . . . . . . . . . . . . . . . . . . . . . 81 10. Updating the Peer . . . . . . . . . . . . . . . . . . . . . . 80
10.1. Sending Update Request messages . . . . . . . . . . . . . 81 10.1. Sending Update Request messages . . . . . . . . . . . . . 80
10.2. Retransmitting Update Request messages . . . . . . . . . 81 10.2. Retransmitting Update Request messages . . . . . . . . . 80
10.3. Newer Information While Retransmitting . . . . . . . . . 82 10.3. Newer Information While Retransmitting . . . . . . . . . 81
10.4. Receiving Update Request messages . . . . . . . . . . . . 82 10.4. Receiving Update Request messages . . . . . . . . . . . . 81
10.5. Receiving Update Acknowledgement messages . . . . . . . . 84 10.5. Receiving Update Acknowledgement messages . . . . . . . . 83
11. Sending ULP Payloads . . . . . . . . . . . . . . . . . . . . 86 11. Sending ULP Payloads . . . . . . . . . . . . . . . . . . . . 85
11.1. Sending ULP Payload after a Switch . . . . . . . . . . . 86 11.1. Sending ULP Payload after a Switch . . . . . . . . . . . 85
12. Receiving Packets . . . . . . . . . . . . . . . . . . . . . . 88 12. Receiving Packets . . . . . . . . . . . . . . . . . . . . . . 87
12.1. Receiving payload without extension headers . . . . . . . 88 12.1. Receiving payload without extension headers . . . . . . . 87
12.2. Receiving Payload Extension Headers . . . . . . . . . . . 88 12.2. Receiving Payload Extension Headers . . . . . . . . . . . 87
12.3. Receiving Shim Control messages . . . . . . . . . . . . . 89 12.3. Receiving Shim Control messages . . . . . . . . . . . . . 88
12.4. Context Lookup . . . . . . . . . . . . . . . . . . . . . 89 12.4. Context Lookup . . . . . . . . . . . . . . . . . . . . . 88
13. Initial Contact . . . . . . . . . . . . . . . . . . . . . . . 92 13. Initial Contact . . . . . . . . . . . . . . . . . . . . . . . 91
14. Protocol constants . . . . . . . . . . . . . . . . . . . . . 93 14. Protocol constants . . . . . . . . . . . . . . . . . . . . . 92
15. Implications Elsewhere . . . . . . . . . . . . . . . . . . . 94 15. Implications Elsewhere . . . . . . . . . . . . . . . . . . . 93
15.1. Congestion Control Considerations . . . . . . . . . . . . 94 15.1. Congestion Control Considerations . . . . . . . . . . . . 93
15.2. Middle-boxes considerations . . . . . . . . . . . . . . . 94 15.2. Middle-boxes considerations . . . . . . . . . . . . . . . 93
15.3. Operation and Management Considerations . . . . . . . . . 95 15.3. Operation and Management Considerations . . . . . . . . . 94
15.4. Other considerations . . . . . . . . . . . . . . . . . . 96 15.4. Other considerations . . . . . . . . . . . . . . . . . . 95
16. Security Considerations . . . . . . . . . . . . . . . . . . . 98 16. Security Considerations . . . . . . . . . . . . . . . . . . . 97
16.1. Interaction with IPsec . . . . . . . . . . . . . . . . . 99 16.1. Interaction with IPSec . . . . . . . . . . . . . . . . . 98
16.2. Residual Threats . . . . . . . . . . . . . . . . . . . . 101 16.2. Residual Threats . . . . . . . . . . . . . . . . . . . . 99
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 103 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 101
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 105 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 103
Appendix A. Possible Protocol Extensions . . . . . . . . . . 106 19. Appendix: Possible Protocol Extensions . . . . . . . . . . . 104
Appendix B. Simplified STATE Machine . . . . . . . . . . . . 108 20. Appendix: Simplified STATE Machine . . . . . . . . . . . . . 106
Appendix B.1. Simplified STATE Machine diagram . . . . . . . . 113 20.1. Simplified STATE Machine diagram . . . . . . . . . . . . 111
Appendix C. Context Tag Reuse . . . . . . . . . . . . . . . . 115 21. Appendix: Context Tag Reuse . . . . . . . . . . . . . . . . . 113
Appendix C.1. Context Recovery . . . . . . . . . . . . . . . . 115 21.1. Context Recovery . . . . . . . . . . . . . . . . . . . . 113
Appendix C.2. Context Confusion . . . . . . . . . . . . . . . . 115 21.2. Context Confusion . . . . . . . . . . . . . . . . . . . . 113
Appendix C.3. Three Party Context Confusion . . . . . . . . . . 116 21.3. Three Party Context Confusion . . . . . . . . . . . . . . 114
Appendix C.4. Summary . . . . . . . . . . . . . . . . . . . . . 116 21.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 114
Appendix D. Design Alternatives . . . . . . . . . . . . . . . 117 22. Appendix: Design Alternatives . . . . . . . . . . . . . . . . 115
Appendix D.1. Context granularity . . . . . . . . . . . . . . . 117 22.1. Context granularity . . . . . . . . . . . . . . . . . . . 115
Appendix D.2. Demultiplexing of data packets in Shim6 22.2. Demultiplexing of data packets in Shim6 communications . 115
communications . . . . . . . . . . . . . . . . . 117 22.2.1. Flow-label . . . . . . . . . . . . . . . . . . . . . 116
Appendix D.2.1. Flow-label . . . . . . . . . . . . . . . . . . . 118 22.2.2. Extension Header . . . . . . . . . . . . . . . . . . 118
Appendix D.2.2. Extension Header . . . . . . . . . . . . . . . . 120 22.3. Context Loss Detection . . . . . . . . . . . . . . . . . 119
Appendix D.3. Context Loss Detection . . . . . . . . . . . . . 121 22.4. Securing locator sets . . . . . . . . . . . . . . . . . . 121
Appendix D.4. Securing locator sets . . . . . . . . . . . . . . 123 22.5. ULID-pair context establishment exchange . . . . . . . . 124
Appendix D.5. ULID-pair context establishment exchange . . . . 126 22.6. Updating locator sets . . . . . . . . . . . . . . . . . . 125
Appendix D.6. Updating locator sets . . . . . . . . . . . . . . 127 22.7. State Cleanup . . . . . . . . . . . . . . . . . . . . . . 125
Appendix D.7. State Cleanup . . . . . . . . . . . . . . . . . . 127 23. Appendix: Change Log . . . . . . . . . . . . . . . . . . . . 128
Appendix E. Change Log . . . . . . . . . . . . . . . . . . . 130 24. References . . . . . . . . . . . . . . . . . . . . . . . . . 135
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 137 24.1. Normative References . . . . . . . . . . . . . . . . . . 135
19.1. Normative References . . . . . . . . . . . . . . . . . . 137 24.2. Informative References . . . . . . . . . . . . . . . . . 135
19.2. Informative References . . . . . . . . . . . . . . . . . 137 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 137
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 139
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 [10], without assuming that a multihomed site will have a properties [10], 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
skipping to change at page 9, line 19 skipping to change at page 9, line 19
when the ULID becomes invalid. The context recovery mechanism will when the ULID becomes invalid. The context recovery mechanism will
then make the peer aware that the context is gone, and that the ULID then make the peer aware that the context is gone, and that the ULID
is no longer present at the same locator(s). is no longer present at the same locator(s).
1.6. Placement of the shim 1.6. Placement of the shim
----------------------- -----------------------
| Transport Protocols | | Transport Protocols |
----------------------- -----------------------
------ ------- -------------- ------------- IP endpoint -------------- ------------- IP endpoint
| AH | | ESP | | Frag/reass | | Dest opts | sub-layer | Frag/reass | | Dest opts | sub-layer
------ ------- -------------- ------------- -------------- -------------
--------------------- ---------------------
| Shim6 shim layer | | Shim6 shim layer |
--------------------- ---------------------
------ IP routing ------ IP routing
| IP | sub-layer | IP | sub-layer
------ ------
Figure 1: Protocol stack Figure 1: Protocol stack
The proposal uses a multihoming shim layer within the IP layer, i.e., The proposal uses a multihoming shim layer within the IP layer, i.e.,
below the ULPs, as shown in Figure 1, in order to provide ULP below the ULPs, as shown in Figure 1, in order to provide ULP
independence. The multihoming shim layer behaves as if it is independence. The multihoming shim layer behaves as if it is
associated with an extension header, which would be placed after any associated with an extension header, which would be placed after any
routing-related headers in the packet (such as any hop-by-hop routing-related headers in the packet (such as any hop-by-hop
options, or routing header). However, when the locator pair is the options, or routing header). However, when the locator pair is the
ULID pair there is no data that needs to be carried in an extension ULID pair there is no data that needs to be carried in an extension
header, thus none is needed in that case. header, thus none is needed in that case.
For the relative layering of the shim and ESP/AH there are two
choices.
With a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation
as well as the case of IPsec communication between a host and a
security gateway the layering naturally becomes shim6 over ESP/AH.
This implies that when the shim on the sender changes the ULIDs to
locators after a failure then a different IPsec security assocation
would be used since the SA is tied to the IP addresses in the packet.
But that approach is of low complexity.
With a native IPsec implementation that communicates end-to-end it is
possible to layer IPsec above the shim. That avoids any key
management actions when the locators change after a failure, and it
fits better with the architectural picture above with IPsec in the
endpoint sublayer. The downside is that it requires some care on the
sender to ensure that the change of the ULIDs to locators underneath
IPsec doesn't cause any violations of IPsec policies. The
implementation of such checks would add some complexity. The details
of needed care is specified in Section 16.1.
A receiver handles either order of AH/ESP and the shim since the
sender's order of processing is reflected in the order of the shim6
vs. AH/ESP headers in the packet.
Layering the fragmentation header above the multihoming shim makes Layering the fragmentation header above the multihoming shim makes
reassembly robust in the case that there is broken multi-path routing reassembly robust in the case that there is broken multi-path routing
which results in using different paths, hence potentially different which results in using different paths, hence potentially different
source locators, for different fragments. Thus, the multihoming shim source locators, for different fragments. Thus, the multihoming shim
layer is placed between the IP endpoint sublayer, which handles layer is placed between the IP endpoint sublayer, which handles
fragmentation, reassembly, and the IP routing sublayer, which selects fragmentation, reassembly, and the IP routing sublayer, which selects
which next hop and interface to use for sending out packets. which next hop and interface to use for sending out packets.
Applications and upper layer protocols use ULIDs which the Shim6 Applications and upper layer protocols use ULIDs which the Shim6
layer map to/from different locators. The Shim6 layer maintains layer map to/from different locators. The Shim6 layer maintains
skipping to change at page 13, line 7 skipping to change at page 12, line 22
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 option is merely a place and weight values for each locator. This option is merely a place
holder when it comes to providing traffic engineering; in order to holder when it comes to providing traffic engineering; in order to
use this in a large site there would have to be a mechanism by which use this in a large site there would have to be a mechanism by which
the host can find out what preference values to use, either the host can find out what preference values to use, either
statically (e.g., some new DHCPv6 option) or dynamically. statically (e.g., some 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. Section 19.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. 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:
skipping to change at page 23, line 39 skipping to change at page 22, line 39
Several API extensions have been discussed for Shim6, but their Several API extensions have been discussed for Shim6, but their
actual specification is out of scope for this document. The simplest actual specification is out of scope for this document. The simplest
one would be to add a socket option to be able to have traffic bypass one would be to add a socket option to be able to have traffic bypass
the shim (not create any state, and not use any state created by the shim (not create any state, and not use any state created by
other traffic). This could be an IPV6_DONTSHIM socket option. Such other traffic). This could be an IPV6_DONTSHIM socket option. Such
an option would be useful for protocols, such as DNS, where the an option would be useful for protocols, such as DNS, where the
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. The actual Some other API extensions are discussed in Section 19. The actual
API extensions are defined in [22]. API extensions are defined in [22].
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 [3] for verifying the locators to prevent an o The HBA technique [3] 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 [4]) before a new o Requiring a Reachability Probe+Reply /defined in [4]) before a new
skipping to change at page 80, line 36 skipping to change at page 79, line 36
Since there is no explicit, coordinated removal of the context state, Since there is no explicit, coordinated removal of the context state,
there are potential issues around context tag reuse. One end might there are potential issues around context tag reuse. One end might
remove the state, and potentially reuse that context tag for some remove the state, and potentially reuse that context tag for some
other communication, and the peer might later try to use the old other communication, and the peer might later try to use the old
context (which it didn't remove). The protocol has mechanisms to context (which it didn't remove). The protocol has mechanisms to
recover from this, which work whether the state removal was total and recover from this, which work whether the state removal was total and
accidental (e.g., crash and reboot of the host), or just a garbage accidental (e.g., crash and reboot of the host), or just a garbage
collection of shim state that didn't seem to be used. However, the collection of shim state that didn't seem to be used. However, the
host should try to minimize the reuse of context tags by trying to host should try to minimize the reuse of context tags by trying to
randomly cycle through the 2^47 context tag values. (See Appendix C randomly cycle through the 2^47 context tag values. (See Section 21
for a summary how the recovery works in the different cases.) for a summary how the recovery works in the different cases.)
10. Updating the Peer 10. Updating the Peer
The Update Request and Acknowledgement are used both to update the The Update Request and Acknowledgement are used both to update the
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
skipping to change at page 99, line 18 skipping to change at page 98, line 18
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
as described in section 4.4 of [14]. Such discovery probably as described in section 4.4 of [14]. Such discovery probably
requires to be along the path in order to be sniff the context tag requires to be along the path in order to be sniff the context tag
value. The result is that through this technique, the Shim6 value. The result is that through this technique, the Shim6
protocol is protected against off-path attackers. protocol is protected against off-path attackers.
16.1. Interaction with IPsec 16.1. Interaction with IPSec
The Shim6 sub-layer can be implemented either below IPsec sublayer, Shim6 has two modes of processing data packets. If the ULID pair is
or above the IPsec sub-layer, or both. (The latter can occur when as well the locator pair being used, then the data packet is not
e.g., IPsec is used both end-to-end as well as for IPsec tunnels.) modified by Shim6. In this case, the interaction with IPSec is
exactly the same as if the Shim6 layer was not present in the host.
In a "bump-in-the-stack" (BITS) IPsec implementation, IPsec is If the ULID pair differs from the current locator pair for that Shim6
implemented "underneath" an existing implementation of an IP protocol context, then Shim6 will take the data packet, replace the ULIDs
stack, between the native IP and the local network drivers. In that contained in the IP source and destination address fields by the
case it is not possible to make IPsec benefit from the failover current locator pair and add the Shim6 extension with the
capabilities of shim6; when shim6 fails over to a different locator correspondent Context Tag. In this case, as it is mentioned in
pair then the BITS IPsec would end up using a different (and possibly section 1.6,, Shim6 conceptually works as a tunnel mechanism where
establish a new) security association for that pair of IP addresses. the inner header contains the ULID and the outer header contains the
Same thing applies to a "bump-in-the-wire" (BITW) IPsec locators. The main difference being that the inner header is
implementation. In those cases shim6 and IPsec still work, but it is "compressed" and a compression tag, namely the Context tag, is added
less efficient to have to use separate security associations as a to decompress the inner header at the receiving end.
result of a shim6 failover.
In order for a BITS and BITW IPsec implementation on the node as well In this case, the interaction between IPSec and Shim6 is then similar
as a security gateway to be able to look at the same selectors before to the interaction between IPSec and a tunnel mechanism. When the
and after a failover, their implementation needs to skip the SHIM6 packet is generated by the upper layer protocol is passed to the IP
layer containing the ULIDs in the IP source and destination field.
IPSec is then applied to this packet. Then, the packet is passed to
the Shim6 sub-layer, which "encapsulates" the received packet and
includes a new IP header containing the locator pair in the IP source
and destination field. This new IP packet is in turn passed to IPSec
for processing, just as in the case of a tunnel. This can be viewed
as if IPSec is located both above and below the Shim6 sublayer and
that IPSec policies apply both to ULIDs and locators.
When IPSec processed the packet after the Shim6 sublayer has
processed it i.e. the packet carrying the locators in the IP source
and destination address field, the Shim6 sublayer may have added the
Shim6 extension header. In that case, IPSec needs to skip the Shim6
extension header to find the selectors for the next layer protocols extension header to find the selectors for the next layer protocols
(e.g., TCP, UDP, Stream Control Transmission Protocol (SCTP)) (e.g., TCP, UDP, Stream Control Transmission Protocol (SCTP))
When the Shim6 sub-layer is implemented below the IPsec sub-layer When a packet is received at the other end, it is processed based on
within the IP layer we avoid any extra IPsec work due to locator the order of the extension headers. Thus if an ESP or AH header
changes, but the implementation needs to make sure that the locator precedes a Shim6 header that determines the order. Shim6 introduces
changes doesn't cause any violations of the inteded IPsec policy. It the need to do policy checks, analogous to how they are done for
is easiest to explain this issue using an example: tunnels, when Shim6 receives a packet a the ULID pair for the packet
is not identical to the locator pair in the packet.
o Assume a pair of hosts, A and B, in different parts of a company.
The hosts do not implement shim6.
o H1 has to IP addresses IP1(A) and IP2(A). Ditto IP1(B) and
IP2(B).
o The routing and firewalls used might be setup so that the path
between IP1(A) and IP1(B) uses a communication path that is
internal to the company. The path between IP2(A) and IP2(B) might
be a fallback path where packets are sent over the public
Internet.
o In such a case it might make sense to have an IPsec policy on A
and B that all packets between IP1(A) and IP1(B) to be in the
clear while packets between IP2(A) and IP2(B) must be encrypted.
Should we introduce the shim below ESP/AH on host A and B then
potentially we could have Ls(A) include IP1(A) and IP2(B) and
likewise for B. This means that some communication might start out
between the ULID pair IP1(A) and IP1(B), and IPsec will see those
ULIDs and, based on the policy, send things in the clear. Should
there be a failure then the shim, transparently to IPsec, might fail
over to using the locator pair IP2(A),IP2(B) while still sending the
packets in the clear. That MUST be avoided.
This implies that when the shim forms a locator set for the host it
MUST NOT include locators for which there exists any differences in
the IPsec policy. And since the shim is independent of any higher
level selectors (protocols, port numbers, ICMP fields), this check
for differences must treat those fields as wildcards. This IPx(A)
and IPy(A) MUST NOT be included in the same locator set if there
exists any IPsec policy in the SPD onthe host that is different
should the local address change between IPx(A) and IPy(A).
This check MUST be performed for the locators sets that are used
locally as well as the locator sets that are sent to the peer in the
shim6 control messages. In the case that there are such differences
it might make sense to form different locator sets. In the above
example should host A have multiple addresses that can be routed over
the public Internet it can form a locator set with those and use that
locator set for communication that uses a ULID that belongs to the
set.
The notion of having separate locator sets that have different
security properties is useful in cases that does not involve IPsec.
For instance, a firewall which has a black network interface and a
red network interface, each having some set of assigned IP addresses,
SHOULD form a Lblacks(local) and a Lreds(local) so that the shim
doesn't attempt to use a red locator assigned to the host for a
context pair that has a local black ULID, and vice versa.
The same constraint applies to shim6 hosts which have interfaces
attached to networks where there are different security
considerations, for instance a host with some interfaces attached to
the public Internet and some interfaces attached to an intranet.
16.2. Residual Threats 16.2. Residual Threats
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 105, line 13 skipping to change at page 103, line 13
+------------+--------------------------------------------+ +------------+--------------------------------------------+
18. Acknowledgements 18. Acknowledgements
Over the years many people active in the multi6 and shim6 WGs have Over the years many people active in the multi6 and shim6 WGs have
contributed ideas a suggestions that are reflected in this contributed ideas a suggestions that are reflected in this
specification. Special thanks to the careful comments from Sam specification. Special thanks to the careful comments from Sam
Hartman, Cullen Jennings, Magnus Nystrom, Stephen Kent, Geoff Huston, Hartman, Cullen Jennings, Magnus Nystrom, Stephen Kent, Geoff Huston,
Shinta Sugimoto, Pekka Savola, Dave Meyer, Deguang Le, Jari Arkko, Shinta Sugimoto, Pekka Savola, Dave Meyer, Deguang Le, Jari Arkko,
Iljitsch van Beijnum, Jim Bound, Brian Carpenter, Sebastien Barre, Iljitsch van Beijnum, Jim Bound, Brian Carpenter, Sebastien Barre,
Matthijs Mekking, Dave Thaler, Bob Braden Wesley Eddy and Tom Matthijs Mekking, Dave Thaler, Bob Braden Wesley Eddy, Pari Eronen
Henderson on earlier versions of this document. and Tom Henderson on earlier versions of this document.
Appendix A. Possible Protocol Extensions 19. Appendix: Possible Protocol Extensions
During the development of this protocol, several issues have been During the development of this protocol, several issues have been
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
single-homed, and cope with a site's ISPs that do ingress single-homed, and cope with a site's ISPs that do ingress
skipping to change at page 108, line 5 skipping to change at page 106, line 5
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 [16]. initial draft on this topic [16].
Appendix B. Simplified STATE Machine 20. Appendix: 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 113, line 28 skipping to change at page 111, line 28
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| Trigger | Action | | Trigger | Action |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| Wait for | Go to IDLE | | Wait for | Go to IDLE |
| ICMP_HOLDDOWN_TIME | | | ICMP_HOLDDOWN_TIME | |
| | | | | |
| Any packet | Process as in IDLE | | Any packet | Process as in IDLE |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
Appendix B.1. Simplified STATE Machine diagram 20.1. Simplified STATE Machine diagram
Timeout/Null +------------+ Timeout/Null +------------+
I1/R1 +------------------| NO SUPPORT | I1/R1 +------------------| NO SUPPORT |
Payload or Control/R1bis | +------------+ Payload or Control/R1bis | +------------+
+---------+ | ^ +---------+ | ^
| | | ICMP Error/Null| | | | ICMP Error/Null|
| V V | | V V |
+-----------------+ Timeout/Null +----------+ | +-----------------+ Timeout/Null +----------+ |
| |<---------------| E-FAILED | | | |<---------------| E-FAILED | |
+-| IDLE | +----------+ | +-| IDLE | +----------+ |
I2 or I2bis/R2 | | | ^ | I2 or I2bis/R2 | | | ^ |
skipping to change at page 115, line 5 skipping to change at page 113, line 5
| | R1 or R1bis/Null | | | R1 or R1bis/Null |
| +-------+ (Timeout#>Max)/I1 | | +-------+ (Timeout#>Max)/I1 |
| R2/Null| +------------------------------------------+ | R2/Null| +------------------------------------------+
| V | | V |
| +-------------------+ | +-------------------+
| | |<-+ (Timeout#<Max)/I2bis | | |<-+ (Timeout#<Max)/I2bis
+-------->| I2bis-SENT | | I1 or I2 or I2bis/R2 +-------->| I2bis-SENT | | I1 or I2 or I2bis/R2
R1bis/I2bis | |--+ R1 or R1bis/Null R1bis/I2bis | |--+ R1 or R1bis/Null
+-------------------+ Payload/I2bis +-------------------+ Payload/I2bis
Appendix C. Context Tag Reuse 21. Appendix: Context Tag Reuse
The Shim6 protocol doesn't have a mechanism for coordinated state The Shim6 protocol doesn't have a mechanism for coordinated state
removal between the peers, because such state removal doesn't seem to removal between the peers, because such state removal doesn't seem to
help given that a host can crash and reboot at any time. A result of help given that a host can crash and reboot at any time. A result of
this is that the protocol needs to be robust against a context tag this is that the protocol needs to be robust against a context tag
being reused for some other context. This section summarizes the being reused for some other context. This section summarizes the
different cases in which a tag can be reused, and how the recovery different cases in which a tag can be reused, and how the recovery
works. works.
The different cases are exemplified by the following case. Assume The different cases are exemplified by the following case. Assume
skipping to change at page 115, line 35 skipping to change at page 113, line 35
<A1, B2>. We've called this "Context Recovery" in this document. <A1, B2>. We've called this "Context Recovery" in this document.
o The context tag is reassigned to a context for a different ULID o The context tag is reassigned to a context for a different ULID
pair between the same to hosts, e.g., <A3, B3>. We've called this pair between the same to hosts, e.g., <A3, B3>. We've called this
"Context Confusion" in this document. "Context Confusion" in this document.
o The context tag is reassigned to a context between B and other o The context tag is reassigned to a context between B and other
host C, for instance for the ULID pair <C3, B2>. That is a form host C, for instance for the ULID pair <C3, B2>. That is a form
of three party context confusion. of three party context confusion.
Appendix C.1. Context Recovery 21.1. Context Recovery
This case is relatively simple, and is discussed in Section 7.5. The This case is relatively simple, and is discussed in Section 7.5. The
observation is that since the ULID pair is the same, when either A or observation is that since the ULID pair is the same, when either A or
B tries to establish the new context, A can keep the old context B tries to establish the new context, A can keep the old context
while B re-creates the context with the same context tag CT(B) = X. while B re-creates the context with the same context tag CT(B) = X.
Appendix C.2. Context Confusion 21.2. Context Confusion
This cases is a bit more complex, and is discussed in Section 7.6. This cases is a bit more complex, and is discussed in Section 7.6.
When the new context is created, whether A or B initiates it, host A When the new context is created, whether A or B initiates it, host A
can detect when it receives B's locator set (in the I2, or R2 can detect when it receives B's locator set (in the I2, or R2
message), that it ends up with two contexts to the same peer host message), that it ends up with two contexts to the same peer host
(overlapping Ls(peer) locator sets) that have the same context tag (overlapping Ls(peer) locator sets) that have the same context tag
CT(peer) = X. At this point in time host A can clear up any CT(peer) = X. At this point in time host A can clear up any
possibility of causing confusion by not using the old context to send possibility of causing confusion by not using the old context to send
any more packets. It either just discards the old context (it might any more packets. It either just discards the old context (it might
not be used by any ULP traffic, since B had discarded it), or it not be used by any ULP traffic, since B had discarded it), or it
recreates a different context for the old ULID pair (<A1, B2>), for recreates a different context for the old ULID pair (<A1, B2>), for
which B will assign a unique CT(B) as part of the normal context which B will assign a unique CT(B) as part of the normal context
establishment mechanism. establishment mechanism.
Appendix C.3. Three Party Context Confusion 21.3. Three Party Context Confusion
The third case does not have a place where the old state on A can be The third case does not have a place where the old state on A can be
verified, since the new context is established between B and C. Thus verified, since the new context is established between B and C. Thus
when B receives payload extension headers with X as the context tag, when B receives payload extension headers with X as the context tag,
it will find the context for <C3, B2>, hence rewrite the packets to it will find the context for <C3, B2>, hence rewrite the packets to
have C3 in the source address field and B2 in the destination address have C3 in the source address field and B2 in the destination address
field before passing them up to the ULP. This rewriting is correct field before passing them up to the ULP. This rewriting is correct
when the packets are in fact sent by host C, but if host A ever when the packets are in fact sent by host C, but if host A ever
happens to send a packet using the old context, then the ULP on A happens to send a packet using the old context, then the ULP on A
sends a packet with ULIDs <A1, B2> and the packet arrives at the ULP sends a packet with ULIDs <A1, B2> and the packet arrives at the ULP
skipping to change at page 116, line 41 skipping to change at page 114, line 41
for very long. The unreachability detection on host A will kick in, for very long. The unreachability detection on host A will kick in,
because it does not see any return traffic (payload or Keepalive because it does not see any return traffic (payload or Keepalive
messages) for the context. This will result in host A sending Probe messages) for the context. This will result in host A sending Probe
messages to host B to find a working locator pair. The effect of messages to host B to find a working locator pair. The effect of
this is that host B will notice that it does not have a context for this is that host B will notice that it does not have a context for
the ULID pair <A1, B2> and CT(B) = X, which will make host B send an the ULID pair <A1, B2> and CT(B) = X, which will make host B send an
R1bis packet to re-establish that context. The re-established R1bis packet to re-establish that context. The re-established
context, just like in the previous section, will get a unique CT(B) context, just like in the previous section, will get a unique CT(B)
assigned by host B, thus there will no longer be any confusion. assigned by host B, thus there will no longer be any confusion.
Appendix C.4. Summary 21.4. Summary
In summary, there are cases where a context tag might be reused while In summary, there are cases where a context tag might be reused while
some peer retains the state, but the protocol can recover from it. some peer retains the state, but the protocol can recover from it.
The probability of these events is low given the 47 bit context tag The probability of these events is low given the 47 bit context tag
size. However, it is important that these recovery mechanisms be size. However, it is important that these recovery mechanisms be
tested. Thus during development and testing it is recommended that tested. Thus during development and testing it is recommended that
implementations not use the full 47 bit space, but instead keep e.g. implementations not use the full 47 bit space, but instead keep e.g.
the top 40 bits as zero, only leaving the host with 128 unique the top 40 bits as zero, only leaving the host with 128 unique
context tags. This will help test the recovery mechanisms. context tags. This will help test the recovery mechanisms.
Appendix D. Design Alternatives 22. Appendix: Design Alternatives
This document has picked a certain set of design choices in order to This document has picked a certain set of design choices in order to
try to work out a bunch of the details, and stimulate discussion. try to work out a bunch of the details, and stimulate discussion.
But as has been discussed on the mailing list, there are other But as has been discussed on the mailing list, there are other
choices that make sense. This appendix tries to enumerate some choices that make sense. This appendix tries to enumerate some
alternatives. alternatives.
Appendix D.1. Context granularity 22.1. Context granularity
Over the years various suggestions have been made whether the shim Over the years various suggestions have been made whether the shim
should, even if it operates at the IP layer, be aware of ULP should, even if it operates at the IP layer, be aware of ULP
connections and sessions, and as a result be able to make separate connections and sessions, and as a result be able to make separate
shim contexts for separate ULP connections and sessions. A few shim contexts for separate ULP connections and sessions. A few
different options have been discussed: different options have been discussed:
o Each ULP connection maps to its own shim context. o Each ULP connection maps to its own shim context.
o The shim is unaware of the ULP notion of connections and just o The shim is unaware of the ULP notion of connections and just
skipping to change at page 117, line 45 skipping to change at page 115, line 45
that want different communication to use different locator pairs, for that want different communication to use different locator pairs, for
instance for quality or cost reasons. instance for quality or cost reasons.
The protocol has a shim which operates with host-level granularity The protocol has a shim which operates with host-level granularity
(strictly speaking, with ULID-pair granularity, to be able to (strictly speaking, with ULID-pair granularity, to be able to
amortize the context establishment over multiple ULP connections. amortize the context establishment over multiple ULP connections.
This is combined with the ability for shim-aware ULPs to request This is combined with the ability for shim-aware ULPs to request
context forking so that different ULP traffic can use different context forking so that different ULP traffic can use different
locator pairs. locator pairs.
Appendix D.2. Demultiplexing of data packets in Shim6 communications 22.2. Demultiplexing of data packets in Shim6 communications
Once a ULID-pair context is established between two hosts, packets Once a ULID-pair context is established between two hosts, packets
may carry locators that differ from the ULIDs presented to the ULPs may carry locators that differ from the ULIDs presented to the ULPs
using the established context. One of main functions of the Shim6 using the established context. One of main functions of the Shim6
layer is to perform the mapping between the locators used to forward layer is to perform the mapping between the locators used to forward
packets through the network and the ULIDs presented to the ULP. In packets through the network and the ULIDs presented to the ULP. In
order to perform that translation for incoming packets, the Shim6 order to perform that translation for incoming packets, the Shim6
layer needs to first identify which of the incoming packets need to layer needs to first identify which of the incoming packets need to
be translated and then perform the mapping between locators and ULIDs be translated and then perform the mapping between locators and ULIDs
using the associated context. Such operation is called using the associated context. Such operation is called
skipping to change at page 118, line 35 skipping to change at page 116, line 35
packet to determine the shim context to be used to perform the packet to determine the shim context to be used to perform the
operation. operation.
Two mechanisms for carrying the context tag information have been Two mechanisms for carrying the context tag information have been
considered in depth during the shim protocol design. Those carrying considered in depth during the shim protocol design. Those carrying
the context tag in the flow label field of the IPv6 header and the the context tag in the flow label field of the IPv6 header and the
usage of a new extension header to carry the context tag. In this usage of a new extension header to carry the context tag. In this
appendix we will describe the pros and cons of each approach and appendix we will describe the pros and cons of each approach and
justify the selected option. justify the selected option.
Appendix D.2.1. Flow-label 22.2.1. Flow-label
A possible approach is to carry the context tag in the Flow Label A possible approach is to carry the context tag in the Flow Label
field of the IPv6 header. This means that when a Shim6 context is field of the IPv6 header. This means that when a Shim6 context is
established, a Flow Label value is associated with this context (and established, a Flow Label value is associated with this context (and
perhaps a separate flow label for each direction). perhaps a separate flow label for each direction).
The simplest approach that does this is to have the triple <Flow The simplest approach that does this is to have the triple <Flow
Label, Source Locator, Destination Locator> identify the context at Label, Source Locator, Destination Locator> identify the context at
the receiver. the receiver.
skipping to change at page 120, line 48 skipping to change at page 118, line 48
would be the preferred approach if the context tag is to be carried would be the preferred approach if the context tag is to be carried
in the Flow Label field. This is not only because it imposes the in the Flow Label field. This is not only because it imposes the
minimum constraints to the Flow Label allocation strategies, limiting minimum constraints to the Flow Label allocation strategies, limiting
the restrictions only to those packets that need to be translated by the restrictions only to those packets that need to be translated by
the shim, but also because Context Loss detection mechanisms greatly the shim, but also because Context Loss detection mechanisms greatly
benefit from the fact that shim data packets are identified as such, benefit from the fact that shim data packets are identified as such,
allowing the receiving end to identify if a shim context associated allowing the receiving end to identify if a shim context associated
to a received packet is suppose to exist, as it will be discussed in to a received packet is suppose to exist, as it will be discussed in
the Context Loss detection appendix below. the Context Loss detection appendix below.
Appendix D.2.2. Extension Header 22.2.2. Extension Header
Another approach, which is the one selected for this protocol, is to Another approach, which is the one selected for this protocol, is to
carry the context tag in a new Extension Header. These context tags carry the context tag in a new Extension Header. These context tags
are allocated by the receiving end during the Shim6 protocol initial are allocated by the receiving end during the Shim6 protocol initial
negotiation, implying that each context will have two context tags, negotiation, implying that each context will have two context tags,
one for each direction. Data packets will be demultiplexed using the one for each direction. Data packets will be demultiplexed using the
context tag carried in the Extension Header. This seems a clean context tag carried in the Extension Header. This seems a clean
approach since it does not overload existing fields. However, it approach since it does not overload existing fields. However, it
introduces additional overhead in the packet due to the additional introduces additional overhead in the packet due to the additional
header. The additional overhead introduced is 8 octets. However, it header. The additional overhead introduced is 8 octets. However, it
skipping to change at page 121, line 24 skipping to change at page 119, line 24
ULIDs do not require a context tag, since no rewriting is necessary ULIDs do not require a context tag, since no rewriting is necessary
at the receiver. This approach would reduce the overhead, because at the receiver. This approach would reduce the overhead, because
the additional header is only required after a failure. On the other the additional header is only required after a failure. On the other
hand, this approach would cause changes in the available MTU for some hand, this approach would cause changes in the available MTU for some
packets, since packets that include the Extension Header will have an packets, since packets that include the Extension Header will have an
MTU 8 octets shorter. However, path changes through the network can MTU 8 octets shorter. However, path changes through the network can
result in different MTU in any case, thus having a locator change, result in different MTU in any case, thus having a locator change,
which implies a path change, affect the MTU doesn't introduce any new which implies a path change, affect the MTU doesn't introduce any new
issues. issues.
Appendix D.3. Context Loss Detection 22.3. Context Loss Detection
In this appendix we will present different approaches considered to In this appendix we will present different approaches considered to
detect context loss and potential context recovery strategies. The detect context loss and potential context recovery strategies. The
scenario being considered is the following: Node A and Node B are scenario being considered is the following: Node A and Node B are
communicating using IPA1 and IPB1. Sometime later, a shim context is communicating using IPA1 and IPB1. Sometime later, a shim context is
established between them, with IPA1 and IPB1 as ULIDs and established between them, with IPA1 and IPB1 as ULIDs and
IPA1,...,IPAn and IPB1,...,IPBm as locator set respectively. IPA1,...,IPAn and IPB1,...,IPBm as locator set respectively.
It may happen, that later on, one of the hosts, e.g. Host A loses It may happen, that later on, one of the hosts, e.g. Host A loses
the shim context. The reason for this can be that Host A has a more the shim context. The reason for this can be that Host A has a more
skipping to change at page 123, line 42 skipping to change at page 121, line 42
exchange and at this point time may be critical since we are exchange and at this point time may be critical since we are
reestablishing a context that is currently needed (because context reestablishing a context that is currently needed (because context
loss detection may occur after a failure). So, another option, which loss detection may occur after a failure). So, another option, which
is the one used in this protocol, is to replace the error message by is the one used in this protocol, is to replace the error message by
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 22.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 [14]. The goal in terms of of redirection attacks as described in [14]. 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
skipping to change at page 126, line 28 skipping to change at page 124, line 28
So, the design decision adopted was that both mechanisms HBA and CGA So, the design decision adopted was that both mechanisms HBA and CGA
are supported, so that when only stable address sets are required, are supported, so that when only stable address sets are required,
the nodes can benefit from the low computational cost offered by HBA the nodes can benefit from the low computational cost offered by HBA
while when dynamic locator sets are required, this can be achieved while when dynamic locator sets are required, this can be achieved
through CGAs with an additional cost. Moreover, because HBAs are through CGAs with an additional cost. Moreover, because HBAs are
defined as a CGA extension, the addresses available in a node can defined as a CGA extension, the addresses available in a node can
simultaneously be CGAs and HBAs, allowing the usage of the HBA and simultaneously be CGAs and HBAs, allowing the usage of the HBA and
CGA functionality when needed without requiring a change in the CGA functionality when needed without requiring a change in the
addresses used. addresses used.
Appendix D.5. ULID-pair context establishment exchange 22.5. ULID-pair context establishment exchange
Two options were considered for the ULID-pair context establishment Two options were considered for the ULID-pair context establishment
exchange: a 2-way handshake and a 4-way handshake. exchange: a 2-way handshake and a 4-way handshake.
A key goal for the design of this exchange was that protection A key goal for the design of this exchange was that protection
against DoS attacks. The attack under consideration was basically a against DoS attacks. The attack under consideration was basically a
situation where an attacker launches a great amount of ULID-pair situation where an attacker launches a great amount of ULID-pair
establishment request packets, exhausting victim's resources, similar establishment request packets, exhausting victim's resources, similar
to TCP SYN flooding attacks. to TCP SYN flooding attacks.
skipping to change at page 127, line 29 skipping to change at page 125, line 29
should be noted, that because this is 2-way exchange, it is not should be noted, that because this is 2-way exchange, it is not
possible to use the number of half open sessions (as in TCP) to possible to use the number of half open sessions (as in TCP) to
detect an ongoing attack and different heuristics need to be detect an ongoing attack and different heuristics need to be
considered. considered.
The design decision taken was that considering the current impact of The design decision taken was that considering the current impact of
DoS attacks and the low impact of the 4-way exchange in the shim DoS attacks and the low impact of the 4-way exchange in the shim
protocol thanks to the deferred context establishment capability, a protocol thanks to the deferred context establishment capability, a
4-way exchange would be adopted for the base protocol. 4-way exchange would be adopted for the base protocol.
Appendix D.6. Updating locator sets 22.6. Updating locator sets
There are two possible approaches to the addition and removal of There are two possible approaches to the addition and removal of
locators: atomic and differential approaches. The atomic approach locators: atomic and differential approaches. The atomic approach
essentially send the complete locators set each time that a variation essentially send the complete locators set each time that a variation
in the locator set occurs. The differential approach send the in the locator set occurs. The differential approach send the
differences between the existing locator set and the new one. The differences between the existing locator set and the new one. The
atomic approach imposes additional overhead, since all the locator atomic approach imposes additional overhead, since all the locator
set has to be exchanged each time while the differential approach set has to be exchanged each time while the differential approach
requires re-synchronization of both ends through changes i.e. that requires re-synchronization of both ends through changes i.e. that
both ends have the same idea about what the current locator set is. both ends have the same idea about what the current locator set is.
Because of the difficulties imposed by the synchronization Because of the difficulties imposed by the synchronization
requirement, the atomic approach was selected. requirement, the atomic approach was selected.
Appendix D.7. State Cleanup 22.7. State Cleanup
There are essentially two approaches for discarding an existing state There are essentially two approaches for discarding an existing state
about locators, keys and identifiers of a correspondent node: a about locators, keys and identifiers of a correspondent node: a
coordinated approach and an unilateral approach. coordinated approach and an unilateral approach.
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,
skipping to change at page 130, line 5 skipping to change at page 128, line 5
coordinated approach using a CLOSE/CLOSE ACK exchange, there is still coordinated approach using a CLOSE/CLOSE ACK exchange, there is still
the possibility of a host rebooting without having the time to the possibility of a host rebooting without having the time to
perform the CLOSE exchange. So, it is true that the coordinated perform the CLOSE exchange. So, it is true that the coordinated
approach eliminates the possibility of a context confusion situation approach eliminates the possibility of a context confusion situation
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 23. Appendix: 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-11:
o Reworded the placement of shim6 w.r.t. IPsec
o Updated text on the IPsec considerations
The following changes have been made since draft-ietf-shim6-proto-10: The following changes have been made since draft-ietf-shim6-proto-10:
o Reworded the placement of shim6 w.r.t. IPsec o Reworded the placement of shim6 w.r.t. IPsec
o Updated text on the IPsec considerations o Updated text on the IPsec considerations
The following changes have been made since draft-ietf-shim6-proto-09: The following changes have been made since draft-ietf-shim6-proto-09:
o Explicitly added a reference to the applicability document o Explicitly added a reference to the applicability document
skipping to change at page 137, line 5 skipping to change at page 135, line 5
context is forked, that is different ULP messages are sent over context is forked, that is different ULP messages are sent over
different locator pairs, things are a lot easier if there is only different locator pairs, things are a lot easier if there is only
one current locator pair used for each context. Thus the forking one current locator pair used for each context. Thus the forking
of the context is now causing a new context to be established for of the context is now causing a new context to be established for
the same ULID; the new context having a new context tag. The the same ULID; the new context having a new context tag. The
original context is referred to as the "default" context for the original context is referred to as the "default" context for the
ULID pair. ULID pair.
o Added more background material and textual descriptions. o Added more background material and textual descriptions.
19. References 24. References
19.1. Normative References 24.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] Aura, T., "Cryptographically Generated Addresses (CGA)", [2] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
[3] Bagnulo, M., "Hash Based Addresses (HBA)", [3] Bagnulo, M., "Hash Based Addresses (HBA)",
draft-ietf-shim6-hba-05 (work in progress), December 2007. draft-ietf-shim6-hba-05 (work in progress), December 2007.
[4] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair [4] 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-13 (work in progress), draft-ietf-shim6-failure-detection-13 (work in progress),
June 2008. June 2008.
19.2. Informative References 24.2. Informative References
[5] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [5] 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.
[6] Ferguson, P. and D. Senie, "Network Ingress Filtering: [6] 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.
[7] Draves, R., "Default Address Selection for Internet Protocol [7] Draves, R., "Default Address Selection for Internet Protocol
 End of changes. 39 change blocks. 
252 lines changed or deleted 190 lines changed or added

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