idnits 2.17.1 draft-chen-ati-adaptive-ipv4-address-space-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 7. IANA Considerations' ) ** The abstract seems to contain references ([2], [RFC791], [3], [RFC862], [4], [5], [6], [RFC2928], [7], [8], [9], [10], [11], [12], [RFC1385], [13], [14], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 9 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 9 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 12, 2017) is 2510 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC791' on line 532 -- Looks like a reference, but probably isn't: 'RFC1385' on line 543 -- Looks like a reference, but probably isn't: 'RFC862' on line 828 -- Looks like a reference, but probably isn't: 'RFC2928' on line 835 -- Obsolete informational reference (is this intentional?): RFC 793 (ref. '6') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 1385 (ref. '9') (Obsoleted by RFC 6814) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 A. Y. Chen 2 Internet Draft R. R. Ati 3 Intended status: Experimental Avinta Communications, Inc. 4 Expires: December 2017 5 June 12, 2017 7 Adaptive IPv4 Address Space 8 draft-chen-ati-adaptive-ipv4-address-space-01.txt 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on December 12, 2017. 33 Copyright Notice 35 Copyright (c) 2017 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Abstract 50 This document describes a solution to the Internet address depletion 51 issue through the use of an existing Option mechanism that is part of 52 the original IPv4 protocol. This proposal, named EzIP (phonetic for 53 Easy IPv4), discusses the IPv4 public address pool expansion and the 54 Internet system architecture enhancement aspects. It was originated 55 by a study called ExIP (Extended IPv4) analyzing the use of the first 56 available octet (eight bits) in the reserved private network pools 57 (10/8, 172.16/12 and 192.168/16) to achieve a moderate address space 58 expansion factor of 256 by each, while maintaining their familiar 59 operation characteristics. Along the way, a parallel yet similar 60 effort, called EnIP (Enhanced IPv4), was discovered. EnIP fully 61 utilizes the same private network pools to increase the address space 62 by a factor of 17.1M with end-to-end connectivity. EzIP is a superset 63 that proposes one unified format for not only encompassing the 64 considerations of both, but also identifying additional capabilities 65 and flexibilities. For example, the EzIP may expand an IPv4 address 66 at least by a factor of 256 to as high as 256M without affecting the 67 existing IPv4 public address assignments, and even keeping the 68 current private networks intact for the 256M case. The EzIP is in 69 full conformance with the IPv4 protocol, and supports not only both 70 categories of connectivity, but also their interoperability. The 71 traditional Internet traffic and the IoT (Internet of Things) 72 operations may coexist simultaneously without perturbing their 73 existing setups, while offering end-users the freedom to choose one 74 or the other. If the IPv4 public pool were reorganized, the 75 assignable pool could be multiplied by 512M or even up to 2B times 76 with end-to-end connectivity. The EzIP may be implemented as a 77 software / firmware enhancement to the Internet edge routers or 78 private network gateways wherever needed, or simply installed as an 79 inline adjunct hardware module between the two, enabling a seamless 80 introduction. The 256M case establishes a spherical layer of routers 81 providing a complete interconnection between the Internet and end- 82 users. This configuration enables the entire current IPv4 based 83 Internet and private networks characteristics to remain intact. Under 84 the Dual-Stack environment, these proposed interim facilities would 85 relieve the IPv4 address shortage issue, while afford IPv6 more time 86 to orderly reach the maturity and the availability levels required 87 for delivering a long-term general service. 89 Table of Contents 91 1. Introduction...................................................4 92 1.1. Contents of this Draft....................................5 93 2. EzIP Overview..................................................6 94 2.1. EzIP Numbering Plan.......................................6 95 2.2. EzIP System Architecture.................................11 96 2.3. IP Header with Option Word...............................13 97 2.4. Examples of Option Mechanism.............................13 98 2.5. Basic EzIP Header........................................14 99 2.6. EzIP Operation...........................................16 100 2.7. Generalizing EzIP Header.................................17 101 3. EzIP Deployment Strategy......................................18 102 4. Updating Servers to Support EzIP..............................19 103 5. EzIP Enhancements.............................................20 104 6. Security Considerations.......................................25 105 7. IANA Considerations...........................................25 106 8. Conclusions...................................................25 107 9. References....................................................26 108 9.1. Normative References.....................................26 109 9.2. Informative References...................................26 110 10. Acknowledgments..............................................27 111 Appendix A EzIP System Architecture.............................28 112 A.1. EzIP System Part A.......................................28 113 A.2. EzIP System Part B.......................................28 114 A.3. EzIP System Part C.......................................29 115 A.4. EzIP System Part D.......................................30 116 Appendix B EzIP Operation.......................................32 117 B.1. Connection between EzIP-unaware IoTs.....................32 118 B.1.1. T1a Initiates a Session Request towards T4a.........32 119 B.1.2. RG1 Forwards the Packet to SPR1.....................33 120 B.1.3. SPR1 Sends the Packet to SPR4 through the Internet..34 121 B.1.4. SPR4 Sends the Packet to T4a........................35 122 B.1.5. T4a Replies to SPR4.................................36 123 B.1.6. SPR4 Sends the Packet to SPR1 through the Internet..37 124 B.1.7. SPR1 Sends the Packet to RG1........................38 125 B.1.8. RG1 Forwards the Packet to T1a......................39 126 B.1.9. T1a Sends a Follow-up Packet to RG1.................39 127 B.2. Connection Between EzIP-capable IoTs.....................40 128 B.2.1. T1z Initiates a Session Request towards T4z.........40 129 B.2.2. RG1 Forwards the Packet to SPR1.....................41 130 B.2.3. SPR1 Sends the Packet to SPR4 through the Internet..42 131 B.2.4. SPR4 Sends the Packet towards T4z...................43 132 B.2.5. T4z Replies to SPR4.................................44 133 B.2.6. SPR4 Sends the Packet to SPR1 through the Internet..45 134 B.2.7. SPR1 Sends the Packet to RG1........................46 135 B.2.8. RG1 Forwards the Packet to T1z......................47 136 B.2.9. T1z Sends a Follow-up Packet to RG1.................48 137 B.3. Connection Between EzIP-unaware and EzIP-capable IoTs....48 138 B.3.1. T1a initiates a request to T4z......................48 139 B.3.2. T1z initiates a request to T4a......................49 140 Appendix C Internet Transition Considerations...................50 141 C.1. EzIP Implementation......................................50 142 C.2. SPR Operation Logic......................................51 143 C.3. RG Enhancement...........................................52 145 1. Introduction 147 For various reasons, there is a large demand for IP addresses. It 148 would be useful to have a unique address for each Internet device, 149 such that if desired, any device may call any other. The Internet of 150 Things (IoT) would also be able to make use of more routable 151 addresses if they were available. Currently, these are not possible 152 with the existing IPv4 facility. 154 By Year 2020, the population and number of IoTs are expected to reach 155 7.6B (Billion) and 50B respectively, according to a recent Cisco 156 online paper [1]. 158 The IPv4 dot-decimal address format, consisting of four octets each 159 made of 8 binary bits, results in the maximum number of assignable 160 public addresses of 4.295 billion (calculated by 256 x 256 x 256 x 161 256 to be 4,294,967,296 - decimal exact). Using the binary / 162 shorthand notation of 64K representing 256 x 256 (decimal 65,536), 163 the full IPv4 address pool of 64K x 64K may be expressed as 4,096M, 164 or 4.096B (or, rounded to 4B). Clearly, the demand is more than 13 165 times over the inherent capability available from the supply. 167 The IPv6 with 128-bit hexadecimal address format having a capacity of 168 256BBBB (4B x 4B x 4B x 4B) combination offers a potential solution 169 to this problem, but its global adoption appears to face certain 170 challenges [2], [3]. Network Address and Port Translation (NAPT - 171 commonly known simply as NAT) on private networks together with 172 Carrier Grade NAT (CGNAT) over the Internet have been providing the 173 interim solutions thus far. However, NAT modules slow down routers 174 due to the state-table look-up process. As well, they only allow an 175 Internet session be initiated by their respective own clients, 176 impeding the end-to-end setup requests from remote devices that 177 certain IoT operations desire. 179 If the IPv4 capacity could be expanded to eliminate this address pool 180 deficiency while maintaining the familiar established operation 181 conventions, and perhaps even to offer reasonable reserve, the 182 urgency will be relaxed long enough for the IPv6 to mature on its own 183 pace. 185 To increase the Internet public address pool, there have been various 186 proposals in the past. Among them, two recent efforts in particular 187 are referenced by this draft, namely ExIP and EnIP. The ExIP [4] 188 study focuses on reclaiming part of a reserved private network 189 address block, for example the third octet of 192.168/16, to be 190 publicly routable at the edge of the Internet. By making use of this 191 octet as semi-public address, the number of assignable public 192 addresses is increased by a factor of 256 to become 1049B which is 193 more than 20 times of the expected IoTs. This address expansion could 194 be implemented in an inline module called Semi-Public Router (SPR) 195 collocated with the Internet Edge Router (ER). Of course, the size of 196 the resultant private networks will be reduced accordingly. 198 The Enhanced IP (EnIP) [5] project proposes to increase the available 199 IPv4 public address space by a factor of 17.1M. Like IPv6, EnIP 200 results in full end-to-end connectivity among the enhanced addresses. 201 The EnIP implementation module, "NAT and EnIPNAT/translator", 202 replacing existing private network gateway, is very similar to the 203 proposed SPR here. 205 The EzIP merges these two schemes into one uniform solution. Neither 206 Internet Core (/ backbone) Router (CR), nor private network Routing 207 (/ Residential) Gateway (RG) needs to handle the Options added to the 208 resultant IP header, since their designs recognize and preserve this 209 Option mechanism, yet do not have the knowledge to process the 210 specific EzIP information. Even the Edge Routers (ER) may stay 211 unchanged, if the SPR is deployed with the adjunct configuration 212 during the introductory phase. 214 The assignable IPv4 compatible public address pool may be expanded 215 significantly more upon incorporating other available IPv4 resources 216 by the EzIP technique, as discussed in the latter part of this 217 document. 219 1.1. Contents of this Draft 221 The rest of this draft begins with outlining the EzIP numbering plan. 222 An enhanced IP header called EzIP header is introduced for carrying 223 the EzIP address data in the Option words. The overview of the 224 Internet architecture as the result of being expanded by the EzIP 225 scheme, the EzIP header transitions through various routers and the 226 operation considerations are discussed next, with details presented 227 in Appendices A, B and C, respectively. Utilizing the EzIP approach, 228 a range of possibilities of expanding the publicly assignable IPv4 229 address pool as well as enhancing the Internet operation flexibility 230 are then described. 232 2. EzIP Overview 234 2.1. EzIP Numbering Plan 236 The ExIP technique which is the foundation of the EzIP scheme began 237 with making use of the reserved private network address pools in very 238 much the same manner as Private Automatic Branch eXchange (PABX) 239 telephone switching machines utilizing locally assigned "extension 240 numbers" to expand the Public Switched Telephone Network (PSTN) 241 capacity by replicating a public telephone line to multitudes of 242 reusable private telephone numbers, each to identify a local 243 instrument. 245 At the first sight, this correlation may seem odd, because the 246 extension numbers of a PABX belong to a separate set from that of the 247 public telephone numbers and both are independently expandable, while 248 private network IP address is a specific subset reserved from the 249 overall IPv4 pool that is otherwise all public and finite. However, 250 recognizing that neither of the latter two is allowed to operate in 251 the other's domain suggests that the proposed EzIP numbering system 252 indeed may mirror the telephony case. Bsically, the critical aspect 253 is how to partition a finite address pool to be public or private. So 254 that the private network portion serves to multiply the addresses of 255 the public portion, resulting in an effectively larger address 256 resource. 258 In fact, the ExIP analysis made explicit the untold two-stage 259 subnetting process of 192.168/16 that has been practiced routinely by 260 consumer RGs (Residential / Routing Gateways) for a long time. End- 261 users are accustomed to the second stage of an RG choosing values 262 from the fourth octet for its IoTs. The first stage of selecting a 263 value from the third octet as the factory default for an RG is 264 implicitly capable of expanding a public IPv4 address by 256 times. 266 2.1.1. To facilitate the following discussions, the 32 bits in a 267 private network address notation are divided into three parts, namely 268 Network, Extension and IoT No.'s as shown in Figure 1 below. 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Network No. - Extension No. : IoT No. | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Figure 1 EzIP Address Notation (Generic) 278 The number of bits in the Extension No. part determines the 279 multiplication factor to be applied by the EzIP process. The trailing 280 IoT No. bits determine the size of the resultant private network. The 281 Network No. part is the specific binary value of the remaining 282 leading bits (the prefix) identifying an address block that will be 283 reserved from the public IPv4 pool. 285 2.1.2. Following the general concept of subnetting, the unit for 286 expanding an address does not need to be restricted to the boundary 287 of an octet. This allows potentially finer grain resolution. 289 2.1.3. How to utilize the 32 bits leads to the tradeoff among EzIP 290 operation characteristics. For example, maintaining the private 291 network properties or establishing the end-to-end connectivity is 292 just a matter of whether there are bits reserved for the IoT No. 294 2.1.4. This notation may be used to present two general categories 295 of EzIP address types: 297 A. To retain the private network characteristics, the EzIP 298 subnetting makes use of only the first available octet. For the 299 common three private network address pools, we will have the 300 following: 302 In Figure 2, 8 bits are available for IoT No., resulting in private 303 networks each capable of 256 IoTs. 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | 192.168 - Extension No. : IoT No. | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Figure 2 EzIP-1 (8 bits of 192.168/16 semi-publicly addressable) 313 In Figure 3, 12 bits are available for IoT No., resulting in private 314 networks each capable of 4K IoTs. 316 0 1 2 3 317 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 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | 172.16 - Extension No. : IoT No. | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 Figure 3 EzIP-2 (8 bits of 172.16/12 semi-publicly addressable) 324 In Figure 4, 16 bits are available for IoT No., resulting in private 325 networks each capable of 64K IoTs. 327 0 1 2 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | 10 - Extension No. : IoT No. | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 Figure 4 EzIP-3 (8 bits of 10/8 semi-publicly addressable) 335 B. To allow direct access from the Internet, EzIP makes use of all 336 available bits in a reserved private network address as Extension 337 No., leaving no bit for the IoT No. The resultant private network 338 will have no RG, but only one IoT that is directly connected to the 339 Internet: 341 In Figure 5, 16 bits are assigned for Extension No., resulting in 64K 342 IoTs directly addressable from the Internet. 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | 192.168 - Extension No. | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 Figure 5 EzIP-4 (16 bits of 192.168/16 semi-publicly addressable) 352 In Figure 6, 20 bits are assigned for Extension No., resulting in 353 1M IoTs directly addressable from the Internet. 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | 172.16 - Extension No. | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 Figure 6 EzIP-5 (20 bits of 172.16/12 semi-publicly addressable) 363 In Figure 7, 24 bits are assigned for Extension No., resulting in 16M 364 IoTs directly addressable from the Internet. 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | 10 - Extension No. | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 Figure 7 EzIP-6 (24 bits of 10/8 semi-publicly addressable) 374 For cross reference purpose, EzIP-1 through EzIP-3 are the same 375 numbering types used by the ExIP study, while EzIP-4 through EzIP-6 376 are used by the EnIP project. 378 Figure 8 summarizes the number of possible publicly and privately 379 assignable addresses for each original IPv4 public address under 380 different configurations. 382 | 192.168/16 | 172.16/12 | 10/8 | 383 ==============+===============+================+==============+ 384 Basic IPv4 | | | | 385 --------------+---------------+----------------+--------------+ 386 Address Bits* | 32 | 32 | 32 | 387 --------------+---------------+----------------+--------------+ 388 Public | 1 | 1 | 1 | 389 Private | 64K | 1M | 16M | 390 ==============+===============+================+==============+ 391 (ExIP) | EzIP-1 | EzIP-2 | EzIP-3 | 392 --------------+---------------+----------------+--------------+ 393 Address Bits* | 40 | 40 | 40 | 394 --------------+---------------+----------------+--------------+ 395 Semi-Public | 256 | 256 | 256 | 396 Private | 256 | 4K | 64K | 397 ==============+===============+================+==============+ 398 (EnIP) | EzIP-4 | EzIP-5 | EzIP-6 | 399 --------------+---------------+----------------+--------------+ 400 Address Bits* | 48 | 52 | 56 | 401 --------------+---------------+----------------+--------------+ 402 Public | 64K | 1M | 16M | 403 Private | 1 | 1 | 1 | 404 ==============+===============+================+==============+ 406 Notes: 408 a. * -- Effective Overall Public Address Length 410 b. For each Public-Private pair, the numbers of addresses are 411 multiplicative, not additive. 413 Figure 8 Basic IPv4 Address Expansion Configurations 415 2.2. EzIP System Architecture 417 +------+ 418 Web Server | WS0z | 419 +--+---+ 420 |69.41.190.145 421 | 422 | +-----+ 423 +--+ ER0 | 424 +--+--+ 425 | 426 +------+-------+ 427 +-------+ Internet +--------+ 428 | |(Core Routers)| | 429 +--+--+ +--------------+ +--+--+ 430 +-----+ ER1 | +-----+ ER4 | 431 | +-----+ | +-----+ 432 | | 433 EzIP-1 |69.41.190.110 EzIP-4 |69.41.190.148 434 +--+--+ +--+--+ 435 +-----------+ +-------+ +---------+ +------+ 436 | +-----+ SPR1| | | +-----+ SPR4+--+ | 437 | | +-----+ | | | +-----+ | | 438 | 192.168.2.0 ... 192.168.255.0 | | | | 439 +-----+ |...| |...| 440 |192.168.1.0 | | +---------+ | 441 +--+--+ | | | | 442 +---+ RG1 +--+ 192.168.0.1 | | 192.168.255.255 443 | +-----+ | | | 444 | Premises 1 | +----------+ | 445 | | | Premises 4 | 446 |192.168.1.3 |192.168.1.9 |192.168.4.10 |192.168.4.40 447 +--+--+ +--+--+ +--+--+ +--+--+ 448 | T1a | .... | T1z | | T4a | ....... | T4z | 449 +-----+ +-----+ +-----+ +-----+ 451 Figure 9 EzIP System Architecture-A (192.168/16 Portion) 453 With six basic EzIP expansion types, it is difficult to include 454 them all in one single system architecture diagram. A complete set of 455 system architectural diagrams is presented in Appendix A. To 456 facilitate the presentation, a partial system diagram covering only 457 the 192.168/16 (EzIP-1 and EzIP-4) portion as presented in Figure 9 458 will be utilized for the discussions that follow. 460 +--------------------------+-----------------+----------------+ 461 | | Basic IPv4 | EzIP-capable | 462 +--------------------------+-----------------+----------------+ 463 | Internet Edge Router (ER)| ER0, ER1, ER4 | ------------ | 464 +--------------------------+-----------------+----------------+ 465 | Internet of Things (IoT) | T1a, T4a | T1z, T4z | 466 +--------------------------+-----------------+----------------+ 467 | Routing Gateway (RG) | RG1 | ------------ | 468 +--------------------------+-----------------+----------------+ 469 | Semi-Public Router (SPR) | ------------- | SPR1, SPR4 | 470 +--------------------------+-----------------+----------------+ 471 | Web Server (WS) | ------------- | WS0z | 472 +--------------------------+-----------------+----------------+ 474 Figure 10 EzIP-1 & EzIP-4 Components 476 2.2.1. Referring to the left portion labeled EzIP-1 of Figure 9, 477 instead of assigning each premises a public IPv4 address as in the 478 current practice, an SPR like SPR1, is inserted between an Internet 479 Edge Router (ER1) and its connections to private network Routing 480 Gateways like RG1, for utilizing the third octet, such as 481 192.168.nnn/24 (nnn = 0 through 255) to identify respective premises. 482 The RG1, serving either a LAN (Local Area Network) or a HAN (Home 483 Area Network), uses the fourth octet "mmm" of 192.168.nnn.mmm/32 to 484 identify the IoTs it manages. This is how common RGs are being 485 configured today anyway (Factory default values of nnn are usually 0, 486 1, 2, 10, etc.) 488 2.2.2. The right portion of Figure 9 is labeled EzIP-4. Here SPR4 489 assigns the full range of the available 192.168/16 IP addresses (the 490 third and fourth octets) individually to T4a through T4z. 491 Consequently, these IoTs are directly accessible from any remote 492 device on the Internet. 494 2.2.3. Since the existing physical connections to subscriber's 495 premises do appear at the ER, it is natural to have SPRs be 496 collocated with their ER. It follows that the simple routing function 497 provided by the new SPR modules may be absorbed into the ER through a 498 straightforward operational firmware enhancement. Consequently, the 499 public - private demarcation line will remain at the RG where 500 currently all utility services enter a subscriber's premises. 502 2.2.4. To identify each of these devices, we may use a three part 503 address format "IPv4 - Semi-Public: TCP Port No.". The following is 504 how each of the IoTs in Figure 9 may be identified. 506 RG1: 69.41.190.110-192.168.1.0 508 T1a: 69.41.190.110-192.168.1.0:3 510 T1z: 69.41.190.110-192.168.1.0:9 512 T4a: 69.41.190.148-192.168.4.10 514 T4z: 69.41.190.148-192.168.4.40 516 Note that to simplify the presentation, it is assumed at this 517 juncture that the conventional TCP (Transmission Control Protocol) 518 [6] Port Number, normally assigned to T1a and T1z by RG1's NAT module 519 upon initiating a session, equals to the fourth octet of that IoT's 520 private IP address that is assigned by the RG1's DHCP (Dynamic Host 521 Configuration Protocol) [7] module as ":3" and ":9", respectively. 522 Such numbers are unique within each respective private network. They 523 are adequate for the discussion purpose here. However, considering 524 security, as well as allowing each IoT to have multiple simultaneous 525 sessions, etc., this direct correlation shall be avoided in actual 526 practices by following the NAT operation conventions as depicted by 527 the examples in Error! Reference source not found.. 529 2.3. IP Header with Option Word 531 To transport the EzIP Extension No., we will make use of the Option 532 word in the IP header as defined in Figure 9 of [RFC791] [8]. This 533 mechanism has been used for various cases in the past. Since they 534 were mostly for utility or experimental purposes, however, their 535 formats may be remote from the incident discussion. 537 2.4. Examples of Option Mechanism 539 The following two cases specifically deal with the address pool 540 issues. They are referenced here to facilitate the appreciation of 541 the Option mechanism. 543 A. EIP (Extended Internet Protocol) - [RFC1385] [9] (Assigned but 544 now deprecated Option Number = 17) by Z. Wang: This approach 545 attempted to add a new network layer on top of the existing Internet 546 for increasing the addressable space. Although equipment near the 547 end-user would stay unchanged, equipments around the Internet Core 548 Routers (CR) apparently had to go through rather involved upgrade 549 procedures, perhaps due to the flexible length of the extended 550 address (potentially could be longer than that of the IPv6). 552 B. EnIP (Enhanced IPv4) - Internet Draft [5] (temporarily 553 utilizing Option Number = 26) by W. Chimiak: This work makes use of 554 the reserved private network addresses to extend the public pool by 555 trading the private network operation for end-to-end connectivity. 556 The EnIP and ExIP approaches closely resemble each other. However, 557 the fully deployed EnIP would eliminate the current private networks. 559 2.5. Basic EzIP Header 561 The basic EzIP header format uses the Option ID field to convey the 562 value of the "Network No." as well as the length of the "Extension 563 No.". This header has the capacity to handle up to two octets of the 564 "Extension No." on either end of a connection. 566 0 1 2 3 567 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 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 1 |Version|IHL (7)|Type of Service| Total Length (28) | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 2 | Identification |Flags| Fragment Offset | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 3 | Time to Live | Protocol | Header Checksum | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 4 | Source Host Number | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 5 | Destination Host Number | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | EzIP ID | EzIP | Extended | Extended | 580 6 | (Source) | Option Length | Source | Source | 581 | (------) | (4) | No.-1 | No.-2 | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | EzIP ID | EzIP | Extended | Extended | 584 7 | (Destination) | Option Length | Destination | Destination | 585 | (------) | (4) | No.-1 | No.-2 | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 Figure 11 Basic EzIP Header (Two Octet) 590 To transport an IP header for T4z at the Source end and RG1 at the 591 Destination end, Figure 12 depicts an EzIP header example: 593 0 1 2 3 594 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 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 1 |Version|IHL (7)|Type of Service| Total Length (28) | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 2 | Identification |Flags| Fragment Offset | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 3 | Time to Live | Protocol | Header Checksum | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 4 | Source Host Number (69.41.190.148) | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 5 | Destination Host Number (69.41.190.110) | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | EzIP-4 | EzIP | Extended | Extended | 607 6 | (Source) | Option Length | Source | Source | 608 | (0X9A) | (4) | No. (4) | No. (40) | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | EzIP-1 | EzIP | Extended | End of | 611 7 | (Destination) | Option Length | Destination | Option List | 612 | (0x9B) | (3) | No. (1) | (00000000) | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 Figure 12 EzIP Header Example 1 617 Note that the Option IDs 0x9A (Option Number = 26) and 0x9B (Option 618 Number = 27), both representing Network No. 192.168/16 while 619 conveying the Extension No.'s being two and one octet, respectively, 620 in the above figure, are arbitrarily chosen from the currently 621 available Option Numbers list [10]. Since RG1 extension No. has only 622 one octet, the "End of Option list" Option is used to fill up word 7. 624 If the transmission direction is reversed, types of EzIP extension 625 used by the Source and the Destination will be interchanged as well. 626 The unused octet will now be at the end of word 6. The "No Operation" 627 Option should be used as the filler shown in Figure 13: 629 0 1 2 3 630 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 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 1 |Version|IHL (7)|Type of Service| Total Length (28) | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 2 | Identification |Flags| Fragment Offset | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 3 | Time to Live | Protocol | Header Checksum | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 4 | Source Host Number 69.41.190.110) | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 5 | Destination Host Number (69.41.190.148) | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | EzIP ID | EzIP | Extended | No | 643 6 | (Source) | Option Length | Source | Operation | 644 | (0X9B) | (3) | No. (1) | (00000001) | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | EzIP ID | EzIP | Extended | Extended | 647 7 | (Destination) | Option Length | Destination | Destination | 648 | (0x9A) | (4) | No. (4) | No. (40) | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 Figure 13 EzIP Header Example 2 653 2.6. EzIP Operation 655 With half a dozen of EzIP types, it would be very tedious and 656 distracting to go through all combinations of IP header 657 configurations and their transitions through the network. To convey 658 the general scheme, Error! Reference source not found. presents 659 examples of EzIP header transitions through routers among IoTs having 660 EzIP-1 and EzIP-4 types of addresses, with and without EzIP 661 capability. 663 To introduce the EzIP approach into an environment where EzIP-unaware 664 IoTs like T1a and T4a will be numerous for a long time to come, a SPR 665 must be able to follow certain decision rules to determine which type 666 of service to provide for achieving a smooth transition. Appendix C 667 outlines such logic and related considerations. 669 2.7. Generalizing EzIP Header 671 2.7.1. The basic EzIP header shown in Figure 11 with up to two 672 octet Extension No. format is not capable of EzIP-5 and EzIP-6 types 673 with 20 and 24 bit, respectively. One extra octet is needed on each 674 end of such a link. An additional word in the header, however, will 675 have two octets unused. To take advantage of this spare resource, we 676 might as well consider a header format shown in Figure 14 that can 677 transport the full 4 octet (32 bit) extension addresses of both ends. 678 This is similar as the EnIP header [5], except more flexible by 679 allowing EzIP type being independent of that at the other end. 681 0 1 2 3 682 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 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 1 |Version|IHL (8)|Type of Service| Total Length (32) | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 2 | Identification |Flags| Fragment Offset | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 3 | Time to Live | Protocol | Header Checksum | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 4 | Source Host Number | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 5 | Destination Host Number | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | EzIP ID | EzIP | Extended | Extended | 695 6 | (Source) | Option Length | Source | Source | 696 | (0X9A) | (6) | No.-1 | No.-2 | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Extended | Extended | EzIP ID | EzIP | 699 7 | Source | Source | (Destination) | Option Length | 700 | No.-3 | No.-4 | (0X9A) | (6) | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Extended | Extended | Extended | Extended | 703 8 | Destination | Destination | Destination | Destination | 704 | No.-1 | No.-2 | No.-3 | No.-4 | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 Figure 14 Full EzIP Header (Four octet) 709 2.7.2. In brief, Figure 12 or Figure 13 with seven words (40% 710 overhead) having two octet capacity is suitable to transport EzIP-1 711 through EzIP-4 types consisting of one or two octet Extension No. 712 EzIP-5 and EzIP-6 require the next IP header size which is eight 713 words (60% overhead),capable of transporting full four octet IPv4 714 addresses as shown in Figure 14. 716 2.7.3. Being a superset, utilizing "No Operation" or "End of Option 717 List" type of fillers, Figure 14 is capable of handling information 718 for EzIP-1 through EzIP-4 just as well. The question then becomes; 719 whether the extra 20% overhead when handling EzIP-1 through EzIP-4 720 headers is tolerable? If so, the single Figure 14 format may be used 721 for all EzIP cases. 723 2.7.4. With the "Network No." prefixes of the well-know private 724 network addresses all explicitly carried by the IP header of every 725 packet as shown in Figure 14, the Option Number only needs to 726 identify the length of the "Extended No.". Consequently, one Option 727 Number is sufficient to represent EzIP-1 through EzIP-3 that only the 728 first available octet is used for the Extension No. Similarly, one 729 single Option Number representing EzIP-4 through EzIP-6 conveys the 730 condition that all available bits are to be used for Extension No. 732 2.7.5. One potential drawback of the full four octet EzIP header is 733 that it may cause Internet routers to intercept a packet for 734 containing a disallowed (private network) IP address, although 735 positioned at a location of the header normally not designated for 736 address information. 738 2.7.6. By harmonizing EzIP-4 to -6 (EnIP) with EzIP-1 to -3 (ExIP) 739 into one common (EzIP) format, enjoying which operating 740 characteristics will simply be the result of a user subscribing to an 741 EzIP address type appropriate for how he wishes to use his IoT. 743 3. EzIP Deployment Strategy 745 Although the eventual goal of the SPR is to support both web server 746 access by IoTs from behind private networks and direct end-to-end 747 connectivity between IoTs, the former application should be addressed 748 first to immediately relieve the basic address shortage issue. Once 749 the IoTs on both ends of an intended connection are served by SPRs, 750 it will be natural to realize the latter. 752 A. Architecturally 754 Since the design philosophy of the SPR is an inline module between an 755 Internet ER (Edge Router) and the private network RG (Routing 756 Gateway) it serves, SPR introduction process may be flexible. 758 A.1. A SPR may be deployed as an inline module after an ER to 759 begin providing the CGNAT equivalent function. This could be done 760 immediately without affecting any of the existing Internet 761 components, CR, ER and RG. EzIP-capable IoTs will then take 762 advantage of the faster bi-directional routing services through the 763 SPRs by initiating a communication session to another EzIP-capable 764 IoT with an EzIP header. 766 A.2. Alternatively, a SPR may be deployed as an adjunct module 767 before an existing RG to realize the same EzIP functions on private 768 premises, even if the serving Internet Service Provider (ISP) has not 769 enhanced ERs with the EzIP capability. This empowers individual 770 subscribers to enjoy the new EzIP capability on their own. This 771 approach could upgrade all residents within a good size area to have 772 publically accessible addresses for community-wide peer-to-peer 773 communication based on just one or two current IPv4 addresses. 775 B. Functionally 777 B.1. First, an ISP should install SPRs in front of business web 778 servers so that new routing branches may be added to support the 779 additional web servers for expanding business activities. 780 Alternatively, this may be achieved by deploying new web servers with 781 the SPR function built-in. 783 B.2. On the subscriber side, SPRs should be deployed to relieve 784 the public address shortage issue, and to facilitate the access to 785 new web servers. 787 C. Permanently 789 In the long run, it would be best if SPRs are integrated into ERs by 790 upgrading the latter's firmware to minimize the hardware and to 791 streamline the overall system architecture. 793 Appendix C details the considerations in implementing these outlines. 795 4. Updating Servers to Support EzIP 797 Although the IP header Option mechanism utilized by EzIP was defined 798 a long time ago as part of the original IPv4 protocol, it has not 799 been used much in daily traffic. Compatibility with current Internet 800 facilities and conventions may need be reviewed. Since the EzIP 801 information is transported as part of the defined IP header payload, 802 it is not exected to affect higher layer protocols. Certain facility 803 may be optimized without considering the Option mechanism. They need 804 be adjusted to provide the same performance to EzIP packets. There 805 are also utility type of servers that need be updated to support the 806 longer EzIP address. For example; 808 A. Fast Path 809 Internet Core Routers (CRs) are currently optimized to only provide 810 the "fast-path" (through hardware line card) routing service to 811 packets without Option word in the IP header [11]. This puts EzIP 812 packets in a disadvantage, because EzIP packets would be put through 813 the "slow path" (processed by CPU's software before giving to the 814 correct hardware line card to forward), resulting in a slower 815 throughput. Since the immediate goal of the EzIP is to ease the 816 address pool exhaustion issue, subscribers not demanding for high 817 performance traffic may be assigned with the facility provided 818 through EzIP. This gives time for Internet routers to update so that 819 EzIP packets with authorized Option numbers will eventually be 820 recognized for receiving the "fast-path" service. 822 B. Connectivity Verification 824 One frequently used utility for verifying baseline connectivity, 825 commonly referred to as the "PING" function in PC terminology, needs 826 be able to transport the full EzIP address that is longer than the 827 standard 32 bit IPv4 address. There is an example of an upgraded TCP 828 echo server in [RFC862] [12]. 830 C. Domain Name Server (DNS) 832 Similarly, the DNS needs to expand its data format to transport the 833 longer IP address created by EzIP. This already can be done under 834 IPv6. Utilizing the experimental IPv6 prefix 2001:0101 defined by 835 [RFC2928] [13], EzIP addresses may be transported as standardized 836 AAAA records. 838 These topics are discussed in more detail under the IETF Draft RFC, 839 Enhanced IPv4 - V.03 [5]. 841 5. EzIP Enhancements 843 To minimize disturbing any assigned addresses, deployed equipment and 844 current operation procedures, etc., the EzIP derivations so far are 845 conducted under the constraint of utilizing only the existing three 846 reserved private network address blocks. Beyond such, there are other 847 possibilities. In the long run, EzIP may significantly expand the 848 current IPv4 public address pool through the employment of such 849 additional resources outlined below. 851 A. In reviewing the IP Option Number assignments [10], it is 852 discovered that more than a dozen of them are currently available. 853 That is, besides five numbers, 26, 27, 28, 29 & 31 that have never 854 been assigned, there are eleven numbers assigned earlier but have 855 been deprecated due to the end of associated experiments. If we take 856 six such numbers, one to represent each of the six EzIP extension 857 types, the EzIP-1 to EzIP-3 cases will multiply the IPv4 public 858 address pool by a factor of 256, individually, or a combined factor 859 of 768, resulting in 3,145.728B, or 3.146KB publicly assignable 860 addresses. Similarly, we can use one Option Number for each of the 861 EzIP-4, -5 and -6 cases to multiply IPv4 pool by 64K, 1M and 16M (a 862 total of 17.1M) fold, respectively, to the combined total of 69.894MB 863 addresses. These capacities are over 63 and 1.4M times of the 864 expected Year 2020 IoTs, respectively. 866 B. EzIP-8: If all Option numbers were made available, each 867 representing one EzIP Network No. prefix, up to 32 private network 868 address blocks, like the 10/8 could be utilized by EzIP. To determine 869 the upper limit of this scenario, let's assume that we could employ 870 31 additional 10/8 type address blocks, say by re-designating 11/8 871 through 41/8 as private network blocks. These enable us to expand 872 each existing IPv4 public address by 32 x 16M or 512M fold. Since 873 this block of 512M addresses have to be removed from the basic public 874 pool, the resulting total addresses will be (4.096B - 512M) x 512M, 875 or 1,835MB. This is over 36M times of the predicted number of IoTs 876 (50B) by Year 2020. It certainly has the capacity to deal with the 877 short- to mid- term public IP address needs. 879 C. The above may be condensed for a more efficient operation. For 880 example, a single 224/3 block contains the same amount of 512M 881 addresses may be chosen upon re-allocation of currently assigned IPv4 882 public addresses so that just one Option Number may represent it. Now 883 that we have freed up 31 Option numbers, we could allocate up to 31 884 more /3 address blocks for EzIP operation that provides even more 885 extension address resource. However, this last step will exceed the 886 total capacity of the IPv4 pool. On the other hand, this line of 887 reasoning leads to the next observation. 889 D. EzIP-9: One interesting consequence of the EzIP header in Figure 890 144 capable of transporting the full 32 bit private network address 891 is that the Extension No. may be as long as practical. That is, we 892 can go to the extreme of reserving only one bit for the Network No., 893 and leaving nothing for the IoT No. With these criteria, the current 894 IPv4 pool may be divided into two halves, reserving one half of it 895 (about 2B addresses) as a private network with prefix equal to "1" as 896 the Network No., and all trailing 31 bits designated as Extension No. 897 Each of the remaining 2B addresses (with prefix equals to "0") of the 898 basic IPv4 pool may then be expanded 2B times through the EzIP 899 process, resulting in a total of 4BB addresses that are IPv4 900 compatible and capable of full end-to-end connectivity. This is 901 roughly 80M times of the Year 2020 IoT needs. Note that this scenario 902 will depend on reorganizing the currently already assigned address 903 blocks, thus is only for academic illustration of the potential. 905 E. EzIP-7: In addition, this full 32 bit EzIP addresses transport 906 facility may be applied to the elusive IPv4 240/4 block (240/8 - 907 255/8) consisting of 256M addresses that has become "RESERVED for 908 Future use" [14] since 1981 as the result of the historical address 909 assignment evolution. Since this block is not suitable for being used 910 as public address, it might as well be re-classified as an additional 911 (the fourth) reusable private network pool, but not used as such. 912 Then, the SPR may use this block as the semi-public extension address 913 pool in the EzIP process. Following this approach, each current IPv4 914 public address may be multiplied by 256M times based on only one 915 Option Number. Since the 240/4 block could not be used for public 916 addressing, the size of the publicly assignable IPv4 pool has 917 actually been only 3.84B (4.096B - 256M). So, the net public 918 addressable pool created from this approach is 983MB (3.84B x 256M), 919 which is over 19.6M times of the expected Year 2020 IoTs. This scheme 920 is very close to EzIP-8. Although half of its capacity, this EzIP 921 manifestation has the advantage of circumventing reassignment of 922 public IPv4 addresses. In addition, this approach preserves all 923 practices of the three private networks. 925 The following compares various IPv4 public address pool expansion 926 configurations. 928 | Extension |Option|Effect. |Expansion|Assignable| SUP/|Connect- | 929 | Scheme | Used | AddBits| Factor | Pub Add | DMD | ivity | 930 +=============+======+========+=========+==========+=====+=========+ 931 | IPv4 Public Address Block Assignments Unchanged | 932 +---+---------+------+--------+---------+----------+-----+---------+ 933 | E | EzIP-1 | 1 | 40 | 256 | 978.69B | 19.6| PrivNet | 934 | x +---------+------+--------+---------+----------+-----+---------+ 935 | I | EzIP-2 | 1 | 40 | 256 | 978.69B | 19.6| PrivNet | 936 | P +---------+------+--------+---------+----------+-----+---------+ 937 | | EzIP-3 | 1 | 40 | 256 | 978.69B | 19.6| PrivNet | 938 +---+---------+------+--------+---------+----------+-----+---------+ 939 | E | EzIP-4 | 1 | 48 | 64K | 244.67KB | 5K |EndToEnd | 940 | n +---------+------+--------+---------+----------+-----+---------+ 941 | I | EzIP-5 | 1 | 52 | 1M | 3.82MB | 77K |EndToEnd | 942 | P +---------+------+--------+---------+----------+-----+---------+ 943 | | EzIP-6 | 1 | 56 | 16M | 61.17MB | 1M |EndToEnd | 944 +---+---------+------+--------+---------+----------+-----+---------+ 945 |EzIP-7(240/4)| 1 | 60 | 256M | 978.69MB | 20M |EndToEnd | 946 +=============+======+========+=========+==========+=====+=========+ 947 | IPv4 Public Address Block Assignments Adjusted | 948 +-------------+------+--------+---------+----------+-----+---------+ 949 | EzIP-8 | | | | | | | 950 | (224/3) | 1 | 61 | 512M | 1.84BB | 36M |EndToEnd | 951 +-------------+------+--------+---------+----------+-----+---------+ 952 | EzIP-9 | | | | | | | 953 | (Half of | 1 | 63 | 2B | 4BB | 80M |EndToEnd | 954 | IPv4 Pool) | | | | | | | 955 +=============+======+========+=========+==========+=====+=========+ 957 Notes: 959 a. EzIP-1 through EzIP-7 Assignable Public Addresses calculated 960 with the net basic IPv4 public address pool of 3.823B after removed 961 the 240/4, 10/8, 172.16/12 and 192.168/16 blocks from the original 962 4.096B 964 b. EzIP-8 and EzIP-9 Assignable Public Addresses calculation 965 started from scratch based on the full IPv4 pool of 4.096B minus only 966 the specific portion used for extension purpose 968 c. "SUP/DMD": Ratio of EzIP SUPplied publicly assignable addresses 969 to IoT DeManD by Year 2020 971 d. Each group of EzIP-1 to -3 and EzIP-4 to -6 may need only one 972 Option number if the "four octet" EzIP header format is used. 974 Figure 15 IPv4 Address Multiplication Possibilities 976 F. It is important to note that schemes summarized in Figure 15 are 977 not mutually exclusive but mostly complementary. Except the last two 978 cases (EzIP-8 and EzIP-9) that are intend to demonstrate the 979 potential public address sizes by starting from the full 4.096B IPv4 980 pool ignoring the current assignments and reservations, EzIP-1 981 through EzIP-7 may be applied to the same public IPv4 address since 982 they are distinguished from one another by the Option Numbers 983 representing the network prefix and the number of Extension No. bits. 984 These enable an ISP to offer a rich mixture of addresses for the 985 subscribers to choose from. 987 G. An address extended by EzIP-4 through EzIP-7 directly connecting 988 an IoT to the Internet could nevertheless be replaced by a private 989 network established through an RG as described at the end of Appendix 990 B. The EzIP-7 can best take advantage of this approach, because the 991 240/4 address block is totally segregated from the three conventional 992 private network pools, thus avoiding confusing the Internet routers. 993 Essentially, the subscribers, appearing as private networks or 994 directly connected IoTs, will interface with the existing Internet 995 through a complete spherical layer of secondary ERs (made of the 996 SPRs) utilizing a never publiclly assigned address pool (240/4). 998 H. In summary, the EzIP technique may expand the current IPv4 public 999 address pool with a wide range of multiplication factors. It may be 1000 256 folds while maintaining the current private network properties 1001 except with reduced size, and from 64K to 256M folds while offering 1002 direct end-to-end connectivity. In addition, multiplication factor of 1003 512M may be achieved. Lastly, the address capacity could even become 1004 1B times of the current 4B pool with fully direct end-to-end 1005 connectivity. However, these last two EzIP manifestations rely on 1006 significant realignments of the current address blocks. In between, 1007 we could have an IPv4 based Internet that can simultaneously support 1008 private networks along with directly accessible IoTs for 1009 interconnectivity and interoperability. 1011 I. Overall, EzIP-7 may be the optimum choice. It utilizes a block of 1012 IPv4 addresses that could not be properly assigned anyway. It needs 1013 only one Option Number. Furthermore, existing private network setups 1014 will remain intact. Essentially, EzIP-7 introduces a new complete 1015 shell of routers (made of the SPRs) that covers the entire current 1016 Internet to expand its address capacity by 256M fold uniformly, with 1017 minimum disturbance to the current Internet components and 1018 operations. 1020 6. Security Considerations 1022 The EzIP solution is based on an inline module called SPR that 1023 intends to be as transparent to the Internet traffic as possible. 1024 Thus, no overall system security degradation is expected. 1026 7. IANA Considerations 1028 This draft does not create a new registry nor does it register any 1029 values in existing registries; no IANA action is required. 1031 8. Conclusions 1033 This draft RFC describes an enhancement to IPv4 operation utilizing 1034 the IP header Option mechanism. Because the design criterion is to 1035 enhance IPv4 by extending instead of altering it, the impact on 1036 already in-place routers and security mechanisms is minimized. 1038 To resolve the IPv4 public address pool exhaustion issue, a technique 1039 called EzIP (phonetic for Easy IPv4) making use of reserved address 1040 blocks is proposed. 1042 The basic EzIP intention is to maintain the existing private network 1043 configuration. On the other hand, if an Extension No. for EzIP is 1044 chosen from the very end of a 32 bit reserved address, leading to no 1045 address bit available to assign on the resultant sub-network, the IoT 1046 being served becomes directly accessible from any remote device in 1047 the Internet. An IoT may communicate through the Internet with either 1048 type of the connectivity, depending on which type of extension 1049 address its owner wishes to subscribe and to utilize. 1051 The basic EzIP header uses two added words (or 40% overhead) to the 1052 IP header for transporting two octets of an Extension No. To carry 1053 the full four octet EzIP extension address, a third added word is 1054 needed resulting in a 60% overhead. The latter, being a superset of 1055 the former, may be used for all EzIP cases if the extra 20% overhead 1056 is tolerated for cases when the larger capacity is not necessary. 1058 At the extreme end of the spectrum, the EzIP scheme could be 1059 configured to support an IPv4 compatible pool of up to 4BB addresses 1060 with full direct end-to-end connectivity. 1062 Last but not the least, the "RESERVED for Future use" 240/4 block may 1063 be re-classified as the fourth reusable private network pool that is 1064 only used by the SPR as the EzIP extension address. This pool can 1065 multiply each current IPv4 public address by 256M times based on only 1066 one Option Number, while all existing subscriber premises setups 1067 (private networks as well as directly connected IoTs) may remain 1068 unchanged. This manifestation of EzIP technique may be the optimal 1069 solution to our needs. 1071 9. References 1073 9.1. Normative References 1075 (None) 1077 9.2. Informative References 1079 [1] https://nishithsblog.files.wordpress.com/2014/04/internet-of- 1080 things-market-forecast.jpg 1082 [2] http://stats.labs.apnic.net/ipv6 1084 [3] https://ams-ix.net/technical/statistics/sflow-stats/ether-type 1086 [4] http://www.avinta.com/phoenix-1/home/IETF-Draft-ExIP.pdf 1088 [5] https://tools.ietf.org/html/draft-chimiak-enhanced-ipv4-03 1090 [6] https://tools.ietf.org/html/rfc793 1092 [7] https://www.ietf.org/rfc/rfc2131.txt 1094 [8] https://tools.ietf.org/html/rfc791 1096 [9] https://tools.ietf.org/html/rfc1385 1098 [10] http://www.iana.org/assignments/ip-parameters/ip- 1099 parameters.xhtml 1101 [11] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.477.19 1102 42&rep=rep1&type=pdf 1104 [12] https://tools.ietf.org/html/rfc862 1106 [13] https://tools.ietf.org/html/rfc2928 1108 [14] http://www.iana.org/assignments/ipv4-address-space/ipv4- 1109 address-space.xhtml 1111 10. Acknowledgments 1113 The authors would express their deep appreciation to Dr. W. Chimiak 1114 for the enlightening discussions about his team's efforts and 1115 experiences through the EnIP development. 1117 This document was prepared using 2-Word-v2.0.template.dot. 1119 Appendix A EzIP System Architecture 1121 A.1. EzIP System Part A 1123 The EzIP-1 and EzIP-4 portions of the EzIP system has already been 1124 shown as Figure 9 in the main body of this Draft document. 1126 A.2. EzIP System Part B 1128 The EzIP-2 portion maintains private network operation 1129 characteristics, while EzIP-5 portion delivers end-to-end 1130 connectivity. 1132 +------+ 1133 Web Server | WS0z | 1134 +--+---+ 1135 |69.41.190.145 1136 | 1137 | +-----+ 1138 +--+ ER0 | 1139 +--+--+ 1140 | 1141 +------+-------+ 1142 +-------+ Internet +--------+ 1143 | |(Core Routers)| | 1144 +--+--+ +--------------+ +--+--+ 1145 +-----+ ER2 | +-----+ ER5 | 1146 | +-----+ | +-----+ 1147 EzIP-2 |69.41.190.120 EzIP-5 |69.41.190.158 1148 +--+--+ +--+--+ 1149 +-----------+ +-------+ +---------+ +------+ 1150 | +-----+ SPR2| | | +-----+ SPR5+--+ | 1151 | | +-----+ | | | +-----+ | | 1152 | | ................. | |...| |...| 1153 172.16.1.0 |172.16.2.0 172.31.240.0 | | +---------+ | 1154 +--+--+ | | | | 1155 +---+ RG2 +--+ 172.16.1.0 | | 172.31.255.255 1156 | +-----+ | | | 1157 | Premises 2 | +----------+ | 1158 | | | Premises 5 | 1159 |172.16.2.3 |172.16.2.9 |172.16.5.10 |172.16.5.40 1160 +--+--+ +--+--+ +--+--+ +--+--+ 1161 | T2a | .... | T2z | | T5a | ....... | T5z | 1162 +-----+ +-----+ +-----+ +-----+ 1164 Figure 16 EzIP System Architecture-B (172.16/12 Portion) 1166 A.3. EzIP System Part C 1168 The EzIP-3 portion maintains private network operation 1169 characteristics, while EzIP-6 portion delivers end-to-end 1170 connectivity. 1172 +------+ 1173 Web Server | WS0z | 1174 +--+---+ 1175 |69.41.190.145 1176 | 1177 | +-----+ 1178 +--+ ER0 | 1179 +--+--+ 1180 | 1181 +------+-------+ 1182 +-------+ Internet +--------+ 1183 | |(Core Routers)| | 1184 +--+--+ +--------------+ +--+--+ 1185 +-----+ ER3 | +-----+ ER6 | 1186 | +-----+ | +-----+ 1187 | | 1188 EzIP-3 |69.41.190.130 EzIP-6 |69.41.190.160 1189 +--+--+ +--+--+ 1190 +-----------+ +-------+ +---------+ +------+ 1191 | +-----+ SPR3| | | +-----+ SPR6+--+ | 1192 | | +-----+ | | | +-----+ | | 1193 | ... | ................. | | | | | 1194 | | | |...| |...| 1195 10.1.0.0 |10.3.0.0 10.255.0.0 | | +---------+ | 1196 +--+--+ | | | | 1197 +---+ RG3 +--+ 10.1.0.0 | | 10.255.255.255 1198 | +-----+ | | | 1199 | Premises 3 | +----------+ | 1200 | | | Premises 6 | 1201 |10.3.0.3 |10.3.255.9 |10.6.0.10 |10.6.0.40 1202 +--+--+ +--+--+ +--+--+ +--+--+ 1203 | T3a | .... | T3z | | T6a | ....... | T6z | 1204 +-----+ +-----+ +-----+ +-----+ 1206 Figure 17 EzIP System Architecture-C (10/8 Portion) 1208 A.4. EzIP System Part D 1210 Utilizing 240/4, the EzIP provides a "spherical shell" of routable 1211 addresses wrapped around the entire current Internet (CRs and ERs), 1212 separating it from the subscribers' IoTs that are either directly 1213 addressable from the Internet such as T7z, T8z, or protected behind 1214 existing private networks like RG7, RG8. 1216 +------+ 1217 Web Server | WS0z | 1218 +--+---+ 1219 |69.41.190.145 1220 | 1221 | +-----+ 1222 +--+ ER0 | 1223 +--+--+ 1224 | 1225 +------+-------+ 1226 ER1 ------+ +----- ER4 1227 Interconnect | | 1228 with ER2 ------+ Internet +----- ER5 1229 Preceding | | 1230 Figures ER3 ------+(Core Routers)+----- ER6 1231 | | 1232 +-------+ +--------+ 1233 | | | | 1234 +--+--+ +--------------+ +--+--+ 1235 +-----+ ER7 | +-----+ ER8 | 1236 | +-----+ | +-----+ 1237 | | 1238 |69.41.190.170 |69.41.190.180 1239 +--+--+ +--+--+ 1240 +-----------+ +-------+ +---------+ +------+ 1241 | +-----+ SPR7+--+ |EzIP-7 | +-----+ SPR8+--+ | 1242 | ... | +-----+ |... | | | +-----+ | | 1243 | | +--------+ | |...| |...| 1244 240.0.0.1 | | 255.255.255.255 | | +---------+ | 1245 | | | | | | 1246 +------+ | 240.0.0.1 | | 255.255.255.255 1247 | Premises 7 | +----------+ | 1248 | | | Premises 8 | 1249 |247.0.0.3 |247.0.0.9 |248.0.0.10 |248.0.0.40 1250 +--+--+ +--+--+ +--+--+ +--+--+ 1251 | RG7 | .... | T7z | | T8z | ....... | RG8 | 1252 +-----+ +-----+ +-----+ +-----+ 1254 Figure 18 EzIP System Architecture-D (240/4 Portion) 1256 +--------------------------+-----------------+----------------+ 1257 | | Basic IPv4 | EzIP-capable | 1258 +--------------------------+-----------------+----------------+ 1259 | | ER0, ER1, ER2, | ------------ | 1260 | Internet Edge Router (ER)| ER3, ER4, ER5, | | 1261 | | ER6, ER7, ER8 | | 1262 +--------------------------+-----------------+----------------+ 1263 | | T1a, T2a, T3a, | T1z, T2z, T3z, | 1264 | Internet of Things (IoT) | T4a, T5a, T6a, | T4z, T5z, T6z, | 1265 | | | T7z, T8z | 1266 +--------------------------+-----------------+----------------+ 1267 | | RG1, RG2, RG3 | | 1268 | Routing Gateway (RG) | RG7, RG8 | ------------ | 1269 +--------------------------+-----------------+----------------+ 1270 | | ------------- | SPR1, SPR2, | 1271 | Semi-Public Router (SPR) | | SPR3, SPR4, | 1272 | | | SPR5, SPR6, | 1273 | | | SPR7, SPR8 | 1274 +--------------------------+-----------------+----------------+ 1275 | Web Server (WS) | ------------- | WS0z | 1276 +--------------------------+-----------------+----------------+ 1278 Note: WS0z could be either a collection of conventional web servers 1279 connected to the Internet via a SPR, with message transfer capability 1280 among themselves, or a new web sever with multiple modules that 1281 recognize and re-direct packets depending on its header type 1282 (conventional IP or EzIP). The main path functions the same as 1283 existing web servers. The secondary servers are at EzIP extension 1284 addresses that may be directly accessed by packets with EzIP header, 1285 or receive packets forwarded by the main module upon being qualified. 1287 Figure 19 EzIP System Components 1289 Appendix B EzIP Operation 1291 To demonstrate how EzIP could support and enhance the Internet 1292 operations, the following are three connection examples that involve 1293 SPRs as shown in Figure 9. These present a general perspective of how 1294 IP header transitions through the routers may look like. 1296 A. The first example is between EzIP-unaware IoTs, T1a and T4a. This 1297 operation is very much like the conventional TCP/IP packet 1298 transmission except with SPRs acting as an extra pair of routers 1299 supported by CGNAT. In addition, SPR4 may be viewed as a full-fledged 1300 RG minus DHCP and NAT support, because it assigns its IoTs with 1301 static addresses from the entire range of reserved 192.168/16, 1302 instead of the common much smaller pool of 192.168.nnn/24. 1304 B. The second one is between EzIP-capable IoTs, T1z and T4z. Here, 1305 the SPRs process the extended public IP addresses in router mode, 1306 avoiding the delays due to the NAT type of operations above. 1308 C. The last one is between EzIP-unaware and EzIP-capable IoTs. By 1309 initiating and responding with a conventional IP header, T1z and T4z 1310 behave like an EzIP-unaware IoT. Thus, all packet exchanges use the 1311 conventional IP headers, just like case A. above. 1313 B.1. Connection between EzIP-unaware IoTs 1315 B.1.1. T1a Initiates a Session Request towards T4a 1317 In Figure 20, T1a initiates a session request to SPR4 that serves T4a 1318 by sending an IP packet to RG1. There is no TCP port number in this 1319 IP header yet. 1321 0 1 2 3 1322 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 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 1 |Version|IHL (5)|Type of Service| Total Length (20) | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 2 | Identification |Flags| Fragment Offset | 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 3 | Time to Live | Protocol | Header Checksum | 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 4 | Source Host Number (192.168.1.3) | 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 5 | Destination Host Number (69.41.190.148) | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 Figure 20 IP Header: From T1a to RG1 1337 B.1.2. RG1 Forwards the Packet to SPR1 1339 In Figure 21, RG1, allowing be masqueraded by T1a, relays the 1340 packet toward SPR1 by assigning the TCP Source port number, 3N, to 1341 T1a. Note that the suffix "N" denotes the actual TCP port number 1342 assigned by the RG1's NAT. This could assume multiple values, each 1343 represents a separate communications session that T1a is engaged in. 1344 A corresponding entry is created in the state table for handling the 1345 responding packet from the Destination site. Since T4a's TCP port 1346 number is not known yet, it is filled with all 1's. 1348 0 1 2 3 1349 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 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 1 |Version|IHL (5)|Type of Service| Total Length (24) | 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1353 2 | Identification |Flags| Fragment Offset | 1354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1355 3 | Time to Live | Protocol | Header Checksum | 1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1357 4 | Source Host Number (192.168.1.0) | 1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 5 | Destination Host Number (69.41.190.148) | 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 6 | Source Port (3N) | Destination Port (All 1's) | 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1364 Figure 21 TCP/IP Header: From RG1 to SPR1 1366 B.1.3. SPR1 Sends the Packet to SPR4 through the Internet 1368 In Figure 22, SPR1 allowing masqueraded by RG1 (with the Source Host 1369 Number changed to be its own and the TCP port number changed to 1C, 1370 where "C" stands for CGNAT) sends the packet out through the Internet 1371 towards SPR4. The packet traverses through the Internet (ER1, CR and 1372 ER4) utilizing only the basic IP header portion of address 1373 information (words 4 & 5). 1375 0 1 2 3 1376 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 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1378 1 |Version|IHL (5)|Type of Service| Total Length (24) | 1379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1380 2 | Identification |Flags| Fragment Offset | 1381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1382 3 | Time to Live | Protocol | Header Checksum | 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1384 4 | Source Host Number (69.41.190.110) | 1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 5 | Destination Host Number (69.41.190.148) | 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 6 | Source Port (1C) | Destination Port (All 1's) | 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 Figure 22 TCP/IP Header: From SPR1 to SPR4 1393 B.1.4. SPR4 Sends the Packet to T4a 1395 Since the packet has a conventional IP header without Destination TCP 1396 port number, SPR4 would ordinarily drop it due to the CGNAT function. 1397 However, for this example, let's assume that there exists a state- 1398 table that was set up by a DMZ process for redirecting this packet to 1399 T4a with a CGNAT TCP port number 410C (the composite of the third and 1400 the fourth octets, "4.10" of T4a's Extension No.). In Figure 23, SPR4 1401 sends the packet to T4a by constructing the destination address 1402 accordingly. 1404 0 1 2 3 1405 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 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1407 1 |Version|IHL (5)|Type of Service| Total Length (24) | 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 2 | Identification |Flags| Fragment Offset | 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 3 | Time to Live | Protocol | Header Checksum | 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1413 4 | Source Host Number (69.41.190.110) | 1414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1415 5 | Destination Host Number (192.168.4.10) | 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 6 | Source Port (1C) | Destination Port (410C) | 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 Figure 23 TCP/IP Header: From SPR4 to T4a 1422 B.1.5. T4a Replies to SPR4 1424 In Figure 24, when T4a replies to SPR4, it interchanges the Source 1425 and Destination identifications to create an IP header for the reply 1426 packet. 1428 0 1 2 3 1429 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 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 1 |Version|IHL (5)|Type of Service| Total Length (24) | 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1433 2 | Identification |Flags| Fragment Offset | 1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 3 | Time to Live | Protocol | Header Checksum | 1436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1437 4 | Source Host Number (192.168.4.10) | 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1439 5 | Destination Host Number (69.41.190.110) | 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1441 6 | Source Port (410C) | Destination Port (1C) | 1442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 Figure 24 TCP/IP Header: From T4a to SPR4 1446 B.1.6. SPR4 Sends the Packet to SPR1 through the Internet 1448 In Figure 25, SPR4 sends the packet toward SPR1 with the following 1449 header through the Internet (ER4, CR and ER1) who will simply relay 1450 the packet according to the information in word 5 (Destination Host 1451 Number): 1453 0 1 2 3 1454 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 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 1 |Version|IHL (5)|Type of Service| Total Length (24) | 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 2 | Identification |Flags| Fragment Offset | 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 3 | Time to Live | Protocol | Header Checksum | 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1462 4 | Source Host Number (69.41.190.148) | 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 5 | Destination Host Number (69.41.190.110) | 1465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1466 6 | Source Port (410C) | Destination Port (1C) | 1467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1469 Figure 25 TCP/IP Header: From SPR4 to SPR1 1471 B.1.7. SPR1 Sends the Packet to RG1 1473 In Figure 26, RG1 address is reconstructed by using the information 1474 in the CGNAT state-table stored in SPR1. 1476 0 1 2 3 1477 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 1478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1479 1 |Version|IHL (5)|Type of Service| Total Length (24) | 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1481 2 | Identification |Flags| Fragment Offset | 1482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1483 3 | Time to Live | Protocol | Header Checksum | 1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 4 | Source Host Number (69.41.190.148) | 1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1487 5 | Destination Host Number (192.168.1.0) | 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 6 | Source Port (410C) | Destination Port (3N) | 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 Figure 26 TCP/IP Header: From SPR1 to RG1 1494 B.1.8. RG1 Forwards the Packet to T1a 1496 In Figure 27, T1a address is reconstructed from that of RG1 and the 1497 state-table in the NAT based on Destination Port (3N). 1499 0 1 2 3 1500 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 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 1 |Version|IHL (5)|Type of Service| Total Length (24) | 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1504 2 | Identification |Flags| Fragment Offset | 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 3 | Time to Live | Protocol | Header Checksum | 1507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1508 4 | Source Host Number (69.41.190.148) | 1509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1510 5 | Destination Host Number (192.168.1.3) | 1511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1512 6 | Source Port (410C) | Destination Port (3N) | 1513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 Figure 27 TCP/IP Header: From RG1 to T1a 1517 B.1.9. T1a Sends a Follow-up Packet to RG1 1519 To carry on the communication, T1a in Figure 28 sends the follow-up 1520 packet to RG1 with a full TCP/IP header. 1522 0 1 2 3 1523 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 1524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 1 |Version|IHL (5)|Type of Service| Total Length (24) | 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 2 | Identification |Flags| Fragment Offset | 1528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 3 | Time to Live | Protocol | Header Checksum | 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1531 4 | Source Host Number (192.168.1.3) | 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 5 | Destination Host Number (69.41.190.148) | 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1535 6 | Source Port (3N) | Destination Port (410C) | 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1538 Figure 28 TCP/IP Header: Follow-up Packets From T1a to RG1 1540 B.2. Connection Between EzIP-capable IoTs 1542 The following is an example of EzIP operation between T1z and T4z 1543 shown in Figure 9. Each knows its own full "Public - EzIP : Private" 1544 network addresses, "69.41.190.110-192.168.1.0:9" and "69.41.190.148- 1545 192.168.4.40", respectively, as well as the other's. Note that T4z 1546 full address does not have the IoT No. portion. It is directly 1547 addressable from the Internet. 1549 B.2.1. T1z Initiates a Session Request towards T4z 1551 T1z initiates a session request to T4z by sending an EzIP packet to 1552 RG1. There is no TCP port number word, because T4z does not have such 1553 and that for T1z has not been assigned by the RG1's NAT. 1555 0 1 2 3 1556 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 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1558 1 |Version|IHL (7)|Type of Service| Total Length (28) | 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1560 2 | Identification |Flags| Fragment Offset | 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 3 | Time to Live | Protocol | Header Checksum | 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 4 | Source Host Number (192.168.1.9) | 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 5 | Destination Host Number (69.41.190.148) | 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 | EzIP ID | EzIP | Extended | No | 1569 6 | (Source) | Option Length | Source | Operation | 1570 | (0X9B) | (3) | No. (1) | (00000001) | 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 | EzIP ID | EzIP | Extended | Extended | 1573 7 | (Destination) | Option Length | Destination | Destination | 1574 | (0X9A) | (4) | No. (4) | No. (40) | 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1577 Figure 29 EzIP Header: From T1z to RG1 1579 Note that 0X9A and 0X9B are temporarily selected from the available 1580 "IP Option Numbers" [10]. They were employed by prior efforts to 1581 facilitate the presentation of, EnIP and ExIP, respectively. These 1582 convey the concepts of transporting the value of the "Network No." as 1583 well as the number of octets needed in the "Extension No.". That is, 1584 both Option Numbers represent 192.168/16 as the EzIP Network No. 1585 prefix, while individually conveys two or one octets used in the 1586 Extension No., respectively. 1588 B.2.2. RG1 Forwards the Packet to SPR1 1590 In Figure 30, RG1, allowing to be masqueraded by T1z, relays the 1591 packet toward SPR1 by assigning the TCP Source port number, 9N, to 1592 T1z. Since T4z is directly connected to the Internet, there is no 1593 private network information to fill the Destination portion of the 1594 TCP word. 1596 0 1 2 3 1597 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 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1599 1 |Version|IHL (7)|Type of Service| Total Length (32) | 1600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1601 2 | Identification |Flags| Fragment Offset | 1602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 3 | Time to Live | Protocol | Header Checksum | 1604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 4 | Source Host Number (192.168.1.0) | 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 5 | Destination Host Number (69.41.190.148) | 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 | EzIP ID | EzIP | Extended | No | 1610 6 | (Source) | Option Length | Source | Operation | 1611 | (0X9B) | (3) | No. (1) | (00000001) | 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 | EzIP ID | EzIP | Extended | Extended | 1614 7 | (Destination) | Option Length | Destination | Destination | 1615 | (0X9A) | (4) | No. (4) | No. (40) | 1616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1617 8 | Source Port (9N) | Destination Port (All 1's) | 1618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 Figure 30 TCP/EzIP Header: From RG1 to SPR1 1622 B.2.3. SPR1 Sends the Packet to SPR4 through the Internet 1624 In Figure 31, SPR1 sends the packet out into the Internet towards 1625 SPR4. The packet traverses through the Internet (ER1, CR and ER4), 1626 utilizing only the basic IP header portion of address information. 1627 Note that the third octet of word 6 plus the first two octets of word 1628 8 make up the subnet address of T1z. And, the last two octets of word 1629 7 represent the extended address of T4z. 1631 0 1 2 3 1632 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 1633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1634 1 |Version|IHL (7)|Type of Service| Total Length (32) | 1635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1636 2 | Identification |Flags| Fragment Offset | 1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 3 | Time to Live | Protocol | Header Checksum | 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 4 | Source Host Number (69.41.190.110) | 1641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1642 5 | Destination Host Number (69.41.190.148) | 1643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1644 | EzIP ID | EzIP | Extended | No | 1645 6 | (Source) | Option Length | Source | Operation | 1646 | (0X9B) | (3) | No. (1) | (00000001) | 1647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1648 | EzIP ID | EzIP | Extended | Extended | 1649 7 | (Destination) | Option Length | Destination | Destination | 1650 | (0X9A) | (4) | No. (4) | No. (40) | 1651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1652 8 | Source Port (9N) | Destination Port (All 1's) | 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1655 Figure 31 TCP/EzIP Header: From SPR1 to SPR4 1657 B.2.4. SPR4 Sends the Packet towards T4z 1659 In Figure 32, SPR4 sends the packet to T4z by reconstructing its 1660 address from the Option number and the Extended Destination No. 1662 0 1 2 3 1663 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 1664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1665 1 |Version|IHL (7)|Type of Service| Total Length (32) | 1666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1667 2 | Identification |Flags| Fragment Offset | 1668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1669 3 | Time to Live | Protocol | Header Checksum | 1670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1671 4 | Source Host Number (69.41.190.110) | 1672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1673 5 | Destination Host Number (192.168.4.40) | 1674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1675 | EzIP ID | EzIP | Extended | No | 1676 6 | (Source) | Option Length | Source | Operation | 1677 | (0X9B) | (3) | No. (1) | (00000001) | 1678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1679 | EzIP ID | EzIP | Extended | Extended | 1680 7 | (Destination) | Option Length | Destination | Destination | 1681 | (0X9A) | (4) | No. (4) | No. (40) | 1682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 8 | Source Port (9N) | Destination Port (All 1's) | 1684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1686 Figure 32 TCP/EzIP Header: From SPR4 to T4z 1688 B.2.5. T4z Replies to SPR4 1690 In Figure 33, T4z replies to SPR4 with the full T1z identification 1691 (69.41.190.110-192.68.1.0:192.168.1.9N conveyed by Option ID 0X9B 1692 together with the compact address string 69.41.190.110-1:9N) to 1693 create an EzIP header for the reply packet. 1695 0 1 2 3 1696 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 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1698 1 |Version|IHL (7)|Type of Service| Total Length (32) | 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 2 | Identification |Flags| Fragment Offset | 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 3 | Time to Live | Protocol | Header Checksum | 1703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1704 4 | Source Host Number (192.168.4.40) | 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 5 | Destination Host Number (69.41.190.110) | 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 | EzIP ID | EzIP | Extended | Extended | 1709 6 | (Source) | Option Length | Source | Source | 1710 | (0X9A) | (4) | No. (4) | No. (40) | 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1712 | EzIP ID | EzIP | Extended | End of | 1713 7 | (Destination) | Option Length | Destination | Option | 1714 | (0X9B) | (3) | No. (1) | (00000000) | 1715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 8 | Source Port (All 1's) | Destination Port (9N) | 1717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1719 Figure 33 TCP/EzIP Header: From T4z to SPR4 1721 B.2.6. SPR4 Sends the Packet to SPR1 through the Internet 1723 In Figure 34, SPR4 sends the packet toward SPR1 with the following 1724 header through the Internet (ER2, CR, and ER1) who will simply relay 1725 the packet according to the information in word 5 (Destination Host 1726 Number): 1728 0 1 2 3 1729 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 1730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1731 1 |Version|IHL (7)|Type of Service| Total Length (32) | 1732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1733 2 | Identification |Flags| Fragment Offset | 1734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1735 3 | Time to Live | Protocol | Header Checksum | 1736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1737 4 | Source Host Number (69.41.190.148) | 1738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1739 5 | Destination Host Number (69.41.190.110) | 1740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1741 | EzIP ID | EzIP | Extended | Extended | 1742 6 | (Source) | Option Length | Source | Source | 1743 | (0X9A) | (4) | No. (4) | No. (40) | 1744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1745 | EzIP ID | EzIP | Extended | End of | 1746 7 | (Destination) | Option Length | Destination | Option | 1747 | (0X9B) | (3) | No. (1) | (00000000) | 1748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1749 8 | Source Port (All 1's) | Destination Port (9N) | 1750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1752 Figure 34 TCP/EzIP Header: From SPR4 to SPR1 1754 B.2.7. SPR1 Sends the Packet to RG1 1756 In Figure 35, RG1 address is reconstructed from the Option number and 1757 the Extended Destination No. 1759 0 1 2 3 1760 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 1761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1762 1 |Version|IHL (7)|Type of Service| Total Length (32) | 1763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1764 2 | Identification |Flags| Fragment Offset | 1765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1766 3 | Time to Live | Protocol | Header Checksum | 1767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1768 4 | Source Host Number (69.41.190.148) | 1769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1770 5 | Destination Host Number (192.168.1.0) | 1771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1772 | EzIP ID | EzIP | Extended | Extended | 1773 6 | (Source) | Option Length | Source | Source | 1774 | (0X9A) | (4) | No. (4) | No. (40) | 1775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1776 | EzIP ID | EzIP | Extended | End of | 1777 7 | (Destination) | Option Length | Destination | Option | 1778 | (0X9B) | (3) | No. (1) | (00000000) | 1779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1780 8 | Source Port (All 1's) | Destination Port (9N) | 1781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1783 Figure 35 TCP/EzIP Header: From SPR1 to RG1 1785 B.2.8. RG1 Forwards the Packet to T1z 1787 In Figure 36, T1z address is reconstructed from that of RG1 and the 1788 NAT state-table based on Destination Port (9N). 1790 0 1 2 3 1791 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 1792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1793 1 |Version|IHL (7)|Type of Service| Total Length (32) | 1794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1795 2 | Identification |Flags| Fragment Offset | 1796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1797 3 | Time to Live | Protocol | Header Checksum | 1798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 4 | Source Host Number (69.41.190.148) | 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1801 5 | Destination Host Number (192.168.1.9) | 1802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1803 | EzIP ID | EzIP | Extended | Extended | 1804 6 | (Source) | Option Length | Source | Source | 1805 | (0X9A) | (4) | No. (4) | No. (40) | 1806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1807 | EzIP ID | EzIP | Extended | End of | 1808 7 | (Destination) | Option Length | Destination | Option | 1809 | (0X9B) | (3) | No. (1) | (00000000) | 1810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1811 8 | Source Port (All 1's) | Destination Port (9N) | 1812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1814 Figure 36 TCP/EzIP Header: From RG1 to T1z 1816 B.2.9. T1z Sends a Follow-up Packet to RG1 1818 In Figure 37, T1z sends a follow-up packet to RG1 with all fields 1819 filled with needed information. 1821 0 1 2 3 1822 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 1823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1824 1 |Version|IHL (7)|Type of Service| Total Length (32) | 1825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1826 2 | Identification |Flags| Fragment Offset | 1827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1828 3 | Time to Live | Protocol | Header Checksum | 1829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1830 4 | Source Host Number (192.168.1.9) | 1831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1832 5 | Destination Host Number (69.41.190.148) | 1833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 | EzIP ID | EzIP | Extended | No Op | 1835 6 | (Source) | Option Length | Source | Option | 1836 | (0X9B) | (3) | No. (1) | (00000001) | 1837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1838 | EzIP ID | EzIP | Extended | Extended | 1839 7 | (Destination) | Option Length | Destination | Destination | 1840 | (0X9A) | (4) | No. (4) | No. (40) | 1841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1842 8 | Source Port (9N) | Destination Port (All 1's) | 1843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1845 Figure 37 TCP/EzIP Header: Follow-up Packets from T1z to RG1 1847 B.3. Connection Between EzIP-unaware and EzIP-capable IoTs 1849 B.3.1. T1a initiates a request to T4z 1851 Since T1a can create only IP header with conventional format, the 1852 SPRs will provide CGNAT type of services to the IP packets. And, 1853 assuming SPR4 has a state-table set up by DMZ for forwarding the 1854 request to T4z, the packet will be delivered to T4z. Seeing the 1855 incoming packet using conventional IP header, T4z should respond with 1856 the same so that the session will be conducted with conventional 1857 TCP/IP headers. 1859 B.3.2. T1z initiates a request to T4a 1861 Knowing T4a is not capable of EzIP header, T1z purposely initiates 1862 the request packet using conventional IP header. It will be treated 1863 by SPRs in the same manner as the T1a initiated case above and 1864 recognizable by T4a. 1866 In brief, the steps outlined above are very much the same as the 1867 conventional TCP/IP header transitions between routers, except two 1868 extra steps in each direction are inserted to encode and decode the 1869 additional SPR provided EzIP routing process. 1871 Note that when an IoT, such as T4a or T4z, is directly connected to a 1872 SPR, like SPR4, there is no RG in-between. There is no corresponding 1873 TCP port number in word 8 of the above TCP/EzIP headers. This spare 1874 facility in the header allows an RG be inserted if desired, thus re- 1875 establishing the private network environment. 1877 When only its Extension No. portion of an EzIP extension address is 1878 transported in the EzIP header, the conventional private network 1879 address may be reused in this kind of added private networks. When 1880 extension address is transported by a full TCP/EzIP header with four 1881 octet format, proper precaution must be exercised to avoid confusing 1882 the routers along the way due to the appearance of a full private 1883 network address, although at a location in the IP header ordinarily 1884 not intended for IP address. When EzIP-7 is used, this is not of 1885 concern because the 240/4 block does not belong to the three 1886 conventional private network address blocks. 1888 Appendix C Internet Transition Considerations 1890 To enhance a large communication system like the Internet, it is 1891 important to minimize the disturbance to the existing equipments and 1892 processes due to any needed modification. The basic EzIP plan is to 1893 confine all actionable enhancements within the new SPR module. The 1894 following outlines the considerations for supporting the transition 1895 from the current Internet to the one enhanced by the EzIP technique. 1897 C.1. EzIP Implementation 1899 C.1.1. Introductory Phase: 1901 A. Insert an SPR in front of a web-server that desires to have 1902 additional subnet addresses for offering diversified activities. For 1903 the long term, a new web server may be designed with these two 1904 functional modules combined. 1906 . The first address of a private network address pool, e.g., 1907 192.168.0.0, used by the SPR should be reserved as a DMZ (De- 1908 Militarized Zone) channel directing the initial incoming service 1909 requesting packets to the existing web server. This will maintain the 1910 same operation behavior projected to the general public. 1912 . The additional addresses, up to 192.168.255.255 may be used for 1913 EzIP address extension purposes. Each may be assigned to an 1914 additional web server representing one of the business's new 1915 activities. Each of these new servers will then respond with EzIP 1916 header to messages forwarded from the main server, or be directly 1917 accessed through its EzIP address. 1919 B. Insert an SPR in front of a group of subscribers who are to be 1920 served with the EzIP function. The basic service provided by this SPR 1921 will be the CGNAT equivalent function. This will maintain the same 1922 baseline user experience in accessing the Internet currently. 1924 C. Session initiating packets with basic IPv4 header will be routed 1925 by SPRs to a business's existing server at the currently published 1926 IPv4 public address (discoverable through existing DNS). The server 1927 should respond with the basic IPv4 format as well. Essentially, this 1928 maintains the existing interaction between a user and a web server 1929 within an EzIP-unaware environment. 1931 So far, neither the web-server nor any subscriber's IoTs needs to 1932 be enhanced, because the operations remain pretty much the same as 1933 today's common practice utilizing CGNAT assisted connectivity. See 1934 Appendix B.1. for an example. 1936 D. Upon connected to the main web server, if a customer intentionally 1937 selects one of the new services offered by the primary web-server, 1938 the web-server will ask the customer to confirm the selection. 1940 . If confirmed, implying that the customer is aware of the fact 1941 that his IoT is being served by an SPR, the web server forwards the 1942 request to a branch server for carrying on the communication via an 1943 EzIP address. 1945 . The SPR at the originating side, recognizing the EzIP header 1946 from the web-server, replaces the CGNAT service with the EzIP 1947 routing. 1949 . For all subsequent packets exchanged, the EzIP headers will be 1950 used in either direction. See Appendix B.2. for an example. This will 1951 speed up the transmission throughput performance for the rest of the 1952 session. 1954 C.1.2. New IoT Operation Modes: 1956 A. EzIP-capable IoT will create EzIP header in initiating a session, 1957 to directly reach a specific web-server, instead of the lengthy steps 1958 of going through the DMZ port followed by manually making the 1959 selection from the main web server. This will speed up the initial 1960 handshake process. See Appendix B.2. for an example. 1962 B. To communicate with an EzIP-unaware IoT, an EzIP-capable IoT 1963 should purposely initiate a session with conventional IP header. This 1964 will signal the SPRs to provide just CGNAT type of connection 1965 service. See Appendix B.3. for an example. 1967 C.1.3. End-to-End Operation: 1969 Once EzIP-capable IoTs become common for the general public, direct 1970 communication between any pair of such IoTs will be achievable. An 1971 EzIP-capable IoT, knowing the other IoT's full EzIP address, may 1972 initiate a session by creating an EzIP header that directs the SPRs 1973 to provide EzIP services, bypassing the CGNAT process. See Appendix 1974 B.2. for an example. 1976 C.2. SPR Operation Logic 1978 To support the above scenarios, the SPR should be designed with the 1979 following decision process: 1981 C.2.1. Initiating a Session Request for an IoT or via a RG 1982 If a session request IP packet contains EzIP Option word, it will be 1983 routed forward by SPR accordingly. Otherwise, the SPR provides CGNAT 1984 service by assigning a TCP port number to the packet and allowing the 1985 packet to masquerade with the SPR's own IP address while an entry to 1986 the state (port forward / look-up / hash) table is created in 1987 anticipation of the reply packet. 1989 C.2.2. Receiving a Session Request from the ER 1991 If a received IP packet includes a valid EzIP Option word or port 1992 number, SPR will utilize it to route the packet to an RG or an IoT. 1993 For a packet with plain IP header, it will be routed according to the 1994 Destination Host Number (IP header word 5). 1996 C.3. RG Enhancement 1998 With IPv4 address pool expanded by the EzIP schemes, there will be 1999 sufficient publicly assignable addresses for IoTs wishing to be 2000 directly accessible from the Internet. The existing private networks 2001 may continue their current behavior of blocking session request 2002 packets from the Internet. In-between, another connection mode is 2003 possible. The following describes such an option in the context of 2004 the existing RG operation conventions. 2006 C.3.1. Initiating Session request for an IoT 2008 Without regard to whether the IP header is a conventional one or an 2009 EzIP type, a RG allows a packet to masquerade with the RG's own IP 2010 address by assigning a TCP port number to the packet and creating an 2011 entry to the state (port forward / look-up / hash) table. This is the 2012 same as current NAT practice. 2014 C.3.2. Receiving a packet from the SPR 2016 The "Destination Port" value in the packet is examined: 2018 A. If it matches with an entry in the RG NAT's state-table, the 2019 packet is forward to the corresponding address. This is the same as 2020 the normal NAT processes in a conventional RG. 2022 B. If it matches with the address of an active IoT on the private 2023 network, the packet is assigned with a TCP port number and then 2024 forwarded to that IoT. 2026 Note that there is certain amount of increased security risk with 2027 this added last step, because a match between a guessed destination 2028 identity and the above two lists could happen by chance. To address 2029 this issue, the following proactive mechanism should be incorporated 2030 in parallel: 2032 If the "Destination Port" number is null or does not match with 2033 either of the above cases, the packet is dropped and an alarm state 2034 is activated to monitor for possible ill-intended follow-up attempts. 2035 A defensive mechanism should be triggered when the number of failed 2036 attempts has exceeded the preset threshold within a finite time 2037 interval. 2039 In brief, if the IP header of a session requesting packet indicates 2040 that the sender knows the identity of the desired destination IoT on 2041 a private network, the common RG screening process will be bypassed. 2042 This facilitates the direct end-to-end connection, even in the 2043 presence of the NAT. Note that this process is very much the same as 2044 the AA (Automated Attendant) capability in a PABX telephone switching 2045 system that automatically makes the connection for a caller who 2046 indicates (via proper secondary dialing or the equivalent) knowing 2047 the extension number of the destination party. Such process can 2048 effectively screen out most of the unwanted callers while serves the 2049 acquaintance expeditiously. 2051 Authors' Addresses 2053 Abraham Y. Chen 2054 Avinta Communications, Inc. 2055 142 N. Milpitas Blvd., #148, Milpitas, CA 95035-4401 US 2057 Phone: _+1(408)942-1485 2058 Email: AYChen@Avinta.com 2060 Ramamurthy R. Ati 2061 Avinta Communications, Inc. 2062 142 N. Milpitas Blvd., #148, Milpitas, CA 95035-4401 US 2064 Phone: _+1(408)458-7109 2065 Email: rama_ati@outlook.com