Exit Zen
23
../../exercises/trace.rst:114
English
You can now use your understanding of wireshark_ and tcpdump_ to analyze a 2-minutes long packet trace.
0/1030 · 103
23
../../protocols/bgp.rst:78
English
the `import filter` that specifies, for each peering relationship, the routes that can be accepted from the neighboring domain (the non-acceptable routes are ignored and the domain never uses them to forward packets)
0/2160 · 216
23
../../protocols/congestion.rst:118
English
The third difficulty is to allow an ECN-capable sender to detect whether the remote host also supports ECN. This is a classical negotiation of extensions to a transport protocol. In TCP, this could have been solved by defining a new TCP option used during the three-way handshake. To avoid wasting space in the TCP options, the designers of ECN opted in :rfc:`3168` for using the `ECN-Echo` and `CWR` bits in the TCP header to perform this negotiation. In the end, the result is the same with fewer bits exchanged.
0/5140 · 514
23
../../protocols/dnssec.rst:220
English
There are several details of the operation of DNSSEC that are worth being discussed. First, a server that supports DNSSEC must have a public-private key pair. The public key is distributed with the `DNSKEY` record. The private key is never distributed and it does not even need to be stored on the server that uses the public key. DNSSEC does not require the DNSSEC servers to perform any operation that requires a private key in real time. All the `RRSIG` records can be computed offline, possibly on a different server than the server that returns the DNSSEC replies. The initial motivation for this design choice was the CPU complexity of computing the `RRSIG` signatures for zones that contain millions of records. In the early days of DNSSEC, this was an operational constraint. Today, this is less an issue, but avoiding costly signature operations in real time has two important benefits. First, this reduces the risk of denial of service attacks since an attacker cannot force a DNSSEC server to perform computationally intensive signing operations. Second, the private key can be stored offline, which means that even if an attacker gains access to the DNSSEC server, it cannot retrieve its private key. Using offline signatures for the `RRSIG` records has some practical implications that are reflected in the content of this record. First, each `RRSIG` record contains the original TTL of the signed record. When DNS resolvers cache records, they change the value of the TTL of these cached records and then return the modified records to their clients. When a resolver receives a signed DNS record, it must replace the received TTL of the record with the original TTL (and check that the received TTL is smaller than the original one) before checking the signature. Second, the `RRSIG` records contain a validity period, i.e. a starting time and an ending time for the validity of the signature. This period is specified as two timestamps. This period is only the validity of the signature. It does not affect the TTL of the signed record and is independent from the TTL. In practice, the validity period is important to allow DNS server operators to update their public/private keys. When such a key is changed, e.g. because the private could have been compromised, there is some period of time during which records signed with the two keys coexist in the network. The validity period allows ensuring that old signatures do not remain in DNS caches for ever.
0/24710 · 2471
23
../../protocols/email.rst:124
English
Several other optional header lines are defined in :rfc:`5322` and elsewhere [#femailheaders]_. Furthermore, many email clients and servers define their own header lines starting from `X-`. Several of the optional header lines defined in :rfc:`5322` are worth being discussed here :
0/2820 · 282
23
../../protocols/ethernet.rst:156
English
A hierarchical Ethernet network composed of hubs
0/480 · 48
23
../../protocols/http.rst:110
English
A simple HTML page
0/180 · 18
23
../../protocols/http2.rst:155
English
The information exchanged over an HTTP/2.0 session is composed of frames. A frame starts with a 9 bytes-long header that carries several types of information. The HTTP/2.0 frames have a variable length. The `Length` field of the header contains the length of the frame payload in bytes. As this field is encoded as a 24 bits field, an HTTP/2.0 frame cannot be longer than :math:`2^{24} -1` bytes. It should be noted that :rfc:`7540` assumes a maximum size of :math:`2^{14}` bytes, i.e. 16,384 bytes for the HTTP/2.0 frame payload unless a longer maximum frame length has been negotiated at the beginning of the session using the HTTP/2.0 `Settings` frame that will be described later. The next field of the frames header indicates the frame type. The first frame types are `Data` which contains data from web objects and `Headers` containing HTTP/2.0 headers. When a client retrieves a web object from a server, it always receives an HTTP/2.0 `Headers` frame followed by an HTTP/2.0 `Data` frame. The `Headers` frame information contains essentially the same HTTP headers as the ones supported by HTTP/1.1, but those are encoded by leveraging a data compression technique that minimizes the number of bytes required to transmit them.
0/12330 · 1233
23
../../protocols/ipv6.rst:105
English
IPv6 addressing architecture
0/280 · 28
23
../../protocols/ethernet.rst:59
English
The last field of the Ethernet frame is a 32 bit Cyclical Redundancy Check (CRC). This CRC is able to catch a much larger number of transmission errors than the Internet checksum used by IP, UDP and TCP [SGP98]_. The format of the Ethernet frame is shown below.
0/2610 · 261
23
../../protocols/routing.rst:75
English
Internal router : A router whose directly connected networks belong to the area
0/790 · 79
23
../../protocols/rpc.rst:100
English
The second sub-problem is how to reach the callee. A simple solution to this problem is to make sure that the callee listens on a specific port on the remote machine and then exchange information with this server process. This is the solution chosen for JSON-RPC [JSON-RPC2]_. JSON-RPC can be used over the connectionless or the connection-oriented transport service. A JSON-RPC request contains the following fields:
0/4170 · 417
23
../../protocols/ssh.rst:204
English
a key used by the client (resp. server) to encrypt the data that it sends
0/730 · 73
23
../../protocols/tcp.rst:50
English
the `RST` is used in case of problems or when an invalid segment has been received
0/820 · 82
23
../../protocols/tls.rst:47
English
990
0/100 · 3
23
../../protocols/transport-service.rst:65
English
The second transport service is the connection-oriented service. On the Internet, this service is often called the `byte-stream service` as it creates a reliable byte stream between the two applications that are linked by a transport connection. Like the datagram service, the networked applications that use the byte-stream service are identified by the host on which they run and a port number. These hosts can be identified by an address or a name. The figure below illustrates two applications that are using the byte-stream service provided by the TCP protocol on IPv6 hosts. The byte stream service provided by TCP is reliable and bidirectional.
0/6510 · 651
23
../../protocols/udp.rst:74
English
the entire UDP segment, including its header
0/440 · 44
23
../../protocols/wifi.rst:24
English
11 Mbps
0/100 · 7
24
../../bibliography.rst:74
English
Feldmeier, D. C., `Fast software implementation of error detection codes <https://dx.doi.org/10.1109/90.477710>`_. IEEE/ACM Transactions Networking 3, 6 (Dec. 1995), 640-651.
0/1740 · 174
24
../../glossary.rst:24
English
broadcast
0/100 · 9