inet6 man page on Solaris

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

inet6(7P)			   Protocols			     inet6(7P)

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 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
       addresses.

       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 identified
       by  that	 address,  pursuant  to the routing protocol's measure of dis‐
       tance. 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‐
		  tifier.

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

	   o	  The last 64 bits are the interface ID. This is 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 is 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 is 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
       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  can  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 receives
       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 elicits the error EAD‐
       DRNOTAVAI. 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  can  explicitly
       override	 the  socket  restriction  by  setting the SO_REUSEADDR socket
       option with setsockopt(). See getsockopt(3SOCKET).

       In addition, the same port can 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 can 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 is used to send	 pack‐
				     ets  to D and the other is not, then pre‐
				     fer 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‐
				     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  defined  in  RFC
				     3041. Temporary addresses are disabled by
				     default and can be enabled by appropriate
				     settings in ndpd.conf(4).

				     The  sense	 of  this rule can 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 causes temporary or public
				     addresses to be preferred,	 respectively,
				     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.

SEE ALSO
       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.

NOTES
       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.

SunOS 5.10			  17 May 2011			     inet6(7P)
[top]

List of man pages available for Solaris

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]
Tweet
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