doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc6866.txt b/doc/rfc/rfc6866.txt
new file mode 100644
index 0000000..75cd085
--- /dev/null
+++ b/doc/rfc/rfc6866.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      B. Carpenter
+Request for Comments: 6866                             Univ. of Auckland
+Category: Informational                                         S. Jiang
+ISSN: 2070-1721                            Huawei Technologies Co., Ltd.
+                                                           February 2013
+
+
+              Problem Statement for Renumbering IPv6 Hosts
+              with Static Addresses in Enterprise Networks
+
+Abstract
+
+   This document analyses the problems of updating the IPv6 addresses of
+   hosts in enterprise networks that, for operational reasons, require
+   static addresses.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6866.
+
+Copyright Notice
+
+   Copyright (c) 2013 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+Carpenter & Jiang             Informational                     [Page 1]
+
+RFC 6866              Renumbering Static Addresses         February 2013
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Analysis ........................................................3
+      2.1. Static Addresses Imply Static Prefixes .....................3
+      2.2. Other Hosts Need Literal Address ...........................4
+      2.3. Static Server Addresses ....................................5
+      2.4. Static Virtual Machine Addresses ...........................6
+      2.5. Asset Management and Security Tracing ......................6
+      2.6. Primitive Software Licensing ...............................7
+      2.7. Network Elements ...........................................7
+      2.8. Access Control Lists .......................................7
+      2.9. Management Aspects .........................................8
+   3. Summary of Problem Statement ....................................8
+   4. Security Considerations .........................................9
+   5. Acknowledgements ...............................................10
+   6. Informative References .........................................10
+
+1.  Introduction
+
+   A problem that is frequently mentioned in discussions of renumbering
+   enterprise networks [RFC5887] [RFC6879] [GAP-ANALYSIS] is that of
+   statically assigned addresses.  The scope of the present document is
+   to analyse the problems caused for enterprise networks during
+   renumbering by static addresses and to identify related gaps in
+   existing technology.  Some aspects also apply to small office and
+   home networks, but these are not the intended scope of the document.
+
+   A static address can be defined as an IP address that is intended by
+   the network manager to remain constant over a long period of time,
+   possibly many years, regardless of system restarts or any other
+   unpredictable events.  Static addressing often implies manual address
+   assignment, including manual preparation of configuration scripts.
+   An implication of hosts having static addresses is that subnets must
+   have static prefixes, which also requires analysis.
+
+   In a sense, the issue of static addresses is a result of history.  As
+   discussed in Section 3.2 of [RFC6250], various properties of IP
+   addresses that have long been assumed by programmers and operators
+   are no longer true today, although they were true when almost all
+   addresses were manually assigned.  In some cases, the resulting
+   operational difficulties are avoided by static addressing.
+
+   Although static addressing is, in general, problematic for
+   renumbering, hosts inside an enterprise may have static addresses for
+   a number of operational reasons:
+
+
+
+
+
+Carpenter & Jiang             Informational                     [Page 2]
+
+RFC 6866              Renumbering Static Addresses         February 2013
+
+
+   o  For some reason, other hosts need to be configured with a literal
+      numeric address for the host in question, so its address must be
+      static.
+
+   o  Even if a site has local DNS support and this is normally used to
+      locate servers, some operators wish their servers to have static
+      addresses so that issues of address lifetime and DNS Time to Live
+      (TTL) cannot affect connectivity.
+
+   o  Some approaches to virtual server farms require static addressing.
+
+   o  On some sites, the network operations staff require hosts to have
+      static addresses for asset management purposes and for address-
+      based backtracking of security incidents.
+
+   o  Certain software licensing mechanisms are based on IP addresses.
+
+   o  Network elements, such as routers, are usually assigned static
+      addresses, which are also configured into network monitoring and
+      management systems.
+
+   o  Access Control Lists and other security mechanisms are often
+      configured using IP addresses.
+
+   Static addressing is not the same thing as manual addressing.  Static
+   addresses may be configured automatically, for example, by stateful
+   DHCPv6.  In that case, the database from which the static address is
+   derived may itself have been created automatically in some fashion,
+   or configured manually.  If a host's address is configured manually
+   by the host's administrator, it is by definition static.
+
+   This document analyses these issues in more detail and presents a
+   problem statement.  Where obvious alternatives to static addresses
+   exist, they are mentioned.
+
+2.  Analysis
+
+2.1.  Static Addresses Imply Static Prefixes
+
+   Host addresses can only be static if subnet prefixes are also static.
+   Static prefixes are such a long-established practice in enterprise
+   networks that it is hard to discern the reason for them.  Originally,
+   before DHCP became available, there was simply no alternative.  Thus
+   it became accepted practice to assign subnet prefixes manually and
+   build them into static router configurations.  Today, the static
+   nature of subnet prefixes has become a diagnostic tool in itself, at
+
+
+
+
+
+Carpenter & Jiang             Informational                     [Page 3]
+
+RFC 6866              Renumbering Static Addresses         February 2013
+
+
+   least in the case of IPv4 where prefixes can easily be memorised.  If
+   several users sharing a subnet prefix report problems, the fault can
+   readily be localised.
+
+   This model is being challenged for the case of unmanaged home IPv6
+   networks, in which it is possible to assign subnet prefixes
+   automatically, at least in a cold start scenario [PREFIX].  For an
+   enterprise network, the question arises whether automatic subnet
+   prefix assignment can be made using the "without a flag day" approach
+   to renumbering.  [RFC4192] specifies that "the new prefix is added to
+   the network infrastructure in parallel with (and without interfering
+   with) the old prefix".  Any method for automatic prefix assignment
+   needs to support this.
+
+2.2.  Other Hosts Need Literal Address
+
+   This issue commonly arises in small networks without local DNS
+   support, for devices such as printers, that all other hosts need to
+   reach.  In this case, not only does the host in question have a
+   static address but that address is also configured in the other
+   hosts.  It is a long-established practice in small IPv4 enterprise
+   networks that printers, in particular, are manually assigned a fixed
+   address (typically, an [RFC1918] address) and that users are told to
+   manually configure printer access using that fixed address.  For a
+   small network, the work involved in doing this is much less than the
+   work involved in doing it "properly" by setting up DNS service,
+   whether local or hosted by an ISP, to give the printer a name.  Also,
+   although the Service Location Protocol (SLP) [RFC2608] is widely
+   available for tasks such as printer discovery, it is not widely used
+   in enterprise networks.  In consequence, if the printer is renumbered
+   for any reason, the manual configuration of all users' hosts must be
+   updated in many enterprises.
+
+   In the case of IPv6, exactly the same situation would be created by
+   numbering the printer statically under the site's Unique Local
+   Address (ULA) prefix [RFC4193].  Although this address would not
+   change if the site's globally routable prefix is changed, internal
+   renumbering for any other reason would be troublesome.  Additionally,
+   the disadvantage compared to IPv4 is that an IPv6 address is harder
+   to communicate reliably, compared to something as simple as
+   "10.1.1.10".  The process will be significantly more error-prone for
+   IPv6.
+
+   If such a host is numbered out of a globally routable prefix that is
+   potentially subject to renumbering, then a renumbering event will
+   require a configuration change in all hosts using the device in
+   question, and such configuration data are by no means stored in the
+   network layer.
+
+
+
+Carpenter & Jiang             Informational                     [Page 4]
+
+RFC 6866              Renumbering Static Addresses         February 2013
+
+
+   At least two simple alternatives exist to avoid static numbering of
+   simple devices, such as printers, by giving them local names.  One is
+   the use of Multicast DNS (mDNS) [RFC6762] in combination with DNS
+   Service Discovery [RFC6763].  The other is the Service Location
+   Protocol [RFC2608].  Both of these solutions are widely implemented,
+   but seemingly not widely deployed in enterprise networks.
+
+2.3.  Static Server Addresses
+
+   On larger sites, it is safe to assume that servers of all kinds,
+   including printers, are identified in user configurations and
+   applications by DNS names.  However, it is very widespread
+   operational practice that servers have static IP addresses.  If they
+   did not, whenever an address assigned by stateless address
+   autoconfiguration [RFC4862] or DHCPv6 [RFC3315] expired, and if the
+   address actually changed for some extraneous reason, sessions in
+   progress might fail (depending on whether the address deprecation
+   period was long enough).
+
+   DNS aspects of renumbering are discussed in more detail in [RFC6879].
+   Here, we note that one reason for widespread use of static server
+   addresses is the lack of deployment of Secure Dynamic DNS update
+   [RFC3007], or some other method of prompt DNS updates, in enterprise
+   networks.  A separate issue is that even with such updates in place,
+   remote users of a server would attempt to use the wrong address until
+   the DNS TTL expired, as discussed in [RFC4192].
+
+   Server addresses can be managed centrally, even if they are static,
+   by using DHCPv6 in stateful mode to ensure that the same address is
+   always assigned to a given server.  Consistency with DNS can be
+   ensured by generating both DHCPv6 data and DNS data from a common
+   configuration database using a suitable configuration tool.  This
+   does normally carry the implication that the database also contains
+   the hardware (Media Access Control (MAC)) addresses of the relevant
+   LAN interfaces on the servers, so that the correct IPv6 address can
+   be delivered whenever a server requests an address.  Not every
+   operator wishes to maintain such a costly database, however, and some
+   sites are therefore likely today to fall back on manual configuration
+   of server addresses as a result.
+
+   In the event of renumbering the prefix covering such servers, the
+   situation should be manageable if there is a common configuration
+   database; the "without a flag day" procedure [RFC4192] could be
+   followed.  However, if there is no such database, a manual procedure
+   would have to be adopted.
+
+
+
+
+
+
+Carpenter & Jiang             Informational                     [Page 5]
+
+RFC 6866              Renumbering Static Addresses         February 2013
+
+
+2.4.  Static Virtual Machine Addresses
+
+   According to [PROBLEM], the placement and live migration of Virtual
+   Machines (VMs) in a physical network requires that their IP addresses
+   be fixed and static.  Otherwise, when a VM is migrated to a different
+   physical server, its IP address would change and transport sessions
+   in progress would be lost.  In effect, this is a special case of the
+   previous one.
+
+   If VMs are numbered out of a prefix that is subject to renumbering,
+   there is a direct conflict with application session continuity,
+   unless a procedure similar to [RFC4192] is followed.
+
+2.5.  Asset Management and Security Tracing
+
+   There are some large (campus-sized) sites that not only capture the
+   MAC addresses of servers in a configuration system, but also do so
+   for desktop client machines with wired connections that are then
+   given static IP addresses.  Such hosts are not normally servers, so
+   the two preceding cases do not apply.  One motivation for this
+   approach is straightforward asset management (Who has which
+   computer?, Connected to which cable?).  Another, more compelling,
+   reason is security incident handling.  If, as occurs with reasonable
+   frequency on any large network, a particular host is found to be
+   generating some form of unwanted traffic, it is urgent to be able to
+   track back from its IP address to its physical location so that an
+   appropriate intervention can be made.  A static binding between the
+   MAC address and the IPv6 address might be preferred for this purpose.
+
+   Such users will not, in most circumstances, be significantly
+   inconvenienced by prefix renumbering, as long as it follows the
+   [RFC4192] procedure.  The address deprecation mechanism would allow
+   for clean termination of current sessions, including those in which
+   their machine was actually operating as a server, e.g., for a peer-
+   to-peer application.  The only users who would be seriously affected
+   would be those running extremely long transport sessions that might
+   outlive the address deprecation period.
+
+   Note that such large campus sites generally allocate addresses
+   dynamically to wireless hosts, since (in an IPv4 world) addresses are
+   scarce and allocating static addresses to intermittent users is not
+   acceptable.  Also, a wireless user may appear on different subnets at
+   different times, so it cannot be given a single static address.
+   These users will, in most circumstances, only be slightly
+   inconvenienced, if at all, by prefix renumbering.
+
+
+
+
+
+
+Carpenter & Jiang             Informational                     [Page 6]
+
+RFC 6866              Renumbering Static Addresses         February 2013
+
+
+2.6.  Primitive Software Licensing
+
+   Although it has many disadvantages and cannot be recommended as a
+   solution, software licensing based on IP addresses or prefixes is
+   still quite widely used in various forms.  It is to be expected that
+   this practice will continue for IPv6.  If so, there is no alternative
+   to informing the licensing party of the new address(es) by whatever
+   administrative process is required.  In an RFC 4192 renumbering
+   procedure, the licenses for the old and new addresses or prefixes
+   would have to overlap.
+
+   If acceptable to the licensing mechanism, using addresses under an
+   enterprise's ULA prefix for software licensing would avoid this
+   problem.
+
+2.7.  Network Elements
+
+   Each interface of a router needs an IP address, and so do other
+   network elements, such as firewalls, proxies, and load balancers.
+   Since these are critical infrastructures, they must be monitored and
+   in some cases controlled by a network management system.  A
+   conventional approach to this is to assign the necessary IP addresses
+   statically, and to configure those addresses in the monitoring and
+   management systems.  It is common practice that some such addresses
+   will have no corresponding DNS entry.  If these addresses need to be
+   changed, there will be considerable ramifications.  A restart of the
+   network element might be needed, interrupting all user sessions in
+   progress.  Simultaneously, the monitoring and management system
+   configurations must be updated, and in the case of a default router,
+   its clients must be informed.  To avoid such disruption, network
+   elements must be renumbered according to an [RFC4192] procedure, like
+   any other host.
+
+   There is a school of thought that to minimise renumbering problems
+   for network elements and to keep the simplicity of static addressing
+   for them, network elements should all have static ULA addresses for
+   management and monitoring purposes, regardless of what other global
+   addresses they may have.
+
+2.8.  Access Control Lists
+
+   Access Control Lists (ACLs) and other security mechanisms are often
+   configured using static IP addresses.  This may occur in network
+   elements or hosts.  If they are not updated promptly during a
+   renumbering event, the result may be the opening of security
+   loopholes, the blocking of legitimate traffic, or both.  Such
+   security loopholes may never be detected until they are successfully
+   exploited.
+
+
+
+Carpenter & Jiang             Informational                     [Page 7]
+
+RFC 6866              Renumbering Static Addresses         February 2013
+
+
+2.9.  Management Aspects
+
+   As noted in the Introduction, static addressing and manual address
+   configuration are not the same thing.  In terms of managing a
+   renumbering event, static addressing derived automatically from a
+   central database, e.g., by stateful DHCPv6, is clearly better than
+   manual configuration by an administrator.  This remains true even if
+   the database itself requires manual changes, since, otherwise, an
+   administrator would have to log in to every host concerned, a time-
+   consuming and error-prone task.  In cases where static addresses
+   cannot be avoided, they could be assigned automatically from a
+   central database using a suitable protocol, such as stateful DHCPv6.
+   Clearly, the database needs to be supported by a suitable
+   configuration tool, to minimise manual updates and to eliminate
+   manual configuration of individual hosts.
+
+3.  Summary of Problem Statement
+
+   If subnet prefixes are statically assigned, various network elements
+   and the network management system must be updated when they are
+   renumbered.  To avoid loss of existing user sessions, the old
+   prefixes need to be removed only after a period of overlap.
+
+   If a printer or similar local server is statically addressed, and has
+   no DNS or mDNS name and no discovery protocol, renumbering will
+   require configuration changes in all hosts using that server.  Most
+   likely, these changes will be manual; therefore, this type of
+   configuration should be avoided except for very small networks.  Even
+   if the server is under a ULA prefix, any subnet rearrangement that
+   causes it to be renumbered will have the same effect.
+
+   If a server with a DNS name is statically addressed via a common
+   configuration database that supports both DHCPv6 and DNS, then it can
+   be renumbered "without a flag day" by following RFC 4192.  However,
+   if there is no common configuration database, then present technology
+   requires manual intervention.  Similar considerations apply to
+   virtual servers with static addresses.
+
+   If client computers, such as desktops, are statically addressed via a
+   common configuration database and stateful DHCPv6, they can also be
+   renumbered "without a flag day."  But other statically addressed
+   clients will need manual intervention, so DHCPv6 should be used if
+   possible.
+
+   If address-based software licensing is unavoidable, requiring static
+   addresses, and ULAs cannot be used for this case, an administrative
+   procedure during renumbering seems unavoidable.
+
+
+
+
+Carpenter & Jiang             Informational                     [Page 8]
+
+RFC 6866              Renumbering Static Addresses         February 2013
+
+
+   If network elements have static addresses, the network management
+   system and affected client hosts must be informed when they are
+   renumbered.  Even if a network element is under a ULA prefix, any
+   subnet rearrangement that causes it to be renumbered will have the
+   same effect.
+
+   ACLs configured with static addresses must be updated during
+   renumbering.
+
+   It appears that the majority of the above problems can be largely
+   mitigated if the following measures are taken:
+
+   1.  The site uses a general configuration management database and an
+       associated tool that manage all prefixes and all DHCPv6, DNS, and
+       router and security configurations in a consistent and integrated
+       way.  Even if static addresses are used, they are always
+       configured with this tool, and never manually.  Specification of
+       such a tool is out of scope for the present document.
+
+   2.  All printers and other local servers are always accessed via a
+       DNS or mDNS name, or via a discovery protocol.  User computers
+       are configured only with names for such servers and never with
+       their addresses.
+
+   3.  Internal traffic uses a ULA prefix, such that disturbance to such
+       traffic is avoided if the externally used prefix changes.
+
+   4.  If prefix renumbering is required, the RFC 4192 procedure is
+       followed.
+
+   Remaining open questions are:
+
+   1.  Is minor residual loss of extremely long-living transport
+       sessions during renumbering operationally acceptable?
+
+   2.  Can automatic network element renumbering be performed without
+       interrupting any user sessions?
+
+   3.  Do any software licensing systems require manual intervention?
+
+4.  Security Considerations
+
+   This document does not define a protocol, so it does not introduce
+   any new security exposures.  However, security configurations, such
+   as ACLs, are affected by the renumbering of static addresses.
+
+
+
+
+
+
+Carpenter & Jiang             Informational                     [Page 9]
+
+RFC 6866              Renumbering Static Addresses         February 2013
+
+
+5.  Acknowledgements
+
+   Valuable comments and contributions were made by Ran Atkinson, Ralph
+   Droms, Adrian Farrel, Wes George, Brian Haberman, Bing Liu, Pete
+   Resnick, and other participants in the 6renum WG.
+
+6.  Informative References
+
+   [GAP-ANALYSIS]  Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W.
+                   George, "IPv6 Site Renumbering Gap Analysis", Work
+                   in Progress, December 2012.
+
+   [PREFIX]        Baker, F. and R. Droms, "IPv6 Prefix Assignment in
+                   Small Networks", Work in Progress, March 2012.
+
+   [PROBLEM]       Narten, T., Ed., Gray, E., Ed., Black, D., Dutt, D.,
+                   Fang, L., Kreeger, L., Napierala, M., and M.
+                   Sridharan, "Problem Statement: Overlays for Network
+                   Virtualization", Work in Progress, October 2012.
+
+   [RFC1918]       Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot,
+                   G., and E. Lear, "Address Allocation for Private
+                   Internets", BCP 5, RFC 1918, February 1996.
+
+   [RFC2608]       Guttman, E., Perkins, C., Veizades, J., and M. Day,
+                   "Service Location Protocol, Version 2", RFC 2608,
+                   June 1999.
+
+   [RFC3007]       Wellington, B., "Secure Domain Name System (DNS)
+                   Dynamic Update", RFC 3007, November 2000.
+
+   [RFC3315]       Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
+                   C., and M. Carney, "Dynamic Host Configuration
+                   Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+   [RFC4192]       Baker, F., Lear, E., and R. Droms, "Procedures for
+                   Renumbering an IPv6 Network without a Flag Day",
+                   RFC 4192, September 2005.
+
+   [RFC4193]       Hinden, R. and B. Haberman, "Unique Local IPv6
+                   Unicast Addresses", RFC 4193, October 2005.
+
+   [RFC4862]       Thomson, S., Narten, T., and T. Jinmei, "IPv6
+                   Stateless Address Autoconfiguration", RFC 4862,
+                   September 2007.
+
+
+
+
+
+
+Carpenter & Jiang             Informational                    [Page 10]
+
+RFC 6866              Renumbering Static Addresses         February 2013
+
+
+   [RFC5887]       Carpenter, B., Atkinson, R., and H. Flinck,
+                   "Renumbering Still Needs Work", RFC 5887, May 2010.
+
+   [RFC6250]       Thaler, D., "Evolution of the IP Model", RFC 6250,
+                   May 2011.
+
+   [RFC6762]       Cheshire, S. and M. Krochmal, "Multicast DNS",
+                   RFC 6762, February 2013.
+
+   [RFC6763]       Cheshire, S. and M. Krochmal, "DNS-Based Service
+                   Discovery", RFC 6763, February 2013.
+
+   [RFC6879]       Jiang, S., Liu, B., and B. Carpenter, "IPv6
+                   Enterprise Network Renumbering Scenarios,
+                   Considerations, and Methods", RFC 6879,
+                   February 2013.
+
+Authors' Addresses
+
+   Brian Carpenter
+   Department of Computer Science
+   University of Auckland
+   PB 92019
+   Auckland,   1142
+   New Zealand
+
+   EMail: brian.e.carpenter@gmail.com
+
+
+   Sheng Jiang
+   Huawei Technologies Co., Ltd.
+   Q14, Huawei Campus
+   No.156 Beiqing Road
+   Hai-Dian District, Beijing  100095
+   P.R. China
+
+   EMail: jiangsheng@huawei.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Carpenter & Jiang             Informational                    [Page 11]
+