How'd You Address a RobotIntroductionPart IIP AddressesWhat Is a NetworkRoutersInternet Routing AddressesIP Address NotationsNAT (Network Address Translator)Default GatewayExercises on Your Home RouterIs an IP Address an Identifier?IPv4 vs. IPv6Ai-Fi VPN and APs (Access Points)Part IIYou've Brought Home a RobotDomesticated Robot Walking about a Single SubnetDomesticated Robot Roaming an IntranetDomesticated Robot out Roaming the WorldRobots Roaming under a Protective CloudFree-Roaming Robots to RobotsDeadboltsReferences
This is a tutorial for those who rarely have the need to understand "IP addresses". It is not meant to attract their idle curiosity but to hit home the fact that the Internet is more than for simple web browsing. The Internet of Things (IoT) is believed to be the next Industrial Revolution impacting the way all businesses, governments, and consumers interact with the physical and digital worlds. There will be a great number of intelligent "things" in your future such as smart watch, body sensors, webcams, smart door knobs, robots in various forms, drones, swarm of drones (bees) and many more, which you need to proactively manage and address (figuratively and literally). You may need to assign certain IP addresses, funny numerals like 10.9.8.8, to your sleuth of intelligent devices and to understand their security implications while doing so. Otherwise, you are handicapped in your ability to command them. Worse yet, if not managed correctly, those devices will be quickly swallowed up by the ever encroaching “attack surface” with grave consequences.
However, even if you are well versed in network technology, we hope you'd find Part II of this presentation an interesting read, which touches upon some unavoidable challenges raised by the rapidly approaching "IoT" thrust. To survive in the brave new world of IoT, its security ramification requires your undivided attention.
If you were a lay person without much background in the innards of the Internet, off and on you'd encounter the uneasy situation when this odd "IP address" is requested. This occurs when you buy yourself a new Wi-Fi router needing "configuration"; or when you need to copy a file from your colleague or to get hold of your desktop PC from a remote location when you are on the road or work from home requiring extensive use of your office PC.
Most of the time our PC plays the role of a "client" device, which typically gets on the network only to acquire information or services from some "server" devices, such as your wireless router, your file servers, web sites, amazon.com, Dropbox servers in the cloud, et cetera. Under the cover mysterious DHCP server assigns to your client device a "dynamic" address, which may change from time to time but is sufficient to establish your PC as an "addressable" device or a member of the Internet community without involving you much. On the other hand, for a "server" device, this addressing issue is considerably more complex and costly. The addresses of servers must be fixed or "static" and reachable (routable) in order for clients to find them from anywhere at any time. They are mapped into friendly "domain names" for you to memorize them. In the current browsing-centric Internet architecture, the servers have strong economic incentive to hold their end of the bargain. We consumers or clients of this commerce-driven world of the Internet have led a sheltered life so far.
As the tidal wave of the IoT tsunami relentlessly advances towards us, this easy life of being a client will soon end. Those server devices we must face and manage in our life will multiply rapidly. Just picture yourself surrounded by iPhones, Androids, smart watches, intelligent door knobs, robots, drones, swarms of drones (bees), driverless cars, and many more. Almost all of them are in the category of servers and inherently mobile, each of which serves some intelligent function, albeit frequently only micro in scope. It will be a challenge for us to reach them individually in order to acquire their designed services. On the other hand, as clear as day, many of those will be hacked and turned into malicious zombie devices if not cared for carefully. A little background in IP addresses and commonsense security in general would go a long way in helping us cope with this flood of new intelligent things and complex application scenarios. Rest assured, for all that mathematical, binary and scary appearances, they are easier to learn than reading a map.
The Internet has been an integral part of our modern life. It is the global system of interconnected computer networks consisting of private, public, academic, business, and government networks of local to global scope, linked by a broad array of electronic, wireless, and optical networking technologies. It has grown organically into a colossal size with its complexity partially reflected in the following graph:
It is frequently asked: What is the building block behind this mesmerizing complexity and tremendous size? What are those “networks” that are being interconnected? Some experts will offer the following simple representation, tongue in cheek not intended:
I find the following picture of a coaxial cable more informative:
This is actually what the first generation network is constructed of. The magic of this piece of coaxial cable is its ability to allow multiple devices attached to it to send, receive and share all signals emitted by all the participants along the same cable. As long as those attached devices observe a specific conversation etiquette or more technically "protocol", all devices may interact with each other through this single cable, hence its rightful name of "network". Note that in the beginning there were around many other competing network standards battling for dominance before Ethernet bested everyone else as the de facto standard, mostly due to its simplicity and ease of deployment.
The yellow line below is the network constructed out of our coaxial cable with a few computers attached to it:
The pinkish blocks embedded in those computers are the NICs (Network Interface Cards or Adapters, nowadays most likely built into the motherboard). Those brown things are BNC connectors, which come in various forms, with the following most popular:
Back in their heyday, these BNC connectors could be seen everywhere and coaxial cables frequently discovered snaking around the office floor below desks and furniture. Gone were the days when the only means of transferring data between computers was mostly through a "sneaker net". The "network" was indeed a revolutionary invention after the arrival of personal computers.
A side note about those two gray "resistor terminators". The effective length of wire adopted by these first generation networks is limited. If a network cable grew too long, the running signals on the cable would greatly deteriorate, in which case another signal-enhancing box may be installed to connect two separate wires to extend the network. Those signal enhancers are called "bridges", for bridging two resistor terminators.
The most widespread signaling etiquette or access protocol in the Ethernet networks is the contention- based CSMA/CD protocol, a mouthful for sure but nowadays simply referred to as the Ethernet protocol. Each NIC has a hardware "address" or an identifier called the MAC address when participating in this message exchange protocol. The MAC address is supposed to be unique, but this uniqueness is not enforced beyond the immediate network it is attached to. This “MAC address” is not to be confused with the “IP address” which is the main topic of our discussion. According to Edward Snowden, the US National Security Agency has a system that tracks the movements of everyone in a city by monitoring the MAC addresses of their electronic devices. You are trackable by your device's MAC address. On Windows systems it is called the "physical address" of the NIC, of 6-byte long. On my Windows PC, they look like 00-8C-FA-8B-89-98 for my Realtek PCIe GBE Family Controller and E8-B1-FC-98-74-88 for my Intel Dual Band Wireless-AC 7260. The NIC device can be created as a "virtual" device, dubbed as "virtual adapter", which also is given a MAC address.
Not long after its invention that long cable was twirled together and cased in a box, becoming a later day hub or switch and bearing less resemblance to its original appearance as a sprawling "network" but more suited for centralized control and deployment flexibility:
As time marches on with the bandwidth and speed of the network improving per Moore's law and the attachment to the switch taking a wide variety of different forms, the basic protocol of Ethernet has remained the same and ruled the network technology behind the scenes since its inception. Nowadays, it is more a connectivity standard, embodied in either hardware or software, than a simple cable attachment agreement. This is true even when the wireless devices came on the scene, with their connectivity also classified as "wireless Ethernet", governed by the same standards bodies (The IEEE 802.11 family). Almost all popular network devices provide Ethernet interface, either by wire or wirelessly. This includes your cell phone, which supports it either directly or through constructing a "layer" above the cellular networks so that your hand set may seamlessly plug into the Internet world.
The popular schematic convention for describing networks and their connectivity still looks pretty much like devices connecting to coaxial cables identifiable through their MAC addresses, by wired or wirelessly:
In the above diagram each computer is labeled with its MAC address, which is too random to memorize. This is why most systems have their own naming convention that assigns sensible names to devices and carries out the mapping to their MAC addresses when required. The names labeled above are examples under Windows NetBIOS convention, with maximal length of 15 characters (not even a power of 2). There is no need for "IP addresses" in this single network scenario.
Without the next great invention, the "router", a network is just a coaxial cable existing in isolation. To interconnect two networks or independent cables, we need the router device to hop or "route" from one to the other. A small router usually looks similar to a hub/switch, a box with cables coming in and out of it. Symbolically it is drawn as the round box in the middle of the drawing below, with two networks interconnected via it:
A router appears to each of its attached networks just like any other devices on the same network except that it can pass data from one network to the other. The Internet would not have grown into its humongous size without the contribution of this simple yet ingenious router technology. Although grossly simplified, the enormous complexity of the Internet can be summed up as a collection of interconnected networks and routers. (This is like saying that a brain is just a collection of interconnected neurons and neural pathways.)
At our home usually the router and switch are combined into a single box with Wi-Fi capability. Most laymen just call that Wi-Fi/Ethernet/Switch/Router box in the closet by the front door "the router". I trust that now you know better than average people and are capable of telling apart functionally the network (ethernet) boxes from router boxes.
Since the MAC address of a device is only useful on the Ethernet where it is attached to, to make reference to foreign devices on different or external networks we need a different addressing scheme. Otherwise put, since MAC addresses are not routable, a second level of addresses for routing purposes is created for sending messages across the networks as part of the Internet Protocol, dubbed as the "IP addresses". Unlike the MAC addresses, which are usually "statically" tied to those NICs where the devices are equipped with, the IP addresses are purely logical constructs, which are "dynamically" configured or re-configured based on the needs of the actual deployment of network devices. Note that the IP address is not an identifier but a simple "location specifier", implying the path leading to it. A device may assume a previously used IP address when it takes over the path formerly used to address another device. It may also be assigned more than one IP address when there are multiple paths leading to it. For instance, a router device has at least two IP addresses, one for each network it is assigned to connect. This transitory path-dependent property, not directly linked to the fixed identity of the device, makes the concept of IP address a bit more confusing than the straightforward MAC addresses. However, from a privacy protection point of view, this lack of identification of a device on the Internet may be a blessing in disguise. The ephemeral nature of IP addresses affords a level of deniability for the location of Internet devices.
An IP address is a unique set of four numbers such as 184.108.40.206, each ranging from 0 to 255. Since the IP address actually implies the path that leads to the specified location, it must be carefully assigned so that the routers may discover their way to it. Those computers within a network and their neighbors usually share a contiguous block of addresses, or subnets for short. This is sometimes required such that a cluster of computers may share the same path in order to conserve routing resources. Those contiguous blocks are on the binary number boundary, or to the power of 2 such as 4, 8, 16, et cetera. For example, 220.127.116.11 to 18.104.22.168 may be the block sharing the same routing path, which has the size of 256, or 2 to the 8th power. All computers in this block share the first 24 bits of address designation, or otherwise put, the "network mask" of (the leading) 24 bits. Sometimes it is expressed as 22.214.171.124/24, or the CIDR notation, with the last 8 bits arbitrarily assignable within this block. Note the last number "118" is taken out of the CIDR expression as it is immaterial. The larger the mask is defined, the smaller its coverage is. For instance, 126.96.36.199/16 covers 256 x 256 addresses, a much larger subnet than 188.8.131.52/24.
(Actually there are two different address schemes: IPv4, as described here, and IPv6. IPv4 is the reigning standard and therefore given more space in this article.)
There is quite a bit of hassle to acquire a block of publicly routable IP address, involving the requirement to register the address block and to provide and maintain the routing resources. For Intranet, namely networks used internally within an enterprise or private organization, a labor saving addressing scheme is defined as follows:
Private addresses: A substantial number of address blocks are defined as "private". They are meant to be utilized within the confines of an administrative domain without the hazard of duplicating those in other organizations. They include those addresses mostly familiar to us, such as 192.168.1.2 (block mask may be as big as 16 bits, or 192.168.0.0/16), or 10.1.2.3. (Block mask may be as short as 8 bits, or 10.0.0.0/8, which offers 256 x 256 x 256 addresses). The following are reserved for private networks:
Public addresses: All other non-private address blocks must be acquired formally through the appropriate regulatory bodies.
It is clear that the amount of private IP addresses available to a private party or enterprise is quite large. The IP address plan, as far as its size is concerned, should not be an issue if there is a way to securely interconnect the branches, each of which owns a unique set of subnets among all the private IP address blocks.
If you understand the diagram below and its subnetting scheme, you are on your way to becoming a network expert!
Note that the lower network or LAN may host 256 devices and the upper network 256 x 256 = 65536 devices. The wireless router between two networks has two IP addresses, one for each network. The router facing the Internet is usually referred to as "Edge Router", which has one local LAN address 10.1.254.254 and another egress address to Internet at 184.108.40.206, that is public and visible to all devices on the Internet. The egress public IP address is usually assigned by your ISP (Internet Service Provider). As it is laid out here, both interior networks 192.168.0.0/24 and 10.1.0.0/16 are private IP addresses and therefore not visible to any devices outside of these two Intranet LANs.
If these two networks constitute one of your domain branches, 192.168.0.0/24 and 10.1.0.0/16 are all you need to declare for this branch, which must not overlap any subnets in any other branches.
More observant readers will note that if the source IP address of a network message is private, it is not possible to get delivered to any one outside the private domain (due to the lack of a valid return address). In that case various types of "proxies" ("care of" intermediaries) may be employed to carry out the deed. NAT (Network Address Translator) is one common proxy which modifies the source address of the message and makes it returnable. Many tunneling agents are other types of proxy that add an extra layer of message header for the delivery.
In the previous network drawing, the edge router serves the NAT function so that all devices interior to the edge may browse the Internet through it. Note that this NAT will reject all connections or UDP packets attempting to enter the private networks uninvited, which incidentally turns it into a highly performant firewall which implements deny-by-default policies. However, if you stockpile a bunch of IoT devices behind your NAT, you need a secure way to address and locate them. You want them to be visible only to you from the Internet outside of the NAT perimeter.
In ordinary situations sending out a message from a client device involves four notions:
The logic for routing a message to its destination based on the source address and the destination address is quite straightforward, involving the following:
An IP address is not intended to identify a device. It only describes its current location. This is why sometimes the device has multiple IP addresses indicating the different paths that may lead to the same device. A significant amount of confusion comes from this dichotomy of "locator" vs. "identifier". Actually most client devices are not given unique identifiers largely because they don't provide useful services worthwhile to be identified. There are also expenses and hazards involved in maintaining publicly accessible identifiers. This situation will quickly change as a large number of IoT devices are not without the need to be individually identified. For instance, almost all robots will be named in order to be given commands.
There are a few issues involved in establishing the location of a device:
As mentioned previously there are two Internet Protocols: IPv4 and IPv6. With the exponential growth of the Internet, the IPv4 addresses are facing depletion. The second generation IPv6 is designed mainly to solve this problem. Many people are anxious to deploy IPv6, which promises to be large enough for every grain of sand on earth to be IP addressable. However, in this day and age, addressability is not too much a concern but security and privacy are. IPv6 would be a healthy boost for Internet service providers but largely irrelevant to individual end users. Actually mindlessly deploying IPv6 into your home or enterprises can only bring pain and loss of privacy. It is a scary thought of assigning each one of our devices a universally unique identification number, which is a direct assault on the privacy of our device ownership. Unless your addressing requirement exceeds the totality of all current internet devices which is totally impossible, there is no reason for any individual or private enterprise to move up to IPv6. On the contrary, even if you have an enormous pressure on the number or the variety of network devices, it is wiser to find a way to subdivide them than to be exposed to IPv6, which will quickly turn into a free-for-all to all the hackers and service providers after the loss of net neutrality.
The number one tenet of network security is the reduction of your "attack surface". Additionally, firewalling is always necessary to limit the exposure of your facility and to filter out hazardous traffic by applying security policies on a packet by packet basis. It doesn't seem to be logical or sensible to first Inflate the attack surface by opening up all your facility through IPv6 and then constructing a firewall to thwart dangerous traffic from invading. Ai-Fi.net takes the only reasonable approach for taking advantage of the infinite connectivity of the public Internet, IPv6 or not, without cramping the growth of your private domains:
Build up your private domains as a complete IPv4 Intranet, consisting of multiple branch sites. Your private domain is completely self contained, segregated from all other domains, invisible to uninvited traffic and therefore impervious to external hacking attempts. Internal devices become addressable only after a rigorous zero-knowledge authentication, prior to the successful completion of which there is no addressability.
Don't risk the privacy and security of your private domains. Adopt Ai-Fi.net.
To protect your network assets, you create and administer your own private domains, each consisting of a number of branch sites. Each site is basically a set of subnetworks without overlapping those in other sites. To connect with other branch sites through Ai-Fi.net, each site requires an AP (Access Point) to interface with the Ai-Fi cloud in the center. A single Ai-Fi account may manage multiple domains.
OK, you've brought home the robot you've always wanted. You name it "Gerty" after the movie "Moon" and hope it's just as useful, obedient, and loyal to your wellbing at its tender robotic heart. We are not going to dwell on the philosophical subject of the robots living among us, but to focus on the mechanic or network issues of keeping them around close to us or sending them out for assignments within the realistic confines of our network technology. IPv4 is used to explain the applications. For IPv6, it is largely the same in routing complexity but much more risky due to unintended exposure in terms of security and privacy.
If your robot is a dumb one, such as this robotic vacuum cleaner physically restricted to a small area in your home without the ability to climb stairs or thresholds, a simple addressing scheme through a local subnet is sufficient to interface with it. Assigning it a private IP such as 192.168.255.88, with all your robots lumped into 192.168.255.0/24, which allows for 255 additional robots, you may start controlling it within the confine of the subnet from the controller at 192.168.1.1. This is the simple and convenient case of combining the identity and the network attachment of the robot into a single IP address.
Obviously you will not be able to turn this thing on from your office remotely.
Supposing that your facility is large enough to have deployed several subnets with various routers connecting them and that your robot has the door opening skill or drone-like capability of flying between subnets , your interaction with this robot is substantially more complicated. Your controller must be able to identify your target robot and figure out the path to reach it. No longer is it sufficient for the single private IP address to act as the identifier. The controller must be able to discover the whereabouts of the robot, or conversely the robot must initiate the contact with its owning controller autonomously when required. Either way the robot would assume multiple IP addresses while moving around. The controller App must be upgraded to deal with this situation, which usually involves assigning the robot an identify, certainly different from its IP addresses, and demands the robot to go through an authentication process when connecting back to the controller or the mother ship, as it is no longer workable or secure to equate its identity with its ever changing IP addresses.
The authentication process must be sufficiently rigorous to guard against malicious hacking, particularly if the Intranet in which the robot roams spread wide over many physical security perimeters or through the wireless means is easily hacked by simply listening in from outside of the perimeter. Another possible approach is to adopt a large enough subnet such as 10.1.0.0/16 or even 10.0.0.0/8 to cover a facility of a large number of devices and things. Instead of relying on routers, use only bridges so the robot may roam across the entire facility without the need to route to a different subnet. This single-LAN scheme turns the deployment into the scenario described in the previous section titled "Domesticated Robot Walking about a Single Subnet". Although viable, this approach is longer popular due to its security implications and management issues of LAN bridges.
Assuming you have splurged on an expensive and highly capable robot, which is still in the class of ANI (Narrow AI) and not AGI (General AI), and the robot is competent enough to go to the corner bodega to pick up something you've ordered. Now the controller has a much tougher task than before, needing to make contact with the robot while it roams around on the street by itself beyond the warm and fuzzy protective realm of your private intranet. This contact obviously must be made physically through the public Internet as your private wireless network is not powerful enough to cover the distance. The following is required:
Given sufficient resources, requirements 1, 2 and 3 are all doable. However, prior to the offering of Ai-Fi.net, requirement 4 is pretty much beyond the grasp of ordinary consumers, even after learning thoroughly about IP addresses and the inner workings of subnetting. Part of the difficulty stems from the fact that the Internet so far has been well utilized mostly for C2B (Client to Business) purposes but not C2C (Client to Client).
Take another look of the Internet connectivity:
If you use the conceptual model of root/trunk/branch/leaf of intertwined nodes, most of the Internet traffic flows from the consumer nodes (leaves) and converges to upstream branch- and trunk-nodes, which often turns some popular nodes into enormous size. However, inter-leaf traffic remains quite low, if done at all, due to various levels of difficulties:
For requirement 4, in the post-net neutrality world, you need to recruit the assistance of some service providers who are willing to offer the connectivity purpose-built for not recording the meta-data precious to you. Ai-Fi.net offers this level of privacy protection automatically.
Ai-Fi.net is built as a network overlay on top of the Internet with its own rules and design priorities. Originally motivated by the requirement for remote access of Ai-Fi subscribers connecting back to their home base, branch IP addresses are highly mobile and dynamically established only after the connection is successfully made to the cloud. Furthermore, Ai-Fi.net guarantees the identity of the AP through a rigorous authentication measure. If the Ai-Fi AP (Access Point) server function is embedded into a device, this AP function set would enable a "cloud of one" which may move about and uniquely identifies the embedding device. Combining with the stealth nature of the AP or the branch location, the assigned internal IP address of the AP may be equated with the device itself. This "cloud of one" feature completely delegates the authentication function to the cloud and greatly simplifies the App for controlling the robots, while its private but routable IP address never changes. Even the presence status of this "cloud of one" is maintained and kept up to date for the App to take advantage of.
The ultimate connectivity under the owning controller is to simply lay out the rules of engagement or interaction for those robots to follow, leave them be and come back later to harvest the happy results. Robots would contact other robots individually or in swarms attempting to realize their master's desire.
As far as the connectivity goes, all those four requirements mentioned previously still apply.
To summarize, Ai-Fi.net's approach is to cover and protect those robots in one or multiple virtual domains over and above the Internet, depending on their individual tasks and functions, and tightly supervise their managed interactions. Interactions beyond domains obviously impose a different level of risks. Only after those risks are assessed and deemed acceptable, and only after the rules of engagement are explicitly defined, are they allowed to be carried out.
This network protection can be effected simply by configuring a domain to contain all the "things" you are interested in and embed the target with a tag of unique IP address, which is announced to all other intelligent things. Whenever the target is able to connect with the Ai-Fi.net, its location and other relevant information may be passed around for tracking purposes.
TBD [Rogue robot dogs]