Protocol: IP Fragment ( IP Fragment )

IP Fragment ( IP Fragment )

Update: 2005-12-09 11:48:31 I have words to say about this protocol

On this page

SUMMARY
DESCRIPTION
EXAMPLES
PROTOCOL RELATIONS
GLOSSARY
REFERENCES
OTHER PROTOCOLS

SUMMARY
Protocol	:	IP Fragment
Protocol suite	:	TCP/IP
Layer	:	Network Layer
Type	:	Connectionless network layer protocol
EtherType	:	0x0800
SNMP MIBs	:	iso.org.dod.internet.mgmt.mib-2.ip (1.3.6.1.2.1.4) iso.org.dod.internet.mgmt.mib-2.ipMIB (1.3.6.1.2.1.48) iso.org.dod.internet.mgmt.mib-2.ipMRouteStdMIB (1.3.6.1.2.1.83)
Related protocols	:	IPv6, TCP, UDP, ICMP, SNMP, FTP, TELNET, SMTP, ARP, RARP
Working groups	:	Diffserv, Differentiated Services. Iip1394, IP Over IEEE 1394

DESCRIPTION

The Internet Protocol allows IP fragment so that datagrams can be fragmented into pieces small enough to pass over a link with a smaller MTU than the original datagram size. When one IP host has a large amount of data to send to another host, the data is transmitted as a series of IP datagrams. It is usually preferable that these datagrams be of the largest size that does not require fragmentation anywhere along the path from the source to the destination. This datagram size is referred to as the Path MTU (PMTU), and it is equal to the minimum of the MTUs of each hop in the path. A shortcoming of the current Internet protocol suite is the lack of a standard mechanism for a host to discover the PMTU of an arbitrary path.

The IP layer at the receiving host must accumulate these fragments until enough have arrived to completely reconstitute the original datagram. The specification document for IP gives a complete description of the reassembly mechanism, and contains several examples. It also provides one possible algorithm for reassembly, based on keeping track of arriving fragments in a vector of bits. This document describes an alternate approach which should prove more suitable in some machines.

A superficial examination of the reassembly process may suggest that it is rather complicated. First, it is necessary to keep track of all the fragments, which suggests a small bookkeeping job. Second, when a new fragment arrives, it may combine with the existing fragments in a number of different ways. It may precisely fill the space between two fragments, or it may overlap with existing fragments, or completely duplicate existing fragments, or partially fill a space between two fragments without abutting either of them. Thus, it might seem that the reassembly process might involve designing a fairly complicated algorithm that tests for a number of different options.

Fragment Processing Algorithm
An arriving fragment can fill any of the existing holes in a number of ways. Most simply, it can completely fill a hole. Alternatively, it may leave some remaining space at either the beginning or the end of an existing hole. Or finally, it can lie in the middle of an existing hole, breaking the hole in half and leaving a smaller hole at each end. Because of these possibilities, it might seem that a number of tests must be made when a new fragment arrives, leading to a rather complicated algorithm. In fact, if properly expressed, the algorithm can compare each hole to the arriving fragment in only four tests.

Select the next hole descriptor from the hole descriptor list. If there are no more entries, go to step eight.

If fragment.first is greater than hole.last, go to step one.

If fragment.last is less than hole.first, go to step one.
If either step two or step three is true, then the newly arrived fragment does not overlap with the hole in any way, so we need pay no further attention to this hole. We return to the beginning of the algorithm where we select the next hole for examination.

Delete the current entry from the hole descriptor list.
Since neither step two nor step three was true, the newly arrived fragment does interact with this hole in some way. Therefore, the current descriptor will no longer be valid. We will destroy it, and in the next two steps we will determine whether or not it is necessary to create any new hole descriptors.

If fragment.first is greater than hole.first, then create a new hole descriptor "new_hole" with new_hole.first equal to hole.first, and new_hole.last equal to fragment.first minus one.

If the test in step five is true, then the first part of the original hole is not filled by this fragment. We create a new descriptor for this smaller hole.

If fragment.last is less than hole.last and fragment.more fragments is true, then create a new hole descriptor "new_hole", with new_hole.first equal to fragment.last plus one and new_hole.last equal to hole.last.

Go to step one.

If the hole descriptor list is now empty, the datagram is now complete. Pass it on to the higher level protocol processor for further handling. Otherwise, return.

Complete Algorithm
In addition to the algorithm described above there are two parts to the reassembly process. First, when a fragment arrives, it is necessary to find the reassembly buffer associated with that fragment. This requires some mechanism for searching all the existing reassembly buffers. The correct reassembly buffer is identified by an equality of the following fields: the foreign and local internet address, the protocol ID, and the identification field.

The final part of the algorithm is some sort of timer based mechanism which decrements the time to live field of each partially reassembled datagram, so that incomplete datagrams which have outlived their usefulness can be detected and deleted. One can either create a demon which comes alive once a second and decrements the field in each datagram by one, or one can read the clock when each first fragment arrives, and queue some sort of timer call, using whatever system mechanism is appropriate, to reap the datagram when its time has come.

An implementation of the complete algorithm comprising all these parts was constructed in BCPL as a test. The complete algorithm took less than one and one-half pages of listing, and generated approximately 400 nova machine instructions. That portion of the algorithm actually involved with management of hole descriptors is about 20 lines of code.

IP Fragment Filtering
IP fragmentation can be used to disguise TCP packets from IP filters used in routers and hosts.

System administrators rely on manufacturers of networking equipment to provide them with packet filters; these filters are used for keeping attackers from accessing private systems and information, while permitting friendly agents to transfer data between private nets and the Internet. For this reason, it is important for network equipment vendors to anticipate possible attacks against their equipment and to implement robust mechanisms to deflect such attacks.

Filtering IP Fragments
IP packet filters on routers are designed with a user interface that hides packet fragment from the administrator; conceptually, an IP filter is applied to each IP packet as a complete entity.

One approach to fragment filtering, described by Mogul, involves keeping track of the results of applying filter rules to the first fragment (FO = 0) and applying them to subsequent fragments of the same packet. The filtering module would maintain a list of packets indexed by the source address, destination address, protocol, and IP ID. When the initial (FO = 0) fragment is seen, if the MF bit is set, a list item would be allocated to hold the result of filter access checks. When packets with a non-zero FO come in, look up the list element with a matching SA/DA/PROT/ID and apply the stored result (pass or block). When a fragment with a zero MF bit is seen, free the list element.

Although this method (or some refinement of it) might successfully remove any trace of the offending whole packet, it has some difficulties. Fragments that arrive out of order, possibly because they traveled over different paths, violate one of the design assumptions, and undesired fragments can leak through as a result. Furthermore, if the filtering router lies on one of several parallel paths, the filtering module will not see every fragment and cannot guarantee complete fragment filtering in the case of packets that should be dropped.

Fortunately, we do not need to remove all fragments of an offending packet. Since "interesting" packet information is contained in the headers at the beginning, filters are generally applied only to the first fragment. Non-first fragments are passed without filtering, because it will be impossible for the destination host to complete reassembly of the packet if the first fragment is missing, and therefore the entire packet will be discarded.

The Internet Protocol allows fragment of packets into pieces so small as to be impractical because of data and computational overhead. Attackers can sometimes exploit typical filter behavior and the ability to create peculiar fragment sequences in order to sneak otherwise disallowed packets past the filter. In normal practice, such path a logical fragment is never used, so it is safe to drop these fragments without danger of preventing normal operation.

Tiny Fragment Attack
With many IP implementations it is possible to impose an unusually small fragment size on outgoing packets. If the fragment size is made small enough to force some of a TCP packet's TCP header fields into the second fragment, filter rules that specify patterns for those fields will not match. If the filtering implementation does not enforce a minimum fragment size, a disallowed packet might be passed because it didn't hit a match in the filter.

Note that, for the purpose of security, it is not sufficient to merely guarantee that a fragment contains at least 8 octets of data beyond the IP header because important transport header information (e.g., the CODE field of the TCP header) might be beyond the 8th data octet.

In a router, one can prevent this sort of attack by enforcing certain limits on fragments passing through, namely, that the first fragment be large enough to contain all the necessary header information.

There are two ways to guarantee that the first fragment of a "passed" packet includes all the required fields, one direct, the other indirect.

Overlapping Fragment Attack
The current IP protocol specification, describes a reassembly algorithm that results in new fragments overwriting any overlapped portions of previously-received fragments.

Given such a reassembly implementation, an attacker could construct a series of packets in which the lowest (zero-offset) fragment would contain innocuous data (and thereby be passed by administrative packet filters), and in which some subsequent packet having a non-zero offset would overlap TCP header information (destination port, for instance) and cause it to be modified. The second packet would be passed through most filter implementations because it does not have a zero fragment offset.

Thus, fully-compliant IP implementations are not guaranteed to be immune to overlapping-fragment attacks. The 4.3 BSD reassembly implementation takes care to avoid these attacks by forcing data from lower-offset fragments to take precedence over data from higher-offset fragments. However, not all IP implementations are based on the original BSD code, and it is likely that some of them are vulnerable.

Since no standard requires that an overlap-safe reassembly algorithm be used, the potential vulnerability of hosts to this attack is quite large.

By adopting a better strategy in a router's IP filtering code, one can be assured of blocking this attack. If the router's filtering module enforces a minimum fragment offset for fragments that have non-zero offsets, it can prevent overlaps in filter parameter regions of the transport headers.

In the case of TCP, this minimum is sixteen octets, to ensure that the TCP flags field is never contained in a non-zero-offset fragment. If a TCP fragment has FO = 1, it should be discarded because it starts only eight octets into the transport header. Conveniently, dropping FO = 1 fragments also protects against the tiny fragment attack, as discussed earlier.

An IP stack must be capable of passing an 8 byte IP data payload without further fragmentation (fragments sit on 8 byte boundaries). Since an IP header can be up to 60 bytes long (including options), this means that the minimum MTU on a link should be 68 bytes.

A typical IP header is only 20 bytes long and can therefore carry 48 bytes of data. No one in the real world should ever be generating a TCP packet with FO = 1, as it would require both that a previous system fragmenting IP data down to the 8 byte minimum and a 60 byte IP header.

A general algorithm, then, for ensuring that filters work in the face of both the tiny fragment attack and the overlapping fragment attack is:
If filtering based on fields in other transport protocol headers is provided in a router, the minimum could be greater, depending on the position of those fields in the header. In particular, if filtering is permitted on data beyond the sixteenth octet of the transport header, either because of a flexible user interface or the implementation of filters for some new transport protocol, dropping packets with FO = 1 might not be sufficient.

Top of Page

EXAMPLES

Example 1: Tiny Fragment Attack



n this example, the first fragment contains only eight octets of data (the minimum 

fragment size). In the case of TCP, this is sufficient to contain the source and 

destination port numbers, but it will force the TCP flags field into the second 

fragment.



Filters that attempt to drop connection requests (TCP datagrams having SYN=1 and 

ACK=0) will be unable to test these flags in the first octet, and will typically ignore 

them in subsequent fragments.



FRAGMENT 1

          IP HEADER

          +-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+

          |     | ... | Fragment Offset = 0 | ... |     |

          +-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+



          TCP HEADER

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          |        Source Port            |       Destination Port        |

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          |                       Sequence Number                         |

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



          FRAGMENT 2

          IP HEADER

          +-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+

          |     | ... | Fragment Offset = 1 | ... |     |

          +-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+



          TCP HEADER

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          |                    Acknowledgment Number                      |

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          |  Data |           |U|A|P|R|S|F|                               |

          | Offset| Reserved  |R|C|S|S|Y|I|            Window             |

          |       |           |G|K|H|T|N|N|                               |

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Example 2: Overlapping Fragment Attack



In this example, fragments are large enough to satisfy the minimum size requirements 

described in the previous section. The filter is configured to drop TCP connection 

request packets.



The first fragment contains values, e.g., SYN=0, ACK=1, that enable it to pass 

through the filter unharmed.



The second fragment, with a fragment offset of eight octets, contains TCP Flags that 

differ from those given in the first fragment, e.g., SYN=1, ACK=0. Since this second 

fragment is not a 0-offset fragment, it will not be checked, and it, too will pass 

through the filter.



The receiving host, if it conforms fully to the algorithms given in RFC 791, will 

reconstitute the packet as a connection request because the "bad" data arrived 

later.



FRAGMENT 1

          IP HEADER

          +-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+

          |     | ... | Fragment Offset = 0 | ... |     |

          +-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+



          TCP HEADER

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          |        Source Port            |       Destination Port        |

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          |                       Sequence Number                         |

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          |                    Acknowledgment Number                      |

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          |  Data |           |U|A|P|R|S|F|                               |

          | Offset| Reserved  |R|C|S|S|Y|I|            Window             |

          |       |           |G|K|H|T|N|N|                               |

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                       .

                                       .

                                       .

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          |                        (Other data)                           |

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



          FRAGMENT 2

          IP HEADER

          +-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+

          |     | ... | Fragment Offset = 1 | ... |     |

          +-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+



          TCP HEADER

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          |                    Acknowledgment Number                      |

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          |  Data |           |U|A|P|R|S|F|                               |

          | Offset| Reserved  |R|C|S|S|Y|I|            Window             |

          |       |           |G|K|H|T|N|N|                               |

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                       .

                                       .

                                       .

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          |                        (Other data)                           |

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





If the receiving host has a reassembly algorithm that prevents new data from 

overwriting data received previously, we can send Fragment 2 first, followed by 

Fragment 1, and accomplish the same successful attack.

Top of Page

PROTOCOL RELATIONS

■ Parent layer
■ Child layer

IP
IP Fragment

Top of Page

GLOSSARY

Access
(v.)
*To use. For example, programs can access memory , which means they read data from or write data to main memory. A user can access files, directories, computers, or peripheral devices.
*More specifically, access often means to read data from or write data to a mass storage device. The time it takes to locate a single byte of information on a mass-storage device is called the access time.
*To visit a Web site.

(n.)
*The act of reading data from or writing data to a storage device.
*A privilege to use computer information in some manner. For example, a user might be granted read access to a file, meaning that the user can read the file but cannot modify or delete it. Most operating systems have several different types of access privileges that can be granted or denied to specific users or groups of users.
*When capitalized as Access, short for Microsoft Access.

Agent
Agent is a program that performs some information gathering or processing task in the background. Typically, an agent is given a very small and well-defined task.

Algorithm
Algorithm is a formula or set of steps for solving a particular problem. To be an algorithm, a set of rules must be unambiguous and have a clear stopping point. Algorithms can be expressed in any language, from natural languages like English or French to programming languages like FORTRAN.

We use algorithms every day. For example, a recipe for baking a cake is an algorithm. Most programs, with the exception of some artificial intelligence applications, consist of algorithms. Inventing elegant algorithms -- algorithms that are simple and require the fewest steps possible -- is one of the principal challenges in programming.

BSD
BSD (Berkeley Software Distribution) is the Unix derivative distributed by the University of California, Berkeley starting in the 1970s. The name is also used collectively for the modern descendants of these distributions.

Bit
Bit (binary digit), the smallest unit of information on a machine, a leading statistician and adviser to five presidents. A single bit can hold only one of two values: 0 or 1. More meaningful information is obtained by combining consecutive bits into larger units. For example, a byte is composed of 8 consecutive bits.

Buffer
Buffer is a temporary storage area, usually in RAM. The purpose of most buffers is to act as a holding area, enabling the CPU to manipulate data before transferring it to a device. Because the processes of reading and writing data to a disk are relatively slow, many programs keep track of data changes in a buffer and then copy the buffer to a disk.

Byte
Byte (binary term) is a unit of storage capable of holding a single character. On almost all modern computers, a byte is equal to 8 bits. Large amounts of memory are indicated in terms of kilobytes (1,024 bytes), megabytes (1,048,576 bytes), and gigabytes (1,073,741,824 bytes).

Data
* Distinct pieces of information, usually formatted in a special way. All software is divided into two general categories: data and programs. Programs are collections of instructions for manipulating data. Data can exist in a variety of forms -- as numbers or text on pieces of paper, as bits and bytes stored in electronic memory, or as facts stored in a person's mind. Strictly speaking, data is the plural of datum, a single piece of information. In practice, however, people use data as both the singular and plural form of the word.

* The term data is often used to distinguish binary machine-readable information from textual human-readable information. For example, some applications make a distinction between data files (files that contain binary data) and text files (files that contain ASCII data).

* In database management systems, data files are the files that store the database information, whereas other files, such as index files and data dictionaries, store administrative information, known as metadata.

Datagram
A datagram is a self-contained, independent entity of data carrying sufficient information to be routed from the source to the destination computer without reliance on earlier exchanges between this source and destination computer and the transporting network.

The term has been generally replaced by the term packet. Datagrams or packets are the message units that the Internet Protocol deals with and that the Internet transports. A datagram or packet needs to be self-contained without reliance on earlier exchanges because there is no connection of fixed duration between the two communicating points as there is, for example, in most voice telephone conversations.

Filter
*A program that accepts a certain type of data as input, transforms it in some manner, and then outputs the transformed data.
*A pattern through which data is passed. Only data that matches the pattern is allowed to pass through the filter.
*In paint programs and image editors, a filter is an effect that can be applied to a bit map.

Host
Host is a computer system that is accessed by a user working at a remote location. Typically, the term is used when there are two computer systems connected by modems and telephone lines. The system that contains the data is called the host, while the computer at which the user sits is called the remote terminal.

Host can refer to a computer that is connected to a TCP/IP network, including the Internet. Each host has a unique IP address.

Host can refer to provide the infrastructure for a computer service too. For example, there are many companies that host Web servers. This means that they provide the hardware, software, and communications lines required by the server, but the content on the server may be controlled by someone else.

IP
The IP (Internet Protocol) is a protocol which uses datagrams to communicate over a packet-switched network. IP specifies the format of packets, also called datagrams, and the addressing scheme. Most networks combine IP with a higher-level protocol called Transmission Control Protocol (TCP), which establishes a virtual connection between a destination and a source.

IP by itself is something like the postal system. It allows you to address a package and drop it in the system, but there's no direct link between you and the recipient. TCP/IP, on the other hand, establishes a connection between two hosts so that they can send messages back and forth for a period of time.

The current version of IP is IPv4. A new version, called IPv6 or IPng, is under development.

IP Filter
IP Filter (commonly referred to as ipf) is a software package that can be used to provide network address translation (NAT) or firewall services. It can either be used as a loadable kernel module or incorporated into the UNIX kernel; use as a loadable kernel module where possible is highly recommended.

IP Fragment
The Internet Protocol allows datagrams can be fragmented into pieces small enough to transmitted as a single unit will arrive at its final destination

Interface
Interface is the connection between a router and one of its attached networks. An interface has state information associated with it, which is obtained from the underlying lower level protocols and the routing protocol itself. An interface to a network has associated with it a single IP address and mask (unless the network is an unnumbered point-to-point network). An interface is sometimes also referred to as a link.

Internet
A global network connecting millions of computers. More than 100 countries are linked into exchanges of data, news and opinions.

Unlike online services, which are centrally controlled, the Internet is decentralized by design. Each Internet computer, called a host, is independent. Its operators can choose which Internet services to use and which local services to make available to the global Internet community. Remarkably, this anarchy by design works exceedingly well.

There are a variety of ways to access the Internet. Most online services, such as America Online, offer access to some Internet services. It is also possible to gain access through a commercial Internet Service Provider (ISP).

MTU
MTU (Maximum transmission unit) is the size of the largest packet that can be transmitted over a particular medium. Packets exceeding the MTU value in size are fragmented or segmented, and then reassembled at the receiving end. If fragmentation is not supported or possible, a packet that exceeds the MTU value is dropped.

Packet
A packet is the unit of data that is routed between an origin and a destination on the Internet or any other packet-switched network. When any file (e-mail message, HTML file, Graphics Interchange Format file, Uniform Resource Locator request, and so forth) is sent from one place to another on the Internet, the Transmission Control Protocol (TCP) layer of TCP/IP divides the file into "chunks" of an efficient size for routing. Each of these packets is separately numbered and includes the Internet address of the destination. The individual packets for a given file may travel different routes through the Internet. When they have all arrived, they are reassembled into the original file (by the TCP layer at the receiving end).

Path
The route taken by the SCTP packets sent by one SCTP endpoint to a specific destination transport address of its peer SCTP endpoint. Sending to different destination transport addresses does not necessarily guarantee getting separate paths.

Process
(n) An executing program. The term is used loosely as a synonym of task.
(v) To perform some useful operations on data.

Protocol stack
Protocol stack is a set of network protocol layers that work together. The OSI Reference Model that defines seven protocol layers is often called a stack, as is the set of TCP/IP protocols that define communication over the internet.

Router
A device that forwards data packets along networks. A router is connected to at least two networks, commonly two LANs or WANs or a LAN and its ISP network. Routers are located at gateways, the places where two or more networks connect.

Routers use headers and forwarding tables to determine the best path for forwarding the packets, and they use protocols such as ICMP to communicate with each other and configure the best route between any two hosts.

TCP
TCP (Transmission Control Protocol) is one of the main protocols in TCP/IP networks. TCP is one of the main protocols in TCP/IP networks. Whereas the IP protocol deals only with packets, TCP enables two hosts to establish a connection and exchange streams of data. TCP guarantees delivery of data and also guarantees that packets will be delivered in the same order in which they were sent.

TCP/IP
TCP/IP(transmission Control Protocol/Internet Protocol) is the suite of communications protocols used to connect hosts on the Internet. TCP/IP uses several protocols, the two main ones being TCP and IP. TCP/IP is built into the UNIX operating system and is used by the Internet, making it the de facto standard for transmitting data over networks. Even network operating systems that have their own protocols, such as Netware, also support TCP/IP.

Top of Page

REFERENCES

RFCs:
[IEN 92] Protocol Options.
[IEN 95] Source Routing.
[IEN 114] PROTOCOL OPTIONS.
[IEN 123] DOD STANDARD INTERNET PROTOCOL.
                Obsoletes: IEN 26, IEN 28, IEN 41, IEN 44, IEN 54, IEN 80, IEN 111.
[IEN 186] PROPOSED DCEC IP SPECIFICATION.
[IEN 212] IP - Local Area Network Addressing Issues.
[RFC 781] A SPECIFICATION OF THE INTERNET PROTOCOL (IP) TIMESTAMP OPTION.
[RFC 791] Internet Protocol.
                Obsoletes: RFC 760.
[RFC 795] SERVICE MAPPINGS.
[RFC 796] ADDRESS MAPPINGS.
                Obsoletes: IEN 115.
[RFC 815] IP DATAGRAM REASSEMBLY ALGORITHMS.
[RFC 894] A Standard for the Transmission of IP Datagrams over Ethernet Networks.
[RFC 895] A Standard for the Transmission of IP Datagrams over Experimental Ethernet Networks.
[RFC 917] INTERNET SUBNETS.
[RFC 919] BROADCASTING INTERNET DATAGRAMS.
[RFC 922] BROADCASTING INTERNET DATAGRAMS IN THE PRESENCE OF SUBNETS.
[RFC 932] A SUBNETWORK ADDRESSING SCHEME.
[RFC 936] Another Internet Subnet Addressing Scheme.
[RFC 940] Toward an Internet Standard Scheme for Subnetting.
[RFC 950] IP Subnet Extension.
[RFC 963] SOME PROBLEMS WITH THE SPECIFICATION OF THE MILITARY STANDARD INTERNET PROTOCOL.
[RFC 1042] A Standard for the Transmission of IP Datagrams over IEEE 802 Networks.
                Obsoletes: RFC 948.
[RFC 1044] Internet Protocol on Network Systems HYPERchannel Protocol Specification.
[RFC 1046] A Queuing Algorithm to Provide Type-of-Service for IP Links.
[RFC 1055] A NONSTANDARD FOR TRANSMISSION OF IP DATAGRAMS OVER SERIAL LINES: SLIP.
[RFC 1070] Use of the Internet as a Subnetwork for Experimentation with the OSI Network Layer.
[RFC 1088] A Standard for the Transmission of IP Datagrams over NetBIOS Networks.
[RFC 1108] U.S. Department of Defense Security Options for the Internet Protocol.
                Defines IP options 2 and 5.
                Obsoletes: RFC 1038.
[RFC 1112] Host Extensions for IP Multicasting.
                Obsoletes: RFC 988, RFC 1054.
[RFC 1122] Requirements for Internet Hosts -- Communication Layers.
[RFC 1132] A Standard for the Transmission of 802.2 Packets over IPX Networks.
[RFC 1141] Incremental Updating of the Internet Checksum.
                Obsoletes: RFC 1071.
[RFC 1156] Management Information Base for Network Management of TCP/IP-based internets.
                Obsoletes: RFC 1066.
[RFC 1180] A TCP/IP Tutorial.
[RFC 1188] A Proposed Standard for the Transmission of IP Datagrams over FDDI Networks.
                Obsoletes: RFC 1103.
[RFC 1191] Path MTU Discovery.
                Obsoletes: RFC 1063.
[RFC 1201] Transmitting IP Traffic over ARCNET Networks.
                Obsoletes: RFC 1051.
[RFC 1209] The Transmission of IP Datagrams over the SMDS Service.
[RFC 1213] Management Information Base for Network Management of TCP/IP-based internets: MIB-II.
                Obsoletes: RFC 1158.
[RFC 1219] On the Assignment of Subnet Numbers.
[RFC 1226] Internet Protocol Encapsulation of AX.25 Frames.
[RFC 1234] Tunneling IPX Traffic through IP Networks.
[RFC 1236] IP to X.121 Address Mapping for DDN.
[RFC 1242] Benchmarking Terminology for Network Interconnection Devices.
[RFC 1356] Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode.
                Obsoletes: RFC 877.
[RFC 1365] An IP Address Extension Proposal.
[RFC 1375] Suggestion for New Classes of IP Addresses.
[RFC 1390] Transmission of IP and ARP over FDDI Networks.
[RFC 1393] Traceroute Using an IP Option.
[RFC 1454] Comparison of Proposals for Next Version of IP.
[RFC 1466] Guidelines for Management of IP Address Space.
                Obsoletes: RFC 1366.
[RFC 1469] IP Multicast over Token-Ring Local Area Networks.
[RFC 1475] TP/IX: The Next Internet.
[RFC 1577] Classical IP and ARP over ATM.
[RFC 1608] Representing IP Information in the X.500 Directory.
[RFC 1620] Internet Architecture Extensions for Shared Media.
[RFC 1624] Computation of the Internet Checksum via Incremental Update.
                Updates: RFC 1141.
[RFC 1626] Default IP MTU for use over ATM AAL5.
[RFC 1716] Towards Requirements for IP Routers.
[RFC 1744] Observations on the Management of the Internet Address Space.
[RFC 1755] ATM Signaling Support for IP over ATM.
[RFC 1770] IPv4 Option for Sender Directed Multi-Destination Delivery.
[RFC 1797] Class A Subnet Experiment.
[RFC 1812] Requirements for IP Version 4 Routers.
                Obsoletes: RFC 1009, RFC 1716.
[RFC 1814] Unique Addresses are Good.
[RFC 1821] Integration of Real-time Services in an IP-ATM Network Architecture.
[RFC 1826] IP Authentication Header.
[RFC 1827] IP Encapsulating Security Payload (ESP).
[RFC 1858] Security Considerations for IP Fragment Filtering.
[RFC 1878] Variable Length Subnet Table For IPv4.
                Obsoletes: RFC 1860.
[RFC 1917] An Appeal to the Internet Community to Return Unused IP Networks (Prefixes) to the IANA.
[RFC 1918] Address Allocation for Private Internets.
                Obsoletes: RFC 1597.
[RFC 1932] IP over ATM: A Framework Document.
[RFC 1944] Benchmarking Methodology for Network Interconnect Devices.
[RFC 1953] Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0.
[RFC 1954] Transmission of Flow Labelled IPv4 on ATM Data Links Ipsilon Version 1.0.
[RFC 2002] IP Mobility Support.
[RFC 2003] IP Encapsulation within IP.
[RFC 2004] Minimal Encapsulation within IP.
[RFC 2005] Applicability Statement for IP Mobility Support.
[RFC 2006] The Definitions of Managed Objects for IP Mobility Support using SMIv2.
[RFC 2011] SNMPv2 Management Information Base for the Internet Protocol using SMIv2.
                Updates SNMP MIB iso.org.dod.internet.mgmt.mib-2.icmp (1.3.6.1.2.1.5).
                Defines SNMP MIB iso.org.dod.internet.mgmt.mib-2.ipMIB (1.3.6.1.2.1.48).
[RFC 2022] Support for Multicast over UNI 3.0/3.1 based ATM Networks.
[RFC 2067] IP over HIPPI.
                Obsoletes: RFC 1374.
[RFC 2085] HMAC-MD5 IP Authentication with Replay Prevention.
[RFC 2096] IP Forwarding Table MIB.
                Obsoletes: RFC 1354.
[RFC 2101] IPv4 Address Behaviour Today.
[RFC 2113] IP Router Alert Option.
                Defines IP option 20 (Router Alert).
[RFC 2143] Encapsulating IP with the Small Computer System Interface.
[RFC 2176] IPv4 over MAPOS Version 1.
                Describes how IP is encapsulated in MAPOS.
[RFC 2225] Classical IP and ARP over ATM.
                Obsoletes: RFC 1577, RFC 1626.
[RFC 2226] IP Broadcast over ATM Networks.
[RFC 2285] Benchmarking Terminology for LAN Switching Devices.
[RFC 2336] Classical IP and ARP over ATM to NHRP Transition.
[RFC 2344] Reverse Tunneling for Mobile IP.
[RFC 2365] Administratively Scoped IP Multicast.
[RFC 2401] Security Architecture for the Internet Protocol.
                Obsoletes: RFC 1825.
[RFC 2432] Terminology for IP Multicast Benchmarking.
[RFC 2474] Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers.
                Obsoletes: RFC 1349, RFC 1455.
[RFC 2475] An Architecture for Differentiated Services.
[RFC 2507] IP Header Compression.
[RFC 2508] Compressing IP/UDP/RTP Headers for Low-Speed Serial Links.
[RFC 2625] IP and ARP over Fibre Channel.
[RFC 2697] A Single Rate Three Color Marker.
[RFC 2698] A Two Rate Three Color Marker.
[RFC 2728] The Transmission of IP Over the Vertical Blanking Interval of a Television Signal.
[RFC 2734] IPv4 over IEEE 1394.
[RFC 2757] Long Thin Networks.
[RFC 2765] Stateless IP/ICMP Translation Algorithm (SIIT).
[RFC 2766] Network Address Translation - Protocol Translation (NAT-PT).
[RFC 2767] Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS).
[RFC 2780] IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers.
[RFC 2834] ARP and IP Broadcast over HIPPI-800.
                Obsoletes: RFC 1374.
[RFC 2835] IP and ARP over HIPPI-6400 (GSN).
[RFC 2893] Transition Mechanisms for IPv6 Hosts and Routers.
                Obsoletes: RFC 1933.
[RFC 2932] IPv4 Multicast Routing MIB.
                Defines SNMP MIB iso.org.dod.internet.mgmt.mib-2.ipMRouteStdMIB (1.3.6.1.2.1.83).
[RFC 3021] Using 31-Bit Prefixes on IPv4 Point-to-Point Links.
[RFC 3095] RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed.
[RFC 3128] Protection Against a Variant of the Tiny Fragment Attack.
                Updates: RFC 1858.
[RFC 3142] An IPv6-to-IPv4 Transport Relay Translator.
[RFC 3168] The Addition of Explicit Congestion Notification (ECN) to IP.
                Obsoletes: RFC 2481.
                Updates: RFC 793, RFC 2401, RFC 2474.
[RFC 3330] Special-Use IPv4 Addresses.
[RFC 3393] IP Packet Delay Variation Metric for IP Performance Metrics (IPPM).
[RFC 3544] IP Header Compression over PPP.
                Obsoletes: RFC 2509.
[RFC 3545] Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering.
[RFC 3754] IP Multicast in Differentiated Services (DS) Networks.
[RFC 3789] Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents.
[RFC 3790] Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards Track and Experimental Documents.
[RFC 3791] Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Track and Experimental Documents.
[RFC 3792] Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Track and Experimental Documents.
[RFC 3793] Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Track and Experimental Documents.
[RFC 3794] Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents.
[RFC 3795] Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents.
[RFC 3796] Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Track and Experimental Documents.
[RFC 3843] RObust Header Compression (ROHC): A Compression Profile for IP.

Obsolete RFCs:
[IEN 111] INTERNET PROTOCOL.
                Obsoleted by: IEN 123.
[IEN 115] ADDRESS MAPPINGS.
                Obsoleted by: RFC 796.
[RFC 760] DOD STANDARD INTERNET PROTOCOL.
                Obsoleted by: RFC 791.
                Obsoletes: IEN 26, IEN 28, IEN 41, IEN 44, IEN 54, IEN 80, IEN 111, IEN 123.
[RFC 877] A Standard for the Transmission of IP Datagrams Over Public Data Networks.
                Obsoleted by: RFC 1356.
[RFC 948] TWO METHODS FOR THE TRANSMISSION OF IP DATAGRAMS OVER IEEE 802.3 NETWORKS.
                Obsoleted by: RFC 1042.
[RFC 988] Host Extensions for IP Multicasting.
                Obsoleted by: RFC 1054, RFC 1112.
                Defines IGMP version 0.
                Obsoletes: RFC 966.
[RFC 1038] Draft Revised IP Security Option.
                Obsoleted by: RFC 1108.
[RFC 1051] A Standard for the Transmission of IP Datagrams and ARP Packets over ARCNET Networks.
                Obsoleted by: RFC 1201.
[RFC 1054] Host Extensions for IP Multicasting.
                Obsoleted by: RFC 1112.
[RFC 1063] IP MTU Discovery Options.
                Obsoleted by: RFC 1191.
[RFC 1066] Management Information Base for Network Management of TCP/IP-based internets.
                Obsoleted by: RFC 1156.
[RFC 1071] Computing the Internet Checksum.
                Obsoleted by: RFC 1141.
[RFC 1103] A Proposed Standard for the Transmission of IP Datagrams over FDDI Networks.
                Obsoleted by: RFC 1188.
[RFC 1349] Type of Service in the Internet Protocol Suite.
                Obsoleted by: RFC 2474.
                Updates: RFC 791, RFC 1060, RFC 1122, RFC 1123, RFC 1195, RFC 1247, RFC 1248.
[RFC 1354] IP Forwarding Table MIB.
                Obsoleted by: RFC 2096.
[RFC 1366] Guidelines for Management of IP Address Space.
                Obsoleted by: RFC 1466.
[RFC 1374] IP and ARP on HIPPI.
                Obsoleted by: RFC 2834.
[RFC 1455] Physical Link Security Type of Service.
                Obsoleted by: RFC 2474.
[RFC 1597] Address Allocation for Private Internets.
                Obsoleted by: RFC 1918.
[RFC 1860] Variable Length Subnet Table For IPv4.
                Obsoleted by: RFC 1878.
[RFC 1933] Transition Mechanisms for IPv6 Hosts and Routers.
                Obsoleted by: RFC 2893.
[RFC 2481] A Proposal to add Explicit Congestion Notification (ECN) to IP.
                Obsoleted by: RFC 3168.
[RFC 2509] IP Header Compression over PPP.
                Obsoleted by: RFC 3544.

Top of Page

OTHER PROTOCOLS OF TCP/IP SUITE