halaman web

Laman, halaman muka atau beranda (Bahasa Melayu: laman, yakni "muka surat" atau "halaman muka") kata laman dalam bahasa Indonesia sendiri berarti "halaman depan" atau "halaman muka" yang bisa mengacu kepada halaman depan buku, surat, situs web, dan lain sebagainya. Menurut Panduan Pembakuan Istilah Pelaksanaan Instruksi Presiden Nomor 2 Tahun 2001 tentang Penggunaan Komputer dengan Aplikasi Komputer Berbahasa Indonesia/Kiat Pembakuan Peristilahan Perkomputeran dalam Bahasa Indonesia, kata laman dipakai untuk menggantikan kata home page atau index page dalam bahasa Inggris. Namun dewasa ini kata laman sering digunakan menggantikan kata halaman.
Dalam istilah komputer, laman juga disebut halaman beranda, halaman awal, halaman utama, dan Front Page, halaman depan dari sebuah situs web yang dirancang sebagai titik fokus pusat. Dalam kebanyakan kasus, situs web ini juga bertindak sebagai halaman yang mengirimkan informasi ke komputer lain ketika telah terhubung ke dalam jaringan tanpa permintaan informasi khusus.
Diposting oleh Tidak ada komentar:

web server

The term web server, also written as Web server, can refer to either the hardware (the computer) or the software (the computer application) that helps to deliver web content that can be accessed through the Internet.[1]
The most common use of web servers is to host websites, but there are other uses such as gaming, data storage, running enterprise applications, handling email, FTP, or other web uses.

Overview

The primary function of a web server is to store, process and deliver web pages to clients. The communication between client and server takes place using the Hypertext Transfer Protocol (HTTP). Pages delivered are most frequently HTML documents, which may include images, style sheets and scripts in addition to text content.
A user agent, commonly a web browser or web crawler, initiates communication by making a request for a specific resource using HTTP and the server responds with the content of that resource or an error message if unable to do so. The resource is typically a real file on the server's secondary storage, but this is not necessarily the case and depends on how the web server is implemented.
While the primary function is to serve content, a full implementation of HTTP also includes ways of receiving content from clients. This feature is used for submitting web forms, including uploading of files.
Many generic web servers also support server-side scripting using Active Server Pages (ASP), PHP, or other scripting languages. This means that the behaviour of the web server can be scripted in separate files, while the actual server software remains unchanged. Usually, this function is used to create HTML documents dynamically ("on-the-fly") as opposed to returning static documents. The former is primarily used for retrieving and/or modifying information from databases. The latter is typically much faster and more easily cached but cannot deliver dynamic content.
Web servers are not always used for serving the World Wide Web. They can also be found embedded in devices such as printers, routers, webcams and serving only a local network. The web server may then be used as a part of a system for monitoring and/or administering the device in question. This usually means that no additional software has to be installed on the client computer, since only a web browser is required (which now is included with most operating systems).

History

The world's first web server, a NeXT Computer workstation with Ethernet, 1990, the case label reads: "This machine is a server. DO NOT POWER IT DOWN!!"
In 1989 Tim Berners-Lee proposed a new project to his employer CERN, with the goal of easing the exchange of information between scientists by using a hypertext system. The project resulted in Berners-Lee writing two programs in 1990:
Between 1991 and 1994, the simplicity and effectiveness of early technologies used to surf and exchange data through the World Wide Web helped to port them to many different operating systems and spread their use among scientific organizations and universities, and then to industry.
In 1994 Tim Berners-Lee decided to constitute the World Wide Web Consortium (W3C) to regulate the further development of the many technologies involved (HTTP, HTML, etc.) through a standardization process.

Common features

Path translation

Web servers are able to map the path component of a Uniform Resource Locator (URL) into:
  • A local file system resource (for static requests)
  • An internal or external program name (for dynamic requests)
For a static request the URL path specified by the client is relative to the web server's root directory.
Consider the following URL as it would be requested by a client:
http://www.example.com/path/file.html
The client's user agent will translate it into a connection to www.example.com with the following HTTP 1.1 request:
GET /path/file.html HTTP/1.1
Host: www.example.com
The web server on www.example.com will append the given path to the path of its root directory. On an Apache server, this is commonly /home/www (On Unix machines, usually /var/www). The result is the local file system resource:
/home/www/path/file.html
The web server then reads the file, if it exists and sends a response to the client's web browser. The response will describe the content of the file and contain the file itself or an error message will return saying that the file does not exist or is unavailable.

Kernel-mode and user-mode web servers

A web server can be either implemented into the OS kernel, or in user space (like other regular applications).
An in-kernel web server (like Microsoft IIS on Windows or TUX on GNU/Linux) will usually work faster, because, as part of the system, it can directly use all the hardware resources it needs, such as non-paged memory, CPU time-slices, network adapters, or buffers.
Web servers that run in user-mode have to ask the system for permission to use more memory or more CPU resources. Not only do these requests to the kernel take time, but they are not always satisfied because the system reserves resources for its own usage and has the responsibility to share hardware resources with all the other running applications. Executing in user mode can also mean useless buffer copies which are another handicap for user-mode web servers.

Load limits

A web server (program) has defined load limits, because it can handle only a limited number of concurrent client connections (usually between 2 and 80,000, by default between 500 and 1,000) per IP address (and TCP port) and it can serve only a certain maximum number of requests per second depending on:
  • its own settings,
  • the HTTP request type,
  • whether the content is static or dynamic,
  • whether the content is cached, and
  • the hardware and software limitations of the OS of the computer on which the web server runs.
When a web server is near to or over its limit, it becomes unresponsive.

Causes of overload

At any time web servers can be overloaded because of:
  • Too much legitimate web traffic. Thousands or even millions of clients connecting to the web site in a short interval, e.g., Slashdot effect;
  • Distributed Denial of Service attacks. A denial-of-service attack (DoS attack) or distributed denial-of-service attack (DDoS attack) is an attempt to make a computer or network resource unavailable to its intended users;
  • Computer worms that sometimes cause abnormal traffic because of millions of infected computers (not coordinated among them);
  • XSS viruses can cause high traffic because of millions of infected browsers and/or web servers;
  • Internet bots Traffic not filtered/limited on large web sites with very few resources (bandwidth, etc.);
  • Internet (network) slowdowns, so that client requests are served more slowly and the number of connections increases so much that server limits are reached;
  • Web servers (computers) partial unavailability. This can happen because of required or urgent maintenance or upgrade, hardware or software failures, back-end (e.g., database) failures, etc.; in these cases the remaining web servers get too much traffic and become overloaded.

Symptoms of overload

The symptoms of an overloaded web server are:
  • Requests are served with (possibly long) delays (from 1 second to a few hundred seconds).
  • The web server returns an HTTP error code, such as 500, 502, 503, 504, 408, or even 404, which is inappropriate for an overload condition.
  • The web server refuses or resets (interrupts) TCP connections before it returns any content.
  • In very rare cases, the web server returns only a part of the requested content. This behavior can be considered a bug, even if it usually arises as a symptom of overload.

Anti-overload techniques

To partially overcome above average load limits and to prevent overload, most popular web sites use common techniques like:
  • Managing network traffic, by using:
    • Firewalls to block unwanted traffic coming from bad IP sources or having bad patterns
    • HTTP traffic managers to drop, redirect or rewrite requests having bad HTTP patterns
    • Bandwidth management and traffic shaping, in order to smooth down peaks in network usage
  • Deploying web cache techniques
  • Using different domain names to serve different (static and dynamic) content by separate web servers, i.e.:
    • http://images.example.com
    • http://www.example.com
  • Using different domain names and/or computers to separate big files from small and medium sized files; the idea is to be able to fully cache small and medium sized files and to efficiently serve big or huge (over 10 - 1000 MB) files by using different settings
  • Using many web servers (programs) per computer, each one bound to its own network card and IP address
  • Using many web servers (computers) that are grouped together behind a load balancer so that they act or are seen as one big web server
  • Adding more hardware resources (i.e. RAM, disks) to each computer
  • Tuning OS parameters for hardware capabilities and usage
  • Using more efficient computer programs for web servers, etc.
  • Using other workarounds, especially if dynamic content is involved

Market share

The LAMP (software bundle) (here additionally with Squid), composed entirely of free and open-source software, is a high performance and high-availability heavy duty solution for a hostile environment
Market share of major web servers
For more details on HTTP server programs, see Category:Web server software.
Below are the latest statistics of the market share of the top web servers on the Internet by Netcraft Survey April, May 2014.
Product Vendor April 2014 Percent May 2014 Percent Change
Apache Apache 361,853,003 37.74% 366,262,346 37.56% -0.18%
IIS Microsoft 316,843,695 33.04% 325,854,054 33.41% +0.37%
nginx NGINX, Inc. 146,204,067 15.25% 142,426,538 14.60% -0.64%
GWS Google 20,983,310 2.19% 20,685,165 2.12% -0.07%
Apache, IIS and Nginx are the most used web servers on the Internet.

See also

Diposting oleh Tidak ada komentar:

web server

The term web server, also written as Web server, can refer to either the hardware (the computer) or the software (the computer application) that helps to deliver web content that can be accessed through the Internet.[1]
The most common use of web servers is to host websites, but there are other uses such as gaming, data storage, running enterprise applications, handling email, FTP, or other web uses.

Overview

The primary function of a web server is to store, process and deliver web pages to clients. The communication between client and server takes place using the Hypertext Transfer Protocol (HTTP). Pages delivered are most frequently HTML documents, which may include images, style sheets and scripts in addition to text content.
A user agent, commonly a web browser or web crawler, initiates communication by making a request for a specific resource using HTTP and the server responds with the content of that resource or an error message if unable to do so. The resource is typically a real file on the server's secondary storage, but this is not necessarily the case and depends on how the web server is implemented.
While the primary function is to serve content, a full implementation of HTTP also includes ways of receiving content from clients. This feature is used for submitting web forms, including uploading of files.
Many generic web servers also support server-side scripting using Active Server Pages (ASP), PHP, or other scripting languages. This means that the behaviour of the web server can be scripted in separate files, while the actual server software remains unchanged. Usually, this function is used to create HTML documents dynamically ("on-the-fly") as opposed to returning static documents. The former is primarily used for retrieving and/or modifying information from databases. The latter is typically much faster and more easily cached but cannot deliver dynamic content.
Web servers are not always used for serving the World Wide Web. They can also be found embedded in devices such as printers, routers, webcams and serving only a local network. The web server may then be used as a part of a system for monitoring and/or administering the device in question. This usually means that no additional software has to be installed on the client computer, since only a web browser is required (which now is included with most operating systems).

History

The world's first web server, a NeXT Computer workstation with Ethernet, 1990, the case label reads: "This machine is a server. DO NOT POWER IT DOWN!!"
In 1989 Tim Berners-Lee proposed a new project to his employer CERN, with the goal of easing the exchange of information between scientists by using a hypertext system. The project resulted in Berners-Lee writing two programs in 1990:
Between 1991 and 1994, the simplicity and effectiveness of early technologies used to surf and exchange data through the World Wide Web helped to port them to many different operating systems and spread their use among scientific organizations and universities, and then to industry.
In 1994 Tim Berners-Lee decided to constitute the World Wide Web Consortium (W3C) to regulate the further development of the many technologies involved (HTTP, HTML, etc.) through a standardization process.

Common features

Path translation

Web servers are able to map the path component of a Uniform Resource Locator (URL) into:
  • A local file system resource (for static requests)
  • An internal or external program name (for dynamic requests)
For a static request the URL path specified by the client is relative to the web server's root directory.
Consider the following URL as it would be requested by a client:
http://www.example.com/path/file.html
The client's user agent will translate it into a connection to www.example.com with the following HTTP 1.1 request:
GET /path/file.html HTTP/1.1
Host: www.example.com
The web server on www.example.com will append the given path to the path of its root directory. On an Apache server, this is commonly /home/www (On Unix machines, usually /var/www). The result is the local file system resource:
/home/www/path/file.html
The web server then reads the file, if it exists and sends a response to the client's web browser. The response will describe the content of the file and contain the file itself or an error message will return saying that the file does not exist or is unavailable.

Kernel-mode and user-mode web servers

A web server can be either implemented into the OS kernel, or in user space (like other regular applications).
An in-kernel web server (like Microsoft IIS on Windows or TUX on GNU/Linux) will usually work faster, because, as part of the system, it can directly use all the hardware resources it needs, such as non-paged memory, CPU time-slices, network adapters, or buffers.
Web servers that run in user-mode have to ask the system for permission to use more memory or more CPU resources. Not only do these requests to the kernel take time, but they are not always satisfied because the system reserves resources for its own usage and has the responsibility to share hardware resources with all the other running applications. Executing in user mode can also mean useless buffer copies which are another handicap for user-mode web servers.

Load limits

A web server (program) has defined load limits, because it can handle only a limited number of concurrent client connections (usually between 2 and 80,000, by default between 500 and 1,000) per IP address (and TCP port) and it can serve only a certain maximum number of requests per second depending on:
  • its own settings,
  • the HTTP request type,
  • whether the content is static or dynamic,
  • whether the content is cached, and
  • the hardware and software limitations of the OS of the computer on which the web server runs.
When a web server is near to or over its limit, it becomes unresponsive.

Causes of overload

At any time web servers can be overloaded because of:
  • Too much legitimate web traffic. Thousands or even millions of clients connecting to the web site in a short interval, e.g., Slashdot effect;
  • Distributed Denial of Service attacks. A denial-of-service attack (DoS attack) or distributed denial-of-service attack (DDoS attack) is an attempt to make a computer or network resource unavailable to its intended users;
  • Computer worms that sometimes cause abnormal traffic because of millions of infected computers (not coordinated among them);
  • XSS viruses can cause high traffic because of millions of infected browsers and/or web servers;
  • Internet bots Traffic not filtered/limited on large web sites with very few resources (bandwidth, etc.);
  • Internet (network) slowdowns, so that client requests are served more slowly and the number of connections increases so much that server limits are reached;
  • Web servers (computers) partial unavailability. This can happen because of required or urgent maintenance or upgrade, hardware or software failures, back-end (e.g., database) failures, etc.; in these cases the remaining web servers get too much traffic and become overloaded.

Symptoms of overload

The symptoms of an overloaded web server are:
  • Requests are served with (possibly long) delays (from 1 second to a few hundred seconds).
  • The web server returns an HTTP error code, such as 500, 502, 503, 504, 408, or even 404, which is inappropriate for an overload condition.
  • The web server refuses or resets (interrupts) TCP connections before it returns any content.
  • In very rare cases, the web server returns only a part of the requested content. This behavior can be considered a bug, even if it usually arises as a symptom of overload.

Anti-overload techniques

To partially overcome above average load limits and to prevent overload, most popular web sites use common techniques like:
  • Managing network traffic, by using:
    • Firewalls to block unwanted traffic coming from bad IP sources or having bad patterns
    • HTTP traffic managers to drop, redirect or rewrite requests having bad HTTP patterns
    • Bandwidth management and traffic shaping, in order to smooth down peaks in network usage
  • Deploying web cache techniques
  • Using different domain names to serve different (static and dynamic) content by separate web servers, i.e.:
    • http://images.example.com
    • http://www.example.com
  • Using different domain names and/or computers to separate big files from small and medium sized files; the idea is to be able to fully cache small and medium sized files and to efficiently serve big or huge (over 10 - 1000 MB) files by using different settings
  • Using many web servers (programs) per computer, each one bound to its own network card and IP address
  • Using many web servers (computers) that are grouped together behind a load balancer so that they act or are seen as one big web server
  • Adding more hardware resources (i.e. RAM, disks) to each computer
  • Tuning OS parameters for hardware capabilities and usage
  • Using more efficient computer programs for web servers, etc.
  • Using other workarounds, especially if dynamic content is involved

Market share

The LAMP (software bundle) (here additionally with Squid), composed entirely of free and open-source software, is a high performance and high-availability heavy duty solution for a hostile environment
Market share of major web servers
For more details on HTTP server programs, see Category:Web server software.
Below are the latest statistics of the market share of the top web servers on the Internet by Netcraft Survey April, May 2014.
Product Vendor April 2014 Percent May 2014 Percent Change
Apache Apache 361,853,003 37.74% 366,262,346 37.56% -0.18%
IIS Microsoft 316,843,695 33.04% 325,854,054 33.41% +0.37%
nginx NGINX, Inc. 146,204,067 15.25% 142,426,538 14.60% -0.64%
GWS Google 20,983,310 2.19% 20,685,165 2.12% -0.07%
Apache, IIS and Nginx are the most used web servers on the Internet.

See also

Diposting oleh Tidak ada komentar:

FTP

FTP" redirects here. For other uses, see FTP (disambiguation).
The File Transfer Protocol (FTP) is a standard network protocol used to transfer computer files from one host to another host over a TCP-based network, such as the Internet.
FTP is built on a client-server architecture and uses separate control and data connections between the client and the server.[1] FTP users may authenticate themselves using a clear-text sign-in protocol, normally in the form of a username and password, but can connect anonymously if the server is configured to allow it. For secure transmission that protects the username and password, and encrypts the content, FTP is often secured with SSL/TLS (FTPS). SSH File Transfer Protocol (SFTP) is sometimes also used instead, but is technologically different.
The first FTP client applications were command-line applications developed before operating systems had graphical user interfaces, and are still shipped with most Windows, Unix, and Linux operating systems.[2][3] Many FTP clients and automation utilities have since been developed for desktops, servers, mobile devices, and hardware, and FTP has been incorporated into productivity applications, such as Web page editors.

History of FTP server

The original specification for the File Transfer Protocol was written by Abhay Bhushan and published as RFC 114 on 16 April 1971. Until 1980, FTP ran on NCP, the predecessor of TCP/IP.[2] The protocol was later replaced by a TCP/IP version, RFC 765 (June 1980) and RFC 959 (October 1985), the current specification. Several proposed standards amend RFC 959, for example RFC 2228 (June 1997) proposes security extensions and RFC 2428 (September 1998) adds support for IPv6 and defines a new type of passive mode.[4]

Protocol overview

Communication and data transfer

Illustration of starting a passive connection using port 21
FTP may run in active or passive mode, which determines how the data connection is established.[5] In both cases, the client creates a TCP control connection from a random unprivileged port N to the FTP server command port 21. In active modes, the client starts listening for incoming data connections on port N+1 from the server (the client sends the FTP command PORT N+1 to inform the server on which port it is listening). In situations where the client is behind a firewall and unable to accept incoming TCP connections, passive mode may be used. In this mode, the client uses the control connection to send a PASV command to the server and then receives a server IP address and server port number from the server,[5][6] which the client then uses to open a data connection from an arbitrary client port to the server IP address and server port number received.[7] Both modes were updated in September 1998 to support IPv6. Further changes were introduced to the passive mode at that time, updating it to extended passive mode.[8]
The server responds over the control connection with three-digit status codes in ASCII with an optional text message. For example "200" (or "200 OK") means that the last command was successful. The numbers represent the code for the response and the optional text represents a human-readable explanation or request (e.g. <Need account for storing file>).[1] An ongoing transfer of file data over the data connection can be aborted using an interrupt message sent over the control connection.
While transferring data over the network, four data representations can be used:[2][3][4]
  • ASCII mode: used for text. Data is converted, if needed, from the sending host's character representation to "8-bit ASCII" before transmission, and (again, if necessary) to the receiving host's character representation. As a consequence, this mode is inappropriate for files that contain data other than plain text.
  • Image mode (commonly called Binary mode): the sending machine sends each file byte for byte, and the recipient stores the bytestream as it receives it. (Image mode support has been recommended for all implementations of FTP).
  • EBCDIC mode: use for plain text between hosts using the EBCDIC character set.
  • Local mode: Allows two computers with identical setups to send data in a proprietary format without the need to convert it to ASCII
For text files, different format control and record structure options are provided. These features were designed to facilitate files containing Telnet or ASA
Data transfer can be done in any of three modes:[1][2]
  • Stream mode: Data is sent as a continuous stream, relieving FTP from doing any processing. Rather, all processing is left up to TCP. No End-of-file indicator is needed, unless the data is divided into records.
  • Block mode: FTP breaks the data into several blocks (block header, byte count, and data field) and then passes it on to TCP.[4]
  • Compressed mode: Data is compressed using a single algorithm (usually run-length encoding).

Login

FTP login utilizes a normal username and password scheme for granting access.[2] The username is sent to the server using the USER command, and the password is sent using the PASS command.[2] If the information provided by the client is accepted by the server, the server will send a greeting to the client and the session will commence.[2] If the server supports it, users may log in without providing login credentials, but the same server may authorize only limited access for such sessions.[2]

Anonymous FTP

A host that provides an FTP service may provide anonymous FTP access.[2] Users typically log into the service with an 'anonymous' (lower-case and case-sensitive in some FTP servers) account when prompted for user name. Although users are commonly asked to send their email address instead of a password,[3] no verification is actually performed on the supplied data.[9] Many FTP hosts whose purpose is to provide software updates will allow anonymous logins.[3]

NAT and firewall traversal

FTP normally transfers data by having the server connect back to the client, after the PORT command is sent by the client. This is problematic for both NATs and firewalls, which do not allow connections from the Internet towards internal hosts.[10] For NATs, an additional complication is that the representation of the IP addresses and port number in the PORT command refer to the internal host's IP address and port, rather than the public IP address and port of the NAT.
There are two approaches to this problem. One is that the FTP client and FTP server use the PASV command, which causes the data connection to be established from the FTP client to the server.[10] This is widely used by modern FTP clients. Another approach is for the NAT to alter the values of the PORT command, using an application-level gateway for this purpose.[10]

Differences from HTTP

HTTP essentially fixes the bugs in FTP that made it inconvenient to use for many small ephemeral transfers as are typical in web pages.
FTP has a stateful control connection which maintains a current working directory and other flags, and each transfer requires a secondary connection through which the data is transferred. In "passive" mode this secondary connection is from client to server, whereas in the default "active" mode this connection is from server to client. This apparent role reversal when in active mode, and random port numbers for all transfers, is why firewalls and NAT gateways have such a hard time with FTP. HTTP is stateless and multiplexes control and data over a single connection from client to server on well-known port numbers, which trivially passes through NAT gateways and is simple for firewalls to manage.
Setting up an FTP control connection is quite slow due to the round-trip delays of sending all of the required commands and awaiting responses, so it is customary to bring up a control connection and hold it open for multiple file transfers rather than drop and re-establish the session afresh each time. In contrast, HTTP originally dropped the connection after each transfer because doing so was so cheap. While HTTP has subsequently gained the ability to reuse the TCP connection for multiple transfers, the conceptual model is still of independent requests rather than a session.
When FTP is transferring over the data connection, the control connection is idle. If the transfer takes long enough, the firewall or NAT may decide that the control connection is dead and stop tracking it, effectively breaking the connection and confusing the download. The single HTTP connection is only idle between requests and it is normal and expected for such connections to be dropped after a time-out.

Web browser support

Most common web browsers can retrieve files hosted on FTP servers, although they may not support protocol extensions such as FTPS.[3][11] When an FTP—rather than an HTTP—URL is supplied, the accessible contents on the remote server are presented in a manner that is similar to that used for other Web content. A full-featured FTP client can be run within Firefox in the form of an extension called FireFTP.

Syntax

FTP URL syntax is described in RFC1738,[12] taking the form: ftp://[<user>[:<password>]@]<host>[:<port>]/<url-path>[12] The bracketed parts are optional.
For example, the URL ftp://public.ftp-servers.example.com/mydirectory/myfile.txt represents the file myfile.txt from the directory mydirectory on the server public.ftp-servers.example.com as an FTP resource. The URL ftp://user001:secretpassword@private.ftp-servers.example.com/mydirectory/myfile.txt adds a specification of the username and password that must be used to access this resource.
More details on specifying a username and password may be found in the browsers' documentation, such as, for example, Firefox[13] and Internet Explorer.[14] By default, most web browsers use passive (PASV) mode, which more easily traverses end-user firewalls.

Security

FTP was not designed to be a secure protocol, and has many security weaknesses.[15] In May 1999, the authors of RFC 2577 listed a vulnerability to the following problems:[16]
FTP does not encrypt its traffic; all transmissions are in clear text, and usernames, passwords, commands and data can be read by anyone able to perform packet capture (sniffing) on the network.[2][15] This problem is common to many of the Internet Protocol specifications (such as SMTP, Telnet, POP and IMAP) that were designed prior to the creation of encryption mechanisms such as TLS or SSL.[4] A common solution to this problem is to use the "secure", TLS-protected versions of the insecure protocols (e.g. FTPS for FTP, TelnetS for Telnet, etc.) or a different, more secure protocol that can handle the job, such as the SFTP/SCP tools included with most implementations of the Secure Shell protocol.

Secure FTP

Securing FTP transfers may be accomplished by several methods.

FTPS

Explicit FTPS is an extension to the FTP standard that allows clients to request that the FTP session be encrypted. This is done by sending the "AUTH TLS" command. The server has the option of allowing or denying connections that do not request TLS. This protocol extension is defined in the proposed standard: RFC 4217. Implicit FTPS is a deprecated standard for FTP that required the use of a SSL or TLS connection. It was specified to use different ports than plain FTP.

SFTP

The SSH file transfer protocol or secure FTP (SFTP), also transfers files and has a similar command set for users, but is built on different software technology. SFTP uses the Secure Shell protocol (SSH) to transfer files. Unlike FTP, it encrypts both commands and data, preventing passwords and sensitive information from being transmitted openly over the network. It cannot interoperate with FTP software.

FTP over SSH (not SFTP)

FTP over SSH is the practice of tunneling a normal FTP session over a Secure Shell connection.[15] Because FTP uses multiple TCP connections (unusual for a TCP/IP protocol that is still in use), it is particularly difficult to tunnel over SSH. With many SSH clients, attempting to set up a tunnel for the control channel (the initial client-to-server connection on port 21) will protect only that channel; when data is transferred, the FTP software at either end sets up new TCP connections (data channels) and thus have no confidentiality or integrity protection.
Otherwise, it is necessary for the SSH client software to have specific knowledge of the FTP protocol, to monitor and rewrite FTP control channel messages and autonomously open new packet forwardings for FTP data channels. Software packages that support this mode include:
Other methods of transferring files using SSH that are not related to FTP include SFTP and SCP; in each of these, the entire conversation (credentials and data) is always protected by the SSH protocol.

FTP commands

Main article: List of FTP commands

FTP reply codes

Below is a summary of FTP reply codes that may be returned by an FTP server. These codes have been standardized in RFC 959 by the IETF. The reply code is a three-digit value. The first digit is used to indicate one of three possible outcomes—success, failure or to indicate an error or incomplete reply:
  • 2yz – Success reply
  • 4yz or 5yz – Failure Reply
  • 1yz or 3yz – Error or Incomplete reply
The second digit defines the kind of error:
  • x0z – Syntax. These replies refer to syntax errors.
  • x1z – Information. Replies to requests for information.
  • x2z – Connections. Replies referring to the control and data connections.
  • x3z – Authentication and accounting. Replies for the login process and accounting procedures.
  • x4z – Not defined.
  • x5z – File system. These replies relay status codes from the server file system.
The third digit of the reply code is used to provide additional detail for each of the categories defined by the second digit.
Diposting oleh Tidak ada komentar:

Dynamic Host Configuration Protocol (DHCP)

"DHCP" redirects here. For other uses, see DHCP (disambiguation).
Internet protocol suite
Application layer
Transport layer
Internet layer
Link layer
The Dynamic Host Configuration Protocol (DHCP) is a standardized networking protocol used on Internet Protocol (IP) networks for dynamically distributing network configuration parameters, such as IP addresses for interfaces and services. With DHCP, computers request IP addresses and networking parameters automatically from a DHCP server, reducing the need for a network administrator or a user to configure these settings manually.

Overview

Dynamic Host Configuration Protocol is used by computers for requesting Internet Protocol parameters, such as an IP address from a network server. The protocol operates based on the client-server model. DHCP is very common in all modern networks[1] ranging in size from home networks to large campus networks and regional Internet service provider networks. Most residential network routers receive a globally unique IP address within the provider network. Within a local network, DHCP assigns a local IP address to devices connected to the local network.
When a computer or other networked device connects to a network, its DHCP client software in the operating system sends a broadcast query requesting necessary information. Any DHCP server on the network may service the request. The DHCP server manages a pool of IP addresses and information about client configuration parameters such as default gateway, domain name, the name servers, and time servers. On receiving a request, the server may respond with specific information for each client, as previously configured by an administrator, or with a specific address and any other information valid for the entire network, and the time period for which the allocation (lease) is valid. A host typically queries for this information immediately after booting, and periodically thereafter before the expiration of the information. When an assignment is refreshed by the client computer, it initially requests the same parameter values, but may be assigned a new address from the server, based on the assignment policies set by administrators.
On large networks that consist of multiple links, a single DHCP server may service the entire network when aided by DHCP relay agents located on the interconnecting routers. Such agents relay messages between DHCP clients and DHCP servers located on different subnets.
Depending on implementation, the DHCP server may have three methods of allocating IP-addresses:
  • dynamic allocation: A network administrator reserves a range of IP addresses for DHCP, and each client computer on the LAN is configured to request an IP address from the DHCP server during network initialization. The request-and-grant process uses a lease concept with a controllable time period, allowing the DHCP server to reclaim (and then reallocate) IP addresses that are not renewed.
  • automatic allocation: The DHCP server permanently assigns an IP address to a requesting client from the range defined by the administrator. This is like dynamic allocation, but the DHCP server keeps a table of past IP address assignments, so that it can preferentially assign to a client the same IP address that the client previously had.
  • static allocation: The DHCP server allocates an IP address based on a preconfigured mapping to each client's MAC address. This feature is variously called static DHCP assignment by DD-WRT, fixed-address by the dhcpd documentation, address reservation by Netgear, DHCP reservation or static DHCP by Cisco and Linksys, and IP address reservation or MAC/IP address binding by various other router manufacturers.
DHCP is used for Internet Protocol version 4 (IPv4), as well as IPv6. While both versions serve the same purpose, the details of the protocol for IPv4 and IPv6 are sufficiently different that they may be considered separate protocols.[2] For IPv6 operation, devices may alternatively use stateless address autoconfiguration. IPv4 hosts may also use link-local addressing to achieve operation restricted to the local network link.

History

DHCP was first defined as a standards track protocol in RFC 1531 in October 1993, as an extension to the Bootstrap Protocol (BOOTP). The motivation for extending BOOTP was that BOOTP required manual intervention to add configuration information for each client, and did not provide a mechanism for reclaiming unused IP addresses.
DHCP development culminated in RFC 2131 in 1997, and remains as of 2014 the standard for IPv4 networks. DHCPv6 is documented in RFC 3315. RFC 3633 added a DHCPv6 mechanism for prefix delegation. DHCPv6 was further extended to provide configuration information to clients configured using stateless address autoconfiguration in RFC 3736.
The BOOTP protocol itself was first defined in RFC 951 as a replacement for the Reverse Address Resolution Protocol RARP. The primary motivation for replacing RARP with BOOTP was that RARP was a data link layer protocol. This made implementation difficult on many server platforms, and required that a server be present on each individual network link. BOOTP introduced the innovation of a relay agent, which allowed the forwarding of BOOTP packets off the local network using standard IP routing, thus one central BOOTP server could serve hosts on many IP subnets.[3]
The Dynamic Host Configuration Protocol was created for the express purpose of addressing the shortcomings in RARP and BOOTP. DHCP is based on BOOTP to great extent, but instead of simply supplying predetermined configuration parameters to network clients, DHCP can dynamically allocate IP addresses from a pool and reclaim them when they are no longer in use. This prevents workstations from being assigned multiple IP addresses. In contrast to BOOTP, DHCP can deliver a wide range of configuration parameters to IP clients, including platform-specific parameters extending the core set of parameters.[4]

Operation

Diagram of a typical DHCP session
The DHCP protocol employs a connectionless service model, using the User Datagram Protocol (UDP). It is implemented with two UDP port numbers for its operations which are the same as for the BOOTP protocol. UDP port number 67 is the destination port of a server, and UDP port number 68 is used by the client.
DHCP operations fall into four phases: server discovery, IP lease offer, IP request, and IP lease acknowledgment. These stages are often abbreviated as DORA for discovery, offer, request, and acknowledgment.
The DHCP protocol operation begins with clients broadcasting a request. If the client and server are on different subnets, a DHCP Helper or DHCP Relay Agent may be used. Clients requesting renewal of an existing lease may communicate directly via UDP unicast, since the client already has an established IP address at that point.

DHCP discovery

The client broadcasts messages on the network subnet using the destination address 255.255.255.255 or the specific subnet broadcast address. A DHCP client may also request its last-known IP address. If the client remains connected to the same network, the server may grant the request. Otherwise, it depends whether the server is set up as authoritative or not. An authoritative server denies the request, causing the client to issue a new request. A non-authoritative server simply ignores the request, leading to an implementation-dependent timeout for the client to expire the request and ask for a new IP address.
DHCPDISCOVER message
UDP Src=0.0.0.0 sPort=68
Dest=255.255.255.255 dPort=67
OP HTYPE HLEN HOPS
0x01 0x01 0x06 0x00
XID
0x3903F326
SECS FLAGS
0x0000 0x0000
CIADDR (Client IP address)
0x00000000
YIADDR (Your IP address)
0x00000000
SIADDR (Server IP address)
0x00000000
GIADDR (Gateway IP address)
0x00000000
CHADDR (Client hardware address)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 octets of 0s, or overflow space for additional options. BOOTP legacy
Magic cookie
0x63825363
DHCP Options
DHCP option 53: DHCP Discover
DHCP option 50: 192.168.1.100 requested
DHCP option 55: Parameter Request List: Request Subnet Mask (1), Router (3), Domain Name (15), Domain Name Server (6)

DHCP offer

When a DHCP server receives a DHCPDISCOVER message from a client, which is an IP address lease request, the server reserves an IP address for the client and makes a lease offer by sending a DHCPOFFER message to the client. This message contains the client's MAC address, 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 (client hardware address) field. Here the server, 192.168.1.1, specifies the client's IP address in the YIADDR (your IP address) field.
DHCPOFFER message
UDP Src=192.168.1.1 sPort=67
Dest=255.255.255.255 | dPort=68
OP HTYPE HLEN HOPS
0x02 0x01 0x06 0x00
XID
0x3903F326
SECS FLAGS
0x0000 0x0000
CIADDR (Client IP address)
0x00000000
YIADDR (Your IP address)
0xC0A80164
SIADDR (Server IP address)
0xC0A80101
GIADDR (Gateway IP address)
0x00000000
CHADDR (Client hardware address)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 octets of 0s. BOOTP legacy
Magic cookie
0x63825363
DHCP Options
DHCP option 53: DHCP Offer
DHCP option 1: 255.255.255.0 subnet mask
DHCP option 3: 192.168.1.1 router
DHCP option 51: 86400s (1 day) IP address lease time
DHCP option 54: 192.168.1.1 DHCP server
DHCP option 6: DNS servers 9.7.10.15, 9.7.10.16, 9.7.10.18

DHCP request

In response to the DHCP offer, the client replies with a DHCP request, broadcast to the server, requesting the offered address. A client can receive DHCP offers from multiple servers, but it will accept only one DHCP offer. Based on required server identification option in the request and broadcast messaging, servers are informed whose offer the client has accepted.[5]:Section 3.1, Item 3 When other DHCP servers receive this message, they withdraw any offers that they might have made to the client and return the offered address to the pool of available addresses.
DHCPREQUEST message
UDP Src=0.0.0.0 sPort=68
Dest=255.255.255.255 dPort=67
OP HTYPE HLEN HOPS
0x01 0x01 0x06 0x00
XID
0x3903F326
SECS FLAGS
0x0000 0x0000
CIADDR (Client IP address)
0x00000000
YIADDR (Your IP address)
0x00000000
SIADDR (Server IP address)
0xC0A80101
GIADDR (Gateway IP address)
0x00000000
CHADDR (Client hardware address)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 octets of 0s. BOOTP legacy
Magic cookie
0x63825363
DHCP Options
DHCP option 53: DHCP Request
DHCP option 50: 192.168.1.100 requested
DHCP option 54: 192.168.1.1 DHCP server.

DHCP acknowledgement

When the DHCP server receives the DHCPREQUEST message from the client, the configuration process enters its final phase. The 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 IP configuration process is completed.
The protocol expects the DHCP client to configure its network interface with the negotiated parameters.
After the client obtains an IP address, the client may use the Address Resolution Protocol (ARP) to prevent address conflicts caused by overlapping address pools of DHCP servers.
DHCPACK message
UDP Src=192.168.1.1 sPort=67
Dest=255.255.255.255 dPort=68
OP HTYPE HLEN HOPS
0x02 0x01 0x06 0x00
XID
0x3903F326
SECS FLAGS
0x0000 0x0000
CIADDR (Client IP address)
0x00000000
YIADDR (Your IP address)
0xC0A80164
SIADDR (Server IP address)
0xC0A80101
GIADDR (Gateway IP address switched by relay)
0x00000000
CHADDR (Client hardware address)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 octets of 0s. BOOTP legacy
Magic cookie
0x63825363
DHCP Options
DHCP option 53: DHCP ACK
DHCP option 1: 255.255.255.0 subnet mask
DHCP option 3: 192.168.1.1 router
DHCP option 51: 86400s (1 day) IP address lease time
DHCP option 54: 192.168.1.1 DHCP server
DHCP option 6: DNS servers 9.7.10.15, 9.7.10.16, 9.7.10.18

DHCP information

A DHCP client may request more information than the server sent with the original DHCPOFFER. The client may also request repeat data for a particular application. For example, browsers use DHCP Inform to obtain web proxy settings via WPAD.

DHCP releasing

The client sends a request to the DHCP server to release the DHCP information and the client deactivates its IP address. As client devices usually do not know when users may unplug them from the network, the protocol does not mandate the sending of DHCP Release.

Client configuration parameters

A DHCP server can provide optional configuration parameters to the client. RFC 2132 describes the available DHCP options defined by Internet Assigned Numbers Authority (IANA) - DHCP and BOOTP PARAMETERS.[6]
A DHCP client can select, manipulate and overwrite parameters provided by a DHCP server.[7]

DHCP options

Options are variable length octet strings. The first octet is the option code, the second octet is the number of following octets and the remaining octets are code dependent. For example, the DHCP Message type option for an Offer would appear as 0x35,0x01,0x02, where 0x35 is code 53 for "DHCP Message Type", 0x01 means one octet follows and 0x02 is the value of "Offer".
The following tables list the available DHCP options, as stated in RFC2132.[8]
RFC1497 vendor extensions[8]:Section 3
Code Name Length Notes
0 Pad[8]:Section 3.1 0 octets Can be used to pad other options so that they are aligned to the word boundary; is not followed by length byte
1 Subnet Mask[8]:Section 3.3 4 octets Must be sent after the router option (option 3) if both are included
2 Time Offset[8]:Section 3.4 4 octets
3 Router multiples of 4 octets Available routers, should be listed in order of preference
4 Time Server multiples of 4 octets Available time servers to synchronise with, should be listed in order of preference
5 Name Server multiples of 4 octets Available IEN116 name servers, should be listed in order of preference
6 Domain Name Server multiples of 4 octets Available DNS servers, should be listed in order of preference
7 Log Server multiples of 4 octets Available log servers, should be listed in order of preference.
8 Cookie Server multiples of 4 octets
9 LPR Server multiples of 4 octets
10 Impress Server multiples of 4 octets
11 Resource Location Server multiples of 4 octets
12 Host Name minimum of 1 octet
13 Boot File Size 2 octets Length of the boot image in 4KiB blocks
14 Merit Dump File minimum of 1 octet Path where crash dumps should be stored
15 Domain Name minimum of 1 octet
16 Swap Server 4 octets
17 Root Path minimum of 1 octet
18 Extensions Path minimum of 1 octet
255 End 0 octets Used to mark the end of the vendor option field
IP Layer Parameters per Host[8]:Section 4
Code Name Length Notes
19 IP Forwarding Enable/Disable 1 octet
20 Non-Local Source Routing Enable/Disable 1 octet
21 Policy Filter multiples of 8 octets
22 Maximum Datagram Reassembly Size 2 octets
23 Default IP Time-to-live 1 octet
24 Path MTU Aging Timeout 4 octets
25 Path MTU Plateau Table multiples of 2 octets
IP Layer Parameters per Interface[8]:Section 5
Code Name Length Notes
26 Interface MTU 2 octets
27 All Subnets are Local 1 octet
28 Broadcast Address 4 octets
29 Perform Mask Discovery 1 octet
30 Mask Supplier 1 octet
31 Perform Router Discovery 1 octet
32 Router Solicitation Address 4 octets
33 Static Route multiples of 8 octets A list of destination/router pairs
Link Layer Parameters per Interface[8]:Section 6
Code Name Length Notes
34 Trailer Encapsulation Option 1 octet
35 ARP Cache Timeout 4 octets
36 Ethernet Encapsulation 1 octet
TCP Parameters[8]:Section 7
Code Name Length Notes
37 TCP Default TTL 1 octet
38 TCP Keepalive Interval 4 octets
39 TCP Keepalive Garbage 1 octet
Application and Service Parameters[8]:Section 8
Code Name Length Notes
40 Network Information Service Domain minimum of 1 octet
41 Network Information Servers multiples of 4 octets
42 Network Time Protocol Servers multiples of 4 octets
43 Vendor Specific Information minimum of 1 octets
44 NetBIOS over TCP/IP Name Server multiples of 4 octets
45 NetBIOS over TCP/IP Datagram Distribution Server multiples of 4 octets
46 NetBIOS over TCP/IP Node Type 1 octet
47 NetBIOS over TCP/IP Scope minimum of 1 octet
48 X Window System Font Server multiples of 4 octets
49 X Window System Display Manager multiples of 4 octets
64 Network Information Service+ Domain minimum of 1 octet
65 Network Information Service+ Servers multiples of 4 octets
68 Mobile IP Home Agent multiples of 4 octets
69 Simple Mail Transport Protocol (SMTP) Server multiples of 4 octets
70 Post Office Protocol (POP3) Server multiples of 4 octets
71 Network News Transport Protocol (NNTP) Server multiples of 4 octets
72 Default World Wide Web (WWW) Server) multiples of 4 octets
73 Default Finger Server multiples of 4 octets
74 Default Internet Relay Chat (IRC) Server multiples of 4 octets
75 StreetTalk Server multiples of 4 octets
76 StreetTalk Directory Assistance (STDA) Server multiples of 4 octets
DHCP Extensions[8]:Section 9
Code Name Length Notes
50 Requested IP address 4 octets
51 IP address Lease Time 4 octets
52 Option Overload 1 octet
53 DHCP Message Type 1 octet
54 Server Identifier 4 octets
55 Parameter Request List minimum of 1 octet
56 Message minimum of 1 octet
57 Maximum DHCP Message Size 2 octets
58 Renewal (T1) Time Value 4 octets
59 Rebinding (T2) Time Value 4 octets
60 Vendor class identifier minimum of 1 octet
61 Client-identifier minimum of 2 octets
66 TFTP server name minimum of 1 octet
67 Bootfile name minimum of 1 octet

Vendor identification

An option exists to identify the vendor and functionality of a DHCP client. The information is a variable-length string of characters or octets which has a meaning specified by the vendor of the DHCP client. One method that a DHCP client can utilize to communicate to the server that it is using a certain type of hardware or firmware is to set a value in its DHCP requests called the Vendor Class Identifier (VCI) (Option 60).
This method allows a DHCP server to differentiate between the two kinds of client machines and process the requests from the two types of modems appropriately. Some types of set-top boxes also set the VCI (Option 60) to inform the DHCP server about the hardware type and functionality of the device. The value this option is set to gives the DHCP server a hint about any required extra information that this client needs in a DHCP response.

DHCP relaying

In small networks, where only one IP subnet is being managed, DHCP clients communicate directly with DHCP servers. However, DHCP servers can also provide IP addresses for multiple subnets. In this case, a DHCP client that has not yet acquired an IP address cannot communicate directly with the DHCP server using IP routing, because it does not have a routable IP address, nor does it know the IP address of a router.
In order to allow DHCP clients on subnets not directly served by DHCP servers to communicate with DHCP servers, DHCP relay agents can be installed on these subnets. The DHCP client broadcasts on the local link; the relay agent receives the broadcast and transmits it to one or more DHCP servers using unicast. The relay agent stores its own IP address in the GIADDR field of the DHCP packet. The DHCP server uses the GIADDR to determine the subnet on which the relay agent received the broadcast, and allocates an IP address on that subnet. When the DHCP server replies to the client, it sends the reply to the GIADDR address, again using unicast. The relay agent then retransmits the response on the local network.

Reliability

The DHCP protocol provides reliability in several ways: periodic renewal, rebinding,[5]:Section 4.4.5 and failover. DHCP clients are allocated leases that last for some period of time. Clients begin to attempt to renew their leases once half the lease interval has expired.[5]:Section 4.4.5 Paragraph 3 They do this by sending a unicast DHCPREQUEST message to the DHCP server that granted the original lease. If that server is down or unreachable, it will fail to respond to the DHCPREQUEST. However, the DHCPREQUEST will be repeated by the client from time to time,[5]:Section 4.4.5 Paragraph 8[a] so when the DHCP server comes back up or becomes reachable again, the DHCP client will succeed in contacting it, and renew its lease.
If the DHCP server is unreachable for an extended period of time,[5]:Section 4.4.5 Paragraph 5 the DHCP client will attempt to rebind, by broadcasting its DHCPREQUEST rather than unicasting it. Because it is broadcast, the DHCPREQUEST message will reach all available DHCP servers. If some other DHCP server is able to renew the lease, it will do so at this time.
In order for rebinding to work, when the client successfully contacts a backup DHCP server, that server must have accurate information about the client's binding. Maintaining accurate binding information between two servers is a complicated problem; if both servers are able to update the same lease database, there must be a mechanism to avoid conflicts between updates on the independent servers. A proposal for implementing fault-tolerant DHCP servers was submitted to the Internet Engineering Task Force, but never formalized[9][b]
If rebinding fails, the lease will eventually expire. When the lease expires, the client must stop using the IP address granted to it in its lease.[5]:Section 4.4.5 Paragraph 9 At that time, it will restart the DHCP process from the beginning by broadcasting a DHCPDISCOVER message. Since its lease has expired, it will accept any IP address offered to it. Once it has a new IP address, presumably from a different DHCP server, it will once again be able to use the network. However, since its IP address has changed, any ongoing connections will be broken.

Security

See also: DHCP snooping
The base DHCP protocol does not include any mechanism for authentication.[10] Because of this, it is vulnerable to a variety of attacks. These attacks fall into three main categories:
  • Unauthorized DHCP servers providing false information to clients.[11]
  • Unauthorized clients gaining access to resources.[11]
  • Resource exhaustion attacks from malicious DHCP clients.[11]
Because the client has no way to validate the identity of a DHCP server, unauthorized DHCP servers (commonly called "rogue DHCP") can be operated on networks, providing incorrect information to DHCP clients.[12] This can serve either as a denial-of-service attack, preventing the client from gaining access to network connectivity,[13] or as a man-in-the-middle attack.[14] Because the DHCP server provides the DHCP client with server IP addresses, such as the IP address of one or more DNS servers,[11] an attacker can convince a DHCP client to do its DNS lookups through its own DNS server, and can therefore provide its own answers to DNS queries from the client.[15] This in turn allows the attacker to redirect network traffic through itself, allowing it to eavesdrop on connections between the client and network servers it contacts, or to simply replace those network servers with its own.[15]
Because the DHCP server has no secure mechanism for authenticating the client, clients can gain unauthorized access to IP addresses by presenting credentials, such as client identifiers, that belong to other DHCP clients.[12] This also allows DHCP clients to exhaust the DHCP server's store of IP addresses—by presenting new credentials each time it asks for an address, the client can consume all the available IP addresses on a particular network link, preventing other DHCP clients from getting service.[12]
DHCP does provide some mechanisms for mitigating these problems. The Relay Agent Information Option protocol extension (RFC 3046, usually referred to in the industry by its actual number as Option 82[16][17]) allows network operators to attach tags to DHCP messages as these messages arrive on the network operator's trusted network. This tag is then used as an authorization token to control the client's access to network resources. Because the client has no access to the network upstream of the relay agent, the lack of authentication does not prevent the DHCP server operator from relying on the authorization token.[10]
Another extension, Authentication for DHCP Messages (RFC 3118), provides a mechanism for authenticating DHCP messages. Unfortunately RFC 3118 has not seen (as of 2002) widespread adoption because of the problems of managing keys for large numbers of DHCP clients.[18] A 2007 book about DSL technologies remarked that "there were numerous security vulnerabilities identified against the security measures proposed by RFC 3118. This fact, combined with the introduction of 802.1x, slowed the deployment and take-rate of authenticated DHCP, and it has never been widely deployed."[19] A 2010 book notes that "[t]here have been very few implementations of DHCP Authentication. The challenges of key management and processing delays due to hash computation have been deemed too heavy a price to pay for the perceived benefits."[20]
More recent (2008) architectural proposals involve authenticating DHCP requests using 802.1x or PANA (both of which transport EAP).[21] An IETF proposal was made for including EAP in DHCP itself, the so-called EAPoDHCP;[22] this does not appear to have progressed beyond IETF draft level, the last of which dates to 2010.[23]

IETF standards documents

  • RFC 2131, Dynamic Host Configuration Protocol
  • RFC 2132, DHCP Options and BOOTP Vendor Extensions
  • RFC 3046, DHCP Relay Agent Information Option
  • RFC 3942, Reclassifying Dynamic Host Configuration Protocol Version Four (DHCPv4) Options
  • RFC 4242, Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6
  • RFC 4361, Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)
  • RFC 4436, Detecting Network Attachment in IPv4 (DNAv4)

See also

Portal icon Computer networking portal

Notes

  1. The RFC calls for the client to wait one half of the remaining time until T2 before it retransmits the DHCPREQUEST packet
  2. The proposal provided a mechanism whereby two servers could remain loosely in sync with each other in such a way that even in the event of a total failure of one server, the other server could recover the lease database and continue operating. Due to the length and complexity of the specification, it was never published as a standard; however, the techniques described in the specification are in wide use, with one open source implementation in the ISC DHCP server as well as several commercial implementations.
Diposting oleh Tidak ada komentar:
Langganan: Komentar (Atom)