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