svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
inet6(4p)
inet6(4P) Network Protocols inet6(4P)
NAME
inet6 - Internet protocol family for Internet Protocol version 6
SYNOPSIS
#include <sys/types.h>
#include <netinet/in.h>
DESCRIPTION
The inet6 protocol family implements a collection of protocols that are
centered around the Internet Protocol version 6 (IPv6) and share a com‐
mon address format. The inet6 protocol family can be accessed using the
socket interface, where it supports the SOCK_STREAM, SOCK_DGRAM, and
SOCK_RAW socket types, or the Transport Level Interface (TLI), where it
supports the connectionless (T_CLTS) and connection oriented
(T_COTS_ORD) service types.
PROTOCOLS
The Internet protocol family for IPv6 included the Internet Protocol
Version 6 (IPv6), the Neighbor Discovery Protocol (NDP), the Internet
Control Message Protocol (ICMPv6), the Transmission Control Protocol
(TCP), and the User Datagram Protocol (UDP).
TCP supports the socket interface's SOCK_STREAM abstraction and TLI's
T_COTS_ORD service type. UDP supports the SOCK_DGRAM socket abstraction
and the TLI T_CLTS service type. See tcp(4P) and udp(4P). A direct in‐
terface to IPv6 is available using the socket interface. See ip6(4P).
ICMPv6 is used by the kernel to handle and report errors in protocol
processing. It is also accessible to user programs. See icmp6(4P). NDP
is used to translate 128-bit IPv6 addresses into 48-bit Ethernet ad‐
dresses.
IPv6 addresses come in three types: unicast, anycast, and multicast. A
unicast address is an identifier for a single network interface. An
anycast address is an identifier for a set of interfaces; a packet sent
to an anycast address is delivered to the "nearest" interface identi‐
fied by that address, pursuant to the routing protocol's measure of
distance. A multicast address is an identifier for a set of interfaces;
a packet sent to a multicast address is delivered to all interfaces
identified by that address. There are no broadcast addresses as such in
IPv6; their functionality is superseded by multicast addresses.
For IPv6 addresses, there are three scopes within which unicast ad‐
dresses are guaranteed to be unique. The scope is indicated by the ad‐
dress prefix. The three varieties are link-local (the address is unique
on that physical link), site-local (the address is unique within that
site), and global (the address is globally unique).
The three highest order bits for global unicast addresses are set to
001. The ten highest order bits for site-local addresses are set to
1111 1110 11. The ten highest order bits for link-local addresses are
set to 1111 1110 11. For multicast addresses, the eight highest order
bits are set to 1111 1111. Anycast addresses have the same format as
unicast addresses.
IPv6 addresses do not follow the concept of "address class" seen in IP.
A global unicast address is divided into the following segments:
o The first three bits are the Format Prefix identifying a
unicast address.
o The next 13 bits are the Top-Level Aggregation (TLA) identi‐
fier. For example, the identifier could specify the ISP.
o The next eight bits are reserved for future use.
o The next 24 bits are the Next-Level Aggregation (NLA) iden‐
tifier.
o The next 16 bits are the Site-Level Aggregation (SLA) iden‐
tifier.
o The last 64 bits are the interface ID. This will most often
be the hardware address of the link in IEEE EUI-64 format.
Link-local unicast addresses are divided in this manner:
o The first ten bits are the Format Prefix identifying a link-
local address.
o The next 54 bits are zero.
o The last 64 bits are the interface ID. This will most often
be the hardware address of the link in IEEE EUI-64 format.
Site-local unicast addresses are divided in this manner:
o The first ten bits are the Format Prefix identifying a site-
local address.
o The next 38 bits are zero.
o The next 16 bits are the subnet ID.
o The last 64 bits are the interface ID. This will most often
be the hardware address of the link in IEEE EUI-64 format.
ADDRESSING
IPv6 addresses are sixteen byte quantities, stored in network byte or‐
der. The socket API uses the sockaddr_in6 structure when passing IPv6
addresses between an application and the kernel. The sockaddr_in6
structure has the following members:
sa_family_t sin6_family;
in_port_t sin6_port;
uint32_t sin6_flowinfo;
struct in6_addr sin6_addr;
uint32_t sin6_scope_id;
uint32_t __sin6_src_id;
Library routines are provided to manipulate structures of this form.
See inet(3C).
sin6_family is always set to AF_INET6.
sin6_flowinfo can be used to set the 20-bit IPv6 flow label. An example
of the code fragment is as follows:
...
struct sockaddr_in6 to6;
...
bzero((char *)&to6, sizeof (struct sockaddr_in6));
to6.sin6_family = AF_INET6;
to6.sin6_flowinfo = htonl(flow_label_val) & IPV6_FLOWINFO_FLOWLABEL;
...
The sin6_addr field of the sockaddr_in6 structure specifies a local or
remote IPv6 address. Each network interface has one or more IPv6 ad‐
dresses configured, that is, a link-local address, a site-local ad‐
dress, and one or more global unicast IPv6 addresses. The special value
of all zeros may be used on this field to test for "wildcard" matching.
Given in a bind(3C) call, this value leaves the local IPv6 address of
the socket unspecified, so that the socket will receive connections or
messages directed at any of the valid IPv6 addresses of the system.
This can prove useful when a process neither knows nor cares what the
local IPv6 address is, or when a process wishes to receive requests us‐
ing all of its network interfaces.
The sockaddr_in6 structure given in the bind() call must specify an
in6_addr value of either all zeros or one of the system's valid IPv6
addresses. Requests to bind any other address will elicit the error
EADDRNOTAVAIL. When a connect(3C) call is made for a socket that has a
wildcard local address, the system sets the sin6_addr field of the
socket to the IPv6 address of the network interface through which the
packets for that connection are routed.
The sin6_port field of the sockaddr_in6 structure specifies a port num‐
ber used by TCP or UDP. The local port address specified in a bind(3C)
call is restricted to be greater than or equal to smallest-nonpriv-
port, and not one of the extra-priv-ports, unless the process has the
PRIV_NET_PRIVADDR privilege asserted, as described in the privileges(7)
manual page. The smallest-nonpriv-port and extra-priv-ports properties
may be modified or queried via the ipadm(8) command. The default value
for smallest-nonpriv-port is the constant IPPORT_RESERVED (defined in
<netinet/in.h>). In addition, the local port address cannot be in use
by any socket of the same address family and type. Requests to bind
sockets to port numbers being used by other sockets return the error
EADDRINUSE. If the local port address is specified as 0, the system
picks a unique port address in the range (smallest-anon-port, largest-
anon-port), where the smallest-anon-port and largest-anon-port proper‐
ties may be modified or queried via the ipadm(8) command. A unique lo‐
cal port address is also selected when a socket which is not bound is
used in a connect(3C) or sendto(3C) call. This allows programs that do
not care which local port number is used to set up TCP connections by
simply calling socket(3C) and then connect(3C), and to send UDP data‐
grams with a socket(3C) call followed by a sendto(3C) call.
Although this implementation restricts sockets to unique local port
numbers, TCP allows multiple simultaneous connections involving the
same local port number so long as the remote IPv6 addresses or port
numbers are different for each connection. Programs may explicitly
override the socket restriction by setting the SO_REUSEADDR socket op‐
tion with setsockopt(3C).
In addition, the same port may be bound by two separate sockets if one
is an IP socket and the other an IPv6 socket.
TLI applies somewhat different semantics to the binding of local port
numbers. These semantics apply when Internet family protocols are used
using the TLI.
SOURCE ADDRESS SELECTION
IPv6 source address selection is done on a per destination basis, and
utilizes a list of rules from which the best source address is selected
from candidate addresses. The candidate set comprises a set of local
addresses assigned on the system which are up and not anycast. If just
one candidate exists in the candidate set, it is selected.
Conceptually, each selection rule prefers one address over another, or
determines their equivalence. If a rule produces a tie, a subsequent
rule is used to break the tie.
The sense of some rules may be reversed on a per-socket basis using the
IPV6_SRC_PREFERENCES socket option (see ip6(4P)). The flag values for
this option are defined in <netinet/in.h> and are referenced in the de‐
scription of the appropriate rules below.
As the selection rules indicate, the candidate addresses are SA and SB
and the destination is D.
Prefer the same address
If SA == D, prefer SA. If SB == D, prefer SB.
Prefer appropriate scope
Here, Scope(X) is the scope of X according to the IPv6 Addressing
Architecture.
If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB
and otherwise prefer SA.
If Scope(SB) < Scope(SA): If Scope(SB) < Scope(D), then prefer SA
and otherwise prefer SB.
Avoid deprecated addresses
If one of the addresses is deprecated (IFF_DEPRECATED) and the
other is not, prefer the one that isn't deprecated.
Prefer preferred addresses
If one of the addresses is preferred (IFF_PREFERRED) and the other
is not, prefer the one that is preferred.
Prefer outgoing interface
If one of the addresses is assigned to the interface that will be
used to send packets to D and the other is not, then prefer the
former.
Prefer matching label
This rule uses labels which are obtained through the IPv6 default
address selection policy table. See ipaddrsel(8) for a description
of the default contents of the table and how the table is config‐
ured.
If Label(SA) == Label(D) and Label(SB) != Label(D), then prefer SA.
If Label(SB) == Label(D) and Label(SA) != Label(D), then prefer SB.
Prefer public addresses
This rule prefers public addresses over temporary addresses, as de‐
fined in RFC 3041. Temporary addresses are disabled by default and
may be enabled by appropriate settings in ndpd.conf(5).
RFC 6724 reversed this preference to "prefer temporary addresses",
Solaris kept the RFC 3484 preference by default to maintain back‐
ward compatibility with existing applications. Solaris will follow
the RFC 6724 rule if the ipadm IPv6 protocol property "prefer-sr‐
caddr" is set to "temporary", see ipadm(8).
The sense of this rule may be set on a per-socket basis using the
IPV6_SRC_PREFERENCES socket option. Passing the flag IPV6_PRE‐
FER_SRC_TMP or IPV6_PREFER_SRC_PUBLIC will cause temporary or pub‐
lic addresses to be preferred, respectively, for that particular
socket. See ip6(4P) for more information about IPv6 socket options.
Use longest matching prefix.
This rule prefers the source address that has the longer matching
prefix with the destination. Because this is the last rule and be‐
cause both source addresses could have equal matching prefixes,
this rule does an xor of each source address with the destination,
then selects the source address with the smaller xor value in order
to break any potential tie.
If SA ^ D < SB ^ D, then prefer SA.
If SB ^ D < SA ^ D, then prefer SB.
Applications can override this algorithm by calling bind(3C) and speci‐
fying an address.
SEE ALSO
ioctl(2), bind(3C), byteorder(3C), connect(3C), getaddrinfo(3C),
getnameinfo(3C), getprotobyname(3C), getservbyname(3C), inet(3C),
sendto(3C), setsockopt(3C), icmp6(4P), inet(4P), ip6(4P), tcp(4P),
udp(4P), privileges(7), ipadm(8)
Internet Engineering Task Force Standards:
https://www.ietf.org/standards/
Deering, S. and Hinden, B., RFC 1883, Internet Protocol, Version 6
(IPv6) Specification, December 1995.
https://tools.ietf.org/html/rfc1883
Hinden, B. and Deering, S., RFC 1884, IP Version 6 Addressing Architec‐
ture, December 1995. https://tools.ietf.org/html/rfc1884
Conta, A. and Deering, S., RFC 1885, Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification, De‐
cember 1995. https://tools.ietf.org/html/rfc1885
Draves, R., RFC 3484, Default Address Selection for IPv6. February
2003. https://tools.ietf.org/html/rfc3484
Narten, T., and Draves, R. RFC 3041, Privacy Extensions for Stateless
Address Autoconfiguration in IPv6. January 2001.
https://tools.ietf.org/html/rfc3041
NOTES
The IPv6 support is subject to change as the Internet protocols de‐
velop. Users should not depend on details of the current implementa‐
tion, but rather the services exported.
Oracle Solaris 11.4 2 Feb 2021 inet6(4P)