2. cnp3-ebook
3. English
4. Zen

214 ../../protocols/email.rst:443
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Once the client has retrieved and possibly deleted the emails contained in the mailbox, it must issue the `QUIT` command. This command terminates the POP session and allows the server to delete all the messages that have been marked for deletion by using the `DELE` command. 274/10000 · 274
214 ../../protocols/ipv6.rst:789
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Upon reception of this message, the host can derive its global IPv6 address by concatenating its 64 bits identifier with the received prefix. It concludes the SLAAC by sending a Neighbor Solicitation message targeted at its global IPv6 address to ensure that no other host is using the same IPv6 address. 304/10000 · 304
215 ../../protocols/email.rst:445
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The figure below provides a simple POP session. All lines prefixed with `C:` (resp. `S:`) are sent by the client (resp. server). 128/10000 · 128
215 ../../protocols/ipv6.rst:791
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Router Advertisements and Hop Limits 36/10000 · 36
216 ../../protocols/email.rst:471
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In this example, a POP client contacts a POP server on behalf of the user named `alice`. Note that in this example, Alice's password is sent in clear by the client. This implies that if someone is able to capture the packets sent by Alice, he will know Alice's password [#fapop]_. Then Alice's client issues the `STAT` command to know the number of messages that are stored in her mailbox. It then retrieves and deletes the first message of the mailbox. 453/10000 · 453
216 ../../protocols/ipv6.rst:793
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — ICMPv6 Router Advertisements messages are regularly sent by routers. They are destined to all devices attached to the local subnet and no router should ever forward them to another subnet. Still, these messages are sent inside IPv6 packets whose `Hop Limit` is always set to ``255``. Given that the packet should not be forwarded outside of the local subnet, the reader could expect instead a `Hop Limit` set to ``1``. Using a `Hop Limit` set to ``255`` provides one important benefit from a security viewpoint and this hack has been adapted in several Internet protocols. When a host receives a `Router Advertisement` message, it expects that this message has been generated by a router attached to the same subnet. Using a `Hop Limit` of ``255`` provides a simple check for this. If the message was generated by an attacker outside the subnet, it would reach the subnet with a decremented `Hop Limit`. Checking that the `Hop Limit` is set to ``255`` is a simple [#fsend]_ verification that the packet was generated on this particular subnet. :rfc:`5082` provides other examples of protocols that use this hack and discuss its limitations. 1140/10000 · 1140
217 ../../protocols/email.rst:482
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Footnotes 9/10000 · 9
217 ../../protocols/ipv6.rst:796
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Routers regularly send Router Advertisement messages. These messages are triggered by a timer that is often set at approximately 30 seconds. Usually, hosts wait for the arrival of a Router Advertisement message to configure their address. This implies that hosts could sometimes need to wait 30 seconds before being able to configure their address. If this delay is too long, a host can also send a `Router Solicitation` message. This message is sent towards the multicast address that corresponds to all IPv6 routers (i.e. ``FF01::2``) and the default router will reply. 571/10000 · 571
218 ../../protocols/email.rst:483
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — It could be surprising that the `To:` is not mandatory inside an email message. While most email messages will contain this header line an email that does not contain a `To:` header line and that relies on the `bcc:` to specify the recipient is valid as well. 259/10000 · 259
218 ../../protocols/ipv6.rst:798
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The last point that needs to be explained about ICMPv6 is the `Redirect` message. This message is used when there is more than one router on a subnet as shown in the figure below. 179/10000 · 179
219 ../../protocols/email.rst:485
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The list of all standard email header lines may be found at http://www.iana.org/assignments/message-headers/message-header-index.html 133/10000 · 133
219 ../../protocols/ipv6.rst:819
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In this network, ``router1`` is the default router for all hosts. The second router, ``router2`` provides connectivity to a specific IPv6 subnet, e.g. ``2001:db8:abcd::/48``. These two routers attached to the same subnet can be used in different ways. First, it is possible to manually configure the routing tables on all hosts to add a route towards ``2001:db8:abcd::/48`` via ``router2``. Unfortunately, forcing such manual configuration boils down all the benefits of using address auto-configuration in IPv6. The second approach is to automatically configure a default route via ``router1`` on all hosts. With such route, when a host needs to send a packet to any address within ``2001:db8:abcd::/48``, it will send it to ``router1``. ``router1`` would consult its routing table and find that the packet needs to be sent again on the subnet to reach ``router2``. This is a waste of time. A better approach would be to enable the hosts to automatically learn the new route. This is possible thanks to the ICMPv6 `Redirect` message. When ``router1`` receives a packet that needs to be forwarded back on the same interface, it replies with a `Redirect` message that indicates that the packet should have been sent via ``router2``. Upon reception of a `Redirect` message, the host updates it forwarding table to include a new transient entry for the destination reported in the message. A timeout is usually associated with this transient entry to automatically delete it after some time. 1490/10000 · 1490
220 ../../protocols/email.rst:487
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — During the last years, many Internet Service Providers, campus and enterprise networks have deployed SMTP extensions :rfc:`4954` on their MSAs. These extensions force the MUAs to be authenticated before the MSA accepts an email message from the MUA. 249/10000 · 249
220 ../../protocols/ipv6.rst:826
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — An alternative is the Dynamic Host Configuration Protocol (DHCP) defined in :rfc:`2131` and :rfc:`3315`. DHCP allows a host to automatically retrieve its assigned IPv6 address, but relies on server. A DHCP server is associated to each subnet [#fdhcpserver]_. Each DHCP server manages a pool of IPv6 addresses assigned to the subnet. When a host is first attached to the subnet, it sends a DHCP request message in a UDP segment (the DHCP server listens on port 67). As the host knows neither its IPv6 address nor the IPv6 address of the DHCP server, this UDP segment is sent inside a multicast packet target at the DHCP servers. The DHCP request may contain various options such as the name of the host, its datalink layer address, etc. The server captures the DHCP request and selects an unassigned address in its address pool. It then sends the assigned IPv6 address in a DHCP reply message which contains the datalink layer address of the host and additional information such as the subnet mask, the address of the default router or the address of the DNS resolver. The DHCP reply also specifies the lifetime of the address allocation. This forces the host to renew its address allocation once it expires. Thanks to the limited lease time, IP addresses are automatically returned to the pool of addresses when hosts are powered off. 1336/10000 · 1336
221 ../../protocols/email.rst:489
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The first versions of SMTP used `HELO` as the first command sent by a client to a SMTP server. When SMTP was extended to support newer features such as 8 bits characters, it was necessary to allow a server to recognize whether it was interacting with a client that supported the extensions or not. `EHLO` became mandatory with the publication of :rfc:`2821`. 358/10000 · 358
221 ../../protocols/ipv6.rst:828
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Both SLAAC and DHCPv6 can be extended to provide additional information beyond the IPv6 prefix/address. For example, :rfc:`6106` defines options for the ICMPv6 ND message that can carry the IPv6 address of the recursive DNS resolver and a list of default domain search suffixes. It is also possible to combine SLAAC with DHCPv6. :rfc:`3736` defines a stateless variant of DHCPv6 that can be used to distribute DNS information while SLAAC is used to distribute the prefixes. 473/10000 · 473
222 ../../protocols/email.rst:491
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — This implies that a valid email message cannot contain a line with one dot followed by `CR` and `LF`. If a user types such a line in an email, his email client will automatically add a space character before or after the dot when sending the message over SMTP. 260/10000 · 260
222 ../../protocols/ipv6.rst:834
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Footnotes 9/10000 · 9
223 ../../protocols/email.rst:493
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — :rfc:`1939` defines the APOP authentication scheme that is not vulnerable to such attacks. 90/10000 · 90
223 ../../protocols/ipv6.rst:835
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The full list of allocated IPv6 multicast addresses is available at http://www.iana.org/assignments/ipv6-multicast-addresses 124/10000 · 124