IPv6 From the Ground Up : Part - I Contd.......

From RFC2460, the following information jumps out at you immediately:

- IPv6 is supposedly a succesor to IPv4 (RFC 791). It's uptake (at least in kenya) is a bit discouraging though I get the feeling this will be forced on networks when V4 resources run out.
-Expands the address size from 32 to 128 bits supporting more levels of addressing, more addressable nodes and autoconfiguration. Multicast routing is scaled by using 'scope' and a new address called anycast is defined.
-Header format is simplified to make the packet handling better and limit bandwidth costs.
-Improved support for extensions and other improvements. IPv6 has less stringent limits on length of options.
-another key thing is extension support for authentication and other privacy measures eg confidentiality and integrity can be extended on the header.
-flow labelling capability takes qos to a whole /nother level. eg you can label a flow for which the sender requests special handling eg real time traffic.

IPv6 Header Format as seen on the rfc - modified by my notes:

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Version-4bits|Traffic Class|           Flow Label              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Payload Length        |  Next Header  |   Hop Limit   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                                                               +
 |                                                               |
 +                         Source Address                        +
 |                                                               |
 +                                                               +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                                                               +
 |                                                               |
 +                      Destination Address                      +
 |                                                               |
 +                                                               +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Extension headers:
Optional information is encoded in separate headers placed between the IPv6 header and the upper layer header. this have to be identified by a distinct header value.

• Headers are not processed until they reach the destination/s. As such a node has to process extension headers strictly in the order they appear in the packet.
• if the hop-by-hop header , which must be immeadeately following the IPv6 header is present, then it will be processed by all nodes. its presence is indicated by a value zero (0) in the next field header.
• ICMP code 1 is sent to a sender if a parameter is not understood ie unrecognized. the same is apparently sent to a packet originator if a value zero is found on any header other than the IPv6 header.
• If more than one extension header is used, there's a specific order they should appear in. (please read the rfc) i definately don't expect this on an exam. However, IPv6 header, hop by hop options, Destination options, routing and fragmentation followed by authentication, encapsulation and security and a destinations headed then an upper layer header is what's listed.
• Note the two destinations, one is the final destination and the other is the destination listed in the routing header. ie (once before a Routing header and once before the upper-layer header) That still does confuse me.
• IPv6 will accept extension headers in any order apart from the hop-by-hop optiones one that has to follow the IPv6 header.
• A destination header is not examined or processed until it reaches the node identified in the Destination Address field of the IPv6 header.
• Note, the frgment header is just like in IPv4 used to send a packet larger than the path mtu. However this is only done by the source nodes not routers along the path. the value identifying it is 44.
• each fragment will have an unfragmentable part, a fragment header and the fragment itself. The unfragmentable part has the payload length of the original v6 header changed to contain the fragmented packet length only, the fragment header id's the first header of the fragmentable header of the original packet. Then obviously the fragment lengths must have a resulting MTU of the path being taken to the destination.
• For reassembly, the packets must have the same source & destination address and fragment identification
• note, the fragment header doesn't show up in the final reassembled packet.
• IPv6 requires that the MTU on each link be either equal to or more than 1280 octets. and fragmentation and or reassembly must be procided by a layer below the IPv6.
• its recommended that IPv6 nodes implement PMTU.
• IPv4 ttl is renamed to hop-limit . this is because IPv6 nodes are not required to enforce a packets lifetime. applications curently relyin gon the internet layer for ttl purposes have to be upgraded to have a mechanism to detect and discard obsolete packets

Im not generally a fan of RFC's but for topics I don't understand, I'd rather start from there and work out towards the actual configuration with some sound theories behind me...(there's the added fact that Im out of books budget and RFC's are pretty much the source of most info)

further reading:

Authentication 
Encapsulating Security Payload