Well...
I'm usually with you Coder on a lot of your comments, but this one not so much. I have a daughter at college many, many miles away, and frankly, Facetime helps bridge that gap - a lot. So in this case, one man's trivia is another's comfort.
A problem with the handling of UDP network packets is leaving T‑Mobile US customers unable to make FaceTime or WhatsApp calls with the latest Apple iOS beta. Various netizens say they are unable to make video calls on their T‑Mo handsets when running the latest iOS beta build. WhatsApp calls are also reportedly dropped. Other …
This post has been deleted by its author
This post has been deleted by its author
"But if you want or need decent VoIP, use something based on real, open, inter-operable standards. In my experience, Facetime and WhatsApp are just toys. Complaining when they break just makes me wonder why people don't seek a better alternative."
Facetime is actually pretty damned good.
I want something reliable, but actually it's more important to have "something that the other person has".
That narrows it down a bit - is your girlfriend a techie? what do you use?
Using TCP/IP is fine over a private network where can depend on end to end QoS, but problematic over the internet where packet loss makes UDP more suitable. You can judge this as "trivia" if you want, but if it wasn't for the unwashed masses finding uses for smartphones you deem beneath you, they'd cost YOU more due to lack of production scale.
T-Mobile users may have noticed issues with other apps that use UDP, but these VoIP apps would get the heaviest use and is where the problem would be primarily noticed. Obviously something about the handling of UDP changes in iOS 9.3, and T-Mobile apparently handles UDP differently than other carriers as well - so whether the fix needs to be applied to Apple's side or T-Mobile's side it is good this was found during beta and not with the official release where it would be a problem for millions of T-Mobile iPhone users.
T-Mobile US are pioneers of ipv6-only with android devices using 464xlat and have been for 3 years now. By trying other device types they are again pushing the agenda for all operators strapped for IP. I am sure they will receive a little flak for this bug.
But take your eyes off the operator for a moment and forgive me for asking this: we have a massive organisation with a market leading set of smart devices, so why in 2016 is a full ipv6 build still a beta? (i.e. can you guys test it for us); and the various regional address authorities practically ran out of v4 addressing a year ago?
Most people don't want their phone to have a globally-unique and addressable address.
It's the selling point for IPv6 that, actually, few want.
Yes, a properly configured firewall can 1:1 map the public IPs for you.
But if you have IPv4 NAT, and IPv4 clients, the easiest way to upgrade your network is to just change your external IPv4 address for a single IPv6 address.
Can someone explain why NAT is even required with IPv6?
Technically NAT itself is not required with IPv6, however, I am running a IPv6 to IPv6 NAT (NAT66) without issues. Of course, I do not use facetime or whatapp, so I am not entirely sure how they work, but I can explain possibilities from a network standpoint. You can do anything you want if you throw enough computing power at the problem.
The issue is that ISPs need a way to enable their IPv6-only clients to get to the IPv4 internet. NAT64, is required with IPv6 for sites that do not use IPv6. They accomplish this by a complete header swap on each packet. NAT64 works with both TCP and UDP, but somehow in this case, something is not working. I am not sure if there is a tie on the client source port, or how that would work, but the NAT64 will pick a new source port at the point of NAT, with the intent of being able to map the packes back to the source. With IPv6 being larger, there is no need to swap the source ports, but on the IPv4 side, usually only one IPv4 address is tied to the NAT box. This single IPv4 address needs differentiators which usually means the NAT pick a unique port.
"Application developers should be
advised that UDP is being rate-limited on a bits-per-second and
packet-per-second basis by network operators to enforce known good
baseline traffic levels for UDP. UDP has been abused to such an
extent that legitimate use may become collateral damage and
application and protocol developers should avoid using UDP as a
transport when possible."
https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00