draft-ietf-mpls-over-l2tpv3-01.txt   draft-ietf-mpls-over-l2tpv3-02.txt 
Network Working Group W. Mark Townsley Network Working Group M. Townsley
Internet-Draft Carlos Pignataro Internet-Draft C. Pignataro
Expiration Date: August 2006 Scott Wainner Expiration Date: April 2007 S. Wainner
cisco Systems cisco Systems
Ted Seely T. Seely
Sprint Sprint Nextel
Jeffery S. Young J. Young
Alcatel
February 2006 October 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 draft-ietf-mpls-over-l2tpv3-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 46 skipping to change at page 1, line 45
http://www.ietf.org/1id-abstracts.html 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
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 stack and its This document defines how to carry an MPLS label stack and its
payload over L2TPv3. This enables an application which traditionally payload over the L2TPv3 data encapsulation. This enables an
requires an MPLS-enabled core network to utilize an L2TPv3 application which traditionally requires an MPLS-enabled core network
encapsulation over an IP network instead. to utilize an L2TPv3 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................................. 3 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................................... 6 5. Congestion 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....................................... 8 6. Security Considerations................................... 6
6.1 In the Absence of IPsec............................... 7
6.2 Context Validation.................................... 7
6.3 Securing the Tunnel with IPsec........................ 8
7. Acknowledgements.......................................... 8 7. IANA Considerations....................................... 9
8. References................................................ 8 8. Acknowledgements.......................................... 9
8.1 Normative References.................................. 8
8.2 Informative References................................ 9
9. Authors' Addresses........................................ 10 9. References................................................ 9
9.1 Normative References.................................. 9
9.2 Informative References................................ 9
10. Authors' Addresses....................................... 11
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 stack and its This document defines how to encapsulate an MPLS label stack and its
payload over L2TPv3. After defining the MPLS over L2TPv3 payload inside the L2TPv3 tunnel payload. After defining the MPLS
encapsulation procedure, other MPLS over IP encapsulation options over L2TPv3 encapsulation procedure, other MPLS over IP encapsulation
including IP, GRE and IPsec are discussed in context with MPLS over options including IP, GRE and IPsec are discussed in context with
L2TPv3 in an Applicability section. This document only describes MPLS over L2TPv3 in an Applicability section. This document only
encapsulation and does not concern itself with all possible MPLS- describes encapsulation and does not concern itself with all possible
based applications which may be enabled over L2TPv3. MPLS-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] and its MPLS over L2TPv3 allows tunneling of an MPLS stack [RFC3032] and its
payload over an IP network utilizing the L2TPv3 encapsulation defined payload over an IP network utilizing the L2TPv3 encapsulation defined
in [RFC3931]. The MPLS Label Stack and payload are carried in their in [RFC3931]. The MPLS Label Stack and payload are carried in their
entirety after IP (either IPv4 or IPv6) and L2TPv3. entirety following IP (either IPv4 or IPv6) and L2TPv3 headers.
+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+
| IP | | IP |
+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+
| L2TPv3 | | L2TPv3 |
+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+
| MPLS Label Stack | | MPLS Label Stack |
+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+
| MPLS Payload | | MPLS Payload |
+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+
skipping to change at page 3, line 41 skipping to change at page 3, line 41
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 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
MAY be present. It is generally not present and hence not included MAY be present. It is generally not present and hence not included
in Figure 2.2. The L2TPv3 Session ID MUST be present. The Cookie MAY in Figure 2.2. The L2TPv3 Session ID MUST be present. The Cookie MAY
be present. 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, the presence and type of an L2TPv3 L2-Specific-Sublayer, assigned, the presence and type of an L2TPv3 L2-Specific Sublayer,
as well as what type of tunneled encapsulation follows (i.e., as well as what type of tunneled encapsulation follows (i.e.,
Frame Relay, Ethernet, MPLS, etc.) 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
skipping to change at page 4, line 29 skipping to change at page 4, line 29
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 stack entry 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 fragmentation and MTU Generic IP encapsulation procedures such as fragmentation and MTU
considerations, handling of TTL, EXP and DSCP bits, etc. are the same considerations, handling of TTL, EXP and DSCP bits, etc. are the same
as the "Common Procedures" for IP encapsulation of MPLS defined in as the "Common Procedures" for IP encapsulation of MPLS defined in
Section 5 of [RFC4023] 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 (if present) is out of scope.
4. Applicability 4. Applicability
The methods defined [RFC4023], [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 is comparable to other alternatives are discussed in
discussed in this section. 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 packets destinations. Thus, the use of IP or GRE to carry MPLS packets
increases the opportunity for MPLS label spoofing attacks. L2TPv3 increases the likelihood that an MPLS label spoofing attack will
provides an additional level of protection against packet spoofing succeed. L2TPv3 provides an additional level of protection against
before allowing a packet to enter a VPN (much like IPsec provides an packet spoofing before allowing a packet to enter a VPN (much like
additional level of protection at a PE rather than relying on ACL IPsec provides an additional level of protection at a Provider Edge
(PE) router rather than relying on Access Control List (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 value that is very difficult to spoof.
MPLS over L2TPv3 may be favorable compared to [RFC4023], if: MPLS over L2TPv3 may be advantageous compared to [RFC4023], if:
Two routers are "adjacent" over an L2TPv3 tunnel that exists for Two routers are already "adjacent" over an L2TPv3 tunnel
some reason outside the scope of this document, and those two established for some other reason, and wish to exchange MPLS
routers need to send MPLS packets over that adjacency. 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 or distributed processing. the L2TPv3 encapsulation for faster or distributed processing.
Packet spoofing and insertion, service integrity and resource Packet spoofing and insertion, service integrity and resource
protection are of concern, especially given the fact that an IP protection are of concern, especially given the fact that an IP
tunnel potentially exposes the router to rogue or inappropriate IP tunnel potentially exposes the router to rogue or inappropriate IP
packets from unknown or untrusted sources. IP ACLs and numbering packets from unknown or untrusted sources. IP Access Control
methods may be used to protect the PEs from rogue IP sources, but Lists (ACLs) and numbering methods may be used to protect the
may be subject to error and cumbersome to maintain at all edge Provider Edge (PE) routers from rogue IP sources, but may be
points at all times. The L2TPv3 Cookie provides a simple means of 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 validating the source of an L2TPv3 packet before allowing
processing to continue. This validation offers an additional level processing to continue. This validation offers an additional level
of protection over and above IP ACLs, and a validation that the of protection over and above IP ACLs, and a validation that the
Session ID was not corrupted in transit or suffered an internal Session ID was not corrupted in transit or suffered an internal
lookup error upon receipt and processing. If the Cookie value is lookup error upon receipt and processing. If the Cookie value is
assigned and distributed automatically, it is less subject to assigned and distributed automatically, it is less subject to
operator error, and if selected in a cryptographically random operator error, and if selected in a cryptographically random
nature, less subject to blind guesses than source IP addresses (in nature, less subject to blind guesses than source IP addresses (in
the event that a hacker can insert packets within a VPN core the event that a hacker can insert packets within a VPN core
network). network).
(The first two of the above applicability statements were adopted (The first two of the above applicability statements were adopted
from [RFC4023]) 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 [RFC4023] 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 that hardware is already optimized to
incoming L2TPv3 packets carrying IP framed in a variety of ways. For classify incoming L2TPv3 packets carrying IP framed in a variety of
example, IP encapsulated by HDLC or Frame Relay over L2TPv3 may be ways. For example, IP encapsulated by HDLC or Frame Relay over L2TPv3
considered not that far removed from IP encapsulated by MPLS over may be equivalent in complexity to IP encapsulated by MPLS over
L2TPv3. L2TPv3.
5. Security Considerations 5. Congestion Considerations
This document specifies an encapsulation method for MPLS inside the
L2TPv3 tunnel payload. MPLS can carry a number of different protocols
as payloads. When an MPLS/L2TPv3 flow carries IP-based traffic, the
aggregate traffic is assumed to be TCP friendly due to the congestion
control mechanisms used by the payload traffic. Packet loss will
trigger the necessary reduction in offered load, and no additional
congestion avoidance action is necessary.
When an MPLS/L2TPv3 flow carries payload traffic that is not known to
be TCP friendly and the flow runs across an unprovisioned path, the
application that uses the encapsulation specified in this document
MUST employ additional mechanisms to ensure that the offered load is
reduced appropriately during periods of congestion. The MPLS/L2TPv3
flow should not exceed the average bandwidth that a TCP flow across
the same network path and experiencing the same network conditions
would achieve, measured on a reasonable timescale.
The comparison to TCP cannot be specified exactly but is intended as
an "order-of-magnitude" comparison in timescale and throughput. The
timescale on which TCP throughput is measured is the round-trip time
of the connection. In essence, this requirement states that it is not
acceptable to deploy an application using the encapsulation specified
in this document on the best-effort Internet, which consumes
bandwidth arbitrarily and does not compete fairly with TCP within an
order of magnitude. One method of determining an acceptable bandwidth
is described in [RFC3448]. Other methods exist, but are outside the
scope of this document.
6. Security Considerations
There are three main concerns when transporting MPLS labeled traffic There are three main concerns when transporting MPLS labeled traffic
between PEs using IP tunnels. The first is the possibility that a between PEs using IP tunnels. The first is the possibility that a
third party may insert packets into a packet stream between two PEs. 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 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 two PEs. The third is that a third party may alter packets in a
stream between two PEs. The security requirements of the stream between two PEs. The security requirements of the
applications whose traffic is being sent through the tunnel applications whose traffic is being sent through the tunnel
characterizes how significant these issues are. Operators may use characterizes how significant these issues are. Operators may use
multiple methods to mitigate the risk including access lists, multiple methods to mitigate the risk including access lists,
authentication, encryption, and context validation. Operators needs authentication, encryption, and context validation. Operators should
to consider the cost to mitigate the risk. consider the cost to mitigate the risk.
Security is also discussed as part of the applicability discussion in Security is also discussed as part of the applicability discussion in
section 4 of this document. section 4 of this document.
5.1 In the Absence of IPsec 6.1 In the Absence of IPsec
If the tunnels are not secured with IPsec, then some other method If the tunnels are not secured with IPsec, then some other method
should be used to ensure that packets are decapsulated and processed should be used to ensure that packets are decapsulated and processed
by the tunnel tail only if those packets were encapsulated by the by the tunnel tail only if those packets were encapsulated by the
tunnel head. If the tunnel lies entirely within a single tunnel head. If the tunnel lies entirely within a single
administrative domain, address filtering at the boundaries can be administrative domain, address filtering at the boundaries can be
used to ensure that no packet with the IP source address of a tunnel 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 endpoint or with the IP destination address of a tunnel endpoint can
enter the domain from outside. enter the domain from outside.
skipping to change at page 7, line 6 skipping to change at page 7, line 38
filtering) is done at the boundaries of an administrative domain. If filtering) is done at the boundaries of an administrative domain. If
this is the case, the filtering does not provide effective protection this is the case, the filtering does not provide effective protection
at all unless the decapsulator of MPLS over L2TPv3 validates the IP at all unless the decapsulator of MPLS over L2TPv3 validates the IP
source address of the packet. source address of the packet.
Additionally, the "Data Packet Spoofing" considerations in Section Additionally, the "Data Packet Spoofing" considerations in Section
8.2. of [RFC3931] and the "Context Validation" considerations in 8.2. of [RFC3931] and the "Context Validation" considerations in
Section 5.2 of this document apply. Those two sections highlight the Section 5.2 of this document apply. Those two sections highlight the
benefits of the L2TPv3 Cookie. benefits of the L2TPv3 Cookie.
5.2 Context Validation 6.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 an off-path attacker, the L2TPv3 Cookie may be used
yet effective packet source authentication check which is quite as a simple yet effective packet source authentication check which is
resistant to brute force packet spoofing attacks. It also alleviates quite resistant to brute force packet spoofing attacks. It also
the need to rely solely on filter lists based on a list of valid alleviates the need to rely solely on filter lists based on a list of
source IP addresses, and thwarts attacks which could benefit by valid source IP addresses, and thwarts attacks which could benefit by
spoofing a permitted source IP address. The L2TPv3 Cookie provides a spoofing a permitted source IP address. The L2TPv3 Cookie provides a
means of validating the currently assigned Session ID on the packet means of validating the currently assigned Session ID on the packet
flow, providing context protection, and may be deemed complimentary flow, providing context protection, and may be deemed complimentary
to securing the tunnel utilizing IPsec. In the absence of to securing the tunnel utilizing IPsec. In the absence of
cryptographic security on the data plane (such as that provided by cryptographic security on the data plane (such as that provided by
IPsec), the L2TPv3 Cookie provides a simple method of validating the IPsec), the L2TPv3 Cookie provides a simple method of validating the
Session ID lookup performed on each L2TPv3 packet. If the Cookie is Session ID lookup performed on each L2TPv3 packet. If the Cookie is
sufficiently random and remains unknown to an attacker (that is, the sufficiently random and remains unknown to an attacker (that is, the
attacker has no way to predict Cookie values or monitor traffic attacker has no way to predict Cookie values or monitor traffic
between PEs) then the Cookie provides an additional measure of between PEs) then the Cookie provides an additional measure of
protection against malicious spoofed packets inserted at the PE over protection against malicious spoofed packets inserted at the PE over
and above that of typical IP address and port ACLs. and above that of typical IP address and port ACLs.
5.3 Securing the Tunnel with IPsec 6.3 Securing the Tunnel with IPsec
L2TPv3 tunnels may also be secured using IPsec, as specified in L2TPv3 tunnels may also be secured using IPsec, as specified in
Section 4.1.3. of [RFC3931]. IPSec may provide authentication, Section 4.1.3. of [RFC3931]. IPSec may provide authentication,
privacy protection, integrity checking and replay protection. These privacy protection, integrity checking and replay protection. These
functions may be deemed necessary by the operator. When using IPsec, 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. A single IP address of the endpoints of a Security Association. A single IP address of the
tunnel head is used as the source IP address, and a single IP address tunnel head is used as the source IP address, and a single IP address
of the tunnel tail is used as the destination IP address. The means of the tunnel tail is used as the destination IP address. The means
by which each node knows the proper address of the other is outside by which each node knows the proper address of the other is outside
skipping to change at page 8, line 23 skipping to change at page 9, line 7
Securing L2TPv3 using IPsec MUST provide authentication and Securing L2TPv3 using IPsec MUST provide authentication and
integrity. (Note that the authentication and integrity provided will integrity. (Note that the authentication and integrity provided will
apply to the entire MPLS packet, including the MPLS label stack.) apply to the entire MPLS packet, including the MPLS label stack.)
Consequently, the implementation MUST support ESP with null Consequently, the implementation MUST support ESP with null
encryption. ESP with encryption MAY be supported if a source encryption. ESP with encryption MAY be supported if a source
requires confidentiality. If ESP is used, the tunnel tail MUST check 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 that the source IP address of any packet received on a given SA is
the one expected. the one expected.
Key distribution may be done either manually or automatically by Key distribution may be done either manually or automatically by
means of IKE [RFC2409]. Manual keying MUST be supported. If means of IKE [RFC2409] or IKEv2 [RFC4306]. Manual keying MUST be
automatic keying is implemented, IKE in main mode with preshared keys supported. If automatic keying is implemented, IKE in main mode with
MUST be supported. A particular application may escalate this preshared keys MUST be supported. A particular application may
requirement and request implementation of automatic keying. Manual escalate this requirement and request implementation of automatic
key distribution is much simpler, but also less scalable, than keying. Manual key distribution is much simpler, but also less
automatic key distribution. If replay protection is regarded as scalable, than automatic key distribution. If replay protection is
necessary for a particular tunnel, automatic key distribution should regarded as necessary for a particular tunnel, automatic key
be configured. distribution should be configured.
6. IANA Considerations 7. IANA Considerations
There are no IANA considerations for this document. There are no IANA considerations for this document.
7. Acknowledgements 8. 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 [RFC4023]. review of this document. Some text was adopted from [RFC4023].
8. References 9. References
8.1 Normative References 9.1 Normative References
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two
Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931,
March 2005. 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.
[RFC4023] Worster, T., Rekhter, Y., and 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)",
RFC 4023, March 2005. RFC 4023, March 2005.
8.2 Informative References 9.2 Informative References
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001. Encoding", RFC 3032, January 2001.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, Requirements for Security", BCP 106, RFC 4086,
June 2005. June 2005.
[MPLS-IPSEC] Rosen, E., "Architecture for the Use of PE-PE IPsec [MPLS-IPSEC] Rosen, E., "Architecture for the Use of PE-PE IPsec
Tunnels in BGP/MPLS IP VPNs", Tunnels in BGP/MPLS IP VPNs",
draft-ietf-l3vpn-ipsec-2547-05 (work in progress), draft-ietf-l3vpn-ipsec-2547-05 (work in progress),
August 2005. August 2005.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, [RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture", RFC 3031, "Multiprotocol Label Switching Architecture", RFC 3031,
January 2001. January 2001.
9. Authors' Addresses [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification",
RFC 3448, January 2003.
10. Authors' Addresses
W. Mark Townsley W. Mark Townsley
cisco Systems cisco Systems
Phone: +1-919-392-3741
EMail: mark@townsley.net EMail: mark@townsley.net
Carlos Pignataro Carlos Pignataro
cisco Systems cisco Systems
7025 Kit Creek Road 7025 Kit Creek Road
PO Box 14987 PO Box 14987
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
Phone: +1-919-392-7428
EMail: cpignata@cisco.com EMail: cpignata@cisco.com
Scott Wainner Scott Wainner
cisco Systems cisco Systems
13600 Dulles Technology Drive 13600 Dulles Technology Drive
Herndon, VA 20171 Herndon, VA 20171
EMail: swainner@cisco.com EMail: swainner@cisco.com
Ted Seely Ted Seely
Sprint Sprint Nextel
12502 Sunrise Valley Dr
Reston, VA 20196
Phone: +1-703-689-6425
EMail: tseely@sprint.net EMail: tseely@sprint.net
Jeffrey S. Young Jeff Young
Alcatel
EMail: Jeffrey.S.Young@alcatel.com EMail: young@jsyoung.net
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 11, line 33 skipping to change at page 12, line 33
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 This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
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. 45 change blocks. 
90 lines changed or deleted 135 lines changed or added

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