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