GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5739

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5739.txt · Last modified: 2010/02/18 01:44 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki