Exit Zen
64
../../exercises/ipv6.rst:611
English
``2001:db8:1341:1::/64`` on the link between ``a`` and ``r1``
0/610 · 61
64
../../exercises/routing-protocols.rst:866
English
Another interesting utilization of IPMininet_ is to explore how routers react to link failures. We start from the same network as with the previous example and disable the link between ``AS2`` and ``AS3``. For this, we log on one of the two routers and issue the following commands.
0/2820 · 282
64
../../protocols/bgp.rst:274
English
This network contains three routers : `R1`, `R2` and `R3`. Each router is attached to a local IPv6 subnet that it advertises using BGP. There are two BGP sessions, one between `R1` and `R2` and the second between `R2` and `R3`. A `/127` subnet is used on each interdomain link (`2001:db8::4/127` on `R1-R2` and `2001:db8::0/127` on `R2-R3`) in conformance with the latest recommendation :rfc:`6164`. The BGP sessions run above TCP connections established between the neighboring routers (e.g. `2001:db8::5 - 2001:db8::6` for the `R1-R2` session).
0/5460 · 546
64
../../protocols/email.rst:234
English
j
0/100 · 1
64
../../protocols/ethernet.rst:300
English
Ethernet switches in a loop
0/270 · 27
64
../../protocols/http.rst:306
English
To allow the clients and servers to control the utilization of these persistent TCP connections, HTTP 1.1 :rfc:`2616` defines several new HTTP headers:
0/1510 · 151
64
../../protocols/ipv6.rst:218
English
a packet with destination ``2001:1890:123a::1:1e`` matches one route : ``::/0``. The packet is forwarded via ``fe80::dead:beef``
0/1280 · 128
64
../../protocols/ethernet.rst:195
English
Initially, the OUIs were allocated by Xerox [DP1981]_. However, once Ethernet became an IEEE and later an ISO standard, the allocation of the OUIs moved to IEEE. The list of all OUI allocations may be found at http://standards.ieee.org/regauth/oui/index.shtml
0/2590 · 259
64
../../protocols/tcp.rst:219
English
The first parameter which is negotiated during the establishment of a TCP connection is the Maximum Segment Size (:term:`MSS`). The MSS is the size of the largest segment that a TCP entity is able to process. According to :rfc:`879`, all TCP implementations must be able to receive TCP segments containing 536 bytes of payload. However, most TCP implementations are able to process larger segments. Such TCP implementations use the TCP MSS Option in the `SYN`/`SYN+ACK` segment to indicate the largest segment they are able to process. The MSS value indicates the maximum size of the payload of the TCP segments. The client (resp. server) stores in its :term:`TCB` the MSS value announced by the server (resp. the client).
0/7220 · 722
64
../../protocols/tls.rst:338
English
a `Length` field. A TLS record cannot be longer than 16,384 bytes.
0/660 · 66
65
../../glossary.rst:243
English
The Internet Corporation for Assigned Names and Numbers (ICANN) coordinates the allocation of domain names, IP addresses and AS numbers as well protocol parameters. It also coordinates the operation and the evolution of the DNS root name servers.
0/2460 · 246
65
../../principles/reliability.rst:239
English
`0` : `0110000` b
0/170 · 17
65
../../principles/transport.rst:222
English
When two applications need to communicate, they need to structure their exchange of information. Structuring this exchange of information requires solving two different problems. The first problem is how to represent the information being exchanged knowing that the two applications may be running on hosts that use different operating systems, different processors and have different conventions to store information. This requires a common syntax to transfer the information between the two applications. For this chapter, let us assume that this syntax exists and that the two applications simply need to exchange bytes. We will discuss later how more complex data can be encoded as sequences of bytes to be exchanged. The second problem is how to organize the interactions between the application and the underlying network. From the application's viewpoint, the `network` will appear as the `transport layer` service. This `transport layer` can provide three types of services to the applications :
0/10030 · 1003
65
../../principles/sharing.rst:269
English
`Deterministic` or `pessimistic` MAC algorithms. These algorithms assume that collisions are a very severe problem and that they must be completely avoided. These algorithms ensure that at any time, at most one device is allowed to send a frame on the LAN. This is usually achieved by using a distributed protocol which elects one device that is allowed to transmit at each time. A deterministic MAC algorithm ensures that no collision will happen, but there is some overhead in regulating the transmission of all the devices attached to the LAN.
0/5460 · 546
65
../../principles/security.rst:775
English
Now consider that Mallory wants to be authenticated as Alice. The above protocol has a subtle flaw that could be exploited by Mallory. This flaw can be exploited if Alice and Bob can act as both client and server. Knowing this, Mallory could operate as follows. Mallory starts an authentication with Bob faking himself as Alice. He sends a first message to Bob including Alice's identity.
0/3880 · 388
65
../../exercises/ipv6.rst:612
English
``2001:db8:1341:12::/64`` on the link between ``r1`` and ``r2``
0/630 · 63
65
../../exercises/routing-protocols.rst:898
English
We first connect to the BGP daemon on router `as2`. In addition to the `show` commands that have been described earlier, the router also supports privileged commands that can change its configuration. Before executing these commands, we must enter the privileged mode with the `enable` command. On production routers, this command requires a password to verify the credentials of the network administrator. The `#` prompt indicates that we are allowed to execute privileged commands. We first check the state of the BGP sessions with the `show bgp summary` commands. There are two BGP sessions configured on this router.
0/6200 · 620
65
../../exercises/tcp-2.rst:876
English
On Linux, most of the parameters to tune the TCP stack are accessible via :manpage:`sysctl`. These parameters are briefly described in https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.txt and in the :manpage:`tcp` manpage. Each script sets some of these configuration variables.
0/3100 · 310
65
../../protocols/bgp.rst:279
English
Let us assume that the `R1-R2` BGP session is the first to be established. A `BGP Update` message sent on such a session contains three fields :
0/1440 · 144
65
../../protocols/email.rst:234
English
52
0/100 · 2