No empty .Rs/.Re
[netbsd-mini2440.git] / share / man / man4 / inet.4
blobb7dfc848fa09b3020542a7dc2121675f3ec13cd6
1 .\"     $NetBSD: inet.4,v 1.16 2003/08/07 10:31:02 agc Exp $
2 .\"
3 .\" Copyright (c) 1983, 1991, 1993
4 .\"     The Regents of the University of California.  All rights reserved.
5 .\"
6 .\" Redistribution and use in source and binary forms, with or without
7 .\" modification, are permitted provided that the following conditions
8 .\" are met:
9 .\" 1. Redistributions of source code must retain the above copyright
10 .\"    notice, this list of conditions and the following disclaimer.
11 .\" 2. Redistributions in binary form must reproduce the above copyright
12 .\"    notice, this list of conditions and the following disclaimer in the
13 .\"    documentation and/or other materials provided with the distribution.
14 .\" 3. Neither the name of the University nor the names of its contributors
15 .\"    may be used to endorse or promote products derived from this software
16 .\"    without specific prior written permission.
17 .\"
18 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
19 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
20 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
21 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
22 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
23 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
24 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
25 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
26 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
27 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
28 .\" SUCH DAMAGE.
29 .\"
30 .\"     @(#)inet.4      8.1 (Berkeley) 6/5/93
31 .\"
32 .Dd May 15, 2003
33 .Dt INET 4
34 .Os
35 .Sh NAME
36 .Nm inet
37 .Nd Internet protocol family
38 .Sh SYNOPSIS
39 .In sys/types.h
40 .In netinet/in.h
41 .Sh DESCRIPTION
42 The Internet protocol family is a collection of protocols
43 layered atop the
44 .Em Internet  Protocol
45 .Pq Tn IP
46 transport layer, and using the Internet address format.
47 The Internet family provides protocol support for the
48 .Dv SOCK_STREAM , SOCK_DGRAM ,
49 and
50 .Dv SOCK_RAW
51 socket types; the
52 .Dv SOCK_RAW
53 interface provides access to the
54 .Tn IP
55 protocol.
56 .Sh ADDRESSING
57 Internet addresses are four byte quantities, stored in
58 network standard format (on the
59 .Tn VAX
60 these are word and byte
61 reversed).  The include file
62 .Aq Pa netinet/in.h
63 defines this address
64 as a discriminated union.
65 .Pp
66 Sockets bound to the Internet protocol family use
67 the following addressing structure,
68 .Bd -literal -offset indent
69 struct sockaddr_in {
70         uint8_t         sin_len;
71         sa_family_t     sin_family;
72         in_port_t       sin_port;
73         struct in_addr  sin_addr;
74         int8_t          sin_zero[8];
76 .Ed
77 .Pp
78 Sockets may be created with the local address
79 .Dv INADDR_ANY
80 to effect
81 .Dq wildcard
82 matching on incoming messages.
83 The address in a
84 .Xr connect 2
86 .Xr sendto 2
87 call may be given as
88 .Dv INADDR_ANY
89 to mean
90 .Dq this host .
91 The distinguished address
92 .Dv INADDR_BROADCAST
93 is allowed as a shorthand for the broadcast address on the primary
94 network if the first network configured supports broadcast.
95 .Sh PROTOCOLS
96 The Internet protocol family comprises
97 the
98 .Tn IP
99 transport protocol, Internet Control
100 Message Protocol
101 .Pq Tn ICMP ,
102 Transmission Control
103 Protocol
104 .Pq Tn TCP ,
105 and User Datagram Protocol
106 .Pq Tn UDP .
107 .Tn TCP
108 is used to support the
109 .Dv SOCK_STREAM
110 abstraction while
111 .Tn UDP
112 is used to support the
113 .Dv SOCK_DGRAM
114 abstraction.  A raw interface to
115 .Tn IP
116 is available
117 by creating an Internet socket of type
118 .Dv SOCK_RAW .
120 .Tn ICMP
121 message protocol is accessible from a raw socket.
123 The 32-bit Internet address contains both network and host parts.
124 It is frequency-encoded; the most-significant bit is clear
125 in Class A addresses, in which the high-order 8 bits are the network
126 number.
127 Class B addresses use the high-order 16 bits as the network field,
128 and Class C addresses have a 24-bit network part.
129 Sites with a cluster of local networks and a connection to the
130 Internet may chose to use a single network number for the cluster;
131 this is done by using subnet addressing.
132 The local (host) portion of the address is further subdivided
133 into subnet and host parts.
134 Within a subnet, each subnet appears to be an individual network;
135 externally, the entire cluster appears to be a single, uniform
136 network requiring only a single routing entry.
137 Subnet addressing is enabled and examined by the following
138 .Xr ioctl 2
139 commands on a datagram socket in the Internet domain;
140 they have the same form as the
141 .Dv SIOCIFADDR
142 command (see
143 .Xr netintro 4 ) .
145 .Bl -tag -width SIOCSIFNETMASK
146 .It Dv SIOCSIFNETMASK
147 Set interface network mask.
148 The network mask defines the network part of the address;
149 if it contains more of the address than the address type would indicate,
150 then subnets are in use.
151 .It Dv SIOCGIFNETMASK
152 Get interface network mask.
154 .Sh SEE ALSO
155 .Xr ioctl 2 ,
156 .Xr socket 2 ,
157 .Xr icmp 4 ,
158 .Xr intro 4 ,
159 .Xr ip 4 ,
160 .Xr netintro 4 ,
161 .Xr tcp 4 ,
162 .Xr udp 4
164 .%T "An Introductory 4.4BSD Interprocess Communication Tutorial"
165 .%A Stuart Sechrest
167 .Pq see Pa /usr/share/doc/psd/20.ipctut
169 .%T "Advanced 4.4BSD IPC Tutorial"
170 .%A Samuel J. Leffler
171 .%A Robert S. Fabry
172 .%A William N. Joy
173 .%A Phil Lapsley
174 .%A Steve Miller
175 .%A Chris Torek
177 .Pq see Pa /usr/share/doc/psd/21.ipc
178 .Sh HISTORY
181 protocol interface appeared in
182 .Bx 4.2 .
183 .Sh BUGS
184 The Internet protocol support is subject to change as
185 the Internet protocols develop.  Users should not depend
186 on details of the current implementation, but rather
187 the services exported.