cnp3-ebook/protocols/ipv6 — French @ Weblate: 1500 bytes

	English	French	Actions
	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.
	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.
	The IPv6 `Hop-by-Hop Options` header
	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 :
	``00`` : if a node does not recognize this header, it can be safely skipped and the processing continues with the subsequent header
	``01`` : if a node does not recognize this header, the packet must be discarded
	``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)
	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.
	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.
	The `Destinations Option` header uses the same format as the `Hop-by-Hop Options` header. It has some usages, e.g. to support mobile nodes :rfc:`6275`, but these are outside the scope of this document.
	The `Fragment Options` header is more important. An important problem in the network layer is the ability to handle heterogeneous datalink layers. Most datalink layer technologies can only transmit and receive frames that are shorter than a given maximum frame size. Unfortunately, all datalink layer technologies use different maximum frames sizes.
	Each datalink layer has its own characteristics and as indicated earlier, each datalink layer is characterized by a maximum frame size. From IP's point of view, a datalink layer interface is characterized by its `Maximum Transmission Unit (MTU)`. The MTU of an interface is the largest packet (including header) that it can send. The table below provides some common MTU sizes.
	Datalink layer
	MTU
	Ethernet
	1500 bytes
	WiFi
	2272 bytes
	ATM (AAL5)
	9180 bytes
	802.15.4
	102 or 81 bytes
	Token Ring
	4464 bytes
	FDDI
	4352 bytes
	Although IPv6 can send 64 KBytes long packets, few datalink layer technologies that are used today are able to send a 64 KBytes packet inside a frame. Furthermore, as illustrated in the figure below, another problem is that a host may send a packet that would be too large for one of the datalink layers used by the intermediate routers.
	The need for fragmentation and reassembly
	To solve these problems, IPv6 includes a packet fragmentation and reassembly mechanism. In IPv4, fragmentation was performed by both the hosts and the intermediate routers. However, experience with IPv4 has shown that fragmenting packets in routers was costly [KM1995]_. For this reason, the developers of IPv6 have decided that routers would not fragment packets anymore. In IPv6, fragmentation is only performed by the source host. If a source has to send a packet which is larger than the MTU of the outgoing interface, the packet needs to be fragmented before being transmitted. In IPv6, each packet fragment is an IPv6 packet that includes the `Fragmentation` header. This header is included by the source in each packet fragment. The receiver uses them to reassemble the received fragments.
	IPv6 fragmentation header
	If a router receives a packet that is too long to be forwarded, the packet is dropped and the router returns an ICMPv6 message to inform the sender of the problem. The sender can then either fragment the packet or perform Path MTU discovery. In IPv6, packet fragmentation is performed only by the source by using IPv6 options.

Loading…

None

New source string

cnp3-ebook / protocols/ipv6 — French

New source string 3 years ago

Browse all component changes

Glossary

English	French
No related strings found in the glossary.

String information

Source string location

../../protocols/ipv6.rst:404

String age

3 years ago

Source string age

3 years ago

Translation file

locale/fr/LC_MESSAGES/protocols/ipv6.po, string 119