A. Y. Chen Internet Draft R. R. Ati Intended status: Experimental Avinta Communications, Inc. Expires: December 2018 A. Karandikar India Institute of Technology June 10, 2018 Adaptive IPv4 Address Space draft-chen-ati-adaptive-ipv4-address-space-03.txt Status of this Memo This Internet-Draft is submitted 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 10, 2018. Copyright Notice Copyright (c) 2018 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. Chen, et al. Expires December 10, 2018 [Page 1] Internet-Draft Adaptive IPv4 Address Space June 2018 Abstract This document describes a solution to the Internet address depletion issue through the use of an existing Option mechanism that is part of the original IPv4 protocol. This proposal, named EzIP (phonetic for Easy IPv4), outlines the IPv4 public address pool expansion and the Internet system architecture enhancement considerations. The EzIP may expand an IPv4 address by a factor of 256M without affecting the existing IPv4 based Internet, nor the current private networks. The EzIP is in full conformance with the IPv4 protocol, and supports not only both direct and private network connectivities, but also their interoperability. The EzIP deployment may coexist with the current Internet traffic and the IoT (Internet of Things) operations without perturbing their setups, while offering end-users the freedom to choose either. If the IPv4 public pool allocations were allowed to be reorganized, the assignable pool could be multiplied by 512M times or even more. The EzIP may be implemented as a software / firmware enhancement to the Internet edge routers or private network routing gateways wherever needed, or simply installed as an inline adjunct hardware module between the two, enabling a seamless introduction. The 256M case detailed herein establishes a complete sphere of routers for interfacing between the Internet core fabic and the end user premises. Incorporating the caching proxy technology in the gateway, a fairly large geographical area may enjoy an EzIP based sub-Internet operating from as few as one ordinary IPv4 public address. This will immediately resolve the IPv4 address shortage anywhere, while transparent to the current Internet operation. Under the Dual-Stack environment, these proposed interim facilities will relieve the IPv4 address shortage issue, while affording the IPv6 more time to orderly reach the maturity and the availability levels required for delivering a long-term general service. Table of Contents 1. Introduction...................................................3 1.1. Contents of this Draft....................................5 2. EzIP Overview..................................................5 2.1. EzIP Numbering Plan.......................................5 2.2. EzIP System Architecture..................................6 2.3. IP Header with Option Word................................9 2.4. Examples of Option Mechanism.............................10 2.5. EzIP Header..............................................10 Chen, et al. Expires December 10, 2018 [Page 2] Internet-Draft Adaptive IPv4 Address Space June 2018 2.6. EzIP Operation...........................................11 3. EzIP Deployment Strategy......................................12 4. Updating Servers to Support EzIP..............................14 5. EzIP Enhancement and Application..............................15 6. Security Considerations.......................................19 7. IANA Considerations...........................................19 8. Conclusions...................................................19 9. References....................................................20 9.1. Normative References.....................................20 9.2. Informative References...................................20 10. Acknowledgments..............................................21 Appendix A EzIP Operation.......................................22 A.1. Connection between EzIP-unaware IoTs.....................22 A.1.1. T1a Initiates a Session Request towards T4a.........22 A.1.2. RG1 Forwards the Packet to SPR1.....................23 A.1.3. SPR1 Sends the Packet to SPR4 through the Internet..24 A.1.4. SPR4 Sends the Packet to T4a........................25 A.1.5. T4a Replies to SPR4.................................26 A.1.6. SPR4 Sends the Packet to SPR1 through the Internet..27 A.1.7. SPR1 Sends the Packet to RG1........................28 A.1.8. RG1 Forwards the Packet to T1a......................29 A.1.9. T1a Sends a Follow-up Packet to RG1.................29 A.2. Connection Between EzIP-capable IoTs.....................30 A.2.1. T1z Initiates a Session Request towards T4z.........30 A.2.2. RG1 Forwards the Packet to SPR1.....................31 A.2.3. SPR1 Sends the Packet to SPR4 through the Internet..32 A.2.4. SPR4 Sends the Packet to T4z........................33 A.2.5. T4z Replies to SPR4.................................34 A.2.6. SPR4 Sends the Packet to SPR1 through the Internet..35 A.2.7. SPR1 Sends the Packet to RG1........................36 A.2.8. RG1 Forwards the Packet to T1z......................37 A.2.9. T1z Sends a Follow-up Packet to RG1.................38 A.3. Connection Between EzIP-unaware and EzIP-capable IoTs....39 A.3.1. T1a Initiates a Request to T4z......................39 A.3.2. T1z Initiates a Request to T4a......................39 Appendix B Internet Transition Considerations...................40 B.1. EzIP Implementation......................................40 B.2. SPR Operation Logic......................................41 B.3. RG Enhancement...........................................42 1. Introduction For various reasons, there is a large demand for IP addresses. It would be useful to have a unique address for each Internet device, such that if desired, any device may call any other. The Internet of Things (IoT) would also be able to make use of more routable Chen, et al. Expires December 10, 2018 [Page 3] Internet-Draft Adaptive IPv4 Address Space June 2018 addresses if they were available. Currently, these are not possible with the existing IPv4 configuration. By Year 2020, the world population and number of IoTs are expected to reach 7.6B (Billion) and 50B respectively, according to a 2011 Cisco online white paper [3]. The IPv4 dot-decimal address format, consisting of four octets each made of 8 binary bits, has the maximum number of assignable addresses being 4,295 million (calculated by 256 x 256 x 256 x 256 to be 4,294,967,296 - decimal exact). Using the binary / shorthand notation of 64K representing 256 x 256 (decimal 65,536), the full IPv4 address pool of 64K x 64K may be expressed as 4,096M (Million), or 4.096B (or, further rounded down to 4B for quick estimate calculations). Clearly, the demand is more than 12 times over the inherent capacity available from the supply. The IPv6 with 128-bit hexadecimal address format, being four times as long as the IPv4, has 256BBBB (4B x 4B x 4B x 4B) combination. It offers a promising solution to this problem. However, its global adoption appears to face certain challenges [4], [5]. Network Address and Port Translation (NAPT - commonly known simply as NAT) on private networks together with Carrier Grade NAT (CG-NAT or abbreviated further to CGN) [RFC6264] [6] over the public Internet have been providing the interim relief for the IPv4 address needs thus far. Yet, NAT modules slow down routers due to the state-table look-up process. As well, they only allow an Internet session be initiated by their respective own clients, impeding the end-to-end setup requests initiated from remote devices that a fully functional communication system should be capable of. Being dynamic on the other hand, the state-table used by CGN increases CyberSecurity vulnerability. If the IPv4 capacity could be expanded to eliminate the address pool deficiency while maintaining the familiar established conventions, and perhaps even to create a reasonable address reserve, the urgency will be relaxed long enough for the IPv6 to mature on its own pace. To increase the effective Internet public address pool, there have been various proposals in the past. They all seemed to run into certain handicap or compatibility issue, preventing a smooth transition. The EzIP analysis identifies a long-reserved address block 240/4 [7] that all of the existing Internet Core (/ backbone) Router (CR), Edge Router (ER) and private network Routing (/ Residential) Gateway (RG) are not allowed to operate with, and teams with the Option mechanism defined in [RFC791] [1] for transporting such information as the IP Chen, et al. Expires December 10, 2018 [Page 4] Internet-Draft Adaptive IPv4 Address Space June 2018 header payload that is transparent to all of these routers, except a new category named Semi-Public Router (SPR). By inserting an SPR between an ER and a private premises that it serves, each publicly assignable address is expanded by 256M fold. 1.1. Contents of this Draft The rest of this draft begins with outlining the EzIP numbering plan. An enhanced IP header called EzIP header is introduced for carrying the EzIP address as payload using the Option word. The overview of the Internet architecture as the result of being extended by the EzIP scheme is explained. The EzIP header transitions through various routers and the Internet update considerations are described, with details presented in Appendices A and B, respectively. Utilizing the EzIP approach, a range of possibilities of expanding the publicly assignable IPv4 address pool as well as enhancing the Internet operations are then discussed. 2. EzIP Overview 2.1. EzIP Numbering Plan The EzIP study began with making explicit the use of the reserved private network address pools in very much the same manner as Private Automatic Branch eXchange (PABX) switching machines utilizing locally assigned "extension numbers" to expand the Public Switched Telephone Network (PSTN) capacity by replicating a public telephone line to multitudes of reusable private telephone numbers, each to identify a local instrument. At the first sight, this correlation may seem odd, because the PABX extension numbers belong to a reusable private set separate from that of the public telephone numbers and both are independently expandable, while private network IP address is a specific subset reserved from the overall IPv4 pool that is otherwise all public and finite. However, the fact that neither of the latter two is allowed to operate in the other's domain suggests that the proposed EzIP numbering plan indeed may mirror the telephony practice. The key EzIP concept is the partitioning of a finite public address pool to put aside a block of special (called "Semi-Public" in the presentation below) addresses that extend each remaining public address to multitudes of sub-addresses, resulting in an effectively much larger address resource. Chen, et al. Expires December 10, 2018 [Page 5] Internet-Draft Adaptive IPv4 Address Space June 2018 In fact, the initial EzIP study identified the untold two-stage subnetting process of 192.168/16 that has been practiced routinely for a long time. End-users are commonly accustomed to an RG choosing one out of 256 values from the fourth octet of the 192.18.K/24 block for identifying an IoT on a private premises. They mostly are, however, unaware of the preceeding stage of selecting the value "K" from the third octet of the 192.18/16 block, as the factory default RG identification assigned by a manufacturer, is implicitly capable of expanding a public IPv4 address by 256 fold for supporting the corresponding number of private premises. The elusive IPv4 240/4 block (240/8 - 255/8), been "RESERVED" for "Future use" since 1981-09 as the result of the historical address assignment evolution, was proposed to be redesignated for "Private Use" near a decade ago [2]. However, as pointed out by its own authors in Section 2. Caveats of Use, "Many implementations of the TCP/IP protocol stack have the 240.0.0.0/4 address block marked as experimental, and prevent the host from forwarding IP packets with addresses drawn from this address block." That proposal did not get advanced. Substituting the function of the third octet of 192.168.K/24 with addresses from the 240/4 block in the first stage RG and redefining it as a new category of router, called SPR, the EzIP scheme circumvents the earlier hurdles to achieve the address multiplication factor of 256M without involving any existing router. Since the 240/4 block could not be used by existing routers, the size of the assignable IPv4 public pool has actually been only 3.84B (4.096B - 256M). So, the overall addressable pool created from this EzIP approach is about 983MB (3.84B x 256M), which is over 19M times of the expected Year 2020 IoTs. This configuration certainly has the capacity to support the short- to mid- term public IP address needs. 2.2. EzIP System Architecture The new category of router, SPR is to be positoned inline between an ER and the customer premises that it serves. After the original path is re-established, the remaining addresses in the 240/4 block will be used by the SPR to serve additional prmises. Figure 1 shows a general view of the enhanced Internet system architecture with two SPRs, SPR1 and SPR4, deployed. Note that the "69.41.190.x" are static addresses. In particular, the "69.41.190.145" is the permanent public Internet address assigned to Avinta.com. Chen, et al. Expires December 10, 2018 [Page 6] Internet-Draft Adaptive IPv4 Address Space June 2018 +------+ Web Server | WS0z | +--+---+ |69.41.190.145 | | +-----+ +--+ ER0 | +--+--+ | +------+-------+ +-------+ Core Routers +--------+ | | (Internet) | | +--+--+ +--------------+ +--+--+ +-----+ ER1 | +-----+ ER4 | | +-----+ | +-----+ | | |69.41.190.110 |69.41.190.148 240.0.0.0 +--+--+ +--+--+ +-----------+ +-------+ +---------+ +------+ | +-----+ SPR1| | | +-----+ SPR4+--+ | | | +-----+ | |...| +-----+ |...| | 240.0.0.1 ... 255.255.255.255 | | +---------+ | +-----+ | | | | | 240.0.0.0 | | 255.255.255.255 |Premises 1 +----------+ | +--+--+ | Premises 4 | +---+ RG1 +--+ | | | +-----+ | | | | | | | |192.168.1.3 |192.168.1.9 |240.0.0.10 |246.1.6.40 +--+--+ +--+--+ +--+--+ +--+--+ | T1a | .... | T1z | | T4a | ....... | T4z | +-----+ +-----+ +-----+ +-----+ Figure 1 EzIP System Architecture 2.2.1. Referring to the lefthand portion labeled "Premises 1" of Figure 1, instead of assigning each premises a public IPv4 address as in the current practice, an SPR like SPR1, is inserted between an Internet Edge Router (ER1) and its connections to private network Routing Gateways like RG1, for utilizing 240.0.0.0 through 255.255.255.255 of the 240/4 block to identify respective premises. The RG1, serving either a business LAN (Local Area Network) or a residential HAN (Home Area Network), uses addresses from one of the three private network blocks, 10/8, 172.16/12 and 192.168/16, such as Chen, et al. Expires December 10, 2018 [Page 7] Internet-Draft Adaptive IPv4 Address Space June 2018 192.168.1.3 and 192.168.1.9 to identify the IoTs, T1a and T1z, respectively. 2.2.2. Part of the righthand portion of Figure 1 is labeled "Premises 4". Here SPR4 assigns addresses 240.0.0.10 and 246.1.6.40 from the 240/4 block to T4a and T4z, respectively. Consequently, these IoTs are directly accessible through SPR4 from any other IoT on the Internet. 2.2.3. Since the existing physical connections to subscriber's premises appear at the ER, it would be natural to have SPRs collocated with their ER for streamlining the interconnections. It follows that the simple routing function provided by the new SPR modules may be absorbed into the ER through a straightforward operational firmware enhancement. Consequently, the public / private demarcation line will remain at the RG where currently all utility services enter a subscriber's premises. 2.2.4. To fully tag each of these devices, we may use a concatenated three-part address, "Public - Semi-Public: TCP Port" notation. The following is how each of the IoTs in Figure 1 may be uniquely identified in the Internet. RG1: 69.41.190.110-240.0.0.0 T1a: 69.41.190.110-240.0.0.0:3 T1z: 69.41.190.110-240.0.0.0:9 T4a: 69.41.190.148-240.0.0.10 T4z: 69.41.190.148-246.1.6.40 Note that to simplify the presentation, it is assumed at this juncture that the conventional TCP (Transmission Control Protocol) [RFC793] [8] Port Number, normally assigned to T1a and T1z by RG1's NAT module upon initiating a session, equals to the fourth octet of that IoT's private IP address that is assigned by the RG1's DHCP (Dynamic Host Configuration Protocol) [RFC2123] [9] subsystem as ":3" and ":9", respectively. Such numbers are unique within each respective /24 private network such as the 192.18.1/24 here. They are adequate for the discussion purpose in this document. However, considering security, as well as allowing each IoT to have multiple simultaneous sessions, etc., this direct and singular correlation shall be avoided in actual practice by following the NAT operation conventions as depicted by the examples in Appendix A. Chen, et al. Expires December 10, 2018 [Page 8] Internet-Draft Adaptive IPv4 Address Space June 2018 Figure 2 groups IoTs, routers and servers into two separate columns, EzIP-unaware or EzIP-capable, to facilitate discussions that are to follow. +--------------------------+-----------------+----------------+ | | EzIP-unaware | EzIP-capable | +--------------------------+-----------------+----------------+ | Internet Core Router (CR)| CR | ------------ | +--------------------------+-----------------+----------------+ | Internet Edge Router (ER)| ER0, ER1, ER4 | ------------ | +--------------------------+-----------------+----------------+ | Internet of Things (IoT) | T1a, T4a | T1z, T4z | +--------------------------+-----------------+----------------+ | Routing Gateway (RG) | RG1 | ------------ | +--------------------------+-----------------+----------------+ | Semi-Public Router (SPR) | ------------- | SPR1, SPR4 | +--------------------------+-----------------+----------------+ | Web Server (WS) | ------------- | WS0z | +--------------------------+-----------------+----------------+ Figure 2 EzIP System Components 2.3. IP Header with Option Word To transport the EzIP Extension Addresses, we will make use of the Option mechanism in the IP header as defined in Figure 9 of [RFC791]. One specific aspect of its format deserves some attention. The meanings of the leading eight bits of each Option word, called "Opt. Code" or "Option-type octet", are defined on Page 15 of [RFC791]. They are somewhat confusing because the multiple names used in the literature, and how the octet is parsed into functional bit groups. For example, a two digit hexadecimal number, "0x9A", is conventionaly written in the binary bit string form as "1001 1010". As an "Opt. Code" in [RFC791], however, the eight bits are parsed into three groups of 1, 2 and 5 bits. Their meanings are summarized in Figure 3. +--------------------------------------------------------------+ | Meaning of EzIP ID = 0x9A (Example) | +--------------+------------------+----------------------------+ | 1 | 00 | 11010 | +--------------+------------------+----------------------------+ | Copy Bit Set | Class is Control |Option Value is 26 (base 10)| +--------------+------------------+----------------------------+ Figure 3 Option Type Octet Chen, et al. Expires December 10, 2018 [Page 9] Internet-Draft Adaptive IPv4 Address Space June 2018 A value of "1" for the first bit instructs all routers that this Option word is to be copied upon packet fragmentation. This preserves the Option word through such a process, if it is performed. The value of "00" for the next two bits indicates that this Option word is for "Control" purpose. The decimal "Option Value" of the last five bits, equaling to "26" is defined as the "Option Number" that is listed in the "Number" column of the Internet Protocol Version 4 (IPv4) Parameters list [10]. As can be seen there, "26" has not been assigned. Thus, it is temporarily used in this document to facilitate the EzIP presentation. The next unassigned Option Code, "0x9B" or Number "27" will also be tentatively utilized in this document. 2.4. Examples of Option Mechanism The Option mechanism has been used for various cases. Since they were mostly for utility or experimental purposes, however, their formats may be remote from the incident topic. There were two cases specifically dealt with the address pool issues. They are referenced here to assist the appreciation of the Option mechanism. A. EIP (Extended Internet Protocol) - Figure 1 of [RFC1385] [11] (Assigned but now deprecated Option Number = 17) by Z. Wang: This approach proposed to add a new network layer on top of the existing Internet for increasing the addressable space. Although equipment near the end-user would stay unchanged, equipment among the CRs apparently had to go through rather extensive upgrading procedures, perhaps due to the flexible length of the extended address (could be much longer than that of the IPv6). B. EnIP (Enhanced IPv4) - Figure 1 of Internet Draft [12] (temporarily utilizing Option Number = 26) by W. Chimiak: This work makes use of the three existing private network blocks to extend the public pool by trading the private network operation for end-to-end connectivity. The fully deployed EnIP will eliminate the current private networks which may be against the preference of end-users who have found the private network configuration quite desirable. For example, the NAT in an RG serves as a basic firewall against intrusion. 2.5. EzIP Header The header format shown in Figure 4 can transport the full 4 octet (32 bit) extension addresses of both ends of an Internet link. The extension address in the 240/4 block utilized in the EzIP scheme Chen, et al. Expires December 10, 2018 [Page 10] Internet-Draft Adaptive IPv4 Address Space June 2018 described herein has 28 significant bits. It is possible for EzIP to use addresses having other lengths of significant bits for different multiplication factors. To prepare for such variations, two EzIP ID codes, "0x9A" and "0x9B" are proposed to distinguish between Source and Destination Option words. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 |Version|IHL (8)|Type of Service| Total Length (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Source Host Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Destination Host Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EzIP ID | EzIP | Extended | Extended | 6 | (Source) | Option Length | Source | Source | | (0X9A) | (6) | No.-1 | No.-2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended | Extended | EzIP ID | EzIP | 7 | Source | Source | (Destination) | Option Length | | No.-3 | No.-4 | (0X9B) | (6) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended | Extended | Extended | Extended | 8 | Destination | Destination | Destination | Destination | | No.-1 | No.-2 | No.-3 | No.-4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 Full EzIP Header (Four octet) 2.6. EzIP Operation To convey the general scheme, Appendix A presents examples of IP header transitions through routers, between IoTs with or without EzIP capability. To introduce the EzIP approach into an environment where EzIP-unaware IoTs like T1a and T4a will be numerous for a long time to come, an SPR must be able to follow certain decision rules to determine how to provide the appropriate routing service for a smooth transition to Chen, et al. Expires December 10, 2018 [Page 11] Internet-Draft Adaptive IPv4 Address Space June 2018 the long term operation. Appendix B outlines such logic and related considerations. 3. EzIP Deployment Strategy Although the eventual goal of the SPR is to support both web server access by IoTs from behind private networks and direct end-to-end connectivity between IoTs, the former should be dealt with first to immediately mitigate the address shortage induced issues. In the process, the long term capability for the latter would be enabled naturally. A. Architecturally Since the design philosophy of the SPR is an inline module between an Internet ER (Edge Router) and the private network RG (Routing Gateway) or a directly connected IoT it serves, SPR introduction process can be flexible. A.1. A SPR may be deployed as an inline module right after an ER to begin providing the CGN equivalent function. This could be done immediately without affecting any of the existing Internet components, CR, ER and RG. EzIP-capable IoTs will then take advantage of the faster bi-directional routing service through the SPRs by initiating communication sessions utilizing EzIP headers to contact other EzIP-capable IoTs. A.2. Alternatively, a SPR may be deployed as an adjunct module just before an existing RG or a directly connected IoT to realize the same EzIP functions on the private premises, even if the serving Internet Access Provider (IAP) has not enhanced ERs with the EzIP capability. This approach could empower individual communities to enjoy the new EzIP capability on their own by upgrading all Internet subscribers within a good sized area to have publicly accessible EzIP addresses for intra-community peer-to-peer communication, based on just one (or more) existing public IPv4 address(es) for identifying the gateway(s) to the rest of the world. See sub-section C. below for more specific considerations. B. Functionally B.1. First, an IAP should install SPRs in front of business web servers so that new routing branches may be added to support the Chen, et al. Expires December 10, 2018 [Page 12] Internet-Draft Adaptive IPv4 Address Space June 2018 additional web servers for expanding business activities. Alternatively, this may be achieved if businesses on their own deploy new web servers with the SPR capability built-in. B.2. On the subscriber side, SPRs should be deployed to disseminate static addresses to the public, and to facilitate the access to new web servers. C. Regional Deployment C.1. Since the size of the 240/4 block is significant, a community mentioned in sub-section A.2. above could actually be fairly large. Based on the assumption that each person, on the average, may have 6.6 IoTs by Year 2020 Error! Reference source not found., each 240/4 block is capable of serving nearly 39M (256M / 6.6) people. This exceeds the population of the largest city on earth (33M - Tokyo Metro.). Therefore, any finite sized region can immediately begin to enjoy EzIP addressing by deploying a "sub- Internet" utilizing SPRs operating with one 240/4 block of addresses under one IPv4 public address. If the gateway for such a region is configured in a way that the entire region appears to be one ordinary IPv4 IoT to the rest of the Internet, a sub-Internet may be deployed anywhere there is the need or desire, with no perturbation to the current Internet operation whatsoever. C.2. This gateway may be constructed with a matured networking technology called Caching Proxy [13], popularized by data-intensive web services such as Google, Amazon, Yahoo, etc. Developed for speeding up response to repeated queries while minimizing Internet traffic for data exchanges with the central data bank, caching proxies are placed at strategic locations close to potential inquirers, essentially cloning the central data bank into mulitple distributed copies. This architecture meshs with the EzIP-based sub- Internet very well, because the address translation between the IPv4 in the Internet and the EzIP in the sub-Internet can be accomplished transparently through the two ports of a caching proxy. Consequently, the existing Internet routers, CR and ER even may not see any IP packet with EzIP header at all, during the initial phase of EzIP deployment which will be primarily basic web server access. C.3. This configuration actually mimicks the PABX environment almost exactly. Since the entire region is only accessible through the gateway that performs the address translation, words 4 and 5 (Source and Destination Host Numbers, respectively) in the basic IP header for an intra sub-Internet packet could simply use the addresses in the 240/4 block for expediting the routing by the SPRs. This mirrors the dialing procedures using only extension numbers Chen, et al. Expires December 10, 2018 [Page 13] Internet-Draft Adaptive IPv4 Address Space June 2018 among stations served by the same PABX, circumventing the overhead of including the common public telephone number prefix that the PABX is identified by. The full EzIP header format will only be used when an EzIP-capable IoT intends to directly interact with another EzIP- capable IoT beyond the local sub-Internet. The last part is equivalent to the DID (Direct Inward Dialing) techniques that have been used in the PABX field for many years. D. Permanently In the long run, it would be best if SPRs are integrated into their host ER by upgrading the latter's firmware to minimize the hardware and to streamline the equipment interconnections. Appendix B details the considerations in implementing these outlines. 4. Updating Servers to Support EzIP Although the IP header Option mechanism utilized by EzIP was defined a long time ago as part of the original IPv4 protocol, it has not been used much in daily traffic. Compatibility with current Internet facilities and conventions may need be reviewed. Since the EzIP data is transported as part of the IP header payload, it is not expected to affect higher layer protocols. However, certain facilities may have been optimized without considering the Option mechanism. They need be adjusted to provide the same performance to EzIP packets. There are also utility type of servers that need be updated to support the longer EzIP address. For example; A. Fast Path Internet Core Routers (CRs) are currently optimized to only provide the "fast-path" (through hardware line card) routing service to packets without Option word in the IP header [14]. This puts EzIP packets at a disadvantage position, because EzIP packets will have to go through the "slow path" (processed by CPU's software before giving to the correct hardware line card to forward), resulting in a slower throughput. Since the immediate goal of the EzIP is to ease the address pool exhaustion issue, subscribers not demanding for high throughput performance may be migrated to the EzIP supported facility first. This gives CRs time to update so that EzIP packets with authorized Option numbers will eventually be recognized for receiving the "fast-path" service. B. Connectivity Verification Chen, et al. Expires December 10, 2018 [Page 14] Internet-Draft Adaptive IPv4 Address Space June 2018 One frequently used utility for verifying baseline connectivity, commonly referred to as the "PING" function in PC terminology, needs be able to transport the full EzIP address that is 64 bits long instead of the current 32 bit IPv4 address. There is an example of an upgraded TCP echo server in [RFC862] [15]. C. Domain Name Server (DNS) Similarly, the DNS needs to expand its data format to transport the longer IP address created by the EzIP. This already can be done under IPv6. Utilizing the experimental IPv6 prefix 2001:0101 defined by [RFC2928] [16], EzIP addresses may be transported as standardized AAAA records. These topics are discussed in more detail under an IETF Draft RFC, Enhanced IPv4 - V.03 [12]. 5. EzIP Enhancement and Application To avoid disturbing any assigned addresses, deployed equipment and current operation, etc., the EzIP scheme is derived under the constraint of utilizing only the reserved 240/4 address block. If such restriction were removed by allowing the entire IPv4 address pool be re-allocatable, the assignable public address pool could be expanded significantly more, as outlined below. A. If the 240/4 block were doubled to 224/3, each existing IPv4 public address would be expanded by 512M fold. Since this block of 512M addresses have to be first reserved from the basic public pool, the resultant total addresses will be (4.096B - 512M) x 512M, or 1,835MB. This is over 36M times of the predicted number of IoTs (50B) by Year 2020. This calculation leads to additional possibilities. B. The EzIP header in Figure 4, capable of transporting the full 32 bit IPv4 address, allows the extension number be as long as practical. That is, we can go to the extreme of reserving only one bit for the network number, and using all of the rest bits for the extension address. With this criterion, the current IPv4 pool may be divided into two halves, reserving one half of it (about 2B addresses) as a semi-public network with the network number prefix equal to "1". Each of the remaining 2B public addresses (with prefix equal to "0") of the basic IPv4 pool may then be extended 2B fold through the EzIP process, resulting in a 4BB address pool. This is roughly 80M times of the Year 2020 IoT needs. Chen, et al. Expires December 10, 2018 [Page 15] Internet-Draft Adaptive IPv4 Address Space June 2018 C. If the EzIP technique were applied through several layers of SPRs in succession, the address expansion could be even more. For example, let's divide the IPv4 pool equally into four blocks, each with about 1B addresses. Apply the first 1B address block to the public routers. Set up three layers of SPRs, each makes use of one of the remaining three 1B addresses. The resultant assignable pool will have 1BBBB addresses. Under this configuration, the full length of an IoT's identification code will be the concatenation of four segments of 32 bit IPv4 address, totalling 128 bits, the same as that of the IPv6. Since the first two bits of each segment, being used to distinguish from the other three address blocks, are not significant bits, this 8-bits difference makes the IPv6 pool 256 times larger. However, this ratio is immaterial, because even the 1BBBB address pool is alreaby 20MBB times of the foreseeable need. It is the hierarchical addressing characteristics, made possible by the EzIP scheme, that will enhance the Internet, such as truncating out the common address prefix within a local community, and associating an address with the geographical reference, thus mitigating the GeoLocation issues. D. Along this line of reasoning, we could combine two 1B address blocks togther to be the basic public address. The overall assignable pool becomes 2BBB which is still 40MB times of the expected IoT need(50B). With this pool, we can divide the entire globe into 2B regions, each served by one public router. Each region can then be divided into 1B sections, identified by the first group of SPRs. Next, each section will have the second group of SPRs to manage upto 1B IoTs. Since the basic 2B public addresses are already more than half of the current total assignable IPv4 public addresses (3.84B), their potential GeoLocation resolution capabilities are comparable. With additional two layers of SPR routing, 1B for each, the address grid granuality will be so refined that locating the source of an IP packet becomes a finite task, leaving perpetrators little room to hide. E. The following outlines a possible procedure for optimizing the use of the EzIP address resource by transforming the current Internet to a GeoLocation-capable address system while maintaining the existing IPv4 addressing and operation conventions: a. Quantitative Reference: IETF [RFC6598] [17] reserved the 100.64.0.0/10 block with 4M addresses for supporting IAP's CGN service. Applying all of these to the entire IPv4 pool of 4B addresses, the maximum effective CGN supported IPv4 address pool could be 16MB. This is 0.32M times of the expected number (50B) of IoTs by Year 2020. Chen, et al. Expires December 10, 2018 [Page 16] Internet-Draft Adaptive IPv4 Address Space June 2018 b. Employing the 240/4 block with 256M addresses in the EzIP extension scheme, a /6 block with 64M addresses from the IPv4 basic public pool is sufficient to replicate the above 16MB capacity. This frees up the majority of the IPv4 public pool. c. Since this will be a temporary holding pool to release the current addresses for new assignments, it should occupy as few public addresses as possible to leave the maximum number of addresses for facilitating the long term planning. To just support the expected 50B IoTs need, only 200 IPv4 public addresses are required (200 x 256M = 50B). Thus, a /24 block with 256 addresses is more than enough to accommodate this entire migration process. This frees up even more IPv4 public addresses. d. Although a single /24 public address block is sufficient for migrating all currently perceived IPv4 address needs into one compact temporary EzIP pool, world-wide coordination of new address assignments and routing tables updates will be required. It will be more expeditious by carrying out this preparatory phase on individual country or geographical region basis utilizing public IPv4 addresses already assigned to that area and actively served by existing CR routing tables. Since 200 public addresses are enough to port the entire IoT addresses, most countries should be able to port all of their respective in-use IoTs to be under fewer than a couple of gateways for accessing the Internet. Under each gateway, one 240/4 block will handle the IoT address assignments. If this is managed according to geographical locations, each participating region will begin to enjoy the benefits of the EzIP approach, such as plentifull assignable public addresses, robust security due to inherent GeoLocation ability to spot hackers from within. So that efforts may be focused only on screening suspicious packets originated from without. e. As IoTs getting migrated to the temporary pool, the IPv4 addresses they originally occupy shall be released to re-populate the public address pool for establishing the full scale EzIP operation. f. Upon the completion of the EzIP based world-wide public address allocation map, each country can simply give up the few temporary public addresses in exchange for the permanent assignments. Since the latter is likely more than the former, addresses in one 240/4 block will be served by two (or more) 240/4 blocks. Or, each of such 240/4 block will have more than half of its capacity available to serve additional IoTs. g. This last step is very much the same as the traditional PSTN "Area Code Split" practice, whereby telephone numbers of a service Chen, et al. Expires December 10, 2018 [Page 17] Internet-Draft Adaptive IPv4 Address Space June 2018 area are split into two (or more) blocks, upon introducing one (or more) new area code(s) into the area. All subscribers will continue to use their original telephone numbers, except some may be assigned with a new area code prefix. Each area code will have more than half of its assignable telephone numbers availabe to support the future subscriber growth within its service area. Mimicking the PSTN, the EzIP based Internet will have similar GeoLocation capability as the former's caller identification based services, such as the 911 emergency caller location system in US, mitigating the root cause of the cybersecurity vulnerability. F. With the IPv4 address pool shortage issue resolved, potential applications making use of the EzIP enhanced address pool may be explored. a. Although the entire predicted number (50B) of IoTs by Year 2020 may be served by just one /24 IPv4 public address block utilizing the EzIP scheme with a 240/4 block, let's replace it with a /8 block (16M addresses), resulting in about 4MB (16M x 256M) assignable addresses. Then, only 1 out of each 80K such addresses will be used by the 50B IoTs. Or, each and every person (at Year 2020 population level) would have to own over 500K IoTs to use up this address pool. It is apparent that the spares in this allocation should be sufficient to support the growth of the IoTs for some years to come. b. The IPv4 pool originally has 256 blocks of /8 addresses. After reserving 16 blocks of them (the 240/4 block) as the reusable EzIP extension address and one to complete the pool for the above IoT needs, there are still 239 blocks of /8 addresses available to support additional digital communication systems, each may have as many addresses as those allocated to the Internet. Consequently, many world-wide communication networks may coexist under the same IPv4 protocol framework in the form of sub-Internets as described earlier, with arm's-length links among them. c. For example, a satellite based Internet that is being proposed [18], can start fresh with one EzIP sub-Internet served by one SPR having the capacity of 256M IoTs, under one ER capable of managing one /8 block of IPv4 public address. Utilizing caching proxy as the gateway to handle the data exchange with other systems, this satellite based Internet with 256M hosts will operate pretty much as an isolated system by using 240/4 addresses in the basic IP headers for intra-system communications, most of the time. Only when direct communication with another sub-Internet (such as the one for the current Internet) is needed, full EzIP header will be used. As users grow, additional sub-Internets (each with 256M IoTs capacity), may be incrementally added to support the expansion. Chen, et al. Expires December 10, 2018 [Page 18] Internet-Draft Adaptive IPv4 Address Space June 2018 G. In summary, utilizing the 240/4 address block, the EzIP scheme may expand the IPv4 based Internet to be a collection of up to 240 groups of 16M sub-Internets each managed by one SPR that are inter-operable digital communication systems, normally operate at arm's-lenghth to one another. Each of these groups will have the address capacity of at least 80K times of the number of predicted (50B) IoTs by Year 2020. 6. Security Considerations The EzIP solution is based on an inline module called SPR that intends to be as transparent to the Internet traffic as possible. Thus, no overall system security degradation is expected. 7. IANA Considerations This draft does not create a new registry nor does it register any values in existing registries; no IANA action is required. 8. Conclusions To resolve the IPv4 public address pool exhaustion issue, a technique called EzIP (phonetic for Easy IPv4) making use of a long reserved address block 240/4 is proposed. This draft RFC describes an enhancement to IPv4 operation utilizing the IP header Option mechanism defined in RFC791. Because the design criterion is to enhance IPv4 by extending instead of altering it, the impact on already in-place routers and security mechanisms is minimized. The basic EzIP intention is to maintain the existing private network configuration. Upon reclassifying the "RESERVED for Future use" 240/4 block to be the Semi-Public address pool, it will only be usable by the new SPR (Semi-Public Router) as the EzIP extension address. This pool can multiply each current IPv4 public address by 256M times, while all existing public network and subscriber premises setups (private networks as well as directly connected IoTs) will remain unchanged. This particular manifestation of the EzIP scheme appears to be the optimal solution to our needs. Chen, et al. Expires December 10, 2018 [Page 19] Internet-Draft Adaptive IPv4 Address Space June 2018 The 240/4 block based EzIP scheme will not only relief the IPv4 address shortage issue, but also improve the defense against cybersecurity intrusion by virtue of systematic address management. Furthermore, the EzIP will transcend the IPv4 based Internet to become the common backbone for multiple world-wide digital communication systems that normally may operate in arm's-length from one another. 9. References 9.1. Normative References [1] https://tools.ietf.org/html/rfc791 [2] https://tools.ietf.org/html/draft-wilson-class-e-02 9.2. Informative References [3] https://www.cisco.com/c/dam/en_us/about/ac79/docs/innov/IoT_IBS G_0411FINAL.pdf [4] http://stats.labs.apnic.net/ipv6 [5] https://ams-ix.net/technical/statistics/sflow-stats/ether-type [6] https://tools.ietf.org/html/rfc6264 [7] http://www.iana.org/assignments/ipv4-address-space/ipv4- address-space.xhtml [8] https://tools.ietf.org/html/rfc793 [9] https://www.ietf.org/rfc/rfc2131.txt [10] http://www.iana.org/assignments/ip-parameters/ip- parameters.xhtml [11] https://tools.ietf.org/html/rfc1385 [12] https://tools.ietf.org/html/draft-chimiak-enhanced-ipv4-03 [13] https://en.wikipedia.org/wiki/Proxy_server#Improving_performanc e Chen, et al. Expires December 10, 2018 [Page 20] Internet-Draft Adaptive IPv4 Address Space June 2018 [14] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.477.19 42&rep=rep1&type=pdf [15] https://tools.ietf.org/html/rfc862 [16] https://tools.ietf.org/html/rfc2928 [17] https://tools.ietf.org/html/rfc6598 [18] https://www.commerce.senate.gov/public/index.cfm/2017/10/the- commercial-satellite-industry-what-s-up-and-what-s-on-the- horizon 10. Acknowledgments The authors would express their deep appreciation to Dr. W. Chimiak for the enlightening discussions about his team's efforts and experiences through the EnIP development. This document was prepared using 2-Word-v2.0.template.dot. Chen, et al. Expires December 10, 2018 [Page 21] Internet-Draft Adaptive IPv4 Address Space June 2018 Appendix A EzIP Operation To demonstrate how EzIP could support and enhance the Internet operations, the following are three sets of examples that involve SPRs as shown in Figure 1. These present a general perspective of how IP header transitions through the routers may look like. 1. The first example is between EzIP-unaware IoTs, T1a and T4a. This operation is very much like the conventional TCP/IP packet transmission except with SPRs acting as an extra pair of routers providing the CGN service. 2. The second one is between EzIP-capable IoTs, T1z and T4z. Here, the SPRs process the extended semi-public IP addresses in router mode, avoiding the delays due to the NAT type of operations above. 3. The last one is between EzIP-unaware and EzIP-capable IoTs. By initiating and responding with a conventional IP header, T1z and T4z behave like an EzIP-unaware IoT. Thus, all packet exchanges use the conventional IP headers, just like case 1. above. A.1. Connection between EzIP-unaware IoTs A.1.1. T1a Initiates a Session Request towards T4a In Figure 5, T1a initiates a session request to SPR4 that serves T4a by sending an IP packet to RG1. There is no TCP port number in this IP header yet. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 |Version|IHL (5)|Type of Service| Total Length (20) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Source Host Number (192.168.1.3) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Destination Host Number (69.41.190.148) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 IP Header: From T1a to RG1 Chen, et al. Expires December 10, 2018 [Page 22] Internet-Draft Adaptive IPv4 Address Space June 2018 A.1.2. RG1 Forwards the Packet to SPR1 In Figure 6, RG1, allowing be masqueraded by T1a, relays the packet toward SPR1 by assigning the TCP Source port number, 3N, to T1a. Note that the suffix "N" denotes the actual TCP port number assigned by the RG1's NAT. This could assume multiple values, each represents a separate communications session that T1a is engaged in. A corresponding entry is created in the state table for handling the responding reply packet from the Destination site. Since T4a's TCP port number is not known yet, it is filled with all 1's. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 |Version|IHL (5)|Type of Service| Total Length (24) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Source Host Number (240.0.0.0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Destination Host Number (69.41.190.148) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Source Port (3N) | Destination Port (All 1's) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 TCP/IP Header: From RG1 to SPR1 Chen, et al. Expires December 10, 2018 [Page 23] Internet-Draft Adaptive IPv4 Address Space June 2018 A.1.3. SPR1 Sends the Packet to SPR4 through the Internet In Figure 7, SPR1 allowing masqueraded by RG1 (with the Source Host Number changed to be its own and the TCP port number changed to 0C, where "C" stands for CGN) sends the packet out through the Internet towards SPR4. The packet traverses through the Internet (ER1, CR and ER4) utilizing only the basic IP header portion of address information (words 4 & 5). 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 |Version|IHL (5)|Type of Service| Total Length (24) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Source Host Number (69.41.190.110) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Destination Host Number (69.41.190.148) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Source Port (0C) | Destination Port (All 1's) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7 TCP/IP Header: From SPR1 to SPR4 Chen, et al. Expires December 10, 2018 [Page 24] Internet-Draft Adaptive IPv4 Address Space June 2018 A.1.4. SPR4 Sends the Packet to T4a Since the packet has a conventional IP header without Destination TCP port number, SPR4 would ordinarily drop it due to the CGN function. However, for this example, let's assume that there exists a state- table that was set up by a DMZ (De-Militaried Zone) process for redirecting this packet to T4a with a CGN TCP port number 10C (the fourth octet, "10" of T4a's Extension address). In Figure 8, SPR4 sends the packet to T4a by constructing the destination address accordingly. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 |Version|IHL (5)|Type of Service| Total Length (24) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Source Host Number (69.41.190.110) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Destination Host Number (240.0.0.10) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Source Port (0C) | Destination Port (10C) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8 TCP/IP Header: From SPR4 to T4a Chen, et al. Expires December 10, 2018 [Page 25] Internet-Draft Adaptive IPv4 Address Space June 2018 A.1.5. T4a Replies to SPR4 In Figure 9, when T4a replies to SPR4, it interchanges the Source and Destination identifications to create an IP header for the reply packet. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 |Version|IHL (5)|Type of Service| Total Length (24) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Source Host Number (240.0.0.10) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Destination Host Number (69.41.190.110) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Source Port (10C) | Destination Port (0C) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9 TCP/IP Header: From T4a to SPR4 Chen, et al. Expires December 10, 2018 [Page 26] Internet-Draft Adaptive IPv4 Address Space June 2018 A.1.6. SPR4 Sends the Packet to SPR1 through the Internet In Figure 10, SPR4 sends the packet toward SPR1 with the following header through the Internet (ER4, CR and ER1) who will simply relay the packet according to the information in word 5 (Destination Host Number): 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 |Version|IHL (5)|Type of Service| Total Length (24) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Source Host Number (69.41.190.148) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Destination Host Number (69.41.190.110) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Source Port (10C) | Destination Port (0C) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10 TCP/IP Header: From SPR4 to SPR1 Chen, et al. Expires December 10, 2018 [Page 27] Internet-Draft Adaptive IPv4 Address Space June 2018 A.1.7. SPR1 Sends the Packet to RG1 In Figure 11, RG1 address is reconstructed by using the information in the CGN state-table stored in SPR1. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 |Version|IHL (5)|Type of Service| Total Length (24) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Source Host Number (69.41.190.148) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Destination Host Number (240.0.0.0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Source Port (10C) | Destination Port (3N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11 TCP/IP Header: From SPR1 to RG1 Chen, et al. Expires December 10, 2018 [Page 28] Internet-Draft Adaptive IPv4 Address Space June 2018 A.1.8. RG1 Forwards the Packet to T1a In Figure 12, T1a address is reconstructed from the state-table in RG1's NAT based on Destination Port (3N). 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 |Version|IHL (5)|Type of Service| Total Length (24) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Source Host Number (69.41.190.148) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Destination Host Number (192.168.1.3) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Source Port (10C) | Destination Port (3N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12 TCP/IP Header: From RG1 to T1a A.1.9. T1a Sends a Follow-up Packet to RG1 To carry on the communication, T1a in Figure 13 sends the follow-up packet to RG1 with a full TCP/IP header. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 |Version|IHL (5)|Type of Service| Total Length (24) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Source Host Number (192.168.1.3) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Destination Host Number (69.41.190.148) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Source Port (3N) | Destination Port (10C) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13 TCP/IP Header: Follow-up Packets From T1a to RG1 Chen, et al. Expires December 10, 2018 [Page 29] Internet-Draft Adaptive IPv4 Address Space June 2018 A.2. Connection Between EzIP-capable IoTs The following is an example of EzIP operation between T1z and T4z shown in Figure 1. Each knows its own full "Public - EzIP : Private" network addresses, "69.41.190.110-240.0.0.0:9" and "69.41.190.148- 246.1.6.40", respectively, as well as the other's. Note that T4z is directly addressable from the Internet. It does not have the private portion (TCP port number) in the concatenated address. A.2.1. T1z Initiates a Session Request towards T4z In Figure 14, T1z sends an EzIP packet to RG1. There is no TCP port number word, because T4z does not have such and that for T1z has not been assigned by the RG1's NAT. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 |Version|IHL (8)|Type of Service| Total Length (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Source Host Number (192.168.1.9) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Destination Host Number (69.41.190.148) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EzIP ID | EzIP | Extended | Extended | 6 | (Source) | Option Length | Source | Source | | (0X9A) | (6) | No.-1 (240) | No.-2 (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended | Extended | EzIP ID | EzIP | 7 | Source | Source | (Destination) | Option Length | | No.-3 (0) | No.-4 (0) | (0X9B) | (6) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended | Extended | Extended | Extended | 8 | Destination | Destination | Destination | Destination | | No.-1 (246) | No.-2 (1) | No.-3 (6) | No.-4 (40) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14 EzIP Header: From T1z to RG1 Note that 0X9A and 0X9B are temporarily selected from the available "IP Option Numbers" [10]. Chen, et al. Expires December 10, 2018 [Page 30] Internet-Draft Adaptive IPv4 Address Space June 2018 A.2.2. RG1 Forwards the Packet to SPR1 In Figure 15, RG1, allowing to be masqueraded by T1z, relays the packet toward SPR1 by assigning the TCP Source port number, 9N, to T1z. Since T4z is directly connected to the Internet, there is no private network information to fill the Destination portion of the TCP word. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 |Version|IHL (8)|Type of Service| Total Length (36) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Source Host Number (240.0.0.0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Destination Host Number (69.41.190.148) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EzIP ID | EzIP | Extended | Extended | 6 | (Source) | Option Length | Source | Source | | (0X9A) | (6) | No.-1 (240) | No.-2 (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended | Extended | EzIP ID | EzIP | 7 | Source | Source | (Destination) | Option Length | | No.-3 (0) | No.-4 (0) | (0X9B) | (6) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended | Extended | Extended | Extended | 8 | Destination | Destination | Destination | Destination | | No.-1 (246) | No.-2 (1) | No.-3 (6) | No.-4 (40) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | Source Port (9N) | Destination Port (All 1's) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15 TCP/EzIP Header: From RG1 to SPR1 Chen, et al. Expires December 10, 2018 [Page 31] Internet-Draft Adaptive IPv4 Address Space June 2018 A.2.3. SPR1 Sends the Packet to SPR4 through the Internet In Figure 166, SPR1 sends the packet out into the Internet towards SPR4. The packet traverses through the Internet (ER1, CR and ER4), utilizing only the basic IP header portion of address information. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 |Version|IHL (8)|Type of Service| Total Length (36) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Source Host Number (69.41.190.110) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Destination Host Number (69.41.190.148) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EzIP ID | EzIP | Extended | Extended | 6 | (Source) | Option Length | Source | Source | | (0X9A) | (6) | No.-1 (240) | No.-2 (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended | Extended | EzIP ID | EzIP | 7 | Source | Source | (Destination) | Option Length | | No.-3 (0) | No.-4 (0) | (0X9B) | (6) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended | Extended | Extended | Extended | 8 | Destination | Destination | Destination | Destination | | No.-1 (246) | No.-2 (1) | No.-3 (6) | No.-4 (40) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | Source Port (9N) | Destination Port (All 1's) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16 TCP/EzIP Header: From SPR1 to SPR4 Chen, et al. Expires December 10, 2018 [Page 32] Internet-Draft Adaptive IPv4 Address Space June 2018 A.2.4. SPR4 Sends the Packet to T4z In Figure 17, SPR4 sends the packet to T4z by reconstructing its address from the Option number and the Extended Destination No. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 |Version|IHL (8)|Type of Service| Total Length (36) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Source Host Number (69.41.190.110) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Destination Host Number (246.1.6.40) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EzIP ID | EzIP | Extended | Extended | 6 | (Source) | Option Length | Source | Source | | (0X9A) | (6) | No.-1 (240) | No.-2 (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended | Extended | EzIP ID | EzIP | 7 | Source | Source | (Destination) | Option Length | | No.-3 (0) | No.-4 (0) | (0X9B) | (6) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended | Extended | Extended | Extended | 8 | Destination | Destination | Destination | Destination | | No.-1 (246) | No.-2 (1) | No.-3 (6) | No.-4 (40) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | Source Port (9N) | Destination Port (All 1's) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 17 TCP/EzIP Header: From SPR4 to T4z Chen, et al. Expires December 10, 2018 [Page 33] Internet-Draft Adaptive IPv4 Address Space June 2018 A.2.5. T4z Replies to SPR4 In Figure 18, T4z replies to SPR4 with the full T1z identification 69.41.190.110-240.0.0.0:9N to create an EzIP header for the reply packet. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 |Version|IHL (8)|Type of Service| Total Length (36) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Source Host Number (246.1.6.40) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Destination Host Number (69.41.190.110) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EzIP ID | EzIP | Extended | Extended | 6 | (Source) | Option Length | Source | Source | | (0X9A) | (6) | No.-1 (246) | No.-2 (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended | Extended | EzIP ID | EzIP | 7 | Source | Source | (Destination) | Option Length | | No.-3 (6) | No.-4 (40) | (0X9B) | (6) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended | Extended | Extended | Extended | 8 | Destination | Destination | Destination | Destination | | No.-1 (240) | No.-2 (0) | No.-3 (0) | No.-4 (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | Source Port (All 1's) | Destination Port (9N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 18 TCP/EzIP Header: From T4z to SPR4 Chen, et al. Expires December 10, 2018 [Page 34] Internet-Draft Adaptive IPv4 Address Space June 2018 A.2.6. SPR4 Sends the Packet to SPR1 through the Internet In Figure 19, SPR4 sends the packet toward SPR1 with the following header through the Internet (ER2, CR, and ER1) who will simply relay the packet according to the information in word 5 (Destination Host Number): 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 |Version|IHL (8)|Type of Service| Total Length (36) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Source Host Number (69.41.190.148) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Destination Host Number (69.41.190.110) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EzIP ID | EzIP | Extended | Extended | 6 | (Source) | Option Length | Source | Source | | (0X9A) | (6) | No.-1 (246) | No.-2 (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended | Extended | EzIP ID | EzIP | 7 | Source | Source | (Destination) | Option Length | | No.-3 (6) | No.-4 (40) | (0X9B) | (6) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended | Extended | Extended | Extended | 8 | Destination | Destination | Destination | Destination | | No.-1 (240) | No.-2 (0) | No.-3 (0) | No.-4 (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | Source Port (All 1's) | Destination Port (9N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 19 TCP/EzIP Header: From SPR4 to SPR1 Chen, et al. Expires December 10, 2018 [Page 35] Internet-Draft Adaptive IPv4 Address Space June 2018 A.2.7. SPR1 Sends the Packet to RG1 In Figure 20, RG1 address is reconstructed from the Option number and the Extended Destination No. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 |Version|IHL (8)|Type of Service| Total Length (36) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Source Host Number (69.41.190.148) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Destination Host Number (240.0.0.0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EzIP ID | EzIP | Extended | Extended | 6 | (Source) | Option Length | Source | Source | | (0X9A) | (6) | No.-1 (246) | No.-2 (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended | Extended | EzIP ID | EzIP | 7 | Source | Source | (Destination) | Option Length | | No.-3 (6) | No.-4 (40) | (0X9B) | (6) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended | Extended | Extended | Extended | 8 | Destination | Destination | Destination | Destination | | No.-1 (240) | No.-2 (0) | No.-3 (0) | No.-4 (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | Source Port (All 1's) | Destination Port (9N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 20 TCP/EzIP Header: From SPR1 to RG1 Chen, et al. Expires December 10, 2018 [Page 36] Internet-Draft Adaptive IPv4 Address Space June 2018 A.2.8. RG1 Forwards the Packet to T1z In Figure 21, T1z address is reconstructed from RG1's NAT state-table based on Destination Port (9N). 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 |Version|IHL (8)|Type of Service| Total Length (36) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Source Host Number (69.41.190.148) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Destination Host Number (192.168.1.9) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EzIP ID | EzIP | Extended | Extended | 6 | (Source) | Option Length | Source | Source | | (0X9A) | (6) | No.-1 (246) | No.-2 (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended | Extended | EzIP ID | EzIP | 7 | Source | Source | (Destination) | Option Length | | No.-3 (6) | No.-4 (40) | (0X9B) | (6) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended | Extended | Extended | Extended | 8 | Destination | Destination | Destination | Destination | | No.-1 (240) | No.-2 (0) | No.-3 (0) | No.-4 (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | Source Port (All 1's) | Destination Port (9N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 21 TCP/EzIP Header: From RG1 to T1z Chen, et al. Expires December 10, 2018 [Page 37] Internet-Draft Adaptive IPv4 Address Space June 2018 A.2.9. T1z Sends a Follow-up Packet to RG1 In Figure 22, T1z sends a follow-up packet to RG1 with all fields filled with needed information. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 |Version|IHL (8)|Type of Service| Total Length (36) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Source Host Number (192.168.1.9) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Destination Host Number (69.41.190.148) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EzIP ID | EzIP | Extended | Extended | 6 | (Source) | Option Length | Source | Source | | (0X9A) | (6) | No.-1 (240) | No.-2 (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended | Extended | EzIP ID | EzIP | 7 | Source | Source | (Destination) | Option Length | | No.-3 (0) | No.-4 (0) | (0X9B) | (6) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended | Extended | Extended | Extended | 8 | Destination | Destination | Destination | Destination | | No.-1 (246) | No.-2 (1) | No.-3 (6) | No.-4 (40) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | Source Port (9N) | Destination Port (All 1's) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 22 TCP/EzIP Header: Follow-up Packets from T1z to RG1 Chen, et al. Expires December 10, 2018 [Page 38] Internet-Draft Adaptive IPv4 Address Space June 2018 A.3. Connection Between EzIP-unaware and EzIP-capable IoTs A.3.1. T1a Initiates a Request to T4z Since T1a can create only conventional format IP header, the SPRs will provide CGN type of services to the IP packets. And, assuming SPR4 has a state-table set up by DMZ for forwarding the request to T4z, the packet will be delivered to T4z. Seeing the incoming packet with conventional IP header, T4z should respond with the same so that the session will be conducted with conventional TCP/IP headers. The interaction will follow the same behavior as in Appedix A.1. A.3.2. T1z Initiates a Request to T4a Knowing T4a is not capable of EzIP header, T1z purposely initiates the request packet using conventional IP header. It will be treated by SPRs in the same manner as the T1a initiated case above and the packet will be recognizable by T4a. In brief, the steps outlined above are very much the same as the conventional TCP/IP header transitions between routers with CGN support. Except, when the IP header carries EzIP data as payload, the CGN function is replaced by the SPR process. Note that when an IoT, such as T4a or T4z, is directly connected to a SPR, like SPR4, there is no RG in between. There is no corresponding TCP port number in word 9 of the above TCP/EzIP headers. This spare facility in the header allows an RG be inserted, thus incorporating the private network environment like that on Premises 1, if desired. Chen, et al. Expires December 10, 2018 [Page 39] Internet-Draft Adaptive IPv4 Address Space June 2018 Appendix B Internet Transition Considerations To enhance a large communication system like the Internet, it is important to minimize the disturbance to the existing equipments and processes due to any needed modification. The basic EzIP plan is to confine all actionable enhancements within the new SPR module. The following outlines the considerations for supporting the transition from the current Internet to the one enhanced by the EzIP technique. B.1. EzIP Implementation B.1.1. Introductory Phase: A. Insert an SPR in front of a web-server that desires to have additional subnet addresses for offering diversified activities. For the long term, a new web server may be designed with these two functional modules combined. . The first address of a private network address pool, e.g., 242.0.0.0, used by the SPR should be reserved as a DMZ channel directing the initial incoming service requesting packets to the existing web server. This will maintain the same current operation behavior projected to the general public. . The additional addresses, up to 242.255.255.255 may be used for EzIP address extension purposes. Each may be assigned to an additional web server representing one of the business's new activities. Each of these new servers will then respond with EzIP header to messages forwarded from the main server, or be directly accessible through its own EzIP address. B. Insert an SPR in front of a group of subscribers who are to be served with the EzIP capability. The basic service provided by this SPR will be the CGN equivalent function. This will maintain the same baseline user experience in accessing the Internet currently. C. Session initiating packets with basic IPv4 header will be routed by SPRs to a business's existing server at the currently published IPv4 public address (discoverable through existing DNS). The server should respond with the basic IPv4 format as well. Essentially, this maintains the existing interaction behavior between a user and a web server within an EzIP-unaware environment. So far, neither the web-server nor any subscriber's IoTs needs to be enhanced, because the operations remain pretty much the same as today's common practice utilizing CGN assisted connectivity. See Appendix A.1. for an example. Chen, et al. Expires December 10, 2018 [Page 40] Internet-Draft Adaptive IPv4 Address Space June 2018 D. Upon connected to the main web server, if a customer intentionally selects one of the new services, the main web server should ask the customer to confirm the selection. . If confirmed, implying that the customer is aware of the fact that his IoT is being served by an SPR, the web server forwards the request to a branch server for carrying on the session via an EzIP address. . The SPR at the originating side, recognizing the EzIP header from the additional web-server, replaces the CGN service with the EzIP routing. . For all subsequent packets exchanged, the EzIP headers will be used in both directions. See Appendix A.2. for an example. This will speed up the transmission throughput performance for the rest of the session. B.1.2. New IoT Operation Modes: A. EzIP-capable IoT will create EzIP header in initiating a session, to directly reach a specific EzIP-capable web-server, instead of the lengthy steps of going through the DMZ port followed by manually making the selection from the main web server. This will speed up the initial handshake process. See Appendix A.2. for an example. B. To communicate with an EzIP-unaware IoT, an EzIP-capable IoT should purposely initiate a session with conventional IP header. This will signal the SPRs to provide just the CGN type of connection service. See Appendix A.1. for an example. B.1.3. End-to-End Operation: Once EzIP-capable IoTs become common for the general public, direct communication between any pair of such IoTs will be achievable. An EzIP-capable IoT, knowing the other IoT's full EzIP address, may initiate a session by creating an EzIP header that directs SPRs to provide EzIP services, bypassing the CGN process. See Appendix A.2. for an example. B.2. SPR Operation Logic To support the above scenarios, the SPR should be designed with the following decision process: B.2.1. Initiating a Session Request from an IoT or via a RG Chen, et al. Expires December 10, 2018 [Page 41] Internet-Draft Adaptive IPv4 Address Space June 2018 If a session request IP packet contains EzIP Option word, it will be routed forward by SPR accordingly. Otherwise, the SPR provides CGN service by assigning a TCP port number to the packet and allowing the packet to masquerade with the SPR's own IP address while an entry to the state (port-forward / look-up / hash) table is created in anticipation of the reply packet. B.2.2. Receiving a Session Request from the ER If a received IP packet includes a valid EzIP Option word or port number, SPR will utilize it to route the packet to an RG or an IoT. For a packet with plain IP header, it will be routed according to the Destination Host Number (IP header word 5). B.3. RG Enhancement With IPv4 address pool expanded by the EzIP schemes, there will be sufficient publicly assignable addresses for IoTs wishing to be directly accessible from the Internet. On the other hand, the existing private networks may continue their current behavior of blocking session-request packets from the Internet. In-between, another connection mode is possible. The following describes such an option in the context of the existing RG operation conventions. B.3.1. Initiating Session request for an IoT Without regard to whether the IP header is a conventional type or an EzIP one, a RG allows a packet to masquerade with the RG's own IP address by assigning a TCP port number to the packet and creating an entry to the state (port-forward / look-up / hash) table. This is the same as the current NAT practice. B.3.2. Receiving a packet from the SPR The "Destination Port" value in the packet is examined: A. If it matches with an entry in the RG NAT's state-table, the packet is forward to the corresponding address. This is the same as the normal NAT processes in a conventional RG. B. If it matches with the address of an active IoT on the private network, the packet is assigned with a TCP port number and then forwarded to that IoT. Note that there is certain amount of increased security risk with this added last step, because a match between a guessed destination identity and the above two lists could happen by chance. To address Chen, et al. Expires December 10, 2018 [Page 42] Internet-Draft Adaptive IPv4 Address Space June 2018 this issue, the following proactive mechanism should be incorporated in parallel: If the "Destination Port" number is null or does not match with either of the above two cases, the packet is dropped and an alarm state is activated to monitor for possible ill-intended follow-up attempts. A defensive mechanism should be triggered when the number of failed attempts has exceeded the preset threshold within a predetermined finite time interval. In brief, if the IP header of a session requesting packet indicates that the sender knows the identity of the desired destination IoT on a private network, the common RG screening process will be bypassed. This facilitates the direct end-to-end connection, even in the presence of the NAT. Note that this process is very much the same as the AA (Automated Attendant) capability in a PABX telephone switching system that automatically makes the connection for a caller who indicates (via proper secondary dialing or the equivalent) knowing the extension number of the destination party. Such process has effectively screened out most of the unwanted callers while serves the acquaintance expeditiously. Authors' Addresses Abraham Y. Chen Avinta Communications, Inc. 142 N. Milpitas Blvd., #148, Milpitas, CA 95035-4401 US Phone: _+1(408)942-1485 Email: AYChen@Avinta.com Abhay Karandikar Director, India Institute of Technology Kanpur Kanpur - 208 016, U.P., India Phone: _(+91)512 256 7220 Email: Director@IITK.ac.in Ramamurthy R. Ati Avinta Communications, Inc. 142 N. Milpitas Blvd., #148, Milpitas, CA 95035-4401 US Phone: _+1(408)458-7109 Email: rama_ati@outlook.com Chen, et al. Expires December 10, 2018 [Page 43]