Raul:

I appreciate your enthusiasm for IPv6, and cannot nor would not argue your points. I'll ask a question: what short term benefit does the organization get for dumping its perfectly serviceable IPv4 network? Answer, almost none. They will get additional complexity and administrative costs until it's fully implemented and all the problems are worked out, but at what tangible, actual benefit? Answer: almost no real benefits over what they have now.

As to IBM i being your only concern, I'll strongly argue that might be the least of the worries, comparted to Microsoft updates, Linux updates, Apple updates, Cisco, Brocade, etc, etc. By far the most stable system in the mix is IBM i . Don't forget all the printers, and other IoT devcies that are on the network. I'll bet a hefty amount that video surveillance system does not speak IPv6, nor will the HVAC systems, Door security and badge reader, ditto. It won't take long to compile a bigger list than this one.

The conversion project of that type is far bigger than just the Switch, Router, firewall, PCs and data room devices making your project far more complex and expensive. To what gain other than technological purity?


--
Jim Oberholtzer
Agile Technology Architects


-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Raul Jager
Sent: Wednesday, June 06, 2018 6:28 PM
To: web400@xxxxxxxxxxxx
Subject: Re: [WEB400] IPv6 day

It is true that internal IPv4 addresses are plenty.
Moving to IPv6 you do not need any more internal addresses, nor NAT. It is like having your own, valid IPv4 addresses in the internal network, so your i can communicate directly with any other computer in the internet. Like it was in the original design of the internet. No NAT, no forwarding tables. Simpler, more functionality, but you need to have a well configured firewall.
The only concern in the i is if you store or use the IP for some checks.

With no more IPv4 addresses, and more users some providers are using more NAT, even what they call "Carrier Grade NAT" The more users you put in each IP, the worst the performance, and some applications cease to function. For big users NAT degrades to much, and they are forced to IPv6.
If you stay in IPv4, when an user access your computer from IPv6 you do not get the origin IP, but the one from the gateway between IPv6 and IPv4

"it works, do not fix it" is not always a good politic. In some cases it makes you look obsolete.


On 06/06/2018 09:29 AM, Jim Oberholtzer wrote:
99% of shops will not be implementing IPv6 internally for one simple reason.
They don't need to. Those that do implement it will be doing so for
other reasons, all valid and good but not because the organization ran
out of IPv4 addresses internally.

Nathan is correct the only one that will really care is the network
admin who when forced to used IPv6 on the external network (read:
Internet) will have to contend with the DNS and NAT to connect the systems to the world.

As to PTFs, that's simple. Keep up with the HIPER at V7R3, and the
HIPER and TCP group at V7R2. There is no TCP group at V7R3 currently.


--
Jim Oberholtzer
Agile Technology Architects


-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Nathan
Andelin
Sent: Tuesday, June 05, 2018 5:11 PM
To: Web Enabling the IBM i (AS/400 and iSeries) <web400@xxxxxxxxxxxx>
Subject: Re: [WEB400] IPv6 day

Isn't this really a concern of network administrators? Maybe your ISP
runs out of static IP 4 addresses, or they start charging more for IP
4 addresses than IP 6? Should web application developers be concerned?
Won't the network guy just give you a domain name that points to an IP
6 address, and works seamlessly?


On Tue, Jun 5, 2018 at 4:00 PM, Raul Jager <raul@xxxxxxxxxx> wrote:

June 6 is IPv6 day.

We, in the midrange must plan to leave IPv4 as secondary and focus in
IPv6, otherwise we are going to give a strong argument to the ones
that say midrange is obsolete.

Some information:
https://labs.ripe.net/Members/ulka_athale_1/ripe-ncc-educa-ipv6-day

At some point in time IBM made a mistake with the use of the
protocols, The i tried to connect using IPv6, and if timed out used
IPv4. The idea was to push the use of IPv6, but it back fired, and
some PTFs later they changed the protocol, requesting IPv6 and IPv4
together and using the one that responded first. Since IPv6 is
usually faster, if available the i will use it, otherwise fall back
to IPv4
without delay.
At present the i works great with "dual stack", using both protocols.

At the time the i used IPv4 only after IPv6 timed out there where to
ways to solve it, the good one, set up IPv6, and the easy one disable
IPv6. Sadly, there are still some people advising to disable IPv6.

Enjoy, the future internet is here.


-- Este e-mail fue enviado desde el Mail Server del diario ABC Color --
-- Verificado por Anti-Virus Corporativo Symantec --
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)
mailing list To post a message email: WEB400@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at https://archive.midrange.com/web400.


--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list To post a message email: WEB400@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/web400.




-- Este e-mail fue enviado desde el Mail Server del diario ABC Color --
-- Verificado por Anti-Virus Corporativo Symantec --

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.