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

Versions: 00 01 02 03 04

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


                        Adaptive IPv4 Address Space
             draft-chen-ati-adaptive-ipv4-address-space-03.txt


Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on December 10, 2018.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Chen, et al.          Expires December 10, 2018                [Page 1]


Internet-Draft       Adaptive IPv4 Address Space              June 2018




   Abstract

   This document describes a solution to the Internet address depletion
   issue through the use of an existing Option mechanism that is part of
   the original IPv4 protocol. This proposal, named EzIP (phonetic for
   Easy IPv4), outlines the IPv4 public address pool expansion and the
   Internet system architecture enhancement considerations. The EzIP may
   expand an IPv4 address by a factor of 256M without affecting the
   existing IPv4 based Internet, nor the current private networks. The
   EzIP is in full conformance with the IPv4 protocol, and supports not
   only both direct and private network connectivities, but also their
   interoperability. The EzIP deployment may coexist with the current
   Internet traffic and the IoT (Internet of Things) operations without
   perturbing their setups, while offering end-users the freedom to
   choose either. If the IPv4 public pool allocations were allowed to be
   reorganized, the assignable pool could be multiplied by 512M times or
   even more. The EzIP may be implemented as a software / firmware
   enhancement to the Internet edge routers or private network routing
   gateways wherever needed, or simply installed as an inline adjunct
   hardware module between the two, enabling a seamless introduction.
   The 256M case detailed herein establishes a complete sphere of
   routers for interfacing between the Internet core fabic and the end
   user premises. Incorporating the caching proxy technology in the
   gateway, a fairly large geographical area may enjoy an EzIP based
   sub-Internet operating from as few as one ordinary IPv4 public
   address. This will immediately resolve the IPv4 address shortage
   anywhere, while transparent to the current Internet operation. Under
   the Dual-Stack environment, these proposed interim facilities will
   relieve the IPv4 address shortage issue, while affording the IPv6
   more time to orderly reach the maturity and the availability levels
   required for delivering a long-term general service.



   Table of Contents


   1. Introduction...................................................3
      1.1. Contents of this Draft....................................5
   2. EzIP Overview..................................................5
      2.1. EzIP Numbering Plan.......................................5
      2.2. EzIP System Architecture..................................6
      2.3. IP Header with Option Word................................9
      2.4. Examples of Option Mechanism.............................10
      2.5. EzIP Header..............................................10


Chen, et al.          Expires December 10, 2018                [Page 2]


Internet-Draft       Adaptive IPv4 Address Space              June 2018


      2.6. EzIP Operation...........................................11
   3. EzIP Deployment Strategy......................................12
   4. Updating Servers to Support EzIP..............................14
   5. EzIP Enhancement and Application..............................15
   6. Security Considerations.......................................19
   7. IANA Considerations...........................................19
   8. Conclusions...................................................19
   9. References....................................................20
      9.1. Normative References.....................................20
      9.2. Informative References...................................20
   10. Acknowledgments..............................................21
   Appendix A  EzIP Operation.......................................22
      A.1. Connection between EzIP-unaware IoTs.....................22
         A.1.1. T1a Initiates a Session Request towards T4a.........22
         A.1.2. RG1 Forwards the Packet to SPR1.....................23
         A.1.3. SPR1 Sends the Packet to SPR4 through the Internet..24
         A.1.4. SPR4 Sends the Packet to T4a........................25
         A.1.5. T4a Replies to SPR4.................................26
         A.1.6. SPR4 Sends the Packet to SPR1 through the Internet..27
         A.1.7. SPR1 Sends the Packet to RG1........................28
         A.1.8. RG1 Forwards the Packet to T1a......................29
         A.1.9. T1a Sends a Follow-up Packet to RG1.................29
      A.2. Connection Between EzIP-capable IoTs.....................30
         A.2.1. T1z Initiates a Session Request towards T4z.........30
         A.2.2. RG1 Forwards the Packet to SPR1.....................31
         A.2.3. SPR1 Sends the Packet to SPR4 through the Internet..32
         A.2.4. SPR4 Sends the Packet to T4z........................33
         A.2.5. T4z Replies to SPR4.................................34
         A.2.6. SPR4 Sends the Packet to SPR1 through the Internet..35
         A.2.7. SPR1 Sends the Packet to RG1........................36
         A.2.8. RG1 Forwards the Packet to T1z......................37
         A.2.9. T1z Sends a Follow-up Packet to RG1.................38
      A.3. Connection Between EzIP-unaware and EzIP-capable IoTs....39
         A.3.1. T1a Initiates a Request to T4z......................39
         A.3.2. T1z Initiates a Request to T4a......................39
   Appendix B  Internet Transition Considerations...................40
      B.1. EzIP Implementation......................................40
      B.2. SPR Operation Logic......................................41
      B.3. RG Enhancement...........................................42


   1. Introduction

   For various reasons, there is a large demand for IP addresses. It
   would be useful to have a unique address for each Internet device,
   such that if desired, any device may call any other. The Internet of
   Things (IoT) would also be able to make use of more routable


Chen, et al.          Expires December 10, 2018                [Page 3]


Internet-Draft       Adaptive IPv4 Address Space              June 2018


   addresses if they were available. Currently, these are not possible
   with the existing IPv4 configuration.

   By Year 2020, the world population and number of IoTs are expected to
   reach 7.6B (Billion) and 50B respectively, according to a 2011 Cisco
   online white paper [3].

   The IPv4 dot-decimal address format, consisting of four octets each
   made of 8 binary bits, has the maximum number of assignable addresses
   being 4,295 million (calculated by 256 x 256 x 256 x 256 to be
   4,294,967,296 - decimal exact). Using the binary / shorthand notation
   of 64K representing 256 x 256 (decimal 65,536), the full IPv4 address
   pool of 64K x 64K may be expressed as 4,096M (Million), or 4.096B
   (or, further rounded down to 4B for quick estimate calculations).
   Clearly, the demand is more than 12 times over the inherent capacity
   available from the supply.

   The IPv6 with 128-bit hexadecimal address format, being four times as
   long as the IPv4, has 256BBBB (4B x 4B x 4B x 4B) combination. It
   offers a promising solution to this problem. However, its global
   adoption appears to face certain challenges [4], [5]. Network Address
   and Port Translation (NAPT - commonly known simply as NAT) on private
   networks together with Carrier Grade NAT (CG-NAT or abbreviated
   further to CGN) [RFC6264] [6] over the public Internet have been
   providing the interim relief for the IPv4 address needs thus far.
   Yet, NAT modules slow down routers due to the state-table look-up
   process. As well, they only allow an Internet session be initiated by
   their respective own clients, impeding the end-to-end setup requests
   initiated from remote devices that a fully functional communication
   system should be capable of. Being dynamic on the other hand, the
   state-table used by CGN increases CyberSecurity vulnerability.

   If the IPv4 capacity could be expanded to eliminate the address pool
   deficiency while maintaining the familiar established conventions,
   and perhaps even to create a reasonable address reserve, the urgency
   will be relaxed long enough for the IPv6 to mature on its own pace.

   To increase the effective Internet public address pool, there have
   been various proposals in the past. They all seemed to run into
   certain handicap or compatibility issue, preventing a smooth
   transition.

   The EzIP analysis identifies a long-reserved address block 240/4 [7]
   that all of the existing Internet Core (/ backbone) Router (CR), Edge
   Router (ER) and private network Routing (/ Residential) Gateway (RG)
   are not allowed to operate with, and teams with the Option mechanism
   defined in [RFC791] [1] for transporting such information as the IP


Chen, et al.          Expires December 10, 2018                [Page 4]


Internet-Draft       Adaptive IPv4 Address Space              June 2018


   header payload that is transparent to all of these routers, except a
   new category named Semi-Public Router (SPR). By inserting an SPR
   between an ER and a private premises that it serves, each publicly
   assignable address is expanded by 256M fold.

        1.1. Contents of this Draft

   The rest of this draft begins with outlining the EzIP numbering plan.
   An enhanced IP header called EzIP header is introduced for carrying
   the EzIP address as payload using the Option word. The overview of
   the Internet architecture as the result of being extended by the EzIP
   scheme is explained. The EzIP header transitions through various
   routers and the Internet update considerations are described, with
   details presented in Appendices A and B, respectively. Utilizing the
   EzIP approach, a range of possibilities of expanding the publicly
   assignable IPv4 address pool as well as enhancing the Internet
   operations are then discussed.



   2. EzIP Overview

       2.1. EzIP Numbering Plan

   The EzIP study began with making explicit the use of the reserved
   private network address pools in very much the same manner as Private
   Automatic Branch eXchange (PABX) switching machines utilizing locally
   assigned "extension numbers" to expand the Public Switched Telephone
   Network (PSTN) capacity by replicating a public telephone line to
   multitudes of reusable private telephone numbers, each to identify a
   local instrument.

   At the first sight, this correlation may seem odd, because the PABX
   extension numbers belong to a reusable private set separate from that
   of the public telephone numbers and both are independently
   expandable, while private network IP address is a specific subset
   reserved from the overall IPv4 pool that is otherwise all public and
   finite. However, the fact that neither of the latter two is allowed
   to operate in the other's domain suggests that the proposed EzIP
   numbering plan indeed may mirror the telephony practice.

   The key EzIP concept is the partitioning of a finite public address
   pool to put aside a block of special (called "Semi-Public" in the
   presentation below) addresses that extend each remaining public
   address to multitudes of sub-addresses, resulting in an effectively
   much larger address resource.



Chen, et al.          Expires December 10, 2018                [Page 5]


Internet-Draft       Adaptive IPv4 Address Space              June 2018


   In fact, the initial EzIP study identified the untold two-stage
   subnetting process of 192.168/16 that has been practiced routinely
   for a long time. End-users are commonly accustomed to an RG choosing
   one out of 256 values from the fourth octet of the 192.18.K/24 block
   for identifying an IoT on a private premises. They mostly are,
   however, unaware of the preceeding stage of selecting the value "K"
   from the third octet of the 192.18/16 block, as the factory default
   RG identification assigned by a manufacturer, is implicitly capable
   of expanding a public IPv4 address by 256 fold for supporting the
   corresponding number of private premises.

   The elusive IPv4 240/4 block (240/8 - 255/8), been "RESERVED" for
   "Future use" since 1981-09 as the result of the historical address
   assignment evolution, was proposed to be redesignated for "Private
   Use" near a decade ago [2]. However, as pointed out by its own
   authors in Section 2. Caveats of Use, "Many implementations of the
   TCP/IP protocol stack have the 240.0.0.0/4 address block marked as
   experimental, and prevent the host from forwarding IP packets with
   addresses drawn from this address block." That proposal did not get
   advanced.

   Substituting the function of the third octet of 192.168.K/24 with
   addresses from the 240/4 block in the first stage RG and redefining
   it as a new category of router, called SPR, the EzIP scheme
   circumvents the earlier hurdles to achieve the address multiplication
   factor of 256M without involving any existing router.

   Since the 240/4 block could not be used by existing routers, the size
   of the assignable IPv4 public pool has actually been only 3.84B
   (4.096B - 256M). So, the overall addressable pool created from this
   EzIP approach is about 983MB (3.84B x 256M), which is over 19M times
   of the expected Year 2020 IoTs. This configuration certainly has the
   capacity to support the short- to mid- term public IP address needs.

       2.2. EzIP System Architecture

   The new category of router, SPR is to be positoned inline between an
   ER and the customer premises that it serves. After the original path
   is re-established, the remaining addresses in the 240/4 block will be
   used by the SPR to serve additional prmises. Figure 1 shows a general
   view of the enhanced Internet system architecture with two SPRs, SPR1
   and SPR4, deployed. Note that the "69.41.190.x" are static addresses.
   In particular, the "69.41.190.145" is the permanent public Internet
   address assigned to Avinta.com.





Chen, et al.          Expires December 10, 2018                [Page 6]


Internet-Draft       Adaptive IPv4 Address Space              June 2018


                                       +------+
                        Web Server     | WS0z |
                                       +--+---+
                                          |69.41.190.145
                                          |
                                          |  +-----+
                                          +--+ ER0 |
                                             +--+--+
                                                |
                                         +------+-------+
                                 +-------+ Core Routers +--------+
                                 |       |  (Internet)  |        |
                              +--+--+    +--------------+     +--+--+
                        +-----+ ER1 |                   +-----+ ER4 |
                        |     +-----+                   |     +-----+
                        |                               |
                        |69.41.190.110                  |69.41.190.148
          240.0.0.0  +--+--+                         +--+--+
         +-----------+     +-------+       +---------+     +------+
         |     +-----+ SPR1|       |       |   +-----+ SPR4+--+   |
         |     |     +-----+       |       |...|     +-----+  |...|
         | 240.0.0.1   ... 255.255.255.255 |   |    +---------+   |
         +-----+                           |   |    |             |
               |                     240.0.0.0 |    |    255.255.255.255
               |Premises 1          +----------+    |
            +--+--+                 |   Premises 4  |
        +---+ RG1 +--+              |               |
        |   +-----+  |              |               |
        |            |              |               |
        |192.168.1.3 |192.168.1.9   |240.0.0.10     |246.1.6.40
     +--+--+      +--+--+        +--+--+         +--+--+
     | T1a | .... | T1z |        | T4a | ....... | T4z |
     +-----+      +-----+        +-----+         +-----+


                    Figure 1  EzIP System Architecture

   2.2.1.   Referring to the lefthand portion labeled "Premises 1" of
   Figure 1, instead of assigning each premises a public IPv4 address as
   in the current practice, an SPR like SPR1, is inserted between an
   Internet Edge Router (ER1) and its connections to private network
   Routing Gateways like RG1, for utilizing 240.0.0.0 through
   255.255.255.255 of the 240/4 block to identify respective premises.
   The RG1, serving either a business LAN (Local Area Network) or a
   residential HAN (Home Area Network), uses addresses from one of the
   three private network blocks, 10/8, 172.16/12 and 192.168/16, such as



Chen, et al.          Expires December 10, 2018                [Page 7]


Internet-Draft       Adaptive IPv4 Address Space              June 2018


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

   2.2.2.   Part of the righthand portion of Figure 1 is labeled
   "Premises 4". Here SPR4 assigns addresses 240.0.0.10 and 246.1.6.40
   from the 240/4 block to T4a and T4z, respectively. Consequently,
   these IoTs are directly accessible through SPR4 from any other IoT on
   the Internet.

   2.2.3.   Since the existing physical connections to subscriber's
   premises appear at the ER, it would be natural to have SPRs
   collocated with their ER for streamlining the interconnections. It
   follows that the simple routing function provided by the new SPR
   modules may be absorbed into the ER through a straightforward
   operational firmware enhancement. Consequently, the public / private
   demarcation line will remain at the RG where currently all utility
   services enter a subscriber's premises.

   2.2.4.   To fully tag each of these devices, we may use a
   concatenated three-part address, "Public - Semi-Public: TCP Port"
   notation. The following is how each of the IoTs in Figure 1 may be
   uniquely identified in the Internet.

            RG1: 69.41.190.110-240.0.0.0

            T1a: 69.41.190.110-240.0.0.0:3

            T1z: 69.41.190.110-240.0.0.0:9

            T4a: 69.41.190.148-240.0.0.10

            T4z: 69.41.190.148-246.1.6.40

   Note that to simplify the presentation, it is assumed at this
   juncture that the conventional TCP (Transmission Control Protocol)
   [RFC793] [8] Port Number, normally assigned to T1a and T1z by RG1's
   NAT module upon initiating a session, equals to the fourth octet of
   that IoT's private IP address that is assigned by the RG1's DHCP
   (Dynamic Host Configuration Protocol) [RFC2123] [9] subsystem as ":3"
   and ":9", respectively. Such numbers are unique within each
   respective /24 private network such as the 192.18.1/24 here. They are
   adequate for the discussion purpose in this document. However,
   considering security, as well as allowing each IoT to have multiple
   simultaneous sessions, etc., this direct and singular correlation
   shall be avoided in actual practice by following the NAT operation
   conventions as depicted by the examples in Appendix A.



Chen, et al.          Expires December 10, 2018                [Page 8]


Internet-Draft       Adaptive IPv4 Address Space              June 2018


  Figure 2 groups IoTs, routers and servers into two separate columns,
  EzIP-unaware or EzIP-capable, to facilitate discussions that are to
  follow.

     +--------------------------+-----------------+----------------+
     |                          |   EzIP-unaware  |  EzIP-capable  |
     +--------------------------+-----------------+----------------+
     | Internet Core Router (CR)|       CR        |  ------------  |
     +--------------------------+-----------------+----------------+
     | Internet Edge Router (ER)|  ER0, ER1, ER4  |  ------------  |
     +--------------------------+-----------------+----------------+
     | Internet of Things (IoT) |    T1a, T4a     |    T1z, T4z    |
     +--------------------------+-----------------+----------------+
     | Routing Gateway (RG)     |       RG1       |  ------------  |
     +--------------------------+-----------------+----------------+
     | Semi-Public Router (SPR) |  -------------  |   SPR1, SPR4   |
     +--------------------------+-----------------+----------------+
     | Web Server (WS)          |  -------------  |      WS0z      |
     +--------------------------+-----------------+----------------+

                     Figure 2  EzIP System Components

       2.3. IP Header with Option Word

   To transport the EzIP Extension Addresses, we will make use of the
   Option mechanism in the IP header as defined in Figure 9 of [RFC791].
   One specific aspect of its format deserves some attention. The
   meanings of the leading eight bits of each Option word, called "Opt.
   Code" or "Option-type octet", are defined on Page 15 of [RFC791].
   They are somewhat confusing because the multiple names used in the
   literature, and how the octet is parsed into functional bit groups.
   For example, a two digit hexadecimal number, "0x9A", is conventionaly
   written in the binary bit string form as "1001 1010". As an "Opt.
   Code" in [RFC791], however, the eight bits are parsed into three
   groups of 1, 2 and 5 bits. Their meanings are summarized in Figure 3.

      +--------------------------------------------------------------+
      |           Meaning of EzIP ID = 0x9A (Example)                |
      +--------------+------------------+----------------------------+
      |       1      |        00        |            11010           |
      +--------------+------------------+----------------------------+
      | Copy Bit Set | Class is Control |Option Value is 26 (base 10)|
      +--------------+------------------+----------------------------+


                        Figure 3  Option Type Octet



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


Internet-Draft       Adaptive IPv4 Address Space              June 2018


   A value of "1" for the first bit instructs all routers that this
   Option word is to be copied upon packet fragmentation. This preserves
   the Option word through such a process, if it is performed.

   The value of "00" for the next two bits indicates that this Option
   word is for "Control" purpose.

   The decimal "Option Value" of the last five bits, equaling to "26" is
   defined as the "Option Number" that is listed in the  "Number" column
   of the Internet Protocol Version 4 (IPv4) Parameters list [10]. As
   can be seen there, "26" has not been assigned. Thus, it is
   temporarily used in this document to facilitate the EzIP
   presentation. The next unassigned Option Code, "0x9B" or Number "27"
   will also be tentatively utilized in this document.

       2.4. Examples of Option Mechanism

   The Option mechanism has been used for various cases. Since they were
   mostly for utility or experimental purposes, however, their formats
   may be remote from the incident topic. There were two cases
   specifically dealt with the address pool issues. They are referenced
   here to assist the appreciation of the Option mechanism.

      A. EIP (Extended Internet Protocol) - Figure 1 of [RFC1385] [11]
   (Assigned but now deprecated Option Number = 17) by Z. Wang: This
   approach proposed to add a new network layer on top of the existing
   Internet for increasing the addressable space. Although equipment
   near the end-user would stay unchanged, equipment among the CRs
   apparently had to go through rather extensive upgrading procedures,
   perhaps due to the flexible length of the extended address (could be
   much longer than that of the IPv6).

      B. EnIP (Enhanced IPv4) - Figure 1 of Internet Draft [12]
   (temporarily utilizing Option Number = 26) by W. Chimiak: This work
   makes use of the three existing private network blocks to extend the
   public pool by trading the private network operation for end-to-end
   connectivity. The fully deployed EnIP will eliminate the current
   private networks which may be against the preference of end-users who
   have found the private network configuration quite desirable. For
   example, the NAT in an RG serves as a basic firewall against
   intrusion.

       2.5. EzIP Header

   The header format shown in Figure 4 can transport the full 4 octet
   (32 bit) extension addresses of both ends of an Internet link. The
   extension address in the 240/4 block utilized in the EzIP scheme


Chen, et al.          Expires December 10, 2018               [Page 10]


Internet-Draft       Adaptive IPv4 Address Space              June 2018


   described herein has 28 significant bits. It is possible for EzIP to
   use addresses having other lengths of significant bits for different
   multiplication factors. To prepare for such variations, two EzIP ID
   codes, "0x9A" and "0x9B" are proposed to distinguish between Source
   and Destination Option words.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     1 |Version|IHL (8)|Type of Service|      Total Length (32)        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     2 |        Identification         |Flags|     Fragment Offset     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     3 | Time to Live  |    Protocol   |        Header Checksum        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     4 |                      Source Host Number                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     5 |                    Destination Host Number                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    EzIP ID    |     EzIP      |   Extended    |   Extended    |
     6 |   (Source)    | Option Length |    Source     |    Source     |
       |    (0X9A)     |      (6)      |     No.-1     |     No.-2     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Extended    |   Extended    |    EzIP ID    |     EzIP      |
     7 |    Source     |    Source     | (Destination) | Option Length |
       |     No.-3     |     No.-4     |     (0X9B)    |      (6)      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Extended    |   Extended    |   Extended    |   Extended    |
     8 |  Destination  |  Destination  |  Destination  |  Destination  |
       |     No.-1     |     No.-2     |     No.-3     |     No.-4     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 4  Full EzIP Header (Four octet)



       2.6. EzIP Operation

   To convey the general scheme, Appendix A presents examples of IP
   header transitions through routers, between IoTs with or without EzIP
   capability.

   To introduce the EzIP approach into an environment where EzIP-unaware
   IoTs like T1a and T4a will be numerous for a long time to come, an
   SPR must be able to follow certain decision rules to determine how to
   provide the appropriate routing service for a smooth transition to



Chen, et al.          Expires December 10, 2018               [Page 11]


Internet-Draft       Adaptive IPv4 Address Space              June 2018


   the long term operation. Appendix B outlines such logic and related
   considerations.



   3. EzIP Deployment Strategy

   Although the eventual goal of the SPR is to support both web server
   access by IoTs from behind private networks and direct end-to-end
   connectivity between IoTs, the former should be dealt with first to
   immediately mitigate the address shortage induced issues. In the
   process, the long term capability for the latter would be enabled
   naturally.

   A. Architecturally

   Since the design philosophy of the SPR is an inline module between an
   Internet ER (Edge Router) and the private network RG (Routing
   Gateway) or a directly connected IoT it serves, SPR introduction
   process can be flexible.

      A.1.  A SPR may be deployed as an inline module right after an ER
   to begin providing the CGN equivalent function. This could be done
   immediately without affecting any of the existing Internet
   components, CR, ER and RG. EzIP-capable IoTs will then take advantage
   of the faster bi-directional routing service through the SPRs by
   initiating communication sessions utilizing EzIP headers to contact
   other EzIP-capable IoTs.

      A.2.  Alternatively, a SPR may be deployed as an adjunct module
   just before an existing RG or a directly connected IoT to realize the
   same EzIP functions on the private premises, even if the serving
   Internet Access Provider (IAP) has not enhanced ERs with the EzIP
   capability.

      This approach could empower individual communities to enjoy the
   new EzIP capability on their own by upgrading all Internet
   subscribers within a good sized area to have publicly accessible EzIP
   addresses for intra-community peer-to-peer communication, based on
   just one (or more) existing public IPv4 address(es) for identifying
   the gateway(s) to the rest of the world. See sub-section C. below for
   more specific considerations.

   B. Functionally

      B.1.  First, an IAP should install SPRs in front of business web
   servers so that new routing branches may be added to support the


Chen, et al.          Expires December 10, 2018               [Page 12]


Internet-Draft       Adaptive IPv4 Address Space              June 2018


   additional web servers for expanding business activities.
   Alternatively, this may be achieved if businesses on their own deploy
   new web servers with the SPR capability built-in.

      B.2.  On the subscriber side, SPRs should be deployed to
   disseminate static addresses to the public, and to facilitate the
   access to new web servers.

   C. Regional Deployment

      C.1.  Since the size of the 240/4 block is significant, a
   community mentioned in sub-section A.2. above could actually be
   fairly large. Based on the assumption that each person, on the
   average, may have 6.6 IoTs by Year 2020 Error! Reference source not
   found., each 240/4 block is capable of serving nearly 39M (256M /
   6.6) people. This exceeds the population of the largest city on earth
   (33M - Tokyo Metro.). Therefore, any finite sized region can
   immediately begin to enjoy EzIP addressing by deploying a "sub-
   Internet" utilizing SPRs operating with one 240/4 block of addresses
   under one IPv4 public address. If the gateway for such a region is
   configured in a way that the entire region appears to be one ordinary
   IPv4 IoT to the rest of the Internet, a sub-Internet may be deployed
   anywhere there is the need or desire, with no perturbation to the
   current Internet operation whatsoever.

      C.2. This gateway may be constructed with a matured networking
   technology called Caching Proxy [13], popularized by data-intensive
   web services such as Google, Amazon, Yahoo, etc. Developed for
   speeding up response to repeated queries while minimizing Internet
   traffic for data exchanges with the central data bank, caching
   proxies are placed at strategic locations close to potential
   inquirers, essentially cloning the central data bank into mulitple
   distributed copies. This architecture meshs with the EzIP-based sub-
   Internet very well, because the address translation between the IPv4
   in the Internet and the EzIP in the sub-Internet can be accomplished
   transparently through the two ports of a caching proxy. Consequently,
   the existing Internet routers, CR and ER even may not see any IP
   packet with EzIP header at all, during the initial phase of EzIP
   deployment which will be primarily basic web server access.

      C.3.  This configuration actually mimicks the PABX environment
   almost exactly. Since the entire region is only accessible through
   the gateway that performs the address translation, words 4 and 5
   (Source and Destination Host Numbers, respectively) in the basic IP
   header for an intra sub-Internet packet could simply use the
   addresses in the 240/4 block for expediting the routing by the SPRs.
   This mirrors the dialing procedures using only extension numbers


Chen, et al.          Expires December 10, 2018               [Page 13]


Internet-Draft       Adaptive IPv4 Address Space              June 2018


   among stations served by the same PABX, circumventing the overhead of
   including the common public telephone number prefix that the PABX is
   identified by. The full EzIP header format will only be used when an
   EzIP-capable IoT intends to directly interact with another EzIP-
   capable IoT beyond the local sub-Internet. The last part is
   equivalent to the DID (Direct Inward Dialing) techniques that have
   been used in the PABX field for many years.

   D. Permanently

   In the long run, it would be best if SPRs are integrated into their
   host ER by upgrading the latter's firmware to minimize the hardware
   and to streamline the equipment interconnections.

   Appendix B details the considerations in implementing these outlines.



   4. Updating Servers to Support EzIP

   Although the IP header Option mechanism utilized by EzIP was defined
   a long time ago as part of the original IPv4 protocol, it has not
   been used much in daily traffic. Compatibility with current Internet
   facilities and conventions may need be reviewed. Since the EzIP data
   is transported as part of the IP header payload, it is not expected
   to affect higher layer protocols. However, certain facilities may
   have been optimized without considering the Option mechanism. They
   need be adjusted to provide the same performance to EzIP packets.
   There are also utility type of servers that need be updated to
   support the longer EzIP address. For example;

   A. Fast Path

   Internet Core Routers (CRs) are currently optimized to only provide
   the "fast-path" (through hardware line card) routing service to
   packets without Option word in the IP header [14]. This puts EzIP
   packets at a disadvantage position, because EzIP packets will have to
   go through the "slow path" (processed by CPU's software before giving
   to the correct hardware line card to forward), resulting in a slower
   throughput. Since the immediate goal of the EzIP is to ease the
   address pool exhaustion issue, subscribers not demanding for high
   throughput performance may be migrated to the EzIP supported facility
   first. This gives CRs time to update so that EzIP packets with
   authorized Option numbers will eventually be recognized for receiving
   the "fast-path" service.

   B. Connectivity Verification


Chen, et al.          Expires December 10, 2018               [Page 14]


Internet-Draft       Adaptive IPv4 Address Space              June 2018


   One frequently used utility for verifying baseline connectivity,
   commonly referred to as the "PING" function in PC terminology, needs
   be able to transport the full EzIP address that is 64 bits long
   instead of the current 32 bit IPv4 address. There is an example of an
   upgraded TCP echo server in [RFC862] [15].

   C. Domain Name Server (DNS)

   Similarly, the DNS needs to expand its data format to transport the
   longer IP address created by the EzIP. This already can be done under
   IPv6. Utilizing the experimental IPv6 prefix 2001:0101 defined by
   [RFC2928] [16], EzIP addresses may be transported as standardized
   AAAA records.

   These topics are discussed in more detail under an IETF Draft RFC,
   Enhanced IPv4 - V.03 [12].



   5. EzIP Enhancement and Application

   To avoid disturbing any assigned addresses, deployed equipment and
   current operation, etc., the EzIP scheme is derived under the
   constraint of utilizing only the reserved 240/4 address block. If
   such restriction were removed by allowing the entire IPv4 address
   pool be re-allocatable, the assignable public address pool could be
   expanded significantly more, as outlined below.

   A. If the 240/4 block were doubled to 224/3, each existing IPv4
   public address would be expanded by 512M fold. Since this block of
   512M addresses have to be first reserved from the basic public pool,
   the resultant total addresses will be (4.096B - 512M) x 512M, or
   1,835MB. This is over 36M times of the predicted number of IoTs (50B)
   by Year 2020. This calculation leads to additional possibilities.

   B. The EzIP header in Figure 4, capable of transporting the full 32
   bit IPv4 address, allows the extension number be as long as
   practical. That is, we can go to the extreme of reserving only one
   bit for the network number, and using all of the rest bits for the
   extension address. With this criterion, the current IPv4 pool may be
   divided into two halves, reserving one half of it (about 2B
   addresses) as a semi-public network with the network number prefix
   equal to "1". Each of the remaining 2B public addresses (with prefix
   equal to "0") of the basic IPv4 pool may then be extended 2B fold
   through the EzIP process, resulting in a 4BB address pool. This is
   roughly 80M times of the Year 2020 IoT needs.



Chen, et al.          Expires December 10, 2018               [Page 15]


Internet-Draft       Adaptive IPv4 Address Space              June 2018


   C. If the EzIP technique were applied through several layers of SPRs
   in succession, the address expansion could be even more. For example,
   let's divide the IPv4 pool equally into four blocks, each with about
   1B addresses. Apply the first 1B address block to the public routers.
   Set up three layers of SPRs, each makes use of one of the remaining
   three 1B addresses. The resultant assignable pool will have 1BBBB
   addresses. Under this configuration, the full length of an IoT's
   identification code will be the concatenation of four segments of 32
   bit IPv4 address, totalling 128 bits, the same as that of the IPv6.
   Since the first two bits of each segment, being used to distinguish
   from the other three address blocks, are not significant bits, this
   8-bits difference makes the IPv6 pool 256 times larger. However, this
   ratio is immaterial, because even the 1BBBB address pool is alreaby
   20MBB times of the foreseeable need. It is the hierarchical
   addressing characteristics, made possible by the EzIP scheme, that
   will enhance the Internet, such as truncating out the common address
   prefix within a local community, and associating an address with the
   geographical reference, thus mitigating the GeoLocation issues.

   D. Along this line of reasoning, we could combine two 1B address
   blocks togther to be the basic public address. The overall assignable
   pool becomes 2BBB which is still 40MB times of the expected IoT
   need(50B). With this pool, we can divide the entire globe into 2B
   regions, each served by one public router. Each region can then be
   divided into 1B sections, identified by the first group of SPRs.
   Next, each section will have the second group of SPRs to manage upto
   1B IoTs. Since the basic 2B public addresses are already more than
   half of the current total assignable IPv4 public addresses (3.84B),
   their potential GeoLocation resolution capabilities are comparable.
   With additional two layers of SPR routing, 1B for each, the address
   grid granuality will be so refined that locating the source of an IP
   packet becomes a finite task, leaving perpetrators little room to
   hide.

   E. The following outlines a possible procedure for optimizing the use
   of the EzIP address resource by transforming the current Internet to
   a GeoLocation-capable address system while maintaining the existing
   IPv4 addressing and operation conventions:

      a. Quantitative Reference: IETF [RFC6598] [17] reserved the
   100.64.0.0/10 block with 4M addresses for supporting IAP's CGN
   service. Applying all of these to the entire IPv4 pool of 4B
   addresses, the maximum effective CGN supported IPv4 address pool
   could be 16MB. This is 0.32M times of the expected number (50B) of
   IoTs by Year 2020.




Chen, et al.          Expires December 10, 2018               [Page 16]


Internet-Draft       Adaptive IPv4 Address Space              June 2018


      b. Employing the 240/4 block with 256M addresses in the EzIP
   extension scheme, a /6 block with 64M addresses from the IPv4 basic
   public pool is sufficient to replicate the above 16MB capacity. This
   frees up the majority of the IPv4 public pool.

      c. Since this will be a temporary holding pool to release the
   current addresses for new assignments, it should occupy as few public
   addresses as possible to leave the maximum number of addresses for
   facilitating the long term planning. To just support the expected 50B
   IoTs need, only 200 IPv4 public addresses are required (200 x 256M =
   50B). Thus, a /24 block with 256 addresses is more than enough to
   accommodate this entire migration process. This frees up even more
   IPv4 public addresses.

      d. Although a single /24 public address block is sufficient for
   migrating all currently perceived IPv4 address needs into one compact
   temporary EzIP pool, world-wide coordination of new address
   assignments and routing tables updates will be required. It will be
   more expeditious by carrying out this preparatory phase on individual
   country or geographical region basis utilizing public IPv4 addresses
   already assigned to that area and actively served by existing CR
   routing tables. Since 200 public addresses are enough to port the
   entire IoT addresses, most countries should be able to port all of
   their respective in-use IoTs to be under fewer than a couple of
   gateways for accessing the Internet. Under each gateway, one 240/4
   block will handle the IoT address assignments. If this is managed
   according to geographical locations, each participating region will
   begin to enjoy the benefits of the EzIP approach, such as plentifull
   assignable public addresses, robust security due to inherent
   GeoLocation ability to spot hackers from within. So that efforts may
   be focused only on screening suspicious packets originated from
   without.

      e. As IoTs getting migrated to the temporary pool, the IPv4
   addresses they originally occupy shall be released to re-populate the
   public address pool for establishing the full scale EzIP operation.

      f. Upon the completion of the EzIP based world-wide public address
   allocation map, each country can simply give up the few temporary
   public addresses in exchange for the permanent assignments. Since the
   latter is likely more than the former, addresses in one 240/4 block
   will be served by two (or more) 240/4 blocks. Or, each of such 240/4
   block will have more than half of its capacity available to serve
   additional IoTs.

      g. This last step is very much the same as the traditional PSTN
   "Area Code Split" practice, whereby telephone numbers of a service


Chen, et al.          Expires December 10, 2018               [Page 17]


Internet-Draft       Adaptive IPv4 Address Space              June 2018


   area are split into two (or more) blocks, upon introducing one (or
   more) new area code(s) into the area. All subscribers will continue
   to use their original telephone numbers, except some may be assigned
   with a new area code prefix. Each area code will have more than half
   of its assignable telephone numbers availabe to support the future
   subscriber growth within its service area. Mimicking the PSTN, the
   EzIP based Internet will have similar GeoLocation capability as the
   former's caller identification based services, such as the 911
   emergency caller location system in US, mitigating the root cause of
   the cybersecurity vulnerability.

   F. With the IPv4 address pool shortage issue resolved, potential
   applications making use of the EzIP enhanced address pool may be
   explored.

      a. Although the entire predicted number (50B) of IoTs by Year 2020
   may be served by just one /24 IPv4 public address block utilizing the
   EzIP scheme with a 240/4 block, let's replace it with a /8 block (16M
   addresses), resulting in about 4MB (16M x 256M) assignable addresses.
   Then, only 1 out of each 80K such addresses will be used by the 50B
   IoTs. Or, each and every person (at Year 2020 population level) would
   have to own over 500K IoTs to use up this address pool. It is
   apparent that the spares in this allocation should be sufficient to
   support the growth of the IoTs for some years to come.

      b. The IPv4 pool originally has 256 blocks of /8 addresses. After
   reserving 16 blocks of them (the 240/4 block) as the reusable EzIP
   extension address and one to complete the pool for the above IoT
   needs, there are still 239 blocks of /8 addresses available to
   support additional digital communication systems, each may have as
   many addresses as those allocated to the Internet. Consequently, many
   world-wide communication networks may coexist under the same IPv4
   protocol framework in the form of sub-Internets as described earlier,
   with arm's-length links among them.

      c. For example, a satellite based Internet that is being proposed
   [18], can start fresh with one EzIP sub-Internet served by one SPR
   having the capacity of 256M IoTs, under one ER capable of managing
   one /8 block of IPv4 public address. Utilizing caching proxy as the
   gateway to handle the data exchange with other systems, this
   satellite based Internet with 256M hosts will operate pretty much as
   an isolated system by using 240/4 addresses in the basic IP headers
   for intra-system communications, most of the time. Only when direct
   communication with another sub-Internet (such as the one for the
   current Internet) is needed, full EzIP header will be used. As users
   grow, additional sub-Internets (each with 256M IoTs capacity), may be
   incrementally added to support the expansion.


Chen, et al.          Expires December 10, 2018               [Page 18]


Internet-Draft       Adaptive IPv4 Address Space              June 2018


   G. In summary, utilizing the 240/4 address block, the EzIP scheme may
   expand the IPv4 based Internet to be a collection of up to 240 groups
   of 16M sub-Internets each managed by one SPR that are inter-operable
   digital communication systems, normally operate at arm's-lenghth to
   one another. Each of these groups will have the address capacity of
   at least 80K times of the number of predicted (50B) IoTs by Year
   2020.



   6. Security Considerations

   The EzIP solution is based on an inline module called SPR that
   intends to be as transparent to the Internet traffic as possible.
   Thus, no overall system security degradation is expected.



   7. IANA Considerations

   This draft does not create a new registry nor does it register any
   values in existing registries; no IANA action is required.



   8. Conclusions

   To resolve the IPv4 public address pool exhaustion issue, a technique
   called EzIP (phonetic for Easy IPv4) making use of a long reserved
   address block 240/4 is proposed.

   This draft RFC describes an enhancement to IPv4 operation utilizing
   the IP header Option mechanism defined in RFC791. Because the design
   criterion is to enhance IPv4 by extending instead of altering it, the
   impact on already in-place routers and security mechanisms is
   minimized.

   The basic EzIP intention is to maintain the existing private network
   configuration. Upon reclassifying the "RESERVED for Future use" 240/4
   block to be the Semi-Public address pool, it will only be usable by
   the new SPR (Semi-Public Router) as the EzIP extension address. This
   pool can multiply each current IPv4 public address by 256M times,
   while all existing public network and subscriber premises setups
   (private networks as well as directly connected IoTs) will remain
   unchanged. This particular manifestation of the EzIP scheme appears
   to be the optimal solution to our needs.



Chen, et al.          Expires December 10, 2018               [Page 19]


Internet-Draft       Adaptive IPv4 Address Space              June 2018


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



   9. References

   9.1. Normative References

   [1]   https://tools.ietf.org/html/rfc791

   [2]   https://tools.ietf.org/html/draft-wilson-class-e-02



   9.2.  Informative References

   [3]   https://www.cisco.com/c/dam/en_us/about/ac79/docs/innov/IoT_IBS
         G_0411FINAL.pdf

   [4]   http://stats.labs.apnic.net/ipv6

   [5]   https://ams-ix.net/technical/statistics/sflow-stats/ether-type

   [6]   https://tools.ietf.org/html/rfc6264

   [7]   http://www.iana.org/assignments/ipv4-address-space/ipv4-
         address-space.xhtml

   [8]   https://tools.ietf.org/html/rfc793

   [9]   https://www.ietf.org/rfc/rfc2131.txt

   [10]  http://www.iana.org/assignments/ip-parameters/ip-
         parameters.xhtml

   [11]  https://tools.ietf.org/html/rfc1385

   [12]  https://tools.ietf.org/html/draft-chimiak-enhanced-ipv4-03

   [13]  https://en.wikipedia.org/wiki/Proxy_server#Improving_performanc
         e


Chen, et al.          Expires December 10, 2018               [Page 20]


Internet-Draft       Adaptive IPv4 Address Space              June 2018


   [14]  http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.477.19
         42&rep=rep1&type=pdf

   [15]  https://tools.ietf.org/html/rfc862

   [16]  https://tools.ietf.org/html/rfc2928

   [17]  https://tools.ietf.org/html/rfc6598

   [18]  https://www.commerce.senate.gov/public/index.cfm/2017/10/the-
         commercial-satellite-industry-what-s-up-and-what-s-on-the-
         horizon




   10. Acknowledgments

   The authors would express their deep appreciation to Dr. W. Chimiak
   for the enlightening discussions about his team's efforts and
   experiences through the EnIP development.

   This document was prepared using 2-Word-v2.0.template.dot.


























Chen, et al.          Expires December 10, 2018               [Page 21]


Internet-Draft       Adaptive IPv4 Address Space              June 2018


Appendix A  EzIP Operation

   To demonstrate how EzIP could support and enhance the Internet
   operations, the following are three sets of examples that involve
   SPRs as shown in Figure 1. These present a general perspective of how
   IP header transitions through the routers may look like.

   1. The first example is between EzIP-unaware IoTs, T1a and T4a. This
   operation is very much like the conventional TCP/IP packet
   transmission except with SPRs acting as an extra pair of routers
   providing the CGN service.

   2. The second one is between EzIP-capable IoTs, T1z and T4z. Here,
   the SPRs process the extended semi-public IP addresses in router
   mode, avoiding the delays due to the NAT type of operations above.

   3. The last one is between EzIP-unaware and EzIP-capable IoTs. By
   initiating and responding with a conventional IP header, T1z and T4z
   behave like an EzIP-unaware IoT. Thus, all packet exchanges use the
   conventional IP headers, just like case 1. above.

A.1. Connection between EzIP-unaware IoTs

A.1.1. T1a Initiates a Session Request towards T4a

   In Figure 5, T1a initiates a session request to SPR4 that serves T4a
   by sending an IP packet to RG1. There is no TCP port number in this
   IP header yet.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     1 |Version|IHL (5)|Type of Service|       Total Length (20)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     2 |        Identification         |Flags|     Fragment Offset     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     3 | Time to Live  |    Protocol   |        Header Checksum        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     4 |              Source Host Number (192.168.1.3)                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     5 |           Destination Host Number (69.41.190.148)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 5  IP Header: From T1a to RG1





Chen, et al.          Expires December 10, 2018               [Page 22]


Internet-Draft       Adaptive IPv4 Address Space              June 2018


A.1.2. RG1 Forwards the Packet to SPR1

     In Figure 6, RG1, allowing be masqueraded by T1a, relays the packet
   toward SPR1 by assigning the TCP Source port number, 3N, to T1a. Note
   that the suffix "N" denotes the actual TCP port number assigned by
   the RG1's NAT. This could assume multiple values, each represents a
   separate communications session that T1a is engaged in. A
   corresponding entry is created in the state table for handling the
   responding reply packet from the Destination site. Since T4a's TCP
   port number is not known yet, it is filled with all 1's.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     1 |Version|IHL (5)|Type of Service|       Total Length (24)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     2 |        Identification         |Flags|     Fragment Offset     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     3 | Time to Live  |    Protocol   |        Header Checksum        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     4 |              Source Host Number (240.0.0.0)                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     5 |           Destination Host Number (69.41.190.148)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     6 |       Source Port (3N)        |   Destination Port (All 1's)  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 6  TCP/IP Header: From RG1 to SPR1





















Chen, et al.          Expires December 10, 2018               [Page 23]


Internet-Draft       Adaptive IPv4 Address Space              June 2018




A.1.3. SPR1 Sends the Packet to SPR4 through the Internet

   In Figure 7, SPR1 allowing masqueraded by RG1 (with the Source Host
   Number changed to be its own and the TCP port number changed to 0C,
   where "C" stands for CGN) sends the packet out through the Internet
   towards SPR4. The packet traverses through the Internet (ER1, CR and
   ER4) utilizing only the basic IP header portion of address
   information (words 4 & 5).

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     1 |Version|IHL (5)|Type of Service|       Total Length (24)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     2 |        Identification         |Flags|     Fragment Offset     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     3 | Time to Live  |    Protocol   |        Header Checksum        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     4 |             Source Host Number (69.41.190.110)                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     5 |           Destination Host Number (69.41.190.148)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     6 |       Source Port (0C)        |   Destination Port (All 1's)  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 7  TCP/IP Header: From SPR1 to SPR4





















Chen, et al.          Expires December 10, 2018               [Page 24]


Internet-Draft       Adaptive IPv4 Address Space              June 2018




A.1.4. SPR4 Sends the Packet to T4a

   Since the packet has a conventional IP header without Destination TCP
   port number, SPR4 would ordinarily drop it due to the CGN function.
   However, for this example, let's assume that there exists a state-
   table that was set up by a DMZ (De-Militaried Zone) process for
   redirecting this packet to T4a with a CGN TCP port number 10C (the
   fourth octet, "10" of T4a's Extension address). In Figure 8, SPR4
   sends the packet to T4a by constructing the destination address
   accordingly.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     1 |Version|IHL (5)|Type of Service|       Total Length (24)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     2 |        Identification         |Flags|     Fragment Offset     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     3 | Time to Live  |    Protocol   |        Header Checksum        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     4 |             Source Host Number (69.41.190.110)                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     5 |           Destination Host Number (240.0.0.10)                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     6 |       Source Port (0C)        |      Destination Port (10C)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 8  TCP/IP Header: From SPR4 to T4a



















Chen, et al.          Expires December 10, 2018               [Page 25]


Internet-Draft       Adaptive IPv4 Address Space              June 2018




A.1.5. T4a Replies to SPR4

   In Figure 9, when T4a replies to SPR4, it interchanges the Source and
   Destination identifications to create an IP header for the reply
   packet.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     1 |Version|IHL (5)|Type of Service|       Total Length (24)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     2 |        Identification         |Flags|     Fragment Offset     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     3 | Time to Live  |    Protocol   |        Header Checksum        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     4 |              Source Host Number (240.0.0.10)                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     5 |           Destination Host Number (69.41.190.110)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     6 |      Source Port (10C)        |     Destination Port (0C)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 9  TCP/IP Header: From T4a to SPR4
























Chen, et al.          Expires December 10, 2018               [Page 26]


Internet-Draft       Adaptive IPv4 Address Space              June 2018




A.1.6. SPR4 Sends the Packet to SPR1 through the Internet

   In Figure 10, SPR4 sends the packet toward SPR1 with the following
   header through the Internet (ER4, CR and ER1) who will simply relay
   the packet according to the information in word 5 (Destination Host
   Number):

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     1 |Version|IHL (5)|Type of Service|       Total Length (24)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     2 |        Identification         |Flags|     Fragment Offset     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     3 | Time to Live  |    Protocol   |        Header Checksum        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     4 |              Source Host Number (69.41.190.148)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     5 |           Destination Host Number (69.41.190.110)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     6 |      Source Port (10C)        |     Destination Port (0C)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 10 TCP/IP Header: From SPR4 to SPR1























Chen, et al.          Expires December 10, 2018               [Page 27]


Internet-Draft       Adaptive IPv4 Address Space              June 2018




A.1.7. SPR1 Sends the Packet to RG1

   In Figure 11, RG1 address is reconstructed by using the information
   in the CGN state-table stored in SPR1.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     1 |Version|IHL (5)|Type of Service|       Total Length (24)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     2 |        Identification         |Flags|     Fragment Offset     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     3 | Time to Live  |    Protocol   |        Header Checksum        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     4 |              Source Host Number (69.41.190.148)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     5 |            Destination Host Number (240.0.0.0)                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     6 |       Source Port (10C)       |     Destination Port (3N)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 11 TCP/IP Header: From SPR1 to RG1

























Chen, et al.          Expires December 10, 2018               [Page 28]


Internet-Draft       Adaptive IPv4 Address Space              June 2018




A.1.8. RG1 Forwards the Packet to T1a

   In Figure 12, T1a address is reconstructed from the state-table in
   RG1's NAT based on Destination Port (3N).

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     1 |Version|IHL (5)|Type of Service|       Total Length (24)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     2 |        Identification         |Flags|     Fragment Offset     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     3 | Time to Live  |    Protocol   |        Header Checksum        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     4 |              Source Host Number (69.41.190.148)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     5 |            Destination Host Number (192.168.1.3)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     6 |      Source Port (10C)        |     Destination Port (3N)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 12 TCP/IP Header: From RG1 to T1a

A.1.9. T1a Sends a Follow-up Packet to RG1

   To carry on the communication, T1a in Figure 13 sends the follow-up
   packet to RG1 with a full TCP/IP header.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     1 |Version|IHL (5)|Type of Service|       Total Length (24)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     2 |        Identification         |Flags|     Fragment Offset     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     3 | Time to Live  |    Protocol   |        Header Checksum        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     4 |                Source Host Number (192.168.1.3)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     5 |            Destination Host Number (69.41.190.148)            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     6 |       Source Port (3N)        |    Destination Port (10C)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 13 TCP/IP Header: Follow-up Packets From T1a to RG1


Chen, et al.          Expires December 10, 2018               [Page 29]


Internet-Draft       Adaptive IPv4 Address Space              June 2018


A.2. Connection Between EzIP-capable IoTs

   The following is an example of EzIP operation between T1z and T4z
   shown in Figure 1. Each knows its own full "Public - EzIP : Private"
   network addresses, "69.41.190.110-240.0.0.0:9" and "69.41.190.148-
   246.1.6.40", respectively, as well as the other's. Note that T4z is
   directly addressable from the Internet. It does not have the private
   portion (TCP port number) in the concatenated address.

A.2.1. T1z Initiates a Session Request towards T4z

   In Figure 14, T1z sends an EzIP packet to RG1. There is no TCP port
   number word, because T4z does not have such and that for T1z has not
   been assigned by the RG1's NAT.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     1 |Version|IHL (8)|Type of Service|       Total Length (32)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     2 |        Identification         |Flags|     Fragment Offset     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     3 | Time to Live  |    Protocol   |        Header Checksum        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     4 |              Source Host Number (192.168.1.9)                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     5 |           Destination Host Number (69.41.190.148)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    EzIP ID    |     EzIP      |   Extended    |   Extended    |
     6 |   (Source)    | Option Length |    Source     |    Source     |
       |    (0X9A)     |      (6)      |  No.-1 (240)  |   No.-2 (0)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Extended    |   Extended    |    EzIP ID    |     EzIP      |
     7 |    Source     |    Source     | (Destination) | Option Length |
       |   No.-3 (0)   |   No.-4 (0)   |     (0X9B)    |      (6)      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Extended    |   Extended    |   Extended    |   Extended    |
     8 |  Destination  |  Destination  |  Destination  |  Destination  |
       |  No.-1 (246)  |   No.-2 (1)   |   No.-3 (6)   |  No.-4 (40)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 14 EzIP Header: From T1z to RG1

   Note that 0X9A and 0X9B are temporarily selected from the available
   "IP Option Numbers" [10].




Chen, et al.          Expires December 10, 2018               [Page 30]


Internet-Draft       Adaptive IPv4 Address Space              June 2018


A.2.2. RG1 Forwards the Packet to SPR1

     In Figure 15, RG1, allowing to be masqueraded by T1z, relays the
   packet toward SPR1 by assigning the TCP Source port number, 9N, to
   T1z. Since T4z is directly connected to the Internet, there is no
   private network information to fill the Destination portion of the
   TCP word.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     1 |Version|IHL (8)|Type of Service|       Total Length (36)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     2 |        Identification         |Flags|     Fragment Offset     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     3 | Time to Live  |    Protocol   |        Header Checksum        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     4 |              Source Host Number (240.0.0.0)                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     5 |           Destination Host Number (69.41.190.148)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    EzIP ID    |     EzIP      |   Extended    |   Extended    |
     6 |   (Source)    | Option Length |    Source     |    Source     |
       |    (0X9A)     |      (6)      |  No.-1 (240)  |   No.-2 (0)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Extended    |   Extended    |    EzIP ID    |     EzIP      |
     7 |    Source     |    Source     | (Destination) | Option Length |
       |   No.-3 (0)   |   No.-4 (0)   |     (0X9B)    |      (6)      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Extended    |   Extended    |   Extended    |   Extended    |
     8 |  Destination  |  Destination  |  Destination  |  Destination  |
       |  No.-1 (246)  |   No.-2 (1)   |   No.-3 (6)   |  No.-4 (40)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     9 |       Source Port (9N)        |   Destination Port (All 1's)  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 15 TCP/EzIP Header: From RG1 to SPR1












Chen, et al.          Expires December 10, 2018               [Page 31]


Internet-Draft       Adaptive IPv4 Address Space              June 2018




A.2.3. SPR1 Sends the Packet to SPR4 through the Internet

   In Figure 166, SPR1 sends the packet out into the Internet towards
   SPR4. The packet traverses through the Internet (ER1, CR and ER4),
   utilizing only the basic IP header portion of address information.



        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     1 |Version|IHL (8)|Type of Service|       Total Length (36)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     2 |        Identification         |Flags|     Fragment Offset     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     3 | Time to Live  |    Protocol   |        Header Checksum        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     4 |             Source Host Number (69.41.190.110)                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     5 |           Destination Host Number (69.41.190.148)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    EzIP ID    |     EzIP      |   Extended    |   Extended    |
     6 |   (Source)    | Option Length |    Source     |    Source     |
       |    (0X9A)     |      (6)      |  No.-1 (240)  |   No.-2 (0)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Extended    |   Extended    |    EzIP ID    |     EzIP      |
     7 |    Source     |    Source     | (Destination) | Option Length |
       |   No.-3 (0)   |   No.-4 (0)   |     (0X9B)    |      (6)      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Extended    |   Extended    |   Extended    |   Extended    |
     8 |  Destination  |  Destination  |  Destination  |  Destination  |
       |  No.-1 (246)  |   No.-2 (1)   |   No.-3 (6)   |  No.-4 (40)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     9 |       Source Port (9N)        |   Destination Port (All 1's)  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




               Figure 16 TCP/EzIP Header: From SPR1 to SPR4







Chen, et al.          Expires December 10, 2018               [Page 32]


Internet-Draft       Adaptive IPv4 Address Space              June 2018




A.2.4. SPR4 Sends the Packet to T4z

   In Figure 17, SPR4 sends the packet to T4z by reconstructing its
   address from the Option number and the Extended Destination No.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     1 |Version|IHL (8)|Type of Service|       Total Length (36)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     2 |        Identification         |Flags|     Fragment Offset     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     3 | Time to Live  |    Protocol   |        Header Checksum        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     4 |             Source Host Number (69.41.190.110)                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     5 |           Destination Host Number (246.1.6.40)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    EzIP ID    |     EzIP      |   Extended    |   Extended    |
     6 |   (Source)    | Option Length |    Source     |    Source     |
       |    (0X9A)     |      (6)      |  No.-1 (240)  |   No.-2 (0)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Extended    |   Extended    |    EzIP ID    |     EzIP      |
     7 |    Source     |    Source     | (Destination) | Option Length |
       |   No.-3 (0)   |   No.-4 (0)   |     (0X9B)    |      (6)      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Extended    |   Extended    |   Extended    |   Extended    |
     8 |  Destination  |  Destination  |  Destination  |  Destination  |
       |  No.-1 (246)  |   No.-2 (1)   |   No.-3 (6)   |  No.-4 (40)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     9 |       Source Port (9N)        |   Destination Port (All 1's)  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                Figure 17 TCP/EzIP Header: From SPR4 to T4z












Chen, et al.          Expires December 10, 2018               [Page 33]


Internet-Draft       Adaptive IPv4 Address Space              June 2018




A.2.5. T4z Replies to SPR4

   In Figure 18, T4z replies to SPR4 with the full T1z identification
   69.41.190.110-240.0.0.0:9N to create an EzIP header for the reply
   packet.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     1 |Version|IHL (8)|Type of Service|       Total Length (36)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     2 |        Identification         |Flags|     Fragment Offset     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     3 | Time to Live  |    Protocol   |        Header Checksum        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     4 |              Source Host Number (246.1.6.40)                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     5 |           Destination Host Number (69.41.190.110)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    EzIP ID    |     EzIP      |   Extended    |   Extended    |
     6 |   (Source)    | Option Length |    Source     |    Source     |
       |    (0X9A)     |      (6)      |  No.-1 (246)  |   No.-2 (1)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Extended    |   Extended    |    EzIP ID    |     EzIP      |
     7 |    Source     |    Source     | (Destination) | Option Length |
       |   No.-3 (6)   |   No.-4 (40)  |     (0X9B)    |      (6)      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Extended    |   Extended    |   Extended    |   Extended    |
     8 |  Destination  |  Destination  |  Destination  |  Destination  |
       |  No.-1 (240)  |   No.-2 (0)   |   No.-3 (0)   |   No.-4 (0)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     9 |     Source Port (All 1's)     |     Destination Port (9N)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





                Figure 18 TCP/EzIP Header: From T4z to SPR4








Chen, et al.          Expires December 10, 2018               [Page 34]


Internet-Draft       Adaptive IPv4 Address Space              June 2018




A.2.6. SPR4 Sends the Packet to SPR1 through the Internet

   In Figure 19, SPR4 sends the packet toward SPR1 with the following
   header through the Internet (ER2, CR, and ER1) who will simply relay
   the packet according to the information in word 5 (Destination Host
   Number):

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     1 |Version|IHL (8)|Type of Service|       Total Length (36)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     2 |        Identification         |Flags|     Fragment Offset     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     3 | Time to Live  |    Protocol   |        Header Checksum        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     4 |              Source Host Number (69.41.190.148)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     5 |           Destination Host Number (69.41.190.110)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    EzIP ID    |     EzIP      |   Extended    |   Extended    |
     6 |   (Source)    | Option Length |    Source     |    Source     |
       |    (0X9A)     |      (6)      |  No.-1 (246)  |   No.-2 (1)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Extended    |   Extended    |    EzIP ID    |     EzIP      |
     7 |    Source     |    Source     | (Destination) | Option Length |
       |   No.-3 (6)   |   No.-4 (40)  |     (0X9B)    |      (6)      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Extended    |   Extended    |   Extended    |   Extended    |
     8 |  Destination  |  Destination  |  Destination  |  Destination  |
       |  No.-1 (240)  |   No.-2 (0)   |   No.-3 (0)   |   No.-4 (0)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     9 |     Source Port (All 1's)     |     Destination Port (9N)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





               Figure 19 TCP/EzIP Header: From SPR4 to SPR1







Chen, et al.          Expires December 10, 2018               [Page 35]


Internet-Draft       Adaptive IPv4 Address Space              June 2018




A.2.7. SPR1 Sends the Packet to RG1

   In Figure 20, RG1 address is reconstructed from the Option number and
   the Extended Destination No.



        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     1 |Version|IHL (8)|Type of Service|       Total Length (36)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     2 |        Identification         |Flags|     Fragment Offset     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     3 | Time to Live  |    Protocol   |        Header Checksum        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     4 |              Source Host Number (69.41.190.148)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     5 |            Destination Host Number (240.0.0.0)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    EzIP ID    |     EzIP      |   Extended    |   Extended    |
     6 |   (Source)    | Option Length |    Source     |    Source     |
       |    (0X9A)     |      (6)      |  No.-1 (246)  |   No.-2 (1)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Extended    |   Extended    |    EzIP ID    |     EzIP      |
     7 |    Source     |    Source     | (Destination) | Option Length |
       |   No.-3 (6)   |   No.-4 (40)  |     (0X9B)    |      (6)      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Extended    |   Extended    |   Extended    |   Extended    |
     8 |  Destination  |  Destination  |  Destination  |  Destination  |
       |  No.-1 (240)  |   No.-2 (0)   |   No.-3 (0)   |   No.-4 (0)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     9 |     Source Port (All 1's)     |     Destination Port (9N)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





                Figure 20 TCP/EzIP Header: From SPR1 to RG1







Chen, et al.          Expires December 10, 2018               [Page 36]


Internet-Draft       Adaptive IPv4 Address Space              June 2018




A.2.8. RG1 Forwards the Packet to T1z

   In Figure 21, T1z address is reconstructed from RG1's NAT state-table
   based on Destination Port (9N).



        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     1 |Version|IHL (8)|Type of Service|       Total Length (36)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     2 |        Identification         |Flags|     Fragment Offset     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     3 | Time to Live  |    Protocol   |        Header Checksum        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     4 |              Source Host Number (69.41.190.148)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     5 |            Destination Host Number (192.168.1.9)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    EzIP ID    |     EzIP      |   Extended    |   Extended    |
     6 |   (Source)    | Option Length |    Source     |    Source     |
       |    (0X9A)     |      (6)      |  No.-1 (246)  |   No.-2 (1)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Extended    |   Extended    |    EzIP ID    |     EzIP      |
     7 |    Source     |    Source     | (Destination) | Option Length |
       |   No.-3 (6)   |   No.-4 (40)  |     (0X9B)    |      (6)      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Extended    |   Extended    |   Extended    |   Extended    |
     8 |  Destination  |  Destination  |  Destination  |  Destination  |
       |  No.-1 (240)  |   No.-2 (0)   |   No.-3 (0)   |   No.-4 (0)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     9 |     Source Port (All 1's)     |     Destination Port (9N)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




                Figure 21 TCP/EzIP Header: From RG1 to T1z








Chen, et al.          Expires December 10, 2018               [Page 37]


Internet-Draft       Adaptive IPv4 Address Space              June 2018




A.2.9. T1z Sends a Follow-up Packet to RG1

      In Figure 22, T1z sends a follow-up packet to RG1 with all fields
   filled with needed information.



        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     1 |Version|IHL (8)|Type of Service|       Total Length (36)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     2 |        Identification         |Flags|     Fragment Offset     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     3 | Time to Live  |    Protocol   |        Header Checksum        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     4 |              Source Host Number (192.168.1.9)                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     5 |          Destination Host Number (69.41.190.148)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    EzIP ID    |     EzIP      |   Extended    |   Extended    |
     6 |   (Source)    | Option Length |    Source     |    Source     |
       |    (0X9A)     |      (6)      |  No.-1 (240)  |   No.-2 (0)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Extended    |   Extended    |    EzIP ID    |     EzIP      |
     7 |    Source     |    Source     | (Destination) | Option Length |
       |   No.-3 (0)   |   No.-4 (0)   |     (0X9B)    |      (6)      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Extended    |   Extended    |   Extended    |   Extended    |
     8 |  Destination  |  Destination  |  Destination  |  Destination  |
       |  No.-1 (246)  |   No.-2 (1)   |   No.-3 (6)   |  No.-4 (40)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     9 |       Source Port (9N)        |   Destination Port (All 1's)  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




       Figure 22 TCP/EzIP Header: Follow-up Packets from T1z to RG1








Chen, et al.          Expires December 10, 2018               [Page 38]


Internet-Draft       Adaptive IPv4 Address Space              June 2018


A.3. Connection Between EzIP-unaware and EzIP-capable IoTs

A.3.1. T1a Initiates a Request to T4z

   Since T1a can create only conventional format IP header, the SPRs
   will provide CGN type of services to the IP packets. And, assuming
   SPR4 has a state-table set up by DMZ for forwarding the request to
   T4z, the packet will be delivered to T4z. Seeing the incoming packet
   with conventional IP header, T4z should respond with the same so that
   the session will be conducted with conventional TCP/IP headers. The
   interaction will follow the same behavior as in Appedix A.1.

A.3.2. T1z Initiates a Request to T4a

   Knowing T4a is not capable of EzIP header, T1z purposely initiates
   the request packet using conventional IP header. It will be treated
   by SPRs in the same manner as the T1a initiated case above and the
   packet will be recognizable by T4a.

   In brief, the steps outlined above are very much the same as the
   conventional TCP/IP header transitions between routers with CGN
   support. Except, when the IP header carries EzIP data as payload, the
   CGN function is replaced by the SPR process.

   Note that when an IoT, such as T4a or T4z, is directly connected to a
   SPR, like SPR4, there is no RG in between. There is no corresponding
   TCP port number in word 9 of the above TCP/EzIP headers. This spare
   facility in the header allows an RG be inserted, thus incorporating
   the private network environment like that on Premises 1, if desired.




















Chen, et al.          Expires December 10, 2018               [Page 39]


Internet-Draft       Adaptive IPv4 Address Space              June 2018


Appendix B  Internet Transition Considerations

   To enhance a large communication system like the Internet, it is
   important to minimize the disturbance to the existing equipments and
   processes due to any needed modification. The basic EzIP plan is to
   confine all actionable enhancements within the new SPR module. The
   following outlines the considerations for supporting the transition
   from the current Internet to the one enhanced by the EzIP technique.

B.1. EzIP Implementation

   B.1.1.   Introductory Phase:

   A. Insert an SPR in front of a web-server that desires to have
   additional subnet addresses for offering diversified activities. For
   the long term, a new web server may be designed with these two
   functional modules combined.

      .  The first address of a private network address pool, e.g.,
   242.0.0.0, used by the SPR should be reserved as a DMZ channel
   directing the initial incoming service requesting packets to the
   existing web server. This will maintain the same current operation
   behavior projected to the general public.

      .  The additional addresses, up to 242.255.255.255 may be used for
   EzIP address extension purposes. Each may be assigned to an
   additional web server representing one of the business's new
   activities. Each of these new servers will then respond with EzIP
   header to messages forwarded from the main server, or be directly
   accessible through its own EzIP address.

   B. Insert an SPR in front of a group of subscribers who are to be
   served with the EzIP capability. The basic service provided by this
   SPR will be the CGN equivalent function. This will maintain the same
   baseline user experience in accessing the Internet currently.

   C. Session initiating packets with basic IPv4 header will be routed
   by SPRs to a business's existing server at the currently published
   IPv4 public address (discoverable through existing DNS). The server
   should respond with the basic IPv4 format as well. Essentially, this
   maintains the existing interaction behavior between a user and a web
   server within an EzIP-unaware environment.

      So far, neither the web-server nor any subscriber's IoTs needs to
   be enhanced, because the operations remain pretty much the same as
   today's common practice utilizing CGN assisted connectivity. See
   Appendix A.1. for an example.


Chen, et al.          Expires December 10, 2018               [Page 40]


Internet-Draft       Adaptive IPv4 Address Space              June 2018


   D. Upon connected to the main web server, if a customer intentionally
   selects one of the new services, the main web server should ask the
   customer to confirm the selection.

      .  If confirmed, implying that the customer is aware of the fact
   that his IoT is being served by an SPR, the web server forwards the
   request to a branch server for carrying on the session via an EzIP
   address.

      .  The SPR at the originating side, recognizing the EzIP header
   from the additional web-server, replaces the CGN service with the
   EzIP routing.

      .  For all subsequent packets exchanged, the EzIP headers will be
   used in both directions. See Appendix A.2. for an example. This will
   speed up the transmission throughput performance for the rest of the
   session.

   B.1.2.   New IoT Operation Modes:

   A. EzIP-capable IoT will create EzIP header in initiating a session,
   to directly reach a specific EzIP-capable web-server, instead of the
   lengthy steps of going through the DMZ port followed by manually
   making the selection from the main web server. This will speed up the
   initial handshake process. See Appendix A.2. for an example.

   B. To communicate with an EzIP-unaware IoT, an EzIP-capable IoT
   should purposely initiate a session with conventional IP header. This
   will signal the SPRs to provide just the CGN type of connection
   service. See Appendix A.1. for an example.

   B.1.3.   End-to-End Operation:

   Once EzIP-capable IoTs become common for the general public, direct
   communication between any pair of such IoTs will be achievable. An
   EzIP-capable IoT, knowing the other IoT's full EzIP address, may
   initiate a session by creating an EzIP header that directs SPRs to
   provide EzIP services, bypassing the CGN process. See Appendix A.2.
   for an example.

B.2. SPR Operation Logic

   To support the above scenarios, the SPR should be designed with the
   following decision process:

   B.2.1. Initiating a Session Request from an IoT or via a RG



Chen, et al.          Expires December 10, 2018               [Page 41]


Internet-Draft       Adaptive IPv4 Address Space              June 2018


   If a session request IP packet contains EzIP Option word, it will be
   routed forward by SPR accordingly. Otherwise, the SPR provides CGN
   service by assigning a TCP port number to the packet and allowing the
   packet to masquerade with the SPR's own IP address while an entry to
   the state (port-forward / look-up / hash) table is created in
   anticipation of the reply packet.

   B.2.2.   Receiving a Session Request from the ER

   If a received IP packet includes a valid EzIP Option word or port
   number, SPR will utilize it to route the packet to an RG or an IoT.
   For a packet with plain IP header, it will be routed according to the
   Destination Host Number (IP header word 5).

B.3. RG Enhancement

   With IPv4 address pool expanded by the EzIP schemes, there will be
   sufficient publicly assignable addresses for IoTs wishing to be
   directly accessible from the Internet. On the other hand, the
   existing private networks may continue their current behavior of
   blocking session-request packets from the Internet. In-between,
   another connection mode is possible. The following describes such an
   option in the context of the existing RG operation conventions.

   B.3.1.   Initiating Session request for an IoT

   Without regard to whether the IP header is a conventional type or an
   EzIP one, a RG allows a packet to masquerade with the RG's own IP
   address by assigning a TCP port number to the packet and creating an
   entry to the state (port-forward / look-up / hash) table. This is the
   same as the current NAT practice.

   B.3.2.   Receiving a packet from the SPR

   The "Destination Port" value in the packet is examined:

      A. If it matches with an entry in the RG NAT's state-table, the
   packet is forward to the corresponding address. This is the same as
   the normal NAT processes in a conventional RG.

      B. If it matches with the address of an active IoT on the private
   network, the packet is assigned with a TCP port number and then
   forwarded to that IoT.

   Note that there is certain amount of increased security risk with
   this added last step, because a match between a guessed destination
   identity and the above two lists could happen by chance. To address


Chen, et al.          Expires December 10, 2018               [Page 42]


Internet-Draft       Adaptive IPv4 Address Space              June 2018


   this issue, the following proactive mechanism should be incorporated
   in parallel:

   If the "Destination Port" number is null or does not match with
   either of the above two cases, the packet is dropped and an alarm
   state is activated to monitor for possible ill-intended follow-up
   attempts. A defensive mechanism should be triggered when the number
   of failed attempts has exceeded the preset threshold within a
   predetermined finite time interval.

   In brief, if the IP header of a session requesting packet indicates
   that the sender knows the identity of the desired destination IoT on
   a private network, the common RG screening process will be bypassed.
   This facilitates the direct end-to-end connection, even in the
   presence of the NAT. Note that this process is very much the same as
   the AA (Automated Attendant) capability in a PABX telephone switching
   system that automatically makes the connection for a caller who
   indicates (via proper secondary dialing or the equivalent) knowing
   the extension number of the destination party. Such process has
   effectively screened out most of the unwanted callers while serves
   the acquaintance expeditiously.

Authors' Addresses

   Abraham Y. Chen
   Avinta Communications, Inc.
   142 N. Milpitas Blvd., #148, Milpitas, CA 95035-4401 US

   Phone: _+1(408)942-1485
   Email: AYChen@Avinta.com


   Abhay Karandikar
   Director, India Institute of Technology Kanpur
   Kanpur - 208 016, U.P., India

   Phone: _(+91)512 256 7220
   Email: Director@IITK.ac.in


   Ramamurthy R. Ati
   Avinta Communications, Inc.
   142 N. Milpitas Blvd., #148, Milpitas, CA 95035-4401 US

   Phone: _+1(408)458-7109
   Email: rama_ati@outlook.com



Chen, et al.          Expires December 10, 2018               [Page 43]


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