diff options
Diffstat (limited to 'usr/src/man/man7p')
| -rw-r--r-- | usr/src/man/man7p/Makefile | 86 | ||||
| -rw-r--r-- | usr/src/man/man7p/arp.7p | 421 | ||||
| -rw-r--r-- | usr/src/man/man7p/dlpi.7p | 407 | ||||
| -rw-r--r-- | usr/src/man/man7p/icmp.7p | 108 | ||||
| -rw-r--r-- | usr/src/man/man7p/icmp6.7p | 159 | ||||
| -rw-r--r-- | usr/src/man/man7p/if_tcp.7p | 872 | ||||
| -rw-r--r-- | usr/src/man/man7p/inet.7p | 170 | ||||
| -rw-r--r-- | usr/src/man/man7p/inet6.7p | 404 | ||||
| -rw-r--r-- | usr/src/man/man7p/ip.7p | 934 | ||||
| -rw-r--r-- | usr/src/man/man7p/ip6.7p | 779 | ||||
| -rw-r--r-- | usr/src/man/man7p/ipsec.7p | 361 | ||||
| -rw-r--r-- | usr/src/man/man7p/ipsecah.7p | 72 | ||||
| -rw-r--r-- | usr/src/man/man7p/ipsecesp.7p | 81 | ||||
| -rw-r--r-- | usr/src/man/man7p/ndp.7p | 355 | ||||
| -rw-r--r-- | usr/src/man/man7p/pf_key.7p | 946 | ||||
| -rw-r--r-- | usr/src/man/man7p/rarp.7p | 56 | ||||
| -rw-r--r-- | usr/src/man/man7p/route.7p | 330 | ||||
| -rw-r--r-- | usr/src/man/man7p/routing.7p | 163 | ||||
| -rw-r--r-- | usr/src/man/man7p/sctp.7p | 412 | ||||
| -rw-r--r-- | usr/src/man/man7p/sip.7p | 27 | ||||
| -rw-r--r-- | usr/src/man/man7p/slp.7p | 127 | ||||
| -rw-r--r-- | usr/src/man/man7p/tcp.7p | 898 | ||||
| -rw-r--r-- | usr/src/man/man7p/udp.7p | 248 | ||||
| -rw-r--r-- | usr/src/man/man7p/vxlan.7p | 137 |
24 files changed, 0 insertions, 8553 deletions
diff --git a/usr/src/man/man7p/Makefile b/usr/src/man/man7p/Makefile deleted file mode 100644 index 9186b1ac20..0000000000 --- a/usr/src/man/man7p/Makefile +++ /dev/null @@ -1,86 +0,0 @@ -# -# This file and its contents are supplied under the terms of the -# Common Development and Distribution License ("CDDL"), version 1.0. -# You may only use this file in accordance with the terms of version -# 1.0 of the CDDL. -# -# A full copy of the text of the CDDL should have accompanied this -# source. A copy of the CDDL is also available via the Internet -# at http://www.illumos.org/license/CDDL. -# - -# -# Copyright 2011, Richard Lowe -# Copyright 2013 Nexenta Systems, Inc. All rights reserved. -# - -include $(SRC)/Makefile.master - -MANSECT= 7p - -MANFILES= arp.7p \ - dlpi.7p \ - icmp.7p \ - icmp6.7p \ - if_tcp.7p \ - inet.7p \ - inet6.7p \ - ip.7p \ - ip6.7p \ - ipsec.7p \ - ipsecah.7p \ - ipsecesp.7p \ - ndp.7p \ - pf_key.7p \ - rarp.7p \ - route.7p \ - routing.7p \ - sctp.7p \ - sip.7p \ - slp.7p \ - tcp.7p \ - udp.7p \ - vxlan.7p - -MANLINKS= AH.7p \ - ARP.7p \ - ESP.7p \ - ICMP.7p \ - IP.7p \ - NDP.7p \ - RARP.7p \ - SCTP.7p \ - TCP.7p \ - UDP.7p \ - VXLAN.7p \ - if.7p - -ARP.7p := LINKSRC = arp.7p - -ICMP.7p := LINKSRC = icmp.7p - -if.7p := LINKSRC = if_tcp.7p - -IP.7p := LINKSRC = ip.7p - -AH.7p := LINKSRC = ipsecah.7p - -ESP.7p := LINKSRC = ipsecesp.7p - -NDP.7p := LINKSRC = ndp.7p - -RARP.7p := LINKSRC = rarp.7p - -SCTP.7p := LINKSRC = sctp.7p - -TCP.7p := LINKSRC = tcp.7p - -UDP.7p := LINKSRC = udp.7p - -VXLAN.7p := LINKSRC = vxlan.7p - -.KEEP_STATE: - -include $(SRC)/man/Makefile.man - -install: $(ROOTMANFILES) $(ROOTMANLINKS) diff --git a/usr/src/man/man7p/arp.7p b/usr/src/man/man7p/arp.7p deleted file mode 100644 index d7055fcb0a..0000000000 --- a/usr/src/man/man7p/arp.7p +++ /dev/null @@ -1,421 +0,0 @@ -'\" te -.\" Copyright (c) 2009, Sun Microsystems, Inc. All Rights Reserved. -.\" Copyright 2008 AT&T -.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License. -.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License. -.\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner] -.TH ARP 7P "Sep 02, 2015" -.SH NAME -arp, ARP \- Address Resolution Protocol -.SH SYNOPSIS -.LP -.nf -\fB#include <sys/fcntl.h>\fR -\fB#include <sys/socket.h>\fR -\fB#include <net/if_arp.h>\fR -\fB#include <netinet/in.h>\fR -.fi -.LP -.nf -\fBs = socket(PF_INET, SOCK_DGRAM, 0);\fR -.fi -.LP -.nf -\fBd = open ("/dev/arp", \fIoflag\fR);\fR -.fi -.SH DESCRIPTION -.LP -ARP is a protocol used to map dynamically between Internet Protocol (IP) and -Ethernet addresses. It is used by all Ethernet datalink providers (network -drivers) and can be used by other datalink providers that support broadcast, -including FDDI and Token Ring. The only network layer supported in this -implementation is the Internet Protocol, although ARP is not specific to that -protocol. -.sp -.LP -\fBARP\fR caches \fBIP-to-link-layer\fR address mappings. When an interface -requests a mapping for an address not in the cache, \fBARP\fR queues the -message that requires the mapping and broadcasts a message on the associated -network requesting the address mapping. If a response is provided, \fBARP\fR -caches the new mapping and transmits any pending message. \fBARP\fR will queue -a maximum of four packets while awaiting a response to a mapping request. ARP -keeps only the first four transmitted packets. -.SH APPLICATION PROGRAMMING INTERFACE -.LP -The STREAMS device \fB/dev/arp\fR is not a Transport Level Interface -(\fBTLI\fR) transport provider and may not be used with the \fBTLI\fR -interface. -.sp -.LP -To facilitate communications with systems that do not use ARP, ioctl() -requests are provided to enter and delete entries in the IP-to-link -address tables. Ioctls that change the table contents require the -\fBPRIV_SYS_NET_CONFIG\fR privilege. See \fBprivileges\fR(5). -.sp -.in +2 -.nf -#include <sys/sockio.h> -#include <sys/socket.h> -#include <net/if.h> -#include <net/if_arp.h> -struct arpreq arpreq; -ioctl(s, SIOCSARP, (caddr_t)&arpreq); -ioctl(s, SIOCGARP, (caddr_t)&arpreq); -ioctl(s, SIOCDARP, (caddr_t)&arpreq); -.fi -.in -2 - -.sp -.LP -\fBSIOCSARP\fR, \fBSIOCGARP\fR and \fBSIOCDARP\fR are BSD compatible ioctls. -These ioctls do not communicate the mac address length between the user and the -kernel (and thus only work for 6 byte wide Ethernet addresses). To manage the -ARP cache for media that has different sized mac addresses, use -\fBSIOCSXARP\fR, \fBSIOCGXARP\fR and \fBSIOCDXARP\fR ioctls. -.sp -.in +2 -.nf -#include <sys/sockio.h> -#include <sys/socket.h> -#include <net/if.h> -#include <net/if_dl.h> -#include <net/if_arp.h> -struct xarpreq xarpreq; -ioctl(s, SIOCSXARP, (caddr_t)&xarpreq); -ioctl(s, SIOCGXARP, (caddr_t)&xarpreq); -ioctl(s, SIOCDXARP, (caddr_t)&xarpreq); -.fi -.in -2 - -.sp -.LP -Each \fBioctl()\fR request takes the same structure as an argument. -\fBSIOCS[X]ARP\fR sets an \fBARP\fR entry, \fBSIOCG[X]ARP\fR gets an \fBARP\fR -entry, and \fBSIOCD[X]ARP\fR deletes an \fBARP\fR entry. These \fBioctl()\fR -requests may be applied to any Internet family socket descriptor\fIs\fR, or to -a descriptor for the \fBARP\fR device. Note that \fBSIOCS[X]ARP\fR and -\fBSIOCD[X]ARP\fR require the user to have the \fBPRIV_SYS_NET_CONFIG\fR -privilege, while \fBSIOCG[X]ARP\fR does not. -.sp -.LP -The \fBarpreq\fR structure contains -.sp -.in +2 -.nf -/* -* ARP ioctl request -*/ -struct arpreq { - struct sockaddr arp_pa; /* protocol address */ - struct sockaddr arp_ha; /* hardware address */ - int arp_flags; /* flags */ -}; -.fi -.in -2 - -.sp -.LP -The \fBxarpreq\fR structure contains: -.sp -.in +2 -.nf -/* -* Extended ARP ioctl request -*/ -struct xarpreq { - struct sockaddr_storage xarp_pa; /* protocol address */ - struct sockaddr_dl xarp_ha; /* hardware address */ - int xarp_flags; /* arp_flags field values */ -}; -#define ATF_COM 0x2 /* completed entry (arp_ha valid) */ -#define ATF_PERM 0x4 /* permanent (non-aging) entry */ -#define ATF_PUBL 0x8 /* publish (respond for other host) */ -#define ATF_USETRAILERS 0x10 /* send trailer pckts to host */ -#define ATF_AUTHORITY 0x20 /* hardware address is authoritative */ -.fi -.in -2 - -.sp -.LP -The address family for the [x]arp_pa sockaddr must be \fBAF_INET\fR. The -\fBATF_COM\fR flag bits ([x]arp_flags) cannot be altered. \fBATF_USETRAILERS\fR -is not implemented by the operating system and is retained for -compatibility only. \fBATF_PERM\fR makes the entry permanent (disables aging) -if the \fBioctl()\fR request succeeds. \fBATF_PUBL\fR specifies that the system -should respond to ARP requests for the indicated protocol address coming from -other machines. This allows a host to act as an ARP server, which may be useful -in convincing an ARP-only machine to talk to a non-ARP machine. -\fBATF_AUTHORITY\fR indicates that this machine owns the address. ARP does not -update the entry based on received packets. -.sp -.LP -The address family for the arp_ha sockaddr must be \fBAF_UNSPEC\fR. -.sp -.LP -Before invoking any of the \fBSIOC*XARP\fR ioctls, user code must fill in the -\fBxarp_pa\fR field with the protocol (IP) address information, similar to the -BSD variant. The \fBSIOC*XARP\fR ioctls come in two (legal) varieties, -depending on \fBxarp_ha.sdl_nlen\fR: -.RS +4 -.TP -1. -if \fBsdl_nlen\fR = 0, it behaves as an extended BSD ioctl. The kernel uses -the IP address to determine the network interface. -.RE -.RS +4 -.TP -2. -if (\fBsdl_nlen\fR > 0) and (\fBsdl_nlen\fR < \fBLIFNAMSIZ\fR), the kernel -uses the interface name in sdl_data[0] to determine the network interface; -\fBsdl_nlen\fR represents the length of the string (excluding terminating null -character). -.RE -.RS +4 -.TP -3. -if (\fBsdl_nlen\fR >= \fBLIFNAMSIZ\fR), an error (\fBEINVAL\fR) is flagged -from the ioctl. -.RE -.sp -.LP -Other than the above, the \fBxarp_ha\fR structure should be 0-filled except for -\fBSIOCSXARP\fR, where the \fBsdl_alen\fR field must be set to the size of -hardware address length and the hardware address itself must be placed in the -\fB\fR\fBLLADDR/sdl_data[]\fR area. (\fBEINVAL\fR will be returned if user -specified \fBsdl_alen\fR does not match the address length of the identified -interface). -.sp -.LP -On return from the kernel on a \fBSIOCGXARP\fR ioctl, the kernel fills in the -name of the interface (excluding terminating NULL) and its hardware address, -one after another, in the \fBsdl_data/LLADDR\fR area; if the two are larger -than can be held in the 244 byte \fBsdl_data[\fR] area, an \fBEINVAL\fR error -is returned. Assuming it fits, the kernel will also set \fBsdl_alen\fR with the -length of the hardware address, \fBsdl_nlen\fR with the length of the name of the -interface (excluding terminating NULL), \fBsdl_type\fR with an IFT_* value to -indicate the type of the media, \fBsdl_slen\fR with 0, \fBsdl_family\fR with -\fBAF_LINK\fR and \fBsdl_index\fR (which if not 0) with system given index for -the interface. The information returned is very similar to that returned via -routing sockets on an \fBRTM_IFINFO\fR message. -.sp -.LP -The ARP ioctls have several additional restrictions and enhancements when -used in conjunction with IPMP: -.RS +4 -.TP -.ie t \(bu -.el o -ARP mappings for IPMP data and test addresses are managed by the kernel and -cannot be changed through ARP ioctls, though they may be retrieved using -\fBSIOCGARP\fR or \fBSIOCGXARP\fR. -.RE -.RS +4 -.TP -.ie t \(bu -.el o -ARP mappings for a given IPMP group must be consistent across the group. As a -result, ARP mappings cannot be associated with individual underlying IP -interfaces in an IPMP group and must instead be associated with the -corresponding IPMP IP interface. -.RE -.RS +4 -.TP -.ie t \(bu -.el o -Proxy ARP mappings for an IPMP group are automatically managed by the kernel. -Specifically, if the hardware address in a \fBSIOCSARP\fR or \fBSIOCSXARP\fR -request matches the hardware address of an IP interface in an IPMP group and -the IP address is not local to the system, the kernel regards this as a IPMP -Proxy ARP entry. This IPMP Proxy ARP entry will have its hardware address -automatically adjusted in order to keep the IP address reachable (provided -the IPMP group has not entirely failed). -.RE -.sp -.LP -\fBARP\fR performs duplicate address detection for local addresses. When a -logical interface is brought up (\fBIFF_UP\fR) or any time the hardware link -goes up (\fBIFF_RUNNING\fR), ARP sends probes (ar$spa == 0) for the assigned -address. If a conflict is found, the interface is torn down. See -\fBifconfig\fR(1M) for more details. -.sp -.LP -\fBARP\fR watches for hosts impersonating the local host, that is, any host -that responds to an ARP request for the local host's address, and any address -for which the local host is an authority. ARP defends local addresses and logs -those with \fBATF_AUTHORITY\fR set, and can tear down local addresses on an -excess of conflicts. -.sp -.LP -ARP also handles UNARP messages received from other nodes. It does not -generate these messages. -.SH PACKET EVENTS -.LP -The \fBarp\fR driver registers itself with the netinfo interface. To gain -access to these events, a handle from net_protocol_lookup must be acquired by -passing it the value \fBNHF_ARP\fR. Through this interface, two packet events -are supported: -.sp -.LP -Physical in - ARP packets received via a network interface -.sp -.LP -Physical out - ARP packets to be sent out via a network interface -.sp -.LP -For ARP packets, the hook_pkt_event structure is filled out as follows: -.sp -.ne 2 -.na -\fBhpe_ifp\fR -.ad -.sp .6 -.RS 4n -Identifier indicating the inbound interface for packets received with the -\fBphysical in\fR event. -.RE - -.sp -.ne 2 -.na -\fBhpe_ofp\fR -.ad -.sp .6 -.RS 4n -Identifier indicating the outbound interface for packets received with the -\fBphysical out\fR event. -.RE - -.sp -.ne 2 -.na -\fBhpe_hdr\fR -.ad -.sp .6 -.RS 4n -Pointer to the start of the ARP header (not the Ethernet header). -.RE - -.sp -.ne 2 -.na -\fBhpe_mp\fR -.ad -.sp .6 -.RS 4n -Pointer to the start of the mblk_t chain containing the ARP packet. -.RE - -.sp -.ne 2 -.na -\fBhpe_mb\fR -.ad -.sp .6 -.RS 4n -Pointer to the mblk_t with the ARP header in it. -.RE - -.SH NETWORK INTERFACE EVENTS -.LP -In addition to events describing packets as they move through the system, it -is also possible to receive notification of events relating to network -interfaces. These events are all reported back through the same callback. The -list of events is as follows: -.sp -.ne 2 -.na -\fBplumb\fR -.ad -.sp .6 -.RS 4n -A new network interface has been instantiated. -.RE - -.sp -.ne 2 -.na -\fBunplumb\fR -.ad -.sp .6 -.RS 4n -A network interface is no longer associated with ARP. -.RE - -.SH SEE ALSO -.LP -\fBarp\fR(1M), \fBifconfig\fR(1M), \fBsockaddr\fR(3SOCKET), \fBprivileges\fR(5), -\fBif_tcp\fR(7P), \fBinet\fR(7P), \fBnetinfo\fR(9F) -.sp -.LP -Plummer, Dave, \fIAn Ethernet Address Resolution Protocol\fR or \fIConverting -Network Protocol Addresses to 48 .bit Ethernet Addresses for Transmission on -Ethernet Hardware\fR, RFC 826, STD 0037, November 1982. -.sp -.LP -Malkin, Gary, \fIARP Extension - UNARP, RFC 1868\fR, November, 1995 -.SH DIAGNOSTICS -.LP -Several messages can be written to the system logs (by the IP module) when -errors occur. In the following examples, the hardware address strings include -colon (:) separated ASCII representations of the link layer addresses, whose -lengths depend on the underlying media (for example, 6 bytes for Ethernet). -.sp -.ne 2 -.na -\fBNode %x:%x ... %x:%x is using our IP address %d.%d.%d.%d on %s.\fR -.ad -.sp .6 -.RS 4n -Duplicate IP address warning. ARP has discovered another host on a local -network that responds to mapping requests for the Internet address of this -system, and has defended the system against this node by re-announcing the ARP -entry. -.RE - -.sp -.ne 2 -.na -\fB%s has duplicate address %d.%d.%d.%d (in use by %x:%x ... %x:%x); -disabled.\fR -.ad -.sp .6 -.RS 4n -Duplicate IP address detected while performing initial probing. The -newly-configured interface has been shut down. -.RE - -.sp -.ne 2 -.na -\fB%s has duplicate address %d.%d.%d.%d (claimed by %x:%x ... %x:%x); -disabled.\fR -.ad -.sp .6 -.RS 4n -Duplicate IP address detected on a running IP interface. The conflict cannot be -resolved, and the interface has been disabled to protect the network. -.RE - -.sp -.ne 2 -.na -\fBRecovered address %d.%d.%d.%d on %s.\fR -.ad -.sp .6 -.RS 4n -An interface with a previously-conflicting IP address has been recovered -automatically and reenabled. The conflict has been resolved. -.RE - -.sp -.ne 2 -.na -\fBProxy ARP problem? Node '%x:%x ... %x:%x' is using %d.%d.%d.%d on %s\fR -.ad -.sp .6 -.RS 4n -This message appears if \fBarp\fR(1M) has been used to create a published -permanent (\fBATF_AUTHORITY\fR) entry, and some other host on the local network -responds to mapping requests for the published ARP entry. -.RE - diff --git a/usr/src/man/man7p/dlpi.7p b/usr/src/man/man7p/dlpi.7p deleted file mode 100644 index c2ffdc6889..0000000000 --- a/usr/src/man/man7p/dlpi.7p +++ /dev/null @@ -1,407 +0,0 @@ -'\" te -.\" Copyright (c) 2009, Sun Microsystems, Inc. -.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License. You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. -.\" See the License for the specific language governing permissions and limitations under the License. When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the -.\" fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner] -.TH DLPI 7P "April 9, 2016" -.SH NAME -dlpi \- Data Link Provider Interface -.SH SYNOPSIS -.LP -.nf -\fB#include <sys/dlpi.h>\fR -.fi - -.SH DESCRIPTION -.LP -SunOS STREAMS-based device drivers wishing to support the STREAMS \fB TCP/IP\fR -and other STREAMS-based networking protocol suite implementations support -Version 2 of the Data Link Provider Interface (\fBDLPI\fR). \fBDLPI V2\fR -enables a data link service user to access and use any of a variety of -conforming data link service providers without special knowledge of the -provider's protocol. Specifically, the interface is intended to support -Ethernet, \fBX.25 LAPB,\fR \fBSDLC,\fR \fBISDN LAPD,\fR \fBCSMA/CD,\fR -\fBFDDI,\fR token ring, token bus, Bisync, and other datalink-level protocols. -.sp -.LP -The interface specifies access to the data link service provider in the form of -\fBM_PROTO\fR and \fBM_PCPROTO\fR type STREAMS messages and does not define a -specific protocol implementation. The interface defines the syntax and -semantics of primitives exchanged between the data link user and the data link -provider to attach a physical device with physical-level address to a stream, -bind a datalink-level address to the stream, get implementation-specific -information from the data link provider, exchange data with a peer data link -user in one of three communication modes (connection, connectionless, -acknowledged connectionless), enable/disable multicast group and promiscuous -mode reception of datalink frames, get and set the physical address associated -with a stream, and several other operations. -.sp -.LP -Solaris conforms to The Open Group Technical Standard for \fIDLPI, Version -2\fR. For free access to this specification, point your browser to -\fIwww.opengroup.org/pubs/catalog/c811.htm\fR. Solaris also provides extensions -to the DLPI standard, as detailed in this man page. -.SH SOLARIS-SPECIFIC DLPI EXTENSIONS -.ne 2 -.na -\fBNotification Support\fR -.ad -.sp .6 -.RS 4n -Enables \fBDLPI\fR consumers to register for notification when events of -interest occur at the \fBDLPI\fR provider. The negotiation can be performed on -any attached DLPI stream, and begins with the \fBDLPI\fR consumer, sending a -DL_NOTIFY_REQ to the provider, which is an M_PROTO message with the following -payload: -.sp -.in +2 -.nf - typedef struct { - t_uscalar_t dl_primitive; - uint32_t dl_notifications; - uint32_t dl_timelimit; - } dl_notify_req_t; -.fi -.in -2 - -The dl_primitive field must be set to DL_NOTIFY_REQ; the dl_timelimit field is -reserved for future use and must be set to zero. The dl_notifications field is -a bitmask containing the event types the consumer is interested in receiving, -and must be zero or more of: -.sp -.in +2 -.nf -DL_NOTE_LINK_DOWN Notify when link has gone down -DL_NOTE_LINK_UP Notify when link has come up -DL_NOTE_PHYS_ADDR Notify when address changes -DL_NOTE_SDU_SIZE Notify when MTU changes -DL_NOTE_SPEED Notify when speed changes -DL_NOTE_PROMISC_ON_PHYS Notify when DL_PROMISC_PHYS is set -DL_NOTE_PROMISC_OFF_PHYS Notify when DL_PROMISC_PHYS is cleared -.fi -.in -2 - -Consumers might find it useful to send a DL_NOTIFY_REQ message with no -requested types to check if the \fBDLPI\fR provider supports the extension. -.sp -Upon receiving the DL_NOTIFY_REQ, the \fBDLPI\fR provider must generate a -DL_NOTIFY_ACK, which is an M_PROTO message with the following payload: -.sp -.in +2 -.nf - typedef struct { - t_uscalar_t dl_primitive; - uint32_t dl_notifications; - } dl_notify_ack_t; -.fi -.in -2 - -The \fBdl_primitive\fR field must be set to DL_NOTIFY_ACK. The -\fBdl_notifications\fR field must include any notifications that the provider -supports, along with any other unrequested notifications that the provider -supports. However, regardless of the notifications the provider supports, it is -restricted to sending only DL_NOTIFY_IND messages (see below) that were -requested in the DL_NOTIFY_REQ. -.sp -Since there are additional notification types which are not yet available for -public use, \fBDLPI\fR consumers and providers must take care when inspecting -and setting the \fBdl_notifications\fR field. Specifically, consumers must be -careful to only request the above notification types, and providers must be -careful to not include any unrecognized notification types in the -\fBdl_notifications\fR field when constructing the DL_NOTIFY_ACK. In addition, -DL_NOTIFY_IND's that are received with undocumented dl_notification or dl_data -values must be ignored. -.sp -DLPI consumers might receive a DL_ERROR_ACK message (with dl_error_primitive -set to DL_NOTIFY_REQ) in response to the initial DL_NOTIFY_REQ message. This -message indicates that the DLPI provider does not support the DLPI notification -extension. Otherwise, the DLPI consumer receives a DL_NOTIFY_ACK and should -expect to receive DL_NOTIFY_IND messages for any types that it requested that -were still set in it. The DL_NOTIFY_IND is an M_PROTO message with the -following payload: -.sp -.in +2 -.nf - typedef struct { - t_uscalar_t dl_primitive; - uint32_t dl_notification; - uint32_t dl_data; - t_uscalar_t dl_addr_length; - t_uscalar_t dl_addr_offset; - } dl_notify_ind_t; -.fi -.in -2 - -The \fBdl_primitive\fR field must be set to DL_NOTIFY_IND, and the -\fBdl_notification\fR field must be set to the event type that has occurred -(for example, DL_NOTE_LINK_DOWN). Only a single event type can be set in each -DL_NOTIFY_IND. -.sp -For the DL_NOTE_SPEED event type, \fBdl_data\fR must be set to the current -interface speed in kilobits per second. For the DL_NOTE_PHYS_ADDR event type, -dl_data must be set to DL_CURR_PHYS_ADDR. For the DL_NOTE_SDU_SIZE event type, -\fBdl_data\fR must be set to the current MTU in bytes. Otherwise, \fBdl_data\fR -must be set to zero. -.sp -For the DL_NOTE_PHYS_ADDR event type, the \fBdl_addr_length\fR field must be -set to the length of the address, and the \fBdl_addr_offset\fR field must be -set to offset of the first byte of the address, relative to b_rptr (for -example, if the address immediately follows the \fBdl_notify_ind\fR structure, -\fBdl_addr_offset\fR is set to 'sizeof (\fBdl_notify_ind\fR)'). For all other -event types, the \fBdl_addr_length\fR and \fBdl_addr_offset\fR fields must be -set to zero by DLPI providers and ignored by DLPI consumers. -.sp -In addition to generating DL_NOTIFY_IND messages when a requested event has -occurred, the \fBDLPI\fR provider must initially generate one or more -DL_NOTIFY_IND messages to notify the \fBDLPI\fR consumer of the current -state of the interface. For instance, if the consumer has requested -DL_NOTE_LINK_UP | DL_NOTE_LINK_DOWN, the provider must send a DL_NOTIFY_IND -containing the current state of the link (either DL_NOTE_LINK_UP or -DL_NOTE_LINK_DOWN) after sending the DL_NOTIFY_ACK. -.sp -For the initial DL_NOTIFY_IND message, the DLPI provider is strongly -recommended against sending DL_NOTE_LINK_DOWN, even if the interface is still -initializing and is not yet ready to send or receive packets. Instead, either -delaying the DL_NOTIFY_IND message until the interface is ready or -optimistically reporting DL_NOTIFY_LINK_UP and subsequently reporting -DL_NOTE_LINK_DOWN if the negotiation fails is strongly preferred. This -prevents DL_NOTIFY_IND consumers from needlessly triggering network failover -operations and logging error messages during network interface initialization. -.sp -The DLPI provider must continue to generate DL_NOTIFY_IND messages until it -receives a new DL_NOTIFY_REQ message or the \fBDLPI\fR stream is detached (or -closed). Further, a DLPI style 2 provider must keep track of the requested -events after a DL_DETACH_REQ operation, and if a subsequent DL_ATTACH_REQ is -received, it must send gratuitous DL_NOTIFY_IND messages to notify the -consumer of the current state of the device, since the state might have -changed while detached (or the consumer might have simply discarded its -previous state). -.RE - -.sp -.ne 2 -.na -\fBPassive Consumers of Aggregated Links\fR -.ad -.sp .6 -.RS 4n -Solaris link aggregations as configured by \fBdladm\fR(1M) export DLPI nodes -for both the link aggregation, and individual links that comprises the -aggregation, to allow observability of the aggregated links. To allow -applications such as \fBsnoop\fR(1M) to open those individual aggregated links -while disallowing other consumers such as \fBip\fR(7P), DL_PASSIVE_REQ (a DLPI -primitive), must be issued by \fBsnoop\fR(1M) and similar applications. -.sp -The DL_PASSIVE_REQ primitive is an M_PROTO message containing the following -payload: -.sp -.in +2 -.nf -typedef struct { - t_uscalar_t dl_primitive; -} dl_passive_req_t; -.fi -.in -2 - -Issuing this primitive allows the consumer of a DLPI link to coexist with a -link aggregation that also uses the link. Such a consumer is considered -\fBpassive\fR. -.sp -Consumers that don't use this primitive while an aggregation is using the link -receive DL_SYSERR/EBUSY when issuing the following DLPI primitives: -.sp -.in +2 -.nf -DL_BIND_REQ -DL_ENABMULTI_REQ -DL_PROMISCON_REQ -DL_AGGR_REQ -DL_UNAGGR_REQ -DL_CONTROL_REQ -DL_SET_PHYS_ADDR_REQ -.fi -.in -2 - -A consumer that has not issued a DL_PASSIVE_REQ and has successfully issued one -of the above primitives is considered \fBactive\fR. -.sp -The creation of a link aggregation using \fBdladm\fR(1M) fails if one of the -links included in the aggregation has an \fBactive\fR consumer, but succeeds if -the links do not have any DLPI consumers or only \fBpassive\fR consumers. -.RE - -.sp -.ne 2 -.na -\fBRaw Mode\fR -.ad -.sp .6 -.RS 4n -The \fBDLIOCRAW\fR ioctl function is used by some DLPI applications, most -notably the \fBsnoop\fR(1M) command. The \fBDLIOCRAW\fR command puts the stream -into a raw mode, which, upon receive, causes the full MAC-level packet to -be sent upstream in an \fBM_DATA\fR message instead of it being transformed -into the \fBDL_UNITDATA_IND\fR form normally used for reporting incoming -packets. Packet \fBSAP\fR filtering is still performed on streams that are in -raw mode. If a stream user wants to receive all incoming packets it must also -select the appropriate promiscuous modes. After successfully selecting raw -mode, the application is also allowed to send fully formatted packets to the -provider as \fBM_DATA\fR messages for transmission. \fBDLIOCRAW\fR takes no -arguments. Once enabled, the stream remains in this mode until closed. -.RE - -.sp -.ne 2 -.na -\fBNative Mode\fR -.ad -.sp .6 -.RS 4n -Some DLPI providers are able to represent their link layer using more than one -link-layer format. In this case, the default link-layer format can minimize -impact to applications, but might not allow truly \fBnative\fR link-layer -headers to be sent or received. DLPI consumers who wish to use the native -link-layer format can use DLIOCNATIVE to transition the stream. DLIOCNATIVE -takes no arguments and returns the DLPI mac type associated with the new -link-layer format upon success. Once enabled, the stream remains in -this mode until closed. Note that DLIOCNATIVE does not enable transition -between dissimilar DLPI mac types and (aside from the link-layer format), the -new DLPI mac type is guaranteed to be semantically identical. In particular, -the SAP space and addressing format are not affected and the effect of -DLIOCNATIVE is only visible when in raw mode, though any subsequent DL_INFO_REQ -requests generate responses with dl_mac_type set to the native DLPI type. -.RE - -.sp -.ne 2 -.na -\fBMargin\fR -.ad -.sp .6 -.RS 4n -While a DLPI provider provides its maximum SDU via dl_max_sdu in DL_INFO_ACK -messages, this value typically represents a standard maximum SDU for the -provider's media (1500 for Ethernet for example), and not necessarily the -absolute maximum amount of data that the provider is able to transmit in a -given data unit. The \fBmargin\fR "is the extra amount of data in bytes that -the provider can transmit beyond its advertised maximum SDU. For example, if a -DL_ETHER provider can handle packets whose payload section is no greater than -1522 bytes and its dl_max_sdu is set to 1500 (as is typical for Ethernet), then -the margin would be 22. If a provider supports a non-zero margin, it implements -the DLIOCMARGININFO ioctl, whose data is a t_uscalar_t representing the margin -size. -.RE - -.SH DL_ETHER-SPECIFIC DLPI SEMANTICS -.SS "VLAN Support" -.SS "Traditional VLAN Access" -.LP -Some \fBDL_ETHER DLPI\fR providers support \fIIEEE 802.1Q\fR Virtual LANs -(VLAN). For these providers, traffic for a particular VLAN can be accessed by -opening a VLAN data-link. -.sp -.LP -Unless raw mode is enabled, a DLPI stream bound to a VLAN data-link behaves -no differently than a traditional DLPI stream. As with non-VLAN data-link -access, data must be sent to a DLPI provider without link-layer headers (which -are added by the provider) and received data is passed to interested DLPI -consumers without link-layer headers. As a result, DLPI consumers not require -special-case logic to implement VLAN access. -.SS "SAP-Based VLAN Access" -.LP -As per \fIIEEE 802.1Q\fR, all VLAN traffic is sent using Ether- Type 0x8100, -meaning that in addition to directly opening a VLAN data-link, all VLAN -traffic for a given underline data-link can also be accessed by opening the -underlying data-link and binding to SAP 0x8100. Accordingly, all VLAN traffic -(regardless of VLAN ID) can be sent and received by the DLPI consumer. -However, even when raw mode is disabled, packets are received starting with -their VLAN headers and must be sent to the DLPI provider with their VLAN -headers already pre-pended (but without Ethernet headers). Because adhering to -these semantics requires each DLPI consumer to have specialized knowledge of -VLANs, VLANs should only be accessed in this way when the traditional VLAN -access method is insufficient (for example, because access to all VLAN -traffic, regardless of VLAN ID, is needed). -.sp -.LP -Because all VLAN traffic is sent with SAP 0x8100, VLAN traffic not filtered at -the physical (\fBDL_PROMISC_PHYS\fR) level is also visible if a DLPI consumer -enables promiscuous mode of a stream at the \fBDL_PROMISC_SAP\fR level. As -mentioned earlier, these packets are received starting with their VLAN headers -if raw mode is not enabled. -.SS "QoS Support" -.LP -The \fIIEEE 802.1Q\fR standard defines eight classes of priority values used by -QoS traffic control of Ethernet packets. Although the priority values are -encoded in the\fI 802.1Q\fR tags, they can be used independently from VLANs. -In particular, a special priority tagged packet (with VLAN ID zero but -priority bits non-zero) does not belong to any VLAN. -.sp -.LP -The priority value can be set on either a per-stream or per-packet basis. DLPI -consumers can specify the per-stream priority using the \fBDL_UDQOS_REQ\fR -request (the priority value remains unchanged until the next DL_UDQOS_REQ) and -also specify the per-packet priority value using the b_band field of a M_DATA -message or the \fBdl_priority\fR field of a \fBDL_UNITDATA_REQ\fR. -.SS "Raw Mode" -.SS "SAP-Based VLAN Access" -.LP -When raw mode is enabled, the complete, unmodified MAC- level packet (including -Ethernet and VLAN headers) is passed to interested DLPI consumers. Similarly, -the entire MAC-level packet (including Ethernet and VLAN headers) must be sent -to the DLPI provider for transmission. Note that the priority value specified -in the b_band field can be overridden by encoding the priority value (if any) -into the VLAN header. -.SS "Traditional VLAN Access" -.LP -When raw mode is enabled, only packets with the correct VLAN ID are passed up -to interested DLPI consumers. With the exception of priority-tagged packets, -DLPI providers must strip off the VLAN headers (while retaining the preceding -Ethernet headers) before sending up the packets. For priority-tagged packets, -DLPI providers must use the reserved tag 0 to encode the VLAN TCI and send up -the packets. -.sp -.LP -On the transmit-side, DLPI consumers must send the packets down to the DLPI -providers without the VLAN headers (but with the Ethernet headers) unless -certain QoS support is required. If QoS support is needed, the packet can have -the VLAN header to indicate the priority value, however its VLAN ID must be -zero. The DLPI providers then insert the VLAN tags or encode the VLAN tags -using the priority value specified in the VLAN headers and send the packets. -.SH FILES -.LP -Files in or under \fB/dev\fR. -.SH ATTRIBUTES -.LP -See \fBattributes\fR(5) for descriptions of the following attributes: -.sp - -.sp -.TS -box; -c | c -l | l . -ATTRIBUTE TYPE ATTRIBUTE VALUE -_ -T{ -Interface Stability (Notification support/Passive mode behavior) -T} Committed -.TE - -.SH SEE ALSO -.LP -\fBdladm\fR(1M), \fBsnoop\fR(1M), \fBlibdlpi\fR(3LIB), \fBgld\fR(7D), -\fBip\fR(7P) -.SH NOTES -.LP -A Solaris DLPI link name consists of a \fBDLPI provider name\fR followed by a -numeric \fBPPA\fR (physical point of attachment). -.sp -.LP -The DLPI provider name must be between 1 and 16 characters in length, though -names between 3 and 8 characters are preferred. The DLPI provider name can -consist of any alphanumeric character (a-z, A-Z, 0-9), and the underscore (_). -The first and last character of the DLPI provider name cannot be a digit. -.sp -.LP -The PPA must be a number between \fB0\fR and \fB4294967294\fR inclusive. -Leading zeroes are not permitted. diff --git a/usr/src/man/man7p/icmp.7p b/usr/src/man/man7p/icmp.7p deleted file mode 100644 index 21a9fc164b..0000000000 --- a/usr/src/man/man7p/icmp.7p +++ /dev/null @@ -1,108 +0,0 @@ -'\" te -.\" Copyright 1989 AT&T -.\" Copyright (C) 1999, Sun Microsystems, Inc. -.\" All Rights Reserved -.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License. -.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License. -.\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner] -.TH ICMP 7P "Dec 03, 2015" -.SH NAME -icmp, ICMP \- Internet Control Message Protocol -.SH SYNOPSIS -.LP -.nf -#include <sys/socket.h> -#include <netinet/in.h> -#include <netinet/ip_icmp.h> -s = socket(AF_INET, SOCK_RAW, proto); -t = t_open("/dev/icmp", O_RDWR); -.fi - -.SH DESCRIPTION -.LP -\fBICMP\fR is the error and control message protocol used by the Internet -protocol family. It is used by the kernel to handle and report errors in -protocol processing. It may also be accessed by programs using the socket -interface or the Transport Level Interface (\fBTLI\fR) for network monitoring -and diagnostic functions. When used with the socket interface, a "raw socket" -type is used. The protocol number for \fBICMP,\fR used in the \fIproto\fR -parameter to the socket call, can be obtained from -\fBgetprotobyname\fR(3SOCKET). \fBICMP\fR file descriptors and sockets are -connectionless, and are normally used with the \fBt_sndudata\fR / -\fBt_rcvudata\fR and the \fBsendto()\fR / \fBrecvfrom()\fR calls. In order to -send \fBICMP\fR packets, a process needs the \fBPRIV_NET_ICMPACCESS\fR -privilege. (See \fBprivileges\fR(5) for more information on privileges.) -.sp -.LP -Outgoing packets automatically have an Internet Protocol (\fBIP\fR) header -prepended to them. Incoming packets are provided to the user with the \fBIP\fR -header and options intact. -.sp -.LP -\fBICMP\fR is an datagram protocol layered above \fBIP.\fR It is used -internally by the protocol code for various purposes including routing, fault -isolation, and congestion control. Receipt of an \fBICMP\fR "redirect" message -will add a new entry in the routing table, or modify an existing one. -\fBICMP\fR messages are routinely sent by the protocol code. Received -\fBICMP\fR messages may be reflected back to users of higher-level protocols -such as \fBTCP\fR or \fBUDP\fR as error returns from system calls. A copy of -all \fBICMP\fR message received by the system is provided to every holder of an -open \fBICMP\fR socket or \fBTLI\fR descriptor. -.SH SEE ALSO -.LP -\fBgetprotobyname\fR(3SOCKET), \fBrecv\fR(3SOCKET), \fBsend\fR(3SOCKET), -\fBt_rcvudata\fR(3NSL), \fBt_sndudata\fR(3NSL), \fBprivileges\fR(5), -\fBinet\fR(7P), \fBip\fR(7P), \fBrouting\fR(7P) -.sp -.LP -Postel, Jon, \fIInternet Control Message Protocol \(em DARPA Internet Program -Protocol Specification\fR, \fBRFC\fR 792, Network Information Center, \fBSRI\fR -International, Menlo Park, Calif., September 1981. -.SH DIAGNOSTICS -.LP -A socket operation may fail with one of the following errors returned: -.sp -.ne 2 -.na -\fB\fBEISCONN\fR\fR -.ad -.RS 17n -An attempt was made to establish a connection on a socket which already has -one, or when trying to send a datagram with the destination address specified -and the socket is already connected. -.RE - -.sp -.ne 2 -.na -\fB\fBENOTCONN\fR\fR -.ad -.RS 17n -An attempt was made to send a datagram, but no destination address is -specified, and the socket has not been connected. -.RE - -.sp -.ne 2 -.na -\fB\fBENOBUFS\fR\fR -.ad -.RS 17n -The system ran out of memory for an internal data structure. -.RE - -.sp -.ne 2 -.na -\fB\fBEADDRNOTAVAIL\fR\fR -.ad -.RS 17n -An attempt was made to create a socket with a network address for which no -network interface exists. -.RE - -.SH NOTES -.LP -Replies to \fBICMP\fR "echo" messages which are source routed are not sent back -using inverted source routes, but rather go back through the normal routing -mechanisms. diff --git a/usr/src/man/man7p/icmp6.7p b/usr/src/man/man7p/icmp6.7p deleted file mode 100644 index d00493040d..0000000000 --- a/usr/src/man/man7p/icmp6.7p +++ /dev/null @@ -1,159 +0,0 @@ -'\" te -.\" Copyright (C) 1999, Sun Microsystems, -.\" Inc. All Rights Reserved -.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License. -.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License. -.\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner] -.TH ICMP6 7P "Dec 03, 2015" -.SH NAME -icmp6 \- Internet Control Message Protocol for Internet Protocol Version 6 -.SH SYNOPSIS -.LP -.nf -#include <sys/socket.h> -#include <netinet/in.h> -#include <netinet/ip_icmp.h> -#include <netinet/icmp6.h> -.fi - -.LP -.nf -s = socket(AF_INET6, SOCK_RAW, proto); -.fi - -.LP -.nf -t = t_open("/dev/icmp6", O_RDWR); -.fi - -.SH DESCRIPTION -.LP -The \fBICMP6\fR protocol is the error and control message protocol used with -Version 6 of the Internet Protocol. It is used by the kernel to handle and -report errors in protocol processing. It is also used for \fBIPv6\fR neighbor -and router discovery, and for multicast group membership queries and reports. -It may also be accessed by programs using the socket interface or the Transport -Level Interface (\fBTLI\fR) for network monitoring and diagnostic functions. -When used with the socket interface, a "raw socket" type is used. The protocol -number for \fBICMP6\fR, used in the \fIproto\fR parameter to the socket call, -can be obtained from \fBgetprotobyname\fR(3SOCKET). \fBICMP6\fR file -descriptors and sockets are connectionless and are normally used with the -\fBt_sndudata\fR / \fBt_rcvudata\fR and the \fBsendto()\fR / \fBrecvfrom()\fR -calls. They may also be used with the \fBsendmsg()\fR/\fBrecvgmsg()\fR calls -when sending or receiving ancillary data. In order to send \fBICMP6\fR packets, -a process needs the \fBPRIV_NET_ICMPACCESS\fR privilege. (See -\fBprivileges\fR(5) for more information on privileges.) -.sp -.LP -Outgoing packets automatically have an Internet Protocol Version 6 (\fBIPv6\fR) -header and zero or more \fBIPv6\fR extension headers prepended. These headers -are prepended by the kernel. Unlike \fBICMP\fR for \fBIPv4\fR, the -\fBIP_HDRINCL\fR option is not supported for \fBICMP6\fR, so \fBICMP6\fR -applications neither build their own outbound \fBIPv6\fR headers, nor do they -receive the inbound \fBIPv6\fR headers with received data. \fBIPv6\fR extension -headers and relevant fields of the \fBIPv6\fR header may be set or received as -ancillary data to a \fBsendmsg\fR(3SOCKET) or \fBrecvmsg\fR(3SOCKET) system -call. Each of these fields and extension headers may also be set on a per -socket basis with the \fBsetsockopt\fR(3SOCKET) system call. Such "sticky" -options are used on all outgoing packets unless overridden by ancillary data. -When any ancillary data is present with a \fBsendmsg\fR(3SOCKET) system call, -all sticky options are ignored for that system call, but subsequently remain -configured. -.sp -.LP -\fBICMP6\fR is a datagram protocol layered above \fBIPv6\fR. Received -\fBICMP6\fR messages may be reflected back to users of higher-level protocols -such as \fBTCP\fR or \fBUDP\fR as error returns from system calls. A copy of -each \fBICMP6\fR error message received by the system is provided to every -holder of an open \fBICMP6\fR socket or \fBTLI\fR descriptor. -.SH SEE ALSO -.LP -\fBgetprotobyname\fR(3SOCKET), \fBrecv\fR(3SOCKET), \fBrecvmsg\fR(3SOCKET), -\fBsend\fR(3SOCKET), \fBsendmsg\fR(3SOCKET), \fBsetsockopt\fR(3SOCKET), -\fBt_rcvudata\fR(3NSL), \fBt_sndudata\fR(3NSL), \fBprivileges\fR(5), -\fBinet6\fR(7P), \fBip6\fR(7P), \fBrouting\fR(7P) -.sp -.LP -Conta, A. and Deering, S., \fIRFC 2463, Internet Control Message Protocol -(ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification\fR, The -Internet Society, December 1998. -.SH DIAGNOSTICS -.LP -A socket operation may fail with one of the following errors returned: -.sp -.ne 2 -.na -\fB\fBEISCONN\fR\fR -.ad -.RS 17n -An attempt was made to establish a connection on a socket which already has -one, or when trying to send a datagram with the destination address specified -and the socket is already connected. -.RE - -.sp -.ne 2 -.na -\fB\fBENOTCONN\fR\fR -.ad -.RS 17n -An attempt was made to send a datagram, but no destination address is -specified, and the socket has not been connected. -.RE - -.sp -.ne 2 -.na -\fB\fBENOBUFS\fR\fR -.ad -.RS 17n -The system ran out of memory for an internal data structure. -.RE - -.sp -.ne 2 -.na -\fB\fBEADDRNOTAVAIL\fR\fR -.ad -.RS 17n -An attempt was made to create a socket with a network address for which no -network interface exists. -.RE - -.sp -.ne 2 -.na -\fB\fBENOMEM\fR\fR -.ad -.RS 17n -The system was unable to allocate memory for an internal data structure. -.RE - -.sp -.ne 2 -.na -\fB\fBENOPROTOOPT\fR\fR -.ad -.RS 17n -An attempt was made to set an \fBIPv4\fR socket option on an \fBIPv6\fR socket. -.RE - -.sp -.ne 2 -.na -\fB\fBEINVAL\fR\fR -.ad -.RS 17n -An attempt was made to set an invalid or malformed socket option. -.RE - -.sp -.ne 2 -.na -\fB\fBEAFNOSUPPORT\fR\fR -.ad -.RS 17n -An attempt was made to bind or connect to an \fBIPv4\fR or mapped address, or -to specify an \fBIPv4\fR or mapped address as the next hop. -.RE - diff --git a/usr/src/man/man7p/if_tcp.7p b/usr/src/man/man7p/if_tcp.7p deleted file mode 100644 index acba34c8ae..0000000000 --- a/usr/src/man/man7p/if_tcp.7p +++ /dev/null @@ -1,872 +0,0 @@ -'\" te -.\" Copyright (C) 2009, Sun Microsystems, Inc. All Rights Reserved. -.\" Copyright 1989 AT&T -.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License. You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. -.\" See the License for the specific language governing permissions and limitations under the License. When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with -.\" the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner] -.TH IF_TCP 7P "Sep 02, 2015" -.SH NAME -if_tcp, if \- general properties of Internet Protocol network interfaces -.SH DESCRIPTION -.LP -A network interface is a device for sending and receiving packets on a network. -It is usually a hardware device, although it can be implemented in software. -Network interfaces used by the Internet Protocol (IPv4 or IPv6) must be STREAMS -devices conforming to the Data Link Provider Interface (\fBDLPI\fR). See -\fBdlpi\fR(7P). -.SH APPLICATION PROGRAMMING INTERFACE -.LP -An interface becomes available to \fBIP\fR when it is opened and the \fBIP\fR -module is pushed onto the stream with the \fBI_PUSH\fR \fBioctl\fR(2) command. -(See \fBstreamio\fR(7I)). The \fBSIOCSLIFNAME\fR \fBioctl\fR(2) is issued to -specify the name of the interface and to indicate whether it is IPv4 or IPv6. -This may be initiated by the kernel at boot time or by a user program after the -system is running. Each interface must be assigned an \fBIP\fR address with the -\fBSIOCSLIFADDR\fR \fBioctl()\fR before it can be used. On interfaces where the -network-to-link layer address mapping is static, only the network number is -taken from the \fBioctl()\fR request; the remainder is found in a hardware -specific manner. On interfaces which provide dynamic network-to-link layer -address mapping facilities (for example, Ethernets using \fBarp\fR(7P)), the -entire address specified in the \fBioctl()\fR is used. A routing table entry -for destinations on the network of the interface is installed automatically -when an interface's address is set. -.sp -.LP -You cannot create IPMP IP interfaces using the procedure described above. -Instead, use \fBifconfig\fR(1M). -.SH IOCTLS -.LP -The following \fBioctl()\fR calls may be used to manipulate \fBIP\fR network -interfaces. Unless specified otherwise, the request takes an \fBlifreq\fR -structure as its parameter. This structure has the form: -.sp -.in +2 -.nf -struct lifreq { -#define LIFNAMSIZ 32 - char lifr_name[LIFNAMSIZ]; /* if name, e.g. "le1" */ - union { - int lifru_addrlen; /* for subnet/token etc */ - uint_t lifru_ppa; /* SIOCSLIFNAME */ - } lifr_lifru1; - union { - struct sockaddr_storage lifru_addr; - struct sockaddr_storage lifru_dstaddr; - struct sockaddr_storage lifru_broadaddr; - struct sockaddr_storage lifru_token; /* With lifr_addrlen */ - struct sockaddr_storage lifru_subnet; /* With lifr_addrlen */ - int lifru_index; /* interface index */ - uint64_t lifru_flags; /* SIOC?LIFFLAGS */ - int lifru_metric; - uint_t lifru_mtu; - int lif_muxid[2]; /* mux id's for arp & ip */ - struct lif_nd_req lifru_nd_req; /* SIOCLIF*ND */ - struct lif_ifinfo_req lifru_ifinfo_req; - zoneid_t lifru_zone; /* SIOC[GS]LIFZONE */ - } lifr_lifru; - -#define lifr_addrlen lifr_lifru1.lifru_addrlen -#define lifr_ppa lifr_lifru1.lifru_ppa /* Driver's ppa */ -#define lifr_addr lifr_lifru.lifru_addr /* address */ -#define lifr_dstaddr lifr_lifru.lifru_dstaddr -#define lifr_broadaddr lifr_lifru.lifru_broadaddr /* broadcast addr. */ -#define lifr_token lifr_lifru.lifru_token /* address token */ -#define lifr_subnet lifr_lifru.lifru_subnet /* subnet prefix */ -#define lifr_index lifr_lifru.lifru_index /* interface index */ -#define lifr_flags lifr_lifru.lifru_flags /* flags */ -#define lifr_metric lifr_lifru.lifru_metric /* metric */ -#define lifr_mtu lifr_lifru.lifru_mtu /* mtu */ -#define lifr_ip_muxid lifr_lifru.lif_muxid[0] -#define lifr_arp_muxid lifr_lifru.lif_muxid[1] -#define lifr_nd lifr_lifru.lifru_nd_req /* SIOCLIF*ND */ -#define lifr_ifinfo lifr_lifru.lifru_ifinfo_req /* SIOC[GS]LIFLNKINFO */ -#define lifr_zone lifr_lifru.lifru_zone /* SIOC[GS]LIFZONE */ -}; -.fi -.in -2 - -.sp -.ne 2 -.na -\fB\fBSIOCSLIFADDR\fR\fR -.ad -.RS 19n -Set interface address. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCGLIFADDR\fR\fR -.ad -.RS 19n -Get interface address. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCSLIFDSTADDR\fR\fR -.ad -.RS 19n -Set point to point address for interface. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCGLIFDSTADDR\fR\fR -.ad -.RS 19n -Get point to point address for interface. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCSLIFFLAGS\fR\fR -.ad -.RS 19n -Set interface flags field. If the interface is marked down, any processes -currently routing packets through the interface are notified. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCGLIFFLAGS\fR\fR -.ad -.RS 19n -Get interface flags. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCGLIFCONF\fR\fR -.ad -.RS 19n -Get interface configuration list. This request takes a \fBlifconf\fR structure -(see below) as a value-result parameter. The \fBlifc_family\fR field can be -set to \fBAF_UNSPEC\fR to retrieve both \fBAF_INET\fR and \fBAF_INET6\fR -interfaces. The \fBlifc_len\fR field should be set to the size of the buffer -pointed to by \fBlifc_buf\fR. -.sp -The \fBlifc_flags\fR field should usually be set to zero, but callers that need -low-level knowledge of the underlying IP interfaces that comprise an IPMP -group can set it to \fBLIFC_UNDER_IPMP\fR to request that those interfaces be -included in the result. Upon success, \fBlifc_len\fR contains the length, in -bytes, of the array of \fBlifreq\fR structures pointed to by \fBlifc_req\fR. -For each \fBlifreq\fR structure, the \fBlifr_name\fR and \fBlifr_addr\fR fields -are valid. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCGLIFNUM\fR\fR -.ad -.RS 19n -Get number of interfaces. This request returns an integer which is the number -of interface descriptions (\fBstruct lifreq\fR) returned by the -\fBSIOCGLIFCONF\fR ioctl (in other words, indicates how large \fBlifc_len\fR -must be). -.sp -This request takes a \fBstruct lifnum\fR (see below) as a value-result -parameter. The \fBlifn_family\fR field can be set to \fBAF_UNSPEC\fR to count -both \fBAF_INET\fR and \fBAF_INET6\fR interfaces. The \fBlifn_flags\fR field -should usually be set to zero, but callers that need low-level knowledge of the -underlying IP interfaces that comprise an IPMP group can set it to -\fBLIFC_UNDER_IPMP\fR to request that those interfaces be included in the -count. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCSLIFMTU\fR\fR -.ad -.RS 19n -Set the maximum transmission unit (MTU) size for interface. Place the request -in the \fBlifru_mtu\fR field. The \fBMTU\fR can not exceed the physical -\fBMTU\fR limitation (which is reported in the \fBDLPI\fR \fBDL_INFO_ACK\fR -message). -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCGLIFMTU\fR\fR -.ad -.RS 19n -Get the maximum transmission unit size for interface. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCSLIFMETRIC\fR\fR -.ad -.RS 19n -Set the metric associated with the interface. The metric is used by routing -daemons such as \fBin.routed\fR(1M). -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCGLIFMETRIC\fR\fR -.ad -.RS 19n -Get the metric associated with the interface. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCGLIFMUXID\fR\fR -.ad -.RS 19n -Get the \fBip\fR and \fBarp\fR \fBmuxid\fR associated with the interface. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCSLIFMUXID\fR\fR -.ad -.RS 19n -Set the \fBip\fR and \fBarp\fR \fBmuxid\fR associated with the interface. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCGLIFINDEX\fR\fR -.ad -.RS 19n -Get the interface index associated with the interface. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCSLIFINDEX\fR\fR -.ad -.RS 19n -Set the interface index associated with the interface. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCGLIFZONE\fR\fR -.ad -.RS 19n -Get the zone associated with the interface. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCSLIFZONE\fR\fR -.ad -.RS 19n -Set the zone associated with the interface. Only applies for zones that use the -shared-IP instance. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCLIFADDIF\fR\fR -.ad -.RS 19n -Add a new logical interface on a physical interface using an unused logical -interface number. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCLIFREMOVEIF\fR\fR -.ad -.RS 19n -Remove a logical interface by specifying its \fBIP\fR address or logical -interface name. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCSLIFTOKEN\fR\fR -.ad -.RS 19n -Set the address token used to form IPv6 link-local addresses and for stateless -address autoconfiguration. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCGLIFTOKEN\fR\fR -.ad -.RS 19n -Get the address token used to form IPv6 link-local addresses and for stateless -address autoconfiguration. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCSLIFSUBNET\fR\fR -.ad -.RS 19n -Set the subnet prefix associated with the interface. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCGLIFSUBNET\fR\fR -.ad -.RS 19n -Get the subnet prefix associated with the interface. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCSLIFLNKINFO\fR\fR -.ad -.RS 19n -Set link specific parameters for the interface. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCGLIFLNKINFO\fR\fR -.ad -.RS 19n -Get link specific parameters for the interface. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCLIFDELND\fR\fR -.ad -.RS 19n -Delete a neighbor cache entry for IPv6. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCLIFGETND\fR\fR -.ad -.RS 19n -Get a neighbor cache entry for IPv6. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCLIFSETND\fR\fR -.ad -.RS 19n -Set a neighbor cache entry for IPv6. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCSLIFUSESRC\fR\fR -.ad -.RS 19n -Set the interface from which to choose a source address. The \fBlifr_index\fR -field has the interface index corresponding to the interface whose address is -to be used as the source address for packets going out on the interface whose -name is provided by \fBlifr_name\fR. If the \fBlifr_index\fR field is set to -zero, the previous setting is cleared. See \fBifconfig\fR(1M) for examples of -the \fBusesrc\fR option. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCGLIFUSESRC\fR\fR -.ad -.RS 19n -Get the interface index of the interface whose address is used as the source -address for packets going out on the interface provided by \fBlifr_name\fR -field. The value is retrieved in the \fBlifr_index\fR field. See -\fBifconfig\fR(1M) for examples of the \fBusesrc\fR option. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCGLIFSRCOF\fR\fR -.ad -.RS 19n -Get the interface configuration list for interfaces that use an address hosted -on the interface provided by the \fBlifs_ifindex\fR field in the \fBlifsrcof\fR -struct (see below), as a source address. The application sets \fBlifs_maxlen\fR -to the size (in bytes) of the buffer it has allocated for the data. On return, -the kernel sets \fBlifs_len\fR to the actual size required. Note, the -application could set \fBlifs_maxlen\fR to zero to query the kernel of the -required buffer size instead of estimating a buffer size. The application tests -\fBlifs_len\fR <= \fBlifs_maxlen\fR -- if that's true, the buffer was big -enough and the application has an accurate list. If it is false, it needs to -allocate a bigger buffer and try again, and \fBlifs_len\fR provides a hint of -how big to make the next trial. See \fBifconfig\fR(1M) for examples of the -\fBusesrc\fR option. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCTONLINK\fR\fR -.ad -.RS 19n -Test if the address is directly reachable, for example, that it can be reached -without going through a router. This request takes an \fBsioc_addrreq\fR -structure (see below) as a value-result parameter. The \fBsa_addr\fR field -should be set to the address to test. The \fBsa_res\fR field will contain a -non-zero value if the address is onlink. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCTMYADDR\fR\fR -.ad -.RS 19n -Test if the address is assigned to this node. This request takes an -\fBsioc_addrreq\fR structure (see below) as a value-result parameter. The -\fBsa_addr\fR field should be set to the address to test. The \fBsa_res\fR -field will contain a non-zero value if the address is assigned to this node. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCTMYSITE\fR\fR -.ad -.RS 19n -Test if the address is part of the same site as this node. This request takes -an \fBsioc_addrreq\fR structure (see below) as a value-result parameter. The -\fBsa_addr\fR field should be set to the address to test. The \fBsa_res\fR -field will contain a non-zero value if the address is in the same site. -.RE - -.sp -.LP -The structure used by \fBSIOCGLIFCONF\fR has the form: -.sp -.in +2 -.nf -struct lifconf { - sa_family_t lifc_family; - int lifc_flags; /* request specific - /* interfaces */ - int lifc_len; /* size of assoc. buffer */ - union { - caddr_t lifcu_buf; - struct lifreq *lifcu_req; - } lifc_lifcu; - -#define lifc_buf lifc_lifcu.lifcu_buf /* buffer address */ -#define lifc_req lifc_lifcu.lifcu_req /* array of structs returned */ -}; -.fi -.in -2 - -.sp -.LP -The structure used by \fBSIOCGLIFNUM\fR has the form: -.sp -.in +2 -.nf -struct lifnum { - sa_family_t lifn_family; - int lifn_flags; /* req. specf. interfaces */ - int lifn_count; /* Result */ -}; -.fi -.in -2 - -.sp -.LP -The structure used by \fBSIOCTONLINK\fR, \fBSIOCTMYADDR\fR and -\fBSIOCTMYSITE\fR has the form: -.sp -.in +2 -.nf -struct sioc_addrreq { - struct sockaddr_storage sa_addr; /* Address to test */ - int sa_res; /* Result - 0/1 */ -}; -.fi -.in -2 - -.sp -.LP -The structure used by \fBSIOCGLIFSRCOF\fR has the form: -.sp -.in +2 -.nf - struct lifsrcof { - uint_t lifs_ifindex; /* addr on this interface */ - /* used as the src addr */ - size_t lifs_maxlen; /* size of buffer: input */ - size_t lifs_len; /* size of buffer: output */ - union { - caddr_t lifsu_buf; - struct lifreq *lifsu_req; - } lifs_lifsu; -#define lifs_buf lifs_lifsu.lifsu_buf /* buffer addr. */ -#define lifs_req lifs_lifsu.lifsu_req /* array returned */ -}; -.fi -.in -2 - -.sp -.LP -The following \fBioctl()\fR calls are maintained for compatibility but only -apply to IPv4 network interfaces, since the data structures are too small to -hold an IPv6 address. Unless specified otherwise, the request takes an -\fBifreq\fR structure as its parameter. This structure has the form: -.sp -.in +2 -.nf -struct ifreq { -#define IFNAMSIZ 16 - char ifr_name[IFNAMSIZ]; /* interface name - e.g. "hme0" */ - union { - struct sockaddr ifru_addr; - struct sockaddr ifru_dstaddr; - struct sockaddr ifru_broadaddr; - short ifru_flags; - int ifru_metric; - int if_muxid[2]; /* mux id's for arp and ip */ - int ifru_index; /* interface index */ - } ifr_ifru; - -#define ifr_addr ifr_ifru.ifru_addr /* address */ -#define ifr_dstaddr ifr_ifru.ifru_dstaddr /* other end of p-to-p link */ -#define ifr_broadaddr ifr_ifru.ifru_broadaddr /* broadcast address */ -#define ifr_flags ifr_ifru.ifru_flags /* flags */ -#define ifr_index ifr_ifru.ifru_index /* interface index */ -#define ifr_metric ifr_ifru.ifru_metric /* metric */ -}; -.fi -.in -2 - -.sp -.ne 2 -.na -\fB\fBSIOCSIFADDR\fR\fR -.ad -.RS 18n -Set interface address. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCGIFADDR\fR\fR -.ad -.RS 18n -Get interface address. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCSIFDSTADDR\fR\fR -.ad -.RS 18n -Set point to point address for interface. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCGIFDSTADDR\fR\fR -.ad -.RS 18n -Get point to point address for interface. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCSIFFLAGS\fR\fR -.ad -.RS 18n -Set interface flags field. If the interface is marked down, any processes -currently routing packets through the interface are notified. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCGIFFLAGS\fR\fR -.ad -.RS 18n -Get interface flags. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCGIFCONF\fR\fR -.ad -.RS 18n -Get interface configuration list. This request takes an \fBifconf\fR structure -(see below) as a value-result parameter. The \fBifc_len\fR field should be set -to the size of the buffer pointed to by \fBifc_buf\fR. Upon success, -\fBifc_len\fR will contain the length, in bytes, of the array of \fBifreq\fR -structures pointed to by \fBifc_req\fR. For each \fBifreq\fR structure, the -\fBifr_name\fR and \fBifr_addr\fR fields are valid. Though IPMP IP interfaces -are included in the array, underlying IP interfaces that comprise those IPMP -groups are not. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCGIFNUM\fR\fR -.ad -.RS 18n -Get number of interfaces. This request returns an integer which is the number -of interface descriptions (\fBstruct ifreq\fR) returned by the -\fBSIOCGIFCONF\fR ioctl (in other words, indicates how large \fBifc_len\fR must -be). Though IPMP IP interfaces are included in the array, underlying IP -interfaces that comprise those IPMP groups are not. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCSIFMTU\fR\fR -.ad -.RS 18n -Set the maximum transmission unit (\fBMTU\fR) size for interface. Place the -request in the \fBifr_metric\fR field. The \fBMTU\fR has to be smaller than -physical \fBMTU\fR limitation (which is reported in the \fBDLPI\fR -\fBDL_INFO_ACK\fR message). -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCGIFMTU\fR\fR -.ad -.RS 18n -Get the maximum transmission unit size for interface. Upon success, the request -is placed in the \fBifr_metric\fR field. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCSIFMETRIC\fR\fR -.ad -.RS 18n -Set the metric associated with the interface. The metric is used by routine -daemons such as \fBin.routed\fR(1M). -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCGIFMETRIC\fR\fR -.ad -.RS 18n -Get the metric associated with the interface. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCGIFMUXID\fR\fR -.ad -.RS 18n -Get the \fBip\fR and \fBarp\fR \fBmuxid\fR associated with the interface. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCSIFMUXID\fR\fR -.ad -.RS 18n -Set the \fBip\fR and \fBarp\fR \fBmuxid\fR associated with the interface. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCGIFINDEX\fR\fR -.ad -.RS 18n -Get the interface index associated with the interface. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCSIFINDEX\fR\fR -.ad -.RS 18n -Set the interface index associated with the interface. -.RE - -.sp -.LP -The \fBifconf\fR structure has the form: -.sp -.in +2 -.nf -struct ifconf { - int ifc_len; /* size of assoc. buffer */ - union { - caddr_t ifcu_buf; - struct ifreq *ifcu_req; - } ifc_ifcu; - -#define ifc_buf ifc_ifcu.ifcu_buf /* buffer address */ -#define ifc_req ifc_ifcu.ifcu_req /* array of structs returned */ -}; -.fi -.in -2 - -.SS "IFF_ Flags" -.LP -You can use the \fBifconfig\fR(1M) command to display the \fBIFF\fR_ flags -listed below (with the leading \fBIFF\fR_ prefix removed). See the -\fBifconfig\fR(1M) manpage for a definition of each flag. -.sp -.in +2 -.nf -#define IFF_UP 0x0000000001 /* Address is up */ -#define IFF_BROADCAST 0x0000000002 /* Broadcast address valid */ -#define IFF_DEBUG 0x0000000004 /* Turn on debugging */ -#define IFF_LOOPBACK 0x0000000008 /* Loopback net */ - -#define IFF_POINTOPOINT 0x0000000010 /* Interface is p-to-p */ -#define IFF_NOTRAILERS 0x0000000020 /* Avoid use of trailers */ -#define IFF_RUNNING 0x0000000040 /* Resources allocated */ -#define IFF_NOARP 0x0000000080 /* No address res. protocol */ - -#define IFF_PROMISC 0x0000000100 /* Receive all packets */ -#define IFF_ALLMULTI 0x0000000200 /* Receive all multicast pkts */ -#define IFF_INTELLIGENT 0x0000000400 /* Protocol code on board */ -#define IFF_MULTICAST 0x0000000800 /* Supports multicast */ - -#define IFF_MULTI_BCAST 0x0000001000 /* Multicast using broadcst. add. */ -#define IFF_UNNUMBERED 0x0000002000 /* Non-unique address */ -#define IFF_DHCPRUNNING 0x0000004000 /* DHCP controls interface */ -#define IFF_PRIVATE 0x0000008000 /* Do not advertise */ - -#define IFF_NOXMIT 0x0000010000 /* Do not transmit pkts */ -#define IFF_NOLOCAL 0x0000020000 /* No address - just on-link subnet */ -#define IFF_DEPRECATED 0x0000040000 /* Address is deprecated */ -#define IFF_ADDRCONF 0x0000080000 /* Addr. from stateless addrconf */ - -#define IFF_ROUTER 0x0000100000 /* Router on interface */ -#define IFF_NONUD 0x0000200000 /* No NUD on interface */ -#define IFF_ANYCAST 0x0000400000 /* Anycast address */ -#define IFF_NORTEXCH 0x0000800000 /* Don't xchange rout. info */ - -#define IFF_IPV4 0x0001000000 /* IPv4 interface */ -#define IFF_IPV6 0x0002000000 /* IPv6 interface */ -#define IFF_NOFAILOVER 0x0008000000 /* in.mpathd test address */ -#define IFF_FAILED 0x0010000000 /* Interface has failed */ - -#define IFF_STANDBY 0x0020000000 /* Interface is a hot-spare */ -#define IFF_INACTIVE 0x0040000000 /* Functioning but not used */ -#define IFF_OFFLINE 0x0080000000 /* Interface is offline */ -#define IFF_XRESOLV 0x0100000000 /* IPv6 external resolver */ - -#define IFF_COS_ENABLED 0x0200000000 /* If CoS marking is supported */ -#define IFF_PREFERRED 0x0400000000 /* Prefer as source address */ -#define IFF_TEMPORARY 0x0800000000 /* RFC3041 */ -#define IFF_FIXEDMTU 0x1000000000 /* MTU set with SIOCSLIFMTU */ - -#define IFF_VIRTUAL 0x2000000000 /* Cannot send/receive pkts */ -#define IFF_DUPLICATE 0x4000000000 /* Local address in use */ -#define IFF_IPMP 0x8000000000 /* IPMP IP interface */ -.fi -.in -2 - -.SH ERRORS -.ne 2 -.na -\fB\fBEPERM\fR\fR -.ad -.RS 12n -Calling process has insufficient privileges. -.RE - -.sp -.ne 2 -.na -\fB\fBENXIO\fR\fR -.ad -.RS 12n -The \fBlifr_name\fR member of the \fBlifreq\fR structure contains an invalid -value. -.sp -For \fBSIOCGLIFSRCOF\fR, the \fBlifs_ifindex\fR member of the \fBlifsrcof\fR -structure contains an invalid value. -.sp -For \fBSIOCSLIFUSESRC\fR, this error is returned if the \fBlifr_index\fR is set -to an invalid value. -.RE - -.sp -.ne 2 -.na -\fB\fBEBADADDR\fR\fR -.ad -.RS 12n -Wrong address family or malformed address. -.RE - -.sp -.ne 2 -.na -\fB\fBEINVAL\fR\fR -.ad -.RS 12n -For \fBSIOCSLIFMTU\fR, this error is returned when the requested \fBMTU\fR size -is invalid. This error indicates the \fBMTU\fR size is greater than the -\fBMTU\fR size supported by the \fBDLPI\fR provider or less than \fB68\fR (for -IPv4) or less than \fB1280\fR (for IPv6). -.sp -For \fBSIOCSLIFUSESRC\fR, this error is returned if either the \fBlifr_index\fR -or \fBlifr_name\fR identify interfaces that are already part of an existing -IPMP group. -.RE - -.sp -.ne 2 -.na -\fB\fBEEXIST\fR\fR -.ad -.RS 12n -For \fBSIOCLIFADDIF\fR, this error is returned if the \fBlifr_name\fR member in -the \fBlifreq\fR structure corresponds to an interface that already has the PPA -specified by \fBlifr_ppa\fR plumbed. -.RE - -.SH SEE ALSO -.LP -\fBifconfig\fR(1M), \fBin.routed\fR(1M), \fBioctl\fR(2), -\fBsockaddr\fR(3SOCKET), \fBstreamio\fR(7I), \fBarp\fR(7P), \fBdlpi\fR(7P), -\fBip\fR(7P), \fBip6\fR(7P), \fBndp\fR(7P) diff --git a/usr/src/man/man7p/inet.7p b/usr/src/man/man7p/inet.7p deleted file mode 100644 index 541892768b..0000000000 --- a/usr/src/man/man7p/inet.7p +++ /dev/null @@ -1,170 +0,0 @@ -'\" te -.\" Copyright 1989 AT&T -.\" Copyright (C) 2000, Sun Microsystems, Inc. All Rights Reserved -.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License. -.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License. -.\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner] -.TH INET 7P "Aug 3, 2000" -.SH NAME -inet \- Internet protocol family -.SH SYNOPSIS -.LP -.nf -\fB#include <sys/types.h>\fR -.fi - -.LP -.nf -\fB#include <netinet/in.h>\fR -.fi - -.SH DESCRIPTION -.LP -The Internet protocol family implements a collection of protocols which are -centered around the Internet Protocol ("\fBIP\fR") and which share a common -address format. The Internet family protocols can be accessed using the socket -interface, where they support the \fBSOCK_STREAM\fR, \fBSOCK_DGRAM\fR, and -\fBSOCK_RAW\fR socket types, or the Transport Level Interface (TLI), where they -support the connectionless (\fBT_CLTS\fR) and connection oriented -(\fBT_COTS_ORD\fR) service types. -.SH PROTOCOLS -.LP -The Internet protocol family is comprised of the Internet Protocol -("\fBIP\fR"), the Address Resolution Protocol ("\fBARP\fR"), the Internet -Control Message Protocol ("\fBICMP\fR"), the Transmission Control Protocol -("\fBTCP\fR"), and the User Datagram Protocol ("\fBUDP\fR"). -.sp -.LP -\fBTCP\fR supports the socket interface's \fBSOCK_STREAM\fR abstraction and -\fBTLI\fR's \fBT_COTS_ORD\fR service type. \fBUDP\fR supports the -\fBSOCK_DGRAM\fR socket abstraction and the \fBTLI\fR \fBT_CLTS\fR service -type. See \fBtcp\fR(7P) and \fBudp\fR(7P). A direct interface to \fBIP\fR is -available using both \fBTLI\fR and the socket interface (see \fBip\fR(7P)). -\fBICMP\fR is used by the kernel to handle and report errors in protocol -processing. It is also accessible to user programs (see \fBicmp\fR(7P)). -\fBARP\fR is used to translate 32-bit \fBIP\fR addresses into 48-bit Ethernet -addresses. See \fBarp\fR(7P). -.sp -.LP -The 32-bit \fBIP\fR address is divided into network number and host number -parts. It is frequency-encoded. The most-significant bit is zero in Class A -addresses, in which the high-order 8 bits represent the network number. Class B -addresses have their high order two bits set to 10 and use the high-order 16 -bits as the network number field. Class C addresses have a 24-bit network -number part of which the high order three bits are 110. Sites with a cluster of -\fBIP\fR networks may chose to use a single network number for the cluster; -this is done by using subnet addressing. The host number portion of the address -is further subdivided into subnet number and host number parts. Within a -subnet, each subnet appears to be an individual network. Externally, the entire -cluster appears to be a single, uniform network requiring only a single routing -entry. Subnet addressing is enabled and examined by the following -\fBioctl\fR(2) commands. They have the same form as the \fBSIOCSIFADDR\fR -command. -.sp -.ne 2 -.na -\fB\fBSIOCSIFNETMASK\fR\fR -.ad -.RS 18n -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. -.RE - -.sp -.ne 2 -.na -\fB\fBSIOCGIFNETMASK\fR\fR -.ad -.RS 18n -Get interface network mask. -.RE - -.SH ADDRESSING -.LP -\fBIP\fR addresses are four byte quantities, stored in network byte order. -\fBIP\fR addresses should be manipulated using the byte order conversion -routines. See \fBbyteorder\fR(3C). -.sp -.LP -Addresses in the Internet protocol family use the \fBsockaddr_in\fR structure, -which has that following members: -.sp -.in +2 -.nf -short sin_family; -ushort_t sin_port; -struct in_addr sin_addr; -char sin_zero[8]; -.fi -.in -2 - -.sp -.LP -Library routines are provided to manipulate structures of this form; See -\fBinet\fR(3SOCKET). -.sp -.LP -The \fBsin_addr\fR field of the \fBsockaddr_in\fR structure specifies a local -or remote \fBIP\fR address. Each network interface has its own unique \fBIP\fR -address. The special value \fBINADDR_ANY\fR may be used in this field to -effect "wildcard" matching. Given in a \fBbind\fR(3SOCKET) call, this value -leaves the local \fBIP\fR address of the socket unspecified, so that the socket -will receive connections or messages directed at any of the valid \fBIP\fR -addresses of the system. This can prove useful when a process neither knows nor -cares what the local \fBIP\fR address is or when a process wishes to receive -requests using all of its network interfaces. The \fBsockaddr_in\fR structure -given in the \fBbind\fR(3SOCKET) call must specify an \fBin_addr\fR value of -either \fBINADDR_ANY\fR or one of the system's valid \fBIP\fR addresses. -Requests to bind any other address will elicit the error \fBEADDRNOTAVAIL\fR. -When a \fBconnect\fR(3SOCKET) call is made for a socket that has a wildcard -local address, the system sets the \fBsin_addr\fR field of the socket to the -\fBIP\fR address of the network interface that the packets for that connection -are routed through. -.sp -.LP -The \fBsin_port\fR field of the \fBsockaddr_in\fR structure specifies a port -number used by \fBTCP\fR or \fBUDP.\fR The local port address specified in a -\fBbind\fR(3SOCKET) call is restricted to be greater than \fBIPPORT_RESERVED\fR -(defined in <\fB<netinet/in.h>\fR>) unless the creating process is running as -the superuser, providing a space of protected port numbers. In addition, the -local port address must not be in use by any socket of same address family and -type. Requests to bind sockets to port numbers being used by other sockets -return the error \fBEADDRINUSE\fR. If the local port address is specified as 0, -then the system picks a unique port address greater than \fBIPPORT_RESERVED\fR. -A unique local port address is also picked when a socket which is not bound is -used in a \fBconnect\fR(3SOCKET) or \fBsendto\fR (see \fBsend\fR(3SOCKET)) -call. This allows programs which do not care which local port number is used to -set up \fBTCP\fR connections by simply calling \fBsocket\fR(3SOCKET) and then -\fBconnect\fR(3SOCKET), and to send \fBUDP\fR datagrams with a -\fBsocket\fR(3SOCKET) call followed by a \fBsendto()\fR call. -.sp -.LP -Although this implementation restricts sockets to unique local port numbers, -\fBTCP\fR allows multiple simultaneous connections involving the same local -port number so long as the remote \fBIP\fR addresses or port numbers are -different for each connection. Programs may explicitly override the socket -restriction by setting the \fBSO_REUSEADDR\fR socket option with -\fBsetsockopt\fR (see \fBgetsockopt\fR(3SOCKET)). -.sp -.LP -\fBTLI\fR applies somewhat different semantics to the binding of local port -numbers. These semantics apply when Internet family protocols are used using -the \fBTLI\fR. -.SH SEE ALSO -.LP -\fBioctl\fR(2), \fBbind\fR(3SOCKET), \fBbyteorder\fR(3C), -\fBconnect\fR(3SOCKET), \fBgethostbyname\fR(3NSL), \fBgetnetbyname\fR(3SOCKET), -\fBgetprotobyname\fR(3SOCKET), \fBgetservbyname\fR(3SOCKET), -\fBgetsockopt\fR(3SOCKET), \fBsend\fR(3SOCKET), \fBsockaddr\fR(3SOCKET), -\fBsocket\fR(3SOCKET), \fBarp\fR(7P), \fBicmp\fR(7P), \fBip\fR(7P), -\fBtcp\fR(7P), \fBudp\fR(7P) -.sp -.LP -Network Information Center, \fIDDN Protocol Handbook\fR (3 vols.), Network -Information Center, \fBSRI\fR International, Menlo Park, Calif., 1985. -.SH NOTES -.LP -The Internet protocol 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. diff --git a/usr/src/man/man7p/inet6.7p b/usr/src/man/man7p/inet6.7p deleted file mode 100644 index 9acffed9d7..0000000000 --- a/usr/src/man/man7p/inet6.7p +++ /dev/null @@ -1,404 +0,0 @@ -'\" te -.\" Copyright (C) 2002, Sun Microsystems, Inc. All Rights Reserved -.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License. -.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License. -.\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner] -.TH INET6 7P "Oct 3, 2002" -.SH NAME -inet6 \- Internet protocol family for Internet Protocol version 6 -.SH SYNOPSIS -.LP -.nf -\fB#include <sys/types.h> -#include <netinet/in.h>\fR -.fi - -.SH DESCRIPTION -.LP -The \fBinet6\fR protocol family implements a collection of protocols that are -centered around the Internet Protocol version 6 (\fBIPv6\fR) and share a common -address format. The \fBinet6\fR protocol family can be accessed using the -socket interface, where it supports the \fBSOCK_STREAM\fR, \fBSOCK_DGRAM\fR, -and \fBSOCK_RAW\fR socket types, or the Transport Level Interface (\fBTLI\fR), -where it supports the connectionless (\fBT_CLTS\fR) and connection oriented -(\fBT_COTS_ORD\fR) service types. -.SH PROTOCOLS -.LP -The Internet protocol family for \fBIPv6\fR included the Internet Protocol -Version 6 (\fBIPv6\fR), the Neighbor Discovery Protocol (\fBNDP\fR), the -Internet Control Message Protocol (\fBICMPv6\fR), the Transmission Control -Protocol (\fBTCP\fR), and the User Datagram Protocol (\fBUDP\fR). -.sp -.LP -\fBTCP\fR supports the socket interface's \fBSOCK_STREAM\fR abstraction and -\fBTLI\fR's \fBT_COTS_ORD\fR service type. \fBUDP\fR supports the -\fBSOCK_DGRAM\fR socket abstraction and the \fBTLI\fR \fBT_CLTS\fR service -type. See \fBtcp\fR(7P) and \fBudp\fR(7P). A direct interface to \fBIPv6\fR is -available using the socket interface. See \fBip6\fR(7P). \fBICMPv6\fR is used -by the kernel to handle and report errors in protocol processing. It is also -accessible to user programs. See \fBicmp6\fR(7P). \fBNDP\fR is used to -translate 128-bit \fBIPv6\fR addresses into 48-bit Ethernet addresses. -.sp -.LP -\fBIPv6\fR addresses come in three types: unicast, anycast, and multicast. A -unicast address is an identifier for a single network interface. An anycast -address is an identifier for a set of interfaces; a packet sent to an anycast -address is delivered to the "nearest" interface identified by that address, -pursuant to the routing protocol's measure of distance. A multicast address is -an identifier for a set of interfaces; a packet sent to a multicast address is -delivered to all interfaces identified by that address. There are no broadcast -addresses as such in \fBIPv6\fR; their functionality is superseded by multicast -addresses. -.sp -.LP -For \fBIPv6\fR addresses, there are three scopes within which unicast addresses -are guaranteed to be unique. The scope is indicated by the address prefix. The -three varieties are link-local (the address is unique on that physical link), -site-local (the address is unique within that site), and global (the address is -globally unique). -.sp -.LP -The three highest order bits for global unicast addresses are set to -\fB001\fR. The ten highest order bits for site-local addresses are set to -\fB1111 1110 11\fR. The ten highest order bits for link-local addresses are set -to \fB1111 1110 11\fR. For multicast addresses, the eight highest order bits -are set to \fB1111 1111\fR. Anycast addresses have the same format as unicast -addresses. -.sp -.LP -\fBIPv6\fR addresses do not follow the concept of "address class" seen in -\fBIP\fR. -.sp -.LP -A global unicast address is divided into the following segments: -.RS +4 -.TP -.ie t \(bu -.el o -The first three bits are the Format Prefix identifying a unicast address. -.RE -.RS +4 -.TP -.ie t \(bu -.el o -The next 13 bits are the Top-Level Aggregation (\fBTLA\fR) identifier. For -example, the identifier could specify the \fBISP\fR. -.RE -.RS +4 -.TP -.ie t \(bu -.el o -The next eight bits are reserved for future use. -.RE -.RS +4 -.TP -.ie t \(bu -.el o -The next 24 bits are the Next-Level Aggregation (\fBNLA\fR) identifier. -.RE -.RS +4 -.TP -.ie t \(bu -.el o -The next 16 bits are the Site-Level Aggregation (\fBSLA\fR) identifier. -.RE -.RS +4 -.TP -.ie t \(bu -.el o -The last 64 bits are the interface \fBID\fR. This will most often be the -hardware address of the link in \fBIEEE EUI-64\fR format. -.RE -.sp -.LP -Link-local unicast addresses are divided in this manner: -.RS +4 -.TP -.ie t \(bu -.el o -The first ten bits are the Format Prefix identifying a link-local address. -.RE -.RS +4 -.TP -.ie t \(bu -.el o -The next 54 bits are zero. -.RE -.RS +4 -.TP -.ie t \(bu -.el o -The last 64 bits are the interface \fBID\fR. This will most often be the -hardware address of the link in \fBIEEE EUI-64\fR format. -.RE -.sp -.LP -Site-local unicast addresses are divided in this manner: -.RS +4 -.TP -.ie t \(bu -.el o -The first ten bits are the Format Prefix identifying a site-local address. -.RE -.RS +4 -.TP -.ie t \(bu -.el o -The next 38 bits are zero. -.RE -.RS +4 -.TP -.ie t \(bu -.el o -The next 16 bits are the subnet \fBID\fR. -.RE -.RS +4 -.TP -.ie t \(bu -.el o -The last 64 bits are the interface \fBID\fR. This will most often be the -hardware address of the link in \fBIEEE EUI-64\fR format. -.RE -.SH ADDRESSING -.LP -\fBIPv6\fR addresses are sixteen byte quantities, stored in network byte order. -The socket \fBAPI\fR uses the \fBsockaddr_in6\fR structure when passing -\fBIPv6\fR addresses between an application and the kernel. The -\fBsockaddr_in6\fR structure has the following members: -.sp -.in +2 -.nf -sa_familty_t sin6_family; -in_port_t sin6_port; -uint32_t sin6_flowinfo; -struct in6_addr sin6_addr; -uint32_t sin6_scope_id; -uint32_t __sin6_src_id; -.fi -.in -2 - -.sp -.LP -Library routines are provided to manipulate structures of this form. See -\fBinet\fR(3SOCKET). -.sp -.LP -The \fBsin6_addr\fR field of the \fBsockaddr_in6\fR structure specifies a local -or remote \fBIPv6\fR address. Each network interface has one or more \fBIPv6\fR -addresses configured, that is, a link-local address, a site-local address, and -one or more global unicast \fBIPv6\fR addresses. The special value of all zeros -may be used on this field to test for "wildcard" matching. Given in a -\fBbind\fR(3SOCKET) call, this value leaves the local \fBIPv6\fR address of the -socket unspecified, so that the socket will receive connections or messages -directed at any of the valid \fBIPv6\fR addresses of the system. This can prove -useful when a process neither knows nor cares what the local \fBIPv6\fR address -is, or when a process wishes to receive requests using all of its network -interfaces. -.sp -.LP -The \fBsockaddr_in6\fR structure given in the \fBbind()\fR call must specify -an \fIin6_addr\fR value of either all zeros or one of the system's valid -\fBIPv6\fR addresses. Requests to bind any other address will elicit the error -\fBEADDRNOTAVAI\fR. When a \fBconnect\fR(3SOCKET) call is made for a socket -that has a wildcard local address, the system sets the \fBsin6_addr\fR field of -the socket to the \fBIPv6\fR address of the network interface through which the -packets for that connection are routed. -.sp -.LP -The \fBsin6_port\fR field of the \fBsockaddr_in6\fR structure specifies a port -number used by \fBTCP\fR or \fBUDP\fR. The local port address specified in a -\fBbind()\fR call is restricted to be greater than \fBIPPORT_RESERVED\fR -(defined in <\fBnetinet/in.h\fR>) unless the creating process is running as the -super-user, providing a space of protected port numbers. In addition, the -local port address cannot be in use by any socket of the same address family -and type. Requests to bind sockets to port numbers being used by other sockets -return the error \fBEADDRINUSE\fR. If the local port address is specified as -\fB0\fR, the system picks a unique port address greater than -\fBIPPORT_RESERVED\fR. A unique local port address is also selected when a -socket which is not bound is used in a \fBconnect\fR(3SOCKET) or \fBsendto()\fR -call. See \fBsend\fR(3SOCKET). This allows programs that do not care which -local port number is used to set up \fBTCP\fR connections by simply calling -\fBsocket\fR(3SOCKET) and then \fBconnect\fR(3SOCKET), and then sending -\fBUDP\fR datagrams with a \fBsocket()\fR call followed by a \fBsendto()\fR -call. -.sp -.LP -Although this implementation restricts sockets to unique local port numbers, -\fBTCP\fR allows multiple simultaneous connections involving the same local -port number so long as the remote \fBIPv6\fR addresses or port numbers are -different for each connection. Programs may explicitly override the socket -restriction by setting the \fBSO_REUSEADDR\fR socket option with -\fBsetsockopt()\fR. See \fBgetsockopt\fR(3SOCKET). -.sp -.LP -In addition, the same port may be bound by two separate sockets if one is an -\fBIP\fR socket and the other an \fBIPv6\fR socket. -.sp -.LP -\fBTLI\fR applies somewhat different semantics to the binding of local port -numbers. These semantics apply when Internet family protocols are used using -the \fBTLI\fR. -.SH SOURCE ADDRESS SELECTION -.LP -IPv6 source address selection is done on a per destination basis, and utilizes -a list of rules from which the best source address is selected from candidate -addresses. The candidate set comprises a set of local addresses assigned on the -system which are up and not anycast. If just one candidate exists in the -candidate set, it is selected. -.sp -.LP -Conceptually, each selection rule prefers one address over another, or -determines their equivalence. If a rule produces a tie, a subsequent rule is -used to break the tie. -.sp -.LP -The sense of some rules may be reversed on a per-socket basis using the -IPV6_SRC_PREFERENCES socket option (see \fBip6\fR(7P)). The flag values for -this option are defined in <\fBnetinet/in.h\fR> and are referenced in the -description of the appropriate rules below. -.sp -.LP -As the selection rules indicate, the candidate addresses are SA and SB and the -destination is D. -.sp -.ne 2 -.na -\fBPrefer the same address\fR -.ad -.RS 30n -If SA == D, prefer SA. If SB == D, prefer SB. -.RE - -.sp -.ne 2 -.na -\fBPrefer appropriate scope\fR -.ad -.RS 30n -Here, Scope(X) is the scope of X according to the IPv6 Addressing Architecture. -.sp -If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and otherwise -prefer SA. -.sp -If Scope(SB) < Scope(SA): If Scope(SB) < Scope(D), then prefer SA and otherwise -prefer SB. -.RE - -.sp -.ne 2 -.na -\fBAvoid deprecated addresses\fR -.ad -.RS 30n -If one of the addresses is deprecated (IFF_DEPRECATED) and the other is not, -prefer the one that isn't deprecated. -.RE - -.sp -.ne 2 -.na -\fBPrefer preferred addresses\fR -.ad -.RS 30n -If one of the addresses is preferred (IFF_PREFERRED) and the other is not, -prefer the one that is preferred. -.RE - -.sp -.ne 2 -.na -\fBPrefer outgoing interface\fR -.ad -.RS 30n -If one of the addresses is assigned to the interface that will be used to send -packets to D and the other is not, then prefer the former. -.RE - -.sp -.ne 2 -.na -\fBPrefer matching label\fR -.ad -.RS 30n -This rule uses labels which are obtained through the IPv6 default address -selection policy table. See \fBipaddrsel\fR(1M) for a description of the -default contents of the table and how the table is configured. -.sp -If Label(SA) == Label(D) and Label(SB) != Label(D), then prefer SA. -.sp -If Label(SB) == Label(D) and Label(SA) != Label(D), then prefer SB. -.RE - -.sp -.ne 2 -.na -\fBPrefer public addresses\fR -.ad -.RS 30n -This rule prefers public addresses over temporary addresses, as defined in -\fIRFC 3041\fR. Temporary addresses are disabled by default and may be enabled -by appropriate settings in \fBndpd.conf\fR(4). -.sp -The sense of this rule may be set on a per-socket basis using the -IPV6_SRC_PREFERENCES socket option. Passing the flag IPV6_PREFER_SRC_TMP or -IPV6_PREFER_SRC_PUBLIC will cause temporary or public addresses to be -preferred, respectively, for that particular socket. See \fBip6\fR(7P) for -more information about IPv6 socket options. -.RE - -.sp -.ne 2 -.na -\fBUse longest matching prefix.\fR -.ad -.sp .6 -.RS 4n -This rule prefers the source address that has the longer matching prefix with -the destination. Because this is the last rule and because both source -addresses could have equal matching prefixes, this rule does an \fBxor\fR of -each source address with the destination, then selects the source address with -the smaller \fBxor\fR value in order to break any potential tie. -.sp -If SA ^ D < SB ^ D, then prefer SA. -.sp -If SB ^ D < SA ^ D, then prefer SB. -.RE - -.sp -.LP -Applications can override this algorithm by calling \fBbind\fR(3SOCKET) and -specifying an address. -.SH SEE ALSO -.LP -\fBioctl\fR(2), \fBbind\fR(3SOCKET), \fBconnect\fR(3SOCKET), -\fBgetipnodebyaddr\fR(3SOCKET), -\fBgetipnodebyname\fR(3SOCKET), \fBgetprotobyname\fR(3SOCKET), -\fBgetservbyname\fR(3SOCKET), \fBgetsockopt\fR(3SOCKET), \fBinet\fR(3SOCKET), -\fBsend\fR(3SOCKET), \fBsockaddr\fR(3SOCKET), -\fBicmp6\fR(7P), \fBip6\fR(7P), \fBtcp\fR(7P), \fBudp\fR(7P) -.sp -.LP -Conta, A. and Deering, S., \fIInternet Control Message Protocol (ICMPv6) for -the Internet Protocol Version 6 (IPv6) Specification\fR, RFC 1885, December -1995. -.sp -.LP -Deering, S. and Hinden, B., \fIInternet Protocol, Version 6 (IPv6) -Specification\fR, RFC 1883, December 1995. -.sp -.LP -Hinden, B. and Deering, S., \fIIP Version 6 Addressing Architecture\fR, RFC -1884, December 1995. -.sp -.LP -Draves, R., \fIRFC 3484, Default Address Selection for IPv6.\fR The Internet -Society. February 2003. -.sp -.LP -Narten, T., and Draves, R. \fIRFC 3041, Privacy Extensions for Stateless -Address Autoconfiguration in IPv6.\fR The Internet Society. January 2001. -.SH NOTES -.LP -The \fBIPv6\fR 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. diff --git a/usr/src/man/man7p/ip.7p b/usr/src/man/man7p/ip.7p deleted file mode 100644 index b8c8d9a44d..0000000000 --- a/usr/src/man/man7p/ip.7p +++ /dev/null @@ -1,934 +0,0 @@ -'\" te -.\" Copyright 2020 OmniOS Community Edition (OmniOSce) Association. -.\" Copyright (c) 2008, Sun Microsystems, Inc. All Rights Reserved. -.\" Copyright 2008 AT&T -.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License. -.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License. -.\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner] -.TH IP 7P "Sep 18, 2020" -.SH NAME -ip, IP \- Internet Protocol -.SH SYNOPSIS -.nf -\fB#include <sys/socket.h>\fR -.fi - -.LP -.nf -\fB#include <netinet/in.h>\fR -.fi - -.LP -.nf -\fBs = socket(AF_INET, SOCK_RAW, proto);\fR -.fi - -.LP -.nf -\fBt = t_open ("/dev/rawip", O_RDWR);\fR -.fi - -.SH DESCRIPTION -IP is the internetwork datagram delivery protocol that is central to the -Internet protocol family. Programs may use \fBIP\fR through higher-level -protocols such as the Transmission Control Protocol (TCP) or the User Datagram -Protocol (UDP), or may interface directly to IP. See \fBtcp\fR(7P) and -\fBudp\fR(7P). Direct access may be by means of the socket interface, using a -"raw socket," or by means of the Transport Level Interface (TLI). The protocol -options defined in the IP specification may be set in outgoing datagrams. -.sp -.LP -Packets sent to or from this system may be subject to IPsec policy. See -\fBipsec\fR(7P) for more information. -.SH APPLICATION PROGRAMMING INTERFACE -The STREAMS driver \fB/dev/rawip\fR is the TLI transport provider that provides -raw access to IP. -.sp -.LP -Raw IP sockets are connectionless and are normally used with the \fBsendto()\fR -and \fBrecvfrom()\fR calls (see \fBsend\fR(3SOCKET) and \fBrecv\fR(3SOCKET)), -although the \fBconnect\fR(3SOCKET) call may also be used to fix the -destination for future datagram. In this case, the \fBread\fR(2) or -\fBrecv\fR(3SOCKET) and \fBwrite\fR(2) or \fBsend\fR(3SOCKET) calls may be -used. If \fIproto\fR is \fBIPPROTO_RAW\fR or \fBIPPROTO_IGMP\fR, the -application is expected to include a complete IP header when sending. -Otherwise, that protocol number will be set in outgoing datagrams and used to -filter incoming datagrams and an IP header will be generated and prepended to -each outgoing datagram. In either case, received datagrams are returned with -the IP header and options intact. -.sp -.LP -If an application uses \fBIP_HDRINCL\fR and provides the IP header contents, -the IP stack does not modify the following supplied fields under any -conditions: Type of Service, DF Flag, Protocol, and Destination Address. The IP -Options and IHL fields are set by use of \fBIP_OPTIONS\fR, and \fBTotal -Length\fR is updated to include any options. Version is set to the default. -Identification is chosen by the normal IP ID selection logic. The source -address is updated if none was specified and the TTL is changed if the packet -has a broadcast destination address. Since an applicaton cannot send down -fragments (as IP assigns the IP ID), Fragment Offset is always 0. The IP -Checksum field is computed by IP. None of the data beyond the IP header are -changed, including the application-provided transport header. -.sp -.LP -The socket options supported at the IP level are: -.sp -.ne 2 -.na -\fBIP_OPTIONS\fR -.ad -.RS 22n -IP options for outgoing datagrams. This socket option may be used to set IP -options to be included in each outgoing datagram. IP options to be sent are set -with \fBsetsockopt()\fR (see \fBgetsockopt\fR(3SOCKET)). The -\fBgetsockopt\fR(3SOCKET) call returns the IP options set in the last -\fBsetsockopt()\fR call. IP options on received datagrams are visible to user -programs only using raw IP sockets. The format of IP options given in -\fBsetsockopt()\fR matches those defined in the IP specification with one -exception: the list of addresses for the source routing options must include -the first-hop gateway at the beginning of the list of gateways. The first-hop -gateway address will be extracted from the option list and the size adjusted -accordingly before use. IP options may be used with any socket type in the -Internet family. -.RE - -.sp -.ne 2 -.na -\fBIP_SEC_OPT\fR -.ad -.RS 22n -Enable or obtain IPsec security settings for this socket. For more details on -the protection services of IPsec, see \fBipsec\fR(7P). -.RE - -.sp -.ne 2 -.na -\fBIP_ADD_MEMBERSHIP\fR -.ad -.RS 22n -Join a multicast group. -.RE - -.sp -.ne 2 -.na -\fBIP_DROP_MEMBERSHIP\fR -.ad -.RS 22n -Leave a multicast group. -.RE - -.sp -.ne 2 -.na -\fBIP_BOUND_IF\fR -.ad -.RS 22n -Limit reception and transmission of packets to this interface. Takes an -integer as an argument. The integer is the selected interface index. -.RE - -.sp -.LP -The following option takes \fBin_pktinfo_t\fR as the parameter: -.sp -.ne 2 -.na -\fBIP_PKTINFO\fR -.ad -.sp .6 -.RS 4n -Set the source address and/or transmit interface of the packet(s). Note that -the IP_BOUND_IF socket option takes precedence over the interface index passed -in IP_PKTINFO. -.sp -.in +2 -.nf -struct in_pktinfo { - unsigned int ipi_ifindex;/* send/recv interface index */ - struct in_addr ipi_spec_dst;/* matched source addr. */ - struct in_addr ipi_addr;/* src/dst addr. in IP hdr */ -} in_pktinfo_t; -.fi -.in -2 - -When passed in (on transmit) via ancillary data with IP_PKTINFO, ipi_spec_dst -is used as the source address and ipi_ifindex is used as the interface index to -send the packet out. -.RE - -.sp -.LP -The following options are boolean switches controlling the reception of -ancillary data. The option value is type \fBint\fR; a non-zero value -enables the option whilst a zero value disables it. - -.sp -.ne 2 -.na -\fBIP_RECVDSTADDR\fR -.ad -.RS 22n -When enabled on a SOCK_DGRAM socket, enables receipt of the destination -IP address of the incoming packet. Returns \fBinaddr_t\fR as ancillary -data. -.RE - -.sp -.ne 2 -.na -\fBIP_RECVIF\fR -.ad -.RS 22n -Enable/disable receipt of the inbound interface index. Returns \fBuint_t\fR as -ancillary data. -.RE - -.sp -.ne 2 -.na -\fBIP_RECVOPTS\fR -.ad -.RS 22n -When enabled on a SOCK_DGRAM socket, enables receipt of the IP options -from the incoming packet. Returns variable-length IP options, up to 40 -bytes, as ancillary data. -.RE - -.sp -.ne 2 -.na -\fBIP_RECVPKTINFO\fR -.ad -.RS 22n -Enable/disable receipt of the index of the interface the packet arrived on, the -local address that was matched for reception, and the inbound packet's actual -destination address. Takes boolean as the parameter. Returns -\fBin_pktinfo_t\fR as ancillary data. -.RE - -.sp -.ne 2 -.na -\fBIP_RECVSLLA\fR -.ad -.RS 22n -When enabled on a SOCK_DGRAM socket, enables receipt of the source link-layer -address for the incoming packet. Returns \fBstruct sockaddr_dl\fR as -ancillary data. -.RE - -.sp -.ne 2 -.na -\fBIP_RECVTTL\fR -.ad -.RS 22n -When enabled on a SOCK_DGRAM socket, the IP TTL (time to live) field for an -incoming datagram is returned as \fBuint8_t\fR in ancillary data. -.RE - -.sp -.ne 2 -.na -\fBIP_RECVTOS\fR -.ad -.RS 22n -When enabled, the IP TOS (type of service) field is returned as \fBuint8_t\fR -in ancillary data. For \fBSOCK_DGRAM\fR sockets, the ancillary data item is -included for every call to \fBrecvmsg()\fR. For \fBSOCK_STREAM\fR sockets, -where there is no direct mapping between received TCP segments and receive -operations, the ancillary data item will only be present when this option -is first enabled, and subsequently only if the value changes. -.RE - -.sp -.LP -The following options take a \fBstruct ip_mreq\fR as the parameter. The -structure contains a multicast address which must be set to the \fBCLASS-D\fR -\fBIP\fR multicast address and an interface address. Normally the interface -address is set to \fBINADDR_ANY\fR which causes the kernel to choose the -interface on which to join. -.sp -.ne 2 -.na -\fBIP_BLOCK_SOURCE\fR -.ad -.RS 29n -Block multicast packets whose source address matches the given source address. -The specified group must be joined previously using IP_ADD_MEMBERSHIP or -MCAST_JOIN_GROUP. -.RE - -.sp -.ne 2 -.na -\fBIP_UNBLOCK_SOURCE\fR -.ad -.RS 29n -Unblock (begin receiving) multicast packets which were previously blocked using -IP_BLOCK_SOURCE. -.RE - -.sp -.ne 2 -.na -\fBIP_ADD_SOURCE_MEMBERSHIP\fR -.ad -.RS 29n -Begin receiving packets for the given multicast group whose source address -matches the specified address. -.RE - -.sp -.ne 2 -.na -\fBIP_DROP_SOURCE_MEMBERSHIP\fR -.ad -.RS 29n -Stop receiving packets for the given multicast group whose source address -matches the specified address. -.RE - -.sp -.LP -The following options take a \fBstruct ip_mreq_source\fR as the parameter. The -structure contains a multicast address (which must be set to the CLASS-D IP -multicast address), an interface address, and a source address. -.sp -.ne 2 -.na -\fBMCAST_JOIN_GROUP\fR -.ad -.RS 28n -Join a multicast group. Functionally equivalent to IP_ADD_MEMBERSHIP. -.RE - -.sp -.ne 2 -.na -\fBMCAST_BLOCK_SOURCE\fR -.ad -.RS 28n -Block multicast packets whose source address matches the given source address. -The specified group must be joined previously using IP_ADD_MEMBERSHIP or -MCAST_JOIN_GROUP. -.RE - -.sp -.ne 2 -.na -\fBMCAST_UNBLOCK_SOURCE\fR -.ad -.RS 28n -Unblock (begin receiving) multicast packets which were previously blocked using -MCAST_BLOCK_SOURCE. -.RE - -.sp -.ne 2 -.na -\fBMCAST_LEAVE_GROUP\fR -.ad -.RS 28n -Leave a multicast group. Functionally equivalent to IP_DROP_MEMBERSHIP. -.RE - -.sp -.ne 2 -.na -\fBMCAST_JOIN_SOURCE_GROUP\fR -.ad -.RS 28n -Begin receiving packets for the given multicast group whose source address -matches the specified address. -.RE - -.sp -.ne 2 -.na -\fBMCAST_LEAVE_SOURCE_GROUP\fR -.ad -.RS 28n -Stop receiving packets for the given multicast group whose source address -matches the specified address. -.RE - -.sp -.LP -The following options take a struct \fBgroup_req\fR or struct -\fBgroup_source_req\fR as the parameter. The `\fBgroup_req\fR structure -contains an interface index and a multicast address which must be set to the -CLASS-D multicast address. The \fBgroup_source_req\fR structure is used for -those options which include a source address. It contains an interface index, -multicast address, and source address. -.sp -.ne 2 -.na -\fBIP_MULTICAST_IF\fR -.ad -.RS 21n -The outgoing interface for multicast packets. This option takes a \fBstruct\fR -\fBin_addr\fR as an argument, and it selects that interface for outgoing IP -multicast packets. If the address specified is \fBINADDR_ANY\fR, it uses the -unicast routing table to select the outgoing interface (which is the default -behavior). -.RE - -.sp -.ne 2 -.na -\fBIP_MULTICAST_TTL\fR -.ad -.RS 21n -Time to live for multicast datagrams. This option takes an unsigned character -as an argument. Its value is the TTL that IP uses on outgoing multicast -datagrams. The default is \fB1\fR. -.RE - -.sp -.ne 2 -.na -\fBIP_MULTICAST_LOOP\fR -.ad -.RS 21n -Loopback for multicast datagrams. Normally multicast datagrams are delivered -to members on the sending host (or sending zone). Setting the unsigned -character argument to 0 causes the opposite behavior, meaning that when -multiple zones are present, the datagrams are delivered to all zones except the -sending zone. -.RE - -.sp -.ne 2 -.na -\fBIP_TOS\fR -.ad -.RS 21n -This option takes an integer argument as its input value. The least significant -8 bits of the value are used to set the Type Of Service field in the IP header -of the outgoing packets. -.RE - -.sp -.ne 2 -.na -\fBIP_NEXTHOP\fR -.ad -.RS 21n -This option specifies the address of the onlink nexthop for traffic originating -from that socket. It causes the routing table to be bypassed and outgoing -traffic is sent directly to the specified nexthop. This option takes an -ipaddr_t argument representing the IPv4 address of the nexthop as the input -value. The IP_NEXTHOP option takes precedence over IPOPT_LSRR. IP_BOUND_IF and -SO_DONTROUTE take precedence over IP_NEXTHOP. This option has no meaning for -broadcast and multicast packets. The application must ensure that the specified -nexthop is alive. An application may want to specify the IP_NEXTHOP option on a -TCP listener socket only for incoming requests to a particular IP address. In -this case, it must avoid binding the socket to INADDR_ANY and instead must bind -the listener socket to the specific IP address. In addition, typically the -application may want the incoming and outgoing interface to be the same. In -this case, the application must select a suitable nexthop that is onlink and -reachable via the desired interface and do a setsockopt (IP_NEXTHOP) on it. -Then it must bind to the IP address of the desired interface. Setting the -IP_NEXTHOP option requires the PRIV_SYS_NET_CONFIG privilege. -.RE - -.sp -.LP -The multicast socket options (IP_MULTICAST_IF, IP_MULTICAST_TTL, -IP_MULTICAST_LOOP and IP_RECVIF) can be used with any datagram socket type in -the Internet family. -.sp -.LP -At the socket level, the socket option \fBSO_DONTROUTE\fR may be applied. This -option forces datagrams being sent to bypass routing and forwarding by forcing -the IP Time To Live field to \fB1\fR, meaning that the packet will not be -forwarded by routers. -.sp -.LP -Raw IP datagrams can also be sent and received using the TLI connectionless -primitives. -.sp -.LP -Datagrams flow through the IP layer in two directions: from the network -\fIup\fR to user processes and from user processes \fIdown\fR to the network. -Using this orientation, IP is layered \fIabove\fR the network interface drivers -and \fIbelow\fR the transport protocols such as UDP and TCP. The Internet -Control Message Protocol (ICMP) is logically a part of IP. See \fBicmp\fR(7P). -.sp -.LP -IP provides for a checksum of the header part, but not the data part, of the -datagram. The checksum value is computed and set in the process of sending -datagrams and checked when receiving datagrams. -.sp -.LP -IP options in received datagrams are processed in the IP layer according to the -protocol specification. Currently recognized IP options include: security, -loose source and record route (LSRR), strict source and record route (SSRR), -record route, and internet timestamp. -.sp -.LP -By default, the IP layer will not forward IPv4 packets that are not addressed -to it. This behavior can be overridden by using \fBrouteadm\fR(1M) to enable -the ipv4-forwarding option. IPv4 forwarding is configured at boot time based on -the setting of \fBrouteadm\fR(1M)'s ipv4-forwarding option. -.sp -.LP -For backwards compatibility, IPv4 forwarding can be enabled or disabled using -\fBndd\fR(1M)'s ip_forwarding variable. It is set to 1 if IPv4 forwarding is -enabled, or 0 if it is disabled. -.sp -.LP -Additionally, finer-grained forwarding can be configured in IP. Each interface -can be configured to forward IP packets by setting the IFF_ROUTER interface -flag. This flag can be set and cleared using \fBifconfig\fR(1M)'s router and -router options. If an interface's IFF_ROUTER flag is set, packets can be -forwarded to or from the interface. If it is clear, packets will neither be -forwarded from this interface to others, nor forwarded to this interface. -Setting the ip_forwarding variable sets all of the IPv4 interfaces' IFF_ROUTER -flags. -.sp -.LP -For backwards compatibility, each interface creates an -\fB<ifname>:ip_forwarding /dev/ip\fR variable that can be modified using -\fBndd\fR(1M). An interface's \fB:ip_forwarding ndd\fR variable is a boolean -variable that mirrors the status of its IFF_ROUTER interface flag. It is set to -1 if the flag is set, or 0 if it is clear. This interface specific \fB<ifname> -:ip_forwarding ndd\fR variable is obsolete and may be removed in a future -release of Solaris. The \fBifconfig\fR(1M) router and -router interfaces are -preferred. -.sp -.LP -The IP layer sends an ICMP message back to the source host in many cases when -it receives a datagram that can not be handled. A "time exceeded" ICMP message -is sent if the "time to live" field in the IP header drops to zero in the -process of forwarding a datagram. A "destination unreachable" message is sent -if a datagram can not be forwarded because there is no route to the final -destination, or if it can not be fragmented. If the datagram is addressed to -the local host but is destined for a protocol that is not supported or a port -that is not in use, a destination unreachable message is also sent. The IP -layer may send an ICMP "source quench" message if it is receiving datagrams too -quickly. ICMP messages are only sent for the first fragment of a fragmented -datagram and are never returned in response to errors in other ICMP messages. -.sp -.LP -The IP layer supports fragmentation and reassembly. Datagrams are fragmented on -output if the datagram is larger than the maximum transmission unit (MTU) of -the network interface. Fragments of received datagrams are dropped from the -reassembly queues if the complete datagram is not reconstructed within a short -time period. -.sp -.LP -Errors in sending discovered at the network interface driver layer are passed -by IP back up to the user process. -.sp -.LP -Multi-Data Transmit allows more than one packet to be sent from the IP module -to another in a given call, thereby reducing the per-packet processing costs. -The behavior of Multi-Data Transmit can be overrideen by using \fBndd\fR(1M) to -set the \fB/dev/ip\fR variable, ip_multidata_outbound to 0. Note, the IP module -will only initiate Multi-Data Transmit if the network interface driver supports -it. -.SH PACKET EVENTS -Through the netinfo framework, this driver provides the following packet -events: -.sp -.ne 2 -.na -\fBPhysical in\fR -.ad -.RS 16n -Packets received on a network interface from an external source. -.RE - -.sp -.ne 2 -.na -\fBPhysical out\fR -.ad -.RS 16n -Packets to be sent out a network interface. -.RE - -.sp -.ne 2 -.na -\fBForwarding\fR -.ad -.RS 16n -Packets being forwarded through this host to another network. -.RE - -.sp -.ne 2 -.na -\fBloopback in\fR -.ad -.RS 16n -Packets that have been sent by a local application to another. -.RE - -.sp -.ne 2 -.na -\fBloopback out\fR -.ad -.RS 16n -Packets about to be received by a local application from another. -.RE - -.sp -.LP -Currently, only a single function may be registered for each event. As a -result, if the slot for an event is already occupied by someone else, a second -attempt to register a callback fails. -.sp -.LP -To receive packet events in a kernel module, it is first necessary to obtain a -handle for either IPv4 or IPv6 traffic. This is achieved by passing NHF_INET -or NHF_INET6 through to a net_protocol_lookup() call. The value returned from -this call must then be passed into a call to net_register_hook(), along with -a description of the hook to add. For a description of the structure passed -through to the callback, please see \fBhook_pkt_event\fR(9S). For IP -packets, this structure is filled out as follows: -.sp -.ne 2 -.na -\fBhpe_ifp\fR -.ad -.RS 11n -Identifier indicating the inbound interface for packets received with the -"physical in" event. -.RE - -.sp -.ne 2 -.na -\fBhpe_ofp\fR -.ad -.RS 11n -Identifier indicating the outbound interface for packets received with the -"physical out" event. -.RE - -.sp -.ne 2 -.na -\fBhpe_hdr\fR -.ad -.RS 11n -Pointer to the start of the IP header (not the ethernet header). -.RE - -.sp -.ne 2 -.na -\fBhpe_mp\fR -.ad -.RS 11n -Pointer to the start of the mblk_t chain containing the IP packet. -.RE - -.sp -.ne 2 -.na -\fBhpe_mb\fR -.ad -.RS 11n -Pointer to the mblk_t with the IP header in it. -.RE - -.SH NETWORK INTERFACE EVENTS -In addition to events describing packets as they move through the system, it is -also possible to receive notification of events relating to network interfaces. -These events are all reported back through the same callback. The list of -events is as follows: -.sp -.ne 2 -.na -\fBplumb\fR -.ad -.RS 18n -A new network interface has been instantiated. -.RE - -.sp -.ne 2 -.na -\fBunplumb\fR -.ad -.RS 18n -A network interface is no longer associated with this protocol. -.RE - -.sp -.ne 2 -.na -\fBup\fR -.ad -.RS 18n -At least one logical interface is now ready to receive packets. -.RE - -.sp -.ne 2 -.na -\fBdown\fR -.ad -.RS 18n -There are no logical interfaces expecting to receive packets. -.RE - -.sp -.ne 2 -.na -\fBaddress change\fR -.ad -.RS 18n -An address has changed on a logical interface. -.RE - -.SH SEE ALSO -\fBifconfig\fR(1M), \fBrouteadm\fR(1M), \fBndd\fR(1M), \fBread\fR(2), -\fBwrite\fR(2), \fBsocket.h\fR(3HEAD), \fBbind\fR(3SOCKET), -\fBconnect\fR(3SOCKET), \fBgetsockopt\fR(3SOCKET), \fBrecv\fR(3SOCKET), -\fBsend\fR(3SOCKET), \fBsetsockopt\fR(3SOCKET), \fBdefaultrouter\fR(4), -\fBicmp\fR(7P), \fBif_tcp\fR(7P), \fBinet\fR(7P), \fBip\fR(7P), \fBip6\fR(7P), -\fBipsec\fR(7P), \fBrouting\fR(7P), \fBtcp\fR(7P), \fBudp\fR(7P), -\fBnet_hook_register\fR(9F), \fBhook_pkt_event\fR(9S) -.sp -.LP -Braden, R., \fIRFC 1122, Requirements for Internet Hosts \(mi Communication -Layers\fR, Information Sciences Institute, University of Southern California, -October 1989. -.sp -.LP -Postel, J., \fIRFC 791, Internet Protocol \(mi DARPA Internet Program Protocol -Specification\fR, Information Sciences Institute, University of Southern -California, September 1981. -.SH DIAGNOSTICS -A socket operation may fail with one of the following errors returned: -.sp -.ne 2 -.na -\fBEACCES\fR -.ad -.RS 17n -A \fBbind()\fR operation was attempted with a "reserved" port number and the -effective user ID of the process was not the privileged user. -.sp -Setting the IP_NEXTHOP was attempted by a process lacking the -PRIV_SYS_NET_CONFIG privilege. -.RE - -.sp -.ne 2 -.na -\fBEADDRINUSE\fR -.ad -.RS 17n -A \fBbind()\fR operation was attempted on a socket with a network address/port -pair that has already been bound to another socket. -.RE - -.sp -.ne 2 -.na -\fBEADDRNOTAVAIL\fR -.ad -.RS 17n -A \fBbind()\fR operation was attempted for an address that is not configured on -this machine. -.RE - -.sp -.ne 2 -.na -\fBEINVAL\fR -.ad -.RS 17n -A \fBsendmsg()\fR operation with a non-NULL \fBmsg_accrights\fR was attempted. -.RE - -.sp -.ne 2 -.na -\fBEINVAL\fR -.ad -.RS 17n -A \fBgetsockopt()\fR or \fBsetsockopt()\fR operation with an unknown socket -option name was given. -.RE - -.sp -.ne 2 -.na -\fBEINVAL\fR -.ad -.RS 17n -A \fBgetsockopt()\fR or \fBsetsockopt()\fR operation was attempted with the -\fBIP\fR option field improperly formed; an option field was shorter than the -minimum value or longer than the option buffer provided. -.RE - -.sp -.ne 2 -.na -\fBEISCONN\fR -.ad -.RS 17n -A \fBconnect()\fR operation was attempted on a socket on which a -\fBconnect()\fR operation had already been performed, and the socket could not -be successfully disconnected before making the new connection. -.RE - -.sp -.ne 2 -.na -\fBEISCONN\fR -.ad -.RS 17n -A \fBsendto()\fR or \fBsendmsg()\fR operation specifying an address to which -the message should be sent was attempted on a socket on which a \fBconnect()\fR -operation had already been performed. -.RE - -.sp -.ne 2 -.na -\fBEMSGSIZE\fR -.ad -.RS 17n -A \fBsend()\fR, \fBsendto()\fR, or \fBsendmsg()\fR operation was attempted to -send a datagram that was too large for an interface, but was not allowed to be -fragmented (such as broadcasts). -.RE - -.sp -.ne 2 -.na -\fBENETUNREACH\fR -.ad -.RS 17n -An attempt was made to establish a connection by means of \fBconnect()\fR, or -to send a datagram by means of \fBsendto()\fR or \fBsendmsg()\fR, where there -was no matching entry in the routing table; or if an ICMP "destination -unreachable" message was received. -.RE - -.sp -.ne 2 -.na -\fBENOTCONN\fR -.ad -.RS 17n -A \fBsend()\fR or \fBwrite()\fR operation, or a \fBsendto()\fR or -\fBsendmsg()\fR operation not specifying an address to which the message should -be sent, was attempted on a socket on which a \fBconnect()\fR operation had not -already been performed. -.RE - -.sp -.ne 2 -.na -\fBENOBUFS\fR -.ad -.RS 17n -The system ran out of memory for fragmentation buffers or other internal data -structures. -.RE - -.sp -.ne 2 -.na -\fBENOBUFS\fR -.ad -.RS 17n -\fBSO_SNDBUF\fR or \fBSO_RCVBUF\fR exceeds a system limit. -.RE - -.sp -.ne 2 -.na -\fBEINVAL\fR -.ad -.RS 17n -Invalid length for \fBIP_OPTIONS\fR. -.RE - -.sp -.ne 2 -.na -\fBEHOSTUNREACH\fR -.ad -.RS 17n -Invalid address for \fBIP_MULTICAST_IF\fR. -.sp -Invalid (offlink) nexthop address for IP_NEXTHOP. -.RE - -.sp -.ne 2 -.na -\fBEINVAL\fR -.ad -.RS 17n -Not a multicast address for \fBIP_ADD_MEMBERSHIP\fR and -\fBIP_DROP_MEMBERSHIP\fR. -.RE - -.sp -.ne 2 -.na -\fBEADDRNOTAVAIL\fR -.ad -.RS 17n -Bad interface address for \fBIP_ADD_MEMBERSHIP\fR and \fBIP_DROP_MEMBERSHIP\fR. -.RE - -.sp -.ne 2 -.na -\fBEADDRINUSE\fR -.ad -.RS 17n -Address already joined for \fBIP_ADD_MEMBERSHIP\fR. -.RE - -.sp -.ne 2 -.na -\fBENOENT\fR -.ad -.RS 17n -Address not joined for \fBIP_DROP_MEMBERSHIP\fR. -.RE - -.sp -.ne 2 -.na -\fBENOPROTOOPT\fR -.ad -.RS 17n -Invalid socket type. -.RE - -.sp -.ne 2 -.na -\fBEPERM\fR -.ad -.RS 17n -No permissions. -.RE - -.SH NOTES -Raw sockets should receive \fBICMP\fR error packets relating to the protocol; -currently such packets are simply discarded. -.sp -.LP -Users of higher-level protocols such as \fBTCP\fR and \fBUDP\fR should be able -to see received IP options. diff --git a/usr/src/man/man7p/ip6.7p b/usr/src/man/man7p/ip6.7p deleted file mode 100644 index c88233ed39..0000000000 --- a/usr/src/man/man7p/ip6.7p +++ /dev/null @@ -1,779 +0,0 @@ -'\" te -.\" Copyright (c) 2008, Sun Microsystems, Inc. All Rights Reserved -.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License. -.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License. -.\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner] -.TH IP6 7P "December 28, 2020" -.SH NAME -ip6 \- Internet Protocol Version 6 -.SH SYNOPSIS -.nf -#include <sys/socket.h> -#include <netinet/in.h> -#include <netinet/ip6.h> -.fi - -.LP -.nf -s = socket(AF_INET6, SOCK_RAW, proto); -.fi - -.LP -.nf -t = t_open ("/dev/rawip6", O_RDWR); -.fi - -.SH DESCRIPTION -The \fBIPv6\fR protocol is the next generation of the internetwork datagram -delivery protocol of the Internet protocol family. Programs may use \fBIPv6\fR -through higher-level protocols such as the Transmission Control Protocol -(\fBTCP\fR) or the User Datagram Protocol (\fBUDP\fR), or may interface -directly to \fBIPv6\fR. See \fBtcp\fR(7P) and \fBudp\fR(7P). Direct access may -be by means of the socket interface, using a "raw socket," or by means of the -Transport Level Interface (\fBTLI\fR). The protocol options and \fBIPv6\fR -extension headers defined in the \fBIPv6\fR specification may be set in -outgoing datagrams. -.SH APPLICATION PROGRAMMING INTERFACE -The \fBSTREAMS\fR driver \fB/dev/rawip6\fR is the \fBTLI\fR transport provider -that provides raw access to \fBIPv6\fR. -.sp -.LP -Raw \fBIPv6\fR sockets are connectionless and are normally used with the -\fBsendto()\fR and \fBrecvfrom()\fR calls (see \fBsend\fR(3SOCKET) and -\fBrecv\fR(3SOCKET)), although the \fBconnect\fR(3SOCKET) call may also be used -to fix the destination for future datagrams. In this case, the \fBread\fR(2) or -\fBrecv\fR(3SOCKET) and \fBwrite\fR(2) or \fBsend\fR(3SOCKET) calls may be -used. Ancillary data may also be sent or received over raw \fBIPv6\fR sockets -using the \fBsendmsg\fR(3SOCKET) and \fBrecvmsg\fR(3SOCKET) system calls. -.sp -.LP -Unlike raw \fBIP\fR, \fBIPv6\fR applications do not include a complete -\fBIPv6\fR header when sending; there is no \fBIPv6\fR analog to the \fBIP\fR -\fBIP_HDRINCL\fR socket option. \fBIPv6\fR header values may be specified or -received as ancillary data to a \fBsendmsg\fR(3SOCKET) or -\fBrecvmsg\fR(3SOCKET) system call, or may be specified as "sticky" options on -a per-socket basis by using the \fBsetsockopt\fR(3SOCKET) system call. Such -sticky options are applied to all outbound packets unless overridden by -ancillary data. If any ancillary data is specified in a \fBsendmsg\fR(3SOCKET) -call, all sticky options not explicitly overridden revert to default values for -that datagram only; the sticky options persist as set for subsequent datagrams. -.sp -.LP -Since \fBsendmsg\fR(3SOCKET) is not supported for \fBSOCK_STREAM\fR upper level -protocols such as \fBTCP\fR, ancillary data is unsupported for \fBTCP\fR. -Sticky options, however, are supported. -.sp -.LP -Since \fBsendmsg\fR(3SOCKET) is supported for \fBSOCK_DGRAM\fR upper level -protocols, both ancillary data and sticky options are supported for \fBUDP\fR, -\fBICMP6\fR, and raw \fBIPv6\fR sockets. -.sp -.LP -The socket options supported at the \fBIPv6\fR level are: -.sp -.ne 2 -.na -\fB\fBIPV6_BOUND_IF\fR\fR -.ad -.RS 24n -Limit reception and transmission of packets to this interface. Takes an integer -as an argument; the integer is the selected interface index. -.RE - -.sp -.ne 2 -.na -\fB\fBIPV6_UNSPEC_SRC\fR\fR -.ad -.RS 24n -Boolean. Allow/disallow sending with a zero source address. -.RE - -.sp -.ne 2 -.na -\fB\fBIPV6_UNICAST_HOPS\fR\fR -.ad -.RS 24n -Default hop limit for unicast datagrams. This option takes an integer as an -argument. Its value becomes the new default value for \fBip6_hops\fR that -\fBIPv6\fR will use on outgoing unicast datagrams sent from that socket. The -initial default is \fB60\fR. -.RE - -.sp -.ne 2 -.na -\fB\fBIPV6_CHECKSUM\fR\fR -.ad -.RS 24n -Specify the integer offset in bytes into the user data of the checksum -location. Does not apply to the \fBICMP6\fR protocol. Note: checksums are -required for all \fBIPv6\fR datagrams; this is different from \fBIP\fR, in -which datagram checksums were optional. \fBIPv6\fR will compute the \fBULP\fR -checksum if the value in the checksum field is zero. -.RE - -.sp -.ne 2 -.na -\fB\fBIPV6_SEC_OPT\fR\fR -.ad -.RS 24n -Enable or obtain IPsec security settings for this socket. For more details on -the protection services of IPsec, see \fBipsec\fR(7P). -.RE - -.sp -.ne 2 -.na -\fB\fBIPV6_DONTFRAG\fR\fR -.ad -.RS 24n -Boolean. Control fragmentation. -.RE - -.sp -.ne 2 -.na -\fB\fBIPV6_USE_MIN_MTU\fR\fR -.ad -.RS 24n -Controls whether path MTU discovery is used. If set to 1, path MTU discovery is -never used and IPv6 packets are sent with the IPv6 minimum MTU. If set to -1, -path MTU discovery is not used for multicast and multicast packets are sent -with the IPv6 minimum MTU. If set to 0, path MTU is always performed. -.RE - -.sp -.ne 2 -.na -\fB\fBIPV6_V6ONLY\fR\fR -.ad -.RS 24n -Boolean. If set, only V6 packets can be sent or received -.RE - -.sp -.ne 2 -.na -\fB\fBIPV6_SRC_PREFERENCES\fR\fR -.ad -.RS 24n -Enable or obtain Source Address Selection rule settings for this socket. For -more details on the Source Address Selection rules, see \fBinet6\fR(7P). -.RE - -.sp -.LP -The following options are boolean switches controlling the reception of -ancillary data: -.sp -.ne 2 -.na -\fB\fBIPV6_RECVPKTINFO\fR\fR -.ad -.RS 25n -Enable/disable receipt of the index of the interface the packet arrived on, and -of the inbound packet's destination address. -.RE - -.sp -.ne 2 -.na -\fB\fBIPV6_RECVHOPLIMIT\fR\fR -.ad -.RS 25n -Enable/disable receipt of the inbound packet's current hoplimit. -.RE - -.sp -.ne 2 -.na -\fB\fBIPV6_RECVHOPOPTS\fR\fR -.ad -.RS 25n -Enable/disable receipt of the inbound packet's \fBIPv6\fR hop-by-hop extension -header. -.RE - -.sp -.ne 2 -.na -\fB\fBIPV6_RECVDSTOPTS\fR\fR -.ad -.RS 25n -Enable/disable receipt of the inbound packet's \fBIPv6\fR destination options -extension header. -.RE - -.sp -.ne 2 -.na -\fB\fBIPV6_RECVRTHDR\fR\fR -.ad -.RS 25n -Enable/disable receipt of the inbound packet's \fBIPv6\fR routing header. -.RE - -.sp -.ne 2 -.na -\fB\fBIPV6_RECVRTHDRDSTOPTS\fR\fR -.ad -.RS 25n -Enable/disable receipt of the inbound packet's intermediate-hops options -extension header. This option is obsolete. IPV6_RECVDSTOPTS turns on receipt of -both destination option headers. -.RE - -.sp -.ne 2 -.na -\fB\fBIPV6_RECVTCLASS\fR\fR -.ad -.RS 25n -Enable/disable receipt of the traffic class of the inbound packet. -.RE - -.sp -.ne 2 -.na -\fB\fBIPV6_RECVPATHMTU\fR\fR -.ad -.RS 25n -Enable/disable receipt of the path mtu of the inbound packet. -.RE - -.sp -.LP -The following options may be set as sticky options with -\fBsetsockopt\fR(3SOCKET) or as ancillary data to a \fBsendmsg\fR(3SOCKET) -system call: -.sp -.ne 2 -.na -\fB\fBIPV6_PKTINFO\fR\fR -.ad -.RS 21n -Set the source address and/or interface out which the packet(s) will be sent. -Takes a \fBstruct\fR \fBin6_pktinfo\fR as the parameter. -.RE - -.sp -.ne 2 -.na -\fB\fBIPV6_HOPLIMIT\fR\fR -.ad -.RS 21n -Set the initial hoplimit for outbound datagrams. Takes an integer as the -parameter. Note: This option sets the hoplimit only for ancillary data or -sticky options and does not change the default hoplimit for the socket; see -\fBIPV6_UNICAST_HOPS\fR and \fBIPV6_MULTICAST_HOPS\fR to change the socket's -default hoplimit. -.RE - -.sp -.ne 2 -.na -\fB\fBIPV6_NEXTHOP\fR\fR -.ad -.RS 21n -Specify the \fBIPv6\fR address of the first hop, which must be a neighbor of -the sending host. Takes a \fBstruct\fR \fBsockaddr_in6\fR as the parameter. -When this option specifies the same address as the destination \fBIPv6\fR -address of the datagram, this is equivalent to the existing \fBSO_DONTROUTE\fR -option. -.RE - -.sp -.ne 2 -.na -\fB\fBIPV6_HOPOPTS\fR\fR -.ad -.RS 21n -Specify one or more hop-by-hop options. Variable length. Takes a complete -\fBIPv6\fR hop-by-hop options extension header as the parameter. -.RE - -.sp -.ne 2 -.na -\fB\fBIPV6_DSTOPTS\fR\fR -.ad -.RS 21n -Specify one or more destination options. Variable length. Takes a complete -\fBIPv6\fR destination options extension header as the parameter. -.RE - -.sp -.ne 2 -.na -\fB\fBIPV6_RTHDR\fR\fR -.ad -.RS 21n -Specify the \fBIPv6\fR routing header. Variable length. Takes a complete -\fBIPv6\fR routing header as the parameter. Currently, only type 0 routing -headers are supported. -.RE - -.sp -.ne 2 -.na -\fB\fBIPV6_RTHDRDSTOPTS\fR\fR -.ad -.RS 21n -Specify one or more destination options for all intermediate hops. May be -configured, but will not be applied unless an \fBIPv6\fR routing header is also -configured. Variable length. Takes a complete \fBIPv6\fR destination options -extension header as the parameter. -.RE - -.sp -.ne 2 -.na -\fB\fBIPV6_PATHMTU\fR\fR -.ad -.RS 21n -Get the path MTU associated with a connected socket. Takes a ip6_mtuinfo as the -parameter. -.RE - -.sp -.ne 2 -.na -\fB\fBIPV6_TCLASS\fR\fR -.ad -.RS 21n -Set the traffic class associated with outgoing packets. The parameter is an -integer. If the parameter is less then -1 or greater then 256, EINVAL is -returned. If the parameter is equal to -1, use the default. If the parameter is -between 0 and 255 inclusive, use that value. -.RE - -.sp -.LP -The following options affect the socket's multicast behavior: -.sp -.ne 2 -.na -\fB\fBIPV6_JOIN_GROUP\fR\fR -.ad -.RS 28n -Join a multicast group. Takes a \fBstruct\fR \fBipv6_mreq\fR as the parameter; -the structure contains a multicast address and an interface index. -.RE - -.sp -.ne 2 -.na -\fB\fBIPV6_LEAVE_GROUP\fR\fR -.ad -.RS 28n -Leave a multicast group. Takes a \fBstruct\fR \fBipv6_mreq\fR as the parameter; -the structure contains a multicast address and an interface index. -.RE - -.sp -.ne 2 -.na -\fB\fBMCAST_JOIN_GROUP\fR\fR -.ad -.RS 28n -Functionally equivalent to IPV6_JOIN_GROUP. Takes a \fBstruct\fR -\fBgroup_req\fR as the parameter. The structure contains a multicast address -and an interface index. -.RE - -.sp -.ne 2 -.na -\fB\fBMCAST_BLOCK_SOURCE\fR\fR -.ad -.RS 28n -Block multicast packets on a particular multicast group whose source address -matches the given source address. The specified group must be joined previously -using IPV6_JOIN_GROUP or MCAST_JOIN_GROUP. Takes a \fBstruct\fR -\fBgroup_source_req\fR as the parameter. The structure contains an interface -index, a multicast address, and a source address. -.RE - -.sp -.ne 2 -.na -\fB\fBMCAST_UNBLOCK_SOURCE\fR\fR -.ad -.RS 28n -Unblock multicast packets which were previously blocked using -MCAST_BLOCK_SOURCE. Takes a \fBstruct\fR \fBgroup_source_req\fR as the -parameter. The structure contains an interface index, a multicast address, and -a source address. -.RE - -.sp -.ne 2 -.na -\fB\fBMCAST_LEAVE_GROUP\fR\fR -.ad -.RS 28n -Functionally equivalent to IPV6_LEAVE_GROUP. Takes a \fBstruct\fR -\fBgroup_req\fR as the parameter. The structure contains a multicast address -and an interface index. -.RE - -.sp -.ne 2 -.na -\fB\fBMCAST_JOIN_SOURCE_GROUP\fR\fR -.ad -.RS 28n -Begin receiving packets for the given multicast group whose source address -matches the specified address. Takes a \fBstruct\fR \fBgroup_source_req\fR as -the parameter. The structure contains an interface index, a multicast address, -and a source address. -.RE - -.sp -.ne 2 -.na -\fB\fBMCAST_LEAVE_SOURCE_GROUP\fR\fR -.ad -.RS 28n -Stop receiving packets for the given multicast group whose source address -matches the specified address. Takes a \fBstruct\fR \fBgroup_source_req\fR as -the parameter. The structure contains an interface index, a multicast address, -and a source address. -.RE - -.sp -.ne 2 -.na -\fB\fBIPV6_MULTICAST_IF\fR\fR -.ad -.RS 28n -The outgoing interface for multicast packets. This option takes an integer as -an argument; the integer is the interface index of the selected interface. -.RE - -.sp -.ne 2 -.na -\fB\fBIPV6_MULTICAST_HOPS\fR\fR -.ad -.RS 28n -Default hop limit for multicast datagrams. This option takes an integer as an -argument. Its value becomes the new default value for \fBip6_hops\fR that -\fBIPv6\fR will use on outgoing multicast datagrams sent from that socket. The -initial default is \fB1\fR. -.RE - -.sp -.ne 2 -.na -\fB\fBIPV6_MULTICAST_LOOP\fR\fR -.ad -.RS 28n -Loopback for multicast datagrams. Normally multicast datagrams are delivered to -members on the sending host. Setting the unsigned character argument to 0 will -cause the opposite behavior. -.RE - -.sp -.LP -The multicast socket options can be used with any datagram socket type in the -\fBIPv6\fR family. -.sp -.LP -At the socket level, the socket option \fBSO_DONTROUTE\fR may be applied. This -option forces datagrams being sent to bypass routing and forwarding by forcing -the \fBIPv6\fR hoplimit field to \fB1\fR, meaning that the packet will not be -forwarded by routers. -.sp -.LP -Raw \fBIPv6\fR datagrams can also be sent and received using the \fBTLI\fR -connectionless primitives. -.sp -.LP -Datagrams flow through the \fBIPv6\fR layer in two directions: from the network -\fIup\fR to user processes and from user processes \fIdown\fR to the network. -Using this orientation, \fBIPv6\fR is layered \fIabove\fR the network interface -drivers and \fIbelow\fR the transport protocols such as \fBUDP\fR and -\fBTCP\fR. The Internet Control Message Protocol (\fBICMPv6\fR) for the -Internet Protocol Version 6 (\fBIPv6\fR) is logically a part of \fBIPv6\fR. See -\fBicmp6\fR(7P). -.sp -.LP -Unlike \fBIP\fR, \fBIPv6\fR provides no checksum of the \fBIPv6\fR header. Also -unlike \fBIP\fR, upper level protocol checksums are required. \fBIPv6\fR will -compute the \fBULP\fR/data portion checksum if the checksum field contains a -zero (see \fBIPV6_CHECKSUM\fR option above). -.sp -.LP -\fBIPv6\fR extension headers in received datagrams are processed in the -\fBIPv6\fR layer according to the protocol specification. Currently recognized -\fBIPv6\fR extension headers include hop-by-hop options header, destination -options header, routing header (currently, only type 0 routing headers are -supported), and fragment header. -.sp -.LP -By default, the IPv6 layer will not forward IPv6 packets that are not addressed -to it. This behavior can be overridden by using \fBrouteadm\fR(1M) to enable -the ipv6-forwarding option. IPv6 forwarding is configured at boot time based on -the setting of \fBrouteadm\fR(1M)'s ipv6-forwarding option. -.sp -.LP -For backwards compatibility, IPv6 forwarding can be enabled or disabled using -\fBndd\fR(1M)'s ip_forwarding variable. It is set to 1 if IPv6 forwarding is -enabled, or 0 if it is disabled. -.sp -.LP -Additionally, finer-grained forwarding can be configured in IPv6. Each -interface can be configured to forward IPv6 packets by setting the IFF_ROUTER -interface flag. This flag can be set and cleared using \fBifconfig\fR(1M)'s -router and -router options. If an interface's IFF_ROUTER flag is set, packets -can be forwarded to or from the interface. If it is clear, packets will neither -be forwarded from this interface to others, nor forwarded to this interface. -Setting the ip6_forwarding variable sets all of the IPv6 interfaces' IFF_ROUTER -flags. -.sp -.LP -For backwards compatibility, each interface creates an -\fB<ifname>ip6_forwarding /dev/ip6\fR variable that can be modified using -\fBndd\fR(1M). An interface's \fB:ip6_forwarding ndd\fR variable is a boolean -variable that mirrors the status of its IFF_ROUTER interface flag. It is set to -1 if the flag is set, or 0 if it is clear. This interface specific -\fB<ifname>:ip6_forwarding ndd\fR variable is obsolete and may be removed in a -future release of Solaris. The \fBifconfig\fR(1M) router and -router interfaces -are preferred. -.sp -.LP -The \fBIPv6\fR layer will send an \fBICMP6\fR message back to the source host -in many cases when it receives a datagram that can not be handled. A -"\fBtime\fR \fBexceeded\fR" \fBICMP6\fR message will be sent if the -\fBip6_hops\fR field in the \fBIPv6\fR header drops to zero in the process of -forwarding a datagram. A "\fBdestination\fR \fBunreachable\fR" message will be -sent by a router or by the originating host if a datagram can not be sent on -because there is no route to the final destination; it will be sent by a router -when it encounters a firewall prohibition; it will be sent by a destination -node when the transport protocol (that is, \fBTCP\fR) has no listener. A -"\fBpacket\fR \fBtoo\fR \fBbig\fR" message will be sent by a router if the -packet is larger than the \fBMTU\fR of the outgoing link (this is used for Path -\fBMTU\fR Discovery). A "\fBparameter\fR \fBproblem\fR" message will be sent if -there is a problem with a field in the \fBIPv6\fR header or any of the -\fBIPv6\fR extension headers such that the packet cannot be fully processed. -.sp -.LP -The \fBIPv6\fR layer supports fragmentation and reassembly. Datagrams are -fragmented on output if the datagram is larger than the maximum transmission -unit (\fBMTU\fR) of the network interface. Fragments of received datagrams are -dropped from the reassembly queues if the complete datagram is not -reconstructed within a short time period. -.sp -.LP -Errors in sending discovered at the network interface driver layer are passed -by IPv6 back up to the user process. -.SH SEE ALSO -\fBsvcs\fR(1), \fBndd\fR(1M), \fBrouteadm\fR(1M), \fBsvcadm\fR(1M), -\fBread\fR(2), \fBwrite\fR(2), \fBbind\fR(3SOCKET), \fBconnect\fR(3SOCKET), -\fBgetsockopt\fR(3SOCKET), \fBrecv\fR(3SOCKET), \fBrecvmsg\fR(3SOCKET), -\fBsend\fR(3SOCKET), \fBsendmsg\fR(3SOCKET), \fBsetsockopt\fR(3SOCKET), -\fBdefaultrouter\fR(4), \fBsmf\fR(5), \fBicmp6\fR(7P), \fBif_tcp\fR(7P), -\fBipsec\fR(7P), \fBinet6\fR(7P), \fBrouting\fR(7P), \fBtcp\fR(7P), -\fBudp\fR(7P) -.sp -.LP -Deering, S. and Hinden, B. \fI RFC 2460, Internet Protocol, Version 6 (IPv6) -Specification\fR. The Internet Society. December, 1998. -.sp -.LP -Stevens, W., and Thomas, M. \fIRFC 2292, Advanced Sockets API for IPv6\fR. -Network Working Group. February 1998. -.SH DIAGNOSTICS -A socket operation may fail with one of the following errors returned: -.sp -.ne 2 -.na -\fB\fBEPROTONOSUPPORT\fR\fR -.ad -.RS 19n -Unsupported protocol (for example, IPPROTO_RAW.) -.RE - -.sp -.ne 2 -.na -\fB\fBEACCES\fR\fR -.ad -.RS 19n -A \fBbind()\fR operation was attempted with a "reserved" port number and the -effective user ID of the process was not the privileged user. -.RE - -.sp -.ne 2 -.na -\fB\fBEADDRINUSE\fR\fR -.ad -.RS 19n -A \fBbind()\fR operation was attempted on a socket with a network address/port -pair that has already been bound to another socket. -.RE - -.sp -.ne 2 -.na -\fB\fBEADDRNOTAVAIL\fR\fR -.ad -.RS 19n -A \fBbind()\fR operation was attempted for an address that is not configured on -this machine. -.RE - -.sp -.ne 2 -.na -\fB\fBEINVAL\fR\fR -.ad -.RS 19n -A \fBsendmsg()\fR operation with a non-NULL \fBmsg_accrights\fR was attempted. -.RE - -.sp -.ne 2 -.na -\fB\fBEINVAL\fR\fR -.ad -.RS 19n -A \fBgetsockopt()\fR or \fBsetsockopt()\fR operation with an unknown socket -option name was given. -.RE - -.sp -.ne 2 -.na -\fB\fBEINVAL\fR\fR -.ad -.RS 19n -A \fBgetsockopt()\fR or \fBsetsockopt()\fR operation was attempted with the -\fBIPv6\fR option field improperly formed; an option field was shorter than the -minimum value or longer than the option buffer provided; the value in the -option field was invalid. -.RE - -.sp -.ne 2 -.na -\fB\fBEISCONN\fR\fR -.ad -.RS 19n -A \fBconnect()\fR operation was attempted on a socket on which a -\fBconnect()\fR operation had already been performed, and the socket could not -be successfully disconnected before making the new connection. -.RE - -.sp -.ne 2 -.na -\fB\fBEISCONN\fR\fR -.ad -.RS 19n -A \fBsendto()\fR or \fBsendmsg()\fR operation specifying an address to which -the message should be sent was attempted on a socket on which a \fBconnect()\fR -operation had already been performed. -.RE - -.sp -.ne 2 -.na -\fB\fBEMSGSIZE\fR\fR -.ad -.RS 19n -A \fBsend()\fR, \fBsendto()\fR, or \fBsendmsg()\fR operation was attempted to -send a datagram that was too large for an interface, but was not allowed to be -fragmented (such as broadcasts). -.RE - -.sp -.ne 2 -.na -\fB\fBENETUNREACH\fR\fR -.ad -.RS 19n -An attempt was made to establish a connection via \fBconnect()\fR, or to send a -datagram by means of \fBsendto()\fR or \fBsendmsg()\fR, where there was no -matching entry in the routing table; or if an \fBICMP\fR "\fBdestination -unreachable\fR" message was received. -.RE - -.sp -.ne 2 -.na -\fB\fBENOTCONN\fR\fR -.ad -.RS 19n -A \fBsend()\fR or \fBwrite()\fR operation, or a \fBsendto()\fR or -\fBsendmsg()\fR operation not specifying an address to which the message should -be sent, was attempted on a socket on which a \fBconnect()\fR operation had not -already been performed. -.RE - -.sp -.ne 2 -.na -\fB\fBENOBUFS\fR\fR -.ad -.RS 19n -The system ran out of memory for fragmentation buffers or other internal data -structures. -.RE - -.sp -.ne 2 -.na -\fB\fBENOMEM\fR\fR -.ad -.RS 19n -The system was unable to allocate memory for an \fBIPv6\fR socket option or -other internal data structures. -.RE - -.sp -.ne 2 -.na -\fB\fBENOPROTOOPT\fR\fR -.ad -.RS 19n -An \fBIP\fR socket option was attempted on an \fBIPv6\fR socket, or an -\fBIPv6\fR socket option was attempted on an \fBIP\fR socket. -.RE - -.sp -.ne 2 -.na -\fB\fBENOPROTOOPT\fR\fR -.ad -.RS 19n -Invalid socket type for the option. -.RE - -.SH NOTES -Applications using the sockets \fBAPI\fR must use the Advanced Sockets -\fBAPI\fR for \fBIPv6\fR (\fIRFC 2292\fR) to see elements of the inbound -packet's \fBIPv6\fR header or extension headers. -.sp -.LP -The \fBip6\fR service is managed by the service management facility, -\fBsmf\fR(5), under the service identifier: -.sp -.in +2 -.nf -svc:/network/initial:default -.fi -.in -2 -.sp - -.sp -.LP -Administrative actions on this service, such as enabling, disabling, or -requesting restart, can be performed using \fBsvcadm\fR(1M). The service's -status can be queried using the \fBsvcs\fR(1) command. diff --git a/usr/src/man/man7p/ipsec.7p b/usr/src/man/man7p/ipsec.7p deleted file mode 100644 index 75fe2f259e..0000000000 --- a/usr/src/man/man7p/ipsec.7p +++ /dev/null @@ -1,361 +0,0 @@ -'\" te -.\" Copyright (C) 2009, Sun Microsystems, Inc. All Rights Reserved -.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License. You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. -.\" See the License for the specific language governing permissions and limitations under the License. When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with -.\" the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner] -.TH IPSEC 7P "Sep 25, 2009" -.SH NAME -ipsec \- Internet Protocol Security Architecture -.SH DESCRIPTION -.sp -.LP -The \fBIP\fR Security Architecture (IPsec) provides protection for \fBIP\fR -datagrams. The protection can include confidentiality, strong integrity of the -data, partial sequence integrity (replay protection), and data authentication. -\fBIPsec\fR is performed inside the \fBIP\fR processing, and it can be applied -with or without the knowledge of an Internet application. -.sp -.LP -IPsec applies to both IPv4 and IPv6. See \fBip\fR(7P) and \fBip6\fR(7P). -.SS "Protection Mechanisms" -.sp -.LP -IPsec provides two mechanisms for protecting data. The Authentication Header -(\fBAH\fR) provides strong integrity, replay protection, and data -authentication. \fBAH\fR protects as much of the \fBIP\fR datagram as it can. -\fBAH\fR cannot protect fields that change nondeterministically between sender -and receiver. -.sp -.LP -The Encapsulating Security Payload (\fBESP\fR) provides confidentiality over -what it encapsulates, as well as the services that \fBAH\fR provides, but only -over that which it encapsulates. \fBESP\fR's authentication services are -optional, which allow \fBESP\fR and \fBAH\fR to be used together on the same -datagram without redundancy. -.sp -.LP -Authentication and encryption algorithms are used for IPsec. Authentication -algorithms produce an integrity checksum value or "digest"based on the data and -a key. Encryption algorithms operate on data in units of a "block size". -.SS "NAT Traversal" -.sp -.LP -IPsec's ESP can also encapsulate itself in UDP if IKE (see \fBin.iked\fR(1M)) -discovers a Network Address Translator (NAT) between two communicating -endpoints. -.sp -.LP -A UDP socket can be specified as a NAT-Traversal endpoint. See \fBudp\fR(7P) -for details. -.SS "Security Associations" -.sp -.LP -\fBAH\fR and \fBESP\fR use Security Associations (\fBSA\fR). SA's are entities -that specify security properties from one host to another. Two communicating -machines require two \fBSA\fRs (at a minimum) to communicate securely. However, -communicating machines that use multicast can share the same multicast -\fBSA\fR. \fBSA\fRs are managed through the \fBpf_key\fR(7P) interface. For -IPv4, automatic \fBSA\fR management is available through the Internet Key -Exchange (IKE), as implemented by \fBin.iked\fR(1M). A command-line front-end -is available by means of \fBipseckey\fR(1M). An IPsec \fBSA\fR is identified by -a tuple of <\fBAH\fR or \fBESP\fR, destination \fBIP\fR address, and -\fBSPI\fR>. The Security Parameters Index (\fBSPI\fR) is an arbitrary 32-bit -value that is transmitted on the wire with an \fBAH\fR or \fBESP\fR packet. See -\fBipsecah\fR(7P) or \fBipsecesp\fR(7P) for an explanation about where the -\fBSPI\fR falls in a protected packet. -.SS "Protection Policy and Enforcement Mechanisms" -.sp -.LP -Mechanism and policy are separate. The policy for applying IPsec is enforced on -a system-wide or per-socket level. Configuring system-wide policy and -per-tunnel policy (see Transport Mode and Tunnel Mode sections) is done via the -\fBipsecconf\fR(1M) command. Configuring per-socket policy is discussed later -in this section. -.sp -.LP -System-wide IPsec policy is applied to incoming and outgoing datagrams. Some -additional rules can be applied to outgoing datagrams because of the additional -data known by the system. Inbound datagrams can be accepted or dropped. The -decision to drop or accept an inbound datagram is based on several criteria -which sometimes overlap or conflict. Conflict resolution is resolved by which -rule is parsed first, with one exception: if a policy entry states that traffic -should bypass all other policy, it is automatically be accepted. Outbound -datagrams are sent with or without protection. Protection may (or may not) -indicate specific algorithms. If policy normally would protect a datagram, it -can be bypassed either by an exception in system-wide policy or by requesting a -bypass in per-socket policy. -.sp -.LP -Intra-machine traffic policies are enforced, but actual security mechanisms are -not applied. Instead, the outbound policy on an intra-machine packet translates -into an inbound packet with those mechanisms applied. -.sp -.LP -IPsec policy is enforced in the \fBip\fR(7P) driver. Several \fBndd\fR tunables -for \fB/dev/ip\fR affect policy enforcement, including: -.sp -.ne 2 -.na -\fBicmp_accept_clear_messages\fR -.ad -.RS 30n -If equal to 1 (the default), allow certain cleartext icmp messages to bypass -policy. For ICMP echo requests ("ping"messages), protect the response like the -request. If zero, treat icmp messages like other IP traffic. -.RE - -.sp -.ne 2 -.na -\fBigmp_accept_clear_messages\fR -.ad -.RS 30n -If 1, allow inbound cleartext IGMP messages to bypass IPsec policy. -.RE - -.sp -.ne 2 -.na -\fBpim_accept_clear_messages\fR -.ad -.RS 30n -If 1, allow inbound cleartext PIM messages to bypass IPsec policy. -.RE - -.sp -.ne 2 -.na -\fBipsec_policy_log_interval\fR -.ad -.RS 30n -IPsec logs policy failures and errors to \fB/var/adm/messages\fR. To prevent -syslog from being overloaded, the IPsec kernel modules limit the rate at which -errors can be logged. You can query/set ipsec_policy_log_interval using -\fBndd\fR(1M). The value is in milliseconds. Only one message can be logged per -interval. -.RE - -.SS "Transport Mode and Tunnel Mode" -.sp -.LP -If IPsec is used on a tunnel, Tunnel Mode IPsec can be used to protect distinct -flows within a tunnel or to cause packets that do not match per-tunnel policy -to drop. System-wide policy is always Transport Mode. A tunnel can use -Transport Mode IPsec or Tunnel Mode IPsec. -.SS "Per-Socket Policy" -.sp -.LP -The \fBIP_SEC_OPT\fR or \fBIPV6_SEC_OPT\fR socket option is used to set -per-socket IPsec policy. The structure used for an \fBIP_SEC_OPT\fR request -is: -.sp -.in +2 -.nf -typedef struct ipsec_req { - uint_t ipsr_ah_req; /* AH request */ - uint_t ipsr_esp_req; /* ESP request */ - uint_t ipsr_self_encap_req; /* Self-Encap request */ - uint8_t ipsr_auth_alg; /* Auth algs for AH */ - uint8_t ipsr_esp_alg; /* Encr algs for ESP */ - uint8_t ipsr_esp_auth_alg; /* Auth algs for ESP */ -} ipsec_req_t; -.fi -.in -2 - -.sp -.LP -The IPsec request has fields for both \fBAH\fR and \fBESP\fR. Algorithms may or -may not be specified. The actual request for \fBAH\fR or \fBESP\fR services can -take one of the following values: -.sp -.ne 2 -.na -\fB\fBIPSEC_PREF_NEVER\fR\fR -.ad -.RS 23n -Bypass all policy. Only the superuser may request this service. -.RE - -.sp -.ne 2 -.na -\fB\fBIPSEC_PREF_REQUIRED\fR\fR -.ad -.RS 23n -Regardless of other policy, require the use of the IPsec service. -.RE - -.sp -.LP -The following value can be logically ORed to an \fBIPSEC_PREF_REQUIRED\fR -value: -.sp -.ne 2 -.na -\fB\fBIPSEC_PREF_UNIQUE\fR\fR -.ad -.RS 21n -Regardless of other policy, enforce a unique \fBSA\fR for traffic originating -from this socket. -.RE - -.sp -.LP -In the event \fBIP\fR options not normally encapsulated by \fBESP\fR need to -be, the \fBipsec_self_encap_req\fR is used to add an additional \fBIP\fR header -outside the original one. Algorithm values from <\fBnet/pfkeyv2.h\fR> are as -follows: -.sp -.ne 2 -.na -\fB\fBSADB_AALG_MD5HMAC\fR\fR -.ad -.RS 24n -Uses the MD5-HMAC (\fIRFC 2403\fR) algorithm for authentication. -.RE - -.sp -.ne 2 -.na -\fB\fBSADB_AALG_SHA1HMAC\fR\fR -.ad -.RS 24n -Uses the SHA1-HMAC (\fIRFC 2404)\fR algorithm for authentication. -.RE - -.sp -.ne 2 -.na -\fB\fBSADB_EALG_DESCBC\fR\fR -.ad -.RS 24n -Uses the \fBDES\fR (\fIRFC 2405\fR) algorithm for encryption. -.RE - -.sp -.ne 2 -.na -\fB\fBSADB_EALG_3DESCBC\fR\fR -.ad -.RS 24n -Uses the Triple \fBDES \fR (\fIRFC 2451\fR) algorithm for encryption. -.RE - -.sp -.ne 2 -.na -\fB\fBSADB_EALG_BLOWFISH\fR\fR -.ad -.RS 24n -Uses the Blowfish (\fIRFC 2451\fR) algorithm for encryption. -.RE - -.sp -.ne 2 -.na -\fB\fBSADB_EALG_AES\fR\fR -.ad -.RS 24n -Uses the Advanced Encryption Standard algorithm for encryption. -.RE - -.sp -.ne 2 -.na -\fB\fBSADB_AALG_SHA256HMAC\fR\fR -.ad -.br -.na -\fB\fBSADB_AALG_SHA384HMAC\fR\fR -.ad -.br -.na -\fB\fBSADB_AALG_SHA512HMAC\fR\fR -.ad -.RS 24n -Uses the SHA2 hash algorithms with HMAC (\fIRFC 4868\fR)for authentication. -.RE - -.sp -.LP -An application should use either the \fBgetsockopt\fR(3SOCKET) or the -\fBsetsockopt\fR(3SOCKET) call to manipulate IPsec requests. For example: -.sp -.in +2 -.nf -#include <sys/socket.h> -#include <netinet/in.h> -#include <net/pfkeyv2.h> /* For SADB_*ALG_* */ -/* .... socket setup skipped */ -rc = setsockopt(s, IPPROTO_IP, IP_SEC_OPT, - (const char *)&ipsec_req, sizeof (ipsec_req_t)); -.fi -.in -2 - -.SH SECURITY -.sp -.LP -While IPsec is an effective tool in securing network traffic, it will not make -security problems disappear. Security issues beyond the mechanisms that IPsec -offers may be discussed in similar "Security" or "Security Consideration" -sections within individual reference manual pages. -.sp -.LP -While a non-root user cannot bypass IPsec, a non-root user can set policy to be -different from the system-wide policy. For ways to prevent this, consult the -\fBndd\fR(1M) variables in \fB/dev/ip\fR. -.SH ATTRIBUTES -.sp -.LP -See \fBattributes\fR(5) for descriptions of the following attributes: -.sp - -.sp -.TS -box; -c | c -l | l . -ATTRIBUTE TYPE ATTRIBUTE VALUE -_ -Interface Stability Committed -.TE - -.SH SEE ALSO -.sp -.LP -\fBin.iked\fR(1M), \fBipsecconf\fR(1M), \fBipseckey\fR(1M), \fBndd\fR(1M), -\fBgetsockopt\fR(3SOCKET), \fBsetsockopt\fR(3SOCKET), \fBattributes\fR(5), -\fBinet\fR(7P), \fBip\fR(7P), \fBip6\fR(7P), \fBipsecah\fR(7P), -\fBipsecesp\fR(7P), \fBpf_key\fR(7P), \fBudp\fR(7P) -.sp -.LP -Kent, S., and Atkinson, R., \fIRFC 2401, Security Architecture for the Internet -Protocol\fR, The Internet Society, 1998. -.sp -.LP -Kent, S. and Atkinson, R., \fIRFC 2406, IP Encapsulating Security Payload -(ESP)\fR, The Internet Society, 1998. -.sp -.LP -Madson, C., and Doraswamy, N., \fIRFC 2405, The ESP DES-CBC Cipher Algorithm -with Explicit IV\fR, The Internet Society, 1998. -.sp -.LP -Madsen, C. and Glenn, R., \fIRFC 2403, The Use of HMAC-MD5-96 within ESP and -AH\fR, The Internet Society, 1998. -.sp -.LP -Madsen, C. and Glenn, R., \fIRFC 2404, The Use of HMAC-SHA-1-96 within ESP and -AH\fR, The Internet Society, 1998. -.sp -.LP -Pereira, R. and Adams, R., \fIRFC 2451, The ESP CBC-Mode Cipher Algorithms\fR, -The Internet Society, 1998. -.sp -.LP -Kelly, S. and Frankel, S., \fIRFC 4868, Using HMAC-SHA-256, HMAC-SHA-384, and -HMAC-SHA-512 with IPsec\fR, 2007. -.sp -.LP -Huttunen, A., Swander, B., Volpe, V., DiBurro, L., Stenberg, \fIM., RFC 3948, -UDP Encapsulation of IPsec ESP Packets\fR, The Internet Society, 2005. diff --git a/usr/src/man/man7p/ipsecah.7p b/usr/src/man/man7p/ipsecah.7p deleted file mode 100644 index 428cc3ea90..0000000000 --- a/usr/src/man/man7p/ipsecah.7p +++ /dev/null @@ -1,72 +0,0 @@ -'\" te -.\" Copyright (C) 2009, Sun Microsystems, Inc. All Rights Reserved -.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License. You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. -.\" See the License for the specific language governing permissions and limitations under the License. When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with -.\" the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner] -.TH IPSECAH 7P "Sep 25, 2009" -.SH NAME -ipsecah, AH \- IPsec Authentication Header -.SH SYNOPSIS -.LP -.nf -\fBdrv/ipsecah\fR -.fi - -.SH DESCRIPTION -.sp -.LP -The \fBipsecah\fR module (\fBAH\fR) provides strong integrity, authentication, -and partial sequence integrity (replay protection) to \fBIP\fR datagrams. -\fBAH\fR protects the parts of the \fBIP\fR datagram that can be predicted by -the sender as it will be received by the receiver. For example, the \fBIP\fR -\fBTTL\fR field is not a predictable field, and is not protected by \fBAH\fR. -.sp -.LP -\fBAH\fR is inserted between the \fBIP\fR header and the transport header. The -transport header can be \fBTCP\fR, \fBUDP\fR, \fBICMP\fR, or another \fBIP\fR -header, if tunnels are being used. -.SS "AH Device" -.sp -.LP -AH is implemented as a module that is auto-pushed on top of IP. The entry -\fB/dev/ipsecah\fR is used for tuning AH with \fBndd\fR(1M). -.SS "Authentication Algorithms" -.sp -.LP -Current authentication algorithms supported include HMAC-MD5 and HMAC-SHA-1. -Each authentication algorithm has its own key size and key format properties. -You can obtain a list of authentication algorithms and their properties by -using the \fBipsecalgs\fR(1M) command. You can also use the functions described -in the \fBgetipsecalgbyname\fR(3NSL) man page to retrieve the properties of -algorithms. -.SS "Security Considerations" -.sp -.LP -Without replay protection enabled, \fBAH\fR is vulnerable to replay attacks. -\fBAH\fR does not protect against eavesdropping. Data protected with \fBAH\fR -can still be seen by an adversary. -.SH ATTRIBUTES -.sp -.LP -See \fBattributes\fR(5) for descriptions of the following attributes: -.sp - -.sp -.TS -box; -c | c -l | l . -ATTRIBUTE TYPE ATTRIBUTE VALUE -Interface Stability Committed -.TE - -.SH SEE ALSO -.sp -.LP -\fBipsecalgs\fR(1M), \fBipsecconf\fR(1M), \fBndd\fR(1M), \fBattributes\fR(5), -\fBgetipsecalgbyname\fR(3NSL), \fBip\fR(7P), \fBipsec\fR(7P), -\fBipsecesp\fR(7P) -.sp -.LP -Kent, S. and Atkinson, R. \fIRFC 2402, IP Authentication Header\fR, The -Internet Society, 1998. diff --git a/usr/src/man/man7p/ipsecesp.7p b/usr/src/man/man7p/ipsecesp.7p deleted file mode 100644 index 9123e58bc9..0000000000 --- a/usr/src/man/man7p/ipsecesp.7p +++ /dev/null @@ -1,81 +0,0 @@ -'\" te -.\" Copyright (C) 2003, Sun Microsystems, Inc. All Rights Reserved -.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License. -.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License. -.\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner] -.TH IPSECESP 7P "May 18, 2003" -.SH NAME -ipsecesp, ESP \- IPsec Encapsulating Security Payload -.SH SYNOPSIS -.LP -.nf -\fBdrv/ipsecesp\fR -.fi - -.SH DESCRIPTION -.sp -.LP -The \fBipsecesp\fR module provides confidentiality, integrity, authentication, -and partial sequence integrity (replay protection) to \fBIP\fR datagrams. The -encapsulating security payload (\fBESP\fR) encapsulates its data, enabling it -to protect data that follows in the datagram. For \fBTCP\fR packets, \fBESP\fR -encapsulates the \fBTCP\fR header and its data only. If the packet is an -\fBIP\fR in \fBIP\fR datagram, \fBESP\fR protects the inner \fBIP\fR datagram. -Per-socket policy allows "self-encapsulation" so \fBESP\fR can encapsulate -\fBIP\fR options when necessary. See \fBipsec\fR(7P). -.sp -.LP -Unlike the authentication header (\fBAH\fR), \fBESP\fR allows multiple -varieties of datagram protection. (Using a single datagram protection form can -expose vulnerabilities.) For example, only \fBESP\fR can be used to provide -confidentiality. But protecting confidentiality alone exposes vulnerabilities -in both replay attacks and cut-and-paste attacks. Similarly, if \fBESP\fR -protects only integrity and does not fully protect against eavesdropping, it -may provide weaker protection than \fBAH\fR. See \fBipsecah\fR(7P). -.SS "ESP Device" -.sp -.LP -\fBESP\fR is implemented as a module that is auto-pushed on top of \fBIP\fR. -Use the \fB/dev/ipsecesp\fR entry to tune \fBESP\fR with \fBndd\fR(1M). -.SS "Algorithms" -.sp -.LP -\fBESP\fRuses encryption and authentication algorithms. Authentication -algorithms include HMAC-MD5 and HMAC-SHA-1. Encryption algorithms include DES, -Triple-DES, Blowfish and AES. Each authentication and encryption algorithm -contain key size and key format properties. You can obtain a list of -authentication and encryption algorithms and their properties by using the -\fBipsecalgs\fR(1M) command. You can also use the functions described in the -\fBgetipsecalgbyname\fR(3NSL) man page to retrieve the properties of -algorithms. Because of export laws in the United States, not all encryption -algorithms are available outside of the United States. -.SS "Security Considerations" -.sp -.LP -\fBESP\fR without authentication exposes vulnerabilities to cut-and-paste -cryptographic attacks as well as eavesdropping attacks. Like AH, \fBESP\fR is -vulnerable to eavesdropping when used without confidentiality. -.SH ATTRIBUTES -.sp -.LP -See \fBattributes\fR(5) for descriptions of the following attributes: -.sp - -.sp -.TS -box; -c | c -l | l . -ATTRIBUTE TYPE ATTRIBUTE VALUE -Interface Stability Evolving -.TE - -.SH SEE ALSO -.sp -.LP -\fBipsecalgs\fR(1M), \fBipsecconf\fR(1M), \fBndd\fR(1M), \fBattributes\fR(5), -\fBgetipsecalgbyname\fR(3NSL), \fBip\fR(7P), \fBipsec\fR(7P), \fBipsecah\fR(7P) -.sp -.LP -Kent, S. and Atkinson, R. \fIRFC 2406, IP Encapsulating Security Payload -(ESP)\fR, The Internet Society, 1998. diff --git a/usr/src/man/man7p/ndp.7p b/usr/src/man/man7p/ndp.7p deleted file mode 100644 index 28d4d2a1d4..0000000000 --- a/usr/src/man/man7p/ndp.7p +++ /dev/null @@ -1,355 +0,0 @@ -.\" -.\" This file and its contents are supplied under the terms of the -.\" Common Development and Distribution License ("CDDL"), version 1.0. -.\" You may only use this file in accordance with the terms of version -.\" 1.0 of the CDDL. -.\" -.\" A full copy of the text of the CDDL should have accompanied this -.\" source. A copy of the CDDL is also available via the Internet at -.\" http://www.illumos.org/license/CDDL. -.\" -.\" -.\" Copyright (c) 2015, Joyent, Inc. All rights reserved. -.\" -.Dd Sep 02, 2015 -.Dt NDP 7P -.Os -.Sh NAME -.Nm ndp , -.Nm NDP -.Nd Neighbor Discovery Protocol -.Sh SYNOPSIS -.In sys/socket.h -.In sys/sockio.h -.In netinet/in.h -.In net/if.h -.Bd -literal -s = socket(PF_INET6, SOCK_DGRAM, 0); - -struct lifreq lifr; -ioctl(s, SIOCLIFGETND, &lifr); -ioctl(s, SIOCLIFSETND, &lifr); -ioctl(s, SIOCLIFDELND, &lifr); -.Ed -.Sh DESCRIPTION -The Neighbor Discovery Protocol (NDP) is a protocol used to distribute and -request information about neighboring IPv6 systems on the local network, much -like -.Xr ARP 7P -for IPv4. -NDP is also responsible for spreading information about the network gateway and -how hosts should configure themselves -.Pq see Xr in.ndpd 1M for more on how this happens . -.Sh APPLICATION PROGRAMMING INTERFACE -The operating system provides several ioctls to help manipulate the mappings -obtained through NDP. -They are -.Sy SIOCLIFGETND , -.Sy SIOCLIFSETND , -and -.Sy SIOCLIFDELND , -for getting, setting, and deleting respectively. -Each of these ioctls takes a -.Vt struct lifreq -.Pq see Xr if 7P for details , -where the -.Fa lifr_lifru -field is of type -.Vt struct lif_nd_req : -.Bd -literal -offset 2m -typedef struct lif_nd_req { - struct sockaddr_storage lnr_addr; - uint8_t lnr_state_create; - uint8_t lnr_state_same_lla; - uint8_t lnr_state_diff_lla; - int lnr_hdw_len; - int lnr_flags; - int lnr_pad0; - char lnr_hdw_addr[ND_MAX_HDW_LEN]; -} lif_nd_req_t; -.Ed -.Pp -The -.Fa lnr_addr -field should be filled in with an IPv6 address -.Pq see Xr sockaddr_in6 3SOCKET , -and the -.Fa lnr_hdw_addr -is the link-layer address of length -.Fa lnr_hdw_len . -.Pp -State flags for -.Fa lnr_state_create , -.Fa lnr_state_same_lla , -and -.Fa lnr_state_diff_lla -can be set to one of the following values: -.Bl -tag -offset indent -width 16m -.It Sy ND_UNCHANGED -For ioctls that don't modify state -.It Sy ND_INCOMPLETE -Address resolution is currently in progress -.It Sy ND_REACHABLE -The link-layer address has recently been reachable -.It Sy ND_STALE -The link-layer address may be unreachable, and the system shouldn't do anything -.It Sy ND_DELAY -This entry hasn't yet started sending Neighbor Solicitations -.It Sy ND_PROBE -The operating system is currently sending out Neighbor Solicitations for the address -.It Sy ND_UNREACHABLE -The link-layer address is unreachable, and this entry is going to be deleted. -.El -.sp -When creating a new entry, the only valid values for -.Fa lnr_state_create -are -.Sy ND_REACHABLE -and -.Sy ND_STALE . -Any other value will return -.Sy EINVAL . -The -.Fa lnr_state_same_lla -and -.Fa lnr_state_diff_lla -fields are reserved for future use and can be safely set to -.Sy ND_UNCHANGED -and -.Sy ND_STALE -respectively. -.Pp -Flags that can be placed in -.Fa lnr_flags -are: -.Bl -tag -offset indent -width 16m -.It Sy NDF_ISROUTER_ON -Mark this entry as being a router. -This will cause Neighbor Advertisements for this address to be sent with the -R-bit (Router). -.It Sy NDF_ISROUTER_OFF -If this entry was flagged as being a router, remove the flag. -.It Sy NDF_ANYCAST_ON -Mark this entry as being for an anycast address. -This prevents sending Neighbor Advertisements with the O-bit (Override). -.It Sy NDF_ANYCAST_OFF -If this entry was flagged as an anycast address, remove the flag. -.It Sy NDF_STATIC -Prevent this entry from being deleted by the system. -.El -.sp -When using -.Sy SIOCLIFGETND , -these flags represent the current state of the corresponding Neighbor Cache -Entry. -When using -.Sy SIOCLIFSETND , -these flags represent what changes should be applied to the underlying entry. -.Pp -The only fields that need to be set for the -.Sy SIOCLIFGETND -or -.Sy SIOCLIFDELND -ioctls are -.Fa lifr_name -and -.Fa lnr_addr . -All other fields should be zeroed out. -After successfully getting an entry, the other fields will be filled in. -When using -.Sy SIOCLIFSETND , -all fields should be set to an appropriate value, as described above, with the -exception of -.Fa lnr_pad0 , -which is unused and only exists for padding purposes. -.Pp -After performing the ioctl, the following errors may be returned through the -global -.Sy errno -variable: -.Bl -tag -offset indent -width 16m -.It Sy EAFNOSUPPORT -A non-IPv6 socket was used to perform the ioctl. -.It Sy EINVAL -The request contents were bad. -This could be because conflicting flags were used, the specified interface -wasn't logical unit zero, or another reason. -.It Sy ENOMEM -The system ran out of memory for internal data structures. -.It Sy ENXIO -The specified interface does not exist. -.It Sy EPERM -The caller does not have permission to modify the Neighbor Cache Entries -associated with this interface. -They may be lacking the -.Sy PRIV_SYS_NET_CONFIG -privilege -.Po see Xr privileges 5 Pc , -or the interface is managed by IPMP (IP Network Multipathing). -.It Sy ESRCH -There is no entry matching the specified address. -.El -.Sh EXAMPLES -The following examples demonstrate how to get and set NDP mappings using the -provided ioctls. -They can be compiled by using a C compiler and linking against the sockets -library. -.Ss Example 1: Getting a mapping -.Bd -literal -offset indent -$ gcc -Wall -lsocket -o get get.c -$ cat get.c -/* - * Example of getting a mapping for a node name. - */ -#include <strings.h> -#include <stdio.h> -#include <stdlib.h> -#include <sys/socket.h> -#include <sys/sockio.h> -#include <unistd.h> -#include <netdb.h> -#include <net/if.h> - -int get(char *host) { - struct lifreq lifr; - struct addrinfo hints, *serverinfo, *p; - int err, s; - - bzero(&hints, sizeof (struct addrinfo)); - hints.ai_family = PF_INET6; - hints.ai_protocol = IPPROTO_IPV6; - - if ((err = getaddrinfo(host, NULL, &hints, &serverinfo)) != 0) { - (void) fprintf(stderr, "Unable to lookup %s: %s\\n", host, - gai_strerror(err)); - return (1); - } - - s = socket(AF_INET6, SOCK_DGRAM, 0); - if (s < 0) { - perror("Failed to open IPv6 socket"); - return (1); - } - - for (p = serverinfo; p != NULL; p = p->ai_next) { - /* Zero out structure */ - bzero(&lifr, sizeof (struct lifreq)); - (void) strlcpy(lifr.lifr_name, "net0", - sizeof (lifr.lifr_name)); - (void) memcpy(&lifr.lifr_nd.lnr_addr, p->ai_addr, - sizeof (struct sockaddr_storage)); - - /* Get mapping */ - if (ioctl(s, SIOCLIFGETND, &lifr) < 0) { - perror("Unable to get NDP mapping"); - continue; - } - - /* - * lifr.lifr_nd.lnr_hdw_addr now contains the MAC address, - * and can be used as desired. - */ - } - - /* - * Clean up linked list. - */ - freeaddrinfo(serverinfo); - return (0); -} - -int main(int argc, char *argv[]) { - if (argc < 2) - exit(1); - return (get(argv[1])); -} -.Ed -.sp -Deleting a mapping would work similarly, except that instead of using -.Sy SIOCLIFGETND , -you would instead use the -.Sy SIOCLIFDELND -ioctl. -.Ss Example 2: Adding a mapping -.Bd -literal -offset indent -$ gcc -Wall -lsocket -o set set.c -$ cat set.c -/* - * Example of setting a mapping to an all-zero Ethernet address. - */ -#include <strings.h> -#include <stdio.h> -#include <stdlib.h> -#include <sys/socket.h> -#include <sys/sockio.h> -#include <unistd.h> -#include <netdb.h> -#include <net/if.h> - -int set(char *host) { - struct lifreq lifr; - struct addrinfo hints, *serverinfo, *p; - int err, s; - - bzero(&hints, sizeof (struct addrinfo)); - hints.ai_family = PF_INET6; - hints.ai_protocol = IPPROTO_IPV6; - - if ((err = getaddrinfo(host, NULL, &hints, &serverinfo)) != 0) { - (void) fprintf(stderr, "Unable to lookup %s: %s\\n", host, - gai_strerror(err)); - return (1); - } - - s = socket(AF_INET6, SOCK_DGRAM, 0); - if (s < 0) { - perror("Failed to open IPv6 socket"); - return (1); - } - - for (p = serverinfo; p != NULL; p = p->ai_next) { - /* Zero out structure */ - bzero(&lifr, sizeof (struct lifreq)); - (void) strlcpy(lifr.lifr_name, "net0", - sizeof (lifr.lifr_name)); - (void) memcpy(&lifr.lifr_nd.lnr_addr, p->ai_addr, - sizeof (struct sockaddr_storage)); - - lifr.lifr_nd.lnr_state_create = ND_REACHABLE; - lifr.lifr_nd.lnr_flags = NDF_STATIC; - - /* Get mapping */ - if (ioctl(s, SIOCLIFSETND, &lifr) < 0) { - perror("Unable to set NDP mapping"); - continue; - } - } - - /* - * Clean up linked list. - */ - freeaddrinfo(serverinfo); - return (0); -} - -int main(int argc, char *argv[]) { - if (argc < 2) - exit(1); - return (set(argv[1])); -} -.Ed -.Sh SEE ALSO -.Xr ifconfig 1M , -.Xr in.ndpd 1M , -.Xr ndp 1M , -.Xr sockaddr_in6 3SOCKET , -.Xr privileges 5 -.Rs -.%A Narten, T. -.%A Nordmark, E. -.%A Simpson, W. -.%A Soliman, H. -.%R Neighbor Discovery for IP version 6 -.%T RFC 4861 -.%D September 2007 -.Re diff --git a/usr/src/man/man7p/pf_key.7p b/usr/src/man/man7p/pf_key.7p deleted file mode 100644 index 1c904048f4..0000000000 --- a/usr/src/man/man7p/pf_key.7p +++ /dev/null @@ -1,946 +0,0 @@ -'\" te -.\" Copyright (C) 2008, Sun Microsystems, Inc. All Rights Reserved -.\" Copyright 2018, Joyent, Inc. -.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License. -.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License. -.\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner] -.TH PF_KEY 7P "December 28, 2020" -.SH NAME -pf_key \- Security association database interface -.SH SYNOPSIS -.nf -#include <sys/types.h> -#include <sys/socket.h> -#include <net/pfkeyv2.h> - - - -\fBint\fR \fBsocket\fR(\fB\fR\fIPF_KEY\fR,SOCK_RAW,\fIPF_KEY_V2\fR); -.fi - -.SH DESCRIPTION -Keying information for IPsec security services is maintained in security -association databases (\fBSADB\fRs). The security associations (\fBSA\fRs) are -used to protect both inbound and outbound packets. -.sp -.LP -A user process (or possibly multiple co-operating processes) maintains -\fBSADB\fRs by sending messages over a special kind of socket. This is -analogous to the method described in \fBroute\fR(7P). Only a superuser may -access an \fBSADB\fR. -.sp -.LP -SunOS applications that use PF_KEY include \fBipseckey\fR(1M) and -\fBin.iked\fR(1M). -.sp -.LP -The operating system may spontaneously send pf_key messages to listening -processes, such as a request for a new \fBSA\fR for an outbound datagram or to -report the expiration of an existing \fBSA\fR. -.sp -.LP -One opens the channel for passing \fBSADB\fR control messages by using the -socket call shown in the section above. More than one key socket can be open -per system. -.sp -.LP -Messages are formed by a small base header, followed by zero or more extension -messages, some of which require additional data following them. The base -message and all extensions must be eight-byte aligned. An example message is -the \fBGET\fR message, which requires the base header, the \fBSA \fRextension, -and the \fBADDRESS_DST\fR extension. -.SS "Messages" -Messages include: -.sp -.in +2 -.nf -#define SADB_GETSPI /* Get a new SPI value from the system. */ -#define SADB_UPDATE /* Update an SA. */ -#define SADB_ADD /* Add a fully-formed SA. */ -#define SADB_DELETE /* Delete an SA. */ -#define SADB_GET /* Get an SA */ -#define SADB_ACQUIRE /* Kernel needs a new SA. */ -#define SADB_REGISTER /* Regis. to receive ACQUIRE msgs. */ -#define SADB_EXPIRE /* SA has expired. */ -#define SADB_FLUSH /* Flush all SAs. */ -#define SADB_DUMP /* Get all SAs. (Unreliable) */ -#define SADB_X_PROMISC /* Listen promiscuously */ -#define SADB_X_INVERSE_ACQUIRE /* Query kernel policy, - get an ACQUIRE in return. */ -#define SADB_X_UPDATEPAIR /* Update an SA and its pair SA */ -#define SADB_X_DELPAIR /* Delete an SA pair. */ -.fi -.in -2 - -.sp -.LP -The base message header consists of: -.sp -.in +2 -.nf -struct sadb_msg { - uint8_t sadb_msg_version; /* Set to PF_KEY_V2, for compat. */ - uint8_t sadb_msg_type; /* Msg. type */ - uint8_t sadb_msg_errno; /* Why message failed */ - uint8_t sadb_msg_satype; /* Which security service */ - uint16_t sadb_msg_len; /* Length in 8-byte units */ - uint16_t sadb_msg_reserved; /* Zero out */ - #define sadb_x_msg_diagnostic sadb_msg_reserved - /* Extended diagnostics for errors */ - uint32_t sadb_msg_seq; /* For msg. originator */ - uint32_t sadb_msg_pid; /* ID originator */ -}; -.fi -.in -2 - -.sp -.LP -Extension types include: -.sp -.in +2 -.nf -#define SADB_EXT_SA /* SA info */ -#define SADB_EXT_LIFETIME_HARD /* Hard lifetime */ -#define SADB_EXT_LIFETIME_SOFT /* Soft lifetime */ -#define SADB_EXT_ADDRESS_SRC /* Source address */ -#define SADB_EXT_ADDRESS_DST /* Destination address */ -#define SADB_EXT_ADDRESS_PROXY /* Proxy address - DEPRECATED */ -#define SADB_EXT_KEY_AUTH /* Authen. key */ -#define SADB_EXT_KEY_ENCRYPT /* Encryption key */ -#define SADB_EXT_IDENTITY_SRC /* Source certif. ID */ -#define SADB_EXT_IDENTITY_DST /* Destination certif. ID */ -#define SADB_EXT_SENSITIVITY /* Sensitivity info */ -#define SADB_EXT_PROPOSAL /* Security proposal */ -#define SADB_EXT_SUPPORTED_AUTH /* Supported authen. algo's */ -#define SADB_EXT_SUPPORTED_ENCRYPT /* Supported encryption algo's */ -#define SADB_EXT_SPIRANGE /* Range of possible SPIs * -#define SADB_X_EXT_EREG /* Reg. for extended ACQUIRE */ -#define SADB_X_EXT_EPROP /* Extended ACQUIRE proposals */ -#define SADB_X_EXT_KM_COOKIE /* Indicates which KM derived SA. */ -#define SADB_X_EXT_ADDRESS_NATT_LOC /* NAT-Traversal local (my public) */ -#define SADB_X_EXT_ADDRESS_NATT_REM /* NAT-T remote (peer's private) */ -#define SADB_X_EXT_ADDRESS_INNER_SRC /* Tunnel-mode inner source */ -#define SADB_X_EXT_ADDRESS_INNER_DST /* Tunnel-mode inner dest */ -#define SADB_X_EXT_PAIR /* SA pair extension. -.fi -.in -2 - -.sp -.LP -Security Association Information Extension flags: -.sp -.in +2 -.nf -#define SADB_SAFLAGS_PFS 0x1 /* Perfect forward secrecy? */ -#define SADB_SAFLAGS_NOREPLAY 0x2 /* Replay field NOT PRESENT. */ -#define SADB_X_SAFLAGS_USED 0x80000000 /* SA used/not used */ -#define SADB_X_SAFLAGS_UNIQUE 0x40000000 /* SA unique/reusable */ -#define SADB_X_SAFLAGS_AALG1 0x20000000 /* Auth-alg specif. flag 1 */ -#define SADB_X_SAFLAGS_AALG2 0x10000000 /* Auth-alg specif. flag 2 */ -#define SADB_X_SAFLAGS_EALG1 0x8000000 /* Encr-alg specif. flag 1 */ -#define SADB_X_SAFLAGS_EALG2 0x4000000 /* Encr-alg specif. flag 2 */ -#define SADB_X_SAFLAGS_KM1 0x2000000 /* Key mgmt. specif. flag 1 */ -#define SADB_X_SAFLAGS_KM2 0x1000000 /* Key mgmt. specif. flag 2 */ -#define SADB_X_SAFLAGS_KM3 0x800000 /* Key mgmt. specif. flag 3 */ -#define SADB_X_SAFLAGS_KM4 0x400000 /* Key mgmt. specif. flag 4 */ -#define SADB_X_SAFLAGS_KRES1 0x200000 /* Reserved by the kernel */ -#define SADB_X_SAFLAGS_NATT_LOC 0x100000 /* this has a natted srcSA */ -#define SADB_X_SAFLAGS_NATT_REM 0x80000 /* this has a natted dstSA */ -#define SADB_X_SAFLAGS_KRES2 0x40000 /* Reserved by the kernel */ -#define SADB_X_SAFLAGS_TUNNEL 0x20000 /* tunnel mode */ -#define SADB_X_SAFLAGS_PAIRED 0x10000 /* inbound/outbound pair*/ -#define SADB_X_SAFLAGS_OUTBOUND 0x8000 /* SA direction bit */ -#define SADB_X_SAFLAGS_INBOUND 0x4000 /* SA direction bit */ -.fi -.in -2 - -.sp -.LP -Extension headers include: -.SS "Generic Extension Header" -.in +2 -.nf -struct sadb_ext { - uint16_t sadb_ext_len; /* In 64-bit words, inclusive */ - uint16_t sadb_ext_type; /* 0 is reserved */ -}; -.fi -.in -2 - -.SS "Security Association Information Extension" -.in +2 -.nf -struct sadb_sa { - uint16_t sadb_sa_len; - uint16_t sadb_sa_exttype; /* ASSOCIATION */ - uint32_t sadb_sa_spi; - uint8_t sadb_sa_replay; - uint8_t sadb_sa_state; - uint8_t sadb_sa_auth; - uint8_t sadb_sa_encrypt; - uint32_t sadb_sa_flags; -}; -.fi -.in -2 - -.SS "Lifetime Extension" -.in +2 -.nf -struct sadb_lifetime { - uint16_t sadb_lifetime_len; - uint16_t sadb_lifetime_exttype; /* SOFT, HARD, CURRENT */ - uint32_t sadb_lifetime_allocations; - uint64_t sadb_lifetime_bytes; - uint64_t sadb_lifetime_addtime; - uint64_t sadb_lifetime_usetime; -}; -.fi -.in -2 - -.SS "Address Extension" -.in +2 -.nf -struct sadb_address { - uint16_t sadb_address_len; - uint16_t sadb_address_exttype; /* SRC, DST, NATT_*, INNER_* */ - uint8_t sadb_address_proto; /* Proto for ports... */ - uint8_t sadb_address_prefixlen; /* Prefix length for INNER_*. */ - uint16_t sadb_address_reserved; /* Padding */ - /* Followed by a sockaddr - structure.*/ -}; -.fi -.in -2 - -.SS "Keying Material Extension" -.in +2 -.nf -struct sadb_key { - uint16_t sadb_key_len; - uint16_t sadb_key_exttype; /* AUTH, ENCRYPT */ - uint16_t sadb_key_bits; - uint16_t sadb_key_reserved; - /* Followed by actual key(s) in - canonical (outbound proc.) order. */ -}; -.fi -.in -2 - -.SS "Identity Extension" -.in +2 -.nf -struct sadb_ident { - uint16_t sadb_ident_len; - uint16_t sadb_ident_exttype; /* SRC, DST, PROXY */ - uint16_t sadb_ident_type; /* FQDN, USER_FQDN, etc. */ - uint16_t sadb_ident_reserved; /* Padding */ - uint64_t sadb_ident_id; /* For userid, etc. */ - /* Followed by an identity null-terminate C string if present. */ -}; -.fi -.in -2 - -.SS "Sensitivity/Integrity Extension" -.in +2 -.nf -struct sadb_sens { - uint16_t sadb_sens_len; - uint16_t sadb_sens_exttype; /* SENSITIVITY */ - uint32_t sadb_sens_dpd; - uint8_t sadb_sens_sens_level; - uint8_t sadb_sens_sens_len; /* 64-bit words */ - uint8_t sadb_sens_integ_level; - uint8_t sadb_sens_integ_len; /* 64-bit words */ - uint32_t sadb_sens_reserved; - /* - * followed by two uint64_t arrays - * uint64_t sadb_sens_bitmap[sens_bitmap_len]; - * uint64_t integ_bitmap[integ_bitmap_len]; - */ -}; -.fi -.in -2 - -.SS "Proposal Extension" -.in +2 -.nf -struct sadb_prop { - uint16_t sadb_prop_len; - uint16_t sadb_prop_exttype; /* PROPOSAL, X_EPROP */ - uint8_t sadb_prop_replay; - uint8_t sadb_X_prop_ereserved; - uint16_t sadb_x_prop_numecombs; -/* Followed by sadb_comb[] array or sadb_ecomb[] array. */ -}; -.fi -.in -2 - -.SS "Combination Instance for a Proposal" -.in +2 -.nf -struct sadb_comb { - uint8_t sadb_comb_auth; - uint8_t sadb_comb_encrypt; - uint16_t sadb_comb_flags; - uint16_t sadb_comb_auth_minbits; - uint16_t sadb_comb_auth_maxbits; - uint16_t sadb_comb_encrypt_minbits; - uint16_t sadb_comb_encrypt_maxbits; - uint8_t sadb_x_comb_encrypt_saltbits; - uint8_t sadb_x_comb_reserved; - uint16_t sadb_comb_reserved; - uint32_t sadb_comb_soft_allocations; - uint32_t sadb_comb_hard_allocations; - uint64_t sadb_comb_soft_bytes; - uint64_t sadb_comb_hard_bytes; - uint64_t sadb_comb_soft_addtime; - uint64_t sadb_comb_hard_addtime; - uint64_t sadb_comb_soft_usetime; - uint64_t sadb_comb_hard_usetime; -}; -.fi -.in -2 - -.SS "Extended Combination" -.in +2 -.nf -struct sadb_x_ecomb { - uint8_t sadb_x_ecomb_numalgs; - uint8_t sadb_x_ecomb_reserved; - uint16_t sadb_x_ecomb_flags; /* E.g. PFS? */ - uint32_t sadb_x_ecomb_reserved2; - uint32_t sadb_x_ecomb_soft_allocations; - uint32_t sadb_x_ecomb_hard_allocations; - uint64_t sadb_x_ecomb_soft_bytes; - uint64_t sadb_x_ecomb_hard_bytes; - uint64_t sadb_x_ecomb_soft_addtime; - uint64_t sadb_x_ecomb_hard_addtime; - uint64_t sadb_x_ecomb_soft_usetime; - uint64_t sadb_x_ecomb_hard_usetime; -}; -.fi -.in -2 - -.SS "Extended Combination Algorithm Descriptors" -.in +2 -.nf -struct sadb_x_algdesc { - uint8_t sadb_x_algdesc_satype; /* ESP, AH, etc. */ - uint8_t sadb_x_algdesc_algtype; /* AUTH, CRYPT, COMPRESS */ - uint8_t sadb_x_algdesc_alg; /* DES, 3DES, MD5, etc. */ - uint8_t sadb_x_algdesc_saltbits; - uint16_t sadb_x_algdesc_minbits; /* Bit strengths. */ - uint16_t sadb_x_algdesc_maxbits; - }; -.fi -.in -2 - -.SS "Extended Register" -.in +2 -.nf -struct sadb_x_ereg { - uint16_t sadb_x_ereg_len; - uint16_t sadb_x_ereg_exttype; /* X_EREG */ - uint8_t sadb_x_ereg_satypes[4]; /* Array of SA types, 0-terminated. -|}; -.fi -.in -2 - -.SS "Key Management Cookie" -.in +2 -.nf -struct sadb_x_kmc { - uint16_t sadb_x_kmc_len; - uint16_t sadb_x_kmc_exttype; /* X_KM_COOKIE */ - uint32_t sadb_x_kmc_proto; /* KM protocol */ - uint32_t sadb_x_kmc_cookie; /* KMP-specific */ - uint32_t sadb_x_kmc_reserved; /* Reserved; must be zero */ - }; -.fi -.in -2 - -.SS "Supported Algorithms Extension" -.in +2 -.nf -struct sadb_supported { - uint16_t sadb_supported_len; - uint16_t sadb_supported_exttype; - uint32_t sadb_supported_reserved; -}; -.fi -.in -2 - -.SS "Algorithm Instance" -.in +2 -.nf -struct sadb_alg { - uint8_t sadb_alg_id; /* Algorithm type. */ - uint8_t sadb_alg_ivlen; /* IV len, in bits */ - uint16_t sadb_alg_minbits; /* Min. key len (in bits) */ - uint16_t sadb_alg_maxbits; /* Max. key length */ - uint16_t sadb_alg_reserved; -}; -.fi -.in -2 - -.SS "SPI Extension Range" -.in +2 -.nf -struct sadb_spirange { - uint16_t sadb_spirange_len; - uint16_t sadb_spirange_exttype; /* SPI_RANGE */ - uint32_t sadb_spirange_min - uint32_t sadb_spirange_max; - uint32_t sadb_spirange_reserved; -}; -.fi -.in -2 - -.SS "Security Association Pair Extension" -.in +2 -.nf -struct sadb_x_pair { - uint16_t sadb_x_pair_len; - uint16_t sadb_x_pair_exttype; /* SADB_X_EXT_PAIR */ - uint32_t sadb_x_pair_spi; /* SPI of paired SA */ -}; -.fi -.in -2 - -.SS "Message Use and Behavior" -Each message has a behavior. A behavior is defined as where the initial message -travels, for example, user to kernel, and what subsequent actions are expected -to take place. Contents of messages are illustrated as: -.sp -.in +2 -.nf -<base, REQUIRED EXTENSION, REQ., (OPTIONAL EXTENSION,) (OPT)> -.fi -.in -2 - -.sp -.LP -The \fBSA\fR extension is sometimes used only for its \fBSPI\fR field. If all -other fields must be ignored, this is represented by \fBSA\fR(*). -.sp -.LP -The lifetime extensions are represented with one to three letters after the -word lifetime, representing (H)ARD, (S)OFT, and (C)URRENT. -.sp -.LP -The address extensions are represented with one to three letters after the word -"address," representing (S)RC, (D)ST, (Nl)NAT-T local, (Nr)NAT-T remote, -(Is)Inner source, and (Id)Inner destination. -.sp -.LP -Source and destination address extensions reflect outer-header selectors for an -IPsec SA. An SA is inbound or outbound depending on which of the source or -destination address is local to the node. Inner-source and inner-destination -selectors represent inner-header selectors for Tunnel Mode SAs. A Tunnel Mode -SA \fBmust\fR have either IPPROTO_ENCAP or IPPROTO_IPV6 in its outer-headers as -protocol selector, in addition to filled-in Inner-address extensions. -.sp -.LP -NAT-T local and NAT-T remote addresses store local and remote ports used for -ESP-in-UDP encapsulation. A non-zero local NAT-T address extension represents -the local node's external IP address if it is not equivalent to the SA's local -address. A non-zero remote NAT-T address represents a peer's behind-a-NAT -address if it is not equivalent to the SA's remote address. An SA with NAT-T -extensions will protect-and-transmit outbound traffic. Processing of inbound -NAT-T traffic requires a UDP socket bound to the appropriate local port and it -\fBmust\fR have the UDP_NAT_T_ENDPOINT (see \fBudp\fR(7P)) socket option -enabled. -.sp -.LP -Note that when an error occurs, only the base header is sent. In the event of -an error, an extended diagnostic may be set (see DIAGNOSTICS). Typical errors -include: -.sp -.ne 2 -.na -\fB\fBEINVAL\fR\fR -.ad -.RS 11n -Various message improprieties, including \fBSPI\fR ranges that are malformed, -weak keys, and others. If EINVAL is returned, an application should look at the -\fBsadb_x_msg_diagnostic\fR field of the sadb_msg structure. It contains one of -many possible causes for EINVAL. See \fBnet/pfkeyv2.h\fR for values, all of the -form SADB_X_DIAGNOSTIC_. -.RE - -.sp -.ne 2 -.na -\fB\fBENOMEM\fR\fR -.ad -.RS 11n -Needed memory was not available. -.RE - -.sp -.ne 2 -.na -\fB\fBENSGSIZ\fR\fR -.ad -.RS 11n -Message exceeds the maximum length allowed. -.RE - -.sp -.ne 2 -.na -\fB\fBEEXIST\fR\fR -.ad -.RS 11n -\fBSA\fR (that is being added or created with \fBGETSPI\fR) already exists. -.RE - -.sp -.ne 2 -.na -\fB\fBESRCH\fR\fR -.ad -.RS 11n -\fBSA\fR could not be found. -.RE - -.sp -.LP -The following are examples of message use and behavior: -.SS "\fBSADB_GETSPI\fR" -Send a \fBSADB_GETSPI\fR message from a user process to the kernel. -.sp -.in +2 -.nf -<base, address, SPI range> -.fi -.in -2 - -.sp -.LP -The kernel returns the \fBSADB_GETSPI\fR message to all listening processes. -.sp -.in +2 -.nf -<base, SA(*), address (SD)> -.fi -.in -2 - -.SS "\fBSADB_UPDATE\fR" -Send a \fBSADB_UPDATE\fR message from a user process to the kernel. -.sp -.in +2 -.nf -<base, SA, (lifetime(HS),) address(SD), (address(Is,Id), - address(Nl,Nr), key (AE), (identity(SD),) (sensitivity)> -.fi -.in -2 - -.sp -.LP -The kernel returns the \fBSADB_UPDATE\fR message to all listening processes. -.sp -.in +2 -.nf -<base, SA(*), address (SD), (pair)> -.fi -.in -2 - -.sp -.LP -Adding a sadb_x_pair extension to an \fBSADB_UPDATE\fR or \fBSADB_ADD\fR -message will update the security association pair linkage with the SPI of the -security association contained in that extension. The resulting security -association "pair" can be updated or as a single entity using the -\fBSADB_X_UPDATEPAIR\fR or \fBSADB_X_DELPAIR\fR message types. -.SS "\fBSADB_ADD\fR" -Send a \fBSADB_ADD\fR message from a user process to the kernel. -.sp -.in +2 -.nf -<base, SA, (lifetime(HS),) address(SD), (address(Is,Id),) - (address(Nl,Nr),) key (AE), (identity(SD),) (sensitivity) (pair)> -.fi -.in -2 - -.sp -.LP -The kernel returns the \fBSADB_ADD\fR message to all listening processes. -.sp -.in +2 -.nf -<base, SA, (lifetime(HS),) address (SD), (address(Is,Id),) - (address(Nl,Nr),) (identity (SD),) (sensitivity)> -.fi -.in -2 - -.SS "\fBSADB_X_UPDATEPAIR\fR" -Send a \fBSADB_X_UPDATEPAIR\fR message from a user process to the kernel. -This message type is used to update the lifetime values of a security -association and the lifetime values of the security association it is paired -with. -.sp -.in +2 -.nf -<base, SA, lifetime(HS), address(SD)> -.fi -.in -2 - -.SS "\fBSADB_DELETE | SADB_X_DELPAIR\fR" -Send a \fBSADB_DELETE\fR message from a user process to the kernel. The -\fBSADB_X_DELPAIR\fR message type will request deletion of the security -association and the security association it is paired with. -.sp -.in +2 -.nf -<base, SA (*), address (SD)> -.fi -.in -2 - -.sp -.LP -The kernel returns the \fBSADB_DELETE\fR message to all listening processes. -.sp -.in +2 -.nf -<base, SA (*), address (SD)> -.fi -.in -2 - -.SS "\fBSADB_GET\fR" -Send a \fBSADB_GET\fR message from a user process to the kernel. -.sp -.in +2 -.nf -<base, SA (*), address (SD)> -.fi -.in -2 - -.sp -.LP -The kernel returns the \fBSADB_GET\fR message to the socket that sent the -\fBSADB_GET\fR message. -.sp -.in +2 -.nf -<base, SA , (lifetime (HSC),) address SD), (address (P),) key (AE), - (identity (SD),) (sensitivity)> -.fi -.in -2 - -.SS "\fBSADB_ACQUIRE\fR" -The kernel sends a \fBSADB_ACQUIRE\fR message to registered sockets. Note that -any \fBGETSPI\fR, \fBADD\fR, or \fBUPDATE\fR calls in reaction to an -\fBACQUIRE\fR must fill in the \fBsadb_msg_seq\fR of those messages with the -one in the \fBACQUIRE\fR message. The address (\fBSD\fR) extensions must have -the port fields filled in with the port numbers of the session requiring keys -if appropriate. -.sp -.in +2 -.nf -<base, address (SD), (address(Is,Id)), (identity(SD),) - (sensitivity,) proposal> -.fi -.in -2 - -.sp -.LP -Extended ACQUIRE will have a slightly different format. The -\fBsadb_msg_satype\fR field is 0, and the extension contains the desired -combination(s) of security protocols. -.sp -.in +2 -.nf -<base, address (SD), (address(Is,Id)), (identity(SD),) - (sensitivity,) eprop> -.fi -.in -2 - -.sp -.LP -If key management fails, send an \fBSADB_ACQUIRE\fR to indicate failure. -.sp -.in +2 -.nf -<base> -.fi -.in -2 - -.SS "\fBSADB_X_INVERSE_ACQUIRE\fR" -For inbound Key Management processing, a Key Management application may wish to -consult the kernel for its policy. The application should send to the kernel: -.sp -.in +2 -.nf -<base, address (SD), (address(Is,Id))> -.fi -.in -2 - -.sp -.LP -The kernel returns a message similar to a kernel-generated extended ACQUIRE: -.sp -.in +2 -.nf -<base, address (SD), (address(Is,Id)), (identity(SD),) - (sensitivity,) eprop> -.fi -.in -2 - -.SS "\fBSADB_REGISTER\fR" -Send a \fBSADB_REGISTER\fR message from a user process to the kernel. -.sp -.in +2 -.nf -<base> -.fi -.in -2 - -.sp -.LP -The kernel returns the \fBSADB_REGISTER\fR message to registered sockets, with -algorithm types supported by the kernel being indicated in the supported -algorithms field. Note that this message may arrive asynchronously due to an -algorithm being loaded or unloaded into a dynamically linked kernel. -.sp -.in +2 -.nf -<base, supported> -.fi -.in -2 - -.sp -.LP -There is also the extended REGISTER, which will allow this process to receive -extended ACQUIREs. -.sp -.in +2 -.nf -<base, ereg> -.fi -.in -2 - -.sp -.LP -Which returns a series of SADB_REGISTER replies (one for each security protocol -registered) from the kernel. -.SS "\fBSADB_EXPIRE\fR" -The kernel sends a \fBSADB_EXPIRE\fR message to all listeners when the soft -limit of a security association has been expired. -.sp -.in +2 -.nf -<base, SA, lifetime (C and one of HS), address (SD)> -.fi -.in -2 - -.SS "\fBSADB_FLUSH\fR" -Send a \fBSADB_FLUSH\fR message from a user process to the kernel. -.sp -.in +2 -.nf -<base> -.fi -.in -2 - -.sp -.LP -The kernel returns the \fBSADB_FLUSH\fR message to all listening sockets. -.sp -.in +2 -.nf -<base> -.fi -.in -2 - -.SS "\fBSADB_DUMP\fR" -Send a \fBSADB_DUMP\fR message from a user process to the kernel. -.sp -.in +2 -.nf -<base> -.fi -.in -2 - -.sp -.LP -Several \fBSADB_DUMP\fR messages will return from the kernel to the sending -socket. -.sp -.in +2 -.nf -<base, SA, (lifetime (HSC),) address (SD), (address (Is,Id),) - (address (Nl,Nr),) key (AE), (identity (SD),) sensitivity)> -.fi -.in -2 - -.sp -.LP -To mark the end of a dump a single base header arrives with its -\fBsadb_mdg_seq\fR set to 0. -.sp -.in +2 -.nf -<base> -.fi -.in -2 - -.SS "\fBSADB_X_PROMISC\fR" -Send a \fBSADB_X_PROMISC\fR message from a user process to the kernel. -.sp -.in +2 -.nf -<base> -.fi -.in -2 - -.sp -.LP -The kernel returns the \fBSADB_X_PROMISC\fR message to all listening processes. -.sp -.in +2 -.nf -<base> -.fi -.in -2 - -.SH DIAGNOSTICS -The message returning from the kernel will contain a diagnostic value in the -base message header, the diagnostic value will indicate if action requested by -the original message was a success. -.sp -.LP -Diagnostic Values: -.sp -.in +2 -.nf -#define SADB_X_DIAGNOSTIC_NONE 0 -#define SADB_X_DIAGNOSTIC_UNKNOWN_MSG 1 -#define SADB_X_DIAGNOSTIC_UNKNOWN_EXT 2 -#define SADB_X_DIAGNOSTIC_BAD_EXTLEN 3 -#define SADB_X_DIAGNOSTIC_UNKNOWN_SATYPE 4 -#define SADB_X_DIAGNOSTIC_SATYPE_NEEDED 5 -#define SADB_X_DIAGNOSTIC_NO_SADBS 6 -#define SADB_X_DIAGNOSTIC_NO_EXT 7 - /* Bad address family value */ -#define SADB_X_DIAGNOSTIC_BAD_SRC_AF 8 - /* in sockaddr->sa_family. */ -#define SADB_X_DIAGNOSTIC_BAD_DST_AF 9 - /* These two are synonyms. */ -#define SADB_X_DIAGNOSTIC_BAD_PROXY_AF 10 -#define SADB_X_DIAGNOSTIC_BAD_INNER_SRC_AF 10 - -#define SADB_X_DIAGNOSTIC_AF_MISMATCH 11 - -#define SADB_X_DIAGNOSTIC_BAD_SRC 12 -#define SADB_X_DIAGNOSTIC_BAD_DST 13 - -#define SADB_X_DIAGNOSTIC_ALLOC_HSERR 14 -#define SADB_X_DIAGNOSTIC_BYTES_HSERR 15 -#define SADB_X_DIAGNOSTIC_ADDTIME_HSERR 16 -#define SADB_X_DIAGNOSTIC_USETIME_HSERR 17 - -#define SADB_X_DIAGNOSTIC_MISSING_SRC 18 -#define SADB_X_DIAGNOSTIC_MISSING_DST 19 -#define SADB_X_DIAGNOSTIC_MISSING_SA 20 -#define SADB_X_DIAGNOSTIC_MISSING_EKEY 21 -#define SADB_X_DIAGNOSTIC_MISSING_AKEY 22 -#define SADB_X_DIAGNOSTIC_MISSING_RANGE 23 - -#define SADB_X_DIAGNOSTIC_DUPLICATE_SRC 24 -#define SADB_X_DIAGNOSTIC_DUPLICATE_DST 25 -#define SADB_X_DIAGNOSTIC_DUPLICATE_SA 26 -#define SADB_X_DIAGNOSTIC_DUPLICATE_EKEY 27 -#define SADB_X_DIAGNOSTIC_DUPLICATE_AKEY 28 -#define SADB_X_DIAGNOSTIC_DUPLICATE_RANGE 29 - -#define SADB_X_DIAGNOSTIC_MALFORMED_SRC 30 -#define SADB_X_DIAGNOSTIC_MALFORMED_DST 31 -#define SADB_X_DIAGNOSTIC_MALFORMED_SA 32 -#define SADB_X_DIAGNOSTIC_MALFORMED_EKEY 33 -#define SADB_X_DIAGNOSTIC_MALFORMED_AKEY 34 -#define SADB_X_DIAGNOSTIC_MALFORMED_RANGE 35 - -#define SADB_X_DIAGNOSTIC_AKEY_PRESENT 36 -#define SADB_X_DIAGNOSTIC_EKEY_PRESENT 37 -#define SADB_X_DIAGNOSTIC_PROP_PRESENT 38 -#define SADB_X_DIAGNOSTIC_SUPP_PRESENT 39 -#define SADB_X_DIAGNOSTIC_BAD_AALG 40 -#define SADB_X_DIAGNOSTIC_BAD_EALG 41 -#define SADB_X_DIAGNOSTIC_BAD_SAFLAGS 42 -#define SADB_X_DIAGNOSTIC_BAD_SASTATE 43 - -#define SADB_X_DIAGNOSTIC_BAD_AKEYBITS 44 -#define SADB_X_DIAGNOSTIC_BAD_EKEYBITS 45 - -#define SADB_X_DIAGNOSTIC_ENCR_NOTSUPP 46 - -#define SADB_X_DIAGNOSTIC_WEAK_EKEY 47 -#define SADB_X_DIAGNOSTIC_WEAK_AKEY 48 - -#define SADB_X_DIAGNOSTIC_DUPLICATE_KMP 49 -#define SADB_X_DIAGNOSTIC_DUPLICATE_KMC 50 - -#define SADB_X_DIAGNOSTIC_MISSING_NATT_LOC 51 -#define SADB_X_DIAGNOSTIC_MISSING_NATT_REM 52 -#define SADB_X_DIAGNOSTIC_DUPLICATE_NATT_LOC 53 -#define SADB_X_DIAGNOSTIC_DUPLICATE_NATT_REM 54 -#define SADB_X_DIAGNOSTIC_MALFORMED_NATT_LOC 55 -#define SADB_X_DIAGNOSTIC_MALFORMED_NATT_REM 56 -#define SADB_X_DIAGNOSTIC_DUPLICATE_NATT_PORTS 57 - -#define SADB_X_DIAGNOSTIC_MISSING_INNER_SRC 58 -#define SADB_X_DIAGNOSTIC_MISSING_INNER_DST 59 -#define SADB_X_DIAGNOSTIC_DUPLICATE_INNER_SRC 60 -#define SADB_X_DIAGNOSTIC_DUPLICATE_INNER_DST 61 -#define SADB_X_DIAGNOSTIC_MALFORMED_INNER_SRC 62 -#define SADB_X_DIAGNOSTIC_MALFORMED_INNER_DST 63 - -#define SADB_X_DIAGNOSTIC_PREFIX_INNER_SRC 64 -#define SADB_X_DIAGNOSTIC_PREFIX_INNER_DST 65 -#define SADB_X_DIAGNOSTIC_BAD_INNER_DST_AF 66 -#define SADB_X_DIAGNOSTIC_INNER_AF_MISMATCH 67 - -#define SADB_X_DIAGNOSTIC_BAD_NATT_REM_AF 68 -#define SADB_X_DIAGNOSTIC_BAD_NATT_LOC_AF 69 - -#define SADB_X_DIAGNOSTIC_PROTO_MISMATCH 70 -#define SADB_X_DIAGNOSTIC_INNER_PROTO_MISMATCH 71 - -#define SADB_X_DIAGNOSTIC_DUAL_PORT_SETS 72 - -#define SADB_X_DIAGNOSTIC_PAIR_INAPPROPRIATE 73 -#define SADB_X_DIAGNOSTIC_PAIR_ADD_MISMATCH 74 -#define SADB_X_DIAGNOSTIC_PAIR_ALREADY 75 -#define SADB_X_DIAGNOSTIC_PAIR_SA_NOTFOUND 76 -#define SADB_X_DIAGNOSTIC_BAD_SA_DIRECTION 77 - -#define SADB_X_DIAGNOSTIC_SA_NOTFOUND 78 -#define SADB_X_DIAGNOSTIC_SA_EXPIRED 79 -.fi -.in -2 - -.SH ATTRIBUTES -See \fBattributes\fR(5) for descriptions of the following attributes: -.sp - -.sp -.TS -box; -c | c -l | l . -ATTRIBUTE TYPE ATTRIBUTE VALUE -Interface Stability Evolving -.TE - -.SH SEE ALSO -\fBin.iked\fR(1M), \fBipseckey\fR(1M), \fBsockaddr\fR(3SOCKET), -\fBipsec\fR(7P), \fBipsecah\fR(7P), -\fBipsecesp\fR(7P), \fBroute\fR(7P), \fBudp\fR(7P) -.sp -.LP -McDonald, D.L., Metz, C.W., and Phan, B.G., \fIRFC 2367, PF_KEY Key Management -API, Version 2\fR, The Internet Society, July 1998. -.SH NOTES -Time-based lifetimes may not expire with exact precision in seconds because -kernel load may affect the aging of \fBSA\fR's. diff --git a/usr/src/man/man7p/rarp.7p b/usr/src/man/man7p/rarp.7p deleted file mode 100644 index 4ab51cf38b..0000000000 --- a/usr/src/man/man7p/rarp.7p +++ /dev/null @@ -1,56 +0,0 @@ -'\" te -.\" Copyright (c) 2001, Sun Microsystems, Inc. -.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License. -.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License. -.\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner] -.TH RARP 7P "May 28, 2005" -.SH NAME -rarp, RARP \- Reverse address resolution protocol -.SH DESCRIPTION -.sp -.LP -You use the RARP protocol to map dynamically between the Internet Protocol (IP) -and network interface MAC addresses. RARP is often used to boot a Solaris -client. RARP clients include the SPARC boot PROM, x86 boot floppy, SunOS -kernel, and \fBifconfig\fR(1M). \fBin.rarpd\fR(1M) provides the server-side -implementation. -.sp -.LP -RARP request timeout behavior in application-layer clients is governed by the -\fB/etc/inet/rarp\fR default file. To tune the number of retries an application -attempts before giving up, set the \fBRARP_RETRIES\fR variable in -\fB/etc/inet/rarp\fR. If the file is not present or \fBRARP_RETRIES\fR is not -initialized within it, applications retry a maximum of five times with a eight -second wait between retries. -.SH FILES -.sp -.LP -\fB/etc/inet/rarp\fR -.SH ATTRIBUTES -.sp -.LP -See \fBattributes\fR(5) for descriptions of the following attributes: -.sp - -.sp -.TS -box; -c | c -l | l . -ATTRIBUTE TYPE ATTRIBUTE VALUE -_ -Interface Stability (protocol) Standard -_ -Interface Stability (defaults file) Unstable -_ -Interface Stability (RARP_RETRIES) Unstable -.TE - -.SH SEE ALSO -.sp -.LP -\fBifconfig\fR(1M), \fBin.rarpd\fR(1M), \fBarp\fR(7P) -.sp -.LP -\fIReverse Address Resolution Protocol RFC 903. June, 1984\fR R. Finlayson, T. -Mann, J.C. Mogul, M. Theimer diff --git a/usr/src/man/man7p/route.7p b/usr/src/man/man7p/route.7p deleted file mode 100644 index 22d4f4c735..0000000000 --- a/usr/src/man/man7p/route.7p +++ /dev/null @@ -1,330 +0,0 @@ -'\" te -.\" Copyright (c) 1990, 1991, 1993 The Regents of the University of California. 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. All advertising materials mentioning features or use of this software must display -.\" the following acknowledgement: This product includes software developed by the University of California, Berkeley and its contributors. 4. Neither the name of the University 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 REGENTS 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 REGENTS -.\" 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. -.\" Portions Copyright (c) 2009, Sun Microsystems, Inc. All Rights Reserved. -.TH ROUTE 7P "April 9, 2016" -.SH NAME -route \- kernel packet forwarding database -.SH SYNOPSIS -.LP -.nf -#include <sys/types.h> -#include <sys/socket.h> -#include <net/if.h> -#include <net/route.h> - -\fBint\fR \fBsocket\fR(\fB\fR\fIPF_ROUTE\fR, \fB\fR\fISOCK_RAW\fR, \fBint\fR \fIprotocol\fR); -.fi - -.SH DESCRIPTION -.LP -UNIX provides some packet routing facilities. The kernel maintains a routing -information database, which is used in selecting the appropriate network -interface when transmitting packets. -.sp -.LP -A user process (or possibly multiple co-operating processes) maintains this -database by sending messages over a special kind of socket. This supplants -fixed size \fBioctl\fR(2)'s specified in \fBrouting\fR(7P). Routing table -changes can only be carried out by the superuser. -.sp -.LP -The operating system might spontaneously emit routing messages in response to -external events, such as receipt of a re-direct, or failure to locate a -suitable route for a request. The message types are described in greater detail -below. -.sp -.LP -Routing database entries come in two flavors: entries for a specific host, or -entries for all hosts on a generic subnetwork (as specified by a bit mask and -value under the mask). The effect of wildcard or default route can be achieved -by using a mask of all zeros, and there can be hierarchical routes. -.sp -.LP -When the system is booted and addresses are assigned to the network interfaces, -the internet protocol family installs a routing table entry for each interface -when it is ready for traffic. Normally the protocol specifies the route through -each interface as a \fIdirect\fR connection to the destination host or network. -If the route is direct, the transport layer of a protocol family usually -requests the packet be sent to the same host specified in the packet. -Otherwise, the interface is requested to address the packet to the gateway -listed in the routing entry, that is, the packet is forwarded. -.sp -.LP -When routing a packet, the kernel attempts to find the most specific route -matching the destination. If no entry is found, the destination is declared to -be unreachable, and a routing-miss message is generated if there are any -listeners on the routing control socket (described below). If there are two -different mask and value-under-the-mask pairs that match, the more specific is -the one with more bits in the mask. A route to a host is regarded as being -supplied with a mask of as many ones as there are bits in the destination. -.sp -.LP -A wildcard routing entry is specified with a zero destination address value, -and a mask of all zeroes. Wildcard routes are used when the system fails to -find other routes matching the destination. The combination of wildcard routes -and routing redirects can provide an economical mechanism for routing traffic. -.sp -.LP -One opens the channel for passing routing control messages by using the socket -call. There can be more than one routing socket open per system. -.sp -.LP -Messages are formed by a header followed by a small number of \fBsockaddrs\fR, -whose length depend on the address family. \fBsockaddrs\fR are interpreted by -position. An example of a type of message with three addresses might be a -\fBCIDR\fR prefix route: Destination, Netmask, and Gateway. The interpretation -of which addresses are present is given by a bit mask within the header, and -the sequence is least significant to most significant bit within the vector. -.sp -.LP -Any messages sent to the kernel are returned, and copies are sent to all -interested listeners. The kernel provides the process \fBID\fR of the sender, -and the sender can use an additional sequence field to distinguish between -outstanding messages. However, message replies can be lost when kernel buffers -are exhausted. -.sp -.LP -The \fIprotocol\fR parameter specifies which messages an application listening -on the routing socket is interested in seeing, based on the address family -of the \fBsockaddrs\fR present. Currently, you can specify \fBAF_INET\fR and -\fBAF_INET6\fR to filter the messages seen by the listener, or alternatively, -you can specify \fBAF_UNSPEC\fR to indicate that the listener is interested in -all routing messages. -.sp -.LP -The kernel might reject certain messages, and indicates this by filling in the -\fBrtm_errno\fR field of the \fBrt_msghdr\fR struct (see below). The following -codes are returned: -.sp -.ne 2 -.na -\fB\fBEEXIST\fR\fR -.ad -.RS 11n -If requested to duplicate an existing entry -.RE - -.sp -.ne 2 -.na -\fB\fBESRCH\fR\fR -.ad -.RS 11n -If requested to delete a non-existent entry -.RE - -.sp -.ne 2 -.na -\fB\fBENOBUFS\fR\fR -.ad -.RS 11n -If insufficient resources were available to install a new route. -.RE - -.sp -.ne 2 -.na -\fB\fBEPERM\fR\fR -.ad -.RS 11n -If the calling process does not have appropriate privileges to alter the -routing table. -.RE - -.sp -.LP -In the current implementation, all routing processes run locally, and the -values for \fBrtm_errno\fR are available through the normal \fBerrno\fR -mechanism, even if the routing reply message is lost. -.sp -.LP -A process can avoid the expense of reading replies to its own messages by -issuing a \fBsetsockopt\fR(3SOCKET) call indicating that the -\fBSO_USELOOPBACK\fR option at the \fBSOL_SOCKET\fR level is to be turned off. -A process can ignore all messages from the routing socket by doing a -\fBshutdown\fR(3SOCKET) system call for further input. -.sp -.LP -By default, underlying IP interfaces in an IPMP group are not visible to -routing sockets. As such, routing sockets do not receive events related to -underlying IP interface in an IPMP group. For consistency, when an IP interface -is placed into an IPMP group, \fBRTM_DELADDR\fR messages are generated for each -\fBIFF_UP\fR address that is not migrated to the corresponding IPMP IP -interface and an \fBRTM_IFINFO\fR message is sent indicating the interface is -down. Similarly, when an underlying interface is removed from an IPMP group, an -\fBRTM_IFINFO\fR message is sent indicating the interface is again up and -\fBRTM_NEWADDR\fR messages are generated for each \fBIFF_UP\fR address found on -the interface. -.sp -.LP -The \fBRT_AWARE\fR socket option at the \fBSOL_ROUTE\fR level allows an -application to indicate its awareness of certain features, which control -routing socket behavior. The supported values are: -.sp -.ne 2 -.na -\fB\fBRTAW_DEFAULT\fR\fR -.ad -.RS 20n -Default awareness. -.RE - -.sp -.ne 2 -.na -\fB\fBRTAW_UNDER_IPMP\fR\fR -.ad -.RS 20n -IPMP underlying interface awareness. When enabled, underlying IP interfaces in -an IPMP group remain visible to the routing socket and events related to them -continue to be generated. -.RE - -.sp -.LP -An \fBRTM_ADD\fR request tied to an underlying IP interface in an IPMP group is -translated to an \fBRTM_ADD\fR request for its corresponding IPMP IP interface. -All routing socket requests other than \fBRTM_ADD\fR and \fBRTM_GET\fR fail -when issued on an underlying IP interface in an IPMP group. -.sp -.LP -If a route is in use when it is deleted, the routing entry is marked down and -removed from the routing table, but the resources associated with it are not -reclaimed until all references to it are released. -.sp -.LP -The \fBRTM_IFINFO\fR, \fBRTM_NEWADDR\fR, and \fBRTM_ADD\fR messages associated -with interface configuration (setting the \fBIFF_UP\fR bit) are normally -delayed until after Duplicate Address Detection completes. Thus, applications -that configure interfaces and wish to wait until the interface is ready can -wait until \fBRTM_IFINFO\fR is returned and \fBSIOCGLIFFLAGS\fR shows that -\fBIFF_DUPLICATE\fR is not set. -.SS "Messages" -.LP -User processes can obtain information about the routing entry to a specific -destination by using a \fBRTM_GET\fR message. -.sp -.LP -Messages include: -.sp -.in +2 -.nf -#define RTM_ADD 0x1 /* Add Route */ -#define RTM_DELETE 0x2 /* Delete Route */ -#define RTM_CHANGE 0x3 /* Change Metrics, Flags, or Gateway */ -#define RTM_GET 0x4 /* Report Information */ -#define RTM_LOSING 0x5 /* Kernel Suspects Partitioning */ -#define RTM_REDIRECT 0x6 /* Told to use different route */ -#define RTM_MISS 0x7 /* Lookup failed on this address */ -#define RTM_LOCK 0x8 /* fix specified metrics */ -#define RTM_OLDADD 0x9 /* caused by SIOCADDRT */ -#define RTM_OLDDEL 0xa /* caused by SIOCDELRT */ -#define RTM_RESOLVE 0xb /* request to resolve dst to LL addr */ -#define RTM_NEWADDR 0xc /* address being added to iface */ -#define RTM_DELADDR 0xd /* address being removed from iface */ -#define RTM_IFINFO 0xe /* iface going up/down etc. */ -.fi -.in -2 - -.sp -.LP -A message header consists of: -.sp -.in +2 -.nf -struct rt_msghdr { - ushort_t rtm_msglen; /* to skip over non-understood messages */ - uchar_t rtm_version; /* future binary compatibility */ - uchar_t rtm_type; /* message type */ - ushort_t rtm_index; /* index for associated ifp */ - pid_t rtm_pid; /* identify sender */ - int rtm_addrs; /* bitmask identifying sockaddrs in msg */ - int rtm_seq; /* for sender to identify action */ - int rtm_errno; /* why failed */ - int rtm_flags; /* flags, incl kern & message, e.g., DONE */ - int rtm_use; /* from rtentry */ - uint_t rtm_inits; /* which values we are initializing */ - - struct rt_metrics rtm_rmx; /* metrics themselves */ -}; -.fi -.in -2 - -.sp -.LP -where -.sp -.in +2 -.nf -struct rt_metrics { - uint32_t rmx_locks; /* Kernel must leave these values alone */ - uint32_t rmx_mtu; /* MTU for this path */ - uint32_t rmx_hopcount; /* max hops expected */ - uint32_t rmx_expire; /* lifetime for route, e.g., redirect */ - uint32_t rmx_recvpipe; /* inbound delay-bandwidth product */ - uint32_t rmx_sendpipe; /* outbound delay-bandwidth product */ - uint32_t rmx_ssthresh; /* outbound gateway buffer limit */ - uint32_t rmx_rtt; /* estimated round trip time */ - uint32_t rmx_rttvar; /* estimated rtt variance */ - uint32_t rmx_pksent; /* packets sent using this route */ -}; - -/* Flags include the values */ - - -#define RTF_UP 0x1 /* route usable */ -#define RTF_GATEWAY 0x2 /* destination is a gateway */ -#define RTF_HOST 0x4 /* host entry (net otherwise) */ -#define RTF_REJECT 0x8 /* host or net unreachable */ -#define RTF_DYNAMIC 0x10 /* created dynamically(by redirect) */ -#define RTF_MODIFIED 0x20 /* modified dynamically(by redirect) */ -#define RTF_DONE 0x40 /* message confirmed */ -#define RTF_MASK 0x80 /* subnet mask present */ -#define RTF_CLONING 0x100 /* generate new routes on use */ -#define RTF_XRESOLVE 0x200 /* external daemon resolves name */ -#define RTF_LLINFO 0x400 /* generated by ARP */ -#define RTF_STATIC 0x800 /* manually added */ -#define RTF_BLACKHOLE 0x1000 /* just discard pkts (during updates) */ -#define RTF_PRIVATE 0x2000 /* do not advertise this route */ -#define RTF_PROTO2 0x4000 /* protocol specific routing flag #2 */ -#define RTF_PROTO1 0x8000 /* protocol specific routing flag #1 */ - -/* Specifiers for metric values in rmx_locks and rtm_inits are */ - -#define RTV_MTU 0x1 /* init or lock _mtu */ -#define RTV_HOPCOUNT 0x2 /* init or lock _hopcount */ -#define RTV_EXPIRE 0x4 /* init or lock _expire */ -#define RTV_RPIPE 0x8 /* init or lock _recvpipe */ -#define RTV_SPIPE 0x10 /* init or lock _sendpipe */ -#define RTV_SSTHRESH 0x20 /* init or lock _ssthresh */ -#define RTV_RTT 0x40 /* init or lock _rtt */ -#define RTV_RTTVAR 0x80 /* init or lock _rttvar */ - -/* Specifiers for which addresses are present in the messages are */ - -#define RTA_DST 0x1 /* destination sockaddr present */ -#define RTA_GATEWAY 0x2 /* gateway sockaddr present */ -#define RTA_NETMASK 0x4 /* netmask sockaddr present */ -#define RTA_GENMASK 0x8 /* cloning mask sockaddr present */ -#define RTA_IFP 0x10 /* interface name sockaddr present */ -#define RTA_IFA 0x20 /* interface addr sockaddr present */ -#define RTA_AUTHOR 0x40 /* sockaddr for author of redirect */ -#define RTA_BRD 0x80 /* for NEWADDR, broadcast or p-p dest addr */ -.fi -.in -2 - -.SH SEE ALSO -.LP -\fBioctl\fR(2), \fBsetsockopt\fR(3SOCKET), \fBshutdown\fR(3SOCKET), -\fBsockaddr\fR(3SOCKET), \fBrouting\fR(7P) -.SH NOTES -.LP -Some of the metrics might not be implemented and return zero. The implemented -metrics are set in \fBrtm_inits\fR. diff --git a/usr/src/man/man7p/routing.7p b/usr/src/man/man7p/routing.7p deleted file mode 100644 index be5d0d832c..0000000000 --- a/usr/src/man/man7p/routing.7p +++ /dev/null @@ -1,163 +0,0 @@ -'\" te -.\" Copyright 1989 AT&T -.\" Copyright (C) 1999, Sun Microsystems, -.\" Inc. All Rights Reserved -.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License. -.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License. -.\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner] -.TH ROUTING 7P "Nov 9, 1999" -.SH NAME -routing \- system support for packet network routing -.SH DESCRIPTION -.sp -.LP -The network facilities provide general packet routing. The \fBrouting\fR -interface described here can be used to maintain the system's IPv4 routing -table. It has been maintained for compatibility with older applications. The -recommended interface for maintaining the system's routing tables is the -routing socket, described at \fBroute\fR(7P). The routing socket can be used to -manipulate both the IPv4 and IPv6 routing tables of the system. Routing table -maintenance may be implemented in applications processes. -.sp -.LP -A simple set of data structures compose a "routing table" used in selecting the -appropriate network interface when transmitting packets. This table contains a -single entry for each route to a specific network or host. The routing table -was designed to support routing for the Internet Protocol (IP), but its -implementation is protocol independent and thus it may serve other protocols as -well. User programs may manipulate this data base with the aid of two -\fBioctl\fR(2) commands, \fBSIOCADDRT\fR and \fBSIOCDELRT\fR. These commands -allow the addition and deletion of a single routing table entry, respectively. -Routing table manipulations may only be carried out by privileged user. -.sp -.LP -A routing table entry has the following form, as defined in -\fB/usr/include/net/route.h\fR: -.sp -.in +2 -.nf -struct rtentry { - unit_t rt_hash; /* to speed lookups */ - struct sockaddr rt_dst; /* key */ - struct sockaddr rt_gateway; /* value */ - short rt_flags; /* up/down?, host/net */ - short rt_refcnt; /* # held references */ - unit_t rt_use; /* raw # packets forwarded */ -/* - * The kernel does not use this field, and without it the structure is - * datamodel independent. - */ -#if !defined(_KERNEL) - struct ifnet *rt_ifp; /* the answer: interface to use */ -#endif /* !defined(_KERNEL) */ -}; -.fi -.in -2 - -.sp -.LP -with \fIrt_flags\fR defined from: -.sp -.in +2 -.nf -#define RTF_UP 0x1 /* route usable */ -#define RTF_GATEWAY 0x2 /* destination is a gateway */ -#define RTF_HOST 0x4 /* host entry (net otherwise) */ -.fi -.in -2 - -.sp -.LP -There are three types of routing table entries: those for a specific host, -those for all hosts on a specific network, and those for any destination not -matched by entries of the first two types, called a wildcard route. Each -network interface installs a routing table entry when it is initialized. -Normally the interface specifies if the route through it is a "direct" -connection to the destination host or network. If the route is direct, the -transport layer of a protocol family usually requests the packet be sent to the -same host specified in the packet. Otherwise, the interface may be requested to -address the packet to an entity different from the eventual recipient; -essentially, the packet is forwarded. -.sp -.LP -Routing table entries installed by a user process may not specify the hash, -reference count, use, or interface fields; these are filled in by the routing -routines. If a route is in use when it is deleted, meaning its \fBrt_refcnt\fR -is non-zero, the resources associated with it will not be reclaimed until all -references to it are removed. -.sp -.LP -User processes read the routing tables through the \fB/dev/ip\fR device. -.sp -.LP -The \fIrt_use\fR field contains the number of packets sent along the route. -This value is used to select among multiple routes to the same destination. -When multiple routes to the same destination exist, the least used route is -selected. -.sp -.LP -A wildcard routing entry is specified with a \fBzero\fR destination address -value. Wildcard routes are used only when the system fails to find a route to -the destination host and network. The combination of wildcard routes and -routing redirects can provide an economical mechanism for routing traffic. -.SH ERRORS -.sp -.ne 2 -.na -\fB\fBEEXIST\fR\fR -.ad -.RS 15n -A request was made to duplicate an existing entry. -.RE - -.sp -.ne 2 -.na -\fB\fBESRCH\fR\fR -.ad -.RS 15n -A request was made to delete a non-existent entry. -.RE - -.sp -.ne 2 -.na -\fB\fBENOBUFS\fR\fR -.ad -.RS 15n -Insufficient resources were available to install a new route. -.RE - -.sp -.ne 2 -.na -\fB\fBENOMEM\fR\fR -.ad -.RS 15n -Insufficient resources were available to install a new route. -.RE - -.sp -.ne 2 -.na -\fB\fBENETUNREACH\fR\fR -.ad -.RS 15n -The gateway is not directly reachable. For example, it does not match the -destination/subnet on any of the network interfaces. -.RE - -.SH FILES -.sp -.ne 2 -.na -\fB\fB/dev/ip\fR\fR -.ad -.RS 11n -\fBIP\fR device driver -.RE - -.SH SEE ALSO -.sp -.LP -\fBroute\fR(1M), \fBioctl\fR(2), \fBroute\fR(7P) diff --git a/usr/src/man/man7p/sctp.7p b/usr/src/man/man7p/sctp.7p deleted file mode 100644 index 9af1cf66fa..0000000000 --- a/usr/src/man/man7p/sctp.7p +++ /dev/null @@ -1,412 +0,0 @@ -'\" te -.\" Copyright (c) 2009, Sun Microsystems, Inc. All Rights Reserved. -.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License. You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. -.\" See the License for the specific language governing permissions and limitations under the License. When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with -.\" the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner] -.TH SCTP 7P "Jul 30, 2009" -.SH NAME -sctp, SCTP \- Stream Control Transmission Protocol -.SH SYNOPSIS -.LP -.nf -#include <sys/socket.h> -#include <netinet/in.h> - -s = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP); -.fi - -.LP -.nf -\fBs = socket(AF_INET, SOCK_SEQPACKET, IPPROTO_SCTP);\fR -.fi - -.LP -.nf -\fBs = socket(AF_INET6, SOCK_STREAM, IPPROTO_SCTP);\fR -.fi - -.LP -.nf -\fBs = socket(AF_INET6, SOCK_SEQPACKET, IPPROTO_SCTP);\fR -.fi - -.SH DESCRIPTION -.sp -.LP -SCTP is a transport protocol layered above the Internet Protocol (IP), or the -Internet Protocol Version 6 (IPv6). SCTP provides a reliable, session oriented, -flow-controlled, two-way transmission of data. It is a message- oriented -protocol and supports framing of individual messages boundaries. An SCTP -association is created between two endpoints for data transfer which is -maintained during the lifetime of the transfer. An SCTP association is setup -between two endpoints using a four-way handshake mechanism with the use of a -cookie to guard against some types of denial of service (DoS) attacks. These -endpoints may be represented by multiple IP addresses. -.sp -.LP -An SCTP message includes a common SCTP header followed by one or more chunks. -Included in the common header is a 32-bit field which contains the checksum -(computed using CRC-32c polynomial) of the entire SCTP packet. -.sp -.LP -SCTP transfers data payloads in the form of DATA chunks. Each DATA chunk -contains a Transmission Sequence Number (TSN), which governs the transmission -of messages and detection of loss. DATA chunk exchanges follow the Transmission -Control Protocol's (TCP) Selective ACK (SACK) mechanism. The receiver -acknowledges data by sending SACK chunks, which not only indicate the -cumulative TSN range received, but also non-cumulative TSNs received, implying -gaps in the received TSN sequence. SACKs are sent using the delayed -acknowledgment method similar to TCP, that is, one SCTP per every other -received packet with an upper bound on the delay (when there are gaps detected -the frequency is increased to one every received packet). Flow and congestion -control follow TCP algorithms: Slow Start, Congestion Avoidance, Fast Recovery -and Fast retransmit. But unlike TCP, SCTP does not support half-close -connection and "urgent" data. -.sp -.LP -SCTP is designed to support a number of functions that are critical for -telephony signalling transport, including multi-streaming. SCTP allows data to -be partitioned into multiple streams that have the property of independent -sequenced delivery so that message loss in any one stream only affects delivery -within that stream. In many applications (particularly telephony signalling), -it is only necessary to maintain sequencing of messages that affect some -resource. Other messages may be delivered without having to maintain overall -sequence integrity. A DATA chunk on an SCTP association contains the Stream -Id/Stream Sequence Number pair, in addition to the TSN, which is used for -sequenced delivery within a stream. -.sp -.LP -SCTP uses IP's host level addressing and adds its own per-host collection of -port addresses. The endpoints of an SCTP association are identified by the -combination of IP address(es) and an SCTP port number. By providing the ability -for an endpoint to have multiple IP addresses, SCTP supports multi-homing, -which makes an SCTP association more resilient in the presence of network -failures (assuming the network is constructed to provided redundancy). For a -multi-homed SCTP association, a single address is used as the primary address, -which is used as the destination address for normal DATA chunk transfers. -Retransmitted DATA chunks are sent over alternate address(es) to increase the -probability of reaching the remote endpoint. Continued failure to send DATA -chunks over the primary address results in selecting an alternate address as -the primary address. Additionally, SCTP monitors the accessibility of all -alternate addresses by sending periodic "heartbeats" chunks. An SCTP -association supports multi-homing by exchanging the available list of addresses -during association setup (as part of its four-way handshake mechanism). An SCTP -endpoint is associated with a local address using the \fBbind\fR(3SOCKET) call. -Subsequently, the endpoint can be associated with additional addresses using -\fBsctp_bindx\fR(3SOCKET). By using a special value of \fBINADDR_ANY\fR with IP -or the unspecified address (all zeros) with IPv6 in the \fBbind()\fR or -\fBsctp_bindx()\fR calls, an endpoint can be bound to all available IP or IPv6 -addresses on the system. -.sp -.LP -SCTP uses a three-way mechanism to allow graceful shutdown, where each endpoint -has confirmation of the DATA chunks received by the remote endpoint prior to -completion of the shutdown. An Abort is provided for error cases when an -immediate shutdown is needed. -.sp -.LP -Applications can access SCTP using the socket interface as a \fBSOCK_STREAM\fR -(one-to-one style) or \fBSOCK_SEQPACKET\fR (one-to-many style) socket type. -.sp -.LP -One-to-one style socket interface supports similar semantics as sockets for -connection oriented protocols, such as TCP. Thus, a passive socket is created -by calling the \fBlisten\fR(3SOCKET) function after binding the socket using -\fBbind()\fR. Associations to this passive socket can be received using -\fBaccept\fR(3SOCKET) function. Active sockets use the \fBconnect\fR(3SOCKET) -function after binding to initiate an association. If an active socket is not -explicitly bound, an implicit binding is performed. If an application wants to -exchange data during the association setup phase, it should not call -\fBconnect()\fR, but use \fBsendto\fR(3SOCKET)/\fBsendmsg\fR(3SOCKET) to -implicitly initiate an association. Once an association has been established, -\fBread\fR(2) and \fBwrite\fR(2) can used to exchange data. Additionally, -\fBsend\fR(3SOCKET), \fBrecv\fR(3SOCKET), \fBsendto()\fR, -\fBrecvfrom\fR(3SOCKET), \fBsendmsg()\fR, and \fBrecvmsg\fR(3SOCKET) can be -used. -.sp -.LP -One-to-many socket interface supports similar semantics as sockets for -connection less protocols, such as UDP (however, unlike UDP, it does not -support broadcast or multicast communications). A passive socket is created -using the \fBlisten()\fR function after binding the socket using \fBbind()\fR. -An \fBaccept()\fR call is not needed to receive associations to this passive -socket (in fact, an \fBaccept()\fR on a one-to-many socket will fail). -Associations are accepted automatically and notifications of new associations -are delivered in \fBrecvmsg()\fR provided notifications are enabled. Active -sockets after binding (implicitly or explicitly) need not call \fBconnect()\fR -to establish an association, implicit associations can be created using -\fBsendmsg()\fR/\fBrecvmsg()\fR or \fBsendto()\fR/\fBrecvfrom()\fR calls. Such -implicit associations cannot be created using \fBsend()\fR and \fBrecv()\fR -calls. On an SCTP socket (one-to-one or one-to-many), an association may be -established using \fBsendmsg()\fR. However, if an association already exists -for the destination address specified in the \fImsg_name\fR member of the -\fImsg\fR parameter, \fBsendmsg()\fR must include the association id in -\fImsg_iov\fR member of the \fImsg\fR parameter (using \fBsctp_sndrcvinfo\fR -structure) for a one-to-many SCTP socket. If the association id is not -provided, \fBsendmsg()\fR fails with \fBEADDRINUSE\fR. On a one-to-one socket -the destination information in the \fImsg\fR parameter is ignored for an -established association. -.sp -.LP -A one-to-one style association can be created from a one-to-many association by -branching it off using the \fBsctp_peeloff\fR(3SOCKET) call; \fBsend()\fR and -\fBrecv()\fR can be used on such peeled off associations. Calling -\fBclose\fR(2) on a one-to-many socket will gracefully shutdown all the -associations represented by that one-to-many socket. -.sp -.LP -The \fBsctp_sendmsg\fR(3SOCKET) and \fBsctp_recvmsg\fR(3SOCKET) functions can -be used to access advanced features provided by SCTP. -.sp -.LP -SCTP provides the following socket options which are set using -\fBsetsockopt\fR(3SOCKET) and read using \fBgetsockopt\fR(3SOCKET). The option -level is the protocol number for SCTP, available from -\fBgetprotobyname\fR(3SOCKET). -.sp -.ne 2 -.na -\fB\fBSCTP_NODELAY\fR\fR -.ad -.sp .6 -.RS 4n -Turn on/off any Nagle-like algorithm (similar to \fBTCP_NODELAY\fR). -.RE - -.sp -.ne 2 -.na -\fB\fBSO_RCVBUF\fR\fR -.ad -.sp .6 -.RS 4n -Set the receive buffer. -.RE - -.sp -.ne 2 -.na -\fB\fBSO_SNDBUF\fR\fR -.ad -.sp .6 -.RS 4n -Set the send buffer. -.RE - -.sp -.ne 2 -.na -\fB\fBSCTP_AUTOCLOSE\fR\fR -.ad -.sp .6 -.RS 4n -For one-to-many style socket, automatically close any association that has been -idle for more than the specified number of seconds. A value of '0' indicates -that no associations should be closed automatically. -.RE - -.sp -.ne 2 -.na -\fB\fBSCTP_EVENTS\fR\fR -.ad -.sp .6 -.RS 4n -Specify various notifications and ancillary data the user wants to receive. -.RE - -.sp -.ne 2 -.na -\fB\fBSCTP_STATUS\fR\fR -.ad -.sp .6 -.RS 4n -Retrieve current status information about an SCTP association. -.RE - -.sp -.ne 2 -.na -\fB\fBSCTP_GET_ASSOC_STATS\fR\fR -.ad -.sp .6 -.RS 4n -Gather and reset per endpoint association statistics. -.RE - -.sp -.LP -Example Usage: -.sp -.in +2 -.nf -#include <netinet/sctp.h> - -struct sctp_assoc_stats stat; -int rc; - -int32_t len = sizeof (stat); - -/* - * Per endpoint stats use the socket descriptor for sctp association. - */ - -/* Gather per endpoint association statistics */ -rc = getsockopt(sd, IPPROTO_SCTP, SCTP_GET_ASSOC_STATS, &stat, &len); -.fi -.in -2 - -.sp -.LP -Extract from the modified header file: -.sp -.in +2 -.nf -sctp.h - - /* - * SCTP socket option used to read per endpoint association statistics. - */ - #define SCTP_GET_ASSOC_STATS 24 - - /* - * A socket user request reads local per endpoint association stats. - * All stats are counts except sas_maxrto, which is the max value - * since the last user request for stats on this endpoint. - */ - typedef struct sctp_assoc_stats { - uint64_t sas_rtxchunks; /* Retransmitted Chunks */ - uint64_t sas_gapcnt; /* Gap Acknowledgements Received */ - uint64_t sas_maxrto; /* Maximum Observed RTO this period */ - uint64_t sas_outseqtsns; /* TSN received > next expected */ - uint64_t sas_osacks; /* SACKs sent */ - uint64_t sas_isacks; /* SACKs received */ - uint64_t sas_octrlchunks; /* Control chunks sent - no dups */ - uint64_t sas_ictrlchunks; /* Control chunks received - no dups */ - uint64_t sas_oodchunks; /* Ordered data chunks sent */ - uint64_t sas_iodchunks; /* Ordered data chunks received */ - uint64_t sas_ouodchunks; /* Unordered data chunks sent */ - uint64_t sas_iuodchunks; /* Unordered data chunks received */ - uint64_t sas_idupchunks; /* Dups received (ordered+unordered) */ -} sctp_assoc_stats_t; -.fi -.in -2 - -.SH MULTIHOMING -.sp -.LP -The ability of SCTP to use multiple addresses in an association can create -issues with some network utilities. This requires a system administrator to be -careful in setting up the system. -.sp -.LP -For example, the \fBtcpd\fR allows an administrator to use a simple form of -address/hostname access control. While \fBtcpd\fR can work with SCTP, the -access control part can have some problems. The \fBtcpd\fR access control is -only based on one of the addresses at association setup time. Once as -association is allowed, no more checking is performed. This means that during -the life time of the association, SCTP packets from different addresses of the -peer host can be received in the system. This may not be what the system -administrator wants as some of the peer's addresses are supposed to be blocked. -.sp -.LP -Another example is the use of IP Filter, which provides several functions such -as IP packet filtering (\fBipf\fR(1M)) and NAT \fBipnat\fR(1M)). For packet -filtering, one issue is that a filter policy can block packets from some of the -addresses of an association while allowing packets from other addresses to go -through. This can degrade SCTP's performance when failure occurs. There is a -more serious issue with IP address rewrite by NAT. At association setup time, -SCTP endpoints exchange IP addresses. But IP Filter is not aware of this. So -when NAT is done on a packet, it may change the address to an unacceptable one. -Thus the SCTP association setup may succeed but packets cannot go through -afterwards when a different IP address is used for the association. -.SH SEE ALSO -.sp -.LP -\fBipf\fR(1M), \fBipnat\fR(1M), \fBndd\fR(1M), \fBioctl\fR(2), \fBclose\fR(2), -\fBread\fR(2), \fBwrite\fR(2), \fBaccept\fR(3SOCKET), \fBbind\fR(3SOCKET), -\fBconnect\fR(3SOCKET), \fBgetprotobyname\fR(3SOCKET), -\fBgetsockopt\fR(3SOCKET), \fBlibsctp\fR(3LIB), \fBlisten\fR(3SOCKET), -\fBrecv\fR(3SOCKET), \fBrecvfrom\fR(3SOCKET), \fBrecvmsg\fR(3SOCKET), -\fBsctp_bindx\fR(3SOCKET), \fBsctp_getladdrs\fR(3SOCKET), -\fBsctp_getpaddrs\fR(3SOCKET), \fBsctp_freepaddrs\fR(3SOCKET), -\fBsctp_opt_info\fR(3SOCKET), \fBsctp_peeloff\fR(3SOCKET), -\fBsctp_recvmsg\fR(3SOCKET), \fBsctp_sendmsg\fR(3SOCKET), \fBsend\fR(3SOCKET), -\fBsendmsg\fR(3SOCKET), \fBsendto\fR(3SOCKET), \fBsocket\fR(3SOCKET), -\fBipfilter\fR(5), \fBtcp\fR(7P), \fBudp\fR(7P), \fBinet\fR(7P), -\fBinet6\fR(7P), \fBip\fR(7P), \fBip6\fR(7P) -.sp -.LP -R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. -Rytina, M. Kalla, L. Zang, V. Paxson, \fIRFC 2960, Stream Control Transmission -Protocol\fR, October 2000 -.sp -.LP -L. Ong, J. Yoakum, \fIRFC 3286, An Introduction to Stream Control Transmission -Protocol (SCTP)\fR, May 2002 -.sp -.LP -J. Stone, R. Stewart, D. Otis, \fIRFC 3309, Stream Control Transmission -Protocol (SCTP) Checksum Change\fR, September 2002. -.SH DIAGNOSTICS -.sp -.LP -A socket operation may fail if: -.sp -.ne 2 -.na -\fB\fBEPROTONOSUPPORT\fR\fR -.ad -.RS 19n -The socket type is other than \fBSOCK_STREAM\fR and \fBSOCK_SEQPACKET\fR. -.RE - -.sp -.ne 2 -.na -\fB\fBETIMEDOUT\fR\fR -.ad -.RS 19n -An association was dropped due to excessive retransmissions. -.RE - -.sp -.ne 2 -.na -\fB\fBECONNREFUSED\fR\fR -.ad -.RS 19n -The remote peer refused establishing an association. -.RE - -.sp -.ne 2 -.na -\fB\fBEADDRINUSE\fR\fR -.ad -.RS 19n -A \fBbind()\fR operation was attempted on a socket with a network address/port -pair that has already been bound to another socket. -.RE - -.sp -.ne 2 -.na -\fB\fBEINVAL\fR\fR -.ad -.RS 19n -A \fBbind()\fR operation was attempted on a socket with an invalid network -address. -.RE - -.sp -.ne 2 -.na -\fB\fBEPERM\fR\fR -.ad -.RS 19n -A \fBbind()\fR operation was attempted on a socket with a "reserved" port -number and the effective user ID of the process was not the privileged user. -.RE - diff --git a/usr/src/man/man7p/sip.7p b/usr/src/man/man7p/sip.7p deleted file mode 100644 index 2a60163606..0000000000 --- a/usr/src/man/man7p/sip.7p +++ /dev/null @@ -1,27 +0,0 @@ -'\" te -.\" Copyright (c) 2004, Sun Microsystems, Inc. All Rights Reserved -.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License. -.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License. -.\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner] -.TH SIP 7P "Jul 29, 2004" -.SH NAME -sip \- SIP Proxy/registrar/redirect server -.SH DESCRIPTION -.sp -.LP -Solaris supports deployment of VoIP/SIP services by providing an \fIRFC -3261\fR-compliant SIP proxy/registrar/redirect server called SER from -\fIiptel.org\fR. -.sp -.LP -See the \fBser(8)\fR man page under \fB/usr/sfw/man\fR. -.SH FILES -.sp -.LP -\fB/etc/sfw/ser/ser.cfg\fR -.sp -.LP -\fB/etc/sfw/ser/README.solaris.ser\fR -.sp -.LP -\fB/usr/sfw/share/doc/ser/README\fR diff --git a/usr/src/man/man7p/slp.7p b/usr/src/man/man7p/slp.7p deleted file mode 100644 index 1f45c63317..0000000000 --- a/usr/src/man/man7p/slp.7p +++ /dev/null @@ -1,127 +0,0 @@ -'\" te -.\" Copyright (C) 1999, Sun Microsystems, Inc. -.\" All Rights Reserved. -.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License. -.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License. -.\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner] -.TH SLP 7P "Nov 17, 1999" -.SH NAME -slp \- Service Location Protocol -.SH DESCRIPTION -.sp -.LP -The Service Location Protocol (\fBSLP\fR) is a dynamic service discovery -protocol that runs on top of the Internet Protocol (\fBIP\fR). The protocol is -specified by the \fBIETF\fR standard-track documents \fIRFC 2165\fR, \fIRFC -2608\fR, \fIRFC 2609\fR; the \fBAPI\fR is documented in \fIRFC 2614\fR. . -.sp -.LP -There are two components to the \fBSLP\fR technology. The first is a daemon, -\fBslpd\fR(1M), which coordinates \fBSLP\fR operations. The second is a -software library, \fBslp_api\fR(3SLP), through which processes access a public -\fBAPI\fR. Both components are configured by means of the \fBSLP\fR -configuration file, \fBslp.conf\fR(4). -.sp -.LP -The \fBSLP\fR \fBAPI\fR is useful for two types of processes: -.sp -.ne 2 -.na -\fBClient Applications\fR -.ad -.RS 23n -Services and service information can be requested from the \fBAPI\fR. Clients -do not need to know the location of a required service, only the type of -service, and optionally, the service characteristics. \fBSLP\fR will supply -the location and other information to the client through the \fBAPI\fR. -.RE - -.sp -.ne 2 -.na -\fBServer Processes\fR -.ad -.RS 23n -Programs that offer network services use the \fBSLP\fR \fBAPI\fR to advertise -their location as well as other service information. The advertisement can -optionally include attributes describing the service. Advertisements are -accompanied by a lifetime; when the lifetime expires, the advertisement is -flushed, unless it is refreshed prior to expiration. -.RE - -.sp -.LP -\fBAPI\fR libraries are available for both the C and Java languages. -.sp -.LP -\fBSLP\fR provides the following additional features: -.RS +4 -.TP -.ie t \(bu -.el o -\fBslpd\fR(1M) can be configured to function as a transparent directory agent. -This feature makes \fBSLP\fR scalable to the enterprise. System administrators -can configure directory agents to achieve a number of different strategies for -scalability. -.RE -.RS +4 -.TP -.ie t \(bu -.el o -\fBSLP\fR service advertising and discovery is performed in scopes. Unless -otherwise configured, all discovery and all advertisements are in the scope -\fIdefault\fR. In the case of a larger network, scopes can be used to group -services and client systems so that users will only find those services which -are physically near them, belong to their department, or satisfy the specified -criteria. Administrators can configure these scopes to achieve different -service provider strategies. -.RE -.RS +4 -.TP -.ie t \(bu -.el o -Services may be registered by proxy through a serialized registration file. -This is an alternative to registering services through the \fBAPI\fR. See -\fBslpd.reg\fR(4) for more information. -.RE -.SH ATTRIBUTES -.sp -.LP -See \fBattributes\fR(5) for descriptions of the following attributes: -.sp - -.sp -.TS -box; -c | c -l | l . -ATTRIBUTE TYPE ATTRIBUTE VALUE -_ -CSI CSI-enabled -_ -Interface Stability Standard -_ -MT-Level MT-Safe -.TE - -.SH SEE ALSO -.sp -.LP -\fBslpd\fR(1M), \fBslp_api\fR(3SLP), \fBslp.conf\fR(4), \fBslpd.reg\fR(4), -\fBattributes\fR(5) -.sp -.LP -Guttman, E., Perkins, C., Veizades, J., and Day, M., \fIRFC 2608, Service -Location Protocol, Version 2\fR, The Internet Society, June 1999. -.sp -.LP -Guttman, E., Perkins, C., and Kempf, J., \fIRFC 2609, Service Templates and -Service: Schemes\fR, The Internet Society, June 1999. -.sp -.LP -Kempf, J. and Guttman, E., \fIRFC 2614, An API for Service Location\fR, The -Internet Society, June 1999. -.sp -.LP -Veizades, J., Guttman, E., Perkins, C., and Kaplan, S., \fIRFC 2165, Service -Location Protocol\fR, Network Working Group, 1997. diff --git a/usr/src/man/man7p/tcp.7p b/usr/src/man/man7p/tcp.7p deleted file mode 100644 index 6dc5413c42..0000000000 --- a/usr/src/man/man7p/tcp.7p +++ /dev/null @@ -1,898 +0,0 @@ -'\" -.\" This file and its contents are supplied under the terms of the -.\" Common Development and Distribution License ("CDDL"), version 1.0. -.\" You may only use this file in accordance with the terms of version -.\" 1.0 of the CDDL. -.\" -.\" A full copy of the text of the CDDL should have accompanied this -.\" source. A copy of the CDDL is also available via the Internet at -.\" http://www.illumos.org/license/CDDL. -.\" -.\" -.\" Copyright (c) 2006, Sun Microsystems, Inc. All Rights Reserved. -.\" Copyright (c) 2011 Nexenta Systems, Inc. All rights reserved. -.\" Copyright 2019 Joyent, Inc. -.\" Copyright 2022 Oxide Computer Company -.\" Copyright 1989 AT&T -.\" -.Dd "Jan 07, 2019" -.Dt TCP 7P -.Os -.Sh NAME -.Nm tcp , -.Nm TCP -.Nd Internet Transmission Control Protocol -.Sh SYNOPSIS -.In sys/socket.h -.In netinet/in.h -.In netinet/tcp.h -.Bd -literal -s = socket(AF_INET, SOCK_STREAM, 0); -s = socket(AF_INET6, SOCK_STREAM, 0); -t = t_open("/dev/tcp", O_RDWR); -t = t_open("/dev/tcp6", O_RDWR); -.Ed -.Sh DESCRIPTION -TCP is the virtual circuit protocol of the Internet protocol family. -It provides reliable, flow-controlled, in-order, two-way transmission of data. -It is a byte-stream protocol layered above the Internet Protocol -.Po Sy IP Pc , -or the Internet Protocol Version 6 -.Po Sy IPv6 Pc , -the Internet protocol family's -internetwork datagram delivery protocol. -.Pp -Programs can access TCP using the socket interface as a -.Dv SOCK_STREAM -socket type, or using the Transport Level Interface -.Po Sy TLI Pc -where it supports the connection-oriented -.Po Dv BT_COTS_ORD Pc -service type. -.Pp -A checksum over all data helps TCP provide reliable communication. -Using a window-based flow control mechanism that makes use of positive -acknowledgements, sequence numbers, and a retransmission strategy, TCP can -usually recover when datagrams are damaged, delayed, duplicated or delivered -out of order by the underlying medium. -.Pp -TCP provides several socket options, defined in -.In netinet/tcp.h -and described throughout this document, -which may be set using -.Xr setsockopt 3SOCKET -and read using -.Xr getsockopt 3SOCKET . -The -.Fa level -argument for these calls is the protocol number for TCP, available from -.Xr getprotobyname 3SOCKET . -IP level options may also be used with TCP. -See -.Xr ip 7P -and -.Xr ip6 7P . -.Ss "Listening And Connecting" -TCP uses IP's host-level addressing and adds its own per-host -collection of -.Dq port addresses . -The endpoints of a TCP connection are -identified by the combination of an IPv4 or IPv6 address and a TCP -port number. -Although other protocols, such as the User Datagram Protocol -.Po Sy UDP Pc , -may use the same host and port address format, the port space of these -protocols is distinct. -See -.Xr inet 7P -and -.Xr inet6 7P -for details on -the common aspects of addressing in the Internet protocol family. -.Pp -Sockets utilizing TCP are either -.Dq active -or -.Dq passive . -Active sockets -initiate connections to passive sockets. -Passive sockets must have their local IPv4 or IPv6 address and TCP port number -bound with the -.Xr bind 3SOCKET -system call after the socket is created. -If an active socket has not been bound by the time -.Xr connect 3SOCKET -is called, then the operating system will choose a local address and port for -the application. -By default, TCP sockets are active. -A passive socket is created by calling the -.Xr listen 3SOCKET -system call after binding, which establishes a queueing parameter for the -passive socket. -Connections to the passive socket can then be received using the -.Xr accept 3SOCKET -system call. -Active sockets use the -.Xr connect 3SOCKET -call after binding to initiate connections. -.Pp -If incoming connection requests include an IP source route option, then the -reverse source route will be used when responding. -.Pp -By using the special value -.Dv INADDR_ANY -with IPv4, or the unspecified -address (all zeroes) with IPv6, the local IP address can be left -unspecified in the -.Fn bind -call by either active or passive TCP -sockets. -This feature is usually used if the local address is either unknown or -irrelevant. -If left unspecified, the local IP address will be bound at connection time to -the address of the network interface used to service the connection. -For passive sockets, this is the destination address used by the connecting -peer. -For active sockets, this is usually an address on the same subnet as the -destination or default gateway address, although the rules can be more complex. -See -.Sy "Source Address Selection" -in -.Xr inet6 7P -for a detailed discussion of how this works in IPv6. -.Pp -Note that no two TCP sockets can be bound to the same port unless the bound IP -addresses are different. -IPv4 -.Dv INADDR_ANY -and IPv6 unspecified addresses compare as equal to any IPv4 or IPv6 address. -For example, if a socket is bound to -.Dv INADDR_ANY -or the unspecified address and port -.Em N , -no other socket can bind to port -.Em N , -regardless of the binding address. -This special consideration of -.Dv INADDR_ANY -and the unspecified address can be changed using the socket option -.Dv SO_REUSEADDR . -If -.Dv SO_REUSEADDR -is set on a socket doing a bind, IPv4 -.Dv INADDR_ANY -and the IPv6 unspecified address do not compare as equal to any IP address. -This means that as long as the two sockets are not both bound to -.Dv INADDR_ANY , -the unspecified address, or the same IP address, then the two sockets can be -bound to the same port. -.Pp -If an application does not want to allow another socket using the -.Dv SO_REUSEADDR -option to bind to a port its socket is bound to, the -application can set the socket-level -.Po Dv SOL_SOCKET Pc -option -.Dv SO_EXCLBIND -on a socket. -The -option values of 0 and 1 mean enabling and disabling the option respectively. -Once this option is enabled on a socket, no other socket can be bound to the -same port. -.Ss "Sending And Receiving Data" -Once a connection has been established, data can be exchanged using the -.Xr read 2 -and -.Xr write 2 -system calls. -If, after sending data, the local TCP receives no acknowledgements from its -peer for a period of time (for example, if the remote machine crashes), the -connection is closed and an error is returned. -.Pp -When a peer is sending data, it will only send up to the advertised -.Dq receive window , -which is determined by how much more data the recipient can fit in its buffer. -Applications can use the socket-level option -.Dv SO_RCVBUF -to increase or decrease the receive buffer size. -Similarly, the socket-level option -.Dv SO_SNDBUF -can be used to allow TCP to buffer more unacknowledged and unsent data locally. -.Pp -Under most circumstances, TCP will send data when it is written by the -application. -When outstanding data has not yet been acknowledged, though, TCP will gather -small amounts of output to be sent as a single packet once an acknowledgement -has been received. -Usually referred to as Nagle's Algorithm (RFC 896), this behavior helps prevent -flooding the network with many small packets. -.Pp -However, for some highly interactive clients (such as remote shells or -windowing systems that send a stream of keypresses or mouse events), this -batching may cause significant delays. -To disable this behavior, TCP provides a boolean socket option, -.Dv TCP_NODELAY . -.Pp -Conversely, for other applications, it may be desirable for TCP not to send out -any data until a full TCP segment can be sent. -To enable this behavior, an application can use the TCP-level socket option -.Dv TCP_CORK . -When set to a non-zero value, TCP will only send out a full TCP segment. -When -.Dv TCP_CORK -is set to zero after it has been enabled, all currently buffered data is sent -out (as permitted by the peer's receive window and the current congestion -window). -.Pp -Still other latency-sensitive applications rely on receiving a quick -notification that their packets have been successfully received. -To satisfy the requirements of those applications, setting the -.Dv TCP_QUICKACK -option to a non-zero value will instruct the TCP stack to send an acknowlegment -immediately upon receipt of a packet, rather than waiting to acknowledge -multiple packets at once. -.Pp -TCP provides an urgent data mechanism, which may be invoked using the -out-of-band provisions of -.Xr send 3SOCKET . -The caller may mark one byte as -.Dq urgent -with the -.Dv MSG_OOB -flag to -.Xr send 3SOCKET . -This sets an -.Dq urgent pointer -pointing to this byte in the TCP stream. -The receiver on the other side of the stream is notified of the urgent data by a -.Dv SIGURG -signal. -The -.Dv SIOCATMARK -.Xr ioctl 2 -request returns a value indicating whether the stream is at the urgent mark. -Because the system never returns data across the urgent mark in a single -.Xr read 2 -call, it is possible to -advance to the urgent data in a simple loop which reads data, testing the -socket with the -.Dv SIOCATMARK -.Fn ioctl -request, until it reaches the mark. -.Ss "Congestion Control" -TCP follows the congestion control algorithm described in RFC 2581, and -also supports the initial congestion window (cwnd) changes in RFC 3390. -The initial cwnd calculation can be overridden by the socket option -.Dv TCP_INIT_CWND . -An application can use this option to set the initial cwnd to a -specified number of TCP segments. -This applies to the cases when the connection -first starts and restarts after an idle period. -The process must have the -.Dv PRIV_SYS_NET_CONFIG -privilege if it wants to specify a number greater than that -calculated by RFC 3390. -.Pp -The operating system also provides alternative algorithms that may be more -appropriate for your application, including the CUBIC congestion control -algorithm described in RFC 8312. -These can be configured system-wide using -.Xr ipadm 1M , -or on a per-connection basis with the TCP-level socket option -.Dv TCP_CONGESTION , -whose argument is the name of the algorithm to use -.Pq for example Dq cubic . -If the requested algorithm does not exist, then -.Fn setsockopt -will fail, and -.Va errno -will be set to -.Er ENOENT . -.Ss "TCP Keep-Alive" -Since TCP determines whether a remote peer is no longer reachable by timing out -waiting for acknowledgements, a host that never sends any new data may never -notice a peer that has gone away. -While consumers can avoid this problem by sending their own periodic heartbeat -messages (Transport Layer Security does this, for example), -TCP describes an optional keep-alive mechanism in RFC 1122. -Applications can enable it using the socket-level option -.Dv SO_KEEPALIVE . -When enabled, the first keep-alive probe is sent out after a TCP connection is -idle for two hours. -If the peer does not respond to the probe within eight minutes, the TCP -connection is aborted. -An application can alter the probe behavior using the following TCP-level -socket options: -.Bl -tag -offset indent -width 16m -.It Dv TCP_KEEPALIVE_THRESHOLD -Determines the interval for sending the first probe. -The option value is specified as an unsigned integer in milliseconds. -The system default is controlled by the TCP -.Nm ndd -parameter -.Cm tcp_keepalive_interval . -The minimum value is ten seconds. -The maximum is ten days, while the default is two hours. -.It Dv TCP_KEEPALIVE_ABORT_THRESHOLD -If TCP does not receive a response to the probe, then this option determines -how long to wait before aborting a TCP connection. -The option value is an unsigned integer in milliseconds. -The value zero indicates that TCP should never time -out and abort the connection when probing. -The system default is controlled by the TCP -.Nm ndd -parameter -.Sy tcp_keepalive_abort_interval . -The default is eight minutes. -.It Dv TCP_KEEPIDLE -This option, like -.Dv TCP_KEEPALIVE_THRESHOLD , -determines the interval for sending the first probe, except that -the option value is an unsigned integer in -.Sy seconds . -It is provided primarily for compatibility with other Unix flavors. -.It Dv TCP_KEEPCNT -This option specifies the number of keep-alive probes that should be sent -without any response from the peer before aborting the connection. -.It Dv TCP_KEEPINTVL -This option specifies the interval in seconds between successive, -unacknowledged keep-alive probes. -.El -.Ss "Additional Configuration" -illumos supports TCP Extensions for High Performance (RFC 7323) -which includes the window scale and timestamp options, and Protection Against -Wrap Around Sequence Numbers -.Po Sy PAWS Pc . -Note that if timestamps are negotiated on -a connection, received segments without timestamps on that connection are -silently dropped per the suggestion in the RFC. illumos also supports Selective -Acknowledgment -.Po Sy SACK Pc -capabilities (RFC 2018) and Explicit Congestion -Notification -.Po Sy ECN Pc -mechanism (RFC 3168). -.Pp -Turn on the window scale option in one of the following ways: -.Bl -bullet -offset indent -width 4m -.It -An application can set -.Dv SO_SNDBUF -or -.Dv SO_RCVBUF -size in the -.Fn setsockopt -option to be larger than 64K. -This must be done -.Em before -the program calls -.Fn listen -or -.Fn connect , -because the window scale -option is negotiated when the connection is established. -Once the connection -has been made, it is too late to increase the send or receive window beyond the -default TCP limit of 64K. -.It -For all applications, use -.Xr ndd 1M -to modify the configuration parameter -.Cm tcp_wscale_always . -If -.Cm tcp_wscale_always -is set to -.Sy 1 , -the -window scale option will always be set when connecting to a remote system. -If -.Cm tcp_wscale_always -is -.Sy 0 , -the window scale option will be set only if -the user has requested a send or receive window larger than 64K. -The default value of -.Cm tcp_wscale_always -is -.Sy 1 . -.It -Regardless of the value of -.Cm tcp_wscale_always , -the window scale option -will always be included in a connect acknowledgement if the connecting system -has used the option. -.El -.Pp -Turn on SACK capabilities in the following way: -.Bl -bullet -offset indent -width 4m -.It -Use -.Nm ndd -to modify the configuration parameter -.Cm tcp_sack_permitted . -If -.Cm tcp_sack_permitted -is set to -.Sy 0 , -TCP will not accept SACK or send out SACK information. -If -.Cm tcp_sack_permitted -is -set to -.Sy 1 , -TCP will not initiate a connection with SACK permitted option in the -.Sy SYN -segment, but will respond with SACK permitted option in the -.Sy SYN|ACK -segment if an incoming connection request has the SACK permitted option. -This means that TCP will only accept SACK information if the other side of the -connection also accepts SACK information. -If -.Cm tcp_sack_permitted -is set to -.Sy 2 , -it will both initiate and accept connections with SACK information. -The default for -.Cm tcp_sack_permitted -is -.Sy 2 -.Pq active enabled . -.El -.Pp -Turn on the TCP ECN mechanism in the following way: -.Bl -bullet -offset indent -width 4m -.It -Use -.Nm ndd -to modify the configuration parameter -.Cm tcp_ecn_permitted . -If -.Cm tcp_ecn_permitted -is set to -.Sy 0 , -then TCP will not negotiate with a peer that supports ECN mechanism. -If -.Cm tcp_ecn_permitted -is set to -.Sy 1 -when initiating a connection, TCP will not tell a peer that it supports -.Sy ECN -mechanism. -However, it will tell a peer that it supports -.Sy ECN -mechanism when accepting a new incoming connection request if the peer -indicates that it supports -.Sy ECN -mechanism in the -.Sy SYN -segment. -If -.Cm tcp_ecn_permitted -is set to 2, in addition to negotiating with a peer on -.Sy ECN -mechanism when accepting connections, TCP will indicate in the outgoing -.Sy SYN -segment that it supports -.Sy ECN -mechanism when TCP makes active outgoing connections. -The default for -.Cm tcp_ecn_permitted -is 1. -.El -.Pp -Turn on the timestamp option in the following way: -.Bl -bullet -offset indent -width 4m -.It -Use -.Nm ndd -to modify the configuration parameter -.Cm tcp_tstamp_always . -If -.Cm tcp_tstamp_always -is -.Sy 1 , -the timestamp option will always be set -when connecting to a remote machine. -If -.Cm tcp_tstamp_always -is -.Sy 0 , -the timestamp option will not be set when connecting to a remote system. -The -default for -.Cm tcp_tstamp_always -is -.Sy 0 . -.It -Regardless of the value of -.Cm tcp_tstamp_always , -the timestamp option will -always be included in a connect acknowledgement (and all succeeding packets) if -the connecting system has used the timestamp option. -.El -.Pp -Use the following procedure to turn on the timestamp option only when the -window scale option is in effect: -.Bl -bullet -offset indent -width 4m -.It -Use -.Nm ndd -to modify the configuration parameter -.Cm tcp_tstamp_if_wscale . -Setting -.Cm tcp_tstamp_if_wscale -to -.Sy 1 -will cause the timestamp option -to be set when connecting to a remote system, if the window scale option has -been set. -If -.Cm tcp_tstamp_if_wscale -is -.Sy 0 , -the timestamp option will -not be set when connecting to a remote system. -The default for -.Cm tcp_tstamp_if_wscale -is -.Sy 1 . -.El -.Pp -Protection Against Wrap Around Sequence Numbers -.Po Sy PAWS Pc -is always used when the -timestamp option is set. -.Pp -The operating system also supports multiple methods of generating initial sequence numbers. -One of these methods is the improved technique suggested in RFC 1948. -We -.Em HIGHLY -recommend that you set sequence number generation parameters as -close to boot time as possible. -This prevents sequence number problems on -connections that use the same connection-ID as ones that used a different -sequence number generation. -The -.Sy svc:/network/initial:default -service configures the initial sequence number generation. -The service reads the value contained in the configuration file -.Pa /etc/default/inetinit -to determine which method to use. -.Pp -The -.Pa /etc/default/inetinit -file is an unstable interface, and may change in future releases. -.Sh EXAMPLES -.Ss Example 1: Connecting to a server -.Bd -literal -$ gcc -std=c99 -Wall -lsocket -o client client.c -$ cat client.c -#include <sys/socket.h> -#include <netinet/in.h> -#include <netinet/tcp.h> -#include <netdb.h> -#include <stdio.h> -#include <string.h> -#include <unistd.h> - -int -main(int argc, char *argv[]) -{ - struct addrinfo hints, *gair, *p; - int fd, rv, rlen; - char buf[1024]; - int y = 1; - - if (argc != 3) { - fprintf(stderr, "%s <host> <port>\\n", argv[0]); - return (1); - } - - memset(&hints, 0, sizeof (hints)); - hints.ai_family = PF_UNSPEC; - hints.ai_socktype = SOCK_STREAM; - - if ((rv = getaddrinfo(argv[1], argv[2], &hints, &gair)) != 0) { - fprintf(stderr, "getaddrinfo() failed: %s\\n", - gai_strerror(rv)); - return (1); - } - - for (p = gair; p != NULL; p = p->ai_next) { - if ((fd = socket( - p->ai_family, - p->ai_socktype, - p->ai_protocol)) == -1) { - perror("socket() failed"); - continue; - } - - if (connect(fd, p->ai_addr, p->ai_addrlen) == -1) { - close(fd); - perror("connect() failed"); - continue; - } - - break; - } - - if (p == NULL) { - fprintf(stderr, "failed to connect to server\\n"); - return (1); - } - - freeaddrinfo(gair); - - if (setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE, &y, - sizeof (y)) == -1) { - perror("setsockopt(SO_KEEPALIVE) failed"); - return (1); - } - - while ((rlen = read(fd, buf, sizeof (buf))) > 0) { - fwrite(buf, rlen, 1, stdout); - } - - if (rlen == -1) { - perror("read() failed"); - } - - fflush(stdout); - - if (close(fd) == -1) { - perror("close() failed"); - } - - return (0); -} -$ ./client 127.0.0.1 8080 -hello -$ ./client ::1 8080 -hello -.Ed -.Ss Example 2: Accepting client connections -.Bd -literal -$ gcc -std=c99 -Wall -lsocket -o server server.c -$ cat server.c -#include <sys/socket.h> -#include <netinet/in.h> -#include <netinet/tcp.h> -#include <netdb.h> -#include <stdio.h> -#include <string.h> -#include <unistd.h> -#include <arpa/inet.h> - -void -logmsg(struct sockaddr *s, int bytes) -{ - char dq[INET6_ADDRSTRLEN]; - - switch (s->sa_family) { - case AF_INET: { - struct sockaddr_in *s4 = (struct sockaddr_in *)s; - inet_ntop(AF_INET, &s4->sin_addr, dq, sizeof (dq)); - fprintf(stdout, "sent %d bytes to %s:%d\\n", - bytes, dq, ntohs(s4->sin_port)); - break; - } - case AF_INET6: { - struct sockaddr_in6 *s6 = (struct sockaddr_in6 *)s; - inet_ntop(AF_INET6, &s6->sin6_addr, dq, sizeof (dq)); - fprintf(stdout, "sent %d bytes to [%s]:%d\\n", - bytes, dq, ntohs(s6->sin6_port)); - break; - } - default: - fprintf(stdout, "sent %d bytes to unknown client\\n", - bytes); - break; - } -} - -int -main(int argc, char *argv[]) -{ - struct addrinfo hints, *gair, *p; - int sfd, cfd; - int slen, wlen, rv; - - if (argc != 3) { - fprintf(stderr, "%s <port> <message>\\n", argv[0]); - return (1); - } - - slen = strlen(argv[2]); - - memset(&hints, 0, sizeof (hints)); - hints.ai_family = PF_UNSPEC; - hints.ai_socktype = SOCK_STREAM; - hints.ai_flags = AI_PASSIVE; - - if ((rv = getaddrinfo(NULL, argv[1], &hints, &gair)) != 0) { - fprintf(stderr, "getaddrinfo() failed: %s\\n", - gai_strerror(rv)); - return (1); - } - - for (p = gair; p != NULL; p = p->ai_next) { - if ((sfd = socket( - p->ai_family, - p->ai_socktype, - p->ai_protocol)) == -1) { - perror("socket() failed"); - continue; - } - - if (bind(sfd, p->ai_addr, p->ai_addrlen) == -1) { - close(sfd); - perror("bind() failed"); - continue; - } - - break; - } - - if (p == NULL) { - fprintf(stderr, "server failed to bind()\\n"); - return (1); - } - - freeaddrinfo(gair); - - if (listen(sfd, 1024) != 0) { - perror("listen() failed"); - return (1); - } - - fprintf(stdout, "waiting for clients...\\n"); - - for (int times = 0; times < 5; times++) { - struct sockaddr_storage stor; - socklen_t alen = sizeof (stor); - struct sockaddr *addr = (struct sockaddr *)&stor; - - if ((cfd = accept(sfd, addr, &alen)) == -1) { - perror("accept() failed"); - continue; - } - - wlen = 0; - - do { - wlen += write(cfd, argv[2] + wlen, slen - wlen); - } while (wlen < slen); - - logmsg(addr, wlen); - - if (close(cfd) == -1) { - perror("close(cfd) failed"); - } - } - - if (close(sfd) == -1) { - perror("close(sfd) failed"); - } - - fprintf(stdout, "finished.\\n"); - - return (0); -} -$ ./server 8080 $'hello\\n' -waiting for clients... -sent 6 bytes to [::ffff:127.0.0.1]:59059 -sent 6 bytes to [::ffff:127.0.0.1]:47448 -sent 6 bytes to [::ffff:127.0.0.1]:54949 -sent 6 bytes to [::ffff:127.0.0.1]:55186 -sent 6 bytes to [::1]:62256 -finished. -.Ed -.Sh DIAGNOSTICS -A socket operation may fail if: -.Bl -tag -offset indent -width 16m -.It Er EISCONN -A -.Fn connect -operation was attempted on a socket on which a -.Fn connect -operation had already been performed. -.It Er ETIMEDOUT -A connection was dropped due to excessive retransmissions. -.It Er ECONNRESET -The remote peer forced the connection to be closed (usually because the remote -machine has lost state information about the connection due to a crash). -.It Er ECONNREFUSED -The remote peer actively refused connection establishment (usually because no -process is listening to the port). -.It Er EADDRINUSE -A -.Fn bind -operation was attempted on a socket with a network address/port pair that has -already been bound to another socket. -.It Er EADDRNOTAVAIL -A -.Fn bind -operation was attempted on a socket with a network address for which no network -interface exists. -.It Er EACCES -A -.Fn bind -operation was attempted with a -.Dq reserved -port number and the effective user ID of the process was not the privileged user. -.It Er ENOBUFS -The system ran out of memory for internal data structures. -.El -.Sh SEE ALSO -.Xr svcs 1 , -.Xr ndd 1M , -.Xr svcadm 1M , -.Xr ioctl 2 , -.Xr read 2 , -.Xr write 2 , -.Xr accept 3SOCKET , -.Xr bind 3SOCKET , -.Xr connect 3SOCKET , -.Xr getprotobyname 3SOCKET , -.Xr getsockopt 3SOCKET , -.Xr listen 3SOCKET , -.Xr send 3SOCKET , -.Xr smf 5 , -.Xr inet 7P , -.Xr inet6 7P , -.Xr ip 7P , -.Xr ip6 7P -.Rs -.%A "K. Ramakrishnan" -.%A "S. Floyd" -.%A "D. Black" -.%T "The Addition of Explicit Congestion Notification (ECN) to IP" -.%R "RFC 3168" -.%D "September 2001" -.Re -.Rs -.%A "M. Mathias" -.%A "J. Mahdavi" -.%A "S. Ford" -.%A "A. Romanow" -.%T "TCP Selective Acknowledgement Options" -.%R "RFC 2018" -.%D "October 1996" -.Re -.Rs -.%A "S. Bellovin" -.%T "Defending Against Sequence Number Attacks" -.%R "RFC 1948" -.%D "May 1996" -.Re -.Rs -.%A "D. Borman" -.%A "B. Braden" -.%A "V. Jacobson" -.%A "R. Scheffenegger, Ed." -.%T "TCP Extensions for High Performance" -.%R "RFC 7323" -.%D "September 2014" -.Re -.Rs -.%A "Jon Postel" -.%T "Transmission Control Protocol - DARPA Internet Program Protocol Specification" -.%R "RFC 793" -.%C "Network Information Center, SRI International, Menlo Park, CA." -.%D "September 1981" -.Re -.Sh NOTES -The -.Sy tcp -service is managed by the service management facility, -.Xr smf 5 , -under the service identifier -.Sy svc:/network/initial:default . -.Pp -Administrative actions on this service, such as enabling, disabling, or -requesting restart, can be performed using -.Xr svcadm 1M . -The service's -status can be queried using the -.Xr svcs 1 -command. diff --git a/usr/src/man/man7p/udp.7p b/usr/src/man/man7p/udp.7p deleted file mode 100644 index 723cbb8e6b..0000000000 --- a/usr/src/man/man7p/udp.7p +++ /dev/null @@ -1,248 +0,0 @@ -'\" te -.\" Copyright 2006 AT&T -.\" Copyright (C) 2006, Sun Microsystems, Inc. All Rights Reserved -.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License. -.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License. -.\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner] -.TH UDP 7P "Jul 4, 2006" -.SH NAME -udp, UDP \- Internet User Datagram Protocol -.SH SYNOPSIS -.LP -.nf -\fB#include <sys/socket.h>\fR -.fi - -.LP -.nf -\fB#include <netinet/in.h>\fR -.fi - -.LP -.nf -\fBs = socket(AF_INET, SOCK_DGRAM, 0);\fR -.fi - -.LP -.nf -\fBs = socket(AF_INET6, SOCK_DGRAM, 0);\fR -.fi - -.LP -.nf -\fBt = t_open("/dev/udp", O_RDWR);\fR -.fi - -.LP -.nf -\fBt = t_open("/dev/udp6", O_RDWR);\fR -.fi - -.SH DESCRIPTION -.sp -.LP -\fBUDP\fR is a simple datagram protocol which is layered directly above the -Internet Protocol ("\fBIP\fR") or the Internet Protocol Version 6 ("IPv6"). -Programs may access \fBUDP\fR using the socket interface, where it supports -the \fB\fR\fBSOCK_DGRAM\fR\fB\fR socket type, or using the Transport Level -Interface ("\fBTLI\fR"), where it supports the connectionless (\fBT_CLTS\fR) -service type. -.sp -.LP -Within the socket interface, \fBUDP\fR is normally used with the -\fBsendto()\fR, \fBsendmsg()\fR, \fBrecvfrom()\fR, and \fBrecvmsg()\fR calls -(see \fBsend\fR(3SOCKET) and \fBrecv\fR(3SOCKET)). If the -\fBconnect\fR(3SOCKET) call is used to fix the destination for future packets, -then the \fBrecv\fR(3SOCKET) or \fBread\fR(2) and \fBsend\fR(3SOCKET) or -\fBwrite\fR(2) calls may be used. -.sp -.LP -\fBUDP\fR address formats are identical to those used by the Transmission -Control Protocol ("\fBTCP\fR"). Like \fBTCP,\fR \fBUDP\fR uses a port number -along with an \fBIP\fRor IPv6 address to identify the endpoint of -communication. The \fBUDP\fR port number space is separate from the \fBTCP\fR -port number space, that is, a \fBUDP\fR port may not be "connected" to a -\fBTCP\fR port. The \fBbind\fR(3SOCKET) call can be used to set the local -address and port number of a \fBUDP\fR socket. The local \fBIP\fR or IPv6 -address may be left unspecified in the \fBbind()\fR call by using the special -value \fBINADDR_ANY\fR for \fBIP\fR, or the unspecified address (all zeroes) -for IPv6. If the \fBbind()\fR call is not done, a local \fBIP\fR or IPv6 -address and port number will be assigned to the endpoint when the first packet -is sent. Broadcast packets may be sent, assuming the underlying network -supports this, by using a reserved "broadcast address" This address is network -interface dependent. Broadcasts may only be sent by the privileged user. -.sp -.LP -Note that no two UDP sockets can be bound to the same port unless the bound IP -addresses are different. IPv4 \fBINADDR_ANY\fR and IPv6 unspecified addresses -compare as equal to any IPv4 or IPv6 address. For example, if a socket is bound -to \fBINADDR_ANY\fR or unspecified address and port X, no other socket can bind -to port X, regardless of the binding address. This special consideration of -\fBINADDR_ANY\fR and unspecified address can be changed using the -\fBSO_REUSEADDR\fR socket option. If \fBSO_REUSEADDR\fR is set on a socket -doing a bind, IPv4 \fBINADDR_ANY\fR and IPv6 unspecified address do not compare -as equal to any IP address. This means that as long as the two sockets are not -both bound to \fBINADDR_ANY\fR/unspecified address or the same IP address, the -two sockets can be bound to the same port. -.sp -.LP -If an application does not want to allow another socket using the -\fBSO_REUSEADDR\fR option to bind to a port its socket is bound to, the -application can set the socket level option \fBSO_EXCLBIND\fR on a socket. The -option values of 0 and 1 represent enabling and disabling the option, -respectively. Once this option is enabled on a socket, no other socket can be -bound to the same port. -.sp -.LP -IPv6 does not support broadcast addresses; their function is supported by IPv6 -multicast addresses. -.sp -.LP -Options at the \fBIP\fR level may be used with \fBUDP\fR. See \fBip\fR(7P) or -\fBip6\fR(7P). Additionally, there is one UDP-level option of interest to IPsec -Key Management applications (see \fBipsec\fR(7P)and \fBpf_key\fR(7P)): -.sp -.ne 2 -.na -\fBUDP_NAT_T_ENDPOINT\fR -.ad -.sp .6 -.RS 4n -If this boolean option is set, datagrams sent via this socket will have a -non-ESP marker inserted between the UDP header and the data. Likewise, inbound -packets that match the endpoint's local-port will be demultiplexed between ESP -or the endpoint itself if a non-ESP marker is present. This option is only -available on IPv4 sockets (AF_INET), and the application must have sufficient -privilege to use PF_KEY sockets to also enable this option. -.RE - -.sp -.LP -There are a variety of ways that a \fBUDP\fR packet can be lost or corrupted, -including a failure of the underlying communication mechanism. \fBUDP\fR -implements a checksum over the data portion of the packet. If the checksum of a -received packet is in error, the packet will be dropped with no indication -given to the user. A queue of received packets is provided for each \fBUDP\fR -socket. This queue has a limited capacity. Arriving datagrams which will not -fit within its \fIhigh-water\fR capacity are silently discarded. -.sp -.LP -\fBUDP\fR processes Internet Control Message Protocol ("\fBICMP\fR") and -Internet Control Message Protocol Version 6 ("\fBICMP6\fR") error messages -received in response to \fBUDP\fR packets it has sent. See \fBicmp\fR(7P) and -\fBicmp6\fR(7P). -.sp -.LP -\fBICMP\fR "source quench" messages are ignored. \fBICMP\fR "destination -unreachable," "time exceeded" and "parameter problem" messages disconnect the -socket from its peer so that subsequent attempts to send packets using that -socket will return an error. \fBUDP\fR will not guarantee that packets are -delivered in the order they were sent. As well, duplicate packets may be -generated in the communication process. -.sp -.LP -\fBICMP6\fR "destination unreachable" packets are ignored unless the enclosed -code indicates that the port is not in use on the target host, in which case, -the application is notified. \fBICMP6\fR "parameter problem" notifications are -similarly passed upstream. All other \fBICMP6\fR messages are ignored. -.SH SEE ALSO -.sp -.LP -\fBread\fR(2), \fBwrite\fR(2), \fBbind\fR(3SOCKET), \fBconnect\fR(3SOCKET), -\fBrecv\fR(3SOCKET), \fBsend\fR(3SOCKET), \fBicmp\fR(7P), \fBicmp6\fR(7P), -\fBinet\fR(7P), \fBinet6\fR(7P), \fBip\fR(7P), \fBipsec\fR(7P), \fBip6\fR(7P), -\fBpf_key\fR(7P), \fBtcp\fR(7P) -.sp -.LP -Postel, Jon, \fIRFC 768, User Datagram Protocol\fR, Network Information Center, -SRI International, Menlo Park, Calif., August 1980 -.sp -.LP -Huttunen, A., Swander, B., Volpe, V., DiBurro, L., Stenberg, \fIM., RFC 3948, -UDP Encapsulation of IPsec ESP Packets\fR, The Internet Society, 2005. -.SH DIAGNOSTICS -.sp -.LP -A socket operation may fail if: -.sp -.ne 2 -.na -\fB\fBEISCONN\fR\fR -.ad -.RS 17n -A \fBconnect()\fR operation was attempted on a socket on which a -\fBconnect()\fR operation had already been performed, and the socket could not -be successfully disconnected before making the new connection. -.RE - -.sp -.ne 2 -.na -\fB\fBEISCONN\fR\fR -.ad -.RS 17n -A \fBsendto()\fR or \fBsendmsg()\fR operation specifying an address to which -the message should be sent was attempted on a socket on which a \fBconnect()\fR -operation had already been performed. -.RE - -.sp -.ne 2 -.na -\fB\fBENOTCONN\fR\fR -.ad -.RS 17n -A \fBsend()\fR or \fBwrite()\fR operation, or a \fBsendto()\fR or -\fBsendmsg()\fR operation not specifying an address to which the message should -be sent, was attempted on a socket on which a \fBconnect()\fR operation had not -already been performed. -.RE - -.sp -.ne 2 -.na -\fB\fBEADDRINUSE\fR\fR -.ad -.RS 17n -A \fBbind()\fR operation was attempted on a socket with a network address/port -pair that has already been bound to another socket. -.RE - -.sp -.ne 2 -.na -\fB\fBEADDRNOTAVAIL\fR\fR -.ad -.RS 17n -A \fBbind()\fR operation was attempted on a socket with a network address for -which no network interface exists. -.RE - -.sp -.ne 2 -.na -\fB\fBEINVAL\fR\fR -.ad -.RS 17n -A \fBsendmsg()\fR operation with a non-NULL \fBmsg_accrights\fR was attempted. -.RE - -.sp -.ne 2 -.na -\fB\fBEACCES\fR\fR -.ad -.RS 17n -A \fBbind()\fR operation was attempted with a "reserved" port number and the -effective user \fBID\fR of the process was not the privileged user. -.RE - -.sp -.ne 2 -.na -\fB\fBENOBUFS\fR\fR -.ad -.RS 17n -The system ran out of memory for internal data structures. -.RE - diff --git a/usr/src/man/man7p/vxlan.7p b/usr/src/man/man7p/vxlan.7p deleted file mode 100644 index 59c1d3d9d8..0000000000 --- a/usr/src/man/man7p/vxlan.7p +++ /dev/null @@ -1,137 +0,0 @@ -.\" -.\" This file and its contents are supplied under the terms of the -.\" Common Development and Distribution License ("CDDL"), version 1.0. -.\" You may only use this file in accordance with the terms of version -.\" 1.0 of the CDDL. -.\" -.\" A full copy of the text of the CDDL should have accompanied this -.\" source. A copy of the CDDL is also available via the Internet at -.\" http://www.illumos.org/license/CDDL. -.\" -.\" -.\" Copyright 2018 Joyent, Inc. -.\" -.Dd December 20, 2018 -.Dt VXLAN 7P -.Os -.Sh NAME -.Nm VXLAN , -.Nm vxlan -.Nd Virtual eXtensible Local Area Network -.Sh SYNOPSIS -.In sys/vxlan.h -.Sh DESCRIPTION -.Nm -(RFC 7348) is a network encapsulation protocol that is used by -.Xr overlay 5 -devices. -A payload, commonly an Ethernet frame, is placed inside of a -UDP packet and prepended with an 8-byte -.Nm -header. -.Pp -The -.Nm -header contains two 32-bit words. -The first word is an 8-bit flags field followed by 24 reserved bits. -The second word is a 24-bit virtual network identifier followed by 8 -reserved bits. -The virtual network identifier identifies a unique -.Nm -and -is similar in concept to an IEEE 802.1Q VLAN identifier. -.Pp -The system provides access to -.Nm -through dladm overlays. -See -.Xr dladm 1M -and -.Xr overlay 5 -for more information. -.Pp -The -.In sys/vxlan.h -header provides information for working with the -.Nm -protocol. -The contents of this header are -.Sy uncommitted . -The header defines a structure that may be used to encode and decode a VXLAN -header. -It defines a packed structure type -.Sy vxlan_hdr_t -which represents the -.Nm -frame header and has the following members: -.Bd -literal - uint32_t vxlan_flags; /* flags in upper 8 bits */ - uint32_t vxlan_id; /* VXLAN ID in upper 24 bits */ -.Ed -.Sh EXAMPLES -.Sy Example 1 -Decoding a -.Nm -header -.Pp -The following example shows how to validate a -.Nm header. -For more information on this process, see RFC 7348. -.Bd -literal -offset indent -#include <sys/types.h> -#include <netinet/in.h> -#include <inttypes.h> -#include <sys/vxlan.h> - -\&... - -/* - * Validate the following bytes as a VXLAN header. If valid, return - * 0 and store the VXLAN identifier in *vidp. Otherwise, return an - * error. - */ -int -validate_vxlan(void *buf, int len, uint32_t *vidp) -{ - vxlan_hdr_t *hdr; - - if (len < sizeof (vxlan_hdr_t)) - return (EINVAL); - - hdr = buf; - - /* - * This verifies that the required flag is set; however, it does - * not look at any of the other bist that are reserved in the - * header. Software needs to evaluate how it should handle other - * bits being set in the vxlan_flags member. - */ - if ((ntohl(hdr->vxlan_flags) & VXLAN_F_VDI) == 0) - return (EINVAL); - - *vidp = ntohl(vxlan->vxlan_id) >> VXLAN_ID_SHIFT; - - return (0); -} -.Ed -.Sh STABILITY -The contents of -.In sys/vxlan.h -are -.Sy Uncommitted . -.Sh SEE ALSO -.Xr dladm 1M , -.Xr overlay 5 -.Rs -.%A Mahalingam, M. -.%A Dutt, D. -.%A Duda, K. -.%A Agarwal, P. -.%A Kreeger L. -.%A Sridhar, T. -.%A Bursell, M. -.%A C. Wright -.%T RFC 7348, Virtual eXtensible Local Area Network (VXLAN): A Framework -.%T for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks -.%D August 2014 -.Re |