1 |
27 |
unneback |
.\" $OpenBSD: inet.3,v 1.13 2001/02/17 23:13:26 pjanzen Exp $
|
2 |
|
|
.\" $NetBSD: inet.3,v 1.7 1997/06/18 02:25:24 lukem Exp $
|
3 |
|
|
.\"
|
4 |
|
|
.\" Copyright (c) 1983, 1990, 1991, 1993
|
5 |
|
|
.\" The Regents of the University of California. All rights reserved.
|
6 |
|
|
.\"
|
7 |
|
|
.\" Redistribution and use in source and binary forms, with or without
|
8 |
|
|
.\" modification, are permitted provided that the following conditions
|
9 |
|
|
.\" are met:
|
10 |
|
|
.\" 1. Redistributions of source code must retain the above copyright
|
11 |
|
|
.\" notice, this list of conditions and the following disclaimer.
|
12 |
|
|
.\" 2. Redistributions in binary form must reproduce the above copyright
|
13 |
|
|
.\" notice, this list of conditions and the following disclaimer in the
|
14 |
|
|
.\" documentation and/or other materials provided with the distribution.
|
15 |
|
|
.\" 3. All advertising materials mentioning features or use of this software
|
16 |
|
|
.\" must display the following acknowledgement:
|
17 |
|
|
.\" This product includes software developed by the University of
|
18 |
|
|
.\" California, Berkeley and its contributors.
|
19 |
|
|
.\" 4. Neither the name of the University nor the names of its contributors
|
20 |
|
|
.\" may be used to endorse or promote products derived from this software
|
21 |
|
|
.\" without specific prior written permission.
|
22 |
|
|
.\"
|
23 |
|
|
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
|
24 |
|
|
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
25 |
|
|
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
26 |
|
|
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
|
27 |
|
|
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
28 |
|
|
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
29 |
|
|
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
30 |
|
|
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
31 |
|
|
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
32 |
|
|
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
33 |
|
|
.\" SUCH DAMAGE.
|
34 |
|
|
.\"
|
35 |
|
|
.\" @(#)inet.3 8.1 (Berkeley) 6/4/93
|
36 |
|
|
.\"
|
37 |
|
|
.Dd June 18, 1997
|
38 |
|
|
.Dt INET 3
|
39 |
|
|
.Os
|
40 |
|
|
.Sh NAME
|
41 |
|
|
.Nm inet_addr ,
|
42 |
|
|
.Nm inet_aton ,
|
43 |
|
|
.Nm inet_lnaof ,
|
44 |
|
|
.Nm inet_makeaddr ,
|
45 |
|
|
.Nm inet_netof ,
|
46 |
|
|
.Nm inet_network ,
|
47 |
|
|
.Nm inet_ntoa ,
|
48 |
|
|
.Nm inet_ntop ,
|
49 |
|
|
.Nm inet_pton
|
50 |
|
|
.Nd Internet address manipulation routines
|
51 |
|
|
.Sh SYNOPSIS
|
52 |
|
|
.Fd #include
|
53 |
|
|
.Fd #include
|
54 |
|
|
.Fd #include
|
55 |
|
|
.Ft in_addr_t
|
56 |
|
|
.Fn inet_addr "const char *cp"
|
57 |
|
|
.Ft int
|
58 |
|
|
.Fn inet_aton "const char *cp" "struct in_addr *addr"
|
59 |
|
|
.Ft in_addr_t
|
60 |
|
|
.Fn inet_lnaof "struct in_addr in"
|
61 |
|
|
.Ft struct in_addr
|
62 |
|
|
.Fn inet_makeaddr "unsigned long net" "unsigned long lna"
|
63 |
|
|
.Ft in_addr_t
|
64 |
|
|
.Fn inet_netof "struct in_addr in"
|
65 |
|
|
.Ft in_addr_t
|
66 |
|
|
.Fn inet_network "const char *cp"
|
67 |
|
|
.Ft char *
|
68 |
|
|
.Fn inet_ntoa "struct in_addr in"
|
69 |
|
|
.Ft const char *
|
70 |
|
|
.Fn inet_ntop "int af" "const void *src" "char *dst" "size_t size"
|
71 |
|
|
.Ft int
|
72 |
|
|
.Fn inet_pton "int af" "const char *src" "void *dst"
|
73 |
|
|
.Sh DESCRIPTION
|
74 |
|
|
The routines
|
75 |
|
|
.Fn inet_aton ,
|
76 |
|
|
.Fn inet_addr
|
77 |
|
|
and
|
78 |
|
|
.Fn inet_network
|
79 |
|
|
interpret character strings representing
|
80 |
|
|
numbers expressed in the Internet standard
|
81 |
|
|
.Ql \&.
|
82 |
|
|
notation.
|
83 |
|
|
The
|
84 |
|
|
.Fn inet_pton
|
85 |
|
|
function converts a presentation format address (that is, printable form
|
86 |
|
|
as held in a character string) to network format (usually a
|
87 |
|
|
.Li struct in_addr
|
88 |
|
|
or some other internal binary representation, in network byte order).
|
89 |
|
|
It returns 1 if the address was valid for the specified address family, or
|
90 |
|
|
|
91 |
|
|
if some system error occurred (in which case
|
92 |
|
|
.Va errno
|
93 |
|
|
will have been set).
|
94 |
|
|
This function is presently valid for
|
95 |
|
|
.Dv AF_INET
|
96 |
|
|
and
|
97 |
|
|
.Dv AF_INET6 .
|
98 |
|
|
The
|
99 |
|
|
.Fn inet_aton
|
100 |
|
|
routine interprets the specified character string as an Internet address,
|
101 |
|
|
placing the address into the structure provided.
|
102 |
|
|
It returns 1 if the string was successfully interpreted,
|
103 |
|
|
or 0 if the string was invalid.
|
104 |
|
|
The
|
105 |
|
|
.Fn inet_addr
|
106 |
|
|
and
|
107 |
|
|
.Fn inet_network
|
108 |
|
|
functions return numbers suitable for use
|
109 |
|
|
as Internet addresses and Internet network
|
110 |
|
|
numbers, respectively.
|
111 |
|
|
.Pp
|
112 |
|
|
The function
|
113 |
|
|
.Fn inet_ntop
|
114 |
|
|
converts an address from network format (usually a
|
115 |
|
|
.Li struct in_addr
|
116 |
|
|
or some other binary form, in network byte order) to presentation format
|
117 |
|
|
(suitable for external display purposes).
|
118 |
|
|
It returns
|
119 |
|
|
.Dv NULL
|
120 |
|
|
if a system
|
121 |
|
|
error occurs (in which case,
|
122 |
|
|
.Va errno
|
123 |
|
|
will have been set), or it returns a pointer to the destination string.
|
124 |
|
|
The routine
|
125 |
|
|
.Fn inet_ntoa
|
126 |
|
|
takes an Internet address and returns an
|
127 |
|
|
.Tn ASCII
|
128 |
|
|
string representing the address in
|
129 |
|
|
.Ql \&.
|
130 |
|
|
notation.
|
131 |
|
|
The routine
|
132 |
|
|
.Fn inet_makeaddr
|
133 |
|
|
takes an Internet network number and a local
|
134 |
|
|
network address and constructs an Internet address
|
135 |
|
|
from it.
|
136 |
|
|
The routines
|
137 |
|
|
.Fn inet_netof
|
138 |
|
|
and
|
139 |
|
|
.Fn inet_lnaof
|
140 |
|
|
break apart Internet host addresses, returning
|
141 |
|
|
the network number and local network address part,
|
142 |
|
|
respectively.
|
143 |
|
|
.Pp
|
144 |
|
|
All Internet addresses are returned in network
|
145 |
|
|
order (bytes ordered from left to right).
|
146 |
|
|
All network numbers and local address parts are
|
147 |
|
|
returned as machine format integer values.
|
148 |
|
|
.Sh INTERNET ADDRESSES (IP VERSION 4)
|
149 |
|
|
Values specified using the
|
150 |
|
|
.Ql \&.
|
151 |
|
|
notation take one
|
152 |
|
|
of the following forms:
|
153 |
|
|
.Bd -literal -offset indent
|
154 |
|
|
a.b.c.d
|
155 |
|
|
a.b.c
|
156 |
|
|
a.b
|
157 |
|
|
a
|
158 |
|
|
.Ed
|
159 |
|
|
.Pp
|
160 |
|
|
When four parts are specified, each is interpreted
|
161 |
|
|
as a byte of data and assigned, from left to right,
|
162 |
|
|
to the four bytes of an Internet address.
|
163 |
|
|
Note that when an Internet address is viewed as a 32-bit
|
164 |
|
|
integer quantity on a system that uses little-endian
|
165 |
|
|
byte order (such as the
|
166 |
|
|
.Tn Intel 386, 486
|
167 |
|
|
and
|
168 |
|
|
.Tn Pentium
|
169 |
|
|
processors) the bytes referred to above appear as
|
170 |
|
|
.Dq Li d.c.b.a .
|
171 |
|
|
That is, little-endian bytes are ordered from right to left.
|
172 |
|
|
.Pp
|
173 |
|
|
When a three part address is specified, the last
|
174 |
|
|
part is interpreted as a 16-bit quantity and placed
|
175 |
|
|
in the rightmost two bytes of the network address.
|
176 |
|
|
This makes the three part address format convenient
|
177 |
|
|
for specifying Class B network addresses as
|
178 |
|
|
.Dq Li 128.net.host .
|
179 |
|
|
.Pp
|
180 |
|
|
When a two part address is supplied, the last part
|
181 |
|
|
is interpreted as a 24-bit quantity and placed in
|
182 |
|
|
the rightmost three bytes of the network address.
|
183 |
|
|
This makes the two part address format convenient
|
184 |
|
|
for specifying Class A network addresses as
|
185 |
|
|
.Dq Li net.host .
|
186 |
|
|
.Pp
|
187 |
|
|
When only one part is given, the value is stored
|
188 |
|
|
directly in the network address without any byte
|
189 |
|
|
rearrangement.
|
190 |
|
|
.Pp
|
191 |
|
|
All numbers supplied as
|
192 |
|
|
.Dq parts
|
193 |
|
|
in a
|
194 |
|
|
.Ql \&.
|
195 |
|
|
notation
|
196 |
|
|
may be decimal, octal, or hexadecimal, as specified
|
197 |
|
|
in the C language (i.e., a leading 0x or 0X implies
|
198 |
|
|
hexadecimal; otherwise, a leading 0 implies octal;
|
199 |
|
|
otherwise, the number is interpreted as decimal).
|
200 |
|
|
.Sh INTERNET ADDRESSES (IP VERSION 6)
|
201 |
|
|
In order to support scoped IPv6 addresses,
|
202 |
|
|
.Xr getaddrinfo 3
|
203 |
|
|
and
|
204 |
|
|
.Xr getnameinfo 3
|
205 |
|
|
are recommended rather than the functions presented here.
|
206 |
|
|
.Pp
|
207 |
|
|
The presentation format of an IPv6 address is given in [RFC1884 2.2]:
|
208 |
|
|
.Pp
|
209 |
|
|
There are three conventional forms for representing IPv6 addresses as
|
210 |
|
|
text strings:
|
211 |
|
|
.Bl -enum
|
212 |
|
|
.It
|
213 |
|
|
The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the
|
214 |
|
|
hexadecimal values of the eight 16-bit pieces of the address.
|
215 |
|
|
Examples:
|
216 |
|
|
.Bd -literal -offset indent
|
217 |
|
|
FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
|
218 |
|
|
1080:0:0:0:8:800:200C:417A
|
219 |
|
|
.Ed
|
220 |
|
|
.Pp
|
221 |
|
|
Note that it is not necessary to write the leading zeros in an
|
222 |
|
|
individual field, but there must be at least one numeral in
|
223 |
|
|
every field (except for the case described in 2.).
|
224 |
|
|
.It
|
225 |
|
|
Due to the method of allocating certain styles of IPv6
|
226 |
|
|
addresses, it will be common for addresses to contain long
|
227 |
|
|
strings of zero bits.
|
228 |
|
|
In order to make writing addresses
|
229 |
|
|
.Pp
|
230 |
|
|
containing zero bits easier a special syntax is available to
|
231 |
|
|
compress the zeros.
|
232 |
|
|
The use of
|
233 |
|
|
.Dq \&:\&:
|
234 |
|
|
indicates multiple groups
|
235 |
|
|
of 16 bits of zeros.
|
236 |
|
|
The
|
237 |
|
|
.Dq \&:\&:
|
238 |
|
|
can only appear once in an
|
239 |
|
|
address.
|
240 |
|
|
The
|
241 |
|
|
.Dq \&:\&:
|
242 |
|
|
can also be used to compress the leading and/or trailing zeros in an address.
|
243 |
|
|
.Pp
|
244 |
|
|
For example the following addresses:
|
245 |
|
|
.Bd -literal -offset indent
|
246 |
|
|
1080:0:0:0:8:800:200C:417A a unicast address
|
247 |
|
|
FF01:0:0:0:0:0:0:43 a multicast address
|
248 |
|
|
0:0:0:0:0:0:0:1 the loopback address
|
249 |
|
|
0:0:0:0:0:0:0:0 the unspecified addresses
|
250 |
|
|
.Ed
|
251 |
|
|
.Pp
|
252 |
|
|
may be represented as:
|
253 |
|
|
.Bd -literal -offset indent
|
254 |
|
|
1080::8:800:200C:417A a unicast address
|
255 |
|
|
FF01::43 a multicast address
|
256 |
|
|
::1 the loopback address
|
257 |
|
|
:: the unspecified addresses
|
258 |
|
|
.Ed
|
259 |
|
|
.It
|
260 |
|
|
An alternative form that is sometimes more convenient when
|
261 |
|
|
dealing with a mixed environment of IPv4 and IPv6 nodes is
|
262 |
|
|
x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values
|
263 |
|
|
of the six high-order 16-bit pieces of the address, and the 'd's
|
264 |
|
|
are the decimal values of the four low-order 8-bit pieces of the
|
265 |
|
|
address (standard IPv4 representation).
|
266 |
|
|
Examples:
|
267 |
|
|
.Bd -literal -offset indent
|
268 |
|
|
0:0:0:0:0:0:13.1.68.3
|
269 |
|
|
0:0:0:0:0:FFFF:129.144.52.38
|
270 |
|
|
.Ed
|
271 |
|
|
.Pp
|
272 |
|
|
or in compressed form:
|
273 |
|
|
.Bd -literal -offset indent
|
274 |
|
|
::13.1.68.3
|
275 |
|
|
::FFFF:129.144.52.38
|
276 |
|
|
.Ed
|
277 |
|
|
.El
|
278 |
|
|
.Sh DIAGNOSTICS
|
279 |
|
|
The constant
|
280 |
|
|
.Dv INADDR_NONE
|
281 |
|
|
is returned by
|
282 |
|
|
.Fn inet_addr
|
283 |
|
|
and
|
284 |
|
|
.Fn inet_network
|
285 |
|
|
for malformed requests.
|
286 |
|
|
.Sh SEE ALSO
|
287 |
|
|
.Xr byteorder 3 ,
|
288 |
|
|
.Xr gethostbyname 3 ,
|
289 |
|
|
.Xr getnetent 3 ,
|
290 |
|
|
.Xr inet_net 3 ,
|
291 |
|
|
.Xr hosts 5 ,
|
292 |
|
|
.Xr networks 5
|
293 |
|
|
.Sh STANDARDS
|
294 |
|
|
The
|
295 |
|
|
.Nm inet_ntop
|
296 |
|
|
and
|
297 |
|
|
.Nm inet_pton
|
298 |
|
|
functions conforms to the IETF IPv6 BSD API and address formatting
|
299 |
|
|
specifications.
|
300 |
|
|
Note that
|
301 |
|
|
.Nm inet_pton
|
302 |
|
|
does not accept 1-, 2-, or 3-part dotted addresses; all four parts
|
303 |
|
|
must be specified.
|
304 |
|
|
This is a narrower input set than that accepted by
|
305 |
|
|
.Nm inet_aton .
|
306 |
|
|
.Sh HISTORY
|
307 |
|
|
The
|
308 |
|
|
.Nm inet_addr ,
|
309 |
|
|
.Nm inet_network ,
|
310 |
|
|
.Nm inet_makeaddr ,
|
311 |
|
|
.Nm inet_lnaof
|
312 |
|
|
and
|
313 |
|
|
.Nm inet_netof
|
314 |
|
|
functions appeared in
|
315 |
|
|
.Bx 4.2 .
|
316 |
|
|
The
|
317 |
|
|
.Nm inet_aton
|
318 |
|
|
and
|
319 |
|
|
.Nm inet_ntoa
|
320 |
|
|
functions appeared in
|
321 |
|
|
.Bx 4.3 .
|
322 |
|
|
The
|
323 |
|
|
.Nm inet_pton
|
324 |
|
|
and
|
325 |
|
|
.Nm inet_ntop
|
326 |
|
|
functions appeared in BIND 4.9.4.
|
327 |
|
|
.Sh BUGS
|
328 |
|
|
The value
|
329 |
|
|
.Dv INADDR_NONE
|
330 |
|
|
(0xffffffff) is a valid broadcast address, but
|
331 |
|
|
.Fn inet_addr
|
332 |
|
|
cannot return that value without indicating failure.
|
333 |
|
|
Also,
|
334 |
|
|
.Fn inet_addr
|
335 |
|
|
should have been designed to return a
|
336 |
|
|
.Li struct in_addr .
|
337 |
|
|
The newer
|
338 |
|
|
.Fn inet_aton
|
339 |
|
|
function does not share these problems, and almost all existing code
|
340 |
|
|
should be modified to use
|
341 |
|
|
.Fn inet_aton
|
342 |
|
|
instead.
|
343 |
|
|
.Pp
|
344 |
|
|
The problem of host byte ordering versus network byte ordering is
|
345 |
|
|
confusing.
|
346 |
|
|
.Pp
|
347 |
|
|
The string returned by
|
348 |
|
|
.Fn inet_ntoa
|
349 |
|
|
resides in a static memory area.
|