idnits 2.17.1 draft-chimiak-enhanced-ipv4-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. == There are 23 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 08, 2016) is 2877 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Chimiak 3 Internet-Draft S. Patton 4 Intended status: Experimental J. Brown 5 Expires: December 10, 2016 Laboratory for Telecommunication Sciences 6 J. Bezerra 7 Florida International University 8 H. Galiza 9 Rede Nacional de Ensino e Pesquisa (RNP) - NEG AmLight 10 J. Smith 11 University of Pennsylvania 12 June 08, 2016 14 IPv4 with 64 bit Address Space 15 draft-chimiak-enhanced-ipv4-03 17 Abstract 19 This document describes a solution to the Internet address depletion 20 problem through use of a clever IPv4 options mechanism as a solution. 21 This IPv4 protocol extension is called enhanced IP (EnIP). Because 22 it is IPv4, it maximizes backward compatibility while increasing 23 address space by a factor of 17.9 million. Unlike other similar 24 proposals, care was taken to avoid costly changes and requirements to 25 the core network and border routers, with the exception that options 26 be passed in that equipment as described below. Because it is 27 backward compatible, current IPv4 software, network equipment, 28 firewalls, intrusion detection/protection, and layer 5 firewalls can 29 be maintained until IPv6 system information security reaches 30 acceptable maturity and availability. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on December 10, 2016. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Protocol Transitions . . . . . . . . . . . . . . . . . . 4 68 1.2. EnIP's Use of IP Options . . . . . . . . . . . . . . . . 4 69 1.3. Contents of this Paper . . . . . . . . . . . . . . . . . 5 70 2. Introduction to EnIP (EnIP) . . . . . . . . . . . . . . . . . 5 71 2.1. EnIP Addressing Example . . . . . . . . . . . . . . . . . 5 72 2.2. IPv4 Header with EnIP Option Header . . . . . . . . . . . 5 73 2.2.1. IPv4 Header Fields used for EnIP . . . . . . . . . . 6 74 3. EnIP Operation . . . . . . . . . . . . . . . . . . . . . . . 8 75 3.1. IPv4 NAT Explanation using Figure 2 . . . . . . . . . . . 8 76 3.1.1. Typical Private IPv4 Host to a Typical Public IPv4 77 Host using NAT . . . . . . . . . . . . . . . . . . . 8 78 3.1.2. Typical Private IPv4 Host to a Typical Private IPv4 79 Host using NAT . . . . . . . . . . . . . . . . . . . 9 80 3.1.3. Private EnIP Host to a Typical Public IPv4 Host 81 NAT . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 3.1.4. Private EnIP Host to a Typical Private IPv4 Host 83 using NAT . . . . . . . . . . . . . . . . . . . . . . 10 84 3.2. Enhanced IPv4 Explanation using an Example Figure 7 . . . 11 85 3.2.1. EIP1 constructs the Packet . . . . . . . . . . . . . 11 86 3.2.2. EIP1 Transmits the Packet to N1 . . . . . . . . . . . 12 87 3.2.3. Packet Arrives at N2 (192.0.2.2) . . . . . . . . . . 12 88 3.2.4. EIP2 Receives the Packet . . . . . . . . . . . . . . 12 89 3.2.5. EIP2 Transmits a Packet to EIP1 . . . . . . . . . . . 13 90 3.2.6. Packet Arrives at N2 . . . . . . . . . . . . . . . . 13 91 3.2.7. Packet Arrives at N1 . . . . . . . . . . . . . . . . 13 92 3.3. Upgrading Servers to Support EnIP . . . . . . . . . . . . 14 93 3.4. DNS Operation . . . . . . . . . . . . . . . . . . . . . . 14 94 3.5. Information Security . . . . . . . . . . . . . . . . . . 14 95 4. Tests and Comparisons of EnIP and Typical IPv4 . . . . . . . 15 96 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 15 97 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 98 7. Informative References . . . . . . . . . . . . . . . . . . . 16 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 101 1. Introduction 103 For various reasons, there is a large demand for IP addresses. It 104 would be useful to have a unique address for each Internet device to 105 allow, if desired, that any device could call another [Lee-2012]. 106 The Internet of Things would also be able to make use of more 107 routable addresses if they were available. Currently, this is not 108 possible with IPv4. IPv6 has presented a potential solution to this 109 problem but has faced problems with global adoption. Carrier Grade 110 Network Address Translation and NAT (NAPT) have provided the solution 111 thus far. 113 Furthermore, in the NIST Workshop on Named Data Networking that took 114 place May 31, 2016 various presentations from Academia and Industry 115 (see http://www.nist.gov/itl/antd/named-data-networking.cfm), did not 116 think IPv6 was the layer 3 network of the future. In fact, attendees 117 recommended abandoning all IP protocols and using Named Data 118 Networking (NDN) as the network layer. Specifically, the NDN Plenary 119 Session 1, Data-centric networking strategies for IoT, a network 120 industry presenter stated that there were serious problems with IPv6 121 in supporting future networks, especially wireless networks and 122 Internet of Things (IoT) systems. That person mentioned only a few 123 of the IPv6 RFCs that attempted to fix the problems, which that 124 person stated would not solve the networking problems. 125 Unfortunately, NDN requires discarding the current IP layer - IPv4 126 and IPv6. 128 Now Enhanced IP (EnIP) was designed to minimize impact on core and 129 border routers. DHCP, ARP, and existing IPv4 routing protocols are 130 compatible with EnIP. By leveraging private address space in a 131 similar manner of IP4+4 [Turanyi-2002], EnIP increases available 132 address space by a factor of 17.9 million [Chimiak-2014] or 17.9 133 million new addresses for each current routable IP address. 135 This could allow the reassignment of small segments of unused address 136 blocks in /8 networks to registries with chronic shortages of IP 137 addresses. 139 EnIP packets carry additional address bits and state in an IP option, 140 eliminating routing table updates like IPv6. EnIP supports end-to- 141 end connectivity, a shortcoming of NAT, making it easier to implement 142 mobile networks. Host renumbering is also not required in EnIP as 143 has been the case with other 64-bit protocol proposals 144 [Turanyi-2002]. This is a major topic of section 4. 146 Because current NATs are resource intensive, requiring that state be 147 maintained, this paper will call these NATs NATs, The stateless NAT 148 used in EnIP will be called an EnIP NAT. 150 1.1. Protocol Transitions 152 Several transitions in the Internet Protocol suite are discussed in 153 the IEEE paper [Chimiak-2014]. These transitions include Network 154 Control Program (NCP) to TCP/IP, the evolution of IPv4, and IPv6. It 155 also refers to network address port translation (NAPT), usually 156 called NAT [Paul-2014], Nat444 [Shirasaki-2012], Dual-Stack Lite 157 [RFC6333], NAT64 [RFC6146] and RFC 6144 [RFC6144]. 159 1.2. EnIP's Use of IP Options 161 EnIP uses IP options to increase address space. Over time, this 162 fixed-length IP option would need to be added to the fast path 163 implementations available on core routers [Aweya-1999]. Fast path 164 implementations are discussed by Hidell et. al. [Hidell-2014]. Fast 165 path allows core routers to optimize data paths to line cards based 166 on table lookups. The fast path does not usually process packets 167 containing IP options [Aweya-1999]. As a result, packets containing 168 IP options are forwarded to the slow path CPU for processing and 169 forwarding to the correct line card. 171 However, a very simple upgrade could be made to the core and border 172 routers to process EnIP packets in the fast path with the following 173 simple pseudo code [Chimiak-2014]: 175 if (IgnoreOptions) 176 FastPathOperations(); 177 else if (IP_Option_Present AND Option_Byte1 == 0X9A) 178 FastPathOperations() ; 179 else 180 SlowPathOperations() ; 182 EnIP and IPv6 both require upgrades to the fast path implementations 183 of routers. EnIP's fast path upgrade has four advantages: 185 (1) The EnIP upgrade is the pseudo code above, instead of a large 186 code base insertion. 188 (2) There is no equipment reconfiguration. 190 (3) Internet providers can independently upgrade their fast paths. 192 (4) Finally, there are no requirements to update the IPv4 routing 193 tables. 195 1.3. Contents of this Paper 197 Section 2 describes EnIP. Section 3 is the heart of the paper, 198 describing the mechanics of EnIP. Section 4 describes the University 199 of Maryland and University of Delaware deployment. It also describes 200 tests between two nodes using EnIP and using normal IPv4 and gives 201 the results of the tests. The final section contains some concluding 202 remarks. 204 2. Introduction to EnIP (EnIP) 206 EnIP increases IP address space while maintaining compatibility with 207 existing IPv4 implementations. Current EnIP implementations use IP 208 option 26 to create a twelve byte extension to the IP header. 210 2.1. EnIP Addressing Example 212 The EnIP extension contains four bytes of overhead, and two four byte 213 fields used as additional storage for the EnIP source and destination 214 addresses. EnIP addresses are written as two IPv4 addresses 215 concatenated together. IPv6 and EnIP addressing schemes are shown 216 below: 218 IPv6 address 2001:0101:c000:0202:0a01:0102::0 219 EnIP address 192.0.2.2.10.1.1.2 221 In the above EnIP address, 192.0.2.2 is a public IPv4 address called 222 the site address; the 10.1.1.2 address is called the host address. 223 The host address is always a private IPv4 address assigned to a host 224 behind a lightweight, stateless EnIP-enabled NAT. It is the private 225 IPv4 address that identifies the host in the network behind that NAT 226 and is compatible with other normal IPv4 hosts. The site address 227 allows the packet to traverse public networks because its IPv4 Source 228 Host Number (or source address) is 192.0.2.2, a fully routable IPv4 229 address. 231 2.2. IPv4 Header with EnIP Option Header 233 The IPv4 header supporting EnIP is shown in Figure 1. It is an IPv4 234 header with additional option space used as follows: 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 1 |Version| IHL |Type of Service| Total Length | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 2 | Identification |Flags| Fragment Offset | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 3 | Time to Live | Protocol | Header Checksum | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 4 | Source Host Number | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 5 | Destination Host Number | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 6 | EnIP ID | EnIP ID |E|E| | 250 | (0X9A) | Option Length |S|D| (Reserved) | 251 | | |P|P| | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 7 | Enhanced Source Address | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 8 | Enhanced Destination Address | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 Figure 1: EnIP Header 260 2.2.1. IPv4 Header Fields used for EnIP 262 The fields 264 Field Bits Description 265 ------------------------------------------------------------------- 266 Version 4 The Version field is identical 267 to IPv4's 268 IHL 4 Internet Header Length is 269 identical to IPv4's and is 270 set to the length of the 271 EnIP header 272 Type of Service 8 The ToS field is identical 273 to IPv4's 274 Total Length 16 The Total Length field is 275 identical to that of IPv4 276 and is 32 octets 277 Identification 16 The Identification field is 278 identical to IPv4's 279 Flags 3 The Flags field is identical 280 to IPv4's 281 Fragment Offset 13 The Fragment Offset field is 282 identical to IPv4's 283 Time to Live 8 The Time to Live field is 284 identical to IPv4's 285 Protocol 8 The Protocol field is 286 identical to IPv4's 287 Header Checksum 16 The Header Checksum field is 288 to IPv4's 289 ------------------------------------------------------------------- 291 EnIP specific 292 ------------------------------------------------------------------- 293 Source Host Number 32 The Source Host Number field 294 identifies the source host. 295 The EnIP use is described in 296 section 3 297 Destination Host Number 32 The Destination Host Number 298 field identifies the 299 destination host.The EnIP 300 is described in section 3 301 EnIP ID 8 The EnIP ID field equals to 302 0x9A or 1 00 11010. It's 303 meaning is given at the end 304 of this section 305 EnIP Option Length 8 The EnIP Option Length field 306 is 12 octets 307 ESP 1 This selector determines if an 308 Enhanced Source Address is 309 present 310 EDP 1 This selector determines if an 311 EnIP Destination Address is 312 present 313 Reserved 14 Reserved for future use 314 Enhanced Source Address 32 This is the host address used 315 by EnIP. It is described in 316 section 3 317 Enhanced Destination Address 32 This is the destination host 318 address used by EnIP. It is 319 described in section 3 320 ------------------------------------------------------------------- 322 NOTE: The protocol has 12 bytes of overhead per packet. 324 The meaning of the EnIP ID field, 326 1 00 11010 (0x9A hexadecimal) 328 is as follows: 330 If an EnIP packet traverses a router and must be fragmented because 331 of a link with a smaller MTU, the copy bit ensures that fragments 332 include the 12-byte IP option header in all fragmented packets. The 333 rest of the bits and their meaning are as follows. 335 +--------------------------------------------------------+ 336 | Meaning of 1 00 11010 the EnIP ID | 337 +-------------+------------------+-----------------------+ 338 | 1 | 00 | 11010 (or 26 base 10) | 339 +-------------+----------------+-+-----------------------+ 340 |copy bit set | Class is Control | Option is a new value | 341 +-------------+------------------|-----------------------+ 343 EnIP Id Field Interpretation 345 Note that 26 is the IP option value used in the EnIP experiments. 347 3. EnIP Operation 349 3.1. IPv4 NAT Explanation using Figure 2 351 +-----+ +-----+ 352 | IP1 | | IP2 | 353 +-----+ +-----+ 354 10.1.1.1 10.3.3.1 355 192.0.2.1 192.0.2.2 356 +----+ +----+ 357 +------+ | N1 | | N2 | +------+ 358 | EIP1 | +----+ +----+ | EIP2 | 359 +------+ 10.1.1.254 10.3.3.254 +------+ 360 10.1.1.2 10.3.3.2 362 EIP1 and EIP2: machines supporting IPv4 363 and Enhanced IPv4 364 IP1 and IP2: machines supporting only IPv4 365 N1 and N2: NAT and EnIPNAT/translator devices 367 Figure 2 - Enhanced IP and Unenhanced IPv4 369 This section shows how two nodes, without EnIP, can communicate. 370 More complete explanations are available in [Chimiak-2014]. 372 3.1.1. Typical Private IPv4 Host to a Typical Public IPv4 Host using 373 NAT 375 IP1 (10.1.1.1), a typical IPv4 host, wants to reach N2 (192.0.2.2) 376 (See Figure 3). It uses NAT (as on Linux iptables) to masquerade as 377 the public IP address of N1 (192.0.2.1). N1 sets up a port 378 forwarding rule for IP1 for return packets from N2. 380 192.0.2.1 192.0.2.2 381 +-----+ +----+ +----+ 382 | IP1 +--------------+ N1 +--------------+ N2 + 383 +-----+ +----+ +----+ 384 10.1.1.1 386 IP1: machine supporting only IPv4 387 N1 and N2: NAT and EnIPNAT/translator devices 389 Figure 3 - Typical Private IPv4 Host to a Typical Public IPv4 Host 390 NAT 392 3.1.2. Typical Private IPv4 Host to a Typical Private IPv4 Host using 393 NAT 395 The same IP1 (10.1.1.1) wants to reach tcp port 80 on IP2 (10.3.3.1), 396 another typical IPv4 host (see Figure 4). The packets from 10.1.1.1 397 use NAT on N1 to masquerade as source IP address 192.0.2.1. At N2 398 (192.0.2.2), the packets arrive. There they have a NAT port 399 forwarding rule setup on N2 to map tcp port 80 on 192.0.2.2 to 400 forward packets to the internal host IP2 (10.3.3.1). 402 192.0.2.1 192.0.2.2 403 +-----+ +----+ +----+ +-----+ 404 | IP1 +---------+ N1 +---------+ N2 +---------+ IP2 | 405 +-----+ +----+ +----+ +-----+ 406 10.1.1.1 10.3.3.1 408 IP1 and IP2: machines supporting only IPv4 409 N1 and N2: NAT and EnIP NAT/translator devices 411 Figure 4 - Typical Private IPv4 Host to a Typical Private IPv4 Host 412 using NAT 414 So packets move from IP1 to N1, taking N1's address as the source 415 address and move to N2. N2 has a mapping to IP2 and sends the packet 416 to IP2. When IP2 sends replies, the NATs used their table entries to 417 send the packet back to IP1, adjusting the addresses as necessary. 419 3.1.3. Private EnIP Host to a Typical Public IPv4 Host NAT 421 Suppose EIP1 (10.1.1.2) wants to reach N2 (192.0.2.2) as in Figure 5. 422 It is the same as an IPv4 node wanting to reach N2. So the 423 destination IP address EIP1 used to communicate with N2 is 192.0.2.2. 424 The NAT device (N1) uses IPv4 NAT to translate the source of the 425 packets to come from 192.0.2.1. EIP1 behaves as though it is an IPv4 426 host. It is fully compatible with normal IPv4 communications. 428 192.0.2.1 192.0.2.2 429 +------+ +---+ +----+ 430 | EIP1 +------------+ N1 +------------+ N2 | 431 +------+ +----+ +----+ 432 10.1.1.2 434 EIP1: machine supporting IPv4 435 and Enhanced IPv4 436 N1 and N2: NAT and EnIP NAT/translator devices 438 Figure 5 - Private EnIP Host to a Typical Public IPv4 Host using NAT 440 3.1.4. Private EnIP Host to a Typical Private IPv4 Host using NAT 442 EIP1 (10.1.1.2) initiates a tcp port 80 connection to IP2 (10.3.3.1) 443 (see Figure 6). Packets from EIP1 reach N1. As above, they are 444 masqueraded as IPv4 address 192.0.2.1. When the packets arrive at N2 445 (192.0.2.2) from N1 (192.0.2.1), there is a port forwarding entry for 446 the port 80 setup to send the packets to IP2 (10.3.3.1). 448 +-----+ 449 192.0.2.1 192.0.2.2 +----+ IP2 | 450 +----+ +----+ | +-----+ 451 +----+ N1 +----------+ N2 +-----+ 10.3.3.1 452 +------+ | +----+ +----+ 453 | EIP1 +-----+ 454 +------+ 455 10.1.1.2 457 EIP1: machine supporting IPv4 458 and Enhanced IPv4 459 IP2: machine supporting only IPv4 460 N1 and N2: NAT and EnIP NAT/translator devices 462 Figure 6 - Private EnIP Host to a Typical Private IPv4 Host using NAT 464 In the reverse direction, IP2 looks at the return address. It is the 465 address of N1 (192.0.2.1). It sends the packet to N2. N2 sees the 466 connection in its state table and realizes the is the N1 to IP2 467 connection. It strips IP2's 10.3.3.1 and places its 192.0.2.2 468 address in the source field and places the appropriate port value and 469 sends the packet to N1. N1 sees that this is the EIP1 to IP2 470 connection in its state table. It uses the state table entry to 471 rewrite the proper port translation, sets the destination address as 472 10.1.1.2 and sends the packet back to EIP1 as a normal IPv4 packet. 474 ------------------------------------------------------------------- 476 It is important to note that thus far this paper 477 has not demonstrated any usage of EnIP features, 478 just compatibility with current IPv4 implementations 480 ------------------------------------------------------------------- 482 3.2. Enhanced IPv4 Explanation using an Example Figure 7 484 Suppose EIP1 wants to send packets to EIP2. Here both hosts are 485 running Enhanced IPv4 stacks and N1 and N2 support EnIP. Suppose 486 EIP1 knows the address of EIP2 is 192.0.2.2.10.3.3.2. EIP1 knows its 487 internal IP address of 10.1.1.2 but is not aware of the external 488 address of N1 (192.0.2.1). The following is done (see Figure 7): 490 192.0.2.1 192.0.2.2 491 +----+ +----+ 492 +-----+ N1 +------------+ N2 +-----+ 493 +------+ | +----+ +----+ | +------+ 494 | EIP1 +-----+ 10.1.1.254 10.3.3.254 +-----+ EIP2 | 495 +------+ +------+ 496 10.1.1.2 10.3.3.2 498 EIP1 and EIP2: machines supporting IPv4 499 and Enhanced IPv4 500 N1 and N2: NAT and EnIP NAT/translator devices 502 Figure 7 - Enhanced IP 504 3.2.1. EIP1 constructs the Packet 506 (1) EIP1 sets the Source Host Number field (the source IPv4 507 address) to 10.1.1.2; 509 (2) The EnIP ID field is set to 0X9A. the ESP bit is zeroed in the 510 EnIP header. 512 (3) The Enhanced Source Address in the EnIP header is set to all 513 ones since an EnIP source address is not currently present. 515 (4) The most significant 32 bits of the EnIP address is set by 516 storing 192.0.2.2 in the IPv4 Destination Host Number. 518 (5) The least significant 32 bits of the EnIP address is set by 519 storing 10.3.3.2 in the EnIP Destination Address field. 521 (6) Finally, EIP1 sets the EDP bit to 1. 523 3.2.2. EIP1 Transmits the Packet to N1 525 The packet is routed to N1 using normal IPv4. N1 does the following: 527 (1) It notes the EnIP option (0X9A)is present. 529 (2) N1 reads 10.1.1.2 from the IPv4 Source Host Number field and 530 places that in the Enhanced Source Address field. This field 531 no longer contains 255.255.255.255. 533 (3) N1 sets the ESP bit to 1 535 (4) N1 makes 192.0.2.1 the IPv4 Source Host Number. 537 (5) N1 recomputes the IP checksum of the new packet. If the 538 packet carries TCP or UDP, it recomputes these checksums as 539 they have also changed. 541 3.2.3. Packet Arrives at N2 (192.0.2.2) 543 When the packet Arrives at N2, N2 does the following: 545 (1) N2 identifies the packet as an EnIP packet (0X9A). 547 (2) It reads the Enhanced Destination Address, 10.3.3.2, and 548 places this value as the IP header's Destination Host Number. 550 (3) N2 zeroes the EDP bit and the Enhanced Destination Address to 551 zero. 553 (4) It recomputes the IP checksum. If the packet carries TCP or 554 UDP, recomputes these checksums as they have changed as a 555 result of a change to the IP destination address. 557 (5) N2 sends the packet to EIP2. 559 3.2.4. EIP2 Receives the Packet 561 When the packet arrives at EIP2, EIP2 does the following: 563 (1) It computes the source address of the packet. The IPv4 Source 564 Host Number (192.0.2.1) is concatenated with the Enhanced 565 source address (10.1.1.2) The result is 192.0.2.1.10.1.1.2. 567 (2) The IPv4 Destination Host Number (address) is 10.3.3.2. 569 3.2.5. EIP2 Transmits a Packet to EIP1 571 To construct a packet from EIP2 to EIP1, EIP2 does the following: 573 (1) EIP2 sets the Option ID field to 0X9A. 575 (2) It takes the IPv4 Source Host Number from the incoming packet, 576 192.0.2.1, and sets it as the IPv4 Destination Host Number. 578 (3) It places the Enhanced Source Address (10.1.1.2) in the 579 Enhanced Destination Address field. 581 (4) EIP2 sets the EDP field to 1 and the IPv4 Source Host Number 582 to 10.3.3.2. 584 (5) It sets the Enhanced Source Address to all ones. 586 (6) It sets the ESP bit to 0. 588 3.2.6. Packet Arrives at N2 590 When the packet Arrives at N2, N2 does the following: 592 (1) It writes 10.3.3.2 in the Enhanced Source Address field. 594 (2) The ESP bit is set to 1. 596 (3) N2 writes 192.0.2.2 in the IPv4 Source Host Number field and 597 recomputes the IP checksum. If the packet carries TCP or UDP, 598 it recomputes these checksums as well. 600 (4) N2 sends the packet to N1 (192.0.2.1). 602 3.2.7. Packet Arrives at N1 604 When the packet arrives at N1, it does the following: 606 (1) N1 reads 10.1.1.2 from the Enhanced Destination Address. 608 (2) It writes this value in the IPv4 Destination Host Number 609 field. 611 (3) It zeroes the EDP bit and the Enhanced Destination Address 612 field. 614 (4) N1 recomputes the IP checksum and if the protocol is TCP or 615 UDP, recomputes these checksums as well. 617 (5) N1 sends the packet to EIP1. 619 3.3. Upgrading Servers to Support EnIP 621 In order to maintain backward compatibility with old IPv4 systems, it 622 is important that the EnIP Source Address is an allowed private 623 address. Otherwise, that address becomes a routable address outside 624 of an autonomous system and there is a potential for routing 625 ambiguity. 627 With a kernel modification to support EnIP, an existing server 628 deployed using an IPv4 address can be upgraded. The example of a TCP 629 echo server [RFC862] is shown in detail elsewhere [Chimiak-2014]. 630 However, highlights are now presented here. 632 An echo server logs the source IP address of each data packet with 633 the getpeername function. However, the length of the IPv4 address 634 structure returned is currently 16 bytes for IPv4 (the size of a 635 struct sockaddr_in). For IPv6 the size of struct sockaddr_in6 is 28 636 bytes. As an example of the Alpha implementation mentioned 637 previously, EnIP returns a new structure called struct sockaddr_ein 638 that is 26 bytes. It is necessary to use the length 26 to detect a 639 struct sockaddr_ein. This new struct has two values: sin addr1 and 640 sin addr2. These represent the IPv4 source address and the EnIP 641 Source Address. An implementation of getpeername could provide a 642 compatibility mode to treat EnIP addresses as IPv4 addresses. Once 643 the echo client software is upgraded, the getpeername implementation 644 could return struct sockaddr_ein. 646 3.4. DNS Operation 648 RFC 2928 provides 2001:0101 as the experimental IPv6 prefix[RFC2928] 649 . EnIP lookups can use already standardized AAAA records with this 650 prefix. This prefix uses 32 bits of the 128 bit AAAA record. EnIP 651 uses only 64 bits of the remaining 96 bits. If 192.0.2.2.10.1.1.2 is 652 the EnIP address, the EnIP AAAA record is 653 2001:0101:c000:0202:0a01:0102::0. We call this an AA record. A new 654 record type is not needed and eliminates the need for DNS server 655 software upgrades on a massive scale. 657 3.5. Information Security 659 The same article shows the care taken to minimize changes in IDS/ 660 Firewalls Operation. It also addresses the prevention of EnIP NAT or 661 hosts from forwarding illegal packets, and its operation with most of 662 IPSEC, except in the full tunnel mode AH+ESP scenario. 664 4. Tests and Comparisons of EnIP and Typical IPv4 666 The IEEE Computer Magazine article describes the two-node EnIP test 667 deployment over the Internet2 network with the EnIP NATs. The tests, 668 along with their results, are given that compare typical IPv4 669 connections with EnIP connections [Chimiak-2014]. EnIP was used 670 across 7 routers on Internet2 to demonstrate viability in 671 environments that need more addressing. 673 In brief, the test had a node at the University of Maryland running 674 the Linux 2.6.38 kernel with patches to include the EnIP alpha code. 675 Another similar node was set up at the University of Delaware. Each 676 had an EnIP NAT. http, samba, and ssh were used without modification 677 with Enhanced IP DNS calls used. 679 The results, in section 5.3 of the paper[Chimiak-2014], show EnIP 680 performance gains over traditional NAT, as there are no hash table 681 lookups, as in NAT. It provided roughly a factor of 2 improvement. 683 EnIP has also had basic testing with a 4G Long Term Evolution (LTE) 684 simulator along with an Android phone. However, these results have 685 not been compiled. 687 5. Conclusion 689 This RFC describes the operation of IPv4 using IP options, called 690 Enhanced IP or EnIP. EnIP provides a solution to IPv4 address 691 scarcity. Because the EnIP design criteria is to extend IPv4 instead 692 of replacing it, it reduces impact on routers and information 693 security mechanisms already in place. The operation of two EnIP 694 nodes at the University of Maryland and the University of Delaware, 695 running http, samba, and ssh without modification of the software or 696 routers in the path demonstrates the feasibility of EnIP on a small 697 but realistic scale that spanned seven routers. 699 Tests were conducted and documented, that show expected performance 700 improvement over the old NAT currently used, and the new EnIP NAT. 701 It provided roughly a factor of 2 improvement [Chimiak-2014]. 703 6. IANA Considerations 705 This document does not create a new registry nor does it register any 706 values in existing registries; no IANA action is required. 708 7. Informative References 710 [Chimiak-2014] 711 Chimiak, W., Patton, S., and S. Janansky, "Enhanced IP: 712 IPv4 with 64-Bit Addresses", IEEE Comuter Magazine Vol. 713 47, Issue 2, pp 62-69, February 2014. 715 [Lee-2012] 716 Lee, G., "The Internet of Things - Concept and Problem 717 Statement", Internet Draft (work in progress) draft-lee- 718 iot-problem-statement-05, July 2012. 720 [Turanyi-2002] 721 Turanyi, Z. and A. Valko, "IPv4+4", Proceedings of the 722 10th IEEE International Conference on Network Protocols, 723 2002. 725 [Paul-2014] 726 Paul, T. and F. Tsuchiya, "Extending the ip Internet 727 through address reuse", ACM SIGCOMM Computer Communication 728 Review vol. 23, Issue 1, pp. 16-33, January 1993. 730 [Shirasaki-2012] 731 Yamaguchi, J., Shirasaki, Y., Miyakawa, S., Nakagawa, A., 732 and H. Ashida, ""Enhanced IP: IPv4 with 64-Bit 733 Addresses"", Internet Draft (work in progress) draft- 734 shirasaki-nat444-isp-shared-addr-08, July 2012. 736 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 737 Stack Lite Broadband Deployments Following IPv4 738 Exhaustion", Proposed Standard RFC 6333, August 2011. 740 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 741 NAT64: Network Address and Protocol Translation from IPv6 742 Clients to IPv4 Servers", Proposed Standard RFC 6146, Apr 743 2011. 745 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 746 IPv4/IPv6 Translation.", Internet Draft 747 (Informational) RFC 6144, April 2011. 749 [Aweya-1999] 750 Aweya, J., "IP router architecture: An overview", 751 Technical Report University of Virginia, 1999. 753 [Hidell-2014] 754 Hidell, M., Sjodin, P., and O. Hagsand, "Router 755 architectures: Tutorial at Networking 2004", Networking 756 2004 Athens, Greece, May 2004. 758 [RFC862] Postel, J., "Echo Protocol", May 1983. 760 [RFC2928] Postel, J., "Initial IPv6 Sub-TLA ID Assignments", 761 September 2000. 763 Authors' Addresses 765 William Chimiak 766 Laboratory for Telecommunication Sciences 767 8080 Greenmead Drive 768 College Park, MD 20740 769 US 771 Phone: +1 301 422 5217 772 EMail: w.chimiak@ieee.org 774 Samuel Patton 775 Laboratory for Telecommunication Sciences 776 8080 Greenmead Drive 777 College Park, MD 20740 778 US 780 Phone: +1 301 422 5217 781 EMail: sam@enhancedip.org 783 James F. Brown 784 Laboratory for Telecommunication Sciences 785 8080 Greenmead Drive 786 College Park, MD 20740 787 US 789 Phone: +1 301 422 5217 790 EMail: brown@ltsnet.net 791 Jeronimo A Bezerra 792 Florida International University 793 11200 S.W. 8th St PC building Suite 312 794 Miami, FL 33199 795 US 797 Phone: +1 786 616 3081 798 EMail: jbezerra@fiu.edu 800 Humberto Silva Galiza de Freitas 801 Rede Nacional de Ensino e Pesquisa (RNP) - NEG AmLight 802 Av. Dr. Andre Tosello, 209 803 Cidade Universitaria Zeferino Vaz Campinas, SP 13083-886 804 Brazil 806 Phone: +55 19 3787-3300 807 EMail: galiza@amlight.net 809 Jonathan Smith 810 University of Pennsylvania 811 Levine Hall 3330 Walnut Street 812 Philadelphia, PA 19104 813 US 815 Phone: 215.898.9509 816 EMail: jms@cis.upenn.edu