The Illustrated Network- P57 pps

But today almost all FTP client software, and many servers, use GUI interfaces to let users simply point and Table 20.5 FTP Commands for Transfer Parameters, with Meaning and Parameters

The three FTP commands that set the type, structure, and mode of the fi le transfer are outlined in Table 20.5 The 10 FTP commands that actually control the fi le trans-fer are outlined in Table 20.6 Finally, the fi ve FTP commands outlined in Table 20.7 supply useful information to the user

Variations on a Theme

Few people use the command line interface for FTP unless they have to However, it is common to use the CLI for instructional purposes (as done here) But today almost all FTP client software, and many servers, use GUI interfaces to let users simply point and

Table 20.5 FTP Commands for Transfer Parameters, with Meaning and Parameters

TYPE Identify the fi le type for transfer A (ASCII), E (EBCDIC), I (binary image),

N ( nonprint), T (telnet), C (ASA) STRU File structure F (fi le) or R (record)

MODE Format used for transmission S (stream), B (block), C (compressed)

Table 20.6 FTP Commands for File Transfer, with Meaning and Parameters

ALLO Allocate enough space for the data to come Integer number of bytes APPE Append a local fi le to the remote fi le File names

EPSV The extended version (RFC 2428) of the PASV

command, used for IPv6 and NAT

IP address and port

EPRT The extended version (RFC 2428) of the PORT

command, used for IPv6 and NAT

IP address and port

PASV Supply the network address and port number that will

be used for the data connection initiated by the client

IP address and port

PORT Supply the network address and port number that will

be used for the data connection initiated by the server

IP address and port

REST Identify a restart marker (followed by the transfer

command to be restarted)

Marker value

STOU Create a version of the fi le with a unique name (store

unique)

File name

CHAPTER 20 File Transfer Protocol 529

click at directories and fi les and effect a transfer Almost all still allow users to watch the interplay between mouse strokes and FTP commands and response codes, but few pay attention to them unless things go wrong

GUI implementations of FTP tend to be much more sophisticated than their CLI cousins, especially when it comes to security variations The heavy use of security on modern networks has spawned many variations of the simple FTP control and data connection process Most of these variations have to do with how the user ID and pass-word are packaged and sent from client to server, but some are more far-reaching than that Many commercial FTP server implementations can be set up to function in any of the following environments:

■ Simple FTP

■ FTP over Secure Sockets Layer and Transport Layer Security (SSL/TLS), using implicit encryption

■ FTP over SSL/TLS using explicit encryption

■ FTP over TLS directly, using explicit encryption

■ FTP bypassing the fi rewall

We’ll have much more to say about these security variations later in this book There

is also Secure FTP (SFTP), a feature of Secure Shell 2 (SSH2) But this is a completely different protocol than FTP, as we’ll see in Chapter 25 (on SSH)

A Note on NFS

If TCP/IP is indeed for everything, an employee at a branch bank should be able to use common TCP/IP applications to change a customer’s information in the central bank’s database However, it makes no sense at all to access the master account fi le, transfer a copy of it to the branch host, update it, and then load it back up to the central location

Not only does this method transfer masses of information not needed, but it prevents

(hopefully) anyone else from updating any other customer record at the same time

Table 20.7 FTP Commands for User Information, with Meaning and Parameters

HELP Gives information about server implementation None

SITE Used in the popular WU-FTP implementation from Washington

University (used in many Linux versions) to engage server-specifi c

commands not in the FTP standard

None

SYST Requests that the server identify its OS version None

STAT Request connection status and parameter information from server None

530 PART IV Application Level

Many applications don’t want or need remote fi le transfer They just need remote

fi le access, usually to a particular record or even fi eld This is the idea behind the

Net-work File System (NFS), pioneered by Sun Microsystems NFS allows local fi le systems

to be accessed by remote users as if they were local users and is a nice illustration of the power and utility of the socket interface

NFS is actually part of an overall system that includes an extension of the socket concept known as remote procedure calls (RPCs) RPCs are a more sophisticated way

of handling basic programming subroutine (or function) calls by allowing the subpro-gram (the procedure) to be called on a remote system across a network (hence the

term remote procedure call).

RPCs do not use well-known ports RPC server processes handle RPC client requests

for server connections by dynamically mapping the server ports In dynamic map-ping, all connection requests handled by TCP go to one server process running at the

application layer instead of several This server process is capable of dynamically start-ing up the correct port server application process and allowstart-ing the TCP protocol to grant the connection The single server application process running under dynamic

mapping is known as the port mapper These port mappers (usually run as the rpcbind

process) are very common on most Unix implementations of TCP/IP

Another part of the NFS is the External Data Representation (XDR) standard, a way

of defi ning data types in terms of standard formats The point is to allow remote fi le access between different platforms, from Unix to Windows to MACs and even more NFS has been a part of the overall TCP/IP standardization process since 1998

CHAPTER 20 File Transfer Protocol 531

This page intentionally left blank

QUESTIONS FOR READERS

Figure 20.12 shows some of the concepts discussed in this chapter and can be used to answer the following questions

1 Who initiates the data connection in active and passive mode, respectively?

2 In the fi gure, for active mode what port will the client use on the server for data transfer?

3 In the fi gure, for passive mode what port will the client use on the server for data transfer?

4 In the fi gure, what port will the client use for the data connection in active mode?

5 In the fi gure, what port will the client use for the data connection in passive

mode? How does the server know what it is?

CLIENT

ACK Send PORT 33167 command

(send or receive data)

(send or receive data) (send or receive data)

(send or receive data)

Send PASV command

“Use Data Port 2020”

Control Connection

on Port 4096

Control Connection

on Port 4096

Control Connection

on Port 21

Control Connection

on Port 21

Active FTP

Passive FTP

Data Connection

Open data connection

CLIENT

SERVER

SERVER

Data Connection Open data connection

FIGURE 20.12

Simplifi ed view of active and passive data transfer modes.

533

What You Will Learn

In this chapter, you will learn about the major architectures used to send and receive email on the Internet We’ll also see the fi ve steps needed to send an email message

You will learn about the protocols used with email applications, especially SMTP and POP3 We’ll also describe MIME messages and discuss the important role of headers in email

SMTP and Email

21

The Internet and TCP/IP are known to the greatest number of people through electronic mail (email) applications Even those who cannot tell a router from a modem, or a packet from a frame, can check their email and send a message A certain percentage of users still use the Internet mainly for email

Email was one of the original applications the Internet was created to support (the others being fi le transfer and remote computer access) Things have come a long way since the original mail application, which is still supported on many Unix boxes:

>mail harry

We need to talk.

.

The modern email explosion has produced on-line ads, do-not-contact lists, spam, spam blockers, evil attachments, impounded attachments, and dozens of other moves and countermoves that make the email experience at once essential and yet daunt-ing for many Hardly anyone uses email except through a GUI today, and the mail user agents (MUAs)—the technical term for email client applications—are as varied as they are powerful, allowing users to schedule meetings, reserve conference rooms, or even request a projector for a certain time or place

Email is a set of related and interconnected protocols that run on clients and servers

to provide the global mesh of mailboxes and readers and writers upon which email depends We’ll look at several scenarios for sending and receiving email, using the devices on the network shown in Figure 21.1

lo0: 192.168.0.1

fe-1/3/0: 10.10.11.1 MAC: 00:05:85:88:cc:db (Juniper_88:cc:db) IPv6: fe80:205:85ff:fe88:ccdb

P9

lo0: 192.168.9.1

PE5

lo0: 192.168.5.1

P4

lo0: 192.168.4.1

so-0/0/1 79.2

so-0/0/1 24.2

so-0/0/0 47.1

so-0/0 /2 29.2

so-0/0/3 49.2

so-0/0/3 49.1

so-0/0/059.2

so-0/0/2 45.1

so-0/0 /2 45.2

so-0/0/059.1

ge-0/0/3 50.2

ge-0/0/350.1 DSL Link

Ethernet LAN Switch with Twisted-Pair Wiring

em0: 10.10.11.177 eth0: 10.10.11.66 LAN2: 10.10.11.51

MAC: 00:0e:0c:3b:88:3c (Intel_3b:88:3c) IPv6: fe80::20e:

cff:fe3b:883c

LAN2: 10.10.11.111 MAC: 00:0e:0c:3b:87:36 (Intel_3b:87:36) IPv6: fe80::20e:

cff:fe3b:8736

winsvr1

LAN1

Los Angeles

Office

Ace ISP

AS 65459

Wireless

in Home

Email

Client

Email Server

Email Client

Solid rules ⫽ SONET/SDH

Dashed rules ⫽ Gig Ethernet

Note: All links use 10.0.x.y

addressing only the last

two octets are shown.

FIGURE 21.1

Email on the Illustrated Network, showing the Unix-based hosts used on email clients and servers.

536 PART IV Application Level

Email Server

Email Client

CE6

lo0: 192.168.6.1

fe-1/3/0: 10.10.12.1 MAC: 0:05:85:8b:bc:db (Juniper_8b:bc:db) IPv6: fe80:205:85ff:fe8b:bcdb Ethernet LAN Switch with Twisted-Pair Wiring

eth0: 10.10.12.77 eth0: 10.10.12.166 LAN2: 10.10.12.52

MAC: 00:0e:0c:3b:88:56 (Intel_3b:88:56) IPv6: fe80::20e:

cff:fe3b:8856

LAN2: 10.10.12.222 MAC: 00:02:b3:27:fa:8c IPv6: fe80::202: b3ff:fe27:fa8c

LAN2

New York

Office

P7

lo0: 192.168.7.1

PE1

lo0: 192.168.1.1

P2

lo0: 192.168.2.1

so-0/0/1

79.1

so-0/0/1

24.1

so-0/0/0

47.2

so-0/0/2

29.1

so-0/0/3 27.2

so-0/0/3 27.1

so-0/0/2 17.2

so-0/0/2 17.1

so-0/0/0 12.2

so-0/0/0 12.1

ge-0/0/3 16.2

ge-0/0/3 16.

1

Best ISP

AS 65127

Global Public Internet

In some examples, we’ll use the Unix-based host systems as email clients and servers We won’t leave Windows out, however We’ll use the email client at the home

to offi ce to show that Windows Outlook works essentially the same as older email systems

ARCHITECTURES FOR EMAIL

What needs to be added to the network to create the TCP/IP email system shown in the

fi gure? It all depends on the overall architecture used to support email, and these have evolved through three distinct stages, all of which are still supported today The fi nal stage is the general email architecture for the Internet today, and that’s what we will be exploring in this chapter The three architectures are:

Single shared system—The shared system could be a mainframe or minicomputer

that users access The email administrator creates mailboxes (restricted access

files on the local hard drive) where received messages are stored A special user agent (UA) program creates the messages and stores them in the user’s mailbox

Shared systems connected by the Internet—The second architecture takes into account the fact that users might not share the same local system Another piece was added to the email architecture: the message transfer agent (MTA) The UA still handles mailboxes and messages locally, whereas the MTA handles communications between the two systems in the usual client/server fashion

Email clients and servers connected by the Internet—The final step is to realize that today most users are connected to their email servers by a LAN or WAN (dial-up or DSL) link Because receivers are not always present (even on a LAN), users need the services of a message access agent (MAA) to retrieve their email from their local email server The architecture of this final scenario is shown

in Figure 21.2, between typical users we can call “Alice” and “Bob.” The flow shown is from Alice to Bob, but when Bob replies to Alice the roles of client and server (as well as MTA and MAA) are reversed

This architecture shows two systems dedicated to managing users’ email mailboxes and delivering email But how does the sender’s email system know which device is acting as the receiver’s email system? Today, special DNS records provide this

informa-tion, but in the early days of the Internet relaying was used to deliver email Email was

routed from email system to email system in a fashion similar to forwarding packets Today, most email travels over the Internet from an originator’s email system directly to the recipient’s, minimizing complexity and delay

But email servers are not necessary for the TCP/IP email protocol, the Simple Mail Transfer Protocol (SMTP), to operate We can still use the original and simple Unix built-in applications (sendmail and mail) to send and retrieve email from (for example)

538 PART IV Application Level