The Illustrated Network- P22 pps

1 byte Next Header Payload Length 128-bit IPv6 Source Address 128-bit IPv6 Destination Address Hop Limit FIGURE 6.5 The IPv6 header fi elds.. Next Header—An 8-bit field giving the type o

The reassembly time-out value must have a value low enough to make the recovery process delay of the transport layer reasonable The transport layer contains session (connection) information that will detect a missing packet in a sequence of segments (the contents of the packets), and TCP always requests missing information to be resent Too long a value for the reassembly timer makes this retransmission process very ineffi cient Too short a value leads to needlessly discarded packets In most TCP/

IP implementations, the reassembly timer is set by the software vendor and cannot be changed This is yet another reason to avoid fragmentation

Reassembly “deadlock” used to be a problem as well When memory was a scarce commodity in hosts, all available local buffer memory could end up holding partially assembled fragments An arriving fragment could not be accepted even if it completed

a set and the system eventually hung However, in these days of cheap and plentiful memory, this rarely happens

Limitations of IPv4

The limitations of IPv4 are often cast solely in terms of address space As important as that is, it is only part of the story Address space is not the only IPv4 limitation Some others follow:

■ The fragmentation fi elds are present in every IPv4 packet

■ Fragmentation is always done with a performance penalty and is best avoided Yet the fi elds involved—all 6 bytes worth and more than 25% of the basic 20-byte IPv4 header—must be present in each and every packet

■ IPv4 Options were seldom used and limited in scope

■ The IPv4 Type of Service fi eld was never used as intended

■ The IPv4 Time To Live fi eld was also never used as intended

■ The 8-bit IPv4 Type fi eld limited IPv4 packet content to 256 possibilities

All of these factors contributed to the structure of the IPv6 packet header

The IPv6 Header Structure

Let’s go back to our Windows devices and capture some IPv6 packets Then we can examine those headers and compare them to IPv4 headers

bsdserver# ping6 fc00:fe67:d4:b:205:85ff:fe8b:bcdb

PING6(56=40+8+8 bytes) fc00:fe67:d4:b:20e:cff:fe3b:8732 >

fc00:fe67:d4:b:205:85ff:fe8b:bcdb

1 6 bytes from fc00:fe67:d4:b:205:85ff:fe8b:bcdb, icmp_seq=0 hlim=64

time=16.027 ms

1 6 bytes from fc00:fe67:d4:b:205:85ff:fe8b:bcdb, icmp_seq=1 hlim=64

time=0.538 ms

1 6 bytes from fc00:fe67:d4:b:205:85ff:fe8b:bcdb, icmp_seq=2 hlim=64

time=0.655 ms

1 6 bytes from fc00:fe67:d4:b:205:85ff:fe8b:bcdb, icmp_seq=3 hlim=64

time=0.622 ms

^C

fc00:fe67:d4:b:205:85ff:fe8b:bcdb ping6 statistics

-4 packets transmitted, -4 packets received, 0% packet loss

round-trip min/avg/max/std-dev = 0.538/4.461/16.027/6.678 ms

Here is the fi rst packet we captured:

bsdserver# tethereal -V

Capturing on em0

Frame 1 (70 bytes on wire, 70 bytes captured)

Arrival Time: May 23, 2008 18:39:58.914560000

Time delta from previous packet: 0.000000000 seconds

Time since reference or first frame: 0.000000000 seconds

Frame Number: 1

Packet Length: 70 bytes

Capture Length: 70 bytes

Ethernet II, Src: 00:0e:0c:3b:87:32, Dst: 00:05:85:8b:bc:db

Destination: 00:05:85:8b:bc:db (JuniperN_8b:bc:db)

Source: 00:0e:0c:3b:87:32 (Intel_3b:87:32)

Type: IPv6 (0x86dd)

Internet Protocol Version 6

Version: 6

Traffic class: 0x00

Flowlabel: 0x00000

Payload length: 16

Next header: ICMPv6 (0x3a)

Hop limit: 64

Source address: fc00:fe67:d4:b:20e:cff:fe3b:8732 (fc00:fe67:d4:b:20e: cff:fe3b:8732)

Destination address: fc00:fe67:d4:b:205:85ff:fe8b:bcdb (fc00:fe67:d4: b:205:85ff:fe8b:bcdb)

Internet Control Message Protocol v6

Type: 128 (Echo request)

Code: 0

Checksum: 0x7366 (correct)

ID: 0x0565

Sequence: 0x0000

Data (8 bytes)

0000 6e b9 73 44 43 f4 0d 00 n.sDC

In contrast to the IPv4 header, there are only eight lines (and eight fi elds) in the IPv6 header Since the packet is simple enough, let’s look at the header fi elds in detail as we examine the meaning and values in this IPv6 packet

The IPv6 header is shown in Figure 6.5 Besides the new expanded, 16-byte IP source and destination addresses, there are only six other fi elds in the entire IPv6 header This simpler header structure makes for faster packet processing in most cases

IPv6 packets have their own frame Ethertype value, 0x86dd, making it easy for receivers that must handle both IPv4 and IPv6 on the same interface to distinguish the frame content

Version—A 4-bit field for the IP version number (0x06)

Traffic Class—A 12-bit field that identifies the major class of the packet content (e.g., voice or video packets) Our capture shows this fi eld as the default at 0, meaning that it is ordinary bulk data (as FTP should carry) and requires no special handling at devices

Flow Label—A 16-bit field used to label packets belonging to the same flow (those with the same values in several TCP/IP header parameters) The flow label here is 0, but this is common

Payload Length—A 16-bit fi eld giving the length of the packet in bytes, excluding the IPv6 header The payload of this packet, an ICMP message, is 16 bytes long

1 byte

Next Header Payload Length

128-bit IPv6 Source Address

128-bit IPv6 Destination Address

Hop Limit

FIGURE 6.5

The IPv6 header fi elds Note the reduction in fi eld number of how the address fi elds occupy most of the header.

Next Header—An 8-bit field giving the type of header immediately following the IPv6 header (this served the same function as the Protocol field in IPv4) This packet carries an ICMPv3 message, so the value is 0x3a

Hop Limit—An 8-bit field set by the source host and decremented by 1 at each router Packets are discarded if the hop limit is decremented to zero (this replaces the IPv4 Time To Live field) The hop limit here is 64, half of the FTP value in our IPv4 example Generally, implementers choose the default to use, but values such as 64 or 128 are common

IPv4 AND IPv6 HEADERS COMPARED

Figure 6.6 shows the fi elds in the IPv4 packet header compared to the fi elds in the IPv6 header

1 byte

Hdr

Len

Type of

Service

Time to

Live

Source Address (32-bit IPv4)

Destination Address (32-bit IPv4)

Destination Address (128-bit IPv6) Source Address (128-bit IPv6)

Field names kept from IPv4 to IPv6

Field name and position changed in IPv6

New field in IPv6

Fields not kept in IPv6

(Options, if present, padded in needed)

Protocol Header Checksum

Identification Flags Fragment Offset

1 byte

Total Packet Length Ver-sion

1 byte 1 byte

Traffic Class

1 byte 1 byte 1 byte 1 byte

Flow Label Next Header Hop Limit Playload Length

Ver-sion

FIGURE 6.6

IPv4 and IPv6 headers compared, showing how the old fi elds and new fi elds relate to each other.

IPv6 Header Changes

In summary, the following are some of the most important changes to the IP header in IPv6

■ Longer addresses (32 bits to 128 bits) No fragmentation fi elds

■ No header checksum fi eld No header length fi eld (there is a fi xed length header)

■ Payload length given in bytes, not “blocks” (32-bit units) Time to Live (TTL) fi eld becomes Hop Limit

■ Protocol fi eld becomes Next Header (determines content format) 64-bit alignment

of the packet, not 32-bit alignment A Flow Label fi eld has been added

■ No Type of Service bits (which were seldom respected anyway) Many of the IPv4

fi elds vanish completely, especially the fi elds used for packet fragmentation IPv6 addresses fragmentation performance penalties and problems by forbidding it alto-gether in routers Source hosts can still fragment, however, if the source host wants

to send packets larger than the Path MTU size to a destination In IPv6, as in IPv4, fragmentation issues can be avoided altogether by making all packets 1280 bytes long—the minimum established by RFC 2460—but this results in many “extra” packets

■ The IPv4 header Checksum fi eld is absent because destination host error checking

is the preferred method of error detection in today’s more reliable networks, and almost all transmission frames provide better error detection than the IP layer There

is no header length fi eld because all IPv6 headers are the same length The Payload Length fi eld excludes the IPv6 header fi elds and is measured in bytes, rather than the awkward 4-byte units of IPv4

■ The TTL fi eld, never interpreted as time anyway, is gone as well In its place is the Hop Limit fi eld, a simple indication of the number of routers that a packet can pass through before it should reach the destination host The Protocol fi eld of IPv4 has become the Next Header fi eld in IPv6 The term “next header” is more accurate because the information inside the IPv6 packet is not necessarily a higher layer pro-tocol (e.g., TCP segment) in IPv6 There are many other possibilities

■ The entire packet must be an integer number of 64-bit (8-byte) units The 32-bit unit for IPv4 was established when many high-performance computers were 32-bit machines, meaning memory access and internal bus operations moved 32-bit units (called a “word”) around Today high-performance computers often support 64-bit words It only made sense to align the new IPv6 header for ease and speed of pro-cessing on the newer architecture computers

■ Finally, in place of the ToS fi eld in IPv4, the IPv6 header defi nes a Flow Label fi eld Flows are used by routers to pick out IPv6 packets containing delay-sensitive data such as voice, video, and multimedia The Type of Service fi eld was usually ignored by rout-ers in IPv4, and other uses were not standardized

■ The IPv6 specifi cation includes a concept known as Extension Headers Extension Headers essentially take the place of the Options in the IPv4 packet header IPv6 Extension Headers are only present when necessary and are designed to be exten-sible (new functions may be defi ned in the future), but the term “extenexten-sible Exten-sion Headers” is awkward

■ The current Extension Headers include a Hop-by-Hop Option Header, exam-ined by every router handling the IPv6 packet and an Authentication Header for enhanced security on TCP/IP networks (these are used in IPv4 as part of IPSec) There is also a Fragmentation header for the use of the source host when there is no way to prevent the source from sending packets larger than the path MTU size (IPv6 routers cannot fragment, but hosts can) Also, there used to be

a Routing Header specifying the IP addresses of the routers on the path from source to destination (similar to “source routing” in token ring LANs), but this is deprecated by RFC 5095 There are several others, but these show the kinds of capabilities included in the IPv6 Extension Headers

IPv6 AND FRAGMENTATION

What would happen if we put IPv6 into a situation where it has to fragment packet content to make it fi t into a frame? Let’s use the Illustrated Network to fi nd out Two useful ping parameters are the size of the packet to bounce off a remote device and the count of packets sent We’ll capture the packets sent when bsdserver sends a 2000-byte packet (too large for an Ethernet frame) to the router

bsdserver# ping6 -s 2000 -c 1 fc00:fe67:d4:b:205:85ff:fe8b:bcdb

PING6(2048=40+8+2000 bytes) fc00:fe67:d4:b:20e:cff:fe3b:8732 >

fc00:fe67:d4:b:205:85ff:fe8b:bcdb

2 008 bytes from fc00:fe67:d4:b:205:85ff:fe8b:bcdb, icmp_seq=0 hlim=64

time=2.035 ms

fc00:fe67:d4:b:205:85ff:fe8b:bcdb ping6 statistics

-1 packets transmitted, -1 packets received, 0% packet loss

round-trip min/avg/max/std-dev = 2.035/2.035/2.035/0.000 ms

bsdserver#

This makes 2008 bytes with the IPv6 header Here’s what we have (the data fi elds, which contain test strings, have been omitted):

bsdserver# tethereal -V

Capturing on em0

Frame 1 (1510 bytes on wire, 1510 bytes captured)

Arrival Time: May 25, 2008 08:39:21.231993000

Time delta from previous packet: 0.000000000 seconds

Time since reference or first frame: 0.000000000 seconds

Frame Number: 1

Packet Length: 1510 bytes

Capture Length: 1510 bytes

Ethernet II, Src: 00:0e:0c:3b:87:32, Dst: 00:05:85:8b:bc:db

Destination: 00:05:85:8b:bc:db (JuniperN_8b:bc:db)

Source: 00:0e:0c:3b:87:32 (Intel_3b:87:32)

Type: IPv6 (0x86dd)

Internet Protocol Version 6

Version: 6

Traffic class: 0x00

Flowlabel: 0x00000

Payload length: 1456

Next header: IPv6 fragment (0x2c)

Hop limit: 64

Source address: fc00:fe67:d4:b:20e:cff:fe3b:8732 (fc00:fe67:d4:b:20e: cff:fe3b:8732)

Destination address: fc00:fe67:d4:b:205:85ff:fe8b:bcdb (fc00:fe67:d4: b:205:85ff:fe8b:bcdb)

Fragmentation Header

Next header: ICMPv6 (0x3a)

Offset: 0

More fragments: Yes

Identification: 0x000000e5

Internet Control Message Protocol v6

Type: 128 (Echo request)

Code: 0

Checksum: 0x74df

ID: 0x0e60

Sequence: 0x0000

Data (1440 bytes) (OMITTED)

Frame 2 (622 bytes on wire, 622 bytes captured)

Arrival Time: May 25, 2008 08:39:21.232007000

Time delta from previous packet: 0.000014000 seconds

Time since reference or first frame: 0.000014000 seconds

Frame Number: 2

Packet Length: 622 bytes

Capture Length: 622 bytes

Ethernet II, Src: 00:0e:0c:3b:87:32, Dst: 00:05:85:8b:bc:db

Destination: 00:05:85:8b:bc:db (JuniperN_8b:bc:db)

Source: 00:0e:0c:3b:87:32 (Intel_3b:87:32)

Type: IPv6 (0x86dd)

Internet Protocol Version 6

Version: 6

Traffic class: 0x00

Flowlabel: 0x00000

Payload length: 568

Next header: IPv6 fragment (0x2c)

Hop limit: 64

Source address: fc00:fe67:d4:b:20e:cff:fe3b:8732 (fc00:fe67:d4:

b:20e:cff:fe3b:8732)

Destination address: fc00:fe67:d4:b:205:85ff:fe8b:bcdb (fc00:fe67:

d4:b:205:85ff:fe8b:bcdb)

Fragmentation Header

Next header: ICMPv6 (0x3a)

Offset: 1448

More fragments: No

Identification: 0x000000e5

Data (560 bytes) (OMITTED)

(Frames 3 and 4, the echoed frames sent back in response, are mirror

images of Frames 1 and 2 and have been omitted for brevity.)

bsdserver#

Because the host cannot pack 2000 bytes into an Ethernet frame, the IPv6 host does

the fragmenting before it sends the bits onto the LAN There are no fragmentation fi elds

in the IPv6 header, however, so IPv6 includes a second header (next header) that carries the information needed for the destination to reassemble the fragments (in this case, two of them) The important fi elds are highlighted in bold in the preceding code The fi rst frame (the capture says “packet”) is 1510 bytes long, including 1456 bytes

of payload (given in the Payload Length fi eld) The Next Header value of 0x2c indicates that the next header is an IPv6 fragment header The Fragmentation Header fi elds are listed in full:

■ Next Header (0x3a)—The header following the Fragmentation Header is an ICMPv6 message header

■ Offset (0)—This is the fi rst fragment of a series

■ More Fragments (Yes)—There are more fragments to come

■ Identifi cation (0x000000e5)—Only reassemble fragments that share this

identifi er value

The data fi eld in the ICMPv6 message is 1440 bytes long The rest of the 1510 bytes are from the various headers pasted onto these bytes

Frame 2 holds the rest of the 2000 bytes in the ping This frame is 622 bytes long and carries 568 bytes of payload The Next Header is still an IPv6 fragment (0x2c) The Fragmentation Header fi elds follow:

■ Next header (0x3a)—The header following the Fragmentation Header is an ICMPv6 message header

■ Offset (1448)—These bytes start 1448 bytes after the content of the fi rst

frame (The “extra” 8 bytes are for the ICMPv6 header.)

■ More Fragments (No)—The contents of this packet complete the series

■ Identifi cation (0x000000e5)—This fragment goes with the previous one with this identifi er value

The data fi eld in the ICMPv6 message is 560 bytes long Along with the 1440 bytes

in the fi rst fragment, these add up to the 2000 bytes sent

QUESTIONS FOR READERS

Figure 6.7 shows some of the concepts discussed in this chapter and can be used to help you answer the following questions

Hdr

Len

Flags Identification

Time to

Live Protocol Header Checksum

Source Address (32-bit IPv4)

Destination Address (32-bit IPv4)

(Options, if present, padded if needed)

Fragment Offset

Type of

Service Total Packet Length

Playload Length

Source Address (128-bit IPv6)

Destination Address (128-bit IPv6)

Flow Label Next

Header Hop Limit

Ver-sion

1 Why are diagnostics like ping messages routinely given high hop-count values such as 64 or 128?

2 Without any IPv4 options in use, what value should be seen in the Header Length

fi eld most of the time?

3 How does an IP receiver detect missing fragments?

4 Is there any way for an IP receiver to determine how many fragments are supposed to arrive?

5 Since almost all the IPv4 header fi elds are options in IPv6, is it correct to say that the IPv6 header is “simplifi ed”?

FIGURE 6.7

The IPv4 and IPv6 packet header fi elds IPv6 can employ most IPv4 options as “next header”

fi elds following the basic header.