The FreeBSD man page for inet6 has the following:

By default, FreeBSD does not route IPv4 traffic to AF_INET6 sockets. The default behavior intentionally violates RFC2553 for security reasons. Listen to two sockets if you want to accept both IPv4 and IPv6 traffic. IPv4 traffic may be routed with certain per-socket/per-node configuration, however, it is not recommended to do so. Consult ip6(4) for details.

OpenBSD also has a similar wording in its man page

For security reasons, OpenBSD does not route IPv4 traffic to an AF_INET6 socket, and does not support IPv4 mapped addresses, where IPv4 traffic is seen as if it comes from an IPv6 address like ::ffff: Where both IPv4 and IPv6 traffic need to be accepted, listen on two sockets.

This is referencing section 3.7 of RFC2553 (obsoleted by RFC3493) regarding IPv4 addresses being translated into ::FFFF:<IPv4-address>.

What I don't understand is what kind of security issues would be exposed by accepting IPv4 connections? What makes a translated IPv4 address less secure than any other IPv6 address? And why does Linux allow such "insecure" behavior?


1 Answer 1


Most of these security issues arise when a host accepts IPv4-mapped IPv6 traffic over the network, rather than accepting IPv4 traffic and presenting it to an application on an IPv6 socket with a mapped address. An application may have no good way to tell the difference and detect a potential attack in progress. Of course no host should ever be accepting mapped addresses from the network, but since when have operating systems ever behaved perfectly?

RFC 4942 § 2.2 explains the issues in depth:

Overloaded functionality is always a double-edged sword: it may yield some deployment benefits, but often also incurs the price that comes with ambiguity.

One example of such is IPv4-mapped IPv6 addresses (::ffff/96): a representation of an IPv4 address as an IPv6 address inside an operating system as defined in [RFC3493]. Since the original specification, the use of IPv4-mapped addresses has been extended to a transition mechanism, Stateless IP/ICMP Translation algorithm (SIIT) [RFC2765], where they are potentially used in the addresses of packets on the wire.

Therefore, it becomes difficult to unambiguously discern whether an IPv4 mapped address is really an IPv4 address represented in the IPv6 address format (basic API behavior) or an IPv6 address received from the wire (which may be subject to address forgery, etc.). (SIIT behavior). The security issues that arise from the ambiguous behavior when IPv4-mapped addresses are used on the wire include:

  • If an attacker transmits an IPv6 packet with ::ffff: in the IPv6 source address field, he might be able to bypass a node's access controls by deceiving applications into believing that the packet is from the node itself (specifically, the IPv4 loopback address, The same attack might be performed using the node's IPv4 interface address instead.

  • If an attacker transmits an IPv6 packet with IPv4-mapped addresses in the IPv6 destination address field corresponding to IPv4 addresses inside a site's security perimeter (e.g., ::ffff:, he might be able to bypass IPv4 packet filtering rules and traverse a site's firewall.

  • If an attacker transmits an IPv6 packet with IPv4-mapped addresses in the IPv6 source and destination fields to a protocol that swaps IPv6 source and destination addresses, he might be able to use a node as a proxy for certain types of attacks. For example, this might be used to construct broadcast multiplication and proxy TCP port scan attacks.

In addition, special cases like these, while giving deployment benefits in some areas, require a considerable amount of code complexity (e.g., in the implementations of bind() system calls and reverse DNS lookups) that is probably undesirable but can be managed in this case.

In practice, although the packet translation mechanisms of SIIT are specified for use in "Network Address Translator - Protocol Translator (NAT-PT)" [RFC2766], NAT-PT uses a mechanism different from IPv4-mapped IPv6 addresses for communicating embedded IPv4 addresses in IPv6 addresses. Also, SIIT is not recommended for use as a standalone transition mechanism. Given the issues that have been identified, it seems appropriate that mapped addresses should not be used on the wire. However, changing application behavior by deprecating the use of mapped addresses in the operating system interface would have significant impact on application porting methods as described in [RFC4038], and it is expected that IPv4-mapped IPv6 addresses will continue to be used within the API to aid application portability.

Using the basic API behavior has some security implications in that it adds additional complexity to address-based access controls. The main issue that arises is that an IPv6 (AF_INET6) socket will accept IPv4 packets even if the node has no IPv4 (AF_INET) sockets open. This has to be taken into account by application developers and may allow a malicious IPv4 peer to access a service even if there are no open IPv4 sockets. This violates the security principle of "least surprise".

  • 2
    So the argument boils down to "Some firewalls and operating systems don't know about ::ffff:<ipv4 address> addresses, so they might let in invalid packets". Is this correct? Because all these cases apply to regular IPv4 packets with these addresses in them (which current firewalls/OSs correctly block).
    – imgx64
    Commented Jun 21, 2015 at 12:23
  • 1
    Pretty much. Having the host reject mapped addresses on the wire solves all of these problems, including the last one (which is the main one that *BSD could argue about) so it's mystifying that they chose another approach. Commented Jun 21, 2015 at 13:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .