Re: [ipv6-wg] ipv6-wg Digest, Vol 55, Issue 4 -NAT64 Benedikt Stockebrand
Hello Benedikt, I’m not a friend of NAT as well, but demonize NAT for any actions is a kind of overdo, isn’t it. We are living with NAT a long time now for better or for worse. A customer of mine (enterprise customer with hundreds of sites and thousands of employees) has setup his IPv6 project more than 4 years ago and plans to be finished 2020. Their project team produced hundreds of pages in planning strategy, timeline and migration. In one of their sub projects they saw NAT as a interim solution for their Webservice as best method. We implemented a redundant NAT64 solution based on Cisco Adress Family Translation. Now IPv6-only or Dual-stacked Users can hit the customers web service which is still IPv4 only. Of course not a low-cost solution, but for „political" and/or technical reasons a solid way. Best regards Thorsten
-----Ursprüngliche Nachricht----- Von: ipv6-wg [mailto:ipv6-wg-bounces@ripe.net] Im Auftrag von ipv6-wg-request@ripe.net Gesendet: Dienstag, 26. April 2016 12:00 An: ipv6-wg@ripe.net Betreff: ipv6-wg Digest, Vol 55, Issue 4
Send ipv6-wg mailing list submissions to ipv6-wg@ripe.net
To subscribe or unsubscribe via the World Wide Web, visit https://lists.ripe.net/mailman/listinfo/ipv6-wg or, via email, send a message with subject or body 'help' to ipv6-wg-request@ripe.net
You can reach the person managing the list at ipv6-wg-owner@ripe.net
When replying, please edit your Subject line so it is more specific than "Re: Contents of ipv6-wg digest..."
Today's Topics:
1. Re: ipv6-wg Digest, Vol 55, Issue 2 (Benedikt Stockebrand) 2. Re: ipv6-wg Digest, Vol 55, Issue 2 (Silvia Hagen) 3. Re: ipv6-wg Digest, Vol 55, Issue 2 (Sander Steffann)
----------------------------------------------------------------------
Message: 1 Date: Mon, 25 Apr 2016 18:13:35 +0000 From: Benedikt Stockebrand <bs@stepladder-it.com> To: christian bretterhofer <christian.bretterhofer@gmail.com> Cc: ipv6-wg@ripe.net Subject: Re: [ipv6-wg] ipv6-wg Digest, Vol 55, Issue 2 Message-ID: <87eg9th7zk.fsf@moa.stepladder-it.com> Content-Type: text/plain
Hi Christian and list,
christian bretterhofer <christian.bretterhofer@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/
------------------------------
Message: 2 Date: Mon, 25 Apr 2016 18:35:28 +0000 From: Silvia Hagen <silvia.hagen@sunny.ch> To: Benedikt Stockebrand <bs@stepladder-it.com>, christian bretterhofer <christian.bretterhofer@gmail.com> Cc: "ipv6-wg@ripe.net" <ipv6-wg@ripe.net> Subject: Re: [ipv6-wg] ipv6-wg Digest, Vol 55, Issue 2 Message-ID: <F1D4404E5E6C614EB9D3083F4D15A7E70129FFFA@hex02> Content-Type: text/plain; charset="iso-8859-1"
That would be a great panel discussion with some diverse speakers on the panel :-)
Silvia
-----Urspr?ngliche Nachricht----- Von: ipv6-wg [mailto:ipv6-wg-bounces@ripe.net] Im Auftrag von Benedikt Stockebrand Gesendet: Montag, 25. April 2016 20:14 An: christian bretterhofer Cc: ipv6-wg@ripe.net Betreff: Re: [ipv6-wg] ipv6-wg Digest, Vol 55, Issue 2
Hi Christian and list,
christian bretterhofer <christian.bretterhofer@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/
------------------------------
Message: 3 Date: Mon, 25 Apr 2016 19:45:27 +0100 From: Sander Steffann <sander@steffann.nl> To: Silvia Hagen <silvia.hagen@sunny.ch> Cc: christian bretterhofer <christian.bretterhofer@gmail.com>, "ipv6-wg@ripe.net" <ipv6-wg@ripe.net> Subject: Re: [ipv6-wg] ipv6-wg Digest, Vol 55, Issue 2 Message-ID: <0831019F-B2A2-40DB-99E4-9CAA526D1581@steffann.nl> Content-Type: text/plain; charset="iso-8859-1"
Hi,
Op 25 apr. 2016, om 19:35 heeft Silvia Hagen <silvia.hagen@sunny.ch> het volgende geschreven:
That would be a great panel discussion with some diverse speakers on the panel :-)
I have been doing some enterprise stuff as well recently. If there is going to be such a panel I would love to participate! :)
Cheers, Sander
Hi Thorsten and list, Thorsten Trottier <thorsten.trottier@googlemail.com> writes:
I’m not a friend of NAT as well, but demonize NAT for any actions is a kind of overdo, isn’t it. We are living with NAT a long time now for better or for worse.
first off: NAT and NAT64 are two rather different concepts. NAT translates addresses and ports, but NAT64 translates between address/protocol families.
A customer of mine (enterprise customer with hundreds of sites and thousands of employees) has setup his IPv6 project more than 4 years ago and plans to be finished 2020. [...]
That's a different scenario than the one Christian talked about, which was more centered around an AD setup. But anyways: Why didn't you do the updates and made the servers dual-stacked? If they are too old to support IPv6, then at least from my experience they are in dire need of an update---or usually a replacement---anyway. I understand that using the NAT64 setup buys you some time at least on some accounts, but from my experience there is pretty much always some sort of stuff that doesn't work with NAT64 at least in enterprise environments. And actually finding these things beforehand is quite some job, so I'd generally consider this move something of a desperate gamble: Don't properly test because you *really* need a quick kludge, and hope no major functionalities get affected. Cheers, Benedikt PS: \begin{ObNATBashing} Anyone who thinks that NAT is no problem should be forced to implement STUN on any low end SIP phone first and made to deal with the legal fallout whenever an emergency call didn't work due to STUN problems second. \end{ObNATBashing} -- 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 (2)
-
Benedikt Stockebrand -
Thorsten Trottier