idnits 2.17.1 draft-ietf-v6ops-ipv6-ehs-in-real-world-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 21, 2015) is 3291 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 317, but no explicit reference was found in the text == Unused Reference: 'RFC4443' is defined on line 323, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 327, but no explicit reference was found in the text == Unused Reference: 'RFC6145' is defined on line 331, but no explicit reference was found in the text == Unused Reference: 'RFC6946' is defined on line 334, but no explicit reference was found in the text == Unused Reference: 'RFC5927' is defined on line 373, but no explicit reference was found in the text == Unused Reference: 'RFC6980' is defined on line 375, but no explicit reference was found in the text == Unused Reference: 'RFC7045' is defined on line 378, but no explicit reference was found in the text == Unused Reference: 'RFC7113' is defined on line 381, but no explicit reference was found in the text == Unused Reference: 'RFC7123' is defined on line 384, 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: October 23, 2015 Google 6 T. Chown 7 University of Southampton 8 W. Liu 9 Huawei Technologies 10 April 21, 2015 12 Observations on IPv6 EH Filtering in the Real World 13 draft-ietf-v6ops-ipv6-ehs-in-real-world-00 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 October 23, 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 . . . . . . . . . . . . . . . . . . . . . 7 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . 10 72 A.3. Filtering the IPv6 Address Datasets . . . . . . . . . . . 10 73 A.4. Performing Measurements with Each IPv6 Address Dataset . 11 74 A.5. Obtaining Statistics from our Measurements . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . . 15 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 packets containing IPv6 Extension Headers are filtered in the 96 Internet, as measured in August 2014 (pending operational advice in 97 this area). The results presented in this document indicate that in 98 the scenarios where the corresponding measurements were performed, 99 the use of IPv6 extension headers can lead to packet drops. We note 100 that, in particular, packet drops occurring at transit networks are 101 undesirable, and it is hoped and expected that this situation will 102 improve over time. 104 2. Support of IPv6 Extension Headers in the Internet 106 This section summarizes the results obtained when measuring the 107 support of IPv6 Extension Headers on the path towards different types 108 of public IPv6 servers. Two sources of information were employed for 109 the list of public IPv6 servers: the "World IPv6 Launch Day" site 110 (http://www.worldipv6launch.org/) and Alexa's top 1M web sites 111 (http://www.alexa.com). For each list of domain names, the following 112 datasets were obtained: 114 o Web servers (AAAA records of the aforementioned list) 116 o Mail servers (MX -> AAAA of the aforementioned list) 118 o Name servers (NS -> AAAA of the aforementioned list) 120 Duplicate addresses and IPv6 addresses other than global unicast 121 addresses were eliminated from each of those lists prior to obtaining 122 the results included in this document. Additionally, addresses that 123 were found to be unreachable were discarded from the dataset (please 124 see Appendix B for further details). 126 For each of the aforementioned address sets, three different types of 127 probes were employed: 129 o IPv6 packets with a Destination Options header of 8 bytes 131 o IPv6 packets resulting in two IPv6 fragments of 512 bytes each 132 (approximately) 134 o IPv6 packets with a Hop-by-Hop Options header of 8 bytes 136 In the case of packets with a Destination Options Header and the case 137 of packets with a Hop-by-Hop Options header, the desired EH size was 138 achieved by means of PadN options [RFC2460]. The upper-layer 139 protocol of the probe packets was, in all cases, TCP [RFC0793] 140 segments with the Destination Port set to the service port 141 [IANA-PORT-NUMBERS] of the corresponding dataset. For example, the 142 probe packets for all the measurements involving web servers were TCP 143 segments with the destination port set to 80. 145 Besides obtaining the packet drop rate when employing the 146 aforementioned IPv6 extension headers, we tried to identify whether 147 the Autonomous System (AS) dropping the packets was the same as the 148 Autonomous System of the destination/target address. This is of 149 particular interest since it essentially reveals whether the packet 150 drops are under the control of the intended destination of the 151 packets. Packets dropped by the destination AS are less of a 152 concern, since the device dropping the packets is under the control 153 of the same organization as that to which the packets are destined 154 (hence, it is probably easier to update the filtering policy if 155 deemed necessary). On the other hand, packets dropped by transit 156 ASes are more of a concern, since they affect the deployability and 157 usability of IPv6 extension headers (including IPv6 fragmentation) by 158 a third-party (the destination AS). In any case, we note that it is 159 impossible to tell whether, in those cases where IPv6 packets with 160 extension headers get dropped, the packet drops are the result of an 161 explicit and intended policy, or the result of improper device 162 configuration defaults, buggy devices, etc. Thus, packet drops that 163 occur at the destination AS might still prove to be problematic. 165 Since there is some ambiguity when identifying the autonomous system 166 to which a specific router belongs (see Appendix B.2), each of our 167 measurements results in two different values: one corresponding to 168 the "best-case scenario", and one corresponding to the "worst-case 169 scenario". The "best-case scenario" is that in which, when in doubt, 170 the packets are assumed to be dropped by the destination AS, whereas 171 the "worst-case scenario" is that in which, when in doubt, the 172 packets are assumed to be dropped by a transit AS (please see 173 Appendix B.2 for details). In the following tables, the values shown 174 within parentheses represent the possibility that, when a packet is 175 dropped, the packet drop occurs in an AS other than the destination 176 AS (considering both the best-case scenario and the worst-case 177 scenario). 179 +-------------+-----------------+-----------------+-----------------+ 180 | Dataset | DO8 | HBH8 | FH512 | 181 +-------------+-----------------+-----------------+-----------------+ 182 | Webservers | 11.88% | 40.70% | 30.51% | 183 | | (17.60%/20.80%) | (31.43%/40.00%) | (5.08%/6.78%) | 184 +-------------+-----------------+-----------------+-----------------+ 185 | Mailservers | 17.07% | 48.86% | 39.17% | 186 | | (6.35%/26.98%) | (40.50%/65.42%) | (2.91%/12.73%) | 187 +-------------+-----------------+-----------------+-----------------+ 188 | Nameservers | 15.37% | 43.25% | 38.55% | 189 | | (14.29%/33.46%) | (42.49%/72.07%) | (3.90%/13.96%) | 190 +-------------+-----------------+-----------------+-----------------+ 192 Table 1: WIPv6LD dataset: Packet drop rate for different destination 193 types, and estimated percentage of dropped packets that were deemed 194 to be dropped in a different AS (lower, in parentheses) 196 NOTE: As an example, we note that the cell describing the support 197 of IPv6 packets with DO8 for webservers (containing the value 198 "11.88% (17.60%/20.80%)") should be read as: "when sending IPv6 199 packets with DO8 to public webservers, 11.88% of such packets get 200 dropped. Among those packets that get dropped, 17.60%/20.80% 201 (best case / worst case) of them get dropped at an AS other than 202 the destination AS". 204 +--------+------------------+-------------------+-------------------+ 205 | EH | Webservers | Mailservers | Nameservers | 206 | Type | | | | 207 +--------+------------------+-------------------+-------------------+ 208 | DO8 | 11.88% | 17.07% | 15.37% | 209 | | (17.60%/20.80%) | (6.35%/26.98%) | (14.29%/33.46%) | 210 +--------+------------------+-------------------+-------------------+ 211 | HBH8 | 40.70% | 48.86% | 43.25% | 212 | | (31.43%/40.00%) | (40.50%/65.42%) | (42.49%/72.07%) | 213 +--------+------------------+-------------------+-------------------+ 214 | FH512 | 30.51% | 39.17% | 38.55% | 215 | | (5.08%/6.78%) | (2.91%/12.73%) | (3.90%/13.96%) | 216 +--------+------------------+-------------------+-------------------+ 218 Table 2: WIPv6LD dataset: Packet drop rate for different EH types, 219 and estimated percentage of dropped packets that were deemed to be 220 dropped in a different AS (lower, in parentheses) 222 NOTE: This table contains the same information as Table 1, but 223 makes it easier to obtain the drop rates for each EH type. Each 224 cell should be read in exactly the same way as each cell in 225 Table 1. 227 +-------------+-----------------+-----------------+-----------------+ 228 | Dataset | DO8 | HBH8 | FH512 | 229 +-------------+-----------------+-----------------+-----------------+ 230 | Webservers | 10.91% | 39.03% | 28.26% | 231 | | (46.52%/53.23%) | (36.90%/46.35%) | (53.64%/61.43%) | 232 +-------------+-----------------+-----------------+-----------------+ 233 | Mailservers | 11.54% | 45.45% | 35.68% | 234 | | (2.41%/21.08%) | (41.27%/61.13%) | (3.15%/10.92%) | 235 +-------------+-----------------+-----------------+-----------------+ 236 | Nameservers | 21.33% | 54.12% | 55.23% | 237 | | (10.27%/56.80%) | (50.64%/81.00%) | (5.66%/32.23%) | 238 +-------------+-----------------+-----------------+-----------------+ 240 Table 3: Alexa's top 1M sites dataset: Packet drop rate for different 241 destination types, and estimated percentage of dropped packets that 242 were deemed to be dropped in a different AS (lower, in parentheses) 244 +--------+------------------+-------------------+-------------------+ 245 | EH | Webservers | Mailservers | Nameservers | 246 | Type | | | | 247 +--------+------------------+-------------------+-------------------+ 248 | DO8 | 10.91% | 11.54% | 21.33% | 249 | | (46.52%/53.23%) | (2.41%/21.08%) | (10.27%/56.80%) | 250 +--------+------------------+-------------------+-------------------+ 251 | HBH8 | 39.03% | 45.45% | 54.12% | 252 | | (36.90%/46.35%) | (41.27%/61.13%) | (50.64%/81.00%) | 253 +--------+------------------+-------------------+-------------------+ 254 | FH512 | 28.26% | 35.68% | 55.23% | 255 | | (53.64%/61.43%) | (3.15%/10.92%) | (5.66%/32.23%) | 256 +--------+------------------+-------------------+-------------------+ 258 Table 4: Alexa's top 1M sites dataset: Packet drop rate for different 259 EH types, and estimated percentage of dropped packets that were 260 deemed to be dropped in a different AS (lower, in parentheses) 262 NOTE: This table contains the same information as Table 3, but 263 makes it easier to obtain the drop rates for each EH type. Each 264 cell should be read in exactly the same way as each cell in 265 Table 3. 267 There are a number of observations to be made based on the results 268 presented above. Firstly, while it has been generally assumed that 269 it is IPv6 fragments that are dropped by operators, our results 270 indicate that it is IPv6 extension headers in general that result in 271 packet drops. Secondly, our results indicate that a significant 272 percentage of such packet drops occurs in transit Autonomous Systems; 273 that is, the packet drops are not under the control of the same 274 organization as the final destination. 276 3. IANA Considerations 278 There are no IANA registries within this document. The RFC-Editor 279 can remove this section before publication of this document as an 280 RFC. 282 4. Security Considerations 284 This document presents real-world data regarding the extent to which 285 IPv6 packets employing extension headers are filtered in the 286 Internet. As such, this document does not introduce any new security 287 issues. 289 5. Acknowledgements 291 The authors would like to thank (in alphabetical order) Mikael 292 Abrahamsson, Mark Andrews, Fred Baker, Brian Carpenter, Gert Doering, 293 C. M. Heard, Nick Hilliard, Joel Jaeggli, Tatuya Jinmei, Merike 294 Kaeo, Warren Kumari, Mark Smith, Ole Troan, and Eric Vyncke, for 295 providing valuable comments on earlier versions of this document. 296 Additionally, the authors would like to thank participants of the 297 v6ops and opsec working groups for their valuable input on the topics 298 discussed in this document. 300 The authors would like to thank Fred Baker for his guidance in 301 improving this document. 303 Fernando Gont would like to thank Jan Zorz / Go6 Lab 304 , and Jared Mauch / NTT America, for providing 305 access to systems and networks that were employed to produce some of 306 the measurement results presented in this document. Additionally, he 307 would like to thank SixXS for providing IPv6 308 connectivity. 310 6. References 312 6.1. Normative References 314 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 315 793, September 1981. 317 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 318 STD 13, RFC 1034, November 1987. 320 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 321 (IPv6) Specification", RFC 2460, December 1998. 323 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 324 Message Protocol (ICMPv6) for the Internet Protocol 325 Version 6 (IPv6) Specification", RFC 4443, March 2006. 327 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 328 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 329 September 2007. 331 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 332 Algorithm", RFC 6145, April 2011. 334 [RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC 335 6946, May 2013. 337 6.2. Informative References 339 [Gont-Chown-IEPG89] 340 Gont, F. and T. Chown, "A Small Update on the Use of IPv6 341 Extension Headers", IEPG 89. London, UK. March 2, 2014, 342 . 345 [Gont-IEPG88] 346 Gont, F., "Fragmentation and Extension header Support in 347 the IPv6 Internet", IEPG 88. Vancouver, BC, Canada. 348 November 13, 2013, . 351 [IANA-PORT-NUMBERS] 352 IANA, "Service Name and Transport Protocol Port Number 353 Registry", . 357 [IPv6-Toolkit] 358 "SI6 Networks' IPv6 Toolkit", 359 . 361 [Linkova-Gont-IEPG90] 362 Linkova, J. and F. Gont, "IPv6 Extension Headers in the 363 Real World v2.0", IEPG 90. Toronto, ON, Canada. July 20, 364 2014, . 367 [PMTUD-Blackholes] 368 De Boer, M. and J. Bosma, "Discovering Path MTU black 369 holes on the Internet using RIPE Atlas", July 2012, 370 . 373 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010. 375 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 376 with IPv6 Neighbor Discovery", RFC 6980, August 2013. 378 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 379 of IPv6 Extension Headers", RFC 7045, December 2013. 381 [RFC7113] Gont, F., "Implementation Advice for IPv6 Router 382 Advertisement Guard (RA-Guard)", RFC 7113, February 2014. 384 [RFC7123] Gont, F. and W. Liu, "Security Implications of IPv6 on 385 IPv4 Networks", RFC 7123, February 2014. 387 [blackhole6] 388 blackhole6, , "blackhole6 tool manual page", 389 , 2014. 391 [path6] path6, , "path6 tool manual page", 392 , 2014. 394 Appendix A. Reproducing Our Experiment 396 This section describes, step by step, how to reproduce the experiment 397 with which we obtained the results presented in this document. Each 398 subsection represents one step in the experiment. The tools employed 399 for the experiment are traditional UNIX-like tools (such as gunzip), 400 and the SI6 Networks' IPv6 Toolkit [IPv6-Toolkit]. 402 A.1. Obtaining the List of Domain Names 404 The primary data source employed was Alexa's Top 1M web sites, 405 available at: . 406 The file is a zipped file containing the list of the most popular web 407 sites, in CSV format. The aforementioned file can be extracted with 408 "gunzip < top-1m.csv.zip > top-1m.csv". 410 A list of domain names (i.e., other data stripped) can be obtained 411 with the following command of [IPv6-Toolkit]: "cat top-1m.csv | 412 script6 get-alexa-domains > top-1m.txt". This command will create a 413 "top-1m.txt" file, containing one domain name per line. 415 NOTE: The domain names corresponding to the WIPv6LD dataset is 416 available at: . Since the corresponding file is a text file 418 containing one domain name per line, the steps produced in this 419 subsection need not be performed. The WIPv6LD data set should be 420 processed in the same way as the Alexa Dataset, starting from 421 Appendix A.2. 423 A.2. Obtaining AAAA Resource Records 425 The file obtained in the previous subsection contains a list of 426 domain names that correspond to web sites. The AAAA records for such 427 domain names can be obtained with: 429 $ cat top-1m.txt | script6 get-aaaa > top-1m-web-aaaa.txt 431 The AAAA records corresponding to the mailservers of each of the 432 aforementioned domain names can be obtained with: 434 $ cat top-1m.txt | script6 get-mx | script6 get-aaaa > top-1m-mail- 435 aaaa.txt 437 The AAAA records corresponding to the nameservers of each of the 438 aforementioned domain names can be obtained with: 440 $ cat top-1m.txt | script6 get-ns | script6 get-aaaa > top-1m-dns- 441 aaaa.txt 443 A.3. Filtering the IPv6 Address Datasets 445 The lists of IPv6 addresses obtained in the previous step could 446 possibly contain undesired addresses (i.e., non-global unicast 447 addresses) and/or duplicate addresses. In order to remove both 448 undesired and duplicate addresses, each of the three files from the 449 previous section should be filtered accordingly: 451 $ cat top-1m-web-aaaa.txt | addr6 -i -q -B multicast -B unspec -k 452 global > top-1m-web-aaaa-unique.txt 454 $ cat top-1m-mail-aaaa.txt | addr6 -i -q -B multicast -B unspec -k 455 global > top-1m-mail-aaaa-unique.txt 457 $ cat top-1m-dns-aaaa.txt | addr6 -i -q -B multicast -B unspec -k 458 global > top-1m-dns-aaaa-unique.txt 460 A.4. Performing Measurements with Each IPv6 Address Dataset 462 A.4.1. Measurements with web servers 464 In order to measure DO8 with the list of webservers: 466 # cat top-1m-web-aaaa-unique.txt | script6 trace6 do8 tcp 80 > top- 467 1m-web-aaaa-do8-m.txt 469 In order to measure HBH8 with the list of webservers: 471 # cat top-1m-web-aaaa-unique.txt | script6 trace6 hbh8 tcp 80 > top- 472 1m-web-aaaa-hbh8-m.txt 474 In order to measure FH512 with the list of webservers: 476 # cat top-1m-web-aaaa-unique.txt | script6 trace6 fh512 tcp 80 > top- 477 1m-web-aaaa-fh512-m.txt 479 A.4.2. Measurements with mail servers 481 In order to measure DO8 with the list of mailservers: 483 # cat top-1m-mail-aaaa-unique.txt | script6 trace6 do8 tcp 25 > top- 484 1m-mail-aaaa-do8-m.txt 486 In order to measure HBH8 with the list of webservers: 488 # cat top-1m-mail-aaaa-unique.txt | script6 trace6 hbh8 tcp 25 > top- 489 1m-mail-aaaa-hbh8-m.txt 491 In order to measure FH512 with the list of webservers: 493 # cat top-1m-mail-aaaa-unique.txt | script6 trace6 fh512 tcp 25 > 494 top-1m-mail-aaaa-fh512-m.txt 496 A.4.3. Measurements with DNS servers 498 In order to measure DO8 with the list of mameservers: 500 # cat top-1m-dns-aaaa-unique.txt | script6 trace6 do8 tcp 53 > top- 501 1m-dns-aaaa-do8-m.txt 503 In order to measure HBH8 with the list of webservers: 505 # cat top-1m-dns-aaaa-unique.txt | script6 trace6 hbh8 tcp 53 > top- 506 1m-dns-aaaa-hbh8-m.txt 507 In order to measure FH512 with the list of webservers: 509 # cat top-1m-dns-aaaa-unique.txt | script6 trace6 fh512 tcp 53 > top- 510 1m-dns-aaaa-fh512-m.txt 512 A.5. Obtaining Statistics from our Measurements 514 A.5.1. Statistics for Web Servers 516 In order to compute the statistics corresponding to our measurements 517 of DO8 with the list of webservers: 519 $ cat top-1m-web-aaaa-do8-m.txt | script6 get-trace6-stats > top-1m- 520 web-aaaa-do8-stats.txt 522 In order to compute the statistics corresponding to our measurements 523 of HBH8 with the list of webservers: 525 $ cat top-1m-web-aaaa-hbh8-m.txt | script6 get-trace6-stats > top-1m- 526 web-aaaa-hbh8-stats.txt 528 In order to compute the statistics corresponding to our measurements 529 of FH512 with the list of webservers: 531 $ cat top-1m-web-aaaa-fh512-m.txt | script6 get-trace6-stats > top- 532 1m-web-aaaa-fh512-stats.txt 534 A.5.2. Statistics for Mail Servers 536 In order to compute the statistics corresponding to our measurements 537 of DO8 with the list of mailservers: 539 $ cat top-1m-mail-aaaa-do8-m.txt | script6 get-trace6-stats > top-1m- 540 mail-aaaa-do8-stats.txt 542 In order to compute the statistics corresponding to our measurements 543 of HBH8 with the list of mailservers: 545 $ cat top-1m-mail-aaaa-hbh8-m.txt | script6 get-trace6-stats > top- 546 1m-mail-aaaa-hbh8-stats.txt 548 In order to compute the statistics corresponding to our measurements 549 of FH512 with the list of mailservers: 551 $ cat top-1m-mail-aaaa-fh512-m.txt | script6 get-trace6-stats > top- 552 1m-mail-aaaa-fh512-stats.txt 554 A.5.3. Statistics for Name Servers 556 In order to compute the statistics corresponding to our measurements 557 of DO8 with the list of nameservers: 559 $ cat top-1m-dns-aaaa-do8-m.txt | script6 get-trace6-stats > top-1m- 560 dns-aaaa-do8-stats.txt 562 In order to compute the statistics corresponding to our measurements 563 of HBH8 with the list of mailservers: 565 $ cat top-1m-dns-aaaa-hbh8-m.txt | script6 get-trace6-stats > top-1m- 566 dns-aaaa-hbh8-stats.txt 568 In order to compute the statistics corresponding to our measurements 569 of FH512 with the list of mailservers: 571 $ cat top-1m-dns-aaaa-fh512-m.txt | script6 get-trace6-stats > top- 572 1m-dns-aaaa-fh512-stats.txt 574 Appendix B. Measurements Caveats 576 A number of issues have needed some consideration when producing the 577 results presented in this document. These same issues should be 578 considered when troubleshooting connectivity problems resulting from 579 the use of IPv6 Extension headers. 581 B.1. Isolating the Dropping Node 583 Let us assume that we find that IPv6 packets with EHs are being 584 dropped on their way to the destination system 2001:db8:d::1, and 585 that the output of running traceroute towards such destination is: 587 1. 2001:db8:1:1000::1 588 2. 2001:db8:2:4000::1 589 3. 2001:db8:3:4000::1 590 4. 2001:db8:3:1000::1 591 5. 2001:db8:4:4000::1 592 6. 2001:db8:4:1000::1 593 7. 2001:db8:5:5000::1 594 8. 2001:db8:5:6000::1 595 9. 2001:db8:d::1 597 Additionally, let us assume that the output of EH-enabled traceroute 598 to the same destination is: 600 1. 2001:db8:1:1000::1 601 2. 2001:db8:2:4000::1 602 3. 2001:db8:3:4000::1 603 4. 2001:db8:3:1000::1 604 5. 2001:db8:4:4000::1 606 For the sake of brevity, let us refer to the last-responding node in 607 the EH-enabled traceroute ("2001:db8:4:4000::1" in this case) as "M". 608 Assuming that packets in both traceroutes employ the same path, we'll 609 refer to "the node following the last responding node in the EH- 610 enabled traceroute" ("2001:db8:4:1000::1" in our case), as "M+1", 611 etc. 613 Based on traceroute information above, which node is the one actually 614 dropping the EH-enabled packets will depend on whether the dropping 615 node filters packets before making the forwarding decision, or after 616 making the forwarding decision. If the former, the dropping node 617 will be M+1. If the latter, the dropping node will be "M". 619 Throughout this document (and our measurements), we assume that those 620 nodes filtering packets that carry IPv6 EHs apply their filtering 621 policy, and only then, if necessary, forward the packets. Thus, in 622 our example above the last responding node to the EH-enabled 623 traceroute ("M") is "2001:db8:4:4000::1", and therefore we assume the 624 dropping node to be "2001:db8:4:1000::1" ("M+1"). 626 Additionally, we note that when isolating the dropping node we assume 627 that both the EH-enabled and the EH-free traceroutes result in the 628 same paths. However, this might not be the case. 630 B.2. Obtaining the Responsible Organization for the Packet Drops 632 In order to identify the organization operating the dropping node, 633 one would be tempted to lookup the ASN corresponding to the dropping 634 node. However, assuming that M and M+1 are two peering routers, any 635 of these two organizations could be providing the address space 636 employed for such peering. Or, in the case of an Internet eXchange 637 Point (IXP), the address space could correspond to the IXP AS, rather 638 than to any of the participating ASes. Thus, the organization 639 operating the dropping node (M+1) could be the AS for M+1, but it 640 might as well be the AS for M+2. Only when the ASN for M+1 is the 641 same as the ASN for M+2 we have certainty about who the responsible 642 organization for the packet drops is (see slides 21-23 of 643 [Linkova-Gont-IEPG90]). 645 In the measurement results presented in Section 2, the aforementioned 646 ambiguity results in a "best-case" and a "worst-case" scenario 647 (rather than a single value): the lowest percentage value means that, 648 when in doubt, we assume the packet drops occur in the same AS as the 649 destination; on the other hand, the highest percentage value means 650 that, when in doubt, we assume the packet drops occur at different AS 651 than the destination AS. 653 We note that the aforementioned ambiguity should also be considered 654 when troubleshooting and reporting IPv6 packet drops, since 655 identifying the organization responsible for the packet drops might 656 probe to be a non-trivial task. 658 Finally, we note that a specific organization might be operating more 659 than one Autonomous System. However, our measurements assume that 660 different Autonomous System Numbers imply different organizations. 662 Appendix C. Troubleshooting Packet Drops due to IPv6 Extension Headers 664 Isolating IPv6 blackholes essentially involves performing IPv6 665 traceroute for a destination system with and without IPv6 extension 666 headers. The EH-free traceroute would provide the full working path 667 towards a destination, while the EH-enabled traceroute would provide 668 the address of the last-responding node for EH-enabled packets (say, 669 "M"). In principle, one could isolate the dropping node by looking- 670 up "M" in the EH-free traceroute, with the dropping node being "M+1" 671 (see Appendix B.1 for caveats). 673 At the time of this writing, most traceroute implementations do not 674 support IPv6 extension headers. However, the path6 tool [path6] of 675 [IPv6-Toolkit] provides such support. Additionally, the blackhole6 676 tool [blackhole6] of [IPv6-Toolkit] automates the troubleshooting 677 process and can readily provide information such as: dropping node's 678 IPv6 address, dropping node's Autonomous System, etc. 680 Authors' Addresses 682 Fernando Gont 683 SI6 Networks / UTN-FRH 684 Evaristo Carriego 2644 685 Haedo, Provincia de Buenos Aires 1706 686 Argentina 688 Phone: +54 11 4650 8472 689 Email: fgont@si6networks.com 690 URI: http://www.si6networks.com 691 J. Linkova 692 Google 693 1600 Amphitheatre Parkway 694 Mountain View, CA 94043 695 USA 697 Email: furry@google.com 699 Tim Chown 700 University of Southampton 701 Highfield 702 Southampton , Hampshire SO17 1BJ 703 United Kingdom 705 Email: tjc@ecs.soton.ac.uk 707 Will(Shucheng) Liu 708 Huawei Technologies 709 Bantian, Longgang District 710 Shenzhen 518129 711 P.R. China 713 Email: liushucheng@huawei.com