5331 want sockaddr(3SOCKET)
[illumos-gate.git] / usr / src / man / man7p / inet6.7p
blobe439a7f4984c782097c3ed79f4325f70091f0d0f
1 '\" te
2 .\" Copyright (C) 2002, Sun Microsystems, Inc. All Rights Reserved
3 .\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License").  You may not use this file except in compliance with the License.
4 .\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing.  See the License for the specific language governing permissions and limitations under the License.
5 .\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE.  If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
6 .TH INET6 7P "Oct 3, 2002"
7 .SH NAME
8 inet6 \- Internet protocol family for Internet Protocol version 6
9 .SH SYNOPSIS
10 .LP
11 .nf
12 \fB#include <sys/types.h>
13 #include <netinet/in.h>\fR
14 .fi
16 .SH DESCRIPTION
17 .LP
18 The \fBinet6\fR protocol family implements a collection of protocols that are
19 centered around the Internet Protocol version 6 (\fBIPv6\fR) and share a common
20 address format. The \fBinet6\fR protocol family can be accessed using the
21 socket interface, where it supports the \fBSOCK_STREAM\fR, \fBSOCK_DGRAM\fR,
22 and \fBSOCK_RAW\fR socket types, or the Transport Level Interface (\fBTLI\fR),
23 where it supports  the connectionless (\fBT_CLTS\fR) and connection oriented
24 (\fBT_COTS_ORD\fR) service types.
25 .SH PROTOCOLS
26 .LP
27 The Internet protocol family for \fBIPv6\fR included the Internet Protocol
28 Version 6 (\fBIPv6\fR), the Neighbor Discovery Protocol (\fBNDP\fR), the
29 Internet Control Message Protocol (\fBICMPv6\fR), the Transmission Control
30 Protocol (\fBTCP\fR), and the User Datagram Protocol (\fBUDP\fR).
31 .sp
32 .LP
33 \fBTCP\fR supports the socket interface's \fBSOCK_STREAM\fR abstraction and
34 \fBTLI\fR's  \fBT_COTS_ORD\fR service  type. \fBUDP\fR supports the
35 \fBSOCK_DGRAM\fR socket abstraction and the \fBTLI\fR \fBT_CLTS\fR service
36 type. See \fBtcp\fR(7P) and \fBudp\fR(7P). A direct interface to \fBIPv6\fR is
37 available using the socket interface. See \fBip6\fR(7P). \fBICMPv6\fR is used
38 by the kernel to handle and report errors in protocol processing. It  is also
39 accessible to user programs. See \fBicmp6\fR(7P). \fBNDP\fR is used to
40 translate 128-bit \fBIPv6\fR addresses into 48-bit Ethernet addresses.
41 .sp
42 .LP
43 \fBIPv6\fR addresses come in three types: unicast, anycast, and multicast. A
44 unicast address is an identifier for a single network interface. An anycast
45 address is an identifier for a set of interfaces; a packet sent to an anycast
46 address is delivered to the "nearest"  interface identified by that address,
47 pursuant to the routing protocol's measure of distance. A multicast address is
48 an identifier for a set of interfaces; a packet sent to a multicast address is
49 delivered to all  interfaces identified by that address. There are no broadcast
50 addresses as such in \fBIPv6\fR; their functionality is superseded by multicast
51 addresses.
52 .sp
53 .LP
54 For \fBIPv6\fR addresses, there are three scopes within which unicast addresses
55 are guaranteed to be unique. The scope is indicated by the address prefix. The
56 three varieties are link-local (the address is unique on that physical link),
57 site-local (the address is unique within that site), and global (the address is
58 globally unique).
59 .sp
60 .LP
61 The three highest order  bits for global unicast addresses are set to
62 \fB001\fR. The ten highest order bits for site-local addresses are set to
63 \fB1111 1110 11\fR. The ten highest order bits for link-local addresses are set
64 to \fB1111 1110 11\fR. For multicast addresses, the eight highest order bits
65 are set to \fB1111 1111\fR. Anycast addresses have the same format as unicast
66 addresses.
67 .sp
68 .LP
69 \fBIPv6\fR addresses do not follow the concept of "address class" seen in
70 \fBIP\fR.
71 .sp
72 .LP
73 A global unicast address is divided into the following segments:
74 .RS +4
75 .TP
76 .ie t \(bu
77 .el o
78 The first three bits are the Format Prefix identifying a unicast address.
79 .RE
80 .RS +4
81 .TP
82 .ie t \(bu
83 .el o
84 The next 13 bits are the Top-Level Aggregation (\fBTLA\fR) identifier. For
85 example, the identifier could specify the \fBISP\fR.
86 .RE
87 .RS +4
88 .TP
89 .ie t \(bu
90 .el o
91 The next eight bits are reserved for future use.
92 .RE
93 .RS +4
94 .TP
95 .ie t \(bu
96 .el o
97 The next 24 bits are the Next-Level Aggregation (\fBNLA\fR) identifier.
98 .RE
99 .RS +4
101 .ie t \(bu
102 .el o
103 The next 16 bits are the Site-Level Aggregation (\fBSLA\fR) identifier.
105 .RS +4
107 .ie t \(bu
108 .el o
109 The last 64 bits are the interface \fBID\fR. This will most often be the
110 hardware address of the link in \fBIEEE EUI-64\fR format.
114 Link-local unicast addresses are divided in this manner:
115 .RS +4
117 .ie t \(bu
118 .el o
119 The first ten bits are the Format Prefix identifying a link-local address.
121 .RS +4
123 .ie t \(bu
124 .el o
125 The next 54 bits are zero.
127 .RS +4
129 .ie t \(bu
130 .el o
131 The last 64 bits are the interface \fBID\fR. This will most often be the
132 hardware address of the link in \fBIEEE EUI-64\fR format.
136 Site-local unicast addresses are divided in this manner:
137 .RS +4
139 .ie t \(bu
140 .el o
141 The first ten bits are the Format Prefix identifying a site-local address.
143 .RS +4
145 .ie t \(bu
146 .el o
147 The next 38 bits are zero.
149 .RS +4
151 .ie t \(bu
152 .el o
153 The next 16 bits are the subnet \fBID\fR.
155 .RS +4
157 .ie t \(bu
158 .el o
159 The last 64 bits are the interface \fBID\fR. This will most often be the
160 hardware address of the link in \fBIEEE EUI-64\fR format.
162 .SH ADDRESSING
164 \fBIPv6\fR addresses are sixteen byte quantities, stored in network byte order.
165 The socket \fBAPI\fR uses the \fBsockaddr_in6\fR structure when passing
166 \fBIPv6\fR addresses between an application and the kernel. The
167 \fBsockaddr_in6\fR structure has the following members:
169 .in +2
171 sa_familty_t     sin6_family;
172 in_port_t        sin6_port;
173 uint32_t         sin6_flowinfo;
174 struct in6_addr  sin6_addr;
175 uint32_t         sin6_scope_id;
176 uint32_t         __sin6_src_id;
178 .in -2
182 Library routines are provided to  manipulate  structures of this form. See
183 \fBinet\fR(3SOCKET).
186 The \fBsin6_addr\fR field of the \fBsockaddr_in6\fR structure specifies a local
187 or remote \fBIPv6\fR address. Each network interface has one or more \fBIPv6\fR
188 addresses configured, that is, a link-local address, a site-local address, and
189 one or more global unicast \fBIPv6\fR addresses. The special value of all zeros
190 may be used on this field to test for "wildcard" matching. Given in a
191 \fBbind\fR(3SOCKET) call, this value leaves the local \fBIPv6\fR address of the
192 socket unspecified, so that the socket will receive connections or messages
193 directed at any of the valid \fBIPv6\fR addresses of the system. This can prove
194 useful when a process neither knows nor cares what the local \fBIPv6\fR address
195 is, or when a process wishes to receive requests using all of its network
196 interfaces.
199 The \fBsockaddr_in6\fR structure given in  the \fBbind()\fR call must specify
200 an \fIin6_addr\fR value of either all zeros or one of the system's valid
201 \fBIPv6\fR addresses. Requests to bind any other address will elicit the error
202 \fBEADDRNOTAVAI\fR. When a \fBconnect\fR(3SOCKET) call is made for a socket
203 that has a wildcard local address, the system sets the \fBsin6_addr\fR field of
204 the socket to the \fBIPv6\fR address of the network interface through which the
205 packets for that connection are routed.
208 The \fBsin6_port\fR field of the \fBsockaddr_in6\fR structure specifies a port
209 number used by \fBTCP\fR or \fBUDP\fR. The local port address specified in a
210 \fBbind()\fR call is restricted to be greater than \fBIPPORT_RESERVED\fR
211 (defined in <\fBnetinet/in.h\fR>) unless the creating process is running as the
212 super-user,  providing a space of protected port numbers. In addition, the
213 local port address cannot be in use by any socket of the same address family
214 and type. Requests to bind sockets to port numbers being used by other sockets
215 return the error \fBEADDRINUSE\fR. If the local port address is specified as
216 \fB0\fR, the system picks a unique port address greater than
217 \fBIPPORT_RESERVED\fR. A unique local port address is also selected when a
218 socket which is not bound is used in a \fBconnect\fR(3SOCKET) or \fBsendto()\fR
219 call. See \fBsend\fR(3SOCKET). This allows programs that do not care which
220 local port number is used to set up \fBTCP\fR connections by simply calling
221 \fBsocket\fR(3SOCKET) and then \fBconnect\fR(3SOCKET), and then sending
222 \fBUDP\fR datagrams with a \fBsocket()\fR call followed by a \fBsendto()\fR
223 call.
226 Although this implementation restricts sockets to unique local port numbers,
227 \fBTCP\fR allows multiple simultaneous connections involving the same local
228 port number so long as the remote \fBIPv6\fR addresses or port numbers are
229 different for each connection. Programs may explicitly override the socket
230 restriction by setting the \fBSO_REUSEADDR\fR socket option with
231 \fBsetsockopt()\fR. See \fBgetsockopt\fR(3SOCKET).
234 In addition, the same port may be bound by two separate sockets if one is an
235 \fBIP\fR socket and the other an \fBIPv6\fR socket.
238 \fBTLI\fR applies somewhat different semantics to the binding of local port
239 numbers. These semantics apply when Internet family protocols are used using
240 the \fBTLI\fR.
241 .SH SOURCE ADDRESS SELECTION
243 IPv6 source address selection is done on a per destination basis, and utilizes
244 a list of rules from which the best source address is selected from candidate
245 addresses. The candidate set comprises a set of local addresses assigned on the
246 system which are up and not anycast.  If just one candidate exists in the
247 candidate set, it is selected.
250 Conceptually, each selection rule prefers one address over another, or
251 determines their equivalence. If a rule produces a tie, a subsequent rule is
252 used to break the tie.
255 The sense of some rules may be reversed on a per-socket basis using the
256 IPV6_SRC_PREFERENCES socket option (see \fBip6\fR(7P)). The flag values for
257 this option are defined in <\fBnetinet/in.h\fR> and are referenced in the
258 description of the appropriate rules below.
261 As the selection rules indicate, the candidate addresses are SA and SB and the
262 destination is D.
264 .ne 2
266 \fBPrefer the same address\fR
268 .RS 30n
269 If SA == D, prefer SA.  If SB == D, prefer SB.
273 .ne 2
275 \fBPrefer appropriate scope\fR
277 .RS 30n
278 Here, Scope(X) is the scope of X according to the IPv6 Addressing Architecture.
280 If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and otherwise
281 prefer SA.
283 If Scope(SB) < Scope(SA): If Scope(SB) < Scope(D), then prefer SA and otherwise
284 prefer SB.
288 .ne 2
290 \fBAvoid deprecated addresses\fR
292 .RS 30n
293 If one of the addresses is deprecated (IFF_DEPRECATED) and the other is not,
294 prefer the one that isn't deprecated.
298 .ne 2
300 \fBPrefer preferred addresses\fR
302 .RS 30n
303 If one of the addresses is preferred (IFF_PREFERRED) and the other is not,
304 prefer the one that is preferred.
308 .ne 2
310 \fBPrefer outgoing interface\fR
312 .RS 30n
313 If one of the addresses is assigned to the interface that will be used to send
314 packets to D and the other is not, then prefer the former.
318 .ne 2
320 \fBPrefer matching label\fR
322 .RS 30n
323 This rule uses labels which are obtained through the IPv6 default address
324 selection policy table. See \fBipaddrsel\fR(1M) for a description of the
325 default contents of the table and how the table is configured.
327 If Label(SA) == Label(D) and Label(SB) != Label(D), then prefer SA.
329 If Label(SB) == Label(D) and Label(SA) != Label(D), then prefer SB.
333 .ne 2
335 \fBPrefer public addresses\fR
337 .RS 30n
338 This rule prefers public addresses over temporary addresses, as defined in
339 \fIRFC 3041\fR. Temporary addresses are disabled by default and may be enabled
340 by appropriate settings in \fBndpd.conf\fR(4).
342 The sense of this rule may be set on a per-socket basis using the
343 IPV6_SRC_PREFERENCES socket option.  Passing the flag IPV6_PREFER_SRC_TMP or
344 IPV6_PREFER_SRC_PUBLIC will cause temporary or public addresses to be
345 preferred, respectively, for that particular socket.  See \fBip6\fR(7P) for
346 more information about IPv6 socket options.
350 .ne 2
352 \fBUse longest matching prefix.\fR
354 .sp .6
355 .RS 4n
356 This rule prefers the source address that has the longer matching prefix with
357 the destination. Because this is the last rule and because both source
358 addresses could have equal matching prefixes, this rule does an \fBxor\fR of
359 each source address with the destination, then selects the source address with
360 the smaller \fBxor\fR value in order to break any potential tie.
362 If SA ^ D < SB ^ D, then prefer SA.
364 If SB ^ D < SA ^ D, then prefer SB.
369 Applications can override this algorithm by calling  \fBbind\fR(3SOCKET) and
370 specifying an address.
371 .SH SEE ALSO
373 \fBioctl\fR(2), \fBbind\fR(3SOCKET), \fBconnect\fR(3SOCKET),
374 \fBgetipnodebyaddr\fR(3SOCKET),
375 \fBgetipnodebyname\fR(3SOCKET),\fBgetprotobyname\fR(3SOCKET),
376 \fBgetservbyname\fR(3SOCKET), \fBgetsockopt\fR(3SOCKET), \fBinet\fR(3SOCKET),
377 \fBsend\fR(3SOCKET), \fBsockaddr\fR(3SOCKET),
378 \fBicmp6\fR(7P), \fBip6\fR(7P), \fBtcp\fR(7P), \fBudp\fR(7P)
381 Conta, A. and Deering, S., \fIInternet Control Message Protocol (ICMPv6) for
382 the Internet Protocol Version 6 (IPv6) Specification\fR, RFC 1885, December
383 1995.
386 Deering, S. and Hinden, B., \fIInternet Protocol, Version 6 (IPv6)
387 Specification\fR, RFC 1883, December 1995.
390 Hinden, B. and Deering, S.,  \fIIP Version 6 Addressing Architecture\fR, RFC
391 1884, December 1995.
394 Draves, R., \fIRFC 3484, Default Address Selection for IPv6.\fR The Internet
395 Society.  February 2003.
398 Narten, T., and Draves, R. \fIRFC 3041, Privacy Extensions for Stateless
399 Address Autoconfiguration in IPv6.\fR The Internet Society.  January 2001.
400 .SH NOTES
402 The \fBIPv6\fR support is subject to change as the Internet protocols develop.
403 Users should not depend on details of the current implementation, but rather
404 the services exported.