Does PA support or will support IPv6?

Considering that IPv4 address space is exhausted. Does PA support or will support IPv6?

In PA's case isn't that more so the nature of the server itself?

Mike

If I remember things right, there was a discussion about IPv6 (dualstack actually with IPv4 mapped into IPv6) in February and neutrino said that it was postponed, but would be added at some point.

I don't know if it has been added yet or if the whole network stack (actually only the lowest layer is affected) is still IPv4 only, but if it hasn't been added yet, it will be until release.

I guess the game will need to be v6 compliant on release, as players will then be able to create their own game servers, and some of these will be v6 by default. If you can't address v6 servers, you can't play in v6-served games. I'm also assuming that we'll be able to play networked via IP addresses, as per TA.

Well both the server and client must support it. In order to communicate with one another. Right now is a transitional period going from Internet Protocol version 4 to version 6. The most ISPs in North America still run IPv4 but most of the places like Asia, Africa, etc. use IPv6. So it important that PA supports it in the future.

You're right, I didn't have time search for posted because had to go to work. found that discussion and some more on the same topic. Here those posts:

https://forums.uberent.com/threads/for-server-focus-on-linux.46161/#post-721648
https://forums.uberent.com/threads/ipv6-support-for-network-play.34591/

They're all interesting.

Yes, it would have to be or later patch and both use IP addresses to just look completely different. IPv4 uses a 32-bit address space where IPv6 uses a 128-bit address space. And both notated completely differently one uses hex the other one doesn't. Examples: 192.168.20.110 is a IPv4 address and ::C0A8:146E is a IPv6 address.

but the point is it's necessary to future proof the project.

EDIT: is a [IPv6] address

I'd be highly surprised if IPv6 support isn't in PA. The internet has been raging about this for years.

Ah, so it was May, not February.

The difference isn't an issue at all, if the underlying OS is dualstack capable, IPv4 can be treated as a subnet of IPv6, to be specific ::ffff:192.168.20.110 is a valid IPv6 address (IPv6 mapped IPv4) and routed to 192.168.20.110 by any dual stack capable OS / router (which includes any modern OS short of unpatched Windows XP, SP3 brings IPv6 support, but it has yet to be activated manually). Incoming packets on a dual stack socket get converted to IPv6 the same way. Thats not tunneling, but actually real IPv4 inside of IPv6 address space for backward compatibility.

And thats the reason why there probably isn't any IPv6 support yet. For time savings, the network layer of an older application was used as a base and that didn't have IPv6 support yet.

As long as they support it at some time.

This is not a valid IPv6 address. a valid IPv6 address is represented by hexadecimal groups and separated by colons.
http://en.wikipedia.org/wiki/IPv6

They should also support RFC 2324 and RFC 1149.

My US ISP uses IPv6 and I play PA.

I want to support it long term but it's not in the current version. It won't be too hard to get it in there.

It actually is. http://tools.ietf.org/html/rfc4291#section-2.5.5.2 describes this type of address and the format I used is the alternative form #3 as described here: http://tools.ietf.org/html/rfc4291#section-2.2

Wikipedia is NOT a reliable source, you should know that. (Except that you would have found that notation in that article too).

Good

As an addendum: ::ffff:0.0.0.0/96 is a valid IPv6 address format (IPv4 mapped IPv6), great for inside-the-program, but must never be seen on the wire.

Also, when representing it, an application should never show it, it should just strip the ::ffff: prefix from the front before displaying it to the user.

Typically this is used so that the programmer can use sockaddr_storage structure which can represent multiple sockaddr variants (sockaddr_in for IPv4, sockaddr_in6 for IPv6 and sockaddr_un for UNIX sockets amongst others).

More details can be found on google(eva ipv6) aka http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html

It is a valid IPv6 transitional address but it is something I would never want to see in any production environment. It is merely a hack like NAT was to deal with IPv4 exhaustion to give sometime to figure out a permanent solution to it. Like the other forms of transitional IPv6 technologies such as dual-stack, 4to6, or 6in4. You would only want to put them on your edge router on the interface that is connected to your ISP or ISPs. This does a couple things. First it does not hurt network performance. Second makes troubleshooting easier by not doubling network stacks which increases complexity in the network and the time required to come up with a solution. In short you want your network to be, reliable, have good performance, and scalable.

@exterminans what I really meant was it wouldn't be a good idea for a production network. An issue about Wikipedia not being a reliable source for me it's good enough for this forum if I was on a networking forum and yes. I would have used the RFC as a source but I didn't. Also misread the article only human.

There have been two independent studies on how reliable Wikipedia is. Both of them found at Wikipedia scientific and technology articles have less errors than the encyclopedias that they check against. one of the reasons they believe that it took those specific articles are of higher quality it's because of the people writing them. They tend to be more methodical than other groups of people. It's also good to note that both studies say treat their findings with a grain of salt and more studies are required. If I remember the universities that did these studies I would cite them.

> It is a valid IPv6 transitional address but it is something I would never want to see in any production environment.

You will not see it in "production" as it never goes on the wire. On Linux old versions of 'netstat' showed them though when a socket was AF_INET6, but the connecting application was IPv4. The net.ipv6.bindv6only sysctl on Linux changes that behavior (0 is default though, as otherwise many programs would not support both IPv4 and IPv6).

> It is merely a hack like NAT was to deal with IPv4 exhaustion to give sometime to figure out a permanent solution to it.

It is not a hack at all. It (IPv4-mapped IPv6 addresses) is a great way to store an IPv4 address inside a 128bit datafield without having to have two fields, one for IPv4 and one for IPv6 and then another to indicate version. I use it all the time in as good as every program I write (and I've done a few IPv6 ones...).

> Like the other forms of transitional IPv6 technologies such as dual-stack, 4to6, or 6to4.

Dual-stack is definitely a permanent situation.
What is 4to6? Never heard of that.
6to4 is actively in process being marked for deprecation (see ipv6-ops mailinglist).

> You would only want to put them on your edge router on the interface that is connected to your ISP or ISPs.

IPv4-mapped-IPv6 addresses MUST NEVER be configured on an interface or used on the wire.
They are just for representing an IPv4 address inside an IPv6 one, nothing else.

> This does a couple things. First it does not hurt network performance. Second makes troubleshooting easier by not doubling network stacks which increases complexity in the network and the time required to come up with a solution. In short you want your network to be, reliable, have good performance, and scalable.

You are confusing me a lot with this sentence as it does not make sense. Hence please elaborate.

Having separate stacks (IPv4 and IPv6) is a great thing. It makes debugging MUCH easier, than if you would be mixing them.

Having two stacks will not cost any performance (unless you are at the limits of your hardware/software combo), it will not make it less reliable (only more reliable, eg when IPv4 is down IPv6 still works). And scalability in a network comes from having addresses and the ability to hierarchically allocate them.

> what I really meant was it wouldn't be a good idea for a production network

As above, you will never see ::ffff:0.0.0.0/96 on the wire (unless somebody misconfigured something which happens quite a lot with 6PE on Ciscos it seems).

@fuzzels

I believe we're talking about two different things.

Network address translation (NAT) was created to mitigate the exhaustion of IPv4 addresses as stated in RFC 1631. In conjunction with CIDR (classless inter-domain routing) was also used to slow down IPv4 exhaustion in order to give enough time to come up with a permanent solution.
rfc1519 rfc1518

Okay but only on the edge router not cross network.

My bad. I meant 4in6 instead of 4to6.

Good to know. That is to take a while.

I what thinking dual-stack.

At this point in time on network devices (E.g. routers, switches, etc.) IPv6 must be manually enabled per interface on the device. When it enable layer 3 (Network) to layer 8 (Application) traffic doubles because one is IPv6 and the other one IPv4. This is to separate network stacks to troubleshoot with their own separate commands. E.g debug ipv6 routing, ping ipv6, etc. You have twice the amount of troubleshooting to do in a fully dual stacked network. There is no benefit to it only grief and dual stack should be deployed only on the edge router.

It does when the hardware you're dealing with has finite resources. Network devices processors are generally in the megahertz range and 512 of RAM or lower which stores your routing table, etc. Routers and switches simply do not have the capacity to be running multiple network stacks. Especially when you take into account network load at peak times. Running both IP stacks do have a performance detriment which is miserable and which your end-users will complain about. When layers 1 and 2 go down your network breaks because you're only relying on dual stack. Scalability comes from good planning and foresight. Like not wasting IP addresses, have redundant links, a sensible topology, designing for growth, etc.

(only more reliable, eg when IPv4 is down IPv6 still works)
Please explain?

You can and Cisco provides a way to do that.
https://www.safaribooksonline.com/library/view/cisco-ios-cookbook/0596527225/ch25s13.html
http://www.cisco.com/c/en/us/td/doc..._4t/ipv6_12_4t_book/ip6-tunnel.html#wp1054203

Hence why I repeat "It (IPv4-mapped IPv6 addresses)" and "::ffff:0.0.0.0/96" several times

Not really. That depends on the operator in question.

Most networks out there today are dual-stack, especially transit networks. But there are some networks which are moving to IPv6-only (eg CERNET2) using DNS64 or other such tricks to allow hosts to connect to IPv4 resources.

The end-hosts will have to be dual-stack though, or at minimum support just IPv6.
As quite a few applications do not have IPv6 support, dual-stack is the minimum to be maintained.

Very very few networks use 4in6. But hat simply has to do with the mere fact that IPv4 is there and native IPv6 is still rare in most places and nobody wants to bother with the problems of debugging

Actually not. There are only a few (<5) 6to4 relays left globally and those will go down quickly.

Hence, while the protocol might be implemented in OSs and not disabled yet, only hosts with public IPv4 addresses will be doing host-to-host 6to4, which is already mostly the case because of RFC3484 address selection and of course the "great" Happy Eyeballs (great, as it does solve failover, but it makes debugging very unpredictable).

In dual-stack you do not configure an IPv4-mapped-IPv6 address :ffff:0.0.0.0/96) on an interface.
The IPv4 interface gets a normal IPv4 address, the IPv6 interface gets a normal IPv6 address (2000::/3).

I do not know of any such device. Please provide a brand/model so that I can kick the vendor to get into 2014, or more like 2004.

IPv6 comes enabled per default, and link-locals are always there. That one might have to configure IPv6 on the device is a different thing, one has to configure IPv4 too.

You are aware that IP does not follow the OSI model right?

Nonsense. One is not transmitting in both IPv4 and IPv6 at the same time.The only thing that one "adds" is a few bytes of IPv6 header, a full 20 bytes of them.

Of course you get new commands, you do need to point out the new stack.

Just like IPX commands are separate from the IPv4 ones.

Fortunately most CLIs have made it very simple, eg 'ip -6 addr show' and 'ip -4 addr show' etc.

You want to introduce the grief of DNS64 and other kind of translators? Eek.

The whole advantage of having separate stacks is that you can debug them separately.

Only when tunnels and translator tricks are involved do you need to look at them both at the same time.

The only thing you need to be making sure of that Happy Eyeballs does not mess things up by switching addresses all the time. OSX is a lot of fun in that regard.

The speed of your CPU in a switch/router does not matter (too much) as most of the work is done in hardware. If you are at the limits of that capacity (as written above too), then you have those problems anyway. Get new hardware, one had almost 20 years to know that IPv6 was coming and it is not that people have not been telling that to folks.

Then why does the world keep on running and IPv6 is growing and growing everyday? Oh, yeah, hardware and software have a lifecycle and it gets replaced every once in a while.

What about upgrading your gear instead? You should never go over 80% of your load, if you do, upgrade. If you don't you are doing the wrong thing. (Talking enterprise networks, not your random home network here).

I have been running dual-stack IPv4 + IPv6 for over 15 years. Do you got any papers that show these imaginary problems?

Yeah, so in the OSI model (which does not apply to IP), Layer 1 == physical. Indeed when your physical layer (cable, wireless) is broken, nothing on the upper layers will work...

Nonsense.

Like upgrading your hardware in time to support both IPv4 and IPv6?

Or like introducing a new protocol that supports all of that; next to that dual-stack (which you seem to dislike) provides this 'redundant links' in a different way: if IPv4 is broken, one could still use IPv6.

Exactly like I state it. Lets say you have a full dual-stack network: A - B - C - D - E -F

B,C,D,E are routers, all nodes do both IPv4 and IPv6.

The operator of C misconfigures IPv4, eg removes the IP address. Hence the IPv4 network is split.
As IPv6 is not misconfigured, it just keeps on working though.

Or more practical example: you misconfigure the IPv6 firewall on node F, but the IPv4 firewall still lets you in. (Great trick for being able to change firewall rules in one protocol without affecting the other

NAT-PT is obsoleted for big reasons. See http://tools.ietf.org/html/rfc4966