Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
ip(7P)				   Protocols				ip(7P)

       ip, IP -	Internet Protocol

       #include	<sys/socket.h>

       #include	<netinet/in.h>

       s = socket(AF_INET, SOCK_RAW, proto);

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

       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, us-
       ing a "raw socket," or by means of the Transport	Level Interface	(TLI).
       The protocol options defined in the IP specification may	be set in out-
       going datagrams.

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

       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  IP-
       PROTO_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  Ad-
       dress.  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	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 getsockopt(3SOCKET)).	The  getsockopt(3SOCKET)  call
		    returns the	 IP options set	in the last setsockopt() call.
		    IP options on received datagrams are visible to user  pro-
		    grams  only	using raw IP sockets. The format of IP options
		    given in setsockopt() 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  op-
		    tion list and the size adjusted accordingly	before use. IP
		    options may	be used	with any socket	type in	 the  Internet

		    Enable  or obtain IPsec security settings for this socket.
		    For	more details on	the protection services	of IPsec,  see

		    Join a multicast group.

		    Leave a multicast group.

       These  options  take  a struct ip_mreq as the parameter.	 The structure
       contains	a multicast address which has to be set	to the CLASS-D IP mul-
       ticast  address,	 and  an interface address. Normally the interface ad-
       dress is	set to INADDR_ANY which	causes the kernel to choose   the  in-
       terface to join on.

		    The	outgoing interface for multicast packets.  This	option
		    takes a struct in_addr as an argument, and it selects that
		    interface  for  outgoing IP	multicast packets.  If the ad-
		    dress specified is INADDR_ANY, it  will  use  the  unicast
		    routing  table to select  the outgoing interface (which is
		    the	default	behavior).

		    Time to live for multicast datagrams. This option takes an
		    unsigned  character	 as  an	argument. Its value is the TTL
		    that IP will use on	outgoing multicast datagrams. The  de-
		    fault is 1.

		    Loopback for multicast datagrams. Normally multicast data-
		    grams are delivered	 to members on the sending host.  Set-
		    ting  the unsigned character argument to 0 will cause  the
		    opposite behavior.

		    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

       The multicast socket options 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 in-
       clude: security,	loose source and record	route  (LSRR),	strict	source
       and record route	(SSRR),	record route, and internet timestamp.

       The  IP layer will normally act as a router when	the machine has	two or
       more interfaces that are	up, forwarding	datagrams  that	 are  not  ad-
       dressed	to  it,	among other things. This behavior can be overridden by
       using ndd(1M) to	set the	/dev/ip	variable,  ip_forwarding. The value  0
       means  do  not  forward;	the value 1 means forward.  The	initialization
       scripts set this	value at boot time based on the	number of "up"	inter-
       faces,  but  will  not  turn  on	 IP  forwarding	 at  all  if  the file
       /etc/notrouter exists. See /etc/init.d/inetinit.	 When the IP module is
       loaded, ip_forwarding is	0 and remains so if:

	      one non-DHCP-managed interface is	up (the	most common case)

	      file  /etc/notrouter  exists  and	DHCP does not say that IP for-
	     warding is	on

	      file /etc/defaultrouter exists and DHCP does not say IP forward-
	     ing is on

       Otherwise, ip_forwarding	is set to 1.

       Additionally,  finer-grained  forwarding	can be configured in IP.  Each
       interface creates an <ifname>:ip_forwarding /dev/ip variable  that  can
       be  modified using ndd(1M).  If a per-interface :ip_forwarding variable
       is set to 0, packets will neither be forwarded from this	 interface  to
       others,	nor  forwarded	to  this interface.  Setting the ip_forwarding
       variable	toggles	all of the per-interface :ip_forwarding	 variables  to
       the setting of ip_forwarding.

       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  ex-
       ceeded"	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.

       ndd(1M),	read(2), write(2), bind(3SOCKET),  connect(3SOCKET),  getsock-
       opt(3SOCKET), recv(3SOCKET), send(3SOCKET), defaultrouter(4), 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 Cali-
       fornia, October 1989.

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

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

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

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

	     A	bind() operation was attempted for an address that is not con-
	     figured on	this machine.

	     A sendmsg() operation  with  a  non-NULL  msg_accrights  was  at-

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

	     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.

	     A connect() operation was attempted on a socket on	which  a  con-
	     nect() operation had already been performed, and the socket could
	     not be successfully disconnected before making  the  new  connec-

	     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.

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

	     An	 attempt  was  made to establish a connection by means of con-
	     nect(), 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.

	     A send() or write() operation, or a sendto() or sendmsg()	opera-
	     tion  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.

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

	     SO_SNDBUF or SO_RCVBUF exceeds a system limit.

	     Invalid length for	IP_OPTIONS.

	     Invalid address for IP_MULTICAST_IF.

	     Not a multicast address for IP_ADD_MEMBERSHIP and IP_DROP_MEMBER-

	     Bad  interface  address for IP_ADD_MEMBERSHIP and IP_DROP_MEMBER-

	     Address already joined for	IP_ADD_MEMBERSHIP.

	     Address not joined	for IP_DROP_MEMBERSHIP.

       EPERM No	permissions.

       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.9			  7 Feb	2002				ip(7P)


Want to link to this manual page? Use this URL:

home | help