The example of the installation of an @home connection, alongside the singular IP address @home allocates per customer, prompts considerations of IP address allocations and ways around the conventional paradigms of globally unique IP addresses and their geographic locations.
First some background. For many years the Internet community is faced with a dilemma of routing table size explosion and available address space depletion, which has resulted in the work towards version 6 of the Internet Protocol (IPv6). IPv6 has significantly longer addresses, but will only be successful if large scale deployment in the underlying infrastructure is in place, accompanied by sensible architecture for a hierarchical address structure, as well as transition strategies, and user software. A while ago a Cisco employee stressed that their best selling Network Address Translation (NAT) routers will obliviate the need for IPv6, as it will slow the address depletion and routing table size increases. That comment and my @home experiences prompted me to write this short summary.
For the purpose of this writeup I assume three Internet client networks, interconnected by broad Internet infrastructure, consisting of interconnected Internet Service Providers (ISP):
In this diagram the numbered red circles as the ISPs that constitute the interconnection network for the infrastructure. Each of the networks (N1, N2, N3) has a router (R1, R2, R3), and a host (H1, H2, H3) on their network. In this case the routers connect to a single ISP each. In all the outlined scenarios, each of the (N1, N2, N3) network can accommodate many hosts.
The common conventional practice is global uniqueness of all the addresses, and predictability of their locations (e.g., all members of a network number are directly interconnected in some way or another). All the network numbers are globally known, and reachable from other networks within the Internet community, typically either via direct knowledge of a route to the specific network, or by using a default route. In other words, each host can directly send stateless IP packets to any other host, with also no state being kept in intermediary routers, and by typically the routers making single-path decisions to getting a packet toward its destination.
Often organizations will attempt to create Virtual Private Network (VPN) overlays by creating tunnels of IP packets encapsulated into IP. Besides the tunnel itself, this will add a 20 byte payload penalty for the additional IP header to each packet
To create a tunnel, for example, in a Linux system, first a tunnel to the destination machine has to be defined, e.g., with a "tunl0" pseudo device:
In the example, H1 and H2 can be part of a common network, perhaps N1 and N2 being different subnets of a common network. This can help with IP address needs, and can also enhance privacy if the tunnel is encrypting all data between R1 and R2. However, if, e.g., N2 is the main network that is being globally routed, and H1 would want to access the larger Internet, it would have to access H3 via R2, as in the example below.
In that case, both traffic from H1 to H3 (red) and from H3 to H1 (blue) traverse R2. This has performance and reliability repercussions. Some of the performance may be improved by R1 having global routing knowledge and delivering packets from H1 directly.
In that scenario, however, an asymmetric path is being created, with H1 to H3 traffic being normally routed, and H3 to H1 traffic being routed via the R2 to R1 encapsulation tunnel.
though any network number would do, as long as won't conflict with addresses known or trying to be reached by the NAT router.
In the example, R1 is being used as the NAT router, with N1 not being globally known. In the example, neither H2 or H3 can reach anything on N1, as N1 is not advertised to the Internet. Instead, R1 will intercept packets on behalf of N1 hosts, and modify the IP header to use its own, usually globally known, IP address, most likely the address of the interface to the local ISP. Typically the N1 host addresses as well as port numbers will be modified, and timed out in R1. For all of N1, the world would only know R1's ISP assigned host address. R1 will dynamically assign ports. It may also have preconfigured mappings, for example if hosts on N1 run servers that are supposed to be globally reachable. In the NAT case there is neither an impact on global routing table sizes, or on depletion of globally unique addresses.
Network Address Translation is called "IP Masquerade" in the Linux operating system. An example (Linux) configuration assigns net 10.1.1.0/24 to N1, and wants to make hosts on N1 be able to communicate with the global Internet. To configure the NAT mechanism, the "IP Masquerade" feature has to be enabled in the Linux kernel, and a command be executed to enable it: