Networking

IPv6 and IPv4 mixed mode nodes inevitable

Rick Vanover looks ahead to the time when implementing IPv6 across the board will be necessary. What changes will be necessary and how should you prepare for it now?

I am starting to look at Internet Protocol version 6 (IPv6) for selected live systems. While I do not have a particular need or requirement for using the updated version of the lifeblood of my network, I want to start formulating plans and scenarios so that there are no surprises when the time comes to implement IPv6 across the board. The feature list of IPv6 is compelling with IPSec, 128-bit address space, built-in efficiency, and the removal of subnet masks, making perfect sense when engineering is a protocol.

All that is fine and good; it is just that the change is going to be a real pain. One of the bigger inhibitors in migrating to IPv6 is that it does not have native backward compatibility. This alone effectively mandates dual-stack nodes. In fact, Windows Server 2008 default installations load both IPv4 and IPv6 protocol stacks. There is no guarantee for applications to work correctly with IPv6. This will be an issue, and identification of the applications that will not function correctly in the IPv6 address space will be an involved discovery process.I feel that the dual-protocol world will exist for a while once IPv6 becomes frequently used, possibly with IPv4 address spaces used exclusively in internal networks, a cross-version of NAT if you will. This, however, is only a stopgap solution. DNS will be playing a key part of the coexistence of both IPv4 and IPv6. One example is that Windows Server 2008’s DNS server supports both versions of TCP/IP within DNS on the same server instance. Take the standard host (A) record, in IPv6 it is now the AAAA record. The figure below shows the creation of the AAAA record in the DNS console in Windows Server 2008:

DNS AAAA record creation

Only once a basic framework for IPv6 is in place and then put to use will we be able to identify what kind of growing pains are going to be upon us. How are you testing and preparing for IPv6 in your environment? Share your comments below.

About

Rick Vanover is a software strategy specialist for Veeam Software, based in Columbus, Ohio. Rick has years of IT experience and focuses on virtualization, Windows-based server administration, and system hardware.

5 comments
PhilippeV
PhilippeV

URL parsing is a current compatibility issue for some good reasons: there are still tons of applications that do not use DNS names for their host names but only IPv4 addresses in decimal dotted notation, like 127.0.0.1. However, IPv4 addresses in this notation is transparently parsed in URLs as it uses the same characters as the lone used in DNS names: only digits and full stops. This is not the case with IPv6 addresses used as host names, because: * they require using a ":" separator * they have several "canonical" representations, depending on if they are compressed or not (nortmally IPv6 addresses are formatted using eight 16-bit blocks, each one separated by ":" and coded using 4 hex digits, but you may omit the leading zeroes, or even the complete 16-bit subfield if it is null, and the ":" separator between two successive null subfields). This makes the validation and canonicalization of IPv6 address formats a bit more complex. * the presence of ":" in the host name would make it normally incompatible with URL formats, that use ":" as the separator between a hostname/address and a service port number; to solve the ambiguity, the URL format for IPv6 addresses requires surrounding IPv6 address notations between [square:brackets]. The square brackets are forbidden in normal host names (including for DNS application using hast names accessible only through IPv6) So ULR parsers need to be updated. however there are LOTs of implementations of URL parsers that are currently checking the restriction of host names to only letters, digits, hyphens and full stops. And too many applications that are parsing URLs by looking for the location of the first ":" that occurs in the URL between the URI scheme + hostname indicator prefix (like "http://" or "https://" or "ftp://") and the first slash that indicates the path, and assume that this ":" is separating the hostname and the port number. These applications need to be updated to correctly parse the URLs, and also to accept the extra "[:]" characters present in IPv6 host names. It's not complicate to program, but finding all locations in currently deployed software where such assumption for IPV4 only was made can be tricky. Of course, the use of IPv6 addresses in URLs is highly discouraged: you shoud use a DNS-resolved hostname and name name instead, and use hostname-to-address resolution APIs where ever possible. This means that some environments will need to install a DNS server, where one was not needed with IPv4-only networks; but some hardware devices are still not supporting DNS resolutions, and absolutely want a numeric address (look for example in the very limited configuration panels of many printers with a LAN connection over Ethernet or WiFi...) ---- Many routers and home gateways are incompatible and do not support dual stacks. This is probablyt the most major issue for deploying IPv6 everywhere to all customers, so few ISPs have done their homework to also support IPv6 routing over their PPP or VLAN connections through the access WANs they are currently selling. ---- Applications also need to be prepared so that when resolving hostnames to IP addresses, they will accept an IP address in either 32-bit or 128-bit space: this means that applications using standard hostname-to-address APIs (in socket libraries) need to detect which address format will be returned, and correctly remember it when further binding their sockets or accepting connections. Many socket applications will not support IPv6 addresses correctly if they are returned by "gethostaddress()" socket-like API's. ---- The final problem will be to prepare the firewalls to new routing rules: their configuration in IPv6 may be tricky, because IPv6-compatible hosts and services frequently use multiple addresses simultaneously (remember that IPv6 does no longer support broadcast addresses for local network discovery of hosts and services, and more complex rules must be used and configured in addition to keeping the rules already made for IPv4 that are generally preconfigured in IPv4 using simple netmasks; for IPv6 you need multiple netmasks, otherwise you loose the possibility offered by the great IPv6 "zero-knownledge" autoconfiguration which permits great things like allow host to be reachable from multiple networks simultaneously with distinct IPv6 addresses for each but just a common address part in the least signifivant bits of the address; this great IPv6 feature is meant to forget the nightmare of NAT routing in IPv4 for network interconnections). Finally, you should know that IPv6 providers and ISPs will not provide you with a single IPv6 address but instead a quite large block of IPv6 addresses for your connection. Normally this block is offered so that you can effectively map local IPv4 addresses directly yo IPv6 using the prefix of the IPv6 address block and fitting your local IPv4 addresses in the lowest bits of the IPv6 address: no configuration is need in routers, that can perform this mapping automatically for you; however some ISPs were lazy and are only offering a single IPv6 address (just like the providers of 6-to-4 gateways which are just transitory solutions not meant for performance but just for compatibility with IPv4-only networks).

shahemail
shahemail

In US the major IPv6 driver is to meet the commitment to the US government agencies, which are under an OMB (Office of Management and Budget) mandate to upgrade their networks to be IPv6-ready by June 2008. It is expected that IPv4 and IPv6 will coexist for a long time. In an Enterprise network, some sites may move to IPv6 (Dual Stack) first, while others continue to use IPv4. In such cases, IPv4 and IPv6 will co-exist on the same network hardware and infrastructure and the network is required to support both IPv6 and IPv4 services. Applications must support dual stack where a network administrator will able to configured in IPv4 only, Dual stack or IPv6 only to meet various deployment scenarios. The clients, servers and endpoint device may need IPv4 and IPv6 addresses depending upon a network design and features requirements. In a commercial world IPv6 only network are possible but not envision. Future DoD tactical network will be one the driver for the IPv6 only network where no IPv4 addresses are required.

b4real
b4real

That is true, but there are a lot of networks that are not under the regulations you describe above. Me, as the simple network guy, would rather NOT have multiple versions of IP running - but I have conceded that it is inevitable. I find this somewhat similar to the battle to remove WINS from the network and replace with DNS!

shahemail
shahemail

IPv6 deployment issues are not same as=>: Each WINS server holds a full copy of every other related WINS system's records. There is no hierarchy in WINS (unlike DNS), but like DNS its database can be queried for the address to contact rather than broadcasting a request for which address to contact. WINS and DNS will support both IPv4 and IPv6 and IP stacks for a given application.

b4real
b4real

I'm saying this is another example where old and new will co-exist, probably longer than planned. I didn't say they were the same.

Editor's Picks