inet6 man page on SmartOS

Man page or keyword search:  
man Server   16655 pages
apropos Keyword Search (all sections)
Output format
SmartOS logo
[printable version]

INET6(7P)							     INET6(7P)

       inet6 - Internet protocol family for Internet Protocol version 6

       #include <sys/types.h>
       #include <netinet/in.h>

       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.

       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 abstrac‐
       tion and the TLI T_CLTS service type. See tcp(7P) and udp(7P). A direct
       interface to IPv6 is available using the socket interface. See ip6(7P).
       ICMPv6 is used by the kernel to handle and report  errors  in  protocol
       processing. It  is also accessible to user programs. See icmp6(7P). NDP
       is used to  translate  128-bit  IPv6  addresses	into  48-bit  Ethernet

       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
       addresses are guaranteed to be unique. The scope is  indicated  by  the
       address	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‐

	   o	  The  next 16 bits are the Site-Level Aggregation (SLA) iden‐

	   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.

       IPv6  addresses	are  sixteen  byte  quantities, stored in network byte
       order.  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_familty_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(3SOCKET).

       The  sin6_addr field of the sockaddr_in6 structure specifies a local or
       remote IPv6 address. Each  network  interface  has  one	or  more  IPv6
       addresses  configured,  that  is,  a  link-local	 address, a site-local
       address, 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(3SOCKET) 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 using 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
       EADDRNOTAVAI. When a connect(3SOCKET) 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()
       call  is	 restricted  to	 be  greater  than IPPORT_RESERVED (defined in
       <netinet/in.h>) unless the creating process is running  as  the	super-
       user,   providing  a  space of protected port numbers. 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 greater than
       IPPORT_RESERVED. A unique local port address is also  selected  when  a
       socket  which  is  not  bound is used in a connect(3SOCKET) or sendto()
       call. See send(3SOCKET). This allows programs that do  not  care	 which
       local  port  number is used to set up TCP connections by simply calling
       socket(3SOCKET) and then connect(3SOCKET), and then sending  UDP	 data‐
       grams with a socket() call followed by a sendto() 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
       option with setsockopt(). See getsockopt(3SOCKET).

       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.

       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(7P)). The flag  values  for
       this  option  are  defined  in <netinet/in.h> and are referenced in the
       description 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, pre‐
				     fer SB.

       Prefer appropriate scope
				     Here, Scope(X) is the scope of X  accord‐
				     ing 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 selec‐
				     tion policy table. See ipaddrsel(1M)  for
				     a	description of the default contents of
				     the table and how the  table  is  config‐

				     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  defined  in  RFC
				     3041. Temporary addresses are disabled by
				     default and may be enabled by appropriate
				     settings in ndpd.conf(4).

				     The  sense	 of  this rule may be set on a
				     per-socket basis using the IPV6_SRC_PREF‐
				     ERENCES  socket option.  Passing the flag
				     IPV6_PREFER_SRC_TMP     or	     IPV6_PRE‐
				     FER_SRC_PUBLIC  will  cause  temporary or
				     public addresses to be preferred, respec‐
				     tively,  for that particular socket.  See
				     ip6(7P) 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
	   because  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(3SOCKET)  and
       specifying an address.

       ioctl(2),  bind(3SOCKET),  connect(3SOCKET),  getipnodebyaddr(3SOCKET),
       getipnodebyname(3SOCKET),getprotobyname(3SOCKET),	    getservby‐
       name(3SOCKET),	getsockopt(3SOCKET),   inet(3SOCKET),	send(3SOCKET),
       icmp6(7P), ip6(7P), tcp(7P), udp(7P)

       Conta, A. and Deering, S., Internet Control Message  Protocol  (ICMPv6)
       for  the	 Internet  Protocol  Version 6 (IPv6) Specification, RFC 1885,
       December 1995.

       Deering, S. and Hinden, B., Internet Protocol, Version 6 (IPv6)	Speci‐
       fication, RFC 1883, December 1995.

       Hinden,	B. and Deering, S.,  IP Version 6 Addressing Architecture, RFC
       1884, December 1995.

       Draves, R., RFC 3484, Default Address Selection for IPv6. The  Internet
       Society.	 February 2003.

       Narten,	T.,  and Draves, R. RFC 3041, Privacy Extensions for Stateless
       Address Autoconfiguration in IPv6. The Internet Society.	 January 2001.

       The IPv6 support	 is  subject  to  change  as  the  Internet  protocols
       develop.	 Users should not depend on details of the current implementa‐
       tion, but rather the services exported.

				  Oct 3, 2002			     INET6(7P)

List of man pages available for SmartOS

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net