Overview of Ethernet Addresses

Overview of Ethernet Addresses

You may remember from an earlier section that TCP/IP is independent of the underlying network hardware. If you are running on an Ethernet-based network, be careful not to confuse the Ethernet hardware address and the IP address required by TCP/IP.
Each Ethernet network card (and any other NIC, for that matter) has its own unique hardware address, known as the media access control (MAC) address. This hardware address is predefined
and preprogrammed on the NIC by the manufacturer of the board as a unique 48-bit number.
The first three bytes of this address are called the Organizationally Unique Identifier (OUI) and are assigned by the Institute of Electrical and Electronics Engineers (IEEE). Manufacturers
purchase OUIs and then vary the last three bytes of the MAC address for each interface they produce, making each address unique provided no other manufacturer makes unauthorized use
of the OUI and related address space. Remember that the Ethernet address

Read More

Understanding IP Addressing

Understanding IP Addressing

As you know from the section “The Internet Layer Protocols” earlier in this chapter, IP moves data between computer systems in the form of a series of one or more packets, often making up
a TCP or UDP datagram, and each datagram is delivered to the IP destination system and to the port number (on that system) that is contained in the encapsulated TCP or UDP header. This
destination socket, or port and address combination, is a standard 48-bit number (a 32-bit IP address and a 16-bit port number) that contains enough information to identify the receiving network, the host for which the datagram is intended on that network, and the application running on that host.
        In this section, you’ll learn what IP addresses are, why they are so necessary, and how they are used in TCP/IP networking. But first, let’s clear up a possible source of confusion: Ethernet addresses and IP addresses.

Read More

Overview of Ports and Sockets

Overview of Ports and Sockets

On a TCP/IP network, data travels from a port on the sending computer to a port on the receiving computer. A port is a numerical value that identifies the application associated with the data. The source port number identifies the application that sent the data, and the destination port number identifies the application that receives the data. Each port is assigned a unique 16-bit number in the range of 0 through 65535. Additionally, there are two types of ports—TCP and UDP—which are based on their respective protocols. Both TCP and UDP maintain a separate list of used (reserved and allocated) port numbers. This allows them both to make sure no
port is duplicated within each list. A benefit of this mechanism is that multiple application data streams can be multiplexed through each protocol simultaneously. For example, it is no problem for TCP to handle HTTP traffic and FTP traffic simultaneously, nor is it a problem for UDP to allow TFTP and SNMP simultaneous access to the network.

Note:

Of course, simultaneous access is a figurative expression because, as with all serial data flows, only one data source can be serviced at a time. The appearance of simultaneous operation is achieved through time-division multiplexing, which interleaves the separate flows into one.

The very existence of ports and their numbers is more or less transparent to the users of the network because many server-side ports are standardized. Thus, a client application protocol
will know which remote port it should connect to for a specific service. For example, all servers that offer Telnet services usually do so on TCP port 23, and web servers normally run on TCP
port 80. This means that when you connect to the Internet to browse to a web server, you automatically connect to port 80, and when you use Telnet, you automatically connect to port 23.
The TCP/IP protocol suite uses a modifiable lookup table to determine the correct port for the data type. Table 3.1 lists some of the well-known port numbers for common protocols.

TABLE 3 . 1 Well-Known Port Numbers for Common Protocols

ــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــ
       Port                                           Protocol
ــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــ

       UDP port 15                               NETSTAT

       TCP port 20                                FTP data
       TCP port 21                                FTP control
       TCP port 22                                SSH
       TCP port 23                                Telnet
       TCP port 25                                SMTP
       TCP port 53                                DNS zone transfers
       UDP port 53                                DNS queries
       UDP port 69                                TFTP
       TCP port 70                                Gopher
       TCP port 79                                Finger
       TCP port 80                                HTTP
       TCP port 110                              POP3
       UDP port 111                              RPC
       TCP port 119                              NNTP
       TCP port 123                              NTP
       UDP port 137                              NetBIOS name service
       TCP port 143                               IMAP4
       UDP port 161                              SNMP
       TCP port 443                               HTTPS
       UDP port 520                               RIP

       UDP port 2049                             NFS
ــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــ

Client application protocols require identification by port numbers as well, but they could not possibly each have their own well-known port numbers, which is where registered port numbers come in. Registered port numbers begin at 1024 and extend to 49151. These port numbers are used by TCP and UDP alike to be temporarily assigned to client application protocols as they begin their journey to the remote device and its server application protocol. Ports from 49152 to 65535 are considered dynamic ports and/or private ports.

The combination of an IP address (more on IP addresses in a moment) and a port number is known as a socket. A socket identifies a single network process in terms of the entire Internet or other endto- end IP-based internetwork. Two sockets—one on the sending system and one on the receiving host—are needed to define a connection for connection-oriented protocols, such as TCP. You may hear or see the terms socket and port used as if they are interchangeable terms, but they are not.

Note:

In the Novell NetWare world, a socket is part of an IPX internetwork address
and acts as a destination for the IPX data packet. Most socket numbers are allocated
dynamically, but a few are associated with specific functions.

Sockets were first developed as a part of the BSD UNIX system kernel, in which they allow processes that are not running at the same time or on the same system to exchange information.
You can read data from or write data to a socket just as you can with a file. Socket pairs are bidirectional so that either process can send data to the other.

The Two Ports and Modes of FTP

You may have noticed in Table 3.1 that FTP has two TCP ports associated with it, one for control and the other for data. Additionally, FTP runs in two modes: active and passive. In every FTP active-mode session, both of these ports are used on the server but in very different capacities. Because the use of the FTP protocol implies that resources will be available across a potentially
insecure public infrastructure, it is important that the administrator of those resources have the last word as to their availability. This is where the two ports come into play. Port 21, the FTP control port, is targeted by the client when an FTP session is being requested of the server. In this request directed at the server’s TCP port 21, the client issues a PORT command, whereby it communicates to the server the random TCP port it would like the server to send data back to. This randomly assigned port will generally be one greater than the port it was using to source the traffic to port 21. The server then opens a TCP connection sourced from its own port 20, the
FTP data port, back to this advertised port on the client. Once this TCP connection is established, data transfer can commence across it. This prevents the client from simply reaching over to the server and grabbing whatever it wants without first being authenticated. The port 20 connection can be postponed, pending proper authentication from the client.
That’s how the active-mode FTP connection works. What if a firewall local to the user is secure enough not to allow what appears to be an externally initiated TCP connection? Well, then the
second half of the FTP process fails because that’s exactly what the server’s port-20-initiated connection is and data transfer never actually occurs. Why not let the client initiate the data connection
to port 20 at will? Well, if the server merely lets any and every client gain immediate access to its resources without authentication, FTP wouldn’t last very long as a successful protocol. One
solution is for everything to start the same way it does for the active-mode FTP connection, but instead of the server initiating the second session from port 20, it actually opens a random port,
as the client did, and asks the client to use that port to effect its data transfers. All of this can be done in the initial port 21 control phase, allowing any authentication the administrator has configured
to occur before this random port number is shared with the client. How does the server know the client wishes to start this type of connection and not have the server open a connection of its own from port 20? Instead of issuing the PORT command, as it did in the active-mode connection, the client issues the PASV command, indicating to the server that the client itself needs to open the data connection. This is known as passive-mode FTP. Not all client software supports passive-mode FTP, but most modern versions do. A key difference between the modes is that active mode uses both ports 20 and 21 but passive mode only uses port 21, substituting a registered port, greater than 1024, for port 20.

Read More

Internet Connection Sharing (ICS)

Internet Connection Sharing (ICS)

In addition to the standard TCP/IP services provided in Windows, Microsoft includes Internet Connection Sharing (ICS) services in all versions of Windows since Windows 98. What ICS does
is to take an Internet connection to one computer and share it with the rest of the computers on a network, essentially turning the computer connected to the Internet into an Internet gateway for
the rest of the network. Microsoft states that ICS works mostly at the Network layer of the OSI model, where it facilitates layer 3 access to the Internet on behalf of one or more other devices.
ICS works with just about any Internet connection type. The main benefit to ICS is that you are running an Internet gateway in software so you can avoid the added expense of a router for
your small network. However, the software gateway in ICS isn’t as efficient as a dedicated hardware router.

Read More

AppleTalk Filing Protocol (AFP)

AppleTalk Filing Protocol (AFP)

Before there was ever a Windows file sharing system in place, Apple had the AppleTalk Filing Protocol (AFP) for its AppleShare servers. AFP is the Presentation layer protocol that is used to
access AppleShare and Mac OS File Sharing files. It is the only protocol that accesses Apple- Share servers natively. Any system wanting to access an AppleShare server must be running
some version of AFP (or at least AFP over another transport protocol, like TCP/IP).

Note: 
See Chapter 2 for more on AFP.

==============================================

Real World scenario  

A Better Windows Server?

I was working at a local networking service establishment when I was presented with a problem.
A customer wanted a server capable of doing some file sharing. The server had to be
robust and capable of interacting with all of the company’s Windows clients. But they were at
the end of a budget cycle and the new budget wouldn’t be approved for at least a month and
they needed the server for one of their workgroups immediately. They had the hardware but
couldn’t afford the Windows 2000 Server licenses they needed and Windows 98 just wasn’t up
to par. The solution we came up with was to install Red Hat Linux on one of their machines and
then install Samba. It allowed them to have SMB-compatible file sharing and use their existing
Windows clients while not having to purchase a Windows server. To my knowledge, that server
is still running today.

Read More

Server Message Block (SMB) + Samba

Server Message Block (SMB)

Server Message Block (SMB) is a Presentation layer protocol developed through the efforts of corporations the likes of Xerox, 3Com, and IBM and further developed by (and currently attributed
to) Microsoft, providing a networking command message format used when sending networking commands to servers. These commands allow a client to do things like browse for resources; open connections, access files, printers, and communications ports; and list directories. SMB can be run over any number of lower-layer protocols, such as NetBEUI, NetBIOS over TCP/IP, NetBIOS over IPX/SPX, and others.

Samba
SMB is not limited to Windows machines (although they are where SMB commands are usually found). SMB is being developed for the world community as the Common Internet File System
(CIFS), a term now synonymous with SMB. Through Samba, one popular application of SMB/CIFS for the non-Microsoft market (visit samba.org), UNIX and Linux servers can use SMB commands
to communicate with Windows clients. Samba is a free open-source protocol suite that provides file and print services to SMB/CIFS clients. Samba allows for interoperability between Linux/UNIX servers and Windows-based clients by running on a platform other than Microsoft Windows, such as UNIXLinux, IBM OpenVMS, and so on. Samba uses TCP/IP installed on the host server, allowing that host to interact with a Microsoft Windows client or server as if it were a Windows file and print server.
The two primary programs, or daemons, of Samba, called smbd and nmbd, are responsible for two each of the four common CIFS services:

• File and print services
• Authentication and authorization
• Name resolution
• Service announcement (browsing)

Arguably the foundation of CIFS, file and print services are performed by smbd, as are authentication and authorization. The nmbd daemon provides NetBIOS name services to clients,

including name resolution and service announcement, often referred to as browsing services.

Read More

User Datagram Protocol (UDP)

User Datagram Protocol (UDP)

User Datagram Protocol (UDP) is a Transport layer connectionless protocol that does not provide the reliability services available with TCP but instead provides best effort transmission services to
application protocols. UDP gives applications a direct interface with IP and the ability to address a specific application protocol running on a host via a port number without setting up an end-toend
virtual circuit or connection. UDP, like TCP, uses IP to deliver its packets.
Figure 3.4 shows how some of these components fit together.

FIGURE 3 . 4 The components in a TCP/IP block diagram

Read More