One document matched: draft-ymbk-aplusp-07.xml

<?xml version="1.0" encoding="UTF-8"?>
<!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="exp" docName="draft-ymbk-aplusp-07" ipr="noDerivativesTrust200902">
  <front>
    <title abbrev="A+P Addressing Extension">The A+P Approach to the IPv4 Address Shortage</title> 

    <author role="editor" fullname="Randy Bush" initials="R.B." surname="Bush">
      <organization>Internet Initiative Japan</organization>
      <address>
        <postal>
          <street>5147 Crystal Springs</street>
          <city>Bainbridge Island</city>
          <region>Washington</region>
          <code>98110</code>
          <country>US</country>
          </postal>
        <phone>+1 206 780 0431 x1</phone>
        <email>randy@psg.com</email>
        <!-- uri and facsimile elements may also be added -->
        </address>
      </author>

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

    <abstract>

      <t>We are facing the exhaustion of the IANA IPv4 free IP address
      pool. Unfortunately, IPv6 is not yet deployed widely enough to fully
      replace IPv4, and it is unrealistic to expect that this is going to
      change before the depletion of IPv4 addresses. Letting hosts seamlessly
      communicate in an IPv4-world without assigning a unique globally
      routable IPv4 address to each of them is a challenging problem. </t>

      <t>This draft proposes an IPv4 address sharing scheme, treating
      some of the port number bits as part of an extended IPv4 address
      (Address plus Port, or A+P). Instead of assigning a single IPv4
      address to a single customer device, we propose to extend the address field by
      using bits from the port number range in the TCP/UDP header as 
      additional end point identifiers, thus leaving a reduced range of ports
      available to applications. This means assigning the
      same IPv4 address to multiple clients (e.g., CPE, mobile phones),
      each with its assigned port-range. In the face of IPv4 address
      exhaustion, the need for addresses is stronger than the need to be
      able to address thousands of applications on a single host. If address
      translation is needed, the end-user should be in control of the
      translation process - not some smart boxes in the core. </t>

<!--
      <t>This document discusses overall constraints that apply to address
      sharing proposals.
      <xref target="I-D.levis-behave-ipv4-shortage-framework"/> gives an
      overview over the solution space and questions that need to be
      addressed, while <xref target="I-D.durand-softwire-dual-stack-lite"/>,
      <xref target="I-D.boucadair-port-range"/>,
      <xref target="I-D.boucadair-dhc-port-range"/>,
      <xref target="I-D.bajko-pripaddrassign"/>,
      suggest various ways of overcoming the problems of shared addresses.
      </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>
    <?rfc include="00-a+p-intro.xml" ?>    
    <?rfc include="01-a+p-terminology.xml" ?>    
    <?rfc include="01-a+p-solution.xml" ?>  
    
    <?rfc include="05-a+p-SMAP.xml" ?>

   <section title="Deployment Scenarios">
    <?rfc include="02-a+p-implementation.xml" ?>
    <?rfc include="02-a+p-dynamic-port-allocation.xml" ?>
    <?rfc include="03-a+p-forward-packets.xml" ?>
   </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>

      <t>Note to RFC Editor: this section may be removed on publication
      as an RFC.</t>
    </section>

    <?rfc include="04-a+p-security.xml" ?> 

    <section anchor="authors" title="Authors">

    <t>This document has 9 primary authors, which is not allowed in
    the header of Internet-Drafts.   This is the list of actual authors
    of this document.</t>

<figure align="left"><artwork align="left">
   Gabor Bajko
   Nokia
   Email: gabor(dot)bajko(at)nokia(dot)com

   Mohamed Boucadair
   France Telecom
   3, Av Francois Chateaux
   Rennes  35000
   France
   Email: mohamed.boucadair@orange-ftgroup.com
   
   Steven M. Bellovin
   Columbia University
   1214 Amsterdam Avenue
   MC 0401
   New York, NY  10027
   US
   Phone: +1 212 939 7149
   Email: bellovin@acm.org

   Randy Bush
   Internet Initiative Japan
   5147 Crystal Springs
   Bainbridge Island, Washington  98110
   US
   Phone: +1 206 780 0431 x1
   Email: randy@psg.com

   Luca Cittadini
   Universita' Roma Tre
   via della Vasca Navale, 79
   Rome,   00146
   Italy
   Phone: +39 06 5733 3215
   Email: luca.cittadini@gmail.com

   Alain Durand
   Juniper Networks
   1194 North Mathilda Avenue
   Sunnyvale, CA  94089-1206
   USA
   Email: adurand@juniper.net
   
   Olaf Maennel
   Loughborough University 
   Department of Computer Science - N.2.03
   Loughborough 
   United Kindom
   Phone: +44 115 714 0042
   Email: o@maennel.net
   
   Reinaldo Penno
   Juniper Networks
   1194 North Mathilda Avenue
   Sunnyvale, California  94089
   USA
   Email: rpenno@juniper.net

   Teemu Savolainen
   Nokia
   Hermiankatu 12 D
   TAMPERE, FI-33720
   Finland
   Email: teemu.savolainen@nokia.com

   Jan Zorz
   go6.si
   Frankovo naselje 165
   Skofja Loka,  4220
   Slovenia
   Phone: +38659042000
   Email: jan@go6.si

</artwork></figure>

    </section>

    <section anchor="Acknowledgments" title="Acknowledgments">
      <t>The authors wish to especially thank Remi Despres, and Pierre
      Levis for their help on the development of the A+P approach.
     
      We also thank David Ward for review, constructive criticism, and
      interminable questions, and Dave Thaler for useful criticism on
      "stackable" A+P gateways.  We would also like to thank the
      following persons for their feedback on earlier versions of this
      work: Rob Austein, Gert Doering, Dino Farinacci, Russ Housley, 
      and Ruediger Volk.</t>
    </section>

  </middle>

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

      <?rfc include="reference.I-D.ietf-softwire-dual-stack-lite"?>
      <?rfc include="reference.I-D.boucadair-dhcpv6-shared-address-option"?>
      <?rfc include="reference.I-D.boucadair-pppext-portrange-option"?>
      <?rfc include="reference.I-D.bajko-pripaddrassign"?>
      <?rfc include="reference.I-D.wing-softwire-port-control-protocol"?>
      <?rfc include="reference.I-D.ietf-behave-address-format"?>
      <?rfc include="reference.I-D.ietf-behave-v6v4-xlate-stateful"?>
      <?rfc include="nonRFCrefs.xml" ?>
      <?rfc include="reference.RFC.1918"?>
      <?rfc include="reference.RFC.3715"?>
      <?rfc include="reference.RFC.1191"?>
      <?rfc include="reference.RFC.1858"?>
      <!-- 
         <?rfc include="reference.RFC.0959"?>
         <?rfc include="reference.I-D.levis-behave-ipv4-shortage-framework"?>
         <?rfc include="reference.RFC.3022"?>
         <?rfc include="reference.RFC.3489"?>
	 <?rfc include="reference.RFC.2766"?>
         <?rfc include="reference.RFC.4966"?> 
      --> 
    </references>
  </back>
</rfc>