draft-ietf-shim6-proto-06.txt   draft-ietf-shim6-proto-07.txt 
SHIM6 WG E. Nordmark SHIM6 WG E. Nordmark
Internet-Draft Sun Microsystems Internet-Draft Sun Microsystems
Expires: April 26, 2007 M. Bagnulo Expires: May 28, 2007 M. Bagnulo
UC3M UC3M
October 23, 2006 November 24, 2006
Level 3 multihoming shim protocol Level 3 multihoming shim protocol
draft-ietf-shim6-proto-06.txt draft-ietf-shim6-proto-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 26, 2007. This Internet-Draft will expire on May 28, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
The SHIM6 protocol is a layer 3 shim for providing locator agility The SHIM6 protocol is a layer 3 shim for providing locator agility
below the transport protocols, so that multihoming can be provided below the transport protocols, so that multihoming can be provided
for IPv6 with failover and load sharing properties, without assuming for IPv6 with failover and load sharing properties, without assuming
skipping to change at page 3, line 4 skipping to change at page 3, line 4
5.12. Keepalive Message Format . . . . . . . . . . . . . . . . 39 5.12. Keepalive Message Format . . . . . . . . . . . . . . . . 39
5.13. Probe Message Format . . . . . . . . . . . . . . . . . . 39 5.13. Probe Message Format . . . . . . . . . . . . . . . . . . 39
5.14. Option Formats . . . . . . . . . . . . . . . . . . . . . 40 5.14. Option Formats . . . . . . . . . . . . . . . . . . . . . 40
5.14.1. Responder Validator Option Format . . . . . . . . . 42 5.14.1. Responder Validator Option Format . . . . . . . . . 42
5.14.2. Locator List Option Format . . . . . . . . . . . . . 42 5.14.2. Locator List Option Format . . . . . . . . . . . . . 42
5.14.3. Locator Preferences Option Format . . . . . . . . . 44 5.14.3. Locator Preferences Option Format . . . . . . . . . 44
5.14.4. CGA Parameter Data Structure Option Format . . . . . 46 5.14.4. CGA Parameter Data Structure Option Format . . . . . 46
5.14.5. CGA Signature Option Format . . . . . . . . . . . . 46 5.14.5. CGA Signature Option Format . . . . . . . . . . . . 46
5.14.6. ULID Pair Option Format . . . . . . . . . . . . . . 47 5.14.6. ULID Pair Option Format . . . . . . . . . . . . . . 47
5.14.7. Forked Instance Identifier Option Format . . . . . . 48 5.14.7. Forked Instance Identifier Option Format . . . . . . 48
5.14.8. Probe Option Format . . . . . . . . . . . . . . . . 48 5.14.8. Keepalive Timeout Option Format . . . . . . . . . . 48
5.14.9. Reachability Option Format . . . . . . . . . . . . . 49 6. Conceptual Model of a Host . . . . . . . . . . . . . . . . . 49
5.14.10. Payload Reception Report Option Format . . . . . . . 49 6.1. Conceptual Data Structures . . . . . . . . . . . . . . . 49
6. Conceptual Model of a Host . . . . . . . . . . . . . . . . . 50 6.2. Context States . . . . . . . . . . . . . . . . . . . . . 50
6.1. Conceptual Data Structures . . . . . . . . . . . . . . . 50 7. Establishing ULID-Pair Contexts . . . . . . . . . . . . . . . 52
6.2. Context States . . . . . . . . . . . . . . . . . . . . . 51 7.1. Uniqueness of Context Tags . . . . . . . . . . . . . . . 52
7. Establishing ULID-Pair Contexts . . . . . . . . . . . . . . . 53 7.2. Locator Verification . . . . . . . . . . . . . . . . . . 52
7.1. Uniqueness of Context Tags . . . . . . . . . . . . . . . 53 7.3. Normal context establishment . . . . . . . . . . . . . . 53
7.2. Locator Verification . . . . . . . . . . . . . . . . . . 53 7.4. Concurrent context establishment . . . . . . . . . . . . 53
7.3. Normal context establishment . . . . . . . . . . . . . . 54 7.5. Context recovery . . . . . . . . . . . . . . . . . . . . 55
7.4. Concurrent context establishment . . . . . . . . . . . . 54 7.6. Context confusion . . . . . . . . . . . . . . . . . . . . 57
7.5. Context recovery . . . . . . . . . . . . . . . . . . . . 56 7.7. Sending I1 messages . . . . . . . . . . . . . . . . . . . 58
7.6. Context confusion . . . . . . . . . . . . . . . . . . . . 58 7.8. Retransmitting I1 messages . . . . . . . . . . . . . . . 58
7.7. Sending I1 messages . . . . . . . . . . . . . . . . . . . 59 7.9. Receiving I1 messages . . . . . . . . . . . . . . . . . . 59
7.8. Retransmitting I1 messages . . . . . . . . . . . . . . . 59 7.10. Sending R1 messages . . . . . . . . . . . . . . . . . . . 60
7.9. Receiving I1 messages . . . . . . . . . . . . . . . . . . 60 7.10.1. Generating the R1 Validator . . . . . . . . . . . . 60
7.10. Sending R1 messages . . . . . . . . . . . . . . . . . . . 61 7.11. Receiving R1 messages and sending I2 messages . . . . . . 61
7.10.1. Generating the R1 Validator . . . . . . . . . . . . 61 7.12. Retransmitting I2 messages . . . . . . . . . . . . . . . 62
7.11. Receiving R1 messages and sending I2 messages . . . . . . 62 7.13. Receiving I2 messages . . . . . . . . . . . . . . . . . . 62
7.12. Retransmitting I2 messages . . . . . . . . . . . . . . . 63 7.14. Sending R2 messages . . . . . . . . . . . . . . . . . . . 64
7.13. Receiving I2 messages . . . . . . . . . . . . . . . . . . 63 7.15. Match for Context Confusion . . . . . . . . . . . . . . . 64
7.14. Sending R2 messages . . . . . . . . . . . . . . . . . . . 65 7.16. Receiving R2 messages . . . . . . . . . . . . . . . . . . 65
7.15. Match for Context Confusion . . . . . . . . . . . . . . . 65 7.17. Sending R1bis messages . . . . . . . . . . . . . . . . . 66
7.16. Receiving R2 messages . . . . . . . . . . . . . . . . . . 66 7.17.1. Generating the R1bis Validator . . . . . . . . . . . 66
7.17. Sending R1bis messages . . . . . . . . . . . . . . . . . 67 7.18. Receiving R1bis messages and sending I2bis messages . . . 67
7.17.1. Generating the R1bis Validator . . . . . . . . . . . 67 7.19. Retransmitting I2bis messages . . . . . . . . . . . . . . 68
7.18. Receiving R1bis messages and sending I2bis messages . . . 68 7.20. Receiving I2bis messages and sending R2 messages . . . . 68
7.19. Retransmitting I2bis messages . . . . . . . . . . . . . . 69 8. Handling ICMP Error Messages . . . . . . . . . . . . . . . . 70
7.20. Receiving I2bis messages and sending R2 messages . . . . 69 9. Teardown of the ULID-Pair Context . . . . . . . . . . . . . . 72
8. Handling ICMP Error Messages . . . . . . . . . . . . . . . . 71 10. Updating the Peer . . . . . . . . . . . . . . . . . . . . . . 73
9. Teardown of the ULID-Pair Context . . . . . . . . . . . . . . 73 10.1. Sending Update Request messages . . . . . . . . . . . . . 73
10. Updating the Peer . . . . . . . . . . . . . . . . . . . . . . 74 10.2. Retransmitting Update Request messages . . . . . . . . . 73
10.1. Sending Update Request messages . . . . . . . . . . . . . 74 10.3. Newer Information While Retransmitting . . . . . . . . . 74
10.2. Retransmitting Update Request messages . . . . . . . . . 74 10.4. Receiving Update Request messages . . . . . . . . . . . . 74
10.3. Newer Information While Retransmitting . . . . . . . . . 75 10.5. Receiving Update Acknowledgement messages . . . . . . . . 76
10.4. Receiving Update Request messages . . . . . . . . . . . . 75 11. Sending ULP Payloads . . . . . . . . . . . . . . . . . . . . 77
10.5. Receiving Update Acknowledgement messages . . . . . . . . 77 11.1. Sending ULP Payload after a Switch . . . . . . . . . . . 77
11. Sending ULP Payloads . . . . . . . . . . . . . . . . . . . . 78 12. Receiving Packets . . . . . . . . . . . . . . . . . . . . . . 79
11.1. Sending ULP Payload after a Switch . . . . . . . . . . . 78 12.1. Receiving Payload Extension Headers . . . . . . . . . . . 79
12. Receiving Packets . . . . . . . . . . . . . . . . . . . . . . 80 12.2. Receiving Shim Control messages . . . . . . . . . . . . . 79
12.1. Receiving Payload Extension Headers . . . . . . . . . . . 80 12.3. Context Lookup . . . . . . . . . . . . . . . . . . . . . 80
12.2. Receiving Shim Control messages . . . . . . . . . . . . . 80 13. Initial Contact . . . . . . . . . . . . . . . . . . . . . . . 82
12.3. Context Lookup . . . . . . . . . . . . . . . . . . . . . 81 14. Protocol constants . . . . . . . . . . . . . . . . . . . . . 83
13. Initial Contact . . . . . . . . . . . . . . . . . . . . . . . 83 15. Implications Elsewhere . . . . . . . . . . . . . . . . . . . 84
14. Protocol constants . . . . . . . . . . . . . . . . . . . . . 84 16. Security Considerations . . . . . . . . . . . . . . . . . . . 86
15. Implications Elsewhere . . . . . . . . . . . . . . . . . . . 85
16. Security Considerations . . . . . . . . . . . . . . . . . . . 87
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 89 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 89
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 91 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 91
Appendix A. Possible Protocol Extensions . . . . . . . . . . 92 Appendix A. Possible Protocol Extensions . . . . . . . . . . 92
Appendix B. Simplified State Machine . . . . . . . . . . . . 94 Appendix B. Simplified State Machine . . . . . . . . . . . . 94
Appendix B.1. Simplified State Machine diagram . . . . . . . . 100 Appendix B.1. Simplified State Machine diagram . . . . . . . . 100
Appendix C. Context Tag Reuse . . . . . . . . . . . . . . . . 101 Appendix C. Context Tag Reuse . . . . . . . . . . . . . . . . 101
Appendix C.1. Context Recovery . . . . . . . . . . . . . . . . 101 Appendix C.1. Context Recovery . . . . . . . . . . . . . . . . 101
Appendix C.2. Context Confusion . . . . . . . . . . . . . . . . 101 Appendix C.2. Context Confusion . . . . . . . . . . . . . . . . 101
Appendix C.3. Three Party Context Confusion . . . . . . . . . . 102 Appendix C.3. Three Party Context Confusion . . . . . . . . . . 102
Appendix D. Design Alternatives . . . . . . . . . . . . . . . 103 Appendix D. Design Alternatives . . . . . . . . . . . . . . . 103
skipping to change at page 4, line 27 skipping to change at page 4, line 25
Appendix D.2.2. Extension Header . . . . . . . . . . . . . . . . 106 Appendix D.2.2. Extension Header . . . . . . . . . . . . . . . . 106
Appendix D.3. Context Loss Detection . . . . . . . . . . . . . 107 Appendix D.3. Context Loss Detection . . . . . . . . . . . . . 107
Appendix D.4. Securing locator sets . . . . . . . . . . . . . . 109 Appendix D.4. Securing locator sets . . . . . . . . . . . . . . 109
Appendix D.5. ULID-pair context establishment exchange . . . . 112 Appendix D.5. ULID-pair context establishment exchange . . . . 112
Appendix D.6. Updating locator sets . . . . . . . . . . . . . . 113 Appendix D.6. Updating locator sets . . . . . . . . . . . . . . 113
Appendix D.7. State Cleanup . . . . . . . . . . . . . . . . . . 113 Appendix D.7. State Cleanup . . . . . . . . . . . . . . . . . . 113
Appendix E. Change Log . . . . . . . . . . . . . . . . . . . 116 Appendix E. Change Log . . . . . . . . . . . . . . . . . . . 116
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 120 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 120
19.1. Normative References . . . . . . . . . . . . . . . . . . 120 19.1. Normative References . . . . . . . . . . . . . . . . . . 120
19.2. Informative References . . . . . . . . . . . . . . . . . 120 19.2. Informative References . . . . . . . . . . . . . . . . . 120
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 123
Intellectual Property and Copyright Statements . . . . . . . . . 123 Intellectual Property and Copyright Statements . . . . . . . . . 124
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 [15], without assuming that a multihomed site will have a properties [16], 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. should the original one stop working.
We assume that redirection attacks are prevented using the mechanism We assume that redirection attacks are prevented using the mechanism
specified in HBA [7]. specified in HBA [8].
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, is specified new working locator pair is discovered after a failure, are specified
in a separate document [8] This document allocates message types and in a separate document [9]. This document allocates message types
option types for that sub-protocol, and leaves the specification of and option types for that sub-protocol, and leaves the specification
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 is 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 in particular. transport protocols in particular.
o Address the security threats in [19] through the combination of o Address the security threats in [20] through the combination of
the HBA/CGA approach specified in a separate document [7] and the HBA/CGA approach specified in a separate document [8] 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 6, line 45 skipping to change at page 6, line 45
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 [12]. Some extensions are address selection as specified in RFC 3484 [13]. 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 [13]. Underneath, and the shim6 protocol is used, as outlined in [14]. 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 [22] for further discussion of the application unreachable. See [23] 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) [18], as ULIDs in a multihoming as Unique-Local Addresses (ULAs) [19], 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 7, line 38 skipping to change at page 7, line 38
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 [10] for unicast.) filtering [11] 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 [14], shim. This is quite a natural fit for protocols which use RTP [15],
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 8, line 37 skipping to change at page 8, line 37
communication between two ULIDs might continue to work after one or communication between two ULIDs might continue to work after one or
both of those ULIDs are no longer reachable as locators, for example both of those ULIDs are no longer reachable as locators, for example
due to a renumbering event. This opens up the possibility that the due to a renumbering event. This opens up the possibility that the
ULID (or at least the prefix on which it is based) is reassigned to ULID (or at least the prefix on which it is based) is reassigned to
another site while it is still being used (with another locator) for another site while it is still being used (with another locator) for
existing communication. existing communication.
In the worst case we could end up with two separate hosts using the In the worst case we could end up with two separate hosts using the
same ULID while both of them are communicating with the same host. same ULID while both of them are communicating with the same host.
This potential source for confusion can be avoided if we require that This potential source for confusion is avoided requiring that any
any communication using a ULID must be terminated when the ULID communication using a ULID MUST be terminated when the ULID becomes
becomes invalid (due to the underlying prefix becoming invalid). If invalid (due to the underlying prefix becoming invalid). This
that behavior is desired, it can be accomplished by explicitly behaviour can be accomplished by explicitly discarding the shim state
discarding the shim state when the ULID becomes invalid. The context when the ULID becomes invalid. The context recovery mechanism will
recovery mechanism will then make the peer aware that the context is then make the peer aware that the context is gone, and that the ULID
gone, and that the ULID is no longer present at the same locator(s). is no longer present at the same locator(s).
1.6. Placement of the shim 1.6. Placement of the shim
----------------------- -----------------------
| Transport Protocols | | Transport Protocols |
----------------------- -----------------------
------ ------- -------------- ------------- IP endpoint ------ ------- -------------- ------------- IP endpoint
| AH | | ESP | | Frag/reass | | Dest opts | sub-layer | AH | | ESP | | Frag/reass | | Dest opts | sub-layer
------ ------- -------------- ------------- ------ ------- -------------- -------------
skipping to change at page 11, line 27 skipping to change at page 11, line 27
peer performs no destination address selection. peer performs no destination address selection.
Thus in "single prefix multihoming" the site, and in many cases its Thus in "single prefix multihoming" the site, and in many cases its
upstream ISPs, can use BGP to exert some control of the ingress path upstream ISPs, can use BGP to exert some control of the ingress path
used to reach the site. This capability can't easily be recreated in used to reach the site. This capability can't easily be recreated in
"multiple prefix multihoming" such as shim6. "multiple prefix multihoming" such as shim6.
The protocol provides a placeholder, in the form of the Locator The protocol provides a placeholder, in the form of the Locator
Preferences option, which can be used by hosts to express priority Preferences option, which can be used by hosts to express priority
and weight values for each locator. This is intentionally made and weight values for each locator. This is intentionally made
identical to the DNS SRV [9] specification of priority and weight, so identical to the DNS SRV [10] specification of priority and weight,
that DNS SRV records can be used for initial contact and the shim for so that DNS SRV records can be used for initial contact and the shim
failover, and they can use the same way to describe the preferences. for failover, and they can use the same way to describe the
But the Locator Preference option is merely a place holder when it preferences. But the Locator Preference option is merely a place
comes to providing traffic engineering; in order to use this in a holder when it comes to providing traffic engineering; in order to
large site there would have to be a mechanism by which the host can use this in a large site there would have to be a mechanism by which
find out what preference values to use, either statically (e.g., some the host can find out what preference values to use, either
new DHCPv6 option) or dynamically. statically (e.g., some new DHCPv6 option) or dynamically.
Thus traffic engineering is listed as a possible extension in Thus traffic engineering is listed as a possible extension in
Appendix A. Appendix A.
2. Terminology 2. Terminology
This document uses the terms MUST, SHOULD, RECOMMENDED, MAY, SHOULD This document uses the terms MUST, SHOULD, RECOMMENDED, MAY, SHOULD
NOT and MUST NOT defined in RFC 2119 [1]. The terms defined in RFC NOT and MUST NOT defined in RFC 2119 [1]. The terms defined in RFC
2460 [2] are also used. 2460 [2] are also used.
skipping to change at page 14, line 36 skipping to change at page 14, line 36
communication when some ULP decides to start communication when some ULP decides to start
communicating with a peer by sending and communicating with a peer by sending and
receiving ULP packets. Typically this would not receiving ULP packets. Typically this would not
invoke any operations in the shim, since the shim invoke any operations in the shim, since the shim
can defer the context establishment until some can defer the context establishment until some
arbitrary later point in time. arbitrary later point in time.
Hash Based Addresses (HBA) Hash Based Addresses (HBA)
A form of IPv6 address where the interface ID is A form of IPv6 address where the interface ID is
derived from a cryptographic hash of all the derived from a cryptographic hash of all the
prefixes assigned to the host. See [7]. prefixes assigned to the host. See [8].
Cryptographically Generated Addresses (CGA) Cryptographically Generated Addresses (CGA)
A form of IPv6 address where the interface ID is A form of IPv6 address where the interface ID is
derived from a cryptographic hash of the public derived from a cryptographic hash of the public
key. See [6]. key. See [6].
CGA Parameter Data Structure (PDS) CGA Parameter Data Structure (PDS)
The information that CGA and HBA exchanges in The information that CGA and HBA exchanges in
order to inform the peer of how the interface ID order to inform the peer of how the interface ID
was computed. See [6]., [7]. was computed. See [6]., [8].
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.
skipping to change at page 16, line 42 skipping to change at page 16, line 42
In addition, when the site's ISPs perform ingress filtering based on In addition, when the site's ISPs perform ingress filtering based on
packet source addresses, shim6 assumes that packets sent with packet source addresses, shim6 assumes that packets sent with
different source and destination combinations have a reasonable different source and destination combinations have a reasonable
chance of making it through the relevant ISP's ingress filters. This chance of making it through the relevant ISP's ingress filters. This
can be accomplished in several ways (all outside the scope of this can be accomplished in several ways (all outside the scope of this
document), such as having the ISPs relax there ingress filters, or document), such as having the ISPs relax there ingress filters, or
selecting the egress such that it matches the IP source address selecting the egress such that it matches the IP source address
prefix. prefix.
Further discussion of this issue is captured in [20]. Further discussion of this issue is captured in [21].
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.
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 [12] and its extensions [13] work, then there is no Selection [13] and its extensions [14] work, then there is no
action by the shim at this point in time. Any shim context action by the shim at this point in time. Any shim context
establishment can be deferred until later. establishment 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. establishment exchange.
skipping to change at page 20, line 43 skipping to change at page 20, line 43
application has its own failover mechanism (multiple NS records in application has its own failover mechanism (multiple NS records in
the case of DNS) and using the shim could potentially add extra the case of DNS) and using the shim could potentially add extra
latency with no added benefits. latency with no added benefits.
Some other API extensions are discussed in Appendix A Some other API extensions are discussed in Appendix A
4.4. Securing shim6 4.4. Securing shim6
The mechanisms are secured using a combination of techniques: The mechanisms are secured using a combination of techniques:
o The HBA technique [7] for verifying the locators to prevent an o The HBA technique [8] 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 before a new locator is used o Requiring a Reachability Probe+Reply /defined in [9]) before a new
as the destination, in order to prevent 3rd party flooding locator is used as the destination, in order to prevent 3rd party
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
attacks, and to prevent off-path attackers from interfering with attacks, and to prevent off-path attackers from interfering with
the establishment. the establishment.
skipping to change at page 21, line 28 skipping to change at page 21, line 28
technique, the shim6 protocol is protected against off-path technique, the shim6 protocol is protected against off-path
attackers. 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 [25].] message. [The names of these messages are borrowed from HIP [26].]
R1bis and I2bis messages are defined, which are used to recover a R1bis and I2bis messages are defined, which are used to recover a
context after it has been lost. A R1bis message is sent when a shim6 context after it has been lost. A R1bis message is sent when a shim6
control or Payload extension header arrives and there is no matching control or Payload extension header arrives and there is no matching
context state at the receiver. When such a message is received, it context state at the receiver. When such a message is received, it
will result in the re-creation of the shim6 context using the I2bis will result in the re-creation of the shim6 context using the I2bis
and R2 messages. and R2 messages.
The peers' lists of locators are normally exchanged as part of the The peers' lists of locators are normally exchanged as part of the
context establishment exchange. But the set of locators might be context establishment exchange. But the set of locators might be
skipping to change at page 22, line 5 skipping to change at page 22, line 5
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 [8]. rules are specified in [9].
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 an Probe message type, with the packet format and processing reserves a Probe message type, with the packet format and processing
rules specified in [8]. rules specified in [9].
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
[12] [13]. In the future versions of the protocol, and with a richer [13] [14]. 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 39, line 32 skipping to change at page 39, line 32
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.14. option will be handled by an implementation. See Section 5.14.
5.12. Keepalive Message Format 5.12. Keepalive Message Format
This message format is defined in [8]. This message format is defined in [9].
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 [8]. This message and its semantics are defined in [9].
The idea behind that mechanism is to be able to handle the case when The idea behind that mechanism is to be able to handle the case when
one locator pair works in from A to B, and another locator pair works one locator pair works in from A to B, and another locator pair works
from B to A, but there is no locator pair which works in both from B to A, but there is no locator pair which works in both
directions. The protocol mechanism is that as A is sending probe directions. The protocol mechanism is that as A is sending probe
messages to B, B will observe which locator pairs it has received messages to B, B will observe which locator pairs it has received
from and report that back in probe messages it is sending to A. from and report that back in probe messages it is sending to A.
5.14. Option Formats 5.14. 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 [25]. However, there is no intention to track any changes to format [26]. 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 41, line 11 skipping to change at page 41, line 11
implementation might view the C bit as part of the implementation might view the C bit as part of the
Type field, by multiplying the type values in this Type field, by multiplying the type values in this
specification by two. specification by two.
Length: Length of the Contents, in bytes. Length: Length of the Contents, in bytes.
Contents: Parameter specific, defined by Type. Contents: Parameter specific, defined by Type.
Padding: Padding, 0-7 bytes, added if needed. Padding: Padding, 0-7 bytes, added if needed.
+------+---------------------------------+ +------+------------------------------+
| Type | Option Name | | Type | Option Name |
+------+---------------------------------+ +------+------------------------------+
| 1 | Responder Validator | | 1 | Responder Validator |
| | | | | |
| 2 | Locator List | | 2 | Locator List |
| | | | | |
| 3 | Locator Preferences | | 3 | Locator Preferences |
| | | | | |
| 4 | CGA Parameter Data Structure | | 4 | CGA Parameter Data Structure |
| | | | | |
| 5 | CGA Signature | | 5 | CGA Signature |
| | | | | |
| 6 | ULID Pair | | 6 | ULID Pair |
| | | | | |
| 7 | Forked Instance Identifier | | 7 | Forked Instance Identifier |
| | | | | |
| 10 | Probe Option | | 10 | Keepalive Timeout Option |
| | | +------+------------------------------+
| 11 | Reachability Option |
| | |
| 12 | Payload Reception Report Option |
+------+---------------------------------+
Table 2 Table 2
Future protocol extensions might define additional options for the Future protocol extensions might define additional options for the
SHIM6 messages. The C-bit in the option format defines how such a SHIM6 messages. The C-bit in the option format defines how such a
new option will be handled by an implementation. new option will be handled by an implementation.
If a host receives an option that it does not understand (an option If a host receives an option that it does not understand (an option
that was defined in some future extension to this protocol) or is not that was defined in some future extension to this protocol) or is not
listed as a valid option for the different message types above, then listed as a valid option for the different message types above, then
skipping to change at page 44, line 27 skipping to change at page 44, line 27
Table 3 Table 3
5.14.3. Locator Preferences Option Format 5.14.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 [9] for how weight would provide a way to do some load sharing. See [10] 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 46, line 38 skipping to change at page 46, line 38
| Type = 4 |0| Length | | Type = 4 |0| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ CGA Parameter Data Structure ~ ~ CGA Parameter Data Structure ~
~ +-+-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+-+
~ | Padding | ~ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
CGA Parameter Data Structure: Variable length content. Content CGA Parameter Data Structure: Variable length content. Content
defined in [6] and [7]. defined in [6] and [8].
Padding: Padding, 0-7 bytes, added if needed. See Padding: Padding, 0-7 bytes, added if needed. See
Section 5.14. Section 5.14.
5.14.5. CGA Signature Option Format 5.14.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 48, line 47 skipping to change at page 48, line 47
| Type = 7 |0| Length = 4 | | Type = 7 |0| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forked Instance Identifier | | Forked Instance Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
Forked Instance Identifier: 32-bit field containing the identifier of Forked Instance Identifier: 32-bit field containing the identifier of
the particular forked instance. the particular forked instance.
5.14.8. Probe Option Format 5.14.8. Keepalive Timeout Option Format
This option is defined in [8].
5.14.9. Reachability Option Format
This option is defined in [8].
5.14.10. Payload Reception Report Option Format
This option is defined in [8]. This option is defined in [9].
6. Conceptual Model of a Host 6. Conceptual Model of a Host
This section describes a conceptual model of one possible data This section describes a conceptual model of one possible data
structure organization that hosts will maintain for the purposes of structure organization that hosts will maintain for the purposes of
shim6. The described organization is provided to facilitate the shim6. The described organization is provided to facilitate the
explanation of how the shim6 protocol should behave. This document explanation of how the shim6 protocol should behave. This document
does not mandate that implementations adhere to this model as long as does not mandate that implementations adhere to this model as long as
their external behavior is consistent with that described in this their external behavior is consistent with that described in this
document. document.
skipping to change at page 51, line 14 skipping to change at page 50, line 14
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 [8]. o Reachability state for the locator pairs as specified in [9].
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 [8]. have been sent and received as specified in [9].
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:
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| State | Explanation | | State | Explanation |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| IDLE | State machine start | | IDLE | State machine start |
skipping to change at page 53, line 26 skipping to change at page 52, line 26
7.1. Uniqueness of Context Tags 7.1. Uniqueness of Context Tags
As part of establishing a new context, each host has to assign a As part of establishing a new context, each host has to assign a
unique context tag. Since the Payload Extension headers are unique context tag. Since the Payload Extension headers are
demultiplexed based solely on the context tag value (without using demultiplexed based solely on the context tag value (without using
the locators), the context tag MUST be unique for each context. the locators), the context tag MUST be unique for each context.
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 2^47 context tag values,(e.g. SHOULD randomly cycle through the 2^47 context tag values,(e.g.
following the guidelines described in [17]). following the guidelines described in [18]).
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 [19]. These different verifications happen at party flooding attacks [20]. 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 [8]. routability test as part of the Probe sub-protocol [9].
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 generates an ICMP parameter problem (type 4, code 0), with the SHOULD generates an ICMP parameter problem (type 4, code 0), with the
Pointer referencing the octet in the Verification method that was Pointer referencing the octet in the Verification method that was
found inconsistent. found inconsistent.
skipping to change at page 76, line 21 skipping to change at page 75, line 21
then the host MUST verify if the actual PDS contained in the packet then the host MUST verify if the actual PDS contained in the packet
corresponds to the ULID(peer). If this verification fails, the corresponds to the ULID(peer). If this verification fails, the
message is silently discarded. message is silently discarded.
Then, depending on the state of the context: Then, depending on the state of the context:
o If ESTABLISHED: Proceed to process message. o If ESTABLISHED: Proceed to process message.
o If I1-SENT, discard the message and stay in I1-SENT. o If I1-SENT, discard the message and stay in I1-SENT.
o If I2-SENT, then send R2 and proceed to process the message. o If I2-SENT, then send I2 and proceed to process the message.
o If I2BIS-SENT, then send R2 and proceed to process the message. o If I2BIS-SENT, then send I2bis and proceed to process the message.
The verification issues for the locators carried in the Locator The verification issues for the locators carried in the Locator
Update message are specified in Section 7.2. If the locator list can Update message are specified in Section 7.2. If the locator list can
not be verified, this procedure might send an ICMP Parameter Problem not be verified, this procedure might send an ICMP Parameter Problem
error. In any case, if it can not be verified, there is no further error. In any case, if it can not be verified, there is no further
processing of the Update Request. processing of the Update Request.
Once any Locator List option in the Update Request has been verified, Once any Locator List option in the Update Request has been verified,
the peer generation number in the context is updated to be the one in the peer generation number in the context is updated to be the one in
the Locator List option. the Locator List option.
skipping to change at page 77, line 10 skipping to change at page 76, line 10
recorded in the context. recorded in the context.
Once the Locator List option (if present) has been verified and any Once the Locator List option (if present) has been verified and any
new locator list or locator preferences have been recorded, the host new locator list or locator preferences have been recorded, the host
sends an Update Acknowledgement message, copying the nonce from the sends an Update Acknowledgement message, copying the nonce from the
request, and using the CT(peer) in as the Receiver Context Tag. request, and using the CT(peer) in as the Receiver Context Tag.
Any new locators, or more likely new locator preferences, might Any new locators, or more likely new locator preferences, might
result in the host wanting to select a different locator pair for the result in the host wanting to select a different locator pair for the
context. For instance, if the Locator Preferences lists the current context. For instance, if the Locator Preferences lists the current
Lp(peer) as BROKEN. The host uses the Probe message in [8] to verify Lp(peer) as BROKEN. The host uses the Probe message in [9] to verify
that the new locator is reachable before changing Lp(peer). that the new locator is reachable before changing Lp(peer).
10.5. Receiving Update Acknowledgement messages 10.5. Receiving Update Acknowledgement messages
A host MUST silently discard any received Update Acknowledgement A host MUST silently discard any received Update Acknowledgement
messages that do not satisfy all of the following validity checks in messages that do not satisfy all of the following validity checks in
addition to those specified in Section 12.2: addition to those specified in Section 12.2:
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 78, line 30 skipping to change at page 77, 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 [8]. this document and is specified in [9].
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 80, line 27 skipping to change at page 79, line 27
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:
o If ESTABLISHED: Proceed to process message. o If ESTABLISHED: Proceed to process message.
o If I1-SENT, discard the message and stay in I1-SENT. o If I1-SENT, discard the message and stay in I1-SENT.
o If I2-SENT, then send R2 and proceed to process the message. o If I2-SENT, then send I2 and proceed to process the message.
o If I2BIS-SENT, then send R2 and proceed to process the message. o If I2BIS-SENT, then send I2bis and proceed to process the message.
With the context in hand, the receiver can now replace the IP address With the context in hand, the receiver can now replace the IP address
fields with the ULIDs kept in the context. Finally, the Payload fields with the ULIDs kept in the context. Finally, the Payload
extension header is removed from the packet (so that the ULP doesn't extension header is removed from the packet (so that the ULP doesn't
get confused by it), and the next header value in the preceding get confused by it), and the next header value in the preceding
header is set to be the actual protocol number for the payload. Then header is set to be the actual protocol number for the payload. Then
the packet can be passed to the protocol identified by the next the packet can be passed to the protocol identified by the next
header value (which might be some function associated with the IP header value (which might be some function associated with the IP
endpoint sublayer, or a ULP). endpoint sublayer, or a ULP).
skipping to change at page 83, line 18 skipping to change at page 82, 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 [12], and some fixes to that specification [13] to make it Selection [13], and some fixes to that specification [14] 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 85, line 12 skipping to change at page 84, line 12
second retransmission [0.5*8, 1.5*8] seconds after the first one, second retransmission [0.5*8, 1.5*8] seconds after the first one,
etc. etc.
15. Implications Elsewhere 15. Implications Elsewhere
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. The key implications are: solution, has implications elsewhere. The key implications are:
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 [22]. But in order for such applications to be as described in [23]. 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 Firewalls that today pass limited traffic, e.g., outbound TCP o Firewalls that today pass limited traffic, e.g., outbound TCP
connections, would presumably block the shim6 protocol. This connections, would presumably block the shim6 protocol. This
means that even when shim6 capable hosts are communicating, the I1 means that even when shim6 capable hosts are communicating, the I1
skipping to change at page 87, line 7 skipping to change at page 86, line 7
local to the sending host, thus conveying the change to the ULPs local to the sending host, thus conveying the change to the ULPs
is an implementation matter. is an implementation matter.
o The precise interaction between Mobile IPv6 and shim6 is for o The precise interaction between Mobile IPv6 and shim6 is for
further study, but it might make sense to have Mobile IPv6 operate further study, but it might make sense to have Mobile IPv6 operate
on locators, meaning that the shim would be layered on top of the on locators, meaning that the shim would be layered on top of the
MIPv6 mechanism. MIPv6 mechanism.
16. Security Considerations 16. Security Considerations
This document satisfies the concerns specified in [19] as follows: This document satisfies the concerns specified in [20] as follows:
o The HBA technique [7] for verifying the locators to prevent an o The HBA [6] and CGA technique [8] for verifying the locators to
attacker from redirecting the packet stream to somewhere else. prevent an attacker from redirecting the packet stream to
somewhere else. The minimum acceptable key length for public keys
used in the generation of CGAs SHOULD be 1024 bits. Any
implementation should follow prudent cryptographic practice in
determining the appropriate key lengths.
o Requiring a Reachability Probe+Reply before a new locator is used o Requiring a Reachability Probe+Reply before a new locator is used
as the destination, in order to prevent 3rd party flooding as the destination, in order to prevent 3rd party flooding
attacks. attacks.
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, cosnuming his own resources requires the attacker to create state, cosnuming his own resources
skipping to change at page 87, line 36 skipping to change at page 86, line 40
o Every control message of the shim6 protocol, past the context o Every control message of the shim6 protocol, past the context
establishment, carry the context tag assigned to the particular establishment, carry the context tag assigned to the particular
context. This implies that an attacker needs to discover that context. This implies that an attacker needs to discover that
context tag before being able to spoof any shim6 control message. context tag before being able to spoof any shim6 control message.
Such discovery probably requires to be along the path in order to Such discovery probably requires to be along the path in order to
be sniff the context tag value. The result is that through this be sniff the context tag value. The result is that through this
technique, the shim6 protocol is protected against off-path technique, the shim6 protocol is protected against off-path
attackers. attackers.
Interaction with IPSec
The shim6 sub-layer is implemented below the IPSec layer within the
IP layer. This deserves some additional considerations for a couple
of specific cases: First, it should be noted that the shim6 approach
does not preclude using IPSEC tunnels on shim6 packets within the
network transit path. Second, in case that IPSec is implemented as
Bump-In-The-Wire (BITW) [7] it is expected that the shim6 sub-layer
is also implemnted in the same fashion.
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 90, line 27 skipping to change at page 90, line 27
| 4 | CGA Parameter Data Structure | | 4 | CGA Parameter Data Structure |
| | | | | |
| 5 | CGA Signature | | 5 | CGA Signature |
| | | | | |
| 6 | ULID Pair | | 6 | ULID Pair |
| | | | | |
| 7 | Forked Instance Identifier | | 7 | Forked Instance Identifier |
| | | | | |
| 8-9 | Allocated using Standards action | | 8-9 | Allocated using Standards action |
| | | | | |
| 10 | Probe Option | | 10 | Keepalive Timeout Option |
| | |
| 11 | Reachability Option |
| | |
| 12 | Payload Reception Report Option |
| | | | | |
| 13-16383 | Allocated using Standards action | | 11-16383 | Allocated using Standards action |
| | | | | |
| 16384-32767 | For Experimental use | | 16384-32767 | For Experimental use |
+-------------+----------------------------------+ +-------------+----------------------------------+
18. Acknowledgements 18. Acknowledgements
Over the years many people active in the multi6 and shim6 WGs have Over the years many people active in the multi6 and shim6 WGs have
contributed ideas a suggestions that are reflected in this contributed ideas a suggestions that are reflected in this
specification. Special thanks to the careful comments from Geoff specification. Special thanks to the careful comments from Geoff
Huston, Shinta Sugimoto, Pekka Savola, Dave Meyer, Deguang Le and Jim Huston, Shinta Sugimoto, Pekka Savola, Dave Meyer, Deguang Le, Jari
Bound on earlier versions of this draft. Arkko, Iljitsch van Beijnum, Jim Bound, Brian Carpenter, Sebastien
Barre and Tom Henderson on earlier versions of this document.
Appendix A. Possible Protocol Extensions Appendix A. Possible Protocol Extensions
During the development of this protocol, several issues have been During the development of this protocol, several issues have been
brought up as important one to address, but are ones that do not need brought up as important one to address, but are ones that do not need
to be in the base protocol itself but can instead be done as to be in the base protocol itself but can instead be done as
extensions to the protocol. The key ones are: extensions to the protocol. The key ones are:
o As stated in the assumptions in Section 3, the in order for the o As stated in the assumptions in Section 3, the in order for the
shim6 protocol to be able to recover from a wide range of shim6 protocol to be able to recover from a wide range of
failures, for instance when one of the communicating hosts is failures, for instance when one of the communicating hosts is
singly-homed, and cope with a site's ISPs that do ingress singly-homed, and cope with a site's ISPs that do ingress
filtering based on the source IPv6 address, there is a need for filtering based on the source IPv6 address, there is a need for
the host to be able to influence the egress selection from its the host to be able to influence the egress selection from its
site. Further discussion of this issue is captured in [20]. site. Further discussion of this issue is captured in [21].
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 93, line 45 skipping to change at page 93, line 45
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 [21]. initial draft on this topic [22].
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 100, line 42 skipping to change at page 100, line 42
| | |R2/Null +-------------+ | | | | |R2/Null +-------------+ | |
| | +----------+ |R1/I2 | | | | +----------+ |R1/I2 | |
| | | V | | | | | V | |
| | +------------------+ | | | | +------------------+ | |
| | | |-------------+ | | | | |-------------+ |
| | | I2-SENT | (Timeout#>Max)/I1 | | | | I2-SENT | (Timeout#>Max)/I1 |
| | | | | | | | | |
| | +------------------+ | | | +------------------+ |
| | | ^ | | | | ^ |
| | +--------------+ | | | +--------------+ |
| | I1 or I2bis or I2 or Payload/R2 | | | I1 or I2bis or I2/R2 |
| | (Timeout#<Max)/I2 | | | (Timeout#<Max) or Payload/I2 |
| | R1 or R1bis/Null | | | R1 or R1bis/Null |
| +-------+ (Timeout#>Max)/I1 | | +-------+ (Timeout#>Max)/I1 |
| R2/Null| +------------------------------------------+ | R2/Null| +------------------------------------------+
| V | | V |
| +-------------------+ | +-------------------+
| | |<-+ (Timeout#<Max)/I2bis | | |<-+ (Timeout#<Max)/I2bis
+-------->| I2bis-SENT | | I1 or I2 or I2bis/R2 +-------->| I2bis-SENT | | I1 or I2 or I2bis/R2
R1bis/I2bis | |--+ R1 or R1bis/Null R1bis/I2bis | |--+ R1 or R1bis/Null
+-------------------+ Payload/R2 +-------------------+ Payload/I2bis
Appendix C. Context Tag Reuse Appendix C. Context Tag Reuse
The shim6 protocol doesn't have a mechanism for coordinated state The shim6 protocol doesn't have a mechanism for coordinated state
removal between the peers, because such state removal doesn't seem to removal between the peers, because such state removal doesn't seem to
help given that a host can crash and reboot at any time. A result of help given that a host can crash and reboot at any time. A result of
this is that the protocol needs to be robust against a context tag this is that the protocol needs to be robust against a context tag
being reused for some other context. This section summarizes the being reused for some other context. This section summarizes the
different cases in which a tag can be reused, and how the recovery different cases in which a tag can be reused, and how the recovery
works. works.
skipping to change at page 106, line 14 skipping to change at page 106, line 14
which stage of the communication they decide, based on their own which stage of the communication they decide, based on their own
policies, that a given communication requires to be protected by the policies, that a given communication requires to be protected by the
shim. 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 [16]). The packets sent after a failure when a or as suggested in [17]). 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 109, line 47 skipping to change at page 109, line 47
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 [19]. The goal in terms of of redirection attacks as described in [20]. 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 111, line 19 skipping to change at page 111, line 19
is the usage of digital certificates. This implies that an IPsec is the usage of digital certificates. This implies that an IPsec
based solution would require that the generation of digital based solution would require that the generation of digital
certificates that bind the key and the ULID by a common third trusted certificates that bind the key and the ULID by a common third trusted
party for both parties involved in the communication. Considering party for both parties involved in the communication. Considering
that the scope of application of the shim protocol is global, this that the scope of application of the shim protocol is global, this
would imply a global public key infrastructure. The major issues would imply a global public key infrastructure. The major issues
with this approach are the deployment difficulties associated with a with this approach are the deployment difficulties associated with a
global PKI. global PKI.
Finally two different technologies were selected to protect the shim Finally two different technologies were selected to protect the shim
protocol: HBA [7] and CGA [6]. These two approaches provide a protocol: HBA [8] and CGA [6]. 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 113, line 51 skipping to change at page 113, line 51
In the unilateral approach, each node discards the information about In the unilateral approach, each node discards the information about
the other node without coordination with the other node based on some the other node without coordination with the other node based on some
local timers and heuristics. No packet exchange is required for local timers and heuristics. No packet exchange is required for
this. In this case, it would be possible that one of the nodes has this. In this case, it would be possible that one of the nodes has
discarded the state while the other node still hasn't. In this case, discarded the state while the other node still hasn't. In this case,
a No-Context error message may be required to inform about the a No-Context error message may be required to inform about the
situation and possibly a recovery mechanism is also needed. situation and possibly a recovery mechanism is also needed.
A coordinated approach would use an explicit CLOSE mechanism, akin to A coordinated approach would use an explicit CLOSE mechanism, akin to
the one specified in HIP [25]. If an explicit CLOSE handshake and the one specified in HIP [26]. 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 116, line 9 skipping to change at page 116, line 9
because premature garbage collection, but it does not prevents the because premature garbage collection, but it does not prevents 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-06:
o Changed wording in the renumberin considerations section, so that
a shim6 context using a ULID that has been renumbered, MUST be
discarded
o Included text in the security considerations about IPSec BITW and
IPSec tunnels.
o Added text about the minimum key length of CGA in the security
considerations section
o fixed Payload/update message processing
o synchonized with READ draft
The following changes have been made since draft-ietf-shim6-proto-05: The following changes have been made since draft-ietf-shim6-proto-05:
o Removed the possibility to keep on uding the ULID after a o Removed the possibility to keep on uding the ULID after a
renumbering event renumbering event
o Editorial corrections resulting from Dave Meyer's and Jim Bound's o Editorial corrections resulting from Dave Meyer's and Jim Bound's
reviews. reviews.
The following changes have been made since draft-ietf-shim6-proto-04: The following changes have been made since draft-ietf-shim6-proto-04:
skipping to change at page 117, line 25 skipping to change at page 117, line 41
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 [8]. Only the message type values and option and Event option to [9]. 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 120, line 28 skipping to change at page 120, line 28
[4] Thomson, S. and T. Narten, "IPv6 Stateless Address [4] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[5] Conta, A. and S. Deering, "Internet Control Message Protocol [5] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6) (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998. Specification", RFC 2463, December 1998.
[6] Aura, T., "Cryptographically Generated Addresses (CGA)", [6] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
[7] Bagnulo, M., "Hash Based Addresses (HBA)", [7] Kent, S. and K. Seo, "Security Architecture for the Internet
draft-ietf-shim6-hba-01 (work in progress), September 2006. Protocol", RFC 4301, December 2005.
[8] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair [8] Bagnulo, M., "Hash Based Addresses (HBA)",
draft-ietf-shim6-hba-02 (work in progress), October 2006.
[9] 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-06 (work in progress), draft-ietf-shim6-failure-detection-06 (work in progress),
September 2006. September 2006.
19.2. Informative References 19.2. Informative References
[9] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [10] 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.
[10] Ferguson, P. and D. Senie, "Network Ingress Filtering: [11] 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.
[11] Narten, T. and R. Draves, "Privacy Extensions for Stateless [12] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001. Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[12] Draves, R., "Default Address Selection for Internet Protocol [13] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003. version 6 (IPv6)", RFC 3484, February 2003.
[13] Bagnulo, M., "Updating RFC 3484 for multihoming support", [14] 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.
[14] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [15] 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.
[15] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- [16] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-
Multihoming Architectures", RFC 3582, August 2003. Multihoming Architectures", RFC 3582, August 2003.
[16] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 [17] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6
Flow Label Specification", RFC 3697, March 2004. Flow Label Specification", RFC 3697, March 2004.
[17] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [18] 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.
[18] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [19] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[19] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming [20] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming
Solutions", RFC 4218, October 2005. Solutions", RFC 4218, October 2005.
[20] Huitema, C., "Ingress filtering compatibility for IPv6 [21] 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.
[21] Bagnulo, M. and E. Nordmark, "SHIM - MIPv6 Interaction", [22] 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.
[22] Nordmark, E., "Shim6 Application Referral Issues", [23] 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.
[23] Bagnulo, M. and J. Abley, "Applicability Statement for the [24] 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-01 (work in progress), draft-ietf-shim6-applicability-02 (work in progress),
June 2006. October 2006.
[24] Huston, G., "Architectural Commentary on Site Multi-homing [25] Huston, G., "Architectural Commentary on Site Multi-homing
using a Level 3 Shim", draft-ietf-shim6-arch-00 (work in using a Level 3 Shim", draft-ietf-shim6-arch-00 (work in
progress), July 2005. progress), July 2005.
[25] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-06 [26] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-06
(work in progress), June 2006. (work in progress), June 2006.
[26] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", [27] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)",
draft-ietf-mobike-protocol-08 (work in progress), draft-ietf-mobike-protocol-08 (work in progress),
February 2006. February 2006.
Authors' Addresses Authors' Addresses
Erik Nordmark Erik Nordmark
Sun Microsystems Sun Microsystems
17 Network Circle 17 Network Circle
Menlo Park, CA 94025 Menlo Park, CA 94025
USA USA
 End of changes. 89 change blocks. 
176 lines changed or deleted 192 lines changed or added

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