draft-ietf-mpls-in-udp-10.txt   draft-ietf-mpls-in-udp-11.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: July 18, 2015 Juniper Networks Expires: August 4, 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
January 14, 2015 January 31, 2015
Encapsulating MPLS in UDP Encapsulating MPLS in UDP
draft-ietf-mpls-in-udp-10 draft-ietf-mpls-in-udp-11
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) for situations where UDP MPLS-in-UDP (User Datagram Protocol) for situations where UDP
encapsulation is preferred to direct use of MPLS, e.g., to enable encapsulation is preferred to direct use of MPLS, e.g., to enable
UDP-based ECMP (Equal Cost Multi-Pathing) or link aggregation. The UDP-based ECMP (Equal Cost Multi-Pathing) or link aggregation. The
MPLS-in-UDP encapsulation technology must only be deployed within a MPLS-in-UDP encapsulation technology must only be deployed within a
single network (with a single network operator) or networks of an single network (with a single network operator) or networks of an
adjacent set of co-operating network operators where traffic is adjacent set of co-operating network operators where traffic is
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 July 18, 2015. This Internet-Draft will expire on August 4, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 33 skipping to change at page 2, line 33
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. Applicability Statements . . . . . . . . . . . . . . . . 4 1.3. Applicability 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 . . 9 3.2. Middlebox Considerations for IPv6 UDP Zero Checksums . . 9
4. Processing Procedures . . . . . . . . . . . . . . . . . . . . 9 4. Processing Procedures . . . . . . . . . . . . . . . . . . . . 9
5. Congestion Considerations . . . . . . . . . . . . . . . . . . 10 5. Congestion Considerations . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 17
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 7, line 27 skipping to change at page 7, line 27
if each non-cooperating network administration independently if each non-cooperating network administration independently
satisfies one or more of the exceptions for UDP zero-checksum mode satisfies one or more of the exceptions for UDP zero-checksum mode
usage with MPLS-in-UDP over IPv6. 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. The 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 node SHOULD only allow the use of UDP c. The tunnel decapsulator SHOULD only allow the use of UDP zero-
zero-checksum mode for IPv6 on a single received UDP Destination checksum mode for IPv6 on a single received UDP Destination Port
Port regardless of the sender. The motivation for this regardless of the encapsulator. The motivation for this
requirement is possible corruption of the UDP destination port, requirement is possible corruption of the UDP destination port,
which may cause packet delivery to the wrong UDP port. If that which may cause packet delivery to the wrong UDP port. If that
other UDP port requires the UDP checksum, the misdelivered packet other UDP port requires the UDP checksum, the misdelivered packet
will be discarded will be discarded
d. An MPLS-in-UDP receiver MUST check that the source and d. The tunnel decapsulator 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
on which the packet was received if that tunnel uses UDP zero- on which the packet was received if that tunnel uses UDP zero-
checksum mode and discard any packet for which this check fails. checksum mode and discard any packet for which this check fails.
e. An MPLS-in-UDP sender SHOULD use different IPv6 addresses for e. The tunnel encapsulator SHOULD use different IPv6 addresses for
each MPLS-in-UDP tunnel that uses UDP zero-checksum mode each MPLS-in-UDP tunnel that uses UDP zero-checksum mode
regardless of receiver in order to strengthen the receiver's regardless of decapsulator in order to strengthen the
check of the IPv6 source address. When this is not possible, it decapsulator's check of the IPv6 source address (i.e., the same
is RECOMMENDED to use each source IPv6 address for as few UDP IPv6 source address SHOULD NOT be used with more than one IPv6
zero-checksum mode MPLS-in-UDP tunnels as is feasible. destination address, independent of whether that destination
address is a unicast or multicast address). When this is not
possible, it is RECOMMENDED to use each source IPv6 address for
as few UDP zero-checksum mode MPLS-in-UDP tunnels (i.e., with as
few destination IPv6 addresses) as is feasible.
f. Any middlebox support for MPLS-in-UDP with UDP zero-checksum mode f. 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]. [RFC6936].
g. Measures SHOULD be taken to prevent IPv6 traffic with zero UDP g. Measures SHOULD be taken to prevent IPv6 traffic with zero UDP
checksums from "escaping" to the general Internet; see Section 5 checksums from "escaping" to the general Internet; see Section 5
for examples of such measures. for examples of such measures.
h. IPv6 traffic with zero UDP checksums MUST be actively monitored h. IPv6 traffic with zero UDP checksums MUST be actively monitored
for errors by the network operator. for errors by the network operator.
The above requirements do not change either the requirements The above requirements do not change either the requirements
specified in [RFC2460] as modified by [RFC6935] or the requirements specified in [RFC2460] as modified by [RFC6935] or the requirements
skipping to change at page 9, line 47 skipping to change at page 9, line 49
UDP checksum are described in Section 5 of [RFC6936]. UDP checksum are described in Section 5 of [RFC6936].
4. Processing Procedures 4. Processing Procedures
This MPLS-in-UDP encapsulation causes MPLS packets to be forwarded This MPLS-in-UDP encapsulation causes MPLS packets to be forwarded
through "UDP tunnels". When performing MPLS-in-UDP encapsulation by through "UDP tunnels". When performing MPLS-in-UDP encapsulation by
the encapsulator, the entropy value would be generated by the the encapsulator, the entropy value would be generated by the
encapsulator and then be filled in the Source Port field of the UDP encapsulator and then be filled in the Source Port field of the UDP
header. The Destination Port field is set to a value (TBD1) header. The Destination Port field is set to a value (TBD1)
allocated by IANA to indicate that the UDP tunnel payload is an MPLS allocated by IANA to indicate that the UDP tunnel payload is an MPLS
packet. As for whether the top label in the MPLS label stack is packet. As for whether the top label of the encapsulated MPLS packet
downstream-assigned or upstream-assigned, it SHOULD be determined is downstream-assigned or upstream-assigned, it is determined
based on the tunnel destination IP address. That is to say, if the according to the following criteria which are compatible with
destination IP address is a multicast address, the top label SHOULD [RFC5332]:
be upstream-assigned, otherwise if the destination IP address is a
unicast address, it SHOULD be downstream-assigned. Intermediate a. If the tunnel destination IP address is a unicast address, the
routers, upon receiving these UDP encapsulated packets, could balance top label MUST be downstream-assigned;
these packets based on the hash of the five-tuple of UDP packets.
Upon receiving these UDP encapsulated packets, the decapsulator would b. If the tunnel destination IP address is an IP multicast address,
decapsulate them by removing the UDP headers and then process them either all encapsulated MPLS packets in the particular tunnel
accordingly. For other common processing procedures associated with have a downstream-assigned label at the top of the stack, or all
tunneling encapsulation technologies including but not limited to encapsulated MPLS packets in that tunnel have an upstream-
Maximum Transmission Unit (MTU) and preventing fragmentation and assigned label at the top of the stack. The means by which this
reassembly, Time to Live (TTL) and differentiated services, the is determined for a particular tunnel is outside the scope of
corresponding "Common Procedures" defined in [RFC4023] which are this specification. In the absence of any knowledge about a
applicable for MPLS-in-IP and MPLS-in-GRE encapsulation formats specific tunnel, the label SHOULD be presumed to be upstream-
SHOULD be followed. assigned.
Intermediate routers, upon receiving these UDP encapsulated packets,
could balance these packets based on the hash of the five-tuple of
UDP packets. Upon receiving these UDP encapsulated packets, the
decapsulator would decapsulate them by removing the UDP headers and
then process them accordingly. For other common processing
procedures associated with tunneling encapsulation technologies
including but not limited to Maximum Transmission Unit (MTU) and
preventing fragmentation and reassembly, Time to Live (TTL) and
differentiated services, the corresponding "Common Procedures"
defined in [RFC4023] which are applicable for MPLS-in-IP and MPLS-in-
GRE encapsulation formats SHOULD be followed.
Note: Each UDP tunnel is unidirectional, as MPLS-in-UDP traffic is
sent to the IANA-allocated UDP Destination Port, and in particular,
is never sent back to any port used as a UDP Source Port (which
serves solely as a source of entropy). This is at odds with a common
middlebox (e.g., firewall) assumption that bidirectional traffic uses
a common pair of UDP ports. As a result, arranging to pass
bidirectional MPLS-in-UDP traffic through middleboxes may require
separate configuration for each direction of traffic.
5. Congestion Considerations 5. Congestion Considerations
Section 3.1.3 of [RFC5405] discussed the congestion implications of Section 3.1.3 of [RFC5405] discussed the congestion implications of
UDP tunnels. As discussed in [RFC5405], because other flows can UDP tunnels. As discussed in [RFC5405], because other flows can
share the path with one or more UDP tunnels, congestion control share the path with one or more UDP tunnels, congestion control
[RFC2914] needs to be considered. [RFC2914] needs to be considered.
A major motivation for encapsulating MPLS in UDP is to improve the A major motivation for encapsulating MPLS in UDP is to improve the
use of multipath (such as ECMP) in cases where traffic is to traverse use of multipath (such as ECMP) in cases where traffic is to traverse
skipping to change at page 12, line 34 skipping to change at page 13, line 9
concerned, the MPLS-in-UDP tunnel SHOULD be secured with IPsec or concerned, the MPLS-in-UDP tunnel SHOULD be secured with IPsec or
DTLS. IPsec was designed as a network security mechanism and DTLS. IPsec was designed as a network security mechanism and
therefore it resides at the network layer. As such, if the tunnel is therefore it resides at the network layer. As such, if the tunnel is
secured with IPsec, the UDP header would not be visible to secured with IPsec, the UDP header would not be visible to
intermediate routers anymore in either IPsec tunnel or transport intermediate routers anymore in either IPsec tunnel or transport
mode. As a result, the meaning of adopting the MPLS-in-UDP tunnel as mode. As a result, the meaning of adopting the MPLS-in-UDP tunnel as
an alternative to the MPLS-in-GRE or MPLS-in-IP tunnel is lost. By an alternative to the MPLS-in-GRE or MPLS-in-IP tunnel is lost. By
comparison, DTLS is better suited for application security and can comparison, DTLS is better suited for application security and can
better preserve network and transport layer protocol information. better preserve network and transport layer protocol information.
Specifically, if DTLS is used, the destination port of the UDP header Specifically, if DTLS is used, the destination port of the UDP header
will be filled with a value (TBD2) indicating MPLS with DTLS and the MUST be set to an IANA-assigned value (TBD2) indicating MPLS-in-UDP
source port can still be used as an entropy field for load-sharing with DTLS, and that UDP port MUST NOT be used for other traffic. The
purposes. UDP source port field can still be used to add entropy, e.g., for
load-sharing purposes. DTLS usage is limited to a single DTLS
session for any specific tunnel encapsulator/ decapsulator pair
(identified by source and destination IP addresses). Both IP
addresses MUST be unicast addresses - multicast traffic is not
supported when DTLS is used. An MPLS-in-UDP tunnel decapsulator
implementation that supports DTLS is expected to be able to establish
DTLS sessions with multiple tunnel encapsulators, and likewise an
MPLS-in-UDP tunnel encapsulator implementation is expected to be able
to establish DTLS sessions with multiple decapsulators (although
different source and/or destination IP addresses may be involved -
see Section 3.1 for discussion of one situation where use of
different source IP addresses is important).
If the tunnel is not secured with IPsec or DTLS, some other method If the tunnel is not secured with IPsec or DTLS, some other method
should be used to ensure that packets are decapsulated and forwarded should be used to ensure that packets are decapsulated and forwarded
by the tunnel tail only if those packets were encapsulated by the by the tunnel tail only if those packets were encapsulated by the
tunnel head. If the tunnel lies entirely within a single tunnel head. If the tunnel lies entirely within a single
administrative domain, address filtering at the boundaries can be administrative domain, address filtering at the boundaries can be
used to ensure that no packet with the IP source address of a tunnel used to ensure that no packet with the IP source address of a tunnel
endpoint or with the IP destination address of a tunnel endpoint can endpoint or with the IP destination address of a tunnel endpoint can
enter the domain from outside. However, when the tunnel head and the enter the domain from outside. However, when the tunnel head and the
tunnel tail are not in the same administrative domain, this may tunnel tail are not in the same administrative domain, this may
skipping to change at page 15, line 14 skipping to change at page 15, line 43
Email: curtis@occnc.com Email: curtis@occnc.com
9. Acknowledgements 9. Acknowledgements
Thanks to Shane Amante, Dino Farinacci, Keshava A K, Ivan Pepelnjak, Thanks to Shane Amante, Dino Farinacci, Keshava A K, Ivan Pepelnjak,
Eric Rosen, Andrew G. Malis, Kireeti Kompella, Marshall Eubanks, Eric Rosen, Andrew G. Malis, Kireeti Kompella, Marshall Eubanks,
George Swallow, Loa Andersson, Vivek Kumar, Stewart Bryant, Wen George Swallow, Loa Andersson, Vivek Kumar, Stewart Bryant, Wen
Zhang, Joel M. Halpern, Noel Chiappa, Scott Brim, Alia Atlas, Zhang, Joel M. Halpern, Noel Chiappa, Scott Brim, Alia Atlas,
Alexander Vainshtein, Joel Jaeggli, Edward Crabbe, Mark Tinka, Lars Alexander Vainshtein, Joel Jaeggli, Edward Crabbe, Mark Tinka, Lars
Eggert, Joe Touch, Lloyd Wood, Gorry Fairhurst, Weiguo Hao, Mark Eggert, Joe Touch, Lloyd Wood, Gorry Fairhurst, Weiguo Hao, Mark
Szczesniak, Zhenxiao Liu and Xing Tong for their valuable comments Szczesniak, Stephen Farrell, Zhenxiao Liu and Xing Tong for their
and suggestions on this document. valuable comments and suggestions on this document.
Special thanks to Alia Atlas for her insightful suggestion of adding Special thanks to Alia Atlas for her insightful suggestion of adding
an applicability statement. an applicability statement.
Thanks to Daniel King, Gregory Mirsky and Eric Osborne for their Thanks to Daniel King, Gregory Mirsky and Eric Osborne for their
valuable MPLS-RT reviews on this document. Thanks to Charlie Kaufman valuable MPLS-RT reviews on this document. Thanks to Charlie Kaufman
for his SecDir review of this document. Thanks to Nevil Brownlee for for his SecDir review of this document. Thanks to Nevil Brownlee for
the OPSDir review of this document. Thanks to Roni Even for the Gen- the OPSDir review of this document. Thanks to Roni Even for the Gen-
ART review of this document. Thanks to Pearl Liang for the IANA ART review of this document. Thanks to Pearl Liang for the IANA
review of this documents. review of this documents.
skipping to change at page 15, line 47 skipping to change at page 16, line 35
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001. Encoding", RFC 3032, January 2001.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS
Multicast Encapsulations", RFC 5332, August 2008.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405, November for Application Designers", BCP 145, RFC 5405, November
2008. 2008.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012.
[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.
 End of changes. 16 change blocks. 
42 lines changed or deleted 82 lines changed or added

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