awareness, as an IPv6 URI may be passed to an HTTP loader API as simple strings. It will then be the imple- mentation behind HTTP loader API that has to be able to handle the parsing of an address literal given through its API. However, if an application performs any parsing of the URI by itself, it must be aware that, in the case of IPv6, the URI may contain brackets and more than one colon, and that the presence of a colon does not by itself indicate the presence of a port number. 3.9.4 Happy Eyeballs In the Internet, IPv4 and IPv6 may traverse significantly different paths between two dual-stack enabled peers. This means that the path properties and functionalities may be different for IPv4 and IPv6. Sometimes either IPv4 or IPv6 may be fully broken, have significantly different latencies, or may be not working between some specific peers. IETF has defined the concept of 'Happy Eyeballs' around this issue [134]. The Happy Eyeballs concept means that the end user is kept as unaware as possible about possible failures in one address family. In practice a host, and often the imple- mentation of an API, must perform quick fallback to another address family if the first one tried does not yield successful results. For example, if an application first attempts to create a connection to a destination with IPv6, but it does not succeed reasonably Introduction to IPv6 Recursive DNS server DNS query for 'AAAA' DNS query for 'A' IPv6 address IPv4 address TCP SYN over IPv6 TCP SYN over IPv4 TCP SYN/ACK over IPv6 TCP SYN/ACK over IPv4 TCP ACK over IPv6 TCP RST over IPv4 Figure 3.22 An example of the Happy Eyeballs procedure. fast, the application has to fallback to using IPv4. Figure 3.22 illustrates Happy Eyeballs in a normally functioning case. In the figure, a host is connecting to a peer by using TCP. The host starts by sending out both DNS IPv6 address record (AAAA) query for the peer's IPv6 address and the DNS IPv4 address record (A) query for the peer's IPv4 address. In the example, a recursive DNS resolver returns 