Document Action: 'The A+P Approach to the IPv4 Address Shortage' to Experimental RFC (draft-ymbk-aplusp-10.txt)

[The IESG <[e-mail]>]

The IESG has approved the following document:
- 'The A+P Approach to the IPv4 Address Shortage'
  (draft-ymbk-aplusp-10.txt) as an Experimental RFC

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Ron Bonica.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ymbk-aplusp/




Technical Summary

   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 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.

Working Group Summary

This document is not the product of a working group.

Document Quality

- Are there existing implementations of the protocol?

Yes, one (ISC AFTR A+P support), but without dynamic port allocations and
no stateless support. Other implementations to follow, one of obstacles is
current status (draft).

- Have a significant number of vendors indicated their plan to implement
the specification?

Iskratel, possibly Cisco and Juniper.

- Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues?

All last version thorough reviewers are now among authors:
Mohammed Boucadair (FT)
Reinaldo Penno (Juniper)

Personnel

Ron Bonica is document shepherd