Jump to content

Internet Protocol: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
m links
Grammar
Line 2: Line 2:
The '''Internet Protocol''' ('''IP''') is a data-oriented protocol used by source and destination [[host]]s for communicating data across a [[packet-switched]] [[internetwork]]. The grouping of data sent in each [[packet]] is referred to as a [[datagram]] in an IP network. Each datagram contains enough information to allow each to be sent independent of previous or future datagrams. Packet switches, or network layer [[router]]s, are used to forward IP datagrams across interconnected [[layer 2]] networks. Minimal functionality is required, and typically provided, within IP datagrams or within packet switches in order to simplify the overall architecture.
The '''Internet Protocol''' ('''IP''') is a data-oriented protocol used by source and destination [[host]]s for communicating data across a [[packet-switched]] [[internetwork]]. The grouping of data sent in each [[packet]] is referred to as a [[datagram]] in an IP network. Each datagram contains enough information to allow each to be sent independent of previous or future datagrams. Packet switches, or network layer [[router]]s, are used to forward IP datagrams across interconnected [[layer 2]] networks. Minimal functionality is required, and typically provided, within IP datagrams or within packet switches in order to simplify the overall architecture.


IP is the common element found in today's public [[Internet]]. It is described in [[IETF]] [[RFC]] 791, which was first published in September, 1981. This document describes the current and most popular network layer protocol in use today. This version of the protocol is assigned as version 4. [[IPv6]] is also becoming popular and is deemed the successor to IPv4. IPv6's primary advantage is increased source and destination address bit length. Versions 0 through 3 were either reserved or unused. Version 5 was used for an experimental multicast protocol. Other version numbers have been assigned, usually for experimental protocols, but have not been widely used.
IP is the common element found in today's public [[Internet]]. It is described in [[IETF]] [[RFC]] 791, which was first published in September, 1981. This document describes the current and most popular network layer protocol in use today. This version of the protocol is assigned as version 4. [[IPv6]] is also becoming popular and is the successor to IPv4. The Internet is running out of addresses. IPv6 has 128-bit source and destination addresses, providing more addresses than IPv4's 32 bits. Versions 0 through 3 were either reserved or unused. Version 5 was used for an experimental multicast protocol. Other version numbers have been assigned, usually for experimental protocols, but have not been widely used.


The first header field in an IPv4 datagram is the 4-bit version field. The second field in an IPv4 datagram is a 4-bit Internet Header Length (IHL) field that defines how long the entire IPv4 header is. Since an IPv4 header may contain a variable number of options, this field essentially specifies the offset to the data portion of an IPv4 datagram. The IHL is specified in 32-bit words. A minimum IPv4 header is 20 bytes long so the value in decimal in the IHL field would be 5.
The first header field in an IPv4 datagram is the 4-bit version field. The second field is a 4-bit Internet Header Length (IHL) telling the number of 32-bit words the IPv4 header. Since an IPv4 header may contain a variable number of options, this field essentially specifies the offset to the data portion of an IPv4 datagram. A minimum IPv4 header is 20 bytes long so the value in decimal in the IHL field would be 5.


In RFC 791, the following 8 bits were allocated to a Type of Service (ToS) field. The original intention was for a sending host to specify a preference for how the datagram would be handled as it made its way through an internetwork. For instance, one IPv4 datagram could set a ToS field value to a preference for low delay, while another would signal a preference for high reliability. In practice, the use of this field has not been widely implemented. However, a great deal of experimental, research and deployment work has focused on how to make use of these eight bits. These bits have been redefined and most recently through DiffServ working group in the IETF and the Explicit Congestion Notification codepoints (see RFC 3168).
In RFC 791, the following 8 bits were allocated to a Type of Service (ToS) field. The original intention was for a sending host to specify a preference for how the datagram would be handled as it made its way through an internetwork. For instance, one host could set its IPv4 datagrams' ToS field value to prefer for low delay, while another might prefer high reliability. In practice, the ToS field has not been widely implemented. However, a great deal of experimental, research and deployment work has focused on how to make use of these eight bits. These bits have been redefined and most recently through DiffServ working group in the IETF and the Explicit Congestion Notification codepoints (see RFC 3168).


The IPv4 field is a 16-bit total length field. This field defines the entire datagram size including header and data in 8-bit bytes. The minimum length datagram is 576 bytes and the maximum is 65535. Note however, in some cases, [[subnetwork]]s impose further restrictions on the size. In this case, datagrams require fragmentation, which can be handled in either the host or packet switch in IPv4 or in the host only in IPv6.
The 16-bit IPv4 field defines the entire datagram size, including header and data, in 8-bit bytes. The minimum-length datagram is 576 bytes and the maximum is 65535. In some cases, [[subnetwork]]s impose further restrictions on the size. In this case, datagrams must br fragmented. Fragmentation is handled in either the host or packet switch in IPv4 or in the host only in IPv6.


The next 16-bit field is an identification field. This field is primarily used for uniquely identifying fragments of an original IP datagram. Some experimental work has suggested using the ID field for other purposes, such as for adding packet tracing information to datagrams in order to help traceback source address spoofed datagrams.
The next 16-bit field is an identification field. This field is primarily used for uniquely identifying fragments of an original IP datagram. Some experimental work has suggested using the ID field for other purposes, such as for adding packet tracing information to datagrams in order to help traceback source address spoofed datagrams.
Line 16: Line 16:
The fragment offset field is 13-bits long and helps a receiver determine the place of a particular fragment in the original IP datagram.
The fragment offset field is 13-bits long and helps a receiver determine the place of a particular fragment in the original IP datagram.


An 8-bit [[time to live]] (TTL) field is used to help prevent datagrams from persisting on an internetwork forever. Historically the TTL field limited a datagram's lifetime in seconds, but traditionally it has come to be used as a [[hop count]] field, where for each packet switch (or router) that a datagram crosses, the TTL field value is decremented by one. When a TTL field hits zero, it will no longer be forwarded by a packet switch and will die on the final subnetwork.
An 8-bit [[time to live]] (TTL) field helps prevent datagrams from persisting (e.g. going in circles) on an internetwork. Historically the TTL field limited a datagram's lifetime in seconds, but has come to be a [[hop count]] field. Each packet switch (or router) that a datagram crosses decrements the TTL field by one. When the TTL field hits zero, the packet is no longer forwarded by a packet switch and dies.


An 8-bit Protocol field follows. This field defines the next protocol used in the data portion of the IP datagram. The [[Internet Assigned Numbers Authority]] maintains a list of Protocol numbers. Common protocols and their decimal values include [[ICMP]] (1), [[TCP]] (6) and [[UDP]] (17).
An 8-bit Protocol field follows. This field defines the next protocol used in the data portion of the IP datagram. The [[Internet Assigned Numbers Authority]] maintains a list of Protocol numbers. Common protocols and their decimal values include [[ICMP]] (1), [[TCP]] (6) and [[UDP]] (17).
Line 22: Line 22:
The following field is a 16-bit checksum field for the IPv4 datagram header. Some values in a IPv4 datagram header may change at each packet switch hop, so the checksum must be recomputed on its way through an internetwork.
The following field is a 16-bit checksum field for the IPv4 datagram header. Some values in a IPv4 datagram header may change at each packet switch hop, so the checksum must be recomputed on its way through an internetwork.


The checksum is followed by a 32-bit source address and 32-bit destination address respectively. Note, in IPv6 source and destination addresses are 128 bits each.
The checksum is followed by a 32-bit source address and 32-bit destination address respectively. Note, IPv6 source and destination addresses are 128 bits each.


Optional header fields may follow the destination address field, but not commonly used in most IP networks. Option fields may be followed by a pad field that ensure the datagram header is aligned on a 32-bit word boundary. Note, in IPv6, options move out of the standard header and are specified by a Next Protocol field, similar in function to IPv4's Protocol field.
Optional header fields may follow the destination address field, but these are not used in most IP networks. Option fields may be followed by a pad field that ensure the datagram header is aligned on a 32-bit word boundary. In IPv6, options move out of the standard header and are specified by a Next Protocol field, similar in function to IPv4's Protocol field.


Perhaps the most complex aspects of IP are addressing and [[routing]]. Addressing refers to how end hosts are assigned [[IP address]]es and how subnetworks of IP host addresses are divided and grouped together. IP routing is a function performed by all hosts, but most popularly by internetwork routers, which typically use either [[interior gateway protocol]]s (IGPs) or [[external gateway protocol]]s (EGPs) to help make IP datagram forwarding decisions across IP connected networks.
Perhaps the most complex aspects of IP are addressing and [[routing]]. Addressing refers to how end hosts are assigned [[IP address]]es and how subnetworks of IP host addresses are divided and grouped together. IP routing is performed by all hosts, but most famously by internetwork routers, which typically use either [[interior gateway protocol]]s (IGPs) or [[external gateway protocol]]s (EGPs) to help make IP datagram forwarding decisions across IP connected networks.


See also: [[TCP/IP]]
See also: [[TCP/IP]]

Revision as of 17:28, 13 May 2003

The Internet Protocol (IP) is a data-oriented protocol used by source and destination hosts for communicating data across a packet-switched internetwork. The grouping of data sent in each packet is referred to as a datagram in an IP network. Each datagram contains enough information to allow each to be sent independent of previous or future datagrams. Packet switches, or network layer routers, are used to forward IP datagrams across interconnected layer 2 networks. Minimal functionality is required, and typically provided, within IP datagrams or within packet switches in order to simplify the overall architecture.

IP is the common element found in today's public Internet. It is described in IETF RFC 791, which was first published in September, 1981. This document describes the current and most popular network layer protocol in use today. This version of the protocol is assigned as version 4. IPv6 is also becoming popular and is the successor to IPv4. The Internet is running out of addresses. IPv6 has 128-bit source and destination addresses, providing more addresses than IPv4's 32 bits. Versions 0 through 3 were either reserved or unused. Version 5 was used for an experimental multicast protocol. Other version numbers have been assigned, usually for experimental protocols, but have not been widely used.

The first header field in an IPv4 datagram is the 4-bit version field. The second field is a 4-bit Internet Header Length (IHL) telling the number of 32-bit words the IPv4 header. Since an IPv4 header may contain a variable number of options, this field essentially specifies the offset to the data portion of an IPv4 datagram. A minimum IPv4 header is 20 bytes long so the value in decimal in the IHL field would be 5.

In RFC 791, the following 8 bits were allocated to a Type of Service (ToS) field. The original intention was for a sending host to specify a preference for how the datagram would be handled as it made its way through an internetwork. For instance, one host could set its IPv4 datagrams' ToS field value to prefer for low delay, while another might prefer high reliability. In practice, the ToS field has not been widely implemented. However, a great deal of experimental, research and deployment work has focused on how to make use of these eight bits. These bits have been redefined and most recently through DiffServ working group in the IETF and the Explicit Congestion Notification codepoints (see RFC 3168).

The 16-bit IPv4 field defines the entire datagram size, including header and data, in 8-bit bytes. The minimum-length datagram is 576 bytes and the maximum is 65535. In some cases, subnetworks impose further restrictions on the size. In this case, datagrams must br fragmented. Fragmentation is handled in either the host or packet switch in IPv4 or in the host only in IPv6.

The next 16-bit field is an identification field. This field is primarily used for uniquely identifying fragments of an original IP datagram. Some experimental work has suggested using the ID field for other purposes, such as for adding packet tracing information to datagrams in order to help traceback source address spoofed datagrams.

A 3-bit field follows and is used to control or identify fragments.

The fragment offset field is 13-bits long and helps a receiver determine the place of a particular fragment in the original IP datagram.

An 8-bit time to live (TTL) field helps prevent datagrams from persisting (e.g. going in circles) on an internetwork. Historically the TTL field limited a datagram's lifetime in seconds, but has come to be a hop count field. Each packet switch (or router) that a datagram crosses decrements the TTL field by one. When the TTL field hits zero, the packet is no longer forwarded by a packet switch and dies.

An 8-bit Protocol field follows. This field defines the next protocol used in the data portion of the IP datagram. The Internet Assigned Numbers Authority maintains a list of Protocol numbers. Common protocols and their decimal values include ICMP (1), TCP (6) and UDP (17).

The following field is a 16-bit checksum field for the IPv4 datagram header. Some values in a IPv4 datagram header may change at each packet switch hop, so the checksum must be recomputed on its way through an internetwork.

The checksum is followed by a 32-bit source address and 32-bit destination address respectively. Note, IPv6 source and destination addresses are 128 bits each.

Optional header fields may follow the destination address field, but these are not used in most IP networks. Option fields may be followed by a pad field that ensure the datagram header is aligned on a 32-bit word boundary. In IPv6, options move out of the standard header and are specified by a Next Protocol field, similar in function to IPv4's Protocol field.

Perhaps the most complex aspects of IP are addressing and routing. Addressing refers to how end hosts are assigned IP addresses and how subnetworks of IP host addresses are divided and grouped together. IP routing is performed by all hosts, but most famously by internetwork routers, which typically use either interior gateway protocols (IGPs) or external gateway protocols (EGPs) to help make IP datagram forwarding decisions across IP connected networks.

See also: TCP/IP

Further reading: