draft-ietf-mpls-in-udp-08.txt   draft-ietf-mpls-in-udp-09.txt 
Network Working Group X. Xu Network Working Group X. Xu
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Standards Track N. Sheth Intended status: Standards Track N. Sheth
Expires: June 13, 2015 Juniper Networks Expires: June 21, 2015 Juniper Networks
L. Yong L. Yong
Huawei USA Huawei USA
R. Callon R. Callon
Juniper Networks Juniper Networks
D. Black D. Black
EMC Corporation EMC Corporation
December 10, 2014 December 18, 2014
Encapsulating MPLS in UDP Encapsulating MPLS in UDP
draft-ietf-mpls-in-udp-08 draft-ietf-mpls-in-udp-09
Abstract Abstract
This document specifies an IP-based encapsulation for MPLS, called This document specifies an IP-based encapsulation for MPLS, called
MPLS-in-UDP (User Datagram Protocol). The MPLS-in-UDP encapsulation MPLS-in-UDP (User Datagram Protocol) for situations where UDP
technology MUST only be deployed within a service provider network or encapsulation is preferred to direct use of MPLS, e.g., to enable
networks of an adjacent set of co-operating service providers where UDP-based ECMP (Equal Cost Multi-Pathing) or link aggregation. MPLS-
congestion control is not a concern. in-UDP is primarily applicable to service provider networks, and
additional restrictions apply to MPLS-in-UDP usage for traffic that
is not congestion controlled and to UDP zero checksum usage with
IPv6.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on June 13, 2015. This Internet-Draft will expire on June 21, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Existing Encapsulations . . . . . . . . . . . . . . . . . 3 1.1. Existing Encapsulations . . . . . . . . . . . . . . . . . 3
1.2. Motivations for MPLS-in-UDP Encapsulation . . . . . . . . 3 1.2. Motivations for MPLS-in-UDP Encapsulation . . . . . . . . 3
1.3. Application Statements . . . . . . . . . . . . . . . . . 4 1.3. Application Statements . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Encapsulation in UDP . . . . . . . . . . . . . . . . . . . . 4 3. Encapsulation in UDP . . . . . . . . . . . . . . . . . . . . 4
3.1. UDP Checksum Usage with IPv6 . . . . . . . . . . . . . . 6 3.1. UDP Checksum Usage with IPv6 . . . . . . . . . . . . . . 6
3.2. Middlebox Considerations for IPv6 UDP Zero Checksums . . 8 3.2. Middlebox Considerations for IPv6 UDP Zero Checksums . . 9
4. Processing Procedures . . . . . . . . . . . . . . . . . . . . 9 4. Processing Procedures . . . . . . . . . . . . . . . . . . . . 9
5. Congestion Considerations . . . . . . . . . . . . . . . . . . 9 5. Congestion Considerations . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
This document specifies an IP-based encapsulation for MPLS, i.e. This document specifies an IP-based encapsulation for MPLS, i.e.
MPLS-in-UDP (User Datagram Protocol), which is applicable in some MPLS-in-UDP (User Datagram Protocol), which is applicable in some
circumstances where IP-based encapsulation for MPLS is required and circumstances where IP-based encapsulation for MPLS is required and
further fine-grained load balancing of MPLS packets over IP networks further fine-grained load balancing of MPLS packets over IP networks
over Equal Cost Multi-Path (ECMP) and/or Link Aggregation Groups over Equal Cost Multi-Path (ECMP) and/or Link Aggregation Groups
(LAG) is required as well. There are already IP-based encapsulations (LAG) is required as well. There are already IP-based encapsulations
for MPLS that allow for fine-grained load balancing by using some for MPLS that allow for fine-grained load balancing by using some
skipping to change at page 5, line 46 skipping to change at page 6, line 4
specification of these exceptions and additional requirements specification of these exceptions and additional requirements
that apply when UDP zero-checksum mode is used for MPLS-in-UDP that apply when UDP zero-checksum mode is used for MPLS-in-UDP
traffic over IPv6. traffic over IPv6.
MPLS Label Stack MPLS Label Stack
This field contains an MPLS Label Stack as defined in This field contains an MPLS Label Stack as defined in
[RFC3032]. [RFC3032].
Message Body Message Body
This field contains one MPLS message body. This field contains one MPLS message body.
3.1. UDP Checksum Usage with IPv6 3.1. UDP Checksum Usage with IPv6
When UDP is used over IPv6, the UDP checksum is relied upon to When UDP is used over IPv6, the UDP checksum is relied upon to
protect the IPv6 header from corruption, and MUST be used unless the protect both the IPv6 and UDP headers from corruption, and MUST be
requirements in [RFC6935] and [RFC6936] for use of UDP zero-checksum used unless the requirements in [RFC6935] and [RFC6936] for use of
mode with a tunnel protocol are satisfied. MPLS-in-UDP is a tunnel UDP zero-checksum mode with a tunnel protocol are satisfied. MPLS-
protocol, and there is significant successful deployment of MPLS-in- in-UDP is a tunnel protocol, and there is significant successful
IPv6 without UDP (i.e., without a checksum that covers the IPv6 deployment of MPLS-in-IPv6 without UDP (i.e., without a checksum that
header or the MPLS label stack), as described in Section 3.1 of covers the IPv6 header or the MPLS label stack), as described in
[RFC6936]: Section 3.1 of [RFC6936]:
"There is extensive experience with deployments using tunnel "There is extensive experience with deployments using tunnel
protocols in well-managed networks (e.g., corporate networks and protocols in well-managed networks (e.g., corporate networks and
service provider core networks). This has shown the robustness of service provider core networks). This has shown the robustness of
methods such as Pseudowire Emulation Edge-to-Edge (PWE3) and MPLS methods such as Pseudowire Emulation Edge-to-Edge (PWE3) and MPLS
that do not employ a transport protocol checksum and that have not that do not employ a transport protocol checksum and that have not
specified mechanisms to protect from corruption of the unprotected specified mechanisms to protect from corruption of the unprotected
headers(such as the VPN Identifier in MPLS)". headers(such as the VPN Identifier in MPLS)".
This draft focuses on service provider core networks. The This document focuses on service provider core networks. The UDP
requirements in Section 5 for use of MPLS-in-UDP to carry traffic checksum MUST be implemented and MUST be used in accordance with
that is not necessarily congestion controlled involve significant [RFC0768] and [RFC2460] for MPLS-in-UDP traffic over IPv6 unless one
service provider traffic management and engineering - this is a or more of the following exceptions applies and the additional
hallmark of the well-managed networks that the above [RFC6936] text requirements stated below are also complied with. There are three
refers to. Therefore, the UDP checksum MUST be implemented and MUST exceptions that allow use of UDP zero-checksum mode for IPv6 with
be used in accordance with [RFC0768] and [RFC2460] for MPLS-in-UDP MPLS-in-UDP, subject to the additional requirements stated below in
traffic over IPv6 unless one of the following exceptions applies and this section. The three exceptions are:
the additional requirements stated below are complied with. There
are two exceptions that allow use of UDP zero-checksum mode for IPv6
with MPLS-in-UDP, subject to the additional requirements stated below
in this section. The two exceptions are:
a. Use of MPLS-in-UDP within a single service provider that utilizes a. Use of MPLS-in-UDP in networks under single administrative
careful provisioning (e.g., rate limiting at the entries of the control (such as within a single service provider) where it is
network while over-provisioning network capacity) to ensure known (perhaps through knowledge of equipment types and lower
against congestion and that actively monitors MPLS traffic for layer checks) that packet corruption is exceptionally unlikely
errors; or and where the operator is willing to take the risk of undetected
packet corruption.
b. Use of MPLS-in-UDP within a limited number of service providers b. Use of MPLS-in-UDP in networks under single administrative
who closely cooperate in order to jointly provide this same control (such as within a single service provider) where it is
careful provisioning and monitoring. judged through observational measurements (perhaps of historic or
current traffic flows that use a non-zero checksum) that the
level of packet corruption is tolerably low and where the
operator is willing to take the risk of undetected packet
corruption.
Even when one of the above exceptions applies, use of UDP checksums c. Use of MPLS-in-UDP for traffic delivery for applications that are
may be appropriate when VPN services are provided over MPLS-in-UDP, tolerant of misdelivered or corrupted packets (perhaps through
see Section 6. As such, for IPv6, the UDP checksum for MPLS-in-UDP higher layer checksum, validation, and retransmission or
MUST be used as specified in [RFC0768] and [RFC2460] over the general transmission redundancy) where the operator is willing to rely on
Internet, and over non-cooperating SPs, even if each non-cooperating the applications using the tunnel to survive any corrupt packets.
SP independently satisfies the first exception for UDP zero-checksum
mode usage with MPLS-in-UDP over IPv6 within the SP's own network. These exceptions may also be extended to the use of MPLS-in-UDP
Measures SHOULD be taken to prevent UDP zero checksum mode MPLS-in- within a set of closely cooperating network administrations (such as
UDP over IPv6 traffic from "escaping" to the general Internet; see service providers who have agreed to work together in order to
Section 5 for examples of such measures. jointly provide specific services). Even when one of the above
exceptions applies, use of UDP checksums may be appropriate when VPN
services are provided over MPLS-in-UDP, see Section 6.
As such, for IPv6, the UDP checksum for MPLS-in-UDP MUST be used as
specified in [RFC0768] and [RFC2460] over the general Internet, and
for tunnels that span multiple networks whose network administrations
do not cooperate closely, even if each non-cooperating network
administration independently satisfies one or more of the exceptions
for UDP zero-checksum mode usage with MPLS-in-UDP over IPv6.
The following additional requirements apply to implementation and use The following additional requirements apply to implementation and use
of UDP zero-checksum mode for MPLS-in-UDP over IPv6: of UDP zero-checksum mode for MPLS-in-UDP over IPv6:
a. Use of the UDP checksum with IPv6 MUST be the default a. Use of the UDP checksum with IPv6 MUST be the default
configuration of all MPLS-in-UDP implementations. configuration of all MPLS-in-UDP implementations.
b. An MPLS-in-UDP implementation MUST comply with all requirements b. An MPLS-in-UDP implementation MUST comply with all requirements
specified in Section 4 of [RFC6936] and with requirement 1 specified in Section 4 of [RFC6936] and with requirement 1
specified in Section 5 of [RFC6936]. specified in Section 5 of [RFC6936].
c. An MPLS-in-UDP receiver MUST check that the source and c. An MPLS-in-UDP receiver node SHOULD only allow the use of UDP
zero-checksum mode for IPv6 on a single UDP port regardless of
sender. The motivation for this requirement is possible
corruption of the UDP destination port, which may cause packet
delivery to the wrong UDP port. If that other UDP port requires
the UDP checksum, the misdelivered packet will be discarded
d. An MPLS-in-UDP receiver MUST check that the source and
destination IPv6 addresses are valid for the MPLS-in-UDP tunnel destination IPv6 addresses are valid for the MPLS-in-UDP tunnel
and discard any packet for which this check fails. on which the packet was received if that tunnel uses UDP zero-
checksum mode and discard any packet for which this check fails.
d. An MPLS-in-UDP sender SHOULD use different IPv6 addresses for e. An MPLS-in-UDP sender SHOULD use different IPv6 addresses for
each MPLS-in-UDP tunnel that uses UDP zero-checksum mode in order each MPLS-in-UDP tunnel that uses UDP zero-checksum mode
to strengthen the receiver's check of the IPv6 source address. regardless of receiver in order to strengthen the receiver's
When this is not possible, it is RECOMMENDED to use each source check of the IPv6 source address. When this is not possible, it
IPv6 address for as few UDP zero-checksum mode MPLS-in-UDP is RECOMMENDED to use each source IPv6 address for as few UDP
tunnels as is feasible. zero-checksum mode MPLS-in-UDP tunnels as is feasible.
e. An MPLS-in-UDP receiver MUST check that the top label of the MPLS f. An MPLS-in-UDP receiver MUST check that the top label of the MPLS
label stack is valid for the tunnel. This check will often be label stack is valid for the tunnel on which the packet was
received if that tunnel uses UDP zero-checksum mode and discard
any packet for which this check fails. This check will often be
part of the MPLS LSR forwarding logic, but MUST be scoped to the part of the MPLS LSR forwarding logic, but MUST be scoped to the
specific tunnel. specific tunnel.
f. An MPLS-in-UDP receiver node SHOULD only enable the use of UDP
zero-checksum mode on a single UDP port and SHOULD NOT support
any other use UDP zero-checksum mode on any other UDP port.
g. Any middlebox support for MPLS-in-UDP with UDP zero-checksum mode g. Any middlebox support for MPLS-in-UDP with UDP zero-checksum mode
for IPv6 MUST comply with requirements 1 and 8-10 in Section 5 of for IPv6 MUST comply with requirements 1 and 8-10 in Section 5 of
[RFC6936]. [RFC6936].
The above requirements do not change the requirements specified in h. Measures SHOULD be taken to prevent IPv6 traffic with zero UDP
[RFC2460] as modified by [RFC6935] and the requirements specified in checksums from "escaping" to the general Internet; see Section 5
[RFC6936]. for examples of such measures.
i. IPv6 traffic with zero UDP checksums MUST be actively monitored
for errors by the network operator.
The above requirements do not change either the requirements
specified in [RFC2460] as modified by [RFC6935] or the requirements
specified in [RFC6936].
The requirements to check the source IPv6 address and top label of The requirements to check the source IPv6 address and top label of
the MPLS stack (in addition to the destination IPv6 address), plus the MPLS stack (in addition to the destination IPv6 address), plus
the strong recommendation against reuse of source IPv6 addresses the strong recommendation against reuse of source IPv6 addresses
among MPLS-in-UDP tunnels collectively provide some offset for the among MPLS-in-UDP tunnels collectively provide some mitigation for
absence of UDP checksum coverage of the IPv6 header. The expected the absence of UDP checksum coverage of the IPv6 header. The
result for IPv6 UDP zero-checksum mode for MPLS-in-UDP is that expected result for IPv6 UDP zero-checksum mode for MPLS-in-UDP is
corruption of the destination IPv6 address will usually cause packet that corruption of the destination IPv6 address will usually cause
discard, as offsetting corruptions to the source IPv6 and/or MPLS top packet discard, as offsetting corruptions to the source IPv6 and/or
label are unlikely. Additional assurance is provided by the MPLS top label are unlikely. Additional assurance is provided by the
restrictions in the above exceptions that limit usage of IPv6 UDP restrictions in the above exceptions that limit usage of IPv6 UDP
zero-checksum mode to specific types of well-managed networks for zero-checksum mode to well-managed networks for which MPLS packet
which MPLS packet corruption has not been a problem in practice. corruption has not been a problem in practice.
Hence MPLS-in-UDP is suitable for transmission over lower layers in Hence MPLS-in-UDP is suitable for transmission over lower layers in
the well-managed networks that are allowed by the two exceptions the well-managed networks that are allowed by the exceptions stated
stated above and is not expected to increase the rate of corruption above and the rate of corruption of the inner IP packet on such
of the inner IP packet on such networks by comparison to MPLS traffic networks is not expected to increase by comparison to MPLS traffic
that is not encapsulated in UDP. For these reasons, MPLS-in-UDP does that is not encapsulated in UDP. For these reasons, MPLS-in-UDP does
not provide an additional integrity check when UDP zero-checksum mode not provide an additional integrity check when UDP zero-checksum mode
is used with IPv6, and this design is in accordance with requirements is used with IPv6, and this design is in accordance with requirements
2, 3 and 5 specified in Section 5 of [RFC6936]. 2, 3 and 5 specified in Section 5 of [RFC6936].
MPLS does not accumulate incorrect state as a consequence of label MPLS does not accumulate incorrect state as a consequence of label
stack corruption. A corrupt MPLS label results in either packet stack corruption. A corrupt MPLS label results in either packet
discard or forwarding (and forgetting) of the packet without discard or forwarding (and forgetting) of the packet without
accumulation of MPLS protocol state. Active monitoring of MPLS-in- accumulation of MPLS protocol state. Active monitoring of MPLS-in-
UDP traffic for errors is REQUIRED as occurrence of errors will UDP traffic for errors is REQUIRED as occurrence of errors will
skipping to change at page 8, line 38 skipping to change at page 9, line 15
accordance with requirement 4 specified in Section 5 of [RFC6936]. accordance with requirement 4 specified in Section 5 of [RFC6936].
The remaining requirements specified in Section 5 of [RFC6936] are The remaining requirements specified in Section 5 of [RFC6936] are
inapplicable to MPLS-in-UDP. Requirements 6 and 7 do not apply inapplicable to MPLS-in-UDP. Requirements 6 and 7 do not apply
because MPLS does not have an MPLS-generic control feedback because MPLS does not have an MPLS-generic control feedback
mechanism. Requirements 8-10 are middlebox requirements that do not mechanism. Requirements 8-10 are middlebox requirements that do not
apply to MPLS-in-UDP tunnel endpoints, but see Section 3.2 for apply to MPLS-in-UDP tunnel endpoints, but see Section 3.2 for
further middlebox discussion. further middlebox discussion.
In summary, UDP zero-checksum mode for IPv6 is allowed to be used In summary, UDP zero-checksum mode for IPv6 is allowed to be used
with MPLS-in-UDP when one of the two exceptions specified above with MPLS-in-UDP when one of the three exceptions specified above
applies, provided that the additional requirements specified above applies, provided that the additional requirements specified in this
are complied with. Otherwise the UDP checksum MUST be used for IPv6 section are complied with. Otherwise the UDP checksum MUST be used
as specified in [RFC0768] and [RFC2460]. for IPv6 as specified in [RFC0768] and [RFC2460].
This entire section and its requirements apply only to use of UDP This entire section and its requirements apply only to use of UDP
zero-checksum mode for IPv6; they can be avoided by using the UDP zero-checksum mode for IPv6; they can be avoided by using the UDP
checksum as specified in [RFC0768] and [RFC2460]. checksum as specified in [RFC0768] and [RFC2460].
3.2. Middlebox Considerations for IPv6 UDP Zero Checksums 3.2. Middlebox Considerations for IPv6 UDP Zero Checksums
IPv6 datagrams with a zero UDP checksum will not be passed by any IPv6 datagrams with a zero UDP checksum will not be passed by any
middlebox that validates the checksum based on [RFC2460] or that middlebox that validates the checksum based on [RFC2460] or that
updates the UDP checksum field, such as NATs or firewalls. Changing updates the UDP checksum field, such as NATs or firewalls. Changing
skipping to change at page 11, line 35 skipping to change at page 12, line 13
from the general Internet. from the general Internet.
b. Deployment of packet filters that block the UDP ports assigned b. Deployment of packet filters that block the UDP ports assigned
for MPLS-over-UDP. for MPLS-over-UDP.
c. Imposition of restrictions on MPLS-in-UDP traffic by software c. Imposition of restrictions on MPLS-in-UDP traffic by software
tools used to set up MPLS-in-UDP tunnels between specific end tools used to set up MPLS-in-UDP tunnels between specific end
systems (as might be used within a single data center). systems (as might be used within a single data center).
d. Use of a "Managed Circuit Breaker" for the MPLS traffic as d. Use of a "Managed Circuit Breaker" for the MPLS traffic as
described in [I-D.fairhurst-tsvwg-circuit-breaker]. described in [I-D.ietf-tsvwg-circuit-breaker].
6. Security Considerations 6. Security Considerations
The security problems faced with the MPLS-in-UDP tunnel are exactly The security problems faced with the MPLS-in-UDP tunnel are exactly
the same as those faced with MPLS-in-IP and MPLS-in-GRE tunnels the same as those faced with MPLS-in-IP and MPLS-in-GRE tunnels
[RFC4023]. In other words, the MPLS-in-UDP tunnel as defined in this [RFC4023]. In other words, the MPLS-in-UDP tunnel as defined in this
document by itself cannot ensure the integrity and privacy of data document by itself cannot ensure the integrity and privacy of data
packets being transported through the MPLS-in-UDP tunnel and cannot packets being transported through the MPLS-in-UDP tunnel and cannot
enable the tunnel decapsulator to authenticate the tunnel enable the tunnel decapsulator to authenticate the tunnel
encapsulator. In the case where any of the above security issues is encapsulator. In the case where any of the above security issues is
skipping to change at page 15, line 38 skipping to change at page 16, line 17
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
UDP Checksums for Tunneled Packets", RFC 6935, April 2013. UDP Checksums for Tunneled Packets", RFC 6935, April 2013.
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
for the Use of IPv6 UDP Datagrams with Zero Checksums", for the Use of IPv6 UDP Datagrams with Zero Checksums",
RFC 6936, April 2013. RFC 6936, April 2013.
10.2. Informative References 10.2. Informative References
[I-D.fairhurst-tsvwg-circuit-breaker] [I-D.ietf-tsvwg-circuit-breaker]
Fairhurst, G., "Network Transport Circuit Breakers", Fairhurst, G., "Network Transport Circuit Breakers",
draft-fairhurst-tsvwg-circuit-breaker-01 (work in draft-ietf-tsvwg-circuit-breaker-00 (work in progress),
progress), May 2014. September 2014.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998. 1998.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
2914, September 2000. 2914, September 2000.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating
 End of changes. 27 change blocks. 
91 lines changed or deleted 116 lines changed or added

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