Exit Zen
14
../../exercises/transport.rst:126
English
Practice
9/100 · 8
14
../../principles/naming.rst:77
English
The Domain Name System was created at a time when the Internet was mainly used in North America. The initial design assumed that all domain names would be composed of letters and digits :rfc:`1035`. As Internet usage grew in other parts of the world, it became important to support non-ASCII characters. For this, extensions have been proposed to the Domain Name System :rfc:`3490`. In a nutshell, the solution that is used to support Internationalized Domain Names works as follows. First, it is possible to use most of the Unicode characters to encode domain names and hostnames, with a few exceptions (for example, the dot character cannot be part of a name since it is used as a separator). Once a domain name has been encoded as a series of Unicode characters, it is then converted into a string that contains the ``xn--`` prefix and a sequence of ASCII characters. More details on these algorithms can be found in :rfc:`3490` and :rfc:`3492`.
1139/9480 · 948
14
../../principles/referencemodels.rst:56
English
The `Datalink layer` builds on the service provided by the underlying physical layer. The `Datalink layer` allows two hosts that are directly connected through the physical layer to exchange information. The unit of information exchanged between two entities in the `Datalink layer` is a frame. A frame is a finite sequence of bits. Some `Datalink layers` use variable-length frames while others only use fixed-length frames. Some `Datalink layers` provide a connection-oriented service while others provide a connectionless service. Some `Datalink layers` provide reliable delivery while others do not guarantee the correct delivery of the information.
751/6530 · 653
14
../../principles/network.rst:74
English
To send one byte of information to host `B`, host `A` needs to place this information inside a `packet`. In addition to the data being transmitted, the packet also contains either the addresses of the source and the destination nodes or information that indicates the path that needs to be followed to reach the destination.
329/3240 · 324
14
../../principles/reliability.rst:51
English
:math:`10^3`
12/120 · 12
14
../../principles/transport.rst:34
English
Bob : `You're welcome`
20/220 · 22
14
../../protocols/dns.rst:52
English
The `TTL` field indicates the lifetime of the `Resource Record` in seconds. This field is set by the server that returns an answer and indicates for how long a client or a resolver can store the `Resource Record` inside its cache. A long `TTL` indicates a stable `RR`. Some companies use short `TTL` values for mobile hosts and also for popular servers. For example, a web hosting company that wants to spread the load over a pool of hundred servers can configure its nameservers to return different answers to different clients. If each answer has a small `TTL`, the clients will be forced to send DNS queries regularly. The nameserver will reply to these queries by supplying the address of the less loaded server.
817/7160 · 716
14
../../principles/security.rst:187
English
The last type of attack that we consider in this introduction are the `Denial of Service` or DoS attacks. During such an attack, the attacker generates enough packets to saturate a given service and prevent it from operating correctly. The simplest Denial of Service attack is to send more packets that the bandwidth of the link that attaches the target to the network. The target could be a single server, a company or even an entire country. If these packets all come from the same source, then the victim can identify the attacker and contact the law enforcement authorities. In practice, such denial of service attacks do not originate from a single source. The attacker usually compromises a (possibly very large) set of sources and forces them to send packets to saturate a given target. Since the attacking traffic comes from a wide range of sources, it is difficult for the victim to locate the culprit and also to counter the attack. Saturating a link is the simplest example of `Distributed Denial of Service (DDoS)` attacks.
0/10350 · 1035
14
../../exercises/dns.rst:45
English
What is the IPv6 address that corresponds to `www.computer-networking.info` ? Which type of DNS query does `dig` send to obtain this information ?
0/1460 · 146
14
../../exercises/http.rst:37
English
As for the DNS, besides using software tools that implement the HTTP protocols, it can also be useful to analyze packet traces with wireshark_ . The exercises below contain simple packet traces collected with different versions of the HTTP protocol.
0/2490 · 249
14
../../exercises/ipv6.rst:43 • ../../exercises/ipv6.rst:152
English
router ``R4`` uses address ``2001:db8:1341:34::4`` on its West interface, address ``2001:db8:1341:24::4`` on its North interface and address ``2001:db8:1341:4::4`` on its East interface
0/1850 · 185
14
../../exercises/lan.rst:91
English
Fig. 5. Will the link between `S0` and `S1` ever be used?
0/570 · 57
14
../../exercises/routing-policies.rst:151
English
Via which provider does `AS456` receive the packets destined to ``2001:db8:caff::bb`` and ``2001:db8:cafe::aa`` ?
0/1130 · 113
14
../../exercises/routing-protocols.rst:239
English
We can also use the packet traces that were collected by tcpdump_ to observe the packets that the OSPFv3 daemons exchange. OSPFv3 is a more complex protocol that the basic link state protocol that we have described in this book, but you should be able to understand some of these packets. The packet traces are available as :download:`/exercises/traces/ospf6-r1-trace.pcap`, :download:`/exercises/traces/ospf6-r2-trace.pcap` and :download:`/exercises/traces/ospf6-r3-trace.pcap`. Here are a few interesting packets collected on router ``r1``.
0/5420 · 542
14
../../exercises/tcp-2.rst:80
English
At this point, the socket is ready to accept incoming TCP connections. packetdrill_ needs to inject a TCP segment in the instrumented Linux stack. This can be done with the line below.
0/1840 · 184
14
../../exercises/trace.rst:88
English
Wireshark : default window
0/260 · 26
14
../../protocols/bgp.rst:55
English
To understand the `customer->provider` relationship, let us consider the simple internetwork shown in the figure above. In this internetwork, `AS7` is a stub domain that is connected to one provider : `AS4`. The contract between `AS4` and `AS7` allows a host inside `AS7` to exchange packets with any host in the internetwork. To enable this exchange of packets, `AS7` must know a route towards any domain and all the domains of the internetwork must know a route via `AS4` that allows them to reach hosts inside `AS7`. From a routing perspective, the commercial contract between `AS7` and `AS4` leads to the following routes being exchanged :
0/6430 · 643
14
../../protocols/congestion.rst:89
English
Furthermore when a TCP connection has been idle for more than its current retransmission timer, it should reset its congestion window to the congestion window size that it uses when the connection begins, as it no longer knows the current congestion state of the network.
0/2710 · 271
14
../../protocols/dnssec.rst:161
English
the `DNSKEY` record allows storing the public key associated with a zone. This record is encoded as a TLV and includes a `Base64` representation of the key and the identification of the public key algorithm. This allows the `DNSKEY` record to support different public key algorithms.
0/2830 · 283
14
../../protocols/email.rst:98
English
The email header contains several lines that all begin with a keyword followed by a colon and additional information. The format of email messages and the different types of header lines are defined in :rfc:`5322`. Two of these header lines are mandatory and must appear in all email messages :
0/2940 · 294