idnits 2.17.1 draft-bryant-pals-ethernet-cw-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4448, updated by this document, for RFC5378 checks: 2002-09-04) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 02, 2017) is 2458 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PALS Working Group S. Bryant 3 Internet-Draft A. Malis 4 Updates: 4448 (if approved) Huawei 5 Intended status: Standards Track I. Bagdonas 6 Expires: February 3, 2018 Equinix 7 August 02, 2017 9 Use of Ethernet Control Word RECOMMENDED 10 draft-bryant-pals-ethernet-cw-01 12 Abstract 14 The pseudowire (PW) encapsulation of Ethernet, as defined in RFC4448, 15 specifies that the use of the control word (CW) is optional. In the 16 absence of the CW an Ethernet pseudowire packet can be misidentified 17 as an IP packet by a label switching router (LSR). This in turn may 18 lead to the selection of the wrong equal-cost-multi-path (ECMP) path 19 for the packet, leading in turn to the mis-ordering of packets. This 20 problem has become more serious due to the deployment of equipment 21 with Ethernet MAC addresses that start with 0x4 or 0x6. The use of 22 the Ethernet PW CW addresses this problem. This document recommends 23 the use of the Ethernet pseudowire control word in all but 24 exceptional circumstances. 26 This document updates RFC4448. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on February 3, 2018. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 64 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Recommendation . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. Equal Cost Multi-path (ECMP) . . . . . . . . . . . . . . . . 5 67 6. Mitigations . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 7. Operational Considerations . . . . . . . . . . . . . . . . . 6 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 71 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 74 11.2. Informative References . . . . . . . . . . . . . . . . . 7 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 The pseudowire(PW) encapsulation of Ethernet, as defined in RFC4448, 80 specifies that the use of the control word (CW) is optional. It is 81 common for label switching routers (LSRs) to search past the end of 82 the label stack to determine whether the payload is an IP packet, and 83 if the payload is an IP packet, to select the next hop based of the 84 so called "five-tuple" (IP source address, IP destination address, 85 protocol/next-header, transport layer source port and transport layer 86 destination port). In the absence of a PW CW an Ethernet pseudowire 87 packet can be misidentified as an IP packet by a label switching 88 router (LSR) selecting the ECMP path based on the five-tuple. This 89 in turn may lead to the selection of the wrong equal-cost-multi-path 90 (ECMP) path for the packet, leading in turn to the mis-ordering of 91 packets. Further discussion of this topic is published in [RFC4928]. 93 Flow misordering can also happen in a single path scenario when 94 traffic classification and differential forwarding treatment 95 mechanisms are in use. This occurs when a forwarder incorrectly 96 assumes that the packet is IP and applies forwarding policy based on 97 fields in the PW payload. 99 This problem has recently become more serious for a number of 100 reasons. Firsly due to the deployment of equipment with Ethernet MAC 101 addresses that start with 0x4 or 0x6 assigned by the IEEE RAC. 102 Secondly, concerns over privacy have led to the use of MAC address 103 randomization which assigns local MAC addresses randomly for privacy. 104 Random assignmen produce addresses starting with one of the two 105 values about 1/8 of the time. 107 The use of the Ethernet PW CW addresses this problem. 109 This document recommends the use of the Ethernet pseudowire control 110 word in all but exceptional circumstances. 112 2. Specification of Requirements 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 3. Background 120 Ethernet pseudowire encapsulation is specified in [RFC4448]. In 121 particular the reader is drawn to section 4.6, part of which is 122 quoted below for the convenience of the reader: 124 "The control word defined in this section is based on the Generic 125 PW MPLS Control Word as defined in [RFC4385]. It provides the 126 ability to sequence individual frames on the PW, avoidance of 127 equal-cost multiple-path load-balancing (ECMP) [RFC2992], and 128 Operations and Management (OAM) mechanisms including VCCV 129 [RFC5085]. 131 "[RFC4385] states, "If a PW is sensitive to packet misordering 132 and is being carried over an MPLS PSN that uses the contents 133 of the MPLS payload to select the ECMP path, it MUST employ a 134 mechanism which prevents packet misordering." This is necessary 135 because ECMP implementations may examine the first nibble after 136 the MPLS label stack to determine whether the labeled packet 137 is IP or not. Thus, if the source MAC address of an Ethernet 138 frame carried over the PW without a control word present begins 139 with 0x4 or 0x6, it could be mistaken for an IPv4 or IPv6 140 packet. This could, depending on the configuration and 141 topology of the MPLS network, lead to a situation where all 142 packets for a given PW do not follow the same path. This may 143 increase out-of-order frames on a given PW, or cause OAM packets 144 to follow a different path than actual traffic (see 145 Section 4.4.3, "Frame Ordering"). 147 "The features that the control word provides may not be needed 148 for a given Ethernet PW. For example, ECMP may not be present 149 or active on a given MPLS network, strict frame sequencing may 150 not be required, etc. If this is the case, the control word 151 provides little value and is therefore optional. Early Ethernet 152 PW implementations have been deployed that do not include a 153 control word or the ability to process one if present. To 154 aid in backwards compatibility, future implementations MUST 155 be able to send and receive frames without the control word 156 present." 158 At the time when pseudowires were first deployed, some equipment of 159 commercial significance was unable to process the Ethernet Control 160 Word. In addition, at that time it was considered that no Ethernet 161 MAC address had been issued by the IEEE Registration Authority 162 Committee (RAC) that starts with 0x4 or 0x6, and thus it was thought 163 to be safe to deploy Ethernet PWs without the CW. 165 Since that time the RAC has issued Ethernet MAC addresses start with 166 0x4 or 0x6 and thus the assumption that in practical networks there 167 would be no confusion between an Ethernet PW packet without the CW 168 and an IP packet is no longer correct. 170 Possibly through the use of unauthorized Ethernet MAC addresses, this 171 assumption has been unsafe for a while, leading some equipment 172 vendors to implement more complex, proprietary, methods to 173 discriminate between Ethernet PW packets and IP packets. Such 174 mechanisms rely on the heuristics of examining the transit packets in 175 trying to find out the exact payload type of the packet and cannot be 176 reliable due to the random nature of the payload carried within such 177 packets. 179 A recent posting on the Nanog email list has highlighted this 180 problem: 182 https://mailman.nanog.org/pipermail/nanog/2016-December/089395.html 184 RFC EDITOR Please delete this paragraph. 185 Kramdown does not include references when they are only found in 186 literal text so I include them here: [RFC4385] [RFC2992] [RFC5085] as 187 a fixup. 189 4. Recommendation 191 The ambiguity between an MPLS payload that is a Ethernet PW and one 192 that is an IP packet is resolved when the Ethernet PW control word is 193 used. This document updates RFC4448 [RFC4448] to state that where 194 both both the ingress PE and the egress PE support the Ethernet 195 pseudowire control word, then the CW MUST be used. 197 5. Equal Cost Multi-path (ECMP) 199 Where the volume of traffic on an Ethernet PW is such that ECMP is 200 required then one of two methods may be used: 202 o Flow-Aware Transport (FAT) of Pseudowires over an MPLS Packet 203 Switched Network specified in [RFC6391], or 205 o LSP entropy labels specified [RFC6790] 207 RFC6391 works by increasing the entropy of the bottom of stack label. 208 It requires that both the ingress and egress provider edge (PE)s 209 support this feature. It also requires that sufficient LSRs on the 210 LSP between the ingress and egress PE be able to select an 211 ECMP path on an MPLS packet with the resultant stack depth. 213 RFC6790 works by including an entropy value in the LSP part of the 214 label stack. This requires that the Ingress and Egress PEs support 215 the insertion and removal of the entropy label (EL) and the entropy 216 label indicator, and that sufficient LSRs on the LSP are able to 217 preform ECMP based on the EL. 219 In both cases there considerations in getting Operations, 220 Administration, and Maintenance (OAM) packets to follow the same path 221 as a data packet. This is described in detail section 7 of 222 [RFC6391], and section 6 of RFC6790. However in both cases the 223 situation is improved compared to the ECMP behavior in the case where 224 the Ethernet PW CW was not used, since there is currently no known 225 method of getting a PW OAM packet to follow the same path as a PW 226 data packet subjected to ECMP based on the five tuple of the IP 227 payload. 229 6. Mitigations 231 Where it is not possible to use the Ethernet PW CW, the effects of 232 ECMP can be disabled by carrying the PW over a traffic engineered 233 path that does not subject the payload to load balancing (for example 234 [RFC3209]. However such paths may be subjected to link bundle load 235 balancing and of course the single LSP has to carry the full PW load. 237 7. Operational Considerations 239 CW presence on the PW is controlled by the configuration and may be 240 subject to default operational mode of not being enabled. Care needs 241 to be taken to ensure that software that implements this 242 recommendation does not depend on existing configuration setting that 243 prevents the use of control word. It is recommended that platform 244 software emits a rate limited message indicating that CW can be used 245 but is disabled due to existing configuration. 247 To remove this problem in the long term, and hence to reduce the 248 operational cost of investigating problems associated with the 249 incorrect forwarding of Ethernet packets over PWs not using the CW, 250 it is RECOMMENDED that equipment that does not support the CW be 251 phased out of operational use. 253 8. Security Considerations 255 This document expresses a preference for one existing and widely 256 deployed Ethernet PW encapsulation over another. These methods have 257 identical security considerations, which are discussed in [RFC4448]. 258 This document introduces no additional security issues. 260 9. IANA Considerations 262 This document makes no IANA requests. 264 10. Acknowledgements 266 The authors thank Job Snijders for drawing attention to this problem. 267 The authors also thank Pat Thaler for clarifying the matter of local 268 MAC address assignment. 270 11. References 272 11.1. Normative References 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", BCP 14, RFC 2119, 276 DOI 10.17487/RFC2119, March 1997, 277 . 279 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 280 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 281 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 282 February 2006, . 284 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 285 "Encapsulation Methods for Transport of Ethernet over MPLS 286 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, 287 . 289 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 290 Cost Multipath Treatment in MPLS Networks", BCP 128, 291 RFC 4928, DOI 10.17487/RFC4928, June 2007, 292 . 294 [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., 295 Regan, J., and S. Amante, "Flow-Aware Transport of 296 Pseudowires over an MPLS Packet Switched Network", 297 RFC 6391, DOI 10.17487/RFC6391, November 2011, 298 . 300 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 301 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 302 RFC 6790, DOI 10.17487/RFC6790, November 2012, 303 . 305 11.2. Informative References 307 [RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path 308 Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000, 309 . 311 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 312 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 313 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 314 . 316 [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual 317 Circuit Connectivity Verification (VCCV): A Control 318 Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, 319 December 2007, . 321 Authors' Addresses 323 Stewart Bryant 324 Huawei 326 Email: stewart.bryant@gmail.com 328 Andrew G Malis 329 Huawei 331 Email: agmalis@gmail.com 333 Ignas Bagdonas 334 Equinix 336 Email: ibagdona.ietf@gmail.com>