Exit Zen
209
../../protocols/email.rst:433
English
The Post Office Protocol
0/240 · 24
209
../../protocols/ipv6.rst:772
English
Format of the ICMPv6 Router Advertisement message
0/490 · 49
210
../../protocols/email.rst:435
English
When the first versions of SMTP were designed, the Internet was composed of minicomputers that were used by an entire university department or research lab. These minicomputers were used by many users at the same time. Email was mainly used to send messages from a user on a given host to another user on a remote host. At that time, SMTP was the only protocol involved in the delivery of the emails as all hosts attached to the network were running an SMTP server. On such hosts, an email destined to local users was delivered by placing the email in a special directory or file owned by the user. However, the introduction of personal computers in the 1980s changed this environment. Initially, users of these personal computers used applications such as :term:`telnet` to open a remote session on the local :term:`minicomputer` to read their email. This was not user-friendly. A better solution appeared with the development of user friendly email client applications on personal computers. Several protocols were designed to allow these client applications to retrieve the email messages destined to a user from his/her server. Two of these protocols became popular and are still used today. The Post Office Protocol (POP), defined in :rfc:`1939`, is the simplest one. It allows a client to download all the messages destined to a given user from his/her email server. We describe POP briefly in this section. The second protocol is the Internet Message Access Protocol (IMAP), defined in :rfc:`3501`. IMAP is more powerful, but also more complex than POP. IMAP was designed to allow client applications to efficiently access, in real-time, to messages stored in various folders on servers. IMAP assumes that all the messages of a given user are stored on a server and provides the functions that are necessary to search, download, delete or filter messages.
0/18620 · 1862
210
../../protocols/ipv6.rst:774
English
This message is sent from the link-local address of the router on the subnet. Its destination is the IPv6 multicast address that targets all IPv6 enabled hosts (i.e. ``ff02::1``). The `Cur Hop Limit` field, if different from zero, allows specifying the default `Hop Limit` that hosts should use when sending IPv6 packets from this subnet. ``64`` is a frequently used value. The `M` and `O` bits are used to indicate that some information can be obtained from DHCPv6. The `Router Lifetime` parameter provides the expected lifetime (in seconds) of the sending router acting as a default router. This lifetime enables planning the replacement of a router by another one in the same subnet. The `Reachable Time` and the `Retrans Timer` parameter are used to configure the utilization of the NDP protocol on the hosts attached to the subnet.
0/8360 · 836
211
../../protocols/email.rst:437
English
POP is another example of a simple line-based protocol. POP runs above the bytestream service. A POP server usually listens to port 110. A POP session is composed of three parts : an `authorisation` phase during which the server verifies the client's credential, a `transaction` phase during which the client downloads messages and an `update` phase that concludes the session. The client sends commands and the server replies are prefixed by `+OK` to indicate a successful command or by `-ERR` to indicate errors.
0/5140 · 514
211
../../protocols/ipv6.rst:776
English
Several options can be included in the Router Advertisement message. The simplest one is the MTU option that indicates the MTU to be used within the subnet. Thanks to this option, it is possible to ensure that all devices attached to the same subnet use the same MTU. Otherwise, operational problems could occur. The `Prefix` option is more important. It provides information about the prefix(es) that is (are) advertised by the router on the subnet.
0/4500 · 450
212
../../protocols/email.rst:439
English
When a client opens a transport connection with the POP server, the latter sends as banner an ASCII-line starting with `+OK`. The POP session is at that time in the `authorisation` phase. In this phase, the client can send its username (resp. password) with the `USER` (resp. `PASS`) command. The server replies with `+OK` if the username (resp. password) is valid and `-ERR` otherwise.
0/3860 · 386
212
../../protocols/ipv6.rst:782
English
The Prefix information option
0/290 · 29
213
../../protocols/email.rst:441
English
Once the username and password have been validated, the POP session enters in the `transaction` phase. In this phase, the client can issue several commands. The `STAT` command is used to retrieve the status of the server. Upon reception of this command, the server replies with a line that contains `+OK` followed by the number of messages in the mailbox and the total size of the mailbox in bytes. The `RETR` command, followed by a space and an integer, is used to retrieve the nth message of the mailbox. The `DELE` command is used to mark for deletion the nth message of the mailbox.
0/5860 · 586
213
../../protocols/ipv6.rst:787
English
The key information placed in this option are the prefix and its length. This allows the hosts attached to the subnet to automatically configure their own IPv6 address. The `Valid` and `Preferred` `Lifetimes` provide information about the expected lifetime of the prefixes. Associating some time validity to prefixes is a good practice from an operational viewpoint. There are some situations where the prefix assigned to a subnet needs to change without impacting the hosts attached to the subnet. This is often called the IPv6 renumbering problem in the literature :rfc:`7010`. A very simple scenario is the following. An SME subscribes to one ISP. Its router is attached to another router of this ISP and advertises a prefix assigned by the ISP. The SME is composed of a single subnet and all its hosts rely on stateless address configuration. After a few years, the SME decides to change of network provider. It connects its router to the second ISP and receives a different prefix from this ISP. At this point, two prefixes are advertised on the SME's subnet. The old prefix can be advertised with a short lifetime to ensure that hosts will stop using it while the new one is advertised with a longer lifetime. After sometime, the router stops advertising the old prefix and the hosts stop using it. The old prefix can now be returned back to the first ISP. In larger networks, renumbering an IPv6 remains a difficult operational problem [LeB2009]_.
0/14540 · 1454
214
../../protocols/email.rst:443
English
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.
0/2740 · 274
214
../../protocols/ipv6.rst:789
English
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.
0/3040 · 304
215
../../protocols/email.rst:445
English
The figure below provides a simple POP session. All lines prefixed with `C:` (resp. `S:`) are sent by the client (resp. server).
0/1280 · 128
215
../../protocols/ipv6.rst:791
English
Router Advertisements and Hop Limits
0/360 · 36
216
../../protocols/email.rst:471
English
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.
0/4530 · 453
216
../../protocols/ipv6.rst:793
English
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.
0/11400 · 1140
217
../../protocols/email.rst:482
English
Footnotes
0/100 · 9
217
../../protocols/ipv6.rst:796
English
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.
0/5710 · 571
218
../../protocols/email.rst:483
English
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.
0/2590 · 259
218
../../protocols/ipv6.rst:798
English
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.
0/1790 · 179