6- only destinations. This means that even if a node implementing BIH is in an IPv6-only network, it should not perform protocol translation if the destination has an IPv4 address. This design decision was based on the dominant view at the IETF during the standard writing, which was against definition of double protocol translation schemes. However, as time has passed the double protocol translation has become acceptable (see Section 5.4.4) and the current definition of BIH actually complements 464XLAT. In any case, with BIH, an implementation can be made to do protocol translation even if a destination has IPv4 address. This is done by defining special exclusion sets (RFC 6535, Section 2.3.1) to exclude all received IPv4 addresses, hence making the destination look like IPv6-only for the rest of the BIH implementation. 5.3.6 Mapping Address and Port Number Among certain IPv6 transition/migration solutions it has become common to embed IPv4 address and port information into the IPv6 prefix assigned to the end host. Mapping of IPv4 addresses inside IPv6 addresses is an old and known technology dating back to the days of automatic tunneling [41]. These specifically concern transition solutions where IPv4 access is provided for leaf networks where parts (or the entire) ISP backbone is IPv6 only. The basic idea is to embed enough IPv4 related information into the IPv6 prefix, and in some cases also into the IID, SO that the ISP network can do a stateless algorithmic mapping/translation from an IPv6 address to an IPv4 address/prefix and vice versa [42]. Often, IPv4 address sharing using address plus port (A+P) [20] techniques go hand in hand with mapped IPv6 addresses. The mapping scheme described in this section supports transportation of IPv4 packets in IPv6 in both mesh and hub-and-spoke topologies (see Section 5.2.3), including address mappings with full independence between IPv6 and IPv4 addresses. Within the MAP context we mean the address family translation similar to NAT64 as the translation mode and tunneling