[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

<Network Working Group>                                      A. Y. Chen
Internet Draft                                                 R. R. Ati
Intended status: Experimental               Avinta Communications, Inc.
Expires: June 2018                                        A. Karandikar
                                          India Institute of Technology
                                                       December 9, 2017


                        Adaptive IPv4 Address Space
             draft-chen-ati-adaptive-ipv4-address-space-02.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 June 9, 2017.

Copyright Notice

   Copyright (c) 2017 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 June 9, 2018                  [Page 1]


Internet-Draft       Adaptive IPv4 Address Space          December 2017




   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 layer 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 deploy 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 June 9, 2018                  [Page 2]


Internet-Draft       Adaptive IPv4 Address Space          December 2017


      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 June 9, 2018                  [Page 3]


Internet-Draft       Adaptive IPv4 Address Space          December 2017


   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 estimates). Clearly, the
   demand is more than 13 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 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, the state-table used by CGN also 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 seamless
   transition.

   The EzIP approach 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 June 9, 2018                  [Page 4]


Internet-Draft       Adaptive IPv4 Address Space          December 2017


   header payload that is transparent to all these routers except a new
   category, named Semi-Public Router (SPR). By inserting a 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 words. 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 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 extends each remaining public
   address to multitudes of sub-addresses, resulting in an effectively
   much larger address resource.



Chen, et al.             Expires June 9, 2018                  [Page 5]


Internet-Draft       Adaptive IPv4 Address Space          December 2017


   In fact, the initial EzIP analysis identified the untold two-stage
   subnetting process of 192.168/16 that has been practiced routinely by
   consumer RG manufacturers 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 a private IoT. 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 identification for an RG, is implicitly capable of expanding
   a public IPv4 address by 256 times for supporting the corresponding
   number of private premises, each in turn is capable of serving 256
   IoTs utilizing the 192.168.K/24 block.

   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." This proposal did not get
   advanced.

   Substituting the third octet of 192.168/16 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 and achieves 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 pool has actually been only 3.84B (4.096B -
   256M). So, the overall public 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 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 for Avinta.com.




Chen, et al.             Expires June 9, 2018                  [Page 6]


Internet-Draft       Adaptive IPv4 Address Space          December 2017


                                       +------+
                        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 |   |              |   |
         +-----+                           |...| Premises 4   |...|
               |    Premises 1             |   |    +---------+   |
            +--+--+                        |   |    |             |
        +---+ RG1 +--+               240.0.0.0 |    |    255.255.255.255
        |   +-----+  |                         |    |
        | Premises 1 |              +----------+    |
        |            |              |    Premises 4 |
        |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 common 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
   private network blocks, 10/8, 172.16/12 and  192.168/16, such as



Chen, et al.             Expires June 9, 2018                  [Page 7]


Internet-Draft       Adaptive IPv4 Address Space          December 2017


   192.168.1.3 and 192.168.1.9 to identify the IoTs, T1a and T1z,
   respectively.

   2.2.2.   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 device on the
   Internet.

   2.2.3.   Since the existing physical connections to subscriber's
   premises appear at the ER, it is natural to have SPRs be collocated
   with their ER. 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 notation, "Public - Semi-Public: TCP
   Port". 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 June 9, 2018                  [Page 8]


Internet-Draft       Adaptive IPv4 Address Space          December 2017


  Figure 2 groups IoTs, routers and servers in two separate columns,
  EzIP-unaware or EzIP-capable, to facilitate discussions that will
  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, "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], 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 (or, 26 base 10) |
      +--------------+--------------------+-------------------------+
      | Copy Bit Set |  Class is Control  |      Option Value       |
      +--------------+--------------------+-------------------------+


                        Figure 3  Option Type Octet



Chen, et al.             Expires June 9, 2018                  [Page 9]


Internet-Draft       Adaptive IPv4 Address Space          December 2017


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

   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 appears 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, equipments among the CR
   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 private network blocks to extend the public
   pool by trading the private network operation for end-to-end
   connectivity. The fully deployed EnIP would eliminate the current
   private networks that may be against the preference of end-users who
   have found this facility 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
   described herein has 28 significant bits. It is possible for EzIP to


Chen, et al.             Expires June 9, 2018                 [Page 10]


Internet-Draft       Adaptive IPv4 Address Space          December 2017


   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 at least 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, a SPR
   must be able to follow certain decision rules to determine how to
   provide the appropriate routing service for a smooth transition to
   the long term operation. Appendix B outlines such logic and related
   considerations.


Chen, et al.             Expires June 9, 2018                 [Page 11]


Internet-Draft       Adaptive IPv4 Address Space          December 2017




   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 will be naturally
   built up.

   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) 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 with EzIP headers to 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
   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.



Chen, et al.             Expires June 9, 2018                 [Page 12]


Internet-Draft       Adaptive IPv4 Address Space          December 2017


      B.2.  On the subscriber side, SPRs should be deployed to relieve
   the public address shortage issue, 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 on the average, each
   person may have 6.6 IoTs by Year 2020 Error! Reference source not
   found., each 240/4 block is capable of serving more than 36M (256M /
   6.6) people. This exceeds the population of the largest city on earth
   (Tokyo Metro.: population 33M). 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
   from 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 queries while minimizing Internet traffic of
   repeated 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 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 will not see any IP
   packet with EzIP header at all, during the initial phase of operation
   which will be mostly basic web server access.

      C.3.  This configuration actually mimicks the PABX environment
   almost exactly. Since this entire region is only accessible through
   the gateway that performs the address translation, the 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 telephone dialing procedures using only extension
   numbers among stations served by the same PABX. 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.



Chen, et al.             Expires June 9, 2018                 [Page 13]


Internet-Draft       Adaptive IPv4 Address Space          December 2017


   D. Permanently

   In the long run, it would be best if SPRs are integrated into ERs by
   upgrading the latter's firmware to minimize the hardware and to
   streamline the overall system architecture.

   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

   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 standard 32 bit IPv4 address. There is an example of
   an upgraded TCP echo server in [RFC862] [15].

   C. Domain Name Server (DNS)


Chen, et al.             Expires June 9, 2018                 [Page 14]


Internet-Draft       Adaptive IPv4 Address Space          December 2017


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

   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.

   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


Chen, et al.             Expires June 9, 2018                 [Page 15]


Internet-Draft       Adaptive IPv4 Address Space          December 2017


   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
   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 routers. Each region can be
   divided into 1B sections, identified by the first group of SPRs. 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, their potential
   GeoLocation resolution capabilities are comparable. With additional
   two layers of SPR routing, 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 EzIP-based 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 ISP'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.

      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 for releasing the
   current addresses for new assignments, it should occupy as few public
   addresses as possible, leaving 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 =


Chen, et al.             Expires June 9, 2018                 [Page 16]


Internet-Draft       Adaptive IPv4 Address Space          December 2017


   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 may 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 handful 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 on only 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
   can be carried by two (or more) 240/4 blocks. Each 240/4 block, using
   one separate permanent public address identified gateway to access
   the worldwide Internet, 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
   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 the 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



Chen, et al.             Expires June 9, 2018                 [Page 17]


Internet-Draft       Adaptive IPv4 Address Space          December 2017


   emergency caller location system in US, mitigating the root cause of
   the cybersecurity vulnerability.

   F. With the IPv4 address pool shortage issue resolved, potential
   additional 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 under the
   EzIP scheme, let's replace it with a /8 block, 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. In fact, 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 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 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 arms-length links among them.

      c. For example, a satellite based Internet that is being proposed
   [18], can simply start fresh with one EzIP sub-Internet 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 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, upto 16M of them, may be added.

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





Chen, et al.             Expires June 9, 2018                 [Page 18]


Internet-Draft       Adaptive IPv4 Address Space          December 2017


   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.

   The 240/4 block based EzIP scheme will not only relief the IPv4
   address shortage issue, but also improves the defense against
   cybersecurity intrusion. Furthermore, the EzIP will transcend the
   IPv4 based Internet to become the common backbone for multiple
   digital communication systems that normally may operate in arm's-
   length from one another.






Chen, et al.             Expires June 9, 2018                 [Page 19]


Internet-Draft       Adaptive IPv4 Address Space          December 2017


   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

   [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



Chen, et al.             Expires June 9, 2018                 [Page 20]


Internet-Draft       Adaptive IPv4 Address Space          December 2017


   [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 June 9, 2018                 [Page 21]


Internet-Draft       Adaptive IPv4 Address Space          December 2017


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 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 June 9, 2018                 [Page 22]


Internet-Draft       Adaptive IPv4 Address Space          December 2017


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 June 9, 2018                 [Page 23]


Internet-Draft       Adaptive IPv4 Address Space          December 2017




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 June 9, 2018                 [Page 24]


Internet-Draft       Adaptive IPv4 Address Space          December 2017




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 June 9, 2018                 [Page 25]


Internet-Draft       Adaptive IPv4 Address Space          December 2017




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 June 9, 2018                 [Page 26]


Internet-Draft       Adaptive IPv4 Address Space          December 2017




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 June 9, 2018                 [Page 27]


Internet-Draft       Adaptive IPv4 Address Space          December 2017




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 June 9, 2018                 [Page 28]


Internet-Draft       Adaptive IPv4 Address Space          December 2017




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 June 9, 2018                 [Page 29]


Internet-Draft       Adaptive IPv4 Address Space          December 2017


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 of the concatenated address.

A.2.1. T1z Initiates a Session Request towards T4z

   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 June 9, 2018                 [Page 30]


Internet-Draft       Adaptive IPv4 Address Space          December 2017


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 June 9, 2018                 [Page 31]


Internet-Draft       Adaptive IPv4 Address Space          December 2017




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 June 9, 2018                 [Page 32]


Internet-Draft       Adaptive IPv4 Address Space          December 2017




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 June 9, 2018                 [Page 33]


Internet-Draft       Adaptive IPv4 Address Space          December 2017




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 June 9, 2018                 [Page 34]


Internet-Draft       Adaptive IPv4 Address Space          December 2017




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 June 9, 2018                 [Page 35]


Internet-Draft       Adaptive IPv4 Address Space          December 2017




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 June 9, 2018                 [Page 36]


Internet-Draft       Adaptive IPv4 Address Space          December 2017




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 June 9, 2018                 [Page 37]


Internet-Draft       Adaptive IPv4 Address Space          December 2017




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

                                 Figure 23






Chen, et al.             Expires June 9, 2018                 [Page 38]


Internet-Draft       Adaptive IPv4 Address Space          December 2017


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
   service. Except, when the IP header carries EzIP data as payload, the
   CGN function is enhanced to 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 June 9, 2018                 [Page 39]


Internet-Draft       Adaptive IPv4 Address Space          December 2017


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 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 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 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 June 9, 2018                 [Page 40]


Internet-Draft       Adaptive IPv4 Address Space          December 2017


   D. Upon connected to the main web server, if a customer intentionally
   selects one of the new services offered by the primary web-server,
   the web-server will 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 communication via an
   EzIP address.

      .  The SPR at the originating side, recognizing the EzIP header
   from the 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 CGN type of connection service.
   See Appendix A.3. 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 the 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 for an IoT or via a RG




Chen, et al.             Expires June 9, 2018                 [Page 41]


Internet-Draft       Adaptive IPv4 Address Space          December 2017


   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. 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 one or an
   EzIP type, 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 June 9, 2018                 [Page 42]


Internet-Draft       Adaptive IPv4 Address Space          December 2017


   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 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
   Dept. of E.E., India Institute of Technology Bombay
   Powai, Mumbai-40007, India

   Phone: _(+91-22)2576-7004
   Email: Dean.FA@IITB.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 June 9, 2018                 [Page 43]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/