, hosts utilize source and destination address selection algorithms to choose which addresses to try first - see Section 3.5.4. Implementations that attempt to provide the fastest response time sometimes start using the addresses as soon as they arrive, and if those do not yield a working connectivity, fall back to the addresses that were slower to resolve. Introduction to IPv6 3.10.3 Applications IPv6 has a significant impact on many applications, and in particular to those that are, for whatever reason, IP version aware. File Transfer Protocol (FTP) is a classic and famous protocol used on the Internet for a very long time. As the FTP [147] is IP-version aware and passes IP address literals in its protocol payloads, it is a handy protocol for us to highlight typical implications that IPv6 can have for upper layer protocols - both those right above layer 3, and those that are in the application layer. RFC 2428, FTP Extensions for IPv6 and NATs, describes in depth the implications for FTP [148], and here we provide a short summary. The original specification for FTP, quite fairly for that time, assumed that the IP addresses were always of 32 bits in length. As IPv6 address are four times the length, 128 bits, issues were certain to arise. Any piece of code that is participating somehow at the IP address management must change, and similarly any part of protocol specifications that touches IP addresses must be updated. The problems are made even harder as endpoints may be addressed with both IPv4 and IPv6 addresses. In the case of FTP, the abovementioned issues have the following implications: 1. An FTP program has to be able to set up a TCP connection to a remote peer with IPv6, if the DNS resolution for the peer's name results in an IPv6 address or a program is given an IPv6 address literal as input. In some cases the program has to be able to fallback from a failure to establish a connection with the first address family (e.g., IPv6) to a second address family (e.g. IPv4). The preferences and fallback logic rel