diff options
Diffstat (limited to 'static/netbsd/man4/inet6.4')
| -rw-r--r-- | static/netbsd/man4/inet6.4 | 408 |
1 files changed, 408 insertions, 0 deletions
diff --git a/static/netbsd/man4/inet6.4 b/static/netbsd/man4/inet6.4 new file mode 100644 index 00000000..83644728 --- /dev/null +++ b/static/netbsd/man4/inet6.4 @@ -0,0 +1,408 @@ +.\" $NetBSD: inet6.4,v 1.33 2012/03/13 19:25:40 njoly Exp $ +.\" $KAME: inet6.4,v 1.18 2000/11/24 08:50:32 itojun Exp $ +.\" +.\" Copyright (C) 1995, 1996, 1997, and 1998 WIDE Project. +.\" All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" 3. Neither the name of the project nor the names of its contributors +.\" may be used to endorse or promote products derived from this software +.\" without specific prior written permission. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE PROJECT AND CONTRIBUTORS ``AS IS'' AND +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE PROJECT OR CONTRIBUTORS BE LIABLE +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\" SUCH DAMAGE. +.\" +.Dd March 10, 2010 +.Dt INET6 4 +.Os +.Sh NAME +.Nm inet6 +.Nd Internet protocol version 6 family +.Sh SYNOPSIS +.In sys/types.h +.In netinet/in.h +.Sh DESCRIPTION +The +.Nm +family is an updated version of +.Xr inet 4 +family. +While +.Xr inet 4 +implements Internet Protocol version 4, +.Nm +implements Internet Protocol version 6. +.Pp +.Nm +is a collection of protocols layered atop the +.Em Internet Protocol version 6 +.Pq Tn IPv6 +transport layer, and using the IPv6 address format. +The +.Nm +family provides protocol support for the +.Dv SOCK_STREAM , SOCK_DGRAM , +and +.Dv SOCK_RAW +socket types; the +.Dv SOCK_RAW +interface provides access to the +.Tn IPv6 +protocol. +.Sh ADDRESSING +IPv6 addresses are 16 byte quantities, stored in network standard byteorder. +The include file +.In netinet/in.h +defines this address +as a discriminated union. +.Pp +Sockets bound to the +.Nm +family use the following addressing structure: +.Bd -literal -offset indent +struct sockaddr_in6 { + uint8_t sin6_len; + sa_family_t sin6_family; + in_port_t sin6_port; + uint32_t sin6_flowinfo; + struct in6_addr sin6_addr; + uint32_t sin6_scope_id; +}; +.Ed +.Pp +Sockets may be created with the local address +.Dq Dv :: +.Po +which is equal to IPv6 address +.Dv 0:0:0:0:0:0:0:0 +.Pc +to effect +.Dq wildcard +matching on incoming messages. +.Pp +The IPv6 specification defines scoped addresses, +like link-local or site-local addresses. +A scoped address is ambiguous to the kernel, +if it is specified without a scope identifier. +To manipulate scoped addresses properly from the userland, +programs must use the advanced API defined in RFC 2292. +A compact description of the advanced API is available in +.Xr ip6 4 . +If a scoped address is specified without an explicit scope, +the kernel may raise an error. +Note that scoped addresses are not for daily use at this moment, +both from a specification and an implementation point of view. +.Pp +The KAME implementation supports an extended numeric IPv6 address notation +for link-local addresses, +like +.Dq Li fe80::1%de0 +to specify +.Do +.Li fe80::1 +on +.Li de0 +interface +.Dc . +This notation is supported by +.Xr getaddrinfo 3 +and +.Xr getnameinfo 3 . +Some of normal userland programs, such as +.Xr telnet 1 +or +.Xr ftp 1 , +are able to use this notation. +With special programs +like +.Xr ping6 8 , +you can specify the outgoing interface by an extra command line option +to disambiguate scoped addresses. +.Pp +Scoped addresses are handled specially in the kernel. +In kernel structures like routing tables or interface structures, +a scoped address will have its interface index embedded into the address. +Therefore, +the address in some kernel structures is not the same as that on the wire. +The embedded index will become visible through a +.Dv PF_ROUTE +socket, kernel memory accesses via +.Xr kvm 3 +and on some other occasions. +HOWEVER, users should never use the embedded form. +For details please consult +.Lk http://www.kame.net/dev/cvsweb2.cgi/kame/IMPLEMENTATION . +Note that the above URL describes the situation with the latest KAME tree, +not the +.Nx +tree. +.Sh PROTOCOLS +The +.Nm +family comprises the +.Tn IPv6 +network protocol, Internet Control +Message Protocol version 6 +.Pq Tn ICMPv6 , +Transmission Control Protocol +.Pq Tn TCP , +and User Datagram Protocol +.Pq Tn UDP . +.Tn TCP +is used to support the +.Dv SOCK_STREAM +abstraction while +.Tn UDP +is used to support the +.Dv SOCK_DGRAM +abstraction. +Note that +.Tn TCP +and +.Tn UDP +are common to +.Xr inet 4 +and +.Nm inet6 . +A raw interface to +.Tn IPv6 +is available +by creating an Internet socket of type +.Dv SOCK_RAW . +The +.Tn ICMPv6 +message protocol is accessible from a raw socket. +.\" .Pp +.\" The 128-bit IPv6 address contains both network and host parts. +.\" However, direct examination of addresses is discouraged. +.\" For those programs which absolutely need to break addresses +.\" into their component parts, the following +.\" .Xr ioctl 2 +.\" commands are provided for a datagram socket in the +.\" .Nm +.\" domain; they have the same form as the +.\" .Dv SIOCIFADDR +.\" command (see +.\" .Xr intro 4 ) . +.\" .Pp +.\" .Bl -tag -width SIOCSIFNETMASK +.\" .It Dv SIOCSIFNETMASK +.\" Set interface network mask. +.\" The network mask defines the network part of the address; +.\" if it contains more of the address than the address type would indicate, +.\" then subnets are in use. +.\" .It Dv SIOCGIFNETMASK +.\" Get interface network mask. +.\" .El +.\" .Sh ROUTING +.\" The current implementation of Internet protocols includes some routing-table +.\" adaptations to provide enhanced caching of certain end-to-end +.\" information necessary for Transaction TCP and Path MTU Discovery. The +.\" following changes are the most significant: +.\" .Bl -enum +.\" .It +.\" All IP routes, except those with the +.\" .Dv RTF_CLONING +.\" flag and those to multicast destinations, have the +.\" .Dv RTF_PRCLONING +.\" flag forcibly enabled (they are thus said to be +.\" .Dq "protocol cloning" ). +.\" .It +.\" When the last reference to an IP route is dropped, the route is +.\" examined to determine if it was created by cloning such a route. If +.\" this is the case, the +.\" .Dv RTF_PROTO3 +.\" flag is turned on, and the expiration timer is initialized to go off +.\" in net.inet.ip.rtexpire seconds. If such a route is re-referenced, +.\" the flag and expiration timer are reset. +.\" .It +.\" A kernel timeout runs once every ten minutes, or sooner if there are +.\" soon-to-expire routes in the kernel routing table, and deletes the +.\" expired routes. +.\" .El +.\" .Pp +.\" A dynamic process is in place to modify the value of +.\" net.inet.ip.rtexpire if the number of cached routes grows too large. +.\" If after an expiration run there are still more than +.\" net.inet.ip.rtmaxcache unreferenced routes remaining, the rtexpire +.\" value is multiplied by 3/4, and any routes which have longer +.\" expiration times have those times adjusted. This process is damped +.\" somewhat by specification of a minimum rtexpire value +.\" (net.inet.ip.rtminexpire), and by restricting the reduction to once in +.\" a ten-minute period. +.\" .Pp +.\" If some external process deletes the original route from which a +.\" protocol-cloned route was generated, the ``child route'' is deleted. +.\" (This is actually a generic mechanism in the routing code support for +.\" protocol-requested cloning.) +.\" .Pp +.\" No attempt is made to manage routes which were not created by protocol +.\" cloning; these are assumed to be static, under the management of an +.\" external routing process, or under the management of a link layer +.\" (e.g., +.\" .Tn ARP +.\" for Ethernets). +.\" .Pp +.\" Only certain types of network activity will result in the cloning of a +.\" route using this mechanism. Specifically, those protocols (such as +.\" .Tn TCP +.\" and +.\" .Tn UDP ) +.\" which themselves cache a long-lasting reference to route for a destination +.\" will trigger the mechanism; whereas raw +.\" .Tn IP +.\" packets, whether locally-generated or forwarded, will not. +.Ss Interaction between IPv4/v6 sockets +By default, +.Nx +does not route IPv4 traffic to +.Dv AF_INET6 +sockets. +The default behavior intentionally violates RFC 2553 for security reasons. +Listen to two sockets if you want to accept both IPv4 and IPv6 traffic. +IPv4 traffic may be routed with certain +per-socket/per-node configuration, however, it is not recommended to do so. +Consult +.Xr ip6 4 +for details. +.Pp +The behavior of +.Dv AF_INET6 +TCP/UDP socket is documented in RFC 2553. +Basically, it says this: +.Bl -bullet -compact +.It +A specific bind on an +.Dv AF_INET6 +socket +.Po +.Xr bind 2 +with an address specified +.Pc +should accept IPv6 traffic to that address only. +.It +If you perform a wildcard bind +on an +.Dv AF_INET6 +socket +.Po +.Xr bind 2 +to IPv6 address +.Li :: +.Pc , +and there is no wildcard bind +.Dv AF_INET +socket on that TCP/UDP port, IPv6 traffic as well as IPv4 traffic +should be routed to that +.Dv AF_INET6 +socket. +IPv4 traffic should be seen as if it came from an IPv6 address like +.Li ::ffff:10.1.1.1 . +This is called an IPv4 mapped address. +.It +If there are both a wildcard bind +.Dv AF_INET +socket and a wildcard bind +.Dv AF_INET6 +socket on one TCP/UDP port, they should behave separately. +IPv4 traffic should be routed to the +.Dv AF_INET +socket and IPv6 should be routed to the +.Dv AF_INET6 +socket. +.El +.Pp +However, RFC 2553 does not define the ordering constraint between calls to +.Xr bind 2 , +nor how IPv4 TCP/UDP port numbers and IPv6 TCP/UDP port numbers +relate to each other +.Po +should they be integrated or separated +.Pc . +Implemented behavior is very different from kernel to kernel. +Therefore, it is unwise to rely too much upon the behavior of +.Dv AF_INET6 +wildcard bind sockets. +It is recommended to listen to two sockets, one for +.Dv AF_INET +and another for +.Dv AF_INET6 , +when you would like to accept both IPv4 and IPv6 traffic. +.Pp +It should also be noted that +malicious parties can take advantage of the complexity presented above, +and are able to bypass access control, +if the target node routes IPv4 traffic to +.Dv AF_INET6 +socket. +Users are advised to take care handling connections +from IPv4 mapped address to +.Dv AF_INET6 +sockets. +.Sh SEE ALSO +.Xr ioctl 2 , +.Xr socket 2 , +.Xr sysctl 3 , +.Xr icmp6 4 , +.Xr intro 4 , +.Xr ip6 4 , +.Xr tcp 4 , +.Xr udp 4 +.Rs +.%A Qing \&Li +.%A Tatuya Jinmei +.%A Keiichi Shima +.%B "IPv6 Core Protocols Implementation" +.%D 2006 +.%I Morgan Kaufmann +.Re +.Rs +.%A Qing \&Li +.%A Tatuya Jinmei +.%A Keiichi Shima +.%B "IPv6 Advanced Protocols Implementation" +.%D 2007 +.%I Morgan Kaufmann +.Re +.Sh STANDARDS +.Rs +.%A Tatuya Jinmei +.%A Atsushi Onoe +.%T "An Extension of Format for IPv6 Scoped Addresses" +.%R internet draft +.%D June 2000 +.%N draft-ietf-ipngwg-scopedaddr-format-02.txt +.%O work in progress material +.Re +.Sh HISTORY +The +.Nm +protocol interfaces are defined in RFC 2553 and RFC 2292. +The implementation described herein appeared in the WIDE/KAME project. +.Sh BUGS +The IPv6 support is subject to change as the Internet protocols develop. +Users should not depend on details of the current implementation, +but rather the services exported. +.Pp +Users are suggested to implement +.Dq version independent +code as much as possible, as you will need to support both +.Xr inet 4 +and +.Nm inet6 . |