2. cnp3-ebook
3. English
4. Zen

74 ../../principles/transport.rst:309
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A second reason is when the service provider is unable to reach the destination user. This might happen because the destination user is not currently attached to the network or due to congestion. In these cases, the service provider responds to the `Connect.request` with a `Disconnect.indication` primitive whose `reason` parameter contains additional information about the failure of the connection. 401/10000 · 401
74 ../../principles/security.rst:885
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Until now, we have only discussed the authentication problem. This is an important but not sufficient step to have a secure communication between two users through an insecure network. To securely exchange information, Alice and Bob need to both : 247/10000 · 247
74 ../../exercises/ipv6.rst:682
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — With this ``build`` method, we can now launch the network by using the python code below. 89/10000 · 89
74 ../../exercises/routing-protocols.rst:1029
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Another interesting utilization IPMininet_ is to explore the impact of a link failure. We start from a small variant of the above topology. 139/10000 · 139
74 ../../protocols/bgp.rst:295
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the router has been manually configured by the network operator to always advertise one or several routes on a BGP session. For example, on the BGP session between UCLouvain and its provider, belnet_ , UCLouvain's router always advertises the `2001:6a8:3080/48` IPv6 prefix assigned to the campus network 304/10000 · 304
74 ../../protocols/email.rst:238
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — D 1/10000 · 1
74 ../../protocols/ethernet.rst:334
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `identifier` of the root switch (`R`) 41/10000 · 41
74 ../../protocols/http.rst:387
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A first solution is to force the users to be authenticated. This was the solution used by `FTP` to control the files that each user could access. Initially, user names and passwords could be included inside URIs :rfc:`1738`. However, placing passwords in the clear in a potentially publicly visible URI is completely insecure and this usage has now been deprecated :rfc:`3986`. HTTP supports several extension headers :rfc:`2617` that can be used by a server to request the authentication of the client by providing his/her credentials. However, user names and passwords have not been popular on web servers as they force human users to remember one user name and one password per server. Remembering a password is acceptable when a user needs to access protected content, but users will not accept to remember a unique user name and password for each web sites that they visit. 878/10000 · 878
74 ../../protocols/ipv6.rst:265
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The addresses described above are unicast addresses. These addresses are used to identify (interfaces on) hosts and routers. They can appear as source and destination addresses in the IPv6 packets. When a host sends a packet towards a unicast address, this packet is delivered by the network to its final destination. There are situations, such as when delivering video or television signal to a large number of receivers, where it is useful to have a network that can efficiently deliver the same packet to a large number of receivers. This is the `multicast` service. A multicast service can be provided in a LAN. In this case, a multicast address identifies a set of receivers and each frame sent towards this address is delivered to all receivers in the group. Multicast can also be used in a network containing routers and hosts. In this case, a multicast address identifies also a group of receivers and the network delivers efficiently each multicast packet to all members of the group. Consider for example the network below. 1033/10000 · 1033
74 ../../protocols/ethernet.rst:263
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The pseudo-code below details how an Ethernet switch forwards Ethernet frames. It first updates its `MAC address table` with the source address of the frame. The `MAC address table` used by some switches also contains a timestamp that is updated each time a frame is received from each known source address. This timestamp is used to remove from the `MAC address table` entries that have not been active during the last `n` minutes. This limits the growth of the `MAC address table`, but also allows hosts to move from one port to another. The switch uses its `MAC address table` to forward the received unicast frame. If there is an entry for the frame's destination address in the `MAC address table`, the frame is forwarded selectively on the port listed in this entry. Otherwise, the switch does not know how to reach the destination address and it must forward the frame on all its ports except the port from which the frame has been received. This ensures that the frame will reach its destination, at the expense of some unnecessary transmissions. These unnecessary transmissions will only last until the destination has sent its first frame. Multicast and Broadcast frames are also forwarded in a similar way. 1217/10000 · 1217
74 ../../protocols/tcp.rst:237
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Concerning the TCP options, the robustness principle implies that a TCP implementation should be able to accept TCP options that it does not understand, in particular in received `SYN` segments, and that it should be able to parse any received segment without crashing, even if the segment contains an unknown TCP option. Furthermore, a server should not send in the `SYN+ACK` segment or later, options that have not been proposed by the client in the `SYN` segment. 466/10000 · 466
74 ../../protocols/tls.rst:395
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The last point is the difficulty of deploying TLS servers [KMS2017]_. When TLS servers are installed, the system administrator needs to obtain certificates and configure a range of servers. Initially, getting certificates was complex and costly, but initiatives such as https://letsencrypt.org have simplified this workflow. 324/10000 · 324
74 ../../bibliography.rst:97
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Ishihara, K., Mukai, M., Hiromi, R., Mawatari, M., `Packet Filter and Route Filter Recommendation for IPv6 at xSP routers <http://www.team-cymru.org/ReadingRoom/Templates/IPv6Routers/xsp-recommendations.html>`_, 2013 216/10000 · 216
75 ../../bibliography.rst:98
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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 308/10000 · 308
75 ../../glossary.rst:71
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — an internet is an internetwork, i.e. a network composed of different networks. The :term:`Internet`, with a capital `I` corresponds to the global network that we use today, but other internetworks have been used in the path. 224/10000 · 224
75 ../../principles/network.rst:427
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Fragmenting packets on a per-link basis, as presented for the second solution, can minimize the transmission overhead since a packet is only fragmented on the links where fragmentation is required. Large packets can continue to be used downstream of a link that only accepts small packets. However, this reduction of the overhead comes with two drawbacks. First, fragmenting packets, potentially on all links, increases the processing time and the buffer requirements on the routers. Second, this solution leads to a longer end-to-end delay since the downstream router has to reassemble all the packet fragments before forwarding the packet. 641/10000 · 641
75 ../../principles/reliability.rst:260
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `DLE`: `0010000` b 18/10000 · 18
75 ../../principles/sharing.rst:480
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Packet radio technologies have evolved in various directions since the first experiments performed at the University of Hawaii. The Amateur packet radio service developed by amateur radio operators is one of the descendants ALOHANet. Many amateur radio operators are very interested in new technologies and they often spend countless hours developing new antennas or transceivers. When the first personal computers appeared, several amateur radio operators designed radio modems and their own datalink layer protocols [KPD1985]_ [BNT1997]_. This network grew and it was possible to connect to servers in several European countries by only using packet radio relays. Some amateur radio operators also developed TCP/IP protocol stacks that were used over the packet radio service. Some parts of the `amateur packet radio network <http://www.ampr.org/>`_ are connected to the global Internet and use the `44.0.0.0/8` IPv4 prefix. 926/10000 · 926
75 ../../principles/transport.rst:329
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Once the connection has been established, the service provider supplies two data streams to the communicating users. The first data stream can be used by the initiating user to send SDUs. The second data stream allows the responding user to send SDUs to the initiating user. The data streams can be organized in different ways. A first organization is the `message-mode` transfer. With the `message-mode` transfer, the service provider guarantees that one and only one `Data.indication` will be delivered to the endpoint of the data stream for each `Data.request` primitive issued by the other endpoint. The `message-mode` transfer is illustrated in the figure below. The main advantage of the `message-transfer` mode is that the recipient receives exactly the SDUs that were sent by the other user. If each SDU contains a command, the receiving user can process each command as soon as it receives a SDU. 905/10000 · 905
75 ../../principles/security.rst:890
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — mutually authenticate each other 32/10000 · 32