idnits 2.17.1 draft-chen-ati-ipv4-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 9 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 6 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 11, 2016) is 2722 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for draft-ietf-wgname-docname - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 1385 (Obsoleted by RFC 6814) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Chen 3 Internet-Draft R. Ati 4 Intended status: Standards Track Avinta Communications Inc. 5 Expires: May 15, 2017 November 11, 2016 7 IPv4 with Adaptive Address Space 8 draft-chen-ati-ipv4-with-adaptive-address-space-00 10 Abstract 12 This document describes a solution to the Internet address depletion 13 issue through the use of an existing Option mechanism that is part of 14 the original IPv4 protocol. This proposal, named EzIP (phonetic for 15 Easy IPv4), discusses the IPv4 public address pool expansion and the 16 Internet system architecture enhancement aspects. It was originated 17 by a study called ExIP (Extended IPv4) analyzing the use of the first 18 available octet (eight bits) in the reserved private network pools 19 (10/8, 172.16/12 and 192.168/16) to achieve a moderate address space 20 expansion factor of 256 by each, while maintaining their familiar 21 operation characteristics. Along the way, a parallel yet similar 22 effort, called EnIP (Enhanced IPv4), was discovered. EnIP fully 23 utilizes the same private network pools to increase the address space 24 by a factor of 17.1M with end-to-end connectivity. EzIP is a 25 superset that proposes one unified format for not only encompassing 26 the considerations of both, but also identifying additional 27 capabilities and flexibilities. For example, EzIP may expand an IPv4 28 address at least by a factor of 256 to as high as 256M without 29 affecting the existing IPv4 public address assignments, while still 30 keeping intact the current private networks for the 256M case if 31 desired. The EzIP is in full conformance with the IPv4 protocol, and 32 supports not only both categories of connectivity, but also their 33 interoperability. The traditional Internet traffic and the IoT 34 operations may coexist simultaneously without perturbing their 35 existing setups, while offering end-users the freedom to choose one 36 or the other. If the IPv4 public pool were reorganized, the 37 assignable pool could be multiplied by 512M or even up to 2B times 38 with end-to-end connectivity. EzIP may be deployed as a firmware 39 enhancement to the Internet edge routers or private network gateways 40 wherever needed, or simply installed as an inline adjunct module 41 between the two, enabling a seamless introduction. The 256M case 42 establishes a spherical layer of routers providing a complete 43 interconnection between the Internet and end-users. This 44 configuration enables the entire current Internet and private 45 networks characteristics to remain intact. These proposed interim 46 facilities would afford IPv6 more time to orderly reach the maturity 47 and the availability levels required for delivering a long-term 48 general service. 50 Requirements Language 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC 2119 [RFC2119]. 56 Status of This Memo 58 This Internet-Draft is submitted in full conformance with the 59 provisions of BCP 78 and BCP 79. 61 Internet-Drafts are working documents of the Internet Engineering 62 Task Force (IETF). Note that other groups may also distribute 63 working documents as Internet-Drafts. The list of current Internet- 64 Drafts is at http://datatracker.ietf.org/drafts/current/. 66 Internet-Drafts are draft documents valid for a maximum of six months 67 and may be updated, replaced, or obsoleted by other documents at any 68 time. It is inappropriate to use Internet-Drafts as reference 69 material or to cite them other than as "work in progress." 71 This Internet-Draft will expire on May 15, 2017. 73 Copyright Notice 75 Copyright (c) 2016 IETF Trust and the persons identified as the 76 document authors. All rights reserved. 78 This document is subject to BCP 78 and the IETF Trust's Legal 79 Provisions Relating to IETF Documents 80 (http://trustee.ietf.org/license-info) in effect on the date of 81 publication of this document. Please review these documents 82 carefully, as they describe your rights and restrictions with respect 83 to this document. Code Components extracted from this document must 84 include Simplified BSD License text as described in Section 4.e of 85 the Trust Legal Provisions and are provided without warranty as 86 described in the Simplified BSD License. 88 Table of Contents 90 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 91 2. EzIP Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 92 2.1. EzIP Numbering Plan . . . . . . . . . . . . . . . . . . . 5 93 2.2. EzIP System Architecture . . . . . . . . . . . . . . . . 9 94 2.3. IP Header with Option Word . . . . . . . . . . . . . . . 12 95 2.4. Examples of Option Mechanism . . . . . . . . . . . . . . 12 96 2.5. Basic EzIP Header . . . . . . . . . . . . . . . . . . . . 13 97 2.6. EzIP Operation . . . . . . . . . . . . . . . . . . . . . 15 98 2.7. Generalizing EzIP Header . . . . . . . . . . . . . . . . 15 99 3. EzIP Deployment Strategy . . . . . . . . . . . . . . . . . . 17 100 3.1. Architecturally . . . . . . . . . . . . . . . . . . . . . 17 101 3.2. Functionally . . . . . . . . . . . . . . . . . . . . . . 18 102 3.3. Permanently . . . . . . . . . . . . . . . . . . . . . . . 18 103 4. Updating Servers to Support EzIP . . . . . . . . . . . . . . 18 104 4.1. Fast Path . . . . . . . . . . . . . . . . . . . . . . . . 18 105 4.2. Connectivity Verification . . . . . . . . . . . . . . . . 19 106 4.3. Domain Name Server (DNS) . . . . . . . . . . . . . . . . 19 107 5. EzIP Enhancements . . . . . . . . . . . . . . . . . . . . . . 19 108 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 109 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 110 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 111 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 23 112 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 113 10.1. Normative References . . . . . . . . . . . . . . . . . . 24 114 10.2. Informative References . . . . . . . . . . . . . . . . . 24 115 Appendix A. EzIP System Architecture . . . . . . . . . . . . . . 25 116 A.1. EzIP System Part A . . . . . . . . . . . . . . . . . . . 25 117 A.2. EzIP System Part B . . . . . . . . . . . . . . . . . . . 26 118 A.3. EzIP System Part C . . . . . . . . . . . . . . . . . . . 26 119 A.4. EzIP System Part D . . . . . . . . . . . . . . . . . . . 27 120 Appendix B. EzIP Operation . . . . . . . . . . . . . . . . . . . 29 121 B.1. Connection between EzIP-unaware IoTs . . . . . . . . . . 30 122 B.2. Connection Between EzIP-capable IoTs . . . . . . . . . . 35 123 B.3. Connection Between EzIP-unaware and EzIP-capable IoTs . . 44 124 Appendix C. Internet Transition Considerations . . . . . . . . . 45 125 C.1. EzIP Implementation . . . . . . . . . . . . . . . . . . . 45 126 C.2. SPR Operation Logic . . . . . . . . . . . . . . . . . . . 47 127 C.3. RG Enhancement . . . . . . . . . . . . . . . . . . . . . 47 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 130 1. Introduction 132 The huge growth in the Internet of Things(IoTs) devices has exploded 133 the demand for IP addresses. It would be useful to have a unique 134 address for each Internet device, such that if desired, any device 135 may call any other. The Internet of Things (IoTs) would also be able 136 to make use of more routable addresses if they were available. 137 Currently, these are not possible with the existing IPv4 facility. 139 By Year 2020, the population and number of IoTs are expected to reach 140 7.6 billion and 50 billion respectively, according to a recent Cisco 141 online paper [Internet-of-Things-Market-Forecast]. 143 The IPv4 dot-decimal address format, consisting of four octets each 144 made of 8 binary bits, results in the maximum number of assignable 145 public addresses of 4.295 billion (calculated by 256 x 256 x 256 x 146 256, to be 4,294,967,296 (decimal exact). Using the binary / 147 shorthand notation of 64K representing 256 x 256 (decimal 65,536), 148 the full IPv4 address pool of 64K x 64K may be expressed as 4,096M, 149 or 4.096B. Clearly, the demand is more than 13 times over the 150 inherent capability available from the supply. 152 IPv6 with 128-bit hexadecimal address format offers a potential 153 solution to this problem, but its global adoption appears to face 154 certain challenges [IPv6], [EtherType]. Network Address and Port 155 Translation (NAPT - commonly known simply as NAT) on private networks 156 together with Carrier Grade NAT (CGNAT) over the Internet have been 157 providing the interim solutions thus far. However, NAT modules slow 158 down routers due to the state-table look-up process. As well, they 159 only allow an Internet session be initiated by their respective own 160 clients, impeding the end-to-end setup requests from remote devices 161 that certain IoT operations desire. 163 If the IPv4 capacity could be expanded to eliminate this address pool 164 deficiency while maintaining the familiar established operation 165 conventions, and perhaps even offers reasonable reserve, the urgency 166 will be relaxed long enough for the IPv6 to mature on its own pace. 168 To increase the Internet public address pool, there have been various 169 proposals in the past. Among them, two recent efforts in particular 170 are referenced by this draft, namely ExIP [ExIP] and EnIP. The ExIP 171 study focuses on reclaiming part of a reserved private network 172 address block, for example the third octet of 192.168/16, to be 173 publicly routable at the edge of the Internet. By making use of this 174 octet as semi-public address, the number of assignable public 175 addresses is increased by a factor of 256 to become 1049B which is 176 more than 20 times of the expected IoTs. This address expansion 177 could be implemented in an inline module called Semi-Public Router 178 (SPR) collocated with the Internet Edge Router (ER). Of course, the 179 size of the resultant private networks will be reduced accordingly. 181 The Enhanced IP (EnIP) [EnhancedIpV4] project proposes to increase 182 the available IPv4 public address space by a factor of 17.1M. Like 183 IPv6, EnIP results in full end-to-end connectivity among the enhanced 184 addresses. The EnIP implementation module, "NAT and EnIPNAT/ 185 translator", replacing existing private network gateway, is very 186 similar to the SPR. 188 EzIP merges these two schemes into one uniform solution. Neither 189 Internet Core (/ backbone) Router (CR), nor private network Routing 190 Gateway (RG) needs to handle the Options added to the resultant IP 191 header, since their designs recognize and preserve this Option 192 mechanism, yet are not programmed to process the specific EzIP 193 information. Even the Edge Routers (ER) may stay unchanged, if the 194 SPR is deployed with the adjunct configuration during the 195 introductory phase. 197 The assignable IPv4 compatible public address pool may be expanded 198 significantly more upon incorporating other available IPv4 resources 199 by the EzIP technique, as discussed in the latter part of this 200 document. 202 The rest of this draft begins with outlining the EzIP numbering plan. 203 A modified IP header called EzIP header is introduced for carrying 204 the EzIP address data in the Option words. The overview of the 205 Internet architecture as the result of being expanded by the EzIP 206 scheme, the EzIP header transitions through various routers and the 207 operation considerations are discussed next, with details presented 208 in Appendices A, B and C, respectively. Utilizing the EzIP approach, 209 a range of possibilities of expanding the publicly assignable IPv4 210 address pool as well as enhancing the Internet operation flexibility 211 are then described. 213 2. EzIP Overview 215 2.1. EzIP Numbering Plan 217 The ExIP technique which is the foundation of the EzIP plan began 218 with making use of the reserved private network address pools in very 219 much the same manner as Private Automatic Branch eXchange (PABX) 220 telephone switching machines utilizing locally assigned "extension 221 numbers" to expand the Public Switched Telephone Network (PSTN) 222 capacity by replicating a public telephone line to multitudes of 223 reusable private telephone numbers, each to identify a local 224 instrument. At the first sight, this may seem odd, because the 225 extension numbers of a PABX belong to a separate set from that of the 226 public telephone numbers, while private network IP address is a 227 specific subset reserved from the overall IPv4 pool that is otherwise 228 all public. However, recognizing that neither of the latter two is 229 allowed to operate in the other's domain suggests that the proposed 230 EzIP numbering system indeed may mirror the telephony case. In fact, 231 the very basic form of the EzIP numbering is to make explicit the 232 familiar subnetting process of 192.168/16 that has been performed 233 routinely by consumer RGs (Residential / Routing Gateways) on 234 residential premises for a long time. 236 To facilitate the following discussions, the 32 bits in a private 237 network address notation are divided into three parts, namely 238 Network, Extension and IoT No.'s as shown in Figure 1 below. 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Network No. - Extension No. : IoT No. | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 Figure 1: EzIP Address Notation (Generic) 248 The number of bits in the Extension No. part determines the 249 multiplication factor to be applied by the EzIP process. The 250 trailing IoT No. bits determine the size of the resultant private 251 network. The Network No. part is the specific binary value of the 252 remaining leading bits (the prefix) identifying an address block that 253 will be reserved from the public IPv4 pool. 255 Following the general concept of subnetting, the unit for expanding 256 an address does not need to be restricted to the boundary of an 257 octet. This allows potentially finer grain resolution. 259 How to utilize the 32 bits leads to tradeoffs among EzIP operation 260 characteristics. For example, maintaining the private network 261 properties or establishing the end-to-end connectivity is just a 262 matter of whether there are bits reserved for the IoT No. 264 This notation may be used to present two general categories of EzIP 265 address expression: 267 a. To retain the private network characteristics, the EzIP 268 subnetting makes use of only the first available octet. For the 269 common three private network address pools, we will have the 270 following: 272 1. In Figure 2, 8 bits are available for IoT No., resulting in 273 private networks each capable of 256 IoTs. 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | 192.168 - Extension No. : IoT No. | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Figure 2: EzIP-1 (8 bits of 192.168/16 semi-publicly addressable 283 2. In Figure 3, 12 bits are available for IoT No., resulting in 284 private networks each capable of 4K IoTs. 286 0 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | 172.16 - Extension No. : IoT No. | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 Figure 3: EzIP-2 (8 bits of 172.16/12 semi-publicly addressable) 294 3. In Figure 4, 16 bits are available for IoT No., resulting in 295 private networks each capable of 64K IoTs. 297 0 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | 10 - Extension No. : IoT No. | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Figure 4: EzIP-3 (8 bits of 10/8 semi-publicly addressable) 305 b. To allow direct access from the Internet, EzIP makes use of all 306 available bits in a reserved private network address as Extension 307 No., leaving no bit for the IoT No. The resultant private 308 network will have no RG, but only one IoT that is directly 309 connected to the Internet. 311 1. In Figure 5, 16 bits are assigned for Extension No., 312 resulting in 64K IoTs directly addressable from the Internet. 314 0 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | 192.168 - Extension No. | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 Figure 5: EzIP-4 (16 bits of 192.168/16 semi-publicly addressable) 322 2. In Figure 6, 20 bits are assigned for Extension No., 323 resulting in 1M IoTs directly addressable from the Internet. 325 0 1 2 3 326 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 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | 172.16 - Extension No. | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Figure 6: EzIP-5 (20 bits of 172.16/12 semi-publicly addressable) 333 3. In Figure 7, 24 bits are assigned for Extension No., 334 resulting in 16M IoTs directly addressable from the Internet. 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | 10 - Extension No. | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 Figure 7: EzIP-6 (24 bits of 10/8 semi-publicly addressable) 344 4. For cross reference purpose, EzIP-1 through EzIP-3 are the 345 same numbering types used by the ExIP study, while EzIP-4 346 through EzIP-6 are used by the EnIP project. 348 5. Figure 8, summarizes the number of possible publicly and 349 privately assignable addresses for each original IPv4 public 350 address under different configurations. 352 +===============+================+==============+ 353 | 192.168/16 | 172.16/12 | 10/8 | 354 ==============+===============+================+==============+ 355 Basic IPv4 | | | | 356 --------------+---------------+----------------+--------------+ 357 Address Bits*| 32 | 32 | 32 | 358 --------------+---------------+----------------+--------------+ 359 Public | 1 | 1 | 1 | 360 Private | 64K | 1M | 16M | 361 ==============+===============+================+==============+ 362 (ExIP) | EzIP-1 | EzIP-2 | EzIP-3 | 363 --------------+---------------+----------------+--------------+ 364 Address Bits* | 40 | 40 | 40 | 365 --------------+---------------+----------------+--------------+ 366 Semi-Public | 256 | 256 | 256 | 367 Private | 256 | 4K | 64K | 368 ==============+===============+================+==============+ 369 (EnIP) | EzIP-4 | EzIP-5 | EzIP-6 | 370 --------------+---------------+----------------+--------------+ 371 Address Bits* | 48 | 52 | 56 | 372 --------------+---------------+----------------+--------------+ 373 Public | 64K | 1M | 16M | 374 Private | 1 | 1 | 1 | 375 ==============+===============+================+==============+ 377 Figure 8: Possible original IPv4 under different configurations 379 6. Notes: 381 1. * -- Effective Overall Public Address Length 383 2. For each Public-Private pair, the numbers of addresses 384 are multiplicative, not additive. 386 2.2. EzIP System Architecture 388 With six basic EzIP expansion types, it is difficult to include them 389 all in one single system architecture diagram. To facilitate the 390 presentation, a partial system diagram covering only the 192.168/16 391 (EzIP-1 and EzIP-4) portion as presented below will be utilized for 392 the discussions that follow. A complete set of system architectural 393 diagrams is presented in Appendix A. Refer to Figure 9 and Figure 10 394 for only the 192.168/16 (EzIP-1 and EzIP-4) portion shown: 396 +------+ 397 Web Server | WS0z | 398 +--+---+ 399 |69.41.190.145 400 | 401 | +-----+ 402 +--+ ER0 | 403 +--+--+ 404 | 405 +------+-------+ 406 +-------+ Internet +--------+ 407 | |(Core Routers)| | 408 +--+--+ +--------------+ +--+--+ 409 +-----+ ER1 | +-----+ ER4 | 410 | +-----+ | +-----+ 411 | | 412 EzIP-1 |69.41.190.110 EzIP-4 |69.41.190.148 413 +--+--+ +--+--+ 414 +-----------+ +-------+ +---------+ +------+ 415 | +-----+ SPR1| | | +-----+ SPR4+--+ | 416 | | +-----+ | | | +-----+ | | 417 | 192.168.2.0 ... 192.168.255.0 | | | | 418 +-----+ |...| |...| 419 |192.168.1.0 | | +---------+ | 420 +--+--+ | | | | 421 +---+ RG1 +--+ 192.168.0.1 | | 192.168.255.255 422 | +-----+ | | | 423 | Premises 1 | +----------+ | 424 | | | Premises 4 | 425 |192.168.1.3 |192.168.1.9 |192.168.4.10 |192.168.4.40 426 +--+--+ +--+--+ +--+--+ +--+--+ 427 | T1a | .... | T1z | | T4a | ....... | T4z | 428 +-----+ +-----+ +-----+ +-----+ 430 Figure 9: EzIP System Architecture-A (192.168/16 Portion) 431 +--------------------------+-----------------+----------------+ 432 | | Basic IPv4 | EzIP-capable | 433 +--------------------------+-----------------+----------------+ 434 | Internet Edge Router (ER)| ER0, ER1, ER4 | ------------ | 435 +--------------------------+-----------------+----------------+ 436 | Internet of Things (IoT) | T1a, T4a | T1z, T4z | 437 +--------------------------+-----------------+----------------+ 438 | Routing Gateway (RG) | RG1 | ------------ | 439 +--------------------------+-----------------+----------------+ 440 | Semi-Public Router (SPR) | ------------- | SPR1, SPR4 | 441 +--------------------------+-----------------+----------------+ 442 | Web Server (WS) | ------------- | WS0z | 443 +--------------------------+-----------------+----------------+ 445 Figure 10: EzIP-1 and EzIP-4 Components 447 The following discussions references the above two figures: 449 a. Referring to the left portion labeled EzIP-1 of Figure 9, instead 450 of assigning each premises a public IPv4 address as in the 451 current practice, an SPR like SPR1, is inserted between an 452 Internet Edge Router (ER1) and its connections to private network 453 Routing Gateways like RG1, for utilizing the third octet as 454 192.168.nnn/24 (nnn = 0 through 255) to identify respective 455 entities. The RG1 serves either a LAN or a HAN. On each LAN / 456 HAN, the fourth octet "mmm" of of 192.168.nnn.mmm/32 continues to 457 be used by the RG1 to identify the IoTs it serves. This is how 458 common RGs are being configured today anyway (Factory default 459 values of nnn are usually 0, 1, 2, 10, etc.) 461 b. The right portion of Figure 9 is labeled EzIP-4. Here SPR4 462 assigns the full range of the available 192.168/16 IP addresses 463 (the third and fourth octets) individually to T4a through T4z. 464 Consequently, these IoTs are directly accessible from any remote 465 device on the Internet. 467 c. Since the existing physical connections to subscriber premises do 468 appear at the ER, it is natural to have SPRs be collocated with 469 their ER. It follows that the simple routing function provided 470 by the new SPR modules may be absorbed into the ER through a 471 straightforward operational firmware enhancement. Consequently, 472 the public - private demarcation line will remain at the RG where 473 currently all utility services enter a subscribers premises. 475 d. To identify each of these devices, we may use a three part 476 address format "Semi-Public: TCP Port No.". The following is how 477 each of the IoTs in Figure 9 may be identified. 479 RG1: 69.41.190.110-192.168.1.0 480 T1a: 69.41.190.110-192.168.1.0:3 481 T1z: 69.41.190.110-192.168.1.0:9 482 T4a: 69.41.190.148-192.168.4.10 483 T4z: 69.41.190.148-192.168.4.40 485 e. Note that to simplify the presentation, it is assumed at this 486 juncture that the conventional TCP (Transmission Control 487 Protocol) [RFC793] Port Number, normally assigned to T1a and T1z 488 by RG1's NAT module upon initiating a session, equals to the 489 fourth octet of that IoTs private IP address that is assigned by 490 the RG1's DHCP (Dynamic Host Configuration Protocol) [RFC2131] 491 module as and ":3" and ":9", respectively. Such numbers are 492 unique within each respective private network. They are adequate 493 for the discussion purpose here. However, considering security, 494 as well as allowing each IoT to have multiple simultaneous 495 sessions, etc., this direct correlation shall be avoided in 496 actual practices by following the NAT operation conventions as 497 depicted by the examples in Appendix B. 499 2.3. IP Header with Option Word 501 To transport the EzIP Extension No., we will make use of the Option 502 word in the IP header as defined in Figure 9 of [RFC791]. This 503 mechanism has been used for various cases in the past. Since they 504 were mostly for utility or experimental purposes, however, their 505 formats may be remote from the incident discussion. 507 2.4. Examples of Option Mechanism 509 The following two cases specifically deal with the address pool 510 issues. They are referenced here to facilitate the appreciation of 511 the Option mechanism. 513 a. Case 1: EIP (Extended Internet Protocol) [RFC1385] (Assigned but 514 now deprecated Option Number = 17) by Z. Wang. This approach 515 attempted to add a new network layer on top of the existing 516 Internet for increasing the addressable space. Although 517 equipment near the end-user would stay unchanged, equipments 518 around the Internet Core Routers (CR) apparently had to go 519 through rather involved upgrade procedures. 521 b. Case 2: EnIP (Enhanced IPv4), [EnhancedIpV4] (temporarily 522 utilizing Option Number = 26 by W. Chimiak). This work makes 523 use of the reserved private network addresses to extend the 524 public pool by trading the private network operation for end-to- 525 end connectivity. The EnIP and ExIP approaches closely resemble 526 each other. 528 2.5. Basic EzIP Header 530 The basic EzIP header format uses the Option ID field to convey the 531 value of the "Network No." as well as the length of the "Extension 532 No.". This header has the capacity to handle up to two octets of the 533 "Extension No." on either end of a connection. Refer to Figure 11. 535 0 1 2 3 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 1 |Version|IHL (7)|Type of Service| Total Length (28) | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 2 | Identification |Flags| Fragment Offset | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 3 | Time to Live | Protocol | Header Checksum | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 4 | Source Host Number | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 5 | Destination Host Number | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | EzIP ID | EzIP | Extended | Extended | 549 6 | (Source) | Option Length | Source | Source | 550 | (------) | (4) | No.-1 | No.-2 | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | EzIP ID | EzIP | Extended | Extended | 553 7 | (Destination) | Option Length | Destination | Destination | 554 | (------) | (4) | No.-1 | No.-2 | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 Figure 11: Basic EzIP Header (Two Octet) 559 For transporting an IP header for T4z at the Source end and RG1 at 560 the Destination end, Figure 12 depicts an EzIP header example: 562 0 1 2 3 563 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 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 1 |Version|IHL (7)|Type of Service| Total Length (28) | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 2 | Identification |Flags| Fragment Offset | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 3 | Time to Live | Protocol | Header Checksum | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 4 | Source Host Number (69.41.190.148) | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 5 | Destination Host Number (69.41.190.110) | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | EzIP-4 | EzIP | Extended | Extended | 576 6 | (Source) | Option Length | Source | Source | 577 | (0X9A) | (4) | No. (4) | No. (40) | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | EzIP-1 | EzIP | Extended | End of | 580 7 | (Destination) | Option Length | Destination | Option List | 581 | (0x9B) | (3) | No. (1) | (00000000) | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 Figure 12: EzIP Header Example 1 586 Note that the Option IDs 0x9A (Option Number = 26) and 0x9B (Option 587 Number = 27), both representing Network No. 192.168/16 while 588 conveying the Extension No.'s being two and one octet, respectively, 589 in the above figure, are arbitrarily chosen from the currently 590 available Option Numbers list [IPparameters]. Since RG1 extension 591 No. has only one octet, the "End of Option list" Option is used to 592 fill up word 7. If the transmission direction is reversed, types of 593 EzIP extension used by the Source and the Destination will be 594 interchanged as well. The unused octet will now be at the end of 595 word 6. The "No Operation" Option should be used as the filler shown 596 in Figure 13. 598 0 1 2 3 599 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 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 1 |Version|IHL (7)|Type of Service| Total Length (28) | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 2 | Identification |Flags| Fragment Offset | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 3 | Time to Live | Protocol | Header Checksum | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 4 | Source Host Number 69.41.190.110) | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 5 | Destination Host Number (69.41.190.148) | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | EzIP ID | EzIP | Extended | No | 612 6 | (Source) | Option Length | Source | Operation | 613 | (0X9B) | (3) | No. (1) | (00000001) | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | EzIP ID | EzIP | Extended | Extended | 616 7 | (Destination) | Option Length | Destination | Destination | 617 | (0x9A) | (4) | No. (4) | No. (40) | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 Figure 13: EzIP Header Example 2 622 2.6. EzIP Operation 624 It would be very tedious and distracting to go through half a dozen 625 of EzIP types, covering all combinations of IP header configurations 626 and their transitions through the network. To better convey the 627 general scheme, Appendix B presents examples of EzIP header 628 transitions through routers among IoTs having EzIP-1 and EzIP-4 types 629 of addresses, with and without EzIP capability. To introduce the 630 EzIP approach into an environment where EzIP-unaware IoTs like T1a 631 and T4a will be numerous for a long time to come, a SPR must be able 632 to follow certain decision rules to determine which type of service 633 to provide for achieving a smooth transition. Appendix C outlines 634 such logic and related considerations 636 2.7. Generalizing EzIP Header 638 a. The basic EzIP header shown in Figure 11 with up to two octet 639 Extension No. format is not capable of EzIP-5 and EzIP-6 types 640 with 20 and 24 bit, respectively. One extra octet is needed on 641 each end of a connection. An additional word in the header, 642 however, will have only two octets unused. To take advantage of 643 this spare resource, we might as well consider a header format 644 shown in Figure 14 that can transport the full 4 octet (32 bit) 645 extension addresses of both ends. This is similar as the EnIP 647 [EnhancedIpV4] header, except more flexible by allowing EzIP type 648 being independent of that at the other end. 650 0 1 2 3 651 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 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 1 |Version|IHL (8)|Type of Service| Total Length (32) | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 2 | Identification |Flags| Fragment Offset | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 3 | Time to Live | Protocol | Header Checksum | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 4 | Source Host Number | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 5 | Destination Host Number | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | EzIP ID | EzIP | Extended | Extended | 664 6 | (Source) | Option Length | Source | Source | 665 | (0X9A) | (6) | No.-1 | No.-2 | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Extended | Extended | EzIP ID | EzIP | 668 7 | Source | Source | (Destination) | Option Length | 669 | No.-3 | No.-4 | (0X9A) | (6) | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Extended | Extended | Extended | Extended | 672 8 | Destination | Destination | Destination | Destination | 673 | No.-1 | No.-2 | No.-3 | No.-4 | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 Figure 14: Full EzIP Header (Four octet) 678 b. In brief, Figure 12 or Figure 13 with seven words (40% overhead) 679 having two octet capacity is suitable to transport EzIP-1 through 680 EzIP-4 types consisting of one or two octet Extension No. EzIP-5 681 and EzIP-6 require the next IP header size which is eight words 682 (60% overhead) as shown in Figure 14. 684 c. Being a superset, utilizing "No Operation" or "End of Option 685 List" type of fillers, Figure 14 is capable of handling 686 information for EzIP-1 through EzIP-4 just as well. The question 687 then becomes; whether the extra 20% overhead when handling EzIP-1 688 through EzIP-4 headers is tolerable? If so, the single Figure 14 689 format may be used for all EzIP cases. 691 d. With the "Network No." prefixes of the well-know private network 692 addresses all explicitly carried by the IP header of every packet 693 as shown in Figure 14, the Option Number only needs to identify 694 the length of the "Extended No.". Consequently, one Option 695 Number is sufficient to represent EzIP-1 through EzIP-3 that only 696 the first available octet is used for the Extension No. 697 Similarly, one single Option Number representing EzIP-4 through 698 EzIP-6 conveys the condition that all available bits are to be 699 used for Extension No. 701 e. One potential drawback of the full four octet EzIP header is that 702 it may cause Internet routers to intercept a packet for 703 containing a disallowed (private network) IP address, although 704 positioned at a location of the header normally not designated 705 for address information. 707 f. By harmonizing EzIP-4 to EzIP-6 (EnIP) with EzIP-1 to EzIP-3 708 (ExIP) into one common (EzIP) format, enjoying which operating 709 characteristics will simply be the result of a user subscribing 710 to an EzIP address type appropriate for how he wishes to use his 711 IoT. 713 3. EzIP Deployment Strategy 715 Although the eventual goal of the SPR is to support both web server 716 access by IoTs from behind private networks and direct end-to-end 717 connectivity between IoTs, the former application should be addressed 718 first to immediately relieve the basic address shortage issue. Once 719 the IoTs on both ends of an intended connection are served by SPRs, 720 it will be natural to realize the latter 722 3.1. Architecturally 724 Since the design philosophy of the SPR is an inline module between 725 the Internet ER (Edge Router) and the private network RG (Routing 726 Gateway), SPR introduction process may be flexible. 728 a. SPRs may be collocated with ERs to begin providing the CGNAT 729 equivalent function. This may be done immediately without 730 affecting the existing Internet (edge and core) routers. EzIP- 731 capable IoTs will then take advantage of the faster bi- 732 directional routing services through the SPRs by initiating a 733 communication session with an EzIP header. 735 b. Alternatively, a SPR may be deployed as an adjunct module before 736 an existing RG to realize the same EzIP functions on private 737 premises, even if the serving Internet Service Provider (ISP) has 738 not enhanced ERs with the EzIP capability. This empowers 739 individual subscribers to enjoy the new EzIP capability on their 740 own. 742 3.2. Functionally 744 a. First, an ISP should install SPRs in front of business web 745 servers so that new routing branches may be added to support the 746 additional web servers for expanding business activities. 747 Alternatively, this may be achieved by deploying new web servers 748 with the SPR function builtin. 750 b. On the subscriber side, SPRs should be deployed to relieve the 751 public address shortage issue, and to facilitate the access to 752 new web servers. 754 3.3. Permanently 756 a. In the long run, it would be best if SPRs are integrated into ERs 757 by upgrading the latters firmware to minimize the hardware. 758 Appendix C details the considerations in implementing these 759 outlines. 761 4. Updating Servers to Support EzIP 763 Although the IP header Option mechanism utilized by EzIP was defined 764 a long time ago as part of the original IPv4 protocol, it has not 765 been used much in daily traffic. Certain current Internet facilities 766 were thus optimized without considering the Option mechanism. They 767 need be adjusted to provide the same performance to EzIP packets. 768 There are also utility type of servers need be updated to support the 769 longer EzIP address. For example: 771 4.1. Fast Path 773 Internet Core Routers (CRs) are currently optimized to only provide 774 the "fast path" (through hardware line card) routing service to 775 packets without Option word in the IP header. This puts EzIP packets 776 at a disadvantage, because EzIP packets would be put through the 777 "slow path" (processed by CPU's software before giving to the correct 778 hardware line card to forward), resulting in a slower throughput. 779 Since the immediate goal of the EzIP is to ease the address pool 780 exhaustion issue, subscribers not demanding for high performance 781 traffic may be assigned with the facility provided through EzIP. 782 This gives time for Internet routers to update so that EzIP packets 783 with authorized Option numbers will eventually be recognized for 784 receiving the "fast path" service. 786 4.2. Connectivity Verification 788 One frequently used utility for verifying baseline connectivity, 789 commonly referred to as the "PING" function in PC terminology, needs 790 be able to transport the full EzIP address that is longer than the 791 standard 32 bit IPv4 address. There is an example of an upgraded TCP 792 echo server in [RFC862]. 794 4.3. Domain Name Server (DNS) 796 Similarly, the DNS needs to expand its data format to transport the 797 longer IP address created by EzIP. This already can be done under 798 IPv6. Utilizing the experimental IPv6 prefix defined by [RFC2928], 799 EzIP addresses may be transported as standardized AAAA records. 800 These topics are discussed in more detail under the IETF 801 [EnhancedIpV4]. 803 5. EzIP Enhancements 805 To minimize disturbing any assigned addresses, deployed equipment and 806 current operation procedures, etc., the EzIP derivations so far are 807 conducted under the constraint of utilizing only the existing three 808 reserved private network address blocks. Beyond such, there are 809 other possibilities. In the long run, EzIP may significantly expand 810 the current IPv4 public address pool through the employment of such 811 additional resources outlined below: 813 a. In reviewing the IP Option Number assignments [IPparameters], it 814 is discovered that more than a dozen of them are currently 815 available. That is, besides five numbers, 26, 27, 28, 29 and 31 816 that have never been assigned, there are eleven numbers assigned 817 earlier but have been deprecated due to the end of associated 818 experiments. If we take six such numbers, one to represent each 819 of the six EzIP extension types, the EzIP-1 to EzIP-3 cases will 820 multiply the IPv4 public address pool by a factor of 256, 821 individually, or a combined factor of 768, resulting in 822 3,145.728B, or 3.146KB publicly assignable addresses. Similarly, 823 we can use one Option Number for each of the EzIP-4, EzIP-5 and 824 EzIP-6 cases to multiply IPv4 pool by 64K, 1M and 16M (a total of 825 17.1M) fold, respectively, to the combined total of 69.894MB 826 addresses. These capacities are over 63 and 1.4M times of the 827 expected Year 2020 IoTs, respectively. 829 b. EzIP-8: If all Option numbers were made available, each 830 representing one EzIP Network No. prefix, up to 32 private 831 network address blocks, like the 10/8 could be utilized by EzIP. 832 To determine the upper limit of this scenario, let's assume that 833 we could employ 31 additional 10/8 type address blocks, say by 834 re-designating 11/8 through 41/8 as private network blocks. 835 These enable us to expand each existing IPv4 public address by 32 836 x 16M or 512M fold. Since this block of 512M addresses have to 837 be removed from the basic public pool, the resulting total 838 addresses will be (4.096B - 512M) x 512M, or 1,835MB. This is 839 over 35M times of the predicted number of IoTs (50B) by Year 840 2020. It certainly has the capacity to deal with the short- to 841 mid- term public IP address needs. 843 c. The above may be condensed for a more efficient operation. For 844 example, a single 224/3 block contains the same amount of 512M 845 addresses may be chosen upon re-allocation of currently assigned 846 IPv4 public addresses so that just one Option Number may 847 represent it. Now that we have freed up 31 Option numbers, we 848 could allocate up to 31 more /3 address blocks for EzIP operation 849 that provides even more extension address resource. However, 850 this last step will exceed the total capacity of the IPv4 pool. 851 On the other hand, this line of reasoning leads to the next 852 observation. 854 d. EzIP-9: One interesting consequence of the EzIP header in 855 Figure 14 capable of transporting the full 32 bit private network 856 address is that the Extension No. may be as long as practical. 857 That is, we can go to the extreme of reserving only one bit for 858 the Network No., and leaving nothing for the IoT No. With these 859 criteria, the current IPv4 pool may be divided into two halves, 860 reserving one half of it (about 2B addresses) as a private 861 network with prefix equal to "1" as the Network No., and all 862 trailing 31 bits designated as Extension No. Each of the 863 remaining 2B addresses (with prefix equals to "0") of the basic 864 IPv4 pool may then be expanded 2B times through the EzIP process, 865 resulting in a total of 4BB addresses that are IPv4 compatible 866 and capable of full end-to-end connectivity. This is roughly 80M 867 times of the Year 2020 IoTs. 869 e. EZIP7: The following compares various IPv4 public address pool 870 expansion configurations. On the other hand, this full 32 bit 871 EzIP addresses transport facility may be applied to the elusive 872 IPv4 240/4 block (240/8 to 255/8) consisting of 256M addresses 873 that has become "RESERVED for Future use" [AddressSpace] as the 874 result of the historical address assignment evolution. Since 875 this block is not suitable for being used as public address, it 876 might as well be re-classified as an additional (the fourth) 877 reusable private network pool. Then, the SPR may use this block 878 as the extension address pool in the EzIP process. Following 879 this approach, each current IPv4 public address may be multiplied 880 by 256M times based on only one Option Number. Following this 881 approach, each current IPv4 public address may be multiplied by 882 256M times based on only one Option Number. Since the 240/4 883 block could not be used for public addressing, the size of the 884 publicly assignable IPv4 pool has actually been only 3.84B (the 885 difference of 4.096B and 256M). So, the net public addressable 886 pool created from this approach is 983MB (3.84B x 256M), which is 887 over 19.6M times of the expected Year 2020 IoTs. This scheme is 888 very close to EzIP-8. Although half of the capacity, this 889 manifestation has the advantage of circumventing reassignment of 890 public IPv4 addresses. The following compares various IPv4 891 public address pool expansion configurations. Refer to 892 Figure 15. 894 +---+---------+------+--------+---------+----------+-----+---------+ 895 | Extension |Option|Effect. |Expansion|Assignable| SUP/|Connect- | 896 | Scheme | Used | AddBits| Factor | Pub Add | DMD | ivity | 897 +=============+======+========+=========+==========+=====+=========+ 898 | IPv4 Public Address Block Assignments Unchanged | 899 +---+---------+------+--------+---------+----------+-----+---------+ 900 | E | EzIP-1 | 1 | 40 | 256 | 978.69B | 19.6| PrivNet | 901 | x +---------+------+--------+---------+----------+-----+---------+ 902 | I | EzIP-2 | 1 | 40 | 256 | 978.69B | 19.6| PrivNet | 903 | P +---------+------+--------+---------+----------+-----+---------+ 904 | | EzIP-3 | 1 | 40 | 256 | 978.69B | 19.6| PrivNet | 905 +---+---------+------+--------+---------+----------+-----+---------+ 906 | E | EzIP-4 | 1 | 48 | 64K | 244.67KB | 5K |EndToEnd | 907 | n +---------+------+--------+---------+----------+-----+---------+ 908 | I | EzIP-5 | 1 | 52 | 1M | 3.82MB | 77K |EndToEnd | 909 | P +---------+------+--------+---------+----------+-----+---------+ 910 | | EzIP-6 | 1 | 56 | 16M | 61.17MB | 1M |EndToEnd | 911 +---+---------+------+--------+---------+----------+-----+---------+ 912 |EzIP-7(240/4)| 1 | 64 | 256M | 978.69MB | 20M |EndToEnd | 913 +=============+======+========+=========+==========+=====+=========+ 914 | IPv4 Public Address Block Assignments Adjusted | 915 +-------------+------+--------+---------+----------+-----+---------+ 916 | EzIP-8 | | | | | | | 917 | (224/3) | 1| 56 | 512M | 1.84BB | 37M |EndToEnd | 918 +-------------+------+--------+---------+----------+-----+---------+ 919 | EzIP-9 | | | | | | | 920 | (Half of | 1 | 63 | 2B | 4BB | 80M |EndToEnd | 921 | IPv4 Pool) | | | | | | | 922 +=============+======+========+=========+==========+=====+=========+ 924 Figure 15: IPv4 Address Multiplication Factor 926 f. Notes: With reference to above Figure 15 927 1. EzIP-1 through EzIP-7: Assignable Public Addresses calculated 928 with the net basic IPv4 public address pool of 3.823B after 929 removed of the 240/4, 10/8, 172.16/12 and 192.168/16 blocks 930 from the basic 4.096B. 932 2. EzIP-8 and EzIP-9: Assignable Public Addresses calculation 933 started from scratch based on the full IPv4 pool of 4.096B 934 minus only the specific portion used for extension purpose. 936 3. "SUP/DMD": Ratio of EzIP SUPplied publicly assignable 937 addresses to IoT DeManD by Year 2020. 939 4. Each group of EzIP-1 to EzIP-3 and EzIP-4 to EzIP-6 may use 940 only one Option number if "four octet" EzIP headers are used. 942 g. It is important to note that schemes summarized in Figure 15 are 943 not mutually exclusive but mostly complementary. Except the last 944 two cases (EzIP-8 and EzIP-9) that are intend to demonstrate the 945 potential public address sizes by starting from the full 4.096B 946 IPv4 pool ignoring the current assignments and reservations, 947 EzIP-1 through EzIP-7 may be applied to the same public IPv4 948 address since they are distinguished from one another by the 949 Option Numbers representing the network prefix and the number of 950 Extension No. bits. These enable an ISP to offer a rich mixture 951 of addresses for the subscribers to choose from. 953 h. An address extended by EzIP-4 through EzIP-7 directly connecting 954 an IoT to the Internet could nevertheless be replaced by a 955 private network established through an RG as described at the end 956 of Appendix B. The EzIP-7 can best take advantage of this 957 approach, because the 240/4-address block is totally segregated 958 from the three conventional private network pools, thus avoiding 959 confusing the Internet routers. Essentially, the subscribers, 960 appearing as private networks and directly connected IoTs, will 961 interface with a complete spherical layer of secondary ERs (made 962 of the SPRs) that wraps the entire existing Internet within by 963 utilizing a never assigned address pool. 965 i. In summary, the EzIP technique may expand the current IPv4 public 966 address pool with a wide range of multiplication factors. It may 967 be 256 folds while maintaining the current private network 968 properties except with reduced size, and from 64K to 256M folds 969 while offering direct end-to-end connectivity. In addition, 970 multiplication factor of 512M may be achieved with some re- 971 assignments of the IPv4 blocks. Lastly, the address capacity 972 could even become 1B times of the current 4B pool with fully 973 direct end-to-end connectivity. However, these last two EzIP 974 manifestations rely on significant realignments of the current 975 address blocks. In between, we could have an IPv4 based Internet 976 that can simultaneously support private networks along with 977 directly accessible IoTs for interconnectivity and 978 interoperability. 980 j. Overall, EzIP-7 may be the optimum choice. It utilizes a block 981 of IPv4 addresses that could not be assigned as public 982 identifiers anyway. It needs only one Option Number. 983 Furthermore, existing private network setups may remain intact. 984 Essentially, EzIP-7 introduces a new layer of routers (made of 985 the SPRs) that expands the Internet address capacity by 256M fold 986 uniformly, with minimum disturbance to the current Internet 987 operations. 989 6. Security Considerations 991 This document does not introduce any security issues as the EzIP 992 solution is based on an inline module called SPR that intends to be 993 as transparent as possible to the Internet traffic and hence no 994 overall system security degradation is expected. 996 7. IANA Considerations 998 None. 1000 8. Acknowledgements 1002 The authors would express their deep appreciation to Dr. W. Chimiak 1003 for the enlightening discussions about his team's efforts and 1004 experiences through the EnIP development. 1006 9. Conclusions 1008 This draft RFC describes an enhancement to IPv4 operation utilizing 1009 IP header Option mechanism. Because the design criterion is to 1010 enhance IPv4 by extending instead of altering it, the impact on 1011 already in-place routers and security mechanisms is minimized. To 1012 resolve the IPv4 public address pool exhaustion issue, a technique 1013 called EzIP (phonetic for Easy IPv4) making use of the reserved 1014 private network address blocks is proposed. 1016 The basic EzIP intention is to maintain the existing private network 1017 configuration. If an Extension No. for EzIP is chosen from the very 1018 end of the 32 bit reserved private network address, leading to no 1019 address bit available to assign on the resultant network, the IoT 1020 being served is directly accessible from any remote device in the 1021 Internet. An IoT may communicate through the Internet with either 1022 type of the connectivity, depending on which type of extension 1023 address its owner wishes to subscribe and to utilize with. 1025 The basic EzIP header uses two added words (or 40% overhead) to the 1026 IP header for transporting two octets of an Extension No. To carry 1027 the full four octet EzIP extension address, a third added word is 1028 needed resulting in a 60% overhead. The latter, being a superset of 1029 the former, may be used for all EzIP cases if the extra 20% overhead 1030 is tolerable for cases when the larger capacity is not necessary. 1032 At the extreme end of the spectrum, the EzIP scheme could be 1033 configured to support an IPv4 compatible pool of up to 4BB addresses 1034 with full direct end-to-end connectivity. 1036 Last but not the least, the "RESERVED for Future use" 240/4 block may 1037 be re-classified as the fourth reusable private network pool, so that 1038 the SPR may use it as the EzIP extension address. This pool can 1039 multiply each current IPv4 public address by 256M times based on only 1040 one Option Number, while all existing subscriber premises setups 1041 (private networks and directly connected IoTs) may remain unchanged. 1042 This manifestation of EzIP technique may be the optimal solution to 1043 our needs. 1045 10. References 1047 10.1. Normative References 1049 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1050 Requirement Levels", BCP 14, RFC 2119, 1051 DOI 10.17487/RFC2119, March 1997, 1052 . 1054 10.2. Informative References 1056 [AddressSpace] 1057 "IANA IPv4 Address Space Registry", 1058 . 1061 [EnhancedIpV4] 1062 Laboratory for Telecommunication Sciences08, "IPv4 with 64 1063 bit Address Space", 06 2016, . 1066 [EtherType] 1067 AMSix, "Ether Type Distribution", . 1070 [ExIP] Avinta Communications, Inc., "IPv4 with 40 bit Address 1071 Space, draft-ietf-wgname-docname-00", 1072 . 1075 [Internet-of-Things-Market-Forecast] 1076 Nishiths Blog Files Wordpress, "IoT Forecast: Cisco IBSG, 1077 April 2011", 1078 . 1081 [IPparameters] 1082 "Internet Protocol Version 4 (IPv4) Parameters", 1083 . 1086 [IPv6] Stats Labs Apnic, "IPv6 Capable Rate by Country", 1087 . 1089 [RFC1385] "EIP: The Extended Internet Protocol, A Framework for 1090 Maintaining Backward Compatibility", 1091 . 1093 [RFC2131] "Dynamic Host Configuration Protocol", 1094 . 1096 [RFC2928] "Initial IPv6 Sub-TLA ID Assignments", 1097 . 1099 [RFC791] "INTERNET PROTOCOL, DARPA INTERNET PROGRAM, PROTOCOL 1100 SPECIFICATION", . 1102 [RFC793] "TRANSMISSION CONTROL PROTOCOL", 1103 . 1105 [RFC862] "Echo Protocol", . 1107 Appendix A. EzIP System Architecture 1109 A.1. EzIP System Part A 1111 The EzIP-1 and EzIP-4 portions of the EzIP system has already been 1112 shown as Picture 9 in the main body of this Draft document. 1114 A.2. EzIP System Part B 1116 The EzIP-2 portion maintains private network operation 1117 characteristics, while EzIP-5 portion delivers end-to-end 1118 connectivity as shown in Figure 16. 1120 +------+ 1121 Web Server | WS0z | 1122 +--+---+ 1123 |69.41.190.145 1124 | 1125 | +-----+ 1126 +--+ ER0 | 1127 +--+--+ 1128 | 1129 +------+-------+ 1130 +-------+ Internet +--------+ 1131 | |(Core Routers)| | 1132 +--+--+ +--------------+ +--+--+ 1133 +-----+ ER2 | +-----+ ER5 | 1134 | +-----+ | +-----+ 1135 EzIP-2 |69.41.190.120 EzIP-5 |69.41.190.158 1136 +--+--+ +--+--+ 1137 +-----------+ +-------+ +---------+ +------+ 1138 | +-----+ SPR2| | | +-----+ SPR5+--+ | 1139 | | +-----+ | | | +-----+ | | 1140 | | ................. | |...| |...| 1141 172.16.1.0 |172.16.2.0 172.31.240.0 | | +---------+ | 1142 +--+--+ | | | | 1143 +---+ RG2 +--+ 172.16.1.0 | | 172.31.255.255 1144 | +-----+ | | | 1145 | Premises 2 | +----------+ | 1146 | | | Premises 5 | 1147 |172.16.2.3 |172.16.2.9 |172.16.5.10 |172.16.5.40 1148 +--+--+ +--+--+ +--+--+ +--+--+ 1149 | T2a | .... | T2z | | T5a | ....... | T5z | 1150 +-----+ +-----+ +-----+ +-----+ 1152 Figure 16: EzIP System Architecture-B (172.16/12 Portion) 1154 A.3. EzIP System Part C 1156 The EzIP-3 portion maintains private network operation 1157 characteristics, while EzIP-6 portion delivers end-to-end 1158 connectivity. See Figure 17. 1160 +------+ 1161 Web Server | WS0z | 1162 +--+---+ 1163 |69.41.190.145 1164 | 1165 | +-----+ 1166 +--+ ER0 | 1167 +--+--+ 1168 | 1169 +------+-------+ 1170 +-------+ Internet +--------+ 1171 | |(Core Routers)| | 1172 +--+--+ +--------------+ +--+--+ 1173 +-----+ ER3 | +-----+ ER6 | 1174 | +-----+ | +-----+ 1175 | | 1176 EzIP-3 |69.41.190.130 EzIP-6 |69.41.190.160 1177 +--+--+ +--+--+ 1178 +-----------+ +-------+ +---------+ +------+ 1179 | +-----+ SPR3| | | +-----+ SPR6+--+ | 1180 | | +-----+ | | | +-----+ | | 1181 | ... | ................. | | | | | 1182 | | | |...| |...| 1183 10.1.0.0 |10.3.0.0 10.255.0.0 | | +---------+ | 1184 +--+--+ | | | | 1185 +---+ RG3 +--+ 10.1.0.0 | | 10.255.255.255 1186 | +-----+ | | | 1187 | Premises 3 | +----------+ | 1188 | | | Premises 6 | 1189 |10.3.0.3 |10.3.255.9 |10.6.0.10 |10.6.0.40 1190 +--+--+ +--+--+ +--+--+ +--+--+ 1191 | T3a | .... | T3z | | T6a | ....... | T6z | 1192 +-----+ +-----+ +-----+ +-----+ 1194 Figure 17: EzIP System Architecture-C (10/8 Portion 1196 A.4. EzIP System Part D 1198 Utilizing 240/4, the EzIP provides a "spherical shell" of routable 1199 addresses wrapped around the entire current Internet (CRs and ERs), 1200 separating it from the subscribers' IoTs that are either directly 1201 addressable from the Internet such as T7z, T8z, or behind existing 1202 private networks like RG7, RG8.See Figure 18. 1204 +------+ 1205 Web Server | WS0z | 1206 +--+---+ 1207 |69.41.190.145 1208 | 1209 | +-----+ 1210 +--+ ER0 | 1211 +--+--+ 1212 | 1213 +------+-------+ 1214 ER1 ------+ +----- ER4 1215 Interconnect | | 1216 with ER2 ------+ Internet +----- ER5 1217 Preceding | | 1218 Figures ER3 ------+(Core Routers)+----- ER6 1219 | | 1220 +-------+ +--------+ 1221 | | | | 1222 +--+--+ +--------------+ +--+--+ 1223 +-----+ ER7 | +-----+ ER8 | 1224 | +-----+ | +-----+ 1225 | | 1226 |69.41.190.170 |69.41.190.180 1227 +--+--+ +--+--+ 1228 +-----------+ +-------+ +---------+ +------+ 1229 | +-----+ SPR7+--+ |EzIP-7 | +-----+ SPR8+--+ | 1230 | ... | +-----+ |... | | | +-----+ | | 1231 | | +--------+ | |...| |...| 1232 240.0.0.1 | | 255.255.255.255 | | +---------+ | 1233 | | | | | | 1234 +------+ | 240.0.0.1 | | 255.255.255.255 1235 | Premises 7 | +----------+ | 1236 | | | Premises 8 | 1237 |247.0.0.3 |247.0.0.9 |248.0.0.10 |248.0.0.40 1238 +--+--+ +--+--+ +--+--+ +--+--+ 1239 | RG7 | .... | T7z | | T8z | ....... | RG8 | 1240 +-----+ +-----+ +-----+ +-----+ 1242 Figure 18: EzIP System Architecture-D (240/4 Portion) 1244 +--------------------------+-----------------+----------------+ 1245 | | Basic IPv4 | EzIP-capable | 1246 +--------------------------+-----------------+----------------+ 1247 | | ER0, ER1, ER2, | ------------ | 1248 | Internet Edge Router (ER)| ER3, ER4, ER5, | | 1249 | | ER6, ER7, ER8 | | 1250 +--------------------------+-----------------+----------------+ 1251 | | T1a, T2a, T3a, | T1z, T2z, T3z, | 1252 | Internet of Things (IoT) | T4a, T5a, T6a, | T4z, T5z, T6z, | 1253 | | | T7z, T8z | 1254 +--------------------------+-----------------+----------------+ 1255 | | RG1, RG2, RG3 | | 1256 | Routing Gateway (RG) | RG7, RG8 | ------------ | 1257 +--------------------------+-----------------+----------------+ 1258 | | ------------- | SPR1, SPR2, | 1259 | Semi-Public Router (SPR) | | SPR3, SPR4, | 1260 | | | SPR5, SPR6, | 1261 | | | SPR7, SPR8 | 1262 +--------------------------+-----------------+----------------+ 1263 | Web Server (WS) | ------------- | WS0z | 1264 +--------------------------+-----------------+----------------+ 1266 Figure 19: EzIP System Components 1268 Appendix B. EzIP Operation 1270 To demonstrate how EzIP could support and enhance the Internet 1271 operations, the following are three connection examples that involve 1272 SPRs as shown in Figure 9. These present a general perspective of 1273 how IP header transitions through the routers may look like. 1275 1. The first example is between EzIP-unaware IoTs, T1a and T4a. 1276 This operation is very much like the conventional TCP/IP packet 1277 transmission except with SPRs acting as an extra pair of routers 1278 supported by CGNAT. In addition, SPR4 may be viewed as a full- 1279 fledged RG minus DHCP and NAT support, because it assigns its 1280 IoTs with static addresses from the entire range of reserved 1281 192.168/16, instead of the common much smaller pool of 1282 192.168.nnn/24. 1284 2. The second one is between EzIP-capable IoTs, T1z and T4z. Here, 1285 the SPRs process the extended public IP addresses in router mode, 1286 avoiding the delays due to the NAT type of operations. 1288 3. The last one is between EzIP-unaware and EzIP-capable IoTs. By 1289 initiating and responding with a conventional IP header, T1z and 1290 T4z behave like an EzIP-unaware IoT. Thus, all packet exchanges 1291 use the conventional IP headers, just like case 1. above. 1293 B.1. Connection between EzIP-unaware IoTs 1295 B.1.1. T1a Initiates a Session Request towards T4a 1297 In Figure 20. T1a initiates a session request to SPR4 that serves 1298 T4a by sending an IP packet to RG1. There is no TCP port number in 1299 this IP header yet. 1301 0 1 2 3 1302 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 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 1 |Version|IHL (5)|Type of Service| Total Length (20) | 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 2 | Identification |Flags| Fragment Offset | 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 3 | Time to Live | Protocol | Header Checksum | 1309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1310 4 | Source Host Number (192.168.1.3) | 1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 5 | Destination Host Number (69.41.190.148) | 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 Figure 20: EzIP System Components 1317 B.1.2. RG1 Forwards the Packet to SPR1 1319 In Figure 21 RG1, allowing to be masqueraded by T1a, relays the 1320 packet toward SPR1 by assigning the TCP Source port number, 3N, to 1321 T1a. Note that the suffix "N" denotes the actual TCP port number 1322 assigned by the RG1's NAT. This could assume multiple values, each 1323 represents a separate communications session that T1a is engaged in. 1324 A corresponding entry is created in the state table for handling the 1325 responding packet from the Destination site Since T4a's TCP port 1326 number is not known yet, it is filled with all 1's. 1328 0 1 2 3 1329 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 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 1 |Version|IHL (6)|Type of Service| Total Length (24) | 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 2 | Identification |Flags| Fragment Offset | 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 3 | Time to Live | Protocol | Header Checksum | 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 4 | Source Host Number (192.168.1.0) | 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 5 | Destination Host Number (69.41.190.148) | 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 6 | Source Port (3N) | Destination Port (All 1's) | 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 Figure 21: TCP/IP Header: From RG1 to SPR1 1346 B.1.3. SPR1 Sends the Packet to SPR4 through the Internet 1348 In Figure 22, SPR1 allowing masqueraded by RG1 (with the Source Host 1349 Number changed to be its own and the TCP port number changed to 1C, 1350 where "C" stands for CGNAT) sends the packet out through the Internet 1351 towards SPR4. The packet traverses through the Internet (ER1, CR and 1352 ER4) utilizing only the basic IP header portion of address 1353 information (words 4 and 5). 1355 0 1 2 3 1356 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 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 1 |Version|IHL (6)|Type of Service| Total Length (24) | 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1360 2 | Identification |Flags| Fragment Offset | 1361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1362 3 | Time to Live | Protocol | Header Checksum | 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1364 4 | Source Host Number (69.41.190.110) | 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 5 | Destination Host Number (69.41.190.148) | 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 6 | Source Port (1C) | Destination Port (All 1's) | 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 Figure 22: TCP/IP Header: From SPR1 to SPR4 1373 B.1.4. TCP/IP Header: From SPR1 to SPR4 1375 Since the packet has a conventional IP header without Destination TCP 1376 port number, SPR4 would ordinarily drop it due to the CGNAT function. 1377 However, for this example, let's assume that there exists a state- 1378 table that was set up by a DMZ process for redirecting this packet to 1379 T4a with a CGNAT TCP port number 410C (the composite of the third and 1380 the fourth octets, "4.10" of T4a's Extension No.). In Figure 23, 1381 SPR4 sends the packet to T4a by constructing the destination address 1382 accordingly. 1384 0 1 2 3 1385 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 1386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1387 1 |Version|IHL (6)|Type of Service| Total Length (24) | 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 2 | Identification |Flags| Fragment Offset | 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 3 | Time to Live | Protocol | Header Checksum | 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 4 | Source Host Number (69.41.190.110) | 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1395 5 | Destination Host Number (69.41.190.148) | 1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1397 6 | Source Port (1C) | Destination Port (All 1's) | 1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 Figure 23: TCP/IP Header: From SPR4 to T4a 1402 B.1.5. TCP/IP Header: T4a Replies to SPR4 1404 In Figure 24, it interchanges the Source and Destination 1405 identifications to create an IP header for the reply packet. 1407 0 1 2 3 1408 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 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1410 1 |Version|IHL (6)|Type of Service| Total Length (24) | 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 2 | Identification |Flags| Fragment Offset | 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 3 | Time to Live | Protocol | Header Checksum | 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 4 | Source Host Number (192.168.4.10) | 1417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1418 5 | Destination Host Number (69.41.190.110) | 1419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 6 | Source Port (410C) | Destination Port (1C) | 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 Figure 24: TTCP/IP Header: From T4a to SPR4 1425 B.1.6. SPR4 Sends the Packet to SPR1 through the Internet 1427 In Figure 25 SPR4 sends the packet toward SPR1 with the following 1428 header through the Internet (ER4, CR and ER1) who will simply relay 1429 the packet according to the information in word 5 (Destination Host 1430 Number). 1432 0 1 2 3 1433 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 1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 1 |Version|IHL (6)|Type of Service| Total Length (24) | 1436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1437 2 | Identification |Flags| Fragment Offset | 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1439 3 | Time to Live | Protocol | Header Checksum | 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1441 4 | Source Host Number (69.41.190.148) | 1442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 5 | Destination Host Number (69.41.190.110) | 1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1445 6 | Source Port (410C) | Destination Port (1C) | 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 Figure 25: TCP/IP Header: From SPR4 to SPR1 1450 B.1.7. SPR1 Sends the Packet to RG1 1452 In Figure 26, RG1 address is reconstructed by using the information 1453 in the CGNAT state-table stored in SPR1. 1455 0 1 2 3 1456 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 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 1 |Version|IHL (6)|Type of Service| Total Length (24) | 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 2 | Identification |Flags| Fragment Offset | 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1462 3 | Time to Live | Protocol | Header Checksum | 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 4 | Source Host Number (69.41.190.148) | 1465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1466 5 | Destination Host Number (192.168.1.0) | 1467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1468 6 | Source Port (410C) | Destination Port (3N) | 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 Figure 26: TCP/IP Header: From SPR1 to RG1 1473 B.1.8. RG1 Forwards the Packet to T1a 1475 In Figure 27, T1a address is reconstructed from that of RG1 and the 1476 state-table in the NAT based on Destination Port (3N). 1478 0 1 2 3 1479 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 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1481 1 |Version|IHL (6)|Type of Service| Total Length (24) | 1482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1483 2 | Identification |Flags| Fragment Offset | 1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 3 | Time to Live | Protocol | Header Checksum | 1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1487 4 | Source Host Number (69.41.190.148) | 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 5 | Destination Host Number (192.168.1.3) | 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 6 | Source Port (410C) | Destination Port (3N) | 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 Figure 27: TCP/IP Header: From RG1 to T1a 1496 B.1.9. T1a Sends a Follow-up Packet to RG1 1498 To carry on the communication, T1a in Figure 28 sends the follow-up 1499 packet to RG1 with a full TCP/IP header. 1501 0 1 2 3 1502 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 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1504 1 |Version|IHL (6)|Type of Service| Total Length (24) | 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 2 | Identification |Flags| Fragment Offset | 1507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1508 3 | Time to Live | Protocol | Header Checksum | 1509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1510 4 | Source Host Number (192.168.1.3) | 1511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1512 5 | Destination Host Number (69.41.190.148) | 1513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1514 6 | Source Port (3N) | Destination Port (410C) | 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 Figure 28: TCP/IP Header: Follow-up Packets From T1a to RG1 1519 B.2. Connection Between EzIP-capable IoTs 1521 The following is an example of EzIP operation between T1z and T4z 1522 shown in Figure 9. Each knows its own full "Public - EzIP : Private 1523 network addresses", "69.41.190.110-192.168.1.0:9 " and 1524 "69.41.190.148-192.168.4.40" respectively, as well as the other's. 1525 Note that Tz full address does not have the IoT No. portion. It is 1526 directly addressable from the Internet. 1528 B.2.1. T1z Initiates a Session Request towards T4z 1530 T1z initiates a session request to T4z by sending an EzIP packet to 1531 RG1. There is no TCP port number word, because T4z does not have 1532 such and that for T1z has not been assigned by the RG1's NAT. 1534 0 1 2 3 1535 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 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 1 |Version|IHL (7)|Type of Service| Total Length (28) | 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 2 | Identification |Flags| Fragment Offset | 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 3 | Time to Live | Protocol | Header Checksum | 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 4 | Source Host Number (192.168.1.9) | 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1545 5 | Destination Host Number (69.41.190.148) | 1546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1547 | EzIP ID | EzIP | Extended | No | 1548 6 | (Source) | Option Length | Source | Operation | 1549 | (0X9B) | (3) | No. (1) | (00000001) | 1550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1551 | EzIP ID | EzIP | Extended | Extended | 1552 7 | (Destination) | Option Length | Destination | Destination | 1553 | (0X9A) | (4) | No. (4) | No. (40) | 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1556 Figure 29: EzIP Header: From T1z to RG1 1558 Note that 0X9A and 0X9B are temporarily selected from the available 1559 "IP Option Numbers" [RFC1385]. They were employed by prior efforts 1560 to facilitate the presentation of, EnIP and ExIP, respectively. 1561 These convey the concepts of transporting the value of the "Network 1562 No." as well as the number of octets needed in the "Extension No.". 1563 That is, both Option Numbers represent 192.168/16 as the EzIP Network 1564 No. prefix, while individually conveys two or one octets used in the 1565 Extension No., respectively. 1567 B.2.2. RG1 Forwards the Packet to SPR1 1569 In Figure 30 RG1, allowing to be masqueraded by T1z, relays the 1570 packet toward SPR1 by assigning the TCP Source port number, 9N, to 1571 T1z. Since T4z is directly connected to the Internet, there is no 1572 private network information to fill the Destination portion of the 1573 TCP word. 1575 0 1 2 3 1576 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 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 1 |Version|IHL (7)|Type of Service| Total Length (32) | 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 2 | Identification |Flags| Fragment Offset | 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 3 | Time to Live | Protocol | Header Checksum | 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 4 | Source Host Number (192.168.1.0) | 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 5 | Destination Host Number (69.41.190.148) | 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 | EzIP ID | EzIP | Extended | No | 1589 6 | (Source) | Option Length | Source | Operation | 1590 | (0X9B) | (3) | No. (1) | (00000001) | 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 | EzIP ID | EzIP | Extended | Extended | 1593 7 | (Destination) | Option Length | Destination | Destination | 1594 | (0X9A) | (4) | No. (4) | No. (40) | 1595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1596 8 | Source Port (9N) | Destination Port (All 1's) | 1597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1599 Figure 30: TCP/EzIP Header: From RG1 to SPR1 1601 B.2.3. SPR1 Sends the Packet to SPR4 through the Internet 1603 In Figure 31 , SPR4 sends the packet to RG2 by reconstructing its 1604 address from the Option number and the Extended Destination No. 1606 0 1 2 3 1607 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 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 1 |Version|IHL (7)|Type of Service| Total Length (32) | 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 2 | Identification |Flags| Fragment Offset | 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 3 | Time to Live | Protocol | Header Checksum | 1614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1615 4 | Source Host Number (69.41.190.110) | 1616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1617 5 | Destination Host Number (192.168.4.40) | 1618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1619 | EzIP ID | EzIP | Extended | No | 1620 6 | (Source) | Option Length | Source | Operation | 1621 | (0X9B) | (3) | No. (1) | (00000001) | 1622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1623 | EzIP ID | EzIP | Extended | Extended | 1624 7 | (Destination) | Option Length | Destination | Destination | 1625 | (0X9A) | (4) | No. (4) | No. (40) | 1626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1627 8 | Source Port (9N) | Destination Port (All 1's) | 1628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 Figure 31: CP/EzIP Header: From SPR1 to SPR4 1632 B.2.4. TCP/EzIP Header: From SPR1 to SPR4 1634 In Figure 32, SPR4 sends the packet to RG2 by reconstructing its 1635 address from the Option number and the Extended Destination No. 1637 0 1 2 3 1638 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 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 1 |Version|IHL (7)|Type of Service| Total Length (32) | 1641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1642 2 | Identification |Flags| Fragment Offset | 1643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1644 3 | Time to Live | Protocol | Header Checksum | 1645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1646 4 | Source Host Number (69.41.190.110) | 1647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1648 5 | Destination Host Number (192.168.4.40) | 1649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1650 | EzIP ID | EzIP | Extended | No | 1651 6 | (Source) | Option Length | Source | Operation | 1652 | (0X9B) | (3) | No. (1) | (00000001) | 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 | EzIP ID | EzIP | Extended | Extended | 1655 7 | (Destination) | Option Length | Destination | Destination | 1656 | (0X9A) | (4) | No. (4) | No. (40) | 1657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1658 8 | Source Port (9N) | Destination Port (All 1's) | 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1661 Figure 32: TCP/EzIP Header: From SPR4 to T4z 1663 B.2.5. TCP/EzIP Header: From SPR4 to T4z 1665 In Figure 33, T4z replies to SPR4 with the full T1z identification 1666 (69.41.190.110-192.68.1.0:192.168.1.9N conveyed by Option ID 0X9B 1667 together with the compact address string 69.41.190.110-1:9N) to 1668 create an EzIP header for the reply packet. 1670 0 1 2 3 1671 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 1672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1673 1 |Version|IHL (7)|Type of Service| Total Length (32) | 1674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1675 2 | Identification |Flags| Fragment Offset | 1676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1677 3 | Time to Live | Protocol | Header Checksum | 1678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1679 4 | Source Host Number (192.168.4.40) | 1680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1681 5 | Destination Host Number (69.41.190.110) | 1682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 | EzIP ID | EzIP | Extended | Extended | 1684 6 | (Source) | Option Length | Source | Source | 1685 | (0X9A) | (4) | No. (4) | No. (40) | 1686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1687 | EzIP ID | EzIP | Extended | End of | 1688 7 | (Destination) | Option Length | Destination | Option | 1689 | (0X9B) | (3) | No. (1) | (00000000) | 1690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1691 8 | Source Port (All 1's) | Destination Port (9N | 1692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1694 Figure 33: TCP/EzIP Header: From T4z to SPR4 1696 B.2.6. TCP/EzIP Header: From T4z to SPR4 1698 In Figure 34, SPR4 sends the packet toward SPR1 with the following 1699 header through the Internet (ER2, CR, and ER1) who will simply relay 1700 the packet according to the information in word 5 (Destination Host 1701 Number): 1703 0 1 2 3 1704 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 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 1 |Version|IHL (7)|Type of Service| Total Length (32) | 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 2 | Identification |Flags| Fragment Offset | 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 3 | Time to Live | Protocol | Header Checksum | 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1712 4 | Source Host Number (69.41.190.148) | 1713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1714 5 | Destination Host Number (69.41.190.110) | 1715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 | EzIP ID | EzIP | Extended | Extended | 1717 6 | (Source) | Option Length | Source | Source | 1718 | (0X9A) | (4) | No. (4) | No. (40) | 1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 | EzIP ID | EzIP | Extended | End of | 1721 7 | (Destination) | Option Length | Destination | Option | 1722 | (0X9B) | (3) | No. (1) | (00000000) | 1723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1724 8 | Source Port (All 1's) | Destination Port (9N) | 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1727 Figure 34: TCP/EzIP Header: From SPR4 to SPR1 1729 B.2.7. SPR1 Sends the Packet to RG1 1731 In Figure 35, RG1 address is reconstructed from the Option number and 1732 the Extended Destination No. 1734 0 1 2 3 1735 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 1736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1737 1 |Version|IHL (7)|Type of Service| Total Length (32) | 1738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1739 2 | Identification |Flags| Fragment Offset | 1740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1741 3 | Time to Live | Protocol | Header Checksum | 1742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1743 4 | Source Host Number (69.41.190.148) | 1744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1745 5 | Destination Host Number (192.168.1.0) | 1746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1747 | EzIP ID | EzIP | Extended | Extended | 1748 6 | (Source) | Option Length | Source | Source | 1749 | (0X9A) | (4) | No. (4) | No. (40) | 1750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1751 | EzIP ID | EzIP | Extended | End of | 1752 7 | (Destination) | Option Length | Destination | Option | 1753 | (0X9B) | (3) | No. (1) | (00000000) | 1754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1755 8 | Source Port (All 1's) | Destination Port (9N) | 1756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1758 Figure 35: TCP/EzIP Header: From SPR1 to RG1 1760 B.2.8. RG1 Forwards the Packet to T1z 1762 In Figure 36, T1z address is reconstructed from that of RG1 and the 1763 NAT state-table based on Destination Port (9N). 1765 0 1 2 3 1766 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 1767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1768 1 |Version|IHL (7)|Type of Service| Total Length (32) | 1769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1770 2 | Identification |Flags| Fragment Offset | 1771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1772 3 | Time to Live | Protocol | Header Checksum | 1773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1774 4 | Source Host Number (69.41.190.148) | 1775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1776 5 | Destination Host Number (192.168.1.9) | 1777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1778 | EzIP ID | EzIP | Extended | Extended | 1779 6 | (Source) | Option Length | Source | Source | 1780 | (0X9A) | (4) | No. (4) | No. (40) | 1781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1782 | EzIP ID | EzIP | Extended | End of | 1783 7 | (Destination) | Option Length | Destination | Option | 1784 | (0X9B) | (3) | No. (1) | (00000000) | 1785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1786 8 | Source Port (All 1's) | Destination Port (9N) | 1787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1789 Figure 36: TCP/EzIP Header: From RG1 to T1z 1791 B.2.9. T1z Sends a Follow-up Packet to RG1 1793 In Figure 37, T1z sends a follow-up packet to RG1 with all fields 1794 filled with needed information. 1796 0 1 2 3 1797 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 1798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 1 |Version|IHL (7)|Type of Service| Total Length (32) | 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1801 2 | Identification |Flags| Fragment Offset | 1802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1803 3 | Time to Live | Protocol | Header Checksum | 1804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1805 4 | Source Host Number (192.168.1.9) | 1806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1807 5 | Destination Host Number (69.41.190.148) | 1808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1809 | EzIP ID | EzIP | Extended | No Op | 1810 6 | (Source) | Option Length | Source | Option | 1811 | (0X9B) | (3) | No. (1) | (00000001) | 1812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1813 | EzIP ID | EzIP | Extended | Extended | 1814 7 | (Destination) | Option Length | Destination | Destination | 1815 | (0X9A) | (4) | No. (4) | No. (40) | 1816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1817 8 | Source Port (9N) |Destination Port (All 1's) | 1818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1820 Figure 37: TCP/EzIP Header: Follow-up Packets from T1z to RG1 1822 B.3. Connection Between EzIP-unaware and EzIP-capable IoTs 1824 B.3.1. T1a initiates a request to T4z 1826 Since T1a can create only IP header with conventional format, the 1827 SPRs will provide CGNAT type of services to the IP packets. And, 1828 assuming SPR4 has a state-table set up by DMZ for forwarding the 1829 request to T4z, the packet will be delivered to T4z. Seeing the 1830 incoming packet using conventional IP header, T4z should respond with 1831 the same so that the session will be conducted with conventional TCP/ 1832 IP headers. 1834 B.3.2. T1z initiates a request to T4a 1836 Knowing T4a is not capable of EzIP header, T1z purposely initiates 1837 the request packet using conventional IP header. It will be treated 1838 by SPRs in the same manner as the T1a initiated case above and 1839 recognizable by T4a. 1841 In brief, the steps outlined above are very much the same as the 1842 conventional TCP/IP header transitions between routers, except two 1843 extra steps in each direction are inserted to encode and decode the 1844 additional SPR provided EzIP routing process. 1846 Note that when an IoT, such as T4a or T4z, is directly connected to a 1847 SPR, like SPR4, there is no RG in-between. There is no corresponding 1848 TCP port number in word 8 of the above TCP/EzIP headers. This spare 1849 facility in the header allows an RG be inserted if desired, thus re- 1850 establishing the private network environment. When extension address 1851 is transported by a full TCP/EzIP header with four octet format, 1852 proper precaution must be exercised to avoid confusing the routers 1853 along the way due to the appearance of a full private network address 1854 although at a location in the IP header not intended for ordinary IP 1855 address. When EzIP-7 is used, this is not of concern because the 1856 240/4 block does not belong to the three conventional private network 1857 address blocks. 1859 Appendix C. Internet Transition Considerations 1861 To enhance a large communication system like the Internet, it is 1862 important to minimize the disturbance to the existing equipments and 1863 processes due to any needed modification. The basic EzIP plan is to 1864 confine all actionable enhancements within the new SPR module. The 1865 following outlines the considerations for supporting the transition 1866 from the current Internet to the one enhanced by the EzIP technique. 1868 C.1. EzIP Implementation 1870 C.1.1. Introductory Phase 1872 a. Insert an SPR in front of a web-server that desires to have 1873 additional subnet addresses for offering diversified activities. 1874 For the long term, a new web server may be designed with these 1875 two functional modules combined. 1877 b. Insert an SPR in front of a group of subscribers who are to be 1878 served with the EzIP function. The basic service provided by 1879 this SPR will be the CGNAT equivalent function. This will 1880 maintain the same baseline user experience in accessing the 1881 Internet. 1883 c. Session initiating packets with basic IPv4 header will be routed 1884 by SPRs to a business's existing server at the currently 1885 published IPv4 public address (discoverable by existing DNS). 1886 The server should respond with the basic IPv4 format as well. 1887 Essentially, this maintains the existing interaction between a 1888 user and a web server within an EzIP-unaware environment. So 1889 far, neither the web-server nor any subscriber's IoTs needs to be 1890 enhanced, because the operations remain pretty much the same as 1891 today's common practice utilizing CGNAT assisted connectivity. 1892 See Appendix B.1. for an example. 1894 d. Upon connected to the main web server, if a customer 1895 intentionally selects one of the new services offered by the 1896 primary web-server, the web-server will ask the customer to 1897 confirm the selection: 1899 1. If confirmed, implying that the customer is aware of the fact 1900 that his IoT is being served by an SPR, the web server 1901 forwards the request to a branch server for carrying on the 1902 communication via an EzIP address. 1904 2. The SPR at the originating side, recognizing the EzIP header 1905 from the web-server, replaces the CGNAT service with EzIP 1906 routing. 1908 3. For all subsequent packets exchanged, the EzIP headers will 1909 be used in either direction. See Appendix B.2. for an 1910 example. This will speed up the transmission throughput 1911 performance for the rest of the session. 1913 C.1.2. New IoT Operation Modes 1915 a. EzIP-capable IoT will create EzIP header initiating a session, to 1916 directly reach a specific web-server, instead of the lengthy 1917 steps of going through the DMZ port followed by manually making 1918 the selection from the main web server.This will speed up the 1919 initial handshake process. See Appendix B.2. for an example. 1921 b. To communicate with an EzIP-unaware IoT, an EzIP-capable IoT 1922 should purposely initiate a session with conventional IP header. 1923 This will signal the SPRs to provide just CGNAT type of 1924 connection service. See Appendix B.3. for an example. 1926 C.1.3. End-to-End Operation: 1928 Once EzIP-capable IoTs become common for the general public, direct 1929 communication between any pair of such IoTs will be achievable. An 1930 EzIP-capable IoT, knowing the other IoT's full EzIP address, may 1931 initiate a session by creating an EzIP header that directs the SPRs 1932 to provide EzIP services, bypassing the CGNAT process. See 1933 Appendix B.2. for an example. 1935 C.2. SPR Operation Logic 1937 To support the above scenarios, the SPR should be designed with the 1938 following decision process: 1940 C.2.1. Initiating a Session Request for an IoT or via a RG 1942 If a session request IP packet contains EzIP Option word, it will be 1943 routed forward by SPR accordingly. Otherwise, the SPR provides CGNAT 1944 service by assigning a TCP port number to the packet and allowing the 1945 packet to masquerade with the SPR's own IP address while an entry to 1946 the state (port forward / look-up / hash) table is created in 1947 anticipation of the reply packet. 1949 C.2.2. Receiving a Session Request from the ER 1951 If a received IP packet includes a valid EzIP Option word or port 1952 number, SPR will utilize it to route the packet to an RG or an IoT. 1953 For a packet with plain IP header, it will be routed according to the 1954 Destination Host Number (IPheader word 5). 1956 C.3. RG Enhancement 1958 With IPv4 address pool expanded by the EzIP schemes, there will be 1959 sufficient publicly assignable addresses for IoTs wishing to be 1960 directly accessible. The existing private networks may continue 1961 their current behavior of blocking session request packets from the 1962 Internet. In-between, another connection mode is possible. The 1963 following describes such an option in the context of the existing RG 1964 operation conventions. 1966 C.3.1. Initiating Session request for an IoT 1968 Without regard to whether the IP header is a conventional one or an 1969 EzIP type, a RG allows a packet to masquerade with the RG's own IP 1970 address by assigning a TCP port number to the packet and creating an 1971 entry to the state (port forward /look-up / hash) table. This is the 1972 same as current NAT practice. 1974 C.3.2. Receiving a packet from the SPR 1976 The "Destination Port" value in the packet is examined: 1978 a. If it matches with an entry in the RG NAT's state-table, the 1979 packet is forward to the corresponding address. This is the same 1980 as the normal NAT processes in a conventional RG. 1982 b. If it matches with the address of an activeIoT on the private 1983 network, the packet is assigned with a TCP port number and then 1984 forwarded to that IoT. 1986 Note that there is certain amount of increased security risk with 1987 this added last step, because a match between a guessed destination 1988 identity and the above two lists could happen by chance. To address 1989 this issue, the following proactive mechanism may be incorporated in 1990 parallel: 1992 If the "Destination Port" number is null or does not match with 1993 either of the above cases, the packet is dropped and an alarm state 1994 is activated to monitor for possible ill-intended follow-up attempts. 1995 A defensive mechanism should be triggered when the number of failed 1996 attempts has exceeded the preset threshold within a finite time 1997 interval. 1999 Alternatively, if the IP header of a session requesting packet 2000 indicates that the sender knows the identity of the desired 2001 destination IoT on a private network, the common RG screening process 2002 will be bypassed. This facilitates the direct end-to-end connection, 2003 even in the presence of the NAT. Note that this process is very much 2004 the same as the AA (Automated Attendant) capability in a PABX 2005 telephone switching system that automatically makes the connection 2006 for a caller who indicates (via proper secondary dialing or the 2007 equivalent) knowing the extension number of the destination party. 2008 Such process can effectively screen out most of the unwanted callers. 2010 Authors' Addresses 2012 Abraham Chen 2013 Avinta Communications Inc. 2014 142 N. Milpitas Blvd., #148 2015 Milpitas, California 95035 2016 USA 2018 Email: AYChen@Avinta.com 2020 Ramamurthy Ati 2021 Avinta Communications Inc. 2022 142 N. Milpitas Blvd., #148 2023 Milpitas 95035 2024 USA 2026 Email: RamaAti18@gmail.com.com