Cite this RFC:TXT | XML | BibTeX
DOI: https://doi.org/10.17487/RFC6346
Discuss this RFC: Send questions or comments to the mailing listiesg@ietf.org
Other actions:Submit Errata | Find IPR Disclosures from the IETF | View History of RFC 6346
We are facing the exhaustion of the IANA IPv4 free IP address pool.Unfortunately, IPv6 is not yet deployed widely enough to fullyreplace IPv4, and it is unrealistic to expect that this is going tochange before the depletion of IPv4 addresses. Letting hostsseamlessly communicate in an IPv4 world without assigning a uniqueglobally routable IPv4 address to each of them is a challengingproblem.
This document proposes an IPv4 address sharing scheme, treating someof the port number bits as part of an extended IPv4 address (Addressplus Port, or A+P). Instead of assigning a single IPv4 address to asingle customer device, we propose to extend the address field byusing bits from the port number range in the TCP/UDP header asadditional endpoint identifiers, thus leaving a reduced range ofports available to applications. This means assigning the same IPv4address to multiple clients (e.g., Customer Premises Equipment (CPE),mobile phones), each with its assigned port range. In the face ofIPv4 address exhaustion, the need for addresses is stronger than theneed to be able to address thousands of applications on a singlehost. If address translation is needed, the end-user should be incontrol of the translation process -- not some smart boxes in thecore. This document defines an Experimental Protocol for the Internetcommunity.
For the definition ofStatus,seeRFC 2026.
For the definition ofStream, seeRFC 8729.