tcp-ip-2

What do you mean by RFC? Explain its significance.

Requests for Comments (RFCs) The standards for TCP/IP are published in a series of documents called Requests for Comments (RFCs). RFCs describe the internal workings of the Internet. TCP/IP standards are always published as RFCs, although not all RFCs specify standards. Some RFCs provide informational, experimental, or historical information only. An RFC begins as an Internet draft, which is typically developed by one or more authors in an IETF working group. An IETF working group is a group of individuals that has a specific charter for an area of technology in the TCP/IP protocol suite.

2. Clearly differentiate between PVC and SVC.

Short for permanent virtual circuit, a virtual circuit that is permanently available. The only difference between a PVC and a switched virtual circuit (SVC) is that an SVC must be reestablished each time data is to be sent. Once the data has been sent, the SVC disappears. PVCs are more efficient for connections between hosts that communicate frequently.

PVCs play a central role in Frame Relay networks. They're also supported in some other types of networks, such as X.25.The ARP protocol resolves a host’s hardware address for a known IP address. The InATMARP protocol resolves a host’s IP address for a known hardware address. In a switched environment, you first establish a virtual connection (VC) of either a permanent virtual connection (PVC) or switched virtual connection (SVC) in order to communicate with another station. Therefore, you know the exact hardware address of the partner by administration, but the IP address is unknown. InATMARP provides dynamic address resolution.

ATM provides a virtual connection switched environment. VC setup can be done on either a permanent virtual connection (PVC) or a dynamic switched virtual connection (SVC) basis. SVC call management is performed by implementations of the Q.93B protocol.

3. Discuss various OPTIONS used by IP.

An IP implementation is not required to be capable of generating options in a datagram. However, all IP implementations are required to be able to process datagrams containing options. The Options field is variable in length (there can be zero or more options). There are two option formats. The format for each is dependent on the value of the option number found in the first octet:

fc (Flag copy): This field indicates whether (1) or not (0) the option field is

copied when the datagram is fragmented.

class: The option class is a 2-bit unsigned integer:

· 0: Control

· 1: Reserved

· 2: Debugging and measurement

· 3: Reserved

option number: The option number is a 5-bit unsigned integer:

· 0: End of option list. It has a class of 0, the fc bit is set to zero, and it has no length byte or data. That is, the option list is terminated by a X’00′ byte. It is only required if the IP header length (which is a multiple of 4 bytes) does not match the actual length of the options.

· 1: No operation. It has a class of 0, the fc bit is not set, and there is no length byte or data. It can be used to align fields in the datagram.

· 2: Security. It has a class of 0, the fc bit is set, and there is a length byte with a value of 11 and 8 bytes of data). It is used for security information needed by U.S.

· 3: Loose source routing. It has a class of 0, the fc bit is set, and there is a variable length data field.

· 4: Internet time stamp. It has a class of 2, the fc bit is not set, and there is a variable length data field. The total length can be up to 40 bytes. We discuss this option in more detail later.

· 7: Record route. It has a class of 0, the fc bit is not set, and there is a variable length data field.

· 8: Stream ID. It has a class of 0, the fc bit is set, and there is a length byte with a value of 4 and one data byte. It is used with the SATNET system.

· 9: Strict source routing. It has a class of 0, the fc bit is set, and there is a

variable length data field. We discuss this option in more detail later.

length: This field counts the length (in octets) of the option, including the type and length fields.

option data: This field contains data relevant to the specific option.

Padding: If an option is used, the datagram is padded with all-zero octets up to the next 32-bit boundary.

Data: The data contained in the datagram. It is passed to the higher-level protocol specified in the protocol field.

4. Differentiate between well known and ephemeral ports.

Each process that wants to communicate with another process identifies itself to the TCP/IP protocol suite by one or more ports. A port is a 16-bit number used by the host-to-host protocol to identify to which higher-level protocol or application program (process) it must deliver incoming messages. There are two types of ports:

1. Well-Known: Well-known ports belong to standard servers, for example, Telnet uses port 23. Well-known port numbers range between 1 and 1023 (prior to 1992, the range between 256 and 1023 was used for

2. UNIX-specific servers). Well-known port numbers are typically odd, because early systems using the port concept required an odd/even pair of ports for duplex operations. Most servers require only a single port. Exceptions are the BOOTP server, which uses two: 67 and 68 and the FTP server, which uses two: 20 and 21. The well-known ports are controlled and assigned by the Internet Assigned Number Authority (IANA) and on most systems can only be used by system processes or by programs executed by privileged users. Well-known ports allow clients to find servers without configuration information. The well-known port numbers are defined in STD 2 – Assigned Internet Numbers.

2. Ephemeral: Some clients do not need well-known port numbers because they initiate communication with servers, and the port number they are using is contained in the UDP/TCP datagrams sent to the server. Each client process is allocated a port number, for as long as it needs, by the host on which it is running. Ephemeral port numbers have values greater than 1023, normally in the range of 1024 to 65535. Ephemeral ports are not controlled by IANA and can be used by ordinary user-developed programs on most systems. Confusion, due to two different applications trying to use the same port numbers on one host, is avoided by writing those applications to request an available port from TCP/IP. Because this port number is dynamically assigned, it can differ from one invocation of an application to the next. UDP, TCP and ISO TP-4 all use the same port principle. To the best possible extent, the same port numbers are used for the same services on top of UDP, TCP and ISO TP-4.

5. Explain the DNS message format.

All messages in the Domain Name System protocol use a single format. This format is shown in Fig. 5.5. This frame is sent by the resolver to the name server. Only the header and the question section are used to form the query. Replies and forwarding of the query use the same frame, but with more sections filled in (the answer/authority/additional sections).Header Format: The header section is always present and has a fixed length of 12 bytes. The other sections are of variable length.

ID: A 16-bit identifier assigned by the program. This identifier is copied in the corresponding reply from the name server and can be used for differentiation

of responses when multiple queries are outstanding at the same time.

Where:

QR Flag identifying a query (0) or a response(1).

Op code 4-bit field specifying the kind of query:

0 Standard query (QUERY)

1 Inverse query (IQUERY)

2 Server status request (STATUS)

Other values are reserved for future use:

AA: Authoritative answer flag. If set in a response, this flag specifies that the responding name server is an authority for the domain name sent in the query.

TC: Truncation flag. Set if message was longer than permitted on the physical channel.

RD: Recursion desired flag. This bit signals to the name server that recursive resolution is asked for. The bit is copied to the response.

RA: Recursion available flag. Indicates whether the name server supports recursive resolution.

Zero: 3 bits reserved for future use. Must be zero.

Rcode: 4-bit response code. Possible values are:

0 No error.

1 Format error. The server was unable to interpret the message.

2 Server failure. The message was not processed because of a problem with the server.

3 Name error. The domain name in the query does not exist. This is only valid if the AA bit is set in the response.

4 Not implemented. The requested type of query is not implemented by name server.

5 Refused. The server refuses to respond for policy reasons. Other values are reserved for future use.

QDcount: An unsigned 16-bit integer specifying the number of entries in the question section.

ANcount: An unsigned 16-bit integer specifying the number of RRs in the answer section.

NScount: An unsigned 16-bit integer specifying the number of name server RRs in the authority section.

ARcount: An unsigned 16-bit integer specifying the number of RRs in the additional records section.Where:

Length: A single byte giving the length of the next label.

Label: One element of the domain name characters (for example, ibm from ral.ibm.com). The domain name referred to by the question is stored as a series of these variable length labels, each preceded by a 1-byte length.

00: X’00′ indicates the end of the domain name and represents the null label of the root domain.

Type: 2 bytes specifying the type of query. It can have any value from the Type field in a resource record.

Class: 2 bytes specifying the class of the query. For Internet queries, this will be IN.

For example, the domain name mydiv.mycorp.com is encoded with the following fields:

X’05′

"mydiv"

X’06′

"mycorp"

X’03′

"com"

X’00′

Therefore, the entry in the question section for mydiv.mycorp.com requires 22 bytes: 18 to store the domain name and 2 each for the Qtype and Qclass fields.

Where the fields before the TTL field have the same meanings as for a question entry and:

TTL: A 32-bit time-to-live value in seconds for the record. This defines how long it can be regarded as valid.

RDlength: A 16-bit length for the Rdata field.

Rdata: A variable length string whose interpretation depends on the Type field

6. Explain the principle of operation of REXEC protocol.

Remote Execution Command Daemon (REXECD) is a server that allows the execution of jobs submitted from a remote host over the TCP/IP network. The client uses the REXEC or Remote Shell Protocol (RSH) command to transfer the job across to the server. Any standard output or error output is sent back to the client for display or further processing.

REXECD is a server (or daemon). It handles commands issued by foreign hosts and transfers orders to subordinate virtual machines for job execution. The daemon performs automatic login and user authentication when a user ID and password are entered. The REXEC command is used to define the user ID, password, host address, and the process to be started on the remote host. However, RSH does not require you to send a user name and password; it uses a host access file instead. Both server and client are linked over the TCP/IP network. REXEC uses TCP port 512 and RSH uses TCP port 514

7. Explain various operations performed by the user with FTP.

When using FTP, the user performs some or all of the following operations:

· Connect to a remote host

· Navigate and manipulate the directory structure.

· List files available for transfer.

· Define the transfer mode, transfer type and data structure.

· Transfer data to or from the remote host.

· Disconnect from the remote host.

Connecting to a remote host

To execute a file transfer, the user begins by logging in to the remote host. This is only the primary method of implementing security within the FTP model. Additional security can be provided using SSL and TLS. Conversely, this authentication can be bypassed using anonymous FTP . There are four commands that are used:

Open: Selects the remote host and initiates the login session.

User: Identifies the remote user ID.

Pass: Authenticates the user.

Site: Sends information to the foreign host that is used to provide services specific to that host.

Navigating the directory structure

After a user has been authenticated and logged on to the server, that user can navigate through the directory structure of the remote host in order to locate the file desired for retrieval, or locate the directory into which a local file will be transferred. The user can also navigate the directory structure of the client’s host. After the correct local and remote directories have been accessed, users can display the contents of the remote directory. The subcommands that perform these functions are as follows:

cd: Changes the directory on the remote host: A path name can be specified, but must conform to the directory structure of the remote host. In most implementations, cd .. will move one directory up within the directory structure.

Lcd: Changes the directory on the local host. Similar to the cd command, a path name can be specified but must conform to the directory structure of the local host.

Ls: Lists the contents of the remote directory. The list generated by this command is treated as data, and therefore, this command requires the use of a data connection. This command is intended to create output readable by human users.

Dir: Lists the contents of the remote directory. Similar to the ls command, the list generated by dir is treated as data and requires the use of a data

connection. This command is intended to create output readable by programs.

Controlling the data transfer

Transferring data between dissimilar systems often requires transformations of the data as part of the transfer process. The user has to decide on three aspects of the data handling:

· The way the bits will be moved from one place to another

· The different representations of data on the system’s architecture

· The file structure in which the data is to be stored

Each of these is controlled by a subcommand:

Mode: Specifies whether the file is treated as having a record structure in a byte stream format:

B: This specifies block mode is to be used. This indicates that the logical record boundaries of the file are preserved.

S: This specifies that stream mode is to be used, meaning that the file is treated as a byte stream. This is the default and provides more efficient transfer but might not produce the desired results when working with a record-based file system.

Type: Specifies the character sets used in translating and representing the data:

A: Indicates that both hosts are ASCII-based, or that if one is ASCII-based and the other is EBCDIC-based, that ASCII-EBCDIC translation must be performed. On many implementations, this can be invoked by issuing the ASCII command, which the PI translates into the type A ommand.

E: Indicates that both hosts use an EBCDIC data representation. On many implementations, this can be invoked by issuing the EBCDIC command, which the PI translates into the type E command.

I: Indicates that no translation is to be done on the data. On many implementations, this can be invoked by using the BINARY command, which the PI translates into the type I command.

Structure: Specifies the structure of the file to be transferred:

File: Indicates that the file has no internal structure, and is considered to be a continuous sequence of data bytes.

Record: Indicates that the file is made up of sequential records.

Page: Indicates that the file is made up of independent indexed pages. Because these subcommands do not cover all possible differences between systems, the

site subcommand is available to issue implementation-dependent and platform-specific commands. The syntax of this command will vary by implementation.

Transferring files

The following commands can be used to copy files between FTP clients and servers:

Get: Copies a file from the remote host to the local host. The PI translates get: into a RETR command.

Mget: Copies multiple files from the remote to the local host. The PI translates mget into a series of RETR commands.

Put: Copies a file from the local host to the remote host. The PI translates put into a STOR command.

Mput: Copies multiple files from the local host to the remote host. The PI translates mput into a series of STOR commands.

Terminating the FTP session

The following commands are used to end an FTP session:

Quit: Disconnects from the remote host and terminates FTP. Some implementations use the BYE subcommand.

Close: Disconnects from the remote host but leaves the FTP client running. An open command can be issued to establish a new control connection.

8. Discuss the format of SMTP mail header.

Typically, a user does not have to worry about the message header because it is managed by SMTP itself. A short reference is included here for completeness. RFC 2822 contains a complete lexical analysis of the mail header. The syntax is written in a form known as the Augmented Backus-Naur Form (ABNF), defined in RFC 2822. Additionally, many RFCs related to RFC 2822 use this format. RFC 2822 also describes how to parse a mail header to a canonical representation, unfolding continuation lines, deleting insignificant spaces, removing comments, and so on. The syntax is powerful, but relatively difficult to parse. A basic description is given here, which should be adequate for you to interpret the

meaning of simple mail headers that might be encountered. Briefly, the header is a list of specifications in the form of:

keyword: value

Fields begin in column 1. Lines beginning with white space characters (space or tab) are continuation lines that are unfolded to create a single line for each field in the canonical representation. Strings enclosed in ASCII quotation marks indicate single tokens within which special characters, such as the colon, and are not significant. Many important field values (such as those for the To and From fields) are mailboxes. The most common forms for these are:

yourEmail@yourdiv.redbookscorp.com

Your Email <yourEmail@yourdiv.redbookscorp.com>

"Your Email" <yourEmail@yourdiv.redbookscorp.com>

In this example, the string Your Email is intended to be read by human recipients and is the name of the mailbox owner. yourEmail@yourdiv.redbookscorp.com is the machine-readable address of the mailbox (the angle brackets delimit the address but are not part of it).

9. With aid of a neat block diagram explain the structure of a web browser.

A browser is referred to as an application that provides access to a Web server. Depending on the

implementation, browser capabilities and thus structures vary. A Web browser, at a minimum, consists of an Hypertext Markup Language (HTML) interpreter and HTTP client that is used to retrieve HTML Web pages. Besides this basic requirement, many browsers also support FTP, NNTP, e-mail (POP and SMTP clients), among other features, with an easy-to-manage graphical interface. Fig. 9.1 illustrates a basic Web browser structure.

As with many other Internet facilities, the Web uses a client/server processing model. The Web browser is the client component. Examples of Web browsers include Mozilla Firefox, Netscape Navigator, and Microsoft Internet Explorer® Web browsers are responsible for formatting and displaying information, interacting with the user, and invoking external functions, such as Telnet, or external viewers for data types that Web browsers do not directly support. Web browsers have become the “universal client” for the GUI workstation environment, in much the same way that the ability to emulate popular terminals such as the DEC VT100 or IBM 3270 allows connectivity and access to character-based applications on a wide variety of computers. Web browsers are widely available for all popular GUI workstation platforms and are inexpensive.

10. Differentiate between getNextRequest and getBulkRequest taking an appropriate example.

getNextRequest: Requests that the agent return the first valid value following the specified object. For example, assume a getNext is executed for ifType (1.3.6.1.2.1.2.2.1.3). Assuming the first valid instance of ifType is ifType.1 (1.3.6.1.2.1.2.2.1.3.1), this is the value that the SNMP agent will return.getBulkRequest: Performs the same function as the get request, but allows the manager to query more than one object per request. This is only valid using the SNMPv2c security model .The GetBulkRequest is defined in RFC 3416 and is thus part of the protocol operations. A GetBulkRequest is generated and transmitted as a request of an SNMPv2 application. The purpose of the GetBulkRequest is to request the transfer of a potentially large amount of data, including, but not limited to, the efficient and rapid retrieval of large tables. The GetBulkRequest is more efficient than the GetNext request in case of retrieval of large MIB object tables. The syntax of the GetBulkRequest is:

GetBulkRequest [ non-repeaters = N, max-repetitions = M ]

( RequestedObjectName1,

RequestedObjectName2,

RequestedObjectName3 )

Where:

RequestedObjectName1, 2, 3

MIB object identifier, such as sysUpTime. The objects are in a lexicographically ordered list. Each object identifier has a binding to at least one variable. For example, the object identifier ipNetToMediaPhysAddress has a variable binding for each IP address in the ARP table and the content is the associated MAC address.

N Specifies the non-repeaters value, which means that you request only the contents of the variable next to the object specified in your request of the first N objects named between the parentheses. This is the same function as provided by the GetNextRequest.

M Specifies the max-repetitions value, which means that you request from the remaining (number of requested objects – N) objects the contents of the M variables next to your object specified in the request. Similar to an iterated GetNextRequest but transmitted in only one request. With the GetBulkRequest, you can efficiently get the contents of the next variable or the next M variables in only one request Assume the following ARP table in a host that runs an SNMPv2 agent:

Interface-Number Network-Address Physical-Address Type

1 10.0.0.51 00:00:10:01:23:45 static

1 9.2.3.4 00:00:10:54:32:10 dynamic

2 10.0.0.15 00:00:10:98:76:54 dynamic

An SNMPv2 manager sends the following request to retrieve

the sysUpTime and the complete ARP table:

This response signals the end of the table to the SNMPv2 manager. Using the getNextRequest, this same result requires four iterations of queries.

It is the purpose of the administrative model for SNMPv2 to define how the administrative framework is applied to realize effective network management in a variety of configurations and environments. The model entails the use of distinct identities for peers that exchange SNMPv2 messages. Therefore, it represents a departure from the community-based administrative model of the original SNMPv1. By unambiguously identifying the source and intended recipient of each SNMPv2 message, this new strategy improves on the historical community scheme both by supporting a more convenient access control model and allowing for effective use of asymmetric (public key) security

protocols in the future. Fig. 10.7 illustrates the new message format.

In this figure, the fields are defined as follows:

PDU Includes one of the following protocol data units:

• GetNextRequest

• GetRequest

• Inform

• Report

• Response

• SNMPv2-Trap

• SetRequest

The GetBulkRequest has a different PDU format, as hown earlier