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

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