[v6ops] Comments on draft-chown-v6ops-call-to-arms-02

[Matthew Ford <[e-mail]>]

Hi,

Firstly, thanks to Tim and Stig for taking the initiative to put this together. I've reviewed the draft and have some comments, inline below. Overall I think the document is a useful contribution, but the time to raise awareness is now so pointers to the (revised) draft will have to suffice I think.

Regards,
Mat

> 1.  Introduction
> 
>    Despite the recent exhaustion of the available IPv4 address pool,
>    deployment of IPv6 remains limited.  To help encourage organisations
>    to trial production deployment, ISOC has declared June 8th 2011 as
>    World IPv6 Day [ISOC].  Organisations are encouraged to use this day
>    to test IPv6 in production, either by enabling clients in their
>    network, or by making externally-facing services available over IPv6.

I'd prefer to have this read 'Organisations are encouraged to use this day to test IPv6 in production by making their main, externally-facing websites available over IPv6'.

The original purpose of W6D was to measure and identify sources of end-user brokenness to help address some content provider issues. Nevertheless, W6D has clearly helped to move IPv6 deployment up the agenda for ISPs and others as well. ISPs have a different set of issues when it comes to enabling IPv6.

The following text was agreed elsewhere as advice for ISPs in relation to W6D and it might be good to include it here:

"If you are planning to turn on IPv6 for access in your network in the interest
of World IPv6 Day, please ensure your adds are completed well before the day
(e.g., by May 31), and commit to leaving it active.  Turning on IPv6 for
only a brief period around June 8th will confuse measurements and not give a
clear idea of the world's readiness for IPv6 and IPv4 coexistence:  it is
therefore not a contribution to the effort.

If Service Providers want to participate in World IPv6 Day they can do the 
following:

1. Support IPv6 / AAAA records for all their Internet facing services (web/mail/etc)

2. Record the impact of World IPv6 Day on their IPv4-only customers (as described in more detail below)

If, and only if, providers are ready to support production quality, general availability 
of IPv6, then they should be encouraged to:

3. Record the impact of World IPv6 Day on dual-stack customers"

>    At the current time, this would generally mean enabling dual-stack
>    networking with IPv4 running alongside IPv6.  However, IPv6-only
>    networks are inevitable, and so some sites may choose to use June 8th
>    to undertake some focused tests on that deployment model.
> 

I think that needs to come with a health warning along the lines of 'please don't do anything that you can't have enabled well in advance of World IPv6 Day, and continue to support in the long-term'. Turning up networks for 24hrs isn't going to help. I know you have some of these points below, but I think it's important to make clear the right way do this on first mention of enabling IPv6 networks.

>    The purpose of this document is two-fold.  One is to discuss common
>    IPv6 connectivity issues that are likely to arise on June 8th, with a
>    focus on dual-stack networking (which is likely to be how the vast
>    majority of sites take part).  Most of the issues discussed in this
>    text are those that would affect an end site or enterprise network
>    running IPv6, but may be applicable elsewhere.  Highlighting the
>    issues should help raise awareness of those problems and possible
>    mitigations.  The other purpose is to encourage organisations to
>    think about how they might get useful instrumentation in place to
>    observe what happens in and to/from their networks on the day, both
>    from the network and application perspective.  Such measurement tools
>    are likely to be useful in the longer term, so once deployed they
>    could be left in place beyond June 8th.
> 
>    For most sites providing content, June 8th will be a chance to make
>    some public facing services available over IPv6, most likely web
>    content using their production domain (e.g. www.example.com) rather
>    than a contrived IPv6 test domain (e.g. www.ipv6.example.com).
>    Enabling public-facing Internet services is a reasonable first step
>    for any organisation deploying IPv6.  Some sites or enterprises may
>    choose to enable IPv6 in user/client subnets, in which case the
>    performance of those systems and the applications they run will be of
>    paramount interest.  However, enabling client access for just one day
>    may not be optimal; it would be much more preferable that client
>    subnets were enabled in advance of World IPv6 Day, using a method
>    that the enabling site would be happy to use indefinitely.  For some
>    sites enabling clients in their IT department may be appropriate; for
>    educational sites enabling IPv6 on eduroam wireless networks could be
>    appropriate given the underlying 802.1x authentication technology is
>    IP version independent.
> 
>    It should be emphasised that while World IPv6 Day is in many senses
>    an 'experiment' or 'test flight' for IPv6, organisations should
>    strongly consider deploying IPv6 in exactly the same robust way that
>    they would do if they were deploying IPv6 and leaving it enabled
> 
> 
> 
> Chown & Venaas          Expires October 21, 2011                [Page 3]
> Internet-Draft         World IPv6 Day Call to Arms            April 2011
> 
> 
>    indefinitely.  Similarly, applying measures to improve IPv6
>    robustness, e.g. improved ICMPv6 filtering practice, should be
>    considered long term benefits.  That they 'affect' the experiment is
>    not a problem; indeed all measures that improve the robustness of
>    IPv6 deployment should be seen as worthwhile.  There will still be
>    problems found, but these can at least be recognised and work done to
>    make them better.
> 
>    The document also includes a brief section on tools that might be
>    used to test IPv6-only operation.
> 
>    NB.  This is still a rather rough draft of the document; feedback is
>    very much welcomed.  The scope of the document is purely
>    informational to provoke discussion.  We aim to have a relatively
>    mature informational text ready well in advance of June.
> 
> 
> 2.  Connectivity Issues
> 
>    In this section we review some common causes of IPv6 connectivity
>    issues, oriented towards those that end sites or enterprises may have
>    some ability to influence or mitigate.  Some issues, such as transit
>    arrangements, are not included - currently the focus is on end sites
>    (or users) who may take part in the World IPv6 Day. There is no
>    significance to the order in which issues are listed.
> 
> 2.1.  Unmanaged Tunnels
> 
>    One cause of connectivity problems is the use of unmanaged tunnels,
>    in particular 'automated' methods that are not provisioned by the
>    user's ISP.  The most common example is 6to4 [RFC3056], or more
>    specifically the 6to4 relay approach described in [RFC3068].  A
>    native IPv6 host communicating with a 6to4 host will require both
>    hosts to have access to an appropriately capable 6to4 relay (which
>    may or may not be the same relay).  If a host in a native IPv6
>    network has no route to 2002::/16 it cannot send traffic to a 6to4
>    host.  Similarly, a 6to4 router that cannot reach the well-known IPv4
>    anycast relay address cannot send traffic to a native IPv6 network.
>    There are also potential issues with Protocol 41 filtering at site
>    borders close to the client.
> 
>    A presentation by Geoff Huston at IETF80 [Huston2011] highlighted the
>    connection failure rates with 6to4, measured in excess of 15%, as
>    well as the additional latency in 6to4 communications, with 6to4
>    showing an average additional 1.2s latency per retrieval.
> 
>    One approach to this problem is to encourage sites/ISPs to run local
>    relays, as discussed in [I-D.carpenter-v6ops-6to4-teredo-advisory].
> 
> 
> 
> Chown & Venaas          Expires October 21, 2011                [Page 4]
> Internet-Draft         World IPv6 Day Call to Arms            April 2011
> 
> 
>    This draft discusses how to make 6to4 more robust in situations where
>    there is a conscious decision to use it.  The alternative to reduce
>    such problems is simply to move 6to4 to Historic, as proposed in
>    [I-D.troan-v6ops-6to4-to-historic].  This would not necessarily kill
>    6to4 completely, but it would certainly send a strong signal that
>    6to4 should not be enabled by default.

This paragraph seems to be talking about options for the IETF whereas I would have expected options for network operators and sysadmins. How about something more along these lines?

Given the serious performance and reliability issues associated with 6to4, sites that use it are strongly encouraged to run local relays, as discussed in [I-D.carpenter-v6ops-6to4-teredo-advisory]. Alternatively, such performance and reliability issues can be mitigated by avoiding the use of 6to4 altogether as a means of accessing the IPv6 Internet.

> 
>    There may still be some CPE routers that do enable 6to4 by default;
>    it is likely that devices behind such routers will experience
>    problems on World IPv6 Day.

CPE firmware upgrades, where available, should be deployed in advance of the day.

[And here, it might be worth referencing http://getipv6.info/index.php/Customer_problems_that_could_occur which provides a lot of detail about specifically which CPE has known problems and whether upgrades are available to fix them]

> 
>    Connection failures and latency with the Teredo protocol [RFC4380]
>    were also highlighted by Geoff Huston's IETF80 presentation.  Teredo
>    connection failure rates were as high as 35%, with 1-3s additional
>    latency.  One of the connection issues is reliance on the ICMPv6
>    probe packet being able to reach the destination host; in practice
>    filters may block these.
> 

Can we draw any conclusion from that? How about:

Teredo should not be considered a reliable means of accessing the IPv6 Internet.

> 2.2.  Tunnel Broker first-hop delays
> 
>    IPv6 tunnel brokers, such as those provided by SixXS
>    (http://www.sixxs.net) and Hurricane Electric
>    (http://tunnelbroker.net) provide a more robust, managed approach to
>    IPv6-in-IPv4 tunnelled access than 6to4.  Individual users interested
>    in IPv6 access for World IPv6 Day, in the absence of IPv6 support
>    from their ISP, should consider registering to use a free tunnel
>    broker.  It would be sensible to register for and test your broker
>    client well in advance of IPv6 Day, and ideally plan to keep it
>    available beyond that date, until your ISP provides IPv6 natively for
>    you.
> 

You could reference http://isoc.org/wp/worldipv6day/ipv6-enabled-websites/ here as a potentially useful list of IPv6-enabled websites for tunnel broker users to test against. The formatting for that page is about to be improved as well.

>    When choosing a broker service, it is prudent to pick one with a
>    presence near to you that has a minimal round trip time.  Providers
>    such as SixXS and HE have tunnel broker servers in many countries.
>    Beware picking a broker in another continent that may add 150ms+ to
>    your round trip times.
> 
> 2.3.  Connection Timeouts
> 

Either right up front, or somewhere else in the section that follows it's important to make two points clearly I think:

1. Identifying and fixing the problems that lead to these timeouts is a major driver for World IPv6 Day
2. Because unreliable IPv6 connectivity leads to these intensely frustrating problems for end-users, it is essential that people motivated to deploy IPv6 connectivity, whether for themselves, or for a larger network, only do so in a well-supported, production-quality fashion.

>    Where dual-stack systems - or rather the applications running on them
>    - have a choice of IPv4 or IPv6 connectivity, timeouts can occur if
>    there is no connectivity on the preferred protocol.  For example, if
>    both A and AAAA DNS records exists for a web server, and IPv6
>    connectivity is broken, there is likely to be some timeout for the
>    browser before the connection drops back to IPv4.
> 
>    A bigger problem exists if the application or OS tries IPv6 first and
>    then does not fall back to IPv4.  A bug in versions of Opera prior to
> 
> 
> 
> Chown & Venaas          Expires October 21, 2011                [Page 5]
> Internet-Draft         World IPv6 Day Call to Arms            April 2011
> 
> 
>    10.5 caused such behaviour, which was obviously a big issue for Opera
>    users trying to access dual-stack web sites with broken IPv6
>    connectivity.
> 
>    The author has undertaken some informal tests at his own site, which
>    shows how different combinations of browsers and operating systems
>    behave in the event of IPv6 connections failing or when ICMP
>    unreachables are received.  On Linux/Firefox, web connections timeout
>    after 20 seconds for 'no response', but immediately for unreachables.
>    In contrast, Windows Vista/IE was 20 seconds regardless of
>    unreachables being received.  Any non-trivial delay will cause
>    significant user frustration.
> 
>    A more complete set of tests was run by Teemu Savolainen and reported
>    at IETF80 [Savolainen2011].  Although the tests were only samples,
>    they confirmed the results, also showing experiences across a much
>    broader range of platforms, and that the problems with Vista/IE are
>    repeated with Win 7/IE.  It's thus clear that if major content
>    providers enable IPv6 on World IPv6 Day, and end users for some
>    reason try to access the content with broken IPv6 connectivity, they
>    are likely to experience significant timeout issues.
> 
>    This problem is probably the main reason that Google implemented a
>    AAAA whitelisting system for its test sites.  The sites had to
>    demonstrate they had good IPv6 connectivity before being allowed into
>    the test programme.  The topic is discussed in
>    [I-D.ietf-v6ops-v6-aaaa-whitelisting-implications].  For the sake of
>    World IPv6 Day, it is expected that no such whitelisting is in place
>    - that is, after all, the point of having a day dedicated to testing
>    IPv6 in production.
> 
>    An interesting suggestion to handle the problem is the 'happy
>    eyeballs' approach described in [I-D.ietf-v6ops-happy-eyeballs].
>    This approach is now also being suggested for multiple interface
>    systems, as per [I-D.chen-mif-happy-eyeballs-extension].  The happy
>    eyeballs philosophy is to try both IPv4 and IPv6 together, and keep
>    the first working connection up, remembering the result for future
>    connection attempts.  It may prefer IPv6 slightly in initial
>    connections rather than trying connections exactly simultaneously.
>    It is an interesting approach, though some people are concerned about
>    the additional connection load, or that this 'workaround' is simply
>    masking underlying problems that should be fixed.
> 
> 2.4.  PMTU Discovery
> 
>    IPv6 mandates that fragmentation is only undertaken by the sending
>    node, and thus IPv6 requires working PMTU Discovery [RFC1981].  An
>    existing RFC gives Recommendations for Filtering ICMPv6 Messages in
> 
> 
> 
> Chown & Venaas          Expires October 21, 2011                [Page 6]
> Internet-Draft         World IPv6 Day Call to Arms            April 2011
> 
> 
>    Firewalls [RFC4890]; if this guidance is not followed, connectivity
>    problems are likely to arise.  Blindly filtering all ICMPv6 messages
>    is not good practise.

In setting up monitors for World IPv6 Day participants, I've been struck by the number of sites that filter inbound ICMP for 'security' or other reasons. That actually led me to consider writing a short I-D highlighting the importance of not adopting the same approach when dealing with ICMPv6, right before call-to-arms popped into my inbox ;)

Anyway, I wonder if the advice here needs to be beefed up a little. Probably won't have any impact on the real world, but might make me feel better...

Maybe just stating, 'Filtering ICMP is a common practice in some IPv4 networks today. Adopting the same approach to ICMPv6 when deploying IPv6 networks will cause connectivity issues for users of the network filtering ICMPv6 and hosts trying to reach the filtered network. RFC4890 is therefore an important document for IPv6 deployment engineers to read and it is similarly important to verify that IPv6 firewall deployments support appropriate configurations for ICMPv6 filtering.'

> 
>    The minimum MTU for IPv6 is 1280 bytes.  Where PMTUD is not working
>    or not implemented, the minimum MTU should be used.

This could be further emphasised: When IPv6 connectivity issues arise, one of the first things to check is the MTU. In many cases, reducing MTU to the minimum will resolve the problem.

>  Tunnel broker
>    services such as SixXS and HE set their MTUs to default to 1280,
>    probably due to the varying conditions their customers may be in.
>    However, it is preferable for enterprise networks to configure
>    appropriate ICMPv6 filtering to allow PMTUD to operate and establish
>    the most efficient MTUs for a link.
> 
> 2.5.  Rogue Router Advertisements
> 
>    Within a site, hosts may use IPv6 Stateless Address Autoconfiguration
>    (SLAAC) [RFC4862].  However, it is possible for accidental (or
>    malicious) rogue RAs to cause connectivity issues, as described in
>    the Rogue Router Advertisement Problem Statement [RFC6104].
> 
>    A typical cause of rogue RAs is Windows ICS, which can present a
>    rogue 6to4 router on its wireless interface.  This will cause hosts
>    to potentially autoconfigure two global IPv6 addresses and pick the
>    wrong default router, with unpredictable results.  As a (bad) example
>    the author experienced a scenario where he had a rogue 6to4 RA, but
>    because the rogue 6to4 was working he was able to access IPv6
>    networks outside his own network, but could not access most internal
>    hosts inside his own network because he was unwittingly using 6to4
>    from outside into his own network, and thus being firewalled from
>    those internal hosts.
> 
>    In many cases, default address selection [RFC3484] (and
>    [I-D.ietf-6man-rfc3484-revise]) would avoid such cases, because the
>    address selection rules should prefer, or can be configured to
>    prefer, native IPv6 over 6to4.  However not all operating systems
>    implement RFC 3484 yet, in particular MacOS X (though support may be
>    appearing in Lion).  Where rogue RAs cause broken IPv6 behaviour, the
>    timeout issues discussed above may apply.
> 
>    Adding ACLs to your switches to block ICMPv6 Type 134 packets on
>    ports that do not have routers connected would also minimise the
>    impact of rogue RAs.  A more elegant solution is RA Guard [RFC6105],
>    and another is use of SEcure Neighbour Discovery (SEND) [RFC3971].
>    However neither is widely implemented yet.  Indeed, any reported
>    operational experience of SEND in an enterprise network would be very
>    welcome.
> 
>    Finally, there is a tool called RAmond, available freely from
>    http://ramond.sourceforge.net, that can be configured to detect and
> 
> 
> 
> Chown & Venaas          Expires October 21, 2011                [Page 7]
> Internet-Draft         World IPv6 Day Call to Arms            April 2011
> 
> 
>    issue deprecating RAs against observed rogue RAs.  This software is
>    based on rafixd.
> 
> 2.6.  Tunnel performance
> 
>    In scenarios where sites currently have manually configured tunnels
>    to gain IPv6 connectivity, it may be the case that such encapsulation
>    is performed by a router's CPU, in which case unexpected high volumes
>    of traffic may cause problems.  Bear in mind that on World IPv6 Day,
>    you may start using IPv6 by default for some high bandwidth
>    applications that you had not used before, e.g.  YouTube from Google.
>    It may be prudent to estimate your load for such applications in
>    advance, and test the capability of your tunnelling solution to
>    handle that load.
> 
> 2.7.  AAAA record advertised but service not enabled
> 
>    If enabling a service for World IPv6 Day, be aware of other existing
>    services that may be running on the same system.  If a server has
>    multiple functions, all services should be IPv6 enabled before a AAAA
>    record is entered into the DNS for services that may use that name.
> 
>    A related consideration is to make sure that firewalls don't just
>    drop IPv6 packets to ports that are not in use.  It's better if the
>    firewall or host sends an unreachable indication or a TCP RST to
>    avoid a potential timeout.  For example, if you add a AAAA record for
>    your web server that also runs say FTP, where FTP is IPv4 only,
>    either the firewall should have port 21 open or the firewall should
>    be configured ta send a TCP RST.  There are of course tradeoffs in
>    enabling ICMP unreachables.

Can these tradeoffs be mentioned explicitly?

> 
> 
> 3.  Instrumentation
> 
>    In this section we discuss potential instrumentation approaches that
>    may be configured in advance of World IPv6 Day, and then retained
>    longer term after the event.  These are particularly useful if your
>    site is turning on AAAA records for its production web presence (for
>    example) and wants to get the best insight into how the systems
>    performed and the nature of the end user experience.
> 
>    These measurements should complement informal, subjective reports
>    from users at participating sites.  It is probably prudent to make at
>    least your organisation's IT staff aware of the 'at risk' day, and
>    actions they should take should the experience problems.  It may also

s/should the/should they

Again, a reference to http://getipv6.info/index.php/Customer_problems_that_could_occur would be of value here I think as it provides a lot of detailed information that support staff could use in advance of the day to develop their support strategy.

>    be desirable to undertake some form of user survey soon afterwards;
>    whether you inform general users in advance is an issue for each
>    site.
> 
> 
> 
> Chown & Venaas          Expires October 21, 2011                [Page 8]
> Internet-Draft         World IPv6 Day Call to Arms            April 2011
> 
> 
> 3.1.  IPv6 traffic levels
> 
>    It should be possible to measure raw IPv6 traffic levels
>    independently on dual-stack switch/router platforms, given
>    implementations of appropriate MIBs.  Sites should take steps to
>    ensure they have the tools in place to be able to view the relative
>    levels of IPv4 and IPv6 traffic over time.
> 
>    Application level measurement is also desirable, because handling of
>    choice (preference) of protocol used lies with the application if
>    both A and AAAA records are returned.  Sites should be aware that due
>    to IPv6 Privacy Extensions [RFC4941] application logs may show more
>    apparent different clients connecting, due to clients cycling the
>    source IPv6 address they use over time.
> 

I think you've combined three distinct measurements into one section here, and it might be helpful to break them out:

1. IPv6 traffic volume, sources of IPv6 traffic by AS, types of IPv6 traffic (e.g. native, 6to4, Teredo, tunnelled)
2. IPv6 application mix, comparison with IPv4
3. Number and type of IPv6 client connections

> 3.2.  Network flow records
> 
>    Where available, sites should seek to deploy network flow records for

I think 'deploy' needs to be unpacked. You're actually recommending sites generate and record these records, yes? So let's say that: Where available, sites should seek to generate and record network flow records...

>    traffic, to maximise opportunities to analyse traffic patterns after
>    the event, or in the case of reports of specific problems.  Netflow
>    v9 supports IPv6.  Open source IPv6-capable Netflow collectors also
>    exist, e.g. nfsen, from http://nfsen.sourceforge.net.
> 
> 3.3.  Client Web Access Success Rate
> 
>    There have been some recent studies on the capabilities of web
>    clients to access content on dual-stack servers by IPv4 or IPv6 in
>    the presence of both A and AAAA records existing for a web domain.
> 
>    One good example is that of [Anderson10], as reported at RIPE-61,
>    where the author set up some application (web server) oriented tests
>    for his newspaper content in Norway.  The methodology was to add an
>    invisible IFRAME to his site that would include IMG links randomly to
>    1x1 images that were served either via an IPv4-only target or a dual-
>    stack target.  Variation in the hit rates would imply IPv6
>    brokenness.  By analysing the http metadata information could be
>    gleaned on the cause of the brokenness.  Results in Q4'2009 showed
>    0.2-0.3% brokenness, including the Opera bug mentioned above.
> 
>    Recent figures published by Google suggest at most a 0.1% level of
>    brokenness, indicating some improvement, but that level is still
>    potentially 1 in 1000 users with a problem.
> 
> 3.4.  Tools to measure IPv6 brokenness

This seems like a continuation of §3.3, or maybe a subsection. §3.3 is an introduction to work on measuring web client brokenness, now we're going to discuss creating your own measurements.

> 
>    Sites may wish to make their own measurements of IPv6 brokenness
>    rather than relying on third party reports.  There are some openly
>    available tools available that work along similar principles to the
> 
> 
> 
> Chown & Venaas          Expires October 21, 2011                [Page 9]
> Internet-Draft         World IPv6 Day Call to Arms            April 2011
> 
> 
>    method proposed by Tore Anderson above.
> 

I think it's important to note here that you can't measure brokenness once you have enabled dual-stack service for a site. So, for content providers planning to enable IPv6 access on the day, the interesting measurements are comparisons of brokenness before and after World IPv6 Day to explore whether the event helped spur the actions needed to reduce brokenness. 

>    The APNIC Labs test tool uses a combination of JavaScript and Google
>    Analytics to measure various types of brokenness [APNIC].  Eric
>    Vyncke's tool [Vyncke] measures a slightly smaller set of types of
>    brokenness, but also looks very useful, with additional reports on
>    the browser type for each failure.  The author is currently using the
>    latter tool, and plans to enable the APNIC measurement system shortly
>    when other Analytics updates are applied locally.
> 
> 3.5.  IPv4 Performance Comparison
> 
>    Where a dual-stack service is deployed, measuring the relative
>    performance of both protocols is desirable.  This may primarily be a
>    measurement of throughput or delay, but may also include
>    availability/uptime measurement.  A site may choose to set up its own
>    performance measuring framework, for example using open source
>    bandwidth and throughput test tools.
> 

Here you might add: 'Participants in World IPv6 Day will be monitored from a broad range of locations and measurements will be available to show availability of AAAA records, reachability to http service, latency and availability over time.'

> 3.6.  User Tickets
> 
>    It is possible a higher than usual user ticket rate for connectivity
>    issues may be experienced. being able to categorise these cases for
>    subsequent analysis is desirable.
> 
> 3.7.  Security monitoring
> 
>    We mentioned RAmond above in the context of watching for rogue RAs.
>    There is another useful package called NDPmon, also available freely
>    from http://ndpmon.sourceforge.net, that can be configured to watch
>    for certain types of IPv6 'abuse' on your local network.  It may be
>    interesting to run the tool to confirm whether any 'bad' traffic is
>    observed within your network on World IPv6 Day.
> 
> 
> 4.  IPv6-only testing
> 
>    The long-term IPv6 deployment plan is IPv6-only networking, rather
>    than dual-stack.  It is not clear how quickly significant IPv6-only
>    networks will emerge, but testing of approaches to IPv6-only
>    operation is desirable as soon as possible.
> 

A reference to draft-arkko-ipv6-only-experience would be helpful here I think.

>    Some experience of NAT64 [I-D.ietf-behave-v6v4-xlate-stateful] has
>    been described in [I-D.tan-v6ops-nat64-experiences], though this
>    appears to have used only NAT-PT so far.  An implementation of NAT64
>    is available at http://ecdysis.viagenie.ca.  Operational experience
>    of IVI is also desirable.  An implementation of IVI is available at
>    http://www.ivi2.org/IVI.
> 
> 
> 
> Chown & Venaas          Expires October 21, 2011               [Page 10]
> Internet-Draft         World IPv6 Day Call to Arms            April 2011
> 
> 
> 5.  Conclusions
> 
>    With the ISOC World IPv6 Day event due on June 8th 2011, this
>    document aims to help focus attention on both improving awareness and
>    mitigations of common causes of IPv6 connectivity problems, and
>    encouraging sites and organisations to introduce appropriate
>    instrumentation into their networks so they can observe traffic
>    behaviour appropriately.
> 
>    This is still an early version of the text, and is thus a little
>    drafty.  All comments are very welcome towards a mature version in
>    advance of June.
> 
> 
> 6.  Security Considerations
> 
>    There are no extra security consideration for this document.
> 
> 
> 7.  IANA Considerations
> 
>    There are no extra IANA consideration for this document.
> 
> 
> 8.  Acknowledgments
> 
>    To be added.
> 
> 
> 9.  Informative References
> 
>    [RFC1981]  McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
>               for IP version 6", RFC 1981, August 1996.
> 
>    [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
>               via IPv4 Clouds", RFC 3056, February 2001.
> 
>    [RFC3068]  Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
>               RFC 3068, June 2001.
> 
>    [RFC3484]  Draves, R., "Default Address Selection for Internet
>               Protocol version 6 (IPv6)", RFC 3484, February 2003.
> 
>    [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
>               Neighbor Discovery (SEND)", RFC 3971, March 2005.
> 
>    [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
>               Network Address Translations (NATs)", RFC 4380,
> 
> 
> 
> Chown & Venaas          Expires October 21, 2011               [Page 11]
> Internet-Draft         World IPv6 Day Call to Arms            April 2011
> 
> 
>               February 2006.
> 
>    [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
>               Address Autoconfiguration", RFC 4862, September 2007.
> 
>    [RFC4890]  Davies, E. and J. Mohacsi, "Recommendations for Filtering
>               ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
> 
>    [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
>               Extensions for Stateless Address Autoconfiguration in
>               IPv6", RFC 4941, September 2007.
> 
>    [RFC6104]  Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement
>               Problem Statement", RFC 6104, February 2011.
> 
>    [RFC6105]  Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
>               Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
>               February 2011.
> 
>    [I-D.carpenter-v6ops-6to4-teredo-advisory]
>               Carpenter, B., "Advisory Guidelines for 6to4 Deployment",
>               draft-carpenter-v6ops-6to4-teredo-advisory-03 (work in
>               progress), March 2011.
> 
>    [I-D.ietf-v6ops-happy-eyeballs]
>               Wing, D. and A. Yourtchenko, "Happy Eyeballs: Trending
>               Towards Success with Dual-Stack Hosts",
>               draft-ietf-v6ops-happy-eyeballs-01 (work in progress),
>               March 2011.
> 
>    [I-D.tan-v6ops-nat64-experiences]
>               Tan, J., Lin, J., and W. Li, "Experience from NAT64
>               applications", draft-tan-v6ops-nat64-experiences-00 (work
>               in progress), March 2011.
> 
>    [I-D.troan-v6ops-6to4-to-historic]
>               Troan, O., "Request to move Connection of IPv6 Domains via
>               IPv4 Clouds (6to4) to Historic status",
>               draft-troan-v6ops-6to4-to-historic-01 (work in progress),
>               March 2011.
> 
>    [I-D.ietf-v6ops-v6-aaaa-whitelisting-implications]
>               Livingood, J., "IPv6 AAAA DNS Whitelisting Implications",
>               draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
>               (work in progress), February 2011.
> 
>    [I-D.chen-mif-happy-eyeballs-extension]
>               Chen, G. and C. Williams, "Happy Eyeballs Extension for
> 
> 
> 
> Chown & Venaas          Expires October 21, 2011               [Page 12]
> Internet-Draft         World IPv6 Day Call to Arms            April 2011
> 
> 
>               Multiple Interfaces",
>               draft-chen-mif-happy-eyeballs-extension-01 (work in
>               progress), March 2011.
> 
>    [I-D.ietf-6man-rfc3484-revise]
>               Matsumoto, A., Kato, J., and T. Fujisaki, "Update to RFC
>               3484 Default Address Selection for IPv6",
>               draft-ietf-6man-rfc3484-revise-02 (work in progress),
>               March 2011.
> 
>    [I-D.ietf-behave-v6v4-xlate-stateful]
>               Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
>               NAT64: Network Address and Protocol Translation from IPv6
>               Clients to IPv4 Servers",
>               draft-ietf-behave-v6v4-xlate-stateful-12 (work in
>               progress), July 2010.
> 
>    [APNIC]    "IPv6 Capability Tracker", <http://labs.apnic.net/>.
> 
>    [Vyncke]   Vyncke, E., "Estimation of IPv6 brokenness",
>               <http://test4.vyncke.org/testv6/>.
> 
>    [ISOC]     "World IPv6 Day", <http://isoc.org/wp/worldipv6day/>.
> 
>    [Huston2011]
>               Huston, G., "Stacking it Up: Experimental Observations on
>               the operation of Dual Stack Services", 2011,
>               <http://www.ietf.org/proceedings/80/slides/v6ops-1.pdf>.
> 
>    [Savolainen2011]
>               Savolainen, T., "Experiences of host behaviour in broken
>               IPv6 networks", 2011,
>               <http://www.ietf.org/proceedings/80/slides/v6ops-12.pdf>.
> 
>    [Anderson10]
>               Anderson, T., "Measuring and Combating IPv6 Brokenness",
>               2010,
>               <http://ripe61.ripe.net/presentations/162-ripe61.pdf>.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Chown & Venaas          Expires October 21, 2011               [Page 13]
> Internet-Draft         World IPv6 Day Call to Arms            April 2011
> 
> 
> Authors' Addresses
> 
>    Tim Chown
>    University of Southampton
>    Highfield
>    Southampton, Hampshire  SO17 1BJ
>    United Kingdom
> 
>    Email: [e-mail]
> 
> 
>    Stig Venaas
>    Cisco Systems
>    Tasman Drive
>    San Jose, CA  95134
>    USA
> 
>    Email: [e-mail]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Chown & Venaas          Expires October 21, 2011               [Page 14]
>