idnits 2.17.00 (12 Aug 2021) /tmp/idnits11145/draft-ietf-v6ops-ipv6-ehs-in-real-world-02.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 -- The document date (December 10, 2015) is 2347 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1034' is defined on line 277, but no explicit reference was found in the text == Unused Reference: 'RFC4443' is defined on line 285, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 291, but no explicit reference was found in the text == Unused Reference: 'RFC5927' is defined on line 339, but no explicit reference was found in the text == Unused Reference: 'RFC6980' is defined on line 343, but no explicit reference was found in the text == Unused Reference: 'RFC7045' is defined on line 348, but no explicit reference was found in the text == Unused Reference: 'RFC7113' is defined on line 353, but no explicit reference was found in the text == Unused Reference: 'RFC7123' is defined on line 358, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations Working Group (v6ops) F. Gont 3 Internet-Draft SI6 Networks / UTN-FRH 4 Intended status: Informational J. Linkova 5 Expires: June 12, 2016 Google 6 T. Chown 7 University of Southampton 8 W. Liu 9 Huawei Technologies 10 December 10, 2015 12 Observations on the Dropping of Packets with IPv6 Extension Headers in 13 the Real World 14 draft-ietf-v6ops-ipv6-ehs-in-real-world-02 16 Abstract 18 This document presents real-world data regarding the extent to which 19 packets with IPv6 extension headers are dropped in the Internet (as 20 originally measured in August 2014 and later in June 2015, with 21 similar results), and where in the network such dropping occurs. The 22 aforementioned results serve as a problem statement that is expected 23 to trigger operational advice on the filtering of IPv6 packets 24 carrying IPv6 Extension Headers, so that the situation improves over 25 time. This document also explains how the aforementioned results 26 were obtained, such that the corresponding measurements can be 27 reproduced by other members of the community and repeated over time 28 to observe changes in the handling of packets with IPv6 extension 29 headers. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on June 12, 2016. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Support of IPv6 Extension Headers in the Internet . . . . . . 3 67 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 72 6.2. Informative References . . . . . . . . . . . . . . . . . 7 73 Appendix A. Reproducing Our Experiment . . . . . . . . . . . . . 8 74 A.1. Obtaining the List of Domain Names . . . . . . . . . . . 8 75 A.2. Obtaining AAAA Resource Records . . . . . . . . . . . . . 9 76 A.3. Filtering the IPv6 Address Datasets . . . . . . . . . . . 9 77 A.4. Performing Measurements with Each IPv6 Address Dataset . 10 78 A.5. Obtaining Statistics from our Measurements . . . . . . . 11 79 Appendix B. Measurements Caveats . . . . . . . . . . . . . . . . 12 80 B.1. Isolating the Dropping Node . . . . . . . . . . . . . . . 12 81 B.2. Obtaining the Responsible Organization for the Packet 82 Drops . . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 Appendix C. Troubleshooting Packet Drops due to IPv6 Extension 84 Headers . . . . . . . . . . . . . . . . . . . . . . 14 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 IPv6 Extension Headers (EHs) allow for the extension of the IPv6 90 protocol, and provide support for core functionality such as IPv6 91 fragmentation. While packets employing IPv6 Extension Headers have 92 been suspected to be dropped in some IPv6 deployments, there was not 93 much concrete data on the topic. Some preliminary measurements have 94 been presented in [PMTUD-Blackholes], [Gont-IEPG88] and 96 [Gont-Chown-IEPG89], whereas [Linkova-Gont-IEPG90] presents more 97 comprehensive results on which this document is based. 99 This document presents real-world data regarding the extent to which 100 packets containing IPv6 Extension Headers are dropped in the 101 Internet, as measured in August 2014 and later in June 2015 with 102 similar results (pending operational advice in this area). The 103 results presented in this document indicate that in the scenarios 104 where the corresponding measurements were performed, the use of IPv6 105 extension headers can lead to packet drops. We note that, in 106 particular, packet drops occurring at transit networks are 107 undesirable, and it is hoped and expected that this situation will 108 improve over time. 110 2. Support of IPv6 Extension Headers in the Internet 112 This section summarizes the results obtained when measuring the 113 support of IPv6 Extension Headers on the path towards different types 114 of public IPv6 servers. Two sources of information were employed for 115 the list of public IPv6 servers: the "World IPv6 Launch Day" site 116 (http://www.worldipv6launch.org/) and Alexa's top 1M web sites 117 (http://www.alexa.com). For each list of domain names, the following 118 datasets were obtained: 120 o Web servers (AAAA records of the aforementioned list) 122 o Mail servers (MX -> AAAA of the aforementioned list) 124 o Name servers (NS -> AAAA of the aforementioned list) 126 Duplicate addresses and IPv6 addresses other than global unicast 127 addresses were eliminated from each of those lists prior to obtaining 128 the results included in this document. Additionally, addresses that 129 were found to be unreachable were discarded from the dataset (please 130 see Appendix B for further details). 132 For each of the aforementioned address sets, three different types of 133 probes were employed: 135 o IPv6 packets with a Destination Options header of 8 bytes 137 o IPv6 packets resulting in two IPv6 fragments of 512 bytes each 138 (approximately) 140 o IPv6 packets with a Hop-by-Hop Options header of 8 bytes 142 In the case of packets with a Destination Options Header and the case 143 of packets with a Hop-by-Hop Options header, the desired EH size was 144 achieved by means of PadN options [RFC2460]. The upper-layer 145 protocol of the probe packets was, in all cases, TCP [RFC0793] 146 segments with the Destination Port set to the service port 147 [IANA-PORT-NUMBERS] of the corresponding dataset. For example, the 148 probe packets for all the measurements involving web servers were TCP 149 segments with the destination port set to 80. 151 Besides obtaining the packet drop rate when employing the 152 aforementioned IPv6 extension headers, we tried to identify whether 153 the Autonomous System (AS) dropping the packets was the same as the 154 Autonomous System of the destination/target address. This is of 155 particular interest since it essentially reveals whether the packet 156 drops are under the control of the intended destination of the 157 packets. Packets dropped by the destination AS are less of a 158 concern, since the device dropping the packets is under the control 159 of the same organization as that to which the packets are destined 160 (hence, it is probably easier to update the filtering policy if 161 deemed necessary). On the other hand, packets dropped by transit 162 ASes are more of a concern, since they affect the deployability and 163 usability of IPv6 extension headers (including IPv6 fragmentation) by 164 a third-party (the destination AS). In any case, we note that it is 165 impossible to tell whether, in those cases where IPv6 packets with 166 extension headers get dropped, the packet drops are the result of an 167 explicit and intended policy, or the result of improper device 168 configuration defaults, buggy devices, etc. Thus, packet drops that 169 occur at the destination AS might still prove to be problematic. 171 Since there is some ambiguity when identifying the autonomous system 172 to which a specific router belongs (see Appendix B.2), each of our 173 measurements results in two different values: one corresponding to 174 the "best-case scenario", and one corresponding to the "worst-case 175 scenario". The "best-case scenario" is that in which, when in doubt, 176 the packets are assumed to be dropped by the destination AS, whereas 177 the "worst-case scenario" is that in which, when in doubt, the 178 packets are assumed to be dropped by a transit AS (please see 179 Appendix B.2 for details). In the following tables, the values shown 180 within parentheses represent the possibility that, when a packet is 181 dropped, the packet drop occurs in an AS other than the destination 182 AS (considering both the best-case scenario and the worst-case 183 scenario). 185 +-------------+-----------------+-----------------+-----------------+ 186 | Dataset | DO8 | HBH8 | FH512 | 187 +-------------+-----------------+-----------------+-----------------+ 188 | Webservers | 11.88% | 40.70% | 30.51% | 189 | | (17.60%/20.80%) | (31.43%/40.00%) | (5.08%/6.78%) | 190 +-------------+-----------------+-----------------+-----------------+ 191 | Mailservers | 17.07% | 48.86% | 39.17% | 192 | | (6.35%/26.98%) | (40.50%/65.42%) | (2.91%/12.73%) | 193 +-------------+-----------------+-----------------+-----------------+ 194 | Nameservers | 15.37% | 43.25% | 38.55% | 195 | | (14.29%/33.46%) | (42.49%/72.07%) | (3.90%/13.96%) | 196 +-------------+-----------------+-----------------+-----------------+ 198 Table 1: WIPv6LD dataset: Packet drop rate for different destination 199 types, and estimated percentage of dropped packets that were deemed 200 to be dropped in a different AS (lower, in parentheses) 202 NOTE: As an example, we note that the cell describing the support 203 of IPv6 packets with DO8 for webservers (containing the value 204 "11.88% (17.60%/20.80%)") should be read as: "when sending IPv6 205 packets with DO8 to public webservers, 11.88% of such packets get 206 dropped. Among those packets that get dropped, 17.60%/20.80% 207 (best case / worst case) of them get dropped at an AS other than 208 the destination AS". 210 +-------------+-----------------+-----------------+-----------------+ 211 | Dataset | DO8 | HBH8 | FH512 | 212 +-------------+-----------------+-----------------+-----------------+ 213 | Webservers | 10.91% | 39.03% | 28.26% | 214 | | (46.52%/53.23%) | (36.90%/46.35%) | (53.64%/61.43%) | 215 +-------------+-----------------+-----------------+-----------------+ 216 | Mailservers | 11.54% | 45.45% | 35.68% | 217 | | (2.41%/21.08%) | (41.27%/61.13%) | (3.15%/10.92%) | 218 +-------------+-----------------+-----------------+-----------------+ 219 | Nameservers | 21.33% | 54.12% | 55.23% | 220 | | (10.27%/56.80%) | (50.64%/81.00%) | (5.66%/32.23%) | 221 +-------------+-----------------+-----------------+-----------------+ 223 Table 2: Alexa's top 1M sites dataset: Packet drop rate for different 224 destination types, and estimated percentage of dropped packets that 225 were deemed to be dropped in a different AS (lower, in parentheses) 227 There are a number of observations to be made based on the results 228 presented above. Firstly, while it has been generally assumed that 229 it is IPv6 fragments that are dropped by operators, our results 230 indicate that it is IPv6 extension headers in general that result in 231 packet drops. Secondly, our results indicate that a significant 232 percentage of such packet drops occurs in transit Autonomous Systems; 233 that is, the packet drops are not under the control of the same 234 organization as the final destination. 236 3. IANA Considerations 238 There are no IANA registries within this document. The RFC-Editor 239 can remove this section before publication of this document as an 240 RFC. 242 4. Security Considerations 244 This document presents real-world data regarding the extent to which 245 IPv6 packets employing extension headers are dropped in the Internet. 246 As such, this document does not introduce any new security issues. 248 5. Acknowledgements 250 The authors would like to thank (in alphabetical order) Mikael 251 Abrahamsson, Mark Andrews, Fred Baker, Brian Carpenter, Gert Doering, 252 C. M. Heard, Nick Hilliard, Joel Jaeggli, Tatuya Jinmei, Merike 253 Kaeo, Warren Kumari, Ted Lemon, Mark Smith, Ole Troan, and Eric 254 Vyncke, for providing valuable comments on earlier versions of this 255 document. Additionally, the authors would like to thank participants 256 of the v6ops and opsec working groups for their valuable input on the 257 topics discussed in this document. 259 The authors would like to thank Fred Baker for his guidance in 260 improving this document. 262 Fernando Gont would like to thank Jan Zorz / Go6 Lab 263 , and Jared Mauch / NTT America, for providing 264 access to systems and networks that were employed to produce some of 265 the measurement results presented in this document. Additionally, he 266 would like to thank SixXS for providing IPv6 267 connectivity. 269 6. References 271 6.1. Normative References 273 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 274 RFC 793, DOI 10.17487/RFC0793, September 1981, 275 . 277 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 278 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 279 . 281 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 282 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 283 December 1998, . 285 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 286 Control Message Protocol (ICMPv6) for the Internet 287 Protocol Version 6 (IPv6) Specification", RFC 4443, 288 DOI 10.17487/RFC4443, March 2006, 289 . 291 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 292 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 293 DOI 10.17487/RFC4861, September 2007, 294 . 296 6.2. Informative References 298 [blackhole6] 299 blackhole6, , "blackhole6 tool manual page", 300 , 2014. 302 [Gont-Chown-IEPG89] 303 Gont, F. and T. Chown, "A Small Update on the Use of IPv6 304 Extension Headers", IEPG 89. London, UK. March 2, 2014, 305 . 308 [Gont-IEPG88] 309 Gont, F., "Fragmentation and Extension header Support in 310 the IPv6 Internet", IEPG 88. Vancouver, BC, Canada. 311 November 13, 2013, . 314 [IANA-PORT-NUMBERS] 315 IANA, "Service Name and Transport Protocol Port Number 316 Registry", . 320 [IPv6-Toolkit] 321 "SI6 Networks' IPv6 Toolkit", 322 . 324 [Linkova-Gont-IEPG90] 325 Linkova, J. and F. Gont, "IPv6 Extension Headers in the 326 Real World v2.0", IEPG 90. Toronto, ON, Canada. July 20, 327 2014, . 330 [path6] path6, , "path6 tool manual page", 331 , 2014. 333 [PMTUD-Blackholes] 334 De Boer, M. and J. Bosma, "Discovering Path MTU black 335 holes on the Internet using RIPE Atlas", July 2012, 336 . 339 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, 340 DOI 10.17487/RFC5927, July 2010, 341 . 343 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 344 with IPv6 Neighbor Discovery", RFC 6980, 345 DOI 10.17487/RFC6980, August 2013, 346 . 348 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 349 of IPv6 Extension Headers", RFC 7045, 350 DOI 10.17487/RFC7045, December 2013, 351 . 353 [RFC7113] Gont, F., "Implementation Advice for IPv6 Router 354 Advertisement Guard (RA-Guard)", RFC 7113, 355 DOI 10.17487/RFC7113, February 2014, 356 . 358 [RFC7123] Gont, F. and W. Liu, "Security Implications of IPv6 on 359 IPv4 Networks", RFC 7123, DOI 10.17487/RFC7123, February 360 2014, . 362 Appendix A. Reproducing Our Experiment 364 This section describes, step by step, how to reproduce the experiment 365 with which we obtained the results presented in this document. Each 366 subsection represents one step in the experiment. The tools employed 367 for the experiment are traditional UNIX-like tools (such as gunzip), 368 and the SI6 Networks' IPv6 Toolkit [IPv6-Toolkit]. 370 A.1. Obtaining the List of Domain Names 372 The primary data source employed was Alexa's Top 1M web sites, 373 available at: . 374 The file is a zipped file containing the list of the most popular web 375 sites, in CSV format. The aforementioned file can be extracted with 376 "gunzip < top-1m.csv.zip > top-1m.csv". 378 A list of domain names (i.e., other data stripped) can be obtained 379 with the following command of [IPv6-Toolkit]: "cat top-1m.csv | 380 script6 get-alexa-domains > top-1m.txt". This command will create a 381 "top-1m.txt" file, containing one domain name per line. 383 NOTE: The domain names corresponding to the WIPv6LD dataset is 384 available at: . Since the corresponding file is a text file 386 containing one domain name per line, the steps produced in this 387 subsection need not be performed. The WIPv6LD data set should be 388 processed in the same way as the Alexa Dataset, starting from 389 Appendix A.2. 391 A.2. Obtaining AAAA Resource Records 393 The file obtained in the previous subsection contains a list of 394 domain names that correspond to web sites. The AAAA records for such 395 domain names can be obtained with: 397 $ cat top-1m.txt | script6 get-aaaa > top-1m-web-aaaa.txt 399 The AAAA records corresponding to the mailservers of each of the 400 aforementioned domain names can be obtained with: 402 $ cat top-1m.txt | script6 get-mx | script6 get-aaaa > top-1m-mail- 403 aaaa.txt 405 The AAAA records corresponding to the nameservers of each of the 406 aforementioned domain names can be obtained with: 408 $ cat top-1m.txt | script6 get-ns | script6 get-aaaa > top-1m-dns- 409 aaaa.txt 411 A.3. Filtering the IPv6 Address Datasets 413 The lists of IPv6 addresses obtained in the previous step could 414 possibly contain undesired addresses (i.e., non-global unicast 415 addresses) and/or duplicate addresses. In order to remove both 416 undesired and duplicate addresses, each of the three files from the 417 previous section should be filtered accordingly: 419 $ cat top-1m-web-aaaa.txt | addr6 -i -q -B multicast -B unspec -k 420 global > top-1m-web-aaaa-unique.txt 422 $ cat top-1m-mail-aaaa.txt | addr6 -i -q -B multicast -B unspec -k 423 global > top-1m-mail-aaaa-unique.txt 424 $ cat top-1m-dns-aaaa.txt | addr6 -i -q -B multicast -B unspec -k 425 global > top-1m-dns-aaaa-unique.txt 427 A.4. Performing Measurements with Each IPv6 Address Dataset 429 A.4.1. Measurements with web servers 431 In order to measure DO8 with the list of webservers: 433 # cat top-1m-web-aaaa-unique.txt | script6 trace6 do8 tcp 80 > top- 434 1m-web-aaaa-do8-m.txt 436 In order to measure HBH8 with the list of webservers: 438 # cat top-1m-web-aaaa-unique.txt | script6 trace6 hbh8 tcp 80 > top- 439 1m-web-aaaa-hbh8-m.txt 441 In order to measure FH512 with the list of webservers: 443 # cat top-1m-web-aaaa-unique.txt | script6 trace6 fh512 tcp 80 > top- 444 1m-web-aaaa-fh512-m.txt 446 A.4.2. Measurements with mail servers 448 In order to measure DO8 with the list of mailservers: 450 # cat top-1m-mail-aaaa-unique.txt | script6 trace6 do8 tcp 25 > top- 451 1m-mail-aaaa-do8-m.txt 453 In order to measure HBH8 with the list of webservers: 455 # cat top-1m-mail-aaaa-unique.txt | script6 trace6 hbh8 tcp 25 > top- 456 1m-mail-aaaa-hbh8-m.txt 458 In order to measure FH512 with the list of webservers: 460 # cat top-1m-mail-aaaa-unique.txt | script6 trace6 fh512 tcp 25 > 461 top-1m-mail-aaaa-fh512-m.txt 463 A.4.3. Measurements with DNS servers 465 In order to measure DO8 with the list of mameservers: 467 # cat top-1m-dns-aaaa-unique.txt | script6 trace6 do8 tcp 53 > top- 468 1m-dns-aaaa-do8-m.txt 470 In order to measure HBH8 with the list of webservers: 472 # cat top-1m-dns-aaaa-unique.txt | script6 trace6 hbh8 tcp 53 > top- 473 1m-dns-aaaa-hbh8-m.txt 475 In order to measure FH512 with the list of webservers: 477 # cat top-1m-dns-aaaa-unique.txt | script6 trace6 fh512 tcp 53 > top- 478 1m-dns-aaaa-fh512-m.txt 480 A.5. Obtaining Statistics from our Measurements 482 A.5.1. Statistics for Web Servers 484 In order to compute the statistics corresponding to our measurements 485 of DO8 with the list of webservers: 487 $ cat top-1m-web-aaaa-do8-m.txt | script6 get-trace6-stats > top-1m- 488 web-aaaa-do8-stats.txt 490 In order to compute the statistics corresponding to our measurements 491 of HBH8 with the list of webservers: 493 $ cat top-1m-web-aaaa-hbh8-m.txt | script6 get-trace6-stats > top-1m- 494 web-aaaa-hbh8-stats.txt 496 In order to compute the statistics corresponding to our measurements 497 of FH512 with the list of webservers: 499 $ cat top-1m-web-aaaa-fh512-m.txt | script6 get-trace6-stats > top- 500 1m-web-aaaa-fh512-stats.txt 502 A.5.2. Statistics for Mail Servers 504 In order to compute the statistics corresponding to our measurements 505 of DO8 with the list of mailservers: 507 $ cat top-1m-mail-aaaa-do8-m.txt | script6 get-trace6-stats > top-1m- 508 mail-aaaa-do8-stats.txt 510 In order to compute the statistics corresponding to our measurements 511 of HBH8 with the list of mailservers: 513 $ cat top-1m-mail-aaaa-hbh8-m.txt | script6 get-trace6-stats > top- 514 1m-mail-aaaa-hbh8-stats.txt 516 In order to compute the statistics corresponding to our measurements 517 of FH512 with the list of mailservers: 519 $ cat top-1m-mail-aaaa-fh512-m.txt | script6 get-trace6-stats > top- 520 1m-mail-aaaa-fh512-stats.txt 522 A.5.3. Statistics for Name Servers 524 In order to compute the statistics corresponding to our measurements 525 of DO8 with the list of nameservers: 527 $ cat top-1m-dns-aaaa-do8-m.txt | script6 get-trace6-stats > top-1m- 528 dns-aaaa-do8-stats.txt 530 In order to compute the statistics corresponding to our measurements 531 of HBH8 with the list of mailservers: 533 $ cat top-1m-dns-aaaa-hbh8-m.txt | script6 get-trace6-stats > top-1m- 534 dns-aaaa-hbh8-stats.txt 536 In order to compute the statistics corresponding to our measurements 537 of FH512 with the list of mailservers: 539 $ cat top-1m-dns-aaaa-fh512-m.txt | script6 get-trace6-stats > top- 540 1m-dns-aaaa-fh512-stats.txt 542 Appendix B. Measurements Caveats 544 A number of issues have needed some consideration when producing the 545 results presented in this document. These same issues should be 546 considered when troubleshooting connectivity problems resulting from 547 the use of IPv6 Extension headers. 549 B.1. Isolating the Dropping Node 551 Let us assume that we find that IPv6 packets with EHs are being 552 dropped on their way to the destination system 2001:db8:d::1, and 553 that the output of running traceroute towards such destination is: 555 1. 2001:db8:1:1000::1 556 2. 2001:db8:2:4000::1 557 3. 2001:db8:3:4000::1 558 4. 2001:db8:3:1000::1 559 5. 2001:db8:4:4000::1 560 6. 2001:db8:4:1000::1 561 7. 2001:db8:5:5000::1 562 8. 2001:db8:5:6000::1 563 9. 2001:db8:d::1 565 Additionally, let us assume that the output of EH-enabled traceroute 566 to the same destination is: 568 1. 2001:db8:1:1000::1 569 2. 2001:db8:2:4000::1 570 3. 2001:db8:3:4000::1 571 4. 2001:db8:3:1000::1 572 5. 2001:db8:4:4000::1 574 For the sake of brevity, let us refer to the last-responding node in 575 the EH-enabled traceroute ("2001:db8:4:4000::1" in this case) as "M". 576 Assuming that packets in both traceroutes employ the same path, we'll 577 refer to "the node following the last responding node in the EH- 578 enabled traceroute" ("2001:db8:4:1000::1" in our case), as "M+1", 579 etc. 581 Based on traceroute information above, which node is the one actually 582 dropping the EH-enabled packets will depend on whether the dropping 583 node filters packets before making the forwarding decision, or after 584 making the forwarding decision. If the former, the dropping node 585 will be M+1. If the latter, the dropping node will be "M". 587 Throughout this document (and our measurements), we assume that those 588 nodes dropping packets that carry IPv6 EHs apply their filtering 589 policy, and only then, if necessary, forward the packets. Thus, in 590 our example above the last responding node to the EH-enabled 591 traceroute ("M") is "2001:db8:4:4000::1", and therefore we assume the 592 dropping node to be "2001:db8:4:1000::1" ("M+1"). 594 Additionally, we note that when isolating the dropping node we assume 595 that both the EH-enabled and the EH-free traceroutes result in the 596 same paths. However, this might not be the case. 598 B.2. Obtaining the Responsible Organization for the Packet Drops 600 In order to identify the organization operating the dropping node, 601 one would be tempted to lookup the ASN corresponding to the dropping 602 node. However, assuming that M and M+1 are two peering routers, any 603 of these two organizations could be providing the address space 604 employed for such peering. Or, in the case of an Internet eXchange 605 Point (IXP), the address space could correspond to the IXP AS, rather 606 than to any of the participating ASes. Thus, the organization 607 operating the dropping node (M+1) could be the AS for M+1, but it 608 might as well be the AS for M+2. Only when the ASN for M+1 is the 609 same as the ASN for M+2 we have certainty about who the responsible 610 organization for the packet drops is (see slides 21-23 of 611 [Linkova-Gont-IEPG90]). 613 In the measurement results presented in Section 2, the aforementioned 614 ambiguity results in a "best-case" and a "worst-case" scenario 615 (rather than a single value): the lowest percentage value means that, 616 when in doubt, we assume the packet drops occur in the same AS as the 617 destination; on the other hand, the highest percentage value means 618 that, when in doubt, we assume the packet drops occur at different AS 619 than the destination AS. 621 We note that the aforementioned ambiguity should also be considered 622 when troubleshooting and reporting IPv6 packet drops, since 623 identifying the organization responsible for the packet drops might 624 probe to be a non-trivial task. 626 Finally, we note that a specific organization might be operating more 627 than one Autonomous System. However, our measurements assume that 628 different Autonomous System Numbers imply different organizations. 630 Appendix C. Troubleshooting Packet Drops due to IPv6 Extension Headers 632 Isolating IPv6 blackholes essentially involves performing IPv6 633 traceroute for a destination system with and without IPv6 extension 634 headers. The EH-free traceroute would provide the full working path 635 towards a destination, while the EH-enabled traceroute would provide 636 the address of the last-responding node for EH-enabled packets (say, 637 "M"). In principle, one could isolate the dropping node by looking- 638 up "M" in the EH-free traceroute, with the dropping node being "M+1" 639 (see Appendix B.1 for caveats). 641 At the time of this writing, most traceroute implementations do not 642 support IPv6 extension headers. However, the path6 tool [path6] of 643 [IPv6-Toolkit] provides such support. Additionally, the blackhole6 644 tool [blackhole6] of [IPv6-Toolkit] automates the troubleshooting 645 process and can readily provide information such as: dropping node's 646 IPv6 address, dropping node's Autonomous System, etc. 648 Authors' Addresses 650 Fernando Gont 651 SI6 Networks / UTN-FRH 652 Evaristo Carriego 2644 653 Haedo, Provincia de Buenos Aires 1706 654 Argentina 656 Phone: +54 11 4650 8472 657 Email: fgont@si6networks.com 658 URI: http://www.si6networks.com 659 J. Linkova 660 Google 661 1600 Amphitheatre Parkway 662 Mountain View, CA 94043 663 USA 665 Email: furry@google.com 667 Tim Chown 668 University of Southampton 669 Highfield 670 Southampton , Hampshire SO17 1BJ 671 United Kingdom 673 Email: tjc@ecs.soton.ac.uk 675 Will(Shucheng) Liu 676 Huawei Technologies 677 Bantian, Longgang District 678 Shenzhen 518129 679 P.R. China 681 Email: liushucheng@huawei.com