Imagine creating and orchestrating 1 million containers\u2014in less than two minutes. That\u2019s a whole new dimension of IP management issues.\u00a0\nAlmost all organizations depend on IP-based devices to ensure worker productivity. But few, if any, workers remain in one fixed location for their entire employment\u2014many may move several times within a year. This causes immense complexity in managing the movement of devices, and the inevitable address conflicts and limitations.\u00a0\nAnd it\u2019s only getting worse as network administrators deal with devices spanning physical, virtual, and cloud domains. Take software containers, for example. These lightweight, self-contained executable packages of software can be populated across operating systems and environments quickly. A recent Microsoft demonstration involved the creation and orchestration of 1 million containers\u2014in less than two minutes. That represents a whole new dimension of IP management issues.\u00a0\nBecause a machine\u2019s IP address is used simultaneously for both identity and location, network management relies on rules and security policies that dictate how devices can connect to enterprise servers, firewalls, VPNs, and other users. That can create unforeseen problems when companies merge or data centers are migrated only to discover that two entities are using the same IP address, which can render either or both unusable for network operations.\u00a0\nIP conflict headaches\nThere are two options to resolve IP conflicts, Keith Townsend writes in Tech Republic. The preferred one is to define a new IP address scope for the conflicting network, something known as re-IP'ing.\u00a0\n\u201cDepending on the size or complexity of the target network, re-IP'ing is not an option,\u201d Townsend points out. \u201cThink of hundreds of databases with hard-coded IP addresses or thousands of desktops with client software configured to communicate via hard-coded IP addresses.\u201d\u00a0\nThe second option is to set up Network Address Translations tables, but, Townsend notes, \u201cfor large networks, this technique becomes extremely difficult to manage and troubleshoot.\u201d\u00a0\nConsider that you\u2019ll need to use public IP addresses to access cloud services over the internet, and likely also private IP addresses if you\u2019re utilizing a hybrid cloud environment. You may want to integrate services from multiple clouds, which can be complex, and in many cases impossible. Public cloud providers cannot support cross region VPC (Virtual Private Clouds) peering primarily due to IP namespace limitations.\u00a0\nThere\u2019s got to be a better way, and there is: an Identity Defined Network (IDN) fabric that relies on cryptographic identities for each authorized device. HIP separates the end-point identifier and locator roles of IP addresses, providing for a more flexible networking and secure Host Identity Namespace.\u00a0\nAccording to Tempered Networks, IDN security policy is based on a unique, long-lived CryptoID (CID), rather than on a short-lived IP address: \u201cWithin the IDN fabric, the identity of an IP resource is now a unique CID, not the IP address itself. This secure abstraction allows tremendous flexibility in IP resource and networking mobility. For the first time, an IP resource can move within the fabric and still be found, authenticated and authorized whether it\u2019s movement is in a static or dynamic IP environment.\u201d\u00a0\nTo learn more about the IDN architecture, download this white paper.