draft-ietf-mpls-over-l2tpv3-00.txt		draft-ietf-mpls-over-l2tpv3-01.txt
	Network Working Group W. Mark Townsley		Network Working Group W. Mark Townsley
	Internet-Draft cisco Systems		Internet-Draft Carlos Pignataro
	<draft-ietf-mpls-over-l2tpv3-00.txt> Ted Seely		Expiration Date: August 2006 Scott Wainner
	February 2005 Sprint		cisco Systems
			Ted Seely
			Sprint
	Jeffery S. Young		Jeffery S. Young
	Alcatel		Alcatel
			February 2006
	Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3		Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3
			draft-ietf-mpls-over-l2tpv3-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, each author represents that any
	patent or other IPR claims of which I am aware have been disclosed,		applicable patent or other IPR claims of which he or she is aware
	and any of which I become aware will be disclosed, in accordance with		have been or will be disclosed, and any of which he or she becomes
	RFC 3668.		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
	other groups may also distribute working documents as		other groups may also distribute working documents as Internet-
	Internet-Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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/1id-abstracts.html
	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
	Copyright Notice
	Copyright (C) The Internet Society (2005). All Rights Reserved.
	Abstract		Abstract
	The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a		The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a
	protocol for tunneling a variety of payload types over IP networks.		protocol for tunneling a variety of payload types over IP networks.
	This document defines how to carry an MPLS label or label stack and		This document defines how to carry an MPLS label stack and its
	its payload over L2TPv3. This enables an application which		payload over L2TPv3. This enables an application which traditionally
	traditionally requires an MPLS-enabled core network to utilize an		requires an MPLS-enabled core network to utilize an L2TPv3
	L2TPv3 encapsulation over an IP network instead.		encapsulation over an IP network instead.
	Contents		Contents
	Status of this Memo.......................................... 1		Status of this Memo.......................................... 1
	1. Introduction.............................................. 2		1. Introduction.............................................. 2
	2. MPLS over L2TPv3 Encoding................................. 2		2. MPLS over L2TPv3 Encoding................................. 3
	3. Assigning the L2TPv3 Session ID and Cookie................ 4		3. Assigning the L2TPv3 Session ID and Cookie................ 4
	4. Applicability............................................. 4		4. Applicability............................................. 4
	5. Security Considerations................................... 5		5. Security Considerations................................... 6
			5.1 In the Absence of IPsec............................... 6
			5.2 Context Validation.................................... 7
			5.3 Securing the Tunnel with IPsec........................ 7
	6. IANA Considerations....................................... 6		6. IANA Considerations....................................... 8
	7. Acknowledgments........................................... 6		7. Acknowledgements.......................................... 8
	8. References................................................ 6		8. References................................................ 8
	8.1 Normative References.................................. 6		8.1 Normative References.................................. 8
	8.2 Informative References................................ 6		8.2 Informative References................................ 9
	9. Contacts.................................................. 6		9. Authors' Addresses........................................ 10
	Specification of Requirements		Specification of Requirements
	In this document, several words are used to signify the requirements		In this document, several words are used to signify the requirements
	of the specification. These words are often capitalized. The key		of the specification. These words are often capitalized. The key
	words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",		words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
	"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document		"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
	are to be interpreted as described in [RFC2119].		are to be interpreted as described in [RFC2119].
	1. Introduction		1. Introduction
	This document defines how to encapsulate an MPLS label or label stack		This document defines how to encapsulate an MPLS label stack and its
	and its payload over L2TPv3. After defining the MPLS over L2TPv3		payload over L2TPv3. After defining the MPLS over L2TPv3
	encapsulation procedure, other MPLS over IP encapsulation options		encapsulation procedure, other MPLS over IP encapsulation options
	including IP, GRE and IPsec are discussed in context with MPLS over		including IP, GRE and IPsec are discussed in context with MPLS over
	L2TPv3 in an Applicability section. This document only describes		L2TPv3 in an Applicability section. This document only describes
	encapsulation and does not concern itself with all possible MPLS-		encapsulation and does not concern itself with all possible MPLS-
	based applications which may be enabled over L2TPv3.		based applications which may be enabled over L2TPv3.
	2. MPLS over L2TPv3 Encoding		2. MPLS over L2TPv3 Encoding
	MPLS over L2TPv3 allows tunneling of an MPLS stack [RFC3032] over an		MPLS over L2TPv3 allows tunneling of an MPLS stack [RFC3032] and its
	IP network utilizing the L2TPv3 encapsulation defined in [RFC3931].		payload over an IP network utilizing the L2TPv3 encapsulation defined
	The MPLS Label Stack and payload is carried in its entirety after IP		in [RFC3931]. The MPLS Label Stack and payload are carried in their
	and L2TPv3.		entirety after IP (either IPv4 or IPv6) and L2TPv3.
	+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+
	| IP |		| IP |
	+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+
	| L2TPv3 |		| L2TPv3 |
	+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+
	| MPLS Label Stack |		| MPLS Label Stack |
	+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+
			| MPLS Payload |
			+-+-+-+-+-+-+-+-+-+-+
	Figure 2.1 MPLS Stack over L2TPv3/IP		Figure 2.1 MPLS Packet over L2TPv3/IP
	The L2TPv3 encapsulation carrying a single MPLS label is as follows:		The L2TPv3 encapsulation carrying a single MPLS label stack entry is
			as follows:
	0 1 2 3		0 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Session ID |		| Session ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Cookie (optional, maximum 64 bits)...		| Cookie (optional, maximum 64 bits)...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	... |		... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
	| Label | Exp |S| TTL | Stack		| Label | Exp |S| TTL | Stack
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry
	Figure 2.2 MPLS label over L2TPv3 encapsulation		Figure 2.2 MPLS over L2TPv3 encapsulation
	When encapsulating MPLS over L2TPv3, the L2TPv3 L2-Specific-Sublayer		When encapsulating MPLS over L2TPv3, the L2TPv3 L2-Specific-Sublayer
	MUST NOT be present. The L2TPv3 Session ID MUST be present. The		MAY be present. It is generally not present and hence not included
	Cookie MAY be present.		in Figure 2.2. The L2TPv3 Session ID MUST be present. The Cookie MAY
			be present.
	Session ID		Session ID
	The L2TPv3 Session ID is a 32-bit identifier field locally		The L2TPv3 Session ID is a 32-bit identifier field locally
	selected as a lookup key for the context of an L2TP Session. An		selected as a lookup key for the context of an L2TP Session. An
	L2TP Session contains necessary context for processing a received		L2TP Session contains necessary context for processing a received
	L2TP packet. At a minimum, such context contains whether the		L2TP packet. At a minimum, such context contains whether the
	Cookie (see description below) is present, the value it was		Cookie (see description below) is present, the value it was
	assigned, as well as what type of tunneled encapsulation follows		assigned, the presence and type of an L2TPv3 L2-Specific-Sublayer,
	(i.e., Frame Relay, Ethernet, MPLS, etc).		as well as what type of tunneled encapsulation follows (i.e.,
			Frame Relay, Ethernet, MPLS, etc.)
	Cookie		Cookie
	The L2TPv3 Cookie field contains a variable length (maximum 64		The L2TPv3 Cookie field contains a variable length (maximum 64
	bits) randomly assigned value. It is intended to provide an		bits) randomly assigned value. It is intended to provide an
	additional level of guarantee that a data packet has been directed		additional level of guarantee that a data packet has been directed
	to the proper L2TP session by the Session ID. While the Session		to the proper L2TP session by the Session ID. While the Session
	ID may be encoded and assigned any value (perhaps optimizing for		ID may be encoded and assigned any value (perhaps optimizing for
	local lookup capabilities, redirection in a distributed forwarding		local lookup capabilities, redirection in a distributed forwarding
	architecture, etc.), the Cookie MUST be selected as a		architecture, etc.), the Cookie MUST be selected as a
	cryptographically random value [RFC1750], with the added		cryptographically random value [RFC4086], with the added
	restriction that it not be the same as a recently used value for a		restriction that it not be the same as a recently used value for a
	given Session ID. A well-chosen Cookie will prevent inadvertent		given Session ID. A well-chosen Cookie will prevent inadvertent
	misdirection of a stray packet containing a recently reused		misdirection of a stray packet containing a recently reused
	Session ID, a Session ID that is subject to packet corruption, and		Session ID, a Session ID that is subject to packet corruption, and
	protection against some specific malicious packet insertion		protection against some specific malicious packet insertion
	attacks as described in more detail in Section 4 of this document.		attacks as described in more detail in Section 4 of this document.
	Label Stack Entry		Label Stack Entry
	An MPLS label as defined in [RFC3032].		An MPLS label stack entry as defined in [RFC3032].
	The optional L2-Specific-Sublayer defined in [RFC3931] is generally		The optional L2-Specific-Sublayer defined in [RFC3931] is generally
	not present for MPLS over L2TPv3.		not present for MPLS over L2TPv3.
	Generic IP encapsulation procedures such as MTU considerations,		Generic IP encapsulation procedures such as fragmentation and MTU
	handling of TTL, EXP and DSCP bits, etc. are the same as the "Common		considerations, handling of TTL, EXP and DSCP bits, etc. are the same
	Procedures" for IP encapsulation of MPLS defined in Section 5 of		as the "Common Procedures" for IP encapsulation of MPLS defined in
	[MPLS-IP-GRE] and are not reiterated here.		Section 5 of [RFC4023] and are not reiterated here.
	3. Assigning the L2TPv3 Session ID and Cookie		3. Assigning the L2TPv3 Session ID and Cookie
	Much like an MPLS label, the L2TPv3 Session ID and Cookie must be		Much like an MPLS label, the L2TPv3 Session ID and Cookie must be
	selected and exchanged between participating nodes before L2TPv3 can		selected and exchanged between participating nodes before L2TPv3 can
	operate. These values may be configured manually, or distributed via		operate. These values may be configured manually, or distributed via
	a signaling protocol. This document concerns itself only with the		a signaling protocol. This document concerns itself only with the
	encapsulation of MPLS over L2TPv3, thus the particular method of		encapsulation of MPLS over L2TPv3, thus the particular method of
	assigning the Session ID and Cookie is out of scope.		assigning the Session ID and Cookie is out of scope.
	4. Applicability		4. Applicability
	The methods defined [MPLS-IP-GRE], [MPLS-IPSEC] and this document all		The methods defined [RFC4023], [MPLS-IPSEC] and this document all
	describe methods for carrying MPLS over an IP network. Cases where		describe methods for carrying MPLS over an IP network. Cases where
	MPLS over L2TPv3 may be applicable compared to other alternatives are		MPLS over L2TPv3 may be applicable compared to other alternatives are
	discussed in this section.		discussed in this section.
	It is generally simpler to have one's border routers refuse to accept		It is generally simpler to have one's border routers refuse to accept
	an MPLS packet than to configure a router to refuse to accept certain		an MPLS packet than to configure a router to refuse to accept certain
	MPLS packets carried in IP or GRE to or from certain IP sources or		MPLS packets carried in IP or GRE to or from certain IP sources or
	destinations. Thus, the use of IP or GRE to carry MPLS labels		destinations. Thus, the use of IP or GRE to carry MPLS packets
	increases the opportunity for MPLS label spoofing attacks. L2TPv3		increases the opportunity for MPLS label spoofing attacks. L2TPv3
	provides an additional level of protection against packet spoofing		provides an additional level of protection against packet spoofing
	before allowing a packet to enter a VPN (much like IPsec provides an		before allowing a packet to enter a VPN (much like IPsec provides an
	additional level of protection at a PE rather than relying on ACL		additional level of protection at a PE rather than relying on ACL
	filters). Checking the value of the L2TPv3 Cookie is similar to any		filters). Checking the value of the L2TPv3 Cookie is similar to any
	sort of ACL which inspects the contents of a packet header, except		sort of ACL which inspects the contents of a packet header, except
	that we give ourselves the luxury of "seeding" the L2TPv3 header with		that we give ourselves the luxury of "seeding" the L2TPv3 header with
	a very difficult to spoof value.		a very difficult to spoof value.
	MPLS over L2TPv3 may be favorable compared to [MPLS-IP-GRE], if:		MPLS over L2TPv3 may be favorable compared to [RFC4023], if:
	Two routers are "adjacent" over an L2TPv3 tunnel that exists for		Two routers are "adjacent" over an L2TPv3 tunnel that exists for
	some reason outside the scope of this document, and those two		some reason outside the scope of this document, and those two
	routers need to send MPLS packets over that adjacency.		routers need to send MPLS packets over that adjacency.
	Implementation considerations dictate the use of MPLS over L2TPv3.		Implementation considerations dictate the use of MPLS over L2TPv3.
	For example, a hardware device may be able to take advantage of		For example, a hardware device may be able to take advantage of
	the L2TPv3 encapsulation for faster processing.		the L2TPv3 encapsulation for faster or distributed processing.
	Packet spoofing and insertion is of concern. The L2TPv3 Cookie		Packet spoofing and insertion, service integrity and resource
	allows simple validation, over and above that of IP ACLs, of the		protection are of concern, especially given the fact that an IP
	source of an L2TPv3 packet before allowing processing to continue.		tunnel potentially exposes the router to rogue or inappropriate IP
			packets from unknown or untrusted sources. IP ACLs and numbering
			methods may be used to protect the PEs from rogue IP sources, but
			may be subject to error and cumbersome to maintain at all edge
			points at all times. The L2TPv3 Cookie provides a simple means of
			validating the source of an L2TPv3 packet before allowing
			processing to continue. This validation offers an additional level
			of protection over and above IP ACLs, and a validation that the
			Session ID was not corrupted in transit or suffered an internal
			lookup error upon receipt and processing. If the Cookie value is
			assigned and distributed automatically, it is less subject to
			operator error, and if selected in a cryptographically random
			nature, less subject to blind guesses than source IP addresses (in
			the event that a hacker can insert packets within a VPN core
			network).
	(The first two of the above applicability statements were adopted		(The first two of the above applicability statements were adopted
	from [MPLS-IP-GRE])		from [RFC4023])
	In summary, L2TPv3 can provide a balance between the limited security		In summary, L2TPv3 can provide a balance between the limited security
	against IP spoofing attacks offered by [MPLS-IP-GRE] vs. the greater		against IP spoofing attacks offered by [RFC4023] vs. the greater
	security and associated operational and processing overhead offered		security and associated operational and processing overhead offered
	by [MPLS-IPSEC]. Further, MPLS over L2TPv3 may be faster in some		by [MPLS-IPSEC]. Further, MPLS over L2TPv3 may be faster in some
	hardware, particularly if it is already optimized to classify		hardware, particularly if it is already optimized to classify
	incoming L2TPv3 packets carrying IP framed in a variety of ways. For		incoming L2TPv3 packets carrying IP framed in a variety of ways. For
	example, IP encapsulated by HDLC or Frame Relay over L2TPv3 may be		example, IP encapsulated by HDLC or Frame Relay over L2TPv3 may be
	considered not that far removed from IP encapsulated by MPLS over		considered not that far removed from IP encapsulated by MPLS over
	L2TPv3.		L2TPv3.
	5. Security Considerations		5. Security Considerations
			There are three main concerns when transporting MPLS labeled traffic
			between PEs using IP tunnels. The first is the possibility that a
			third party may insert packets into a packet stream between two PEs.
			The second is that a third party might view the packet stream between
			two PEs. The third is that a third party may alter packets in a
			stream between two PEs. The security requirements of the
			applications whose traffic is being sent through the tunnel
			characterizes how significant these issues are. Operators may use
			multiple methods to mitigate the risk including access lists,
			authentication, encryption, and context validation. Operators needs
			to consider the cost to mitigate the risk.
			Security is also discussed as part of the applicability discussion in
			section 4 of this document.
			5.1 In the Absence of IPsec
			If the tunnels are not secured with IPsec, then some other method
			should be used to ensure that packets are decapsulated and processed
			by the tunnel tail only if those packets were encapsulated by the
			tunnel head. If the tunnel lies entirely within a single
			administrative domain, address filtering at the boundaries can be
			used to ensure that no packet with the IP source address of a tunnel
			endpoint or with the IP destination address of a tunnel endpoint can
			enter the domain from outside.
			However, when the tunnel head and the tunnel tail are not in the same
			administrative domain, this may become difficult, and filtering based
			on the destination address can even become impossible if the packets
			must traverse the public Internet.
			Sometimes only source address filtering (but not destination address
			filtering) is done at the boundaries of an administrative domain. If
			this is the case, the filtering does not provide effective protection
			at all unless the decapsulator of MPLS over L2TPv3 validates the IP
			source address of the packet.
			Additionally, the "Data Packet Spoofing" considerations in Section
			8.2. of [RFC3931] and the "Context Validation" considerations in
			Section 5.2 of this document apply. Those two sections highlight the
			benefits of the L2TPv3 Cookie.
			5.2 Context Validation
	The L2TPv3 Cookie does not provide protection via encryption.		The L2TPv3 Cookie does not provide protection via encryption.
	However, when used with a sufficiently random 64-bit value which is		However, when used with a sufficiently random 64-bit value which is
	kept secret from a hacker, the L2TPv3 Cookie may be used as a simple		kept secret from a hacker, the L2TPv3 Cookie may be used as a simple
	yet effective packet source authentication check which is quite		yet effective packet source authentication check which is quite
	resistent to brute force packet spoofing attacks. It also alleviates		resistant to brute force packet spoofing attacks. It also alleviates
	the need to rely solely on filter lists based on a list of valid		the need to rely solely on filter lists based on a list of valid
	source IP addresses, and thwarts attacks which could benefit by		source IP addresses, and thwarts attacks which could benefit by
	spoofing a permitted source IP address.		spoofing a permitted source IP address. The L2TPv3 Cookie provides a
			means of validating the currently assigned Session ID on the packet
			flow, providing context protection, and may be deemed complimentary
			to securing the tunnel utilizing IPsec. In the absence of
			cryptographic security on the data plane (such as that provided by
			IPsec), the L2TPv3 Cookie provides a simple method of validating the
			Session ID lookup performed on each L2TPv3 packet. If the Cookie is
			sufficiently random and remains unknown to an attacker (that is, the
			attacker has no way to predict Cookie values or monitor traffic
			between PEs) then the Cookie provides an additional measure of
			protection against malicious spoofed packets inserted at the PE over
			and above that of typical IP address and port ACLs.
	L2TPv3 tunnels may also be secured using IPsec. When using IPsec,		5.3 Securing the Tunnel with IPsec
			L2TPv3 tunnels may also be secured using IPsec, as specified in
			Section 4.1.3. of [RFC3931]. IPSec may provide authentication,
			privacy protection, integrity checking and replay protection. These
			functions may be deemed necessary by the operator. When using IPsec,
	the tunnel head and the tunnel tail should be treated as the		the tunnel head and the tunnel tail should be treated as the
	endpoints of a Security Association. The MPLS over L2TPv3		endpoints of a Security Association. A single IP address of the
	encapsulated packets should be considered as originating at the		tunnel head is used as the source IP address, and a single IP address
	tunnel head and as being destined for the tunnel tail; IPsec		of the tunnel tail is used as the destination IP address. The means
	transport mode should thus be used. Key distribution may be done		by which each node knows the proper address of the other is outside
	either manually or automatically.		the scope of this document. However, if a control protocol is used
			to set up the tunnels, such control protocol MUST have an
			authentication mechanism, and this MUST be used when the tunnel is
			set up. If the tunnel is set up automatically as the result of, for
			example, information distributed by BGP, then the use of BGP's MD5-
			based authentication mechanism can serve this purpose.
	Security is also discussed as part of the applicability discussion in		The MPLS over L2TPv3 encapsulated packets should be considered as
	section 4 of this document.		originating at the tunnel head and as being destined for the tunnel
			tail; IPsec transport mode SHOULD thus be used.
			Note that the tunnel tail and the tunnel head are LSP adjacencies
			(label distribution adjacencies, see [RFC3031]), which means that the
			topmost label of any packet sent through the tunnel must be one that
			was distributed by the tunnel tail to the tunnel head. The tunnel
			tail MUST know precisely which labels it has distributed to the
			tunnel heads of IPsec-secured tunnels. Labels in this set MUST NOT
			be distributed by the tunnel tail to any LSP adjacencies other than
			those that are tunnel heads of IPsec-secured tunnels. If an MPLS
			packet is received without an IPsec encapsulation, and if its topmost
			label is in this set, then the packet MUST be discarded.
			Securing L2TPv3 using IPsec MUST provide authentication and
			integrity. (Note that the authentication and integrity provided will
			apply to the entire MPLS packet, including the MPLS label stack.)
			Consequently, the implementation MUST support ESP with null
			encryption. ESP with encryption MAY be supported if a source
			requires confidentiality. If ESP is used, the tunnel tail MUST check
			that the source IP address of any packet received on a given SA is
			the one expected.
			Key distribution may be done either manually or automatically by
			means of IKE [RFC2409]. Manual keying MUST be supported. If
			automatic keying is implemented, IKE in main mode with preshared keys
			MUST be supported. A particular application may escalate this
			requirement and request implementation of automatic keying. Manual
			key distribution is much simpler, but also less scalable, than
			automatic key distribution. If replay protection is regarded as
			necessary for a particular tunnel, automatic key distribution should
			be configured.
	6. IANA Considerations		6. IANA Considerations
	There are no IANA considerations for this document.		There are no IANA considerations for this document.
	7. Acknowledgments		7. Acknowledgements
	Thanks to Robert Raszuk, Clarence Filsfils and Eric Rosen for their		Thanks to Robert Raszuk, Clarence Filsfils and Eric Rosen for their
	review of this document. Some text was adopted from [MPLS-IP-GRE].		review of this document. Some text was adopted from [RFC4023].
	8. References		8. References
	8.1 Normative References		8.1 Normative References
	[RFC3931] J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling		[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two
	Protocol (Version 3)", work in progress,		Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931,
	draft-ietf-l2tpext-l2tp-base-15.txt, December 2004.		March 2005.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[MPLS-IP-GRE] T. Worster, Y. Rekhter, E. Rosen, "Encapsulating		[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating
	MPLS in IP or Generic Routing Encapsulation (GRE)",		MPLS in IP or Generic Routing Encapsulation (GRE)",
	work in progress, draft-ietf-mpls-in-ip-or-gre-08.txt,		RFC 4023, March 2005.
	June 2004.
	8.2 Informative References		8.2 Informative References
	[RFC2547] E. Rosen, Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999.		[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
			Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
			Encoding", RFC 3032, January 2001.
	[RFC3032] R. Rosen, et. al., "MPLS Label Stack Encoding," RFC 3032,		[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
	January 2001.		Requirements for Security", BCP 106, RFC 4086,
			June 2005.
	[MPLS-IPSEC] E. Rosen, J. De Clercq, O/ Paridaens, Y. T'Joens,		[MPLS-IPSEC] Rosen, E., "Architecture for the Use of PE-PE IPsec
	C. Sargor, "Use of PE-PE IPsec in RFC2547 VPNs",		Tunnels in BGP/MPLS IP VPNs",
	work in progress, draft-ietf-l3vpn-ipsec-2547-01.txt,		draft-ietf-l3vpn-ipsec-2547-05 (work in progress),
	August 2003.		August 2005.
	9. Contacts		[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
			(IKE)", RFC 2409, November 1998.
			[RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
			"Multiprotocol Label Switching Architecture", RFC 3031,
			January 2001.
			9. Authors' Addresses
	W. Mark Townsley		W. Mark Townsley
	cisco Systems		cisco Systems
	mark@townsley.net
			EMail: mark@townsley.net
			Carlos Pignataro
			cisco Systems
			7025 Kit Creek Road
			PO Box 14987
			Research Triangle Park, NC 27709
			EMail: cpignata@cisco.com
			Scott Wainner
			cisco Systems
			13600 Dulles Technology Drive
			Herndon, VA 20171
			EMail: swainner@cisco.com
	Ted Seely		Ted Seely
	Sprint		Sprint
	tseely@sprint.net
			EMail: tseely@sprint.net
	Jeffrey S. Young		Jeffrey S. Young
	Alcatel		Alcatel
	Jeffrey.S.Young@alcatel.com
			EMail: Jeffrey.S.Young@alcatel.com
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	skipping to change at page 7, line 38		skipping to change at page 11, line 31
	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.
	Disclaimer of Validity		Disclaimer of Validity
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2004). This document is subject		Copyright (C) The Internet Society (2006).
	to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		This document is subject to the rights, licenses and restrictions
			contained in BCP 78, and except as set forth therein, the authors
			retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 53 change blocks.
	94 lines changed or deleted		244 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/