Internet Protocol version 4: Difference between revisions

From Citizendium
Jump to navigation Jump to search
m (Text replacement - "[[" to "")
mNo edit summary
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{PropDel}}<br><br>{{subpages}}
{{subpages}}
Version 4 of the '''Internet Protocol (IP)''', specifically '''IPv4''' has been the principal internal data transfer of the Internet]] since 1980. It will gradually be replaced by Internet Protocol version 6]] ('''IPv6''').
Version 4 of the '''Internet Protocol (IP)''', specifically '''IPv4''' has been the principal internal data transfer of the Internet since 1980. It will gradually be replaced by Internet Protocol version 6 ('''IPv6''').


In the Internet Protocol Suite]] architecture, all traffic is broken up into IP packets, which are then routed]] over arbitrary data link protocol]]s and network medium|physical media]]. Internet architects speak of both versons of IP as "medium agnostic"; an application can move from running over an Ethernet]] to point-to-point optical fibers with no changes to IP and the protocols above it.  
In the Internet Protocol Suite architecture, all traffic is broken up into IP packets, which are then routed over arbitrary data link protocols and network medium|physical media. Internet architects speak of both versons of IP as "medium agnostic"; an application can move from running over an Ethernet to point-to-point optical fibers with no changes to IP and the protocols above it.  


Since the routers do not retain knowledge of relationships (e.g., sessions or connections) between endpoints, each IP packet must contain a source and destination address. The role of the destination address is clearly necessary to forward the packet. The source address, however, has a number of housekeeping and security functions. For now, assume the source address is needed if the router or destination host needs to send an error message back to the source.
Since the routers do not retain knowledge of relationships (e.g., sessions or connections) between endpoints, each IP packet must contain a source and destination address. The role of the destination address is clearly necessary to forward the packet. The source address, however, has a number of housekeeping and security functions. For now, assume the source address is needed if the router or destination host needs to send an error message back to the source.
Line 8: Line 8:
IPv4 uses 32 bit binary addresses. At a given point in a network, some number of bits, starting with the leftmost, form the '''prefix''', or the basic information a router needs to decide where to forward the packet. You could think of a prefix as the identifier of a highway or street. The bits that follow the prefix only become significant on the destination "street", where they identify the final destination of a "house on the street" or a "host on the subnet". Subnet, while a little dated as a term, still is in common use to describe the medium to which hosts connect.
IPv4 uses 32 bit binary addresses. At a given point in a network, some number of bits, starting with the leftmost, form the '''prefix''', or the basic information a router needs to decide where to forward the packet. You could think of a prefix as the identifier of a highway or street. The bits that follow the prefix only become significant on the destination "street", where they identify the final destination of a "house on the street" or a "host on the subnet". Subnet, while a little dated as a term, still is in common use to describe the medium to which hosts connect.


See Classless Inter-Domain Routing]] for a discussion of current address assignment and usage.
See Classless Inter-Domain Routing for a discussion of current address assignment and usage.
==Packet structure==
==Packet structure==


The first four bits establish the IP version number; the only valid values are 0100 for IPv4 and 0110 for IPv6.  Should there be a successor to Version 6, under current conventions, that would be version 9, as the intervening numbers were assigned to experimental protocols to succeed Version 4. Of the several choices, version 6 were adopted.
The first four bits establish the IP version number; the only valid values are 0100 for IPv4 and 0110 for IPv6.  Should there be a successor to Version 6, under current conventions, that would be version 9, as the intervening numbers were assigned to experimental protocols to succeed Version 4. Of the several choices, version 6 were adopted.


Option fields for IPv4 are rarely used. Their encoding imposed substantial overhead, and a very different option-handling technique is used in IPv6]]. It will be assumed, in this article, that the options fields are not used, and that the bytes following the 20-byte header all belong to the payload protocol indicated by the #Protocol identification|protocol identification]] field.
Option fields for IPv4 are rarely used. Their encoding imposed substantial overhead, and a very different option-handling technique is used in IPv6. It will be assumed, in this article, that the options fields are not used, and that the bytes following the 20-byte header all belong to the payload protocol indicated by the #Protocol identification|protocol identification field.
                                      
                                      
     0                  1                  2                  3   
     0                  1                  2                  3   
Line 34: Line 34:
The next four bits are straightforward enough: they are the length of this specific packet's header in units of 32 bits. Since IP options are rarely used, the value is almost always binary 0101.
The next four bits are straightforward enough: they are the length of this specific packet's header in units of 32 bits. Since IP options are rarely used, the value is almost always binary 0101.
===Type of Service===
===Type of Service===
This field has undergone several revisions, and its current use is defined by differentiated service]]s.  
This field has undergone several revisions, and its current use is defined by differentiated services.  
===Fragmentation fields===
===Fragmentation fields===
The total length, identification, fragment offset, and flags work together to support the #fragmentation]] mechanism.
The total length, identification, fragment offset, and flags work together to support the #fragmentation mechanism.


===Time to Live===
===Time to Live===
Rather than being a quote from a movie such as ''The Godfather'', TTL is not actually a time, but a counter intended to prevent loops. Whenever a packet enters a router, the TTL field is decremented by 1. If the result is zero, it is assumed the packet is looping because it has exceeded the maximum plausible number of routers in the network.
Rather than being a quote from a movie such as ''The Godfather'', TTL is not actually a time, but a counter intended to prevent loops. Whenever a packet enters a router, the TTL field is decremented by 1. If the result is zero, it is assumed the packet is looping because it has exceeded the maximum plausible number of routers in the network.
===Protocol identification===
===Protocol identification===
The next field identifies the type of protocol carried in this packet's data field. Most often, the value will be that of an end-to-end protocol, or a tunneling protocol. Otherwise, it is likely to be a control protocol internal to the layer at which IP operates. Internet Control Message Protocol (ICMP), used principally for troubleshooting and error reporting, will be common. Several routing protocols do not use a higher-level transport protocol, so the packet could be Open Shortest Path Firat]] or Cisco's (Enhanced) Interior Gateway Protocol.
The next field identifies the type of protocol carried in this packet's data field. Most often, the value will be that of an end-to-end protocol, or a tunneling protocol. Otherwise, it is likely to be a control protocol internal to the layer at which IP operates. Internet Control Message Protocol (ICMP), used principally for troubleshooting and error reporting, will be common. Several routing protocols do not use a higher-level transport protocol, so the packet could be Open Shortest Path Firat or Cisco's (Enhanced) Interior Gateway Protocol.
*
*


Line 51: Line 51:
! Value
! Value
|-
|-
| Internet Control Message Protocol]]
| Internet Control Message Protocol
| Control: diagnostics and error reporting
| Control: diagnostics and error reporting
| 1
| 1
|-
|-
| Internet Group Management Protocol]]
| Internet Group Management Protocol
| Control: multicast group membership
| Control: multicast group membership
| 2
| 2
|-
|-
| IP in IP]]
| IP in IP
| Tunneling
| Tunneling
| 4
| 4
|-
|-
| Transmission Control Protocol]]
| Transmission Control Protocol
| End-to-end
| End-to-end
| 6
| 6
|-
|-
| User Datagram Protocol]]
| User Datagram Protocol
| End-to-end
| End-to-end
| 17
| 17
|-
|-
| Generic Route Encapsulation]]
| Generic Route Encapsulation
| Tunneling
| Tunneling
| 47
| 47
|-
|-
| Interior Gateway Routing Protocol]]
| Interior Gateway Routing Protocol
| Routing
| Routing
| 88
| 88
|-
|-
| Open Shortest Path First]]
| Open Shortest Path First
| Routing
| Routing
| 89
| 89
|}
|}
===Header checksum===
===Header checksum===
This is an error control]] field of very limited power to detect bit errors. All modern medium-specific protocols below IP have much stronger error detection capability than the Fletcher algorithm used in IPv4.  IPv6 recognized that this field is of little practical value, and does not support regular error checking of the header.
This is an error control field of very limited power to detect bit errors. All modern medium-specific protocols below IP have much stronger error detection capability than the Fletcher algorithm used in IPv4.  IPv6 recognized that this field is of little practical value, and does not support regular error checking of the header.


End-to-end protocols above IPv4 use the same checksum algorithm, but they look at the overall data being delivered, not just the header. Since an errored packet header may very well fail routing and be dropped, if reliable delivery is needed, TCP]] can be used and will trigger retransmission. There are other alternatives for reliable delivery using the lower-overhead UDP, with error control in the application protocol.
End-to-end protocols above IPv4 use the same checksum algorithm, but they look at the overall data being delivered, not just the header. Since an errored packet header may very well fail routing and be dropped, if reliable delivery is needed, TCP can be used and will trigger retransmission. There are other alternatives for reliable delivery using the lower-overhead UDP, with error control in the application protocol.
==Maximum Transmission Unit issues==
==Maximum Transmission Unit issues==
Several fields work together to support '''fragmentation''', but, over time, it was realized that fragmentation was a high-overhead process, and could be avoided through MTU path discovery. While every IPv4 packet contains the necessary header fields for a very general case of fragmentation; IPv6 makes it an option, and an option that is supported only at a limited number of points.
Several fields work together to support '''fragmentation''', but, over time, it was realized that fragmentation was a high-overhead process, and could be avoided through MTU path discovery. While every IPv4 packet contains the necessary header fields for a very general case of fragmentation; IPv6 makes it an option, and an option that is supported only at a limited number of points.
Line 99: Line 99:
  | url = http://www.ietf.org/rfc/rfc1853.txt }}</ref>
  | url = http://www.ietf.org/rfc/rfc1853.txt }}</ref>
===Tunneling===
===Tunneling===
MTU issues become complex when tunneling is involved. Tunneling, in principle, is invisible to the end user. Assume that the real MTU on a router interface is 1500 bytes. Using the simplest tunneling protocol]], IP in IP]],<ref name=RFC1853>{{citation
MTU issues become complex when tunneling is involved. Tunneling, in principle, is invisible to the end user. Assume that the real MTU on a router interface is 1500 bytes. Using the simplest tunneling protocol, IP in IP,<ref name=RFC1853>{{citation
  | id = RFC 1853
  | id = RFC 1853
  | title = IP in IP Tunneling
  | title = IP in IP Tunneling
Line 111: Line 111:
  | url = http://www.ietf.org/rfc/rfc1191.txt }}</ref> and without knowledge of the tunnel, there may be a performance impact. The severity of the performance impact depends on how many of the original packets have a payload between 1481 and 1500 bytes; if few do, there will be little degradation.
  | url = http://www.ietf.org/rfc/rfc1191.txt }}</ref> and without knowledge of the tunnel, there may be a performance impact. The severity of the performance impact depends on how many of the original packets have a payload between 1481 and 1500 bytes; if few do, there will be little degradation.


A potential problem comes if the MTU discovery software, on discovering 1500 does not work, next tries a ''much'' smaller MTU, such as 1200 or 600. MTU path discovery software, on discovering a failure at the native MTU, would do well to try slightly smaller MTUs that reflect common tunneling protocol overhead, or even combinations of tunneling protocols. These include IP in IP, Generic Route Encapsulation]],<ref name=RFC2784>{{citation
A potential problem comes if the MTU discovery software, on discovering 1500 does not work, next tries a ''much'' smaller MTU, such as 1200 or 600. MTU path discovery software, on discovering a failure at the native MTU, would do well to try slightly smaller MTUs that reflect common tunneling protocol overhead, or even combinations of tunneling protocols. These include IP in IP, Generic Route Encapsulation,<ref name=RFC2784>{{citation
  | id = RFC 2784
  | id = RFC 2784
  | title = Generic Routing Encapsulation (GRE)
  | title = Generic Routing Encapsulation (GRE)
Line 123: Line 123:
  | url = http://www.ietf.org/rfc/rfc2890.txt}}</ref> and IPSec. The IPSec case may involve either the Authentication Header alone, or the Authentication Header and Encapsulating Security Payload.
  | url = http://www.ietf.org/rfc/rfc2890.txt}}</ref> and IPSec. The IPSec case may involve either the Authentication Header alone, or the Authentication Header and Encapsulating Security Payload.
==References==
==References==
{{reflist|2}}
{{reflist|2}}[[Category:Suggestion Bot Tag]]

Latest revision as of 12:00, 2 September 2024

This article is developing and not approved.
Main Article
Discussion
Definition [?]
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
This editable Main Article is under development and subject to a disclaimer.

Version 4 of the Internet Protocol (IP), specifically IPv4 has been the principal internal data transfer of the Internet since 1980. It will gradually be replaced by Internet Protocol version 6 (IPv6).

In the Internet Protocol Suite architecture, all traffic is broken up into IP packets, which are then routed over arbitrary data link protocols and network medium|physical media. Internet architects speak of both versons of IP as "medium agnostic"; an application can move from running over an Ethernet to point-to-point optical fibers with no changes to IP and the protocols above it.

Since the routers do not retain knowledge of relationships (e.g., sessions or connections) between endpoints, each IP packet must contain a source and destination address. The role of the destination address is clearly necessary to forward the packet. The source address, however, has a number of housekeeping and security functions. For now, assume the source address is needed if the router or destination host needs to send an error message back to the source.

Addressing

IPv4 uses 32 bit binary addresses. At a given point in a network, some number of bits, starting with the leftmost, form the prefix, or the basic information a router needs to decide where to forward the packet. You could think of a prefix as the identifier of a highway or street. The bits that follow the prefix only become significant on the destination "street", where they identify the final destination of a "house on the street" or a "host on the subnet". Subnet, while a little dated as a term, still is in common use to describe the medium to which hosts connect.

See Classless Inter-Domain Routing for a discussion of current address assignment and usage.

Packet structure

The first four bits establish the IP version number; the only valid values are 0100 for IPv4 and 0110 for IPv6. Should there be a successor to Version 6, under current conventions, that would be version 9, as the intervening numbers were assigned to experimental protocols to succeed Version 4. Of the several choices, version 6 were adopted.

Option fields for IPv4 are rarely used. Their encoding imposed substantial overhead, and a very different option-handling technique is used in IPv6. It will be assumed, in this article, that the options fields are not used, and that the bytes following the 20-byte header all belong to the payload protocol indicated by the #Protocol identification|protocol identification field.

   0                   1                   2                   3   
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Version|  IHL  |Type of Service|          Total Length         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |         Identification        |Flags|      Fragment Offset    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Time to Live |    Protocol   |         Header Checksum       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                       Source Address                          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    Destination Address                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    Options                    |    Padding    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Internet Header Length

The next four bits are straightforward enough: they are the length of this specific packet's header in units of 32 bits. Since IP options are rarely used, the value is almost always binary 0101.

Type of Service

This field has undergone several revisions, and its current use is defined by differentiated services.

Fragmentation fields

The total length, identification, fragment offset, and flags work together to support the #fragmentation mechanism.

Time to Live

Rather than being a quote from a movie such as The Godfather, TTL is not actually a time, but a counter intended to prevent loops. Whenever a packet enters a router, the TTL field is decremented by 1. If the result is zero, it is assumed the packet is looping because it has exceeded the maximum plausible number of routers in the network.

Protocol identification

The next field identifies the type of protocol carried in this packet's data field. Most often, the value will be that of an end-to-end protocol, or a tunneling protocol. Otherwise, it is likely to be a control protocol internal to the layer at which IP operates. Internet Control Message Protocol (ICMP), used principally for troubleshooting and error reporting, will be common. Several routing protocols do not use a higher-level transport protocol, so the packet could be Open Shortest Path Firat or Cisco's (Enhanced) Interior Gateway Protocol.

Common IPv4 payload types
Protocol Function Value
Internet Control Message Protocol Control: diagnostics and error reporting 1
Internet Group Management Protocol Control: multicast group membership 2
IP in IP Tunneling 4
Transmission Control Protocol End-to-end 6
User Datagram Protocol End-to-end 17
Generic Route Encapsulation Tunneling 47
Interior Gateway Routing Protocol Routing 88
Open Shortest Path First Routing 89

Header checksum

This is an error control field of very limited power to detect bit errors. All modern medium-specific protocols below IP have much stronger error detection capability than the Fletcher algorithm used in IPv4. IPv6 recognized that this field is of little practical value, and does not support regular error checking of the header.

End-to-end protocols above IPv4 use the same checksum algorithm, but they look at the overall data being delivered, not just the header. Since an errored packet header may very well fail routing and be dropped, if reliable delivery is needed, TCP can be used and will trigger retransmission. There are other alternatives for reliable delivery using the lower-overhead UDP, with error control in the application protocol.

Maximum Transmission Unit issues

Several fields work together to support fragmentation, but, over time, it was realized that fragmentation was a high-overhead process, and could be avoided through MTU path discovery. While every IPv4 packet contains the necessary header fields for a very general case of fragmentation; IPv6 makes it an option, and an option that is supported only at a limited number of points.

Fragmentation

Fragmentation takes place when a packet arrives at a router interface that supports a long packet. Let us assume the packet is 3000 bytes long. On consulting its forwarding information base, the router decides that the packet needs to be forwarded out a physical interface, which connects to a medium that will accept payloads of no longer than 1500 bytes.

MTU path discovery

If the sending host knew, before sending a packet, the minimum packet length supported on the end-to-end path, it could reduce its packet size to that minimum and avoid the need for fragmentation. The host can learn this through the technique of MTU path discovery.[1]

Tunneling

MTU issues become complex when tunneling is involved. Tunneling, in principle, is invisible to the end user. Assume that the real MTU on a router interface is 1500 bytes. Using the simplest tunneling protocol, IP in IP,[1] 20 bytes of overhead give the tunnel a 1480 byte maximum MTU. Without path MTU discovery,[2] and without knowledge of the tunnel, there may be a performance impact. The severity of the performance impact depends on how many of the original packets have a payload between 1481 and 1500 bytes; if few do, there will be little degradation.

A potential problem comes if the MTU discovery software, on discovering 1500 does not work, next tries a much smaller MTU, such as 1200 or 600. MTU path discovery software, on discovering a failure at the native MTU, would do well to try slightly smaller MTUs that reflect common tunneling protocol overhead, or even combinations of tunneling protocols. These include IP in IP, Generic Route Encapsulation,[3] [4] and IPSec. The IPSec case may involve either the Authentication Header alone, or the Authentication Header and Encapsulating Security Payload.

References

  1. 1.0 1.1 W. Simpson (October 1995), IP in IP Tunneling, RFC 1853
  2. J.C. Mogul, S.E. Deering (November 1990), Path MTU discovery, RFC 1191
  3. D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina (March 2000), Generic Routing Encapsulation (GRE), RFC 2784
  4. G. Dommety (September 2000), Key and Sequence Number Extensions to GRE, RFC 2890