Site-Local Addresses⏎ In IPv4, it's common to use RFC 1918 private address ranges (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16) for internal communication. The idea was to take private addresses to the next level in IPv6 by introducing the "scope" mechanism. We've already discussed addresses with link-local scope. Because those are only valid on an individual subnet, they can be reused on other subnets without real problems. Site-local addresses are supposed to work in a similar vein: they are only used within an individual "site" so that other sites can reuse the same address range. But can router vendors make that a router that connects to two different sites, manages to keep packets from site A in site A, and packets from site B in site B, even though both sites use the same addresses? This would require hacks such as using different routing tables, depending on the interface a packet was received on. For link-local addresses, this isn't a problem, because packets with those addresses are never forwarded by a router: they flow directly from the source to the destination over the local link; so there is never any real ambiguity. Experience with RFC 1918 addresses has also uncovered other problems, such as packets with private addresses leaking into the global network, where they can't be traced back to the source (to fix the leak) because of their ambiguity. And, when two large organizations that both use private addresses merge, their addresses plans often clash, requiring inconvenient renumbering efforts.⏎ Then there is the problem that the word "site" is ill defined: does it mean the entire network for an organization, possibly spanning multiple locations? The network for the part of an organization in one location? The "inside" network, the DMZ, or both? What happens when direct connectivity between two parts of a "site" breaks so packets have to travel offsite to reach the other part? A narrow interpretation of the word "site" doesn't provide the functionality that users require, while a broad interpretation leads to all kinds of implementation issues.⏎ For all of these reasons, the IETF decided to deprecate the existing site-local specification in RFC 3879. Existing implementations and deployments may continue to use site-local addresses in the address range fec0::/10, but the special behavior associated with site-locals should be removed in future versions of router and host implementations.⏎ Despite problems outlined in this section, site-local addressing has a number of legitimate uses that aren't easily transferred to other types of addresses. Two examples are networks that aren't connected to the Internet at all and networks that have only intermittent connectivity.⏎ For instance, an airplane would very likely connect to a network when it's at the terminal so that maintenance personnel can connect to the various on-board systems. When the plane is in the air, it will generally not have connectivity for these types of systems (even though there are some carriers that provide Internet connectivity to passengers during the flight).⏎ To accommodate these needs, the IETF is in the process of defining a new type of sitelocal addresses: "unique local IPv6 unicast addresses." The idea is that this address type is still local, but it's also globally unique. This means that routers, hosts, and applications can treat them like regular global scope addresses.⏎ Figure 4-6 shows the format of these addresses. The prefix is fc00::/7. The local bit indicates whether the global ID was randomly generated (L = 1) or registered through a registry (L = 0), which may be possible in the future. The 40-bit global ID is large enough to make accidental collisions rate, but they may still happen on occasion. A collision is the situation where two organizations pick the same unique local prefix.⏎ In IPv4, it's common practice that all hosts have private addresses that are translated into global addresses at the network border. Due to lack of NAT, this setup is hard to implement in IPv6: the alternative is to use proxies, but these aren't available for all protocols. An alternative is to give all hosts both private/local and public/global addresses. But unless hosts implement advanced source address selection (see Chapter 8), they may try to connect to a global destination address by using a local source address, which won't work. To avoid the reverse, where a host tries to contact a far away server by its local address, it's recommended to keep these addresses out of the DNS (they shouldn't appear in either AAAA or PTR records). Because, obviously, using the addresses means having them in the DNS, this effectively means the IETF is mandating the practice of "two-faced DNS," where a DNS server gives a different reply based on the address of the host performing the query.🏁

Submitted by Dasha - 11/14/2025

Site-Local Addresses⏎ In IPv4, it's common to use RFC 1918 private address ranges (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16) for internal communication. The idea was to take private addresses to the next level in IPv6 by introducing the "scope" mechanism. We've already discussed addresses with link-local scope. Because those are only valid on an individual subnet, they can be reused on other subnets without real problems. Site-local addresses are supposed to work in a similar vein: they are only used within an individual "site" so that other sites can reuse the same address range. But can router vendors make that a router that connects to two different sites, manages to keep packets from site A in site A, and packets from site B in site B, even though both sites use the same addresses? This would require hacks such as using different routing tables, depending on the interface a packet was received on. For link-local addresses, this isn't a problem, because packets with those addresses are never forwarded by a router: they flow directly from the source to the destination over the local link; so there is never any real ambiguity. Experience with RFC 1918 addresses has also uncovered other problems, such as packets with private addresses leaking into the global network, where they can't be traced back to the source (to fix the leak) because of their ambiguity. And, when two large organizations that both use private addresses merge, their addresses plans often clash, requiring inconvenient renumbering efforts.⏎ Then there is the problem that the word "site" is ill defined: does it mean the entire network for an organization, possibly spanning multiple locations? The network for the part of an organization in one location? The "inside" network, the DMZ, or both? What happens when direct connectivity between two parts of a "site" breaks so packets have to travel offsite to reach the other part? A narrow interpretation of the word "site" doesn't provide the functionality that users require, while a broad interpretation leads to all kinds of implementation issues.⏎ For all of these reasons, the IETF decided to deprecate the existing site-local specification in RFC 3879. Existing implementations and deployments may continue to use site-local addresses in the address range fec0::/10, but the special behavior associated with site-locals should be removed in future versions of router and host implementations.⏎ Despite problems outlined in this section, site-local addressing has a number of legitimate uses that aren't easily transferred to other types of addresses. Two examples are networks that aren't connected to the Internet at all and networks that have only intermittent connectivity.⏎ For instance, an airplane would very likely connect to a network when it's at the terminal so that maintenance personnel can connect to the various on-board systems. When the plane is in the air, it will generally not have connectivity for these types of systems (even though there are some carriers that provide Internet connectivity to passengers during the flight).⏎ To accommodate these needs, the IETF is in the process of defining a new type of sitelocal addresses: "unique local IPv6 unicast addresses." The idea is that this address type is still local, but it's also globally unique. This means that routers, hosts, and applications can treat them like regular global scope addresses.⏎ Figure 4-6 shows the format of these addresses. The prefix is fc00::/7. The local bit indicates whether the global ID was randomly generated (L = 1) or registered through a registry (L = 0), which may be possible in the future. The 40-bit global ID is large enough to make accidental collisions rate, but they may still happen on occasion. A collision is the situation where two organizations pick the same unique local prefix.⏎ In IPv4, it's common practice that all hosts have private addresses that are translated into global addresses at the network border. Due to lack of NAT, this setup is hard to implement in IPv6: the alternative is to use proxies, but these aren't available for all protocols. An alternative is to give all hosts both private/local and public/global addresses. But unless hosts implement advanced source address selection (see Chapter 8), they may try to connect to a global destination address by using a local source address, which won't work. To avoid the reverse, where a host tries to contact a far away server by its local address, it's recommended to keep these addresses out of the DNS (they shouldn't appear in either AAAA or PTR records). Because, obviously, using the addresses means having them in the DNS, this effectively means the IETF is mandating the practice of "two-faced DNS," where a DNS server gives a different reply based on the address of the host performing the query.🏁

Submitted by Dasha - 11/14/2025