draft-ietf-shim6-proto-10.txt   draft-ietf-shim6-proto-11.txt 
SHIM6 WG E. Nordmark SHIM6 WG E. Nordmark
Internet-Draft Sun Microsystems Internet-Draft Sun Microsystems
Expires: August 17, 2008 M. Bagnulo Intended status: Standards Track M. Bagnulo
UC3M Expires: June 18, 2009 UC3M
February 14, 2008 December 15, 2008
Shim6: Level 3 Multihoming Shim Protocol for IPv6 Shim6: Level 3 Multihoming Shim Protocol for IPv6
draft-ietf-shim6-proto-10.txt draft-ietf-shim6-proto-11.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering 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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 August 17, 2008. This Internet-Draft will expire on June 18, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2008 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
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
properties, without assuming that a multihomed site will have a properties, without assuming that a multihomed site will have a
provider independent IPv6 address prefix which is announced in the provider independent IPv6 address prefix which is announced in the
global IPv6 routing table. The hosts in a site which has multiple global IPv6 routing table. The hosts in a site which has multiple
provider allocated IPv6 address prefixes, will use the Shim6 protocol provider allocated IPv6 address prefixes, will use the Shim6 protocol
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 . . . . . . . . . . . . . . . . . . . . . . . . . 13 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 13 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 14
2.2. Notational Conventions . . . . . . . . . . . . . . . . . 16 2.2. Notational Conventions . . . . . . . . . . . . . . . . . 17
3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3. Conceptual . . . . . . . . . . . . . . . . . . . . . . . 17
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 19 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Context Tags . . . . . . . . . . . . . . . . . . . . . . 21 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 20
4.2. Context Forking . . . . . . . . . . . . . . . . . . . . . 21 4.1. Context Tags . . . . . . . . . . . . . . . . . . . . . . 22
4.3. API Extensions . . . . . . . . . . . . . . . . . . . . . 22 4.2. Context Forking . . . . . . . . . . . . . . . . . . . . . 22
4.4. Securing Shim6 . . . . . . . . . . . . . . . . . . . . . 22 4.3. API Extensions . . . . . . . . . . . . . . . . . . . . . 23
4.5. Overview of Shim Control Messages . . . . . . . . . . . . 23 4.4. Securing Shim6 . . . . . . . . . . . . . . . . . . . . . 23
4.6. Extension Header Order . . . . . . . . . . . . . . . . . 24 4.5. Overview of Shim Control Messages . . . . . . . . . . . . 24
5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 26 4.6. Extension Header Order . . . . . . . . . . . . . . . . . 25
5.1. Common Shim6 Message Format . . . . . . . . . . . . . . . 26 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 27
5.2. Payload Extension Header Format . . . . . . . . . . . . . 27 5.1. Common Shim6 Message Format . . . . . . . . . . . . . . . 27
5.3. Common Shim6 Control header . . . . . . . . . . . . . . . 27 5.2. Payload Extension Header Format . . . . . . . . . . . . . 28
5.4. I1 Message Format . . . . . . . . . . . . . . . . . . . . 29 5.3. Common Shim6 Control header . . . . . . . . . . . . . . . 28
5.5. R1 Message Format . . . . . . . . . . . . . . . . . . . . 30 5.4. I1 Message Format . . . . . . . . . . . . . . . . . . . . 30
5.6. I2 Message Format . . . . . . . . . . . . . . . . . . . . 32 5.5. R1 Message Format . . . . . . . . . . . . . . . . . . . . 31
5.7. R2 Message Format . . . . . . . . . . . . . . . . . . . . 34 5.6. I2 Message Format . . . . . . . . . . . . . . . . . . . . 33
5.8. R1bis Message Format . . . . . . . . . . . . . . . . . . 35 5.7. R2 Message Format . . . . . . . . . . . . . . . . . . . . 35
5.9. I2bis Message Format . . . . . . . . . . . . . . . . . . 37 5.8. R1bis Message Format . . . . . . . . . . . . . . . . . . 36
5.10. Update Request Message Format . . . . . . . . . . . . . . 39 5.9. I2bis Message Format . . . . . . . . . . . . . . . . . . 38
5.11. Update Acknowledgement Message Format . . . . . . . . . . 40 5.10. Update Request Message Format . . . . . . . . . . . . . . 40
5.12. Keepalive Message Format . . . . . . . . . . . . . . . . 41 5.11. Update Acknowledgement Message Format . . . . . . . . . . 41
5.13. Probe Message Format . . . . . . . . . . . . . . . . . . 42 5.12. Keepalive Message Format . . . . . . . . . . . . . . . . 42
5.14. Error Message Format . . . . . . . . . . . . . . . . . . 42 5.13. Probe Message Format . . . . . . . . . . . . . . . . . . 43
5.15. Option Formats . . . . . . . . . . . . . . . . . . . . . 43 5.14. Error Message Format . . . . . . . . . . . . . . . . . . 43
5.15.1. Responder Validator Option Format . . . . . . . . . 46 5.15. Option Formats . . . . . . . . . . . . . . . . . . . . . 44
5.15.2. Locator List Option Format . . . . . . . . . . . . . 46 5.15.1. Responder Validator Option Format . . . . . . . . . 47
5.15.3. Locator Preferences Option Format . . . . . . . . . 48 5.15.2. Locator List Option Format . . . . . . . . . . . . . 47
5.15.4. CGA Parameter Data Structure Option Format . . . . . 50 5.15.3. Locator Preferences Option Format . . . . . . . . . 49
5.15.5. CGA Signature Option Format . . . . . . . . . . . . 50 5.15.4. CGA Parameter Data Structure Option Format . . . . . 51
5.15.6. ULID Pair Option Format . . . . . . . . . . . . . . 51 5.15.5. CGA Signature Option Format . . . . . . . . . . . . 51
5.15.7. Forked Instance Identifier Option Format . . . . . . 52 5.15.6. ULID Pair Option Format . . . . . . . . . . . . . . 52
5.15.8. Keepalive Timeout Option Format . . . . . . . . . . 52 5.15.7. Forked Instance Identifier Option Format . . . . . . 53
6. Conceptual Model of a Host . . . . . . . . . . . . . . . . . 53 5.15.8. Keepalive Timeout Option Format . . . . . . . . . . 53
6.1. Conceptual Data Structures . . . . . . . . . . . . . . . 53 6. Conceptual Model of a Host . . . . . . . . . . . . . . . . . 54
6.2. Context STATES . . . . . . . . . . . . . . . . . . . . . 55 6.1. Conceptual Data Structures . . . . . . . . . . . . . . . 54
7. Establishing ULID-Pair Contexts . . . . . . . . . . . . . . . 57 6.2. Context STATES . . . . . . . . . . . . . . . . . . . . . 56
7.1. Uniqueness of Context Tags . . . . . . . . . . . . . . . 57 7. Establishing ULID-Pair Contexts . . . . . . . . . . . . . . . 58
7.2. Locator Verification . . . . . . . . . . . . . . . . . . 57 7.1. Uniqueness of Context Tags . . . . . . . . . . . . . . . 58
7.3. Normal context establishment . . . . . . . . . . . . . . 58 7.2. Locator Verification . . . . . . . . . . . . . . . . . . 58
7.4. Concurrent context establishment . . . . . . . . . . . . 58 7.3. Normal context establishment . . . . . . . . . . . . . . 59
7.5. Context recovery . . . . . . . . . . . . . . . . . . . . 60 7.4. Concurrent context establishment . . . . . . . . . . . . 59
7.6. Context confusion . . . . . . . . . . . . . . . . . . . . 62 7.5. Context recovery . . . . . . . . . . . . . . . . . . . . 61
7.7. Sending I1 messages . . . . . . . . . . . . . . . . . . . 63 7.6. Context confusion . . . . . . . . . . . . . . . . . . . . 63
7.8. Retransmitting I1 messages . . . . . . . . . . . . . . . 64 7.7. Sending I1 messages . . . . . . . . . . . . . . . . . . . 64
7.9. Receiving I1 messages . . . . . . . . . . . . . . . . . . 64 7.8. Retransmitting I1 messages . . . . . . . . . . . . . . . 65
7.10. Sending R1 messages . . . . . . . . . . . . . . . . . . . 65 7.9. Receiving I1 messages . . . . . . . . . . . . . . . . . . 65
7.10.1. Generating the R1 Validator . . . . . . . . . . . . 66 7.10. Sending R1 messages . . . . . . . . . . . . . . . . . . . 66
7.11. Receiving R1 messages and sending I2 messages . . . . . . 66 7.10.1. Generating the R1 Validator . . . . . . . . . . . . 67
7.12. Retransmitting I2 messages . . . . . . . . . . . . . . . 67 7.11. Receiving R1 messages and sending I2 messages . . . . . . 67
7.13. Receiving I2 messages . . . . . . . . . . . . . . . . . . 68 7.12. Retransmitting I2 messages . . . . . . . . . . . . . . . 68
7.14. Sending R2 messages . . . . . . . . . . . . . . . . . . . 69 7.13. Receiving I2 messages . . . . . . . . . . . . . . . . . . 69
7.15. Match for Context Confusion . . . . . . . . . . . . . . . 70 7.14. Sending R2 messages . . . . . . . . . . . . . . . . . . . 70
7.16. Receiving R2 messages . . . . . . . . . . . . . . . . . . 70 7.15. Match for Context Confusion . . . . . . . . . . . . . . . 71
7.17. Sending R1bis messages . . . . . . . . . . . . . . . . . 71 7.16. Receiving R2 messages . . . . . . . . . . . . . . . . . . 71
7.17.1. Generating the R1bis Validator . . . . . . . . . . . 72 7.17. Sending R1bis messages . . . . . . . . . . . . . . . . . 72
7.18. Receiving R1bis messages and sending I2bis messages . . . 72 7.17.1. Generating the R1bis Validator . . . . . . . . . . . 73
7.19. Retransmitting I2bis messages . . . . . . . . . . . . . . 73 7.18. Receiving R1bis messages and sending I2bis messages . . . 73
7.20. Receiving I2bis messages and sending R2 messages . . . . 74 7.19. Retransmitting I2bis messages . . . . . . . . . . . . . . 74
8. Handling ICMP Error Messages . . . . . . . . . . . . . . . . 76 7.20. Receiving I2bis messages and sending R2 messages . . . . 75
9. Teardown of the ULID-Pair Context . . . . . . . . . . . . . . 79 8. Handling ICMP Error Messages . . . . . . . . . . . . . . . . 77
10. Updating the Peer . . . . . . . . . . . . . . . . . . . . . . 80 9. Teardown of the ULID-Pair Context . . . . . . . . . . . . . . 80
10.1. Sending Update Request messages . . . . . . . . . . . . . 80 10. Updating the Peer . . . . . . . . . . . . . . . . . . . . . . 81
10.2. Retransmitting Update Request messages . . . . . . . . . 80 10.1. Sending Update Request messages . . . . . . . . . . . . . 81
10.3. Newer Information While Retransmitting . . . . . . . . . 81 10.2. Retransmitting Update Request messages . . . . . . . . . 81
10.4. Receiving Update Request messages . . . . . . . . . . . . 81 10.3. Newer Information While Retransmitting . . . . . . . . . 82
10.5. Receiving Update Acknowledgement messages . . . . . . . . 83 10.4. Receiving Update Request messages . . . . . . . . . . . . 82
11. Sending ULP Payloads . . . . . . . . . . . . . . . . . . . . 85 10.5. Receiving Update Acknowledgement messages . . . . . . . . 84
11.1. Sending ULP Payload after a Switch . . . . . . . . . . . 85 11. Sending ULP Payloads . . . . . . . . . . . . . . . . . . . . 86
12. Receiving Packets . . . . . . . . . . . . . . . . . . . . . . 87 11.1. Sending ULP Payload after a Switch . . . . . . . . . . . 86
12.1. Receiving payload without extension headers . . . . . . . 87 12. Receiving Packets . . . . . . . . . . . . . . . . . . . . . . 88
12.2. Receiving Payload Extension Headers . . . . . . . . . . . 87 12.1. Receiving payload without extension headers . . . . . . . 88
12.3. Receiving Shim Control messages . . . . . . . . . . . . . 88 12.2. Receiving Payload Extension Headers . . . . . . . . . . . 88
12.4. Context Lookup . . . . . . . . . . . . . . . . . . . . . 88 12.3. Receiving Shim Control messages . . . . . . . . . . . . . 89
13. Initial Contact . . . . . . . . . . . . . . . . . . . . . . . 91 12.4. Context Lookup . . . . . . . . . . . . . . . . . . . . . 89
14. Protocol constants . . . . . . . . . . . . . . . . . . . . . 92 13. Initial Contact . . . . . . . . . . . . . . . . . . . . . . . 92
15. Implications Elsewhere . . . . . . . . . . . . . . . . . . . 93 14. Protocol constants . . . . . . . . . . . . . . . . . . . . . 93
15.1. Congestion Control Considerations . . . . . . . . . . . . 93 15. Implications Elsewhere . . . . . . . . . . . . . . . . . . . 94
15.2. Middle-boxes considerations . . . . . . . . . . . . . . . 93 15.1. Congestion Control Considerations . . . . . . . . . . . . 94
15.3. Operation and Management Considerations . . . . . . . . . 94 15.2. Middle-boxes considerations . . . . . . . . . . . . . . . 94
15.4. Other considerations . . . . . . . . . . . . . . . . . . 95 15.3. Operation and Management Considerations . . . . . . . . . 95
16. Security Considerations . . . . . . . . . . . . . . . . . . . 97 15.4. Other considerations . . . . . . . . . . . . . . . . . . 96
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 101 16. Security Considerations . . . . . . . . . . . . . . . . . . . 98
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 103 16.1. Interaction with IPsec . . . . . . . . . . . . . . . . . 99
Appendix A. Possible Protocol Extensions . . . . . . . . . . 104 16.2. Residual Threats . . . . . . . . . . . . . . . . . . . . 101
Appendix B. Simplified STATE Machine . . . . . . . . . . . . 106 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 103
Appendix B.1. Simplified STATE Machine diagram . . . . . . . . 111 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 105
Appendix C. Context Tag Reuse . . . . . . . . . . . . . . . . 113 Appendix A. Possible Protocol Extensions . . . . . . . . . . 106
Appendix C.1. Context Recovery . . . . . . . . . . . . . . . . 113 Appendix B. Simplified STATE Machine . . . . . . . . . . . . 108
Appendix C.2. Context Confusion . . . . . . . . . . . . . . . . 113 Appendix B.1. Simplified STATE Machine diagram . . . . . . . . 113
Appendix C.3. Three Party Context Confusion . . . . . . . . . . 114 Appendix C. Context Tag Reuse . . . . . . . . . . . . . . . . 115
Appendix D. Design Alternatives . . . . . . . . . . . . . . . 115 Appendix C.1. Context Recovery . . . . . . . . . . . . . . . . 115
Appendix D.1. Context granularity . . . . . . . . . . . . . . . 115 Appendix C.2. Context Confusion . . . . . . . . . . . . . . . . 115
Appendix C.3. Three Party Context Confusion . . . . . . . . . . 116
Appendix C.4. Summary . . . . . . . . . . . . . . . . . . . . . 116
Appendix D. Design Alternatives . . . . . . . . . . . . . . . 117
Appendix D.1. Context granularity . . . . . . . . . . . . . . . 117
Appendix D.2. Demultiplexing of data packets in Shim6 Appendix D.2. Demultiplexing of data packets in Shim6
communications . . . . . . . . . . . . . . . . . 115 communications . . . . . . . . . . . . . . . . . 117
Appendix D.2.1. Flow-label . . . . . . . . . . . . . . . . . . . 116 Appendix D.2.1. Flow-label . . . . . . . . . . . . . . . . . . . 118
Appendix D.2.2. Extension Header . . . . . . . . . . . . . . . . 118 Appendix D.2.2. Extension Header . . . . . . . . . . . . . . . . 120
Appendix D.3. Context Loss Detection . . . . . . . . . . . . . 119 Appendix D.3. Context Loss Detection . . . . . . . . . . . . . 121
Appendix D.4. Securing locator sets . . . . . . . . . . . . . . 121 Appendix D.4. Securing locator sets . . . . . . . . . . . . . . 123
Appendix D.5. ULID-pair context establishment exchange . . . . 124 Appendix D.5. ULID-pair context establishment exchange . . . . 126
Appendix D.6. Updating locator sets . . . . . . . . . . . . . . 125 Appendix D.6. Updating locator sets . . . . . . . . . . . . . . 127
Appendix D.7. State Cleanup . . . . . . . . . . . . . . . . . . 125 Appendix D.7. State Cleanup . . . . . . . . . . . . . . . . . . 127
Appendix E. Change Log . . . . . . . . . . . . . . . . . . . 128 Appendix E. Change Log . . . . . . . . . . . . . . . . . . . 130
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 135 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 137
19.1. Normative References . . . . . . . . . . . . . . . . . . 135 19.1. Normative References . . . . . . . . . . . . . . . . . . 137
19.2. Informative References . . . . . . . . . . . . . . . . . 135 19.2. Informative References . . . . . . . . . . . . . . . . . 137
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 137 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 139
Intellectual Property and Copyright Statements . . . . . . . . . 138
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 [11], 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
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 [4]. Addresses (HBA) as defined in [3].
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 [5]. This document allocates message types in a separate document [4]. 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 [15] through the combination of o Address the security threats in [14] through the combination of
the HBA/CGA approach specified in a separate document [4] and the HBA/CGA approach specified in a separate document [3] 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 [8]. Some extensions are address selection as specified in RFC 3484 [7]. 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 [9]. Underneath, and the Shim6 protocol is used, as outlined in [8]. 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 [18] for further discussion of the application unreachable. See [17] 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) [14], as ULIDs in a multihoming as Unique-Local Addresses (ULAs) [13], 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 [7] for unicast.) filtering [6] 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 [10], shim. This is quite a natural fit for protocols which use RTP [9],
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 9, line 42 skipping to change at page 9, line 42
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.
Layering AH and ESP above the multihoming shim means that for a For the relative layering of the shim and ESP/AH there are two
native implementation of IPsec, IPsec can be made to be unaware of choices.
locator changes the same way that transport protocols can be unaware.
A "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation is With a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation
layered in the same place as the application of IPsec in security as well as the case of IPsec communication between a host and a
gateways. In that case there might be separate security associations security gateway the layering naturally becomes shim6 over ESP/AH.
for different locators. 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, effectively the source locators, for different fragments. Thus, the multihoming shim
multihoming shim layer is placed between the IP endpoint sublayer, layer is placed between the IP endpoint sublayer, which handles
which handles fragmentation, reassembly, and IPsec, and the IP fragmentation, reassembly, and the IP routing sublayer, which selects
routing sublayer, which selects which next hop and interface to use which next hop and interface to use for sending out packets.
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
state, called ULID-pair context, per ULID pair (that is, applies to state, called ULID-pair context, per ULID pair (that is, applies to
all ULP connections between the ULID pair) in order to perform this all ULP connections between the ULID pair) in order to perform this
mapping. The mapping is performed consistently at the sender and the mapping. The mapping is performed consistently at the sender and the
receiver so that ULPs see packets that appear to be sent using ULIDs receiver so that ULPs see packets that appear to be sent using ULIDs
from end to end. This property is maintained even though the packets from end to end. This property is maintained even though the packets
travel through the network containing locators in the IP address travel through the network containing locators in the IP address
fields, and even though those locators may be changed by the fields, and even though those locators may be changed by the
skipping to change at page 11, line 17 skipping to change at page 11, line 42
correct ULIDs there is a need to include some "compression tag" in correct ULIDs there is a need to include some "compression tag" in
the data packets. This serves to indicate the correct context to use the data packets. This serves to indicate the correct context to use
for decompression when the locator pair in the packet is insufficient for decompression when the locator pair in the packet is insufficient
to uniquely identify the context. to uniquely identify the context.
There are different types of interactions between the Shim6 layer and There are different types of interactions between the Shim6 layer and
other protocols. Those intereactions are influenced by the usage of other protocols. Those intereactions are influenced by the usage of
the addresses that these other protocols do and the impact of the the addresses that these other protocols do and the impact of the
Shim6 mapping on these usages. A detailed analysis of the Shim6 mapping on these usages. A detailed analysis of the
interactions of different portocols, including SCTP, MIP and HIP can interactions of different portocols, including SCTP, MIP and HIP can
be found in [19]. Moreover, some applications may need to have a be found in [18]. Moreover, some applications may need to have a
richer interaction with the Shim6 sub-layer. In order to enable richer interaction with the Shim6 sub-layer. In order to enable
that, a API [23] has been defined to enable greater control and that, a API [22] has been defined to enable greater control and
information exchange for those applications that need it. information exchange for those applications that need it.
1.7. Traffic Engineering 1.7. Traffic Engineering
At the time of this writing it is not clear what requirements for At the time of this writing it is not clear what requirements for
traffic engineering make sense for the Shim6 protocol, since the traffic engineering make sense for the Shim6 protocol, since the
requirements must both result in some useful behavior as well as be requirements must both result in some useful behavior as well as be
implementable using a host-to-host locator agility mechanism like implementable using a host-to-host locator agility mechanism like
Shim6. Shim6.
skipping to change at page 15, line 36 skipping to change at page 16, 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 [4]. prefixes assigned to the host. See [3].
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 [2]. 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 [2], [4]. was computed. See [2], [3].
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. A host might form
different locators sets containing different subnets of the hosts IP
addresses. This is necessary in some cases for security reasons.
See Section 16.1.
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(A) is a context tag assigned by A. CT(A) is a context tag assigned by A.
STATE (in uppercase) refers to the the specific state of the state STATE (in uppercase) refers to the the specific state of the state
machine described in Section 6.2 machine described in Section 6.2
2.3. Conceptual
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 17, line 48 skipping to change at page 18, line 48
(node B in the previous paragraph) to select a source address that (node B in the previous paragraph) to select a source address that
corresponds to the operational egress, in order to pass the ISP's corresponds to the operational egress, in order to pass the ISP's
ingress filters. ingress filters.
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 The security of the Shim6 protocol relies on the usage of Hash Based
Addresses (HBA) [4] and/or Cryptographically Generated Addresses Addresses (HBA) [3] and/or Cryptographically Generated Addresses
(CGA) [2]. In the case that HBAs are used, all the 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 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 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 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 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 neither CGAs nor HBAs. It should be noted that it is perfectly
acceptable to run the Shim6 protocol between a host that has multiple acceptable to run the Shim6 protocol between a host that has multiple
locators and another host that has a single IP address. In this 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 case, the address of the host with a single address does not need to
be an HBA nor a CGA. 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 [8] and its extensions [9] work, then there is no action Selection [7] and its extensions [8] work, then there is no action
by the shim at this point in time. Any shim context establishment by the shim at this point in time. Any shim context 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
skipping to change at page 22, line 40 skipping to change at page 23, line 40
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 Appendix A. The actual
API extensions are defined in [23]. 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 [4] 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 [5]) before a new o Requiring a Reachability Probe+Reply /defined in [4]) 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 23, line 31 skipping to change at page 24, 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 [20].] 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 24, line 7 skipping to change at page 25, 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 [5]. rules are specified in [4].
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 [5]. rules specified in [4].
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
[8] [9]. In the future versions of the protocol, and with a richer [7] [8]. 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 41, line 50 skipping to change at page 42, 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 [5]. This message format is defined in [4].
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 [5]. This message and its semantics are defined in [4].
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 43, line 50 skipping to change at page 44, line 50
| | option | | | option |
| | | | | |
| 120-127 | Reserved for debugging purposes | | 120-127 | Reserved for debugging purposes |
+---------+---------------------------------------------------------+ +---------+---------------------------------------------------------+
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 [20]. 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 48, line 27 skipping to change at page 49, 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 [6] for how weight would provide a way to do some load sharing. See [5] 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 50, line 40 skipping to change at page 51, line 40
| 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 [2] and [4]. defined in [2] and [3].
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 52, line 49 skipping to change at page 53, 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 [5]. This option is defined in [4].
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 54, line 17 skipping to change at page 55, 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 [5]. o Reachability state for the locator pairs as specified in [4].
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 [5]. have been sent and received as specified in [4].
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 57, line 33 skipping to change at page 58, 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 unstructured tag name space SHOULD randomly cycle through the unstructured 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 [13]). guidelines described in [12]).
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 [15]. These different verifications happen at party flooding attacks [14]. 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 [5]. routability test as part of the Probe sub-protocol [4].
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.
7.3. Normal context establishment 7.3. Normal context establishment
The normal context establishment consists of a 4 message exchange in The normal context establishment consists of a 4 message exchange in
the order of I1, R1, I2, R2 as can be seen in Figure 25. the order of I1, R1, I2, R2 as can be seen in Figure 3.
Initiator Responder Initiator Responder
IDLE IDLE IDLE IDLE
------------- I1 --------------> ------------- I1 -------------->
I1-SENT I1-SENT
<------------ R1 --------------- <------------ R1 ---------------
IDLE IDLE
------------- I2 --------------> ------------- I2 -------------->
I2-SENT I2-SENT
<------------ R2 --------------- <------------ R2 ---------------
ESTABLISHED ESTABLISHED ESTABLISHED ESTABLISHED
Figure 25: Normal context establishment Figure 3: Normal context establishment
7.4. Concurrent context establishment 7.4. Concurrent context establishment
When both ends try to initiate a context for the same ULID pair, then When both ends try to initiate a context for the same ULID pair, then
we might end up with crossing I1 messages. Alternatively, since no we might end up with crossing I1 messages. Alternatively, since no
state is created when receiving the I1, a host might send a I1 after state is created when receiving the I1, a host might send a I1 after
having sent a R1 message. having sent a R1 message.
Since a host remembers that it has sent an I1, it can respond to an Since a host remembers that it has sent an I1, it can respond to an
I1 from the peer (for the same ULID-pair), with a R2, resulting in I1 from the peer (for the same ULID-pair), with a R2, resulting in
the message exchange shown in Figure 26. Such behavior is needed for the message exchange shown in Figure 4. Such behavior is needed for
other reasons such as to correctly respond to retransmitted I1 other reasons such as to correctly respond to retransmitted I1
messages, which occur when the R2 message has been lost. messages, which occur when the R2 message has been lost.
Host A Host B Host A Host B
IDLE IDLE IDLE IDLE
-\ -\
I1-SENT---\ I1-SENT---\
---\ /--- ---\ /---
--- I1 ---\ /--- I1-SENT --- I1 ---\ /--- I1-SENT
skipping to change at page 59, line 34 skipping to change at page 60, line 34
-\ -\
I1-SENT---\ I1-SENT---\
---\ /--- ---\ /---
--- R2 ---\ /--- I1-SENT --- R2 ---\ /--- I1-SENT
---\ ---\
/--- R2 ---/ ---\ /--- R2 ---/ ---\
/--- --> /--- -->
<--- ESTABLISHED <--- ESTABLISHED
ESTABLISHED ESTABLISHED
Figure 26: Crossing I1 messages Figure 4: Crossing I1 messages
If a host has received an I1 and sent an R1, it has no state to If a host has received an I1 and sent an R1, it has no state to
remember this. Thus if the ULP on the host sends down packets, this remember this. Thus if the ULP on the host sends down packets, this
might trigger the host to send an I1 message itself. Thus while one might trigger the host to send an I1 message itself. Thus while one
end is sending an I1 the other is sending an I2 as can be seen in end is sending an I1 the other is sending an I2 as can be seen in
Figure 27. Figure 5.
Host A Host B Host A Host B
IDLE IDLE IDLE IDLE
-\ -\
---\ ---\
I1-SENT ---\ I1-SENT ---\
--- I1 ---\ --- I1 ---\
---\ ---\
---\ ---\
skipping to change at page 60, line 42 skipping to change at page 61, line 42
-\ -\
I2-SENT---\ I2-SENT---\
---\ /--- ---\ /---
--- R2 ---\ /--- --- R2 ---\ /---
---\ ---\
/--- R2 ---/ ---\ /--- R2 ---/ ---\
/--- --> /--- -->
<--- ESTABLISHED <--- ESTABLISHED
ESTABLISHED ESTABLISHED
Figure 27: Crossing I2 and I1 Figure 5: Crossing I2 and I1
7.5. Context recovery 7.5. Context recovery
Due to garbage collection, we can end up with one end having and Due to garbage collection, we can end up with one end having and
using the context state, and the other end not having any state. We using the context state, and the other end not having any state. We
need to be able to recover this state at the end that has lost it, need to be able to recover this state at the end that has lost it,
before we can use it. before we can use it.
This need can arise in the following cases: This need can arise in the following cases:
skipping to change at page 61, line 22 skipping to change at page 62, line 22
o The host that retained the state sends a control message (e.g. an o The host that retained the state sends a control message (e.g. an
Update Request message). Update Request message).
In all the cases the result is that the peer without state receives a In all the cases the result is that the peer without state receives a
shim message for which it has no context for the context tag. shim message for which it has no context for the context tag.
In all of those cases we can recover the context by having the node In all of those cases we can recover the context by having the node
which doesn't have a context state, send back an R1bis message, and which doesn't have a context state, send back an R1bis message, and
have then complete the recovery with a I2bis and R2 message as can be have then complete the recovery with a I2bis and R2 message as can be
seen in Figure 28. seen in Figure 6.
Host A Host B Host A Host B
Context for Context for
CT(peer)=X Discards context for CT(peer)=X Discards context for
CT(local)=X CT(local)=X
ESTABLISHED IDLE ESTABLISHED IDLE
---- payload, probe, etc. -----> No context state ---- payload, probe, etc. -----> No context state
for CT(local)=X for CT(local)=X
<------------ R1bis ------------ <------------ R1bis ------------
IDLE IDLE
------------- I2bis -----------> ------------- I2bis ----------->
I2BIS_SENT I2BIS_SENT
<------------ R2 --------------- <------------ R2 ---------------
ESTABLISHED ESTABLISHED ESTABLISHED ESTABLISHED
Figure 28: Context loss at receiver Figure 6: Context loss at receiver
If one end has garbage collected or lost the context state, it might If one end has garbage collected or lost the context state, it might
try to create a new context state (for the same ULID pair), by try to create a new context state (for the same ULID pair), by
sending an I1 message. The peer (that still has the context state) sending an I1 message. The peer (that still has the context state)
will reply with an R1 message and the full 4-way exchange will be will reply with an R1 message and the full 4-way exchange will be
performed again in this case as can be seen in Figure 29. performed again in this case as can be seen in Figure 7.
Host A Host B Host A Host B
Context for Context for
CT(peer)=X Discards context for CT(peer)=X Discards context for
ULIDs A1, B1 CT(local)=X ULIDs A1, B1 CT(local)=X
ESTABLISHED IDLE ESTABLISHED IDLE
Finds <------------ I1 --------------- Tries to setup Finds <------------ I1 --------------- Tries to setup
skipping to change at page 62, line 32 skipping to change at page 63, line 32
<------------ I2 --------------- <------------ I2 ---------------
Recreate context Recreate context
with new CT(peer) I2-SENT with new CT(peer) I2-SENT
and Ls(peer). and Ls(peer).
ESTABLISHED ESTABLISHED
------------- R2 --------------> ------------- R2 -------------->
ESTABLISHED ESTABLISHED ESTABLISHED ESTABLISHED
Figure 29: Context loss at sender Figure 7: Context loss at sender
7.6. Context confusion 7.6. Context confusion
Since each end might garbage collect the context state we can have Since each end might garbage collect the context state we can have
the case when one end has retained the context state and tries to use the case when one end has retained the context state and tries to use
it, while the other end has lost the state. We discussed this in the it, while the other end has lost the state. We discussed this in the
previous section on recovery. But for the same reasons, when one previous section on recovery. But for the same reasons, when one
host retains context tag X as CT(peer) for ULID pair <A1, B1>, the host retains context tag X as CT(peer) for ULID pair <A1, B1>, the
other end might end up allocating that context tag as CT(local) for other end might end up allocating that context tag as CT(local) for
another ULID pair, e.g., <A3, B1> between the same hosts. In this another ULID pair, e.g., <A3, B1> between the same hosts. In this
skipping to change at page 76, line 8 skipping to change at page 77, line 8
with the data contained in the I2 message and the host MUST with the data contained in the I2 message and the host MUST
send a R2 message back as specified in Section 7.14. Note that send a R2 message back as specified in Section 7.14. Note that
before updating Ls(peer) information, the host SHOULD perform before updating Ls(peer) information, the host SHOULD perform
the HBA/CGA validation of the peer's locator set at this point the HBA/CGA validation of the peer's locator set at this point
in time as specified in Section 7.2. The context STATE remains in time as specified in Section 7.2. The context STATE remains
unchanged. unchanged.
8. Handling ICMP Error Messages 8. Handling ICMP Error Messages
The routers in the path as well as the destination might generate The routers in the path as well as the destination might generate
various ICMP error messages, such as destination unreachable, packet ICMP error messages. In some cases, the Shim6 can take action and
too big, and Unrecognized Next Header type. In some cases, it is solve the solve the problem that resulted in the error. In other
critical that these packets make it back up to the ULPs so that they cases, the Shim6 layer can not solve the problem and it is critical
can take appropriate action. In other cases, it is probably the best that these packets make it back up to the ULPs so that they can take
option to process these packets locally at the Shim6 layer and not appropriate action.
inform to the ULP.
This is an implementation issue in the sense that the mechanism is This is an implementation issue in the sense that the mechanism is
completely local to the host itself. But the issue of how ICMP completely local to the host itself. But the issue of how ICMP
errors are correctly dispatched to the ULP on the host are important, errors are correctly dispatched to the ULP on the host are important,
hence this section specifies the issue. hence this section specifies the issue.
The main issue to be consider is whether the reported error can be All ICMP messages MUST be delivered to the ULP in all cases except
solved by the Shim6 layer or not. In some cases, it is clear that when Shim6 successfully acts on the message (e.g. selects a new
the shim6 layer cannot do anything to solve the problem reported by path). There SHOULD be a configuration option to unconditionally
the ICMP error e.g. Port unreachable, Packet too big error. In deliver all ICMP messages (including ones acted on by shim6) to the
these cases, the Shim6 layer should pass these messages to the ULP. ULP.
However, in some other cases, the reported error can be solved by the
Shim6 layer. For instance, in many of the cases, the Destination
unreachable error will be solved by the Shim6 layer by changing the
communication path. In this case, it maynot make sense to pass the
ICMP error to the ULP, since the problem will be solved by the Shim6
layer. Nevertheless, it is not clear whether the Shim6 will be able
to actually solve the problem, since it may be the case that there is
no communication path available. So the basic guideline to handle
this situation is: if the Shim6 layer cannot do anything to solve the
problem reported in the ICMP error, then pass the error to the ULP as
described below. If the Shim6 layer can try to solve the problem, it
may make sense to not pass the error to the ULP. This, on the other
hand, may be implementations specific, meaning that depending what is
the response of the ULP to the ICMP error, it may be more or less
critical to actually passing or not the ICMP errors back. In other
words, if the response of a given ULP to the reception of an ICMP
error is to close the communication, it is very important that the
Shim6 layer does not passes the ICMP error unless it is certain that
there is no alternative path available. If the response of the ULP
is simply to ignore ICMP error, it may make sense to always pass the
ICMP errors to the ULP. In any case, we reccommend that the Shim6
layer provides a configuration interface, so it is possible to
configure how to process the different ICMP error messages. Below,
we provide some guidelines on how to process the different ICMP
errors.
The following ICMP error messages should be processed by the Shim6 According to that recommendation, the following ICMP error messages
layer and not passed to the ULP: ICMP error Destiantion unreachable should be processed by the Shim6 layer and not passed to the ULP:
with codes 0 (No route to destination), 1 (Communication with ICMP error Destination unreachable with codes 0 (No route to
destination administratively prohibited), 2 (Beyond scope of source destination), 1 (Communication with destination administratively
address), 3 (Address unreachable), 5 (Source address failed ingress/ prohibited), 2 (Beyond scope of source address), 3 (Address
egress policy), 6 (Reject route to destination), ICMP Time exceeded unreachable), 5 (Source address failed ingress/egress policy), 6
error, ICMP Parameter problem error with the paramter that caused the (Reject route to destination), ICMP Time exceeded error, ICMP
error being a Shim6 paramter. Parameter problem error with the parameter that caused the error
being a Shim6 parameter.
The following ICMP error messages report problems that cannot be The following ICMP error messages report problems that cannot be
addressed by the Shim6 layer and that should be passed to the ULP (as addressed by the Shim6 layer and that should be passed to the ULP (as
described below): ICMP Packet too big error, ICMP Destination described below): ICMP Packet too big error, ICMP Destination
Unreachable with Code 4 (Port unreachable) ICMP Paramenter problem Unreachable with Code 4 (Port unreachable) ICMP Parameter problem (if
(if the paramter that caused the problem is not a Shim6 parameter). the parameter that caused the problem is not a Shim6 parameter).
+--------------+ +--------------+
| IPv6 Header | | IPv6 Header |
| | | |
+--------------+ +--------------+
| ICMPv6 | | ICMPv6 |
| Header | | Header |
- - +--------------+ - - - - +--------------+ - -
| IPv6 Header | | IPv6 Header |
| src, dst as | Can be dispatched | src, dst as | Can be dispatched
skipping to change at page 77, line 37 skipping to change at page 78, line 25
| on host | ICMP error handler | on host | ICMP error handler
Packet +--------------+ Packet +--------------+
| ULP | | ULP |
in | Header | in | Header |
+--------------+ +--------------+
Error | | Error | |
~ Data ~ ~ Data ~
| | | |
- - +--------------+ - - - - +--------------+ - -
Figure 30: ICMP error handling without payload extension header Figure 8: ICMP error handling without payload extension header
When the ULP packets are sent without the payload extension header, When the ULP packets are sent without the payload extension header,
that is, while the initial locators=ULIDs are working, this that is, while the initial locators=ULIDs are working, this
introduces no new concerns; an implementation's existing mechanism introduces no new concerns; an implementation's existing mechanism
for delivering these errors to the ULP will work. See Figure 30. for delivering these errors to the ULP will work. See Figure 8.
But when the shim on the transmitting side inserts the payload But when the shim on the transmitting side inserts the payload
extension header and replaces the ULIDs in the IP address fields with extension header and replaces the ULIDs in the IP address fields with
some other locators, then an ICMP error coming back will have a some other locators, then an ICMP error coming back will have a
"packet in error" which is not a packet that the ULP sent. Thus the "packet in error" which is not a packet that the ULP sent. Thus the
implementation will have to apply the reverse mapping to the "packet implementation will have to apply the reverse mapping to the "packet
in error" before passing the ICMP error up to the ULP, including the in error" before passing the ICMP error up to the ULP, including the
ICMP extensions defined in [25]. See Figure 31. ICMP extensions defined in [24]. See Figure 9.
+--------------+ +--------------+
| IPv6 Header | | IPv6 Header |
| | | |
+--------------+ +--------------+
| ICMPv6 | | ICMPv6 |
| Header | | Header |
- - +--------------+ - - - - +--------------+ - -
| IPv6 Header | | IPv6 Header |
| src, dst as | Needs to be | src, dst as | Needs to be
skipping to change at page 78, line 28 skipping to change at page 79, line 28
| Header | header removed | Header | header removed
in +--------------+ before it can be in +--------------+ before it can be
| Transport | dispatched to the ULP | Transport | dispatched to the ULP
Error | Header | ICMP error handler. Error | Header | ICMP error handler.
+--------------+ +--------------+
| | | |
~ Data ~ ~ Data ~
| | | |
- - +--------------+ - - - - +--------------+ - -
Figure 31: ICMP error handling with payload extension header Figure 9: ICMP error handling with payload extension header
Note that this mapping is different than when receiving packets from Note that this mapping is different than when receiving packets from
the peer with a payload extension headers, because in that case the the peer with a payload extension headers, because in that case the
packets contain CT(local). But the ICMP errors have a "packet in packets contain CT(local). But the ICMP errors have a "packet in
error" with an payload extension header containing CT(peer). This is error" with an payload extension header containing CT(peer). This is
because they were intended to be received by the peer. In any case, because they were intended to be received by the peer. In any case,
since the <Source Locator, Destination Locator, CT(peer)> has to be since the <Source Locator, Destination Locator, CT(peer)> has to be
unique when received by the peer, the local host should also only be unique when received by the peer, the local host should also only be
able to find one context that matches this tuple. able to find one context that matches this tuple.
skipping to change at page 83, line 15 skipping to change at page 84, line 15
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 reachability exploration Lp(peer) as BROKEN. The host uses the reachability exploration
procedure described in [5] to verify that the new locator is procedure described in [4] to verify that the new locator is
reachable before changing Lp(peer). 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 85, line 30 skipping to change at page 86, 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 [5]. this document and is specified in [4].
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 87, line 26 skipping to change at page 88, 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 purposes as described in [5]. The host reachability detection purposes as described in [4]. 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 91, line 18 skipping to change at page 92, 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 [8], and some fixes to that specification [9] to make it Selection [7], and some fixes to that specification [8] 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 93, line 14 skipping to change at page 94, line 14
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 recommended that the alternative network path. In this case, it recommended that the
Shim6 follows the recommendation defined in [21] 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 to 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
skipping to change at page 95, line 29 skipping to change at page 96, line 29
configuration can increase the operation work in a network. However, configuration can increase the operation work in a network. However,
it should be noted that the capability of having multiupl prefixes in it should be noted that the capability of having multiupl prefixes in
a site and multiple addresses assigned to an interface is an IPv6 a site and multiple addresses assigned to an interface is an IPv6
capability that goes beyond the Shim6 case and it is expected to be capability that goes beyond the Shim6 case and it is expected to be
widely used. So, even though this is the case for Shim6, we consider widely used. So, even though this is the case for Shim6, we consider
that the implications of such a configuration is beyond the that the implications of such a configuration is beyond the
particular case of Shim6 and must be addressed for the generic IPv6 particular case of Shim6 and must be addressed for the generic IPv6
case. Nevertheless, Shim6 also assumes the usage of CGA/HBA case. Nevertheless, Shim6 also assumes the usage of CGA/HBA
addresses by Shim6 hosts. this implies that Shim6 capable hosts addresses by Shim6 hosts. this implies that Shim6 capable hosts
should configure addresses using HBA/CGA generation mechanims. should configure addresses using HBA/CGA generation mechanims.
Additional consideration about this issue can be found at [19] Additional consideration about this issue can be found at [18]
15.4. Other considerations 15.4. 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 [18]. But in order for such applications to be as described in [17]. 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 96, line 16 skipping to change at page 97, line 16
the flow label stays the same. the flow label stays the same.
o MTU implications. The path MTU mechanisms we use are robust o MTU implications. The path MTU mechanisms we use are robust
against different packets taking different paths through the against different packets taking different paths through the
Internet, by computing a minimum over the recently observed path Internet, by computing a minimum over the recently observed path
MTUs. When Shim6 fails over from using one locator pair to MTUs. When Shim6 fails over from using one locator pair to
another pair, this means that packets might travel over a another pair, this means that packets might travel over a
different path through the Internet, hence the path MTU might be different path through the Internet, hence the path MTU might be
quite different. In order to deal with this changes in the MTU, quite different. In order to deal with this changes in the MTU,
the usage of Packetization Layer Path MTU Discovery as defined in the usage of Packetization Layer Path MTU Discovery as defined in
[24] is reccommended. [23] is reccommended.
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. By conveying the information to the is an implementation matter. By conveying the information to the
transport layer, it can adapt and reduce the MSS accordingly. transport layer, it can adapt and reduce the MSS accordingly.
16. Security Considerations 16. Security Considerations
This document satisfies the concerns specified in [15] as follows: This document satisfies the concerns specified in [14] as follows:
o The HBA [2] and CGA technique [4] for verifying the locators to o The HBA [2] and CGA technique [3] 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, preventing threats described in sections 4.1.1, somewhere else, preventing threats described in sections 4.1.1,
4.1.2, 4.1.3 and 4.2 of [15]. These two approaches provide a 4.1.2, 4.1.3 and 4.2 of [14]. These two approaches provide a
similar level of protection but they provide different similar level of protection but they provide different
functionality with a different computational cost. The HBA functionality with a different computational cost. The HBA
mechanism relies on the capability of generating all the addresses mechanism relies on the capability of generating all the addresses
of a multihomed host as an unalterable set of intrinsically bound of a multihomed host as an unalterable set of intrinsically bound
IPv6 addresses, known as an HBA set. In this approach, addresses IPv6 addresses, known as an HBA set. In this approach, addresses
incorporate a cryptographic one-way hash of the prefix-set incorporate a cryptographic one-way hash of the prefix-set
available into the interface identifier part. The result is that 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 the addresses themselves, providing hijacking protection. Any
peer using the shim protocol node can efficiently verify that the peer using the shim protocol node can efficiently verify that the
skipping to change at page 97, line 35 skipping to change at page 98, line 35
calculation. In a CGA based approach the address used as ULID is calculation. In a CGA based approach the address used as ULID is
a CGA that contains a hash of a public key in its interface a CGA that contains a hash of a public key in its interface
identifier. The result is a secure binding between the ULID and identifier. The result is a secure binding between the ULID and
the associated key pair. This allows each peer to use the the associated key pair. This allows each peer to use the
corresponding private key to sign the shim messages that convey corresponding private key to sign the shim messages that convey
locator set information. The trust chain in this case is the locator set information. The trust chain in this case is the
following: the ULID used for the communication is securely bound following: the ULID used for the communication is securely bound
to the key pair because it contains the hash of the public key, to the key pair because it contains the hash of the public key,
and the locator set is bound to the public key through the and the locator set is bound to the public key through the
signature. Any of these two mechanisms HBA and CGA provide time- signature. Any of these two mechanisms HBA and CGA provide time-
shifted attack protection (as described in section 4.1.2 of [15]), shifted attack protection (as described in section 4.1.2 of [14]),
since the ULID is securely bound to a locator set that can only be since the ULID is securely bound to a locator set that can only be
defined by the owner of the ULID. The minimum acceptable key defined by the owner of the ULID. The minimum acceptable key
length for RSA keys used in the generation of CGAs MUST be at length for RSA keys used in the generation of CGAs MUST be at
least 1024 bits. Any implementation should follow prudent least 1024 bits. Any implementation should follow prudent
cryptographic practice in determining the appropriate key lengths. cryptographic practice in determining the appropriate key lengths.
o 3rd party flooding attacks described in section 4.3 of [15] are o 3rd party flooding attacks described in section 4.3 of [14] are
prevented by requiring a Shim6 peer to perform a successful prevented by requiring a Shim6 peer to perform a successful
Reachability probe + reply exchange before accepting a new locator Reachability probe + reply exchange before accepting a new locator
for use as a packet destination.. for use as a packet destination..
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
requires the attacker to create state, consuming his own resources requires the attacker to create state, consuming his own resources
and also it provides an IPv6 address that the attacker was using. and also it 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
attacks as described in section 4.1.4 of [15], and to prevent off- attacks as described in section 4.1.4 of [14], and to prevent off-
path attackers from interfering with the establishment. path attackers from interfering with the establishment.
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 [15]. 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.
Interaction with IPsec 16.1. Interaction with IPsec
The Shim6 sub-layer is implemented below the IPsec layer within the
IP layer. This deserves some additional considerations for a couple
of specific cases: First, it should be noted that the Shim6 approach
does not preclude using IPsec tunnels on Shim6 packets within the
network transit path. Second, in case that IPsec is implemented as
Bump-In-The-Wire (BITW) [3], either the shim MUST be disabled, or the
shim MUST also be implemented as Bump-In-The-Wire, in order to
satisfy the requirement that IPsec is layered above the shim.
If a shim6 node has some protected and some unprotected interfaces
[RFC 4301] for the purposes of IPsec, then it MUST treat the locator
sets for the protected and unprotected interfaces as separate locator
sets and not intermix them. This ensures that shim6 will never
failover from using a protected interface to using an unprotected
interface and vice versa.
The same constraint applies to shim6 hosts which have interfaces The Shim6 sub-layer can be implemented either below IPsec sublayer,
attached to networks where there are different security or above the IPsec sub-layer, or both. (The latter can occur when
considerations, for instance a host with some interfaces attached to e.g., IPsec is used both end-to-end as well as for IPsec tunnels.)
the public Internet and some interfaces attached to an intranet.
In a "bump-in-the-stack" (BITS) IPsec implementation, IPsec is In a "bump-in-the-stack" (BITS) IPsec implementation, IPsec is
implemented "underneath" an existing implementation of an IP protocol implemented "underneath" an existing implementation of an IP protocol
stack, between the native IP and the local network drivers. In that stack, between the native IP and the local network drivers. In that
case it is not possible to make IPsec benefit from the failover case it is not possible to make IPsec benefit from the failover
capabilities of shim6; when shim6 fails over to a different locator capabilities of shim6; when shim6 fails over to a different locator
pair then the BITS IPsec would end up using a different (and possibly pair then the BITS IPsec would end up using a different (and possibly
establish a new) security association for that pair of IP addresses. establish a new) security association for that pair of IP addresses.
Same thing applies to a "bump-in-the-wire" (BITW) IPsec Same thing applies to a "bump-in-the-wire" (BITW) IPsec
implementation. In those cases shim6 and IPsec still work, but it is implementation. In those cases shim6 and IPsec still work, but it is
less efficient to have to use separate security associations as a less efficient to have to use separate security associations as a
result of a shim6 failover. result of a shim6 failover.
In order for a BITS and BITW IPsec implementation on a host as well In order for a BITS and BITW IPsec implementation on the node as well
as a security gateway to be able to look at the same selectors before as a security gateway to be able to look at the same selectors before
and after a failover, their implementation needs to skip the SHIM6 and after a failover, their implementation 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
within the IP layer we avoid any extra IPsec work due to locator
changes, but the implementation needs to make sure that the locator
changes doesn't cause any violations of the inteded IPsec policy. It
is easiest to explain this issue using an example:
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
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
context tags that are being used, and once known it can use those context tags that are being used, and once known it can use those
to send bogus messages. to send bogus messages.
skipping to change at page 104, line 18 skipping to change at page 106, 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
single-homed, and cope with a site's ISPs that do ingress single-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 [16]. site. Further discussion of this issue is captured in [15].
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 105, line 35 skipping to change at page 107, line 35
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 [17]. initial draft on this topic [16].
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 114, line 41 skipping to change at page 116, 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
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 Appendix D. Design Alternatives
skipping to change at page 118, line 13 skipping to change at page 120, 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 [12]). The packets sent after a failure when a or as suggested in [11]). 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 121, line 46 skipping to change at page 123, 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 [15]. 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
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 123, line 17 skipping to change at page 125, line 17
set that can be used to exchange packets. The mechanism provided by set that can be used to exchange packets. The mechanism provided by
IPsec to securely bind the address used with the cryptographic keys IPsec to securely bind the address used with the cryptographic keys
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. The other possibility would be to use some form of global PKI. The other possibility would be to use some form of
opportunistic IPSec, like BTNS [22]. However, this would still opportunistic IPSec, like BTNS [21]. However, this would still
present some issues, in particular, this approach requires a leap-of- present some issues, in particular, this approach requires a leap-of-
faith in order to bind a given address to the public ky that is being faith in order to bind a given address to the public ky that is being
used, which would actually prevent from providing the most critical used, which would actually prevent from providing the most critical
security feature that a Shim6 security solution needs to achieve, security feature that a Shim6 security solution needs to achieve,
i.e. proving identifier ownership. On top of that, using IPsec would i.e. proving identifier ownership. On top of that, using IPsec would
require to turn on per-packet AH/ESP just for multihoming to occur. require to turn on per-packet AH/ESP just for multihoming to occur.
Finally two different technologies were selected to protect the shim Finally two different technologies were selected to protect the shim
protocol: HBA [4] and CGA [2]. These two approaches provide a protocol: HBA [3] 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 126, line 10 skipping to change at page 128, line 10
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 [20]. 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 128, line 9 skipping to change at page 130, 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-10:
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-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
o Added text on why oportunistic IPSec was not used for securing o Added text on why oportunistic IPSec was not used for securing
locator sets locator sets
o Reowrded the Validator generation text to make it clearer o Reowrded the Validator generation text to make it clearer
o Reworded security considerations to explicitly address RFC 4218 o Reworded security considerations to explicitly address RFC 4218
threats threats
o Added OandM section o Added OandM section
o Added text on TE considerations o Added text on TE considerations
o Added requirement to properly support RFC4884 icmp messages o Added requirement to properly support RFC4884 icmp messages
o added th usage of Packetization Layer Path MTU Discovery o Added th usage of Packetization Layer Path MTU Discovery
o reworded the placement of shim6 w.r.t. ipsec o Reworded the placement of shim6 w.r.t. IPsec
o added text on the IPsec considerations o Added text on the IPsec considerations
The following changes have been made since draft-ietf-shim6-proto-08: 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 o Clarified that the validator option must be included in R1 and I2
messages messages
o changed preferred peer/local locator to current peer/local locator o changed preferred peer/local locator to current peer/local locator
to align it with faliure detection draft to align it with faliure detection draft
o Reworded sections describing the generation and reception of o Reworded sections describing the generation and reception of
skipping to change at page 132, line 13 skipping to change at page 134, line 17
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 [5]. Only the message type values and option and Event option to [4]. 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 135, line 15 skipping to change at page 137, line 15
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] Aura, T., "Cryptographically Generated Addresses (CGA)", [2] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
[3] Kent, S. and K. Seo, "Security Architecture for the Internet [3] Bagnulo, M., "Hash Based Addresses (HBA)",
Protocol", RFC 4301, December 2005.
[4] 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.
[5] 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-11 (work in progress), draft-ietf-shim6-failure-detection-13 (work in progress),
February 2008. June 2008.
19.2. Informative References 19.2. Informative References
[6] 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.
[7] 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.
[8] Draves, R., "Default Address Selection for Internet Protocol [7] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003. version 6 (IPv6)", RFC 3484, February 2003.
[9] Bagnulo, M., "Updating RFC 3484 for multihoming support", [8] 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.
[10] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [9] 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.
[11] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- [10] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-
Multihoming Architectures", RFC 3582, August 2003. Multihoming Architectures", RFC 3582, August 2003.
[12] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 [11] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6
Flow Label Specification", RFC 3697, March 2004. Flow Label Specification", RFC 3697, March 2004.
[13] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [12] 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.
[14] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [13] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[15] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming [14] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming
Solutions", RFC 4218, October 2005. Solutions", RFC 4218, October 2005.
[16] Huitema, C., "Ingress filtering compatibility for IPv6 [15] 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.
[17] Bagnulo, M. and E. Nordmark, "SHIM - MIPv6 Interaction", [16] 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.
[18] Nordmark, E., "Shim6 Application Referral Issues", [17] 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.
[19] Bagnulo, M. and J. Abley, "Applicability Statement for the [18] Bagnulo, M. and J. Abley, "Applicability Statement for the
Level 3 Multihoming Shim Protocol (Shim6)", Level 3 Multihoming Shim Protocol (Shim6)",
draft-ietf-shim6-applicability-03 (work in progress), draft-ietf-shim6-applicability-03 (work in progress),
July 2007. July 2007.
[20] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, [19] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", draft-ietf-hip-base-10 (work in "Host Identity Protocol", draft-ietf-hip-base-10 (work in
progress), October 2007. progress), October 2007.
[21] Schuetz, S., Koutsianas, N., Eggert, L., Eddy, W., Swami, Y., [20] Schuetz, S., Koutsianas, N., Eggert, L., Eddy, W., Swami, Y.,
and K. Le, "TCP Response to Lower-Layer Connectivity-Change and K. Le, "TCP Response to Lower-Layer Connectivity-Change
Indications", draft-schuetz-tcpm-tcp-rlci-02 (work in Indications", draft-schuetz-tcpm-tcp-rlci-03 (work in
progress), November 2007. progress), February 2008.
[22] Williams, N. and M. Richardson, "Better-Than-Nothing-Security: [21] Williams, N. and M. Richardson, "Better-Than-Nothing-Security:
An Unauthenticated Mode of IPsec", draft-ietf-btns-core-06 An Unauthenticated Mode of IPsec", draft-ietf-btns-core-07
(work in progress), January 2008. (work in progress), August 2008.
[23] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, "Socket [22] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, "Socket
Application Program Interface (API) for Multihoming Shim", Application Program Interface (API) for Multihoming Shim",
draft-ietf-shim6-multihome-shim-api-04 (work in progress), draft-ietf-shim6-multihome-shim-api-07 (work in progress),
February 2008. November 2008.
[24] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [23] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007. Discovery", RFC 4821, March 2007.
[25] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended [24] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended
ICMP to Support Multi-Part Messages", RFC 4884, April 2007. ICMP to Support Multi-Part Messages", RFC 4884, April 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
skipping to change at page 138, line 4 skipping to change at line 5848
Marcelo Bagnulo Marcelo Bagnulo
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
Av. Universidad 30 Av. Universidad 30
Leganes, Madrid 28911 Leganes, Madrid 28911
SPAIN SPAIN
Phone: +34 91 6248814 Phone: +34 91 6248814
Email: marcelo@it.uc3m.es Email: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es URI: http://www.it.uc3m.es
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 122 change blocks. 
308 lines changed or deleted 364 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/