1inet6(7P) Protocols inet6(7P)
2
6 inet6 - Internet protocol family for Internet Protocol version 6
7
9 #include <sys/types.h>
10 #include <netinet/in.h>
11
14 The inet6 protocol family implements a collection of protocols that are
15 centered around the Internet Protocol version 6 (IPv6) and share a com‐
16 mon address format. The inet6 protocol family can be accessed using the
17 socket interface, where it supports the SOCK_STREAM, SOCK_DGRAM, and
18 SOCK_RAW socket types, or the Transport Level Interface (TLI), where it
19 supports the connectionless (T_CLTS) and connection oriented
20 (T_COTS_ORD) service types.
21
23 The Internet protocol family for IPv6 included the Internet Protocol
24 Version 6 (IPv6), the Neighbor Discovery Protocol (NDP), the Internet
25 Control Message Protocol (ICMPv6), the Transmission Control Protocol
26 (TCP), and the User Datagram Protocol (UDP).
27 TCP supports the socket interface's SOCK_STREAM abstraction and TLI's
30 T_COTS_ORD service type. UDP supports the SOCK_DGRAM socket abstrac‐
31 tion and the TLI T_CLTS service type. See tcp(7P) and udp(7P). A direct
32 interface to IPv6 is available using the socket interface. See ip6(7P).
33 ICMPv6 is used by the kernel to handle and report errors in protocol
34 processing. It is also accessible to user programs. See icmp6(7P). NDP
35 is used to translate 128-bit IPv6 addresses into 48-bit Ethernet
36 addresses.
37 IPv6 addresses come in three types: unicast, anycast, and multicast. A
40 unicast address is an identifier for a single network interface. An
41 anycast address is an identifier for a set of interfaces; a packet sent
42 to an anycast address is delivered to the "nearest" interface identi‐
43 fied by that address, pursuant to the routing protocol's measure of
44 distance. A multicast address is an identifier for a set of interfaces;
45 a packet sent to a multicast address is delivered to all interfaces
46 identified by that address. There are no broadcast addresses as such in
47 IPv6; their functionality is superseded by multicast addresses.
48 For IPv6 addresses, there are three scopes within which unicast
51 addresses are guaranteed to be unique. The scope is indicated by the
52 address prefix. The three varieties are link-local (the address is
53 unique on that physical link), site-local (the address is unique
54 within that site), and global (the address is globally unique).
55 The three highest order bits for global unicast addresses are set to
58 001. The ten highest order bits for site-local addresses are set to
59 1111 1110 11. The ten highest order bits for link-local addresses are
60 set to 1111 1110 11. For multicast addresses, the eight highest order
61 bits are set to 1111 1111. Anycast addresses have the same format as
62 unicast addresses.
63 IPv6 addresses do not follow the concept of "address class" seen in IP.
66 A global unicast address is divided into the following segments:
69 o The first three bits are the Format Prefix identifying a
71 unicast address.
72 o The next 13 bits are the Top-Level Aggregation (TLA) identi‐
74 fier. For example, the identifier could specify the ISP.
75 o The next eight bits are reserved for future use.
77 o The next 24 bits are the Next-Level Aggregation (NLA) iden‐
79 tifier.
80 o The next 16 bits are the Site-Level Aggregation (SLA) iden‐
82 tifier.
83 o The last 64 bits are the interface ID. This will most often
85 be the hardware address of the link in IEEE EUI-64 format.
86 Link-local unicast addresses are divided in this manner:
89 o The first ten bits are the Format Prefix identifying a link-
91 local address.
92 o The next 54 bits are zero.
94 o The last 64 bits are the interface ID. This will most often
96 be the hardware address of the link in IEEE EUI-64 format.
97 Site-local unicast addresses are divided in this manner:
100 o The first ten bits are the Format Prefix identifying a site-
102 local address.
103 o The next 38 bits are zero.
105 o The next 16 bits are the subnet ID.
107 o The last 64 bits are the interface ID. This will most often
109 be the hardware address of the link in IEEE EUI-64 format.
110
112 IPv6 addresses are sixteen byte quantities, stored in network byte
113 order. The socket API uses the sockaddr_in6 structure when passing IPv6
114 addresses between an application and the kernel. The sockaddr_in6
115 structure has the following members:
116 sa_familty_t sin6_family;
118 in_port_t sin6_port;
119 uint32_t sin6_flowinfo;
120 struct in6_addr sin6_addr;
121 uint32_t sin6_scope_id;
122 uint32_t __sin6_src_id;
123 Library routines are provided to manipulate structures of this form.
127 See inet(3SOCKET).
128 The sin6_addr field of the sockaddr_in6 structure specifies a local or
131 remote IPv6 address. Each network interface has one or more IPv6
132 addresses configured, that is, a link-local address, a site-local
133 address, and one or more global unicast IPv6 addresses. The special
134 value of all zeros may be used on this field to test for "wildcard"
135 matching. Given in a bind(3SOCKET) call, this value leaves the local
136 IPv6 address of the socket unspecified, so that the socket will receive
137 connections or messages directed at any of the valid IPv6 addresses of
138 the system. This can prove useful when a process neither knows nor
139 cares what the local IPv6 address is, or when a process wishes to
140 receive requests using all of its network interfaces.
141 The sockaddr_in6 structure given in the bind() call must specify an
144 in6_addr value of either all zeros or one of the system's valid IPv6
145 addresses. Requests to bind any other address will elicit the error
146 EADDRNOTAVAI. When a connect(3SOCKET) call is made for a socket that
147 has a wildcard local address, the system sets the sin6_addr field of
148 the socket to the IPv6 address of the network interface through which
149 the packets for that connection are routed.
150 The sin6_port field of the sockaddr_in6 structure specifies a port num‐
153 ber used by TCP or UDP. The local port address specified in a bind()
154 call is restricted to be greater than IPPORT_RESERVED (defined in
155 <netinet/in.h>) unless the creating process is running as the super-
156 user, providing a space of protected port numbers. In addition, the
157 local port address cannot be in use by any socket of the same address
158 family and type. Requests to bind sockets to port numbers being used by
159 other sockets return the error EADDRINUSE. If the local port address is
160 specified as 0, the system picks a unique port address greater than
161 IPPORT_RESERVED. A unique local port address is also selected when a
162 socket which is not bound is used in a connect(3SOCKET) or sendto()
163 call. See send(3SOCKET). This allows programs that do not care which
164 local port number is used to set up TCP connections by simply calling
165 socket(3SOCKET) and then connect(3SOCKET), and then sending UDP data‐
166 grams with a socket() call followed by a sendto() call.
167 Although this implementation restricts sockets to unique local port
170 numbers, TCP allows multiple simultaneous connections involving the
171 same local port number so long as the remote IPv6 addresses or port
172 numbers are different for each connection. Programs may explicitly
173 override the socket restriction by setting the SO_REUSEADDR socket
174 option with setsockopt(). See getsockopt(3SOCKET).
175 In addition, the same port may be bound by two separate sockets if one
178 is an IP socket and the other an IPv6 socket.
179 TLI applies somewhat different semantics to the binding of local port
182 numbers. These semantics apply when Internet family protocols are used
183 using the TLI.
184
186 IPv6 source address selection is done on a per destination basis, and
187 utilizes a list of rules from which the best source address is selected
188 from candidate addresses. The candidate set comprises a set of local
189 addresses assigned on the system which are up and not anycast. If just
190 one candidate exists in the candidate set, it is selected.
191 Conceptually, each selection rule prefers one address over another, or
194 determines their equivalence. If a rule produces a tie, a subsequent
195 rule is used to break the tie.
196 The sense of some rules may be reversed on a per-socket basis using the
199 IPV6_SRC_PREFERENCES socket option (see ip6(7P)). The flag values for
200 this option are defined in <netinet/in.h> and are referenced in the
201 description of the appropriate rules below.
202 As the selection rules indicate, the candidate addresses are SA and SB
205 and the destination is D.
206 Prefer the same address If SA == D, prefer SA. If SB == D, pre‐
208 fer SB.
209 Prefer appropriate scope Here, Scope(X) is the scope of X accord‐
212 ing to the IPv6 Addressing Architecture.
213 If Scope(SA) < Scope(SB): If Scope(SA) <
215 Scope(D), then prefer SB and otherwise
216 prefer SA.
217 If Scope(SB) < Scope(SA): If Scope(SB) <
219 Scope(D), then prefer SA and otherwise
220 prefer SB.
221 Avoid deprecated addresses If one of the addresses is deprecated
224 (IFF_DEPRECATED) and the other is not,
225 prefer the one that isn't deprecated.
226 Prefer preferred addresses If one of the addresses is preferred
229 (IFF_PREFERRED) and the other is not,
230 prefer the one that is preferred.
231 Prefer outgoing interface If one of the addresses is assigned to
234 the interface that will be used to send
235 packets to D and the other is not, then
236 prefer the former.
237 Prefer matching label This rule uses labels which are obtained
240 through the IPv6 default address selec‐
241 tion policy table. See ipaddrsel(1M) for
242 a description of the default contents of
243 the table and how the table is config‐
244 ured.
245 If Label(SA) == Label(D) and Label(SB) !=
247 Label(D), then prefer SA.
248 If Label(SB) == Label(D) and Label(SA) !=
250 Label(D), then prefer SB.
251 Prefer public addresses This rule prefers public addresses over
254 temporary addresses, as defined in RFC
255 3041. Temporary addresses are disabled by
256 default and may be enabled by appropriate
257 settings in ndpd.conf(4).
258 The sense of this rule may be set on a
260 per-socket basis using the IPV6_SRC_PREF‐
261 ERENCES socket option. Passing the flag
262 IPV6_PREFER_SRC_TMP or IPV6_PRE‐
263 FER_SRC_PUBLIC will cause temporary or
264 public addresses to be preferred, respec‐
265 tively, for that particular socket. See
266 ip6(7P) for more information about IPv6
267 socket options.
268 Use longest matching prefix.
271 This rule prefers the source address that has the longer matching
273 prefix with the destination. Because this is the last rule and
274 because both source addresses could have equal matching prefixes,
275 this rule does an xor of each source address with the destination,
276 then selects the source address with the smaller xor value in order
277 to break any potential tie.
278 If SA ^ D < SB ^ D, then prefer SA.
280 If SB ^ D < SA ^ D, then prefer SB.
282 Applications can override this algorithm by calling bind(3SOCKET) and
286 specifying an address.
287
289 ioctl(2), bind(3SOCKET), connect(3SOCKET), getipnodebyaddr(3SOCKET),
290 getipnodebyname(3SOCKET),getprotobyname(3SOCKET), getservby‐
291 name(3SOCKET), getsockopt(3SOCKET), inet(3SOCKET), send(3SOCKET),
292 icmp6(7P), ip6(7P), tcp(7P), udp(7P)
293 Conta, A. and Deering, S., Internet Control Message Protocol (ICMPv6)
296 for the Internet Protocol Version 6 (IPv6) Specification, RFC 1885,
297 December 1995.
298 Deering, S. and Hinden, B., Internet Protocol, Version 6 (IPv6) Speci‐
301 fication, RFC 1883, December 1995.
302 Hinden, B. and Deering, S., IP Version 6 Addressing Architecture, RFC
305 1884, December 1995.
306 Draves, R., RFC 3484, Default Address Selection for IPv6. The Internet
309 Society. February 2003.
310 Narten, T., and Draves, R. RFC 3041, Privacy Extensions for Stateless
313 Address Autoconfiguration in IPv6. The Internet Society. January 2001.
314
316 The IPv6 support is subject to change as the Internet protocols
317 develop. Users should not depend on details of the current implementa‐
318 tion, but rather the services exported.
319SunOS 5.11 3 Oct 2002 inet6(7P)