| IPv6 Network - IPv4-Mapped IPv6 Addresses |
IPv6 Network - IPv4-Mapped IPv6 Addresses The socket API changes require that in order to support IPv6, small parts of an application must be updated to use the new API calls. For obvious reasons, turning an IPv4-only application into an IPv6-only application isn’t all that useful, so RFC 3493 makes it possible for an application that uses the new mechanisms to communicate over IPv4 by using IPv4-mapped IPv6 addresses.
An IPv4-mapped address is an IPv6 address that consists of the prefix 0:0:0:0:0:ffff::/96 (or ::ffff:0:0/96) followed by the IPv4 address in question. So the IPv4-mapped address for localhost would be ::ffff:7f00:1. These addresses are often expressed in the more convenient form, ::ffff:127.0.0.1. Even though to the application, an IPv4-mapped address looks like any other IPv6 address, using these addresses results in IPv4 packets on the wire (network), not IPv6 packets. IPv6 packets with IPv4-mapped addresses as their source or destination are best filtered out because they could be used to bypass IPv4 filters. In 2002, IPv4-mapped addresses got some bad press when Jun-ichiro itojun Hagino wrote an Internet Draft for the IETF community under the title “IPv4 mapped address considered harmful.” The document goes on to explain that IPv4 mapped addresses are dangerous only on the wire and not in the API, but the title of the first version didn’t capture that nuance. (The title was changed in the next version.)
IPv4-mapped addresses are a good example of how a clear and simple concept can lead to unexpected complications. Daemon applications that listen for incoming connections must tell the system they are interested in incoming TCP sessions or UDP packets on a certain address and a certain port number by “binding” to an address and port. Most daemons specify they are interested in incoming sessions or packets on any address. The trouble starts when an application binds to “any” in IPv6, and also to “any” in IPv4. Because “any” in IPv6 includes IPv4-mapped addresses, the “any” IPv4 binding clashes with the IPv6 one. On some systems, this doesn’t lead to problems, but on others, the binding fails. The solution would be to bind to the IPv6 “any” address only, but some systems (such as Windows) never supported IPv4 mapped addresses, and some systems, such as NetBSD, dropped IPv4-mapped address support somewhere along the way or only support them when explicitly enabled (FreeBSD 5 and later).
The end result is that whatever an application writer does, there will be trouble on some operating system. Some argue that the correct way for a daemon application to support both IPv4 and IPv6 is to request a list of the system’s addresses and then bind to each address explicitly rather than to “any” addresses. However, this adds overhead to the system and the application because there are now more sockets that need attention periodically, and, worse, the list of addresses may change over time, requiring additional complexity.
The inconsistent handling of IPv4-mapped IPv6 addresses across different operating systems is probably the reason why BIND 9.2 only supports listening to the IPv6 “any” address: on most systems, the specific bindings for individual IPv4 addresses preempt the IPv6 “any” binding so there aren’t any problems. RFC 3493 solves this problem by introducing the IPV6_V6ONLY socket option. By setting this option, an application indicates that it doesn’t want to use IPv4-mapped addresses so that IPv4 and IPv6 bindings no longer clash. As the
| Users' Comments (0) |
|
No comment posted
