One document matched: draft-ietf-6renum-static-problem-02.xml

<?xml version="1.0" encoding="UTF-8"?>

<!-- This is built from a template for a generic Internet Draft. Suggestions for
     improvement welcome - write to Brian Carpenter, brian.e.carpenter @ gmail.com -->

<!-- This can be converted using the Web service at http://xml.resource.org/experimental.html
     (which supports the latest, sometimes undocumented and under-tested, features.) -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!-- You need one entry like the following for each RFC referenced -->

<!ENTITY RFC2119 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC2629 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml'>
<!ENTITY RFC2460 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml'>
<!ENTITY RFC5887 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5887.xml'>
<!ENTITY RFC1918 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml'>
<!ENTITY RFC4192 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4192.xml'>
<!ENTITY RFC4193 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml'>
<!ENTITY RFC4862 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml'>
<!ENTITY RFC3315 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml'>
<!ENTITY RFC3007 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3007.xml'>
<!ENTITY RFC2608 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2608'>
<!ENTITY RFC6250 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6250'>



<!-- You need one entry like the following for each I-D referenced -->

<!ENTITY DRAFT-renent SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6renum-enterprise.xml">
<!ENTITY DRAFT-rengap SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6renum-gap-analysis.xml">
<!ENTITY DRAFT-nvo3 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nvo3-overlay-problem-statement.xml">
<!ENTITY DRAFT-homepref SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.baker-homenet-prefix-assignment.xml">
<!ENTITY DRAFT-mdns SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.cheshire-dnsext-multicastdns.xml">

<!ENTITY DRAFT-dnssd SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.cheshire-dnsext-dns-sd.xml">

]>


<?rfc toc="yes"?>            <!-- You want a table of contents -->
<?rfc symrefs="yes"?>        <!-- Use symbolic labels for references -->
<?rfc sortrefs="yes"?>       <!-- This sorts the references -->
<?rfc iprnotified="no" ?>    <!-- Change to "yes" if someone has disclosed IPR for the draft -->
<?rfc compact="yes"?>


<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate -->
<rfc ipr="trust200902" docName="draft-ietf-6renum-static-problem-02" category="info" >


<front>
<title abbrev="Renumbering Static Addresses">Problem Statement for Renumbering IPv6 Hosts with Static Addresses</title>


<author initials="B. E." surname="Carpenter" fullname="Brian Carpenter">
    <organization abbrev="Univ. of Auckland"></organization>
    <address>
      <postal>
        <street>Department of Computer Science</street>
        <street>University of Auckland</street>
        <street>PB 92019</street>
        <city>Auckland</city>
        <region></region>
        <code>1142</code>
        <country>New Zealand</country>
      </postal>
      
      <email>brian.e.carpenter@gmail.com</email>
    </address>
</author>

   <author fullname="Sheng Jiang" initials="S." surname="Jiang">
      <organization>Huawei Technologies Co., Ltd</organization>
      <address>
        <postal>
          <street>Q14, Huawei Campus</street>
          <street>No.156 Beiqing Road</street>
          <city>Hai-Dian District, Beijing</city>
          <code>100095</code>
          <country>P.R. China</country>
        </postal>
        <email>jiangsheng@huawei.com</email>
      </address>
    </author>

 <date day="30" month="September" year="2012" />

<area>Operations and Management</area>
<workgroup>6RENUM</workgroup>

 


<abstract>

<t>This document analyses the problems of updating the IPv6 addresses of hosts in enterprise
networks that for operational reasons require static addresses. 
</t>
    
</abstract>
</front>

<middle>
<section anchor="intro" title="Introduction">

<t>A problem that is frequently mentioned in discussions of renumbering enterprise networks
<xref target="RFC5887"/> <xref target="I-D.ietf-6renum-enterprise"/>  <xref target="I-D.ietf-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. </t>

<t>In a sense, the issue of static addresses is a result of history. As discussed in Section 3.2
of <xref target="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.</t>

<t>Although static addressing is in general problematic for renumbering,
hosts inside an enterprise may have static addresses for a number of operational reasons:</t>
<t><list style="symbols">
   <t>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.  </t>
   <t>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. </t>
   <t>Some approaches to virtual server farms require static addressing. </t>
   <t>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. </t>
   <t>Certain software licensing mechanisms are based on IP addresses. </t>
   <t>Network elements such as routers are usually assigned static addresses, which are also
      configured into network monitoring and management systems. </t>
   </list></t>

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

<t>This document analyses these issues in more detail and presents a problem statement. 
Where obvious alternatives to static addresses exist, they are mentioned. </t> 

</section> <!-- intro -->

<section anchor="anal" title="Analysis">

 <section title="Static Addresses Imply Static Prefixes">
 <t>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. </t>

 <t>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 <xref target="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. <xref target="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. </t>
 </section> 


 <section title="Other Hosts Need Literal Address">
 <t>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 <xref target="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 <xref target="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. </t>
 <t>In the case of IPv6, exactly the same situation would be created by numbering the printer
    statically under the site's ULA prefix <xref target="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. </t>
 <t>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. </t>

 <t>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 <xref target="I-D.cheshire-dnsext-multicastdns"/> in
 combination with DNS Service Discovery <xref target="I-D.cheshire-dnsext-dns-sd"/>.
 The other is the Service Location Protocol <xref target="RFC2608"/>. Both of these solutions
 are widely implemented, but seemingly not widely deployed in enterprise networks. </t>
 </section>

 <section title="Static Server Addresses">

 <t>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 <xref target="RFC4862"/> or DHCPv6 <xref target="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 <xref target="RFC3007"/>
 would be required, remote users would attempt to use the wrong address until
 the DNS time-to-live expired. </t>

 <t>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
 using a suitable configuration tool. 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. </t>

 <t>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 <xref target="RFC4192"/> could be followed.
 However, if there is no such database, a manual procedure would have to be adopted. </t>
 </section> 

 <section title="Static Virtual Machine Addresses">
 <t>According to <xref target= "I-D.ietf-nvo3-overlay-problem-statement"/>, the placement and movement of virtual
   machines (VMs) in a physical
   network effectively requires that their IP addresses are 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.</t>
 <t>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 <xref target="RFC4192"/>
   is followed. </t> 
 </section>

 <section title="Asset Management and Security Tracing">
 <t>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.  </t>

 <t>Such users will not in most circumstances be significantly inconvenienced by prefix renumbering, as long
    as it follows the <xref target="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. </t>

 <t>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. </t>
 </section>

 <section title="Primitive Software Licensing">
 <t>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. </t>

 <t>If acceptable to the licensing mechanism, using addresses under an enterprise's ULA prefix for
    software licensing would avoid this problem. </t>

 </section>

 <section title="Network Elements">
 <t>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 <xref target="RFC4192"/>
    procedure, like any other host. </t>

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

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

 </section>

 <section title="Management Aspects">
 <t>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 possible. Clearly the database needs to be supported by a suitable configuration tool. </t>
 </section>


</section> <!-- anal -->

<section anchor="prob" title="Summary of Problem Statement">

<t>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? </t>

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

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

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

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

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

<t>It appears that the majority of the above problems can be largely mitigated if the following measures are taken:</t>

<t>
<list style="numbers">
<t>The site uses a general
configuration management database and an associated tool that manage all prefixes, DHCPv6, DNS and router 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. </t>
<t>All printers and other local servers are always
accessed via a DNS, mDNS or SLP name. User computers are configured only with names for
such servers and never with their addresses. </t>
<t>Internal traffic uses a ULA prefix, such that disturbance to such traffic is avoided
if the externally used prefix changes. </t>
<t>If external prefix renumbering is required, the RFC 4192 procedure is followed. </t>
</list>
</t>

<t>Remaining open questions are: </t>
<t>
<list style="numbers">
<t>Is minor residual loss of ongoing transport sessions during renumbering operationally acceptable? </t>
<t>Can automatic network element renumbering can be performed without interrupting user sessions? </t>
<t>Do any software licensing systems require manual intervention? </t>
</list>
</t>


</section> <!-- prob -->


<section anchor="security" title="Security Considerations">

<t>This document defines no protocol, so does not introduce any new security exposures. </t>

   
</section> <!-- security -->


<section anchor="iana" title="IANA Considerations">
   <t>This document requests no action by IANA. </t>
</section> <!-- iana -->




<section anchor="ack" title="Acknowledgements">

<t>
Valuable comments and contributions were made by
Ran Atkinson,
Wes George, 
Brian Haberman, 
Bing Liu,
and other participants in the 6renum WG.</t>

<t>This document was produced using the xml2rfc tool
<xref target="RFC2629"/>.</t>

</section> <!-- ack -->


<section anchor ="changes" title="Change log [RFC Editor: Please remove]">
<t>draft-ietf-6renum-static-problem-02: WGLC comments, clarified discussion of SLP and mDNS,
expanded discussion of configuration tool, 2012-09-30.</t>
<t>draft-ietf-6renum-static-problem-01: WG comments, 2012-08-31.</t>
<t>draft-ietf-6renum-static-problem-00: adopted by WG and as milestone, 2012-07-30.</t>
<t>draft-carpenter-6renum-static-problem-02: more feedback from WG, 2012-02-28.</t>
<t>draft-carpenter-6renum-static-problem-01: feedback from WG, new text on software licensing, 2011-12-06.</t>
<t>draft-carpenter-6renum-static-problem-00: original version, 2011-10-18.</t>


</section> <!-- changes -->

</middle>

<back>


<references title="Informative References">

&RFC5887;
&RFC2629;
&RFC1918;
&RFC4192;
&RFC4193;
&RFC4862;
&RFC3315;
&RFC3007;
&RFC2608;
&RFC6250;
&DRAFT-renent;
&DRAFT-rengap;
&DRAFT-nvo3;
&DRAFT-homepref;
&DRAFT-mdns;
&DRAFT-dnssd;
  
</references>




</back>
</rfc>