Microsoft: Give Xbox One users IPv6 connectivity

[Tore Anderson]

* Jakob Hirsch

>> not all of the XB1s communicating have native IPv6, fallback to Teredo
>> is the expected behaviour.)
> 
> "documented", yes, but sureley not "expected".

In my world view, the documentation defines the expected. If it didn't,
what's the point of having documentation?

>> involved XB1s are behind AVM HGWs, any IPv6 connectivity is broken and
>> thus useless. That may well be the reason why the XB1 is trying to fall
>> back on Teredo in the first place, a fact that makes the claims in the
> 
> No, according to Microsoft the XB1 will not use native IPv6 if one of
> the peers is IPv4 only.

Of course not. How could it? For IPv6 to be used, both peers must have
IPv6, and so must the entire network path between them. If there's any
missing link in that chain, then the use of native IPv6 is impossible.

>> «The Xbox's behavior contradicts the Teredo standard (RFC 4380 Section
>> 5.5)». --> No, it doesn't, because the XB1 *doesn't* have IPv6
>> connectivity, because the AVM broke it.
> 
> No. Just because there's stateful IPv6 firewall does not mean "no IPv6
> connectivity"?

If the firewall blocks the IPv6 traffic relevant to the application
(like AVM does with the XB1's IPSEC traffic), that application does not
have any IPv6 connectivity worth mentioning, IMHO.

Think about it: If your firewall drops all IPv6 80/tcp and 443/tcp
packets, does your web browser have IPv6 connectivity? Would you really
blame it for trying alternative fall-back methods for getting you the
web sites you're asking it to display?

>> (Besides which, RFC 4380 section
>> 5.5 is meant for Teredo implementers, not for HGW manufacturers.)
> 
> So what? It's XB1 which is using Teredo and violating section 5.5 of RFC
> 4380 (which is, ironically, authored by Microsoft itself). And now the
> HGW is the one to blame for that it was not expecting that?

I simply do not expect an HGW to assume the responsibility by default to
block all sorts of application traffic that may or may not be considered
obsolete, outdated, sunset, or whatever. If the user explicitly asks for
it, sure, but by default no. An HGW simply cannot know for certain that
this is what the user wants or even if it is the right thing to do in
the first place.

In the specific case of Teredo, a HGW has no certain way of knowing
whether or not the Teredo client has any form of IPv6 connectivity.
Consider for example there being another IPv4-only router located
between the HGW and the Teredo client (whether this is an XB1 or a
Windows PC, or something else). In this case the Teredo client would not
have any form of IPv6 connectivity regardless of how you choose to
define it, and it would be clear that activating the Teredo service does
not run afoul of RFC 4380 section 5.5. An AVM HGW would still block that
traffic by default, as I understand it. Which is unequivocally the wrong
thing to do.

In any case I do not think it is at all unreasonable to consider the XB1
to be compliant with RFC 4380 section 5.5, even if it does have an IPv6
address configured. The RFC says:

«The Teredo-capable nodes MUST NOT behave as Teredo clients if they
already have IPv6 connectivity through any other means, such as native
IPv6 connectivity».

The key question is, what is meant by «IPv6 connectivity»?

1) The XB1 uses IPSEC (500/udp + ESP). AVM blocks this. I think it is
completely fair for the XB1 to then conclude «no, I do *not* have
[usable] IPv6 connectivity» - and therefore start up Teredo as a
second-best alternative.

2) The word «connectivity» implies two (or more) endpoints. As in,
«connectivity *between A and B*». So, if the your XB1 tries to
communicate with another XB1 that does not have any form of IPv6, then I
think it is again completely fair for the XB1 to conclude «no, I do
*not* have IPv6 connectivity [to that other XB1]», and start Teredo as a
second-best alternative.

Tore