2. cnp3-ebook
3. English
4. Zen

20 ../../principles/transport.rst:66
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Bob : `This is not the correct password.` 41/10000 · 41
20 ../../protocols/dns.rst:66
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Reverse DNS 11/10000 · 11
20 ../../principles/security.rst:270
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `A cryptographic algorithm should be secure even if the attacker knows everything about the system, except one parameter known as the secret key.` 146/10000 · 146
20 ../../exercises/dns.rst:55
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — What is the lifetime associated to this IPv6 address ? 54/10000 · 54
20 ../../exercises/ipv6.rst:151 • ../../exercises/ipv6.rst:229
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — router ``R3`` uses address ``2001:db8:1341:34::3`` on its East interface and address ``2001:db8:1341:13::3`` on its North interface 131/10000 · 131
20 ../../exercises/lan.rst:195
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The network contains five nodes and six links. 46/10000 · 46
20 ../../exercises/routing-policies.rst:167
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A ``traceroute6`` towards ``ipv6.google.com`` provides the following output : 77/10000 · 77
20 ../../exercises/routing-protocols.rst:261
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The requested information is sent in a `LS Update` packet shortly after that. 77/10000 · 77
20 ../../exercises/tcp-2.rst:113
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — packetdrill_ writes 10 bytes of data through the :manpage:`write` system call. The stack immediately sends these 10 bytes inside a segment whose ``Push`` flag is set [#fpush]_. The payload starts at sequence number ``1`` and ends at sequence number ``10``. packetdrill_ replies by injecting an acknowledgment for the entire data after 100 milliseconds. 352/10000 · 352
20 ../../exercises/trace.rst:109
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — When analyzing packet traces with wireshark_, it is often very useful to use `Display filters` that only show the packets that match some specific criteria. There filters are described in several online documents: 213/10000 · 213
20 ../../protocols/bgp.rst:68
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — From a routing perspective, over a `shared-cost` peering relationship a domain only advertises its internal routes/prefixes and the routes that it has learned from its customers. This restriction ensures that only packets destined to the local domain or one of its customers is received over the `shared-cost` peering relationship. This implies that the routes that have been learned from a provider or from another `shared-cost` peer is not advertised over a `shared-cost` peering relationship. This is motivated by economical reasons. If a domain were to advertise the routes that it learned from a provider over a `shared-cost` peering relationship that does not bring revenue, it would have allowed its `shared-cost` peer to use the link with its provider without any payment. If a domain were to advertise the routes it learned over a `shared cost` peering over another `shared-cost` peering relationship, it would have allowed these `shared-cost` peers to use its own network (which may span one or more continents) freely to exchange packets. 1049/10000 · 1049
20 ../../protocols/congestion.rst:108
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The first difficulty in adding Explicit Congestion Notification (ECN) in TCP/IP network was to modify the format of the network packet and transport segment headers to carry the required information. In the network layer, one bit was required to allow the routers to mark the packets they forward during congestion periods. In the IP network layer, this bit is called the `Congestion Experienced` (`CE`) bit and is part of the packet header. However, using a single bit to mark packets is not sufficient. Consider a simple scenario with two sources, one congested router and one destination. Assume that the first sender and the destination support ECN, but not the second sender. If the router is congested it will mark packets from both senders. The first sender will react to the packet markings by reducing its transmission rate. However since the second sender does not support ECN, it will not react to the markings. Furthermore, this sender could continue to increase its transmission rate, which would lead to more packets being marked and the first source would decrease again its transmission rate, ... In the end, the sources that implement ECN are penalized compared to the sources that do not implement it. This unfairness issue is a major hurdle to widely deploy ECN on the public Internet [#fprivate]_. The solution proposed in :rfc:`3168` to deal with this problem is to use a second bit in the network packet header. This bit, called the `ECN-capable transport` (ECT) bit, indicates whether the packet contains a segment produced by a transport protocol that supports ECN or not. Transport protocols that support ECN set the ECT bit in all packets. When a router is congested, it first verifies whether the ECT bit is set. In this case, the CE bit of the packet is set to indicate congestion. Otherwise, the packet is discarded. This eases the deployment of ECN [#fecnnonce]_. 1893/10000 · 1893
20 ../../protocols/dnssec.rst:189
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To obtain an authenticated record for `www.example.org`, Alice's resolver first needs to retrieve the `NS` which is responsible for the `.org` Top-Level Domain (TLD). This record is served by the DNS root server and Alice's resolver can retrieve the signature (`RRSIG` record) for this `NS` record. Since Alice knows the `DNSKEY` of the root, she can verify the validity of this signature. 389/10000 · 389
20 ../../protocols/email.rst:107
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `bcc:` header line is used by the sender to provide a list of comma separated email addresses that must receive a blind carbon copy of the message. The `bcc:` header line is not delivered to the recipients of the email message. 231/10000 · 231
20 ../../protocols/ethernet.rst:113
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The second physical layer was 10Base2. This physical layer used a thin coaxial cable that was easier to install than the 10Base5 cable, but could not be longer than 185 meters. A 10BaseF physical layer was also defined to transport Ethernet over point-to-point optical links. The major change to the physical layer was the support of twisted pairs in the 10BaseT specification. Twisted pair cables are traditionally used to support the telephone service in office buildings. Most office buildings today are equipped with structured cabling. Several twisted pair cables are installed between any room and a central telecom closet per building or per floor in large buildings. These telecom closets act as concentration points for the telephone service but also for LANs. 769/10000 · 769
20 ../../protocols/http.rst:96
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A markup language is a structured way of adding annotations about the formatting of the document within the document itself. Example markup languages include troff_, which is used to write the Unix man pages or Latex_. HTML uses markers to annotate text and a document is composed of `HTML elements`. Each element is usually composed of three parts: a start tag that potentially includes some specific attributes, some text (often including other elements), and an end tag. A HTML tag is a keyword enclosed in angle brackets. The generic form of an HTML element is :: 567/10000 · 567
20 ../../protocols/http2.rst:144
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To cope with these two problems, the IETF HTTP working group developed version 2.0 of HTTP. HTTP/2.0 diverges from HTTP/1.1 in two important ways. First, HTTP/2.0 relies on binary encoding which is both more compact and easier to parse. Second, HTTP/2.0 supports multiple streams, which makes it possible to simultaneously transfer different web objects over a single transport connection. Furthermore, HTTP/2.0 also compresses the HTTP headers to reduce the amount of data transferred. This technique is described in :rfc:`7541` but is not discussed in this chapter. 567/10000 · 567
20 ../../protocols/ipv6.rst:98
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Security must be part of IPv6 29/10000 · 29
20 ../../protocols/ethernet.rst:47
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The original 10 Mbps Ethernet specification [DIX]_ defined a simple frame format where each frame is composed of five fields. The Ethernet frame starts with a preamble (not shown in the figure below) that is used by the physical layer of the receiver to synchronize its clock with the sender's clock. The first field of the frame is the destination address. As this address is placed at the beginning of the frame, an Ethernet interface can quickly verify whether it is the frame recipient and if not, cancel the processing of the arriving frame. The second field is the source address. While the destination address can be either a unicast or a multicast/broadcast address, the source address must always be a unicast address. The third field is a 16 bits integer that indicates which type of network layer packet is carried inside the frame. This field is often called the `EtherType`. Frequently used `EtherType` values [#fethertype]_ include `0x0800` for IPv4, `0x86DD` for IPv6 [#fipv6ether]_ and `0x806` for the Address Resolution Protocol (ARP). 1052/10000 · 1052
20 ../../protocols/routing.rst:67
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Link-state routing protocols are used in IP networks. Open Shortest Path First (OSPF), defined in :rfc:`2328`, is the link state routing protocol that has been standardized by the IETF. The last version of OSPF, which supports IPv6, is defined in :rfc:`5340`. OSPF is frequently used in enterprise networks and in some ISP networks. However, ISP networks often use the IS-IS link-state routing protocol [ISO10589]_ , which was developed for the ISO CLNP protocol but was adapted to be used in IP :rfc:`1195` networks before the finalization of the standardization of OSPF. A detailed analysis of ISIS and OSPF may be found in [BMO2006]_ and [Perlman2000]_. Additional information about OSPF may be found in [Moy1998]_. 719/10000 · 719