.jpg)
DHCP stands for "Dynamic Host Configuration Protocol".
Dynamic Host Configuration Protocol (DHCP) is a protocol used by networked devices (clients) to obtain various parameters necessary for the clients to operate in an Internet Protocol (IP) network. By using this protocol, system administration workload greatly decreases, and devices can be added to the network with minimal or no manual configurations.
DHCP's purpose is to enable individual computers on an IP network to extract their configurations from a server (the 'DHCP server') or servers, in particular, servers that have no exact information about the individual computers until they request the information. The overall purpose of this is to reduce the work necessary to administer a large IP network. The most significant piece of information distributed in this manner is the IP address.
No, it is too tied to IP. Furthermore, they don't need it since they have always had automated mechanisms for assigning their own network addresses.
DHCP was created by the Dynamic Host Configuration Working Group of the Internet Engineering Task Force (IETF; a volunteer organization which defines protocols for use on the Internet). As such, it's definition is recorded in an Internet RFC and the Internet Activities Board (IAB) is asserting its status as to Internet Standardization. As of this writing (June 1998), DHCP is an Internet Draft Standard Protocol and is Elective. BOOTP is an Internet Draft Standard Protocol and is Recommended. For more information on Internet standardization, see RFC2300 (May 1998)
DHCP is based on BOOTP and maintains some backward compatibility. The main difference is that BOOTP was designed for manual pre-configuration of the host information in a server database, while DHCP allows for dynamic allocation of network addresses and configurations to newly attached hosts. Additionally, DHCP allows for recovery and reallocation of network addresses through a leasing mechanism.
RARP is a protocol used by Sun and other vendors that allows a computer to find out its own IP number, which is one of the protocol parameters typically passed to the client system by DHCP or BOOTP. RARP doesn't support other parameters and using it, a server can only serve a single LAN. DHCP and BOOTP are designed so they can be routed.
DHCP and VLANs, which are very different in concept, are sometimes cited as different solutions to the same problem. While they have a goal in common (easing moves of networked computers), VLANs represent a more revolutionary change to a LAN than DHCP. A DHCP server and forwarding agents can allow you to set things up so that you can unplug a client computer from one network or subnet and plug it into another and have it come alive immediately, it having been reconfigured automatically. In conjunction to Dynamic DNS, it could automatically be given its same name in its new place. VLAN-capable LAN equipment with dynamic VLAN assignment allows you to configure things so a client computer can be plugged into any port and have the same IP number (as well as name) and be on the same subnet. The VLAN-capable network either has its own configuration that lists which MAC addresses are to belong to each VLAN, or it makes the determination from the source IP address of the IP packets that the client computer sends. Some differences in the two approaches:
§ DHCP handles changes by reconfiguring the client while a VLAN-capable network handles it by reconfiguring the network port the client is moved to.
§ DHCP dynamic reconfiguration requires a DHCP server, forwarding agent in each router, and DHCP capability in each client's TCP/IP support. The analogous capability in VLANs requires that all hubs throughout the network be VLAN-capable, supporting the same VLAN scheme. To this point VLAN support is proprietary with no vendor interoperability, but standards are being developed.
§ DHCP can configure a new client computer for you while a VLAN-capable network can't.
§ DHCP is generally aimed at giving "easy moves" capability to networks that are divided into subnets on a geographical basis, or on separate networks. VLANs are generally aimed at allowing you to set up subnets on some basis other than geographical, e.g. instead of putting everyone in one office on the same subnet, putting each person on a subnet that has access to the servers that that person requires.
There is an issue with trying to use DHCP (or BOOTP) and VLANs at the same time, in particular, with the scheme by which the VLAN-capable network determines the client's VLAN based upon the client computer's source IP address. Doing so assumes the client computer is already configured, which precludes the use of network to get the configuration information from a DHCP or BOOTP server.
DHCP, like BOOTP runs over UDP, utilizing ports 67 and 68.
An IP address (also called an IP number) is a number (typically written as four numbers separated by periods, i.e. 107.4.1.3 or 84.2.1.111) which uniquely identifies a computer that is making use of the Internet. It is analogous to your telephone number in that the telephone number is used by the telephone network to direct calls to you. The IP address is used by the Internet to direct data to your computer, e.g. the data your web browser retrieves and displays when you surf the net. One task of DHCP is to assist in the problem of getting a functional and unique IP number into the hands of the computers that make use of the Internet.
A MAC address (also called an Ethernet address or an IEEE MAC address) is a number (typically written as twelve hexadecimal digits, 0 through 9 and A through F, or as six hexadecimal numbers separated by periods or colons, i.e. 0080002012ef, 0:80:0:2:20:ef) which uniquely identifes a computer that has an Ethernet interface. Unlike the IP number, it includes no indication of where your computer is located. In DHCP's typical use, the server uses a requesting computer's MAC address to uniquely identify it.
A DHCP lease is the amount of time that the DHCP server grants to the DHCP client permission to use a particular IP address. A typical server allows its administrator to set the lease time.
What is termed the Client ID for the purposes of the DHCP protocol is whatever is used by the protocol to identify the client computer. By default, DHCP implementations typically employ the client's MAC address for this purpose, but the DHCP protocol allows other options. Some DHCP implementations have a setup option to specify the client ID you want. One alternative to the MAC address is simply a character string of your choice. In any case, in order for DHCP to function, you must be certain that no other client is using the client ID you choose, and you must be sure the DHCP server will accept it.
It is theoretically possible to develop software for client-machines that finds an unused address by picking them out of the blue and broadcasting a request of all the other client machines to see if they are using them. Appletalk is designed around this idea, and Apple's MacTCP can be configured to do this for IP. However, this method of IP address assignment has disadvantages.
1. A computer that needs a permanently-assigned IP number might be turned off and lose its number to a machine coming up. This has problems both for finding services and for security.
2. A network might be temporarily divided into two non-communicating networks while a network component is not functioning. During this time, two different client-machines might end up claiming the same IP number. When the network comes back, they start malfunctioning.
3. If such dynamic assignment is to be confined to ranges of IP addresses, then the ranges are configured in each desktop machine rather than being centrally administered. This can lead both to hidden configuration errors and to difficulty in changing the range. Another problem with the use of such ranges is keeping it easy to move a computer from one subnet to another.
Yes. At least there is nothing in the protocol to preclude this and one expects it to be a feature of any DHCP server. This is really a server matter and the client should work either way. The RFC refers to this as manual allocation.
For the situations where there is more than one LAN, each with its own subnet number, there are two ways. First of all, you can set up a seperate server on each subnet. Secondly, a feature of some routers known as "BOOTP forwarding" to forward DHCP or BOOTP requests to a server on another subnet and to forward the replies back to the client. The part of such a router (or server acting as a router) that does this is called a "BOOTP forwarding agent". Typically you have to enable it on the interface to the subnet to be served and have to configure it with the IP address of the DHCP or BOOTP server. On a Cisco router, the address is known as the "UDP Helper Address".
Only if the DHCP server is specifically written to also handle BOOTP queries.
Only if the DHCP client were specifically written to make use of the answer from a BOOTP server. It would presumably treat a BOOTP reply as an unending lease on the IP address.
In particular, the TCP/IP stack included with Windows 95 does not have this capability.
The RFC on such interoperability (1534) is clear: "In summary, a DHCP server: ... MAY support BOOTP clients," (section 2). The word "MAY" indicates such support, however useful, is left as an option.
A source of confusion on this point is the following statement in section 1.5 of RFC 1541: "DHCP must provide service to existing BOOTP clients." However, this statement is one in a list of "general design goals for DHCP", i.e. what the designers of the DHCP protocol set as their own goals. It is not in a list of requirements for DHCP servers.
The RFC on such interoperability (1534) is clear: "A DHCP client MAY use a reply from a BOOTP server if the configuration returned from the BOOTP server is acceptable to the DHCP client." (section 3). The word "MAY" indicates such support, however useful, is left as an option.
1. Can a DHCP client or server make a DNS server update the client's DNS entry to match the client's dynamically assigned address?
RFCs 2136 and 2137 indicate a way in which DNS entries can be updated dynamically. Using this requires a DNS server that supports this feature and a DHCP server that makes use of it. The RFCs are very recent (as of 5/97) and implementations are few. In the mean time, there are DNS and DHCP servers that accomplish this through proprietary means.
You can have two or more servers handing out leases for different addresses. If each has a dynamic pool accessible to the same clients, then even if one server is down, one of those clients can lease an address from the other server.
However, without communication between the two servers to share their information on current leases, when one server is down, any client with a lease from it will not be able to renew their lease with the other server. Such communication is the purpose of the "server to server protocol" (see next question). It is possible that some server vendors have addressed this issue with their own proprietary server-to-server communication.
The DHC WG of the IETF is actively investigating the issues in inter-server communication. The protocol should be defined "soon".
1. In a subnetted environment, how does the DHCP server discover what subnet a request has come from?
DHCP client messages are sent to off-net servers by DHCP relay agents, which are often a part of an IP router. The DHCP relay agent records the subnet from which the message was received in the DHCP message header for use by the DHCP server.
1. If a single LAN has more than one subnet number, how can addresses be served on subnets other than the primary one?
A single LAN might have more than one subnet number applicable to the same set of ports (broadcast domain). Typically, one subnet is designated as primary, the others as secondary. A site may find it necessary to support addresses on more than one subnet number associated with a single interface. DHCP's scheme for handling this is that the server has to be configured with the necessary information and has to support such configuration & allocation. Here are four cases a server might have to handle:
1. Dynamic allocation supported on secondary subnet numbers on the LAN to which the server is attached.
2. Dynamic allocation supported on secondary subnet numbers on a LAN which is handled through a DHCP/BOOTP Relay. In this case, the DHCP/BOOTP Relay sends the server a gateway address associated with the primary subnet and the server must know what to do with it.
The other two cases are the same capabilities during manual allocation. It is possible that a particular server-implementation can handle some of these cases, but not all of them. See section below listing the capabilities of some servers.
2. If a physical LAN has more than one logical subnet, how can different groups of clients be allocated addresses on different subnets?
One way to do this is to preconfigure each client with information about what group it belongs to. A DHCP feature designed for this is the user class option. To do this, the client software must allow the user class option to be preconfigured and the server software must support its use to control which pool a client's address is allocated from.
In Internet RFCs.
RFC 2131
R. Droms, "Dynamic Host Configuration Protocol", 3/97. Supersedes RFC 1541 and RFC 1531. [Note that some of the references in this FAQ are to RFC 1541: I'll update them when I get a chance. -- Author]
RFC 1534
R. Droms, "Interoperation Between DHCP and BOOTP", 10/08/1993.
RFC 2132
S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor Extensions", 3/97. Supersedes RFC 1533.
PPP has its own non-DHCP way in which communications servers can hand clients an IP address called IPCP (IP Control Protocol) but doesn't have the same flexibility as DHCP or BOOTP in handing out other parameters. Such a communications server may support the use of DHCP to acquire the IP addresses it gives out. This is sometimes called doing DHCP by proxy for the client. I know that Windows NT's remote access support does this.
A feature of DHCP under development (DHCPinform) is a method by which a DHCP server can supply parameters to a client that already has an IP number. With this, a PPP client could get its IP number using IPCP, then get the rest of its parameters using this feature of DHCP.
SLIP has no standard way in which a server can hand a client an IP address, but many communications servers support non-standard ways of doing this that can be utilized by scripts, etc. Thus, like communications servers supporting PPP, such communications servers could also support the use of DHCP to acquire the IP addressees to give out.
The DHCP protocol is capable of allocating an IP address to a device without an IEEE-style MAC address, such as a computer attached through SLIP or PPP, but to do so, it makes use of a feature which may or may not be supported by the DHCP server: the ability of the server to use something other than the MAC address to identify the client. Communications servers that acquire IP numbers for their clients via DHCP run into the same roadblock in that they have just one MAC address, but need to acquire more than one IP address. One way such a communications server can get around this problem is through the use of a set of unique pseudo-MAC addresses for the purposes of its communications with the DHCP server. Another way (used by Shiva) is to use a different "client ID type" for your hardware address. Client ID type 1 means you're using MAC addresses. However, client ID type 0 means an ASCII string.
There is nothing in the protocol to keep a client that already has a leased or permanent IP number from getting a(nother) lease on a temporary basis on another subnet (i.e., for that laptop which is almost always in one office, but occasionally is plugged in in a conference room or class room). Thus it is left to the server implementation to support such a feature. I've heard that Microsoft's NT-based server can do it.
A server on a net(subnet) can relay DHCP or BOOTP for that net. Microsoft has software to make Windows NT do this.
I don't have an answer for this, but will offer a little discussion. The answer depends a lot on what BOOTP server you are using and how you are maintaining it. If you depend heavily on BOOTP server software to support your existing clients, then the demand to support clients that support DHCP but not BOOTP presents you with problems. In general, you are faced with the choice:
1. Find a server that is administered like your BOOTP server only that also serves DHCP. For example, one popular BOOTP server, the CMU server, has been patched so that it will answer DHCP queries.
2. Run both a DHCP and a BOOTP server. It would be good if I could find out the gotcha's of such a setup.
3. Adapt your site's administration to one of the available DHCP/BOOTP servers.
4. Handle the non-BOOTP clients specially, e.g. turn off DHCP and configure them statically: not a good solution, but certainly one that can be done to handle the first few non-BOOTP clients at your site.
Sites may choose to require central pre-configuration for all computers that will be able to acquire a dynamic address. A DHCP server could be designed to implement such a requirement, presumably as an option to the server administrator. See section below on servers that implement this.
There is no standard MIB; creating one is on the list of possible activities of the DHCP working group. It is possible that some servers implement private MIBs.
Ascend Pipeline ISDN routers (which attach Ethernets to ISDN lines) incorporate a feature that Ascend calls "DHCP spoofing" which is essentially a tiny server implementation that hands an IP address to a connecting Windows 95 computer, with the intention of giving it an IP number during its connection process.
I've asked sites about this and have heard answers ranging from 15 minutes to a year. Most administrators will say it depends upon your goals, your site's usage patterns, and service arrangements for your DHCP server.
A very relevant factor is that the client starts trying to renew the lease when it is halfway through: thus, for example, with a 4 day lease, the client which has lost access to its DHCP server has 2 days from when it first tries to renew the lease until the lease expires and the client must stop using the network. During a 2-day outage, new users cannot get new leases, but no lease will expire for any computer turned on at the time that the outage commences.
Another factor is that the longer the lease the longer time it takes for client configuration changes controlled by DHCP to propogate.
Some relevant questions in deciding on a lease time:
Do you have more users than addresses?
If so, you want to keep the lease time short so people don't end up sitting on leases. Naturally, there are degrees. In this situation, I've heard examples cited of 15 minutes, 2 hours, and 2 days. Naturally, if you know you will have 20 users using 10 addresses in within a day, a 2 day lease is not practical.
Are you supporting mobile users?
If so, you may be in the situation of having more users than addresses on some particular IP number range. See above.
Do you have a typical or minimum amount of time that you are trying to support?
If your typical user is on for an hour at minimum, that suggest a hour lease at minimum.
How many clients do you have and how fast are the communications lines over which the DHCP packets will be run?
The shorter the lease, the higher the server and network load. In general, a lease of at least 2 hours is long enough that the load of even thousands of clients is negligible. For shorter leases, there may be a point beyond which you will want to watch the load. Note that if you have a communication line down for a long enough time for the leases to expire, you might see an unusually high load it returns. If the lease-time is at least double the communication line outage, this is avoided.
How long would it take to bring back up the DHCP server, and to what extent can your users live without it?
If the lease time is at least double the server outage, then running clients who already have leases will not lose them. If you have a good idea of your longest likely server outage, you can avoid such problems. For example, if your server-coverage is likely to recover the server within three hours at any time that clients are using their addresses, then a six hour lease will handle such an outage. If you might have a server go down on Friday right after work and may need all Monday's work-day to fix it, then your maximum outage time is 3 days and a 6-day lease will handle it.
Do you have users who want to tell other users about their IP number?
If your users are setting up their own web servers and telling people how to get to them either by telling people the IP number or through a permanent DNS entry, then they are looking for an IP number that won't be changing. While some sites would manually allocate any address that people expected to remain stable, other sites want to use DHCP's ability to automate distribution of relatively permanent addresses. The relevant time is the maximum amount of time that you wish to allow the user to keep their machine turned off yet keep their address. For example, in a university, if students might have their computers turned off for as long as three weeks between semesters, and you wish them to keep their IP address, then a lease of six weeks or longer would suffice.
1. SomeSome examples of lease-times that sites have used & their rationals:
15 minutes
To keep the maximum number of addresses free for distribution in cases where there will be more users than addresses.
6 hours
Long enough to allow the DHCP server to be fixed, e.g. 3 hours.
12 hours
If you need to take back an address, then you know that it will only take one night for the users' lease to expire.
3 days
This is apparently Microsoft's default, thus many sites use it.
6 days
Long enough that a weekend server outage that gets fixed on Monday will not result in leases terminating.
4 months
Long enough that students can keep their IP address over the summer hiatus. I believe this rational is workable if the summer hiatus is no more than 2 months.
One year
If a user has not used their address in six months, then they are likely to be gone. Allows administrator to recover those addresses after someone has moved on.
examples of lease-times that sites have used & their rationals:
1. How can I prevent unauthorized laptops from using a network that uses DHCP for dynamic addressing?
This would have to be done using a mechanism other than DHCP. DHCP does not prevent other clients from using the addresses it is set to hand out nor can it distinguish between a computer's permanent MAC address and one set by the computer's user. DHCP can impose no restrictions on what IP address can use a particular port nor control the IP address used by any client.
DHCP requires disk storage (or some other form of reliable non-volatile storage), making the task of DHCP service more compatible with servers than with dedicated routers. The large-scale routers (i.e., those of Cisco, Bay, Fore) don't an will probably never will have a DHCP server function.
But there are a number of types of servers that can be configured to route and serve DHCP. This includes Novell servers and computers running Unix. There are also units designed to handle two or more aspects of your Internet connection, e.g. routing between a LAN and a leased line as well as doing other functions to allow computers on the LAN to reach the Internet (or corporate intranet as the case may be). One example is Farallon's Netopia Internet Router mentioned above under commercial servers.
The DHCP RFC specifically says that DHCP is not intended for use in configuring routers. The reason is that in maintaining and troubleshooting routers, it is important to know its exact configuration rather than leaving that to be automatically done, and also that you do not want your router's operation to depend upon the working of yet another server.
It may be possible to configure some types of more general-purpose computers or servers to get their addresses from DHCP and to act as routers. Also, there are remote access servers, often which are usually not true routers, which use DHCP to acquire addresses to hand out to their clients.
§ Windows NT's 3.51 Service Pack 3 (and 4) includes a BOOTP (& DHCP) relay agent as part of "Multi Protocol Router". 3.51).
§ For Novell servers, there are NLMs that forward BOOTP requests, thus DHCP requests. The "BOOTPFWD NLM" is included in NetWare 4.1. You can get this support in NetWare 3.11 and 3.12 also by applying the TCPN01.EXE patch which is located at ftp://ftp.novell.com/updates/inet/mpr211/tcpn01.exe and on Netwire. Two other such NLMs (possibly old versions of the same) that are available online:
§ ftp://netlab2.usu.edu/misc/bootpfd.zip(unsupported Novell software, 1993)
§ ftp://netlab2.usu.edu/misc/bootp311.zip(unsupported Novell software, 1991)
§ Also for Novell servers, the DHCP server that comes with NetWare/IP 2.2 can be configured to be just a BOOTP/DHCP forwarding agent.
§ AIX, through its dhcprd daemon.
§ Warp Server Version 4.
The broadcast flag is an optional element of DHCP, but a client which sets it works only with a server or relay that supports it.
§ Clients
Microsoft Windows NT
DHCP client support added with version 3.5 sets the broadcast flag. Version 3.51 and later no longer set it. The exception is in the remote access support: it sets the flag when it uses DHCP to acquire addresses to hand out to its PPP clients.
tcp/ip-32 for Microsoft Windows for Workgroups (WFW)
Version 3.11a sets it, but version 3.11B doesn't.
Microsoft Windows 95
Does not set the broadcast flag.
4. (These are not complete lists) The following servers can handle dynamic allocation on secondary subnet numbers:
§ IPTrack version 2.0
§ ISC
§ JOIN
§ SGI's DHCP Server under IRIX 6.2
§ Cisco (previously TGV)
§ NetID
§ Microsoft Windows NT 4.0 (since service pack 2)
§ Sonic
§ QDHCP
§ ipLease
§ IBM Warp Server Version 4
§ IBM AIX
Not really a DHCP question, but it has been asked a lot, particularly by sites for which changing from BOOTP represents a lot of work. Some choices:
§ Use no server at all for the Windows 95 clients: set the addresses in each client's setup.
§ Install a non-Microsoft TCP/IP stack for Windows 95 that supports BOOTP.
§ Switch from your current BOOTP server to one that supports both BOOTP and DHCP.
§ The 'billgPC' program uses BOOTP (instead of DHCP) to configure Windows 95's native IP stack: http://www.panix.com/~perin/ (note: it also works with Windows NT).
A Document that addresses this question is the Windows 95tm Networking FAQ,
Resources for DHCP
The Dynamic Host Configuration Protocol (DHCP) is an Internet protocol for automating the configuration of computers that use TCP/IP. DHCP can be used to automatically assign IP addresses, to deliver TCP/IP stack configuration parameters such as the subnet mask and default router, and to provide other configuration information such as the addresses for printer, time and news. DHCP
Short for Dynamic Host Configuration Protocol, a protocol for assigning dynamic IP addresses to devices on a network. With dynamic addressing, a device can have a different IP address every time it connects to the network. In some systems, the device's IP address can even change while it is still connected. DHCP also supports a mix of static and dynamic IP addresses.
Dynamic addressing simplifies network administration because the software keeps track of IP addresses rather than requiring an administrator to manage the task. This means that a new computer can be added to a network without the hassle of manually assigning it a unique IP address. Many ISPs use dynamic IP addressing for dial-up users.
Dynamic Host Configuration Protocol (DHCP)
ISC's Dynamic Host Configuration Protocol Distribution provides a freely redistributable reference implementation of all aspects of DHCP, through a suite of DHCP tools:
· A DHCP server
· A DHCP client
· A DHCP relay agent
These tools all use a modular API which is designed to be sufficiently general that it can easily be made to work on POSIX-compliant operating systems and also non-POSIX systems like Windows NT and MacOS.
The DHCP server, client and relay agent are provided both as reference implementations of the protocol and as working, fully-featured sample implementations. Both the client and the server provide functionality that, while not strictly required by the protocol, is very useful in practice. The DHCP server also makes allowances for non-compliant clients which one might still like to support.
 |  | |||||||
| ||||||||
- DHCP (Dynamic Host Configuration Protocol) is a communications
What is DHCP?
Dynamic Host Configuration Protocol (DHCP) is a network protocol that enables a DHCP server to automatically assign an IP address to an individual computer's TCP/IP stack software. DHCP assigns a number dynamically from a defined range of numbers (i.e., a scope) configured for a given network.
Client computers configured to use DHCP for IP assignment do not need to have a statically assigned IP address. In addition, they generally do not need to have addresses configured for DNS servers or WINS servers, as these are also set by the DHCP server.
DHCP assigns a TCP/IP address when a system is started. Typically, it works like this:
1. A user turns on a computer with a DHCP client.
2. The client computer sends a broadcast request (called a DISCOVER or DHCPDISCOVER), looking for a DHCP server to answer.
3. The router directs the DISCOVER packet to the correct DHCP server.
4. The server receives the DISCOVER packet. Based on availability and usage policies set on the server, the server determines an appropriate address (if any) to give to the client. The server then temporarily reserves that address for the client and sends back to the client an OFFER (or DHCPOFFER) packet, with that address information. The server also configures the client's DNS servers, WINS servers, NTP servers, and sometimes other services as well.
5. The client sends a REQUEST (or DHCPREQUEST) packet, letting the server know that it intends to use the address.
6. The server sends an ACK (or DHCPACK) packet, confirming that the client has a been given a lease on the address for a server-specified period of time.
When a computer uses a static IP address, it means that the computer is manually configured to use a specific IP address. One problem with static assignment, which can result from user error or inattention to detail, occurs when two computers are configured with the same IP address. This creates a conflict that results in loss of service. Using DHCP to dynamically assign IP addresses minimizes these conflicts.
| DHCP Dynamic Host Configuration Protocol (DHCP)
This protocol is used to assign IP addresses to hosts or workstations on the network. Usually a DHCP server on the network performs this function. Basically it "leases" out address for specific times to the various hosts. If a host does not use a given address for some period of time, that IP address can then be assigned to another machine by the DHCP server. When assignments are made or changed, the DHCP server must update the information in the DNS server.
As with BOOTP, DHCP uses the machine's or NIC ethernet (MAC) or hardware address to determine IP address assignments. The DHCP protocol is built on BOOTP and replaces BOOTP. DHCP extends the vendor specific area in BOOTP to 312 bytes from 64. RFC 1541 defines DHCP.
DHCP RFCs
DHCP RFCs are 1533, 1534, 1541, and 1542. Sent from DHCP server:
· IP address
· Netmask
· Default Gateway address
· DNS server addresse(s)
· NetBIOS Name server (NBNS) address(es).
· Lease period in hours
· IP address of DHCP server.
DHCP Lease Stages |   |
1. Lease Request - The client sends a broadcast requesting an IP address
2. Lease Offer - The server sends the above information and marks the offered address as unavailable. The message sent is a DHCPOFFER broadcast message.
3. Lease Acceptance - The first offer received by the client is accepted. The acceptance is sent from the client as a broadcast (DHCPREQUEST message) including the IP address of the DNS server that sent the accepted offer. Other DHCP servers retract their offers and mark the offered address as available and the accepted address as unavailable.
4. Server lease acknowledgement - The server sends a DHCPACK or a DHCPNACK if an unavailable address was requested.
DHCP discover message - The initial broadcast sent by the client to obtain a DHCP lease. It contains the client MAC address and computer name. This is a broadcast using 255.255.255.255 as the destination address and 0.0.0.0 as the source address. The request is sent, then the client waits one second for an offer. The request is repeated at 9, 13, and 16 second intervals with additional 0 to 1000 milliseconds of randomness. The attempt is repeated every 5 minutes thereafter.
The client uses its own port 68 as the source port with port 67 as the destination port on the server to send the request to the server. The server uses its own port 67 as the source port with port 68 as the destination port on the client to reply to the client. Therefore the server is listening and sending on its own port 67 and the client is listening and sending on its own port 68. This can be confusing when you consider which way the message is going. To be clear on this, I quote RFC 1531 which states "DHCP messages from a client to a server are sent to the 'DHCP server' port (67), and DHCP messages from a server to a client are sent to the 'DHCP client' port (68)"
DHCP Lease Renewal
After 50% of the lease time has passed, the client will attempt to renew the lease with the original DHCP server that it obtained the lease from using a DHCPREQUEST message. Any time the client boots and the lease is 50% or more passed, the client will attempt to renew the lease. At 87.5% of the lease completion, the client will attempt to contact any DHCP server for a new lease. If the lease expires, the client will send a request as in the initial boot when the client had no IP address. If this fails, the client TCP/IP stack will cease functioning.
DHCP Scope and Subnets
One DHCP scope is required for each subnet.
DHCP Relay Agents
May be placed in two places:
· Routers
· Subnets that don't have a DHCP server to forward DHCP requests.
Client Reservation
Client Reservation is used to be sure a computer gets the same IP address all the time. Therefore since DHCP IP address assignments use MAC addresses to control assignments, the following are required for client reservation:
· MAC (hardware) address
· IP address
Exclusion Range
Exclusion range is used to reserve a bank of IP addresses so computers with static IP addresses, such as servers may use the assigned addresses in this range. These addresses are not assigned by the DHCP server.
DNS
Domain name systThe Domain Name System (DNS) associates various sorts of information with so-called domain names; most importantly, it serves as the "phone book" for the Internet by translating human-readable computer hostnames, e.g. www.example.com, into the IP addresses, e.g. 208.77.188.166, that networking equipment needs to deliver information. It also stores other information such as the list of mail exchange servers that accept email for a given domain. In providing a worldwide keyword-based redirection service, the Domain Name System is an essential component of contemporary Internet use.
DNS
(1) Short for Domain Name System (or Service or Server), an Internet service that translates domain names into IP addresses. Because domain names are alphabetic, they're easier to remember. The Internet however, is really based on IP addresses. Every time you use a domain name, therefore, a DNS service must translate the name into the corresponding IP address. For example, the domain name www.example.com might translate to 198.105.232.4.
The DNS system is, in fact, its own network. If one DNS server doesn't know how to translate a particular domain name, it asks another one, and so on, until the correct IP address is returned
. (2) Short for digital nervous system, a term coined by Bill Gates to describe a network of personal computers that make it easier to obtain and understand information
. How Domain Name Servers Work
If you spend any time on the Internet sending e-mail or browsing the Web, then you use domain name servers without even realizing it. Domain name servers, or DNS, are an incredibly important but completely hidden part of the Internet, and they are fascinating. The DNS system forms one of the largest and most active distributed databases on the planet. Without DNS, the Internet would shut down very quickly.
In this article, we'll take a look at the DNS system so you can understand how it works and appreciate its amazing capabilities.
When you use the Web or send an e-mail message, you use a domain name to do it. For example, the URL "http://www.howstuffworks.com" contains the domain name howstuffworks.com. So does the e-mail address "iknow@howstuffworks.com."
Human-readable names like "howstuffworks.com" are easy for people to remember, but they don't do machines any good. All of the machines use names called IP addresses to refer to one another. For example, the machine that humans refer to as "www.howstuffworks.com" has the IP address 216.183.103.150. Every time you use a domain name, you use the Internet's domain name servers (DNS) to translate the human-readable domain name into the machine-readable IP address. During a day of browsing and e-mailing, you might access the domain name servers hundreds of times!
Domain name servers translate domain names to IP addresses. That sounds like a simple task, and it would be -- except for five things:
· There are billions of IP addresses currently in use, and most machines have a human-readable name as well.
· There are many billions of DNS requests made every day. A single person can easily make a hundred or more DNS requests a day, and there are hundreds of millions of people and machines using the Internet daily.
· Domain names and IP addresses change daily.
· New domain names get created daily.
· Millions of people do the work to change and add domain names and IP addresses every day.
The DNS system is a database, and no other database on the planet gets this many requests. No other database on the planet has millions of people changing it every day, either. That is what makes the DNS system so unique.
IP Addresses
To keep all of the machines on the Internet straight, each machine is assigned a unique address called an IP address. IP stands for Internet protocol, and these addresses are 32-bit numbers normally expressed as four "octets" in a "dotted decimal number." A typical IP address looks like this:
216.183.103.150
The four numbers in an IP address are called octets because they can have values between 0 and 256 (28 possibilities per octet).
Every machine on the Internet has its own IP address. A server has a static IP address that does not change very often. A home machine that is dialing up through a modem often has an IP address that is assigned by the ISP when you dial in. That IP address is unique for your session and may be different the next time you dial in. In this way, an ISP only needs one IP address for each modem it supports, rather than for every customer.
If you are working on a Windows machine, you can view your current IP address with the command WINIPCFG.EXE (IPCONFIG.EXE for Windows 2000/XP). On a UNIX machine, type nslookup along with a machine name (such as "nslookup www.howstuffworks.com") to display the IP address of the machine (use the command hostname to learn the name of your machine).
For more information on IP addresses, see IANA.
As far as the Internet's machines are concerned, an IP address is all that you need to talk to a server. For example, you can type in your browser the URL http://216.183.103.150 and you will arrive at the machine that contains the Web server for HowStuffWorks. Domain names are strictly a human convenience.
 |
 |
 - The domain name system (DNS) is the way that Internet domain names are located and translated into Internet Protocol addresses. A domain name is a meaningful and easy-to-remember "handle" for an Internet address.
Because maintaining a central list of domain name/IP address correspondences would be impractical, the lists of domain names and IP addresses are distributed throughout the Internet in a hierarchy of authority. There is probably a DNS server within close geographic proximity to your access provider that maps the domain names in your Internet requests or forwards them to other servers in the Internet.
|
ACTIVE DIRECTORY
Active Directory (AD) is an implementation of LDAP directory services by Microsoft for use primarily in Windows environments. Its main purpose is to provide central authentication and authorization services for Windows based computers. Active Directory also allows administrators to assign policies, deploy software, and apply critical updates to an organization. Active Directory stores information and settings in a central database. Active Directory networks can vary from a small installation with a few hundred objects, to a large installation with millions of objects.
Active Directory was previewed in 1996, released first with Windows 2000 Server edition, and revised to extend functionality and improve administration in Windows Server 2003. Additional improvements were made in both Windows Server 2003 R2 and Windows Server 2008.
Active Directory was called NTDS (NT Directory Service) in older Microsoft documents. This name can still be seen in some AD binaries.
There is a common misconception that Active Directory provides software distribution. Software distribution is run by a separate service that uses additional proprietary schema attributes that work in conjunction with the LDAP protocol. Active Directory does not automate software distribution, but provides a mechanism in which other services can provide software distribution
Active Directory features include:
· Support for the X.500 standard for global directories
· The capability for secure extension of network operations to the Web
· A hierarchical organization that provides a single point of access for system administration (management of user accounts, clients, servers, and applications, for example) to reduce redundancy and errors
· An object-oriented storage organization, which allows easier access to information
· Support for the Lightweight Directory Access Protocol (LDAP) to enable inter-directory operability
· Designed to be both backward compatible and forward compatible
FSMO
Short for Flexible Single Master Operations, it is a feature of Microsoft's Active Directory. The schema master FSMO role holder is the domain controller responsible for performing updates to the directory schema.
There are just five operations where the usual multiple master model breaks down, and the Active Directory task must only be carried out on one Domain Controller. FSMO roles:
1. PDC Emulator - Most famous for backwards compatibility with NT 4.0 BDC's. However, there are two other FSMO roles which operate even in Windows 2003 Native Domains, synchronizing the W32Time service and creating group policies. I admit that it is confusing that these two jobs have little to do with PDCs and BDCs.
2. RID Master - Each object must have a globally unique number (GUID). The RID master makes sure each domain controller issues unique numbers when you create objects such as users or computers. For example DC one is given RIDs 1-4999 and DC two is given RIDs 5000 - 9999.
3. Infrastructure Master - Responsible for checking objects in other other domains. Universal group membership is the most important example. To me, it seems as though the operating system is paranoid that, a) You are a member of a Universal Group in another domain and b) that group has been assigned Deny permissions. So if the Infrastructure master could not check your Universal Groups there could be a security breach.
4. Domain Naming Master - Ensures that each child domain has a unique name. How often do child domains get added to the forest? Not very often I suggest, so the fact that this is a FSMO does not impact on normal domain activity. My point is it's worth the price to confine joining and leaving the domain operations to one machine, and save the tiny risk of getting duplicate names or orphaned domains.
5. Schema Master - Operations that involve expanding user properties e.g. Exchange 2003 / forestprep which adds mailbox properties to users. Rather like the Domain naming master, changing the schema is a rare event. However if you have a team of Schema Administrators all experimenting with object properties, you would not want there to be a mistake which crippled your forest. So its a case of Microsoft know best, the Schema Master should be a Single Master Operation and thus a FSMO role.
0 Comments:
Post a Comment