idnits 2.17.1 draft-chen-ati-adaptive-ipv4-address-space-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 7. IANA Considerations' ) ** There are 9 instances of too long lines in the document, the longest one being 18 characters in excess of 72. ** The abstract seems to contain references ([15], [2], [16], [RFC791], [3], [17], [RFC862], [RFC2123], [4], [18], [RFC793], [5], [19], [6], [RFC6598], [RFC2928], [7], [8], [9], [RFC1918], [10], [11], [12], [RFC1385], [13], [14], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 16 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance 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 == Line 677 has weird spacing: '...cribers on th...' -- The document date (December 8, 2021) is 868 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC6598' on line 1195 -- Looks like a reference, but probably isn't: 'RFC791' on line 979 -- Looks like a reference, but probably isn't: 'RFC1918' on line 412 -- Looks like a reference, but probably isn't: 'RFC793' on line 448 -- Looks like a reference, but probably isn't: 'RFC2123' on line 451 -- Looks like a reference, but probably isn't: 'RFC1385' on line 531 -- Looks like a reference, but probably isn't: 'RFC862' on line 771 -- Looks like a reference, but probably isn't: 'RFC2928' on line 778 -- Obsolete informational reference (is this intentional?): RFC 793 (ref. '9') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 1385 (ref. '12') (Obsoleted by RFC 6814) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 A. Y. Chen 2 Internet Draft R. R. Ati 3 Intended status: Experimental Avinta Communications, Inc. 4 Expires: June 2022 A. Karandikar 5 India Institute of Technology 6 D. R. Crowe 7 Wireless Telcom Consultant 8 December 8, 2021 10 Adaptive IPv4 Address Space 11 draft-chen-ati-adaptive-ipv4-address-space-10.txt 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on June 8, 2019. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Abstract 53 This document describes a solution to the Internet address depletion 54 issue through the use of an existing Option mechanism that is part of 55 the original IPv4 protocol. This proposal, named EzIP (phonetic for 56 Easy IPv4), outlines the IPv4 public address pool expansion and the 57 Internet system architecture enhancement considerations. EzIP may 58 expand an IPv4 address by a factor of 256M without affecting the 59 existing IPv4 based Internet, or the current private networks. It is 60 in full conformance with the IPv4 protocol, and supports not only 61 both direct and private network connectivity, but also their 62 interoperability. EzIP deployments may coexist with existing Internet 63 traffic and IoTs (Internet of Things) operations without perturbing 64 their setups, while offering end-users the freedom to indepdently 65 choose which service. EzIP may be implemented as a software or 66 firmware enhancement to Internet edge routers or private network 67 routing gateways, wherever needed, or simply installed as an inline 68 adjunct hardware module between the two, enabling a seamless 69 introduction. The 256M case detailed here establishes a complete 70 spherical layer of an overlay of routers for interfacing between the 71 Internet fabic (core plus edge routers) and the end user premises or 72 IoTs. Incorporating caching proxy technology in the gateway, a fairly 73 large geographical region may enjoy address expansion based on as few 74 as one ordinary IPv4 public address utilizing IP packets with 75 degenerated EzIP header. If IPv4 public pool allocations were 76 reorganized, the assignable pool could be multiplied 512M fold or 77 even more. Enabling hierarchical address architecture which 78 facilitates both hierarchical and mesh routing, EzIP can provide 79 nearly the same order of magnitude of address pool resources as IPv6 80 while streamlining the administrative aspects of it. The basic EzIP 81 will immediately resolve the local IPv4 address shortage, while being 82 transparent to the rest of the Internet as a new parallel facility. 83 Under the Dual-Stack environment, these proposed interim facilities 84 will relieve the IPv4 address shortage issue, while affording IPv6 85 more time to reach maturity for providing the availability levels 86 required for delivering a long-term general service. 88 Table of Contents 90 1. Introduction...................................................4 91 1.1. Contents of this Draft....................................6 93 2. EzIP Overview..................................................6 94 2.1. EzIP Numbering Plan.......................................6 95 2.2. Analogy with NAT..........................................8 96 2.3. EzIP System Architecture..................................9 97 2.4. IP Header with Option Word...............................11 98 2.5. Examples of Option Mechanism.............................12 99 2.6. EzIP Header..............................................13 100 2.7. EzIP Operation...........................................14 101 3. EzIP Deployment Strategy......................................14 102 4. Updating Servers to Support EzIP..............................17 103 5. EzIP Enhancement and Application..............................18 104 6. Security Considerations.......................................22 105 7. IANA Considerations...........................................22 106 8. Conclusions...................................................22 107 9. References....................................................23 108 9.1. Normative References.....................................23 109 9.2. Informative References...................................23 110 10. Acknowledgments..............................................24 111 Appendix A EzIP Operation.......................................25 112 A.1. Connection between EzIP-unaware IoTs.....................25 113 A.1.1. T1a Initiates a Session Request towards T4a.........25 114 A.1.2. RG1 Forwards the Packet to SPR1.....................26 115 A.1.3. SPR1 Sends the Packet to SPR4 through the Internet..27 116 A.1.4. SPR4 Sends the Packet to T4a........................28 117 A.1.5. T4a Replies to SPR4.................................29 118 A.1.6. SPR4 Sends the Packet to SPR1 through the Internet..30 119 A.1.7. SPR1 Sends the Packet to RG1........................31 120 A.1.8. RG1 Forwards the Packet to T1a......................32 121 A.1.9. T1a Sends a Follow-up Packet to RG1.................32 122 A.2. Connection Between EzIP-capable IoTs.....................33 123 A.2.1. T1z Initiates a Session Request towards T4z.........33 124 A.2.2. RG1 Forwards the Packet to SPR1.....................34 125 A.2.3. SPR1 Sends the Packet to SPR4 through the Internet..35 126 A.2.4. SPR4 Sends the Packet to T4z........................36 127 A.2.5. T4z Replies to SPR4.................................37 128 A.2.6. SPR4 Sends the Packet to SPR1 through the Internet..38 129 A.2.7. SPR1 Sends the Packet to RG1........................39 130 A.2.8. RG1 Forwards the Packet to T1z......................40 131 A.2.9. T1z Sends a Follow-up Packet to RG1.................41 132 A.3. Connection Between EzIP-unaware and EzIP-capable IoTs....42 133 A.3.1. T1a Initiates a Request to T4z......................42 134 A.3.2. T1z Initiates a Request to T4a......................42 135 Appendix B Internet Transition Considerations...................43 136 B.1. EzIP Implementation......................................43 137 B.2. SPR Operation Logic......................................44 138 B.3. RG Enhancement...........................................45 139 Appendix C EzIP Realizability...................................47 140 C.1. 240/4 Netblock Capable IoTs..............................47 141 C.2. 240/4 Netblock Capable Routers...........................47 142 C.3. Enhancing an RG..........................................48 143 C.4. SPR Reference Design.....................................49 144 C.5. RAN Deployment Model.....................................49 145 Appendix D Enhancement of a Commercial RG.......................51 146 D.1. Candidate Code for Modification..........................51 147 D.2. Proposed Modification....................................51 148 D.3. Performance Verification.................................52 149 Appendix E Utilizing Open Source Router Code....................53 150 E.1. EzIP Realizability Test Bed..............................53 151 E.2. RAN Architecture Demonstration...........................53 152 E.3. EzIP Compatible Routers..................................54 153 Appendix F Sub-Internet.........................................55 154 F.1. Gateway Configuration....................................55 155 F.2. Gateway Setup............................................55 156 F.3. Sub-Internet Operation...................................55 158 1. Introduction 160 For various reasons, there is a large demand for IP addresses. It 161 would be useful to have a unique address for each Internet device, 162 such that, if desired, any device may call upon any other directly. 163 IP addresses are needed while client devices, such as mobile phones, 164 are attached to the internet, which is a rapidly increasing demand. 165 The Internet of Things (IoT) would also be able to make use of more 166 routable addresses if they were available. Currently, these are not 167 possible with the existing IPv4 configuration. 169 By Year 2020, the world population and number of IoTs are expected to 170 reach 7.6B (Billion) and 50B respectively, according to a 2011 Cisco 171 online white paper [3]. 173 The IPv4 dot-decimal address format, consisting of four octets each 174 made of 8 binary bits, provides a little over 4 billion unique 175 addresses (256 x 256 x 256 x 256 equals 4,294,967,296 - decimal 176 exact). Using the binary / shorthand notation of 64K representing 256 177 x 256 (decimal 65,536), the full IPv4 address pool of 64K x 64K may 178 be expressed as 4,096M (Million), or 4.096B (or, further rounded down 179 to 4B for quick estimate calculations). Clearly, the predicted demand 180 is more than 12 times over the inherent capacity available from the 181 supply. 183 IPv6, with its 128-bit hexadecimal address format, is four times as 184 long as the IPv4, has 256BBBB (4B x 4B x 4B x 4B) unique addresses. 186 It offers a promising solution to the address shortage. However, its 187 global adoption appears to be facing significant challenges [4], [5]. 189 Interim relief to the IPv4 address shortage has been provided by 190 Network Address and Port Translation (NAPT - commonly known simply as 191 NAT) on private networks together with Carrier Grade NAT (CG-NAT or 192 abbreviated further to CGN) [RFC6598] [6] over the public Internet. 193 However, NAT modules slow down routers due to the state-table look-up 194 process. As well, they only allow an Internet session be initiated by 195 their own clients, impeding the end-to-end setup requests initiated 196 from remote devices that a fully functional communication system 197 should be capable of. Since port numbers are used to effectively 198 increase the size of the address pool, they introduce complex and 199 suboptimal port management requirements. For example, being dynamic, 200 the state-table used by CG-NAT increases CyberSecurity vulnerability 201 by imposing extra efforts to forensic tracing of perpetrators. On the 202 other hand, private network NAT as part of a Routing / Residential 203 Gateway (RG) does provide a rudimentary defense against intrusion. To 204 minimize the confusion, we will explicitly label this latter 205 (although implemented first) NAT as RG-NAT in this document to 206 distinguish from the CG-NAT. 208 If IPv4 capacity could be expanded without the CG-NAT limitations, 209 such as size, speed and outgoing-only, the urgency due to address 210 shortage will be relaxed long enough for the IPv6 to mature on its 211 own pace. 213 There have been several proposals to increase the effective Internet 214 public address pool in the past. They all introduced new techniques 215 or protocols that ran into certain handicaps or compatibility issues, 216 preventing a smooth transition. 218 EzIP utilizes a long-reserved network address block (netblock) 240/4 219 [7] that all of the existing Internet Core (/ backbone) Router (CR), 220 Edge Router (ER) and private network Routing (/ Residential) Gateway 221 (RG) as well as terminal hosts such as PCs and IoTs are not allowed 222 to utilize. The Option mechanism defined in [RFC791] [1] is used for 223 transporting such information as the IP header payload so that an IP 224 packet is transparent to all of these routers, except a newly defined 225 category named Semi-Public Router (SPR). By inserting an SPR between 226 an ER and a private premises that it serves, each publicly assignable 227 address can be expanded 256M fold. 229 EzIP introduces minimal perturbation by being compatible to the 230 current Internet system architecture. Its deployment will start with 231 an SPR providing public CG-NAT functions to unload the burden from 232 the current CG-NAT facility. With the basic routing as an integral 233 part of the SPR, directly connected individual IoTs and private 234 networks will be encouraged to migrate toward the full EzIP service 235 for enjoying the end-to-end connectivity between and among them. 237 1.1. Contents of this Draft 239 This draft outlines the EzIP numbering plan. An enhanced IP header, 240 called EzIP header, is introduced to carry the EzIP address as 241 payload using the Option word. How the Internet architecture will 242 change as the result of being extended by the EzIP scheme is 243 explained. How the EzIP header flows through various routers, and 244 Internet update considerations are described, with details presented 245 in Appendices A and B, respectively. Utilizing the EzIP approach, 246 several ways to expand the publicly assignable IPv4 address pool, as 247 well as enhance Internet operations are then discussed. Appendix C 248 outlines the experimental effort to demonstrate the feasibility of 249 EzIP by configuring a regional area network model based on current 250 networking equipment upon finite enhancements. Appendix D is a Work- 251 In-Progress report about the enhancement of a specific commercial RG. 252 Appendix E is an EzIP scheme feasibility demonstration by utilizing 253 publicly available hardware and software. Appendix F describes a 254 networking configuration called Sub-Internet that is based on one 255 single IPv4 address. A sub-Internet is a self-content module that can 256 provide Internet-like services to a stand-alone region with upto 256M 257 IoTs or private premises. 259 2. EzIP Overview 261 2.1. EzIP Numbering Plan 263 EzIP uses the reserved private network address pools in very much the 264 same way that Private Automatic Branch eXchange (PABX) switching 265 machines utilize locally assigned "extension numbers" to expand the 266 Public Switched Telephone Network (PSTN) capacity, by replicating a 267 public telephone line to multitudes of reusable private telephone 268 numbers, each to identify a local instrument. 270 At the first sight, this correlation may seem odd, because the PABX 271 extension numbers belong to a reusable private set separate from that 272 of the public telephone numbers and both are independently 273 expandable, while private network IP address is a specific subset 274 parsed from the overall IPv4 pool that is otherwise all public and 275 finite. However, the fact that neither of the latter two is allowed 276 to operate in the other's domain, the same as in the telephony 277 practice, suggests that the proposed EzIP numbering plan indeed may 278 mirror the PABX. For example, extension 123 or 1234 may exist in 279 thousands of different PABX switches without ambiguity. Similarly, 280 the IPv4 private network address blocks (10/8, 172.16/12 and 281 192.168/16) may also be re-used in many networks without ambiguity. 283 The key EzIP concept is the partitioning of a finite public address 284 pool to put aside a block of special (called "Semi-Public" in the 285 presentation below) addresses that extends each remaining public 286 address to multitudes of sub-addresses, resulting in an effectively 287 much larger assignable public address resource. 289 In fact, the initial EzIP analysis identified the untold two-stage 290 subnetting process of 192.168/16 that has been practiced routinely 291 for a long time. End-users are commonly accustomed to an RG choosing 292 one out of 256 values from the fourth octet of the 192.168.K/24 293 address block for identifying an IoT on a private premises. They 294 mostly are, however, unaware of the preceeding stage of selecting the 295 value "K" from the third octet of the 192.168/16 block, as the 296 factory default RG identification assigned by a manufacturer, is 297 implicitly capable of expanding it by 256 fold for supporting a 298 corresponding number of private premises. A key EzIP concept is to 299 use the elusive IPv4 240/4 netblock (240/8 - 255/8), that has been 300 "RESERVED" for "Future use" since 1981-09, as the result of the 301 historical address assignment evolution. It was proposed to be 302 redesignated to "Private Use" over a decade ago [2]. However, as 303 pointed out by its own authors in Section 2, Caveats of Use, "Many 304 implementations of the TCP/IP protocol stack have the 240.0.0.0/4 305 address block marked as experimental, and prevent the host from 306 forwarding IP packets with addresses drawn from this address block." 307 That proposal did not get advanced. Consequently, to this date, the 308 240/4 netblock remains practically unused. 310 Substituting the function of the third octet of 192.168.K/24 with 311 addresses from the 240/4 netblock in the first stage RG and 312 redefining it as a new category of router, called SPR, the EzIP 313 scheme circumvents the earlier hurdles to achieve the address 314 multiplication factor of 256M without involving any existing router. 315 This is because the 240/4 addresses are only used by the SPR and 316 within the Option word header extension. They are not recognized as 317 IPv4 addresses anywhere within the current Internet, while the Option 318 word mechanism can carry them through the network as part of the IP 319 header payload. 321 Since the 240/4 netblock cannot be used by existing routers, the size 322 of the maximum assignable IPv4 pool has actually been only 3.84B 323 (4.096B - 256M). So, the overall assignable pool resulted from the 324 EzIP approach is about 983MB (3.84B x 256M), which is over 19M times 325 of the expected Year 2020 IoTs. This size certainly has the potential 326 to support the short- to mid-term public IP address needs. 328 2.2. Analogy with NAT 330 NAT generally works by temporarily assigning a port number to 331 outgoing communications originated from a local / private address, by 332 converting it into a public IPv4 address shared with other local IoTs 333 for external transmission. When responses are received, the port 334 number is converted back into the local / private IPv4 address. 336 EzIP possesses similarities to CG-NAT, but also has some important 337 differences. 339 There are a number of limitations of NAT that are not present with 340 EzIP. (1) There are only 65,536 port numbers but 256M 240/4 EzIP 341 addresses; (2) Due to the limited number of ports, assignments are 342 only temporary and will be reclaimed after a period of inactivity, 343 but there are so many EzIP addresses that assignments will be made 344 permanent; (3) Port numbers are used for other purposes than NAT, 345 further reducing the pool, but EzIP uses 240/4 addresses solely for 346 one purpose; (4) Due to the limited time during which a port number 347 is assigned, the NAT port numbers cannot be used for incoming 348 communications, but the EzIP address assignments will be long term 349 and can be used for direct communications between EzIP-aware devices. 350 (5) Intriguingly, while RG-NAT provides rudimental defense agaist 351 intrusion, the dynamic nature of CG-NAT opens up the Internet 352 vulnerability to cyber attacks, due to its inherent lack of forensic 353 traceability. SPR will eventually replace CG-NAT for a more efficient 354 and robust path. 356 2.3. EzIP System Architecture 358 +------+ 359 Web Server | WS0z | 360 +--+---+ 361 |69.41.190.145 362 | 363 | +-----+ 364 +--+ ER0 | 365 +--+--+ 366 | 367 +------+-------+ 368 +-------+ Core Routers +--------+ 369 | | (CR/Internet)| | 370 +--+--+ +--------------+ +--+--+ 371 +-----+ ER1 | +-----+ ER4 | 372 | +-----+ | +-----+ 373 | | 374 |69.41.190.110 |69.41.190.148 375 240.0.0.0 +--+--+ +--+--+ 376 +-----------+ +-------+ +---------+ +------+ 377 | +-----+ SPR1| | | +-----+ SPR4+--+ | 378 | | +-----+ | |...| +-----+ |...| 379 | 240.0.0.1 ... 255.255.255.255 | | +---------+ | 380 +-----+ | | | | 381 Public | 240.0.0.0 | | 255.255.255.255 382 Demarc. ----+-------------------------------+----+------------------- 383 Private |Premises 1 +----------+ | 384 +--+--+ | Premises 4 | 385 +---+ RG1 +--+ | | 386 | +-----+ | | | 387 | | | | 388 |192.168.1.3 |192.168.1.9 |240.0.0.10 |246.1.6.40 389 +--+--+ +--+--+ +--+--+ +--+--+ 390 | T1a | .... | T1z | | T4a | ....... | T4z | 391 +-----+ +-----+ +-----+ +-----+ 393 Figure 1 EzIP System Architecture 395 The new category of router, SPR is to be positoned inline between an 396 ER and the customer premises that it serves. After the original path 397 is re-established, the remaining addresses in the 240/4 netblock will 398 be used by the SPR to serve additional premises. Figure 1 shows a 399 general view of the enhanced Internet system architecture with two 400 SPRs, SPR1 and SPR4, deployed. Note that the "69.41.190.x" are static 401 addresses. In particular, the "69.41.190.145" is the permanent public 402 Internet address assigned to Avinta.com. 404 2.3.1. Referring to the lefthand portion labeled "Premises 1" of 405 Figure 1, instead of assigning each premises a public IPv4 address as 406 in the current practice, an SPR like SPR1, is inserted between an ER 407 (ER1) and its connections to private network Routing Gateways like 408 RG1, for utilizing 240.0.0.0 through 255.255.255.255 of the 240/4 409 netblock to identify respective premises. The RG1, serving either a 410 business LAN (Local Area Network) or a residential HAN (Home Area 411 Network), uses addresses from one of the three private network 412 [RFC1918] [8] blocks, 10/8, 172.16/12 and 192.168/16, such as 413 192.168.1.3 and 192.168.1.9 to identify the IoTs, T1a and T1z, 414 respectively. 416 2.3.2. Part of the righthand portion of Figure 1 is labeled 417 "Premises 4". Here SPR4 directly assigns addresses 240.0.0.10 and 418 246.1.6.40 from the 240/4 netblock to T4a and T4z, respectively. 419 Consequently, these IoTs are accessible through SPR4 from any other 420 IoT in the Internet. 422 2.3.3. Since the existing physical connections to subscriber's 423 premises terminate at the ER, it would be natural to have SPRs 424 collocated with their ER for streamlining the interconnections. It 425 follows that the simple routing function provided by the new SPR 426 modules may be absorbed into the ER through a straightforward 427 operational firmware enhancement. Consequently, the public / private 428 demarcation (Demarc.) line will remain at the RG where currently all 429 utility services enter a subscriber's premises. 431 2.3.4. To fully tag each of these devices, we may use a 432 concatenated three-part address notation: "Public - Semi-Public: TCP 433 Port". The following is how each of the IoTs in Figure 1 may be 434 uniquely identified in the Internet. 436 RG1: 69.41.190.110-240.0.0.0 438 T1a: 69.41.190.110-240.0.0.0:3 440 T1z: 69.41.190.110-240.0.0.0:9 442 T4a: 69.41.190.148-240.0.0.10 444 T4z: 69.41.190.148-246.1.6.40 446 Note that to simplify the presentation, it is assumed at this 447 juncture that the conventional TCP (Transmission Control Protocol) 448 [RFC793] [9] Port Number, normally assigned to T1a and T1z by RG1's 449 RG-NAT module upon initiating a session, equals to the fourth octet 450 of that IoT's private IP address that is assigned by the RG1's DHCP 451 (Dynamic Host Configuration Protocol) [RFC2123] [10] subsystem as 452 ":3" and ":9", respectively. Such numbers are unique within each 453 respective /24 private network such as the 192.168.1/24 here. They 454 are adequate for the discussion purpose in this document. However, 455 considering security, as well as allowing each IoT to have multiple 456 simultaneous sessions, etc., this direct and singular correlation 457 shall be avoided in actual practice by following the RG-NAT operation 458 conventions as depicted by the examples in Appendix A. 460 Figure 2 groups IoTs, routers and servers into two separate columns, 461 EzIP-unaware or EzIP-capable, to facilitate discussions that are to 462 follow. 464 +--------------------------+-----------------+----------------+ 465 | | EzIP-unaware | EzIP-capable | 466 +--------------------------+-----------------+----------------+ 467 | Internet Core Router (CR)| CR | ------------ | 468 +--------------------------+-----------------+----------------+ 469 | Internet Edge Router (ER)| ER0, ER1, ER4 | ------------ | 470 +--------------------------+-----------------+----------------+ 471 | Internet of Things (IoT) | T1a, T4a | T1z, T4z | 472 +--------------------------+-----------------+----------------+ 473 | Routing Gateway (RG) | RG1 | ------------ | 474 +--------------------------+-----------------+----------------+ 475 | Semi-Public Router (SPR) | ------------- | SPR1, SPR4 | 476 +--------------------------+-----------------+----------------+ 477 | Web Server (WS) | ------------- | WS0z | 478 +--------------------------+-----------------+----------------+ 480 Figure 2 EzIP System Components 482 2.4. IP Header with Option Word 484 To transport the EzIP Extension Addresses through existing devices 485 without being recognized as such and consequently acted upon, the IP 486 Header Option mechanism defined by Figure 9 in Appendix A of [RFC791] 487 is utilized to carry it as the payload. One specific aspect of its 488 format deserves some attention. The meanings of the leading eight 489 bits of each Option word, called "Opt. Code" or "Option-type octet", 490 are summarized on Page 15 of [RFC791]. They are somewhat confusing 491 because the multiple names used in the literature, and how the octet 492 is parsed into functional bit groups. For example, a two digit 493 hexadecimal number, "0x9A", is conventionaly written in the binary 494 bit string form as "1001 1010". As Opt. Code, however, the eight bits 495 here are parsed into three groups of 1, 2 and 5 bits as "1 00 11010" 496 with meanings described in Figure 3. 498 +--------------------------------------------------------------+ 499 | Meaning of EzIP ID = 0x9A (Example) | 500 +--------------+------------------+----------------------------+ 501 | Copy Bit | Class | Option Value / Number | 502 +--------------+------------------+----------------------------+ 503 | 1 (Set) | 00 (Control) | 11010 (26 - base 10) | 504 +--------------+------------------+----------------------------+ 506 Figure 3 Option Type Octet 508 A value of "1" for the first bit instructs all routers that this 509 Option word is to be copied upon packet fragmentation. This preserves 510 the Option word through such a process, if it is performed. 512 The value of "00" for the next two bits indicates that this Option 513 word is for "Control" purpose. 515 The decimal "Option Value" of the last five bits, equaling to "26" is 516 defined as the "Option Number" that is listed in the "Number" column 517 of the Internet Protocol Version 4 (IPv4) Parameters list [11]. As 518 can be seen there, "26" has not been assigned. Thus, it is 519 temporarily used in this document to facilitate the EzIP 520 presentation. The next unassigned Option Code, "0x9B" or Number "27" 521 will also be tentatively utilized in this document. 523 2.5. Examples of Option Mechanism 525 The Option mechanism has been used for various cases. Since they were 526 mostly for utility or experimental purposes, however, their formats 527 may be remote from the incident topic. There were two cases 528 specifically dealt with the address pool issues. They are referenced 529 here to assist the appreciation of the Option mechanism. 531 A. EIP (Extended Internet Protocol) - Figure 1 of [RFC1385] [12] 532 (Assigned but now deprecated Option Number = 17) by Z. Wang: This 533 approach proposed to add a new network layer on top of the existing 534 Internet for increasing the addressable space. Although equipment 535 near the end-user would stay unchanged, those among the CRs 536 apparently had to go through rather extensive upgrading procedures, 537 perhaps due to the flexible length of the extended address (could be 538 much longer than that of the IPv6). 540 B. EnIP (Enhanced IPv4) - Figure 1 of Internet Draft [13] 541 (temporarily utilizing Option Number = 26) by W. Chimiak: This work 542 made use of the three existing private network blocks to extend the 543 public pool by trading the private network operation for end-to-end 544 connectivity. The fully deployed EnIP will eliminate the current 545 private networks which may be against the intuitive preference of 546 end-users who have found the private network configuration quite 547 desirable. For example, the RG-NAT serves as a rudimentary deterrent 548 against intrusion. In addition, the coexistence of private RG-NAT and 549 public EnIP router functions in the same EnIP devices (N1 & N2), 550 could lead to certain logistic inconsistency concerns. 552 2.6. EzIP Header 554 0 1 2 3 555 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 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 1 |Version|IHL (8)|Type of Service| Total Length (32) | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 2 | Identification |Flags| Fragment Offset | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 3 | Time to Live | Protocol | Header Checksum | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 4 | Source Host Number | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 5 | Destination Host Number | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | EzIP ID | EzIP | Extended | Extended | 568 6 | (Source) | Option Length | Source | Source | 569 | (0X9A) | (6) | No.-1 | No.-2 | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Extended | Extended | EzIP ID | EzIP | 572 7 | Source | Source | (Destination) | Option Length | 573 | No.-3 | No.-4 | (0X9B) | (6) | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Extended | Extended | Extended | Extended | 576 8 | Destination | Destination | Destination | Destination | 577 | No.-1 | No.-2 | No.-3 | No.-4 | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 Figure 4 Full EzIP Header 582 The proposed EzIP header format shown in Figure 4 can transport the 583 full 4 octet (32 bit) extension addresses of both ends of an Internet 584 link. The extension address in the 240/4 netblock utilized in the 585 EzIP scheme described herein has 28 significant bits. It is possible 586 for EzIP to use addresses having other lengths of significant bits 587 for different multiplication factors. To prepare for such variations, 588 two separate EzIP ID codes, "0x9A" and "0x9B" are proposed to 589 distinguish between Source and Destination Option words, 590 respectively, as basic examples. 592 2.7. EzIP Operation 594 To convey the general scheme, Appendix A presents examples of IP 595 header transitions through routers, between IoTs with or without EzIP 596 capability. 598 To introduce the EzIP approach into an environment where EzIP-unaware 599 IoTs like T1a and T4a will be numerous for a long time to come, an 600 SPR must be able to follow certain decision branches to determine how 601 to provide the appropriate routing service for a smooth transition to 602 the long term operation. Appendix B outlines such logic and related 603 considerations. 605 3. EzIP Deployment Strategy 607 Although the eventual goal of the SPR is to support both web server 608 access by IoTs from behind private networks and direct end-to-end 609 connectivity between IoTs, the former should be dealt with first to 610 immediately mitigate the address shortage induced daily issues. In 611 the process, the latter would be built up naturally. 613 A. Architecturally 615 Since the design philosophy of the SPR is an inline module between an 616 ER and the private premises (RG or directly connected IoTs) that it 617 serves, SPR introduction process can be flexible. 619 A.1. An SPR may be deployed as an inline module right after an ER 620 to begin providing the CG-NAT equivalent function. This could be done 621 immediately without affecting any of the existing Internet 622 components, CR, ER and RG. EzIP-capable IoTs will then take advantage 623 of the faster bi-directional routing service through the SPRs by 624 initiating communication sessions utilizing EzIP headers to contact 625 other EzIP-capable IoTs. 627 A.2. Alternatively, an SPR may be deployed as an adjunct module 628 just before an existing RG or a directly connected IoT to realize the 629 same EzIP functions on the private premises, even if the serving 630 Internet Access Provider (IAP) has not enhanced its ERs with the EzIP 631 capability. 633 This approach will empower individual communities to enjoy the new 634 EzIP capability on their own by upgrading all Internet subscribers 635 within a good sized region to have publicly accessible EzIP addresses 636 for intra-community peer-to-peer communication, starting from just 637 using one existing public IPv4 address to identify the entire region 638 through a gateway to the rest of the world. See sub-section C. below 639 for more specific considerations. 641 B. Functionally 643 B.1. First, an IAP should install SPRs in front of business web 644 servers so that new routing branches may be added to support the 645 additional web servers for expanding business activities. 646 Alternatively, this may be achieved if businesses on their own deploy 647 new web servers with the SPR capability built-in. 649 B.2. On the subscriber side, SPRs should be deployed to 650 disseminate static addresses to the public, and to facilitate the 651 access to new web servers. 653 C. Regional Area Network 655 C.1. Since the size of the 240/4 netblock is significant, a 656 region mentioned in sub-section A.2. above could actually be fairly 657 large. Based on the assumption that each person, on the average, may 658 have 6.6 IoTs by Year 2020 [3], a 240/4 netblock is capable of 659 serving nearly 39M (256M / 6.6) individual devices, even before 660 utilizing any private netblocks to manage private prmises. This 661 exceeds the population of the largest city on earth (38M - Tokyo 662 Metro.) and 75% of the countries around the world (i. e., most of the 663 233 countries other than the top 35). Therefore, any finite sized 664 region can immediately begin to enjoy EzIP addressing by deploying a 665 Regional Area Network (RAN) utilizing SPRs operating with one 240/4 666 netblock of addresses from one IPv4 public address. With the gateway 667 for a region configured in such a way that the entire region appears 668 to be one ordinary IPv4 IoT to the rest of the Internet, a self- 669 contained RAN may be deployed anywhere there is the need or desire, 670 with no perturbation to the current Internet operations whatsoever. 672 C.2. This gateway may be constructed with a matured networking 673 technology called Caching Proxy [14], popularized by data-intensive 674 web services such as Google, Amazon, Yahoo, as well as gateways for 675 corporate LANs, VPN (Virtual Private Network), etc. Developed for 676 speeding up response to repetitive queries from a group of 677 subscribers on the same topic, while storing data from the central 678 data bank, caching proxies are placed at strategic locations close to 679 potential high activities, essentially cloning the central data bank 680 into distributed copies (not necessarily a full set, but containing 681 all relevant subsets pertaining to the local community). This 682 architecture meshs with the EzIP-based RAN very well, because the 683 address translation between the IPv4 in the Internet and the EzIP in 684 the RAN can be accomplished transparently through the two ports of a 685 caching proxy (For such matter, even could be between the IPv6 and 686 the EzIP if desired!). Consequently, existing Internet routers, such 687 as CR and ER may not see any IP packet with EzIP header at all, 688 during the initial phase of the RAN deployment which will primarily 689 consist of basic intra-regional messaging and web service access in a 690 primarily local operation mode. Ongoing study of this possibility is 691 reported in Appendix F. 693 C.3. This configuration actually mimicks the PABX environment 694 almost exactly. Since the entire region is only accessible through 695 the gateway that performs the address translation, degenerated EzIP 696 header (conventional IP header with words 4 and 5 using 240/4 697 netblock addresses) will be suffice for the intra RAN traffic. This 698 mirrors the dialing procedure of using only extension numbers among 699 stations served by the same PABX, circumventing the unnecessary and 700 wasteful overhead of including the dialing of the common public 701 telephone number prefix whose only purpose is to identify the PABX to 702 the PSTN which is not involved in such intra-PABX communications. 704 C.4. The full EzIP header format will only be used when an EzIP- 705 capable IoT intends to directly interact with an EzIP-capable IoT in 706 another RAN. The last part is equivalent to the IDDD (International 707 Direct Distance Dialing) conventions when a call is made through the 708 PSTN to a station outside of a PABX. 710 C.5. The RAN would streamline the CIR (Country-based Internet 711 Registry) model proposed by ITU-T [18] as well. Instead of allocating 712 a block of public IPv6 addresses to an ITU-T authorized entity 713 (essentially the sixth RIR - Regional Internet Registry) to 714 administrate on behalf of individual countries, the EzIP RAN 715 configuration enables each member state to start her own CIR with up 716 to 256M IoTs, based on just one of the IPv4 public address already 717 allocated to that country from the responsible RIR. Consequently, 718 each CIR is coordinated by its parent RIR, yet its operation can 719 conform to local preferences. This configuration will establish a 720 second Internet service parallel to the existing one for 721 demonstrating their respective merits independently, offering 722 subscribers true options to choose from. 724 D. Permanently 726 In the long run, it would be best if SPRs are integrated into their 727 host ER by upgrading the latter's firmware to minimize the hardware 728 and to streamline the equipment interconnections. 730 Appendix B details the considerations in implementing these outlines. 732 4. Updating Servers to Support EzIP 734 Although the IP header Option mechanism utilized by EzIP was defined 735 a long time ago as part of the original IPv4 protocol [RFC791] [1], 736 it has not been used much in daily traffic. Compatibility with 737 current Internet facilities and conventions may need be reviewed. 738 Since the EzIP data is transported as part of the IP header payload, 739 it is not expected to affect higher layer protocols. However, certain 740 facilities may have been optimized without considering the Option 741 mechanism. They need be adjusted to provide the same performance to 742 EzIP packets. There are also utility type of servers that need be 743 updated to support the longer EzIP address. For example; 745 A. Fast Path 747 Internet Core Routers (CRs) are currently optimized to only provide 748 the "fast-path" (through hardware line card) routing service to 749 packets without Option word in the IP header [15]. This puts EzIP 750 packets at a disadvantage, because EzIP packets will have to go 751 through the "slow path" (processed by CPU's software before giving to 752 the correct hardware line card to forward), resulting in a slower 753 throughput. Since the immediate goal of the EzIP is to ease the 754 address pool exhaustion affecting web server access, subscribers not 755 demanding high throughput performance may be migrated to the EzIP 756 supported facility first. This gives CRs the time to update so that 757 EzIP packets with authorized Option numbers will eventually be 758 recognized for receiving the "fast-path" service. On the other hand, 759 an alternative logic may be applied for the CR. That is, it should by 760 default ignore any Option word in an IP header so that all IP packets 761 will be processed through the "fast-path", unless a recognizable 762 Option word requiring action is detected. This approach would 763 mitigate the security issues caused by the "source routing" attack, 764 as well. 766 B. Connectivity Verification 767 One frequently used probing utility for verifying baseline 768 connectivity, commonly referred to as the "ping" function in PC 769 terminology, needs be able to transport the full EzIP address that is 770 64 bits long instead of the current 32 bit IPv4 address. There is an 771 example of an upgraded TCP echo server in [RFC862] [16]. 773 C. Domain Name Server (DNS) 775 Similarly, the DNS needs to expand its data format to transport the 776 longer IP address created by the EzIP. This already can be done under 777 IPv6. Utilizing the experimental IPv6 prefix 2001:0101 defined by 778 [RFC2928] [17], EzIP addresses may be transported as standardized 779 AAAA records. 781 These topics are discussed in more detail under an IETF Draft RFC, 782 Enhanced IPv4 - V.03 [13]. 784 5. EzIP Enhancement and Application 786 To avoid disturbing any assigned address, deployed equipment and 787 current operation, etc., the EzIP scheme is derived under the 788 constraint of utilizing only the reserved 240/4 address block. If 789 such restriction were removed by allowing the entire IPv4 address 790 pool be flexibly re-allocatable, the assignable public address pool 791 could be expanded significantly more, as outlined below. 793 A. If the 240/4 netblock were doubled to 224/3, each existing IPv4 794 public address would be expanded by 512M fold. Since this block of 795 512M addresses have to be first reserved from the basic public pool, 796 the resultant total addresses will be (4.096B - 512M) x 512M, or 797 1,835MB. This is over 36M times of the predicted number of IoTs (50B) 798 by Year 2020. This calculation leads to additional possibilities. 800 B. The EzIP header in Figure 4, capable of transporting the full 32 801 bit IPv4 address, allows the extension number to be as long as 802 practical. That is, we can go to the extreme of reserving only one 803 bit for the network number, and using all the rest of bits for the 804 extension address. With this criterion, the basic IPv4 pool may be 805 divided into two halves, reserving one half of it (about 2B 806 addresses) as a semi-public network with the network number prefix 807 equal to "1". Each of the remaining 2B public addresses (with prefix 808 equal to "0") of the basic IPv4 pool may then be extended 2B fold 809 through the EzIP process, resulting in a 4BB address pool. This is 810 roughly 80M times of the Year 2020 IoT needs. 812 C. If the EzIP technique were applied through several layers of SPRs 813 in succession, the address expansion could be even more. For example, 814 let's divide the IPv4 pool equally into four blocks, each with about 815 1B addresses. Apply the first 1B address block to the public routers. 816 Set up three layers of SPRs, each makes use of one of the remaining 817 three 1B address blocks. The resultant assignable pool will have 818 1BBBB addresses. Under this configuration, the full length of an 819 IoT's identification code will be the concatenation of four segments 820 of 32 bit IPv4 address, totalling 128 bits, the same as that of the 821 IPv6. The first two bits of each segment, however, being used to 822 distinguish from the other three address blocks, are not significant 823 bits. This 8-bits difference makes the IPv6 pool 256 times larger. 824 This ratio is immaterial, because even the 1BBBB address pool is 825 alreaby 20MBB times of the foreseeable need. It is the hierarchical 826 addressing characteristics, made possible by the EzIP scheme, that 827 will enhance the Internet, such as truncating out the common address 828 prefix for communicating within a local community, and associating an 829 address with the geographical position, thus mitigating the 830 GeoLocation related issues. 832 D. Along this line of reasoning, we could combine two 1B address 833 blocks togther to be the basic public address. The overall assignable 834 pool becomes 2BBB which is still 40MB times of the expected IoT 835 need(50B). With this pool, we can divide the entire globe into 2B 836 regions, each served by one public router. Each region can then be 837 divided into 1B sections, identified by the first group of SPRs. 838 Next, each section will have the second group of SPRs to manage upto 839 1B RGs and IoTs. Since the basic 2B public addresses are already more 840 than half of the current total assignable IPv4 public addresses 841 (3.84B), their potential GeoLocation resolution capabilities are 842 comparable. With additional two layers of SPR routing, 1B for each, 843 the address grid granuality will be so refined that locating the 844 source of an IP packet becomes a finite task, leaving perpetrators 845 little room to hide. 847 E. The following outlines a possible procedure for optimizing the use 848 of the EzIP address resource by transforming the current Internet to 849 be a GeoLocation-capable address system while maintaining the 850 existing IPv4 addressing and operation conventions: 852 a. Quantitative Reference: IETF [RFC6598] [6] reserved the 853 100.64/10 block with 4M addresses for supporting IAP's CG-NAT 854 service. Applying all of these to the entire IPv4 pool of 4B 855 addresses, the maximum effective CG-NAT supported IPv4 address pool 856 could be 16MB. This is 0.32M times of the expected number (50B) of 857 IoTs by Year 2020. 859 b. Employing the 240/4 netblock with 256M addresses in the EzIP 860 extension scheme, a /6 block with 64M addresses from the IPv4 basic 861 public pool is sufficient to replicate the above 16MB capacity. This 862 frees up the majority of the IPv4 public pool. 864 c. Since this will be a temporary holding pool to release the 865 current addresses for new assignments, it should occupy as few public 866 addresses as possible to leave the maximum number of addresses for 867 facilitating the long term planning. To just support the expected 50B 868 IoTs need, only 200 IPv4 public addresses are required (200 x 256M = 869 50B). Thus, a /24 block with 256 addresses is more than enough to 870 accommodate this entire migration process. This frees up even more 871 IPv4 public addresses. 873 d. Although a single /24 public address block is sufficient for 874 migrating all currently perceived IPv4 address needs into one compact 875 temporary EzIP pool, world-wide coordination of new address 876 assignments and routing table updates will be required. It will be 877 more expeditious to carry out this preparatory phase on an individual 878 country or geographical region basis utilizing public IPv4 addresses 879 already assigned to that area and actively served by existing CR 880 routing tables. Since 200 public addresses are enough to port the 881 entire IoT addresses, most of the 233 countries other than the top 35 882 (about 75%) countries should be able to port all of their respective 883 predicted IoTs to be under one 240/4 netblock, each represented by 884 one gateway to the Internet. If this is managed according to 885 geographical disciplines, each participating region will begin to 886 enjoy the benefits of the EzIP approach, such as plentiful assignable 887 public addresses, robust security due to inherent GeoLocation ability 888 to spot hackers from within, so that efforts may be focused on only 889 screening suspicious packets originated from without. 891 e. As IoTs are getting migrated to the temporary pool, the IPv4 892 addresses they originally occupy shall be released to re-populate the 893 public address pool for establishing full scale EzIP operation. 895 f. Upon the completion of the EzIP based world-wide public address 896 allocation map, each country can simply give up the few temporary 897 public addresses in exchange for the permanent assignments. Since the 898 latter is likely more than the former, addresses in one 240/4 899 netblock will be served by two (or more) 240/4 netblocks. Then, each 900 of such 240/4 netblock will have more than half of its capacity 901 available to serve the growth of additional IoTs. 903 g. This last step is very much the same as the traditional PSTN 904 "Area Code Split" practice, whereby telephone numbers of a service 905 area are split into two (or more) blocks, upon introducing one (or 906 more) new area code(s) into the area. All subscribers will continue 907 to use their original local telephone numbers for calling among 908 neighbors daily, except some may be assigned with a new area code 909 prefix. Upon the split, each area code will have more than half of 910 its assignable telephone numbers availabe to support the future 911 subscriber growth within its service area. Mimicking the PSTN, the 912 EzIP based Internet will have similar GeoLocation capability as the 913 former's caller identification based services, such as the 911 914 emergency caller location system in US, mitigating the root cause to 915 the cybersecurity vulnerability. 917 F. With the IPv4 address shortage issue resolved, potential system 918 configurations utilizing the EzIP enhanced address pool may be 919 explored. 921 a. Although the entire predicted number (50B) of IoTs by Year 2020 922 may be served by just one /24 IPv4 public address block utilizing the 923 EzIP scheme with a 240/4 netblock, let's replace it with a /8 block 924 (16M addresses), resulting in about 4MB (16M x 256M) assignable 925 addresses. This is 80K times of the expected 50B IoTs. Or, each and 926 every person (of predicted 2020 population) would have to own over 927 500K IoTs to use up this address pool. It is apparent that the spares 928 in this allocation should be sufficient to support the growth of the 929 IoTs for some years to come. 931 b. Next, the IPv4 pool originally has 256 blocks of /8 addresses. 932 After the above allocation, there are still 239 blocks of /8 933 addresses available to support additional digital communication 934 systems, each having the same size of address pool as the allocation 935 above. Consequently, many world-wide communication networks may 936 coexist under the same IPv4 protocol framework in the form of groups 937 of RANs as described earlier, with arm's-length links among them. 939 c. For example, a satellite based Internet that is being proposed 940 [19], such as StarLink can start fresh as one EzIP RAN served by one 941 SPR having the capacity of 256M IoTs, under one ER capable of 942 managing one /8 block of IPv4 public address. Utilizing a caching 943 proxy as the gateway to handle the data exchange with other RAN, this 944 satellite based Internet with 256M hosts can operate pretty much as 945 an isolated system by using 240/4 addresses in the basic IP headers 946 for intra-RAN communications, most of the time. Only when direct 947 communication with another RAN (such as the one for the existing 948 Internet) is needed, will the full EzIP header be required. As users 949 grow, additional RANs (each with 256M IoTs capacity), may be 950 incrementally added to support the expansion. 952 G. In summary, utilizing the 240/4 netblock, the EzIP scheme may 953 expand the IPv4 based Internet to be a collection of up to 240 groups 954 of 16M RANs each managed by one SPR with 256M IoTs capacity that are 955 inter-operable digital communication systems, normally operate at 956 arm's-lenghth to one another. Each of these groups has the address 957 capacity of at least 80K times of the number of predicted (50B) IoTs 958 by Year 2020. 960 6. Security Considerations 962 The EzIP solution is based on an inline module called SPR that is 963 intended to be as transparent to Internet traffic as possible. The 964 proposed address assignment rule is deterministic and systematic. 965 Thus, no overall system security degradation is expected. 967 7. IANA Considerations 969 This draft does not create a new registry nor does it register any 970 values in existing registries; no IANA action is required. 972 8. Conclusions 974 To resolve the IPv4 public address pool exhaustion issue, a technique 975 called EzIP (phonetic for Easy IPv4) making use of a long reserved 976 address block 240/4, is proposed. 978 This draft RFC describes an enhancement to IPv4 operation utilizing 979 the IP header Option mechanism defined in [RFC791]. Since the design 980 criterion is to enhance IPv4 by extending instead of altering it, the 981 impact on already in-place routers and security mechanisms is 982 minimized. 984 The basic EzIP philosophy includes maintaining the existing public 985 and private network structure. Upon reclassifying the "RESERVED for 986 Future use" 240/4 netblock to be the Semi-Public address pool, it 987 will only be usable by the new SPR (Semi-Public Router) as the EzIP 988 extension address. This pool can multiply each current IPv4 public 989 address by 256M fold, while all existing public network and 990 subscriber premises setups (private networks as well as directly 991 connected IoTs) may remain unchanged. A subscriber is encouraged to 992 upgrade his IoT(s) to be EzIP-capable so as to fully enjoy the 993 enhanced router service by EzIP for end-to-end communication. This 994 particular manifestation of the EzIP scheme appears to be the optimal 995 solution to our needs. 997 The 240/4 netblock based EzIP scheme will not only relieve the IPv4 998 address shortage, but also improve the defense against cybersecurity 999 intrusion by virtue of systematic and deterministic address 1000 management. The EzIP RAN (Regional Area Network) configuration will 1001 also support the desire to establish CIR (Country-based Internet 1002 Registry) operation expressed by ITU-T, as a parallel local facility 1003 providing services equivalent to the current global Internet. 1005 Furthermore, EzIP will help the IPv4 based Internet to become the 1006 common backbone for multiple world-wide digital communication systems 1007 such as satellite based systems like StarLink that normally would 1008 operate in arm's-length from one another. 1010 These last two possible applications turn out to be a generic 1011 architectural feature that is also suitable for establishing test 1012 beds at arm's-length to one another for developing new protocols and 1013 products. This particular manifestation of the EzIP empowers end- 1014 users to participate in the evaluation, and the smooth transition 1015 from testing to the eventual use, of new services in a realistic, not 1016 simulated, parallel environment. 1018 9. References 1020 9.1. Normative References 1022 [1] https://tools.ietf.org/html/rfc791 1024 [2] https://tools.ietf.org/html/draft-wilson-class-e-02 1026 9.2. Informative References 1028 [3] https://www.cisco.com/c/dam/en_us/about/ac79/docs/innov/IoT_IBS 1029 G_0411FINAL.pdf 1031 [4] http://stats.labs.apnic.net/ipv6 1033 [5] https://stats.ams-ix.net/sflow/ether_type.html 1035 [6] https://tools.ietf.org/html/rfc6598 1037 [7] http://www.iana.org/assignments/ipv4-address-space/ipv4- 1038 address-space.xhtml 1040 [8] https://tools.ietf.org/html/rfc1918 1042 [9] https://tools.ietf.org/html/rfc793 1044 [10] https://www.ietf.org/rfc/rfc2131.txt 1046 [11] http://www.iana.org/assignments/ip-parameters/ip- 1047 parameters.xhtml 1049 [12] https://tools.ietf.org/html/rfc1385 1051 [13] https://tools.ietf.org/html/draft-chimiak-enhanced-ipv4-03 1053 [14] https://en.wikipedia.org/wiki/Proxy_server#Improving_performanc 1054 e 1056 [15] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.477.19 1057 42&rep=rep1&type=pdf 1059 [16] https://tools.ietf.org/html/rfc862 1061 [17] https://tools.ietf.org/html/rfc2928 1063 [18] https://www.nro.net/wp-content/uploads/nro-response-to-ls-5.pdf 1065 [19] https://www.commerce.senate.gov/public/index.cfm/2017/10/the- 1066 commercial-satellite-industry-what-s-up-and-what-s-on-the- 1067 horizon 1069 10. Acknowledgments 1071 The authors would express their deep appreciation to Dr. W. Chimiak 1072 for the enlightening discussions about his team's efforts and 1073 experiences through their EnIP development. 1075 This document was prepared using 2-Word-v2.0.template.dot. 1077 Appendix A EzIP Operation 1079 To demonstrate how EzIP could support and enhance the Internet 1080 operations, the following are three sets of examples that involve 1081 SPRs as shown in Figure 1. These present a general perspective of how 1082 IP header transitions through the routers may look like. 1084 1. The first example is between EzIP-unaware IoTs, T1a and T4a. This 1085 operation is very much the same as the conventional TCP/IP packet 1086 transmission except with SPRs acting as an extra pair of routers 1087 providing the CG-NAT service. 1089 2. The second one is between EzIP-capable IoTs, T1z and T4z. Here, 1090 the SPRs process the extended semi-public IP addresses in router 1091 mode, avoiding the drawbacks due to the CG-NAT type of table look-up 1092 operations above. 1094 3. The last one is between EzIP-unaware and EzIP-capable IoTs. By 1095 initiating and responding with a conventional IP header, EzIP-capable 1096 IoTs behave like EzIP-unaware IoTs. Thus, all packet exchanges use 1097 the conventional IP headers, just like case 1. above. 1099 A.1. Connection between EzIP-unaware IoTs 1101 A.1.1. T1a Initiates a Session Request towards T4a 1103 T1a sends a session request to SPR4 that serves T4a by a plain IP 1104 packet with header as in Figure 5, to RG1. There is no TCP port 1105 number in this IP header yet. 1107 0 1 2 3 1108 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 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 1 |Version|IHL (5)|Type of Service| Total Length (20) | 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 2 | Identification |Flags| Fragment Offset | 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 3 | Time to Live | Protocol | Header Checksum | 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 4 | Source Host Number (192.168.1.3) | 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 5 | Destination Host Number (69.41.190.148) | 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 Figure 5 IP Header: From T1a to RG1 1123 A.1.2. RG1 Forwards the Packet to SPR1 1125 RG1, allowing be masqueraded by T1a, relays the packet toward SPR1 1126 by assigning the TCP Source port number, 3N, to T1a, with a header as 1127 in Figure 6,. Note that the suffix "N" denotes the actual TCP port 1128 number assigned by the RG1's RG-NAT. This could assume multiple 1129 values, each represents a separate communications session that T1a is 1130 engaged in. A corresponding entry is created in the RG1 state table 1131 for handling the reply packet from the Destination site. Since T4a's 1132 TCP port number is not known yet, it is filled with all 1's. 1134 0 1 2 3 1135 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 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 1 |Version|IHL (6)|Type of Service| Total Length (24) | 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 2 | Identification |Flags| Fragment Offset | 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 3 | Time to Live | Protocol | Header Checksum | 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 4 | Source Host Number (240.0.0.0) | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 5 | Destination Host Number (69.41.190.148) | 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 6 | Source Port (3N) | Destination Port (All 1's) | 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 Figure 6 TCP/IP Header: From RG1 to SPR1 1152 A.1.3. SPR1 Sends the Packet to SPR4 through the Internet 1154 SPR1, detecting no EzIP Option word, acts like a CG-NAT. It allows 1155 being masqueraded by RG1 (with the Source Host Number changed to be 1156 SPR1's own and the TCP port number changed to 0C, where "0" is the 1157 last octet of RG1's IP address, and "C" stands for CG-NAT) and sends 1158 the packet as in Figure 7 out through the Internet towards SPR4. The 1159 packet traverses through the Internet (ER1, CR and ER4) utilizing 1160 only the Destination Host Number (word 5) in the header. 1162 0 1 2 3 1163 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 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 1 |Version|IHL (6)|Type of Service| Total Length (24) | 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 2 | Identification |Flags| Fragment Offset | 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 3 | Time to Live | Protocol | Header Checksum | 1170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 4 | Source Host Number (69.41.190.110) | 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 5 | Destination Host Number (69.41.190.148) | 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 6 | Source Port (0C) | Destination Port (All 1's) | 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 Figure 7 TCP/IP Header: From SPR1 to SPR4 1180 Note that although schematically shown in Figure 1 as one public IPv4 1181 address serving one SPR capable of a full 240/4 address block, the 1182 PCP port number has a theoretical limit of 64K (256 x 256) because it 1183 consists of 16 bits. This is much smaller than a full 240/4 pool. 1184 Even with dynamic assignments, it will take quite a few public 1185 address to serve the CG-NAT need if many IoTs are EzIP-unaware. So, 1186 IoTs are encouraged to become EzIP-capable as soon as possible to 1187 avoid straining the SPR's CG-NAT capability. This should not be an 1188 issue for emerging regions currently having very little facility and 1189 IoTs. As new ones are deployed, they should be enabled as EzIP- 1190 capable by factory default. For the rural area of developed countries 1191 with existing EzIP-unaware IoTs, the need for CG-NAT service will be 1192 greater. Multiple IPv4 public addresses would be needed initially to 1193 support smaller sub- 240/4 netblocks. This is probably workable 1194 because the latter does have more public IPv4 addresses. The CG-NAT 1195 techniques developed under [RFC6598] [6] may be incorporated here to 1196 facilitate the transition. 1198 A.1.4. SPR4 Sends the Packet to T4a 1200 Since the packet has a conventional TCP/IP header without Destination 1201 TCP port number, SPR4 would ordinarily drop it due to the CG-NAT 1202 function. However, for this example, let's assume that there exists a 1203 state-table that was set up by a DMZ (De-Militaried Zone) process for 1204 redirecting this packet to T4a with a CG-NAT TCP port number 10C 1205 (Here, "10" is the fourth octet of T4a's Extension address, and "C" 1206 stands for CG-NAT.). After constructing the Destination Host Number 1207 accordingly, SPR4 sends the packet to T4a with a header as in Figure 1208 8. 1210 0 1 2 3 1211 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 1212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 1 |Version|IHL (6)|Type of Service| Total Length (24) | 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 2 | Identification |Flags| Fragment Offset | 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 3 | Time to Live | Protocol | Header Checksum | 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 4 | Source Host Number (69.41.190.110) | 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 5 | Destination Host Number (240.0.0.10) | 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 6 | Source Port (0C) | Destination Port (10C) | 1224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 Figure 8 TCP/IP Header: From SPR4 to T4a 1228 A.1.5. T4a Replies to SPR4 1230 T4a interchanges the Source and Destination identifications in the 1231 incoming TCP/IP packet to create a header as in Figure 9, for the 1232 reply packet to SPR4. 1234 0 1 2 3 1235 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 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1237 1 |Version|IHL (6)|Type of Service| Total Length (24) | 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1239 2 | Identification |Flags| Fragment Offset | 1240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1241 3 | Time to Live | Protocol | Header Checksum | 1242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1243 4 | Source Host Number (240.0.0.10) | 1244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1245 5 | Destination Host Number (69.41.190.110) | 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 6 | Source Port (10C) | Destination Port (0C) | 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 Figure 9 TCP/IP Header: From T4a to SPR4 1252 A.1.6. SPR4 Sends the Packet to SPR1 through the Internet 1254 SPR4, allowing being masqueraded by T4a, sends the packet toward SPR1 1255 with the header in Figure 10, through the Internet (ER4, CR and ER1) 1256 who will simply relay the packet according to the information in word 1257 5 (Destination Host Number): 1259 0 1 2 3 1260 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 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 1 |Version|IHL (6)|Type of Service| Total Length (24) | 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 2 | Identification |Flags| Fragment Offset | 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 3 | Time to Live | Protocol | Header Checksum | 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 4 | Source Host Number (69.41.190.148) | 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 5 | Destination Host Number (69.41.190.110) | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 6 | Source Port (10C) | Destination Port (0C) | 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 Figure 10 TCP/IP Header: From SPR4 to SPR1 1277 A.1.7. SPR1 Sends the Packet to RG1 1279 Using the stored data in the CG-NAT state-table, SPR1 reconstructes a 1280 header as in Figure 11, for sending the packet to RG1. 1282 0 1 2 3 1283 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 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 1 |Version|IHL (6)|Type of Service| Total Length (24) | 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 2 | Identification |Flags| Fragment Offset | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 3 | Time to Live | Protocol | Header Checksum | 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 4 | Source Host Number (69.41.190.148) | 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 5 | Destination Host Number (240.0.0.0) | 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 6 | Source Port (10C) | Destination Port (3N) | 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1298 Figure 11 TCP/IP Header: From SPR1 to RG1 1300 A.1.8. RG1 Forwards the Packet to T1a 1302 From the state-table in RG1's RG-NAT, T1a address is reconstructed 1303 based on Destination Port (3N), as in Figure 12. 1305 0 1 2 3 1306 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 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 1 |Version|IHL (6)|Type of Service| Total Length (24) | 1309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1310 2 | Identification |Flags| Fragment Offset | 1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 3 | Time to Live | Protocol | Header Checksum | 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 4 | Source Host Number (69.41.190.148) | 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 5 | Destination Host Number (192.168.1.3) | 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 6 | Source Port (10C) | Destination Port (3N) | 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1321 Figure 12 TCP/IP Header: From RG1 to T1a 1323 A.1.9. T1a Sends a Follow-up Packet to RG1 1325 To carry on the communication, T1a constructs a full TCP/IP header as 1326 in Figure 13 for sending the follow-up packet to RG1. 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.3) | 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 5 | Destination Host Number (69.41.190.148) | 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 6 | Source Port (3N) | Destination Port (10C) | 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 Figure 13 TCP/IP Header: Follow-up Packets From T1a to RG1 1346 A.2. Connection Between EzIP-capable IoTs 1348 The following is an example of EzIP operation between T1z and T4z 1349 shown in Figure 1, with full "Public - EzIP : Private" network 1350 addresses, "69.41.190.110-240.0.0.0:9" and "69.41.190.148- 1351 246.1.6.40", respectively. Note that T4z, without the private portion 1352 (TCP port number) in the concatenated address, is directly 1353 addressable from the Internet. For T1z to initiate a session, it 1354 needs to know the full address of T4z, but only it's own private 1355 address. 1357 A.2.1. T1z Initiates a Session Request towards T4z 1359 T1z sends an EzIP packet, as in Figure 14, to RG1. There is no TCP 1360 port number word, because T4z does not have such while that for T1z 1361 is waiting for assignment from the RG1's RG-NAT. Also, the Extended 1362 Source No. is filled with all "1's", waiting for being specified by 1363 SPR1. 1365 0 1 2 3 1366 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 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 1 |Version|IHL (8)|Type of Service| Total Length (32) | 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 2 | Identification |Flags| Fragment Offset | 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1372 3 | Time to Live | Protocol | Header Checksum | 1373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1374 4 | Source Host Number (192.168.1.9) | 1375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1376 5 | Destination Host Number (69.41.190.148) | 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1378 | EzIP ID | EzIP | Extended | Extended | 1379 6 | (Source) | Option Length | Source | Source | 1380 | (0X9A) | (6) | No.-1 (255) | No.-2 (255) | 1381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1382 | Extended | Extended | EzIP ID | EzIP | 1383 7 | Source | Source | (Destination) | Option Length | 1384 | No.-3 (255) | No.-4 (255) | (0X9B) | (6) | 1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 | Extended | Extended | Extended | Extended | 1387 8 | Destination | Destination | Destination | Destination | 1388 | No.-1 (246) | No.-2 (1) | No.-3 (6) | No.-4 (40) | 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 Figure 14 EzIP Header: From T1z to RG1 1393 A.2.2. RG1 Forwards the Packet to SPR1 1395 RG1, allowing to be masqueraded by T1z, relays a packet as in 1396 Figure 15, toward SPR1 by assigning the TCP Source port number, 9N, 1397 to T1z. Not knowing whether T4z is behind an RG, "All 1's" is used to 1398 fill the Destination Port part of the TCP word. 1400 0 1 2 3 1401 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 1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1403 1 |Version|IHL (9)|Type of Service| Total Length (36) | 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 2 | Identification |Flags| Fragment Offset | 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1407 3 | Time to Live | Protocol | Header Checksum | 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 4 | Source Host Number (240.0.0.0) | 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 5 | Destination Host Number (69.41.190.148) | 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1413 | EzIP ID | EzIP | Extended | Extended | 1414 6 | (Source) | Option Length | Source | Source | 1415 | (0X9A) | (6) | No.-1 (255) | No.-2 (255) | 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 | Extended | Extended | EzIP ID | EzIP | 1418 7 | Source | Source | (Destination) | Option Length | 1419 | No.-3 (255) | No.-4 (255) | (0X9B) | (6) | 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 | Extended | Extended | Extended | Extended | 1422 8 | Destination | Destination | Destination | Destination | 1423 | No.-1 (246) | No.-2 (1) | No.-3 (6) | No.-4 (40) | 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 9 | Source Port (9N) | Destination Port (All 1's) | 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1428 Figure 15 TCP/EzIP Header: From RG1 to SPR1 1430 A.2.3. SPR1 Sends the Packet to SPR4 through the Internet 1432 SPR1 replaces the Source Host Number with its own as well as fills in 1433 the Extended Source No. information, and then sends the packet, with 1434 a header as in Figure 166, out into the Internet towards SPR4. The 1435 packet traverses through ER1, CR and ER4, utilizing only the 1436 Destination Host Number (Word 5) in the IP Header. 1438 0 1 2 3 1439 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 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1441 1 |Version|IHL (9)|Type of Service| Total Length (36) | 1442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 2 | Identification |Flags| Fragment Offset | 1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1445 3 | Time to Live | Protocol | Header Checksum | 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 4 | Source Host Number (69.41.190.110) | 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 5 | Destination Host Number (69.41.190.148) | 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 | EzIP ID | EzIP | Extended | Extended | 1452 6 | (Source) | Option Length | Source | Source | 1453 | (0X9A) | (6) | No.-1 (240) | No.-2 (0) | 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 | Extended | Extended | EzIP ID | EzIP | 1456 7 | Source | Source | (Destination) | Option Length | 1457 | No.-3 (0) | No.-4 (0) | (0X9B) | (6) | 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 | Extended | Extended | Extended | Extended | 1460 8 | Destination | Destination | Destination | Destination | 1461 | No.-1 (246) | No.-2 (1) | No.-3 (6) | No.-4 (40) | 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 9 | Source Port (9N) | Destination Port (All 1's) | 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1466 Figure 16 TCP/EzIP Header: From SPR1 to SPR4 1468 A.2.4. SPR4 Sends the Packet to T4z 1470 SPR4 reconstructs T4z address from the Option number 0X9B and the 1471 Extended Destination No. then sends the packet, with the header as in 1472 Figure 17, to T4z. 1474 0 1 2 3 1475 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 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 1 |Version|IHL (9)|Type of Service| Total Length (36) | 1478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1479 2 | Identification |Flags| Fragment Offset | 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1481 3 | Time to Live | Protocol | Header Checksum | 1482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1483 4 | Source Host Number (69.41.190.110) | 1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 5 | Destination Host Number (246.1.6.40) | 1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1487 | EzIP ID | EzIP | Extended | Extended | 1488 6 | (Source) | Option Length | Source | Source | 1489 | (0X9A) | (6) | No.-1 (240) | No.-2 (0) | 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 | Extended | Extended | EzIP ID | EzIP | 1492 7 | Source | Source | (Destination) | Option Length | 1493 | No.-3 (0) | No.-4 (0) | (0X9B) | (6) | 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 | Extended | Extended | Extended | Extended | 1496 8 | Destination | Destination | Destination | Destination | 1497 | No.-1 (246) | No.-2 (1) | No.-3 (6) | No.-4 (40) | 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1499 9 | Source Port (9N) | Destination Port (All 1's) | 1500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 Figure 17 TCP/EzIP Header: From SPR4 to T4z 1504 A.2.5. T4z Replies to SPR4 1506 Making use of the information in the incoming TCP/EzIP header, T4z 1507 replies to SPR4 with a full header, as in Figure 18. 1509 0 1 2 3 1510 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 1511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1512 1 |Version|IHL (9)|Type of Service| Total Length (36) | 1513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1514 2 | Identification |Flags| Fragment Offset | 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1516 3 | Time to Live | Protocol | Header Checksum | 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 4 | Source Host Number (246.1.6.40) | 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 5 | Destination Host Number (69.41.190.110) | 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 | EzIP ID | EzIP | Extended | Extended | 1523 6 | (Source) | Option Length | Source | Source | 1524 | (0X9A) | (6) | No.-1 (246) | No.-2 (1) | 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1526 | Extended | Extended | EzIP ID | EzIP | 1527 7 | Source | Source | (Destination) | Option Length | 1528 | No.-3 (6) | No.-4 (40) | (0X9B) | (6) | 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 | Extended | Extended | Extended | Extended | 1531 8 | Destination | Destination | Destination | Destination | 1532 | No.-1 (240) | No.-2 (0) | No.-3 (0) | No.-4 (0) | 1533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1534 9 | Source Port (All 1's) | Destination Port (9N) | 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 Figure 18 TCP/EzIP Header: From T4z to SPR4 1539 A.2.6. SPR4 Sends the Packet to SPR1 through the Internet 1541 SPR4 replaces the Source Host Number with its own, and sends the 1542 packet with the header, as in Figure 19, towards SPR1. The Internet 1543 (ER4, CR, and ER1) simply relays the packet according to the TCP/EzIP 1544 header word 5 (Destination Host Number): 1546 0 1 2 3 1547 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 1548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1549 1 |Version|IHL (9)|Type of Service| Total Length (36) | 1550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1551 2 | Identification |Flags| Fragment Offset | 1552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 3 | Time to Live | Protocol | Header Checksum | 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1555 4 | Source Host Number (69.41.190.148) | 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 5 | Destination Host Number (69.41.190.110) | 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 | EzIP ID | EzIP | Extended | Extended | 1560 6 | (Source) | Option Length | Source | Source | 1561 | (0X9A) | (6) | No.-1 (246) | No.-2 (1) | 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 | Extended | Extended | EzIP ID | EzIP | 1564 7 | Source | Source | (Destination) | Option Length | 1565 | No.-3 (6) | No.-4 (40) | (0X9B) | (6) | 1566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1567 | Extended | Extended | Extended | Extended | 1568 8 | Destination | Destination | Destination | Destination | 1569 | No.-1 (240) | No.-2 (0) | No.-3 (0) | No.-4 (0) | 1570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1571 9 | Source Port (All 1's) | Destination Port (9N) | 1572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 Figure 19 TCP/EzIP Header: From SPR4 to SPR1 1576 A.2.7. SPR1 Sends the Packet to RG1 1578 SPR1 reconstructs RG1 address from the Option number 0X9B and the 1579 Extended Destination No. Then, sends packet with a header as in 1580 Figure 20 toward RG1. 1582 0 1 2 3 1583 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 1584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1585 1 |Version|IHL (9)|Type of Service| Total Length (36) | 1586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1587 2 | Identification |Flags| Fragment Offset | 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 3 | Time to Live | Protocol | Header Checksum | 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1591 4 | Source Host Number (69.41.190.148) | 1592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 5 | Destination Host Number (240.0.0.0) | 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 | EzIP ID | EzIP | Extended | Extended | 1596 6 | (Source) | Option Length | Source | Source | 1597 | (0X9A) | (6) | No.-1 (246) | No.-2 (1) | 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1599 | Extended | Extended | EzIP ID | EzIP | 1600 7 | Source | Source | (Destination) | Option Length | 1601 | No.-3 (6) | No.-4 (40) | (0X9B) | (6) | 1602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 | Extended | Extended | Extended | Extended | 1604 8 | Destination | Destination | Destination | Destination | 1605 | No.-1 (240) | No.-2 (0) | No.-3 (0) | No.-4 (0) | 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 9 | Source Port (All 1's) | Destination Port (9N) | 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1610 Figure 20 TCP/EzIP Header: From SPR1 to RG1 1612 A.2.8. RG1 Forwards the Packet to T1z 1614 RG1 reconstructs T1z address from RG1's RG-NAT state-table based on 1615 Destination Port (9N), then sends the packet to T1z with a header as 1616 in Figure 21. 1618 0 1 2 3 1619 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 1620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 1 |Version|IHL (9)|Type of Service| Total Length (36) | 1622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1623 2 | Identification |Flags| Fragment Offset | 1624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1625 3 | Time to Live | Protocol | Header Checksum | 1626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1627 4 | Source Host Number (69.41.190.148) | 1628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1629 5 | Destination Host Number (192.168.1.9) | 1630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1631 | EzIP ID | EzIP | Extended | Extended | 1632 6 | (Source) | Option Length | Source | Source | 1633 | (0X9A) | (6) | No.-1 (246) | No.-2 (1) | 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 | Extended | Extended | EzIP ID | EzIP | 1636 7 | Source | Source | (Destination) | Option Length | 1637 | No.-3 (6) | No.-4 (40) | (0X9B) | (6) | 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1639 | Extended | Extended | Extended | Extended | 1640 8 | Destination | Destination | Destination | Destination | 1641 | No.-1 (240) | No.-2 (0) | No.-3 (0) | No.-4 (0) | 1642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1643 9 | Source Port (All 1's) | Destination Port (9N) | 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1646 Figure 21 TCP/EzIP Header: From RG1 to T1z 1648 A.2.9. T1z Sends a Follow-up Packet to RG1 1650 With all fields filled with needed information from the incoming 1651 TCP/EzIP header, T1z sends a follow-up packet to RG1 as in Figure 22. 1653 0 1 2 3 1654 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 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1656 1 |Version|IHL (9)|Type of Service| Total Length (36) | 1657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1658 2 | Identification |Flags| Fragment Offset | 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 3 | Time to Live | Protocol | Header Checksum | 1661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1662 4 | Source Host Number (192.168.1.9) | 1663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1664 5 | Destination Host Number (69.41.190.148) | 1665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1666 | EzIP ID | EzIP | Extended | Extended | 1667 6 | (Source) | Option Length | Source | Source | 1668 | (0X9A) | (6) | No.-1 (240) | No.-2 (0) | 1669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1670 | Extended | Extended | EzIP ID | EzIP | 1671 7 | Source | Source | (Destination) | Option Length | 1672 | No.-3 (0) | No.-4 (0) | (0X9B) | (6) | 1673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1674 | Extended | Extended | Extended | Extended | 1675 8 | Destination | Destination | Destination | Destination | 1676 | No.-1 (246) | No.-2 (1) | No.-3 (6) | No.-4 (40) | 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1678 9 | Source Port (9N) | Destination Port (All 1's) | 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1681 Figure 22 TCP/EzIP Header: Follow-up Packets from T1z to RG1 1683 A.3. Connection Between EzIP-unaware and EzIP-capable IoTs 1685 A.3.1. T1a Initiates a Request to T4z 1687 Since T1a can create only conventional format IP header, the SPRs 1688 will provide CG-NAT type of services to the TCP/IP packets. And, 1689 assuming SPR4 has a state-table set up by DMZ for forwarding the 1690 request to T4z, the packet will be delivered to T4z. Seeing the 1691 incoming packet with conventional TCP/IP header, T4z should respond 1692 with the same so that the session will be conducted with conventional 1693 TCP/IP headers. The interaction will follow the same behavior as in 1694 Appedix A.1. 1696 A.3.2. T1z Initiates a Request to T4a 1698 Knowing T4a is not capable of EzIP header, T1z purposely initiates 1699 the request packet using conventional IP header. It will be treated 1700 by SPRs in the same manner as the T1a initiated case as in Appedix 1701 A.1. so that the packet will be recognizable by T4a. 1703 Note that to maximize the combination in the EzIP System Architecture 1704 diagram (Figure 1) for demonstrating the possible variations, there is 1705 no RG on Premises 4. IoTs, such as T4a and T4z, are thus directly 1706 connected to a SPR, like SPR4 and there is no corresponding TCP port 1707 number in word 9 of the above TCP/EzIP headers. This spare facility in 1708 the header suggests that an RG may be installed if desired, to establish 1709 the similar private network environment as that on Premises 1. 1711 In brief, the steps outlined above are very much the same as the 1712 conventional TCP/IP header transitions through the Internet with the SPR 1713 providing the CG-NAT service. Except, when a TCP/EzIP header is 1714 detected, the SPR switches to the router mode for forwarding the packet 1715 to improve the performance. 1717 In essence, with the EzIP system architecture very much the same as 1718 today's Internet, the SPR starts with assuming the current CG-NAT duty, 1719 while ready to perform the new EzIP routing function for EzIP-aware 1720 IoTs. This strategy offers a simple transition path for the Internet to 1721 evolve toward the future. 1723 It is important to note that both SPR and CG-NAT are inline devices with 1724 respect to ER. However, since CG-NAT provides soft / ephemeral TCP 1725 ports, it is positioned between a CR and ERs, while SPR is located 1726 between an ER and RGs to assign hard / static physical addresses. 1728 Appendix B Internet Transition Considerations 1730 To enhance a large communication system like the Internet, it is 1731 important to minimize the disturbance to the existing equipments and 1732 processes due to any required modification. The basic EzIP plan is to 1733 confine all actionable enhancements within the new SPR module(s). The 1734 following outlines the considerations for supporting the transition 1735 from the current Internet to the one enhanced by the EzIP technique. 1737 B.1. EzIP Implementation 1739 B.1.1. Introductory Phase: 1741 A. Insert an SPR in front of a web-server that desires to have 1742 additional subnet addresses for offering diversified activities. This 1743 configuration is commonly referred to as a reverse proxy. For the 1744 long term, a new web server may be designed with these two functional 1745 modules combined. 1747 . The first address of a private network address pool, e.g., 1748 242.0.0.0, used by the SPR should be reserved as a DMZ channel 1749 directing the initial incoming service requesting packets to the 1750 existing web server. This will maintain the same current operation 1751 behavior projected to the general public. 1753 . The additional addresses, up to 255.255.255.255 may be used for 1754 EzIP address extension purposes. Each may be assigned to an 1755 additional web server representing one of the business's new 1756 activities. Each of these new servers will then respond with EzIP 1757 header to messages forwarded from the main server, or be directly 1758 accessible through its own EzIP address. 1760 B. Insert an SPR in front of a group of subscribers who are to be 1761 served with the EzIP capability. The basic service provided by this 1762 SPR will be the CG-NAT equivalent function. This will maintain the 1763 same current baseline user experience in accessing the Internet. 1765 C. Session initiating packets with basic IPv4 header will be routed 1766 by SPRs to a business's existing server at the currently published 1767 IPv4 public address (discoverable through existing DNS). The server 1768 should respond with the basic IPv4 format as well. Essentially, this 1769 maintains the existing user experience between a customer and a web 1770 server within an EzIP-unaware environment. 1772 So far, neither the web-server nor any subscriber's IoTs needs to 1773 be enhanced, because the operations remain pretty much the same as 1774 today's common practice utilizing CG-NAT assisted connectivity. See 1775 Appendix A.1. for an example. 1777 D. Upon connection to the main web server, if a customer 1778 intentionally selects one of the new services, the main web server 1779 should ask the customer to confirm the selection. 1781 . If confirmed, implying that the customer is aware of the fact 1782 that his IoT is being served by an SPR, the web server forwards the 1783 request to a branch server for carrying on the session via an EzIP 1784 address. 1786 . The SPR on the customer side, recognizing the EzIP header from 1787 the branch web-server, replaces the CG-NAT service with the EzIP 1788 routing. 1790 . For all subsequent packets exchanged, the EzIP headers will be 1791 used in both directions. This will speed up the transmission 1792 throughput performance for the rest of the session. See Appendix A.2. 1793 for an example. 1795 B.1.2. New IoT Operation Modes: 1797 A. EzIP-capable IoT will create EzIP header in initiating a session, 1798 to directly reach a specific EzIP-capable web-server, instead of the 1799 manual interaction steps of going through the DMZ port then making 1800 the selection from the main web server. This will speed up the 1801 initial handshake process. See Appendix A.2. for an example. 1803 B. To communicate with an EzIP-unaware IoT, an EzIP-capable IoT 1804 should purposely initiate a session with conventional IP header. This 1805 will signal the SPRs to provide just the CG-NAT type of connection 1806 service. See Appendix A.1. for an example. 1808 B.1.3. End-to-End Operation: 1810 Once EzIP-capable IoTs become wide spread among the general public, 1811 direct communication between any pair of such IoTs will be 1812 achievable. An EzIP-capable IoT, knowing the other IoT's full EzIP 1813 address, may initiate a session by creating an EzIP header that 1814 directs SPRs to provide EzIP service, bypassing the CG-NAT process. 1815 See Appendix A.2. for an example. 1817 B.2. SPR Operation Logic 1819 To support the above scenarios, the SPR should be designed with the 1820 following decision process: 1822 B.2.1. Sending an IP packet out for an IoT or a RG 1824 If the IP header contains EzIP Option word, SPR will route it forward 1825 by using the EzIP mechanism (replacing Source Host Number by SPR's 1826 own and filling in Extended Source No. if not already there). 1827 Otherwise, the SPR provides the CG-NAT service (assigning TCP Source 1828 Port number and allowing the packet to masquerade with the SPR's own 1829 IP address, plus creating an entry to the state (port-forward / look- 1830 up / hash) table in anticipation of the reply packet). 1832 B.2.2. Receiving an IP packet from the ER 1834 If a received IP packet includes a valid EzIP Option word, SPR will 1835 provide the EzIP routing service (utilizing the Extended Destination 1836 No. as the Destination Host Number). If only Destination Port number 1837 is present, CG-NAT service will be provided. For a packet with plain 1838 IP header (with neither EzIP nor CG-NAT information), it will be 1839 dropped. 1841 B.3. RG Enhancement 1843 With IPv4 address pool expanded by the EzIP schemes, there will be 1844 sufficient publicly assignable addresses for IoTs wishing to be 1845 directly accessible from the Internet. On the other hand, the 1846 existing private networks may continue their current behavior of 1847 blocking session-request packets from the Internet. In-between, 1848 another connection mode is possible. The following describes such an 1849 option in the context of the existing RG operation conventions. 1851 B.3.1. Initiating Session request for an IoT 1853 Without regard to whether the IP header is a conventional type or an 1854 EzIP one, a RG allows a packet to masquerade with the RG's own IP 1855 address by assigning a TCP port number to the packet and creating an 1856 entry to the state (port-forward / look-up / hash) table. This is the 1857 same as the current RG-NAT practice. 1859 B.3.2. Receiving a packet from the SPR 1861 The "Destination Port" value in the packet is examined: 1863 A. If it matches with an entry in the RG-NAT's state-table, the 1864 packet is forwarded to the corresponding address. This is the same as 1865 the normal RG-NAT processes in a conventional RG. 1867 B. If it matches with the IP address of an active IoT on the 1868 private network, the packet is assigned with a TCP port number and 1869 then forwarded to that IoT. 1871 Note that there is certain amount of increased security risk with 1872 this added last step, because a match between a guessed destination 1873 identity and either of the above two lists could happen by chance. To 1874 address this issue, the following proactive mechanism should be 1875 incorporated in parallel: 1877 C. If the "Destination Port" number is null or matches with 1878 neither of the above two lists, the packet is dropped and an alarm 1879 state is activated to monitor for possible ill-intended follow-up 1880 attempts. A defensive mechanism should be triggered when the number 1881 of failed attempts has exceeded the preset threshold within a 1882 predetermined finite time interval. 1884 In brief, if the IP header of a session requesting packet indicates 1885 that the sender knows the identity of the desired destination IoT on 1886 a private network, the common RG screening process will be bypassed. 1887 This facilitates the direct end-to-end connection, even in the 1888 presence of the RG-NAT. Note that this process is very much the same 1889 as the AA (Automated Attendant) capability in a PABX telephone 1890 switching system that automatically makes the connection for a caller 1891 who indicates (via proper secondary dialing or an equivalent means) 1892 knowing the extension number of the destination party. Such process 1893 effectively screens out most of the unwanted callers while serving 1894 the acquaintance expeditiously. 1896 Appendix C EzIP Realizability 1898 The EzIP scheme proposes a new type of network router, called SPR, 1899 capable of utilizing 240/4 address transported via the Option word 1900 mechanism in the EzIP Header. In particular, EzIP may optimally be 1901 first deployed in the form of a Regional Area Network (RAN) wherever 1902 desired. Each RAN starts from one IPv4 public address to serve up to 1903 256M IoTs. For such a configuration, an SPR will operate with the 1904 degenerated EzIP Header which is identical to the basic IPv4 Header, 1905 except the addresses are from the 240/4 netblock. Since this can be 1906 accomplished by simply expanding the scope of the accessible address 1907 pool within the IPv4 protocol, there is hardly any need to modify the 1908 design of existing routers. 1910 Having been "Reserved for Future Use" for so long (since 1981-09), 1911 however, it is a challenge to identify current equipments that may be 1912 conducive to the use of the 240/4 netblock. Un-documented behaviors, 1913 observed through extensive research and testing of products in-use 1914 and on-the-market as well as public domain firmware, confirm that 1915 certain pairs of router and IoT / PC OS are already partially 1916 supporting this mode of operation. This unexpected discovery sets the 1917 baseline for the following interim report. 1919 C.1. 240/4 Netblock Capable IoTs 1921 A. Open source Xubuntu OS (V.18.04.1) enables a PC to assume both 1922 dynamic and static IP addresses, through the same physical Ethernet 1923 port, simultaneously. The former operates in the default DHCP client 1924 mode with conventional three private netblocks, while the latter 1925 accepts manually set static addresses including those from the 240/4 1926 netblock. Making use of this "dual personality", connectivity between 1927 two similarly equipped PCs can be established first through a 1928 compatible router (described in the next subsection) by "ping"ing 1929 each other with the dynamic address. Using the static 240/4 1930 addresses, the additional networking channel through the same router 1931 can then be confirmed. 1933 B. Several other PC OSs, such as Chrome (V.74.0.3729.125), LinuxMint 1934 V.19 tara (Ubuntu V.4.15.0), Mojave (OSX 10.14.1) and Ubuntu 19.04 1935 (Ubuntu 5.0.0), have been found to behave similarly, although 1936 partially and not as conveniently. 1938 C.2. 240/4 Netblock Capable Routers 1940 A. Open source router firmware OpenWrt (V18.06.1) currently does not 1941 utilize the 240/4 netblock in its DHCP operation, while it would not 1942 reject the process of specifying such but would not function properly 1943 afterwards. Yet, it transports, in its native configuration, 240/4 1944 addressed "ping" packets between two 240/4 capable PCs anyway. 1946 B. Also, a common RG, TP-Link Archer C20 AC750 (F/W V4_170222 / 1947 0.9.13.16 v0348.0) rejects setting its DHCP pool to use the 240/4 1948 netblock, but transports 240/4 addressed "ping" packets, nonetheless. 1950 C. Similarly, Verizon FiOS-G1100 RG (H/W: 1.03, F/W: 02.02.00.14 UI 1951 Ver: v1.0.388) will not allow its DHCP server to utilize the 240/4 1952 netblock, but transports the 240/4 addressed "ping" packets, just 1953 fine. 1955 D. Other routers, such as LinkSys E3000 (DD-WRT v24-sp2 (05/27/13) 1956 mini (SVN Rev. 21676), have been found to exhibit similar behavior. 1958 E. Furthermore, test data suggest that 240/4 addressed "ping" and 1959 "traceroute" packets from some of the above setups could have 1960 propagated through an IAP's ER (108.30.229.xxx, Verizon's Edge 1961 Router) into the Internet. The addresses (130.81.171.xxx) that they 1962 arrrived at appear to be Verizon's internal routers. If these are not 1963 CRs (Core Routers), at least they are ARs (Aggregate Routers). 1965 C.3. Enhancing an RG 1967 The above observations suggest that Xubuntu OS based PCs are likely 1968 ready to network as 240/4 addressed DHCP clients. To complement this 1969 capability, we need a router that can function as a 240/4 DHCP 1970 server. Although the OpenWrt firmware appears to be closer to this 1971 desired functionality than the TP-Link Router, the source code of the 1972 latter being hardware specific would better facilitate the firmware 1973 enhancement efforts. Accordingly, the following outlines the steps 1974 being planned to bring TP-Link Router and Xubuntu OS based PCs up to 1975 a state for performing the essential SPR functions: 1977 C.3.1. Enhance the TP-Link Router firmware to include the 240/4 1978 netblock in its DHCP pool. 1980 C.3.2. Verify that Xubuntu OS based PCs will accept 240/4 based 1981 DHCP assignment from the enhanced Router above. With this, deactivate 1982 the static address settings in the PCs. 1984 C.3.3. Send 240/4 destined traffic between two Xubuntu PCs to be 1985 sure that it is transported through the Router. Three tests will be 1986 conducted; sending "ping" and "traceroute" packets to confirm the 1987 basic connectivity as well as file transfer to verify TCP/IP 1988 capability. 1990 C.3.4. A separate second TP-Link Router will then be plugged into 1991 this first Router as a client IoT to verify that it would accept a 1992 240/4 address as its WAN port designation. Based on this, the second 1993 Router will serve as an RG providing the conventional private network 1994 environment (10/8, 172.16/12 and 192.168/16 netblocks) to common 1995 IoTs, allowing them to continue their current operations without 1996 modification, at all. 1998 C.4. SPR Reference Design 2000 The above pair of enhanced Routers can be used as the SPR model for 2001 enahancing industrial grade routers that are capable of the daily 2002 traffic level expected by a RAN. 2004 Note that including 240/4 netblock in the DHCP pool for the LAN of 2005 the first Router and accepting the 240/4 address assignment on the 2006 WAN port of the second Router are two orthogonal capabilities. They 2007 can be implemented in the same physical Router, consolidating both 2008 modifications into one single SPR module. 2010 C.5. RAN Deployment Model 2012 The above SPR reference design is essentially an existing common IPv4 2013 RG with two simple enhancements: 2015 I. Upstream (WAN) port capable of being a DHCP client accepting 240/4 2016 address assignment, in addition to the ordinary IPv4 public address. 2018 II. Downstream (LAN) port providing DHCP service to client IoTs 2019 using the 240/4 netblock, in addition to the three conventional 2020 private netblocks. 2022 By selectively activating these capabilities, three versions of SPRs 2023 can be derived for completing a functional RAN model: 2025 C.5.1. Root / Gateway SPR: This is the first SPR for starting a 2026 RAN from an IPv4 public address. As such, the upstream port of this 2027 SPR should accept a public IPv4 address. And, its downstream port 2028 will use the 240/4 netblock in its DHCP pool. 2030 Note that this particular type of SPR is only needed for a RAN 2031 demonstration setup. In an actual RAN deployment, a proxy gateway 2032 that caches the Internet traffic for improving the operation 2033 efficiency will naturally perform the same function of this Root SPR, 2034 by virtue of being a more capable two-port device. 2036 C.5.2. Intermediate SPRs: To optimize the performance 2037 requirements on the routing processor, a practical SPR is not 2038 expected to handle all 256M IoTs in a single module. A RAN should 2039 have several layers of SPRs in a tree structure, each handles a 2040 subset of the 240/4 netblock. This architecture enables processing 2041 local traffic locally. Only communications with distance parties need 2042 be consoliated by going through the higher layers of SPRs for 2043 delivery. For this type of SPRs, both their upstream DHCP client port 2044 and downstream DHCP Server pool will operate on sub-240/4 netblocks, 2045 segregated according to the numbering plan in the RAN system design. 2047 C.5.3. RG SPR: To serve existing IoTs on customer premises, this 2048 SPR will be configured to accept a 240/4 address on its upstream 2049 port, while the downstream port assigns addresses from the three 2050 conventional private netblocks to its DHCP client IoTs. 2052 Appendix D Enhancement of a Commercial RG 2054 Since the 240/4 netblock is just one part of the full IPv4 address 2055 pool, there is nothing special about it. In principle, all we need to 2056 do to utilize it is to include it within the usable ranges of a 2057 router's addresses. However, perhaps because it has been reserved for 2058 so long, hardly anyone has been paying attention to how the 240/4 2059 netblock has been treated in current router programs. An intuitive 2060 assumption is that there may be a database that lists all acceptable 2061 address ranges or netblocks. If so, the EzIP enhancement would entail 2062 adding the 240/4 netblock to the list. On the other hand, the current 2063 approach maybe is based on singling out specific unusable IP 2064 addresses. Then, eliminationg such process is sufficient. It turns 2065 out that a commercial RG product appears to be operating with the 2066 latter approach. From such, the task would become simply commenting 2067 out the program statements that are rejecting the 240/4 netblock. 2069 D.1. Candidate Code for Modification 2071 The following short JavaScript function named "ifip" in the TP-Link 2072 Archer C20 V4 source code has been shown to selectively reject 2073 specific ranges of IP addresses. In particular, Line 1047 uses a "2's 2074 Complement" technique to identify the 240/4 netblock as "PRESERVED", 2075 thus rejecting it. A quick scan of the firmware code in the router 2076 indicates that this function is a popular utility because there are 2077 numerous processes calling for it. So, this should be the best 2078 candidate to start testing our concept. 2080 lib.js:1040:ifip: function(ip, unalert) { 2081 lib.js-1041-if ((ip = $.ip2num(ip)) === false) return $.alert(ERR_IP_FORMAT, unalert); 2082 lib.js-1042-if (ip == -1) return $.alert(ERR_IP_BROADCAST, unalert); 2083 lib.js-1043-var net = ip >> 24; 2084 lib.js-1044-if (net == 0) return $.alert(ERR_IP_SUBNETA_NET_0, unalert); 2085 lib.js-1045-if (net == 127) return $.alert(ERR_IP_LOOPBACK, unalert); 2086 lib.js-1046-if (net >= -32 && net < -16) return $.alert(ERR_IP_MULTICAST, unalert); 2087 lib.js-1047-if (net >= -16 && net < 0) return $.alert(ERR_IP_PRESERVED, unalert); 2088 lib.js-1048-return 0; 2089 lib.js-1049-}, 2091 D.2. Proposed Modification 2093 To stop rejecting the 240/4 netblock addressed packets, below is a 2094 modification that comments out Line 1047, a modification that has 2095 been shown to eliminate javascript pre-validation of 240/4 IP 2096 addresses, allowing them to be sent within the router, where a second 2097 layer of validation rejects them in a different way. 2099 lib.js:1040: ifip: function(ip, unalert) { 2100 lib.js-1041- if ((ip = $.ip2num(ip)) === false) return $.alert(ERR_IP_FORMAT, unalert); 2101 lib.js-1042- if (ip == -1) return $.alert(ERR_IP_BROADCAST, unalert); 2102 lib.js-1043- var net = ip >> 24; 2103 lib.js-1044- if (net == 0) return $.alert(ERR_IP_SUBNETA_NET_0, unalert); 2104 lib.js-1045- if (net == 127) return $.alert(ERR_IP_LOOPBACK, unalert); 2105 lib.js-1046- if (net >= -32 && net < -16) return $.alert(ERR_IP_MULTICAST, unalert); 2106 lib.js-1047- //if (net >= -16 && net < 0) return $.alert(ERR_IP_PRESERVED, unalert); 2107 lib.js-1048- return 0; 2108 lib.js-1049-}, 2110 D.3. Performance Verification 2112 Initially, the TP-Link Archer C20 router's GPL source code package 2113 from the manufacturer would not go through compilation process. A 2114 revised version allowed us to build a firmware file. Yet, it failed 2115 in loading into the hardware. Interactions continue with the 2116 manufacturer hoping to resolve this basic issue soon. Unfortunately, 2117 this issue remains pending to this day. 2119 Appendix E Utilizing Open Source Router Code 2121 An alternative to the above is to make use of open source router 2122 codes for the EzIP implementation. The advantage of this approach is 2123 that once it is verified in one commercial router, interested parties 2124 may then load the same vintage of open source codes to their own 2125 preferred routers for replicating the operation. The challenge to 2126 this approach, however, is that open source codes are "generic" for 2127 supporting a wide range of brands and models. Customization must be 2128 made to adapt it for a specific router model to generate an 2129 executable binary file for the target device as its firmware. As 2130 well, this configuration information will be needed each time the 2131 source code is modified for a new application, such as the EzIP. 2132 Interestingly, such knowledge appeared to be not in an "open" 2133 document. In the process of studying such, we discovered that OpenWrt 2134 was planning to enhance its Linux core which included the removal of 2135 the current restriction on using 240/4. Although their intention was 2136 to be able to use the 240/4 pool as the fourth private netblock, such 2137 capability suited our EzIP scheme just fine. So, we waited for the 2138 release of the OpenWrt 19.07 and further for its more stable OpenWrt 2139 19.07.2 version, before attempting the EzIP application. Below is a 2140 WIP report of our test results based on OpenWrt 19.07.3. 2142 E.1. EzIP Realizability Test Bed 2144 The first step is to create a LAN environment served by a router 2145 utilizing the 240/4 netblock. Upon loaded OpenWrt 19.07.3 into a 2146 commercial TP-Link Archer C20 V4 Router, it operated with 240/4 2147 address pool as if it was the fourth private netblock. IoTs capable 2148 of utilizing 240/4 netblock operated fine under this environment. 2149 Specifics of this effort is reported on Page 2 of the following 2150 whitepaper: 2152 https://www.avinta.com/phoenix- 2153 1/home/RegionalAreaNetworkArchitecture.pdf 2155 E.2. RAN Architecture Demonstration 2157 The goal of a RAN Demo is to transport a conventional IPv4 (public) 2158 netblock addressed IP packet though a 240/4 environment and then back 2159 to an IPv4 private network operating with one of the three 2160 conventional netblocks (10/8, 172.16/12 or 192.168/16). This process 2161 will increase the assignable addresses, while allowing all IoTs to 2162 retain their existing operation characteristics. To simuate such a 2163 RAN, we need a RG that can operate as a client in the 240/4 2164 environment established by Apppendix E.1. above, while maintaining 2165 its DHCP LAN service to a conventional private network. It has been 2166 identified that besides OpenWrt 19.07.3 supported routers, at least 2167 one RG (Sagemcom RAC2V1S) provided by Spectrum cable service delivers 2168 this function. Page 4 of the above whiitepaper details the 2169 configuration and operation of such a RAN. In addition, during past 2170 experiments, RG for Verizon's FiOS service was found to be already 2171 transporting 240/4 addressed packets, as well. Combined, this means 2172 that most of existing private networks may continue normal operations 2173 under the inserted RAN environment while the latter provides 2174 assignable 240/4 addresses to additional premises for expanding the 2175 system capacity. 2177 E.3. EzIP Compatible Routers 2179 At the last count, there were 1091 branded router models supported by 2180 OpenWrt 21.02.1. In fact, it turns out that for an existing IPv4 2181 router to become an SPR for supporting the EzIP operation, all needs 2182 be done is "disabling the existing program code that has been 2183 disabling the use of the 240/4 netblock". Such effort is expected to 2184 be rather minimal for parties having control of the relevant program 2185 source codes. Consequently, most existing IPv4 routers should be able 2186 to support EzIP through finite enhancement processes, even if they 2187 are currently not supported by OpenWrt 19.07.3 (or newer). 2189 Appendix F Sub-Internet 2191 Since each RAN serving up to 256M IoTs can be operated with just one 2192 IPv4 address for interacting with the Internet, it follows that if a 2193 buffering device is inserted inline between the two for relaying 2194 requests to the Internet and caching the responses from the Internet, 2195 a RAN could behave like a pseudo (although miniature) Internet from 2196 its clients' perspective for practical purposes. Such buffering 2197 function may be provided by a Gateway module which is commonly used 2198 by institutions for serving their respective LANs. Terminology wise, 2199 this Gateway is called Transparent / Intercepting Proxy as compared 2200 to other forms of cache proxies such as Peer Proxy, Reverse Proxy, 2201 etc. Combining a RAN with a Gateway, a Sub-Internet is formed that 2202 can operate as a stand-alone module to provide Internet services. 2203 Below is a brief description of a Gateway for serving a RAN. 2205 F.1. Gateway Configuration 2207 Besides the above mentioned caching functions, a Gateway, being a two 2208 port device, can also bridge two different netblocks together. This 2209 is convenient because the Gateway's upstream port uses the 2210 conventional public IPv4 address while the downstream port supports 2211 the RAN that runs on 240/4 netblock. However, this is not a 2212 necessity, because the root SPR in the RAN is configured, by default, 2213 as a DHCP client so that it can work from either netblock, anyway. 2215 F.2. Gateway Setup 2217 A Raspberry Pi4 single board computer loaded with Raspaian Buster 2218 Linux for Pi4 OS is used as the base for running a cache proxy 2219 (squid/oldstable,now 4.6-1+deb10u6 armhf) to serve as a Transparent 2220 Proxy. 2222 F.3. Sub-Internet Operation 2224 Several basic functions, such as web access, file transfer, eMial, 2225 etc. are being tested. Initial results are encouraging. The WIP (Work 2226 In Progress) file posted at the following URL has been updated to 2227 report the latest results of the ongoing efforts. 2229 https://www.avinta.com/phoenix-1/home/SubInternet_RJC.pdf 2231 Authors' Addresses 2233 Abraham Y. Chen 2234 Avinta Communications, Inc. 2235 142 N. Milpitas Blvd., #148, Milpitas, CA 95035-4401 US 2237 Phone: _+1(408)942-1485 2238 Email: AYChen@Avinta.com 2240 Abhay Karandikar 2241 Director, India Institute of Technology Kanpur 2242 Kanpur - 208 016, U.P., India 2244 Phone: _(+91)512 256 7220 2245 Email: Director@IITK.ac.in 2247 Ramamurthy R. Ati 2248 Avinta Communications, Inc. 2249 142 N. Milpitas Blvd., #148, Milpitas, CA 95035-4401 US 2251 Phone: _+1(408)458-7109 2252 Email: rama_ati@outlook.com 2254 David R. Crowe 2255 Wireless Telecom Consultant and Forensic Expert Witness 2256 102 Point Drive NW, Calgary, Alberta, T3B 5B3, Canada 2258 Phone: _+1(403)289-6609__ 2259 Email: David.Crowe@CNP-wireless.com