draft-ietf-shim6-failure-detection-03.txt   faildet.txt 
Network Working Group J. Arkko Network Working Group J. Arkko
Internet-Draft Ericsson Internet-Draft Ericsson
Expires: June 24, 2006 I. Beijnum Intended status: Informational I. Beijnum
Muada Expires: December 25, 2006 Muada
December 21, 2005 June 23, 2006
Failure Detection and Locator Pair Exploration Protocol for IPv6 Failure Detection and Locator Pair Exploration Protocol for IPv6
Multihoming Multihoming
draft-ietf-shim6-failure-detection-03 draft-ietf-shim6-failure-detection-04
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 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 24, 2006. This Internet-Draft will expire on December 25, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document defines a mechanism for the detection of communication This document specifies how the level 3 multihoming shim protocol
failures between two communicating hosts at IP layer, and an (SHIM6) detects failures between two communicating hosts. It also
exploration protocol for switching to another pair of interfaces specifies an exploration protocol for switching to another pair of
and/or addresses between the same hosts if a working pair can be interfaces and/or addresses between the same hosts if a failure
found. The draft also discusses the roles of a multihoming protocol occurs and a working pair can be found.
versus network attachment functions at IP and link layers.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements language . . . . . . . . . . . . . . . . . . . . 4
3. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Available Addresses . . . . . . . . . . . . . . . . . . 7 4.1. Available Addresses . . . . . . . . . . . . . . . . . . 7
4.2. Locally Operational Addresses . . . . . . . . . . . . . 7 4.2. Locally Operational Addresses . . . . . . . . . . . . . 8
4.3. Operational Address Pairs . . . . . . . . . . . . . . . 8 4.3. Operational Address Pairs . . . . . . . . . . . . . . . 8
4.4. Current Address Pair . . . . . . . . . . . . . . . . . . 9 4.4. Current Address Pair . . . . . . . . . . . . . . . . . . 10
4.5. Miscellaneous . . . . . . . . . . . . . . . . . . . . . 10
5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Failure Detection . . . . . . . . . . . . . . . . . . . 11 5.1. Failure Detection . . . . . . . . . . . . . . . . . . . 11
5.2. Alternative Address Pair Exploration . . . . . . . . . . 13 5.2. Alternative Address Pair Exploration . . . . . . . . . . 12
5.3. Exploration Order . . . . . . . . . . . . . . . . . . . 14 5.3. Exploration Order . . . . . . . . . . . . . . . . . . . 13
5.4. Protocol Design . . . . . . . . . . . . . . . . . . . . 14 5.4. Protocol Design . . . . . . . . . . . . . . . . . . . . 14
5.5. Example Protocol Runs . . . . . . . . . . . . . . . . . 15 5.5. Example Protocol Runs . . . . . . . . . . . . . . . . . 15
5.6. Limitations . . . . . . . . . . . . . . . . . . . . . . 21 5.6. Limitations . . . . . . . . . . . . . . . . . . . . . . 21
6. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 22 6. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 22
6.1. Keepalive Message . . . . . . . . . . . . . . . . . . . 22 6.1. Keepalive Message . . . . . . . . . . . . . . . . . . . 22
6.1.1. Keepalive Option . . . . . . . . . . . . . . . . 23 6.1.1. Keepalive Option . . . . . . . . . . . . . . . . 23
6.2. Probe Message . . . . . . . . . . . . . . . . . . . . . 24 6.2. Probe Message . . . . . . . . . . . . . . . . . . . . . 24
6.2.1. Probe Option . . . . . . . . . . . . . . . . . . 25 6.2.1. Probe Option . . . . . . . . . . . . . . . . . . 26
6.3. Reachability Option . . . . . . . . . . . . . . . . . . 26 6.3. Reachability Option . . . . . . . . . . . . . . . . . . 27
6.3.1. Payload Reception Report . . . . . . . . . . . . 27 6.3.1. Payload Reception Report . . . . . . . . . . . . 28
6.3.2. Probe Reception Report . . . . . . . . . . . . . 28 6.3.2. Probe Reception Report . . . . . . . . . . . . . 28
6.4. Behaviour . . . . . . . . . . . . . . . . . . . . . . . 29 6.4. Behaviour . . . . . . . . . . . . . . . . . . . . . . . 29
6.5. Protocol Constants . . . . . . . . . . . . . . . . . . . 33 6.5. Protocol Constants . . . . . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.1. Normative References . . . . . . . . . . . . . . . . . . 37 9.1. Normative References . . . . . . . . . . . . . . . . . . 37
9.2. Informative References . . . . . . . . . . . . . . . . . 37 9.2. Informative References . . . . . . . . . . . . . . . . . 37
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 39 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 40
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 40 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . . . . . 42 Intellectual Property and Copyright Statements . . . . . . . . . . 43
1. Introduction 1. Introduction
The SHIM6 protocol extends IPv6 to support multihoming. This The SHIM6 protocol [I-D.ietf-shim6-proto] extends IPv6 to support
protocol is an IP layer mechanism that hides multihoming from multihoming. It is an IP layer mechanism that hides multihoming from
applications [18]. A part of the SHIM6 solution involves detecting applications. A part of the SHIM6 solution involves detecting when a
when a currently used pair of addresses (or interfaces) between two currently used pair of addresses (or interfaces) between two
communication hosts has failed, and picking another pair when this communication hosts has failed, and picking another pair when this
occurs. We call the former failure detection, and the latter locator occurs. We call the former failure detection, and the latter locator
pair exploration. pair exploration.
This draft defines the mechanism and protocol to achieve both failure This document specifies the mechanisms and protocol messages to
detection and locator pair exploration. This protocol is called achieve both failure detection and locator pair exploration. This
REAchability Protocol (REAP). It designed to be carried within the part of the SHIM6 protocol is called the REAchability Protocol
SHIM6 protocol, but may also be used in other contexts. (REAP).
The draft is structured as follows: Section 3 discusses prior work in The document is structured as follows: Section 3 discusses related
this space, Section 4 defines a set of useful terms, Section 5 gives work in this space, Section 4 defines a set of useful terms,
an overview of REAP, and Section 6 specifies the message formats and Section 5 gives an overview of REAP, and Section 6 specifies the
behaviour in detail. Section 7 discusses the security considerations message formats and behaviour in detail. Section 7 discusses the
of REAP. security considerations of REAP.
For the purposes of this draft, we consider an address to be In this specification, we consider an address to be synonymous with a
synonymous with a locator. We assume that there are other, higher locator. Other parts of the SHIM6 protocol ensure that the different
level identifiers such as CGA public keys or HBA bindings that tie locators used by a node actually belong together. That is, REAP is
the different locators used by a node together [17]. not responsible for ensuring that it ends up with a legitimate
locator.
2. Requirements language 2. Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
described in [2]. document are to be interpreted as described in [RFC2119].
3. Related Work 3. Related Work
In SCTP [10], the addresses of the endpoints are learned in the In SCTP [RFC2960], transport addresses (IP address and port pairs)
connection setup phase either through listing them explicitly or via are exchanged during SCTP Association (i.e. connection) setup phase.
giving a DNS name that points to them. In order to provide a In order to provide a failover mechanism between multihomed hosts,
failover mechanism between multihomed hosts, SCTP selects one of the one of the peer's addresses is selected as the primary address by the
peer's addresses as the primary address by the application running on application running on top of SCTP. All data packets are sent to
top of SCTP. All data packets are sent to this address until there this address until there is a reason to choose another address, such
is a reason to choose another address, such as the failure of the as the failure of the primary address.
primary address.
SCTP also tests the reachability of the peer endpoint's addresses. SCTP also tests the reachability of the peer endpoint's addresses.
This is done both via observing the data packets sent to the peer or This is done both via observing the data packets sent to the peer or
via a periodic heartbeat when there is no data packets to send. Each via a periodic heartbeat when there is no data packets to send. Each
time data packet retransmission is initiated (or when a heartbeat is time data packet retransmission is initiated (or when a heartbeat is
not answered within the estimated round-trip time) an error counter not answered within the estimated round-trip time) an error counter
is incremented. When a configured error limit is reached, the is incremented. When a configured error limit is reached, the
particular destination address is marked as inactive. The reception particular destination address is marked as inactive. The reception
of an acknowledgement or heartbeat response clears the counter. of an acknowledgement or heartbeat response clears the counter. When
Retransmission: When retransmitting the endpoint attempts pick the retransmitting the endpoint attempts pick the most "divergent"
most "divergent" source-destination pair from the original source- source-destination pair from the original source-destination pair to
destination pair to which the packet was transmitted. Rules for such which the packet was transmitted. Rules for such selection are,
selection are, however, left as implementation decisions in SCTP. however, left as implementation decisions in SCTP.
SCTP does not define how local knowledge (such as information learned SCTP does not define how local knowledge (such as information learned
from the link layer) should be used. SCTP also has no mechanism to from the link layer) should be used. A mechanism, dynamic address
deal with dynamic changes to the set of available addresses, although reconfiguration mechanism [I-D.ietf-tsvwg-addip-sctp], is being
mechanisms for that are being developed [20]. developed to deal with dynamic changes to the set of available
addresses.
The MOBIKE protocol [15] provides multihoming and mobility for VPN The MOBIKE protocol [RFC4555] provides multihoming and mobility for
connections. Its failure detection and locator pair exploration is VPN connections. Its failure detection and locator pair exploration
designed to work across mixed IPv4/IPv6 environments and NATs, as is designed to work across mixed IPv4/IPv6 environments and NATs, as
long as a path that allows bidirectional communication can be found. long as a path that allows bidirectional communication can be found.
Existing mechanisms at lower layers or in IKEv2 are used to detect Existing mechanisms at lower layers or in IKEv2 are used to detect
failures, and upon failure MOBIKE attempts to explore all failures, and upon failure MOBIKE attempts to explore all
combinations of addresses to find a working pair. Such exploration combinations of addresses to find a working pair. Such exploration
is necessary when a problem affects both nodes. For instance, two is necessary when a problem affects both nodes. For instance, two
nodes connected by two separate point-to-point links will be unable nodes connected by two separate point-to-point links will be unable
to switch to the other link if a failure occurs on the first one. to switch to the other link if a failure occurs on the first one.
While both communicating hosts are aware of each others' addresses, While both communicating hosts are aware of each others' addresses,
only one end of the communication is in charge of deciding what only one end of the communication is in charge of deciding what
address pair to use, however. address pair to use, however.
The mobility and multihoming specification for the HIP protocol [14] The mobility and multihoming specification for the HIP protocol
leaves the determination of when address updates are sent to a local [I-D.ietf-hip-mm] leaves the determination of when address updates
policy, but suggests the use of local information and ICMP error are sent to a local policy, but suggests the use of local information
messages. and ICMP error messages.
Network attachment procedures are also relevant for multihoming. The Network attachment procedures are also relevant for multihoming. The
IPv6 and MIP6 working groups have standardized mechanisms to learn IPv6 and MIP6 working groups have standardized mechanisms to learn
about networks that a node has attached to. Basic IPv6 Neighbor about networks that a node has attached to. Basic IPv6 Neighbor
Discovery was, however, designed primarily for static situations. Discovery was, however, designed primarily for static situations.
The fully dynamic detection procedure has turned out to be a The fully dynamic detection procedure has turned out to be a
relatively complex procedure for mobile hosts, and it was not fully relatively complex procedure for mobile hosts. Enhanced or optimized
anticipated at the time IPv6 Neighbor Discovery or DHCP were being mechanisms are being designed in the DHC and DNA working groups DNAv4
designed. As a result, enhanced or optimized mechanisms are being [RFC4436], CPL [I-D.ietf-dna-cpl], and DNAv6 [I-D.ietf-dna-protocol].
designed in the DHC and DNA working groups [13] [7].
ICE [16], STUN [11], and TURN [24] are also related mechanisms. They ICE [I-D.ietf-mmusic-ice], STUN [RFC3489], and TURN
are primarily used for NAT detection and communication through NATs [I-D.rosenberg-midcom-turn] are also related mechanisms. They are
in IPv4 environment, for application such as as voice over IP. STUN primarily used for NAT detection and communication through NATs in
IPv4 environment, for application such as as voice over IP. STUN
uses a server in the Internet to discover the presence and type of uses a server in the Internet to discover the presence and type of
NATs and the client's public IP addresses and ports. TURN makes it NATs and the client's public IP addresses and ports. TURN makes it
possible to receive incoming connections in hosts behind NATs. ICE possible to receive incoming connections in hosts behind NATs. ICE
makes use of these protocols in peer-to-peer cooperative fashion, makes use of these protocols in peer-to-peer cooperative fashion,
allowing participants to discover, create and verify mutual allowing participants to discover, create and verify mutual
connectivity, and then use this connectivity for multimedia streams. connectivity, and then use this connectivity for multimedia streams.
While these mechanisms are not designed for dynamic and failure While these mechanisms are not designed for dynamic and failure
situations, they have many of the same requirements for the situations, they have many of the same requirements for the
exploration of connectivity, as well as the requirement to deal with exploration of connectivity, as well as the requirement to deal with
middleboxes. middleboxes.
Related work in the IPv6 area includes RFC 3484 [6] which defines Related work in the IPv6 area includes RFC 3484 [RFC3484] which
source and destination address selection rules for IPv6 in situations defines source and destination address selection rules for IPv6 in
where multiple candidate address pairs exist. RFC 3484 considers situations where multiple candidate address pairs exist. RFC 3484
only a static situation, however, and does not take into account the considers only a static situation, however, and does not take into
effect of failures. Reference [23] considers how applications can account the effect of failures.
re-initiate connections after failures in the best way. This work
differs from the shim-layer approach selected for further development
in the working group with respect to the timing of the address
selection. In the shim-layer approach failure detection and the
selection of new addresses happens at any time, while [23] considers
only the case when an application re-establishes connections.
An earlier SHIM6 document [19] discussed what kind of mechanisms can An earlier SHIM6 document [I-D.ietf-shim6-reach-detect] analyzed what
be used to detect whether the peer is still reachable at the kind of mechanisms can be used to detect whether the peer is still
currently used address. Two proposed mechanisms, Correspondent reachable at the currently used address. Two proposed mechanisms,
Unreachability Detection (CUD) and Forced Bidirectional Communication Correspondent Unreachability Detection (CUD) and Forced Bidirectional
(FBD) were presented. CUD is based on getting upper layer positive Communication (FBD) were presented. CUD is based on getting upper
feedback, and IPv6 NUD-like probing if there is no feedback. FBD is layer positive feedback, and IPv6 NUD-like probing if there is no
based on forcing bidirectional communication by adding keepalive feedback. FBD is based on forcing bidirectional communication by
messages when there is no other, payload traffic. FBD is the chosen adding keepalive messages when there is no other, payload traffic.
mechanism in this document. FBD is the chosen mechanism in this document.
Many other protocols, both standardized in the IETF and outside of
the IETF make use of keepalives to track the liveness of a connection
or session.
4. Definitions 4. Definitions
This section defines terms useful in discussing the problem space. This section defines terms useful for discussing failure detection
and locator pair exploration.
4.1. Available Addresses 4.1. Available Addresses
Multihoming nodes need to be aware of what addresses they themselves SHIM6 nodes need to be aware of what addresses they themselves have.
have. If a node loses the address it is currently using for If a node loses the address it is currently using for communications,
communications, another address must replace this address. And if a another address must replace this address. And if a node loses an
node loses an address that the node's peer knows about, the peer must address that the node's peer knows about, the peer must be informed.
be informed. Similarly, when a node acquires a new address it may Similarly, when a node acquires a new address it may generally wish
generally wish the peer to know about it. the peer to know about it.
Definition. Available address. An address is said to be available Definition. Available address. An address is said to be available
if the following conditions are fulfilled: if the following conditions are fulfilled:
o The address has been assigned to an interface of the node. o The address has been assigned to an interface of the node.
o If the address is an IPv6 address, we additionally require that o The address is valid in the sense of RFC 2461 [RFC2461].
(a) the address is valid in the sense of RFC 2461 [3], and that
(b) the address is not tentative in the sense of RFC 2462 [4]. In o The address is not tentative in the sense of RFC 2462 [RFC2462].
other words, the address assignment is complete so that In other words, the address assignment is complete so that
communications can be started. communications can be started.
Note that this explicitly allows an address to be optimistic in Note that this explicitly allows an address to be optimistic in
the sense of [8] even though implementations are probably better the sense of Optimistic DAD [RFC4429] even though implementations
off using other addresses as long as there is an alternative. may prefer using other addresses as long as there is an
alternative.
o The address is a global unicast, unique local address [9], or an o The address is a global unicast, unique local address [RFC4193],
unambiguous IPv6 link-local address. That is, it is not an IPv6 or an unambiguous IPv6 link-local address. That is, it is not an
site-local address. Where IPv6 link-local addresses are used, IPv6 site-local address.
their use needs to be unambiguous as follows. At most one link-
local address may be used per node within the same connection Where IPv6 link-local addresses are used, their use needs to be
between two peers. unambiguous as follows. At most one link-local address may be
used per node within the same connection between two peers.
o The address and interface is acceptable for use according to a o The address and interface is acceptable for use according to a
local policy. local policy.
Available addresses are discovered and monitored through mechanisms Available addresses are discovered and monitored through mechanisms
outside the scope of the protocol described here. These mechanisms outside the scope of SHIM6. These mechanisms include IPv6 Neighbor
include IPv6 Neighbor Discovery and Address Autoconfiguration [3] Discovery [RFC2461] and Address Autoconfiguration [RFC2462], and DHCP
[4], DHCP [5], and DNA mechanisms [7]. [RFC3315].
4.2. Locally Operational Addresses 4.2. Locally Operational Addresses
Two different granularity levels are needed for failure detection. Two different granularity levels are needed for failure detection.
The coarser granularity is for individual addresses: The coarser granularity is for individual addresses:
Definition. Locally Operational Address. An available address is Definition. Locally Operational Address. An available address is
said to be locally operational when its use is known to be possible said to be locally operational when its use is known to be possible
locally: the interface is up, at least one default router (if locally: the interface is up, a default router (if needed) suitable
applicable) that could be used to send a packet with this address as for this address is known to be reachable, and no other local
a source address is known to be reachable, and no other local
information points to the address being unusable. information points to the address being unusable.
Locally operational addresses are discovered and monitored through Locally operational addresses are discovered and monitored through
mechanisms outside the protocol described here. These mechanisms mechanisms outside the SHIM6 protocol. These mechanisms include
include IPv6 Neighbor Discovery [3] and link layer specific Neighbor Unreachability Detection [RFC2461], and link layer specific
mechanisms. mechanisms.
It is also possible for hosts to learn about routing failures for a Note 1: A part of the problem in ensuring that an address is
particular selected source prefix, if suitable protocols for this operational is making sure that after a change in link layer
purpose exist. Some proposals in this space have been made, see, for connectivity we are still connected to the same IP subnet.
instance [21] and [23]. Potential approaches include overloading Mechanisms such as DNA CPL [I-D.ietf-dna-cpl] or DNAv6
information in current IPv6 Router Advertisement or adding some new [I-D.ietf-dna-protocol] can be used to ensure this.
information in them. Similarly, hosts could learn information from
servers that query the BGP routing tables. Note 2: It is also possible for hosts to learn about routing
failures for a particular selected source prefix, if suitable
protocols for this purpose exist. Some proposals in this space
have been made, see, for instance
[I-D.bagnulo-shim6-addr-selection] and
[I-D.huitema-multi6-addr-selection], but none have been
standardized to date.
4.3. Operational Address Pairs 4.3. Operational Address Pairs
The existence of locally operational addresses are not, however, a The existence of locally operational addresses are not, however, a
guarantee that communications can be established with the peer. A guarantee that communications can be established with the peer. A
failure in the routing infrastructure can prevent the sent packets failure in the routing infrastructure can prevent packets from
from reaching their destination. For this reason we need the reaching their destination. For this reason we need the definition
definition of a second level of granularity, for pairs of addresses: of a second level of granularity, for pairs of addresses:
Definition. Bidirectionally operational address pair. A pair of Definition. Bidirectionally operational address pair. A pair of
locally operational addresses are said to be an operational address locally operational addresses are said to be an operational address
pair, iff bidirectional connectivity can be shown between the pair, iff bidirectional connectivity can be shown between the
addresses. That is, a packet sent with one of the addresses in the addresses. That is, a packet sent with one of the addresses in the
source field and the other in the destination field reaches the source field and the other in the destination field reaches the
destination, and vice versa. destination, and vice versa.
Unfortunately, there are scenarios where bidirectionally operational Unfortunately, there are scenarios where bidirectionally operational
address pairs do not exist. For instance, ingress filtering or address pairs do not exist. For instance, ingress filtering or
network failures may result in one address pair being operational in network failures may result in one address pair being operational in
one direction while another one is operational from the other one direction while another one is operational from the other
direction. The following definition captures this general situation: direction. The following definition captures this general situation:
Definition. Undirectionally operational address pair. A pair of Definition. Unidirectionally operational address pair. A pair of
locally operational addresses are said to be an unidirectionally locally operational addresses are said to be an unidirectionally
operational address pair, iff packets sent with the first address as operational address pair, iff packets sent with the first address as
the source and the second address as the destination can be shown to the source and the second address as the destination can be shown to
reach the destination. reach the destination.
Both types of operational pairs could be discovered and monitored Operational address pairs are discovered through the following means:
through the following mechanisms:
o Positive feedback from upper layer protocols. For instance, TCP o Positive feedback from upper layer protocols. For instance, TCP
can indicate to the IP layer that it is making progress. This is can indicate to the IP layer that it is making progress. This is
similar to how IPv6 Neighbor Unreachability Detection can in some similar to how IPv6 Neighbor Unreachability Detection can in some
cases be avoided when upper layers provide information about cases be avoided when upper layers provide information about
bidirectional connectivity [3]. In the case of unidirectional bidirectional connectivity [RFC2461].
connectivity, the upper layer protocol responses come back using
another address pair, but show that the messages sent using the In the case of unidirectional connectivity, the upper layer
first address pair have been received. protocol responses come back using another address pair, but show
that the messages sent using the first address pair have been
received.
o Negative feedback from upper layer protocols. It is conceivable o Negative feedback from upper layer protocols. It is conceivable
that upper layer protocols give an indication of a problem to the that upper layer protocols give an indication of a problem to the
multihoming layer. For instance, TCP could indicate that there's multihoming layer. For instance, TCP could indicate that there's
either congestion or lack of connectivity in the path because it either congestion or lack of connectivity in the path because it
is not getting ACKs. is not getting ACKs.
o Explicit reachability tests, such as keepalives or probes added o Explicit reachability tests, described later in this
when there's only unidirectional payload traffic. specification.
o ICMP error messages. Given the ease of spoofing ICMP messages, o ICMP error messages. Given the ease of spoofing ICMP messages,
one should be careful to not trust these blindly, however. Our one should be careful to not trust these blindly, however. Our
suggestion is to use ICMP error messages only as a hint to perform suggestion is to use ICMP error messages only as a hint to perform
an explicit reachability test, but not as a reason to disrupt an explicit reachability test, but not as a reason to disrupt
ongoing communications without other indications of problems. The ongoing communications without other indications of problems. The
situation may be different when certain verifications of the ICMP situation may be different when certain verifications of the ICMP
messages are being performed [22]. These verifications can ensure messages are being performed, as explained by Gont in
that (practically) only on-path attackers can spoof the messages. [I-D.ietf-tcpm-icmp-attacks]. These verifications can ensure that
(practically) only on-path attackers can spoof the messages.
Note a multihoming protocol needs to perform a return routability Note SHIM6 needs to perform a return routability test of an address
test of an address before it is taken into use. The purpose of this before it is taken into use. The purpose of this test is to ensure
test is to ensure that fraudulent peers do not trick others into that fraudulent peers do not trick others into redirecting traffic
redirecting traffic streams onto innocent victims [25]. This test streams onto innocent victims. For a discussion of such attacks, see
can at the same time work as a means to ensure that an address pair Aura et al [AURA02]. The test can at the same time work as a means
is operational, as discussed in Section 5.2. to ensure that an address pair is operational, as discussed in
Section 5.2.
4.4. Current Address Pair 4.4. Current Address Pair
IP-layer solutions need to avoid sending packets concurrently over SHIM6 needs to avoid sending packets concurrently over multiple
multiple paths; TCP behaves rather poorly in such circumstances. For paths, because congestion control in commonly used transport
this reason it is necessary to choose a particular pair of addresses protocols is based upon a notion of a single path. While routing can
as the current address pair which is used until problems occur, at introduce path changes as well and transport protocols have means to
least for the same session. deal with this, frequent changes will cause problems. Efficient
congestion control over multible paths is a considered research at
the time this specification is written.
For these reasons it is necessary to choose a particular pair of
addresses as the current address pair which is used until problems
occur, at least for the same session.
A current address pair need not be operational at all times. If A current address pair need not be operational at all times. If
there is no traffic to send, we may not know if the primary address there is no traffic to send, we may not know if the primary address
pair is operational. Nevertheless, it makes sense to assume that the pair is operational. Nevertheless, it makes sense to assume that the
address pair that worked in some time ago continues to work for new address pair that worked in some time ago continues to work for new
communications as well. communications as well.
4.5. Miscellaneous
Addresses can become deprecated [3]. When other operational
addresses exist, nodes generally wish to move their communications
away from the deprecated addresses.
Similarly, IPv6 source address selection [6] may guide the selection
of a particular source address - destination address pair.
5. Protocol Overview 5. Protocol Overview
This section discusses the design of the reachability detection and This section discusses the design of the reachability detection and
address pair exploration mechanisms, and gives on overview of the address pair exploration mechanisms, and gives on overview of the
REAP protocol. REAP protocol.
A naive implementation of an (un)reachability detection mechanism
could just probe all possible paths between two hosts periodically.
A "path" is defined as a combination of a source address for host A
and a destination address for host B. In hop-by-hop forwarding the
source address has no effect on reachability, but in the presence of
filters or source address based routing, it may. And although links
almost always work in two directions, routing protocols and filters
only work in one direction so unidirectional reachability is
possible. Without additional mechanisms, the practice of ingress
filtering by ISPs makes unidirectional connectivity likely. Being
able to use the working leg in a unidirectional path is useful, it's
not an essential requirement. It is essential, however, to avoid
assuming bidirectional connectivity when there is in fact a
unidirectional failure.
Exploring the full set of communication options between two hosts Exploring the full set of communication options between two hosts
that both have two or more addresses is an expensive operation as the that both have two or more addresses is an expensive operation as the
number of combinations to be explored increases very quickly with the number of combinations to be explored increases very quickly with the
number of addresses. For instance, with two addresses on both sides, number of addresses. For instance, with two addresses on both sides,
there are four possible address pairs. Since we can't assume that there are four possible address pairs. Since we can't assume that
reachability in one direction automatically means reachability for reachability in one direction automatically means reachability for
the complement pair in the other direction, the total number of two- the complement pair in the other direction, the total number of two-
way combinations is eight. (Combinations = nA * nB * 2.) way combinations is eight. (Combinations = nA * nB * 2.)
An important observation in multihoming is that failures are An important observation in multihoming is that failures are
relatively infrequent, so that a path that worked a few seconds ago relatively infrequent, so that a path that worked a few seconds ago
is very likely to work now as well. So it makes sense to have a is very likely to work now as well. So it makes sense to have a
light-weight protocol that confirms existing reachability, and only light-weight protocol that confirms existing reachability, and only
invoke heavier exploration when a there is a suspected failure. invoke heavier exploration when a there is a suspected failure.
5.1. Failure Detection 5.1. Failure Detection
This process consists of three tasks. First, it is necessary to Failure detection consists of three parts: tracking local
track local information from lower and upper layers. For instance, information, tracking remote peer status, and finally verifying
when link layer informs that we have no connection then we know there reachability. Tracking local information consists of using, for
is a failure. Nodes SHOULD employ techniques listed in Section 4.1 instance, reachability information about the local router as an
and Section 4.2 to be aware of the local situation. input. Nodes SHOULD employ techniques listed in Section 4.1 and
Section 4.2 to be track the local situation. It is also necessary to
Similarly, it is necessary to track remote address information from track remote address information from the peer. For instance, if the
the peer. For instance, the peer may inform that its currently used peer's currently used address is no longer in use, mechanism to relay
address is no longer in use. Techniques outside the scope of this that information is needed. The Update message in the SHIM6 protocol
document are used for this, for further information see [18]. is used for this purpose [I-D.ietf-shim6-proto]. Finally, when the
local and remote information indicates that communication should be
The third task is to ensure verify reachability with the peer when possible and there are upper layer packets to be sent, reachability
the local and remote information indicates that communication should verification is necessary to ensure that there actually is a working
be possible. This needs to be performed only if there's upper layer path between the peers.
packets to be sent, however.
This document defines the protocol mechanisms only for the third A technique called Forced Bidirectional Detection (FBD) is employed
task. We employ a technique called Forced Bidirectional Detection for the reachability verification. Reachability for the currently
(FBD). Reachability for the currently used address pair in a shim used address pair in a shim context is determined by making sure that
context is determined by making sure that whenever there is data whenever there is data traffic in one direction, there is also
traffic in one direction, there is also traffic in the other traffic in the other direction. This can be data traffic as well,
direction. This can be data traffic as well, but also transport but also transport layer acknowledgments or a REAP reachability
layer acknowledgments or a REAP reachability keepalive if there is no keepalive if there is no other traffic. This way, it is no longer
other traffic. This way, it is no longer possible to have traffic in possible to have traffic in only one direction, so whenever there is
only one direction, so whenever there is data traffic going out, but data traffic going out, but there are no return packets, there must
there are no return packets, there must be a failure, so the full be a failure, so the full exploration mechanism is started.
path exploration mechanism is started.
A more detailed description of the current pair reachability A more detailed description of the current pair reachability
evaluation mechanism: evaluation mechanism:
1. The base timing unit for this mechanism is named Keepalive 1. The base timing unit for this mechanism is named Keepalive
Timeout. Until a negotiation mechanism to negotiate different Timeout. Until a negotiation mechanism to negotiate different
values for this timer becomes available, the value (3 seconds) values for this timer becomes available, the value (3 seconds)
specified in Section 6.5 SHOULD be used. specified in Section 6.5 SHOULD be used.
2. Whenever outgoing data packets are generated that are part of a 2. Whenever outgoing data packets are generated that are part of a
skipping to change at page 13, line 42 skipping to change at page 13, line 26
signaling messages. signaling messages.
Specifically, when A decides that it needs to explore for an Specifically, when A decides that it needs to explore for an
alternative address pair to B, it will initiate a set of Probe alternative address pair to B, it will initiate a set of Probe
messages, in sequence, until it gets an Probe message from B messages, in sequence, until it gets an Probe message from B
indicating that (a) B has received one of A's messages and, indicating that (a) B has received one of A's messages and,
obviously, (b) that B's Probe message gets back to A. B uses the same obviously, (b) that B's Probe message gets back to A. B uses the same
algorithm, but starts the process from the reception of the first algorithm, but starts the process from the reception of the first
Probe message from A. Probe message from A.
Upon changing to a new address pair, transport layer protocol needs Upon changing to a new address pair, the network path traversed most
to be informed so that it can perform a slow start, or some other likely has changed, so that the ULP SHOULD be informed. This can be
form of adaptation to the possibly changed conditions. However, this a signal for the ULP to adapt due to the change in path so that, for
functionality is outside the scope of REAP and is rather seen as a example, TCP could initiate a slow start procedure.
general multihoming issue.
Similarly, one can also envision that applications would be able to Similarly, one can also envision that applications would be able to
tell the IP or transport layer that the current connection in tell the IP or transport layer that the current connection in
unsatisfactory and an exploration for a better one would be unsatisfactory and an exploration for a better one would be
desirable. This would require an API to be developed, however. In desirable. This would require an API to be developed, however. In
any case, this is another issue that we treat as being outside the any case, this is another issue that we treat as being outside the
scope of pure address exploration. scope of pure address exploration.
5.3. Exploration Order 5.3. Exploration Order
The exploration process assumes an ability to pick current and The exploration process assumes an ability to choose address pairs
alternative address pairs. This process may result in a for testing, in some sequence. This process may result in a
combinatorial explosion when there are many addresses on both sides, combinatorial explosion when there are many addresses on both sides,
but a back-off procedure is employed to avoid a "signaling storm". but a back-off procedure is employed to avoid a "signaling storm".
Nodes MUST first consult RFC 3484 [6] Section 4 rules to determine Nodes first consult the RFC 3484 default address selection rules
what combinations of addresses are allowed from a local point of [RFC3484] Section 4 rules to determine what combinations of addresses
view, as this reduces the search space. RFC 3484 also provides a are allowed from a local point of view, as this reduces the search
priority ordering among different address pairs, making the search space. RFC 3484 also provides a priority ordering among different
possibly faster. Nodes MAY also use local information, such as known address pairs, making the search possibly faster. Nodes may also use
quality of service parameters or interface types to determine what local information, such as known quality of service parameters or
addresses are preferred over others, and try pairs containing such interface types to determine what addresses are preferred over
addresses first. The multihoming protocol also carries preference others, and try pairs containing such addresses first. The SHIM6
information in its messages [18]. protocol also carries preference information in its messages.
Discussion note: The preferences may either be learned dynamically Discussion note: The preferences may either be learned dynamically
or be configured. It is believed, however, that dynamic learning or be configured. It is believed, however, that dynamic learning
based purely on the multihoming protocol is too hard and not the based purely on the multihoming protocol is too hard and not the
task this layer should do. Solutions where multiple protocols task this layer should do. Solutions where multiple protocols
share their information in a common pool of locators could provide share their information in a common pool of locators could provide
this information from transport protocols, however. this information from transport protocols, however.
One suggested good implementation strategy is to record the
reachability test result (an on/off value) and multiply this by the
age of the information. This allows recently tested address pairs to
be chosen before old ones.
Out of the set of possible candidate address pairs, nodes SHOULD Out of the set of possible candidate address pairs, nodes SHOULD
attempt a test through all of them until a working pair is found, and attempt to test through all of them until a working pair is found,
retrying the process as is necessary. However, all nodes MUST and retrying the process as is necessary. However, all nodes MUST
perform this process sequentially and with exponential back-off. perform this process sequentially and with exponential back-off.
This sequential process is necessary in order to avoid a "signaling This sequential process is necessary in order to avoid a "signaling
storm" when an outage occurs (particularly for a complete site). storm" when an outage occurs (particularly for a complete site).
However, it also limits the number of addresses that can in practice However, it also limits the number of addresses that can in practice
be used for multihoming, considering that transport and application be used for multihoming, considering that transport and application
layer protocols will fail if the switch to a new address pair takes layer protocols will fail if the switch to a new address pair takes
too long. too long.
Section 6.5 suggests default values for the timers associated with
the exploration process. The value Initial Probe Timeout (0.5 s)
specifies the interval between initial attempts to send probes;
Number of Initial Probes (4) specifies how many initial probes can be
sent before the exponential backoff procedure needs to be employed.
This process duplicates the time between every probe if there is no
response. Finally, Max probe Timeout (60 s) specifies a limit beyond
which the probe interval may not grow. If the exploration process
reaches this interval, it will continue sending at this rate until a
suitable response is triggered or the SHIM6 context is garbage
collected.
5.4. Protocol Design 5.4. Protocol Design
REAP is designed as a modular part of SHIM6 in the hopes that it may REAP is designed as a modular part of SHIM6 in the hopes that it may
also be useful in other contexts. This document defines how it is also be useful in other contexts. This document defines how it is
carried within SHIM6, but the actual protocol messages are self- carried within SHIM6, but the actual protocol messages are self-
contained so that it could be carried by other protocols as well. contained so that it could be carried by other protocols as well.
The REAP design allows performing both failure detection and address The REAP design allows performing both failure detection and address
pair exploration in the same sequence of messages, without a need to pair exploration in the same sequence of messages, without a need to
designate a specific point when the current address pair is declared designate a specific point when the current address pair is declared
skipping to change at page 15, line 24 skipping to change at page 15, line 13
current pair in case it starts working again. For instance, the current pair in case it starts working again. For instance, the
exploration process can refer to keepalive message that succeeded in exploration process can refer to keepalive message that succeeded in
getting to the peer during the reachability testing phase. getting to the peer during the reachability testing phase.
REAP also integrates a return routability function, making it REAP also integrates a return routability function, making it
unnecessary to perform another roundtrip before a newly discovered unnecessary to perform another roundtrip before a newly discovered
address can be taken into use. address can be taken into use.
This document defines a minimal set of parameters that are carried by This document defines a minimal set of parameters that are carried by
the messages of the protocol. Specifically, we have limited the the messages of the protocol. Specifically, we have limited the
parameters to those that are necessary to find a working path. We parameters to those that are necessary to find a working address
note there may be extensions that are needed in the future for pair. We note there may be extensions that are needed in the future
various reasons, such as the desire to support load balancing or for various reasons, such as the desire to support load balancing or
finding best paths. An option format has been specified to allow finding best pairs. An option format has been specified to allow
this. this.
5.5. Example Protocol Runs 5.5. Example Protocol Runs
This section has examples of REAP protocol runs in typical scenarios. This section has examples of REAP protocol runs in typical scenarios.
We start with the simplest scenario of two hosts, A and B, that have We start with the simplest scenario of two hosts, A and B, that have
a SHIM6 connection with each other but are not currently sending any a SHIM6 connection with each other but are not currently sending any
data. As neither side sends anything, they also do not expect data. As neither side sends anything, they also do not expect
anything back, so there are no messages at all: anything back, so there are no messages at all:
skipping to change at page 20, line 5 skipping to change at page 20, line 5
| | a new path to B | | a new path to B
| | | |
| (A2,B2) payload packet | | (A2,B2) payload packet |
|-------------------------------------------->| Payload packets |-------------------------------------------->| Payload packets
| | flow again | | flow again
| (B2,A2) payload packet | | (B2,A2) payload packet |
|<--------------------------------------------| |<--------------------------------------------|
In the next case we have even less luck. The response to the REAP In the next case we have even less luck. The response to the REAP
probe doesn't make it in the reverse direction, so both ends end up probe doesn't make it in the reverse direction, so both ends end up
exploring indepedently: exploring independently:
Peer A Peer B Peer A Peer B
| | | |
| (A1,B1) payload packet | | (A1,B1) payload packet |
|-------------------------------------------->| |-------------------------------------------->|
| | | |
| (B1,A1) payload packet | | (B1,A1) payload packet |
| /-----------------------------------------| Time T1 | /-----------------------------------------| Time T1
| | Path B1->A1 | | Path B1->A1
| | is now | | is now
skipping to change at page 22, line 29 skipping to change at page 22, line 29
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Options + + Options +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header Next Header
This value MUST be set to NO_NXT_HDR (59). This value MUST be set to NO_NXT_HDR (59).
Hdr Ext Len
This is an 8-bit unsigned integer field, calculated as specified
in Section 5.3 of the SHIM6 protocol description
[I-D.ietf-shim6-proto].
Type Type
This field identifies the Probe message and MUST be set to 66 This field identifies the Probe message and MUST be set to 66
(Keepalive). (Keepalive).
Reserved Reserved
This is a 7-bit field reserved for future use. It is set to zero This is a 7-bit field reserved for future use. It is set to zero
on transmit, and MUST be ignored on receipt. on transmit, and MUST be ignored on receipt.
R R
This is a 1-bit field reserved for future use. It is set to zero This is a 1-bit field reserved for future use. It is set to zero
on transmit, and MUST be ignored on receipt. on transmit, and MUST be ignored on receipt.
Checksum
This is a 16-bit field, calculated as specified in Section 5.3 of
the SHIM6 protocol description [I-D.ietf-shim6-proto].
Receiver Context Tag Receiver Context Tag
This is a 47-bit field for the Context Tag the receiver has This is a 47-bit field for the Context Tag the receiver has
allocated for the context. allocated for the context.
Options Options
This MUST contain at least the Keepalive option and MAY contain This MUST contain at least the Keepalive option and MAY contain
one or more Reachability options.The inclusion of the latter one or more Reachability options.The inclusion of the latter
options is not necessary, however, as there are currenly no options is not necessary, however, as there are currently no
defined options that are useful in a Keepalive message. These defined options that are useful in a Keepalive message. These
options are provided only for future extensibility reasons. options are provided only for future extensibility reasons.
A valid message conforms to the format above, has a Receiver Context A valid message conforms to the format above, has a Receiver Context
Tag that matches to context known by the receiver, is valid shim Tag that matches to context known by the receiver, is valid shim
control message as defined in Section 12.2 of [18], and its shim control message as defined in Section 12.2 of the SHIM6 protocol
context state is ESTABLISHED. The receiver processes a valid message description [I-D.ietf-shim6-proto], and its shim context state is
by inspecting its options, and executing any actions specified for ESTABLISHED. The receiver processes a valid message by inspecting
such options. its options, and executing any actions specified for such options.
The processing rules for this message are the given in more detail in The processing rules for this message are the given in more detail in
Section 6.4. Section 6.4.
6.1.1. Keepalive Option 6.1.1. Keepalive 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 = 10 |0| Length | | Type = 10 |0| Length |
skipping to change at page 23, line 39 skipping to change at page 24, line 8
This value MUST be set to 10 (Keepalive Option). This value MUST be set to 10 (Keepalive Option).
0 0
This value MUST be set to 0, as in other SHIM6 options. This value MUST be set to 0, as in other SHIM6 options.
Length Length
This is the length of the option and MUST be calculated as This is the length of the option and MUST be calculated as
specified in Section 5.14 of [18]. specified in Section 5.14 of the SHIM6 protocol description
[I-D.ietf-shim6-proto].
Res Res
This 4-bit reserved field MUST be set to zero when sending, and This 4-bit reserved field MUST be set to zero when sending, and
ignored on receipt. ignored on receipt.
Identifier Identifier
This 28-bit field identifies this particular instance of an This 28-bit field identifies this particular instance of an
Keepalive message. This value SHOULD be generated using a random Keepalive message. This value SHOULD be generated using a random
number generator that is known to have good randomness properties number generator that is known to have good randomness properties
[1]. Upon reception, Identifier values from both Keepalive and as outlined in RFC 1750 [RFC1750]. Upon reception, Identifier
Probe messages may be copied onto Probe Reception Report options. values from both Keepalive and Probe messages may be copied onto
This allows them to be used for both identifying which packets Probe Reception Report options. This allows them to be used for
were received as well as for performing a return routability test. both identifying which packets were received as well as for
performing a return routability test.
The processing rules for this option are the given in more detail in The processing rules for this option are the given in more detail in
Section 6.4. Section 6.4.
6.2. Probe Message 6.2. Probe Message
This message performs REAP exploration. Its format is as follows: This message performs REAP exploration. Its format is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 24, line 33 skipping to change at page 25, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Options + + Options +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header Next Header
This value MUST be set to NO_NXT_HDR (59). This value MUST be set to NO_NXT_HDR (59).
Hdr Ext Len
This is an 8-bit unsigned integer field, calculated as specified
in Section 5.3 of the SHIM6 protocol description
[I-D.ietf-shim6-proto].
Type Type
This field identifies the Probe message and MUST be set to 67 This field identifies the Probe message and MUST be set to 67
(Probe). (Probe).
Reserved Reserved
This is a 7-bit field reserved for future use. It is set to zero This is a 7-bit field reserved for future use. It is set to zero
on transmit, and MUST be ignored on receipt. on transmit, and MUST be ignored on receipt.
R R
This is a 1-bit field reserved for future use. It is set to zero This is a 1-bit field reserved for future use. It is set to zero
on transmit, and MUST be ignored on receipt. on transmit, and MUST be ignored on receipt.
Checksum
This is a 16-bit field, calculated as specified in Section 5.3 of
the SHIM6 protocol description [I-D.ietf-shim6-proto].
Receiver Context Tag Receiver Context Tag
This is a 47-bit field for the Context Tag the receiver has This is a 47-bit field for the Context Tag the receiver has
allocated for the context. allocated for the context.
Options Options
This MUST contain at least the Probe option and MAY contain one or This MUST contain at least the Probe option and MAY contain one or
more Reachability options. more Reachability options.
A valid message conforms to the format above, has a Receiver Context A valid message conforms to the format above, has a Receiver Context
Tag that matches to a context known by the receiver, is valid shim Tag that matches to a context known by the receiver, is valid shim
control message as defined in Section 12.2 of [18], and its shim control message as defined in Section 12.2 of the SHIM6 protocol
context state is ESTABLISHED. The receiver processes a valid message description [I-D.ietf-shim6-proto], and its shim context state is
by inspecting its options, and executing any actions specified such ESTABLISHED. The receiver processes a valid message by inspecting
options. This includes the SHIM6 Probe option found within the its options, and executing any actions specified such options. This
options. includes the SHIM6 Probe option found within the options.
The processing rules for this message are the given in more detail in The processing rules for this message are the given in more detail in
Section 6.4. Section 6.4.
6.2.1. Probe Option 6.2.1. Probe 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 = 11 |0| Length | | Type = 11 |0| Length |
skipping to change at page 25, line 42 skipping to change at page 26, line 26
This value MUST be set to 11 (Probe Option). This value MUST be set to 11 (Probe Option).
0 0
This value MUST be set to 0, as in other SHIM6 options. This value MUST be set to 0, as in other SHIM6 options.
Length Length
This is the length of the option and MUST be calculated as This is the length of the option and MUST be calculated as
specified in Section 5.14 of [18]. specified in Section 5.14 of the SHIM6 protocol description
[I-D.ietf-shim6-proto].
Y (The "I See You" flag) Y (The "I See You" flag)
This flag is set to 1 if the sender receives either payload This flag is set to 1 if the sender receives either payload
packets or REAP messages from the peer, and 0 otherwise. The packets or REAP messages from the peer, and 0 otherwise. The
determination of when the sender receives something is made during determination of when the sender receives something is made during
the last Send Timeout seconds (see Section 6.5) when traffic was the last Send Timeout seconds (see Section 6.5) when traffic was
expected, i.e., when there was either payload traffic or REAP expected, i.e., when there was either payload traffic or REAP
messages. messages.
skipping to change at page 26, line 19 skipping to change at page 26, line 52
Res Res
This 3-bit reserved field MUST be set to zero when sending, and This 3-bit reserved field MUST be set to zero when sending, and
ignored on receipt. ignored on receipt.
Identifier Identifier
This 28-bit field identifies this particular instance of an Probe This 28-bit field identifies this particular instance of an Probe
message. This value SHOULD be generated using a random number message. This value SHOULD be generated using a random number
generator that is known to have good randomness properties [1]. generator that is known to have good randomness properties. Upon
Upon reception, Identifier values are copied onto Probe Reception reception, Identifier values are copied onto Probe Reception
Report options. This allows them to be used for both identifying Report options. This allows them to be used for both identifying
which Probes were received as well as for performing a return which Probes were received as well as for performing a return
routability test. routability test.
The processing rules for this option are the given in more detail in The processing rules for this option are the given in more detail in
Section 6.4. Section 6.4.
6.3. Reachability Option 6.3. Reachability Option
Additional information can be included in Keepalive and Probe Additional information can be included in Keepalive and Probe
skipping to change at page 27, line 8 skipping to change at page 27, line 39
This value MUST be set to 12 (Reachability option). This value MUST be set to 12 (Reachability option).
0 0
This value MUST be set to 0, as in other SHIM6 options. This value MUST be set to 0, as in other SHIM6 options.
Length Length
This is the length of the option and MUST be calculated as This is the length of the option and MUST be calculated as
specified in Section 5.14 of [18]. specified in Section 5.14 of the SHIM6 protocol description
[I-D.ietf-shim6-proto].
Option Type Option Type
This value identifies the option. This value identifies the option.
Option Data Option Data
Option-specific content. Option-specific content.
Unrecognized options MUST be ignored upon receipt. All Unrecognized options MUST be ignored upon receipt. All
skipping to change at page 28, line 9 skipping to change at page 28, line 42
This field is reserved for possible future Reachability options This field is reserved for possible future Reachability options
that are carried (recursively) within this option. Unrecognized that are carried (recursively) within this option. Unrecognized
options MUST be ignored upon receipt. Currently there are no options MUST be ignored upon receipt. Currently there are no
defined options that can be carried here. defined options that can be carried here.
6.3.2. Probe Reception Report 6.3.2. Probe Reception Report
This option MUST be included in any Probe message when the sender has This option MUST be included in any Probe message when the sender has
recently (within the last Send Timeout seconds) received Probe or recently (within the last Send Timeout seconds) received Probe or
Keepalieve messages from the peer. Depending on MTU and timing Keepalive messages from the peer. Depending on MTU and timing
considerations, the sender MAY, however, include options for only considerations, the sender MAY, however, include options for only
some of the received Probe messages. All implementations MUST some of the received Probe messages. All implementations MUST
support sending of at least five such options, however. support sending of at least five such options, however.
The format of this option is as follows: The format of this option is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 11 |0| Length | | Type = 11 |0| Length |
skipping to change at page 29, line 31 skipping to change at page 30, line 18
state the underlying address pairs are assumed to be operational. In state the underlying address pairs are assumed to be operational. In
the Exploring state this node has observed a problem and has the Exploring state this node has observed a problem and has
currently not seen any traffic from the peer. Finally, in the currently not seen any traffic from the peer. Finally, in the
ExploringOK state this node sees traffic from the peer, but peer may ExploringOK state this node sees traffic from the peer, but peer may
not yet see any traffic from this node so that the exploration not yet see any traffic from this node so that the exploration
process needs to continue. process needs to continue.
The node maintains also the Send and Keepalive timers. The Send The node maintains also the Send and Keepalive timers. The Send
timer reflects the requirement that when this node sends a payload timer reflects the requirement that when this node sends a payload
packet there should be some return traffic (either payload packets or packet there should be some return traffic (either payload packets or
Keepalive messages) within Keepalive Timeout seconds. The Keepalive Keepalive messages) within Send Timeout seconds. The Keepalive timer
timer reflects the requirement that when this node receives a payload reflects the requirement that when this node receives a payload
packet there should a similar response towards the peer. The packet there should a similar response towards the peer. The
Keepalive timer is only used within the Operational state, and the Keepalive timer is only used within the Operational state, and the
Send timer in the Operational and ExploringOK states. No timer is Send timer in the Operational and ExploringOK states. No timer is
running in the Exploring state. running in the Exploring state.
Upon the reception of a payload packet in the Operational state, the Upon the reception of a payload packet in the Operational state, the
node starts the Keepalive timer if it is not yet running, and stops node starts the Keepalive timer if it is not yet running, and stops
the Send timer if it was running. If the node is in the Exploring the Send timer if it was running. If the node is in the Exploring
state it transitions to the ExploringOK state, sends a Probe message state it transitions to the ExploringOK state, sends a Probe message
with the I See You flag set to 1 (Yes), and starts the Send timer. with the I See You flag set to 1 (Yes), and starts the Send timer.
skipping to change at page 34, line 4 skipping to change at page 33, line 45
--------------------------------------------------------------- ---------------------------------------------------------------
- SEND Probe Y=No SEND Probe Y=Yes - SEND Probe Y=No SEND Probe Y=Yes
START Send START Send
6.5. Protocol Constants 6.5. Protocol Constants
The following protocol constants are defined: The following protocol constants are defined:
Send Timeout 10 seconds Send Timeout 10 seconds
Keepalive Timeout 3 seconds Keepalive Timeout 3 seconds
Initial Probe Timeout 0.5 seconds
Number of Initial Probes 4 probes
Max Probe Timeout 60 seconds
7. Security Considerations 7. Security Considerations
Attackers may spoof various indications from lower layers and the Attackers may spoof various indications from lower layers and the
network in an effort to confuse the peers about which addresses are network in an effort to confuse the peers about which addresses are
or are not working. For example, attackers may spoof ICMP error or are not working. For example, attackers may spoof ICMP error
messages in an effort to cause the parties to move their traffic messages in an effort to cause the parties to move their traffic
elsewhere or even to disconnect. Attackers may also spoof elsewhere or even to disconnect. Attackers may also spoof
information related to network attachments, router discovery, and information related to network attachments, router discovery, and
address assignments in an effort to make the parties believe they address assignments in an effort to make the parties believe they
have Internet connectivity when in reality they do not. have Internet connectivity when in reality they do not.
This may cause use of non-preferred addresses or even denial-of- This may cause use of non-preferred addresses or even denial-of-
service. service.
This protocol does not provide any protection of its own for This protocol does not provide any protection of its own for
indications from other parts of the protocol stack. However, this indications from other parts of the protocol stack. Unprotected
protocol has weak resistance against incorrect information from these indications SHOULD NOT be taken as a proof of connectivity problems.
sources in the sense that it performs its own tests prior to picking However, REAP has weak resistance against incorrect information even
a new address pair. Denial-of- service vulnerabilities remain, from unprotected indications in the sense that it performs its own
however, as do vulnerabilities against on path attackers. tests prior to picking a new address pair. Denial-of- service
vulnerabilities remain, however, as do vulnerabilities against on
path attackers.
Some aspects of these vulnerabilities can be mitigated through the Some aspects of these vulnerabilities can be mitigated through the
use of techniques specific to the other parts of the stack, such as use of techniques specific to the other parts of the stack, such as
properly dealing with ICMP errors [22], link layer security, or the properly dealing with ICMP errors [I-D.ietf-tcpm-icmp-attacks], link
use of [12] to protect IPv6 Router and Neighbor Discovery. layer security, or the use of SEND [RFC3971] to protect IPv6 Router
and Neighbor Discovery.
This protocol is designed to be used in situations where other parts Other parts of the SHIM6 protocol ensure that the set of addresses we
of the stack have ensured that a set of addresses belong together, are switching between actually belong together. REAP itself provides
such as via SHIM6 HBAs [17]. That is, REAP itself provides no no such assurances. Similarly, REAP provides only minimal protection
assurance that a set of addresses belongs to the same host. against third party flooding attacks; when REAP is run its Probe
Similarly, REAP provides only minimal protection against third party identifiers can be used as a return routability check that the
flooding attacks; when REAP is run its Probe identifiers can be used claimed address is indeed willing to receive traffic. However, this
as a return routability check that the claimed address is indeed needs to be complemented with another mechanism to ensure that the
willing to receive traffic. However, this needs to be complemented claimed address is also the correct host. SHIM6 does this by
with another mechanism to ensure that the claimed address is also the performing binding of all operations to context tags.
correct host. In SHIM6 this is performed by binding all operations
to context tags.
Finally, the exploration itself can cause a number of packets to be Finally, the exploration itself can cause a number of packets to be
sent. As a result it may be used as a tool for packet amplification sent. As a result it may be used as a tool for packet amplification
in flooding attacks. In order to prevent this it is required that in flooding attacks. In order to prevent this it is required that
the protocol employing REAP has built-in mechanisms to prevent this. the protocol employing REAP has built-in mechanisms to prevent this.
For instance, in SHIM6 contexts are created only after a relatively For instance, in SHIM6 contexts are created only after a relatively
large number of packets has been exchanged, a cost which reduces the large number of packets has been exchanged, a cost which reduces the
attractiveness of using SHIM6 and REAP for amplification attacks. attractiveness of using SHIM6 and REAP for amplification attacks.
However, such protections are typically not present at connection However, such protections are typically not present at connection
establishment time. When exploration would be needed for connection establishment time. When exploration would be needed for connection
skipping to change at page 37, line 9 skipping to change at page 37, line 9
defined values, 1 (Payload Reception Report defined in Section 6.3.1) defined values, 1 (Payload Reception Report defined in Section 6.3.1)
and 2 (Probe Reception Report defined in Section 6.3.2). Further and 2 (Probe Reception Report defined in Section 6.3.2). Further
allocations within this 16-bit field can be made through allocations within this 16-bit field can be made through
Specification Required. The range from 65000 to 65535 is reserved Specification Required. The range from 65000 to 65535 is reserved
for experimental use. for experimental use.
9. References 9. References
9.1. Normative References 9.1. Normative References
[1] Eastlake, D., Crocker, S., and J. Schiller, "Randomness [RFC1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994. Recommendations for Security", RFC 1750, December 1994.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
for IP Version 6 (IPv6)", RFC 2461, December 1998. Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[4] Thomson, S. and T. Narten, "IPv6 Stateless Address [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[5] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", and M. Carney, "Dynamic Host Configuration Protocol for
RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[6] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003.
[7] Choi, J., "Detecting Network Attachment in IPv6 Goals", [RFC3484] Draves, R., "Default Address Selection for Internet
draft-ietf-dna-goals-00 (work in progress), June 2004. Protocol version 6 (IPv6)", RFC 3484, February 2003.
[8] Moore, N., "Optimistic Duplicate Address Detection for IPv6", [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
draft-ietf-ipv6-optimistic-dad-01 (work in progress), June 2004. Addresses", RFC 4193, October 2005.
[9] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
Addresses", draft-ietf-ipv6-unique-local-addr-05 (work in for IPv6", RFC 4429, April 2006.
progress), June 2004.
9.2. Informative References 9.2. Informative References
[10] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [AURA02] Aura, T., Roe, M., and J. Arkko, "Security of Internet
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Location Management", In Proceedings of the 18th Annual
Paxson, "Stream Control Transmission Protocol", RFC 2960, Computer Security Applications Conference, Las Vegas,
October 2000. Nevada, USA., December 2002.
[11] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN [I-D.bagnulo-shim6-addr-selection]
- Simple Traversal of User Datagram Protocol (UDP) Through Bagnulo, M., "Address selection in multihomed
Network Address Translators (NATs)", RFC 3489, March 2003. environments", draft-bagnulo-shim6-addr-selection-00 (work
in progress), October 2005.
[12] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [I-D.huitema-multi6-addr-selection]
Neighbor Discovery (SEND)", RFC 3971, March 2005. Huitema, C., "Address selection in multihomed
environments", draft-huitema-multi6-addr-selection-00
(work in progress), October 2004.
[13] Aboba, B., "Detection of Network Attachment (DNA) in IPv4", [I-D.ietf-dna-cpl]
draft-ietf-dhc-dna-ipv4-08 (work in progress), July 2004. Nordmark, E. and J. Choi, "DNA with unmodified routers:
Prefix list based approach", draft-ietf-dna-cpl-02 (work
in progress), January 2006.
[14] Nikander, P., "End-Host Mobility and Multi-Homing with Host [I-D.ietf-dna-protocol]
Identity Protocol", draft-ietf-hip-mm-00 (work in progress), Kempf, J., "Detecting Network Attachment in IPv6 Networks
October 2004. (DNAv6)", draft-ietf-dna-protocol-00 (work in progress),
February 2006.
[15] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", [I-D.ietf-hip-mm]
draft-ietf-mobike-protocol-03 (work in progress), Nikander, P., "End-Host Mobility and Multihoming with the
September 2005. Host Identity Protocol", draft-ietf-hip-mm-03 (work in
progress), March 2006.
[16] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A [I-D.ietf-mmusic-ice]
Methodology for Network Address Translator (NAT) Traversal for Rosenberg, J., "Interactive Connectivity Establishment
Multimedia Session Establishment Protocols", (ICE): A Methodology for Network Address Translator (NAT)
draft-ietf-mmusic-ice-02 (work in progress), July 2004. Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-08 (work in progress), March 2006.
[17] Bagnulo, M., "Hash Based Addresses (HBA)", [I-D.ietf-shim6-proto]
draft-ietf-shim6-hba-00 (work in progress), July 2005. Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim
protocol", draft-ietf-shim6-proto-05 (work in progress),
May 2006.
[18] Nordmark, E., "Level 3 multihoming shim protocol", [I-D.ietf-shim6-reach-detect]
draft-ietf-shim6-proto-00 (work in progress), October 2005. Beijnum, I., "Shim6 Reachability Detection",
draft-ietf-shim6-reach-detect-01 (work in progress),
October 2005.
[19] Beijnum, I., "Shim6 Reachability Detection", [I-D.ietf-tcpm-icmp-attacks]
draft-ietf-shim6-reach-detect-00 (work in progress), July 2005. Gont, F., "ICMP attacks against TCP",
draft-ietf-tcpm-icmp-attacks-00 (work in progress),
February 2006.
[20] Stewart, R., "Stream Control Transmission Protocol (SCTP) [I-D.ietf-tsvwg-addip-sctp]
Stewart, R., "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration", Dynamic Address Reconfiguration",
draft-ietf-tsvwg-addip-sctp-10 (work in progress), draft-ietf-tsvwg-addip-sctp-15 (work in progress),
January 2005. June 2006.
[21] Bagnulo, M., "Address selection in multihomed environments", [I-D.rosenberg-midcom-turn]
draft-bagnulo-shim6-addr-selection-00 (work in progress), Rosenberg, J., "Traversal Using Relay NAT (TURN)",
October 2005. draft-rosenberg-midcom-turn-08 (work in progress),
September 2005.
[22] Gont, F., "ICMP attacks against TCP", [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
draft-gont-tcpm-icmp-attacks-00 (work in progress), Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
August 2004. Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[23] Huitema, C., "Address selection in multihomed environments", [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
draft-huitema-multi6-addr-selection-00 (work in progress), "STUN - Simple Traversal of User Datagram Protocol (UDP)
October 2004. Through Network Address Translators (NATs)", RFC 3489,
March 2003.
[24] Rosenberg, J., "Traversal Using Relay NAT (TURN)", [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
draft-rosenberg-midcom-turn-05 (work in progress), July 2004. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[25] Aura, T., Roe, M., and J. Arkko, "Security of Internet Location [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
Management", In Proceedings of the 18th Annual Computer Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
Security Applications Conference, Las Vegas, Nevada, USA.,
December 2002. [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
Appendix A. Contributors Appendix A. Contributors
This draft attempts to summarize the thoughts and unpublished This draft attempts to summarize the thoughts and unpublished
contributions of many people, including the MULTI6 WG design team contributions of many people, including the MULTI6 WG design team
members Marcelo Bagnulo Braun, Iljitsch van Beijnum, Erik Nordmark, members Marcelo Bagnulo Braun, Iljitsch van Beijnum, Erik Nordmark,
Geoff Huston, Margaret Wasserman, and Jukka Ylitalo, the MOBIKE WG Geoff Huston, Margaret Wasserman, and Jukka Ylitalo, the MOBIKE WG
contributors Pasi Eronen, Tero Kivinen, Francis Dupont, Spencer contributors Pasi Eronen, Tero Kivinen, Francis Dupont, Spencer
Dawkins, and James Kempf, and my colleague Pekka Nikander at Dawkins, and James Kempf, and my colleague Pekka Nikander at
Ericsson. This draft is also in debt to work done in the context of Ericsson. This draft is also in debt to work done in the context of
SCTP [10] and HIP [14]. SCTP [RFC2960] and HIP [I-D.ietf-hip-mm].
Appendix B. Acknowledgements Appendix B. Acknowledgements
The author would also like to thank Christian Huitema, Pekka Savola, The author would also like to thank Christian Huitema, Pekka Savola,
and Hannes Tschofenig for interesting discussions in this problem John Loughney, and Hannes Tschofenig for interesting discussions in
space, and for their comments on earlier versions of this draft. this problem space, and for review of this specification.
Authors' Addresses Authors' Addresses
Jari Arkko Jari Arkko
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
Email: jari.arkko@ericsson.com Email: jari.arkko@ericsson.com
Iljitsch van Beijnum Iljitsch van Beijnum
Muada Muada
The Netherlands The Netherlands
Email: iljitsch@muada.com Email: iljitsch@muada.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 42, line 29 skipping to change at page 43, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 101 change blocks. 
355 lines changed or deleted 395 lines changed or added

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