NDP

NDP

Reading time: 7 minute Word count: 1291

IPv6 is not only about knowing your own address. A host also needs to know who the default router is, where local neighbors are, whether an address conflicts with someone else, and which prefixes can be treated as directly reachable on the local link. If you still split those jobs the way IPv4 often did, boundaries keep getting loose.

NDP handles that problem. It is not as simple as “turn ARP into IPv6 length addresses”. It brings neighbor resolution, router discovery, prefix advertisement, and address conflict detection into one ICMPv6 control-message framework for the IPv6 local link.

NDP is not “look up a neighbor MAC”. It is the unified control plane on the IPv6 local link for neighbor discovery, router discovery, and address validity probing

Why It Appears

In IPv4, these jobs are scattered:

ARP resolves the next-hop IP into a MAC address
ICMP handles error feedback and part of the control information
Address acquisition and default-route discovery often rely on other mechanisms

IPv6 does not want to keep that split mental model. In IPv6, after a host joins the local link, it has to solve more than “what is the neighbor’s MAC?” It also needs to know:

Who the default router is
Which prefixes can be treated as locally reachable
Whether this address conflicts with someone else
Whether the neighbor is still alive and whether the cache is still valid

NDP’s value is that it pulls those questions into one unified local-link control model.

The Background It Came From

NDP came from inside the IPv6 architecture. It is not just a side branch of IPv4 ARP. It rests on a more systematic design judgment:

Local-link control messages in IPv6 should live inside ICMPv6
Neighbor resolution, router discovery, and address probing should be unified
Local discovery should not depend on a separate protocol split away from the main control plane

That is why NDP feels “heavier” than ARP. It was built to carry more jobs from the start.

Grasp the Main Model First

To understand NDP, keep four message types in mind:

RS: Router Solicitation
RA: Router Advertisement
NS: Neighbor Solicitation
NA: Neighbor Advertisement

You can compress them into two main lines:

Host wants to know about routes and prefixes
  -> RS / RA

Host wants to know whether a neighbor exists or an address conflicts
  -> NS / NA

If you only think of NDP as “IPv6 MAC lookup”, you will miss the first half of the model entirely.

The Most Common Main Path

A common IPv6 host bring-up path can be simplified like this:

sequenceDiagram participant H as Host participant R as Router participant N as Neighbor Host H->>R: Router Solicitation R->>H: Router Advertisement Note over H: Learn prefix / default route / link info H->>N: Neighbor Solicitation N->>H: Neighbor Advertisement Note over H,N: Complete neighbor resolution and cache setup

The key point is not to memorize the packet names. It is to see the split of responsibility:

RS / RA answer “how does the local network as a whole work”
NS / NA answer “who exactly is this local-link neighbor”

Why NDP Is Not Just IPv6 ARP

That wording is not totally wrong, but it is too shallow. ARP only answered one main question:

Which MAC belongs to this IPv4 address

NDP answers a whole set of questions:

Neighbor address resolution
Neighbor reachability confirmation
Duplicate address detection
Router discovery
Prefix advertisement

So NDP does not just move neighbor resolution into IPv6. It also expands and unifies the local-link control plane.

Why Router Advertisement Matters So Much

Once an IPv6 host joins the network, many of its default behaviors start with RA. A Router Advertisement does more than say “a router is here”. It may also tell the host:

Which prefixes may be used to form local addresses
Whether the default route is available
Whether the host should lean toward automatic formation or additional configuration

That is why, when RA is wrong in IPv6, many symptoms appear at once:

The host got an address but cannot reach anything
The default route was not installed correctly
The host behavior does not match the expected configuration model

Why Neighbor Solicitation Is Not Just “Ask for MAC”

NS / NA certainly handle neighbor resolution, but they also take part in two deeper tasks:

Duplicate address detection
Neighbor reachability checks

So when a host sends NS, it is not always just asking for a link-layer address. It may also be asking:

Is this address already in use
Is this neighbor still alive

That is why NDP is more like a continuously running local neighbor-management system than a simple lookup table.

Why Duplicate Address Detection Was Folded In

IPv6 lets hosts form addresses more naturally, which means conflict detection has to be much more serious. Otherwise the easier address formation gets, the more hidden the mistakes become.

So NDP includes duplicate address detection. The value is direct:

Before an address enters active use, check whether someone else already owns it
Conflict handling no longer depends on an extra separate protocol
Autoconfiguration does not become untrustworthy just because conflict detection was missing

That makes the IPv6 host address formation process start with a more complete local-link validation step.

Why NDP Also Brings Trust-Boundary Problems

NDP is more systematic than ARP, but that does not mean it is inherently safe. Once local-link control messages are polluted by wrong or malicious messages, the consequences are immediate:

Wrong router advertisements
Wrong neighbor bindings
Distorted address-conflict judgments

So NDP is not “safer because it is more advanced”. It is “more important to configure and protect correctly because more control lives in one message family.”

What to Look At in Packet Capture

Do not start by memorizing all ICMPv6 type numbers. A more useful order is below.

First decide which main line the failure belongs to

Separate:

RS / RA problems
NS / NA problems

The first is more about default routes and prefix discovery. The second is more about neighbor resolution and address conflict. Both can look like “IPv6 is broken”, but the root causes are different.

Then check what the host actually learned

Focus on:

Whether the default route entered the table
Whether the prefix was accepted by the host
Which neighbor the cache finally learned

Many problems are not “the packet never arrived”. The packet arrived, but the resulting host state was wrong.

Finally check whether the failure was mentally misclassified as ARP

This is one of the most common mental-model mistakes. When IPv6 local connectivity fails, people instinctively go looking for “where ARP is”. In IPv6, the better questions are usually:

Was there an RA
Were NS / NA exchanged correctly
Is the neighbor cache stable

If you stay in the IPv4 mental model, troubleshooting goes off-track immediately.

What Engineering Should Actually Think About NDP Today

Do not simplify NDP to “IPv6 ARP”. It carries a much larger local-link control plane
Do not mix RS / RA with NS / NA. They solve route/prefix discovery and neighbor resolution/probing respectively
Do not ignore duplicate address detection. It is one of the prerequisites for autoconfiguration to work
Do not assume IPv6 should still use IPv4’s ARP mental model. Many problems now start from different entry points
Do not underestimate the trust boundary of local-link control messages. NDP configuration and protection directly affect network trustworthiness