409 lines
12 KiB
Groff
409 lines
12 KiB
Groff
.\" $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 .
|