inet6(4p) 맨 페이지 - 윈디하나의 솔라나라


맨 페이지 이름


inet6(4P)                      Network Protocols                     inet6(4P)

       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 abstraction
       and the TLI  T_CLTS service type. See tcp(4P)  and  udp(4P).  A  direct
       interface to IPv6 is available using the socket interface. See ip6(4P).
       ICMPv6 is used by the kernel to handle and report  errors  in  protocol
       processing.  It is also accessible to user programs. See icmp6(4P). 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_family_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(3C).

       sin6_family is always set to AF_INET6.

       sin6_flowinfo can be used to set the 20-bit IPv6 flow label. An example
       of the code fragment is as follows:

         struct sockaddr_in6 to6;
         bzero((char *)&to6, sizeof (struct sockaddr_in6));
         to6.sin6_family = AF_INET6;
         to6.sin6_flowinfo = htonl(flow_label_val) & IPV6_FLOWINFO_FLOWLABEL;

       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(3C) call, this value leaves the local IPv6
       address of the socket unspecified, so that the socket will receive con‐
       nections 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
       EADDRNOTAVAIL.  When a connect(3C) 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(3C)  or  sendto()  call.
       See  send(3C).  This  allows programs that do not care which local port
       number is used to set up TCP connections by simply  calling  socket(3C)
       and  then  connect(3C),  and then sending UDP datagrams 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(3C).

       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(4P)). 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, prefer

       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(8) 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(5).

                                     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(4P)  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(3C) and speci‐
       fying an address.

       ioctl(2),  bind(3C),  connect(3C),  getipnodebyaddr(3C),   getipnodeby‐
       name(3C),    getprotobyname(3C),   getservbyname(3C),   getsockopt(3C),
       inet(3C), send(3C), icmp6(4P), ip6(4P), tcp(4P), udp(4P)

       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.

Oracle Solaris 11.4               14 May 2018                        inet6(4P)
맨 페이지 내용의 저작권은 맨 페이지 작성자에게 있습니다.