Re: [ipv6-wg] IPv6 only network (not just at RIPE xx meeting)
Hi all, Not attending RIPE-meetings myself anymore these days, I'm not sure whether (just) a IPv6-only network at a meeting is going to cut it. This has been done for a number of years worth of meetings and while the results are interesting, I'm not sure that a RIPE-meeting is a requirement to run these experiments. It makes perfect sense to run a V6-only network at home/office and get the experience all year, not just during a meeting. So, as a typical home user these days, I run a V6-network, some pieces of it being V6-only, other places being V6-preferred, and the experiences are, eumm, mixed. I frequently find sites (at various ISP's) that are either partially or fully broken for V6. In many instances, happy eyeballs rescues things, that is, things seem just slow but not entirely broken unless one analyzes. Reporting a V6-broken website to it's hoster is, in many cases, a waiste of time. Helpdesks don't understand the problem. If I'm lucky I get a response. Problems are seldom resolved. I think I see this five times per month or so. Perhaps I should browse less. Thing is, we seem to be working on making the Internet V6-capable, but currently V6 performance and stability is a serious issue, especially when it comes to reporting problems. Happy eyeballs mean that the V6-network can, in many cases, just be switched off without anybody noticing. We all know of stories of support/helpdesk folk telling people just to switch off V6. That's all nice if it'd just be an academic exercise but not if it is supposed to be the main bread and butter in the years to come. So, my question to the WG: does the WG think this is a problem, and can we think of a way to get clueful v6 complaints to clueful handlers, instead of being ignored / misaddressed / ...? Geert Jan
Hi Geert Jan and list, Geert Jan de Groot <GeertJan.deGroot@xs4all.nl> writes:
[...] Thing is, we seem to be working on making the Internet V6-capable, but currently V6 performance and stability is a serious issue, especially when it comes to reporting problems. [...]
the Good News[TM] here is that with an increasing number of DS-Lite deployments, these will likely put the pressure on those web sites money-wise: If the site appears sluggish or unstable to an increasing number of people who don't have proper (in the broadest possible sense and explicitly including NAT) IPv4 connectivity, the owners of those web sites will eventually notice that they have a problem. I think we are offering these people all the help they need, but until they actually want our help, that's pretty much all we can do. We can spread the word best we can, but we can't force people to listen.
So, my question to the WG: does the WG think this is a problem,
Definitely, but: At the few IETF meetings I've been to before they started the sunset4 WG I've been rather frustrated by the v6ops WG being swamped with transition/somebody-save-my-IPv4 topics. We better be careful that this doesn't happen here as well.
and can we think of a way to get clueful v6 complaints to clueful handlers, instead of being ignored / misaddressed / ...?
The problem of getting first level support up and running with IPv6 is tremendous, and some people put significant effort into dealing with this. What else can we do at this point? On a more general scale: As far as I am personally concerned, rather than putting effort into convincing people who simply refuse to accept that there's something that they have to take care of, I personally rather focus my energy on those people who have realized so and come for help. That is where I can make a difference. After all, anybody in IT should have heard of IPv6 and why we need it by now; it isn't a well kept secret at all. The problem is not that people don't know, it is that people don't care. 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/
I guess this is one of the larger issues with running multiple protocols in parallel :) One solution as a content-provider would be to get the services to be v6-only, and then implement workarounds (for example stateless nat46, 4to6 loadbalancers) on the edge to get the service on to v4 Internet. Most people monitor v4 and if v4 depends on a working v6 its a lot easier to make sure issues are noticed and fixed in time. This is basically what i'm looking at for our services since I don't like the added complexity of running dualstack everywhere. (two of everything doesn't feel right unless its for redundancy, which it isn't in this case) I've got no idea how to handle this on other services who aren't aware of the situation though. Maybe create new best practices? :) /Oskar Stenman Skickat från min Sony Xperia™-smartphone ---- Geert Jan de Groot skrev ----
Hi all,
Not attending RIPE-meetings myself anymore these days, I'm not sure whether (just) a IPv6-only network at a meeting is going to cut it. This has been done for a number of years worth of meetings and while the results are interesting, I'm not sure that a RIPE-meeting is a requirement to run these experiments. It makes perfect sense to run a V6-only network at home/office and get the experience all year, not just during a meeting.
So, as a typical home user these days, I run a V6-network, some pieces of it being V6-only, other places being V6-preferred, and the experiences are, eumm, mixed.
I frequently find sites (at various ISP's) that are either partially or fully broken for V6. In many instances, happy eyeballs rescues things, that is, things seem just slow but not entirely broken unless one analyzes.
Reporting a V6-broken website to it's hoster is, in many cases, a waiste of time. Helpdesks don't understand the problem. If I'm lucky I get a response. Problems are seldom resolved. I think I see this five times per month or so. Perhaps I should browse less.
Thing is, we seem to be working on making the Internet V6-capable, but currently V6 performance and stability is a serious issue, especially when it comes to reporting problems. Happy eyeballs mean that the V6-network can, in many cases, just be switched off without anybody noticing. We all know of stories of support/helpdesk folk telling people just to switch off V6. That's all nice if it'd just be an academic exercise but not if it is supposed to be the main bread and butter in the years to come.
So, my question to the WG: does the WG think this is a problem, and can we think of a way to get clueful v6 complaints to clueful handlers, instead of being ignored / misaddressed / ...?
Geert Jan
Hi Oskar and list,
I guess this is one of the larger issues with running multiple protocols in parallel :)
it is:-)
One solution as a content-provider would be to get the services to be v6-only, and then implement workarounds (for example stateless nat46, 4to6 loadbalancers) on the edge to get the service on to v4 Internet. Most people monitor v4 and if v4 depends on a working v6 its a lot easier to make sure issues are noticed and fixed in time.
Hmm, I doubt that this is a good idea. Of course, it depends on your particular services and their requirements, but here's why I'd rather dual-stack the server (but not the clients): - Running the existing servers dual-stacked is in my experience less pain than messing around with NAT64, proxies or whatever. In other words, dual-stacked servers are likely to be less pain. - If you only monitor the IPv4 side, then you'll get limited information for troubleshooting: You have to check manually if the problem is with the server or the NAT64/proxy/whatever. If you want to keep downtimes at their existing levels, you do need to monitor both the IPv4 and IPv6 sides of the service. - In the long run you'll need IPv6 monitoring anyway, because it is only a matter of time until some services will be provided via IPv6 only. This is likely going to happen faster than people generally expect. (Yes, ask a psychologist/sociologist about this...). That said, I can kind of imagine scenarios where your approach may be useful, it's just that from my subjective experience these aren't the "normal" or "general" case.
This is basically what i'm looking at for our services since I don't like the added complexity of running dualstack everywhere. (two of everything doesn't feel right unless its for redundancy, which it isn't in this case)
When it comes to dual-stacking both sides of a client/server setup, I fully agree. However, if we assume the client side to be single stacked (and/or outside our administrative control), then I generally consider dual-stacking the servers the least painful approach. 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/
I guess this is one of the larger issues with running multiple protocols in parallel :) One solution as a content-provider would be to get the services to be v6-only, and then implement workarounds (for example stateless nat46, 4to6 loadbalancers) on the edge to get the service on to v4 Internet. Most people monitor v4 and if v4 depends on a working v6 its a lot easier to make sure issues are noticed and fixed in time.
This can work as long as the services are conducive to NAT46 or (preferably) SLB46. Web services behind SLB46 work well for example, Facebook being an excellent example of this approach: http://www.internetsociety.org/deploy360/blog/2014/03/facebooks-extremely-im... --Jim ---- Geert Jan de Groot skrev ---- Hi all, Not attending RIPE-meetings myself anymore these days, I'm not sure whether (just) a IPv6-only network at a meeting is going to cut it. This has been done for a number of years worth of meetings and while the results are interesting, I'm not sure that a RIPE-meeting is a requirement to run these experiments. It makes perfect sense to run a V6-only network at home/office and get the experience all year, not just during a meeting. So, as a typical home user these days, I run a V6-network, some pieces of it being V6-only, other places being V6-preferred, and the experiences are, eumm, mixed. I frequently find sites (at various ISP's) that are either partially or fully broken for V6. In many instances, happy eyeballs rescues things, that is, things seem just slow but not entirely broken unless one analyzes. Reporting a V6-broken website to it's hoster is, in many cases, a waiste of time. Helpdesks don't understand the problem. If I'm lucky I get a response. Problems are seldom resolved. I think I see this five times per month or so. Perhaps I should browse less. Thing is, we seem to be working on making the Internet V6-capable, but currently V6 performance and stability is a serious issue, especially when it comes to reporting problems. Happy eyeballs mean that the V6-network can, in many cases, just be switched off without anybody noticing. We all know of stories of support/helpdesk folk telling people just to switch off V6. That's all nice if it'd just be an academic exercise but not if it is supposed to be the main bread and butter in the years to come. So, my question to the WG: does the WG think this is a problem, and can we think of a way to get clueful v6 complaints to clueful handlers, instead of being ignored / misaddressed / ...? Geert Jan
participants (4)
-
Benedikt Stockebrand -
Geert Jan de Groot -
James Small -
Oskar Stenman