Exit Zen
93
../../protocols/ipv6.rst:347
English
``SCTP`` uses `Next Header` number ``132``
0/420 · 42
94
../../protocols/ipv6.rst:349
English
For example, an IPv6 packet that contains an TCP segment would appear as shown in the figure below.
0/990 · 99
95
../../protocols/ipv6.rst:354
English
An IPv6 packet containing an TCP segment
0/400 · 40
96
../../protocols/ipv6.rst:358
English
However, the `Next header` has broader usages than simply indicating the transport protocol which is responsible for the packet payload. An IPv6 packet can contain a chain of headers and the last one indicates the transport protocol that is responsible for the packet payload. Supporting a chain of headers is a clever design from an extensibility viewpoint. As we will see, this chain of headers has several usages.
0/4160 · 416
97
../../protocols/ipv6.rst:360
English
:rfc:`2460` defines several types of IPv6 extension headers that could be added to an IPv6 packet :
0/990 · 99
98
../../protocols/ipv6.rst:362
English
`Hop-by-Hop Options` header. This option is processed by routers and hosts.
0/750 · 75
99
../../protocols/ipv6.rst:363
English
`Destination Options` header. This option is processed only by hosts.
0/690 · 69
100
../../protocols/ipv6.rst:364
English
`Routing` header. This option is processed by some nodes.
0/570 · 57
101
../../protocols/ipv6.rst:365
English
`Fragment` header. This option is processed only by hosts.
0/580 · 58
102
../../protocols/ipv6.rst:366
English
`Authentication` header. This option is processed only by hosts.
0/640 · 64
103
../../protocols/ipv6.rst:367
English
`Encapsulating Security Payload`. This option is processed only by hosts.
0/730 · 73
104
../../protocols/ipv6.rst:369
English
The last two headers are used to add security above IPv6 and implement IPSec. They are described in :rfc:`2402` and :rfc:`2406` and are outside the scope of this document.
0/1710 · 171
105
../../protocols/ipv6.rst:371
English
The `Hop-by-Hop Options` header was designed to make IPv6 easily extensible. In theory, this option could be used to define new fields that were not foreseen when IPv6 was designed. It is intended to be processed by both routers and hosts. Deploying an extension to a network protocol can be difficult in practice since some nodes already support the extensions while others still use the old version and do not understand the extension. To deal with this issue, the IPv6 designers opted for a Type-Length-Value encoding of these IPv6 options. The `Hop-by-Hop Options` header is encoded as shown below.
0/6030 · 603
106
../../protocols/ipv6.rst:376
English
The IPv6 `Hop-by-Hop Options` header
0/360 · 36
107
../../protocols/ipv6.rst:378
English
In this optional header, the `Next Header` field is used to support the chain of headers. It indicates the type of the next header in the chain. IPv6 headers have different lengths. The `Hdr Ext Len` field indicates the total length of the option header in bytes. The `Opt. Type` field indicates the type of option. These types are encoded such that their high order bits specify how the header needs to be handled by nodes that do not recognize it. The following values are defined for the two high order bits :
0/5120 · 512
108
../../protocols/ipv6.rst:380
English
``00`` : if a node does not recognize this header, it can be safely skipped and the processing continues with the subsequent header
0/1320 · 132
109
../../protocols/ipv6.rst:381
English
``01`` : if a node does not recognize this header, the packet must be discarded
0/790 · 79
110
../../protocols/ipv6.rst:382
English
``10`` (resp. ``11``) : if a node does not recognize this header, it must return a control packet (ICMP, see later) back to the source (resp. except if the destination was a multicast address)
0/1920 · 192
111
../../protocols/ipv6.rst:384
English
This encoding allows the designers of protocol extensions to specify whether the option must be supported by all nodes on a path or not. Still, deploying such an extension can be difficult in practice.
0/2010 · 201
112
../../protocols/ipv6.rst:388
English
Two `hop-by-hop` options have been defined. :rfc:`2675` specifies the jumbogram that enables IPv6 to support packets containing a payload larger than 65535 bytes. These jumbo packets have their `payload length` set to `0` and the jumbogram option contains the packet length as a 32 bits field. Such packets can only be sent from a source to a destination if all the routers on the path support this option. However, as of this writing it does not seem that the jumbogram option has been implemented. The router alert option defined in :rfc:`2711` is the second example of a `hop-by-hop` option. The packets that contain this option should be processed in a special way by intermediate routers. This option is used for IP packets that carry Resource Reservation Protocol (RSVP) messages, but this is outside the scope of this book.
0/8300 · 830