< draft-eronen-ipsec-ikev2-ipv6-config-04.txt   draft-eronen-ipsec-ikev2-ipv6-config-05.txt >
Network Working Group P. Eronen Network Working Group P. Eronen
Internet-Draft Nokia Internet-Draft Nokia
Intended status: Standards Track July 4, 2008 Intended status: Standards Track J. Laganier
Expires: January 5, 2009 Expires: May 1, 2009 DOCOMO Euro-Labs
C. Madson
Cisco Systems
October 28, 2008
IPv6 Configuration in IKEv2 IPv6 Configuration in IKEv2
draft-eronen-ipsec-ikev2-ipv6-config-04.txt draft-eronen-ipsec-ikev2-ipv6-config-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 5, 2009. This Internet-Draft will expire on May 1, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
When IKEv2 is used for remote VPN access (client to VPN gateway), the When IKEv2 is used for remote VPN access (client to VPN gateway), the
gateway assigns the client an IP address from the internal network gateway assigns the client an IP address from the internal network
using IKEv2 configuration payloads. The configuration payloads using IKEv2 configuration payloads. The configuration payloads
specified in RFC 4306 work well for IPv4, but make it difficult to specified in RFC 4306 work well for IPv4, but make it difficult to
use certain features of IPv6. This document describes the use certain features of IPv6. This document describes the
limitations of current IKEv2 configuration payloads for IPv6, and limitations of current IKEv2 configuration payloads for IPv6, and
explores possible solutions that would allow IKEv2 to set up full- explores possible solutions that would allow IKEv2 to set up full-
skipping to change at page 3, line 22 skipping to change at page 3, line 22
3.3. Receiving Multicast Traffic . . . . . . . . . . . . . . . 7 3.3. Receiving Multicast Traffic . . . . . . . . . . . . . . . 7
3.4. Interface Identifier Selection . . . . . . . . . . . . . . 7 3.4. Interface Identifier Selection . . . . . . . . . . . . . . 7
3.5. Sharing VPN Access . . . . . . . . . . . . . . . . . . . . 8 3.5. Sharing VPN Access . . . . . . . . . . . . . . . . . . . . 8
3.6. Additional Information . . . . . . . . . . . . . . . . . . 8 3.6. Additional Information . . . . . . . . . . . . . . . . . . 8
4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Main Requirements . . . . . . . . . . . . . . . . . . . . 9 4.1. Main Requirements . . . . . . . . . . . . . . . . . . . . 9
4.2. Desirable Non-Functional Properties . . . . . . . . . . . 10 4.2. Desirable Non-Functional Properties . . . . . . . . . . . 10
4.3. Implementation Considerations . . . . . . . . . . . . . . 10 4.3. Implementation Considerations . . . . . . . . . . . . . . 10
4.4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 10 4.4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Solution Discussion . . . . . . . . . . . . . . . . . . . . . 11 5. Solution Discussion . . . . . . . . . . . . . . . . . . . . . 11
5.1. Link Model . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Link Model . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Distributing Prefix Information . . . . . . . . . . . . . 12 5.2. Distributing Prefix Information . . . . . . . . . . . . . 12
5.3. Unique Address Allocation . . . . . . . . . . . . . . . . 12 5.3. Unique Address Allocation . . . . . . . . . . . . . . . . 13
5.4. Layer 3 Access Control . . . . . . . . . . . . . . . . . . 13 5.4. Layer 3 Access Control . . . . . . . . . . . . . . . . . . 13
5.5. Other Considerations . . . . . . . . . . . . . . . . . . . 13 5.5. Other Considerations . . . . . . . . . . . . . . . . . . . 14
6. Solution Sketch . . . . . . . . . . . . . . . . . . . . . . . 16 6. Solution Sketch . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Initial Exchanges . . . . . . . . . . . . . . . . . . . . 16 6.1. Initial Exchanges . . . . . . . . . . . . . . . . . . . . 16
6.2. Reauthentication . . . . . . . . . . . . . . . . . . . . . 17 6.2. Reauthentication . . . . . . . . . . . . . . . . . . . . . 18
6.3. Creating CHILD_SAs . . . . . . . . . . . . . . . . . . . . 17 6.3. Creating CHILD_SAs . . . . . . . . . . . . . . . . . . . . 18
6.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 18 6.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 18
6.5. Relationship to Neighbor Discovery . . . . . . . . . . . . 18 6.5. Relationship to Neighbor Discovery . . . . . . . . . . . . 19
6.6. Relationship to Existing IKEv2 Payloads . . . . . . . . . 19 6.6. Relationship to Existing IKEv2 Payloads . . . . . . . . . 19
7. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 20 7. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. INTERNAL_IP6_LINK Configuration Attribute . . . . . . . . 20 7.1. INTERNAL_IP6_LINK Configuration Attribute . . . . . . . . 21
7.2. INTERNAL_IP6_PREFIX Configuration Attribute . . . . . . . 20 7.2. INTERNAL_IP6_PREFIX Configuration Attribute . . . . . . . 21
7.3. LINK_ID Notify Payload . . . . . . . . . . . . . . . . . . 21 7.3. LINK_ID Notify Payload . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Alternative Solution Sketches . . . . . . . . . . . . 28 Appendix A. Alternative Solution Sketches . . . . . . . . . . . . 29
A.1. Version -00 Sketch . . . . . . . . . . . . . . . . . . . . 28 A.1. Version -00 Sketch . . . . . . . . . . . . . . . . . . . . 29
A.2. Router Aggregation Sketch #1 . . . . . . . . . . . . . . . 29 A.2. Router Aggregation Sketch #1 . . . . . . . . . . . . . . . 30
A.3. Router Aggregation Sketch #2 . . . . . . . . . . . . . . . 30 A.3. Router Aggregation Sketch #2 . . . . . . . . . . . . . . . 31
A.4. IPv4-like Sketch . . . . . . . . . . . . . . . . . . . . . 32 A.4. IPv4-like Sketch . . . . . . . . . . . . . . . . . . . . . 33
A.5. Sketch Based on RFC 3456 . . . . . . . . . . . . . . . . . 33 A.5. Sketch Based on RFC 3456 . . . . . . . . . . . . . . . . . 34
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 35 Intellectual Property and Copyright Statements . . . . . . . . . . 36
1. Introduction and Problem Statement 1. Introduction and Problem Statement
In typical remote access VPN use (client to VPN gateway), the client In typical remote access VPN use (client to VPN gateway), the client
needs an IP address in the network protected by the security gateway. needs an IP address in the network protected by the security gateway.
IKEv2 includes a feature called "configuration payloads" that allows IKEv2 includes a feature called "configuration payloads" that allows
the gateway to dynamically assign a temporary address to the client the gateway to dynamically assign a temporary address to the client
[IKEv2]. [IKEv2].
For IPv4, the message exchange would look as follows: For IPv4, the message exchange would look as follows:
skipping to change at page 11, line 12 skipping to change at page 11, line 12
[RFC4877], and the intent of this document is not to change that [RFC4877], and the intent of this document is not to change that
interaction in any way. interaction in any way.
5. Solution Discussion 5. Solution Discussion
Assigning a new IPv6 address to the client creates a new "virtual Assigning a new IPv6 address to the client creates a new "virtual
IPv6 interface", and "virtual link" between the client and the IPv6 interface", and "virtual link" between the client and the
gateway. We will assume that the virtual link has the following gateway. We will assume that the virtual link has the following
properties: properties:
o The link and its interfaces are created by IKEv2 messages, and are o The link and its interfaces are created and destroyed by the IKEv2
destroyed once they are no longer used by any IKE SA. process.
o The IPv6 addresses and prefixes are assigned to the link and its
interfaces by IKEv2 messages, and are removed once they are no
longer used by any IKE SA. An IKEv2 implementation may delay
removal of the IPv6 addresses and prefixes for a period of time to
allow upper layer protocol communications (e.g., a TCP connection)
to survive an IKE SA re-authentication that would use the same
addresses and prefixes.
o The link is not an IPsec SA; at any time, there can be zero or o The link is not an IPsec SA; at any time, there can be zero or
more IPsec SAs covering traffic on this link. more IPsec SAs covering traffic on this link.
o The link is not a single IKE SA; to support reauthentication, it o The link is not a single IKE SA; to support reauthentication, it
must be possible to identify the same link in another IKE SA. must be possible to identify the same link in another IKE SA.
o It is TBD whether a single IKE SA needs to support multiple o It is TBD whether a single IKE SA needs to support multiple
virtual links. (Possibly not; if multiple virtual links are virtual links. (Possibly not; if multiple virtual links are
needed, multiple IKE_SAs could be used.) needed, multiple IKE_SAs could be used.)
skipping to change at page 15, line 41 skipping to change at page 15, line 49
something, dst=*), it would typically reject the request (or in something, dst=*), it would typically reject the request (or in
other words, narrow it to an empty set) because it doesn't have other words, narrow it to an empty set) because it doesn't have
SPD/PAD entries that would allow joe.user@example.com to request SPD/PAD entries that would allow joe.user@example.com to request
such CHILD_SAs. such CHILD_SAs.
(However, it might have SPD/PAD entries that would allow (However, it might have SPD/PAD entries that would allow
"neighboring-router.example.com" to create such SAs, for "neighboring-router.example.com" to create such SAs, for
protecting e.g. some routing protocol that uses link-local protecting e.g. some routing protocol that uses link-local
addresses.) addresses.)
However, the virtual interface create when joe.user@example.com However, the virtual interface created when joe.user@example.com
authenticated and sent INTERNAL_IP6_LINK would have a different authenticated and sent INTERNAL_IP6_LINK would have a different
SPD/PAD, which would allow joe.user@example.com to create this SA. SPD/PAD, which would allow joe.user@example.com to create this SA.
6. Solution Sketch 6. Solution Sketch
This solution is basically a combination of (1) point-to-point link This solution is basically a combination of (1) point-to-point link
model, (2) prefix information distributed in IKEv2 messages, and (3) model, (2) prefix information distributed in IKEv2 messages, and (3)
access control enforced by IPsec SAD/SPD. access control enforced by IPsec SAD/SPD.
(Second preliminary version, based on discussions with Tero Kivinen.) (Second preliminary version, based on discussions with Tero Kivinen.)
6.1. Initial Exchanges 6.1. Initial Exchanges
1) During IKE_AUTH, the client sends a new configuration attribute, 1) During IKE_AUTH, the client sends a new configuration attribute,
INTERNAL_IP6_LINK, which requests a virtual link to be created. The INTERNAL_IP6_LINK, which requests a virtual link to be configured.
attribute contains the client's interface ID for link-local address The attribute contains the client's interface ID for link-local
(other addresses may use other interface IDs). Typically, the client address (other addresses may use other interface IDs). Typically,
would also ask for DHCPv6 server address; this is used only for the client would also ask for DHCPv6 server address; this is used
configuration, not address assignment. only for configuration, not address assignment.
To handle backward compatibility between a client that supports the
extended address configuration mechanism hereby specified and a VPN
gateway that does not, this specification RECOMMENDS that the VPN
client includes as well the INTERNAL_IP6_ADDRESS configuration
attribute to allow graceful fallback to the existing address
configuration mechanism specified in the IKEv2 specification [IKEv2],
unless it knows for sure that the VPN gateway supports the extended
mechanism hereby specified (e.g., via configuration.)
CP(CFG_REQUEST) = CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID) { INTERNAL_IP6_LINK(Client's Link-Local Interface ID)
INTERNAL_IP6_ADDRESS()
INTERNAL_IP6_DHCP() } INTERNAL_IP6_DHCP() }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->
The VPN gateway replies with its own link-local interface ID (which To handle backward compatibility between a VPN gateway that supports
MUST be different from the client's), an IKEv2 Link ID (which will be the extended address configuration mechanism hereby specified and a
used for reauthentication and CREATE_CHILD_SA messages), and zero or client that does not, if the client has not sent the
more INTERNAL_IP6_PREFIX attributes. The traffic selectors proposed INTERNAL_IP6_LINK configuration attribute the VPN gateway MUST NOT
by the initiator are also narrowed to contain only the assigned include the INTERNAL_IP6_LINK configuration attribute in its reply
prefixes (and the link-local prefix). and should fallback to the address configuration mechanism specified
in the IKEv2 specification [IKEv2].
If the client has sent the INTERNAL_IP6_LINK configuration attribute,
the VPN gateway SHOULD ignore any INTERNAL_IP6_ADDRESS configuration
attribute present in the request.
The VPN gateway MUST choose for itself a link-local interface
identifier different than the client's one, i.e., accept the link-
local interface identifier proposed by the client. In case the VPN
gateway cannot accept the link-local interface identifier the client
proposed, the VPN gateway MUST fail the IPv6 address assignment by
including a NOTIFY payload with the INTERNAL_ADDRESS_FAILURE message,
i.e., the IKE_SA can be created but no CHILD_SA will be created.
The VPN Gateway then replies with an INTERNAL_IP6_LINK configuration
attribute that contains the IKEv2 Link ID (which will be used for
reauthentication and CREATE_CHILD_SA messages), the client's link
local interface identier, and zero or more INTERNAL_IP6_PREFIX
attributes. The traffic selectors proposed by the initiator are also
narrowed to contain only the assigned prefixes, and the client link-
local address formed from the well-known link-local subnet prefix and
the client link-local interface identifier.
CP(CFG_REPLY) = CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID), { INTERNAL_IP6_LINK(Client's Link-Local Interface ID,
IKEv2 Link ID)
INTERNAL_IP6_PREFIX(Prefix1/64), INTERNAL_IP6_PREFIX(Prefix1/64),
[INTERNAL_IP6_PREFIX(Prefix2/64),...], [INTERNAL_IP6_PREFIX(Prefix2/64),...],
INTERNAL_IP6_DHCP(Address) ] [INTERNAL_IP6_DHCP(Address) ]
TSi = ((0, 0-65535, TSi = ((0, 0-65535,
FE80::<Client's Interface ID> - FE80::<Client's Interface ID> -
FE80::<Client's Interface ID>) FE80::<Client's Interface ID>)
(0, 0-65535, (0, 0-65535,
Prefix1::0 - Prefix1::0 -
Prefix1::FFFF:FFFF:FFFF:FFFF), Prefix1::FFFF:FFFF:FFFF:FFFF),
[(0, 0-65535, [(0, 0-65535,
Prefix2::0 - Prefix2::0 -
Prefix2::FFFF:FFFF:FFFF:FFFF), ...]) Prefix2::FFFF:FFFF:FFFF:FFFF), ...])
TSr = (0, 0-65535, TSr = (0, 0-65535,
0:0:0:0:0:0:0:0 - 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
(To be determined: is it necessary to include the gateway's link- At this point, the client can configure 1) its link-local address
local interface ID? Probably the client does not need it.) from the well-known link-local subnet prefix (FE80::/64) and the
assigned client's link-local interface identifier, and 2) other non-
At this point, the client can configure unicast addresses from the link-local unicast addresses from the assigned prefixes and any
assigned prefixes, using any interface ID. The VPN gateway MUST NOT proper interface identifier [IPv6Addr]. The VPN gateway MUST NOT
simultaneously assign the same prefixes to any other client, and MUST simultaneously assign the same prefixes to any other client, and MUST
NOT itself configure addresses from these prefixes. Thus, the client NOT itself configure addresses from these prefixes. Thus, the client
does not have to perform Duplicate Address Detection (DAD). (This does not have to perform Duplicate Address Detection (DAD). (This
approach is based on [IPv6PPP].) approach is based on [IPv6PPP].)
The prefixes remain valid through the lifetime of the IKE SA (and its The prefixes remain valid through the lifetime of the IKE SA (and its
continuations via rekeying). If the VPN gateway needs to remove a continuations via rekeying). If the VPN gateway needs to remove a
prefix it has previously assigned, or assign a new prefix, it can do prefix it has previously assigned, or assign a new prefix, it can do
so by triggering reauthentication. so by triggering reauthentication.
skipping to change at page 17, line 33 skipping to change at page 18, line 18
as the DNS server), as it allows easier extensibility and more as the DNS server), as it allows easier extensibility and more
options (such as the domain search list for DNS). options (such as the domain search list for DNS).
6.2. Reauthentication 6.2. Reauthentication
When the client performs reauthentication (and wants to continue When the client performs reauthentication (and wants to continue
using the same "virtual link"), it includes the IKEv2 Link ID given using the same "virtual link"), it includes the IKEv2 Link ID given
by the gateway in the INTERNAL_IP6_LINK attribute. by the gateway in the INTERNAL_IP6_LINK attribute.
CP(CFG_REQUEST) = CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID) { INTERNAL_IP6_LINK(Client's Link Local Interface ID,
IKEv2 Link ID)
INTERNAL_IP6_DHCP() } INTERNAL_IP6_DHCP() }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->
The gateway uses the Link ID to look up relevant local state, The gateway uses the Link ID to look up relevant local state,
verifies that the authenticated peer identity associated with the verifies that the authenticated peer identity associated with the
link is correct, and continues the handshake as usual. link is correct, and continues the handshake as usual.
skipping to change at page 18, line 49 skipping to change at page 19, line 39
Address Resolution, Next-hop Determination, and Redirect are not Address Resolution, Next-hop Determination, and Redirect are not
used, as the virtual link does not have link-local addresses, and is used, as the virtual link does not have link-local addresses, and is
a point-to-point link. a point-to-point link.
Neighbor Unreachability Detection could be used, but is a bit Neighbor Unreachability Detection could be used, but is a bit
redundant given IKEv2 Dead Peer Detection. redundant given IKEv2 Dead Peer Detection.
Duplicate Address Detection is not needed, because this is a point- Duplicate Address Detection is not needed, because this is a point-
to-point link, where the VPN gateway does not assign any addresses to-point link, where the VPN gateway does not assign any addresses
from the global unicast prefixes, and link-local interface ID is from the global unicast prefixes, and link-local interface identifier
negotiated separately. is negotiated separately.
6.6. Relationship to Existing IKEv2 Payloads 6.6. Relationship to Existing IKEv2 Payloads
The mechanism described in this document is not intended to be used The mechanism described in this document is not intended to be used
at the same time as the existing INTERNAL_IP6_ADDRESS attribute. For at the same time as the existing INTERNAL_IP6_ADDRESS attribute. For
compatibility with gateways implementing only INTERNAL_IP6_ADDRESS, compatibility with gateways implementing only INTERNAL_IP6_ADDRESS,
the VPN client MAY include attributes for both mechanisms in the VPN client MAY include attributes for both mechanisms in
CFG_REQUEST. The capabilities and preferences of the VPN gateway CFG_REQUEST. The capabilities and preferences of the VPN gateway
will then determine which is used. will then determine which is used.
skipping to change at page 20, line 17 skipping to change at page 21, line 17
7.1. INTERNAL_IP6_LINK Configuration Attribute 7.1. INTERNAL_IP6_LINK Configuration Attribute
The INTERNAL_IP6_LINK configuration attribute is formatted as The INTERNAL_IP6_LINK configuration attribute is formatted as
follows: follows:
1 2 3 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 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 | !R| Attribute Type ! Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-Local | | Client's Link-Local |
| Interface ID | | Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ IKEv2 Link ID ~ ~ IKEv2 Link ID ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Reserved (1 bit) - See [IKEv2]. o Reserved (1 bit) - See [IKEv2].
o Attribute Type (15 bits) - INTERNAL_IP6_LINK (TBD1). o Attribute Type (15 bits) - INTERNAL_IP6_LINK (TBD1).
o Length (2 octets) - Length in octets of the Value field (Link- o Length (2 octets) - Length in octets of the Value field (Client's
Local Interface ID and IKEv2 Link ID); 8 or more. Link-Local Interface ID and IKEv2 Link ID); 8 or more.
o Link-Local Interface ID (8 octets) - The Interface ID used for o Link-Local Interface ID (8 octets) - The Interface ID used for
link-local address (by the party that sent this attribute). link-local address (by the party that sent this attribute).
o IKEv2 Link ID (variable length) - The link ID (may be empty when o IKEv2 Link ID (variable length) - The link ID (may be empty when
the client does not yet know the link ID). the client does not yet know the link ID).
7.2. INTERNAL_IP6_PREFIX Configuration Attribute 7.2. INTERNAL_IP6_PREFIX Configuration Attribute
The INTERNAL_IP6_PREFIX configuration attribute is formatted as The INTERNAL_IP6_PREFIX configuration attribute is formatted as
skipping to change at page 21, line 26 skipping to change at page 22, line 26
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
o Reserved (1 bit) - See [IKEv2]. o Reserved (1 bit) - See [IKEv2].
o Attribute Type (15 bits) - INTERNAL_IP6_PREFIX (TBD2). o Attribute Type (15 bits) - INTERNAL_IP6_PREFIX (TBD2).
o Length (2 octets) - Length in octets of the Value field; in this o Length (2 octets) - Length in octets of the Value field; in this
case, 17. case, 17.
o Prefix (16 octets) - An IPv6 prefix assigned to the virtual link. o Prefix (16 octets) - An IPv6 prefix assigned to the virtual link.
The low order bits of the prefix field which are not part of the
prefix MUST be set to zero by the sender and MUST be ignored by
the receiver.
o Prefix Length (1 octets) - The length of the prefix in bits; o Prefix Length (1 octets) - The length of the prefix in bits;
(almost) always 64. usually 64.
7.3. LINK_ID Notify Payload 7.3. LINK_ID Notify Payload
The LINK_ID notification is included in CREATE_CHILD_SA requests to The LINK_ID notification is included in CREATE_CHILD_SA requests to
indicate that the SA being created is related to the virtual link. indicate that the SA being created is related to the virtual link.
If this notification is not included, the CREATE_CHILD_SA requests is If this notification is not included, the CREATE_CHILD_SA requests is
related to the physical interface. related to the physical interface.
The Notify Message Type for LINK_ID is TBD3. The Protocol ID and SPI The Notify Message Type for LINK_ID is TBD3. The Protocol ID and SPI
Size fields are set to zero. The data associated with this Size fields are set to zero. The data associated with this
notification is the IKEv2 Link ID returned in the INTERNAL_IP6_LINK notification is the IKEv2 Link ID returned in the
configuration attribute. INTERNAL_IP6_LINK_ID configuration attribute.
8. IANA Considerations 8. IANA Considerations
This document defines two new IKEv2 configuration attributes, whose This document defines two new IKEv2 configuration attributes, whose
values are to be allocated (have been allocated) from the "IKEv2 values are to be allocated (have been allocated) from the "IKEv2
Configuration Payload Attribute Types" namespace [IKEv2]: Configuration Payload Attribute Types" namespace [IKEv2]:
Multi- Multi-
Value Attribute Type Valued Length Reference Value Attribute Type Valued Length Reference
------ ---------------------- ------ ------------- --------- ------ ---------------------- ------ ------------- ---------
TBD1 INTERNAL_IP6_LINK NO 8 or more [this doc] TBD1 INTERNAL_IP6_LINK NO 8 or more [this doc]
TBD2 INTERNAL_IP6_PREFIX YES 17 octets [this doc] TBD2 INTERNAL_IP6_PREFIX YES 17 octets [this doc]
This document also defines one new IKEv2 notification, whose value is This document also defines one new IKEv2 notification, whose value is
to be allocated (has been allocated) from the "IKEv2 Notify Message to be allocated (has been allocated) from the "IKEv2 Notify Message
Types" namespace [IKEv2]: Types - Status Types" namespace [IKEv2]:
Value Notify Messages - Status Types Reference Value Notify Messages - Status Types Reference
------ ------------------------------- --------- ------ ------------------------------- ---------
TBD3 LINK_ID [this doc] TBD3 LINK_ID [this doc]
This document does not create any new namespaces to be maintained by This document does not create any new namespaces to be maintained by
IANA. IANA.
9. Security Considerations 9. Security Considerations
To be written. (The security consideration should be pretty much the To be written. (The security consideration should be pretty much the
same as for current configuration payloads.) same as for current configuration payloads.)
Assigning each client a unique prefix makes using randomized Assigning each client a unique prefix makes using randomized
interface identifiers [RFC4941] ineffective from privacy point of interface identifiers [RFC4941] ineffective from privacy point of
view: the client is still uniquely identified by the prefix. In some view: the client is still uniquely identified by the prefix. In some
environments, it may be preferable to assign a VPN client the same environments, it may be preferable to assign a VPN client the same
prefixes each time a VPN connection is established; other prefixes each time a VPN connection is established; other
environments may prefer assigning a different prefix every for environments may prefer assigning a different prefix every time for
privacy reasons. (This is basically a similar trade-off as in Mobile privacy reasons. (This is basically a similar trade-off as in Mobile
IPv6 -- using the same Home Address forever is simpler than changing IPv6 -- using the same Home Address forever is simpler than changing
it often, but has privacy implications.) it often, but has privacy implications.)
10. Acknowledgments 10. Acknowledgments
The author would like to thank Patrick Irwin, Tero Kivinen, Julien The author would like to thank Patrick Irwin, Tero Kivinen, Julien
Laganier, Chinh Nguyen, Mohan Parthasarathy, Yaron Sheffer, Hemant Laganier, Chinh Nguyen, Mohan Parthasarathy, Yaron Sheffer, Hemant
Singh, Dave Thaler, Yinghzhe Wu, and Fan Zhao for their valuable Singh, Dave Thaler, Yinghzhe Wu, and Fan Zhao for their valuable
comments. comments.
skipping to change at page 28, line 15 skipping to change at page 29, line 15
Appendix A. Alternative Solution Sketches Appendix A. Alternative Solution Sketches
A.1. Version -00 Sketch A.1. Version -00 Sketch
The -00 version of this draft contained the following solution The -00 version of this draft contained the following solution
sketch, which is basically a combination of (1) point-to-point link sketch, which is basically a combination of (1) point-to-point link
model, (2) prefix information distributed in Neighbor Advertisements, model, (2) prefix information distributed in Neighbor Advertisements,
and (3) access control enforced outside IPsec. and (3) access control enforced outside IPsec.
1) During IKE_AUTH, client sends a new configuration attribute, 1) During IKE_AUTH, client sends a new configuration attribute,
INTERNAL_IP6_LINK, which requests a virtual link to be created. The INTERNAL_IP6_LINK_ID, which requests a virtual link to be created.
attribute contains the client's interface ID for link-local address The attribute contains the client's interface ID for link-local
(other addresses may use other interface IDs). address (other addresses may use other interface IDs).
CP(CFG_REQUEST) = CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID) } { INTERNAL_IP6_LINK_ID(Link-Local Interface ID) }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->
The VPN gateway replies with its own link-local interface ID (which The VPN gateway replies with its own link-local interface ID (which
MUST be different from the client's) and an IKEv2 Link ID (which will MUST be different from the client's) and an IKEv2 Link ID (which will
be used for reauthentication). be used for reauthentication).
CP(CFG_REPLY) = CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID) } { INTERNAL_IP6_LINK_ID(Link-Local Interface ID, IKEv2 Link ID) }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
At this point, both peers configure the virtual interface with the At this point, both peers configure the virtual interface with the
link-local addresses. link-local addresses.
2) The next step is IPv6 stateless address autoconfiguration; that 2) The next step is IPv6 stateless address autoconfiguration; that
is, Router Solicitation and Router Advertisement messages sent over is, Router Solicitation and Router Advertisement messages sent over
the IPsec SA. the IPsec SA.
ESP(Router Solicitation: ESP(Router Solicitation:
src=: src=:
skipping to change at page 29, line 13 skipping to change at page 30, line 13
Prefix1, [Prefix2...]) Prefix1, [Prefix2...])
After receiving the Router Advertisement, the client can configure After receiving the Router Advertisement, the client can configure
unicast addresses from the advertised prefixes, using any interface unicast addresses from the advertised prefixes, using any interface
ID. The VPN gateway MUST NOT simultaneously assign the same prefixes ID. The VPN gateway MUST NOT simultaneously assign the same prefixes
to any other client, and MUST NOT itself configure addresses from to any other client, and MUST NOT itself configure addresses from
these prefixes. Thus, the client does not have to perform Duplicate these prefixes. Thus, the client does not have to perform Duplicate
Address Detection (DAD). Address Detection (DAD).
3) Reauthentication works basically the same way as in Section 6.2; 3) Reauthentication works basically the same way as in Section 6.2;
the client includes the IKEv2 Link ID in the INTERNAL_IP6_LINK the client includes the IKEv2 Link ID in the INTERNAL_IP6_LINK_ID
attribute. attribute.
4) Creating and rekeying IPsec SAs works basically the same way as in 4) Creating and rekeying IPsec SAs works basically the same way as in
Section 6.3; the client includes the IKEv2 Link ID in those CHILD_SA Section 6.3; the client includes the IKEv2 Link ID in those CHILD_SA
requests that are related to the virtual link. requests that are related to the virtual link.
Comments: This was changed in -01 draft based on feedback from VPN Comments: This was changed in -01 draft based on feedback from VPN
vendors: while the solution looks nice on paper, it is claimed to be vendors: while the solution looks nice on paper, it is claimed to be
unneccessarily complex to implement when the IKE implementation and unneccessarily complex to implement when the IKE implementation and
IPv6 stack are from different companies. Furthermore, enforcing IPv6 stack are from different companies. Furthermore, enforcing
skipping to change at page 29, line 37 skipping to change at page 30, line 37
A.2. Router Aggregation Sketch #1 A.2. Router Aggregation Sketch #1
The following solution was sketched during the IETF 70 meeting in The following solution was sketched during the IETF 70 meeting in
Vancouver together with Hemant Singh. It combines the (1) router Vancouver together with Hemant Singh. It combines the (1) router
aggregation link model, (2) prefix information distributed in IKEv2 aggregation link model, (2) prefix information distributed in IKEv2
messages, (3) unique address allocation with stateless address messages, (3) unique address allocation with stateless address
autoconfiguration (with VPN gateway trapping NS messages and spoofing autoconfiguration (with VPN gateway trapping NS messages and spoofing
NA replies), and (4) access control enforced (partly) outside IPsec. NA replies), and (4) access control enforced (partly) outside IPsec.
1) During IKE_AUTH, the client sends a new configuration attribute, 1) During IKE_AUTH, the client sends a new configuration attribute,
INTERNAL_IP6_LINK, which requests a virtual link to be created. The INTERNAL_IP6_LINK_ID, which requests a virtual link to be created.
attribute contains the client's interface ID for link-local address The attribute contains the client's interface ID for link-local
(other addresses may use other interface IDs). address (other addresses may use other interface IDs).
CP(CFG_REQUEST) = CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID) } { INTERNAL_IP6_LINK_ID(Link-Local Interface ID) }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->
The VPN gateway replies with its own link-local interface ID (which The VPN gateway replies with its own link-local interface ID (which
MUST be different from the client's), an IKEv2 Link ID (which will be MUST be different from the client's), an IKEv2 Link ID (which will be
used for reauthentication and CREATE_CHILD_SA messages), and zero or used for reauthentication and CREATE_CHILD_SA messages), and zero or
more INTERNAL_IP6_PREFIX attributes. The traffic selectors proposed more INTERNAL_IP6_PREFIX attributes. The traffic selectors proposed
by the initiator are also narrowed to contain only the assigned by the initiator are also narrowed to contain only the assigned
prefixes (and the link-local prefix). prefixes (and the link-local prefix).
CP(CFG_REPLY) = CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID), { INTERNAL_IP6_LINK_ID(Link-Local Interface ID, IKEv2 Link ID),
INTERNAL_IP6_PREFIX(Prefix1/64), INTERNAL_IP6_PREFIX(Prefix1/64),
[INTERNAL_IP6_PREFIX(Prefix2/64),...], [INTERNAL_IP6_PREFIX(Prefix2/64),...],
INTERNAL_IP6_DHCP(Address) ] INTERNAL_IP6_DHCP(Address) ]
TSi = ((0, 0-65535, TSi = ((0, 0-65535,
FE80::<Client's Interface ID> - FE80::<Client's Interface ID> -
FE80::<Client's Interface ID>) FE80::<Client's Interface ID>)
(0, 0-65535, (0, 0-65535,
Prefix1::0 - Prefix1::0 -
Prefix1::FFFF:FFFF:FFFF:FFFF), Prefix1::FFFF:FFFF:FFFF:FFFF),
[(0, 0-65535, [(0, 0-65535,
skipping to change at page 30, line 50 skipping to change at page 31, line 50
This is basically similar to the version -00 sketch described with This is basically similar to the version -00 sketch described with
above, but uses router aggregation link model. In other words, it above, but uses router aggregation link model. In other words, it
combines (1) router aggregation link model, (2) prefix information combines (1) router aggregation link model, (2) prefix information
distributed in Neighbor Advertisements, (3) unique address allocation distributed in Neighbor Advertisements, (3) unique address allocation
with stateless address autoconfiguration (with VPN gateway trapping with stateless address autoconfiguration (with VPN gateway trapping
NS messages and spoofing NA replies), and (4) access control enforced NS messages and spoofing NA replies), and (4) access control enforced
outside IPsec. outside IPsec.
1) During IKE_AUTH, client sends a new configuration attribute, 1) During IKE_AUTH, client sends a new configuration attribute,
INTERNAL_IP6_LINK, which requests a virtual link to be created. The INTERNAL_IP6_LINK_ID, which requests a virtual link to be created.
attribute contains the client's interface ID for link-local address The attribute contains the client's interface ID for link-local
(other addresses may use other interface IDs). address (other addresses may use other interface IDs).
CP(CFG_REQUEST) = CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID) } { INTERNAL_IP6_LINK_ID(Link-Local Interface ID) }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->
The VPN gateway replies with its own link-local interface ID (which The VPN gateway replies with its own link-local interface ID (which
MUST be different from the client's) and an IKEv2 Link ID (which will MUST be different from the client's) and an IKEv2 Link ID (which will
be used for reauthentication). be used for reauthentication).
CP(CFG_REPLY) = CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID) } { INTERNAL_IP6_LINK_ID(Link-Local Interface ID, IKEv2 Link ID) }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
At this point, both peers configure the virtual interface with the At this point, both peers configure the virtual interface with the
link-local addresses. link-local addresses.
2) The next step is IPv6 stateless address autoconfiguration; that 2) The next step is IPv6 stateless address autoconfiguration; that
is, Router Solicitation and Router Advertisement messages sent over is, Router Solicitation and Router Advertisement messages sent over
the IPsec SA. the IPsec SA.
ESP(Router Solicitation: ESP(Router Solicitation:
src=: src=:
skipping to change at page 32, line 14 skipping to change at page 33, line 14
forwarding state), and performing access control outside IPsec. forwarding state), and performing access control outside IPsec.
A.4. IPv4-like Sketch A.4. IPv4-like Sketch
This sketch resembles the current IPv4 configuration payloads, and it This sketch resembles the current IPv4 configuration payloads, and it
combines (1) router aggregation link model, (2) prefix information combines (1) router aggregation link model, (2) prefix information
distributed in IKEv2 messages, (3) unique address allocation with distributed in IKEv2 messages, (3) unique address allocation with
IKEv2 messages, and (4) access control enforced by IPsec SAD/SPD. IKEv2 messages, and (4) access control enforced by IPsec SAD/SPD.
1) During IKE_AUTH, the client sends a new configuration attribute, 1) During IKE_AUTH, the client sends a new configuration attribute,
INTERNAL_IP6_LINK, which requests a virtual link to be created. The INTERNAL_IP6_LINK_ID, which requests a virtual link to be created.
attribute contains the client's interface ID for link-local address The attribute contains the client's interface ID for link-local
(other addresses may use other interface IDs). address (other addresses may use other interface IDs).
CP(CFG_REQUEST) = CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID) } { INTERNAL_IP6_LINK_ID(Link-Local Interface ID) }
TSi = (0, 0-65535, TSi = (0, 0-65535,
0:0:0:0:0:0:0:0 - 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, TSr = (0, 0-65535,
0:0:0:0:0:0:0:0 - 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->
The VPN gateway replies with its own link-local interface ID (which The VPN gateway replies with its own link-local interface ID (which
MUST be different from the client's), an IKEv2 Link ID (which will be MUST be different from the client's), an IKEv2 Link ID (which will be
used for reauthentication and CREATE_CHILD_SA messages), and zero or used for reauthentication and CREATE_CHILD_SA messages), and zero or
more INTERNAL_IP6_ADDRESS2 attributes. Each attribute contains one more INTERNAL_IP6_ADDRESS2 attributes. Each attribute contains one
address from a particular prefix. address from a particular prefix.
CP(CFG_REPLY) = CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID), { INTERNAL_IP6_LINK_ID(Link-Local Interface ID, IKEv2 Link ID),
INTERNAL_IP6_ADDRESS2(Prefix1+Client's Interface ID1), INTERNAL_IP6_ADDRESS2(Prefix1+Client's Interface ID1),
[INTERNAL_IP6_ADDRESS2(Prefix2+Client's Interface ID2),...], [INTERNAL_IP6_ADDRESS2(Prefix2+Client's Interface ID2),...],
TSi = ((0, 0-65535, TSi = ((0, 0-65535,
FE80::<Client's Link-Local Interface ID> - FE80::<Client's Link-Local Interface ID> -
FE80::<Client's Link-Local Interface ID>) FE80::<Client's Link-Local Interface ID>)
(0, 0-65535, (0, 0-65535,
Prefix1::<Client's Interface ID1> - Prefix1::<Client's Interface ID1> -
Prefix1::<Client's Interface ID1>), Prefix1::<Client's Interface ID1>),
[(0, 0-65535, [(0, 0-65535,
Prefix2::<Client's Interface ID2> - Prefix2::<Client's Interface ID2> -
skipping to change at page 34, line 5 skipping to change at page 35, line 5
implementation dependency for interface ID selection (see implementation dependency for interface ID selection (see
Section 3.4), and the multi-link subnet model. Section 3.4), and the multi-link subnet model.
A.5. Sketch Based on RFC 3456 A.5. Sketch Based on RFC 3456
For completeness: a solution modeled after [RFC3456] would combine For completeness: a solution modeled after [RFC3456] would combine
(1) router aggregation link model, (2) prefix information (1) router aggregation link model, (2) prefix information
distribution and unique address allocation with DHCPv6, and (3) distribution and unique address allocation with DHCPv6, and (3)
access control enforced by IPsec SAD/SPD. access control enforced by IPsec SAD/SPD.
Author's Address Authors' Addresses
Pasi Eronen Pasi Eronen
Nokia Research Center Nokia Research Center
P.O. Box 407 P.O. Box 407
FIN-00045 Nokia Group FIN-00045 Nokia Group
Finland Finland
Email: pasi.eronen@nokia.com Email: pasi.eronen@nokia.com
Julien Laganier
DOCOMO Communications Laboratories Europe GmbH
Landsberger Strasse 312
Munich D-80687
Germany
Phone: +49 89 56824 231
Email: julien.laganier.IETF@googlemail.com
Cheryl Madson
Cisco Systems, Inc.
510 MacCarthy Drive
Milpitas, CA
USA
Email: cmadson@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
skipping to change at line 1325 skipping to change at page 36, line 44
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 42 change blocks. 
93 lines changed or deleted 162 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/