idnits 2.17.1 draft-peng-6man-tracing-option-00.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 == Line 169 has weird spacing: '...Version n 8 ...' == Line 181 has weird spacing: '...ntifier n 4 ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (30 March 2022) is 759 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 (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Peng 3 Internet-Draft R. Zhao 4 Intended status: Standards Track Huawei Technologies 5 Expires: 1 October 2022 30 March 2022 7 Tracing process in IPv6 VPN Tunneling Networks 8 draft-peng-6man-tracing-option-00 10 Abstract 12 This document specifies the tracing process in IPv6 VPN tunneling 13 networks for diagnostic purposes. An IPv6 Tracing Option is 14 specified to collect and carry the required key information in an 15 effective manner to correctly construct ICMPv4 and ICMPv6 Time 16 Exceeded messages at the corresponding nodes, i.e. CE and P nodes, 17 respectively. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 1 October 2022. 36 Copyright Notice 38 Copyright (c) 2022 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 54 3. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. IPv6 Tracing Option . . . . . . . . . . . . . . . . . . . . . 4 56 5. Tracing Process in different modes of the ingress PE . . . . 5 57 5.1. Tracing Process in Uniform mode . . . . . . . . . . . . . 5 58 5.2. Tracing Process in Pipe mode . . . . . . . . . . . . . . 7 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 64 9.2. Informative References . . . . . . . . . . . . . . . . . 8 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 67 1. Introduction 69 ICMPv6 (Internet Control Message Protocol) RFC 4443 [RFC4443] is used 70 by IPv6 nodes to report errors encountered in processing packets and 71 to perform other internet-layer functions, such as diagnostics 72 (ICMPv6 "ping"). RFC 4443 [RFC4443] describes the format of a set of 73 control messages used in ICMPv6, including the Time Exceeded Message. 74 Every ICMPv6 message is preceded by an IPv6 header and zero or more 75 IPv6 extension headers. The ICMPv6 header is identified by a Next 76 Header value of 58 in the immediately preceding header. 78 If a router receives a packet with a Hop Limit of zero, or if a 79 router decrements a packet's Hop Limit to zero, it MUST discard the 80 packet and originate an ICMPv6 Time Exceeded message with Code 0 to 81 the source of the packet. 83 In the case of VPN, as shown in Figure 1, where CE1 and CE2 are IPv4, 84 an IPv6 tunnel exists between PE1 and PE2, and all the nodes belong 85 to a single network operator. For diagnostic purposes, CE1 sends out 86 an IPv4 packet with its TTL set to a value. The IPv4 packet is 87 encapsulated within the IPv6 tunnel at PE1. The TTL of the IPv4 88 packet will be copied, based on which a new value will be set as the 89 Hop Limit in the outer IPv6 tunnel header. The new Hop Limit value 90 depends on the mode configured on PE1, i.e., Uniform mode or Pipe 91 mode RFC 3443 [RFC3443]. If it is the Uniform mode, the Hop Limit 92 will be the TTL value in the received packet minus one. When an 93 intermediate router P decrements the Hop Limit in the outer tunnel 94 header to zero, an ICMPv6 Time Exceeded Message needs to be sent back 95 to the source, which should be the CE1 via PE1. 97 The Pipe mode can be used to detect the routing loop. If it is the 98 Pipe mode configured on PE1, the Hop Limit will be set to be the 99 maximum value (e.g., 64). In this case, when an intermediate router 100 P decrements the Hop Limit in the outer tunnel header to zero, it 101 means that the routing loop has happened, and this packet needs to be 102 dropped. 104 IPv4 |<========== IPv6 Tunnel =========>| IPv4 105 (CE1)-----(PE1)-------------(P)------------(PE2)-----(CE2) 106 <--| <--| 107 ICMPv4 ICMPv6 109 Figure 1. The tracing in IPv6 VPN tunneling networks 111 In order to construct a correct ICMPv4 Time Exceeded Message at PE1 112 and send it to CE1, a couple of key information is required: 114 1) The IPv4 address of the access interface at the P node, which will 115 be taken as the source address of the ICMPv4 Time Exceeded Message. 117 2) The VPN information, which is used to identify the VPN, either 118 using the VPN ID or the Access Interface ID at the PE1. 120 However, currently this information is missing and there is still no 121 appropriate way to collect and carry it to the right nodes. 123 This document specifies the tracing process in IPv6 VPN tunneling 124 networks. An IPv6 Tracing Option is specified to collect and carry 125 the required key information in an effective manner to correctly 126 construct ICMPv4 and ICMPv6 Time Exceeded messages at the 127 corresponding nodes, i.e. CE and P nodes, respectively. 129 2. Requirements Language 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 133 "OPTIONAL" in this document are to be interpreted as described in BCP 134 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 135 appear in all capitals, as shown here. 137 3. Terminologies 139 TTL: Time To Live 141 ICMP: Internet Control Message Protocol 143 4. IPv6 Tracing Option 145 The tracing option has the following format. 147 Option Option Option 148 Type Data Len Data 149 +--------+--------+--------+--------+ 150 |BBCTTTTT|00000110|Version |Flag|V|U| 151 +--------+--------+--------+--------+ 152 | Identifier | 153 +--------+--------+--------+--------+ 155 Option Type (see Section 4.2 of [RFC8200]): 157 BB 00 Skip over this option and continue processing. 159 C 0 Option data can not change en route to the packet's 160 final destination. 162 TTTTT TBD Option Type to be assigned from IANA. 164 Length 6 8-bit unsigned integer indicates the length of the 165 option Data field of this option, in octets. 166 The value of Opt Data Len of the IPv6 Tracing option 167 SHOULD be set to 6. 169 Version n 8 bits. It indicates the version of this mechanism. 171 Flag n 8 bits, where: 173 U n 1 bit. U-Flag. If set by the ingress PE it indicates 174 that the Uniform mode is configured on the ingress PE. 175 Otherwise, the ingress PE is on the pipe mode. 177 V n 1 bit. V-Flag. If set by the ingress PE it indicates 178 that the carried following Identifier is a VPNID. 179 Otherwise, it is the Access Interface ID. 181 Identifier n 4 octets. It is used to identify the VPN, either using 182 the VPN ID or the Access Interface ID, as indicated 183 by the V flag. 185 5. Tracing Process in different modes of the ingress PE 187 The diagnostic IPv4 packet sent by CE is encapsulated within the IPv6 188 tunnel at the ingress PE. The TTL of the IPv4 packet is copied, 189 based on which a new value is set as the Hop Limit in the outer IPv6 190 tunnel header. 192 The ingress PE can be configured in two modes, that is, Uniform mode 193 and Pipe mode. The new Hop Limit value depends on the mode 194 configured on PE1. If it is the Uniform mode, the Hop Limit will be 195 the TTL value in the received packet minus one. If it is the Pipe 196 mode, the Hop Limit will be set to be the maximum value (e.g., 255). 197 More details are described below. 199 5.1. Tracing Process in Uniform mode 201 When the ingress PE is configured in Uniform Mode, the inner and 202 outer TTLs of the packets are synchronized at tunnel ingress (PE1) 203 and egress (PE2). 205 Figure 2 shows the tracing process in the Uniform Mode. When an IP 206 packet (shown as (1) in the figure and with TTL = n) reaches the 207 ingress PE (PE1), it is encapsulated by the ingress PE into a newly 208 created IPv6 header and an extension header (Hop-by-Hop Options 209 Header or Destination Options Header RFC 8200 [RFC8200]) carrying the 210 IPv6 Tracing Option defined in this document. The Hop Limit is set 211 to be n - 1, shown as (2) in the figure. 213 When the Hop Limit becomes zero, the P node will check whether the 214 IPv6 Tracing Option is carried. If carried, the information in the 215 IPv6 Tracing Option will trigger the following actions. 217 If the U-flag is set, it means that the ingress PE is in the Uniform 218 Mode, so an ICMPv6 packet (shown as (3) in the figure) will be sent 219 back to the PE1. The SA of the packet is the IPv6 address of the P 220 node, while the DA is the IPv6 address of the PE1. The ICMPv6 Error 221 Message carries the IPv4 address of the input port interface of the 222 packet entering the P node, which will be taken as the source address 223 of the ICMPv4 message to be sent by the ingress PE towards CE1. 225 When the packet (3) is received by PE1, the PE1 will construct an 226 ICMPv4 packet (4) and send it to CE1. At the PE1, the information in 227 the carried IPv6 Tracing Option will be read and the VPN using which 228 to continue to forwarding the packet to the corresponding CE will be 229 identified using the V-Flag and the value of the Identifier in the 230 IPv6 Tracing Option. 232 |<============ Tunnel ===========>| 234 +---(n-2)-------(n-i)---+ 235 / (outer header) \ 236 (n-1) (n-i-1) 237 / \ 238 >--(n)--Encap.................(n-1)......Decap--(n-i-2)--> 239 (CE1) (PE1) (P) (PE2) (CE2) 241 (1)-> (2)-> <-(3) 242 +------+ +-------+ +-------+ 243 | SA |\ |SA PE1 |\ | SA P | 244 +------+ \ +-------+ \ +-------+ 245 | DA | \ |DA Out | \ | DA PE1| 246 +------+ \ +-------+ \ +-------+ 247 |TTL=n | \ |HL=n-1 | \ | HL=64 | 248 +------+ \ +-------+ \ +-------+ 249 | PL | \|Option | \|ICMPv6 | => P's input inf IPv4 addr 250 +------+ +-------+ +-------+ 251 \ | SA | |SA PE1 | 252 \ +-------+ +-------+ 253 \ | DA | |DA Out | 254 \ +-------+ +-------+ 255 \ |TTL=n-1| |HL=n-i | 256 \ +-------+ +-------+ 257 \| PL | |Option | 258 +-------+ +-------+ 259 \ | SA | 260 \ +-------+ 261 \ | DA | 262 \ +-------+ 263 \ |TTL=n-1| 264 \ +-------+ 265 \| PL | 266 <-(4) +-------+ 267 +--------+ 268 |SA P Inf| 269 +--------+ 270 | DA CE1 | SA - Source Address (Inner) 271 +--------+ DA - Destination Address (Inner) 272 | ICMPv4 | PL - Payload 273 +--------+ HL - Hop Limit 274 | SA | Out - Outer 275 +--------+ 276 | DA | 277 +--------+ 278 |TTL=n-1 | 279 +--------+ 280 | PL | 281 +--------+ 282 Figure 2. The tracing process in the Uniform Mode 284 5.2. Tracing Process in Pipe mode 286 When the ingress PE is configured in Pipe Mode, the inner and outer 287 TTLs of the packets will not be synchronized at tunnel ingress (PE1) 288 and egress (PE2). The tunnel will be taken as one hop by the inner 289 packet, as shown in Figure 3. 291 The Hop Limit will be set to be the maximum value (e.g., 64) at the 292 ingress PE. Since it is set to the maximum value, in normal case, 293 the Hop Limit will not become zero at any P node. So the only reason 294 when the Hop Limit becomes zero is that a routing loop is detected. 295 In this case, the packet needs to be dropped. 297 If the U-flag is not set, it means that the ingress PE is in the Pipe 298 Mode, and the packet (i.e. (2) as shown in Figure 2) will be dropped 299 when the Hop Limit becomes zero either at the P node (no ICMPv6 300 packet (i.e. (3) as shown in Figure 2) ) or the PE1 node when the P 301 node does not have the dropping capability. 303 |<============ Tunnel ===========>| 305 +---(Max-1)---(Max-i)---+ 306 / (outer header) \ 307 (Max) (Max-i-1) 308 / \ 309 >--(n)--Encap...........(n-1)...........Decap--(n-2)--> 310 (CE1) (PE1) (P) (PE2) (CE2) 312 Figure 3. The tracing process in the Pipe Mode 314 6. IANA Considerations 316 IANA is requested to allocate one new option type from "Destination 317 Options and Hop-by-Hop Options" registry. 319 +=======+=====================+===========+ 320 | Value | Name | Reference | 321 +=======+=====================+===========+ 322 | TBD1 | IPv6 Tracing Option | This ID | 323 +-------+---------------------+-----------+ 325 7. Acknowledgements 327 The authors would like to thank the careful reviews and valuable 328 comments from Stefano Previdi. 330 8. Security Considerations 332 TBD 334 9. References 336 9.1. Normative References 338 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 339 Requirement Levels", BCP 14, RFC 2119, 340 DOI 10.17487/RFC2119, March 1997, 341 . 343 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 344 in Multi-Protocol Label Switching (MPLS) Networks", 345 RFC 3443, DOI 10.17487/RFC3443, January 2003, 346 . 348 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 349 Control Message Protocol (ICMPv6) for the Internet 350 Protocol Version 6 (IPv6) Specification", STD 89, 351 RFC 4443, DOI 10.17487/RFC4443, March 2006, 352 . 354 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 355 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 356 May 2017, . 358 9.2. Informative References 360 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 361 (IPv6) Specification", STD 86, RFC 8200, 362 DOI 10.17487/RFC8200, July 2017, 363 . 365 Authors' Addresses 367 Shuping Peng 368 Huawei Technologies 369 Beijing 370 China 371 Email: pengshuping@huawei.com 373 Ranxiao Zhao 374 Huawei Technologies 375 Beijing 376 China 377 Email: zhaoranxiao@huawei.com