WikiJournal Preprints/A Survey on Internet Protocol version 4 (IPv4)

From Wikiversity
Jump to navigation Jump to search

WikiJournal Preprints logo.svg

WikiJournal Preprints
Open access • Publication charge free • Public peer review

WikiJournal User Group is a publishing group of open-access, free-to-publish, Wikipedia-integrated academic journals. <seo title=" Wikiversity Journal User Group, WikiJournal Free to publish, Open access, Open-access, Non-profit, online journal, Public peer review "/>

<meta name='citation_doi' value=>

Article information

Authors: Michel Bakni[i]ORCID iD.svg , Sandra Hanbo

Michel Bakni; Sandra Hanbo, "Internet Protocol Version 4 (IPv4)", WikiJournal Preprints, Wikidata Q104661268




Abstract

The fourth version of internet protocol, IPv4 for short, is a networking protocol that works at the network layer according to the open systems interconnection model. This protocol was developed in 1981 within a work of DARPA and was on the pillars which the internet later built on.

The internet protocol version four performs a set of functions: service quality control, addressing, fragmentation reassembly, multiplexing, source routing, and protocol parameters describe how these functions are performed. After years of using it on the Internet, and with the great expansion of its network in the early 1990s, the protocol suffered from address space exhaustion problem. As a result, a set of solutions have been developed within two strategies, the first is short-term, includes the development of techniques for translating network addresses and classless routing between domains, and the second is long-term and includes the development of an alternative networking protocol to replace the fourth version, which is the sixth version of the Internet protocol. The internet protocol version 4 requires a number of services that it provides along with a number of other protocols, as it obtains the address of the linking protocol working in the link layer depending on the work of the address translation protocol, and it also depends on the package of the Internet security protocol features, such as privacy in the Internet. And the Internet Group Management Protocol to address issues specific to multicast broadcasting.


Historical Background[edit | edit source]

A timeline for the development of the Transmission Control Protocol TCP and Internet Protocol IP.

The development of packet switching technology in the 1960s was the first major step towards Internet Protocol (IP). In a packet-switching network, digital information is carried in small chunks called packets, each of which contains a fixed number of bytes. Sending one packet, from its source to its destination, is totally independent of sending other packets sharing the same channel.[1]

In 1973, Louis Pouzin created CYCLADES, the first packet-switched network that successfully adopts the concept of datagram for the first time in the history of data networks. According to Pouzin, a datagram contains all the information needed to define its source and the final destination.[2] Based on that, data networks started to support connectionless channels instead of the traditional connection-oriented telecommunication channels. In a connectionless channel, packets are routed based on source and destination addresses carried by the packets themselves. These datagrams were "eagerly embraced" by the designers of the early Internet, and this resolution had deep effects on the development of the other network protocols. [3]

In 1974, a paper titled "A Protocol for Packet Network Interconnection" was published by Bob Kahn and Vint Cerf.[4] This paper is the starting point of the timeline shown in Figure 1, it describes a transport protocol to be activated between hosts in a packet-switching network. The suggested protocol provides several services related to data packets including flow control, process addressing, and end-to-end error checking. The protocol was called Transmission Control Program (TCP)[a] and it was described in a specific Request for Comments (RFC) that has the code name "RFC 675".[6]

Later, the functions of the program were divided into two separated protocols: Transmission Control Protocol (TCP) and IP. Regarding IP, it was developed as a part of a project supported by the Defense Advanced Research Projects Agency (DARPA). Between 1977 and 1979, several experimental versions of the protocol were released, the numbers used to distinguish the progress drafting the standard were 0,1 and 4. [b] During this period, many Internet Experiment Notes (IENs) that describe the IP versions before the official standard were released:

  • IEN2, dated: August 1977, titled: "Comments on Internet Protocol and TCP". The nodes showed the need to divide functionalities of the transmission control program into two separate protocols. In three years, the two protocols will be IPv4 and TCP. IEN2 also proposed the first version of IP and used a version number equal to 0 to identify it in the protocol header.[7]
  • IEN 26, February 1978, "A proposed new internet header format". It described version 1 of the protocol (IPv1).[8]
  • IEN 28, February 1978, "Draft internetwork Protocol specification Version 2". It described version 2 of the protocol (IPv2).[9]
  • IEN 41, June 1978, "Internet Protocol Specification Version 4" [c]. This was the first IEN to describe IPv4, however, the header structure was different from the current protocol.[11]
  • IEN44, June 1978, "Latest header format". It summarized the edits on the header protocol reported in IEN41.[12]
  • IEN 54, September 1978, "Internetwork Protocol specification Version 4". This note included a description identical to the structure adopted later by the official standard of the protocol.[13]
A part of IPv4 standard first page (RFC 791).

Later in 1980, IEN 128 was given the code name RFC 760 to become the first RFC dedicated to the internet protocol.[14] In September of the next year, RFC 791 was published under the title: "Internet Protocol", (Figure 2). Since then, it is the official standard of IPv4. In the next two years, the protocol had been gradually adopted in the United States, before being the main internetwork protocol in the network starting from the 1st of January 1983.[15][16]

Internet Protocol version 5 (IPv5) was developed under the name: "Internet Stream Protocol", but it did not exceed the experimental stage.[17] Additionally, between 1988 and 1993, when address space exhaustion was facing IPv4, a new version of the protocol was developed as a response. The new protocol was arbitrary named IPv7 as its developer stated, however, the project was completely abandoned in 1993.[18]

Internet Protocol version 6 (IPv6) is the successor of IPv4. It is essentially developed to answer the IPv4 address space exhaustion problem. Whereas an IPv4 address is 32 bits long, providing a space that includes 4.3x109 addresses only, an IPv6 address is 128 bits long, supplying 3.4x1038 addresses. IPv6 was firstly described in RFC 1883.[19]. Then, many modifications were included and a new standard was released in 1998 under the code name RFC 2460.[20] Lastly, in 2017, RFC 8200 was issued to cover adjustments made in the past 20 years into the IPv6 standard.[21]

On 1 April 1994, Internet Engineering Task Force (IETF) published an RFC confirming the development of IPv9. However, it was an April Fool.[22]

Operation[edit | edit source]

The main objective of the internet protocol is to allow applications in network nodes to exchange data packets via the network. In order to run IPv4, each node must support an IP module at the network layer of its protocol stack. Figure 3 shows the position of the network layer in the TCP/IP model, where it is located between the transport layer and data link layer. When an IPv4 node is sending data, the IP encapsulates the Protocol Data Unit (PDU) coming from the transport layer and passes the results to the data link layer. When the node is receiving data, the IP accepts PDUs of the link layer, then, the protocol decides which protocol will be the next step for the data, either, one of the protocols in the transport layer or another protocol running in the network layer. In both cases, the IP decapsulates the PDU, removing the IP header, then, delivers it to the next protocol.[23][24]

Basic TCP/IP network node.

IPv4 belongs to a family of network layer protocols called the internetwork protocols.[25][26] Of this family's functionalities,[27] IPv4 provides:

  • A mechanism to determine the quality of service (QoS) needed for each data packet separately.
  • A space of digital addresses, each of which is called an internet address, the protocol also determines the structure of these addresses. Each entity that supports the IP in the network hosts at least one IP address, thus, it is to be called a host. This functionality is called addressing, IP supports two types of addressing: classful and classless. In the classful addressing, the address space is divided into a set of groups that includes a predetermined number of addresses, each group is called a class. Addresses that belong to the same class share the same structure. In the classless addressing there are no specified-length classes, and the address space is divided flexibly as needed.[28]
  • Fragmentation and reassembling. If the IP host is sending data, IP can fragment it into smaller pieces if needed. The same process can take place in any router along the packets' ways to their destination. Fragmentation happened when a packet's length is greater than the Maximum Transmission Unit (MTU) of the next network where the packet is to be routed. On the contrary, the reassembling can only be done at the final destination. It aims to reconstruct the original data packet as it was in before the fragmentation process.[29]
  • A mechanism to multiplex data from different applications together at the packet source and to demultiplex them at the destination.[30]
  • An optional function to provide source routing. It is a routing mechanism providing the source of the packet with the ability to determine an optional or mandatory route for the packets they create. If this function is used and set to be optional, the routers are recommended to use the route specified by the source. If it is used and set to be mandatory, the routes must forward the packet in the route specified by the source. If this is not possible, it must discard it.[31]

IPv4 has limitations, it can not provide several internetwork-related functionalities discussed in the following:

  • IPv4 does not provide host auto-configuration. The configuration of hosts' IP addresses can be achieved either manually or automatically through a dynamic configuration protocol,[32] such as Dynamic Host Configuration Protocol (DHCP).[33]
  • IPv4 does not route data packets, and routing protocol is needed to establish paths between hosts through the network.[34]
  • IPv4 does not provide a reliable data transfer service because it uses connectionless channels. If an error occures while transferring data packets, the lost data can not be restored. However, reliable transport protocols, such as TCP, can be used above IP to provide reliable data transferring service using connection-oriented channels.[35]
  • IPv4 does not have any kind of flow control.[36]
  • IPv4 does not have any built-in security mechanisms.

Header Format[edit | edit source]

Data packet structure for IPv4

PDU of IPv4 is called a packet, it consists of a header and data payload. The header length varies between 20 and 60 bytes, and the payload length can grow up to reach around 65 thousand bytes. In total, the Maximum length of IPv4 data packet can theoretically be 65535 bytes.[37]

The header includes two types of fields, permanent fields and options. The length of permanent fields is 20 bytes. An IPv4 packet might not include any options, however, if it has, the maximum allowed length is 40 bytes. The structure of the IPv4 packet is shown in Figure 4.[38]

Permanent fields[edit | edit source]

The structure of Flags field in the IPv4 header

The header contains 12 permanent fields. The structure and the relative of these fields are displayed in Figure 4. In the following, a brief description for each field can be found:[39]

  • Version: its length is 4 bits. The value of this field is always set to 4 in all IPv4 packets.
  • Internet Header Length (IHL): 4 bits, it determines the end of the header and the start of the payload. The value represents a number of 32-bit (4 bytes) words in the header. Because the minimum header length is 20 bytes, the minimum acceptable value for this field is 5.
  • Type of Service (ToS): 8 bits, it contains a code used to describe the QoS needed while the packet is being transmitted along the network. The parameters used to configure QoS are the precedence, delay, throughput and reliability. The structure of this field was first defined in the RFC 791, then a new structure and mechanism to describe QoS was introduced in RFC 1349,[40] and later in RFC 2474.[41]
  • Total Length: 16 bits, it defines the length of the packet in bytes. The maximum allowed value is 65535.
  • Identification: 16 bits, it is used to uniquely distinguish a packet and all its fragments resulted from the fragmentation. This field helps the IP in the destination to detect all fragments, in order to reassemble them producing the original data packet again.[42]
  • Flags: 3 bits, this field contains one reserved bit always set to zero and two flags: Don't fragment and more fragments (Figure 5). The first flag is used to prevent fragmentation under all circumstances (when set to 1). The second flag is used to distinguish the last fragment resulting from one packet's fragmentation process of one packet (if set to 1). These flags are only used if the packet was subject to a fragmentation process.
  • Fragment Offset: 13 bits, this field is set only if fragmentation is used. It contains the offset of the fragmented packet relative to the start of the original data packet before fragmentation. The fragment offset field helps to reassemble fragments correctly in the destination. The value of this field is equal to the real offset divided by 8. Thus, if this field contains 1, then, the real shift is 8 bytes. The maximum allowed value for the shift is 213=8192 which represents 65536 Bytes.[43]
  • Time To Live (TTL): 8 bits, it is set by the source of the packet, and contains the maximum number of hops the packet can have, which is 255. Each node processes the packet, like routers and gateways, checks the value of this field first. If it is equal to zero, the packet is to be discarded. If not, the node subtracts one from the value of this field.
  • Protocol: 8 bits, it is used by IPv4 multiplexing mechanism. The field contains codes used to define the protocol that is going to process PDU next. The codes are standardized by Internet Assigned Numbers Authority (IANA).[44]
  • Header Checksum: 16 bits, it contains the output of the checksum algorithm that was applied only to the header fields. The protocol standard explains the algorithm used to calculate the value of this field.[45] This algorithm must be applied to recalculate this field every time a change in the header is taking a place. For example, decreasing the value of the TTL field.
  • Source address: 32 bits, it contains the IPv4 address of the sender of the packet that is called the packet source.
  • Destination Address: 32 bits, it contains the IPv4 address of the destination of the packet that is called the packet destination.

Options[edit | edit source]

IPv4 option general structure

In the IPv4 header, the existence of options inside the header is optional, however, the support of the options is mandatory in all IPv4 hosts and routers. There is no fixed length for the options field in an IPv4 packet, which might include no options, one or more with a maximum length of 40 bytes.[46] The options field must always end at the boundary of a 32-bit word. If this is not the case, the missed bits will be completed with padding bits.[47]

IANA maintains standardrized information related to the IPv4 options.[48] All the options, except two, have a TLV structure, Figure 6 shows this structure which includes three fields:

  • Type: 8 bits, it consists of three subfields:
    • Copy flag: 1 bit, it is a single bit length referred to as C. The copy flag is used with fragmentation to determine whether the option used is to be copied to all packets (C=1) or not (C=0).
    • Class: 2 bits, it is used to indicate the functionality of the option: (00)2 for "control" or (10)2 for "debugging and measurement".
    • Number: 5 bits, it is a unique numerical value to distinguish each option.
  • Length: 8 bits, it contains the length of the options field in the IPv4 packet.
  • Value: variable length, it is specified by the type of the option.

The two exceptions that do not follow the previous TLV structure are:[49]

  • End of options list: 8 bits, (00)16, it is used to mark the End of the options field should be always the last field.
  • No operation field: 8 bits, set to (01)16, it sits in-between two options for the purpose of separation, if the header contains more than one option.

IPv4 options are rarely used, because they can be a basis for launching several attacks.[50]

Functionalities[edit | edit source]

Quality of Service[edit | edit source]

The structure of the ToS field in the IPv4 header according to RFC 791
The structure of the ToS field in the IPv4 header according to RFC 2474

When IPv4 is used, the QoS is set using the ToS field in the protocol header, the structure of this field is shown in Figure 7. The original standard of the protocol had reserved three bits in the ToS field to determine the precedence of the packet that contains the header, and the standard defines 8 codes for these bits, each refers to a specific level of precedence. In addition to that, the IPv4 standard specified the QoS of services needed for each packet in terms of three elements: delay, throughput and reliability. The mechanism is implemented by reserving a bit for each element in the ToS field creating three subfields. For each element, if the corresponding bit is set to 0, this indicates that the packet accepts regular delay, a normal throughput and regular reliability respectively. On the other hand, the value of 1 for each bit indicates the need for the low delay, high throughput and higher reliability respectively. By choosing different combinations for the previously described bits, the standard allows the making of a trade-off between the QoS elements.[51]

In 1998, the concept of Differentiated Services (DS) was introduced.[52] In order to ensure QoS in an IPv4 network, the concept defined a simple and scalable architecture for classifying and managing network data.[53] Based on that, the ToS field were also restructured, merging together the previously mentioned subfields. As a result, the Differentiated Services CodePoint (DSCP) field was created (Figure 8).[54] The concept of DS depends on categorizing data packets into a specific number of classes, each has a unique identifier. The routers are then to be configured to recognize the QoS needed for each packet based on the identifier it carries. When DS is applied, the routers at the edge of the network classify the packets, while the core routers only process the packets, so that the process of setting the quality of service provided at the heart of the network remains fast and simple.[55]

The network where the previous set of routers are found is called the differentiated services domain.[56] Any router in the DS domain handles each incoming packet independently from other routers, and that is why this mechanism is called Per-Hop Behavior (PHB). Four standard types of router's behavior are defined:[57]

  • Default Forwarding (DF) behavior, it is the choice selected by a router processing a data packet when no other behavior fits that packet. Supporting DF behavior is mandatory on all routers that support DS. When this behavior is selected, the value of the DS field is to be set to (00000)2.
  • Expedited Forwarding (EF) behavior, it is the behavior corresponding to real-time applications such as sound and video. The provided QoS, when this behavior is chosen, satisfy requirements of low delay, low jitter and low data loss. If this behavior is selected, the value of the DS field is to be set to (10110)2[58]
  • Assured Forwarding (AF) behavior, it allows packets delivery as long as the data traffic does not exceed a specified threshold. If it does, the probability of discarding packets increases on a three-zone scale: low, medium and high. In order to provide users with configuration options, there are four different classes applies for each of the previously mentioned zones ending with a total of 12 possible levels to configure. Table 1 provides a recommended set of values of the DS field for all the classes if the AF behavior is selected.[59]
  • Class Selector (CS) behavior, it provides a way to compatible support for the original ToS precedence subfield. If this behavior is selected, the value of the DS field is (b0b1b2000)2, where b0, b1 and b2 are the precedence bits respectively.
Table 1: Recommended codepoints for the AF Behavior (in binary)[60]
Drop precedence Class 1 Class 2 Class 3 Class 4
Low 001010 010010 011010 100010
Medium 001100 010100 011100 100100
High 001110 010110 011110 100110

Regarding bits 6 and 7 of the ToS, the two bits are used for the Explicit Congestion Notification (ECN), which was first described in 1999.[61] When set to (11)2, the two bits provide a mechanism for routers to notify the destination that congestion currently exists in the network. Three other combinations of the two bits can be used by the data source as follows: (00)2 to indicate that the mechanism is not used, and (10)2 or (01)2 to indicate the use of it.[62]

Addressing[edit | edit source]

IPv4 addressing is giving digital identifiers to IP hosts residing in a local area network or on the internet.[63] The digital identifier is called an IP address, it may be used to uniquely distinguish a specific host, or to identify members of a group each of which is hosting that address at the same time.[64]

Definitions[edit | edit source]

IPv4 address[edit | edit source]
A diagram of an IP address (IPv4).

It is a 32-bit digital identifier, normally written Dot-decimal notation. However, it might also be written using Binary numeral system. The IP address is divided into four parts, each of which is 8 bits long, thus, it is called an octet. The octet numeration started at one, and the first octet includes the Most Significant Bit (MSB) (Figure 9).[65]

When the dot-decimal notation is used, the IPv4 address follows the format: "#.#.#.#", where '#' represents a numerical value in the decimal numeral system. Because each octet is 8 bits long and contains only positive integers, the value in each octet varies between 0 and 255.[66] For example, 10.0.0.1, 172.16.254.1 and 240.0.0.9 are examples IPvs addresses written in the dot-decimal notation.

IPv4 addresses can be represented using dot-binary notation, this can be done by converting the value of each octet from the decimal numeral system into the binary. For example, 10.0.0.1 can also be written as follows: 00001010.00000000.00000000.00000001. Although an IPv4 address has two representation forms, the two can not be used together, thus, when written down, one notation must be used.

IPv4 address space[edit | edit source]

It is the set of all IP addresses. The space includes 232 addresses, approximately 4.3 billion. Based on how addresses are used, the IPv4 address space is divided into three sub-spaces as follows:

  • Unicast address space which occupis 7/8 of the IPv4 address space. It is used to uniquely identify IP hosts. During the lifetime of IPv4, assigning addresses from unicast space has been treated in two different ways:[64]
  • Classful addressing, which is the original method described in the IPv4 standard. However, it was later obsoleted due to the rapid exhaustion of IPv4 address space. When the classful method was used, an IPv4 unicast address had the following structure:[67]
IPv4 address structure used for unicast classful addressing.
The structure of IPv4 classes that are used for unicast addressing.
Table 2: Standard classes for IPv4 unicast addressing
Class 1st octet range Field's lengths
(bits)
Nspc Nadr
Binary Decimal
from to from to brsv bNID bHID
A 00000000 01111111 0 127 1 7 24 27 224
B 10000000 10111111 128 191 2 14 16 214 216
C 11000000 11011111 192 223 3 21 8 221 28
  • Reserved bits, which cover brsv bits. This field is used to define the function and the size of the addressing subspace to which the address belongs. The reserved bits field starts from the address's MSB and extends to cover at least one bit and up to 3 bits at most.[d]
  • Network identifier (NID), it is used to uniquely identify the subspace to which the address belongs. All addresses that reside in the same subspace have the same NID. Network identifier starts directly where the reserved bits ends, its length, referred to as bNID varies according to the number of resulted subspaces Nspc. The relationship between the two parameters can be mathematically written as follows: Nspc = 2bNID.
  • Host identifier (HID), which uniquely identifies the IPv4 host. The value of this field is unique inside each subspace. Host identifier starts directly where NID ends, its length, referred to as bHID varies according to the number of available addresses in the subspace Nadr. The relationship between the two parameters is written as follows: Nadr = 2bHID.[e]
Figure 10 shows the previously described structure highlighting that the sum of the parts' lengths is equal to the length of the IPv4 address, i.e., brsv+bNID+bHID=32.
In the classful addressing, the length of the network and host identifiers are fixed and standardized. Thus, the resulting volume of the subspaces is predetermined. These subspaces are defined as follows: (Figure 11)[69]
  • Class A, it has only one reserved bit that is set to (0)2 always. Based on this, the value of the first octet varies between 0 and 127. In class A, NID is 7 bits long, while HID is 24 bits, that is why there are only 27 = 128 Class A subspaces, each of which has 224 addresses (Table 2).
  • Class B, it has two reserved bits always set to (10)2. As a result, the value of the first octet is in-between 128 and 191. The length of the NID is 14 bits and the length of HID is 16 bits. There are 214 Class B subspaces, each contains 216 addresses.
  • Class C, with three reserved bits, always set to (110)2, which means that the value of the first octet ranges between 192 and 223. The length of the NID in it is 21 bits (221 subspaces) and the length of HID is 8 bits (28=256 subspaces).
IPv4 address structure used for unicast classless addressing.
IPv4 address subspaces.
  • Classless addressing, which is an addressing method where there are no classes nor specific predetermined volumes for the subspaces.[70][71] When classless addressing is used, the IPv4 address will have the following structure (Figure 11):[72]
  • A prefix, which is shared among all the addresses in the subspaces. It covers bprf bits starting from the address's MSB and has no predetermined length. Instead, it can extend longer in the address creating larger subspaces as needed.
  • An HID, which starts from the end of the prefix and covers all the remaining of the address.
Classless addressing requires a hierarchical addressing system,[73] which means that the address space, independently but subsequently, is being divided into smaller subspaces. At each level of the hierarchy, the prefix length increases at the expense of HID. The classless addressing was adopted in 1993 as a short-to-mid term solution for the exhaustionIPv4 address space.[74]
  • Multicast address space, also known as Class D. It is used to uniqulily numbering groups of hosts. Class D includes all the addresses that starts with (1110)2, i.e., the range of the first octet extends from 224 to 239 included, occupiing 1/16 of the IPv4 address space.[75]
  • A reserved address space, usually refer to as Class E. It is reserved for experimental use. Class E covers 1/16 of the IPv4 space volume including all the addresses that starts with (1111)2, The number of reserved bits are 4 and its value is (1111)2.[76]

Figure 13 shows previously discussed IPv4 address subspaces and their relative volumes to the original space. Note that the figure adopts the classful address method when handling the unicast subspace, thus, it also shows the relative volumes of classes: A, B and C.

Because IPv4 addresses are binary-based numbers, all the previously mentioned subspaces must always include a number of addresses that is multiple of 2, i.e., the number of addresses with the subspaces is a member of the set {2,4,8,16,...,232}.[68]

Network mask[edit | edit source]
Table 3: Network masks used with classful addressing
Class Mask notation
Dotted-
decimal
Prefix
A 255.0.0.0 /8
B 255.255.0.0 /16
C 255.255.255.0 /24

It is a 32-bit number associated with the network unicast addresses. A network mask does have the same 4-octet structure as the network address and is written using the same notation systems.[77] However, the mask has a special one-and-zero pattern: starting from its MSB, the mask includes only a sequence of ones, followed by a sequence of zeros, and the sum of the lengths of the two sequences is 32 bits. In both classful and classless addressing, the mask is used to detect the HID field of the corresponding network address. To do so, the bits in the mask section that corresponds to the HID field are always set to zeros, while the rest of the mask is set to ones.[78]

For example, a network address that belongs to a Class C subspace has 8 bits located in its fourth octet. The network mask that corresponds to this address is 1111 1111 . 1111 1111 . 1111 1111 . 0000 0000. To avoid writing long sequences of ones and zeros, and making use of the mask special pattern, the mask can be written as follows: /x, where x is the number of ones in the mask, this writing system is called the prefix notation.[79] For example, the previous network mask can shortly be written: /24, and that is the standard mask for all Class C subspaces. Table 2 shows the standard mask for unicast address subspaces when the classful addressing method is used.[f]

Address space managment[edit | edit source]

Allocation[edit | edit source]
The hierarchy of the unicast IP address allocation space in IPv4.

The Internet needs a central authority to allocate and assign digital identifiers and to keep a reservation record. Since the beginning of the network, IANA, managed by the Information Sciences Institute in California, has provided these services.[81] However, starting from March 2000, the Internet Corporation for Assigned Names and Numbers (ICANN), took control of IANA and started managing allocation services.[82]

IANA maintains global registers for both unicast and multicast subspaces, as follows:

  • Unicast subspaces allocation: following the classless addressing approach, the process is provided based on a four-level hierarchical model shown in Figure 14:[83]
  1. IANA, residing at the top of the pyramid, provides the allocation service for a number of Regional Internet Registries (RIRs) based on geographical bases.
  2. RIRs, serves the Local Internet Registers (LIRs), providing them with smaller subspaces, based on their needs.
  3. LIRs assign subspaces to local internet sub-registers or to agents directly.
  4. Local internet sub-registers assign subspaces to agents where subnetting and VLSM are used to locally manage the provided subspace.
Note that allocation is distinguishable from the assignment in this context: while allocation is providing Internet Service Providers (ISPs) with IPv4 subspace addresses, assignment is giving subspaces on a customer base.[84] In addition to that, going down in the pyramid shown in Figure 14, the allocated/assigned subspaces will have longer prefixes and will, as a result, cover smaller volumes.[85]
At top of the allocation model, IANA follows a three principles policy:[86]
  1. IANA allocates RIRs subspaces distinguished with prefix /8.
  2. IANA is committed to allocating RIRs with subspaces that satisfy their future needs for at least 18 months.
  3. IANA allows the RIRs to adopt their own allocation strategies and to keep their own reservation records.
Some subspaces, usually referred to as blocks of addresses, are reserved addresses for specific protocols, or for special purposes.[87] In general, addresses from these subspaces should not be used to number hosts globally on the Internet. For example, 127.0.0.0/8 is reserved for the loopback function.[88] IANA maintains a regestary for these blocks of addresses.[89]
  • Multicast subspaces allocation: IANA is charged with the process of multicast subspace allocation, it allocates and assigns blocks of multicast addresses directly to newly developed protocols.[90] Additionally, IANA maintains the IPv4 multicast space registry.[91]
Subnetting and VLSM[edit | edit source]
Subnetting concept when used with classful addressing.

Subnetting is a mathematical operation used to logically divide an IPv4 unicast address space into a number of smaller subspaces called subnets, it can be used with both classful and classless addressing. Figure 15 shows how subnetting was being performed with the classful addressing approach. To subnet a classful subspace, a new field, called Subnet identifier (SID) is created in between NID and HID, it grows right to occupies one or more bits from HID, the number of SID bits (bSID) determines how many subnets (Nsubnet) will result after performing the operation, the two are bonded together in the following formula: Nsubnet = 2bSID.[92][93] On the other hand, when the classless addressing method is used, the SID is created between the prefix and the HID following the same approach.[94]

Volumes comparison for subspaces resulted from subnetting a class C subspace. To the right: single-level subnetting, and to the left multi-level subnetting.

The previous approach is called single-Level subnetting, when used, equal-volumed subspaces will be created. If the subnetting algorithm is reperformed on one of the resulted subspaces, new and smaller subspaces will be created, and this approach is called multi-level subnetting. The result of the multi-level approach will be subnets that have different volumes and are distinguished with different masks.[95] Variable Length Subnet Mask (VLSM) is a special type of multi-level subnetting that is performed on single classful address space. As shown in Figure 16, when compared to single-level subnetting, VLSM allows network administrators to effectivly manage their assigned subspaces based on the need.[96]

When creating new unicast addresses subspaces, two special addresses need to be considered in each subnet: the network and the broadcast, that is because they are the two extremities of the address range. The network address is the smallest address in the subspace and corresponds to all-zero HID, it is used to represent the address subspace in total. The broadcast address is the largest address in the subspace and corresponds to all-ones HID, it is used as a destination address to send packets to all hosts numbered using the addresses from the corresponding subspace. Both, the network and the broadcast addresses, should not be used to number hosts.[97]

Fragmentation and reassembly[edit | edit source]

A fragmentation example of in IPv4 packet into smaller fragments.

The internet was originally developed as a network connecting the various networks which may support various maximum sizes of data packets. The problem of supporting different maximum sizes appear since the beginning of the internet, and the suggested solution is fragmentation and reassembly. At the beginning, the router fragment the data packet that it cannot transmit over the destination network and the results data packet called (fragments). The reassembly (defragmentation) happened in the final destination,[98] where the original packet is reassembled from fragments.[29]

Fragmentation[edit | edit source]

IPv4 packets fragmentation algorithm.

When a network layer entity running IPv4 receives a data packet destined to be sent to through a port, it determines the value of the maximum transport unit in the network associated with that port, then compares the size of the packet with the largest value of the transport unit. The packet must be fragmented into smaller pieces, each of which is part of a new independent data packet. Segmentation occurs in the fourth version of the Internet protocol at the source of the data packet and at any intermediate node that handles the packet along its path from its source to its destination, and the data can be fragmented more than once to produce smaller pieces if the need arises. When the entity of network layer ,which runs internet protocol version 4, a data packet destined to send through one of its ports, it determines the value of the maximum transport unit in the network associated with that port. If the data packet size was larger than the size of transport unit. The packet must be fragmented into smaller fragments, each of which is part of a new independent data packet. The fragmentation occurs in the fourth version of internet protocol at the source of the packet or in any intermediate node that handles the packet along its path from its source to its destination, and the data can be fragmented more than once to produce smaller pieces if needed. [99] The fragmentation algorithm described in the specification of IPv4, and it follows these steps: [100]

  1. Determine the length of the packet and compare it with the value of the maximum transport unit of the network to which the packet will be directed to:
    1. If the length of the package is larger, then fragmentation of the package is necessary, otherwise,
    2. The package is sent as it is to the next stage of packaging. The algorithm has finished.
  2. If the non fragmentation flag in the packet is raised, the router disposed the packet. The algorithm has expired. Otherwise,
  3. The payload size of the fragment is determined according to the maximum transport unit and the length of the IP header.
  4. A part of the load of the original package is deducted to be the load of the fragment.
  5. The packet header is built, and this includes:
    1. Calculating the length of the fragment header and add it to the custom field.
    2. Calculate the total segment length and add it to the custom field.
    3. Determine the life time of the fragment.
    4. Set the fragment ID value to the parent package ID value.
    5. Determine the offset value, and add it to the custom field.
    6. Determining the value of the two flags: non-fragmentation and more fragments. And adding their values ​​to the custom field.
    7. Calculate the value of the Collective Verification field.
  6. Generating the new packet by encapsulating the payload of the data fragment in the header.
  7. Send the packet to the next stage of packaging.
  8. Determine whether the previous packet is the last packet through the value of the more segments flag.
  9. If the resulting packet is the last packet, the algorithm expires. Otherwise,
  10. The algorithm will be re-implement starting from the third step, considering that the load size of the new parent packet is the size remaining after the truncation process in the fourth step.

Reassembly[edit | edit source]

The reassembly algorithm in IPv4.

It is the process of recreating the original data packet from the set of segments resulting from the fragmentation process.[101] In the fourth version of the Internet protocol, reassembly is only made at the final destination of the packet, because the different segments resulting from the same fragmentation may take different paths after being directed, and these paths may meet only at the final destination.[102] The reassembly algorithm is described in the protocol specifiers, and it follows the following steps: [103]

  1. Receiving the data packet, and determining whether it is a segment of a larger packet or not.
  2. If it is not, the packet is sent to the next stage of processing. The algorithm has expired. Otherwise
  3. If it is, start the reassembly process and set the value of the hold timer:
    1. Determine the payload and the header in the receiving segment
    2. Determine the relative segment position in relation to the parent packet
      1. If it was the first segment, then it will added to the first section of the packet, otherwise
      2. If it was the last segment, it will be added to the last section of the packet.
      3. The segments were added relatively to their positions.
  4. Determine whether the process of reassembly the original packet load has ended.
    1. If the process has finished, the original packet header is created, then the original packet is returned, and sent to the next stage of processing. The algorithm has expired. Otherwise,
    2. If the process has not been completed, a check is performed for a new data packet containing the same identifier value.
      1. If received, proceed to step (2) of this algorithm, otherwise,
      2. If no answer is received, it will wait until the value of the timer runs out, and periodically check for the arrival of a data packet (if received, the previous step is taken).
      3. If the timer runs out, get rid of stored parts and free up memory. The algorithm has expired. Otherwise,
      4. Repeat step (4.2)

Multiplexing[edit | edit source]

IPv4 performs this function by relying on the protocol field in its header. This field includes a value that specifies the following protocol in the packaging process, which will be the delivery of the package to its entity, which may be:

  • Another network layer protocol that performs a different function, towards the Internet control message protocol, or the enhanced internal routing protocol between gateways.
  • A transport layer protocol, towards a transport control protocol or a user data packet protocol.

IANA defines the encoding values used in this field and the corresponding protocols, and since the field length is only 8 bits, there are only 256 values available.

Source Routing[edit | edit source]

IPv4 provides this functionality by using option fields in its header. When it comes to directing by source, there are two options:

  • Routing option which is not restricted by source path, that is option type 131, where the data packet source obligates the processing routers of it to send it via specific path cannot be changed.
  • The routing option restricted by the source path, which is the option of type 137, in which the source of the packet proposes to the routers that address it a non-binding path to transport it from its source to its destination.

Problems[edit | edit source]

Related to addressing[edit | edit source]

Address space exhaustion[edit | edit source]

Exhaustion addressing space of internet protocol version 4 is the depletion of free addresses in IPv4 address space after allocating them to service providers and hosts on the Internet. This problem was noticed in the early nineties of the twentieth century with the expansion of the Internet, and work began to find solutions to it since that time. The address exhaustion problem was addressed through two strategies, the first was short-term, aimed at reducing the speed of depletion of address space and extending the life of the IPv4 to the maximum possible time, and the second long-term, aimed at finding an alternative to the fourth version with only a limited address space (of around 4.3 billion just) with a networking protocol supports larger addressing space. The short-term strategy helped in a way to extend the life of the fourth version of the Internet Protocol to more than a quarter of a century after what was expected is only 3-5 years, but the depletion of the address space continued, albeit at a slower pace. In February 2011, the Internet Corporation for Assigned Names and Numbers, known for short as ICANN, issued a press release in which it reported that the last unassigned address space had begun to be consumed with a prefix of length /8.

IP address spaces overlap[edit | edit source]

Internet protocols address spaces overlapped when there are a common group of similar addresses between two or more spaces, and this caused y the incorrect use of the masks of differential lengths. When and as a result, two hosts can get the same address but each address has a different mask, which leads to a problem in routing the data packets, so the address priority should not overlap when the addressing process is completed. This problem can be overcome by designing the network precisely so that the addressing is accomplished when masks of different length are used without overlapping partial preference, and this is achieved by specifying the identifiers of each subspace and the address field that extends over it, and avoiding the existence of a common domain between any two spaces used in Addressing.

Related to fragmentation[edit | edit source]

Some attackers took advantage of the mandatory fragmentation process in IPv4 hosts to launch various attacks on data networks, including the following:

  • Segment attack: A digital attack that occurs by sending a malicious packet of small-sized data to pass through the firewall as a hacked segment. This attack is based on the fact that the smallest data packet that any unit supporting IPv4 can handle is 68 bytes long, and in it the IP header has the maximum length allowed, which is 60 bytes, while the payload is only 8 bytes. This length is not sufficient to include the transport protocol header in the packet, and it passes through the firewall without verifying it, because it usually checks the port numbers in the transport layer.
  • Overlap segments attack: It is a digital attack that depends on the presence of a loophole in the algorithm used when reassembling the original package, whereby any subsequent segment can overlap with another previous segment, and partially or completely replace it. This means that the first segment, which contains the header, can be passed Internet protocol from the firewall legally, then manipulating its value by the method of overlaying with a next segment to be shown later.
  • Problems related to the address translation protocol: These problems are related to the way the address translation protocol is implemented. When a data packet is fragmented, are the protocol messages sent for each segment? or is it sufficient to send only for the original package? In addition, in the event that protocol messages are sent for each segment, reassemble the packet depends on the success of all the segments in reaching the final destination, and if one of them fails for reasons related to the address translation protocol properties, then reassembling the packet will not be possible, and the received segments will be disposed out at the destination. .

Auxiliary protocols[edit | edit source]

It is a stack of protocols depends on another protocols to do its functionality. This section will give an overview for auxiliary protocols

Address Resolution Protocol[edit | edit source]

In interconnection model for the open systems, address association protocols are a family of protocols that do matching addresses between the networking protocol operating at the network layer and the link protocol in the link layer interchangeably. [104] It includes a number of protocols, including:

  • Address Resolution Protocol (ARP): It is used to discover the link protocol address associated with the IP address of a remote host, and this matching is an essential function in making an IP package. The protocol was developed in 1982 and described in RFC 826.[105]
  • Inverse Address Resolution Protocol (InARP): It is an address association protocol that is used to discover the address of the networking protocol associated with the address of the link protocol in a remote host, meaning that its work is opposite to the work of the address translation protocol.[106]
  • Reverse Address Resolution Protocol (RARP): It is an address association protocol that is used to discover the address of the networking protocol associated with the address of the link protocol in the node that operates it, meaning that its work is identical to the work of the reverse address association protocol, but it works in the same node not over the network, the protocol was developed in 1984 AD and described in the RFC 903.[107]

Internet Control Message Protocol[edit | edit source]

Internet Control Message Protocol (ICMP): It is a connection protocol and an integrated part of IPv4. ICMP is used by IPv4 hosts to define a mechanism for data packet destination to communicate with its source and provide it with different pieces of information about the network status or packet processing. ICMP developed in 1981 and described in RFC 792,[108] it defines in its standards 11 messages, used to send reports to packet source about network, like timestamps to detect the delay time, or related to packet like the current packet situation. These messages are echo and its reply, redirect, destination unreachable, timestamp and its reply, parameter problem, and Information request message and its reply.[109] Later, The RFC defined additional messages which are:

A new edition of the protocol has accomplished in 1995, compatible with IPv6 and called Internet Control Protocol for the Internet Protocol version 6 (ICMPv6) and described in RFC 1885.[113]

Internet Group Management Protocol[edit | edit source]

It is a communication protocol that works at the network layer, that manages the private sets for group broadcasting of IPv4 packets, and determines how hosts join groups and how to leave them automatically, meaning that it allows any host to join or leave the group at any time he wants. [114][115] In addition, the protocol does not add restrictions on the number of group members nor on their sites, and it also allows one host to join more than one group at the same time. The internet engineering task force have developed three versions of the Internet Groups Management Protocol, the first of which came in 1989 AD, and it is described in the document RFC 1112,[116] which specifies the mechanisms for the host to join or leave a group. As for the second version, developed in 1997, it was described in RFC 2236,[117] and it contained many amendments, the most important of which was allowing the host to request the departure of a specific group. As for the third version, it was developed in 2002, and it is described in RFC 3376,[118] and it supports many additional features, the most important of which supports source-specific multicast feature. [119]

Internet Protocol Security[edit | edit source]

Internet Protocol Security (IPSec): it is a Protocol suit, which are used to provide privacy services and authentication in the network layer. IPSec is used to make a connection between gateways (Gateway-to-Gateway) or between host and gateway (Host-to-Gateway) or between hosts (Host-to-Host). It is used in IPv4, IPv6 and other internetworking protocols.[120]

IPSec is an open standard, these protocols are divided into 3 types: [121]

  • Authentication Headers (AH): it is used for Data integrity and checking its source.[122]
  • Encapsulating Security Payload (ESP): it is used for data confidentiality and protects it from reply attacks.[123]
  • Security Association (SA): it is a set of protocols and parameters used from the previous protocols.[124]

IP Security Working Group had been established as a part of the Internet Engineering Task Force in 1993.[125] With an aim to unify the efforts made by multiple research institutions, foremost of which is the United stated Naval Research Laboratory (USNRL), and to set a standard for security services provided in the network layer. This group had published three Requests for Comments in 1995.[126][127][128]That was the first steps before publishing dozens of RFCs and standards in the following years. [129] Until it obsoleted in 2005.[125]

Notes[edit | edit source]

  1. For TCP, refer to RFC 793 [5]
  2. The counting of the versions started from zero (0), i.e., the first version has the count value set to 0.
  3. Based on the IENs, numbers 2 and 3 were never used as indexes for IP versions, the version counter has been turned from 1 to 4 directly.[10]
  4. In the original protocol standard reserved bits was part of network identifiers,[64] but they were always excluded from the mathematical calculations related to the identifiers and treated as a separate part of the IPv4 address.[68]
  5. A distinction must be made between the number of addresses in a subspace, calculated using 2bHID, and the number of addresses available for numbering hosts, which is calculated using 2bHID - 2, where the two subtracted addresses are the network address and the broadcast addresses, which are served in every subspace and must not be used to numbering hosts.
  6. Refer RFC 1878 for all possible masks when the classless addressing method is used.[80]

Additional information[edit | edit source]

Author contributions[edit | edit source]

Acknowledgements[edit | edit source]

Competing interests[edit | edit source]

Funding[edit | edit source]

Ethics statement[edit | edit source]

References[edit | edit source]

  1. Baran, Paul (1964). "RAND Memorandum RM-3420-PR - On Distributed communications: I. introduction to distributed communications networks" (PDF). rand.org. Archived from the original (PDF) on 19 January 2019. Retrieved 14 December 2020.
  2. Pouzin, Louis (1973). "Presentation and major design aspects of the CYCLADES computer network". DATACOMM '73 Proceedings of the third ACM symposium on Data communications and Data networks: Analysis and design (ACM): 80-87. doi:10.1145/800280.811034. 
  3. TCP/IP Illustrated Volume 1, P.5
  4. Cerf, V.; Khan (May 1974). "A Protocol for Packet Network Intercommunication". IEEE Transactions on Communications (IEEE) 22 (5): 637-648. doi:10.1109/TCOM.1974.1092259. ISSN 1558-0857. 
  5. Postal, J. (September 1981). "RFC 793, Transmission control protocol, DARPA internet program,protocol specification". The Internet Society. doi:10.17487/RFC0793. Archived from the original on 18 September 2019. Retrieved 16 December 2020.
  6. Cerf, V.; Dalal, Y.; Sunshine, C. (December 1974). "RFC 675, SPECIFICATION OF INTERNET TRANSMISSION CONTROL PROGRAM". The Internet Society. doi:10.17487/RFC0675. Archived from the original on 31 December 2019. Retrieved 16 December 2020.
  7. Postel, Jon (15 August 1977). "IEN 2, 2.3.3.2 Comments on Internet Protocol and TCP". rfc-editor. Archived from the original on 8 January 2019. Retrieved 18 December 2020.
  8. Cerf, Vint (14 February 1978). "IEN 26, 2.3.2.1 A Proposed New Internet Header Format" (PDF). rfc-editor. Archived from the original on 16 May 2019. Retrieved 16 December 2020.
  9. Postel, Jonathan (February 1978). "IEN 28, Draft Internetwork Protocol Description Version 2" (PDF). rfc-editor. Archived from the original (PDF) on 16 May 2019. Retrieved 16 December 2020.
  10. "Version Numbers". IANA. Archived from the original on 18 January 2019. Retrieved 16 December 2020.
  11. Postel, Jonathan (June 1978). "IEN 41, Internetwork protocol specification version 4" (PDF). rfc-editor. Archived from the original (PDF) on 16 May 2019. Retrieved 16 December 2020.
  12. Postel, Jonathan (June 1978). "IEN 44, LATEST HEADER FORMAT" (PDF). rfc-editor. Archived from the original (PDF) on 16 May 2019. Retrieved 16 December 2020.
  13. Postel, Jonathan (September 1978). "IEN 54, INTERNETWORK PROTOCOL SPECEFICATION VERSION 4" (PDF). rfc-editor. Archived from the original (PDF) on 16 May 2019. Retrieved 16 December 2020.
  14. Postel, J. (January 1980). "RFC 760, DOD STANDARD INTERNET PROTOCOL". The Internet Society. doi:10.17487/RFC0760. Archived from the original on 16 October 2019. Retrieved 19 December 2020.
  15. Postel, J. (November 1981). "RFC 801, NCP/TCP TRANSITION PLAN". The Internet Society. p. 2. doi:10.17487/RFC0801. Archived from the original on 11 December 2019. Retrieved 19 December 2020.
  16. Nesser, P.; Bergstrom, A. (June 2004). "RFC 3789, Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents". The Internet Society. p. 2. doi:10.17487/RFC3789. Archived from the original on 11 December 2019. Retrieved 19 December 2020.
  17. Delgrossi, L.; Berger, L. (August 1995). "RFC 1819, Internet Stream Protocol Version 2 (ST2), Protocol Specification - Version ST2+". The Internet Society. doi:10.17487/RFC1819. Archived from the original on 2019-12-19. Retrieved 19 December 2020.
  18. Ullmann, R. (June 1993). "RFC 1475 , TP/IX: The Next Internet". The Internet Society. p. 7. doi:10.17487/RFC1475. Archived from the original on 2020-01-09. Retrieved 19 December 2020.
  19. Deering, S.; Hinden, R. (December 1995). "RFC 1883, Internet Protocol, Version 6 (IPv6) Specification". The Internet Society. doi:10.17487/RFC1883. Archived from the original on 2019-12-21. Retrieved 19 December 2020.
  20. Deering, S.; Hinden, R. (December 1998). "RFC 2460, Internet Protocol, Version 6 (IPv6) Specification". The Internet Society. doi:10.17487/RFC2460. Archived from the original on 2020-01-07. Retrieved 19 December 2020.
  21. Deering, S.; Hinden, R. (July 2017). "RFC 8200, Internet Protocol, Version 6 (IPv6) Specification". The Internet Society. doi:10.17487/RFC8200. Archived from the original on 2019-12-11. Retrieved 19 December 2020.
  22. Onions, J. (April 1994). "RFC 1606, A Historical Perspective On The Usage Of IP Version 9". The Internet Society. Archived from the original on 2019-08-11. Retrieved 19 December 2020.
  23. RFC 791, 5-6
  24. RFC 1180, P. 3
  25. RFC 791, P.1
  26. IEN 48, P.1
  27. Callon, Ross (1983). "Internetwork protocol". Proceedings of the IEEE (IEEE) 71 (12): 1388-1393. doi:10.1109/PROC.1983.12783. https://ieeexplore.ieee.org/abstract/document/1457051?casa_token=qiB6MtgcIPgAAAAA:bUfrycf0edEqKAsVPLPE7JGI90B5AoHe4hZK3DEgJXlqrokMdlMpr8aJvSCH166obL-SUq80_qE. 
  28. Lee, Donald (1999). Enhanced IP Services for Cisco Networks (in en) (first ed.). Cisco Press. p. 26. ISBN 1578701066. 
  29. 29.0 29.1 RFC 791, P.8
  30. RFC 1180, P.3-4
  31. RFC 791, P.18-19
  32. TCP/IP Foundations, P.86
  33. Droms, R. (March 1997). "RFC 2131, Dynamic Host Configuration Protocol". The Internet Society. doi:10.17487/RFC2131. Archived from the original on 15 November 2018. Retrieved 30 December 2020.
  34. RFC 791, P.9
  35. TCP/IP illustrated, P.181
  36. RFC 791, P.1
  37. RFC 791, P.13
  38. RFC 791, P.11
  39. RFC 791, P.11-14
  40. Almquist, P. (June 1992). "RFC 1349, Type of Service in the Internet Protocol Suite". The Internet Society. doi:10.17487/RFC1349. Archived from the original on 22 October 2019. Retrieved 30 December 2020.
  41. Nichols, K.; Blake, S.; Baker, F.; Black, D. (December 1998). "RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers". The Internet Society. doi:10.17487/RFC2474. Archived from the original on 6 January 2020. Retrieved 30 December 2020.
  42. RFC 6864
  43. Toni Janevski (2015). Internet Technologies for Fixed and Mobile Networks (in en) (1 ed.). Artech House. pp. 33. ISBN 9781608079216. 
  44. "Service Name and Transport Protocol Port Number Registry". IANA. Archived from the original on 22 September 2019. Retrieved 20 January 2021.
  45. RFC 791, P.14
  46. RFC 791, P.15
  47. TCP/IP Illustrated , P.192
  48. "Internet Protocol Version 4 (IPv4) Parameters - IP Option Numbers". IANA. Archived from the original on 24 November 2019. Retrieved 26 June 2019.
  49. RFC 791, P.16-17
  50. TCP/IP Illustrated , P.192-194
  51. RFC 791, P.12-13
  52. RFC 2474, P.1-2
  53. RFC 2475, P.1
  54. RFC 2474, P.7
  55. RFC 2475, P.12
  56. RFC 2474, P.6
  57. RFC 4594, P. 9-11
  58. RFC 3246, P. 5
  59. RFC 2597, P.6
  60. RFC 2597, P.6
  61. RFC 2481
  62. RFC 3168, P.7
  63. Dictionary of Networking, P.199
  64. 64.0 64.1 64.2 RFC 791, P.7
  65. TCP/IP Foundations, P.76
  66. Main, A. (23 February 2005). "Textual Representation of IPv4 and IPv6 Addresses". The Internet Society. p. 3-4. Archived from the original on 29 September 2019. Retrieved 30 January 2021.
  67. Reynolds, J.; Postel, J. (November 1986). "RFC 990, ASSIGNED NUMBERS". The Internet Society. p. 4. doi:10.17487/RFC0990. Archived from the original on 11 December 2019. Retrieved 30 January 2021.
  68. 68.0 68.1 RFC 1878, P.2
  69. RFC 791, P.7
  70. RFC 1518, P.1-5
  71. RFC 1519, P.2-10
  72. The TCP/IP Guide, P.359
  73. RFC 7020, P. 3
  74. RFC 1338, P.2
  75. Deering, S. (August 1989). "RFC 1112, Host Extensions for IP Multicasting". The Internet Society. p. 3. doi:10.17487/RFC1112. Archived from the original on 2020-02-03. Retrieved 10 January 2021.
  76. Deering, S. E. (July 1986). "RFC 988, Host Extensions for IP Multicasting". The Internet Society. p. 3. doi:10.17487/RFC0988. Archived from the original on 2019-12-11. Retrieved 4 September 2020.
  77. Dictionary of Networking, P.365
  78. RFC 1878, P.3-6
  79. RFC RFC 4632, P.5
  80. RFC 1878, P.2
  81. Cerf, V. (August 1990). "RFC 1174, IAB Recommended Policy on Distributing Internet Identifier Assignment and IAB Recommended Policy Change to Internet "Connected" Status". The Internet Society. p. 2. doi:10.17487/RFC1174. Archived from the original on 8 November 2019. Retrieved 22 January 2020.
  82. Carpenter, B.; Baker, F.; Roberts, M. (June 2000). "RFC 2860, Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority". The Internet Society. doi:10.17487/RFC2860. Archived from the original on 11 August 2012. Retrieved 2 January 2019.
  83. "Internet Assigned Numbers Authority (IANA) Policy For Allocation of IPv4 Blocks to Regional Internet Registries". ICANN.org. p. 3-5. Archived from the original on 6 November 2020. Retrieved 1 January 2020.
  84. Hubbard, K.; Kosters, M.; Conrad, D.; Karrenberg, D.; Postel, J. (November 1996). "RFC 2050, INTERNET REGISTRY IP ALLOCATION GUIDELINES". The Internet Society. p. 4. doi:10.17487/RFC2050. Archived from the original on 11 December 2019. Retrieved 22 January 2020.
  85. RFC 7020, P.3
  86. "Internet Assigned Numbers Authority (IANA) Policy For Allocation of IPv4 Blocks to Regional Internet Registries". ICANN.org. Archived from the original on 6 November 2020. Retrieved 1 January 2020.
  87. RFC 6890, P.1
  88. RFC 6890, P.7
  89. "IANA IPv4 Special-Purpose Address Registry". IANA.org. Archived from the original on 8 June 2021. Retrieved 10 June 2021.
  90. RFC 5771, P.2-3
  91. "IPv4 Multicast Address Space Registry". IANA. Archived from the original on 6 February 2019. Retrieved 14 September 2020.
  92. RFC 950, P.5
  93. Dictionary of Networking, P.365
  94. RFC 1878, P. 3-6
  95. The TCP/IP Guide, P.294-296
  96. TCP/IP Illustrated Volume 1, P. 41-42
  97. RFC 919, P. 5-6
  98. Huston, Geoff (29 January 2016). "Evaluating IPv4 and IPv6 Packet Fragmentation". Réseaux IP Européens Network Coordination Centre RIPE NCC. Archived from the original on 25 April 2018.
  99. TCP/IP Illustrated Volume 1, P.488
  100. RFC 791, P.26
  101. The TCP/IP Guide, P.347-348
  102. TCP/IP Illustrated , P.388
  103. RFC 791, P.28
  104. . The TCP/IP Guide, P.204-206
  105. C. Plummer, David (November 1982). "RFC 826, An Ethernet Address Resolution Protocol or Converting Network Protocol Addresses to 48.bit Ethernet Addres for Transmission on Ethernet Hardware". The internet Society. p. 1. doi:10.17487/RFC0826. Archived from the original on 19 February 2020.
  106. Bradley, T.; Brown, C.; Malis, A. (1992). "RFC 1293, Inverse Address Resolution Protocol". The internet Society. p. 1. doi:10.17487/RFC1293. Archived from the original on 2 January 2020.
  107. Finlayson, Ross; Timothy, Mann; Mogul, Jeffrey; Theimer, Marvin (1984). "RFC 903, A Reverse Address Resolution Protocol". The internet Society. p. 1. doi:10.17487/RFC0903. Archived from the original on 2 January 2020.
  108. RFC 792, P.1
  109. RFC 792, P.20
  110. RFC 950, P.10
  111. Deering, S. (September 1991). "RFC 1256, ICMP Router Discovery Messages". The internet Society. p. 1. doi:10.17487/RFC1256. Archived from the original on 18 December 2019. Retrieved 28 September 2020.
  112. Malkin, G. (January 1993). "RFC 1393, Traceroute Using an IP Option". The internet Society. p. 1. doi:10.17487/RFC1393. Archived from the original on 2 January 2020. Retrieved 28 September 2020.
  113. Conta, A. (December 1995). "RFC 1885, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification". The internet Society. p. 1. doi:10.17487/RFC1885. Archived from the original on 16 December 2019. Retrieved 15 September 2020.
  114. TCP/IP Illustrated Volume 1, P.435-436
  115. CCIE Routing and Switching Exam Certification Guide, P.281-284
  116. Deering, S. (August 1989). "RFC 1112, Host Extensions for IP Multicasting". The Internet Society. Archived from the original on 3 February 2020. Retrieved 1 June 2021.
  117. Fenner, W. (November 1997). "RFC 2236, Internet Group Management Protocol, Version 2". The Internet Society. Archived from the original on 21 October 2020. Retrieved 18 February 2017.
  118. Cain, B.; Deering, S.; Kouvelas, I.; Fenner, B.; Thyagarajan, A. (October 2002). "RFC 3376, Internet Group Management Protocol, Version 3". The Internet Society. Archived from the original on 28 March 2019. Retrieved 1 June 2021.
  119. H. Holbrook, B. Cain (August 2006). "RFC 4607, Source-Specific Multicast for IP". The Internet Society. doi:10.17487/RFC4607. Archived from the original on 11 August 2012.
  120. Frankel, S.; Krishnan, S. (February 2011). "RFC 6071, IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap". p. 4. doi:10.17487/RFC6071. ISSN 2070-1721. Archived from the original on 25 December 2019. Retrieved 20 September 2020.
  121. Thayer, R.; Doraswamy, N. (November 1998). "RFC 2411, IP Security Document Roadmap". p. 1. doi:10.17487/RFC2411. Archived from the original on 11 December 2019. Retrieved 28 September 2020.
  122. Kent, S.; Atkinson, R. (November 1998). "RFC 2402, IP Authentication Header". p. 1. doi:10.17487/RFC2402. Archived from the original on 11 December 2019. Retrieved 28 September 2020.
  123. Kent, S.; Atkinson, R. (November 1998). "RFC 2406, IP Encapsulating Security Payload (ESP)". p. 1. doi:10.17487/RFC2406. Archived from the original on 18 December 2019. Retrieved 28 September 2019.
  124. Maughan, D.; Schertler, M.; Schneider, M.; Turner, J. (November 1998). "RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP)". p. 1. doi:10.17487/RFC2408. Archived from the original on 11 December 2019. Retrieved 28 September 2020.
  125. 125.0 125.1 "IP Security Protocol (ipsec) - Group History". IETF. Archived from the original on 13 September 2019. Retrieved 28 September 2019.
  126. Atkinson, R. (August 1995). "RFC 1825, Security Architecture for the Internet Protocol". p. 1. doi:10.17487/RFC1825. Archived from the original on 18 December 2019. Retrieved 28 September 2019.
  127. Atkinson, R. (August 1995). "RFC 1826, IP Authentication Header". p. 1. doi:10.17487/RFC1826. Archived from the original on 19 December 2019. Retrieved 28 September 2020.
  128. Atkinson, R. (August 1995). "RFC 1827, IP Encapsulating Security Payload (ESP)". p. 1. doi:10.17487/RFC1827. Archived from the original on 11 December 2019. Retrieved 28 September 2019.
  129. "IP Security Protocol (ipsec)". Archived from the original on 13 September 2019. Retrieved 28 September 2019.