You may ask, "Why do we need a new protocol?" As you will see, this isn't a completely new protocol -- it's been...
developed on the strengths of IPv4. In this series Silvia Hagen examines IPv6.
When IPv4 was developed over 30 years ago, the creators had no idea what the Internet would look like in the future. This new protocol builds on the strengths of IPv4 and contains everything that was proven to be good and stable in IPv4 and extended it to meet the needs of the future Internet. You will be happy to realize that you do not need to remove IPv4 from your network. There will be a long transition period and we will have both protocols on our networks for some time. All sorts of transition mechanisms have been defined to make this transition smooth and the coexistence peaceful.
Here's a bit of IPv6 history:
|Early 90s||The IETF (Internet Engineering Task Force) wants to develop a successor protocol to IPv4|
|1993||The IETF starts the IPng Area (IP next generation)|
|1994||The IPng Area directors recommend IPv6 (RFC 1752)|
|1998||The core set of IPv6 becomes IETF draft standard|
Overview of main changes between protocols
- Extended address space: The most obvious change is the newly extended address space, which was the driving reason to develop IPv6 in the first place.
- The new address has 128 bits, which gives us space that can be used to create the hierarchical addressing system and provide plenty of IP addresses for everyone and all devices that need an IP address in the future.
- Expanded auto configuration mechanisms: IPv6 has auto configuration mechanisms that will make our work as network engineers a lot easier. With auto configuration you can install plug and play machines without needing to configure IP addresses. It's now also much easier to re-number the networks.
- Simplification of the header format: It has a simplified header format, which has fixed length of 40 bytes. Options are now inserted as extension headers only if needed. Extension headers are placed after the IPv6 header.
- Extensions for authentication and privacy (security)
Flow labelling capability (QoS – Quality of Service)
The Structure of the IPv6 Protocol
General header structure:
The general header structure of IPv6 is specified in RFC 2460 and has a fixed-length of 40 bytes:
- 16 bytes for source address
- 16 bytes for destination address
8 bytes for general header information
Changes in the general header structure:
Five fields have been removed from the IPv4 header:
- Header Length (fixed length header doesn't need it)
- Fragment Offset
- Header Checksum (checked at the transport layer)
Three fields have been renamed and modified from the IPv4 header:
- Traffic Class (type of service in IPv4)
- Next Header (protocol type in IPv4)
- Hop Limit (Time to live in IPv4)
One field has been added:
- Flow Label (still under discussion at IETF)
This is a snapshot of the fields in an IPv6 header. The biggest part of the header are the source and destination address information - this lean header makes forwarding of an IPv6 packet much more efficient.
Next header field
The "Next Header" field is one byte, called 'Protocol Type' in IPv4 and it's basically used the same way. If the next header is TCP or UDP, the field contains the same protocol numbers as with IPv4.
If extension headers are used with IPv6, this field contains the type of the first extension header. Extension headers are located between the IP header and the TCP or UDP header.
Values in the 'Next Header' field
You can see some values that you are familiar with, like 6 for TCP or 17 for UDP. Two new values are value 41 for IPv6 and value 43 for a routing header. Value 44 is a fragmentation header, which is also a new extension header. In IPv4 the fields for fragmentation were in the IPv4 header. The advantage of dealing with fragmentation in an extension header is that the extension header is only there if fragmentation is necessary.
The extension header routers
These two diagram note value 50 and 51 for security and authentication extension headers. Value 58 is ICMPv6.
This trace file shows the IPv6 header in a trace file. It shows only one packet. The summary line displays the source and the destination address as well as a summary line identifies the type of packet (Echo.) In the lower portion of this diagram the IPv6 header is opened up to show you what it looks like in a trace file. You see the version number 6, and the next header field in the middle of the detail field contains the value 58 for ICMPv6. You see the hop limit of 128 and the source destination address. This is what an IPv6 address looks like. Pretty cool, isn't it?
Options in IPv6 are handled in an extension header. The good thing about extension headers is that they can be inserted if they are needed, but not inserted if they're not needed. In IPv4 we had options within the IPv4 header, so a router would always have to go into the IPv4 header and check if there were options. That's not necessary in IPv6 because the router can see whether there are extension headers that need to be examined or not. Here's a short list of the main extension headers that have been defined so far.
The current IPv6 specification defines six extension headers:
- Hop-by-hop options header
- Routing header
- Fragment header
- Destination options header
- Authentication header
- Encrypted security payload header
Headers one through four are defined in the basic IPv6 RFC 2460. Header five and six relate to security and authentication and each have their own RFC. The authentication extension header is RFC 2402 and the encrypted security payload is RFC 2406. One of the neat things about extension headers is that in the future if the need for new extensions arises, they can be added.
Extension headers (cont.)
This picture shows you how the extension header fits into an IPv6 packet. The first line you have the basic IPv6 header with no extension headers. In this case, the TCP header follows right after the IPv6 header. The IPv6 header contains the next header value of six that says it is TCP/IP. The second line shows the packet that has a routing header inserted. In this case, the IPv6 header has a value of 43 indicating that the next header will be a routing header. The next header is a routing header and it contains the value six in the next header field. So after the routing header, we know we will have a TCP header. And the last line shows how different extension headers can be piled up on each other and how more than one header can be between the IPv6 header and the TCP header. In this case we have an IPv6 header, next a routing header and than a fragment header and finally the TCP header.
Usually extension headers are examined by the destination node only. The hop-by-hop options header is an exception to this rule and carries optional information that must be examined by every node along the path of the packet. It has a Next Header value of zero. An example of why the hop-by-hop header would be used is if you use a Router Alert (RFC 2711) for RSVP (resource reservation protocol.)
The Routing Header is used to give a list of one or more intermediate nodes that should be visited on the packet's path to its destination. It is identified by a next header value of 43.
The routing header in a trace file
This diagram shows a routing header in a trace file. We have the source and destination address in the summary line. You see the details of the IPv6 header which as been opened to view the details.
You see version 6 for IPv6 than you see next header value 43 which is decoded by Sniffer as being a routing header. The hop limit is set to 128 -- source and destination address can be seen, which are the regular fields of the IPv6 header. Next is the routing header. You see the format of the routing header -- and the next header value of 58 that says after this routing header we will have an ICMPv6 header. Then you see the segments left field which has a value of one and this field tells you how many values are in the option part of this extension header. In this case we should have one routing entry that indicates there is one node that needs to be visited on this packets' path. On the last line you finally see the address of the node to be visited that is 2002:3e02:577f::3e02:577f. That is the route that has been entered. It could contain a number of routes - the segments left field would contain the number of routes that have been entered. And by the way, the (Loose) decode that you see is not according to the newest standard, it's just an outdated decode and those fields need to be set to zero (as they are.)
The fragment header is used to handle fragmentation. Fragmentation happens when packets have to be sent over links that have an MTU (Maximum transmission unit) smaller than the packet size. In this case the packet is sliced into fragments that fit the MTU. The fragments are reassembled at the destination. There is one big change with fragmentation in IPv6 -- routers do not fragment packets anymore. The next header value 44 identifies the fragment header.
The fragment header in a trace file
In this picture you can see four packets and the IPv6 header in the lower part of the picture. You see the value 44 which is highlighted that indicates that the next header will be a fragment header. You also see the source and destination address and then the fragment header. Again this is an ICMPv6 packet so the fragment header contains the value 58 in the next header field. And you also see fields that you should be familiar with in an IPv4 header. It has the offset that is zero because it is the first packet in the fragment set. You also see the more fragment field indicating there will be more fragments to follow. Next is an identification field that is used by the destination host to reassemble the packets. All packets that belong to one fragment set will have the same value in the identification field. In the last packet of this fragment set, the offset will be non-zero and the last fragment field contains the value zero, indicating that this is the last packet in the fragment set. The destination host now knows that it received all fragments and starts reassembly of the packet.
This is the detail on the last fragment in the packet set. All the values are basically the same with three differences - this is now the first packet, in the last packet it was zero. Here we have an offset and we have the value zero in the last fragment field indicating that it is the last packet of our fragment set. The identification is one because the two packets belong to the same set.
The destination options header is used to carry optional information that is examined by the destination node only and it is identified by a next header value of 60
An example for the use of a destination options header and a routing header would be mobile IPv6. Our networks are becoming more and more mobile and wireless. So there is a need to define mobile IPv6. Both the routing header and the destination options headers are used with Mobile IPv6 to ensure applications don't lose their TCP connection while a user is roaming from one network to another. Mobile IP uses home agent, home address, and care-of address.
For information about Mobile IPv6, refer to http://www.ietf.org/internet-drafts/draft-ietf-mobileip-IPv6-19.txt (Oct. 2002)
This concludes part one of Getting ready for IPv6. Click here for part two on IPv6 addressing.
Silvia Hagen has been in the networking industry since 1990, and became a CNE and CNI in 1992. She began her career as a successful instructor, and has trained hundreds of system engineers. Today she is CEO of Sunny Connection AG in Switzerland and works as a senior consultant and analyst for many mid-size and large sized companies. Her expertise is in Directory Services and Protocol Analysis. She is the author of the successful book 'Novell's Guide to Troubleshooting TCP/IP,' published by Wiley & Sons and 'SLP - Guide to Service Location Protocol,' published by Podbooks. Her newest book 'IPv6 Essentials' was published in August 02 by O'Reilly. She also presents internationally on various networking topics for Universities, Novell's Brainshare, NetWare Users International Conferences and also offers customized corporate presentations. For more details and contact information visit her Web site at http://www.sunny.ch.