idnits 2.17.1 draft-chen-ati-adaptive-ipv4-address-space-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 7. IANA Considerations' ) ** The abstract seems to contain references ([15], [2], [16], [RFC791], [3], [17], [RFC862], [RFC2123], [4], [18], [RFC793], [19], [6], [RFC6598], [RFC2928], [7], [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 -- The document date (June 9, 2019) is 1773 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC6598' on line 819 -- Looks like a reference, but probably isn't: 'RFC791' on line 460 -- Looks like a reference, but probably isn't: 'RFC1918' on line 383 -- Looks like a reference, but probably isn't: 'RFC793' on line 418 -- Looks like a reference, but probably isn't: 'RFC2123' on line 421 -- Looks like a reference, but probably isn't: 'RFC1385' on line 501 -- Looks like a reference, but probably isn't: 'RFC862' on line 738 -- Looks like a reference, but probably isn't: 'RFC2928' on line 745 == Unused Reference: '5' is defined on line 988, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 995, but no explicit reference was found in the text -- 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: 4 errors (**), 0 flaws (~~), 5 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: December 2019 A. Karandikar 5 India Institute of Technology 6 David R. Crowe 7 Wireless Telcom Consultant 8 June 9, 2019 10 Adaptive IPv4 Address Space 11 draft-chen-ati-adaptive-ipv4-address-space-05.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 December 9, 2019. 36 Copyright Notice 38 Copyright (c) 2019 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 the IoT (Internet of Things) operations without 64 perturbing their setups, while offering end-users the freedom to 65 indepdently choose which service. EzIP may be implemented as a 66 software or firmware enhancement to Internet edge routers or private 67 network routing gateways, wherever needed, or simply installed as an 68 inline adjunct hardware module between the two, enabling a seamless 69 introduction. The 256M case detailed here establishes a complete 70 spherical layer of routers for interfacing between the Internet fabic 71 (core plus edge routers) and the end user premises. Incorporating 72 caching proxy technology in the gateway, a fairly large geographical 73 region may enjoy EzIP as address expansion using as little as one 74 ordinary IPv4 public address utilizing IP packets with degenerated 75 EzIP header. If IPv4 public pool allocations were reorganized, the 76 assignable pool could be multiplied by 512M times or even more. EzIP 77 will immediately resolve local IPv4 address shortages, while being 78 transparent to the rest of the Internet. Under the Dual-Stack 79 environment, these proposed interim facilities will relieve the IPv4 80 address shortage issue, while affording IPv6 more time to reach 81 maturity and to provide the availability levels required for 82 delivering a long-term general service. 84 Table of Contents 86 1. Introduction...................................................4 87 1.1. Contents of this Draft....................................5 88 2. EzIP Overview..................................................6 89 2.1. EzIP Numbering Plan.......................................6 90 2.2. Analogy with NAT..........................................7 91 2.3. EzIP System Architecture..................................8 92 2.4. IP Header with Option Word...............................10 93 2.5. Examples of Option Mechanism.............................11 94 2.6. EzIP Header..............................................12 95 2.7. EzIP Operation...........................................13 96 3. EzIP Deployment Strategy......................................13 97 4. Updating Servers to Support EzIP..............................16 98 5. EzIP Enhancement and Application..............................17 99 6. Security Considerations.......................................21 100 7. IANA Considerations...........................................21 101 8. Conclusions...................................................21 102 9. References....................................................22 103 9.1. Normative References.....................................22 104 9.2. Informative References...................................22 105 10. Acknowledgments..............................................23 106 Appendix A EzIP Operation.......................................24 107 A.1. Connection between EzIP-unaware IoTs.....................24 108 A.1.1. T1a Initiates a Session Request towards T4a.........24 109 A.1.2. RG1 Forwards the Packet to SPR1.....................25 110 A.1.3. SPR1 Sends the Packet to SPR4 through the Internet..26 111 A.1.4. SPR4 Sends the Packet to T4a........................27 112 A.1.5. T4a Replies to SPR4.................................28 113 A.1.6. SPR4 Sends the Packet to SPR1 through the Internet..29 114 A.1.7. SPR1 Sends the Packet to RG1........................30 115 A.1.8. RG1 Forwards the Packet to T1a......................31 116 A.1.9. T1a Sends a Follow-up Packet to RG1.................31 117 A.2. Connection Between EzIP-capable IoTs.....................32 118 A.2.1. T1z Initiates a Session Request towards T4z.........32 119 A.2.2. RG1 Forwards the Packet to SPR1.....................33 120 A.2.3. SPR1 Sends the Packet to SPR4 through the Internet..34 121 A.2.4. SPR4 Sends the Packet to T4z........................35 122 A.2.5. T4z Replies to SPR4.................................36 123 A.2.6. SPR4 Sends the Packet to SPR1 through the Internet..37 124 A.2.7. SPR1 Sends the Packet to RG1........................38 125 A.2.8. RG1 Forwards the Packet to T1z......................39 126 A.2.9. T1z Sends a Follow-up Packet to RG1.................40 127 A.3. Connection Between EzIP-unaware and EzIP-capable IoTs....41 128 A.3.1. T1a Initiates a Request to T4z......................41 129 A.3.2. T1z Initiates a Request to T4a......................41 130 Appendix B Internet Transition Considerations...................42 131 B.1. EzIP Implementation......................................42 132 B.2. SPR Operation Logic......................................43 133 B.3. RG Enhancement...........................................44 134 Appendix C EzIP Realizability...................................46 135 C.1. 240/4 Netblock Capable IoTs..............................46 136 C.2. 240/4 Netblock Capable Routers...........................46 137 C.3. Enhancing an RG..........................................47 138 C.4. SPR Reference Design.....................................48 139 C.5. RAN Deployment Model.....................................48 141 1. Introduction 143 For various reasons, there is a large demand for IP addresses. It 144 would be useful to have a unique address for more Internet devices, 145 such that, if desired, any device may call upon any other directly. 146 The Internet of Things (IoT) would also be able to make use of more 147 routable addresses if they were available. Currently, these are not 148 possible with the existing IPv4 configuration. 150 By Year 2020, the world population and number of IoTs are expected to 151 reach 7.6B (Billion) and 50B respectively, according to a 2011 Cisco 152 online white paper [3]. 154 In addition, IP addresses are needed while client devices, such as 155 mobile phones, are attached to the internet, which is an increasing 156 demand due to a rapidly increasing number of devices. 158 The IPv4 dot-decimal address format, consisting of four octets each 159 made of 8 binary bits, provides just over 4 billion unique addresses 160 (256 x 256 x 256 x 256 equals 4,294,967,296 - decimal exact). Using 161 the binary / shorthand notation of 64K representing 256 x 256 162 (decimal 65,536), the full IPv4 address pool of 64K x 64K may be 163 expressed as 4,096M (Million), or 4.096B (or, further rounded down to 164 4B for quick estimate calculations). Clearly, the predicted demand is 165 more than 12 times over the inherent capacity available from the 166 supply. 168 IPv6, with its 128-bit hexadecimal address format, is four times as 169 long as the IPv4, has 256BBBB (4B x 4B x 4B x 4B) unique addresses. 170 It offers a promising solution to the address shortage. However, its 171 global adoption appears to be facing significant challenges [4], 172 Error! Reference source not found.. 174 Interim relief to the IPv4 address shortage has been provided by 175 Network Address and Port Translation (NAPT - commonly known simply as 176 NAT) on private networks together with Carrier Grade NAT (CG-NAT or 177 abbreviated further to CGN) [RFC6598] Error! Reference source not 178 found. over the public Internet. However, NAT modules slow down 179 routers due to the state-table look-up process. As well, they only 180 allow an Internet session be initiated by their own clients, impeding 181 the end-to-end setup requests initiated from remote devices that a 182 fully functional communication system should be capable of. Being 183 dynamic, the state-table used by CGN increases CyberSecurity 184 vulnerability. Since port numbers are used to effectively increase 185 the size of the address pool, they introduce complex and suboptimal 186 port management requirements. 188 If IPv4 capacity could be expanded without the size and efficiency 189 limitations of NAT, the urgency will be relaxed long enough for the 190 IPv6 to mature on its own pace. 192 There have been several proposals to increase the effective Internet 193 public address pool in the past. They all introduced new techniques 194 or protocols that ran into certain handicaps or compatibility issues, 195 preventing a smooth transition. 197 EzIP utilizes a long-reserved network address block (netblock) 240/4 198 [7] that all of the existing Internet Core (/ backbone) Router (CR), 199 Edge Router (ER) and private network Routing (/ Residential) Gateway 200 (RG) as well as hosts such as IoTs are not allowed to utilize. This 201 is combined with the Option mechanism defined in [RFC791] [1] for 202 transporting such information as the IP header payload that is 203 transparent to all of these routers, except a newly defined category 204 named Semi-Public Router (SPR). By inserting an SPR between an ER and 205 a private premises that it serves, each publicly assignable address 206 can be expanded 256M fold. 208 EzIP introduces minimal perturbation by being compatible to the 209 current Internet system architecture. Its deployment will start with 210 an SPR providing public NAT functions to unload the burden from the 211 current CGN. With basic routing as an integral part of the SPR, 212 individual IoTs, or other large networks, will be encouraged to 213 migrate toward full EzIP service which provides end-to-end 214 connectivity between private premises. 216 1.1. Contents of this Draft 218 This draft outlines the EzIP numbering plan. An enhanced IP header, 219 called EzIP header, is introduced to carry the EzIP address as 220 payload using the Option word. How the Internet architecture will 221 change as the result of being extended by the EzIP scheme is 222 explained. How the EzIP header flows through various routers, and 223 Internet update considerations are described, with details presented 224 in Appendices A and B, respectively. Utilizing the EzIP approach, 225 several ways to expand the publicly assignable IPv4 address pool, as 226 well as enhance Internet operations are then discussed. Appendix C 227 outlines the experimental effort to demonstrate the feasibility of 228 EzIP by configuring a regional area network model based on current 229 networking equipment upon finite enhancements. 231 2. EzIP Overview 233 2.1. EzIP Numbering Plan 235 EzIP uses the reserved private network address pools in very much the 236 same way that Private Automatic Branch eXchange (PABX) switching 237 machines utilize locally assigned "extension numbers" to expand the 238 Public Switched Telephone Network (PSTN) capacity, by replicating a 239 public telephone line to multitudes of reusable private telephone 240 numbers, each to identify a local instrument. 242 At the first sight, this correlation may seem odd, because the PABX 243 extension numbers belong to a reusable private set separate from that 244 of the public telephone numbers and both are independently 245 expandable, while private network IP address is a specific subset 246 reserved from the overall IPv4 pool that is otherwise all public and 247 finite. However, the fact that neither of the latter two is allowed 248 to operate in the other's domain the same as in the telephony 249 practice suggests that the proposed EzIP numbering plan indeed may 250 mirror the latter. PABX extension numbers belong to a reusable 251 private set. For example, extension 123 or 1234 may exist in 252 thousands of different PABX switches without ambiguity. Similarly, 253 the IPv4 private network address (10/8, 172.16/12 and 192.168/16) may 254 also be re-used in many networks without ambiguity. 256 The key EzIP concept is the partitioning of a finite public address 257 pool to put aside a block of special (called "Semi-Public" in the 258 presentation below) addresses that extends each remaining public 259 address to multitudes of sub-addresses, resulting in an effectively 260 much larger assignable public address resource. 262 In fact, the initial EzIP analysis identified the untold two-stage 263 subnetting process of 192.168/16 that has been practiced routinely 264 for a long time. End-users are commonly accustomed to an RG choosing 265 one out of 256 values from the fourth octet of the 192.168.K/24 block 266 for identifying an IoT on a private premises. They mostly are, 267 however, unaware of the preceeding stage of selecting the value "K" 268 from the third octet of the 192.168/16 block, as the factory default 269 RG identification assigned by a manufacturer, is implicitly capable 270 of expanding it by 256 fold for supporting a corresponding number of 271 private premises. A key EzIP concept is to use the elusive IPv4 240/4 272 netblock (240/8 - 255/8), that has been "RESERVED" for "Future use" 273 since 1981-09, as the result of the historical address assignment 274 evolution. It was proposed to be redesignated to "Private Use" near a 275 decade ago [2]. However, as pointed out by its own authors in Section 276 2, Caveats of Use, "Many implementations of the TCP/IP protocol 277 stack have the 240.0.0.0/4 address block marked as experimental, and 278 prevent the host from forwarding IP packets with addresses drawn 279 from this address block." That proposal did not get advanced. 280 Therefore, to this date, the 240/4 netblock remains reserved for 281 future use. 283 Substituting the function of the third octet of 192.168.K/24 with 284 addresses from the 240/4 netblock in the first stage RG and 285 redefining it as a new category of router, called SPR, the EzIP 286 scheme circumvents the earlier hurdles to achieve the address 287 multiplication factor of 256M without involving any existing router. 288 This is because the 240/4 addresses are only used within the SPR and 289 within the Option word header extension, they are not recognized as 290 IPv4 addresses anywhere within the current Internet. These addresses 291 are equivalent to PABX extension numbers that IPv4 Option word 292 mechanism can carry them through the network. 294 Since the 240/4 netblock cannot be used by existing routers, the size 295 of the maximum assignable IPv4 public pool has actually been only 296 3.84B (4.096B - 256M). So, the overall assignable pool resulted from 297 the EzIP approach is about 983MB (3.84B x 256M), which is over 19M 298 times of the expected Year 2020 IoTs. This size certainly has the 299 potential to support the short- to mid-term public IP address needs. 301 2.2. Analogy with NAT 303 NAT works by temporarily assigning a port number to outgoing 304 communications from a private address, while converting the private 305 address into a public IPv4 address for external communications. When 306 responses to messages are received, the public IPv4 address plus port 307 number is converted back into the private IPv4 address. 309 EzIP also has similarities to NAT, but some important differences. 311 There are a number of limitations of NAT that are not present with 312 EzIP. (1) There are only 65,536 port numbers but 256M 240/4 EzIP 313 addresses; (2) Due to the limited number of ports, assignments are 314 only temporary and will be reclaimed after a period of inactivity, 315 but there are so many EzIP addresses that assignments can be made 316 permanent; (3) Port numbers are used for other purposes than NAT, 317 further reducing the pool, but EzIP uses 240/4 addresses for only one 318 purpose; (4) Due to the limited time during which a port number is 319 assigned, the NAT port numbers cannot be used for incoming 320 communications, but the EzIP address assignments will be long term 321 and can be used for direct communications between EzIP-aware devices. 322 (5) Intriguingly, while NAT in a RG provides rudimental defense 323 agaist intrusion, the dynamic nature of CGNAT opens up the Internet 324 vulnerability to cyber attacks, due to the lack of forensic 325 traceability support. 327 2.3. EzIP System Architecture 329 +------+ 330 Web Server | WS0z | 331 +--+---+ 332 |69.41.190.145 333 | 334 | +-----+ 335 +--+ ER0 | 336 +--+--+ 337 | 338 +------+-------+ 339 +-------+ Core Routers +--------+ 340 | | (CR/Internet)| | 341 +--+--+ +--------------+ +--+--+ 342 +-----+ ER1 | +-----+ ER4 | 343 | +-----+ | +-----+ 344 | | 345 |69.41.190.110 |69.41.190.148 346 240.0.0.0 +--+--+ +--+--+ 347 +-----------+ +-------+ +---------+ +------+ 348 | +-----+ SPR1| | | +-----+ SPR4+--+ | 349 | | +-----+ | |...| +-----+ |...| 350 | 240.0.0.1 ... 255.255.255.255 | | +---------+ | 351 +-----+ | | | | 352 Public | 240.0.0.0 | | 255.255.255.255 353 Demarc. ----+-------------------------------+----+------------------- 354 Private |Premises 1 +----------+ | 355 +--+--+ | Premises 4 | 356 +---+ RG1 +--+ | | 357 | +-----+ | | | 358 | | | | 359 |192.168.1.3 |192.168.1.9 |240.0.0.10 |246.1.6.40 360 +--+--+ +--+--+ +--+--+ +--+--+ 361 | T1a | .... | T1z | | T4a | ....... | T4z | 362 +-----+ +-----+ +-----+ +-----+ 364 Figure 1 EzIP System Architecture 366 The new category of router, SPR is to be positoned inline between an 367 ER and the customer premises that it serves. After the original path 368 is re-established, the remaining addresses in the 240/4 netblock will 369 be used by the SPR to serve additional premises. Figure 1 shows a 370 general view of the enhanced Internet system architecture with two 371 SPRs, SPR1 and SPR4, deployed. Note that the "69.41.190.x" are static 372 addresses. In particular, the "69.41.190.145" is the permanent public 373 Internet address assigned to Avinta.com. 375 2.3.1. Referring to the lefthand portion labeled "Premises 1" of 376 Figure 1, instead of assigning each premises a public IPv4 address as 377 in the current practice, an SPR like SPR1, is inserted between an ER 378 (ER1) and its connections to private network Routing Gateways like 379 RG1, for utilizing 240.0.0.0 through 255.255.255.255 of the 240/4 380 netblock to identify respective premises. The RG1, serving either a 381 business LAN (Local Area Network) or a residential HAN (Home Area 382 Network), uses addresses from one of the three private network 383 [RFC1918] Error! Reference source not found. blocks, 10/8, 172.16/12 384 and 192.168/16, such as 192.168.1.3 and 192.168.1.9 to identify the 385 IoTs, T1a and T1z, respectively. 387 2.3.2. Part of the righthand portion of Figure 1 is labeled 388 "Premises 4". Here SPR4 directly assigns addresses 240.0.0.10 and 389 246.1.6.40 from the 240/4 netblock to T4a and T4z, respectively. 390 Consequently, these IoTs are accessible through SPR4 from any other 391 IoT in the Internet. 393 2.3.3. Since the existing physical connections to subscriber's 394 premises terminate at the ER, it would be natural to have SPRs 395 collocated with their ER for streamlining the interconnections. It 396 follows that the simple routing function provided by the new SPR 397 modules may be absorbed into the ER through a straightforward 398 operational firmware enhancement. Consequently, the public / private 399 demarcation line (Demarc.) will remain at the RG where currently all 400 utility services enter a subscriber's premises. 402 2.3.4. To fully tag each of these devices, we may use a 403 concatenated three-part address notation: "Public - Semi-Public: TCP 404 Port". The following is how each of the IoTs in Figure 1 may be 405 uniquely identified in the Internet. 407 RG1: 69.41.190.110-240.0.0.0 409 T1a: 69.41.190.110-240.0.0.0:3 411 T1z: 69.41.190.110-240.0.0.0:9 412 T4a: 69.41.190.148-240.0.0.10 414 T4z: 69.41.190.148-246.1.6.40 416 Note that to simplify the presentation, it is assumed at this 417 juncture that the conventional TCP (Transmission Control Protocol) 418 [RFC793] [9] Port Number, normally assigned to T1a and T1z by RG1's 419 NAT module upon initiating a session, equals to the fourth octet of 420 that IoT's private IP address that is assigned by the RG1's DHCP 421 (Dynamic Host Configuration Protocol) [RFC2123] [10] subsystem as 422 ":3" and ":9", respectively. Such numbers are unique within each 423 respective /24 private network such as the 192.168.1/24 here. They 424 are adequate for the discussion purpose in this document. However, 425 considering security, as well as allowing each IoT to have multiple 426 simultaneous sessions, etc., this direct and singular correlation 427 shall be avoided in actual practice by following the NAT operation 428 conventions as depicted by the examples in Appendix A. 430 Figure 2 groups IoTs, routers and servers into two separate columns, 431 EzIP-unaware or EzIP-capable, to facilitate discussions that are to 432 follow. 434 +--------------------------+-----------------+----------------+ 435 | | EzIP-unaware | EzIP-capable | 436 +--------------------------+-----------------+----------------+ 437 | Internet Core Router (CR)| CR | ------------ | 438 +--------------------------+-----------------+----------------+ 439 | Internet Edge Router (ER)| ER0, ER1, ER4 | ------------ | 440 +--------------------------+-----------------+----------------+ 441 | Internet of Things (IoT) | T1a, T4a | T1z, T4z | 442 +--------------------------+-----------------+----------------+ 443 | Routing Gateway (RG) | RG1 | ------------ | 444 +--------------------------+-----------------+----------------+ 445 | Semi-Public Router (SPR) | ------------- | SPR1, SPR4 | 446 +--------------------------+-----------------+----------------+ 447 | Web Server (WS) | ------------- | WS0z | 448 +--------------------------+-----------------+----------------+ 450 Figure 2 EzIP System Components 452 2.4. IP Header with Option Word 454 To transport the EzIP Extension Addresses through existing devices 455 without being recognized as such and consequently acted upon, the IP 456 Header Option mechanism defined by Figure 9 in Appendix A of [RFC791] 457 is utilized to carry it as the payload. One specific aspect of its 458 format deserves some attention. The meanings of the leading eight 459 bits of each Option word, called "Opt. Code" or "Option-type octet", 460 are summarized on Page 15 of [RFC791]. They are somewhat confusing 461 because the multiple names used in the literature, and how the octet 462 is parsed into functional bit groups. For example, a two digit 463 hexadecimal number, "0x9A", is conventionaly written in the binary 464 bit string form as "1001 1010". As Opt. Code, however, the eight bits 465 here are parsed into three groups of 1, 2 and 5 bits as "1 00 11010" 466 with meanings described in Figure 3. 468 +--------------------------------------------------------------+ 469 | Meaning of EzIP ID = 0x9A (Example) | 470 +--------------+------------------+----------------------------+ 471 | Copy Bit | Class | Option Value / Number | 472 +--------------+------------------+----------------------------+ 473 | 1 (Set) | 00 (Control) | 11010 (26 - base 10) | 474 +--------------+------------------+----------------------------+ 476 Figure 3 Option Type Octet 478 A value of "1" for the first bit instructs all routers that this 479 Option word is to be copied upon packet fragmentation. This preserves 480 the Option word through such a process, if it is performed. 482 The value of "00" for the next two bits indicates that this Option 483 word is for "Control" purpose. 485 The decimal "Option Value" of the last five bits, equaling to "26" is 486 defined as the "Option Number" that is listed in the "Number" column 487 of the Internet Protocol Version 4 (IPv4) Parameters list [11]. As 488 can be seen there, "26" has not been assigned. Thus, it is 489 temporarily used in this document to facilitate the EzIP 490 presentation. The next unassigned Option Code, "0x9B" or Number "27" 491 will also be tentatively utilized in this document. 493 2.5. Examples of Option Mechanism 495 The Option mechanism has been used for various cases. Since they were 496 mostly for utility or experimental purposes, however, their formats 497 may be remote from the incident topic. There were two cases 498 specifically dealt with the address pool issues. They are referenced 499 here to assist the appreciation of the Option mechanism. 501 A. EIP (Extended Internet Protocol) - Figure 1 of [RFC1385] [12] 502 (Assigned but now deprecated Option Number = 17) by Z. Wang: This 503 approach proposed to add a new network layer on top of the existing 504 Internet for increasing the addressable space. Although equipment 505 near the end-user would stay unchanged, those among the CRs 506 apparently had to go through rather extensive upgrading procedures, 507 perhaps due to the flexible length of the extended address (could be 508 much longer than that of the IPv6). 510 B. EnIP (Enhanced IPv4) - Figure 1 of Internet Draft [13] 511 (temporarily utilizing Option Number = 26) by W. Chimiak: This work 512 made use of the three existing private network blocks to extend the 513 public pool by trading the private network operation for end-to-end 514 connectivity. The fully deployed EnIP will eliminate the current 515 private networks which may be against the preference of end-users who 516 have found the private network configuration quite desirable. For 517 example, the NAT in an RG serves as a rudimentary deterrent against 518 intrusion. In addition, the coexistence of private RG-NAT and public 519 EnIP router functions in the same EnIP devices (N1 & N2), could lead 520 to certain logistic inconsistency concerns. 522 2.6. EzIP Header 524 0 1 2 3 525 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 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 1 |Version|IHL (8)|Type of Service| Total Length (32) | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 2 | Identification |Flags| Fragment Offset | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 3 | Time to Live | Protocol | Header Checksum | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 4 | Source Host Number | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 5 | Destination Host Number | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | EzIP ID | EzIP | Extended | Extended | 538 6 | (Source) | Option Length | Source | Source | 539 | (0X9A) | (6) | No.-1 | No.-2 | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Extended | Extended | EzIP ID | EzIP | 542 7 | Source | Source | (Destination) | Option Length | 543 | No.-3 | No.-4 | (0X9B) | (6) | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Extended | Extended | Extended | Extended | 546 8 | Destination | Destination | Destination | Destination | 547 | No.-1 | No.-2 | No.-3 | No.-4 | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 Figure 4 Full EzIP Header 552 The proposed EzIP header format shown in Figure 4 can transport the 553 full 4 octet (32 bit) extension addresses of both ends of an Internet 554 link. The extension address in the 240/4 netblock utilized in the 555 EzIP scheme described herein has 28 significant bits. It is possible 556 for EzIP to use addresses having other lengths of significant bits 557 for different multiplication factors. To prepare for such variations, 558 two separate EzIP ID codes, "0x9A" and "0x9B" are proposed to 559 distinguish between Source and Destination Option words, 560 respectively, as basic examples. 562 2.7. EzIP Operation 564 To convey the general scheme, Appendix A presents examples of IP 565 header transitions through routers, between IoTs with or without EzIP 566 capability. 568 To introduce the EzIP approach into an environment where EzIP-unaware 569 IoTs like T1a and T4a will be numerous for a long time to come, an 570 SPR must be able to follow certain decision branches to determine how 571 to provide the appropriate routing service for a smooth transition to 572 the long term operation. Appendix B outlines such logic and related 573 considerations. 575 3. EzIP Deployment Strategy 577 Although the eventual goal of the SPR is to support both web server 578 access by IoTs from behind private networks and direct end-to-end 579 connectivity between IoTs, the former should be dealt with first to 580 immediately mitigate the address shortage induced daily issues. In 581 the process, the latter would be built up naturally. 583 A. Architecturally 585 Since the design philosophy of the SPR is an inline module between an 586 ER and the private premises (RG or directly connected IoTs) that it 587 serves, SPR introduction process can be flexible. 589 A.1. An SPR may be deployed as an inline module right after an ER 590 to begin providing the CGN equivalent function. This could be done 591 immediately without affecting any of the existing Internet 592 components, CR, ER and RG. EzIP-capable IoTs will then take advantage 593 of the faster bi-directional routing service through the SPRs by 594 initiating communication sessions utilizing EzIP headers to contact 595 other EzIP-capable IoTs. 597 A.2. Alternatively, an SPR may be deployed as an adjunct module 598 just before an existing RG or a directly connected IoT to realize the 599 same EzIP functions on the private premises, even if the serving 600 Internet Access Provider (IAP) has not enhanced its ERs with the EzIP 601 capability. 603 This approach will empower individual communities to enjoy the new 604 EzIP capability on their own by upgrading all Internet subscribers 605 within a good sized region to have publicly accessible EzIP addresses 606 for intra-community peer-to-peer communication, starting from just 607 using one existing public IPv4 address to identify the entire region 608 through a gateway to the rest of the world. See sub-section C. below 609 for more specific considerations. 611 B. Functionally 613 B.1. First, an IAP should install SPRs in front of business web 614 servers so that new routing branches may be added to support the 615 additional web servers for expanding business activities. 616 Alternatively, this may be achieved if businesses on their own deploy 617 new web servers with the SPR capability built-in. 619 B.2. On the subscriber side, SPRs should be deployed to 620 disseminate static addresses to the public, and to facilitate the 621 access to new web servers. 623 C. Regional Area Network 625 C.1. Since the size of the 240/4 netblock is significant, a 626 region mentioned in sub-section A.2. above could actually be fairly 627 large. Based on the assumption that each person, on the average, may 628 have 6.6 IoTs by Year 2020 Error! Reference source not found., a 629 240/4 netblock is capable of serving nearly 39M (256M / 6.6) people. 630 This exceeds the population of the largest city on earth (38M - Tokyo 631 Metro.) and 75% of the countries around the world (most of the 233 632 countries other than the top 35). Therefore, any finite sized region 633 can immediately begin to enjoy EzIP addressing by deploying a 634 Regional Area Network (RAN) utilizing SPRs operating with one 240/4 635 netblock of addresses under one IPv4 public address. With the gateway 636 for a region configured in such a way that the entire region appears 637 to be one ordinary IPv4 IoT to the rest of the Internet, a self- 638 contained RAN may be deployed anywhere there is the need or desire, 639 with no perturbation to the current Internet operations whatsoever. 641 C.2. This gateway may be constructed with a matured networking 642 technology called Caching Proxy [14], popularized by data-intensive 643 web services such as Google, Amazon, Yahoo, etc. Developed for 644 speeding up response to repetitive queries on the same topic, while 645 consolidating Internet traffic for data exchanges with the central 646 data bank, caching proxies are placed at strategic locations close to 647 potential inquirers, essentially cloning the central data bank into 648 distributed copies (not necessarily a full set, but containing all 649 relevant subsets). This architecture meshs with the EzIP-based RAN 650 very well, because the address translation between the IPv4 in the 651 Internet and the EzIP in the RAN can be accomplished transparently 652 through the two ports of a caching proxy (For such matter, even could 653 be between the IPv6 and the EzIP if desired!). Consequently, existing 654 Internet routers, such as CR and ER may not see any IP packet with 655 EzIP header at all, during the initial phase of the RAN deployment 656 which will primarily consist of basic intra-regional messaging and 657 web service access in a primarily local operation mode. 659 C.3. This configuration actually mimicks the PABX environment 660 almost exactly. Since the entire region is only accessible through 661 the gateway that performs the address translation, degenerated EzIP 662 header (conventional IP header with words 4 and 5 using addresses 663 from the 240/4 netblock) will be suffice for intra RAN traffic. This 664 mirrors the dialing procedure of using only extension numbers among 665 stations served by the same PABX, circumventing the unnecessary and 666 wasteful overhead of including the dialing of the common public 667 telephone number prefix whose only purpose is to identify the PABX to 668 the PSTN which is not involved in such intra- communications. 670 C.4. The full EzIP header format will only be used when an EzIP- 671 capable IoT intends to directly interact with an EzIP-capable IoT in 672 another RAN. The last part is equivalent to the DID (Direct Inward 673 Dialing) conventions when a call is made through the PSTN to a 674 station in another PABX. 676 C.5. The RAN would streamline the CIR (Country-based Internet 677 Registry) model proposed by ITU-T [18] as well. Instead of allocating 678 a block of public IPv6 addresses to an ITU-T authorized entity 679 (essentially the sixth RIR - Regional Internet Registry) to 680 administrate on behalf of individual countries, the EzIP RAN 681 configuration enables each member state to start her own CIR with up 682 to 256M IoTs, based on just one of the IPv4 public address already 683 allocated to that country from the responsible RIR. Consequently, 684 each CIR is coordinated by its parent RIR, yet its operation can 685 conform to local preferences. This scheme will establish a second 686 Internet service parallel to the existing one for demonstrating their 687 respective merits independently, offering subscribers true options to 688 choose from. 690 D. Permanently 692 In the long run, it would be best if SPRs are integrated into their 693 host ER by upgrading the latter's firmware to minimize the hardware 694 and to streamline the equipment interconnections. 696 Appendix B details the considerations in implementing these outlines. 698 4. Updating Servers to Support EzIP 700 Although the IP header Option mechanism utilized by EzIP was defined 701 a long time ago as part of the original IPv4 protocol RFC 791 [1], it 702 has not been used much in daily traffic. Compatibility with current 703 Internet facilities and conventions may need be reviewed. Since the 704 EzIP data is transported as part of the IP header payload, it is not 705 expected to affect higher layer protocols. However, certain 706 facilities may have been optimized without considering the Option 707 mechanism. They need be adjusted to provide the same performance to 708 EzIP packets. There are also utility type of servers that need be 709 updated to support the longer EzIP address. For example; 711 A. Fast Path 713 Internet Core Routers (CRs) are currently optimized to only provide 714 the "fast-path" (through hardware line card) routing service to 715 packets without Option word in the IP header [15]. This puts EzIP 716 packets at a disadvantage, because EzIP packets will have to go 717 through the "slow path" (processed by CPU's software before giving to 718 the correct hardware line card to forward), resulting in a slower 719 throughput. Since the immediate goal of the EzIP is to ease the 720 address pool exhaustion affecting web server access, subscribers not 721 demanding high throughput performance may be migrated to the EzIP 722 supported facility first. This gives CRs the time to update so that 723 EzIP packets with authorized Option numbers will eventually be 724 recognized for receiving the "fast-path" service. On the other hand, 725 an alternative logic may be applied for the CR. That is, it should by 726 default ignore any Option word in an IP header so that all IP packets 727 will be processed through the "fast-path", unless a recognizable 728 Option word requiring action is detected. This approach would 729 mitigate the security issues caused by the "source routing" attack, 730 as well. 732 B. Connectivity Verification 734 One frequently used probing utility for verifying baseline 735 connectivity, commonly referred to as the "ping" function in PC 736 terminology, needs be able to transport the full EzIP address that is 737 64 bits long instead of the current 32 bit IPv4 address. There is an 738 example of an upgraded TCP echo server in [RFC862] [16]. 740 C. Domain Name Server (DNS) 742 Similarly, the DNS needs to expand its data format to transport the 743 longer IP address created by the EzIP. This already can be done under 744 IPv6. Utilizing the experimental IPv6 prefix 2001:0101 defined by 745 [RFC2928] [17], EzIP addresses may be transported as standardized 746 AAAA records. 748 These topics are discussed in more detail under an IETF Draft RFC, 749 Enhanced IPv4 - V.03 [13]. 751 5. EzIP Enhancement and Application 753 To avoid disturbing any assigned addresses, deployed equipment and 754 current operation, etc., the EzIP scheme is derived under the 755 constraint of utilizing only the reserved 240/4 address block. If 756 such restriction were removed by allowing the entire IPv4 address 757 pool be freely re-allocatable, the assignable public address pool 758 could be expanded significantly more, as outlined below. 760 A. If the 240/4 netblock were doubled to 224/3, each existing IPv4 761 public address would be expanded by 512M fold. Since this block of 762 512M addresses have to be first reserved from the basic public pool, 763 the resultant total addresses will be (4.096B - 512M) x 512M, or 764 1,835MB. This is over 36M times of the predicted number of IoTs (50B) 765 by Year 2020. This calculation leads to additional possibilities. 767 B. The EzIP header in Figure 4, capable of transporting the full 32 768 bit IPv4 address, allows the extension number to be as long as 769 practical. That is, we can go to the extreme of reserving only one 770 bit for the network number, and using all the rest of bits for the 771 extension address. With this criterion, the basic IPv4 pool may be 772 divided into two halves, reserving one half of it (about 2B 773 addresses) as a semi-public network with the network number prefix 774 equal to "1". Each of the remaining 2B public addresses (with prefix 775 equal to "0") of the basic IPv4 pool may then be extended 2B fold 776 through the EzIP process, resulting in a 4BB address pool. This is 777 roughly 80M times of the Year 2020 IoT needs. 779 C. If the EzIP technique were applied through several layers of SPRs 780 in succession, the address expansion could be even more. For example, 781 let's divide the IPv4 pool equally into four blocks, each with about 782 1B addresses. Apply the first 1B address block to the public routers. 783 Set up three layers of SPRs, each makes use of one of the remaining 784 three 1B addresses. The resultant assignable pool will have 1BBBB 785 addresses. Under this configuration, the full length of an IoT's 786 identification code will be the concatenation of four segments of 32 787 bit IPv4 address, totalling 128 bits, the same as that of the IPv6. 788 The first two bits of each segment, however, being used to 789 distinguish from the other three address blocks, are not significant 790 bits. This 8-bits difference makes the IPv6 pool 256 times larger. 791 This ratio is immaterial, because even the 1BBBB address pool is 792 alreaby 20MBB times of the foreseeable need. It is the hierarchical 793 addressing characteristics, made possible by the EzIP scheme, that 794 will enhance the Internet, such as truncating out the common address 795 prefix for communicating within a local community, and associating an 796 address with the geographical position, thus mitigating the 797 GeoLocation related issues. 799 D. Along this line of reasoning, we could combine two 1B address 800 blocks togther to be the basic public address. The overall assignable 801 pool becomes 2BBB which is still 40MB times of the expected IoT 802 need(50B). With this pool, we can divide the entire globe into 2B 803 regions, each served by one public router. Each region can then be 804 divided into 1B sections, identified by the first group of SPRs. 805 Next, each section will have the second group of SPRs to manage upto 806 1B RGs and IoTs. Since the basic 2B public addresses are already more 807 than half of the current total assignable IPv4 public addresses 808 (3.84B), their potential GeoLocation resolution capabilities are 809 comparable. With additional two layers of SPR routing, 1B for each, 810 the address grid granuality will be so refined that locating the 811 source of an IP packet becomes a finite task, leaving perpetrators 812 little room to hide. 814 E. The following outlines a possible procedure for optimizing the use 815 of the EzIP address resource by transforming the current Internet to 816 be a GeoLocation-capable address system while maintaining the 817 existing IPv4 addressing and operation conventions: 819 a. Quantitative Reference: IETF [RFC6598] [6] reserved the 820 100.64/10 block with 4M addresses for supporting IAP's CGN service. 821 Applying all of these to the entire IPv4 pool of 4B addresses, the 822 maximum effective CGN supported IPv4 address pool could be 16MB. This 823 is 0.32M times of the expected number (50B) of IoTs by Year 2020. 825 b. Employing the 240/4 netblock with 256M addresses in the EzIP 826 extension scheme, a /6 block with 64M addresses from the IPv4 basic 827 public pool is sufficient to replicate the above 16MB capacity. This 828 frees up the majority of the IPv4 public pool. 830 c. Since this will be a temporary holding pool to release the 831 current addresses for new assignments, it should occupy as few public 832 addresses as possible to leave the maximum number of addresses for 833 facilitating the long term planning. To just support the expected 50B 834 IoTs need, only 200 IPv4 public addresses are required (200 x 256M = 835 50B). Thus, a /24 block with 256 addresses is more than enough to 836 accommodate this entire migration process. This frees up even more 837 IPv4 public addresses. 839 d. Although a single /24 public address block is sufficient for 840 migrating all currently perceived IPv4 address needs into one compact 841 temporary EzIP pool, world-wide coordination of new address 842 assignments and routing table updates will be required. It will be 843 more expeditious to carry out this preparatory phase on an individual 844 country or geographical region basis utilizing public IPv4 addresses 845 already assigned to that area and actively served by existing CR 846 routing tables. Since 200 public addresses are enough to port the 847 entire IoT addresses, most of the 233 countries other than the top 35 848 (about 75%) countries should be able to port all of their respective 849 predicted IoTs to be under one 240/4 netblock, each represented by 850 one gateway to the Internet. If this is managed according to 851 geographical disciplines, each participating region will begin to 852 enjoy the benefits of the EzIP approach, such as plentiful assignable 853 public addresses, robust security due to inherent GeoLocation ability 854 to spot hackers from within, so that efforts may be focused only on 855 screening suspicious packets originated from outside. 857 e. As IoTs are getting migrated to the temporary pool, the IPv4 858 addresses they originally occupy shall be released to re-populate the 859 public address pool for establishing full scale EzIP operation. 861 f. Upon the completion of the EzIP based world-wide public address 862 allocation map, each country can simply give up the few temporary 863 public addresses in exchange for the permanent assignments. Since the 864 latter is likely more than the former, addresses in one 240/4 865 netblock will be served by two (or more) 240/4 netblocks. Then, each 866 of such 240/4 netblock will have more than half of its capacity 867 available to serve the growth of additional IoTs. 869 g. This last step is very much the same as the traditional PSTN 870 "Area Code Split" practice, whereby telephone numbers of a service 871 area are split into two (or more) blocks, upon introducing one (or 872 more) new area code(s) into the area. All subscribers will continue 873 to use their original local telephone numbers for calling among 874 neighbors daily, except some may be assigned with a new area code 875 prefix. Upon the split, each area code will have more than half of 876 its assignable telephone numbers availabe to support the future 877 subscriber growth within its service area. Mimicking the PSTN, the 878 EzIP based Internet will have similar GeoLocation capability as the 879 former's caller identification based services, such as the 911 880 emergency caller location system in US, mitigating the root cause to 881 the cybersecurity vulnerability. 883 F. With the IPv4 address shortage issue resolved, potential system 884 configurations utilizing the EzIP enhanced address pool may be 885 explored. 887 a. Although the entire predicted number (50B) of IoTs by Year 2020 888 may be served by just one /24 IPv4 public address block utilizing the 889 EzIP scheme with a 240/4 netblock, let's replace it with a /8 block 890 (16M addresses), resulting in about 4MB (16M x 256M) assignable 891 addresses. This is 80K times of the expected 50B IoTs. Or, each and 892 every person (of predicted 2020 population) would have to own over 893 500K IoTs to use up this address pool. It is apparent that the spares 894 in this allocation should be sufficient to support the growth of the 895 IoTs for some years to come. 897 b. Next, the IPv4 pool originally has 256 blocks of /8 addresses. 898 After the above allocation, there are still 239 blocks of /8 899 addresses available to support additional digital communication 900 systems, each having the same size of address pool as the allocation 901 above. Consequently, many world-wide communication networks may 902 coexist under the same IPv4 protocol framework in the form of groups 903 of RANs as described earlier, with arm's-length links among them. 905 c. For example, a satellite based Internet that is being proposed 906 [19], can start fresh with one EzIP RAN served by one SPR having the 907 capacity of 256M IoTs, under one ER capable of managing one /8 block 908 of IPv4 public address. Utilizing a caching proxy as the gateway to 909 handle the data exchange with other RAN, this satellite based 910 Internet with 256M hosts can operate pretty much as an isolated 911 system by using 240/4 addresses in the basic IP headers for intra-RAN 912 communications, most of the time. Only when direct communication with 913 another RAN (such as the one for the existing Internet) is needed, 914 will the full EzIP header be required. As users grow, additional RANs 915 (each with 256M IoTs capacity), may be incrementally added to support 916 the expansion. 918 G. In summary, utilizing the 240/4 netblock, the EzIP scheme may 919 expand the IPv4 based Internet to be a collection of up to 240 groups 920 of 16M RANs each managed by one SPR with 256M IoTs capacity that are 921 inter-operable digital communication systems, normally operate at 922 arm's-lenghth to one another. Each of these groups has the address 923 capacity of at least 80K times of the number of predicted (50B) IoTs 924 by Year 2020. 926 6. Security Considerations 928 The EzIP solution is based on an inline module called SPR that is 929 intended to be as transparent to the Internet traffic as possible. 930 Thus, no overall system security degradation is expected. 932 7. IANA Considerations 934 This draft does not create a new registry nor does it register any 935 values in existing registries; no IANA action is required. 937 8. Conclusions 939 To resolve the IPv4 public address pool exhaustion issue, a technique 940 called EzIP (phonetic for Easy IPv4) making use of a long reserved 941 address block 240/4, is proposed. 943 This draft RFC describes an enhancement to IPv4 operation utilizing 944 the IP header Option mechanism defined in RFC791. Because the design 945 criterion is to enhance IPv4 by extending instead of altering it, the 946 impact on already in-place routers and security mechanisms is 947 minimized. 949 The basic EzIP philosophy includes maintaining the existing public 950 and private network structure. Upon reclassifying the "RESERVED for 951 Future use" 240/4 netblock to be the Semi-Public address pool, it 952 will only be usable by the new SPR (Semi-Public Router) as the EzIP 953 extension address. This pool can multiply each current IPv4 public 954 address by 256M times, while all existing public network and 955 subscriber premises setups (private networks as well as directly 956 connected IoTs) may remain unchanged. A subscriber is encouraged to 957 upgrade his IoT(s) to be EzIP-capable so as to enjoy the enhanced 958 router service by EzIP. This particular manifestation of the EzIP 959 scheme appears to be the optimal solution to our needs. 961 The 240/4 netblock based EzIP scheme will not only relieve the IPv4 962 address shortage, but also improve the defense against cybersecurity 963 intrusion by virtue of systematic address management. The EzIP RAN 964 (Regional Area Network) configuration will also support the desire to 965 establish CIR operation expressed by ITU-T, as a parallel facility to 966 provide services equivalent to current Internet by individual local 967 entities versus the current global model. 969 Furthermore, EzIP will help the IPv4 based Internet to become the 970 common backbone for multiple world-wide digital communication systems 971 that normally may operate in arm's-length from one another. 973 9. References 975 9.1. Normative References 977 [1] https://tools.ietf.org/html/rfc791 979 [2] https://tools.ietf.org/html/draft-wilson-class-e-02 981 9.2. Informative References 983 [3] https://www.cisco.com/c/dam/en_us/about/ac79/docs/innov/IoT_IBS 984 G_0411FINAL.pdf 986 [4] http://stats.labs.apnic.net/ipv6 988 [5] https://stats.ams-ix.net/sflow/ether_type.html 990 [6] https://tools.ietf.org/html/rfc6598 992 [7] http://www.iana.org/assignments/ipv4-address-space/ipv4- 993 address-space.xhtml 995 [8] https://tools.ietf.org/html/rfc1918 997 [9] https://tools.ietf.org/html/rfc793 999 [10] https://www.ietf.org/rfc/rfc2131.txt 1001 [11] http://www.iana.org/assignments/ip-parameters/ip- 1002 parameters.xhtml 1004 [12] https://tools.ietf.org/html/rfc1385 1006 [13] https://tools.ietf.org/html/draft-chimiak-enhanced-ipv4-03 1008 [14] https://en.wikipedia.org/wiki/Proxy_server#Improving_performanc 1009 e 1011 [15] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.477.19 1012 42&rep=rep1&type=pdf 1014 [16] https://tools.ietf.org/html/rfc862 1016 [17] https://tools.ietf.org/html/rfc2928 1018 [18] https://www.nro.net/wp-content/uploads/nro-response-to-ls-5.pdf 1020 [19] https://www.commerce.senate.gov/public/index.cfm/2017/10/the- 1021 commercial-satellite-industry-what-s-up-and-what-s-on-the- 1022 horizon 1024 10. Acknowledgments 1026 The authors would express their deep appreciation to Dr. W. Chimiak 1027 for the enlightening discussions about his team's efforts and 1028 experiences through the EnIP development. 1030 This document was prepared using 2-Word-v2.0.template.dot. 1032 Appendix A EzIP Operation 1034 To demonstrate how EzIP could support and enhance the Internet 1035 operations, the following are three sets of examples that involve 1036 SPRs as shown in Figure 1. These present a general perspective of how 1037 IP header transitions through the routers may look like. 1039 1. The first example is between EzIP-unaware IoTs, T1a and T4a. This 1040 operation is very much the same as the conventional TCP/IP packet 1041 transmission except with SPRs acting as an extra pair of routers 1042 providing the CGN service. 1044 2. The second one is between EzIP-capable IoTs, T1z and T4z. Here, 1045 the SPRs process the extended semi-public IP addresses in router 1046 mode, avoiding the drawbacks due to the NAT type of operations above. 1048 3. The last one is between EzIP-unaware and EzIP-capable IoTs. By 1049 initiating and responding with a conventional IP header, EzIP-capable 1050 IoTs behave like EzIP-unaware IoTs. Thus, all packet exchanges use 1051 the conventional IP headers, just like case 1. above. 1053 A.1. Connection between EzIP-unaware IoTs 1055 A.1.1. T1a Initiates a Session Request towards T4a 1057 T1a sends a session request to SPR4 that serves T4a by a plain IP 1058 packet with header as in Figure 5, to RG1. There is no TCP port 1059 number in this IP header yet. 1061 0 1 2 3 1062 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 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 1 |Version|IHL (5)|Type of Service| Total Length (20) | 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 2 | Identification |Flags| Fragment Offset | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 3 | Time to Live | Protocol | Header Checksum | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 4 | Source Host Number (192.168.1.3) | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 5 | Destination Host Number (69.41.190.148) | 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 Figure 5 IP Header: From T1a to RG1 1077 A.1.2. RG1 Forwards the Packet to SPR1 1079 RG1, allowing be masqueraded by T1a, relays the packet toward SPR1 1080 by assigning the TCP Source port number, 3N, to T1a, with a header as 1081 in Figure 6,. Note that the suffix "N" denotes the actual TCP port 1082 number assigned by the RG1's NAT. This could assume multiple values, 1083 each represents a separate communications session that T1a is engaged 1084 in. A corresponding entry is created in the RG1 state table for 1085 handling the reply packet from the Destination site. Since T4a's TCP 1086 port number is not known yet, it is filled with all 1's. 1088 0 1 2 3 1089 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 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 1 |Version|IHL (5)|Type of Service| Total Length (24) | 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 2 | Identification |Flags| Fragment Offset | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 3 | Time to Live | Protocol | Header Checksum | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 4 | Source Host Number (240.0.0.0) | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 5 | Destination Host Number (69.41.190.148) | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 6 | Source Port (3N) | Destination Port (All 1's) | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 Figure 6 TCP/IP Header: From RG1 to SPR1 1106 A.1.3. SPR1 Sends the Packet to SPR4 through the Internet 1108 SPR1, detecting no EzIP Option word, acts like a CGN. It allows being 1109 masqueraded by RG1 (with the Source Host Number changed to be SPR1's 1110 own and the TCP port number changed to 0C, where "0" is the last 1111 octet of RG1's IP address, and "C" stands for CGN) and sends the 1112 packet as in Figure 7 out through the Internet towards SPR4. The 1113 packet traverses through the Internet (ER1, CR and ER4) utilizing 1114 only the Destination Host Number (word 5) in the header. 1116 0 1 2 3 1117 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 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 1 |Version|IHL (5)|Type of Service| Total Length (24) | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 2 | Identification |Flags| Fragment Offset | 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 3 | Time to Live | Protocol | Header Checksum | 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 4 | Source Host Number (69.41.190.110) | 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 5 | Destination Host Number (69.41.190.148) | 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 6 | Source Port (0C) | Destination Port (All 1's) | 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 Figure 7 TCP/IP Header: From SPR1 to SPR4 1134 Note that although schematically shown in Figure 1 as one public IPv4 1135 address serving one SPR capable of a full 240/4 address block, the 1136 PCP port number has a theoretical limit of 64K (256 x 256) because it 1137 consists of 16 bits. This is much smaller than a full 240/4 pool. 1138 Even with dynamic assignments, it will take quite a few public 1139 address to serve the NAT need if many IoTs are EzIP-unaware. So, IoTs 1140 are encouraged to become EzIP-capable as soon as possible to avoid 1141 straining the SPR's NAT capability. This should not be an issue for 1142 emerging regions currently having very little facility and IoTs. As 1143 new ones are deployed, they should be enabled as EzIP-capable by 1144 factory default. For the rural area of developed countries with 1145 existing EzIP-unaware IoTs, the need for CG-NAT service will be 1146 greater. Multiple IPv4 public addresses would be needed initially to 1147 support smaller sub- 240/4 netblocks. This is probably workable 1148 because the latter does have more public IPv4 addresses. The CG-NAT 1149 techniques developed under RFC6264 Error! Reference source not found. 1150 may be incorporated here to facilitate the transition. 1152 A.1.4. SPR4 Sends the Packet to T4a 1154 Since the packet has a conventional TCP/IP header without Destination 1155 TCP port number, SPR4 would ordinarily drop it due to the CGN 1156 function. However, for this example, let's assume that there exists a 1157 state-table that was set up by a DMZ (De-Militaried Zone) process for 1158 redirecting this packet to T4a with a CGN TCP port number 10C (Here, 1159 "10" is the fourth octet of T4a's Extension address, and "C" stands 1160 for CGN.). After constructing the Destination Host Number 1161 accordingly, SPR4 sends the packet to T4a with a header as in Figure 1162 8. 1164 0 1 2 3 1165 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 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 1 |Version|IHL (5)|Type of Service| Total Length (24) | 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 2 | Identification |Flags| Fragment Offset | 1170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 3 | Time to Live | Protocol | Header Checksum | 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 4 | Source Host Number (69.41.190.110) | 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 5 | Destination Host Number (240.0.0.10) | 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 6 | Source Port (0C) | Destination Port (10C) | 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 Figure 8 TCP/IP Header: From SPR4 to T4a 1182 A.1.5. T4a Replies to SPR4 1184 T4a interchanges the Source and Destination identifications in the 1185 incoming TCP/IP packet to create a header as in Figure 9, for the 1186 reply packet to SPR4. 1188 0 1 2 3 1189 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 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 1 |Version|IHL (5)|Type of Service| Total Length (24) | 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1193 2 | Identification |Flags| Fragment Offset | 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 3 | Time to Live | Protocol | Header Checksum | 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 4 | Source Host Number (240.0.0.10) | 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 5 | Destination Host Number (69.41.190.110) | 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 6 | Source Port (10C) | Destination Port (0C) | 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 Figure 9 TCP/IP Header: From T4a to SPR4 1206 A.1.6. SPR4 Sends the Packet to SPR1 through the Internet 1208 SPR4, allowing being masqueraded by T4a, sends the packet toward SPR1 1209 with the header in Figure 10, through the Internet (ER4, CR and ER1) 1210 who will simply relay the packet according to the information in word 1211 5 (Destination Host Number): 1213 0 1 2 3 1214 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 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 1 |Version|IHL (5)|Type of Service| Total Length (24) | 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1218 2 | Identification |Flags| Fragment Offset | 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 3 | Time to Live | Protocol | Header Checksum | 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 4 | Source Host Number (69.41.190.148) | 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 5 | Destination Host Number (69.41.190.110) | 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 6 | Source Port (10C) | Destination Port (0C) | 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 Figure 10 TCP/IP Header: From SPR4 to SPR1 1231 A.1.7. SPR1 Sends the Packet to RG1 1233 Using the stored data in the CGN state-table, SPR1 reconstructes a 1234 header as in Figure 11, for sending the packet to RG1. 1236 0 1 2 3 1237 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 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1239 1 |Version|IHL (5)|Type of Service| Total Length (24) | 1240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1241 2 | Identification |Flags| Fragment Offset | 1242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1243 3 | Time to Live | Protocol | Header Checksum | 1244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1245 4 | Source Host Number (69.41.190.148) | 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 5 | Destination Host Number (240.0.0.0) | 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 6 | Source Port (10C) | Destination Port (3N) | 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 Figure 11 TCP/IP Header: From SPR1 to RG1 1254 A.1.8. RG1 Forwards the Packet to T1a 1256 From the state-table in RG1's NAT, T1a address is reconstructed based 1257 on Destination Port (3N), as in Figure 12. 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 (5)|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 (192.168.1.3) | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 6 | Source Port (10C) | Destination Port (3N) | 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 Figure 12 TCP/IP Header: From RG1 to T1a 1277 A.1.9. T1a Sends a Follow-up Packet to RG1 1279 To carry on the communication, T1a constructs a full TCP/IP header as 1280 in Figure 13 for sending the follow-up 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 (5)|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 (192.168.1.3) | 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 5 | Destination Host Number (69.41.190.148) | 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 6 | Source Port (3N) | Destination Port (10C) | 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1298 Figure 13 TCP/IP Header: Follow-up Packets From T1a to RG1 1300 A.2. Connection Between EzIP-capable IoTs 1302 The following is an example of EzIP operation between T1z and T4z 1303 shown in Figure 1, with full "Public - EzIP : Private" network 1304 addresses, "69.41.190.110-240.0.0.0:9" and "69.41.190.148- 1305 246.1.6.40", respectively. Note that T4z, without the private portion 1306 (TCP port number) in the concatenated address, is directly 1307 addressable from the Internet. For T1z to initiate a session, it 1308 needs to know the full address of T4z, but only it's own private 1309 address. 1311 A.2.1. T1z Initiates a Session Request towards T4z 1313 T1z sends an EzIP packet, as in Figure 14, to RG1. There is no TCP 1314 port number word, because T4z does not have such while that for T1z 1315 is waiting for assignment from the RG1's NAT. Also, the Extended 1316 Source No. is filled with all "1's", waiting for being specified by 1317 SPR1. 1319 0 1 2 3 1320 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 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 1 |Version|IHL (8)|Type of Service| Total Length (32) | 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 2 | Identification |Flags| Fragment Offset | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 3 | Time to Live | Protocol | Header Checksum | 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 4 | Source Host Number (192.168.1.9) | 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 5 | Destination Host Number (69.41.190.148) | 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 | EzIP ID | EzIP | Extended | Extended | 1333 6 | (Source) | Option Length | Source | Source | 1334 | (0X9A) | (6) | No.-1 (255) | No.-2 (255) | 1335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 | Extended | Extended | EzIP ID | EzIP | 1337 7 | Source | Source | (Destination) | Option Length | 1338 | No.-3 (255) | No.-4 (255) | (0X9B) | (6) | 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 | Extended | Extended | Extended | Extended | 1341 8 | Destination | Destination | Destination | Destination | 1342 | No.-1 (246) | No.-2 (1) | No.-3 (6) | No.-4 (40) | 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 Figure 14 EzIP Header: From T1z to RG1 1347 A.2.2. RG1 Forwards the Packet to SPR1 1349 RG1, allowing to be masqueraded by T1z, relays a packet as in 1350 Figure 15, toward SPR1 by assigning the TCP Source port number, 9N, 1351 to T1z. Not knowing whether T4z is behind an RG, "All 1's" is used to 1352 fill the Destination Port part of the TCP word. 1354 0 1 2 3 1355 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 1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1357 1 |Version|IHL (8)|Type of Service| Total Length (36) | 1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 2 | Identification |Flags| Fragment Offset | 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 3 | Time to Live | Protocol | Header Checksum | 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 4 | Source Host Number (240.0.0.0) | 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 5 | Destination Host Number (69.41.190.148) | 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 | EzIP ID | EzIP | Extended | Extended | 1368 6 | (Source) | Option Length | Source | Source | 1369 | (0X9A) | (6) | No.-1 (255) | No.-2 (255) | 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 | Extended | Extended | EzIP ID | EzIP | 1372 7 | Source | Source | (Destination) | Option Length | 1373 | No.-3 (255) | No.-4 (255) | (0X9B) | (6) | 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 | Extended | Extended | Extended | Extended | 1376 8 | Destination | Destination | Destination | Destination | 1377 | No.-1 (246) | No.-2 (1) | No.-3 (6) | No.-4 (40) | 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 9 | Source Port (9N) | Destination Port (All 1's) | 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1382 Figure 15 TCP/EzIP Header: From RG1 to SPR1 1384 A.2.3. SPR1 Sends the Packet to SPR4 through the Internet 1386 SPR1 replaces the Source Host Number with its own as well as fills in 1387 the Extended Source No. information, and then sends the packet, with 1388 a header as in Figure 166, out into the Internet towards SPR4. The 1389 packet traverses through ER1, CR and ER4, utilizing only the 1390 Destination Host Number (Word 5) in the IP Header. 1392 0 1 2 3 1393 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 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1395 1 |Version|IHL (8)|Type of Service| Total Length (36) | 1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1397 2 | Identification |Flags| Fragment Offset | 1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1399 3 | Time to Live | Protocol | Header Checksum | 1400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1401 4 | Source Host Number (69.41.190.110) | 1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1403 5 | Destination Host Number (69.41.190.148) | 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 | EzIP ID | EzIP | Extended | Extended | 1406 6 | (Source) | Option Length | Source | Source | 1407 | (0X9A) | (6) | No.-1 (240) | No.-2 (0) | 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 | Extended | Extended | EzIP ID | EzIP | 1410 7 | Source | Source | (Destination) | Option Length | 1411 | No.-3 (0) | No.-4 (0) | (0X9B) | (6) | 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1413 | Extended | Extended | Extended | Extended | 1414 8 | Destination | Destination | Destination | Destination | 1415 | No.-1 (246) | No.-2 (1) | No.-3 (6) | No.-4 (40) | 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 9 | Source Port (9N) | Destination Port (All 1's) | 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 Figure 16 TCP/EzIP Header: From SPR1 to SPR4 1422 A.2.4. SPR4 Sends the Packet to T4z 1424 SPR4 reconstructs T4z address from the Option number 0X9B and the 1425 Extended Destination No. then sends the packet, with the header as in 1426 Figure 17, to T4z. 1428 0 1 2 3 1429 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 1 |Version|IHL (8)|Type of Service| Total Length (36) | 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1433 2 | Identification |Flags| Fragment Offset | 1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 3 | Time to Live | Protocol | Header Checksum | 1436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1437 4 | Source Host Number (69.41.190.110) | 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1439 5 | Destination Host Number (246.1.6.40) | 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1441 | EzIP ID | EzIP | Extended | Extended | 1442 6 | (Source) | Option Length | Source | Source | 1443 | (0X9A) | (6) | No.-1 (240) | No.-2 (0) | 1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1445 | Extended | Extended | EzIP ID | EzIP | 1446 7 | Source | Source | (Destination) | Option Length | 1447 | No.-3 (0) | No.-4 (0) | (0X9B) | (6) | 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 | Extended | Extended | Extended | Extended | 1450 8 | Destination | Destination | Destination | Destination | 1451 | No.-1 (246) | No.-2 (1) | No.-3 (6) | No.-4 (40) | 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 9 | Source Port (9N) | Destination Port (All 1's) | 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 Figure 17 TCP/EzIP Header: From SPR4 to T4z 1458 A.2.5. T4z Replies to SPR4 1460 Making use of the information in the incoming TCP/EzIP header, T4z 1461 replies to SPR4 with a full header, as in Figure 18. 1463 0 1 2 3 1464 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 1465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1466 1 |Version|IHL (8)|Type of Service| Total Length (36) | 1467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1468 2 | Identification |Flags| Fragment Offset | 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 3 | Time to Live | Protocol | Header Checksum | 1471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1472 4 | Source Host Number (246.1.6.40) | 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 5 | Destination Host Number (69.41.190.110) | 1475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1476 | EzIP ID | EzIP | Extended | Extended | 1477 6 | (Source) | Option Length | Source | Source | 1478 | (0X9A) | (6) | No.-1 (246) | No.-2 (1) | 1479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1480 | Extended | Extended | EzIP ID | EzIP | 1481 7 | Source | Source | (Destination) | Option Length | 1482 | No.-3 (6) | No.-4 (40) | (0X9B) | (6) | 1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1484 | Extended | Extended | Extended | Extended | 1485 8 | Destination | Destination | Destination | Destination | 1486 | No.-1 (240) | No.-2 (0) | No.-3 (0) | No.-4 (0) | 1487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1488 9 | Source Port (All 1's) | Destination Port (9N) | 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 Figure 18 TCP/EzIP Header: From T4z to SPR4 1493 A.2.6. SPR4 Sends the Packet to SPR1 through the Internet 1495 SPR4 replaces the Source Host Number with its own, and sends the 1496 packet with the header, as in Figure 19, towards SPR1. The Internet 1497 (ER4, CR, and ER1) simply relays the packet according to the TCP/EzIP 1498 header word 5 (Destination Host Number): 1500 0 1 2 3 1501 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 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 1 |Version|IHL (8)|Type of Service| Total Length (36) | 1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1505 2 | Identification |Flags| Fragment Offset | 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1507 3 | Time to Live | Protocol | Header Checksum | 1508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1509 4 | Source Host Number (69.41.190.148) | 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 5 | Destination Host Number (69.41.190.110) | 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 | EzIP ID | EzIP | Extended | Extended | 1514 6 | (Source) | Option Length | Source | Source | 1515 | (0X9A) | (6) | No.-1 (246) | No.-2 (1) | 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 | Extended | Extended | EzIP ID | EzIP | 1518 7 | Source | Source | (Destination) | Option Length | 1519 | No.-3 (6) | No.-4 (40) | (0X9B) | (6) | 1520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1521 | Extended | Extended | Extended | Extended | 1522 8 | Destination | Destination | Destination | Destination | 1523 | No.-1 (240) | No.-2 (0) | No.-3 (0) | No.-4 (0) | 1524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 9 | Source Port (All 1's) | Destination Port (9N) | 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1528 Figure 19 TCP/EzIP Header: From SPR4 to SPR1 1530 A.2.7. SPR1 Sends the Packet to RG1 1532 SPR1 reconstructs RG1 address from the Option number 0X9B and the 1533 Extended Destination No. Then, sends packet with a header as in 1534 Figure 20 toward RG1. 1536 0 1 2 3 1537 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 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 1 |Version|IHL (8)|Type of Service| Total Length (36) | 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 2 | Identification |Flags| Fragment Offset | 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 3 | Time to Live | Protocol | Header Checksum | 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1545 4 | Source Host Number (69.41.190.148) | 1546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1547 5 | Destination Host Number (240.0.0.0) | 1548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1549 | EzIP ID | EzIP | Extended | Extended | 1550 6 | (Source) | Option Length | Source | Source | 1551 | (0X9A) | (6) | No.-1 (246) | No.-2 (1) | 1552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 | Extended | Extended | EzIP ID | EzIP | 1554 7 | Source | Source | (Destination) | Option Length | 1555 | No.-3 (6) | No.-4 (40) | (0X9B) | (6) | 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 | Extended | Extended | Extended | Extended | 1558 8 | Destination | Destination | Destination | Destination | 1559 | No.-1 (240) | No.-2 (0) | No.-3 (0) | No.-4 (0) | 1560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1561 9 | Source Port (All 1's) | Destination Port (9N) | 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 Figure 20 TCP/EzIP Header: From SPR1 to RG1 1566 A.2.8. RG1 Forwards the Packet to T1z 1568 RG1 reconstructs T1z address from RG1's NAT state-table based on 1569 Destination Port (9N), then sends the packet to T1z with a header as 1570 in Figure 21. 1572 0 1 2 3 1573 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 1574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 1 |Version|IHL (8)|Type of Service| Total Length (36) | 1576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1577 2 | Identification |Flags| Fragment Offset | 1578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1579 3 | Time to Live | Protocol | Header Checksum | 1580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1581 4 | Source Host Number (69.41.190.148) | 1582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1583 5 | Destination Host Number (192.168.1.9) | 1584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1585 | EzIP ID | EzIP | Extended | Extended | 1586 6 | (Source) | Option Length | Source | Source | 1587 | (0X9A) | (6) | No.-1 (246) | No.-2 (1) | 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 | Extended | Extended | EzIP ID | EzIP | 1590 7 | Source | Source | (Destination) | Option Length | 1591 | No.-3 (6) | No.-4 (40) | (0X9B) | (6) | 1592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 | Extended | Extended | Extended | Extended | 1594 8 | Destination | Destination | Destination | Destination | 1595 | No.-1 (240) | No.-2 (0) | No.-3 (0) | No.-4 (0) | 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1597 9 | Source Port (All 1's) | Destination Port (9N) | 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 Figure 21 TCP/EzIP Header: From RG1 to T1z 1602 A.2.9. T1z Sends a Follow-up Packet to RG1 1604 With all fields filled with needed information from the incoming 1605 TCP/EzIP header, T1z sends a follow-up packet to RG1 as in Figure 22. 1607 0 1 2 3 1608 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 1609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1610 1 |Version|IHL (8)|Type of Service| Total Length (36) | 1611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1612 2 | Identification |Flags| Fragment Offset | 1613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1614 3 | Time to Live | Protocol | Header Checksum | 1615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 4 | Source Host Number (192.168.1.9) | 1617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 5 | Destination Host Number (69.41.190.148) | 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 | EzIP ID | EzIP | Extended | Extended | 1621 6 | (Source) | Option Length | Source | Source | 1622 | (0X9A) | (6) | No.-1 (240) | No.-2 (0) | 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1624 | Extended | Extended | EzIP ID | EzIP | 1625 7 | Source | Source | (Destination) | Option Length | 1626 | No.-3 (0) | No.-4 (0) | (0X9B) | (6) | 1627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1628 | Extended | Extended | Extended | Extended | 1629 8 | Destination | Destination | Destination | Destination | 1630 | No.-1 (246) | No.-2 (1) | No.-3 (6) | No.-4 (40) | 1631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1632 9 | Source Port (9N) | Destination Port (All 1's) | 1633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 Figure 22 TCP/EzIP Header: Follow-up Packets from T1z to RG1 1637 A.3. Connection Between EzIP-unaware and EzIP-capable IoTs 1639 A.3.1. T1a Initiates a Request to T4z 1641 Since T1a can create only conventional format IP header, the SPRs 1642 will provide CGN type of services to the TCP/IP packets. And, 1643 assuming SPR4 has a state-table set up by DMZ for forwarding the 1644 request to T4z, the packet will be delivered to T4z. Seeing the 1645 incoming packet with conventional TCP/IP header, T4z should respond 1646 with the same so that the session will be conducted with conventional 1647 TCP/IP headers. The interaction will follow the same behavior as in 1648 Appedix A.1. 1650 A.3.2. T1z Initiates a Request to T4a 1652 Knowing T4a is not capable of EzIP header, T1z purposely initiates 1653 the request packet using conventional IP header. It will be treated 1654 by SPRs in the same manner as the T1a initiated case as in Appedix 1655 A.1. so that the packet will be recognizable by T4a. 1657 Note that to maximize the combination in the EzIP System Architecture 1658 diagram (Figure 1) for demonstrating the possible variations, there is 1659 no RG on Premises 4. IoTs, such as T4a and T4z, are thus directly 1660 connected to a SPR, like SPR4 and there is no corresponding TCP port 1661 number in word 9 of the above TCP/EzIP headers. This spare facility in 1662 the header suggests that an RG may be installed if desired, to establish 1663 the similar private network environment as that on Premises 1. 1665 In brief, the steps outlined above are very much the same as the 1666 conventional TCP/IP header transitions through the Internet with the SPR 1667 providing the CGN service. Except, when a TCP/EzIP header is detected, 1668 the SPR switches to the router mode for forwarding the packet to improve 1669 the performance. 1671 In essence, with the EzIP system architecture very much the same as 1672 today's Internet, the SPR starts with assuming the current CGN duty, 1673 while ready to perform the new EzIP routing function for EzIP-aware 1674 IoTs. This strategy offers a simple transition path for the Internet to 1675 evolve toward the future. 1677 It is important to note that both SPR and CGN are inline devices with 1678 respect to ER. However, since CGN provides soft / ephemeral TCP ports, 1679 it is positioned between a CR and ERs, while SPR is located between an 1680 ER and RGs to assign hard / static physical addresses. 1682 Appendix B Internet Transition Considerations 1684 To enhance a large communication system like the Internet, it is 1685 important to minimize the disturbance to the existing equipments and 1686 processes due to any required modification. The basic EzIP plan is to 1687 confine all actionable enhancements within the new SPR module. The 1688 following outlines the considerations for supporting the transition 1689 from the current Internet to the one enhanced by the EzIP technique. 1691 B.1. EzIP Implementation 1693 B.1.1. Introductory Phase: 1695 A. Insert an SPR in front of a web-server that desires to have 1696 additional subnet addresses for offering diversified activities. For 1697 the long term, a new web server may be designed with these two 1698 functional modules combined. 1700 . The first address of a private network address pool, e.g., 1701 242.0.0.0, used by the SPR should be reserved as a DMZ channel 1702 directing the initial incoming service requesting packets to the 1703 existing web server. This will maintain the same current operation 1704 behavior projected to the general public. 1706 . The additional addresses, up to 255.255.255.255 may be used for 1707 EzIP address extension purposes. Each may be assigned to an 1708 additional web server representing one of the business's new 1709 activities. Each of these new servers will then respond with EzIP 1710 header to messages forwarded from the main server, or be directly 1711 accessible through its own EzIP address. 1713 B. Insert an SPR in front of a group of subscribers who are to be 1714 served with the EzIP capability. The basic service provided by this 1715 SPR will be the CGN equivalent function. This will maintain the same 1716 current baseline user experience in accessing the Internet. 1718 C. Session initiating packets with basic IPv4 header will be routed 1719 by SPRs to a business's existing server at the currently published 1720 IPv4 public address (discoverable through existing DNS). The server 1721 should respond with the basic IPv4 format as well. Essentially, this 1722 maintains the existing user experience between a customer and a web 1723 server within an EzIP-unaware environment. 1725 So far, neither the web-server nor any subscriber's IoTs needs to 1726 be enhanced, because the operations remain pretty much the same as 1727 today's common practice utilizing CGN assisted connectivity. See 1728 Appendix A.1. for an example. 1730 D. Upon connection to the main web server, if a customer 1731 intentionally selects one of the new services, the main web server 1732 should ask the customer to confirm the selection. 1734 . If confirmed, implying that the customer is aware of the fact 1735 that his IoT is being served by an SPR, the web server forwards the 1736 request to a branch server for carrying on the session via an EzIP 1737 address. 1739 . The SPR on the customer side, recognizing the EzIP header from 1740 the branch web-server, replaces the CGN service with the EzIP 1741 routing. 1743 . For all subsequent packets exchanged, the EzIP headers will be 1744 used in both directions. This will speed up the transmission 1745 throughput performance for the rest of the session. See Appendix A.2. 1746 for an example. 1748 B.1.2. New IoT Operation Modes: 1750 A. EzIP-capable IoT will create EzIP header in initiating a session, 1751 to directly reach a specific EzIP-capable web-server, instead of the 1752 manual interaction steps of going through the DMZ port then making 1753 the selection from the main web server. This will speed up the 1754 initial handshake process. See Appendix A.2. for an example. 1756 B. To communicate with an EzIP-unaware IoT, an EzIP-capable IoT 1757 should purposely initiate a session with conventional IP header. This 1758 will signal the SPRs to provide just the CGN type of connection 1759 service. See Appendix A.1. for an example. 1761 B.1.3. End-to-End Operation: 1763 Once EzIP-capable IoTs become wide spread among the general public, 1764 direct communication between any pair of such IoTs will be 1765 achievable. An EzIP-capable IoT, knowing the other IoT's full EzIP 1766 address, may initiate a session by creating an EzIP header that 1767 directs SPRs to provide EzIP service, bypassing the CGN process. See 1768 Appendix A.2. for an example. 1770 B.2. SPR Operation Logic 1772 To support the above scenarios, the SPR should be designed with the 1773 following decision process: 1775 B.2.1. Sending an IP packet out for an IoT or a RG 1776 If the IP header contains EzIP Option word, SPR will route it forward 1777 by using the EzIP mechanism (replacing Source Host Number by SPR's 1778 own and filling in Extended Source No. if not already there). 1779 Otherwise, the SPR provides the CGN service (assigning TCP Source 1780 Port number and allowing the packet to masquerade with the SPR's own 1781 IP address, plus creating an entry to the state (port-forward / look- 1782 up / hash) table in anticipation of the reply packet). 1784 B.2.2. Receiving an IP packet from the ER 1786 If a received IP packet includes a valid EzIP Option word, SPR will 1787 provide the EzIP routing service (utilizing the Extended Destination 1788 No. as the Destination Host Number). If only Destination Port number 1789 is present, CGN service will be provided. For a packet with plain IP 1790 header (with neither EzIP nor CGN information), it will be dropped. 1792 B.3. RG Enhancement 1794 With IPv4 address pool expanded by the EzIP schemes, there will be 1795 sufficient publicly assignable addresses for IoTs wishing to be 1796 directly accessible from the Internet. On the other hand, the 1797 existing private networks may continue their current behavior of 1798 blocking session-request packets from the Internet. In-between, 1799 another connection mode is possible. The following describes such an 1800 option in the context of the existing RG operation conventions. 1802 B.3.1. Initiating Session request for an IoT 1804 Without regard to whether the IP header is a conventional type or an 1805 EzIP one, a RG allows a packet to masquerade with the RG's own IP 1806 address by assigning a TCP port number to the packet and creating an 1807 entry to the state (port-forward / look-up / hash) table. This is the 1808 same as the current NAT practice. 1810 B.3.2. Receiving a packet from the SPR 1812 The "Destination Port" value in the packet is examined: 1814 A. If it matches with an entry in the RG NAT's state-table, the 1815 packet is forwarded to the corresponding address. This is the same as 1816 the normal NAT processes in a conventional RG. 1818 B. If it matches with the IP address of an active IoT on the 1819 private network, the packet is assigned with a TCP port number and 1820 then forwarded to that IoT. 1822 Note that there is certain amount of increased security risk with 1823 this added last step, because a match between a guessed destination 1824 identity and either of the above two lists could happen by chance. To 1825 address this issue, the following proactive mechanism should be 1826 incorporated in parallel: 1828 C. If the "Destination Port" number is null or matches with 1829 neither of the above two lists, the packet is dropped and an alarm 1830 state is activated to monitor for possible ill-intended follow-up 1831 attempts. A defensive mechanism should be triggered when the number 1832 of failed attempts has exceeded the preset threshold within a 1833 predetermined finite time interval. 1835 In brief, if the IP header of a session requesting packet indicates 1836 that the sender knows the identity of the desired destination IoT on 1837 a private network, the common RG screening process will be bypassed. 1838 This facilitates the direct end-to-end connection, even in the 1839 presence of the NAT. Note that this process is very much the same as 1840 the AA (Automated Attendant) capability in a PABX telephone switching 1841 system that automatically makes the connection for a caller who 1842 indicates (via proper secondary dialing or an equivalent means) 1843 knowing the extension number of the destination party. Such process 1844 effectively screens out most of the unwanted callers while serving 1845 the acquaintance expeditiously. 1847 Appendix C EzIP Realizability 1849 The EzIP scheme proposes a new type of network router, called SPR, 1850 capable of utilizing 240/4 address transported via the Option word 1851 mechanism in the EzIP Header. In particular, EzIP may optimally be 1852 first deployed in the form of a Regional Area Network (RAN) wherever 1853 desired. Each RAN starts from one IPv4 public address to serve up to 1854 256M IoTs. For such a configuration, an SPR will operate with the 1855 degenerated EzIP Header which is identical to the basic IPv4 Header, 1856 except the addresses are from the 240/4 netblock. Since this can be 1857 accomplished by simply expanding the scope of the accessible address 1858 pool within the IPv4 protocol, there is hardly any need to modify the 1859 design of existing routers. 1861 Having been "Reserved for Future Use" for so long (since 1981-09), 1862 however, it is a challenge to identify current equipments that may be 1863 conducive to the use of the 240/4 netblock. Un-documented behaviors, 1864 observed through extensive research and testing of products in-use 1865 and on-the-market as well as public domain firmware, confirm that 1866 certain pairs of router and IoT / PC OS are already partially 1867 supporting this mode of operation. This unexpected discovery sets the 1868 baseline for the following interim report. 1870 C.1. 240/4 Netblock Capable IoTs 1872 A. Open source Xubuntu OS (V.18.04.1) enables a PC to assume both 1873 dynamic and static IP addresses, simultaneously. The former operates 1874 in the default DHCP client mode, while the latter accepts manually 1875 set static addresses including those from the 240/4 netblock. Making 1876 use of this "dual personality", connectivity between two similarly 1877 equipped PCs can be established first through a compatible router 1878 (described in the next subsection) by "ping"ing each other with the 1879 dynamic address. Using the static 240/4 addresses, the additional 1880 networking channel through the same router can then be confirmed. 1882 B. Several other PC OSs, such as Chrome (V.74.0.3729.125), LinuxMint 1883 V.19 tara (Ubuntu V.4.15.0), Mojave (OSX 10.14.1) and Ubuntu 19.04 1884 (Ubuntu 5.0.0), have been found to behave similarly, although 1885 partially and not as conveniently. 1887 C.2. 240/4 Netblock Capable Routers 1889 A. Open source router firmware OpenWrt (V.18.06.1) currently does not 1890 utilize the 240/4 netblock in its DHCP operation, while it would not 1891 reject the process of specifying such. Yet, it transports 240/4 1892 addressed "ping" packets between two 240/4 capable PCs, anyway. 1894 B. Also, a common RG, TP-Link Archer C20 AC750 (F/W V4_170222 / 1895 0.9.13.16 v0348.0) rejects setting its DHCP pool to use the 240/4 1896 netblock, but transports 240/4 addressed "ping" packets, nonetheless. 1898 C. Similarly, Verizon FiOS-G1100 RG (H/W: 1.03, F/W: 02.02.00.14 UI 1899 Ver: v1.0.388) will not allow its DHCP server to utilize the 240/4 1900 netblock, but transports the 240/4 addressed "ping" packets, just 1901 fine. 1903 D. Other routers, such as LinkSys E3000 (DD-WRT v24-sp2 (05/27/13) 1904 mini (SVN Rev. 21676), have been found to exhibit similar behavior. 1906 E. Furthermore, test data suggest that 240/4 addressed "ping" and 1907 "traceroute" packets from some of the above setups could have 1908 propagated through an ISP's ER (108.30.229.xxx, Verizon's Edge 1909 Router) into the Internet. The addresses (130.81.171.xxx) that they 1910 arrrived at appear to be Verizon's internal routers. If these are not 1911 CRs (Core Routers), at least they are ARs (Aggregate Routers). 1913 C.3. Enhancing an RG 1915 The above observations suggest that Xubuntu OS based PCs are likely 1916 ready to network as 240/4 addressed DHCP clients. To complement this 1917 capability, we need a router that can function as a 240/4 DHCP 1918 server. Although the OpenWrt firmware appears to be closer to this 1919 desired functionality than the TP-Link Router, the source code of the 1920 latter being hardware specific would better facilitate the firmware 1921 enhancement efforts. Accordingly, the following outlines the steps 1922 being planned to bring TP-Link Router and Xubuntu OS based PCs up to 1923 a state for performing the essential SPR functions: 1925 C.3.1. Enhance the TP-Link Router firmware to include the 240/4 1926 netblock in its DHCP pool. 1928 C.3.2. Verify that Xubuntu OS based PCs will accept 240/4 based 1929 DHCP assignment from the enhanced Router above. With this, deactivate 1930 the static address settings in the PCs. 1932 C.3.3. Send 240/4 destined traffic between two Xubuntu PCs to be 1933 sure that it is transported through the Router. Three tests will be 1934 conducted; sending "ping" and "traceroute" packets to confirm the 1935 basic connectivity as well as file transfer to verify TCP/IP 1936 capability. 1938 C.3.4. A separate second TP-Link Router will then be plugged into 1939 this first Router as a client IoT to verify that it would accept a 1940 240/4 address as its WAN port designation. Based on this, the second 1941 Router will serve as an RG providing the conventional private network 1942 environment (10/8, 172.16/12 and 192.168/16 netblocks) to common 1943 IoTs, allowing them to continue their current operations without 1944 modification, at all. 1946 C.4. SPR Reference Design 1948 The above pair of enhanced Routers can be used as the SPR model for 1949 enahancing industrial grade routers that are capable of the daily 1950 traffic level expected by a RAN. 1952 Note that including 240/4 netblock in the DHCP pool for the LAN of 1953 the first Router and accepting the 240/4 address assignment on the 1954 WAN port of the second Router are two orthogonal capabilities. They 1955 can be implemented in the same physical Router, consolidating both 1956 modifications into one single SPR module. 1958 C.5. RAN Deployment Model 1960 The above SPR reference design essentially is an existing common IPv4 1961 RG with two simple enhancements: 1963 I. Upstream (WAN) port capable of being a DHCP client accepting 240/4 1964 address assignment, in addition to the ordinary IPv4 public address. 1966 II. Downstream (LAN) port providing DHCP service to client IoTs 1967 using the 240/4 netblock, in addition to the three conventional 1968 private netblocks. 1970 By selectively activating these capabilities, three versions of SPRs 1971 can be derived for completing a functional RAN model: 1973 C.5.1. Root / Gateway SPR: This is the first SPR for starting a 1974 RAN from an IPv4 public address. As such, the upstream port of this 1975 SPR should accept a public IPv4 address. And, its downstream port 1976 will use the 240/4 netblock in its DHCP pool. 1978 Note that this particular type of SPR is only needed for a RAN 1979 demonstration setup. In an actual RAN deployment, a proxy gateway 1980 that caches the Internet traffic for improving the operation 1981 efficiency will naturally perform the same function of this Root SPR, 1982 by virtue of being a more capable two-port device. 1984 C.5.2. Intermediate SPRs: To optimize the performance 1985 requirements on the routing processor, a practical SPR is not 1986 expected to handle all 256M IoTs in a single module. A RAN should 1987 have several layers of SPRs in a tree structure, each handles a 1988 subset of the 240/4 netblock. This architecture enables processing 1989 local traffic locally. Only communications with distance parties need 1990 be consoliated by going through the higher layers of SPRs for 1991 delivery. For this type of SPRs, both their upstream DHCP client port 1992 and downstream DHCP Server pool will operate on sub-240/4 netblocks, 1993 segregated according to the numbering plan in the RAN system design. 1995 C.5.3. RG SPR: To serve existing IoTs on customer premises, this 1996 SPR will be configured to accept a 240/4 address on its upstream 1997 port, while the downstream port assigns addresses from the three 1998 conventional private netblocks to its DHCP client IoTs. 2000 Authors' Addresses 2002 Abraham Y. Chen 2003 Avinta Communications, Inc. 2004 142 N. Milpitas Blvd., #148, Milpitas, CA 95035-4401 US 2006 Phone: _+1(408)942-1485 2007 Email: AYChen@Avinta.com 2009 Abhay Karandikar 2010 Director, India Institute of Technology Kanpur 2011 Kanpur - 208 016, U.P., India 2013 Phone: _(+91)512 256 7220 2014 Email: Director@IITK.ac.in 2016 Ramamurthy R. Ati 2017 Avinta Communications, Inc. 2018 142 N. Milpitas Blvd., #148, Milpitas, CA 95035-4401 US 2020 Phone: _+1(408)458-7109 2021 Email: rama_ati@outlook.com 2023 David R. Crowe 2024 Wireless Telecom Consultant and Forensic Expert Witness 2025 102 Point Drive NW, Calgary, Alberta, T3B 5B3, Canada 2027 Phone: _+1(403)289-6609__ 2028 Email: David.Crowe@CNP-wireless.com