share/man/man7p/inet.7p

   1 '\" te
   2 .\"  Copyright 1989 AT&T
   3 .\" Copyright (C) 2000, Sun Microsystems, Inc. All Rights Reserved
   4 .\" 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.
   5 .\" 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.
   6 .\" 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]
   7 .TH INET 7P "Aug 3, 2000"
   8 .SH NAME
   9 inet \- Internet protocol family
  10 .SH SYNOPSIS
  11 .LP
  12 .nf
  13 \fB#include <sys/types.h>\fR
  14 .fi
  15
  16 .LP
  17 .nf
  18 \fB#include <netinet/in.h>\fR
  19 .fi
  20
  21 .SH DESCRIPTION
  22 .LP
  23 The Internet protocol family implements a collection of protocols which are
  24 centered around the Internet Protocol ("\fBIP\fR") and which share a common
  25 address format. The Internet family protocols can be accessed using the socket
  26 interface, where they support the \fBSOCK_STREAM\fR, \fBSOCK_DGRAM\fR, and
  27 \fBSOCK_RAW\fR socket types, or the Transport Level Interface (TLI), where they
  28 support the connectionless (\fBT_CLTS\fR)  and connection oriented
  29 (\fBT_COTS_ORD\fR) service types.
  30 .SH PROTOCOLS
  31 .LP
  32 The Internet protocol family is comprised of the Internet Protocol
  33 ("\fBIP\fR"), the Address Resolution Protocol ("\fBARP\fR"), the Internet
  34 Control Message Protocol ("\fBICMP\fR"), the Transmission Control Protocol
  35 ("\fBTCP\fR"), and the User Datagram Protocol ("\fBUDP\fR").
  36 .sp
  37 .LP
  38 \fBTCP\fR supports the socket interface's \fBSOCK_STREAM\fR abstraction and
  39 \fBTLI\fR's \fBT_COTS_ORD\fR service type. \fBUDP\fR supports the
  40 \fBSOCK_DGRAM\fR socket abstraction and the \fBTLI\fR \fBT_CLTS\fR service
  41 type. See \fBtcp\fR(7P) and \fBudp\fR(7P). A direct interface to \fBIP\fR is
  42 available using both \fBTLI\fR and the socket interface (see \fBip\fR(7P)).
  43 \fBICMP\fR is used by the kernel to handle and report errors in protocol
  44 processing. It is also accessible to user programs (see \fBicmp\fR(7P)).
  45 \fBARP\fR is used to translate 32-bit \fBIP\fR addresses into 48-bit Ethernet
  46 addresses. See \fBarp\fR(7P).
  47 .sp
  48 .LP
  49 The 32-bit \fBIP\fR address is divided into network number and host number
  50 parts. It is frequency-encoded. The most-significant bit is zero in Class A
  51 addresses, in which the high-order 8 bits represent the network number. Class B
  52 addresses have their high order two bits set to 10 and use the high-order 16
  53 bits as the network number field. Class C addresses have a 24-bit network
  54 number part of which the high order three bits are 110. Sites with a cluster of
  55 \fBIP\fR networks may chose to use a single network number for the cluster;
  56 this is done by using subnet addressing. The host number portion of the address
  57 is further subdivided into subnet number and host number parts. Within a
  58 subnet, each subnet appears to be an individual network. Externally, the entire
  59 cluster appears to be a single, uniform network requiring only a single routing
  60 entry. Subnet addressing is enabled and examined by the following
  61 \fBioctl\fR(2) commands. They have the same form as the \fBSIOCSIFADDR\fR
  62 command.
  63 .sp
  64 .ne 2
  65 .na
  66 \fB\fBSIOCSIFNETMASK\fR\fR
  67 .ad
  68 .RS 18n
  69 Set interface network mask. The network mask defines the network part of the
  70 address; if it contains more of the address than the address type would
  71 indicate, then subnets are in use.
  72 .RE
  73
  74 .sp
  75 .ne 2
  76 .na
  77 \fB\fBSIOCGIFNETMASK\fR\fR
  78 .ad
  79 .RS 18n
  80 Get interface network mask.
  81 .RE
  82
  83 .SH ADDRESSING
  84 .LP
  85 \fBIP\fR addresses are four byte quantities, stored in network byte order.
  86 \fBIP\fR addresses should be manipulated using the byte order conversion
  87 routines. See  \fBbyteorder\fR(3SOCKET).
  88 .sp
  89 .LP
  90 Addresses in the Internet protocol family use the  \fBsockaddr_in\fR structure,
  91 which has that following members:
  92 .sp
  93 .in +2
  94 .nf
  95 short    sin_family;
  96 ushort_t sin_port;
  97 struct   in_addr  sin_addr;
  98 char     sin_zero[8];
  99 .fi
 100 .in -2
 101
 102 .sp
 103 .LP
 104 Library routines are provided to manipulate structures of this form; See
 105 \fBinet\fR(3SOCKET).
 106 .sp
 107 .LP
 108 The \fBsin_addr\fR field of the \fBsockaddr_in\fR structure specifies a local
 109 or remote \fBIP\fR address.  Each network interface has its own unique \fBIP\fR
 110 address.  The special value \fBINADDR_ANY\fR may be used in this field to
 111 effect "wildcard" matching. Given in a \fBbind\fR(3SOCKET) call, this value
 112 leaves the local \fBIP\fR address of the socket unspecified, so that the socket
 113 will receive connections or messages directed at any of the valid \fBIP\fR
 114 addresses of the system. This can prove useful when a process neither knows nor
 115 cares what the local \fBIP\fR address is or when a process wishes to receive
 116 requests using all of its network interfaces. The \fBsockaddr_in\fR structure
 117 given in the \fBbind\fR(3SOCKET) call must specify an \fBin_addr\fR value of
 118 either \fBINADDR_ANY\fR or one of the system's valid \fBIP\fR addresses.
 119 Requests to bind any other address will elicit the error  \fBEADDRNOTAVAIL\fR.
 120 When a \fBconnect\fR(3SOCKET) call is made for a socket that has a wildcard
 121 local address, the system sets the \fBsin_addr\fR field of the socket to the
 122 \fBIP\fR address of the network interface that the packets for that connection
 123 are routed through.
 124 .sp
 125 .LP
 126 The \fBsin_port\fR field of the \fBsockaddr_in\fR structure specifies a port
 127 number used by \fBTCP\fR or \fBUDP.\fR The local port address specified in a
 128 \fBbind\fR(3SOCKET) call is restricted to be greater than \fBIPPORT_RESERVED\fR
 129 (defined in <\fB<netinet/in.h>\fR>) unless the creating process is running as
 130 the superuser, providing a space of protected port numbers. In addition, the
 131 local port address must not be in use by any socket of same address family and
 132 type. Requests to bind sockets to port numbers being used by other sockets
 133 return the error \fBEADDRINUSE\fR. If the local port address is specified as 0,
 134 then the system picks a unique port address greater than \fBIPPORT_RESERVED\fR.
 135 A unique local port address is also picked when a socket which is not bound is
 136 used in a \fBconnect\fR(3SOCKET) or \fBsendto\fR (see \fBsend\fR(3SOCKET))
 137 call. This allows programs which do not care which local port number is used to
 138 set up \fBTCP\fR connections by simply calling \fBsocket\fR(3SOCKET) and then
 139 \fBconnect\fR(3SOCKET), and to send \fBUDP\fR datagrams with a
 140 \fBsocket\fR(3SOCKET) call followed by a \fBsendto()\fR call.
 141 .sp
 142 .LP
 143 Although this implementation restricts sockets to unique local port numbers,
 144 \fBTCP\fR allows multiple simultaneous connections involving the same local
 145 port number so long as the remote \fBIP\fR addresses or port numbers are
 146 different for each connection. Programs may explicitly override the socket
 147 restriction by setting the \fBSO_REUSEADDR\fR socket option with
 148 \fBsetsockopt\fR (see \fBgetsockopt\fR(3SOCKET)).
 149 .sp
 150 .LP
 151 \fBTLI\fR applies somewhat different semantics to the binding of local port
 152 numbers. These semantics apply when Internet family protocols are used using
 153 the \fBTLI\fR.
 154 .SH SEE ALSO
 155 .LP
 156 \fBioctl\fR(2), \fBbind\fR(3SOCKET), \fBbyteorder\fR(3SOCKET),
 157 \fBconnect\fR(3SOCKET), \fBgethostbyname\fR(3NSL), \fBgetnetbyname\fR(3SOCKET),
 158 \fBgetprotobyname\fR(3SOCKET), \fBgetservbyname\fR(3SOCKET),
 159 \fBgetsockopt\fR(3SOCKET), \fBsend\fR(3SOCKET), \fBsockaddr\fR(3SOCKET),
 160 \fBsocket\fR(3SOCKET), \fBarp\fR(7P), \fBicmp\fR(7P), \fBip\fR(7P),
 161 \fBtcp\fR(7P), \fBudp\fR(7P)
 162 .sp
 163 .LP
 164 Network Information Center, \fIDDN Protocol Handbook\fR (3 vols.), Network
 165 Information Center, \fBSRI\fR International, Menlo Park, Calif., 1985.
 166 .SH NOTES
 167 .LP
 168 The Internet protocol support is subject to change as the Internet protocols
 169 develop.  Users should not depend on details of the current implementation, but
 170 rather the services exported.