Section 10.7. What Is Missing?
10.7. What Is Missing?The interest in IPv6 has grown a lot in the last year. Allocation of IPv6 address space has increased significantly. Many of the IPv6 deployments are experimental and research-based. Just like with IPv4, these institutions gathering early adopter experiences for the benefit of the whole market are universities, research networks, and government agencies. This section outlines some of the missing pieces for broad IPv6 deployment. We hereby refer to a report created as part of the 6net project. The full report can be found at http://www.6net.org/publications/deliverables. 10.7.1. IPv6 RoutingIPv6 routing is robust and performs well. This has been proven in many different tests worldwide. The implementations in common router equipment are well-tested and optimized. It is important to verify that you are using router models that support hardware-based IPv6 routing. The performance of IPv6 in the Internet will probably not be optimal in the early days because in the beginning, most of the Internet is IPv4-based and IPv6 tunneled. With the growing number of IPv6 Internet backbones, this situation will change. Check with your ISP to find out what kind of connection they have to the IPv6 Internet. When using tunnels, check the available options and choose your tunnel endpoints carefully. 10.7.2. Protocol Selection on Dual-Stack NodesAs already mentioned in "DNS" in Chapter 9, a way will have to be found to optimize address selection on dual-stack nodes. The behavior of a dual-stack node largely depends on the implementation. If both protocols are available, a choice has to be made either by the application or by the protocol stack. The presence of A or AAAA records in DNS is no indicator to a dual-stack client which protocol would be the better choice and whether the service is reachable over both protocols. There are many situations and combinations possible here. The situation has to be analyzed and the best possible configuration chosen individually. 10.7.3. Multihoming with IPv6Multihoming is when a host or a site is reachable over different IP addresses. A multihomed host has multiple global IP addresses. These addresses can come from one or more different providers, and they can be assigned to one or more different interfaces on the host. A multihomed site is connected to the Internet with multiple global IP addresses from one or different providers. The main reasons to configure multihoming are the following:
The autoconfiguration features of IPv6 support an easier maintenance of multihoming scenarios because devices are more flexible in recognizing network prefixes and can configure multiple IPv6 addresses based on Router Advertisements. In the common IPv4 multihoming approach, a site's local prefixes are announced as distinct routing prefixes into the inter-domain routing system and propagated to the top-level hierarchy of the routing system. This approach works well if the address space of the site is provider-independent. But even though this approach covers most of the requirements for multihoming, it is not scalable. With the growing number of multihomed sites on the Internet, the number of prefixes in the global routing system increases linearly. The common opinion is that even modern routing hardware will eventually be overloaded in dealing with the number of entries in the global routing tables. Additionally, with IPv6, there is currently no such thing as provider-independent address space. For these reasons, multihoming is an actively discussed topic in the working groups. The goal is to find solutions that provide multihoming without the scalability and transport issues. If you want to follow the discussions and upcoming specifications, go to the Multihoming Working group at http://www.ietf.org/html.charters/multi6-charter.html and http://tools.ietf.org/wg/multi6. They not only discuss the operations and known limitations of multihoming with IPv4, they provide lists of things to look at when designing multihoming, and discuss architectural approaches and possible threats for multihomed sites. One of the proposals currently discussed is the Shim6 approach. The "Site Multihoming by IPv6 Intermediation" working group (http://www.ietf.org/html.charters/shim6-charter.html) will produce specifications for an IPv6-based site multihoming solution. It adds a new layer (shim) into the IP stack of end-system hosts. The approach enables hosts on multihomed sites to switch between a set of provider-dependent address prefixes and still allow applications to find alternate paths if one or more of the prefixes become unavailable. You can find the list of current drafts in the working group and at the end of this chapter.
10.7.4. DNSResolving DNS names over IPv6 is not implemented in all operating systems yet. With BSD and most Linux resolvers, this is not a problem. Windows XP does not support it. A client that cannot resolve DNS over IPv6 always needs to be dual-stacked and needs a DNS server that is accessible over IPv4. Not all official registration agencies offer the registration of IPv6 DNS domains. This is important if you want to register IPv6-only services.
10.7.5. Network ManagementThe most important standard for network management is SNMP (Simple Network Management Protocol). There aren't many implementations of SNMP over IPv6 yet. You can monitor your IPv6 network with SNMP over IPv4, though, so you only have a problem if you want to monitor an IPv6-only network. The number of IPv6 MIBs (Management Information Base) is still limited, and there are no IPv6 Multicast MIBs yet. If you need an updated list of available MIBs, visit your RFC search engine and enter the search term "MIB". A similar problem exists with the management of wireless access points. There is no problem running Wireless LANs with IPv6. But the configuration and administration of wireless access points is usually only possible over IPv4 or through the serial interface. 10.7.6. IPv4 DependenciesMany issues with IPv6 arise because of the IP address format. For this reason, a huge effort has been made to analyze all existing RFCs for dependencies on IPv4 addresses. The results of this analysis have been published in a number of RFCs. In case you are interested in more details, here's the list of RFCs:
|
- Article 332 Mineral-Insulated, Metal-Sheathed Cable Type MI
- Article 342 Intermediate Metal Conduit Type IMC
- Article 358 Electrical Metallic Tubing Type EMT
- Article 362 Electrical Nonmetallic Tubing Type ENT
- Example No. D2(b) Optional Calculation for One-Family Dwelling, Air Conditioning Larger than Heating [See 220.82(A) and 220.82(C)]