Chapter 7 Internet Protocol: Connectionless Datagram Delivery (IPv4, IPv6)
The service is defined as an unreliable, best-effort, connectionless packet delivery system. The basic service is classified as connectionless because each packet is treated independently from all others and it is unreliable as it mean that delivery is not guaranteed. It uses best-effort delivery because the Internet software makes an earnest attempt to deliver packets.
7.3 The IP Datagram
The Internet calls its basic transfer unit an Internet datagram, usually abbreviated IP datagram. In fact, TCP/IP technology has become so successful that when someone uses the term datagram without any qualification, it is generally accepted to mean IP datagram.
7.4 IPv4 Datagram FormatIPv4 datagram is at least 20 bytes length, max 60 bytes length and the size is not fixed. It depends on the options filed.
Internet Header Length (IHL)
Services Type
* Differentiated Services Code Point (DSCP)
7.5 IPv6 Datagram Format
Each IPv6 datagram begins with a 40-octet base header. IPv6 datagram begins with a fixed-size base header followed by zero or mor eextension headers, followed by a payload. Each IPv6 header contains a NEXT HEADER field that specifies the type of the header that follows. The final header uses the NEXT HEADER field to specify the type of the payload.
VERS field specifies the version of the protocol; 6 specifies an IPv6 datagram.
TRAFFIC CLASS field is interpreted exactly the same as IPv4’sTYPE OF SERVICE field. FLOW LABEL is intended to allow IPv6 to be used with technologies that support resource reservation. The FLOW LABEL holds an ID that allows a router to identify the flow, which is used instead of the destination address when forwarding a datagram. PAYLOAD LENGTH field refers only to the data being carried and does not include the size of the base header or extension header(s). NEXT HEADER field appears in all headers and specifies the type of the next extension header, and in the final header, gives the type of the payload.
HOP LIMIT field specifies the maximum number of networks the datagram
can traverse before being discarded.
SOURCE ADDRESS and DESTINATION ADDRESS fields specify the IPv6 addresses of the original sender and ultimate destination.
7.6 Datagram Type of Service and Differentiated Services
Informally called Type Of Service(TOS), the 8-bit SERVICE TYPE field in an IPv4 header and the TRAFFIC CLASS field in an IPv6 header specify how the datagram should be handled. In the late 1990s, the IETF redefined the meaning of the field to accommodate a set of differentiated services(DiffServ).
Under DiffServ, the first six bits of the field constitute a codepoint, which is sometimes abbreviated DSCP, and the last two bits are left unused. A codepoint value maps to an underlying service definition, typically through an array of pointers. Although it is possible to define 64 separate services, the designers suggest that a given router will only need a few services, and multiple codepoints will map to each service. Thus, the last bit are always 0.
To maintain backward compatibility with the original definition, the standard distinguishes between the first three bits of the codepoint (bits that were formerly used for precedence) and the last three bits. When the last three bits contain zero, the precedence bits define eight broad classes of service that adhere to the same guidelines as the original definition: datagrams with a higher number in their precedence field are given preferential treatment over datagrams with a lower number.
We regard the service type specification as a hint to the forwarding algorithm that helps it choose among various paths to a destination based on local policies and its knowledge of the hardware technologies available on those paths. An internet does not guarantee to provide any particular type of service.
7.7 Datagram Size, Network MTU and Fragmentation
The internet technology should accommodate the greatest possible variety of network hardware and network applications.
The first principle implies that we should not rule out a network technology merely because the technology has a small MTU. The second principle suggests that application programmers should be allowed to choose whatever datagram size they find appropriate.
The standards allow each application to choose a datagram size that is best suited to the application. Then when transferring a datagram, check the size to see if the datagram is less than the MTU. If the datagram does not fit into a frame, divide the datagram into smaller pieces called fragments.
IPv4 allows any router along a path to fragment a datagram. In fact, if a later router along the path finds that a fragment is too large, the router can divide the fragment into fragments that are even smaller. IPv6 requires the original source to learn the path MTU and perform fragmentation; routers are forbidden from performing fragmentation.
7.8 IPv4 Datagram Fragmentation
IPv4 fragmentation occurs automatically at any point along the path when a datagram is too large for a network over which it must pass; the source only needs to insure that datagrams can travel over the first hop.
More information about the IP Fragmentation --> HERE
7.9 IPv6 Fragmentation and Path MTU Discovery (PMTUD)
The original source host is required to find the minimum MTU along the path to the destination and fragment each datagram according to the path it will take. IP routers along the path are not permitted to fragment IPv6 datagrams; if a datagram does not fit into the MTU of a network, the router sends an error message to the original source and drops the datagram.
Because networking technologies used in the Internet do not inform a host about the path MTU, a host must engage in a trial-and-error mechanism to determine the path MTU. Known asPath MTU Discovery(PMTUD), the mechanism consists of sending an IPv6 datagram that fits in the MTU of the directly-connected network.
Therefore, PMTUD specifies that a host should probe periodically by sending a larger datagram. Because we do not expect routes to change frequently and because the path MTU changes less frequently than routes, most implementations of IPv6 choose a long time period before probing again
Recall that the IPv6 base header does not include fields to specify fragmentation. Therefore, when it fragments an IPv6 datagram, a source inserts a Fragment Extension Header into each fragment.
As the figure shows, the extension header includes the required NEXT HEADER field. It also includes two fields that are reserved for future use. The remaining three fields have the same meaning as IPv4 fragmentation control fields. A 13-bit FRAGMENT OFFSET field specifies where in the original datagram this fragment belongs, the Mbits is a more fragments bit that specifies whether a fragment is the final (rightmost) fragment of the original datagram, and the IDENTIFICATION field contains a unique datagram ID that is shared by all the fragments of a datagram.
7.10 Datagram Reassembly
The mechanism used to handle fragment loss consists of a reassembly timer. The ultimate destination starts a timer when a fragment arrives for a given datagram. If the timer expires before all fragments arrive, the receiving machine discards the surviving fragments. The source must retransmit the entire datagram; there is no way for the receiver to request individual fragments. In the Internet, the ultimate destination reassembles fragments. The design means that routers do not need to store fragments or keep other information about packets.
7.11 Header Fields used for Datagram Reassembly
Field IDENTIFICATION contains a unique integer that identifies the datagram. That is, each datagram sent by a given source has a unique ID. A typical implementation uses a sequence number — a computer sends a datagram with identification S, the next datagram will have identification S+1.
A destination uses the IDENTIFICATION field in fragments along with the datagram source address to group all the fragments of a given datagram. The value in the FRAGMENT OFFSET field specifies the offset in the original datagram of the payload being carried in the fragment, measured in units of 8 octets, starting at offset zero.
The more fragmentsbit solves the problem that the datagrams may arrive out of order. Once a fragment arrives with the more fragmentsbit turned off, the destination knows the fragment carries data from the tail of the original datagram. From the FRAGMENT OFFSET field and the size of the fragment, the destination can compute the length of the original datagram.
7.12 Time To Live (IPv4) and Hop Limit (IPv6)
The TTL field is used to specify how many hops a datagram may traverse before being discarded. IPv6 includes the exact same concept. To clarify the meaning, IPv6 uses the name HOP LIMIT in place of TIME-TO-LIVE.
IP software in each machine along a path from source to destination decrements the field known as TIME-TO-LIVE (IPv4) or HOP LIMIT (IPv6). When the field reaches zero the datagram is discarded. A router does more than merely discard a datagram when the TTL reaches zero — the router sends an error message back to the source.
7.13 Optional IP Items
IP OPTIONS field that follows the destination address is used to send optional items. In IPv6, each of the extension headers is optional, and a given datagram may include multiple extensions. Many of the options in the standards are intended for special control or for network testing and debugging.
7.13.1 IPv4 Options
The options area of the header is treated as an array of octets, and options are placed in the array one after another. For more information, please see this post HERE
Some famous options explanation as below.
Record Route Option. The record route option allows the source to create an empty list of IPv4 addresses and request that each router along the path add its IPv4 address to the list. The list begins with a header that specifies the type of the option, a length field, and a pointer. The length field specifies the number of octets in the list, and the pointer specifies the offset of the next free item.
Source Route Options. Two options, Strict Source Route and Loose Source Route, provide a way for a sender to control forwarding along a path through an internet.
Strict Source Route. Strict source routing specifies a complete path through an internet (i.e., the path the datagram must follow to reach its destination). The path consists of IPv4 addresses that each correspond to a router (or to the ultimate destination).
The wordstrictmeans that each pair of routers along the path must be directly connected by a network; an error results if a router cannot reach the next router specified in the
list.
Loose Source Route. Loose source routing specifies a path through an internet, and the option includes a sequence of IP addresses. Unlike strict source routing, a loose source route specifies that the datagram must visit the sequence of IP addresses, but allows multiple network hops between successive addresses on the list
Internet Timestamp Option. The timestamp option works like the record route option: the option field starts with an initially empty list, and each router along the path from source to destination fills in one entry. Unlike the record route option, each entry in a timestamp list contains two 32-bit values that are set to the IPv4 address of the router that filled the entry and a 32-bit integer timestamp. Timestamps give the time and date at which a router handles the datagram.
7.13.2 IPv6 OptionsIPv6 uses the mechanism of extension headers in place of IPv4 options. Many of the IPv6 extension headers are variable size; the size depends on the contents.
As the figure indicates, only the first two octets are specified: a NEXT HEADER
field and a Header Extension Length field (HDR EXT LEN). The length field specifies the length of the extension header in octets. The body of the extension header follows a Type-Length-Value(TLV) approach. The body consists of options that each begin with a 2-octet header. The first octet specifies the type of the option, the second octet specifies the length, and the next octets contain the value.
IPv6 requires datagram headers to be aligned to a multiple of eight octets. Variable-size options mean that the Hop-By-Hop header may not align correctly. In such cases, IPv6 defines two padding options that a sender can use to align the headers. One of the two consists of a single octet of padding; the other uses two octets to specify a padding length.
More explanation --> HERE
7.14 Options Processing during Fragmentation
If an option must be processed by intermediate routers, the option is copied into each fragment. However, if the option is only used at the ultimate destination, the option is copied into the header of the first fragment but not the rest. Although they use the same concept, IPv4 and IPv6 differ in most details.
7.14.1 IPv4 Processing Options during fragmentation
Each code octet contains a copy bit that specifies whether the option should be replicated in all fragments or in only one fragment. Source route options provide an example of options that must be copied into each fragment. When a sender specifies a source route, the sender intends for the datagram to follow the specified path through an internet.
7.14.2 IPv6 Processing Options during fragmentation
IPv6 divides a datagram into two conceptual pieces: an initial piece that is classified as unfragmentable and the remainder, which is classified as fragmentable. The base header lies in the unfragmentable piece and the payload lies in the fragmentable piece.
The IPv6 standards specify whether a header is fragmentable. In particular, the Hop-By-Hop Header and Route Header are not fragmentable; other extension headers are fragmentable. Therefore, the fragmentable part of the datagram begins after the non- fragmentable extension headers.
As the figure indicates, each fragment starts with a copy of the unfragmentable piece of the original datagram. In the figure, the unfragmentable piece includes a Base Header,aHop-By-Hop Header, and a Route Header. Following the unfragmentable piece, a fragment has aFragment Headerlabeled Fin the figure.
7.15 Network Byte Order
Protocols must specify enough detail to insure that both sides interpret data the same way. Standardizing byte-order for integers is especially important for protocol headers because a header usually contains binary values that specify information such as the packet length or a type field that specifies the type of data in the payload area. The TCP/IP protocols solve the byte-order problem by defining a network standard byte order that all machines must use for binary fields in headers.
The Internet protocols define network byte order to be big endian. A sender must convert all integer fields in packet headers to network byte order before sending a packet, and a receiver must convert all integer fields in packet headers to local byte order before processing a packet.
7.1 Internet Architecture and Philosophy
Conceptually, a TCP/IP internet provides three sets of services. Figure below list the three categories and illustrates dependencies among them.
Internet protocols are designed around three conceptual levels of service. A connectionless service at the lowest level matches underlying hardware well, a reliable transport service provides service to applications, and a variety of applications provide the services users expect.
7.2 Connectionless Delivery System CharacteristicsConceptually, a TCP/IP internet provides three sets of services. Figure below list the three categories and illustrates dependencies among them.
Internet protocols are designed around three conceptual levels of service. A connectionless service at the lowest level matches underlying hardware well, a reliable transport service provides service to applications, and a variety of applications provide the services users expect.
The service is defined as an unreliable, best-effort, connectionless packet delivery system. The basic service is classified as connectionless because each packet is treated independently from all others and it is unreliable as it mean that delivery is not guaranteed. It uses best-effort delivery because the Internet software makes an earnest attempt to deliver packets.
7.3 The IP Datagram
The Internet calls its basic transfer unit an Internet datagram, usually abbreviated IP datagram. In fact, TCP/IP technology has become so successful that when someone uses the term datagram without any qualification, it is generally accepted to mean IP datagram.
7.4 IPv4 Datagram FormatIPv4 datagram is at least 20 bytes length, max 60 bytes length and the size is not fixed. It depends on the options filed.
The source address field in a datagram always refers to the original source and the destination address field refers to the ultimate destination.
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), which is 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. The minimum value for this field is 5, 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.
Services Type
It is TOS (Type of Service). It is mostly refer to the DSCP and ECN.
More information on the ToS & DSCP, please see this post HERE
More information on the ToS & DSCP, please see this post HERE
* Differentiated Services Code Point (DSCP)
Originally defined as the Type of service field, this field is now defined for Differentiated services (DiffServ). New technologies are emerging that require real-time data streaming and therefore make use of the DSCP field. An example is Voice over IP(VoIP)
* Explicit Congestion Notification (ECN)
It 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.
Total Length
This 16-bit field defines the entire packet (fragment) size, including header and data, in bytes. The minimum-length packet is 20 bytes (20-byte header + 0 bytes data) and the maximum is 65,535 bytes — the maximum value of a 16-bit word.
Identification
This field is an identification field and is primarily used for uniquely identifying the group of fragments of a single IP datagram.
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
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 is dropped. This can be used when sending packets to a host that does not have sufficient resources to handle fragmentation. For unfragmented packets, the MF flag is cleared. For fragmented packets, all fragments except the last have the MF flag set. The last fragment has a non-zero Fragment Offset field, differentiating it from an unfragmented packet.
Fragment Offset
The fragment offset field, measured in units of eight-byte blocks (64 bits), 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).
More explanation on the IP Fragmentation.--> HERE
TTL (Time to Live)
More explanation on the IP Fragmentation.--> HERE
TTL (Time to Live)
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 practice, the field has become a hop count—when the datagram arrives at a router, the router decrements the TTL field by one. When the TTL field hits zero, the router discards the packet and typically sends an ICMP Time Exceeded message to the sender.
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
Header Checksum
The 16-bit checksum field is used for error-checking of the header. When a packet arrives at a router, the router calculates the checksum of the header and compares it to the checksum field. If the values do not match, the router discards the packet. Errors in the data field must be handled by the encapsulated protocol. Both UDP and TCP have checksum fields.
Source address
This field is the IPv4 address of the sender of the packet. Note that this address may be changed in transit by a network address translation device.
Destination address
This field is the IPv4 address of the receiver of the packet. As with the source address, this may be changed in transit by a network address translation device.
Options
The options field is 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 integer 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.
More information about options please visit this post HERE
More information about options please visit this post HERE
Padding
It depends on the options selected. It represents bits containing zero that may be needed to ensure the datagram header extends to an exact multiple of 32 bits (recall that the header length field is specified in units of 32-bit words).
7.5 IPv6 Datagram Format
Each IPv6 datagram begins with a 40-octet base header. IPv6 datagram begins with a fixed-size base header followed by zero or mor eextension headers, followed by a payload. Each IPv6 header contains a NEXT HEADER field that specifies the type of the header that follows. The final header uses the NEXT HEADER field to specify the type of the payload.
(a) only a base header, (b) a base header and one extension, and
(c) a base header and two extension header
The IPv6 base header format; the size is fixed at 40 octets.
VERS field specifies the version of the protocol; 6 specifies an IPv6 datagram.
TRAFFIC CLASS field is interpreted exactly the same as IPv4’sTYPE OF SERVICE field. FLOW LABEL is intended to allow IPv6 to be used with technologies that support resource reservation. The FLOW LABEL holds an ID that allows a router to identify the flow, which is used instead of the destination address when forwarding a datagram. PAYLOAD LENGTH field refers only to the data being carried and does not include the size of the base header or extension header(s). NEXT HEADER field appears in all headers and specifies the type of the next extension header, and in the final header, gives the type of the payload.
HOP LIMIT field specifies the maximum number of networks the datagram
can traverse before being discarded.
SOURCE ADDRESS and DESTINATION ADDRESS fields specify the IPv6 addresses of the original sender and ultimate destination.
7.6 Datagram Type of Service and Differentiated Services
Informally called Type Of Service(TOS), the 8-bit SERVICE TYPE field in an IPv4 header and the TRAFFIC CLASS field in an IPv6 header specify how the datagram should be handled. In the late 1990s, the IETF redefined the meaning of the field to accommodate a set of differentiated services(DiffServ).
Under DiffServ, the first six bits of the field constitute a codepoint, which is sometimes abbreviated DSCP, and the last two bits are left unused. A codepoint value maps to an underlying service definition, typically through an array of pointers. Although it is possible to define 64 separate services, the designers suggest that a given router will only need a few services, and multiple codepoints will map to each service. Thus, the last bit are always 0.To maintain backward compatibility with the original definition, the standard distinguishes between the first three bits of the codepoint (bits that were formerly used for precedence) and the last three bits. When the last three bits contain zero, the precedence bits define eight broad classes of service that adhere to the same guidelines as the original definition: datagrams with a higher number in their precedence field are given preferential treatment over datagrams with a lower number.
We regard the service type specification as a hint to the forwarding algorithm that helps it choose among various paths to a destination based on local policies and its knowledge of the hardware technologies available on those paths. An internet does not guarantee to provide any particular type of service.
7.7 Datagram Size, Network MTU and Fragmentation
The internet technology should accommodate the greatest possible variety of network hardware and network applications.
The first principle implies that we should not rule out a network technology merely because the technology has a small MTU. The second principle suggests that application programmers should be allowed to choose whatever datagram size they find appropriate.
The standards allow each application to choose a datagram size that is best suited to the application. Then when transferring a datagram, check the size to see if the datagram is less than the MTU. If the datagram does not fit into a frame, divide the datagram into smaller pieces called fragments.
IPv4 allows any router along a path to fragment a datagram. In fact, if a later router along the path finds that a fragment is too large, the router can divide the fragment into fragments that are even smaller. IPv6 requires the original source to learn the path MTU and perform fragmentation; routers are forbidden from performing fragmentation.
7.8 IPv4 Datagram Fragmentation
IPv4 fragmentation occurs automatically at any point along the path when a datagram is too large for a network over which it must pass; the source only needs to insure that datagrams can travel over the first hop.
More information about the IP Fragmentation --> HERE
7.9 IPv6 Fragmentation and Path MTU Discovery (PMTUD)
The original source host is required to find the minimum MTU along the path to the destination and fragment each datagram according to the path it will take. IP routers along the path are not permitted to fragment IPv6 datagrams; if a datagram does not fit into the MTU of a network, the router sends an error message to the original source and drops the datagram.
Because networking technologies used in the Internet do not inform a host about the path MTU, a host must engage in a trial-and-error mechanism to determine the path MTU. Known asPath MTU Discovery(PMTUD), the mechanism consists of sending an IPv6 datagram that fits in the MTU of the directly-connected network.
Therefore, PMTUD specifies that a host should probe periodically by sending a larger datagram. Because we do not expect routes to change frequently and because the path MTU changes less frequently than routes, most implementations of IPv6 choose a long time period before probing again
Recall that the IPv6 base header does not include fields to specify fragmentation. Therefore, when it fragments an IPv6 datagram, a source inserts a Fragment Extension Header into each fragment.
As the figure shows, the extension header includes the required NEXT HEADER field. It also includes two fields that are reserved for future use. The remaining three fields have the same meaning as IPv4 fragmentation control fields. A 13-bit FRAGMENT OFFSET field specifies where in the original datagram this fragment belongs, the Mbits is a more fragments bit that specifies whether a fragment is the final (rightmost) fragment of the original datagram, and the IDENTIFICATION field contains a unique datagram ID that is shared by all the fragments of a datagram.7.10 Datagram Reassembly
The mechanism used to handle fragment loss consists of a reassembly timer. The ultimate destination starts a timer when a fragment arrives for a given datagram. If the timer expires before all fragments arrive, the receiving machine discards the surviving fragments. The source must retransmit the entire datagram; there is no way for the receiver to request individual fragments. In the Internet, the ultimate destination reassembles fragments. The design means that routers do not need to store fragments or keep other information about packets.
7.11 Header Fields used for Datagram Reassembly
Field IDENTIFICATION contains a unique integer that identifies the datagram. That is, each datagram sent by a given source has a unique ID. A typical implementation uses a sequence number — a computer sends a datagram with identification S, the next datagram will have identification S+1.
A destination uses the IDENTIFICATION field in fragments along with the datagram source address to group all the fragments of a given datagram. The value in the FRAGMENT OFFSET field specifies the offset in the original datagram of the payload being carried in the fragment, measured in units of 8 octets, starting at offset zero.
The more fragmentsbit solves the problem that the datagrams may arrive out of order. Once a fragment arrives with the more fragmentsbit turned off, the destination knows the fragment carries data from the tail of the original datagram. From the FRAGMENT OFFSET field and the size of the fragment, the destination can compute the length of the original datagram.
7.12 Time To Live (IPv4) and Hop Limit (IPv6)
The TTL field is used to specify how many hops a datagram may traverse before being discarded. IPv6 includes the exact same concept. To clarify the meaning, IPv6 uses the name HOP LIMIT in place of TIME-TO-LIVE.
IP software in each machine along a path from source to destination decrements the field known as TIME-TO-LIVE (IPv4) or HOP LIMIT (IPv6). When the field reaches zero the datagram is discarded. A router does more than merely discard a datagram when the TTL reaches zero — the router sends an error message back to the source.
7.13 Optional IP Items
IP OPTIONS field that follows the destination address is used to send optional items. In IPv6, each of the extension headers is optional, and a given datagram may include multiple extensions. Many of the options in the standards are intended for special control or for network testing and debugging.
7.13.1 IPv4 Options
The options area of the header is treated as an array of octets, and options are placed in the array one after another. For more information, please see this post HERE
Some famous options explanation as below.
Record Route Option. The record route option allows the source to create an empty list of IPv4 addresses and request that each router along the path add its IPv4 address to the list. The list begins with a header that specifies the type of the option, a length field, and a pointer. The length field specifies the number of octets in the list, and the pointer specifies the offset of the next free item.
Source Route Options. Two options, Strict Source Route and Loose Source Route, provide a way for a sender to control forwarding along a path through an internet.
Strict Source Route. Strict source routing specifies a complete path through an internet (i.e., the path the datagram must follow to reach its destination). The path consists of IPv4 addresses that each correspond to a router (or to the ultimate destination).
The wordstrictmeans that each pair of routers along the path must be directly connected by a network; an error results if a router cannot reach the next router specified in the
list.
Loose Source Route. Loose source routing specifies a path through an internet, and the option includes a sequence of IP addresses. Unlike strict source routing, a loose source route specifies that the datagram must visit the sequence of IP addresses, but allows multiple network hops between successive addresses on the list
Internet Timestamp Option. The timestamp option works like the record route option: the option field starts with an initially empty list, and each router along the path from source to destination fills in one entry. Unlike the record route option, each entry in a timestamp list contains two 32-bit values that are set to the IPv4 address of the router that filled the entry and a 32-bit integer timestamp. Timestamps give the time and date at which a router handles the datagram.
7.13.2 IPv6 OptionsIPv6 uses the mechanism of extension headers in place of IPv4 options. Many of the IPv6 extension headers are variable size; the size depends on the contents.
As the figure indicates, only the first two octets are specified: a NEXT HEADER
field and a Header Extension Length field (HDR EXT LEN). The length field specifies the length of the extension header in octets. The body of the extension header follows a Type-Length-Value(TLV) approach. The body consists of options that each begin with a 2-octet header. The first octet specifies the type of the option, the second octet specifies the length, and the next octets contain the value.
IPv6 requires datagram headers to be aligned to a multiple of eight octets. Variable-size options mean that the Hop-By-Hop header may not align correctly. In such cases, IPv6 defines two padding options that a sender can use to align the headers. One of the two consists of a single octet of padding; the other uses two octets to specify a padding length.
More explanation --> HERE
7.14 Options Processing during Fragmentation
If an option must be processed by intermediate routers, the option is copied into each fragment. However, if the option is only used at the ultimate destination, the option is copied into the header of the first fragment but not the rest. Although they use the same concept, IPv4 and IPv6 differ in most details.
7.14.1 IPv4 Processing Options during fragmentation
Each code octet contains a copy bit that specifies whether the option should be replicated in all fragments or in only one fragment. Source route options provide an example of options that must be copied into each fragment. When a sender specifies a source route, the sender intends for the datagram to follow the specified path through an internet.
7.14.2 IPv6 Processing Options during fragmentation
IPv6 divides a datagram into two conceptual pieces: an initial piece that is classified as unfragmentable and the remainder, which is classified as fragmentable. The base header lies in the unfragmentable piece and the payload lies in the fragmentable piece.
The IPv6 standards specify whether a header is fragmentable. In particular, the Hop-By-Hop Header and Route Header are not fragmentable; other extension headers are fragmentable. Therefore, the fragmentable part of the datagram begins after the non- fragmentable extension headers.
IPv6 fragmentation with (a) an IPv6 datagram with extension headers divided into fragmentable and unfragmentable pieces, and (b) a set of fragments.
As the figure indicates, each fragment starts with a copy of the unfragmentable piece of the original datagram. In the figure, the unfragmentable piece includes a Base Header,aHop-By-Hop Header, and a Route Header. Following the unfragmentable piece, a fragment has aFragment Headerlabeled Fin the figure.
7.15 Network Byte Order
Protocols must specify enough detail to insure that both sides interpret data the same way. Standardizing byte-order for integers is especially important for protocol headers because a header usually contains binary values that specify information such as the packet length or a type field that specifies the type of data in the payload area. The TCP/IP protocols solve the byte-order problem by defining a network standard byte order that all machines must use for binary fields in headers.
The Internet protocols define network byte order to be big endian. A sender must convert all integer fields in packet headers to network byte order before sending a packet, and a receiver must convert all integer fields in packet headers to local byte order before processing a packet.
