Tag Archives: 1.1d

1.1.d IPv4 and IPv6 fragmentation, plus wireshark

1.3.c [i] Using Wireshark trace analyzer

with the df-bit set, sending packets at a higher mtu will be dropped by the receiver…

(using extended ping commands, without walking through the prompts)

R2#ping df-bit

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
Packet sent with the DF bit set
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/37/64 ms

of course the packets get through…

R2#ping size 1501 df-bit

Type escape sequence to abort.
Sending 5, 1501-byte ICMP Echos to, timeout is 2 seconds:
Packet sent with the DF bit set
Success rate is 0 percent (0/5)

that ping failed because the df-bit was set, negating fragmentation of the out of mtu packet

if we don’t set the df-bit and ship packets at a higher mtu:

R2#ping siz 1600

Type escape sequence to abort.
Sending 5, 1600-byte ICMP Echos to, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/55/92 ms

we have success but we automatically set the mf-bit, as below


a note about display filters… look closely at the filter… it’s hierarchical… if you understand the protocol you’re examining it makes perfect sense.


the mf bit of the flags field in the ip header is equal to 1…

even easier is to simply right click on the section your interested in  and apply as a filter… it populates the filter field, and just make adjustments as needed…


1.1.d Explain IP operations

1.1.d [iv] TTL


from: http://www.tcpipguide.com/free/t_IPDatagramGeneralFormat-2.htm

Time To Live (TTL) Field

Since IP datagrams are sent from router to router as they travel across an internetwork, it is possible that a situation could result where a datagram gets passed from router A to router B to router C and then back to router A. Router loops are not supposed to happen, and rarely do, but are possible.

To ensure that datagrams don’t circle around endlessly, the TTL field was intended to be filled in with a time value (in seconds) when a datagram was originally sent. Routers would decrease the time value periodically, and if it ever hit zero, the datagram would be destroyed. This was also intended to be used to ensure that time-critical datagrams wouldn’t linger past the point where they would be “stale”.

In practice, this field is not used in exactly this manner. Routers today are fast and usually take far less than a second to forward a datagram; measuring the time that a datagram “lives” would be impractical. Instead, this field is used as a “maximum hop count” for the datagram. Each time a router processes a datagram, it reduces the value of the TTL field by one. If doing this results in the field being zero, the datagram is said to have expired. It is dropped, and usually an ICMP Time Exceeded message is sent to inform the originator of the message that this happened.

The TTL field is one of the primary mechanisms by which networks are protected from router loops (see the description of ICMP Time Exceeded messages for more on how TTL helps IP handle router loops.)

1.1.d Explain IP operations

1.1.d [iii] IPv4 and IPv6 fragmentation

from: http://searchnetworking.techtarget.com/answer/What-is-the-difference-between-packet-fragmentation-in-IPv4-and-IPv6

One of the innovations introduced by IPv6 is the elimination of hop-by-hop packet fragmentation. With the new protocol, fragmentation is managed at the ends by means of a special extension header.

More specifically, there are two main differences: Difference one is the fields for handling fragmentation are not in the basic IPv6 header but are put into an extension header if fragmentation is required. This makes IPv6 fragmentation lean because this fragmentation extension header is only inserted in the packet, if fragmentation needs to be done. Difference two is that IPv6 routers do not fragment anymore. Fragmentation has to be done by the source host. He will evaluate the packet size by using Path MTU discovery.

from: http://www.tcpipguide.com/free/t_IPMessageReassemblyProcess.htm 

In IPv4, fragmentation can be performed by a router between the source and destination of an IP datagram, but reassembly is only done by the destination device.

The IPv6 Next Header field is used to “chain together” the headers in an IPv6 datagram. The Next Header field in the main header contains the number of the first extension header; its Next Header contains the number of the second, and so forth. The last header in the datagram contains the number of the encapsulated protocol that begins the Data field.


1.1.d Explain IP operations

1.1.d [ii] IPv4 options, IPv6 extension headers

from: http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html

The options field in the IPv4 header is used to convey additional information on the packet or on the way it should be processed. Routers, unless instructed otherwise, must process the options in the IPv4 header. The processing of most header options pushes the packet into the slow path leading to a forwarding performance hit.
IPv4 Options perform a very important role in the IP protocol operation therefore the capability had to be preserved in IPv6. On the other hand, the impact of IPv4 Options on performance was taken into consideration in the development of IPv6. The functionality of options is removed from the main header and implemented through a set of additional headers called extension headers. The main header remains fixed in size (40 bytes) while customized EHs are added as needed.
this is an excellent reference for ip header
Extension Headers

Zero or more extension headers can be present and are of varying lengths. A Next Header field in the IPv6 header indicates the next extension header. Within each extension header is a Next Header field that indicates the next extension header. The last extension header indicates the upper layer protocol (such as TCP, UDP, or ICMPv6) contained within the upper layer protocol data unit.

The IPv6 header and extension headers replace the existing IPv4 IP header with options. The new extension header format allows IPv6 to be augmented to support future needs and capabilities. Unlike options in the IPv4 header, IPv6 extension headers have no maximum size and can expand to accommodate all the extension data needed for IPv6 communication.

Table 5    Values of the Next Header Field

Value (in decimal) Header
0 Hop-by-Hop Options Header
17 UDP
41 Encapsulated IPv6 Header
43 Routing Header
44 Fragment Header
46 Resource ReSerVation Protocol
50 Encapsulating Security Payload
51 Authentication Header
58 ICMPv6
59 No next header
60 Destination Options Header

Comparing the IPv4 and IPv6 Headers

Table 6 shows the differences between the IPv4 and IPv6 header fields.

Table 6    IPv4 Header Fields and Corresponding IPv6 Equivalents

IPv4 Header Field IPv6 Header Field
Version Same field but with different version numbers.
Internet Header Length Removed in IPv6. IPv6 does not include a Header Length field because the IPv6 header is always a fixed size of 40 bytes. Each extension header is either a fixed size or indicates its own size.
Type of Service Replaced by the IPv6 Traffic Class field.
Total Length Replaced by the IPv6 Payload Length field, which only indicates the size of the payload.
Fragmentation Flags
Fragment Offset
Removed in IPv6. Fragmentation information is not included in the IPv6 header. It is contained in a Fragment extension header.
Time to Live Replaced by the IPv6 Hop Limit field.
Protocol Replaced by the IPv6 Next Header field.
Header Checksum Removed in IPv6. In IPv6, bit-level error detection for the entire IPv6 packet is performed by the link layer.
Source Address The field is the same except that IPv6 addresses are 128 bits in length.
Destination Address The field is the same except that IPv6 addresses are 128 bits in length.
Options Removed in IPv6. IPv4 options are replaced by IPv6 extension headers.