Internet Protocol
The Internet Protocol is designed for use in interconnected systems of packet-switched computer communication networks. The internet protocol provides for transmitting blocks of data called datagrams from sources to destinations, where sources and destinations are hosts identified by fixed length addresses. [^RFC791]
The protocol manages address and fragmentation of datagram. It relies on higher level protocol like TCP for reliability and relies on lower level protocol like Ethernet for transmission. Each datagram is treated as an independent entity unrelated to other internet datagrams.
Four key mechanisms:
- Type of Service: chose the quality of service desired.
- Time to Live: upper bound on the lifetime (number of hops) of an internet datagram.
- Options: unnecessary for most common communication but provide control functions.
- Header Checksum: verification that information transmission was correct.
+------+ +-----+ +-----+ +-----+
|Telnet| | FTP | | TFTP| ... | ... |
+------+ +-----+ +-----+ +-----+
| | | |
+-----+ +-----+ +-----+
| TCP | | UDP | ... | ... |
+-----+ +-----+ +-----+
| | |
+--------------------------+----+
| Internet Protocol & ICMP |
+--------------------------+----+
|
+---------------------------+
| Local Network Protocol |
+---------------------------+
Protocol Relationships
Figure taken from RFC791 [^RFC791].
IPv4
This was the version of the internet protocol that got popular. This was the foundational protocol for the internet until IPv6 came along. Current both IPv4 and IPv6 are being used while more people adopt IPv6; further discussion about this later.
Addressing
IPv4 address is/was the primary addressing method for the internet protocol. Each host on the internet would receive a 32-bit number in the form of 4 octets, for example: 12.45.12.56. Each address has a network number followed by a local address. There are three formats or classes of internet addresses:
- Class A: The first bit is
0and the next 7 bits are network address and next 24 bits are local address. - Class B: The first two bits are
10and the next14bits are network addresses, remaining 16 bits are local address. - Class C: The first three bits are
110and the next21bits are network address and the remaining 8 bits are local address.
For more details about address please refer to IP Addresses | Suchicodes.
Some other things I’ve left out:
CIDRnotation allows us to assign any number of bits for the network part of the IP address. Services like AWS let you choose how many bits you want to allocate.- Some address are reserved, such as private IP address.
Fragmentation
Fragmentation is necessary when a datagram comes from a local net that allows large packets but it must then traverse a local net that limits packets to smaller size to reach its destination.
A datagram may be marked as «don’t fragment» and such datagrams, if cannot be delivered to its destination without fragmentation, must be discarded instead.
A sender may break a datagram into an arbitrary number of pieces.
Process flow for fragmentation:
- Sender either creates or receives a datagram with a destination address not that of the sender. Let’s called this datagram OG (for original).
- Sender identifies that datagram OG is too large for the next hop (receiver) in the route to the destination.
- Sender decides to split the datagram into sizes manageable by the receiver at some 64 bit boundary. Let’s say sender decides to split OG into N1 and N2.
- Internet header fields from OG are copied into both N1 and N2.
- N1 length field is updated to match the size of N1. N2 length is also updated.
- N1’s more-fragments flag is set to one.
- N2’s more-fragments flag is set of the value of more-fragments in OG.
- N2’s fragment offset field is set to \(\text{OG's offset field} + (\text{N1's length} / 64)\) (divide by 64 since we only split into 64-bit blocks of fragments, \((\text{N1's length} / 64)\) is the number of fragment blocks).
- Sender transmits N1 and N2.
- Receiver combines internet datagram (if desired) that have the same identification, source, destination, and protocol.
Side Note: (I was curious as to why would anyone set a «don’t fragment» flag)
- Fragmentation increases loss, any lost fragment kills whole packet
- Adds delays of reassembly
- Useful to find out MTU (maximum transit unit) along a path. TCP sets DF bit to 1 and send packet too large for link, the router drops and sends back an ICMP «Fragmentation Needed» message containing the maximum MTU of the link.
- IPsec ESP cannot be fragmented along with certain tunneling protocols.
Header Format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example Internet Datagram Header
Figure taken from RFC791 [^RFC791].
Version (4-bits): Indicates the version of IP being used. Note that this is the first 4-bits so if the version is different, the rest of the header spec will be different. This header format is specifically for Ipv4.
IHL (4-bits): Internet Header Length is the header length in 32 bit words. The minimum value for a correct header is 5 (20 bytes).
Type of Service (8-bits): This was intended to tell the router the quality of services you wanted, such as low-delay, high-reliability, and high-thoughput. You can read about what was intended in RFC 791. However, this field was changed by RFC 2474 and RFC 3168 to monitor things like congestion.
Total Length (16 bits): Length of datagram measured in octets, including internet header and data. Allows length to be up to 65,535 octets. All hosts must be prepared to accept datagrams of up to 576 octets. «It is recommended that hosts only send datagrams larger than 576 octets if they have assurance that the destination is prepared to accept the larger datagrams» [^RFC791].
Identification: (16 bits): An identifying value assigned by the sender to aid in assembling the fragments of a datagram.
Flags (3 bits):
Bit 0: reserved, must be zeroBit 1: (DF) 0 = May fragment, 1 = Don’t fragment.Bit 2: (MF) 0 = Last fragment, 1 = More fragments.
Fragment Offset (13 bits): Indicates where in the datagram this fragment belongs. This fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero.
Time to Live (8 bits): Indicates the maximum time the datagram is allowed to remain in the internet system. If this field contains the value zero, then the datagram is to be destroyed. This field used to be measured in units of seconds and each router had to decrease the TTL by at least one. However, since it rarely more than a full second to process the datagrams, TTL effectively turned into a hop count, not a real timer. All modern stacks treat it as a hop count, and even traceroute relies on it behaving as a hop counter.
Protocol (8 bits): This indicates the next level protocol used in the data portion of the internet datagram. The numbers used are specified by RFC 790, e.g. TCP is
6and UDP is17.Header Checksum (16 bits): A checksum on the header only. Since some header fields change (like TTL), this is verified and recomputed at each point that the internet header is processed.
Source & Destination Address (32 bits each): The source and destination ipv4 addresses.
Options: There are a bunch of options that can be attached to the IPv4 header, please refer to the RFC for the list – RFC 791.
IPv6
The main improvement provided by the IPv6 protocol over the IPv4 protocol include:
Expanded addressing capabilities: IP address size is now 128 bits from 32 bits. It supports more nodes and more levels of addressing hierarchy. Ipv6 also adds a scope field to multicast addresses.
Header format simplification: Dropped some fields, made some optional, to reduce the common-case processing cost of packet handling and to limit the bandwidth cost of the IPv6 header.
Improved support for extensions and options: Encoding efficiency, less stringent limits, greater flexibility.
Flow labeling capabilities: label packets belonging to a particular traffic «flow» for which sender can request special handling such as non-default quality or «real-time» service.
Authentication and privacy capabilities: extensions to support authentication, data integrity, and data confidentiality are specified for IPv6.
Header Format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure taken from [^RFC2460].
References
- [^RFC2460]: https://www.rfc-editor.org/rfc/rfc2460
- [^RFC791]: https://www.rfc-editor.org/rfc/rfc791