--- 1/draft-ietf-hip-multihoming-06.txt 2016-01-31 21:15:11.056461530 -0800 +++ 2/draft-ietf-hip-multihoming-07.txt 2016-01-31 21:15:11.112462926 -0800 @@ -1,20 +1,20 @@ Network Working Group T. Henderson, Ed. Internet-Draft University of Washington Intended status: Standards Track C. Vogt -Expires: January 23, 2016 J. Arkko +Expires: August 3, 2016 J. Arkko Ericsson Research NomadicLab - July 22, 2015 + January 31, 2016 Host Multihoming with the Host Identity Protocol - draft-ietf-hip-multihoming-06 + draft-ietf-hip-multihoming-07 Abstract This document defines host multihoming extensions to the Host Identity Protocol (HIP), by leveraging protocol components defined for host mobility. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -23,25 +23,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (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. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -61,53 +61,54 @@ Table of Contents 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 2 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Host Multihoming . . . . . . . . . . . . . . . . . . . . 5 4.2. Site Multihoming . . . . . . . . . . . . . . . . . . . . 6 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.6. Using LOCATOR_SETs across Addressing Realms . . . . . . . 9 5. Other Considerations . . . . . . . . . . . . . . . . . . . . 9 5.1. Address Verification . . . . . . . . . . . . . . . . . . 9 5.2. Preferred Locator . . . . . . . . . . . . . . . . . . . . 10 5.3. Interaction with Security Associations . . . . . . . . . 10 6. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 12 6.2. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 14 6.3. Verifying Address Reachability . . . . . . . . . . . . . 16 6.4. Changing the Preferred Locator . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative references . . . . . . . . . . . . . . . . . . 17 10.2. Informative references . . . . . . . . . . . . . . . . . 18 Appendix A. Document Revision History . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction and Scope - The Host Identity Protocol [I-D.ietf-hip-rfc4423-bis] (HIP) supports - an architecture that decouples the transport layer (TCP, UDP, etc.) - from the internetworking layer (IPv4 and IPv6) by using public/ - private key pairs, instead of IP addresses, as host identities. When - a host uses HIP, the overlying protocol sublayers (e.g., transport - layer sockets and Encapsulating Security Payload (ESP) Security - Associations (SAs)) are instead bound to representations of these - host identities, and the IP addresses are only used for packet - forwarding. However, each host must also know at least one IP - address at which its peers are reachable. Initially, these IP - addresses are the ones used during the HIP base exchange [RFC7401]. + The Host Identity Protocol [RFC7401] (HIP) supports an architecture + that decouples the transport layer (TCP, UDP, etc.) from the + internetworking layer (IPv4 and IPv6) by using public/private key + pairs, instead of IP addresses, as host identities. When a host uses + HIP, the overlying protocol sublayers (e.g., transport layer sockets + and Encapsulating Security Payload (ESP) Security Associations (SAs)) + are instead bound to representations of these host identities, and + the IP addresses are only used for packet forwarding. However, each + host must also know at least one IP address at which its peers are + reachable. Initially, these IP addresses are the ones used during + the HIP base exchange. One consequence of such a decoupling is that new solutions to network-layer mobility and host multihoming are possible. Basic host 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- of-attachment while desiring to preserve the HIP-enabled security association. Host multihoming is somewhat of a dual case to host mobility, in that a host may simultaneously have more than one network point-of-attachment. There are potentially many variations of host multihoming possible. The scope of this document encompasses @@ -117,33 +118,26 @@ Another variation of multihoming that has been heavily studied is site multihoming. Solutions for site multihoming in IPv6 networks have been specified by the IETF shim6 working group. The shim6 protocol [RFC5533] bears many architectural similarities to HIP but there are differences in the security model and in the protocol. While HIP can potentially be used with transports other than the ESP transport format [RFC7402], this document largely assumes the use of ESP and leaves other transport formats for further study. - There are a number of situations where the simple end-to-end - readdressing functionality defined herein is not sufficient. These - include the initial reachability of a multihomed host, location - privacy, simultaneous mobility of both hosts, and some modes of NAT - traversal. In these situations, there is a need for some helper - functionality in the network, such as a HIP rendezvous server - [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. + 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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The following terms used in this document are defined in [I-D.ietf-hip-rfc5206-bis]: LOCATOR_SET, Locator, Address, Preferred locator, and Credit Based Authorization. @@ -805,51 +799,46 @@ 10. References 10.1. Normative references [I-D.ietf-hip-rfc5206-bis] Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-09 (work in progress), July 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ - RFC2119, March 1997, + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, . [RFC3484] Draves, R., "Default Address Selection for Internet - Protocol version 6 (IPv6)", RFC 3484, DOI 10.17487/ - RFC3484, February 2003, + Protocol version 6 (IPv6)", RFC 3484, + DOI 10.17487/RFC3484, February 2003, . [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. - Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC - 7401, DOI 10.17487/RFC7401, April 2015, + Henderson, "Host Identity Protocol Version 2 (HIPv2)", + RFC 7401, DOI 10.17487/RFC7401, April 2015, . [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the Encapsulating Security Payload (ESP) Transport Format with - the Host Identity Protocol (HIP)", RFC 7402, DOI 10.17487/ - RFC7402, April 2015, + the Host Identity Protocol (HIP)", RFC 7402, + DOI 10.17487/RFC7402, April 2015, . 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] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) - Rendezvous Extension", draft-ietf-hip-rfc5204-bis-06 (work - in progress), June 2015. + Rendezvous Extension", draft-ietf-hip-rfc5204-bis-07 (work + in progress), December 2015. [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, June 2009, . Appendix A. Document Revision History To be removed upon publication +----------+--------------------------------------------------------+ @@ -864,20 +853,24 @@ | | | | draft-03 | Document refresh; no other changes. | | | | | draft-04 | Document refresh; no other changes. | | | | | draft-05 | Move remaining multihoming material from RFC5206-bis | | | to this document | | | | | | Update lingering references to LOCATOR parameter to | | | LOCATOR_SET | + | | | + | draft-06 | Document refresh with updated references. | + | | | + | draft-07 | Document refresh; no other changes. | +----------+--------------------------------------------------------+ Authors' Addresses Thomas R. Henderson (editor) University of Washington Campus Box 352500 Seattle, WA USA