<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-howard-sunset4-v4historic-00" ipr="trust200902">
  <front>
    <title abbrev="draft-howard-sunset4-v4historic">IPv4 Declared Historic</title>

    <author fullname="Lee Howard" initials="L" surname="Howard">
      <organization>Time Warner Cable</organization>

      <address>
        <postal>
          <street>13820 Sunrise Valley Dr.</street>

          <!-- Reorder these if your country does things differently -->

          <city>Herndon</city>

          <region>VA</region>

          <code>20171</code>

          <country>USA</country>
        </postal>

        <phone/>

        <email>lee.howard@twcable.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date day="14" month="March" year="2016"/>

    <abstract><t>IPv4 has been superseded by IPv6, and is therefore Historic.</t>
    </abstract>
  </front>

  <middle>
    <section title=" Introduction">
      <t>  According to [RFC2026], "The Internet Standards Process":</t>
      <t>
      <list style="empty">
        <t>4.2.4 Historic </t>
        <t>A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level. </t>
        <t>Note: Standards track specifications normally must not depend on other standards track specifications which are at a lower maturity level or on non standards track specifications other than referenced specifications from other standards bodies. (See Section 7.)</t>
       </list>
       </t>

       <t>IPv4 [RFC791] has been superseded by the more recent IPv6 specification [RFC2460bis]. The IPv6 document specifically says, "IP version 6 (IPv6) is a new version of the Internet Protocol, designed as the successor to IP version 4 (IPv4) [RFC791]."</t>

       <t>RFC791 is therefore Historic.</t>

       <t>IPv4 has inherent limitations which can not be mitigated; the IETF has therefore developed a new protocol without these limitations. Current and future work builds on IPv6, making it better for every purpose than the old protocol.  </t>

       <t>The use of IPv4 is deprecated. The term "deprecated" is used to indicate a feature, characteristic, or practice that should be avoided, in this case because it is being superseded by a newer protocol. The term does not indicate that the practice is harmful, but that there will be no further development in IPv4, and therefore those using the old version are advised to transition to the newer version.</t>
    </section>

      <section title="Implications">
        <!-- 1.1, line 99-->
        <t>Moving an Internet Standard to the Historic maturity level does not mean that it cannot be used. It does mean that any Standards Track RFC with a Normative reference to RFC791 is Historic. This is appropriate: any RFC defining IPv4 options is Historic.</t>

        <t>In addition, some RFCs that refer to RFC791, such as [RFC1035] "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" which defines A and IN-ADDR.ARPA, will be Updated By this document, but are not Historic. Other documents with incidental references to RFC791 should not be affected. Documents requiring updates are appropriate for [draft-ietf-sunset4-gapanalysis]. </t>
 
        <t>The IETF does not update Historic RFCs. Therefore, the IETF will no longer work on IPv4 technologies, including transition technologies.</t>

	<t>The term "IP," without address family specified, is assumed to mean "IPv6."</t>

    </section>

    <section title=" Security Considerations">
        <t>It is possible that bugs inherent to IPv4 will yet be discovered. Being Historic, the IETF will not further update IPv4. Therefore, for security reasons, the use of IPv6 exclusively is recommended.</t>
    </section>

    <section title=" IANA Considerations">
        <t>This document does not direct IANA to alter its processes for allocating IPv4 addresses according to its processes. This is unlikely to be a significant activity for long.</t>
    </section>

    <section title=" Acknowledgements">

    </section>


    <section title=" References">

      <section title=" Normative References">

	<t>[RFC791], Postel, J., "Internet Protocol", September 1981.</t>

	<t>[RFC2460bis], Deering, S., and Hinden, R., "Internet Protocol, Version 6 (IPv6) Specification", January 2016.</t>

        <t>[RFC2026], Bradner, S., "The Internet Standards Process", October 1996.</t>
        <t>[draft-ietf-6man-rfc2460bis] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", November 2015.</t>
      </section>

      <!-- ends: "7.1 from line 325-->

      <section title=" Informative References">

        <t>[RFC1035], Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", November 1987.</t>


      </section>
   </section>

  </middle>

  <back/>
</rfc>
