This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ipv6-wg@ripe.net/
[ipv6-wg] IPv6 only network (not just at RIPE xx meeting)
- Previous message (by thread): [ipv6-wg] IPv6 only network (not just at RIPE xx meeting)
- Next message (by thread): [ipv6-wg] IPv6 only network (not just at RIPE xx meeting)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Benedikt Stockebrand
bs at stepladder-it.com
Tue Jun 3 14:40:44 CEST 2014
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/
- Previous message (by thread): [ipv6-wg] IPv6 only network (not just at RIPE xx meeting)
- Next message (by thread): [ipv6-wg] IPv6 only network (not just at RIPE xx meeting)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]