idnits 2.17.1 draft-chen-ati-adaptive-ipv4-address-space-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 14 characters in excess of 72. == There are 14 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 271 has weird spacing: '... the intern...' -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC6598' on line 790 -- Looks like a reference, but probably isn't: 'RFC791' on line 433 -- Looks like a reference, but probably isn't: 'RFC1918' on line 361 -- Looks like a reference, but probably isn't: 'RFC793' on line 392 -- Looks like a reference, but probably isn't: 'RFC2123' on line 395 -- Looks like a reference, but probably isn't: 'RFC1385' on line 475 -- Looks like a reference, but probably isn't: 'RFC862' on line 711 -- Looks like a reference, but probably isn't: 'RFC2928' on line 718 -- 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: 1 error (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 A. Y. Chen 3 Internet Draft R. R. Ati 4 Intended status: Experimental Avinta Communications, Inc. 5 Expires June 2019 A. Karandikar 6 India Institute of Technology 7 David Crowe 8 Cellular Networking Perspectives, Ltd. 10 Adaptive IPv4 Address Space 11 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on June 9, 2019. 36 Copyright Notice 38 Copyright (c) 2018 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. 48 Abstract 49 This document describes a solution to the Internet address depletion 50 issue through the use of an existing Option mechanism that is part of 51 the original IPv4 protocol. This proposal, named EzIP (phonetic for 52 Easy IPv4), outlines the IPv4 public address pool expansion and the 53 Internet system architecture enhancement considerations. 55 EzIP may expand an IPv4 address by a factor of 256M without affecting 56 the existing IPv4 based Internet, or the current private networks. It 57 is in full conformance with the IPv4 protocol, and supports not only 58 both direct and private network connectivity, but also their 59 interoperability. EzIP deployments may coexist with existing Internet 60 traffic and the IoT (Internet of Things) operations without 61 perturbing their setups, while offering end-users the freedom to 62 indepdently choose this system. 64 EzIP may be implemented as a software or firmware enhancement to 65 Internet edge routers or private network routing gateways, wherever 66 needed, or simply installed as an inline adjunct hardware module 67 between the two, enabling a seamless introduction. 69 The 256M case detailed here establishes a complete spherical layer of 70 routers for interfacing between the Internet fabic (core plus edge 71 routers) and the end user premises. Incorporating caching proxy 72 technology in the gateway, a fairly large geographical region may 73 enjoy EzIP as address expansion using as little as one ordinary IPv4 74 public address utilizing IP packets with degenerated EzIP header. 76 If IPv4 public pool allocations were reorganized, the assignable pool 77 could be multiplied by 512M times or even more. 79 EzIP will immediately resolve local IPv4 address shortages, while 80 being transparent to the rest of the Internet. Under the Dual-Stack 81 environment, these proposed interim facilities will relieve the IPv4 82 address shortage issue, while affording IPv6 more time to reach 83 maturity and to provide the availability levels required for 84 delivering a long-term general service. 86 Table of Contents 88 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 89 1.1. Contents of this Draft . . . . . . . . . . . . . . . . . . 5 90 2. EzIP Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 91 2.1. EzIP Numbering Plan . . . . . . . . . . . . . . . . . . . . 6 92 2.2. Analogy with NAT . . . . . . . . . . . . . . . . . . . . . 7 93 2.3. EzIP System Architecture . . . . . . . . . . . . . . . . . 8 94 2.4. IP Header with Option Word . . . . . . . . . . . . . . . . 10 95 2.5. Examples of Option Mechanism . . . . . . . . . . . . . . . 11 96 2.6. EzIP Header . . . . . . . . . . . . . . . . . . . . . . . . 12 97 2.7. EzIP Operation . . . . . . . . . . . . . . . . . . . . . . 13 98 3. EzIP Deployment Strategy . . . . . . . . . . . . . . . . . . . 13 99 4. Updating Servers to Support EzIP . . . . . . . . . . . . . . . 15 100 5. EzIP Enhancement and Application . . . . . . . . . . . . . . . 16 101 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 20 102 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 20 103 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 20 104 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 105 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 106 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 107 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 108 Appendix A EzIP Operation . . . . . . . . . . . . . . . . . . . . 23 109 A.1. Connection between EzIP-unaware IoTs . . . . . . . . . . . 23 110 A.1.1. T1a Initiates a Session Request towards T4a . . . . . . 23 111 A.1.2. RG1 Forwards the Packet to SPR1 . . . . . . . . . . . . 24 112 A.1.3. SPR1 Sends the Packet to SPR4 through the Internet . . 25 113 A.1.4. SPR4 Sends the Packet to T4a . . . . . . . . . . . . . 26 114 A.1.5. T4a Replies to SPR4 . . . . . . . . . . . . . . . . . . 27 115 A.1.6. SPR4 Sends the Packet to SPR1 through the Internet . . 27 116 A.1.7. SPR1 Sends the Packet to RG1 . . . . . . . . . . . . . 28 117 A.1.8. RG1 Forwards the Packet to T1a . . . . . . . . . . . . 28 118 A.1.9. T1a Sends a Follow-up Packet to RG1 . . . . . . . . . . 29 119 A.2. Connection Between EzIP-capable IoTs . . . . . . . . . . . 29 120 A.2.1. T1z Initiates a Session Request towards T4z . . . . . . 30 121 A.2.2. RG1 Forwards the Packet to SPR1 . . . . . . . . . . . . 31 122 A.2.3. SPR1 Sends the Packet to SPR4 through the Internet . . 32 123 A.2.4. SPR4 Sends the Packet to T4z . . . . . . . . . . . . . 33 124 A.2.5. T4z Replies to SPR4 . . . . . . . . . . . . . . . . . . 34 125 A.2.6. SPR4 Sends the Packet to SPR1 through the Internet . . 35 126 A.2.7. SPR1 Sends the Packet to RG1 . . . . . . . . . . . . . 36 127 A.2.8. RG1 Forwards the Packet to T1z . . . . . . . . . . . . 37 128 A.2.9. T1z Sends a Follow-up Packet to RG1 . . . . . . . . . . 38 129 A.3. Connection Between EzIP-unaware and EzIP-capable IoTs . . . 38 130 A.3.1. T1a Initiates a Request to T4z . . . . . . . . . . . . 38 131 A.3.2. T1z Initiates a Request to T4a . . . . . . . . . . . . 39 132 Appendix B Internet Transition Considerations . . . . . . . . . . 40 133 B.1. EzIP Implementation . . . . . . . . . . . . . . . . . . . . 40 134 B.1.2. New IoT Operation Modes: . . . . . . . . . . . . . . . 41 135 B.1.3. End-to-End Operation: . . . . . . . . . . . . . . . . . 41 136 B.2. SPR Operation Logic . . . . . . . . . . . . . . . . . . . . 41 137 B.3. RG Enhancement . . . . . . . . . . . . . . . . . . . . . . 42 138 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 140 1. Introduction 142 For various reasons, there is a large demand for IP addresses. It 143 would be useful to have a unique address for more Internet devices, 144 such that, if desired, any device may call upon any other directly. 145 The Internet of Things (IoT) would also be able to make use of more 146 routable addresses if they were available. Currently, these are not 147 possible with the existing IPv4 configuration. 149 By Year 2020, the world population and number of IoTs are expected to 150 reach 7.6B (Billion) and 50B respectively, according to a 2011 Cisco 151 online white paper [3]. 153 In addition, IP addresses are needed while client devices, such as 154 mobile phones, are attached to the internet, which is an increasing 155 amount of time for a rapidly increasing number of devices. 157 The IPv4 dot-decimal address format, consisting of four octets, each 158 made of 8 binary bits, provides just over 4 billion unique address 159 (4,294,967,296 decimal exact). 161 IPv6, with its 128-bit hexadecimal address format, is four times as 162 long as the IPv4, has 256BBBB (4B x 4B x 4B x 4B) unique addresses. 163 It offers a promising solution to the address shortage. However, its 164 global adoption appears to be facing significant challenges [4], 165 [5]. 167 Interim relief to the IPv4 address shortage has been provided by 168 Network Address and Port Translation (NAPT - commonly known simply as 169 NAT) on private networks together with Carrier Grade NAT (CG-NAT or 170 abbreviated further to CGN) [RFC6598] [6] over the public Internet. 171 However, NAT modules slow down routers due to the state-table look-up 172 process. As well, they only allow an Internet session be initiated by 173 their own clients, impeding the end-to-end setup requests initiated 174 from remote devices that a fully functional communication system 175 should be capable of. Being dynamic, the state-table used by CGN 176 increases CyberSecurity vulnerability. Because port numbers are used 177 to effectively increase the size of the address pool, they introduce 178 complex and sub-optimal port management requirements 180 If IPv4 capacity could be expanded without the size and efficiency 181 limitations of NAT, the urgency will be relaxed long enough for the 182 IPv6 to mature on its own pace. 184 There have been several proposals to increase the effective Internet 185 public address pool in the past. They all introduced new techniques 186 or protocols that ran into certain handicaps or compatibility issues, 187 preventing a smooth transition. 189 EzIP utilizes a long-reserved address block 240/4 [7] that all of the 190 existing Internet Core (/ backbone) Router (CR), Edge Router (ER) and 191 private network Routing (/ Residential) Gateway (RG) as well as hosts 192 such as IoTs are not allowed to utilize. This is combined with the 193 Option mechanism defined in [RFC791] [1] for transporting such 194 information as the IP header payload that is transparent to all of 195 these routers, except a newly defined category named Semi-Public 196 Router (SPR). By inserting an SPR between an ER and a private 197 premises that it serves, each publicly assignable address can be 198 expanded 256M fold. 200 EzIP introduces minimal perturbation by utilizing the current 201 Internet system architecture. Its deployment will start with an SPR 202 providing public NAT functions, in a new way, to unload the burden 203 from the current CGN. With basic routing as an integral part of the 204 SPR, individual IoTs, or other large networks, will be encouraged to 205 migrate toward full EzIP service which provides end-to-end 206 connectivity between private premises. 208 1.1. Contents of this Draft 210 This draft outlines the EzIP numbering plan. An enhanced IP header, 211 called EzIP header, is introduced to carry the EzIP address as 212 payload using the Option word. How the Internet architecture will 213 change as the result of being extended by the EzIP scheme is 214 explained. How the EzIP header flows through various routers, and 215 Internet update considerations are described, with details presented 216 in Appendices A and B, respectively. Utilizing the EzIP approach, a 217 several ways to expand the publicly assignable IPv4 address pool, as 218 well as enhance Internet operations are then discussed. 220 2. EzIP Overview 222 2.1. EzIP Numbering Plan 224 EzIP uses the reserved private network address pools in very much the 225 same way that Private Automatic Branch eXchange (PABX) switches 226 utilize locally assigned "extension numbers" to expand the Public 227 Switched Telephone Network (PSTN) capacity, by replicating a public 228 telephone line to multitudes of reusable private telephone numbers, 229 each to identify a local instrument. 231 PABX extension numbers belong to a reusable private set. For example, 232 extension 123 or 1234 may exist in thousands of different PABX 233 switches without ambiguity. Similarly, the IPv4 private network 234 address may also be re-used in many networks without ambiguity. 236 The key EzIP concept is the partitioning of a finite public address 237 pool to put aside a block of special (called "Semi-Public" in the 238 presentation below) addresses that extends each remaining public 239 address to multitudes of sub-addresses, resulting in an effectively 240 much larger assignable public address resource. 242 In fact, the initial EzIP analysis identified the untold two-stage 243 subnetting process of 192.168/16 that has been practiced routinely 244 for a long time. End-users are commonly accustomed to an RG choosing 245 one out of 256 values from the fourth octet of the 192.18.K/24 block 246 for identifying an IoT on a private premises. They mostly are, 247 however, unaware of the preceeding stage of selecting the value "K" 248 from the third octet of the 192.18/16 block, as the factory default 249 RG identification assigned by a manufacturer, is implicitly capable 250 of expanding it by 256 fold for supporting a corresponding number of 251 private premises. 253 A key EzIP concept is to use the elusive IPv4 240/4 block (240/8 - 254 255/8), that has been "RESERVED" for "Future use" since 1981-09. As 255 the result of the historical address assignment evolution, it was 256 proposed to redesignate it for "Private Use" near a decade ago [2]. 257 However, as pointed out by its own authors in Section 2, Caveats of 258 Use, "Many implementations of the TCP/IP protocol stack have the 259 240.0.0.0/4 address block marked as experimental, and prevent the 260 host from forwarding IP packets with addresses drawn from this 261 address block." That proposal did not get advanced. Therefore, 240/4 262 remain reserved for future use. 264 Substituting the function of the third octet of 192.168.K/24 with 265 addresses from the 240/4 block in the first stage RG and redefining 266 it as a new category of router, called SPR, the EzIP scheme 267 circumvents the earlier hurdles to achieve the address multiplication 268 factor of 256M without involving any existing router. This is because 269 the 240/4 addresses are only used within the RG SPR and within the 270 OPTION header extension, they are not used as IPv4 addresses within 271 the internet. These addresses are equivalent to PABX extension 272 numbers, with the additional advantage that IPv4 OPTION header 273 extensions can carry them through the network. 275 Since the 240/4 block cannot be used by existing routers, the size of 276 the assignable IPv4 public pool has actually been only 3.84B (4.096B 277 - 256M). So, the overall assignable pool resulted from the EzIP 278 approach is about 983MB (3.84B x 256M), which is over 19M times of 279 the expected Year 2020 IoTs. This size certainly has the potential to 280 support the short- to mid-term public IP address needs. 282 2.2. Analogy with NAT 284 EzIP also has similarities to NAT, but some important differences. 286 NAT works by temporarily assigning a port number to outgoing 287 communications from a private address, while converting the private 288 address into a public IPv4 address for external communications. When 289 responses to messages are received, the public IPv4 address plus port 290 number is converted back into the private IPv4 address. 292 There are a number of limitations of NAT that are not present with 293 EzIP. (1) There are only 65,536 port numbers but 256M 240/4 EzIP 294 addresses; (2) Due to the limited number of ports, assignments are 295 only temporary and will be reclaimed after a period of inactivity but 296 there are so many EzIP addresses that assignments can be made for a 297 much longer period of time (days or months rather than seconds or 298 minutes); (3) Port numbers are used for other purposes than NAT, 299 further reducing the pool, but EzIP uses 240/4 addresses for only one 300 purpose; (4) Due to the limited time during which a port number is 301 assigned, the NAT port numbers cannot be used for incoming 302 communications, but with EzIP the address assignments will be long 303 term and could be used for direct communications from EzIP-aware 304 devices. 306 2.3. EzIP System Architecture 307 +------+ 308 Web Server | WS0z | 309 +--+---+ 310 |69.41.190.145 311 | 312 | +-----+ 313 +--+ ER0 | 314 +--+--+ 315 | 316 +------+-------+ 317 +-------+ Core Routers +--------+ 318 | | (CR/Internet)| | 319 +--+--+ +--------------+ +--+--+ 320 +-----+ ER1 | +-----+ ER4 | 321 | +-----+ | +-----+ 322 | | 323 |69.41.190.110 |69.41.190.148 324 240.0.0.0 +--+--+ +--+--+ 325 +-----------+ +-------+ +---------+ +------+ 326 | +-----+ SPR1| | | +-----+ SPR4+--+ | 327 | | +-----+ | |...| +-----+ |...| 328 | 240.0.0.1 ... 255.255.255.255 | | +---------+ | 329 +-----+ | | | | 330 Public | 240.0.0.0 | | 255.255.255.255 331 Demarc. ----+-------------------------------+----+------------------- 332 Private |Premises 1 +----------+ | 333 +--+--+ | Premises 4 | 334 +---+ RG1 +--+ | | 335 | +-----+ | | | 336 | | | | 337 |192.168.1.3 |192.168.1.9 |240.0.0.10 |246.1.6.40 338 +--+--+ +--+--+ +--+--+ +--+--+ 339 | T1a | .... | T1z | | T4a | ....... | T4z | 340 +-----+ +-----+ +-----+ +-----+ 342 Figure 1 EzIP System Architecture 344 The new category of router, SPR is to be positioned inline between an 345 ER and the customer premises that it serves. After the original path 346 is re-established, the remaining addresses in the 240/4 block will be 347 used by the SPR to serve additional premises. Figure 1 shows a 348 general view of the enhanced Internet system architecture with two 349 SPRs, SPR1 and SPR4, deployed. Note that the "69.41.190.x" are static 350 addresses. In particular, the "69.41.190.145" is the permanent public 351 Internet address assigned to Avinta.com. 353 2.2.1. Referring to the left-hand portion labeled "Premises 1" of 354 Figure 1, instead of assigning each premises a public IPv4 address as 355 in the current practice, an SPR like SPR1, is inserted between an ER 356 (ER1) and its connections to private network Routing Gateways like 357 RG1, for utilizing 240.0.0.0 through 255.255.255.255 of the 240/4 358 block to identify respective premises. The RG1, serving either a 359 business LAN (Local Area Network) or a residential HAN (Home Area 360 Network), uses addresses from one of the three private network 361 [RFC1918] [8] blocks, 10/8, 172.16/12 and 192.168/16, such as 362 192.168.1.3 and 192.168.1.9 to identify the IoTs, T1a and T1z, 363 respectively. 365 2.2.2. Part of the right-hand portion of Figure 1 is labeled 366 "Premises 4". Here SPR4 directly assigns addresses 240.0.0.10 and 367 246.1.6.40 from the 240/4 block to T4a and T4z, respectively. 368 Consequently, these IoTs are accessible through SPR4 from any other 369 IoT in the Internet. 371 2.2.3. Since the existing physical connections to subscriber's 372 premises terminate at the ER, it would be natural to have SPRs 373 collocated with their ER for streamlining the interconnections. It 374 follows that the simple routing function provided by the new SPR 375 modules may be absorbed into the ER through a straightforward 376 operational firmware enhancement. Consequently, the public / private 377 demarcation line (Demarc.) will remain at the RG where currently all 378 utility services enter a subscriber's premises. 380 2.2.4. To fully tag each of these devices, we may use a concatenated 381 three-part address notation: "Public - Semi-Public: TCP Port". The 382 following is how each of the IoTs in Figure 1 may be uniquely 383 identified in the Internet. 384 RG1: 69.41.190.110-240.0.0.0 385 T1a: 69.41.190.110-240.0.0.0:3 386 T1z: 69.41.190.110-240.0.0.0:9 387 T4a: 69.41.190.148-240.0.0.10 388 T4z: 69.41.190.148-246.1.6.40 390 Note that to simplify the presentation, it is assumed at this 391 juncture that the conventional TCP (Transmission Control Protocol) 392 [RFC793] [9] Port Number, normally assigned to T1a and T1z by RG1's 393 NAT module upon initiating a session, equals to the fourth octet of 394 that IoT's private IP address that is assigned by the RG1's DHCP 395 (Dynamic Host Configuration Protocol) [RFC2123] [10] subsystem as 396 ":3" and ":9", respectively. Such numbers are unique within each 397 respective /24 private network such as the 192.168.1/24 here. They 398 are adequate for the discussion purpose in this document. However, 399 considering security, as well as allowing each IoT to have multiple 400 simultaneous sessions, etc., this direct and singular correlation 401 shall be avoided in actual practice by following the NAT operation 402 conventions as depicted by the examples in Appendix A. 404 Figure 2 groups IoTs, routers and servers into two separate columns, 405 EzIP-unaware or EzIP-capable, to facilitate discussions that are to 406 follow. 407 +--------------------------+-----------------+----------------+ 408 | | EzIP-unaware | EzIP-capable | 409 +--------------------------+-----------------+----------------+ 410 | Internet Core Router (CR)| CR | ------------ | 411 +--------------------------+-----------------+----------------+ 412 | Internet Edge Router (ER)| ER0, ER1, ER4 | ------------ | 413 +--------------------------+-----------------+----------------+ 414 | Internet of Things (IoT) | T1a, T4a | T1z, T4z | 415 +--------------------------+-----------------+----------------+ 416 | Routing Gateway (RG) | RG1 | ------------ | 417 +--------------------------+-----------------+----------------+ 418 | Semi-Public Router (SPR) | ------------- | SPR1, SPR4 | 419 +--------------------------+-----------------+----------------+ 420 | Web Server (WS) | ------------- | WS0z | 421 +--------------------------+-----------------+----------------+ 423 Figure 2 EzIP System Components 425 2.4. IP Header with Option Word 427 To transport the EzIP Extension Addresses through existing devices 428 without being recognized as such and consequently acted upon, the IP 429 Header Option mechanism defined by Figure 9 of [RFC791] is utilized 430 to carry the addresses as payload. One specific aspect of its format 431 deserves some attention. The meanings of the leading eight bits of 432 each Option word, called "Opt. Code" or "Option-type octet", are 433 summarized on Page 15 of [RFC791]. They are somewhat confusing 434 because the multiple names used in the literature, and how the octet 435 is parsed into functional bit groups. For example, a two digit 436 hexadecimal number, "0x9A", is conventionaly written in the binary 437 bit string form as "1001 1010". As Opt. Code, however, the eight bits 438 are parsed into three groups of 1, 2 and 5 bits "1 00 11010" with 439 meanings described in Figure 3. 441 +--------------------------------------------------------------+ 442 | Meaning of EzIP ID = 0x9A (Example) | 443 +--------------+------------------+----------------------------+ 444 | Copy Bit | Class | Option Value / Number | 445 +--------------+------------------+----------------------------+ 446 | 1 (Set) | 00 (Control) | 11010 (26 - base 10) | 447 +--------------+------------------+----------------------------+ 449 Figure 3 Option Type Octet 451 A value of "1" for the first bit instructs all routers that this 452 Option word is to be copied upon packet fragmentation. This preserves 453 the Option word through such a process, if it is performed. 455 The value of "00" for the next two bits indicates that this Option 456 word is for "Control" purpose. 458 The decimal "Option Value" of the last five bits, equaling to "26" is 459 defined as the "Option Number" that is listed in the "Number" column 460 of the Internet Protocol Version 4 (IPv4) Parameters list [11]. As 461 can be seen there, "26" has not been assigned. Thus, it is 462 temporarily used in this document to facilitate the EzIP 463 presentation. The next unassigned Option Code, "0x9B" or Number "27" 464 will also be tentatively utilized in this document. 466 2.5. Examples of Option Mechanism 468 The Option mechanism has been used for various cases. Since they were 469 mostly for utility or experimental purposes, however, their formats 470 may be remote from the incident topic. There were two cases 471 specifically dealt with the address pool issues. They are referenced 472 here to assist the appreciation of the Option mechanism. 474 A. EIP (Extended Internet Protocol) 475 Figure 1 of [RFC1385] [12] (Assigned but now deprecated Option 476 Number = 17) by Z. Wang: This approach proposed to add a new 477 network layer on top of the existing Internet for increasing the 478 addressable space. Although equipment near the end-user would stay 479 unchanged, those among the CRs apparently had to go through rather 480 extensive upgrading procedures, perhaps due to the flexible length 481 of the extended address (could be much longer than that of the 482 IPv6). 484 B. EnIP (Enhanced IPv4) 485 Figure 1 of Internet Draft [13] (temporarily utilizing Option 486 Number = 26) by W. Chimiak: This work made use of the three 487 existing private network blocks to extend the public pool by 488 trading the private network operation for end-to-end connectivity. 490 The fully deployed EnIP will eliminate the current private 491 networks which may be against the preference of end-users who have 492 found the private network configuration quite desirable. For 493 example, the NAT in an RG serves as a rudimentary deterrent 494 against intrusion. In addition, the coexistence of private RG-NAT 495 and public EnIP router functions in the same EnIP devices (N1 & 496 N2), could lead to certain logistic inconsistency concerns. 498 2.6. EzIP Header 499 0 1 2 3 500 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 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 1 |Version|IHL (8)|Type of Service| Total Length (32) | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 2 | Identification |Flags| Fragment Offset | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 3 | Time to Live | Protocol | Header Checksum | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 4 | Source Host Number | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 5 | Destination Host Number | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | EzIP ID | EzIP | Extended | Extended | 513 6 | (Source) | Option Length | Source | Source | 514 | (0X9A) | (6) | No.-1 | No.-2 | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Extended | Extended | EzIP ID | EzIP | 517 7 | Source | Source | (Destination) | Option Length | 518 | No.-3 | No.-4 | (0X9B) | (6) | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Extended | Extended | Extended | Extended | 521 8 | Destination | Destination | Destination | Destination | 522 | No.-1 | No.-2 | No.-3 | No.-4 | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 Figure 4 Full EzIP Header (Four octet) 527 The proposed EzIP header format shown in Figure 4 can transport the 528 full 4 octet (32 bit) extension addresses of both ends of an Internet 529 link. The extension address in the 240/4 block utilized in the EzIP 530 scheme described herein has 28 significant bits. It is possible for 531 EzIP to use addresses having other lengths of significant bits for 532 different multiplication factors. To prepare for such variations, two 533 separate EzIP ID codes, "0x9A" and "0x9B" are proposed to distinguish 534 between Source and Destination Option words, respectively. 536 2.7. EzIP Operation 538 To convey the general scheme, Appendix A presents examples of IP 539 header transitions through routers, between IoTs with or without EzIP 540 capability. 542 To introduce the EzIP approach into an environment where EzIP-unaware 543 IoTs like T1a and T4a will be numerous for a long time to come, an 544 SPR must be able to follow certain decision branches to determine how 545 to provide the appropriate routing service for a smooth transition to 546 the long term operation. Appendix B outlines such logic and related 547 considerations. 549 3. EzIP Deployment Strategy 551 There are no security considerations relevant to this document. 553 Although the eventual goal of the SPR is to support both web server 554 access by IoTs from behind private networks and direct end-to-end 555 connectivity between IoTs, the former should be dealt with first to 556 immediately mitigate the address shortage induced daily issues. In 557 the process, the latter would be built up naturally. 559 A.Architecturally 561 Since the design philosophy of the SPR is an inline module between an 562 ER and the private premises (RG or directly connected IoTs) that it 563 serves, SPR introduction process can be flexible. 565 A.1. An SPR may be deployed as an inline module right after an ER to 566 begin providing the CGN equivalent function. This could be done 567 immediately without affecting any of the existing Internet 568 components, CR, ER and RG. EzIP-capable IoTs will then take advantage 569 of the faster bi-directional routing service through the SPRs by 570 initiating communication sessions utilizing EzIP headers to contact 571 other EzIP-capable IoTs. 573 A.2. Alternatively, an SPR may be deployed as an adjunct module just 574 before an existing RG or a directly connected IoT to realize the same 575 EzIP functions on the private premises, even if the serving Internet 576 Access Provider (IAP) has not enhanced its ERs with the EzIP 577 capability. 579 This approach will empower individual communities to enjoy the new 580 EzIP capability on their own by upgrading all Internet subscribers 581 within a good sized region to have publicly accessible EzIP addresses 582 for intra-community peer-to-peer communication, starting from just 583 using one existing public IPv4 address to identify the entire region 584 through a gateway to the rest of the world. See sub-section C. below 585 for more specific considerations. 587 B. Functionally 589 B.1. First, an IAP should install SPRs in front of business web 590 servers so that new routing branches may be added to support the 591 additional web servers for expanding business activities. 592 Alternatively, this may be achieved if businesses on their own deploy 593 new web servers with the SPR capability built-in. 595 B.2. On the subscriber side, SPRs should be deployed to disseminate 596 static addresses to the public, and to facilitate the access to new 597 web servers. 599 C. Regional Deployment 601 C.1. Since the size of the 240/4 block is significant, a region 602 mentioned in sub-section A.2. above could actually be fairly large. 603 Based on the assumption that each person, on the average, may have 604 6.6 IoTs by Year 2020 [3], a 240/4 block is capable of serving nearly 605 39M (256M / 6.6) people. This exceeds the population of the largest 606 city on earth (33M - Tokyo Metro.) and 75% of the countries around 607 the world (most of the 233 countries other than the top 35). 608 Therefore, any finite sized region can immediately begin to enjoy 609 EzIP addressing by deploying a "RAN" utilizing SPRs operating with 610 one 240/4 block of addresses under one IPv4 public address. If the 611 gateway for a region is configured in such a way that the entire 612 region appears to be one ordinary IPv4 IoT to the rest of the 613 Internet, a RAN may be deployed anywhere there is the need or desire, 614 with no perturbation to the current Internet operation whatsoever. 616 C.2. This gateway may be constructed with a matured networking 617 technology called Caching Proxy [14], popularized by data-intensive 618 web services such as Google, Amazon, Yahoo, etc. Developed for 619 speeding up response to repetitive queries on the same topic, while 620 minimizing Internet traffic for data exchanges with the central data 621 bank, caching proxies are placed at strategic locations close to 622 potential inquirers, essentially cloning the central data bank into 623 distributed copies (not necessarily a full set, but relevant 624 subsets). This architecture meshs with the EzIP-based RAN very well, 625 because the address translation between the IPv4 in the Internet and 626 the EzIP in the RAN can be accomplished transparently through the two 627 ports of a caching proxy (For such matter, even could be between the 628 IPv6 and the EzIP if desired!). Consequently, existing Internet 629 routers, such as CR and ER may not see any IP packet with EzIP header 630 at all, during the initial phase of the RAN deployment which will 631 primarily consist of basic web server access, and intra-regional 632 messaging. 634 C.3. This configuration actually mimicks the PABX environment almost 635 exactly. Since the entire region is only accessible through the 636 gateway that performs the address translation, degenerated EzIP 637 header (conventional IP header with words 4 and 5 using addresses 638 from the 240/4 block) will be suffice for intra RAN traffic. This 639 mirrors the dialing procedure using only extension numbers among 640 stations served by the same PABX, circumventing the unnecessary and 641 wasteful overhead of including the dialing of the common public 642 telephone number prefix that identifies the PABX to the PSTN. 644 C.4. The full EzIP header format will only be used when an EzIP- 645 capable IoT intends to directly interact with an EzIP-capable IoT in 646 another RAN. The last part is equivalent to the DID (Direct Inward 647 Dialing) conventions that have been used in the PABX field for many 648 years. 650 C.5. The above would streamline the CIR (Country-based Internet 651 Registry) model proposed by ITU-T [18]. Instead of allocating a block 652 of public IPv6 addresses to an ITU-T authorized entity (essentially 653 the sixth RIR - Regional Internet Registry) to administrate on behalf 654 of individual countries, the EzIP RAN configuration enables each 655 member state to start her own CIR with up to 256M IoTs, based on just 656 one of the IPv4 public address already allocated to that country from 657 the responsible RIR. Consequently, each CIR is coordinated by its 658 parent RIR, yet its operation conforms to local preferences. This 659 scheme estqablishes a second Internet service parallel to the 660 existing one for demonstrating their respective merits independently, 661 offering subscribers true options to choose from. 663 D. Permanently 665 In the long run, it would be best if SPRs are integrated into their 666 host ER by upgrading the latter's firmware to minimize the hardware 667 and to streamline the equipment interconnections. 669 Appendix B details the considerations in implementing these outlines. 671 4. Updating Servers to Support EzIP 673 Although the IP header Option mechanism utilized by EzIP was defined 674 a long time ago as part of the original IPv4 protocol RFC 791 [1], it 675 has not been used much in daily traffic. Compatibility with current 676 Internet facilities and conventions may need be reviewed. Since the 677 EzIP data is transported as part of the IP header payload, it is not 678 expected to affect higher layer protocols. However, certain 679 facilities may have been optimized without considering the Option 680 mechanism. They need be adjusted to provide the same performance to 681 EzIP packets. There are also utility type of servers that need be 682 updated to support the longer EzIP address. For example; 684 A. Fast Path 686 Internet Core Routers (CRs) are currently optimized to only provide 687 the "fast-path" (through hardware line card) routing service to 688 packets without Option word in the IP header [15]. This puts EzIP 689 packets at a disadvantage position, because EzIP packets will have to 690 go through the "slow path" (processed by CPU's software before giving 691 to the correct hardware line card to forward), resulting in a slower 692 throughput. Since the immediate goal of the EzIP is to ease the 693 address pool exhaustion affecting web server access, subscribers not 694 demanding for high throughput performance may be migrated to the EzIP 695 supported facility first. This gives CRs the time to update so that 696 EzIP packets with authorized Option numbers will eventually be 697 recognized for receiving the "fast-path" service. On the other hand, 698 an alternative logic may be applied for the CR. That is, it should by 699 default ignore any Option word in an IP header so that all IP packets 700 will be processed through the "fast-path", unless a recognizable 701 Option word requiring action is detected. This approach would 702 mitigate the security issues caused by the "source routing" attack, 703 as well. 705 B. Connectivity Verification 707 One frequently used probing utility for verifying baseline 708 connectivity, commonly referred to as the "PING" function in PC 709 terminology, needs be able to transport the full EzIP address that is 710 64 bits long instead of the current 32 bit IPv4 address. There is an 711 example of an upgraded TCP echo server in [RFC862] [16]. 713 C. Domain Name Server (DNS) 715 Similarly, the DNS needs to expand its data format to transport the 716 longer IP address created by the EzIP. This already can be done under 717 IPv6. Utilizing the experimental IPv6 prefix 2001:0101 defined by 718 [RFC2928] [17], EzIP addresses may be transported as standardized 719 AAAA records. These topics are discussed in more detail under an IETF 720 Draft RFC, Enhanced IPv4 - V.03 [12]. 722 5. EzIP Enhancement and Application 724 To avoid disturbing any assigned addresses, deployed equipment and 725 current operation, etc., the EzIP scheme is derived under the 726 constraint of utilizing only the reserved 240/4 address block. If 727 such restriction were removed by allowing the entire IPv4 address 728 pool be freely re-allocatable, the assignable public address pool 729 could be expanded significantly more, as outlined below. 731 A. If the 240/4 block were doubled to 224/3, each existing IPv4 732 public address would be expanded by 512M fold. Since this block of 733 512M addresses have to be first reserved from the basic public pool, 734 the resultant total addresses will be (4.096B - 512M) x 512M, or 735 1,835MB. This is over 36M times of the predicted number of IoTs (50B) 736 by Year 2020. This calculation leads to additional possibilities. 738 B. The EzIP header in Figure 4, capable of transporting the full 32 739 bit IPv4 address, allows the extension number be as long as 740 practical. That is, we can go to the extreme of reserving only one 741 bit for the network number, and using all of the rest bits for the 742 extension address. With this criterion, the basic IPv4 pool may be 743 divided into two halves, reserving one half of it (about 2B 744 addresses) as a semi-public network with the network number prefix 745 equal to "1". Each of the remaining 2B public addresses (with prefix 746 equal to "0") of the basic IPv4 pool may then be extended 2B fold 747 through the EzIP process, resulting in a 4BB address pool. This is 748 roughly 80M times of the Year 2020 IoT needs. 750 C. If the EzIP technique were applied through several layers of SPRs 751 in succession, the address expansion could be even more. For example, 752 let's divide the IPv4 pool equally into four blocks, each with about 753 1B addresses. Apply the first 1B address block to the public routers. 754 Set up three layers of SPRs, each makes use of one of the remaining 755 three 1B addresses. The resultant assignable pool will have 1BBBB 756 addresses. Under this configuration, the full length of an IoT's 757 identification code will be the concatenation of four segments of 32 758 bit IPv4 address, totalling 128 bits, the same as that of the IPv6. 759 The first two bits of each segment, however, being used to 760 distinguish from the other three address blocks, are not significant 761 bits. This 8-bits difference makes the IPv6 pool 256 times larger. 762 This ratio is immaterial, because even the 1BBBB address pool is 763 alreaby 20MBB times of the foreseeable need. It is the hierarchical 764 addressing characteristics, made possible by the EzIP scheme, that 765 will enhance the Internet, such as truncating out the common address 766 prefix for communicating within a local community, and associating an 767 address with the geographical position, thus mitigating the 768 GeoLocation issues. 770 D. Along this line of reasoning, we could combine two 1B address 771 blocks togther to be the basic public address. The overall assignable 772 pool becomes 2BBB which is still 40MB times of the expected IoT 773 need(50B). With this pool, we can divide the entire globe into 2B 774 regions, each served by one public router. Each region can then be 775 divided into 1B sections, identified by the first group of SPRs. 777 Next, each section will have the second group of SPRs to manage upto 778 1B RGs and IoTs. Since the basic 2B public addresses are already more 779 than half of the current total assignable IPv4 public addresses 780 (3.84B), their potential GeoLocation resolution capabilities are 781 comparable. With additional two layers of SPR routing, 1B for each, 782 the address grid granuality will be so refined that locating the 783 source of an IP packet becomes a finite task, leaving perpetrators 784 little room to hide. 786 E. The following outlines a possible procedure for optimizing the use 787 of the EzIP address resource by transforming the current Internet to 788 be a GeoLocation-capable address system while maintaining the 789 existing IPv4 addressing and operation conventions: 790 a. Quantitative Reference: IETF [RFC6598] [6] reserved the 791 100.64/10 block with 4M addresses for supporting IAP's CGN 792 service. Applying all of these to the entire IPv4 pool of 4B 793 addresses, the maximum effective CGN supported IPv4 address pool 794 could be 16MB. This is 0.32M times of the expected number (50B) of 795 IoTs by Year 2020. 797 b. Employing the 240/4 block with 256M addresses in the EzIP 798 extension scheme, a /6 block with 64M addresses from the IPv4 799 basic public pool is sufficient to replicate the above 16MB 800 capacity. This frees up the majority of the IPv4 public pool. 802 c. Since this will be a temporary holding pool to release the 803 current addresses for new assignments, it should occupy as few 804 public addresses as possible to leave the maximum number of 805 addresses for facilitating the long term planning. To just support 806 the expected 50B IoTs need, only 200 IPv4 public addresses are 807 required (200 x 256M = 50B). Thus, a /24 block with 256 addresses 808 is more than enough to accommodate this entire migration process. 809 This frees up even more IPv4 public addresses. 811 d. Although a single /24 public address block is sufficient for 812 migrating all currently perceived IPv4 address needs into one 813 compact temporary EzIP pool, world-wide coordination of new 814 address assignments and routing table updates will be required. It 815 will be more expeditious by carrying out this preparatory phase on 816 individual country or geographical region basis utilizing public 817 IPv4 addresses already assigned to that area and actively served 818 by existing CR routing tables. Since 200 public addresses are 819 enough to port the entire IoT addresses, most (about 190 out of 820 233, or about 80%) countries should be able to port all of their 821 respective predicted IoTs to be under one 240/4 block, each 822 represented by one gateway to the Internet. If this is managed 823 according to geographical disciplines, each participating region 824 will begin to enjoy the benefits of the EzIP approach, such as 825 plentifull assignable public addresses, robust security due to 826 inherent GeoLocation ability to spot hackers from within. So that 827 efforts may be focused only on screening suspicious packets 828 originated from without. 830 e. As IoTs getting migrated to the temporary pool, the IPv4 831 addresses they originally occupy shall be released to re-populate 832 the public address pool for establishing the full scale EzIP 833 operation. 835 f. Upon the completion of the EzIP based world-wide public address 836 allocation map, each country can simply give up the few temporary 837 public addresses in exchange for the permanent assignments. Since 838 the latter is likely more than the former, addresses in one 240/4 839 block will be served by two (or more) 240/4 blocks. Then, each of 840 such 240/4 block will have more than half of its capacity 841 available to serve the growth of additional IoTs. 843 g. This last step is very much the same as the traditional PSTN 844 "Area Code Split" practice, whereby telephone numbers of a service 845 area are split into two (or more) blocks, upon introducing one (or 846 more) new area code(s) into the area. All subscribers will 847 continue to use their original local telephone numbers for calling 848 among neighbors daily, except some may be assigned with a new area 849 code prefix. Upon the split, each area code will have more than 850 half of its assignable telephone numbers availabe to support the 851 future subscriber growth within its service area. Mimicking the 852 PSTN, the EzIP based Internet will have similar GeoLocation 853 capability as the former's caller identification based services, 854 such as the 911 emergency caller location system in US, mitigating 855 the root cause to the cybersecurity vulnerability. 857 F. With the IPv4 address shortage issue resolved, potential system 858 configurations utilizing the EzIP enhanced address pool may be 859 explored. 861 a. Although the entire predicted number (50B) of IoTs by Year 2020 862 may be served by just one /24 IPv4 public address block utilizing 863 the EzIP scheme with a 240/4 block, let's replace it with a /8 864 block (16M addresses), resulting in about 4MB (16M x 256M) 865 assignable addresses. This is 80K times of the expected 50B IoTs. 866 Or, each and every person (of predicted 2020 population) would 867 have to own over 500K IoTs to use up this address pool. It is 868 apparent that the spares in this allocation should be sufficient 869 to support the growth of the IoTs for some years to come. 871 b. Next, the IPv4 pool originally has 256 blocks of /8 addresses. 872 After the above allocation, there are still 239 blocks of /8 873 addresses available to support additional digital communication 874 systems, each having the same size of address pool as the 875 allocation above. Consequently, many world-wide communication 876 networks may coexist under the same IPv4 protocol framework in the 877 form of groups of RANs as described earlier, with arm's-length 878 links among them. 880 c. For example, a satellite based Internet that is being proposed 881 [19], can start fresh with one EzIP RAN served by one SPR having 882 the capacity of 256M IoTs, under one ER capable of managing one /8 883 block of IPv4 public address. Utilizing caching proxy as the 884 gateway to handle the data exchange with other RAN, this satellite 885 based Internet with 256M hosts will operate pretty much as an 886 isolated system by using 240/4 addresses in the basic IP headers 887 for intra-RAN communications, most of the time. Only when direct 888 communication with another RAN (such as the one for the existing 889 Internet) is needed, full EzIP header will be used. As users grow, 890 additional RANs (each with 256M IoTs capacity), may be 891 incrementally added to support the expansion. 893 G. In summary, utilizing the 240/4 address block, the EzIP scheme may 894 expand the IPv4 based Internet to be a collection of up to 240 groups 895 of 16M RANs each managed by one SPR with 256M IoTs capacity that are 896 inter-operable digital communication systems, normally operate at 897 arm's-lenghth to one another. Each of these groups has the address 898 capacity of at least 80K times of the number of predicted (50B) IoTs 899 by Year 2020. 901 6. Security Considerations 903 The EzIP solution is based on an inline module called SPR that 904 intends to be as transparent to the Internet traffic as possible. 905 Thus, no overall system security degradation is expected. 907 7. IANA Considerations 909 This draft does not create a new registry nor does it register any 910 values in existing registries; no IANA action is required. 912 8. Conclusions 914 To resolve the IPv4 public address pool exhaustion issue, a technique 915 called EzIP (phonetic for Easy IPv4) making use of a long reserved 916 address block 240/4 is proposed. 918 This draft RFC describes an enhancement to IPv4 operation utilizing 919 the IP header Option mechanism defined in RFC791. Because the design 920 criterion is to enhance IPv4 by extending instead of altering it, the 921 impact on already in-place routers and security mechanisms is 922 minimized. 924 The basic EzIP philosophy includes maintaining the existing private 925 network configuration. Upon reclassifying the "RESERVED for Future 926 use" 240/4 block to be the Semi-Public address pool, it will only be 927 usable by the new SPR (Semi-Public Router) as the EzIP extension 928 address. This pool can multiply each current IPv4 public address by 929 256M times, while all existing public network and subscriber premises 930 setups (private networks as well as directly connected IoTs) may 931 remain unchanged. A subscriber is encouraged to upgrade his IoT(s) to 932 be EzIP-capable so as to enjoy the enhanced router service by EzIP. 933 This particular manifestation of the EzIP scheme appears to be the 934 optimal solution to our needs. 936 The 240/4 block based EzIP scheme will not only relief the IPv4 937 address shortage issue, but also improve the defense against 938 cybersecurity intrusion by virtue of systematic address management. 939 The EzIP' RAN (Regional Area Network) configuration will also support 940 the desire to establish CIR operation expressed by ITU-T, as a 941 parrellel facility to provide Internet type services by individual 942 entities versus the current global model. 944 Furthermore, the EzIP will transcend the IPv4 based Internet to 945 become the common backbone for multiple world-wide digital 946 communication systems that normally may operate at arm's-length from 947 one another. 949 9. References 951 9.1. Normative References 953 [1] https://tools.ietf.org/html/rfc791 955 [2] https://tools.ietf.org/html/draft-wilson-class-e-02 957 9.2. Informative References 959 [3] 960 https://www.cisco.com/c/dam/en_us/about/ac79/docs/innov/IoT_IBSG_0411FINAL.pdf 962 [4] http://stats.labs.apnic.net/ipv6 964 [5] https://ams-ix.net/technical/statistics/sflow-stats/ether-type 966 [6] https://tools.ietf.org/html/rfc6598 968 [7] http://www.iana.org/assignments/ipv4-address-space/ipv4-address- 969 space.xhtml 971 [8] https://tools.ietf.org/html/rfc1918 973 [9] https://tools.ietf.org/html/rfc793 975 [10] https://www.ietf.org/rfc/rfc2131.txt 977 [11] http://www.iana.org/assignments/ip-parameters/ip- 978 parameters.xhtml 980 [12] https://tools.ietf.org/html/rfc1385 982 [13] https://tools.ietf.org/html/draft-chimiak-enhanced-ipv4-03 984 [14] https://en.wikipedia.org/wiki/Proxy_server#Improving_performance 986 [15] 987 http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.477.1942&rep=rep1&type=pdf 989 [16] https://tools.ietf.org/html/rfc862 991 [17] https://tools.ietf.org/html/rfc2928 993 [18] https://www.nro.net/wp-content/uploads/nro-response-to-ls-5.pdf 995 [19] https://www.commerce.senate.gov/public/index.cfm/2017/10/the- 996 commercial-satellite-industry-what-s-up-and-what-s-on-the-horizon 998 10. Acknowledgments 1000 The authors would express their deep appreciation to Dr. W. Chimiak 1001 for the enlightening discussions about his team's efforts and 1002 experiences through the EnIP development. 1004 This document was prepared using 2-Word-v2.0.template.dot and 3- 1005 nroff.template. 1007 Appendix A EzIP Operation 1009 To demonstrate how EzIP could support and enhance the Internet 1010 operations, the following are three sets of examples that involve 1011 SPRs as shown in Figure 1. These present a general perspective of how 1012 IP header transitions through the routers may look like. 1014 1. The first example is between EzIP-unaware IoTs, T1a and T4a. This 1015 operation is very much the same as the conventional TCP/IP packet 1016 transmission except with SPRs acting as an extra pair of routers 1017 providing the CGN service. 1019 2. The second one is between EzIP-capable IoTs, T1z and T4z. Here, 1020 the SPRs process the extended semi-public IP addresses in router 1021 mode, avoiding the drawbacks due to the NAT type of operations above. 1023 3. The last one is between EzIP-unaware and EzIP-capable IoTs. By 1024 initiating and responding with a conventional IP header, EzIP-capable 1025 IoTs behave like EzIP-unaware IoTs. Thus, all packet exchanges use 1026 the conventional IP headers, just like case 1. above. 1028 A.1. Connection between EzIP-unaware IoTs 1030 A.1.1. T1a Initiates a Session Request towards T4a 1032 T1a sends a session request to SPR4 that serves T4a by a plain IP 1033 packet with header as in Figure 5, to RG1. There is no TCP port 1034 number in this IP header yet. 1036 0 1 2 3 1037 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 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 1 |Version|IHL (5)|Type of Service| Total Length (20) | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 2 | Identification |Flags| Fragment Offset | 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 3 | Time to Live | Protocol | Header Checksum | 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 4 | Source Host Number (192.168.1.3) | 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 5 | Destination Host Number (69.41.190.148) | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 Figure 5 IP Header: From T1a to RG1 1052 A.1.2. RG1 Forwards the Packet to SPR1 1054 RG1, allowing be masqueraded by T1a, relays the packet toward SPR1 by 1055 assigning the TCP Source port number, 3N, to T1a, with a header as in 1056 Figure 6,. Note that the suffix "N" denotes the actual TCP port 1057 number assigned by the RG1's NAT. This could assume multiple values, 1058 each represents a separate communications session that T1a is engaged 1059 in. A corresponding entry is created in the RG1 state table for 1060 handling the reply packet from the Destination site. Since T4a's TCP 1061 port number is not known yet, it is filled with all 1's. 1063 0 1 2 3 1064 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 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 1 |Version|IHL (5)|Type of Service| Total Length (24) | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 2 | Identification |Flags| Fragment Offset | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 3 | Time to Live | Protocol | Header Checksum | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 4 | Source Host Number (240.0.0.0) | 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 5 | Destination Host Number (69.41.190.148) | 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 6 | Source Port (3N) | Destination Port (All 1's) | 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 Figure 6 TCP/IP Header: From RG1 to SPR1 1080 A.1.3. SPR1 Sends the Packet to SPR4 through the Internet 1082 SPR1, detecting no EzIP option word, acts like a CGN. It allows being 1083 masqueraded by RG1 (with the Source Host Number changed to be SPR1's 1084 own and the TCP port number changed to 0C, where "0" is the last 1085 octet of RG1's IP address, and "C" stands for CGN) and sends the 1086 packet as in Figure 7 out through the Internet towards SPR4. The 1087 packet traverses through the Internet (ER1, CR and ER4) utilizing 1088 only the Destination Host Number (word 5) in the header. 1090 0 1 2 3 1091 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 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 1 |Version|IHL (5)|Type of Service| Total Length (24) | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 2 | Identification |Flags| Fragment Offset | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 3 | Time to Live | Protocol | Header Checksum | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 4 | Source Host Number (69.41.190.110) | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 5 | Destination Host Number (69.41.190.148) | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 6 | Source Port (0C) | Destination Port (All 1's) | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 Figure 7 TCP/IP Header: From SPR1 to SPR4 1107 Note that although schematically shown in Figure 1 as one public IPv4 1108 address serving one SPR capable of a full 240/4 address block, the 1109 PCP port number has a theoretical limit of 64K (256 x 256) because it 1110 consists of 16 bits. This is much smaller than a full 240/4 pool. 1111 Even with dynamic assignments, it will take quite a few public 1112 address to serve the NAT need if many IoTs are EzIP-unaware. So, IoTs 1113 are encouraged to become EzIP-capable as soon as possible to avoid 1114 straining the SPR's NAT capability. This should not be an issue for 1115 emerging regions currently having very little facility and IoTs. As 1116 new ones are deployed, they should be enabled as EzIP-capable by 1117 factory default. For the rural area of developed countries with 1118 existing EzIP-unaware IoTs, the need for CG-NAT service will be 1119 greater. Multiple IPv4 public addresses would be needed initially to 1120 support smaller sub- 240/4 blocks. This is probably workable because 1121 the latter does have more public IPv4 addresses. The CG-NAT 1122 techniques developed under RFC6264 [6] may be incorporated here to 1123 facilitate the transition. 1125 A.1.4. SPR4 Sends the Packet to T4a 1127 Since the packet has a conventional TCP/IP header without Destination 1128 TCP port number, SPR4 would ordinarily drop it due to the CGN 1129 function. However, for this example, let's assume that there exists a 1130 state-table that was set up by a DMZ (De-Militaried Zone) process for 1131 redirecting this packet to T4a with a CGN TCP port number 10C (Here, 1132 "10" is the fourth octet of T4a's Extension address, and "C" stands 1133 for CGN.). After constructing the Destination Host Number 1134 accordingly, SPR4 sends the packet to T4a with a header as in Figure 1135 8. 1137 0 1 2 3 1138 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 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 1 |Version|IHL (5)|Type of Service| Total Length (24) | 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 2 | Identification |Flags| Fragment Offset | 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 3 | Time to Live | Protocol | Header Checksum | 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 4 | Source Host Number (69.41.190.110) | 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 5 | Destination Host Number (240.0.0.10) | 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 6 | Source Port (0C) | Destination Port (10C) | 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 Figure 8 TCP/IP Header: From SPR4 to T4a 1154 A.1.5. T4a Replies to SPR4 1156 T4a interchanges the Source and Destination identifications in the 1157 incoming TCP/IP packet to create a header as in Figure 9, for the 1158 reply packet to SPR4. 1159 0 1 2 3 1160 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 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 1 |Version|IHL (5)|Type of Service| Total Length (24) | 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 2 | Identification |Flags| Fragment Offset | 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 3 | Time to Live | Protocol | Header Checksum | 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 4 | Source Host Number (240.0.0.10) | 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1170 5 | Destination Host Number (69.41.190.110) | 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1172 6 | Source Port (10C) | Destination Port (0C) | 1173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1174 Figure 9 TCP/IP Header: From T4a to SPR4 1176 A.1.6. SPR4 Sends the Packet to SPR1 through the Internet 1178 SPR4, allowing being masqueraded by T4a, sends the packet toward SPR1 1179 with the header in Figure 10, through the Internet (ER4, CR and ER1) 1180 who will simply relay the packet according to the information in word 1181 5 (Destination Host Number): 1182 0 1 2 3 1183 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 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 1 |Version|IHL (5)|Type of Service| Total Length (24) | 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 2 | Identification |Flags| Fragment Offset | 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 3 | Time to Live | Protocol | Header Checksum | 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 4 | Source Host Number (69.41.190.148) | 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1193 5 | Destination Host Number (69.41.190.110) | 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 6 | Source Port (10C) | Destination Port (0C) | 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 Figure 10 TCP/IP Header: From SPR4 to SPR1 1199 A.1.7. SPR1 Sends the Packet to RG1 1201 Using the stored data in the CGN state-table, SPR1 reconstructs a 1202 header as in Figure 11, for sending the packet to RG1. 1203 0 1 2 3 1204 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 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 1 |Version|IHL (5)|Type of Service| Total Length (24) | 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 2 | Identification |Flags| Fragment Offset | 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 3 | Time to Live | Protocol | Header Checksum | 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 4 | Source Host Number (69.41.190.148) | 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 5 | Destination Host Number (240.0.0.0) | 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 6 | Source Port (10C) | Destination Port (3N) | 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1218 Figure 11 TCP/IP Header: From SPR1 to RG1 1220 A.1.8. RG1 Forwards the Packet to T1a 1222 From the state-table in RG1's NAT, T1a address is reconstructed based 1223 on Destination Port (3N), as in Figure 12. 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 (5)|Type of Service| Total Length (24) | 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 2 | Identification |Flags| Fragment Offset | 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1231 3 | Time to Live | Protocol | Header Checksum | 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 4 | Source Host Number (69.41.190.148) | 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 5 | Destination Host Number (192.168.1.3) | 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1237 6 | Source Port (10C) | Destination Port (3N) | 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1239 Figure 12 TCP/IP Header: From RG1 to T1a 1241 A.1.9. T1a Sends a Follow-up Packet to RG1 1243 To carry on the communication, T1a constructs a full TCP/IP header as 1244 in Figure 13 for sending the follow-up packet to RG1. 1245 0 1 2 3 1246 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 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1248 1 |Version|IHL (5)|Type of Service| Total Length (24) | 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 2 | Identification |Flags| Fragment Offset | 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 3 | Time to Live | Protocol | Header Checksum | 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 4 | Source Host Number (192.168.1.3) | 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 5 | Destination Host Number (69.41.190.148) | 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 6 | Source Port (3N) | Destination Port (10C) | 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 Figure 13 TCP/IP Header: Follow-up Packets From T1a to RG1 1262 A.2. Connection Between EzIP-capable IoTs 1264 The following is an example of EzIP operation between T1z and T4z 1265 shown in Figure 1, with full "Public - EzIP : Private" network 1266 addresses, "69.41.190.110-240.0.0.0:9" and "69.41.190.148- 1267 246.1.6.40", respectively. Note that T4z, without the private portion 1268 (TCP port number) in the concatenated address, is directly 1269 addressable from the Internet. For T1z to initiate a session, it 1270 needs to know the full address of T4z, but only it's own private 1271 address. 1273 A.2.1. T1z Initiates a Session Request towards T4z 1275 T1z sends an EzIP packet, as in Figure 14, to RG1. There is no TCP 1276 port number word, because T4z does not have such while that for T1z 1277 is waiting for assignment from the RG1's NAT. Also, the Extended 1278 Source No. is filled with all "1's", waiting for being specified by 1279 SPR1. 1281 0 1 2 3 1282 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 1283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1284 1 |Version|IHL (8)|Type of Service| Total Length (32) | 1285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1286 2 | Identification |Flags| Fragment Offset | 1287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1288 3 | Time to Live | Protocol | Header Checksum | 1289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1290 4 | Source Host Number (192.168.1.9) | 1291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1292 5 | Destination Host Number (69.41.190.148) | 1293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1294 | EzIP ID | EzIP | Extended | Extended | 1295 6 | (Source) | Option Length | Source | Source | 1296 | (0X9A) | (6) | No.-1 (255) | No.-2 (255) | 1297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1298 | Extended | Extended | EzIP ID | EzIP | 1299 7 | Source | Source | (Destination) | Option Length | 1300 | No.-3 (255) | No.-4 (255) | (0X9B) | (6) | 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1302 | Extended | Extended | Extended | Extended | 1303 8 | Destination | Destination | Destination | Destination | 1304 | No.-1 (246) | No.-2 (1) | No.-3 (6) | No.-4 (40) | 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 Figure 14 EzIP Header: From T1z to RG1 1308 A.2.2. RG1 Forwards the Packet to SPR1 1310 RG1, allowing to be masqueraded by T1z, relays a packet as in Figure 1311 15, toward SPR1 by assigning the TCP Source port number, 9N, to T1z. 1312 Not knowing whether T4z is behind an RG, "All 1's" is used to fill 1313 the Destination Port part of the TCP word. 1314 0 1 2 3 1315 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 1316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1317 1 |Version|IHL (8)|Type of Service| Total Length (36) | 1318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1319 2 | Identification |Flags| Fragment Offset | 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1321 3 | Time to Live | Protocol | Header Checksum | 1322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1323 4 | Source Host Number (240.0.0.0) | 1324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1325 5 | Destination Host Number (69.41.190.148) | 1326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 | EzIP ID | EzIP | Extended | Extended | 1328 6 | (Source) | Option Length | Source | Source | 1329 | (0X9A) | (6) | No.-1 (255) | No.-2 (255) | 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 | Extended | Extended | EzIP ID | EzIP | 1332 7 | Source | Source | (Destination) | Option Length | 1333 | No.-3 (255) | No.-4 (255) | (0X9B) | (6) | 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 | Extended | Extended | Extended | Extended | 1336 8 | Destination | Destination | Destination | Destination | 1337 | No.-1 (246) | No.-2 (1) | No.-3 (6) | No.-4 (40) | 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 9 | Source Port (9N) | Destination Port (All 1's) | 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 Figure 15 TCP/EzIP Header: From RG1 to SPR1 1343 A.2.3. SPR1 Sends the Packet to SPR4 through the Internet 1345 SPR1 replaces the Source Host Number with its own as well as fills in 1346 the Extended Source No. information, and then sends the packet, with 1347 a header as in Figure 16, out into the Internet towards SPR4. The 1348 packet traverses through ER1, CR and ER4, utilizing only the 1349 Destination Host Number (Word 5) in the IP Header. 1351 0 1 2 3 1352 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 1353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1354 1 |Version|IHL (8)|Type of Service| Total Length (36) | 1355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1356 2 | Identification |Flags| Fragment Offset | 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 3 | Time to Live | Protocol | Header Checksum | 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1360 4 | Source Host Number (69.41.190.110) | 1361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1362 5 | Destination Host Number (69.41.190.148) | 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1364 | EzIP ID | EzIP | Extended | Extended | 1365 6 | (Source) | Option Length | Source | Source | 1366 | (0X9A) | (6) | No.-1 (240) | No.-2 (0) | 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 | Extended | Extended | EzIP ID | EzIP | 1369 7 | Source | Source | (Destination) | Option Length | 1370 | No.-3 (0) | No.-4 (0) | (0X9B) | (6) | 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1372 | Extended | Extended | Extended | Extended | 1373 8 | Destination | Destination | Destination | Destination | 1374 | No.-1 (246) | No.-2 (1) | No.-3 (6) | No.-4 (40) | 1375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1376 9 | Source Port (9N) | Destination Port (All 1's) | 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1378 Figure 16 TCP/EzIP Header: From SPR1 to SPR4 1380 A.2.4. SPR4 Sends the Packet to T4z 1382 SPR4 reconstructs T4z address from the Option number 0X9B and the 1383 Extended Destination No. then sends the packet, with the header as in 1384 Figure 17, to T4z. 1385 0 1 2 3 1386 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 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 1 |Version|IHL (8)|Type of Service| Total Length (36) | 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 2 | Identification |Flags| Fragment Offset | 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 3 | Time to Live | Protocol | Header Checksum | 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 4 | Source Host Number (69.41.190.110) | 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 5 | Destination Host Number (246.1.6.40) | 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 | EzIP ID | EzIP | Extended | Extended | 1399 6 | (Source) | Option Length | Source | Source | 1400 | (0X9A) | (6) | No.-1 (240) | No.-2 (0) | 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 | Extended | Extended | EzIP ID | EzIP | 1403 7 | Source | Source | (Destination) | Option Length | 1404 | No.-3 (0) | No.-4 (0) | (0X9B) | (6) | 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1406 | Extended | Extended | Extended | Extended | 1407 8 | Destination | Destination | Destination | Destination | 1408 | No.-1 (246) | No.-2 (1) | No.-3 (6) | No.-4 (40) | 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1410 9 | Source Port (9N) | Destination Port (All 1's) | 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 Figure 17 TCP/EzIP Header: From SPR4 to T4z 1414 A.2.5. T4z Replies to SPR4 1416 Making use of the information in the incoming TCP/EzIP header, T4z 1417 replies to SPR4 with a full header, as in Figure 18. 1418 0 1 2 3 1419 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 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 1 |Version|IHL (8)|Type of Service| Total Length (36) | 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 2 | Identification |Flags| Fragment Offset | 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 3 | Time to Live | Protocol | Header Checksum | 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 4 | Source Host Number (246.1.6.40) | 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 5 | Destination Host Number (69.41.190.110) | 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 | EzIP ID | EzIP | Extended | Extended | 1432 6 | (Source) | Option Length | Source | Source | 1433 | (0X9A) | (6) | No.-1 (246) | No.-2 (1) | 1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 | Extended | Extended | EzIP ID | EzIP | 1436 7 | Source | Source | (Destination) | Option Length | 1437 | No.-3 (6) | No.-4 (40) | (0X9B) | (6) | 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1439 | Extended | Extended | Extended | Extended | 1440 8 | Destination | Destination | Destination | Destination | 1441 | No.-1 (240) | No.-2 (0) | No.-3 (0) | No.-4 (0) | 1442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 9 | Source Port (All 1's) | Destination Port (9N) | 1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1445 Figure 18 TCP/EzIP Header: From T4z to SPR4 1447 A.2.6. SPR4 Sends the Packet to SPR1 through the Internet 1449 SPR4 replaces the Source Host Number with its own, and sends the 1450 packet with the header, as in Figure 19, towards SPR1. The Internet 1451 (ER4, CR, and ER1) simply relays the packet according to the TCP/EzIP 1452 header word 5 (Destination Host Number): 1453 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 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 1 |Version|IHL (8)|Type of Service| Total Length (36) | 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1457 2 | Identification |Flags| Fragment Offset | 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 3 | Time to Live | Protocol | Header Checksum | 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 4 | Source Host Number (69.41.190.148) | 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 5 | Destination Host Number (69.41.190.110) | 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 | EzIP ID | EzIP | Extended | Extended | 1466 6 | (Source) | Option Length | Source | Source | 1467 | (0X9A) | (6) | No.-1 (246) | No.-2 (1) | 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1469 | Extended | Extended | EzIP ID | EzIP | 1470 7 | Source | Source | (Destination) | Option Length | 1471 | No.-3 (6) | No.-4 (40) | (0X9B) | (6) | 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1473 | Extended | Extended | Extended | Extended | 1474 8 | Destination | Destination | Destination | Destination | 1475 | No.-1 (240) | No.-2 (0) | No.-3 (0) | No.-4 (0) | 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 9 | Source Port (All 1's) | Destination Port (9N) | 1478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1479 Figure 19 TCP/EzIP Header: From SPR4 to SPR1 1481 A.2.7. SPR1 Sends the Packet to RG1 1483 SPR1 reconstructs RG1 address from the Option number 0X9B and the 1484 Extended Destination No. Then, sends packet with a header as in 1485 Figure 20 toward RG1. 1486 0 1 2 3 1487 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 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 1 |Version|IHL (8)|Type of Service| Total Length (36) | 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 2 | Identification |Flags| Fragment Offset | 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 3 | Time to Live | Protocol | Header Checksum | 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 4 | Source Host Number (69.41.190.148) | 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1497 5 | Destination Host Number (240.0.0.0) | 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1499 | EzIP ID | EzIP | Extended | Extended | 1500 6 | (Source) | Option Length | Source | Source | 1501 | (0X9A) | (6) | No.-1 (246) | No.-2 (1) | 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 | Extended | Extended | EzIP ID | EzIP | 1504 7 | Source | Source | (Destination) | Option Length | 1505 | No.-3 (6) | No.-4 (40) | (0X9B) | (6) | 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1507 | Extended | Extended | Extended | Extended | 1508 8 | Destination | Destination | Destination | Destination | 1509 | No.-1 (240) | No.-2 (0) | No.-3 (0) | No.-4 (0) | 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 9 | Source Port (All 1's) | Destination Port (9N) | 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 Figure 20 TCP/EzIP Header: From SPR1 to RG1 1515 A.2.8. RG1 Forwards the Packet to T1z 1517 RG1 reconstructs T1z address from RG1's NAT state-table based on 1518 Destination Port (9N), then sends the packet to T1z with a header as 1519 in Figure 21. 1520 0 1 2 3 1521 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 1522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 1 |Version|IHL (8)|Type of Service| Total Length (36) | 1524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 2 | Identification |Flags| Fragment Offset | 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 3 | Time to Live | Protocol | Header Checksum | 1528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 4 | Source Host Number (69.41.190.148) | 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1531 5 | Destination Host Number (192.168.1.9) | 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 | EzIP ID | EzIP | Extended | Extended | 1534 6 | (Source) | Option Length | Source | Source | 1535 | (0X9A) | (6) | No.-1 (246) | No.-2 (1) | 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 | Extended | Extended | EzIP ID | EzIP | 1538 7 | Source | Source | (Destination) | Option Length | 1539 | No.-3 (6) | No.-4 (40) | (0X9B) | (6) | 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 | Extended | Extended | Extended | Extended | 1542 8 | Destination | Destination | Destination | Destination | 1543 | No.-1 (240) | No.-2 (0) | No.-3 (0) | No.-4 (0) | 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1545 9 | Source Port (All 1's) | Destination Port (9N) | 1546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1547 Figure 21 TCP/EzIP Header: From RG1 to T1z 1549 A.2.9. T1z Sends a Follow-up Packet to RG1 1551 With all fields filled with needed information from the incoming 1552 TCP/EzIP header, T1z sends a follow-up packet to RG1 as in Figure 22. 1554 0 1 2 3 1555 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 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 1 |Version|IHL (8)|Type of Service| Total Length (36) | 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 2 | Identification |Flags| Fragment Offset | 1560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1561 3 | Time to Live | Protocol | Header Checksum | 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 4 | Source Host Number (192.168.1.9) | 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1565 5 | Destination Host Number (69.41.190.148) | 1566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1567 | EzIP ID | EzIP | Extended | Extended | 1568 6 | (Source) | Option Length | Source | Source | 1569 | (0X9A) | (6) | No.-1 (240) | No.-2 (0) | 1570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1571 | Extended | Extended | EzIP ID | EzIP | 1572 7 | Source | Source | (Destination) | Option Length | 1573 | No.-3 (0) | No.-4 (0) | (0X9B) | (6) | 1574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 | Extended | Extended | Extended | Extended | 1576 8 | Destination | Destination | Destination | Destination | 1577 | No.-1 (246) | No.-2 (1) | No.-3 (6) | No.-4 (40) | 1578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1579 9 | Source Port (9N) | Destination Port (All 1's) | 1580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1581 Figure 22 TCP/EzIP Header: Follow-up Packets from T1z to RG1 1583 A.3. Connection Between EzIP-unaware and EzIP-capable IoTs 1585 A.3.1. T1a Initiates a Request to T4z 1587 Since T1a can create only conventional format IP header, the SPRs 1588 will provide CGN type of services to the TCP/IP packets. And, 1589 assuming SPR4 has a state-table set up by DMZ for forwarding the 1590 request to T4z, the packet will be delivered to T4z. Seeing the 1591 incoming packet with conventional TCP/IP header, T4z should respond 1592 with the same so that the session will be conducted with conventional 1593 TCP/IP headers. The interaction will follow the same behavior as in 1594 Appedix A.1. 1596 A.3.2. T1z Initiates a Request to T4a 1598 Knowing T4a is not capable of EzIP header, T1z purposely initiates 1599 the request packet using conventional IP header. It will be treated 1600 by SPRs in the same manner as the T1a initiated case as in Appedix 1601 A.1. so that the packet will be recognizable by T4a. 1603 Note that to maximize the combination in the EzIP System Architecture 1604 diagram (Figure 1) for demonstrating the possible variations, there 1605 is no RG on Premises 4. IoTs, such as T4a and T4z, are thus directly 1606 connected to a SPR, like SPR4 and there is no corresponding TCP port 1607 number in word 9 of the above TCP/EzIP headers. This spare facility 1608 in the header suggests that an RG may be installed if desired, to 1609 establish the similar private network environment as that on Premises 1610 1. 1612 In brief, the steps outlined above are very much the same as the 1613 conventional TCP/IP header transitions through the Internet with the 1614 SPR providing the CGN service. Except, when a TCP/EzIP header is 1615 detected, the SPR switches to the router mode for forwarding the 1616 packet to improve the performance. 1618 In essence, with the EzIP system architecture very much the same as 1619 today's Internet, the SPR starts with assuming the current CGN duty, 1620 while ready to perform the new EzIP routing function for EzIP-aware 1621 IoTs. This strategy offers a simple transition path for the Internet 1622 to evolve toward the future. 1624 It is important to note that both SPR and CGN are inline devices with 1625 respect to ER. However, since CGN provides soft / ephemeral TCP 1626 ports, it is positioned between a CR and ERs, while SPR is located 1627 between an ER and RGs to assign hard / static physical addresses. 1629 Appendix B Internet Transition Considerations 1631 To enhance a large communication system like the Internet, it is 1632 important to minimize the disturbance to the existing equipments and 1633 processes due to any required modification. The basic EzIP plan is to 1634 confine all actionable enhancements within the new SPR module. The 1635 following outlines the considerations for supporting the transition 1636 from the current Internet to the one enhanced by the EzIP technique. 1638 B.1. EzIP Implementation 1640 B.1.1. Introductory Phase: 1642 A. Insert an SPR in front of a web-server that desires to have 1643 additional subnet addresses for offering diversified activities. For 1644 the long term, a new web server may be designed with these two 1645 functional modules combined. 1647 - The first address of a private network address pool, e.g., 1648 242.0.0.0, used by the SPR should be reserved as a DMZ channel 1649 directing the initial incoming service requesting packets to the 1650 existing web server. This will maintain the same current operation 1651 behavior projected to the general public. 1653 - The additional addresses, up to 255.255.255.255 may be used for 1654 EzIP address extension purposes. Each may be assigned to an 1655 additional web server representing one of the business's new 1656 activities. Each of these new servers will then respond with EzIP 1657 header to messages forwarded from the main server, or be directly 1658 accessible through its own EzIP address. 1660 B. Insert an SPR in front of a group of subscribers who are to be 1661 served with the EzIP capability. The basic service provided by this 1662 SPR will be the CGN equivalent function. This will maintain the same 1663 current baseline user experience in accessing the Internet. 1665 C. Session initiating packets with basic IPv4 header will be routed 1666 by SPRs to a business's existing server at the currently published 1667 IPv4 public address (discoverable through existing DNS). The server 1668 should respond with the basic IPv4 format as well. Essentially, this 1669 maintains the existing user experience between a customer and a web 1670 server within an EzIP-unaware environment. 1672 So far, neither the web-server nor any subscriber's IoTs needs to be 1673 enhanced, because the operations remain pretty much the same as 1674 today's common practice utilizing CGN assisted connectivity. See 1675 Appendix A.1. for an example. 1677 D. Upon connected to the main web server, if a customer intentionally 1678 selects one of the new services, the main web server should ask the 1679 customer to confirm the selection. 1680 - If confirmed, implying that the customer is aware of the fact 1681 that his IoT is being served by an SPR, the web server forwards 1682 the request to a branch server for carrying on the session via an 1683 EzIP address. 1685 - The SPR on the customer side, recognizing the EzIP header from 1686 the branch web-server, replaces the CGN service with the EzIP 1687 routing. 1689 - For all subsequent packets exchanged, the EzIP headers will be 1690 used in both directions. This will speed up the transmission 1691 throughput performance for the rest of the session. See Appendix 1692 A.2. for an example. 1694 in 3 1695 B.1.2. New IoT Operation Modes: 1697 A. EzIP-capable IoT will create EzIP header in initiating a 1698 session, to directly reach a specific EzIP-capable web-server, 1699 instead of the manual interaction steps of going through the DMZ 1700 port then making the selection from the main web server. This will 1701 speed up the initial handshake process. See Appendix A.2. for an 1702 example. 1704 B. To communicate with an EzIP-unaware IoT, an EzIP-capable IoT 1705 should purposely initiate a session with conventional IP header. 1706 This will signal the SPRs to provide just the CGN type of 1707 connection service. See Appendix A.1. for an example. 1709 B.1.3. End-to-End Operation: 1711 Once EzIP-capable IoTs become wide spread among the general 1712 public, direct communication between any pair of such IoTs will be 1713 achievable. An EzIP-capable IoT, knowing the other IoT's full EzIP 1714 address, may initiate a session by creating an EzIP header that 1715 directs SPRs to provide EzIP service, bypassing the CGN process. 1716 See Appendix A.2. for an example. 1718 B.2. SPR Operation Logic 1720 To support the above scenarios, the SPR should be designed with 1721 the following decision process: 1723 B.2.1. Sending an IP packet out for an IoT or a RG 1724 If the IP header contains EzIP Option word, SPR will route it 1725 forward by using the EzIP mechanism (replacing Source Host Number 1726 by SPR's own and filling in Extended Source No. if not already 1727 there). Otherwise, the SPR provides the CGN service (assigning TCP 1728 Source Port number and allowing the packet to masquerade with the 1729 SPR's own IP address, plus creating an entry to the state (port- 1730 forward / look-up / hash) table in anticipation of the reply 1731 packet). 1733 B.2.2. Receiving an IP packet from the ER 1735 If a received IP packet includes a valid EzIP Option word, SPR 1736 will provide the EzIP routing service (utilizing the Extended 1737 Destination No. as the Destination Host Number). If only 1738 Destination Port number is present, CGN service will be provided. 1739 For a packet with plain IP header (with neither EzIP nor CGN 1740 information), it will be dropped. 1742 B.3. RG Enhancement 1744 With IPv4 address pool expanded by the EzIP schemes, there will be 1745 sufficient publicly assignable addresses for IoTs wishing to be 1746 directly accessible from the Internet. On the other hand, the 1747 existing private networks may continue their current behavior of 1748 blocking session-request packets from the Internet. In-between, 1749 another connection mode is possible. The following describes such 1750 an option in the context of the existing RG operation conventions. 1752 B.3.1. Initiating Session request for an IoT 1754 Without regard to whether the IP header is a conventional type or 1755 an EzIP one, a RG allows a packet to masquerade with the RG's own 1756 IP address by assigning a TCP port number to the packet and 1757 creating an entry to the state (port-forward / look-up / hash) 1758 table. This is the same as the current NAT practice. 1760 B.3.2. Receiving a packet from the SPR 1762 The "Destination Port" value in the packet is examined: 1764 A. If it matches with an entry in the RG NAT's state-table, the 1765 packet is forwarded to the corresponding address. This is the same 1766 as the normal NAT processes in a conventional RG. 1768 B. If it matches with the IP address of an active IoT on the 1769 private network, the packet is assigned with a TCP port number and 1770 then forwarded to that IoT. 1772 Note that there is certain amount of increased security risk with 1773 this added last step, because a match between a guessed 1774 destination identity and either of the above two lists could 1775 happen by chance. To address this issue, the following proactive 1776 mechanism should be incorporated in parallel: 1778 If the "Destination Port" number is null or matches with neither 1779 of the above two lists, the packet is dropped and an alarm state 1780 is activated to monitor for possible ill-intended follow-up 1781 attempts. A defensive mechanism should be triggered when the 1782 number of failed attempts has exceeded the preset threshold within 1783 a predetermined finite time interval. 1785 In brief, if the IP header of a session requesting packet 1786 indicates that the sender knows the identity of the desired 1787 destination IoT on a private network, the common RG screening 1788 process will be bypassed. This facilitates the direct end-to-end 1789 connection, even in the presence of the NAT. Note that this 1790 process is very much the same as the AA (Automated Attendant) 1791 capability in a PABX telephone switching system that automatically 1792 makes the connection for a caller who indicates (via proper 1793 secondary dialing or an equivalent means) knowing the extension 1794 number of the destination party. Such process has effectively 1795 screened out most of the unwanted callers while serves the 1796 acquaintance expeditiously. 1798 Authors' Addresses 1800 Abraham Y. Chen 1801 Avinta Communications, Inc. 1802 142 N. Milpitas Blvd., #148, Milpitas, CA 95035-4401 US 1803 Phone: _+1(408)942-1485 1804 Email: AYChen@Avinta.com 1806 Abhay Karandikar 1807 Director, India Institute of Technology Kanpur 1808 Kanpur - 208 016, U.P., India 1809 Phone: _(+91)512 256 7220 1810 Email: Director@IITK.ac.in 1812 Ramamurthy R. Ati 1813 Avinta Communications, Inc. 1814 142 N. Milpitas Blvd., #148, Milpitas, CA 95035-4401 US 1815 Phone: _+1(408)458-7109 1816 Email: rama_ati@outlook.com 1818 David Crowe 1819 Wireless Telecom Consultant and Forensic Expert Witness 1820 102 Point Drive NW, Calgary, Alberta, T3B 5B3, Canada 1821 Phone: _+1(403)289-6609 1822 Email: David.Crowe@cnp-wireless.com