One document matched: draft-ietf-ipsecme-ikev2-ipv6-config-00.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc compact="no" ?>
<?rfc subcompact="no" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<rfc ipr="full3978" category="std">
<front>
<title>IPv6 Configuration in IKEv2</title>
<author initials="P." surname="Eronen" fullname="Pasi Eronen">
<organization abbrev="Nokia">Nokia Research Center</organization>
<address>
<postal>
<street>P.O. Box 407</street>
<city>FIN-00045 Nokia Group</city>
<country>Finland</country>
</postal>
<email>pasi.eronen@nokia.com</email>
</address>
</author>
<author initials="J." surname="Laganier" fullname="Julien Laganier">
<organization abbrev="DOCOMO Euro-Labs">
DOCOMO Communications Laboratories Europe GmbH
</organization>
<address> <postal>
<street> Landsberger Strasse 312
</street>
<city>Munich</city>
<code>D-80687</code>
<country>Germany</country>
</postal>
<phone>+49 89 56824 231</phone>
<email>julien.laganier.IETF@googlemail.com</email>
</address>
</author>
<author initials="C." surname="Madson" fullname="Cheryl Madson">
<organization abbrev="Cisco Systems">
Cisco Systems, Inc.
</organization>
<address> <postal>
<street> 510 MacCarthy Drive
</street>
<city>Milpitas, CA</city>
<country>USA</country>
</postal>
<email>cmadson@cisco.com</email>
</address>
</author>
<date year="2008"/>
<abstract>
<t>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 configuration
payloads for IPv6, and explores possible solutions that would
allow IKEv2 to set up full-featured virtual IPv6 interfaces.</t>
</abstract>
</front>
<middle>
<!-- ====================================================================== -->
<section title="Introduction and Problem Statement">
<t>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 <xref target="IKEv2"/>.</t>
<t>For IPv4, the message exchange would look as follows:</t>
<figure anchor="fig:ipv4" title="IPv4 configuration"><artwork><![CDATA[
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) }
]]></artwork></figure>
<t>The IPv4 case has been implemented by various vendors, and in
general works well. IKEv2 also defines almost identical
configuration payloads for IPv6:</t>
<figure anchor="fig:ipv6" title="IPv6 configuration"><artwork><![CDATA[
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) }
]]></artwork></figure>
<t>In other words, IPv6 is basically treated as IPv4 with larger
addresses. As noted in <xref target="RFC4718"/>, this does not fully
follow the "normal IPv6 way of doing things". The IPsec tunnels are
not full-featured "interfaces" in the IPv6 addressing architecture
<xref target="IPv6Addr"/> sense. For example, they do not
necessarily have link-local addresses, and this may complicate the
use of protocols that assume them.</t>
<t>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 to set up full-featured
virtual IPv6 interfaces.</t>
</section>
<!-- ====================================================================== -->
<section title="Terminology">
<t>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 <xref
target='KEYWORDS'/>.</t>
<t>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+").</t>
<t>This document uses the term "virtual interface" when describing
how the client uses the IPv6 address(es) assigned by the gateway.
While existing IPsec documents do not use this term, it is not a new
concept. In order to use the address assigned by the VPN gateway,
current VPN clients already create a local "virtual interface" (as
only addresses assigned to interfaces can be used, e.g., as source
addresses for TCP connections). Note that this definition of
"interface" is not necessarily identical with what some particular
implementation calls "interface".</t>
</section>
<!-- ====================================================================== -->
<section title="Current Limitations">
<t>This section explores the limitations of the current IPv6
configuration mechanism.</t>
<t>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
<xref target="fig:ipv6"/>. It is possible that many of the
limitations described here could be solved by specifying additional
semantics for these configuration payloads.</t>
<section title="Multiple Prefixes">
<t>In <xref target="fig:ipv6"/> 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.</t>
<t>Multiple prefixes are useful for site renumbering, host-based
site multihoming <xref target="SHIM6"/>, and unique local IPv6
addresses <xref target="RFC4193"/>. In all of these cases, the
gateway has better information on how many different addresses
(from different prefixes) the client should be assigned.</t>
</section>
<section title="Link-Local Addresses">
<t>The IPv6 addressing architecture <xref target="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".</t>
<t>Currently, the virtual interface created by IKEv2 configuration
payloads does not have link-local addresses. This violates <xref
target="IPv6Addr"/> and prevents the use of protocols that require
link-local addresses, such as <xref target="MLDv2"/>
and <xref target="DHCPv6"/></t>
</section>
<section title="Receiving Multicast Traffic">
<t>Even if MLD would work, the traffic selectors negotiated in
<xref target="fig:ipv6"/> do not allow receiving multicast
traffic.</t>
</section>
<section title="Interface Identifier Selection" anchor="iidselection">
<t>In the message exchange shown in <xref target="fig:ipv6"/>, 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.</t>
<t>This approach complicates the use of Cryptographically
Generates Addresses <xref target="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.</t>
<t>Similar concerns apply to other cases where the client has some
interest in what interface ID is being used, such as Hash-Based
Addresses <xref target="HBA"/> and privacy addresses <xref
target="RFC4941"/>.</t>
<t>Without CGAs and HBAs, VPN clients are not able to fully use
IPv6 features such as <xref target="SHIM6"/> or enhanced Mobile
IPv6 route optimization <xref target="RFC4866"/>.</t>
</section>
<section title="Sharing VPN Access">
<t>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).</t>
<t>It is to be determined how common this use case would actually
be; e.g., how likely it is that security policies would allow
this. </t>
<t>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. Thus, obtaining a whole prefix for the VPN
client, and advertising that to the local link (something
resembling <xref target="NDProxy"/>) would be preferable. With
DHCPv6 prefix delegation <xref target="RFC3633"/>, even <xref
target="NDProxy"/> and associated multi-link subnet issues would
be avoided.</t>
</section>
<section title="Additional Information">
<t>The original 3GPP standards for IPv6 assigned a single IPv6
address to each mobile phone, resembling current IKEv2 payloads.
<xref target="RFC3314"/> describes the problems with this
approach, and caused 3GPP to change the specifications to assign
unique /64 prefix(es) for each phone.</t>
<t>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. <xref target="Multilink"/> describes issues
associated with multi-link subnets, and recommends that they
should be avoided.</t>
</section>
</section>
<!-- ====================================================================== -->
<section title="Design Goals">
<section title="Main Requirements">
<t><list style='symbols'>
<t>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.</t>
<t>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.</t>
<t>The solution should avoid periodic messages over the VPN
tunnel.</t>
<t>The solution should avoid Duplicate Address Detection (DAD)
over the VPN tunnel.</t>
<t>Multicast works. That is, the client is able to send multicast
packets (tunneled to the gateway via unicast), join multicast
groups using <xref target="MLDv2"/>, and receive multicast
packets (tunneled from the gateway to the client via
unicast).</t>
<t>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 <xref target="RFC4294"/>).</t>
<t>Re-authentication works: the client can start a new IKE SA and
continue using the same "virtual link" (with same addresses,
etc.).</t>
<t>Compatibility with other IPsec uses: Configuring a virtual
IPv6 link should not prevent the peers from using IPsec/IKEv2 for
other uses.</t>
<t>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).</t>
<t>Compatibility with current IPv4 configuration: it should be
possible to use the existing IPv4 configuration mechanism within
the same IKE SA.</t>
<t>(Optional/To be determined) When the client is also a router
(to some local network), it should be able to use DHCPv6 prefix
delegation <xref target="RFC3633"/> over the virtual link.</t>
</list></t>
</section>
<section title="Desirable Non-Functional Properties">
<t>Note that the following desirable properties may be somewhat
conflicting.</t>
<t><list style="symbols">
<t>Re-use existing mechanisms, such as <xref target="AUTOCONF"/>
and <xref target="DHCPv6"/> as much as possible; as explained in
<xref target="IPConfig"/>, creating IKEv2-specific mechanisms
should be avoided.</t>
<t>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.</t>
</list></t>
</section>
<section title="Implementation Considerations">
<t>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 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).</t>
</section>
<section title="Non-Goals">
<t>Mobile IPv6 already defines how it interacts with IPsec/IKEv2
<xref target="RFC4877"/>, and the intent of this document is not
to change that interaction in any way.</t>
</section>
</section>
<!-- ====================================================================== -->
<section title="Solution Discussion">
<t>Assigning a new IPv6 address to the client creates a new "virtual
IPv6 interface", and "virtual link" between the client and the
gateway. We will assume that the virtual link has the following
properties:
<list style="symbols">
<t>The link and its interfaces are created and destroyed by the IKEv2
process.</t>
<t>The IPv6 addresses and prefixes are assigned to the link and its
interfaces by IKEv2 messages, and are removed once they are no longer used
by any IKE SA. An IKEv2 implementation may delay removal of the IPv6
addresses and prefixes for a period of time to allow upper layer protocol
communications (e.g., a TCP connection) to survive an IKE SA
re-authentication that would use the same addresses and prefixes.</t>
<t>The link is not an IPsec SA; at any time, there can be zero or
more IPsec SAs covering traffic on this link.</t>
<t>The link is not a single IKE SA; to support reauthentication, it
must be possible to identify the same link in another IKE SA.</t>
<t>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.)</t>
<t>Not all IPsec-protected traffic between the peers is necessarily
related to the virtual link (although in the simplest VPN
client-to-gateway scenario it will be).</t>
</list></t>
<t>Given these assumptions and the goals described in the previous
section, it seems that the most important design choices to be made
are the following:</t>
<t><list style='symbols'>
<t>What link/subnet model is used: in other words, the
relationships between VPN clients, IPv6 subnet prefixes, and
link-local traffic (especially link-local multicast).</t>
<t>How information about the IPv6 prefix(es) is distributed from
the gateway to the clients.</t>
<t>How to ensure unique IPv6 addresses for each client, and keep
forwarding state up-to-date accordingly..</t>
<t>How layer 3 access control is done; in other words, where the
mechanisms for preventing address spoofing by clients are placed
architecturally.</t>
</list></t>
<t>Each of these is discussed next in turn.</t>
<section title="Link Model">
<t>There are at least three main choices how to organize the
relationships between VPN clients, IPv6 subnet prefixes,
and link-local traffic:</t>
<t><list style='symbols'>
<t>Point-to-point link model: each VPN client is assigned one or
more IPv6 prefixes; these prefixes are not shared with other
clients, and there is no link-local traffic between different VPN
clients connected to the same gateway.</t>
<t>Multi-access link model: multiple VPN clients share the same
IPv6 prefix. Link-local multicast packets sent by one VPN client
will be received by other VPN clients (VPN gateway will forward
the packets, possibly with MLD snooping to remove unnecessary
packets).</t>
<t>"Router aggregation" link model: one form of "multi-link" subnet
<xref target="Multilink"/> where multiple VPN clients share the
same IPv6 prefix. Link-local multicast will not be received by
other VPN clients.</t>
</list></t>
<t>In the multi-access link model, VPN clients who are idle (i.e.,
not currently sending or receiving application traffic) could
receive significant amounts of multicast packets from other clients
(depending on how many other clients are connected). This is
especially undesirable when the clients are battery-powered; for
example, a PDA which keeps the VPN connection to corporate intranet
active 24/7. For this reason, we will not consider the multi-access
link model in the rest of this document.</t>
</section>
<section title="Distributing Prefix Information">
<t>Some types of addresses, such as CGAs, require knowledge about
the prefix before an address can be generated. The prefix
information could be distributed to clients in the following
ways:</t>
<t><list style='symbols'>
<t>IKEv2 messages (Configuration Payloads).</t>
<t>Router Advertisement messages (sent over the IPsec tunnel).</t>
<t>DHCPv6 messages (sent over the IPsec tunnel).</t>
</list></t>
</section>
<section title="Unique Address Allocation">
<t>In the "multi-access" and "router aggregation" link models (where
a single IPv6 prefix is shared between multiple VPN clients)
mechanisms are needed to ensure that one VPN client does not use an
address already used by some other client. Also, the VPN gateway has
to know which client is using which addresses in order to correctly
forward traffic.</t>
<t>The main choices seem to be the following:</t>
<t><list style='symbols'>
<t>Clients receive the address(es) they are allowed to use
in IKEv2 messages (Configuration Payloads). In this case,
keeping track of which client is using which address is trivial.</t>
<t>Clients receive the address(es) they are allowed to use in
DHCPv6 messages sent over the IPsec tunnel. In case the DHCPv6
server is not integrated with the VPN gateway, the gateway may
need to work as a relay agent to keep track of which client is
using which address (and update its forwarding state
accordingly).</t>
<t>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
made to work with router aggretation link model if the VPN gateway
traps NS messages 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.</t>
</list></t>
<t>In the point-to-point link model, the client can simply use any
address from the prefix, and the VPN gateway only needs to know
which client is using which prefix in order to forward packets
correctly.</t>
</section>
<section title="Layer 3 Access Control">
<t>It is almost always desirable to prevent one VPN client from
sending packets with a source address that is used by another VPN
client. In order to correctly forward packets destined to clients,
the VPN gateway obviously has to know which client is using which
address; the question is therefore where, architecturally, the
mechanisms for ingress filtering are placed.</t>
<t><list style='symbols'>
<t>Layer 3 access control enforced by IPsec SAD/SPD: the
addresses/prefixes assigned to a VPN client are reflected in the
traffic selectors used in IPsec Security Association and Security
Policy Database entries, as negotiated in IKEv2.</t>
<t>The ingress filtering capability could be placed outside IPsec;
the traffic selectors in SAD/SPD entries would cover traffic
that would be dropped later by ingress filtering.</t>
</list></t>
<t>The former approach is used by the current IPv4 solution.</t>
</section>
<section title="Other Considerations">
<t><list style="hanging">
<t hangText="VPN gateway state">
<vspace blankLines="1"/> In some combinations of design choices,
the amount of state information required in the VPN gateway depends
not only on the number of clients, but also on the number of addresses
used by one client. With privacy addresses and potentially some uses
of Cryptographically Generated Addresses (CGAs), a single client
could have a large number of different addresses (especially if
different privacy addresses are used with different destinations).</t>
<t hangText="Virtual link identifier">
<vspace blankLines="1"/> 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. Currently,
<xref target="solution"/> proposes 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.
<vspace blankLines="1"/> Note that the link is not uniquely
identified by the IKE peer identities (because IDi is often a user
identity that can be used on multiple hosts at the same time), or
the outer IP addresses of the peers (due to NAT Traversal and
<xref target="MOBIKE"/>).</t>
<t hangText='Prefix lifetime'>
<vspace blankLines="1"/> Prefixes could remain valid either for the
lifetime of the IKE SA, until explicitly cancelled, or for an
explicitly specified time. Currently, <xref target="solution"/>
proposes that 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 thus this
draft does not currently specify more complex solutions (such as
explicit prefix lifetimes, or use of CFG_SET/CFG_ACK).</t>
<t hangText='Compatibility with other IPsec uses'>
<vspace blankLines="1"/>
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
traffic selector narrowing and SA authorization in general.
<vspace blankLines="1"/> One straight-forward solution would be 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).
<vspace blankLines="1"/>
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.
<vspace blankLines="1"/>
These heuristics can work in many
situations, but have proved inadequate in the context of
IPv6-in-IPv4 tunnels <xref target="RFC4891"/> and Provider
Provisioned VPNs <xref target="VLINK"/> <xref target="RFC3884"/>,
and Mobile IPv6 <xref target="RFC4877"/>. Thus, currently <xref
target="solution"/> proposes including the virtual link identifier
in all CREATE_CHILD_SA requests that apply to the virtual
interface.</t>
<t hangText='Example about other IPsec uses:'>
<vspace blankLines="1"/>
If a VPN gateway receives a CREATE_CHILD_SA request
associated with a physical Ethernet interface, requesting SA for
(TSi=FE80::something, dst=*), it would typically reject the request
(or in other words, narrow it to an empty set) because it doesn't
have SPD/PAD entries that would allow joe.user@example.com to
request such CHILD_SAs.
<vspace blankLines="1"/>
(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.)
<vspace blankLines="1"/>
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.</t>
</list></t>
</section>
</section>
<!-- ====================================================================== -->
<section title="Solution Sketch" anchor="solution">
<t>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. </t>
<t>(Second preliminary version, based on discussions with Tero
Kivinen.)</t>
<section title="Initial Exchanges">
<t>1) During IKE_AUTH, the client sends a new configuration attribute,
INTERNAL_IP6_LINK, which requests a virtual link to be configured. The
attribute contains the client's interface ID for 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, not address
assignment. </t>
<t>To handle backward compatibility between a client that supports the
extended address configuration mechanism hereby specified and a VPN gateway
that does not, this specification RECOMMENDS that the VPN client includes as
well the INTERNAL_IP6_ADDRESS configuration attribute to allow graceful
fallback to the existing address configuration mechanism specified in the
IKEv2 specification <xref target="IKEv2"/>, unless it knows for sure that the
VPN gateway supports the extended mechanism hereby specified (e.g., via
configuration.) </t>
<figure><artwork><![CDATA[
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) -->
]]></artwork></figure>
<t>To handle backward compatibility between a VPN gateway that supports the
extended address configuration mechanism hereby specified and a client that
does not, if the client has not sent the INTERNAL_IP6_LINK configuration
attribute the VPN gateway MUST NOT include the INTERNAL_IP6_LINK
configuration attribute in its reply and should fallback to the address
configuration mechanism specified in the IKEv2 specification <xref
target="IKEv2"/>.</t>
<t>If the client has sent the INTERNAL_IP6_LINK configuration attribute, the
VPN gateway SHOULD ignore any INTERNAL_IP6_ADDRESS configuration attribute
present in the request.</t>
<t>The VPN gateway MUST choose 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.</t>
<t>The VPN Gateway then replies with an INTERNAL_IP6_LINK configuration
attribute that contains the IKEv2 Link ID (which will be used for
reauthentication and CREATE_CHILD_SA messages), the client's link local
interface identier, and zero or more INTERNAL_IP6_PREFIX attributes. The
traffic selectors proposed by the initiator are also narrowed to contain only
the assigned prefixes, and the client link-local address formed from
the well-known link-local subnet prefix and the client link-local interface
identifier.</t>
<figure><artwork><![CDATA[
CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK(Client'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)
]]></artwork></figure>
<t>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 and any proper interface
identifier <xref target="IPv6Addr"/>. The VPN gateway MUST NOT
simultaneously assign the same prefixes to any other client, and MUST NOT
itself configure addresses from these prefixes. Thus, the client does not
have to perform Duplicate Address Detection (DAD). (This approach is based
on <xref target="IPv6PPP"/>.)</t>
<t>The prefixes remain valid through the lifetime of the IKE SA
(and its continuations via rekeying). If the VPN gateway needs to
remove a prefix it has previously assigned, or assign a new prefix,
it can do so by triggering reauthentication.</t>
<t>2) The client also contacts the DHCPv6 server. This is the
RECOMMENDED way to obtain additional configuration parameters (such
as the DNS server), as it allows easier extensibility and more
options (such as the domain search list for DNS).</t>
</section>
<section title="Reauthentication" anchor="reauth">
<t>When the client performs reauthentication (and wants to continue
using the same "virtual link"), it includes the IKEv2 Link ID
given by the gateway in the INTERNAL_IP6_LINK attribute.</t>
<figure><artwork><![CDATA[
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) -->
]]></artwork></figure>
<t>The gateway uses the Link ID to look up relevant local state,
verifies that the authenticated peer identity associated with the
link is correct, and continues the handshake as usual.</t>
</section>
<section title="Creating CHILD_SAs" anchor="childsas">
<t>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 interfaces IKEv2 messages are being sent over.</t>
<t>Currently, this document proposes using an explicit indication
instead of relying on heuristics: the peers MUST include a LINK_ID
notification, containing the IKEv2 Link ID, in all CREATE_CHILD_SA
requests, including rekeys, that are related to the virtual link.
The LINK_ID notification is not included in the CREATE_CHILD_SA
response, or when doing IKE_SA rekeying.</t>
</section>
<section title="Multicast">
<t>(The details of multicast use are to-be-determined.)</t>
<t>One way would be to create an SA for receiving multicast
packets:</t>
<figure><artwork><![CDATA[
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)
]]></artwork></figure>
<t>...and then use MLD as usual.</t>
</section>
<section title="Relationship to Neighbor Discovery">
<t>Neighbor Discovery <xref target="IPv6ND"/> specifies the
following mechanisms:</t>
<t>Router Discovery, Prefix Discovery, Parameter Discovery,and
Address Autoconfiguration are not used, as the necessary
functionality is implemented in IKEv2 layer.</t>
<t>Address Resolution, Next-hop Determination, and Redirect are not
used, as the virtual link does not have link-local addresses, and is
a point-to-point link.</t>
<t>Neighbor Unreachability Detection could be used, but is a bit
redundant given IKEv2 Dead Peer Detection.</t>
<t>Duplicate Address Detection is not needed, because this is a
point-to-point link, where the VPN gateway does not assign any
addresses from the global unicast prefixes, and link-local interface
identifier is negotiated separately.</t>
</section>
<section title="Relationship to Existing IKEv2 Payloads">
<t>The mechanism described in this document is not intended to be
used at the same time as the existing INTERNAL_IP6_ADDRESS
attribute. For compatibility with gateways implementing only
INTERNAL_IP6_ADDRESS, the VPN client MAY include attributes for both
mechanisms in CFG_REQUEST. The capabilities and preferences of the
VPN gateway will then determine which is used.</t>
<t>All other attributes except INTERNAL_IP6_ADDRESS (and
INTENAL_ADDRESS_EXPIRY) from <xref target="IKEv2"/> remain valid,
including the somewhat confusingly named INTERNAL_IP6_SUBNET (see
Section 6.3 of <xref target="RFC4718"/> for discussion).</t>
</section>
</section>
<!-- ====================================================================== -->
<section title="Payload Formats">
<section title="INTERNAL_IP6_LINK Configuration Attribute">
<t>The INTERNAL_IP6_LINK configuration attribute is formatted as
follows:</t>
<figure><artwork><![CDATA[
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t><list style='symbols'>
<t>Reserved (1 bit) - See <xref target="IKEv2"/>.</t>
<t>Attribute Type (15 bits) - INTERNAL_IP6_LINK (TBD1).</t>
<t>Length (2 octets) - Length in octets of the Value field (Client's
Link-Local Interface ID and IKEv2 Link ID); 8 or more.</t>
<t>Link-Local Interface ID (8 octets) - The Interface ID used for
link-local address (by the party that sent this attribute).</t>
<t>IKEv2 Link ID (variable length) - The link ID (may be empty when the
client does not yet know the link ID).</t>
</list></t>
</section>
<section title="INTERNAL_IP6_PREFIX Configuration Attribute">
<t>The INTERNAL_IP6_PREFIX configuration attribute is formatted as
follows:</t>
<figure><artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t><list style='symbols'>
<t>Reserved (1 bit) - See <xref target="IKEv2"/>.</t>
<t>Attribute Type (15 bits) - INTERNAL_IP6_PREFIX (TBD2).</t>
<t>Length (2 octets) - Length in octets of the Value field;
in this case, 17. </t>
<t>Prefix (16 octets) - An IPv6 prefix assigned to the virtual link. The
low order bits of the prefix field which are not part of the prefix MUST be
set to zero by the sender and MUST be ignored by the receiver.</t>
<t>Prefix Length (1 octets) - The length of the prefix in bits;
usually 64.</t>
</list></t>
</section>
<section title="LINK_ID Notify Payload">
<t>The LINK_ID notification is included in CREATE_CHILD_SA requests
to indicate that the SA being created is related to the virtual
link. If this notification is not included, the CREATE_CHILD_SA
requests is related to the physical interface.</t>
<t>The Notify Message Type for LINK_ID is TBD3. The Protocol ID and
SPI Size fields are set to zero. The data associated with this
notification is the IKEv2 Link ID returned in the INTERNAL_IP6_LINK_ID
configuration attribute.</t>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="iana" title="IANA Considerations">
<t>This document defines two new IKEv2 configuration attributes,
whose values are to be allocated (have been allocated) from the
"IKEv2 Configuration Payload Attribute Types" namespace <xref
target="IKEv2"/>:</t>
<figure><artwork><![CDATA[
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]
]]></artwork></figure>
<t>This document also defines one new IKEv2 notification, whose value is to
be allocated (has been allocated) from the "IKEv2 Notify Message Types -
Status Types" namespace <xref target="IKEv2"/>:</t>
<figure><artwork><![CDATA[
Value Notify Messages - Status Types Reference
------ ------------------------------- ---------
TBD3 LINK_ID [this doc]
]]></artwork></figure>
<t>This document does not create any new namespaces to be maintained
by IANA.</t>
</section>
<!-- ====================================================================== -->
<section anchor="security" title="Security Considerations">
<t>To be written. (The security consideration should be pretty
much the same as for current configuration payloads.)</t>
<t>Assigning each client a unique prefix makes using randomized interface
identifiers <xref target="RFC4941"/> ineffective from privacy point of view:
the client is still uniquely identified by the prefix. In some environments,
it may be preferable to assign a VPN client the same 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 as in Mobile IPv6 -- using the same Home Address forever is simpler
than changing it often, but has privacy implications.)</t>
</section>
<!-- ====================================================================== -->
<section title="Acknowledgments">
<t>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 their valuable comments.</t>
<t>Many of the challenges associated with IPsec-protected "virtual
interfaces" have been identified before: for example, in the context
of protecting IPv6-in-IPv4 tunnels with IPsec <xref
target="RFC4891"/>, Provider Provisioned VPNs <xref target="VLINK"/>
<xref target="RFC3884"/>, and Mobile IPv6 <xref
target="RFC4877"/>. Some of the limitations of assigning a single
IPv6 address were identified in <xref target="RFC3314"/>.</t>
</section>
</middle>
<!-- ====================================================================== -->
<back>
<references title="Normative References">
<reference anchor="KEYWORDS">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
</author>
<date month="March" year="1997"/>
</front>
<seriesInfo name="RFC" value="2119"/>
</reference>
<reference anchor="IKEv2">
<front>
<title>Internet Key Exchange (IKEv2) Protocol</title>
<author fullname="Charlie Kaufman" initials="C" surname="Kaufman">
<organization/>
</author>
<date month="December" year="2005" />
</front>
<seriesInfo name="RFC" value="4306" />
</reference>
<reference anchor="IPv6Addr">
<front>
<title>IP Version 6 Addressing Architecture</title>
<author initials="R" surname="Hinden"><organization /></author>
<author initials="S" surname="Deering"><organization /></author>
<date month="February" year="2006" />
</front>
<seriesInfo name="RFC" value="4291" />
</reference>
</references>
<references title="Informative References">
<reference anchor="CGA">
<front>
<title>Cryptographically Generated Addresses (CGA)</title>
<author initials="T" surname="Aura"><organization /></author>
<date month="March" year="2006" />
</front>
<seriesInfo name="RFC" value="3972" />
</reference>
<reference anchor="AUTOCONF">
<front>
<title>IPv6 Stateless Address Autoconfiguration</title>
<author initials="S" surname="Thomson"><organization /></author>
<author initials="T" surname="Narten"><organization /></author>
<author initials="T" surname="Jinmei"><organization /></author>
<date month="September" year="2007" />
</front>
<seriesInfo name="RFC" value="4862" />
</reference>
<reference anchor="IPv6ND">
<front>
<title>Neighbor Discovery for IP version 6 (IPv6)</title>
<author initials="T" surname="Narten"><organization /></author>
<author initials="E" surname="Nordmark"><organization /></author>
<author initials="W" surname="Simpson"><organization /></author>
<author initials="H" surname="Soliman"><organization /></author>
<date month="September" year="2007" />
</front>
<seriesInfo name="RFC" value="4861" />
</reference>
<reference anchor="NDProxy">
<front>
<title>Neighbor Discovery Proxies (ND Proxy)</title>
<author initials="D" surname="Thaler"><organization /></author>
<author initials="M" surname="Talwar"><organization /></author>
<author initials="C" surname="Patel"><organization /></author>
<date month="April" year="2006" />
</front>
<seriesInfo name="RFC" value="4389" />
</reference>
<reference anchor="DHCPv6">
<front>
<title>Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title>
<author initials="R" surname="Droms"><organization /></author>
<author initials="J" surname="Bound"><organization /></author>
<author initials="B" surname="Volz"><organization /></author>
<author initials="T" surname="Lemon"><organization /></author>
<author initials="C" surname="Perkins"><organization /></author>
<author initials="M" surname="Carney"><organization /></author>
<date month="July" year="2003" />
</front>
<seriesInfo name="RFC" value="3315" />
</reference>
<reference anchor="SHIM6">
<front>
<title>Shim6: Level 3 Multihoming Shim Protocol for IPv6</title>
<author initials="E" surname="Nordmark"><organization /></author>
<author initials="M" surname="Bagnulo"><organization /></author>
<date month="February" year="2008" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-shim6-proto-10" />
</reference>
<reference anchor="IPConfig">
<front>
<title>Principles of Internet Host Configuration</title>
<author initials="B" surname="Aboba"><organization /></author>
<author initials="D" surname="Thaler"><organization /></author>
<author initials="L" surname="Andersson"><organization /></author>
<date month="May" year="2008" />
</front>
<seriesInfo name="Internet-Draft" value="draft-iab-ip-config-04" />
</reference>
<reference anchor="Multilink">
<front>
<title>Multi-Link Subnet Issues</title>
<author initials="D" surname="Thaler"><organization /></author>
<date month="June" year="2007" />
</front>
<seriesInfo name="RFC" value="4903" />
</reference>
<reference anchor="MOBIKE">
<front>
<title>IKEv2 Mobility and Multihoming Protocol (MOBIKE)</title>
<author initials="P" surname="Eronen"><organization /></author>
<date month="June" year="2006" />
</front>
<seriesInfo name="RFC" value="4555" />
</reference>
<reference anchor="RFC4891">
<front>
<title>Using IPsec to Secure IPv6-in-IPv4 Tunnels</title>
<author initials="R" surname="Graveman"><organization /></author>
<author initials="M" surname="Parthasarathy"><organization /></author>
<author initials="P" surname="Savola"><organization /></author>
<author initials="H" surname="Tschofenig"><organization /></author>
<date month="May" year="2007" />
</front>
<seriesInfo name="RFC" value="4891" />
</reference>
<reference anchor="RFC4877">
<front>
<title>Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture</title>
<author initials="V" surname="Devarapalli"><organization /></author>
<author initials="F" surname="Dupont"><organization /></author>
<date month="April" year="2007" />
</front>
<seriesInfo name="RFC" value="4877" />
</reference>
<reference anchor="IPv6PPP">
<front>
<title>IP Version 6 over PPP</title>
<author initials="S" surname="Varada"><organization /></author>
<author initials="D" surname="Haskins"><organization /></author>
<author initials="E" surname="Allen"><organization /></author>
<date month="September" year="2007" />
</front>
<seriesInfo name="RFC" value="5072" />
</reference>
<reference anchor="VLINK">
<front>
<title>Framework for IPsec Protected Virtual Links for PPVPNs</title>
<author initials="M" surname="Duffy"><organization /></author>
<date month="October" year="2002" />
</front>
<seriesInfo name="Internet-Draft" value="draft-duffy-ppvpn-ipsec-vlink-00" />
</reference>
<reference anchor="HBA">
<front>
<title>Hash Based Addresses (HBA)</title>
<author initials="M" surname="Bagnulo"><organization /></author>
<date month="December" year="2007" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-shim6-hba-05" />
</reference>
<reference anchor="RFC4718">
<front>
<title>IKEv2 Clarifications and Implementation Guidelines</title>
<author fullname="Pasi Eronen" initials="P" surname="Eronen">
<organization/>
</author>
<author fullname="Paul Hoffman" initials="P" surname="Hoffman">
<organization/>
</author>
<date month="October" year="2006" />
</front>
<seriesInfo name="RFC" value="4718" />
</reference>
<reference anchor="RFC3884">
<front>
<title>Use of IPsec Transport Mode for Dynamic Routing</title>
<author initials="J" surname="Touch"><organization/></author>
<author initials="L" surname="Eggert"><organization/></author>
<author initials="Y" surname="Wang"><organization/></author>
<date month="September" year="2004" />
</front>
<seriesInfo name="RFC" value="3884" />
</reference>
<reference anchor="RFC3456">
<front>
<title>Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode</title>
<author initials="B" surname="Patel"><organization/></author>
<author initials="B" surname="Aboba"><organization/></author>
<author initials="S" surname="Kelly"><organization/></author>
<author initials="V" surname="Gupta"><organization/></author>
<date month="January" year="2003" />
</front>
<seriesInfo name="RFC" value="3456" />
</reference>
<reference anchor="MLDv2">
<front>
<title>Multicast Listener Discovery Version 2 (MLDv2) for IPv6</title>
<author initials="R" surname="Vida"><organization /></author>
<author initials="L" surname="Costa"><organization /></author>
<date month="June" year="2004" />
</front>
<seriesInfo name="RFC" value="3810" />
</reference>
<reference anchor="RFC4941">
<front>
<title>Privacy Extensions for Stateless Address Autoconfiguration in IPv6</title>
<author initials="T" surname="Narten"><organization /></author>
<author initials="R" surname="Draves"><organization /></author>
<author initials="S" surname="Krishnan"><organization /></author>
<date month="September" year="2007" />
</front>
<seriesInfo name="RFC" value="4941" />
</reference>
<reference anchor="RFC3314">
<front>
<title>Recommendations for IPv6 in Third Generation Partnership Project 3GPP) Standards</title>
<author initials="M" surname="Wasserman"><organization /></author>
<date month="September" year="2002" />
</front>
<seriesInfo name="RFC" value="3314" />
</reference>
<reference anchor="RFC3633">
<front>
<title>IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6</title>
<author initials="O" surname="Troan"><organization /></author>
<author initials="R" surname="Droms"><organization /></author>
<date month="December" year="2003" />
</front>
<seriesInfo name="RFC" value="3633" />
</reference>
<reference anchor="RFC4193">
<front>
<title>Unique Local IPv6 Unicast Addresses</title>
<author initials="R" surname="Hinden"><organization /></author>
<author initials="B" surname="Haberman"><organization /></author>
<date month="October" year="2005" />
</front>
<seriesInfo name="RFC" value="4193" />
</reference>
<reference anchor="RFC4866">
<front>
<title>Enhanced Route Optimization for Mobile IPv6</title>
<author initials="J" surname="Arkko"><organization /></author>
<author initials="C" surname="Vogt"><organization /></author>
<author initials="W" surname="Haddad"><organization /></author>
<date month="May" year="2007" />
</front>
<seriesInfo name="RFC" value="4866" />
</reference>
<reference anchor="RFC4294">
<front>
<title>IPv6 Node Requirements</title>
<author initials="J" surname="Loughney" role="editor"><organization /></author>
<date month="April" year="2006" />
</front>
<seriesInfo name="RFC" value="4294" />
</reference>
</references>
<section title="Alternative Solution Sketches">
<section title="Version -00 Sketch">
<t>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.</t>
<t>1) During IKE_AUTH, client sends a new configuration attribute,
INTERNAL_IP6_LINK_ID, 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).</t>
<figure><artwork><![CDATA[
CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK_ID(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) -->
]]></artwork></figure>
<t>The VPN gateway replies with its own link-local interface ID
(which MUST be different from the client's) and an IKEv2 Link ID
(which will be used for reauthentication).</t>
<figure><artwork><![CDATA[
CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK_ID(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)
]]></artwork></figure>
<t>At this point, both peers configure the virtual interface with
the link-local addresses.</t>
<t>2) The next step is IPv6 stateless address autoconfiguration;
that is, Router Solicitation and Router Advertisement messages sent
over the IPsec SA. </t>
<figure><artwork><![CDATA[
ESP(Router Solicitation:
src=:
dst=FF02:0:0:0:0:0:0:2) -->
<-- ESP(Router Advertisement:
src=FE80::<Gateway's Interface ID>
dst=FF02:0:0:0:0:0:0:1,
Prefix1, [Prefix2...])
]]></artwork></figure>
<t>After receiving the Router Advertisement, the client can
configure unicast addresses from the advertised prefixes, using any
interface ID. The VPN gateway MUST NOT simultaneously assign the
same prefixes to any other client, and MUST NOT itself configure
addresses from these prefixes. Thus, the client does not have to
perform Duplicate Address Detection (DAD).</t>
<t>3) Reauthentication works basically the same way as in
<xref target="reauth"/>; the client includes the IKEv2 Link ID
in the INTERNAL_IP6_LINK_ID attribute.</t>
<t>4) Creating and rekeying IPsec SAs works basically the same way
as in <xref target="childsas"/>; the client includes the IKEv2 Link
ID in those CHILD_SA requests that are related to the virtual
link.</t>
<t>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.</t>
</section>
<section title="Router Aggregation Sketch #1">
<t>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.</t>
<t>1) During IKE_AUTH, the client sends a new configuration
attribute, INTERNAL_IP6_LINK_ID, 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).</t>
<figure><artwork><![CDATA[
CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK_ID(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) -->
]]></artwork></figure>
<t>The VPN gateway replies with its own link-local interface ID
(which MUST 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).</t>
<figure><artwork><![CDATA[
CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK_ID(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)
]]></artwork></figure>
<t>2) The client now configures tentative unicast addresses from the
prefixes given by the gateway, and performs Duplicate Address
Detection (DAD) for them.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Router Aggregation Sketch #2">
<t>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.</t>
<t>1) During IKE_AUTH, client sends a new configuration attribute,
INTERNAL_IP6_LINK_ID, 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).</t>
<figure><artwork><![CDATA[
CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK_ID(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) -->
]]></artwork></figure>
<t>The VPN gateway replies with its own link-local interface ID
(which MUST be different from the client's) and an IKEv2 Link ID
(which will be used for reauthentication).</t>
<figure><artwork><![CDATA[
CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK_ID(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)
]]></artwork></figure>
<t>At this point, both peers configure the virtual interface with
the link-local addresses.</t>
<t>2) The next step is IPv6 stateless address autoconfiguration;
that is, Router Solicitation and Router Advertisement messages sent
over the IPsec SA.</t>
<figure><artwork><![CDATA[
ESP(Router Solicitation:
src=:
dst=FF02:0:0:0:0:0:0:2) -->
<-- ESP(Router Advertisement:
src=FE80::<Gateway's Interface ID>
dst=FF02:0:0:0:0:0:0:1,
Prefix1, [Prefix2...])
]]></artwork></figure>
<t>3) The client now configures tentative unicast addresses from the
prefixes given by the gateway, and performs Duplicate Address
Detection (DAD) for them.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="IPv4-like Sketch">
<t>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.</t>
<t>1) During IKE_AUTH, the client sends a new configuration
attribute, INTERNAL_IP6_LINK_ID, 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).</t>
<figure><artwork><![CDATA[
CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK_ID(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) -->
]]></artwork></figure>
<t>The VPN gateway replies with its own link-local interface ID
(which MUST 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.</t>
<figure><artwork><![CDATA[
CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK_ID(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)
]]></artwork></figure>
<t>Since the VPN gateway keeps track of address uniqueness, there is
no need to perform Duplicate Address Detection.</t>
<t>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:</t>
<figure><artwork><![CDATA[
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) -->
]]></artwork></figure>
<t>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.</t>
<figure><artwork><![CDATA[
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)
]]></artwork></figure>
<t>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.</t>
<t>The biggest disadvantages are probably potentially complex
implementation dependency for interface ID selection (see <xref
target="iidselection"/>), and the multi-link subnet model.</t>
</section>
<section title="Sketch Based on RFC 3456">
<t>For completeness: a solution modeled after <xref
target="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.</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:19:32 |