Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
inet6(7P)			   Protocols			     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  ad-

       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

	    The	 next  13 bits are the Top-Level Aggregation (TLA) identifier.
	    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) identifier.

	 o  The	next 16	bits are the Site-Level	Aggregation (SLA)  identifier.

	 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

	 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

	 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 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_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  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(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 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
       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 IP-
       PORT_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 op-
       tion 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 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

	   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

       Prefer matching label

	   This	rule uses labels which are obtained through the	 IPv6  default
	   address selection 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 de-
	   fined 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_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(7P)  for	more information about IPv6 socket op-

       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(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, De-
       cember 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 de-
       velop. Users should not depend on details of  the  current  implementa-
       tion, but rather	the services exported.

SunOS 5.10			  3 Oct	2002			     inet6(7P)


Want to link to this manual page? Use this URL:

home | help