The following is based on the configuration exercise 10-1: Configuring OSPFv6 Addresses and OSPF for IPv6 Routing, of the BSCI Authorized Self Study Guide.

Figure 1: IPv6 Addressing Configuration Exercise Topology

Task 1: Configure IPv6 globally on the routers and configure addresses on all interfaces.

• Use the following chart to configure the parameters:

• Dynamips/Dynagen .net configuration for the proceeding lab excercise.

[localhost]

    [[7200]]
        image = \\\\C7200.BIN
        # On Linux / Unix use forward slashes:
        # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image
        npe = npe-400
        ram = 160

    [[ROUTER P1R1]]
        Fa0/0 = P1R3 Fa0/0
        S1/0 = P1R2 s1/0
        model = 7200
        console = 2001
        idlepc = 0x6082d7a0

    [[router P1R2]]
        Fa0/0 = P1R4 Fa0/0
        model = 7200
        console = 2002
        idlepc = 0x607016a0

    [[router P1R3]]
        s1/0 = P1R4 s1/0
        model = 7200
        console = 2003
        idlepc = 0x607016a0

    [[router P1R4]]
        model = 7200
        console = 2004
        idlepc = 0x607016a0

Configure the following on all routers:

• Enable IPv6.
• Enable CEFv6.
• Configure IPv6 global address on all fa0/0 and s1/0 interfaces.

Here is an example of the configuration for P1R1

Figure 2: P1R1 Configuration

• IPv6 is enabled by configure the ipv6 unicast-routing global configuration command.
• Enable CEFv6 by configuring the ipv6 cef global configuration command.
  • This enables Cisco Express Forwarding (CEF) for IPv6, which is a Layer 3 IP switching technology for the forwarding of IPv6 packets. When CEFv6 is enabled, network entries that are added, removed, or modified in the IPv6 Routing Inforamtion Base (RIB), as dictated by the routing protocol in use, are reflected in the Forwarding Information Bases (FIBs), and the IPv6 adjacency tables maintain Layer 2 next-hop addresses for all entries that are in each FIB.
• Use the ipv6 address address/prefix-length [eui-64] interface configuration command.
  • The eui-64 paramater forces the router to complete the addresses’ low-order 64-bits using an EUI-64 format interface ID.

Verify that IPv6 has been configured on interface fa0/0:

Figures 3 & 4: Output of sh ipv6 interface command:

• Notice the highlighted link-local address that was automatically configured on the interfaces.
• Also notice the addresses that have been configured with the ipv6 address command, with the specified prefix and interface ID in EUI-64 format.

Task 2: Enable OSPF on all routers.

• Enable IPv6 OSPF on each router.
• Configure the router ID for each router, based on the chart above.
• Enable IPv6 OSPF in area 0 on all enabled FastEthernet and Serial interfaces.

Figure 5: IPv6 OSPF Configuration on P1R4

• Use the ipv6 router ospf process-id global configuration command to enable OSPFv3.
• A router ID must be configured using router-id router-id router configuration command.
• Use the ipv6 ospf process-id area area-id [instance instance-id] interface configuration command to enable OSPF for IPv6 on an interface.
  • The network area command used in OSPFv2 is not used in OSPFv3. Rather, interfaces are directly configured to specify which IPv6 networks are part of the OSPFv3 network.

Verification

Figure 6: Show IPv6 OSPF Interface

• The figure above shows IPv6 is enabled on all interfaces, with process ID 100 in area 0.

Figure 7: Show Ipv6 OSPF Neighbor

• Shows both neighbors of router P1R4.

Figure 8: Show IPv6 Route

• Displays the IPv6 routing table.

The next few posts should be the last of the remaining topics I need to cover before I go back and do a final review in preparation for the BSCI exam. I still haven’t decided when I’m going to take the exam though. I’m hoping by March 15th. Our second baby is due around mid-April so I need to make sure that I’ll be ready to take the test before that time arrives. Otherwise I’ll probably have to postpone my exam for a few more months – knowing that having a newborn and another one who will be 3 by then will surely put a strain on my studies. I may end up going for the composite exam if it were to go that route. And it’s an option I’ve been seriously considering. We’ll see how it goes.

I’ve been finishing up some lab exercises the last few days. Today was specially hard studying because my body is just aching from soreness all over. We just started our basketball league with old friends whom I’ve been ballin with for the last few years. It’s good way for me to keep in shape since, with all the studying I do, that really is the only physical activity I get to involve myself in. I’m hoping that in the next few weeks, I’ll get in better shape, which in turn will help with my stamina specially in those long study hours.  Ultimately, I’ll need all that stamina when the new baby arrives.

What time is it?

There are three main types of IPv6 addresses:

• Unicast
  • A packet sent to a unicast address is delivered to the interface identified by that address.
  • There are two defined types of unicast addresses:
    • Global Unicast
    • Link-Local Unicast
    • Site-Local Unicast, is a unicast type that has been deprecated (RFC 3879)
  • The IPv6 unicast address space encompasses the entire IPv6 address range, with the exception of the FFoo::/8 range, which is used for multicast addresses.
• Anycast
  • A new type of address that is assigned to a set of interfaces on different devices; identifies multiple interfaces.
  • A packet sent to an anycast address goes to the closest interface identified by the anycast address. The closest interfaces is determined by the routing protocol’ measure of distance.
  • Example: unicast address can be use for load balancing and content delivery services.
  • Anycast address syntax are indistinguishable from gloabl unicast addresses because anycast addresses are allocated from the global unicast address space.
• Multicast
  • Also assigned to a set of interfaces on a different node.
  • A packet sent to a multicast address is delivered to all interfaces identified by that address.

Broadcast Address

• There are no broadcast addresses in IPv6. Broadcasts are replaced by multicasts and anycasts.
• Mulitcast prevents most problems that occur with broadcast; such as broadcast storms in IPv4.

IPv6 Addressing Model

• All types of IPv6 addresses are assigned to interfaces, not nodes.
• An IPv6 unicast address refers to a single interface.
  • Since each interface belongs to a certain node, any interface on that node can be used with a unicast address as an identifier for that node.
• A single interface may be assinge multiple IPv6 addresses of any type (unicast, anycast, multicast).
• Every IPv6-enabled  interface must contain:
  • At least one loopback (::1/128).
  • and one local-link address.
• Optionally, a single interface may have multiple unique local and global addresses.

IPv6 Address Representation

• IPv6 addresses are written as hexadecimal numbers with colons between each set of four hexadecimal digits.
  • Each hexadecimal field is 16 bits.
• The format is:
  • x:x:x:x:x:x:x:x, where ‘x‘ is a 16-bit hexadecimal field.
  • This format is sometimes called “coloned hex” format.
• Following is an example address:

2035:0001:2BC5:0000:0000:087C:0000:0000A

There are 2 rules that apply to IPv6 address syntax to shorten the notation:

1. Any number of successive 0s (zeros) can be replaced with a pair of colons (::), once within an address.
   • A pair of colons can only be used once because an address parser identifies the number of missing 0s by separating the two parts and entering 0 until the 128 bits are complete. If two :: notations were used, there would be no way to identify the size of each block of 0s.
2. Leading 0s within each set of four hexadecimal digits can be omittted.
   • It is not necessary to write the leading 0s in an individual field, but there must be at least one numeral in every field, except for the case of the first rule where the successive 0s are replaced by “::“.

The address in the example above can be shortened as:

2035:1:2BC5::87C:0:A

IPv6 Address Interface Identifiers

• Interface Identifiers in IPv6 unicast addresses are used to identify unique interfaces on a link.
• They may be also be thought of as the “host portion” of an IPv6 address.
• Interface IDs are required to be unique within a link/subnet prefix.
  • They may also be unique over a broader scope.
  • The same interface ID may be used on multiple interfaces on a single node, provided that they are attached to different subnets.
• Interface IDs may be derived from their interface’s link layer address (MAC address). If so the scope of that ID is assumed to be universal (global).
• Note the uniqueness of interface identifiers is independent of the uniqueness of IPv6.
  • For example, a global unicast address may be created with a local scope interface identifier and a link-local address may be created with a universal scope interface identifier.
• Interface identifiers are always 64 bits and are dynamically created based on Layer 2 media and encapsulation.
• The most common type of Layer 2 address is the IEEE 802 MAC address used in Ethernet.
  • MAC addresses are 48 bits divided into two 24-bit blocks:
    • The upper 24 bits are called Organizationally Unique Identifier (OUI). Different organization have their preassigned OUI
    • The lower 24 bits are used as unique identifiers for the specific vendor hardware device.
  • Interface IDs are constructed in the EUI-64 format, based on the 48-bit MAC address and inserting the 16-bit FF:EE between the upper 3 bytes (upper 24 bits) and the lower 3 bytes (lower 24 bits.
    • The seventh bit in the high order byte of the resulting interface ID is set to binary 1 to indicate the uniqueness of the interface ID.
    • The seventh bit is refered to as the Universal/Local (U/L) bit.
    • This bit identifies whether this interface is locally unique on the link or whether it is universally unique.

• The following shows the process of converting to EUI-64:
  • Focusing on the upper above, you take the first 3 bytes (OUI portion) of the Ethernet address and arrange it to the left of the interface ID.
  • The lower 3 bytes (vendor code) is arranged to the right of the interface ID.
  • Right in the middle, insert the 16-bit hexadecimal of FF:EE (or 1111 1111:1111 1110 in binary).
• To convert to Modified EUI-64:
  • Change the 7^th bit of the first byte (the U/L bit) from 0 to 1.
  • The eighth bit in an IPv6 interface identifier, also known as the “G” bit, is the group/individual bit for managing groups.

IPv6 Global Unicast Address

• The IPv6 global aggregatable unicast address, aka the IPv6 global unicast address is the equivalent of the IPv4 global unicast address.
• A global unicast address is an IPv6 address from the global unicast prefix.
• The global unicast address typically consists of:
  • A 48-bit global routing prefix,
  • A 16-bit subnet ID or Site-Level Aggregator (SLA),
  • And a 64-bit interaface ID (typically in EUI-64 bit format).

• Except for addresses that start with 000, all global unicast addresses have a 64-bit interface ID
• Addresses with prefix of 2000::/3 (binary 001)through E000::/3 (binary 111), excluding the FF00::/8 (binary 1111 1111) multicast addrsses, are required to have a 64-bit EUI-64 address format.
  • The IANA allocates the IPv6 space in the range of 2001::/16 to the registries.
• A 16-bit subnet field called the subnet ID could be used by inidividual organizations to create their own local addressing hierarchy and to identify subnets. A subnet ID is similar to a subnet in IPv4, except that an organization with an IPv6 subnet ID can support up to 65,535 individual subnets.

IPv6 Link-Local Unicast Address

• Link-local addresses have a scope limited to the local link. They refer only to a particular physical link/network.
• They are typically used for special purposes such as address resolution or neighbor discovery. The equivalent IPv4 address is the 169.254.0.0/16 auto-configured address when no DHCP is available.
• They are dynamically created on all IPv6 interfaces by using a specific link-local prefix FE80::/10 and a 64-bit interface identifier.

• Nodes on a local link can use link-local addresses to communicate. The nodes do not need globally unique addresses to communicate.
• IPv6 routers must not forward packets that have link local source and destination addresses to other links.

IPv6 Anycast Addresses

• An IPv6 address is a global unique address that is assigned to more than one interface.
• A packet sent to an anycast address is delivered to the closest interface – as defined by the routing protocols in use – identified by the anycast address.
• Anycast addresses are allocated from the unicast address space, using any of the defined unicast address formats.
  • Essential, anycast addresses are same unicast addresses assigned to more than one interface.
  • The nodes to which the addresses are assigned must be explicitly configured to know that it is an anycast address.
• An anycast address must not be used as the source address of an IPv6 packet.
• An anycast address must not be assigned to an IPv6 host – only assign to IPv6 routers.

IPv6 Multicast Addresses

• Mulitcast addresses are defined by the prefix FF00::/8.
  • The first octet consists binary 1111 1111.
  • The next octet consists of the Flag and Scope parameters.

• The Flag parameter consist of 4 bits. Each bit is defined as follows:
  • Bit 1 = 0; reserved
  • Bit 2 = R flag; Rendezvous Point flag
  • Bit 3 = P flag; Indicates if address is based on unicast prefix.
  • Bit 4 = T flag; 0 if address is permanent; 1 if temporary.
• The Scope parameter is a 4 bit scope, with values as follows:
  • 1 = Interface-Local scope
  • 2 = Link-Local scope
  • 4 = Admin-Local scope
  • 5 = Site-Local scope
  • 8 = Organization-Local scope
  • E = Global scope
  • An example, FF02::/16 is a permanent multicast address with a link-local scope.
    • Binary is: 1111 1111 0000 0010
    • The second to the last bit (= 2) indicates a Link-local scope.
    • The 0 in the T Flag indicates it is permanent.
• The multicast address FF00:: to FF0F:: have the “T” flag set to 0 and are reserved. Some common examples of the assigned addresses are:
  • FFO2::1 – All nodes on a link (link-local scope)
  • FF02::2 – All routers on a link
  • FF02::5 – All OSPFv3 routers
  • FF02::6 – All OSPFv3 DR routers
  • FF02::9 – All RIP routers on a link
  • FF02::1:FFXX:XXXX – Solicited-node multicast on a link, where XX:XXXX is the rightmost 24 bits of the corresponding unicast or anycast address of the node. This is similar to ARP in IPv4.

• The multicast Group ID consists of the lower 112 bits of the multicast address.

Resources:

1. RFC 4291: IP version 6 Addressing Architecture
2. TCP/IP Guide – IPv6 Identifiers and Physical Address Mapping
3. RFC 3587: IPv6 Global Unicast Address Format
4. IPv6 Addressing at a Glance – Cisco Technology Whitepapers
5. IPv6 Multicast at a Glance – Cisco Technology Whitepapers

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BSCI course, consider purchasing Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition) by Diane Teare and Catherine Paquet; as well as following the links on the resources section of this entry.

I’ve just spent the last hour poring over some of the latest threads in the techexams.net forum. and networking-forum.com. I’ve been a member of these forums for just about a year now. Anyway, I’m supposed to be studying but somewhere along the way between googling about IPv6 interface ID and CCIE, I ended up reading some success stories in the forums.

I couldn’t help but feel like I’m so far away from my goal and it almost seems so easy to just give up. Reading about some of the stories of the latest CCIE candidates who have passed their exams, both in the blog world and the forums, is ironically, both inspiring and exhausting. Inspiring in a way that it motivates me to just want to hit the books even harder and exhausting in a way that I know there is so much work to be done and I’m barely scratching the surface. But at this moment in time, right now, it feels like it’s so tiring to just think about this whole quest (might have something to do with the fact that I had another long day at work today, my son is sick and being a little un-cooperative this evening, and it’s almost 1am).

It’s funny because just the past few days, as I was reading/posting about some of the few CCIE examinees that just passed, I was pretty motivated and uplifted. Reading about their struggles and accomplishments re-invigorated my desire. And my desire was turning into pure motivation. I guess somehow my ever-expanding tendency for instant gratification (from instant answers from google and up-to-the-minute updates on everything in my newsfeeds ) is skewing the reality that attaining something of value can’t be had that easily; that because I want something so bad and can’t have it as quickly as I would like is screwing  with the reality that I’m know – the reality of instant answers and instant updates.

Or maybe I just need to go to sleep…

I’ve been poring through pages and pages of RFC documents pertaining to my studies. I usually find them bland, boring, and just plain hard to read. Every now and then I have to remind myself that these authors are actual human beings capable of exhibiting basic human functions and emotions. And yes, they are kinda funny too:

RFC 1925
Network Working Group                                  R. Callon, Editor
Request for Comments: 1925                                          IOOF
Category: Informational                                     1 April 1996

                      
The Twelve Networking Truths



Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   This memo documents the fundamental truths of networking for the
   Internet community. This memo does not specify a standard, except in
   the sense that all standards must implicitly follow the fundamental
   truths.

Acknowledgements

   The truths described in this memo result from extensive study over an
   extended period of time by many people, some of whom did not intend
   to contribute to this work. The editor merely has collected these
   truths, and would like to thank the networking community for
   originally illuminating these truths.


. Introduction



   This Request for Comments (RFC) provides information about the
   fundamental truths underlying all networking. These truths apply to
   networking in general, and are not limited to TCP/IP, the Internet,
   or any other subset of the networking community.


. The Fundamental Truths



   (1)  It Has To Work.

   (2)  No matter how hard you push and no matter what the priority,
        you can't increase the speed of light.

        (2a) (corollary). No matter how hard you try, you can't make a
             baby in much less than 9 months. Trying to speed this up
             *might* make it slower, but it won't make it happen any
             quicker.

Callon                       Informational                      [Page 1]

 
RFC 1925            Fundamental Truths of Networking        1 April 1996

   (3)  With sufficient thrust, pigs fly just fine. However, this is
        not necessarily a good idea. It is hard to be sure where they
        are going to land, and it could be dangerous sitting under them
        as they fly overhead.

   (4)  Some things in life can never be fully appreciated nor
        understood unless experienced firsthand. Some things in
        networking can never be fully understood by someone who neither
        builds commercial networking equipment nor runs an operational
        network.

   (5)  It is always possible to aglutenate multiple separate problems
        into a single complex interdependent solution. In most cases
        this is a bad idea.

   (6)  It is easier to move a problem around (for example, by moving
        the problem to a different part of the overall network
        architecture) than it is to solve it.

        (6a) (corollary). It is always possible to add another level of
             indirection.

   (7)  It is always something

        (7a) (corollary). Good, Fast, Cheap: Pick any two (you can't
            have all three).

   (8)  It is more complicated than you think.

   (9)  For all resources, whatever it is, you need more.

       (9a) (corollary) Every networking problem always takes longer to
            solve than it seems like it should.

   (10) One size never fits all.

   (11) Every old idea will be proposed again with a different name and
        a different presentation, regardless of whether it works.

        (11a) (corollary). See rule 6a.

   (12) In protocol design, perfection has been reached not when there
        is nothing left to add, but when there is nothing left to take
        away.

Callon                       Informational                      [Page 2]

 
RFC 1925            Fundamental Truths of Networking        1 April 1996

Security Considerations

   This RFC raises no security issues. However, security protocols are
   subject to the fundamental networking truths.

References

   The references have been deleted in order to protect the guilty and
   avoid enriching the lawyers.

Author's Address

   Ross Callon
   Internet Order of Old Farts
   c/o Bay Networks
   3 Federal Street
   Billerica, MA  01821

   Phone: 508-436-3936
   EMail: rcallon@baynetworks.com

Head over to cciecandiate.com and congratulate Carl Burkland CCIE# 23394

He is the 3rd contributor for ccciecandidate.com to pass the CCIE lab on his first attempt. It started with Ethan Banks, followed by Keith Tokash, and just recently Carl Burkland. There certainly is an enviable pattern of success going on over there.

So to all my faithful readers, this is my last post on this blog. I’ll be heading over to cciecandidate.com and be a mainstay on that site.

Just kidding!

• Internet Protocol version 6 (or IPv6) is designed to succeed the currently dominant Internet Protocol version 4 (IPv4).
• It is defined in RFC 2460: Internet Protocol, Version 6 (IPv6) Specification.
• The changes from IPv4 to IPv6 fall primarily into the following categories:
  • Expanded Addressing Capabilites
    • The IPv4 IP address size is 32 bits. Compared to that, IPv6 address size is 128 bits.
    • The large address space provided by IPv6 allows for several benefits such as:
      • Improved global reachability and flexibility
      • Aggregation of prefixes that are announced in the routing table
      • Easier multihoming ability with multiple ISPs
      • Simpler auto-configuration of addresses
      • End-to-end communication without the need for NAT
      • Easier address renumbering and modification
  • Simplified IP Header
    • Some IPv4 fields are dropped and made optional.
    • Better routing efficiency and performance.
    • Simpler header mechanisms.
  • Flow Labeling Capability
    • Flow labels for per-flow processing with no need to examine the transport layer information to identify various traffic flows.
    • A new capability to enable the labeling of packets belonging to particular traffic “flows” for which the sender requests special handling, such as non-default quality of service or “real-time” service.
  • Authentication and Privacy Capabilities
    • IPSec is mandatory in IPv6.
    • IPSec is enabled and available for use on every IPv6 node, which provides more secure Internet experience.
    • IPSec also requires keys for each device, which implies global key deployment and distribution.
  • Support for Mobility
    • Mobile IP enables mobile devices to move without breaks in established network connections.
    • Mobility is built in, which means that any IPv6 node can use it when necessary.
    • The routing headers of IPv6 makes mobile IPv6 much more efficient for end nodes than mobile IPv4 does.

IPv6 Address Space

• IPcv6 increases the  number of address bits by a factor of 4 – from 32 bits to 128 bits.
• With 32 bits, IPv4 allows for 4,294,967,296 addresses – about 2 billion are usable.
• With 128 bits, IPv6 allows for approximately 3.4 x 10³⁸.
  • Note, however, that increasing the number of bits for the address also increased the IPv6 header size.
  • The header fields that contain the IPv6 address is 256 bits (source and destination bits combined) in size. Compare that to 64 bits in IPv4 (32bit-source address + 32bit-destination address).

IPv6 Packet Header

• The IPv6 headers has 40 octets, compared to the 20 octets in IPv4 header.
• IPv6 has fewer fields, and the header is 64-bit aligned to enable fast, efficient, hardware-based processing.
• The IPv6 address fields are four times larger than in IPv4.
• The following illustration compares the IPv4 and IPv6 headers:

• Note that the IPv6 (main) header displayed above is an illustration of the basic structure of the header,  differentiated from “IPv6 extension headers” to be described shortly.
• Notice that although IPv6 has increased its address size (source & destination fields) by 4 times, the main header is designed for a more  simplified format.
• One of the important changes is the absence of familiar fields from the previous IP version such as:
  • Internet Header Length (IHL)
  • Service Type
  • Identification
  • Flags
  • Fragment Offset
  • Header Checksum
  • Options and Padding
• The following describes the various fields in the new IPv6 header:
  • [4-bit] Version
    
    • Bit size the same as IPv4.
    • The value of this field is 6, to describe version 6.
  • [8-bit] Traffic Class
    • Similar to Type of Service (ToS) in IPv4. Functionality is the same between the two versions.
    • This field used to represent the priority (read QoS) by which packets are delivered.
  • [20-bit] Flow Label
    • New for IPv6.
    • Used by the source of the packet to tag the packet as being part of a specific flow. For example, a packet’s sender can specify a series of packets, say VoIP packets, as a flow. It can then request particular service for this flow.
    • This mechanism allows multilayer switches and routers to hand traffic on a per-flow basis rather than per-packet, for faster packet-switching perfomance.
    • Can also be used for QoS.
  • [16-bit] Payload length
    • Replaces the Total Length field present in the IPv4 header.
    • As opposed to the IPv4 where it measures the total length of the whole packet, in IPv6 it only measures the number of bytes of payload. In other words, it measures the whole packet minus the 40 bytes of the main header.
  • [8-bit] Next Header
    • Similar to the protocol field in the IPv4 header.
    • It can be a trasnport-layer packet, such as TCP or UDP, or it can be an extension header.
    • It has two uses:
      1. If the datagram has extension headers, this field specifies the identity of the first extension header (which is the next header in the diagram).
      2. If it’s just the main header and no extension headers, it serves the same purpose as the old IPv4 protocol and has the same values.
  • [8-bit] Hop Limit
    • This is similar to the TTL field in the IPv4 header -  a more appropriate name since the TTL is really more about the number of hops than a measure of time.
    • Each router decreases this field by one, just like in IPv4.
    • Because there is no checksum in the IPv6 header, an IPv6 router can decrease the field without recomputing the checksum. Recomputation costs processing time.
    • If this field ever reaches 0, a message is sent back to the source of the packet and the packet is discarded.
  • [128-bit] Source Address
    • The originator of the packet.
  • [128-bit] Destination Address
    • The intended recipient of the packet.
  • The basic IPv6 header consists of 320 bits, or 40 bytes, or 40 octets.
  • Extension Headers
    • These are optional information that are placed between the IPv6 header and the upper layer header in a packet. They are discussed below.
• The most significant deletion in IPv6 is the IPv4 header checksum field. Because link-layer technologies perform checksum and error control and are considered relatively reliable, an IP header checksum is considered redundant.
  • Without the IP header checksum, upper-layer checksums, such as UDP, are mandatory with IPv6.

IPv6 Extension Headers

• IPv6 extension headers follow the main header and preced the protocol header and the payload fields in IPv6 packets.
• The Next Header field indentifies the type of header following the main IPv6 header.
• These fields are used for special purposes  to provide flexibility. They are only added when they are needed.
  • By having these fields, they are only attached when there is a need for it, and they are not used when not needed. This allows the main header to remain small when the extension headers are not required for any special purposes.
• Generally, extension headers are not examined or processed by any node other than the node to which packet is destined.
  • The one exception is the hop-by-hop options header, which must be examined and processed by every node along a packet’s delivery path, including the source and destination nodes
• The following is a list (in order) and description of the functions of each extension headers, following the main IPv6 header:
  • Hop-by-hop Options Header
    • When used, this header is processed by every node it passess.
    • Identified by a Next Header value of 0 in the IP6 header.
    • Example uses are for a Router Alert, including for Resource Reservation Protocol (RSVP) and Multicast Listener Discovery (MLD) messages.
  • Destination Options Header
    • Used to carry information that need to be examined only by the node where packet is destined.
      • Or each destination specified by a routing header.
    • Identified by a Next Header value of 60 in the IPv6 header.
    • They follow any hop-by-hop option headers.
    • Alternatively, it can follow any Encapsulating Security Payload (ESP) header, in which case the destination options header is processed only at the final destination.
    • An example where this can be used is Mobile IPV6.
  • Routing Header
    • Used by an IPv6 source to list one or more intermediate nodes to be “visited” on the way to a packet’s destination.
    • Identified by a Next Header value of 43.
  • Fragment Header
    • Used by an IPv6 source to fragment a packet that is larger the maximum transmission unit (MTU) for the path between itself and a destination device.
      • Unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers along the packet’s path.
      • To send a packet that is too large to fit in the MTU of the path to its destination, a source node may divide the packet into fragments and send each fragment as a separate packet. The receiver re-assembles the packet.
      • The fragment header is used in each fragmented packet.
    • Identified by a Next Header value of 44.
  • Authentication Header and Encapsulating Payload Header
    • Next Header values:
      • AH = 51
      • ESP = 50
    • Used within IPSec to provide authentication, integrity, and confidentiality of a packet.
    • Identical for both IPv4 and IPv6.
  • Upper Layer header
    • Typical headers used inside a packet to transport data.
    • Two main protocols (with Next Header values) are:
      • TCP = 6
      • UDP = 17

MTU Discovery

• In IPv6, upper layers are encouraged to avoid sending messages that require fragmentation.
• IPv6 routers no longer perform fragmentation. Only the source can now do fragmentation; nor routers.
• Since routers cannot fragment datagrams, a feedback process has been defined using ICMPv6 that lets routers tell source devices that they are using datagrams that are too large for the route.
  • In this process, source IPv6 devices attempt to send packet at the size specified by upper IP layers, such as transport and application layers.
  • If the device receives an ICMPv6 “packet too big” message, it retransmits the MTU discover packet with a smaller MTU. This process is repeated until the device receives a response that the discover packet arrived intact. The device then sets the MTU for the session.
• IPv6 has a minimum size of  1280 bytes. In IPv4, routers and physical links were required to handle a minimum MTU size of 576 bytes.

Resources:

1. RFC 2460: Internet Protocol, Version 6 (IPv6) Specification
2. TCP/IP Guide.com – Internet Protocol version 6
3. RFC 1981: Path MTU Discovery for IP version 6
4. RFC 4302: IP Authentication Header
5. RFC 4303: IP Encapsulating Security Payload (ESP)
6. IPv6 Headers at a Glance – Cisco Technology Whitepapers

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BSCI course, consider purchasing Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition) by Diane Teare and Catherine Paquet; as well as following the links on the resources section of this entry.