draft-ietf-hip-multihoming-08.txt   draft-ietf-hip-multihoming-09.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: October 9, 2016 J. Arkko Expires: December 2, 2016 Independent
Ericsson Research NomadicLab J. Arkko
April 7, 2016 Ericsson
May 31, 2016
Host Multihoming with the Host Identity Protocol Host Multihoming with the Host Identity Protocol
draft-ietf-hip-multihoming-08 draft-ietf-hip-multihoming-09
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 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 October 9, 2016. This Internet-Draft will expire on December 2, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
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 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 . . . . . . . . . . . . . . . . . . . . . . . 3
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Multiple Addresses . . . . . . . . . . . . . . . . . . . 6 4.2. Multiple Addresses . . . . . . . . . . . . . . . . . . . 5
4.3. Multiple Security Associations . . . . . . . . . . . . . 6 4.3. Multiple Security Associations . . . . . . . . . . . . . 6
4.4. Host Multihoming for Fault Tolerance . . . . . . . . . . 7 4.4. Host Multihoming for Fault Tolerance . . . . . . . . . . 7
4.5. Host Multihoming for Load Balancing . . . . . . . . . . . 8 4.5. Host Multihoming for Load Balancing . . . . . . . . . . . 8
4.6. Site Multihoming . . . . . . . . . . . . . . . . . . . . 9 4.6. Site Multihoming . . . . . . . . . . . . . . . . . . . . 9
4.7. Dual Host Multihoming . . . . . . . . . . . . . . . . . . 10 4.7. Dual Host Multihoming . . . . . . . . . . . . . . . . . . 10
4.8. Combined Mobility and Multihoming . . . . . . . . . . . . 11 4.8. Combined Mobility and Multihoming . . . . . . . . . . . . 10
4.9. Initiating the Protocol in R1, I2, or R2 . . . . . . . . 11 4.9. Initiating the Protocol in R1, I2, or R2 . . . . . . . . 11
4.10. Using LOCATOR_SETs across Addressing Realms . . . . . . . 12 4.10. Using LOCATOR_SETs across Addressing Realms . . . . . . . 12
4.11. Interaction with Security Associations . . . . . . . . . 13 4.11. Interaction with Security Associations . . . . . . . . . 13
5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 13 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 13 5.1. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 13
5.2. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 15 5.2. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 15
5.3. Verifying Address Reachability . . . . . . . . . . . . . 17 5.3. Verifying Address Reachability . . . . . . . . . . . . . 17
5.4. Changing the Preferred Locator . . . . . . . . . . . . . 18 5.4. Changing the Preferred Locator . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 19 8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative references . . . . . . . . . . . . . . . . . . 19 9.1. Normative references . . . . . . . . . . . . . . . . . . 19
9.2. Informative references . . . . . . . . . . . . . . . . . 20 9.2. Informative references . . . . . . . . . . . . . . . . . 19
Appendix A. Document Revision History . . . . . . . . . . . . . 21 Appendix A. Document Revision History . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction and Scope 1. Introduction and Scope
The Host Identity Protocol [RFC7401] (HIP) supports an architecture The Host Identity Protocol [RFC7401] (HIP) supports an architecture
that decouples the transport layer (TCP, UDP, etc.) from the that decouples the transport layer (TCP, UDP, etc.) from the
internetworking layer (IPv4 and IPv6) by using public/private key internetworking layer (IPv4 and IPv6) by using public/private key
pairs, instead of IP addresses, as host identities. When a host uses pairs, instead of IP addresses, as host identities. When a host uses
HIP, the overlying protocol sublayers (e.g., transport layer sockets HIP, the overlying protocol sublayers (e.g., transport layer sockets
and Encapsulating Security Payload (ESP) Security Associations (SAs)) and Encapsulating Security Payload (ESP) Security Associations (SAs))
are instead bound to representations of these host identities, and are instead bound to representations of these host identities, and
skipping to change at page 4, line 28 skipping to change at page 4, line 20
LOCATOR_SET parameter defined in [I-D.ietf-hip-rfc5206-bis], a host LOCATOR_SET parameter defined in [I-D.ietf-hip-rfc5206-bis], a host
can inform its peers of additional (multiple) locators at which it can inform its peers of additional (multiple) locators at which it
can be reached. When multiple locators are available and announced can be reached. When multiple locators are available and announced
to the peer, a host can designate a particular locator as a to the peer, a host can designate a particular locator as a
"preferred" locator, meaning that the host prefers that its peer send "preferred" locator, meaning that the host prefers that its peer send
packets to the designated address before trying an alternative packets to the designated address before trying an alternative
address. Although this document defines a basic mechanism for address. Although this document defines a basic mechanism for
multihoming, it does not define all possible policies and procedures, multihoming, it does not define all possible policies and procedures,
such as which locators to choose when more than one is available, the such as which locators to choose when more than one is available, the
operation of simultaneous mobility and multihoming, source address operation of simultaneous mobility and multihoming, source address
selection policies (beyond those specified in [RFC3484]), and the selection policies (beyond those specified in [RFC6724]), and the
implications of multihoming on transport protocols. implications of multihoming on transport protocols.
4. Protocol Overview 4. Protocol Overview
In this section, we briefly introduce a number of usage scenarios for In this section, we briefly introduce a number of usage scenarios for
HIP multihoming. These scenarios assume that HIP is being used with HIP multihoming. These scenarios assume that HIP is being used with
the ESP transform [RFC7402], although other scenarios may be defined the ESP transform [RFC7402], although other scenarios may be defined
in the future. To understand these usage scenarios, the reader in the future. To understand these usage scenarios, the reader
should be at least minimally familiar with the HIP protocol should be at least minimally familiar with the HIP protocol
specification [RFC7401], the use of the ESP transport format specification [RFC7401], the use of the ESP transport format
skipping to change at page 19, line 25 skipping to change at page 19, line 13
Melen for many improvements to the document. Concepts from a paper Melen for many improvements to the document. Concepts from a paper
on host multihoming across address families, by Samu Varjonen, Miika on host multihoming across address families, by Samu Varjonen, Miika
Komu, and Andrei Gurtov, contributed to this revised version. Komu, and Andrei Gurtov, contributed to this revised version.
9. References 9. References
9.1. Normative references 9.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-10 the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-11
(work in progress), January 2016. (work in progress), May 2016.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/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 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
Protocol version 6 (IPv6)", RFC 3484, "Default Address Selection for Internet Protocol Version 6
DOI 10.17487/RFC3484, February 2003, (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<http://www.rfc-editor.org/info/rfc3484>. <http://www.rfc-editor.org/info/rfc6724>.
[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)", Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 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, the Host Identity Protocol (HIP)", RFC 7402,
DOI 10.17487/RFC7402, April 2015, DOI 10.17487/RFC7402, April 2015,
skipping to change at page 21, line 41 skipping to change at page 20, line 41
| draft-07 | Document refresh; no other changes. | | draft-07 | Document refresh; no other changes. |
| | | | | |
| draft-08 | issues 3 and 11: Address complaints of complexity due | | draft-08 | issues 3 and 11: Address complaints of complexity due |
| | to full mesh of SAs for multihoming. | | | to full mesh of SAs for multihoming. |
| | | | | |
| | issue 5: Improve draft based on recommendations for | | | issue 5: Improve draft based on recommendations for |
| | cross-family handovers in paper by Varjonen et. al. | | | cross-family handovers in paper by Varjonen et. al. |
| | | | | |
| | issue 7: Clarify and distinguish between load | | | issue 7: Clarify and distinguish between load |
| | balancing and fault tolerance use cases. | | | balancing and fault tolerance use cases. |
| | |
| draft-09 | Update author affiliations, IPR boilerplate to |
| | trust200902, and one stale reference. |
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
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
EMail: tomhend@u.washington.edu EMail: tomhend@u.washington.edu
Christian Vogt Christian Vogt
Ericsson Research NomadicLab Independent
Hirsalantie 11 3473 North First Street
JORVAS FIN-02420 San Jose, CA 95134
FINLAND USA
EMail: christian.vogt@ericsson.com EMail: mail@christianvogt.net
Jari Arkko Jari Arkko
Ericsson Research NomadicLab Ericsson
JORVAS FIN-02420 JORVAS FIN-02420
FINLAND FINLAND
Phone: +358 40 5079256 Phone: +358 40 5079256
EMail: jari.arkko@ericsson.com EMail: jari.arkko@piuha.net
 End of changes. 20 change blocks. 
39 lines changed or deleted 31 lines changed or added

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