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