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