< draft-dasmith-mpls-ip-options-00.txt   draft-dasmith-mpls-ip-options-01.txt >
Network Working Group David J. Smith Network Working Group David J. Smith
Internet Draft John Mullooly Internet Draft John Mullooly
Intended status: Proposed Standard Cisco Systems, Inc. Intended status: Proposed Standard Cisco Systems, Inc.
Expiration Date: December 2008 Expiration Date: April 2009
William Jaeger William Jaeger
Tom Scholl
AT&T AT&T
June 30, 2008 Tom Scholl
AT&T Labs
October 6, 2008
Requirements for Label Edge Router Forwarding of IPv4 Option Packets Requirements for Label Edge Router Forwarding of IPv4 Option Packets
draft-dasmith-mpls-ip-options-00.txt draft-dasmith-mpls-ip-options-01.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 2, line 8 skipping to change at page 2, line 10
specifying that when determining whether to MPLS encapsulate an IP specifying that when determining whether to MPLS encapsulate an IP
packet, the determination is made independent of any IP options that packet, the determination is made independent of any IP options that
may be carried in the IP packet header. Lack of a formal standard may be carried in the IP packet header. Lack of a formal standard
may result in a different forwarding behavior for different IP may result in a different forwarding behavior for different IP
packets associated with the same prefix-based Forwarding Equivalence packets associated with the same prefix-based Forwarding Equivalence
Class (FEC). While an IP packet with either a specific option type Class (FEC). While an IP packet with either a specific option type
or no header option may follow the MPLS label switched path (LSP) or no header option may follow the MPLS label switched path (LSP)
associated with a prefix-based FEC, an IP packet with a different associated with a prefix-based FEC, an IP packet with a different
option type but associated with the same prefix-based FEC may bypass option type but associated with the same prefix-based FEC may bypass
MPLS encapsulation and instead be IP routed downstream. IP option MPLS encapsulation and instead be IP routed downstream. IP option
packets that inadvertently bypass MPLS encapsulation present an packets that fail to be MPLS encapsulated simply due to their header
increased security risk against the MPLS infrastructure. options present a security risk against the MPLS infrastructure.
Table of Contents Table of Contents
1 Specification of Requirements ...................... 2 1 Specification of Requirements ...................... 2
2 Motivation ......................................... 2 2 Motivation ......................................... 3
3 Introduction ....................................... 3 3 Introduction ....................................... 3
4 Ingress Label Edge Router Requirement .............. 4 4 Ingress Label Edge Router Requirement .............. 4
5 Security Considerations ............................ 5 5 Security Considerations ............................ 5
5.1 IP Option Packets that Bypass MPLS Encapsulation ... 5 5.1 IP Option Packets that Bypass MPLS Encapsulation ... 5
5.2 Router Alert Label Imposition ...................... 6 5.2 Router Alert Label Imposition ...................... 7
6 IANA Considerations ................................ 7 6 IANA Considerations ................................ 7
7 Conclusion ......................................... 7 7 Conclusion ......................................... 7
8 Acknowledgements ................................... 7 8 Acknowledgements ................................... 7
9 Normative References ............................... 7 9 Normative References ............................... 8
10 Informational References ........................... 8 10 Informational References ........................... 8
11 Authors' Addresses ................................. 8 11 Authors' Addresses ................................. 9
12 Full Copyright Statement ........................... 9 12 Full Copyright Statement ........................... 10
13 Intellectual Property .............................. 10 13 Intellectual Property .............................. 10
1.0 Specification of Requirements 1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2.0 Motivation 2. Motivation
This document is motivated by the need to formalize MPLS This document is motivated by the need to formalize MPLS
encapsulation processing of IP packets with header options transiting encapsulation processing of IPv4 packets with header options in order
an MPLS network. We believe that this document adds details that to mitigate the existing risks of IP options-based security attacks
have not been fully addressed in [RFC3031] and [RFC3032], and that against MPLS infrastructures. We believe that this document adds
the methods presented in this document update [RFC3031] as well as details that have not been fully addressed in [RFC3031] and
complement [RFC3443] and [RFC4950]. [RFC3032], and that the methods presented in this document update
[RFC3031] as well as complement [RFC3443] and [RFC4950].
3.0 Introduction 3. Introduction
The IP packet header provides for various IP options as originally The IP packet header provides for various IP options as originally
specified in [RFC791]. IP header options are used to enable control specified in [RFC791]. IP header options are used to enable control
functions within the IP data forwarding plane that are required in functions within the IP data forwarding plane that are required in
some specific situations but not necessary for most common IP some specific situations but not necessary for most common IP
communications. Typical IP header options include provisions for communications. Typical IP header options include provisions for
timestamps, security, and special routing. Example IP header options timestamps, security, and special routing. Example IP header options
& applications include but are not limited to: & applications include but are not limited to:
o Strict & Loose Source Route Options: Used to IP route the IP o Strict & Loose Source Route Options: Used to IP route the IP
packet based on information supplied by the source. packet based on information supplied by the source.
o Record Route Option: Used to trace the route an IP packet takes. o Record Route Option: Used to trace the route an IP packet takes.
o Router Alert Option: Indicates to downstream IP routers to o Router Alert Option: Indicates to downstream IP routers to
examine these IP packets more closely. examine these IP packets more closely.
The list of current IP header options can be accessed at [IANA]. The list of current IP header options can be accessed at [IANA].
IP packets may or may not use IP header options (they are optional) IP packets may or may not use IP header options (they are optional)
but IP header option handling mechanisms must be implemented by all but IP header option handling mechanisms must be implemented by all
IP protocol stacks (hosts and routers). Each IP header option has IP protocol stacks (hosts and routers). Each IP header option has
distinct header fields and lengths. IP options extend the IP packet distinct header fields and lengths. IP options extend the IP packet
header length beyond the minimum of 20 octets. As a result, IP header length beyond the minimum of 20 octets. As a result, IP
packets received with header options are typically handled as packets received with header options are typically handled as
exceptions and in a less efficient manner due to their variable exceptions and in a less efficient manner due to their variable
length and complex processing requirements. Many router length and complex processing requirements. Many router
implementations, for example, punt such packets from the hardware implementations, for example, punt such packets from the hardware
forwarding (fast) path into the software forwarding (slow) path. forwarding (fast) path into the software forwarding (slow) path.
Multi-Protocol Label Switching (MPLS) [RFC3031] is primarily a Multi-Protocol Label Switching (MPLS) [RFC3031] is a technology in
service provider (SP) technology where IP traffic can be encapsulated which packets are encapsulated with a label stack and then switched
with a label stack and then label switched across a network via Label along a label switched path (LSP) by a sequence of label switch
Switched Paths (LSPs) and Routers (LSRs). MPLS forwarding will routers (LSRs). These intermediate LSRs do not generally perform any
follow either hop-by-hop routing or source-routing as determined by processing of the IP header as packets are forwarded. (There are some
IP routing policies. MPLS provides SPs with the control plane exceptions to this rule, such as ICMP processing, as described in
intelligence of IP while at the same time enabling layer 3 [RFC3032].) Many MPLS deployments rely on LSRs to provide layer 3
transparency much like ATM switches are transparent at layer 2. That transparency much like ATM switches are transparent at layer 2.
is, when a MPLS label stack is imposed at a ingress Label Edge Router
(LER), downstream LSRs generally use the MPLS label information for
their forwarding decision instead of the encapsulated IP header
information. In this way, except when ICMP processing is required per
[RFC3032] LSRs can avoid processing the IP network layer headers of
transit traffic.
Even though MPLS encapsulation seems to offer a viable solution to Even though MPLS encapsulation seems to offer a viable solution to
protect downstream LSRs from being adversely impacted by customer protect downstream LSRs from being adversely impacted by customer
packets with IP header options, there is currently no formal standard packets with IP header options, there is currently no formal standard
for encapsulation of IP packets with header options in MPLS networks. for encapsulation of IP packets with header options in MPLS networks.
When MPLS encapsulated, IP option packets are processed by downstream When MPLS encapsulated, IP option packets are processed by downstream
LSRs as native MPLS packets within their forwarding paths. In this LSRs as native MPLS packets within their forwarding paths. In this
way, the IP header options are effectively ignored by downstream LSRs way, the IP header options are effectively ignored by downstream LSRs
when encapsulated with a MPLS label stack. However, for many LER when encapsulated with a MPLS label stack. However, for many LER
implementations not all IP packets with header options are MPLS implementations not all IP packets with header options are MPLS
encapsulated by the ingress LER. encapsulated by the ingress LER.
Lack of a formal standard has resulted in inconsistent forwarding Lack of a formal standard has resulted in inconsistent forwarding
behaviors by ingress LERs. Namely, IP packets with different types behaviors by ingress LERs. Namely, IP packets with different types
of IP header options are handled differently by an ingress LER of IP header options are handled differently by an ingress LER
despite being associated with the same prefix-based FEC as defined in despite being associated with the same prefix-based FEC as defined in
Section 4.1.1 of [RFC3031]. For instance, some IP header options may Section 4.1.1 of [RFC3031]. For instance, some IP header options may
inadvertently bypass MPLS encapsulation and the associated LSPs, and fail to be MPLS encapsulated, and are instead IP routed downstream on
are instead IP routed downstream on a per-hop basis by downstream a per-hop basis by downstream LSRs within the MPLS core. The
LSRs within the MPLS core. The different forwarding behaviors not different forwarding behaviors not only vary across IP option types
only vary across IP option types but also across ingress LER but also across ingress LER implementations given no formal standard
implementations given no formal standard for IP header option for IP header option processing in MPLS networks. This document
processing in MPLS networks. This document imposes a new requirement imposes a new requirement on ingress LERs in order to reduce the risk
on ingress LERs in order to reduce the risk of IP options-based of IP options-based security attacks against LSRs as well as to
security attacks against LSRs as well as to minimize the IP routing minimize the IP routing information carried by LSRs.
information carried by LSRs.
4.0 Ingress Label Edge Router Requirement 4. Ingress Label Edge Router Requirement
An ingress LER MUST implement the following policy, and the policy An ingress LER MUST implement the following policy, and the policy
MUST be enabled by default: MUST be enabled by default:
o When determining whether to push an MPLS label stack onto an IP o When determining whether to push an MPLS label stack onto an IP
packet, the determination is made without considering any IP packet, the determination is made without considering any IP
options that may be carried in the IP packet header. Further, the options that may be carried in the IP packet header. Further,
label values that appear in the label stack are determined the label values that appear in the label stack are determined
without considering any such IP options. without considering any such IP options.
Further, how an ingress LER processes IP header options before MPLS When processing of signaling messages or data packets with more
encapsulation is out of scope as it is not relevant to MPLS. specific forwarding rules is enabled, this policy SHOULD NOT alter
Similarly, an egress LER SHOULD only process IP options in those the specific processing rules. This applies to, but is not limited
cases where the egress LER forwarding decision is based on the native to, RSVP as per [RFC2205]. Further, how an ingress LER processes IP
IP packet. When the egress LER forwarding decision is based on a header options before MPLS encapsulation is out of scope as it is not
popped label, the MPLS encapsulated IP header information including relevant to MPLS.
IP options should be ignored with the exception of the IP TTL per
[RFC3443] and the Tunneled Diff-Serv information per [RFC3270].
Implementation of the above policy prevents IP packets from Implementation of the above policy prevents IP packets from failing
inadvertently bypassing MPLS encapsulation due to header options. The to be MPLS encapsulated due to header options. The policy also
policy also prevents specific option types such as Router Alert prevents specific option types such as Router Alert (value 148), for
(value 148), for example, from forcing MPLS imposition of the MPLS example, from forcing MPLS imposition of the MPLS Router Alert Label
Router Alert Label (value 1) at ingress LERs. Without this policy, (value 1) at ingress LERs. Without this policy, the MPLS
the MPLS infrastructure is exposed to security attacks using infrastructure is exposed to security attacks using legitimate IP
legitimate IP packets crafted with header options. packets crafted with header options.
5.0 Security Considerations 5. Security Considerations
There are two potential categories of attacks using crafted IP option There are two potential categories of attacks using crafted IP option
packets that threaten the MPLS infrastructure. Both are described packets that threaten existing MPLS infrastructures. Both are
below. described below. To mitigate the risk of these specific attacks, the
ingress LER policy specified above is required.
5.1. IP Option Packets that Bypass MPLS Encapsulation 5.1. IP Option Packets that Bypass MPLS Encapsulation
Given that a router's exception handling process (i.e., CPU, Given that a router's exception handling process (i.e., CPU,
processor line-card bandwidth, etc.) used for IP header option processor line-card bandwidth, etc.) used for IP header option
processing is often shared with IP control and management protocol processing is often shared with IP control and management protocol
router resources, a flood of IP packets with header options may router resources, a flood of IP packets with header options may
adversely affect a router's control and management protocols, adversely affect a router's control and management protocols,
thereby, triggering a denial-of- service (DoS) condition. Note, IP thereby, triggering a denial-of-service (DoS) condition. Note, IP
packets with header options may be valid transit IP packets with packets with header options may be valid transit IP packets with
legitimate sources and destinations. Hence, a DoS-like condition may legitimate sources and destinations. Hence, a DoS-like condition may
be triggered on downstream transit IP routers that lack protection be triggered on downstream transit IP routers that lack protection
mechanisms even in the case of legitimate IP option packets. mechanisms even in the case of legitimate IP option packets.
IP option packets that bypass MPLS encapsulation at a ingress LER may IP option packets that bypass MPLS encapsulation at a ingress LER may
be inadvertently IP routed downstream across the MPLS core network be inadvertently IP routed downstream across the MPLS core network
(not label switched). This allows an external attacker the (not label switched). This allows an external attacker the
opportunity to maliciously craft seemingly legitimate IP packets with opportunity to maliciously craft seemingly legitimate IP packets with
specific IP header options in order to intentionally bypass MPLS specific IP header options in order to intentionally bypass MPLS
skipping to change at page 5, line 46 skipping to change at page 5, line 49
exception path, control and management protocols may be adversely exception path, control and management protocols may be adversely
affected and, thereby, a LSR's availability. This assumes, of affected and, thereby, a LSR's availability. This assumes, of
course, that downstream LSRs lack protection mechanisms. course, that downstream LSRs lack protection mechanisms.
o Crafted IP option packets that bypass MPLS encapsulation at a o Crafted IP option packets that bypass MPLS encapsulation at a
ingress LER may allow for IP TTL expiry-based DoS attacks against ingress LER may allow for IP TTL expiry-based DoS attacks against
downstream LSRs. MPLS enables IP core hiding whereby transit IP downstream LSRs. MPLS enables IP core hiding whereby transit IP
customers see the MPLS network as a single router hop [RFC3443]. customers see the MPLS network as a single router hop [RFC3443].
However, MPLS core hiding does not apply to packets that bypass However, MPLS core hiding does not apply to packets that bypass
MPLS encapsulation and, therefore, IP option packets may be MPLS encapsulation and, therefore, IP option packets may be
crafted to expire on downstream LSRs which may trigger a DoS crafted to expire on downstream LSRs which may trigger a DoS
condition. This assumes, of course, that downstream LSRs lack condition. Bypassing MPLS core hiding is an additional security
protection mechanisms. Bypassing MPLS core hiding is an consideration since it exposes the network topology.
additional security consideration since it exposes the network o Crafted IP option packets that bypass MPLS encapsulation at a
topology. ingress LER may allow for DoS attacks against downstream LSRs
that do not carry the IP routing information required to forward
transit IP traffic. Lack of such IP routing information may
prevent legitimate IP option packets from transiting the MPLS
network and, further, may trigger generation of ICMP destination
unreachable messages which could lead to a DoS condition. This
assumes, of course, that downstream LSRs lack protection
mechanisms and do not carry the IP routing information required
to forward transit traffic.
o Crafted IP option packets that bypass MPLS encapsulation at a o Crafted IP option packets that bypass MPLS encapsulation at a
ingress LER may allow an attacker to bypass LSP Diff-Serv tunnels ingress LER may allow an attacker to bypass LSP Diff-Serv tunnels
[RFC3270] and any associated MPLS CoS field [MPLSCOS] marking [RFC3270] and any associated MPLS CoS field [MPLSCOS] marking
policies at ingress LERs and, thereby, adversely affect (i.e., policies at ingress LERs and, thereby, adversely affect (i.e.,
DoS) high-priority traffic classes within the MPLS core. Further, DoS) high-priority traffic classes within the MPLS core.
this could also lead to theft of high-priority services by Further, this could also lead to theft of high-priority services
unauthorized parties. This assumes, of course, that the by unauthorized parties. This assumes, of course, that the
[RFC3270] Pipe model is deployed within the MPLS core. [RFC3270] Pipe model is deployed within the MPLS core.
o Crafted IP strict and loose source route option packets that o Crafted IP strict and loose source route option packets that
bypass MPLS encapsulation at a ingress LER may allow an attacker bypass MPLS encapsulation at a ingress LER may allow an attacker
to specify explicit IP forwarding path(s) across an MPLS network to specify explicit IP forwarding path(s) across an MPLS network
and, thereby, target specific LSRs with any of the DoS attacks and, thereby, target specific LSRs with any of the DoS attacks
outlined above. This assumes, of course, that the MPLS network outlined above. This assumes, of course, that the MPLS network
is enabled to process IP strict and loose source route options. is enabled to process IP strict and loose source route options.
o Crafted RSVP packets that bypass MPLS encapsulation at a ingress o Crafted RSVP packets that bypass MPLS encapsulation at a ingress
LER may allow an attacker to build RSVP soft-states [RFC2205] on LER may allow an attacker to build RSVP soft-states [RFC2205] on
downstream LSRs which could lead to theft of service by downstream LSRs which could lead to theft of service by
unauthorized parties or to a DoS condition caused by locking up unauthorized parties or to a DoS condition caused by locking up
LSR resources. This assumes, of course, that the MPLS network is LSR resources. This assumes, of course, that the MPLS network is
enabled to process RSVP packets. enabled to process RSVP packets.
The security attacks outlined above specifically apply to IP option The security attacks outlined above specifically apply to IP option
packets that bypass ingress LER label stack imposition. Additionally, packets that bypass ingress LER label stack imposition.
these attacks apply to IP option packets forwarded using the global Additionally, these attacks apply to IP option packets forwarded
routing table (i.e., IPv4 address family) of a ingress LER. IP using the global routing table (i.e., IPv4 address family) of a
option packets associated with a BGP/MPLS IP VPN service are always ingress LER. IP option packets associated with a BGP/MPLS IP VPN
MPLS encapsulated by the LER per [RFC4364] given that packet service are always MPLS encapsulated by the LER per [RFC4364] given
forwarding uses a Virtual Forwarding/Routing (VRF) instance. that packet forwarding uses a Virtual Forwarding/Routing (VRF)
Therefore, BGP/MPLS IP VPN services are not subject to the threats instance. Therefore, BGP/MPLS IP VPN services are not subject to the
outlined above [RFC4381]. Further, IPv6 [RFC2460] makes use of threats outlined above [RFC4381]. Further, IPv6 [RFC2460] makes use
extension headers not header options and is therefore outside the of extension headers not header options and is therefore outside the
scope of this document. A separate security threat that does apply scope of this document. A separate security threat that does apply
to both BGP/MPLS IP VPNs and an IPv4 address family makes use of the to both BGP/MPLS IP VPNs and an IPv4 address family makes use of the
Router Alert Label. This is described directly below. Router Alert Label. This is described directly below.
5.2. Router Alert Label Imposition 5.2. Router Alert Label Imposition
[RFC3032] defines a "Router Alert Label" (value of 1) which is [RFC3032] defines a "Router Alert Label" (value of 1) which is
analogous to the "Router Alert" IP header option. The MPLS Router analogous to the "Router Alert" IP header option. The MPLS Router
Alert Label (when exposed and processed only) indicates to downstream Alert Label (when exposed and processed only) indicates to downstream
LSRs to examine these MPLS packets more closely. MPLS packets with LSRs to examine these MPLS packets more closely. MPLS packets with
the MPLS Router Alert Label are also handled as an exception by LSRs the MPLS Router Alert Label are also handled as an exception by LSRs
and, again, in a less efficient manner. At the time of this writing, and, again, in a less efficient manner. At the time of this writing,
the only legitimate use of the Router Alert Label is for LSP the only legitimate use of the Router Alert Label is for LSP
skipping to change at page 7, line 4 skipping to change at page 7, line 16
[RFC3032] defines a "Router Alert Label" (value of 1) which is [RFC3032] defines a "Router Alert Label" (value of 1) which is
analogous to the "Router Alert" IP header option. The MPLS Router analogous to the "Router Alert" IP header option. The MPLS Router
Alert Label (when exposed and processed only) indicates to downstream Alert Label (when exposed and processed only) indicates to downstream
LSRs to examine these MPLS packets more closely. MPLS packets with LSRs to examine these MPLS packets more closely. MPLS packets with
the MPLS Router Alert Label are also handled as an exception by LSRs the MPLS Router Alert Label are also handled as an exception by LSRs
and, again, in a less efficient manner. At the time of this writing, and, again, in a less efficient manner. At the time of this writing,
the only legitimate use of the Router Alert Label is for LSP the only legitimate use of the Router Alert Label is for LSP
ping/trace [RFC4379]. Since there is also no formal standard for ping/trace [RFC4379]. Since there is also no formal standard for
Router Alert Label imposition at ingress LERs: Router Alert Label imposition at ingress LERs:
o Crafted IP packets with specific IP header options (e.g., Router o Crafted IP packets with specific IP header options (e.g., Router
Alert) may allow an attacker to force MPLS imposition of the Alert) may allow an attacker to force MPLS imposition of the
Router Alert Label at ingress LERs and, thereby, trigger a DoS Router Alert Label at ingress LERs and, thereby, trigger a DoS
condition on downstream LSRs. This assumes, of course, that condition on downstream LSRs. This assumes, of course, that
downstream LSRs lack protection mechanisms. downstream LSRs lack protection mechanisms.
6.0 IANA Considerations 6. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
7.0 Conclusion 7. Conclusion
This document imposes a new requirement on ingress LERs that helps to This document imposes a new requirement on ingress LERs that helps to
mitigate the risk of crafted security attacks using IP option packets mitigate the risk of crafted security attacks using IP option packets
against MPLS infrastructures. The security threats were described against MPLS infrastructures. The security threats were described
and exist as a result of no formal ingress LER specification for MPLS and exist as a result of no formal ingress LER specification for MPLS
encapsulation of IP packets with header options. Adoption of this encapsulation of IP packets with header options. Adoption of this
requirement will also eliminate the variability among ingress LER requirement will also eliminate the variability among ingress LER
implementations. implementations.
8.0 Acknowledgements 8. Acknowledgements
The authors would like to thank Pradosh Mohapatra, Carlos Pignataro, The authors would like to thank Adrian Cepleanu, Bruce Davie, Rick
Eric Rosen and Mark Szczesniak for their valuable comments and Huber, Pradosh Mohapatra, Ashok Narayanan, Carlos Pignataro, Eric
Rosen, Mark Szczesniak and Yung Yu for their valuable comments and
suggestions. suggestions.
9.0 Normative References 9. Normative References
[RFC791] Postel, J., "Internet Protocol Specification," RFC791, [RFC791] Postel, J., "Internet Protocol Specification," RFC791,
September 1981. September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," March 1997. Requirement Levels," March 1997.
[RFC3031] Rosen, E., Viswanathan, A., and Callon, R., "MPLS Label [RFC3031] Rosen, E., Viswanathan, A., and Callon, R., "MPLS Label
Switching Architecture," RFC3031, January 2001. Switching Architecture," RFC3031, January 2001.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and Conta, A., "MPLS Label Stack Encoding," Farinacci, D., Li, T., and Conta, A., "MPLS Label Stack Encoding,"
RFC3032, January 2001. RFC3032, January 2001.
10.0 Informational References 10. Informational References
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S., [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S.,
"Resource ReSerVation Protocol -- Version 1 Functional "Resource ReSerVation Protocol -- Version 1 Functional
Specification," RFC2205, September 1997. Specification," RFC2205, September 1997.
[RFC2460] Deering, S., Hinden, R. "Internet Protocol, Version 6 [RFC2460] Deering, S., Hinden, R. "Internet Protocol, Version 6
Specification," RFC2460, December 1998. Specification," RFC2460, December 1998.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
P., Krishnan, R., Cheval, P., Heinanen, J., "Multi-Protocol Label P., Krishnan, R., Cheval, P., Heinanen, J., "Multi-Protocol Label
skipping to change at page 8, line 31 skipping to change at page 8, line 46
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)," RFC4364, February 2006. Networks (VPNs)," RFC4364, February 2006.
[RFC4379] "Kompella, K., Swallow, G., "Detecting Multi-Protocol Label [RFC4379] "Kompella, K., Swallow, G., "Detecting Multi-Protocol Label
Switched (MPLS) Data Plane Failures," RFC4379, February 2006. Switched (MPLS) Data Plane Failures," RFC4379, February 2006.
[RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP [RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP
Virtual Private Networks (VPNs)," RFC4381, February 2006. Virtual Private Networks (VPNs)," RFC4381, February 2006.
[RFC3209] Awduche, D., L. Berger, D. Gan, T. Li, V. Srinivasan, G.
Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC3209,
December 2001.
[RFC4950] Bonica, R., Gan, D., Tappan, D., and Pignataro, C., "ICMP [RFC4950] Bonica, R., Gan, D., Tappan, D., and Pignataro, C., "ICMP
Extensions for Multiprotocol Label Switching," RFC4950, August 2007. Extensions for Multiprotocol Label Switching," RFC4950, August 2007.
[IANA] "IP Option Numbers," IANA, February 15, 2007, [IANA] "IP Option Numbers," IANA, February 15, 2007,
<www.iana.org/assignments/ip-parameters>. <www.iana.org/assignments/ip-parameters>.
[MPLSCOS] Andersson, L., "EXP Field Renamed to CoS Field," IETF [MPLSCOS] Andersson, L., "EXP Field Renamed to CoS Field," IETF
draft-ietf-mpls-cosfield-def-02.txt, June 11, 2008. draft-ietf-mpls-cosfield-def-02.txt, June 11, 2008.
11.0 Authors' Addresses 11. Authors' Addresses
William Jaeger William Jaeger
AT&T AT&T
200 S. Laurel Avenue 200 S. Laurel Avenue
Middletown, NJ 07748 Middletown, NJ 07748
Email: wjaeger@att.com Email: wjaeger@att.com
John Mullooly John Mullooly
Cisco Systems, Inc. Cisco Systems, Inc.
111 Wood Avenue 111 Wood Avenue
Iselin, NJ 08837 Iselin, NJ 08830
E-mail: jmullool@cisco.com E-mail: jmullool@cisco.com
Tom Scholl Tom Scholl
AT&T AT&T Labs
200 S. Laurel Avenue 200 S. Laurel Avenue
Middletown, NJ 07748 Middletown, NJ 07748
Email: ts3127@att.com Email: ts3127@att.com
David J. Smith David J. Smith
Cisco Systems, Inc. Cisco Systems, Inc.
111 Wood Avenue 111 Wood Avenue
Iselin, NJ 08837 Iselin, NJ 08830
E-mail: dasmith@cisco.com E-mail: djsmith@cisco.com
12.0 Full Copyright Statement 12. Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE 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.
13.0 Intellectual Property 13. Intellectual Property
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
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 44 change blocks. 
100 lines changed or deleted 107 lines changed or added

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