idnits 2.17.1 draft-vyncke-v6ops-james-01.txt: -(2): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(4): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(6): 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 12 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (20 March 2022) is 767 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-31) exists of draft-bonica-6man-comp-rtg-hdr-27 == Outdated reference: A later version (-03) exists of draft-ietf-opsawg-pcap-00 == Outdated reference: A later version (-10) exists of draft-ietf-opsec-ipv6-eh-filtering-08 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations É. Vyncke 3 Internet-Draft Cisco 4 Intended status: Informational R. Léas 5 Expires: 21 September 2022 J. Iurman 6 Université de Liège 7 20 March 2022 9 Just Another Measurement of Extension header Survivability (JAMES) 10 draft-vyncke-v6ops-james-01 12 Abstract 14 In 2016, RFC7872 has measured the drop of packets with IPv6 extension 15 headers. This document presents a slightly different methodology 16 with more recent results. It is still work in progress. 18 About This Document 20 This note is to be removed before publishing as an RFC. 22 The latest revision of this draft can be found at 23 https://evyncke.github.io/v6ops-james/draft-vyncke-v6ops-james.html. 24 Status information for this document may be found at 25 https://datatracker.ietf.org/doc/draft-vyncke-v6ops-james/. 27 Discussion of this document takes place on the IPv6 Operations 28 Working Group mailing list (mailto:v6ops@ietf.org), which is archived 29 at https://mailarchive.ietf.org/arch/browse/v6ops/. 31 Source for this draft and an issue tracker can be found at 32 https://github.com/evyncke/v6ops-james. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 21 September 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Measurements . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3.1. Vantage Points . . . . . . . . . . . . . . . . . . . . . 3 70 3.2. Tested Autonomous Systems . . . . . . . . . . . . . . . . 4 71 3.2.1. Drop attribution to AS . . . . . . . . . . . . . . . 6 72 3.3. Tested Extension Headers . . . . . . . . . . . . . . . . 7 73 4. Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 4.1. Routing Header . . . . . . . . . . . . . . . . . . . . . 8 75 4.2. Hop-by-Hop Options Header . . . . . . . . . . . . . . . . 9 76 4.3. Destination Options Header . . . . . . . . . . . . . . . 10 77 4.4. Fragmentation Header . . . . . . . . . . . . . . . . . . 11 78 4.5. No extension headers drop at all . . . . . . . . . . . . 12 79 4.6. Special Next Headers . . . . . . . . . . . . . . . . . . 13 80 5. Summary of the collaborating parties measurements . . . . . . 13 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 85 8.2. Informative References . . . . . . . . . . . . . . . . . 14 86 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 89 1. Introduction 91 In 2016, [RFC7872] has measured the drop of packets with IPv6 92 extension headers on their transit over the global Internet. This 93 document presents a slightly different methodology with more recent 94 results. Since then, [I-D.draft-ietf-opsec-ipv6-eh-filtering] has 95 provided some recommendations for filtering transit traffic, so there 96 may be some changes in providers policies. 98 It is still work in progress, but the authors wanted to present some 99 results at IETF-113 (March 2022). The code is open source and is 100 available at [GITHUB]. 102 2. Methodology 104 In a first phase, the measurement is done between collaborating IPv6 105 nodes, a.k.a. vantage points, spread over the Internet and multiple 106 Autonomous Systems (ASs). As seen in Section 3.2, the 107 source/destination/transit ASs include some "tier-1" providers per 108 [TIER1], so, they are probably representative of the global Internet 109 core. 111 Relying on collaborating nodes has some benefits: 113 * propagation can be measured even in the absence of any ICMP 114 message or reply generated by the destination; 116 * traffic timing can be measured accurately to answer whether 117 extension headers are slower than plain IP6 packets; 119 * traffic can be captured into .pcap [I-D.draft-ietf-opsawg-pcap] 120 file at the source and at the destination for later analysis. 122 Future phases will send probes to non-collaborating nodes with a much 123 reduced probing speed. The destination will include [ALEXA] top-n 124 websites, popular CDN, as well as random prefix from the IPv6 global 125 routing table. A revision of this IETF draft will describe those 126 experiments. 128 3. Measurements 130 3.1. Vantage Points 132 Several servers were used worldwide (albeit missing Africa and China 133 as the authors were unable to find IPv6 servers in these regions). 134 Table 1 lists all the vantage points together with their AS number 135 and country. 137 +========+===================+==============+===================+ 138 | ASN | AS Name | Country code | Location | 139 +========+===================+==============+===================+ 140 | 7195 | Edge Uno | AG | Buenos Aires | 141 +--------+-------------------+--------------+-------------------+ 142 | 12414 | NL-SOLCON SOLCON | NL | Amsterdam | 143 +--------+-------------------+--------------+-------------------+ 144 | 14061 | Digital Ocean | CA | Toronto, ON | 145 +--------+-------------------+--------------+-------------------+ 146 | 14061 | Digital Ocean | USA | New York City, NY | 147 +--------+-------------------+--------------+-------------------+ 148 | 14601 | Digital Ocean | DE | Francfort | 149 +--------+-------------------+--------------+-------------------+ 150 | 14601 | Digital Ocean | IN | Bangalore | 151 +--------+-------------------+--------------+-------------------+ 152 | 14601 | Digital Ocean | SG | Singapore | 153 +--------+-------------------+--------------+-------------------+ 154 | 16276 | OVH | AU | Sydney | 155 +--------+-------------------+--------------+-------------------+ 156 | 16276 | OVH | PL | Warsaw | 157 +--------+-------------------+--------------+-------------------+ 158 | 44684 | Mythic Beasts | UK | Cambridge | 159 +--------+-------------------+--------------+-------------------+ 160 | 47853 | Hostinger | US | Ashville, NC | 161 +--------+-------------------+--------------+-------------------+ 162 | 60011 | MYTHIC-BEASTS-USA | US | Fremont, CA | 163 +--------+-------------------+--------------+-------------------+ 164 | 198644 | GO6 | SI | Ljubljana | 165 +--------+-------------------+--------------+-------------------+ 167 Table 1: All vantage AS 169 3.2. Tested Autonomous Systems 171 During first phase (traffic among fully-meshed collaborative nodes), 172 Table 2 show the ASs for which our probes have collected data. 174 +===========+======================================+==========+ 175 | AS Number | AS Description | Comment | 176 +===========+======================================+==========+ 177 | 174 | COGENT-174, US | Tier-1 | 178 +-----------+--------------------------------------+----------+ 179 | 1299 | TWELVE99 Twelve99, Telia Carrier, SE | Tier-1 | 180 +-----------+--------------------------------------+----------+ 181 | 2914 | NTT-COMMUNICATIONS-2914, US | Tier-1 | 182 +-----------+--------------------------------------+----------+ 183 | 3320 | DTAG Internet service provider | Tier-1 | 184 | | operations, DE | | 185 +-----------+--------------------------------------+----------+ 186 | 3356 | LEVEL3, US | Tier-1 | 187 +-----------+--------------------------------------+----------+ 188 | 4637 | ASN-TELSTRA-GLOBAL Telstra Global, | Regional | 189 | | HK | Tier | 190 +-----------+--------------------------------------+----------+ 191 | 4755 | TATACOMM-AS TATA Communications | | 192 | | formerly VSNL is Leading ISP, IN | | 193 +-----------+--------------------------------------+----------+ 194 | 5603 | SIOL-NET Telekom Slovenije d.d., SI | | 195 +-----------+--------------------------------------+----------+ 196 | 6453 | Tata Communication | Tier-1 | 197 +-----------+--------------------------------------+----------+ 198 | 6762 | SEABONE-NET TELECOM ITALIA SPARKLE | Tier-1 | 199 | | S.p.A., IT | | 200 +-----------+--------------------------------------+----------+ 201 | 6939 | HURRICANE, US | Regional | 202 | | | Tier | 203 +-----------+--------------------------------------+----------+ 204 | 7195 | EDGEUNO SAS, CO | | 205 +-----------+--------------------------------------+----------+ 206 | 8447 | A1TELEKOM-AT A1 Telekom Austria AG, | | 207 | | AT | | 208 +-----------+--------------------------------------+----------+ 209 | 9498 | BBIL-AP BHARTI Airtel Ltd., IN | | 210 +-----------+--------------------------------------+----------+ 211 | 12414 | NL-SOLCON SOLCON, NL | | 212 +-----------+--------------------------------------+----------+ 213 | 14061 | DIGITALOCEAN-ASN, US | | 214 +-----------+--------------------------------------+----------+ 215 | 16276 | OVH, FR | | 216 +-----------+--------------------------------------+----------+ 217 | 21283 | A1SI-AS A1 Slovenija, SI | | 218 +-----------+--------------------------------------+----------+ 219 | 34779 | T-2-AS AS set propagated by T-2 | | 220 | | d.o.o., SI | | 221 +-----------+--------------------------------------+----------+ 222 | 44684 | MYTHIC Mythic Beasts Ltd, GB | | 223 +-----------+--------------------------------------+----------+ 224 | 60011 | MYTHIC-BEASTS-USA, GB | | 225 +-----------+--------------------------------------+----------+ 226 | 198644 | GO6, SI | | 227 +-----------+--------------------------------------+----------+ 229 Table 2: All AS (source/destination/transit) 231 The table attributes some tier qualification to some ASs based on the 232 Wikipedia page [TIER1], but there is no common way to decide who is a 233 tier-1. Based on some CAIDA research, all the above (except GO6, 234 which is a stub network) are transit providers. 236 While this document lists some operators, the intent is not to build 237 a wall of fame or a wall of shame but more to get an idea about which 238 kind of providers drop packets with extension headers and how 239 widespread the drop policy is enforced and where, i.e., in the access 240 provider or in the core of the Internet. 242 3.2.1. Drop attribution to AS 244 Comparing the traceroutes with and without extension headers allows 245 the attribution of a packet drop to one AS. But, this is not an easy 246 task as inter-AS links often use IPv6 address of only one AS (if not 247 using link-local per [RFC7704]). This document uses the following 248 algorithm to attribute the drop to one AS for packet sourced in one 249 AS and then having a path traversing AS#foo just before AS#bar: 251 * if the packet drop happens at the first router (i.e., hop limit == 252 1 does not trigger an ICMP hop-limit exceeded), then the drop is 253 assumed to this AS as it is probably an ingress filter on the 254 first router (i.e., the hosting provider in most of the cases - 255 except if collocated with an IXP). 257 * if the packet drop happens in AS#foo after one or more hop(s) in 258 AS#bar, then the drop is assumed to be in AS#foo ingress filter on 259 a router with an interface address in AS#foo 261 * if the packet drop happens in AS#bar after one or more hop(s) in 262 AS#bar before going to AS#foo, then the drop is assumed to be in 263 AS#foo ingress filter on a router with an interface address in 264 AS#bar 266 In several cases, the above algorithm was not possible (e.g., some 267 intermediate routers do not generate an ICMP unreachable hop limit 268 exceeded even in the absence of any extension headers), then the drop 269 is not attributed. Please also note that the goal of this document 270 is not to 'point fingers to operators' but more to evaluate the 271 potential impact. I.e., a tier-1 provider dropping packets with 272 extension headers has a much bigger impact on the Internet traffic 273 than an access provider. 275 Future revision of this document will use the work of [MLAT_PEERING]. 277 3.3. Tested Extension Headers 279 In the first phase among collaborating vantage points, packets always 280 contained either a UDP payload or a TCP payload, the latter is sent 281 with only the SYN flag set and with data as permitted by section 3.4 282 of [RFC793] (2nd paragraph). A usual traceroute is done with only 283 the UDP/TCP payload without any extension header with varying hop- 284 limit in order to learn the traversed routers and ASs. Then, several 285 UDP/TCP probes are sent with a set of extension headers: 287 * hop-by-hop and destination options header containing: 289 - one PadN option for an extension header length of 8 octets, 291 - one unknown option with the "discard" bits for an extension 292 header length of 8 octets, 294 - multiple PadN options for an extension header length of 256 295 octets, 297 - one unknown option (two sets with "discard" and "skip" bits) 298 for the destination options header length of 16, 32, 64, and 299 128 octets, 301 - one unknown option (two sets with "discard" and "skip" bits) 302 for an extension header length of 256 and 512 octets. 304 * routing header with routing types from 0 to 6 inclusive; 306 * atomic fragment header (i.e., M-flag = 0 and offset = 0) of 307 varying frame length 512, 1280, and 1500 octets; 309 * non-atomic first fragment header (i.e., M-flag = 1 and offset = 0) 310 of varying frame length 512, 1280, and 1500 octets; 312 * authentication header with dummy SPI followed by UDP/TCP header 313 and a 38 octets payload. 315 In the above, length is the length of the extension header itself 316 except for the fragmentation header where the length is the IP packet 317 length (i.e., including the IPv6, and TCP/UDP headers + payload). 319 For hop-by-hop and destination options headers, when required 320 multiple PadN options were used in order to bypass some Linux kernels 321 that consider a PadN larger than 8 bytes is an attack, see section 322 5.3 of [BCP220], even if multiple PadN options violates section 323 2.1.9.5 of [RFC4942]. 325 In addition to the above extension headers, other probes were sent 326 with next header field of IPv6 header set to: 328 * 59, which is "no next header", especially whether extra octets 329 after the no next header as section 4.7 [RFC8200] requires that 330 "those octets must be ignored and passed on unchanged if the 331 packet is forwarded"; 333 * 143, which is Ethernet payload (see section 10.1 of [RFC8986]). 335 4. Results 337 This section presents the current results out of phase 1 338 (collaborating vantage points) testing. About 4860 experiments were 339 run, one experiment being defined by sending packets between 2 340 vantage points with hop-limit varying from 1 to the number of hops 341 between the two vantage points and for all the extension headers 342 described in Section 3.3. 344 4.1. Routing Header 346 Table 3 lists all routing header types and the percentage of 347 experiments that were successful, i.e., packets with routing header 348 reaching their destination: 350 +=====================+=======================================+ 351 | Routing Header Type | %-age of packets reaching destination | 352 +=====================+=======================================+ 353 | 0 | 80.9% | 354 +---------------------+---------------------------------------+ 355 | 1 | 99.5% | 356 +---------------------+---------------------------------------+ 357 | 2 | 99.5% | 358 +---------------------+---------------------------------------+ 359 | 3 | 99.5% | 360 +---------------------+---------------------------------------+ 361 | 4 | 69.0% | 362 +---------------------+---------------------------------------+ 363 | 5 | 99.5% | 364 +---------------------+---------------------------------------+ 365 | 6 | 99.3% | 366 +---------------------+---------------------------------------+ 368 Table 3: Per Routing Header Types Transmission 370 Table 4 lists the few ASs that drop packets with the routing header 371 type 0 (the original source routing header, which is now deprecated). 373 +===========+================+ 374 | AS Number | AS description | 375 +===========+================+ 376 | 6939 | HURRICANE, US | 377 +-----------+----------------+ 379 Table 4: AS Dropping 380 Routing Header Type 0 382 It is possibly due to a strict implementation of [RFC5095] but it is 383 expected that no packet with routing header type 0 would be 384 transmitted anymore. So, this is not surprising. 386 Table 5 lists the few ASs that drop packets with the routing header 387 type 4 (Segment Routing Header [RFC8754]). 389 +===========+================+ 390 | AS Number | AS description | 391 +===========+================+ 392 | 16276 | OVH, FR | 393 +-----------+----------------+ 395 Table 5: AS Dropping 396 Routing Header Type 0 398 This drop of SRH was to be expected as SRv6 is specified to run only 399 in a limited domain. 401 Other routing header types (1 == deprecated NIMROD [RFC1753], 2 == 402 mobile IPv6 [RFC6275], 3 == RPL [RFC6554], and even 5 == CRH-16 and 6 403 == CRH-32[I-D.draft-bonica-6man-comp-rtg-hdr]) can be transmitted 404 over the global Internet without being dropped (assuming that the 405 0.5% of dropped packets are within the measurement error). 407 4.2. Hop-by-Hop Options Header 409 Many ASs drop packets containing either hop-by-hop options headers 410 per Table 6 below: 412 +===============+========+=======================================+ 413 | Option Type | Length | %-age of packets reaching destination | 414 +===============+========+=======================================+ 415 | Skip | 8 | 5.8% | 416 +---------------+--------+---------------------------------------+ 417 | Discard | 8 | 0.0% | 418 +---------------+--------+---------------------------------------+ 419 | Skip one | 256 | 1.9% | 420 | large PadN | | | 421 +---------------+--------+---------------------------------------+ 422 | Skip multiple | 256 | 0.0% | 423 | PadN | | | 424 +---------------+--------+---------------------------------------+ 425 | Discard | 256 | 0.0% | 426 +---------------+--------+---------------------------------------+ 427 | Skip | 512 | 1.9% | 428 +---------------+--------+---------------------------------------+ 429 | Discard | 512 | 0.0% | 430 +---------------+--------+---------------------------------------+ 432 Table 6: Hop-by-hop Transmission 434 It appears that hop-by-hop options headers cannot reliably traverse 435 the global Internet; only small headers with 'skipable' options have 436 some chances. If the unknown hop-by-hop option has the 'discard' 437 bits, it is dropped per specification. 439 4.3. Destination Options Header 441 Many ASs drop packets containing destination options headers per 442 Table 7: 444 +========+===============+=======================================+ 445 | Length | Multiple PadN | %-age of packets reaching destination | 446 +========+===============+=======================================+ 447 | 8 | No | 99.3% | 448 +--------+---------------+---------------------------------------+ 449 | 16 | No | 99.3% | 450 +--------+---------------+---------------------------------------+ 451 | 32 | No | 93.3% | 452 +--------+---------------+---------------------------------------+ 453 | 64 | No | 41.6% | 454 +--------+---------------+---------------------------------------+ 455 | 128 | No | 4.5% | 456 +--------+---------------+---------------------------------------+ 457 | 256 | No | 2.6% | 458 +--------+---------------+---------------------------------------+ 459 | 256 | Yes | 2.6% | 460 +--------+---------------+---------------------------------------+ 461 | 512 | No | 2.6% | 462 +--------+---------------+---------------------------------------+ 464 Table 7: Hop-by-hop Transmission 466 The measurement did not find any impact of the discard/skip bits in 467 the destination headers options, probably because the routers do not 468 look inside the extension headers into the options. The use of a 469 single large PadN or multiple 8-octet PadN options does not influence 470 the result. 472 The size of the destination options header has a major impact on the 473 drop probability. It appears that extension header larger than 16 474 octets already causes major drops. It may be because the 40 octets 475 of the IPv6 header + the 16 octets of the extension header (total 56 476 octets) is still below some router hardware lookup mechanisms while 477 the next measured size (extension header size of 64 octets for a 478 total of 104 octets) is beyond the hardware limit and some AS has a 479 policy to drop packets where the TCP/UDP ports are unknown... 481 4.4. Fragmentation Header 483 The propagation of two kinds of fragmentation headers was analysed: 484 atomic fragment (offset == 0 and M-flag == 0) and plain first 485 fragment (offset == 0 and M-flag == 1). The Table 8 displays the 486 propagation differences. 488 +============+=======================================+ 489 | M-flag | %-age of packets reaching destination | 490 +============+=======================================+ 491 | 0 (atomic) | 70.2% | 492 +------------+---------------------------------------+ 493 | 1 | 99.0% | 494 +------------+---------------------------------------+ 496 Table 8: IPv6 Fragments Transmission 498 The size of the overall IP packets (512, 1280, and 1500 octets) does 499 not have any impact on the propagation. 501 4.5. No extension headers drop at all 503 Table 9 lists some ASs that do not drop transit traffic (except for 504 routing header type 0) and follow the recommendations of 505 [I-D.draft-ietf-opsec-ipv6-eh-filtering]. This list includes tier-1 506 transit providers (using the "regional" tag per [TIER1]): 508 +===========+=======================================+===============+ 509 | AS Number | AS Description | Comment | 510 +===========+=======================================+===============+ 511 | 4637 | ASN-TELSTRA-GLOBAL Telstra Global, HK | Regional | 512 | | | Tier | 513 +-----------+---------------------------------------+---------------+ 514 | 4755 | TATACOMM-AS TATA Communications | | 515 | | formerly VSNL is Leading ISP, IN | | 516 +-----------+---------------------------------------+---------------+ 517 | 21283 | A1SI-AS A1 Slovenija, SI | | 518 +-----------+---------------------------------------+---------------+ 519 | 60011 | MYTHIC-BEASTS-USA, GB | | 520 +-----------+---------------------------------------+---------------+ 522 Table 9: ASs Not Dropping Packets with Extension Headers 524 Some ASs also drop only large (more than 8 octets) destination 525 options headers, see Table 10: 527 +===========+====================+===================+ 528 | AS Number | AS Description | Largest Forwarded | 529 | | | Dest.Opt. Size | 530 +===========+====================+===================+ 531 | 6453 | Tata | 8 | 532 | | Communication | | 533 +-----------+--------------------+-------------------+ 534 | 1299 | TWELVE99 Twelve99, | 8 | 535 | | Telia Carrier, SE | | 536 +-----------+--------------------+-------------------+ 537 | 174 | COGENT-174, US | 8 | 538 +-----------+--------------------+-------------------+ 540 Table 10: ASs Only Dropping Packets with Large 541 Destination Options Headers 543 4.6. Special Next Headers 545 Measurements also include two protocol numbers that are mainly new 546 use of IPv6. Table 11 indicates the percentage of packets reaching 547 the destination. 549 +===================+=======================================+ 550 | Next Header | %-age of packets reaching destination | 551 +===================+=======================================+ 552 | NoNextHeader (59) | 99.7% | 553 +-------------------+---------------------------------------+ 554 | Ethernet (143) | 99.2% | 555 +-------------------+---------------------------------------+ 557 Table 11: Transmission of Special IP Protocols 559 The above indicates that those IP protocols can be transmitted over 560 the global Internet without being dropped (assuming that the 0.3-0.8% 561 of dropped packets are within the measurement error). 563 5. Summary of the collaborating parties measurements 565 While the analysis has areas of improvement (geographical 566 distribution and impact on latency), it appears that: 568 * authentication and non-atomic fragmentation headers can traverse 569 the Internet; 571 * only routing headers types 0 and 4 experiment problems over the 572 Internet, other types have no problems; 574 * hop-by-hop options headers do not traverse the Internet; 575 * destination options headers are not reliable enough when it 576 exceeds 16 octets. 578 Of course, the next phase of measurement with non-collaborating 579 parties will probably give another view. 581 6. Security Considerations 583 While active probing of the Internet may be considered as an attack, 584 this measurement was done among collaborating parties and using the 585 probe attribution technique described in 586 [I-D.draft-vyncke-opsec-probe-attribution] to allow external parties 587 to identify the source of the probes if required. 589 7. IANA Considerations 591 This document has no IANA actions. 593 8. References 595 8.1. Normative References 597 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, 598 RFC 793, DOI 10.17487/RFC0793, September 1981, 599 . 601 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 602 (IPv6) Specification", STD 86, RFC 8200, 603 DOI 10.17487/RFC8200, July 2017, 604 . 606 8.2. Informative References 608 [ALEXA] "The top 500 sites on the web", n.d., 609 . 611 [BCP220] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 612 Requirements", BCP 220, RFC 8504, January 2019. 614 616 [GITHUB] Léas, R., "james", n.d., 617 . 619 [I-D.draft-bonica-6man-comp-rtg-hdr] 620 Bonica, R., Kamite, Y., Alston, A., Henriques, D., and L. 621 Jalil, "The IPv6 Compact Routing Header (CRH)", Work in 622 Progress, Internet-Draft, draft-bonica-6man-comp-rtg-hdr- 623 27, 15 November 2021, 624 . 627 [I-D.draft-ietf-opsawg-pcap] 628 Harris, G. and M. C. Richardson, "PCAP Capture File 629 Format", Work in Progress, Internet-Draft, draft-ietf- 630 opsawg-pcap-00, 25 October 2021, 631 . 634 [I-D.draft-ietf-opsec-ipv6-eh-filtering] 635 Gont, F. and W. (. Liu, "Recommendations on the Filtering 636 of IPv6 Packets Containing IPv6 Extension Headers at 637 Transit Routers", Work in Progress, Internet-Draft, draft- 638 ietf-opsec-ipv6-eh-filtering-08, 3 June 2021, 639 . 642 [I-D.draft-vyncke-opsec-probe-attribution] 643 Vyncke, É., Donnet, B., and J. Iurman, "Attribution of 644 Internet Probes", Work in Progress, Internet-Draft, draft- 645 vyncke-opsec-probe-attribution-01, 3 March 2022, 646 . 649 [MLAT_PEERING] 650 Giotsas, V., Zhou, S., Luckie, M., and K. Claffy, 651 "Inferring Multilateral Peering", 652 DOI 10.1145/2535372.2535390, December 2013, 653 . 656 [RFC1753] Chiappa, N., "IPng Technical Requirements Of the Nimrod 657 Routing and Addressing Architecture", RFC 1753, 658 DOI 10.17487/RFC1753, December 1994, 659 . 661 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 662 Co-existence Security Considerations", RFC 4942, 663 DOI 10.17487/RFC4942, September 2007, 664 . 666 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 667 of Type 0 Routing Headers in IPv6", RFC 5095, 668 DOI 10.17487/RFC5095, December 2007, 669 . 671 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 672 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 673 2011, . 675 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 676 Routing Header for Source Routes with the Routing Protocol 677 for Low-Power and Lossy Networks (RPL)", RFC 6554, 678 DOI 10.17487/RFC6554, March 2012, 679 . 681 [RFC7704] Crocker, D. and N. Clark, "An IETF with Much Diversity and 682 Professional Conduct", RFC 7704, DOI 10.17487/RFC7704, 683 November 2015, . 685 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 686 "Observations on the Dropping of Packets with IPv6 687 Extension Headers in the Real World", RFC 7872, 688 DOI 10.17487/RFC7872, June 2016, 689 . 691 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 692 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 693 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 694 . 696 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 697 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 698 (SRv6) Network Programming", RFC 8986, 699 DOI 10.17487/RFC8986, February 2021, 700 . 702 [TIER1] "Tier 1 network", n.d., 703 . 705 Acknowledgments 707 The authors want to thank Sander Steffann and Jan Zorz for allowing 708 the free use of their labs. Other thanks to Fernando Gont who 709 indicated a nice IPv6 hosting provider in South America. 711 Special thanks as well to Professor Benoit Donnet for his support and 712 advices. This document would not have existed without his support. 714 Authors' Addresses 715 Éric Vyncke 716 Cisco 717 De Kleetlaan 64 718 1831 Diegem 719 Belgium 720 Email: evyncke@cisco.com 722 Raphaël Léas 723 Université de Liège 724 Liège 725 Belgium 726 Email: raphael.leas@student.uliege.be 728 Justin Iurman 729 Université de Liège 730 Institut Montefiore B28 731 Allée de la Découverte 10 732 4000 Liège 733 Belgium 734 Email: justin.iurman@uliege.be