Exit Zen
26
../../exercises/routing-protocols.rst:357
English
We can observe the RIPng messages that are exchanged over the network. :rfc:`2080` defines two types of RIPng messages:
0/1190 · 119
26
../../exercises/tcp-2.rst:145
English
Another interesting features of packetdrill_ is that it is possible to inspect the state maintained by the Linux kernel for the underlying connection using the ``TCP_INFO`` socket option. This makes it possible to retrieve the value of some variables of the TCP control block.
0/2760 · 276
26
../../protocols/bgp.rst:84
English
A domain's import and export filters can be defined by using the Route Policy Specification Language (RPSL) specified in :rfc:`2622` [GAVE1999]_ . Some Internet Service Providers, notably in Europe, use RPSL to document [#fripedb]_ their import and export policies. Several tools help to easily convert a RPSL policy into router commands.
0/3380 · 338
26
../../protocols/congestion.rst:146
English
To solve this problem, :rfc:`3168` uses an additional bit in the TCP header : the `Congestion Window Reduced` (CWR) bit.
0/1200 · 120
26
../../protocols/dnssec.rst:288
English
Given the above security risks, DNSSEC opted for a different approach that allows the negative replies to be authenticated by using offline signatures. The `NSEC` record exploits the lexicographical ordering of all the domain names. To understand its usage, consider a simple domain that contains three names (the associated `AAAA` and other records that are not shown) :
0/3710 · 371
26
../../protocols/email.rst:128
English
the `Received:` header line is used when an email message is processed by several servers before reaching its destination. Each intermediate email server adds a `Received:` header line. These header lines are useful to debug problems in delivering email messages.
0/2630 · 263
26
../../protocols/ethernet.rst:169
English
Standard
0/100 · 8
26
../../protocols/http.rst:116
English
a `method`, that indicates the type of request, a URI, and the version of the HTTP protocol used by the client
0/1100 · 110
26
../../protocols/http2.rst:167
English
Consider now that the first object is 12500 bytes long and the second 125 bytes long. With a 1 Mbps connection, this object will use the underlying connection during 100 milliseconds. The client will thus need to wait 100 milliseconds to retrieve the second object. This is the `Head of Line` (HoL) blocking problem that affects the performance of many web services. If the short web object is a javascript code that requests other web objects, its retrieval may be critical to display the retrieved web page.
0/5090 · 509
26
../../protocols/ipv6.rst:111
English
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 :
0/3470 · 347
26
../../protocols/ethernet.rst:72
English
The transport and datalink layers usually chose different strategies to place their CRCs or checksums. Transport layer protocols usually place their CRCs or checksums in the segment header. Datalink layer protocols sometimes place their CRC in the frame header, but often in a trailer at the end of the frame. This choice reflects implementation assumptions, but also influences performance :rfc:`893`. When the CRC is placed in the trailer, as in Ethernet, the datalink layer can compute it while transmitting the frame and insert it at the end of the transmission. All Ethernet interfaces use this optimization today. When the checksum is placed in the header, as in a TCP segment, it is impossible for the network interface to compute it while transmitting the segment. Some network interfaces provide hardware assistance to compute the TCP checksum, but this is more complex than if the TCP checksum were placed in the trailer [#ftso]_.
0/9400 · 940
26
../../protocols/routing.rst:84
English
OSPF areas
0/100 · 10
26
../../protocols/rpc.rst:104
English
`params`: a structure that contains the values of the parameters that are passed to the method
0/940 · 94
26
../../protocols/ssh.rst:211
English
It is common practice among designers of security protocols to never use the same key for different purposes. For example, allowing the client and the server to use the same key to encrypt data could enable an attacker to launch a replay attack by sending to the client data that it has itself encrypted.
0/3040 · 304
26
../../protocols/tcp.rst:53
English
the `PSH` flag is used as a notification from the sender to indicate to the receiver that it should pass all the data it has received to the receiving process. However, in practice TCP implementations do not allow TCP users to indicate when the `PSH` flag should be set.
0/2700 · 270
26
../../protocols/tls.rst:84
English
A TLS session is divided in two phases: the handshake and the data transfer. During the handshake, the client and the server negotiate the security parameters and the keys that will be used to secure the data transfer. During the second phase, all the messages exchanged are encrypted and authenticated with the negotiated algorithms and keys.
0/3430 · 343
26
../../protocols/udp.rst:90
English
This limitation is due to the fact that the network layer cannot transport packets that are larger than 64 KBytes. As UDP does not include any segmentation/reassembly mechanism, it cannot split a SDU before sending it. The UDP header consumes 8 bytes and the IPv6 header 60. With IPv4, the IPv4 header only consumes 20 bytes and thus the maximum UDP payload size is 65507 bytes.
0/3780 · 378
26
../../protocols/wifi.rst:25
English
19 Mbps
0/100 · 7
27
../../bibliography.rst:93
English
ISO, `Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473) <http://standards.iso.org/ittf/PubliclyAvailableStandards/c030932_ISO_IEC_10589_2002(E).zip>`_ , 2002
0/3080 · 308
27
../../glossary.rst:131
English
Classless Inter Domain Routing is the current address allocation architecture for IP version 4. It was defined in :rfc:`1518` and :rfc:`4632`.
0/1420 · 142