RFC 5739
IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)
IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) 🎀
Okay bestie, this one is RFC 5739 💖. It's an IETF document (Internet Engineering Task Force) and its category is Experimental. The ISSN is 2070-1721, and it's dated February 2010 🌸. The authors are P. Eronen from Nokia, J. Laganier from QUALCOMM, Inc., and C. Madson from Cisco Systems 🧚. The header doesn't list anything it obsoletes or updates, so it's not replacing or changing any other RFC 🫶.
Abstract ✨
Okay so when IKEv2 is used for remote VPN access (client to VPN gateway), the gateway hands the client an IP address from the internal network using IKEv2 configuration payloads 🔐. The configuration payloads from RFC 4306 work really well for IPv4, but they make it hard to use certain IPv6 features 🙈. This document adds new configuration attributes for IKEv2 so the VPN gateway can give clients IPv6 prefixes 🦋. That means you can use all the IPv6 features over the client-gateway "virtual link" and it's literally iconic 👑.
Status of This Memo 📜
This document is not an Internet Standards Track specification. It's being published so people can look at it, try implementing it, and evaluate it 🧪.
It defines an Experimental Protocol for the Internet community and it's a product of the IETF 💜. It represents the consensus of the IETF community and it's had public review. The IESG approved it for publication. Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 💅.
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc5739 ⭐.
Copyright Notice 🌈
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date of publication. Please read these carefully, because they explain your rights and restrictions for this document. Code Components taken from this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 📝.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have allowed the IETF Trust to permit modifications outside the IETF Standards Process. Without a proper license from those copyright holders, this document can't be modified outside the IETF Standards Process, and derivative works can't be created outside it. The exception is formatting it for publication as an RFC or translating it into languages other than English 🙏.
Table of Contents 🗂️
1. Introduction and Problem Statement ..............................4
2. Terminology .....................................................5
3. Current Limitations and Goals ...................................6
3.1. Multiple Prefixes ..........................................6
3.2. Link-Local Addresses .......................................6
3.3. Interface Identifier Selection .............................7
3.4. Sharing VPN Access .........................................7
3.5. General Goals ..............................................8
3.6. Non-Goals ..................................................8
3.7. Additional Information .....................................9
4. Solution Details ................................................9
4.1. Initial Exchanges ..........................................9
4.2. Reauthentication ..........................................11
4.3. Creating CHILD_SAs ........................................11
4.4. Relationship to Neighbor Discovery ........................12
4.5. Relationship to Existing IKEv2 Payloads ...................13
5. Payload Formats ................................................13
5.1. INTERNAL_IP6_LINK Configuration Attribute .................13
5.2. INTERNAL_IP6_PREFIX Configuration Attribute ...............14
5.3. LINK_ID Notify Payload ....................................14
6. IANA Considerations ............................................15
7. Security Considerations ........................................15
8. Acknowledgments ................................................15
9. References .....................................................16
9.1. Normative References ......................................16
9.2. Informative References ....................................16
Appendix A. Design Rationale (Non-Normative) ...................19
A.1. Link Model ................................................20
A.2. Distributing Prefix Information ...........................20
A.3. Unique Address Allocation .................................21
A.4. Layer 3 Access Control ....................................21
A.5. Other Considerations ......................................22
A.6. Alternative Solution Sketches .............................24
A.6.1. Version -00 Sketch ..................................24
A.6.2. Router Aggregation Sketch #1 ..........................25
A.6.3. Router Aggregation Sketch #2 ..........................27
A.6.4. IPv4-Like Sketch ....................................28
A.6.5. Sketch Based on RFC 3456 ..............................30
Appendix B. Evaluation (Non-Normative) .........................311. Introduction and Problem Statement ✨
Okay so in typical remote access VPN use (client to VPN gateway), the client needs an IP address inside the network that the security gateway protects 🏰. IKEv2 has a feature called "configuration payloads" that lets the gateway dynamically give the client a temporary address [IKEv2] 💫.
For IPv4, the message exchange goes like this:
Client Gateway
-------- ---------
HDR(IKE_SA_INIT), SAi1, KEi, Ni -->
<-- HDR(IKE_SA_INIT), SAr1, KEr, Nr, [CERTREQ]
HDR(IKE_AUTH),
SK { IDi, CERT, [CERTREQ], AUTH, [IDr],
CP(CFG_REQUEST) =
{ INTERNAL_IP4_ADDRESS(),
INTERNAL_IP4_DNS() }, SAi2,
TSi = (0, 0-65535, 0.0.0.0-255.255.255.255),
TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) } -->
<-- HDR(IKE_AUTH),
SK { IDr, CERT, AUTH,
CP(CFG_REPLY) =
{ INTERNAL_IP4_ADDRESS(192.0.2.234),
INTERNAL_IP4_DNS(198.51.100.33) },
SAr2,
TSi = (0, 0-65535, 192.0.2.234-192.0.2.234),
TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) }
Figure 1: IPv4 ConfigurationThe IPv4 case has been implemented by lots of vendors and, for the most part, it works great 🥰. 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 ConfigurationSo basically, IPv6 gets treated like IPv4 with bigger addresses 🙃. As noted in [RFC4718], this doesn't fully follow the "normal IPv6 way of doing things", and it makes certain IPv6 features complicated or impossible to use 😭. Section 3 goes through the limitations in detail 📋.
This document adds new configuration attributes for IKEv2 so the VPN gateway can assign IPv6 prefixes to clients. That means all the IPv6 features can work over 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 with IKEv2 payloads are described, optional payloads go in brackets, like [FOO]. A plus sign means a payload can be repeated one or more times, like FOO+ 🧩.
This document uses the term "virtual interface" to describe how the client uses the IPv6 address(es) the gateway assigns 🫧. Existing IPsec documents don't use this term, but the idea isn't new. To use the address the VPN gateway assigns, current VPN clients already make a local "virtual interface", because only addresses assigned to interfaces can be used, for example as source addresses for TCP connections 🌊. Heads up: this definition of "interface" isn't necessarily the same as what some implementations call an "interface" 🙈.
3. Current Limitations and Goals 🦋
This section covers the limitations of the current IPv6 configuration mechanism and the requirements for the new solution 📝.
3.1. Multiple Prefixes 🌸
Okay so in Figure 2, only one IPv6 address (from one prefix) gets assigned 🎀. The spec does let the client put several INTERNAL_IP6_ADDRESS attributes in its request, but the gateway can't assign more addresses than the client asked for 😤.
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 about how many different addresses (from different prefixes) the client should get 🧠.
The solution should support assigning addresses from multiple prefixes, without requiring the client to know beforehand how many prefixes are needed 💖.
3.2. Link-Local Addresses 🦋
Okay so the IPv6 addressing architecture [IPv6Addr] says "IPv6 addresses of all types are assigned to interfaces, not nodes. [..] All interfaces are required to have at least one Link-Local unicast address". So every interface needs a link-local address, bestie 😭
Right now, the virtual interface made by IKEv2 configuration payloads doesn't have one. That breaks the rules in [IPv6Addr] and blocks protocols that need link-local addresses, like [MLDv2] and [DHCPv6]. Not it 💀
The fix is to give the virtual interfaces link-local addresses and let them 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 picks the interface ID the client uses. The client can also ask for a specific interface ID, and then the gateway picks the prefix part 💅
This gets messy with Cryptographically Generated Addresses (CGAs) [CGA], because the interface ID can't be calculated until the prefix is known. The client could grab a non-CGA address first to learn the prefix, then send a separate CFG_REQUEST to get a CGA with that same prefix. But that means the IKEv2 software has to talk to the component that manages CGAs, which is an ugly implementation dependency that's best avoided 🙅
Similar concerns pop up whenever the client cares which interface ID gets used, like Hash-Based Addresses (HBA) [HBA] and privacy addresses [RFC4941] 🌈
Without CGAs and HBAs, VPN clients can't fully use IPv6 features like [SHIM6] or enhanced Mobile IPv6 route optimization [RFC4866] 😭
The solution should let the VPN client easily get several addresses from a given prefix, where the client selects the interface IDs and they may depend on the prefix 🫶
3.4. Sharing VPN Access 🌸
Some VPN clients want to share the VPN connection with other devices (e.g., from a cell phone to a laptop or vice versa) over a local area network connection (such as Wireless LAN or Bluetooth), if the security policy allows it 📱
Obviously, sharing VPN access needs more than one address (unless NAT is used). But the current model, where each address is requested separately, is probably complicated to fit into a local area network that uses stateless address autoconfiguration [AUTOCONF]. So getting a whole prefix for the VPN client and advertising it to the local link (something resembling [NDProxy]) would be preferable. With DHCPv6 prefix delegation [RFC3633], even [NDProxy] and its associated multi-link subnet issues would be avoided 🧚
The solution should support sharing VPN access over a local area network connection when the other hosts are using stateless address autoconfiguration 🦋
3.5. General Goals 💜
- The solution should avoid periodic messages over the VPN tunnel.
- Reauthentication should work, where the client can start a new IKE Security Association (SA) and continue using the same addresses as before 🔁
- There should be compatibility with other IPsec uses. Configuring a virtual IPv6 link (with addresses assigned in IKEv2) should not prevent the same peers from using IPsec/IKEv2 for other uses (with other addresses). In particular, the peers may have Security Policy Database (SPD) entries and Peer Authorization Database (PAD) Child SA Authorization Data entries that are not related to the virtual link. When a CHILD_SA is created, it should be unambiguous which entries are used 👀
- There should be compatibility with current IPv6 configuration. Although the current IPv6 mechanism is not widely implemented, new solutions should not preclude its use (e.g., by defining incompatible semantics for the existing payloads) 🙏
- The solution should have clean implementation dependencies. In particular, it should not require significant modifications to the core IPv6 stack (typically part of the operating system), or require the IKEv2 implementor to re-implement parts of the IPv6 stack (e.g., to have access or control to functionality that is currently not exposed by interfaces of the IPv6 stack) 🧼
- Re-use existing mechanisms as much as possible, as described in [IPConfig]. Appendix A describes the rationale for why this document nevertheless uses IKEv2 configuration payloads for configuring the addresses. However, Section 4.1 recommends using a DHCPv6 Information-Request message for obtaining other configuration information (such as DNS server addresses) 🎀
3.6. Non-Goals 🙅
Mobile IPv6 already defines how it interacts with IPsec/IKEv2 [RFC4877], and the intent of this document is not to change that interaction in any way. Hands off, periodt 💅
3.7. Additional Information 📚
If the VPN client is assigned IPv6 address(es) from prefix(es) that are shared with other VPN clients, this results in some kind of multi-link subnet. [Multilink] describes issues associated with multi-link subnets and recommends that they be avoided 🙈
The original 3GPP specifications for IPv6 assigned a single IPv6 address to each mobile phone, which resembled the current IKEv2 payloads. [RFC3314] describes the problems with this approach, and it caused 3GPP to change the specifications to assign unique /64 prefix(es) for each phone 📲
Due to similar concerns, the IEEE 802.16 IPv6 Convergence Sublayer [RFC5121] and Proxy Mobile IPv6 [RFC5213] also assign unique prefixes ✨
4. Solution Details 💖
4.1. Initial Exchanges 🚀
During IKE_AUTH, the client sends a new configuration attribute, INTERNAL_IP6_LINK, which requests that a virtual link be configured. The attribute contains the client's interface ID for the link-local address (other addresses may use other interface IDs). Typically, the client would also ask for the DHCPv6 server address. This is used only for configuration (such as DNS server addresses), not address assignment 🍓
CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK(Client's Link-Local Interface ID)
INTERNAL_IP6_DHCP() }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->If the client has sent the INTERNAL_IP6_LINK configuration attribute, the VPN gateway SHOULD ignore any INTERNAL_IP6_ADDRESS configuration attribute present in the request 🙃
The VPN gateway MUST choose for itself a link-local interface identifier different than the client's, i.e., accept the link-local interface identifier proposed by the client. In case the VPN gateway cannot accept the link-local interface identifier the client proposed, the VPN gateway MUST fail the IPv6 address assignment by including a NOTIFY payload with the INTERNAL_ADDRESS_FAILURE message 🚫
The VPN gateway then replies with an INTERNAL_IP6_LINK configuration attribute that contains the IKEv2 Link ID (an identifier selected by the VPN gateway, treated as an opaque octet string by the client -- this will be used for reauthentication and CREATE_CHILD_SA messages), the gateway's link-local interface identifier, and zero or more INTERNAL_IP6_PREFIX attributes. The traffic selectors proposed by the initiator are also narrowed to contain only the assigned prefixes and the client link-local address (FE80::<Client's Interface ID>) identifier 🎯
CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK(Gateway's Link-Local Interface ID,
IKEv2 Link ID)
INTERNAL_IP6_PREFIX(Prefix1/64),
[INTERNAL_IP6_PREFIX(Prefix2/64),...],
INTERNAL_IP6_DHCP(Address) }
TSi = ((0, 0-65535,
FE80::<Client's Interface ID> -
FE80::<Client's Interface ID>)
(0, 0-65535,
Prefix1::0 -
Prefix1::FFFF:FFFF:FFFF:FFFF),
[(0, 0-65535,
Prefix2::0 -
Prefix2::FFFF:FFFF:FFFF:FFFF), ...])
TSr = (0, 0-65535,
0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)At this point, the client can configure its link-local address (FE80::<Client's Interface ID>) and other non-link-local unicast addresses from the assigned prefixes (with any proper interface identifier [IPv6Addr]). The VPN gateway MUST NOT simultaneously assign the same prefixes to any other client, and MUST NOT itself configure addresses from these prefixes. Thus, the client does not have to perform Duplicate Address Detection (DAD). (This approach is based on [IPv6PPP].) No DAD drama, just vibes 🌊
The prefixes remain valid through the lifetime of the IKE SA (and its continuations via rekeying). If the VPN gateway needs to remove a prefix it has previously assigned, or assign a new prefix, it can do so with reauthentication (either by starting reauthentication itself or by requesting the client to reauthenticate using [RFC4478]) 🔄
The client also contacts the DHCPv6 server. This is the RECOMMENDED way to obtain additional configuration parameters (such as DNS server addresses), as it allows easier extensibility and more options (such as the domain search list for DNS) 🌟
4.2. Reauthentication 🔐
When the client performs reauthentication (and wants to continue using the same "virtual link"), it includes the IKEv2 Link ID given by the gateway in the INTERNAL_IP6_LINK attribute 💫
CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK(Client's Link Local Interface ID,
IKEv2 Link ID)
INTERNAL_IP6_DHCP() }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->At this point, the gateway MUST verify that the client is indeed allowed to use the link identified by the IKEv2 Link ID. The same situation occurs in [IKEv2] when the client wants to continue using the same IPv4 address with the INTERNAL_IP4_ADDRESS configuration attribute. Typically, the gateway would use the Link ID to look up relevant local state and compare the authenticated peer identity of the IKE_SA with that local state 🕵️
If the client is allowed to continue using this link, the gateway replies (see Section 4.1) with the same gateway's link-local interface ID and IKEv2 Link ID as used earlier, and sends the IPv6 prefix(es) associated with this link. Usually, the IPv6 prefix(es) will also be the same as earlier, but this is not required 🥰
If the client is not allowed to continue using this link, the gateway treats it as a request for a new virtual link, selects a different IKEv2 Link ID value, and replies as in Section 4.1 💅
4.3. Creating CHILD_SAs 🎀
Okay so when a CHILD_SA gets created, both peers need to figure out which SPD entries and PAD Child SA Authorization Data entries apply to it. In the basic client-to-VPN-gateway setup this is simple, bestie. All the matching SPD entries and Child SA Authorization Data entries belong to the "virtual link" between the VPN client and the VPN gateway. 💖
But ngl, it gets messy when the same peers also use IPsec/IKEv2 for other stuff, with addresses that aren't assigned inside IKEv2. Then they'd have SPD entries and PAD Child SA Authorization Data that have nothing to do with the virtual link. 🙈
So say one peer requests a CHILD_SA and proposes traffic selectors that cover everything (like in Figure 2). Should those get narrowed down to the prefixes configured with INTERNAL_IP6_PREFIX, or to the other SPD/PAD entries? 🤔 Some kind of heuristics are possible (see Appendix A for discussion), but this document goes with an explicit solution:
The peers MUST include a LINK_ID notification, containing the IKEv2 Link ID, in all CREATE_CHILD_SA requests (including rekeys) that are related to the virtual link. The LINK_ID notification is not included in the CREATE_CHILD_SA response or when doing IKE_SA rekeying. ✨
4.4. Relationship to Neighbor Discovery 🧚
Neighbor Discovery [IPv6ND] has a bunch of mechanisms, and here's how they fit in. 💅
Router Discovery, Prefix Discovery, Parameter Discovery, and address autoconfiguration are not used, because IKEv2 already handles that functionality. 🫶
Address Resolution, Next-hop Determination, and Redirect are not used either. The virtual link doesn't have link-layer addresses and it's a point-to-point link, so there's nothing for them to do. 🦋
Neighbor Unreachability Detection could be used, but it's a bit redundant next to IKEv2 Dead Peer Detection. 💀
Duplicate Address Detection isn't needed here, because it's a point-to-point link. The VPN gateway doesn't assign any addresses from the global unicast prefixes, and the link-local interface identifier gets negotiated separately. 🌸
Duplicate Address Detection isn't needed for global unicast addresses formed from the global unicast prefix(es) configured as part of the IKEv2 exchange, for the same reason: point-to-point link, no gateway-assigned global unicast addresses. Duplicate Address Detection may be needed for link-local addresses though, e.g., when the client configures a link-local address as per [RFC4941]. 👀
So, Duplicate Address Detection MAY be skipped for global unicast addresses formed from the global unicast prefix(es) configured as part of the IKEv2 exchange. However, Duplicate Address Detection for link-local unicast addresses MUST be performed as required per some other specifications, e.g., [RFC4941]. No skipping that one, periodt! 🚫✨
4.5. Relationship to Existing IKEv2 Payloads 🍓
The mechanism in this document is not intended to be used at the same time as the existing INTERNAL_IP6_ADDRESS attribute. 🙅♀️
For compatibility with gateways that only implement INTERNAL_IP6_ADDRESS, the VPN client MAY include attributes for both mechanisms in CFG_REQUEST. The gateway's capabilities and preferences then decide which one gets used. It's giving "let the server pick" energy 😌
All the other attributes from [IKEv2] except INTERNAL_IP6_ADDRESS (and INTENAL_ADDRESS_EXPIRY) remain valid. That includes the somewhat confusingly named INTERNAL_IP6_SUBNET (see Section 6.3 of [RFC4718] for discussion). The naming really is a whole thing 🙃
5. Payload Formats 🌈
5.1. INTERNAL_IP6_LINK Configuration Attribute 🎀
The INTERNAL_IP6_LINK configuration attribute is laid out like this:
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's the breakdown:
- Reserved (1 bit): see [IKEv2].
- Attribute Type (15 bits): INTERNAL_IP6_LINK (17).
- Length (2 octets): the length in octets of the Value field (Link-Local Interface ID and IKEv2 Link ID). It's 8 or more. 📏
- Link-Local Interface ID (8 octets): the Interface ID used for the link-local address by the party that sent this attribute. 🔗
- IKEv2 Link ID (variable length): the Link ID. It may be empty when the client doesn't know the Link ID yet. The gateway selects the Link ID, and the client treats it as an opaque octet string. No peeking inside, bestie 🤐
5.2. INTERNAL_IP6_PREFIX Configuration Attribute 🦋
The INTERNAL_IP6_PREFIX configuration attribute is laid out like this:
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 |
+-+-+-+-+-+-+-+-+Here's the breakdown:
- Reserved (1 bit): see [IKEv2].
- Attribute Type (15 bits): INTERNAL_IP6_PREFIX (18).
- Length (2 octets): the length in octets of the Value field. In this case it's 17. 🔢
- Prefix (16 octets): an IPv6 prefix assigned to the virtual link. The low-order bits of the prefix field that are not part of the prefix MUST be set to zero by the sender and MUST be ignored by the receiver. So the sender zeroes them and the receiver ignores them. Clean ✨
- Prefix Length (1 octet): the length of the prefix in bits, usually 64. 💜
5.3. LINK_ID Notify Payload 🌸
The LINK_ID notification gets included in CREATE_CHILD_SA requests to show that the SA being created is related to the virtual link. If this notification isn't included, the CREATE_CHILD_SA requests are related to the real interface. 🔌
The Notify Message Type for LINK_ID is 16414. The Protocol ID and SPI Size fields are set to zero. The data for this notification is the IKEv2 Link ID returned in the INTERNAL_IP6_LINK configuration attribute. 🫶
6. IANA Considerations 📋
This document defines two new IKEv2 configuration attributes. Their values were allocated from the "IKEv2 Configuration Payload Attribute Types" namespace [IKEv2]:
Multi-
Value Attribute Type Valued Length Reference
------ ---------------------- ------ ------------- ---------
17 INTERNAL_IP6_LINK NO 8 or more [RFC5739]
18 INTERNAL_IP6_PREFIX YES 17 octets [RFC5739]It also defines one new IKEv2 notification, whose value was allocated from the "IKEv2 Notify Message Types - Status Types" namespace [IKEv2]:
Value Notify Messages - Status Types Reference
------ ------------------------------- ---------
16414 LINK_ID [RFC5739]This document doesn't create any new namespaces for IANA to maintain. Nice and tidy 🧹✨
7. Security Considerations 🔐
Since this document is an extension to IKEv2, the security considerations in [IKEv2] apply here as well. 🚨
The mechanism in this document assigns each client a unique prefix. That makes randomized interface identifiers [RFC4941] ineffective from a privacy point of view, because the client is still uniquely identified by the prefix. 😱 In some environments it may be preferable to give a VPN client the same prefix every time a VPN connection is established. Other environments may prefer a different prefix every time for privacy reasons. (This is basically the same trade-off as in Mobile IPv6: using the same Home Address forever is simpler than changing it often, but it has privacy implications.) It's a classic trade-off, and the drama is real 🎭💅
8. Acknowledgments 💖
The authors would like to thank Patrick Irwin, Tero Kivinen, Chinh Nguyen, Mohan Parthasarathy, Yaron Sheffer, Hemant Singh, Dave Thaler, Yinghzhe Wu, and Fan Zhao for their valuable comments. Iconic squad, honestly 👑
Many of the challenges associated with IPsec-protected "virtual interfaces" have been identified before. For example, they came up in the context of protecting IPv6-in-IPv4 tunnels with IPsec [RFC4891], Provider Provisioned VPNs ([VLINK], [RFC3884]), and Mobile IPv6 [RFC4877]. Some of the limitations of assigning a single IPv6 address were identified in [RFC3314]. So this problem has main character energy, but it's not new 🌟
9. References 📚
9.1. Normative References 🧾
- [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
- [IPv6Addr] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References 📚🎀
[AUTOCONF] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[CGA] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2006.
[DHCPv6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[HBA] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535,
June 2009.
[IPConfig] Aboba, B., Thaler, D., Andersson, L., and S. Cheshire,
"Principles of Internet Host Configuration", RFC 5505,
May 2009.
[IPv6ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[IPv6PPP] Varada, S., Haskins, D., and E. Allen, "IP Version 6
over PPP", RFC 5072, September 2007.
[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[MOBIKE] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
[Multilink] Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
June 2007.
[NDProxy] Thaler, D., Talwar, M., and C. Patel, "Neighbor
Discovery Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards",
RFC 3314, September 2002.
[RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic
Host Configuration Protocol (DHCPv4) Configuration of
IPsec Tunnel Mode", RFC 3456, January 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec
Transport Mode for Dynamic Routing", RFC 3884,
September 2004.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4478] Nir, Y., "Repeated Authentication in Internet Key
Exchange (IKEv2) Protocol", RFC 4478, April 2006.
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
Implementation Guidelines", RFC 4718, October 2006.
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
Optimization for Mobile IPv6", RFC 4866, May 2007.
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation
with IKEv2 and the Revised IPsec Architecture",
RFC 4877, April 2007.
[RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H.
Tschofenig, "Using IPsec to Secure IPv6-in-IPv4
Tunnels", RFC 4891, May 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S.
Madanapalli, "Transmission of IPv6 via the IPv6
Convergence Sublayer over IEEE 802.16 Networks",
RFC 5121, February 2008.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury,
K., and B. Patil, "Proxy Mobile IPv6", RFC 5213,
August 2008.
[SHIM6] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009.
[VLINK] Duffy, M., "Framework for IPsec Protected Virtual Links
for PPVPNs", Work in Progress, October 2002.Appendix A. Design Rationale (Non-Normative) 🧠✨
okay so this appendix is the "why" behind the whole Section 4 design 💅 it explains why we picked the solution we picked, and it also lists some other options that got considered and then rejected 😭
This appendix describes some of the reasons why the solution in Section 4 was selected and lists some alternative designs that were considered but were ultimately rejected.
bestie, when you give a client a new IPv6 address, it creates a new "virtual IPv6 interface" and a "virtual link" between the client and the gateway 🦋 so let's assume that virtual link has these properties:
- The link and its interfaces are created and destroyed by the IKEv2 process.
- The link is not an IPsec SA; at any time, there can be zero or more IPsec SAs covering traffic on this link.
- The link is not a single IKE SA; to support reauthentication, it must be possible to identify the same link in another IKE SA.
- Not all IPsec-protected traffic between the peers is necessarily related to the virtual link (although in the simplest VPN client-to-gateway scenario, it will be).
Given these assumptions and the goals described in Section 3, it seems like the most important design choices are these 👑:
- What link/subnet model is used; in other words, how relationships between VPN clients, IPv6 subnet prefixes, and link-local traffic (especially link-local multicast) are organized.
- How information about the IPv6 prefix(es) is distributed from the gateway to the clients.
- How to ensure unique IPv6 addresses for each client and keep forwarding state up-to-date accordingly.
- How layer 3 access control is done; in other words, where the mechanisms for preventing address spoofing by clients are placed architecturally.
We'll go through each of these one by one 🫶
A.1. Link Model 🌸
there are at least three main choices for how to organize the relationships between VPN clients, IPv6 subnet prefixes, and link-local traffic:
- 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.
- Multi-access link model: multiple VPN clients share the same IPv6 prefix. Link-local multicast packets sent by one VPN client will be received by other VPN clients (VPN gateway will forward the packets, possibly with Multicast Listener Discovery (MLD) snooping to remove unnecessary packets).
- "Router aggregation" link model: one form of "multi-link" subnet [Multilink] where multiple VPN clients share the same IPv6 prefix. Link-local multicast will not be received by other VPN clients.
In the multi-access link model, VPN clients who are idle (i.e., not currently sending or receiving application traffic) could receive significant amounts of multicast packets from other clients (depending on how many other clients are connected). 😩 This is especially undesirable when the clients are battery-powered, such as a PDA that keeps the VPN connection to corporate intranet active 24/7. For this reason, using the multi-access link model was rejected.
The configuration attributes specified in Section 4 use the point-to-point link model. 💖
A.2. Distributing Prefix Information 🎁
some types of addresses, such as CGAs, need to know the prefix before an address can be generated. The prefix information could be distributed to clients in the following ways:
- IKEv2 messages (configuration payloads)
- Router Advertisement messages (sent over the IPsec tunnel)
- DHCPv6 messages (sent over the IPsec tunnel)
In Section 4, the prefix information is distributed in IKEv2 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 make sure 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 so it can forward traffic correctly. 🙈
The main choices seem to be the following:
- 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.
- 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).
- Clients can use stateless address autoconfiguration to configure addresses and perform Duplicate Address Detection (DAD). This is easy to do in a multi-access link model and can be made to work with a router aggregation link model if the VPN gateway traps Neighbor Solicitation (NS) messages and spoofs Neighbor Advertisement (NA) replies. The gateway keeps track of which client is using which address (and updates its forwarding state accordingly) by trapping these NS/NA messages.
In the point-to-point link model, the client can simply use any address from the prefix, and the VPN gateway only needs to know which client is using which prefix in order to forward packets correctly. 🦋
A.4. Layer 3 Access Control 🚧
it's almost always desirable to prevent one VPN client from sending packets with a source address that is used by another VPN client. 💀 To forward packets destined to clients correctly, 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.
- Layer 3 access control could be enforced by IPsec Security Association Database (SAD) / SPD; the addresses/prefixes assigned to a VPN client would be reflected in the traffic selectors used in IPsec Security Association and Security Policy Database entries, as negotiated in IKEv2.
- The ingress filtering capability could be placed outside IPsec; the traffic selectors in SAD/SPD entries would cover traffic that would be dropped later by ingress filtering.
The former approach is used by the current IPv4 solution and the mechanism specified in Section 4. 🌈
A.5. Other Considerations ✨
VPN gateway state 🌸
okay so, with some combos of design choices, the amount of state the VPN gateway has to keep depends not just on how many clients there are but also on how many addresses ONE client uses 👀. With privacy addresses, and maybe some uses of Cryptographically Generated Addresses (CGAs), a single client could end up with a huge pile of different addresses, especially if it uses different privacy addresses for different destinations. it's a lot, bestie 😭
Virtual link identifier 🦋
reauthentication needs a way to uniquely identify the virtual link when a second IKE SA gets created. some options are the IKE Security Parameter Indexes (SPIs) of the IKE SA where the virtual link was "created" (assuming we can't have multiple virtual links inside the same IKE SA), a brand new identifier assigned when the link gets created, or any unique prefix or address that stays assigned to the link for its whole lifetime. Section 4 says the gateway assigns a new IKEv2 Link ID when the link is created 💜. the client treats the Link ID as an opaque octet string, and the gateway uses it to find the relevant local state when reauthentication happens. iconic.
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 by the outer IP addresses of the peers (thanks to NAT Traversal and [MOBIKE]). so don't go using those as the identifier, not me 🙅♀️
Prefix lifetime 🎀
prefixes could stay valid for the lifetime of the IKE SA, until somebody explicitly cancels them, or for an explicitly specified time. in Section 4, the prefixes stay valid for the lifetime of the IKE SA (and its continuations via rekeying, but NOT via reauthentication). if needed, the VPN gateway can add or remove prefixes by triggering reauthentication 🔥. it's assumed that adding or removing prefixes is a pretty rare situation, so this document doesn't specify fancier solutions (like explicit prefix lifetimes or use of CFG_SET/CFG_ACK). simple is slay ✨
Compatibility with other IPsec uses 🧚
compatibility with other IPsec uses probably means that when a CHILD_SA is created, both peers need to be able to tell whether the CHILD_SA applies to the virtual interface (at the end of the virtual link) or to the real interfaces that the IKEv2 messages are being sent over. this is required so they pick the correct SPD for traffic-selector narrowing and SA authorization in general. the stakes are high here, fr fr 😭
one straightforward solution is to add an extra payload to CREATE_CHILD_SA requests that carries the virtual link identifier. requests without this payload would refer to the real link (the one the IKEv2 messages are sent over) 🍓.
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's probably related to the virtual interface.
these heuristics can work in lots of situations, but they've proved inadequate for IPv6-in-IPv4 tunnels [RFC4891], Provider Provisioned VPNs ([VLINK], [RFC3884]), and Mobile IPv6 [RFC4877] 💀. so Section 4 includes the virtual link identifier in ALL CREATE_CHILD_SA requests that apply to the virtual interface. no guessing, we're doing it properly 💅
Example of other IPsec uses: 🌈
if a VPN gateway gets a CREATE_CHILD_SA request tied to a physical Ethernet interface, asking for an SA for (TSi=FE80::something, dst=*), it would typically reject the request (or, in other words, narrow it down to an empty set). why? because it doesn't have SPD/PAD entries that would let joe.user@example.com request those CHILD_SAs 🙈.
(however, it might have SPD/PAD entries that would let "neighboring-router.example.com" create such SAs to protect, for example, some routing protocol that uses link-local addresses 🤓.)
BUT the virtual interface created when joe.user@example.com authenticated and sent INTERNAL_IP6_LINK would have a different SPD/PAD, and that one WOULD let joe.user@example.com create this SA. that's the glow-up 🦋✨
A.6. Alternative Solution Sketches 🌟
A.6.1. Version -00 Sketch 🍓
the -00 version of this document had the following solution sketch, which is basically a combo of (1) a point-to-point link model, (2) prefix information distributed in Neighbor Advertisements, and (3) access control enforced outside IPsec 💜.
- during IKE_AUTH, the client sends a new configuration attribute, INTERNAL_IP6_LINK, which requests a virtual link to be created. the attribute carries the client's interface ID for the link-local address (other addresses may use other interface IDs) 🫶.
CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID) }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->the VPN gateway replies with its own link-local interface ID (which has to be different from the client's) and an IKEv2 Link ID (which will be used for reauthentication) 🎀.
CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID) }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)at this point, both peers configure the virtual interface with the link-local addresses 🌸.
- the next step is IPv6 stateless address autoconfiguration, meaning Router Solicitation and Router Advertisement messages sent over the IPsec SA 🧚.
ESP(Router Solicitation:
src=::,
dst=FF02:0:0:0:0:0:0:2) -->
<-- ESP(Router Advertisement:
src=FE80::<Gateway's Interface ID>
dst=FF02:0:0:0:0:0:0:1,
Prefix1, [Prefix2...])after getting the Router Advertisement, the client can configure unicast addresses from the advertised prefixes, using any proper interface ID 💅. the VPN gateway does NOT assign the same prefixes to any other client at the same time, and it doesn't configure addresses from these prefixes itself. so the client doesn't have to perform Duplicate Address Detection (DAD) 🙌.
- reauthentication works basically the same way as in Section 4; the client includes the IKEv2 Link ID in the INTERNAL_IP6_LINK attribute 🔁.
- creating and rekeying IPsec SAs works basically the same way as in Section 4.3; the client includes the IKEv2 Link ID in those CHILD_SA requests that are related to the virtual link 🔑.
Comments: this got changed in the -01 version of this document based on feedback from VPN vendors. the solution looks nice on paper, but it was claimed to be unnecessarily complex to implement when the IKE implementation and IPv6 stack come from different companies 😩. plus, enforcing access control outside IPsec is a big architectural change compared to current IPv4 solutions. big mood, but not the move 💀
A.6.2. Router Aggregation Sketch #1 🌙
Hemant Singh helped sketch the following solution during the IETF 70 meeting in Vancouver 🇨🇦✨. it combines (1) the router aggregation link model, (2) prefix information distributed in IKEv2 messages, (3) unique address allocation with stateless address autoconfiguration (with the VPN gateway trapping NS messages and spoofing NA replies), and (4) access control enforced (partly) outside IPsec 👑.
- during IKE_AUTH, the client sends a new configuration attribute, INTERNAL_IP6_LINK, which requests a virtual link to be created. the attribute carries the client's interface ID for the link-local address (other addresses may use other interface IDs) 💖.
CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID) }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->the VPN gateway replies with its own Link-Local Interface ID (which has to be different from the client's), 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 also get narrowed down to contain only the assigned prefixes (and the link-local prefix) 🧸.
CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID),
INTERNAL_IP6_PREFIX(Prefix1/64),
[INTERNAL_IP6_PREFIX(Prefix2/64),...] }
TSi = ((0, 0-65535,
FE80::<Client's Interface ID> -
FE80::<Client's Interface ID>)
(0, 0-65535,
Prefix1::0 -
Prefix1::FFFF:FFFF:FFFF:FFFF),
[(0, 0-65535,
Prefix2::0 -
Prefix2::FFFF:FFFF:FFFF:FFFF), ...])
TSr = (0, 0-65535,
0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)- the client now configures tentative unicast addresses from the prefixes given by the gateway, and performs Duplicate Address Detection (DAD) on them 🔍.
the Neighbor Solicitation messages get 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's now being used by this client and updates its forwarding state accordingly 🛰️.
Comments: the main disadvantages of this solution are the non-standard processing of NS messages (which are used to update the gateway's forwarding state), and performing access control partly outside IPsec. so it's a bit of a messy girlie, but we respect the effort 💅🩷
A.6.3. Router Aggregation Sketch #2 🧚
okay so this one is basically a cousin of the version -00 sketch 💅 but it uses the router aggregation link model. it mashes together four things: (1) the router aggregation link model, (2) prefix information distributed in Neighbor Advertisements, (3) unique address allocation with stateless address autoconfiguration (where the VPN gateway traps NS messages and spoofs NA replies), and (4) access control enforced outside IPsec. it's giving mix-and-match energy 🦋
- During IKE_AUTH, the client sends a new configuration attribute, INTERNAL_IP6_LINK, asking for a virtual link to be created. the attribute carries the client's interface ID for the link-local address (other addresses may use other interface IDs).
CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID) }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->the VPN gateway replies with its own Link-Local Interface ID (which has to be different from the client's) and an IKEv2 Link ID (which will be used for reauthentication) ✨
CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID) }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)at this point, both peers configure the virtual interface with the link-local addresses 🫶
- next up is IPv6 stateless address autoconfiguration, which means Router Solicitation and Router Advertisement messages sent over the IPsec SA 🌸
ESP(Router Solicitation:
src=::,
dst=FF02:0:0:0:0:0:0:2) -->
<-- ESP(Router Advertisement:
src=FE80::<Gateway's Interface ID>
dst=FF02:0:0:0:0:0:0:1,
Prefix1, [Prefix2...])- the client now configures tentative unicast addresses from the prefixes the gateway gave it, and performs Duplicate Address Detection (DAD) on them 🔥
the Neighbor Solicitation messages get 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's now being used by this client and updates its forwarding state to match 💜
comments: the main disadvantages of this solution are the non-standard processing of NS messages (which are used to update the gateway's forwarding state) and performing access control outside IPsec. bestie, that's a lot of weird plumbing 😭
A.6.4. IPv4-Like Sketch 🎀
this sketch looks a lot like the current IPv4 configuration payloads 🍓 it combines (1) the router aggregation link model, (2) prefix information distributed in IKEv2 messages, (3) unique address allocation with IKEv2 messages, and (4) access control enforced by IPsec SAD/SPD. so basically everything lives inside IKEv2 and IPsec, which is very tidy ngl
- During IKE_AUTH, the client sends a new configuration attribute, INTERNAL_IP6_LINK, asking for a virtual link to be created. the attribute carries the client's interface ID for the link-local address (other addresses may use other interface IDs).
CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID) }
TSi = (0, 0-65535,
0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535,
0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->the VPN gateway replies with its own Link-Local Interface ID (which has to be different from the client's), 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 holds one address from a particular prefix 🌈
CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID),
INTERNAL_IP6_ADDRESS2(Prefix1+Client's Interface ID1),
[INTERNAL_IP6_ADDRESS2(Prefix2+Client's Interface ID2),...],
TSi = ((0, 0-65535,
FE80::<Client's Link-Local Interface ID> -
FE80::<Client's Link-Local Interface ID>)
(0, 0-65535,
Prefix1::<Client's Interface ID1> -
Prefix1::<Client's Interface ID1>),
[(0, 0-65535,
Prefix2::<Client's Interface ID2> -
Prefix2::<Client's Interface ID2>), ...])
TSr = (0, 0-65535,
0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)since the VPN gateway keeps track of address uniqueness, there's no need to perform Duplicate Address Detection 🙈
- if the client wants more addresses later (say, with a specific interface ID), it asks for 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 isn't currently in use by some other client, the VPN gateway just returns the same address along with the appropriately narrowed traffic selectors ✨
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 here is that it's quite close to the current IPv4 way of doing things 🥹 by adding explicit link creation (with a Link ID for reauthentication/SPD selection and link-local addresses) and slightly changing the semantics (and also the name) of the INTERNAL_IP6_ADDRESS attribute (which can return more attributes than was asked), we get much of the functionality we need.
the biggest disadvantages are probably the potentially complex implementation dependency for interface ID selection (see Section 3.3) and the multi-link subnet model 🫠
A.6.5. Sketch Based on RFC 3456 💫
for completeness: a solution modeled after [RFC3456] would combine (1) the router aggregation link model, (2) prefix information distribution and unique address allocation with DHCPv6, and (3) access control enforced by IPsec SAD/SPD. different vibe, same goal 🦋
Appendix B. Evaluation (Non-Normative) 👑
Section 3 describes the goals and requirements for IPv6 configuration in IKEv2. this appendix is the report card 📝 it briefly sums up how the solution specified in Sections 4 and 5 measures up against those goals.
- (3.1) Assigning addresses from multiple prefixes is supported, and the client doesn't have to know beforehand how many prefixes it needs. 🎀
- (3.2) Link-local addresses are assigned and can be used for protocols between the VPN client and gateway. 💖
- (3.3) The entire prefix is assigned to a single client, so the client can freely select any number of interface IDs (which may depend on the prefix). 🌸
- (3.4) This document doesn't specify how the VPN client would share the VPN connection with other devices. however, since the entire prefix goes to a single client, the client could further assign addresses from it without needing to coordinate with the VPN gateway. 🧚
- (3.5) The solution doesn't add any new periodic messages over the VPN tunnel. 🌈
- (3.5) Reauthentication works (see Section 4.2). 🔥
- (3.5) The solution is compatible with other IPsec uses, since the LINK_ID notification makes it unambiguous which CHILD_SAs are related to the virtual link and which aren't (see Sections 4.3 and 5.3). ✨
- (3.5) The new mechanisms don't stop the VPN client and/or gateway from implementing the INTERNAL_IP6_ADDRESS configuration attribute as well. however, the two mechanisms aren't intended to be used at the same time (see Section 4.5). 🙃
- (3.5) Implementation dependencies are, obviously, implementation dependent (and their cleanliness is somewhat subjective). possible drawbacks of some alternative solutions are discussed in Appendix A.6. 💅
- (3.5) The mechanism for configuring the prefixes (configuration payloads) is specific to IKEv2, for reasons described in Appendix A. however, Section 4.1 recommends using the DHCPv6 Information-Request message for obtaining other configuration information (such as DNS server addresses). 🫶
Authors' Addresses ✉️
Pasi Eronen
Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
Finland
EMail: pasi.eronen@nokia.com
Julien Laganier
QUALCOMM Incorporated
5775 Morehouse Drive
San Diego, CA 92121
USA
Phone: +1 858 658 3538
EMail: julienl@qualcomm.com
Cheryl Madson
Cisco Systems, Inc.
510 MacCarthy Drive
Milpitas, CA
USA
EMail: cmadson@cisco.com📦 where this page comes from
- ietf: rfc5739 2010-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms