At the recent NY Tech Community Holiday Party I handed out pins that said IPv6 or bust!. They were well received and stimulated many discussions, particularly on what killer app might drive adoption. One suggestion was VoIP mesh networks. The pins are available free online via ISOC-NY.
Besides Bechtel, other US companies with Enterprise IPv6 transitions well under way are Cisco, Microsoft, and EMC. There may be others, but these are the Corporations that we have been involved with. We are also helping several vendors "IPv6-enable" their enterprise IT products. At Command, we "eat our own dogfood" and have been operating a native v6 environment since we were founded in 2006.
By Bill Shelton (not verified) on Wed, 12/19/2007 - 9:23am.
After more than a decade- IPv6 remains a solution in search of a problem. The question is not how many how many IP addresses do we need, but how many public IP addresses do we need. Network Address Translation (NAT) insured that the typical enterprise had no need of IPv6.
True, some day, we won't have enough public IP addresses available and some businesses will need to make a transition. The slow uptake confirms, there are no killer apps, at least not yet. Perhaps there never will be.
The security related issues are the most important to work out before enterprises move in mass to widespread IPv6 deployments.
I can admit that vendor solutions are slightly lagged behind, but according to our tests the open source community has decent security solutions for IPv6 environments....
By Truman Boyes (not verified) on Sat, 12/22/2007 - 6:38pm.
As far as IPv6 capable firewalls and packet filters go, there has been quite capable ipv6 support in Juniper's JUNOS for many years. I think many of the state-based firewalls on the market are not yet fully IPv6 and the associated Application Layer Gateways (ALGs) within these firewalls are not yet fully v6 ready.
I agree with your sentiments; the open source tools are really tracking quite quickly with full v6 support.
By Robert A. Rosenberg (not verified) on Wed, 12/19/2007 - 3:59pm.
I am getting a little tired of all the articles that claim that going to IPv6 from IPv4 will increase the number of addresses from 2^32 to 2^128 (since the addresses go from 32 bits to 128 bits). The correct number is 2^64 since the 2nd 64 is used as the Node Number (ie: The Mac Address of the Node). In fact I think that the equivalent of a IPv4/32 address is an IPv6/48 since that is the size of the prefix assigned to each user.
IOW: When my ISP currently gives me a /32 address, under IPv6 I will get a /48 (with bits 48-63 used by me to set up different addresses for different purposes).
I cannot understand the government and corporate mandates for internet transmittable IPV4 addresses for internal systems!
RFC1918 address space was specifically designed to address the needs of internal enterprise addressing to the tune of 16M+ addresses/enterprise using the 10.0.0.0/8 address space or 1M+ addresses/enterprise using the 172.16.0.0/12 address space. I actually like to use both spaces, the 10. for clients, and the 172.16 for datacenters giving two discreet encryption domains for further isolation, even within the enterprise.
Internet access or extranet access can be implemented using internet accessable IP addresses that are NATed (for host service applications) or PATed (for client service applications) at the boundry between the intranets.
Even the 1st through 3rd tier ISPs could use RFC1918 IPV4 addressing on their internal infrastructure with no impact on their EBGP routing.
An added bonus of RFC1918 IP addresses on the intranet is that it is more difficult to penetrate the internal infrastructure as the internal systems will not respond directly to a internet initiated query or attack.
IPv6 is a wonderful idea, but it must be fully implemented by the ISPs prior to corporate or governmental uptake, and that has to occur prior to the trickle down to end users. In the meantime there will have to be major processing power given to the ongoing translation between IPv6 and IPv4 services until IPv6 is fully implemented and supported, which will cause even more headaches than we have now.
The Leader in Network Knowledge
IPv6 or bust!
At the recent NY Tech Community Holiday Party I handed out pins that said IPv6 or bust!. They were well received and stimulated many discussions, particularly on what killer app might drive adoption. One suggestion was VoIP mesh networks. The pins are available free online via ISOC-NY.
Joly MacFie
Businesses deploying IPv6
Besides Bechtel, other US companies with Enterprise IPv6 transitions well under way are Cisco, Microsoft, and EMC. There may be others, but these are the Corporations that we have been involved with. We are also helping several vendors "IPv6-enable" their enterprise IT products. At Command, we "eat our own dogfood" and have been operating a native v6 environment since we were founded in 2006.
David Green
VP of R&D
Command Information
IPv6 is still a solution in search of a problem
After more than a decade- IPv6 remains a solution in search of a problem. The question is not how many how many IP addresses do we need, but how many public IP addresses do we need. Network Address Translation (NAT) insured that the typical enterprise had no need of IPv6.
True, some day, we won't have enough public IP addresses available and some businesses will need to make a transition. The slow uptake confirms, there are no killer apps, at least not yet. Perhaps there never will be.
The security related issues are the most important to work out before enterprises move in mass to widespread IPv6 deployments.
Security solutions
I think there is good amount of security research has been done until now:
http://www.6net.org/publications/deliverables/D3.5.1v3.pdf
See RFC 3964, RFC 4890, RFC 4891, RFC 4942
I can admit that vendor solutions are slightly lagged behind, but according to our tests the open source community has decent security solutions for IPv6 environments....
RE: security
As far as IPv6 capable firewalls and packet filters go, there has been quite capable ipv6 support in Juniper's JUNOS for many years. I think many of the state-based firewalls on the market are not yet fully IPv6 and the associated Application Layer Gateways (ALGs) within these firewalls are not yet fully v6 ready.
I agree with your sentiments; the open source tools are really tracking quite quickly with full v6 support.
Number of IPv6 Addresses
I am getting a little tired of all the articles that claim that going to IPv6 from IPv4 will increase the number of addresses from 2^32 to 2^128 (since the addresses go from 32 bits to 128 bits). The correct number is 2^64 since the 2nd 64 is used as the Node Number (ie: The Mac Address of the Node). In fact I think that the equivalent of a IPv4/32 address is an IPv6/48 since that is the size of the prefix assigned to each user.
IOW: When my ISP currently gives me a /32 address, under IPv6 I will get a /48 (with bits 48-63 used by me to set up different addresses for different purposes).
Restructure of Government/Corporate Networks vs. IPv6 near term
I cannot understand the government and corporate mandates for internet transmittable IPV4 addresses for internal systems!
RFC1918 address space was specifically designed to address the needs of internal enterprise addressing to the tune of 16M+ addresses/enterprise using the 10.0.0.0/8 address space or 1M+ addresses/enterprise using the 172.16.0.0/12 address space. I actually like to use both spaces, the 10. for clients, and the 172.16 for datacenters giving two discreet encryption domains for further isolation, even within the enterprise.
Internet access or extranet access can be implemented using internet accessable IP addresses that are NATed (for host service applications) or PATed (for client service applications) at the boundry between the intranets.
Even the 1st through 3rd tier ISPs could use RFC1918 IPV4 addressing on their internal infrastructure with no impact on their EBGP routing.
An added bonus of RFC1918 IP addresses on the intranet is that it is more difficult to penetrate the internal infrastructure as the internal systems will not respond directly to a internet initiated query or attack.
IPv6 is a wonderful idea, but it must be fully implemented by the ISPs prior to corporate or governmental uptake, and that has to occur prior to the trickle down to end users. In the meantime there will have to be major processing power given to the ongoing translation between IPv6 and IPv4 services until IPv6 is fully implemented and supported, which will cause even more headaches than we have now.
Post new comment