draft-ietf-hip-multihoming-06.txt   draft-ietf-hip-multihoming-07.txt 
Network Working Group T. Henderson, Ed. Network Working Group T. Henderson, Ed.
Internet-Draft University of Washington Internet-Draft University of Washington
Intended status: Standards Track C. Vogt Intended status: Standards Track C. Vogt
Expires: January 23, 2016 J. Arkko Expires: August 3, 2016 J. Arkko
Ericsson Research NomadicLab Ericsson Research NomadicLab
July 22, 2015 January 31, 2016
Host Multihoming with the Host Identity Protocol Host Multihoming with the Host Identity Protocol
draft-ietf-hip-multihoming-06 draft-ietf-hip-multihoming-07
Abstract Abstract
This document defines host multihoming extensions to the Host This document defines host multihoming extensions to the Host
Identity Protocol (HIP), by leveraging protocol components defined Identity Protocol (HIP), by leveraging protocol components defined
for host mobility. for host mobility.
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 34 skipping to change at page 1, line 34
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 January 23, 2016. This Internet-Draft will expire on August 3, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
Table of Contents Table of Contents
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 2 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3
3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Host Multihoming . . . . . . . . . . . . . . . . . . . . 5 4.1. Host Multihoming . . . . . . . . . . . . . . . . . . . . 5
4.2. Site Multihoming . . . . . . . . . . . . . . . . . . . . 6 4.2. Site Multihoming . . . . . . . . . . . . . . . . . . . . 6
4.3. Dual host multihoming . . . . . . . . . . . . . . . . . . 7 4.3. Dual host multihoming . . . . . . . . . . . . . . . . . . 7
4.4. Combined Mobility and Multihoming . . . . . . . . . . . . 8 4.4. Combined Mobility and Multihoming . . . . . . . . . . . . 7
4.5. Initiating the Protocol in R1 or I2 . . . . . . . . . . . 8 4.5. Initiating the Protocol in R1 or I2 . . . . . . . . . . . 8
4.6. Using LOCATOR_SETs across Addressing Realms . . . . . . . 9 4.6. Using LOCATOR_SETs across Addressing Realms . . . . . . . 9
5. Other Considerations . . . . . . . . . . . . . . . . . . . . 9 5. Other Considerations . . . . . . . . . . . . . . . . . . . . 9
5.1. Address Verification . . . . . . . . . . . . . . . . . . 9 5.1. Address Verification . . . . . . . . . . . . . . . . . . 9
5.2. Preferred Locator . . . . . . . . . . . . . . . . . . . . 10 5.2. Preferred Locator . . . . . . . . . . . . . . . . . . . . 10
5.3. Interaction with Security Associations . . . . . . . . . 10 5.3. Interaction with Security Associations . . . . . . . . . 10
6. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 12 6. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 12 6.1. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 12
6.2. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 14 6.2. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 14
6.3. Verifying Address Reachability . . . . . . . . . . . . . 16 6.3. Verifying Address Reachability . . . . . . . . . . . . . 16
6.4. Changing the Preferred Locator . . . . . . . . . . . . . 16 6.4. Changing the Preferred Locator . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 17 9. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative references . . . . . . . . . . . . . . . . . . 17 10.1. Normative references . . . . . . . . . . . . . . . . . . 17
10.2. Informative references . . . . . . . . . . . . . . . . . 18 10.2. Informative references . . . . . . . . . . . . . . . . . 18
Appendix A. Document Revision History . . . . . . . . . . . . . 19 Appendix A. Document Revision History . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction and Scope 1. Introduction and Scope
The Host Identity Protocol [I-D.ietf-hip-rfc4423-bis] (HIP) supports The Host Identity Protocol [RFC7401] (HIP) supports an architecture
an architecture that decouples the transport layer (TCP, UDP, etc.) that decouples the transport layer (TCP, UDP, etc.) from the
from the internetworking layer (IPv4 and IPv6) by using public/ internetworking layer (IPv4 and IPv6) by using public/private key
private key pairs, instead of IP addresses, as host identities. When pairs, instead of IP addresses, as host identities. When a host uses
a host uses HIP, the overlying protocol sublayers (e.g., transport HIP, the overlying protocol sublayers (e.g., transport layer sockets
layer sockets and Encapsulating Security Payload (ESP) Security and Encapsulating Security Payload (ESP) Security Associations (SAs))
Associations (SAs)) are instead bound to representations of these are instead bound to representations of these host identities, and
host identities, and the IP addresses are only used for packet the IP addresses are only used for packet forwarding. However, each
forwarding. However, each host must also know at least one IP host must also know at least one IP address at which its peers are
address at which its peers are reachable. Initially, these IP reachable. Initially, these IP addresses are the ones used during
addresses are the ones used during the HIP base exchange [RFC7401]. the HIP base exchange.
One consequence of such a decoupling is that new solutions to One consequence of such a decoupling is that new solutions to
network-layer mobility and host multihoming are possible. Basic host network-layer mobility and host multihoming are possible. Basic host
mobility is defined in [I-D.ietf-hip-rfc5206-bis] and covers the case mobility is defined in [I-D.ietf-hip-rfc5206-bis] and covers the case
in which a host has a single address and changes its network point- in which a host has a single address and changes its network point-
of-attachment while desiring to preserve the HIP-enabled security of-attachment while desiring to preserve the HIP-enabled security
association. Host multihoming is somewhat of a dual case to host association. Host multihoming is somewhat of a dual case to host
mobility, in that a host may simultaneously have more than one mobility, in that a host may simultaneously have more than one
network point-of-attachment. There are potentially many variations network point-of-attachment. There are potentially many variations
of host multihoming possible. The scope of this document encompasses of host multihoming possible. The scope of this document encompasses
skipping to change at page 3, line 33 skipping to change at page 3, line 34
Another variation of multihoming that has been heavily studied is Another variation of multihoming that has been heavily studied is
site multihoming. Solutions for site multihoming in IPv6 networks site multihoming. Solutions for site multihoming in IPv6 networks
have been specified by the IETF shim6 working group. The shim6 have been specified by the IETF shim6 working group. The shim6
protocol [RFC5533] bears many architectural similarities to HIP but protocol [RFC5533] bears many architectural similarities to HIP but
there are differences in the security model and in the protocol. there are differences in the security model and in the protocol.
While HIP can potentially be used with transports other than the ESP While HIP can potentially be used with transports other than the ESP
transport format [RFC7402], this document largely assumes the use of transport format [RFC7402], this document largely assumes the use of
ESP and leaves other transport formats for further study. ESP and leaves other transport formats for further study.
There are a number of situations where the simple end-to-end Finally, making underlying IP multihoming transparent to the
readdressing functionality defined herein is not sufficient. These transport layer has implications on the proper response of transport
include the initial reachability of a multihomed host, location congestion control, path MTU selection, and Quality of Service (QoS).
privacy, simultaneous mobility of both hosts, and some modes of NAT Transport-layer mobility triggers, and the proper transport response
traversal. In these situations, there is a need for some helper to a HIP multihoming address change, are outside the scope of this
functionality in the network, such as a HIP rendezvous server document.
[I-D.ietf-hip-rfc5204-bis]. Such functionality is out of the scope
of this document. Finally, making underlying IP multihoming
transparent to the transport layer has implications on the proper
response of transport congestion control, path MTU selection, and
Quality of Service (QoS). Transport-layer mobility triggers, and the
proper transport response to a HIP multihoming address change, are
outside the scope of this document.
2. Terminology and Conventions 2. Terminology and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
The following terms used in this document are defined in The following terms used in this document are defined in
[I-D.ietf-hip-rfc5206-bis]: LOCATOR_SET, Locator, Address, Preferred [I-D.ietf-hip-rfc5206-bis]: LOCATOR_SET, Locator, Address, Preferred
locator, and Credit Based Authorization. locator, and Credit Based Authorization.
skipping to change at page 18, line 6 skipping to change at page 18, line 6
10. References 10. References
10.1. Normative references 10.1. Normative references
[I-D.ietf-hip-rfc5206-bis] [I-D.ietf-hip-rfc5206-bis]
Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with
the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-09 the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-09
(work in progress), July 2015. (work in progress), July 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3484] Draves, R., "Default Address Selection for Internet [RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, DOI 10.17487/ Protocol version 6 (IPv6)", RFC 3484,
RFC3484, February 2003, DOI 10.17487/RFC3484, February 2003,
<http://www.rfc-editor.org/info/rfc3484>. <http://www.rfc-editor.org/info/rfc3484>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC Henderson, "Host Identity Protocol Version 2 (HIPv2)",
7401, DOI 10.17487/RFC7401, April 2015, RFC 7401, DOI 10.17487/RFC7401, April 2015,
<http://www.rfc-editor.org/info/rfc7401>. <http://www.rfc-editor.org/info/rfc7401>.
[RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the
Encapsulating Security Payload (ESP) Transport Format with Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", RFC 7402, DOI 10.17487/ the Host Identity Protocol (HIP)", RFC 7402,
RFC7402, April 2015, DOI 10.17487/RFC7402, April 2015,
<http://www.rfc-editor.org/info/rfc7402>. <http://www.rfc-editor.org/info/rfc7402>.
10.2. Informative references 10.2. Informative references
[I-D.ietf-hip-rfc4423-bis]
Moskowitz, R. and M. Komu, "Host Identity Protocol
Architecture", draft-ietf-hip-rfc4423-bis-12 (work in
progress), June 2015.
[I-D.ietf-hip-rfc5204-bis] [I-D.ietf-hip-rfc5204-bis]
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", draft-ietf-hip-rfc5204-bis-06 (work Rendezvous Extension", draft-ietf-hip-rfc5204-bis-07 (work
in progress), June 2015. in progress), December 2015.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533,
June 2009, <http://www.rfc-editor.org/info/rfc5533>. June 2009, <http://www.rfc-editor.org/info/rfc5533>.
Appendix A. Document Revision History Appendix A. Document Revision History
To be removed upon publication To be removed upon publication
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
skipping to change at page 19, line 28 skipping to change at page 19, line 28
| | | | | |
| draft-03 | Document refresh; no other changes. | | draft-03 | Document refresh; no other changes. |
| | | | | |
| draft-04 | Document refresh; no other changes. | | draft-04 | Document refresh; no other changes. |
| | | | | |
| draft-05 | Move remaining multihoming material from RFC5206-bis | | draft-05 | Move remaining multihoming material from RFC5206-bis |
| | to this document | | | to this document |
| | | | | |
| | Update lingering references to LOCATOR parameter to | | | Update lingering references to LOCATOR parameter to |
| | LOCATOR_SET | | | LOCATOR_SET |
| | |
| draft-06 | Document refresh with updated references. |
| | |
| draft-07 | Document refresh; no other changes. |
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
Authors' Addresses Authors' Addresses
Thomas R. Henderson (editor) Thomas R. Henderson (editor)
University of Washington University of Washington
Campus Box 352500 Campus Box 352500
Seattle, WA Seattle, WA
USA USA
 End of changes. 16 change blocks. 
45 lines changed or deleted 38 lines changed or added

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