idnits 2.17.1 draft-chen-ati-adaptive-ipv4-address-space-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 7. IANA Considerations' ) ** The abstract seems to contain references ([15], [2], [16], [RFC791], [3], [17], [RFC862], [RFC2123], [4], [18], [RFC793], [5], [RFC6598], [6], [RFC2928], [7], [RFC6264], [8], [9], [10], [11], [12], [RFC1385], [13], [14], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 9, 2017) is 2328 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Missing reference section? '3' on line 875 looks like a reference -- Missing reference section? '4' on line 878 looks like a reference -- Missing reference section? '5' on line 880 looks like a reference -- Missing reference section? 'RFC6264' on line 160 looks like a reference -- Missing reference section? '6' on line 882 looks like a reference -- Missing reference section? '7' on line 884 looks like a reference -- Missing reference section? 'RFC791' on line 399 looks like a reference -- Missing reference section? '1' on line 869 looks like a reference -- Missing reference section? '2' on line 871 looks like a reference -- Missing reference section? 'RFC793' on line 354 looks like a reference -- Missing reference section? '8' on line 887 looks like a reference -- Missing reference section? 'RFC2123' on line 357 looks like a reference -- Missing reference section? '9' on line 889 looks like a reference -- Missing reference section? '10' on line 1214 looks like a reference -- Missing reference section? 'RFC1385' on line 435 looks like a reference -- Missing reference section? '11' on line 894 looks like a reference -- Missing reference section? '12' on line 896 looks like a reference -- Missing reference section? '13' on line 898 looks like a reference -- Missing reference section? '14' on line 901 looks like a reference -- Missing reference section? 'RFC862' on line 639 looks like a reference -- Missing reference section? '15' on line 904 looks like a reference -- Missing reference section? 'RFC2928' on line 645 looks like a reference -- Missing reference section? '16' on line 906 looks like a reference -- Missing reference section? 'RFC6598' on line 717 looks like a reference -- Missing reference section? '17' on line 908 looks like a reference -- Missing reference section? '18' on line 910 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 27 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 A. Y. Chen 2 Internet Draft R. R. Ati 3 Intended status: Experimental Avinta Communications, Inc. 4 Expires: June 2018 A. Karandikar 5 India Institute of Technology 6 December 9, 2017 8 Adaptive IPv4 Address Space 9 draft-chen-ati-adaptive-ipv4-address-space-02.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on June 9, 2017. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Abstract 51 This document describes a solution to the Internet address depletion 52 issue through the use of an existing Option mechanism that is part of 53 the original IPv4 protocol. This proposal, named EzIP (phonetic for 54 Easy IPv4), outlines the IPv4 public address pool expansion and the 55 Internet system architecture enhancement considerations. The EzIP may 56 expand an IPv4 address by a factor of 256M without affecting the 57 existing IPv4 based Internet, nor the current private networks. The 58 EzIP is in full conformance with the IPv4 protocol, and supports not 59 only both direct and private network connectivities, but also their 60 interoperability. The EzIP deployment may coexist with the current 61 Internet traffic and the IoT (Internet of Things) operations without 62 perturbing their setups, while offering end-users the freedom to 63 choose either. If the IPv4 public pool allocations were allowed to be 64 reorganized, the assignable pool could be multiplied by 512M times or 65 even more. The EzIP may be implemented as a software / firmware 66 enhancement to the Internet edge routers or private network routing 67 gateways wherever needed, or simply installed as an inline adjunct 68 hardware module between the two, enabling a seamless introduction. 69 The 256M case detailed herein establishes a complete layer of routers 70 for interfacing between the Internet core fabic and the end user 71 premises. Incorporating the caching proxy technology in the gateway, 72 a fairly large geographical area may deploy an EzIP based sub- 73 Internet operating from as few as one ordinary IPv4 public address. 74 This will immediately resolve the IPv4 address shortage anywhere, 75 while transparent to the current Internet operation. Under the Dual- 76 Stack environment, these proposed interim facilities will relieve the 77 IPv4 address shortage issue, while affording the IPv6 more time to 78 orderly reach the maturity and the availability levels required for 79 delivering a long-term general service. 81 Table of Contents 83 1. Introduction...................................................3 84 1.1. Contents of this Draft....................................5 85 2. EzIP Overview..................................................5 86 2.1. EzIP Numbering Plan.......................................5 87 2.2. EzIP System Architecture..................................6 88 2.3. IP Header with Option Word................................9 89 2.4. Examples of Option Mechanism.............................10 90 2.5. EzIP Header..............................................10 91 2.6. EzIP Operation...........................................11 92 3. EzIP Deployment Strategy......................................12 93 4. Updating Servers to Support EzIP..............................14 94 5. EzIP Enhancement and Application..............................15 95 6. Security Considerations.......................................19 96 7. IANA Considerations...........................................19 97 8. Conclusions...................................................19 98 9. References....................................................20 99 9.1. Normative References.....................................20 100 9.2. Informative References...................................20 101 10. Acknowledgments..............................................21 102 Appendix A EzIP Operation.......................................22 103 A.1. Connection between EzIP-unaware IoTs.....................22 104 A.1.1. T1a Initiates a Session Request towards T4a.........22 105 A.1.2. RG1 Forwards the Packet to SPR1.....................23 106 A.1.3. SPR1 Sends the Packet to SPR4 through the Internet..24 107 A.1.4. SPR4 Sends the Packet to T4a........................25 108 A.1.5. T4a Replies to SPR4.................................26 109 A.1.6. SPR4 Sends the Packet to SPR1 through the Internet..27 110 A.1.7. SPR1 Sends the Packet to RG1........................28 111 A.1.8. RG1 Forwards the Packet to T1a......................29 112 A.1.9. T1a Sends a Follow-up Packet to RG1.................29 113 A.2. Connection Between EzIP-capable IoTs.....................30 114 A.2.1. T1z Initiates a Session Request towards T4z.........30 115 A.2.2. RG1 Forwards the Packet to SPR1.....................31 116 A.2.3. SPR1 Sends the Packet to SPR4 through the Internet..32 117 A.2.4. SPR4 Sends the Packet to T4z........................33 118 A.2.5. T4z Replies to SPR4.................................34 119 A.2.6. SPR4 Sends the Packet to SPR1 through the Internet..35 120 A.2.7. SPR1 Sends the Packet to RG1........................36 121 A.2.8. RG1 Forwards the Packet to T1z......................37 122 A.2.9. T1z Sends a Follow-up Packet to RG1.................38 123 A.3. Connection Between EzIP-unaware and EzIP-capable IoTs....39 124 A.3.1. T1a Initiates a Request to T4z......................39 125 A.3.2. T1z Initiates a Request to T4a......................39 126 Appendix B Internet Transition Considerations...................40 127 B.1. EzIP Implementation......................................40 128 B.2. SPR Operation Logic......................................41 129 B.3. RG Enhancement...........................................42 131 1. Introduction 133 For various reasons, there is a large demand for IP addresses. It 134 would be useful to have a unique address for each Internet device, 135 such that if desired, any device may call any other. The Internet of 136 Things (IoT) would also be able to make use of more routable 137 addresses if they were available. Currently, these are not possible 138 with the existing IPv4 configuration. 140 By Year 2020, the world population and number of IoTs are expected to 141 reach 7.6B (Billion) and 50B respectively, according to a 2011 Cisco 142 online white paper [3]. 144 The IPv4 dot-decimal address format, consisting of four octets each 145 made of 8 binary bits, has the maximum number of assignable addresses 146 being 4,295 million (calculated by 256 x 256 x 256 x 256 to be 147 4,294,967,296 - decimal exact). Using the binary / shorthand notation 148 of 64K representing 256 x 256 (decimal 65,536), the full IPv4 address 149 pool of 64K x 64K may be expressed as 4,096M (Million), or 4.096B 150 (or, further rounded down to 4B for quick estimates). Clearly, the 151 demand is more than 13 times over the inherent capacity available 152 from the supply. 154 The IPv6 with 128-bit hexadecimal address format, being four times as 155 long as the IPv4, has 256BBBB (4B x 4B x 4B x 4B) combination. It 156 offers a promising solution to this problem. However, its global 157 adoption appears to face certain challenges [4], [5]. Network Address 158 and Port Translation (NAPT - commonly known simply as NAT) on private 159 networks together with Carrier Grade NAT (CG-NAT or abbreviated 160 further to CGN) [RFC6264] [6] over the public Internet have been 161 providing the interim relief for the IPv4 thus far. Yet, NAT modules 162 slow down routers due to the state-table look-up process. As well, 163 they only allow an Internet session be initiated by their respective 164 own clients, impeding the end-to-end setup requests initiated from 165 remote devices that a fully functional communication system should be 166 capable of. Being dynamic, the state-table used by CGN also increases 167 CyberSecurity vulnerability. 169 If the IPv4 capacity could be expanded to eliminate the address pool 170 deficiency while maintaining the familiar established conventions, 171 and perhaps even to create a reasonable address reserve, the urgency 172 will be relaxed long enough for the IPv6 to mature on its own pace. 174 To increase the effective Internet public address pool, there have 175 been various proposals in the past. They all seemed to run into 176 certain handicap or compatibility issue, preventing a seamless 177 transition. 179 The EzIP approach identifies a long-reserved address block 240/4 [7] 180 that all of the existing Internet Core (/ backbone) Router (CR), Edge 181 Router (ER) and private network Routing (/ Residential) Gateway (RG) 182 are not allowed to operate with, and teams with the Option mechanism 183 defined in [RFC791] [1] for transporting such information as the IP 184 header payload that is transparent to all these routers except a new 185 category, named Semi-Public Router (SPR). By inserting a SPR between 186 an ER and a private premises that it serves, each publicly assignable 187 address is expanded by 256M fold. 189 1.1. Contents of this Draft 191 The rest of this draft begins with outlining the EzIP numbering plan. 192 An enhanced IP header called EzIP header is introduced for carrying 193 the EzIP address as payload using the Option words. The overview of 194 the Internet architecture as the result of being extended by the EzIP 195 scheme is explained. The EzIP header transitions through various 196 routers and the Internet update considerations are described, with 197 details presented in Appendices A and B, respectively. Utilizing the 198 EzIP approach, a range of possibilities of expanding the publicly 199 assignable IPv4 address pool as well as enhancing the Internet 200 operations are then discussed. 202 2. EzIP Overview 204 2.1. EzIP Numbering Plan 206 The EzIP study began with making explicit the use of the reserved 207 private network address pools in very much the same manner as Private 208 Automatic Branch eXchange (PABX) switching machines utilizing locally 209 assigned "extension numbers" to expand the Public Switched Telephone 210 Network (PSTN) capacity by replicating a public telephone line to 211 multitudes of reusable private telephone numbers, each to identify a 212 local instrument. 214 At the first sight, this correlation may seem odd, because the PABX 215 extension numbers belong to a reusable private set separate from that 216 of the public telephone numbers and both are independently 217 expandable, while private network IP address is a specific subset 218 reserved from the overall IPv4 pool that is otherwise all public and 219 finite. However, the fact that neither of the latter two is allowed 220 to operate in the other's domain suggests that the proposed EzIP 221 numbering plan indeed may mirror the telephony practice. 223 The key concept is the partitioning of a finite public address pool 224 to put aside a block of special (called "Semi-Public" in the 225 presentation below) addresses that extends each remaining public 226 address to multitudes of sub-addresses, resulting in an effectively 227 much larger address resource. 229 In fact, the initial EzIP analysis identified the untold two-stage 230 subnetting process of 192.168/16 that has been practiced routinely by 231 consumer RG manufacturers for a long time. End-users are commonly 232 accustomed to an RG choosing one out of 256 values from the fourth 233 octet of the 192.18.K/24 block for identifying a private IoT. They 234 mostly are, however, unaware of the preceeding stage of selecting the 235 value "K" from the third octet of the 192.18/16 block, as the factory 236 default identification for an RG, is implicitly capable of expanding 237 a public IPv4 address by 256 times for supporting the corresponding 238 number of private premises, each in turn is capable of serving 256 239 IoTs utilizing the 192.168.K/24 block. 241 The elusive IPv4 240/4 block (240/8 - 255/8), been "RESERVED" for 242 "Future use" since 1981-09 as the result of the historical address 243 assignment evolution, was proposed to be redesignated for "Private 244 Use" near a decade ago [2]. However, as pointed out by its own 245 authors in Section 2. Caveats of Use, "Many implementations of the 246 TCP/IP protocol stack have the 240.0.0.0/4 address block marked as 247 experimental, and prevent the host from forwarding IP packets with 248 addresses drawn from this address block." This proposal did not get 249 advanced. 251 Substituting the third octet of 192.168/16 with addresses from the 252 240/4 block in the first stage RG and redefining it as a new category 253 of router, called SPR, the EzIP scheme circumvents the earlier 254 hurdles and achieves the address multiplication factor of 256M 255 without involving any existing router. 257 Since the 240/4 block could not be used by existing routers, the size 258 of the assignable IPv4 pool has actually been only 3.84B (4.096B - 259 256M). So, the overall public addressable pool created from this EzIP 260 approach is about 983MB (3.84B x 256M), which is over 19M times of 261 the expected Year 2020 IoTs. This certainly has the capacity to 262 support the short- to mid- term public IP address needs. 264 2.2. EzIP System Architecture 266 The new category of router, SPR is to be positoned inline between an 267 ER and the customer premises that it serves. After the original path 268 is re-established, the remaining addresses in the 240/4 block will be 269 used by the SPR to serve additional prmises. Figure 1 shows a general 270 view of the enhanced Internet system architecture with two SPRs, SPR1 271 and SPR4, deployed. Note that the "69.41.190.x" are static addresses. 272 In particular, the "69.41.190.145" is the permanent public Internet 273 address for Avinta.com. 275 +------+ 276 Web Server | WS0z | 277 +--+---+ 278 |69.41.190.145 279 | 280 | +-----+ 281 +--+ ER0 | 282 +--+--+ 283 | 284 +------+-------+ 285 +-------+ Core Routers +--------+ 286 | | (Internet) | | 287 +--+--+ +--------------+ +--+--+ 288 +-----+ ER1 | +-----+ ER4 | 289 | +-----+ | +-----+ 290 | | 291 |69.41.190.110 |69.41.190.148 292 240.0.0.0 +--+--+ +--+--+ 293 +-----------+ +-------+ +---------+ +------+ 294 | +-----+ SPR1| | | +-----+ SPR4+--+ | 295 | | +-----+ | | | +-----+ | | 296 | 240.0.0.1 ... 255.255.255.255 | | | | 297 +-----+ |...| Premises 4 |...| 298 | Premises 1 | | +---------+ | 299 +--+--+ | | | | 300 +---+ RG1 +--+ 240.0.0.0 | | 255.255.255.255 301 | +-----+ | | | 302 | Premises 1 | +----------+ | 303 | | | Premises 4 | 304 |192.168.1.3 |192.168.1.9 |240.0.0.10 |246.1.6.40 305 +--+--+ +--+--+ +--+--+ +--+--+ 306 | T1a | .... | T1z | | T4a | ....... | T4z | 307 +-----+ +-----+ +-----+ +-----+ 309 Figure 1 EzIP System Architecture 311 2.2.1. Referring to the lefthand portion labeled Premises 1 of 312 Figure 1, instead of assigning each premises a public IPv4 address as 313 in the common practice, an SPR like SPR1, is inserted between an 314 Internet Edge Router (ER1) and its connections to private network 315 Routing Gateways like RG1, for utilizing 240.0.0.0 through 316 255.255.255.255 of the 240/4 block to identify respective premises. 317 The RG1, serving either a business LAN (Local Area Network) or a 318 residential HAN (Home Area Network), uses addresses from one of the 319 private network blocks, 10/8, 172.16/12 and 192.168/16, such as 320 192.168.1.3 and 192.168.1.9 to identify the IoTs, T1a and T1z, 321 respectively. 323 2.2.2. The righthand portion of Figure 1 is labeled Premises 4. 324 Here SPR4 assigns addresses 240.0.0.10 and 246.1.6.40 from the 240/4 325 block to T4a and T4z, respectively. Consequently, these IoTs are 326 directly accessible through SPR4 from any other device on the 327 Internet. 329 2.2.3. Since the existing physical connections to subscriber's 330 premises appear at the ER, it is natural to have SPRs be collocated 331 with their ER. It follows that the simple routing function provided 332 by the new SPR modules may be absorbed into the ER through a 333 straightforward operational firmware enhancement. Consequently, the 334 public / private demarcation line will remain at the RG where 335 currently all utility services enter a subscriber's premises. 337 2.2.4. To fully tag each of these devices, we may use a 338 concatenated three-part address notation, "Public - Semi-Public: TCP 339 Port". The following is how each of the IoTs in Figure 1 may be 340 uniquely identified in the Internet. 342 RG1: 69.41.190.110-240.0.0.0 344 T1a: 69.41.190.110-240.0.0.0:3 346 T1z: 69.41.190.110-240.0.0.0:9 348 T4a: 69.41.190.148-240.0.0.10 350 T4z: 69.41.190.148-246.1.6.40 352 Note that to simplify the presentation, it is assumed at this 353 juncture that the conventional TCP (Transmission Control Protocol) 354 [RFC793] [8] Port Number, normally assigned to T1a and T1z by RG1's 355 NAT module upon initiating a session, equals to the fourth octet of 356 that IoT's private IP address that is assigned by the RG1's DHCP 357 (Dynamic Host Configuration Protocol) [RFC2123] [9] subsystem as ":3" 358 and ":9", respectively. Such numbers are unique within each 359 respective /24 private network such as the 192.18.1/24 here. They are 360 adequate for the discussion purpose in this document. However, 361 considering security, as well as allowing each IoT to have multiple 362 simultaneous sessions, etc., this direct and singular correlation 363 shall be avoided in actual practice by following the NAT operation 364 conventions as depicted by the examples in Appendix A. 366 Figure 2 groups IoTs, routers and servers in two separate columns, 367 EzIP-unaware or EzIP-capable, to facilitate discussions that will 368 follow. 370 +--------------------------+-----------------+----------------+ 371 | | EzIP-unaware | EzIP-capable | 372 +--------------------------+-----------------+----------------+ 373 | Internet Core Router (CR)| CR | ------------ | 374 +--------------------------+-----------------+----------------+ 375 | Internet Edge Router (ER)| ER0, ER1, ER4 | ------------ | 376 +--------------------------+-----------------+----------------+ 377 | Internet of Things (IoT) | T1a, T4a | T1z, T4z | 378 +--------------------------+-----------------+----------------+ 379 | Routing Gateway (RG) | RG1 | ------------ | 380 +--------------------------+-----------------+----------------+ 381 | Semi-Public Router (SPR) | ------------- | SPR1, SPR4 | 382 +--------------------------+-----------------+----------------+ 383 | Web Server (WS) | ------------- | WS0z | 384 +--------------------------+-----------------+----------------+ 386 Figure 2 EzIP System Components 388 2.3. IP Header with Option Word 390 To transport the EzIP Extension Addresses, we will make use of the 391 Option mechanism in the IP header as defined in Figure 9 of [RFC791]. 392 One specific aspect of its format,deserves some attention. The 393 meanings of the leading eight bits of each Option word, "Opt. Code" 394 or "Option-type octet", are defined on Page 15 of [RFC791]. They are 395 somewhat confusing because the multiple names used in the literature, 396 and how the octet is parsed into functional bit groups. For example, 397 a two digit hexadecimal number, "0x9A", is conventionaly written in 398 the binary bit string form as "1001 1010". As an "Opt. Code" in 399 [RFC791], the eight bits are parsed into three groups of 1, 2 and 5 400 bits. Their meanings are summarized in Figure 3. 402 +-------------------------------------------------------------+ 403 | Meaning of EzIP ID = 0x9A (Example) | 404 +--------------+--------------------+-------------------------+ 405 | 1 | 00 | 11010 (or, 26 base 10) | 406 +--------------+--------------------+-------------------------+ 407 | Copy Bit Set | Class is Control | Option Value | 408 +--------------+--------------------+-------------------------+ 410 Figure 3 Option Type Octet 412 A value of "1" for the first bit instructs all routers that this 413 Option word is to be copied upon packet fragmentation. This preserves 414 the Option word through such a process, if it is needed. 416 The value of "00" for the next two bits indicates that this Option 417 word is for "Control" purpose. 419 The decimal "Option Value" of the last five bits, equaling to "26" is 420 defined as the "Option Number" that appears in the "Number" column 421 of the Internet Protocol Version 4 (IPv4) Parameters list [10]. As 422 can be seen there, "26" has not been assigned. Thus, it is 423 temporarily used in this document to facilitate the EzIP 424 presentation. The next unassigned Option Code, "0x9B" or Number "27" 425 will also be tentatively utilized in this document. 427 2.4. Examples of Option Mechanism 429 The Option mechanism has been used for various cases. Since they were 430 mostly for utility or experimental purposes, however, their formats 431 may be remote from the incident topic. There were two cases 432 specifically dealt with the address pool issues. They are referenced 433 here to assist the appreciation of the Option mechanism. 435 A. EIP (Extended Internet Protocol) - Figure 1 of [RFC1385] [11] 436 (Assigned but now deprecated Option Number = 17) by Z. Wang: This 437 approach proposed to add a new network layer on top of the existing 438 Internet for increasing the addressable space. Although equipment 439 near the end-user would stay unchanged, equipments among the CR 440 apparently had to go through rather extensive upgrading procedures, 441 perhaps due to the flexible length of the extended address (could be 442 much longer than that of the IPv6). 444 B. EnIP (Enhanced IPv4) - Figure 1 of Internet Draft [12] 445 (temporarily utilizing Option Number = 26) by W. Chimiak: This work 446 makes use of the three private network blocks to extend the public 447 pool by trading the private network operation for end-to-end 448 connectivity. The fully deployed EnIP would eliminate the current 449 private networks that may be against the preference of end-users who 450 have found this facility quite desirable. For example, the NAT in an 451 RG serves as a basic firewall against intrusion. 453 2.5. EzIP Header 455 The header format shown in Figure 4 can transport the full 4 octet 456 (32 bit) extension addresses of both ends of an Internet link. The 457 extension address in the 240/4 block utilized in the EzIP scheme 458 described herein has 28 significant bits. It is possible for EzIP to 459 use addresses having other lengths of significant bits for different 460 multiplication factors. To prepare for such variations, two EzIP ID 461 codes, "0x9A" and "0x9B" are proposed to at least distinguish between 462 Source and Destination Option words. 464 0 1 2 3 465 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 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 1 |Version|IHL (8)|Type of Service| Total Length (32) | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 2 | Identification |Flags| Fragment Offset | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 3 | Time to Live | Protocol | Header Checksum | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 4 | Source Host Number | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 5 | Destination Host Number | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | EzIP ID | EzIP | Extended | Extended | 478 6 | (Source) | Option Length | Source | Source | 479 | (0X9A) | (6) | No.-1 | No.-2 | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Extended | Extended | EzIP ID | EzIP | 482 7 | Source | Source | (Destination) | Option Length | 483 | No.-3 | No.-4 | (0X9B) | (6) | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Extended | Extended | Extended | Extended | 486 8 | Destination | Destination | Destination | Destination | 487 | No.-1 | No.-2 | No.-3 | No.-4 | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 Figure 4 Full EzIP Header (Four octet) 492 2.6. EzIP Operation 494 To convey the general scheme, Appendix A presents examples of IP 495 header transitions through routers, between IoTs with or without EzIP 496 capability. 498 To introduce the EzIP approach into an environment where EzIP-unaware 499 IoTs like T1a and T4a will be numerous for a long time to come, a SPR 500 must be able to follow certain decision rules to determine how to 501 provide the appropriate routing service for a smooth transition to 502 the long term operation. Appendix B outlines such logic and related 503 considerations. 505 3. EzIP Deployment Strategy 507 Although the eventual goal of the SPR is to support both web server 508 access by IoTs from behind private networks and direct end-to-end 509 connectivity between IoTs, the former should be dealt with first to 510 immediately mitigate the address shortage induced issues. In the 511 process, the long term capability for the latter will be naturally 512 built up. 514 A. Architecturally 516 Since the design philosophy of the SPR is an inline module between an 517 Internet ER (Edge Router) and the private network RG (Routing 518 Gateway) it serves, SPR introduction process can be flexible. 520 A.1. A SPR may be deployed as an inline module right after an ER 521 to begin providing the CGN equivalent function. This could be done 522 immediately without affecting any of the existing Internet 523 components, CR, ER and RG. EzIP-capable IoTs will then take advantage 524 of the faster bi-directional routing service through the SPRs by 525 initiating communication sessions with EzIP headers to other EzIP- 526 capable IoTs. 528 A.2. Alternatively, a SPR may be deployed as an adjunct module 529 just before an existing RG or a directly connected IoT to realize the 530 same EzIP functions on the private premises, even if the serving 531 Internet Access Provider (IAP) has not enhanced ERs with the EzIP 532 capability. 534 This approach could empower individual communities to enjoy the 535 new EzIP capability on their own by upgrading all Internet 536 subscribers within a good sized area to have publicly accessible EzIP 537 addresses for intra-community peer-to-peer communication, based on 538 just one (or more) existing public IPv4 address(es) for identifying 539 the gateway(s) to the rest of the world. See sub-section C. below for 540 more specific considerations. 542 B. Functionally 544 B.1. First, an IAP should install SPRs in front of business web 545 servers so that new routing branches may be added to support the 546 additional web servers for expanding business activities. 547 Alternatively, this may be achieved if businesses on their own deploy 548 new web servers with the SPR capability built-in. 550 B.2. On the subscriber side, SPRs should be deployed to relieve 551 the public address shortage issue, and to facilitate the access to 552 new web servers. 554 C. Regional Deployment 556 C.1. Since the size of the 240/4 block is significant, a 557 community mentioned in sub-section A.2. above could actually be 558 fairly large. Based on the assumption that on the average, each 559 person may have 6.6 IoTs by Year 2020 Error! Reference source not 560 found., each 240/4 block is capable of serving more than 36M (256M / 561 6.6) people. This exceeds the population of the largest city on earth 562 (Tokyo Metro.: population 33M). Therefore, any finite sized region 563 can immediately begin to enjoy EzIP addressing by deploying a "sub- 564 Internet" utilizing SPRs operating with one 240/4 block of addresses 565 from one IPv4 public address. If the gateway for such a region is 566 configured in a way that the entire region appears to be one ordinary 567 IPv4 IoT to the rest of the Internet, a sub-Internet may be deployed 568 anywhere there is the need or desire, with no perturbation to the 569 current Internet operation whatsoever. 571 C.2. This gateway may be constructed with a matured networking 572 technology called Caching Proxy [13], popularized by data-intensive 573 web services such as Google, Amazon, Yahoo, etc. Developed for 574 speeding up response to queries while minimizing Internet traffic of 575 repeated data exchanges with the central data bank, caching proxies 576 are placed at strategic locations close to potential inquirers, 577 essentially cloning the central data bank into mulitple distributed 578 copies. This architecture meshs with EzIP-based sub-Internet very 579 well, because the address translation between the IPv4 in the 580 Internet and the EzIP in the sub-Internet can be accomplished 581 transparently through the two ports of a caching proxy. Consequently, 582 the existing Internet routers, CR and ER even will not see any IP 583 packet with EzIP header at all, during the initial phase of operation 584 which will be mostly basic web server access. 586 C.3. This configuration actually mimicks the PABX environment 587 almost exactly. Since this entire region is only accessible through 588 the gateway that performs the address translation, the words 4 and 5 589 (Source and Destination Host Numbers, respectively) in the basic IP 590 header for an intra sub-Internet packet could simply use the 591 addresses in the 240/4 block for expediting the routing by the SPRs. 592 This mirrors the telephone dialing procedures using only extension 593 numbers among stations served by the same PABX. The full EzIP header 594 format will only be used when an EzIP-capable IoT intends to directly 595 interact with another EzIP-capable IoT beyond the local sub-Internet. 597 D. Permanently 599 In the long run, it would be best if SPRs are integrated into ERs by 600 upgrading the latter's firmware to minimize the hardware and to 601 streamline the overall system architecture. 603 Appendix B details the considerations in implementing these outlines. 605 4. Updating Servers to Support EzIP 607 Although the IP header Option mechanism utilized by EzIP was defined 608 a long time ago as part of the original IPv4 protocol, it has not 609 been used much in daily traffic. Compatibility with current Internet 610 facilities and conventions may need be reviewed. Since the EzIP data 611 is transported as part of the IP header payload, it is not expected 612 to affect higher layer protocols. However, certain facilities may 613 have been optimized without considering the Option mechanism. They 614 need be adjusted to provide the same performance to EzIP packets. 615 There are also utility type of servers that need be updated to 616 support the longer EzIP address. For example; 618 A. Fast Path 620 Internet Core Routers (CRs) are currently optimized to only provide 621 the "fast-path" (through hardware line card) routing service to 622 packets without Option word in the IP header [14]. This puts EzIP 623 packets at a disadvantage position, because EzIP packets will have to 624 go through the "slow path" (processed by CPU's software before giving 625 to the correct hardware line card to forward), resulting in a slower 626 throughput. Since the immediate goal of the EzIP is to ease the 627 address pool exhaustion issue, subscribers not demanding for high 628 throughput performance may be migrated to the EzIP supported facility 629 first. This gives CRs time to update so that EzIP packets with 630 authorized Option numbers will eventually be recognized for receiving 631 the "fast-path" service. 633 B. Connectivity Verification 635 One frequently used utility for verifying baseline connectivity, 636 commonly referred to as the "PING" function in PC terminology, needs 637 be able to transport the full EzIP address that is 64 bits long 638 instead of the standard 32 bit IPv4 address. There is an example of 639 an upgraded TCP echo server in [RFC862] [15]. 641 C. Domain Name Server (DNS) 642 Similarly, the DNS needs to expand its data format to transport the 643 longer IP address created by the EzIP. This already can be done under 644 IPv6. Utilizing the experimental IPv6 prefix 2001:0101 defined by 645 [RFC2928] [16], EzIP addresses may be transported as standardized 646 AAAA records. 648 These topics are discussed in more detail under an IETF Draft RFC, 649 Enhanced IPv4 - V.03 [12]. 651 5. EzIP Enhancement and Application 653 To avoid disturbing any assigned addresses, deployed equipment and 654 current operation, etc., the EzIP scheme is derived under the 655 constraint of utilizing only the reserved 240/4 address block. If 656 such restriction were removed by allowing the entire IPv4 address 657 pool be re-allocatable, the assignable public address pool could be 658 expanded even more. 660 A. If the 240/4 block were doubled to 224/3, each existing IPv4 661 public address would be expanded by 512M fold. Since this block of 662 512M addresses have to be first reserved from the basic public pool, 663 the resultant total addresses will be (4.096B - 512M) x 512M, or 664 1,835MB. This is over 36M times of the predicted number of IoTs (50B) 665 by Year 2020. This calculation leads to additional possibilities. 667 B. The EzIP header in Figure 4, capable of transporting the full 32 668 bit IPv4 address, allows the extension number be as long as 669 practical. That is, we can go to the extreme of reserving only one 670 bit for the network number, and using all of the rest bits for the 671 extension address. With this criterion, the current IPv4 pool may be 672 divided into two halves, reserving one half of it (about 2B 673 addresses) as a semi-public network with the network number prefix 674 equal to "1". Each of the remaining 2B public addresses (with prefix 675 equal to "0") of the basic IPv4 pool may then be extended 2B fold 676 through the EzIP process, resulting in a 4BB address pool. This is 677 roughly 80M times of the Year 2020 IoT needs. 679 C. If the EzIP technique were applied through several layers of SPRs 680 in succession, the address expansion could be even more. For example, 681 let's divide the IPv4 pool equally into four blocks, each with about 682 1B addresses. Apply the first 1B address block to the public routers. 683 Set up three layers of SPRs, each makes use of one of the remaining 684 three 1B addresses. The resultant assignable pool will have 1BBBB 685 addresses. Under this configuration, the full length of an IoT's 686 identification code will be the concatenation of four segments of 32 687 bit IPv4 address, totalling 128 bits, the same as that of the IPv6. 688 Since the first two bits of each segment, being used to distinguish 689 from the other three address blocks, are not significant bits, this 690 8-bits difference makes the IPv6 pool 256 times larger. However, this 691 ratio is immaterial, because even the 1BBBB address pool is alreaby 692 20MBB times of the foreseeable need. It is the hierarchical 693 addressing characteristics, made possible by the EzIP scheme, that 694 will enhance the Internet, such as truncating out the common address 695 prefix within a local community, and associating an address with 696 geographical reference, thus mitigating the GeoLocation issues. 698 D. Along this line of reasoning, we could combine two 1B address 699 blocks togther to be the basic public address. The overall assignable 700 pool becomes 2BBB which is still 40MB times of the expected IoT 701 need(50B). With this pool, we can divide the entire globe into 2B 702 regions, each served by one public routers. Each region can be 703 divided into 1B sections, identified by the first group of SPRs. Each 704 section will have the second group of SPRs to manage upto 1B IoTs. 705 Since the basic 2B public addresses are already more than half of the 706 current total assignable IPv4 public addresses, their potential 707 GeoLocation resolution capabilities are comparable. With additional 708 two layers of SPR routing, the address grid granuality will be so 709 refined that locating the source of an IP packet becomes a finite 710 task, leaving perpetrators little room to hide. 712 E. The following outlines a possible procedure for optimizing the use 713 of the EzIP address resource by transforming the current Internet to 714 a GeoLocation-capable EzIP-based address system while maintaining the 715 existing IPv4 addressing and operation conventions: 717 a. Quantitative Reference: IETF [RFC6598] [17] reserved the 718 100.64.0.0/10 block with 4M addresses for supporting ISP's CGN 719 service. Applying all of these to the entire IPv4 pool of 4B 720 addresses, the maximum effective CGN supported IPv4 address pool 721 could be 16MB. This is 0.32M times of the expected number (50B) of 722 IoTs by Year 2020. 724 b. Employing the 240/4 block with 256M addresses in the EzIP 725 extension scheme, a /6 block with 64M addresses from the IPv4 basic 726 public pool is sufficient to replicate the above 16MB capacity. This 727 frees up the majority of the IPv4 public pool. 729 c. Since this will be a temporary holding pool for releasing the 730 current addresses for new assignments, it should occupy as few public 731 addresses as possible, leaving the maximum number of addresses for 732 facilitating the long term planning. To just support the expected 50B 733 IoTs need, only 200 IPv4 public addresses are required (200 x 256M = 734 50B). Thus, a /24 block with 256 addresses is more than enough to 735 accommodate this entire migration process. This frees up even more 736 IPv4 public addresses. 738 d. Although a single /24 public address block is sufficient for 739 migrating all currently perceived IPv4 address needs into one compact 740 temporary EzIP pool, world-wide coordination of new address 741 assignments and routing tables updates will be required. It may be 742 more expeditious by carrying out this preparatory phase on individual 743 country or geographical region basis utilizing public IPv4 addresses 744 already assigned to that area and actively served by existing CR 745 routing tables. Since 200 public addresses are enough to port the 746 entire IoT addresses, most countries should be able to port all of 747 their respective in-use IoTs to be under fewer than a handful of 748 gateways for accessing the Internet. Under each gateway, one 240/4 749 block will handle the IoT address assignments. If this is managed 750 according to geographical locations, each participating region will 751 begin to enjoy the benefits of the EzIP approach, such as plentifull 752 assignable public addresses, robust security due to inherent 753 GeoLocation ability to spot hackers from within, so that efforts may 754 be focused on only screening suspicious packets originated from 755 without. 757 e. As IoTs getting migrated to the temporary pool, the IPv4 758 addresses they originally occupy shall be released to re-populate the 759 public address pool for establishing the full scale EzIP operation. 761 f. Upon the completion of the EzIP based world-wide public address 762 allocation map, each country can simply give up the few temporary 763 public addresses in exchange for the permanent assignments. Since the 764 latter is likely more than the former, addresses in one 240/4 block 765 can be carried by two (or more) 240/4 blocks. Each 240/4 block, using 766 one separate permanent public address identified gateway to access 767 the worldwide Internet, will have more than half of its capacity 768 available to serve additional IoTs. 770 g. This last step is very much the same as the traditional PSTN 771 "Area Code Split" practice, whereby telephone numbers of a service 772 area are split into two (or more) blocks, upon introducing one (or 773 more) new area code(s) into the area. All subscribers will continue 774 to use their original telephone numbers, except some may be assigned 775 with a new area code prefix. Each area code will have more than half 776 of the assignable telephone numbers availabe to support the future 777 subscriber growth within its service area. Mimicking the PSTN, the 778 EzIP based Internet will have similar GeoLocation capability as the 779 former's caller identification based services, such as the 911 780 emergency caller location system in US, mitigating the root cause of 781 the cybersecurity vulnerability. 783 F. With the IPv4 address pool shortage issue resolved, potential 784 additional applications making use of the EzIP enhanced address pool 785 may be explored. 787 a. Although the entire predicted number (50B) of IoTs by Year 2020 788 may be served by just one /24 IPv4 public address block under the 789 EzIP scheme, let's replace it with a /8 block, resulting in about 4MB 790 (16M x 256M) assignable addresses. Then, only 1 out of each 80K such 791 addresses will be used by the 50B IoTs. In fact, each and every 792 person (at Year 2020 population level) would have to own over 500K 793 IoTs to use up this address pool. It is apparent that the spares in 794 this allocation should be sufficient to support the growth of the 795 IoTs for some years to come. 797 b. The IPv4 originally has 256 blocks of /8 addresses. After 798 reserving 16 blocks of them (the 240/4 block) as the reusable EzIP 799 extension address and one to complete the pool for the above IoT 800 needs, there are still 239 blocks of /8 addresses available to 801 support additional digital communication systems, each may have as 802 many addresses as allocated to the Internet. Consequently, many 803 world-wide communication networks may coexist under the same IPv4 804 protocol framework in the form of sub-Internets as described earlier, 805 with arms-length links among them. 807 c. For example, a satellite based Internet that is being proposed 808 [18], can simply start fresh with one EzIP sub-Internet under one ER 809 capable of managing one /8 block of IPv4 public address. Utilizing 810 caching proxy as the gateway to handle the data exchange with other 811 systems, this satellite Internet with 256M hosts will operate pretty 812 much as an isolated system by using 240/4 addresses in the basic IP 813 headers for intra-system communications, most of the time. Only when 814 direct communication with another sub-Internet (such as the one for 815 the current Internet) is needed, full EzIP header will be used. As 816 users grow, additional sub-Internets, upto 16M of them, may be added. 818 G. In summary, utilizing the 240/4 address block, the EzIP scheme may 819 expand the IPv4 based Internet to be a collection of up to 240 groups 820 of 16M sub-Internets that are inter-operable digital communication 821 systems, normally operate at arm's-lenghth to one another. Each of 822 these groups will have the address capacity of at least 80K times of 823 the number of predicted (50B) IoTs by Year 2020. 825 6. Security Considerations 827 The EzIP solution is based on an inline module called SPR that 828 intends to be as transparent to the Internet traffic as possible. 829 Thus, no overall system security degradation is expected. 831 7. IANA Considerations 833 This draft does not create a new registry nor does it register any 834 values in existing registries; no IANA action is required. 836 8. Conclusions 838 To resolve the IPv4 public address pool exhaustion issue, a technique 839 called EzIP (phonetic for Easy IPv4) making use of a long reserved 840 address block 240/4 is proposed. 842 This draft RFC describes an enhancement to IPv4 operation utilizing 843 the IP header Option mechanism defined in RFC791. Because the design 844 criterion is to enhance IPv4 by extending instead of altering it, the 845 impact on already in-place routers and security mechanisms is 846 minimized. 848 The basic EzIP intention is to maintain the existing private network 849 configuration. Upon reclassifying the "RESERVED for Future use" 240/4 850 block to be the Semi-Public address pool, it will only be usable by 851 the new SPR (Semi-Public Router) as the EzIP extension address. This 852 pool can multiply each current IPv4 public address by 256M times, 853 while all existing public network and subscriber premises setups 854 (private networks as well as directly connected IoTs) will remain 855 unchanged. This particular manifestation of the EzIP scheme appears 856 to be the optimal solution to our needs. 858 The 240/4 block based EzIP scheme will not only relief the IPv4 859 address shortage issue, but also improves the defense against 860 cybersecurity intrusion. Furthermore, the EzIP will transcend the 861 IPv4 based Internet to become the common backbone for multiple 862 digital communication systems that normally may operate in arm's- 863 length from one another. 865 9. References 867 9.1. Normative References 869 [1] https://tools.ietf.org/html/rfc791 871 [2] https://tools.ietf.org/html/draft-wilson-class-e-02 873 9.2. Informative References 875 [3] https://www.cisco.com/c/dam/en_us/about/ac79/docs/innov/IoT_IBS 876 G_0411FINAL.pdf 878 [4] http://stats.labs.apnic.net/ipv6 880 [5] https://ams-ix.net/technical/statistics/sflow-stats/ether-type 882 [6] https://tools.ietf.org/html/rfc6264 884 [7] http://www.iana.org/assignments/ipv4-address-space/ipv4- 885 address-space.xhtml 887 [8] https://tools.ietf.org/html/rfc793 889 [9] https://www.ietf.org/rfc/rfc2131.txt 891 [10] http://www.iana.org/assignments/ip-parameters/ip- 892 parameters.xhtml 894 [11] https://tools.ietf.org/html/rfc1385 896 [12] https://tools.ietf.org/html/draft-chimiak-enhanced-ipv4-03 898 [13] https://en.wikipedia.org/wiki/Proxy_server#Improving_performanc 899 e 901 [14] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.477.19 902 42&rep=rep1&type=pdf 904 [15] https://tools.ietf.org/html/rfc862 906 [16] https://tools.ietf.org/html/rfc2928 908 [17] https://tools.ietf.org/html/rfc6598 910 [18] https://www.commerce.senate.gov/public/index.cfm/2017/10/the- 911 commercial-satellite-industry-what-s-up-and-what-s-on-the- 912 horizon 914 10. Acknowledgments 916 The authors would express their deep appreciation to Dr. W. Chimiak 917 for the enlightening discussions about his team's efforts and 918 experiences through the EnIP development. 920 This document was prepared using 2-Word-v2.0.template.dot. 922 Appendix A EzIP Operation 924 To demonstrate how EzIP could support and enhance the Internet 925 operations, the following are three sets of examples that involve 926 SPRs as shown in Figure 1. These present a general perspective of how 927 IP header transitions through the routers may look like. 929 1. The first example is between EzIP-unaware IoTs, T1a and T4a. This 930 operation is very much like the conventional TCP/IP packet 931 transmission except with SPRs acting as an extra pair of routers 932 providing CGN service. 934 2. The second one is between EzIP-capable IoTs, T1z and T4z. Here, 935 the SPRs process the extended semi-public IP addresses in router 936 mode, avoiding the delays due to the NAT type of operations above. 938 3. The last one is between EzIP-unaware and EzIP-capable IoTs. By 939 initiating and responding with a conventional IP header, T1z and T4z 940 behave like an EzIP-unaware IoT. Thus, all packet exchanges use the 941 conventional IP headers, just like case 1. above. 943 A.1. Connection between EzIP-unaware IoTs 945 A.1.1. T1a Initiates a Session Request towards T4a 947 In Figure 5, T1a initiates a session request to SPR4 that serves T4a 948 by sending an IP packet to RG1. There is no TCP port number in this 949 IP header yet. 951 0 1 2 3 952 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 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 1 |Version|IHL (5)|Type of Service| Total Length (20) | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 2 | Identification |Flags| Fragment Offset | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 3 | Time to Live | Protocol | Header Checksum | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 4 | Source Host Number (192.168.1.3) | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 5 | Destination Host Number (69.41.190.148) | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 Figure 5 IP Header: From T1a to RG1 967 A.1.2. RG1 Forwards the Packet to SPR1 969 In Figure 6, RG1, allowing be masqueraded by T1a, relays the packet 970 toward SPR1 by assigning the TCP Source port number, 3N, to T1a. Note 971 that the suffix "N" denotes the actual TCP port number assigned by 972 the RG1's NAT. This could assume multiple values, each represents a 973 separate communications session that T1a is engaged in. A 974 corresponding entry is created in the state table for handling the 975 responding reply packet from the Destination site. Since T4a's TCP 976 port number is not known yet, it is filled with all 1's. 978 0 1 2 3 979 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 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 1 |Version|IHL (5)|Type of Service| Total Length (24) | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 2 | Identification |Flags| Fragment Offset | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 3 | Time to Live | Protocol | Header Checksum | 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 4 | Source Host Number (240.0.0.0) | 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 5 | Destination Host Number (69.41.190.148) | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 6 | Source Port (3N) | Destination Port (All 1's) | 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 Figure 6 TCP/IP Header: From RG1 to SPR1 996 A.1.3. SPR1 Sends the Packet to SPR4 through the Internet 998 In Figure 7, SPR1 allowing masqueraded by RG1 (with the Source Host 999 Number changed to be its own and the TCP port number changed to 0C, 1000 where "C" stands for CGN) sends the packet out through the Internet 1001 towards SPR4. The packet traverses through the Internet (ER1, CR and 1002 ER4) utilizing only the basic IP header portion of address 1003 information (words 4 & 5). 1005 0 1 2 3 1006 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 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 1 |Version|IHL (5)|Type of Service| Total Length (24) | 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 2 | Identification |Flags| Fragment Offset | 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 3 | Time to Live | Protocol | Header Checksum | 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 4 | Source Host Number (69.41.190.110) | 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 5 | Destination Host Number (69.41.190.148) | 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 6 | Source Port (0C) | Destination Port (All 1's) | 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 Figure 7 TCP/IP Header: From SPR1 to SPR4 1023 A.1.4. SPR4 Sends the Packet to T4a 1025 Since the packet has a conventional IP header without Destination TCP 1026 port number, SPR4 would ordinarily drop it due to the CGN function. 1027 However, for this example, let's assume that there exists a state- 1028 table that was set up by a DMZ (De-Militaried Zone) process for 1029 redirecting this packet to T4a with a CGN TCP port number 10C (the 1030 fourth octet, "10" of T4a's Extension address.). In Figure 8, SPR4 1031 sends the packet to T4a by constructing the destination address 1032 accordingly. 1034 0 1 2 3 1035 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 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 1 |Version|IHL (5)|Type of Service| Total Length (24) | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 2 | Identification |Flags| Fragment Offset | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 3 | Time to Live | Protocol | Header Checksum | 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 4 | Source Host Number (69.41.190.110) | 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 5 | Destination Host Number (240.0.0.10) | 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 6 | Source Port (0C) | Destination Port (10C) | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 Figure 8 TCP/IP Header: From SPR4 to T4a 1052 A.1.5. T4a Replies to SPR4 1054 In Figure 9, when T4a replies to SPR4, it interchanges the Source and 1055 Destination identifications to create an IP header for the reply 1056 packet. 1058 0 1 2 3 1059 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 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 1 |Version|IHL (5)|Type of Service| Total Length (24) | 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 2 | Identification |Flags| Fragment Offset | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 3 | Time to Live | Protocol | Header Checksum | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 4 | Source Host Number (240.0.0.10) | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 5 | Destination Host Number (69.41.190.110) | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 6 | Source Port (10C) | Destination Port (0C) | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 Figure 9 TCP/IP Header: From T4a to SPR4 1076 A.1.6. SPR4 Sends the Packet to SPR1 through the Internet 1078 In Figure 10, SPR4 sends the packet toward SPR1 with the following 1079 header through the Internet (ER4, CR and ER1) who will simply relay 1080 the packet according to the information in word 5 (Destination Host 1081 Number): 1083 0 1 2 3 1084 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 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 1 |Version|IHL (5)|Type of Service| Total Length (24) | 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 2 | Identification |Flags| Fragment Offset | 1089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 3 | Time to Live | Protocol | Header Checksum | 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 4 | Source Host Number (69.41.190.148) | 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 5 | Destination Host Number (69.41.190.110) | 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 6 | Source Port (10C) | Destination Port (0C) | 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 Figure 10 TCP/IP Header: From SPR4 to SPR1 1101 A.1.7. SPR1 Sends the Packet to RG1 1103 In Figure 11, RG1 address is reconstructed by using the information 1104 in the CGN state-table stored in SPR1. 1106 0 1 2 3 1107 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 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 1 |Version|IHL (5)|Type of Service| Total Length (24) | 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 2 | Identification |Flags| Fragment Offset | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 3 | Time to Live | Protocol | Header Checksum | 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 4 | Source Host Number (69.41.190.148) | 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 5 | Destination Host Number (240.0.0.0) | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 6 | Source Port (10C) | Destination Port (3N) | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 Figure 11 TCP/IP Header: From SPR1 to RG1 1124 A.1.8. RG1 Forwards the Packet to T1a 1126 In Figure 12, T1a address is reconstructed from the state-table in 1127 RG1's NAT based on Destination Port (3N). 1129 0 1 2 3 1130 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 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 1 |Version|IHL (5)|Type of Service| Total Length (24) | 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 2 | Identification |Flags| Fragment Offset | 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 3 | Time to Live | Protocol | Header Checksum | 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 4 | Source Host Number (69.41.190.148) | 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 5 | Destination Host Number (192.168.1.3) | 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 6 | Source Port (10C) | Destination Port (3N) | 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 Figure 12 TCP/IP Header: From RG1 to T1a 1147 A.1.9. T1a Sends a Follow-up Packet to RG1 1149 To carry on the communication, T1a in Figure 13 sends the follow-up 1150 packet to RG1 with a full TCP/IP header. 1152 0 1 2 3 1153 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 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 1 |Version|IHL (5)|Type of Service| Total Length (24) | 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 2 | Identification |Flags| Fragment Offset | 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 3 | Time to Live | Protocol | Header Checksum | 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1161 4 | Source Host Number (192.168.1.3) | 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 5 | Destination Host Number (69.41.190.148) | 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 6 | Source Port (3N) | Destination Port (10C) | 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 Figure 13 TCP/IP Header: Follow-up Packets From T1a to RG1 1170 A.2. Connection Between EzIP-capable IoTs 1172 The following is an example of EzIP operation between T1z and T4z 1173 shown in Figure 1. Each knows its own full "Public - EzIP : Private" 1174 network addresses, "69.41.190.110-240.0.0.0:9" and "69.41.190.148- 1175 246.1.6.40", respectively, as well as the other's. Note that T4z is 1176 directly addressable from the Internet. It does not have the private 1177 portion of the concatenated address. 1179 A.2.1. T1z Initiates a Session Request towards T4z 1181 T1z sends an EzIP packet to RG1. There is no TCP port number word, 1182 because T4z does not have such and that for T1z has not been assigned 1183 by the RG1's NAT. 1185 0 1 2 3 1186 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 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 1 |Version|IHL (8)|Type of Service| Total Length (32) | 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 2 | Identification |Flags| Fragment Offset | 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 3 | Time to Live | Protocol | Header Checksum | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 4 | Source Host Number (192.168.1.9) | 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 5 | Destination Host Number (69.41.190.148) | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 | EzIP ID | EzIP | Extended | Extended | 1199 6 | (Source) | Option Length | Source | Source | 1200 | (0X9A) | (6) | No.-1 (240) | No.-2 (0) | 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 | Extended | Extended | EzIP ID | EzIP | 1203 7 | Source | Source | (Destination) | Option Length | 1204 | No.-3 (0) | No.-4 (0) | (0X9B) | (6) | 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 | Extended | Extended | Extended | Extended | 1207 8 | Destination | Destination | Destination | Destination | 1208 | No.-1 (246) | No.-2 (1) | No.-3 (6) | No.-4 (40) | 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1211 Figure 14 EzIP Header: From T1z to RG1 1213 Note that 0X9A and 0X9B are temporarily selected from the available 1214 "IP Option Numbers" [10]. 1216 A.2.2. RG1 Forwards the Packet to SPR1 1218 In Figure 15, RG1, allowing to be masqueraded by T1z, relays the 1219 packet toward SPR1 by assigning the TCP Source port number, 9N, to 1220 T1z. Since T4z is directly connected to the Internet, there is no 1221 private network information to fill the Destination portion of the 1222 TCP word. 1224 0 1 2 3 1225 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 1226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1227 1 |Version|IHL (8)|Type of Service| Total Length (36) | 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 2 | Identification |Flags| Fragment Offset | 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1231 3 | Time to Live | Protocol | Header Checksum | 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 4 | Source Host Number (240.0.0.0) | 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 5 | Destination Host Number (69.41.190.148) | 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1237 | EzIP ID | EzIP | Extended | Extended | 1238 6 | (Source) | Option Length | Source | Source | 1239 | (0X9A) | (6) | No.-1 (240) | No.-2 (0) | 1240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1241 | Extended | Extended | EzIP ID | EzIP | 1242 7 | Source | Source | (Destination) | Option Length | 1243 | No.-3 (0) | No.-4 (0) | (0X9B) | (6) | 1244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1245 | Extended | Extended | Extended | Extended | 1246 8 | Destination | Destination | Destination | Destination | 1247 | No.-1 (246) | No.-2 (1) | No.-3 (6) | No.-4 (40) | 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 9 | Source Port (9N) | Destination Port (All 1's) | 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 Figure 15 TCP/EzIP Header: From RG1 to SPR1 1254 A.2.3. SPR1 Sends the Packet to SPR4 through the Internet 1256 In Figure 166, SPR1 sends the packet out into the Internet towards 1257 SPR4. The packet traverses through the Internet (ER1, CR and ER4), 1258 utilizing only the basic IP header portion of address information. 1260 0 1 2 3 1261 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 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 1 |Version|IHL (8)|Type of Service| Total Length (36) | 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 2 | Identification |Flags| Fragment Offset | 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 3 | Time to Live | Protocol | Header Checksum | 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 4 | Source Host Number (69.41.190.110) | 1270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1271 5 | Destination Host Number (69.41.190.148) | 1272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 | EzIP ID | EzIP | Extended | Extended | 1274 6 | (Source) | Option Length | Source | Source | 1275 | (0X9A) | (6) | No.-1 (240) | No.-2 (0) | 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 | Extended | Extended | EzIP ID | EzIP | 1278 7 | Source | Source | (Destination) | Option Length | 1279 | No.-3 (0) | No.-4 (0) | (0X9B) | (6) | 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 | Extended | Extended | Extended | Extended | 1282 8 | Destination | Destination | Destination | Destination | 1283 | No.-1 (246) | No.-2 (1) | No.-3 (6) | No.-4 (40) | 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 9 | Source Port (9N) | Destination Port (All 1's) | 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1288 Figure 16 TCP/EzIP Header: From SPR1 to SPR4 1290 A.2.4. SPR4 Sends the Packet to T4z 1292 In Figure 17, SPR4 sends the packet to T4z by reconstructing its 1293 address from the Option number and the Extended Destination No. 1295 0 1 2 3 1296 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 1297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1298 1 |Version|IHL (8)|Type of Service| Total Length (36) | 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1300 2 | Identification |Flags| Fragment Offset | 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1302 3 | Time to Live | Protocol | Header Checksum | 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 4 | Source Host Number (69.41.190.110) | 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 5 | Destination Host Number (246.1.6.40) | 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 | EzIP ID | EzIP | Extended | Extended | 1309 6 | (Source) | Option Length | Source | Source | 1310 | (0X9A) | (6) | No.-1 (240) | No.-2 (0) | 1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 | Extended | Extended | EzIP ID | EzIP | 1313 7 | Source | Source | (Destination) | Option Length | 1314 | No.-3 (0) | No.-4 (0) | (0X9B) | (6) | 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 | Extended | Extended | Extended | Extended | 1317 8 | Destination | Destination | Destination | Destination | 1318 | No.-1 (246) | No.-2 (1) | No.-3 (6) | No.-4 (40) | 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 9 | Source Port (9N) | Destination Port (All 1's) | 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1323 Figure 17 TCP/EzIP Header: From SPR4 to T4z 1325 A.2.5. T4z Replies to SPR4 1327 In Figure 18, T4z replies to SPR4 with the full T1z identification 1328 69.41.190.110-240.0.0.0:9N to create an EzIP header for the reply 1329 packet. 1331 0 1 2 3 1332 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 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 1 |Version|IHL (8)|Type of Service| Total Length (36) | 1335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 2 | Identification |Flags| Fragment Offset | 1337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 3 | Time to Live | Protocol | Header Checksum | 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 4 | Source Host Number (246.1.6.40) | 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 5 | Destination Host Number (69.41.190.110) | 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 | EzIP ID | EzIP | Extended | Extended | 1345 6 | (Source) | Option Length | Source | Source | 1346 | (0X9A) | (6) | No.-1 (246) | No.-2 (1) | 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 | Extended | Extended | EzIP ID | EzIP | 1349 7 | Source | Source | (Destination) | Option Length | 1350 | No.-3 (6) | No.-4 (40) | (0X9B) | (6) | 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1352 | Extended | Extended | Extended | Extended | 1353 8 | Destination | Destination | Destination | Destination | 1354 | No.-1 (240) | No.-2 (0) | No.-3 (0) | No.-4 (0) | 1355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1356 9 | Source Port (All 1's) | Destination Port (9N) | 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 Figure 18 TCP/EzIP Header: From T4z to SPR4 1361 A.2.6. SPR4 Sends the Packet to SPR1 through the Internet 1363 In Figure 19, SPR4 sends the packet toward SPR1 with the following 1364 header through the Internet (ER2, CR, and ER1) who will simply relay 1365 the packet according to the information in word 5 (Destination Host 1366 Number): 1368 0 1 2 3 1369 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 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 1 |Version|IHL (8)|Type of Service| Total Length (36) | 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 2 | Identification |Flags| Fragment Offset | 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 3 | Time to Live | Protocol | Header Checksum | 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 4 | Source Host Number (69.41.190.148) | 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 5 | Destination Host Number (69.41.190.110) | 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 | EzIP ID | EzIP | Extended | Extended | 1382 6 | (Source) | Option Length | Source | Source | 1383 | (0X9A) | (6) | No.-1 (246) | No.-2 (1) | 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1385 | Extended | Extended | EzIP ID | EzIP | 1386 7 | Source | Source | (Destination) | Option Length | 1387 | No.-3 (6) | No.-4 (40) | (0X9B) | (6) | 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 | Extended | Extended | Extended | Extended | 1390 8 | Destination | Destination | Destination | Destination | 1391 | No.-1 (240) | No.-2 (0) | No.-3 (0) | No.-4 (0) | 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 9 | Source Port (All 1's) | Destination Port (9N) | 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 Figure 19 TCP/EzIP Header: From SPR4 to SPR1 1398 A.2.7. SPR1 Sends the Packet to RG1 1400 In Figure 20, RG1 address is reconstructed from the Option number and 1401 the Extended Destination No. 1403 0 1 2 3 1404 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 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1406 1 |Version|IHL (8)|Type of Service| Total Length (36) | 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 2 | Identification |Flags| Fragment Offset | 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1410 3 | Time to Live | Protocol | Header Checksum | 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 4 | Source Host Number (69.41.190.148) | 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 5 | Destination Host Number (240.0.0.0) | 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 | EzIP ID | EzIP | Extended | Extended | 1417 6 | (Source) | Option Length | Source | Source | 1418 | (0X9A) | (6) | No.-1 (246) | No.-2 (1) | 1419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 | Extended | Extended | EzIP ID | EzIP | 1421 7 | Source | Source | (Destination) | Option Length | 1422 | No.-3 (6) | No.-4 (40) | (0X9B) | (6) | 1423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1424 | Extended | Extended | Extended | Extended | 1425 8 | Destination | Destination | Destination | Destination | 1426 | No.-1 (240) | No.-2 (0) | No.-3 (0) | No.-4 (0) | 1427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1428 9 | Source Port (All 1's) | Destination Port (9N) | 1429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 Figure 20 TCP/EzIP Header: From SPR1 to RG1 1433 A.2.8. RG1 Forwards the Packet to T1z 1435 In Figure 21, T1z address is reconstructed from RG1's NAT state-table 1436 based on Destination Port (9N). 1438 0 1 2 3 1439 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1441 1 |Version|IHL (8)|Type of Service| Total Length (36) | 1442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 2 | Identification |Flags| Fragment Offset | 1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1445 3 | Time to Live | Protocol | Header Checksum | 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 4 | Source Host Number (69.41.190.148) | 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 5 | Destination Host Number (192.168.1.9) | 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 | EzIP ID | EzIP | Extended | Extended | 1452 6 | (Source) | Option Length | Source | Source | 1453 | (0X9A) | (6) | No.-1 (246) | No.-2 (1) | 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 | Extended | Extended | EzIP ID | EzIP | 1456 7 | Source | Source | (Destination) | Option Length | 1457 | No.-3 (6) | No.-4 (40) | (0X9B) | (6) | 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 | Extended | Extended | Extended | Extended | 1460 8 | Destination | Destination | Destination | Destination | 1461 | No.-1 (240) | No.-2 (0) | No.-3 (0) | No.-4 (0) | 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 9 | Source Port (All 1's) | Destination Port (9N) | 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1466 Figure 21 TCP/EzIP Header: From RG1 to T1z 1468 A.2.9. T1z Sends a Follow-up Packet to RG1 1470 In Figure 22, T1z sends a follow-up packet to RG1 with all fields 1471 filled with needed information. 1473 0 1 2 3 1474 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 1475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1476 1 |Version|IHL (8)|Type of Service| Total Length (36) | 1477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1478 2 | Identification |Flags| Fragment Offset | 1479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1480 3 | Time to Live | Protocol | Header Checksum | 1481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1482 4 | Source Host Number (192.168.1.9) | 1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1484 5 | Destination Host Number (69.41.190.148) | 1485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1486 | EzIP ID | EzIP | Extended | Extended | 1487 6 | (Source) | Option Length | Source | Source | 1488 | (0X9A) | (6) | No.-1 (240) | No.-2 (0) | 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1490 | Extended | Extended | EzIP ID | EzIP | 1491 7 | Source | Source | (Destination) | Option Length | 1492 | No.-3 (0) | No.-4 (0) | (0X9B) | (6) | 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 | Extended | Extended | Extended | Extended | 1495 8 | Destination | Destination | Destination | Destination | 1496 | No.-1 (246) | No.-2 (1) | No.-3 (6) | No.-4 (40) | 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 9 | Source Port (9N) | Destination Port (All 1's) | 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1501 Figure 22 TCP/EzIP Header: Follow-up Packets from T1z to RG1 1503 Figure 23 1505 A.3. Connection Between EzIP-unaware and EzIP-capable IoTs 1507 A.3.1. T1a Initiates a Request to T4z 1509 Since T1a can create only conventional format IP header, the SPRs 1510 will provide CGN type of services to the IP packets. And, assuming 1511 SPR4 has a state-table set up by DMZ for forwarding the request to 1512 T4z, the packet will be delivered to T4z. Seeing the incoming packet 1513 with conventional IP header, T4z should respond with the same so that 1514 the session will be conducted with conventional TCP/IP headers. The 1515 interaction will follow the same behavior as in Appedix A.1. 1517 A.3.2. T1z Initiates a Request to T4a 1519 Knowing T4a is not capable of EzIP header, T1z purposely initiates 1520 the request packet using conventional IP header. It will be treated 1521 by SPRs in the same manner as the T1a initiated case above and the 1522 packet will be recognizable by T4a. 1524 In brief, the steps outlined above are very much the same as the 1525 conventional TCP/IP header transitions between routers with CGN 1526 service. Except, when the IP header carries EzIP data as payload, the 1527 CGN function is enhanced to SPR process. 1529 Note that when an IoT, such as T4a or T4z, is directly connected to a 1530 SPR, like SPR4, there is no RG in-between. There is no corresponding 1531 TCP port number in word 9 of the above TCP/EzIP headers. This spare 1532 facility in the header allows an RG be inserted, thus incorporating 1533 the private network environment like that on Premises 1, if desired. 1535 Appendix B Internet Transition Considerations 1537 To enhance a large communication system like the Internet, it is 1538 important to minimize the disturbance to the existing equipments and 1539 processes due to any needed modification. The basic EzIP plan is to 1540 confine all actionable enhancements within the new SPR module. The 1541 following outlines the considerations for supporting the transition 1542 from the current Internet to the one enhanced by the EzIP technique. 1544 B.1. EzIP Implementation 1546 B.1.1. Introductory Phase: 1548 A. Insert an SPR in front of a web-server that desires to have 1549 additional subnet addresses for offering diversified activities. For 1550 the long term, a new web server may be designed with these two 1551 functional modules combined. 1553 . The first address of a private network address pool, e.g., 1554 242.0.0.0, used by the SPR should be reserved as a DMZ channel 1555 directing the initial incoming service requesting packets to the 1556 existing web server. This will maintain the same operation behavior 1557 projected to the general public. 1559 . The additional addresses, up to 242.255.255.255 may be used for 1560 EzIP address extension purposes. Each may be assigned to an 1561 additional web server representing one of the business's new 1562 activities. Each of these new servers will then respond with EzIP 1563 header to messages forwarded from the main server, or be directly 1564 accessible through its EzIP address. 1566 B. Insert an SPR in front of a group of subscribers who are to be 1567 served with the EzIP capability. The basic service provided by this 1568 SPR will be the CGN equivalent function. This will maintain the same 1569 baseline user experience in accessing the Internet currently. 1571 C. Session initiating packets with basic IPv4 header will be routed 1572 by SPRs to a business's existing server at the currently published 1573 IPv4 public address (discoverable through existing DNS). The server 1574 should respond with the basic IPv4 format as well. Essentially, this 1575 maintains the existing interaction between a user and a web server 1576 within an EzIP-unaware environment. 1578 So far, neither the web-server nor any subscriber's IoTs needs to 1579 be enhanced, because the operations remain pretty much the same as 1580 today's common practice utilizing CGN assisted connectivity. See 1581 Appendix A.1. for an example. 1583 D. Upon connected to the main web server, if a customer intentionally 1584 selects one of the new services offered by the primary web-server, 1585 the web-server will ask the customer to confirm the selection. 1587 . If confirmed, implying that the customer is aware of the fact 1588 that his IoT is being served by an SPR, the web server forwards the 1589 request to a branch server for carrying on the communication via an 1590 EzIP address. 1592 . The SPR at the originating side, recognizing the EzIP header 1593 from the web-server, replaces the CGN service with the EzIP routing. 1595 . For all subsequent packets exchanged, the EzIP headers will be 1596 used in both directions. See Appendix A.2. for an example. This will 1597 speed up the transmission throughput performance for the rest of the 1598 session. 1600 B.1.2. New IoT Operation Modes: 1602 A. EzIP-capable IoT will create EzIP header in initiating a session, 1603 to directly reach a specific EzIP-capable web-server, instead of the 1604 lengthy steps of going through the DMZ port followed by manually 1605 making the selection from the main web server. This will speed up the 1606 initial handshake process. See Appendix A.2. for an example. 1608 B. To communicate with an EzIP-unaware IoT, an EzIP-capable IoT 1609 should purposely initiate a session with conventional IP header. This 1610 will signal the SPRs to provide just CGN type of connection service. 1611 See Appendix A.3. for an example. 1613 B.1.3. End-to-End Operation: 1615 Once EzIP-capable IoTs become common for the general public, direct 1616 communication between any pair of such IoTs will be achievable. An 1617 EzIP-capable IoT, knowing the other IoT's full EzIP address, may 1618 initiate a session by creating an EzIP header that directs the SPRs 1619 to provide EzIP services, bypassing the CGN process. See Appendix 1620 A.2. for an example. 1622 B.2. SPR Operation Logic 1624 To support the above scenarios, the SPR should be designed with the 1625 following decision process: 1627 B.2.1. Initiating a Session Request for an IoT or via a RG 1628 If a session request IP packet contains EzIP Option word, it will be 1629 routed forward by SPR accordingly. Otherwise, the SPR provides CGN 1630 service by assigning a TCP port number to the packet and allowing the 1631 packet to masquerade with the SPR's own IP address while an entry to 1632 the state (port-forward / look-up / hash) table is created in 1633 anticipation of the reply packet. 1635 B.2.2. Receiving a Session Request from the ER 1637 If a received IP packet includes a valid EzIP Option word or port 1638 number, SPR will utilize it to route the packet to an RG or an IoT. 1639 For a packet with plain IP header, it will be routed according to the 1640 Destination Host Number (IP header word 5). 1642 B.3. RG Enhancement 1644 With IPv4 address pool expanded by the EzIP schemes, there will be 1645 sufficient publicly assignable addresses for IoTs wishing to be 1646 directly accessible from the Internet. The existing private networks 1647 may continue their current behavior of blocking session request 1648 packets from the Internet. In-between, another connection mode is 1649 possible. The following describes such an Option in the context of 1650 the existing RG operation conventions. 1652 B.3.1. Initiating Session request for an IoT 1654 Without regard to whether the IP header is a conventional one or an 1655 EzIP type, a RG allows a packet to masquerade with the RG's own IP 1656 address by assigning a TCP port number to the packet and creating an 1657 entry to the state (port-forward / look-up / hash) table. This is the 1658 same as the current NAT practice. 1660 B.3.2. Receiving a packet from the SPR 1662 The "Destination Port" value in the packet is examined: 1664 A. If it matches with an entry in the RG NAT's state-table, the 1665 packet is forward to the corresponding address. This is the same as 1666 the normal NAT processes in a conventional RG. 1668 B. If it matches with the address of an active IoT on the private 1669 network, the packet is assigned with a TCP port number and then 1670 forwarded to that IoT. 1672 Note that there is certain amount of increased security risk with 1673 this added last step, because a match between a guessed destination 1674 identity and the above two lists could happen by chance. To address 1675 this issue, the following proactive mechanism should be incorporated 1676 in parallel: 1678 If the "Destination Port" number is null or does not match with 1679 either of the above two cases, the packet is dropped and an alarm 1680 state is activated to monitor for possible ill-intended follow-up 1681 attempts. A defensive mechanism should be triggered when the number 1682 of failed attempts has exceeded the preset threshold within a finite 1683 time interval. 1685 In brief, if the IP header of a session requesting packet indicates 1686 that the sender knows the identity of the desired destination IoT on 1687 a private network, the common RG screening process will be bypassed. 1688 This facilitates the direct end-to-end connection, even in the 1689 presence of the NAT. Note that this process is very much the same as 1690 the AA (Automated Attendant) capability in a PABX telephone switching 1691 system that automatically makes the connection for a caller who 1692 indicates (via proper secondary dialing or the equivalent) knowing 1693 the extension number of the destination party. Such process has 1694 effectively screened out most of the unwanted callers while serves 1695 the acquaintance expeditiously. 1697 Authors' Addresses 1699 Abraham Y. Chen 1700 Avinta Communications, Inc. 1701 142 N. Milpitas Blvd., #148, Milpitas, CA 95035-4401 US 1703 Phone: _+1(408)942-1485 1704 Email: AYChen@Avinta.com 1706 Abhay Karandikar 1707 Dept. of E.E., India Institute of Technology Bombay 1708 Powai, Mumbai-40007, India 1710 Phone: _(+91-22)2576-7004 1711 Email: Dean.FA@IITB.ac.in 1713 Ramamurthy R. Ati 1714 Avinta Communications, Inc. 1715 142 N. Milpitas Blvd., #148, Milpitas, CA 95035-4401 US 1717 Phone: _+1(408)458-7109 1718 Email: rama_ati@outlook.com