Pangram verdict · v3.3
We believe that this text is a mix of AI and human-written content.
AI likelihood · overall
AIArticle text · 937 words · 4 segments analyzed
There is a subtle asymmetry in IPv6 Neighbour Discovery: a host knows how to reach its router before the router necessarily knows how to reach the host. GRAND fixes that asymmetry by making the host proactively advertise its address, and I implemented that mechanism in FreeBSD. A device joins an IPv6 network, receives a Router Advertisement, configures a new IPv6 address, and immediately starts communicating with the Internet.From the host's perspective, everything is ready. It knows the link-layer address of its default router, so it can immediately send packets towards the Internet.However, from the router's perspective, things may look different. The router may not yet know how to reach the host's newly configured global IPv6 address.This creates a subtle asymmetry in IPv6 Neighbour Discovery: the host can already reach the router, while the router may have to perform Neighbour Discovery before it can forward traffic back to the host.The first IPv6 packet has a problemConsider a host that has just configured a new IPv6 address.The host sends a packet towards an off-link destination. The first-hop router receives the packet and forwards it normally. When the remote destination responds, however, the return packet arrives at the router with the host as its destination.The router may not have a Neighbour Cache entry for that IPv6 address, so it has to resolve the host's link-layer address before it can forward the packet. This puts Neighbour Discovery directly in the critical path of the first return packet.For a mechanism that is normally invisible to applications, this can have a visible effect: the first packets of a connection may experience additional latency, or potentially be dropped while address resolution is in progress.The problem is particularly interesting because the host already has all the information the router needs. The host knows that it owns the IPv6 address and knows the corresponding link-layer address, but the router simply hasn't learned it yet.Why does Neighbour Discovery cause this?IPv6 Neighbour Discovery is reactive in this situation. When a node needs to communicate with a neighbour for which it does not have a usable Neighbour Cache entry, it starts address resolution by sending a Neighbour Solicitation and waiting for a Neighbour Advertisement.This works well for established neighbours. The problem appears during the transition from "the address has just become usable" to "the rest of the network knows how to reach it". So, again, the host already knows its IPv6 address and link-layer address while the first-hop router may have no information about the host until traffic arrives.This is the gap that GRAND addresses.GRAND: changing reactive Neighbour Discovery into proactive informationGratuitous Neighbour Discovery changes the direction of information flow so that instead of waiting for the router to discover the host when the first packet arrives, the host proactively announces its IPv6 address and link-layer address using an unsolicited Neighbour Advertisement.The router can then learn this information before it needs to forward traffic towards the host. This is the central idea behind RFC 9131.But implementing GRAND is not simply a matter of sending an unsolicited Neighbour Advertisement whenever an address appears. GRAND interacts with several existing Neighbour Discovery rules, including the handling of multiple addresses, anycast and proxy addresses, timing, and Duplicate Address Detection.Building GRAND on RFC 4861An important part of implementing GRAND is understanding that unsolicited Neighbour Advertisements already have a defined role in Neighbour Discovery.RFC 4861 rule 7.2.6 specifies behaviour for unsolicited Neighbour Advertisements, including cases such as changes to a node's link-layer address.
It also limits how many advertisements a node can send for multiple addresses and recommends spacing those advertisements to avoid unnecessary congestion.RFC 4861 rules 7.2.7 and 7.2.8 cover the special case of anycast and proxy Neighbour Advertisements.
In these situations, multiple nodes may potentially respond to the same Neighbour Solicitation. If they all transmitted immediately, their purpose becomes ineffective.To address this, RFC 4861 specifies a random delay before sending an anycast or proxy Neighbour Advertisement. This gives multiple potential responders a chance to avoid transmitting simultaneously.These timing rules are an important part of the overall design of Neighbour Discovery: making information available quickly is useful, but doing so without creating a multicast storm is equally important.My implementation adds these behaviours as part of the GRAND work rather than relying on pre-existing queueing and delayed-NA infrastructure.GRAND and delayed Neighbour AdvertisementsOne of the less obvious parts of GRAND is therefore the scheduling of Neighbour Advertisements.
That's where I decided to implement missing RFC 4861 parts.The existing implementation did not previously provide the queueing and delayed-transmission machinery needed for these behaviours. Implementing GRAND required adding that infrastructure and then using it to schedule unsolicited Neighbour Advertisements.In GRAND, a newly configured address may result in an unsolicited Neighbour Advertisement, but the implementation must consider how many addresses are being advertised and when each advertisement should be transmitted. In IPv6, an interface might have hundreds of addresses at the same time.Sending all advertisements immediately could create an unnecessary burst. For example, consider a datacentre after power is restored, causing many servers to start at once. So the implementation therefore adds the delayed advertisement behaviour described by RFC 4861 7.2.6 and the randomised response behaviour described in 7.2.7 and 7.2.8.This is particularly relevant for anycast and proxy addresses, where more than one node may be capable of responding.The goal is not simply to minimise the time before an advertisement is sent. It is to balance fast neighbour discovery with the amount of multicast traffic generated by that discovery.What does RFC 9131 actually change?RFC 9131 builds on these Neighbour Discovery mechanisms to address the first-packet problem.A host sends an unsolicited Neighbour Advertisement when a new IPv6 address becomes usable.