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:
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.).
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.).
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.
