Eliminating the IPv6 First-Packet Latency via GRAND

Author Profile: Seyed Pouria Mousavizadeh Tehrani is a FreeBSD Source Committer with a deep specialization in network protocols. Based in Tehran, he has spent nearly a decade optimizing Internet connectivity across ISPs and datacenters, focusing heavily on the FreeBSD networking stack and IPv6 enhancements.

---

The Asymmetry of Neighbor Discovery

In a standard IPv6 environment, there is a subtle but impactful imbalance in how devices learn about each other. When a host joins a network, the process usually looks like this:

1. The host receives a Router Advertisement (RA).
2. The host configures its own global IPv6 address.
3. The host now knows the link-layer address of its default gateway.

Because the host has the router's information, it can immediately transmit data to the Internet. However, the reverse is not true. The router does not automatically know the host's link-layer address.

The Core Issue: A host knows how to reach its router before the router necessarily knows how to reach the host.

The "First-Packet Gap" Explained

When the remote destination responds to the host's initial request, the return packet hits the first-hop router. If the router lacks a Neighbour Cache entry for that specific host, it cannot forward the packet immediately.

Instead, the router must pause and perform Neighbour Discovery (ND):

• It sends a Neighbour Solicitation (NS).
• It waits for a Neighbour Advertisement (NA).

This means the very first return packet is stuck in the "critical path" of address resolution. This can lead to:

• $\Delta t_{latency} = \text{Processing Time} + \text{Round Trip of NS/NA}$
• Potential packet drops if timers expire.
• Noticeable lag for the end-user application.

Packet Flow Comparison

---

Introducing GRAND: Proactive Discovery

GRAND (Gratuitous Neighbour Discovery) flips the script. Instead of waiting for the router to ask "Who is this address?", the host proactively announces itself.

Reactive Discovery $\rightarrow$ Proactive Announcement

By sending an unsolicited Neighbour Advertisement, the host populates the router's cache before the first return packet even arrives.

Comparison: Reactive vs. Proactive

---

Engineering GRAND within RFC 4861

Implementing GRAND isn't as simple as blasting an NA packet. It must adhere to the strict guidelines of RFC 4861 to avoid destabilizing the network.

Technical Constraints and Nuances

The implementation must account for several complex scenarios:

• Multiple Addresses: An interface might have hundreds of addresses; sending them all at once could cause a "multicast storm."
• Anycast & Proxy Addresses: These require special handling because multiple nodes might claim the same address.

According to RFC 4861 rules 7.2.7 and 7.2.8, anycast or proxy responses must incorporate a random delay. This prevents simultaneous transmissions from colliding.

/* Conceptual logic for GRAND transmission */
if (address_is_newly_configured) {
    if (is_anycast_or_proxy(addr)) {
        schedule_delayed_na(addr, random_delay());
    } else {
        send_unsolicited_na(addr);
    }
}

---

The FreeBSD Implementation Journey

To bring GRAND to FreeBSD, the author discovered that the existing networking stack lacked the necessary machinery for scheduled, delayed transmissions.

Implementation Checklist:

• Develop queueing infrastructure for NA packets.
• Implement delayed-transmission logic for RFC compliance.
• Integrate unsolicited NA triggers upon address configuration.
• Ensure spacing between advertisements for multi-address interfaces.

By building this infrastructure, the host can now manage the timing of its announcements, ensuring that the router is informed efficiently without congesting the local link.