rs. These addresses were fec0 ffff: 1, ,fec0:0:0:ffff: 2, andfec0:0:0:ffff:: 3. Due to lack of any better mechanisms, some vendors chose to support these well-known addresses. Even today some operating systems use these addresses as the last resort means for communicating with DNS servers. Hence, if one sees these addresses in action, it is a hint that the node has failed to obtain DNS server addresses by other means. Despite these implementations, IETF chose not to standardize this approach and the draft specification expired. Furthermore, the whole concept of site-local addressing was made obsolete in RFC 3879 [6]. DNS Queries for Both IPv4 and IPv6 Resource Records As the transition to IPv6 involves a long period of coexistence with IPv4, hosts need to be able to use both IPv4 and IPv6 for communications. A significant implication for DNS of the coexistence is that dual-stack hosts need to be able to resolve destination's IPv4 and IPv6 addresses. An important thing to note is that the type of DNS query, be that A or AAAA, is orthogonal to the IP address family used to transmit the actual DNS queries. Deploying IPv6 in 3GPP Networks Due to the limitations in the DNS protocol, it is not feasible to ask for different types of records in a single DNS query. The main reason for that is the DNS proto- col's lack of capability to indicate different result codes for different queries in a single response; for example, if an A resource record would be available but AAAA would not, the DNS could not differentiate which record resulted in success and which in fail- ure. Therefore, the client implementations will always send separate requests for A and AAAA resource records. This approach increases the number of DNS messages that nodes emit and hence signaling load on a network, but with help of DNS caches (often residing already on nodes themselves) the issues are not that significant - and neverthe- less unavoidable. A variety of approaches for resolving both IPv4 and IPv6 addresses are deployed in different operating s