<?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="653655da7ccdf5ca" weblate-flags="read-only">
        <source>The Point-to-Point Protocol</source>
        <target state="translated">The Point-to-Point Protocol</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ppp.rst</context>
          <context context-type="linenumber">7</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6b8cf977dc261428" weblate-flags="read-only">
        <source>Many point-to-point datalink layers [#flapb]_ have been developed, starting in the 1960s. In this section, we focus on the protocols that are often used to transport IP packets between hosts or routers that are directly connected by a point-to-point link. This link can be a dedicated physical cable, a leased line through the telephone network or a dial-up connection with modems on the two communicating hosts.</source>
        <target state="translated">Many point-to-point datalink layers [#flapb]_ have been developed, starting in the 1960s. In this section, we focus on the protocols that are often used to transport IP packets between hosts or routers that are directly connected by a point-to-point link. This link can be a dedicated physical cable, a leased line through the telephone network or a dial-up connection with modems on the two communicating hosts.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ppp.rst</context>
          <context context-type="linenumber">9</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="12c5a49b2b63ead5" weblate-flags="read-only">
        <source>The first solution to transport IP packets over a serial line was proposed in :rfc:`1055` and is known as `Serial Line IP` (SLIP). SLIP is a simple character stuffing technique applied to IP packets. SLIP defines two special characters : `END` (decimal 192) and `ESC` (decimal 219). `END` appears at the beginning and at the end of each transmitted IP packet and the sender adds `ESC` before each `END` character inside each transmitted IP packet. SLIP only supports the transmission of IP packets and it assumes that the two communicating hosts/routers have been manually configured with each other's IP address. SLIP was mainly used over links offering bandwidth of often less than 20 Kbps.  On such a low bandwidth link, sending 20 bytes of IP header followed by 20 bytes of TCP header for each TCP segment takes a lot of time. This initiated the development of a family of compression techniques to efficiently compress the TCP/IP headers. The first header compression technique proposed in :rfc:`1144` was designed to exploit the redundancy between several consecutive segments that belong to the same TCP connection. In all these segments, the IP addresses and port numbers are always the same. Furthermore, fields such as the sequence and acknowledgment numbers do not change in a random way. :rfc:`1144` defined simple techniques to reduce the redundancy found in successive segments. The development of header compression techniques continued and there are still improvements being developed now :rfc:`5795`.</source>
        <target state="translated">The first solution to transport IP packets over a serial line was proposed in :rfc:`1055` and is known as `Serial Line IP` (SLIP). SLIP is a simple character stuffing technique applied to IP packets. SLIP defines two special characters : `END` (decimal 192) and `ESC` (decimal 219). `END` appears at the beginning and at the end of each transmitted IP packet and the sender adds `ESC` before each `END` character inside each transmitted IP packet. SLIP only supports the transmission of IP packets and it assumes that the two communicating hosts/routers have been manually configured with each other's IP address. SLIP was mainly used over links offering bandwidth of often less than 20 Kbps.  On such a low bandwidth link, sending 20 bytes of IP header followed by 20 bytes of TCP header for each TCP segment takes a lot of time. This initiated the development of a family of compression techniques to efficiently compress the TCP/IP headers. The first header compression technique proposed in :rfc:`1144` was designed to exploit the redundancy between several consecutive segments that belong to the same TCP connection. In all these segments, the IP addresses and port numbers are always the same. Furthermore, fields such as the sequence and acknowledgment numbers do not change in a random way. :rfc:`1144` defined simple techniques to reduce the redundancy found in successive segments. The development of header compression techniques continued and there are still improvements being developed now :rfc:`5795`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ppp.rst</context>
          <context context-type="linenumber">13</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4b45af35ec68ae41" weblate-flags="read-only">
        <source>While SLIP was implemented and used in some environments, it had several limitations discussed in :rfc:`1055`. The `Point-to-Point Protocol` (PPP) was designed shortly after and is specified in :rfc:`1548`. PPP aims to support IP and other network layer protocols over various types of serial lines. PPP is in fact a family of three protocols that are used together :</source>
        <target state="translated">While SLIP was implemented and used in some environments, it had several limitations discussed in :rfc:`1055`. The `Point-to-Point Protocol` (PPP) was designed shortly after and is specified in :rfc:`1548`. PPP aims to support IP and other network layer protocols over various types of serial lines. PPP is in fact a family of three protocols that are used together :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ppp.rst</context>
          <context context-type="linenumber">15</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3561d3af55d9ebf5" weblate-flags="read-only">
        <source>The `Point-to-Point Protocol` defines the framing technique to transport network layer packets.</source>
        <target state="translated">The `Point-to-Point Protocol` defines the framing technique to transport network layer packets.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ppp.rst</context>
          <context context-type="linenumber">17</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7e3fe6b8021e2a8f" weblate-flags="read-only">
        <source>The `Link Control Protocol` that is used to negotiate options and authenticate the session by using username and password or other types of credentials</source>
        <target state="translated">The `Link Control Protocol` that is used to negotiate options and authenticate the session by using username and password or other types of credentials</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ppp.rst</context>
          <context context-type="linenumber">18</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="83a8af0236f482a0" weblate-flags="read-only">
        <source>The `Network Control Protocol` that is specific for each network layer protocol. It is used to negotiate options that are specific for each protocol. For example, IPv4's NCP :rfc:`1548` can negotiate the IPv4 address to be used, the IPv4 address of the DNS resolver. IPv6's NCP is defined in :rfc:`5072`.</source>
        <target state="translated">The `Network Control Protocol` that is specific for each network layer protocol. It is used to negotiate options that are specific for each protocol. For example, IPv4's NCP :rfc:`1548` can negotiate the IPv4 address to be used, the IPv4 address of the DNS resolver. IPv6's NCP is defined in :rfc:`5072`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ppp.rst</context>
          <context context-type="linenumber">19</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="49ef13356396da54" weblate-flags="read-only">
        <source>The PPP framing :rfc:`1662` was inspired by the datalink layer protocols standardized by ITU-T and ISO. A typical PPP frame is composed of the fields shown in the figure below. A PPP frame starts with a one byte flag containing `01111110`. PPP can use bit stuffing or character stuffing depending on the environment where the protocol is used. The address and control fields are present for backward compatibility reasons. The 16 bit Protocol field contains the identifier [#fpppid]_ of the network layer protocol that is carried in the PPP frame. `0x002d` is used for an IPv4 packet compressed with :rfc:`1144` while `0x002f` is used for an uncompressed IPv4 packet. `0xc021` is used by the Link Control Protocol, `0xc023` is used by the Password Authentication Protocol (PAP). `0x0057` is used for IPv6 packets. PPP supports variable length packets, but LCP can negotiate a maximum packet length. The PPP frame ends with a Frame Check Sequence. The default is a 16 bits CRC, but some implementations can negotiate a 32 bits CRC. The frame ends with the `01111110` flag.</source>
        <target state="translated">The PPP framing :rfc:`1662` was inspired by the datalink layer protocols standardized by ITU-T and ISO. A typical PPP frame is composed of the fields shown in the figure below. A PPP frame starts with a one byte flag containing `01111110`. PPP can use bit stuffing or character stuffing depending on the environment where the protocol is used. The address and control fields are present for backward compatibility reasons. The 16 bit Protocol field contains the identifier [#fpppid]_ of the network layer protocol that is carried in the PPP frame. `0x002d` is used for an IPv4 packet compressed with :rfc:`1144` while `0x002f` is used for an uncompressed IPv4 packet. `0xc021` is used by the Link Control Protocol, `0xc023` is used by the Password Authentication Protocol (PAP). `0x0057` is used for IPv6 packets. PPP supports variable length packets, but LCP can negotiate a maximum packet length. The PPP frame ends with a Frame Check Sequence. The default is a 16 bits CRC, but some implementations can negotiate a 32 bits CRC. The frame ends with the `01111110` flag.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ppp.rst</context>
          <context context-type="linenumber">21</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5232cb21df16b2d8" weblate-flags="read-only">
        <source>PPP frame format</source>
        <target state="translated">PPP frame format</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ppp.rst</context>
          <context context-type="linenumber">27</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="594d8e541b849c3f" weblate-flags="read-only">
        <source>PPP played a key role in allowing Internet Service Providers to provide dial-up access over modems in the late 1990s and early 2000s. ISPs operated modem banks connected to the telephone network. For these ISPs, a key issue was to authenticate each user connected through the telephone network. This authentication was performed by using the `Extensible Authentication Protocol` (EAP) defined in :rfc:`3748`. EAP is a simple, but extensible protocol that was initially used by access routers to authenticate the users connected through dial-up lines. Several authentication methods, starting from the simple username/password pairs to more complex schemes have been defined and implemented. When ISPs started to upgrade their physical infrastructure to provide Internet access over `Asymmetric Digital Subscriber Lines` (ADSL), they tried to reuse their existing authentication (and billing) systems. To meet these requirements, the IETF developed specifications to allow PPP frames to be transported over other networks than the point-to-point links for which PPP was designed. Nowadays, most ADSL deployments use PPP over either ATM :rfc:`2364` or Ethernet :rfc:`2516`.</source>
        <target state="translated">PPP played a key role in allowing Internet Service Providers to provide dial-up access over modems in the late 1990s and early 2000s. ISPs operated modem banks connected to the telephone network. For these ISPs, a key issue was to authenticate each user connected through the telephone network. This authentication was performed by using the `Extensible Authentication Protocol` (EAP) defined in :rfc:`3748`. EAP is a simple, but extensible protocol that was initially used by access routers to authenticate the users connected through dial-up lines. Several authentication methods, starting from the simple username/password pairs to more complex schemes have been defined and implemented. When ISPs started to upgrade their physical infrastructure to provide Internet access over `Asymmetric Digital Subscriber Lines` (ADSL), they tried to reuse their existing authentication (and billing) systems. To meet these requirements, the IETF developed specifications to allow PPP frames to be transported over other networks than the point-to-point links for which PPP was designed. Nowadays, most ADSL deployments use PPP over either ATM :rfc:`2364` or Ethernet :rfc:`2516`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ppp.rst</context>
          <context context-type="linenumber">31</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/ppp.rst</context>
          <context context-type="linenumber">34</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8c81cf3037d4e08d" weblate-flags="read-only">
        <source>`LAPB &lt;http://en.wikipedia.org/wiki/LAPB&gt;`_ and `HDLC &lt;http://en.wikipedia.org/wiki/HDLC&gt;`_ were widely used datalink layer protocols.</source>
        <target state="translated">`LAPB &lt;http://en.wikipedia.org/wiki/LAPB&gt;`_ and `HDLC &lt;http://en.wikipedia.org/wiki/HDLC&gt;`_ were widely used datalink layer protocols.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ppp.rst</context>
          <context context-type="linenumber">35</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="36bc4f0244004224" weblate-flags="read-only">
        <source>The IANA maintains the registry of all assigned PPP protocol fields at : http://www.iana.org/assignments/ppp-numbers</source>
        <target state="translated">The IANA maintains the registry of all assigned PPP protocol fields at : http://www.iana.org/assignments/ppp-numbers</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ppp.rst</context>
          <context context-type="linenumber">37</context>
        </context-group>
      </trans-unit>
    </body>
  </file>
</xliff>
