Figure 14-6 illustrates one reason IPv6’s designers wanted to eliminate NAT.
Figure 14-6 Embedded IP Addresses Before and After NAT
Some applications embed the source and destination addresses within the data portion of the packet. If the source and destination addresses are translated, the addresses in the header and the data portion of the packet no longer work, and the application will not work correctly.
NAT implementors have largely learned how to mitigate these changes, but NAT deployments can still sometimes be messy.
IPv6’s designers also wanted to eliminate NAT to increase path visibility through the entire Internet. Translating the source and destination addresses makes it more difficult for network operators to trace the path of a packet from source to destination.
As with autoconfiguration, NAT has proven more challenging to eliminate than IPv6’s designers anticipated. A stateless NAT form, NAT66, is still widely available for IPv6 networks.
IPv6 Packet Format
The IPv6 packet header is simpler than the IPv4 packet header.
Figure 14-7 illustrates.
Figure 14-7 The IPv6 Header
The most apparent difference between the IPv6 and IPv4 headers is all the fragmentation fields, including identification, flags, and fragment offset, are missing. Routers cannot fragment IPv6 packets, so removing these fields from the header makes sense.
A host can use the flow label to identify a group or stream of related packets.
IPv6 uses the hop limit to limit the number of times a packet can be forwarded—just like the IPv4 TTL.
The next header field indicates either the type of protocol data carried in this packet—UDP, TCP, etc.—or the kind of extension header following this header. IPv6 extension headers extend the protocol’s capabilities, as shown in Figure 14-8.
Figure 14-8 IPv6 Extension Headers
IPv4’s protocol type field can contain only a protocol. Because of this, there is no easy way to extend IPv4 headers to include tunneling information, processing instructions to routers, etc.
On the other hand, IPv6’s next header can describe an extension header or a protocol type. Hosts can chain multiple extension headers onto the IPv6 header. Routers process information carried in the hop-by-hop header, and hosts process information carried in the destination header.
Routers process only the hop-by-hop header.
User Datagram Protocol
User Datagram Protocol (UDP) provides a connectionless transport service for carrying data across an IP network.
Connectionless versus Connection-Oriented Transport
Protocols
Table 14–2 describes the differences between a connectionless transport and connection-oriented transport.
Table 14-2 Connectionless versus Connection-oriented Transport Protocols
As a connectionless protocol, UDP offers very few services; the transmitter puts data into UDP-encapsulated segments, puts these segments into IP packets, and sends them.
Connectionless protocols are useful for
• Short, single-packet transmissions, such as the Domain Name Service (DNS).
• Streaming applications, like voice or video, where a single lost or corrupted packet of information can easily be ignored, and by the time missed information is retransmitted, it would not be valuable.
• When a transmitter wants more than one host to receive the packet (such as multicast and broadcast).
Note
Chapter 2, “Addresses, ” describes multicast and broadcast.
Note
Chapter 16, “Names and Time, ” describes DNS.
The UDP Header
UDP has a simple header, shown in Figure 14-9.
Figure 14-9 The UDP Segment Header
UDP uses the source and destination ports to determine which application or service should receive this data. The length describes the amount of data this segment carries in octets.
Checksums
Many computer network protocols use a checksum to determine whether data has been changed in transit. Transmitters use a formula or process to calculate a checksum when sending a packet, placing the result into a field in the packet.
Receivers also use the same formula or process to calculate a checksum. If the receiver’s calculated result matches the one the transmitter stored in the packet, the data has not been changed. If these two calculations do not match, the data has been changed.