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