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/ |