Managing and resolving problems in an IPv6 network requires at least a review of the backend tools used so far, if not brand new tools. Because even the mere length of an IPv6 address is often a problem for some databases that were not designed for such addresses. Many IT administrators who did a conversion without a previous backend check report that Analyzer and other monitoring tools were often not IPv6 compliant. With my ip this is a very important deal now.
Hardware upgrades against performance degradation
Headers now take up more space despite less complexity. At 40 bytes they are twice as large as in IPv4 applications. For applications that rely on small packet sizes, this will have a noticeable impact. For example, SIP uses small packets averaging 1,000 bytes in size. Enlarging the header will increase the packet size by about 2 per cent, which in extreme cases can be noticeable.
Performance is a common problem in the IPv6 network infrastructure. Although most systems allow IPv6 migration, this does not mean that the performance of the systems will not deteriorate if they change from IPv4 to IPv6. The adaptation of the firmware is in this context a first step in the right direction. But with a comprehensive internal changeover, without hardware upgrades in much of the network infrastructure, you will not be able to maintain the system performance that customers and employees expect today.
New SPAM filters
Today’s SPAM blockers rely mainly on DNS blacklists, which become worthless when switching to IPv6. Under IPv4, hosts can only reach a few hundred addresses the listing and blocking of individual addresses remains manageable. Under IPv6, however, hackers can assign thousands of addresses to a server and choose a new, unused address for each SPAM message.
Sending in IPv6 areas in DNS blacklists, as is currently the case with IPv4, is not an option: the areas would be so large that caches and DNS servers would collapse. Additionally, DNS caches tend to favour the newest answers over older ones. Thus, the flood of blacklist data would force all other DNS information out of the cache. Most systems use the same cache for blacklists as they do for all other DNS requests. This will increase the load on all other DNS servers that need to retrieve the answers deleted from the cache.
Even if DNS blacklist servers create a single DNS wildcard to cover a large range of entries, this does not help. DNS caches cannot tell if a wildcard is answering, so a new entry will be created for each answer. Companies should, therefore, ensure that their SPAM protection provider has updated their products in relation to these issues.
The addition of IPv6 to the dual stack will be necessary sooner or later. Some companies have already started and gained experience. Those who heed the seven pointers presented above will be able to avoid many problems with the new protocol from the outset and be better able to take advantage of and benefit from it.