< draft-ietf-shim6-applicability-07.txt   draft-ietf-shim6-applicability-08.txt >
shim6 Working Group J. Abley shim6 Working Group J. Abley
Internet-Draft Afilias Canada Internet-Draft ICANN
Intended status: Informational M. Bagnulo Intended status: Informational M. Bagnulo
Expires: March 24, 2011 A. Garcia-Martinez Expires: April 28, 2011 A. Garcia-Martinez
UC3M UC3M
September 20, 2010 October 25, 2010
Applicability Statement for the Level 3 Multihoming Shim Protocol Applicability Statement for the Level 3 Multihoming Shim Protocol
(Shim6) (Shim6)
draft-ietf-shim6-applicability-07 draft-ietf-shim6-applicability-08
Abstract Abstract
This document discusses the applicability of the Shim6 IPv6 protocol This document discusses the applicability of the Shim6 IPv6 protocol
and associated support protocols and mechanisms to provide site and associated support protocols and mechanisms to provide site
multihoming capabilities in IPv6. multihoming capabilities in IPv6.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on March 24, 2011. This Internet-Draft will expire on April 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 4 2. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 3
3. Address Configuration . . . . . . . . . . . . . . . . . . . . 6 3. Address Configuration . . . . . . . . . . . . . . . . . . . . 5
3.1. Protocol Version (IPv4 vs. IPv6) . . . . . . . . . . . . . 6 3.1. Protocol Version (IPv4 vs. IPv6) . . . . . . . . . . . . . 5
3.2. Prefix Lengths . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Prefix Lengths . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Address Generation . . . . . . . . . . . . . . . . . . . . 7 3.3. Address Generation . . . . . . . . . . . . . . . . . . . . 6
3.4. Use of CGA vs. HBA . . . . . . . . . . . . . . . . . . . . 7 3.4. Use of CGA vs. HBA . . . . . . . . . . . . . . . . . . . . 6
4. Shim6 and Ingress Filtering . . . . . . . . . . . . . . . . . 8 4. Shim6 and Ingress Filtering . . . . . . . . . . . . . . . . . 7
5. Shim6 Capabilities . . . . . . . . . . . . . . . . . . . . . . 10 5. Shim6 Capabilities . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Fault Tolerance . . . . . . . . . . . . . . . . . . . . . 10 5.1. Fault Tolerance . . . . . . . . . . . . . . . . . . . . . 9
5.1.1. Establishing Communications After an Outage . . . . . 10 5.1.1. Establishing Communications After an Outage . . . . . 9
5.1.2. Short-Lived Communications . . . . . . . . . . . . . . 10 5.1.2. Short-Lived Communications . . . . . . . . . . . . . . 9
5.1.3. Long-Lived Communications . . . . . . . . . . . . . . 11 5.1.3. Long-Lived Communications . . . . . . . . . . . . . . 10
5.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Traffic Engineering . . . . . . . . . . . . . . . . . . . 12 5.3. Traffic Engineering . . . . . . . . . . . . . . . . . . . 11
6. Application Considerations . . . . . . . . . . . . . . . . . . 12 6. Application Considerations . . . . . . . . . . . . . . . . . . 11
7. Interaction with Other Protocols . . . . . . . . . . . . . . . 13 7. Interaction with Other Protocols . . . . . . . . . . . . . . . 12
7.1. Shim6 and Mobile IPv6 . . . . . . . . . . . . . . . . . . 13 7.1. Shim6 and Mobile IPv6 . . . . . . . . . . . . . . . . . . 12
7.1.1. Multihomed Home Network . . . . . . . . . . . . . . . 13 7.1.1. Multihomed Home Network . . . . . . . . . . . . . . . 12
7.1.2. Shim6 Between the HA and the MN . . . . . . . . . . . 16 7.1.2. Shim6 Between the HA and the MN . . . . . . . . . . . 15
7.2. Shim6 and SEND . . . . . . . . . . . . . . . . . . . . . . 16 7.2. Shim6 and SEND . . . . . . . . . . . . . . . . . . . . . . 15
7.3. Shim6 and SCTP . . . . . . . . . . . . . . . . . . . . . . 17 7.3. Shim6 and SCTP . . . . . . . . . . . . . . . . . . . . . . 16
7.4. Shim6 and NEMO . . . . . . . . . . . . . . . . . . . . . . 17 7.4. Shim6 and NEMO . . . . . . . . . . . . . . . . . . . . . . 16
7.5. Shim6 and HIP . . . . . . . . . . . . . . . . . . . . . . 18 7.5. Shim6 and HIP . . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 19 8.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . . 22 12.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Site multihoming is an arrangement by which a site may use multiple Site multihoming is an arrangement by which a site may use multiple
paths to the rest of the Internet to provide better reliability for paths to the rest of the Internet to provide better reliability for
traffic passing in and out of the site than would be possible with a traffic passing in and out of the site than would be possible with a
single path. Some of the motivations for operators to multi-home single path. Some of the motivations for operators to multi-home
their network are described in [RFC3582]. their network are described in [RFC3582].
In IPv4, site multihoming is achieved by injecting into the global In IPv4, site multihoming is achieved by injecting into the global
skipping to change at page 5, line 51 skipping to change at page 4, line 51
multihomed site S can be reached through provider ISP[i] only, since multihomed site S can be reached through provider ISP[i] only, since
ISP[i] is solely responsible for advertising a covering prefix for ISP[i] is solely responsible for advertising a covering prefix for
P[i] to the rest of the Internet. P[i] to the rest of the Internet.
The use of locator L[i] on H hence causes inbound traffic towards H The use of locator L[i] on H hence causes inbound traffic towards H
to be routed through ISP[i]. Changing the locator from L[i] to L[j] to be routed through ISP[i]. Changing the locator from L[i] to L[j]
will have the effect of re-routing inbound traffic to H from ISP[i] will have the effect of re-routing inbound traffic to H from ISP[i]
to ISP[j]. This is the central mechanism by which the Shim6 protocol to ISP[j]. This is the central mechanism by which the Shim6 protocol
aims to provide multihoming functionality: by changing locators, host aims to provide multihoming functionality: by changing locators, host
H can change the upstream ISP used to route inbound packets towards H can change the upstream ISP used to route inbound packets towards
itself. Regarding to the outbound traffic to H, the path taken in itself. Regarding the outbound traffic to H, the path taken in this
this case depends on both the actual locator LR[j] chosen by R, and case depends on both the actual locator LR[j] chosen by R, and the
the administrative exit selection policy of site S. administrative exit selection policy of site S.
The Shim6 protocol has other potential applications beyond site The Shim6 protocol has other potential applications beyond site
multihoming. For example, since Shim6 is a host-based protocol, it multihoming. For example, since Shim6 is a host-based protocol, it
can also be used to support host multihoming. In this case, a can also be used to support host multihoming. In this case, a
failure in communication between a multihomed host and some other failure in communication between a multihomed host and some other
remote host might be repaired by selecting a locator associated with remote host might be repaired by selecting a locator associated with
a different interface. a different interface.
3. Address Configuration 3. Address Configuration
skipping to change at page 6, line 39 skipping to change at page 5, line 39
specified for IPv6 for use with IPv4 addresses might require protocol specified for IPv6 for use with IPv4 addresses might require protocol
modifications. modifications.
In addition, there are other factors to take into account when In addition, there are other factors to take into account when
considering the support of IPv4 addresses, in particular IPv4 considering the support of IPv4 addresses, in particular IPv4
locators. Using multiple IPv4 addresses in a single host in order to locators. Using multiple IPv4 addresses in a single host in order to
support Shim6 style of multihoming would result in an increased IPv4 support Shim6 style of multihoming would result in an increased IPv4
address consumption, which with the current rate of IPv4 addresses address consumption, which with the current rate of IPv4 addresses
would be problematic. Besides, Shim6 may suffer additional problems would be problematic. Besides, Shim6 may suffer additional problems
if locators become translated on the wire. Address translation is if locators become translated on the wire. Address translation is
more likely to involve IPv4 addresses. IPv4 addressed can be more likely to involve IPv4 addresses. IPv4 addresses can be
translated to other IPv4 addresses (for example, private IPv4 address translated to other IPv4 addresses (for example, private IPv4 address
into public IPv4 address and vice versa) or to/from IPv6 addresses into public IPv4 address and vice versa) or to/from IPv6 addresses
(for example, as defined by NAT64 (for example, as defined by NAT64
[I-D.ietf-behave-v6v4-xlate-stateful]). When address translation [I-D.ietf-behave-v6v4-xlate-stateful]). When address translation
occurs, a locator exchanged by Shim6 could be different to the occurs, a locator exchanged by Shim6 could be different to the
address needed to reach the corresponding host, either because the address needed to reach the corresponding host, either because the
translated version of the locator exchanged by Shim6 is not known or translated version of the locator exchanged by Shim6 is not known or
because the translation state does not exist any more in the because the translation state does not exist any more in the
translator device. Supporting these scenarios would require NAT translator device. Supporting these scenarios would require NAT
traversal mechanisms which are not defined yet and which would imply traversal mechanisms which are not defined yet and which would imply
skipping to change at page 8, line 41 skipping to change at page 7, line 41
networks with PA, and also for a Shim6 host in a multihomed network. networks with PA, and also for a Shim6 host in a multihomed network.
Note that this is also the case for other solutions supporting Note that this is also the case for other solutions supporting
multihoming, such as SCTP [RFC4960], HIP [RFC4423], etc. multihoming, such as SCTP [RFC4960], HIP [RFC4423], etc.
One solution to this problem is to make the providers aware of the One solution to this problem is to make the providers aware of the
alternative prefixes that can be used by a multihomed site, so that alternative prefixes that can be used by a multihomed site, so that
ingress filtering would not be applied to packets with source ingress filtering would not be applied to packets with source
addresses belonging to these prefixes. This may be possible in some addresses belonging to these prefixes. This may be possible in some
cases, but it cannot be assumed as the general case. cases, but it cannot be assumed as the general case.
[RFC3704] proposes that non-PI addresses should ensure that each [RFC3704] requires that sites using non-PI addresses should ensure
packet is delivered to the provider related with the prefix of its that each packet is delivered to the provider whose prefix matches
source address. To deliver packets to the appropriate outgoing ISP, its source address. To deliver packets to the appropriate outgoing
some routers of the site must consider source addresses in their ISP, some routers of the site must consider source addresses in their
forwarding decisions, in addition to the usual destination-based forwarding decisions, in addition to the usual destination-based
forwarding. These routers maintain as many parallel routing tables forwarding. These routers maintain as many parallel routing tables
as valid source prefixes are, and choose a route that is a function as there are valid source prefixes, and choose a route that is a
of both the source and the destination address. The way these function of both the source and the destination address. The way
routing tables are populated is out of the scope of this document. these routing tables are populated is out of the scope of this
document.
Site exit routers are required (at least) to be part of a single Site exit routers are required (at least) to be part of a single
connected source based routing domain: connected source based routing domain:
Multiple site exits Multiple site exits
| | | | | | | |
-----+-----+-----+-----+----- -----+-----+-----+-----+-----
( ) ( )
( Source based routing domain ) ( Source based routing domain )
( ) ( )
skipping to change at page 12, line 38 skipping to change at page 11, line 38
management [RFC5533] nor the failure detection and recovery [RFC5534] management [RFC5533] nor the failure detection and recovery [RFC5534]
functions require application awareness. functions require application awareness.
However, a specific API [I-D.ietf-shim6-multihome-shim-api] is However, a specific API [I-D.ietf-shim6-multihome-shim-api] is
developed for those applications which might require additional developed for those applications which might require additional
capabilities in ULID/locator management, such as the locator pair in capabilities in ULID/locator management, such as the locator pair in
use for a given context, or the set of local or remote locators use for a given context, or the set of local or remote locators
available for it. This API can also be used to disable Shim6 available for it. This API can also be used to disable Shim6
operation when required. operation when required.
It is worth to note that callbacks can benefit naturally from Shim6 It is worth noting that callbacks can benefit naturally from Shim6
support. In a callback, an application in B retrieves IP_A, the IP support. In a callback, an application in B retrieves IP_A, the IP
address of a peer A, and B uses IP_A to establish a new communication address of a peer A, and B uses IP_A to establish a new communication
with A. As long as the address exchanged, IP_A is the ULID for the with A. As long as the address exchanged, IP_A is the ULID for the
initial communication between A and B, and B uses the same address as initial communication between A and B, and B uses the same address as
in the initial communication, and this initial communication is alive in the initial communication, and this initial communication is alive
(or the context has not been deleted), the new communication could (or the context has not been deleted), the new communication could
use the locators exchanged by Shim6 for the first communication. In use the locators exchanged by Shim6 for the first communication. In
this case, communication could proceed even if the ULID of A is not this case, communication could proceed even if the ULID of A is not
reachable. reachable.
skipping to change at page 19, line 25 skipping to change at page 18, line 25
on-path attackers. On-path attackers are able to sniff and spoof on-path attackers. On-path attackers are able to sniff and spoof
packets in the current Internet, and they are able to do the same in packets in the current Internet, and they are able to do the same in
Shim6 communications (as long as the communication flows through the Shim6 communications (as long as the communication flows through the
path they are located on). So, summarizing, the Shim6 protocol does path they are located on). So, summarizing, the Shim6 protocol does
not provide data packet protection from on-path attackers. not provide data packet protection from on-path attackers.
However, the Shim6 protocol does use several security techniques. However, the Shim6 protocol does use several security techniques.
The goal of these security measures is to protect the Shim6 signaling The goal of these security measures is to protect the Shim6 signaling
protocol from new attacks resulting from the adoption of the Shim6 protocol from new attacks resulting from the adoption of the Shim6
protocol. In particular, the use of HBA/CGA prevents on-path and protocol. In particular, the use of HBA/CGA prevents on-path and
off-path attackers to introduce new locators in the locator set of a off-path attackers injecting new locators into the locator set of a
Shim6 context, preventing redirection attacks [RFC4218]. Moreover, Shim6 context, thus preventing redirection attacks [RFC4218].
the usage of probes before re-homing to a different locator as a Moreover, the usage of probes before re-homing to a different locator
destination address prevents flooding attacks from off-path as a destination address prevents flooding attacks from off-path
attackers. attackers.
In addition, the usage of a 4-way handshake for establishing the In addition, the usage of a 4-way handshake for establishing the
Shim6 context protects against DoS attacks, so hosts implementing the Shim6 context protects against DoS attacks, so hosts implementing the
Shim6 protocol should not be more vulnerable to DoS attacks than Shim6 protocol should not be more vulnerable to DoS attacks than
regular IPv6 hosts. regular IPv6 hosts.
Finally, many Shim6 signaling messages contain a Context Tag, meaning Finally, many Shim6 signaling messages contain a Context Tag, meaning
that only attackers that know the Context Tag can forge them. As a that only attackers that know the Context Tag can forge them. As a
consequence, only on-path attackers can generate false Shim6 consequence, only on-path attackers can generate false Shim6
skipping to change at page 22, line 32 skipping to change at page 21, line 32
Locator Pair Exploration Protocol for IPv6 Multihoming", Locator Pair Exploration Protocol for IPv6 Multihoming",
RFC 5534, June 2009. RFC 5534, June 2009.
[RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535,
June 2009. June 2009.
12.2. Informative References 12.2. Informative References
[I-D.ietf-csi-dhcpv6-cga-ps] [I-D.ietf-csi-dhcpv6-cga-ps]
Jiang, S., "DHCPv6 and CGA Interaction: Problem Jiang, S., "DHCPv6 and CGA Interaction: Problem
Statement", draft-ietf-csi-dhcpv6-cga-ps-04 (work in Statement", draft-ietf-csi-dhcpv6-cga-ps-06 (work in
progress), September 2010. progress), October 2010.
[I-D.nordmark-shim6-esd] [I-D.nordmark-shim6-esd]
Nordmark, E., "Extended Shim6 Design for ID/loc split and Nordmark, E., "Extended Shim6 Design for ID/loc split and
Traffic Engineering", draft-nordmark-shim6-esd-01 (work in Traffic Engineering", draft-nordmark-shim6-esd-01 (work in
progress), February 2008. progress), February 2008.
[RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the [RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the
Internet", RFC 3221, December 2001. Internet", RFC 3221, December 2001.
[RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-
skipping to change at page 23, line 12 skipping to change at page 22, line 12
[RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6
Multihoming Solutions", RFC 4218, October 2005. Multihoming Solutions", RFC 4218, October 2005.
[RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
Workshop on Routing and Addressing", RFC 4984, Workshop on Routing and Addressing", RFC 4984,
September 2007. September 2007.
Authors' Addresses Authors' Addresses
Joe Abley Joe Abley
Afilias Canada, Inc. ICANN
Suite 204 4676 Admiralty Way, Suite 330
4141 Yonge Street Marina del Rey, CA 90292
Toronto, Ontario M2P 2A8 USA
Canada
Phone: +1 416 673 4176 Phone: +1 519 670 9327
Email: jabley@ca.afilias.info Email: joe.abley@icann.org
URI: http://afilias.info/
Marcelo Bagnulo Marcelo Bagnulo
U. Carlos III de Madrid U. Carlos III de Madrid
Av. Universidad 30 Av. Universidad 30
Leganes, Madrid 28911 Leganes, Madrid 28911
Spain Spain
Phone: +34 91 6248814 Phone: +34 91 6248814
Email: marcelo@it.uc3m.es Email: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es/ URI: http://www.it.uc3m.es/
 End of changes. 16 change blocks. 
76 lines changed or deleted 63 lines changed or added

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