xref: /freebsd/share/man/man4/ip6.4 (revision 70fe064ad7cab6c0444b91622f60ec6a462f308a)
1.\"	$KAME: ip6.4,v 1.14 2001/02/26 09:31:39 itojun Exp $
2.\"
3.\" Copyright (C) 1999 WIDE Project.
4.\" 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 project 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 PROJECT 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 PROJECT 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.\" Copyright (c) 1983, 1991, 1993
31.\"	The Regents of the University of California.  All rights reserved.
32.\"
33.\" Redistribution and use in source and binary forms, with or without
34.\" modification, are permitted provided that the following conditions
35.\" are met:
36.\" 1. Redistributions of source code must retain the above copyright
37.\"    notice, this list of conditions and the following disclaimer.
38.\" 2. Redistributions in binary form must reproduce the above copyright
39.\"    notice, this list of conditions and the following disclaimer in the
40.\"    documentation and/or other materials provided with the distribution.
41.\" 3. All advertising materials mentioning features or use of this software
42.\"    must display the following acknowledgement:
43.\"	This product includes software developed by the University of
44.\"	California, Berkeley and its contributors.
45.\" 4. Neither the name of the University nor the names of its contributors
46.\"    may be used to endorse or promote products derived from this software
47.\"    without specific prior written permission.
48.\"
49.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
50.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
51.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
52.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
53.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
54.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
55.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
56.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
57.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
58.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
59.\" SUCH DAMAGE.
60.\"
61.\" $FreeBSD$
62.\"
63.Dd March 13, 2000
64.Dt IP6 4
65.Os
66.\"
67.Sh NAME
68.Nm ip6
69.Nd Internet Protocol version 6 (IPv6)
70.\"
71.Sh SYNOPSIS
72.In sys/types.h
73.In sys/socket.h
74.In netinet/in.h
75.Ft int
76.Fn socket AF_INET6 SOCK_RAW proto
77.\"
78.Sh DESCRIPTION
79.Tn IPv6
80is the network layer protocol used by the Internet protocol version 6 family
81.Pq Dv AF_INET6 .
82Options may be set at the
83.Tn IPv6
84level when using higher-level protocols that are based on
85.Tn IPv6
86(such as
87.Tn TCP
88and
89.Tn UDP ) .
90It may also be accessed through a
91.Dq raw socket
92when developing new protocols, or special-purpose applications.
93.Pp
94There are several
95.Tn IPv6-level
96.Xr setsockopt 2 Ns / Ns Xr getsockopt 2
97options.
98They are separated into the basic IPv6 sockets API
99(defined in RFC2553),
100and the advanced API
101(defined in RFC2292).
102The basic API looks very similar to the API presented in
103.Xr ip 4 .
104Advanced API uses ancillary data and can handle more complex cases.
105.Pp
106To specify some of socket options, certain privilege
107(i.e. root privilege) is required.
108.\"
109.Ss Basic IPv6 sockets API
110.Dv IPV6_UNICAST_HOPS
111may be used to set the hoplimit field in the
112.Tn IPv6
113header.
114As symbol name suggests, the option controls hoplimit field on unicast packets.
115If -1 is specified, the kernel will use a default value.
116If a value of 0 to 255 is specified, the packet will have the specified
117value as hoplimit.
118Other values are considered invalid, and
119.Er EINVAL
120will be returned.
121For example:
122.Bd -literal -offset indent
123int hlim = 60;                   /* max = 255 */
124setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS, &hlim, sizeof(hlim));
125.Ed
126.Pp
127.Tn IPv6
128multicasting is supported only on
129.Dv AF_INET6
130sockets of type
131.Dv SOCK_DGRAM
132and
133.Dv SOCK_RAW,
134and only on networks where the interface driver supports multicasting.
135.Pp
136The
137.Dv IPV6_MULTICAST_HOPS
138option changes the hoplimit for outgoing multicast datagrams
139in order to control the scope of the multicasts:
140.Bd -literal -offset indent
141unsigned int hlim;	/* range: 0 to 255, default = 1 */
142setsockopt(s, IPPROTO_IPV6, IPV6_MULTICAST_HOPS, &hlim, sizeof(hlim));
143.Ed
144.Pp
145Datagrams with a hoplimit of 1 are not forwarded beyond the local network.
146Multicast datagrams with a hoplimit of 0 will not be transmitted on any network,
147but may be delivered locally if the sending host belongs to the destination
148group and if multicast loopback has not been disabled on the sending socket
149(see below).
150Multicast datagrams with hoplimit greater than 1 may be forwarded
151to other networks if a multicast router is attached to the local network.
152.Pp
153For hosts with multiple interfaces, each multicast transmission is
154sent from the primary network interface.
155The
156.Dv IPV6_MULTICAST_IF
157option overrides the default for
158subsequent transmissions from a given socket:
159.Bd -literal -offset indent
160unsigned int outif;
161outif = if_nametoindex("ne0");
162setsockopt(s, IPPROTO_IPV6, IPV6_MULTICAST_IF, &outif, sizeof(outif));
163.Ed
164.Pp
165where "outif" is an interface index of the desired interface,
166or 0 to specify the default interface.
167.Pp
168If a multicast datagram is sent to a group to which the sending host itself
169belongs (on the outgoing interface), a copy of the datagram is, by default,
170looped back by the IPv6 layer for local delivery.
171The
172.Dv IPV6_MULTICAST_LOOP
173option gives the sender explicit control
174over whether or not subsequent datagrams are looped back:
175.Bd -literal -offset indent
176u_char loop;	/* 0 = disable, 1 = enable (default) */
177setsockopt(s, IPPROTO_IPV6, IPV6_MULTICAST_LOOP, &loop, sizeof(loop));
178.Ed
179.Pp
180This option
181improves performance for applications that may have no more than one
182instance on a single host (such as a router daemon), by eliminating
183the overhead of receiving their own transmissions.
184It should generally not be used by applications for which there
185may be more than one instance on a single host (such as a conferencing
186program) or for which the sender does not belong to the destination
187group (such as a time querying program).
188.Pp
189A multicast datagram sent with an initial hoplimit greater than 1 may be delivered
190to the sending host on a different interface from that on which it was sent,
191if the host belongs to the destination group on that other interface.
192The loopback control option has no effect on such delivery.
193.Pp
194A host must become a member of a multicast group before it can receive
195datagrams sent to the group.
196To join a multicast group, use the
197.Dv IPV6_JOIN_GROUP
198option:
199.Bd -literal -offset indent
200struct ipv6_mreq mreq6;
201setsockopt(s, IPPROTO_IPV6, IPV6_JOIN_GROUP, &mreq6, sizeof(mreq6));
202.Ed
203.Pp
204where
205.Fa mreq6
206is the following structure:
207.Bd -literal -offset indent
208struct ipv6_mreq {
209    struct in6_addr ipv6mr_multiaddr;
210    u_int ipv6mr_interface;
211};
212.Ed
213.Pp
214.Dv ipv6mr_interface
215should be 0 to choose the default multicast interface, or the
216interface index of a particular multicast-capable interface if
217the host is multihomed.
218Membership is associated with a single interface;
219programs running on multihomed hosts may need to
220join the same group on more than one interface.
221.Pp
222To drop a membership, use:
223.Bd -literal -offset indent
224struct ipv6_mreq mreq6;
225setsockopt(s, IPPROTO_IPV6, IPV6_LEAVE_GROUP, &mreq6, sizeof(mreq6));
226.Ed
227.Pp
228where
229.Fa mreq6
230contains the same values as used to add the membership.
231Memberships are dropped when the socket is closed or the process exits.
232.Pp
233.Dv IPV6_PORTRANGE
234controls how ephemeral ports are allocated for
235.Dv SOCK_STREAM
236and
237.Dv SOCK_DGRAM
238sockets.
239For example,
240.Bd -literal -offset indent
241int range = IPV6_PORTRANGE_LOW;       /* see <netinet/in.h> */
242setsockopt(s, IPPROTO_IPV6, IPV6_PORTRANGE, &range, sizeof(range));
243.Ed
244.Pp
245.Dv IPV6_V6ONLY
246controls behavior of
247.Dv AF_INET6
248wildcard listening socket.
249The following example sets the option to 1:
250.Bd -literal -offset indent
251int on = 1;
252setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY, &on, sizeof(on));
253.Ed
254.Pp
255If set to 1,
256.Dv AF_INET6
257wildcard listening socket will accept IPv6 traffic only.
258If set to 0, it will accept IPv4 traffic as well,
259as if it was from IPv4 mapped address like
260.Li ::ffff:10.1.1.1 .
261.\" RFC2553 defines the behavior when the variable is set to 0.
262Note that if you set it this to 0,
263IPv4 access control gets much more complicated.
264For example, even if you have no listening
265.Dv AF_INET
266listening socket on port
267.Li X ,
268you will end up accepting IPv4 traffic by
269.Dv AF_INET6
270listening socket on the same port.
271The default value for this flag is copied at socket instantiation time,
272from
273.Li net.inet6.ip6.v6only
274.Xr sysctl 3
275variable.
276The option affects
277.Tn TCP
278and
279.Tn UDP
280sockets only.
281.\"
282.Ss Advanced IPv6 sockets API
283The advanced IPv6 sockets API lets userland programs specify or obtain
284details about the IPv6 header and the IPv6 extension headers on packets.
285The advanced API uses ancillary data for passing data from/to the kernel.
286.Pp
287There are
288.Xr setsockopt 2 Ns / Ns Xr getsockopt 2
289options to get optional information on incoming packets.
290They are
291.Dv IPV6_PKTINFO ,
292.Dv IPV6_HOPLIMIT ,
293.Dv IPV6_HOPOPTS ,
294.Dv IPV6_DSTOPTS ,
295and
296.Dv IPV6_RTHDR .
297.Bd -literal -offset indent
298int  on = 1;
299
300setsockopt(fd, IPPROTO_IPV6, IPV6_PKTINFO,  &on, sizeof(on));
301setsockopt(fd, IPPROTO_IPV6, IPV6_HOPLIMIT, &on, sizeof(on));
302setsockopt(fd, IPPROTO_IPV6, IPV6_HOPOPTS,  &on, sizeof(on));
303setsockopt(fd, IPPROTO_IPV6, IPV6_DSTOPTS,  &on, sizeof(on));
304setsockopt(fd, IPPROTO_IPV6, IPV6_RTHDR,    &on, sizeof(on));
305.Ed
306.Pp
307When any of these options are enabled, the corresponding data is
308returned as control information by
309.Xr recvmsg 2 ,
310as one or more ancillary data objects.
311.Pp
312If
313.Dv IPV6_PKTINFO
314is enabled, the destination IPv6 address and the arriving interface index
315will be available via
316.Li struct in6_pktinfo
317on ancillary data stream.
318You can pick the structure by checking for an ancillary data item with
319.Li cmsg_level
320equals to
321.Dv IPPROTO_IPV6 ,
322and
323.Li cmsg_type
324equals to
325.Dv IPV6_PKTINFO .
326.Pp
327If
328.Dv IPV6_HOPLIMIT
329is enabled, hoplimit value on the packet will be made available to the
330userland program.
331Ancillary data stream will contain an integer data item with
332.Li cmsg_level
333equals to
334.Dv IPPROTO_IPV6 ,
335and
336.Li cmsg_type
337equals to
338.Dv IPV6_HOPLIMIT .
339.Pp
340.Xr inet6_option_space 3
341and friends will help you parse ancillary data items for
342.Dv IPV6_HOPOPTS
343and
344.Dv IPV6_DSTOPTS .
345Similarly,
346.Xr inet6_rthdr_space 3
347and friends will help you parse ancillary data items for
348.Dv IPV6_RTHDR .
349.Pp
350.Dv IPV6_HOPOPTS
351and
352.Dv IPV6_DSTOPTS
353may appear multiple times on an ancillary data stream
354(note that the behavior is slightly different than the specification).
355Other ancillary data item will appear no more than once.
356.Pp
357For outgoing direction,
358you can pass ancillary data items with normal payload data, using
359.Xr sendmsg 2 .
360Ancillary data items will be parsed by the kernel, and used to construct
361the IPv6 header and extension headers.
362For the 5
363.Li cmsg_level
364values listed above, ancillary data format is the same as inbound case.
365Additionally, you can specify
366.Dv IPV6_NEXTHOP
367data object.
368The
369.Dv IPV6_NEXTHOP
370ancillary data object specifies the next hop for the
371datagram as a socket address structure.
372In the
373.Li cmsghdr
374structure
375containing this ancillary data, the
376.Li cmsg_level
377member will be
378.Dv IPPROTO_IPV6 ,
379the
380.Li cmsg_type
381member will be
382.Dv IPV6_NEXTHOP ,
383and the first byte of
384.Li cmsg_data[]
385will be the first byte of the socket address structure.
386.Pp
387If the socket address structure contains an IPv6 address (e.g., the
388sin6_family member is
389.Dv AF_INET6 ) ,
390then the node identified by that
391address must be a neighbor of the sending host.
392If that address
393equals the destination IPv6 address of the datagram, then this is
394equivalent to the existing
395.Dv SO_DONTROUTE
396socket option.
397.Pp
398For applications that do not, or unable to use
399.Xr sendmsg 2
400or
401.Xr recvmsg 2 ,
402.Dv IPV6_PKTOPTIONS
403socket option is defined.
404Setting the socket option specifies any of the optional output fields:
405.Bd -literal -offset indent
406setsockopt(fd, IPPROTO_IPV6, IPV6_PKTOPTIONS, &buf, len);
407.Ed
408.Pp
409The fourth argument points to a buffer containing one or more
410ancillary data objects, and the fifth argument is the total length of
411all these objects.
412The application fills in this buffer exactly as
413if the buffer were being passed to
414.Xr sendmsg 2
415as control information.
416.Pp
417The options set by calling
418.Xr setsockopt 2
419for
420.Dv IPV6_PKTOPTIONS
421are
422called "sticky" options because once set they apply to all packets
423sent on that socket.
424The application can call
425.Xr setsockopt 2
426again to
427change all the sticky options, or it can call
428.Xr setsockopt 2
429with a
430length of 0 to remove all the sticky options for the socket.
431.Pp
432The corresponding receive option
433.Bd -literal -offset indent
434getsockopt(fd, IPPROTO_IPV6, IPV6_PKTOPTIONS, &buf, &len);
435.Ed
436.Pp
437returns a buffer with one or more ancillary data objects for all the
438optional receive information that the application has previously
439specified that it wants to receive.
440The fourth argument points to
441the buffer that is filled in by the call.
442The fifth argument is a
443pointer to a value-result integer: when the function is called the
444integer specifies the size of the buffer pointed to by the fourth
445argument, and on return this integer contains the actual number of
446bytes that were returned.
447The application processes this buffer
448exactly as if the buffer were returned by
449.Xr recvmsg 2
450as control information.
451.\"
452.Ss Advanced API and TCP sockets
453When using
454.Xr getsockopt 2
455with the
456.Dv IPV6_PKTOPTIONS
457option and a
458.Tn TCP
459socket, only the options from the most recently received segment are
460retained and returned to the caller, and only after the socket option
461has been set.
462.\" That is,
463.\" .Tn TCP
464.\" need not start saving a copy of the options until the application says
465.\" to do so.
466The application is not allowed to specify ancillary data in a call to
467.Xr sendmsg 2
468on a
469.Tn TCP
470socket, and none of the ancillary data that we
471described above is ever returned as control information by
472.Xr recvmsg 2
473on a
474.Tn TCP
475socket.
476.\"
477.Ss Conflict resolution
478In some cases, there are multiple APIs defined for manipulating
479a IPv6 header field.
480A good example is the outgoing interface for multicast datagrams:
481it can be manipulated by
482.Dv IPV6_MULTICAST_IF
483in basic API,
484.Dv IPV6_PKTINFO
485in advanced API, and
486.Li sin6_scope_id
487field of the socket address passed to
488.Xr sendto 2 .
489.Pp
490When conflicting options are given to the kernel,
491the kernel will get the value in the following preference:
492(1) options specified by using ancillary data,
493(2) options specified by a sticky option of the advanced API,
494(3) options specified by using the basic API, and lastly
495(4) options specified by a socket address.
496Note that the conflict resolution is undefined in the API specification
497and implementation dependent.
498.\"
499.Ss "Raw IPv6 Sockets"
500Raw
501.Tn IPv6
502sockets are connectionless, and are normally used with the
503.Xr sendto 2
504and
505.Xr recvfrom 2
506calls, though the
507.Xr connect 2
508call may also be used to fix the destination for future
509packets (in which case the
510.Xr read 2
511or
512.Xr recv 2
513and
514.Xr write 2
515or
516.Xr send 2
517system calls may be used).
518.Pp
519If
520.Fa proto
521is 0, the default protocol
522.Dv IPPROTO_RAW
523is used for outgoing packets, and only incoming packets destined
524for that protocol are received.
525If
526.Fa proto
527is non-zero, that protocol number will be used on outgoing packets
528and to filter incoming packets.
529.Pp
530Outgoing packets automatically have an
531.Tn IPv6
532header prepended to them (based on the destination address and the
533protocol number the socket is created with).
534Incoming packets are received without
535.Tn IPv6
536header nor extension headers.
537.Pp
538All data sent via raw sockets MUST be in network byte order and all
539data received via raw sockets will be in network byte order.
540This differs from the IPv4 raw sockets, which did not specify a byte
541ordering and typically used the host's byte order.
542.Pp
543Another difference from IPv4 raw sockets is that complete packets
544(that is, IPv6 packets with extension headers) cannot be read or
545written using the IPv6 raw sockets API.
546Instead, ancillary data
547objects are used to transfer the extension headers, as described above.
548Should an application need access to the
549complete IPv6 packet, some other technique, such as the datalink
550interfaces, such as
551.Xr bpf 4 ,
552must be used.
553.Pp
554All fields in the IPv6 header that an application might want to
555change (i.e., everything other than the version number) can be
556modified using ancillary data and/or socket options by the
557application for output.
558All fields in a received IPv6 header (other
559than the version number and Next Header fields) and all extension
560headers are also made available to the application as ancillary data
561on input.
562Hence there is no need for a socket option similar to the
563IPv4
564.Dv IP_HDRINCL
565socket option.
566.Pp
567When writing to a raw socket the kernel will automatically fragment
568the packet if its size exceeds the path MTU, inserting the required
569fragmentation headers.  On input the kernel reassembles received
570fragments, so the reader of a raw socket never sees any fragment
571headers.
572.Pp
573Most IPv4 implementations give special treatment to a raw socket
574created with a third argument to
575.Xr socket 2
576of
577.Dv IPPROTO_RAW ,
578whose value is normally 255.
579We note that this value has no special meaning to
580an IPv6 raw socket (and the IANA currently reserves the value of 255
581when used as a next-header field).
582.\" Note: This feature was added to
583.\" IPv4 in 1988 by Van Jacobson to support traceroute, allowing a
584.\" complete IP header to be passed by the application, before the
585.\" .Dv IP_HDRINCL
586.\" socket option was added.
587.Pp
588For ICMPv6 raw sockets,
589the kernel will calculate and insert the ICMPv6 checksum for
590since this checksum is mandatory.
591.Pp
592For other raw IPv6 sockets (that is, for raw IPv6 sockets created
593with a third argument other than IPPROTO_ICMPV6), the application
594must set the new IPV6_CHECKSUM socket option to have the kernel (1)
595compute and store a pseudo header checksum for output,
596and (2) verify the received
597pseudo header checksum on input,
598discarding the packet if the checksum is in error.
599This option prevents applications from having to perform source
600address selection on the packets they send.
601The checksum will
602incorporate the IPv6 pseudo-header, defined in Section 8.1 of RFC2460.
603This new socket option also specifies an integer offset into
604the user data of where the checksum is located.
605.Bd -literal -offset indent
606int offset = 2;
607setsockopt(fd, IPPROTO_IPV6, IPV6_CHECKSUM, &offset, sizeof(offset));
608.Ed
609.Pp
610By default, this socket option is disabled.  Setting the offset to -1
611also disables the option.  By disabled we mean (1) the kernel will
612not calculate and store a checksum for outgoing packets, and (2) the
613kernel will not verify a checksum for received packets.
614.Pp
615Note: Since the checksum is always calculated by the kernel for an
616ICMPv6 socket, applications are not able to generate ICMPv6 packets
617with incorrect checksums (presumably for testing purposes) using this
618API.
619.\"
620.Sh ERRORS
621A socket operation may fail with one of the following errors returned:
622.Bl -tag -width Er
623.It Bq Er EISCONN
624when trying to establish a connection on a socket which already
625has one, or when trying to send a datagram with the destination
626address specified and the socket is already connected;
627.It Bq Er ENOTCONN
628when trying to send a datagram, but no destination address is
629specified, and the socket hasn't been connected;
630.It Bq Er ENOBUFS
631when the system runs out of memory for an internal data structure;
632.It Bq Er EADDRNOTAVAIL
633when an attempt is made to create a socket with a network address
634for which no network interface exists.
635.It Bq Er EACCES
636when an attempt is made to create a raw IPv6 socket by a non-privileged process.
637.El
638.Pp
639The following errors specific to
640.Tn IPv6
641may occur:
642.Bl -tag -width EADDRNOTAVAILxx
643.It Bq Er EINVAL
644An unknown socket option name was given.
645.It Bq Er EINVAL
646The ancillary data items were improperly formed, or option name was unknown.
647.El
648.\"
649.Sh SEE ALSO
650.Xr getsockopt 2 ,
651.Xr recv 2 ,
652.Xr send 2 ,
653.Xr setsockopt 2 ,
654.Xr inet6_option_space 3 ,
655.Xr inet6_rthdr_space 3 ,
656.Xr icmp6 4 ,
657.Xr inet6 4 ,
658.Xr intro 4
659.Rs
660.%A W. Stevens
661.%A M. Thomas
662.%R RFC
663.%N 2292
664.%D February 1998
665.%T "Advanced Sockets API for IPv6"
666.Re
667.Rs
668.%A S. Deering
669.%A R. Hinden
670.%R RFC
671.%N 2460
672.%D December 1998
673.%T "Internet Protocol, Version 6 (IPv6) Specification"
674.Re
675.Rs
676.%A R. Gilligan
677.%A S. Thomson
678.%A J. Bound
679.%A W. Stevens
680.%R RFC
681.%N 2553
682.%D March 1999
683.%T "Basic Socket Interface Extensions for IPv6"
684.Re
685.\"
686.Sh STANDARDS
687Most of the socket options are defined in
688RFC2292 and/or RFC2553.
689.Pp
690.Dv IPV6_V6ONLY
691socket option is defined in draft-ietf-ipngwg-rfc2553bis-03.
692.Dv IPV6_PORTRANGE
693socket option
694and
695conflict resolution rule
696are not defined in the RFCs and should be considered implementation dependent.
697.\"
698.Sh HISTORY
699The implementation is based on KAME stack
700(which is descendant of WIDE hydrangea IPv6 stack kit).
701.Pp
702Part of the document was shamelessly copied from RFC2553 and RFC2292.
703.\"
704.Sh BUGS
705The
706.Dv IPV6_NEXTHOP
707object/option is not fully implemented as of writing this.
708