RFC 3879

Okay bestie, let's get into RFC 3879 🎀 It's called Deprecating Site Local Addresses and it was written by C. Huitema (Microsoft) and B. Carpenter (IBM) in September 2004. It's on the Standards Track, so it's a real protocol spec and not just vibes ✨ The title block doesn't list anything it obsoletes or updates, so it's a solo act 💅

Status of This Memo

Okay so this doc is an Internet standards track protocol for the whole Internet community, and it literally asks for discussion and suggestions for improvements 🦋 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 Distribution of this memo is unlimited, so share it with everyone 💖

Copyright Notice

Copyright (C) The Internet Society (2004) 🌸

Abstract

Okay, the main tea ☕ This document looks at the problems with using IPv6 site-local unicast addresses in their original form, and it formally deprecates them 😭 Deprecating them doesn't stop people from using them while a replacement is still being standardized and implemented. So they still work for now, no panic 🫶

1. Introduction ✨

For a while now, the IPv6 working group has been debating a bunch of issues with "site local" addresses 🧠 In its meeting in March 2003, the group reached a measure of agreement that these issues were serious enough to warrant a replacement of site local addresses in their original form. The consensus was far from unanimous, lowkey messy, but in its meeting in July 2003 the working group confirmed the need to document these issues and the decision to deprecate IPv6 site-local unicast addresses 🎀

Site-local addresses are defined in the IPv6 addressing architecture [RFC3513], especially in section 2.5.6 📖

The rest of this document describes the adverse effects of site-local addresses under that definition, and then formally deprecates them 💅

Companion documents will describe the goals of a replacement solution and specify that replacement. But the formal deprecation lets existing usage of site-local addresses keep going until the replacement is standardized and implemented 🦋

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. Read these as the real deal 🔥

2. Adverse Effects of Site Local Addresses 💀

The IPv6 working group talked through several defects of the current site local addressing scope. They fall into two big buckets: ambiguity of addresses, and a fuzzy definition of sites 🙈

As currently defined, site local addresses are ambiguous. An address like FEC0::1 can show up in multiple sites, and the address itself doesn't tell you which site it belongs to. That creates pain for application developers, for router designers, and for network managers 😭 It gets worse because the concept of a site is fuzzy too. We'll dig into the specific pain in the next sections ✨

2.1. Developer Pain, Scope Identifiers

Early feedback from developers says site local addresses are hard to use correctly in an application. This is especially true for multi-homed hosts, which can be connected to multiple sites at the same time, and for mobile hosts, which can be connected to multiple sites one after another 🧳

Here's how it goes: applications learn or remember that a correspondent's address is FEC0::1234:5678:9ABC. They try to put that address in a socket address structure and issue a connect, and the call fails. Why? Because they didn't fill in the "site identifier" variable, so it should have been FEC0::1234:5678:9ABC%1. (The use of the % character as a delimiter for zone identifiers is specified in [SCOPING].) It gets even messier because the site identifier changes with the host instantiation. Sometimes it's %1 and sometimes it's %2, so the host identifier can't just be remembered in memory or learned from a name server 🤯

So the developer pain comes from the ambiguity of site local addresses. Since they're ambiguous, application developers have to manage the "site identifiers" that qualify the addresses of hosts. That management has proven hard for developers to understand, and hard to execute even for the developers who do understand the concept 😩

2.2. Developer Pain, Local Addresses

Simple client/server applications that share IP addresses at the application layer get more complicated with IPv6 site-local addressing 🫠 These applications have to make smart decisions about which addresses should and shouldn't cross site boundaries. In practice, those decisions require the applications to know something about the network topology. Site local addresses can be used when the client and server are in the same site. But trying to use them when the client and server are in different sites may give you unexpected errors (i.e., connection reset by peer) or connections to the wrong node 💔 How robust or secure it is to send packets to an unexpected end-point depends on the application.

Multi-party applications that pass IP addresses at the application layer are an even bigger challenge 😵 Even if a node can correctly tell whether one remote node is in the local site, it has no way of knowing where those addresses might eventually be sent. The best move for these applications might be to use only global addresses. But that would stop them from working on isolated or intermittently connected networks that only have site-local addresses available. It might also clash with using site-local addresses for access control in some cases 🔒

In summary, the ambiguity of site local addresses leads to unexpected application behavior when application payloads carry these addresses outside the local site 🚨

2.3. Manager Pain, Leaks

Managing IPv6 site local addresses is in lots of ways like managing RFC 1918 [RFC1918] addresses in some IPv4 networks 🍓 In theory, the private addresses defined in RFC 1918 should only be used locally and should never appear on the Internet. In practice, they "leak" 🫣 Leaks plus ambiguity equals management problems.

Names and literal addresses of "private" hosts leak into mail messages, web pages, or files. Private addresses also end up as the source or destination of TCP requests or UDP messages, like in DNS or trace-route requests. That makes the request fail, or sends the response to unsuspecting hosts 👀

The experience with RFC 1918 addresses also shows some non-trivial leaks, beyond just putting these addresses in IP headers. Private addresses also end up as targets of reverse DNS queries for RFC 1918, which uselessly overloads the DNS infrastructure 😤 In general, lots of applications use IP addresses directly and end up passing RFC 1918 addresses in application payloads, which creates confusion and failures.

The leakage issue is mostly unavoidable. Some applications are intrinsically scoped (e.g., Router Advertisement, Neighbor Discovery), but most applications have no concept of scope and no way of expressing it. So, as they say, "stuff leaks across the borders" 🙃 Since the addresses are ambiguous, network managers can't easily find out "who did it". Leaks are hard to fix, which means a lot of frustration 😮‍💨

2.4. Router Pain, Increased Complexity

The ambiguity of site local addresses also makes things complicated for routers 🖥️ In theory, site local addresses are only used within a contiguous site, and all routers in that site can treat them as if they weren't ambiguous. In practice, special mechanisms are needed when sites are disjoint, or when routers have to handle several sites 🧩

In theory, sites should never be disjoint. In practice, if site local addressing is used throughout a large network, some parts of the site won't be directly connected, for example because of network partitioning. That creates a demand to route site-local packets across some intermediate network (such as the backbone area) that can't be dedicated to one specific site. In practice, this leads to heavy use of tunneling techniques, or multi-sited routers, or both 🚇

Ambiguous addresses have pretty obvious consequences for multi-sited routers. In classic router architecture, the exit interface is a direct function of the destination address, as specified by a single routing table. But if a router is connected to multiple sites, routing of site local packets depends on the interface the packet arrived on. Interfaces have to be associated with sites, and the routing entries for site local addresses are site-dependent. Supporting this needs special provisions in routing protocols, and techniques for routing and forwarding table virtualization that are normally used for VPNs. All of this adds complexity to router implementation and management 😵‍💫

Network management complexity also goes up, because even though sites could be supported using existing routing constructs (such as domains and areas), the factors driving the creation and boundaries of sites are different from the factors driving those of areas and domains 📐

In multi-homed routers, like site border routers, the forwarding process should be complemented by a filtering process. That guarantees that packets sourced with a site local address never leave the site. This filtering process then interacts with packet forwarding, for example if implementation defects cause packets sent to a global address to be dropped, even if that global address happens to belong to the target site 🛑

In summary, the ambiguity of site local addresses makes them hard to manage in multi-sited routers, while the need to support disjoint sites and existing routing protocol constructs creates demand for those routers 💜

2.5. Site is an Ill-Defined Concept ✨

Okay so the original idea of scopes is basically a set of concentric circles 🎯. Hosts live on a link, the link lives in a site, and the site lives on the Internet. A packet can go to the same link, the same site, or somewhere outside that site. Sounds neat, right? But experts have been fighting about what a "site" even is for years and still haven't agreed 💀. Maybe there's no consensus because there's nothing to agree on 🙈.

Apart from link-local, the scope boundaries are super fuzzy. What counts as a site? Is a whole corporate network one site, or is each physical office its own site? And what about a DMZ, the in-between zone with a firewall, where servers are supposedly reachable by both internal hosts and the outside Internet? Does the DMZ belong to the same site as the internal hosts? Bestie, I have no idea 😭.

It gets worse. Depending on who you ask, the site scope might be about security boundaries, reachability boundaries, routing boundaries, QoS boundaries, administrative boundaries, funding boundaries, some other kind of boundary, or a mix of all of these 🌀. It's very unclear that one single scope could possibly satisfy every single one of those needs.

There are also a bunch of well-known scope-breaking situations 🧨: intermittently connected networks, mobile nodes, mobile networks, inter-domain VPNs, hosted networks, network merges and splits, and so on. So the scope thing cannot be squished into neat concentric circles like a simple link/local/global model 💔. Scopes overlap and bleed into each other, and the scope relationship between two hosts might even be different depending on which protocol you're using. Iconic chaos, honestly 🌪️.

In summary, the current idea of a site is naive, and it doesn't match what networks actually need in real life 🙃.

3. Development of a Better Alternative ✨

The last section was all about why site-local addresses are problematic 💅. But obviously site-locals have some perks, or they would've been removed from the spec way back. The good stuff is that they're simple, stable, and private 🫶. Here's the plot twist: it seems those same benefits can be had with a different architecture, like the one in [Hinden/Haberman], where addresses are not ambiguous and don't have a simple explicit scope 🦋.

Non-ambiguous addresses fix a big chunk of the developer pain 🌸, because developers don't have to manage site identifiers anymore. Apps can just use the addresses like regular global ones, and the stack can use standard techniques to figure out which interface to use. Some pain sticks around, since these addresses won't always be reachable. But apps can handle that by trying again later or by trying a different address 🔁. Speculatively, a more sophisticated scope mechanism might show up later on 👀.

Non-ambiguous addresses won't magically stop the leaks that cause management pain 😤. BUT, since the addresses aren't ambiguous, debugging those leaks will be way simpler 🔍.

Non-ambiguous addresses also solve a large part of the router issues 🛣️. Since the addresses aren't ambiguous, routers can use standard routing techniques and won't need a separate routing table for each interface. A bit of pain remains at border routers, which will need to filter packets from some ranges of source addresses. That's a pretty common job though, so it's fine 💁‍♀️.

Dropping the explicit scope declaration gets rid of the problems tied to the fuzzy site concept 🧹. Non-reachability can be achieved with "firewalls" where they make sense. The firewall rules can account for all kinds of network setups by accepting or refusing traffic to and from ranges of the new non-ambiguous addresses 🧱.

There's one question still hanging around: anycast addressing 🤔. Anycast addresses are ambiguous by design, since by definition they refer to any host that's been assigned a given anycast address. Link-local or global anycast addresses can be "baked in the code." Further study is needed on whether anycast addresses with a scope between link-local and global are actually needed 🔬.

4. Deprecation 🪦

This document formally deprecates the IPv6 site-local unicast prefix defined in [RFC3513], which is 1111111011 in binary or FEC0::/10 💀. The special behavior of this prefix MUST no longer be supported in new implementations. The prefix MUST NOT be reassigned for other use except by a future IETF standards action. Future versions of the addressing architecture [RFC3513] will include this info 📚.

Router implementations SHOULD be configured to prevent routing of this prefix by default. 🚧

The references to site-local addresses should be removed as soon as practical from the revision of the Default Address Selection for Internet Protocol version 6 [RFC3484], the revision of the Basic Socket Interface Extensions for IPv6 [RFC3493], and from the revision of the Internet Protocol Version 6 (IPv6) Addressing Architecture [RFC3513]. Incidental references to site-local addresses should be removed from other IETF documents if and when they get updated. Those other documents include [RFC2772, RFC2894, RFC3082, RFC3111, RFC3142, RFC3177, and RFC3316] 🧹.

Existing implementations and deployments MAY continue to use this prefix. No drama, you're allowed to keep using it 🫶.

5. Security Considerations 🔐

Bestie, this part is serious 😤. Using ambiguous site-local addresses can seriously hurt network security through leaks, ambiguity, and potential misrouting, as covered in section 2. Deprecating ambiguous addresses helps solve a lot of these problems 🛡️.

The site-local unicast prefix lets people block stuff in firewall rules and address selection rules, and that's commonly seen as a security feature because it stops packets from crossing administrative boundaries 🧱. Those blocking rules can be set up for any prefix, including the expected future replacement for the site-local prefix. If these blocking rules are actually enforced, then deprecating the site-local prefix does not endanger security ✅. Phew 😮‍💨.

6. IANA Considerations 📋

IANA is requested to mark the FEC0::/10 prefix as "deprecated," pointing to this document. Reassigning the prefix for any usage requires justification via an IETF Standards Action [RFC2434] 🗂️.

7. Acknowledgements 🫶

The authors would like to thank Fred Templin, Peter Bieringer, Chirayu Patel, Pekka Savola, and Alain Baudot for reviewing the initial version of the document 💖. The text of section 2.2 includes 2 paragraphs taken from a version by Margaret Wasserman describing the impact of site-local addressing 🌷. Alain Durand pointed out the need to revise existing RFCs that reference site-local addresses 📝.

8. References 📚

8.1. Normative References

[RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2434]         Narten, T. and H. Alvestrand, "Guidelines for
                  Writing an IANA Considerations Section in RFCs",
                  BCP 26, RFC 2434, October 1998.

[RFC3513]         Hinden, R. and S. Deering, "Internet Protocol
                  Version 6 (IPv6) Addressing Architecture", RFC
                  3513, April 2003.

8.2. Informative References

[RFC1918]         Rekhter, Y., Moskowitz, B., Karrenberg, D., de
                  Groot, G., and E. Lear, "Address Allocation for
                  Private Internets", BCP 5, RFC 1918, February 1996.

[RFC2772]         Rockell, R. and R. Fink, "6Bone Backbone Routing
                  Guidelines", RFC 2772, February 2000.

[RFC2894]         Crawford, M., "Router Renumbering for IPv6", RFC
                  2894, August 2000.

[RFC3082]         Kempf, J. and J. Goldschmidt, "Notification and
                  Subscription for SLP", RFC 3082, March 2001.

[RFC3111]         Guttman, E., "Service Location Protocol
                  Modifications for IPv6", RFC 3111, May 2001.

[RFC3142]         Hagino, J. and K. Yamamoto, "An IPv6-to-IPv4
                  Transport Relay Translator", RFC 3142, June 2001.

[RFC3177]         IAB and IESG, "IAB/IESG Recommendations on IPv6
                  Address", RFC 3177, September 2001.

[RFC3316]         Arkko, J., Kuijpers, G., Soliman, H., Loughney, J.,
                  and J. Wiljakka, "Internet Protocol Version 6
                  (IPv6) for Some Second and Third Generation
                  Cellular Hosts", RFC 3316, April 2003.

[RFC3484]         Draves, R., "Default Address Selection for Internet
                  Protocol version 6 (IPv6)", RFC 3484, February
                  2003.

[RFC3493]         Gilligan, R., Thomson, S., Bound, J., McCann, J.,
                  and W. Stevens, "Basic Socket Interface Extensions
                  for IPv6", RFC 3493, February 2003.

[Hinden/Haberman] Hinden, R. and B. Haberman, "Unique Local IPv6
                  Unicast Addresses", Work in Progress, June 2004.

[SCOPING]         Deering, S., Haberman, B., Jinmei, T., Nordmark,
                  E., and B. Zill, "IPv6 Scoped Address
                  Architecture", Work in Progress, August 2004.

9. Authors' Addresses 🖊️

Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
USA

EMail: huitema@microsoft.com


Brian Carpenter
IBM Corporation
Sauemerstrasse 4
8803 Rueschlikon
Switzerland

EMail: brc@zurich.ibm.com

10. Full Copyright Statement ©️

Copyright (C) The Internet Society (2004).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🧾

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available, and it does not represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 📬

Acknowledgement ✨

okay bestie, last bit 🎀 the RFC Editor function is currently funded by the Internet Society 🌈 so yes, that's who keeps the lights on for the RFC Editor right now 💖 that's the whole note, no cap 🫶