! The IPv6 header reserves two fields (totaling 28 bits) for prioritizing
and/or identifying packets and packet flows that require special handling, such as prioritization. As real-time applications such as video and voice become more prevalent, these fields should be heavily used.
110 Chapter 3 • The IPv6 Headers
! The Next Header field in IPv6 uses the same definitions used in IPv4
(and defined in RFC 1700).Thus TCP uses “6,” UDP uses “17,” and so on.
! Immediately following the destination IPv6 address is the next header—
an IPv6 extension header, an upper-layer protocol header, etc.
Comparing the IPv6 and IPv4 Headers
! Source and destination IPv6 addresses are four times as long as IPv4
addresses (128 bits versus 32 bits)
! The IPv4 header adds optional functions within the header in the options
field. IPv6 has a completely fixed header, but adds extension headers for optional functions such as routing, fragmentation, or authentication.
! In IPv6, many IPv4 fields were maintained, a few were added, and
several were dropped (or changed to extension headers)
The IPv6 Extension Headers
! Different extension headers were created based on the nodes that would
need to examine and process them. For example, the Destination Header and Fragmentation Headers were created strictly for viewing by the endpoint, whereas the Routing and Hop-by-Hop Headers were created to be viewed by all routers along the path.This improves efficiency, since some headers do not need to be processed by intermediate routers.
! Authentication and Encryption are incorporated into the IPv6 standard
as extension headers, supporting the need for increased security in the digital world.
! Although the Fragmentation header is part of the IPv6 standard, its use
The IPv6 Headers • Chapter 3 111
Q: Since the routing header can control the path of a packet, can it be used to
optimize the path used between a client and server?
A: While in theory this could be done, in reality it will probably be used only in
conjunction with protocols such as RSVP.This is primarily because without RSVP (or an equivalent protocol), the client and the server will not be aware of the underlying network infrastructure. Instead, this feature will most likely be used by mobile users or for diagnostic purposes by network management applications that will allow you to control the flow of the packet for testing purposes.
Q: Doesn’t the IPv6 header create more overhead—and thus less efficiency—
than IPv4?
A: The IPv6 header is larger and does add more overhead to each packet than
IPv4. Assuming there are no options or extensions, the standard IPv6 header is 40 bytes, while the standard IPv4 header is only 20 bytes. So IPv6 adds 20 bytes to the header, but with IPv6 there are 24 more bytes just in the source and destination addresses (32 bytes versus 8 bytes).Without the larger source and destination addresses, the IPv6 header is smaller than IPv4. However, given the shortage of IPv4, I think there is a good argument for increasing the size of IPv6 addresses.
Q: I see that IPv6 supports packets up to 64 KB, or—with the Hop-by-Hop
Options header—even much larger packets. Is this feature likely to be used?
A: Larger packets have advantages, such as reduced processing at the end nodes.
However, packet sizes larger than 1514 bytes have been proposed in the industry several times and have received surprisingly little support. One pre- vious opposing point was that network designers did not want a very large packet to “clog” a slower link, preventing time-sensitive traffic (such as video or voice) to pass in a timely manner. As WAN speeds are increasing over time,
www.syngress.com
Frequently Asked Questions
The following Frequently Asked Questions, answered by the authors of this book, are designed to both measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts. To have your questions about this chapter answered by the author, browse to
112 Chapter 3 • The IPv6 Headers
this is becoming less of a problem. Over time this may become a common option, but I do not anticipate this feature being used in the near future.
Q: Many of the extension headers have fields where options can be added—why
are only a few of those discussed here?
A: The current IPv6 specification, RFC 2460, wanted to create a framework that
would be flexible enough to support changes over time. As such, they defined several extension headers, most with fields for options, yet they did not define many of these options. Rather, they wanted these to be further defined in later RFCs as the needs and requirements of IPv6 became more clear. Most of these options are still evolving and being refined as more and more users adopt IPv6.
Q: Since IPv6 will often be sent over Ethernet (which has its own packet
checksum), and it frequently delivers TCP data (which uses a checksum), is the authentication header necessary?
A: In many cases the Authentication header will not be used. However, in envi-
ronments requiring higher levels of security, the Authentication header is still useful.The Ethernet and TCP checksums use open, well-known methods for calculating the checksum.Thus, in theory, someone could alter the packet and calculate the new, correct checksum. More importantly, though, the authenti- cation header provides end-to-end protection from changes for the IPv6 packet (as opposed to relying on Ethernet or TCP). It also provides additional benefits, such as anti-replay protection—anti-replay is a real threat, especially if someone uses a sniffer on the original conversation).
Q: In today’s Internet it is not unusual for packets to traverse different paths,
even between the same two endpoints.Wouldn’t this make it difficult for an IPv6 source node to effectively use MTU discovery and be sure they had correctly detected the smallest MTU?
A: While today’s packets do take different paths, it is unlikely this condition will
create a problem in the future. Packet sizes today are standardized at 1514 bytes, even in IPv6 environments. Should the MTU of Internet links increase (creating a possible MTU problem), it is likely all link MTUs would increase at approximately the same time (or at the very least, all links within an ISP). This would help to minimize the problem. If this is not the case, potential problems could occur, since intermediate routers do not have the ability to fragment a packet the way IPv4 routers do today.