Network Working Group                                          P. Eronen
Internet-Draft                                                     Nokia
Intended status: Standards Track Experimental                                J. Laganier
Expires: May 22, December 19, 2009                              DOCOMO Euro-Labs
                                                               C. Madson
                                                           Cisco Systems
                                                       November 18, 2008
                                                           June 17, 2009

                      IPv6 Configuration in IKEv2
                draft-ietf-ipsecme-ikev2-ipv6-config-00
                draft-ietf-ipsecme-ikev2-ipv6-config-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she

   This Internet-Draft is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, submitted to IETF in accordance full conformance with Section 6 the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 22, December 19, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   When 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 describes the
   limitations of current IKEv2 specifies new
   configuration payloads attributes for IPv6, and
   explores possible solutions that would allow IKEv2 that allows the VPN gateway to set up full-
   featured virtual
   assign IPv6 prefixes to clients, enabling all features of IPv6 interfaces. to be
   used with the client-gateway "virtual link".

Table of Contents

   1.  Introduction and Problem Statement . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Current Limitations  . . . . . and Goals  . . . . . . . . . . . . . . . .  7
     3.1.  Multiple Prefixes  . . . . . . . . . . . . . . . . . . . .  7
     3.2.  Link-Local Addresses . . . . . . . . . . . . . . . . . . .  7
     3.3.  Receiving Multicast Traffic  .  Interface Identifier Selection . . . . . . . . . . . . . .  7
     3.4.  Interface Identifier Selection  Sharing VPN Access . . . . . . . . . . . . . .  7 . . . . . .  8
     3.5.  Sharing VPN Access  General Goals  . . . . . . . . . . . . . . . . . . . . . .  8
     3.6.  Additional Information .  Non-Goals  . . . . . . . . . . . . . . . . .  8
   4.  Design Goals . . . . . . .  9
     3.7.  Additional Information . . . . . . . . . . . . . . . . . .  9
     4.1.  Main Requirements  . .
   4.  Solution Details . . . . . . . . . . . . . . . . . .  9
     4.2.  Desirable Non-Functional Properties . . . . . 10
     4.1.  Initial Exchanges  . . . . . . 10
     4.3.  Implementation Considerations . . . . . . . . . . . . . . 10
     4.4.  Non-Goals
     4.2.  Reauthentication . . . . . . . . . . . . . . . . . . . . . 11
     4.3.  Creating CHILD_SAs . . . 10
   5.  Solution Discussion . . . . . . . . . . . . . . . . . 12
     4.4.  Relationship to Neighbor Discovery . . . . 11
     5.1.  Link Model . . . . . . . . 12
     4.5.  Relationship to Existing IKEv2 Payloads  . . . . . . . . . 13
   5.  Payload Formats  . . . . . . . 12
     5.2.  Distributing Prefix Information . . . . . . . . . . . . . 12
     5.3.  Unique Address Allocation . . . 14
     5.1.  INTERNAL_IP6_LINK Configuration Attribute  . . . . . . . . 14
     5.2.  INTERNAL_IP6_PREFIX Configuration Attribute  . . . . . 13
     5.4.  Layer 3 Access Control . . 14
     5.3.  LINK_ID Notify Payload . . . . . . . . . . . . . . . . 13
     5.5.  Other Considerations . . 15
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . 14
   6.  Solution Sketch . . . . 16
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
     6.1.  Initial Exchanges  . . . . . . . . . . . . . . . . . . 17
   8.  Acknowledgments  . . 16
     6.2.  Reauthentication . . . . . . . . . . . . . . . . . . . . . 18
     6.3.  Creating CHILD_SAs . . . . . . . . . . .
   9.  References . . . . . . . . . 18
     6.4.  Multicast . . . . . . . . . . . . . . . . . 19
     9.1.  Normative References . . . . . . . 18
     6.5.  Relationship to Neighbor Discovery . . . . . . . . . . . . 19
     6.6.  Relationship to Existing IKEv2 Payloads  . . . . .
     9.2.  Informative References . . . . 19
   7.  Payload Formats . . . . . . . . . . . . . . 19
   Appendix A.  Design Rationale (Non-Normative)  . . . . . . . . . 21
     7.1.  INTERNAL_IP6_LINK Configuration Attribute . 22
     A.1.  Link Model . . . . . . . 21
     7.2.  INTERNAL_IP6_PREFIX Configuration Attribute . . . . . . . 21
     7.3.  LINK_ID Notify Payload . . . . . . . . . . 22
     A.2.  Distributing Prefix Information  . . . . . . . . 22
   8.  IANA Considerations . . . . . 23
     A.3.  Unique Address Allocation  . . . . . . . . . . . . . . . . 23
   9.  Security Considerations  .
     A.4.  Layer 3 Access Control . . . . . . . . . . . . . . . . . . 24
   10. Acknowledgments  . . . .
     A.5.  Other Considerations . . . . . . . . . . . . . . . . . . . 25
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 26
     11.2. Informative References . . . . . . . . . . . . . . . . . . 26
   Appendix A.
     A.6.  Alternative Solution Sketches  . . . . . . . . . . . . 29
     A.1. . . 27
       A.6.1.  Version -00 Sketch . . . . . . . . . . . . . . . . . . . . 29
     A.2. 27
       A.6.2.  Router Aggregation Sketch #1 . . . . . . . . . . . . . . . 30
     A.3. 28
       A.6.3.  Router Aggregation Sketch #2 . . . . . . . . . . . . . . . 31
     A.4. 29
       A.6.4.  IPv4-like Sketch . . . . . . . . . . . . . . . . . . . . . 33
     A.5. 31
       A.6.5.  Sketch Based on RFC 3456 . . . . . . . . . . . . . . . . . 34 32
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
   Intellectual Property and Copyright Statements . . . . . . . . . . 36 33

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(10.11.22.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:

      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".  The IPsec tunnels are not full-
   featured "interfaces" 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 addressing architecture [IPv6Addr]
   sense.  For example, they do not necessarily have link-local
   addresses, and this may complicate the use of protocols that assume
   them.

   This document describes what exactly are the limitations of current
   IKEv2 configuration payloads for IPv6, and explores possible
   solutions that would allow IKEv2-based VPNs prefixes to set up full-featured
   virtual clients, enabling
   all features of IPv6 interfaces. 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].

   When messages containing IKEv2 payloads are described, optional
   payloads are shown in brackets (for instance, "[FOO]"), and 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 interface", as
   only addresses assigned to interfaces can be used, e.g., as source
   addresses for TCP connections). connections.  Note that this definition of
   "interface" is not necessarily identical with what some particular
   implementation calls "interface".

3.  Current Limitations and Goals

   This section explores describes the limitations of the current IPv6
   configuration mechanism.

   The IKEv2 specification does not always fully describe the semantics
   associated with configuration payloads, only their on-the-wire
   format.  This section assumes the semantics implied by Figure 2.  It
   is possible that many of the limitations described here could be
   solved by specifying additional semantics mechanism, and requirements for these configuration
   payloads. 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 address 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]

3.3.  Receiving Multicast Traffic

   Even if MLD would work, [DHCPv6].

   The solution should assign link-local addresses to the traffic selectors negotiated in Figure 2
   do not virtual
   interfaces, and allow receiving multicast traffic.

3.4. 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 Generates
   Addresses [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 provides 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].

3.5.

   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).

   It is to be determined how common this use case would actually be;
   e.g., how likely it is that Bluetooth), if
   allowed by the security policies would allow this. 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. 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.

3.6.  Additional Information

   The original 3GPP standards for IPv6 assigned solution should support sharing the VPN access over a single IPv6 local area
   network connection when the other hosts are using stateless 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.

   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 should be avoided.

4.  Design
   autoconfiguration.

3.5.  General Goals

4.1.  Main Requirements

   o  A VPN client can obtain several addresses from a given prefix; the
      interface IDs can be selected by the client, and may depend on the
      prefix.

   o  A VPN client can be assigned multiple prefixes for use on the
      client-gateway link.  The client does not have to know beforehand
      how many prefixes are needed.

   o  The solution should avoid periodic messages over the VPN tunnel.

   o  The solution should avoid Duplicate Address Detection (DAD) over
      the VPN tunnel.

   o  Multicast works.  That is, the client is able to send multicast
      packets (tunneled to the gateway via unicast), join multicast
      groups using [MLDv2], and receive multicast packets (tunneled from
      the gateway to the client via unicast).

   o  It should be possible to share the VPN access over a local area
      network connection, without requiring anything special from other
      hosts in the local network (beyond minimal IPv6 node requirements
      specified in [RFC4294]).

   o  Re-authentication works: the client can start a new IKE SA and
      continue using the same "virtual link" (with same addresses,
      etc.). addresses as before.

   o  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. uses (with other
      addresses).  In particular, the peers may have SPD entries and PAD
      Child SA Authorization Data entries that are not related to the
      virtual link; when a CHILD_SA is created, it should be unambigous
      which entries are used.

   o  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  Compatibility with current IPv4 configuration: it should be
      possible to use the existing IPv4 configuration mechanism within
      the same IKE SA.

   o  (Optional/To be determined) When the client is also a router (to
      some local network), it should be able to use DHCPv6 prefix
      delegation [RFC3633] over the virtual link.

4.2.  Desirable Non-Functional Properties

   Note that the following desirable properties may be somewhat
   conflicting.

   o  Re-use existing mechanisms, such as [AUTOCONF] and [DHCPv6] as
      much as possible; as explained in [IPConfig], creating IKEv2-
      specific mechanisms should be avoided.

   o  Avoid the Not Invented Here (NIH) syndrome: There were several
      proposals how to do IP address configuration in IKEv2, and the
      IPsec WG chose one of them.  Any significant changes should be
      motivated by real technical needs, not by dislike of the proposal
      that was chosen.

4.3.  Implementation Considerations

   The solution should have clean implementation dependencies.  In
   particular,  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 IKE IKEv2 implementor to re-implement parts of the IPv6
      stack (to, e.g., have access or control to functionality that is
      currently not exposed by public interfaces of the IPv6 stack).

4.4.

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.

5.  Solution Discussion

   Assigning a new IPv6 address to

3.7.  Additional Information

   If the VPN client creates a new "virtual is assigned IPv6 interface", and "virtual link" between the client and the
   gateway.  We will assume address(es) from prefix(es) that the virtual link has the following
   properties:

   o  The link and its interfaces
   are created shared with other VPN clients, this results in some kind of
   multi-link subnet.  [Multilink] describes issues associated with
   multi-link subnets, and destroyed by the IKEv2
      process.

   o recommends that they should be avoided.

   The original 3GPP standards for IPv6 addresses and prefixes are assigned a single IPv6 address
   to the link and its
      interfaces by IKEv2 messages, and are removed once they are no
      longer used by any IKE SA.  An each mobile phone, resembling current IKEv2 implementation may delay
      removal of payloads.  [RFC3314]
   described the IPv6 addresses problems with this approach, and prefixes for a period of time caused 3GPP to
      allow upper layer protocol communications (e.g., a TCP connection) change
   the specifications to survive an IKE SA re-authentication that would use assign unique /64 prefix(es) for each phone.

   Due to similar concerns, the same
      addresses IEEE 802.16 IPv6 Convergence Sublayer
   [RFC5121] and Proxy Mobile IPv6 [RFC5213] also assign unique
   prefixes.

   o  The

4.  Solution Details

4.1.  Initial Exchanges

   1) During IKE_AUTH, the client sends a new configuration attribute,
   INTERNAL_IP6_LINK, which requests a virtual link is not an IPsec SA; at any time, there can to be zero or
      more IPsec SAs covering traffic on this link.

   o configured.
   The link 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 DHCPv6 server address; this is used
   only for configuration (such as DNS server addresses), not a single IKE SA; to support reauthentication, it
      must be possible to identify 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 same link in another IKE SA.

   o  It is TBD whether a single IKE SA needs to support multiple
      virtual links.  (Possibly not; if multiple virtual links are
      needed, multiple IKE_SAs could be used.)

   o  Not all IPsec-protected traffic between client has sent the peers is necessarily
      related to INTERNAL_IP6_LINK configuration attribute,
   the virtual link (although VPN gateway SHOULD ignore any INTERNAL_IP6_ADDRESS configuration
   attribute present in the simplest request.

   The VPN client-
      to-gateway scenario it will be).

   Given these assumptions and gateway MUST choose for itself a link-local interface
   identifier different than the goals described in client's one, i.e., accept the previous
   section, it seems that link-
   local interface identifier proposed by the most important design choices to be made
   are client.  In case the following:

   o  What link/subnet model is used: in other words, the relationships
      between VPN clients, IPv6 subnet prefixes, and link-local traffic
      (especially
   gateway cannot accept the link-local multicast).

   o  How information about interface identifier the IPv6 prefix(es) is distributed from client
   proposed, the VPN gateway to MUST fail 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 assignment by clients are placed
      architecturally.

   Each of these is discussed next in turn.

5.1.  Link Model

   There are at least three main choices 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
   including a NOTIFY payload 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 INTERNAL_ADDRESS_FAILURE message.

   The VPN clients share Gateway then replies with an INTERNAL_IP6_LINK configuration
   attribute that contains the same IPv6
      prefix.  Link-local multicast packets sent IKEv2 Link ID (an identifier selected by one
   the VPN gateway, treated as an opaque octet string by the client --
   this will be received used for reauthentication and CREATE_CHILD_SA messages),
   the gateway's link local interface identier, and zero or more
   INTERNAL_IP6_PREFIX attributes.  The traffic selectors proposed by other VPN clients (VPN gateway will forward
   the
      packets, possibly with MLD snooping initiator are also narrowed to remove unnecessary
      packets).

   o  "Router aggregation" link model: one form of "multi-link" subnet
      [Multilink] where multiple VPN clients share contain only the same IPv6 prefix.
      Link-local multicast will not be received by other VPN clients.

   In assigned
   prefixes, and 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 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 clients are battery-powered; for
   example, a PDA which keeps 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 connection gateway MUST NOT simultaneously
   assign the same prefixes to corporate intranet
   active 24/7.  For this reason, we will not consider any other client, and MUST NOT itself
   configure addresses from these prefixes.  Thus, the multi-access
   link model in client does not
   have to perform Duplicate Address Detection (DAD).  (This approach is
   based on [IPv6PPP].)

   The prefixes remain valid through the rest of this document.

5.2.  Distributing Prefix Information

   Some types lifetime of addresses, such as CGAs, require knowledge about the IKE SA (and its
   continuations via rekeying).  If the VPN gateway needs to remove a
   prefix before an address it has previously assigned, or assign a new prefix, it can be generated.  The prefix information
   could be distributed to clients in do
   so with reauthentication (either starting reauthentication itself, or
   requesting the following ways:

   o  IKEv2 messages (Configuration Payloads).

   o  Router Advertisement messages (sent over client to reauthenticate using [RFC4478]).

   2) The client also contacts the IPsec tunnel).

   o DHCPv6 messages (sent over the IPsec tunnel).

5.3.  Unique Address Allocation

   In the "multi-access" and "router aggregation" link models (where a
   single IPv6 prefix server.  This 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
   RECOMMENDED way to know
   which 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).

4.2.  Reauthentication

   When the client is using which addresses in order to correctly forward
   traffic.

   The main choices seem performs reauthentication (and wants to be continue
   using the following:

   o  Clients receive same "virtual link"), it includes the address(es) they are allowed to use 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
      messages (Configuration Payloads).  In this case, keeping track of
      which client is using which address is trivial.

   o  Clients receive 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)  -->

   The gateway uses the address(es) they are allowed Link ID to use in DHCPv6
      messages sent over look up relevant local state,
   verifies that the IPsec tunnel.  In case authenticated peer identity associated with the DHCPv6 server
   link is
      not integrated with correct, and continues the VPN gateway, handshake as usual.

4.3.  Creating CHILD_SAs

   When a CHILD_SA is created, the gateway may peers need to work
      as a relay agent to keep track of which client is using determine which
      address (and update its forwarding state accordingly).

   o  Clients can use stateless address autoconfiguration to configure
      addresses SPD
   entries and perform Duplicate Address Detection (DAD).  This PAD Child SA Authorization Data entries are used for this
   CHILD_SA.  In the basic client-to-VPN-gateway uses, the situation is
      easy to do in multi-access link model, and can be made to work
      with router aggretation link model if
   simple: all the VPN gateway traps NS
      messages matching SPD entries and spoofs 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 Child SA Authorization Data
   entries are related to the point-to-point link model, "virtual link" between the VPN client can simply use any
   address from the prefix, and
   the VPN gateway only needs to know which
   client is gateway.  However, if the same peers are also using which prefix in order to forward packets correctly.

5.4.  Layer 3 Access Control

   It is almost always desirable to prevent one VPN client from sending
   packets with a source address 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 used by another VPN client.  In
   order to correctly forward packets destined to clients, the VPN
   gateway obviously has not related 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 enforced by IPsec SAD/SPD: virtual link.

   If one of the addresses/
      prefixes assigned to peers requests a VPN client are reflected in the CHILD_SA and proposes traffic
   selectors used covering everything (like in IPsec Security Association and Security Policy
      Database entries, as negotiated in IKEv2.

   o  The ingress filtering capability could Figure 2), should those be placed outside IPsec;
   narrowed to the traffic selectors in SAD/SPD entries would cover traffic that
      would be dropped later by ingress filtering.

   The former approach is used by prefixes configured with INTERNAL_IP6_PREFIX, or to
   the current IPv4 solution.

5.5.  Other Considerations

   VPN gateway state

      In other SPD/PAD entries?  While some combinations kind of design choices, heuristics are
   possible (see Appendix A for discussion), this document specifies an
   explicit solution:

   The peers MUST include a LINK_ID notification, containing the amount of state
      information required IKEv2
   Link ID, in all CREATE_CHILD_SA requests (including rekeys) that are
   related to the VPN gateway depends virtual link.  The LINK_ID notification is not only on
   included in the
      number of clients, but also on CREATE_CHILD_SA response, or when doing IKE_SA
   rekeying.

4.4.  Relationship to Neighbor Discovery

   Neighbor Discovery [IPv6ND] specifies the number of addresses used by one
      client.  With privacy addresses following mechanisms:

   Router Discovery, Prefix Discovery, Parameter Discovery, 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 Address
   Autoconfiguration are used with different destinations).

   Virtual link identifier

      Reauthentication requires a way to uniquely identify not used, as the virtual
      link when a second IKE SA necessary functionality is created.  Some possible alternatives
   implemented in IKEv2.

   Address Resolution, Next-hop Determination, and Redirect are the IKE SPIs of the IKE SA where not
   used, as the virtual link was
      "created" (assuming we can't does not have multiple virtual links within
      the same IKE SA), a new identifier assigned when the link link-layer addresses, and is
      created, or any unique prefix or address that remains assigned to
      the link for its entire lifetime.  Currently, Section 6 proposes
      that the gateway assigns
   a new point-to-point link.

   Neighbor Unreachability Detection could be used, but is a bit
   redundant given IKEv2 Link ID when the link Dead Peer Detection.

   Duplicate Address Detection is
      created.  The client treats the Link ID as an opaque octet string;
      the gateway uses it to identify relevant local state when
      reauthentication not needed, because this is done.

      Note that a point-
   to-point link, where the link is VPN gateway does not uniquely identified by assign any addresses
   from the IKE peer
      identities (because IDi global unicast prefixes, and link-local interface identifier
   is often a user identity that can negotiated separately.

4.5.  Relationship to Existing IKEv2 Payloads

   The mechanism described in this document is not intended to be used
      on multiple hosts
   at the same time), or the outer IP addresses of
      the peers (due to NAT Traversal and [MOBIKE]).

   Prefix lifetime

      Prefixes could remain valid either for time as the lifetime of existing INTERNAL_IP6_ADDRESS attribute.  For
   compatibility with gateways implementing only INTERNAL_IP6_ADDRESS,
   the IKE SA,
      until explicitly cancelled, or for an explicitly specified time.
      Currently, Section 6 proposes that prefixes remain valid VPN client MAY include attributes for the
      lifetime both mechanisms in
   CFG_REQUEST.  The capabilities and preferences of the IKE SA (and its continuations via rekeying, but
      not reauthentication).  If necessary, the VPN gateway can thus add
      or remove prefixes by triggering reauthentication.  It is assumed
      that adding or removing prefixes
   will then determine which is a relatively rare situation,
      and thus this draft does not currently specify more complex
      solutions (such as explicit prefix lifetimes, or use of CFG_SET/
      CFG_ACK).

   Compatibility with other IPsec uses

      Compatibility with used.

   All 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 attributes except INTERNAL_IP6_ADDRESS (and
   INTENAL_ADDRESS_EXPIRY) from [IKEv2] remain valid, including the end
   somewhat confusingly named INTERNAL_IP6_SUBNET (see Section 6.3 of the virtual link),
      or the real interfaces IKEv2 messages are being sent over.  This
   [RFC4718] for discussion).

5.  Payload Formats

5.1.  INTERNAL_IP6_LINK Configuration Attribute

   The INTERNAL_IP6_LINK configuration attribute is required to select 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 (TBD1).

   o  Length (2 octets) - Length in octets of the correct SPD to be 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 traffic
      selector narrowing and SA authorization in general.

      One straight-forward solution would be to add an extra payload to
      CREATE_CHILD_SA requests, containing
      link-local address (by the virtual party that sent this attribute).

   o  IKEv2 Link ID (variable length) - The link identifier.
      Requests ID (may be empty when
      the client does not containing this payload would refer to yet know the real link
      (over which IKEv2 messages are being sent).

      Another solution ID).  The link ID is to require that
      selected by the peer requesting a CHILD_SA
      proposes traffic selectors that identify VPN gateway, and is treated as an opaque octet
      string by the link.  For example,
      if TSi includes client.

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 (TBD2).

   o  Length (2 octets) - Length in octets of the peer's "outer" IP address, it's probably
      related Value field; in this
      case, 17.

   o  Prefix (16 octets) - An IPv6 prefix assigned to the real interface, not the virtual one.  Or if TSi
      includes any link.
      The low order bits of the prefixes assigned prefix field which are not part of the
      prefix MUST be set to zero by the gateway (or sender and MUST be ignored by
      the link-
      local or multicast prefix), it receiver.

   o  Prefix Length (1 octets) - 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 probably related to the virtual link.
   If this notification is not included, the CREATE_CHILD_SA requests is
   related to the real interface.

      These heuristics can work in many situations, but have proved
      inadequate in the context of IPv6-in-IPv4 tunnels [RFC4891] and
      Provider Provisioned VPNs [VLINK] [RFC3884],

   The Notify Message Type for LINK_ID is TBD3.  The Protocol ID and Mobile IPv6
      [RFC4877].  Thus, currently Section 6 proposes including the
      virtual link identifier in all CREATE_CHILD_SA requests that apply SPI
   Size fields are set to the virtual interface.

   Example about other IPsec uses:

      If a VPN gateway receives a CREATE_CHILD_SA request zero.  The data associated with a physical Ethernet interface, requesting SA for (TSi=FE80::
      something, dst=*), it would typically reject this
   notification is the request (or IKEv2 Link ID returned 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, for
      protecting e.g. 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.
   configuration attribute.

6.  Solution Sketch  IANA Considerations

   This solution is basically a combination of (1) point-to-point link
   model, (2) prefix information distributed in IKEv2 messages, and (3)
   access control enforced by IPsec SAD/SPD.

   (Second preliminary version, based on discussions with Tero Kivinen.)

6.1.  Initial Exchanges

   1) During IKE_AUTH, the client sends a document defines two new IKEv2 configuration attribute,
   INTERNAL_IP6_LINK, which requests a virtual link attributes, whose
   values are to be configured.
   The attribute contains the client's interface ID for link-local
   address (other addresses may use other interface IDs).  Typically, allocated (have been allocated) from the client would also ask for DHCPv6 server address; this "IKEv2
   Configuration Payload Attribute Types" namespace [IKEv2]:

                                       Multi-
      Value    Attribute Type          Valued  Length         Reference
      ------   ----------------------  ------  -------------  ---------
      TBD1     INTERNAL_IP6_LINK         NO    8 or more      [this doc]
      TBD2     INTERNAL_IP6_PREFIX       YES   17 octets      [this doc]

   This document also defines one new IKEv2 notification, whose value is used
   only for configuration,
   to be allocated (has been allocated) from the "IKEv2 Notify Message
   Types - Status Types" namespace [IKEv2]:

      Value   Notify Messages - Status Types   Reference
      ------  -------------------------------  ---------
      TBD3    LINK_ID                          [this doc]

   This document does not address assignment.

   To handle backward compatibility between create any new namespaces to be maintained by
   IANA.

7.  Security Considerations

   Assigning each client a unique prefix makes using randomized
   interface identifiers [RFC4941] ineffective from privacy point of
   view: the client that supports is still uniquely identified by the
   extended address configuration mechanism hereby specified and prefix.  In some
   environments, it may be preferable to assign a VPN
   gateway that does not, this specification RECOMMENDS that client the same
   prefix each time a VPN
   client includes connection is established; other environments
   may prefer assigning a different prefix every time for privacy
   reasons.  (This is basically a similar trade-off as well the INTERNAL_IP6_ADDRESS configuration
   attribute to allow graceful fallback to the existing address
   configuration mechanism specified in Mobile IPv6 --
   using the IKEv2 specification [IKEv2],
   unless same Home Address forever is simpler than changing it knows
   often, but has privacy implications.)

8.  Acknowledgments

   The author would like to thank Patrick Irwin, Tero Kivinen, Julien
   Laganier, Chinh Nguyen, Mohan Parthasarathy, Yaron Sheffer, Hemant
   Singh, Dave Thaler, Yinghzhe Wu, and Fan Zhao for sure that the VPN gateway supports their valuable
   comments.

   Many of the extended
   mechanism hereby specified (e.g., via configuration.)

      CP(CFG_REQUEST) =
         { INTERNAL_IP6_LINK(Client's Link-Local Interface ID)
           INTERNAL_IP6_ADDRESS()
           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)  -->

   To handle backward compatibility between a VPN gateway that supports challenges associated with IPsec-protected "virtual
   interfaces" have been identified before: for example, in the extended address configuration mechanism hereby specified context
   of protecting IPv6-in-IPv4 tunnels with IPsec [RFC4891], Provider
   Provisioned VPNs [VLINK] [RFC3884], and a
   client that does not, if the client has not sent the
   INTERNAL_IP6_LINK configuration attribute the VPN gateway MUST NOT
   include Mobile IPv6 [RFC4877].  Some
   of the INTERNAL_IP6_LINK configuration attribute limitations of assigning a single IPv6 address were identified
   in its reply [RFC3314].

9.  References

9.1.  Normative References

   [IKEv2]    Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

   [IPv6Addr]
              Hinden, R. and should fallback to the address configuration mechanism specified S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [KEYWORDS]
              Bradner, S., "Key words for use in the IKEv2 specification [IKEv2].

   If the client has sent the INTERNAL_IP6_LINK configuration attribute,
   the VPN gateway SHOULD ignore any INTERNAL_IP6_ADDRESS configuration
   attribute present RFCs to Indicate
              Requirement Levels", 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)",
              draft-ietf-shim6-hba-05 (work in the request.

   The VPN gateway MUST choose progress), December 2007.

   [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.

   [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 itself a link-local interface
   identifier different than the client's one, 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,
   i.e., the IKE_SA can be created but no CHILD_SA will be created.

   The VPN Gateway then replies with an INTERNAL_IP6_LINK configuration
   attribute that contains the IKEv2 Link ID (which will be used 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
   reauthentication Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

   [RFC3884]  Touch, J., Eggert, L., and CREATE_CHILD_SA messages), the client's link
   local interface identier, Y. Wang, "Use of IPsec
              Transport Mode for Dynamic Routing", RFC 3884,
              September 2004.

   [RFC4193]  Hinden, R. and zero or more INTERNAL_IP6_PREFIX
   attributes.  The traffic selectors proposed by the initiator are also
   narrowed to contain only the assigned prefixes, 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 the client link-
   local address formed from the well-known link-local subnet prefix 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
   the client link-local interface identifier.

      CP(CFG_REPLY) =
         { INTERNAL_IP6_LINK(Client's Link-Local Interface ID, F. Dupont, "Mobile IPv6 Operation with
              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 1) its link-local address
   from the well-known link-local subnet prefix (FE80::/64) and the
   assigned client's link-local interface identifier, and 2) other non-
   link-local unicast addresses from the assigned prefixes Revised IPsec Architecture", RFC 4877,
              April 2007.

   [RFC4891]  Graveman, R., Parthasarathy, M., Savola, P., and any
   proper interface identifier [IPv6Addr].  The VPN gateway MUST NOT
   simultaneously assign the same prefixes H.
              Tschofenig, "Using IPsec to any other client, Secure IPv6-in-IPv4 Tunnels",
              RFC 4891, May 2007.

   [RFC4941]  Narten, T., Draves, R., and MUST
   NOT itself configure addresses from these prefixes.  Thus, the client
   does not have to perform Duplicate S. Krishnan, "Privacy
              Extensions for Stateless Address Detection (DAD).  (This
   approach is based on [IPv6PPP].)

   The prefixes remain valid through the lifetime Autoconfiguration in
              IPv6", RFC 4941, September 2007.

   [RFC5121]  Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S.
              Madanapalli, "Transmission of the IKE SA (and its
   continuations IPv6 via rekeying).  If the VPN gateway needs to remove a
   prefix it has previously assigned, or assign a new prefix, it can do
   so by triggering reauthentication.

   2) The client also contacts the DHCPv6 server. IPv6
              Convergence Sublayer over IEEE 802.16 Networks", RFC 5121,
              February 2008.

   [RFC5213]  Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdury,
              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", draft-ietf-shim6-proto-12 (work
              in progress), February 2009.

   [VLINK]    Duffy, M., "Framework for IPsec Protected Virtual Links
              for PPVPNs", draft-duffy-ppvpn-ipsec-vlink-00 (work in
              progress), October 2002.

Appendix A.  Design Rationale (Non-Normative)

   This is appendix describes some of the
   RECOMMENDED way to obtain additional configuration parameters (such
   as reasons why the DNS server), as it allows easier extensibility solution in
   Section 4 was selected, and more
   options (such as the domain search list for DNS).

6.2.  Reauthentication

   When the client performs reauthentication (and wants lists some alternative designs that were
   considered, but ultimately rejected.

   Assigning a new IPv6 address to continue
   using the same client creates a new "virtual link"), it includes the IKEv2 Link ID given
   by the gateway in
   IPv6 interface", and "virtual link" between 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)  -->

   The gateway uses client and the Link ID to look up relevant local state,
   verifies
   gateway.  We will assume that the authenticated peer identity associated with virtual link has the following
   properties:

   o  The link is correct, and continues the handshake as usual.

6.3.  Creating CHILD_SAs

   As described in the previous section, both peers need to be able to
   determine whether a CHILD_SA applies to the virtual interfaces, or
   the real its interfaces IKEv2 messages are being sent over.

   Currently, this document proposes using created and destroyed by the IKEv2
      process.

   o  The link is not an explicit indication
   instead of relying IPsec SA; at any time, there can be zero or
      more IPsec SAs covering traffic on heuristics: the peers MUST include this link.

   o  The link is not a LINK_ID
   notification, containing single IKE SA; to support reauthentication, it
      must be possible to identify the IKEv2 Link ID, same link in another IKE SA.

   o  Not all CREATE_CHILD_SA
   requests, including rekeys, that are IPsec-protected traffic between the peers is necessarily
      related to the virtual link.
   The LINK_ID notification is not included link (although in the CREATE_CHILD_SA
   response, or when doing IKE_SA rekeying.

6.4.  Multicast

   (The details of multicast use are to-be-determined.)

   One way would be to create an SA for receiving multicast packets:

      TSi = (0, 0-65535,
             FF00: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) -->

      <--
      TSi = (0, 0-65535,
             FF00: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)

   ...and then use MLD as usual.

6.5.  Relationship to Neighbor Discovery

   Neighbor Discovery [IPv6ND] specifies simplest VPN client-
      to-gateway scenario it will be).

   Given these assumptions and the following mechanisms:

   Router Discovery, Prefix Discovery, Parameter Discovery,and Address
   Autoconfiguration goals described in Section 3, it
   seems that the most important design choices to be made are not used, as the necessary functionality
   following:

   o  What link/subnet model is
   implemented used: in IKEv2 layer.

   Address Resolution, Next-hop Determination, and Redirect are not
   used, as other words, the virtual link does not have link-local addresses, relationships
      between VPN clients, IPv6 subnet prefixes, and link-local traffic
      (especially link-local multicast).

   o  How information about the IPv6 prefix(es) 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 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 not needed, because this done; in other words, where the
      mechanisms for preventing address spoofing by clients are placed
      architecturally.

   Each of these is a point-
   to-point link, where discussed next in turn.

A.1.  Link Model

   There are at least three main choices how to organize the
   relationships between VPN gateway does not assign any addresses
   from the global unicast clients, IPv6 subnet prefixes, and link-local interface identifier
   is negotiated separately.

6.6.  Relationship to Existing IKEv2 Payloads

   The mechanism described in this document link-
   local traffic:

   o  Point-to-point link model: each VPN client is assigned one or more
      IPv6 prefixes; these prefixes are not intended shared with other clients,
      and there is no link-local traffic between different VPN clients
      connected to be used
   at the same time as the existing INTERNAL_IP6_ADDRESS attribute.  For
   compatibility with gateways implementing only INTERNAL_IP6_ADDRESS, gateway.

   o  Multi-access link model: multiple VPN clients share the same IPv6
      prefix.  Link-local multicast packets sent by one VPN client MAY include attributes for both mechanisms in
   CFG_REQUEST.  The capabilities and preferences of the will
      be received by other VPN clients (VPN gateway will then determine which is used.

   All forward the
      packets, possibly with 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 attributes except INTERNAL_IP6_ADDRESS (and
   INTENAL_ADDRESS_EXPIRY) 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 [IKEv2] remain valid, including other clients
   (depending on how many other clients are connected).  This is
   especially undesirable when the clients are battery-powered; for
   example, a PDA which keeps the VPN connection to corporate intranet
   active 24/7.  For this reason, using the
   somewhat confusingly named INTERNAL_IP6_SUBNET (see Section 6.3 of
   [RFC4718] for discussion).

7.  Payload Formats

7.1.  INTERNAL_IP6_LINK Configuration Attribute multi-access link model was
   rejected.

   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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Client's Link-Local                      |
   |                         Interface ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                        IKEv2 Link ID                          ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Reserved (1 bit) - See [IKEv2].

   o  Attribute Type (15 bits) - INTERNAL_IP6_LINK (TBD1).

   o  Length (2 octets) - Length attributes specified in octets 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 Value field (Client's
      Link-Local Interface ID and
   prefix before an address can be generated.  The prefix information
   could be distributed to clients in the following ways:

   o  IKEv2 Link ID); 8 or more. messages (Configuration Payloads).

   o  Link-Local Interface ID (8 octets) - The Interface ID used for
      link-local address (by  Router Advertisement messages (sent over the party that sent this attribute). IPsec tunnel).

   o  DHCPv6 messages (sent over the IPsec tunnel).

   In Section 4, the prefix information is distributed in IKEv2 Link ID (variable length) - The link ID (may be empty when
   messages.

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 yet know use an address
   already used by some other client.  Also, the link ID).

7.2.  INTERNAL_IP6_PREFIX Configuration Attribute

   The INTERNAL_IP6_PREFIX configuration attribute VPN gateway has to know
   which client 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 (TBD2).

   o  Length (2 octets) - Length using which addresses in octets of order to correctly forward
   traffic.

   The main choices seem to be the Value field; following:

   o  Clients receive the address(es) they are allowed to use in IKEv2
      messages (Configuration Payloads).  In this case, 17. keeping track of
      which client is using which address is trivial.

   o  Prefix (16 octets) - An IPv6 prefix assigned  Clients receive the address(es) they are allowed to use in DHCPv6
      messages sent over the virtual link.
      The low order bits of IPsec tunnel.  In case the prefix field which are DHCPv6 server is
      not part of integrated with the
      prefix MUST 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 multi-access link model, and can be set made to zero by work
      with router aggregation link model if the sender VPN gateway traps
      Neighbor Solicitation (NS) messages and MUST be ignored by
      the receiver.

   o  Prefix Length (1 octets) - spoofs Neighbor
      Advertisement (NA) replies.  The length gateway keeps track of the prefix in bits;
      usually 64.

7.3.  LINK_ID Notify Payload

   The LINK_ID notification is included in CREATE_CHILD_SA requests to
   indicate that the SA being created which
      client is related to using which address (and updates its forwarding state
      accordingly) by trapping these NS/NA messages.

   In the virtual link.
   If this notification is not included, point-to-point link model, the CREATE_CHILD_SA requests is
   related to client can simply use any
   address from the physical interface.

   The Notify Message Type for LINK_ID is TBD3.  The Protocol ID prefix, 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_ID configuration attribute.

8.  IANA Considerations

   This document defines two new IKEv2 configuration attributes, whose
   values are VPN gateway only needs to be allocated (have been allocated) from the "IKEv2
   Configuration Payload Attribute Types" namespace [IKEv2]:

                                       Multi-
      Value    Attribute Type          Valued  Length         Reference
      ------   ----------------------  ------  -------------  ---------
      TBD1     INTERNAL_IP6_LINK         NO    8 or more      [this doc]
      TBD2     INTERNAL_IP6_PREFIX       YES   17 octets      [this doc]

   This document also defines one new IKEv2 notification, whose value know which
   client is using which prefix in order to be allocated (has been allocated) from the "IKEv2 Notify Message
   Types - Status Types" namespace [IKEv2]:

      Value   Notify Messages - Status Types   Reference
      ------  -------------------------------  ---------
      TBD3    LINK_ID                          [this doc]

   This document does not create any new namespaces forward packets correctly.

A.4.  Layer 3 Access Control

   It is almost always desirable to be maintained prevent one VPN client from sending
   packets with a source address that is used by
   IANA.

9.  Security Considerations

   To be written.  (The security consideration should be pretty much another VPN client.  In
   order to correctly forward packets destined to clients, the
   same as for current configuration payloads.)

   Assigning each VPN
   gateway obviously has to know which client a unique prefix makes is using randomized
   interface identifiers [RFC4941] ineffective from privacy point of
   view: which address;
   the client question is still uniquely identified therefore where, architecturally, the mechanisms for
   ingress filtering are placed.

   o  Layer 3 access control enforced by IPsec SAD/SPD: the prefix.  In some
   environments, it may be preferable addresses/
      prefixes assigned to assign a VPN client are reflected in the same
   prefixes 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 traffic
      selectors used in IPsec Security Association and Security Policy
      Database entries, as negotiated in Mobile
   IPv6 -- using the same Home Address forever is simpler than changing
   it often, but has privacy implications.)

10.  Acknowledgments IKEv2.

   o  The author ingress filtering capability could be placed outside IPsec;
      the traffic selectors in SAD/SPD entries would like to thank Patrick Irwin, Tero Kivinen, Julien
   Laganier, Chinh Nguyen, Mohan Parthasarathy, Yaron Sheffer, Hemant
   Singh, Dave Thaler, Yinghzhe Wu, cover traffic that
      would be dropped later by ingress filtering.

   The former approach is used by the current IPv4 solution, and Fan Zhao for their valuable
   comments.

   Many the
   mechanism specified in Section 4.

A.5.  Other Considerations

   VPN gateway state

      In some combinations of design choices, the challenges associated with IPsec-protected "virtual
   interfaces" have been identified before: for example, amount of state
      information required in the context
   of protecting IPv6-in-IPv4 tunnels with IPsec [RFC4891], Provider
   Provisioned VPNs [VLINK] [RFC3884], and Mobile IPv6 [RFC4877].  Some VPN gateway depends not only on the
      number of clients, but also on the limitations number of assigning a single IPv6 address were identified
   in [RFC3314].

11.  References

11.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", RFC 2119, March 1997.

11.2.  Informative References

   [AUTOCONF]
              Thomson, S., Narten, T., addresses used by one
      client.  With privacy addresses and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [CGA]      Aura, T., "Cryptographically potentially some uses of
      Cryptographically Generated Addresses (CGA)",
              RFC 3972, March 2006.

   [DHCPv6]   Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [HBA]      Bagnulo, M., "Hash Based Addresses (HBA)",
              draft-ietf-shim6-hba-05 (work in progress), December 2007.

   [IPConfig]
              Aboba, B., Thaler, D., and L. Andersson, "Principles (CGAs), a single client
      could have a large number of
              Internet Host Configuration", draft-iab-ip-config-04 (work
              in progress), May 2008.

   [IPv6ND]   Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery 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 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 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. addresses of
      the peers (due to NAT Traversal and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) [MOBIKE]).

   Prefix lifetime

      Prefixes could remain valid either for IPv6", RFC 3810, June 2004.

   [MOBIKE]   Eronen, P., "IKEv2 Mobility and Multihoming Protocol
              (MOBIKE)", RFC 4555, June 2006.

   [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 the lifetime of the IKE SA,
      until explicitly cancelled, or for IPv6 in Third
              Generation Partnership Project 3GPP) Standards", RFC 3314,
              September 2002.

   [RFC3456]  Patel, B., Aboba, B., Kelly, S., 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 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 V. Gupta, "Dynamic
              Host Configuration Protocol (DHCPv4) Configuration 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 Tunnel Mode", RFC 3456, January 2003.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options 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 IKEv2 messages are being sent over.  This
      is required to select the correct SPD to be used for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

   [RFC3884]  Touch, J., Eggert, L., traffic
      selector narrowing and Y. Wang, "Use 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 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.

   [RFC4294]  Loughney, J., Ed., "IPv6 Node Requirements", RFC 4294,
              April 2006.

   [RFC4718]  Eronen, P. and P. Hoffman, "IKEv2 Clarifications IPv6-in-IPv4 tunnels [RFC4891] and
              Implementation Guidelines", RFC 4718, October 2006.

   [RFC4866]  Arkko, J., Vogt, C.,
      Provider Provisioned VPNs [VLINK] [RFC3884], 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
      [RFC4877].  Thus, Section 4 includes 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 virtual link identifier
      in
              IPv6", RFC 4941, September 2007.

   [SHIM6]    Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
              Shim Protocol all CREATE_CHILD_SA requests that apply to the virtual
      interface.

   Example about other IPsec uses:

      If a VPN gateway receives a CREATE_CHILD_SA request associated
      with a physical Ethernet interface, requesting SA for IPv6", draft-ietf-shim6-proto-10 (work (TSi=FE80::
      something, dst=*), it would typically reject the request (or in progress), February 2008.

   [VLINK]    Duffy, M., "Framework for IPsec Protected Virtual Links
      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, for PPVPNs", draft-duffy-ppvpn-ipsec-vlink-00 (work in
              progress), October 2002.

Appendix A.
      protecting e.g. 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.1.

A.6.1.  Version -00 Sketch

   The -00 version of this draft contained the following solution
   sketch, which is basically a combination of (1) point-to-point link
   model, (2) prefix information distributed in Neighbor Advertisements,
   and (3) access control enforced outside IPsec.

   1) During IKE_AUTH, client sends a new configuration attribute,
   INTERNAL_IP6_LINK_ID,
   INTERNAL_IP6_LINK, which requests a virtual link to be created.  The
   attribute contains the client's interface ID for link-local address
   (other addresses may use other interface IDs).

      CP(CFG_REQUEST) =
         { INTERNAL_IP6_LINK_ID(Link-Local 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
   MUST
   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_ID(Link-Local 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.

      ESP(Router Solicitation:
         src=:
          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 MUST NOT does not simultaneously assign the
   same prefixes to any other client, and MUST NOT 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 6.2; 4; the
   client includes the IKEv2 Link ID in the INTERNAL_IP6_LINK_ID INTERNAL_IP6_LINK attribute.

   4) Creating and rekeying IPsec SAs works basically the same way as in
   Section 6.3; 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 -01 draft based on feedback from VPN
   vendors: while the solution looks nice on paper, it is claimed to be
   unneccessarily 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.2.

A.6.2.  Router Aggregation Sketch #1

   The following solution was sketched during the IETF 70 meeting in
   Vancouver together with Hemant Singh.  It combines the (1) 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_ID,
   INTERNAL_IP6_LINK, which requests a virtual link to be created.  The
   attribute contains the client's interface ID for link-local address
   (other addresses may use other interface IDs).

      CP(CFG_REQUEST) =
         { INTERNAL_IP6_LINK_ID(Link-Local 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
   MUST
   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_ID(Link-Local INTERNAL_IP6_LINK(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)

   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.

   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.3.

A.6.3.  Router Aggregation Sketch #2

   This is basically similar to the version -00 sketch described with
   above, but uses router aggregation link model.  In other words, it
   combines (1) router aggregation link model, (2) prefix information
   distributed in Neighbor Advertisements, (3) unique address allocation
   with stateless address autoconfiguration (with VPN gateway trapping
   NS messages and spoofing NA replies), and (4) access control enforced
   outside IPsec.

   1) During IKE_AUTH, client sends a new configuration attribute,
   INTERNAL_IP6_LINK_ID,
   INTERNAL_IP6_LINK, which requests a virtual link to be created.  The
   attribute contains the client's interface ID for link-local address
   (other addresses may use other interface IDs).

      CP(CFG_REQUEST) =
         { INTERNAL_IP6_LINK_ID(Link-Local 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
   MUST
   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_ID(Link-Local 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.

     ESP(Router Solicitation:
         src=:
         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.4.

A.6.4.  IPv4-like Sketch

   This sketch resembles the current IPv4 configuration payloads, and it
   combines (1) 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_ID,
   INTERNAL_IP6_LINK, which requests a virtual link to be created.  The
   attribute contains the client's interface ID for link-local address
   (other addresses may use other interface IDs).

      CP(CFG_REQUEST) =
         { INTERNAL_IP6_LINK_ID(Link-Local 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
   MUST
   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_ID(Link-Local 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
   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 traffic
   selectors narrowed appropriately.

      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 INTERNAL_IP6_ADDRESS attribute (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.4), 3.3), and the multi-link subnet model.

A.5.

A.6.5.  Sketch Based on RFC 3456

   For completeness: a solution modeled after [RFC3456] would combine
   (1) router aggregation link model, (2) prefix information
   distribution and unique address allocation with DHCPv6, and (3)
   access control enforced by IPsec SAD/SPD.

Authors' Addresses

   Pasi Eronen
   Nokia Research Center
   P.O. Box 407
   FIN-00045 Nokia Group
   Finland

   Email: pasi.eronen@nokia.com

   Julien Laganier
   DOCOMO Communications Laboratories Europe GmbH
   Landsberger Strasse 312
   Munich  D-80687
   Germany

   Phone: +49 89 56824 231
   Email: julien.laganier.IETF@googlemail.com

   Cheryl Madson
   Cisco Systems, Inc.
   510 MacCarthy Drive
   Milpitas, CA
   USA

   Email: cmadson@cisco.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.