IPv4 is pretty much everywhere. It uses 32-bit addresses, which means (and you can check the maths on this) that there is a finite number of IP addresses that people can use – 4,294,967,296 addresses, in fact. Although the number of available addresses seems pretty large, you only have to look round at how online everything is to recognize that those addresses will run out. In fact, they already have – although techniques such as Network Address Translation (NAT), classful network design, and Classless Inter-Domain Routing have helped to keep everything working.
Back in the 1990s people (including me) were writing about the address limitation of IPv4, and the proposed solution was IPv6, which, after a very long gestation period, became commercially available in 2006. World IPv6 Launch day was as recently as 6 June 2012. The big selling point of IPv6 is that it uses 128-bit addressing, which results in far more addresses being available for people to use – 340,282,366,920,938,463,463,374,607,431,768,211,456 apparently.
An IPv4 address looks like: 192.169.1.62. An IPv6 address looks like: 2001:0db8:85a3:0042:0000:8a2e:0370:7334. And that’s the problem that many organizations face. How to they convert from IPv4 to IPv6? How do they translate their addresses? How do they test these new addresses when they need to maintain a working business environment?
William Data Systems (WDS) has come up with a new module for its ZEN system called the ZEN Application Gateway – or ZAG. WDS has found that many of its customers are currently facing the costs and risks of changes to applications, networks, and hardware. ZAG helps implement IPv6 under z/OS by minimizing the need for companies to make any changes to their applications, hardware, or networks. ZAG users can input IPv4 and get out IPv6, or they can do things the other way round.
And while z/OS sites are able to run separate IPv4 and IPv6 stacks – in fact, keeping the two IP stacks segregated like this may be something many chose to do because it enables them to keep their IPv6 testing traffic separate from their production IPv4 traffic – one thing they could use ZAG for is to sit in between the two stacks and act as a bridge, allowing IPv6 clients in one stack to access IPv4 applications in another stack (and vice versa). Obviously, sites could do achieve the same thing without ZAG, but they would need to weigh up the additional costs and risks (as well as management time) resulting from application, network, and hardware changes.
According to WDS’s press release, ZAG “allows customers to:
Back in the 1990s people (including me) were writing about the address limitation of IPv4, and the proposed solution was IPv6, which, after a very long gestation period, became commercially available in 2006. World IPv6 Launch day was as recently as 6 June 2012. The big selling point of IPv6 is that it uses 128-bit addressing, which results in far more addresses being available for people to use – 340,282,366,920,938,463,463,374,607,431,768,211,456 apparently.
An IPv4 address looks like: 192.169.1.62. An IPv6 address looks like: 2001:0db8:85a3:0042:0000:8a2e:0370:7334. And that’s the problem that many organizations face. How to they convert from IPv4 to IPv6? How do they translate their addresses? How do they test these new addresses when they need to maintain a working business environment?
William Data Systems (WDS) has come up with a new module for its ZEN system called the ZEN Application Gateway – or ZAG. WDS has found that many of its customers are currently facing the costs and risks of changes to applications, networks, and hardware. ZAG helps implement IPv6 under z/OS by minimizing the need for companies to make any changes to their applications, hardware, or networks. ZAG users can input IPv4 and get out IPv6, or they can do things the other way round.
And while z/OS sites are able to run separate IPv4 and IPv6 stacks – in fact, keeping the two IP stacks segregated like this may be something many chose to do because it enables them to keep their IPv6 testing traffic separate from their production IPv4 traffic – one thing they could use ZAG for is to sit in between the two stacks and act as a bridge, allowing IPv6 clients in one stack to access IPv4 applications in another stack (and vice versa). Obviously, sites could do achieve the same thing without ZAG, but they would need to weigh up the additional costs and risks (as well as management time) resulting from application, network, and hardware changes.
According to WDS’s press release, ZAG “allows customers to:
- Test new IPv6 applications using their existing IPv4 infrastructure
- Access their IPv4 applications from new IPv6 clients
- Segregate their IPv6 and IPv4 traffic on different IP stacks
- Act as a bridge, allowing traffic to connect between IPv6 and IPv4 stacks
- Provide pseudo Network Address Translation (NAT) capabilities in an IPv6 environment, which is very useful if you want to hide internal IPv6 addresses from the outside world.”
If you are at SHARE in Anaheim between 5 and 10 August, WDS will be demonstrating their ZEN suite on a Raspberry Pi. WDS comment this is: “just in case hardware budgets keep reducing!” Adding that one lucky delegate will win the Raspberry Pi in the SHARE prize draw.
Here’s a photo of their Raspberry Pi in action!
Moving from the limited IPv4 to IPv6 is something that people have been talking about for a long time. It now looks like the time to actually migrate is here. Anything that makes the job easier (and the painless) has got to be a good thing.
Moving from the limited IPv4 to IPv6 is something that people have been talking about for a long time. It now looks like the time to actually migrate is here. Anything that makes the job easier (and the painless) has got to be a good thing.
No comments:
Post a Comment