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/