Re: [ipv6-wg] IPv6 cloud!
Hi Ole and list, "Ole Troan (otroan)" <otroan@cisco.com> writes:
Considering the increasing reports of people having problems with DS-Lite
Any more details on that? New problems not mentioned in RFC6269?
sorry I haven't got the time right now to review RFC6269 for what's exactly mentioned there and what isn't, but: When I do IPv6 trainings these days it's about one in eight who is struggling with their land line access, which is based on DS-Lite and which reasonably well matches the estimated percentage of DS-Lite on land lines. The problems are however of a somewhat different nature than what RFC6269 addresses; they are roughly these: - Various services don't work. Like STUN, and due to that, SIP. And apparently various VPN solutions, too, but I never got access to any details with this. The real culprit here seems to be restricted cone NAT in the AFTR, plus apparently IPsec not working through DS-Lite. - There have been multiple reports that during peak hours there are significant connection drops. The impact varies from user to user as well as from ISP to ISP, apparently. Or as one user put it: "I solved the problem. I just don't even try to access IPv4-only web pages on saturday afternoons any longer." I don't have access to the AFTRs involved, so I can't reliably tell what's happening there, but from the descriptions I got it looks like some of them are actually running out of memory/CAM during peak hours and start to drop the connections. This is economically plausible, too, since the ISPs won't spend significant money on AFTR hardware until problems have already shown up. - First level support is frequently completely helpless when confronted with DS-Lite, or even IPv6 in general. The most annoying aspect here is that frequently it comes across that "it's a problem with IPv6" and "if you keep complaining they'll switch it off again for you" (i.e. they go back to IPv4-only connectivity without restricted cone NAT). All the information I have here is largely based on anecdotal reports, but enough of them for me to consider these problems anything but isolated cases. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Benedikt, An idea: Next time you meet the folks encountering the problems, suggest them to google for "go6 nat64" and configure their resolver to one of Jan's NAT64 test DNS64s, and then turn off IPv4 on their host completely. If their life gets better it will be a very interesting and useful data point. --a
On 09 May 2016, at 22:09, Benedikt Stockebrand <bs@stepladder-it.com> wrote:
Hi Ole and list,
"Ole Troan (otroan)" <otroan@cisco.com> writes:
Considering the increasing reports of people having problems with DS-Lite
Any more details on that? New problems not mentioned in RFC6269?
sorry I haven't got the time right now to review RFC6269 for what's exactly mentioned there and what isn't, but: When I do IPv6 trainings these days it's about one in eight who is struggling with their land line access, which is based on DS-Lite and which reasonably well matches the estimated percentage of DS-Lite on land lines. The problems are however of a somewhat different nature than what RFC6269 addresses; they are roughly these:
- Various services don't work. Like STUN, and due to that, SIP. And apparently various VPN solutions, too, but I never got access to any details with this. The real culprit here seems to be restricted cone NAT in the AFTR, plus apparently IPsec not working through DS-Lite.
- There have been multiple reports that during peak hours there are significant connection drops. The impact varies from user to user as well as from ISP to ISP, apparently. Or as one user put it: "I solved the problem. I just don't even try to access IPv4-only web pages on saturday afternoons any longer."
I don't have access to the AFTRs involved, so I can't reliably tell what's happening there, but from the descriptions I got it looks like some of them are actually running out of memory/CAM during peak hours and start to drop the connections. This is economically plausible, too, since the ISPs won't spend significant money on AFTR hardware until problems have already shown up.
- First level support is frequently completely helpless when confronted with DS-Lite, or even IPv6 in general.
The most annoying aspect here is that frequently it comes across that "it's a problem with IPv6" and "if you keep complaining they'll switch it off again for you" (i.e. they go back to IPv4-only connectivity without restricted cone NAT).
All the information I have here is largely based on anecdotal reports, but enough of them for me to consider these problems anything but isolated cases.
Cheers,
Benedikt
-- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/
Business Grade IPv6 --- Consulting, Training, Projects
BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Hi Andrew and list, Andrew 👽 Yourtchenko <ayourtch@gmail.com> writes:
An idea: Next time you meet the folks encountering the problems, suggest them to google for "go6 nat64" and configure their resolver to one of Jan's NAT64 test DNS64s, and then turn off IPv4 on their host completely.
to my knowledge that won't help in any way with their STUN/SIP problems. It will also add to latency. And if Jan's setup gets overloaded, then the overall result won't help them any. But I'll point them that way next time I get into such a situation. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
On 09/05/16 22:09, Benedikt Stockebrand wrote:
Considering the increasing reports of people having problems with DS-Lite
Any more details on that?
And apparently various VPN solutions, too, but I never got access to any details with this.
I came across this recently (my ISP now provides native IPv6 + DS-lite IPv4), and after debugging it, found that the CPE device was reporting an incorrect path MTU when receiving a DF packet that was larger than the tunnel interface to the AFTR. This caused UDP IPv4 OpenVPN tunnels to stall and die horribly. I worked around it by overriding the link-mtu config in OpenVPN. But in this case, it was the CPE, not the AFTR, causing the problem. (Of course I sent the ISP tcpdumps and a full analysis pointing out to them that the firmware in the CPE they provided me was broken. They decided to fix it by sending me a different model of CPE. I doubt they ever escalated it to actually fix the underlying problem in the original CPE. But if you happen to have a Technicolor TC7200, be wary of its DS-Lite implementation!) Cheers, Colin
Hi Colin and list, Colin Petrie <colin@spakka.net> writes:
[Problems with VPNs over DS-Lite]
(Of course I sent the ISP tcpdumps and a full analysis pointing out to them that the firmware in the CPE they provided me was broken. They decided to fix it by sending me a different model of CPE. I doubt they ever escalated it to actually fix the underlying problem in the original CPE. But if you happen to have a Technicolor TC7200, be wary of its DS-Lite implementation!)
that's what I've mentioned(?) before: These issues occur at a reasonably large scale, so they need to be handled by first, or at most second, level support. But show me any first level supporter able to diagnose that, or even understand what a tcpdump is or what it means. They simply don't have a chance. Aimlessly beating at the problem until the customer shuts up (no matter if his problem is solved or he just gave up) is pretty much all they can do. But that doesn't mean that you want to rely on that sort of setup. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
participants (3)
-
Andrew 👽 Yourtchenko -
Benedikt Stockebrand -
Colin Petrie