IPv6 and chess software

[bob]

As for chess software, will ICS and FICS work under IPv6? What about the timeseal programs? Can remote GUI clients connect in all IPv6 environment? If the answers to these questions are unknown, then that's a problem.

You didn't understand the point of my post. Existing versions with any hardcoded IPv4 stuff will continue to work as long as the servers they connect to have an IPv4 address. There is no reason to believe that existing servers like FICS will let go their IPv4 addresses any time soon, if ever.

What will happen is that they will eventually be forced to get an IPv6 address, and update the clients for IPv6. But un-updated clients which are IPv4-only will still be able to connect to those servers, since IPv4 and IPv6 can coexist.

"can" but not "will". Having both is inefficient. And slow. Right now, IPV6 is problematic because not all routers/servers/etc know about IPV6 DNS lookups. You try an IPV6 lookup, wait for it to time-out, then revert back to IPV4. That's not acceptable, and won't be acceptable whenever IPV6 becomes the norm and IPV4 becomes the slow path... It _will_ go away at some point in the not-to-distant future...

None of that contradicts what I said...

IPv4-only clients will never do IPv6 DNS lookups, so none of those timeouts come into play for those clients.

When most of the world is IPV6 only, they will _definitely_ experience timeouts, because no one will respond to their IPV4 lookups...

Servers which have both IPv4 and IPv6 do not get any faster by eliminating the IPv4 DNS record since, as you said, the IPv6 request will either happen first or not at all.

The point is, at the present, it is mostly IPV4, In 5 years, it will be mostly IPV6. If you run on the rag-tag end of IPV4, things are going to get more and more miserable. And sooner, rather than later, IPV4 will be gone.

[rbarreira]

As for chess software, will ICS and FICS work under IPv6? What about the timeseal programs? Can remote GUI clients connect in all IPv6 environment? If the answers to these questions are unknown, then that's a problem.

You didn't understand the point of my post. Existing versions with any hardcoded IPv4 stuff will continue to work as long as the servers they connect to have an IPv4 address. There is no reason to believe that existing servers like FICS will let go their IPv4 addresses any time soon, if ever.

What will happen is that they will eventually be forced to get an IPv6 address, and update the clients for IPv6. But un-updated clients which are IPv4-only will still be able to connect to those servers, since IPv4 and IPv6 can coexist.

"can" but not "will". Having both is inefficient. And slow. Right now, IPV6 is problematic because not all routers/servers/etc know about IPV6 DNS lookups. You try an IPV6 lookup, wait for it to time-out, then revert back to IPV4. That's not acceptable, and won't be acceptable whenever IPV6 becomes the norm and IPV4 becomes the slow path... It _will_ go away at some point in the not-to-distant future...

None of that contradicts what I said...

IPv4-only clients will never do IPv6 DNS lookups, so none of those timeouts come into play for those clients.

When most of the world is IPV6 only, they will _definitely_ experience timeouts, because no one will respond to their IPV4 lookups...

Servers which have both IPv4 and IPv6 do not get any faster by eliminating the IPv4 DNS record since, as you said, the IPv6 request will either happen first or not at all.

The point is, at the present, it is mostly IPV4, In 5 years, it will be mostly IPV6. If you run on the rag-tag end of IPV4, things are going to get more and more miserable. And sooner, rather than later, IPV4 will be gone.

My point is that servers can have IPv4 and IPv6 running simultaneously without any performance problems, as far as I know. The only reason why few servers have enabled IPv6 yet is because there are certain browsers and OSs which run into bugs if they try to use it, which means for now it's better to do IPv4 only. But I have never heard of problems from keeping IPv4 enabled after enabling IPv6. IPv4 clients will never notice the difference, and IPv6 ones simply ignore the IPv4 possibility.

Knowing that, I'd be surprised if most servers had gotten rid of their IPv4 addresses in 4 or 5 years. I think the migration might take longer than that knowing the amount of consumer hardware which is not IPv6 ready, such as home routers. Let's see how it goes.

[bob]

As for chess software, will ICS and FICS work under IPv6? What about the timeseal programs? Can remote GUI clients connect in all IPv6 environment? If the answers to these questions are unknown, then that's a problem.

You didn't understand the point of my post. Existing versions with any hardcoded IPv4 stuff will continue to work as long as the servers they connect to have an IPv4 address. There is no reason to believe that existing servers like FICS will let go their IPv4 addresses any time soon, if ever.

What will happen is that they will eventually be forced to get an IPv6 address, and update the clients for IPv6. But un-updated clients which are IPv4-only will still be able to connect to those servers, since IPv4 and IPv6 can coexist.

"can" but not "will". Having both is inefficient. And slow. Right now, IPV6 is problematic because not all routers/servers/etc know about IPV6 DNS lookups. You try an IPV6 lookup, wait for it to time-out, then revert back to IPV4. That's not acceptable, and won't be acceptable whenever IPV6 becomes the norm and IPV4 becomes the slow path... It _will_ go away at some point in the not-to-distant future...

None of that contradicts what I said...

IPv4-only clients will never do IPv6 DNS lookups, so none of those timeouts come into play for those clients.

When most of the world is IPV6 only, they will _definitely_ experience timeouts, because no one will respond to their IPV4 lookups...

Servers which have both IPv4 and IPv6 do not get any faster by eliminating the IPv4 DNS record since, as you said, the IPv6 request will either happen first or not at all.

The point is, at the present, it is mostly IPV4, In 5 years, it will be mostly IPV6. If you run on the rag-tag end of IPV4, things are going to get more and more miserable. And sooner, rather than later, IPV4 will be gone.

My point is that servers can have IPv4 and IPv6 running simultaneously without any performance problems, as far as I know. The only reason why few servers have enabled IPv6 yet is because there are certain browsers and OSs which run into bugs if they try to use it, which means for now it's better to do IPv4 only. But I have never heard of problems from keeping IPv4 enabled after enabling IPv6. IPv4 clients will never notice the difference, and IPv6 ones simply ignore the IPv4 possibility.

Knowing that, I'd be surprised if most servers had gotten rid of their IPv4 addresses in 4 or 5 years. I think the migration might take longer than that knowing the amount of consumer hardware which is not IPv6 ready, such as home routers. Let's see how it goes.

I do not believe that both will be supported forever. We are going to see a point where there are more IPV6 than IPV4 routers, DNS servers, etc. The IPV4 clients will begin to have problems. IPV6 offers some other really attractive features, such as the ability to cut out much of the "spoofing" that goes on today where an application can put any return address in a packet it wants. There is such an up-side, that it will become the standard, and that spells doom for IPV4. IPV6 is not a huge change for applications...

[sje]

IPV6 is not a huge change for applications...

Other than router firmware and the like, most applications will see a one line change.

From:

Code: Select all

tcp_socket = socket(PF_INET, SOCK_STREAM, 0);

To:

Code: Select all

tcp6_socket = socket(PF_INET6, SOCK_STREAM, 0);

Well, as long as the rest of the program's network code was written correctly.

[Sven]

IPV6 is not a huge change for applications...

Other than router firmware and the like, most applications will see a one line change.

From:

Code: Select all

tcp_socket = socket(PF_INET, SOCK_STREAM, 0);

To:

Code: Select all

tcp6_socket = socket(PF_INET6, SOCK_STREAM, 0);

Well, as long as the rest of the program's network code was written correctly.

That is the hard way but not recommended. Applications have to be made ready for the real world which is mixed IPV4/V6 for some time, not for an "IPV6 only" world. Don't think of an overnight "big bang", that thing won't happen.

A couple of years ago others came to a completely different conclusion than yours, nearby revealing a lot more issues than just the change of one parameter of the socket() function call.

I have also found this document which tells a lot more about the actual issues. It is long and technical but definitely from a credible source.

One line regards
Sven

[sje]

Almost all porting issues can be solved with only a very few code changes plus recompilation and linking with the right libraries. Problems due to having a mixed IPv4/IPv6 environment have already started to decline and will continue to do so.

The necessary code has already been written, tested, and is generally freely available; at least for those using Linux, Mac OS/X, or other Posix compliant platforms.

It is not hard to learn. I started programming back in 1969 and I've managed to figure out these new things without too much effort, so those younger and with a more recent education should have even less difficulty.

Some applications will break, but will be fixed if they're supported or are open source. Using unsupported, closed source programs is itself a problem and will remain so; this sad fact should not be allowed to impede progress for the rest of us.

[Sven]

Almost all porting issues can be solved with only a very few code changes plus recompilation and linking with the right libraries. Problems due to having a mixed IPv4/IPv6 environment have already started to decline and will continue to do so.

How can they have started to decline if IPV6 has not yet started to be widely used?

The necessary code has already been written, tested, and is generally freely available; at least for those using Linux, Mac OS/X, or other Posix compliant platforms.

But here again, we have a "real world" with all these millions of Windows PCs and Windows servers ... They are there, and they will continue to be there. And they have software which must be ported, too. When will that be done?

I also mentioned the millions of home office routers. Do you think they can be thrown away all at once? Network printers? Hubs? You can't, so your software must continue to be aware of "old" and "new" IP world at the same time.

It is not hard to learn. I started programming back in 1969 and I've managed to figure out these new things without too much effort, so those younger and with a more recent education should have even less difficulty.

Some applications will break, but will be fixed if they're supported or are open source. Using unsupported, closed source programs is itself a problem and will remain so; this sad fact should not be allowed to impede progress for the rest of us.

It is not a question of learning. It is a question of how much changes can be done at the same time.

Don't you see the need for a migration strategy, instead of a "big bang"?

Sven

[bob]

Almost all porting issues can be solved with only a very few code changes plus recompilation and linking with the right libraries. Problems due to having a mixed IPv4/IPv6 environment have already started to decline and will continue to do so.

How can they have started to decline if IPV6 has not yet started to be widely used?

The necessary code has already been written, tested, and is generally freely available; at least for those using Linux, Mac OS/X, or other Posix compliant platforms.

But here again, we have a "real world" with all these millions of Windows PCs and Windows servers ... They are there, and they will continue to be there. And they have software which must be ported, too. When will that be done?

I also mentioned the millions of home office routers. Do you think they can be thrown away all at once? Network printers? Hubs? You can't, so your software must continue to be aware of "old" and "new" IP world at the same time.

It is not hard to learn. I started programming back in 1969 and I've managed to figure out these new things without too much effort, so those younger and with a more recent education should have even less difficulty.

Some applications will break, but will be fixed if they're supported or are open source. Using unsupported, closed source programs is itself a problem and will remain so; this sad fact should not be allowed to impede progress for the rest of us.

It is not a question of learning. It is a question of how much changes can be done at the same time.

Don't you see the need for a migration strategy, instead of a "big bang"?

Sven

Nobody is advocating a "big bang". But "deprecated" has a pretty clear meaning. IPV6 has been around for 10+ years now in Linux. It is not brand-spanking new, which is what Steven was talking about. It works reliably today, where it was pretty shaky when it first appeared in the Linux kernel as an experimental feature.

However, back to the point. "Migration" is not forever. There must be a drop-dead data. Everyone puts the conversion off until it is forced on them. Analog TV is an example. The US Congress even extended the "shut off the analogue broadcast transmitters" because everyone fiddled around for 5+ years and then suddenly couldn't get everything ready at the last minute. No deadline, no conversion.

[rbarreira]

Almost all porting issues can be solved with only a very few code changes plus recompilation and linking with the right libraries. Problems due to having a mixed IPv4/IPv6 environment have already started to decline and will continue to do so.

How can they have started to decline if IPV6 has not yet started to be widely used?

The necessary code has already been written, tested, and is generally freely available; at least for those using Linux, Mac OS/X, or other Posix compliant platforms.

But here again, we have a "real world" with all these millions of Windows PCs and Windows servers ... They are there, and they will continue to be there. And they have software which must be ported, too. When will that be done?

I also mentioned the millions of home office routers. Do you think they can be thrown away all at once? Network printers? Hubs? You can't, so your software must continue to be aware of "old" and "new" IP world at the same time.

It is not hard to learn. I started programming back in 1969 and I've managed to figure out these new things without too much effort, so those younger and with a more recent education should have even less difficulty.

Some applications will break, but will be fixed if they're supported or are open source. Using unsupported, closed source programs is itself a problem and will remain so; this sad fact should not be allowed to impede progress for the rest of us.

It is not a question of learning. It is a question of how much changes can be done at the same time.

Don't you see the need for a migration strategy, instead of a "big bang"?

Sven

Nobody is advocating a "big bang". But "deprecated" has a pretty clear meaning. IPV6 has been around for 10+ years now in Linux. It is not brand-spanking new, which is what Steven was talking about. It works reliably today, where it was pretty shaky when it first appeared in the Linux kernel as an experimental feature.

However, back to the point. "Migration" is not forever. There must be a drop-dead data. Everyone puts the conversion off until it is forced on them. Analog TV is an example. The US Congress even extended the "shut off the analogue broadcast transmitters" because everyone fiddled around for 5+ years and then suddenly couldn't get everything ready at the last minute. No deadline, no conversion.

It works reliably at the operating system level, sure. (or at least we think it does)

At the ISP level, home router level, common applications level and probably others, it's not anywhere near working yet. Sure, you can find some ISPs, routers and applications which do support it, but most don't.

I think most of the effort will have to come from ISPs. Most end users do not know or care. Many wouldn't notice if they're put behind a NAT due to IPv4 exhaustion either... Unfortunately.

[sje]

Some home routers have been IPv6 compliant for years. I believe that Apple's AirPort router (and Mac OS/X) has had IPv6 support for over a decade. Of course, it's not the cheapest router available. Purchasers that base buying decisions only on price can get burned in the long run. This has always been the case and will continue to be.

Where will all the cheap, non-upgradable home routers go? The same place the analog televisions went.

I am not responsible for others' choices of hardware and software; I don't expect them to be responsible for mine. But I do expect others to not impede the progress of the rest of us.