Adaptive IPv4 Address Space
draft-chen-ati-adaptive-ipv4-address-space-04
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Abraham Chen , Ramamurthy R. Ati , Abhay Karandikar , David Crowe | ||
| Last updated | 2018-12-11 (Latest revision 2018-06-10) | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-chen-ati-adaptive-ipv4-address-space-04
<Network Working Group> A. Y. Chen
Internet Draft R. R. Ati
Intended status: Experimental Avinta Communications, Inc.
Expires June 2019 A. Karandikar
India Institute of Technology
David Crowe
Cellular Networking Perspectives, Ltd.
Adaptive IPv4 Address Space
<draft-chen-ati-adaptive-ipv4-address-space-04.txt>
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on June 9, 2019.
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.
Abstract
Chen, et al. Expires June 7, 2019 [Page 1]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
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.
EzIP may expand an IPv4 address by a factor of 256M without affecting
the existing IPv4 based Internet, or the current private networks. It
is in full conformance with the IPv4 protocol, and supports not only
both direct and private network connectivity, but also their
interoperability. EzIP deployments may coexist with existing Internet
traffic and the IoT (Internet of Things) operations without
perturbing their setups, while offering end-users the freedom to
indepdently choose this system.
EzIP may be implemented as a software or firmware enhancement to
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 here establishes a complete spherical layer of
routers for interfacing between the Internet fabic (core plus edge
routers) and the end user premises. Incorporating caching proxy
technology in the gateway, a fairly large geographical region may
enjoy EzIP as address expansion using as little as one ordinary IPv4
public address utilizing IP packets with degenerated EzIP header.
If IPv4 public pool allocations were reorganized, the assignable pool
could be multiplied by 512M times or even more.
EzIP will immediately resolve local IPv4 address shortages, while
being transparent to the rest of the Internet. Under the Dual-Stack
environment, these proposed interim facilities will relieve the IPv4
address shortage issue, while affording IPv6 more time to reach
maturity and to provide the availability levels required for
delivering a long-term general service.
Chen, et al. Expires June 7, 2019 [Page 2]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Contents of this Draft . . . . . . . . . . . . . . . . . . 5
2. EzIP Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. EzIP Numbering Plan . . . . . . . . . . . . . . . . . . . . 6
2.2. Analogy with NAT . . . . . . . . . . . . . . . . . . . . . 7
2.3. EzIP System Architecture . . . . . . . . . . . . . . . . . 8
2.4. IP Header with Option Word . . . . . . . . . . . . . . . . 10
2.5. Examples of Option Mechanism . . . . . . . . . . . . . . . 11
2.6. EzIP Header . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7. EzIP Operation . . . . . . . . . . . . . . . . . . . . . . 13
3. EzIP Deployment Strategy . . . . . . . . . . . . . . . . . . . 13
4. Updating Servers to Support EzIP . . . . . . . . . . . . . . . 15
5. EzIP Enhancement and Application . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 20
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 21
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
Appendix A EzIP Operation . . . . . . . . . . . . . . . . . . . . 23
A.1. Connection between EzIP-unaware IoTs . . . . . . . . . . . 23
A.1.1. T1a Initiates a Session Request towards T4a . . . . . . 23
A.1.2. RG1 Forwards the Packet to SPR1 . . . . . . . . . . . . 24
A.1.3. SPR1 Sends the Packet to SPR4 through the Internet . . 25
A.1.4. SPR4 Sends the Packet to T4a . . . . . . . . . . . . . 26
A.1.5. T4a Replies to SPR4 . . . . . . . . . . . . . . . . . . 27
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 . . . . . . . . . . . . 28
A.1.9. T1a Sends a Follow-up Packet to RG1 . . . . . . . . . . 29
A.2. Connection Between EzIP-capable IoTs . . . . . . . . . . . 29
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 . . . 38
A.3.1. T1a Initiates a Request to T4z . . . . . . . . . . . . 38
A.3.2. T1z Initiates a Request to T4a . . . . . . . . . . . . 39
Appendix B Internet Transition Considerations . . . . . . . . . . 40
B.1. EzIP Implementation . . . . . . . . . . . . . . . . . . . . 40
Chen, et al. Expires June 7, 2019 [Page 3]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
B.1.2. New IoT Operation Modes: . . . . . . . . . . . . . . . 41
B.1.3. End-to-End Operation: . . . . . . . . . . . . . . . . . 41
B.2. SPR Operation Logic . . . . . . . . . . . . . . . . . . . . 41
B.3. RG Enhancement . . . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction
For various reasons, there is a large demand for IP addresses. It
would be useful to have a unique address for more Internet devices,
such that, if desired, any device may call upon any other directly.
The Internet of Things (IoT) would also be able to make use of more
routable 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].
In addition, IP addresses are needed while client devices, such as
mobile phones, are attached to the internet, which is an increasing
amount of time for a rapidly increasing number of devices.
The IPv4 dot-decimal address format, consisting of four octets, each
made of 8 binary bits, provides just over 4 billion unique address
(4,294,967,296 decimal exact).
IPv6, with its 128-bit hexadecimal address format, is four times as
long as the IPv4, has 256BBBB (4B x 4B x 4B x 4B) unique addresses.
It offers a promising solution to the address shortage. However, its
global adoption appears to be facing significant challenges [4],
[5].
Interim relief to the IPv4 address shortage has been provided by
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) [RFC6598] [6] over the public Internet.
However, 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 own clients, impeding the end-to-end setup requests initiated
from remote devices that a fully functional communication system
should be capable of. Being dynamic, the state-table used by CGN
increases CyberSecurity vulnerability. Because port numbers are used
to effectively increase the size of the address pool, they introduce
complex and sub-optimal port management requirements
If IPv4 capacity could be expanded without the size and efficiency
limitations of NAT, the urgency will be relaxed long enough for the
Chen, et al. Expires June 7, 2019 [Page 4]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
IPv6 to mature on its own pace.
There have been several proposals to increase the effective Internet
public address pool in the past. They all introduced new techniques
or protocols that ran into certain handicaps or compatibility issues,
preventing a smooth transition.
EzIP utilizes 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) as well as hosts
such as IoTs are not allowed to utilize. This is combined with the
Option mechanism defined in [RFC791] [1] for transporting such
information as the IP header payload that is transparent to all of
these routers, except a newly defined category named Semi-Public
Router (SPR). By inserting an SPR between an ER and a private
premises that it serves, each publicly assignable address can be
expanded 256M fold.
EzIP introduces minimal perturbation by utilizing the current
Internet system architecture. Its deployment will start with an SPR
providing public NAT functions, in a new way, to unload the burden
from the current CGN. With basic routing as an integral part of the
SPR, individual IoTs, or other large networks, will be encouraged to
migrate toward full EzIP service which provides end-to-end
connectivity between private premises.
1.1. Contents of this Draft
This draft outlines the EzIP numbering plan. An enhanced IP header,
called EzIP header, is introduced to carry the EzIP address as
payload using the Option word. How the Internet architecture will
change as the result of being extended by the EzIP scheme is
explained. How the EzIP header flows through various routers, and
Internet update considerations are described, with details presented
in Appendices A and B, respectively. Utilizing the EzIP approach, a
several ways to expand the publicly assignable IPv4 address pool, as
well as enhance Internet operations are then discussed.
Chen, et al. Expires June 7, 2019 [Page 5]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
2. EzIP Overview
2.1. EzIP Numbering Plan
EzIP uses the reserved private network address pools in very much the
same way that Private Automatic Branch eXchange (PABX) switches
utilize 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.
PABX extension numbers belong to a reusable private set. For example,
extension 123 or 1234 may exist in thousands of different PABX
switches without ambiguity. Similarly, the IPv4 private network
address may also be re-used in many networks without ambiguity.
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 extends each remaining public
address to multitudes of sub-addresses, resulting in an effectively
much larger assignable public address resource.
In fact, the initial EzIP analysis 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 it by 256 fold for supporting a corresponding number of
private premises.
A key EzIP concept is to use the elusive IPv4 240/4 block (240/8 -
255/8), that has been "RESERVED" for "Future use" since 1981-09. As
the result of the historical address assignment evolution, it was
proposed to redesignate it 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. Therefore, 240/4
remain reserved for future use.
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
Chen, et al. Expires June 7, 2019 [Page 6]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
factor of 256M without involving any existing router. This is because
the 240/4 addresses are only used within the RG SPR and within the
OPTION header extension, they are not used as IPv4 addresses within
the internet. These addresses are equivalent to PABX extension
numbers, with the additional advantage that IPv4 OPTION header
extensions can carry them through the network.
Since the 240/4 block cannot 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 assignable pool resulted from the EzIP
approach is about 983MB (3.84B x 256M), which is over 19M times of
the expected Year 2020 IoTs. This size certainly has the potential to
support the short- to mid-term public IP address needs.
2.2. Analogy with NAT
EzIP also has similarities to NAT, but some important differences.
NAT works by temporarily assigning a port number to outgoing
communications from a private address, while converting the private
address into a public IPv4 address for external communications. When
responses to messages are received, the public IPv4 address plus port
number is converted back into the private IPv4 address.
There are a number of limitations of NAT that are not present with
EzIP. (1) There are only 65,536 port numbers but 256M 240/4 EzIP
addresses; (2) Due to the limited number of ports, assignments are
only temporary and will be reclaimed after a period of inactivity but
there are so many EzIP addresses that assignments can be made for a
much longer period of time (days or months rather than seconds or
minutes); (3) Port numbers are used for other purposes than NAT,
further reducing the pool, but EzIP uses 240/4 addresses for only one
purpose; (4) Due to the limited time during which a port number is
assigned, the NAT port numbers cannot be used for incoming
communications, but with EzIP the address assignments will be long
term and could be used for direct communications from EzIP-aware
devices.
Chen, et al. Expires June 7, 2019 [Page 7]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
2.3. EzIP System Architecture
+------+
Web Server | WS0z |
+--+---+
|69.41.190.145
|
| +-----+
+--+ ER0 |
+--+--+
|
+------+-------+
+-------+ Core Routers +--------+
| | (CR/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 | | +---------+ |
+-----+ | | | |
Public | 240.0.0.0 | | 255.255.255.255
Demarc. ----+-------------------------------+----+-------------------
Private |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
The new category of router, SPR is to be positioned 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 premises. 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 June 7, 2019 [Page 8]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
2.2.1. Referring to the left-hand 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 ER
(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
[RFC1918] [8] blocks, 10/8, 172.16/12 and 192.168/16, such as
192.168.1.3 and 192.168.1.9 to identify the IoTs, T1a and T1z,
respectively.
2.2.2. Part of the right-hand portion of Figure 1 is labeled
"Premises 4". Here SPR4 directly 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 accessible through SPR4 from any other
IoT in the Internet.
2.2.3. Since the existing physical connections to subscriber's
premises terminate 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 (Demarc.) will remain at the RG where currently all
utility services enter a subscriber's premises.
2.2.4. To fully tag each of these devices, we may use a concatenated
three-part address notation: "Public - Semi-Public: TCP Port". The
following is how each of the IoTs in Figure 1 may be uniquely
identified in the Internet.
RG1: 69.41.190.110-240.0.0.0
T1a: 69.41.190.110-240.0.0.0:3
T1z: 69.41.190.110-240.0.0.0:9
T4a: 69.41.190.148-240.0.0.10
T4z: 69.41.190.148-246.1.6.40
Note that to simplify the presentation, it is assumed at this
juncture that the conventional TCP (Transmission Control Protocol)
[RFC793] [9] 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] [10] subsystem as
":3" and ":9", respectively. Such numbers are unique within each
respective /24 private network such as the 192.168.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
Chen, et al. Expires June 7, 2019 [Page 9]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
shall be avoided in actual practice by following the NAT operation
conventions as depicted by the examples in Appendix A.
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.4. IP Header with Option Word
To transport the EzIP Extension Addresses through existing devices
without being recognized as such and consequently acted upon, the IP
Header Option mechanism defined by Figure 9 of [RFC791] is utilized
to carry the addresses as payload. 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
summarized 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 Opt. Code, however, the eight bits
are parsed into three groups of 1, 2 and 5 bits "1 00 11010" with
meanings described in Figure 3.
Chen, et al. Expires June 7, 2019 [Page 10]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
+--------------------------------------------------------------+
| Meaning of EzIP ID = 0x9A (Example) |
+--------------+------------------+----------------------------+
| Copy Bit | Class | Option Value / Number |
+--------------+------------------+----------------------------+
| 1 (Set) | 00 (Control) | 11010 (26 - base 10) |
+--------------+------------------+----------------------------+
Figure 3 Option Type Octet
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 [11]. 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.5. 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] [12] (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, those 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 [13] (temporarily utilizing Option
Number = 26) by W. Chimiak: This work made use of the three
existing private network blocks to extend the public pool by
trading the private network operation for end-to-end connectivity.
Chen, et al. Expires June 7, 2019 [Page 11]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
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 rudimentary deterrent
against intrusion. In addition, the coexistence of private RG-NAT
and public EnIP router functions in the same EnIP devices (N1 &
N2), could lead to certain logistic inconsistency concerns.
2.6. EzIP 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 (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)
The proposed EzIP header format shown in Figure 4 can transport the
full 4 octet (32 bit) extension addresses of both ends of an Internet
link. The extension address in the 240/4 block utilized in the EzIP
scheme described herein has 28 significant bits. It is possible for
EzIP to use addresses having other lengths of significant bits for
different multiplication factors. To prepare for such variations, two
separate EzIP ID codes, "0x9A" and "0x9B" are proposed to distinguish
between Source and Destination Option words, respectively.
Chen, et al. Expires June 7, 2019 [Page 12]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
2.7. 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 branches to determine how
to provide the appropriate routing service for a smooth transition to
the long term operation. Appendix B outlines such logic and related
considerations.
3. EzIP Deployment Strategy
There are no security considerations relevant to this document.
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 daily issues. In
the process, the latter would be built up naturally.
A.Architecturally
Since the design philosophy of the SPR is an inline module between an
ER and the private premises (RG or directly connected IoTs) that it
serves, SPR introduction process can be flexible.
A.1. An 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, an 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 its ERs with the EzIP
capability.
This approach will empower individual communities to enjoy the new
EzIP capability on their own by upgrading all Internet subscribers
within a good sized region to have publicly accessible EzIP addresses
for intra-community peer-to-peer communication, starting from just
using one existing public IPv4 address to identify the entire region
Chen, et al. Expires June 7, 2019 [Page 13]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
through a gateway to the rest of the world. See sub-section C. below
for more specific considerations.
B. Functionally
B.1. First, an IAP should install SPRs in front of business web
servers so that new routing branches may be added to support the
additional web servers for expanding business activities.
Alternatively, this may be achieved if businesses on their own deploy
new web servers with the SPR capability built-in.
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 region
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 [3], a 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.) and 75% of the countries around
the world (most of the 233 countries other than the top 35).
Therefore, any finite sized region can immediately begin to enjoy
EzIP addressing by deploying a "RAN" utilizing SPRs operating with
one 240/4 block of addresses under one IPv4 public address. If the
gateway for a region is configured in such a way that the entire
region appears to be one ordinary IPv4 IoT to the rest of the
Internet, a RAN 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 [14], popularized by data-intensive
web services such as Google, Amazon, Yahoo, etc. Developed for
speeding up response to repetitive queries on the same topic, 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
distributed copies (not necessarily a full set, but relevant
subsets). This architecture meshs with the EzIP-based RAN very well,
because the address translation between the IPv4 in the Internet and
the EzIP in the RAN can be accomplished transparently through the two
ports of a caching proxy (For such matter, even could be between the
IPv6 and the EzIP if desired!). Consequently, existing Internet
routers, such as CR and ER may not see any IP packet with EzIP header
at all, during the initial phase of the RAN deployment which will
primarily consist of basic web server access, and intra-regional
Chen, et al. Expires June 7, 2019 [Page 14]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
messaging.
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, degenerated EzIP
header (conventional IP header with words 4 and 5 using addresses
from the 240/4 block) will be suffice for intra RAN traffic. This
mirrors the dialing procedure using only extension numbers among
stations served by the same PABX, circumventing the unnecessary and
wasteful overhead of including the dialing of the common public
telephone number prefix that identifies the PABX to the PSTN.
C.4. The full EzIP header format will only be used when an EzIP-
capable IoT intends to directly interact with an EzIP-capable IoT in
another RAN. The last part is equivalent to the DID (Direct Inward
Dialing) conventions that have been used in the PABX field for many
years.
C.5. The above would streamline the CIR (Country-based Internet
Registry) model proposed by ITU-T [18]. Instead of allocating a block
of public IPv6 addresses to an ITU-T authorized entity (essentially
the sixth RIR - Regional Internet Registry) to administrate on behalf
of individual countries, the EzIP RAN configuration enables each
member state to start her own CIR with up to 256M IoTs, based on just
one of the IPv4 public address already allocated to that country from
the responsible RIR. Consequently, each CIR is coordinated by its
parent RIR, yet its operation conforms to local preferences. This
scheme estqablishes a second Internet service parallel to the
existing one for demonstrating their respective merits independently,
offering subscribers true options to choose from.
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 RFC 791 [1], 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
Chen, et al. Expires June 7, 2019 [Page 15]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
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 [15]. 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 affecting web server access, subscribers not
demanding for high throughput performance may be migrated to the EzIP
supported facility first. This gives CRs the time to update so that
EzIP packets with authorized Option numbers will eventually be
recognized for receiving the "fast-path" service. On the other hand,
an alternative logic may be applied for the CR. That is, it should by
default ignore any Option word in an IP header so that all IP packets
will be processed through the "fast-path", unless a recognizable
Option word requiring action is detected. This approach would
mitigate the security issues caused by the "source routing" attack,
as well.
B. Connectivity Verification
One frequently used probing 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] [16].
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] [17], 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
Chen, et al. Expires June 7, 2019 [Page 16]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
pool be freely 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 basic IPv4 pool may be
divided into two halves, reserving one half of it (about 2B
addresses) as a semi-public network with the network number prefix
equal to "1". Each of the remaining 2B public addresses (with prefix
equal to "0") of the basic IPv4 pool may then be extended 2B fold
through the EzIP process, resulting in a 4BB address pool. This is
roughly 80M times of the Year 2020 IoT needs.
C. If the EzIP technique were applied through several layers of SPRs
in succession, the address expansion could be even more. For example,
let's divide the IPv4 pool equally into four blocks, each with about
1B addresses. Apply the first 1B address block to the public routers.
Set up three layers of SPRs, each makes use of one of the remaining
three 1B addresses. The resultant assignable pool will have 1BBBB
addresses. Under this configuration, the full length of an IoT's
identification code will be the concatenation of four segments of 32
bit IPv4 address, totalling 128 bits, the same as that of the IPv6.
The first two bits of each segment, however, 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.
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 for communicating within a local community, and associating an
address with the geographical position, 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.
Chen, et al. Expires June 7, 2019 [Page 17]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
Next, each section will have the second group of SPRs to manage upto
1B RGs and 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
be a GeoLocation-capable address system while maintaining the
existing IPv4 addressing and operation conventions:
a. Quantitative Reference: IETF [RFC6598] [6] reserved the
100.64/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.
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 table 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 (about 190 out of
233, or about 80%) countries should be able to port all of their
respective predicted IoTs to be under one 240/4 block, each
represented by one gateway to the Internet. If this is managed
according to geographical disciplines, each participating region
will begin to enjoy the benefits of the EzIP approach, such as
Chen, et al. Expires June 7, 2019 [Page 18]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
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. Then, each of
such 240/4 block will have more than half of its capacity
available to serve the growth of additional IoTs.
g. This last step is very much the same as the traditional PSTN
"Area Code Split" practice, whereby telephone numbers of a service
area are split into two (or more) blocks, upon introducing one (or
more) new area code(s) into the area. All subscribers will
continue to use their original local telephone numbers for calling
among neighbors daily, except some may be assigned with a new area
code prefix. Upon the split, 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 to the cybersecurity vulnerability.
F. With the IPv4 address shortage issue resolved, potential system
configurations utilizing 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. This is 80K times of the expected 50B IoTs.
Or, each and every person (of predicted 2020 population) 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. Next, the IPv4 pool originally has 256 blocks of /8 addresses.
After the above allocation, there are still 239 blocks of /8
Chen, et al. Expires June 7, 2019 [Page 19]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
addresses available to support additional digital communication
systems, each having the same size of address pool as the
allocation above. Consequently, many world-wide communication
networks may coexist under the same IPv4 protocol framework in the
form of groups of RANs as described earlier, with arm's-length
links among them.
c. For example, a satellite based Internet that is being proposed
[19], can start fresh with one EzIP RAN 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 RAN, 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-RAN communications, most of the time. Only when direct
communication with another RAN (such as the one for the existing
Internet) is needed, full EzIP header will be used. As users grow,
additional RANs (each with 256M IoTs capacity), may be
incrementally added to support the expansion.
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 RANs each managed by one SPR with 256M IoTs capacity that are
inter-operable digital communication systems, normally operate at
arm's-lenghth to one another. Each of these groups has 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
Chen, et al. Expires June 7, 2019 [Page 20]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
impact on already in-place routers and security mechanisms is
minimized.
The basic EzIP philosophy includes maintaining 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) may
remain unchanged. A subscriber is encouraged to upgrade his IoT(s) to
be EzIP-capable so as to enjoy the enhanced router service by EzIP.
This particular manifestation of the EzIP scheme appears to be the
optimal solution to our needs.
The 240/4 block based EzIP scheme will not only relief the IPv4
address shortage issue, but also improve the defense against
cybersecurity intrusion by virtue of systematic address management.
The EzIP' RAN (Regional Area Network) configuration will also support
the desire to establish CIR operation expressed by ITU-T, as a
parrellel facility to provide Internet type services by individual
entities versus the current global model.
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 at 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_IBSG_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/rfc6598
[7] http://www.iana.org/assignments/ipv4-address-space/ipv4-address-
Chen, et al. Expires June 7, 2019 [Page 21]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
space.xhtml
[8] https://tools.ietf.org/html/rfc1918
[9] https://tools.ietf.org/html/rfc793
[10] https://www.ietf.org/rfc/rfc2131.txt
[11] http://www.iana.org/assignments/ip-parameters/ip-
parameters.xhtml
[12] https://tools.ietf.org/html/rfc1385
[13] https://tools.ietf.org/html/draft-chimiak-enhanced-ipv4-03
[14] https://en.wikipedia.org/wiki/Proxy_server#Improving_performance
[15]
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.477.1942&rep=rep1&type=pdf
[16] https://tools.ietf.org/html/rfc862
[17] https://tools.ietf.org/html/rfc2928
[18] https://www.nro.net/wp-content/uploads/nro-response-to-ls-5.pdf
[19] 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 and 3-
nroff.template.
Chen, et al. Expires June 7, 2019 [Page 22]
Internet Draft Adaptive IPv4 Address Space December 10, 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 the same as 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 drawbacks 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, EzIP-capable
IoTs behave like EzIP-unaware IoTs. 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
T1a sends a session request to SPR4 that serves T4a by a plain IP
packet with header as in Figure 5, to RG1. There is no TCP port
number in this IP header yet.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 |Version|IHL (5)|Type of Service| Total Length (20) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Source Host Number (192.168.1.3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Destination Host Number (69.41.190.148) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 IP Header: From T1a to RG1
Chen, et al. Expires June 7, 2019 [Page 23]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
A.1.2. RG1 Forwards the Packet to SPR1
RG1, allowing be masqueraded by T1a, relays the packet toward SPR1 by
assigning the TCP Source port number, 3N, to T1a, with a header as in
Figure 6,. 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 RG1 state table for
handling the reply packet from the Destination site. Since T4a's TCP
port number is not known yet, it is filled with all 1's.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 |Version|IHL (5)|Type of Service| Total Length (24) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Source Host Number (240.0.0.0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Destination Host Number (69.41.190.148) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Source Port (3N) | Destination Port (All 1's) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 TCP/IP Header: From RG1 to SPR1
Chen, et al. Expires June 7, 2019 [Page 24]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
A.1.3. SPR1 Sends the Packet to SPR4 through the Internet
SPR1, detecting no EzIP option word, acts like a CGN. It allows being
masqueraded by RG1 (with the Source Host Number changed to be SPR1's
own and the TCP port number changed to 0C, where "0" is the last
octet of RG1's IP address, and "C" stands for CGN) and sends the
packet as in Figure 7 out through the Internet towards SPR4. The
packet traverses through the Internet (ER1, CR and ER4) utilizing
only the Destination Host Number (word 5) in the 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 (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
Note that although schematically shown in Figure 1 as one public IPv4
address serving one SPR capable of a full 240/4 address block, the
PCP port number has a theoretical limit of 64K (256 x 256) because it
consists of 16 bits. This is much smaller than a full 240/4 pool.
Even with dynamic assignments, it will take quite a few public
address to serve the NAT need if many IoTs are EzIP-unaware. So, IoTs
are encouraged to become EzIP-capable as soon as possible to avoid
straining the SPR's NAT capability. This should not be an issue for
emerging regions currently having very little facility and IoTs. As
new ones are deployed, they should be enabled as EzIP-capable by
factory default. For the rural area of developed countries with
existing EzIP-unaware IoTs, the need for CG-NAT service will be
greater. Multiple IPv4 public addresses would be needed initially to
support smaller sub- 240/4 blocks. This is probably workable because
the latter does have more public IPv4 addresses. The CG-NAT
techniques developed under RFC6264 [6] may be incorporated here to
facilitate the transition.
Chen, et al. Expires June 7, 2019 [Page 25]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
A.1.4. SPR4 Sends the Packet to T4a
Since the packet has a conventional TCP/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 (Here,
"10" is the fourth octet of T4a's Extension address, and "C" stands
for CGN.). After constructing the Destination Host Number
accordingly, SPR4 sends the packet to T4a with a header as in Figure
8.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 |Version|IHL (5)|Type of Service| Total Length (24) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Source Host Number (69.41.190.110) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Destination Host Number (240.0.0.10) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Source Port (0C) | Destination Port (10C) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8 TCP/IP Header: From SPR4 to T4a
Chen, et al. Expires June 7, 2019 [Page 26]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
A.1.5. T4a Replies to SPR4
T4a interchanges the Source and Destination identifications in the
incoming TCP/IP packet to create a header as in Figure 9, for the
reply packet to SPR4.
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
A.1.6. SPR4 Sends the Packet to SPR1 through the Internet
SPR4, allowing being masqueraded by T4a, sends the packet toward SPR1
with the header in Figure 10, through the Internet (ER4, CR and ER1)
who will simply relay the packet according to the information in word
5 (Destination Host Number):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 |Version|IHL (5)|Type of Service| Total Length (24) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Source Host Number (69.41.190.148) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Destination Host Number (69.41.190.110) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Source Port (10C) | Destination Port (0C) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10 TCP/IP Header: From SPR4 to SPR1
Chen, et al. Expires June 7, 2019 [Page 27]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
A.1.7. SPR1 Sends the Packet to RG1
Using the stored data in the CGN state-table, SPR1 reconstructs a
header as in Figure 11, for sending the packet to RG1.
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
A.1.8. RG1 Forwards the Packet to T1a
From the state-table in RG1's NAT, T1a address is reconstructed based
on Destination Port (3N), as in Figure 12.
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
Chen, et al. Expires June 7, 2019 [Page 28]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
A.1.9. T1a Sends a Follow-up Packet to RG1
To carry on the communication, T1a constructs a full TCP/IP header as
in Figure 13 for sending the follow-up packet to RG1.
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
A.2. Connection Between EzIP-capable IoTs
The following is an example of EzIP operation between T1z and T4z
shown in Figure 1, with 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. Note that T4z, without the private portion
(TCP port number) in the concatenated address, is directly
addressable from the Internet. For T1z to initiate a session, it
needs to know the full address of T4z, but only it's own private
address.
Chen, et al. Expires June 7, 2019 [Page 29]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
A.2.1. T1z Initiates a Session Request towards T4z
T1z sends an EzIP packet, as in Figure 14, to RG1. There is no TCP
port number word, because T4z does not have such while that for T1z
is waiting for assignment from the RG1's NAT. Also, the Extended
Source No. is filled with all "1's", waiting for being specified by
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 (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 (255) | No.-2 (255) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended | Extended | EzIP ID | EzIP |
7 | Source | Source | (Destination) | Option Length |
| No.-3 (255) | No.-4 (255) | (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
Chen, et al. Expires June 7, 2019 [Page 30]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
A.2.2. RG1 Forwards the Packet to SPR1
RG1, allowing to be masqueraded by T1z, relays a packet as in Figure
15, toward SPR1 by assigning the TCP Source port number, 9N, to T1z.
Not knowing whether T4z is behind an RG, "All 1's" is used to fill
the Destination Port part 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 (255) | No.-2 (255) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended | Extended | EzIP ID | EzIP |
7 | Source | Source | (Destination) | Option Length |
| No.-3 (255) | No.-4 (255) | (0X9B) | (6) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended | Extended | Extended | Extended |
8 | Destination | Destination | Destination | Destination |
| No.-1 (246) | No.-2 (1) | No.-3 (6) | No.-4 (40) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | Source Port (9N) | Destination Port (All 1's) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15 TCP/EzIP Header: From RG1 to SPR1
Chen, et al. Expires June 7, 2019 [Page 31]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
A.2.3. SPR1 Sends the Packet to SPR4 through the Internet
SPR1 replaces the Source Host Number with its own as well as fills in
the Extended Source No. information, and then sends the packet, with
a header as in Figure 16, out into the Internet towards SPR4. The
packet traverses through ER1, CR and ER4, utilizing only the
Destination Host Number (Word 5) in the 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 (8)|Type of Service| Total Length (36) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Source Host Number (69.41.190.110) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Destination Host Number (69.41.190.148) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EzIP ID | EzIP | Extended | Extended |
6 | (Source) | Option Length | Source | Source |
| (0X9A) | (6) | No.-1 (240) | No.-2 (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended | Extended | EzIP ID | EzIP |
7 | Source | Source | (Destination) | Option Length |
| No.-3 (0) | No.-4 (0) | (0X9B) | (6) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended | Extended | Extended | Extended |
8 | Destination | Destination | Destination | Destination |
| No.-1 (246) | No.-2 (1) | No.-3 (6) | No.-4 (40) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | Source Port (9N) | Destination Port (All 1's) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16 TCP/EzIP Header: From SPR1 to SPR4
Chen, et al. Expires June 7, 2019 [Page 32]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
A.2.4. SPR4 Sends the Packet to T4z
SPR4 reconstructs T4z address from the Option number 0X9B and the
Extended Destination No. then sends the packet, with the header as in
Figure 17, to T4z.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 |Version|IHL (8)|Type of Service| Total Length (36) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Source Host Number (69.41.190.110) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Destination Host Number (246.1.6.40) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EzIP ID | EzIP | Extended | Extended |
6 | (Source) | Option Length | Source | Source |
| (0X9A) | (6) | No.-1 (240) | No.-2 (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended | Extended | EzIP ID | EzIP |
7 | Source | Source | (Destination) | Option Length |
| No.-3 (0) | No.-4 (0) | (0X9B) | (6) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended | Extended | Extended | Extended |
8 | Destination | Destination | Destination | Destination |
| No.-1 (246) | No.-2 (1) | No.-3 (6) | No.-4 (40) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | Source Port (9N) | Destination Port (All 1's) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17 TCP/EzIP Header: From SPR4 to T4z
Chen, et al. Expires June 7, 2019 [Page 33]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
A.2.5. T4z Replies to SPR4
Making use of the information in the incoming TCP/EzIP header, T4z
replies to SPR4 with a full header, as in Figure 18.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 |Version|IHL (8)|Type of Service| Total Length (36) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Source Host Number (246.1.6.40) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Destination Host Number (69.41.190.110) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EzIP ID | EzIP | Extended | Extended |
6 | (Source) | Option Length | Source | Source |
| (0X9A) | (6) | No.-1 (246) | No.-2 (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended | Extended | EzIP ID | EzIP |
7 | Source | Source | (Destination) | Option Length |
| No.-3 (6) | No.-4 (40) | (0X9B) | (6) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended | Extended | Extended | Extended |
8 | Destination | Destination | Destination | Destination |
| No.-1 (240) | No.-2 (0) | No.-3 (0) | No.-4 (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | Source Port (All 1's) | Destination Port (9N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18 TCP/EzIP Header: From T4z to SPR4
Chen, et al. Expires June 7, 2019 [Page 34]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
A.2.6. SPR4 Sends the Packet to SPR1 through the Internet
SPR4 replaces the Source Host Number with its own, and sends the
packet with the header, as in Figure 19, towards SPR1. The Internet
(ER4, CR, and ER1) simply relays the packet according to the TCP/EzIP
header word 5 (Destination Host Number):
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 |Version|IHL (8)|Type of Service| Total Length (36) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Source Host Number (69.41.190.148) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Destination Host Number (69.41.190.110) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EzIP ID | EzIP | Extended | Extended |
6 | (Source) | Option Length | Source | Source |
| (0X9A) | (6) | No.-1 (246) | No.-2 (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended | Extended | EzIP ID | EzIP |
7 | Source | Source | (Destination) | Option Length |
| No.-3 (6) | No.-4 (40) | (0X9B) | (6) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended | Extended | Extended | Extended |
8 | Destination | Destination | Destination | Destination |
| No.-1 (240) | No.-2 (0) | No.-3 (0) | No.-4 (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | Source Port (All 1's) | Destination Port (9N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19 TCP/EzIP Header: From SPR4 to SPR1
Chen, et al. Expires June 7, 2019 [Page 35]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
A.2.7. SPR1 Sends the Packet to RG1
SPR1 reconstructs RG1 address from the Option number 0X9B and the
Extended Destination No. Then, sends packet with a header as in
Figure 20 toward RG1.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 |Version|IHL (8)|Type of Service| Total Length (36) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Source Host Number (69.41.190.148) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Destination Host Number (240.0.0.0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EzIP ID | EzIP | Extended | Extended |
6 | (Source) | Option Length | Source | Source |
| (0X9A) | (6) | No.-1 (246) | No.-2 (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended | Extended | EzIP ID | EzIP |
7 | Source | Source | (Destination) | Option Length |
| No.-3 (6) | No.-4 (40) | (0X9B) | (6) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended | Extended | Extended | Extended |
8 | Destination | Destination | Destination | Destination |
| No.-1 (240) | No.-2 (0) | No.-3 (0) | No.-4 (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | Source Port (All 1's) | Destination Port (9N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20 TCP/EzIP Header: From SPR1 to RG1
Chen, et al. Expires June 7, 2019 [Page 36]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
A.2.8. RG1 Forwards the Packet to T1z
RG1 reconstructs T1z address from RG1's NAT state-table based on
Destination Port (9N), then sends the packet to T1z with a header as
in Figure 21.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 |Version|IHL (8)|Type of Service| Total Length (36) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Source Host Number (69.41.190.148) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Destination Host Number (192.168.1.9) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EzIP ID | EzIP | Extended | Extended |
6 | (Source) | Option Length | Source | Source |
| (0X9A) | (6) | No.-1 (246) | No.-2 (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended | Extended | EzIP ID | EzIP |
7 | Source | Source | (Destination) | Option Length |
| No.-3 (6) | No.-4 (40) | (0X9B) | (6) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended | Extended | Extended | Extended |
8 | Destination | Destination | Destination | Destination |
| No.-1 (240) | No.-2 (0) | No.-3 (0) | No.-4 (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | Source Port (All 1's) | Destination Port (9N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21 TCP/EzIP Header: From RG1 to T1z
Chen, et al. Expires June 7, 2019 [Page 37]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
A.2.9. T1z Sends a Follow-up Packet to RG1
With all fields filled with needed information from the incoming
TCP/EzIP header, T1z sends a follow-up packet to RG1 as in Figure 22.
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
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 TCP/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 TCP/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.
Chen, et al. Expires June 7, 2019 [Page 38]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
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 as in Appedix
A.1. so that the packet will be recognizable by T4a.
Note that to maximize the combination in the EzIP System Architecture
diagram (Figure 1) for demonstrating the possible variations, there
is no RG on Premises 4. IoTs, such as T4a and T4z, are thus directly
connected to a SPR, like SPR4 and there is no corresponding TCP port
number in word 9 of the above TCP/EzIP headers. This spare facility
in the header suggests that an RG may be installed if desired, to
establish the similar private network environment as that on Premises
1.
In brief, the steps outlined above are very much the same as the
conventional TCP/IP header transitions through the Internet with the
SPR providing the CGN service. Except, when a TCP/EzIP header is
detected, the SPR switches to the router mode for forwarding the
packet to improve the performance.
In essence, with the EzIP system architecture very much the same as
today's Internet, the SPR starts with assuming the current CGN duty,
while ready to perform the new EzIP routing function for EzIP-aware
IoTs. This strategy offers a simple transition path for the Internet
to evolve toward the future.
It is important to note that both SPR and CGN are inline devices with
respect to ER. However, since CGN provides soft / ephemeral TCP
ports, it is positioned between a CR and ERs, while SPR is located
between an ER and RGs to assign hard / static physical addresses.
Chen, et al. Expires June 7, 2019 [Page 39]
Internet Draft Adaptive IPv4 Address Space December 10, 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 required 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 255.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
current baseline user experience in accessing the Internet.
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 user experience between a customer and a web
server within an EzIP-unaware environment.
So far, neither the web-server nor any subscriber's IoTs needs to be
enhanced, because the operations remain pretty much the same as
today's common practice utilizing CGN assisted connectivity. See
Appendix A.1. for an example.
Chen, et al. Expires June 7, 2019 [Page 40]
Internet Draft Adaptive IPv4 Address Space December 10, 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 on the customer side, recognizing the EzIP header from
the branch web-server, replaces the CGN service with the EzIP
routing.
- For all subsequent packets exchanged, the EzIP headers will be
used in both directions. This will speed up the transmission
throughput performance for the rest of the session. See Appendix
A.2. for an example.
in 3
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 manual interaction steps of going through the DMZ
port then 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 wide spread among 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 service, 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. Sending an IP packet out for an IoT or a RG
Chen, et al. Expires June 7, 2019 [Page 41]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
If the IP header contains EzIP Option word, SPR will route it
forward by using the EzIP mechanism (replacing Source Host Number
by SPR's own and filling in Extended Source No. if not already
there). Otherwise, the SPR provides the CGN service (assigning TCP
Source Port number and allowing the packet to masquerade with the
SPR's own IP address, plus creating an entry to the state (port-
forward / look-up / hash) table in anticipation of the reply
packet).
B.2.2. Receiving an IP packet from the ER
If a received IP packet includes a valid EzIP Option word, SPR
will provide the EzIP routing service (utilizing the Extended
Destination No. as the Destination Host Number). If only
Destination Port number is present, CGN service will be provided.
For a packet with plain IP header (with neither EzIP nor CGN
information), it will be dropped.
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 forwarded to the corresponding address. This is the same
as the normal NAT processes in a conventional RG.
B. If it matches with the IP address of an active IoT on the
private network, the packet is assigned with a TCP port number and
then forwarded to that IoT.
Chen, et al. Expires June 7, 2019 [Page 42]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
Note that there is certain amount of increased security risk with
this added last step, because a match between a guessed
destination identity and either of the above two lists could
happen by chance. To address this issue, the following proactive
mechanism should be incorporated in parallel:
If the "Destination Port" number is null or matches with neither
of the above two lists, 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 an equivalent means) 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
David Crowe
Wireless Telecom Consultant and Forensic Expert Witness
Chen, et al. Expires June 7, 2019 [Page 43]
Internet Draft Adaptive IPv4 Address Space December 10, 2018
102 Point Drive NW, Calgary, Alberta, T3B 5B3, Canada
Phone: _+1(403)289-6609
Email: David.Crowe@cnp-wireless.com
Chen, et al. Expires June 7, 2019 [Page 44]