![\"IPv4](\"https:\/\/live-infoblox-blog.pantheonsite.io\/wp-content\/uploads\/ipv4-addresses-locally-significant-nat444.jpg\")
<\/p>\nPervasiveness of IPv4 Network Address Translation (NAT) and continued scarcity of IPv4 addresses has resulted in organizational addressing challenges.\u00a0 Organizations desire a globally unique address space to support their businesses, but IPv4 addresses are increasingly secluded in enclaves making them localized.<\/p>\n
The diagram below shows a familiar end-to-end network topology often drawn during a troubleshooting exercise.\u00a0 A residential broadband client sits on the left side safely sequestered behind their consumer-grade router with its stateful packet filter.\u00a0 Their Internet provider connects them to the public Internet.\u00a0 The server in a co-location data center on the right is behind another stateful firewall performing a one-to-one static NAT.<\/p>\n
<\/p>\n
The subscriber network uses one portion of the private address space and if everything within that residence has a unique address within that home network prefix everything is great.\u00a0 The same is true for the server farm; no overlapping addresses.\u00a0 In this diagram, there are three different domains of IPv4 addresses that require unique addressing, the client, public Internet and server co-location networks.\u00a0 Within each domain the addresses assigned to nodes must be unique and are only locally-significant to that one domain.\u00a0 The nodes in the other domains have no knowledge of the addresses used in the other domains.\u00a0 The significance of the IP address is local to within that address domain bordered in each instance by NAT.<\/p>\n
When it comes to two enterprises communicating with each other over the Internet, they can each use overlapping 10.0.0.0\/8 addresses within their private networks.\u00a0 So long as they are performing NAT on their perimeter firewalls, they can communicate using protocols like HTTP that allow for the changing of the source IP address.\u00a0 The diagram below shows this topology of domains with locally-significant addressing.<\/p>\n
![\"IPv4](\"https:\/\/live-infoblox-blog.pantheonsite.io\/wp-content\/uploads\/ipv4-addresses-locally-significant-nat444-part-2.jpg\")
<\/p>\n
Since all enterprises are using NAT at their perimeters, their addresses are \u201clocally significant\u201d to the internal enterprise networks and, as a result, the end-to-end addressing model is not enabled.\u00a0 When enterprises need to collaborate or with a worldwide economy of partners, suppliers, customers, their options are limited.\u00a0 Mergers and acquisitions are messy at best, and nearly impossible at worst.\u00a0 Enterprises are up against a rock-and-a-hard-place and may soon need to investigate using multiple-layers of NAT internally just like the Internet Service Providers (ISP).\u00a0 This adds operational overhead, increased troubleshooting times, and the cost of the\u00a0Carrier-Grade NAT<\/a>\u00a0(CGN)\/Large-Scale-NAT<\/a>\u00a0(LSN) equipment.<\/p>\n Enterprises felt that they would never exhaust their supply of private\u00a0RFC 1918<\/a>\u00a0IPv4 addresses. For example:<\/p>\n What they didn\u2019t anticipate was the inefficiency of hierarchical addressing (with or without summarization) and the subnetting \u201ctax\u201d whereby additional host addresses are lost through subnetting.\u00a0 Also, most enterprises failed to get high utilization percentages on their internal \/24 subnets.\u00a0 High address utilization can be difficult to achieve on wired LANs, but in wireless networks, organizations must dramatically reduce the DHCP IPv4 lease times.\u00a0 Years ago, DHCP lease durations used to be a week, now they are often set to 24 hours.\u00a0 In some environments, the lease-time may be as short as 4 hours (with renewal occurring at half the lease-time, thus every 2 hours).<\/p>\n Just because your laptop has a private IPv4 address, it isn\u2019t yours for long.\u00a0 You are just temporarily borrowing it, kind of like a parking space.\u00a0 IPv4 addresses are ephemeral and some organizations struggle to accurately determine which device had an IPv4 address at a particular point-in-time.<\/p>\n Below is a diagram of another plausible scenario where the service provider is using the\u00a0IANA-Reserved IPv4 Prefix for Shared Address Space (RFC 6598)<\/a>\u00a0100.64.0.0\/10 within their network.\u00a0 The service provider employs a\u00a0Carrier-Grade NAT<\/a>\u00a0(CGN)\/Large-Scale NAT (LSN)<\/a>\u00a0system at their Internet perimeter and use the 100.64.0.0\/10 prefix for allocating addresses to subscribers\u2019 routers or mobile subscriber devices.\u00a0 Within the cloud service provider infrastructure on the right, an application load balancer function defines the boundary for the \u201c10-net\u201d (in this example: 10.1.0.0\/16) addresses used for cloud server instances.<\/p>\n This scenario could affectionally be referred to as NAT4444.\u00a0 In this scenario, there are four different addressing domains with their own locally-significant addressing.\u00a0 Each domain has no awareness of the addressing used in the other domain.\u00a0 The cloud load balancer receives numerous connection requests but has\u00a0no confidence in the authenticity of the client IP address<\/a>\u00a0in the HTTP(S) header.<\/p>\n There are downsides of this type of a NAT4444 scenario that can negatively impact applications (RFC 7021<\/a>).\u00a0 There have been many presentations on the\u00a0impacts of Carrier-Grade NAT on various applications<\/a>.\u00a0 Using so many NATs along the traffic path can make troubleshooting difficult, if not impossible.\u00a0 Therefore, some network engineers are interested in\u00a0methods of detecting NAT4444<\/a>\u00a0occurring along the traffic path.<\/p>\n Large enterprises are starting to experience difficulties using private IPv4 addresses due to the inefficiency of hierarchical addressing as well as subnetting overhead.\u00a0 Not only are their\u00a0public IPv4 addressing resources<\/a>\u00a0limited, but so too is their use of private\u00a0RFC 1918 reserved address space<\/a>.\u00a0 Their internal private address space is becoming more saturated and densely populated.\u00a0 Inefficient internal private IPv4 addressing can quickly exhaust the 10.0.0.0\/8 range.\u00a0 Some large organizations have exhausted their supply of \u201c10-net\u201d addresses and this becomes more important as enterprises try to deploy cloud infrastructure and create hybrid-IT connectivity (not to mention attempting to deploy any IoT solutions internally with such a limited supply of addresses).<\/p>\n Large organizations are now desperately seeking solutions to their addressing shortage.\u00a0 Even enterprises are now considering using 100.64.0.0\/10 (RFC 6598<\/a>) IPv6 transition space, that is intended only for ISPs.\u00a0\u00a0Netflix is already doing this in their AWS<\/a>\u00a0virtual networks because they don\u2019t have enough 10-net addresses for their cloud infrastructure.\u00a0 The problem with this practice is that this IPv4 address block is specifically intended for service providers to facilitate their deployment of IPv6 for their customers.\u00a0 It is not intended for enterprises to use as a substitute for typical private or public IPv4 addressing for services but rather is supposed to be used for IPv4 as a Service (v4aaS) (see blogs\u00a0part 1<\/a>,\u00a0part 2<\/a>,\u00a0part 3<\/a>).\u00a0 Soon enterprises may find that if they use 100.64.0.0\/10 addresses (say for example in their branches or remote offices), conflicts may occur with their service provider which may also be using 100.64.0.0\/10 addresses for its broadband Internet connections to SOHO subscribers.<\/p>\n Recently, a large enterprise asked me what I thought about them using the\u00a0U.S. DoD\u2019s 7.0.0.0\/8<\/a>\u00a0within their enterprise networks.\u00a0 Since this address space is not advertised with BGP to the default-free-zone Internet backbone routing tables, their feeling was that this was \u201csafe\u201d to use internally.\u00a0 I fervently discouraged this practice.<\/p>\n In the early 2000s, large enterprises were starting to consider using 1.0.0.0\/8 and 2.0.0.0\/8 internally, but then due to address exhaustion,\u00a0these addresses were assigned to RIRs and allocated to companies<\/a>.\u00a0 As a result, if your enterprise is employing this bad practice by using these previously unallocated and unassigned blocks, you may start to experience problems.<\/p>\n Desperate organizations are also revisiting RFC 2544, titled\u00a0Benchmarking Methodology for Network Interconnect Devices<\/a>.\u00a0 This RFC noted that the IPv4 address range 198.18.0.0 through 198.19.255.255 (198.18.0.0\/15) could be used for benchmark performance testing.\u00a0 Now organizations are considering using this in their private networks (and also considering additional reserved ranges identified in\u00a0IETF RFC 5735 Special Use IPv4 Addresses<\/a>).\u00a0 Enterprises may also be considering the purchase of addresses on the open market and going through the\u00a0address transfer process<\/a>, but each year that becomes a more expensive proposition.\u00a0 Often, the public reputation of the IPv4 address blocks that are for sale on the transfer market have poor reputation and are often found on block lists, thus making them unusable.<\/p>\n For more than a decade, the\u00a0Internet Society<\/a>\u00a0(ISOC) and the five RIRs have been encouraging organizations to obtain IPv6 addresses and to start using them.\u00a0 However, many enterprises continue to dismiss the warnings that the Internet has reached some absolute constraint due to the lack of IPv4 addresses.\u00a0 Most organizations dismissed IPv6 in the early 2000s when they first heard of it.\u00a0 Their thinking was that they would use NAT at the perimeter:<\/p>\n What they didn\u2019t anticipate was:<\/p>\n The fact is that IPv6 provides an abundance of globally unique addresses for any possible conceivable application.\u00a0 IPv6 relieves the pressure on addressing that all organizations are experiencing.\u00a0 The absence of the necessity for NAT in IPv6 networks makes for a reduction in the anonymity of bad-actors on the Internet and a restoration of the end-to-end model.<\/p>\n Consider the diagram below that shows the same types of environments described above, but now all using IPv6 addresses from the global unicast address (GUA) space 2000::\/3.<\/p>\n The simplicity of\u00a0IPv6 addressing schemes<\/a>\u00a0as well as the ubiquity of IPv6 support in hosts, network devices, and service provider networks makes IPv6 deployment more achievable than ever.<\/p>\n \u201cLocal significance\u201d is a term that was first used with Frame Relay DLCIs, ATM VPIs\/VCIs, MPLS labels, and Ethernet MAC addresses.\u00a0 However, now the term \u201clocally-significant\u201d also applies to how we use IPv4 addresses today.\u00a0 Contemporary use of multiple layers of NAT has made IPv4 addresses ephemeral and domain-specific.<\/p>\n IPv6 offers a refreshingly simple global addressing model and an abundance of addressing resources for any possible application that consumers, enterprises, service providers, and content providers could dream of.<\/p>\n All organizations should be making progress toward IPv6 adoption to start to relieve their long-term dependence on IPv4 addresses.\u00a0 The\u00a012-step journey<\/a>\u00a0to an IPv6-only network starts with the first step, admitting you have an IPv4 address dependency problem.<\/p>\n Scott Hogg\u00a0(@ScottHogg<\/a>) is CTO of\u00a0HexaBuild.io<\/a>, an IPv6 consulting and training company.\u00a0 Scott is Chair Emeritus of the Rocky Mountain IPv6 Task Force (RMv6TF<\/a>) and authored the Cisco Press book on\u00a0IPv6 Security<\/a>.\u00a0 Follow HexaBuild on\u00a0Twitter<\/a>\u00a0and\u00a0LinkedIn<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":" Residential Network Address Translation (NAT) Pervasiveness of IPv4 Network Address Translation (NAT) and continued scarcity of IPv4 addresses has resulted in organizational addressing challenges.\u00a0 Organizations desire a globally unique address space to support their businesses, but IPv4 addresses are increasingly secluded in enclaves making them localized. The diagram below shows a familiar end-to-end network topology […]<\/p>\n","protected":false},"author":321,"featured_media":1016,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"_genesis_hide_title":false,"_genesis_hide_breadcrumbs":false,"_genesis_hide_singular_image":false,"_genesis_hide_footer_widgets":false,"_genesis_custom_body_class":"","_genesis_custom_post_class":"","_genesis_layout":"","footnotes":""},"categories":[17],"tags":[41,56,38,31,39],"class_list":{"0":"post-1733","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-ipv6-coe","8":"tag-cloud","9":"tag-ipv4","10":"tag-ipv6","11":"tag-networking","12":"tag-protocols","13":"entry"},"acf":[],"yoast_head":"\n\n
Large-Scale Network Address Translation (NAT)<\/h2>\n
![\"IPv4](\"https:\/\/live-infoblox-blog.pantheonsite.io\/wp-content\/uploads\/ipv4-addresses-locally-significant-nat444-part-3.jpg\")
<\/p>\nIPv4 Address Scarcity within Private Enterprise Networks<\/h2>\n
IPv6 For The Win<\/h2>\n
\n
\n
![\"IPv4](\"https:\/\/live-infoblox-blog.pantheonsite.io\/wp-content\/uploads\/ipv4-addresses-locally-significant-nat444-part-4.jpg\")
<\/p>\nConclusions:<\/h2>\n