Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2018-12-20
10 (System)
Received changes through RFC Editor sync (changed abstract to 'We are facing the exhaustion of the IANA IPv4 free IP address pool. Unfortunately, IPv6 is …
Received changes through RFC Editor sync (changed abstract to '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. This document defines an Experimental Protocol for the Internet community.')
2015-10-14
10 (System) Notify list changed from randy@psg.com, draft-ymbk-aplusp@ietf.org to (None)
2012-08-22
10 (System) post-migration administrative database adjustment to the No Record position for Ralph Droms
2012-08-22
10 (System) post-migration administrative database adjustment to the No Objection position for Dan Romascanu
2012-08-22
10 (System) post-migration administrative database adjustment to the No Objection position for Wesley Eddy
2012-08-22
10 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2011-08-26
10 Cindy Morgan State changed to RFC Published from RFC Ed Queue.
2011-08-26
10 (System) RFC published
2011-06-14
10 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent.
2011-06-14
10 (System) IANA Action state changed to No IC from In Progress
2011-06-14
10 (System) IANA Action state changed to In Progress
2011-06-14
10 Amy Vezza IESG state changed to Approved-announcement sent
2011-06-14
10 Amy Vezza IESG has approved the document
2011-06-14
10 Amy Vezza Closed "Approve" ballot
2011-06-14
10 Amy Vezza Approval announcement text regenerated
2011-06-14
10 Amy Vezza Ballot writeup text changed
2011-06-14
10 Ron Bonica State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup.
2011-06-13
10 Wesley Eddy [Ballot Position Update] Position for Wesley Eddy has been changed to No Objection from Discuss
2011-06-13
10 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss
2011-05-31
10 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-05-31
10 (System) New version available: draft-ymbk-aplusp-10.txt
2011-03-31
10 Wesley Eddy
[Ballot discuss]
carrying over from Lars Eggert's DISCUSS:


[Ballot discuss]
  DISCUSS: The last item of Pasi Sarolahti's tsv-dir review requires a
  response.


INTRODUCTION, …
[Ballot discuss]
carrying over from Lars Eggert's DISCUSS:


[Ballot discuss]
  DISCUSS: The last item of Pasi Sarolahti's tsv-dir review requires a
  response.


INTRODUCTION, paragraph 1:
> Intended status: Experimental

  DISCUSS: The body of the document ...
  DISCUSS: The last item of Pasi Sarolahti's tsv-dir review requires a
  response.


INTRODUCTION, paragraph 1:
> Intended status: Experimental

  DISCUSS: The body of the document does not discuss at all in which way
  this technology is to be considered experimental, and in which kinds
  of deployments this technology may be experimented with. In fact,
  Section 5 is worded in way that suggests a readiness for global
  deployment. While I understand that this is the opinion of the
  authors, that is not what Experimental RFCs are for. We had several
  BOFs on this topic that all failed to convince the community of the
  value of this approach; I'm surprised to see the same content back
  with an Experimental label for publication on the IETF Stream.


INTRODUCTION, paragraph 10:
>    This Internet-Draft is submitted in full conformance with the
>    provisions of BCP 78 and BCP 79.  This document may not be modified,
>    and derivative works of it may not be created, and it may not be
>    published except as an Internet-Draft.

  DISCUSS: The document has an IETF Trust Provisions (28 Dec 2009)
  Section 6.c(ii) Publication Limitation clause.  If this document is
  intended for submission to the IESG for publication, this constitutes
  an error.


Section 5.3.4., paragraph 0:
> 5.3.4.  Limitations of the A+P approach

  DISCUSS: Just having reviewed
  draft-ietf-intarea-shared-addressing-issues, this section doesn't even
  begin to scratch the surface when it comes to limitations. I don't
  want you to duplicate all the content from
  draft-ietf-intarea-shared-addressing-issues here, but a reference to
  this document plus an upfront summary of the limitations described
  therein need to be added here.
2011-03-31
10 Wesley Eddy [Ballot Position Update] New position, Discuss, has been recorded
2011-02-17
10 Cindy Morgan Removed from agenda for telechat
2011-02-17
10 Cindy Morgan State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation.
2011-02-17
10 Ralph Droms [Ballot Position Update] Position for Ralph Droms has been changed to No Record from Discuss
2011-02-17
10 Dan Romascanu
[Ballot discuss]
Issue #5 on the list of issues raised by Tina Tsou in her review https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=55308&tid=1297852737 needs some clarifying edits as agreed in the …
[Ballot discuss]
Issue #5 on the list of issues raised by Tina Tsou in her review https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=55308&tid=1297852737 needs some clarifying edits as agreed in the mail discussion with Ron.
2011-02-17
10 Jari Arkko
[Ballot comment]
I am fine with this document going forward as an experimental RFC, but I would still like the document to be clearer about …
[Ballot comment]
I am fine with this document going forward as an experimental RFC, but I would still like the document to be clearer about its role. Its good that it already lists some of its limitations, but I don't think we have IETF-wide agreement on some of the things that the document discusses. These include, for instance, applicability to particular types of networks.
2011-02-17
10 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded
2011-02-17
10 Tim Polk
[Ballot comment]
The author's response to cross-area review was unprofessional and not in the spirit of achieving community
consensus.  I support Dan's discuss requiring a …
[Ballot comment]
The author's response to cross-area review was unprofessional and not in the spirit of achieving community
consensus.  I support Dan's discuss requiring a reasonable response...
2011-02-17
10 Tim Polk
[Ballot discuss]
I support publication of this document as an Experimental RFC, but I have concerns that the document content
does not accurately reflect community …
[Ballot discuss]
I support publication of this document as an Experimental RFC, but I have concerns that the document content
does not accurately reflect community consensus.  Since this is being published on the IETF stream, I believe some
additional text explaining why this is not on the standards track are in order.  To me, the text in combination with
publication on the IETF stream gives the impression that this document has significantly more support within the
community than it has in reality/
2011-02-17
10 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded
2011-02-17
10 Alexey Melnikov [Ballot comment]
Similarly to Peter, I found behavior of the editor of this document in response to some comments to be unprofessional.
2011-02-17
10 Alexey Melnikov [Ballot Position Update] New position, Abstain, has been recorded
2011-02-17
10 Ralph Droms
[Ballot discuss]
Discuss-discuss, which I will clear after the telechat:

* a+p supports and encourages the extended use of IPv4 while providing
  no incentive …
[Ballot discuss]
Discuss-discuss, which I will clear after the telechat:

* a+p supports and encourages the extended use of IPv4 while providing
  no incentive or support for the transition away from IPv4 to IPv6
* any effort spent on correcting technical issues with a+p would be
  better spent on resolving issues impeding the transition to IPv6
2011-02-16
10 Russ Housley
[Ballot discuss]
This document says:

    This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79 …
[Ballot discuss]
This document says:

    This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79.  This document may not be modified,
    and derivative works of it may not be created, and it may not be
    published except as an Internet-Draft.

  I find nothing in the write-up to indicate why this is acceptable.
  In general, IETF stream documents provide change control to the IETF.
  This document is not providing that change control.  There may be a
  reason for the exception, but I cannot find it.
2011-02-16
10 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss
2011-02-16
09 (System) New version available: draft-ymbk-aplusp-09.txt
2011-02-16
10 Russ Housley
[Ballot discuss]
This document says:

    This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79 …
[Ballot discuss]
This document says:

    This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79.  This document may not be modified,
    and derivative works of it may not be created, and it may not be
    published except as an Internet-Draft.

  I find nothing in the write-up to indicate why this is acceptable.
  In general, IETF stream documents provide change control to the IETF.
  This document is not providing that change control.  There may be a
  reason for the exception, but I cannot find it.
2011-02-16
10 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to Discuss from Yes
2011-02-16
10 Ralph Droms
[Ballot discuss]
This document should not be published as it does not address the
fundamental issues that were raised during the shara BoF at IETF …
[Ballot discuss]
This document should not be published as it does not address the
fundamental issues that were raised during the shara BoF at IETF 76:

* a+p supports and encourages the extended use of IPv4 while providing
  no incentive or support for the transition away from IPv4 to IPv6
* there are several technical issues that would impede successful
  deployment of a+p
* any effort spent on correcting technical issues with a+p would be
  better spent on resolving issues impeding the transition to IPv6
2011-02-16
10 Ralph Droms [Ballot Position Update] New position, Discuss, has been recorded
2011-02-16
10 Dan Romascanu
[Ballot discuss]
The issues raised by Tina Tsou in her review https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=55308&tid=1297852737 were not addressed at the technical level. I would like to see a …
[Ballot discuss]
The issues raised by Tina Tsou in her review https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=55308&tid=1297852737 were not addressed at the technical level. I would like to see a response on these issues before approving the document. If these were already answered please point me to the answer.
2011-02-16
10 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded
2011-02-15
10 Peter Saint-Andre [Ballot Position Update] New position, Abstain, has been recorded
2011-02-15
10 Robert Sparks
[Ballot comment]
Support Lars' discuss on providing details on evaluating the experiment

Please consider adding the text proposed by Richard Barnes at


This example is …
[Ballot comment]
Support Lars' discuss on providing details on evaluating the experiment

Please consider adding the text proposed by Richard Barnes at


This example is somewhat misleading:
  "(e.g., VoIP clients register a
  public IP and a single delegated port from the CPE, and accept
  incoming calls on that port)".
Most VoIP clients will ask for a separate port for the voice media from the one used for signaling.
2011-02-15
10 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2011-02-15
10 Lars Eggert
[Ballot discuss]
DISCUSS: The last item of Pasi Sarolahti's tsv-dir review requires a
  response.


INTRODUCTION, paragraph 1:
> Intended status: Experimental

  DISCUSS: The …
[Ballot discuss]
DISCUSS: The last item of Pasi Sarolahti's tsv-dir review requires a
  response.


INTRODUCTION, paragraph 1:
> Intended status: Experimental

  DISCUSS: The body of the document does not discuss at all in which way
  this technology is to be considered experimental, and in which kinds
  of deployments this technology may be experimented with. In fact,
  Section 5 is worded in way that suggests a readiness for global
  deployment. While I understand that this is the opinion of the
  authors, that is not what Experimental RFCs are for. We had several
  BOFs on this topic that all failed to convince the community of the
  value of this approach; I'm surprised to see the same content back
  with an Experimental label for publication on the IETF Stream.


INTRODUCTION, paragraph 10:
>    This Internet-Draft is submitted in full conformance with the
>    provisions of BCP 78 and BCP 79.  This document may not be modified,
>    and derivative works of it may not be created, and it may not be
>    published except as an Internet-Draft.

  DISCUSS: The document has an IETF Trust Provisions (28 Dec 2009)
  Section 6.c(ii) Publication Limitation clause.  If this document is
  intended for submission to the IESG for publication, this constitutes
  an error.


Section 5.3.4., paragraph 0:
> 5.3.4.  Limitations of the A+P approach

  DISCUSS: Just having reviewed
  draft-ietf-intarea-shared-addressing-issues, this section doesn't even
  begin to scratch the surface when it comes to limitations. I don't
  want you to duplicate all the content from
  draft-ietf-intarea-shared-addressing-issues here, but a reference to
  this document plus an upfront summary of the limitations described
  therein need to be added here.
2011-02-15
10 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded
2011-02-15
10 Adrian Farrel
[Ballot comment]
I know the RFC Editor can fix this, but in the spirit of devolving work...
You need to not describe the document as …
[Ballot comment]
I know the RFC Editor can fix this, but in the spirit of devolving work...
You need to not describe the document as a "draft"

---

It is not a requirement, but I think it is helpful if Experimental RFCs give some scope to the experiment both in terms of how it is "contained" and how the success of the experiment will be judged. This need not be a lot of text.
2011-02-15
10 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded
2011-02-15
10 Adrian Farrel
[Ballot comment]
I know the RFC Editor can fix this, but in the spirit of devolving work...
You need to not describe the document as …
[Ballot comment]
I know the RFC Editor can fix this, but in the spirit of devolving work...
You need to not describe the document as a "draft"
2011-02-08
10 Russ Housley [Ballot Position Update] New position, Yes, has been recorded
2011-02-07
10 Pasi Sarolahti Request for Last Call review by TSVDIR Completed. Reviewer: Pasi Sarolahti.
2011-02-07
10 Ron Bonica State changed to IESG Evaluation from Waiting for AD Go-Ahead.
2011-02-07
10 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-01-25
10 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Scott Kelly.
2011-01-25
10 Amanda Baber We understand that this document does not require any IANA actions.
2011-01-19
10 David Harrington Request for Last Call review by TSVDIR is assigned to Pasi Sarolahti
2011-01-19
10 David Harrington Request for Last Call review by TSVDIR is assigned to Pasi Sarolahti
2011-01-19
10 David Harrington Assignment of request for Last Call review by TSVDIR to Colin Perkins was rejected
2011-01-14
10 David Harrington Request for Last Call review by TSVDIR is assigned to Colin Perkins
2011-01-14
10 David Harrington Request for Last Call review by TSVDIR is assigned to Colin Perkins
2011-01-12
10 Ron Bonica Placed on agenda for telechat - 2011-02-17
2011-01-12
10 Ron Bonica [Ballot Position Update] New position, Yes, has been recorded for Ronald Bonica
2011-01-12
10 Ron Bonica Ballot has been issued
2011-01-12
10 Ron Bonica Created "Approve" ballot
2011-01-10
10 Samuel Weiler Request for Last Call review by SECDIR is assigned to Scott Kelly
2011-01-10
10 Samuel Weiler Request for Last Call review by SECDIR is assigned to Scott Kelly
2011-01-10
10 Amy Vezza Last call sent
2011-01-10
10 Amy Vezza
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (The A+P Approach to the IPv4 Address Shortage) to Experimental RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'The A+P Approach to the IPv4 Address Shortage'
  as an Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-02-07. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ymbk-aplusp/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ymbk-aplusp/
2011-01-08
10 Ron Bonica Last Call was requested
2011-01-08
10 Ron Bonica State changed to Last Call Requested from Publication Requested.
2011-01-08
10 (System) Ballot writeup text was added
2011-01-08
10 (System) Last call text was added
2011-01-08
10 (System) Ballot approval text was added
2011-01-08
10 Ron Bonica Intended Status has been changed to Experimental from Proposed Standard
2011-01-05
08 (System) New version available: draft-ymbk-aplusp-08.txt
2011-01-05
07 (System) New version available: draft-ymbk-aplusp-07.txt
2010-12-10
10 Ron Bonica Intended Status has been changed to Proposed Standard from None
2010-12-10
10 Ron Bonica Draft Added by Ron Bonica in state Publication Requested
2010-10-18
06 (System) New version available: draft-ymbk-aplusp-06.txt
2010-04-29
10 (System) Document has expired
2009-10-26
05 (System) New version available: draft-ymbk-aplusp-05.txt
2009-07-13
04 (System) New version available: draft-ymbk-aplusp-04.txt
2009-03-09
03 (System) New version available: draft-ymbk-aplusp-03.txt
2009-01-30
02 (System) New version available: draft-ymbk-aplusp-02.txt
2008-11-03
01 (System) New version available: draft-ymbk-aplusp-01.txt
2008-10-27
00 (System) New version available: draft-ymbk-aplusp-00.txt