Join the IPv6 Army

On networks providing IPv4-IPv6 translation (RFC 7915), hosts and other endpoints need to know the IPv6 prefix(es) used for translation (the NAT64 prefix (RFC 6052)). This document provides guidelines for NAT64 prefix discovery, specifically recommending obtaining the NAT64 prefix from the Router Advertisement option (RFC 8781) when available.

Returning with more IPv6 basics, we dive deep into that often overlooked and frequently ignored address family - link-local addresses. Link-local addresses are unicast addresses used for addressing on a single link. The intent of link-local addresses is to let devices that may not have a router or global unicast address allocation mechanism still be able to communicate on a network segment. On today’s show we dig into how link-local addresses work, what to do with them, potential issues with link-local addresses, and more.

An often overlooked dimension of data collection is flow data from hosts. This is not a new concept, there have been tools built for this for a very long time, but in many cases, and especially over the last 8-10 years, many system engineers have gravitated toward tooling like grafana and prometheus. While these are fine tools and if done well provide an excellent view of host health, they aren’t really a full picture of host behavior.

RFC7050 describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation (RFC7915). This methodology depends on the existence of a well-known IPv4-only fully qualified domain name "ipv4only.arpa.". Because newer methods exist that lack the requirement of a higher level protocol, instead using existing operations in the form of native router advertisements, discovery of the IPv6 prefix used for protocol translation using RFC7050 should be discouraged. RFC7050 MAY only be used if other methods (such as RFC8781]) can not be used.