draft-ietf-shim6-proto-01.txt   draft-ietf-shim6-proto-02.txt 
SHIM6 WG E. Nordmark SHIM6 WG E. Nordmark
Internet-Draft Sun Microsystems Internet-Draft Sun Microsystems
Expires: March 5, 2006 September 2005 Expires: March 5, 2006 September 2005
Level 3 multihoming shim protocol Level 3 multihoming shim protocol
draft-ietf-shim6-proto-01.txt draft-ietf-shim6-proto-02.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 45 skipping to change at page 1, line 45
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
The SHIM6 working group is exploring a layer 3 shim approach for The SHIM6 working group is exploring a layer 3 shim approach 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 spreading multihoming can be provided for IPv6 with failover and load spreading
properties, without assuming that a multihomed site will have a properties, without assuming that a multihomed site will have a
provider independent IPv6 address which is announced in the global provider independent IPv6 address prefix which is announced in the
IPv6 routing table. The hosts in a site which has multiple provider global IPv6 routing table. The hosts in a site which has multiple
allocated IPv6 address prefixes, will use the shim6 protocol provider 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.
This document picks a particular approach to such a protocol and This document picks a particular approach to such a protocol and
tries to flush out a bunch of details, with the hope that the WG can tries to flush out a bunch of details, with the hope that the WG can
better understand the details in this proposal as well as discovering better understand the details in this proposal as well as discovering
and understanding alternative designs that might be better. Thus and understanding alternative designs that might be better. Thus
this proposal is my no means cast in stone as the direction; quite to this proposal is my no means cast in stone as the direction; quite to
the contrary it is a depth first exploration of the design space. the contrary it is a depth first exploration of the design space.
skipping to change at page 2, line 24 skipping to change at page 2, line 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Locators as Upper-layer Identifiers . . . . . . . . . . . 5 1.3 Locators as Upper-layer Identifiers . . . . . . . . . . . 5
1.4 IP Multicast . . . . . . . . . . . . . . . . . . . . . . . 6 1.4 IP Multicast . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Renumbering Implications . . . . . . . . . . . . . . . . . 6 1.5 Renumbering Implications . . . . . . . . . . . . . . . . . 6
1.6 Placement of the shim . . . . . . . . . . . . . . . . . . 7 1.6 Placement of the shim . . . . . . . . . . . . . . . . . . 7
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 9 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 9 2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Notational Conventions . . . . . . . . . . . . . . . . . . 10 2.2 Notational Conventions . . . . . . . . . . . . . . . . . . 11
3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 11 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 12
4.1 Context Tags . . . . . . . . . . . . . . . . . . . . . . . 13 4.1 Context Tags . . . . . . . . . . . . . . . . . . . . . . . 13
4.2 Securing shim6 . . . . . . . . . . . . . . . . . . . . . . 14 4.2 Securing shim6 . . . . . . . . . . . . . . . . . . . . . . 14
4.3 Overview of Shim Control Messages . . . . . . . . . . . . 14 4.3 Overview of Shim Control Messages . . . . . . . . . . . . 14
5. Message Formats . . . . . . . . . . . . . . . . . . . . . . 15 4.4 Locator Validation . . . . . . . . . . . . . . . . . . . . 16
5.1 Payload Message Format . . . . . . . . . . . . . . . . . . 15 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . 16
5.2 Common Shim6 Control header . . . . . . . . . . . . . . . 16 5.1 Common shim6 Message Format . . . . . . . . . . . . . . . 16
5.3 I1 Message Format . . . . . . . . . . . . . . . . . . . . 17 5.2 Payload Message Format . . . . . . . . . . . . . . . . . . 17
5.4 R1 Message Format . . . . . . . . . . . . . . . . . . . . 18 5.3 Common Shim6 Control header . . . . . . . . . . . . . . . 17
5.5 I2 Message Format . . . . . . . . . . . . . . . . . . . . 19 5.4 I1 Message Format . . . . . . . . . . . . . . . . . . . . 19
5.6 R2 Message Format . . . . . . . . . . . . . . . . . . . . 21 5.5 R1 Message Format . . . . . . . . . . . . . . . . . . . . 20
5.7 No Context Error Message Format . . . . . . . . . . . . . 22 5.6 I2 Message Format . . . . . . . . . . . . . . . . . . . . 21
5.8 Update Request Message Format . . . . . . . . . . . . . . 23 5.7 R2 Message Format . . . . . . . . . . . . . . . . . . . . 22
5.9 Update Acknowledgement Message Format . . . . . . . . . . 24 5.8 No Context Error Message Format . . . . . . . . . . . . . 23
5.10 Reachability Probe Message Format . . . . . . . . . . . 24 5.9 Update Request Message Format . . . . . . . . . . . . . . 24
5.11 Reachability Reply Message Format . . . . . . . . . . . 25 5.10 Update Acknowledgement Message Format . . . . . . . . . 25
5.12 Keepalive Message Format . . . . . . . . . . . . . . . . 26 5.11 Reachability Probe Message Format . . . . . . . . . . . 26
5.13 Context Locator Pair Explore Message Format . . . . . . 27 5.12 Reachability Reply Message Format . . . . . . . . . . . 27
5.14 Option Formats . . . . . . . . . . . . . . . . . . . . . 28 5.13 Keepalive Message Format . . . . . . . . . . . . . . . . 28
5.14.1 Validator Option Format . . . . . . . . . . . . . . 29 5.14 SHIM6 Probe Message Format . . . . . . . . . . . . . . . 29
5.14.2 Locator List Option Format . . . . . . . . . . . . . 30 5.15 Option Formats . . . . . . . . . . . . . . . . . . . . . 29
5.14.3 Locator Preferences Option Format . . . . . . . . . 31 5.15.1 Validator Option Format . . . . . . . . . . . . . . 30
5.14.4 CGA Parameter Data Structure Option Format . . . . . 32 5.15.2 Locator List Option Format . . . . . . . . . . . . . 31
5.14.5 CGA Signature Option Format . . . . . . . . . . . . 33 5.15.3 Locator Preferences Option Format . . . . . . . . . 32
5.14.6 ULID Pair Option Format . . . . . . . . . . . . . . 33 5.15.4 CGA Parameter Data Structure Option Format . . . . . 33
5.14.7 Packet In Error Option Format . . . . . . . . . . . 34 5.15.5 CGA Signature Option Format . . . . . . . . . . . . 34
5.14.8 Explorer Results Option Format . . . . . . . . . . . 34 5.15.6 ULID Pair Option Format . . . . . . . . . . . . . . 34
5.15.7 Packet In Error Option Format . . . . . . . . . . . 35
5.15.8 SHIM6 Event Option Format . . . . . . . . . . . . . 35
6. Conceptual Model of a Host . . . . . . . . . . . . . . . . . 35 6. Conceptual Model of a Host . . . . . . . . . . . . . . . . . 35
6.1 Conceptual Data Structures . . . . . . . . . . . . . . . . 36 6.1 Conceptual Data Structures . . . . . . . . . . . . . . . . 36
7. Establishing Host Pair Contexts . . . . . . . . . . . . . . 36 7. Establishing Host Pair Contexts . . . . . . . . . . . . . . 36
7.1 Normal context establishment . . . . . . . . . . . . . . . 37 7.1 Normal context establishment . . . . . . . . . . . . . . . 36
7.2 Concurrent context establishment . . . . . . . . . . . . . 37 7.2 Concurrent context establishment . . . . . . . . . . . . . 37
7.3 Context recovery . . . . . . . . . . . . . . . . . . . . . 38 7.3 Context recovery . . . . . . . . . . . . . . . . . . . . . 38
7.4 Context confusion . . . . . . . . . . . . . . . . . . . . 39 7.4 Context confusion . . . . . . . . . . . . . . . . . . . . 39
7.5 Sending I1 messages . . . . . . . . . . . . . . . . . . . 40 7.5 Sending I1 messages . . . . . . . . . . . . . . . . . . . 40
7.6 Receiving I1 messages . . . . . . . . . . . . . . . . . . 40 7.6 Receiving I1 messages . . . . . . . . . . . . . . . . . . 40
7.7 Receiving R1 messages . . . . . . . . . . . . . . . . . . 41 7.7 Receiving R1 messages . . . . . . . . . . . . . . . . . . 41
7.8 Retransmitting I2 messages . . . . . . . . . . . . . . . . 41 7.8 Retransmitting I2 messages . . . . . . . . . . . . . . . . 41
7.9 Receiving I2 messages . . . . . . . . . . . . . . . . . . 41 7.9 Receiving I2 messages . . . . . . . . . . . . . . . . . . 41
7.10 Receiving R2 messages . . . . . . . . . . . . . . . . . 42 7.10 Receiving R2 messages . . . . . . . . . . . . . . . . . 42
8. No Such Content Errors . . . . . . . . . . . . . . . . . . . 42 8. No Such Content Errors . . . . . . . . . . . . . . . . . . . 42
9. Handling ICMP Error Messages . . . . . . . . . . . . . . . . 42 9. Handling ICMP Error Messages . . . . . . . . . . . . . . . . 42
10. Teardown of the Host Pair Context . . . . . . . . . . . . . 43 10. Teardown of the Host Pair Context . . . . . . . . . . . . . 43
11. Updating the Locator Pairs . . . . . . . . . . . . . . . . . 43 11. Updating the Locator Pairs . . . . . . . . . . . . . . . . . 44
12. Various Probe Mechanisms . . . . . . . . . . . . . . . . . . 43 12. Various Probe Mechanisms . . . . . . . . . . . . . . . . . . 44
13. Rehoming to a Different Locator Pair . . . . . . . . . . . . 43 13. Rehoming to a Different Locator Pair . . . . . . . . . . . . 44
14. Payload Packets before a Switch . . . . . . . . . . . . . . 43 14. Sending ULP Payloads . . . . . . . . . . . . . . . . . . . . 44
15. Payload Packets after a Switch . . . . . . . . . . . . . . . 44 14.1 Sending ULP Payload after a Switch . . . . . . . . . . . 45
16. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 45 15. Receiving Packets . . . . . . . . . . . . . . . . . . . . . 45
17. Design Alternatives . . . . . . . . . . . . . . . . . . . . 46 16. Initial Contact . . . . . . . . . . . . . . . . . . . . . . 46
17.1 State Cleanup . . . . . . . . . . . . . . . . . . . . . 46 17. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 46
17.2 Detecting Context Loss . . . . . . . . . . . . . . . . . 46
18. Implications Elsewhere . . . . . . . . . . . . . . . . . . . 47 18. Implications Elsewhere . . . . . . . . . . . . . . . . . . . 47
19. Security Considerations . . . . . . . . . . . . . . . . . . 48 19. Security Considerations . . . . . . . . . . . . . . . . . . 48
20. IANA Considerations . . . . . . . . . . . . . . . . . . . . 48 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . 49
21. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 49 21. Possible Protocol Extensions . . . . . . . . . . . . . . . . 49
22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 22. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 50
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50
23.1 Normative References . . . . . . . . . . . . . . . . . . 49 A. Design Alternatives . . . . . . . . . . . . . . . . . . . . 51
23.2 Informative References . . . . . . . . . . . . . . . . . 50 A.1 Context granularity . . . . . . . . . . . . . . . . . . . 51
Author's Address . . . . . . . . . . . . . . . . . . . . . . 51 A.2 Demultiplexing of data packets in shim6 communications . . 51
Intellectual Property and Copyright Statements . . . . . . . 52 A.2.1 Flow-label . . . . . . . . . . . . . . . . . . . . . . 52
A.2.2 Extension Header . . . . . . . . . . . . . . . . . . . 54
A.3 Context Loss Detection . . . . . . . . . . . . . . . . . . 54
A.4 Securing locator sets . . . . . . . . . . . . . . . . . . 57
A.5 Host-pair context establishment exchange . . . . . . . . . 59
A.6 Updating locator sets . . . . . . . . . . . . . . . . . . 60
A.7 State Cleanup . . . . . . . . . . . . . . . . . . . . . . 61
24. References . . . . . . . . . . . . . . . . . . . . . . . . . 61
24.1 Normative References . . . . . . . . . . . . . . . . . . 61
24.2 Informative References . . . . . . . . . . . . . . . . . 62
Author's Address . . . . . . . . . . . . . . . . . . . . . . 63
Intellectual Property and Copyright Statements . . . . . . . 64
1. Introduction 1. Introduction
The SHIM6 working group, and the MULTI6 WG that preceded it, is The SHIM6 working group, and the MULTI6 WG that preceded it, is
exploring a layer 3 shim approach for providing locator agility below exploring a layer 3 shim approach for providing locator agility below
the transport protocols, so that multihoming can be provided for IPv6 the transport protocols, so that multihoming can be provided for IPv6
with failover and load spreading properties [13], without assuming with failover and load spreading properties [14], without assuming
that a multihomed site will have a provider independent IPv6 address that a multihomed site will have a provider independent IPv6 address
which is announced in the global IPv6 routing table. The hosts in a which is announced in the global IPv6 routing table. The hosts in a
site which has multiple provider allocated IPv6 address prefixes, site which has multiple provider allocated IPv6 address prefixes,
will use the shim6 protocol specified in this document to setup state will use the shim6 protocol specified in this document to setup state
with peer hosts, so that the state can later be used to failover to a with peer hosts, so that the state can later be used to failover to a
different locator pair, should the original one stop working. different locator pair, should the original one stop working.
This document takes the outlines contained in [21] and [20] and This document takes the outlines contained in [22] and [21] and
expands to an actual proposed protocol. expands to an actual proposed protocol.
We assume that redirection attacks are prevented using the mechanism We assume that redirection attacks are prevented using the mechanism
specified in HBA [5]. specified in HBA [6].
The WG mailing list is discussing the scheme used for reachability The WG mailing list is discussing the scheme used for reachability
detection [6]. The schemes that are being discussed are Context detection [7]. The schemes that are being discussed are Context
Unreachability Detection (CUD) or Force Bidirectional communication Unreachability Detection (CUD) or Force Bidirectional communication
Detection (FBD). This document doesn't discuss the tradeoffs between Detection (FBD). This document doesn't discuss the tradeoffs between
the two, but it does suggest a set of keepalive and probe messages the two, but it does suggest a set of keepalive and probe messages
that are sufficient to handle both. Once the WG has decided which that are sufficient to handle both. Once the WG has decided which
approach to take, we can remove the unneeded messages. approach to take, we can remove the unneeded messages.
There is a related but slightly separate issue of how the hosts can There is a related but slightly separate issue of how the hosts can
find which of the locator pairs is working after a failure. This is find which of the locator pairs is working after a failure. This is
discussed in [7]. We don't yet know how these details will be done, discussed in [8].
but this draft specifies a separate "Explore" message as a
placeholder for such a protocol mechanism. NOTE that the direction taken in the latest version of [8] is to use
FBD and some new SHIM6 message types. Some of that work has been
reflected in this document, but there are other edits that remain.
1.1 Goals 1.1 Goals
The goals for this approach is to: The goals for this approach is to:
o Preserve established communications through failures, for example, o Preserve established communications through failures, for example,
TCP connections and application communications using UDP. TCP connections and application communications using UDP.
o Have no impact on upper layer protocols in general and on o Have no impact on upper layer protocols in general and on
transport protocols in particular. transport protocols in particular.
o Address the security threats in [16] through a separate document o Address the security threats in [17] through a separate document
[5], and techniques described in this document. [6], and techniques described in this document.
o No extra roundtrip for setup; deferred setup. o No extra roundtrip for setup; deferred setup.
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. connections) might use different locators of the host.
1.2 Non-Goals 1.2 Non-Goals
The assumption is that the problem we are trying to solve is site The assumption is that the problem we are trying to solve is site
multihoming, with the ability to have the set of site locator multihoming, with the ability to have the set of site locator
prefixes change over time due to site renumbering. Further, we prefixes change over time due to site renumbering. Further, we
skipping to change at page 5, line 33 skipping to change at page 5, line 33
furthermore doesn't seem to help) to solve the multihoming problem. furthermore doesn't seem to help) to solve the multihoming problem.
1.3 Locators as Upper-layer Identifiers 1.3 Locators as Upper-layer Identifiers
Central to this approach is to not introduce a new identifier name Central to this approach is to not introduce a new identifier name
space but instead use one of the locators as the upper-layer ID, space but instead use one of the locators as the upper-layer ID,
while allowing the locators used in the address fields to change over while allowing the locators used in the address fields to change over
time in response to failures of using the original locator. time in response to failures of using the original locator.
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 [11]. Underneath, and address selection as specified in [12]. 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. When with the initial locator pair being the ULID pair. When
communication fails the shim can test and select alternate locators. communication 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 [17] for further discussion of the application unreachable. See [18] for further discussion of the application
implications. implications.
There has been some discussion of using non-routable locators, such There has been some discussion of using non-routable locators, such
as unique-local addresses [15], as ULIDs in a multihoming solution. as unique-local addresses [16], as ULIDs in a multihoming solution.
While this document doesn't specify all aspects of this, it is While this document doesn't specify all aspects of this, it is
believed that the approach can be extended to handle such a case. believed that the approach can be extended to handle such a case.
For example, the protocol already needs to handle ULIDs that are not For example, the protocol already needs to handle ULIDs that are not
initially reachable. Thus the same mechanism can handle ULIDs that initially reachable. Thus the same mechanism can handle ULIDs that
are permanently unreachable from outside their site. The issue are permanently unreachable from outside their site. The issue
becomes how to make the protocol perform well when the ULID is not becomes how to make the protocol perform well when the ULID is not
reachable, for instance, avoiding any timeout and retries in this reachable, for instance, avoiding any timeout and retries in this
case. In addition one would need to understand how the ULAs would be case. In addition one would need to understand how the ULAs would be
entered in the DNS to avoid a performance impact on existing, non- entered in the DNS to avoid a performance impact on existing, non-
shim6 aware, IPv6 hosts potentially trying to communicate to the shim6 aware, IPv6 hosts potentially trying to communicate to the
(unreachable) ULA. (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. the destination group to determine where to forward the packet.
(This isn't much different than the situation with widely implemented (This isn't much different than the situation with widely implemented
ingress filtering [9] for unicast.) ingress filtering [10] 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 [12], shim. This is quite a natural fit for protocols which use RTP [13],
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.
1.5 Renumbering Implications 1.5 Renumbering Implications
As stated above, this approach does not try to make communication As stated above, this approach does not try to make communication
survive renumbering. However, the fact that a ULID might be used survive renumbering. However, the fact that a ULID might be used
with a different locator over time open up the possibility that with a different locator over time open up the possibility that
communication between two ULIDs might continue to work after one or communication between two ULIDs might continue to work after one or
skipping to change at page 7, line 9 skipping to change at page 7, line 9
ULID while both of them are communicating with the same host. 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 can be avoided if we require that
any communication using a ULID must be terminated when the ULID any communication using a ULID must be terminated when the ULID
becomes invalid (due to the underlying prefix becoming invalid). becomes invalid (due to the underlying prefix becoming invalid).
However, this might be an overkill. Even when an IPv6 prefix is However, this might be an overkill. Even when an IPv6 prefix is
retired and reassigned to some other site, there is still a very retired and reassigned to some other site, there is still a very
small probability that another host in that site picks the same 128 small probability that another host in that site picks the same 128
bit address (whether using DHCPv6, stateless address bit address (whether using DHCPv6, stateless address
autoconfiguration, or picking a random interface ID [10]). Should autoconfiguration, or picking a random interface ID [11]). Should
the identical address be used by another host, then there still the identical address be used by another host, then there still
wouldn't be a problem until that host attempts to communicate with wouldn't be a problem until that host attempts to communicate with
the same host with which the initial user of the IPv6 address was the same host with which the initial user of the IPv6 address was
communicating. communicating.
1.6 Placement of the shim 1.6 Placement of the shim
----------------------- -----------------------
| Transport Protocols | | Transport Protocols |
----------------------- -----------------------
skipping to change at page 7, line 38 skipping to change at page 7, line 38
------ IP routing ------ IP routing
| IP | sub-layer | IP | sub-layer
------ ------
Figure 1: Protocol stack Figure 1: Protocol stack
The proposal uses an multihoming shim layer within the IP layer, The proposal uses an multihoming shim layer within the IP layer,
i.e., below the ULPs, as shown in Figure 1, in order to provide ULP i.e., below the ULPs, as shown in Figure 1, in order to provide ULP
independence. The multihoming shim layer behaves as if it is independence. The multihoming shim layer behaves as if it is
associated with an extension header, which would be ordered associated with an extension header, which would be placed after any
immediately after any hop-by-hop options in the packet. However, routing-related headers in the packet (such as any hop-by-hop
when the locator pair is the ULID pair there is no data that needs to options, or routing header). However, when the locator pair is the
be carried in an extension header, thus none is needed in that case. ULID pair there is no data that needs to be carried in an extension
header, thus none is needed in that case.
Layering AH and ESP above the multihoming shim means that IPsec can Layering AH and ESP above the multihoming shim means that IPsec can
be made to be unaware of locator changes the same way that transport be made to be unaware of locator changes the same way that transport
protocols can be unaware. Thus the IPsec security associations protocols can be unaware. Thus the IPsec security associations
remain stable even though the locators are changing. The MOBIKE WG remain stable even though the locators are changing. The MOBIKE WG
is looking at ways to have IPsec security associations survive even is looking at ways to have IPsec security associations survive even
though the IP addresses changes, which is a different approach. though the IP addresses changes, which is a different approach.
Layering the fragmentation header above the multihoming shim makes Layering the fragmentation header above the multihoming shim makes
reassembly robust in the case that there is broken multi-path routing reassembly robust in the case that there is broken multi-path routing
which results in using different paths, hence potentially different which results in using different paths, hence potentially different
source locators, for different fragments. Thus, effectively the source locators, for different fragments. Thus, effectively the
multihoming shim layer is placed between the IP endpoint sublayer, multihoming shim layer is placed between the IP endpoint sublayer,
which handles fragmentation, reassembly, and IPsec, and the IP which handles fragmentation, reassembly, and IPsec, and the IP
routing sublayer, which on a host selects which default router to use routing sublayer, which selects which next hop and interface to use
etc. for sending out packets.
Applications and upper layer protocols use ULIDs which the shim6 Applications and upper layer protocols use ULIDs which the shim6
layer will map to/from different locators. The shim6 layer maintains layer will map to/from different locators. The shim6 layer maintains
state, called host-pair context, per ULID pairs (that is, applies to state, called host-pair context, per ULID pairs (that is, applies to
all ULP connections between the ULID pair) in order to perform this all ULP connections between the ULID pair) in order to perform this
mapping. The mapping is performed consistently at the sender and the mapping. The mapping is performed consistently at the sender and the
receiver, thus from the perspective of the upper layer protocols, receiver, thus from the perspective of the upper layer protocols,
packets appear to be sent using ULIDs from end to end, even though packets appear to be sent using ULIDs from end to end, even though
the packets travel through the network containing locators in the IP the packets travel through the network containing locators in the IP
address fields, and even though those locators might be changed by address fields, and even though those locators might be changed by
skipping to change at page 9, line 19 skipping to change at page 9, line 20
context. context.
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.
2.1 Definitions 2.1 Definitions
This document introduces the following terms (taken from [21]): This document introduces the following terms (taken from [22]):
upper layer protocol (ULP) upper layer protocol (ULP)
A protocol layer immediately above IP. Examples A protocol layer immediately above IP. Examples
are transport protocols such as TCP and UDP, are transport protocols such as TCP and UDP,
control protocols such as ICMP, routing protocols control protocols such as ICMP, routing protocols
such as OSPF, and internet or lower-layer such as OSPF, and internet or lower-layer
protocols being "tunneled" over (i.e., protocols being "tunneled" over (i.e.,
encapsulated in) IP such as IPX, AppleTalk, or IP encapsulated in) IP such as IPX, AppleTalk, or IP
itself. itself.
interface A node's attachment to a link. interface A node's attachment to a link.
address An IP layer name that contains both topological address An IP layer name that contains both topological
significance and acts as a unique identifier for significance and acts as a unique identifier for
an interface. 128 bits. This document only uses an interface. 128 bits. This document only uses
the "address" term in the case where it isn't the "address" term in the case where it isn't
specific whether it is a locator or a identifier. specific whether it is a locator or an
identifier.
locator An IP layer topological name for an interface or locator An IP layer topological name for an interface or
a set of interfaces. 128 bits. The locators are a set of interfaces. 128 bits. The locators are
carried in the IP address fields as the packets carried in the IP address fields as the packets
traverse the network. traverse the network.
identifier An IP layer name for an IP layer endpoint (stack identifier An IP layer name for an IP layer endpoint (stack
name in [23]). The transport endpoint name is a name in [24]). The transport endpoint name is a
function of the transport protocol and would function of the transport protocol and would
typically include the IP identifier plus a port typically include the IP identifier plus a port
number. number.
NOTE: This proposal does not specify any new form NOTE: This proposal does not specify any new form
of IP layer identifier, but still separates the of IP layer identifier, but still separates the
identifying and locating properties of the IP identifying and locating properties of the IP
addresses. addresses.
upper-layer identifier (ULID) upper-layer identifier (ULID)
An IP locator which has been selected for An IP address which has been selected for
communication with a peer to be used by the upper communication with a peer to be used by the upper
layer protocol. 128 bits. This is used for layer protocol. 128 bits. This is used for
pseudo-header checksum computation and connection pseudo-header checksum computation and connection
identification in the ULP. Different sets of identification in the ULP. Different sets of
communication to a host (e.g., different communication to a host (e.g., different
connections) might use different ULIDs in order connections) might use different ULIDs in order
to enable load spreading. to enable load spreading.
Since the ULID is just one of the IP locators/ Since the ULID is just one of the IP locators/
addresses of the node, there is no need for a addresses of the node, there is no need for a
skipping to change at page 10, line 12 skipping to change at page 10, line 19
layer protocol. 128 bits. This is used for layer protocol. 128 bits. This is used for
pseudo-header checksum computation and connection pseudo-header checksum computation and connection
identification in the ULP. Different sets of identification in the ULP. Different sets of
communication to a host (e.g., different communication to a host (e.g., different
connections) might use different ULIDs in order connections) might use different ULIDs in order
to enable load spreading. to enable load spreading.
Since the ULID is just one of the IP locators/ Since the ULID is just one of the IP locators/
addresses of the node, there is no need for a addresses of the node, there is no need for a
separate name space and allocation mechanisms. separate name space and allocation mechanisms.
address field The source and destination address fields in the address field The source and destination address fields in the
IPv6 header. As IPv6 is currently specified this IPv6 header. As IPv6 is currently specified this
fields carry "addresses". If identifiers and fields carry "addresses". If identifiers and
locators are separated these fields will contain locators are separated these fields will contain
locators for packets on the wire. locators for packets on the wire.
FQDN Fully Qualified Domain Name FQDN Fully Qualified Domain Name
Host-pair context The state that the multihoming shim maintains for
a particular peer. The context is for a ULID Host-pair context The state that the multihoming shim maintains.
pair, as is identified by a context tag for each The context is for a ULID pair, and is identified
direction. by a context tag for each direction of the
communication.
Context tag Each end of the context allocates a context tag Context tag Each end of the context allocates a context tag
for the context. This is used to uniquely for the context. This is used to uniquely
associate both received control packets and associate both received control packets and
payload packets with the shim6 Payload extension payload packets with the shim6 Payload extension
header as belonging to the context. header as belonging to the context.
Current locator pair Each end of the context has a current locator Current locator pair Each end of the context has a current locator
pair which is used to send packets to be peer. pair which is used to send packets to be peer.
The two ends might use different locator pairs The two ends might use different current locator
though. pairs though.
Default context At the sending end, the shim uses the ULID pair Default context At the sending end, the shim uses the ULID pair
(passed down from the ULP) to find the context (passed down from the ULP) to find the context
for that pair. Thus, normally, a host can have for that pair. Thus, normally, a host can have
at most one context for a ULID pair. We call at most one context for a ULID pair. We call
this the "default context". this the "default context".
Context forking A mechanism which allows ULPs that are aware of Context forking A mechanism which allows ULPs that are aware of
multiple locators to use separate contexts for multiple locators to use separate contexts for
the same ULID pair, in order to be able use the same ULID pair, in order to be able use
different locator pairs for different different locator pairs for different
communication to the same ULID. Context forking communication to the same ULID. Context forking
causes more than just the default context to be causes more than just the default context to be
created for a ULID pair. created for a ULID pair.
2.2 Notational Conventions 2.2 Notational Conventions
skipping to change at page 11, line 44 skipping to change at page 12, line 13
source locator needs to somehow affect the exit path from the source locator needs to somehow affect the exit path from the
site. site.
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 B using some upper- o An application on host A decides to contact B using some upper-
layer protocol. This results in the ULP on A sending packets to layer protocol. This results in the ULP on A sending packets to
B. We call this the initial contact. Assuming the IP addresses B. We call this the initial contact. Assuming the IP addresses
selected by Default Address Selection [11] work, then there is no selected by Default Address Selection [12] 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 might make o Some heuristic on A or B (or both) determine that it might make
sense to make this communication robust against locator failures. sense to make this communication robust against locator failures.
For instance, this heuristic might be that more than 50 packets For instance, this heuristic might be that more than 50 packets
have been sent or received. This makes the shim initiate the have been sent or received. This makes the shim initiate the
4-way context establishment exchange. 4-way context establishment exchange.
As a result of this exchange, both A and B will know a list of As a result of this exchange, both A and B will know a list of
locators for each other. locators for each other.
skipping to change at page 12, line 20 skipping to change at page 12, line 37
revert to standard unicast behavior for the session. revert to standard unicast behavior for the session.
o Communication continues without any change for the ULP packets. o Communication continues without any change for the ULP packets.
In addition, there might be some messages exchanged between the In addition, there might be some messages exchanged between the
shim sub-layers for (un)reachability detection. shim sub-layers for (un)reachability detection.
o At some point in time something fails. Depending on the approach o At some point in time something fails. Depending on the approach
to reachability detection, there might be some advise from the to reachability detection, there might be some advise from the
ULP, or the shim (un)reachability detection might discover that ULP, or the shim (un)reachability detection might discover that
there is a problem. there is a problem.
At this point in time one or both ends of the communication need At this point in time one or both ends of the communication need
to explore the different alternate locator pairs until a working to probe and explore the different alternate locator pairs until a
pair is found, and rehome to using that pair. working pair is found, and rehome to using that pair.
o Once a working alternative locator pair has been found, the shim o Once a working alternative locator pair has been found, the shim
will rewrite the packets on transmit, and tag the packets with will rewrite the packets on transmit, and tag the packets with
shim6 Payload message as an extension header, which contains the shim6 Payload message as an extension header, which contains the
receiver's context tag. The receiver will use the <Source receiver's context tag. The receiver will use the <Source
Locator, Destination Locator, Context Tag> to find the context Locator, Destination Locator, Context Tag> to find the context
state which will indicate which addresses to place in the IPv6 state which will indicate which addresses to place in the IPv6
header before passing the packet up to the ULP. The result is header before passing the packet up to the ULP. The result is
that from the perspective of the ULP the packet passes unmodified that from the perspective of the ULP the packet passes unmodified
end-to-end, even though the IP routing infrastructure sends the end-to-end, even though the IP routing infrastructure sends the
packet to a different locator. packet to a different locator.
skipping to change at page 13, line 23 skipping to change at page 13, line 42
8-octet "shim payload" extension header before the (extension) 8-octet "shim payload" extension header before the (extension)
headers that are processed by the IP endpoint sublayer and ULPs. headers that are processed by the IP endpoint sublayer and ULPs.
4.1 Context Tags 4.1 Context Tags
A context between two hosts is actually a context between two ULIDs. A context between two hosts is actually a context between two ULIDs.
The context is identified by a pair of context tags. Each end gets The context is identified by a pair of context tags. Each end gets
to allocate a context tag, and once the context is established, the to allocate a context tag, and once the context is established, the
shim6 control messages contain the context tag that the receiver of shim6 control messages contain the context tag that the receiver of
the message allocated. Thus at a minimum the combination of <peer the message allocated. Thus at a minimum the combination of <peer
ULID, local ULID, local context> tag MUST uniquely identify one ULID, local ULID, local context tag> MUST uniquely identify one
context. context.
In addition, the non-shim6 messages, which we call payload packets, In addition, the non-shim6 messages, which we call payload packets,
will not contain the ULIDs after a failure. This introduces the will not contain the ULIDs after a failure. This introduces the
requirement that the <peer locator, local locator, local context tag> requirement that the <peer locator, local locator, local context tag>
MUST uniquely identify the context. Since the peer's set of locators MUST uniquely identify the context. Since the peer's set of locators
might be dynamic the simplest form of unique allocation of the local might be dynamic the simplest form of unique allocation of the local
context tag is to pick a number that is unique on the host. Hosts context tag is to pick a number that is unique on the host. Hosts
which serve multiple ULIDs using disjoint sets of locators can which serve multiple ULIDs using disjoint sets of locators can
maintain the context tag allocation per such disjoint set. maintain the context tag allocation per such disjoint set.
The mechanism for detecting a loss of context state at the peer that The mechanism for detecting a loss of context state at the peer that
is currently proposed in this document assumes that the receiver can is currently proposed in this document assumes that the receiver can
tell the packets that need locator rewriting, even after it has lost tell the packets that need locator rewriting, even after it has lost
all state (e.g., due to a crash followed by a reboot). all state (e.g., due to a crash followed by a reboot). This is
achieved because after a rehoming event the packets that need
receive-side rewriting, carry the Payload Message extension header.
Even though we do not overload the flow label field to carry the Even though we do not overload the flow label field to carry the
context tag, any protocol (such as RSVP or NSIS) which signals context tag, any protocol (such as RSVP or NSIS) which signals
information about flows from the host stack to devices in the path, information about flows from the host stack to devices in the path,
need to be made aware of the locator agility introduced by a layer 3 need to be made aware of the locator agility introduced by a layer 3
shim, so that the signaling can be performed for the locator pairs shim, so that the signaling can be performed for the locator pairs
that are currently being used. that are currently being used.
TBD: add forking - multiple contexts between ULID pairs, default TBD: add forking - multiple contexts between ULID pairs, default
context, etc context, etc. Need to explain that context forking assumes an API
from the ULP.
TBD: add that shim can be disabled for some ULP traffic if we define
an API for this purpose.
4.2 Securing shim6 4.2 Securing shim6
The mechanisms are secured using a combination of techniques: The mechanisms are secured using a combination of techniques:
o The HBA technique [5] for validating the locators to prevent an o The HBA technique [6] for validating 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 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
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. attacks.
4.3 Overview of Shim Control Messages 4.3 Overview of Shim Control Messages
The shim context establishment is accomplished using four messages; The shim 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 [22].] message. [The names of these messages are borrowed from HIP [23].]
There is a No Context error message defined, when a control or There is a No Context error message defined, when a control or
payload packet arrives and there is no matching context state at the payload packet arrives and there is no matching context state at the
receiver. When such a message is received, it will result in the receiver. When such a message is received, it will result in the
destruction of the shim context and a re-establishment. destruction of the shim context and a re-establishment.
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
dynamic. For this reason there is a Locator List Update message and dynamic. For this reason there is a Locator List Update message and
acknowledgement. acknowledgement.
Even though the list of locators is fixed, a host might determine Even though the list of locators is fixed, a host might determine
that some preferences might have changed. For instance, it might that 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. Currently this mechanism has a some locator(s) are no longer usable. Currently this mechanism has a
separate message pair (Rehome Request and acknowledgement), but separate message pair (Rehome Request and acknowledgement), but
perhaps this can be encoded using the Locator List Update message perhaps this can be encoded using the Locator List Update message
pair with a preference option and no change to the list of locators. pair with a preference option and no change to the list of locators.
At least two approaches (CUD and FBD) have been discussed for the At least two approaches (CUD and FBD) have been discussed for the
shim (un)reachability detection [6]. This document attempt to define shim (un)reachability detection [7]. This document attempt to define
messages for both cases; once the WG has picked an approach we can messages for both cases; once the WG has picked an approach we can
delete any unneeded messages. delete any unneeded messages.
The CUD approach uses a probe message and acknowledgement, which can The CUD approach uses a probe message and acknowledgement, which can
be suppressed e.g. using positive advise from the ULP. This message be suppressed e.g. using positive advise from the ULP. This message
pair also seems needed to verify that the host is indeed present at a pair also seems needed to verify that the host is indeed present at a
new locator before the data stream is redirected to that locator, in new locator before the data stream is redirected to that locator, in
order to prevent 3rd party DoS attacks. order to prevent 3rd party DoS attacks.
The FBD approach uses a keepalive message, which is sent when a host The FBD approach uses a keepalive message, which is sent when a host
skipping to change at page 15, line 26 skipping to change at page 15, line 46
host-pair context. However, communication might fail during the host-pair context. However, communication might fail during the
initial context (that is, when the application or transport protocol initial context (that is, when the application or transport protocol
is trying to setup some communication). If we want the shim to be is trying to setup some communication). If we want the shim to be
able to optimize discovering a working locator pair in that case, we able to optimize discovering a working locator pair in that case, we
need a mechanism to test the reachability of locators independent of need a mechanism to test the reachability of locators independent of
some context. We define a locator pair test message and some context. We define a locator pair test message and
acknowledgement for this purpose, even though it isn't yet clear acknowledgement for this purpose, even though it isn't yet clear
whether we need such a thing. whether we need such a thing.
Finally, when the context is established and there is a failure there Finally, when the context is established and there is a failure there
needs to be a way to explore the set of locator pairs to efficiently needs to be a way to probe and explore the set of locator pairs to
find a working pair. We define an explore message as a place holder efficiently find a working pair. We define an explore message as a
for some mechanism in this space [7]. place holder for some mechanism in this space [8].
4.4 Locator Validation
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
that source locator as being part of this context. The peer might
wish to do some verification of the locator before accepting it as a
source address. This document does not require any such
verification. But if it is done by a host, in all cases such
verification need to be finished before the host acknowledges the new
locator, by sending an Update Acknowledgement message, R2 an message.
Before a host can use a locator (different than the ULID) as the
destination locator it must perform the full verification of the
locator. This includes both verifying it using HBA/CGA, and
verifying that the ULID is indeed reachable at the locator. The
latter in order to prevent 3rd party flooding attacks.
5. Message Formats 5. Message Formats
The shim6 messages are all carried using a new IP protocol number TBD The shim6 messages are all carried using a new IP protocol number TBD
[to be assigned by IANA]. The shim6 messages have a common header, [to be assigned by IANA]. The shim6 messages have a common header,
defined below, with some fixed fields, followed by type specific defined below, with some fixed fields, followed by type specific
fields. fields.
5.1 Payload Message Format The shim6 messages are structured as an IPv6 extension header since
the Payload Message is used to carry the ULP packets after a locator
switch. The shim6 control messages use the same extension header
formats so that a single "protocol number" needs to be allowed
through firewalls in order for shim6 to function across the firewall.
5.1 Common shim6 Message Format
The first 17 bits of the shim6 header is common for the Payload
Message and the control messages and looks as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Next Header: The payload which follows this header.
Hdr Ext Len: 8-bit unsigned integer. Length of the shim6 header in
8-octet units, not including the first 8 octets.
P: A single bit to distinguish Payload messages from
control messages.
5.2 Payload Message Format
The payload message is used to carry ULP packets where the receiver The payload message is used to carry ULP packets where the receiver
must replace the content of the source and or destination fields in must replace the content of the source and or destination fields in
the IPv6 header before passing the packet to the ULP. Thus this the IPv6 header before passing the packet to the ULP. Thus this
extension header is included when the locators pair that is used is extension header is included when the locators pair that is used is
not the same as the ULID pair. not the same as the ULID pair.
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 in the host, the shim header will be placed before routing sub-layer in the host, the shim header will be placed before
any endpoint extension headers (fragmentation headers, destination any endpoint extension headers (fragmentation headers, destination
skipping to change at page 16, line 18 skipping to change at page 17, line 38
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | 0 |1| Reserved | | Next Header | 0 |1| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Context Tag | | Receiver Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
Next Header: The payload which follows this header. Next Header: The payload which follows this header.
Hdr Ext Len: 0 (since the header is 8 octets). Hdr Ext Len: 0 (since the header is 8 octets).
P: Set to one. A single bit to distinguish this from the
shim6 control messages.
Reserved: Reserved for future use. Zero on transmit. MUST be Reserved: Reserved for future use. Zero on transmit. MUST be
ignored on receipt. ignored on receipt.
Receiver Context Tag: 32-bit unsigned integer. Allocated by the Receiver Context Tag: 32-bit unsigned integer. Allocated by the
receiver for use to identify the context (together receiver for use to identify the context (together
with the source and destination locators). with the source and destination locators).
5.2 Common Shim6 Control header 5.3 Common Shim6 Control header
The common part of the header has a next header and header extension The common part of the header has a next header and header extension
length field which is consistent with the other IPv6 extension length field which is consistent with the other IPv6 extension
headers, even if the next header value is always "NO NEXT HEADER" for headers, even if the next header value is always "NO NEXT HEADER" for
the control messages; only the payload messages use the Next Header the control messages; only the payload messages use the Next Header
field. field.
The shim6 headers must be a multiple of 8 octets, hence the minimum The shim6 headers must be a multiple of 8 octets, hence the minimum
size is 8 octets. size is 8 octets.
skipping to change at page 17, line 4 skipping to change at page 18, line 21
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len |0| Type |Type specific|0| | Next Header | Hdr Ext Len |0| Type |Type specific|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | | | Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Type specific format | | Type specific format |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
Next Header: 8-bit selector. Normally set to NO_NXT_HDR (59). Next Header: 8-bit selector. Normally set to NO_NXT_HDR (59).
Indicates the next header value for the shim6 payload Indicates the next header value for the shim6 payload
messages. messages.
Hdr Ext Len: 8-bit unsigned integer. Length of the shim6 header in Hdr Ext Len: 8-bit unsigned integer. Length of the shim6 header in
8-octet units, not including the first 8 octets. 8-octet units, not including the first 8 octets.
P: Set to zero. A single bit to distinguish this from
the shim6 payload messages.
Type: 7-bit unsigned integer. Identifies the actual message Type: 7-bit unsigned integer. Identifies the actual message
from the table below. from the table below.
0: A single bit (set to zero) which allows shim6 and HIP 0: A single bit (set to zero) which allows shim6 and HIP
to have a common header format yet telling shim6 and to have a common header format yet telling shim6 and
HIP messages apart. HIP messages apart.
Checksum: 16-bit unsigned integer. The checksum is the 16-bit Checksum: 16-bit unsigned integer. The checksum is the 16-bit
one's complement of the one's complement sum of the one's complement of the one's complement sum of the
entire shim6 header message starting with the shim6 entire shim6 header message starting with the shim6
next header field, and ending as indicated by the Hdr next header field, and ending as indicated by the Hdr
Ext Len. Thus when there is a payload following the Ext Len. Thus when there is a payload following the
skipping to change at page 17, line 36 skipping to change at page 19, line 18
| 1 | I1 (first establishment message from the initiator) | | 1 | I1 (first establishment message from the initiator) |
| 2 | R1 (first establishment message from the responder) | | 2 | R1 (first establishment message from the responder) |
| 3 | I2 (2nd establishment message from the initiator) | | 3 | I2 (2nd establishment message from the initiator) |
| 4 | R2 (2nd establishment message from the responder) | | 4 | R2 (2nd establishment message from the responder) |
| 5 | No Context Error | | 5 | No Context Error |
| 6 | Update Request | | 6 | Update Request |
| 7 | Update Acknowledgement | | 7 | Update Acknowledgement |
| 8 | Reachability Probe | | 8 | Reachability Probe |
| 9 | Reachability Reply | | 9 | Reachability Reply |
| 10 | Keepalive | | 10 | Keepalive |
| 11 | Context Locator Pair Explore | | 11 | SHIM6 Probe Message |
+------------+-----------------------------------------------------+ +------------+-----------------------------------------------------+
Table 1 Table 1
5.3 I1 Message Format 5.4 I1 Message Format
The I1 message is the first message in the context establishment The I1 message is the first message in the context establishment
exchange. exchange.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 1 | Reserved1 |0| | 59 | Hdr Ext Len |0| Type = 1 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Reserved2 | | Checksum | Reserved2 |
skipping to change at page 18, line 38 skipping to change at page 20, line 17
Initiator Context Tag: 32-bit field. The Context Tag the initiator Initiator Context Tag: 32-bit field. The Context Tag the initiator
has allocated for the context. has allocated for the context.
Initiator Nonce: 32-bit unsigned integer. A random number picked by Initiator Nonce: 32-bit unsigned integer. A random number picked by
the initiator which the responder will return in the the initiator which the responder will return in the
R1 message. R1 message.
The following options are allowed in the message: The following options are allowed in the message:
ULID pair: TBD Do we need to carry the ULIDs, or assume they are ULID pair: TBD Do we need to carry the ULIDs, or assume they are
the same as the address fields in the IPv6 header? the same as the address fields in the IPv6 header?
Depends on how we handle failures during initial Depends on how we handle failures during initial
contact. contact. We also need it to be able to reestablish
the host-pair context after a failure when one end has
lost the context state.
5.4 R1 Message Format 5.5 R1 Message Format
The R1 message is the second message in the context establishment The R1 message is the second message in the context establishment
exchange. The responder sends this in response to an I1 message, exchange. The responder sends this in response to an I1 message,
without creating any state specific to the initiator. without creating any state specific to the initiator.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 2 | Reserved1 |0| | 59 | Hdr Ext Len |0| Type = 2 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 19, line 42 skipping to change at page 21, line 19
message. message.
The following options are allowed in the message: The following options are allowed in the message:
Responder Validator: Variable length option. Typically a hash Responder Validator: Variable length option. Typically a hash
generated by the responder, which the responder uses generated by the responder, which the responder uses
together with the Responder Nonce value to verify that together with the Responder Nonce value to verify that
an I2 message is indeed sent in response to a R1 an I2 message is indeed sent in response to a R1
message, and that the parameters in the I2 message are message, and that the parameters in the I2 message are
the same as those in the I1 message. the same as those in the I1 message.
5.5 I2 Message Format 5.6 I2 Message Format
The I2 message is the third message in the context establishment The I2 message is the third message in the context establishment
exchange. The initiator sends this in response to a R1 message, exchange. The initiator sends this in response to a R1 message,
after checking the Initiator Nonce, etc. after checking the Initiator Nonce, etc.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 3 | Reserved1 |0| | 59 | Hdr Ext Len |0| Type = 3 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 20, line 42 skipping to change at page 22, line 17
Initiator Nonce: 32-bit unsigned integer. A random number picked by Initiator Nonce: 32-bit unsigned integer. A random number picked by
the initiator which the responder will return in the the initiator which the responder will return in the
R2 message. R2 message.
Responder Nonce: 32-bit unsigned integer. Copied from the R1 Responder Nonce: 32-bit unsigned integer. Copied from the R1
message. message.
The following options are allowed in the message: The following options are allowed in the message:
Responder Validator: Variable length option. Just a copy of the Responder Validator: Variable length option. Just a copy of the
Validator option in the R1 message. Validator option in the R1 message.
ULID pair: TBD Do we need to carry the ULIDs, or assume they are ULID pair: TBD Do we need to carry the ULIDs, or assume they are
the same as the address fields in the IPv6 header? the same as the address fields in the IPv6 header? We
also need it to be able to reestablish the host-pair
context after a failure when one end has lost the
context state.
Locator list: Optionally sent when the initiator immediately wants Locator list: Optionally sent when the initiator immediately wants
to tell the responder its list of locators. When it to tell the responder its list of locators. When it
is sent, the necessary HBA/CGA information for is sent, the necessary HBA/CGA information for
validating the locator list MUST also be included. validating the locator list MUST also be included.
Locator Preferences: Optionally sent when the locators don't all have Locator Preferences: Optionally sent when the locators don't all have
equal preference. equal preference.
CGA Parameter Data Structure: Included when the locator list is CGA Parameter Data Structure: Included when the locator list is
included so the receiver can verify the locator list. included so the receiver can verify the locator list.
CGA Signature: Included when the some of the locators in the list use CGA Signature: Included when the some of the locators in the list use
CGA (and not HBA) for validation. CGA (and not HBA) for validation.
5.6 R2 Message Format 5.7 R2 Message Format
The R2 message is the fourth message in the context establishment The R2 message is the fourth message in the context establishment
exchange. The responder sends this in response to an I2 message. exchange. The responder sends this in response to an I2 message.
The R2 message is also used when both hosts send I1 messages at the The R2 message is also used when both hosts send I1 messages at the
same time and the I1 messages cross in flight. same time and the I1 messages cross in flight.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 4 | Reserved1 |0| | 59 | Hdr Ext Len |0| Type = 4 | Reserved1 |0|
skipping to change at page 22, line 4 skipping to change at page 23, line 23
Responder Context Tag: 32-bit field. The Context Tag the responder Responder Context Tag: 32-bit field. The Context Tag the responder
has allocated for the context. has allocated for the context.
Initiator Nonce: 32-bit unsigned integer. Copied from the I2 Initiator Nonce: 32-bit unsigned integer. Copied from the I2
message. message.
The following options are allowed in the message: The following options are allowed in the message:
Locator List: Optionally sent when the responder immediately wants Locator List: Optionally sent when the responder immediately wants
to tell the initiator its list of locators. When it to tell the initiator its list of locators. When it
is sent, the necessary HBA/CGA information for is sent, the necessary HBA/CGA information for
validating the locator list MUST also be included. validating the locator list MUST also be included.
Locator Preferences: Optionally sent when the locators don't all have Locator Preferences: Optionally sent when the locators don't all have
equal preference. equal preference.
CGA Parameter Data Structure: Included when the locator list is CGA Parameter Data Structure: Included when the locator list is
included and the PDS was not included in the context included so the receiver can verify the locator list.
establishment messages, so the receiver can verify the
locator list.
CGA Signature: Included when the some of the locators in the list use CGA Signature: Included when the some of the locators in the list use
CGA (and not HBA) for validation. CGA (and not HBA) for validation.
5.7 No Context Error Message Format 5.8 No Context Error Message Format
Should a host receive a packet with a shim Payload message or shim6 Should a host receive a packet with a shim Payload message or shim6
control message, such a a locator update, and the host does not have control message, such a a locator update, and the host does not have
any context state for the locators (in the IPv6 source and any context state for the locators (in the IPv6 source and
destination fields) and the context tag, then it will generate a No destination fields) and the context tag, then it will generate a No
Context Error. The error includes the packet that was received, Context Error. The error includes the packet that was received,
subject to the packet not exceeding 1280 octets. subject to the packet not exceeding 1280 octets.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 23, line 5 skipping to change at page 24, line 21
The following options are allowed in the message: The following options are allowed in the message:
Packet in Error: Variable length option containing the IPv6 packet Packet in Error: Variable length option containing the IPv6 packet
that was in error, starting with the IPv6 header, and that was in error, starting with the IPv6 header, and
normally containing the full packet. If the resulting normally containing the full packet. If the resulting
No Context Error message would exceed 1280 octets, the No Context Error message would exceed 1280 octets, the
Packet In Error option will not include the full Packet In Error option will not include the full
packet in error in order to limit the error to 1280 packet in error in order to limit the error to 1280
octets. octets.
5.8 Update Request Message Format 5.9 Update Request Message Format
The Update Request Message is used to update either the list or The Update Request Message is used to update either the list or
locators, the locator preferences, and both. When the list of locators, the locator preferences, and both. When the list of
locators is updated, the message also contains the option(s) locators is updated, the message also contains the option(s)
necessary for HBA/CGA to secure this. The basic sanity check that necessary for HBA/CGA to secure this. The basic sanity check that
prevents off-path attackers from generating bogus updates is the prevents off-path attackers from generating bogus updates is the
context tag in the message. context tag in the message.
The update message contains options (the Locator List and the Locator
Preferences) that, when included, completely replace the previous
locator list and locator preferences, respectively. Thus there is no
mechanisms to just send deltas to the locator list.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 6 | Reserved1 |0| | 59 | Hdr Ext Len |0| Type = 6 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Reserved2 | | Checksum | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Context Tag | | Receiver Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce | | Request Nonce |
skipping to change at page 24, line 4 skipping to change at page 25, line 23
Request Nonce: 32-bit unsigned integer. A random number picked by Request Nonce: 32-bit unsigned integer. A random number picked by
the initiator which the peer will return in the the initiator which the peer will return in the
acknowledgement message. acknowledgement message.
The following options are allowed in the message: The following options are allowed in the message:
Locator List: The list of the senders (new) locators. The locators Locator List: The list of the senders (new) locators. The locators
might be unchanged and only the preferences have might be unchanged and only the preferences have
changed. changed.
Locator Preferences: Optionally sent when the locators don't all have Locator Preferences: Optionally sent when the locators don't all have
equal preference. equal preference.
CGA Signature: Included when the some of the locators in the list use CGA Signature: Included when the some of the locators in the list use
CGA (and not HBA) for validation. CGA (and not HBA) for validation.
5.9 Update Acknowledgement Message Format 5.10 Update Acknowledgement Message Format
This message is sent in response to a Update Request message. It This message is sent in response to a Update Request message. It
implies that the Update Request has been received, and that any new implies that the Update Request has been received, and that any new
locators in the Update Request can now be used as the source locators locators in the Update Request can now be used as the source locators
of packets. But it does not imply that the (new) locators have been of packets. But it does not imply that the (new) locators have been
verified and will be used as a destination, since the host might verified to be used as a destination, since the host might defer the
defer the verification of a locator until it is used as a verification of a locator until it sees a need to use a locator as
destination. the destination.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 7 | Reserved1 |0| | 59 | Hdr Ext Len |0| Type = 7 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Reserved2 | | Checksum | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Context Tag | | Receiver Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 24, line 48 skipping to change at page 26, line 18
transmit. MUST be ignored on receipt. transmit. MUST be ignored on receipt.
Reserved2: 16-bit field. Reserved for future use. Zero on Reserved2: 16-bit field. Reserved for future use. Zero on
transmit. MUST be ignored on receipt. transmit. MUST be ignored on receipt.
Receiver Context Tag: 32-bit field. The Context Tag the receiver has Receiver Context Tag: 32-bit field. The Context Tag the receiver has
allocated for the context. allocated for the context.
Request Nonce: 32-bit unsigned integer. Copied from the Update Request Nonce: 32-bit unsigned integer. Copied from the Update
Request message. Request message.
No options are currently defined for this message. No options are currently defined for this message.
5.10 Reachability Probe Message Format 5.11 Reachability Probe Message Format
TBD: Given [8] we do not need this message any more.
The Reachability Probe message is used to prevent 3rd party DoS The Reachability Probe message is used to prevent 3rd party DoS
attacks, and can also be used to verify whether a context is attacks, and can also be used to verify whether a context is
reachable at a given locator should that be needed for the general reachable at a given locator should that be needed for the general
reachability detection mechanism (e.g., if we pick the CUD mechanism reachability detection mechanism (e.g., if we pick the CUD mechanism
where one end sends probes and expects a reply). where one end sends probes and expects a reply).
Before a host uses a locator for the peer that is different than the Before a host uses a locator for the peer that is different than the
ULID, it needs to verify that the peer is indeed present at that ULID, it needs to verify that the peer is indeed present at that
locator by sending a Context Verify and receiving an acknowledgement. locator by sending a Context Verify and receiving an acknowledgement.
skipping to change at page 25, line 46 skipping to change at page 27, line 20
transmit. MUST be ignored on receipt. transmit. MUST be ignored on receipt.
Receiver Context Tag: 32-bit field. The Context Tag the receiver has Receiver Context Tag: 32-bit field. The Context Tag the receiver has
allocated for the context. allocated for the context.
Request Nonce: 32-bit unsigned integer. A random number picked by Request Nonce: 32-bit unsigned integer. A random number picked by
the initiator which the responder will return in the the initiator which the responder will return in the
acknowledgement message. acknowledgement message.
The following options are allowed in the message: The following options are allowed in the message:
ULID pair: The ULID pair that is being probed. ULID pair: The ULID pair that is being probed.
5.11 Reachability Reply Message Format 5.12 Reachability Reply Message Format
TBD: Given [8] we do not need this message any more.
This is sent in response to a Reachability Probe message. Although, This is sent in response to a Reachability Probe message. Although,
if the receiver of the Reachability Probe does not have a matching if the receiver of the Reachability Probe does not have a matching
context it will send a No Context Error message. context it will send a No Context Error message.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 9 | Reserved1 |0| | 59 | Hdr Ext Len |0| Type = 9 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 26, line 37 skipping to change at page 28, line 16
transmit. MUST be ignored on receipt. transmit. MUST be ignored on receipt.
Receiver Context Tag: 32-bit field. The Context Tag the receiver has Receiver Context Tag: 32-bit field. The Context Tag the receiver has
allocated for the context. allocated for the context.
Request Nonce: 32-bit unsigned integer. Copied from the request Request Nonce: 32-bit unsigned integer. Copied from the request
message. message.
The following options are allowed in the message: The following options are allowed in the message:
ULID pair: The ULID pair that is being probed. Copied from the ULID pair: The ULID pair that is being probed. Copied from the
Probe message. Probe message.
5.12 Keepalive Message Format 5.13 Keepalive Message Format
TBD: Given [8] we do not need this message any more.
The keepalive message would be used if we decide to do the Force The keepalive message would be used if we decide to do the Force
Bidirectional communication as a way to get verification that the Bidirectional communication as a way to get verification that the
locator pair continues to work. If we are not going to do FBD we locator pair continues to work. If we are not going to do FBD we
probably will not need this message. probably will not need this message.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 10 | Reserved1 |0| | 59 | Hdr Ext Len |0| Type = 10 | Reserved1 |0|
skipping to change at page 27, line 30 skipping to change at page 29, line 4
Fields: Fields:
Next Header: NO_NXT_HDR (59). Next Header: NO_NXT_HDR (59).
Type: 10 Type: 10
Reserved1: 7-bit field. Reserved for future use. Zero on Reserved1: 7-bit field. Reserved for future use. Zero on
transmit. MUST be ignored on receipt. transmit. MUST be ignored on receipt.
Reserved2: 16-bit field. Reserved for future use. Zero on Reserved2: 16-bit field. Reserved for future use. Zero on
transmit. MUST be ignored on receipt. transmit. MUST be ignored on receipt.
Receiver Context Tag: 32-bit field. The Context Tag the receiver has Receiver Context Tag: 32-bit field. The Context Tag the receiver has
allocated for the context. allocated for the context.
Request Nonce: 32-bit unsigned integer. Copied from the Reachability Request Nonce: 32-bit unsigned integer. Copied from the Reachability
Probe message. Probe message.
No options are currently defined for this message. No options are currently defined for this message.
5.13 Context Locator Pair Explore Message Format 5.14 SHIM6 Probe Message Format
This is a placeholder for the protocol mechanism outlined in [7].
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
from B to A, but there is no locator pair which works in both
directions. The protocol mechanism is that as A is sending explore
messages to B, B will observe which locator pairs it has received
from and report that back in explore messages it is sending to A.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 11 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Options +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Next Header: NO_NXT_HDR (59).
Type: 11
Reserved1: 7-bit field. Reserved for future use. Zero on
transmit. MUST be ignored on receipt.
Sequence Number: 16-bit unsigned integer. Used to determine which
messages have been received by the peer.
Receiver Context Tag: 32-bit field. The Context Tag the receiver has
allocated for the context.
The following options are allowed in the message: This message and its semantics are defined in [8]. The idea behind
Explorer Results: Indication of what Explorer messages the sender has that mechanism is to be able to handle the case when one locator pair
recently received from the peer. works in from A to B, and another locator pair works from B to A, but
there is no locator pair which works in both directions. The
protocol mechanism is that as A is sending probe messages to B, B
will observe which locator pairs it has received from and report that
back in probe messages it is sending to A.
5.14 Option Formats 5.15 Option Formats
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
added padding bytes MUST be zeroed by the sender, and their values added padding bytes MUST be zeroed by the sender, and their values
SHOULD NOT be checked by the receiver. SHOULD NOT be checked by the receiver.
Consequently, the Length field indicates the length of the Contents Consequently, the Length field indicates the length of the Contents
skipping to change at page 29, line 37 skipping to change at page 30, line 26
+------------------------------+------+ +------------------------------+------+
| Option Name | Type | | Option Name | Type |
+------------------------------+------+ +------------------------------+------+
| Validator | 1 | | Validator | 1 |
| Locator List | 2 | | Locator List | 2 |
| Locator Preferences | 3 | | Locator Preferences | 3 |
| CGA Parameter Data Structure | 4 | | CGA Parameter Data Structure | 4 |
| CGA Signature | 5 | | CGA Signature | 5 |
| ULID Pair | 6 | | ULID Pair | 6 |
| Packet In Error | 7 | | Packet In Error | 7 |
| Explorer Results | 8 | | SHIM6 Event Option | 8 |
+------------------------------+------+ +------------------------------+------+
Table 2 Table 2
5.14.1 Validator Option Format 5.15.1 Validator Option Format
The responder can choose exactly what input uses to compute the The responder can choose exactly what input uses to compute the
validator, and what one-way function (MD5, SHA1) it uses, as long as validator, and what one-way function (MD5, SHA1) it uses, as long as
the responder can verify that the validator it receives back in the the responder can verify that the validator it receives back in the
I2 message is indeed one that 1) it computed, 2) it computed for the I2 message is indeed one that 1) it computed, 2) it computed for the
particular context, and 3) that it isn't a replayed I2 message. particular context, and 3) that it isn't a replayed I2 message.
One way for the responder to do this is to maintain a single secret One way for the responder to do this is to maintain a single secret
(S) and a running counter for the Responder Nonce. For each I1 (S) and a running counter for the Responder Nonce. For each I1
message, the responder can then increase the counter, use the counter message, the responder can then increase the counter, use the counter
skipping to change at page 30, line 27 skipping to change at page 31, line 16
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 |0| Length | | Type = 1 |0| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Validator ~ ~ Validator ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
Validator: Variable length content whose interpretation is local Validator: Variable length content whose interpretation is local
to the responder. to the responder.
5.14.2 Locator List Option Format 5.15.2 Locator List Option Format
The Locator List Option is used to carry all the locators of the The Locator List Option is used to carry all the locators of the
sender. Note that the order of the locators is important, since the sender. Note that the order of the locators is important, since the
Locator Preferences and the Explorer message refers to the locators Locator Preferences refers to the locators by using the index in the
by using the index in the list. list.
Note that we carry all the locators in this option even though some Note that we carry all the locators in this option even though some
of them can be created automatically from the CGA Parameter Data of them can be created automatically from the CGA Parameter Data
Structure. Structure.
TBD: We can get a simpler format if we split this into two options:
one with the locators and one with just the verification methods.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 |0| Length | | Type = 2 |0| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator List Generation | | Locator List Generation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num Locators | N Octets of Verification Method | | Num Locators | N Octets of Verification Method |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
~ ~ ~ ~
skipping to change at page 31, line 4 skipping to change at page 31, line 43
| Type = 2 |0| Length | | Type = 2 |0| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator List Generation | | Locator List Generation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num Locators | N Octets of Verification Method | | Num Locators | N Octets of Verification Method |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Locators 1 through N ~ ~ Locators 1 through N ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
Locator List Generation: 32-bit unsigned integer. Indicates a Locator List Generation: 32-bit unsigned integer. Indicates a
generation number which is increased by one for each generation number which is increased by one for each
new locator list. This is used to ensure that the new locator list. This is used to ensure that the
index in the Locator Preferences and Explorer results index in the Locator Preferences refer to the right
refer to the right version of the locator list. version of the locator list.
Num Locators: 8-bit unsigned integer. The number of locators that Num Locators: 8-bit unsigned integer. The number of locators that
are included in the option. We call this number "N" are included in the option. We call this number "N"
below. below.
Verification Method: N octets. The i'th octet specifies the Verification Method: N octets. The i'th octet specifies the
verification method for the i'th locator. verification method for the i'th locator.
Locators: N 128-bit locators. Locators: N 128-bit locators.
The defined verification methods are: The defined verification methods are:
+-------+----------+ +-------+----------+
| Value | Method | | Value | Method |
+-------+----------+ +-------+----------+
| 0 | Reserved | | 0 | Reserved |
| 1 | HBA | | 1 | HBA |
| 2 | CGA | | 2 | CGA |
| 3-255 | Reserved | | 3-255 | Reserved |
+-------+----------+ +-------+----------+
Table 3 Table 3
5.14.3 Locator Preferences Option Format 5.15.3 Locator Preferences Option Format
The Locator Preferences option can have some flags to indicate The Locator Preferences option can have some flags to indicate
whether or not a locator is known to work. In addition, the sender whether or not a locator is known to work. In addition, the sender
can include a notion of preferences. It might make sense to define can include a notion of preferences. It might make sense to define
"preferences" as a combination of priority and weight the same way "preferences" as a combination of priority and weight the same way
that DNS SRV records has such information. The priority would that DNS SRV records has such information. The priority would
provide a way to rank the locators, and within a given priority, the provide a way to rank the locators, and within a given priority, the
weight would provide a way to do some load sharing. See [8] for how weight would provide a way to do some load sharing. See [9] 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 32, line 16 skipping to change at page 33, line 12
and the Locator List option is used to verify that they refer to the and the Locator List option is used to verify that they refer to the
same version of the locator list. same version of the locator list.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 |0| Length | | Type = 3 |0| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator List Generation | | Locator List Generation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Element Len | Element[1] ... | Element[2] | | Element Len | Element[1] | Element[2] | Element[3] |
| ... | Element[3] ... | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Case of Element Len = 1 is depicted.
Fields: Fields:
Locator List Generation: 32-bit unsigned integer. Indicates a Locator List Generation: 32-bit unsigned integer. Indicates a
generation number for the locator list to which the generation number for the locator list to which the
elements should apply. elements should apply.
Element Len: 8-bit unsigned integer. The length in octets of each Element Len: 8-bit unsigned integer. The length in octets of each
element. This draft defines the cases when the length element. This draft defines the cases when the length
is 1, 2, or 3. is 1, 2, or 3.
Element[i]: A field with a number of octets defined by the Element Element[i]: A field with a number of octets defined by the Element
Len field. Provides preferences for the i'th locator Len field. Provides preferences for the i'th locator
in the Locator List option that is in use. in the Locator List option that is in use.
skipping to change at page 32, line 49 skipping to change at page 33, line 46
When the Element length equals two, the the element consists of a 1 When the Element length equals two, the the element consists of a 1
octet flags field followed by a 1 octet priority field. The priority octet flags field followed by a 1 octet priority field. The priority
has the same semantics as the priority in DNS SRV records. has the same semantics as the priority in DNS SRV records.
When the Element length equals three, the the element consists of a 1 When the Element length equals three, the the element consists of a 1
octet flags field followed by a 1 octet priority field, and a 1 octet octet flags field followed by a 1 octet priority field, and a 1 octet
weight field. The weight has the same semantics as the weight in DNS weight field. The weight has the same semantics as the weight in DNS
SRV records. SRV records.
5.14.4 CGA Parameter Data Structure Option Format 5.15.4 CGA Parameter Data Structure Option Format
This option contains the CGA parameter data structure (hereafter This option contains the CGA parameter data structure (hereafter
called the PDS). When HBA is used to validate the locators, the PDS called the PDS). When HBA is used to validate the locators, the PDS
contains the HBA multiprefix extension. When CGA is used to validate contains the HBA multiprefix extension. When CGA is used to validate
the locators, in addition to the CGA PDS, the signature will need to the locators, in addition to the CGA PDS, the signature will need to
be included as a CGA Signature option. be included as a CGA Signature option.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 4 |0| Length | | Type = 4 |0| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ CGA Parameter Data Structure ~ ~ CGA Parameter Data Structure ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
CGA Parameter Data Structure: Variable length content. Content CGA Parameter Data Structure: Variable length content. Content
defined in [5]. defined in [5] and [6].
5.14.5 CGA Signature Option Format 5.15.5 CGA Signature Option Format
When CGA is used for validation of one or more of the locators in the When CGA is used for validation of one or more of the locators in the
PDS, then the message in question will need to contain this option. PDS, then the message in question will need to contain this option.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 5 |0| Length | | Type = 5 |0| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ CGA Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
CGA Signature: Variable length content. Content defined in [5]. CGA Signature: A variable-length field containing a PKCS#1 v1.5
signature, constructed by using the sender's private
key over the following sequence of octets:
1. The 128-bit CGA Message Type tag [CGA] value for
SHIM6, 0x4A 30 5662 4858 574B 3655 416F 506A 6D48.
(The tag value has been generated randomly by the
editor of this specification.).
2. The Locator List Generation value of the
correspondent Locator List Option.
3. The subset of locators included in the
correspondent Locator List Option which validation
method is set to CGA. The locators MUST be
included in the order they are listed in the
Locator List Option.
5.14.6 ULID Pair Option Format 5.15.6 ULID Pair Option Format
It isn't clear whether we need this option. It depends whether we It isn't clear whether we need this option. It depends whether we
want to be able to setup a context for a ULID pair when that ULID want to be able to setup a context for a ULID pair when that ULID
pair can't be used to communicate. Thus the IPv6 addresses in the pair can't be used to communicate. Thus the IPv6 addresses in the
context establishment would not be the ULIDs. context establishment would not be the ULIDs.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 |0| Length | | Type = 2 |0| Length |
skipping to change at page 34, line 25 skipping to change at page 35, line 25
+ Receiver ULID + + Receiver ULID +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
Reserved: 48-bit field. Reserved for future use. Zero on Reserved: 48-bit field. Reserved for future use. Zero on
transmit. MUST be ignored on receipt. transmit. MUST be ignored on receipt.
Sender ULID: A 128-bit IPv6 address. Sender ULID: A 128-bit IPv6 address.
Receiver ULID: A 128-bit IPv6 address. Receiver ULID: A 128-bit IPv6 address.
5.14.7 Packet In Error Option Format 5.15.7 Packet In Error Option Format
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 7 |0| Length | | Type = 7 |0| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 header, shim6/TCP/UDP header, etc ~ ~ IPv6 header, shim6/TCP/UDP header, etc ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
Packet: A variable length field which contains the packet in Packet: A variable length field which contains the packet in
error starting with the IPv6 header. error starting with the IPv6 header.
5.14.8 Explorer Results Option Format 5.15.8 SHIM6 Event Option Format
TBD: This needs to indicate which explorer messages (sequence
numbers, source and destination locators?) that have been recently
received, in order to detect which locator pairs work when there is
no locator pair which works in both directions. When indicating
locators it makes sense to use the offset in the Locator List (that
was carries in the Locator List option), since this takes less space
than including the locators themselves.
TBD: add that data and other shim control messages are included in
the learned results.
p
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8 |0| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Locator List Generation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Locator List Generation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Explorer Results ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Sender Locator List Generation: The generation number for the
sender's locator list to which the indices below
refer.
Receiver Locator List Generation: The generation number for the
receiver's locator list to which the indices below
refer.
Explorer Results: This field contains a list of elements, where each
element indicates one locator pair for which the
sender of the option has recently received a message.
Each result occupies 32 bits. The list should be
ordered so that the most recently heard locator pairs
are first. SHOULD NOT include locator pairs that were
last received more than some number of seconds ago.
p
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Index | Receiver Index| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: This option is defined in [8].
Sender Index: 8-bit unsigned Integer. The Index is relative to the
sender's locator list.
Receiver Index: 8-bit unsigned Integer. The Index is relative to the
receiver locator list.
Sequence Number: 16-bit unsigned Integer. The Sequence number of the
explorer message in which the locator pair < sender
index, receiver index> was last heard. If this
locator pair was last heard in a message other than an
Explore message, then this number is zero.
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.
6.1 Conceptual Data Structures 6.1 Conceptual Data Structures
The key conceptual data structure for the shim6 protocol is the host The key conceptual data structure for the shim6 protocol is the host
pair context. This is a data structures which contains the following pair context. This is a data structure which contains the following
information: information:
o The peer ULID; ULID(peer) o The peer ULID; ULID(peer)
o The local ULID; ULID(local) o The local ULID; ULID(local)
o The list of peer locators, with their preferences; Ls(peer) o The list of peer locators, with their preferences; Ls(peer)
o For each peer locator, the validation method to use (from the
Locator List option).
o For each peer locator, a bit whether it has been validated using o For each peer locator, a bit whether it has been validated using
HBA, and a bit whether the locator has been probed to verify that HBA or CGA, and a bit whether the locator has been probed to
the ULID is present at that location. verify that the ULID is present at that location.
o The preferred peer locator - used as destination; Lp(peer) o The preferred peer locator - used as destination; Lp(peer)
o The set of local locators and the preferences; Ls(local) o The set of local locators and the preferences; Ls(local)
o The preferred local locator - used as source; Lp(local) o The preferred local locator - used as source; Lp(local)
o The context tag used to transmit control messages and ULP packets o The context tag used to transmit control messages and ULP packets
- allocated by the peer; CT(peer) - allocated by the peer; CT(peer)
o The context to expect in received control messages and extension o The context to expect in received control messages and extension
headers - allocated by the local host; CT(local) headers - allocated by the local host; CT(local)
o Reachability state for the locator pairs. o Reachability state for the locator pairs.
o During pair exploration, information about the explore messages o During pair exploration, information about the probe messages that
that have been sent and received. have been sent and received.
The receiver finds the context by looking it up using <Source The receiver finds the context by looking it up using <Source
Locator, Destination Locator, CT(local)>, where the context tag is in Locator, Destination Locator, CT(local)>, where the context tag is in
the shim header. The sender needs to be able to find the context the shim header. The sender needs to be able to find the context
state when a ULP packet is passed down from the ULP. In that case state when a ULP packet is passed down from the ULP. In that case
the lookup key is the pair of ULIDs. the lookup key is the pair of ULIDs.
7. Establishing Host Pair Contexts 7. Establishing Host Pair Contexts
Host pair contexts are established using a 4-way exchange, which Host pair contexts are established using a 4-way exchange, which
skipping to change at page 37, line 20 skipping to change at page 37, line 15
Initiator Responder Initiator Responder
------------- I1 --------------> ------------- I1 -------------->
<------------ R1 --------------- <------------ R1 ---------------
------------- I2 --------------> ------------- I2 -------------->
<------------ R2 --------------- <------------ R2 ---------------
Figure 26 Figure 24
7.2 Concurrent context establishment 7.2 Concurrent context establishment
When both ends try to initiate a context for the same ULID pair, then When both ends try to initiate a context for the same ULID pair, then
we might end up with crossing I1 messages, or since the no state is we might end up with crossing I1 messages, or since the no state is
created when receiving the I1, a host might send a I1 after having created when receiving the I1, a host might send a I1 after having
sent a R1 message. sent a R1 message.
Since a host remembers that it has sent an I1, it can respond to an Since a host remembers that it has sent an I1, it can respond to an
I1 from the peer (for the same ULID), with a R2. I1 from the peer (for the same ULID), with a R2.
skipping to change at page 38, line 4 skipping to change at page 37, line 46
<--- <---
-\ -\
---\ ---\
---\ /--- ---\ /---
--- R2 ---\ /--- --- R2 ---\ /---
---\ ---\
/--- R2 ---/ ---\ /--- R2 ---/ ---\
/--- --> /--- -->
<--- <---
Figure 27
Figure 25
If a host has received an I1 and sent an R1, then a ULP can trigger If a host has received an I1 and sent an R1, then a ULP can trigger
it to send an I1 message itself, since it doesn't retain any state it to send an I1 message itself, since it doesn't retain any state
when receiving the I1 message. Thus while one end is sending an I1 when receiving the I1 message. Thus while one end is sending an I1
the other is sending an I2. the other is sending an I2.
Initiator Responder Initiator Responder
-\ -\
---\ ---\
skipping to change at page 38, line 46 skipping to change at page 38, line 41
-\ -\
---\ ---\
---\ /--- ---\ /---
--- R2 ---\ /--- --- R2 ---\ /---
---\ ---\
/--- R2 ---/ ---\ /--- R2 ---/ ---\
/--- --> /--- -->
<--- <---
Figure 28 Figure 26
7.3 Context recovery 7.3 Context recovery
Due to garbage collection, we can end up with one end having and Due to garbage collection, we can end up with one end having and
using the context state, and the other end not having any state. We using the context state, and the other end not having any state. We
need to be able to recover this state at the end that has lost it, need to be able to recover this state at the end that has lost it,
before we can use it. before we can use it.
This need can arise in two cases: This need can arise in two cases:
The communication is working using the ULID pair as the locator
o The communication is working using the ULID pair as the locator
pair, but a problem arises, and the end that has retained the pair, but a problem arises, and the end that has retained the
context state decides to explore alternate locator pairs. context state decides to probe and explore alternate locator
The communication is working using a locator pair that is not the pairs.
o The communication is working using a locator pair that is not the
ULID pair, hence the ULP packets sent from a peer that has ULID pair, hence the ULP packets sent from a peer that has
retained the context state use the shim payload header. retained the context state use the shim payload header.
In both cases the result is that the peer without state receives a In both cases the result is that the peer without state receives a
shim message for which it has to context for the <source locator, shim message for which it has to context for the <source locator,
destination locator, context tag>. destination locator, context tag>.
In both of those case we can recover the context by having the node In both of those case we can recover the context by having the node
which doesn't have a context state, send back an R1bis [TBD] message, which doesn't have a context state, send back an R1bis [TBD] message,
and have this complete a recover with a I2 and R2 message. and have this complete a recover with a I2 and R2 message.
skipping to change at page 39, line 42 skipping to change at page 39, line 39
it, while the other end has lost the state. We discussed this in the it, while the other end has lost the state. We discussed this in the
previous section on recovery. But for the same reasons, when one previous section on recovery. But for the same reasons, when one
host retains context tag X for ULID pair <A1, B1>, the other end host retains context tag X for ULID pair <A1, B1>, the other end
might end up allocating that context tag for another ULID pair, e.g., might end up allocating that context tag for another ULID pair, e.g.,
<A3, B1> between the same hosts. In this case we can not use the <A3, B1> between the same hosts. In this case we can not use the
recovery mechanisms since there needs to be separate context tags for recovery mechanisms since there needs to be separate context tags for
the two ULID pairs. the two ULID pairs.
This type of "confusion" can be observed in two cases (assuming it is This type of "confusion" can be observed in two cases (assuming it is
A that has retained the state and B has dropped it): A that has retained the state and B has dropped it):
B decides to create a context for ULID pair <A3, B1&gt, and o B decides to create a context for ULID pair <A3, B1>, and
allocates X as its context tag for this, and sends an I1 to A. allocates X as its context tag for this, and sends an I1 to A.
A decides to create a context for ULID pair <A3, B1&gt, and starts o A decides to create a context for ULID pair <A3, B1>, and starts
the exchange by sending I1 to B. When B receives the I2 message, the exchange by sending I1 to B. When B receives the I2 message,
it allocates X as the context tag for this context. it allocates X as the context tag for this context.
In both cases, A can detect that B has allocated X for ULID pair <A3, In both cases, A can detect that B has allocated X for ULID pair <A3,
B1&gt even though that A still X as CT(peer) for ULID pair <A1, B1> even though that A still X as CT(peer) for ULID pair <A1, B1>.
B1&gt. Thus A can detect that B must have lost the context for <A1, Thus A can detect that B must have lost the context for <A1, B1>.
B1&gt.
The solution to this issue is TBD. The know possibilities are: The solution to this issue is TBD. The know possibilities are:
Have A forcibly destroy the context for <A1, B1&gt, so that it can o Have A forcibly destroy the context for <A1, B1>, so that it can
accept the new context for <A3, B1&gt. accept the new context for <A3, B1>.
Have A accept the context for <A3, B1&gt, forget about the old
context, but initiate a new (replacement) context for <A1, B1&gt o Have A accept the context for <A3, B1>, forget about the old
by sending an I1 message. That I1 through R2 exchange will make B context, but initiate a new (replacement) context for <A1, B1> by
allocate a new context tag for <A1, B1&gt. sending an I1 message. That I1 through R2 exchange will make B
Avoid the problem by changing the context tag allocation so that A allocate a new context tag for <A1, B1>.
o Avoid the problem by changing the context tag allocation so that A
and B allocates half of the bits (16 each) of the context tags, so and B allocates half of the bits (16 each) of the context tags, so
that even if one end looses state, the peer can make sure that the that even if one end looses state, the peer can make sure that the
context tags for each context are unique. context tags for each context are unique.
7.5 Sending I1 messages 7.5 Sending I1 messages
When the shim layer decides to setup a context for a ULID pair, it When the shim layer decides to setup a context for a ULID pair, it
starts by allocating and initializing the context state for its end. starts by allocating and initializing the context state for its end.
As part of this it assigns its context tag to the context. Then it As part of this it assigns its context tag to the context. Then it
can send an I1 message. can send an I1 message.
skipping to change at page 41, line 15 skipping to change at page 41, line 12
If there is no existing context state, then the host forms a verifier If there is no existing context state, then the host forms a verifier
and sends this back to the peer in an I2 message. No state is and sends this back to the peer in an I2 message. No state is
created on the host in this case. created on the host in this case.
7.7 Receiving R1 messages 7.7 Receiving R1 messages
When the host receives an R1 message, it verifies that the nonce When the host receives an R1 message, it verifies that the nonce
matches what it sent in the I1 message, and that it has context state matches what it sent in the I1 message, and that it has context state
for the ULID pair. It then sends an I2 message, which includes the for the ULID pair. It then sends an I2 message, which includes the
verifier option that was in the R1 message. The I2 message also verifier option that was in the R1 message. The I2 message also
includes A's locator list and the CGA parameter set. If CGA (and not includes A's locator list and the CGA parameter data structure. If
HBA) is used to verify the locator list, then A also signs things and CGA (and not HBA) is used to verify the locator list, then A also
includes a CGA signature option. signs the key parts of the message and includes a CGA signature
option containing the signature.
The host may receive an R1[bis] TBD message that was not sent in The host may receive an R1[bis] TBD message that was not sent in
response to an I1 message but instead sent as a result of context response to an I1 message but instead sent as a result of context
recovery. The difference between an R1bis and an R1 message is that recovery. The difference between an R1bis and an R1 message is that
the former use the context tag of the responder??? TBD how there are the former use the context tag of the responder. TBD how there are
handled and whether they are identical to an R1. handled and whether they are identical to an R1.
7.8 Retransmitting I2 messages 7.8 Retransmitting I2 messages
If the initiator does not receive an R2 message after sending an I2 If the initiator does not receive an R2 message after sending an I2
message it MAY retransmit the I2 message. But since the verifier message it MAY retransmit the I2 message. But since the verifier
option might have a limited lifetime, that is, the peer might reject option might have a limited lifetime, that is, the peer might reject
verifier options that are too old to avoid replay attacks, the verifier options that are too old to avoid replay attacks, the
initiator SHOULD fall back to retransmitting the I1 message when initiator SHOULD fall back to retransmitting the I1 message when
there is no response to one or a few I2 messages. there is no response to one or a few I2 messages.
skipping to change at page 42, line 31 skipping to change at page 42, line 30
MAY verify the peers locator set at this point in time, but the MAY verify the peers locator set at this point in time, but the
requirement is that a locator MUST be verified before the host starts requirement is that a locator MUST be verified before the host starts
sending packets to that locator, thus the host MAY defer the sending packets to that locator, thus the host MAY defer the
verification until later. verification until later.
8. No Such Content Errors 8. No Such Content Errors
TBD TBD
The Interim Meeting discussed ways to recover the context state at The Interim Meeting discussed ways to recover the context state at
one end when the other end sees a failure (and starts sending Explore one end when the other end sees a failure (and starts sending Probe
messages). The discussed approach is to use a R1 (or R1bis) message messages). The discussed approach is to use a R1 (or R1bis) message
in response to a message with an unknown context, which would cause in response to a message with an unknown context, which would cause
the context to be recreated. the context to be recreated.
The idea is that on receipt of a SHIM6 payload packet where there is
no current SHIM6 context at the receiver, the receiver is to respond
with an R1bis packet in order to re-establish SHIM6 context. The
R1bis packet differs from the R1 packet in that an R1 packet echoes
the I1 fields, while this R1bis offers state back to the sender. One
key difference is that the I1 packet contains the initiator's context
tag, while the payload message header contains the receivers context
tag. Either way the next control packet is an I2 in response. The
senders previous context state is to be flushed in receipt of the R2
packet following the R1bis, I2 exchange.
The details of this type of exchange needs to be worked out, but the
likely result is that we will not need a separate "No context" error
message.
9. Handling ICMP Error Messages 9. Handling ICMP Error Messages
The routers in the path as well as the destination might generate The routers in the path as well as the destination might generate
various ICMP error messages, such as host unreachable, packet too various ICMP error messages, such as host unreachable, packet too
big, and payload type unknown. It is critical that these packets big, and payload type unknown. It is critical that these packets
make it back up to the ULPs so that they can take appropriate action. make it back up to the ULPs so that they can take appropriate action.
When the ULP packets are sent unmodified, that is, while the initial When the ULP packets are sent unmodified, that is, while the initial
locators=ULIDs are working, this introduces no new concerns; an locators=ULIDs are working, this introduces no new concerns; an
implementation's existing mechanism for delivering these errors to implementation's existing mechanism for delivering these errors to
skipping to change at page 43, line 35 skipping to change at page 43, line 48
might be cases when the knowledge is not readily available to the might be cases when the knowledge is not readily available to the
shim layer, for instance for UDP applications which not not connect shim layer, for instance for UDP applications which not not connect
their sockets, or any application which retains some higher level their sockets, or any application which retains some higher level
state across (TCP) connections and UDP packets. state across (TCP) connections and UDP packets.
Thus it is RECOMMENDED that implementations minimize premature Thus it is RECOMMENDED that implementations minimize premature
teardown by observing the amount of traffic that is sent and received teardown by observing the amount of traffic that is sent and received
using the context, and only after it appears quiescent, tear down the using the context, and only after it appears quiescent, tear down the
state. state.
TBD: The Interim meeting discussed whether it was feasible to relax
this so that one can end up with an asymmetric distribution of the
context state and still get (most of) the shim benefits. For
example, the busy server would go through the context setup but would
quickly remove the context state after this (in order to save memory)
but the not-so-busy client would retain the context state. The
context recover mechanism presented in Section 7.3 would then be
recreate the state should the client send either a shim control
message (e.g., probe message because it sees a problem), or a ULP
packet in an payload extension header (because it had earlier failed
over to an alternative locator pair, but had been silent for a
while). This seems to provide the benefits of the shim as long as
the client can detect the failure. If the client doesn't send
anything, and it is the server that tries to send, then it will not
be able to recover because the shim on the server has no context
state, hence doesn't know any alternate locator pairs.
11. Updating the Locator Pairs 11. Updating the Locator Pairs
TBD TBD
The validation issues for the locators carried in the Locator Update
message are specified in Section 4.4.
12. Various Probe Mechanisms 12. Various Probe Mechanisms
TBD TBD
13. Rehoming to a Different Locator Pair 13. Rehoming to a Different Locator Pair
TBD TBD
14. Payload Packets before a Switch 14. Sending ULP Payloads
When there is no context state for the ULID pair on the sender, there When there is no context state for the ULID pair on the sender, there
is no effect on how ULP packets are sent. If the host is using some is no effect on how ULP packets are sent. If the host is using some
heuristic for determining when to perform a deferred context heuristic for determining when to perform a deferred context
establishment, then the host might need to do some accounting (count establishment, then the host might need to do some accounting (count
the number of packets sent and received) even before there is a host- the number of packets sent and received) even before there is a host-
pair context. This need to count packets might also appear on the pair context.
receive side, depending on what heuristics the implementation has
chosen.
If there is a host-pair context for the ULID pair, then the sender If there is a host-pair context for the ULID pair, then the sender
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 will be sent unmodified by the If this is the case, then packets will be sent unmodified by the
shim. If it is not the case, then the logic in Section 15 will need shim. If it is not the case, then the logic in Section 14.1 will
to be used. need to be 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 will be covered is follow-ons to [6]. this document and will be covered is follow-ons to [7].
15. Payload Packets after a Switch 14.1 Sending ULP Payload after a Switch
When sending packets, if there is a host-pair context for the ULID When sending packets, if there is a host-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.
First, the IP address fields are replaced. The IPv6 source address First, the IP address fields are replaced. The IPv6 source address
field is set to Lp(local) and the destination address field is set to field is set to Lp(local) and the destination address field is set to
skipping to change at page 44, line 48 skipping to change at page 45, line 32
ULP might have included, thus it skips any hop-by-hop extension ULP might have included, thus it skips any hop-by-hop extension
header, any routing header, and any destination options header that header, any routing header, and any destination options header that
is followed by a routing header. After any such headers the shim6 is followed by a routing header. After any such headers the shim6
extension header will be added. This might be before a Fragment extension header will be added. This might be before a Fragment
header, a Destination Options header, an ESP or AH header, or a ULP header, a Destination Options header, an ESP or AH header, or a ULP
header. header.
The inserted shim6 Payload extension header includes the peer's The inserted shim6 Payload extension header includes the peer's
context tag. context tag.
The receiver parses the (extension) headers in order. Should it find 15. Receiving Packets
a shim6 extension header it will look at the type field in that
header. If the type is Payload message, then the packet must be As in normal IPv6 receive side packet processing the receiver parses
passed to the shim6 payload handling for rewriting. (Otherwise, the the (extension) headers in order. Should it find a shim6 extension
shim6 control messages are handled as specified in other parts of header it will look at the type field in that header. If the type is
this document.) Payload message, then the packet must be passed to the shim6 payload
handling for rewriting. (Otherwise, the shim6 control messages are
handled as specified in other parts of this document.)
The receiver extracts the context tag from the payload message The receiver extracts the context tag from the payload message
header, and uses this together with the IPv6 source and destination header, and uses this together with the IPv6 source and destination
address fields to find a host-pair context. If no context is found, address fields to find a host-pair context. If no context is found,
the receiver SHOULD generate a No Such Context error message (see the receiver SHOULD generate a No Such Context error message (see
Section 8). Section 8).
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).
16. Open Issues If the host is using some heuristic for determining when to perform a
deferred context establishment, then the host might need to do some
accounting (count the number of packets sent and received) for
packets that does not have a shim6 extension header. But the need
for this depends on what heuristics the implementation has chosen.
16. Initial Contact
TBD Describe what inital contact is (basically some non-shim
communication starts between two ULIDs), and what the implications
are of failures. Basic option is to rely on the application retrying
and RFC 3484bis ordering of source and destination ULIDs.
17. Open Issues
The following open issues are known: The following open issues are known:
o Is there need for keeping the list of locators private between the
two communicating endpoints? We can potentially accomplish that
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
the context establishment.
o Forking the context state. On the mailing list we've discussed o Forking the context state. On the mailing list we've discussed
the need to fork the context state, so that different ULP streams the need to fork the context state, so that different ULP streams
can be sent using different locator pairs. No protocol extensions can be sent using different locator pairs. No protocol extensions
are needed if any forking is done independently by each endpoint. are needed if any forking is done independently by each endpoint.
But if we want A to be able to tell B that certain traffic (a But if we want A to be able to tell B that certain traffic (a
5-tuple?) should be forked, then we need a way to convey this in 5-tuple?) should be forked, then we need a way to convey this in
the shim6 protocol. The hard part would be defining what the shim6 protocol. The hard part would be defining what
selectors can be specified for the filter which determines which selectors can be specified for the filter which determines which
traffic uses which of the forks. So the question is whether we traffic uses which of the forks. So the question is whether we
really need signaling for forking, or whether it is sufficient to really need signaling for forking, or whether it is sufficient to
allow each endpoint to do its own selection of which locator pair allow each endpoint to do its own selection of which locator pair
it is using for which traffic. it is using for which traffic.
o If we allow forking, it seems like the mechanism for reachability o If we allow forking, it seems like the mechanism for reachability
detection, whether it is CUD or FBD, must be applied separately detection, whether it is CUD or FBD, must be applied separately
for each locator pair that is in use. Without forking a single for each locator pair that is in use. Without forking a single
locator pair will be in use for each host-pair context, hence locator pair will be in use for each host-pair context, hence
things would be simpler. things would be simpler.
o The specified mechanism (of relying on No Such Context errors)
doesn't always detect the loss of the context on the peer when the
original ULID=locators are used. See Section 17 for other
options.
o In the Locator List option, do we need to indicate which locators
need to be validated using HBA vs. CGA? Or it could tell which
locators are in the HBA extension in the PDS, and assume any
others need CGA validation.
o What happens when a host runs out of N bit context tags? When is o What happens when a host runs out of N bit context tags? When is
it safe for a host to reuse a context tag? With the unilateral it safe for a host to reuse a context tag? With the unilateral
teardown one end might discard the context state long before the teardown one end might discard the context state long before the
other end. other end.
o Should a host explicitly fail communication when a ULID becomes
invalid (based on RFC 2462 lifetimes or DHCPv6), or should we let
the communication continue using the invalidated ULID (it can
certainly work since other locators will be used).
o Should we rename "host-pair context" to be "ULID-pair context"?
If we've decided this is per ULID pair that might make sense.
17. Design Alternatives o We need to pick some initial retransmit timers for I1 and I2. Is
4 seconds ok?
This document has picked a certain set of design choices in order to o Should we require that the R1 verifier be usable for some minimum
try to work out a bunch of the details, and stimulate discussion. time so that the initiator knows for how long time it can safely
But as has been discussed on the mailing list, there are other retransmit I2 before it needs to go back to sending I1 again?
choices that make sense. This section tries to enumerate some o Should we expand the context tag from 32 to 47 bits?
alternatives. o Should we make the receiver not use the source locator to find the
context, but instead only use the context tag? (and optionally,
17.1 State Cleanup the destination locator). This would provide some flexibility for
the future. The potential downside, which we would need to
This document uses a timer based cleanup mechanism, as specified in understand, is packet injection. *If* there is ingress filtering,
Section 10. then we get some extra checking by including the source locator in
the lookup. But an on-path attacker can inject packets at will,
An alternative would be to use an explicit CLOSE mechanism, akin to whether the source locator is part of the lookup or not. An off-
the one specified in HIP [22]. If an explicit CLOSE handshake and path attacker would have a hard time to guess a 47-bit number.
associated timer is used, then there would no longer be a need for o Include locator list in R1 message to deal with R2 being dropped?
the No Context Error message due to a peer having garbage collected o Should we allow a host to intentionally discard the context state,
its end of the context. However, there is still potentially a need with the assumption that the peer is responsible to maintain it,
to have a No Context Error message in the case of a complete state and detect failures? This might be useful in asymetric case, e.g.
loss of the peer (also known as a crash followed by a reboot). Only a server which serves lots of clients, but it can't recover from
if we assume that the reboot takes at least the CLOSE timer, or that all failures. For instance, if the client doesn't send anything
it is ok to not provide complete service until CLOSE timer minutes for a while, and when the server starts to send the locator pair
after the crash, can we completely do away with the No Context Error doesn't work any more. In this case the server can do nothing
message. since it doesn't have a context with alternate locators, and the
client can't possibly know that the server might be having
17.2 Detecting Context Loss problems reaching it.
o When does a host need to verify the locator list? Immediately
This document specifies that context loss is detected by receiving a i.e. before accepting packets from those locators as the source
No Such Context error message from the peer. Such messages are address? Or before sending packets to those locators? There are
generated in response to a shim6 message that contain a the peer's some issues if it isn't verified immediately since it allows an
context tag, including the shim6 Payload messages, when the receiver on-path attacker to send bogus update messages which can not be
doesn't have matching context. They are also generated in response verified; that would potentially make the host no longer accept
to data packets after a locator switch (because such payload packets packets from the actual locator that the peer is using, and when
are identified as such by using the payload message header). it tries to verify the locators it would find that they are "bad"
and has no alternate peer locator it can use. This is the case
This approach has the disadvantage that it doesn't detect the loss of even if the peer has sent a locator list as long as the attacker
context state when the original ULIDs are used as locators, because has sent a more recent one.
there might be no shim6 messages exchanged if the reachability
detection manages to suppress any extra messages.
The Interim Meeting discussed ways to recover the context state at
one end when the other end sees a failure (and starts sending Explore
messages). The discussed approach is to use a R1 (or R1bis) message
in response to a message with an unknown context, which would cause
the context to be recreated.
18. Implications Elsewhere 18. 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 [17]. But in order for such applications to be as described in [18]. But in order for such applications to be
able to take advantage of the multiple locators for redundancy, able to take advantage of the multiple locators for redundancy,
the applications need to be modified to either use fully qualified the applications need to be modified to either use fully qualified
domain names as the 'identifiers', or they need to pass all the domain names as the 'identifiers', or they need to pass all the
locators as the 'identifiers' i.e., the 'identifier' from the locators as the 'identifiers' i.e., the 'identifier' from the
applications perspective becomes a set of IP addresses instead of applications perspective becomes a set of IP addresses instead of
a single IP address. a single IP address.
o 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
messages would be dropped, hence the hosts would not discover that messages would be dropped, hence the hosts would not discover that
skipping to change at page 48, line 15 skipping to change at page 48, line 47
to the path MTU mechanism to try a larger MTU? to the path MTU mechanism to try a larger MTU?
The fact that the shim, at least for uncommon payload types, will The fact that the shim, at least for uncommon payload types, will
add an 8 octet extension header (the payload message) after a add an 8 octet extension header (the payload message) after a
locator switch, can also affect the usable path MTU for the ULPs. locator switch, can also affect the usable path MTU for the ULPs.
In this case the MTU change is local to the sending host, thus In this case the MTU change is local to the sending host, thus
conveying the change to the ULPs is an implementation matter. conveying the change to the ULPs is an implementation matter.
19. Security Considerations 19. Security Considerations
This document satisfies the concerns specified in [16] as follows: This document satisfies the concerns specified in [17] as follows:
o TBD: Using HBA or CGA for ... o TBD: Using HBA or CGA for ...
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 No Such Context error to cause one been established) can use the No Such Context error to cause one
peer to recreate the context, and at that point in time the peer to recreate the context, and at that point in time the
attacker can observe all of the exchange. But this doesn't seem attacker can observe all of the exchange. But this doesn't seem
to open any new doors for the attacker since such an attacker can to open any new doors for the attacker since such an attacker can
observe the Context tags that are being used, and once known it observe the Context tags that are being used, and once known it
can use those to send bogus messages. can use those to send bogus messages.
o An attacker which is present on the path so that it can find out o An attacker which is present on the path so that it can find out
the context tags, can generate a No Such Context error after it the context tags, can generate a No Such Context error after it
has moved off the path. For this packet to be effective it needs has moved off the path. For this packet to be effective it needs
skipping to change at page 48, line 49 skipping to change at page 49, line 35
between two hosts. We can make this harder by using a larger between two hosts. We can make this harder by using a larger
context tag; 47 bits is the largest that fit in the 8-octet context tag; 47 bits is the largest that fit in the 8-octet
payload header. If this isn't sufficient, one could use an even payload header. If this isn't sufficient, one could use an even
larger tag in the shim6 control messages, and use the low-order 47 larger tag in the shim6 control messages, and use the low-order 47
bits in the payload header. bits in the payload header.
20. IANA Considerations 20. IANA Considerations
IANA needs to allocate a new IP Next Header value for this protocol. IANA needs to allocate a new IP Next Header value for this protocol.
IANA also needs to record a CGA message type for this protocol in the
[CGA] namespace, 0x4A30 5662 4858 574B 3655 416F 506A 6D48.
TBD: the IANA rules for the shim6 message types and option types. TBD: the IANA rules for the shim6 message types and option types.
21. Change Log 21. Possible Protocol Extensions
During the development of this protocol, several issues have been
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
extensions to the protocol. The key ones are:
o Is there need for keeping the list of locators private between the
two communicating endpoints? We can potentially accomplish that
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
the context establishment. The suggestion is to leave this for a
future extension to the protocol.
o Defining some form of end-to-end "compression" mechanism that
removes the need for including the Shim6 Payload extension header
when the locator pair is not the ULID pair.
22. Change Log
The following changes have been made since draft-ietf-shim6-proto-00: The following changes have been made since draft-ietf-shim6-proto-00:
o Removed the use of the flow label and the overloading of the IP o Removed the use of the flow label and the overloading of the IP
protocol numbers. Instead, when the locator pair is not the ULID protocol numbers. Instead, when the locator pair is not the ULID
pair, the ULP payloads will be carried with an 8 octet extension pair, the ULP payloads will be carried with an 8 octet extension
header. The belief is that it is possible to remove these extra header. The belief is that it is possible to remove these extra
bytes by defining future shim6 extensions that exchange more bytes by defining future shim6 extensions that exchange more
information between the hosts, without having to overload the flow information between the hosts, without having to overload the flow
label or the IP protocol numbers. label or the IP protocol numbers.
o Grew the context tag from 20 bits to 32 bits, with the possibility o Grew the context tag from 20 bits to 32 bits, with the possibility
skipping to change at page 49, line 39 skipping to change at page 50, line 43
o In order for FBD and exploration to work when there the use of the o In order for FBD and exploration to work when there the use of the
context is forked, that is different ULP messages are sent over context is forked, that is different ULP messages are sent over
different locator pairs, things are a lot easier if there is only different locator pairs, things are a lot easier if there is only
one current locator pair used for each context. Thus the forking one current locator pair used for each context. Thus the forking
of the context is now causing a new context to be established for of the context is now causing a new context to be established for
the same ULID; the new context having a new context tag. The the same ULID; the new context having a new context tag. The
original context is referred to as the "default" context for the original context is referred to as the "default" context for the
ULID pair. ULID pair.
o Added more background material and textual descriptions. o Added more background material and textual descriptions.
22. Acknowledgements 23. 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 draft. contributed ideas a suggestions that are reflected in this draft.
Thanks to Marcelo Bagnulo for providing comments on earlier versions Thanks to Marcelo Bagnulo for providing comments on earlier versions
of this draft. of this draft.
23. References Appendix A. Design Alternatives
23.1 Normative References This document has picked a certain set of design choices in order to
try to work out a bunch of the details, and stimulate discussion.
But as has been discussed on the mailing list, there are other
choices that make sense. This appendix tries to enumerate some
alternatives.
Appendix A.1 Context granularity
TBD
Appendix A.2 Demultiplexing of data packets in shim6 communications
Once a Host-pair context is established between two hosts, packets
may carry locators that differ from the ULIDs presented to the ULPs
using the established context. One of main functions of the SHIM6
layer is to perform the mapping between the locators used to forward
packets through the network and the ULIDs presented to the ULP. In
order to perform that translation for incoming packets, the SHIM6
layer needs to first identify which of the incoming packets need to
be translated and then perform the mapping between locators and ULIDs
using the associated context. Such operation is called
demultiplexing. It should be noted that because any address can be
used both as a locator and as a ULID, additional information other
than the addresses carried in packets, need to be taken into account
for this operation.
For example, if a host has address A1 and A2 and starts communicating
with a peer with addresses B1 and B2, then some communication
(connections) might use the pair <A1, B1> as ULID and others might
use e.g., <A2, B2>. Initially there are no failures so these address
pairs are used as locators i.e. in the IP address fields in the
packets on the wire. But when there is a failure the shim6 layer on
A might decide to send packets that used <A1, B1> as ULIDs using <A2,
B2> as the locators. In this case B needs to be able to rewrite the
IP address field for some packets and not others, but the packets all
have the same locator pair.
In order to accomplish the demultiplexing operation successfully,
data packets carry a context tag that allows the receiver of the
packet to determine the shim context to be used to perform the
operation.
Two mechanisms for carrying the context tag information have been
considered in depth during the shim protocol design. Those carrying
the context tag in the flow label field of the IPv6 header and the
usage of a new extension header to carry the context tag. In this
appendix we will describe the pros and cons of each approach and
justify the selected option.
Appendix A.2.1 Flow-label
A possible approach is to carry the context tag in the Flow Label
field of the IPv6 header. This means that when a shim6 context is
established, a Flow Label value is associated with this context (and
perhaps a separate flow label for each direction).
The simplest approach that does this is to have the triple <Flow
Label, Source Locator, Destination Locator> identify the context at
the receiver.
The problem with this approach is that because the locator sets are
dynamic, it is not possible at any given moment to be sure that two
contexts for which the same context tag is allocated will have
disjoint locator sets during the lifetime of the contexts.
Suppose that Node A has addresses IPA1, IPA2, IPA3 and IPA4 and that
Host B has addresses IPB1 and IPB2.
Suppose that two different contexts are established between HostA and
HostB.
Context #1 is using IPA1 and IPB1 as ULIDs. The locator set
associated to IPA1 is IPA1 and IPA2 while the locator set associated
to IPB1 is just IPB1.
Context #2 uses IPA3 and IPB2 as ULIDs. The locator set associated
to IPA3 is IPA3 and IPA4 and the locator set associated to IPB2 is
just IPB2.
Because the locator sets of the Context #1 and Context # 2 are
disjoint, hosts could think that the same context tag value can be
assigned to both of them. The problem arrives when later on IPA3 is
added as a valid locator for IPA1 and IPB2 is added as a valid
locator for IPB1 in Context #1. In this case, the triple <Flow
Label, Source Locator, Destination Locator> would not identify a
unique context anymore and correct demultiplexing is no longer
possible.
A possible approach to overcome this limitation is simply not to
repeat the Flow Label values for any communication established in a
host. This basically means that each time a new communication that
is using different ULIDs is established, a new Flow Label value is
assigned to it. By this mean, each communication that is using
different ULIDs can be differentiated because it has a different Flow
Label value.
The problem with such approach is that it requires that the receiver
of the communication allocates the Flow Label value used for incoming
packets, in order to assign them uniquely. For this, a shim
negotiation of the Flow Label value to use in the communication is
needed before exchanging data packets. This poses problems with non-
shim capable hosts, since they would not be able to negotiate an
acceptable value for the Flow Label. This limitation can be lifted
by marking the packets that belong to shim sessions from those that
do not. These marking would require at least a bit in the IPv6
header that is not currently available, so more creative options
would be required, for instance using new Next Header values to
indicate that the packet belongs to a shim6 enabled communication and
that the Flow Label carries context information as proposed in the
now expire NOID draft. . However, even if this is done, this
approach is incompatible with the deferred establishment capability
of the shim protocol, which is a preferred function, since it
suppresses the delay due to the shim context establishment prior to
initiation of the communication and it also allows nodes to define at
which stage of the communication they decide, based on their own
policies, that a given communication requires to be protected by the
shim.
In order to cope with the identified limitations, an alternative
approach that does not constraints the flow label values used by
communications that are using ULIDs equal to the locators (i.e. no
shim translation) is to only require that different flow label values
are assigned to different shim contexts. In such approach
communications start with unmodified flow label usage (could be zero,
or as suggested in [15]). The packets sent after a failure when a
different locator pair is used would use a completely different flow
label, and this flow label could be allocated by the receiver as part
of the shim context establishment. Since it is allocated during the
context establishment, the receiver of the "failed over" packets can
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
performance impact, and respecting that for each locator pair, the
flow label value used for a given locator pair doesn't change due to
the operation of the multihoming shim.
In this approach, the constraint is that Flow Label values being used
as context identifiers cannot be used by other communications that
use non-disjoint locator sets. This means that once that a given
Flow Label value has been assigned to a shim context that has a
certain locator sets associated, the same value cannot be used for
other communications that use an address pair that is contained in
the locator sets of the context. This is a constraint in the
potential Flow Label allocation strategies.
A possible workaround to this constraint is to mark shim packets that
require translation, in order to differentiate them from regular IPv6
packets, using the artificial Next Header values described above. In
this case, the Flow Label values constrained are only those of the
packets that are being translated by the shim. This last approach
would be the preferred approach if the context tag is to be carried
in the Flow Label field. This is not only because it imposes the
minimum constraints to the Flow Label allocation strategies, limiting
the restrictions only to those packets that need to be translated by
the shim, but also because Context Loss detection mechanisms greatly
benefit from the fact that shim data packets are identified as such,
allowing the receiving end to identify if a shim context associated
to a received packet is suppose to exist, as it will be discussed in
the Context Loss detection appendix below.
Appendix A.2.2 Extension Header
Another approach is to carry the context tag in a new Extension
Header. These context tags are allocated by the receiving end during
the shim6 protocol initial negotiation, implying that each context
will have two context tags, one for each direction. Data packets
will be demultiplexed using the context tag carried in the Extension
Header. This seems a clean approach since it does not overload
existing fields. However, it introduces additional overhead in the
packet due to the additional header. The additional overhead
introduced is 8 octets. However, it should be noted that the context
tag is only required when a locator other than the one used as ULID
is contained in the packet. Packets where both the source and
destination address fields contain the ULIDs do not require a context
tag, since no rewriting is necessary at the receiver. This approach
would reduce the overhead, because the additional header is only
required after a failure. On the other hand, this approach would
cause changes in the available MTU for some packets, since packets
that include the Extension Header will have an MTU 8 octets shorter.
Appendix A.3 Context Loss Detection
In this appendix we will present different approaches considered to
detect context loss and potential context recovery strategies. The
scenario being considered is the following: Node A and Node B are
communicating using IPA1 and IPB1. Sometime later, a shim context is
established between them, with IPA1 and IPB1 as ULIDs and
IPA1,...,IPAn and IPB1,...,IPBm as locator set respectively.
It may happen, that later on, one of the hosts, e.g. Host A looses
the shim context. The reason for this can be that Host A has a more
aggressive garbage collection policy than HostB or that an error
occurred in the shim layer at host A resulting in the loss of the
context state.
The mechanisms considered in this appendix are aimed to deal with
this problem. There are essentially two tasks that need to be
performed in order to cope with this problem: first, the context loss
must be detected and second the context needs to be recovered/
reestablished.
Mechanisms for detecting context. loss
These mechanisms basically consist in that each end of the context
periodically sends a packet containing context-specific information
to the other end. Upon reception of such packets, the receiver
verifies that the required context exists. In case that the context
does not exist, it sends a packet notifying the problem to the
sender.
An obvious alternative for this would be to create a specific context
keepalive exchange, which consists in periodically sending packets
with this purpose. This option was considered and discarded because
it seemed an overkill to define a new packet exchange to deal with
this issue.
An alternative is to piggyback the context loss detection function in
other existent packet exchanges. In particular, both shim control
and data packets can be used for this.
Shim control packets can be trivially used for this, because they
carry context specific information, so that when a node receives one
of such packets, it will verify if the context exists. However, shim
control frequency may not be adequate for context loss detection
since control packet exchanges can be very limited for a session in
certain scenarios.
Data packets, on the other hand, are expected to be exchanged with a
higher frequency but they do not necessarily carry context specific
information. In particular, packets flowing before a locator change
(i.e. packet carrying the ULIDs in the address fields) do not need
context information since they do not need any shim processing.
Packets that carry locators that differ from the ULIDs carry context
information.
However, we need to make a distinction here between the different
approaches considered to carry the context tag, in particular between
those approaches where packets are explicitly marked as shim packets
and those approaches where packets are not marked as such. For
instance, in the case where the context tag is carried in the Flow
Label and packets are not marked as shim packets (i.e. no new Next
Header values are defined for shim), a receiver that has lost the
associated context is not able to detect that the packet is
associated with a missing context. The result is that the packet
will be passed unchanged to the upper layer protocol, which in turn
will probably silently discard it due to a checksum error. The
resulting behavior is that the context loss is undetected. This is
one additional reason to discard an approach that carries the context
tag in the Flow Label field and does not explicitly mark the shim
packets as such. On the other hand, approaches that mark shim data
packets (like the Extension Header or the Flow Label with new Next
Header values approaches) allow the receiver to detect if the context
associated to the received packet is missing. In this case, data
packets also perform the function of a context loss detection
exchange. However, it must be noted that only those packets that
carry a locator that differs form the ULID are marked. This
basically means that context loss will be detected after an outage
has occurred i.e. alternative locators are being used.
Summarizing, the proposed context loss detection mechanisms uses shim
control packets and payload packets to detect context loss. Shim
control packets detect context loss during the whole lifetime of the
context, but the expected frequency in some cases is very low. On
the other hand, payload packets have a higher expected frequency in
general, but they only detect context loss after an outage. This
behavior implies that it will be common that context loss is detected
after a failure i.e. once that it is actually needed. Because of
that, a mechanism for recovering from context loss is required if
this approach is used.
Overall, the mechanism for detecting lost context would work as
follows: the end that still has the context available sends a message
referring to the context. Upon the reception of such message, the
end that has lost the context identifies the situation and notifies
the context loss event to the other end by sending a packet
containing the lost context information extracted from the received
packet.
One option is to simply send an error message containing the received
packets (or at least as much of the received packet that the MTU
allows to fit in). One of the goals of this notification is to allow
the other end that still retains context state, to reestablish the
lost context. The mechanism to reestablish the loss context consists
in performing the 4-way initial handshake. This is a time consuming
exchange and at this point time may be critical since we are
reestablishing a context that is currently needed (because context
loss detection may occur after a failure). So, another option is to
replace the error message by a modified R1 message, so that the time
required to perform the context establishment exchange can be
reduced. Upon the reception of this modified R1 message, the end
that still has the context state can finish the context establishment
exchange and restore the lost context.
Appendix A.4 Securing locator sets
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
of redirection attacks as described in [17]. The goal in terms of
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
provide additional protection than the currently available in the
single-homed IPv6 Internet.
Multiple security mechanisms were considered to protect the shim
protocol. In this appendix we will present some of them.
The simplest option to protect the shim protocol was to use cookies
i.e. a randomly generated bit string that is negotiated during the
context establishment phase and then it is included in following
signaling messages. By this mean, it would be possible to verify
that the party that was involved in the initial handshake is the same
party that is introducing new locators. Moreover, before using a new
locator, an exchange is performed through the new locator, verifying
that the party located at the new locator knows the cookie i.e. that
it is the same party that performed the initial handshake.
While this security mechanisms does indeed provide a fair amount of
protection, it does leave the door open for the so-called time
shifted attacks. In these attacks, an attacker that once was on the
path, it discovers the cookie by sniffing any signaling message.
After that, the attacker can leave the path and still perform a
redirection attack, since as he is in possession of the cookie, he
can introduce a new locator in the locator set and he can also
successfully perform the reachability exchange if he is able to
receive packets at the new locator. The difference with the current
single-homed IPv6 situation is that in the current situation the
attacker needs to be on-path during the whole lifetime of the attack,
while in this new situation where only cookie protection if provided,
an attacker that once was on the path can perform attacks after he
has left the on-path location.
Moreover, because the cookie is included in signaling messages, the
attacker can discover the cookie by sniffing any of them, making the
protocol vulnerable during the whole lifetime of the shim context. A
possible approach to increase the security was to use a shared secret
i.e. a bit string that is negotiated during the initial handshake but
that is used as a key to protect following messages. With this
technique, the attacker must be present on the path sniffing packets
during the initial handshake, since it is the only moment where the
shared secret is exchanged. While this improves the security, it is
still vulnerable to time shifted attacks, even though it imposes that
the attacker must be on path at a very specific moment (the
establishment phase) to actually be able to launch the attack. While
this seems to substantially improve the situation, it should be noted
that, depending on protocol details, an attacker may be able to force
the recreation of the initial handshake (for instance by blocking
messages and making the parties think that the context has been
lost), so the resulting situation may not differ that much from the
cookie based approach.
Another option that was discussed during the design of the protocol
was the possibility of using IPSec for protecting the shim protocol.
Now, the problem under consideration in this scenario is how to
securely bind an address that is being used as ULID with a locator
set that can be used to exchange packets. The mechanism provided by
IPSec to securely bind the address used with the cryptographic keys
is the usage of digital certificates. This implies that an IPSec
based solution would require that the generation of digital
certificates that bind the key and the ULID by a common third trusted
party for both parties involved in the communication. Considering
that the scope of application of the shim protocol is global, this
would imply a global public key infrastructure. The major issues
with this approach are the deployment difficulties associated with a
global PKI.
Finally two different technologies were selected to protect the shim
protocol: HBA [6] and CGA [5]. These two approaches provide a
similar level of protection but they provide different functionality
with a different computational cost.
The HBA mechanism relies on the capability of generating all the
addresses of a multihomed host as an unalterable set of intrinsically
bound IPv6 addresses, known as an HBA set. In this approach,
addresses incorporate a cryptographic one-way hash of the prefix-set
available into the interface identifier part. The result is that the
binding between all the available addresses is encoded within the
addresses themselves, providing hijacking protection. Any peer using
the shim protocol node can efficiently verify that the alternative
addresses proposed for continuing the communication are bound to the
initial address through a simple hash calculation. A limitation of
the HBA technique is that once generated the address set is fixed and
cannot be changed without also changing all the addresses of the HBA
set. In other words, the HBA technique does not support dynamic
addition of address to a previously generated HBA set. An advantage
of this approach is that it requires only hash operations to verify a
locator set, imposing very low computational cost to the protocol.
In a CGA based approach the address used as ULID is a CGA that
contains a hash of a public key in its interface identifier. The
result is a secure binding between the ULID and the associated key
pair. This allows each peer to use the corresponding private key to
sign the shim messages that convey locator set information. The
trust chain in this case is the following: the ULID used for the
communication is securely bound to the key pair because it contains
the hash of the public key, and the locator set is bound to the
public key through the signature. The CGA approach then supports
dynamic addition of new locators in the locator set, since in order
to do that, the node only needs to sign the new locator with the
private key associated with the CGA used as ULID. A limitation of
this approach is that it imposes systematic usage of public key
cryptography with its associate computational cost.
Any of these two mechanisms HBA and CGA provide time-shifted attack
protection, since the ULID is securely bound to a locator set that
can only be defined by the owner of the ULID.
So, the design decision adopted was that both mechanisms HBA and CGA
are supported, so that when only stable address sets are required,
the nodes can benefit from the low computational cost offered by HBA
while when dynamic locator sets are required, this can be achieved
through CGAs with an additional cost. Moreover, because HBAs are
defined as a CGA extension, the addresses available in a node can
simultaneously be CGAs and HBAs, allowing the usage of the HBA and
CGA functionality when needed without requiring a change in the
addresses used.
Appendix A.5 Host-pair context establishment exchange
Two options were considered for the host-pair context establishment
exchange: a 2-way handshake and a 4-way handshake.
A key goal for the design of this exchange was that protection
against DoS attacks. The attack under consideration was basically a
situation where an attacker launches a great amount of host-pair
establishment request packets, exhausting victim's resources, similar
to TCP SYN flooding attacks.
A 4 way-handshake exchange protects against these attacks because the
receiver does not creates any state associate to a given context
until the reception of the second packet which contains a prior
contact proof in the form of a token. At this point the receiver can
verify that at least the address used by the initiator is at some
extent valid, since the initiator is able to receive packets at this
address. In the worse case, the responder can track down the
attacker using this address. The drawback of this approach is that
it imposes a 4 packet exchange for any context establishment. This
would be a great deal if the shim context needed to be established up
front, before the communication can proceed. However, thanks to
deferred context establishment capability of the shim protocol, this
limitation has a reduced impact in the performance of the protocol.
(It may however have a greater impact in the situation of context
recover as discussed earlier, but in this case, it is possible to
perform optimizations to reduce the number of packets as described
above)
The other option considered was a 2-way handshake with the
possibility to fall back to a 4-way handshake in case of attack. In
this approach, the host pair establishment exchange normally consists
in a 2-packet exchange and it does not verify that the initiator has
performed a prior contact before creating context state. In case
that a DoS attack is detected, the responder falls back to a 4-way
handshake similar to the one described previously in order to prevent
the detected attack to proceed. The main difficulty with this attack
is how to detect that a responder is currently under attack. It
should be noted, that because this is 2-way exchange, it is not
possible to use the number of half open sessions (as in TCP) to
detect an ongoing attack and different heuristics need to be
considered.
The design decision taken was that considering the current impact of
DoS attacks and the low impact of the 4-way exchange in the shim
protocol thanks to the deferred context establishment capability, a
4-way exchange would be adopted for the base protocol.
Appendix A.6 Updating locator sets
There are two possible approaches to the addition and removal of
locators: atomic and differential approaches. The atomic approach
essentially send the complete locators set each time that a variation
in the locator set occurs. The differential approach send the
differences between the existing locator set and the new one. The
atomic approach imposes additional overhead, since all the locator
set has to be exchanged each time while the differential approach
requires re-synchronization of both ends through changes i.e. that
both ends have the same idea about what the current locator set is.
Because of the difficulties imposed by the synchronization
requirement, the atomic approach was selected.
Appendix A.7 State Cleanup
There are essentially two approaches for discarding an existing state
about locators, keys and identifiers of a correspondent node: a
coordinated approach and an unilateral approach.
In the unilateral approach, each node discards the information about
the other node without coordination with the other node based on some
local timers and heuristics. No packet exchange is required for
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,
a No-Context error message may be required to inform about the
situation and possibly a recovery mechanism is also needed.
A coordinated approach would use an explicit CLOSE mechanism, akin
to the one specified in HIP [23]. If an explicit CLOSE handshake and
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
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
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
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
message.
24. References
24.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998. Specification", RFC 2460, December 1998.
[3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998. for IP Version 6 (IPv6)", RFC 2461, December 1998.
[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] Bagnulo, M., "Hash Based Addresses (HBA)", [5] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[6] Bagnulo, M., "Hash Based Addresses (HBA)",
draft-ietf-shim6-hba-00 (work in progress), July 2005. draft-ietf-shim6-hba-00 (work in progress), July 2005.
[6] Beijnum, I., "Shim6 Reachability Detection", [7] Beijnum, I., "Shim6 Reachability Detection",
draft-ietf-shim6-reach-detect-00 (work in progress), July 2005. draft-ietf-shim6-reach-detect-00 (work in progress), July 2005.
[7] Arkko, J., "Failure Detection and Locator Pair Exploration [8] Arkko, J., "Failure Detection and Locator Pair Exploration
Design for IPv6 Multihoming", Design for IPv6 Multihoming",
draft-ietf-shim6-failure-detection-01 (work in progress), draft-ietf-shim6-failure-detection-01 (work in progress),
October 2005. October 2005.
23.2 Informative References 24.2 Informative References
[8] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [9] 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.
[9] Ferguson, P. and D. Senie, "Network Ingress Filtering: [10] 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.
[10] Narten, T. and R. Draves, "Privacy Extensions for Stateless [11] 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.
[11] Draves, R., "Default Address Selection for Internet Protocol [12] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003. version 6 (IPv6)", RFC 3484, February 2003.
[12] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [13] 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.
[13] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- [14] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-
Multihoming Architectures", RFC 3582, August 2003. Multihoming Architectures", RFC 3582, August 2003.
[14] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 [15] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6
Flow Label Specification", RFC 3697, March 2004. Flow Label Specification", RFC 3697, March 2004.
[15] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [16] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[16] Nordmark, E., "Threats relating to IPv6 multihoming solutions", [17] Nordmark, E., "Threats relating to IPv6 multihoming solutions",
draft-ietf-multi6-multihoming-threats-03 (work in progress), draft-ietf-multi6-multihoming-threats-03 (work in progress),
January 2005. January 2005.
[17] Nordmark, E., "Shim6 Application Referral Issues", [18] Nordmark, E., "Shim6 Application Referral Issues",
draft-ietf-shim6-app-refer-00 (work in progress), July 2005. draft-ietf-shim6-app-refer-00 (work in progress), July 2005.
[18] Abley, J., "Shim6 Applicability Statement", [19] Abley, J., "Shim6 Applicability Statement",
draft-ietf-shim6-applicability-00 (work in progress), draft-ietf-shim6-applicability-00 (work in progress),
July 2005. July 2005.
[19] Huston, G., "Architectural Commentary on Site Multi-homing [20] 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.
[20] Bagnulo, M. and J. Arkko, "Functional decomposition of the [21] Bagnulo, M. and J. Arkko, "Functional decomposition of the
multihoming protocol", draft-ietf-shim6-functional-dec-00 (work multihoming protocol", draft-ietf-shim6-functional-dec-00 (work
in progress), July 2005. in progress), July 2005.
[21] Nordmark, E. and M. Bagnulo, "Multihoming L3 Shim Approach", [22] Nordmark, E. and M. Bagnulo, "Multihoming L3 Shim Approach",
draft-ietf-shim6-l3shim-00 (work in progress), July 2005. draft-ietf-shim6-l3shim-00 (work in progress), July 2005.
[22] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-03 [23] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-03
(work in progress), June 2005. (work in progress), June 2005.
[23] Lear, E. and R. Droms, "What's In A Name:Thoughts from the [24] Lear, E. and R. Droms, "What's In A Name:Thoughts from the
NSRG", draft-irtf-nsrg-report-10 (work in progress), NSRG", draft-irtf-nsrg-report-10 (work in progress),
September 2003. September 2003.
Author's Address Author's Address
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. 151 change blocks. 
354 lines changed or deleted 952 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/