idnits 2.17.1 draft-plonka-embed-addr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 19, 2003) is 7496 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2050 (ref. '3') (Obsoleted by RFC 7020) ** Obsolete normative reference: RFC 2030 (ref. '4') (Obsoleted by RFC 4330) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Plonka 3 Internet-Draft University of Wisconsin 4 Expires: April 18, 2004 October 19, 2003 6 Embedding Globally Routable Internet Addresses Considered Harmful 7 draft-plonka-embed-addr-00 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on April 18, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 Vendors of consumer electronics and network gear have produced and 38 sold hundreds of thousands of Internet hosts with globally routable 39 Internet Protocol addresses embedded within their products' firmware. 40 These products are now in operation world-wide and primarily include, 41 but are not necessarily limited to, low-cost routers and middleboxes 42 for personal or residential use. 44 This "hard-coding" of globally routable IP addresses within the 45 host's firmware presents significant problems to the operation of the 46 Internet and to the management of its address space. 48 This document means to clarify best current practices in the Internet 49 community. It denouces the practice of embedding references to 50 unique, globally routable IP addresses in Internet hosts, describes 51 some of the resulting problems, and considers selected alternatives. 52 It is also intended to remind the Internet community of the ephemeral 53 nature of unique, globally routable IP addresses and that the 54 assignment and use of such addresses is temporary and therefore 55 should not be used in fixed configurations. 57 1. Introduction 59 Internet hosts should not contain globally routable Internet Protocol 60 addresses embedded within firmware or elsewhere as part of their 61 default configuration influencing their run-time behavior. 63 Ostensibly, this practice arose as an attempt to implement of "zero 64 configuration" with neither peer review nor the use of a proposed or 65 standard Internet protocol to do so. Unfortunately, products which 66 rely on such embedded IP addresses initially may appear convenient to 67 both the product's designer and its operator or user, but this 68 dubious benefit comes at the expense of others in the Internet 69 community. 71 2. Problems 73 In a number cases, the embedding of IP addresses has caused Internet 74 products to rely on a single central Internet service, which can 75 result in a collapse when the aggregate workload overwhelms that 76 service. When fixed addresses are embedded in an ever-increasing 77 number of client IP hosts, this practice runs directly counter to the 78 design intent of hierarchically deployed services that would 79 otherwise be robust solutions. 81 The reliability, scalability, and performance of many Internet 82 services require that the pool of users not directly access a service 83 by IP address. Instead they rely on a level of indirection provided 84 by the DNS, RFC 2219 [2]. DNS permits the service operator to 85 reconfigure the resources for maintenance and load-balancing without 86 the participation of the users. For instance, a load-balancing 87 technique in common use today employs multiple DNS records with the 88 same name which are then doled out in a round-robin fashion by the 89 Berkeley Internet Name Daemon (BIND) and other DNS server 90 implementations. This enables the operator to distribute the user 91 request load across a set of servers with discrete IP addresses, 92 which generally remain unknown to the user. 94 Furthermore, embedding globally unique IP addresses taints the IP 95 address blocks in which they reside, lessening the usefulness and 96 portability of those IP address blocks and increasing the cost of 97 operation. Unsolicited traffic may continue to be delivered to the 98 embedded addresses for historical reasons, even after the IP address 99 or block has been reassigned. IP address blocks containing addresses 100 that have been embedded into the configuration of many Internet hosts 101 become encumbered by their historical use. This may interfere with 102 the ability of the Internet Assigned Numbers Authority (IANA) and the 103 Internet Registry (IR) hierarchy to usefully reallocate IP address 104 blocks. This is of particular concern as the IPv4 address space nears 105 exhaustion. Note that, to facilitate IP address reuse, RFC 2050 [3], 106 encourages Internet Service Providers (ISPs) to treat address 107 assignments as "loans". 109 Because consumers are not necessarily capable, experienced operators 110 of Internet hosts, they are not able to be relied upon to implement a 111 fix if and when problems arise. As such, a significant 112 responsibility lies with the manufacturer or vendor of the Internet 113 host to avoid embedding IP addresses. 115 3. Recommendations 117 Network product manufacturers should not assume that their products 118 will only be deployed on a single (mythical) global Internet, that 119 they happen to observe today. A myriad of private internets in which 120 these products will be used will often not allow these hosts to 121 establish end-to-end communications with arbitrary hosts on the 122 global Internet. 124 Vendors should, by default, disable unnecessary features in their 125 products. This is especially true of features that generate 126 unsolicited traffic. In this way these hosts will be conservative 127 regarding the unsolicited Internet traffic they produce. For 128 instance, one of the most common uses of embedded IP addresses has 129 been the hard-coding of addresses of well know public Simple Network 130 Time Protocol (SNTP RFC 2030 [4]) servers, even though only a small 131 fraction of the users benefits from these products even having some 132 notion of the current date and time. 134 Vendors should provide an operator interface for every feature that 135 generates unsolicited IP traffic. Non-default configuration should 136 be required to enable these features so that, as a consequence, the 137 operator becomes aware that the feature exists. This will mean that 138 it is more likely that the product's owner or operator can 139 participate in problem determination and mitigation if and when 140 problems arise. 142 Internet hosts should use the Domain Name System to determine the 143 routable IP addresses associated with the Internet services they 144 require. However, note that simply hard-coding DNS names rather than 145 IP addresses is not a panacea. Entries in the domain name space are 146 also ephemeral and can change owners for various reasons including 147 such as acquisitions and litigation. A given vendor ought not assume 148 that it will retain control of a given zone indefinitely. 150 Whenever possible, default configurations, documentation, and example 151 configurations for Internet hosts should use Private Internet 152 Addresses, as defined by RFC 1918 [1], rather than unique, globally 153 routable IP addresses. 155 Service providers and enterprise network operators should advertise 156 the identities of suitable local services. For instance, the DHCP 157 protocol, as defined by RFC 2132 [5], enables one to configure a 158 server to answer queries regarding available servers to clients that 159 ask for them. Unless the advertisement of local services is 160 ubiquitous, designers may resort to ad hoc mechanisms which rely on 161 central services. 163 Operators that provide public services on the global Internet, such 164 as the the NTP community, should deprecate the advertisement of the 165 explicit IP addresses of public services. These addresses are 166 ephemeral, and their widespread citations in indexes of public 167 services interferes with these services to be reconfigured to scale 168 with unexpected, increased load. 170 4. Security Considerations 172 Embedding or "hard-coding" IP addresses within a host's configuration 173 almost always means that some sort of host-based trust model is being 174 employed, and that the Internet host with the given address is 175 trusted in some way. Due to the ephemeral roles of routable IP 176 addresses, the practice of embedding them within products' firmware 177 or default configurations presents a security risk. 179 An Internet host designer may be tempted to implement some sort of 180 remote control mechanism within a product, by which its Internet host 181 configuration can be changed without reliance on, interaction with, 182 or even the knowledge of its operator or user. This raises security 183 issues of its own. If such a scheme is implemented, this should be 184 fully disclosed to the customer, operator, and user so that an 185 informed decision can be made, in accordance with local security or 186 privacy policy. Furthermore, the significant possibility of 187 malicious parties exploiting such a remote control mechanism may 188 completely negate any potential benefit of the remote control scheme. 190 5. Conclusion 192 As larger number of homogenous hosts continue to be deployed, it is 193 particularly important that both designers and other members of the 194 Internet community are diligent in assessing host implementation 195 quality and reconfigurability. Unique, globally routable IP 196 addresses should not be embedded within a host's fixed configuration 197 because doing so excludes the ability to remotely influence hosts 198 when the unsolicited traffic they generate causes problems for the 199 for those operating the IP addresses to which the traffic is 200 destined. 202 References 204 [1] Rekhter, Y., "Address Allocation for Private Internets", RFC 205 1918, BCP 5, February 1996. 207 [2] Hamilton, M., "Use of DNS Aliases for Network Services", RFC 208 2219, BCP 17, October 1997. 210 [3] Hubbard, K., "INTERNET REGISTRY IP ALLOCATION GUIDELINES", RFC 211 2050, BCP 12, November 1996. 213 [4] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for 214 IPv4, IPv6 and OSI", RFC 2030, October 1996. 216 [5] Alexander, S., "DHCP Options and BOOTP Vendor Extensions", RFC 217 2132, March 1997. 219 Author's Address 221 David J. Plonka 222 University of Wisconsin - Madison 223 DoIT, room b263 224 1210 W. Dayton Street 225 Madison, WI 53705 226 US 228 Phone: +1 608 265 5184 229 EMail: plonka@doit.wisc.edu 230 URI: http://net.doit.wisc.edu/~plonka/ 232 Intellectual Property Statement 234 The IETF takes no position regarding the validity or scope of any 235 intellectual property or other rights that might be claimed to 236 pertain to the implementation or use of the technology described in 237 this document or the extent to which any license under such rights 238 might or might not be available; neither does it represent that it 239 has made any effort to identify any such rights. Information on the 240 IETF's procedures with respect to rights in standards-track and 241 standards-related documentation can be found in BCP-11. Copies of 242 claims of rights made available for publication and any assurances of 243 licenses to be made available, or the result of an attempt made to 244 obtain a general license or permission for the use of such 245 proprietary rights by implementors or users of this specification can 246 be obtained from the IETF Secretariat. 248 The IETF invites any interested party to bring to its attention any 249 copyrights, patents or patent applications, or other proprietary 250 rights which may cover technology that may be required to practice 251 this standard. Please address the information to the IETF Executive 252 Director. 254 Full Copyright Statement 256 Copyright (C) The Internet Society (2003). All Rights Reserved. 258 This document and translations of it may be copied and furnished to 259 others, and derivative works that comment on or otherwise explain it 260 or assist in its implementation may be prepared, copied, published 261 and distributed, in whole or in part, without restriction of any 262 kind, provided that the above copyright notice and this paragraph are 263 included on all such copies and derivative works. However, this 264 document itself may not be modified in any way, such as by removing 265 the copyright notice or references to the Internet Society or other 266 Internet organizations, except as needed for the purpose of 267 developing Internet standards in which case the procedures for 268 copyrights defined in the Internet Standards process must be 269 followed, or as required to translate it into languages other than 270 English. 272 The limited permissions granted above are perpetual and will not be 273 revoked by the Internet Society or its successors or assignees. 275 This document and the information contained herein is provided on an 276 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 277 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 278 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 279 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 280 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 282 Acknowledgment 284 Funding for the RFC Editor function is currently provided by the 285 Internet Society.