Exit Zen
11
../../exercises/dns.rst:39
English
dig_ also contains some additional parameters and flags that are described in the man page. Among these, the `+trace` flag allows to trace all requests that are sent when recursively contacting DNS servers.
0/2060 · 206
11
../../exercises/http.rst:31
English
The `ipvfoo <https://code.google.com/p/ipvfoo/>`_ extension on google chrome allows the user to visually detect whether a website is using IPv6 and IPv4, but also to see which web sites have been contacted when rendering a given web page. Some websites are distributed over several dozens of different servers. Can you find one ?
0/3290 · 329
11
../../exercises/ipv6.rst:40 • ../../exercises/ipv6.rst:149
English
router ``R1`` uses address ``2001:db8:1341:1::1`` on its West interface, address ``2001:db8:1341:12::1`` on its East interface and address ``2001:db8:1341:13::1`` on its South interface
0/1850 · 185
11
../../exercises/lan.rst:77
English
In the network represented in Fig. 4, can the host `H0` communicate with `H1` and vice-versa? Explain. Add whatever you need in the network to allow them to communicate.
0/1690 · 169
11
../../exercises/routing-policies.rst:133
English
Consider the network below in which a stub domain, `AS456`, is connected to two providers `AS123` and `AS789`. `AS456` advertises its prefix to both its providers. On the other hand, `AS123` advertises ``2001:db8:dead::/48`` while `AS789` advertises ``2001:db8:beef::/48`` and ``2001:db8:dead:cafe::/63``. Via which provider will the packets destined to ``2001:db8:dead:cafe::1`` will be received by `AS456` ?
0/4090 · 409
11
../../exercises/routing-protocols.rst:152
English
The password to access this daemon is `zebra`. It supports various commands that are described in the `FRRouting documentation <http://docs.frrouting.org/en/latest/ospf6d.html#showing-ospf6-information>`_ We briefly illustrate some of them below.
0/2460 · 246
11
../../exercises/tcp-2.rst:57
English
Let us start with the execution of a system call. A simple example is shown below.
0/820 · 82
11
../../exercises/trace.rst:71
English
The TCP connection is then closed by exchanging three segments, the first two having the `FIN` flag set.
0/1040 · 104
11
../../protocols/bgp.rst:43
English
There are different types of economical relationships that can exist between domains. Interdomain routing converts these relationships into peering relationships between domains that are connected via peering links.
0/2150 · 215
11
../../protocols/congestion.rst:37
English
The figure below illustrates the evolution of the congestion window when the network is lightly congested and all lost segments can be retransmitted using fast retransmit. The sender begins with a slow-start. A segment is lost but successfully retransmitted by a fast retransmit. The congestion window is divided by 2 and the sender immediately enters congestion avoidance as this was a mild congestion.
0/4030 · 403
11
../../protocols/dnssec.rst:125
English
Let us illustrate it on an example. Assume that Alice frequently uses the `example.net` domain and in particular the web server whose name is `www.example.net`. Mallory would like to redirect the TCP connections established by Alice towards `www.example.net` to one IP address that he controls. Assume that Mallory controls the `mallory.net` domain. Mallory can tune the DNS server of his domain and add special DNS records to the responses that it sends. An attack could go roughly as follows. Mallory forces Alice to visit the `www.mallory.net` web site. He can achieve this by sending a spam message to Alice or buying advertisements on a web site visited by Alice and redirect one of these advertisements to `www.mallory.net`. When visiting the advertisement, Alice's DNS resolver will send a DNS request for `www.mallory.net`. Since Mallory control the DNS server, he can easily add in the response a `AAAA` record that associates `www.example.net` to the IP address controlled by Mallory. If Alice's DNS library does not check the returned response, the cache entry for `www.example.net` will be replaced by the `AAAA` record sent by Mallory.
0/11480 · 1148
11
../../protocols/email.rst:60
English
a `header` that plays the same role as the letterhead in regular mail. It contains metadata about the message.
0/1100 · 110
11
../../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
11
../../protocols/http.rst:50
English
A standardized protocol to efficiently retrieve the documents stored on a server
0/800 · 80
11
../../protocols/http2.rst:62
English
A second way to improve the web performance is to reduce the time required to retrieve web objects. While the first web servers returned an HTML documents with possibly a few images, today's rich web servers return one HTML document with associated style sheets, javascript code, images, fonts, ... Some of these web objects come from the original server while others are hosted on different servers. Today, a typical web page contains almost 2 MBytes of data on average. The size of the web pages continues to grow according to statistics collected by `httparchive.org`. Web pages targeted to mobile devices are slightly smaller.
0/6300 · 630
11
../../protocols/ipv6.rst:79
English
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.
0/10040 · 1004
11
../../protocols/ppp.rst:27
English
PPP frame format
0/160 · 16
11
../../protocols/ppp.rst:34
English
Footnotes
0/100 · 9
11
../../protocols/rpc.rst:25
English
Encoding data
0/130 · 13
11
../../protocols/ssh.rst:86
English
Message Authentication Code (MAC)
0/330 · 33