RFC 4085

Embedding Globally-Routable Internet Addresses Considered Harmful

📅 published June 2005, from ietf

RFC 4085: Embedding Globally-Routable Internet Addresses Considered Harmful 💅🎀

Okay bestie, here's the title block tea ☕. This one is from the Global Routing Operations area (Network Working Group), written by D. Plonka at the University of Wisconsin 🦋. It's dated June 2005 and it's a Best Current Practice (BCP 105) 💜. The title block doesn't list anything it obsoletes or updates, so this one is standing on its own ✨.

Status of This Memo 📜

This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. 🌸

Copyright (C) The Internet Society (2005). 🫶

Abstract ✨

Okay so this doc is basically saying "please stop hard-coding globally-routable IP addresses into Internet hosts" 🙅‍♀️. It explains why that's a problem, goes over some alternatives, and is meant to clarify current best practices on the topic 💖.

Table of Contents 🗂️

   1. Introduction ....................................................2
   2. Problems ........................................................2
   3. Recommendations .................................................4
      3.1. Disable Unused Features ....................................4
      3.2. Provide User Interface for IP Features .....................4
      3.3. Use Domain Names as Service Identifiers ....................4
      3.4. Use Special-Purpose, Reserved IP Addresses When Available ..5
      3.5. Discover and Utilize Local Services ........................6
      3.6. Avoid Mentioning the IP Addresses of Services ..............6
   4. Security Considerations .........................................6
   5. Conclusion ......................................................7
   6. Acknowledgements ................................................7
   7. References ......................................................7
   Appendix A.  Background ............................................9

1. Introduction 🧚

So some vendors of consumer electronics and network gear have, unfortunately, decided to embed (or "hard-code") globally-routable Internet Protocol addresses right into their products' firmware 😭. These baked-in addresses are usually individual server IP addresses or IP subnet prefixes. Sometimes they act as service identifiers, which unsolicited requests get sent to, and other times they act as subnet identifiers, marking a set of Internet addresses that the product somehow treats as special 👀.

One recent example is the embedding of the globally-routable IP address of a Network Time Protocol server in the firmware of hundreds of thousands of Internet hosts now running around the world 🌍. These hosts are mostly, but not necessarily, low-cost routers and middleboxes for personal or residential use 🏠. In another case, IP address prefixes that had once been reserved by the Internet Assigned Numbers Authority (IANA) were embedded in a router product, so it could automatically discard packets that seemed to have invalid source IP addresses 🗑️.

This kind of "hard-coding" of globally-routable IP addresses as identifiers inside a host's firmware causes real problems for how the Internet runs and for how its address space gets managed 💀.

Originally this practice was an attempt to make IP host configuration simpler by pre-loading hosts with IP addresses 🙈. Products that depend on these embedded addresses might look super convenient to the designer, and to whoever operates or uses the product, but that shiny benefit comes at the expense of everyone else in the Internet community 😤.

This document calls out the practice of embedding references to unique, globally-routable IP addresses in Internet hosts, describes some of the resulting problems, and considers selected alternatives 📣. It also reminds the community that unique, globally-routable IP addresses are ephemeral: assigning and using IP addresses as identifiers is temporary, so they shouldn't be used in fixed configurations 🦋.

2. Problems 🥀

Embedding IP addresses in products has led to more and more Internet hosts relying on one single central Internet service 📈. When that aggregate workload gets too much for the service, you get an outage 😱. When fixed addresses get embedded in more and more client IP hosts, this practice goes directly against the design intent of hierarchically deployed services, which would otherwise be robust solutions 💅.

The reliability, scalability, and performance of many Internet services depend on the pool of users not accessing a service using its IP address directly 🔑. Instead, users typically rely on a layer of indirection from the Domain Name System, described in RFC 2219 [6] 🧠. When it's used properly, the DNS lets the service operator reconfigure resources for maintenance and do load balancing, without the users getting involved and without any configuration changes needed in the client hosts 🙌. For example, one common load-balancing technique puts multiple DNS records under the same name, and the set of answers returned gets rotated in a round-robin fashion across successive queries 🔄. When a resolver gets a response like that, it typically tries the answers in order until one succeeds 🎯. This lets the operator spread user request load across a set of servers with discrete IP addresses that mostly stay hidden from the user 🫶.

Embedding globally-unique IP addresses taints the IP address blocks they live in, which lowers how useful and mobile those blocks are and raises the cost of running them 😩. Unsolicited traffic can keep showing up at an embedded address long after that address or block has been reassigned and no longer hosts the service the traffic was meant for 👻. Way back around 1997, the authors of RFC 2101 [7] made this observation:

      Due to dynamic address allocation and increasingly frequent
      network renumbering, temporal uniqueness of IPv4 addresses is no
      longer globally guaranteed, which puts their use as identifiers
      into severe question.

When IP addresses get embedded in the configuration of lots of Internet hosts, the address blocks become weighed down by their history 🪨. That can get in the way of the Internet Assigned Numbers Authority (IANA) and the Internet Registry (IR) hierarchy reallocating address blocks in a useful way 🙃. Similarly, to make IP address reuse easier, RFC 2050 [1] encourages Internet Service Providers (ISPs) to treat address assignments as "loans" 🤝.

Consumers aren't necessarily experienced with running Internet hosts, so we can't count on them to fix problems when those problems show up 🤷‍♀️. That's why the manufacturer or vendor of an Internet host has a big responsibility to avoid embedding IP addresses in ways that cause the problems described above 👑.

3. Recommendations 🎀

Internet host and router designers, including network product manufacturers, shouldn't assume their products will only be deployed and used on the single global Internet they happen to see today 🌐. Lots of private or future internetworks may use these products, and in those places the hosts might not be able to talk to arbitrary hosts on the global Internet 🚧. Since the ways a product can fail in an unknown future internetwork can't all be explored, you should avoid assuming our current Internet will last forever ⏳.

The following recommendations are presented as best practice today 📌.

3.1. Disable Unused Features 🙅‍♀️

Vendors should, by default, disable unnecessary features in their products 🔒. This matters especially for features that generate unsolicited Internet traffic 🚫. That way, these hosts stay conservative about the unsolicited Internet traffic they produce 🌱. For instance, one of the most common uses of embedded IP addresses has been hard-coding the addresses of well-known public Simple Network Time Protocol (SNTP, RFC 2030 [8]) servers into products 🕰️. But only a small fraction of users will actually benefit from these products knowing the current date and time 🤏.

3.2. Provide User Interface for IP Features 🖥️

Vendors should provide an operator interface for every feature that generates unsolicited Internet traffic 💻. A prime example: the Domain Name System resolver should have an interface that lets the operator either explicitly set the choice of servers or enable a standard automated configuration protocol like DHCP, which is defined by RFC 2132 [9] ⚙️. These features should start out disabled in the operator interface, and turning them on should alert the operator that the feature exists 🚨. This makes it more likely that the product's owner or operator can take part in problem determination and mitigation when problems come up 🛠️.

RFC 2606 [2] defines the IANA-reserved "example.com", "example.net", and "example.org" domains for use in example configurations and documentation 📖. These are good candidates to use in user interface documentation 💅.

3.3. Use Domain Names as Service Identifiers 🏷️

Internet hosts should use the Domain Name System to figure out the IP addresses associated with the Internet services they need 🗺️.

When you use domain names as service identifiers in the configurations of deployed Internet hosts, designers and vendors are encouraged to introduce service names ✨. These names should sit within a domain they either control or are allowed to use under an agreement with its operator (like for public services provided by the Internet community) 🤝. This is commonly done by adding a service-specific prefix to the domain name 🎀.

For instance, a vendor named "Example, Inc." with the domain "example.com" might configure its product to find its SNTP server by the name sntp-server.config.example.com, or even by a name specific to the product and version, like sntp-server.v1.widget.config.example.com 🧁. Here the config.example.com namespace is dedicated to that vendor's product configuration, with subdomains added as needed 🗂️. Special-purpose domain names like these make ongoing maintenance and reconfiguration of services for their client hosts possible, and they can help measure service usage over the product's whole lifetime 📊.

An alternative to inventing vendor-specific domain naming conventions for a product's service identifiers is to use SRV resource records (RRs), defined by RFC 2782 [10] 🧩. SRV records are a generic type of RR that combines a service-specific prefix with a base domain name 🧱. For example, an SRV-aware SNTP client might discover Example, Inc.'s suggested NTP server by doing an SRV-type query for _ntp._udp.example.com 🔍.

Heads up though: just hard-coding DNS names as service identifiers instead of IP addresses is not a panacea 🚩. Entries in the domain name space are ephemeral too, and they can change owners for all sorts of reasons, including acquisitions and litigation ⚖️. So developers and vendors should explore a product's potential failure modes that result from losing administrative control of a given domain, for whatever reason 💀.

3.4. Use Special-Purpose, Reserved IP Addresses When Available 🎀

Okay bestie, default configs, documentation, and example configs for Internet hosts SHOULD use addresses from special reserved blocks instead of unique, globally-routable IP addresses 💅. For IPv4, RFC 3330 [3] says the 192.0.2.0/24 block has been assigned for documentation and example code 📚. The IPv6 global unicast prefix 2001:DB8::/32 got the same treatment for documentation purposes, per RFC 3849 [4] 🌸. And Private Internet Addresses, as defined by RFC 1918 [5], SHOULD NOT be used for those purposes 🙈.

3.5. Discover and Utilize Local Services 🧚

Service providers and enterprise network operators SHOULD advertise the identities of suitable local services, like NTP ⏰. Literally so many of these services exist, but nobody advertises them or automates how to use them 😤. The DHCP protocol, as defined by RFC 2132 [9], lets you set up a server to answer client queries for service identifiers, which is so useful 🫶. When local services (NTP included) are around but not widely advertised through common protocols like that, designers are more likely to ship ad hoc initialization mechanisms that unnecessarily rely on central services 💀.

3.6. Avoid Mentioning the IP Addresses of Services 🙅‍♀️

Operators who provide public services on the global Internet, like those in the NTP community, SHOULD deprecate the explicit advertisement of the IP addresses of public services 📢. These addresses are ephemeral, aka they can change 🦋. So if they're cited all over public service indexes, it gets in the way of reconfiguring the service when needed to handle unexpected, increased traffic and the aforementioned problems 😭.

4. Security Considerations 🔐

Okay, this part is serious, so hear me out 🫣. Embedding or "hard-coding" IP addresses in a host's configuration often means a host-based trust model is being used, and the Internet host at that address is trusted in some way. Because globally-routable IP addresses have ephemeral roles, putting them in products' firmware or default configurations is a real security risk, since unknown parties may be trusted by accident 🚨.

Internet host designers might also be tempted to build some kind of remote control mechanism into a product 👀. That would let its Internet host configuration change without reliance on, interaction with, or even the knowledge of its operator or user, and that raises security issues of its own. If such a scheme is implemented, its presence SHOULD be fully disclosed to the customer, operator, and user, so an informed decision can be made, perhaps in accordance with local security or privacy policy 📝. Also, the significant possibility of malicious parties exploiting such a remote control mechanism may completely negate any potential benefit of it ☠️. Therefore, remote control mechanisms SHOULD be disabled by default, to be subsequently enabled and disabled by the user 🛑.

5. Conclusion 🎓

When large numbers of homogeneous Internet hosts are deployed, it's super important that both their designers and the wider Internet community diligently assess host implementation quality and reconfigurability 🧐.

Implementors of host services SHOULD avoid any kind of use of unique globally-routable IP addresses within a fixed configuration part of the service implementation 🙅. If there's a requirement for pre-configured state, care SHOULD be taken to use an appropriate service identifier and standard mechanisms for dynamically resolving that identifier into an IP address 🪄. Also, any such identifiers SHOULD be alterable in the field through a conventional command and control interface for the service 🎛️.

6. Acknowledgements 💜

The author thanks the following reviewers for their contributions to this document: Paul Barford, Geoff Huston, David Meyer, Mike O'Connor, Michael Patton, Tom Petch, and Pekka Savola. Harald Alvestrand, Spencer Dawkins, Ted Hardie, David Kessens, and Thomas Narten provided valuable feedback during AD and IESG review 🙌.

7. References 📚

7.1. Normative References

  • [1] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and J. Postel, "Internet Registry IP Allocation Guidelines", BCP 12, RFC 2050, November 1996.
  • [2] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
  • [3] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
  • [4] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, July 2004.
  • [5] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.

7.2. Informative References

  • [6] Hamilton, M. and R. Wright, "Use of DNS Aliases for Network Services", BCP 17, RFC 2219, October 1997.
  • [7] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
  • [8] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996.
  • [9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
  • [10] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
  • [11] Plonka, D., "Flawed Routers Flood University of Wisconsin Internet Time Server", August 2003. http://www.cs.wisc.edu/~plonka/netgear-sntp/

Appendix A. Background 🕵️

In May 2003, the University of Wisconsin discovered that a network product vendor named NetGear had manufactured and shipped over 700,000 routers with firmware containing a hard-coded reference to the IP address of one of the University's NTP servers: 128.105.39.11, which was also known as "ntp1.cs.wisc.edu", a public stratum-2 NTP server.

Due to that embedded fixed configuration and an unrelated bug in the SNTP client, the affected products occasionally exhibit a failure mode in which each flawed router produces one query per second destined for the IP address 128.105.39.11. That hence produces a large scale flood of Internet traffic from hundreds of thousands of source addresses, destined for the University's network, resulting in significant operational problems 😩.

These flawed routers are widely deployed throughout the global Internet and are likely to remain in use for years to come. As such, the University of Wisconsin, with the cooperation of NetGear, will build a new anycast time service that aims to mitigate the damage caused by the misbehavior of these flawed routers 🛠️.

A technical report regarding the details of this situation is available on the world wide web: Flawed Routers Flood University of Wisconsin Internet Time Server [11].

Author's Address 📮

David Plonka
University of Wisconsin - Madison

EMail: plonka@doit.wisc.edu
URI:   http://net.doit.wisc.edu/~plonka/

Copyright (C) The Internet Society (2005).

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/SHE 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. Nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC 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 💖

Funding for the RFC Editor function is currently provided by the Internet Society. ✨

📦 where this page comes from