hosts having dual-stack connectivity, ends up preferring IPv6. In more complex real-life scenarios it can happen that either DNS query yields negative answers, or it is even lost in transit. In such cases the host should proceed after some time has passed with the possibly received positive answer, even if the resolution of the other address family would still be pending. The implementations vary on how they perform error recovery in these kinds of situations. Introduction to IPv6 No. Time Source Destination Protocol Info 6 3.0547 192.168.1.108 192.168.1.1 standard query A ww.1ett.org 3.0573 192.168.1.1 192.168.1.108 Standard query response A 64.170.98.30 3.0583 192.168.1.108 192.168.1.1 Standard query AAAA www. ietf. org 9 3.0616 192.168.1.1 192.168.1.108 DNS Standard query response AAAA 2001:1890:126c::1:1e 2001:1890:126c::1:1e 49439 5e0-0 Len⑉0MSS-1340W5⑉ Frame 10 (86 bytes on wire, 86 bytes captured) Ethernet II, Src: c4:17:fe:47:35:f5 (c4:17:fe:47:35:f5), Dst: 00:23:69:5b:6d:f9 (00:23:69:5b:6d:f9) Internet Protocol version Transmission Control Protocol, src Port: 49439 (49439) Dst Port: http (80) seq: 0. Len: 0 Source port: 49439 (49439) Destination port: http (80) Sequence number: 0 (relative sequence number) Header length: 32 bytes Flags: 0x02 (SYN) window size: 8192 checksum: Oxee0e [correct] options: (12 bytes) Figure 3.34 Example: initiation of TCP handshake with the preferred address family. In Figure 3.34 we can see the result of preferring of IPv6 over IPv4 at packet 10: the first message of the TCP handshake procedures is being sent to the IPv6 address the www.ietf.org that was just learned over the DNS, and no IPv4 traffic whatsoever. Furthermore, this figure shows the main contents of the TCP header and we can see that there is no IPv6 specific content there. Of course, as described in Section 3.10.1, the checksum field also covers the IPv6 pseudo header in addition to the TCP packet headers. If it happens that IPv6 connection establishment is excessively delayed, the host should try to use IPv4 i