Client refers to sshg3, scpg3, sftpg3, and several utilities such as ssh-keyfetch-g3 and ssh-keydist-g3. Their behavior in terms of IP
address-family may be modified by:
The Connection Broker configuration through which the clients communicate with servers (discussed above)
The use of a connection profile defined in the Connection Broker configuration
The host attribute of a connection profile may specify either an IP address or a host name. Whether IPv4 or IPv6 is allowed and whether lookups of host names use IPv4 or IPv6 addresses is controlled by the address family selected for the connection, based on the evaluation of the Connection Broker configurations and broker and client command-line options. In fact, this is the general rule whenever client configurations or operands refer to an address or host, so with that in mind it should be possible to deduce the effect of any such reference in terms of address family.
Command-line options for the client that affect the use of IPv4 or IPv6 are, in the first instance, the
-6 options. These affect the process of DNS lookup, having a restrictive effect on the
getaddrinfo() library function used to resolve hosts. In the absence of either option, the default
unspec address family is used, meaning that address resolution may return both IPv4 and IPv6 addresses. The
-4 option results in only IPv4 addresses being returned, while
-6 results in only IPv6 addresses. Note that these options control just the action of
getaddrinfo(): they determine how names and addresses are resolved for the purpose of the client making connections; they do not determine the address family in use, which is instead controlled at the Connection Broker level.
Addresses or hosts may be used as operands by clients as connection targets and tunnel listen interfaces and targets. Explicit IPv4 or IPv6 addresses may be coded, depending on the configuration and options in effect, and host names are likewise resolved to IPv4 or IPv6 addresses or both. Clients may connect to a server listening on a link-local IPv6 address, but only if the correct
scope_id is supplied, e.g.,
The following table demonstrates some of the possible combinations and their effects:
Address -4 / -6 Address Connect to Family option operand * * none error none none localhost first resolved usable address none -4 localhost 127.0.0.1 none -6 localhost ::1 (fails unless resolves as IPv6) none none 127.0.0.1 127.0.0.1 none -4 127.0.0.1 127.0.0.1 none -6 127.0.0.1 127.0.0.1 none none ::1 ::1 none -4 ::1 ::1 none -6 ::1 ::1 none * fe80::100:00 error (link local requires scope) none * fe80::100:00%1 fe80::100:00%1 none * fd02:200:bb::4 fd02:200:bb::4 (global scope address) 'any' see AddressFamily none 'inet' none localhost first resolved usable address 'inet' -4 localhost 127.0.0.1 'inet' -6 localhost ::1 (fails unless resolves as IPv6) 'inet' * ::1 ::1 'inet' * fe80::100:00 error (link local requires scope) 'inet' * fe80::100:00%1 fe80::100:00%1 'inet6' none localhost ::1 (fails unless resolves as IPv6) 'inet6' -4 localhost 127.0.0.1 'inet6' -6 localhost ::1 (fails unless resolves as IPv6) 'inet6' * 127.0.0.1 127.0.0.1 'inet6' * ::1 ::1 'inet6' * 10.0.0.1 10.0.0.1 'inet6' * fe80::100:00 error (link local requires scope) 'inet6' * fe80::100:00%1 fe80::100:00%1 * * fd02:200:bb::4 fd02:200:bb::4 (global scope address)
For the sake of brevity, this table uses the terms localhost,
::1, but of course localhost might be configured as
::2, etc. The idea is that other types of address may be extrapolated from those given here.