idnits 2.17.1
draft-gont-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 (August 7, 2014) is 3522 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293)
** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200)
== Outdated reference: A later version (-10) exists of
draft-ietf-6man-predictable-fragment-id-01
== Outdated reference: A later version (-03) exists of
draft-wkumari-long-headers-02
Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--).
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: February 8, 2015 Google
6 T. Chown
7 University of Southampton
8 W. Liu
9 Huawei Technologies
10 August 7, 2014
12 IPv6 Extension Headers in the Real World
13 draft-gont-v6ops-ipv6-ehs-in-real-world-00
15 Abstract
17 IPv6 Extension Headers allow for the extension of the IPv6 protocol,
18 and provide support for some core functionality such as IPv6
19 fragmentation. However, IPv6 Extension Headers are deemed to present
20 a challenge to IPv6 implementations and networks, and are known to be
21 intentionally filtered in some existing IPv6 deployments. This
22 summarizes the issues associated with IPv6 extension headers, and
23 presents real-world data regarding the extent to which packets with
24 IPv6 extension headers are filtered in the public Internet, and where
25 in the network such filtering occurs. Additionally, it provides some
26 guidance to operators in troubleshooting IPv6 blackholes resulting
27 from the use of IPv6 extension headers. Finally, this document
28 provides some advice to protocol designers, and discusses areas where
29 further work might be needed.
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 February 8, 2015.
48 Copyright Notice
50 Copyright (c) 2014 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. Previous Work on IPv6 Extension Headers . . . . . . . . . . . 3
67 3. Operational Implications . . . . . . . . . . . . . . . . . . 4
68 3.1. Performance Issues . . . . . . . . . . . . . . . . . . . 4
69 3.2. Security Implications . . . . . . . . . . . . . . . . . . 4
70 4. Support of IPv6 Extension Headers in the Public Internet . . 5
71 5. Implications of Widespread IPv6 Extension Header Filtering . 7
72 5.1. Advice to Protocol Designers . . . . . . . . . . . . . . 8
73 5.2. A possible attack vector . . . . . . . . . . . . . . . . 8
74 5.3. Possible Future Work . . . . . . . . . . . . . . . . . . 8
75 6. Troubleshooting Packet Drops due to IPv6 Extension Headers . 9
76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
80 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
81 10.2. Informative References . . . . . . . . . . . . . . . . . 10
82 Appendix A. Measurements Caveats . . . . . . . . . . . . . . . . 12
83 A.1. Isolating the Dropping Node . . . . . . . . . . . . . . . 12
84 A.2. Obtaining the Responsible Organization for the Packet
85 Drops . . . . . . . . . . . . . . . . . . . . . . . . . . 13
86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
88 1. Introduction
90 IPv6 Extension Headers (EHs) allow for the extension of the IPv6
91 protocol, and provide support for core functionality such as IPv6
92 fragmentation. However, IPv6 Extension Headers have been deemed to
93 present a challenge to IPv6 implementations and networks, and have
94 been assumed/known to be intentionally filtered in some existing IPv6
95 deployments.
97 Discussions over the operational implications of IPv6 extension
98 headers and their usability in the public Internet come up over and
99 over again at both in IETF circles and other venues, and not
100 infrequently some key aspects involving IPv6 extension headers are
101 overlooked.
103 This document tries raise awareness about the operational
104 implications of IPv6 Extension Headers, and their usability in the
105 public Internet. Additionally, it provides some guidance in
106 troubleshooting IPv6 blackholes resulting from the filtering of
107 packets that employ IPv6 extension headers. Finally, it aims to
108 raise awareness about the operational reality of IPv6 extension
109 headers to protocol designers, and trigger discussion within the IETF
110 community regarding areas where future work might be required.
112 Section 2 of this document summarizes the work that has been done in
113 the area of IPv6 extension headers. Section 3 discusses the
114 operational implications of IPv6 Extension Headers. Section 4
115 presents real-world data regarding the extent to which IPv6 Extension
116 Headers are usable in the public Internet. Section 5 provides advise
117 to protocol designers regarding the use of IPv6 extension headers,
118 and aims to raise awareness about the possible interoperability
119 implications on existing protocols. Finally, Section 6 provides some
120 guidance in troubleshooting of problems that may arise as a result of
121 filtering packets that employ IPv6 Extension Headers.
123 2. Previous Work on IPv6 Extension Headers
125 Some of the implications of IPv6 Extension Headers have been
126 discussed in IETF circles. For example, [I-D.taylor-v6ops-fragdrop]
127 discusses a rationale for which operators filter IPv6 fragments.
128 [I-D.wkumari-long-headers] discusses possible issues arising from
129 "long" IPv6 header chains. [RFC7045] clarifies how intermediate
130 nodes should deal with IPv6 extension headers. [RFC7112] discusses
131 the issues arising in a specific case where the IPv6 header chain is
132 fragmented into two or more fragments (and formally forbids such
133 case). [RFC6980] analyzes the security implications of employing
134 IPv6 fragmentation with Neighbor Discovery for IPv6, and formally
135 recommends against such usage. Finally, [RFC7123] discusses how some
136 popular RA-Guard implementations are subject to evasion by means of
137 IPv6 extension headers.
139 While packets employing IPv6 Extension Headers have been "known" to
140 be dropped in some IPv6 deployments, there was not much concrete data
141 on the topic. Some preliminary measurements have been presented in
142 [PMTUD-Blackholes], [Gont-IEPG88] and [Gont-Chown-IEPG89], whereas
143 [Linkova-Gont-IEPG90] presents more comprehensive results on which
144 Section 4 of this document is based.
146 3. Operational Implications
148 3.1. Performance Issues
150 Many IPv6 router implementations suffer from a negative performance
151 impact when IPv6 Extension Headers are employed.
153 In the most trivial case, a packet that includes a Hop-by-Hop Options
154 header will typically go through the slow forwarding path, and be
155 processed by the router's CPU. Another case is that in which a
156 router that has been configured to enforce an ACL based on upper-
157 layer information (e.g., upper layer protocol or TCP Destination
158 Port). In such case, the router will need to process the entire IPv6
159 header chain in order to find the required information, and this may
160 cause the packet to be processed in the slow path [Cisco-EH-Cons].
162 Processing a large amounts of traffic in the slow patch may cause the
163 router to be unable to handle the same traffic loads when compared to
164 normal packets, and may result in Denial of Service (DoS) scenarios.
166 We note that, for obvious reasons, the aforementioned performance
167 issues may also affect other devices such as firewalls, Network
168 Intrusion Detection Systems (NIDS), etc. [Zack-FW-Benchmark].
170 3.2. Security Implications
172 The security implications of IPv6 Extension Headers generally fall
173 into one or more of these categories:
175 o Evasion of security controls
177 o DoS due to processing requirements
179 o DoS due to implementation errors
181 o Extension Header-specific issues
183 Different from IPv4, where the upper-layer protocol can be found
184 after the variable-length IPv4 header, the structure of IPv6 packets
185 is both more flexible and complex. Namely, finding the upper-layer
186 information may imply processing the (daisy-chain like) entire IPv6
187 header chain. This has been often overlooked, and a number of
188 security devices have been found to be trivially evasible by
189 inserting one or more IPv6 Extension Headers between the main IPv6
190 header and the upper layer protocol. [RFC7113] describes this issue
191 for the RA-Guard case, but same same techniques can be employed for
192 circumventing e.g. some IPv6 firewalls. Additionally,
193 inconsistencies in how some packets may be processed may result in
194 evasion of security controls [I-D.kampanakis-6man-ipv6-eh-parsing]
195 [Atlasis2014].
197 As noted in Section 3.1, packets that employ IPv6 Extension Headers
198 may have a negative performance impact on the handling devices.
199 Unless appropriate mitigations are put in place (e.g., packet
200 filtering and/or rate-limiting), an attacker could simply send a
201 large amount of IPv6 traffic employing IPv6 Extension Headers with
202 the purpose of performing a Denial of Service (DoS) attack.
204 IPv6 implementations, as virtually every piece of software, tend to
205 mature over time. While the IPv6 protocol itself (and many
206 implementations) have been around for a long time already, bugs in
207 IPv6 Extension Header processing have been recently found in a number
208 of implementations. Because there is currently almost no reliance on
209 IPv6 Extension headers, the corresponding code paths are rarely
210 exercised, and there is the potential that bugs still remain to be
211 discovered in some implementations.
213 Besides the general implications of IPv6 Extension Headers, each
214 Extension Header tends to its own specific implications. One
215 particular case is that of the Fragment Header, which is employed to
216 provide the fragmentation function in IPv6. While many of the
217 security implications of the fragmentation/reassembly mechanism are
218 known from the IPv4 world, many of the related issues have creeped
219 into IPv6 implementations. They range from Denial of Service attacks
220 to information leakage (see e.g.
221 [I-D.ietf-6man-predictable-fragment-id], [Bonica-NANOG58],
222 [Atlasis2012]).
224 4. Support of IPv6 Extension Headers in the Public Internet
226 This section summarizes the results obtained when measuring the
227 support of IPv6 Extension Headers on the path towards different types
228 of public IPv6 servers. Two sources were employed for the list of
229 public IPv6 servers: the "World IPv6 Launch Day" site
230 (http://www.worldipv6launch.org/) and Alexa's top 1M web sites
231 (http://www.alexa.com). For each list of domain names, the following
232 datasets were obtained:
234 o Web servers (AAAA records of the aforementioned list)
236 o Mail servers (MX -> AAAA of such list
238 o Name servers (NS -> AAAA of such list)
240 Duplicate and unreachable addresses were eliminated from each of
241 those lists prior to obtaining the results below.
243 For each of the aforementioned address sets, three different types of
244 probes were sent:
246 o IPv6 packets with a Destination Options header of 8 bytes
248 o IPv6 packets resulting in two IPv6 fragments of 512 bytes each
249 (approximately)
251 o IPv6 packets with a Hop-by-Hop Options header of 8 bytes
253 In the case of packets with Destination Options Header and Hop-by-Hop
254 Options header, the desired EH size was achieved by means of PadN
255 options [RFC2460]. The upper-layer protocol of the probe packets
256 was, in all cases, TCP [RFC0793] segments with the Destination Port
257 set to the service port [IANA-PORT-NUMBERS] of the corresponding
258 dataset. For example, the probe packets for all the measurements
259 involving web servers were TCP segments with the destination port set
260 to 80.
262 Besides obtaining the packet drop rate when employing the
263 aforementioned IPv6 extension headers, we tried to identify whether
264 the Autonomous System (AS) dropping the packets was the same as the
265 Autonomous System of the destination/target address. This is of
266 particular interest since it essentially reveals whether the packet
267 drops are under the control of the intended destination of the
268 packets. Packets dropped by the destination AS are less of a
269 concern, since they can be assumed to be the result of an explicit
270 policy of the organization to which the packets are destined (who can
271 make its own decision regarding what kind of traffic is
272 "acceptable"). On the other hand, packets dropped by transit ASes
273 are more of a concern, since they affect the deployability and
274 usability of IPv6 extension headers (including IPv6 fragmentation)
275 regardless of the intent of the communicating end-points. Thus, when
276 packet drops do occur, the "best-case scenario" is that in which the
277 packets are dropped by the destination AS, whereas the "worst-case
278 scenario" is that in which the packets are dropped by a transit AS.
279 Since there is some ambiguity when identifying the autonomous system
280 to which a specific router belongs (see Appendix A.2, our
281 measurements result in a percentage *range*: the lowest percentage
282 value represents the "best case scenario" (where, when in doubt, we
283 assume the packet drops occur in the same AS as the destination AS),
284 and the highest percentage value represents the "worst case scenario"
285 (where, when in doubt, we assume the packet drops occur at different
286 AS than the destination AS).
288 +--------------+-----------------+-----------------+----------------+
289 | Dataset | DO8 | HBH8 | FH512 |
290 +--------------+-----------------+-----------------+----------------+
291 | Web | 11.88% | 40.70% | 30.51% |
292 | | (17.60%-20.80%) | (31.43%-40.00%) | (5.08%-6.78%) |
293 +--------------+-----------------+-----------------+----------------+
294 | Mailservers | 17.07% | 48.86% | 39.17% |
295 | | (6.35%-26.98%) | (40.50%-65.42%) | (2.91%-12.73%) |
296 +--------------+-----------------+-----------------+----------------+
297 | Namerservers | 15.37% | 43.25% | 38.55% |
298 | | (14.29%-33.46%) | (42.49%-72.07%) | (3.90%-13.96%) |
299 +--------------+-----------------+-----------------+----------------+
301 Table 1: WIPv6LD dataset: Packet drop rate for different destination
302 types
304 +-------------+-----------------+-----------------+-----------------+
305 | Dataset | DO8 | HBH8 | FH512 |
306 +-------------+-----------------+-----------------+-----------------+
307 | Web | 10.91% | 39.03% | 28.26% |
308 | | (46.52%-53.23%) | (36.90%-46.35%) | (53.64%-61.43%) |
309 +-------------+-----------------+-----------------+-----------------+
310 | Mailservers | 11.54% | 45.45% | 35.68% |
311 | | (2.41%-21.08%) | (41.27%-61.13%) | (3.15%-10.92%) |
312 +-------------+-----------------+-----------------+-----------------+
313 | Namerserver | 21.33% | 54.12% | 55.23% |
314 | s | (10.27%-56.80%) | (50.64%-81.00%) | (5.66%-32.23%) |
315 +-------------+-----------------+-----------------+-----------------+
317 Table 2: Alexa's top 1M sites dataset: Packet drop rate for different
318 destination types
320 There are a number of observations to be made based on the results
321 presented above. Firstly, while it has been generally assumed that
322 it is IPv6 fragments that are dropped by operators, our results
323 indicate that it is IPv6 extension headers in general that are
324 dropped. Secondly, our results indicate that a significant
325 percentage of such packet drops occur in transit Autonomous Systems;
326 that is, the packet drops are not under the control of the same
327 organization as the final destination.
329 5. Implications of Widespread IPv6 Extension Header Filtering
331 The results presented in Section 4 indicate that at least for part of
332 the public Internet, communication employing IPv6 extension headers
333 is unreliable. The following subsections discuss specific
334 implications arising from this conclusion.
336 5.1. Advice to Protocol Designers
338 New protocols that are to operate in the public Internet should
339 consider the effect of widespread filtering of IPv6 extension headers
340 in the public Internet. If IPv6 extension headers are at all
341 employed, a fall-back mechanism that does not rely on IPv6 extension
342 headers should be considered.
344 5.2. A possible attack vector
346 The widespread filtering of IPv6 packets employing IPv6 Extension
347 Headers could, in some scenarios, be exploited for malicious
348 purposes: if packets employing IPv6 EHs are known to be filtered on
349 the path from one system (say, "A") to another (say, "B"), an
350 attacker could cause packets sent from A to B to be dropped by
351 sending a forged an ICMPv6 Packet Too Big [RFC4443] error message to
352 A (with a Next-Hop MTU smaller than 1280), such that subsequent
353 packets from A to B include a fragment header (i.e., they result in
354 atomic fragments [RFC6946]).
356 A problem with this attack scenario is that a node cannot simply
357 "filter/drop all incoming ICMPv6 Packet Too Big error messages", or
358 else it might not be able to properly reduce the assumed path MTU
359 when communicating with other IPv6 nodes.
361 Possible mitigations for this issue include:
363 o Filtering incoming ICMPv6 Packet Too Big (PTB) error messages that
364 advertise a Next-Hop MTU smaller than 1280 bytes.
366 o Artificially reducing the MTU to 1280 bytes and filter incoming
367 ICMPv6 PTB error messages
369 Filtering only those ICMPv6 PTB messages that advertise a Next-Hop
370 MTU smaller than 1280 would prevent the generation of IPv6 atomic
371 fragments without breaking Path-MTU Discovery. However, such
372 filtering would require deep packet inspection, and such
373 functionality (if at all desirable) might not be available.
375 5.3. Possible Future Work
377 The impact of widespread filtering of IPv6 EHs on existing protocols
378 should be considered. In particular, the effect of widespread
379 filtering of IPv6 fragments on the Domain Name System (DNS) [RFC1034]
380 should be evaluated (particularly when it is expected that reliance
381 on IPv6 transport will increase over time).
383 6. Troubleshooting Packet Drops due to IPv6 Extension Headers
385 Isolating IPv6 blackholes essentially involves performing IPv6
386 traceroute for a destination system with and without IPv6 extension
387 headers. The (EH-free) traceroute would provide the full working
388 path towards a destination, while the EH-enabled traceroute would
389 provide the address of the last-responding node for EH-enabled
390 packets (say, "M"). In principle, one could isolate the dropping
391 node by looking-up "M" in the EH-free traceroute, with the dropping
392 node being "M+1" (see Appendix A.1 for caveats).
394 At the time of this writing, most traceroute implementations do not
395 support IPv6 extension headers. However, the path6 tool [path6] and
396 RIPE Atlas [RIPE-Atlas] provide such support. Additionally, the
397 blackhole6 tool [blackhole6] automates the troubleshooting process
398 and can readily provide information such as: dropping node's IPv6
399 address, dropping node's Autonomous System, etc.
401 7. IANA Considerations
403 There are no IANA registries within this document. The RFC-Editor
404 can remove this section before publication of this document as an
405 RFC.
407 8. Security Considerations
409 The security implications of IPv6 extension headers are discussed in
410 Section 3.2. This document does not introduce any new security
411 issues.
413 9. Acknowledgements
415 Fernando Gont would like to thank Jan Zorz and Go6 Lab
416 for providing access to systems and networks that
417 were employed to produce some of the measurement results presented in
418 this document. Additionally, he would like to thank SixXS
419 for providing IPv6 connectivity.
421 10. References
423 10.1. Normative References
425 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
426 793, September 1981.
428 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
429 STD 13, RFC 1034, November 1987.
431 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
432 (IPv6) Specification", RFC 2460, December 1998.
434 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
435 Message Protocol (ICMPv6) for the Internet Protocol
436 Version 6 (IPv6) Specification", RFC 4443, March 2006.
438 [RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC
439 6946, May 2013.
441 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation
442 with IPv6 Neighbor Discovery", RFC 6980, August 2013.
444 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
445 of IPv6 Extension Headers", RFC 7045, December 2013.
447 [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of
448 Oversized IPv6 Header Chains", RFC 7112, January 2014.
450 [RFC7113] Gont, F., "Implementation Advice for IPv6 Router
451 Advertisement Guard (RA-Guard)", RFC 7113, February 2014.
453 [RFC7123] Gont, F. and W. Liu, "Security Implications of IPv6 on
454 IPv4 Networks", RFC 7123, February 2014.
456 10.2. Informative References
458 [Atlasis2012]
459 Atlasis, A., "Attacking IPv6 Implementation Using
460 Fragmentation", BlackHat Europe 2012. Amsterdam,
461 Netherlands. March 14-16, 2012,
462 .
465 [Atlasis2014]
466 Atlasis, A., "A Novel Way of Abusing IPv6 Extension
467 Headers to Evade IPv6 Security Devices", May 2014,
468 .
471 [Bonica-NANOG58]
472 Bonica, R., "IPv6 Extension Headers in the Real World
473 v2.0", NANOG 58. New Orleans, Louisiana, USA. June 3-5,
474 2013, .
477 [Cisco-EH-Cons]
478 Cisco, , "IPv6 Extension Headers Review and
479 Considerations", October 2006,
480 .
483 [Gont-Chown-IEPG89]
484 Gont, F. and T. Chown, "A Small Update on the Use of IPv6
485 Extension Headers", IEPG 89. London, UK. March 2, 2014,
486 .
489 [Gont-IEPG88]
490 Gont, F., "Fragmentation and Extension header Support in
491 the IPv6 Internet", IEPG 88. Vancouver, BC, Canada.
492 November 13, 2013, .
495 [I-D.ietf-6man-predictable-fragment-id]
496 Gont, F., "Security Implications of Predictable Fragment
497 Identification Values", draft-ietf-6man-predictable-
498 fragment-id-01 (work in progress), April 2014.
500 [I-D.kampanakis-6man-ipv6-eh-parsing]
501 Kampanakis, P., "Implementation Guidelines for parsing
502 IPv6 Extension Headers", draft-kampanakis-6man-ipv6-eh-
503 parsing-01 (work in progress), August 2014.
505 [I-D.taylor-v6ops-fragdrop]
506 Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo,
507 M., and T. Taylor, "Why Operators Filter Fragments and
508 What It Implies", draft-taylor-v6ops-fragdrop-02 (work in
509 progress), December 2013.
511 [I-D.wkumari-long-headers]
512 Kumari, W., Jaeggli, J., and R. Bonica, "Operational
513 Issues Associated With Long IPv6 Header Chains", draft-
514 wkumari-long-headers-02 (work in progress), October 2013.
516 [IANA-PORT-NUMBERS]
517 IANA, "Service Name and Transport Protocol Port Number
518 Registry", .
522 [Linkova-Gont-IEPG90]
523 Linkova, J. and F. Gont, "IPv6 Extension Headers in the
524 Real World v2.0", IEPG 90. Toronto, ON, Canada. July 20,
525 2014, .
528 [PMTUD-Blackholes]
529 De Boer, M. and J. Bosma, "Discovering Path MTU black
530 holes on the Internet using RIPE Atlas", July 2012,
531 .
534 [RIPE-Atlas]
535 RIPE, , "RIPE Atlas", .
537 [Zack-FW-Benchmark]
538 Zack, E., "Firewall Security Assessment and Benchmarking
539 IPv6 Firewall Load Tests", IPv6 Hackers Meeting #1,
540 Berlin, Germany. June 30, 2013,
541 .
545 [blackhole6]
546 blackhole6, , "blackhole6 tool manual page",
547 , 2014.
549 [path6] path6, , "path6 tool manual page",
550 , 2014.
552 Appendix A. Measurements Caveats
554 A number of issues have needed some consideration when producing the
555 results presented in Section 4. These same issues should be
556 considered when troubleshooting connectivity problems resulting from
557 the use of IPv6 Extension headers.
559 A.1. Isolating the Dropping Node
561 Let us assume that we find that IPv6 EHs are dropping on their way to
562 the destination system 2001:db8:d::1, and the output of running
563 traceroute towards such destination is:
565 1. 2001:db8:1:1000::1
566 2. 2001:db8:2:2000::4
567 3. 2001:db8:2:4000::1
568 4. 2001:db8:3:4000::1
569 5. 2001:db8:3:1000::1
570 6. 2001:db8:4:4000::1
571 7. 2001:db8:4:1000::1
572 8. 2001:db8:5:5000::1
573 9. 2001:db8:5:6000::1
574 10. 2001:db8:d::1
576 and the output of EH-enabled traceroute to the same destination is:
578 1. 2001:db8:1:1000::1
579 2. 2001:db8:2:2000::4
580 3. 2001:db8:2:4000::1
581 4. 2001:db8:3:4000::1
582 5. 2001:db8:3:1000::1
583 6. 2001:db8:4:4000::1
585 For the sake of brevity, let us refer to the last-responding node in
586 the EH-enabled traceroute ("2001:db8:4:4000::1" in this case) as "M".
587 Assuming both packets in both traceroutes employ the same path, we'll
588 refer to "the node following the last responding node in the EH-
589 enabled traceroute" ("2001:db8:4:1000::1" in our case), as "M+1",
590 etc.
592 Based on traceroute information above, which node is the one actually
593 dropping the EH-enabled packets will depend on whether the dropping
594 node filters packets on ingress or the egress. If the former, the
595 dropping node will be M+1. If the latter, the dropping node will be
596 "M".
598 Throughout this document (and our measurements), we assume that nodes
599 perform ingress-filtering. Thus, in our example above the last
600 responding node to the EH-enabled traceroute ("M") is
601 "2001:db8:4:4000::1", and therefore we assume the "node" dropping
602 node to be "2001:db8:4:1000::1" ("M+1").
604 Additionally, we note that when isolating the dropping node we assume
605 that both the EH-enabled and the EH-free traceroutes result in the
606 same paths. However, this might not be the case.
608 A.2. Obtaining the Responsible Organization for the Packet Drops
610 In order to identify the organization operating the dropping node,
611 one would be tempted to lookup the ASN corresponding to the dropping
612 node. However, assuming that M and M+1 are two peering routers, any
613 of these two organizations could be providing the address space
614 employed for such peering. Or, in the case of an Internet eXchange
615 Point (IXP), the address space could correspond to the IXP AS, rather
616 than to any of the participating ASes. Thus, the organization
617 operating the dropping node (M+1) could be the AS for M+1, but it
618 might as well be the AS for M+2. Only when the ASN for M+1 is the
619 same as the ASN for M+2 we have certainty about who the responsible
620 organization for the packet drops is (see slides 21-23 of
621 [Linkova-Gont-IEPG90]).
623 In the measurement results presented in Section 4, the aforementioned
624 ambiguity results in "percentage ranges" (rather than a specific
625 ratio). This same ambiguity should be considered when
626 troubleshooting and reporting IPv6 packet drops.
628 Finally, we note that a specific organization might be operating more
629 than one Autonomous System. However, our measurements assume that
630 different Autonomous System Numbers imply different organizations.
632 Authors' Addresses
634 Fernando Gont
635 SI6 Networks / UTN-FRH
636 Evaristo Carriego 2644
637 Haedo, Provincia de Buenos Aires 1706
638 Argentina
640 Phone: +54 11 4650 8472
641 Email: fgont@si6networks.com
642 URI: http://www.si6networks.com
644 J. Linkova
645 Google
646 1600 Amphitheatre Parkway
647 Mountain View, CA 94043
648 USA
650 Email: furry@google.com
652 Tim Chown
653 University of Southampton
654 Highfield
655 Southampton , Hampshire SO17 1BJ
656 United Kingdom
658 Email: tjc@ecs.soton.ac.uk
659 Will (Shucheng) Liu
660 Huawei Technologies
661 Bantian, Longgang District
662 Shenzhen 518129
663 P.R. China
665 Email: liushucheng@huawei.com