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