Notes Itnm

Address Resolution ProtocolThe Address Resolution Protocol (ARP) is a computer networking protocol for determining a network host's Link Layer or hardware address when only its Internet Layer (IP) or Network Layer address is known. This function is critical in local area networking as well as for routing internetworking traffic across gateways (routers) based on IP addresses when the next-hop router must be determined.

Consider a LAN where machines using IPv4 over Ethernet wish to communicate. A sender wishes to send a message to some other machine on the LAN and knows a destination IPv4 address. The destination IPv4 address is hopefully associated with some appropriate network interface belonging to the recipient machine, and is present on the LAN. But in order for communication to succeed, the sending machine first needs to discover the ethernet MAC address of the intended recipient network interface. This requirement comes about because Ethernet hardware does not (necessarily) understand IPv4 protocols or IPv4 addresses in the sense that Ethernet hardware 'listens out for' relevant Ethernet MAC addresses but does not 'listen out for' IPv4 addresses. (An impractical alternative would be to have all units listen to every Ethernet packet and inspect the contents for relevant IPv4 addresses, discarding the packets that are intended for other devices, but this would be very inefficient.) So before sending an IPv4 packet, the sender sends a broadcast message onto the LAN using ARP in order to discover the Ethernet MAC address of some interface that is listening for that desired target IPv4 address. Some appropriate unit replies that it has a network interface with a certain MAC address that is associated with the IPv4 address in question. The original would-be sender now has the information needed and can go ahead and send its IPv4 packet to the destination inserting it into an Ethernet frame with the correct destination MAC address for the appropriate recipient. The sender's operating system also stores the newly discovered MAC address in a table ('caches' the result). This table of mappings from IPv4 addresses to MAC addresses is retained and consulted again and again, so the ARP discovery procedure only has to be performed one time, when a packet is sent to a 'new' destination IPv4 address. When a host goes down on a network, there is no message sent to inform the other hosts. They will continue to send messages to that MAC address and because Ethernet doesn't have guaranteed delivery, they will have no way of knowing that the address associated with that host is no longer correct. A timer is set when information is entered in to the ARP cache and it will be discarded when the time is up to prevent the storing of invalid information. A new ARP request will be sent to the stored MAC address to verify that it is in fact still connected.

Packet structure

The Address Resolution Protocol uses a simple message format that contains one address resolution request or response. The size of the ARP message depends on the upper layer and lower layer address sizes, which are given by the type of networking protocol (usually IPv4) in use and the type of hardware or virtual link layer that the upper layer protocol is running on. The message header specifies these types, as well as

the size of addresses of each. The message header is completed with the operation code for request (1) and reply (2). The payload of the packet consists of four addresses, the hardware and protocol address of the sender and receiver hosts.

The principal packet structure of ARP packets is shown in the following table which illustrates the case of IPv4 networks running on Ethernet. In this scenario, the packet has 48-bit fields for the sender hardware address (SHA) and target hardware address (THA), and 32-bit fields for the corresponding sender and target protocol addresses (SPA and TPA). Thus, the ARP packet size in this case is 28 bytes.

Hardware type (HTYPE)This field specifies the Link Layer protocol type. Example: Ethernet is 1.

Protocol type (PTYPE)This field specifies the upper layer protocol for which the ARP request is intended. For IPv4, this has the value 0x0800. The permitted PTYPE values share a numbering space with those for Ethertype

Hardware length (HLEN)Length (in octets) of a hardware address. Ethernet addresses size is 6.

Protocol length (PLEN)Length (in octets) of addresses used in the upper layer protocol. (The upper layer protocol specified in PTYPE.) IPv4 address size is 4.

Operation Specifies the operation that the sender is performing: 1 for request, 2 for reply.

Sender hardware address (SHA)Hardware (MAC) address of the sender.

Sender protocol address (SPA)Upper layer protocol address of the sender.

Target hardware address (THA)Hardware address of the intended receiver. This field is ignored in requests.

Target protocol address (TPA)Upper layer protocol address of the intended receiver.

ARP protocol parameter values have been standardized and are maintained by IAN A

(The Internet Assigned Numbers Authority (IANA) is the entity that oversees global IP address allocation, autonomous system number allocation, root zone management in the Domain Name System (DNS), media types, and other Internet Protocol-related symbols and numbers. IANA is operated by the Internet Corporation for Assigned Names and Numbers, also known as ICANN.)

ARP probeAn ARP probe is an ARP request constructed with an all-zero sender IP address. The term is used in the IPv4 Address Conflict Detection specification . Before beginning to use an IPv4 address (whether received from manual configuration, DHCP, or some other means), a host implementing this specification must test to see if the address is already in use, by broadcasting ARP probe packets.

ARP announcementsARP may also be used as a simple announcement protocol. This is useful for updating other hosts' mapping of a hardware address when the sender's IP address or MAC address has changed. Such an announcement, also called a gratuitous ARP message, is usually broadcast as an ARP request containing the sender's protocol address (SPA) in the target field (TPA=SPA), with the target hardware address (THA) set to zero. An alternative is to broadcast an ARP reply with the sender's hardware and protocol addresses (SHA and SPA) duplicated in the target fields (TPA=SPA, THA=SHA).

ARP mediationARP mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on multiple connected circuits, e.g., ATM on one end and Ethernet on the others.

Inverse ARP and Reverse ARP

Inverse Address Resolution Protocol (Inverse ARP or InARP) is used to obtain Network Layer addresses (for example, IP addresses) of other nodes from Data Link Layer (Layer 2) addresses. It is primarily used in Frame Relay (DLCI) and ATM networks, in which Layer 2 addresses of virtual circuits are sometimes obtained from Layer 2 signaling, and the corresponding Layer 3 addresses must be available before those virtual circuits can be used.

Since ARP translates Layer 3 addresses to Layer 2 addresses, InARP may be described as its inverse. In addition, InARP is implemented as a protocol extension to ARP: it uses the same packet format as ARP, but different operation codes

Reverse Address Resolution Protocol (Reverse ARP or RARP), like InARP, translates Layer 2 addresses to Layer 3 addresses. However, in InARP the requesting station queries the Layer 3 address of another node, whereas RARP is used to obtain the Layer 3 address of the requesting station itself for address configuration purposes. RARP is obsolete; it was replaced by BOOTP, which was later superseded by the Dynamic Host Configuration Protocol (DHCP).

Fig . Reverse Address Resolution Protocol

RARP (Reverse Address Resolution Protocol) is a protocol by which a physical machine in a local area network can request to learn its IP address from a gateway server's Address Resolution Protocol (ARP) table or cache. A network administrator creates a table in a local area network's gateway router that maps the physical machine (or Media Access Control - MAC address) addresses to corresponding Internet Protocol addresses. When a new machine is set up, its RARP client program requests from the RARP server on the router to be sent its IP address. Assuming that an entry has been set up in the router table, the RARP server will return the IP address to the machine which can store it for future use.

RARP is a separate protocol at the data-link level. For example, if the medium used is Ethernet, then RARP packets will have an Ethertype (still to be assigned) different from that of ARP. This recognizes that ARP and RARP are two fundamentally different operations, not supported equally by all hosts. The impact on existing systems is minimized; existing ARP servers will not be confused by RARP packets. It makes RARP a general facility that can be used for mapping hardware addresses to any higher level protocol address.

This approach provides the simplest implementation for RARP client hosts, but also provides the most difficulties for RARP server hosts. However, these difficulties should not be insurmountable.

RARP is available for Ethernet, Fiber Distributed-Data Interface, and Token Ring LANs. ARP (Address Resolution Protocol) performs the opposite function as the RARP: mapping of an IP address to a physical machine address.

8 16 32 bit

Hardware type Protocol typeHLen Plen

Operation

Sender Hardware Address

Sender Protocol Address

Target Hardware Address

Target Protocol Address

Fig. Header structure RARP

Hardware type

Type Description

1 Ethernet.

2 Experimental Ethernet.

3 Amateur Radio AX.25.

4 Proteon ProNET Token Ring.

5 Chaos.

6 IEEE 802.

7 ARCNET.

8 Hyperchannel.

9 Lanstar.

10 Autonet Short Address.

11 LocalTalk.

12 LocalNet (IBM PCNet or SYTEK LocalNET).

13 Ultra link.

14 SMDS.

15 Frame Relay.

16 ATM, Asynchronous Transmission Mode.

17 HDLC.

18 Fibre Channel.

19 ATM, Asynchronous Transmission Mode.

20 Serial Line.

21 ATM, Asynchronous Transmission Mode.

22 MIL-STD-188-220.

23 Metricom.

24 IEEE 1394.1995.

25 MAPOS.

26 Twinaxial.

27 EUI-64.

28 HIPARP.

Protocol type

Protocol Description

0x800 IP.

Hardware address length Length of the hardware address in bytes.

Protocol address length Length of the protocol address in bytes.

Operation The values are as follows:

Opcode Description

1 ARP request

2 ARP response

3 RARP request.

4 RARP response

5 Dynamic RARP request

6 Dynamic RARP reply

7 Dynamic RARP error

8 InARP request

9 InARP reply

Internet ProtocolThe Internet Protocol (IP) is the principal communications protocol used for relaying datagrams (packets) across an internetwork using the Internet Protocol Suite. Responsible for routing packets across network boundaries, it is the primary protocol that establishes the Internet.

IP is the primary protocol in the Internet Layer of the Internet Protocol Suite and has the task of delivering datagrams from the source host to the destination host solely based on their addresses. For this purpose, IP defines addressing methods and structures for datagram encapsulation.

Historically, IP was the connectionless datagram service in the original Transmission Control Program introduced by Vint Cerf and Bob Kahn in 1974, the other being the connection-oriented Transmission Control Protocol (TCP). The Internet Protocol Suite is therefore often referred to as TCP/IP.

The first major version of IP, now referred to as Internet Protocol Version 4 (IPv4) is the dominant protocol of the Internet, although the successor, Internet Protocol Version 6 (IPv6) is in active, growing deployment worldwide.

Services provided by IP

The Internet Protocol is responsible for addressing hosts and routing datagrams (packets) from a source host to the destination host across one or more IP networks. For this purpose the Internet Protocol defines an addressing system that has two functions. Addresses identify hosts and provide a logical location service. Each packet is tagged with a header that contains the meta-data for the purpose of delivery. This process of tagging is also called encapsulation.

IP is a connectionless protocol and does not need circuit setup prior to transmission

Reliability

The design principles of the Internet protocols assume that the network infrastructure is inherently unreliable at any single network element or transmission medium and that it is dynamic in terms of availability of links and nodes. No central monitoring or performance measurement facility exists that tracks or maintains the state of the network. For the benefit of reducing network complexity, the intelligence in the network is purposely mostly located in the end nodes of each data transmission, cf. end-to-end principle. Routers in the transmission path simply forward packets to the next known local gateway matching the routing prefix for the destination address.

As a consequence of this design, the Internet Protocol only provides best effort delivery and its service can also be characterized as unreliable. In network architectural language it is a connection-less protocol, in contrast to so-called connection-oriented modes of transmission. The lack of reliability allows any of the following fault events to occur:

data corruption lost data packets duplicate arrival out-of-order packet delivery; meaning, if packet 'A' is sent before packet 'B', packet 'B' may arrive

before packet 'A'. Since routing is dynamic and there is no memory in the network about the path of prior packets, it is possible that the first packet sent takes a longer path to its destination.

The only assistance that the Internet Protocol provides in Version 4 (IPv4) is to ensure that the IP packet header is error-free through computation of a checksum at the routing nodes. This has the side-effect of discarding packets with bad headers on the spot. In this case no notification is required to be sent to either end node, although a facility exists in the Internet Control Message Protocol (ICMP) to do so.

IPv6, on the other hand, has abandoned the use of IP header checksums for the benefit of rapid forwarding through routing elements in the network.

The resolution or correction of any of these reliability issues is the responsibility of an upper layer protocol. For example, to ensure in-order delivery the upper layer may have to cache data until it can be passed to the application.

In addition to issues of reliability, this dynamic nature and the diversity of the Internet and its components provide no guarantee that any particular path is actually capable of, or suitable for, performing the data transmission requested, even if the path is available and reliable. One of the technical constraints is the size of data packets allowed on a given link. An application must assure that it uses proper transmission characteristics. Some of this responsibility lies also in the upper layer protocols between application and IP. Facilities exist to examine the maximum transmission unit (MTU) size of the local link, as well as for the entire projected path to the destination when using IPv6. The IPv4 internetworking layer has the capability to automatically fragment the original datagram into smaller units for transmission. In this case, IP does provide re-ordering of fragments delivered out-of-order.[1]

Transmission Control Protocol (TCP) is an example of a protocol that will adjust its segment size to be smaller than the MTU. User Datagram Protocol (UDP) and Internet Control Message Protocol (ICMP) disregard MTU size thereby forcing IP to fragment oversized datagrams

IP addressing and routing

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

Version history

In May 1974, the Institute of Electrical and Electronic Engineers (IEEE) published a paper entitled "A Protocol for Packet Network Interconnection."[3] The paper's authors, Vint Cerf and Bob Kahn, described an internetworking protocol for sharing resources using packet-switching among the nodes. A central control component of this model was the "Transmission Control Program" (TCP) that incorporated both connection-oriented links and datagram services between hosts. The monolithic Transmission Control Program was later divided into a modular architecture consisting of the Transmission Control Protocol at the connection-oriented layer and the Internet Protocol at the internetworking (datagram) layer. The model became known informally as TCP/IP, although formally it was henceforth referenced as the Internet Protocol Suite.

The Internet Protocol is one of the determining elements that define the Internet. The dominant internetworking protocol in the Internet Layer in use today is IPv4; with number 4 assigned as the formal protocol version number carried in every IP datagram. IPv4 is described in RFC 791 (1981).

The successor to IPv4 is IPv6. Its most prominent modification from version 4 is the addressing system. IPv4 uses 32-bit addresses (c. 4 billion, or 4.3×109, addresses) while IPv6 uses 128-bit addresses (c. 340 undecillion, or 3.4×1038

addresses). Although adoption of IPv6 has been slow, as of June 2008, all United States government systems have demonstrated basic infrastructure support for IPv6 (if only at the backbone level).[4]

Version numbers 0 through 3 were development versions of IPv4 used between 1977 and 1979.[citation needed] Version number 5 was used by the Internet Stream Protocol, an experimental streaming protocol. Version numbers 6 through 9 were proposed for various protocol models designed to replace IPv4: SIPP (Simple Internet Protocol Plus, known now as IPv6), TP/IX (RFC 1475), PIP (RFC 1621) and TUBA (TCP and UDP with Bigger Addresses, RFC 1347). Version number 6 was eventually chosen as the official assignment for the successor Internet protocol, subsequently standardized as IPv6.

A humorous Request for Comments that made an IPv9 protocol center of its storyline was published on April 1, 1994 by the IETF.[5] It was intended as an April Fool's Day joke. Other protocol proposals named "IPv9" and "IPv8" have also briefly surfaced, though these came with little or no support from the wider industry and academia.

Fig. Internet Protocol Suite in operation between two hosts connected via two routers and the corresponding layers used at each hop

Sample encapsulation of application data from UDP to a Link protocol frame

IPv4Internet Protocol version 4 (IPv4) is the fourth revision in the development of the Internet Protocol (IP) and it is the first version of the protocol to be widely deployed. Together with IPv6, it is at the core of standards-based internetworking methods of the Internet. IPv4 is still by far the most widely deployed Internet Layer protocol. As of 2011, IPv6 deployment is still in its infancy.

IPv4 is described in IETF publication RFC 791 (September 1981), replacing an earlier definition (RFC 760, January 1980).

IPv4 is a connectionless protocol for use on packet-switched Link Layer networks (e.g., Ethernet). It operates on a best effort delivery model, in that it does not guarantee delivery, nor does it assure proper sequencing or avoidance of duplicate delivery. These aspects, including data integrity, are addressed by an upper layer transport protocol (e.g., Transmission Control Protocol).

IPv4 Header

Fig . IPv4 header

An IP packet consists of a header section and a data section.

Header

The IPv4 packet header consists of 14 fields, of which 13 are required. The 14th field is optional (red background in table) and aptly named: options. The fields in the header are packed with the most significant byte first (big endian), and for the diagram and discussion, the most significant bits are considered to come first (MSB 0 bit numbering). The most significant bit is numbered 0, so the version field is actually found in the four most significant bits of the first byte

Version The first header field in an IP packet is the four-bit version field. For IPv4, this has a value of 4 (hence the name IPv4).

Internet Header Length (IHL) The second field (4 bits) is the Internet Header Length (IHL) telling the number of 32-bit words in the header. Since an IPv4 header may contain a variable number of options, this field specifies the size of the header (this also coincides with the offset to the data). The minimum value for this field is

5 (RFC 791), which is a length of 5×32 = 160 bits = 20 bytes. Being a 4-bit value, the maximum length is 15 words (15×32 bits) or 480 bits = 60 bytes.

Differentiated Services Code Point (DSCP)Originally defined as the Type of Service field, this field is now defined by RFC 2474 for Differentiated services (DiffServ). New technologies are emerging that require real-time data streaming and therefore will make use of the DSCP field. An example is Voice over IP (VoIP) that is used for interactive data voice exchange.

Explicit Congestion Notification (ECN) Defined in RFC 3168 and allows end-to-end notification of network congestion without dropping packets. ECN is an optional feature that is only used when both endpoints support it and are willing to use it. It is only effective when supported by the underlying network.

Total Length This 16-bit field defines the entire datagram size, including header and data, in bytes. The minimum-length datagram is 20 bytes (20-byte header + 0 bytes data) and the maximum is 65,535 — the maximum value of a 16-bit word. The minimum size datagram that any host is required to be able to handle is 576 bytes, but most modern hosts handle much larger packets. Sometimes subnetworks impose further restrictions on the size, in which case datagrams must be fragmented. Fragmentation is handled in either the host or packet switch in IPv4 (see Fragmentation and reassembly).

Identification This field is an identification field and is primarily used for uniquely identifying fragments of an original IP datagram. Some experimental work has suggested using the ID field for other purposes, such as for adding packet-tracing information to datagrams in order to help trace back datagrams with spoofed source addresses.[5]

Flags A three-bit field follows and is used to control or identify fragments. They are (in order, from high order to low order):

bit 0: Reserved; must be zero.[note 1]

bit 1: Don't Fragment (DF) bit 2: More Fragments (MF)

If the DF flag is set and fragmentation is required to route the packet then the packet will be dropped. This can be used when sending packets to a host that does not have sufficient resources to handle fragmentation.When a packet is fragmented all fragments have the MF flag set except the last fragment, which does not have the MF flag set. The MF flag is also not set on packets that are not fragmented — an unfragmented packet is its own last fragment.

Fragment Offset The fragment offset field, measured in units of eight-byte blocks, is 13 bits long and specifies the offset of a particular fragment relative to the beginning of the original unfragmented IP datagram. The first fragment has an offset of zero. This allows a maximum offset of (213 – 1) × 8 = 65,528 bytes which would exceed the maximum IP packet length of 65,535 bytes with the header length included (65,528 + 20 = 65,548 bytes).

Time To Live (TTL) An eight-bit time to live field helps prevent datagrams from persisting (e.g. going in circles) on an internet. This field limits a datagram's lifetime. It is specified in seconds, but time intervals less than 1 second are rounded up to 1. In latencies typical in practice, it has come to be a hop count field. Each router that a datagram crosses decrements the TTL field by one. When the TTL field hits zero, the packet is no longer forwarded by a packet switch and is discarded. Typically, an ICMP message (specifically the time exceeded) is sent back to the sender that it has been discarded. The reception of these ICMP messages is at the heart of how traceroute works.

Protocol This field defines the protocol used in the data portion of the IP datagram. The Internet Assigned Numbers Authority maintains a list of IP protocol numbers which was originally defined in RFC 790.

Header Checksum 

The 16-bit checksum field is used for error-checking of the header. At each hop, the checksum of the header must be compared to the value of this field. If a header checksum is found to be mismatched, then the packet is discarded. Note that errors in the data field are up to the encapsulated protocol to handle — indeed, both UDP and TCP have checksum fields.Since the TTL field is decremented on each hop and fragmentation is possible at each hop then at each hop the checksum will have to be recomputed. The method used to compute the checksum is defined within RFC 1071: The checksum field is the 16-bit one's complement of the one's complement sum of all 16-bit words in the header. For purposes of computing the checksum, the value of the checksum field is zero.In other words, all 16-bit words are summed together using one's complement (with the checksum field set to zero). The sum is then one's complemented and this final value is inserted as the checksum field.For example, use Hex 45000030442240008006442e8c7c19acae241e2b (20 bytes IP header): 4500 + 0030 + 4422 + 4000 + 8006 + 0000 + 8c7c + 19ac + ae24 + 1e2b = 2BBCF2 + BBCF = BBD1 = 1011101111010001, the 1'S of sum = 0100010000101110 = 442ETo validate a header's checksum the same algorithm may be used - the checksum of the header with the checksum field filled in should be a word containing all zeros (value 0).

Source address An IPv4 address is a group of four octets for a total of 32 bits. The value for this field is determined by taking the binary value of each octet and concatenating them together to make a single 32-bit value.For example, the address 10.9.8.7 would be 00001010000010010000100000000111.This address is the address of the sender of the packet. Note that this address may not be the "true" sender of the packet due to network address translation. Instead, the source address will be translated by the NATing machine to its own address. Thus, reply packets sent by the receiver are routed to the NATing machine, which translates the destination address to the original sender's address.

Destination address Identical to the source address field but indicates the receiver of the packet.

Options Additional header fields may follow the destination address field, but these are not often used. Note that the value in the IHL field must include enough extra 32-bit words to hold all the options (plus any padding needed to ensure that the header contains an integral number of 32-bit words). The list of options may be terminated with an EOL (End of Options List, 0x00) option; this is only necessary if the end of the options would not otherwise coincide with the end of the header

Note: If the Header Length is greater than 5, i.e. it is between 6-15, it means that the Options field is present and must be considered.

Note: the Copied, Option Class, and Option Number are sometimes referred to as a single eight-bit field - the Option Type.

The use of the LSRR and SSRR options (Loose and Strict Source and Record Route) is discouraged because they create security concerns; many routers block packets containing these options

Data

The data field is not a part of the header and, consequently, is not included in the checksum field. The format of the data field is specified in the protocol header field and can be any one of the transport layer protocols.

Some of the common protocols are listed below including their value used in the protocol field

Fragmentation and reassembly

The Internet Protocol is the facility in the Internet architecture that enables different networks to exchange traffic and route traffic across one another. The design accommodates networks of diverse physical nature; it is independent of the underlying transmission technology used in the Link Layer. Link Layer networks of different hardware design usually vary not only in transmission speed, but also in the structure and size of valid framing methods, characterized by the maximum transmission unit (MTU) parameter. To fulfill the role of IP to traverse networks, it was necessary to implement a mechanism to automatically adjust the size of transmission units to adapt to the underlying technology. This introduced the need for fragmentation of IP datagrams. In IPv4, this function was placed at the Internet Layer, and is performed in IPv4 routers, which thus only require this layer as highest one implemented in their design.

In contrast, the next generation of the Internet Protocol, namely IPv6, does not require routers to perform fragmentation; instead, hosts must determine the path maximum transmission unit in advance of transmission and send conforming datagrams.

Fragmentation

When a device receives an IP packet it examines the destination address and determines the outgoing interface to use. This interface has an associated MTU that dictates the maximum data size for its payload. If the data size is bigger than the MTU then the device must fragment the data.

The device then segments the data into segments where each segment is less-than-or-equal-to the MTU less the IP header size (20 bytes minimum; 60 bytes maximum). Each segment is then put into its own IP packet with the following changes:

The total length field is adjusted to the segment size The more fragments (MF) flag is set for all segments except the last one, which is set to 0 The fragment offset field is set accordingly based on the offset of the segment in the original data

payload. This is measured in units of eight-byte blocks. The header checksum field is recomputed.

For example, for an IP header of length 20 bytes and an Ethernet MTU of 1,500 bytes the fragment offsets would be: 0, (1480/8) = 185, (2960/8) = 370, (4440/8) = 555, (5920/8) = 740, etc.

By some chance if a packet changes link layer protocols or the MTU reduces then these fragments would be fragmented again.

For example, if a 4,500-byte data payload is inserted into an IP packet with no options (thus total length is 4,520 bytes) and is transmitted over a link with an MTU of 2,500 bytes then it will be broken up into two fragments:

Indeed, the amount of data has been preserved — 1480 + 1000 + 1480 + 540 = 4500 — and the last fragment offset (495) * 8 (bytes) plus data — 3960 + 540 = 4500 — is also the total length.

Note that fragments 3 & 4 were derived from the original fragment 2. When a device must fragment the last fragment then it must set the flag for all but the last fragment it creates (fragment 4 in this case). Last fragment would be set to 0 value.

Reassembly

When a receiver detects an IP packet where either of the following is true:

"more fragments" flag set "fragment offset" field is non-zero

then the receiver knows the packet is a fragment. The receiver then stores the data with the identification field, fragment offset, and the more fragments flag. When the receiver receives a fragment with the more fragments flag set to 0 then it knows the length of the original data payload since the fragment offset multiplied by 8 (bytes) plus the data length is equivalent to the original data payload size.

Using the example above, when the receiver receives fragment 4 the fragment offset (495 or 3960 bytes) and the data length (540 bytes) added together yield 4500 — the original data length.

Once it has all the fragments then it can reassemble the data in proper order (by using the fragment offsets) and pass it up the stack for further processing.

Assistive protocols

The Internet Protocol is the protocol that defines and enables internetworking at the Internet Layer and thus forms the Internet. It uses a logical addressing system. IP addresses are not tied in any permanent manner to hardware identifications and, indeed, a network interface can have multiple IP addresses. Hosts and routers need additional mechanisms to identify the relationship between device interfaces and IP addresses, in order to properly deliver an IP packet to the destination host on a link. The Address Resolution Protocol (ARP) perform this IP address to hardware address (MAC address) translation for IPv4. In addition the reverse correlation is often necessary, for example, when an IP host is booted or connected to a network it needs to determine its IP address, unless an address is preconfigured by an administrator. Protocols for such inverse correlations exist in the Internet Protocol Suite. Currently used methods are Dynamic Host Configuration Protocol (DHCP), Bootstrap Protocol (BOOTP) and, infrequently, inverse ARP.

Addressing

IPv4 uses 32-bit (four-byte) addresses, which limits the address space to 4,294,967,296 (232) possible unique addresses. However, some are reserved for special purposes such as private networks (~18 million addresses) or multicast addresses (~270 million addresses). This reduces the number of addresses that can potentially be allocated for routing on the public Internet. As addresses are being incrementally delegated to end users, an IPv4 address shortage has been developing. However, network addressing architecture redesign via classful network design, Classless Inter-Domain Routing, and network address translation (NAT) have contributed to delay significantly the inevitable exhaustion.

This limitation has stimulated the development of IPv6, which is currently in the early stages of deployment, and is the only long-term solution.

IP RoutingIP Routing is an umbrella term for the set of protocols that determine the path that data follows in order to travel across multiple networks from its source to its destination. Data is routed from its source to its destination through a series of routers, and across multiple networks. The IP Routing protocols enable routers to build up a forwarding table that correlates final destinations with next hop addresses.

These protocols include:

BGP (Border Gateway Protocol) IS-IS (Intermediate System - Intermediate System) OSPF (Open Shortest Path First) RIP (Routing Information Protocol)

When an IP packet is to be forwarded, a router uses its forwarding table to determine the next hop for the packet's destination (based on the destination IP address in the IP packet header), and forwards the packet appropriately. The next router then repeats this process using its own forwarding table, and so on until the packet reaches its destination. At each stage, the IP address in the packet header is sufficient information to determine the next hop; no additional protocol headers are required.

The Internet, for the purpose of routing, is divided into Autonomous Systems (ASs). An AS is a group of routers that are under the control of a single administration and exchange routing information using a common routing protocol. For example, a corporate intranet or an ISP network can usually be regarded as an individual AS. The Internet can be visualized as a partial mesh of ASs. An AS can be classified as one of the following three types.

A Stub AS has a single connection to one other AS. Any data sent to, or received from, a destination outside the AS must travel over that connection. A small campus network is an example of a stub AS.

A Transit AS has multiple connections to one or more ASs, which permits data that is not destined for a node within that AS to travel through it. An ISP network is an example of a transit AS.

A Multihomed AS also has multiple connections to one or more ASs, but it does not permit data received over one of these connections to be forwarded out of the AS again. In other words, it does not provide a transit service to other ASs. A Multihomed AS is similar to a Stub AS, except that the ingress and egress points for data traveling to or from the AS can be chosen from one of a number of connections, depending on which connection offers the shortest route to the eventual destination. A large enterprise network would normally be a multihomed AS.

An Interior Gateway Protocol (IGP) calculates routes within a single AS. The IGP enables nodes on different networks within an AS to send data to one another. The IGP also enables data to be forwarded across an AS from ingress to egress, when the AS is providing transit services.

Routes are distributed between ASs by an Exterior Gateway Protocol (EGP). The EGP enables routers within an AS to choose the best point of egress from the AS for the data they are trying to route.

The EGP and the IGPs running within each AS cooperate to route data across the Internet. The EGP determines the ASs that data must cross in order to reach its destination, and the IGP determines the path within each AS that data must follow to get from the point of ingress (or the point of origin) to the point of egress (or the final destination).

The diagram below illustrates the different types of AS in a network. OSPF, IS-IS and RIP are IGPs used within the individual ASs; BGP is the EGP used between ASs.