IPv6 in Practice - A Unixer's Guide to the Next Generation Internet

16 More on Addresses (p. 211)

Chapter 3 provided all the information necessary to get IPv6 up and running. But there is more to IPv6 addresses than we have seen to far. This chapter covers a number of not so essential aspects concerning IPv6 addresses as such.

16.1 Site-local and Unique-local Addresses

In section 3.4.2 we introduced site-local and unique-local unicast addresses. Until now they haven’t been particularly exciting, but they are quite useful as a fallback during network renumberings.

16.1.1 From Site-local to Unique-local Addresses

Originally, the IPv6 address architecture standards (RFCs 1884 (61), 2373 (62) and 3513 (63)) de.ned the address range fec0::/10 as "site-local" unicast addresses. They were similar to the private IPv4 addresses defined in RFC 1918 (97) (10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/24) and anybody was free to use them for internal purposes as long as they were only used inside a local network cloud.

Experience has shown that this approach introduces a number of problems. RFC 3879 (71) pointed out two core causes: Address ambiguity, or multiple machines using the same address, and an ill-de.ned concept of "site". Problems related to the "site" concept are mostly a matter of interpretation of the term "site" in a particular context.

But even if your network might be considered a "site" by whatever definition, the more serious problems related to the ambiguity of addresses remain. Some of them, like the trouble of setting up "multi-sited routers", can be trivially solved by not using site-local addresses for inter-site or global purposes—like NAT in the IPv4 world.

But site-local addresses that leak into dynamic routing tables and the DNS are more serious. To solve these problems it was necessary to make even private addresses unique. Discussions sprang up to devise an address range for private purposes where addresses were not ambiguous, they just wouldn’t be globally routed.

Originally, it was planned to use the fc00::/8 address range to assign /48 prefixes by a central authority and fd00::/8 to pick random /48 pre.xes without central management, thus making them unique only by probabilistic standards. Eventually, RFC 4193 (66) de.ned the fd00::/8 prefix accordingly.

Until now, there has been neither an o.cial standard nor a central management authority for the fc00::/8 address range. RFC 4291 (64), the successor of RFC 3513, formally declares the old site-local prefix fec0::/10 obsolete.

Throughout this book, we call both site-local and unique-local addresses site-scoped addresses. So what exactly is the difference between the old fec0::/10 and the new fd00::/8 prefix?