idnits 2.17.1 draft-qian-6man-ipv6-multipath-mtu-detection-00.txt: -(474): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. 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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (1 March 2022) is 780 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: 'I-D.ietf-6man-mtu-option' is defined on line 441, but no explicit reference was found in the text == Unused Reference: 'RFC1191' is defined on line 448, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 457, but no explicit reference was found in the text == Unused Reference: 'RFC4821' is defined on line 461, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 469, but no explicit reference was found in the text == Unused Reference: 'RFC8899' is defined on line 474, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-6man-mtu-option-12 ** Downref: Normative reference to an Experimental draft: draft-ietf-6man-mtu-option (ref. 'I-D.ietf-6man-mtu-option') ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Qian 3 Internet-Draft T. Zhou 4 Intended status: Standards Track Huawei 5 Expires: 2 September 2022 1 March 2022 7 IPv6 Minimum Multipath MTU Detection 8 draft-qian-6man-ipv6-multipath-mtu-detection-00 10 Abstract 12 I In current multipath load balancing network scenario, all path 13 detection mechanisms have a defect. A typical load balancing route 14 selection mechanism cannot cover all forwarding paths, which will 15 cause missing detection.This document describes how to extend a new 16 path detection mechanism to instruct intermediate devices to send 17 probe packets to all downstream paths. This new mechanism is named 18 load-sharing multipath replication forwarding (LMRF). 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 24 "OPTIONAL" in this document are to be interpreted as described in BCP 25 14 [RFC2119] [RFC8174] when, and only when, they appear in all 26 capitals, as shown here. 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 https://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 2 September 2022. 45 Copyright Notice 47 Copyright (c) 2022 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 (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Scenario Description . . . . . . . . . . . . . . . . . . . . 3 64 3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3.2. Solution . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Detail solution . . . . . . . . . . . . . . . . . . . . . . . 5 67 4.1. IPv4 solution . . . . . . . . . . . . . . . . . . . . . . 5 68 4.2. IPv6 solution . . . . . . . . . . . . . . . . . . . . . . 5 69 4.2.1. Detection Solution . . . . . . . . . . . . . . . . . 5 70 4.2.2. Modifications to existing mechanisms . . . . . . . . 6 71 5. Supplementary description of the protocol . . . . . . . . . . 9 72 6. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 10. Normative References . . . . . . . . . . . . . . . . . . . . 10 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 In the current multipath load balancing scenario, a path detection 82 mechanism has a defect. A common load balancing route selection 83 solution cannot cover all forwarding paths, which causes missing 84 detection.This document describes how to extend a new probe mechanism 85 to instruct intermediate forwarding devices to send probe packets to 86 all downstream paths. 88 Typical problem: During path MTU detection, the path MTU of a path 89 cannot be used as the path MTU of all load balancing paths. In this 90 case, the source selects the minimum path MTU of different paths as 91 the path MTU of the entire path to ensure normal forwarding on the 92 intermediate network. 94 Currently, there are some solutions in the industry, such as the 95 Paris trace solution.By constructing a large number of packets at the 96 source and modifying information such as the transport-layer port 97 number of the packets, the forwarding device on the network can hash 98 the packets to as many forwarding paths as possible during route 99 selection. This solution cannot ensure that all paths are covered. 100 In addition, a large number of packets need to be constructed at the 101 source, which affects network performance and imposes more workload 102 and skill requirements on O&M engineers. 104 2. Terminology 106 The following terminology is used in this document. 108 MTU: Maximum Transmission Unit 110 Path MTU: path maximum transmission unit 112 TWAPM:Two-Way Active Measurement Protocol 114 BFD: Bidirectional Forwarding Detection 116 LMRF: Load-sharing multipath replication forwarding 118 3. Scenario Description 120 3.1. Example 122 +-----------+ 123 | | 124 | B | 125 /------->| Router |------\ 126 +-----------+ / | | \ +---------+ 127 | | / +-----------+ \ | | 128 | A |/ \ | D | 129 | Router |\ \---->| Router | 130 | | \ / | | 131 +-----------+ \ +-----------+ / +---------+ 132 \ | | / 133 \------>| C |-------/ 134 | Router | 135 | | 136 +-----------+ 138 Figure 1:Muiltpah Network Example 140 As shown in Figure 1, there are two paths from A to D: A-B-D and 141 A-C-D. The two paths are ECMP paths from A to D. Data packets from 142 A to D are transmitted based on the 5-tuple or triplet information in 143 the packet header. Selects a path based on the hash calculation 144 result. TCP/UDP/ICMP packets are routed based on quintuple, and raw 145 IP packets are routed based on triplet. Take ping packets as an 146 example. The source IP address, destination IP address, protocol 147 number, ICMP type, and ICMP code are used for hash calculation. The 148 result is used for ECMP route selection. Therefore, ping packets 149 from A to D can always cover only one path. Therefore, even if the 150 ping result is normal, services may be abnormal.Conversely, when a 151 service fault occurs, the ping detection may be normal. 153 Similar problems occur in trace route detection, BFD detection, TWAMP 154 detection, and path MTU detection. 156 In multi-channel load balancing scenarios, incorrect path MTU 157 detection may cause service exceptions. To simplify packet 158 processing and improve processing efficiency, IPv6 packets are 159 fragmented only on the source node.Therefore, the IPv6 path MTU 160 discovery protocol must be implemented.The latest document (draft- 161 ietf-6man-mtu-option-11 - IPv6 Minimum Path MTU Hop-by-Hop Option) 162 provides the path MTU discovery method for a single path, but does 163 not solve the path MTU problem in multipath scenarios. 165 +-----------+ 166 | | 167 MTU 1600 | B | MTU 1600 168 /------->| Router |------\ 169 +-----------+ / | | \ +-----------+ 170 | | / +-----------+ \ | | 171 | A |/ \ | D | 172 | Router |\ \---->| Router | 173 | | \ / | | 174 +-----------+ \ +-----------+ / +-----------+ 175 \ | | / 176 \------>| C |-------/ 177 MTU 1500 | Router | MTU 1500 178 | | 179 +-----------+ 181 Figure 2:MTU in Multipath Network 183 As shown in Figure 2, if the path MTU probe packet from A to D is 184 A-B-D, the path MTU of this path is 1600, and the path MTU of the 185 path A-C-D is 1500, Packet loss occurs when data packets with more 186 than 1500 bytes are routed to route A-C-D. 188 3.2. Solution 190 A universal replication detection mechanism is required to support 191 connectivity detection, path MTU detection, and delay detection. 192 This document discusses enhancements to IP header to support 193 multipath detection. 195 Path MTU detection affects service availability. Therefore, this 196 document focuses on the problem of path MTU detection. Other 197 problems, such as connectivity monitoring and delay monitoring, will 198 be discussed in the future. 200 4. Detail solution 202 4.1. IPv4 solution 204 This document focuses on the IPv6 network solution, IPv4 netwrok 205 solution will be discussed in the future. 207 4.2. IPv6 solution 209 4.2.1. Detection Solution 211 For IPv6, Hop by hop header and Destination header are extended to 212 carry the multipath replication switch and MTU detection switch. For 213 details, see section 4.2.2. The source node marks the flag, and the 214 intermediate device and tail device perform corresponding processing. 215 After the replication function is enabled on the source node, the 216 source node and transit node copy probe packets to all downstream 217 load balancing paths. After the MTU detection function is enabled on 218 the source node, the source node and intermediate node add the MTU 219 value of the outbound interface to the packet. You can add the MTU 220 value to the packet one by one, or you can compare the MTU value and 221 enter the minimum value. The end node responds to all received 222 detection packets, carries the MTU added along the path, and sends 223 the packets to the source node. The end node can also compare the 224 packets and select the smallest MTU as the final path MTU. To 225 simplify the packet format, packet size, and data-plane prosection 226 cessing, it is recommended that only the minimum MTU be reserved in 227 packets. In addition, the path MTU aging mechanism needs to be 228 modified. Considering that the network topology may change, the path 229 MTU may increase.If you always select the minimum value, you can 230 never increase it. Therefore, if no path MTU smaller than or equal 231 to the current path MTU is received for a long time, the current path 232 MTU may be set to an aging state. When the path MTU is in the aging 233 state, the path MTU may be replaced by a larger path MTU. 235 4.2.2. Modifications to existing mechanisms 237 4.2.2.1. Modification of the packet structure 239 The hop-by-hop extension header is used in common IP packet. The 240 TTTTT needs to be allocated by the IANA. 242 Option Option Option 243 Type Data Len Data 244 +--------+--------+--------+--------+---------+ 245 |BBCTTTTT|00000011|RRRRRRMD|-------MTU--------+ 246 +--------+--------+--------+--------+---------+ 247 R:Reserved 248 M:Path MTU detection flag 249 D:Load balancing duplicating flag 250 MTU:Minimum MTU on the path 252 The reply packet uses the DH extension header, and the TTTTT needs to 253 be allocated from the IANA. 255 Option Option Option 256 Type Data Len Data 257 +--------+--------+--------+---------+ 258 |BBCTTTTT|00000010|-------MTU--------+ 259 +--------+--------+--------+---------+ 260 MTU:Minimum MTU on the path 262 4.2.2.2. Source node behavior 264 1. Enable the load balancing duplicating flag. 266 2. Enable the MTU detection flag. 268 3. Set the detection timer: The system periodically sends detection 269 packets in duplicate mode and carries the MTU information of its own 270 interface. You are advised to set the timer interval to minutes, 271 which is configurable using the command line. 273 4. After receiving the response packet from the tail node, the 274 ingress node compares the path MTU value with the local path MTU 275 value and selects the minimum value. 277 5. Set the path MTU aging timer: The lifetime of the path MTU is 278 periodically updated. When a smaller path MTU or equivalent path MTU 279 is received, the timer is cleared. It is recommended that the timer 280 be set to three times of the detection timer. 282 6. When the path MTU aging timer expires, the path MTU is set to the 283 aging state and the minimum MTU detected in the next detection period 284 is used to overwrite the path MTU. 286 4.2.2.3. transit node behavior 288 1. Duplicating is performed to all load balancing next hops based on 289 the enabling flag of the load balancing duplicating flag. 291 2. Compare the MTU in packet with the local output interface MTU, 292 and replace the MTU in the packet with the smaller one. 294 4.2.2.4. Destination node behavior 296 1. Send Reply to source node accouding to all received packets and 297 fill back MTU value get from the received packets. 299 4.2.2.5. Process flow 301 step 5 302 |---------------------------<<---------------------------| 303 | | 304 | +-----------+ | 305 | | | | 306 | | B | | 307 | /------->| Router |------\ | 308 +-----------+ / | |step3 \ +--------+ 309 | | / +-----------+ \ | | 310 | A |/ step2 \ | D | 311 | Router |\ \---->| Router | 312 | | \ / | | 313 +-----------+ \ +-----------+ / +--------+ 314 step 1 \ | |step4 / 315 step 6 \------>| C |-------/ 316 | Router | 317 | | 318 +-----------+ 320 step 1. Router A try to dicovery the path mtu to Router D 322 step 2. Two packets will be send to Router D through Router B and 323 Router C, A-B-D path MTU set as 1600, A-C-D path MTU set as 1700 325 step 3. Router B received the packet and transfer to Router D, and 326 modify the MTU to 1500 327 step 4. Router C received the packet and transfer to Router D, and 328 modify the MTU to 1600 330 step 5. Router D received two packets and reply to Router A with the 331 corresponding path MTU 333 step 6. Router A updates local Path MTU with 1500, which is the 334 smallest one among all reply packets. 336 4.2.2.6. Uplayer protocol consideration 338 This function does not depend on upper-layer protocols and can work 339 with any upper-layer protocols, such as TCP, UPD, ICMP, Quic, and 340 TWAMP. 342 Take TWAMP as an example, TWAMP-test packets carry hop-by-hop 343 extension headers and enable M and D flags to detect the MTU of 344 multipath. Sequence numbers are used to identify multiple copies of 345 a packet. 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Sequence Number | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Timestamp | 353 | | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Error Estimate | | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 357 | | 358 . . 359 . Packet Padding . 360 . . 361 | | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 The receiver replies to the source as follows: 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Sequence Number | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Timestamp | 372 | | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Error Estimate | MBZ | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Receive Timestamp | 377 | | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Sender Sequence Number | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Sender Timestamp | 382 | | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Sender Error Estimate | MBZ | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Sender TTL | | 387 +-+-+-+-+-+-+-+-+ + 388 | | 389 . . 390 . Packet Padding . 391 . . 392 | | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 Sender Sequence Number is a copy of the Sequence Number of the packet 396 transmitted by the Session-Sender that caused the Session-Reflector 397 to generate and send this test packet. 399 5. Supplementary description of the protocol 401 1. In SDN scenarios, path MTUs can be sent to the controller by 402 telemetry, and controller then transfer the packets to source node. 403 This is not discussed in this document. 405 2. The detection protocol can be extended by TWAMP, BFD, or other 406 OAM protocol. This document does not provide any analysis. 408 3. This solution assumes all devices on the network support this 409 solution. If intermediate devices do not support, real path MTU will 410 be not detected, Then, PTB will be used to detect the path MTU. 412 4. The detection of connectivity faults and parameters such as 413 latancy in multipath load balancing scenarios will be discussed in 414 future. 416 6. Benefits 418 This solution provides accurate path MTU detection in load balancing 419 scenarios to prevent packet loss caused by excessively large packets. 421 7. Acknowledgements 423 Thank you to Yang Pingan, Zhao Ranxiao, Xia Yang, Wu Qin, Yudan, and 424 others for participating in the solution discussion and helping 425 improve the solution. 427 8. IANA Considerations 429 For carrying the Load balancing duplicating flag and Path MTU 430 detection flag, new option types need to be defined in the existing 431 RH and Hop by Hop headers. 433 9. Security Considerations 435 Considering the impact of packet replication on device and network 436 performance, packets in replication mode need to be traced, 437 encrypted, URPF, security filtering, and rate limiting. 439 10. Normative References 441 [I-D.ietf-6man-mtu-option] 442 Hinden, R. M. and G. Fairhurst, "IPv6 Minimum Path MTU 443 Hop-by-Hop Option", Work in Progress, Internet-Draft, 444 draft-ietf-6man-mtu-option-12, 27 January 2022, 445 . 448 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 449 DOI 10.17487/RFC1191, November 1990, 450 . 452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 453 Requirement Levels", BCP 14, RFC 2119, 454 DOI 10.17487/RFC2119, March 1997, 455 . 457 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 458 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 459 December 1998, . 461 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 462 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 463 . 465 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 466 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 467 May 2017, . 469 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 470 (IPv6) Specification", STD 86, RFC 8200, 471 DOI 10.17487/RFC8200, July 2017, 472 . 474 [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. 475 Völker, "Packetization Layer Path MTU Discovery for 476 Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, 477 September 2020, . 479 Authors' Addresses 481 Guofeng Qian 482 Huawei 483 Huawei Bld., No.156 Beiqing Rd. 484 Beijing 485 100095 486 China 487 Email: Qianguofeng@huawei.com 489 Tianran Zhou 490 Huawei 491 Huawei Bld., No.156 Beiqing Rd. 492 Beijing 493 100095 494 China 495 Email: Zhoutianran@huawei.com