When I move into a new dormitory, the network manager in the network center tells me my IP address, DNS address, gateway address, and stuff. I was told to just plug in my cable, enter these addresses, and then all are fine to go.

And it did work fine.

But I am wondering, what is going on when I manually change these address? Wouldn't there be a chance that two people under the same subnet enter the same IP address and they go into confict? How to prevent that?

I know there is a protocol called DHCP, which is set to dynamically assign IP addresses to new devices joining the network. I know DHCP pretty well, but I just can't figure out what's really going on with those manually assigned IP addresses. What protocol is used to handle those possible conflicts? And, more importantly, how can my device tell the router this new IP address so that the router can forward packets in the right direction?

  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer.
    – Ron Maupin
    Aug 14 '17 at 2:55

Wouldn't there be a chance that two people under the same subnet enter the same IP address and they go into confict? How to prevent them ?

Yes, that can, and does, happen when networks have manually configured addressing. That situation leads to unpredictable network behavior. Often, devices with the same address can't communicate on the network. Sometimes, one device works. Some OSes can detect the conflict and report it. There is no real way to prevent this from happening.

What protocol is used to handle those possible conflict ? And more importantly, how can my device tell the router this new IP address so that the router can forward packets in a right direction?

Your device doesn't need to tell the router anything. The router knows the networks which are attached to its interfaces. It will ARP to resolve the layer-3 address to a layer-2 address before encapsulating the packets into frames for the network segment.

IPv6 has DAD (Duplicate Address Detection) built in. For IPv4, it was not part of the original standard, but there is now RFC 5227, IPv4 Address Conflict Detection:

1. Introduction

Historically, accidentally configuring two Internet hosts with the same IP address has often been an annoying and hard-to-diagnose problem.

This is unfortunate, because the existing Address Resolution Protocol (ARP) provides an easy way for a host to detect this kind of misconfiguration and report it to the user. The DHCP specification [RFC2131] briefly mentions the role of ARP in detecting misconfiguration, as illustrated in the following three excerpts from RFC 2131:

  • the client SHOULD probe the newly received address, e.g., with ARP

  • The client SHOULD perform a final check on the parameters (e.g., ARP for allocated network address)

  • If the client detects that the address is already in use (e.g., through the use of ARP), the client MUST send a DHCPDECLINE message
    to the server

    Unfortunately, the DHCP specification does not give any guidance to implementers concerning the number of ARP packets to send, the interval between packets, the total time to wait before concluding that an address may safely be used, or indeed even which kinds of packets a host should be listening for, in order to make this determination. It leaves unspecified the action a host should take if, after concluding that an address may safely be used, it subsequently discovers that it was wrong. It also fails to specify what precautions a DHCP client should take to guard against pathological failure cases, such as a DHCP server that repeatedly OFFERs the same address, even though it has been DECLINEd multiple times.

    The authors of the DHCP specification may have been justified in thinking at the time that the answers to these questions seemed too simple, obvious, and straightforward to be worth mentioning, but unfortunately this left some of the burden of protocol design to each individual implementer. This document seeks to remedy this omission by clearly specifying the required actions for:

    1. Determining whether use of an address is likely to lead to an addressing conflict. This includes (a) the case where the address is already actively in use by another host on the same link, and (b) the case where two hosts are inadvertently about to begin using the same address, and both are simultaneously in the process of probing to determine whether the address may safely be used (Section 2.1.).

    2. Subsequent passive detection that another host on the network is inadvertently using the same address. Even if all hosts observe precautions to avoid using an address that is already in use, conflicts can still occur if two hosts are out of communication at the time of initial interface configuration. This could occur with wireless network interfaces if the hosts are temporarily out of range, or with Ethernet interfaces if the link between two Ethernet hubs is not functioning at the time of address configuration. A well-designed host will handle not only conflicts detected during interface configuration, but also conflicts detected later, for the entire duration of the time that the host is using the address (Section 2.4.).

    3. Rate-limiting of address acquisition attempts in the case of an excessive number of repeated conflicts (Section 2.1.).

The utility of IPv4 Address Conflict Detection (ACD) is not limited to DHCP clients. No matter how an address was configured, whether via manual entry by a human user, via information received from a DHCP server, or via any other source of configuration information, detecting conflicts is useful. Upon detecting a conflict, the configuring agent should be notified of the error. In the case where the configuring agent is a human user, that notification may take the form of an error message on a screen, a Simple Network Management Protocol (SNMP) notification, or an error message sent via text message to a mobile phone. In the case of a DHCP server, that notification takes the form of a DHCP DECLINE message sent to the server. In the case of configuration by some other kind of software, that notification takes the form of an error indication to the software in question, to inform it that the address it selected is in conflict with some other host on the network. The configuring software may choose to cease network operation, or it may automatically select a new address so that the host may re-establish IP connectivity as soon as possible.

Allocation of IPv4 Link-Local Addresses [RFC3927] can be thought of as a special case of this mechanism, where the configuring agent is a pseudo-random number generator, and the action it takes upon being notified of a conflict is to pick a different random number and try again. In fact, this is exactly how IPv4 Link-Local Addressing was implemented in Mac OS 9 back in 1998. If the DHCP client failed to get a response from any DHCP server, it would simply make up a fake response containing a random 169.254.x.x address. If the ARP module reported a conflict for that address, then the DHCP client would try again, making up a new random 169.254.x.x address as many times as was necessary until it succeeded. Implementing ACD as a standard feature of the networking stack has the side effect that it means that half the work for IPv4 Link-Local Addressing is already done.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.