Tag - IP address

What are the Gotcha’s

What are the Gotcha’s?
A malicious user could make trouble by putting up an unofficial DHCP server.
The immediate problem would be a server passing out numbers already belonging to some computer yielding the potential for two or more “innocent bystander” nodes ending up with the same IP number. Net result is problems using the nodes, possibly intermittent of one or the other is sometimes turned off.
A lot of problems are possible if a renegade server manages to get a client to accept its lease offering, and feeds the client its own version of other booting paramvcers. One scenario is a client that loads its OS over the network via tftp being directed to a different file (possibly on a different server), thus allowing the perpetrator to take over the client. Given that boot paramvcers are often made to control many different things about the computers’ operation and communication, many other scenarios are just as serious.
Note that BOOTP has the same vulnerabilities.
The “broadcast flag”: DHCP includes a way in which client implementations unable to receive a packet with a specific IP address can ask the server or relay agent to use the broadcast IP address in the replies (a “flag” set by the client in the requests). The definition of DHCP states that implementations “should” honor this flag, but it doesn’t say they “must”. Some Microsoft TCP/IP implementations used this flag, which meant in practical terms, relay agents and servers had to implement it. A number of BOOTP-relay-agent implementations (e.g. in routers) handled DHCP just fine except for the need for this feature, thus they announced new versions stated to handle DHCP.
Some of the virtual LAN schemes, i.e., those that use the packet’s IP number to decide which “virtual LAN” a client-computer is on for the purposes of TCP/IP, don’t work when using DHCP to dynamically assign addresses. DHCP servers and relay agents use their knowledge of what LAN the client-station is on to select the subnet number for the client-station’s new IP address whereas such switches use the subnet number sent by the client-station to decide which (virtual) LAN to put the station on.
Routers are sometimes configured so that one LAN on one port has multiple network (or subnet) numbers. When the router is relaying requests from such a LAN to the DHCP server, it must pass along as IP number that is associated with one of the network (or subnet) numbers. The only way the DHCP server can allocate addresses on one of the LAN’s other network (or subnet) numbers is if the DHCP server is specifically written to have a feature to handle such cases, and it has a configuration describing the situation.
The knowledge that a particular IP number is associated with a particular node is often used for various functions. Examples are: for security purposes, for network management, and even for identifying resources. Furthermore, if the DNS’s names are going to identify IP numbers, the numbers, the IP numbers have to be stable. Dynamic configuration of the IP numbers undercuts such methods. For this reason, some sites try to keep the continued use of dynamically allocatable IP numbers to a minimum.
With two or more servers serving a LAN, clients that are moved around (e.g. mobile clients) can end up with redundant leases. Consider a home site with two DHCP servers, a remote site with DHCP services, and a mobile client. The client first connects to the home site and receives an address from one of the two serves. He/she then travels to the remote site (without releasing the lease at the home site) and attempts to use the acquired address. It is of course NAK’ed and the client receives an address appropriate for the remote site. The client then returns home and tries to use the address from the remote site. It is NAK’ed but now the client broadcasts a DHCPDISCOVER to get a address. The server that holds the previous lease will offer the address back to the client but there is no guarantee that the client will accept that address; consequently, it is possible for the client to acquire an address on the other server and therefore have two leases within the site. The problem can be solved by using only one server per subnet/site and can be mitigated by short lease lengths. But in a very mobile environment, it is possible for these transient clients to consume more than their fair share of addresses.
If departments, offices, or individuals run DHCP servers with their own small address pools on LANs shared by other departments, offices, or individuals, they can find that their addresses are being used by anyone on the LAN that happens to set their IP configuration to use DHCP.
An easy mistake to make in setting up a DHCP server is to fail to set all the necessary global paramvcers. This can result in some functions working while others are not, or functions working when the client is set up manually, but failing to work when set to use DHCP.
Long leases can be disadvantageous in cases where you need to change a configuration paramvcer or withdraw an address from use. The length of the lease can mean the difference between having to go to every affected client and rebooting it, or merely waiting a certain amount of time for the leases to be renewed. (Note: one workaround is to fool with the client computer’s clock).

Back DHCP FAQ

How can I control which clients get leases from my server

34. How can I control which clients get leases from my server?
There is no ideal answer: you have to give something up or do some extra work.

You can put all your clients on a subnet of your own along with your own DHCP server.
You can use manual allocation.
Perhaps you can find DHCP server software that allows you to list which MAC addresses the server will accept. DHCP servers that support roaming machines may be adapted to such use.
You can use the user class option assuming your clients and server support it: it will require you to configure each of your clients with a user class name. You still depend upon the other clients to respect your wishes.

35. 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.

Back DHCP FAQ

BOOTP client boot from a DHCP and BOOTPserver

15. Can a BOOTP client boot from a DHCP server?
Only if the DHCP server is specifically written to also handle BOOTP queries.

16. Can a DHCP client boot from a BOOTP server?
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.

17. Is a DHCP server “supposed to” be able to support a BOOTP client?
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.

18. Is a DHCP client “supposed to” be able to use a BOOTP server?
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.

19. 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.

Back DHCP FAQ

Copyright ©2010 - 2022 Ciscoforall.com | Privacy Policy | Terms & Conditions