Visual RFC.
ALL RFCs / RFC 8106
Read the RFC ↗

RFC 8106 / START HERE

IPv6 DNS advertisements, before the details

IPv6 is Internet Protocol version 6. RA means Router Advertisement; DNS means Domain Name System. These RA options tell a host which recursive DNS servers and search suffixes it can use.

A router can advertise DNS server IPv6 addresses and a DNS search list on its link. The host keeps that configuration for its own lifetime, then makes separate DNS queries when it needs an answer.

The idea in one picture

  1. Advertise DNS information

  2. Keep scoped configuration

  3. Make a later DNS query

A simplified picture of the idea; the chapters explain the actual mechanisms.

Why it exists

This March 2017 Proposed Standard replaces RFC 6106. It raises the recommended default DNS-option lifetime for lossy links and clarifies processing, link-local scope, source preference and security limits.

A familiar example

Imagine a welcome desk giving you a directory service’s address and a suggested neighborhood to search. That is contact information, not an answer or proof the desk is trustworthy; it can also expire or be withdrawn.

Helpful background

You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.

What you’ll learn next

Begin with chapter one, or choose a topic.

  1. Carry DNS configuration in Router AdvertisementsLearning how to contact a resolver is separate from getting an IPv6 address or a DNS answer.
  2. Decode RDNSS addresses and keep their link scopeType 25 carries whole 128-bit addresses and a shared lifetime; a link-local address also needs its link.
  3. Encode search suffixes without DNS compressionType 31 concatenates zero-terminated domain names and zero padding; the suffix is not itself an answer.
  4. Refresh and withdraw DNS data using its own lifetimeReceipt-relative DNS lifetimes survive router-lifetime expiry and require synchronized removal from both repositories.
  5. Merge sources without mistaking configuration for trustAn ordered resolver list needs source-aware preference, while well-formed advertisements can still be malicious.
Start with chapter one →

This introduction explains RFC 8106 (2017). Read the original RFC ↗