draft-ietf-grow-embed-addr-04.txt   draft-ietf-grow-embed-addr-05.txt 
Global Routing Operations D. Plonka Global Routing Operations D. Plonka
Internet-Draft University of Wisconsin Internet-Draft University of Wisconsin
Expires: April 22, 2005 October 22, 2004 Expires: May 24, 2005 November 23, 2004
Embedding Globally Routable Internet Addresses Considered Harmful Embedding Globally Routable Internet Addresses Considered Harmful
draft-ietf-grow-embed-addr-04 draft-ietf-grow-embed-addr-05
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 35 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 22, 2005. This Internet-Draft will expire on May 24, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2004).
Abstract Abstract
This document means to clarify best current practices in the Internet This document means to clarify best current practices in the Internet
community. Internet hosts should not contain globally routable community. Internet hosts should not contain globally routable
Internet Protocol addresses embedded within firmware or elsewhere as Internet Protocol addresses embedded within firmware or elsewhere as
part of their default configuration such that it influences run-time part of their default configuration such that it influences run-time
behavior. behavior.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 5 3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Disable Unused Features . . . . . . . . . . . . . . . . . 6 3.1 Disable Unused Features . . . . . . . . . . . . . . . . . 5
3.2 Provide User Interface for IP Features . . . . . . . . . . 6 3.2 Provide User Interface for IP Features . . . . . . . . . . 5
3.3 Use Domain Names as Service Identifiers . . . . . . . . . 6 3.3 Use Domain Names as Service Identifiers . . . . . . . . . 5
3.4 Use Special-Purpose, Reserved IP Addresses When 3.4 Use Special-Purpose, Reserved IP Addresses When
Available . . . . . . . . . . . . . . . . . . . . . . . . 7 Available . . . . . . . . . . . . . . . . . . . . . . . . 6
3.5 Discover and Utilize Local Services . . . . . . . . . . . 7 3.5 Discover and Utilize Local Services . . . . . . . . . . . 6
3.6 Avoid Mentioning the IP Addresses of Services . . . . . . 8 3.6 Avoid Mentioning the IP Addresses of Services . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 8
8.2 Informative References . . . . . . . . . . . . . . . . . . . 9 8.2 Informative References . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9
A. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 10 A. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 10
Revision History
RFC-EDITOR: PLEASE REMOVE REVISION HISTORY BEFORE PUBLICATION. The
following is the recent revision history of this document
$Log: draft-ietf-grow-embed-addr.xml,v $
Revision 1.19 2004/10/22 16:08:17 plonka
edits based on initial IESG evaluation for BCP:
* fixed a typo reported by Spencer Dawkins
* reworded the introduction as suggested by Ted Hardie to make it clear that
the document is about service identifiers used by the device, not the host
IP address it uses as a client of those services
* improved recommendation to use DNS names based on comments by Harald
Alvestrand, Steve Bellovin, and Pekka Savola
* under Security Considerations, strengthened the opposition to ad hoc remote
control mechanisms by mentioned that they should be able to be disabled,
based on comment by Russ Housley
* used the term "mobility" rather than "portability" and "networks"
rather than "internets" based on comment by Thomas Narten.
Revision 1.18 2004/10/21 20:24:35 plonka
changed from full RFC2026 to RFC3667 compliance
used compact as suggested by Pekka Savola
added table of contents and sortrefs
added headings and subsections for specific recommendations
added example of how domain names might be used, based on suggestion by
Pekka Savola
added reference to RFC3849 now that it's available (re: IPv6 documentation
prefix)
other minor edits
Figure 1
1. Introduction 1. Introduction
Vendors of consumer electronics and network gear have unfortunately Vendors of consumer electronics and network gear have unfortunately
chosen to embed, or "hard-code", globally routable Internet Protocol chosen to embed, or "hard-code", globally routable Internet Protocol
addresses within their products' firmware. These products use these addresses within their products' firmware. These products use these
embedded IP addresses as service identifiers and direct service embedded IP addresses as service identifiers and direct service
requests (unsolicited Internet traffic) to them. One recent example requests (unsolicited Internet traffic) to them. One recent example
was the embedding of the globally routable IP address of a Network was the embedding of the globally routable IP address of a Network
Time Protocol server in the firmware of hundreds of thousands of Time Protocol server in the firmware of hundreds of thousands of
skipping to change at page 7, line 19 skipping to change at page 6, line 19
version-specific name such as version-specific name such as
"sntp-server.v1.widget.config.example.com". Here, the "sntp-server.v1.widget.config.example.com". Here, the
"config.example.com" namespace is dedicated to that vendor's product "config.example.com" namespace is dedicated to that vendor's product
configuration, with sub-domains introduced as deemed necessary. Such configuration, with sub-domains introduced as deemed necessary. Such
special-purpose domain names enable ongoing maintenance and special-purpose domain names enable ongoing maintenance and
reconfiguration of the services for their client hosts and can aid in reconfiguration of the services for their client hosts and can aid in
the ongoing measurement of service usage throughout the product's the ongoing measurement of service usage throughout the product's
lifetime. lifetime.
An alternative to inventing vendor-specific domain naming conventions An alternative to inventing vendor-specific domain naming conventions
for a product's service identifiers is to utilize SVR resource for a product's service identifiers is to utilize SRV resource
records (RR), defined by RFC 2782 [10]. SRV records are a generic records (RR), defined by RFC 2782 [10]. SRV records are a generic
type of RR which uses a service-specific prefix in combination with a type of RR which uses a service-specific prefix in combination with a
base domain name. For example, an SVR-cognizant SNTP client might base domain name. For example, an SRV-cognizant SNTP client might
discover Example, Inc.'s suggested NTP server by performing an discover Example, Inc.'s suggested NTP server by performing an
SVR-type query to lookup for "_ntp._udp.example.com". SRV-type query to lookup for "_ntp._udp.example.com".
However, note that simply hard-coding DNS name service identifiers However, note that simply hard-coding DNS name service identifiers
rather than IP addresses is not a panacea. Entries in the domain rather than IP addresses is not a panacea. Entries in the domain
name space are also ephemeral and can change owners for various name space are also ephemeral and can change owners for various
reasons including acquisitions and litigation. As such, developers reasons including acquisitions and litigation. As such, developers
and vendors should explore a product's potential failure modes and vendors should explore a product's potential failure modes
resulting from the loss of administrative control of a given domain resulting from the loss of administrative control of a given domain
for whatever reason. for whatever reason.
3.4 Use Special-Purpose, Reserved IP Addresses When Available 3.4 Use Special-Purpose, Reserved IP Addresses When Available
skipping to change at page 9, line 20 skipping to change at page 8, line 20
pre-configured state then care should be taken to use an appropriate pre-configured state then care should be taken to use an appropriate
service identifier and use standard resolution mechanisms to service identifier and use standard resolution mechanisms to
dynamically resolve the identifier into an IP address. Also, any dynamically resolve the identifier into an IP address. Also, any
such identifiers should be alterable in the field through a such identifiers should be alterable in the field through a
conventional command and control interface for the service. conventional command and control interface for the service.
7. Acknowledgements 7. Acknowledgements
The author thanks the following reviewers for their contributions to The author thanks the following reviewers for their contributions to
this document: Paul Barford, Geoff Huston, David Meyer, Mike this document: Paul Barford, Geoff Huston, David Meyer, Mike
O'Connor, Michael Patton, Tom Petch, and Pekka Savola. O'Connor, Michael Patton, Tom Petch, and Pekka Savola. Harald
Alvestrand, Spencer Dawkins, Ted Hardie, and Thomas Narten provided
valuable feedback during AD and IESG review.
8. References 8. References
8.1 Normative References 8.1 Normative References
[1] Hubbard, K., "INTERNET REGISTRY IP ALLOCATION GUIDELINES", RFC [1] Hubbard, K., "INTERNET REGISTRY IP ALLOCATION GUIDELINES", RFC
2050, BCP 12, November 1996. 2050, BCP 12, November 1996.
[2] Eastlake, D., "Reserved Top Level DNS Names", RFC 2606, BCP 32, [2] Eastlake, D., "Reserved Top Level DNS Names", RFC 2606, BCP 32,
June 1999. June 1999.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/