--- 1/draft-ietf-ipsecme-ikev2-ipv6-config-01.txt 2009-08-21 03:12:08.000000000 +0200 +++ 2/draft-ietf-ipsecme-ikev2-ipv6-config-02.txt 2009-08-21 03:12:08.000000000 +0200 @@ -1,44 +1,54 @@ Network Working Group P. Eronen Internet-Draft Nokia Intended status: Experimental J. Laganier -Expires: December 19, 2009 DOCOMO Euro-Labs +Expires: February 21, 2010 Qualcomm Inc. C. Madson Cisco Systems - June 17, 2009 + August 20, 2009 IPv6 Configuration in IKEv2 - draft-ietf-ipsecme-ikev2-ipv6-config-01 + draft-ietf-ipsecme-ikev2-ipv6-config-02 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. + provisions of BCP 78 and BCP 79. 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on December 19, 2009. + This Internet-Draft will expire on February 21, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights @@ -50,59 +60,59 @@ gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads. The configuration payloads specified in RFC 4306 work well for IPv4, but make it difficult to use certain features of IPv6. This document specifies new configuration attributes for IKEv2 that allows the VPN gateway to assign IPv6 prefixes to clients, enabling all features of IPv6 to be used with the client-gateway "virtual link". Table of Contents - 1. Introduction and Problem Statement . . . . . . . . . . . . . . 4 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3. Current Limitations and Goals . . . . . . . . . . . . . . . . 7 - 3.1. Multiple Prefixes . . . . . . . . . . . . . . . . . . . . 7 - 3.2. Link-Local Addresses . . . . . . . . . . . . . . . . . . . 7 - 3.3. Interface Identifier Selection . . . . . . . . . . . . . . 7 - 3.4. Sharing VPN Access . . . . . . . . . . . . . . . . . . . . 8 - 3.5. General Goals . . . . . . . . . . . . . . . . . . . . . . 8 - 3.6. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.7. Additional Information . . . . . . . . . . . . . . . . . . 9 - 4. Solution Details . . . . . . . . . . . . . . . . . . . . . . . 10 - 4.1. Initial Exchanges . . . . . . . . . . . . . . . . . . . . 10 - 4.2. Reauthentication . . . . . . . . . . . . . . . . . . . . . 11 - 4.3. Creating CHILD_SAs . . . . . . . . . . . . . . . . . . . . 12 - 4.4. Relationship to Neighbor Discovery . . . . . . . . . . . . 12 - 4.5. Relationship to Existing IKEv2 Payloads . . . . . . . . . 13 - 5. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 14 - 5.1. INTERNAL_IP6_LINK Configuration Attribute . . . . . . . . 14 - 5.2. INTERNAL_IP6_PREFIX Configuration Attribute . . . . . . . 14 - 5.3. LINK_ID Notify Payload . . . . . . . . . . . . . . . . . . 15 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 - Appendix A. Design Rationale (Non-Normative) . . . . . . . . . . 22 - A.1. Link Model . . . . . . . . . . . . . . . . . . . . . . . . 22 - A.2. Distributing Prefix Information . . . . . . . . . . . . . 23 - A.3. Unique Address Allocation . . . . . . . . . . . . . . . . 23 - A.4. Layer 3 Access Control . . . . . . . . . . . . . . . . . . 24 - A.5. Other Considerations . . . . . . . . . . . . . . . . . . . 25 - A.6. Alternative Solution Sketches . . . . . . . . . . . . . . 27 - A.6.1. Version -00 Sketch . . . . . . . . . . . . . . . . . . 27 - A.6.2. Router Aggregation Sketch #1 . . . . . . . . . . . . . 28 - A.6.3. Router Aggregation Sketch #2 . . . . . . . . . . . . . 29 - A.6.4. IPv4-like Sketch . . . . . . . . . . . . . . . . . . . 31 - A.6.5. Sketch Based on RFC 3456 . . . . . . . . . . . . . . . 32 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 + 1. Introduction and Problem Statement . . . . . . . . . . . . . . 5 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3. Current Limitations and Goals . . . . . . . . . . . . . . . . 8 + 3.1. Multiple Prefixes . . . . . . . . . . . . . . . . . . . . 8 + 3.2. Link-Local Addresses . . . . . . . . . . . . . . . . . . . 8 + 3.3. Interface Identifier Selection . . . . . . . . . . . . . . 8 + 3.4. Sharing VPN Access . . . . . . . . . . . . . . . . . . . . 9 + 3.5. General Goals . . . . . . . . . . . . . . . . . . . . . . 9 + 3.6. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.7. Additional Information . . . . . . . . . . . . . . . . . . 10 + 4. Solution Details . . . . . . . . . . . . . . . . . . . . . . . 11 + 4.1. Initial Exchanges . . . . . . . . . . . . . . . . . . . . 11 + 4.2. Reauthentication . . . . . . . . . . . . . . . . . . . . . 12 + 4.3. Creating CHILD_SAs . . . . . . . . . . . . . . . . . . . . 13 + 4.4. Relationship to Neighbor Discovery . . . . . . . . . . . . 13 + 4.5. Relationship to Existing IKEv2 Payloads . . . . . . . . . 14 + 5. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 15 + 5.1. INTERNAL_IP6_LINK Configuration Attribute . . . . . . . . 15 + 5.2. INTERNAL_IP6_PREFIX Configuration Attribute . . . . . . . 15 + 5.3. LINK_ID Notify Payload . . . . . . . . . . . . . . . . . . 16 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 + Appendix A. Design Rationale (Non-Normative) . . . . . . . . . . 23 + A.1. Link Model . . . . . . . . . . . . . . . . . . . . . . . . 23 + A.2. Distributing Prefix Information . . . . . . . . . . . . . 24 + A.3. Unique Address Allocation . . . . . . . . . . . . . . . . 24 + A.4. Layer 3 Access Control . . . . . . . . . . . . . . . . . . 25 + A.5. Other Considerations . . . . . . . . . . . . . . . . . . . 26 + A.6. Alternative Solution Sketches . . . . . . . . . . . . . . 28 + A.6.1. Version -00 Sketch . . . . . . . . . . . . . . . . . . 28 + A.6.2. Router Aggregation Sketch #1 . . . . . . . . . . . . . 29 + A.6.3. Router Aggregation Sketch #2 . . . . . . . . . . . . . 30 + A.6.4. IPv4-like Sketch . . . . . . . . . . . . . . . . . . . 32 + A.6.5. Sketch Based on RFC 3456 . . . . . . . . . . . . . . . 33 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 1. Introduction and Problem Statement In typical remote access VPN use (client to VPN gateway), the client needs an IP address in the network protected by the security gateway. IKEv2 includes a feature called "configuration payloads" that allows the gateway to dynamically assign a temporary address to the client [IKEv2]. For IPv4, the message exchange would look as follows: @@ -306,20 +316,27 @@ should not preclude its use (e.g., by defining incompatible semantics for the existing payloads). o The solution should have clean implementation dependencies. In particular, it should not require significant modifications to the core IPv6 stack (typically part of the operating system), or require the IKEv2 implementor to re-implement parts of the IPv6 stack (to, e.g., have access or control to functionality that is currently not exposed by interfaces of the IPv6 stack). + o Re-use existing mechanisms as much as possible, as described in + [IPConfig]. Appendix A describes the rationale why this document + nevertheless uses IKEv2 Configuration Payloads for configuring the + addresses. However, Section 4.1 recommends using DHCPv6 + Information-Request message for obtaining other configuration + information (such as DNS server addresses). + 3.6. Non-Goals Mobile IPv6 already defines how it interacts with IPsec/IKEv2 [RFC4877], and the intent of this document is not to change that interaction in any way. 3.7. Additional Information If the VPN client is assigned IPv6 address(es) from prefix(es) that are shared with other VPN clients, this results in some kind of @@ -603,24 +620,23 @@ view: the client is still uniquely identified by the prefix. In some environments, it may be preferable to assign a VPN client the same prefix each time a VPN connection is established; other environments may prefer assigning a different prefix every time for privacy reasons. (This is basically a similar trade-off as in Mobile IPv6 -- using the same Home Address forever is simpler than changing it often, but has privacy implications.) 8. Acknowledgments - The author would like to thank Patrick Irwin, Tero Kivinen, Julien - Laganier, Chinh Nguyen, Mohan Parthasarathy, Yaron Sheffer, Hemant - Singh, Dave Thaler, Yinghzhe Wu, and Fan Zhao for their valuable - comments. + The author would like to thank Patrick Irwin, Tero Kivinen, Chinh + Nguyen, Mohan Parthasarathy, Yaron Sheffer, Hemant Singh, Dave + Thaler, Yinghzhe Wu, and Fan Zhao for their valuable comments. Many of the challenges associated with IPsec-protected "virtual interfaces" have been identified before: for example, in the context of protecting IPv6-in-IPv4 tunnels with IPsec [RFC4891], Provider Provisioned VPNs [VLINK] [RFC3884], and Mobile IPv6 [RFC4877]. Some of the limitations of assigning a single IPv6 address were identified in [RFC3314]. 9. References @@ -646,20 +662,25 @@ [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2006. [DHCPv6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [HBA] Bagnulo, M., "Hash Based Addresses (HBA)", draft-ietf-shim6-hba-05 (work in progress), December 2007. + [IPConfig] + Aboba, B., Thaler, D., Andersson, L., and S. Cheshire, + "Principles of Internet Host Configuration", RFC 5505, + May 2009. + [IPv6ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [IPv6PPP] Varada, S., Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007. [MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. @@ -1254,25 +1276,25 @@ Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland Email: pasi.eronen@nokia.com Julien Laganier - DOCOMO Communications Laboratories Europe GmbH - Landsberger Strasse 312 - Munich D-80687 - Germany + Qualcomm Incorporated + 5775 Morehouse Drive + San Diego, CA 92121 + USA - Phone: +49 89 56824 231 - Email: julien.laganier.IETF@googlemail.com + Phone: +1 858 858 3538 + Email: julienl@qualcomm.com Cheryl Madson Cisco Systems, Inc. 510 MacCarthy Drive Milpitas, CA USA Email: cmadson@cisco.com