IPv6 Foundation Part 3: IPv6 Headers & Extension Headers

IPv6 Foundation Part 3 - IPv6 Headers and Extension Headers
How do IPv4 and IPv6 Head­ers look like? What are IPv6 Exten­sion Head­ers and why we need them? Find the answers and more right here!

Table of Con­tents

About this course

So you are inter­est­ed in IPv6, which is absolute­ly great!

IPv6 is not only the future of net­work­ing, it is already here today! All the big play­ers on the Inter­net are already IPv6 enabled and it is now time for you to join the par­ty!

This course cov­ers all major aspects of the new Inter­net Pro­to­col and what changed, com­pared to IPv4. You will under­stand the fun­da­men­tals and be ahead of your peers that are still on the sink­ing ship of IPv4! As of today, there are no IPv4 address­es left and we have no oth­er option but to go ahead and deploy IPv6.

IPv6 Act Now

IPv6 Foun­da­tion Part 3: IPv6 Head­ers & Exten­sion Head­ers

The IP pack­et head­er has sim­i­lar­i­ties and dif­fer­ences between the two pro­to­col ver­sions 4 and 6. Let’s have a look.

How to IPv4 Head­er is set up

First, let’s do a quick recap of the IPv4 pack­et head­er and the dif­fer­ent fields:

Off­set Octet 0 1 2 3

Octet

Bit

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

0

0

Ver­sion

IHL

DHCP

ECN

Total Length

4

32

Iden­ti­fi­ca­tion

Flags

Frag­ment Off­set

8

64

Time To Live

Pro­to­col

Head­er Check­sum

12

96

Source IP Address

16
128
Des­ti­na­tion IP Address
20
160

Options (if IHL > 5)

About the IPv4 Head­er Ver­sion Field

The first head­er field in an IP pack­et is the four-bit ver­sion field. For IPv4, this has a val­ue of 4 (hence the name IPv4).

Inter­net Head­er Length (IHL) Field

The sec­ond field (4 bits) is the Inter­net Head­er Length (IHL), which is the num­ber of 32-bit words in the head­er. Since an IPv4 head­er may con­tain a vari­able num­ber of options, this field spec­i­fies the size of the head­er (this also coin­cides with the off­set to the data). The min­i­mum val­ue for this field is 5 (RFC 791), which is a length of 5×32 = 160 bits = 20 bytes. Being a 4‑bit val­ue, the max­i­mum length is 15 words (15×32 bits) or 480 bits = 60 bytes.

Dif­fer­en­ti­at­ed Ser­vices Code Point (DSCP) Field

Orig­i­nal­ly defined as the Type of ser­vice field, this field is now defined by RFC 2474 for Dif­fer­en­ti­at­ed ser­vices (Diff­Serv). New tech­nolo­gies are emerg­ing that require real-time data stream­ing and there­fore make use of the DSCP field. An exam­ple is Voice over IP (VoIP), which is used for inter­ac­tive data voice exchange.

Explic­it Con­ges­tion Noti­fi­ca­tion (ECN) Field

This field is defined in RFC 3168 and allows end-to-end noti­fi­ca­tion of net­work con­ges­tion with­out drop­ping pack­ets. ECN is an option­al fea­ture that is only used when both end­points sup­port it and are will­ing to use it. It is only effec­tive when sup­port­ed by the under­ly­ing net­work.

Total Length Field

This 16-bit field defines the entire pack­et (frag­ment) size, includ­ing head­er and data, in bytes. The min­i­mum-length pack­et is 20 bytes (20-byte head­er + 0 bytes data) and the max­i­mum is 65,535 bytes — the max­i­mum val­ue of a 16-bit word. All hosts are required to be able to reassem­ble data­grams of size up to 576 bytes, but most mod­ern hosts han­dle much larg­er pack­ets. Some­times sub­net­works impose fur­ther restric­tions on the pack­et size, in which case data­grams must be frag­ment­ed. Frag­men­ta­tion is han­dled in either the host or router in IPv4.

Iden­ti­fi­ca­tion Field

This field is an iden­ti­fi­ca­tion field and is pri­mar­i­ly used for unique­ly iden­ti­fy­ing the group of frag­ments of a sin­gle IP data­gram. Some exper­i­men­tal work has sug­gest­ed using the ID field for oth­er pur­pos­es, such as for adding pack­et-trac­ing infor­ma­tion to help trace data­grams with spoofed source addresses,[13] but RFC 6864 now pro­hibits any such use.

Flags Field

A three-bit field fol­lows and is used to con­trol or iden­ti­fy frag­ments. They are (in order, from high order to low order): bit 0: Reserved; must be zero.
bit 1: Don’t Frag­ment (DF)
bit 2: More Frag­ments (MF)

If the DF flag is set, and frag­men­ta­tion is required to route the pack­et, then the pack­et is dropped. This can be used when send­ing pack­ets to a host that does not have suf­fi­cient resources to han­dle frag­men­ta­tion. It can also be used for Path MTU Dis­cov­ery, either auto­mat­i­cal­ly by the host IP soft­ware, or man­u­al­ly using diag­nos­tic tools such as ping or tracer­oute. For unfrag­ment­ed pack­ets, the MF flag is cleared. For frag­ment­ed pack­ets, all frag­ments except the last have the MF flag set. The last frag­ment has a non-zero Frag­ment Off­set field, dif­fer­en­ti­at­ing it from an unfrag­ment­ed pack­et.

Frag­ment Off­set Field

The frag­ment off­set field, mea­sured in units of eight-byte blocks (64 bits), is 13 bits long and spec­i­fies the off­set of a par­tic­u­lar frag­ment rel­a­tive to the begin­ning of the orig­i­nal unfrag­ment­ed IP data­gram. The first frag­ment has an off­set of zero. This allows a max­i­mum off­set of (213 – 1) × 8 = 65,528 bytes, which would exceed the max­i­mum IP pack­et length of 65,535 bytes with the head­er length includ­ed (65,528 + 20 = 65,548 bytes).

Time To Live (TTL) Field

An eight-bit time to live field helps pre­vent data­grams from per­sist­ing (e.g. going in cir­cles) on an inter­net. This field lim­its a data­gram’s life­time. It is spec­i­fied in sec­onds, but time inter­vals less than 1 sec­ond are round­ed up to 1. In prac­tice, the field has become a hop count—when the data­gram arrives at a router, the router decre­ments the TTL field by one. When the TTL field hits zero, the router dis­cards the pack­et and typ­i­cal­ly sends an ICMP Time Exceed­ed mes­sage to the sender.

The pro­gram tracer­oute uses these ICMP Time Exceed­ed mes­sages to print the routers used by pack­ets to go from the source to the des­ti­na­tion.

Pro­to­col Field

This field defines the pro­to­col used in the data por­tion of the IP data­gram. The Inter­net Assigned Num­bers Author­i­ty main­tains a list of IP pro­to­col num­bers which was orig­i­nal­ly defined in RFC 790.

Head­er Check­sum Field

Main arti­cle: IPv4 head­er check­sum

The 16-bit check­sum field is used for error-check­ing of the head­er. When a pack­et arrives at a router, the router cal­cu­lates the check­sum of the head­er and com­pares it to the check­sum field. If the val­ues do not match, the router dis­cards the pack­et. Errors in the data field must be han­dled by the encap­su­lat­ed pro­to­col. Both UDP and TCP have check­sum fields. When a pack­et arrives at a router, the router decreas­es the TTL field. Con­se­quent­ly, the router must cal­cu­late a new check­sum. RFC 1071 defines the check­sum cal­cu­la­tion:

The check­sum field is the 16-bit one’s com­ple­ment of the one’s com­ple­ment sum of all 16-bit words in the head­er. For pur­pos­es of com­put­ing the check­sum, the val­ue of the check­sum field is zero.

For exam­ple, con­sid­er Hex 4500003044224000800600008c7c19acae241e2b (20 bytes IP head­er), using a machine which uses stan­dard two’s com­ple­ment arith­metic:

Step 1) 4500 + 0030 + 4422 + 4000 + 8006 + 0000 + 8c7c + 19ac + ae24 + 1e2b = 0002BBCF (32-bit sum)

Step 2) 0002 + BBCF = BBD1 = 1011101111010001 (1’s com­ple­ment 16-bit sum, formed by “end around car­ry” of 32-bit 2’s com­ple­ment sum)

Step 3) ~BBD1 = 0100010000101110 = 442E (1’s com­ple­ment of 1’s com­ple­ment 16-bit sum)

To val­i­date a head­er’s check­sum the same algo­rithm may be used – the check­sum of a head­er which con­tains a cor­rect check­sum field is a word con­tain­ing all zeros (val­ue 0):

2BBCF + 442E = 2FFFD. 2 + FFFD = FFFF. the 1’S of FFFF = 0.

Source address Field

This field is the IPv4 address of the sender of the pack­et. Note that this address may be changed in tran­sit by a net­work address trans­la­tion device.

 

Des­ti­na­tion address Field

This field is the IPv4 address of the receiv­er of the pack­et. As with the source address, this may be changed in tran­sit by a net­work address trans­la­tion device.

Options Field

The options field is not often used. Note that the val­ue in the IHL field must include enough extra 32-bit words to hold all the options (plus any padding need­ed to ensure that the head­er con­tains an inte­ger num­ber of 32-bit words). The list of options may be ter­mi­nat­ed with an EOL (End of Options List, 0x00) option; this is only nec­es­sary if the end of the options would not oth­er­wise coin­cide with the end of the head­er.

How the IPv6 Head­er is built

The IPv6 head­er is big­ger by size, because the new address­es are 128 bits instead of 32 bits in size. The head­er is sim­pler at the same time!

Off­set Octet 0 1 2 3

Octet

Bit

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

0

0

Ver­sion

Traf­fic Class

Flow Label

4

32

Pay­load Length

Next Head­er

Hop Lim­it

8

64

Source IPv6 Address

12

96

16
128
20
160
24
192

Des­ti­na­tion IPv6 Address

28
224
32
256
36
288

About the IPv6 Head­er Ver­sion Field (4 bits)

The con­stant 6 (bit sequence 0110)

Traf­fic Class (8 bits) Field

The bits of this field hold two val­ues. The 6 most-sig­nif­i­cant bits are used for dif­fer­en­ti­at­ed ser­vices, which is used to clas­si­fy pack­ets. The remain­ing two bits are used for ECN; pri­or­i­ty val­ues sub­di­vide into ranges: traf­fic where the source pro­vides con­ges­tion con­trol and non-con­ges­tion con­trol traf­fic.

Flow Label (20 bits) Field

Orig­i­nal­ly cre­at­ed for giv­ing real-time appli­ca­tions spe­cial ser­vice. The flow label when set to a non-zero val­ue now serves as a hint to routers and switch­es with mul­ti­ple out­bound paths that these pack­ets should stay on the same path so that they will not be reordered. It has fur­ther been sug­gest­ed that the flow label be used to help detect spoofed pack­ets.

Pay­load Length (16 bits) Field

The size of the pay­load in octets, includ­ing any exten­sion head­ers. The length is set to zero when a Hop-by-Hop exten­sion head­er car­ries a Jum­bo Pay­load option.

Next Head­er (8 bits) Field

Spec­i­fies the type of the next head­er. This field usu­al­ly spec­i­fies the trans­port lay­er pro­to­col used by a pack­et’s pay­load. When exten­sion head­ers are present in the pack­et this field indi­cates which exten­sion head­er fol­lows. The val­ues are shared with those used for the IPv4 pro­to­col field, as both fields have the same func­tion (see List of IP pro­to­col num­bers).

Hop Lim­it (8 bits) Field

Replaces the time to live field of IPv4. This val­ue is decre­ment­ed by one at each inter­me­di­ate node vis­it­ed by the pack­et. When the counter reach­es 0 the pack­et is dis­card­ed.

Source Address (128 bits) Field

The IPv6 address of the send­ing node.

Des­ti­na­tion Address (128 bits) Field

The IPv6 address of the des­ti­na­tion node(s).

In order to increase per­for­mance, and since cur­rent link lay­er tech­nol­o­gy is assumed to pro­vide suf­fi­cient error detec­tion, the head­er has no check­sum to pro­tect it.

What IPv6 Exten­sion Head­ers are and why we need them

This is new with IPv6 and makes the pack­et small­er, and the whole thing very flex­i­ble. Option­al Exten­sion Head­ers can be insert­ed after the fixed pack­et head­er.
 In this case the Next Head­er field con­tains the type of Exten­sion Head­er
 that is used (see table below).

It is pos­si­ble to chain mul­ti­ple Exten­sion Head­ers.

IPv6 Exten­sion Head­er Types

Exten­sion Head­er Type Descrip­tion
Hop-by-Hop Options

0

Options that need to be exam­ined by all devices on the path. Router Alert for RSVP, MLD
Des­ti­na­tion Options
(before rout­ing head­er)

60

Options that need to be exam­ined only by the des­ti­na­tion of the pack­et.
Rout­ing

43

Meth­ods to spec­i­fy the route for a data­gram, e.g. manda­to­ry hops (used with Mobile IPv6).
Frag­ment

44

Con­tains para­me­ters for frag­men­ta­tion of data­grams.
Authen­ti­ca­tion Head­er (AH)

51

Con­tains infor­ma­tion used to ver­i­fy the authen­tic­i­ty of most parts of the pack­et. Used for IPsec
Encap­su­lat­ing Secu­ri­ty Pay­load (ESP)

50

Car­ries encrypt­ed data for secure com­mu­ni­ca­tion. Used for IPsec
Des­ti­na­tion Options
(before upper-lay­er head­er)

60

Options that need to be exam­ined only by the des­ti­na­tion of the pack­et.
Mobil­i­ty
(cur­rent­ly with­out upper-lay­er head­er)

135

Para­me­ters used with Mobile IPv6.

IPv6 Frag­men­ta­tion and it’s lim­i­ta­tions

In IPv6, routers do not frag­ment IPv6 pack­ets. This is a major dif­fer­ence to IPv4.

Hosts have to use Path MTU Dis­cov­ery (PMTUD) to find out the max­i­mum pos­si­ble pack­et size
 which is sup­port­ed by the end-to-end rout­ing path from source to des­ti­na­tion.

Pack­ets that are too large are dropped and an ICMPv6 type 2 mes­sage (Pack­et too big) is sent to the source. This is very sim­i­lar to set­ting the IPv4 don’t frag­ment (df) bit.

For fur­ther read­ing on this top­ic I can rec­om­mend a great Arti­cle by Geoff Hus­ton about Eval­u­at­ing IPv4 and IPv6 Pack­et Frag­men­ta­tion and also one by CDN provider Cloud­flare about why IP frag­men­ta­tion is bro­ken by design.

IPv6 Frag­ment Exten­sion Head­er

In case the appli­ca­tion is not able to keep the pay­load with­in range, the source host can use a Frag­ment Exten­sion Head­er
. Usu­al­ly it is the appli­ca­tion’s job to keep the pack­et below the max­i­mum size.

With the Frag­ment Exten­sion Head­er, pack­ets are frag­ment­ed end to end
.

Only the des­ti­na­tion host will rebuild the orig­i­nal pack­et from frag­ments.

Thank You

Thank you for attend­ing the Orig­i­nal IPv6 Foun­da­tion Mas­ter Class! You can book­mark this site to use it as a quick ref­er­ence in case you need to re-read some­thing and you can share this page to social media and your friends and col­leagues. Stay tuned to this blog for more in-depth sto­ries like this one.

Rec­om­mend­ed Resources for addi­tion­al read­ing

Apart from the links through­out this course I rec­om­mend the fol­low­ing resources for addi­tion­al infor­ma­tion:

  1. The Inter­net Soci­ety (ISOC) IPv6 Por­tal
  2. Test your IPv6 con­nec­tiv­i­ty on test-ipv6.com
  3. The offi­cial IANA list of assigned IPv6 address space is very inter­est­ing
  4. The Google IPv6 deploy­ment sta­tis­tics
  5. The RIPE NCC IPv6 work­ing group and mail­ing list

Book rec­om­men­da­tions on IPv6

I can rec­om­mend the fol­low­ing 3 books (Ama­zon refer­ral links) which I enjoyed read­ing:

This con­cludes IPv6 Foun­da­tion Part 3: IPv6 Head­ers & Exten­sion Head­ers of the orig­i­nal IPv6 Foun­da­tion Mas­ter Class.

Pre­vi­ous Part: IPv6 Foun­da­tion Part 2: IPv6 Address­ing and Sub­net­ting

Next Part: IPv6 Foun­da­tion Part 4: ICMPv6 & IPv6 Neigh­bor­ships

Share this post

Share on pocket
Share on reddit
Share on facebook
Share on twitter
Share on linkedin
Share on xing