[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 draft-ietf-6renum-static-problem

6RENUM                                                      B. Carpenter
Internet-Draft                                         Univ. of Auckland
Intended status: Informational                                  S. Jiang
Expires: August 31, 2012                    Huawei Technologies Co., Ltd
                                                       February 28, 2012


   Problem Statement for Renumbering IPv6 Hosts with Static Addresses
                draft-carpenter-6renum-static-problem-02

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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 31, 2012.

Copyright Notice

   Copyright (c) 2012 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        Expires August 31, 2012                [Page 1]


Internet-Draft        Renumbering Static Addresses         February 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Static Addresses Imply Static Prefixes . . . . . . . . . .  4
     2.2.  Other Hosts Need Literal Address . . . . . . . . . . . . .  4
     2.3.  Static Server Addresses  . . . . . . . . . . . . . . . . .  5
     2.4.  Static Virtual Machine Addresses . . . . . . . . . . . . .  5
     2.5.  Asset Management and Security Tracing  . . . . . . . . . .  6
     2.6.  Primitive Software Licensing . . . . . . . . . . . . . . .  6
     2.7.  Network Elements . . . . . . . . . . . . . . . . . . . . .  7
     2.8.  Management Aspects . . . . . . . . . . . . . . . . . . . .  7
   3.  Summary of Problem Statement . . . . . . . . . . . . . . . . .  8
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  Change log [RFC Editor: Please remove] . . . . . . . . . . . .  9
   8.  Informative References . . . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
































Carpenter & Jiang        Expires August 31, 2012                [Page 2]


Internet-Draft        Renumbering Static Addresses         February 2012


1.  Introduction

   A problem that is frequently mentioned in discussions of renumbering
   enterprise networks [RFC5887] [I-D.jiang-6renum-enterprise]
   [I-D.liu-6renum-gap-analysis] is that of statically assigned
   addresses.  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.

   Although static addressing is in general problematic for renumbering,
   hosts inside an enterprise may have static addresses for a number of
   operational reasons:

   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 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.

   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





Carpenter & Jiang        Expires August 31, 2012                [Page 3]


Internet-Draft        Renumbering Static Addresses         February 2012


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
   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
   [I-D.baker-homenet-prefix-assignment].  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 long established practice in small IPv4 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.  It is also
   unusual to enable the Service Location Protocol [RFC2608] for the
   same purpose.  In consequence, if the printer is renumbered for any
   reason, the manual configuration of all users' hosts must be updated.

   In the case of IPv6, exactly the same situation would be created by
   numbering the printer statically under the site's ULA prefix
   [RFC4193].  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.




Carpenter & Jiang        Expires August 31, 2012                [Page 4]


Internet-Draft        Renumbering Static Addresses         February 2012


   If such a host is numbered out of a 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
   the configuration data are by no means stored in the network layer.

   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 [I-D.cheshire-dnsext-multicastdns] and the
   other is the Service Location Protocol [RFC2608].

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 auto-
   configuration [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).  Also, since a dynamic DNS update [RFC3007]
   would be required, remote users would attempt to use the wrong
   address until the DNS time-to-live expired.

   Such server addresses can be managed centrally even if they are
   static, by using DHCPv6 in stateful mode, and by generating both
   DHCPv6 data and DNS data from a common configuration database.  This
   does normally carry the implication that the database also contains
   the hardware (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 very likely today
   to fall back on manual configuration of server addresses as a result.

   In the event of renumbering of 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.

2.4.  Static Virtual Machine Addresses

   According to [I-D.narten-nvo3-overlay-problem-statement], "Placement
   and movement of VMs in a network effectively requires that VM 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.



Carpenter & Jiang        Expires August 31, 2012                [Page 5]


Internet-Draft        Renumbering Static Addresses         February 2012


   If VMs are numbered out of a prefix that is subject to renumbering,
   there is a direct conflict with transport 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.

   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 cannot be given a single static address.  These
   users will in most circumstances only be slightly inconvenienced, if
   at all, by prefix renumbering.

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



Carpenter & Jiang        Expires August 31, 2012                [Page 6]


Internet-Draft        Renumbering Static Addresses         February 2012


   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 infrastructure, 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 also to configure those addresses in the monitoring
   and management systems.  It is quite 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.

   In any case, when network elements are renumbered, existing user
   sessions may not survive, because of temporary "destination
   unreachable" conditions being treated as fatal errors.  This aspect
   needs further investigation.

2.8.  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.  Thus, in cases where static
   addresses cannot be avoided, they should in any case be assigned
   automatically from a central database using a suitable protocol,
   probably stateful DHCPv6.  If possible, even static addresses kept in
   the central database should be assigned automatically.  Manual
   updates of the central database should be kept to a minimum, and
   manual configuration of individual hosts should be avoided if at all



Carpenter & Jiang        Expires August 31, 2012                [Page 7]


Internet-Draft        Renumbering Static Addresses         February 2012


   possible.


3.  Summary of Problem Statement

   If subnet prefixes are statically assigned, various network elements
   and the network management system must be informed when they are
   renumbered.  Alternatively, can automatic subnet prefix assignment be
   performed without interruption to user sessions?

   If a printer or similar local server is statically addressed out of a
   non-ULA prefix, and has no DNS, mDNS or SLP name, prefix renumbering
   will require configuration changes in all hosts using that server.
   Most likely, these changes will be manual; therefore this situation
   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.

   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.

   It should be clarified whether automatic network element renumbering
   can be performed without interrupting user sessions.


4.  Security Considerations

   This document defines no protocol, so does not introduce any new



Carpenter & Jiang        Expires August 31, 2012                [Page 8]


Internet-Draft        Renumbering Static Addresses         February 2012


   security exposures.


5.  IANA Considerations

   This document requests no action by IANA.


6.  Acknowledgements

   Valuable comments and contributions were made by Brian Haberman, Bing
   Liu, and other participants in the 6renum WG.

   This document was produced using the xml2rfc tool [RFC2629].


7.  Change log [RFC Editor: Please remove]

   draft-carpenter-6renum-static-problem-02: more feedback from WG,
   2012-02-28.

   draft-carpenter-6renum-static-problem-01: feedback from WG, new text
   on software licensing, 2011-12-06.

   draft-carpenter-6renum-static-problem-00: original version,
   2011-10-18.


8.  Informative References

   [I-D.baker-homenet-prefix-assignment]
              Baker, F. and R. Droms, "IPv6 Prefix Assignment in Small
              Networks", draft-baker-homenet-prefix-assignment-00 (work
              in progress), October 2011.

   [I-D.cheshire-dnsext-multicastdns]
              Cheshire, S. and M. Krochmal, "Multicast DNS",
              draft-cheshire-dnsext-multicastdns-15 (work in progress),
              December 2011.

   [I-D.jiang-6renum-enterprise]
              Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise
              Network Renumbering Scenarios and Guidelines",
              draft-jiang-6renum-enterprise-02 (work in progress),
              December 2011.

   [I-D.liu-6renum-gap-analysis]
              Liu, B., Jiang, S., and B. Carpenter, "IPv6 Site



Carpenter & Jiang        Expires August 31, 2012                [Page 9]


Internet-Draft        Renumbering Static Addresses         February 2012


              Renumbering Gap Analysis",
              draft-liu-6renum-gap-analysis-03 (work in progress),
              December 2011.

   [I-D.narten-nvo3-overlay-problem-statement]
              Narten, T., Sridhavan, M., Dutt, D., Black, D., and L.
              Kreeger, "Problem Statement: Overlays for Network
              Virtualization",
              draft-narten-nvo3-overlay-problem-statement-01 (work in
              progress), October 2011.

   [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.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              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.

   [RFC5887]  Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
              Still Needs Work", RFC 5887, May 2010.










Carpenter & Jiang        Expires August 31, 2012               [Page 10]


Internet-Draft        Renumbering Static Addresses         February 2012


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        Expires August 31, 2012               [Page 11]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/