idnits 2.17.1 draft-gont-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 (March 8, 2015) is 3336 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 301, but no explicit reference was found in the text == Unused Reference: 'RFC4443' is defined on line 307, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 311, but no explicit reference was found in the text == Unused Reference: 'RFC6145' is defined on line 315, but no explicit reference was found in the text == Unused Reference: 'RFC6946' is defined on line 318, but no explicit reference was found in the text == Unused Reference: 'RFC5927' is defined on line 357, but no explicit reference was found in the text == Unused Reference: 'RFC6980' is defined on line 359, but no explicit reference was found in the text == Unused Reference: 'RFC7045' is defined on line 362, but no explicit reference was found in the text == Unused Reference: 'RFC7113' is defined on line 365, but no explicit reference was found in the text == Unused Reference: 'RFC7123' is defined on line 368, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) Summary: 3 errors (**), 0 flaws (~~), 11 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: September 9, 2015 Google 6 T. Chown 7 University of Southampton 8 W. Liu 9 Huawei Technologies 10 March 8, 2015 12 Observations on IPv6 EH Filtering in the Real World 13 draft-gont-v6ops-ipv6-ehs-in-real-world-02 15 Abstract 17 This document presents real-world data regarding the extent to which 18 packets with IPv6 extension headers are filtered in the Internet (as 19 measured in August 2014), and where in the network such filtering 20 occurs. The aforementioned results serve as a problem statement that 21 is expected to trigger operational advice on the filtering of IPv6 22 packets carrying IPv6 Extension Headers, so that the situation 23 improves over time. This document also explains how the 24 aforementioned results were obtained, such that the corresponding 25 measurements can be reproduced by other members of the community. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 9, 2015. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Support of IPv6 Extension Headers in the Internet . . . . . . 3 63 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 6.2. Informative References . . . . . . . . . . . . . . . . . 8 69 Appendix A. Reproducing Our Experiment . . . . . . . . . . . . . 9 70 A.1. Obtaining the List of Domain Names . . . . . . . . . . . 9 71 A.2. Obtaining AAAA Resource Records . . . . . . . . . . . . . 9 72 A.3. Filtering the IPv6 Address Datasets . . . . . . . . . . . 10 73 A.4. Performing Measurements with Each IPv6 Address Dataset . 10 74 A.5. Obtaining Statistics from our Measurements . . . . . . . 11 75 Appendix B. Measurements Caveats . . . . . . . . . . . . . . . . 13 76 B.1. Isolating the Dropping Node . . . . . . . . . . . . . . . 13 77 B.2. Obtaining the Responsible Organization for the Packet 78 Drops . . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 Appendix C. Troubleshooting Packet Drops due to IPv6 Extension 80 Headers . . . . . . . . . . . . . . . . . . . . . . 14 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 83 1. Introduction 85 IPv6 Extension Headers (EHs) allow for the extension of the IPv6 86 protocol, and provide support for core functionality such as IPv6 87 fragmentation. While packets employing IPv6 Extension Headers have 88 been suspected to be dropped in some IPv6 deployments, there was not 89 much concrete data on the topic. Some preliminary measurements have 90 been presented in [PMTUD-Blackholes], [Gont-IEPG88] and 91 [Gont-Chown-IEPG89], whereas [Linkova-Gont-IEPG90] presents more 92 comprehensive results on which this document is based. 94 This document presents real-world data regarding the extent to which 95 IPv6 Extension Headers are filtered in the Internet, as measured in 96 August 2014 (pending operational advice in this area). 98 2. Support of IPv6 Extension Headers in the Internet 100 This section summarizes the results obtained when measuring the 101 support of IPv6 Extension Headers on the path towards different types 102 of public IPv6 servers. Two sources were employed for the list of 103 public IPv6 servers: the "World IPv6 Launch Day" site 104 (http://www.worldipv6launch.org/) and Alexa's top 1M web sites 105 (http://www.alexa.com). For each list of domain names, the following 106 datasets were obtained: 108 o Web servers (AAAA records of the aforementioned list) 110 o Mail servers (MX -> AAAA of such list) 112 o Name servers (NS -> AAAA of such list) 114 IPv6 addresses other than global unicast addresses and duplicate 115 addresses were eliminated from each of those lists prior to obtaining 116 the results included in this document. Additionally, addresses that 117 were found to be unreachable were discarded from the dataset (please 118 see Appendix B for further details). 120 For each of the aforementioned address sets, three different types of 121 probes were performed: 123 o IPv6 packets with a Destination Options header of 8 bytes 125 o IPv6 packets resulting in two IPv6 fragments of 512 bytes each 126 (approximately) 128 o IPv6 packets with a Hop-by-Hop Options header of 8 bytes 130 In the case of packets with Destination Options Header and Hop-by-Hop 131 Options header, the desired EH size was achieved by means of PadN 132 options [RFC2460]. The upper-layer protocol of the probe packets 133 was, in all cases, TCP [RFC0793] segments with the Destination Port 134 set to the service port [IANA-PORT-NUMBERS] of the corresponding 135 dataset. For example, the probe packets for all the measurements 136 involving web servers were TCP segments with the destination port set 137 to 80. 139 Besides obtaining the packet drop rate when employing the 140 aforementioned IPv6 extension headers, we tried to identify whether 141 the Autonomous System (AS) dropping the packets was the same as the 142 Autonomous System of the destination/target address. This is of 143 particular interest since it essentially reveals whether the packet 144 drops are under the control of the intended destination of the 145 packets. Packets dropped by the destination AS are less of a 146 concern, since the device dropping the packets is under the control 147 of the same organization as that to which the packets are destined 148 (hence, it is probably easier to update the filtering policy if 149 deemed necessary). On the other hand, packets dropped by transit 150 ASes are more of a concern, since they affect the deployability and 151 usability of IPv6 extension headers (including IPv6 fragmentation) by 152 a third-party (the destination AS). In any case, we note that it is 153 impossible to tell whether, in those cases where IPv6 packets with 154 extension headers get dropped, the packet drops are the result of an 155 explicit and intended policy, or the result of improper device 156 configuration defaults, buggy devices, etc. Thus, packet drops that 157 occur at the destination AS might still prove to be problematic. 159 Since there is some ambiguity when identifying the autonomous system 160 to which a specific router belongs, our measurements result in a 161 percentage *range* (see Appendix B.2). In the following tables, the 162 values shown within parentheses represent the estimated range of 163 possibility that when a packet is dropped, the packet drop occurs in 164 an AS other than the destination AS. 166 +-------------+-----------------+-----------------+-----------------+ 167 | Dataset | DO8 | HBH8 | FH512 | 168 +-------------+-----------------+-----------------+-----------------+ 169 | Webservers | 11.88% | 40.70% | 30.51% | 170 | | (17.60%-20.80%) | (31.43%-40.00%) | (5.08%-6.78%) | 171 +-------------+-----------------+-----------------+-----------------+ 172 | Mailservers | 17.07% | 48.86% | 39.17% | 173 | | (6.35%-26.98%) | (40.50%-65.42%) | (2.91%-12.73%) | 174 +-------------+-----------------+-----------------+-----------------+ 175 | Nameservers | 15.37% | 43.25% | 38.55% | 176 | | (14.29%-33.46%) | (42.49%-72.07%) | (3.90%-13.96%) | 177 +-------------+-----------------+-----------------+-----------------+ 179 Table 1: WIPv6LD dataset: Packet drop rate for different destination 180 types, and estimated percentage of dropped packets that were deemed 181 to be dropped in a different AS (lower, in parentheses) 183 NOTE: As an example, we note that the cell describing the support 184 of IPv6 packets with DO8 for webservers (containing the value 185 "11.88% (17.60%-20.80%)") should be read as: "when sending IPv6 186 packets with DO8 to public webservers, 11.88% of such packets get 187 dropped. Among those packets that get dropped, between 17.60%- 188 20.80% of them get dropped at an AS other than the destination 189 AS". 191 +--------+------------------+-------------------+-------------------+ 192 | EH | Webservers | Mailservers | Nameservers | 193 | Type | | | | 194 +--------+------------------+-------------------+-------------------+ 195 | DO8 | 11.88% | 17.07% | 15.37% | 196 | | (17.60%-20.80%) | (6.35%-26.98%) | (14.29%-33.46%) | 197 +--------+------------------+-------------------+-------------------+ 198 | HBH8 | 40.70% | 48.86% | 43.25% | 199 | | (31.43%-40.00%) | (40.50%-65.42%) | (42.49%-72.07%) | 200 +--------+------------------+-------------------+-------------------+ 201 | FH512 | 30.51% | 39.17% | 38.55% | 202 | | (5.08%-6.78%) | (2.91%-12.73%) | (3.90%-13.96%) | 203 +--------+------------------+-------------------+-------------------+ 205 Table 2: WIPv6LD dataset: Packet drop rate for different EH types, 206 and estimated percentage of dropped packets that were deemed to be 207 dropped in a different AS (lower, in parentheses) 209 NOTE: This table contains the same information as Table 1, but 210 makes it easier to obtain the drop rates for each EH type. Each 211 cell should be read in exactly the same way as each cell in 212 Table 1. 214 +-------------+-----------------+-----------------+-----------------+ 215 | Dataset | DO8 | HBH8 | FH512 | 216 +-------------+-----------------+-----------------+-----------------+ 217 | Webservers | 10.91% | 39.03% | 28.26% | 218 | | (46.52%-53.23%) | (36.90%-46.35%) | (53.64%-61.43%) | 219 +-------------+-----------------+-----------------+-----------------+ 220 | Mailservers | 11.54% | 45.45% | 35.68% | 221 | | (2.41%-21.08%) | (41.27%-61.13%) | (3.15%-10.92%) | 222 +-------------+-----------------+-----------------+-----------------+ 223 | Nameservers | 21.33% | 54.12% | 55.23% | 224 | | (10.27%-56.80%) | (50.64%-81.00%) | (5.66%-32.23%) | 225 +-------------+-----------------+-----------------+-----------------+ 227 Table 3: Alexa's top 1M sites dataset: Packet drop rate for different 228 destination types, and estimated percentage of dropped packets that 229 were deemed to be dropped in a different AS (lower, in parentheses) 231 +--------+------------------+-------------------+-------------------+ 232 | EH | Webservers | Mailservers | Nameservers | 233 | Type | | | | 234 +--------+------------------+-------------------+-------------------+ 235 | DO8 | 10.91% | 11.54% | 21.33% | 236 | | (46.52%-53.23%) | (2.41%-21.08%) | (10.27%-56.80%) | 237 +--------+------------------+-------------------+-------------------+ 238 | HBH8 | 39.03% | 45.45% | 54.12% | 239 | | (36.90%-46.35%) | (41.27%-61.13%) | (50.64%-81.00%) | 240 +--------+------------------+-------------------+-------------------+ 241 | FH512 | 28.26% | 35.68% | 55.23% | 242 | | (53.64%-61.43%) | (3.15%-10.92%) | (5.66%-32.23%) | 243 +--------+------------------+-------------------+-------------------+ 245 Table 4: Alexa's top 1M sites dataset: Packet drop rate for different 246 EH types, and estimated percentage of dropped packets that were 247 deemed to be dropped in a different AS (lower, in parentheses) 249 NOTE: This table contains the same information as Table 3, but 250 makes it easier to obtain the drop rates for each EH type. Each 251 cell should be read in exactly the same way as each cell in 252 Table 3. 254 There are a number of observations to be made based on the results 255 presented above. Firstly, while it has been generally assumed that 256 it is IPv6 fragments that are dropped by operators, our results 257 indicate that it is IPv6 extension headers in general that result in 258 packet drops. Secondly, our results indicate that a significant 259 percentage of such packet drops occur in transit Autonomous Systems; 260 that is, the packet drops are not under the control of the same 261 organization as the final destination. 263 3. IANA Considerations 265 There are no IANA registries within this document. The RFC-Editor 266 can remove this section before publication of this document as an 267 RFC. 269 4. Security Considerations 271 This document presents real-world data regarding the extent to which 272 IPv6 packets employing extension headers are filtered in the 273 Internet. As such, this document does not introduce any new security 274 issues. 276 5. Acknowledgements 278 The authors would like to thank (in alphabetical order) Mark Andrews, 279 Fred Baker, Brian Carpenter and Tatuya Jinmei for providing valuable 280 comments on earlier versions of this document. Additionally, the 281 authors would like to thank participants of the v6ops and opsec 282 working groups for their valuable input on the topics discussed in 283 this document. 285 The authors would like to thank Fred Baker for his guidance in 286 improving this document. 288 Fernando Gont would like to thank Jan Zorz and Go6 Lab 289 for providing access to systems and networks that 290 were employed to produce some of the measurement results presented in 291 this document. Additionally, he would like to thank SixXS 292 for providing IPv6 connectivity. 294 6. References 296 6.1. Normative References 298 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 299 793, September 1981. 301 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 302 STD 13, RFC 1034, November 1987. 304 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 305 (IPv6) Specification", RFC 2460, December 1998. 307 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 308 Message Protocol (ICMPv6) for the Internet Protocol 309 Version 6 (IPv6) Specification", RFC 4443, March 2006. 311 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 312 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 313 September 2007. 315 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 316 Algorithm", RFC 6145, April 2011. 318 [RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC 319 6946, May 2013. 321 6.2. Informative References 323 [Gont-Chown-IEPG89] 324 Gont, F. and T. Chown, "A Small Update on the Use of IPv6 325 Extension Headers", IEPG 89. London, UK. March 2, 2014, 326 . 329 [Gont-IEPG88] 330 Gont, F., "Fragmentation and Extension header Support in 331 the IPv6 Internet", IEPG 88. Vancouver, BC, Canada. 332 November 13, 2013, . 335 [IANA-PORT-NUMBERS] 336 IANA, "Service Name and Transport Protocol Port Number 337 Registry", . 341 [IPv6-Toolkit] 342 "SI6 Networks' IPv6 Toolkit", 343 . 345 [Linkova-Gont-IEPG90] 346 Linkova, J. and F. Gont, "IPv6 Extension Headers in the 347 Real World v2.0", IEPG 90. Toronto, ON, Canada. July 20, 348 2014, . 351 [PMTUD-Blackholes] 352 De Boer, M. and J. Bosma, "Discovering Path MTU black 353 holes on the Internet using RIPE Atlas", July 2012, 354 . 357 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010. 359 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 360 with IPv6 Neighbor Discovery", RFC 6980, August 2013. 362 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 363 of IPv6 Extension Headers", RFC 7045, December 2013. 365 [RFC7113] Gont, F., "Implementation Advice for IPv6 Router 366 Advertisement Guard (RA-Guard)", RFC 7113, February 2014. 368 [RFC7123] Gont, F. and W. Liu, "Security Implications of IPv6 on 369 IPv4 Networks", RFC 7123, February 2014. 371 [blackhole6] 372 blackhole6, , "blackhole6 tool manual page", 373 , 2014. 375 [path6] path6, , "path6 tool manual page", 376 , 2014. 378 Appendix A. Reproducing Our Experiment 380 This section describes, step by step, how to reproduce the experiment 381 with which we obtained the results presented in this document. Each 382 subsection represents one step in the experiment. The tools employed 383 for the experiment are traditional UNIX-like tools (such as gunzip), 384 and the SI6 Networks' IPv6 Toolkit [IPv6-Toolkit]. 386 A.1. Obtaining the List of Domain Names 388 The primary data source employed was Alexa's Top 1M web sites, 389 available at: . 390 The file is a zipped file containing the list of the most popular web 391 sites, in CSV format. The aforementioned file an be extracted with 392 "gunzip < top-1m.csv.zip > top-1m.csv". 394 A list of domain names (i.e., other data stripped) can be obtained 395 with the following command of [IPv6-Toolkit]: "cat top-1m.csv | 396 script6 get-alexa-domains > top-1m.txt". This command will create a 397 "top-1m.txt" file, containing one domain name per line. 399 NOTE: The domain names corresponding to the WIPv6LD dataset is 400 available at: . Since the corresponding file is a text file 402 containing one domain name per line, the steps produced in this 403 subsection need not be performed. The WIPv6LD data set should be 404 processed in the same way as the Alexa Dataset, starting from 405 Appendix A.2. 407 A.2. Obtaining AAAA Resource Records 409 The file obtained in the previous subsection contains a list of 410 domain names that correspond to web sites. The AAAA records for such 411 domains can be obtained with: 413 $ cat top-1m.txt | script6 get-aaaa > top-1m-web-aaaa.txt 414 The AAAA records corresponding to the mailservers of each of the 415 aforementioned domain names can be obtained with: 417 $ cat top-1m.txt | script6 get-mx | script6 get-aaaa > top-1m-mail- 418 aaaa.txt 420 The AAAA records corresponding to the nameservers of each of the 421 aforementioned domain names can be obtained with: 423 $ cat top-1m.txt | script6 get-ns | script6 get-aaaa > top-1m-dns- 424 aaaa.txt 426 A.3. Filtering the IPv6 Address Datasets 428 The lists of IPv6 addresses obtained in the previous step could 429 possibly contain undesired addresses (i.e., non-global unicast 430 addresses) and/or duplicate addresses. In order to remove both 431 undesired and duplicate addresses each of the three files from the 432 previous section should be filtered accordingly: 434 $ cat top-1m-web-aaaa.txt | addr6 -i -q -B multicast -B unspec -k 435 global > top-1m-web-aaaa-unique.txt 437 $ cat top-1m-mail-aaaa.txt | addr6 -i -q -B multicast -B unspec -k 438 global > top-1m-mail-aaaa-unique.txt 440 $ cat top-1m-dns-aaaa.txt | addr6 -i -q -B multicast -B unspec -k 441 global > top-1m-dns-aaaa-unique.txt 443 A.4. Performing Measurements with Each IPv6 Address Dataset 445 A.4.1. Measurements with web servers 447 In order to measure DO8 with the list of webservers: 449 # cat top-1m-web-aaaa-unique.txt | script6 trace6 do8 tcp 80 > > top- 450 1m-web-aaaa-do8-m.txt 452 In order to measure HBH8 with the list of webservers: 454 # cat top-1m-web-aaaa-unique.txt | script6 trace6 hbh8 tcp 80 > > 455 top-1m-web-aaaa-hbh8--m.txt 457 In order to measure FH512 with the list of webservers: 459 # cat top-1m-web-aaaa-unique.txt | script6 trace6 fh512 tcp 80 > > 460 top-1m-web-aaaa-fh512-m.txt 462 A.4.2. Measurements with mail servers 464 In order to measure DO8 with the list of mailservers: 466 # cat top-1m-mail-aaaa-unique.txt | script6 trace6 do8 tcp 25 > top- 467 1m-mail-aaaa-do8-m.txt 469 In order to measure HBH8 with the list of webservers: 471 # cat top-1m-mail-aaaa-unique.txt | script6 trace6 hbh8 tcp 25 > top- 472 1m-mail-aaaa-hbh8-m.txt 474 In order to measure FH512 with the list of webservers: 476 # cat top-1m-mail-aaaa-unique.txt | script6 trace6 fh512 tcp 25 > 477 top-1m-mail-aaaa-fh512-m.txt 479 A.4.3. Measurements with DNS servers 481 In order to measure DO8 with the list of mameservers: 483 # cat top-1m-dns-aaaa-unique.txt | script6 trace6 do8 tcp 53 > top- 484 1m-dns-aaaa-do8-m.txt 486 In order to measure HBH8 with the list of webservers: 488 # cat top-1m-dns-aaaa-unique.txt | script6 trace6 hbh8 tcp 53 > top- 489 1m-dns-aaaa-hbh8-m.txt 491 In order to measure FH512 with the list of webservers: 493 # cat top-1m-dns-aaaa-unique.txt | script6 trace6 fH512 tcp 53 > top- 494 1m-dns-aaaa-fh512-m.txt 496 A.5. Obtaining Statistics from our Measurements 498 A.5.1. Statistics for Web Servers 500 In order to compute the statistics corresponding to our measurements 501 of DO8 with the list of webservers: 503 $ cat top-1m-web-aaaa-do8-m.txt | script6 get-trace6-stats > top-1m- 504 web-aaaa-do8-stats.txt 506 In order to compute the statistics corresponding to our measurements 507 of HBH8 with the list of webservers: 509 $ cat top-1m-web-aaaa-hbh8-m.txt | script6 get-trace6-stats > top-1m- 510 web-aaaa-hbh8-stats.txt 512 In order to compute the statistics corresponding to our measurements 513 of FH512 with the list of webservers: 515 $ cat top-1m-web-aaaa-fh512-m.txt | script6 get-trace6-stats > top- 516 1m-web-aaaa-fh512-stats.txt 518 A.5.2. Statistics for Mail Servers 520 In order to compute the statistics corresponding to our measurements 521 of DO8 with the list of mailservers: 523 $ cat top-1m-mail-aaaa-do8-m.txt | script6 get-trace6-stats > top-1m- 524 mail-aaaa-do8-stats.txt 526 In order to compute the statistics corresponding to our measurements 527 of HBH8 with the list of mailservers: 529 $ cat top-1m-mail-aaaa-hbh8-m.txt | script6 get-trace6-stats > top- 530 1m-mail-aaaa-hbh8-stats.txt 532 In order to compute the statistics corresponding to our measurements 533 of FH512 with the list of mailservers: 535 $ cat top-1m-mail-aaaa-fh512-m.txt | script6 get-trace6-stats > top- 536 1m-mail-aaaa-fh512-stats.txt 538 A.5.3. Statistics for Name Servers 540 In order to compute the statistics corresponding to our measurements 541 of DO8 with the list of nameservers: 543 $ cat top-1m-dns-aaaa-do8-m.txt | script6 get-trace6-stats > top-1m- 544 dns-aaaa-do8-stats.txt 546 In order to compute the statistics corresponding to our measurements 547 of HBH8 with the list of mailservers: 549 $ cat top-1m-dns-aaaa-hbh8-m.txt | script6 get-trace6-stats > top-1m- 550 dns-aaaa-hbh8-stats.txt 552 In order to compute the statistics corresponding to our measurements 553 of FH512 with the list of mailservers: 555 $ cat top-1m-dns-aaaa-fh512-m.txt | script6 get-trace6-stats > top- 556 1m-dns-aaaa-fh512-stats.txt 558 Appendix B. Measurements Caveats 560 A number of issues have needed some consideration when producing the 561 results presented in this document. These same issues should be 562 considered when troubleshooting connectivity problems resulting from 563 the use of IPv6 Extension headers. 565 B.1. Isolating the Dropping Node 567 Let us assume that we find that IPv6 packets with EHs are being 568 dropped on their way to the destination system 2001:db8:d::1, and 569 that the output of running traceroute towards such destination is: 571 1. 2001:db8:1:1000::1 572 2. 2001:db8:2:4000::1 573 3. 2001:db8:3:4000::1 574 4. 2001:db8:3:1000::1 575 5. 2001:db8:4:4000::1 576 6. 2001:db8:4:1000::1 577 7. 2001:db8:5:5000::1 578 8. 2001:db8:5:6000::1 579 9. 2001:db8:d::1 581 Additionally, let us assume that the output of EH-enabled traceroute 582 to the same destination is: 584 1. 2001:db8:1:1000::1 585 2. 2001:db8:2:4000::1 586 3. 2001:db8:3:4000::1 587 4. 2001:db8:3:1000::1 588 5. 2001:db8:4:4000::1 590 For the sake of brevity, let us refer to the last-responding node in 591 the EH-enabled traceroute ("2001:db8:4:4000::1" in this case) as "M". 592 Assuming both packets in both traceroutes employ the same path, we'll 593 refer to "the node following the last responding node in the EH- 594 enabled traceroute" ("2001:db8:4:1000::1" in our case), as "M+1", 595 etc. 597 Based on traceroute information above, which node is the one actually 598 dropping the EH-enabled packets will depend on whether the dropping 599 node filters packets before making the forwarding decision, or after 600 making the forwarding decision. If the former, the dropping node 601 will be M+1. If the latter, the dropping node will be "M". 603 Throughout this document (and our measurements), we assume that those 604 nodes filtering packets that carry IPv6 EHs apply their filtering 605 policy, and only then, if necessary, forward the packets. Thus, in 606 our example above the last responding node to the EH-enabled 607 traceroute ("M") is "2001:db8:4:4000::1", and therefore we assume the 608 dropping node to be "2001:db8:4:1000::1" ("M+1"). 610 Additionally, we note that when isolating the dropping node we assume 611 that both the EH-enabled and the EH-free traceroutes result in the 612 same paths. However, this might not be the case. 614 B.2. Obtaining the Responsible Organization for the Packet Drops 616 In order to identify the organization operating the dropping node, 617 one would be tempted to lookup the ASN corresponding to the dropping 618 node. However, assuming that M and M+1 are two peering routers, any 619 of these two organizations could be providing the address space 620 employed for such peering. Or, in the case of an Internet eXchange 621 Point (IXP), the address space could correspond to the IXP AS, rather 622 than to any of the participating ASes. Thus, the organization 623 operating the dropping node (M+1) could be the AS for M+1, but it 624 might as well be the AS for M+2. Only when the ASN for M+1 is the 625 same as the ASN for M+2 we have certainty about who the responsible 626 organization for the packet drops is (see slides 21-23 of 627 [Linkova-Gont-IEPG90]). 629 In the measurement results presented in Section 2, the aforementioned 630 ambiguity results in "percentage ranges" (rather than a specific 631 ratio): the lowest percentage value means that, when in doubt, we 632 assume the packet drops occur in the same AS as the destination; on 633 the other hand, the highest percentage value means that, when in 634 doubt, we assume the packet drops occur at different AS than the 635 destination AS. 637 We note that the aforementioned ambiguity should also be considered 638 when troubleshooting and reporting IPv6 packet drops, since 639 identifying the organization responsible for the packet drops might 640 probe to be a non-trivial task. 642 Finally, we note that a specific organization might be operating more 643 than one Autonomous System. However, our measurements assume that 644 different Autonomous System Numbers imply different organizations. 646 Appendix C. Troubleshooting Packet Drops due to IPv6 Extension Headers 648 Isolating IPv6 blackholes essentially involves performing IPv6 649 traceroute for a destination system with and without IPv6 extension 650 headers. The (EH-free) traceroute would provide the full working 651 path towards a destination, while the EH-enabled traceroute would 652 provide the address of the last-responding node for EH-enabled 653 packets (say, "M"). In principle, one could isolate the dropping 654 node by looking-up "M" in the EH-free traceroute, with the dropping 655 node being "M+1" (see Appendix B.1 for caveats). 657 At the time of this writing, most traceroute implementations do not 658 support IPv6 extension headers. However, the path6 tool [path6] of 659 [IPv6-Toolkit] provides such support. Additionally, the blackhole6 660 tool [blackhole6] automates the troubleshooting process and can 661 readily provide information such as: dropping node's IPv6 address, 662 dropping node's Autonomous System, etc. 664 Authors' Addresses 666 Fernando Gont 667 SI6 Networks / UTN-FRH 668 Evaristo Carriego 2644 669 Haedo, Provincia de Buenos Aires 1706 670 Argentina 672 Phone: +54 11 4650 8472 673 Email: fgont@si6networks.com 674 URI: http://www.si6networks.com 676 J. Linkova 677 Google 678 1600 Amphitheatre Parkway 679 Mountain View, CA 94043 680 USA 682 Email: furry@google.com 684 Tim Chown 685 University of Southampton 686 Highfield 687 Southampton , Hampshire SO17 1BJ 688 United Kingdom 690 Email: tjc@ecs.soton.ac.uk 692 Will(Shucheng) Liu 693 Huawei Technologies 694 Bantian, Longgang District 695 Shenzhen 518129 696 P.R. China 698 Email: liushucheng@huawei.com