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 -------------------- Earlier this year we announced some Xbox functionality coming to Windows 10. One key feature of Windows 10 is enabling multiplayer gaming and chat functionality between Xbox One consoles and Windows 10 devices. This functionality on Windows 10 will behave similarly to how multiplayer works today on Xbox One, using Teredo for NAT traversal and IPsec for security. When used for Xbox Live enabled experiences, the Windows 10 Teredo client will prefer originating traffic from the IANA-registered port, 3074, when available. More detailed guidance on Xbox One behavior is linked at the bottom of this email. It also should be noted that Windows supports a broad range of applications and a huge portfolio of great games outside of the Xbox Live ecosystem. In general, Microsoft encourages broad adoption of the recommendations in RFC 4787, RFC 6092, and RFC 6888 to maximize the viability of P2P technologies for all. IPv4's P2P health is degrading -------------------- Qualitative and quantitative evidence available to us indicates that overall availability of functioning P2P connectivity on the IPv4 Internet is decreasing over time. In particular we are concerned that IPv4 address scarcity is forcing many small and medium market network operators to deploy carrier-grade NAT functionality. This often results in end-users being intractably stuck behind "strict" networks with degraded multiplayer experiences as a result. Healthy, standards-compliant IPv6 access is broadly needed, sooner rather than later. However, we have identified a few areas of concern in regard to IPv6 support that will hinder the efficacy of enabling multiplayer on IPv6. 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. 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. 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. 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. Network operators and CPE manufactures are encouraged to reach out to our team at xboxteredo@microsoft.com 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. Thanks for your time, Darrin Veit & Christopher Palmer Xbox Platform Networking Operating System Group Current Xbox One Multiplayer Networking Guidance ------------------------- http://download.microsoft.com/download/A/C/4/AC4484B8-AA16-446F-86F8-BDFC498...
On Mon, May 18, 2015 at 04:57:59PM +0000, Darrin Veit wrote:
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 xboxteredo@microsoft.com 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 -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
In message <20150518180445.GB15755@puck.nether.net>, Jared Mauch writes:
On Mon, May 18, 2015 at 04:57:59PM +0000, Darrin Veit wrote:
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.
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. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
participants (3)
-
Darrin Veit -
Jared Mauch -
Mark Andrews