idnits 2.17.1 draft-ietf-ipsecme-ikev2-ipv6-config-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 14 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 17, 2009) is 5426 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'CERTREQ' is mentioned on line 144, but not defined == Missing Reference: 'IDr' is mentioned on line 144, but not defined ** Obsolete normative reference: RFC 4306 (ref. 'IKEv2') (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. 'DHCPv6') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4718 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Eronen 3 Internet-Draft Nokia 4 Intended status: Experimental J. Laganier 5 Expires: December 19, 2009 DOCOMO Euro-Labs 6 C. Madson 7 Cisco Systems 8 June 17, 2009 10 IPv6 Configuration in IKEv2 11 draft-ietf-ipsecme-ikev2-ipv6-config-01 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 19, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 When IKEv2 is used for remote VPN access (client to VPN gateway), the 50 gateway assigns the client an IP address from the internal network 51 using IKEv2 configuration payloads. The configuration payloads 52 specified in RFC 4306 work well for IPv4, but make it difficult to 53 use certain features of IPv6. This document specifies new 54 configuration attributes for IKEv2 that allows the VPN gateway to 55 assign IPv6 prefixes to clients, enabling all features of IPv6 to be 56 used with the client-gateway "virtual link". 58 Table of Contents 60 1. Introduction and Problem Statement . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3. Current Limitations and Goals . . . . . . . . . . . . . . . . 7 63 3.1. Multiple Prefixes . . . . . . . . . . . . . . . . . . . . 7 64 3.2. Link-Local Addresses . . . . . . . . . . . . . . . . . . . 7 65 3.3. Interface Identifier Selection . . . . . . . . . . . . . . 7 66 3.4. Sharing VPN Access . . . . . . . . . . . . . . . . . . . . 8 67 3.5. General Goals . . . . . . . . . . . . . . . . . . . . . . 8 68 3.6. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 9 69 3.7. Additional Information . . . . . . . . . . . . . . . . . . 9 70 4. Solution Details . . . . . . . . . . . . . . . . . . . . . . . 10 71 4.1. Initial Exchanges . . . . . . . . . . . . . . . . . . . . 10 72 4.2. Reauthentication . . . . . . . . . . . . . . . . . . . . . 11 73 4.3. Creating CHILD_SAs . . . . . . . . . . . . . . . . . . . . 12 74 4.4. Relationship to Neighbor Discovery . . . . . . . . . . . . 12 75 4.5. Relationship to Existing IKEv2 Payloads . . . . . . . . . 13 76 5. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 14 77 5.1. INTERNAL_IP6_LINK Configuration Attribute . . . . . . . . 14 78 5.2. INTERNAL_IP6_PREFIX Configuration Attribute . . . . . . . 14 79 5.3. LINK_ID Notify Payload . . . . . . . . . . . . . . . . . . 15 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 82 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 86 Appendix A. Design Rationale (Non-Normative) . . . . . . . . . . 22 87 A.1. Link Model . . . . . . . . . . . . . . . . . . . . . . . . 22 88 A.2. Distributing Prefix Information . . . . . . . . . . . . . 23 89 A.3. Unique Address Allocation . . . . . . . . . . . . . . . . 23 90 A.4. Layer 3 Access Control . . . . . . . . . . . . . . . . . . 24 91 A.5. Other Considerations . . . . . . . . . . . . . . . . . . . 25 92 A.6. Alternative Solution Sketches . . . . . . . . . . . . . . 27 93 A.6.1. Version -00 Sketch . . . . . . . . . . . . . . . . . . 27 94 A.6.2. Router Aggregation Sketch #1 . . . . . . . . . . . . . 28 95 A.6.3. Router Aggregation Sketch #2 . . . . . . . . . . . . . 29 96 A.6.4. IPv4-like Sketch . . . . . . . . . . . . . . . . . . . 31 97 A.6.5. Sketch Based on RFC 3456 . . . . . . . . . . . . . . . 32 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 100 1. Introduction and Problem Statement 102 In typical remote access VPN use (client to VPN gateway), the client 103 needs an IP address in the network protected by the security gateway. 104 IKEv2 includes a feature called "configuration payloads" that allows 105 the gateway to dynamically assign a temporary address to the client 106 [IKEv2]. 108 For IPv4, the message exchange would look as follows: 110 Client Gateway 111 -------- --------- 113 HDR(IKE_SA_INIT), SAi1, KEi, Ni --> 115 <-- HDR(IKE_SA_INIT), SAr1, KEr, Nr, [CERTREQ] 117 HDR(IKE_AUTH), 118 SK { IDi, CERT, [CERTREQ], AUTH, [IDr], 119 CP(CFG_REQUEST) = 120 { INTERNAL_IP4_ADDRESS(), 121 INTERNAL_IP4_DNS() }, SAi2, 122 TSi = (0, 0-65535, 0.0.0.0-255.255.255.255), 123 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) } --> 125 <-- HDR(IKE_AUTH), 126 SK { IDr, CERT, AUTH, 127 CP(CFG_REPLY) = 128 { INTERNAL_IP4_ADDRESS(192.0.2.234), 129 INTERNAL_IP4_DNS(10.11.22.33) }, 130 SAr2, 131 TSi = (0, 0-65535, 192.0.2.234-192.0.2.234), 132 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) } 134 Figure 1: IPv4 configuration 136 The IPv4 case has been implemented by various vendors, and in general 137 works well. IKEv2 also defines almost identical configuration 138 payloads for IPv6: 140 Client Gateway 141 -------- --------- 143 HDR(IKE_AUTH), 144 SK { IDi, CERT, [CERTREQ], AUTH, [IDr], 145 CP(CFG_REQUEST) = 146 { INTERNAL_IP6_ADDRESS(), 147 INTERNAL_IP6_DNS() }, SAi2, 148 TSi = (0, 0-65535, 149 0:0:0:0:0:0:0:0 - 150 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF), 151 TSr = (0, 152 0-65535, 0:0:0:0:0:0:0:0 - 153 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) } --> 155 <-- HDR(IKE_AUTH), 156 SK { IDr, CERT, AUTH, 157 CP(CFG_REPLY) = 158 { INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5, 159 64), 160 INTERNAL_IP6_DNS(2001:DB8:9:8:7:6:5:4) }, 161 SAr2, 162 TSi = (0, 0-65535, 163 2001:DB8:0:1:2:3:4:5 - 164 2001:DB8:0:1:2:3:4:5), 165 TSr = (0, 0-65535, 166 0:0:0:0:0:0:0:0: - 167 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) } 169 Figure 2: IPv6 configuration 171 In other words, IPv6 is basically treated as IPv4 with larger 172 addresses. As noted in [RFC4718], this does not fully follow the 173 "normal IPv6 way of doing things", and it complicates or prevents 174 using certain features of IPv6. Section 3 describes the limitations 175 in detail. 177 This document specifies new configuration attributes for IKEv2 that 178 allows the VPN gateway to assign IPv6 prefixes to clients, enabling 179 all features of IPv6 to be used with the client-gateway "virtual 180 link". 182 2. Terminology 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [KEYWORDS]. 188 When messages containing IKEv2 payloads are described, optional 189 payloads are shown in brackets (for instance, "[FOO]"), and a plus 190 sign indicates that a payload can be repeated one or more times (for 191 instance, "FOO+"). 193 This document uses the term "virtual interface" when describing how 194 the client uses the IPv6 address(es) assigned by the gateway. While 195 existing IPsec documents do not use this term, it is not a new 196 concept. In order to use the address assigned by the VPN gateway, 197 current VPN clients already create a local "virtual interface", as 198 only addresses assigned to interfaces can be used, e.g., as source 199 addresses for TCP connections. Note that this definition of 200 "interface" is not necessarily identical with what some particular 201 implementation calls "interface". 203 3. Current Limitations and Goals 205 This section describes the limitations of the current IPv6 206 configuration mechanism, and requirements for the new solution. 208 3.1. Multiple Prefixes 210 In Figure 2 only a single IPv6 address (from a single prefix) is 211 assigned. The specification does allow the client to include 212 multiple INTERNAL_IP6_ADDRESS attributes in its request, but the 213 gateway cannot assign more addresses than the client requested. 215 Multiple prefixes are useful for site renumbering, host-based site 216 multihoming [SHIM6], and unique local IPv6 addresses [RFC4193]. In 217 all of these cases, the gateway has better information on how many 218 different addresses (from different prefixes) the client should be 219 assigned. 221 The solution should support assigning address from multiple prefixes, 222 without requiring the client to know beforehand how many prefixes are 223 needed. 225 3.2. Link-Local Addresses 227 The IPv6 addressing architecture [IPv6Addr] specifies that "IPv6 228 addresses of all types are assigned to interfaces, not nodes. [..] 229 All interfaces are required to have at least one Link-Local unicast 230 address". 232 Currently, the virtual interface created by IKEv2 configuration 233 payloads does not have link-local addresses. This violates the 234 requirements in [IPv6Addr] and prevents the use of protocols that 235 require link-local addresses, such as [MLDv2] and [DHCPv6]. 237 The solution should assign link-local addresses to the virtual 238 interfaces, and allow them to be used for protocols between the VPN 239 client and gateway. 241 3.3. Interface Identifier Selection 243 In the message exchange shown in Figure 2, the gateway chooses the 244 interface ID used by the client. It is also possible for the client 245 to request a specific interface ID; the gateway then chooses the 246 prefix part. 248 This approach complicates the use of Cryptographically Generates 249 Addresses [CGA]. With CGAs, the interface ID cannot be calculated 250 before the prefix is known. The client could first obtain a non-CGA 251 address to determine the prefix, and then send a separate CFG_REQUEST 252 to obtain a CGA address with the same prefix. However, this approach 253 requires that the IKEv2 software component provides an interface to 254 the component managing CGAs; an ugly implementation dependency that 255 would be best avoided. 257 Similar concerns apply to other cases where the client has some 258 interest in what interface ID is being used, such as Hash-Based 259 Addresses [HBA] and privacy addresses [RFC4941]. 261 Without CGAs and HBAs, VPN clients are not able to fully use IPv6 262 features such as [SHIM6] or enhanced Mobile IPv6 route optimization 263 [RFC4866]. 265 The solution should allow the VPN client to easily obtain several 266 addresses from a given prefix, where the interface IDs are selected 267 by the client, and may depend on the prefix. 269 3.4. Sharing VPN Access 271 Some VPN clients may want to share the VPN connection with other 272 devices (e.g., from a cell phone to a laptop, or vice versa) via some 273 local area network connection (such as Wireless LAN or Bluetooth), if 274 allowed by the security policy. 276 Quite obviously sharing of VPN access requires more than one address 277 (unless NAT is used). However, the current model where each address 278 is requested separately is probably complex to integrate with a local 279 area network that uses stateless address autoconfiguration 280 [AUTOCONF]. Thus, obtaining a whole prefix for the VPN client, and 281 advertising that to the local link (something resembling [NDProxy]) 282 would be preferable. With DHCPv6 prefix delegation [RFC3633], even 283 [NDProxy] and associated multi-link subnet issues would be avoided. 285 The solution should support sharing the VPN access over a local area 286 network connection when the other hosts are using stateless address 287 autoconfiguration. 289 3.5. General Goals 291 o The solution should avoid periodic messages over the VPN tunnel. 293 o Re-authentication works: the client can start a new IKE SA and 294 continue using the same addresses as before. 296 o Compatibility with other IPsec uses: Configuring a virtual IPv6 297 link (with addresses assigned in IKEv2) should not prevent the 298 same peers from using IPsec/IKEv2 for other uses (with other 299 addresses). In particular, the peers may have SPD entries and PAD 300 Child SA Authorization Data entries that are not related to the 301 virtual link; when a CHILD_SA is created, it should be unambigous 302 which entries are used. 304 o Compatibility with current IPv6 configuration: Although the 305 current IPv6 mechanism is not widely implemented, new solutions 306 should not preclude its use (e.g., by defining incompatible 307 semantics for the existing payloads). 309 o The solution should have clean implementation dependencies. In 310 particular, it should not require significant modifications to the 311 core IPv6 stack (typically part of the operating system), or 312 require the IKEv2 implementor to re-implement parts of the IPv6 313 stack (to, e.g., have access or control to functionality that is 314 currently not exposed by interfaces of the IPv6 stack). 316 3.6. Non-Goals 318 Mobile IPv6 already defines how it interacts with IPsec/IKEv2 319 [RFC4877], and the intent of this document is not to change that 320 interaction in any way. 322 3.7. Additional Information 324 If the VPN client is assigned IPv6 address(es) from prefix(es) that 325 are shared with other VPN clients, this results in some kind of 326 multi-link subnet. [Multilink] describes issues associated with 327 multi-link subnets, and recommends that they should be avoided. 329 The original 3GPP standards for IPv6 assigned a single IPv6 address 330 to each mobile phone, resembling current IKEv2 payloads. [RFC3314] 331 described the problems with this approach, and caused 3GPP to change 332 the specifications to assign unique /64 prefix(es) for each phone. 334 Due to similar concerns, the IEEE 802.16 IPv6 Convergence Sublayer 335 [RFC5121] and Proxy Mobile IPv6 [RFC5213] also assign unique 336 prefixes. 338 4. Solution Details 340 4.1. Initial Exchanges 342 1) During IKE_AUTH, the client sends a new configuration attribute, 343 INTERNAL_IP6_LINK, which requests a virtual link to be configured. 344 The attribute contains the client's interface ID for the link-local 345 address (other addresses may use other interface IDs). Typically, 346 the client would also ask for DHCPv6 server address; this is used 347 only for configuration (such as DNS server addresses), not address 348 assignment. 350 CP(CFG_REQUEST) = 351 { INTERNAL_IP6_LINK(Client's Link-Local Interface ID) 352 INTERNAL_IP6_DHCP() } 353 TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - 354 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 355 TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - 356 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 358 If the client has sent the INTERNAL_IP6_LINK configuration attribute, 359 the VPN gateway SHOULD ignore any INTERNAL_IP6_ADDRESS configuration 360 attribute present in the request. 362 The VPN gateway MUST choose for itself a link-local interface 363 identifier different than the client's one, i.e., accept the link- 364 local interface identifier proposed by the client. In case the VPN 365 gateway cannot accept the link-local interface identifier the client 366 proposed, the VPN gateway MUST fail the IPv6 address assignment by 367 including a NOTIFY payload with the INTERNAL_ADDRESS_FAILURE message. 369 The VPN Gateway then replies with an INTERNAL_IP6_LINK configuration 370 attribute that contains the IKEv2 Link ID (an identifier selected by 371 the VPN gateway, treated as an opaque octet string by the client -- 372 this will be used for reauthentication and CREATE_CHILD_SA messages), 373 the gateway's link local interface identier, and zero or more 374 INTERNAL_IP6_PREFIX attributes. The traffic selectors proposed by 375 the initiator are also narrowed to contain only the assigned 376 prefixes, and the client link-local address (FE80::)identifier. 379 CP(CFG_REPLY) = 380 { INTERNAL_IP6_LINK(Gateway's Link-Local Interface ID, 381 IKEv2 Link ID) 382 INTERNAL_IP6_PREFIX(Prefix1/64), 383 [INTERNAL_IP6_PREFIX(Prefix2/64),...], 384 [INTERNAL_IP6_DHCP(Address) ] 385 TSi = ((0, 0-65535, 386 FE80:: - 387 FE80::) 388 (0, 0-65535, 389 Prefix1::0 - 390 Prefix1::FFFF:FFFF:FFFF:FFFF), 391 [(0, 0-65535, 392 Prefix2::0 - 393 Prefix2::FFFF:FFFF:FFFF:FFFF), ...]) 394 TSr = (0, 0-65535, 395 0:0:0:0:0:0:0:0 - 396 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 398 At this point, the client can configure its link-local address 399 (FE80::), and other non-link-local unicast 400 addresses from the assigned prefixes (with any proper interface 401 identifier [IPv6Addr]). The VPN gateway MUST NOT simultaneously 402 assign the same prefixes to any other client, and MUST NOT itself 403 configure addresses from these prefixes. Thus, the client does not 404 have to perform Duplicate Address Detection (DAD). (This approach is 405 based on [IPv6PPP].) 407 The prefixes remain valid through the lifetime of the IKE SA (and its 408 continuations via rekeying). If the VPN gateway needs to remove a 409 prefix it has previously assigned, or assign a new prefix, it can do 410 so with reauthentication (either starting reauthentication itself, or 411 requesting the client to reauthenticate using [RFC4478]). 413 2) The client also contacts the DHCPv6 server. This is the 414 RECOMMENDED way to obtain additional configuration parameters (such 415 as DNS server addresses), as it allows easier extensibility and more 416 options (such as the domain search list for DNS). 418 4.2. Reauthentication 420 When the client performs reauthentication (and wants to continue 421 using the same "virtual link"), it includes the IKEv2 Link ID given 422 by the gateway in the INTERNAL_IP6_LINK attribute. 424 CP(CFG_REQUEST) = 425 { INTERNAL_IP6_LINK(Client's Link Local Interface ID, 426 IKEv2 Link ID) 427 INTERNAL_IP6_DHCP() } 428 TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - 429 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 430 TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - 431 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 433 The gateway uses the Link ID to look up relevant local state, 434 verifies that the authenticated peer identity associated with the 435 link is correct, and continues the handshake as usual. 437 4.3. Creating CHILD_SAs 439 When a CHILD_SA is created, the peers need to determine which SPD 440 entries and PAD Child SA Authorization Data entries are used for this 441 CHILD_SA. In the basic client-to-VPN-gateway uses, the situation is 442 simple: all the matching SPD entries and Child SA Authorization Data 443 entries are related to the "virtual link" between the VPN client and 444 the VPN gateway. However, if the same peers are also using IPsec/ 445 IKEv2 for other uses (with addresses not assigned inside IKEv2), they 446 would also have SPD entries and PAD Child SA Authorization Data that 447 is not related to the virtual link. 449 If one of the peers requests a CHILD_SA and proposes traffic 450 selectors covering everything (like in Figure 2), should those be 451 narrowed to the prefixes configured with INTERNAL_IP6_PREFIX, or to 452 the other SPD/PAD entries? While some kind of heuristics are 453 possible (see Appendix A for discussion), this document specifies an 454 explicit solution: 456 The peers MUST include a LINK_ID notification, containing the IKEv2 457 Link ID, in all CREATE_CHILD_SA requests (including rekeys) that are 458 related to the virtual link. The LINK_ID notification is not 459 included in the CREATE_CHILD_SA response, or when doing IKE_SA 460 rekeying. 462 4.4. Relationship to Neighbor Discovery 464 Neighbor Discovery [IPv6ND] specifies the following mechanisms: 466 Router Discovery, Prefix Discovery, Parameter Discovery, and Address 467 Autoconfiguration are not used, as the necessary functionality is 468 implemented in IKEv2. 470 Address Resolution, Next-hop Determination, and Redirect are not 471 used, as the virtual link does not have link-layer addresses, and is 472 a point-to-point link. 474 Neighbor Unreachability Detection could be used, but is a bit 475 redundant given IKEv2 Dead Peer Detection. 477 Duplicate Address Detection is not needed, because this is a point- 478 to-point link, where the VPN gateway does not assign any addresses 479 from the global unicast prefixes, and link-local interface identifier 480 is negotiated separately. 482 4.5. Relationship to Existing IKEv2 Payloads 484 The mechanism described in this document is not intended to be used 485 at the same time as the existing INTERNAL_IP6_ADDRESS attribute. For 486 compatibility with gateways implementing only INTERNAL_IP6_ADDRESS, 487 the VPN client MAY include attributes for both mechanisms in 488 CFG_REQUEST. The capabilities and preferences of the VPN gateway 489 will then determine which is used. 491 All other attributes except INTERNAL_IP6_ADDRESS (and 492 INTENAL_ADDRESS_EXPIRY) from [IKEv2] remain valid, including the 493 somewhat confusingly named INTERNAL_IP6_SUBNET (see Section 6.3 of 494 [RFC4718] for discussion). 496 5. Payload Formats 498 5.1. INTERNAL_IP6_LINK Configuration Attribute 500 The INTERNAL_IP6_LINK configuration attribute is formatted as 501 follows: 503 1 2 3 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 !R| Attribute Type ! Length | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Link-Local | 509 | Interface ID | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | | 512 ~ IKEv2 Link ID ~ 513 | | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 o Reserved (1 bit) - See [IKEv2]. 518 o Attribute Type (15 bits) - INTERNAL_IP6_LINK (TBD1). 520 o Length (2 octets) - Length in octets of the Value field ( Link- 521 Local Interface ID and IKEv2 Link ID); 8 or more. 523 o Link-Local Interface ID (8 octets) - The Interface ID used for 524 link-local address (by the party that sent this attribute). 526 o IKEv2 Link ID (variable length) - The link ID (may be empty when 527 the client does not yet know the link ID). The link ID is 528 selected by the VPN gateway, and is treated as an opaque octet 529 string by the client. 531 5.2. INTERNAL_IP6_PREFIX Configuration Attribute 533 The INTERNAL_IP6_PREFIX configuration attribute is formatted as 534 follows: 536 1 2 3 537 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 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 !R| Attribute Type ! Length | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | | 542 | Prefix | 543 | | 544 | | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Prefix Length | 547 +-+-+-+-+-+-+-+-+ 549 o Reserved (1 bit) - See [IKEv2]. 551 o Attribute Type (15 bits) - INTERNAL_IP6_PREFIX (TBD2). 553 o Length (2 octets) - Length in octets of the Value field; in this 554 case, 17. 556 o Prefix (16 octets) - An IPv6 prefix assigned to the virtual link. 557 The low order bits of the prefix field which are not part of the 558 prefix MUST be set to zero by the sender and MUST be ignored by 559 the receiver. 561 o Prefix Length (1 octets) - The length of the prefix in bits; 562 usually 64. 564 5.3. LINK_ID Notify Payload 566 The LINK_ID notification is included in CREATE_CHILD_SA requests to 567 indicate that the SA being created is related to the virtual link. 568 If this notification is not included, the CREATE_CHILD_SA requests is 569 related to the real interface. 571 The Notify Message Type for LINK_ID is TBD3. The Protocol ID and SPI 572 Size fields are set to zero. The data associated with this 573 notification is the IKEv2 Link ID returned in the INTERNAL_IP6_LINK 574 configuration attribute. 576 6. IANA Considerations 578 This document defines two new IKEv2 configuration attributes, whose 579 values are to be allocated (have been allocated) from the "IKEv2 580 Configuration Payload Attribute Types" namespace [IKEv2]: 582 Multi- 583 Value Attribute Type Valued Length Reference 584 ------ ---------------------- ------ ------------- --------- 585 TBD1 INTERNAL_IP6_LINK NO 8 or more [this doc] 586 TBD2 INTERNAL_IP6_PREFIX YES 17 octets [this doc] 588 This document also defines one new IKEv2 notification, whose value is 589 to be allocated (has been allocated) from the "IKEv2 Notify Message 590 Types - Status Types" namespace [IKEv2]: 592 Value Notify Messages - Status Types Reference 593 ------ ------------------------------- --------- 594 TBD3 LINK_ID [this doc] 596 This document does not create any new namespaces to be maintained by 597 IANA. 599 7. Security Considerations 601 Assigning each client a unique prefix makes using randomized 602 interface identifiers [RFC4941] ineffective from privacy point of 603 view: the client is still uniquely identified by the prefix. In some 604 environments, it may be preferable to assign a VPN client the same 605 prefix each time a VPN connection is established; other environments 606 may prefer assigning a different prefix every time for privacy 607 reasons. (This is basically a similar trade-off as in Mobile IPv6 -- 608 using the same Home Address forever is simpler than changing it 609 often, but has privacy implications.) 611 8. Acknowledgments 613 The author would like to thank Patrick Irwin, Tero Kivinen, Julien 614 Laganier, Chinh Nguyen, Mohan Parthasarathy, Yaron Sheffer, Hemant 615 Singh, Dave Thaler, Yinghzhe Wu, and Fan Zhao for their valuable 616 comments. 618 Many of the challenges associated with IPsec-protected "virtual 619 interfaces" have been identified before: for example, in the context 620 of protecting IPv6-in-IPv4 tunnels with IPsec [RFC4891], Provider 621 Provisioned VPNs [VLINK] [RFC3884], and Mobile IPv6 [RFC4877]. Some 622 of the limitations of assigning a single IPv6 address were identified 623 in [RFC3314]. 625 9. References 627 9.1. Normative References 629 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 630 RFC 4306, December 2005. 632 [IPv6Addr] 633 Hinden, R. and S. Deering, "IP Version 6 Addressing 634 Architecture", RFC 4291, February 2006. 636 [KEYWORDS] 637 Bradner, S., "Key words for use in RFCs to Indicate 638 Requirement Levels", RFC 2119, March 1997. 640 9.2. Informative References 642 [AUTOCONF] 643 Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 644 Address Autoconfiguration", RFC 4862, September 2007. 646 [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", 647 RFC 3972, March 2006. 649 [DHCPv6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 650 and M. Carney, "Dynamic Host Configuration Protocol for 651 IPv6 (DHCPv6)", RFC 3315, July 2003. 653 [HBA] Bagnulo, M., "Hash Based Addresses (HBA)", 654 draft-ietf-shim6-hba-05 (work in progress), December 2007. 656 [IPv6ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 657 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 658 September 2007. 660 [IPv6PPP] Varada, S., Haskins, D., and E. Allen, "IP Version 6 over 661 PPP", RFC 5072, September 2007. 663 [MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery 664 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 666 [MOBIKE] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 667 (MOBIKE)", RFC 4555, June 2006. 669 [Multilink] 670 Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 671 June 2007. 673 [NDProxy] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 674 Proxies (ND Proxy)", RFC 4389, April 2006. 676 [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third 677 Generation Partnership Project 3GPP) Standards", RFC 3314, 678 September 2002. 680 [RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic 681 Host Configuration Protocol (DHCPv4) Configuration of 682 IPsec Tunnel Mode", RFC 3456, January 2003. 684 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 685 Host Configuration Protocol (DHCP) version 6", RFC 3633, 686 December 2003. 688 [RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec 689 Transport Mode for Dynamic Routing", RFC 3884, 690 September 2004. 692 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 693 Addresses", RFC 4193, October 2005. 695 [RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange 696 (IKEv2) Protocol", RFC 4478, April 2006. 698 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 699 Implementation Guidelines", RFC 4718, October 2006. 701 [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route 702 Optimization for Mobile IPv6", RFC 4866, May 2007. 704 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 705 IKEv2 and the Revised IPsec Architecture", RFC 4877, 706 April 2007. 708 [RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. 709 Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", 710 RFC 4891, May 2007. 712 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 713 Extensions for Stateless Address Autoconfiguration in 714 IPv6", RFC 4941, September 2007. 716 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. 717 Madanapalli, "Transmission of IPv6 via the IPv6 718 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, 719 February 2008. 721 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdury, 722 K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, 723 August 2008. 725 [SHIM6] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 726 Shim Protocol for IPv6", draft-ietf-shim6-proto-12 (work 727 in progress), February 2009. 729 [VLINK] Duffy, M., "Framework for IPsec Protected Virtual Links 730 for PPVPNs", draft-duffy-ppvpn-ipsec-vlink-00 (work in 731 progress), October 2002. 733 Appendix A. Design Rationale (Non-Normative) 735 This appendix describes some of the reasons why the solution in 736 Section 4 was selected, and lists some alternative designs that were 737 considered, but ultimately rejected. 739 Assigning a new IPv6 address to the client creates a new "virtual 740 IPv6 interface", and "virtual link" between the client and the 741 gateway. We will assume that the virtual link has the following 742 properties: 744 o The link and its interfaces are created and destroyed by the IKEv2 745 process. 747 o The link is not an IPsec SA; at any time, there can be zero or 748 more IPsec SAs covering traffic on this link. 750 o The link is not a single IKE SA; to support reauthentication, it 751 must be possible to identify the same link in another IKE SA. 753 o Not all IPsec-protected traffic between the peers is necessarily 754 related to the virtual link (although in the simplest VPN client- 755 to-gateway scenario it will be). 757 Given these assumptions and the goals described in Section 3, it 758 seems that the most important design choices to be made are the 759 following: 761 o What link/subnet model is used: in other words, the relationships 762 between VPN clients, IPv6 subnet prefixes, and link-local traffic 763 (especially link-local multicast). 765 o How information about the IPv6 prefix(es) is distributed from the 766 gateway to the clients. 768 o How to ensure unique IPv6 addresses for each client, and keep 769 forwarding state up-to-date accordingly. 771 o How layer 3 access control is done; in other words, where the 772 mechanisms for preventing address spoofing by clients are placed 773 architecturally. 775 Each of these is discussed next in turn. 777 A.1. Link Model 779 There are at least three main choices how to organize the 780 relationships between VPN clients, IPv6 subnet prefixes, and link- 781 local traffic: 783 o Point-to-point link model: each VPN client is assigned one or more 784 IPv6 prefixes; these prefixes are not shared with other clients, 785 and there is no link-local traffic between different VPN clients 786 connected to the same gateway. 788 o Multi-access link model: multiple VPN clients share the same IPv6 789 prefix. Link-local multicast packets sent by one VPN client will 790 be received by other VPN clients (VPN gateway will forward the 791 packets, possibly with MLD snooping to remove unnecessary 792 packets). 794 o "Router aggregation" link model: one form of "multi-link" subnet 795 [Multilink] where multiple VPN clients share the same IPv6 prefix. 796 Link-local multicast will not be received by other VPN clients. 798 In the multi-access link model, VPN clients who are idle (i.e., not 799 currently sending or receiving application traffic) could receive 800 significant amounts of multicast packets from other clients 801 (depending on how many other clients are connected). This is 802 especially undesirable when the clients are battery-powered; for 803 example, a PDA which keeps the VPN connection to corporate intranet 804 active 24/7. For this reason, using the multi-access link model was 805 rejected. 807 The configuration attributes specified in Section 4 use the point-to- 808 point link model. 810 A.2. Distributing Prefix Information 812 Some types of addresses, such as CGAs, require knowledge about the 813 prefix before an address can be generated. The prefix information 814 could be distributed to clients in the following ways: 816 o IKEv2 messages (Configuration Payloads). 818 o Router Advertisement messages (sent over the IPsec tunnel). 820 o DHCPv6 messages (sent over the IPsec tunnel). 822 In Section 4, the prefix information is distributed in IKEv2 823 messages. 825 A.3. Unique Address Allocation 827 In the "multi-access" and "router aggregation" link models (where a 828 single IPv6 prefix is shared between multiple VPN clients) mechanisms 829 are needed to ensure that one VPN client does not use an address 830 already used by some other client. Also, the VPN gateway has to know 831 which client is using which addresses in order to correctly forward 832 traffic. 834 The main choices seem to be the following: 836 o Clients receive the address(es) they are allowed to use in IKEv2 837 messages (Configuration Payloads). In this case, keeping track of 838 which client is using which address is trivial. 840 o Clients receive the address(es) they are allowed to use in DHCPv6 841 messages sent over the IPsec tunnel. In case the DHCPv6 server is 842 not integrated with the VPN gateway, the gateway may need to work 843 as a relay agent to keep track of which client is using which 844 address (and update its forwarding state accordingly). 846 o Clients can use stateless address autoconfiguration to configure 847 addresses and perform Duplicate Address Detection (DAD). This is 848 easy to do in multi-access link model, and can be made to work 849 with router aggregation link model if the VPN gateway traps 850 Neighbor Solicitation (NS) messages and spoofs Neighbor 851 Advertisement (NA) replies. The gateway keeps track of which 852 client is using which address (and updates its forwarding state 853 accordingly) by trapping these NS/NA messages. 855 In the point-to-point link model, the client can simply use any 856 address from the prefix, and the VPN gateway only needs to know which 857 client is using which prefix in order to forward packets correctly. 859 A.4. Layer 3 Access Control 861 It is almost always desirable to prevent one VPN client from sending 862 packets with a source address that is used by another VPN client. In 863 order to correctly forward packets destined to clients, the VPN 864 gateway obviously has to know which client is using which address; 865 the question is therefore where, architecturally, the mechanisms for 866 ingress filtering are placed. 868 o Layer 3 access control enforced by IPsec SAD/SPD: the addresses/ 869 prefixes assigned to a VPN client are reflected in the traffic 870 selectors used in IPsec Security Association and Security Policy 871 Database entries, as negotiated in IKEv2. 873 o The ingress filtering capability could be placed outside IPsec; 874 the traffic selectors in SAD/SPD entries would cover traffic that 875 would be dropped later by ingress filtering. 877 The former approach is used by the current IPv4 solution, and the 878 mechanism specified in Section 4. 880 A.5. Other Considerations 882 VPN gateway state 884 In some combinations of design choices, the amount of state 885 information required in the VPN gateway depends not only on the 886 number of clients, but also on the number of addresses used by one 887 client. With privacy addresses and potentially some uses of 888 Cryptographically Generated Addresses (CGAs), a single client 889 could have a large number of different addresses (especially if 890 different privacy addresses are used with different destinations). 892 Virtual link identifier 894 Reauthentication requires a way to uniquely identify the virtual 895 link when a second IKE SA is created. Some possible alternatives 896 are the IKE SPIs of the IKE SA where the virtual link was 897 "created" (assuming we can't have multiple virtual links within 898 the same IKE SA), a new identifier assigned when the link is 899 created, or any unique prefix or address that remains assigned to 900 the link for its entire lifetime. Section 4 specifies that the 901 gateway assigns a new IKEv2 Link ID when the link is created. The 902 client treats the Link ID as an opaque octet string; the gateway 903 uses it to identify relevant local state when reauthentication is 904 done. 906 Note that the link is not uniquely identified by the IKE peer 907 identities (because IDi is often a user identity that can be used 908 on multiple hosts at the same time), or the outer IP addresses of 909 the peers (due to NAT Traversal and [MOBIKE]). 911 Prefix lifetime 913 Prefixes could remain valid either for the lifetime of the IKE SA, 914 until explicitly cancelled, or for an explicitly specified time. 915 In Section 4 the prefixes remain valid for the lifetime of the IKE 916 SA (and its continuations via rekeying, but not reauthentication). 917 If necessary, the VPN gateway can thus add or remove prefixes by 918 triggering reauthentication. It is assumed that adding or 919 removing prefixes is a relatively rare situation, and thus this 920 document does not specify more complex solutions (such as explicit 921 prefix lifetimes, or use of CFG_SET/CFG_ACK). 923 Compatibility with other IPsec uses 925 Compatibility with other IPsec uses probably requires that when a 926 CHILD_SA is created, both peers can determine whether the CHILD_SA 927 applies to the virtual interface (at the end of the virtual link), 928 or the real interfaces IKEv2 messages are being sent over. This 929 is required to select the correct SPD to be used for traffic 930 selector narrowing and SA authorization in general. 932 One straight-forward solution is to add an extra payload to 933 CREATE_CHILD_SA requests, containing the virtual link identifier. 934 Requests not containing this payload would refer to the real link 935 (over which IKEv2 messages are being sent). 937 Another solution is to require that the peer requesting a CHILD_SA 938 proposes traffic selectors that identify the link. For example, 939 if TSi includes the peer's "outer" IP address, it's probably 940 related to the real interface, not the virtual one. Or if TSi 941 includes any of the prefixes assigned by the gateway (or the link- 942 local or multicast prefix), it is probably related to the virtual 943 interface. 945 These heuristics can work in many situations, but have proved 946 inadequate in the context of IPv6-in-IPv4 tunnels [RFC4891] and 947 Provider Provisioned VPNs [VLINK] [RFC3884], and Mobile IPv6 948 [RFC4877]. Thus, Section 4 includes the virtual link identifier 949 in all CREATE_CHILD_SA requests that apply to the virtual 950 interface. 952 Example about other IPsec uses: 954 If a VPN gateway receives a CREATE_CHILD_SA request associated 955 with a physical Ethernet interface, requesting SA for (TSi=FE80:: 956 something, dst=*), it would typically reject the request (or in 957 other words, narrow it to an empty set) because it doesn't have 958 SPD/PAD entries that would allow joe.user@example.com to request 959 such CHILD_SAs. 961 (However, it might have SPD/PAD entries that would allow 962 "neighboring-router.example.com" to create such SAs, for 963 protecting e.g. some routing protocol that uses link-local 964 addresses.) 966 However, the virtual interface created when joe.user@example.com 967 authenticated and sent INTERNAL_IP6_LINK would have a different 968 SPD/PAD, which would allow joe.user@example.com to create this SA. 970 A.6. Alternative Solution Sketches 972 A.6.1. Version -00 Sketch 974 The -00 version of this draft contained the following solution 975 sketch, which is basically a combination of (1) point-to-point link 976 model, (2) prefix information distributed in Neighbor Advertisements, 977 and (3) access control enforced outside IPsec. 979 1) During IKE_AUTH, client sends a new configuration attribute, 980 INTERNAL_IP6_LINK, which requests a virtual link to be created. The 981 attribute contains the client's interface ID for link-local address 982 (other addresses may use other interface IDs). 984 CP(CFG_REQUEST) = 985 { INTERNAL_IP6_LINK(Link-Local Interface ID) } 986 TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - 987 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 988 TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - 989 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 991 The VPN gateway replies with its own link-local interface ID (which 992 has to be different from the client's) and an IKEv2 Link ID (which 993 will be used for reauthentication). 995 CP(CFG_REPLY) = 996 { INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID) } 997 TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - 998 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 999 TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1000 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1002 At this point, both peers configure the virtual interface with the 1003 link-local addresses. 1005 2) The next step is IPv6 stateless address autoconfiguration; that 1006 is, Router Solicitation and Router Advertisement messages sent over 1007 the IPsec SA. 1009 ESP(Router Solicitation: 1010 src=::, 1011 dst=FF02:0:0:0:0:0:0:2) --> 1013 <-- ESP(Router Advertisement: 1014 src=FE80:: 1015 dst=FF02:0:0:0:0:0:0:1, 1016 Prefix1, [Prefix2...]) 1018 After receiving the Router Advertisement, the client can configure 1019 unicast addresses from the advertised prefixes, using any proper 1020 interface ID. The VPN gateway does not simultaneously assign the 1021 same prefixes to any other client, and does not itself configure 1022 addresses from these prefixes. Thus, the client does not have to 1023 perform Duplicate Address Detection (DAD). 1025 3) Reauthentication works basically the same way as in Section 4; the 1026 client includes the IKEv2 Link ID in the INTERNAL_IP6_LINK attribute. 1028 4) Creating and rekeying IPsec SAs works basically the same way as in 1029 Section 4.3; the client includes the IKEv2 Link ID in those CHILD_SA 1030 requests that are related to the virtual link. 1032 Comments: This was changed in -01 draft based on feedback from VPN 1033 vendors: while the solution looks nice on paper, it is claimed to be 1034 unneccessarily complex to implement when the IKE implementation and 1035 IPv6 stack are from different companies. Furthermore, enforcing 1036 access control outside IPsec is a significant architectural change 1037 compared to current IPv4 solutions. 1039 A.6.2. Router Aggregation Sketch #1 1041 The following solution was sketched during the IETF 70 meeting in 1042 Vancouver together with Hemant Singh. It combines the (1) router 1043 aggregation link model, (2) prefix information distributed in IKEv2 1044 messages, (3) unique address allocation with stateless address 1045 autoconfiguration (with VPN gateway trapping NS messages and spoofing 1046 NA replies), and (4) access control enforced (partly) outside IPsec. 1048 1) During IKE_AUTH, the client sends a new configuration attribute, 1049 INTERNAL_IP6_LINK, which requests a virtual link to be created. The 1050 attribute contains the client's interface ID for link-local address 1051 (other addresses may use other interface IDs). 1053 CP(CFG_REQUEST) = 1054 { INTERNAL_IP6_LINK(Link-Local Interface ID) } 1055 TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1056 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1057 TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1058 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 1060 The VPN gateway replies with its own link-local interface ID (which 1061 has to be different from the client's), an IKEv2 Link ID (which will 1062 be used for reauthentication and CREATE_CHILD_SA messages), and zero 1063 or more INTERNAL_IP6_PREFIX attributes. The traffic selectors 1064 proposed by the initiator are also narrowed to contain only the 1065 assigned prefixes (and the link-local prefix). 1067 CP(CFG_REPLY) = 1068 { INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID), 1069 INTERNAL_IP6_PREFIX(Prefix1/64), 1070 [INTERNAL_IP6_PREFIX(Prefix2/64),...], 1071 INTERNAL_IP6_DHCP(Address) ] 1072 TSi = ((0, 0-65535, 1073 FE80:: - 1074 FE80::) 1075 (0, 0-65535, 1076 Prefix1::0 - 1077 Prefix1::FFFF:FFFF:FFFF:FFFF), 1078 [(0, 0-65535, 1079 Prefix2::0 - 1080 Prefix2::FFFF:FFFF:FFFF:FFFF), ...]) 1081 TSr = (0, 0-65535, 1082 0:0:0:0:0:0:0:0 - 1083 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1085 2) The client now configures tentative unicast addresses from the 1086 prefixes given by the gateway, and performs Duplicate Address 1087 Detection (DAD) for them. 1089 The Neighbor Solicitation messages are processed by the VPN gateway: 1090 if the target address is already in use by some other VPN client, the 1091 gateway replies with a Neighbor Advertisement. If the target address 1092 is not already in use, the VPN gateway notes that it is now being 1093 used by this client, and updates its forwarding state accordingly. 1095 Comments: The main disadvantages of this solution are non-standard 1096 processing of NS messages (which are used to update the gateway's 1097 forwarding state), and performing access control partly outside 1098 IPsec. 1100 A.6.3. Router Aggregation Sketch #2 1102 This is basically similar to the version -00 sketch described with 1103 above, but uses router aggregation link model. In other words, it 1104 combines (1) router aggregation link model, (2) prefix information 1105 distributed in Neighbor Advertisements, (3) unique address allocation 1106 with stateless address autoconfiguration (with VPN gateway trapping 1107 NS messages and spoofing NA replies), and (4) access control enforced 1108 outside IPsec. 1110 1) During IKE_AUTH, client sends a new configuration attribute, 1111 INTERNAL_IP6_LINK, which requests a virtual link to be created. The 1112 attribute contains the client's interface ID for link-local address 1113 (other addresses may use other interface IDs). 1115 CP(CFG_REQUEST) = 1116 { INTERNAL_IP6_LINK(Link-Local Interface ID) } 1117 TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1118 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1119 TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1120 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 1122 The VPN gateway replies with its own link-local interface ID (which 1123 has to be different from the client's) and an IKEv2 Link ID (which 1124 will be used for reauthentication). 1126 CP(CFG_REPLY) = 1127 { INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID) } 1128 TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1129 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1130 TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - 1131 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1133 At this point, both peers configure the virtual interface with the 1134 link-local addresses. 1136 2) The next step is IPv6 stateless address autoconfiguration; that 1137 is, Router Solicitation and Router Advertisement messages sent over 1138 the IPsec SA. 1140 ESP(Router Solicitation: 1141 src=::, 1142 dst=FF02:0:0:0:0:0:0:2) --> 1144 <-- ESP(Router Advertisement: 1145 src=FE80:: 1146 dst=FF02:0:0:0:0:0:0:1, 1147 Prefix1, [Prefix2...]) 1149 3) The client now configures tentative unicast addresses from the 1150 prefixes given by the gateway, and performs Duplicate Address 1151 Detection (DAD) for them. 1153 The Neighbor Solicitation messages are processed by the VPN gateway: 1154 if the target address is already in use by some other VPN client, the 1155 gateway replies with a Neighbor Advertisement. If the target address 1156 is not already in use, the VPN gateway notes that it is now being 1157 used by this client, and updates its forwarding state accordingly. 1159 Comments: The main disadvantages of this solution are non-standard 1160 processing of NS messages (which are used to update the gateway's 1161 forwarding state), and performing access control outside IPsec. 1163 A.6.4. IPv4-like Sketch 1165 This sketch resembles the current IPv4 configuration payloads, and it 1166 combines (1) router aggregation link model, (2) prefix information 1167 distributed in IKEv2 messages, (3) unique address allocation with 1168 IKEv2 messages, and (4) access control enforced by IPsec SAD/SPD. 1170 1) During IKE_AUTH, the client sends a new configuration attribute, 1171 INTERNAL_IP6_LINK, which requests a virtual link to be created. The 1172 attribute contains the client's interface ID for link-local address 1173 (other addresses may use other interface IDs). 1175 CP(CFG_REQUEST) = 1176 { INTERNAL_IP6_LINK(Link-Local Interface ID) } 1177 TSi = (0, 0-65535, 1178 0:0:0:0:0:0:0:0 - 1179 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1180 TSr = (0, 0-65535, 1181 0:0:0:0:0:0:0:0 - 1182 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 1184 The VPN gateway replies with its own link-local interface ID (which 1185 has to be different from the client's), an IKEv2 Link ID (which will 1186 be used for reauthentication and CREATE_CHILD_SA messages), and zero 1187 or more INTERNAL_IP6_ADDRESS2 attributes. Each attribute contains 1188 one address from a particular prefix. 1190 CP(CFG_REPLY) = 1191 { INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID), 1192 INTERNAL_IP6_ADDRESS2(Prefix1+Client's Interface ID1), 1193 [INTERNAL_IP6_ADDRESS2(Prefix2+Client's Interface ID2),...], 1194 TSi = ((0, 0-65535, 1195 FE80:: - 1196 FE80::) 1197 (0, 0-65535, 1198 Prefix1:: - 1199 Prefix1::), 1200 [(0, 0-65535, 1201 Prefix2:: - 1202 Prefix2::), ...]) 1203 TSr = (0, 0-65535, 1204 0:0:0:0:0:0:0:0 - 1205 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1207 Since the VPN gateway keeps track of address uniqueness, there is no 1208 need to perform Duplicate Address Detection. 1210 2) If the client wants additional addresses later (for example, with 1211 specific interface ID), it requests them in a separate 1212 CREATE_CHILD_SA exchange. For example: 1214 CP(CFG_REQUEST) = 1215 { INTERNAL_IP6_ADDRESS2(Prefix1+Client's Interface ID3) } 1216 TSi = (0, 0-65535, 1217 Prefix1::0 - 1218 Prefix1::FFFF:FFFF:FFFF:FFFF>), 1219 TSr = (0, 0-65535, 1220 0:0:0:0:0:0:0:0 - 1221 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> 1223 If the requested address is not currently in use by some other 1224 client, the VPN gateway simply returns the same address, and traffic 1225 selectors narrowed appropriately. 1227 CP(CFG_REQUEST) = 1228 { INTERNAL_IP6_ADDRESS2(Prefix1+Client's Interface ID3) } 1229 TSi = ((0, 0-65535, 1230 Prefix1:: - 1231 Prefix1::), 1232 TSr = (0, 0-65535, 1233 0:0:0:0:0:0:0:0 - 1234 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1236 Comments: The main advantage of this solution is that it's quite 1237 close to the current IPv4 way of doing things. By adding explicit 1238 link creation (with Link ID for reauthentication/SPD selection, and 1239 link-local addresses), and slightly changing the semantics (and also 1240 name) of INTERNAL_IP6_ADDRESS attribute (can return more attributes 1241 than was asked), we get much of the needed functionality. 1243 The biggest disadvantages are probably potentially complex 1244 implementation dependency for interface ID selection (see 1245 Section 3.3), and the multi-link subnet model. 1247 A.6.5. Sketch Based on RFC 3456 1249 For completeness: a solution modeled after [RFC3456] would combine 1250 (1) router aggregation link model, (2) prefix information 1251 distribution and unique address allocation with DHCPv6, and (3) 1252 access control enforced by IPsec SAD/SPD. 1254 Authors' Addresses 1256 Pasi Eronen 1257 Nokia Research Center 1258 P.O. Box 407 1259 FIN-00045 Nokia Group 1260 Finland 1262 Email: pasi.eronen@nokia.com 1264 Julien Laganier 1265 DOCOMO Communications Laboratories Europe GmbH 1266 Landsberger Strasse 312 1267 Munich D-80687 1268 Germany 1270 Phone: +49 89 56824 231 1271 Email: julien.laganier.IETF@googlemail.com 1273 Cheryl Madson 1274 Cisco Systems, Inc. 1275 510 MacCarthy Drive 1276 Milpitas, CA 1277 USA 1279 Email: cmadson@cisco.com