Internet DRAFT - draft-franco-ipv4depletion
draft-franco-ipv4depletion
Network Working Group J. Franco Arboine
Internet-Draft: DRAFT-FRANCO-IPV4DEPLETION-00.{txt} Saudi Aramco
Intended status: Informational
Expiration: January 28, 2012 July 27, 2011
IP v4 Addressing Depletion Solution
draft-franco-ipv4depletion-00
Abstract
This document addresses the problem of IP v4 address space depletion.
This document proposes an easy, technical solution based on the use
of two options in the IP packet. The IP Version is used to extend
the current IP v4 address universe to 25 to 30 billion IP addresses.
A modified IP packet header Option 3, the Loose Source and Record
Router (LSRR), is used to carry source ip version, source ip prefix,
destination ip version, and destination ip prefix in the IP network
packet. This document introduces the concepts of RIR nebulae (or IP
address nebula) and mirror prefixes (or pseudo prefixes). RIR nebulae
are concurrent IP v4 address spaces which are differentiated from one
another by the IP Version in the IP network packet header. The mirror
prefixes (/33 to /255) emulate or mirror standard prefixes (/0 to /31).
The single host route (/32 or 255.255.255.255) is supported in all RIR
nebulae. The new extended IP v4 universe (a new, hypothetical Internet)
is comprised of multiple IP v4 address spaces and DNS domains of 4.2
billion addresses.
Status of this Memo
This memo provides information for the entire Internet community.
It does not specify an Internet standard of any kind. Distribution
of this memo is unlimited and global.
This document may not be modified, and derivative works of it
may not be created, except to format it for publication as an
RFC or to translate it into languages other than English.
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 28, 2012.
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.
This Internet-Draft is submitted in full conformance with the
Provisions of BCP 78 and BCP 79.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IP Address Depletion Quandary . . . . . . . . . . . . . . . . . 4
3. Proposal to Extend the Life of IP v4 . . . . . . . . . . . . . 5
3.1 Concurrent IP Address Nebulae . . . . . . . . . . . . . . . . . 5
3.2 Using the IP Version to Tag IP Network Packets . . . . . . . . 6
3.3 Mirroring Prefixes /0-/31 to Route RIR Nebula Packets . . . . . 8
3.3.1 INTERNET IPv4 (IP version 4) (prefixes /0-/32) . . . . . . . 10
3.3.2 APNIC (IP version 10) (prefixes /160-/191, /32) . . . . . . 10
3.3.3 ARIN (IP version 11) (prefixes /64-/95, /32) . . . . . . . . 10
3.3.4 LACNIC (IP version 12) (prefixes /192-/223, /32) . . . . . . 10
3.3.5 RIPENCC (IP version 13) (prefixes /128-/159, /32) . . . . . 10
3.3.6 AFRINIC (IP version 14) (prefixes /224-/255, /32) . . . . . 10
3.3.7 IPv4IPv6 (IP version 15) (prefixes /96-/127, /32) . . . . . 10
3.4 Single Host Mask (prefix /32) (255.255.255.255) . . . . . . . 11
4 Transition to Concurrent IP v4 Address Nebulae . . . . . . . . . 12
4.1 Thirty Two (32) Bits to 25-30 Billion IP Addresses . . . . . . 12
4.2 Reorganizing the IP v4 Address Allocations . . . . . . . . . . 13
4.3 Reduction of Private Networks . . . . . . . . . . . . . . . . 13
4.4 Routing in the Concurrent IPv4 Address Nebulae . . . . . . . . 14
4.5 DNS Name Resolution and Reverse DNS Lookup . . . . . . . . . . 15
4.6 Configuring Network Devices with RIR IP Settings . . . . . . . 16
4.7 IP Multicasting on the Concurrent RIR Nebulae . . . . . . . . 16
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Dedication . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Contact . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1 Introduction
The sole goal of this document is to propose a feasible, more cost
effective, and much less labor intensive alternative solution to the
Internet Protocol (IP) version 4 address space depletion (exhaustion)
problem, to extend the useable lifetime of the Internet Protocol (IP)
version 4, and to save time, financial and human resources as well as
reduce the sizes of routing tables on the Net.
This document is written in a simple and straight forward style to
harvest maximum support from the public at large, the non-profit
sector, private industry, governments, and Internet organizations.
This author is not sponsored by any hardware or software manufacturer,
any Internet organization, any corporation, or any governmental
institution.
Most of the IP addresses and IP networks used in the examples in this
document are from the IP private address space; even though, private
network IP addresses are not allowed on the Internet.
The current solution to the IP address exhaustion problem, promoted
in the IT industry, is to migrate to the new Internet Protocol (IP)
version 6. However, the current rate of migration to IP v6 is
extremely low. We must think of an alternative plan if IP v6 fails to
catch on with Internet users. This document presents a simple, yet
intelligent solution to the current IP address depletion problem and
recommends a transition strategy to an extended Internet using
concurrent IP v4 address spaces. IP v6 is in use and is here to stay;
nonetheless, IP v6 is not the de facto standard.
The Internet Assigned Numbers Authority (IANA) assigned the last pool
of available IP v4 addresses to the Regional Internet Registries (RIRs)
last February, 2011. This means that there are no more large IP v4
address pools to be assigned by the IANA. The Internet has come to
the most important juncture in its history.
However, despite the depletion of IP v4 addresses, the Internet will
continue to work normally. The main problem is that without new IP v4
address pools the Internet will not grow, resulting in economic and
technical dilemmas for end-user organizations conducting serious
business on the Internet. The deployment of IP v6 is the only solution
which has been considered for the continued growth and evolution of the
Internet. Internet pundits have failed to consider the fact that not every
organization around the world has the financial resources or technical
knowledge needed to migrate their networks to IP v6 in the very near future.
And we cannot have two distinct Internets. The Internet has served humanity
extremely well and must be kept united as one in the best interest of
humanity.
As we shall see, where there is a will, there is always a way.
2 IP v4 Address Depletion Quandary
Ask not what the Internet can do for you?, Ask what you can do for
the Internet? to paraphrase the greatest and the most eloquent of
statesmen from the world over. The Internet, over the last three
decades, has revolutionized human communications and has advanced
human development all over the Earth. Today, conversely, Internet
is at a crucial point in time. The Internet is running out of IP v4
addresses.
The biggest and most compelling technical problem on the Internet
today is the upcoming depletion of the Internet Protocol (IP)
version 4 addresses. The IP version 4 is the current version of the
Internet Protocol installed on most computers and network devices
today. An IP address is a 32-bit number, administered by the
Internet Assigned Numbers Authority (IANA). An IP address can be
represented in binary, decimal, hexadecimal, octal, and dotted decimal
formats. An IP address is normally denoted in dotted decimal format
(e.g. 10.20.90.25). An IP address allows a network device (a computer,
a router, a switch, a printer, a web server, a mobile phone, an
embedded system, etc) to communicate on the Internet or on a private
IP network. Without an IP address a network device would not be able
communicate with other network devices on the Internet or on a private
IP network. Every device directly connected to an IP network requires
a unique IP address. The problem is that with the advent of mobile and
wireless communications, with the development of new applications, and
accumulation of massive amounts of data, the requests for new IP
addresses has grown drastically in recent years. The main problem
is that 32-bit address space is very limited and can only accommodate
256 Class A networks (each of 16,777,216 ip addresses) or just over
4.2 billion IP addresses (4,294,967,296 to be exact). To make matters
worse, a good percentage of these IP addresses are also reserved or
has been pre-allocated for special services. Even when those IP
addresses which have been reserved by the IANA are taken into account,
the reserved IP v4 address pools of the IANA and the five Regional
Internet Registries (RIRs) are definitely going to be exhausted in
the very near future. IP v6 is seen as the only way out.
The Internet Corporation for Assigned Names and Numbers (ICANN) and
its contracting agency the Internet Assigned Numbers Authority (IANA)
manage and administer domain names, IP addresses, and other Internet
resources. All IP addresses and other Internet resources originate with
the Internet Assigned Numbers Authority (IANA) which is the organization
responsible for reserving, controlling, and allocating IP addresses to
the five existing Regional Internet Registries (RIR). Besides IP
addresses, the IANA is also responsible for assigning domain names,
managing the root DNS zones of the Internet, assigning protocol numbers,
and assigning autonomous system (AS) numbers. Each Regional Internet
Registry (RIR) in turn is solely responsible for the request fulfillment
of IP addresses and other Internet resources to Local Internet Registries
(LIRs) such as Internet Service Providers (ISPs), educational institutions,
and other end-user organizations in their respective geographical regions
of the world. There are five authorized Regional Internet Registries (RIR)
around the world:
African Network Information Centre (AFRINIC) for Africa
American Registry for Internet Numbers (ARIN) for the United States,
Canada, several parts of the Caribbean region,and Antarctica
Asia-Pacific Network Information Centre (APNIC) for Asia, Australia,
New Zealand, and adjoining countries
Latin America and Caribbean Network Information Centre (LACNIC)
for Latin America and parts of the Caribbean region
Reseaux IP Europeens Network Coordination Centre (RIPENCC) for
Europe, the Middle East, and Central Asia
The Number Resource Organization (NRO) is the organization which
administers and coordinates the collective activities of the five
Regional Internet Registries (RIRs). Besides these organizations,
there are other bodies that play a fundamental role in the
technological development of the Internet. The Internet Engineering
Task Force (IETF) develops Internet engineering standards. The
Internet Architecture Board (IAB) is a committee of the Internet
Engineering Task Force (IETF). The Internet Society (ISOC) is the
home of the IETF and the IAB. The World Wide Web Consortium
(W3C.org) develops Internet WWW standards.
3 Proposal to Extend the Life of IP v4
This proposal to extend the life of the Internet Protocol (IP) v4
is simple yet revolutionary. It does not propose sharing of IP
addresses but the deployment of concurrent IP v4 address spaces
through the use of the IP Version to tag IP network packets from
their origin and using of mirroring IP prefixes to IP network
packets from new the IP address spaces.
3.1 Concurrent IP v4 Address Nebulae
The existing 32-bit IP v4 address space and its urgently mounting
depletion problem are well understood by anyone in the Internet
community who understands the fundamentals of IP addressing and
its importance to networking. Necessity, as it has been said many
times before, is the mother of invention. This constraining problem
can be solved with the deployment of concurrent IP v4 address spaces
or RIR nebulae to be supported by upgraded IP routers and upgraded IP
switches as well as by modified domain name resolution (DNS) servers
and other ancillary basic IP services to support the technical
requirements of an Internet nebulae network environment.
The terms RIR nebulae and RIR nebula are used here to differentiate
new IP address spaces (to be created) to work concurrently with the
active IP v4 32-bit address space (the Internet IP v4). RIR nebulae is
defined as a set of concurrent, interconnected IP v4 32-bit address
spaces that are similar in configuration but are not mirrors of each
other.
The idea is to route or switch multiple, duplicate IP addresses derived
from separate IP address spaces using the standard prefixes (/0-/32) and
mirror prefixes (/33 to /255) on the extended Internet. Every network
or host IP address is accompanied by a subnet mask or IP prefix. In a
normal IP network packet, the source address (32-bits) and destination
address (32- bits) do not carry with them their associated IP prefix or
subnet mask information.
How can we route, switch, or forward IP packets from IP network
10.68.3.0/24 of the ARIN nebula, from IP network 10.68.3.0/24 of the
APNIC nebula, from IP network 10.68.3.0/24 of the AFRINIC nebula, from
IP network 10.68.3.0/24 of the RIPENCC nebula, from IP network
10.68.3.0/24 of the LACNIC nebula, and from IP network 10.68.3.0/24
of the Internet IP v4 if all these networks use the same IP network
address and the same IP subnet mask?
This technical challenge is easily solved by making an intelligent use
of two fields in the IP packet. First, the IP Version field in the IP
packet header of each network packet can be used to tag or identify
the origin of IP packets. This way we can control and verify the IP
address space (nebula) origin of an IP network packet. That is, all
IP Version 4 packets must originate only from the existing IP v4
address space. All IP Version 10 packets must originate only from
the APNIC address space or APNIC nebula. Second, in this nebula
environment, we can route IP packets from their source and to their
destination through the implementation of mirror prefixes in each
RIR nebula to correspond to prefixes (/0-/31). These parameters
can be forwarded in the Options field of an IP network packet.
Internet routers and switches, once modified, would then be able to
correctly identify and route the Internet IP packets originating from
each RIR geographical zone or RIR nebula onto the current Internet
(the IP v4 address space) during the transitional period. Eventually,
the upgraded Internet routers and switches will be able to route any IP
packet from any IP address space (nebula) to any other IP address space
(nebula).
Internet Datagram Header (from RFC791)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This technical solution to the IP v4 Address Exhaustion problem, in
my opinion, will be substantially more cost effective, less difficult,
less technically challenging, and less time consuming than carrying
out full network migrations from IP v4 to IP v6 and than having to
resolve the hardware and software compatibility issues in corporate
production environments. Nevertheless, this proposed technical solution
requires extensive testing as well as carefully implemented extensions
of IP network packets and to the IP routing protocols on routers,
switches, firewalls, protocol analyzers, fundamental networking
applications such as DNS servers, application servers, web browsers,
and a myriad number of host utilities, and other network devices on
the Internet.
This easy technical solution must first be tested in lab network
environment. It cannot be implemented independently or directly on the
Internet without authorization by the IETF and Internet organizations.
This solution can only be submitted for the independent evaluation and
testing of the IETF to develop Internet drafts to hopefully become new
Internet standard RFCs. The endorsement of this technical solution by
other technical organizations, software and hardware vendors, and
end-user organizations is also crucial for its deployment and
implementation worldwide. The Internet Service Providers (ISPs) and
telecommunications giants, not the Regional Internet Registries (RIRs),
are the main purveyors of Internet access to Internet customers.
3.2 Using the IP Version to Tag IP Network Packets
Every Internet Protocol (IP) network packet carries an IP Version field
(4 bits) in the IP packet header. The IP header is on average 20 bytes
in length. The current IP version is version 4 (four). IP v4 supports
an IP address space of 32 bits; that is, 2^32 IP addresses or just
over 4.2 billion IP addresses.
Since IP Version field in this solution will be used to tag the origin
of an IP network packet, the IP Version field, perhaps, can be renamed
Originator or Nebula field.
All current IP v4 packets have the IP Version field set to 0100
(number 4), the current IP version, as shown below.
Decimal 8 4 2 1
Bits bit 3 Bit 2 bit 1 bit 0
IP 0 1 0 0
Version
IP versions 0, 1, 2, 3, 10, 11, 12, 13, 14, and 15 are not currently
assigned. The bulk of IP network packets on the Internet are version 4
and version 6.
IP Version IP Version Assignments
0 Reserved
1 Reserved
2 Reserved
3 Reserved
4 IPv4 Internet Protocol
(current IP v4 address space)
5 (ST) Internet Streaming Protocol v2,
(SCMP) Stream Control Message Protocol
6 IPv6 Internet Protocol,
(SIP) Simple Internet Protocol,
(SIPP) Simple Internet Protocol Plus
7 (TP/IX) Next Internet Protocol
8 (PIP) Private Internet Protocol
9 (TUBA) TCP and UDP with Bigger Addresses
10 APNIC Nebula (new IPv4 address space)
11 ARIN Nebula (new IPv4 address space)
12 LACNIC Nebula (new IPv4 address space)
13 RIPENCC Nebula (new IPv4 address space)
14 AFRINIC Nebula (new IPv4 address space)
15 Reserved
Through the intelligent use of the IP Version field (4 bits), we can
assign a group of the possible 2^4=16 versions (0-15) to identify the
network ip packets coming from the five RIR geographical zones (or the
RIR nebulae to be deployed). IP Version 4 and IP Version 6 are already
in use on the Internet. We can set aside IP Versions 10, 11, 12, 13,
and 14 for the implementation of RIR nebulae.
8 4 2 1 Ver Base IP Version Prefixes
0 0 0 0 0 0 Reserved
0 0 0 1 1 Reserved
0 0 1 0 2 32 Reserved 33 63
0 0 1 1 3 Reserved
0 1 0 0 4 64 IP v4 Internet 0 32
0 1 0 1 5 ST2 Protocol
0 1 1 0 6 96 IP v6 Internet
0 1 1 1 7 TP/IX
1 0 0 0 8 PIP, MPLS
1 0 0 1 9 TUBA
1 0 1 0 10 160 APNIC 160 191
1 0 1 1 11 64 ARIN 64 95
1 1 0 0 12 192 LACNIC 192 223
1 1 0 1 13 128 RIPENIC 128 159
1 1 1 0 14 224 AFRINIC 224 255
1 1 1 1 15 Reserved 96 127
128 64 32 16 Ver Base IP Version Prefixes
The IP Version field in each IP v4 packet is a 4-bit field which we
can be interpreted in two ways (big endian). If IP Version field is
seen as the least significant nibble of a byte, then decimal values
for the 4 bits are 8, 4, 2, and 1. If IP Version field is seen as the
most significant nibble of a byte, then the decimal values for the 4
bits are 128, 64, 32, and 16.
IP Versions 5, 7, 8, and 9 are or were reserved for experimental IP
protocols. IP Version 5 has been assigned to the Streaming Protocol v2.
IP Version 7 has been assigned to TP/IX, the Next Internet Protocol.
IP Version 8 has been assigned to PIP, the Protective Internet Protocol.
IP Version 9 has been assigned to TUBA, TCP and UDP with Big Addresses.
The only actual network prefixes supported on IP networks are /0 to /32,
the other are mirror or pseudo prefixes mirroring prefixes /0 to /31.
The mirror prefixes /33 to /255 are used only for routing IP network
packets to and from each RIR nebula and the current Internet (IP v4),
not for the purpose of actually subnetting IP networks. If we able to
route IP packets on the Internet from each RIR geographical zone using
this new strategy, we would then be able to easily extend the IP address
universe to 25.7 billion IP addresses (a 500% expansion) from the
current 4.2 billion IP addresses. In this scenario, each RIR
geographical zone would need to support routing IP versions (10, 11,
12, 13, and 14) in addition to IP Versions 4 and 6. Also, domain name
resolution, reversed name lookup, and IP multicasting would also need
to be supported through engineering modifications for basic IP services
to work in the Internet Nebulae environment.
IP Addresses Service IP Version
4,294,967,296 INTERNET 4
4,294,967,296 ARIN 11
4,294,967,296 RIPENCC 13
4,294,967,296 APNIC 10
4,294,967,296 LACNIC 12
4,294,967,296 AFRINIC 14
25,769,803,776 Total
3.3 Mirroring Prefixes /0-/31 to Route Nebula Packets
Since every node on the Internet is able to contact any other node on
the Internet, the IP routing protocols would need to be modified to
identify and route the network packets coming from or going to each
RIR nebula. Within each RIR geographical zone or RIR nebula, the
enterprise networks connected to the Internet would only need small
updates, not drastic modifications. However, the Internet Service
Providers (ISPs) would need to make major modifications to routers,
switches, and domain name servers. Yet these IP v4 modifications would
still be less expensive and less time consuming than conducting full
migrations from IP v4 to IP v6.
The IP routing protocols would need to recognize the source and
destination mirror prefixes (/33 to /255) in addition to the standard
prefixes (/0 to /32), associated with the network or IP address on the
Internet IP v4 address space and in each RIR nebula address space.
This solution would require a new set of standard RFCs from the IETF
since routing updates, routing tables, dns server records, and network
packets would require new extensions. Routing protocol packets already
contain 32 bits fields used for the subnet masks. Modifications to these
32 bit fields would be required in order to allow routing protocols and
dns server records to carry the standard prefix or mirror prefix
(8 bits) and the IP Version (8 bits) of source and destination addresses
for IP routing and name resolution to work correctly in the extended
Internet Nebulae environment.
IP Version 4 2 11 15 13 10 12 14
first prefix 0 33 64 96 128 160 192 224
last prefix 32 63 95 127 159 191 223 255
single host 32 32 32 32 32 32 32 32
IPV4INT ARIN RIPENCC LACNIC
RESERVED IPV4IPV6 APNIC AFRINIC
The table above shows the standard prefixes (/0-/32) used with IP
Version 4. All the other prefixes are mirror prefixes of the standard
prefixes (/0-/32). These mirror prefixes are to be used only for routing
packets to and from the RIR nebulas and not for actual IP subnetting.
For example, a network packet from the ARIN nebula on the Internet would
carry prefixes /64 to /95 (to differentiate these network packets as
ARIN nebula packets) but the actual prefixes are standard prefixes
/0-/31. Prefixes /64 to /95 are dummy or mirror prefixes.
In another example, a network packet from the APNIC nebula on the
Internet would carry prefixes /192 to /223 (to differentiate these
packets as APNIC packets on the Internet) but the actual prefixes are
also standard prefixes /0 to /31. We cannot use prefixes /0 to /32 on
the Internet for the ARIN, RIPENCC, APNIC, LACNIC, or AFRINIC nebulae
because prefixes /0 to /32 belong to the Internet IP v4 address space.
However, the standard prefixes /0 to /32 should be usable within each
ARIN, RIPENCC, APNIC, LACNIC, or AFRINIC nebula, allowing corporate and
home networks connected to them to remain almost unchanged. The Internet
routers in this new Internet design are the key components. The Internet
routers controlled by the Internet Services Providers and key Internet
organizations, will need to function as prefix translators and as prefix
verifiers for the routing of network packets among the RIR nebulae,
including the current Internet IP v4 address space.
The Routing Information Protocol (RIP) version 1 did not carry any
subnet mask information in the RIP routing table updates. This
problem was only corrected with the release of Routing Information
Protocol (RIP) version 2. To implement this pressing Internet technical
solution, we will need to make progressive modifications (add extensions)
to the IP protocols on routers, switches, and hosts connected to the
Internet.
Interior Routing Protocols:
Routing Information Protocol (RIP) v2
Interior Gateway Protocol (IGRP)
Enhanced Interior Gateway Protocol (EIGRP)
Open Shortest Path First (OSPF)
Intermediate System to Intermediate System (IS-IS)
Exterior Routing Protocols:
Border Gateway Protocol (BGP), fundamental to the Internet.
Exterior Gateway Protocol (EGP), now obsolete.
3.3.1 INTERNET IPv4 (IP version 4) (prefixes /0-/32)
All IP packets with IP Version field set to 0100 (4), by definition,
will be treated as originating from the current INTERNET IP v4 address
space. Because the IP Version is set to 4, the only valid prefixes in
these IP packets are from /0 to /32 (corresponding to standard IP
subnet masks 0.0.0.0 to 255.255.255.255).
3.3.2 APNIC (IP version 10) (prefixes /160-/191, /32)
All IP packets with IP Version field set to 1010 (10), by definition,
will be treated as originating from the APNIC RIR geographical zone or
the APNIC Nebula. Because the IP Version is set to 10, the only valid
prefixes in these IP packets are from /160 to /191 (mirroring prefixes
/0 to /31) and /32 (the single host subnet mask).
3.3.3 ARIN (IP version 11) (prefixes /64-/95, /32)
All IP packets with IP Version field set to 1011 (11), by definition,
will be treated as originating from the ARIN RIR geographical zone or
the ARIN Nebula. Because the IP Version is set to 11, the only valid
prefixes in these IP packets are from /64 to /95 (mirroring prefixes
/0 to /31) and /32 (the single host subnet mask).
3.3.4 LACNIC (IP version 12) (prefixes /192-/223, /32)
All IP packets with IP Version field set to 1100 (12), by definition,
will be treated as originating from the LACNIC RIR geographical zone
or the LACNIC Nebula. Because the IP Version is set to 12, the only
valid prefixes in these IP packets are /192 to /223 (mirroring
prefixes /0 to /31) and /32 (the single host subnet mask).
3.3.5 RIPENCC (IP version 13) (prefixes /128-/159, /32)
All IP packets with IP Version field set to 1101 (13), by definition,
will be treated as originating from the RIPENCC RIR geographical zone
or the RIPENCC Nebula. Because the IP Version is set to 13, the only
valid prefixes in these IP packets are /128 to /159 (mirroring prefixes
/0 to /31) and /32 (the single host subnet mask).
3.3.6 AFRINIC (IP version 14) (prefixes /224-/255, /32)
All IP packets with IP Version field set to 1110 (14), by definition,
will be treated as originating from the AFRINIC RIR geographical zone
or the AFRINIC Nebula. Because the IP Version is set to 14, the only
valid prefixes for the source hosts in these IP packets are /224 to
/255 (mirroring prefixes /0 to /31) and /32 (the single host subnet
mask). The prefix /255 must NOT to be confused with standard IP subnet
mask 255.0.0.0 (prefix /8).
3.3.7 IPv4IPv6 (IP version 15) (prefixes /96-/127, /32)
All IP packets with IP Version field set to 1111 (15), by definition,
are processed as originating from the IPv4IPv6 nebula. This nebula can
be used by end user organizations as the test bed for developing an IPv4
to IPv6 migration framework. Because the IP Version is set to 15, the
valid prefixes in these IP packets would be /96 to /127 (mirroring
prefixes /0 to /31) and /32 (the single host subnet mask). This IPv4IPv6
nebula can be used for testing software and hardware compatibility
between IPv4 and IPv6 by all Internet user organizations. IP v6 and
IP v4 can only coexist in the same host using dual IP stacks.
In retrospect, Ethernet networks and Token Ring networks were not able
to communicate with each other until the advent of translational
bridges.
The IP header of an IPv6 packet consists of 40 bytes (320 bits) and
is not compatible with the IP header of an IP v4 packet, which is 20
bytes (160 bits) in length on average.
IP Version 15 and mirror prefixes /96 to /127 can also be set aside
for the Department of Defense Network Information Center (DoDNIC) of
the US Government to deploy a sixth RIR nebula (IP Version 15) for
building more restricted, highly secure defense networks, to free up
major IP address blocks on the current Internet IP v4 address space,
and to expand the IP v4 address universe to 30,064,771,072 IP v4
addresses or 30 billion IP v4 addresses (a 600% augmentation).
3.4 Single Host Mask (prefix /32) (255.255.255.255)
The IP subnet mask 255.255.255.255 or prefix /32 is known as the single
host mask. This is the only subnet mask which is not mirrored by prefixes
(/33 to /255). The IP subnet mask 255.255.255.255 or prefix /32 used for
single host routes will be supported in each RIR nebula. The IP version
(and the prefix) will distinguish single host routes among RIR nebulae.
IP Versions, Standard Prefixes (/0-/32), and Mirror Prefixes (/33-/255)
4 2 11 15 13 10 12 14
IPV4INT ARIN RIPENCC LACNIC
RESERVED IPV4IPV6 APNIC AFRINIC
0 -- 64 96 128 160 192 224
1 33 65 97 129 161 193 225
2 34 66 98 130 162 194 226
3 35 67 99 131 163 195 227
4 36 68 100 132 164 196 228
5 37 69 101 133 165 197 229
6 38 70 102 134 166 198 230
7 39 71 103 135 167 199 231
8 40 72 104 136 168 200 232
9 41 73 105 137 169 201 233
10 42 74 106 138 170 202 234
11 43 75 107 139 171 203 235
12 44 76 108 140 172 204 236
13 45 77 109 141 173 205 237
14 46 78 110 142 174 206 238
15 47 79 111 143 175 207 239
16 48 80 112 144 176 208 240
17 49 81 113 145 177 209 241
18 50 82 114 146 178 210 242
19 51 83 115 147 179 211 243
20 52 84 116 148 180 212 244
21 53 85 117 149 181 213 245
22 54 86 118 150 182 214 246
23 55 87 119 151 183 215 247
24 56 88 120 152 184 216 248
25 57 89 121 153 185 217 249
26 58 90 122 154 186 218 250
27 59 91 123 155 187 219 251
28 60 92 124 156 188 220 252
29 61 93 125 157 189 221 253
30 62 94 126 158 190 222 254
31 63 95 127 159 191 223 255
32 32 32 32 32 32 32 32
4 Transition to Concurrent IPv4 Address Nebulae
The transition to the Concurrent IPv4 Address Nebulae can do easily by
using the current Internet IP v4 to interconnect each RIR nebula to be
implemented progressively from a smaller scale to a larger scale.
After the transition phase has been completed, each RIR nebula and the
existing Internet IP v4 address space (a new RIR nebula) must be able
to send and receive IP network packets to and from any other RIR nebula.
4.1 Thirty Two (32) Bits to 25-30 Billion IP Addresses
The main problem with the implementation of an extended Internet based
on IP address nebulae is that the IP header of an IP network packet
carries only source and destination IP addresses. For IP routing to
work correctly, hosts must be able to pass additional parameters to
the modified IP router or IP switch.
The source prefix or subnet mask (8 bits), the source IP version (8 bits),
the destination prefix (8 bits) or subnet mask and the destination IP
version (8 bits), are these key parameters. If the destination prefix
or subnet mask is not known, then this value must be set to null until
updated by the destination network router. In practice, only 4 bits
for the IP Version are needed but we will use 8 bits (an octet) to bring
the total number of bits to 32 bits or 4 octets. These four octets (four
8 bits or 32 bits) must be communicated in the IP network packet to the
modified IP router or IP switch in order for the IP router or IP switch
to forward the IP network packet to its correct destination and for the
destination to be able to reply correctly to the source on the new
Internet Nebulae network environment.
In an Internet nebulae environment, the source host needs to provide
its IP version (nebula), its prefix, the destination IP version (nebula),
and the destination prefix (if known) in the network packet in order for
the network packet to make it to its destination and for the destination
to be able to reply accurately to the source.
A total of 32 bits (4 octets) to be transmitted:
Source IP Version (8 bits) plus Source prefix (8 bits)
Destination IP Version (8 bits) plus Destination prefix (8 bits)
The most effective way to transmit these four new nebula parameters
is to make intelligent use of IP option 3 or the Loose Source and Record
Route option, in the IP header of an IP network packet. It will not be
difficult to integrate to these four parameters into existing IP service
infrastructure; even though, new standard RFCs will be required.
Incorporating these four parameters into the IP v4 service family of
protocols is far less complex than carrying out full IP v6 network
migrations.
1st octet2nd octet3rd octet4th octet5th octet6th octet7th octet
0 8 16 0 8 16 24 31
10000011 LengthPointer route data =
source ip version, source prefix,
destination ip version, destination prefix
The Loose Source and Record Router (LSRR), option 3 in the IP header,
allows the source of IP network packet to supply additional routing
information to be used by the IP router or IP switch in forwarding
the IP network packet to the correct destination and to record the
route information.
The LSRR option starts with the type code, the first octet. The option
length is the second octet. The third octet is the pointer into the
route data. The pointer is relative to this option, and the smallest
legal value for the pointer is 4. The route data is a string of IP
addresses. Each internet address is 32 bits or 4 octets. An octet is
considered to be 8 bits in length.
To transmit the required four nebula parameters (32 bits or 4 octets),
the required nebula parameters can be embedded in the LSRR option as
the first IP address (32 bits) of the route data in all the network IP
packets. IP routers and IP switches block IP network packets with Loose
Source and Record Router (LSRR), IP option 3, and Strict Source Record
Route (SSRR), IP option 9, due to Internet security concerns such as IP
address spoofing. A modified LSRR record can be used solely for
transmission of the required nebula parameters (four octets or 32 bits)
as route data from a host to a router or from a router to a host.
IP network packets would then routed and switched with precision among
the new Internet Nebulae, including the existing Internet (the IP v4
address space).
4.2 Reorganizing the IP v4 Address Allocations
The implementation of multiple concurrent RIR nebulae will facilitate
a much needed reorganization of the existing and almost depleted IP v4
address space on the Internet and, more importantly, will increase
urgently needed IP v4 addresses in RIR geographical zones.
After the five RIR nebulae are implemented and connected to the current
Internet, user organizations belonging to the RIR geographical zones
(APNIC, RIPENCC, LACNIC, AFRINIC, and ARIN) can be given parallel IP
address blocks in their respective RIR nebula that correspond to their
existing Internet (IP v4) allocations to free up IP address blocks in
the existing Internet (IP v4 address space).
IP Routing on the Transitional Internet Topology
Interconnect Prefix Mirror INTERNET-APNIC-ARIN-LACNIC-RIPENIC-AFRINIC
INTERNET (ip v4) /0-/32 N/A N/A yes yes yes yes yes
APNIC (ip v10) /0-/31 /160-/191 yes N/A no no no no
ARIN (ip v11) /0-/31 /64-/95 yes no N/A no no no
LACNIC (ip v12) /0-/31 /192-/223 yes no no N/A no no
RIPENIC (ip v13) /0-/31 /128-/159 yes no no no N/A no
AFRINIC (ip v14) /0-/31 /224-/255 yes no no no no N/A
N/A stands for not applicable.
Internet routers Internet R0 (/0-/32), APNIC R1 (/160-/191),
ARIN R2 (/64-/95), LACNIC R3 (/192-/223), RIPENCC R4 (/128-/159),
AFRINIC R5 (/224-/255) manage network traffic to and from their
respective IP address spaces.
4.3 Reduction of Private Networks
The use of private networks in the new Internet, as defined in RFC1918,
must be limited to network 10.0.0.0/8 or 10.0.0.0/255.0.0.0. This private
network supports 16,777,216 IP addresses and is sufficient to satisfy
all customers who want to keep their corporate or home networks off the
Internet. The other private networks 172.16.0.0-172.31.255.255/12 or
172.16.0.0 to 172.31.255.255/255.240.0.0 and 192.168.0.0/16 or
192.168.0.0/255.255.0.0 can be returned to the IP address pool of each
RIR geographic zone or RIR nebula, to be administered by the IANA and
to be reassigned to customers to connect their networks to the Internet.
This move frees up more IP addresses for use on the Internet. We need keep
only one private network in each RIR geographic zone or RIR nebula.
However, it must be said reduction of private networks is only an option
and not a requirement for the resolution of IP address depletion problem.
With the implementation of the Internet Nebulae, the entire Class E address
range, which has been reserved for experimental purposes, can be released
for allocation to end users.
IP Addressing on the New Internet Nebulae
INTERNET (IP v4)
lemon.com
10.68.3.50
255.255.255.0
(/24)
ARIN (IP v11)
olive.com
10.68.3.50
255.255.255.0
(/88)
RIPENCC (IP v13)
raisin.fr
10.68.3.50
255.255.255.0
(/152)
APNIC (IP v10)
noni.jp
10.68.3.50
255.255.255.0
(/184)
LACNIC (IP v12)
acai.com.br
10.68.3.50
255.255.255.0
(/216)
AFRINIC (IP v14)
cherry.eg
10.68.3.50
255.255.255.0
(/248)
4.4 Routing in the Concurrent IPv4 Address Nebulae
In an Internet nebulae network environment, only IP network packets
originating in their own RIR geographical zone or RIR nebula are
forwarded to the other RIR nebulae. The network packets belonging to
an Internet nebula can only originate from its own geographical zone.
A major benefit is that Internet routing tables are greatly reduced
in size. Theoretically, we need to route and advertise about
256 Class A networks or /8 blocks from one IP address nebula to any
other IP address nebula. Each nebula manages its own network routes.
IP rules must be implemented to prevent the network packets of a RIR nebula
from being originated outside of its RIR nebula. The RIR nebulae are APNIC
(IP Version 10), ARIN (IP Version 11), LACNIC (IP Version 12), RIPENCC (IP
Version 13), AFRINIC (IP Version 14), and CURRENT INTERNET (IP Version 4).
IP Routing on the New Internet Nebulae
Internet routers R0, R1, R2, R3, R4, R5 control and forward network traffic
to and from their IP address nebula.
The routing tables on IP routers, IP switches, and IP hosts must be able
to display and process the standard prefixes (/0 to /32) and the mirror
prefixes (/33 to /255) on the extended Internet Nebulae.
routeripv4> show ospf route
Prefix Route Type Metric Next hop i/f Next hop addr
10.68.3.0/24 Intra Network 1 gig0/0/0
10.68.3.0/88 Ext2 Network 10 gig0/0/1 10.88.4.254/30
10.68.3.0/152 Ext2 Network 10 gig0/0/2 10.88.4.253/30
10.68.3.0/184 Ext2 Network 10 gig1/0/0 10.88.3.254/30
10.68.3.0/216 Ext2 Network 10 gig1/0/1 10.88.3.253/30
10.68.3.0/248 Ext2 Network 10 gig1/0/2 10.88.2.254/30
4.5 DNS Name Resolution and Reverse DNS Lookup
Domain Name Server (DNS) Resolution, Reverse DNS Lookup, Internet Control
Message Protocol (ICMP) services must be able to resolve IP addresses
to the correct fully qualified domain names (FDQN) and to reverse lookup
to the right IP address belonging to the correct RIR nebula.
nslookup 10.68.3.50/152
Server: dns101.west.ripenicc.internet.net
Address: 10.120.60.240/158
Name: raisin.fr
Address: 10.68.3.50/152
ping -a 10.68.3.50 or
ping -a 10.68.3.50/24
Pinging lemon.com [10.68.3.50/24]
Reply from 10.68.3.50/24: bytes=32 time<1ms TTL=105
Reply from 10.68.3.50/24: bytes=32 time<1ms TTL=105
Reply from 10.68.3.50/24: bytes=32 time<1ms TTL=105
Reply from 10.68.3.50/24: bytes=32 time<1ms TTL=105
ping -a 10.63.3.50/88
Pinging olive.com [10.68.3.50/88]
Reply from 10.68.3.50/88: bytes=32 time<1ms TTL=105
Reply from 10.68.3.50/88: bytes=32 time<1ms TTL=105
Reply from 10.68.3.50/88: bytes=32 time<1ms TTL=105
Reply from 10.68.3.50/88: bytes=32 time<1ms TTL=105
ping -a 10.68.3.50/216
Pinging acai.com.br [10.68.3.50/216]
Reply from 10.68.3.50/216: bytes=32 time<1ms TTL=105
Reply from 10.68.3.50/216: bytes=32 time<1ms TTL=105
Reply from 10.68.3.50/216: bytes=32 time<1ms TTL=105
Reply from 10.68.3.50/216: bytes=32 time<1ms TTL=105
4.6 Configuring Network Devices with RIR IP Settings
This solution is not complex. Every network device that must be
connected to the new Internet Nebulae environment can be preconfigured
with its respective IP Version (denoting its RIR nebula). Also, the
correct IP prefixes corresponding to the RIR geographical zone or RIR
nebula must be configured on the network device before it can be
connected to transmit or receive network traffic onto the Internet
Nebulae. This new TCP/IP requirement can be easily implemented in the
TCP/IP settings of network devices or implemented via a flash memory
registers or a dynamic RAM memory registers for embedded network
devices. Through the use the IP Version as a RIR nebula tag and
through modified routing, switching, and extended dns and ancillary
IP services, millions of network devices can be easily relocated to
their respective RIR nebula, expanding the IP address universe and
freeing up millions of IP addresses on the current IP v4 address space
without the drastic software and hardware changes required by a full
IP v4 to IP v6 network migration.
4.7 IP Multicasting on Concurrent RIR Nebulae
Class D IP addresses from 224.0.0.0 to 239.255.255.255 has been reserved
for IP multicasting functions. The routing of multicast network traffic
will not be greatly affected by the implementation of concurrent RIR
nebulae. Most of the IP multicast traffic will be routed to Internet
routers which will require modifications to be able to route the
multicast network packets correctly to their destinations. A new set of
Class D IP addresses can be set aside only for IP multicasting in the RIR
nebulae network environment. During the transition period, the modified
Internet routers must be able to route multicast traffic to and from all
RIR nebulae and the core of the Internet (IP v4). For instance, when
multicast traffic is sent to ip address 224.0.0.5 (all OSPF routers),
all OSPF routers in the Internet (IP v4) and to ip address 224.0.0.55,
for example, in the RIR nebulae (IPv4, ARIN, RIPENCC, APNIC, LACNIC,
and AFRINIC) must receive this IP multicast traffic. The IETF can make
the required protocol modifications to make multicasting work properly
across the new Internet Nebulae environment. The Internet routers must
be able to identify and process these multicast packets going from one
RIR nebula to other RIR nebulae.
IPv6 Multicast IPv4 Multicast IP Multicast
Address Address Group
Node Local Scope
FF01:0:0:0:0:0:0:1 224.0.0.1 All-nodes
FF01:0:0:0:0:0:0:2 224.0.0.2 All-routers
Link Local Scope
FF02:0:0:0:0:0:0:1 224.0.0.1 All-nodes
FF02:0:0:0:0:0:0:2 224.0.0.2 All-routers
FF02:0:0:0:0:0:0:5 224.0.0.5 OSPF
FF02:0:0:0:0:0:0:6 224.0.0.6 All OSPF DRs
FF02:0:0:0:0:0:0:9 224.0.0.9 All RIP routers
FF02:0:0:0:0:0:0:D 224.0.0.13 All PIM routers
Site Local Scope
FF05:0:0:0:0:0:0:2 224.0.0.2 All routers
Any Scope
FF0x:0:0:0:0:0:0:101 224.0.1.1 NTP
FF0x:0:0:0:0:0:0:127 224.0.1.39 cisco-rp-announce
FF0x:0:0:0:0:0:0:128 224.0.1.40 cisco-rp-discovery
IP v6 and IP v4 Multicasting IP Addresses
In the new Internet Nebulae environment, the final phase, each nebula is
able to send and receive network from and to every other nebula
(in an n x n matrix)
Interconnect INTERNET-APNIC-ARIN-LACNIC-RIPENIC-AFRINIC
INTERNET (ip v4) N/A yes yes yes yes yes
APNIC (ip v10) yes N/A yes yes yes yes
ARIN (ip v11) yes yes N/A yes yes yes
LACNIC (ip v12) yes yes yes N/A yes yes
RIPENIC (ip v13) yes yes yes yes N/A yes
AFRINIC (ip v14) yes yes yes yes yes N/A
In the new Internet Nebulae network environment, each RIR nebula is
able to forward and receive IP network packets directly from every
other RIR nebula. Each RIR manages its own IP address space (2^32
or 4.2 billion IP addresses).
The current Internet IP v4 address space becomes another nebula in the
Internet Nebulae setting and is managed by a new RIR (Regional Internet
Registry).
5. Conclusion
The recommended solution to resolve the IP v4 Address Depletion problem
is the migration from IP v4 to IP v6. The migration to IP v6, however,
requires a long term investment in project management, planning, time,
finance, hardware, software, troubleshooting, testing, documentation,
training, consulting, and human resources.
By extending the current IP v4 address space and by adding extensions
or modifications to the current family of IP v4 protocols, we extend the
life of Internet Protocol (IP) v4, saving billions of dollars in hardware,
software, and other costly upgrades required by full network migrations
to Internet Protocol (IP) v6 (IPng).
All in all, we do not need to rush head on with IP v6 network migrations
on the enterprise. The expansion of the IP v4 address space and
progressive, methodical network migrations to IP v6 can take place at the
same time. We must first solve the IP v4 address depletion problem and
thus create a time window to make the needed adjustments to IPv6, to
upgrade IP v4 only applications and systems, to create proven frameworks
for the smooth migration from IP v4 to IP v6, to workout the
incompatibility issues related to IP v6 and IPv4, and to plan the
consolidation of entire computing networks to IP v6 at a more appropriate
future time.
6. References
AFRINIC, http://www.afrinic.net
APNIC, http://www.apnic.net
ARIN, http://www.arin.net
LACNIC, http://www/lacnic.net
RIPENCC, http://ripe.net
NRO, http://www.nro.net
IANA, http://www.iana.org
IANA Internet Protocol v4 Address Space
http://www.iana.org/assignments/ipv4-address-space
http://www.ipv4depletion.com/
http://www.rfc-editor.org/
http://www.ietf.org
http://www.iab.org
http://www.cisco.com/web/about/ac123/ac147/archived_issues/
ipj_6-4/ipv4.html
http://www.cisco.com/web/about/ac123/ac147/archived_issues/
ipj_6-2/ipv6_operations_group.html
http://www.cisco.com/web/about/ac123/ac147/archived_issues/
ipj_10-3/103_addr-cons.html
http://test-ipv6.com/
http://www.ietf.org/html.charters/v6ops-charter.html
http://www.ietf.org/rfc/rfc791.txt
http://ubiquity.acm.org/article.cfm?id=1071915
8. Dedication
This Internet-Draft document is dedicated to the memory of
Dr. Jonathan Bruce Postel (Jon Postel), one of the great
scientists who helped to bring about the birth of the Internet.
9. Authors' Addresses
Johnny A. Franco Arboine
Saudi Aramco
Information Technology
Computer Operations Dept
Data Management Division
Tower Building 1st Floor North
Dhahran, Saudi Arabia 31311
<pini@acm.org>
<pini@ieee.org>
Phone: 1-856-327-4787
Fax: 1-856-327-4787
Internet Draft Expires January 28, 2012
J. Franco Arboine IP v4 Addressing Solution July 2011
