Usage of Teredo and IPv6 for P2P on Windows 10 and Xbox One

Hi Everyone -

We've had very fruitful discussions with members of this community on Xbox One networking behavior, in particular concerning P2P multiplayer gaming activity. In an effort to continue that useful dialogue, we wanted to provide an informational update for Xbox One, but also share relevant details on upcoming Windows functionality in terms of Teredo and IPv6 usage. We also include some observations about IPv4 and IPv6 health that may be broadly interesting, especially as it pertains to network readiness for Xbox multiplayer via IPv6.

New Xbox experiences launching on Windows 10 will use Teredo for P2P communications

IPv6 is being deployed, but not perfectly, jeopardizing IPv6 P2P
Across the Xbox One customer base, in particular for customers who play multiplayer games, we observe that a substantial minority (around 20%) of devices have native IPv6 configured. This represents a much higher IPv6 penetration rate than Microsoft's other products and services report, as well as public data from other sources.

However we have numerous concerns about IPv6's growth. We are often finding that retail customer premise equipment is configured with IPv6 disabled by default, requiring user action to enable.

  I'm curious how this compares with how the xbox live breaks
with "xbox strict nat" which has been quite catastrophic for users
in IPv4 land that may sit behind one or more cascaded NATs where
UPnP is not available or may trigger the wrong tier. (This is more
common in areas where access is via WISP).

  That seems to be a long unaddressed or rejected problem
from the customer perspective.

We've also encountered a very small set of reports where IPv6 latency and bandwidth performance are suboptimal compared to IPv4. Reports of this nature have usually focused on streaming media experiences and user concern that IPv6 is slower than IPv4 (i.e. "I get 1080P resolution with IPv4, and 720P with IPv6"). In the rare cases where these reports have been substantiated, the primary culprit has been differences in deployed CDN support.

  This is not Microsofts problem unless you are contracting with the
CDN. The CDN should address this gap by placing devices on network that
can properly dual-stack only. IPv6 for those last-mile-networks has
been a solved problem for quite some time.

Also, some networking hardware and operators apply firewall policy to the IPv6 path contrary to RFC 6092 recommendations. Of particular concern are configurations where unsolicited inbound IKE/IPsec traffic is not permitted in the default operating mode. Growth of these non-conformant configurations puts the P2P benefit of the next generation Internet in jeopardy. It would be incredibly regrettable if IPv6 necessitated the high level of configuration and inefficiency currently required for IPv4.

  Many self-appointed IT experts have shot themselves in the foot
in this regard. After 5+ years of trying to get sensible pMTU working
inside an organization, or get IPv6 there people need to undertake other
methods to address these shortcomings. Stateful inspection devices
(or packet eaters as I call them) improperly generate spurious warnings
when they are presented with data they don't understand or expect.

  Take a look at what happened when the Linux kernel made TCP-ECN
the default, many firewalls blocked a perfectly valid TCP option and
broke large number of mail servers. 20 years ago it would be feasible
to shame these people into upgrading or standards compliance, but the
race to be the worst continues.

Deprecating public Teredo servers for Windows Vista and Windows 7
On May 4th, 2015, we began deactivating Microsoft's publicly available Teredo servers currently configured as the default servers for Windows Vista and Windows 7 clients. This is a result of limited usage on those platforms and our desire to focus our operations on Xbox One and Windows 10.

If you read this far, you are awesome.

We will likely request a NANOG presentation slot later in the year to discuss these points, but we want to make sure we have sufficiently interesting and new things to discuss before swallowing up people's time.

  If you can keep the content in ~10 minutes, a lightning talk may
still fit for the upcoming NANOG.

Network operators and CPE manufactures are encouraged to reach out to our team at with operational questions. Please note that our most common reply will be "better documentation is coming later in the year," but we will try our best to respond to questions quickly.

  Is there a good way to contact CPE vendors about issues? I have
a large dataset showing how bad they are at various things, including
responding with REFUSED for valid rfc1035 complaint DNS packets breaking
customer experiences in nasty ways. I have large datasets I'm
willing to share showing the information discloure your home CPE performs
due to poorly coded dnsmasq, iptables and other defaults on these devices
which are never updated/maintained.

  I've been looking for a research team that has the time
to undertake this effort of documenting things and pushing for broad
scale recommendations and fixes.

  With the desires of the homenet WG at IETF to make the
complex layers of networks even harder to address, we need to fix
the vendors sooner vs later otherwise the pollution will get worse.

  - Jared

And they also eat DNS packets with "unexpected" DNS opcodes.
They eat DNS packets with EDNS version != 0.
They eat DNS packets with a EDNS flag set that is not DO.
They eat DNS packets with EDNS options (less so than EDNS version != 0
or EDNS flag).

Different != bad. Different != malformed. Different should not equal drop.

Nameservers return NOTIMP (RFC 103[45]), BADVER or ignore and ignore
(RFC 6891) respectively. There are no valid reasons to stop any
of these extensions getting through to the nameserver as they handle
them. 25 years ago blocking these may have been "reasonable" as
some implementations were not up to scratch but we are not in the
1990's anymore. Nameservers have been attacked to 25 years. They
have been hardened over that period.

All dropping a so called "bad" DNS packets does is make it harder
to deploy extensions. It doesn't save the nameserver. It doesn't
"protect" the nameserver.