idnits 2.17.1 draft-xu-bier-non-mpls-encap-over-udp-04.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 22, 2019) is 1914 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) == Unused Reference: 'RFC6936' is defined on line 296, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Xu 3 Internet-Draft Alibaba Inc. 4 Intended status: Standards Track G. Shepherd 5 Expires: July 26, 2019 Cisco 6 January 22, 2019 8 Encapsulating Non-MPLS-BIER in UDP 9 draft-xu-bier-non-mpls-encap-over-udp-04 11 Abstract 13 Bit Index Explicit Replication (BIER) is a new multicast forwarding 14 paradigm which doesn't require an explicit tree-building protocol nor 15 intermediate routers to maintain any multicast state. BIER has two 16 types of encapsulation formats: one is MPLS-BIER encapsulation, the 17 other is non-MPLS-BIER encapsulation. This document proposes a 18 mechanism of encapsulating non-MPLS-BIER packets over UDP tunnels. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 26, 2019. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. Encapsulation in UDP . . . . . . . . . . . . . . . . . . . . 3 58 4. Processing Procedures . . . . . . . . . . . . . . . . . . . . 4 59 5. Congestion Considerations . . . . . . . . . . . . . . . . . . 5 60 6. Applicability Statements . . . . . . . . . . . . . . . . . . 5 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 66 10.2. Informative References . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Introduction 71 Bit Index Explicit Replication (BIER) [RFC8279] is a new multicast 72 forwarding paradigm which doesn't require an explicit tree-building 73 protocol nor intermediate routers to maintain any multicast state. 74 As described in Section 6.9 of [RFC8279], a BFR may need to tunnel a 75 BIER packet over a certain kind of tunnel, e.g., UDP tunnel. 77 [RFC8296] defines two types of BIER encapsulation formats: one is 78 MPLS-BIER encapsulation, the other is non-MPLS-BIER encapsulation. 79 MPLS-BIER packets can be transported over UDP tunnels by using the 80 MPLS-in-UDP encapsulation as described in [RFC7510] . This document 81 proposes a mechanism of encapsulating non-MPLS-BIER packets over UDP 82 tunnels. 84 1.1. Requirements Language 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC 2119 [RFC2119]. 90 2. Terminology 92 This memo makes use of the terms defined in [RFC8279]and [RFC8296]. 94 3. Encapsulation in UDP 96 Non-MPLS-BIER-in-UDP encapsulation format is shown as follows: 98 0 1 2 3 99 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 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 | Source Port = Entropy | Dest Port = TBD1 | 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 | UDP Length | UDP Checksum | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | | 106 ~ Non-MPLS-BIER Packet ~ 107 | | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 Figure 1: Non-MPLS-BIER-in-UDP Encapsulation Format 111 Source Port of UDP: 113 This field contains a 16-bit entropy value that is generated by 114 the encapsulator to uniquely identify a flow. What constitutes 115 a flow is locally determined by the encapsulator and therefore 116 is outside the scope of this document. What algorithm is 117 actually used by the encapsulator to generate an entropy value 118 is outside the scope of this document. For example, the 20-bit 119 entropy value contained in the BIER header could actually be 120 transformed to a 16- bit value and then be filled into this 121 field. 123 In case the tunnel does not need entropy, this field of all 124 packets belonging to a given flow SHOULD be set to a randomly 125 selected constant value so as to avoid packet reordering. 127 To ensure that the source port number is always in the range 128 49152 to 65535 (Note that those ports less than 49152 are 129 reserved by IANA to identify specific applications/protocols) 130 which may be required in some cases, instead of calculating a 131 16-bit hash, the encapsulator SHOULD calculate a 14-bit hash 132 and use those 14 bits as the least significant bits of the 133 source port field while the most significant two bits SHOULD be 134 set to binary 11. That still conveys 14 bits of entropy 135 information which would be enough as well in practice. 137 Destination Port of UDP: 139 This field is set to a value (TBD1) allocated by IANA to 140 indicate that the UDP tunnel payload is a non-MPLS-BIER packet. 142 UDP Length: 144 The usage of this field is in accordance with the current UDP 145 specification [RFC0768]. 147 UDP Checksum: 149 For IPv4 UDP encapsulation, this field is RECOMMENDED to be set 150 to zero for performance or implementation reasons because the 151 IPv4 header includes a checksum and use of the UDP checksum is 152 optional with IPv4. For IPv6 UDP encapsulation, the IPv6 153 header does not include a checksum, so this field MUST contain 154 a UDP checksum that MUST be used as specified in [RFC0768] and 155 [RFC2460] unless one of the exceptions that allows use of UDP 156 zero-checksum mode (as specified in [RFC6935]) applies. 158 Non-MPLS-BIER Packet: 160 This field contains one non-MPLS-BIER packet. 162 4. Processing Procedures 164 This Non-MPLS-BIER-in-UDP encapsulation causes non-MPLS BIER packets 165 to be forwarded across an IP transit core via "UDP tunnels". While 166 performing Non-MPLS-BIER-in-UDP encapsulation, an encapsulator would 167 generate an entropy value and encode it in the Source Port field of 168 the UDP header. The Destination Port field is set to a value (TBD1) 169 allocated by IANA to indicate that the UDP tunnel payload is a non- 170 MPLS-BIER packet. Transit routers, upon receiving these UDP 171 encapsulated non-MPLS-BIER packets, could balance these packets based 172 on the hash of the five-tuple of UDP packets. Decapsulators 173 receiving these UDP encapsulated non-MPLS-BIER packets MUST 174 decapsulate these packets by removing the UDP header and then forward 175 them accordingly. 177 Similar to all other IP-based tunneling technologies, Non-MPLS-BIER- 178 in-UDP encapsulation introduces overheads and reduces the effective 179 Maximum Transmission Unit (MTU) size. Non-MPLS-BIER-in-UDP 180 encapsulation may also impact Time-to-Live (TTL) or Hop Count (HC) 181 and Differentiated Services (DSCP). Hence, Non-MPLS-BIER-in-UDP MUST 182 follow the corresponding procedures defined in [RFC2003]. 184 Encapsulators MUST NOT fragment non-MPLS-BIER packet, and when the 185 outer IP header is IPv4, encapsulators MUST set the DF bit in the 186 outer IPv4 header. It is strongly RECOMMENDED that IP transit core 187 be configured to carry an MTU at least large enough to accommodate 188 the added encapsulation headers. Meanwhile, it is strongly 189 RECOMMENDED that Path MTU Discovery [RFC1191] [RFC1981] or 190 Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] is used to 191 prevent or minimize fragmentation. 193 5. Congestion Considerations 195 As it's explicitly stated in the Application Statements (Section 6), 196 this Non-MPLS-BIER-in-UDP encapsulation method MUST only be used 197 within networks that are well-managed, therefore, congestion control 198 mechanism is not needed. 200 6. Applicability Statements 202 This Non-MPLS-BIER-in-UDP encapsulation technology MUST only be used 203 within networks which are well-managed by a service provider and MUST 204 NOT be used within the Internet. In the well-managed network, 205 traffic is well-managed to avoid congestion and fragmentation on 206 encapsulated packets (i.e., Non-MPLS-BIER packets) are not needed. 208 7. Acknowledgements 210 TBD. 212 8. IANA Considerations 214 One UDP destination port number indicating non-MPLS-BIER needs to be 215 allocated by IANA: 217 Service Name: Non-MPLS-BIER-in-UDP Transport Protocol(s):UDP 218 Assignee: IESG 219 Contact: IETF Chair . 220 Description: Encapsulate Non-MPLS-BIER packets in UDP tunnels. 221 Reference: This document. 222 Port Number: TBD1 -- To be assigned by IANA. 224 One UDP destination port number indicating Non-MPLS-BIER with DTLS 225 needs to be allocated by IANA: 227 Service Name: Non-MPLS-BIER-in-UDP-with-DTLS 228 Transport Protocol(s): UDP 229 Assignee: IESG 230 Contact: IETF Chair . 231 Description: Encapsulate Non-MPLS-BIER packets in UDP tunnels with DTLS. 232 Reference: This document. 233 Port Number: TBD2 -- To be assigned by IANA. 235 9. Security Considerations 237 The security problems faced with the Non-MPLS-BIER-in-UDP tunnel are 238 exactly the same as those faced with MPLS-in-UDP tunnel [RFC7510]. 239 In other words, the Non-MPLS-BIER-in-UDP tunnel as defined in this 240 document by itself cannot ensure the integrity and privacy of data 241 packets being transported through the Non-MPLS-BIER-in-UDP tunnel and 242 cannot enable the tunnel decapsulator to authenticate the tunnel 243 encapsulator. In the case where any of the above security issues is 244 concerned, the Non-MPLS-BIER-in-UDP tunnel SHOULD be secured with 245 IPsec or DTLS. IPsec was designed as a network security mechanism 246 and therefore it resides at the network layer. As such, if the 247 tunnel is secured with IPsec, the UDP header would not be visible to 248 intermediate routers anymore in either IPsec tunnel or transport 249 mode. As a result, the meaning of adopting the Non-MPLS-BIER-in-UDP 250 tunnel as an alternative to the Non-MPLS-BIER-in-GRE or Non-MPLS- 251 BIER-in-IP tunnel is lost. By comparison, DTLS is better suited for 252 application security and can better preserve network and transport 253 layer protocol information. Specifically, if DTLS is used, the 254 destination port of the UDP header will be filled with a value (TBD2) 255 indicating non-MPLS-BIER with DTLS and the source port can still be 256 used as an entropy field for load-sharing purposes. 258 10. References 260 10.1. Normative References 262 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 263 DOI 10.17487/RFC0768, August 1980, 264 . 266 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 267 DOI 10.17487/RFC1191, November 1990, 268 . 270 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 271 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 272 1996, . 274 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 275 DOI 10.17487/RFC2003, October 1996, 276 . 278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 279 Requirement Levels", BCP 14, RFC 2119, 280 DOI 10.17487/RFC2119, March 1997, 281 . 283 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 284 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 285 December 1998, . 287 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 288 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 289 . 291 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 292 UDP Checksums for Tunneled Packets", RFC 6935, 293 DOI 10.17487/RFC6935, April 2013, 294 . 296 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 297 for the Use of IPv6 UDP Datagrams with Zero Checksums", 298 RFC 6936, DOI 10.17487/RFC6936, April 2013, 299 . 301 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 302 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 303 Explicit Replication (BIER)", RFC 8279, 304 DOI 10.17487/RFC8279, November 2017, 305 . 307 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 308 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 309 for Bit Index Explicit Replication (BIER) in MPLS and Non- 310 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 311 2018, . 313 10.2. Informative References 315 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 316 "Encapsulating MPLS in UDP", RFC 7510, 317 DOI 10.17487/RFC7510, April 2015, 318 . 320 Authors' Addresses 322 Xiaohu Xu 323 Alibaba Inc. 325 Email: xiaohu.xxh@alibaba-inc.com 327 Greg Shepherd 328 Cisco 330 Email: gjshep@gmail.com