<?xml version="1.0" encoding="UTF-8"?>
<xliff xmlns="urn:oasis:names:tc:xliff:document:1.1" version="1.1">
  <file original="NoName" source-language="en" datatype="plaintext" target-language="en">
    <body>
      <trans-unit xml:space="preserve" approved="no" id="352b54a54156c204" weblate-flags="read-only">
        <source>The network layer</source>
        <target state="translated">The network layer</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">7</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="93037758bd7e47f1" weblate-flags="read-only">
        <source>The main objective of the network layer is to allow hosts, connected to different networks, to exchange information through intermediate systems called :term:`router`. The unit of information in the network layer is called a :term:`packet`.</source>
        <target state="translated">The main objective of the network layer is to allow hosts, connected to different networks, to exchange information through intermediate systems called :term:`router`. The unit of information in the network layer is called a :term:`packet`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">9</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="77203ee33a1e36c6" weblate-flags="read-only">
        <source>Before explaining the network layer in detail, it is useful to begin by analyzing the service provided by the `datalink` layer. There are many variants of the datalink layer. Some provide a connection-oriented service while others provide a connectionless service. In this section, we focus on connectionless datalink layer services as they are the most widely used. Using a connection-oriented datalink layer causes some problems that are beyond the scope of this chapter. See :rfc:`3819` for a discussion on this topic.</source>
        <target state="translated">Before explaining the network layer in detail, it is useful to begin by analyzing the service provided by the `datalink` layer. There are many variants of the datalink layer. Some provide a connection-oriented service while others provide a connectionless service. In this section, we focus on connectionless datalink layer services as they are the most widely used. Using a connection-oriented datalink layer causes some problems that are beyond the scope of this chapter. See :rfc:`3819` for a discussion on this topic.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">37</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6cad673872cbdc5b" weblate-flags="read-only">
        <source>There are three main types of datalink layers. The simplest datalink layer is when there are only two communicating systems that are directly connected through the physical layer. Such a datalink layer is used when there is a point-to-point link between the two communicating systems. The two systems can be hosts or routers. :abbr:`PPP (Point-to-Point Protocol)`, defined in :rfc:`1661`, is an example of such a point-to-point datalink layer. Datalink layers exchange `frames` and a datalink :term:`frame` sent by a datalink layer entity on the left is transmitted through the physical layer, so that it can reach the datalink layer entity on the right. Point-to-point datalink layers can either provide an unreliable service (frames can be corrupted or lost) or a reliable service (in this case, the datalink layer includes retransmission mechanisms similar to the ones used in the transport layer). The unreliable service is frequently used above physical layers (e.g. optical fiber, twisted pairs) having a low bit error ratio while reliability mechanisms are often used in wireless networks to recover locally from transmission errors.</source>
        <target state="translated">There are three main types of datalink layers. The simplest datalink layer is when there are only two communicating systems that are directly connected through the physical layer. Such a datalink layer is used when there is a point-to-point link between the two communicating systems. The two systems can be hosts or routers. :abbr:`PPP (Point-to-Point Protocol)`, defined in :rfc:`1661`, is an example of such a point-to-point datalink layer. Datalink layers exchange `frames` and a datalink :term:`frame` sent by a datalink layer entity on the left is transmitted through the physical layer, so that it can reach the datalink layer entity on the right. Point-to-point datalink layers can either provide an unreliable service (frames can be corrupted or lost) or a reliable service (in this case, the datalink layer includes retransmission mechanisms similar to the ones used in the transport layer). The unreliable service is frequently used above physical layers (e.g. optical fiber, twisted pairs) having a low bit error ratio while reliability mechanisms are often used in wireless networks to recover locally from transmission errors.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">57</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d2c07f956066d9ec" weblate-flags="read-only">
        <source>The second type of datalink layer is the one used in Local Area Networks (LAN). Conceptually, a LAN is a set of communicating devices such that any two devices can directly exchange frames through the datalink layer. Both hosts and routers can be connected to a LAN. Some LANs only connect a few devices, but there are LANs that can connect hundreds or even thousands of devices.</source>
        <target state="translated">The second type of datalink layer is the one used in Local Area Networks (LAN). Conceptually, a LAN is a set of communicating devices such that any two devices can directly exchange frames through the datalink layer. Both hosts and routers can be connected to a LAN. Some LANs only connect a few devices, but there are LANs that can connect hundreds or even thousands of devices.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">59</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="84f25380f7a372e1" weblate-flags="read-only">
        <source>A local area network</source>
        <target state="translated">A local area network</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">65</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6ceb843cc5e86457" weblate-flags="read-only">
        <source>In the next chapter, we describe the organization and the operation of Local Area Networks. An important difference between the point-to-point datalink layers and the datalink layers used in LANs is that in a LAN, each communicating device is identified by a unique `datalink layer address`. This address is usually embedded in the hardware of the device and different types of LANs use different types of datalink layer addresses. Most LANs use 48-bits long addresses that are usually called `MAC` addresses. A communicating device attached to a LAN can send a datalink frame to any other communicating device that is attached to the same LAN. Most LANs also support special broadcast and multicast datalink layer addresses. A frame sent to the broadcast address of the LAN is delivered to all communicating devices that are attached to the LAN. The multicast addresses are used to identify groups of communicating devices. When a frame is sent towards a multicast datalink layer address, it is delivered by the LAN to all communicating devices that belong to the corresponding group.</source>
        <target state="translated">In the next chapter, we describe the organization and the operation of Local Area Networks. An important difference between the point-to-point datalink layers and the datalink layers used in LANs is that in a LAN, each communicating device is identified by a unique `datalink layer address`. This address is usually embedded in the hardware of the device and different types of LANs use different types of datalink layer addresses. Most LANs use 48-bits long addresses that are usually called `MAC` addresses. A communicating device attached to a LAN can send a datalink frame to any other communicating device that is attached to the same LAN. Most LANs also support special broadcast and multicast datalink layer addresses. A frame sent to the broadcast address of the LAN is delivered to all communicating devices that are attached to the LAN. The multicast addresses are used to identify groups of communicating devices. When a frame is sent towards a multicast datalink layer address, it is delivered by the LAN to all communicating devices that belong to the corresponding group.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">67</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="133872b9fc1ac578" weblate-flags="read-only">
        <source>The third type of datalink layers are used in Non-Broadcast Multi-Access (NBMA) networks. These networks are used to interconnect devices like a LAN. All devices attached to an NBMA network are identified by a unique datalink layer address. However, and this is the main difference between an NBMA network and a traditional LAN, the NBMA service only supports unicast. The datalink layer service provided by an NBMA network supports neither broadcast nor multicast.</source>
        <target state="translated">The third type of datalink layers are used in Non-Broadcast Multi-Access (NBMA) networks. These networks are used to interconnect devices like a LAN. All devices attached to an NBMA network are identified by a unique datalink layer address. However, and this is the main difference between an NBMA network and a traditional LAN, the NBMA service only supports unicast. The datalink layer service provided by an NBMA network supports neither broadcast nor multicast.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">71</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="af0d0a7523de1306" weblate-flags="read-only">
        <source>Unfortunately no datalink layer is able to send frames of unlimited side. Each datalink layer is characterized by a maximum frame size. There are more than a dozen different datalink layers and unfortunately most of them use a different maximum frame size. The network layer must cope with the heterogeneity of the datalink layer.</source>
        <target state="translated">Unfortunately no datalink layer is able to send frames of unlimited side. Each datalink layer is characterized by a maximum frame size. There are more than a dozen different datalink layers and unfortunately most of them use a different maximum frame size. The network layer must cope with the heterogeneity of the datalink layer.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">73</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="34004f56bb122c64" weblate-flags="read-only">
        <source>IP version 6</source>
        <target state="translated">IP version 6</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">77</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="adecd346efd6e7e2" weblate-flags="read-only">
        <source>In the late 1980s and early 1990s the growth of the Internet was causing several operational problems on routers. Many of these routers had a single CPU and up to 1 MByte of RAM to store their operating system, packet buffers and routing tables. Given the rate of allocation of IPv4 prefixes to companies and universities willing to join the Internet, the routing tables where growing very quickly and some feared that all IPv4 prefixes would quickly be allocated. In 1987, a study cited in :rfc:`1752`, estimated that there would be 100,000 networks in the near future. In August 1990, estimates indicated that the class B space would be exhausted by March 1994. Two types of solution were developed to solve this problem. The first short term solution was the introduction of Classless Inter Domain Routing (:term:`CIDR`). A second short term solution was the Network Address Translation (:term:`NAT`) mechanism, defined in :rfc:`1631`. NAT allowed multiple hosts to share a single public IPv4 address.</source>
        <target state="translated">In the late 1980s and early 1990s the growth of the Internet was causing several operational problems on routers. Many of these routers had a single CPU and up to 1 MByte of RAM to store their operating system, packet buffers and routing tables. Given the rate of allocation of IPv4 prefixes to companies and universities willing to join the Internet, the routing tables where growing very quickly and some feared that all IPv4 prefixes would quickly be allocated. In 1987, a study cited in :rfc:`1752`, estimated that there would be 100,000 networks in the near future. In August 1990, estimates indicated that the class B space would be exhausted by March 1994. Two types of solution were developed to solve this problem. The first short term solution was the introduction of Classless Inter Domain Routing (:term:`CIDR`). A second short term solution was the Network Address Translation (:term:`NAT`) mechanism, defined in :rfc:`1631`. NAT allowed multiple hosts to share a single public IPv4 address.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">79</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="cd258bbca83857f1" weblate-flags="read-only">
        <source>However, in parallel with these short-term solutions, which have allowed the IPv4 Internet to continue to be usable until now, the Internet Engineering Task Force started working on developing a replacement for IPv4. This work started with an open call for proposals, outlined in :rfc:`1550`. Several groups responded to this call with proposals for a next generation Internet Protocol (IPng) :</source>
        <target state="translated">However, in parallel with these short-term solutions, which have allowed the IPv4 Internet to continue to be usable until now, the Internet Engineering Task Force started working on developing a replacement for IPv4. This work started with an open call for proposals, outlined in :rfc:`1550`. Several groups responded to this call with proposals for a next generation Internet Protocol (IPng) :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">87</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="edbc4d8e8e2db7e6" weblate-flags="read-only">
        <source>TUBA proposed in :rfc:`1347` and :rfc:`1561`</source>
        <target state="translated">TUBA proposed in :rfc:`1347` and :rfc:`1561`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">89</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8d832c3116d22729" weblate-flags="read-only">
        <source>PIP proposed in :rfc:`1621`</source>
        <target state="translated">PIP proposed in :rfc:`1621`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">90</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e26ad4195c5d20ae" weblate-flags="read-only">
        <source>SIPP proposed in :rfc:`1710`</source>
        <target state="translated">SIPP proposed in :rfc:`1710`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">91</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0641ddbcecf87b72" weblate-flags="read-only">
        <source>The IETF decided to pursue the development of IPng based on the SIPP proposal. As IP version `5` was already used by the experimental ST-2 protocol defined in :rfc:`1819`, the successor of IP version 4 is IP version 6. The initial IP version 6 defined in :rfc:`1752` was designed based on the following assumptions :</source>
        <target state="translated">The IETF decided to pursue the development of IPng based on the SIPP proposal. As IP version `5` was already used by the experimental ST-2 protocol defined in :rfc:`1819`, the successor of IP version 4 is IP version 6. The initial IP version 6 defined in :rfc:`1752` was designed based on the following assumptions :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">93</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ad8db82285b20122" weblate-flags="read-only">
        <source>IPv6 addresses are encoded as a 128 bits field</source>
        <target state="translated">IPv6 addresses are encoded as a 128 bits field</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">95</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5b9bf948390665af" weblate-flags="read-only">
        <source>The IPv6 header has a simple format that can easily be parsed by hardware devices</source>
        <target state="translated">The IPv6 header has a simple format that can easily be parsed by hardware devices</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">96</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="666ffc7ec763f417" weblate-flags="read-only">
        <source>A host should be able to configure its IPv6 address automatically</source>
        <target state="translated">A host should be able to configure its IPv6 address automatically</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">97</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="428e17ada2a476a0" weblate-flags="read-only">
        <source>Security must be part of IPv6</source>
        <target state="translated">Security must be part of IPv6</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">98</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9db2ee92026a11a0" weblate-flags="read-only">
        <source>The IPng address size</source>
        <target state="translated">The IPng address size</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">100</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="434eac2cb3bc1077" weblate-flags="read-only">
        <source>When the work on IPng started, it was clear that 32 bits was too small to encode an IPng address and all proposals used longer addresses. However, there were many discussions about the most suitable address length. A first approach, proposed by SIPP in :rfc:`1710`, was to use 64 bit addresses. A 64 bits address space was 4 billion times larger than the IPv4 address space and, furthermore, from an implementation perspective, 64 bit CPUs were being considered and 64 bit addresses would naturally fit inside their registers. Another approach was to use an existing address format. This was the TUBA proposal (:rfc:`1347`) that reuses the ISO CLNP 20 bytes addresses. The 20 bytes addresses provided room for growth, but using ISO CLNP was not favored by the IETF partially due to political reasons, despite the fact that mature CLNP implementations were already available. 128 bits appeared to be a reasonable compromise at that time.</source>
        <target state="translated">When the work on IPng started, it was clear that 32 bits was too small to encode an IPng address and all proposals used longer addresses. However, there were many discussions about the most suitable address length. A first approach, proposed by SIPP in :rfc:`1710`, was to use 64 bit addresses. A 64 bits address space was 4 billion times larger than the IPv4 address space and, furthermore, from an implementation perspective, 64 bit CPUs were being considered and 64 bit addresses would naturally fit inside their registers. Another approach was to use an existing address format. This was the TUBA proposal (:rfc:`1347`) that reuses the ISO CLNP 20 bytes addresses. The 20 bytes addresses provided room for growth, but using ISO CLNP was not favored by the IETF partially due to political reasons, despite the fact that mature CLNP implementations were already available. 128 bits appeared to be a reasonable compromise at that time.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">102</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="12f48ad08b6ec077" weblate-flags="read-only">
        <source>IPv6 addressing architecture</source>
        <target state="translated">IPv6 addressing architecture</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">105</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9eecdfa0a8295537" weblate-flags="read-only">
        <source>The experience of IPv4 revealed that the scalability of a network layer protocol heavily depends on its addressing architecture. The designers of IPv6 spent a lot of effort defining its addressing architecture :rfc:`3513`. All IPv6 addresses are 128 bits wide. This implies that there are :math:`340,282,366,920,938,463,463,374,607,431,768,211,456 (3.4 \times 10^{38})` different IPv6 addresses. As the surface of the Earth is about 510,072,000 :math:`km^2`, this implies that there are about :math:`6.67 \times 10^{23}` IPv6 addresses per square meter on Earth. Compared to IPv4, which offers only 8 addresses per square kilometer, this is a significant improvement on paper.</source>
        <target state="translated">The experience of IPv4 revealed that the scalability of a network layer protocol heavily depends on its addressing architecture. The designers of IPv6 spent a lot of effort defining its addressing architecture :rfc:`3513`. All IPv6 addresses are 128 bits wide. This implies that there are :math:`340,282,366,920,938,463,463,374,607,431,768,211,456 (3.4 \times 10^{38})` different IPv6 addresses. As the surface of the Earth is about 510,072,000 :math:`km^2`, this implies that there are about :math:`6.67 \times 10^{23}` IPv6 addresses per square meter on Earth. Compared to IPv4, which offers only 8 addresses per square kilometer, this is a significant improvement on paper.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">107</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="322acc74f9d3b081" weblate-flags="read-only">
        <source>Textual representation of IPv6 addresses</source>
        <target state="translated">Textual representation of IPv6 addresses</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">109</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5ba1a6e82f148b02" weblate-flags="read-only">
        <source>It is sometimes necessary to write IPv6 addresses in text format, e.g. when manually configuring addresses or for documentation purposes. The preferred format for writing IPv6 addresses is ``x:x:x:x:x:x:x:x``, where the ``x`` 's are hexadecimal digits representing the eight 16-bit parts of the address. Here are a few examples of IPv6 addresses :</source>
        <target state="translated">It is sometimes necessary to write IPv6 addresses in text format, e.g. when manually configuring addresses or for documentation purposes. The preferred format for writing IPv6 addresses is ``x:x:x:x:x:x:x:x``, where the ``x`` 's are hexadecimal digits representing the eight 16-bit parts of the address. Here are a few examples of IPv6 addresses :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">111</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0122ff958798413c" weblate-flags="read-only">
        <source>``abcd:ef01:2345:6789:abcd:ef01:2345:6789``</source>
        <target state="translated">``abcd:ef01:2345:6789:abcd:ef01:2345:6789``</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">113</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c6cb01981886e730" weblate-flags="read-only">
        <source>``2001:db8:0:0:8:800:200c:417a``</source>
        <target state="translated">``2001:db8:0:0:8:800:200c:417a``</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">114</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="edfdf568f9225655" weblate-flags="read-only">
        <source>``fe80:0:0:0:219:e3ff:fed7:1204``</source>
        <target state="translated">``fe80:0:0:0:219:e3ff:fed7:1204``</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">115</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4217afdf0eb04279" weblate-flags="read-only">
        <source>IPv6 addresses often contain a long sequence of bits set to ``0``. In this case, a compact notation has been defined. With this notation, `::` is used to indicate one or more groups of 16 bits blocks containing only bits set to `0`. For example,</source>
        <target state="translated">IPv6 addresses often contain a long sequence of bits set to ``0``. In this case, a compact notation has been defined. With this notation, `::` is used to indicate one or more groups of 16 bits blocks containing only bits set to `0`. For example,</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">117</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="55e5553d46834159" weblate-flags="read-only">
        <source>``2001:db8:0:0:8:800:200c:417a``  is represented as  ``2001:db8::8:800:200c:417a``</source>
        <target state="translated">``2001:db8:0:0:8:800:200c:417a``  is represented as  ``2001:db8::8:800:200c:417a``</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">119</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4d67b098980d06d9" weblate-flags="read-only">
        <source>``ff01:0:0:0:0:0:0:101``   is represented as ``ff01::101``</source>
        <target state="translated">``ff01:0:0:0:0:0:0:101``   is represented as ``ff01::101``</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">120</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="652ec50a93ae5757" weblate-flags="read-only">
        <source>``0:0:0:0:0:0:0:1`` is represented as ``::1``</source>
        <target state="translated">``0:0:0:0:0:0:0:1`` is represented as ``::1``</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">121</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c495bc88ff889a1d" weblate-flags="read-only">
        <source>``0:0:0:0:0:0:0:0`` is represented as ``::``</source>
        <target state="translated">``0:0:0:0:0:0:0:0`` is represented as ``::``</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">122</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="14fe762b4e435feb" weblate-flags="read-only">
        <source>An IPv6 prefix can be represented as `address/length`, where `length` is the length of the prefix in bits. For example, the three notations below correspond to the same IPv6 prefix :</source>
        <target state="translated">An IPv6 prefix can be represented as `address/length`, where `length` is the length of the prefix in bits. For example, the three notations below correspond to the same IPv6 prefix :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">124</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="466e9e0111f435ce" weblate-flags="read-only">
        <source>``2001:0db8:0000:cd30:0000:0000:0000:0000`` / ``60``</source>
        <target state="translated">``2001:0db8:0000:cd30:0000:0000:0000:0000`` / ``60``</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">126</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9412b3cfd8bcb142" weblate-flags="read-only">
        <source>``2001:0db8::cd30:0:0:0:0`` / ``60``</source>
        <target state="translated">``2001:0db8::cd30:0:0:0:0`` / ``60``</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">127</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b6db4f713535bec5" weblate-flags="read-only">
        <source>``2001:0db8:0:cd30::`` / ``60``</source>
        <target state="translated">``2001:0db8:0:cd30::`` / ``60``</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">128</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="59ed05ccd695d119" weblate-flags="read-only">
        <source>IPv6 supports unicast, multicast and anycast addresses. An IPv6 unicast address is used to identify one datalink-layer interface on a host. If a host has several datalink layer interfaces (e.g. an Ethernet interface and a WiFi interface), then it needs several IPv6 addresses. In general, an IPv6 unicast address is structured as shown in the figure below.</source>
        <target state="translated">IPv6 supports unicast, multicast and anycast addresses. An IPv6 unicast address is used to identify one datalink-layer interface on a host. If a host has several datalink layer interfaces (e.g. an Ethernet interface and a WiFi interface), then it needs several IPv6 addresses. In general, an IPv6 unicast address is structured as shown in the figure below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">130</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="aa4d79de329336fb" weblate-flags="read-only">
        <source>An IPv6 unicast address is composed of three parts :</source>
        <target state="translated">An IPv6 unicast address is composed of three parts :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">153</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1db278c4e699b904" weblate-flags="read-only">
        <source>A `global routing prefix` that is assigned to the Internet Service Provider that owns this block of addresses</source>
        <target state="translated">A `global routing prefix` that is assigned to the Internet Service Provider that owns this block of addresses</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">155</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6ccbcfa263002d21" weblate-flags="read-only">
        <source>A `subnet identifier` that identifies a customer of the ISP</source>
        <target state="translated">A `subnet identifier` that identifies a customer of the ISP</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">156</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="81f0bb375fee53af" weblate-flags="read-only">
        <source>An `interface identifier` that identifies a particular interface on a host</source>
        <target state="translated">An `interface identifier` that identifies a particular interface on a host</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">157</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a676ac910c6a58de" weblate-flags="read-only">
        <source>The subnet identifier plays a key role in the scalability of network layer addressing architecture. An important point to be defined in a network layer protocol is the allocation of the network layer addresses. A naive allocation scheme would be to provide an address to each host when the host is attached to the Internet on a first come first served basis. With this solution, a host in Belgium could have address ``2001:db8::1`` while another host located in Africa would use address ``2001:db8::2``. Unfortunately, this would force all routers on the Internet to maintain one route towards each host. In the network layer, scalability is often a function of the number of routes stored on the router. A network will usually work better if its routers store fewer routes and network administrators usually try to minimize the number of routes that are known by their routers. For this, they often divide their network prefix in smaller blocks. For example, consider a company with three campuses, a large one and two smaller ones. The network administrator would probably divide his block of addresses as follows :</source>
        <target state="translated">The subnet identifier plays a key role in the scalability of network layer addressing architecture. An important point to be defined in a network layer protocol is the allocation of the network layer addresses. A naive allocation scheme would be to provide an address to each host when the host is attached to the Internet on a first come first served basis. With this solution, a host in Belgium could have address ``2001:db8::1`` while another host located in Africa would use address ``2001:db8::2``. Unfortunately, this would force all routers on the Internet to maintain one route towards each host. In the network layer, scalability is often a function of the number of routes stored on the router. A network will usually work better if its routers store fewer routes and network administrators usually try to minimize the number of routes that are known by their routers. For this, they often divide their network prefix in smaller blocks. For example, consider a company with three campuses, a large one and two smaller ones. The network administrator would probably divide his block of addresses as follows :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">159</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="13953dd2ca495c2c" weblate-flags="read-only">
        <source>the bottom half is used for the large campus</source>
        <target state="translated">the bottom half is used for the large campus</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">161</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a190d4d677f88737" weblate-flags="read-only">
        <source>the top half is divided in two smaller blocks, one for each small campus</source>
        <target state="translated">the top half is divided in two smaller blocks, one for each small campus</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">162</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8cb5eec6b1348d1f" weblate-flags="read-only">
        <source>Inside each campus, the same division can be done, for example on a per building basis, starting from the buildings that host the largest number of nodes, e.g. the company datacenter. In each building, the same division can be done on a per floor basis, ... The advantage of such a hierarchical allocation of the addresses is that the routers in the large campus only need one route to reach a router in the smaller campus. The routers in the large campus would know more routes about the buildings in their campus, but they do not need to know the details of the organization of each smaller campus.</source>
        <target state="translated">Inside each campus, the same division can be done, for example on a per building basis, starting from the buildings that host the largest number of nodes, e.g. the company datacenter. In each building, the same division can be done on a per floor basis, ... The advantage of such a hierarchical allocation of the addresses is that the routers in the large campus only need one route to reach a router in the smaller campus. The routers in the large campus would know more routes about the buildings in their campus, but they do not need to know the details of the organization of each smaller campus.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">164</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0a3149dce18b3fcd" weblate-flags="read-only">
        <source>To preserve the scalability of the routing system, it is important to minimize the number of routes that are stored on each router. A router cannot store and maintain one route for each of the almost 1 billion hosts that are connected to today's Internet. Routers should only maintain routes towards blocks of addresses and not towards individual hosts. For this, hosts are grouped in `subnets` based on their location in the network. A typical subnet groups all the hosts that are part of the same enterprise. An enterprise network is usually composed of several LANs interconnected by routers. A small block of addresses from the Enterprise's block is usually assigned to each LAN.</source>
        <target state="translated">To preserve the scalability of the routing system, it is important to minimize the number of routes that are stored on each router. A router cannot store and maintain one route for each of the almost 1 billion hosts that are connected to today's Internet. Routers should only maintain routes towards blocks of addresses and not towards individual hosts. For this, hosts are grouped in `subnets` based on their location in the network. A typical subnet groups all the hosts that are part of the same enterprise. An enterprise network is usually composed of several LANs interconnected by routers. A small block of addresses from the Enterprise's block is usually assigned to each LAN.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">166</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="33bdd841300f01f3" weblate-flags="read-only">
        <source>In today's deployments, interface identifiers are always 64 bits wide. This implies that while there are :math:`2^{128}` different IPv6 addresses, they must be grouped in :math:`2^{64}` subnets. This could appear as a waste of resources, however using 64 bits for the host identifier allows IPv6 addresses to be auto-configured and also provides some benefits from a security point of view, as explained in section ICMPv6_.</source>
        <target state="translated">In today's deployments, interface identifiers are always 64 bits wide. This implies that while there are :math:`2^{128}` different IPv6 addresses, they must be grouped in :math:`2^{64}` subnets. This could appear as a waste of resources, however using 64 bits for the host identifier allows IPv6 addresses to be auto-configured and also provides some benefits from a security point of view, as explained in section ICMPv6_.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">168</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b5319fbbf95c5779" weblate-flags="read-only">
        <source>In practice, there are several types of IPv6 unicast address. Most of the `IPv6 unicast addresses &lt;http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml&gt;`_ are allocated in blocks under the responsibility of IANA_. The current IPv6 allocations are part of the `2000::/3` address block. Regional Internet Registries (RIR) such as RIPE_ in Europe,  ARIN_ in North-America or AfriNIC in Africa have each received a `block of IPv6 addresses &lt;http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml&gt;`_ that they sub-allocate to Internet Service Providers in their region.  The ISPs then sub-allocate addresses to their customers.</source>
        <target state="translated">In practice, there are several types of IPv6 unicast address. Most of the `IPv6 unicast addresses &lt;http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml&gt;`_ are allocated in blocks under the responsibility of IANA_. The current IPv6 allocations are part of the `2000::/3` address block. Regional Internet Registries (RIR) such as RIPE_ in Europe,  ARIN_ in North-America or AfriNIC in Africa have each received a `block of IPv6 addresses &lt;http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml&gt;`_ that they sub-allocate to Internet Service Providers in their region.  The ISPs then sub-allocate addresses to their customers.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">174</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="dc40503131173de1" weblate-flags="read-only">
        <source>When considering the allocation of IPv6 addresses, two types of address allocations are often distinguished. The RIRs allocate `provider-independent (PI)` addresses. PI addresses are usually allocated to Internet Service Providers and large companies that are connected to at least two different ISPs [CSP2009]_. Once a PI address block has been allocated to a company, this company can use its address block with the provider of its choice and change its provider at will. Internet Service Providers allocate `provider-aggregatable (PA)` address blocks from their own PI address block to their customers. A company that is connected to only one ISP should only use PA addresses. The drawback of PA addresses is that when a company using a PA address block changes its provider, it needs to change all the addresses that it uses. This can be a nightmare from an operational perspective and many companies are lobbying to obtain `PI` address blocks even if they are small and connected to a single provider. The typical size of the IPv6 address blocks are :</source>
        <target state="translated">When considering the allocation of IPv6 addresses, two types of address allocations are often distinguished. The RIRs allocate `provider-independent (PI)` addresses. PI addresses are usually allocated to Internet Service Providers and large companies that are connected to at least two different ISPs [CSP2009]_. Once a PI address block has been allocated to a company, this company can use its address block with the provider of its choice and change its provider at will. Internet Service Providers allocate `provider-aggregatable (PA)` address blocks from their own PI address block to their customers. A company that is connected to only one ISP should only use PA addresses. The drawback of PA addresses is that when a company using a PA address block changes its provider, it needs to change all the addresses that it uses. This can be a nightmare from an operational perspective and many companies are lobbying to obtain `PI` address blocks even if they are small and connected to a single provider. The typical size of the IPv6 address blocks are :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">176</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="766ebeda97a09e82" weblate-flags="read-only">
        <source>``/32`` for an Internet Service Provider</source>
        <target state="translated">``/32`` for an Internet Service Provider</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">178</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2efd5b9c6be1e9ef" weblate-flags="read-only">
        <source>``/48`` for a single company</source>
        <target state="translated">``/48`` for a single company</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">179</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c28f613de0f07daf" weblate-flags="read-only">
        <source>``/56`` for small user sites</source>
        <target state="translated">``/56`` for small user sites</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">180</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e2fd3a7da79cc4df" weblate-flags="read-only">
        <source>``/64`` for a single user (e.g. a home user connected via ADSL)</source>
        <target state="translated">``/64`` for a single user (e.g. a home user connected via ADSL)</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">181</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="74411567dc6830b9" weblate-flags="read-only">
        <source>``/128`` in the rare case when it is known that no more than one host will be attached</source>
        <target state="translated">``/128`` in the rare case when it is known that no more than one host will be attached</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">182</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b3cfe963740acb53" weblate-flags="read-only">
        <source>There is one difficulty with the utilization of these IPv6 prefixes. Consider Belnet, the Belgian research  ISP that has been allocated the ``2001:6a8::/32`` prefix. Universities are connected to Belnet. UCLouvain uses prefix ``2001:6a8:3080::/48`` while the University of Liege uses ``2001:6a8:2d80::/48``. A commercial ISP uses prefix ``2a02:2788::/32``. Both Belnet and the commercial ISP are connected to the global Internet.</source>
        <target state="translated">There is one difficulty with the utilization of these IPv6 prefixes. Consider Belnet, the Belgian research  ISP that has been allocated the ``2001:6a8::/32`` prefix. Universities are connected to Belnet. UCLouvain uses prefix ``2001:6a8:3080::/48`` while the University of Liege uses ``2001:6a8:2d80::/48``. A commercial ISP uses prefix ``2a02:2788::/32``. Both Belnet and the commercial ISP are connected to the global Internet.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">189</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="58ab7104d44a163c" weblate-flags="read-only">
        <source>The Belnet network advertises prefix ``2001:6a8::/32`` that includes the prefixes from both UCLouvain and ULg. These two subnetworks can be easily reached from any internet connected host. After a few years, UCLouvain decides to increase the redundancy of its Internet connectivity and buys transit service from ISP1. A direct link between UCLouvain and the commercial ISP appears on the network and UCLouvain expects to receive packets from both Belnet and the commercial ISP.</source>
        <target state="translated">The Belnet network advertises prefix ``2001:6a8::/32`` that includes the prefixes from both UCLouvain and ULg. These two subnetworks can be easily reached from any internet connected host. After a few years, UCLouvain decides to increase the redundancy of its Internet connectivity and buys transit service from ISP1. A direct link between UCLouvain and the commercial ISP appears on the network and UCLouvain expects to receive packets from both Belnet and the commercial ISP.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">196</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c78495b27caea135" weblate-flags="read-only">
        <source>Now, consider how a router inside ``alpha.com`` would reach a host in the ``UCLouvain`` network. This router has two routes towards ``2001:6a8:3080::1``. The first one, for prefix ``2001:6a8:3080::/48`` is via the direct link between the commercial ISP and UCLouvain. The second one, for prefix ``2001:6a8::/32`` is via the Internet and Belnet. Since :rfc:`1519` when a router knows several routes towards the same destination address, it must forward packets along the route having the longest prefix length. In the case of ``2001:6a8:3080::1``, this is the route ``2001:6a8:3080::/48`` that is used to forward the packet. This forwarding rule is called the `longest prefix match` or the `more specific match`. All IP routers implement this forwarding rule.</source>
        <target state="translated">Now, consider how a router inside ``alpha.com`` would reach a host in the ``UCLouvain`` network. This router has two routes towards ``2001:6a8:3080::1``. The first one, for prefix ``2001:6a8:3080::/48`` is via the direct link between the commercial ISP and UCLouvain. The second one, for prefix ``2001:6a8::/32`` is via the Internet and Belnet. Since :rfc:`1519` when a router knows several routes towards the same destination address, it must forward packets along the route having the longest prefix length. In the case of ``2001:6a8:3080::1``, this is the route ``2001:6a8:3080::/48`` that is used to forward the packet. This forwarding rule is called the `longest prefix match` or the `more specific match`. All IP routers implement this forwarding rule.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">199</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a42aaae67e497abd" weblate-flags="read-only">
        <source>To understand the `longest prefix match` forwarding, consider the IPv6 routing below.</source>
        <target state="translated">To understand the `longest prefix match` forwarding, consider the IPv6 routing below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">201</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="89e26e4f086edf42" weblate-flags="read-only">
        <source>With the longest match rule, the route ``::/0`` plays a particular role. As this route has a prefix length of `0` bits, it matches all destination addresses. This route is often called the `default` route.</source>
        <target state="translated">With the longest match rule, the route ``::/0`` plays a particular role. As this route has a prefix length of `0` bits, it matches all destination addresses. This route is often called the `default` route.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">214</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="aa0072d012922a7b" weblate-flags="read-only">
        <source>a packet with destination ``2a02:2788:2c4:16f::1`` received by router `R` is destined to a host on interface ``eth0`` .</source>
        <target state="translated">a packet with destination ``2a02:2788:2c4:16f::1`` received by router `R` is destined to a host on interface ``eth0`` .</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">216</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c7ce0d891be5e16a" weblate-flags="read-only">
        <source>a packet with destination ``2001:6a8:3080::1234`` matches three routes : ``::/0``, ``2001:6a8::/32`` and ``2001:6a8:3080::/48``. The packet is forwarded via gateway ``fe80::bad:cafe``</source>
        <target state="translated">a packet with destination ``2001:6a8:3080::1234`` matches three routes : ``::/0``, ``2001:6a8::/32`` and ``2001:6a8:3080::/48``. The packet is forwarded via gateway ``fe80::bad:cafe``</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">217</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="26231c4aa6659be2" weblate-flags="read-only">
        <source>a packet with destination ``2001:1890:123a::1:1e`` matches one route : ``::/0``. The packet is forwarded via ``fe80::dead:beef``</source>
        <target state="translated">a packet with destination ``2001:1890:123a::1:1e`` matches one route : ``::/0``. The packet is forwarded via ``fe80::dead:beef``</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">218</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d98081fe6d76ce1f" weblate-flags="read-only">
        <source>a packet with destination ``2001:6a8:3880:40::2`` matches two routes : ``2001:6a8::/32`` and ``::/0``. The packet is forwarded via ``fe80::aaaa:bbbb``</source>
        <target state="translated">a packet with destination ``2001:6a8:3880:40::2`` matches two routes : ``2001:6a8::/32`` and ``::/0``. The packet is forwarded via ``fe80::aaaa:bbbb``</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">219</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9c17ab79ffec920e" weblate-flags="read-only">
        <source>The longest prefix match can be implemented by using different data structures One possibility is to use a trie. Details on how to implement efficient packet forwarding algorithms may be found in [Varghese2005]_.</source>
        <target state="translated">The longest prefix match can be implemented by using different data structures One possibility is to use a trie. Details on how to implement efficient packet forwarding algorithms may be found in [Varghese2005]_.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">225</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="122667a650d8abd5" weblate-flags="read-only">
        <source>For the companies that want to use IPv6 without being connected to the IPv6 Internet, :rfc:`4193` defines the `Unique Local Unicast (ULA)` addresses (``fc00::/7``). These ULA addresses play a similar role as the private IPv4 addresses defined in :rfc:`1918`. However, the size of the ``fc00::/7`` address block allows ULA to be much more flexible than private IPv4 addresses.</source>
        <target state="translated">For the companies that want to use IPv6 without being connected to the IPv6 Internet, :rfc:`4193` defines the `Unique Local Unicast (ULA)` addresses (``fc00::/7``). These ULA addresses play a similar role as the private IPv4 addresses defined in :rfc:`1918`. However, the size of the ``fc00::/7`` address block allows ULA to be much more flexible than private IPv4 addresses.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">230</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e9502dfb0b0e4f59" weblate-flags="read-only">
        <source>Furthermore, the IETF has reserved some IPv6 addresses for a special usage. The two most important ones are :</source>
        <target state="translated">Furthermore, the IETF has reserved some IPv6 addresses for a special usage. The two most important ones are :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">234</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="01beb0c5cb3768eb" weblate-flags="read-only">
        <source>``0:0:0:0:0:0:0:1`` (``::1`` in compact form) is the IPv6 loopback address. This is the address of a logical interface that is always up and running on IPv6 enabled hosts.</source>
        <target state="translated">``0:0:0:0:0:0:0:1`` (``::1`` in compact form) is the IPv6 loopback address. This is the address of a logical interface that is always up and running on IPv6 enabled hosts.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">236</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3ebac04fbb4824d4" weblate-flags="read-only">
        <source>``0:0:0:0:0:0:0:0`` (``::`` in compact form) is the unspecified IPv6 address. This is the IPv6 address that a host can use as source address when trying to acquire an official address.</source>
        <target state="translated">``0:0:0:0:0:0:0:0`` (``::`` in compact form) is the unspecified IPv6 address. This is the IPv6 address that a host can use as source address when trying to acquire an official address.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">237</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4cafb0fef5abcffd" weblate-flags="read-only">
        <source>The last type of unicast IPv6 addresses are the `Link Local Unicast` addresses. These addresses are part of the `fe80::/10` address block and are defined in :rfc:`4291`. Each host can compute its own link local address by concatenating the `fe80::/64` prefix with the 64 bits identifier of its interface. Link local addresses can be used when hosts that are attached to the same link (or local area network) need to exchange packets. They are used notably for address discovery and auto-configuration purposes. Their usage is restricted to each link and a router cannot forward a packet whose source or destination address is a link local address. Link local addresses have also been defined for IPv4 :rfc:`3927`. However, the IPv4 link local addresses are only used when a host cannot obtain a regular IPv4 address, e.g. on an isolated LAN.</source>
        <target state="translated">The last type of unicast IPv6 addresses are the `Link Local Unicast` addresses. These addresses are part of the `fe80::/10` address block and are defined in :rfc:`4291`. Each host can compute its own link local address by concatenating the `fe80::/64` prefix with the 64 bits identifier of its interface. Link local addresses can be used when hosts that are attached to the same link (or local area network) need to exchange packets. They are used notably for address discovery and auto-configuration purposes. Their usage is restricted to each link and a router cannot forward a packet whose source or destination address is a link local address. Link local addresses have also been defined for IPv4 :rfc:`3927`. However, the IPv4 link local addresses are only used when a host cannot obtain a regular IPv4 address, e.g. on an isolated LAN.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">241</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2a35cc70d340a579" weblate-flags="read-only">
        <source>All IPv6 hosts have several addresses</source>
        <target state="translated">All IPv6 hosts have several addresses</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">259</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="fc540ec435986f32" weblate-flags="read-only">
        <source>An important consequence of the IPv6 unicast addressing architecture and the utilization of link-local addresses is that each IPv6 host has several IPv6 addresses. This implies that all IPv6 stacks must be able to handle multiple IPv6 addresses.</source>
        <target state="translated">An important consequence of the IPv6 unicast addressing architecture and the utilization of link-local addresses is that each IPv6 host has several IPv6 addresses. This implies that all IPv6 stacks must be able to handle multiple IPv6 addresses.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">261</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d4ff6a186326bd5b" weblate-flags="read-only">
        <source>The addresses described above are unicast addresses. These addresses are used to identify (interfaces on) hosts and routers. They can appear as source and destination addresses in the IPv6 packets. When a host sends a packet towards a unicast address, this packet is delivered by the network to its final destination. There are situations, such as when delivering video or television signal to a large number of receivers, where it is useful to have a network that can efficiently deliver the same packet to a large number of receivers. This is the `multicast` service. A multicast service can be provided in a LAN. In this case, a multicast address identifies a set of receivers and each frame sent towards this address is delivered to all receivers in the group. Multicast can also be used in a network containing routers and hosts. In this case, a multicast address identifies also a group of receivers and the network delivers efficiently each multicast packet to all members of the group. Consider for example the network below.</source>
        <target state="translated">The addresses described above are unicast addresses. These addresses are used to identify (interfaces on) hosts and routers. They can appear as source and destination addresses in the IPv6 packets. When a host sends a packet towards a unicast address, this packet is delivered by the network to its final destination. There are situations, such as when delivering video or television signal to a large number of receivers, where it is useful to have a network that can efficiently deliver the same packet to a large number of receivers. This is the `multicast` service. A multicast service can be provided in a LAN. In this case, a multicast address identifies a set of receivers and each frame sent towards this address is delivered to all receivers in the group. Multicast can also be used in a network containing routers and hosts. In this case, a multicast address identifies also a group of receivers and the network delivers efficiently each multicast packet to all members of the group. Consider for example the network below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">265</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5a24262d2b1c9644" weblate-flags="read-only">
        <source>Assume that ``B`` and ``D`` are part of a multicast group. If ``A`` sends a multicast packet towards this group, then ``R1`` will replicate the packet to forward it to ``R2`` and ``R3``. ``R2`` would forward the packet towards ``B``. ``R3`` would forward the packet towards ``R4`` that would deliver it to ``D``.</source>
        <target state="translated">Assume that ``B`` and ``D`` are part of a multicast group. If ``A`` sends a multicast packet towards this group, then ``R1`` will replicate the packet to forward it to ``R2`` and ``R3``. ``R2`` would forward the packet towards ``B``. ``R3`` would forward the packet towards ``R4`` that would deliver it to ``D``.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">289</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4dacb424ad885164" weblate-flags="read-only">
        <source>Finally, :rfc:`4291` defines the structure of the IPv6 multicast addresses [#fmultiiana]_. This structure is depicted in the figure below.</source>
        <target state="translated">Finally, :rfc:`4291` defines the structure of the IPv6 multicast addresses [#fmultiiana]_. This structure is depicted in the figure below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">291</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0ee019d1762c1e39" weblate-flags="read-only">
        <source>The low order 112 bits of an IPv6 multicast address are the group's identifier. The high order bits are used as a marker to distinguish multicast addresses from unicast addresses. Notably, the 4-bit `Flags` field indicates whether the address is temporary or permanent. Finally, the `Scope` field indicates the boundaries of the forwarding of packets destined to a particular address. A link-local scope indicates that a router should not forward a packet destined to such a multicast address. An organization local-scope indicates that a packet sent to such a multicast destination address should not leave the organization. Finally the global scope is intended for multicast groups spanning the global Internet.</source>
        <target state="translated">The low order 112 bits of an IPv6 multicast address are the group's identifier. The high order bits are used as a marker to distinguish multicast addresses from unicast addresses. Notably, the 4-bit `Flags` field indicates whether the address is temporary or permanent. Finally, the `Scope` field indicates the boundaries of the forwarding of packets destined to a particular address. A link-local scope indicates that a router should not forward a packet destined to such a multicast address. An organization local-scope indicates that a packet sent to such a multicast destination address should not leave the organization. Finally the global scope is intended for multicast groups spanning the global Internet.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">314</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ca2209328c79f20c" weblate-flags="read-only">
        <source>Among these addresses, some are well known. For example, all hosts automatically belong to the ``ff02::1`` multicast group while all routers automatically belong to the ``ff02::2`` multicast group. A detailed discussion of IPv6 multicast is outside the scope of this chapter.</source>
        <target state="translated">Among these addresses, some are well known. For example, all hosts automatically belong to the ``ff02::1`` multicast group while all routers automatically belong to the ``ff02::2`` multicast group. A detailed discussion of IPv6 multicast is outside the scope of this chapter.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">316</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="731f9bc2c07e28d9" weblate-flags="read-only">
        <source>IPv6 packet format</source>
        <target state="translated">IPv6 packet format</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">321</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="12bd234c6395b238" weblate-flags="read-only">
        <source>The IPv6 packet format was heavily inspired by the packet format proposed for the SIPP protocol in :rfc:`1710`. The standard IPv6 header defined in :rfc:`2460` occupies 40 bytes and contains 8 different fields, as shown in the figure below.</source>
        <target state="translated">The IPv6 packet format was heavily inspired by the packet format proposed for the SIPP protocol in :rfc:`1710`. The standard IPv6 header defined in :rfc:`2460` occupies 40 bytes and contains 8 different fields, as shown in the figure below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">323</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8900cc3ff5f3bd86" weblate-flags="read-only">
        <source>The IP version 6 header (:rfc:`2460`)</source>
        <target state="translated">The IP version 6 header (:rfc:`2460`)</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">329</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="82deb317e0b8d2c5" weblate-flags="read-only">
        <source>Apart from the source and destination addresses, the IPv6 header contains the following fields :</source>
        <target state="translated">Apart from the source and destination addresses, the IPv6 header contains the following fields :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">331</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b951efc14a22c412" weblate-flags="read-only">
        <source>`Version` : a 4 bits field set to `6` and intended to allow IP to evolve in the future if needed</source>
        <target state="translated">`Version` : a 4 bits field set to `6` and intended to allow IP to evolve in the future if needed</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">333</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2a1a1cd7680d80f5" weblate-flags="read-only">
        <source>`Traffic class` : this 8 bits field indicates the type of service expected by this packet and contains the ``CE`` and ``ECT`` flags that are used by `Explicit Congestion Notification`</source>
        <target state="translated">`Traffic class` : this 8 bits field indicates the type of service expected by this packet and contains the ``CE`` and ``ECT`` flags that are used by `Explicit Congestion Notification`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">334</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5c144d8833ef308f" weblate-flags="read-only">
        <source>`Flow Label` : this field was initially intended to be used to tag packets belonging to the same `flow`. A recent document, :rfc:`6437` describes some possible usages of this field, but it is too early to tell whether it will be really used.</source>
        <target state="translated">`Flow Label` : this field was initially intended to be used to tag packets belonging to the same `flow`. A recent document, :rfc:`6437` describes some possible usages of this field, but it is too early to tell whether it will be really used.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">335</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="320ef6c9b91eb94b" weblate-flags="read-only">
        <source>`Payload Length` : this is the size of the packet payload in bytes. As the length is encoded as a 16 bits field, an IPv6 packet can contain up to 65535 bytes of payload.</source>
        <target state="translated">`Payload Length` : this is the size of the packet payload in bytes. As the length is encoded as a 16 bits field, an IPv6 packet can contain up to 65535 bytes of payload.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">336</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f7075d38d486865b" weblate-flags="read-only">
        <source>`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.</source>
        <target state="translated">`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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">337</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1cd80cd9a722c510" weblate-flags="read-only">
        <source>`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.</source>
        <target state="translated">`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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">338</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0fd7084c0193aaac" weblate-flags="read-only">
        <source>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]_.</source>
        <target state="translated">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]_.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">341</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ded23eb32e56d211" weblate-flags="read-only">
        <source>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 :</source>
        <target state="translated">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 :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">343</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c4596be63ba1e340" weblate-flags="read-only">
        <source>``TCP`` uses `Next Header` number ``6``</source>
        <target state="translated">``TCP`` uses `Next Header` number ``6``</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">345</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d13410621ccc7c16" weblate-flags="read-only">
        <source>``UDP`` uses `Next Header` number ``17``</source>
        <target state="translated">``UDP`` uses `Next Header` number ``17``</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">346</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="83077115cac54e62" weblate-flags="read-only">
        <source>``SCTP`` uses `Next Header` number ``132``</source>
        <target state="translated">``SCTP`` uses `Next Header` number ``132``</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">347</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2d20567fd45ae1b1" weblate-flags="read-only">
        <source>For example, an IPv6 packet that contains an TCP segment would appear as shown in the figure below.</source>
        <target state="translated">For example, an IPv6 packet that contains an TCP segment would appear as shown in the figure below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">349</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="92c3e86f48e0107d" weblate-flags="read-only">
        <source>An IPv6 packet containing an TCP segment</source>
        <target state="translated">An IPv6 packet containing an TCP segment</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">354</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="cc7e57d580d93e0f" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">358</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0863e2baba7ee8a9" weblate-flags="read-only">
        <source>:rfc:`2460` defines several types of IPv6 extension headers that could be added to an IPv6 packet :</source>
        <target state="translated">:rfc:`2460` defines several types of IPv6 extension headers that could be added to an IPv6 packet :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">360</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5b32dfc3df9352d4" weblate-flags="read-only">
        <source>`Hop-by-Hop Options` header. This option is processed by routers and hosts.</source>
        <target state="translated">`Hop-by-Hop Options` header. This option is processed by routers and hosts.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">362</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c40faf6cebe14b04" weblate-flags="read-only">
        <source>`Destination Options` header. This option is processed only by hosts.</source>
        <target state="translated">`Destination Options` header. This option is processed only by hosts.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">363</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="04a8c66a5f62d3c1" weblate-flags="read-only">
        <source>`Routing` header. This option is processed by some nodes.</source>
        <target state="translated">`Routing` header. This option is processed by some nodes.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">364</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e30710d898f9b744" weblate-flags="read-only">
        <source>`Fragment` header. This option is processed only by hosts.</source>
        <target state="translated">`Fragment` header. This option is processed only by hosts.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">365</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="14f6f61d5864218f" weblate-flags="read-only">
        <source>`Authentication` header. This option is processed only by hosts.</source>
        <target state="translated">`Authentication` header. This option is processed only by hosts.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">366</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6692793ed538bf8c" weblate-flags="read-only">
        <source>`Encapsulating Security Payload`. This option is processed only by hosts.</source>
        <target state="translated">`Encapsulating Security Payload`. This option is processed only by hosts.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">367</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="736abce0f6841a9c" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">369</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a8f3adf003abcbd7" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">371</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="eb1abd0df10c9969" weblate-flags="read-only">
        <source>The IPv6 `Hop-by-Hop Options` header</source>
        <target state="translated">The IPv6 `Hop-by-Hop Options` header</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">376</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7503c40d954cef7e" weblate-flags="read-only">
        <source>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 :</source>
        <target state="translated">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 :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">378</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="728d41ad415e0827" weblate-flags="read-only">
        <source>``00`` : if a node does not recognize this header, it  can be safely skipped and the processing continues with the subsequent header</source>
        <target state="translated">``00`` : if a node does not recognize this header, it  can be safely skipped and the processing continues with the subsequent header</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">380</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="76c84238195a4f6c" weblate-flags="read-only">
        <source>``01`` : if a node does not recognize this header, the packet must be discarded</source>
        <target state="translated">``01`` : if a node does not recognize this header, the packet must be discarded</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">381</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3087e6e385c87437" weblate-flags="read-only">
        <source>``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)</source>
        <target state="translated">``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)</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">382</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="697d41d11a7d844c" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">384</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e50c500ee679083a" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">388</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c3991f071823acad" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">391</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="17f2f8887a1340ff" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">395</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="96c9477b6c848151" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">399</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="fde26275094166df" weblate-flags="read-only">
        <source>Datalink layer</source>
        <target state="translated">Datalink layer</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">402</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7fa2f641bdba3630" weblate-flags="read-only">
        <source>MTU</source>
        <target state="translated">MTU</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">402</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f02a9d72d0eaf293" weblate-flags="read-only">
        <source>Ethernet</source>
        <target state="translated">Ethernet</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">404</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f6bfd313c7ce5af3" weblate-flags="read-only">
        <source>1500 bytes</source>
        <target state="translated">1500 bytes</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">404</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a0df8453fbfedecd" weblate-flags="read-only">
        <source>WiFi</source>
        <target state="translated">WiFi</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">405</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="65f48ebb952ae4ff" weblate-flags="read-only">
        <source>2272 bytes</source>
        <target state="translated">2272 bytes</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">405</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="70c75d7fe70d6034" weblate-flags="read-only">
        <source>ATM (AAL5)</source>
        <target state="translated">ATM (AAL5)</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">406</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="93a55db3a81253fc" weblate-flags="read-only">
        <source>9180 bytes</source>
        <target state="translated">9180 bytes</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">406</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="614c55caeb6b1be0" weblate-flags="read-only">
        <source>802.15.4</source>
        <target state="translated">802.15.4</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">407</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9a1200088cccead8" weblate-flags="read-only">
        <source>102 or 81 bytes</source>
        <target state="translated">102 or 81 bytes</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">407</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d16d2867daa23ffa" weblate-flags="read-only">
        <source>Token Ring</source>
        <target state="translated">Token Ring</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">408</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1b11bb9dbb1eaef2" weblate-flags="read-only">
        <source>4464 bytes</source>
        <target state="translated">4464 bytes</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">408</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0f1b84de78a1ba79" weblate-flags="read-only">
        <source>FDDI</source>
        <target state="translated">FDDI</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">409</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="fe13506b55cd79a9" weblate-flags="read-only">
        <source>4352 bytes</source>
        <target state="translated">4352 bytes</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">409</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a9a2ada369f7423e" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">412</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="72e3ebbfc4be4ba5" weblate-flags="read-only">
        <source>The need for fragmentation and reassembly</source>
        <target state="translated">The need for fragmentation and reassembly</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">418</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3428ec85c401e7bd" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">422</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d1bb787a0feacb8e" weblate-flags="read-only">
        <source>IPv6 fragmentation header</source>
        <target state="translated">IPv6 fragmentation header</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">427</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="456d726dbb9c7b72" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">429</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d00a96cdc4bd243d" weblate-flags="read-only">
        <source>In IPv6, fragmentation is performed exclusively by the source host and relies on the fragmentation header. This 64 bits header is composed of six fields :</source>
        <target state="translated">In IPv6, fragmentation is performed exclusively by the source host and relies on the fragmentation header. This 64 bits header is composed of six fields :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">433</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1458918295b09581" weblate-flags="read-only">
        <source>a `Next Header` field that indicates the type of the header that follows the fragmentation header</source>
        <target state="translated">a `Next Header` field that indicates the type of the header that follows the fragmentation header</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">435</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1a378ae03c1a39ef" weblate-flags="read-only">
        <source>two `Reserved` fields set to `0`.</source>
        <target state="translated">two `Reserved` fields set to `0`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">436</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6de96cc24bd40b55" weblate-flags="read-only">
        <source>the `Fragment Offset` is a 13-bit unsigned integer that contains the offset, in 8 bytes units, of the data following this header, relative to the start of the original packet.</source>
        <target state="translated">the `Fragment Offset` is a 13-bit unsigned integer that contains the offset, in 8 bytes units, of the data following this header, relative to the start of the original packet.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">437</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c916b27e2c28dd43" weblate-flags="read-only">
        <source>the `More` flag, which is set to `0` in the last fragment of a packet and to `1` in all other fragments.</source>
        <target state="translated">the `More` flag, which is set to `0` in the last fragment of a packet and to `1` in all other fragments.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">438</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="23f06ddbc8b19f76" weblate-flags="read-only">
        <source>the 32-bit `Identification` field indicates to which original packet a fragment belongs. When a host sends fragmented packets, it should ensure that it does not reuse the same `identification` field for packets sent to the same destination during a period of `MSL` seconds. This is easier with the 32 bits `identification` used in the IPv6 fragmentation header, than with the 16 bits `identification` field of the IPv4 header.</source>
        <target state="translated">the 32-bit `Identification` field indicates to which original packet a fragment belongs. When a host sends fragmented packets, it should ensure that it does not reuse the same `identification` field for packets sent to the same destination during a period of `MSL` seconds. This is easier with the 32 bits `identification` used in the IPv6 fragmentation header, than with the 16 bits `identification` field of the IPv4 header.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">439</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="aa465f61bee5e5ca" weblate-flags="read-only">
        <source>Some IPv6 implementations send the fragments of a packet in increasing fragment offset order, starting from the first fragment. Others send the fragments in reverse order, starting from the last fragment. The latter solution can be advantageous for the host that needs to reassemble the fragments, as it can easily allocate the buffer required to reassemble all fragments of the packet upon reception of the last fragment. When a host receives the first fragment of an IPv6 packet, it cannot know a priori the length of the entire IPv6 packet.</source>
        <target state="translated">Some IPv6 implementations send the fragments of a packet in increasing fragment offset order, starting from the first fragment. Others send the fragments in reverse order, starting from the last fragment. The latter solution can be advantageous for the host that needs to reassemble the fragments, as it can easily allocate the buffer required to reassemble all fragments of the packet upon reception of the last fragment. When a host receives the first fragment of an IPv6 packet, it cannot know a priori the length of the entire IPv6 packet.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">445</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="16718077d1b185b2" weblate-flags="read-only">
        <source>The figure below provides an example of a fragmented IPv6 packet containing a UDP segment. The `Next Header` type reserved for the IPv6 fragmentation option is 44.</source>
        <target state="translated">The figure below provides an example of a fragmented IPv6 packet containing a UDP segment. The `Next Header` type reserved for the IPv6 fragmentation option is 44.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">447</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4049f1e1daec731a" weblate-flags="read-only">
        <source>IPv6 fragmentation example</source>
        <target state="translated">IPv6 fragmentation example</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">453</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="25a16eaf5f4c11a6" weblate-flags="read-only">
        <source>The following pseudo-code details the IPv6 fragmentation, assuming that the packet does not contain options.</source>
        <target state="translated">The following pseudo-code details the IPv6 fragmentation, assuming that the packet does not contain options.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">455</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4f4001107a7ac1b9" weblate-flags="read-only">
        <source>In the above pseudocode, we maintain a single 32 bits counter that is incremented for each packet that needs to be fragmented. Other implementations to compute the packet identification are possible. :rfc:`2460` only requires that two fragmented packets that are sent within the MSL between the same pair of hosts have different identifications.</source>
        <target state="translated">In the above pseudocode, we maintain a single 32 bits counter that is incremented for each packet that needs to be fragmented. Other implementations to compute the packet identification are possible. :rfc:`2460` only requires that two fragmented packets that are sent within the MSL between the same pair of hosts have different identifications.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">490</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f87e8ad57b0f86de" weblate-flags="read-only">
        <source>The fragments of an IPv6 packet may arrive at the destination in any order, as each fragment is forwarded independently in the network and may follow different paths. Furthermore, some fragments may be lost and never reach the destination.</source>
        <target state="translated">The fragments of an IPv6 packet may arrive at the destination in any order, as each fragment is forwarded independently in the network and may follow different paths. Furthermore, some fragments may be lost and never reach the destination.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">492</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="15488477e1f24e10" weblate-flags="read-only">
        <source>The reassembly algorithm used by the destination host is roughly as follows. First, the destination can verify whether a received IPv6 packet is a fragment or not by checking whether it contains a fragment header. If so, all fragments with the some identification must be reassembled together. The reassembly algorithm relies on the `Identification` field of the received fragments to associate a fragment with the corresponding packet being reassembled. Furthermore, the `Fragment Offset` field indicates the position of the fragment payload in the original non-fragmented packet. Finally, the packet with the `M` flag reset allows the destination to determine the total length of the original non-fragmented packet.</source>
        <target state="translated">The reassembly algorithm used by the destination host is roughly as follows. First, the destination can verify whether a received IPv6 packet is a fragment or not by checking whether it contains a fragment header. If so, all fragments with the some identification must be reassembled together. The reassembly algorithm relies on the `Identification` field of the received fragments to associate a fragment with the corresponding packet being reassembled. Furthermore, the `Fragment Offset` field indicates the position of the fragment payload in the original non-fragmented packet. Finally, the packet with the `M` flag reset allows the destination to determine the total length of the original non-fragmented packet.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">494</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f75d762ab8a4486d" weblate-flags="read-only">
        <source>Note that the reassembly algorithm must deal with the unreliability of the IP network. This implies that a fragment may be duplicated or a fragment may never reach the destination. The destination can easily detect fragment duplication thanks to the `Fragment Offset`. To deal with fragment losses, the reassembly algorithm must bind the time during which the fragments of a packet are stored in its buffer while the packet is being reassembled. This can be implemented by starting a timer when the first fragment of a packet is received. If the packet has not been reassembled upon expiration of the timer, all fragments are discarded and the packet is considered to be lost.</source>
        <target state="translated">Note that the reassembly algorithm must deal with the unreliability of the IP network. This implies that a fragment may be duplicated or a fragment may never reach the destination. The destination can easily detect fragment duplication thanks to the `Fragment Offset`. To deal with fragment losses, the reassembly algorithm must bind the time during which the fragments of a packet are stored in its buffer while the packet is being reassembled. This can be implemented by starting a timer when the first fragment of a packet is received. If the packet has not been reassembled upon expiration of the timer, all fragments are discarded and the packet is considered to be lost.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">496</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f2da7ea53485fe76" weblate-flags="read-only">
        <source>Header compression on low bandwidth links</source>
        <target state="translated">Header compression on low bandwidth links</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">499</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="161508a5d7afd25e" weblate-flags="read-only">
        <source>Given the size of the IPv6 header, it can cause huge overhead on low bandwidth links, especially when small packets are exchanged such as for Voice over IP applications. In such environments, several techniques can be used to reduce the overhead. A first solution is to use data compression in the datalink layer to compress all the information exchanged [Thomborson1992]_. These techniques are similar to the data compression algorithms used in tools such as :manpage:`compress(1)` or :manpage:`gzip(1)` :rfc:`1951`. They compress streams of bits without taking advantage of the fact that these streams contain IP packets with a known structure. A second solution is to compress the IP and TCP header. These header compression techniques, such as the one defined in :rfc:`5795` take advantage of the redundancy found in successive packets from the same flow to significantly reduce the size of the protocol headers. Another solution is to define a compressed encoding of the IPv6 header that matches the capabilities of the underlying datalink layer :rfc:`4944`.</source>
        <target state="translated">Given the size of the IPv6 header, it can cause huge overhead on low bandwidth links, especially when small packets are exchanged such as for Voice over IP applications. In such environments, several techniques can be used to reduce the overhead. A first solution is to use data compression in the datalink layer to compress all the information exchanged [Thomborson1992]_. These techniques are similar to the data compression algorithms used in tools such as :manpage:`compress(1)` or :manpage:`gzip(1)` :rfc:`1951`. They compress streams of bits without taking advantage of the fact that these streams contain IP packets with a known structure. A second solution is to compress the IP and TCP header. These header compression techniques, such as the one defined in :rfc:`5795` take advantage of the redundancy found in successive packets from the same flow to significantly reduce the size of the protocol headers. Another solution is to define a compressed encoding of the IPv6 header that matches the capabilities of the underlying datalink layer :rfc:`4944`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">501</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="79558b8f30986638" weblate-flags="read-only">
        <source>The last type of `IPv6 header extension` is the `Routing` header. The ``type 0`` routing header defined in :rfc:`2460` is an example of an IPv6 option that must be processed by some routers. This option is encoded as shown below.</source>
        <target state="translated">The last type of `IPv6 header extension` is the `Routing` header. The ``type 0`` routing header defined in :rfc:`2460` is an example of an IPv6 option that must be processed by some routers. This option is encoded as shown below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">503</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9172cf3479c5c859" weblate-flags="read-only">
        <source>The Type 0 routing header (:rfc:`2460`)</source>
        <target state="translated">The Type 0 routing header (:rfc:`2460`)</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">509</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4cf6a93c40ed7b80" weblate-flags="read-only">
        <source>The type 0 routing option was intended to allow a host to indicate a loose source route that should be followed by a packet by specifying the addresses of some of the routers that must forward this packet. Unfortunately, further work with this routing header, including an entertaining demonstration with scapy_ [BE2007]_ , revealed severe security problems with this routing header. For this reason, loose source routing with the type 0 routing header has been removed from the IPv6 specification :rfc:`5095`.</source>
        <target state="translated">The type 0 routing option was intended to allow a host to indicate a loose source route that should be followed by a packet by specifying the addresses of some of the routers that must forward this packet. Unfortunately, further work with this routing header, including an entertaining demonstration with scapy_ [BE2007]_ , revealed severe security problems with this routing header. For this reason, loose source routing with the type 0 routing header has been removed from the IPv6 specification :rfc:`5095`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">512</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0482f84ad346df86" weblate-flags="read-only">
        <source>ICMP version 6</source>
        <target state="translated">ICMP version 6</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">520</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a98ebd264e5a5cda" weblate-flags="read-only">
        <source>It is sometimes necessary for intermediate routers or the destination host to inform the sender of the packet of a problem that occurred while processing a packet. In the TCP/IP protocol suite, this reporting is done by the Internet Control Message Protocol (ICMP). ICMPv6 is defined in :rfc:`4443`. It is used both to report problems that occurred while processing an IPv6 packet, but also to distribute addresses.</source>
        <target state="translated">It is sometimes necessary for intermediate routers or the destination host to inform the sender of the packet of a problem that occurred while processing a packet. In the TCP/IP protocol suite, this reporting is done by the Internet Control Message Protocol (ICMP). ICMPv6 is defined in :rfc:`4443`. It is used both to report problems that occurred while processing an IPv6 packet, but also to distribute addresses.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">522</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="23a006a2db0d5bec" weblate-flags="read-only">
        <source>ICMPv6 messages are carried inside IPv6 packets (the `Next Header` field for ICMPv6 is ``58``). Each ICMP message contains a 32 bits header with an 8 bits `type` field, a `code` field and a 16 bits checksum computed over the entire ICMPv6 message. The message body contains a copy of the IPv6 packet in error.</source>
        <target state="translated">ICMPv6 messages are carried inside IPv6 packets (the `Next Header` field for ICMPv6 is ``58``). Each ICMP message contains a 32 bits header with an 8 bits `type` field, a `code` field and a 16 bits checksum computed over the entire ICMPv6 message. The message body contains a copy of the IPv6 packet in error.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">524</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0734c6e8164d87e7" weblate-flags="read-only">
        <source>ICMP version 6 packet format</source>
        <target state="translated">ICMP version 6 packet format</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">530</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d04247966b664c19" weblate-flags="read-only">
        <source>ICMPv6 specifies two classes of messages : error messages that indicate a problem in handling a packet and informational messages. Four types of error messages are defined in :rfc:`4443` :</source>
        <target state="translated">ICMPv6 specifies two classes of messages : error messages that indicate a problem in handling a packet and informational messages. Four types of error messages are defined in :rfc:`4443` :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">533</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="357aae78d32afb4e" weblate-flags="read-only">
        <source>``1`` : `Destination Unreachable`. Such an ICMPv6 message is sent when the destination address of a packet is unreachable. The `code` field of the ICMP header contains additional information about the type of unreachability. The following codes are specified in :rfc:`4443`</source>
        <target state="translated">``1`` : `Destination Unreachable`. Such an ICMPv6 message is sent when the destination address of a packet is unreachable. The `code` field of the ICMP header contains additional information about the type of unreachability. The following codes are specified in :rfc:`4443`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">539</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="908be4a6fd1e9d75" weblate-flags="read-only">
        <source>Destination Unreachable. Such an ICMPv6 message is sent when the destination address of a packet is unreachable. The code field of the ICMP header contains additional information about the type of unreachability. The following codes are specified in RFC 4443</source>
        <target state="translated">Destination Unreachable. Such an ICMPv6 message is sent when the destination address of a packet is unreachable. The code field of the ICMP header contains additional information about the type of unreachability. The following codes are specified in RFC 4443</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">538</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="79664200f8508922" weblate-flags="read-only">
        <source>``0`` : No route to destination. This indicates that the router that sent the ICMPv6 message did not have a route towards the packet's destination</source>
        <target state="translated">``0`` : No route to destination. This indicates that the router that sent the ICMPv6 message did not have a route towards the packet's destination</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">536</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b95f297a2325d75c" weblate-flags="read-only">
        <source>``1`` : Communication with destination administratively prohibited. This indicates that a firewall has refused to forward the packet towards its final destination.</source>
        <target state="translated">``1`` : Communication with destination administratively prohibited. This indicates that a firewall has refused to forward the packet towards its final destination.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">537</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="387e950859efa792" weblate-flags="read-only">
        <source>``2`` : Beyond scope of source address. This message can be sent if the source is using link-local addresses to reach a global unicast address outside its subnet.</source>
        <target state="translated">``2`` : Beyond scope of source address. This message can be sent if the source is using link-local addresses to reach a global unicast address outside its subnet.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">538</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="fc2ccce444713efe" weblate-flags="read-only">
        <source>``3`` : Address unreachable. This message indicates that the packet reached the subnet of the destination, but the host that owns this destination address cannot be reached.</source>
        <target state="translated">``3`` : Address unreachable. This message indicates that the packet reached the subnet of the destination, but the host that owns this destination address cannot be reached.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">539</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2925c923d783f842" weblate-flags="read-only">
        <source>``4`` : Port unreachable. This message indicates that the IPv6 packet was received by the destination, but there was no application listening to the specified port.</source>
        <target state="translated">``4`` : Port unreachable. This message indicates that the IPv6 packet was received by the destination, but there was no application listening to the specified port.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">540</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="deb0c53a13f8dee9" weblate-flags="read-only">
        <source>``2`` : Packet Too Big. The router that was to send the ICMPv6 message received an IPv6 packet that is larger than the MTU of the outgoing link. The ICMPv6 message contains the MTU of this link in bytes. This allows the sending host to implement Path MTU discovery :rfc:`1981`</source>
        <target state="translated">``2`` : Packet Too Big. The router that was to send the ICMPv6 message received an IPv6 packet that is larger than the MTU of the outgoing link. The ICMPv6 message contains the MTU of this link in bytes. This allows the sending host to implement Path MTU discovery :rfc:`1981`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">541</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e7d2540f9b599b9a" weblate-flags="read-only">
        <source>``3`` : Time Exceeded. This error message can be sent either by a router or by a host. A router would set `code` to `0` to report the reception of a packet whose `Hop Limit` reached `0`. A host would set `code` to `1` to report that it was unable to reassemble received IPv6 fragments.</source>
        <target state="translated">``3`` : Time Exceeded. This error message can be sent either by a router or by a host. A router would set `code` to `0` to report the reception of a packet whose `Hop Limit` reached `0`. A host would set `code` to `1` to report that it was unable to reassemble received IPv6 fragments.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">542</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="eaa327792125c1ff" weblate-flags="read-only">
        <source>``4`` : Parameter Problem. This ICMPv6 message is used to report either the reception of an IPv6 packet with an erroneous header field (code `0`) or an unknown `Next Header` or IP option (codes `1` and `2`). In this case, the message body contains the erroneous IPv6 packet and the first 32 bits of the message body contain a pointer to the error.</source>
        <target state="translated">``4`` : Parameter Problem. This ICMPv6 message is used to report either the reception of an IPv6 packet with an erroneous header field (code `0`) or an unknown `Next Header` or IP option (codes `1` and `2`). In this case, the message body contains the erroneous IPv6 packet and the first 32 bits of the message body contain a pointer to the error.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">543</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0712439f6d6ec0a6" weblate-flags="read-only">
        <source>The `Destination Unreachable` ICMP error message is returned when a packet cannot be forwarded to its final destination. The first four ICMPv6 error messages (type ``1``, codes ``0-3``)  are generated by routers while hosts may return code ``4`` when there is no application bound to the corresponding port number.</source>
        <target state="translated">The `Destination Unreachable` ICMP error message is returned when a packet cannot be forwarded to its final destination. The first four ICMPv6 error messages (type ``1``, codes ``0-3``)  are generated by routers while hosts may return code ``4`` when there is no application bound to the corresponding port number.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">546</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6f290fcb49d29136" weblate-flags="read-only">
        <source>The `Packet Too Big` ICMP messages enable the source host to discover the MTU size that it can safely use to reach a given destination. To understand its operation, consider the (academic) scenario shown in the figure below. In this figure, the labels on each link represent the maximum packet size supported by this link.</source>
        <target state="translated">The `Packet Too Big` ICMP messages enable the source host to discover the MTU size that it can safely use to reach a given destination. To understand its operation, consider the (academic) scenario shown in the figure below. In this figure, the labels on each link represent the maximum packet size supported by this link.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">548</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ec36e3af76cec4b8" weblate-flags="read-only">
        <source>If ``A`` sends a 1500 bytes packet, ``R1`` will return an ICMPv6 error message indicating a maximum packet length of 1400 bytes. ``A`` would then fragment the packet before retransmitting it. The small fragment would go through, but the large fragment will be refused by ``R2`` that would return an ICMPv6 error message. ``A`` can fragment again the packet and send it to the final destination as two fragments.</source>
        <target state="translated">If ``A`` sends a 1500 bytes packet, ``R1`` will return an ICMPv6 error message indicating a maximum packet length of 1400 bytes. ``A`` would then fragment the packet before retransmitting it. The small fragment would go through, but the large fragment will be refused by ``R2`` that would return an ICMPv6 error message. ``A`` can fragment again the packet and send it to the final destination as two fragments.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">570</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0436c6ea2ac25ba2" weblate-flags="read-only">
        <source>In practice, an IPv6 implementation does not store the transmitted packets to be able to retransmit them if needed. However, since TCP (and SCTP) buffer the segments that they transmit, a similar approach can be used in transport protocols to detect the largest MTU on a path towards a given destination. This technique is called PathMTU Discovery :rfc:`1981`.</source>
        <target state="translated">In practice, an IPv6 implementation does not store the transmitted packets to be able to retransmit them if needed. However, since TCP (and SCTP) buffer the segments that they transmit, a similar approach can be used in transport protocols to detect the largest MTU on a path towards a given destination. This technique is called PathMTU Discovery :rfc:`1981`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">572</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8ef2eb964d23a9cb" weblate-flags="read-only">
        <source>When a TCP segment is transported in an IP packet that is fragmented in the network, the loss of a single fragment forces TCP to retransmit the entire segment (and thus all the fragments). If TCP was able to send only packets that do not require fragmentation in the network, it could retransmit only the information that was lost in the network. In addition, IP reassembly causes several challenges at high speed as discussed in :rfc:`4963`. Using IP fragmentation to allow UDP applications to exchange large messages raises several security issues [KPS2003]_.</source>
        <target state="translated">When a TCP segment is transported in an IP packet that is fragmented in the network, the loss of a single fragment forces TCP to retransmit the entire segment (and thus all the fragments). If TCP was able to send only packets that do not require fragmentation in the network, it could retransmit only the information that was lost in the network. In addition, IP reassembly causes several challenges at high speed as discussed in :rfc:`4963`. Using IP fragmentation to allow UDP applications to exchange large messages raises several security issues [KPS2003]_.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">576</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c5a5b8e50622373f" weblate-flags="read-only">
        <source>ICMPv6 is used by TCP implementations to discover the largest MTU size that is allowed to reach a destination host without causing network fragmentation. A TCP implementation parses the `Packets Too Big` ICMP messages that it receives. These ICMP messages contain the MTU of the router's outgoing link in their `Data` field. Upon reception of such an ICMP message, the source TCP implementation adjusts its Maximum Segment Size (MSS) so that the packets containing the segments that it sends can be forwarded by this router without requiring fragmentation.</source>
        <target state="translated">ICMPv6 is used by TCP implementations to discover the largest MTU size that is allowed to reach a destination host without causing network fragmentation. A TCP implementation parses the `Packets Too Big` ICMP messages that it receives. These ICMP messages contain the MTU of the router's outgoing link in their `Data` field. Upon reception of such an ICMP message, the source TCP implementation adjusts its Maximum Segment Size (MSS) so that the packets containing the segments that it sends can be forwarded by this router without requiring fragmentation.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">578</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c8ecf31ccf59d65b" weblate-flags="read-only">
        <source>Two types of informational ICMPv6 messages are defined in :rfc:`4443` : `echo request` and `echo reply`, which are used to test the reachability of a destination by using :manpage:`ping6(8)`. Each host is supposed [#fpingproblems]_ to reply with an ICMP `Echo reply` message when it receives an  ICMP `Echo request` message. A sample usage of :manpage:`ping6(8)` is shown below.</source>
        <target state="translated">Two types of informational ICMPv6 messages are defined in :rfc:`4443` : `echo request` and `echo reply`, which are used to test the reachability of a destination by using :manpage:`ping6(8)`. Each host is supposed [#fpingproblems]_ to reply with an ICMP `Echo reply` message when it receives an  ICMP `Echo request` message. A sample usage of :manpage:`ping6(8)` is shown below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">583</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4e70ca7a196414d1" weblate-flags="read-only">
        <source>Another very useful debugging tool is :manpage:`traceroute6(8)`. The traceroute man page describes this tool as `"print the route packets take to network host"`. traceroute uses the `Time exceeded` ICMP messages to discover the intermediate routers on the path towards a destination. The principle behind traceroute is very simple. When a router receives an IP packet whose `Hop Limit` is set to ``1`` it is forced to return to the sending host a `Time exceeded` ICMP message containing the header and the first bytes of the discarded packet. To discover all routers on a network path, a simple solution is to first send a packet whose `Hop Limit` is set to `1`, then a packet whose `Hop Limit` is set to `2`, etc. A sample traceroute6 output is shown below.</source>
        <target state="translated">Another very useful debugging tool is :manpage:`traceroute6(8)`. The traceroute man page describes this tool as `"print the route packets take to network host"`. traceroute uses the `Time exceeded` ICMP messages to discover the intermediate routers on the path towards a destination. The principle behind traceroute is very simple. When a router receives an IP packet whose `Hop Limit` is set to ``1`` it is forced to return to the sending host a `Time exceeded` ICMP message containing the header and the first bytes of the discarded packet. To discover all routers on a network path, a simple solution is to first send a packet whose `Hop Limit` is set to `1`, then a packet whose `Hop Limit` is set to `2`, etc. A sample traceroute6 output is shown below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">605</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="351822374ec96371" weblate-flags="read-only">
        <source>Rate limitation of ICMP messages</source>
        <target state="translated">Rate limitation of ICMP messages</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">627</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="36a38c40770d43f2" weblate-flags="read-only">
        <source>High-end hardware based routers use special purpose chips on their interfaces to forward IPv6 packets at line rate. These chips are optimized to process `correct` IP packets. They are not able to create ICMP messages at line rate. When such a chip receives an IP packet that triggers an ICMP message, it interrupts the main CPU of the router and the software running on this CPU processes the packet. This CPU is much slower than the hardware acceleration found on the interfaces [Gill2004]_. It would be overloaded if it had to process IP packets at line rate and generate one ICMP message for each received packet. To protect this CPU, high-end routers limit the rate at which the hardware can interrupt the main CPU and thus the rate at which ICMP messages can be generated. This implies that not all erroneous IP packets cause the transmission of an ICMP message. The risk of overloading the main CPU of the router is also the reason why using hop-by-hop IPv6 options, including the router alert option is discouraged [#falert]_.</source>
        <target state="translated">High-end hardware based routers use special purpose chips on their interfaces to forward IPv6 packets at line rate. These chips are optimized to process `correct` IP packets. They are not able to create ICMP messages at line rate. When such a chip receives an IP packet that triggers an ICMP message, it interrupts the main CPU of the router and the software running on this CPU processes the packet. This CPU is much slower than the hardware acceleration found on the interfaces [Gill2004]_. It would be overloaded if it had to process IP packets at line rate and generate one ICMP message for each received packet. To protect this CPU, high-end routers limit the rate at which the hardware can interrupt the main CPU and thus the rate at which ICMP messages can be generated. This implies that not all erroneous IP packets cause the transmission of an ICMP message. The risk of overloading the main CPU of the router is also the reason why using hop-by-hop IPv6 options, including the router alert option is discouraged [#falert]_.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">629</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b5c829fe6e1fdb46" weblate-flags="read-only">
        <source>The IPv6 subnet</source>
        <target state="translated">The IPv6 subnet</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">633</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="737a35a3cdd47518" weblate-flags="read-only">
        <source>Until now, we have focused our discussion on the utilization of IPv6 on point-to-point links. Although there are point-to-point links in the Internet, mainly between routers and sometimes hosts, most of the hosts are attached to datalink layer networks such as Ethernet LANs or WiFi networks. These datalink layer networks play an important role in today's Internet and have heavily influenced the design of the operation of IPv6. To understand IPv6 and ICMPv6 completely, we first need to correctly understand the key principles behind these datalink layer technologies.</source>
        <target state="translated">Until now, we have focused our discussion on the utilization of IPv6 on point-to-point links. Although there are point-to-point links in the Internet, mainly between routers and sometimes hosts, most of the hosts are attached to datalink layer networks such as Ethernet LANs or WiFi networks. These datalink layer networks play an important role in today's Internet and have heavily influenced the design of the operation of IPv6. To understand IPv6 and ICMPv6 completely, we first need to correctly understand the key principles behind these datalink layer technologies.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">635</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="72c1647838391b00" weblate-flags="read-only">
        <source>As explained earlier, devices attached to a Local Area Network can directly exchange frames among themselves. For this, each datalink layer interface on a device (host, router, ...) attached to such a network is identified by a MAC address. Each datalink layer interface includes a unique hardwired MAC address. MAC addresses are allocated to manufacturers in blocks and interface is numbered with a unique address. Thanks to the global unicity of the MAC addresses, the datalink layer service can assume that two hosts attached to a LAN have different addresses. Most LANs provide an unreliable connectionless service and a datalink layer frame has a header containing :</source>
        <target state="translated">As explained earlier, devices attached to a Local Area Network can directly exchange frames among themselves. For this, each datalink layer interface on a device (host, router, ...) attached to such a network is identified by a MAC address. Each datalink layer interface includes a unique hardwired MAC address. MAC addresses are allocated to manufacturers in blocks and interface is numbered with a unique address. Thanks to the global unicity of the MAC addresses, the datalink layer service can assume that two hosts attached to a LAN have different addresses. Most LANs provide an unreliable connectionless service and a datalink layer frame has a header containing :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">637</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="087ddd7e5701f607" weblate-flags="read-only">
        <source>the source MAC address</source>
        <target state="translated">the source MAC address</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">639</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="042029603245992a" weblate-flags="read-only">
        <source>the destination MAC address</source>
        <target state="translated">the destination MAC address</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">640</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2dd661bb6e3f6fc1" weblate-flags="read-only">
        <source>some multiplexing information to indicate the network layer protocol that is responsible for the payload of the frame</source>
        <target state="translated">some multiplexing information to indicate the network layer protocol that is responsible for the payload of the frame</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">641</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="61ac83c7a81e32c1" weblate-flags="read-only">
        <source>LANs also provide a broadcast and a multicast service. The broadcast service enables a device to send a single frame to all the devices attached to the same LAN. This is done by reserving a special broadcast  MAC address (typically all bits of the address are set to one). To broadcast a frame, a device simply needs to send a frame whose destination is the broadcast address. All devices attached to the datalink network will receive the frame.</source>
        <target state="translated">LANs also provide a broadcast and a multicast service. The broadcast service enables a device to send a single frame to all the devices attached to the same LAN. This is done by reserving a special broadcast  MAC address (typically all bits of the address are set to one). To broadcast a frame, a device simply needs to send a frame whose destination is the broadcast address. All devices attached to the datalink network will receive the frame.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">643</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="75ab36eef03ad2d0" weblate-flags="read-only">
        <source>The broadcast service allows easily reaching all devices attached to a datalink layer network. It has been widely used to support IP version 4. A drawback of using the broadcast service to support a network layer protocol is that a broadcast frame that contains a network layer packet is always delivered to all devices attached to the datalink network, even if some of these devices do not support the network layer protocol. The multicast service is a useful alternative to the broadcast service. To understand its operation, it is important to understand how a datalink layer interface operates. In shared media LANs, all devices are attached to the same physical medium and all frames are delivered to all devices. When such a frame is received by a datalink layer interface, it compares the destination address with the MAC address of the device. If the two addresses match, or the destination address is the broadcast address, the frame is destined to the device and its payload is delivered to the network layer protocol. The multicast service exploits this principle. A multicast address is a logical address. To receive frames destined to a multicast address in a shared media LAN, a device captures all frames having this multicast address as their destination. All IPv6 nodes are capable of capturing datalink layer frames destined to different multicast addresses.</source>
        <target state="translated">The broadcast service allows easily reaching all devices attached to a datalink layer network. It has been widely used to support IP version 4. A drawback of using the broadcast service to support a network layer protocol is that a broadcast frame that contains a network layer packet is always delivered to all devices attached to the datalink network, even if some of these devices do not support the network layer protocol. The multicast service is a useful alternative to the broadcast service. To understand its operation, it is important to understand how a datalink layer interface operates. In shared media LANs, all devices are attached to the same physical medium and all frames are delivered to all devices. When such a frame is received by a datalink layer interface, it compares the destination address with the MAC address of the device. If the two addresses match, or the destination address is the broadcast address, the frame is destined to the device and its payload is delivered to the network layer protocol. The multicast service exploits this principle. A multicast address is a logical address. To receive frames destined to a multicast address in a shared media LAN, a device captures all frames having this multicast address as their destination. All IPv6 nodes are capable of capturing datalink layer frames destined to different multicast addresses.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">645</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1180e062b43f0065" weblate-flags="read-only">
        <source>Interactions between IPv6 and the datalink layer</source>
        <target state="translated">Interactions between IPv6 and the datalink layer</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">649</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d9bf3be1d160954e" weblate-flags="read-only">
        <source>IPv6 hosts and routers frequently interact with the datalink layer service. To understand the main interactions, it is useful to analyze all the packets that are exchanged when a simple network containing a few hosts and routers is built. Let us first start with a LAN containing two hosts [#fMAC]_.</source>
        <target state="translated">IPv6 hosts and routers frequently interact with the datalink layer service. To understand the main interactions, it is useful to analyze all the packets that are exchanged when a simple network containing a few hosts and routers is built. Let us first start with a LAN containing two hosts [#fMAC]_.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">653</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ea53c6832a75ab49" weblate-flags="read-only">
        <source>Hosts ``A`` and ``B`` are attached to the same datalink layer network. They can thus exchange frames by using the MAC addresses shown in the figure above. To be able to use IPv6 to exchange packets, they need to have an IPv6 address. One possibility would be to manually configure an IPv6 address on each host. However, IPv6 provides a better solution thanks to the `link-local` IPv6 addresses. A `link-local` IPv6 address is an address that is composed by concatenating the ``fe80:://64`` prefix with the MAC address of the device. In the example above, host A would use IPv6 `link-local` address ``fe80::0223:45FF:FE67:89ab`` and host B ``fe80::0234:56FF:FE78:9abc``. With these two IPv6 addresses, the hosts can exchange IPv6 packets.</source>
        <target state="translated">Hosts ``A`` and ``B`` are attached to the same datalink layer network. They can thus exchange frames by using the MAC addresses shown in the figure above. To be able to use IPv6 to exchange packets, they need to have an IPv6 address. One possibility would be to manually configure an IPv6 address on each host. However, IPv6 provides a better solution thanks to the `link-local` IPv6 addresses. A `link-local` IPv6 address is an address that is composed by concatenating the ``fe80:://64`` prefix with the MAC address of the device. In the example above, host A would use IPv6 `link-local` address ``fe80::0223:45FF:FE67:89ab`` and host B ``fe80::0234:56FF:FE78:9abc``. With these two IPv6 addresses, the hosts can exchange IPv6 packets.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">671</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2401c2378cbf3ac4" weblate-flags="read-only">
        <source>Converting MAC addresses in host identifiers</source>
        <target state="translated">Converting MAC addresses in host identifiers</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">673</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6ff4c33ae2f86e50" weblate-flags="read-only">
        <source>Appendix A of :rfc:`4291` provides the algorithm used to convert a 48 bits MAC address into a 64 bits host identifier. This algorithm builds upon the structure of the MAC addresses. A MAC address is represented as shown in the figure below.</source>
        <target state="translated">Appendix A of :rfc:`4291` provides the algorithm used to convert a 48 bits MAC address into a 64 bits host identifier. This algorithm builds upon the structure of the MAC addresses. A MAC address is represented as shown in the figure below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">675</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4cceed0cb8d12175" weblate-flags="read-only">
        <source>A MAC address</source>
        <target state="translated">A MAC address</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">680</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c18d0890f1fdf69f" weblate-flags="read-only">
        <source>MAC addresses are allocated in blocks of :math:`2^{20}`. When a company registers for a block of MAC addresses, it receives an identifier. company identifier is then used to populated the `c` bits of the MAC addresses. The company can allocate all addresses in starting with this prefix and manages the `m` bits as it wishes.</source>
        <target state="translated">MAC addresses are allocated in blocks of :math:`2^{20}`. When a company registers for a block of MAC addresses, it receives an identifier. company identifier is then used to populated the `c` bits of the MAC addresses. The company can allocate all addresses in starting with this prefix and manages the `m` bits as it wishes.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">682</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="45d5dc3afec33a3d" weblate-flags="read-only">
        <source>A MAC address converted into a 64 bits host identifier</source>
        <target state="translated">A MAC address converted into a 64 bits host identifier</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">687</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="41bb397113e2f44b" weblate-flags="read-only">
        <source>Inside a MAC address, the two bits indicated as `0` and `g` in the figure above play a special role. The first bit indicates whether the address is universal or local. The `g` bit indicates whether this is a multicast address or a unicast address. The MAC address can be converted into a 64 bits host identifier by flipping the value of the `0` bit and inserting ``FFFE``, i.e. ``1111111111111110`` in binary, in the middle of the address as shown in the figure below. The `c`, `m` and `g` bits of the MAC address are not modified.</source>
        <target state="translated">Inside a MAC address, the two bits indicated as `0` and `g` in the figure above play a special role. The first bit indicates whether the address is universal or local. The `g` bit indicates whether this is a multicast address or a unicast address. The MAC address can be converted into a 64 bits host identifier by flipping the value of the `0` bit and inserting ``FFFE``, i.e. ``1111111111111110`` in binary, in the middle of the address as shown in the figure below. The `c`, `m` and `g` bits of the MAC address are not modified.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">689</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a1c87c20665acf01" weblate-flags="read-only">
        <source>The next step is to connect the LAN to the Internet. For this, a router is attached to the LAN.</source>
        <target state="translated">The next step is to connect the LAN to the Internet. For this, a router is attached to the LAN.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">692</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="af4bdd6a70ec6a57" weblate-flags="read-only">
        <source>Assume that the LAN containing the two hosts and the router is assigned prefix ``2001:db8:1234:5678/64``. A first solution to configure the IPv6 addresses in this network is to assign them manually. A possible assignment is :</source>
        <target state="translated">Assume that the LAN containing the two hosts and the router is assigned prefix ``2001:db8:1234:5678/64``. A first solution to configure the IPv6 addresses in this network is to assign them manually. A possible assignment is :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">711</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0629bebb5ca60762" weblate-flags="read-only">
        <source>``2001:db8:1234:5678::1`` is assigned to ``router``</source>
        <target state="translated">``2001:db8:1234:5678::1`` is assigned to ``router``</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">713</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="aaa0e75f93b1cd94" weblate-flags="read-only">
        <source>``2001:db8:1234:5678::AA`` is assigned to ``hostA``</source>
        <target state="translated">``2001:db8:1234:5678::AA`` is assigned to ``hostA``</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">714</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="89fc1eef0ffc2799" weblate-flags="read-only">
        <source>``2001:db8:1234:5678::BB`` is assigned to ``hostB``</source>
        <target state="translated">``2001:db8:1234:5678::BB`` is assigned to ``hostB``</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">715</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ae8be3475705943a" weblate-flags="read-only">
        <source>To be able to exchange IPv6 packets with ``hostB``, ``hostA`` needs to know the MAC address of the interface of ``hostB`` on the LAN. This is the `address resolution` problem. In IPv6, this problem is solved by using the Neighbor Discovery Protocol (NDP). NDP is specified in :rfc:`4861`. This protocol is part of ICMPv6 and uses the multicast datalink layer service.</source>
        <target state="translated">To be able to exchange IPv6 packets with ``hostB``, ``hostA`` needs to know the MAC address of the interface of ``hostB`` on the LAN. This is the `address resolution` problem. In IPv6, this problem is solved by using the Neighbor Discovery Protocol (NDP). NDP is specified in :rfc:`4861`. This protocol is part of ICMPv6 and uses the multicast datalink layer service.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">719</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="17a002b7d52a5f73" weblate-flags="read-only">
        <source>NDP allows a host to discover the MAC address used by any other host attached to the same LAN. NDP operates in two steps. First, the querier sends a multicast ICMPv6 Neighbor Solicitation message that contains as parameter the queried IPv6 address. This multicast ICMPv6 NS is placed inside a multicast frame [#fndpmulti]_. The queried node receives the frame, parses it and replies with a unicast ICMPv6 Neighbor Advertisement that provides its own IPv6 and MAC addresses. Upon reception of the Neighbor Advertisement message, the querier stores the mapping between the IPv6 and the MAC address inside its NDP table. This table is a data structure that maintains a cache of the recently received Neighbor Advertisement. Thanks to this cache, a host only needs to send a Neighbor Solicitation message for the first packet that it sends to a given host. After this initial packet, the NDP table can provide the mapping between the destination IPv6 address and the corresponding MAC address.</source>
        <target state="translated">NDP allows a host to discover the MAC address used by any other host attached to the same LAN. NDP operates in two steps. First, the querier sends a multicast ICMPv6 Neighbor Solicitation message that contains as parameter the queried IPv6 address. This multicast ICMPv6 NS is placed inside a multicast frame [#fndpmulti]_. The queried node receives the frame, parses it and replies with a unicast ICMPv6 Neighbor Advertisement that provides its own IPv6 and MAC addresses. Upon reception of the Neighbor Advertisement message, the querier stores the mapping between the IPv6 and the MAC address inside its NDP table. This table is a data structure that maintains a cache of the recently received Neighbor Advertisement. Thanks to this cache, a host only needs to send a Neighbor Solicitation message for the first packet that it sends to a given host. After this initial packet, the NDP table can provide the mapping between the destination IPv6 address and the corresponding MAC address.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">727</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9324e1e00f8dd884" weblate-flags="read-only">
        <source>The NS message can also be used to verify the reachability of a host in the local subnet. For this usage, NS messages can be sent in unicast since other nodes on the subnet do not need to process the message.</source>
        <target state="translated">The NS message can also be used to verify the reachability of a host in the local subnet. For this usage, NS messages can be sent in unicast since other nodes on the subnet do not need to process the message.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">738</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="aeb3138a29c07df7" weblate-flags="read-only">
        <source>When an entry in the NDP table times out on a host, it may either be deleted or the host may try to validate it by sending the NS message again.</source>
        <target state="translated">When an entry in the NDP table times out on a host, it may either be deleted or the host may try to validate it by sending the NS message again.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">740</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2bcec2025c501c98" weblate-flags="read-only">
        <source>This is not the only usage of the Neighbor Solicitation and Neighbor Advertisement messages. They are also used to detect the utilization of duplicate addresses. In the network above, consider what happens when a new host is connected to the LAN. If this host is configured by mistake with the same address as ``hostA`` (i.e. ``2001:db8:1234:5678::AA``), problems could occur. Indeed, if two hosts have the same IPv6 address on the LAN, but different MAC addresses, it will be difficult to correctly reach them. IPv6 anticipated this problem and includes a `Duplicate Address Detection` Algorithm (DAD). When an IPv6 address [#flinklocal]_ is configured on a host, by any means, the host must verify the uniqueness of this address on the LAN. For this, it multicasts an ICMPv6 Neighbor Solicitation that queries the network for its newly configured address. The IPv6 source address of this NS is set to ``::`` (i.e. the reserved unassigned address) if the host does not already have an IPv6 address on this subnet). If the NS does not receive any answer, the new address is considered to be unique and can safely be used. Otherwise, the new address is refused and an error message should be returned to the system administrator or a new IPv6 address should be generated. The `Duplicate Address Detection` Algorithm can prevent various operational problems that are often difficult to debug.</source>
        <target state="translated">This is not the only usage of the Neighbor Solicitation and Neighbor Advertisement messages. They are also used to detect the utilization of duplicate addresses. In the network above, consider what happens when a new host is connected to the LAN. If this host is configured by mistake with the same address as ``hostA`` (i.e. ``2001:db8:1234:5678::AA``), problems could occur. Indeed, if two hosts have the same IPv6 address on the LAN, but different MAC addresses, it will be difficult to correctly reach them. IPv6 anticipated this problem and includes a `Duplicate Address Detection` Algorithm (DAD). When an IPv6 address [#flinklocal]_ is configured on a host, by any means, the host must verify the uniqueness of this address on the LAN. For this, it multicasts an ICMPv6 Neighbor Solicitation that queries the network for its newly configured address. The IPv6 source address of this NS is set to ``::`` (i.e. the reserved unassigned address) if the host does not already have an IPv6 address on this subnet). If the NS does not receive any answer, the new address is considered to be unique and can safely be used. Otherwise, the new address is refused and an error message should be returned to the system administrator or a new IPv6 address should be generated. The `Duplicate Address Detection` Algorithm can prevent various operational problems that are often difficult to debug.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">747</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a6bba3ee179f26f1" weblate-flags="read-only">
        <source>Few users manually configure the IPv6 addresses on their hosts. They prefer to rely on protocols that can automatically configure their IPv6 addresses. IPv6 supports two such protocols : DHCPv6 and the Stateless Address Autoconfiguration (SLAAC).</source>
        <target state="translated">Few users manually configure the IPv6 addresses on their hosts. They prefer to rely on protocols that can automatically configure their IPv6 addresses. IPv6 supports two such protocols : DHCPv6 and the Stateless Address Autoconfiguration (SLAAC).</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">753</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="100260fe30815abe" weblate-flags="read-only">
        <source>The Stateless Address Autoconfiguration (SLAAC) mechanism defined in :rfc:`4862` enables hosts to automatically configure their addresses without maintaining any state. When a host boots, it derives its identifier from its datalink layer address [#fprivacy]_ as explained earlier and concatenates this 64 bits identifier to the `FE80::/64` prefix to obtain its link-local IPv6 address. It then multicasts a Neighbor Solicitation with its link-local address as a target to verify whether another host is using the same link-local address on this subnet. If it receives a Neighbor Advertisement indicating that the link-local address is used by another host, it generates another 64 bits identifier and sends again a Neighbor Solicitation. If there is no answer, the host considers its link-local address to be valid. This address will be used as the source address for all NDP messages sent on the subnet.</source>
        <target state="translated">The Stateless Address Autoconfiguration (SLAAC) mechanism defined in :rfc:`4862` enables hosts to automatically configure their addresses without maintaining any state. When a host boots, it derives its identifier from its datalink layer address [#fprivacy]_ as explained earlier and concatenates this 64 bits identifier to the `FE80::/64` prefix to obtain its link-local IPv6 address. It then multicasts a Neighbor Solicitation with its link-local address as a target to verify whether another host is using the same link-local address on this subnet. If it receives a Neighbor Advertisement indicating that the link-local address is used by another host, it generates another 64 bits identifier and sends again a Neighbor Solicitation. If there is no answer, the host considers its link-local address to be valid. This address will be used as the source address for all NDP messages sent on the subnet.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">764</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="94f5e66d838a3de7" weblate-flags="read-only">
        <source>To automatically configure its global IPv6 address, the host must know the globally routable IPv6 prefix that is used on the local subnet. IPv6 routers regularly multicast ICMPv6 Router Advertisement messages that indicate the IPv6 prefix assigned to the subnet. The Router Advertisement message contains several interesting fields.</source>
        <target state="translated">To automatically configure its global IPv6 address, the host must know the globally routable IPv6 prefix that is used on the local subnet. IPv6 routers regularly multicast ICMPv6 Router Advertisement messages that indicate the IPv6 prefix assigned to the subnet. The Router Advertisement message contains several interesting fields.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">766</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ba739294b96792bc" weblate-flags="read-only">
        <source>Format of the ICMPv6 Router Advertisement message</source>
        <target state="translated">Format of the ICMPv6 Router Advertisement message</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">772</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a141dc37757ba02b" weblate-flags="read-only">
        <source>This message is sent from the link-local address of the router on the subnet. Its destination is the IPv6 multicast address that targets all IPv6 enabled hosts (i.e. ``ff02::1``). The `Cur Hop Limit` field, if different from zero, allows specifying the default `Hop Limit` that hosts should use when sending IPv6 packets from this subnet. ``64`` is a frequently used value. The `M` and `O` bits are used to indicate that some information can be obtained from DHCPv6. The `Router Lifetime` parameter provides the expected lifetime (in seconds) of the sending router acting as a default router. This lifetime enables planning the replacement of a router by another one in the same subnet. The `Reachable Time` and the `Retrans Timer` parameter are used to configure the utilization of the NDP protocol on the hosts attached to the subnet.</source>
        <target state="translated">This message is sent from the link-local address of the router on the subnet. Its destination is the IPv6 multicast address that targets all IPv6 enabled hosts (i.e. ``ff02::1``). The `Cur Hop Limit` field, if different from zero, allows specifying the default `Hop Limit` that hosts should use when sending IPv6 packets from this subnet. ``64`` is a frequently used value. The `M` and `O` bits are used to indicate that some information can be obtained from DHCPv6. The `Router Lifetime` parameter provides the expected lifetime (in seconds) of the sending router acting as a default router. This lifetime enables planning the replacement of a router by another one in the same subnet. The `Reachable Time` and the `Retrans Timer` parameter are used to configure the utilization of the NDP protocol on the hosts attached to the subnet.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">774</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b78dedc24ab380f7" weblate-flags="read-only">
        <source>Several options can be included in the Router Advertisement message. The simplest one is the MTU option that indicates the MTU to be used within the subnet. Thanks to this option, it is possible to ensure that all devices attached to the same subnet use the same MTU. Otherwise, operational problems could occur. The `Prefix` option is more important. It provides information about the prefix(es) that is (are) advertised by the router on the subnet.</source>
        <target state="translated">Several options can be included in the Router Advertisement message. The simplest one is the MTU option that indicates the MTU to be used within the subnet. Thanks to this option, it is possible to ensure that all devices attached to the same subnet use the same MTU. Otherwise, operational problems could occur. The `Prefix` option is more important. It provides information about the prefix(es) that is (are) advertised by the router on the subnet.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">776</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c2bad57b00ab3cba" weblate-flags="read-only">
        <source>The Prefix information option</source>
        <target state="translated">The Prefix information option</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">782</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="113765ce55e21292" weblate-flags="read-only">
        <source>The key information placed in this option are the prefix and its length. This allows the hosts attached to the subnet to automatically configure their own IPv6 address. The `Valid` and `Preferred` `Lifetimes` provide information about the expected lifetime of the prefixes. Associating some time validity to prefixes is a good practice from an operational viewpoint. There are some situations where the prefix assigned to a subnet needs to change without impacting the hosts attached to the subnet. This is often called the IPv6 renumbering problem in the literature :rfc:`7010`. A very simple scenario is the following. An SME subscribes to one ISP. Its router is attached to another router of this ISP and advertises a prefix assigned by the ISP. The SME is composed of a single subnet and all its hosts rely on stateless address configuration. After a few years, the SME decides to change of network provider. It connects its router to the second ISP and receives a different prefix from this ISP. At this point, two prefixes are advertised on the SME's subnet. The old prefix can be advertised with a short lifetime to ensure that hosts will stop using it while the new one is advertised with a longer lifetime. After sometime, the router stops advertising the old prefix and the hosts stop using it. The old prefix can now be returned back to the first ISP. In larger networks, renumbering an IPv6 remains a difficult operational problem [LeB2009]_.</source>
        <target state="translated">The key information placed in this option are the prefix and its length. This allows the hosts attached to the subnet to automatically configure their own IPv6 address. The `Valid` and `Preferred` `Lifetimes` provide information about the expected lifetime of the prefixes. Associating some time validity to prefixes is a good practice from an operational viewpoint. There are some situations where the prefix assigned to a subnet needs to change without impacting the hosts attached to the subnet. This is often called the IPv6 renumbering problem in the literature :rfc:`7010`. A very simple scenario is the following. An SME subscribes to one ISP. Its router is attached to another router of this ISP and advertises a prefix assigned by the ISP. The SME is composed of a single subnet and all its hosts rely on stateless address configuration. After a few years, the SME decides to change of network provider. It connects its router to the second ISP and receives a different prefix from this ISP. At this point, two prefixes are advertised on the SME's subnet. The old prefix can be advertised with a short lifetime to ensure that hosts will stop using it while the new one is advertised with a longer lifetime. After sometime, the router stops advertising the old prefix and the hosts stop using it. The old prefix can now be returned back to the first ISP. In larger networks, renumbering an IPv6 remains a difficult operational problem [LeB2009]_.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">787</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="bc994507b75736bb" weblate-flags="read-only">
        <source>Upon reception of this message, the host can derive its global IPv6 address by concatenating its 64 bits identifier with the received prefix. It concludes the SLAAC by sending a Neighbor Solicitation message targeted at its global IPv6 address to ensure that no other host is using the same IPv6 address.</source>
        <target state="translated">Upon reception of this message, the host can derive its global IPv6 address by concatenating its 64 bits identifier with the received prefix. It concludes the SLAAC by sending a Neighbor Solicitation message targeted at its global IPv6 address to ensure that no other host is using the same IPv6 address.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">789</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1b42904f3106ab9f" weblate-flags="read-only">
        <source>Router Advertisements and Hop Limits</source>
        <target state="translated">Router Advertisements and Hop Limits</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">791</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5b851e0b0eed94d6" weblate-flags="read-only">
        <source>ICMPv6 Router Advertisements messages are regularly sent by routers. They are destined to all devices attached to the local subnet and no router should ever forward them to another subnet. Still, these messages are sent inside IPv6 packets whose `Hop Limit` is always set to ``255``. Given that the packet should not be forwarded outside of the local subnet, the reader could expect instead a `Hop Limit` set to ``1``. Using a `Hop Limit` set to ``255`` provides one important benefit from a security viewpoint and this hack has been adapted in several Internet protocols. When a host receives a `Router Advertisement` message, it expects that this message has been generated by a router attached to the same subnet. Using a `Hop Limit` of ``255`` provides a simple check for this. If the message was generated by an attacker outside the subnet, it would reach the subnet with a decremented `Hop Limit`. Checking that the `Hop Limit` is set to ``255`` is a simple [#fsend]_ verification that the packet was generated on this particular subnet. :rfc:`5082` provides other examples of protocols that use this hack and discuss its limitations.</source>
        <target state="translated">ICMPv6 Router Advertisements messages are regularly sent by routers. They are destined to all devices attached to the local subnet and no router should ever forward them to another subnet. Still, these messages are sent inside IPv6 packets whose `Hop Limit` is always set to ``255``. Given that the packet should not be forwarded outside of the local subnet, the reader could expect instead a `Hop Limit` set to ``1``. Using a `Hop Limit` set to ``255`` provides one important benefit from a security viewpoint and this hack has been adapted in several Internet protocols. When a host receives a `Router Advertisement` message, it expects that this message has been generated by a router attached to the same subnet. Using a `Hop Limit` of ``255`` provides a simple check for this. If the message was generated by an attacker outside the subnet, it would reach the subnet with a decremented `Hop Limit`. Checking that the `Hop Limit` is set to ``255`` is a simple [#fsend]_ verification that the packet was generated on this particular subnet. :rfc:`5082` provides other examples of protocols that use this hack and discuss its limitations.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">793</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6ddbe02e3c900ccf" weblate-flags="read-only">
        <source>Routers regularly send Router Advertisement messages. These messages are triggered by a timer that is often set at approximately 30 seconds. Usually, hosts wait for the arrival of a Router Advertisement message to configure their address. This implies that hosts could sometimes need to wait 30 seconds before being able to configure their address. If this delay is too long, a host can also send a `Router Solicitation` message. This message is sent towards the multicast address that corresponds to all IPv6 routers (i.e. ``FF01::2``) and the default router will reply.</source>
        <target state="translated">Routers regularly send Router Advertisement messages. These messages are triggered by a timer that is often set at approximately 30 seconds. Usually, hosts wait for the arrival of a Router Advertisement message to configure their address. This implies that hosts could sometimes need to wait 30 seconds before being able to configure their address. If this delay is too long, a host can also send a `Router Solicitation` message. This message is sent towards the multicast address that corresponds to all IPv6 routers (i.e. ``FF01::2``) and the default router will reply.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">796</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6be6f341deac80ae" weblate-flags="read-only">
        <source>The last point that needs to be explained about ICMPv6 is the `Redirect` message. This message is used when there is more than one router on a subnet as shown in the figure below.</source>
        <target state="translated">The last point that needs to be explained about ICMPv6 is the `Redirect` message. This message is used when there is more than one router on a subnet as shown in the figure below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">798</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="38023469313f14f7" weblate-flags="read-only">
        <source>In this network, ``router1`` is the default router for all hosts. The second router, ``router2`` provides connectivity to a specific IPv6 subnet, e.g. ``2001:db8:abcd::/48``. These two routers attached to the same subnet can be used in different ways. First, it is possible to manually configure the routing tables on all hosts to add a route towards ``2001:db8:abcd::/48`` via ``router2``. Unfortunately, forcing such manual configuration boils down all the benefits of using address auto-configuration in IPv6. The second approach is to automatically configure a default route via ``router1`` on all hosts. With such route, when a host needs to send a packet to any address within ``2001:db8:abcd::/48``, it will send it to ``router1``. ``router1`` would consult its routing table and find that the packet needs to be sent again on the subnet to reach ``router2``. This is a waste of time. A better approach would be to enable the hosts to automatically learn the new route. This is possible thanks to the ICMPv6 `Redirect` message. When ``router1`` receives a packet that needs to be forwarded back on the same interface, it replies with a `Redirect` message that indicates that the packet should have been sent via ``router2``. Upon reception of a `Redirect`  message, the host updates it forwarding table to include a new transient entry for the destination reported in the message. A timeout is usually associated with  this transient entry to automatically delete it after some time.</source>
        <target state="translated">In this network, ``router1`` is the default router for all hosts. The second router, ``router2`` provides connectivity to a specific IPv6 subnet, e.g. ``2001:db8:abcd::/48``. These two routers attached to the same subnet can be used in different ways. First, it is possible to manually configure the routing tables on all hosts to add a route towards ``2001:db8:abcd::/48`` via ``router2``. Unfortunately, forcing such manual configuration boils down all the benefits of using address auto-configuration in IPv6. The second approach is to automatically configure a default route via ``router1`` on all hosts. With such route, when a host needs to send a packet to any address within ``2001:db8:abcd::/48``, it will send it to ``router1``. ``router1`` would consult its routing table and find that the packet needs to be sent again on the subnet to reach ``router2``. This is a waste of time. A better approach would be to enable the hosts to automatically learn the new route. This is possible thanks to the ICMPv6 `Redirect` message. When ``router1`` receives a packet that needs to be forwarded back on the same interface, it replies with a `Redirect` message that indicates that the packet should have been sent via ``router2``. Upon reception of a `Redirect`  message, the host updates it forwarding table to include a new transient entry for the destination reported in the message. A timeout is usually associated with  this transient entry to automatically delete it after some time.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">819</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d9892eb37e340c49" weblate-flags="read-only">
        <source>An alternative is the Dynamic Host Configuration Protocol (DHCP) defined in :rfc:`2131` and :rfc:`3315`. DHCP allows a host to automatically retrieve its assigned IPv6 address, but relies on  server. A DHCP server is associated to each subnet [#fdhcpserver]_. Each DHCP server manages a pool of IPv6 addresses assigned to the subnet. When a host is first attached to the subnet, it sends a DHCP request message in a UDP segment (the DHCP server listens on port 67). As the host knows neither its IPv6 address nor the IPv6 address of the DHCP server, this UDP segment is sent inside a multicast packet target at the DHCP servers. The DHCP request may contain various options such as the name of the host, its datalink layer address, etc. The server captures the DHCP request and selects an unassigned address in its address pool. It then sends the assigned IPv6 address in a DHCP reply message which contains the datalink layer address of the host and additional information such as the subnet mask, the address of the default router or the address of the DNS resolver. The DHCP reply also specifies the lifetime of the address allocation. This forces the host to renew its address allocation once it expires. Thanks to the limited lease time, IP addresses are automatically returned to the pool of addresses when  hosts are powered off.</source>
        <target state="translated">An alternative is the Dynamic Host Configuration Protocol (DHCP) defined in :rfc:`2131` and :rfc:`3315`. DHCP allows a host to automatically retrieve its assigned IPv6 address, but relies on  server. A DHCP server is associated to each subnet [#fdhcpserver]_. Each DHCP server manages a pool of IPv6 addresses assigned to the subnet. When a host is first attached to the subnet, it sends a DHCP request message in a UDP segment (the DHCP server listens on port 67). As the host knows neither its IPv6 address nor the IPv6 address of the DHCP server, this UDP segment is sent inside a multicast packet target at the DHCP servers. The DHCP request may contain various options such as the name of the host, its datalink layer address, etc. The server captures the DHCP request and selects an unassigned address in its address pool. It then sends the assigned IPv6 address in a DHCP reply message which contains the datalink layer address of the host and additional information such as the subnet mask, the address of the default router or the address of the DNS resolver. The DHCP reply also specifies the lifetime of the address allocation. This forces the host to renew its address allocation once it expires. Thanks to the limited lease time, IP addresses are automatically returned to the pool of addresses when  hosts are powered off.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">826</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="39f645879137b076" weblate-flags="read-only">
        <source>Both SLAAC and DHCPv6 can be extended to provide additional information beyond the IPv6 prefix/address. For example, :rfc:`6106` defines options for the ICMPv6 ND message that can carry the IPv6 address of the recursive DNS resolver and a list of default domain search suffixes. It is also possible to combine SLAAC with DHCPv6. :rfc:`3736` defines a stateless variant of DHCPv6 that can be used to distribute DNS information while SLAAC is used to distribute the prefixes.</source>
        <target state="translated">Both SLAAC and DHCPv6 can be extended to provide additional information beyond the IPv6 prefix/address. For example, :rfc:`6106` defines options for the ICMPv6 ND message that can carry the IPv6 address of the recursive DNS resolver and a list of default domain search suffixes. It is also possible to combine SLAAC with DHCPv6. :rfc:`3736` defines a stateless variant of DHCPv6 that can be used to distribute DNS information while SLAAC is used to distribute the prefixes.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">828</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c463aea6549199a2" weblate-flags="read-only">
        <source>Footnotes</source>
        <target state="translated">Footnotes</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">834</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d9e8b6d07bd68a64" weblate-flags="read-only">
        <source>The full list of allocated IPv6 multicast addresses is available at http://www.iana.org/assignments/ipv6-multicast-addresses</source>
        <target state="translated">The full list of allocated IPv6 multicast addresses is available at http://www.iana.org/assignments/ipv6-multicast-addresses</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">835</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e9d7b7d0969e9b36" weblate-flags="read-only">
        <source>The IANA_ maintains the list of all allocated Next Header types at http://www.iana.org/assignments/protocol-numbers/</source>
        <target state="translated">The IANA_ maintains the list of all allocated Next Header types at http://www.iana.org/assignments/protocol-numbers/</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">837</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="bae9b891b8a25105" weblate-flags="read-only">
        <source>When IPv4 was designed, the situation was different. The IPv4 header includes a checksum that only covers the network header. This checksum is computed by the source and updated by all intermediate routers that decrement the TTL, which is the IPv4 equivalent of the `HopLimit` used by IPv6.</source>
        <target state="translated">When IPv4 was designed, the situation was different. The IPv4 header includes a checksum that only covers the network header. This checksum is computed by the source and updated by all intermediate routers that decrement the TTL, which is the IPv4 equivalent of the `HopLimit` used by IPv6.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">839</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b34e7466ae8a8719" weblate-flags="read-only">
        <source>Until a few years ago, all hosts replied to `Echo request` ICMP messages. However, due to the security problems that have affected TCP/IP implementations, many of these implementations can now be configured to disable answering `Echo request` ICMP messages.</source>
        <target state="translated">Until a few years ago, all hosts replied to `Echo request` ICMP messages. However, due to the security problems that have affected TCP/IP implementations, many of these implementations can now be configured to disable answering `Echo request` ICMP messages.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">841</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="30582640eeb1f7ec" weblate-flags="read-only">
        <source>For a discussion of the issues with the router alert IP option, see http://tools.ietf.org/html/draft-rahman-rtg-router-alert-dangerous-00 or http://tools.ietf.org/html/draft-rahman-rtg-router-alert-considerations-03</source>
        <target state="translated">For a discussion of the issues with the router alert IP option, see http://tools.ietf.org/html/draft-rahman-rtg-router-alert-dangerous-00 or http://tools.ietf.org/html/draft-rahman-rtg-router-alert-considerations-03</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">843</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ec3a3fddbeec0502" weblate-flags="read-only">
        <source>For simplicity, you assume that each datalink layer interface is assigned a 64 bits MAC address. As we will see later, today's datalink layer technologies mainly use 48 bits MAC addresses, but the smaller addresses can easily be converted into 64 bits addresses.</source>
        <target state="translated">For simplicity, you assume that each datalink layer interface is assigned a 64 bits MAC address. As we will see later, today's datalink layer technologies mainly use 48 bits MAC addresses, but the smaller addresses can easily be converted into 64 bits addresses.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">846</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="28691ccaaf077723" weblate-flags="read-only">
        <source>:rfc:`4291` and :rfc:`4861` explain in more details how the IPv6 multicast address is determined from the target IPv6 unicast address. These details are outside the scope of this book, but may matter if you try to understand a packet trace.</source>
        <target state="translated">:rfc:`4291` and :rfc:`4861` explain in more details how the IPv6 multicast address is determined from the target IPv6 unicast address. These details are outside the scope of this book, but may matter if you try to understand a packet trace.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">848</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2f760062715f48d8" weblate-flags="read-only">
        <source>The DAD algorithm is also used with `link-local` addresses.</source>
        <target state="translated">The DAD algorithm is also used with `link-local` addresses.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">850</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8728d521391c53ee" weblate-flags="read-only">
        <source>Using a datalink layer address to derive a 64 bits identifier for each host raises privacy concerns as the host will always use the same identifier. Attackers could use this to track hosts on the Internet. An extension to the Stateless Address Configuration mechanism that does not raise privacy concerns is defined in :rfc:`4941`. These privacy extensions allow a host to generate its 64 bits identifier randomly every time it attaches to a subnet. It then becomes impossible for an attacker to use the 64-bits identifier to track a host.</source>
        <target state="translated">Using a datalink layer address to derive a 64 bits identifier for each host raises privacy concerns as the host will always use the same identifier. Attackers could use this to track hosts on the Internet. An extension to the Stateless Address Configuration mechanism that does not raise privacy concerns is defined in :rfc:`4941`. These privacy extensions allow a host to generate its 64 bits identifier randomly every time it attaches to a subnet. It then becomes impossible for an attacker to use the 64-bits identifier to track a host.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">852</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="118603f9168993bf" weblate-flags="read-only">
        <source>Using a `Hop Limit` of ``255`` prevents one family of attacks against ICMPv6, but other attacks still remain possible. A detailed discussion of the security issues with IPv6 is outside the scope of this book. It is possible to secure NDP by using the `Cryptographically Generated IPv6 Addresses` (CGA) defined in :rfc:`3972`. The Secure Neighbor Discovery Protocol is defined in :rfc:`3971`. A detailed discussion of the security of IPv6 may be found in [HV2008]_.</source>
        <target state="translated">Using a `Hop Limit` of ``255`` prevents one family of attacks against ICMPv6, but other attacks still remain possible. A detailed discussion of the security issues with IPv6 is outside the scope of this book. It is possible to secure NDP by using the `Cryptographically Generated IPv6 Addresses` (CGA) defined in :rfc:`3972`. The Secure Neighbor Discovery Protocol is defined in :rfc:`3971`. A detailed discussion of the security of IPv6 may be found in [HV2008]_.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">857</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="cb0073ed582f50b8" weblate-flags="read-only">
        <source>In practice, there is usually one DHCP server per group of subnets and the routers capture on each subnet the DHCP messages and forward them to the DHCP server.</source>
        <target state="translated">In practice, there is usually one DHCP server per group of subnets and the routers capture on each subnet the DHCP messages and forward them to the DHCP server.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ipv6.rst</context>
          <context context-type="linenumber">859</context>
        </context-group>
      </trans-unit>
    </body>
  </file>
</xliff>
