<?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="info" docName="draft-bdgks-arin-shared-transition-space-03"
     ipr="trust200902" submissionType="independent">
  <front>
    <title abbrev="ARIN Shared Transition Space">ARIN Draft Policy 2011-5:
    Shared Transition Space</title>

    <author fullname="Stan Barber" initials="S." surname="Barber">
      <organization>Cox Communications</organization>

      <address>
        <email>stan.barber2@cox.com</email>
      </address>
    </author>

    <author fullname="Owen Delong" initials="O." surname="Delong">
      <organization>Hurricane Electric</organization>

      <address>
        <email>owen@delong.com</email>
      </address>
    </author>

    <author fullname="Chris Grundemann" initials="C." surname="Grundemann">
      <organization>CableLabs</organization>

      <address>
        <email>c.grundemann@cablelabs.com</email>
      </address>
    </author>

    <author fullname="Victor Kuarsingh" initials="V." surname="Kuarsingh">
      <organization>Rogers Communications</organization>

      <address>
        <email>victor.kuarsingh@rci.rogers.com</email>
      </address>
    </author>

    <author fullname="Benson Schliesser" initials="B." surname="Schliesser">
      <organization>Cisco Systems</organization>

      <address>
        <email>bschlies@cisco.com</email>
      </address>
    </author>

    <date day="19" month="September" year="2011" />

    <area>Operations</area>

    <workgroup></workgroup>

    <keyword></keyword>

    <abstract>
      <t>This memo discusses the applicability of a Shared Transition Space,
      an IPv4 prefix designated for local use within service provider networks
      during the period of IPv6 transition. This address space has been
      proposed at various times in the IETF, and more recently come to
      consensus within the ARIN policy development community where it was
      recommended for adoption as Draft Policy 2011-5.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="Introduction" title="Introduction">
      <t>As the Internet community approaches exhaustion of unallocated IPv4
      numbers, the value of globally unique addresses is becoming manifest.
      More than ever network operators recognize the need to transition to the
      IPv6 address family. However, the immediate necessity of continued IPv4
      connectivity poses a near-term challenge - without adequate IPv4
      resources, most network operators must deploy more efficient addressing
      architectures and many must deploy address-sharing technologies.</t>

      <t>In order to facilitate these operators' need for near-term IPv4
      connectivity, <xref
      target="I-D.weil-shared-transition-space-request"></xref> proposes the
      reservation of a /10 IPv4 prefix for use in Service Provider (SP)
      networks. Referred to as Shared Transition Space, this address block
      would facilitate SP deployment of non-unique address plans that do not
      conflict with traditional Private <xref target="RFC1918"></xref> address
      space. By using the Shared Transition Space operators may deploy CGN
      <xref target="I-D.ietf-behave-lsn-requirements"></xref> internal
      networks, extranet <xref target="RFC4364"></xref> communities, and/or
      SP-local services without consuming Global Unicast Addresses.</t>

      <t>However, given the Feb 2011 depletion of the IANA Free Pool inventory
      <xref target="NRO-IANA-exhaust"></xref> it is not currently possible for
      the IANA to reserve an IPv4 /10 prefix as recommended in <xref
      target="I-D.weil-shared-transition-space-request"></xref>. Thus the ARIN
      community has proposed in Draft Policy <xref
      target="ARIN-2011-5"></xref> the reservation of a Shared Transition
      Space from the ARIN inventory of unallocated IPv4 numbers. After much
      discussion by the ARIN community, <xref target="ARIN-2011-5"></xref>
      reached consensus and was recommended by the ARIN Advisory Council for
      approval by the ARIN Board of Trustees.</t>

      <t>Following the community's recommendation of <xref
      target="ARIN-2011-5"></xref> the ARIN Board requested clarification from
      the IAB with regard to responsibilities outlined in <xref
      target="RFC2860"></xref>. The ARIN Board received a response in <xref
      target="IAB-response"></xref> indicating that the IETF holds
      responsibility for the reservation of specialized address blocks. Thus,
      the ARIN Board believes that it is not within ARIN's authority to
      unilaterally make specialized allocations of the sort proposed in Draft
      Policy 2011-5. <xref target="PPML-022778"></xref></t>

      <t>This memo explains the intended use and discusses the merits and
      drawbacks of using Shared Transition Space.</t>
    </section>

    <section anchor="Applicability" title="Applicability">
      <section title="Intended Use of Shared Transition Space">
        <t>The Shared Transition Space is intended for use by service
        providers and should not be thought of as additional RFC1918 space.
        There are a number of specific use-cases for the Shared Transition
        Space. This section discusses the primary scenarios envisioned at the
        time of this writing. Equipment vendors and non-ISP network operators
        should be aware that using the Shared Transition Space outside of its
        intended scope may result in unpredictable behavior.</t>

        <section title="CGN">
          <t>The primary use-case for the Shared Transition Space will be
          deployment in CGN <xref
          target="I-D.ietf-behave-lsn-requirements"></xref> internal networks.
          A key benefit of CGN is the ability to share a smaller number of
          Global Unicast Addresses (GUA) amongst a larger number of
          end-sites.</t>

          <t>In one CGN deployment scenario sometimes referred to as NAT444
          <xref target="I-D.shirasaki-nat444"></xref>, the CGN internal
          network is numbered with IPv4 addresses that are not globally routed
          while the end-sites are numbered with Private <xref
          target="RFC1918"></xref> addresses. In this scenario the Shared
          Transition Space will be used to provide contextually unique IPv4
          addresses to end-site CPE devices and intermediate infrastructure.
          <xref target="I-D.shirasaki-nat444-isp-shared-addr"></xref></t>
        </section>

        <section title="SP Services &amp; Infrastructure">
          <t>In networks that contain local services (such as nameservers,
          content repositories or caches, etc) the Shared Transition Space
          will offer an alternative to GUA. For instance, video content
          servers that are available only to customers directly connected to
          the SP network might be addressed from the Shared Transition Space,
          preserving GUA for services that require global connectivity. Where
          these services are accessed by customers who have their own
          IPv4-only equipment, use of the Shared Transition Space will reduce
          or eliminate the need for NAT. Similarly, those infrastructure
          elements which touch IPv4-only customer-managed equipment could also
          be numbered from the Shared Transition Space. In cases where the
          provider manages both endpoints, IPv6 should be used.</t>
        </section>

        <section title="Note of Caution">
          <t>In any case, care must be taken to ensure the Shared Transition
          Space is not used in scenarios where routing may be ambiguous. For
          instance, when multiple provider networks may be simultaneously
          reachable the use of Shared Transition Space might result in address
          conflicts etc. Conversely, operators may choose to allow (not
          filter) ICMP messages from the Shared Transition Space in order to
          enable Path MTU Discovery etc. This topic requires further
          investigation so that best practices may be developed.</t>
        </section>
      </section>

      <section title="Alternatives">
        <t>A number of possible alternatives to Shared Transition Space have
        been proposed and/or discussed by the Internet community. See, for
        instance, <xref target="RFC6319"></xref> for a discussion of
        alternatives and potential issues. This section outlines these
        possible alternatives and briefly discusses their applicability.</t>

        <section title="Global Unicast Addresses">
          <t>Every discussion of the Shared Transition Space begins with an
          assumption that Global Unicast Addresses (GUA) are a preferable
          choice for numbering. This is almost always technically true.
          However, given the fundamental driver of IPv4 address exhaustion,
          GUA is not a pragmatic alternative to the Shared Transition
          Space.</t>

          <t>Additionally, if various organizations use various GUA ranges to
          number CGN zones, it will be difficult for other networks and/or
          systems to deterministically know if the endpoints are using true
          Internet reachable IPs, or if the source network may be using them
          as CGN zone space. This situation would likely lead to additional
          technical issues during various leakage conditions, filter rule
          issues (routing) and for CDN or other third party providers who may
          be present within the source network, to name a few.</t>
        </section>

        <section title="Private">
          <t>In each of the use-cases for Shared Transition Space, it may be
          possible to instead use Private <xref target="RFC1918"></xref>
          address space. In situations where all endpoints in the network are
          managed by a single organization, this may be a viable option.
          However when end-sites are administered by different organizations
          and/or individuals, the possibility of address conflict becomes a
          significant risk to operations. Private <xref
          target="RFC1918"></xref> address space is not generally intended to
          be used for purposes which cross administrative domains. Further,
          these recommendations involve use of the Shared Transition Space to
          provide services in one administrative domain to leaf networks which
          are generally single-homed to the serving administrative domain.
          This is also a significant difference from the intent of Private
          <xref target="RFC1918"></xref> address space.</t>

          <t>A study of DNS traffic <xref target="v6ops-msg06187"></xref> has
          shown that effectively all of the existing Private <xref
          target="RFC1918"></xref> address space is currently being used by
          end-sites attached to the Internet. While individual network
          environments may vary in this regard, most SP operators face the
          risk that their use of Private address space will conflict with
          their customer end-sites. defined private space is not generally
          intended to be used for purposes which cross administrative
          domains.</t>

          <t>In the event of conflict, it is possible that the end-site CPE
          will fail and/or not function correctly. Some CPE implementations
          are known to support overlapping addresses on the "inside" and
          "outside" interfaces, however many others are known to fail under
          such circumstances. For SP operators, the Shared Transition Space
          offers a less risky alternative to GUA that retains the benefit of
          non-conflict.</t>

          <t>Also, the use of Private <xref target="RFC1918"></xref> address
          space on interfaces and hosts often causes default behaviors on such
          hosts which may not be desirable when the endpoint is actually
          connected to the Internet. There are often behavioral expectations
          for Internet connected endpoints, regardless of them being subject
          to a NAT.</t>

          <t>Incorrect affiliation of the WAN side interface being in a
          "protected" zone and/or on a trusted network may not be desirable.
          With NAT444 deployments, it is important that the endpoint (i.e.
          CPE) behave like any other Internet node. One example of this from
          our testing was observed behaviors where some CPEs did not filter
          and/or firewall correctly when Private <xref
          target="RFC1918"></xref> address space was used on both WAN and LAN
          interfaces.</t>
        </section>

        <section title="Class E">
          <t>One proposed alternative to Shared Transition Space is the
          re-classification and use of the 240.0.0.0/4 "Class E" address space
          as unicast. This has been proposed, for instance, by <xref
          target="I-D.fuller-240space"></xref> and <xref
          target="I-D.wilson-class-e"></xref>. While this alternative might be
          possible in tightly constrained environments, where all of the
          network elements are known to support Class E address space, it is
          not generally useful in the use-cases described above. At this time,
          a significant number of IPv4 stack implementations treat the Class E
          address space as reserved and will not route, forward, and/or
          originate traffic for that range. For example, <xref
          target="CISCO"></xref> states that: "No addresses are allowed with
          the highest-order bits set to 1111." For the scenarios described
          herein, it should be noted that this alternative would create
          additional SP dependencies on customer selected CPE support for
          Class E addressing.</t>
        </section>

        <section title="Prefix Squatting">
          <t>An unfortunate alternative to the Shared Transition Space is
          "prefix squatting", in which the operator re-uses another
          organization's IPv4 allocation for their own numbering needs. When
          this approach results in the other organization's prefix being
          announced globally by the "squatting" operator, it is often referred
          to as "prefix hijacking". However, this discussion is focused on
          scenarios in which the prefix is not announced globally but is,
          rather, used for internal numbering only.</t>

          <t>In this scenario, the allocation may not be routed globally by
          the legitimate address holder, making it attractive for such
          purposes. Or it may be routed but "uninteresting" to the SP
          network's endpoints. In either case there is a potential for
          conflict in the event that any end-site actually wishes to
          communicate with the legitimate address holder. Indeed, various RIRs
          attempt to discover and "recycle" abandoned or unused IPv4 address
          space, making it more likely that such conflicts will be experienced
          in time. As such, this alternative is to be discouraged with
          prejudice.</t>

          <t>It is important to note that there are no behavioral advantages
          to using "squat space" over using assigned "shared space". Both
          options subject the CPE to the same general behaviors (GUA space,
          but not globally reachable). The only real difference is the
          negative impacts of squatting (as noted above) and the advantages of
          a community coordinated and standardized prefix.</t>

          <t>The primary reason that any network would be likely to adopt
          "prefix squatting" is if they are faced with the operational
          realities of CGN before/without the allocation of a shared
          transition space.</t>
        </section>

        <section title="Regional Re-use of Allocated Prefix">
          <t>Similar to "Prefix Squatting" but significantly less dangerous,
          this alternative involves the reuse by an operator of their own
          address allocations. In this scenario, a network operator might use
          the same prefix for multiple "regions" and/or extranet communities.
          For instance, in CGN deployments the operator might reuse the same
          GUA prefix across multiple geographic regions (e.g. without
          announcing it globally).</t>

          <t>Here again, it is important to note that there are no behavioral
          advantages gained over a "shared space" but there is the added
          community cost of each network having to dedicate a unique block of
          addresses to this purpose, consuming far more resources than a
          single block of "shared space".</t>
        </section>

        <section title="Consortium">
          <t>In the event that the Internet community doesn't set aside an
          IPv4 prefix for Shared Transition Space, it is possible that a
          number of SP operators can come together and designate an address
          block to be "shared" amongst them for an identical purpose. This
          would have the same technical merits as an IETF and/or RIR sponsored
          Shared Transition Space, however it would lack the efficiency of a
          community coordinated and standardized prefix for such purposes,
          gain no behavioral advantages, remove the deterministic nature of
          managing a single range and also subjects the Internet (users of the
          space) to additional risk since any member of the consortium who has
          contributed space could later pull out and potentially cause
          disruptions in multiple networks.</t>
        </section>
      </section>
    </section>

    <section anchor="Analysis" title="Analysis of Benefits">
      <section title="Continued Operation Post-exhaustion">
        <t>Availability of a Shared Transition Space helps SPs continue to
        meet the demands of IPv4 addressing and/or connectivity post
        exhaustion. For environments where CGN in a NAT444 scenario is
        necessary, addresses from this space can be used to provide addressing
        for the network between the CGN device(s) and CPE which will enable
        IPv4 flow continuity for customers using these services. In other
        circumstances, the shared transition space allows SPs to number
        devices in the network which do not require global reachability
        without the need for fulfillment thorough an RIR.</t>
      </section>

      <section title="Delayed Need for CGN Deployment">
        <t>If operators are required to use their individually allocated GUA
        where "shared space" would have applied, e.g. for internal services,
        they will face exhaustion sooner and thus be forced to deploy CGN
        sooner as well. Operators may be able to postpone the deployment of
        CGN by using "shared space" for internal uses, because that allows
        more efficient use of their remaining GUA in places where global
        uniqueness is truly mandatory.</t>

        <t>Further, without this shared transition space, some service
        providers may be forced to reclaim GUA from existing customers in
        order to deploy CGN and address the required infrastructure. Having
        this transition space will enable deployment of CGN where it is
        required, in a manner that is less disruptive and with impact to fewer
        customers.</t>
      </section>

      <section title="Recovery of Existing Addresses">
        <t>The shared transition space can also be used to number and reclaim
        IPv4 addresses within provider networks which do not require global
        reachability. This option can be used by many networks worldwide, it
        provides an option for using currently assigned space much more
        efficiently.</t>

        <section title="Re-deployment Where Needed">
          <t>Operators can re-deploy recovered addresses for customers that
          need them (including new / static / GUA customers), hosted servers,
          etc. or to facilitate other efforts that might provide even more
          efficient use of GUA space within the network. The freed addresses
          can be assigned to endpoints which require IPv4 global reachablity
          and thus help delay and/or remove the need for CGN.</t>
        </section>

        <section title="Return or Transfer">
          <t>In cases where the operator is not deploying CGN and doesn't need
          the recovered addresses, they can be made available to others that
          do need them for connectivity to the public IPv4 Internet. This may
          be through voluntary return to the RIR, or through transfer to
          another network operator. For example, in the ARIN region, there are
          transfer mechanisms defined in the ARIN NRPM 8.3 <xref
          target="ARIN-NRPM-8.3"></xref>.</t>
        </section>
      </section>

      <section title="Impact on Allocations of RIR Inventory">
        <t>While making Shared Transition Space available to the community may
        or may not lessen the demand on the RIRs for allocations, it will help
        ensure that the address resources which remain in inventory are used
        most efficiently, maximizing the use of that inventory for services
        that require Global Unicast Addresses.</t>
      </section>

      <section title="Benefit of Standardization">
        <t>Standardizing on a single block will help the community develop
        standard ways of selecting, routing, filtering and managing shared
        space. This task would be much more difficult or impractical for any
        of the alternative options.</t>

        <t>Standard internal routing policy and filtering can be applied
        uniformly inside network environments. Additionally, exchange points
        between networks can have standard policies applied allowing operators
        to protect each other from CGN zone IPs leaking between networks. This
        may not be possible with squat space since many operators will not
        divulge what space may be used and with Private <xref
        target="RFC1918"></xref> address space where each operator may only be
        able to free up certain portions of the space which are not likely to
        be consistent between networks.</t>
      </section>

      <section title="IPv6 Deployments">
        <t>Operators will need to grapple with the need to provide IPv4 based
        flow continuity to customers post exhaustion. By removing the burden
        of operators needing to find adequate IPv4 address space to meet the
        needs that a Shared Transition Space can fulfill, they can concentrate
        on the real task at hand: Deploying IPv6.</t>
      </section>
    </section>

    <section title="Analysis of Detractors' Arguments">
      <section title="It Breaks">
        <section title="NAT is Bad">
          <t>NAT is understood to be less than optimal <xref
          target="RFC6269"></xref>, especially when implemented as CGN <xref
          target="I-D.donley-nat444-impacts"></xref>. That said, it is a
          necessary technology for many networks and cannot be completely
          avoided. Since the number of IPv4 Internet endpoints will exceed the
          number of IPv4 addresses which are available for Internet
          connectivity, NATs are needed.</t>

          <t>While the authors agree that "NAT is bad", it must also be
          understood that shared transition space does not change the
          fundamental motivations or issues with NAT and so those problems
          will not be discussed at length here.</t>
        </section>

        <section title="Breaks Assumptions about Address Scope">
          <t>Some host or CPE functions incorrectly assume global reachability
          based on the type of address that is configured, potentially causing
          issues when deployed in a NAT444 scenario. Whether an operator uses
          this proposed Shared Transition Space or some other GUA space (e.g.
          through squatting or reuse), the net effect on hosts and/or CPE
          making such assumptions about reachability is identical. Conversely,
          with an identified Shared Transition Space hosts that make these
          mistaken assumptions can be modified to treat the identified block
          as having restricted reachability semantics. This would not be
          possible (or at least not nearly as easy) with the other
          solutions.</t>

          <section title="6to4">
            <t>Although 6to4 can break in CGN scenarios using the Shared
            Transition Space, recent guidance suggests that it should be
            turned off by default. <xref target="RFC6343"></xref> <xref
            target="I-D.ietf-v6ops-6to4-to-historic"></xref> Indeed, recent
            versions of operating systems de-preference 6to4 addresses as
            described in <xref target="I-D.ietf-6man-rfc3484-revise"></xref>,
            mitigating effects from incorrect 6to4 instantiation behind a
            firewall that obstructs its function.</t>

            <t>Since the volume of impacted endpoints will be low, operators
            can likely manage the disabling of 6to4 when needed. More
            fundamentally, broken 6to4 should not be an issue if service
            providers deploy (and user equipment supports) native IPv6
            connectivity.</t>
          </section>
        </section>

        <section title="Potential Misuse as Private Space">
          <t>Shared Transition Space is intended to be used solely by Service
          Providers for IPv4 to IPv6 transition purposes. <xref
          target="I-D.weil-shared-transition-space-request"></xref> The value
          of a Shared Transition Space may be diminished if commonly misused
          by end-sites as generic Private addresses. Thus, the reservation
          must be clearly designated for use by SPs that are providing
          infrastructure as described herein.</t>
        </section>
      </section>

      <section title="It's Not Needed">
        <section title="Nobody Will Use It">
          <t>This argument is simply incorrect. Post IPv4-exaustion, any SP
          that wishes to continue providing IPv4 connectivity will necessarily
          deploy network architectures and technologies that require such an
          address space. Thus, in absense of a designated Shared Transition
          Space, operators will use GUA space in essentially the same ways
          described in this memo, with or without IETF or RIR
          acknowledgement.</t>
        </section>

        <section title="ISPs Are Not Actually Growing">
          <t>While customer growth for some ISPs has slowed, for many service
          providers new services are growing at a faster rate than has been
          anticipated. Wireline voice customers for example require two-way
          communication paths to allow them to function properly. IP enabled
          televisions is another example of devices that support video and
          voice services and require IP addresses. The only way to maintain
          these services, which in many cases are considered lifeline, is to
          provide them with an IP address that is unique within the service
          provider network.</t>

          <t>Likewise, growth continues to exist in some geographical regions.
          While some areas have slower growth, as a result of significant
          penetration of Internet access, there are still many areas with
          unmet needs, growing populations, or both.</t>
        </section>

        <section title="RIR IPv4 Inventory is Not Actually Exhausted">
          <t>With the IANA inventory essentially exhausted <xref
          target="NRO-IANA-exhaust"></xref> it is only a matter of time before
          each of the RIRs are unable to satisfy requests for IPv4 addresses.
          <xref target="GIH-When"></xref> In fact, the APNIC has already
          allocated all but their final /8 of inventory <xref
          target="APNIC-final-slash8"></xref> and is no longer making
          allocations larger than a /22 prefix. Each of the other RIRs is on a
          trajectory toward exhaustion in the near future.</t>
        </section>

        <section title="ISP IPv4 Inventory is Not Actually Exhausted">
          <t>While some SPs have existing inventory that will outlast the RIR
          inventories, this is not universally true. In fact, the distribution
          of IPv4 number resources amongst operators is highly variable (based
          on size, history, etc) and in the worst cases is already becoming
          problematic.</t>
        </section>
      </section>

      <section title="Address Inventory">
        <section title="Shared Transition Space Uses Up Address Inventory">
          <t>While true that this Shared Transition Space will remove a block
          of global unicast IPv4 addresses from the free pool, it must also be
          noted that the use of the same "shared space" repeatedly across
          multiple networks will very likely increase the available pool of
          unique IPv4 addresses through operational efficiency. For example,
          if just two operators use their own GUA /10, the Internet community
          effectively loses a /9 of unique space while if both operators use
          the same "shared" /10, the Internet community loses that single /10.
          This benefit becomes more significant as more operators use the
          Shared Transition Space.</t>

          <t>It remains to be seen whether the reservation of a Shared
          Transition Space will actually delay the impending exhaustion of
          RIRs' IPv4 inventory. Certainly, the availability of this Shared
          Transition Space will satisfy a number of demands that would
          otherwise become requests for GUA resources. However, whether this
          translates to an actual reduction in requests is up to the RIRs and
          requesting organizations. Regardless of the allocation of Shared
          Transition Space, RIR IPv4 exhaustion may happen at roughly the same
          time. However, as noted above, Shared Transition Space does provide
          the opportunity for more efficient use of the remaining RIR IPv4
          addresses. Additionally, the reservation of a Shared Transition
          Space will enable continued deployment of IPv4 connectivity by SP
          networks beyond the free pool depletion horizon; another clear
          benefit.</t>
        </section>

        <section title="/10 is not Enough">
          <t>Although previous requests for Shared Transition Space asked for
          a full /8, it has been determined by many operators that a /10 will
          in fact be sufficient. A /10 provides for roughly 4 million hosts
          and although many of the largest SPs have subscriber counts in the
          tens of millions, none will be placing all of their subscribers
          behind a single CGN. In the event that a /10 does not provide enough
          addresses for an operators entire CGN deployment, it could be
          re-used multiple times in distinct "NAT zones" or regions.</t>
        </section>
      </section>

      <section title="IPv6 Arguments">
        <section title="Use IPv6 Instead">
          <t>Although IPv6 is the strategic long term answer for IPv4 address
          exhaustion, it does not immediately solve IPv4 connectivity
          requirements. There is an entire eco-system which exists on the
          Internet today and is not IPv6 ready at this time <xref
          target="I-D.arkko-ipv6-only-experience"></xref>. IPv4 flow
          continuity will be required for at least several years.</t>

          <t>Many businesses have long procurement and fulfillment cycles
          which will need to be used to upgrade networks to support IPv6.
          Also, the consumer (home) space is years away from being all IPv6
          capable. Many homes are filled with IPv4 only consumer electronics,
          computers, TVs, accessories and other systems.</t>

          <t>There are still a number of products that are either not IPv6
          compliant, or for which the necessary criteria for being "IPv6
          compliant" is unclear or undefined. Some examples include security
          products, a large number of software applications, and there are
          still production systems (both inside companies and as products)
          being rolled out that are not IPv6 aware.</t>
        </section>

        <section title="Delay of IPv6 Deployment">
          <t>The whole Internet needs to get to IPv6 more or less at the same
          time in order to avoid significant deployment of transition
          technologies. This proposal may help delay some transition
          technology deployment while IPv6 deployments move ahead. More IPv6
          should mean less transition technology.</t>
        </section>
      </section>
    </section>

    <section anchor="Policy" title="ARIN Draft Policy 2011-5">
      <section title="History">
        <section title="Shared Address Space">
          <t>Proposals for additional Private space date back at least to
          <xref target="I-D.hain-1918bis"></xref> in April 2004. Some of these
          proposals and surrounding discussion may have considered similar
          use-cases as described herein. However, they were fundamentally
          intended to increase the size of the <xref target="RFC1918"></xref>
          pool, whereas a defining characteristic of Shared Transition Space
          is that it is distinctly not part of the Private <xref
          target="RFC1918"></xref> address pool.</t>

          <t>Rather, the Shared Transition Space is reserved for more narrow
          deployment scenarios, specifically for use by SPs to meet the needs
          of ongoing IPv4 connectivity during the period of IPv6 transition.
          This key feature emerged in more recent proposals such as <xref
          target="I-D.shirasaki-isp-shared-addr"></xref> in June 2008 where a
          proposal to set aside "ISP Shared Space" was made. During discussion
          of these more recent proposals, many of the salient points where
          commented upon, including challenges with RFC1918 in the ISP NAT
          Zone, Avoidance of IP Address Conflicts, and challenges with
          240/4.</t>

          <t>This effort was followed up by <xref
          target="I-D.weil-opsawg-provider-address-space"></xref> in July 2010
          which was re-worked in November 2010 as <xref
          target="I-D.weil-shared-transition-space-request"></xref>. These
          latter efforts continued to point out the operators' need for Shared
          Transition Space, with full acknowledgement that challenges may
          arise with NAT444 as per <xref
          target="I-D.donley-nat444-impacts"></xref> and that such space does
          not reduce the need for IPv6 deployment.</t>

          <t>Most recently, following exhaustion of the IANA's /8 pool <xref
          target="NRO-IANA-exhaust"></xref>, this proposal has been discussed
          by various RIR policy development participants. As described herein,
          the body of ARIN policy development participants has reached
          consensus and recommended a Shared Address Space policy for adoption
          <xref target="ARIN-2011-5"></xref>.</t>

          <t>This history shows that operators and other industry contributors
          have consistently identified the need for a Shared Transition Space
          assignment, based on pragmatic operational needs. The previous work
          has also described the awareness of the challenges of this space,
          but points to this option as the most manageable and workable
          solution for IPv6 transition space.</t>
        </section>

        <section title="Proposal">
          <t>The following is a brief history of the proposal for Shared
          Address Space within ARIN, ultimately resulting in the
          recommendation of ARIN Draft Policy 2011-5 <xref
          target="ARIN-2011-5"></xref>.</t>

          <t>In January 2011, a policy was proposed to the ARIN policy
          development community called ARIN-prop-127: Shared Transition Space
          for IPv4 Address Extension <xref target="ARIN-prop-127"></xref>.
          This policy proposal would reserve an IPv4 /10 prefix by ARIN, to be
          shared by any Service Providers who wish to use it with no further
          registration actions required.</t>

          <t>After generating much discussion (over 100 posts) on the ARIN
          Public Policy Mailing List (PPML), the ARIN Advisory Council (AC)
          accepted the proposal as Draft Policy 2011-5 <xref
          target="ARIN-AC-28Jan2011"></xref>, formally announced on PPML 3
          February 2011 <xref target="ARIN-2011-5-AC"></xref>.</t>

          <t>On 14 February 2011, ARIN staff made the following statement with
          regard to 2011-5: "In keeping with the spirit of RFC 2860 with
          respect to the assignment of specialized address blocks, ARIN Staff
          will consult with the IANA and the IAB regarding implementation of
          this draft policy." <xref target="ARIN-2011-5-Staff"></xref></t>

          <t>In the ensuing PPML discussion there was a roughly two to one
          ratio of those clearly in support of the policy versus those clearly
          against. ARIN Draft Policy 2011-5 was then discussed at the ARIN
          XXVII public policy meeting on 12 April 2011. Following the
          discussion, there was a straw poll of the room. With a total number
          of people in the meeting room and remote of 116; in favor of it were
          30 and against it were 15. <xref target="ARIN27.2011-5"></xref></t>

          <t>Seeing an obvious need in the service provider community, the AC
          voted to send the Draft Policy to last call <xref
          target="ARIN-AC-13Apr2011"></xref> for final comments 18 April
          through 2 May 2011. <xref target="ARIN-2011-5-LC"></xref> Following
          a strong show of support from the operator community during last
          call, the AC voted <xref target="ARIN-AC-19May2011"></xref> to
          recommend adoption of 2011-5 to the ARIN Board of Trustees with a
          vote of 10 in favor and 2 abstentions. <xref
          target="ARIN-2011-5-Rec"></xref></t>

          <t>Following this recommendation, ARIN staff consulted with the IAB
          and IANA as committed. The IAB response <xref
          target="IAB-response"></xref> stated, in short, that they believed
          the adoption of <xref target="ARIN-2011-5"></xref> was in conflict
          with the provisions in <xref target="RFC2860"></xref> and requested
          that the community re-review the operational and technical merits of
          shared transition space in the IETF. That process is now underway,
          with this draft an attempt at more fully analyzing said operational
          and technical merits.</t>
        </section>
      </section>

      <section title="Policy Text">
        <t>Draft Policy ARIN-2011-5</t>

        <t>Shared Transition Space for IPv4 Address Extension</t>

        <t>Date: 20 January 2011</t>

        <t>Policy statement:</t>

        <t>Updates 4.10 of the NRPM:</t>

        <t>A second contiguous /10 IPv4 block will be reserved to facilitate
        IPv4 address extension. This block will not be allocated or assigned
        to any single organization, but is to be shared by Service Providers
        for internal use for IPv4 address extension deployments until
        connected networks fully support IPv6. Examples of such needs include:
        IPv4 addresses between home gateways and NAT444 translators.</t>

        <t>Rationale:</t>

        <t>The Internet community is rapidly consuming the remaining supply of
        unallocated IPv4 addresses. During the transition period to IPv6, it
        is imperative that Service Providers maintain IPv4 service for devices
        and networks that are currently incapable of upgrading to IPv6.
        Consumers must be able to reach the largely IPv4 Internet after
        exhaustion. Without a means to share addresses, people or
        organizations who gain Internet access for the first time, or those
        who switch providers, or move to another area, will be unable to reach
        the IPv4 Internet.</t>

        <t>Further, many CPE router devices used to provide residential or
        small-medium business services have been optimized for IPv4 operation,
        and typically require replacement in order to fully support the
        transition to IPv6 (either natively or via one of many transition
        technologies). In addition, various consumer devices including
        IP-enabled televisions, gaming consoles, medical and family monitoring
        devices, etc. are IPv4-only, and cannot be upgraded. While these will
        eventually be replaced with dual-stack or IPv6 capable devices, this
        transition will take many years. As these are typically consumer-owned
        devices, service providers do not have control over the speed of their
        replacement cycle. However, consumers have an expectation that they
        will continue to receive IPv4 service, and that such devices will
        continue to have IPv4 Internet connectivity after the IPv4 pool is
        exhausted, even if the customer contracts for new service with a new
        provider.</t>

        <t>Until such customers replace their Home Gateways and all IPv4-only
        devices with IPv6-capable devices, Service Providers will be required
        to continue to offer IPv4 services through the use of an IPv4 address
        sharing technology such as NAT444. A recent study showed that there is
        no part of RFC1918 space which would not overlap with some IPv4
        gateways, and therefore to prevent address conflicts, new address
        space is needed.</t>

        <t>Service providers are currently presented with three options for
        obtaining sufficient IPv4 address space for NAT444/IPv4 extension
        deployments: (1) Request allocations under the NRPM; (2) share address
        space with other providers (this proposal); or (3) use address space
        allocated to another entity (i.e. 'squat'). Of the three options,
        option 2 (this proposal) is preferable, as it will minimize the number
        of addresses used for IPv4 extension deployments while preserving the
        authority of IANA and RIRs.</t>

        <t>Timetable for implementation: immediately</t>
      </section>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank the following individuals for their
      contributions: John Curran, David Farmer, Jeffrey Finkelstein, William
      Herrin, and Dan Wing.</t>

      <t>The authors would also like to thank the following people for their
      review, comments, and support: Gary Buhrmaster, Chris Donley, Wes
      George, Chris Metz, Richard Von Scherr, and Lane Wigley.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>Upon notification by the IAB that that an address reservation should
      be made, ARIN is willing to proceed with the implementation of its Draft
      Policy 2011-5 which would result in ARIN reserving IPv4 /10 block for
      shared transition. The IANA is to record the allocation of the IPv4
      address block for this purpose. Alternatively, the IAB may direct the
      IANA to request return of sufficient address space from ARIN's available
      IPv4 number resource pool to allow the IANA to perform this reservation
      directly.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This memo makes reference to a number of deployment scenarios that
      have unique security considerations, and the reader is advised to
      investigate these independently.</t>

      <t>While this memo does not introduce any specific technical issues that
      may be subject to detailed security considerations, it does reccommend
      the reservation of a new IPv4 address space that might have unique
      properties when deployed. As such, all implementors of this Shared
      Transition Space are encouraged to consider carefully the best practices
      associated with the use of this space, including considerations relating
      to filtering, routing, etc.</t>
    </section>
  </middle>

  <back>
    <references title="Informative References">
      <reference anchor="RFC1918">
        <front>
          <title>Address Allocation for Private Internets</title>

          <author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
            <organization>Cisco systems</organization>

            <address>
              <postal>
                <street>170 West Tasman Drive</street>

                <city>San Jose</city>

                <region>CA</region>

                <code>95134-1706</code>

                <country>US</country>
              </postal>

              <phone>+1 914 528 0090</phone>

              <facsimile>+1 408 526 4952</facsimile>

              <email>yakov@cisco.com</email>
            </address>
          </author>

          <author fullname="Robert G. Moskowitz" initials="R."
                  surname="Moskowitz">
            <organization>Chrysler Corporation</organization>

            <address>
              <postal>
                <street>25999 Lawrence Ave</street>

                <city>Center Line</city>

                <region>MI</region>

                <code>48015</code>

                <country>US</country>
              </postal>

              <phone>+1 810 758 8212</phone>

              <facsimile>+1 810 758 8173</facsimile>

              <email>rgm3@is.chrysler.com</email>
            </address>
          </author>

          <author fullname="Daniel Karrenberg" initials="D."
                  surname="Karrenberg">
            <organization>RIPE Network Coordination Centre</organization>

            <address>
              <postal>
                <street>Kruislaan 409</street>

                <city>Amsterdam</city>

                <region></region>

                <code>1098 SJ</code>

                <country>NL</country>
              </postal>

              <phone>+31 20 5925065</phone>

              <facsimile>+31 20 5925090</facsimile>

              <email>Daniel.Karrenberg@ripe.net</email>
            </address>
          </author>

          <author fullname="Geert Jan de Groot" initials="G." surname="Groot">
            <organization>RIPE Network Coordination Centre</organization>

            <address>
              <postal>
                <street>Kruislaan 409</street>

                <city>Amsterdam</city>

                <region></region>

                <code>1098 SJ</code>

                <country>NL</country>
              </postal>

              <phone>+31 20 5925065</phone>

              <facsimile>+31 20 5925090</facsimile>

              <email>GeertJan.deGroot@ripe.net</email>
            </address>
          </author>

          <author fullname="Eliot Lear" initials="E." surname="Lear">
            <organization>Silicon Graphics, Inc.</organization>

            <address>
              <postal>
                <street>2011 N. Shoreline Blvd.</street>

                <street>Mail Stop 15-730</street>

                <city>Mountain View</city>

                <region>CA</region>

                <code>94043-1389</code>

                <country>US</country>
              </postal>

              <phone>+1 415 960 1980</phone>

              <facsimile>+1 415 961 9584</facsimile>

              <email>lear@sgi.com</email>
            </address>
          </author>

          <date month="February" year="1996" />
        </front>

        <seriesInfo name="BCP" value="5" />

        <seriesInfo name="RFC" value="1918" />

        <format octets="22270"
                target="http://www.rfc-editor.org/rfc/rfc1918.txt" type="TXT" />
      </reference>

      <reference anchor="RFC4364">
        <front>
          <title>BGP/MPLS IP Virtual Private Networks (VPNs)</title>

          <author fullname="E. Rosen" initials="E." surname="Rosen">
            <organization></organization>
          </author>

          <author fullname="Y. Rekhter" initials="Y." surname="Rekhter">
            <organization></organization>
          </author>

          <date month="February" year="2006" />

          <abstract>
            <t>This document describes a method by which a Service Provider
            may use an IP backbone to provide IP Virtual Private Networks
            (VPNs) for its customers. This method uses a "peer model", in
            which the customers' edge routers (CE routers) send their routes
            to the Service Provider's edge routers (PE routers); there is no
            "overlay" visible to the customer's routing algorithm, and CE
            routers at different sites do not peer with each other. Data
            packets are tunneled through the backbone, so that the core
            routers do not need to know the VPN routes. [STANDARDS-TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4364" />

        <format octets="116446"
                target="http://www.rfc-editor.org/rfc/rfc4364.txt" type="TXT" />
      </reference>

      <reference anchor="RFC2860">
        <front>
          <title>Memorandum of Understanding Concerning the Technical Work of
          the Internet Assigned Numbers Authority</title>

          <author fullname="B. Carpenter" initials="B." surname="Carpenter">
            <organization></organization>
          </author>

          <author fullname="F. Baker" initials="F." surname="Baker">
            <organization></organization>
          </author>

          <author fullname="M. Roberts" initials="M." surname="Roberts">
            <organization></organization>
          </author>

          <date month="June" year="2000" />

          <abstract>
            <t>This document places on record the text of the Memorandum of
            Understanding concerning the technical work of the IANA that was
            signed on March 1, 2000 between the IETF and ICANN, and ratified
            by the ICANN Board on March 10, 2000. This memo provides
            information for the Internet community.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="2860" />

        <format octets="12361"
                target="http://www.rfc-editor.org/rfc/rfc2860.txt" type="TXT" />
      </reference>

      <reference anchor="I-D.ietf-behave-lsn-requirements">
        <front>
          <title>Common requirements for Carrier Grade NAT (CGN)</title>

          <author fullname="Simon Perreault" initials="S" surname="Perreault">
            <organization></organization>
          </author>

          <author fullname="Ikuhei Yamagata" initials="I" surname="Yamagata">
            <organization></organization>
          </author>

          <author fullname="Shin Miyakawa" initials="S" surname="Miyakawa">
            <organization></organization>
          </author>

          <author fullname="Akira Nakagawa" initials="A" surname="Nakagawa">
            <organization></organization>
          </author>

          <author fullname="Hiroyuki Ashida" initials="H" surname="Ashida">
            <organization></organization>
          </author>

          <date day="18" month="August" year="2011" />

          <abstract>
            <t>This document defines common requirements for Carrier-Grade NAT
            (CGN).</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft"
                    value="draft-ietf-behave-lsn-requirements-03" />

        <format target="http://www.ietf.org/internet-drafts/draft-ietf-behave-lsn-requirements-03.txt"
                type="TXT" />
      </reference>

      <reference anchor="I-D.donley-nat444-impacts">
        <front>
          <title>Assessing the Impact of NAT444 on Network
          Applications</title>

          <author fullname="Chris Donley" initials="C" surname="Donley">
            <organization></organization>
          </author>

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

          <author fullname="Victor Kuarsingh" initials="V" surname="Kuarsingh">
            <organization></organization>
          </author>

          <author fullname="Abishek Chandrasekaran" initials="A"
                  surname="Chandrasekaran">
            <organization></organization>
          </author>

          <author fullname="Vivek Ganti" initials="V" surname="Ganti">
            <organization></organization>
          </author>

          <date day="25" month="October" year="2010" />

          <abstract>
            <t>NAT444 is an IPv4 extension technology being considered by
            Service Providers to continue offering IPv4 service to customers
            while transitioning to IPv6. This technology adds an extra
            Large-Scale NAT ("LSN") in the Service Provider network, often
            resulting in two NATs. CableLabs, Time Warner Cable, and Rogers
            Communications independently tested the impacts of NAT444 on many
            popular Internet services using a variety of test scenarios,
            network topologies, and vendor equipment. This document identifies
            areas where adding a second layer of NAT disrupts the
            communication channel for common Internet applications.</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft"
                    value="draft-donley-nat444-impacts-01" />

        <format target="http://www.ietf.org/internet-drafts/draft-donley-nat444-impacts-01.txt"
                type="TXT" />
      </reference>

      <reference anchor="I-D.weil-shared-transition-space-request">
        <front>
          <title>IANA Reserved IPv4 Prefix for Shared Transition Space</title>

          <author fullname="Jason Weil" initials="J" surname="Weil">
            <organization></organization>
          </author>

          <author fullname="Victor Kuarsingh" initials="V" surname="Kuarsingh">
            <organization></organization>
          </author>

          <author fullname="Chris Donley" initials="C" surname="Donley">
            <organization></organization>
          </author>

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

          <author fullname="Marla Azinger" initials="M" surname="Azinger">
            <organization></organization>
          </author>

          <date day="2" month="August" year="2011" />

          <abstract>
            <t>This document requests a reserved IANA IPv4 address allocation
            as Shared Transition Space to support the deployment of IPv4
            address sharing technologies post IPv4 exhaustion</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft"
                    value="draft-weil-shared-transition-space-request-03" />

        <format target="http://www.ietf.org/internet-drafts/draft-weil-shared-transition-space-request-03.txt"
                type="TXT" />
      </reference>

      <reference anchor="I-D.weil-opsawg-provider-address-space">
        <front>
          <title>IANA Reserved IPv4 Prefix for IPv6 Transition</title>

          <author fullname="Jason Weil" initials="J" surname="Weil">
            <organization></organization>
          </author>

          <author fullname="Victor Kuarsingh" initials="V" surname="Kuarsingh">
            <organization></organization>
          </author>

          <author fullname="Chris Donley" initials="C" surname="Donley">
            <organization></organization>
          </author>

          <date day="24" month="September" year="2010" />

          <abstract>
            <t>This document specifies the use of a reserved IANA IPv4 address
            allocation to support the deployment of IPv6 transition
            technologies and IPv4 address sharing technologies post IPv4
            exhaustion. Service providers are in the process of implementing
            IPv6 support by providing dual-stack IPv4 and IPv6 services to
            their end-users. One method for continued support of the IPv4
            Internet post IANA IPv4 depletion is through the use of a
            carrier-provided NAT444 infrastructure. Another mechanism used to
            transition to IPv6 is an IPv6-in-IPv4 tunnel such as IPv6 Rapid
            Deployment (6RD). This document details the use of an IANA
            reserved address block for these purposes.</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft"
                    value="draft-weil-opsawg-provider-address-space-02" />

        <format target="http://www.ietf.org/internet-drafts/draft-weil-opsawg-provider-address-space-02.txt"
                type="TXT" />
      </reference>

      <reference anchor="I-D.shirasaki-isp-shared-addr">
        <front>
          <title>ISP Shared Address</title>

          <author fullname="Ikuhei Yamagata" initials="I" surname="Yamagata">
            <organization></organization>
          </author>

          <author fullname="Shin Miyakawa" initials="S" surname="Miyakawa">
            <organization></organization>
          </author>

          <author fullname="Akira Nakagawa" initials="A" surname="Nakagawa">
            <organization></organization>
          </author>

          <author fullname="Jiro Yamaguchi" initials="J" surname="Yamaguchi">
            <organization></organization>
          </author>

          <author fullname="Hiroyuki Ashida" initials="H" surname="Ashida">
            <organization></organization>
          </author>

          <date day="10" month="July" year="2011" />

          <abstract>
            <t>This document defines IPv4 ISP Shared Address to be jointly
            used among Internet Service Providers (ISPs). This space is
            intended to be used in NAT444 model which is used during the
            transition period to IPv6.</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft"
                    value="draft-shirasaki-isp-shared-addr-06" />

        <format target="http://www.ietf.org/internet-drafts/draft-shirasaki-isp-shared-addr-06.txt"
                type="TXT" />
      </reference>

      <reference anchor="I-D.shirasaki-nat444-isp-shared-addr">
        <front>
          <title>NAT444 addressing models</title>

          <author fullname="Jiro Yamaguchi" initials="J" surname="Yamaguchi">
            <organization></organization>
          </author>

          <author fullname="Yasuhiro Shirasaki" initials="Y"
                  surname="Shirasaki">
            <organization></organization>
          </author>

          <author fullname="Shin Miyakawa" initials="S" surname="Miyakawa">
            <organization></organization>
          </author>

          <author fullname="Akira Nakagawa" initials="A" surname="Nakagawa">
            <organization></organization>
          </author>

          <author fullname="Hiroyuki Ashida" initials="H" surname="Ashida">
            <organization></organization>
          </author>

          <date day="10" month="July" year="2011" />

          <abstract>
            <t>This document describes addressing models of NAT444. There are
            some addressing models of NAT444. The addressing models have some
            issues of network behaviors, operations, and addressing. This
            document helps network architects to use NAT444 after IPv4 address
            exhaustion.</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft"
                    value="draft-shirasaki-nat444-isp-shared-addr-06" />

        <format target="http://www.ietf.org/internet-drafts/draft-shirasaki-nat444-isp-shared-addr-06.txt"
                type="TXT" />
      </reference>

      <reference anchor="I-D.shirasaki-nat444">
        <front>
          <title>NAT444</title>

          <author fullname="Ikuhei Yamagata" initials="I" surname="Yamagata">
            <organization></organization>
          </author>

          <author fullname="Yasuhiro Shirasaki" initials="Y"
                  surname="Shirasaki">
            <organization></organization>
          </author>

          <author fullname="Akira Nakagawa" initials="A" surname="Nakagawa">
            <organization></organization>
          </author>

          <author fullname="Jiro Yamaguchi" initials="J" surname="Yamaguchi">
            <organization></organization>
          </author>

          <author fullname="Hiroyuki Ashida" initials="H" surname="Ashida">
            <organization></organization>
          </author>

          <date day="10" month="July" year="2011" />

          <abstract>
            <t>This document describes one of the network models that are
            designed for smooth transition to IPv6. It is called NAT444 model.
            NAT444 model is composed of IPv6, and IPv4 with Large Scale NAT
            (LSN). NAT444 is the only scheme not to require replacing Customer
            Premises Equipment (CPE) even if IPv4 address exhausted. But it
            must be noted that NAT444 has serious restrictions i.e. it limits
            the number of sessions per CPE so that rich applications such as
            AJAX and RSS feed cannot work well. Therefore, IPv6 which is free
            from such a difficulty has to be introduced into the network at
            the same time. In other words, NAT444 is just a tool to make IPv6
            transition easy to be swallowed. It is designed for the days IPv4
            and IPv6 co-existence.</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft" value="draft-shirasaki-nat444-04" />

        <format target="http://www.ietf.org/internet-drafts/draft-shirasaki-nat444-04.txt"
                type="TXT" />
      </reference>

      <reference anchor="I-D.ietf-6man-rfc3484-revise">
        <front>
          <title>Update to RFC 3484 Default Address Selection for IPv6</title>

          <author fullname="Arifumi Matsumoto" initials="A"
                  surname="Matsumoto">
            <organization></organization>
          </author>

          <author fullname="Jun-ya Kato" initials="J" surname="Kato">
            <organization></organization>
          </author>

          <author fullname="Tomohiro Fujisaki" initials="T" surname="Fujisaki">
            <organization></organization>
          </author>

          <author fullname="Tim Chown" initials="T" surname="Chown">
            <organization></organization>
          </author>

          <date day="1" month="July" year="2011" />

          <abstract>
            <t>RFC 3484 describes algorithms for source address selection and
            for destination address selection. The algorithms specify default
            behavior for all Internet Protocol version 6 (IPv6)
            implementations. This document specifies a set of updates that
            modify the algorithms and fix the known defects.</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft"
                    value="draft-ietf-6man-rfc3484-revise-04" />

        <format target="http://www.ietf.org/internet-drafts/draft-ietf-6man-rfc3484-revise-04.txt"
                type="TXT" />
      </reference>

      <reference anchor="RFC6269">
        <front>
          <title>Issues with IP Address Sharing</title>

          <author fullname="M. Ford" initials="M." surname="Ford">
            <organization></organization>
          </author>

          <author fullname="M. Boucadair" initials="M." surname="Boucadair">
            <organization></organization>
          </author>

          <author fullname="A. Durand" initials="A." surname="Durand">
            <organization></organization>
          </author>

          <author fullname="P. Levis" initials="P." surname="Levis">
            <organization></organization>
          </author>

          <author fullname="P. Roberts" initials="P." surname="Roberts">
            <organization></organization>
          </author>

          <date month="June" year="2011" />

          <abstract>
            <t>The completion of IPv4 address allocations from IANA and the
            Regional Internet Registries (RIRs) is causing service providers
            around the world to question how they will continue providing IPv4
            connectivity service to their subscribers when there are no longer
            sufficient IPv4 addresses to allocate them one per subscriber.
            Several possible solutions to this problem are now emerging based
            around the idea of shared IPv4 addressing. These solutions give
            rise to a number of issues, and this memo identifies those common
            to all such address sharing approaches. Such issues include
            application failures, additional service monitoring complexity,
            new security vulnerabilities, and so on. Solution-specific
            discussions are out of scope.&lt;/t&gt;&lt;t&gt; Deploying IPv6 is
            the only perennial way to ease pressure on the public IPv4 address
            pool without the need for address sharing mechanisms that give
            rise to the issues identified herein. This document is not an
            Internet Standards Track specification; it is published for
            informational purposes.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="6269" />

        <format octets="71660"
                target="http://www.rfc-editor.org/rfc/rfc6269.txt" type="TXT" />
      </reference>

      <reference anchor="RFC6319">
        <front>
          <title>Issues Associated with Designating Additional Private IPv4
          Address Space</title>

          <author fullname="M. Azinger" initials="M." surname="Azinger">
            <organization></organization>
          </author>

          <author fullname="L. Vegoda" initials="L." surname="Vegoda">
            <organization></organization>
          </author>

          <date month="July" year="2011" />

          <abstract>
            <t>When a private network or internetwork grows very large, it is
            sometimes not possible to address all interfaces using private
            IPv4 address space because there are not enough addresses. This
            document describes the problems faced by those networks, the
            available options, and the issues involved in assigning a new
            block of private IPv4 address space.&lt;/t&gt;&lt;t&gt; While this
            informational document does not make a recommendation for action,
            it documents the issues surrounding the various options that have
            been considered. This document is not an Internet Standards Track
            specification; it is published for informational purposes.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="6319" />

        <format octets="26939"
                target="http://www.rfc-editor.org/rfc/rfc6319.txt" type="TXT" />
      </reference>

      <reference anchor="I-D.fuller-240space">
        <front>
          <title>Reclassifying 240/4 as usable unicast address space</title>

          <author fullname="Vince Fuller" initials="V" surname="Fuller">
            <organization></organization>
          </author>

          <date day="25" month="March" year="2008" />

          <abstract>
            <t>This memo reclassifies the address block 240.0.0.0/4 as usable
            address space. While the community has not concluded whether the
            block should be considered public or private, given the current
            consumption rate, it is clear that the block should not be left
            unused. This document also makes several recommendations on ways
            that current implementations of the IP protocol stack will need to
            be modified to make this address space usable.</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft" value="draft-fuller-240space-02" />

        <format target="http://www.ietf.org/internet-drafts/draft-fuller-240space-02.txt"
                type="TXT" />
      </reference>

      <reference anchor="I-D.wilson-class-e">
        <front>
          <title>Redesignation of 240/4 from "Future Use" to "Private
          Use"</title>

          <author fullname="Paul Wilson" initials="P" surname="Wilson">
            <organization></organization>
          </author>

          <author fullname="George Michaelson" initials="G"
                  surname="Michaelson">
            <organization></organization>
          </author>

          <author fullname="Geoff Huston" initials="G" surname="Huston">
            <organization></organization>
          </author>

          <date day="29" month="September" year="2008" />

          <abstract>
            <t>This document directs the IANA to designate the block of IPv4
            addresses from 240.0.0.0 to 255.255.255.255 (240.0.0.0/4) as
            unicast address space for Private Use.</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft" value="draft-wilson-class-e-02" />

        <format target="http://www.ietf.org/internet-drafts/draft-wilson-class-e-02.txt"
                type="TXT" />
      </reference>

      <reference anchor="I-D.ietf-v6ops-6to4-to-historic">
        <front>
          <title>Request to move Connection of IPv6 Domains via IPv4 Clouds
          (6to4) to Historic status</title>

          <author fullname="Ole Troan" initials="O" surname="Troan">
            <organization></organization>
          </author>

          <date day="24" month="June" year="2011" />

          <abstract>
            <t>Experience with the "Connection of IPv6 Domains via IPv4 Clouds
            (6to4)" IPv6 transitioning mechanism has shown that the mechanism
            is unsuitable for widespread deployment and use in the Internet.
            This document requests that RFC3056 and the companion document "An
            Anycast Prefix for 6to4 Relay Routers" RFC3068 are made obsolete
            and moved to historic status.</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft"
                    value="draft-ietf-v6ops-6to4-to-historic-05" />

        <format target="http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-to-historic-05.txt"
                type="TXT" />
      </reference>

      <reference anchor="RFC6343">
        <front>
          <title>Advisory Guidelines for 6to4 Deployment</title>

          <author fullname="B. Carpenter" initials="B." surname="Carpenter">
            <organization></organization>
          </author>

          <date month="August" year="2011" />

          <abstract>
            <t>This document provides advice to network operators about
            deployment of the 6to4 technique for automatic tunneling of IPv6
            over IPv4. It is principally addressed to Internet Service
            Providers (ISPs), including those that do not yet support IPv6,
            and to Content Providers. Some advice to implementers is also
            included. The intention of the advice is to minimize both user
            dissatisfaction and help-desk calls. This document is not an
            Internet Standards Track specification; it is published for
            informational purposes.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="6343" />

        <format octets="51496"
                target="http://www.rfc-editor.org/rfc/rfc6343.txt" type="TXT" />
      </reference>

      <reference anchor="I-D.arkko-ipv6-only-experience">
        <front>
          <title>Experiences from an IPv6-Only Network</title>

          <author fullname="Jari Arkko" initials="J" surname="Arkko">
            <organization></organization>
          </author>

          <author fullname="Ari Keranen" initials="A" surname="Keranen">
            <organization></organization>
          </author>

          <date day="26" month="April" year="2011" />

          <abstract>
            <t>This document discusses our experiences from moving a small
            number of users to an IPv6-only network, with access to the
            IPv4-only parts of the Internet via a NAT64 device. The document
            covers practical experiences as well as road blocks and
            opportunities for this type of a network setup. The document also
            makes some recommendations about where such networks are
            applicable and what should be taken into account in the network
            design. The document also discusses further work that is needed to
            make IPv6-only networking applicable in all environments.</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft"
                    value="draft-arkko-ipv6-only-experience-03" />

        <format target="http://www.ietf.org/internet-drafts/draft-arkko-ipv6-only-experience-03.txt"
                type="TXT" />
      </reference>

      <reference anchor="ARIN-prop-127"
                 target="http://lists.arin.net/pipermail/arin-ppml/2011-January/019278.html">
        <front>
          <title>ARIN-prop-127: Shared Transition Space for IPv4 Address
          Extension</title>

          <author fullname="Chris Donley" initials="C." surname="Donley">
            <organization>CableLabs</organization>
          </author>

          <date day="20" month="Jan" year="2011" />
        </front>
      </reference>

      <reference anchor="ARIN27.2011-5"
                 target="https://www.arin.net/participate/meetings/reports/ARIN_XXVII/ppm2_transcript.html#anchor_6">
        <front>
          <title>ARIN XXVII Meeting - Participant Vote on 2011-5</title>

          <author>
            <organization>ARIN</organization>
          </author>

          <date day="12" month="Apr" year="2011" />
        </front>
      </reference>

      <reference anchor="ARIN-2011-5"
                 target="https://www.arin.net/policy/proposals/2011_5.html">
        <front>
          <title>Draft Policy ARIN-2011-5: Shared Transition Space for IPv4
          Address Extension</title>

          <author>
            <organization>ARIN</organization>
          </author>

          <date year="2011" />
        </front>
      </reference>

      <reference anchor="ARIN-2011-5-AC"
                 target="http://lists.arin.net/pipermail/arin-ppml/2011-February/019579.html">
        <front>
          <title>Message to ARIN-PPML, announcing selection of ARIN-prop-127
          for Discussion as Draft Policy 2011-5</title>

          <author>
            <organization>ARIN</organization>
          </author>

          <date day="3" month="Feb" year="2011" />
        </front>
      </reference>

      <reference anchor="ARIN-2011-5-Staff"
                 target="http://lists.arin.net/pipermail/arin-ppml/2011-February/019805.html">
        <front>
          <title>Message to ARIN-PPML, providing additional ARIN Staff
          Assessment of Draft Policy 2011-5</title>

          <author>
            <organization>ARIN</organization>
          </author>

          <date day="14" month="Feb" year="2011" />
        </front>
      </reference>

      <reference anchor="ARIN-2011-5-LC"
                 target="http://lists.arin.net/pipermail/arin-ppml/2011-April/020808.html">
        <front>
          <title>Message to ARIN-PPML, announcing Last Call for Draft Policy
          2011-5</title>

          <author>
            <organization>ARIN</organization>
          </author>

          <date day="18" month="Apr" year="2011" />
        </front>
      </reference>

      <reference anchor="ARIN-2011-5-Rec"
                 target="http://lists.arin.net/pipermail/arin-ppml/2011-May/022331.html">
        <front>
          <title>Message to ARIN-PPML, announcing Advisory Council meeting
          results Recommending 2011-5 for Board Approval</title>

          <author>
            <organization>ARIN</organization>
          </author>

          <date day="24" month="May" year="2011" />
        </front>
      </reference>

      <reference anchor="ARIN-AC-28Jan2011"
                 target="https://www.arin.net/about_us/ac/ac2011_0128.html">
        <front>
          <title>Minutes: Meeting of the ARIN Advisory Committee - 28 Jan
          2011</title>

          <author>
            <organization>ARIN</organization>
          </author>

          <date month="Jan" year="2011" />
        </front>
      </reference>

      <reference anchor="ARIN-AC-13Apr2011"
                 target="https://www.arin.net/about_us/ac/ac2011_0413.html">
        <front>
          <title>Minutes: Meeting of the ARIN Advisory Committee - 13 Apr
          2011</title>

          <author>
            <organization>ARIN</organization>
          </author>

          <date month="Apr" year="2011" />
        </front>
      </reference>

      <reference anchor="ARIN-AC-19May2011"
                 target="https://www.arin.net/about_us/ac/ac2011_0519.html">
        <front>
          <title>Minutes: Meeting of the ARIN Advisory Committee - 19 May
          2011</title>

          <author>
            <organization>ARIN</organization>
          </author>

          <date month="May" year="2011" />
        </front>
      </reference>

      <reference anchor="ARIN-NRPM-8.3"
                 target="https://www.arin.net/policy/nrpm.html#eight3">
        <front>
          <title>ARIN Number Resource Policy Manual, section 8.3 - Transfers
          to Specified Recipients</title>

          <author>
            <organization>ARIN</organization>
          </author>

          <date day="1" month="Jul" year="2011" />
        </front>
      </reference>

      <reference anchor="IAB-response"
                 target="http://www.iab.org/2011/06/iab-responds-to-arin-request-for-guidance-regarding-draft-policy-arin-2011-5/">
        <front>
          <title>IAB responds to ARIN request for guidance regarding Draft
          Policy ARIN-2011-5</title>

          <author>
            <organization>IAB</organization>
          </author>

          <date day="27" month="Jun" year="2011" />
        </front>
      </reference>

      <reference anchor="NRO-IANA-exhaust"
                 target="http://www.nro.net/news/ipv4-free-pool-depleted">
        <front>
          <title>Free Pool of IPv4 Address Space Depleted</title>

          <author>
            <organization>NRO</organization>
          </author>

          <date day="3" month="Feb" year="2011" />
        </front>
      </reference>

      <reference anchor="v6ops-msg06187"
                 target="http://www.ietf.org/mail-archive/web/v6ops/current/msg06187.html">
        <front>
          <title>Re: [v6ops] IETF 79 Meeting minutes - Draft</title>

          <author fullname="Akira Kato">
            <organization>WIDE</organization>
          </author>

          <date day="16" month="Nov" year="2010" />
        </front>
      </reference>

      <reference anchor="GIH-When"
                 target="http://www.potaroo.net/ispcol/2010-10/when.html">
        <front>
          <title>When?</title>

          <author fullname="Geoff Huston" initials="G" surname="Huston">
            <organization></organization>
          </author>

          <date month="Sep" year="2010" />
        </front>
      </reference>

      <reference anchor="APNIC-final-slash8"
                 target="http://www.apnic.net/publications/news/2011/final-8">
        <front>
          <title>APNIC IPv4 Address Pool Reaches Final /8</title>

          <author>
            <organization>APNIC</organization>
          </author>

          <date day="15" month="Apr" year="2011" />
        </front>
      </reference>

      <reference anchor="I-D.hain-1918bis"
                 target="http://www.ietf.org/internet-drafts/draft-hain-1918bis-01.txt">
        <front>
          <title>Expanded Address Allocation for Private Internets</title>

          <author fullname="Tony Hain" initials="T" surname="Hain">
            <organization></organization>
          </author>

          <date month="January" year="2005" />
        </front>

        <seriesInfo name="Internet-Draft" value="draft-hain-1918bis-01" />

        <format target="http://www.ietf.org/internet-drafts/draft-hain-1918bis-01.txt"
                type="TXT" />
      </reference>

      <reference anchor="PPML-022778"
                 target="http://lists.arin.net/pipermail/arin-ppml/2011-July/022778.html">
        <front>
          <title>Message to ARIN-PPML, indicating the Board's disposition
          toward 2011-5</title>

          <author>
            <organization></organization>
          </author>

          <date day="7" month="July" year="2011" />
        </front>
      </reference>

      <reference anchor="CISCO"
                 target="http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cwhubs/starvwug/83428.htm#xtocid74886">
        <front>
          <title>TCP/IP Overview: Class E Addresses</title>

          <author fullname="Cisco" initials="" surname="">
            <organization>Cisco</organization>
          </author>

          <date month="" year="" />
        </front>
      </reference>
    </references>
  </back>
</rfc>
