< draft-tschofenig-v6ops-secure-tunnels-02.txt		draft-tschofenig-v6ops-secure-tunnels-03.txt >
	IPv6 Operations WG R. Graveman		IPv6 Operations WG R. Graveman
	Internet-Draft RFG Security, LLC		Internet-Draft RFG Security, LLC
	Expires: April 24, 2005 M. Parthasarathy		Expires: June 16, 2005 M. Parthasarathy
	Nokia		Nokia
	P. Savola		P. Savola
	CSC/FUNET		CSC/FUNET
	H. Tschofenig		H. Tschofenig
	Siemens		Siemens
	October 24, 2004		December 16, 2004
	Using IPsec to Secure IPv6-over-IPv4 Tunnels		Using IPsec to Secure IPv6-over-IPv4 Tunnels
	draft-tschofenig-v6ops-secure-tunnels-02.txt		draft-tschofenig-v6ops-secure-tunnels-03.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		This document is an Internet-Draft and is subject to all provisions
	of section 3 of RFC 3667. By submitting this Internet-Draft, each		of section 3 of RFC 3667. By submitting this Internet-Draft, each
	author represents that any applicable patent or other IPR claims of		author represents that any 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 is aware have been or will be disclosed, and any of
	which he or she become aware will be disclosed, in accordance with		which he or she become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 April 24, 2005.		This Internet-Draft will expire on June 16, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004).		Copyright (C) The Internet Society (2004).
	Abstract		Abstract
	This document gives guidance on securing IPv6-in-IPv4 tunnels using		This document gives guidance on securing IPv6-in-IPv4 tunnels using
	IPsec. No additional protocol extensions are described beyond those		IPsec. No additional protocol extensions are described beyond those
	available with the revised IPsec framework. IKEv2 is extensively		available with the IPsec framework. This document describes packet
	used as an authentication and key exchange protocol to cover address		formats, IPsec security policy database for various scenarios,
	configuration procedures, and the usage of the Extensible		address configuration procedures, and the usage of the Extensible
	Authentication Procotol and NAT traversal capabilities is also		Authentication Procotol.
	described.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Threats and the Use of IPsec . . . . . . . . . . . . . . . . . 3		2. Threats and the Use of IPsec . . . . . . . . . . . . . . . . . 3
	2.1 IPsec in Transport Mode . . . . . . . . . . . . . . . . . 4		2.1 IPsec in Transport Mode . . . . . . . . . . . . . . . . . 4
	2.2 IPsec in Tunnel Mode . . . . . . . . . . . . . . . . . . . 4		2.2 IPsec in Tunnel Mode . . . . . . . . . . . . . . . . . . . 4
	3. Scenarios and Overview . . . . . . . . . . . . . . . . . . . . 5		3. Scenarios and Overview . . . . . . . . . . . . . . . . . . . . 5
	3.1 Router-to-Router Tunnels . . . . . . . . . . . . . . . . . 5		3.1 Router-to-Router Tunnels . . . . . . . . . . . . . . . . . 5
	3.2 Site-to-Router/Router-to-Site Tunnels . . . . . . . . . . 5		3.2 Site-to-Router/Router-to-Site Tunnels . . . . . . . . . . 5
	3.3 Host-to-Host Tunnels . . . . . . . . . . . . . . . . . . . 7		3.3 Host-to-Host Tunnels . . . . . . . . . . . . . . . . . . . 7
	4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 7		4. IKE and IPsec Versions . . . . . . . . . . . . . . . . . . . . 7
	5. IPsec Configuration Details . . . . . . . . . . . . . . . . . 9		5. IPsec Configuration Details . . . . . . . . . . . . . . . . . 8
	5.1 IPsec Transport mode . . . . . . . . . . . . . . . . . . . 9		5.1 IPsec Transport mode . . . . . . . . . . . . . . . . . . . 8
	5.2 IPsec Tunnel mode . . . . . . . . . . . . . . . . . . . . 9		5.2 IPsec Tunnel mode . . . . . . . . . . . . . . . . . . . . 9
	5.2.1 SPD for Host-to-Host Scenario . . . . . . . . . . . . 9		5.2.1 SPD for Host-to-Host Scenario . . . . . . . . . . . . 9
	5.2.2 SPD for Host-to-Router scenario . . . . . . . . . . . 10		5.2.2 SPD for Host-to-Router scenario . . . . . . . . . . . 11
	6. Dynamic Address Configuration . . . . . . . . . . . . . . . . 12		6. Dynamic Address Configuration . . . . . . . . . . . . . . . . 14
	7. Extensible Authentication Support . . . . . . . . . . . . . . 13		7. Extensible Authentication Support . . . . . . . . . . . . . . 14
	8. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 15		8. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 15
	9. Tunnel Endpoint Discovery . . . . . . . . . . . . . . . . . . 16		9. Tunnel Endpoint Discovery . . . . . . . . . . . . . . . . . . 16
	10. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 17		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
	11. Security Considerations . . . . . . . . . . . . . . . . . . 17		11. Security Considerations . . . . . . . . . . . . . . . . . . 16
	12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 18		12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 17
	13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20		13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
	14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 20		14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 18
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 20		15. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	15.1 Normative References . . . . . . . . . . . . . . . . . . . . 20		15.1 Normative References . . . . . . . . . . . . . . . . . . . . 18
	15.2 Informative References . . . . . . . . . . . . . . . . . . . 21		15.2 Informative References . . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
	Intellectual Property and Copyright Statements . . . . . . . . 24		Intellectual Property and Copyright Statements . . . . . . . . 22
	1. Introduction		1. Introduction
	The IPv6 operations (v6ops) working group has selected IPv6-in-IPv4		The IPv6 operations (v6ops) working group has selected IPv6-in-IPv4
	tunneling [I-D.ietf-v6ops-mech-v2] as one of the IPv6 transition		tunneling [I-D.ietf-v6ops-mech-v2] as one of the IPv6 transition
	mechanisms for IPv6 deployment. A number of threats have been		mechanisms for IPv6 deployment. A number of threats have been
	identified with possible solutions to mitigate them		identified with possible solutions to mitigate them
	[I-D.ietf-v6ops-mech-v2]. One of the solutions is the use of IPsec		[I-D.ietf-v6ops-mech-v2]. One of the solutions is the use of IPsec
	protected tunnels, but there is little detail on how IPsec would		protected tunnels, but there is little detail on how IPsec would
	actually be used in an interoperable manner. This memo describes the		actually be used in an interoperable manner. This memo describes the
	skipping to change at page 3, line 30 ¶		skipping to change at page 3, line 30 ¶
	entries. Finally, it discusses the usage of IPsec NAT-traversal		entries. Finally, it discusses the usage of IPsec NAT-traversal
	mechanism that can be used with configured tunnels in some scenarios.		mechanism that can be used with configured tunnels in some scenarios.
	2. Threats and the Use of IPsec		2. Threats and the Use of IPsec
	Following threats have been identified in [I-D.ietf-v6ops-mech-v2]:		Following threats have been identified in [I-D.ietf-v6ops-mech-v2]:
	1. IPv4 address of the encapsulating ("outer") packet can be		1. IPv4 address of the encapsulating ("outer") packet can be
	spoofed.		spoofed.
	2. IPv6 address of the encapsualted ("inner") packet can be spoofed.		2. IPv6 address of the encapsulated ("inner") packet can be spoofed.
	The reason for threat (1) is due to the lack of widespread deployment		The reason for threat (1) is due to the lack of widespread deployment
	of IPv4 ingress filtering in the network. The reason for threat (2)		of IPv4 ingress filtering. The reason for threat (2) is that the
	is that the IPv6 packet is encapsulated in IPv4 and hence escapes		IPv6 packet is encapsulated in IPv4 and hence escapes IPv6 ingress
	IPv6 ingress filtering. [I-D.ietf-v6ops-mech-v2] specifies following		filtering. [I-D.ietf-v6ops-mech-v2] specifies following strict
	strict address checks as mitigating measures.		address checks as mitigating measures.
	To mitigate threat (1), the decapsulator verifies that the IPv4		To mitigate threat (1), the decapsulator verifies that the IPv4
	source address of the packet is the same as the address of the		source address of the packet is the same as the address of the
	configured tunnel endpoint. The decapsulator may also implement IPv4		configured tunnel endpoint. The decapsulator may also implement IPv4
	ingress filtering, i.e., checks whether the packet is received on a		ingress filtering, i.e., checks whether the packet is received on a
	legitimate interface.		legitimate interface.
	To mitigate threat (2), the decapsulator verifies whether the inner		To mitigate threat (2), the decapsulator verifies whether the inner
	IPv6 address is a valid IPv6 address and also applies IPv6 ingress		IPv6 address is a valid IPv6 address and also applies IPv6 ingress
	filtering before accepting the IPv6 packet.		filtering before accepting the IPv6 packet.
	skipping to change at page 4, line 51 ¶		skipping to change at page 5, line 5 ¶
	The IPv4 addresses may be spoofed and IPsec cannot detect it in this		The IPv4 addresses may be spoofed and IPsec cannot detect it in this
	mode, that is, two nodes that are using IPsec tunnel mode to secure		mode, that is, two nodes that are using IPsec tunnel mode to secure
	the tunnel with a common tunnel endpoint can spoof each other's IPv4		the tunnel with a common tunnel endpoint can spoof each other's IPv4
	address. But, the packet will not be accepted by IPsec as the IPv6		address. But, the packet will not be accepted by IPsec as the IPv6
	address bound to the SA will not match the address in the spoofed		address bound to the SA will not match the address in the spoofed
	packet. Thus, the outer address spoofing is irrelevant as long as		packet. Thus, the outer address spoofing is irrelevant as long as
	the inner IPv6 packet can be verified to come from the right IPv6		the inner IPv6 packet can be verified to come from the right IPv6
	endpoint.		endpoint.
	It may not be possible to always verify the IPv6 address -- for
	example with link-local addresses. The additional issues with
	address verification are discussed in each of the scenarios section
	appropriately.
	3. Scenarios and Overview		3. Scenarios and Overview
	There are roughly three kinds of scenarios: (generic)		There are roughly three kinds of scenarios: (generic)
	router-to-router tunnels, site-to-router/router-to-site tunnels (a		router-to-router tunnels, site-to-router/router-to-site tunnels (a
	generalization of host-to-router/router-to-host scenarios,		generalization of host-to-router/router-to-host scenarios,
	respectively), and host-to-host tunnels.		respectively), and host-to-host tunnels.
	3.1 Router-to-Router Tunnels		3.1 Router-to-Router Tunnels
	IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of		IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of
	skipping to change at page 5, line 28 ¶		skipping to change at page 5, line 26 ¶
	Tunneling can be used in a variety of ways.		Tunneling can be used in a variety of ways.
	.--------. _----_ .--------.		.--------. _----_ .--------.
	|v6-in-v4| _( IPv4 )_ |v6-in-v4|		|v6-in-v4| _( IPv4 )_ |v6-in-v4|
	| Router | <======( Internet )=====> | Router |		| Router | <======( Internet )=====> | Router |
	| A | (_ _) | B |		| A | (_ _) | B |
	'--------' '----' '--------'		'--------' '----' '--------'
	^ IPsec tunnel between ^		^ IPsec tunnel between ^
	| Router A and Router B |		| Router A and Router B |
	V V		V V
	.--------. .-------.
	| End | | End |
	| Host | | Host |
	'--------' '--------'
	Figure 1: Router-to-Router Scenario		Figure 1: Router-to-Router Scenario
	IPv6/IPv4 routers interconnected by an IPv4 infrastructure can tunnel		IPv6/IPv4 routers interconnected by an IPv4 infrastructure can tunnel
	IPv6 packets between themselves. In this case, the tunnel spans one		IPv6 packets between themselves. In this case, the tunnel spans one
	segment of the end-to-end path that the IPv6 packet takes.		segment of the end-to-end path that the IPv6 packet takes.
	The source and destination addresses of the IPv6 packets traversing		The source and destination addresses of the IPv6 packets traversing
	the tunnel could come from a wide range of IPv6 prefixes. It is not		the tunnel could come from a wide range of IPv6 prefixes. It is not
	scalable to establish IPsec tunnel mode SAs for all such packets.		scalable to establish IPsec tunnel mode SAs for all such packets.
	Hence, IPsec transport mode SA is recommended for this scenario.		Hence, IPsec transport mode SA is recommended for this scenario.
	IPv6 ingress filtering should be performed to mitigate the IPv6		IPv6 ingress filtering should be performed to mitigate the IPv6
	address spoofing threat.		address spoofing threat.
	A specific case of router-to-router tunnels, when one router resides		A specific case of router-to-router tunnels, when one router resides
	at an end site, is described in the next section.		at an end site, is described in the next section.
	3.2 Site-to-Router/Router-to-Site Tunnels		3.2 Site-to-Router/Router-to-Site Tunnels
	This is a generalization of site-to-router and router-to-site		This is a generalization of host-to-router and router-to-host
	tunneling, because the issues when connecting a whole site (using a		tunneling, because the issues when connecting a whole site (using a
	router), and connecting a single host are roughly equal.		router), and connecting a single host are roughly equal.
	_----_ .---------. IPsec _----_ IPsec .-------.		_----_ .---------. IPsec _----_ IPsec .-------.
	_( IPv6 )_ |v6-in-v4 | Tunnel _( IPv4 )_ Tunnel | V4/V6 |		_( IPv6 )_ |v6-in-v4 | Tunnel _( IPv4 )_ Tunnel | V4/V6 |
	( Internet )<--->| Router |<=======( Internet )=======>| Site B |		( Internet )<--->| Router |<=======( Internet )=======>| Site B |
	(_ _) | A | (_ _) '--------'		(_ _) | A | (_ _) '--------'
	'----' '---------' '----'		'----' '---------' '----'
	^		^
	|		|
	V		V
	.--------.		.--------.
	| Native |		| Native |
	| IPv6 |		| IPv6 |
	| node |		| node |
	'--------'		'--------'
	Figure 2: Router-to-Site Scenario		Figure 2: Router-to-Site Scenario
	IPv6/IPv4 routers can tunnel IPv6 packets to their final destination		IPv6/IPv4 routers can tunnel IPv6 packets to their final destination
	IPv6/IPv4 host. This tunnel spans only the last segment of the		IPv6/IPv4 site. This tunnel spans only the last segment of the
	end-to-end path.		end-to-end path.
	This is the same as the Site-to-Router case.		This is the same as the Site-to-Router case.
	+---------------------+		+---------------------+
	| IPv6 Network |		| IPv6 Network |
	| |		| |
	.--------. _----_ | .--------. |		.--------. _----_ | .--------. |
	| V6/V4 | _( IPv4 )_ | |v6-in-v4| |		| V6/V4 | _( IPv4 )_ | |v6-in-v4| |
	| Site B |<====( Internet )==========>| Router | |		| Site B |<====( Internet )==========>| Router | |
	skipping to change at page 7, line 5 ¶		skipping to change at page 6, line 50 ¶
	| | Host | |		| | Host | |
	| '--------' |		| '--------' |
	+---------------------+		+---------------------+
	Figure 3: Site-to-Router Scenario		Figure 3: Site-to-Router Scenario
	IPv6/IPv4 hosts can tunnel IPv6 packets to an intermediary IPv6/IPv4		IPv6/IPv4 hosts can tunnel IPv6 packets to an intermediary IPv6/IPv4
	router that is reachable via an IPv4 infrastructure. This type of		router that is reachable via an IPv4 infrastructure. This type of
	tunnel spans the first segment of the packet's end-to-end path.		tunnel spans the first segment of the packet's end-to-end path.
	In this case, the host(s) originate the packet with source address		Here, the hosts in the site originate the packets with source
	coming from a well known prefix whereas the destination address could		addresses coming from a well known prefix whereas the destination
	be any node on the internet. In this case, the IPsec tunnel mode SA		address could be any node on the Internet.
	can be bound to the prefix that was allocated to the router at Site B
	and router A can verify that the source address of the packet matches		In this case, the IPsec tunnel mode SA can be bound to the prefix
	the prefix. Site B will not be able to do a similar verification for		that was allocated to the router at Site B and router A can verify
	the packets it receives. This may be quite reasonable for most of		that the source address of the packet matches the prefix. Site B
	the deployment cases, for example, the ISP allocating a /48 to a		will not be able to do a similar verification for the packets it
	customer. The CPE (where the tunnel is terminated) "trusts" (in a		receives. This may be quite reasonable for most of the deployment
	weak sense) the ISP's router and the ISP's router can verify that the		cases, for example, the ISP allocating a /48 to a customer. The CPE
	Site B is the only one that can originate packets within the /48.		(where the tunnel is terminated) "trusts" (in a weak sense) the ISP's
	IPsec tunnel mode SA is recommended for this case, though similar		router and the ISP's router can verify that the Site B is the only
	amount of protection can be obtained with transport mode SA with		one that can originate packets within the /48.
	strict ingress filtering as well.
			IPsec tunnel mode SA is recommended for this case which prevents
			spoofing completely, though similar amount of protection can be
			obtained with transport mode SA with strict ingress filtering (except
			for link-local addresses) as well.
	3.3 Host-to-Host Tunnels		3.3 Host-to-Host Tunnels
	.--------. _----_ .--------.		.--------. _----_ .--------.
	| V6/V4 | _( IPv4 )_ | V6/V4 |		| V6/V4 | _( IPv4 )_ | V6/V4 |
	| Host | <======( Internet )=====> | Host |		| Host | <======( Internet )=====> | Host |
	| A | (_ _) | B |		| A | (_ _) | B |
	'--------' '----' '--------'		'--------' '----' '--------'
	IPsec tunnel between		IPsec tunnel between
	Host A and Host B		Host A and Host B
	skipping to change at page 7, line 40 ¶		skipping to change at page 7, line 40 ¶
	Figure 4: Host-to-Host Scenario		Figure 4: Host-to-Host Scenario
	IPv6/IPv4 hosts that are interconnected by an IPv4 infrastructure can		IPv6/IPv4 hosts that are interconnected by an IPv4 infrastructure can
	tunnel IPv6 packets between themselves. In this case, the tunnel		tunnel IPv6 packets between themselves. In this case, the tunnel
	spans the entire end-to-end path that the packet takes.		spans the entire end-to-end path that the packet takes.
	In this case, the source and the destination IPv6 address are known a		In this case, the source and the destination IPv6 address are known a
	priori. A tunnel mode SA can be bound to the specific address. The		priori. A tunnel mode SA can be bound to the specific address. The
	address verification prevents IPv6 address spoofing completely.		address verification prevents IPv6 address spoofing completely.
	4. Assumptions		4. IKE and IPsec Versions
	Throughout this document we make a few assumptions which are briefly
	listed here. The following documents are used as a basis:
	o Revised 'Security Architecture for the Internet Protocol' as		This section discusses the different versions of the IKE and IPsec
	described in [I-D.ietf-ipsec-rfc2401bis].		security architecture and its applicability to this document.
	o IKEv2 as described in [I-D.ietf-ipsec-ikev2] and the accompanying		IPsec security architecture is defined in [RFC2401] and
	documents for cipher suites and cryptgraphic algorithms (see		[I-D.ietf-ipsec-rfc2401bis]. There are several differences between
	[I-D.ietf-ipsec-ikev2-algorithms], [I-D.ietf-ipsec-ikev2-iana] and		them. The difference relevants to this document are discussed below.
	[I-D.ietf-ipsec-ui-suites]).
	o 'IP Encapsulating Security Payload (ESP)' as described in		1. [RFC2401] does not allow IP as the next layer protocol in traffic
	[I-D.ietf-ipsec-esp-v3]		selectors when IPsec SA is negotiated.
			[I-D.ietf-ipsec-rfc2401bis] allows IP also as the next layer
			protocol like TCP or UDP in traffic selectors.
	o 'UDP Encapsulation of IPsec Packets' as described in		2. [RFC2401] does not support transport mode SAs between hosts and
	[I-D.ietf-ipsec-udp-encaps] for the purpose of NAT traversal.		security gateways. [I-D.ietf-ipsec-rfc2401bis] supports
			transport mode SA between hosts and security gateway to provide
			link security e.g., IP-IP tunnel protected with IPsec.
	Please note that we do not consider the usage of the IP		3. [I-D.ietf-ipsec-rfc2401bis] assumes IKEv2, as some of the new
	Authentication Header (AH) [I-D.ietf-ipsec-rfc2402bis] since Section		features cannot be negotiated using IKEv1. It is valid to
	3.2 of [I-D.ietf-ipsec-rfc2401bis] specifies that IPsec		negotiate multiple traffic selectors for a given IPsec SA in
	implementations MUST implement ESP and MAY implement AH with the		[I-D.ietf-ipsec-rfc2401bis]. This is possible only with
	reasoning that ESP provides security services (such as integrity		[I-D.ietf-ipsec-ikev2]. If [RFC2409] is used, then multiple SAs
	protection without confidentiality protection using 'NULL'		need to be setup for each of the traffic selector.
	encryption) which are comparable with AH.
	Furthermore, we focus on IKEv2 since [I-D.ietf-ipsec-rfc2401bis]		Note that the existing implementations based on [RFC2409] may already
	assumes use of IKEv2 as a key and security association management		be able to support the [I-D.ietf-ipsec-rfc2401bis] features described
	system and not IKEv1 with its extensions.		in (1) and (2). If appropriate, the deployment may choose to use
			them.
	The decision to focus on IKEv2 and newer IPsec documents is based on		IKE is defined in [RFC2409] (which is referred to as IKE in this
	the premise that doing so allows using "mixed-mode" transforms as		document) and in [I-D.ietf-ipsec-ikev2] (which is referred to as
	described below. This is useful for Transport mode SAs. Some		IKEv2 in this document). IKEv2 supports features that are useful for
	implementations might, however, support these SAs already, at least		configuring and securing tunnels which are not present with IKEv1.
	using manual configuration.
	The support of IPv4/IPv6 transition capabilities with IPsec is		1. IKEv2 supports legacy authentication methods by carrying them in
	possible with [RFC2401] and with [I-D.ietf-ipsec-rfc2401bis] (see		EAP payloads. This can be used to authenticate the hosts/sites
	Section 5.1.2 of [I-D.ietf-ipsec-rfc2401bis]). IPsec allows the IP		to the ISP using EAP methods that supports username and password.
	version of the encapsulating header to be different from that of the
	inner header.
	The IPsec framework does not allow IKEv1/IKEv2 to be used to create		2. IKEv2 supports dynamic address configuration which may be used to
	tunnels which do not experience cryptographic protection although		configure the IPv6 address of the host.
	this functionality might be useful in some environments. IKEv2 would
	then migrate into a secure signaling protocol for tunnel
	establishment (without implementing data traffic protection) in a
	fashion similar to the 'IPv6 Tunnel Broker with the Tunnel Setup
	Protocol (TSP)' [I-D.blanchet-v6ops-tunnelbroker-tsp] protocol
	proposal. Section 4.2 of [I-D.ietf-ipsec-rfc2401bis], however,
	prohibits this functionality by stating:
	"		NAT traversal works with both the old and revised IPsec
	A compliant implementation MUST NOT allow instantiation of an ESP SA		architectures, but the negotiation is integrated with IKEv2.
	that employs both NULL encryption and no integrity algorithm.
	"
	Regarding the usage of the Explicit Congestion Notification (ECN), it		We do not consider the usage of the IP Authentication Header (AH)
	appears that the ECN bits in the IPv4 and IPv6 headers have exactly		[I-D.ietf-ipsec-rfc2402bis] as ESP [I-D.ietf-ipsec-esp-v3] provides
	the same semantics, so the bits just need to be copied from the outer		security services (such as integrity protection without
	IPv4 header to the inner IPv6 header on tunnel exit.		confidentiality protection using 'NULL' encryption) which are
			comparable with AH. This is explicitly stated in
			[I-D.ietf-ipsec-rfc2401bis].
	5. IPsec Configuration Details		5. IPsec Configuration Details
	This section describes details about the IPsec tunnel establishment		This section describes details about the IPsec tunnel establishment
	for protection of IPv4/IPv6 data traffic.		for protection of IPv4/IPv6 data traffic.
	5.1 IPsec Transport mode		5.1 IPsec Transport mode
	This is typically used in Router-to-Router scenario.		This is typically used in Router-to-Router scenario.
	The following SPD entries assume that there are two routers Router1		The following SPD entries assume that there are two routers Router1
	and Router2, whose tunnel endpoint's IPv4 address is denoted by		and Router2, whose tunnel endpoint's IPv4 address is denoted by
	IPV4-TEP1 and IPV4-TEP2 respectively.		IPV4-TEP1 and IPV4-TEP2 respectively. The implementations that are
			strictly conformant to [RFC2401] may not be able to setup the IPsec
			transport mode SA.
	Router1's SPD OUT :		Router1's SPD OUT :
	IF SRC = IPV4-TEP1 && DST = IPV4-TEP2 && protocol = 41		IF SRC = IPV4-TEP1 && DST = IPV4-TEP2 && protocol = 41
	THEN USE ESP TRANSPORT MODE SA		THEN USE ESP TRANSPORT MODE SA
	Router1's SPD IN:		Router1's SPD IN:
	IF SRC = IPV4-TEP2 && DST = IPV4-TEP1 && protocol = 41		IF SRC = IPV4-TEP2 && DST = IPV4-TEP1 && protocol = 41
	THEN USE ESP TRANSPORT MODE SA		THEN USE ESP TRANSPORT MODE SA
	skipping to change at page 9, line 48 ¶		skipping to change at page 9, line 40 ¶
	The IDci and IDcr payloads of IKEv1 carry the IPv4-TEP1, IPV4-TEP2		The IDci and IDcr payloads of IKEv1 carry the IPv4-TEP1, IPV4-TEP2
	and protocol value 41 as phase 2 identities. With IKEv2, the traffic		and protocol value 41 as phase 2 identities. With IKEv2, the traffic
	selectors are used to carry the same information.		selectors are used to carry the same information.
	5.2 IPsec Tunnel mode		5.2 IPsec Tunnel mode
	5.2.1 SPD for Host-to-Host Scenario		5.2.1 SPD for Host-to-Host Scenario
	The following SPD entries assume that there are two hosts Host1 and		The following SPD entries assume that there are two hosts Host1 and
	Host2, whose IPv6 addresses are denoted by IPV6-EP1 and IPV6-EP2 and		Host2, whose IPv6 addresses are denoted by IPV6-EP1 and IPV6-EP2
	IPV4 addresses of the tunnel endpoints are denoted by IPV4-TEP1 and		(global addresses) and IPV4 addresses of the tunnel endpoints are
	IPV4-TEP2 respectively.		denoted by IPV4-TEP1 and IPV4-TEP2 respectively. The first three
			entries of the following SPD are used for protecting link-local
			traffic: specifically Neighbor Discovery [RFC2461] (ND) and Multicast
			Listener Discovery messages (MLD) [RFC2710].
			IKEv2 [I-D.ietf-ipsec-ikev2] provides the ability to negotiate a
			single SA for multiple traffic selectors. It could be used here to
			negotiate a single SA for global and link-local entries shown below.
	Host1's SPD OUT :		Host1's SPD OUT :
			IF SRC = ::/128 & destination = any
			THEN USE ESP TUNNEL MODE SA:
			outer source = IPv4-TEP1
			outer dest = IPV4-TEP2
			IF SRC = fe80::/10 & destination = any
			THEN USE ESP TUNNEL MODE SA:
			outer source = IPv4-TEP1
			outer dest = IPV4-TEP2
			IF SRC = any & destination = fe80::/10
			THEN USE ESP TUNNEL MODE SA:
			outer source = IPv4-TEP1
			outer dest = IPV4-TEP2
	IF SRC = IPV6-EP1 && DST = IPV6-EP2		IF SRC = IPV6-EP1 && DST = IPV6-EP2
	THEN USE ESP TUNNEL MODE SA:		THEN USE ESP TUNNEL MODE SA:
	outer source = IPv4-TEP1		outer source = IPv4-TEP1
	outer dest = IPV4-TEP2		outer dest = IPV4-TEP2
	Host1's SPD IN:		Host1's SPD IN:
			IF SRC = ::/128 & destination = any
			THEN USE ESP TUNNEL MODE SA:
			outer source = IPv4-TEP2
			outer dest = IPV4-TEP1
			IF SRC = fe80::/10 & destination = any
			THEN USE ESP TUNNEL MODE SA:
			outer source = IPv4-TEP2
			outer dest = IPV4-TEP1
			IF SRC = any & destination = fe80::/10
			THEN USE ESP TUNNEL MODE SA:
			outer source = IPv4-TEP2
			outer dest = IPV4-TEP1
	IF SRC = IPV6-EP2 && DST = IPV6-EP1		IF SRC = IPV6-EP2 && DST = IPV6-EP1
	THEN USE ESP TUNNEL MODE SA		THEN USE ESP TUNNEL MODE SA
	outer source = IPV4-TEP2		outer source = IPV4-TEP2
	outer dest = IPV4-TEP1		outer dest = IPV4-TEP1
	Host2's SPD OUT:		Host2's SPD OUT:
			IF SRC = ::/128 & destination = any
			THEN USE ESP TUNNEL MODE SA:
			outer source = IPv4-TEP2
			outer dest = IPV4-TEP1
			IF SRC = fe80::/10 & destination = any
			THEN USE ESP TUNNEL MODE SA:
			outer source = IPv4-TEP2
			outer dest = IPV4-TEP1
			IF SRC = any & destination = fe80::/10
			THEN USE ESP TUNNEL MODE SA:
			outer source = IPv4-TEP2
			outer dest = IPV4-TEP1
	IF SRC = IPV6-EP2 && DST = IPV6-EP1		IF SRC = IPV6-EP2 && DST = IPV6-EP1
	THEN USE ESP TUNNEL MODE SA		THEN USE ESP TUNNEL MODE SA
	outer source = IPV4-TEP2		outer source = IPV4-TEP2
	outer dest = IPV4-TEP1		outer dest = IPV4-TEP1
	Host2's SPD IN:		Host2's SPD IN:
			IF SRC = ::/128 & destination = any
			THEN USE ESP TUNNEL MODE SA:
			outer source = IPv4-TEP1
			outer dest = IPV4-TEP2
			IF SRC = fe80::/10 & destination = any
			THEN USE ESP TUNNEL MODE SA:
			outer source = IPv4-TEP1
			outer dest = IPV4-TEP2
			IF SRC = any & destination = fe80::/10
			THEN USE ESP TUNNEL MODE SA:
			outer source = IPv4-TEP1
			outer dest = IPV4-TEP2
	IF SRC = IPV6-EP1 && DST = IPV6-EP2		IF SRC = IPV6-EP1 && DST = IPV6-EP2
	THEN USE ESP TUNNEL MODE SA:		THEN USE ESP TUNNEL MODE SA:
	outer source = IPv4-TEP1		outer source = IPv4-TEP1
	outer dest = IPV4-TEP2		outer dest = IPV4-TEP2
	The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and IPV6-TEP2		The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and IPV6-TEP2
	as phase 2 identities. With IKEv2, the traffic selectors are used to		or the link-local addresses from the packet headers as phase 2
	carry the same information.		identities. With IKEv2, the traffic selectors are used to carry the
			same information.
	5.2.2 SPD for Host-to-Router scenario		5.2.2 SPD for Host-to-Router scenario
	The following SPD entries assume that the host has the IPv6 address		The following SPD entries assume that the host has the IPv6 address
	IPV6-EP1 and the tunnel end points of the host and router are		IPV6-EP1 and the tunnel end points of the host and router are
	IPV4-TEP1 and IPV4-TEP2 respectively. If the tunnel is between a		IPV4-TEP1 and IPV4-TEP2 respectively. If the tunnel is between a
	router and a host where the router has allocated a IPV6-PREF/48 to		router and a host where the router has allocated a IPV6-PREF/48 to
	the host, the corresponding SPD entries can be derived by		the host, the corresponding SPD entries can be derived by
	substituting IPV6-EP1 by IPV6-PREF/48.		substituting IPV6-EP1 by IPV6-PREF/48. The first three entries of
			the following SPD are used for protecting link-local traffic:
			specifically Neighbor Discovery (ND) and Multicast Listener Discovery
			messages (MLD).
			IKEv2 [I-D.ietf-ipsec-ikev2] provides the ability to negotiate a
			single SA for multiple traffic selectors. It could be used here to
			negotiate a single SA for global and link-local entries shown below.
	Host's SPD OUT:		Host's SPD OUT:
			IF SRC = ::/128 & destination = any
			THEN USE ESP TUNNEL MODE SA:
			outer source = IPv4-TEP1
			outer dest = IPV4-TEP2
			IF SRC = fe80::/10 & destination = any
			THEN USE ESP TUNNEL MODE SA:
			outer source = IPv4-TEP1
			outer dest = IPV4-TEP2
			IF SRC = any & destination = fe80::/10
			THEN USE ESP TUNNEL MODE SA:
			outer source = IPv4-TEP1
			outer dest = IPV4-TEP2
	IF SRC = IPV6-EP1 && DST = any		IF SRC = IPV6-EP1 && DST = any
	THEN use ESP TUNNEL MODE SA		THEN use ESP TUNNEL MODE SA
	outer source = IPV4-TEP1		outer source = IPV4-TEP1
	outer dest = IPV4-TEP2		outer dest = IPV4-TEP2
	Host's SPD IN:		Host's SPD IN:
			IF SRC = ::/128 & destination = any
			THEN USE ESP TUNNEL MODE SA:
			outer source = IPv4-TEP2
			outer dest = IPV4-TEP1
			IF SRC = fe80::/10 & destination = any
			THEN USE ESP TUNNEL MODE SA:
			outer source = IPv4-TEP2
			outer dest = IPV4-TEP1
			IF SRC = any & destination = fe80::/10
			THEN USE ESP TUNNEL MODE SA:
			outer source = IPv4-TEP2
			outer dest = IPV4-TEP1
	IF SRC = any && DST = IPV6-EP1		IF SRC = any && DST = IPV6-EP1
	THEN use ESP TUNNEL MODE SA		THEN use ESP TUNNEL MODE SA
	outer source = IPV4-TEP1		outer source = IPV4-TEP2
	outer dest = IPV4-TEP2		outer dest = IPV4-TEP1
	Router's SPD OUT:		Router's SPD OUT:
			IF SRC = ::/128 & destination = any
			THEN USE ESP TUNNEL MODE SA:
			outer source = IPv4-TEP2
			outer dest = IPV4-TEP1
			IF SRC = fe80::/10 & destination = any
			THEN USE ESP TUNNEL MODE SA:
			outer source = IPv4-TEP2
			outer dest = IPV4-TEP1
			IF SRC = any & destination = fe80::/10
			THEN USE ESP TUNNEL MODE SA:
			outer source = IPv4-TEP2
			outer dest = IPV4-TEP1
	IF SRC = any && DST = IPV6-EP1		IF SRC = any && DST = IPV6-EP1
	THEN use ESP TUNNEL MODE SA		THEN use ESP TUNNEL MODE SA
	outer source = IPV4-TEP1		outer source = IPV4-TEP2
	outer dest = IPV4-TEP2		outer dest = IPV4-TEP1
	Router's SPD IN:		Router's SPD IN:
			IF SRC = ::/128 & destination = any
			THEN USE ESP TUNNEL MODE SA:
			outer source = IPv4-TEP1
			outer dest = IPV4-TEP2
			IF SRC = fe80::/10 & destination = any
			THEN USE ESP TUNNEL MODE SA:
			outer source = IPv4-TEP1
			outer dest = IPV4-TEP2
			IF SRC = any & destination = fe80::/10
			THEN USE ESP TUNNEL MODE SA:
			outer source = IPv4-TEP1
			outer dest = IPV4-TEP2
	IF SRC = IPV6-EP1 && DST = any		IF SRC = IPV6-EP1 && DST = any
	THEN use ESP TUNNEL MODE SA		THEN use ESP TUNNEL MODE SA
	outer source = IPV4-TEP1		outer source = IPV4-TEP1
	outer dest = IPV4-TEP2		outer dest = IPV4-TEP2
	The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and		The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and
	ID_IPV6_ADDR_RANGE or ID_IPV6_ADDR_SUBNET as its phase 2 identity.		ID_IPV6_ADDR_RANGE or ID_IPV6_ADDR_SUBNET as its phase 2 identity.
	The starting address is zero IP address and the end address is all		The starting address is zero IP address and the end address is all
	ones for ID_IPV6_ADDR_RANGE. The starting address is zero IP address		ones for ID_IPV6_ADDR_RANGE. The starting address is zero IP address
	and the end address is all zeroes for ID_IPV6_ADDR_SUBNET. With		and the end address is all zeroes for ID_IPV6_ADDR_SUBNET.
	IKEv2, the traffic selectors are used to carry the same information.		Link-local addresses from the packet would be used if the packet
			matches the first three selector entries of the SPD. With IKEv2, the
	To describe the packet format the following acronyms are used		traffic selectors are used to carry the same information.
	throughout this document:
	o IPV4-TEP1 and IPV4-TEP2 denote the IPv4 address of the tunnel
	endpoints.
	o IPV6-EP1 and IPV6-EP2 denote the IPv6 address of the two IPv6
	endpoints of the communication.
	The packet format is the same for both transport mode and tunnel mode		The packet format is the same for both transport mode and tunnel mode
	as shown in Figure 9.		as shown in Figure 8.
	IPv4 header (source = IPV4-TEP1,		IPv4 header (source = IPV4-TEP1,
	destination = IPV4-TEP2)		destination = IPV4-TEP2)
	ESP header		ESP header
	IPv6 header (source = IPV6-EP1,		IPv6 header (source = IPV6-EP1,
	destination = IPV6-EP2)		destination = IPV6-EP2)
	Figure 9: Packet Format for transport and tunnel mode		Figure 8: Packet Format for transport and tunnel mode
	This type of layering may not be valid with [RFC2401] since, with a
	strict definition, IP does not meet the definition of a "higher layer
	protocol" being the next protocol after an IP header.
	With [I-D.ietf-ipsec-rfc2401bis] the definition about the "next layer
	protocol" was explicitly expanded and hence this type of layering is
	valid.
	6. Dynamic Address Configuration		6. Dynamic Address Configuration
	With the exchange of protected configuration payloads, IKEv2 is able		With the exchange of protected configuration payloads, IKEv2 is able
	to provide the IKEv2 peer with DHCP-like information payloads. These		to provide the IKEv2 peer with DHCP-like information payloads. These
	configuration payloads are exchanged between the IKEv2 initiator and		configuration payloads are exchanged between the IKEv2 initiator and
	the responder with the help of the CFG_REQUEST/CFG_REPLY and		the responder.
	CFG_SET/CFG_ACK payloads. The former is used to request information
	and the latter allows pushing configuration data. Configuration
	information (e.g., a temporary address) can be carried in any request
	to create a CHILD_SA by including a CP payload.
	These configuration payloads are primiarly used for bootstrapping the
	IKEv2 peer. Although these payloads are extensible they are not used
	as a generic purpose management.
	The following example exchange illustrates the usage of configuration
	payloads:
	Initiator Responder
	------------- --------------
	HDR, SAi1, KEi, Ni -->
	<-- HDR(A,0), N(COOKIE)
	HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
	<-- HDR, SAr1, KEr, Nr,[CERTREQ]
	HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
	AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr} -->
	<-- HDR, SK {IDr, [CERT,] AUTH,
	CP(CFG_REPLY), SAr2, TSi, TSr}
	Figure 10: IKEv2 Configuration payload payload exchange
	The example message exchange shown in Figure 10 shows IKEv2 with a
	denial of service protection enabled exchange and a CFG_REQUEST in
	message 5 and the corresponding response in message 6. The content
	of these payloads, for example, contains (as given in Section 2.19 of
	[I-D.ietf-ipsec-ikev2]):
	CP(CFG_REQUEST)=
	INTERNAL_ADDRESS(0.0.0.0)
	INTERNAL_NETMASK(0.0.0.0)
	INTERNAL_DNS(0.0.0.0)
	TSi = (0, 0-65536,0.0.0.0-255.255.255.255)
	TSr = (0, 0-65536,0.0.0.0-255.255.255.255)
	CP(CFG_REPLY)=		This can be used by the host in the host-to-router scenario to obtain
	INTERNAL_ADDRESS(10.168.219.202)		the IPv6 address from the ISP as part of setting up the IPsec tunnel
	INTERNAL_NETMASK(255.255.255.0)		mode SA.
	INTERNAL_SUBNET(10.168.219.0/255.255.255.0)
	TSi = (0, 0-65536,10.168.219.202-10.168.219.202)
	TSr = (0, 0-65536,10.168.219.0-10.168.219.255)
	7. Extensible Authentication Support		7. Extensible Authentication Support
	In addition to the authentication mechanisms provided in IKEv2 the		In addition to the authentication mechanisms provided in IKEv2 the
	Extensible Authentication Protocol (EAP) [I-D.ietf-eap-rfc2284bis] is		Extensible Authentication Protocol (EAP) [I-D.ietf-eap-rfc2284bis] is
	included which provides some flexibility for authentication		included which provides some flexibility for authentication
	mechanisms. Figure 12 shows an example IKEv2 exchange with EAP		mechanisms. The usage of EAP offers two interesting features:
	support. The usage of EAP offers two interesting features:
	o User authentication is terminated at a different entity other than		o User authentication is terminated at a different entity other than
	the IKEv2 responder. This allows users' security credentials to		the IKEv2 responder. This allows users' security credentials to
	be kept in a central place (e.g., AAA server) and to terminate the		be kept in a central place (e.g., AAA server) and to terminate the
	EAP method at this entity instead at the IKEv2 responder.		EAP method at this entity instead at the IKEv2 responder.
	Authorization can also be executed at the same entity.		Authorization can also be executed at the same entity.
	o A number of authentication and key exchange protocols are		o A number of authentication and key exchange protocols are
	supported via EAP method (such as EAP-AKA, EAP-SIM, SRP, etc.).		supported via EAP method (such as EAP-AKA, EAP-SIM, SRP, etc.).
	Each EAP methods provides its own properties and usage		Each EAP methods provides its own properties and usage
	environment. This provides a certain degree of flexibility.		environment. This provides a certain degree of flexibility.
	Note that IKEv2 with EAP authentication still requires public key		Note that IKEv2 with EAP authentication still requires public key
	based authentication of the IKEv2 responder outside the EAP		based authentication of the IKEv2 responder outside the EAP
	authentication. In most deployments this requires a server-side		authentication. In most deployments this requires a server-side
	public-key based authentication to protect the EAP exchange with a		public-key based authentication to protect the EAP exchange with a
	uni-lateral authenticated tunnel. With the extensions proposed in		uni-lateral authenticated tunnel. This method can be used in the
	[I-D.eronen-ipsec-ikev2-eap-auth] only EAP authentication is used by		host-to-router scenario, where the host can use the traditional
	omitting the IKEv2 responder authentication.		(username, password) mechanism to authenticate to the router (ISP)
			without needing additional configuration for IKE.
	Please note that Section 3.16 of [I-D.ietf-ipsec-ikev2] indicates
	that the EAP Identity-Request/Identity-Response payload SHOULD NOT be
	used. The IDr payload (message 3 in Figure 12) carries this identity
	instead. As a consequence active user identity confidentiality for
	the IKEv2 initiator is not provided. Special purpose EAP methods
	must be used instead if this features is desired.
	Figure 12 shows an example IKEv2 message exchange with EAP-AKA as an
	EAP method. Note that the interaction between the IKEv2 responder
	and the AAA infrastructure is not shown.
	Initiator Responder
	------------- --------------
	HDR, SAi1, KEi, Ni -->
	<-- HDR, SAr1, KEr, Nr, [CERTREQ]
	HDR, SK {IDi, [CERTREQ,] [IDr,]
	SAi2, TSi, TSr} -->
	<-- HDR, SK {IDr, [CERT,] AUTH,
	EAP-Request/AKA-Challenge (AT_RAND, AT_AUTN, AT_MAC) }
	HDR, SK {EAP-Response/AKA-Challenge(AT_RES, AT_MAC)} -->
	<-- HDR, SK {EAP-Success, AUTH}
	HDR, SK { AUTH } -->
	<-- HDR, SK { SAr2, TSi, TSr }
	Figure 12: EAP usage in IKEv2 with EAP-AKA
	EAP will typically be used with a backend AAA server which raises
	some security concerns. See [I-D.ietf-eap-keying] for a more
	complete discussion of these security issues.
	When a backend server is used, there are actually two authentication
	exchanges: the EAP method between the client and the AAA server, and
	another authentication between the AAA server and IKEv2 gateway. The
	AAA server authenticates the client using the selected EAP method,
	and they establish a session key. The AAA server then sends this key
	to the IKEv2 gateway over a connection authenticated using e.g.
	IPsec or TLS. The protocol used between the IKEv2 responder and the
	AAA server could be, for instance, Diameter or RADIUS [RFC3579].
	RADIUS and Diameter are able to carry EAP payloads as described in
	[RFC3579] and in [I-D.ietf-aaa-eap], respectively.
	8. NAT Traversal		8. NAT Traversal
	Network address (and port) translation devices are commonly found in		Network address (and port) translation devices are commonly found in
	today's networks. A detailed description of the problem of IPsec		today's networks. A detailed description of the problem of IPsec
	protected data traffic traversing a NAT including requirements are		protected data traffic traversing a NAT including requirements are
	discussed in [RFC3715].		discussed in [RFC3715].
	IKEv2 can detect the presence of a NAT automatically by sending an		IKEv2 can detect the presence of a NAT automatically by sending an
	Informational exchange with NAT_DETECTION_SOURCE_IP and		Informational exchange with NAT_DETECTION_SOURCE_IP and
	skipping to change at page 17, line 5 ¶		skipping to change at page 16, line 30 ¶
	o Using a pre-configured or pre-determined IPv4 anycast address.		o Using a pre-configured or pre-determined IPv4 anycast address.
	o Using other, unspecified or proprietary methods such as TED (see		o Using other, unspecified or proprietary methods such as TED (see
	[I-D.fluhrer-ted]).		[I-D.fluhrer-ted]).
	For the purpose of this document it is assumed that this address can		For the purpose of this document it is assumed that this address can
	be obtained somehow. Once the address has been learned, it is		be obtained somehow. Once the address has been learned, it is
	configured as the tunnel end-point for the configured IPv6-over-IPv4		configured as the tunnel end-point for the configured IPv6-over-IPv4
	tunnel.		tunnel.
	10. Example		This problem is also discussed at more length in
			[I-D.palet-v6ops-tun-auto-disc].
	TBD: Full-fledged example		10. IANA Considerations
			This memo makes no request to IANA. [[ Please remove this section at
			publication ]]
	11. Security Considerations		11. Security Considerations
	When you run IPv6-in-IPv4 tunnels (unsecured) over the Internet, it		When you run IPv6-in-IPv4 tunnels (unsecured) over the Internet, it
	is possible to "inject" packets in the tunnel by spoofing the source		is possible to "inject" packets in the tunnel by spoofing the source
	address (data plane security), or if the tunnel is signalled somehow		address (data plane security), or if the tunnel is signalled somehow
	(e.g., some messages where you authenticate to the server, so that		(e.g., some messages where you authenticate to the server, so that
	you would get a static v6 prefix), someone might be able to spoof the		you would get a static v6 prefix), someone might be able to spoof the
	signalling (control plane security).		signalling (control plane security).
	To add security to both, the protocol for tunnel setup and to the		To add security to both, the protocol for tunnel setup and to the
	data traffic, the IPsec framework plays an important role.		data traffic, the IPsec framework plays an important role.
	IKEv2 is a signaling protocol with optional Denial of Service		IKE is a signaling protocol with optional Denial of Service
	protection which authenticates both end points (with different		protection which authenticates both end points (with different
	identifities) and establishes two types of security associations		identifities) and establishes two types of security associations
	(CHILD-SAs and IKE-SA). The authentication mechanisms are very		(CHILD-SAs and IKE-SA). The authentication mechanisms are very
	flexible due to the built-in support for symmetric and asymmetric		flexible due to the built-in support for symmetric and asymmetric
	cryptography (or even a combination of both) and the Extensible		cryptography (or even a combination of both) and the Extensible
	Authentication Protocol support (as desribed in Figure 12). The		Authentication Protocol support. The IKE-SA is used to secure most
	IKE-SA is used to secure most of the IKEv2 message exchange. In		of the IKE message exchange. In particular the CHILD-SA exchange,
	particular the CHILD-SA exchange, Informational exchanges (such as		Informational exchanges (such as the dead-peer detection mechanisms
	the dead-peer detection mechanisms used for liveness checks) and the		used for liveness checks) and the exchange of configuration messages
	exchange of configuration messages are secured. The CHILD-SA		are secured. The CHILD-SA exchange leads to the establishment of a
	exchange leads to the establishment of a IPsec tunnel and the		IPsec tunnel and the creation of SAD and SPD entries.
	creation of SAD and SPD entries.
	As a summary, IKEv2 provides a secure signaling protocol for		As a summary, IKE provides a secure signaling protocol for
	establishing, maintaining and deleting an IPsec tunnel.		establishing, maintaining and deleting an IPsec tunnel.
	IPsec, with the Encapsulating Security Payload (ESP), offers		IPsec, with the Encapsulating Security Payload (ESP), offers
	integrity and data origin authentication, confidentiality, with		integrity and data origin authentication, confidentiality, with
	optional (at the discretion of the receiver) anti-replay features.		optional (at the discretion of the receiver) anti-replay features.
	The usage of confidentity-only is discouraged. ESP furthermore		The usage of confidentity-only is discouraged. ESP furthermore
	provides limited traffic flow confidentality.		provides limited traffic flow confidentality.
	IPsec provides access control mechanisms through the distribution of		IPsec provides access control mechanisms through the distribution of
	keys and also through the usage of policies dictated by the Security		keys and also through the usage of policies dictated by the Security
	Policy Database (SPD). Furthermore, through the usage of EAP and the		Policy Database (SPD). Furthermore, through the usage of EAP and the
	backend AAA infrastructure it is possible to enforce additional		backend AAA infrastructure it is possible to enforce additional
	authorization mechanisms (at the user level) at entities other than		authorization mechanisms (at the user level) at entities other than
	the tunnel end points.		the tunnel end points.
	The NAT traversal mechanism provided by IKEv2 introduces some		The NAT traversal mechanism provided by IKE introduces some
	weaknesses into IKEv2 and IPsec. These issues are discussed in more		weaknesses into IKE and IPsec. These issues are discussed in more
	detail in [I-D.ietf-ipsec-ikev2].		detail in [I-D.ietf-ipsec-ikev2].
	Please note that the usage of IPsec for the scenarios described in		Please note that the usage of IPsec for the scenarios described in
	Figure 3, Figure 2 and Figure 1 does not aim to protect the		Figure 3, Figure 2 and Figure 1 does not aim to protect the
	end-to-end communication. It protects just the tunnel part. It is		end-to-end communication. It protects just the tunnel part. It is
	still possible for an IPv6 endpoint that is not attached to the IPsec		still possible for an IPv6 endpoint that is not attached to the IPsec
	tunnel to spoof packets.		tunnel to spoof packets.
	12. Open Issues		12. Open Issues
	This section lists some open issues that will be resolved in future		This section lists some open issues for which feedback/text would be
	versions of this document.		especially useful, and will be resolved in one way or another in a
			future revision.
	o Some text on the usage of IKEv1 might be useful.
	o Discussion of 'Use of IPsec Transport Mode for Dynamic Routing'		o Discussion of 'Use of IPsec Transport Mode for Dynamic Routing'
	[I-D.touch-ipsec-vpn] would be appropriate.		[I-D.touch-ipsec-vpn] might be appropriate.
	o A more detailed description of the address configuration mechanism		o A more detailed description of the address configuration mechanism
	would be helpful. The configuration example with		would be helpful. The configuration example with
	CFG_REQUEST/CFG_REPLY payloads should contain IPv6 addresses.		CFG_REQUEST/CFG_REPLY payloads should contain IPv6 addresses.
	o The full-fledged example of Section 10 is still missing. A
	possible example is described below.
	o Some notes on the implications of mobility interworking are still		o Some notes on the implications of mobility interworking are still
	missing.		missing.
	o Discuss the use of link-local etc. messages with Tunnel mode SAs
	-- i.e., how many SAs will be needed (and how they are negotiated)
	if link-local messages will be present as well?
	o The "Site-to-Router" scenarios separation is a bit weak -- any		o The "Site-to-Router" scenarios separation is a bit weak -- any
	better ideas how to categorize these would be appreciated.		better ideas how to categorize these would be appreciated.
	o Better discussion of when transport/tunnel mode SAs make sense and		o More extensive discussion of when transport/tunnel mode SAs make
	would probably be useful.		sense and would probably be useful.
	The following paragraph describes a possible scenario for Section 10.
	+------------------+
	Transition | IPv6 Network |
	Device | |
	.--------. _----_ .--------. _----_ | .--------. |
	| V6/V4 | _( IPv4 )_ | V4/V6 | _( IPv6 )_ | | V6 | |
	| Host A |<-( Network )--| Router |-( Network )---> | Router | |
	'--------' (_ _) '--------' (_ _) | | X | |
	^ '----' '----' |/>'--------' |
	| // ^ |
	| / | | |
	| / | V |
	| // | .-------. |
	| / | | V6 | |
	+-------------------------------------/ | | Host B | |
	IPsec tunnel between | '--------' |
	V6 Host and Router B +------------------+
	As noted in the figure above there is an IPv4/IPv6 transition
	mechanism (which is not further specified) between the IPv4/IPv6
	network. The following IPsec packet is sent from Host A towards Host
	B (via router X).
	Host A (outgoing)
	IPsec ESP, Tunnel mode
	Outer Header:
	Src IP: IPv4 A
	Dst IP: IPv4 Router X
	Inner Header:
	Src IP: IPv6 A
	Dst IP: IPv6 Host B
	The transition device then changes the source and destination IP
	address is replaced (from IPv4 to an IPv6 address):
	Router (incoming):
	IPsec ESP, Tunnel mode
	Outer Header:
	Src IP: IPv6 NAT-PT box
	Dst IP: IPv6 Router X (automatic encapsulation of IPv4 in IPv6)
	Inner Header:
	Src IP: IPv6 A
	Dst IP: IPv6 Host B
	Router X (outgoing towards Host B, packet decapsulated):
	Header:
	Src IP: IPv6 A
	Dst IP: IPv6 Host B
	The packet then travels the same path backwards experiencing the same
	procressing.
	13. Contributors		13. Contributors
	Please note that the authors are listed in alphabetical order.		The authors are listed in alphabetical order.
	Suresh Satapati also participated in the discussions.		Suresh Satapati also participated in the discussions.
	14. Acknowledgments		14. Acknowledgments
	The authors would like to thank Stephen Kent and Michael Richardson		The authors would like to thank Stephen Kent and Michael Richardson
	for their comments.		for their comments.
	We would like to thank Pasi Eronen for his text contributions.		We would like to thank Pasi Eronen for his text contributions.
	skipping to change at page 20, line 46 ¶		skipping to change at page 18, line 48 ¶
	[I-D.ietf-ipsec-esp-v3]		[I-D.ietf-ipsec-esp-v3]
	Kent, S., "IP Encapsulating Security Payload (ESP)",		Kent, S., "IP Encapsulating Security Payload (ESP)",
	draft-ietf-ipsec-esp-v3-09 (work in progress), October		draft-ietf-ipsec-esp-v3-09 (work in progress), October
	2004.		2004.
	[I-D.ietf-ipsec-ikev2]		[I-D.ietf-ipsec-ikev2]
	Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",		Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
	draft-ietf-ipsec-ikev2-17 (work in progress), October		draft-ietf-ipsec-ikev2-17 (work in progress), October
	2004.		2004.
	[I-D.ietf-ipsec-ikev2-algorithms]
	Schiller, J., "Cryptographic Algorithms for use in the
	Internet Key Exchange Version 2",
	draft-ietf-ipsec-ikev2-algorithms-05 (work in progress),
	April 2004.
	[I-D.ietf-ipsec-rfc2401bis]		[I-D.ietf-ipsec-rfc2401bis]
	Kent, S. and K. Seo, "Security Architecture for the		Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", draft-ietf-ipsec-rfc2401bis-03 (work		Internet Protocol", draft-ietf-ipsec-rfc2401bis-05 (work
	in progress), September 2004.		in progress), December 2004.
	[I-D.ietf-ipsec-udp-encaps]		[I-D.ietf-ipsec-udp-encaps]
	Huttunen, A., "UDP Encapsulation of IPsec Packets",		Huttunen, A., "UDP Encapsulation of IPsec Packets",
	draft-ietf-ipsec-udp-encaps-09 (work in progress), May		draft-ietf-ipsec-udp-encaps-09 (work in progress), May
	2004.		2004.
	[I-D.ietf-ipsec-ui-suites]
	Hoffman, P., "Cryptographic Suites for IPsec",
	draft-ietf-ipsec-ui-suites-06 (work in progress), April
	2004.
	[I-D.ietf-v6ops-mech-v2]		[I-D.ietf-v6ops-mech-v2]
	Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms		Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
	for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-06		for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-06
	(work in progress), September 2004.		(work in progress), September 2004.
			[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
			Discovery for IP Version 6 (IPv6)", RFC 2461, December
			1998.
			[RFC2710] Deering, S., Fenner, W. and B. Haberman, "Multicast
			Listener Discovery (MLD) for IPv6", RFC 2710, October
			1999.
	15.2 Informative References		15.2 Informative References
	[I-D.bellovin-useipsec]		[I-D.bellovin-useipsec]
	Bellovin, S., "Guidelines for Mandating the Use of IPsec",		Bellovin, S., "Guidelines for Mandating the Use of IPsec",
	draft-bellovin-useipsec-03 (work in progress), March 2004.		draft-bellovin-useipsec-03 (work in progress), March 2004.
	[I-D.blanchet-v6ops-tunnelbroker-tsp]		[I-D.blanchet-v6ops-tunnelbroker-tsp]
	Parent, F. and M. Blanchet, "IPv6 Tunnel Broker with the		Parent, F. and M. Blanchet, "IPv6 Tunnel Broker with the
	Tunnel Setup Protocol(TSP)",		Tunnel Setup Protocol(TSP)",
	draft-blanchet-v6ops-tunnelbroker-tsp-01 (work in		draft-blanchet-v6ops-tunnelbroker-tsp-01 (work in
	progress), June 2004.		progress), June 2004.
	[I-D.eronen-ipsec-ikev2-eap-auth]
	Eronen, P., "Extension for EAP Authentication in IKEv2",
	draft-eronen-ipsec-ikev2-eap-auth-02 (work in progress),
	October 2004.
	[I-D.fluhrer-ted]		[I-D.fluhrer-ted]
	Fluhrer, S., "Tunnel Endpoint Discovery",		Fluhrer, S., "Tunnel Endpoint Discovery",
	draft-fluhrer-ted-00 (work in progress), November 2001.		draft-fluhrer-ted-00 (work in progress), November 2001.
	[I-D.ietf-aaa-eap]
	Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
	Authentication Protocol (EAP) Application",
	draft-ietf-aaa-eap-09 (work in progress), August 2004.
	[I-D.ietf-eap-keying]
	Aboba, B., "Extensible Authentication Protocol (EAP) Key
	Management Framework", draft-ietf-eap-keying-03 (work in
	progress), July 2004.
	[I-D.ietf-ipsec-ikev2-iana]
	Richardson, M., "Initial IANA registry contents",
	draft-ietf-ipsec-ikev2-iana-02 (work in progress), April
	2004.
	[I-D.ietf-ipsec-rfc2402bis]		[I-D.ietf-ipsec-rfc2402bis]
	Kent, S., "IP Authentication Header",		Kent, S., "IP Authentication Header",
	draft-ietf-ipsec-rfc2402bis-08 (work in progress), October		draft-ietf-ipsec-rfc2402bis-10 (work in progress),
	2004.		December 2004.
	[I-D.ietf-pana-ipsec]
	Parthasarathy, M., "PANA enabling IPsec based Access
	Control", draft-ietf-pana-ipsec-04 (work in progress),
	September 2004.
	[I-D.kivinen-mobike-design]		[I-D.palet-v6ops-tun-auto-disc]
	Kivinen, T., "Design of the MOBIKE protocol",		Palet, J. and M. Diaz, "Analysis of IPv6 Tunnel End-point
	draft-kivinen-mobike-design-00 (work in progress), March		Discovery Mechanisms", draft-palet-v6ops-tun-auto-disc-02
	2004.		(work in progress), October 2004.
	[I-D.touch-ipsec-vpn]		[I-D.touch-ipsec-vpn]
	Touch, J., Eggert, L. and Y. Wang, "Use of IPsec Transport		Touch, J., Eggert, L. and Y. Wang, "Use of IPsec Transport
	Mode for Dynamic Routing", draft-touch-ipsec-vpn-07 (work		Mode for Dynamic Routing", draft-touch-ipsec-vpn-07 (work
	in progress), March 2004.		in progress), March 2004.
	[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the		[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
	Internet Protocol", RFC 2401, November 1998.		Internet Protocol", RFC 2401, November 1998.
	[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address		[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
	Translator (NAT) Terminology and Considerations", RFC		(IKE)", RFC 2409, November 1998.
	2663, August 1999.
	[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
	"Remote Authentication Dial In User Service (RADIUS)", RFC
	2865, June 2000.
	[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
	Dial In User Service) Support For Extensible
	Authentication Protocol (EAP)", RFC 3579, September 2003.
	[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed		[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
	Networks", BCP 84, RFC 3704, March 2004.		Networks", BCP 84, RFC 3704, March 2004.
	[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation		[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
	(NAT) Compatibility Requirements", RFC 3715, March 2004.		(NAT) Compatibility Requirements", RFC 3715, March 2004.
	Authors' Addresses		Authors' Addresses
	Richard Graveman		Richard Graveman
End of changes. 74 change blocks.
	383 lines changed or deleted		298 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/