summaryrefslogtreecommitdiff
path: root/lib/libc/net
diff options
context:
space:
mode:
authorJason McIntyre <jmc@cvs.openbsd.org>2006-12-09 13:29:55 +0000
committerJason McIntyre <jmc@cvs.openbsd.org>2006-12-09 13:29:55 +0000
commitd1f4df63e0baf6b565fd22fbbaab792622c531aa (patch)
treebb588113d6bddb3457301d0131f107e2c6d21da1 /lib/libc/net
parent0195bf8e47e94c352cfb0b8af8b46b46c9b6e21c (diff)
various tweaks; my apologies to itojun for forgetting to
send him feedback for these
Diffstat (limited to 'lib/libc/net')
-rw-r--r--lib/libc/net/inet6_opt_init.354
1 files changed, 28 insertions, 26 deletions
diff --git a/lib/libc/net/inet6_opt_init.3 b/lib/libc/net/inet6_opt_init.3
index a97eb0f28ba..9fad745923f 100644
--- a/lib/libc/net/inet6_opt_init.3
+++ b/lib/libc/net/inet6_opt_init.3
@@ -1,4 +1,4 @@
-.\" $OpenBSD: inet6_opt_init.3,v 1.1 2006/12/09 01:12:28 itojun Exp $
+.\" $OpenBSD: inet6_opt_init.3,v 1.2 2006/12/09 13:29:54 jmc Exp $
.\" $KAME: inet6_opt_init.3,v 1.7 2004/12/27 05:08:23 itojun Exp $
.\"
.\" Copyright (C) 2004 WIDE Project.
@@ -63,21 +63,21 @@
Building and parsing the Hop-by-Hop and Destination options is
complicated.
The advanced sockets API defines a set of functions to
-help applications create and manipulate Hop-by-Hope and Destination
+help applications create and manipulate Hop-by-Hop and Destination
options.
.\"This man page describes the functions specified in
-.\"IETF Draft RFC3542 while the
+.\"IETF Draft RFC 3542 while the
.\".Xr inet6_options_space 3
.\"man page documents the functions defined in RFC 2292.
.\"It is expected
.\"that this set of functions will supersede those in RFC 2292 but for
.\"the time being both APIs are retained.
These functions use the
-formatting rules specified in Appendix B in RFC2460, i.e., that the
+formatting rules specified in Appendix B in RFC 2460, i.e. that the
largest field is placed last in the option.
The function prototypes
for these functions are all contained in the header file
-.Aq netinet/in.h .
+.Aq Pa netinet/in.h .
.\"
.Ss inet6_opt_init
The
@@ -92,7 +92,8 @@ then the
.Fn inet6_opt_init
function also initializes the extension header's length field.
When attempting to initialize an extension buffer passed in the
-.Va extbuf argument
+.Va extbuf
+argument,
.Fa extlen
must be a positive multiple of 8 or else the function fails and
returns \-1 to the caller.
@@ -100,7 +101,7 @@ returns \-1 to the caller.
.Ss inet6_opt_append
The
.Fn inet6_opt_append
-function can perform to different jobs.
+function can perform different jobs.
When a valid
.Fa extbuf
argument is supplied it appends an option to the extension buffer and
@@ -113,7 +114,8 @@ of
is
.Dv NULL
then the
-.Fn inet6_opt_append function only reports what the total length would
+.Fn inet6_opt_append
+function only reports what the total length would
be if the option were actually appended.
The
.Fa len
@@ -159,7 +161,7 @@ The
parameter must have a value of 1, 2, 4, or 8 and cannot exceed the
value of
.Fa len .
-The alignment values represent no alignment, 16 bit, 32 bit and 64 bit
+The alignment values represent no alignment, 16-bit, 32-bit and 64-bit
alignments respectively.
.\"
.Ss inet6_opt_finish
@@ -195,7 +197,8 @@ The
argument is a pointer to memory that was returned by the
.Fn inet6_opt_append
call and the
-.Fa offset argument specifies where the option should be placed in the
+.Fa offset
+argument specifies where the option should be placed in the
data buffer.
The
.Fa val
@@ -205,7 +208,7 @@ inserted into the extension header, and the
argument indicates how much data to copy.
.Pp
The caller should ensure that each field is aligned on its natural
-boundaries as described in Appendix B of RFC2460.
+boundaries as described in Appendix B of RFC 2460.
.Pp
The function returns the offset for the next field which is calculated as
.Fa offset
@@ -236,7 +239,7 @@ The option is returned in the arguments
.Fa typep , lenp ,
and
.Fa databufp .
-.Fa typep, lenp,
+.Fa typep , lenp ,
and
.Fa databufp
point to the 8-bit option type, the 8-bit option length and the option
@@ -280,7 +283,7 @@ or
functions.
The
.Fa val
-argument points where the data will be extracted.
+argument points to where the data will be extracted.
The
.Fa offset
argument specifies from where in the data portion of the option the
@@ -288,7 +291,7 @@ value should be extracted; the first byte of option data is specified
by an offset of zero.
.Pp
It is expected that each field is aligned on its natural boundaries as
-described in Appendix B of RFC2460.
+described in Appendix B of RFC 2460.
.Pp
The function returns the offset for the next field
by calculating
@@ -298,18 +301,17 @@ by calculating
which can be used when extracting option content with multiple fields.
Robust receivers must verify alignment before calling this function.
.\"
-.Sh DIAGNOSTICS
-All the functions return
-\-1
-on an error.
-.\"
.Sh EXAMPLES
-RFC3542 gives comprehensive examples in Section 23.
-.Pp
+RFC 3542 gives comprehensive examples in Section 23.
KAME also provides examples in the
.Pa advapitest
directory of its kit.
.\"
+.Sh DIAGNOSTICS
+All the functions return
+\-1
+on an error.
+.\"
.Sh SEE ALSO
.Rs
.%A W. Stevens
@@ -317,20 +319,20 @@ directory of its kit.
.%A E. Nordmark
.%A T. Jinmei
.%T "Advanced Sockets API for IPv6"
-.%N RFC3542
+.%N RFC 3542
.%D October 2002
.Re
.Rs
.%A S. Deering
.%A R. Hinden
.%T "Internet Protocol, Version 6 (IPv6) Specification"
-.%N RFC2460
+.%N RFC 2460
.%D December 1998
.Re
-.Sh HISTORY
-The implementation first appeared in KAME advanced networking kit.
.Sh STANDARDS
The functions are documented in
.Dq Advanced Sockets API for IPv6
-.Pq RFC3542 .
+.Pq RFC 3542 .
+.Sh HISTORY
+The implementation first appeared in KAME advanced networking kit.
.\"