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/[email protected]/
[ipv6-wg] ipv6-wg Digest, Vol 55, Issue 2
- Previous message (by thread): [ipv6-wg] ipv6-wg Digest, Vol 55, Issue 2
- Next message (by thread): [ipv6-wg] ipv6-wg Digest, Vol 55, Issue 2
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Benedikt Stockebrand
bs at stepladder-it.com
Mon Apr 25 20:13:35 CEST 2016
Hi Christian and list, christian bretterhofer <christian.bretterhofer at gmail.com> writes: > I think the basic work for ISPs in concern to IPv6 is covered. well, depends on the ISP in question. To me it looks a lot like many are still struggling to get the necessary knowledge and experience to their tech and support crowd---not necessarily with the people actively involved in the RIPE community, but at least with the big ones. A customer recently asked one of the large players here in Germany if they were interested in a contract that would have allowed my customer to outsource some IPv6-related tasks---or rather, to outsource some tasks that were also expected to be supported via IPv6. They were turned down with the explanation "we don't have the necessary manpower to operate this". > But i miss the topics to be addressed if you want to migrate from a > IPv4 Microsoft Active domain using company to an system where most > server in an enterprise could by just IPv6 only and use technologies > like NAT46 ( SIIT-DC ) or similar to still make IPv4 only windows > clients happy. Now I've taken a bit of a look at these things, but then I'm not exactly a Microsoft guy. From all I've seen, going for NAT64 and such is generally a bad idea. Instead, ensure that IPv6 is provided wherever it is needed and then make your servers dual stacked. Yes, that frequently involves upgrades on various servers nobody really wants to touch, but the very reasons why nobody wants to touch them are the reasons why you actually clean that stuff up. > Switching an enterprise with location around the global from a "we > donot route any IPv6 traffic across our WAN Links" "most servers have > IPv6 disabled" to > We start IPv6 routing partially and enable partial IPv6 support on > servers in a Microsoft ADS environment seems not covered in most IPv6 > covering websites and presentations. That may be because your approach is unnecessarily painful. You want to get IPv6 up and running in the network infrastructure first, then make your servers dual-stacked and then deal with the clients. At least that's the "strategic" outline of an approach. Beyond that it's really a lot of detail work to do on an individual basis. > Maintaining dual stack for the datacenters is just painfull and there > should be a "single" device in the form of NAT46/SIIT/SIIT-DC in front > of each server area. I am not sure that Active directory is ready for > that. Nonononono, don't do that. Whenever something goes wrong with that "single device", you'll have a serious disruption of service, not everything works through it, and you'll never ever get a chance to get rid of it in the long run because there'll always be that one last server that depends on it, or might depend on it but nobody knows for sure. Yes, that means that you need to have all your servers dual stacked, and yes, that's some serious extra workload in a data center context, but anything else is quite likely way worse. 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-wg Digest, Vol 55, Issue 2
- Next message (by thread): [ipv6-wg] ipv6-wg Digest, Vol 55, Issue 2
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]