Exit Zen
87
../../protocols/ipv6.rst:337
English
`Next Header` : this 8-bit field indicates the type [#fianaprotocol]_ of header that follows the IPv6 header. It can be a transport layer header (e.g. `6` for TCP or `17` for UDP) or an IPv6 option.
0/1980 · 198
88
../../protocols/ipv6.rst:338
English
`Hop Limit` : this 8-bit field indicates the number of routers that can forward the packet. It is decremented by one by each router and prevents packets from looping forever inside the network.
0/1930 · 193
89
../../protocols/ipv6.rst:341
English
It is interesting to note that there is no checksum inside the IPv6 header. This is mainly because all datalink layers and transport protocols include a checksum or a CRC to protect their frames/segments against transmission errors. Adding a checksum in the IPv6 header would have forced each router to recompute the checksum of all packets, with limited benefit in detecting errors. In practice, an IP checksum allows for catching errors that occur inside routers (e.g. due to memory corruption) before the packet reaches its destination. However, this benefit was found to be too small given the reliability of current memories and the cost of computing the checksum on each router [#fipv4checksum]_.
0/7020 · 702
90
../../protocols/ipv6.rst:343
English
When a host receives an IPv6 packet, it needs to determine which transport protocol (UDP, TCP, SCTP, ...) needs to handle the payload of the packet. This is the first role of the `Next header` field. The IANA_ which manages the allocation of Internet resources and protocol parameters, maintains an official list of transport protocols [#fianaprotocol]_. The following protocol numbers are reserved :
0/4000 · 400
91
../../protocols/ipv6.rst:345
English
``TCP`` uses `Next Header` number ``6``
0/390 · 39
92
../../protocols/ipv6.rst:346
English
``UDP`` uses `Next Header` number ``17``
0/400 · 40
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