draft-ietf-shim6-proto-05.txt   draft-ietf-shim6-proto-06.txt 
SHIM6 WG E. Nordmark SHIM6 WG E. Nordmark
Internet-Draft Sun Microsystems Internet-Draft Sun Microsystems
Expires: November 16, 2006 M. Bagnulo Expires: April 26, 2007 M. Bagnulo
UC3M UC3M
May 15, 2006 October 23, 2006
Level 3 multihoming shim protocol Level 3 multihoming shim protocol
draft-ietf-shim6-proto-05.txt draft-ietf-shim6-proto-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 16, 2006. This Internet-Draft will expire on April 26, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
The SHIM6 protocol is a layer 3 shim for providing locator agility The SHIM6 protocol is a layer 3 shim for providing locator agility
below the transport protocols, so that multihoming can be provided below the transport protocols, so that multihoming can be provided
for IPv6 with failover and load sharing properties, without assuming for IPv6 with failover and load sharing properties, without assuming
skipping to change at page 5, line 21 skipping to change at page 5, line 21
provider independent IPv6 address which is announced in the global provider independent IPv6 address which is announced in the global
IPv6 routing table. The hosts in a site which has multiple provider IPv6 routing table. The hosts in a site which has multiple provider
allocated IPv6 address prefixes, will use the shim6 protocol allocated IPv6 address prefixes, will use the shim6 protocol
specified in this document to setup state with peer hosts, so that specified in this document to setup state with peer hosts, so that
the state can later be used to failover to a different locator pair, the state can later be used to failover to a different locator pair,
should the original one stop working. should the original one stop working.
We assume that redirection attacks are prevented using the mechanism We assume that redirection attacks are prevented using the mechanism
specified in HBA [7]. specified in HBA [7].
The reachability and failure detection, including how a new working The reachability and failure detection mechanisms, including how a
locator pair is discovered after a failure, is specified in a new working locator pair is discovered after a failure, is specified
separate documents [8] This document allocates message types and in a separate document [8] This document allocates message types and
option types for that sub-protocol, and leaves the specification of option types for that sub-protocol, and leaves the specification of
the message and option formats as well as the protocol behavior to the message and option formats as well as the protocol behavior to
that document. that document.
1.1. Goals 1.1. Goals
The goals for this approach is to: The goals for this approach is to:
o Preserve established communications through certain classes of o Preserve established communications in the presence of certain
failures, for example, TCP connections and application classes of failures, for example, TCP connections and UDP streams.
communications using UDP.
o Have minimal impact on upper layer protocols in general and on o Have minimal impact on upper layer protocols in general and on
transport protocols in particular. transport protocols in particular.
o Address the security threats in [19] through the combination of o Address the security threats in [19] through the combination of
the HBA/CGA approach specified in a separate document [7], and the HBA/CGA approach specified in a separate document [7] and
techniques described in this document. techniques described in this document.
o Not require extra roundtrip up front to setup shim specific state. o Not require extra roundtrip up front to setup shim specific state.
Instead allow the upper layer traffic (e.g., TCP) to flow as Instead allow the upper layer traffic (e.g., TCP) to flow as
normal and defer the setup of the shim state until some number of normal and defer the setup of the shim state until some number of
packets have been exchanged. packets have been exchanged.
o Take advantage of multiple locators/addresses for load spreading o Take advantage of multiple locators/addresses for load spreading
so that different sets of communication to a host (e.g., different so that different sets of communication to a host (e.g., different
connections) might use different locators of the host. Note that connections) might use different locators of the host. Note that
this might cause load to be spread unevenly, thus we use the term this might cause load to be spread unevenly, thus we use the term
"load spreading" instead of "load balancing". This capability "load spreading" instead of "load balancing". This capability
might enable some forms of traffic engineering, but the details might enable some forms of traffic engineering, but the details
for traffic engineering, including what requirements can be for traffic engineering, including what requirements can be
satisfied, are not specified in this document, and form part of a satisfied, are not specified in this document, and form part of a
potential extensions to this protocol. potential extensions to this protocol.
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 prefixes change
prefixes change over time due to site renumbering. Further, we over time due to site renumbering. Further, we assume that such
assume that such changes to the set of locator prefixes can be changes to the set of locator prefixes can be relatively slow and
relatively slow and managed; slow enough to allow updates to the DNS managed; slow enough to allow updates to the DNS to propagate (since
to propagate. But it is not a goal to try to make communication the protocol defined in this document depends on the DNS to find the
survive a renumbering event (which causes all the locators of a host appropriate locator sets). Note, however that it is an explicit non-
to change to a new set of locators). This proposal does not attempt goal to make communication survive a renumbering event (which causes
to solve the, perhaps related, problem of host mobility. However, it all the locators of a host to change to a new set of locators). This
might turn out that the shim6 protocol can be a useful component for proposal does not attempt to solve the related problem of host
future host mobility solutions, e.g., for route optimization. mobility. However, it might turn out that the shim6 protocol can be
a useful component for future host mobility solutions, e.g., for
route optimization.
This proposal also does not try to provide a new network level or Finally, this proposal also does not try to provide a new network
transport level identifier namespace separated from the current IP level or transport level identifier name space distinct from the
address namespace. Even though such a concept would be useful to current IP address name space. Even though such a concept would be
ULPs and applications, especially if the management burden for such a useful to Upper Layer Protocols (ULPs) and applications, especially
name space was negligible and there was an efficient yet secure if the management burden for such a name space was negligible and
mechanism to map from identifiers to locators, such a name space there was an efficient yet secure mechanism to map from identifiers
isn't necessary (and furthermore doesn't seem to help) to solve the to locators, such a name space isn't necessary (and furthermore
multihoming problem. doesn't seem to help) to solve the multihoming problem.
1.3. Locators as Upper-layer Identifiers 1.3. Locators as Upper-layer Identifiers
This approach does not introduce a new identifier name space but The approach described in this document does not introduce a new
instead uses the locator that is selected in the initial contact with identifier name space but instead uses the locator that is selected
the remote peer as the preserved upper-level identifier. While there in the initial contact with the remote peer as the preserved Upper-
may be subsequent changes in the selected network level locators over Layer Identifier (ULID). While there may be subsequent changes in
time in response to failures in using the original locator, the upper the selected network level locators over time in response to failures
level protocol stack elements will continue to use this upper level in using the original locator, the upper level protocol stack
identifier without change. elements will continue to use this upper level identifier without
change.
This implies that the ULID selection is performed as today's default This implies that the ULID selection is performed as today's default
address selection as specified in RFC 3484 [12]. Some extensions are address selection as specified in RFC 3484 [12]. Some extensions are
needed to RFC 3484 to try different source addresses, whether or not needed to RFC 3484 to try different source addresses, whether or not
the shim6 protocol is used, as outlined in [13]. Underneath, and the shim6 protocol is used, as outlined in [13]. 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. If communication
communication fails the shim can test and select alternate locators. subsequently fails the shim can test and select alternate locators.
A subsequent section discusses the issues when the selected ULID is A subsequent section discusses the issues when the selected ULID is
not initially working hence there is a need to switch locators up not initially working hence there is a need to switch locators up
front. front.
Using one of the locators as the ULID has certain benefits for Using one of the locators as the ULID has certain benefits for
applications which have long-lived session state, or performs applications which have long-lived session state or performs
callbacks or referrals, because both the FQDN and the 128-bit ULID callbacks or referrals, because both the FQDN and the 128-bit ULID
work as handles for the applications. However, using a single 128- work as handles for the applications. However, using a single 128-
bit ULID doesn't provide seamless communication when that locator is bit ULID doesn't provide seamless communication when that locator is
unreachable. See [22] for further discussion of the application unreachable. See [22] 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 addresses, such
as unique-local addresses [18], as ULIDs in a multihoming solution. as Unique-Local Addresses (ULAs) [18], as ULIDs in a multihoming
While this document doesn't specify all aspects of this, it is solution. While this document doesn't specify all aspects of this,
believed that the approach can be extended to handle such a case. it is believed that the approach can be extended to handle the non-
For example, the protocol already needs to handle ULIDs that are not routable address case.. For example, the protocol already needs to
initially reachable. Thus the same mechanism can handle ULIDs that handle ULIDs that are not initially reachable. Thus the same
are permanently unreachable from outside their site. The issue mechanism can handle ULIDs that are permanently unreachable from
becomes how to make the protocol perform well when the ULID is known outside their site. The issue becomes how to make the protocol
a priori to be not reachable (e.g., the ULID is a ULA), for instance, perform well when the ULID is known a priori to be not reachable
avoiding any timeout and retries in this case. In addition one would (e.g., the ULID is a ULA), for instance, avoiding any timeout and
need to understand how the ULAs would be entered in the DNS to avoid retries in this case. In addition one would need to understand how
a performance impact on existing, non-shim6 aware, IPv6 hosts the ULAs would be entered in the DNS to avoid a performance impact on
potentially trying to communicate to the (unreachable) ULA. existing, non-shim6 aware, IPv6 hosts potentially trying to
communicate to the (unreachable) ULA.
1.4. IP Multicast 1.4. IP Multicast
IP Multicast requires that the IP source address field contain a IP Multicast requires that the IP source address field contain a
topologically correct locator for interface that is used to send the topologically correct locator for interface that is used to send the
packet, since IP multicast routing uses both the source address and packet, since IP multicast routing uses both the source address and
the destination group to determine where to forward the packet. the destination group to determine where to forward the packet. In
(This isn't much different than the situation with widely implemented particular, it need to be able to do the RPF check. (This isn't much
ingress filtering [10] for unicast.) different than the situation with widely implemented 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 [14], shim. This is quite a natural fit for protocols which use RTP [14],
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.
skipping to change at page 8, line 14 skipping to change at page 8, line 19
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 in the general case. survive renumbering in the general case.
When a host is renumbered, the effect is that one or more locators When a host is renumbered, the effect is that one or more locators
become invalid, and zero or more locators are added to the host's become invalid, and zero or more locators are added to the host's
network interface. This means that the set of locators that is used network interface. This means that the set of locators that is used
in the shim will change, which the shim can handle as long as not all in the shim will change, which the shim can handle as long as not all
the original locators become invalid at the same time. the original locators become invalid at the same time and depending
on the time that is required to update the DNS and for those updates
to propagate.
But IP addresses are also used as ULID, and making the communication But IP addresses are also used as ULID, and making the communication
survive locators becoming invalid can potentially cause some survive locators becoming invalid can potentially cause some
confusion at the upper layers. The fact that a ULID might be used confusion at the upper layers. 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
both of those ULIDs are no longer reachable as locators, for example both of those ULIDs are no longer reachable as locators, for example
due to a renumbering event. This opens up the possibility that the due to a renumbering event. This opens up the possibility that the
ULID (or at least the prefix on which it is based) is reassigned to ULID (or at least the prefix on which it is based) is reassigned to
another site while it is still being used (with another locator) for another site while it is still being used (with another locator) for
skipping to change at page 8, line 38 skipping to change at page 9, line 5
same ULID while both of them are communicating with the same host. same ULID while both of them are communicating with the same host.
This potential source for confusion can be avoided if we require that This potential source for confusion 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). If becomes invalid (due to the underlying prefix becoming invalid). If
that behavior is desired, it can be accomplished by explicitly that behavior is desired, it can be accomplished by explicitly
discarding the shim state when the ULID becomes invalid. The context discarding the shim state when the ULID becomes invalid. The context
recovery mechanism will then make the peer aware that the context is recovery mechanism will then make the peer aware that the context is
gone, and that the ULID is no longer present at the same locator(s). gone, and that the ULID is no longer present at the same locator(s).
However, terminating the communication might be overkill. Even when
an IPv6 prefix is retired and reassigned to some other site, there is
a very small probability that another host in that site picks the
same 128 bit address (whether using DHCPv6, stateless address
autoconfiguration, or picking a random interface ID [11]). Should
the identical address be used by another host, then there still
wouldn't be a problem until that host attempts to communicate with
the same peer host with which the initial user of the IPv6 address
was communicating.
The protocol as specified in this document does not perform any
action when an address becomes invalid. As we gain further
understanding of the practical impact of renumbering this might
change in a future version of the protocol.
1.6. Placement of the shim 1.6. Placement of the shim
----------------------- -----------------------
| Transport Protocols | | Transport Protocols |
----------------------- -----------------------
------ ------- -------------- ------------- IP endpoint ------ ------- -------------- ------------- IP endpoint
| AH | | ESP | | Frag/reass | | Dest opts | sub-layer | AH | | ESP | | Frag/reass | | Dest opts | sub-layer
------ ------- -------------- ------------- ------ ------- -------------- -------------
skipping to change at page 9, line 50 skipping to change at page 9, line 50
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 selects which next hop and interface to use routing sublayer, which selects which next hop and interface to use
for sending out packets. for sending out packets.
Applications and upper layer protocols use ULIDs which the shim6 Applications and upper layer protocols use ULIDs which the shim6
layer will map to/from different locators. The shim6 layer maintains layer map to/from different locators. The shim6 layer maintains
state, called ULID-pair context, per ULID pairs (that is, applies to state, called ULID-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 so that ULPs see packets that appear to be sent using ULIDs
packets appear to be sent using ULIDs from end to end, even though from end to end. This property is maintained even though the packets
the packets travel through the network containing locators in the IP travel through the network containing locators in the IP address
address fields, and even though those locators might be changed by fields, and even though those locators may be changed by the
the transmitting shim6 layer. transmitting shim6 layer. .
The context state in this approach is maintained per remote ULID i.e. The context state is maintained per remote ULID i.e. approximately
approximately per peer host, and not at any finer granularity. In per peer host, and not at any finer granularity. In particular, it
particular, it is independent of the ULPs and any ULP connections. is independent of the ULPs and any ULP connections. However, the
However, the forking capability enables shim-aware ULPs to use more forking capability enables shim-aware ULPs to use more than one
than one locator pair at a time for an single ULID pair. locator pair at a time for an single ULID pair.
---------------------------- ---------------------------- ---------------------------- ----------------------------
| Sender A | | Receiver B | | Sender A | | Receiver B |
| | | | | | | |
| ULP | | ULP | | ULP | | ULP |
| | src ULID(A)=L1(A) | | ^ | | | src ULID(A)=L1(A) | | ^ |
| | dst ULID(B)=L1(B) | | | src ULID(A)=L1(A) | | | dst ULID(B)=L1(B) | | | src ULID(A)=L1(A) |
| v | | | dst ULID(B)=L1(B) | | v | | | dst ULID(B)=L1(B) |
| multihoming shim | | multihoming shim | | multihoming shim | | multihoming shim |
| | src L2(A) | | ^ | | | src L2(A) | | ^ |
skipping to change at page 10, line 39 skipping to change at page 10, line 39
---------------------------- ---------------------------- ---------------------------- ----------------------------
| ^ | ^
------- cloud with some routers ------- ------- cloud with some routers -------
Figure 2: Mapping with changed locators Figure 2: Mapping with changed locators
The result of this consistent mapping is that there is no impact on The result of this consistent mapping is that there is no impact on
the ULPs. In particular, there is no impact on pseudo-header the ULPs. In particular, there is no impact on pseudo-header
checksums and connection identification. checksums and connection identification.
Conceptually one could view this approach as if both ULIDs and Conceptually, one could view this approach as if both ULIDs and
locators are being present in every packet, and with a header locators are being present in every packet, and with a header
compression mechanism applied that removes the need for the ULIDs to compression mechanism applied that removes the need for the ULIDs to
be carried in the packets once the compression state has been be carried in the packets once the compression state has been
established. In order for the receiver to recreate a packet with the established. In order for the receiver to recreate a packet with the
correct ULIDs there is a need to include some "compression tag" in correct ULIDs there is a need to include some "compression tag" in
the data packets. This serves to indicate the correct context to use the data packets. This serves to indicate the correct context to use
for decompression when the locator pair in the packet is insufficient for decompression when the locator pair in the packet is insufficient
to uniquely identify the context. to uniquely identify the context.
1.7. Traffic Engineering 1.7. Traffic Engineering
skipping to change at page 11, line 20 skipping to change at page 11, line 20
from identifiers is that each host ends up with multiple locators. from identifiers is that each host ends up with multiple locators.
This means that at least for initial contact, it is the remote peer This means that at least for initial contact, it is the remote peer
that needs to select which peer locator to try first. In the case of that needs to select which peer locator to try first. In the case of
shim6 this is performed by applying RFC 3484 address selection. shim6 this is performed by applying RFC 3484 address selection.
This is quite different than the common case of IPv4 multihoming This is quite different than the common case of IPv4 multihoming
where the site has a single IP address prefix, since in that case the where the site has a single IP address prefix, since in that case the
peer performs no destination address selection. peer performs no destination address selection.
Thus in "single prefix multihoming" the site, and in many cases its Thus in "single prefix multihoming" the site, and in many cases its
upstream ISPs, can use BGP to exert some control of the ingress used upstream ISPs, can use BGP to exert some control of the ingress path
to reach the site. This capability can't easily be recreated in used to reach the site. This capability can't easily be recreated in
"multiple prefix multihoming" such as shim6. "multiple prefix multihoming" such as shim6.
The protocol provides a placeholder, in the form of the Locator The protocol provides a placeholder, in the form of the Locator
Preferences option, which can be used by hosts to express priority Preferences option, which can be used by hosts to express priority
and weight values for each locator. This is intentionally made and weight values for each locator. This is intentionally made
identical to the DNS SRV [9] specification of priority and weight, so identical to the DNS SRV [9] specification of priority and weight, so
that DNS SRV records can be used for initial contact and the shim for that DNS SRV records can be used for initial contact and the shim for
failover, and they can use the same way to describe the preferences. failover, and they can use the same way to describe the preferences.
The format allows adding additional notions of "metrics" over time.
But the Locator Preference option is merely a place holder when it But the Locator Preference option is merely a place holder when it
comes to providing traffic engineering; in order to use this in a comes to providing traffic engineering; in order to use this in a
large site there would have to be a mechanism by which the host can large site there would have to be a mechanism by which the host can
find out what preference values to use, either statically (e.g., some find out what preference values to use, either statically (e.g., some
new DHCPv6 option) or dynamically. new DHCPv6 option) or dynamically.
Thus traffic engineering is listed as a possible extension in Thus traffic engineering is listed as a possible extension in
Appendix A. Appendix A.
2. Terminology 2. Terminology
skipping to change at page 15, line 9 skipping to change at page 15, line 9
CGA Parameter Data Structure (PDS) CGA Parameter Data Structure (PDS)
The information that CGA and HBA exchanges in The information that CGA and HBA exchanges in
order to inform the peer of how the interface ID order to inform the peer of how the interface ID
was computed. See [6]., [7]. was computed. See [6]., [7].
2.2. Notational Conventions 2.2. Notational Conventions
A, B, and C are hosts. X is a potentially malicious host. A, B, and C are hosts. X is a potentially malicious host.
FQDN(A) is the domain name for A. FQDN(A) is the Fully qualified Domain Name for A.
Ls(A) is the locator set for A, which consists of the locators L1(A), Ls(A) is the locator set for A, which consists of the locators L1(A),
L2(A), ... Ln(A). L2(A), ... Ln(A). The locator set in not ordered in any particular
way other than maybe what is returned by the DNS.
ULID(A) is an upper-layer ID for A. In this proposal, ULID(A) is ULID(A) is an upper-layer ID for A. In this proposal, ULID(A) is
always one member of A's locator set. always one member of A's locator set.
CT(X) is a context tag assigned by X. CT(X) is a context tag assigned by X.
This document also makes use of internal conceptual variables to This document also makes use of internal conceptual variables to
describe protocol behavior and external variables that an describe protocol behavior and external variables that an
implementation must allow system administrators to change. The implementation must allow system administrators to change. The
specific variable names, how their values change, and how their specific variable names, how their values change, and how their
skipping to change at page 16, line 12 skipping to change at page 16, line 12
consistent with that described in this document. See Section 6 for a consistent with that described in this document. See Section 6 for a
description of the conceptual data structures. description of the conceptual data structures.
3. Assumptions 3. Assumptions
The design intent is to ensure that the shim6 protocol is capable of The design intent is to ensure that the shim6 protocol is capable of
handling path failures independently of the number of IP addresses handling path failures independently of the number of IP addresses
(locators) available to the two communicating hosts, and (locators) available to the two communicating hosts, and
independently of which host detects the failure condition. independently of which host detects the failure condition.
In the case when host A and host B have an active shim6 state, with Consider, for example, the case in which both A and B have active
host A having only one locator and host B having multiple locators, shim6 state and where A has only one locator while B has multiple
it might be that host B is trying to send a packet to host A, and has locators. In this case, it might be that B is trying to send a
detected a failure condition with the current locator pair. As host packet to A, and has detected a failure condition with the current
B has multiple locators it presumably has multiple ISPs. In this locator pair. Since B has multiple locators it presumably has
case there are probably alternate egress paths for host B to be able multiple ISPs, and consequently likely has alternate egress paths
to try to reach A, but B can not vary the destination address (host A toward A. However, B cannot vary the destination address (i.e., A's
locator) to select such alternate paths, since A has only one locator), since A has only one locator.
locator.
This leads to the assumption that a host should be able to cause The above scenario leads to the assumption that a host should be able
different egress paths from its site to be used. The most reasonable to cause different egress paths from its site to be used. The most
approach to accomplish this is to have the host use different source reasonable approach to accomplish this is to have the host use
addresses and have the source address affect the selection of the different source addresses and have the source address affect the
site egress. The details of how this can be accomplished is beyond selection of the site egress. The details of how this can be
the scope of this document, but without this capability the ability accomplished is beyond the scope of this document, but without this
of the shim to try different "paths" by trying different locator capability the ability of the shim to try different "paths" by trying
pairs will have limited utility. different locator pairs will have limited utility.
The above assumption applies whether or not the ISPs perform ingress The above assumption applies whether or not the ISPs perform ingress
filtering. filtering.
In addition, when the site's ISPs perform ingress filtering based on In addition, when the site's ISPs perform ingress filtering based on
packet source addresses, shim6 assumes that packets sent with packet source addresses, shim6 assumes that packets sent with
different source and destination combinations have a reasonable different source and destination combinations have a reasonable
chance of making it through the relevant ISP's ingress filters. This chance of making it through the relevant ISP's ingress filters. This
can be accomplished in several ways (all outside the scope of this can be accomplished in several ways (all outside the scope of this
document), such as having the ISPs relax there ingress filters, or document), such as having the ISPs relax there ingress filters, or
skipping to change at page 17, line 10 skipping to change at page 17, line 10
The shim6 approach assumes that there are no IPv6-to-IPv6 NATs on the The shim6 approach assumes that there are no IPv6-to-IPv6 NATs on the
paths, i.e., that the two ends can exchange their own notion of their paths, i.e., that the two ends can exchange their own notion of their
IPv6 addresses and that those addresses will also make sense to their IPv6 addresses and that those addresses will also make sense to their
peer. peer.
4. Protocol Overview 4. Protocol Overview
The shim6 protocol operates in several phases over time. The The shim6 protocol operates in several phases over time. The
following sequence illustrates the concepts: following sequence illustrates the concepts:
o An application on host A decides to contact B using some upper- o An application on host A decides to contact an application on host
layer protocol. This results in the ULP on A sending packets to B using some upper-layer protocol. This results in the ULP on
B. We call this the initial contact. Assuming the IP addresses host A sending packets to host B. We call this the initial
selected by Default Address Selection [12] and its extensions [13] contact. Assuming the IP addresses selected by Default Address
work, then there is no action by the shim at this point in time. Selection [12] and its extensions [13] work, then there is no
Any shim context establishment can be deferred until later. action by the shim at this point in time. Any shim context
establishment can be deferred until later.
o Some heuristic on A or B (or both) determine that it is o Some heuristic on A or B (or both) determine that it is
appropriate to pay the shim6 overhead to make this host-to-host appropriate to pay the shim6 overhead to make this host-to-host
communication robust against locator failures. For instance, this communication robust against locator failures. For instance, this
heuristic might be that more than 50 packets have been sent or heuristic might be that more than 50 packets have been sent or
received, or a timer expiration while active packet exchange is in received, or a timer expiration while active packet exchange is in
place. This makes the shim initiate the 4-way context place. This makes the shim initiate the 4-way context
establishment exchange. establishment exchange.
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
skipping to change at page 18, line 25 skipping to change at page 18, line 25
o The shim (un)reachability detection will monitor the new locator o The shim (un)reachability detection will monitor the new locator
pair as it monitored the original locator pair, so that subsequent pair as it monitored the original locator pair, so that subsequent
failures can be detected. failures can be detected.
o In addition to failures detected based on end-to-end observations, o In addition to failures detected based on end-to-end observations,
one endpoint might know for certain that one or more of its one endpoint might know for certain that one or more of its
locators is not working. For instance, the network interface locators is not working. For instance, the network interface
might have failed or gone down (at layer 2), or an IPv6 address might have failed or gone down (at layer 2), or an IPv6 address
might have become deprecated or invalid. In such cases the host might have become deprecated or invalid. In such cases the host
can signal its peer that this address is no longer recommended to can signal its peer that this address is no longer recommended to
try. Thus this triggers something similar to a failure handling try. This triggers something similar to a failure handling and a
in that a new, working locator pair must be found. new working locator pair must be found.
The protocol also has the ability to express other forms of The protocol also has the ability to express other forms of
locator preferences. A change in any preferences can be signaled locator preferences. A change in any preferences can be signaled
to the peer, which will made the peer record the new preferences. to the peer, which will have made the peer record the new
A change in the preferences might optionally make the peer want to preferences. A change in the preferences might optionally make
use a different locator pair. If it makes this decision, it the peer want to use a different locator pair. In this case, the
follows the same locator switching procedure as after a failure peer follows the same locator switching procedure as after a
(by verifying that its peer is indeed present at the alternate failure (by verifying that its peer is indeed present at the
locator, etc). alternate locator, etc).
o When the shim thinks that the context state is no longer used, it o When the shim thinks that the context state is no longer used, it
can garbage collect the state; there is no coordination necessary can garbage collect the state; there is no coordination necessary
with the peer host before the state is removed. There is a with the peer host before the state is removed. There is a
recovery message defined to be able to signal when there is no recovery message defined to be able to signal when there is no
context state, which can be used to detect and recover from both context state, which can be used to detect and recover from both
premature garbage collection, as well as complete state loss premature garbage collection, as well as complete state loss
(crash and reboot) of a peer. (crash and reboot) of a peer.
The exact mechanism to determine when the context state is no The exact mechanism to determine when the context state is no
longer used is implementation dependent. An implementation might longer used is implementation dependent. For example, an
use the existence of ULP state (where known to the implementation) implementation might use the existence of ULP state (where known
as an indication that the state is still used, combined with a to the implementation) as an indication that the state is still
timer (to handle ULP state that might not be known to the shim used, combined with a timer (to handle ULP state that might not be
sub-layer) to determine when the state is likely to no longer be known to the shim sub-layer) to determine when the state is likely
used. to no longer be used.
NOTE: The ULP packets in shim6 can be carried completely unmodified NOTE: The ULP packets in shim6 can be carried completely unmodified
as long as the ULID pair is used as the locator pair. After a switch as long as the ULID pair is used as the locator pair. After a switch
to a different locator pair the packets are "tagged" with a shim6 to a different locator pair the packets are "tagged" with a shim6
extension header, so that the receiver can always determine the extension header, so that the receiver can always determine the
context to which they belong. This is accomplished by including an context to which they belong. This is accomplished by including an
8-octet shim6 Payload Extension header before the (extension) headers 8-octet shim6 Payload Extension header before the (extension) headers
that are processed by the IP endpoint sublayer and ULPs. If that are processed by the IP endpoint sublayer and ULPs. If
subsequently the original ULIDs are selected as the active locator subsequently the original ULIDs are selected as the active locator
pair then the tagging of packets with the shim6 extension header can pair then the tagging of packets with the shim6 extension header is
also be stopped. no longer necesary.
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, most to allocate a context tag, and once the context is established, most
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> have to uniquely identify one ULID, local ULID, local context tag> have to uniquely identify one
context. But since the Payload extension headers are demultiplexed context. But since the Payload extension headers are demultiplexed
without looking at the locators in the packet, the receiver will need without looking at the locators in the packet, the receiver will need
to allocate context tags that are unique for all its contexts. The to allocate context tags that are unique for all its contexts. The
context tag is a 47-bit number (the largest which can fit in an context tag is a 47-bit number (the largest which can fit in an
8-octet extension header). 8-octet extension header).
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
is currently proposed in this document assumes that the receiver can assumes that the receiver can tell the packets that need locator
tell the packets that need locator rewriting, even after it has lost rewriting, even after it has lost all state (e.g., due to a crash
all state (e.g., due to a crash followed by a reboot). This is followed by a reboot). This is achieved because after a rehoming
achieved because after a rehoming event the packets that need event the packets that need receive-side rewriting, carry the Payload
receive-side rewriting, carry the Payload extension header. extension header.
4.2. Context Forking 4.2. Context Forking
It has been asserted that it will be important for future ULPs, in It has been asserted that it will be important for future ULPs, in
particular, future transport protocols, to be able to control which particular, future transport protocols, to be able to control which
locator pairs are used for different communication. For instance, locator pairs are used for different communication. For instance,
host A and host B might communicate using both VoIP traffic and ftp host A and host B might communicate using both VoIP traffic and ftp
traffic, and those communications might benefit from using different traffic, and those communications might benefit from using different
locator pairs. However, the fundamental shim6 mechanism uses a locator pairs. However, the basic shim6 mechanism uses a single
single current locator pair for each context, thus a single context current locator pair for each context, thus a single context cannot
can not accomplish this. accomplish this.
For this reason, the shim6 protocol supports the notion of context For this reason, the shim6 protocol supports the notion of context
forking. This is a mechanism by which a ULP can specify (using some forking. This is a mechanism by which a ULP can specify (using some
API not yet defined) that a context for e.g., the ULID pair <A1, B2> API not yet defined) that a context for e.g., the ULID pair <A1, B2>
should be forked into two contexts. In this case the forked-off should be forked into two contexts. In this case the forked-off
context will be assigned a non-zero Forked Instance Identifier, while context will be assigned a non-zero Forked Instance Identifier, while
the default context has FII zero. the default context has FII zero.
The Forked Instance Identifier is a 32-bit identifier which has no The Forked Instance Identifier (FII) is a 32-bit identifier which has
semantics in the protocol other then being part of the tuple which no semantics in the protocol other then being part of the tuple which
identifies the context. The hosts can allocate FIIs e.g., as identifies the context. For example, a host migth allocate FIIs as
sequential numbers for any given ULID pair. sequential numbers for any given ULID pair.
No other special considerations are needed in the shim6 protocol to No other special considerations are needed in the shim6 protocol to
handle forked contexts. handle forked contexts.
Note that forking as specified does NOT allow A to be able to tell B Note that forking as specified does NOT allow A to be able to tell B
that certain traffic (a 5-tuple?) should be forked for the reverse that certain traffic (a 5-tuple?) should be forked for the reverse
direction. The shim6 forking mechanism as specified applies only to direction. The shim6 forking mechanism as specified applies only to
the sending of ULP packets. If some ULP wants to fork for both the sending of ULP packets. If some ULP wants to fork for both
directions, it is up to the ULP to set this up, and then instruct the directions, it is up to the ULP to set this up, and then instruct the
skipping to change at page 21, line 49 skipping to change at page 21, line 49
dynamic. For this reason there is a Update Request and Update dynamic. For this reason there is a Update Request and Update
Acknowledgement messages, and a Locator List option. Acknowledgement messages, and a Locator List option.
Even when the list of locators is fixed, a host might determine that Even when the list of locators is fixed, a host might determine that
some preferences might have changed. For instance, it might some preferences might have changed. For instance, it might
determine that there is a locally visible failure that implies that determine that there is a locally visible failure that implies that
some locator(s) are no longer usable. This uses a Locator some locator(s) are no longer usable. This uses a Locator
Preferences option in the Update Request message. Preferences option in the Update Request message.
The mechanism for (un)reachability detection is called Forced The mechanism for (un)reachability detection is called Forced
Bidirectional Communication (FBD). The FBD approach uses a Keepalive Bidirectional Communication (FBD). FBD uses a Keepalive message
message, which is sent when a host has received packets from the which is sent when a host has received packets from its peer but has
peer, but the ULP has not given the host an opportunity to send any not yet sent any packets from its ULP to the peer. The message type
packet to the peer. The message type is reserved in this document, is reserved in this document, but the message format and processing
but the message format and processing rules are specified in [8]. rules are specified in [8].
In addition, when the context is established and there is a failure In addition, when the context is established and there is a
there needs to be a way to probe the set of locator pairs to subsequent failure there needs to be a way to probe the set of
efficiently find a working pair. This document reserves an Probe locator pairs to efficiently find a working pair. This document
message type, with the packet format and processing rules specified reserves an Probe message type, with the packet format and processing
in [8]. rules specified in [8].
The above probe and keepalive messages assume we have an established The above probe and keepalive messages assume we have an established
ULID-pair context. However, communication might fail during the ULID-pair context. However, communication might fail during the
initial contact (that is, when the application or transport protocol initial contact (that is, when the application or transport protocol
is trying to setup some communication). This is handled using the is trying to setup some communication). This is handled using the
mechanisms in the ULP to try different address pairs as specified in mechanisms in the ULP to try different address pairs as specified in
[12] [13]. In the future versions of the protocol, and with a richer [12] [13]. In the future versions of the protocol, and with a richer
API between the ULP and the shim, the shim might be help optimize API between the ULP and the shim, the shim might be help optimize
discovering a working locator pair during initial contact. This is discovering a working locator pair during initial contact. This is
for further study. for further study.
4.6. Extension Header Order 4.6. Extension Header Order
Since the shim is placed between the IP endpoint sub-layer and the IP Since the shim is placed between the IP endpoint sub-layer and the IP
routing sub-layer in the host, the shim header will be placed before routing sub-layer, the shim header will be placed before any endpoint
any endpoint extension headers (fragmentation headers, destination extension headers (fragmentation headers, destination options header,
options header, AH, ESP), but after any routing related headers (hop- AH, ESP), but after any routing related headers (hop-by-hop
by-hop extensions header, routing header, a destinations options extensions header, routing header, a destinations options header
header which precedes a routing header). When tunneling is used, which precedes a routing header). When tunneling is used, whether
whether IP-in-IP tunneling or the special form of tunneling that IP-in-IP tunneling or the special form of tunneling that Mobile IPv6
Mobile IPv6 uses (with Home Address Options and Routing header type uses (with Home Address Options and Routing header type 2), there is
2), there is a choice whether the shim applies inside the tunnel or a choice whether the shim applies inside the tunnel or outside the
outside the tunnel, which affects the location of the shim6 header. tunnel, which affects the location of the shim6 header.
In most cases IP-in-IP tunnels are used as a routing technique, thus In most cases IP-in-IP tunnels are used as a routing technique, thus
it makes sense to apply them on the locators which means that the it makes sense to apply them on the locators which means that the
sender would insert the shim6 header after any IP-in-IP sender would insert the shim6 header after any IP-in-IP
encapsulation; this is what occurs naturally when routers apply IP- encapsulation; this is what occurs naturally when routers apply IP-
in-IP encapsulation. Thus the packets would have: in-IP encapsulation. Thus the packets would have:
o Outer IP header o Outer IP header
o Inner IP header o Inner IP header
o Shim6 extension header (if needed> o Shim6 extension header (if needed)
o ULP o ULP
But the shim can also be used to create "shimmed tunnels" i.e., where But the shim can also be used to create "shimmed tunnels" i.e., where
an IP-in-IP tunnel uses the shim to be able to switch the tunnel an IP-in-IP tunnel uses the shim to be able to switch the tunnel
endpoint addresses between different locators. In such a case the endpoint addresses between different locators. In such a case the
packets would have: packets would have:
o Outer IP header o Outer IP header
o Shim6 extension header (if needed> o Shim6 extension header (if needed)
o Inner IP header o Inner IP header
o ULP o ULP
In any case, the receiver behavior is well-defined; a receiver In any case, the receiver behavior is well-defined; a receiver
processes the extension headers in order. However, the precise processes the extension headers in order. However, the precise
interaction between Mobile IPv6 and shim6 is for further study, but interaction between Mobile IPv6 and shim6 is for further study, but
it might make sense to have Mobile IPv6 operate on locators as well, it might make sense to have Mobile IPv6 operate on locators as well,
meaning that the shim would be layered on top of the MIPv6 mechanism. meaning that the shim would be layered on top of the MIPv6 mechanism.
skipping to change at page 45, line 45 skipping to change at page 45, line 45
Padding: Padding, 0-7 bytes, added if needed. See Padding: Padding, 0-7 bytes, added if needed. See
Section 5.14. Section 5.14.
When the Element length equals one, then the element consists of only When the Element length equals one, then the element consists of only
a one octet flags field. The currently defined set of flags are: a one octet flags field. The currently defined set of flags are:
BROKEN: 0x01 BROKEN: 0x01
TEMPORARY: 0x02 TEMPORARY: 0x02
The intent of TEMPORARY is to allow the distinction between more The intent of the BROKEN flag is to inform the peer that a given
stable addresses and less stable addresses when shim6 is combined locator is known to be not working. The intent of TEMPORARY is to
with IP mobility, when we might have more stable home locators, and allow the distinction between more stable addresses and less stable
less stable care-of-locators. addresses when shim6 is combined with IP mobility, when we might have
more stable home locators, and less stable care-of-locators.
When the Element length equals two, then the element consists of a 1 When the Element length equals two, then 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, then the element consists of a When the Element length equals three, then the element consists of a
1 octet flags field followed by a 1 octet priority field, and a 1 1 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 octet weight field. The weight has the same semantics as the weight
in DNS SRV records. in DNS SRV records.
skipping to change at page 62, line 8 skipping to change at page 62, line 8
7.10.1. Generating the R1 Validator 7.10.1. Generating the R1 Validator
One way for the responder to properly generate validators is to One way for the responder to properly generate validators is to
maintain a single secret (S) and a running counter for the Responder maintain a single secret (S) and a running counter for the Responder
Nonce. Nonce.
In the case the validator is generated to be included in a R1 In the case the validator is generated to be included in a R1
message, for each I1 message. The responder can increase the message, for each I1 message. The responder can increase the
counter, use the counter value as the responder nonce, and use the counter, use the counter value as the responder nonce, and use the
following information as input to the one-way function: following information concatenated as input to the one-way function:
o The the secret S o The the secret S
o That Responder Nonce o That Responder Nonce
o The Initiator Context Tag from the I1 message o The Initiator Context Tag from the I1 message
o The ULIDs from the I1 message o The ULIDs from the I1 message
o The locators from the I1 message (strictly only needed if they are o The locators from the I1 message (strictly only needed if they are
skipping to change at page 68, line 5 skipping to change at page 68, line 5
7.17.1. Generating the R1bis Validator 7.17.1. Generating the R1bis Validator
One way for the responder to properly generate validators is to One way for the responder to properly generate validators is to
maintain a single secret (S) and a running counter for the Responder maintain a single secret (S) and a running counter for the Responder
Nonce. Nonce.
In the case the validator is generated to be included in a R1bis In the case the validator is generated to be included in a R1bis
message, for each received payload extension header or control message, for each received payload extension header or control
message, the responder can increase the counter, use the counter message, the responder can increase the counter, use the counter
value as the responder nonce, and use the following information as value as the responder nonce, and use the following information
input to the one-way function: concatenated as input to the one-way function:
o The the secret S o The the secret S
o That Responder Nonce o That Responder Nonce
o The Receiver Context tag included in the received packet o The Receiver Context tag included in the received packet
o The locators from the received packet o The locators from the received packet
and then the output of the hash function is used as the validator and then the output of the hash function is used as the validator
skipping to change at page 87, line 20 skipping to change at page 87, line 20
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. requires the attacker to create state, cosnuming his own resources
and also it provides an IPv6 address that the attacker was using.
o The context establishment messages use nonces to prevent replay o The context establishment messages use nonces to prevent replay
attacks, and to prevent off-path attackers from interfering with attacks, and to prevent off-path attackers from interfering with
the establishment. the establishment.
o Every control message of the shim6 protocol, past the context o Every control message of the shim6 protocol, past the context
establishment, carry the context tag assigned to the particular establishment, carry the context tag assigned to the particular
context. This implies that an attacker needs to discover that context. This implies that an attacker needs to discover that
context tag before being able to spoof any shim6 control message. context tag before being able to spoof any shim6 control message.
Such discovery probably requires to be along the path in order to Such discovery probably requires to be along the path in order to
skipping to change at page 91, line 10 skipping to change at page 91, line 10
| 13-16383 | Allocated using Standards action | | 13-16383 | Allocated using Standards action |
| | | | | |
| 16384-32767 | For Experimental use | | 16384-32767 | For Experimental use |
+-------------+----------------------------------+ +-------------+----------------------------------+
18. Acknowledgements 18. Acknowledgements
Over the years many people active in the multi6 and shim6 WGs have Over the years many people active in the multi6 and shim6 WGs have
contributed ideas a suggestions that are reflected in this contributed ideas a suggestions that are reflected in this
specification. Special thanks to the careful comments from Geoff specification. Special thanks to the careful comments from Geoff
Huston, Shinta Sugimoto and Pekka Savola on earlier versions of this Huston, Shinta Sugimoto, Pekka Savola, Dave Meyer, Deguang Le and Jim
draft. Bound on earlier versions of this draft.
Appendix A. Possible Protocol Extensions Appendix A. Possible Protocol Extensions
During the development of this protocol, several issues have been During the development of this protocol, several issues have been
brought up as important one to address, but are ones that do not need brought up as important one to address, but are ones that do not need
to be in the base protocol itself but can instead be done as to be in the base protocol itself but can instead be done as
extensions to the protocol. The key ones are: extensions to the protocol. The key ones are:
o As stated in the assumptions in Section 3, the in order for the o As stated in the assumptions in Section 3, the in order for the
shim6 protocol to be able to recover from a wide range of shim6 protocol to be able to recover from a wide range of
skipping to change at page 116, line 9 skipping to change at page 116, line 9
because premature garbage collection, but it does not prevents the because premature garbage collection, but it does not prevents the
same situations due to a crash and reboot of one of the involved same situations due to a crash and reboot of one of the involved
hosts. The result is that even if we went for a coordinated hosts. The result is that even if we went for a coordinated
approach, we would still need to deal with context confusion and approach, we would still need to deal with context confusion and
provide the means to detect and recover from this situations. provide the means to detect and recover from this situations.
Appendix E. Change Log Appendix E. Change Log
[RFC Editor: please remove this section] [RFC Editor: please remove this section]
The following changes have been made since draft-ietf-shim6-proto-05:
o Removed the possibility to keep on uding the ULID after a
renumbering event
o Editorial corrections resulting from Dave Meyer's and Jim Bound's
reviews.
The following changes have been made since draft-ietf-shim6-proto-04: The following changes have been made since draft-ietf-shim6-proto-04:
o Defined I1_RETRIES_MAX as 4. o Defined I1_RETRIES_MAX as 4.
o Added text in section 7.9 clarifying the no per context state is o Added text in section 7.9 clarifying the no per context state is
stored at the receiver in order to reply an I1 message. stored at the receiver in order to reply an I1 message.
o Added text in section 5 and in section 5.14 in particular, on o Added text in section 5 and in section 5.14 in particular, on
defining additional options (including critical and non critical defining additional options (including critical and non critical
options). options).
skipping to change at page 120, line 29 skipping to change at page 120, line 29
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[5] Conta, A. and S. Deering, "Internet Control Message Protocol [5] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6) (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998. Specification", RFC 2463, December 1998.
[6] Aura, T., "Cryptographically Generated Addresses (CGA)", [6] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
[7] Bagnulo, M., "Hash Based Addresses (HBA)", [7] Bagnulo, M., "Hash Based Addresses (HBA)",
draft-ietf-shim6-hba-01 (work in progress), October 2005. draft-ietf-shim6-hba-01 (work in progress), September 2006.
[8] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair [8] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair
Exploration Protocol for IPv6 Multihoming", Exploration Protocol for IPv6 Multihoming",
draft-ietf-shim6-failure-detection-03 (work in progress), draft-ietf-shim6-failure-detection-06 (work in progress),
December 2005. September 2006.
19.2. Informative References 19.2. Informative References
[9] 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.
[10] 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.
skipping to change at page 121, line 36 skipping to change at page 121, line 36
[20] Huitema, C., "Ingress filtering compatibility for IPv6 [20] Huitema, C., "Ingress filtering compatibility for IPv6
multihomed sites", draft-huitema-shim6-ingress-filtering-00 multihomed sites", draft-huitema-shim6-ingress-filtering-00
(work in progress), September 2005. (work in progress), September 2005.
[21] Bagnulo, M. and E. Nordmark, "SHIM - MIPv6 Interaction", [21] Bagnulo, M. and E. Nordmark, "SHIM - MIPv6 Interaction",
draft-bagnulo-shim6-mip-00 (work in progress), July 2005. draft-bagnulo-shim6-mip-00 (work in progress), July 2005.
[22] Nordmark, E., "Shim6 Application Referral Issues", [22] Nordmark, E., "Shim6 Application Referral Issues",
draft-ietf-shim6-app-refer-00 (work in progress), July 2005. draft-ietf-shim6-app-refer-00 (work in progress), July 2005.
[23] Abley, J., "Shim6 Applicability Statement", [23] Bagnulo, M. and J. Abley, "Applicability Statement for the
draft-ietf-shim6-applicability-00 (work in progress), Level 3 Multihoming Shim Protocol (Shim6)",
July 2005. draft-ietf-shim6-applicability-01 (work in progress),
June 2006.
[24] Huston, G., "Architectural Commentary on Site Multi-homing [24] Huston, G., "Architectural Commentary on Site Multi-homing
using a Level 3 Shim", draft-ietf-shim6-arch-00 (work in using a Level 3 Shim", draft-ietf-shim6-arch-00 (work in
progress), July 2005. progress), July 2005.
[25] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-05 [25] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-06
(work in progress), March 2006. (work in progress), June 2006.
[26] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", [26] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)",
draft-ietf-mobike-protocol-08 (work in progress), draft-ietf-mobike-protocol-08 (work in progress),
February 2006. February 2006.
Authors' Addresses Authors' Addresses
Erik Nordmark Erik Nordmark
Sun Microsystems Sun Microsystems
17 Network Circle 17 Network Circle
 End of changes. 49 change blocks. 
178 lines changed or deleted 180 lines changed or added

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