Exit Zen
85
../../exercises/ipv6.rst:794
English
There are three routes in this table. The first two correspond to the two prefixes that are used over the ``a-eth0`` interface. These routes are automatically created when an IPv6 address is configured on an interface. The last route is the default route (``::/0``) which points towards ``2001:db8:1341:1::1``, i.e. router ``r1``.
0/3300 · 330
85
../../exercises/routing-protocols.rst:1265
English
What is the Loc-RIB of ``AS6`` for prefix `p1` ? Indicate which is the best route towards this prefix.
0/1020 · 102
85
../../protocols/bgp.rst:335
English
With this import filter, all the BGP routes learned from `RB` over the high bandwidth links are preferred over the routes learned over the backup link. If the primary link fails, the corresponding routes are removed from `R1`'s RIB and `R1` uses the route learned from `RA`. `R1` reuses the routes via `RB` as soon as they are advertised by `RB` once the `R1-RB` link comes back.
0/3790 · 379
85
../../protocols/email.rst:240
English
m
0/100 · 1
85
../../protocols/ethernet.rst:356
English
200000
0/100 · 6
85
../../protocols/ipv6.rst:335
English
`Flow Label` : this field was initially intended to be used to tag packets belonging to the same `flow`. A recent document, :rfc:`6437` describes some possible usages of this field, but it is too early to tell whether it will be really used.
0/2410 · 241
85
../../protocols/ethernet.rst:327
English
In this network, the STP will compute the following spanning tree. `Switch1` will be the root of the tree. All the interfaces of `Switch1`, `Switch2` and `Switch7` are part of the spanning tree. Only the interface connected to `LAN B` will be active on `Switch9`. `LAN H` will only be served by `Switch7` and the port of `Switch44` on `LAN G` will be disabled. A frame originating on `LAN B` and destined for `LAN A` will be forwarded by `Switch7` on `LAN C`, then by `Switch1` on `LAN E`, then by `Switch44` on `LAN F` and eventually by `Switch2` on `LAN A`.
0/5590 · 559
85
../../protocols/tcp.rst:261
English
the local TCP port number
0/250 · 25
85
../../protocols/tls.rst:447
English
There are several important differences with the TLS 1.2 handshake. First, the Diffie Hellman key exchange is required in TLS 1.3 and this exchange is initiated by the client (before having validated the server identity). To initiate the Diffie Hellman key exchange, the client needs to guess the modulus and the base that can be accepted by the server. Either the client uses standard parameters that most server supports or the client remembers the last modulus/base that it used with this particular server. If the client guessed incorrectly, the server replies with the parameters that it expects and one round-trip-time is lost. When the server sends its `ServerHello`, it already knows the session key. This implies that the server can encrypt all subsequent messages. After one round-trip-time, all data exchanged over the TLS 1.3 session is encrypted and authenticated. In TLS 1.3, the server certificate is encrypted with the session key, as well as the `Finished` message. The server signs the handshake to confirm that it owns the public key of its certificate. If the server wants to send application data, it can already encrypt it and send it to the client. Upon reception of the server Certificate, the client verifies it and checks the signature of the handshake and the `Finished` message. The client confirms the end of the handshake by sending its own `Finished` message. At that time, the client can send encrypted data. This means that the client only had to wait one round-trip-time before sending encrypted data. This is much faster than with TLS 1.2.
0/15740 · 1574
86
../../glossary.rst:83
English
is the version 6 of the Internet Protocol, the connectionless network layer protocol which is intended to replace IPv4. IP version 6 addresses are encoded as a 128 bits field.
0/1750 · 175
86
../../principles/network.rst:362
English
the outgoing interface for the packet
0/370 · 37
86
../../principles/transport.rst:519
English
Services and layers
0/190 · 19
86
../../principles/sharing.rst:377
English
The above pseudo-code is often called `persistent CSMA` [KT1975]_ as the terminal will continuously listen to the channel and transmit its frame as soon as the channel becomes free. Another important variant of CSMA is the `non-persistent CSMA` [KT1975]_. The main difference between persistent and non-persistent CSMA described in the pseudo-code below is that a non-persistent CSMA node does not continuously listen to the channel to determine when it becomes free. When a non-persistent CSMA terminal senses the transmission channel to be busy, it waits for a random time before sensing the channel again. This improves channel utilization compared to persistent CSMA. With persistent CSMA, when two terminals sense the channel to be busy, they will both transmit (and thus cause a collision) as soon as the channel becomes free. With non-persistent CSMA, this synchronization does not occur, as the terminals wait a random time after having sensed the transmission channel. However, the higher channel utilization achieved by non-persistent CSMA comes at the expense of a slightly higher waiting time in the terminals when the network is lightly loaded.
0/11570 · 1157
86
../../principles/security.rst:945
English
An example of the utilization of the Diffie-Hellman key exchange is shown below. Before starting the exchange, Alice and Bob agree on a modulus (:math:`p=23`) and a base (:math:`g=5`). These two numbers are public. They are typically part of the standard that defines the protocol that uses the key exchange.
0/3080 · 308
86
../../exercises/ipv6.rst:796
English
Another useful command is ``xterm`` 'node' that allows to launch a terminal on the specified node. This gives you a interactive shell on any node. You can use it to capture packets with tcpdump_. As an example, let us use :manpage:`traceroute6(8)` to trace the path followed by packets from host ``a`` towards the IPv6 address of host ``b`` i.e. ``2001:db8:1341:3::b``. The output of this command shows that the path passes through routers ``r1``, ``r2`` and ``r3``.
0/4660 · 466
86
../../exercises/routing-protocols.rst:1267
English
What is the Loc-RIB of ``AS8`` for prefix `p2` ? Indicate which is the best route towards this prefix.
0/1020 · 102
86
../../protocols/bgp.rst:337
English
The import filter above modifies the selection of the BGP routes inside `AS1`. Thus, it influences the route followed by the packets forwarded by `AS1`. In addition to using the primary link to send packets, `AS1` would like to receive its packets via the high bandwidth link. For this, `AS2` also needs to set the `local-pref` attribute in its import filter.
0/3590 · 359
86
../../protocols/email.rst:240
English
55
0/100 · 2
86
../../protocols/ethernet.rst:357
English
1 Gbps
0/100 · 6
86
../../protocols/ipv6.rst:336
English
`Payload Length` : this is the size of the packet payload in bytes. As the length is encoded as a 16 bits field, an IPv6 packet can contain up to 65535 bytes of payload.
0/1690 · 169