One document matched: draft-davies-reusable-ipv4-address-block-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-davies-reusable-ipv4-address-block-00"
     ipr="pre5378Trust200902">
  <front>
    <title abbrev="reusable-ipv4-address-block">Transitional non-conflicting
    reusable IPv4 address block</title>

    <author fullname="Greg Davies" initials="G" surname="Davies">
      <organization>Telstra Corporation</organization>

      <address>
        <postal>
          <street>28/242 Exhibition Street</street>

          <city>Melbourne</city>

          <region>VIC</region>

          <code>3000</code>

          <country>AU</country>
        </postal>

        <phone>+61.3.9634.3640</phone>

        <facsimile></facsimile>

        <email>greg.davies@team.telstra.com</email>

        <uri>http://www.telstra.com</uri>
      </address>
    </author>

    <author fullname="Christopher Liljenstolpe" initials="C."
            surname="Liljenstolpe">
      <organization>Telstra Corporation</organization>

      <address>
        <postal>
          <street>32/242 Exhibition Street</street>

          <city>Melbourne</city>

          <region>VIC</region>

          <code>3000</code>

          <country>AU</country>
        </postal>

        <phone>+61.3.8647.6389</phone>

        <facsimile></facsimile>

        <email>cdl@asgaard.org</email>

        <uri>http://www.telstra.com</uri>
      </address>
    </author>

    <date day="09" month="November" year="2009" />

    <abstract>
      <t>Although IPv6 is being introduced globally, the entire IP ecosystem
      will not have transitioned to IPv6 before the forecast exhaustion of the
      global IPv4 address pools.</t>

      <t>This document describes a new transitional non-conflicting reusable
      IPv4 address block which will facilitate a smooth IPv4 to IPv6
      transition for customers and transit providers.</t>

      <t>The address block would be assigned by IANA and have a limited time
      horizon to match its transitional purpose.</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>IPv6 is being introduced globally, however the entire IP ecosystem
      will not have transitioned to IPv6 before the exhaustion of the global
      IPv4 address pool.</t>

      <t>During the transition, IPV4 connectivity will still be required for
      customers with IPv4-only devices, IPv4-only operating systems and for
      accessing remaining IPv4-only content and applications.</t>

      <t>To facilitate a smooth transition to IPv6 for customers and transit
      providers an address block is required that will not conflict with
      existing <xref target="RFC1918">RFC1918</xref> addresses (used
      extensively within customer networks and in management of IP
      infrastructure).</t>

      <t>The idea of a reusable address space has also been discussed in <xref
      target="I-D.shirasaki-isp-shared-addr"></xref></t>
    </section>

    <section title="Characateristics of the address block">
      <t></t>

      <section title="Transitional">
        <t>The address block is not proposed as a permanent solution as it is
        intended to aid the transition from IPv4 to IPv6. It is therefore
        RECOMMENDED that a time horizon of 2020 be set for the retirement of
        this address block. This will provide sufficient time for the
        successful lifecycle transition of the customer environment from IPv4
        to IPv6 (given support from device vendors).</t>
      </section>

      <section title="Non-conflicting">
        <t>The address block MUST NOT conflict with existing <xref
        target="RFC1918">RFC1918</xref> addresses which are used extensively
        within customer networks and by transit providers in the management of
        IP infrastructure.</t>

        <t>This address block MUST NOT be used as a default range in any CPE
        equipment.</t>
      </section>

      <section title="Re-usable">
        <t>It is proposed that the address block can be re-used by any transit
        provider. The address block MUST NOT be used in global routing on the
        public Internet.</t>
      </section>

      <section title="Address range">
        <t>A suitable address range for this purpose should be selected and
        reserved by IANA from the unallocated IPv4 address pool. This address
        could be from previously reclaimed space, or space reclaimed for this
        purpose.</t>

        <t>It is noted that although in principle an address block from the
        reserved 240/4 range could be used for this purpose, it is understood
        that the actual use of this range is prevented within the
        implementation of many current IPv4 protocol stacks. Any proposed use
        of 240/4 would therefore appear to require major changes to deployed
        equipment, which would be impractical for the purposes of a
        transitional IPv4 solution because of the time needed for deployment
        to customers and the financial requirements involved.</t>
      </section>

      <section title="Size of address block">
        <t>An address block with a /10 CIDR mask should be reserved for this
        purpose.</t>

        <t>The size of the reserved address block is not associated with any
        specific network architectures, but it is intended to accommodate the
        potential requirements of different network designs used by individual
        providers.</t>

        <t>In particular, this address block is sized to the minimal level
        expected for the addressing needs of a major provider offering
        services to a large broadband domain such as a single large city. It
        is believed that a block smaller than /10 would require duplicate use
        of the same address space within such a domain, which could force the
        provider to use an inefficient network design and could introduce
        significant complexity in network operations such as service identity
        management.</t>
      </section>

      <section title="Global routing table">
        <t>The address block MUST be considered a bogon in the global routing
        table, and filtered as the <xref target="RFC1918">RFC1918</xref>
        address space is currently in the public Internet.</t>
      </section>

      <section title="Reverse DNS">
        <t>Reverse DNS queries for addresses in this block MUST NOT be
        forwarded to the global DNS infrastructure.</t>

        <t>Any provider using this address block SHOULD provide reverse DNS
        infrastructure for this block, or the portions of it that they
        utilize.</t>

        <t>The in-addr.arpa root servers MUST return NXDOMAIN for this address
        block, if queried.</t>
      </section>

      <section title="Traffic Filters">
        <t>Any provider utilizing this address block MUST filter traffic with
        source or destination addresses within this block at their external
        borders</t>

        <t>All networks SHOULD apply the same filters.</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>IANA is to record the allocation of the IPv4 global unicast address
      as ‘Transitional IPv4 to IPv6 address block’ in the IPv4
      address registry.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Security considerations for this address block would be equivalent to
      those associated with <xref target="RFC1918">RFC1918</xref>
      addresses.</t>
    </section>

    <section anchor="Acknowledgements" title="Contributors">
      <t>The authors wish to acknowledge the contributions of Yasuhiro
      Shirasaki and Shin Miyakawa (NTT Communications Corporation) as well as
      Akira Nakagawa (KDDI Corporation) for their work on the ISP Shared
      Address.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include='reference.RFC.1918'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.shirasaki-isp-shared-addr'?>
    </references>
  </back>
</rfc>