The Address plus Port (A+P) Approach to the IPv4 Address Shortage
RFC 6346

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 10

Internet Engineering Task Force (IETF)                      R. Bush, Ed.
Request for Comments: 6346                     Internet Initiative Japan
Category: Experimental                                       August 2011
ISSN: 2070-1721

   The Address plus Port (A+P) Approach to the IPv4 Address Shortage

Abstract

   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.

   This document 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 endpoint identifiers, thus leaving a reduced range of
   ports available to applications.  This means assigning the same IPv4
   address to multiple clients (e.g., Customer Premises Equipment (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.

Bush                          Experimental                      [Page 1]
RFC 6346                A+P Addressing Extension             August 2011

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and
   evaluation.

   This document defines an Experimental Protocol for the Internet
   community.  This document is a product of the Internet Engineering
   Task Force (IETF).  It represents the consensus of the IETF
   community.  It has received public review and has been approved for
   publication by the Internet Engineering Steering Group (IESG).  Not
   all documents approved by the IESG are a candidate for any level of
   Internet Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6346.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Bush                          Experimental                      [Page 2]
RFC 6346                A+P Addressing Extension             August 2011

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Problems with Carrier Grade NATs . . . . . . . . . . . . .  4
     1.2.  Requirements Language  . . . . . . . . . . . . . . . . . .  5
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Design Constraints and Functions . . . . . . . . . . . . . . .  6
     3.1.  Design Constraints . . . . . . . . . . . . . . . . . . . .  6
     3.2.  A+P Functions  . . . . . . . . . . . . . . . . . . . . . .  7
     3.3.  Overview of the A+P Solution . . . . . . . . . . . . . . .  8
       3.3.1.  Signaling  . . . . . . . . . . . . . . . . . . . . . .  9
       3.3.2.  Address Realm  . . . . . . . . . . . . . . . . . . . . 11
       3.3.3.  Reasons for Allowing Multiple A+P Gateways . . . . . . 15
       3.3.4.  Overall A+P Architecture . . . . . . . . . . . . . . . 16
     3.4.  A+P Experiments  . . . . . . . . . . . . . . . . . . . . . 17
   4.  Stateless A+P Mapping Function . . . . . . . . . . . . . . . . 18
     4.1.  Stateless A+P Mapping (SMAP) Gateway Function
           Description  . . . . . . . . . . . . . . . . . . . . . . . 18
     4.2.  Implementation Mode  . . . . . . . . . . . . . . . . . . . 20
     4.3.  Towards IPv6-Only Networks . . . . . . . . . . . . . . . . 22
     4.4.  PRR: On Stateless and Binding Table Modes  . . . . . . . . 22
     4.5.  General Recommendations on SMAP  . . . . . . . . . . . . . 23
   5.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 24