ip man page on SunOS

Man page or keyword search:  
man Server   20652 pages
apropos Keyword Search (all sections)
Output format
SunOS logo
[printable version]

ip(7P)				   Protocols				ip(7P)

NAME
       ip, IP - Internet Protocol

SYNOPSIS
       #include <sys/socket.h>

       #include <netinet/in.h>

       s = socket(AF_INET, SOCK_RAW, proto);

       t = t_open ("/dev/rawip", O_RDWR);

DESCRIPTION
       IP  is  the  internetwork datagram delivery protocol that is central to
       the Internet protocol family. Programs may use IP through  higher-level
       protocols  such	as the Transmission Control Protocol (TCP) or the User
       Datagram Protocol (UDP), or may interface directly to IP.  See  tcp(7P)
       and  udp(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.

       Packets sent to or from this system may be subject to IPsec policy. See
       ipsec(7P) for more information.

APPLICATION PROGRAMMING INTERFACE
       The  STREAMS  driver /dev/rawip is the TLI transport provider that pro‐
       vides raw access to IP.

       Raw IP sockets are  connectionless  and	are  normally  used  with  the
       sendto()	 and  recvfrom()  calls (see send(3SOCKET) and recv(3SOCKET)),
       although the connect(3SOCKET) call may also be used to fix the destina‐
       tion  for  future  datagram. In this case, the read(2) or recv(3SOCKET)
       and  write(2)  or  send(3SOCKET)	 calls	may  be	 used.	If  proto   is
       IPPROTO_RAW  or	IPPROTO_IGMP, 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.

       If an application uses IP_HDRINCL 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 IP_OPTIONS,
       and Total Length 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),	 Frag‐
       ment  Offset is always 0. The IP Checksum field is computed by IP. None
       of the data beyond the IP header are changed,  including	 the  applica‐
       tion-provided transport header.

       The socket options supported at the IP level are:

       IP_ADD_MEMBERSHIP     Join a multicast group.

       IP_BOUND_IF	     Limit   reception	and transmission of packets to
			     this interface. Takes an integer as an  argument.
			     The integer is the selected intefrace index.

       IP_DROP_MEMBERSHIP    Leave a multicast group.

       IP_OPTIONS	     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 setsockopt()	(see  getsock‐
			     opt(3SOCKET)).   The   getsockopt(3SOCKET)	  call
			     returns the IP options set in the	last  setsock‐
			     opt()  call. IP options on received datagrams are
			     visible to user programs only using raw IP	 sock‐
			     ets.  The	format of IP options given in setsock‐
			     opt() matches those defined in the IP  specifica‐
			     tion  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 fam‐
			     ily.

       IP_RECVTTL	     Allow the user level  application,	 mipagent,  to
			     read  the	IP  TTL (time to live) for an incoming
			     packet.

       IP_SEC_OPT	     Enable or obtain IPsec security settings for this
			     socket.  For  more details on the protection ser‐
			     vices of IPsec, see ipsec(7P).

       The following options take in_pktinfo_t as the parameter:

       IP_PKTINFO

	   Set the source address and/or transmit interface of the packet(s).

	   IP_XMIT_IF and IP_DONTFAILOVER_IF options take precedence  over  IF
	   index passed in IP_PKTINFO.

	     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;

	   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.

       IP_RECVPKTINFO

	   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 struct in_pktinfo_t as ancillary data.

       The following options take a  struct  ip_mreq  as  the  parameter.  The
       structure contains a multicast address which must be set to the CLASS-D
       IP multicast address and an interface address. Normally	the  interface
       address	is  set	 to  INADDR_ANY	 which causes the kernel to choose the
       interface on which to join.

       IP_BLOCK_SOURCE		    Block  multicast  packets	whose	source
				    address  matches the given source address.
				    The specified group must be joined	previ‐
				    ously     using    IP_ADD_MEMBERSHIP    or
				    MCAST_JOIN_GROUP.

       IP_UNBLOCK_SOURCE	    Unblock (begin receiving) multicast	 pack‐
				    ets	 which	were  previously blocked using
				    IP_BLOCK_SOURCE.

       IP_ADD_SOURCE_MEMBERSHIP	    Begin receiving packets for the given mul‐
				    ticast  group whose source address matches
				    the specified address.

       IP_DROP_SOURCE_MEMBERSHIP    Stop receiving packets for the given  mul‐
				    ticast  group whose source address matches
				    the specified address.

       The following options take a struct ip_mreq_source  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.

       MCAST_JOIN_GROUP		   Join a multicast group. Functionally equiv‐
				   alent to IP_ADD_MEMBERSHIP.

       MCAST_BLOCK_SOURCE	   Block  multicast   packets	whose	source
				   address  matches  the given source address.
				   The specified group must be	joined	previ‐
				   ously     using     IP_ADD_MEMBERSHIP    or
				   MCAST_JOIN_GROUP.

       MCAST_UNBLOCK_SOURCE	   Unblock (begin receiving) multicast packets
				   which   were	  previously   blocked	 using
				   MCAST_BLOCK_SOURCE.

       MCAST_LEAVE_GROUP	   Leave  a  multicast	 group.	  Functionally
				   equivalent to IP_DROP_MEMBERSHIP.

       MCAST_JOIN_SOURCE_GROUP	   Begin  receiving packets for the given mul‐
				   ticast group whose source  address  matches
				   the specified address.

       MCAST_LEAVE_SOURCE_GROUP	   Stop receiving packets for the given multi‐
				   cast group whose source address matches the
				   specified address.

       The   following	 options   take	  a   struct   group_req   or	struct
       group_source_req as the parameter. The `group_req structure contains an
       interface index and a multicast address which must be set to the CLASS-
       D multicast address. The group_source_req structure is used  for	 those
       options which include a source address. It contains an interface index,
       multicast address, and source address.

       IP_MULTICAST_IF	    The outgoing interface for multicast packets. This
			    option  takes a struct in_addr as an argument, and
			    it selects that interface for outgoing  IP	multi‐
			    cast   packets.   If   the	address	 specified  is
			    INADDR_ANY, it uses the unicast routing  table  to
			    select   the  outgoing  interface  (which  is  the
			    default behavior).

       IP_MULTICAST_TTL	    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	multi‐
			    cast datagrams. The default is 1.

       IP_MULTICAST_LOOP    Loopback for multicast  datagrams. Normally multi‐
			    cast  datagrams are delivered to  members  on  the
			    sending   host  (or	 sending  zone).  Setting  the
			    unsigned character argument to 0 causes the	 oppo‐
			    site  behavior,  meaning  that when multiple zones
			    are present, the datagrams are  delivered  to  all
			    zones except the sending zone.

       IP_RECVIF	    Receive the inbound interface index.

       IP_TOS		    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.

       IP_NEXTHOP	    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_XMIT_IF and SO_DON‐
			    TROUTE  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 set‐
			    sockopt (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.

       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.

       At  the	socket	level,	the socket option SO_DONTROUTE may be applied.
       This option forces datagrams being sent to bypass routing and  forward‐
       ing  by forcing the IP Time To Live field to 1, meaning that the packet
       will not be forwarded by routers.

       Raw IP datagrams can also be sent and received using  the  TLI  connec‐
       tionless primitives.

       Datagrams flow through the IP layer in two directions: from the network
       up to user processes and from user processes down to the network. Using
       this orientation, IP is layered above the network interface drivers and
       below the transport protocols such as UDP and TCP. The Internet Control
       Message Protocol (ICMP) is logically a part of IP. See icmp(7P).

       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.

       IP  options in received datagrams are processed in the IP layer accord‐
       ing 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.

       By default, the IP layer will not forward IPv4  packets	that  are  not
       addressed to it. This behavior can be overridden by using  routeadm(1M)
       to enable the ipv4-forwarding option. IPv4 forwarding is configured  at
       boot  time  based  on  the  setting  of	routeadm(1M)'s ipv4-forwarding
       option.

       For backwards compatibility, IPv4 forwarding can be enabled or disabled
       using  ndd(1M)'s	 ip_forwarding	variable.  It is set to 1 if IPv4 for‐
       warding is enabled, or 0 if it is disabled.

       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
       ifconfig(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 oth‐
       ers, nor forwarded to this interface. Setting the  ip_forwarding	 vari‐
       able sets all of the IPv4 interfaces' IFF_ROUTER flags.

       For backwards compatibility, each interface creates an <ifname>:ip_for‐
       warding /dev/ip variable that can be modified using ndd(1M). An	inter‐
       face's  :ip_forwarding  ndd 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 <ifname> :ip_for‐
       warding ndd variable is obsolete and may be removed in a future release
       of  Solaris.  The  ifconfig(1M)	router and -router interfaces are pre‐
       ferred.

       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 "desti‐
       nation 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  des‐
       tined  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	 frag‐
       mented  datagram	 and are never returned in response to errors in other
       ICMP messages.

       The IP layer supports fragmentation and reassembly. Datagrams are frag‐
       mented  on  output if the datagram is larger than the maximum transmis‐
       sion unit (MTU) of the network interface. Fragments of  received	 data‐
       grams  are  dropped from the reassembly queues if the complete datagram
       is not reconstructed within a short time period.

       Errors in sending discovered at the network interface driver layer  are
       passed by IP back up to the user process.

       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 pro‐
       cessing costs. The behavior of Multi-Data Transmit can be overrideen by
       using ndd(1M) to set the /dev/ip variable, ip_multidata_outbound to  0.
       Note,  the IP module will only initiate Multi-Data Transmit if the net‐
       work interface driver supports it.

SEE ALSO
       ifconfig(1M), routeadm(1M), ndd(1M), read(2), write(2),	bind(3SOCKET),
       connect(3SOCKET),  getsockopt(3SOCKET),	recv(3SOCKET),	send(3SOCKET),
       defaultrouter(4),  privileges(5),   icmp(7P),   if_tcp(7P),   inet(7P),
       ip6(7P), ipsec(7P), routing(7P), tcp(7P), udp(7P)

       Braden,	R.,  RFC 1122, Requirements for Internet Hosts − Communication
       Layers, Information Sciences Institute, University of Southern Califor‐
       nia, October 1989.

       Postel,	J., RFC 791, Internet Protocol − DARPA Internet Program Proto‐
       col Specification, Information Sciences Institute, University of South‐
       ern California, September 1981.

DIAGNOSTICS
       A socket operation may fail with one of the following errors returned:

       EACCES		A  bind()  operation  was  attempted with a "reserved"
			port number and the effective user ID of  the  process
			was not the privileged user.

			Setting	 the  IP_NEXTHOP  was  attempted  by a process
			lacking the PRIV_SYS_NET_CONFIG privilege.

       EADDRINUSE	A bind() operation was attempted on a  socket  with  a
			network	 address/port pair that has already been bound
			to another socket.

       EADDRNOTAVAIL	A bind() operation was attempted for an	 address  that
			is not configured on this machine.

       EINVAL		A  sendmsg()  operation	 with a non-NULL msg_accrights
			was attempted.

       EINVAL		A  getsockopt()	 or  setsockopt()  operation  with  an
			unknown socket option name was given.

       EINVAL		A getsockopt() or setsockopt() operation was attempted
			with the IP option field improperly formed; an	option
			field  was  shorter  than  the minimum value or longer
			than the option buffer provided.

       EISCONN		A connect() operation was attempted  on	 a  socket  on
			which  a  connect()  operation	had  already been per‐
			formed, and the socket could not be successfully  dis‐
			connected before making the new connection.

       EISCONN		A   sendto()  or  sendmsg()  operation	specifying  an
			address to  which  the	message	 should	 be  sent  was
			attempted  on  a socket on which a connect() operation
			had already been performed.

       EMSGSIZE		A  send(),  sendto(),  or  sendmsg()   operation   was
			attempted to send a datagram that was too large for an
			interface, but was not allowed to be fragmented	 (such
			as broadcasts).

       ENETUNREACH	An attempt was made to establish a connection by means
			of connect(), or  to  send  a  datagram	 by  means  of
			sendto()  or  sendmsg(),  where	 there was no matching
			entry in the routing table; or if an ICMP "destination
			unreachable" message was received.

       ENOTCONN		A  send()  or  write()	operation,  or	a  sendto() or
			sendmsg() operation not specifying an address to which
			the  message should be sent, was attempted on a socket
			on which a connect() operation had  not	 already  been
			performed.

       ENOBUFS		The system ran out of memory for fragmentation buffers
			or other internal data structures.

       ENOBUFS		SO_SNDBUF or SO_RCVBUF exceeds a system limit.

       EINVAL		Invalid length for IP_OPTIONS.

       EHOSTUNREACH	Invalid address for IP_MULTICAST_IF.

			Invalid (offlink) nexthop address for IP_NEXTHOP.

       EINVAL		Not a  multicast  address  for	IP_ADD_MEMBERSHIP  and
			IP_DROP_MEMBERSHIP.

       EADDRNOTAVAIL	Bad   interface	  address  for	IP_ADD_MEMBERSHIP  and
			IP_DROP_MEMBERSHIP.

       EADDRINUSE	Address already joined for IP_ADD_MEMBERSHIP.

       ENOENT		Address not joined for IP_DROP_MEMBERSHIP.

       ENOPROTOOPT	Invalid socket type.

       EPERM		No permissions.

NOTES
       Raw sockets should receive ICMP error packets relating to the protocol;
       currently such packets are simply discarded.

       Users  of  higher-level protocols such as TCP and UDP should be able to
       see received IP options.

SunOS 5.10			  5 Jan 2011				ip(7P)
[top]

List of man pages available for SunOS

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net