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