CCNA Certification/Application Layer
Acknowledgements — Introduction — The OSI Model — Application Layer — Transport Layer — Network Layer — Addressing — Routing Protocols — Data Link Layer — Switching — Physical Layer — Router Operation — Advanced Addressing Topics — Advanced Routing Topics — Advanced Switching Topics — Security — WAN — Configuration — Conclusion — References — About the Exam — Cisco Router Commands — Quick Reference Sheet
Application Layer
The application layer is the seventh level of the seven-layer OSI model. It interfaces directly to and performs common application services for the application processes; it also issues requests to the presentation layer.
The common application layer services provide semantic conversion between associated application processes. Note: Examples of common application services of general interest include the virtual file, virtual terminal, and job transfer and manipulation protocols.
The application layer of the four layer and five layer TCP/IP models corresponds to the application layer, the presentation layer and session layer in the seven layer OSI model.
DHCP
DHCP is a set of rules used by communications devices such as a computer, router or network adapter to allow the device to request and obtain an IP address from a server which has a list of addresses available for assignment.
DHCP is a protocol used by networked computers (clients) to obtain IP addresses and other parameters such as the default gateway, subnet mask, and IP addresses of DNS servers from a DHCP server. It facilitates access to a network because these settings would otherwise have to be made manually for the client to participate in the network.
The DHCP server ensures that all IP addresses are unique, e.g., no IP address is assigned to a second client while the first client's assignment is valid (its lease has not expired). Thus IP address pool management is done by the server and not by a human network administrator.
DHCP emerged as a standard protocol in October 1993. As of 2006, RFC 2131 provides the latest ([dated March 1997]) DHCP definition. DHCP functionally became a successor to the older BOOTP protocol, whose leases were given for infinite time and did not support options. Due to the backward-compatibility of DHCP, very few networks continue to use pure BOOTP.
The latest non-standard of the protocol, describing DHCPv6 (DHCP in an IPv6 environment), appeared in July 2003 as RFC 3315.
IP address allocation
Depending on implementation, the DHCP server has three methods of allocating IP-addresses:
- manual allocation, where the DHCP server performs the allocation based on a table with MAC address - IP address pairs manually filled by the server administrator. Only requesting clients with a MAC address listed in this table get the IP address according to the table.
- automatic allocation, where the DHCP server permanently assigns to a requesting client a free IP-address from a range given by the administrator.
- dynamic allocation, the only method which provides dynamic re-use of IP addresses. A network administrator assigns a range of IP addresses to DHCP, and each client computer on the LAN has its TCP/IP software configured to request an IP address from the DHCP server when that client computer's network interface card starts up. The request-and-grant process uses a lease concept with a controllable time period. This eases the network installation procedure on the client computer side considerably.
This decision is generally unapparent to clients.
Some DHCP server implementations can update the DNS name associated with the client hosts to reflect the new IP address. They make use of the DNS update protocol established with RFC 2136.
DHCP and firewalls
Firewalls usually have to permit DHCP traffic explicitly. Specification of the DHCP client-server protocol describes several cases when packets must have the source address of 0x00000000 or the destination address of 0xffffffff. Anti-spoofing policy rules and tight inclusive firewalls often stop such packets. Multi-homed DHCP servers require special consideration and further complicate configuration.
To allow DHCP, network administrators need to allow several types of packets through the server-side firewall. All DHCP packets travel as UDP datagrams; all client-sent packets have source port 68 and destination port 67; all server-sent packets have source port 67 and destination port 68. For example, a server-side firewall should allow the following types of packets:
- Incoming packets from 0.0.0.0 or dhcp-pool to dhcp-ip
- Incoming packets from any address to 255.255.255.255
- Outgoing packets from dhcp-ip to dhcp-pool or 255.255.255.255
where dhcp-ip represents any address configured on a DHCP server host and dhcp-pool stands for the pool from which a DHCP server assigns addresses to clients
Example in ipfw firewall
To give an idea of how a configuration would look in production, the following rules for a server-side ipfirewall to allow DHCP traffic through. Dhcpd operates on interface rl0 and assigns addresses from 192.168.0.0/24 :
pass udp from 0.0.0.0,192.168.0.0/24 68 to me 67 in recv rl0 pass udp from any 68 to 255.255.255.255 67 in recv rl0 pass udp from me 67 to 192.168.0.0/24,255.255.255.255 68 out xmit rl0
Example in Cisco IOS Extended ACL
The following entries are valid on a Cisco 3560 switch with enabled DHCP service. The ACL is applied to a routed interface, 10.32.73.129, on input. The subnet is 10.32.73.128/26.
10 permit udp host 0.0.0.0 eq bootpc host 10.32.73.129 eq bootps 20 permit udp 10.32.73.128 0.0.0.63 eq bootpc host 10.32.73.129 eq bootps 30 permit udp any eq bootpc host 255.255.255.255 eq bootps
Technical details
DHCP uses the same two IANA assigned ports as BOOTP: 67/udp for the server side, and 68/udp for the client side.
DHCP operations fall into four basic phases. These phases are IP lease request, IP lease offer, IP lease selection, and IP lease acknowledgement.
DHCP discovery
The client broadcasts on the local physical subnet to find available servers. Network administrators can configure a local router to forward DHCP packets to a DHCP server on a different subnet. This client-implementation creates a UDP packet with the broadcast destination of 255.255.255.255 or subnet broadcast address.
A client can also request its last-known IP address (in the example below, 192.168.1.100). If the client is still in a network where this IP is valid, the server might grant the request. Otherwise, it depends whether the server is set up as authoritative or not. An authoritative server will deny the request, making the client ask for a new IP immediately. A non-authoritative server simply ignores the request, leading to an implementation dependent time out for the client to give up on the request and ask for a new IP.
DHCP offers
When a DHCP server receives an IP lease request from a client, it extends an IP lease offer. This is done by reserving an IP address for the client and sending a DHCPOFFER message across the network to the client. This message contains the client's MAC address, followed by the IP address that the server is offering, the subnet mask, the lease duration, and the IP address of the DHCP server making the offer.
The server determines the configuration, based on the client's hardware address as specified in the CHADDR field. Here the server, 192.168.1.1, specifies the IP address in the YIADDR field.
DHCP requests
The client selects a configuration out of the DHCP "Offer" packets it has received and broadcasts it on the local subnet. Again, this client requests the 192.168.1.100 address that the server specified. In case the client has received multiple offers it specifies the server from which it has accepted the offer.
DHCP acknowledgement
When the DHCP server receives the DHCPREQUEST message from the client, it initiates the final phase of the configuration process. This acknowledgement phase involves sending a DHCPACK packet to the client. This packet includes the lease duration and any other configuration information that the client might have requested. At this point, the TCP/IP configuration process is complete.
The server acknowledges the request and sends the acknowledgement to the client. The system as a whole expects the client to configure its network interface with the supplied options.
|
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
DHCP selection
When the client PC receives an IP lease offer, it must tell all the other DHCP servers that it has accepted an offer. To do this, the client broadcasts a DHCPREQUEST message containing the IP address of the server that made the offer. When the other DHCP servers receive this message, they withdraw any offers that they might have made to the client. They then return the address that they had reserved for the client back to the pool of valid addresses that they can offer to another computer. Any number of DHCP servers can respond to an IP lease request, but the client can only accept one offer per network interface card.
DHCP information
The client sends a request to the DHCP server: either to request more information than the server sent with the original DHCPACK; or to repeat data for a particular application - for example, browsers use DHCP Inform to obtain web proxy settings via WPAD. Such queries do not cause the DHCP server to refresh the IP expiry time in its database.
DHCP releasing
The client sends a request to the DHCP server to release the DHCP and the client unconfigures its IP address. As clients usually do not know when users may unplug them from the network, the protocol does not define the sending of DHCP Release as mandatory.
Simple Mail Transfer Protocol (SMTP) is the de facto standard for e-mail transmissions across the Internet. Formally SMTP is defined in RFC 821 (STD 10) as amended by RFC 1123 (STD 3) chapter 5. The protocol used today is also known as ESMTP and defined in RFC 2821.
Description
SMTP is a relatively simple, text-based protocol, where one or more recipients of a message are specified (and in most cases verified to exist) and then the message text is transferred. It is quite easy to test an SMTP server using the telnet program (see below).
SMTP uses TCP port 25. To determine the SMTP server for a given domain name, the MX (Mail eXchange) DNS record is typically used, falling back to a simple A record in the case of no MX (not all MTAs (Mail Transfer Agents) support fallback). Some current mail transfer agents will also use SRV records, a more general form of MX, though these are not widely adopted.
SMTP is a "push" protocol that does not allow one to "pull" messages from a remote server on demand. To do this a mail client must use POP3 or IMAP. Another SMTP server can trigger a delivery in SMTP using ETRN.
History
SMTP developed out of Mail Box Protocol (ca. 1971), FTP Mail (ca. 1973)[1], and Mail Protocol. [2]. The work continued throughout the 1970s, until the ARPANET converted into the modern Internet around 1980. Jon Postel then proposed a Mail Transfer Protocol in 1980 that began to remove the mail's reliance on FTP.[3] SMTP was published as RFC 821 in 1982, also by Jonathan Postel.
SMTP started becoming widely used in the early 1980s. At the time, it was a complement to UUCP (Unix to Unix CoPy) which was better suited to handle e-mail transfers between machines that were intermittently connected. SMTP, on the other hand, works best when both the sending and receiving machines are connected to the network all the time. Both use a store and forward mechanism and are examples of push technology.
The article about sender rewriting contains technical background info about the early SMTP history and source routing before RFC 1123.
Sendmail was one of the first (if not the first) mail transfer agent to implement SMTP. As of 2001 there are at least 50 programs that implement SMTP as a client (sender of messages) or a server (receiver of messages). Some other popular SMTP server programs include Postfix, qmail, Novell GroupWise, Exim, Novell NetMail and Microsoft Exchange Server.
Since this protocol started out as purely ASCII text-based, it did not deal well with binary files. Standards such as Multipurpose Internet Mail Extensions MIME were developed to encode binary files for transfer through SMTP. MTAs developed after sendmail also tended to be implemented 8-bit-clean, so that the alternate "just send eight" strategy could be used to transmit arbitrary data via SMTP. Non-8-bit-clean MTAs today tend to support the 8BITMIME extension, permitting binary files to be transmitted almost as easily as plain text.
Developers
Many people edited or contributed to the core SMTP specifications, among them Jon Postel, Eric Allman, Dave Crocker, Ned Freed, Randall Gellens, John Klensin, and Keith Moore.
Sample communications
After establishing a connection between the sender (the client) and the receiver (the server), the following is a legal SMTP session. In the following conversation, everything sent by the client is prefaced with C: and everything sent by the server is prefaced with S:. On most computer systems, a connection can be established using the telnet command on the client machine, for example.
telnet www.example.com 25
which opens a TCP connection from the sending machine to the MTA listening on port 25 on host www.example.com.
S: 220 www.example.com ESMTP Postfix C: HELO mydomain.com S: 250 Hello mydomain.com C: MAIL FROM:<sender@mydomain.com> S: 250 Ok C: RCPT TO:<friend@example.com> S: 250 Ok C: DATA S: 354 End data with <CR><LF>.<CR><LF> C: Subject: test message C: From: sender@mydomain.com C: To: friend@example.com C: C: Hello, C: This is a test. C: Goodbye. C: . S: 250 Ok: queued as 12345 C: QUIT S: 221 Bye
Although optional and not shown above, nearly all clients ask the server which SMTP extensions the server supports, by using the EHLO greeting to invoke Extended SMTP (ESMTP). These clients use HELO only if the server does not respond to EHLO.
Contemporary clients will use the ESMTP extension keyword SIZE to inquire of the server the maximum message size that will be accepted. Older clients and servers will try to transfer huge messages that will be rejected after wasting the network resources, including a lot of connect time to dialup ISPs that are paid by the minute.
For the edit planning of giant files or sending with older clients, users can manually determine in advance the maximum size accepted by ESMTP servers. The user telnets as above, but substitutes "EHLO mydomain.com" for the HELO command line.
S: 220-serverdomain.com ESMTP {postfix version and date}
S: 220 NO UCE. {etc., terms of service}
C: EHLO mydomain.com
S: 250-serverdomain.com Hello mydomain.com [127.0.0.1]
S: 250-SIZE 14680064
S: 250-PIPELINING
S: 250 HELP
This serverdomain.com declares that it will accept a fixed maximum message size no larger than 14,680,064 octets (8-bit bytes). Depending on the server's actual resource usage, it may be currently unable to accept a message this large.
In the simplest case, an ESMTP server will declare a maximum SIZE with only the EHLO user interaction. If no number appears after the SIZE keyword, or if the current message limit must be exactly determined, the user can further interact by simulating the ESMTP header of a message with an estimated size. See External Link RFC 1870 below.
Security and spamming
- Main article: Anti-spam techniques (e-mail)
One of the limitations of the original SMTP is that it has no facility for authentication of senders. Therefore the SMTP-AUTH extension was defined. However, the impracticalities of widespread SMTP-AUTH implementation and management means that E-mail spamming is not and cannot be addressed by it.
Modifying SMTP extensively, or replacing it completely, is not believed to be practical, due to the network effects of the huge installed base of SMTP. Internet Mail 2000 is one such proposal for replacement.
Spam is enabled by several factors, including vendors implementing broken MTAs (that do not adhere to standards, and therefore make it difficult for other MTAs to enforce standards), security vulnerabilities within the operating system (often exacerbated by always-on broadband connections) that allow spammers to remotely control end-user PCs and cause them to send spam, and a regrettable lack of "intelligence" in many MTAs still a major problem.
There are a number of proposals for sideband protocols that will assist SMTP operation. The Anti-Spam Research Group (ASRG) of the Internet Research Task Force (IRTF) is working on a number of E-mail authentication and other proposals for providing simple source authentication that is flexible, lightweight, and scalable. Recent Internet Engineering Task Force (IETF) activities include MARID (2004) leading to two approved IETF experiments in 2005, and DomainKeys Identified Mail in 2006.
In computing, local e-mail clients use the Post Office Protocol version 3 (POP3), an application-layer Internet standard protocol, to retrieve e-mail from a remote server over a TCP/IP connection. Nearly all subscribers to individual Internet service provider e-mail accounts access their e-mail with client software that uses POP3.
Overview
POP3 has made earlier versions of the protocol obsolete, POP (informally called POP1) and POP2. In contemporary usage, the less precise term POP almost always means POP3 in the context of e-mail protocols.
The design of POP3 and its procedures supports end-users with intermittent connections (such as dial-up connections), allowing these users to retrieve e-mail when connected and then to view and manipulate the retrieved messages without needing to stay connected. Although most clients have an option to leave mail on server, e-mail clients using POP3 generally connect, retrieve all messages, store them on the user's PC as new messages, delete them from the server, and then disconnect. In contrast, the newer, more capable Internet Message Access Protocol (IMAP) supports both connected and disconnected modes of operation. E-mail clients using IMAP generally leave messages on the server until the user explicitly deletes them. This and other facets of IMAP operation allow multiple clients to access the same mailbox. Most e-mail clients support either POP3 or IMAP to retrieve messages; however, fewer Internet Service Providers (ISPs) support IMAP. The fundamental difference between POP3 and IMAP4 is that POP3 offers access to a mail drop; the mail exists on the server until it is collected by the client. Even if the client leaves some or all messages on the server, the client's message store is considered authoritative. In contrast, IMAP4 offers access to the mail store; the client may store local copies of the messages, but these are considered to be a temporary cache; the server's store is authoritative.
Clients with a leave mail on server option generally use the POP3 UIDL (Unique IDentification Listing) command. Most POP3 commands identify specific messages by their ordinal number on the mail server. This creates a problem for a client intending to leave messages on the server, since these message numbers may change from one connection to the server to another. For example if a mailbox contains five messages at last connect, and a different client then deletes message #3, the next connecting user will find the last two messages' numbers decremented by one. UIDL provides a mechanism to avoid these numbering issues. The server assigns a string of characters as a permanent and unique ID for the message. When a POP3-compatible e-mail client connects to the server, it can use the UIDL command to get the current mapping from these message IDs to the ordinal message numbers. The client can then use this mapping to determine which messages it has yet to download, which saves time when downloading. IMAP has a similar mechanism, using a 32-bit UID (Unique IDentifier) that is required to be strictly ascending. The advantage of the numeric UID is with large mailboxes; a client can request just the UIDs greater than its previously stored "highest UID". In POP, the client must fetch the entire UIDL map.
Whether using POP3 or IMAP to retrieve messages, e-mail clients typically use the SMTP_Submit profile of the SMTP protocol to send messages. E-mail clients are commonly categorized as either POP or IMAP clients, but in both cases the clients also use SMTP. There are extensions to POP3 that allow some clients to transmit outbound mail via POP3 - these are known as "XTND XMIT" extensions. The Qualcomm qpopper and CommuniGate Pro servers and Eudora clients are examples of systems that optionally utilize the XTND XMIT methods of authenticated client-to-server e-mail transmission.
MIME serves as the standard for attachments and non-ASCII text in e-mail. Although neither POP3 nor SMTP require MIME-formatted e-mail, essentially all Internet e-mail comes MIME-formatted, so POP clients must also understand and use MIME. IMAP, by design, assumes MIME-formatted e-mail.
Like many other older Internet protocols, POP3 originally supported only an unencrypted login mechanism. Although plain text transmission of passwords in POP3 still commonly occurs, POP3 currently supports several authentication methods to provide varying levels of protection against illegitimate access to a user's e-mail. One such method, APOP, uses the MD5 hash function in an attempt to avoid replay attacks and disclosure of a shared secret. Clients implementing APOP include Mozilla, Thunderbird, Opera, Eudora, KMail and Novell Evolution. POP3 clients can also support SASL authentication methods via the AUTH extension.
POP3 works over a TCP/IP connection using TCP on network port 110. E-mail clients can encrypt POP3 traffic using TLS or SSL. A TLS or SSL connection is negotiated using the STLS command. Some clients and servers, like Google Gmail, instead use the deprecated alternate-port method, which uses TCP port 995.
Dialog example
RFC 1939 APOP support indicated by <1896.697170952@dbc.mtview.ca.us> here:
S: <wait for connection on TCP port 110> C: <open connection> S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us> C: APOP mrose c4c9334bac560ecc979e58001b3e22fb S: +OK mrose's maildrop has 2 messages (320 octets) C: STAT S: +OK 2 320 C: LIST S: +OK 2 messages (320 octets) S: 1 120 S: 2 200 S: . C: RETR 1 S: +OK 120 octets S: <the POP3 server sends message 1> S: . C: DELE 1 S: +OK message 1 deleted C: RETR 2 S: +OK 200 octets S: <the POP3 server sends message 2> S: . C: DELE 2 S: +OK message 2 deleted C: QUIT S: +OK dewey POP3 server signing off (maildrop empty) C: <close connection> S: <wait for next connection>
POP3 servers without the optional APOP command expect you to log in with the USER and PASS commands:
C: USER mrose S: +OK User accepted C: PASS mrosepass S: +OK Pass accepted
web
Hypertext Transfer Protocol (HTTP) is a method used to transfer or convey information on the World Wide Web. Its original purpose was to provide a way to publish and retrieve HTML pages.
Development of HTTP was coordinated by the World Wide Web Consortium and the Internet Engineering Task Force, culminating in the publication of a series of RFCs, most notably RFC 2616 (1999), which defines HTTP/1.1, the version of HTTP in common use today.
HTTP is a request/response protocol between clients and servers. The originating client, such as a web browser, spider, or other end-user tool, is referred to as the user agent. The destination server, which stores or creates resources such as HTML files and images, is called the origin server. In between the user agent and origin server may be several intermediaries, such as proxies, gateways, and tunnels.
An HTTP client initiates a request by establishing a Transmission Control Protocol (TCP) connection to a particular port on a remote host (port 80 by default; see List of TCP and UDP port numbers). An HTTP server listening on that port waits for the client to send a request message.
Upon receiving the request, the server sends back a status line, such as "HTTP/1.1 200 OK", and a message of its own, the body of which is perhaps the requested file, an error message, or some other information.
Resources to be accessed by HTTP are identified using Uniform Resource Identifiers (URIs) (or, more specifically, URLs) using the http: or https URI schemes.
Request message
The request message consists of the following:
- Request line, such as GET /images/logo.gif HTTP/1.1, which requests the file logo.gif from the /images directory
- Headers, such as Accept-Language: en
- An empty line
- An optional message body
The request line and headers must all end with CRLF (i.e. a carriage return followed by a line feed). The empty line must consist of only CRLF and no other whitespace.
In the HTTP/1.1 protocol, all headers except Host are optional.
Request methods
HTTP defines eight methods (sometimes referred to as "verbs") indicating the desired action to be performed on the identified resource.
- HEAD
- Asks for the response identical to the one that would correspond to a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content.
- GET
- Requests a representation of the specified resource. By far the most common method used on the Web today. Should not be used for operations that cause side-effects (using it for actions in web applications is a common misuse). See 'safe methods' below.
- POST
- Submits data to be processed (e.g. from an HTML form) to the identified resource. The data is included in the body of the request. This may result in the creation of a new resource or the updates of existing resources or both.
- PUT
- Uploads a representation of the specified resource.
- DELETE
- Deletes the specified resource.
- TRACE
- Echoes back the received request, so that a client can see what intermediate servers are adding or changing in the request.
- OPTIONS
- Returns the HTTP methods that the server supports. This can be used to check the functionality of a web server.
- CONNECT
- For use with a proxy that can change to being an SSL tunnel.
HTTP servers are supposed to implement at least the GET and HEAD methods and, whenever possible, also the OPTIONS method.
Safe methods
Some methods (e.g. HEAD or GET) are defined as safe, which means they are intended only for information retrieval and should not change the state of the server (in other words, they should not have side effects). Unsafe methods (such as POST, PUT and DELETE) should be displayed to the user in a special way, typically as buttons rather than links, thus making the user aware of possible obligations (such as a button that causes a financial transaction).
Despite the required safety of GET requests, in practice they can cause changes on the server. For example, a Web server may use the retrieval through a simple hyperlink to initiate deletion of a domain database record, thus causing a change of the server's state as a side-effect of a GET request. This is discouraged, because it can cause problems for Web caching, search engines and other automated agents, who can make unintended changes on the server. Another case is that a GET request may cause the server to create a cache space. The important distinction is that the client did not request the side effect and is not liable (technically, financially or legally) for these side-effects [citation needed] .
Obligated methods
Methods (eg. POST, PUT, or DELETE) that are intended to cause "real-world" effects are defined as Obligated because the client that initiates the request is responsible for such effects.
Idempotent methods
Methods GET, HEAD, PUT and DELETE are defined to be idempotent, meaning that multiple identical requests should have the same effect as a single request. Methods OPTIONS and TRACE, being safe, are inherently idempotent.
HTTP versions
HTTP has evolved into multiple, mostly backwards-compatible protocol versions. RFC 2145 describes the use of HTTP version numbers. Basically, the client tells in the beginning of the request the version it uses, and the server uses the same or earlier version in the response.
