draft-ietf-ipsecme-ikev2-ipv6-config-03.txt   rfc5739.txt 
Network Working Group P. Eronen Internet Engineering Task Force (IETF) P. Eronen
Internet-Draft Nokia Request for Comments: 5739 Nokia
Intended status: Experimental J. Laganier Category: Experimental J. Laganier
Expires: April 29, 2010 QUALCOMM Inc. ISSN: 2070-1721 QUALCOMM, Inc.
C. Madson C. Madson
Cisco Systems Cisco Systems
October 26, 2009 February 2010
IPv6 Configuration in IKEv2
draft-ietf-ipsecme-ikev2-ipv6-config-03
Status of this Memo IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)
This Internet-Draft is submitted to IETF in full conformance with the Abstract
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 When Internet Key Exchange Protocol version 2 (IKEv2) is used for
Task Force (IETF), its areas, and its working groups. Note that remote VPN access (client to VPN gateway), the gateway assigns the
other groups may also distribute working documents as Internet- client an IP address from the internal network using IKEv2
Drafts. 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".
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
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 This document is not an Internet Standards Track specification; it is
http://www.ietf.org/ietf/1id-abstracts.txt. published for examination, experimental implementation, and
evaluation.
The list of Internet-Draft Shadow Directories can be accessed at This document defines an Experimental Protocol for the Internet
http://www.ietf.org/shadow.html. community. This document is a product of the Internet Engineering
Task Force (IETF). It represents the consensus of the IETF
community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on April 29, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5739.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
When IKEv2 is used for remote VPN access (client to VPN gateway), the This document may contain material from IETF Documents or IETF
gateway assigns the client an IP address from the internal network Contributions published or made publicly available before November
using IKEv2 configuration payloads. The configuration payloads 10, 2008. The person(s) controlling the copyright in some of this
specified in RFC 4306 work well for IPv4, but make it difficult to material may not have granted the IETF Trust the right to allow
use certain features of IPv6. This document specifies new modifications of such material outside the IETF Standards Process.
configuration attributes for IKEv2 that allows the VPN gateway to Without obtaining an adequate license from the person(s) controlling
assign IPv6 prefixes to clients, enabling all features of IPv6 to be the copyright in such materials, this document may not be modified
used with the client-gateway "virtual link". 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 Problem Statement . . . . . . . . . . . . . . 5 1. Introduction and Problem Statement ..............................4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology .....................................................5
3. Current Limitations and Goals . . . . . . . . . . . . . . . . 8 3. Current Limitations and Goals ...................................6
3.1. Multiple Prefixes . . . . . . . . . . . . . . . . . . . . 8 3.1. Multiple Prefixes ..........................................6
3.2. Link-Local Addresses . . . . . . . . . . . . . . . . . . . 8 3.2. Link-Local Addresses .......................................6
3.3. Interface Identifier Selection . . . . . . . . . . . . . . 8 3.3. Interface Identifier Selection .............................7
3.4. Sharing VPN Access . . . . . . . . . . . . . . . . . . . . 9 3.4. Sharing VPN Access .........................................7
3.5. General Goals . . . . . . . . . . . . . . . . . . . . . . 9 3.5. General Goals ..............................................8
3.6. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 10 3.6. Non-Goals ..................................................8
3.7. Additional Information . . . . . . . . . . . . . . . . . . 10 3.7. Additional Information .....................................9
4. Solution Details . . . . . . . . . . . . . . . . . . . . . . . 11 4. Solution Details ................................................9
4.1. Initial Exchanges . . . . . . . . . . . . . . . . . . . . 11 4.1. Initial Exchanges ..........................................9
4.2. Reauthentication . . . . . . . . . . . . . . . . . . . . . 12 4.2. Reauthentication ..........................................11
4.3. Creating CHILD_SAs . . . . . . . . . . . . . . . . . . . . 13 4.3. Creating CHILD_SAs ........................................11
4.4. Relationship to Neighbor Discovery . . . . . . . . . . . . 14 4.4. Relationship to Neighbor Discovery ........................12
4.5. Relationship to Existing IKEv2 Payloads . . . . . . . . . 14 4.5. Relationship to Existing IKEv2 Payloads ...................13
5. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 16 5. Payload Formats ................................................13
5.1. INTERNAL_IP6_LINK Configuration Attribute . . . . . . . . 16 5.1. INTERNAL_IP6_LINK Configuration Attribute .................13
5.2. INTERNAL_IP6_PREFIX Configuration Attribute . . . . . . . 16 5.2. INTERNAL_IP6_PREFIX Configuration Attribute ...............14
5.3. LINK_ID Notify Payload . . . . . . . . . . . . . . . . . . 17 5.3. LINK_ID Notify Payload ....................................14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations ............................................15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations ........................................15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgments ................................................15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. References .....................................................16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References ......................................16
9.2. Informative References . . . . . . . . . . . . . . . . . . 21 9.2. Informative References ....................................16
Appendix A. Design Rationale (Non-Normative) . . . . . . . . . . 24 Appendix A. Design Rationale (Non-Normative) ...................19
A.1. Link Model . . . . . . . . . . . . . . . . . . . . . . . . 24 A.1. Link Model ................................................20
A.2. Distributing Prefix Information . . . . . . . . . . . . . 25 A.2. Distributing Prefix Information ...........................20
A.3. Unique Address Allocation . . . . . . . . . . . . . . . . 25 A.3. Unique Address Allocation .................................21
A.4. Layer 3 Access Control . . . . . . . . . . . . . . . . . . 26 A.4. Layer 3 Access Control ....................................21
A.5. Other Considerations . . . . . . . . . . . . . . . . . . . 27 A.5. Other Considerations ......................................22
A.6. Alternative Solution Sketches . . . . . . . . . . . . . . 29 A.6. Alternative Solution Sketches .............................24
A.6.1. Version -00 Sketch . . . . . . . . . . . . . . . . . . 29 A.6.1. Version -00 Sketch ..................................24
A.6.2. Router Aggregation Sketch #1 . . . . . . . . . . . . . 30 A.6.2. Router Aggregation Sketch #1 ..........................25
A.6.3. Router Aggregation Sketch #2 . . . . . . . . . . . . . 31 A.6.3. Router Aggregation Sketch #2 ..........................27
A.6.4. IPv4-like Sketch . . . . . . . . . . . . . . . . . . . 33 A.6.4. IPv4-Like Sketch ....................................28
A.6.5. Sketch Based on RFC 3456 . . . . . . . . . . . . . . . 34 A.6.5. Sketch Based on RFC 3456 ..............................30
Appendix B. Evaluation (Non-Normative) . . . . . . . . . . . . . 35 Appendix B. Evaluation (Non-Normative) .........................31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
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 5, line 34 skipping to change at page 4, line 34
CP(CFG_REQUEST) = CP(CFG_REQUEST) =
{ INTERNAL_IP4_ADDRESS(), { INTERNAL_IP4_ADDRESS(),
INTERNAL_IP4_DNS() }, SAi2, INTERNAL_IP4_DNS() }, SAi2,
TSi = (0, 0-65535, 0.0.0.0-255.255.255.255), TSi = (0, 0-65535, 0.0.0.0-255.255.255.255),
TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) } --> TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) } -->
<-- HDR(IKE_AUTH), <-- HDR(IKE_AUTH),
SK { IDr, CERT, AUTH, SK { IDr, CERT, AUTH,
CP(CFG_REPLY) = CP(CFG_REPLY) =
{ INTERNAL_IP4_ADDRESS(192.0.2.234), { INTERNAL_IP4_ADDRESS(192.0.2.234),
INTERNAL_IP4_DNS(10.11.22.33) }, INTERNAL_IP4_DNS(198.51.100.33) },
SAr2, SAr2,
TSi = (0, 0-65535, 192.0.2.234-192.0.2.234), TSi = (0, 0-65535, 192.0.2.234-192.0.2.234),
TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) } TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) }
Figure 1: IPv4 configuration Figure 1: IPv4 Configuration
The IPv4 case has been implemented by various vendors, and in general The IPv4 case has been implemented by various vendors and, in
works well. IKEv2 also defines almost identical configuration general, works well. IKEv2 also defines almost identical
payloads for IPv6: configuration payloads for IPv6:
Client Gateway Client Gateway
-------- --------- -------- ---------
HDR(IKE_AUTH), HDR(IKE_AUTH),
SK { IDi, CERT, [CERTREQ], AUTH, [IDr], SK { IDi, CERT, [CERTREQ], AUTH, [IDr],
CP(CFG_REQUEST) = CP(CFG_REQUEST) =
{ INTERNAL_IP6_ADDRESS(), { INTERNAL_IP6_ADDRESS(),
INTERNAL_IP6_DNS() }, SAi2, INTERNAL_IP6_DNS() }, SAi2,
TSi = (0, 0-65535, TSi = (0, 0-65535,
skipping to change at page 6, line 31 skipping to change at page 5, line 31
SK { IDr, CERT, AUTH, SK { IDr, CERT, AUTH,
CP(CFG_REPLY) = CP(CFG_REPLY) =
{ INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5, { INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5,
64), 64),
INTERNAL_IP6_DNS(2001:DB8:9:8:7:6:5:4) }, INTERNAL_IP6_DNS(2001:DB8:9:8:7:6:5:4) },
SAr2, SAr2,
TSi = (0, 0-65535, TSi = (0, 0-65535,
2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5 -
2001:DB8:0:1:2:3:4:5), 2001:DB8:0:1:2:3:4:5),
TSr = (0, 0-65535, TSr = (0, 0-65535,
0:0:0:0:0:0:0:0: - 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) } FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) }
Figure 2: IPv6 configuration Figure 2: IPv6 Configuration
In other words, IPv6 is basically treated as IPv4 with larger In other words, IPv6 is basically treated as IPv4 with larger
addresses. As noted in [RFC4718], this does not fully follow the addresses. As noted in [RFC4718], this does not fully follow the
"normal IPv6 way of doing things", and it complicates or prevents "normal IPv6 way of doing things", and it complicates or prevents
using certain features of IPv6. Section 3 describes the limitations using certain features of IPv6. Section 3 describes the limitations
in detail. in detail.
This document specifies new configuration attributes for IKEv2 that This document specifies new configuration attributes for IKEv2 that
allows the VPN gateway to assign IPv6 prefixes to clients, enabling allows the VPN gateway to assign IPv6 prefixes to clients, enabling
all features of IPv6 to be used with the client-gateway "virtual all features of IPv6 to be used with the client-gateway "virtual
link". link".
2. Terminology 2. Terminology
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 [KEYWORDS]. document are to be interpreted as described in [KEYWORDS].
When messages containing IKEv2 payloads are described, optional When messages containing IKEv2 payloads are described, optional
payloads are shown in brackets (for instance, "[FOO]"), and a plus payloads are shown in brackets (for instance, "[FOO]"); a plus sign
sign indicates that a payload can be repeated one or more times (for indicates that a payload can be repeated one or more times (for
instance, "FOO+"). instance, "FOO+").
This document uses the term "virtual interface" when describing how This document uses the term "virtual interface" when describing how
the client uses the IPv6 address(es) assigned by the gateway. While the client uses the IPv6 address(es) assigned by the gateway. While
existing IPsec documents do not use this term, it is not a new existing IPsec documents do not use this term, it is not a new
concept. In order to use the address assigned by the VPN gateway, concept. In order to use the address assigned by the VPN gateway,
current VPN clients already create a local "virtual interface", as current VPN clients already create a local "virtual interface", as
only addresses assigned to interfaces can be used, e.g., as source only addresses assigned to interfaces can be used, e.g., as source
addresses for TCP connections. Note that this definition of addresses for TCP connections. Note that this definition of
"interface" is not necessarily identical with what some particular "interface" is not necessarily identical with what some particular
implementation calls "interface". implementations call "interface".
3. Current Limitations and Goals 3. Current Limitations and Goals
This section describes the limitations of the current IPv6 This section describes the limitations of the current IPv6
configuration mechanism, and requirements for the new solution. configuration mechanism and requirements for the new solution.
3.1. Multiple Prefixes 3.1. Multiple Prefixes
In Figure 2 only a single IPv6 address (from a single prefix) is In Figure 2, only a single IPv6 address (from a single prefix) is
assigned. The specification does allow the client to include assigned. The specification does allow the client to include
multiple INTERNAL_IP6_ADDRESS attributes in its request, but the multiple INTERNAL_IP6_ADDRESS attributes in its request, but the
gateway cannot assign more addresses than the client requested. gateway cannot assign more addresses than the client requested.
Multiple prefixes are useful for site renumbering, host-based site Multiple prefixes are useful for site renumbering, host-based site
multihoming [SHIM6], and unique local IPv6 addresses [RFC4193]. In multihoming [SHIM6], and unique local IPv6 addresses [RFC4193]. In
all of these cases, the gateway has better information on how many all of these cases, the gateway has better information on how many
different addresses (from different prefixes) the client should be different addresses (from different prefixes) the client should be
assigned. assigned.
The solution should support assigning address from multiple prefixes, The solution should support assigning addresses from multiple
without requiring the client to know beforehand how many prefixes are prefixes, without requiring the client to know beforehand how many
needed. prefixes are needed.
3.2. Link-Local Addresses 3.2. Link-Local Addresses
The IPv6 addressing architecture [IPv6Addr] specifies that "IPv6 The IPv6 addressing architecture [IPv6Addr] specifies that "IPv6
addresses of all types are assigned to interfaces, not nodes. [..] addresses of all types are assigned to interfaces, not nodes. [..]
All interfaces are required to have at least one Link-Local unicast All interfaces are required to have at least one Link-Local unicast
address". address".
Currently, the virtual interface created by IKEv2 configuration Currently, the virtual interface created by IKEv2 configuration
payloads does not have link-local addresses. This violates the payloads does not have link-local addresses. This violates the
requirements in [IPv6Addr] and prevents the use of protocols that requirements in [IPv6Addr] and prevents the use of protocols that
require link-local addresses, such as [MLDv2] and [DHCPv6]. require link-local addresses, such as [MLDv2] and [DHCPv6].
The solution should assign link-local addresses to the virtual The solution should assign link-local addresses to the virtual
interfaces, and allow them to be used for protocols between the VPN interfaces and allow them to be used for protocols between the VPN
client and gateway. client and gateway.
3.3. Interface Identifier Selection 3.3. Interface Identifier Selection
In the message exchange shown in Figure 2, the gateway chooses the In the message exchange shown in Figure 2, the gateway chooses the
interface ID used by the client. It is also possible for the client interface ID used by the client. It is also possible for the client
to request a specific interface ID; the gateway then chooses the to request a specific interface ID; the gateway then chooses the
prefix part. prefix part.
This approach complicates the use of Cryptographically Generated This approach complicates the use of Cryptographically Generated
Addresses [CGA]. With CGAs, the interface ID cannot be calculated Addresses (CGAs) [CGA]. With CGAs, the interface ID cannot be
before the prefix is known. The client could first obtain a non-CGA calculated before the prefix is known. The client could first obtain
address to determine the prefix, and then send a separate CFG_REQUEST a non-CGA address to determine the prefix and then send a separate
to obtain a CGA address with the same prefix. However, this approach CFG_REQUEST to obtain a CGA address with the same prefix. However,
requires that the IKEv2 software component provides an interface to this approach requires that the IKEv2 software component provide an
the component managing CGAs; an ugly implementation dependency that interface to the component managing CGAs; an ugly implementation
would be best avoided. dependency that would be best avoided.
Similar concerns apply to other cases where the client has some Similar concerns apply to other cases where the client has some
interest in what interface ID is being used, such as Hash-Based interest in what interface ID is being used, such as Hash-Based
Addresses [HBA] and privacy addresses [RFC4941]. Addresses [HBA] and privacy addresses [RFC4941].
Without CGAs and HBAs, VPN clients are not able to fully use IPv6 Without CGAs and HBAs, VPN clients are not able to fully use IPv6
features such as [SHIM6] or enhanced Mobile IPv6 route optimization features such as [SHIM6] or enhanced Mobile IPv6 route optimization
[RFC4866]. [RFC4866].
The solution should allow the VPN client to easily obtain several The solution should allow the VPN client to easily obtain several
addresses from a given prefix, where the interface IDs are selected addresses from a given prefix, where the interface IDs are selected
by the client, and may depend on the prefix. by the client and may depend on the prefix.
3.4. Sharing VPN Access 3.4. Sharing VPN Access
Some VPN clients may want to share the VPN connection with other Some VPN clients may want to share the VPN connection with other
devices (e.g., from a cell phone to a laptop, or vice versa) via some devices (e.g., from a cell phone to a laptop or vice versa) via some
local area network connection (such as Wireless LAN or Bluetooth), if local area network connection (such as Wireless LAN or Bluetooth), if
allowed by the security policy. allowed by the security policy.
Quite obviously sharing of VPN access requires more than one address Quite obviously, sharing of VPN access requires more than one address
(unless NAT is used). However, the current model where each address (unless NAT is used). However, the current model where each address
is requested separately is probably complex to integrate with a local is requested separately is probably complex to integrate with a local
area network that uses stateless address autoconfiguration area network that uses stateless address autoconfiguration
[AUTOCONF]. Thus, obtaining a whole prefix for the VPN client, and [AUTOCONF]. Thus, obtaining a whole prefix for the VPN client and
advertising that to the local link (something resembling [NDProxy]) advertising that to the local link (something resembling [NDProxy])
would be preferable. With DHCPv6 prefix delegation [RFC3633], even would be preferable. With DHCPv6 prefix delegation [RFC3633], even
[NDProxy] and associated multi-link subnet issues would be avoided. [NDProxy] and associated multi-link subnet issues would be avoided.
The solution should support sharing the VPN access over a local area The solution should support sharing the VPN access over a local area
network connection when the other hosts are using stateless address network connection when the other hosts are using stateless address
autoconfiguration. autoconfiguration.
3.5. General Goals 3.5. General Goals
o The solution should avoid periodic messages over the VPN tunnel. o The solution should avoid periodic messages over the VPN tunnel.
o Re-authentication works: the client can start a new IKE SA and o Reauthentication should work, where the client can start a new IKE
continue using the same addresses as before. Security Association (SA) and continue using the same addresses as
before.
o Compatibility with other IPsec uses: Configuring a virtual IPv6 o There should be compatibility with other IPsec uses. Configuring
link (with addresses assigned in IKEv2) should not prevent the a virtual IPv6 link (with addresses assigned in IKEv2) should not
same peers from using IPsec/IKEv2 for other uses (with other prevent the same peers from using IPsec/IKEv2 for other uses (with
addresses). In particular, the peers may have SPD entries and PAD other addresses). In particular, the peers may have Security
Child SA Authorization Data entries that are not related to the Policy Database (SPD) entries and Peer Authorization Database
virtual link; when a CHILD_SA is created, it should be unambigous (PAD) Child SA Authorization Data entries that are not related to
which entries are used. the virtual link; when a CHILD_SA is created, it should be
unambiguous which entries are used.
o Compatibility with current IPv6 configuration: Although the o There should be compatibility with current IPv6 configuration.
current IPv6 mechanism is not widely implemented, new solutions Although the current IPv6 mechanism is not widely implemented, new
should not preclude its use (e.g., by defining incompatible solutions should not preclude its use (e.g., by defining
semantics for the existing payloads). incompatible 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 (e.g., to 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 o Re-use existing mechanisms as much as possible, as described in
[IPConfig]. Appendix A describes the rationale why this document [IPConfig]. Appendix A describes the rationale of why this
nevertheless uses IKEv2 Configuration Payloads for configuring the document nevertheless uses IKEv2 configuration payloads for
addresses. However, Section 4.1 recommends using DHCPv6 configuring the addresses. However, Section 4.1 recommends using
Information-Request message for obtaining other configuration a DHCPv6 Information-Request message for obtaining other
information (such as DNS server addresses). 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
multi-link subnet. [Multilink] describes issues associated with multi-link subnet. [Multilink] describes issues associated with
multi-link subnets, and recommends that they should be avoided. multi-link subnets and recommends that they be avoided.
The original 3GPP specifications for IPv6 assigned a single IPv6 The original 3GPP specifications for IPv6 assigned a single IPv6
address to each mobile phone, resembling current IKEv2 payloads. address to each mobile phone, resembling current IKEv2 payloads.
[RFC3314] described the problems with this approach, and caused 3GPP [RFC3314] describes the problems with this approach and caused 3GPP
to change the specifications to assign unique /64 prefix(es) for each to change the specifications to assign unique /64 prefix(es) for each
phone. phone.
Due to similar concerns, the IEEE 802.16 IPv6 Convergence Sublayer Due to similar concerns, the IEEE 802.16 IPv6 Convergence Sublayer
[RFC5121] and Proxy Mobile IPv6 [RFC5213] also assign unique [RFC5121] and Proxy Mobile IPv6 [RFC5213] also assign unique
prefixes. prefixes.
4. Solution Details 4. Solution Details
4.1. Initial Exchanges 4.1. Initial Exchanges
1) During IKE_AUTH, the client sends a new configuration attribute, During IKE_AUTH, the client sends a new configuration attribute,
INTERNAL_IP6_LINK, which requests a virtual link to be configured. INTERNAL_IP6_LINK, which requests a virtual link to be configured.
The attribute contains the client's interface ID for the link-local The attribute contains the client's interface ID for the link-local
address (other addresses may use other interface IDs). Typically, address (other addresses may use other interface IDs). Typically,
the client would also ask for DHCPv6 server address; this is used the client would also ask for the DHCPv6 server address; this is used
only for configuration (such as DNS server addresses), not address only for configuration (such as DNS server addresses), not address
assignment. assignment.
CP(CFG_REQUEST) = CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK(Client's Link-Local Interface ID) { INTERNAL_IP6_LINK(Client's Link-Local Interface ID)
INTERNAL_IP6_DHCP() } INTERNAL_IP6_DHCP() }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->
If the client has sent the INTERNAL_IP6_LINK configuration attribute, If the client has sent the INTERNAL_IP6_LINK configuration attribute,
the VPN gateway SHOULD ignore any INTERNAL_IP6_ADDRESS configuration the VPN gateway SHOULD ignore any INTERNAL_IP6_ADDRESS configuration
attribute present in the request. attribute present in the request.
The VPN gateway MUST choose for itself a link-local interface The VPN gateway MUST choose for itself a link-local interface
identifier different than the client's one, i.e., accept the link- identifier different than the client's, i.e., accept the link-local
local interface identifier proposed by the client. In case the VPN interface identifier proposed by the client. In case the VPN gateway
gateway cannot accept the link-local interface identifier the client cannot accept the link-local interface identifier the client
proposed, the VPN gateway MUST fail the IPv6 address assignment by proposed, the VPN gateway MUST fail the IPv6 address assignment by
including a NOTIFY payload with the INTERNAL_ADDRESS_FAILURE message. including a NOTIFY payload with the INTERNAL_ADDRESS_FAILURE message.
The VPN Gateway then replies with an INTERNAL_IP6_LINK configuration The VPN gateway then replies with an INTERNAL_IP6_LINK configuration
attribute that contains the IKEv2 Link ID (an identifier selected by attribute that contains the IKEv2 Link ID (an identifier selected by
the VPN gateway, treated as an opaque octet string by the client -- the VPN gateway, treated as an opaque octet string by the client --
this will be used for reauthentication and CREATE_CHILD_SA messages), this will be used for reauthentication and CREATE_CHILD_SA messages),
the gateway's link local interface identier, and zero or more the gateway's link-local interface identifier, and zero or more
INTERNAL_IP6_PREFIX attributes. The traffic selectors proposed by INTERNAL_IP6_PREFIX attributes. The traffic selectors proposed by
the initiator are also narrowed to contain only the assigned the initiator are also narrowed to contain only the assigned prefixes
prefixes, and the client link-local address (FE80::<Client's and the client link-local address (FE80::<Client's Interface ID>)
Interface ID>)identifier. identifier.
CP(CFG_REPLY) = CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK(Gateway's Link-Local Interface ID, { INTERNAL_IP6_LINK(Gateway's Link-Local Interface ID,
IKEv2 Link ID) IKEv2 Link ID)
INTERNAL_IP6_PREFIX(Prefix1/64), INTERNAL_IP6_PREFIX(Prefix1/64),
[INTERNAL_IP6_PREFIX(Prefix2/64),...], [INTERNAL_IP6_PREFIX(Prefix2/64),...],
[INTERNAL_IP6_DHCP(Address) ] INTERNAL_IP6_DHCP(Address) }
TSi = ((0, 0-65535, TSi = ((0, 0-65535,
FE80::<Client's Interface ID> - FE80::<Client's Interface ID> -
FE80::<Client's Interface ID>) FE80::<Client's Interface ID>)
(0, 0-65535, (0, 0-65535,
Prefix1::0 - Prefix1::0 -
Prefix1::FFFF:FFFF:FFFF:FFFF), Prefix1::FFFF:FFFF:FFFF:FFFF),
[(0, 0-65535, [(0, 0-65535,
Prefix2::0 - Prefix2::0 -
Prefix2::FFFF:FFFF:FFFF:FFFF), ...]) Prefix2::FFFF:FFFF:FFFF:FFFF), ...])
TSr = (0, 0-65535, TSr = (0, 0-65535,
0:0:0:0:0:0:0:0 - 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
At this point, the client can configure its link-local address At this point, the client can configure its link-local address
(FE80::<Client's Interface ID>), and other non-link-local unicast (FE80::<Client's Interface ID>) and other non-link-local unicast
addresses from the assigned prefixes (with any proper interface addresses from the assigned prefixes (with any proper interface
identifier [IPv6Addr]). The VPN gateway MUST NOT simultaneously identifier [IPv6Addr]). The VPN gateway MUST NOT simultaneously
assign the same prefixes to any other client, and MUST NOT itself assign the same prefixes to any other client and MUST NOT itself
configure addresses from these prefixes. Thus, the client does not configure addresses from these prefixes. Thus, the client does not
have to perform Duplicate Address Detection (DAD). (This approach is have to perform Duplicate Address Detection (DAD). (This approach is
based on [IPv6PPP].) based on [IPv6PPP].)
The prefixes remain valid through the lifetime of the IKE SA (and its The prefixes remain valid through the lifetime of the IKE SA (and its
continuations via rekeying). If the VPN gateway needs to remove a continuations via rekeying). If the VPN gateway needs to remove a
prefix it has previously assigned, or assign a new prefix, it can do prefix it has previously assigned, or assign a new prefix, it can do
so with reauthentication (either starting reauthentication itself, or so with reauthentication (either starting reauthentication itself or
requesting the client to reauthenticate using [RFC4478]). requesting the client to reauthenticate using [RFC4478]).
2) The client also contacts the DHCPv6 server. This is the The client also contacts the DHCPv6 server. This is the RECOMMENDED
RECOMMENDED way to obtain additional configuration parameters (such way to obtain additional configuration parameters (such as DNS server
as DNS server addresses), as it allows easier extensibility and more addresses), as it allows easier extensibility and more options (such
options (such as the domain search list for DNS). as the domain search list for DNS).
4.2. Reauthentication 4.2. Reauthentication
When the client performs reauthentication (and wants to continue When the client performs reauthentication (and wants to continue
using the same "virtual link"), it includes the IKEv2 Link ID given using the same "virtual link"), it includes the IKEv2 Link ID given
by the gateway in the INTERNAL_IP6_LINK attribute. by the gateway in the INTERNAL_IP6_LINK attribute.
CP(CFG_REQUEST) = CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK(Client's Link Local Interface ID, { INTERNAL_IP6_LINK(Client's Link Local Interface ID,
IKEv2 Link ID) IKEv2 Link ID)
skipping to change at page 13, line 19 skipping to change at page 11, line 25
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->
At this point, the gateway MUST verify that the client is indeed At this point, the gateway MUST verify that the client is indeed
allowed to use the link identified by the IKEv2 Link ID. The same allowed to use the link identified by the IKEv2 Link ID. The same
situation occurs in [IKEv2] when the client wants to continue using situation occurs in [IKEv2] when the client wants to continue using
the same IPv4 address with the INTERNAL_IP4_ADDRESS configuration the same IPv4 address with the INTERNAL_IP4_ADDRESS configuration
attribute. Typically, the gateway would use the Link ID to look up attribute. Typically, the gateway would use the Link ID to look up
relevant local state, and compare the authenticated peer identity of relevant local state and compare the authenticated peer identity of
the IKE_SA with the local state. the IKE_SA with the local state.
If the client is allowed to continue using this link, the gateway If the client is allowed to continue using this link, the gateway
replies (see Section 4.1) with the same Gateway's Link-Local replies (see Section 4.1) with the same gateway's link-local
Interface ID and IKEv2 Link ID as used earlier, and sends the IPv6 interface ID and IKEv2 Link ID as used earlier and sends the IPv6
prefix(es) associated with this link. Usually, the IPv6 prefix(es) prefix(es) associated with this link. Usually, the IPv6 prefix(es)
will also be the same as earlier, but this is not required. will also be the same as earlier, but this is not required.
If the client is not allowed to continue using this link, the gateway If the client is not allowed to continue using this link, the gateway
treats it as a request for a new virtual link, selects a different treats it as a request for a new virtual link, selects a different
IKEv2 Link ID value, and replies as in Section 4.1. IKEv2 Link ID value, and replies as in Section 4.1.
4.3. Creating CHILD_SAs 4.3. Creating CHILD_SAs
When a CHILD_SA is created, the peers need to determine which SPD When a CHILD_SA is created, the peers need to determine which SPD
skipping to change at page 13, line 46 skipping to change at page 11, line 52
CHILD_SA. In the basic client-to-VPN-gateway uses, the situation is CHILD_SA. In the basic client-to-VPN-gateway uses, the situation is
simple: all the matching SPD entries and Child SA Authorization Data simple: all the matching SPD entries and Child SA Authorization Data
entries are related to the "virtual link" between the VPN client and entries are related to the "virtual link" between the VPN client and
the VPN gateway. However, if the same peers are also using IPsec/ the VPN gateway. However, if the same peers are also using IPsec/
IKEv2 for other uses (with addresses not assigned inside IKEv2), they IKEv2 for other uses (with addresses not assigned inside IKEv2), they
would also have SPD entries and PAD Child SA Authorization Data that would also have SPD entries and PAD Child SA Authorization Data that
is not related to the virtual link. is not related to the virtual link.
If one of the peers requests a CHILD_SA and proposes traffic If one of the peers requests a CHILD_SA and proposes traffic
selectors covering everything (like in Figure 2), should those be selectors covering everything (like in Figure 2), should those be
narrowed to the prefixes configured with INTERNAL_IP6_PREFIX, or to narrowed to the prefixes configured with INTERNAL_IP6_PREFIX or to
the other SPD/PAD entries? While some kind of heuristics are the other SPD/PAD entries? While some kind of heuristics are
possible (see Appendix A for discussion), this document specifies an possible (see Appendix A for discussion), this document specifies an
explicit solution: explicit solution:
The peers MUST include a LINK_ID notification, containing the IKEv2 The peers MUST include a LINK_ID notification, containing the IKEv2
Link ID, in all CREATE_CHILD_SA requests (including rekeys) that are Link ID, in all CREATE_CHILD_SA requests (including rekeys) that are
related to the virtual link. The LINK_ID notification is not related to the virtual link. The LINK_ID notification is not
included in the CREATE_CHILD_SA response, or when doing IKE_SA included in the CREATE_CHILD_SA response or when doing IKE_SA
rekeying. rekeying.
4.4. Relationship to Neighbor Discovery 4.4. Relationship to Neighbor Discovery
Neighbor Discovery [IPv6ND] specifies the following mechanisms: Neighbor Discovery [IPv6ND] specifies the following mechanisms:
Router Discovery, Prefix Discovery, Parameter Discovery, and Address Router Discovery, Prefix Discovery, Parameter Discovery, and address
Autoconfiguration are not used, as the necessary functionality is autoconfiguration are not used, as the necessary functionality is
implemented in IKEv2. implemented in IKEv2.
Address Resolution, Next-hop Determination, and Redirect are not Address Resolution, Next-hop Determination, and Redirect are not
used, as the virtual link does not have link-layer addresses, and is used, as the virtual link does not have link-layer addresses and is a
a point-to-point link. point-to-point link.
Neighbor Unreachability Detection could be used, but is a bit Neighbor Unreachability Detection could be used but is a bit
redundant given IKEv2 Dead Peer Detection. redundant given IKEv2 Dead Peer Detection.
Duplicate Address Detection is not needed, because this is a point- Duplicate Address Detection is not needed because this is a point-to-
to-point link, where the VPN gateway does not assign any addresses point link, where the VPN gateway does not assign any addresses from
from the global unicast prefixes, and link-local interface identifier the global unicast prefixes, and the link-local interface identifier
is negotiated separately. is negotiated separately.
Duplicate Address Detection is not needed for global unicast Duplicate Address Detection is not needed for global unicast
addresses formed from the global unicast prefix(es) configured as addresses formed from the global unicast prefix(es) configured as
part of the IKEv2 exchange, because this is a point-to-point link, part of the IKEv2 exchange, because this is a point-to-point link,
where the VPN gateway does not assign any addresses from the global where the VPN gateway does not assign any addresses from the global
unicast prefixes. Duplicate Address Detection may be needed for unicast prefixes. Duplicate Address Detection may be needed for
link-local addresses, e.g., when the client configures a link-local link-local addresses, e.g., when the client configures a link-local
address as per [RFC4941]. address as per [RFC4941].
skipping to change at page 16, line 27 skipping to change at page 13, line 41
| Link-Local | | Link-Local |
| Interface ID | | Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ IKEv2 Link ID ~ ~ IKEv2 Link ID ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Reserved (1 bit) - See [IKEv2]. o Reserved (1 bit) - See [IKEv2].
o Attribute Type (15 bits) - INTERNAL_IP6_LINK (TBD1). o Attribute Type (15 bits) - INTERNAL_IP6_LINK (17).
o Length (2 octets) - Length in octets of the Value field ( Link- o Length (2 octets) - Length in octets of the Value field (Link-
Local Interface ID and IKEv2 Link ID); 8 or more. Local Interface ID and IKEv2 Link ID); 8 or more.
o Link-Local Interface ID (8 octets) - The Interface ID used for o Link-Local Interface ID (8 octets) - The Interface ID used for
link-local address (by the party that sent this attribute). link-local address (by the party that sent this attribute).
o IKEv2 Link ID (variable length) - The link ID (may be empty when o IKEv2 Link ID (variable length) - The Link ID (may be empty when
the client does not yet know the link ID). The link ID is the client does not yet know the Link ID). The Link ID is
selected by the VPN gateway, and is treated as an opaque octet selected by the VPN gateway and is treated as an opaque octet
string by the client. string by the client.
5.2. INTERNAL_IP6_PREFIX Configuration Attribute 5.2. INTERNAL_IP6_PREFIX Configuration Attribute
The INTERNAL_IP6_PREFIX configuration attribute is formatted as The INTERNAL_IP6_PREFIX configuration attribute is formatted as
follows: follows:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 17, line 20 skipping to change at page 14, line 25
| | | |
| Prefix | | Prefix |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | | Prefix Length |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
o Reserved (1 bit) - See [IKEv2]. o Reserved (1 bit) - See [IKEv2].
o Attribute Type (15 bits) - INTERNAL_IP6_PREFIX (TBD2). o Attribute Type (15 bits) - INTERNAL_IP6_PREFIX (18).
o Length (2 octets) - Length in octets of the Value field; in this o Length (2 octets) - Length in octets of the Value field; in this
case, 17. case, 17.
o Prefix (16 octets) - An IPv6 prefix assigned to the virtual link. o Prefix (16 octets) - An IPv6 prefix assigned to the virtual link.
The low order bits of the prefix field which are not part of the The low-order bits of the prefix field that are not part of the
prefix MUST be set to zero by the sender and MUST be ignored by prefix MUST be set to zero by the sender and MUST be ignored by
the receiver. the receiver.
o Prefix Length (1 octets) - The length of the prefix in bits; o Prefix Length (1 octet) - The length of the prefix in bits;
usually 64. usually 64.
5.3. LINK_ID Notify Payload 5.3. LINK_ID Notify Payload
The LINK_ID notification is included in CREATE_CHILD_SA requests to The LINK_ID notification is included in CREATE_CHILD_SA requests to
indicate that the SA being created is related to the virtual link. indicate that the SA being created is related to the virtual link.
If this notification is not included, the CREATE_CHILD_SA requests is If this notification is not included, the CREATE_CHILD_SA requests
related to the real interface. are related to the real interface.
The Notify Message Type for LINK_ID is TBD3. The Protocol ID and SPI The Notify Message Type for LINK_ID is 16414. The Protocol ID and
Size fields are set to zero. The data associated with this SPI Size fields are set to zero. The data associated with this
notification is the IKEv2 Link ID returned in the INTERNAL_IP6_LINK notification is the IKEv2 Link ID returned in the INTERNAL_IP6_LINK
configuration attribute. configuration attribute.
6. IANA Considerations 6. IANA Considerations
This document defines two new IKEv2 configuration attributes, whose This document defines two new IKEv2 configuration attributes, whose
values are to be allocated (have been allocated) from the "IKEv2 values have been allocated from the "IKEv2 Configuration Payload
Configuration Payload Attribute Types" namespace [IKEv2]: Attribute Types" namespace [IKEv2]:
Multi- Multi-
Value Attribute Type Valued Length Reference Value Attribute Type Valued Length Reference
------ ---------------------- ------ ------------- --------- ------ ---------------------- ------ ------------- ---------
TBD1 INTERNAL_IP6_LINK NO 8 or more [this doc] 17 INTERNAL_IP6_LINK NO 8 or more [RFC5739]
TBD2 INTERNAL_IP6_PREFIX YES 17 octets [this doc] 18 INTERNAL_IP6_PREFIX YES 17 octets [RFC5739]
This document also defines one new IKEv2 notification, whose value is This document also defines one new IKEv2 notification, whose value
to be allocated (has been allocated) from the "IKEv2 Notify Message has been allocated from the "IKEv2 Notify Message Types - Status
Types - Status Types" namespace [IKEv2]: Types" namespace [IKEv2]:
Value Notify Messages - Status Types Reference Value Notify Messages - Status Types Reference
------ ------------------------------- --------- ------ ------------------------------- ---------
TBD3 LINK_ID [this doc] 16414 LINK_ID [RFC5739]
This document does not create any new namespaces to be maintained by This document does not create any new namespaces to be maintained by
IANA. IANA.
7. Security Considerations 7. Security Considerations
Since this document is an extension to IKEv2, the security Since this document is an extension to IKEv2, the security
considerations in [IKEv2] apply here as well. considerations in [IKEv2] apply here as well.
The mechanism described in this document assigns each client a unique The mechanism described in this document assigns each client a unique
prefix, which makes using randomized interface identifiers [RFC4941] prefix, which makes using randomized interface identifiers [RFC4941]
ineffective from privacy point of view: the client is still uniquely ineffective from a privacy point of view: the client is still
identified by the prefix. In some environments, it may be preferable uniquely identified by the prefix. In some environments, it may be
to assign a VPN client the same prefix each time a VPN connection is preferable to assign a VPN client the same prefix each time a VPN
established; other environments may prefer assigning a different connection is established; other environments may prefer assigning a
prefix every time for privacy reasons. (This is basically a similar different prefix every time for privacy reasons. (This is basically
trade-off as in Mobile IPv6 -- using the same Home Address forever is a similar trade-off as in Mobile IPv6 -- using the same Home Address
simpler than changing it often, but has privacy implications.) forever is simpler than changing it often, but has privacy
implications.)
8. Acknowledgments 8. Acknowledgments
The author would like to thank Patrick Irwin, Tero Kivinen, Chinh The authors would like to thank Patrick Irwin, Tero Kivinen, Chinh
Nguyen, Mohan Parthasarathy, Yaron Sheffer, Hemant Singh, Dave Nguyen, Mohan Parthasarathy, Yaron Sheffer, Hemant Singh, Dave
Thaler, Yinghzhe Wu, and Fan Zhao for their valuable comments. Thaler, Yinghzhe Wu, and Fan Zhao for their valuable 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].
of the limitations of assigning a single IPv6 address were identified Some of the limitations of assigning a single IPv6 address were
in [RFC3314]. identified in [RFC3314].
9. References 9. References
9.1. Normative References 9.1. Normative References
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[IPv6Addr] [IPv6Addr] Hinden, R. and S. Deering, "IP Version 6 Addressing
Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
Architecture", RFC 4291, February 2006.
[KEYWORDS] [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
Requirement Levels", RFC 2119, March 1997.
9.2. Informative References 9.2. Informative References
[AUTOCONF] [AUTOCONF] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
Address Autoconfiguration", RFC 4862, September 2007.
[CGA] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2006.
[DHCPv6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)",
and M. Carney, "Dynamic Host Configuration Protocol for RFC 3972, March 2006.
IPv6 (DHCPv6)", RFC 3315, July 2003.
[HBA] Bagnulo, M., "Hash Based Addresses (HBA)", [DHCPv6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
draft-ietf-shim6-hba-05 (work in progress), December 2007. and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[IPConfig] [HBA] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535,
Aboba, B., Thaler, D., Andersson, L., and S. Cheshire, June 2009.
"Principles of Internet Host Configuration", RFC 5505,
May 2009.
[IPv6ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [IPConfig] Aboba, B., Thaler, D., Andersson, L., and S. Cheshire,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Principles of Internet Host Configuration", RFC 5505,
September 2007. May 2009.
[IPv6PPP] Varada, S., Haskins, D., and E. Allen, "IP Version 6 over [IPv6ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
PPP", RFC 5072, September 2007. "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery [IPv6PPP] Varada, S., Haskins, D., and E. Allen, "IP Version 6
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. over PPP", RFC 5072, September 2007.
[MOBIKE] Eronen, P., "IKEv2 Mobility and Multihoming Protocol [MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery
(MOBIKE)", RFC 4555, June 2006. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[Multilink] [MOBIKE] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
Thaler, D., "Multi-Link Subnet Issues", RFC 4903, (MOBIKE)", RFC 4555, June 2006.
June 2007.
[NDProxy] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery [Multilink] Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
Proxies (ND Proxy)", RFC 4389, April 2006. June 2007.
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third [NDProxy] Thaler, D., Talwar, M., and C. Patel, "Neighbor
Generation Partnership Project 3GPP) Standards", RFC 3314, Discovery Proxies (ND Proxy)", RFC 4389, April 2006.
September 2002.
[RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Host Configuration Protocol (DHCPv4) Configuration of Generation Partnership Project (3GPP) Standards",
IPsec Tunnel Mode", RFC 3456, January 2003. RFC 3314, September 2002.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCPv4) Configuration of
December 2003. IPsec Tunnel Mode", RFC 3456, January 2003.
[RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Transport Mode for Dynamic Routing", RFC 3884, Host Configuration Protocol (DHCP) version 6", RFC 3633,
September 2004. December 2003.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec
Addresses", RFC 4193, October 2005. Transport Mode for Dynamic Routing", RFC 3884,
September 2004.
[RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
(IKEv2) Protocol", RFC 4478, April 2006. Addresses", RFC 4193, October 2005.
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and [RFC4478] Nir, Y., "Repeated Authentication in Internet Key
Implementation Guidelines", RFC 4718, October 2006. Exchange (IKEv2) Protocol", RFC 4478, April 2006.
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
Optimization for Mobile IPv6", RFC 4866, May 2007. Implementation Guidelines", RFC 4718, October 2006.
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
IKEv2 and the Revised IPsec Architecture", RFC 4877, Optimization for Mobile IPv6", RFC 4866, May 2007.
April 2007.
[RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation
Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", with IKEv2 and the Revised IPsec Architecture",
RFC 4891, May 2007. RFC 4877, April 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H.
Extensions for Stateless Address Autoconfiguration in Tschofenig, "Using IPsec to Secure IPv6-in-IPv4
IPv6", RFC 4941, September 2007. Tunnels", RFC 4891, May 2007.
[RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
Madanapalli, "Transmission of IPv6 via the IPv6 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S.
Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, Madanapalli, "Transmission of IPv6 via the IPv6
February 2008. Convergence Sublayer over IEEE 802.16 Networks",
RFC 5121, February 2008.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdury, [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury,
K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213,
August 2008. August 2008.
[SHIM6] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming [SHIM6] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", draft-ietf-shim6-proto-12 (work Shim Protocol for IPv6", RFC 5533, June 2009.
in progress), February 2009.
[VLINK] Duffy, M., "Framework for IPsec Protected Virtual Links [VLINK] Duffy, M., "Framework for IPsec Protected Virtual Links
for PPVPNs", draft-duffy-ppvpn-ipsec-vlink-00 (work in for PPVPNs", Work in Progress, October 2002.
progress), October 2002.
Appendix A. Design Rationale (Non-Normative) Appendix A. Design Rationale (Non-Normative)
This appendix describes some of the reasons why the solution in This appendix describes some of the reasons why the solution in
Section 4 was selected, and lists some alternative designs that were Section 4 was selected and lists some alternative designs that were
considered, but ultimately rejected. considered but were ultimately rejected.
Assigning a new IPv6 address to the client creates a new "virtual Assigning a new IPv6 address to the client creates a new "virtual
IPv6 interface", and "virtual link" between the client and the IPv6 interface" and "virtual link" between the client and the
gateway. We will assume that the virtual link has the following gateway. We will assume that the virtual link has the following
properties: properties:
o The link and its interfaces are created and destroyed by the IKEv2 o The link and its interfaces are created and destroyed by the IKEv2
process. process.
o The link is not an IPsec SA; at any time, there can be zero or o The link is not an IPsec SA; at any time, there can be zero or
more IPsec SAs covering traffic on this link. more IPsec SAs covering traffic on this link.
o The link is not a single IKE SA; to support reauthentication, it o The link is not a single IKE SA; to support reauthentication, it
must be possible to identify the same link in another IKE SA. must be possible to identify the same link in another IKE SA.
o Not all IPsec-protected traffic between the peers is necessarily o Not all IPsec-protected traffic between the peers is necessarily
related to the virtual link (although in the simplest VPN client- related to the virtual link (although in the simplest VPN client-
to-gateway scenario it will be). to-gateway scenario, it will be).
Given these assumptions and the goals described in Section 3, it Given these assumptions and the goals described in Section 3, it
seems that the most important design choices to be made are the seems that the most important design choices to be made are the
following: following:
o What link/subnet model is used: in other words, the relationships o What link/subnet model is used; in other words, how relationships
between VPN clients, IPv6 subnet prefixes, and link-local traffic between VPN clients, IPv6 subnet prefixes, and link-local traffic
(especially link-local multicast). (especially link-local multicast) are organized.
o How information about the IPv6 prefix(es) is distributed from the o How information about the IPv6 prefix(es) is distributed from the
gateway to the clients. gateway to the clients.
o How to ensure unique IPv6 addresses for each client, and keep o How to ensure unique IPv6 addresses for each client and keep
forwarding state up-to-date accordingly. forwarding state up-to-date accordingly.
o How layer 3 access control is done; in other words, where the o How layer 3 access control is done; in other words, where the
mechanisms for preventing address spoofing by clients are placed mechanisms for preventing address spoofing by clients are placed
architecturally. architecturally.
Each of these is discussed next in turn. Each of these is discussed next in turn.
A.1. Link Model A.1. Link Model
There are at least three main choices how to organize the There are at least three main choices for how to organize the
relationships between VPN clients, IPv6 subnet prefixes, and link- relationships between VPN clients, IPv6 subnet prefixes, and link-
local traffic: local traffic:
o Point-to-point link model: each VPN client is assigned one or more o Point-to-point link model: each VPN client is assigned one or more
IPv6 prefixes; these prefixes are not shared with other clients, IPv6 prefixes. These prefixes are not shared with other clients,
and there is no link-local traffic between different VPN clients and there is no link-local traffic between different VPN clients
connected to the same gateway. connected to the same gateway.
o Multi-access link model: multiple VPN clients share the same IPv6 o Multi-access link model: multiple VPN clients share the same IPv6
prefix. Link-local multicast packets sent by one VPN client will prefix. Link-local multicast packets sent by one VPN client will
be received by other VPN clients (VPN gateway will forward the be received by other VPN clients (VPN gateway will forward the
packets, possibly with MLD snooping to remove unnecessary packets, possibly with Multicast Listener Discovery (MLD) snooping
packets). to remove unnecessary packets).
o "Router aggregation" link model: one form of "multi-link" subnet o "Router aggregation" link model: one form of "multi-link" subnet
[Multilink] where multiple VPN clients share the same IPv6 prefix. [Multilink] where multiple VPN clients share the same IPv6 prefix.
Link-local multicast will not be received by other VPN clients. Link-local multicast will not be received by other VPN clients.
In the multi-access link model, VPN clients who are idle (i.e., not In the multi-access link model, VPN clients who are idle (i.e., not
currently sending or receiving application traffic) could receive currently sending or receiving application traffic) could receive
significant amounts of multicast packets from other clients significant amounts of multicast packets from other clients
(depending on how many other clients are connected). This is (depending on how many other clients are connected). This is
especially undesirable when the clients are battery-powered; for especially undesirable when the clients are battery-powered such as a
example, a PDA which keeps the VPN connection to corporate intranet PDA that keeps the VPN connection to corporate intranet active 24/7.
active 24/7. For this reason, using the multi-access link model was For this reason, using the multi-access link model was rejected.
rejected.
The configuration attributes specified in Section 4 use the point-to- The configuration attributes specified in Section 4 use the point-to-
point link model. point link model.
A.2. Distributing Prefix Information A.2. Distributing Prefix Information
Some types of addresses, such as CGAs, require knowledge about the Some types of addresses, such as CGAs, require knowledge about the
prefix before an address can be generated. The prefix information prefix before an address can be generated. The prefix information
could be distributed to clients in the following ways: could be distributed to clients in the following ways:
o IKEv2 messages (Configuration Payloads). o IKEv2 messages (configuration payloads)
o Router Advertisement messages (sent over the IPsec tunnel). o Router Advertisement messages (sent over the IPsec tunnel)
o DHCPv6 messages (sent over the IPsec tunnel). o DHCPv6 messages (sent over the IPsec tunnel)
In Section 4, the prefix information is distributed in IKEv2 In Section 4, the prefix information is distributed in IKEv2
messages. messages.
A.3. Unique Address Allocation A.3. Unique Address Allocation
In the "multi-access" and "router aggregation" link models (where a In the "multi-access" and "router aggregation" link models (where a
single IPv6 prefix is shared between multiple VPN clients) mechanisms single IPv6 prefix is shared between multiple VPN clients),
are needed to ensure that one VPN client does not use an address mechanisms are needed to ensure that one VPN client does not use an
already used by some other client. Also, the VPN gateway has to know address already used by some other client. Also, the VPN gateway has
which client is using which addresses in order to correctly forward to know which client is using which addresses in order to correctly
traffic. forward traffic.
The main choices seem to be the following: The main choices seem to be the following:
o Clients receive the address(es) they are allowed to use in IKEv2 o Clients receive the address(es) they are allowed to use in IKEv2
messages (Configuration Payloads). In this case, keeping track of messages (configuration payloads). In this case, keeping track of
which client is using which address is trivial. which client is using which address is trivial.
o Clients receive the address(es) they are allowed to use in DHCPv6 o Clients receive the address(es) they are allowed to use in DHCPv6
messages sent over the IPsec tunnel. In case the DHCPv6 server is messages sent over the IPsec tunnel. In case the DHCPv6 server is
not integrated with the VPN gateway, the gateway may need to work not integrated with the VPN gateway, the gateway may need to work
as a relay agent to keep track of which client is using which as a relay agent to keep track of which client is using which
address (and update its forwarding state accordingly). address (and update its forwarding state accordingly).
o Clients can use stateless address autoconfiguration to configure o Clients can use stateless address autoconfiguration to configure
addresses and perform Duplicate Address Detection (DAD). This is addresses and perform Duplicate Address Detection (DAD). This is
easy to do in multi-access link model, and can be made to work easy to do in a multi-access link model and can be made to work
with router aggregation link model if the VPN gateway traps with a router aggregation link model if the VPN gateway traps
Neighbor Solicitation (NS) messages and spoofs Neighbor Neighbor Solicitation (NS) messages and spoofs Neighbor
Advertisement (NA) replies. The gateway keeps track of which Advertisement (NA) replies. The gateway keeps track of which
client is using which address (and updates its forwarding state client is using which address (and updates its forwarding state
accordingly) by trapping these NS/NA messages. accordingly) by trapping these NS/NA messages.
In the point-to-point link model, the client can simply use any In the point-to-point link model, the client can simply use any
address from the prefix, and the VPN gateway only needs to know which address from the prefix, and the VPN gateway only needs to know which
client is using which prefix in order to forward packets correctly. client is using which prefix in order to forward packets correctly.
A.4. Layer 3 Access Control A.4. Layer 3 Access Control
It is almost always desirable to prevent one VPN client from sending It is almost always desirable to prevent one VPN client from sending
packets with a source address that is used by another VPN client. In packets with a source address that is used by another VPN client. In
order to correctly forward packets destined to clients, the VPN order to correctly forward packets destined to clients, the VPN
gateway obviously has to know which client is using which address; gateway obviously has to know which client is using which address;
the question is therefore where, architecturally, the mechanisms for the question is therefore where, architecturally, the mechanisms for
ingress filtering are placed. ingress filtering are placed.
o Layer 3 access control enforced by IPsec SAD/SPD: the addresses/ o Layer 3 access control could be enforced by IPsec Security
prefixes assigned to a VPN client are reflected in the traffic Association Database (SAD) / SPD; the addresses/prefixes assigned
selectors used in IPsec Security Association and Security Policy to a VPN client would be reflected in the traffic selectors used
Database entries, as negotiated in IKEv2. in IPsec Security Association and Security Policy Database
entries, as negotiated in IKEv2.
o The ingress filtering capability could be placed outside IPsec; o The ingress filtering capability could be placed outside IPsec;
the traffic selectors in SAD/SPD entries would cover traffic that the traffic selectors in SAD/SPD entries would cover traffic that
would be dropped later by ingress filtering. would be dropped later by ingress filtering.
The former approach is used by the current IPv4 solution, and the The former approach is used by the current IPv4 solution and the
mechanism specified in Section 4. mechanism specified in Section 4.
A.5. Other Considerations A.5. Other Considerations
VPN gateway state VPN gateway state
In some combinations of design choices, the amount of state In some combinations of design choices, the amount of state
information required in the VPN gateway depends not only on the information required in the VPN gateway depends not only on the
number of clients, but also on the number of addresses used by one number of clients but also on the number of addresses used by one
client. With privacy addresses and potentially some uses of client. With privacy addresses and potentially some uses of
Cryptographically Generated Addresses (CGAs), a single client Cryptographically Generated Addresses (CGAs), a single client
could have a large number of different addresses (especially if could have a large number of different addresses (especially if
different privacy addresses are used with different destinations). different privacy addresses are used with different destinations).
Virtual link identifier Virtual link identifier
Reauthentication requires a way to uniquely identify the virtual Reauthentication requires a way to uniquely identify the virtual
link when a second IKE SA is created. Some possible alternatives link when a second IKE SA is created. Some possible alternatives
are the IKE SPIs of the IKE SA where the virtual link was are the IKE Security Parameter Indexes (SPIs) of the IKE SA where
"created" (assuming we can't have multiple virtual links within the virtual link was "created" (assuming we can't have multiple
the same IKE SA), a new identifier assigned when the link is virtual links within the same IKE SA), a new identifier assigned
created, or any unique prefix or address that remains assigned to when the link is created, or any unique prefix or address that
the link for its entire lifetime. Section 4 specifies that the remains assigned to the link for its entire lifetime. Section 4
gateway assigns a new IKEv2 Link ID when the link is created. The specifies that the gateway assigns a new IKEv2 Link ID when the
client treats the Link ID as an opaque octet string; the gateway link is created. The client treats the Link ID as an opaque octet
uses it to identify relevant local state when reauthentication is string; the gateway uses it to identify relevant local state when
done. reauthentication is done.
Note that the link is not uniquely identified by the IKE peer Note that the link is not uniquely identified by the IKE peer
identities (because IDi is often a user identity that can be used identities (because IDi is often a user identity that can be used
on multiple hosts at the same time), or the outer IP addresses of on multiple hosts at the same time) or the outer IP addresses of
the peers (due to NAT Traversal and [MOBIKE]). the peers (due to NAT Traversal and [MOBIKE]).
Prefix lifetime Prefix lifetime
Prefixes could remain valid either for the lifetime of the IKE SA, Prefixes could remain valid either for the lifetime of the IKE SA,
until explicitly cancelled, or for an explicitly specified time. until explicitly cancelled, or for an explicitly specified time.
In Section 4 the prefixes remain valid for the lifetime of the IKE In Section 4, the prefixes remain valid for the lifetime of the
SA (and its continuations via rekeying, but not reauthentication). IKE SA (and its continuations via rekeying but not via
If necessary, the VPN gateway can thus add or remove prefixes by reauthentication). If necessary, the VPN gateway can thus add or
triggering reauthentication. It is assumed that adding or remove prefixes by triggering reauthentication. It is assumed
removing prefixes is a relatively rare situation, and thus this that adding or removing prefixes is a relatively rare situation,
document does not specify more complex solutions (such as explicit and thus this document does not specify more complex solutions
prefix lifetimes, or use of CFG_SET/CFG_ACK). (such as explicit prefix lifetimes or use of CFG_SET/CFG_ACK).
Compatibility with other IPsec uses Compatibility with other IPsec uses
Compatibility with other IPsec uses probably requires that when a Compatibility with other IPsec uses probably requires that when a
CHILD_SA is created, both peers can determine whether the CHILD_SA CHILD_SA is created, both peers can determine whether the CHILD_SA
applies to the virtual interface (at the end of the virtual link), applies to the virtual interface (at the end of the virtual link)
or the real interfaces IKEv2 messages are being sent over. This or the real interfaces over which IKEv2 messages are being sent.
is required to select the correct SPD to be used for traffic This is required to select the correct SPD to be used for traffic-
selector narrowing and SA authorization in general. selector narrowing and SA authorization in general.
One straight-forward solution is to add an extra payload to One straight-forward solution is to add an extra payload to
CREATE_CHILD_SA requests, containing the virtual link identifier. CREATE_CHILD_SA requests, containing the virtual link identifier.
Requests not containing this payload would refer to the real link Requests not containing this payload would refer to the real link
(over which IKEv2 messages are being sent). (over which IKEv2 messages are being sent).
Another solution is to require that the peer requesting a CHILD_SA Another solution is to require that the peer requesting a CHILD_SA
proposes traffic selectors that identify the link. For example, proposes traffic selectors that identify the link. For example,
if TSi includes the peer's "outer" IP address, it's probably if TSi includes the peer's "outer" IP address, it's probably
related to the real interface, not the virtual one. Or if TSi related to the real interface, not the virtual one. Or if TSi
includes any of the prefixes assigned by the gateway (or the link- includes any of the prefixes assigned by the gateway (or the link-
local or multicast prefix), it is probably related to the virtual local or multicast prefix), it is probably related to the virtual
interface. interface.
These heuristics can work in many situations, but have proved These heuristics can work in many situations but have proved
inadequate in the context of IPv6-in-IPv4 tunnels [RFC4891] and inadequate in the context of IPv6-in-IPv4 tunnels [RFC4891],
Provider Provisioned VPNs [VLINK] [RFC3884], and Mobile IPv6 Provider Provisioned VPNs ([VLINK], [RFC3884]), and Mobile IPv6
[RFC4877]. Thus, Section 4 includes the virtual link identifier [RFC4877]. Thus, Section 4 includes the virtual link identifier
in all CREATE_CHILD_SA requests that apply to the virtual in all CREATE_CHILD_SA requests that apply to the virtual
interface. interface.
Example about other IPsec uses: Example of other IPsec uses:
If a VPN gateway receives a CREATE_CHILD_SA request associated If a VPN gateway receives a CREATE_CHILD_SA request associated
with a physical Ethernet interface, requesting SA for (TSi=FE80:: with a physical Ethernet interface, requesting an SA for
something, dst=*), it would typically reject the request (or in (TSi=FE80::something, dst=*), it would typically reject the
other words, narrow it to an empty set) because it doesn't have request (or, in other words, narrow it to an empty set) because it
SPD/PAD entries that would allow joe.user@example.com to request doesn't have SPD/PAD entries that would allow joe.user@example.com
such CHILD_SAs. to request such CHILD_SAs.
(However, it might have SPD/PAD entries that would allow (However, it might have SPD/PAD entries that would allow
"neighboring-router.example.com" to create such SAs, for "neighboring-router.example.com" to create such SAs to protect,
protecting e.g. some routing protocol that uses link-local for example, some routing protocol that uses link-local
addresses.) addresses.)
However, the virtual interface created when joe.user@example.com However, the virtual interface created when joe.user@example.com
authenticated and sent INTERNAL_IP6_LINK would have a different authenticated and sent INTERNAL_IP6_LINK would have a different
SPD/PAD, which would allow joe.user@example.com to create this SA. SPD/PAD, which would allow joe.user@example.com to create this SA.
A.6. Alternative Solution Sketches A.6. Alternative Solution Sketches
A.6.1. Version -00 Sketch A.6.1. Version -00 Sketch
The -00 version of this draft contained the following solution The -00 version of this document contained the following solution
sketch, which is basically a combination of (1) point-to-point link sketch, which is basically a combination of (1) a point-to-point link
model, (2) prefix information distributed in Neighbor Advertisements, model, (2) prefix information distributed in Neighbor Advertisements,
and (3) access control enforced outside IPsec. and (3) access control enforced outside IPsec.
1) During IKE_AUTH, client sends a new configuration attribute, 1. During IKE_AUTH, the client sends a new configuration attribute,
INTERNAL_IP6_LINK, which requests a virtual link to be created. The INTERNAL_IP6_LINK, which requests a virtual link to be created.
attribute contains the client's interface ID for link-local address The attribute contains the client's interface ID for the link-
(other addresses may use other interface IDs). local address (other addresses may use other interface IDs).
CP(CFG_REQUEST) = CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID) } { INTERNAL_IP6_LINK(Link-Local Interface ID) }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->
The VPN gateway replies with its own link-local interface ID (which The VPN gateway replies with its own link-local interface ID (which
has to be different from the client's) and an IKEv2 Link ID (which has to be different from the client's) and an IKEv2 Link ID (which
will be used for reauthentication). will be used for reauthentication).
CP(CFG_REPLY) = CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID) } { INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID) }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
At this point, both peers configure the virtual interface with the At this point, both peers configure the virtual interface with the
link-local addresses. link-local addresses.
2) The next step is IPv6 stateless address autoconfiguration; that 2. The next step is IPv6 stateless address autoconfiguration, that
is, Router Solicitation and Router Advertisement messages sent over is, Router Solicitation and Router Advertisement messages sent
the IPsec SA. over the IPsec SA.
ESP(Router Solicitation: ESP(Router Solicitation:
src=::, src=::,
dst=FF02:0:0:0:0:0:0:2) --> dst=FF02:0:0:0:0:0:0:2) -->
<-- ESP(Router Advertisement: <-- ESP(Router Advertisement:
src=FE80::<Gateway's Interface ID> src=FE80::<Gateway's Interface ID>
dst=FF02:0:0:0:0:0:0:1, dst=FF02:0:0:0:0:0:0:1,
Prefix1, [Prefix2...]) Prefix1, [Prefix2...])
After receiving the Router Advertisement, the client can configure After receiving the Router Advertisement, the client can configure
unicast addresses from the advertised prefixes, using any proper unicast addresses from the advertised prefixes, using any proper
interface ID. The VPN gateway does not simultaneously assign the interface ID. The VPN gateway does not simultaneously assign the
same prefixes to any other client, and does not itself configure same prefixes to any other client and does not itself configure
addresses from these prefixes. Thus, the client does not have to addresses from these prefixes. Thus, the client does not have to
perform Duplicate Address Detection (DAD). perform Duplicate Address Detection (DAD).
3) Reauthentication works basically the same way as in Section 4; the 3. Reauthentication works basically the same way as in Section 4;
client includes the IKEv2 Link ID in the INTERNAL_IP6_LINK attribute. the client includes the IKEv2 Link ID in the INTERNAL_IP6_LINK
attribute.
4) Creating and rekeying IPsec SAs works basically the same way as in 4. Creating and rekeying IPsec SAs works basically the same way as
Section 4.3; the client includes the IKEv2 Link ID in those CHILD_SA in Section 4.3; the client includes the IKEv2 Link ID in those
requests that are related to the virtual link. CHILD_SA requests that are related to the virtual link.
Comments: This was changed in -01 draft based on feedback from VPN Comments: This was changed in the -01 version of this document based
vendors: while the solution looks nice on paper, it is claimed to be on feedback from VPN vendors; while the solution looks nice on paper,
unneccessarily complex to implement when the IKE implementation and it is claimed to be unnecessarily complex to implement when the IKE
IPv6 stack are from different companies. Furthermore, enforcing implementation and IPv6 stack are from different companies.
access control outside IPsec is a significant architectural change Furthermore, enforcing access control outside IPsec is a significant
compared to current IPv4 solutions. architectural change compared to current IPv4 solutions.
A.6.2. Router Aggregation Sketch #1 A.6.2. Router Aggregation Sketch #1
The following solution was sketched during the IETF 70 meeting in Hemant Singh helped sketch the following solution during the IETF 70
Vancouver together with Hemant Singh. It combines the (1) router meeting in Vancouver. It combines (1) the router aggregation link
aggregation link model, (2) prefix information distributed in IKEv2 model, (2) prefix information distributed in IKEv2 messages, (3)
messages, (3) unique address allocation with stateless address unique address allocation with stateless address autoconfiguration
autoconfiguration (with VPN gateway trapping NS messages and spoofing (with VPN gateway trapping NS messages and spoofing NA replies), and
NA replies), and (4) access control enforced (partly) outside IPsec. (4) access control enforced (partly) outside IPsec.
1) During IKE_AUTH, the client sends a new configuration attribute, 1. During IKE_AUTH, the client sends a new configuration attribute,
INTERNAL_IP6_LINK, which requests a virtual link to be created. The INTERNAL_IP6_LINK, which requests a virtual link to be created.
attribute contains the client's interface ID for link-local address The attribute contains the client's interface ID for the link-
(other addresses may use other interface IDs). local address (other addresses may use other interface IDs).
CP(CFG_REQUEST) = CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID) } { INTERNAL_IP6_LINK(Link-Local Interface ID) }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->
The VPN gateway replies with its own link-local interface ID (which The VPN gateway replies with its own Link-Local Interface ID (which
has to be different from the client's), an IKEv2 Link ID (which will has to be different from the client's), an IKEv2 Link ID (which will
be used for reauthentication and CREATE_CHILD_SA messages), and zero be used for reauthentication and CREATE_CHILD_SA messages), and zero
or more INTERNAL_IP6_PREFIX attributes. The traffic selectors or more INTERNAL_IP6_PREFIX attributes. The traffic selectors
proposed by the initiator are also narrowed to contain only the proposed by the initiator are also narrowed to contain only the
assigned prefixes (and the link-local prefix). assigned prefixes (and the link-local prefix).
CP(CFG_REPLY) = CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID), { INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID),
INTERNAL_IP6_PREFIX(Prefix1/64), INTERNAL_IP6_PREFIX(Prefix1/64),
[INTERNAL_IP6_PREFIX(Prefix2/64),...], [INTERNAL_IP6_PREFIX(Prefix2/64),...] }
INTERNAL_IP6_DHCP(Address) ] TSi = ((0, 0-65535,
TSi = ((0, 0-65535, FE80::<Client's Interface ID> -
FE80::<Client's Interface ID> - FE80::<Client's Interface ID>)
FE80::<Client's Interface ID>) (0, 0-65535,
(0, 0-65535, Prefix1::0 -
Prefix1::0 - Prefix1::FFFF:FFFF:FFFF:FFFF),
Prefix1::FFFF:FFFF:FFFF:FFFF), [(0, 0-65535,
[(0, 0-65535, Prefix2::0 -
Prefix2::0 - Prefix2::FFFF:FFFF:FFFF:FFFF), ...])
Prefix2::FFFF:FFFF:FFFF:FFFF), ...]) TSr = (0, 0-65535,
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
0:0:0:0:0:0:0:0 - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
2) The client now configures tentative unicast addresses from the 2. The client now configures tentative unicast addresses from the
prefixes given by the gateway, and performs Duplicate Address prefixes given by the gateway, and performs Duplicate Address
Detection (DAD) for them. Detection (DAD) for them.
The Neighbor Solicitation messages are processed by the VPN gateway: The Neighbor Solicitation messages are processed by the VPN
if the target address is already in use by some other VPN client, the gateway; if the target address is already in use by some other
gateway replies with a Neighbor Advertisement. If the target address VPN client, the gateway replies with a Neighbor Advertisement.
is not already in use, the VPN gateway notes that it is now being If the target address is not already in use, the VPN gateway
used by this client, and updates its forwarding state accordingly. notes that it is now being used by this client and updates its
forwarding state accordingly.
Comments: The main disadvantages of this solution are non-standard Comments: The main disadvantages of this solution are non-standard
processing of NS messages (which are used to update the gateway's processing of NS messages (which are used to update the gateway's
forwarding state), and performing access control partly outside forwarding state), and performing access control partly outside
IPsec. IPsec.
A.6.3. Router Aggregation Sketch #2 A.6.3. Router Aggregation Sketch #2
This is basically similar to the version -00 sketch described with This is basically similar to the version -00 sketch described above
above, but uses router aggregation link model. In other words, it but uses the router aggregation link model. In other words, it
combines (1) router aggregation link model, (2) prefix information combines (1) the router aggregation link model, (2) prefix
distributed in Neighbor Advertisements, (3) unique address allocation information distributed in Neighbor Advertisements, (3) unique
with stateless address autoconfiguration (with VPN gateway trapping address allocation with stateless address autoconfiguration (with the
NS messages and spoofing NA replies), and (4) access control enforced VPN gateway trapping NS messages and spoofing NA replies), and (4)
outside IPsec. access control enforced outside IPsec.
1) During IKE_AUTH, client sends a new configuration attribute, 1. During IKE_AUTH, the client sends a new configuration attribute,
INTERNAL_IP6_LINK, which requests a virtual link to be created. The INTERNAL_IP6_LINK, which requests a virtual link to be created.
attribute contains the client's interface ID for link-local address The attribute contains the client's interface ID for the link-
(other addresses may use other interface IDs). local address (other addresses may use other interface IDs).
CP(CFG_REQUEST) = CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID) } { INTERNAL_IP6_LINK(Link-Local Interface ID) }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->
The VPN gateway replies with its own link-local interface ID (which The VPN gateway replies with its own Link-Local Interface ID (which
has to be different from the client's) and an IKEv2 Link ID (which has to be different from the client's) and an IKEv2 Link ID (which
will be used for reauthentication). will be used for reauthentication).
CP(CFG_REPLY) = CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID) } { INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID) }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
At this point, both peers configure the virtual interface with the At this point, both peers configure the virtual interface with the
link-local addresses. link-local addresses.
2) The next step is IPv6 stateless address autoconfiguration; that 2. The next step is IPv6 stateless address autoconfiguration, that
is, Router Solicitation and Router Advertisement messages sent over is, Router Solicitation and Router Advertisement messages sent
the IPsec SA. over the IPsec SA.
ESP(Router Solicitation: ESP(Router Solicitation:
src=::, src=::,
dst=FF02:0:0:0:0:0:0:2) --> dst=FF02:0:0:0:0:0:0:2) -->
<-- ESP(Router Advertisement: <-- ESP(Router Advertisement:
src=FE80::<Gateway's Interface ID> src=FE80::<Gateway's Interface ID>
dst=FF02:0:0:0:0:0:0:1, dst=FF02:0:0:0:0:0:0:1,
Prefix1, [Prefix2...]) Prefix1, [Prefix2...])
3) The client now configures tentative unicast addresses from the 3. The client now configures tentative unicast addresses from the
prefixes given by the gateway, and performs Duplicate Address prefixes given by the gateway and performs Duplicate Address
Detection (DAD) for them. Detection (DAD) for them.
The Neighbor Solicitation messages are processed by the VPN gateway: The Neighbor Solicitation messages are processed by the VPN
if the target address is already in use by some other VPN client, the gateway; if the target address is already in use by some other
gateway replies with a Neighbor Advertisement. If the target address VPN client, the gateway replies with a Neighbor Advertisement.
is not already in use, the VPN gateway notes that it is now being If the target address is not already in use, the VPN gateway
used by this client, and updates its forwarding state accordingly. notes that it is now being used by this client and updates its
forwarding state accordingly.
Comments: The main disadvantages of this solution are non-standard Comments: The main disadvantages of this solution are non-standard
processing of NS messages (which are used to update the gateway's processing of NS messages (which are used to update the gateway's
forwarding state), and performing access control outside IPsec. forwarding state) and performing access control outside IPsec.
A.6.4. IPv4-like Sketch A.6.4. IPv4-Like Sketch
This sketch resembles the current IPv4 configuration payloads, and it This sketch resembles the current IPv4 configuration payloads and
combines (1) router aggregation link model, (2) prefix information combines (1) the router aggregation link model, (2) prefix
distributed in IKEv2 messages, (3) unique address allocation with information distributed in IKEv2 messages, (3) unique address
IKEv2 messages, and (4) access control enforced by IPsec SAD/SPD. allocation with IKEv2 messages, and (4) access control enforced by
IPsec SAD/SPD.
1) During IKE_AUTH, the client sends a new configuration attribute, 1. During IKE_AUTH, the client sends a new configuration attribute,
INTERNAL_IP6_LINK, which requests a virtual link to be created. The INTERNAL_IP6_LINK, which requests a virtual link to be created.
attribute contains the client's interface ID for link-local address The attribute contains the client's interface ID for the link-
(other addresses may use other interface IDs). local address (other addresses may use other interface IDs).
CP(CFG_REQUEST) = CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID) } { INTERNAL_IP6_LINK(Link-Local Interface ID) }
TSi = (0, 0-65535, TSi = (0, 0-65535,
0:0:0:0:0:0:0:0 - 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, TSr = (0, 0-65535,
0:0:0:0:0:0:0:0 - 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->
The VPN gateway replies with its own link-local interface ID (which The VPN gateway replies with its own Link-Local Interface ID (which
has to be different from the client's), an IKEv2 Link ID (which will has to be different from the client's), an IKEv2 Link ID (which will
be used for reauthentication and CREATE_CHILD_SA messages), and zero be used for reauthentication and CREATE_CHILD_SA messages), and zero
or more INTERNAL_IP6_ADDRESS2 attributes. Each attribute contains or more INTERNAL_IP6_ADDRESS2 attributes. Each attribute contains
one address from a particular prefix. one address from a particular prefix.
CP(CFG_REPLY) = CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID), { INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID),
INTERNAL_IP6_ADDRESS2(Prefix1+Client's Interface ID1), INTERNAL_IP6_ADDRESS2(Prefix1+Client's Interface ID1),
[INTERNAL_IP6_ADDRESS2(Prefix2+Client's Interface ID2),...], [INTERNAL_IP6_ADDRESS2(Prefix2+Client's Interface ID2),...],
TSi = ((0, 0-65535, TSi = ((0, 0-65535,
FE80::<Client's Link-Local Interface ID> - FE80::<Client's Link-Local Interface ID> -
FE80::<Client's Link-Local Interface ID>) FE80::<Client's Link-Local Interface ID>)
(0, 0-65535, (0, 0-65535,
Prefix1::<Client's Interface ID1> - Prefix1::<Client's Interface ID1> -
Prefix1::<Client's Interface ID1>), Prefix1::<Client's Interface ID1>),
[(0, 0-65535, [(0, 0-65535,
Prefix2::<Client's Interface ID2> - Prefix2::<Client's Interface ID2> -
Prefix2::<Client's Interface ID2>), ...]) Prefix2::<Client's Interface ID2>), ...])
TSr = (0, 0-65535, TSr = (0, 0-65535,
0:0:0:0:0:0:0:0 - 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
Since the VPN gateway keeps track of address uniqueness, there is no Since the VPN gateway keeps track of address uniqueness, there is no
need to perform Duplicate Address Detection. need to perform Duplicate Address Detection.
2) If the client wants additional addresses later (for example, with 2. If the client wants additional addresses later (for example, with
specific interface ID), it requests them in a separate a specific interface ID), it requests them in a separate
CREATE_CHILD_SA exchange. For example: CREATE_CHILD_SA exchange. For example:
CP(CFG_REQUEST) = CP(CFG_REQUEST) =
{ INTERNAL_IP6_ADDRESS2(Prefix1+Client's Interface ID3) } { INTERNAL_IP6_ADDRESS2(Prefix1+Client's Interface ID3) }
TSi = (0, 0-65535, TSi = (0, 0-65535,
Prefix1::0 - Prefix1::0 -
Prefix1::FFFF:FFFF:FFFF:FFFF>), Prefix1::FFFF:FFFF:FFFF:FFFF>),
TSr = (0, 0-65535, TSr = (0, 0-65535,
0:0:0:0:0:0:0:0 - 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->
If the requested address is not currently in use by some other If the requested address is not currently in use by some other
client, the VPN gateway simply returns the same address, and traffic client, the VPN gateway simply returns the same address and the
selectors narrowed appropriately. appropriately narrowed traffic selectors.
CP(CFG_REQUEST) = CP(CFG_REQUEST) =
{ INTERNAL_IP6_ADDRESS2(Prefix1+Client's Interface ID3) } { INTERNAL_IP6_ADDRESS2(Prefix1+Client's Interface ID3) }
TSi = ((0, 0-65535, TSi = ((0, 0-65535,
Prefix1::<Client's Interface ID3> - Prefix1::<Client's Interface ID3> -
Prefix1::<Client's Interface ID3>), Prefix1::<Client's Interface ID3>),
TSr = (0, 0-65535, TSr = (0, 0-65535,
0:0:0:0:0:0:0:0 - 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
Comments: The main advantage of this solution is that it's quite Comments: The main advantage of this solution is that it's quite
close to the current IPv4 way of doing things. By adding explicit close to the current IPv4 way of doing things. By adding explicit
link creation (with Link ID for reauthentication/SPD selection, and link creation (with Link ID for reauthentication/SPD selection and
link-local addresses), and slightly changing the semantics (and also link-local addresses) and slightly changing the semantics (and also
name) of INTERNAL_IP6_ADDRESS attribute (can return more attributes name) of the INTERNAL_IP6_ADDRESS attribute (which can return more
than was asked), we get much of the needed functionality. attributes than was asked), we get much of the needed functionality.
The biggest disadvantages are probably potentially complex The biggest disadvantages are probably potentially complex
implementation dependency for interface ID selection (see implementation dependency for interface ID selection (see
Section 3.3), and the multi-link subnet model. Section 3.3) and the multi-link subnet model.
A.6.5. Sketch Based on RFC 3456 A.6.5. Sketch Based on RFC 3456
For completeness: a solution modeled after [RFC3456] would combine For completeness: a solution modeled after [RFC3456] would combine
(1) router aggregation link model, (2) prefix information (1) the router aggregation link model, (2) prefix information
distribution and unique address allocation with DHCPv6, and (3) distribution and unique address allocation with DHCPv6, and (3)
access control enforced by IPsec SAD/SPD. access control enforced by IPsec SAD/SPD.
Appendix B. Evaluation (Non-Normative) Appendix B. Evaluation (Non-Normative)
Section 3described the goals and requirements for IPv6 configuration Section 3 describes the goals and requirements for IPv6 configuration
in IKEv2. This appendix briefly summarizes how the solution in IKEv2. This appendix briefly summarizes how the solution
specified in Section 4 and Section 5 meets these goals. specified in Sections 4 and 5 meets these goals.
o (3.1) Assigning addresses from multiple prefixes is supported, o (3.1) Assigning addresses from multiple prefixes is supported,
without requiring the client to know beforehand how many prefixes without requiring the client to know beforehand how many prefixes
are needed. are needed.
o (3.2) Link-local addresses are assigned, and can be used for o (3.2) Link-local addresses are assigned and can be used for
protocols between the VPN client and gateway. protocols between the VPN client and gateway.
o (3.3) The entire prefix is assigned to a single client, so the o (3.3) The entire prefix is assigned to a single client, so the
client can freely select any number of interface IDs (which may client can freely select any number of interface IDs (which may
depend on the prefix.) depend on the prefix).
o (3.4) This document does not specify how the VPN client would o (3.4) This document does not specify how the VPN client would
share the VPN connection with other devices. However, since the share the VPN connection with other devices. However, since the
entire prefix is assigned to a single client, the client could entire prefix is assigned to a single client, the client could
further assign addresses from it without requiring coordination further assign addresses from it without requiring coordination
with the VPN gateway. with the VPN gateway.
o (3.5) The solution does not add any new periodic messages over the o (3.5) The solution does not add any new periodic messages over the
VPN tunnel. VPN tunnel.
o (3.5) Re-authentication works (see Section 4.2.) o (3.5) Reauthentication works (see Section 4.2).
o (3.5) The solution is compatible with other IPsec uses, since the o (3.5) The solution is compatible with other IPsec uses since the
LINK_ID notification makes it unambiguous which CHILD_SAs are LINK_ID notification makes it unambiguous which CHILD_SAs are
related to the virtual link and which are not (see Section 4.3 and related to the virtual link and which are not (see Sections 4.3
Section 5.3.) and 5.3).
o (3.5) The new mechanisms do not prevent the VPN client and/or o (3.5) The new mechanisms do not prevent the VPN client and/or
gateway from implementing the INTERNAL_IP6_ADDRESS configuration gateway from implementing the INTERNAL_IP6_ADDRESS configuration
attribute as well; however, the two mechanisms are not intended to attribute as well; however, the two mechanisms are not intended to
be used simultaneously (see Section 4.5.) be used simultaneously (see Section 4.5).
o (3.5) Implementation dependencies are, obviously, implementation o (3.5) Implementation dependencies are, obviously, implementation
dependant (and their cleanliness somewhat subjective.) Possible dependent (and their cleanliness somewhat subjective). Possible
drawbacks of some alternative solutions are discussed in drawbacks of some alternative solutions are discussed in
Appendix A.6. Appendix A.6.
o (3.5) The mechanism for configuring the prefixes (configuration o (3.5) The mechanism for configuring the prefixes (configuration
payloads) is specific to IKEv2, for reasons described in payloads) is specific to IKEv2, for reasons described in
Appendix A. However, Section 4.1 recommends using DHCPv6 Appendix A. However, Section 4.1 recommends using DHCPv6
Information-Request message for obtaining other configuration Information-Request message for obtaining other configuration
information (such as DNS server addresses.) information (such as DNS server addresses).
Authors' Addresses Authors' Addresses
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
QUALCOMM Incorporated QUALCOMM Incorporated
5775 Morehouse Drive 5775 Morehouse Drive
San Diego, CA 92121 San Diego, CA 92121
USA USA
Phone: +1 858 858 3538 Phone: +1 858 658 3538
Email: julienl@qualcomm.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. 184 change blocks. 
567 lines changed or deleted 565 lines changed or added

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