draft-ietf-mpls-in-udp-06.txt   draft-ietf-mpls-in-udp-07.txt 
Network Working Group X. Xu Network Working Group X. Xu
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Informational N. Sheth Intended status: Standards Track N. Sheth
Expires: April 27, 2015 Juniper Networks Expires: April 27, 2015 Juniper Networks
L. Yong L. Yong
Huawei USA Huawei USA
C. Pignataro C. Pignataro
Cisco Systems Cisco Systems
Y. Fan Y. Fan
China Telecom China Telecom
R. Callon R. Callon
Juniper Networks Juniper Networks
D. Black D. Black
EMC Corporation EMC Corporation
October 24, 2014 October 24, 2014
Encapsulating MPLS in UDP Encapsulating MPLS in UDP
draft-ietf-mpls-in-udp-06 draft-ietf-mpls-in-udp-07
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). The MPLS-in-UDP encapsulation
technology MUST only be deployed within a service provider network or technology MUST only be deployed within a service provider network or
networks of an adjacent set of co-operating service providers where networks of an adjacent set of co-operating service providers where
congestion control is not a concern. congestion control is not a concern.
Status of This Memo Status of This Memo
skipping to change at page 4, line 25 skipping to change at page 4, line 25
operating SPs where congestion control is not a concern, rather than operating SPs where congestion control is not a concern, rather than
over the Internet where congestion control is required. Furthermore, over the Internet where congestion control is required. Furthermore,
packet filters SHOULD be added to prevent MPLS-in-UDP packets from packet filters SHOULD be added to prevent MPLS-in-UDP packets from
escaping from the service provider networks due to misconfiguation or escaping from the service provider networks due to misconfiguation or
packet errors. packet errors.
2. Terminology 2. Terminology
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 RFC 2119 [RFC2119].. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Encapsulation in UDP 3. Encapsulation in UDP
MPLS-in-UDP encapsulation format is shown as follows: MPLS-in-UDP encapsulation format is shown 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port = Entropy | Dest Port = MPLS | | Source Port = Entropy | Dest Port = MPLS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 46 skipping to change at page 11, line 46
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.fairhurst-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
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
skipping to change at page 13, line 8 skipping to change at page 13, line 8
traffic across VPN boundaries. Such leakage is highly undesirable traffic across VPN boundaries. Such leakage is highly undesirable
when inter-VPN isolation is used for privacy or security reasons. when inter-VPN isolation is used for privacy or security reasons.
When that is the case, UDP checksums SHOULD be used for MPLS-in-UDP When that is the case, UDP checksums SHOULD be used for MPLS-in-UDP
with both IPv4 and IPv6, and in particular, UDP zero-checksum mode with both IPv4 and IPv6, and in particular, UDP zero-checksum mode
SHOULD NOT be used with IPv6. Each UDP checksum covers the VPN SHOULD NOT be used with IPv6. Each UDP checksum covers the VPN
label, thereby providing increased assurance of isolation among VPNs. label, thereby providing increased assurance of isolation among VPNs.
7. IANA Considerations 7. IANA Considerations
One UDP destination port number indicating MPLS needs to be allocated One UDP destination port number indicating MPLS needs to be allocated
by IANA.: by IANA:
Service Name: MPLS-in-UDP Service Name: MPLS-in-UDP
Transport Protocol(s): UDP Transport Protocol(s): UDP
Assignee: IESG <iesg@ietf.org> Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>. Contact: IETF Chair <chair@ietf.org>.
Description: Encapsulate MPLS packets in UDP tunnels. Description: Encapsulate MPLS packets in UDP tunnels.
skipping to change at page 15, line 5 skipping to change at page 14, line 50
[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.
[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.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating
MPLS in IP or Generic Routing Encapsulation (GRE)", RFC
4023, March 2005.
[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.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405, November
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.
[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.
skipping to change at page 15, line 37 skipping to change at page 15, line 34
progress), May 2014. progress), May 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
MPLS in IP or Generic Routing Encapsulation (GRE)", RFC
4023, March 2005.
[RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., and [RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., and
J. Young, "Encapsulation of MPLS over Layer 2 Tunneling J. Young, "Encapsulation of MPLS over Layer 2 Tunneling
Protocol Version 3", RFC 4817, March 2007. Protocol Version 3", RFC 4817, March 2007.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405, November
2008.
[RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load- [RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load-
Balancing for Mesh Softwires", RFC 5640, August 2009. Balancing for Mesh Softwires", RFC 5640, August 2009.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation in for Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, November 2011. Tunnels", RFC 6438, November 2011.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, January Locator/ID Separation Protocol (LISP)", RFC 6830, January
2013. 2013.
 End of changes. 9 change blocks. 
13 lines changed or deleted 13 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/