<?xml version="1.0" encoding="UTF-8"?>

<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

 <!ENTITY rfc1981  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1981.xml'>

 <!ENTITY rfc3056  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3056.xml'>

 <!ENTITY rfc3068  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3068.xml'>

 <!ENTITY rfc3484  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3484.xml'>

 <!ENTITY rfc3971  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3971.xml'>

 <!ENTITY rfc4380  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4380.xml'>

 <!ENTITY rfc4862  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml'>

 <!ENTITY rfc4890  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4890.xml'>

 <!ENTITY rfc4941  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4941.xml'>

 <!ENTITY rfc6104  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6104.xml'>

 <!ENTITY rfc6105  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6105.xml'>

 <!ENTITY rfc6146  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6146.xml'>


<!ENTITY I-D.arkko-ipv6-only-experience
	PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.arkko-ipv6-only-experience.xml'>

<!ENTITY I-D.carpenter-v6ops-6to4-teredo-advisory
	PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.carpenter-v6ops-6to4-teredo-advisory.xml'>

<!ENTITY I-D.ietf-6man-rfc3484-revise
	PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-rfc3484-revise.xml'>

<!ENTITY I-D.ietf-v6ops-happy-eyeballs
	PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-happy-eyeballs.xml'>

<!ENTITY I-D.tan-v6ops-nat64-experiences
	PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.tan-v6ops-nat64-experiences.xml'>

<!ENTITY I-D.troan-v6ops-6to4-to-historic
	PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.troan-v6ops-6to4-to-historic.xml'>

<!ENTITY I-D.chen-mif-happy-eyeballs-extension
	PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.chen-mif-happy-eyeballs-extension.xml'>

<!ENTITY I-D.ietf-v6ops-v6-aaaa-whitelisting-implications
	PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-v6-aaaa-whitelisting-implications.xml'>


]>

<rfc ipr="trust200902" category="info" docName="draft-chown-v6ops-call-to-arms-03">
	<front>
		<title abbrev="World IPv6 Day Call to Arms">World IPv6 Day Call to Arms</title>
		<author fullname="Tim Chown" initials="T.J." surname="Chown">
			<organization> University of Southampton </organization>
			<address>
				<postal>
					<street> Highfield </street>
					<city> Southampton </city>
					<code> SO17 1BJ </code>
					<region> Hampshire </region>
					<country> United Kingdom </country>
				</postal>
				<email> tjc@ecs.soton.ac.uk </email>
			</address>
		</author>

		<author initials='M.' surname='Ford' fullname='Mat Ford'>
   			<organization>Internet Society</organization>
   			<address><postal>
       			<street></street>
   			<city>Geneva</city> <region></region>
   			<code></code>
   			<country>Switzerland</country>
     			</postal>
     			<email>ford@isoc.org</email></address>
 		</author>  
		<author initials='S.' surname='Venaas' fullname='Stig Venaas'>
   			<organization>Cisco Systems</organization>
   			<address><postal>
       			<street>Tasman Drive</street>
   			<city>San Jose</city> <region>CA</region>
   			<code>95134</code>
   			<country>USA</country>
     			</postal>
     			<email>stig@cisco.com</email></address>
 		</author>  

		<date month="June" year="2011"/>
		<area>Operations</area>
		<workgroup>IPv6 Operations</workgroup>
		<abstract>
<t>
The Internet Society (ISOC) has declared that June 8th 2011 will be
World IPv6 Day, on which some major organisations are going to make their
content available over IPv6.  With the likes of Google and Facebook 
providing IPv6 access to their production services and domains, it is
very likely we will see more IPv6 traffic flowing across the Internet than 
has ever been seen before.  With this in mind, it seems timely to issue 
a call to arms for systems and network administrators to review their 
organisation's IPv6 capabilities in order to mitigate common causes of 
IPv6 connectivity problems in advance of the day.   The increased traffic 
on World IPv6 Day should also create an excellent opportunity to observe 
the behaviour and performance of IPv6; it is thus very desirable to have 
appropriate measurement tools in place in advance.   We discuss some 
appropriate tools from the network and application perspective.
</t>
		</abstract>
	</front>
	<middle>

<section title="Introduction">
	<t>
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 <xref target="ISOC"/>.
Organisations are encouraged to use this day to test IPv6 in production 
by making their main, externally-facing websites available over IPv6.
Sites planning to turn on IPv6 for access in their network in the 
interest of World IPv6 Day should ensure this is completed well before 
the day, and commit to leaving it active after the event, and thus
using the method they would choose to do so indefinitely.
At the current time, this would generally mean enabling dual-stack 
networking with IPv4 running alongside IPv6.  However, IPv6-only 
networks are ultimately inevitable, and so some sites may choose to use 
June 8th to undertake some focused tests on that deployment model.
	</t>
	<t>
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.
	</t>
	<t>
For 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. 
For ISPs, supporting IPv6 for their Internet-facing services (web, mail, 
etc.) and recording the impact of World IPv6 Day on their IPv4-only
customers is an appropriate action.
For sites enabling clients, doing so initially 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.
	</t>
	<t>
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 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.
	</t>
	<t>
The document also includes a brief section on tools that might be used to 
test IPv6-only operation.  
	</t>
	<t>
The scope of this document is purely informational to provoke discussion.  
	</t>
</section>

<section title="Connectivity Issues">
	<t>
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. Some IPv6 connectivity test sites are
emerging, for example <xref target="testipv6"/>.

There is no significance to the order in which issues are listed.
	</t>

<section title="Unmanaged Tunnels">
	<t>
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 <xref target="RFC3056"/>,
or more specifically the 6to4 relay approach described in 
<xref target="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.
	</t>
	<t>
A presentation by Geoff Huston at IETF80 <xref target="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.
	</t>
	<t>
One approach to this problem is to encourage sites/ISPs to run local
relays, as discussed in
<xref target="I-D.carpenter-v6ops-6to4-teredo-advisory"/>.  This draft
discusses how to make 6to4 more robust in situations where there is a
conscious decision to use it.  Sites using 6to4 should consider deploying
local relays to increase the chance of a good IPv6 experience.  The
alternative to reduce such problems is simply to move 6to4 to Historic, as
proposed in 
<xref target="I-D.troan-v6ops-6to4-to-historic"/>.  This would mean 6to4
would not be enabled by default anywhere, and once its usage had reduced
enough, relays could be turned off.
	</t>
	<t>
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.
	</t>
	<t>
Connection failures and latency with the Teredo protocol 
<xref target="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. Thus Teredo should not be considered
a reliable means of accessing the IPv6 Internet.
	</t>
</section>

<section title="Tunnel Broker first-hop delays">
	<t>
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.  One set of test sites to use would be the list cited on the
ISOC World IPv6 Day site <xref target="ISOCsites"/>.
	</t>
	<t>
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.
	</t>
</section>

<section title="Connection Timeouts">
	<t>
One of the main drivers for IPv6 Day is identifying and fixing the 
problems that can lead to connection timeouts.
Because unreliable IPv6 connectivity leads to 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.
	</t>
	<t>
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.   
	</t>
	<t>
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 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.
	</t>
	<t>
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.
	</t>
	<t>
A more complete set of tests was run by Teemu Savolainen and reported at
IETF80 <xref target="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.
	</t>
	<t>
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
<xref target="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.
	</t>
	<t>
An interesting suggestion to handle the problem is the 'happy eyeballs'
approach described in <xref target="I-D.ietf-v6ops-happy-eyeballs"/>.
This approach is now also being suggested for multiple interface
systems, as per <xref target="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.
	</t>
</section>

<section title="PMTU Discovery">
	<t>
IPv6 mandates that fragmentation is only undertaken by the sending node,
and thus IPv6 requires working PMTU Discovery <xref target="RFC1981"/>.  
An existing RFC gives Recommendations for Filtering ICMPv6 Messages in
Firewalls <xref target="RFC4890"/>; if this guidance is not followed,
connectivity problems are likely to arise.  Blindly filtering all
ICMPv6 messages is not good practise.   
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. RFC 4890 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.
	</t>
	<t>
The minimum MTU for IPv6 is 1280 bytes.  Checking the MTU is an
important step when connectivity issues arise.  Where PMTUD is not working 
or not implemented, the using the minimum MTU is likely to resolve the
problem, though not give optimal performance (the cause should still be
investigated and resolved for longer term benefit).  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.
	</t>
</section>

<section title="Rogue Router Advertisements">
	<t>
Within a site, hosts may use IPv6 Stateless Address Autoconfiguration
(SLAAC) <xref target="RFC4862"/>.   However, it is possible for 
accidental (or malicious) rogue RAs to cause connectivity issues, 
as described in the Rogue Router Advertisement Problem Statement 
<xref target="RFC6104"/>.   
	</t>
	<t>
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.  
	</t>
	<t>
In many cases, default address selection <xref target="RFC3484"/>
(and <xref target="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.
	</t>
	<t>
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 <xref target="RFC6105"/>, and
another is use of SEcure Neighbour Discovery (SEND) <xref target="RFC3971"/>.
However neither is widely implemented yet.  Indeed, any
reported operational experience of SEND in an enterprise network
would be very welcome.
	</t>
	<t>
Finally, there is a tool called RAmond, available freely from
http://ramond.sourceforge.net, that can be configured to detect and
issue deprecating RAs against observed rogue RAs.   This software
is based on rafixd.
	</t>
</section>

<section title="Tunnel performance">
	<t>
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.
	</t>
</section>

<section title="AAAA record advertised but service not enabled">
	<t>
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.  
	</t>
	<t>
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.
	</t>
</section>

<section title="IPv6 Reverse DNS">
	<t>
Presence of IPv6 reverse DNS records is used by many systems as a
security method.  For example, many mail exchangers will only accept
SMTP connections from IP addresses with a reverse DNS entry.  It is
thus important for such records to exist where, for example, a site
is sending mail out over IPv6 transport.  It is not necessarily the
case that such connections will fall back to IPv4 if reverse records
are not present.
	</t>
</section>

</section>



<section title="Instrumentation">
	<t>
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.
	</t>
	<t>
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 they experience problems.   It may also 
be desirable to undertake some form of user survey soon afterwards; 
whether you inform general users in advance is an issue for each site.
The ARIN IPv6 wiki is a good source of such advice <xref target="ARINwiki"/>.
	</t>

<section title="IPv6 traffic levels">
	<t>
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.
	</t>
	<t>
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 <xref target="RFC4941"/> application
logs may show more apparent different clients connecting, due to
clients cycling the source IPv6 address they use over time.
	</t>
	<t>
The types of information gathered might for example include:
<list style="symbols">
<t>IPv6 traffic volume, sources of IPv6 traffic by AS, types of IPv6 
traffic (e.g. native, 6to4, Teredo, tunnelled);</t>
<t>IPv6 application mix, comparison with IPv4;</t>
<t>The number and type of IPv6 client connections.</t>
</list>
	</t>
</section>

<section title="Network flow records">
	<t>
Where available, sites should seek to generate and record 
network flow records for
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.
	</t>
</section>

<section title="Client Web Access Success Rate">
	<t>
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.   
	</t>
	<t>
One good example is that of <xref target="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.
	</t>
	<t>
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.   
	</t>
</section>

<section title="Tools to measure IPv6 brokenness">
	<t>
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 method 
proposed by Tore Anderson above.
	</t>
	<t>
The APNIC Labs test tool uses a combination of JavaScript and Google
Analytics to measure various types of brokenness <xref target="APNIC"/>.
Eric Vyncke's tool <xref target="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.
	</t>
</section>

<section title="IPv4 Performance Comparison">
	<t>
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.
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.
	</t>
</section>

<section title="User Tickets">
	<t>
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.
	</t>
</section>

<section title="Security monitoring">
	<t>
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.
	</t>
</section>

</section>


<section title="IPv6-only testing">
	<t>
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 draft by Jari Arkko and Ari Keranen
describes some
such experiences <xref target="I-D.arkko-ipv6-only-experience"/>.
	</t>
	<t>
Some experience of NAT64 
<xref target="RFC6146"/>
has been described in
<xref target="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.
	</t>
</section>


<section anchor="Conclusions" title="Conclusions">
	<t>
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.   
	</t>
	<t>
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.
	</t>

</section>

<section anchor="Security" title="Security Considerations">
	<t>
There are no extra security consideration for this document.
	</t>
</section>

<section anchor="IANA" title="IANA Considerations">
	<t>
There are no extra IANA consideration for this document.
	</t>
</section>

<section anchor="Acknowledgments" title="Acknowledgments">
	<t>
To be added.
	</t>
</section>


</middle>
<back>

<references title="Informative References">

	&rfc1981;
	&rfc3056;
	&rfc3068;
	&rfc3484;
	&rfc3971;
	&rfc4380;
	&rfc4862;
	&rfc4890;
	&rfc4941;
	&rfc6104;
	&rfc6105;
	&rfc6146;
	&I-D.carpenter-v6ops-6to4-teredo-advisory;
	&I-D.ietf-v6ops-happy-eyeballs;
	&I-D.tan-v6ops-nat64-experiences;
	&I-D.troan-v6ops-6to4-to-historic;
	&I-D.ietf-v6ops-v6-aaaa-whitelisting-implications;
	&I-D.chen-mif-happy-eyeballs-extension;
	&I-D.ietf-6man-rfc3484-revise;
	&I-D.arkko-ipv6-only-experience;

	<reference anchor='APNIC' target="http://labs.apnic.net/">
	<front>
	<title>IPv6 Capability Tracker</title> 
	<author initials="" surname="" fullname="">
	<organization /> 
	</author>
	<date year="" /> 
        </front>
	</reference>

	<reference anchor='Vyncke' target="http://test4.vyncke.org/testv6/">
	<front>
	<title>Estimation of IPv6 brokenness</title> 
	<author initials="E." surname="Vyncke" fullname="Eric Vyncke">
	<organization /> 
	</author>
	<date year="" /> 
        </front>
	</reference>

	<reference anchor='ARINwiki' target="http://getipv6.info/index.php/Customer_problems_that_could_occur">
	<front>
	<title>ARIN IPv6 Wiki</title> 
	<author initials="" surname="" fullname="">
	<organization /> 
	</author>
	<date year="" /> 
        </front>
	</reference>

	<reference anchor='testipv6' target="http://www.test-ipv6.com/">
	<front>
	<title>Test IPv6</title> 
	<author initials="" surname="" fullname="">
	<organization /> 
	</author>
	<date year="" /> 
        </front>
	</reference>

	<reference anchor='ISOC' target="http://isoc.org/wp/worldipv6day/">
	<front>
	<title>World IPv6 Day</title> 
	<author initials="" surname="" fullname="">
	<organization /> 
	</author>
	<date year="" /> 
        </front>
	</reference>

	<reference anchor='Huston2011' target="http://www.ietf.org/proceedings/80/slides/v6ops-1.pdf">
	<front>
	<title>Stacking it Up: Experimental Observations on the operation of Dual Stack Services</title> 
	<author initials="G." surname="Huston" fullname="Geoff Huston">
	<organization /> 
	</author>
	<date year="2011" /> 
        </front>
	</reference>

	<reference anchor='Savolainen2011' target="http://www.ietf.org/proceedings/80/slides/v6ops-12.pdf">
	<front>
	<title>Experiences of host behaviour in broken IPv6 networks</title> 
	<author initials="T." surname="Savolainen" fullname="Teemu Savolainen">
	<organization /> 
	</author>
	<date year="2011" /> 
        </front>
	</reference>

	<reference anchor='ISOCsites' target="http://www.worldipv6day.org/ipv6-enabled-websites">
	<front>
	<title>IPv6 Enabled Websites</title> 
	<author initials="" surname="" fullname="">
	<organization /> 
	</author>
	<date year="" /> 
        </front>
	</reference>

	<reference anchor='Anderson10' target="http://ripe61.ripe.net/presentations/162-ripe61.pdf">
	<front>
	<title>Measuring and Combating IPv6 Brokenness</title> 
	<author initials="T." surname="Anderson" fullname="Tore Anderson">
	<organization /> 
	</author>
	<date year="2010" /> 
        </front>
	</reference>

</references>
	</back>
</rfc>
