idnits 2.17.1
draft-chown-v6ops-call-to-arms-03.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 (June 7, 2011) is 4705 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
-- Obsolete informational reference (is this intentional?): RFC 1981
(Obsoleted by RFC 8201)
-- Obsolete informational reference (is this intentional?): RFC 3068
(Obsoleted by RFC 7526)
-- Obsolete informational reference (is this intentional?): RFC 3484
(Obsoleted by RFC 6724)
-- Obsolete informational reference (is this intentional?): RFC 4941
(Obsoleted by RFC 8981)
== Outdated reference: A later version (-07) exists of
draft-ietf-v6ops-happy-eyeballs-02
== Outdated reference: A later version (-11) exists of
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-05
== Outdated reference: A later version (-04) exists of
draft-chen-mif-happy-eyeballs-extension-01
== Outdated reference: A later version (-05) exists of
draft-ietf-6man-rfc3484-revise-02
== Outdated reference: A later version (-05) exists of
draft-arkko-ipv6-only-experience-03
Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 IPv6 Operations T. Chown
3 Internet-Draft University of Southampton
4 Intended status: Informational M. Ford
5 Expires: December 9, 2011 Internet Society
6 S. Venaas
7 Cisco Systems
8 June 7, 2011
10 World IPv6 Day Call to Arms
11 draft-chown-v6ops-call-to-arms-03
13 Abstract
15 The Internet Society (ISOC) has declared that June 8th 2011 will be
16 World IPv6 Day, on which some major organisations are going to make
17 their content available over IPv6. With the likes of Google and
18 Facebook providing IPv6 access to their production services and
19 domains, it is very likely we will see more IPv6 traffic flowing
20 across the Internet than has ever been seen before. With this in
21 mind, it seems timely to issue a call to arms for systems and network
22 administrators to review their organisation's IPv6 capabilities in
23 order to mitigate common causes of IPv6 connectivity problems in
24 advance of the day. The increased traffic on World IPv6 Day should
25 also create an excellent opportunity to observe the behaviour and
26 performance of IPv6; it is thus very desirable to have appropriate
27 measurement tools in place in advance. We discuss some appropriate
28 tools from the network and application perspective.
30 Status of this Memo
32 This Internet-Draft is submitted in full conformance with the
33 provisions of BCP 78 and BCP 79.
35 Internet-Drafts are working documents of the Internet Engineering
36 Task Force (IETF). Note that other groups may also distribute
37 working documents as Internet-Drafts. The list of current Internet-
38 Drafts is at http://datatracker.ietf.org/drafts/current/.
40 Internet-Drafts are draft documents valid for a maximum of six months
41 and may be updated, replaced, or obsoleted by other documents at any
42 time. It is inappropriate to use Internet-Drafts as reference
43 material or to cite them other than as "work in progress."
45 This Internet-Draft will expire on December 9, 2011.
47 Copyright Notice
48 Copyright (c) 2011 IETF Trust and the persons identified as the
49 document authors. All rights reserved.
51 This document is subject to BCP 78 and the IETF Trust's Legal
52 Provisions Relating to IETF Documents
53 (http://trustee.ietf.org/license-info) in effect on the date of
54 publication of this document. Please review these documents
55 carefully, as they describe your rights and restrictions with respect
56 to this document. Code Components extracted from this document must
57 include Simplified BSD License text as described in Section 4.e of
58 the Trust Legal Provisions and are provided without warranty as
59 described in the Simplified BSD License.
61 Table of Contents
63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
64 2. Connectivity Issues . . . . . . . . . . . . . . . . . . . . . 4
65 2.1. Unmanaged Tunnels . . . . . . . . . . . . . . . . . . . . 4
66 2.2. Tunnel Broker first-hop delays . . . . . . . . . . . . . . 5
67 2.3. Connection Timeouts . . . . . . . . . . . . . . . . . . . 5
68 2.4. PMTU Discovery . . . . . . . . . . . . . . . . . . . . . . 7
69 2.5. Rogue Router Advertisements . . . . . . . . . . . . . . . 7
70 2.6. Tunnel performance . . . . . . . . . . . . . . . . . . . . 8
71 2.7. AAAA record advertised but service not enabled . . . . . . 8
72 2.8. IPv6 Reverse DNS . . . . . . . . . . . . . . . . . . . . . 9
73 3. Instrumentation . . . . . . . . . . . . . . . . . . . . . . . 9
74 3.1. IPv6 traffic levels . . . . . . . . . . . . . . . . . . . 9
75 3.2. Network flow records . . . . . . . . . . . . . . . . . . . 10
76 3.3. Client Web Access Success Rate . . . . . . . . . . . . . . 10
77 3.4. Tools to measure IPv6 brokenness . . . . . . . . . . . . . 10
78 3.5. IPv4 Performance Comparison . . . . . . . . . . . . . . . 11
79 3.6. User Tickets . . . . . . . . . . . . . . . . . . . . . . . 11
80 3.7. Security monitoring . . . . . . . . . . . . . . . . . . . 11
81 4. IPv6-only testing . . . . . . . . . . . . . . . . . . . . . . 11
82 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11
83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
85 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
86 9. Informative References . . . . . . . . . . . . . . . . . . . . 12
87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
89 1. Introduction
91 Despite the recent exhaustion of the available IPv4 address pool,
92 deployment of IPv6 remains limited. To help encourage organisations
93 to trial production deployment, ISOC has declared June 8th 2011 as
94 World IPv6 Day [ISOC]. Organisations are encouraged to use this day
95 to test IPv6 in production by making their main, externally-facing
96 websites available over IPv6. Sites planning to turn on IPv6 for
97 access in their network in the interest of World IPv6 Day should
98 ensure this is completed well before the day, and commit to leaving
99 it active after the event, and thus using the method they would
100 choose to do so indefinitely. At the current time, this would
101 generally mean enabling dual-stack networking with IPv4 running
102 alongside IPv6. However, IPv6-only networks are ultimately
103 inevitable, and so some sites may choose to use June 8th to undertake
104 some focused tests on that deployment model.
106 The purpose of this document is two-fold. One is to discuss common
107 IPv6 connectivity issues that are likely to arise on June 8th, with a
108 focus on dual-stack networking (which is likely to be how the vast
109 majority of sites take part). Most of the issues discussed in this
110 text are those that would affect an end site or enterprise network
111 running IPv6, but may be applicable elsewhere. Highlighting the
112 issues should help raise awareness of those problems and possible
113 mitigations. The other purpose is to encourage organisations to
114 think about how they might get useful instrumentation in place to
115 observe what happens in and to/from their networks on the day, both
116 from the network and application perspective. Such measurement tools
117 are likely to be useful in the longer term, so once deployed they
118 could be left in place beyond June 8th.
120 For sites providing content, June 8th will be a chance to make some
121 public facing services available over IPv6, most likely web content
122 using their production domain (e.g. www.example.com) rather than a
123 contrived IPv6 test domain (e.g. www.ipv6.example.com). Enabling
124 public-facing Internet services is a reasonable first step for any
125 organisation deploying IPv6. For ISPs, supporting IPv6 for their
126 Internet-facing services (web, mail, etc.) and recording the impact
127 of World IPv6 Day on their IPv4-only customers is an appropriate
128 action. For sites enabling clients, doing so initially in their IT
129 department may be appropriate; for educational sites enabling IPv6 on
130 eduroam wireless networks could be appropriate given the underlying
131 802.1x authentication technology is IP version independent.
133 It should be emphasised that while World IPv6 Day is in many senses
134 an 'experiment' or 'test flight' for IPv6, organisations should
135 strongly consider deploying IPv6 in exactly the same robust way that
136 they would do if they were deploying IPv6 and leaving it enabled
137 indefinitely. Similarly, applying measures to improve IPv6
138 robustness, e.g. improved ICMPv6 filtering practice, should be
139 considered long term benefits. That they 'affect' the experiment is
140 not a problem; indeed all measures that improve the robustness of
141 IPv6 deployment should be seen as worthwhile. There will still be
142 problems found, but these can at least be recognised and work done to
143 make them better.
145 The document also includes a brief section on tools that might be
146 used to test IPv6-only operation.
148 The scope of this document is purely informational to provoke
149 discussion.
151 2. Connectivity Issues
153 In this section we review some common causes of IPv6 connectivity
154 issues, oriented towards those that end sites or enterprises may have
155 some ability to influence or mitigate. Some issues, such as transit
156 arrangements, are not included - currently the focus is on end sites
157 (or users) who may take part in the World IPv6 Day. Some IPv6
158 connectivity test sites are emerging, for example [testipv6]. There
159 is no significance to the order in which issues are listed.
161 2.1. Unmanaged Tunnels
163 One cause of connectivity problems is the use of unmanaged tunnels,
164 in particular 'automated' methods that are not provisioned by the
165 user's ISP. The most common example is 6to4 [RFC3056], or more
166 specifically the 6to4 relay approach described in [RFC3068]. A
167 native IPv6 host communicating with a 6to4 host will require both
168 hosts to have access to an appropriately capable 6to4 relay (which
169 may or may not be the same relay). If a host in a native IPv6
170 network has no route to 2002::/16 it cannot send traffic to a 6to4
171 host. Similarly, a 6to4 router that cannot reach the well-known IPv4
172 anycast relay address cannot send traffic to a native IPv6 network.
173 There are also potential issues with Protocol 41 filtering at site
174 borders close to the client.
176 A presentation by Geoff Huston at IETF80 [Huston2011] highlighted the
177 connection failure rates with 6to4, measured in excess of 15%, as
178 well as the additional latency in 6to4 communications, with 6to4
179 showing an average additional 1.2s latency per retrieval.
181 One approach to this problem is to encourage sites/ISPs to run local
182 relays, as discussed in [I-D.carpenter-v6ops-6to4-teredo-advisory].
183 This draft discusses how to make 6to4 more robust in situations where
184 there is a conscious decision to use it. Sites using 6to4 should
185 consider deploying local relays to increase the chance of a good IPv6
186 experience. The alternative to reduce such problems is simply to
187 move 6to4 to Historic, as proposed in
188 [I-D.troan-v6ops-6to4-to-historic]. This would mean 6to4 would not
189 be enabled by default anywhere, and once its usage had reduced
190 enough, relays could be turned off.
192 There may still be some CPE routers that do enable 6to4 by default;
193 it is likely that devices behind such routers will experience
194 problems on World IPv6 Day.
196 Connection failures and latency with the Teredo protocol [RFC4380]
197 were also highlighted by Geoff Huston's IETF80 presentation. Teredo
198 connection failure rates were as high as 35%, with 1-3s additional
199 latency. One of the connection issues is reliance on the ICMPv6
200 probe packet being able to reach the destination host; in practice
201 filters may block these. Thus Teredo should not be considered a
202 reliable means of accessing the IPv6 Internet.
204 2.2. Tunnel Broker first-hop delays
206 IPv6 tunnel brokers, such as those provided by SixXS
207 (http://www.sixxs.net) and Hurricane Electric
208 (http://tunnelbroker.net) provide a more robust, managed approach to
209 IPv6-in-IPv4 tunnelled access than 6to4. Individual users interested
210 in IPv6 access for World IPv6 Day, in the absence of IPv6 support
211 from their ISP, should consider registering to use a free tunnel
212 broker. It would be sensible to register for and test your broker
213 client well in advance of IPv6 Day, and ideally plan to keep it
214 available beyond that date, until your ISP provides IPv6 natively for
215 you. One set of test sites to use would be the list cited on the
216 ISOC World IPv6 Day site [ISOCsites].
218 When choosing a broker service, it is prudent to pick one with a
219 presence near to you that has a minimal round trip time. Providers
220 such as SixXS and HE have tunnel broker servers in many countries.
221 Beware picking a broker in another continent that may add 150ms+ to
222 your round trip times.
224 2.3. Connection Timeouts
226 One of the main drivers for IPv6 Day is identifying and fixing the
227 problems that can lead to connection timeouts. Because unreliable
228 IPv6 connectivity leads to intensely frustrating problems for end-
229 users, it is essential that people motivated to deploy IPv6
230 connectivity, whether for themselves, or for a larger network, only
231 do so in a well-supported, production-quality fashion.
233 Where dual-stack systems - or rather the applications running on them
234 - have a choice of IPv4 or IPv6 connectivity, timeouts can occur if
235 there is no connectivity on the preferred protocol. For example, if
236 both A and AAAA DNS records exists for a web server, and IPv6
237 connectivity is broken, there is likely to be some timeout for the
238 browser before the connection drops back to IPv4.
240 A bigger problem exists if the application or OS tries IPv6 first and
241 then does not fall back to IPv4. A bug in versions of Opera prior to
242 10.5 caused such behaviour, which was obviously a big issue for Opera
243 users trying to access dual-stack web sites with broken IPv6
244 connectivity.
246 The author has undertaken some informal tests at his own site, which
247 shows how different combinations of browsers and operating systems
248 behave in the event of IPv6 connections failing or when ICMP
249 unreachables are received. On Linux/Firefox, web connections timeout
250 after 20 seconds for 'no response', but immediately for unreachables.
251 In contrast, Windows Vista/IE was 20 seconds regardless of
252 unreachables being received. Any non-trivial delay will cause
253 significant user frustration.
255 A more complete set of tests was run by Teemu Savolainen and reported
256 at IETF80 [Savolainen2011]. Although the tests were only samples,
257 they confirmed the results, also showing experiences across a much
258 broader range of platforms, and that the problems with Vista/IE are
259 repeated with Win 7/IE. It's thus clear that if major content
260 providers enable IPv6 on World IPv6 Day, and end users for some
261 reason try to access the content with broken IPv6 connectivity, they
262 are likely to experience significant timeout issues.
264 This problem is probably the main reason that Google implemented a
265 AAAA whitelisting system for its test sites. The sites had to
266 demonstrate they had good IPv6 connectivity before being allowed into
267 the test programme. The topic is discussed in
268 [I-D.ietf-v6ops-v6-aaaa-whitelisting-implications]. For the sake of
269 World IPv6 Day, it is expected that no such whitelisting is in place
270 - that is, after all, the point of having a day dedicated to testing
271 IPv6 in production.
273 An interesting suggestion to handle the problem is the 'happy
274 eyeballs' approach described in [I-D.ietf-v6ops-happy-eyeballs].
275 This approach is now also being suggested for multiple interface
276 systems, as per [I-D.chen-mif-happy-eyeballs-extension]. The happy
277 eyeballs philosophy is to try both IPv4 and IPv6 together, and keep
278 the first working connection up, remembering the result for future
279 connection attempts. It may prefer IPv6 slightly in initial
280 connections rather than trying connections exactly simultaneously.
282 It is an interesting approach, though some people are concerned about
283 the additional connection load, or that this 'workaround' is simply
284 masking underlying problems that should be fixed.
286 2.4. PMTU Discovery
288 IPv6 mandates that fragmentation is only undertaken by the sending
289 node, and thus IPv6 requires working PMTU Discovery [RFC1981]. An
290 existing RFC gives Recommendations for Filtering ICMPv6 Messages in
291 Firewalls [RFC4890]; if this guidance is not followed, connectivity
292 problems are likely to arise. Blindly filtering all ICMPv6 messages
293 is not good practise. Filtering ICMP is a common practice in some
294 IPv4 networks today. Adopting the same approach to ICMPv6 when
295 deploying IPv6 networks will cause connectivity issues for users of
296 the network filtering ICMPv6 and hosts trying to reach the filtered
297 network. RFC 4890 is therefore an important document for IPv6
298 deployment engineers to read and it is similarly important to verify
299 that IPv6 firewall deployments support appropriate configurations for
300 ICMPv6 filtering.
302 The minimum MTU for IPv6 is 1280 bytes. Checking the MTU is an
303 important step when connectivity issues arise. Where PMTUD is not
304 working or not implemented, the using the minimum MTU is likely to
305 resolve the problem, though not give optimal performance (the cause
306 should still be investigated and resolved for longer term benefit).
307 Tunnel broker services such as SixXS and HE set their MTUs to default
308 to 1280, probably due to the varying conditions their customers may
309 be in. However, it is preferable for enterprise networks to
310 configure appropriate ICMPv6 filtering to allow PMTUD to operate and
311 establish the most efficient MTUs for a link.
313 2.5. Rogue Router Advertisements
315 Within a site, hosts may use IPv6 Stateless Address Autoconfiguration
316 (SLAAC) [RFC4862]. However, it is possible for accidental (or
317 malicious) rogue RAs to cause connectivity issues, as described in
318 the Rogue Router Advertisement Problem Statement [RFC6104].
320 A typical cause of rogue RAs is Windows ICS, which can present a
321 rogue 6to4 router on its wireless interface. This will cause hosts
322 to potentially autoconfigure two global IPv6 addresses and pick the
323 wrong default router, with unpredictable results. As a (bad) example
324 the author experienced a scenario where he had a rogue 6to4 RA, but
325 because the rogue 6to4 was working he was able to access IPv6
326 networks outside his own network, but could not access most internal
327 hosts inside his own network because he was unwittingly using 6to4
328 from outside into his own network, and thus being firewalled from
329 those internal hosts.
331 In many cases, default address selection [RFC3484] (and
332 [I-D.ietf-6man-rfc3484-revise]) would avoid such cases, because the
333 address selection rules should prefer, or can be configured to
334 prefer, native IPv6 over 6to4. However not all operating systems
335 implement RFC 3484 yet, in particular MacOS X (though support may be
336 appearing in Lion). Where rogue RAs cause broken IPv6 behaviour, the
337 timeout issues discussed above may apply.
339 Adding ACLs to your switches to block ICMPv6 Type 134 packets on
340 ports that do not have routers connected would also minimise the
341 impact of rogue RAs. A more elegant solution is RA Guard [RFC6105],
342 and another is use of SEcure Neighbour Discovery (SEND) [RFC3971].
343 However neither is widely implemented yet. Indeed, any reported
344 operational experience of SEND in an enterprise network would be very
345 welcome.
347 Finally, there is a tool called RAmond, available freely from
348 http://ramond.sourceforge.net, that can be configured to detect and
349 issue deprecating RAs against observed rogue RAs. This software is
350 based on rafixd.
352 2.6. Tunnel performance
354 In scenarios where sites currently have manually configured tunnels
355 to gain IPv6 connectivity, it may be the case that such encapsulation
356 is performed by a router's CPU, in which case unexpected high volumes
357 of traffic may cause problems. Bear in mind that on World IPv6 Day,
358 you may start using IPv6 by default for some high bandwidth
359 applications that you had not used before, e.g. YouTube from Google.
360 It may be prudent to estimate your load for such applications in
361 advance, and test the capability of your tunnelling solution to
362 handle that load.
364 2.7. AAAA record advertised but service not enabled
366 If enabling a service for World IPv6 Day, be aware of other existing
367 services that may be running on the same system. If a server has
368 multiple functions, all services should be IPv6 enabled before a AAAA
369 record is entered into the DNS for services that may use that name.
371 A related consideration is to make sure that firewalls don't just
372 drop IPv6 packets to ports that are not in use. It's better if the
373 firewall or host sends an unreachable indication or a TCP RST to
374 avoid a potential timeout. For example, if you add a AAAA record for
375 your web server that also runs say FTP, where FTP is IPv4 only,
376 either the firewall should have port 21 open or the firewall should
377 be configured ta send a TCP RST. There are of course tradeoffs in
378 enabling ICMP unreachables.
380 2.8. IPv6 Reverse DNS
382 Presence of IPv6 reverse DNS records is used by many systems as a
383 security method. For example, many mail exchangers will only accept
384 SMTP connections from IP addresses with a reverse DNS entry. It is
385 thus important for such records to exist where, for example, a site
386 is sending mail out over IPv6 transport. It is not necessarily the
387 case that such connections will fall back to IPv4 if reverse records
388 are not present.
390 3. Instrumentation
392 In this section we discuss potential instrumentation approaches that
393 may be configured in advance of World IPv6 Day, and then retained
394 longer term after the event. These are particularly useful if your
395 site is turning on AAAA records for its production web presence (for
396 example) and wants to get the best insight into how the systems
397 performed and the nature of the end user experience.
399 These measurements should complement informal, subjective reports
400 from users at participating sites. It is probably prudent to make at
401 least your organisation's IT staff aware of the 'at risk' day, and
402 actions they should take should they experience problems. It may
403 also be desirable to undertake some form of user survey soon
404 afterwards; whether you inform general users in advance is an issue
405 for each site. The ARIN IPv6 wiki is a good source of such advice
406 [ARINwiki].
408 3.1. IPv6 traffic levels
410 It should be possible to measure raw IPv6 traffic levels
411 independently on dual-stack switch/router platforms, given
412 implementations of appropriate MIBs. Sites should take steps to
413 ensure they have the tools in place to be able to view the relative
414 levels of IPv4 and IPv6 traffic over time.
416 Application level measurement is also desirable, because handling of
417 choice (preference) of protocol used lies with the application if
418 both A and AAAA records are returned. Sites should be aware that due
419 to IPv6 Privacy Extensions [RFC4941] application logs may show more
420 apparent different clients connecting, due to clients cycling the
421 source IPv6 address they use over time.
423 The types of information gathered might for example include:
425 o IPv6 traffic volume, sources of IPv6 traffic by AS, types of IPv6
426 traffic (e.g. native, 6to4, Teredo, tunnelled);
428 o IPv6 application mix, comparison with IPv4;
430 o The number and type of IPv6 client connections.
432 3.2. Network flow records
434 Where available, sites should seek to generate and record network
435 flow records for traffic, to maximise opportunities to analyse
436 traffic patterns after the event, or in the case of reports of
437 specific problems. Netflow v9 supports IPv6. Open source IPv6-
438 capable Netflow collectors also exist, e.g. nfsen, from
439 http://nfsen.sourceforge.net.
441 3.3. Client Web Access Success Rate
443 There have been some recent studies on the capabilities of web
444 clients to access content on dual-stack servers by IPv4 or IPv6 in
445 the presence of both A and AAAA records existing for a web domain.
447 One good example is that of [Anderson10], as reported at RIPE-61,
448 where the author set up some application (web server) oriented tests
449 for his newspaper content in Norway. The methodology was to add an
450 invisible IFRAME to his site that would include IMG links randomly to
451 1x1 images that were served either via an IPv4-only target or a dual-
452 stack target. Variation in the hit rates would imply IPv6
453 brokenness. By analysing the http metadata information could be
454 gleaned on the cause of the brokenness. Results in Q4'2009 showed
455 0.2-0.3% brokenness, including the Opera bug mentioned above.
457 Recent figures published by Google suggest at most a 0.1% level of
458 brokenness, indicating some improvement, but that level is still
459 potentially 1 in 1000 users with a problem.
461 3.4. Tools to measure IPv6 brokenness
463 Sites may wish to make their own measurements of IPv6 brokenness
464 rather than relying on third party reports. There are some openly
465 available tools available that work along similar principles to the
466 method proposed by Tore Anderson above.
468 The APNIC Labs test tool uses a combination of JavaScript and Google
469 Analytics to measure various types of brokenness [APNIC]. Eric
470 Vyncke's tool [Vyncke] measures a slightly smaller set of types of
471 brokenness, but also looks very useful, with additional reports on
472 the browser type for each failure. The author is currently using the
473 latter tool, and plans to enable the APNIC measurement system shortly
474 when other Analytics updates are applied locally.
476 3.5. IPv4 Performance Comparison
478 Where a dual-stack service is deployed, measuring the relative
479 performance of both protocols is desirable. This may primarily be a
480 measurement of throughput or delay, but may also include
481 availability/uptime measurement. A site may choose to set up its own
482 performance measuring framework, for example using open source
483 bandwidth and throughput test tools. Participants in World IPv6 Day
484 will be monitored from a broad range of locations and measurements
485 will be available to show availability of AAAA records, reachability
486 to http service, latency and availability over time.
488 3.6. User Tickets
490 It is possible a higher than usual user ticket rate for connectivity
491 issues may be experienced. being able to categorise these cases for
492 subsequent analysis is desirable.
494 3.7. Security monitoring
496 We mentioned RAmond above in the context of watching for rogue RAs.
497 There is another useful package called NDPmon, also available freely
498 from http://ndpmon.sourceforge.net, that can be configured to watch
499 for certain types of IPv6 'abuse' on your local network. It may be
500 interesting to run the tool to confirm whether any 'bad' traffic is
501 observed within your network on World IPv6 Day.
503 4. IPv6-only testing
505 The long-term IPv6 deployment plan is IPv6-only networking, rather
506 than dual-stack. It is not clear how quickly significant IPv6-only
507 networks will emerge, but testing of approaches to IPv6-only
508 operation is desirable as soon as possible. A draft by Jari Arkko
509 and Ari Keranen describes some such experiences
510 [I-D.arkko-ipv6-only-experience].
512 Some experience of NAT64 [RFC6146] has been described in
513 [I-D.tan-v6ops-nat64-experiences], though this appears to have used
514 only NAT-PT so far. An implementation of NAT64 is available at
515 http://ecdysis.viagenie.ca. Operational experience of IVI is also
516 desirable. An implementation of IVI is available at
517 http://www.ivi2.org/IVI.
519 5. Conclusions
521 With the ISOC World IPv6 Day event due on June 8th 2011, this
522 document aims to help focus attention on both improving awareness and
523 mitigations of common causes of IPv6 connectivity problems, and
524 encouraging sites and organisations to introduce appropriate
525 instrumentation into their networks so they can observe traffic
526 behaviour appropriately.
528 This is still an early version of the text, and is thus a little
529 drafty. All comments are very welcome towards a mature version in
530 advance of June.
532 6. Security Considerations
534 There are no extra security consideration for this document.
536 7. IANA Considerations
538 There are no extra IANA consideration for this document.
540 8. Acknowledgments
542 To be added.
544 9. Informative References
546 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
547 for IP version 6", RFC 1981, August 1996.
549 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
550 via IPv4 Clouds", RFC 3056, February 2001.
552 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
553 RFC 3068, June 2001.
555 [RFC3484] Draves, R., "Default Address Selection for Internet
556 Protocol version 6 (IPv6)", RFC 3484, February 2003.
558 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
559 Neighbor Discovery (SEND)", RFC 3971, March 2005.
561 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
562 Network Address Translations (NATs)", RFC 4380,
563 February 2006.
565 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
566 Address Autoconfiguration", RFC 4862, September 2007.
568 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering
569 ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
571 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
572 Extensions for Stateless Address Autoconfiguration in
573 IPv6", RFC 4941, September 2007.
575 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement
576 Problem Statement", RFC 6104, February 2011.
578 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
579 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
580 February 2011.
582 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
583 NAT64: Network Address and Protocol Translation from IPv6
584 Clients to IPv4 Servers", RFC 6146, April 2011.
586 [I-D.carpenter-v6ops-6to4-teredo-advisory]
587 Carpenter, B., "Advisory Guidelines for 6to4 Deployment",
588 draft-carpenter-v6ops-6to4-teredo-advisory-03 (work in
589 progress), March 2011.
591 [I-D.ietf-v6ops-happy-eyeballs]
592 Wing, D. and A. Yourtchenko, "Happy Eyeballs: Trending
593 Towards Success with Dual-Stack Hosts",
594 draft-ietf-v6ops-happy-eyeballs-02 (work in progress),
595 May 2011.
597 [I-D.tan-v6ops-nat64-experiences]
598 Tan, J., Lin, J., and W. Li, "Experience from NAT64
599 applications", draft-tan-v6ops-nat64-experiences-00 (work
600 in progress), March 2011.
602 [I-D.troan-v6ops-6to4-to-historic]
603 Troan, O., "Request to move Connection of IPv6 Domains via
604 IPv4 Clouds (6to4) to Historic status",
605 draft-troan-v6ops-6to4-to-historic-01 (work in progress),
606 March 2011.
608 [I-D.ietf-v6ops-v6-aaaa-whitelisting-implications]
609 Livingood, J., "IPv6 AAAA DNS Whitelisting Implications",
610 draft-ietf-v6ops-v6-aaaa-whitelisting-implications-05
611 (work in progress), May 2011.
613 [I-D.chen-mif-happy-eyeballs-extension]
614 Chen, G. and C. Williams, "Happy Eyeballs Extension for
615 Multiple Interfaces",
616 draft-chen-mif-happy-eyeballs-extension-01 (work in
617 progress), March 2011.
619 [I-D.ietf-6man-rfc3484-revise]
620 Matsumoto, A., Kato, J., and T. Fujisaki, "Update to RFC
621 3484 Default Address Selection for IPv6",
622 draft-ietf-6man-rfc3484-revise-02 (work in progress),
623 March 2011.
625 [I-D.arkko-ipv6-only-experience]
626 Arkko, J. and A. Keranen, "Experiences from an IPv6-Only
627 Network", draft-arkko-ipv6-only-experience-03 (work in
628 progress), April 2011.
630 [APNIC] "IPv6 Capability Tracker", .
632 [Vyncke] Vyncke, E., "Estimation of IPv6 brokenness",
633 .
635 [ARINwiki]
636 "ARIN IPv6 Wiki", .
639 [testipv6]
640 "Test IPv6", .
642 [ISOC] "World IPv6 Day", .
644 [Huston2011]
645 Huston, G., "Stacking it Up: Experimental Observations on
646 the operation of Dual Stack Services", 2011,
647 .
649 [Savolainen2011]
650 Savolainen, T., "Experiences of host behaviour in broken
651 IPv6 networks", 2011,
652 .
654 [ISOCsites]
655 "IPv6 Enabled Websites",
656 .
658 [Anderson10]
659 Anderson, T., "Measuring and Combating IPv6 Brokenness",
660 2010,
661 .
663 Authors' Addresses
665 Tim Chown
666 University of Southampton
667 Highfield
668 Southampton, Hampshire SO17 1BJ
669 United Kingdom
671 Email: tjc@ecs.soton.ac.uk
673 Mat Ford
674 Internet Society
675 Geneva,
676 Switzerland
678 Email: ford@isoc.org
680 Stig Venaas
681 Cisco Systems
682 Tasman Drive
683 San Jose, CA 95134
684 USA
686 Email: stig@cisco.com