NZ736418B2 - System and method for ipv4 to ipv6 transition rather than an outage - Google Patents

Abstract

Disclosed is a system and method to provide a seamless transition to IPv6 from IPv4 rather than the outage that occurs presently. The system and method for transition to IPv6 also takes into consideration the application, which must also be migrated to IPv6. There are two types of applications available to the customer, those which he has the source code for, and those that he doesn't. The disclosed system and method differentiates between the two automatically. able to the customer, those which he has the source code for, and those that he doesn't. The disclosed system and method differentiates between the two automatically.

Description

SYSTEM AND METHOD FOR IPV4 TO IPV6 TRANSITON RATHER THAN AN OUTAGE BACKGROUND OF THE DISCLOSURE This disclosure describes a system and method of providing for a controlled transition from IPv4 to IPv6 and the routing necessary to effect that transition.

In general, any time an IP address changes, there is initial outage while that change occurs. Disclosed is a system and method for allowing the IP address between IPv4 and IPv6 to change with a controlled transition rather than an undergoing an .

BRIEF PTION OF THE DRAWINGS Fig 1a IPv4 and IPv6 addresses are deployed at the same time in coordination with each other.

Fig 1b IPv4 and IPv6 are both still in use, but the address register for IPv4 uses the IPv6 address (containing identical information) and both library calls (“gethostbyaddress128” and stbyaddress32”) utilize the IPv6 register.

Fig 2a The IPv6 s is solely available, but the application/system is able to use both IPv4 “gethostbyaddress32” and IPv6 “gethostbyaddress128” ers.

Fig 2b The IPv6 is solely available and the application(s) migrated to use the IPv6 “gethostbyaddress128” library. The IPv4 address is now available for re-use.

Fig 3a The released IPv4 address is put to use on a new network (e.g. for a new customer) and a new IPv6 address is used.

Fig 3b The new IPv6 address and the original IPv4 address is still in place, but the management system is using the new IPv6 address Fig 4a The new IPv6 address is using both IPv4 and “gethostbyaddress” IPv6 ers with the new IPv6 address Fig 4b The application(s) are migrated to the new IPv6 address and IPv6 stbyaddress” library. The IPv4 address is freed up for re-use. The released IPv4 address is again put to use on a new network (e.g. for a new customer) and a new IPv6 address is used.

Fig5 The g aleo identifies a physical or virtual Core Router, a virtual Edge Router, a virtual Autonomous Number System Router, a physical or virtual Layer 2 switch and a management system that can only ca accessed thru a “virtual wire” thru the isolated unrouted network accessible only to the ISP. The ISP chooses the customers to expose the unrouted network that cannot be networked thru so the ers can create their own network ents.

Fig 6 This figure identifies key ISP king components consisting of a firewall to keep customers from accessing each other’s data, a management lan that consists of an isolated non-routing network that is a “virtual wire” between the management system and the physical equipment, a management system that is only accessible thru the ed, nonrouting network, a al or virtual Core Router, and a physical or virtual edge .

Fig 7 The figure shows that a particular customer may utilize via their own network core routers between management systems without the need to erse the internet. This is particular useful for instituting disaster recovery between data centers.

Fig 8 This figure shows that all ISP communications via the internet go thru a core router first, then and edge router, then a firewall, and finally the internet.

Fig 9 This figure shows that a particular er may btilze via their own network core routers between management systejs without the need to tranbsverse the internet.

Fig 10 This figure shows a customer network that utilizes the ISP to instantiate virtual core routers and edge routers, a virtual firewall, and communications via the internet.

Fig 11 The drawing demonstrates, from an ISP system perspective, l key k components provided by the ISP so that their er can create a virtual or physical network.

Fig 12 The drawing demonstrates, from a customer perspective, several key network components that are available to the customer to create a Software Defined Network (virtual network). A person who is skilled in the art will recognize that there are many other network components available (such as load balancers) and that this is a simplified example.

Fig 13 The drawing shows how the Certificate System interacts with the other components to enhance ty. It also identifies a Hardware Security Module that is accessed by the Certificate system that supplies the timing between Regional et Registrars and the location (in a manner ous to GPS) of the RIR’s HSM.

Fig 14 The drawing shows the RPKI system.

Fig 15 The drawing shows the RPKI XML method.

ED DESCRIPTION OF DRAWINGS FIG 1-4 discuss embodiments by which the transition from IPv4 to IPv6 can occur without an outage. An additional benefit occurs because after the tion is completed, the IPv4 addresses are available for re-allocation to a different network and a new customer.

Although this is conceptually simple, this provision has not been disclosed from a thorough investigation of the prior art. Even though IPv6 has been available for over a decade at the time of this patent ation, there are separate processes in place for the allocation of IPv4 addresses and IPv6 addresses, such that there is no coordination of the deployment of IPv4 and IPv6 addresses. As a result, instead of a controlled smooth transition, there are ably outages as new IPs are migrated to the new IPv6 addressing standard. Although the drawings show the low order bits for alignment, the mask can be anywhere in the IPv6 address field. The low order bits are shown in the drawings for city and understanding.

Though the ts are simple to understand, there are many steps disclosed that are necessary to enable a smooth and orderly transition to IPv6 rather than an outage per IP deployment. In the claims and drawings, the major requirements of the present embodiment have been disclosed. The complex details underlying a successful IPv4 to IPv6 transition are “hidden” from the end network/customer but all of them are required to be implemented in the underlying infrastructure. The complexity and non-obviousness of the solution disclosed in this patent explains why this has not been achieved to date.

Fig 1a The first step, as sed in this description, requires that IPv4 and IPv6 addresses be available for allocation. This patent discloses a method, meaning no hardware is required.

Fig 1b The second step is the allocation of both matching IPv4 and IPv6 addresses on a given network at the same time, as shown in Fig 1a. The system and method which controls the sub-allocation of addresses s the matching of IPv4 and IPv6 addresses at a defined n of the address field of IPv6. It doesn’t have to be the low order bits. This ation and gs are shown for simplicity in the drawings. Other bits of the IPv6 s can be used besides the low order bits, but the drawings become very abstract.

Fig 2a The third step is the reallocation of the library :gethostbyaddress32” and the removal of the IPv4 address register from the IPv4 address to the matching IPv5 address register as shown in Fig 1b. This action is disclose by claims indicating that control over the routing s essential. The routing information is also privately used to control where the library “gethostbyaddress” is located.

Fig 2b. The fourth step shows that eventually there will be only a tbyaddress128, This will take a very long time. There is a point of stability for the organization/customer, where all of the source code has been iled to use the new address IPv6 address, whatever binary substitutions can be made of the al IPv4 gethostbeaddress32. It is likely that very few companies will do this, particularly for free. It is more likely that companies will, on a case by case basis, make increased addressing available as a new release.

Fig 3a. The drawing provides identical information as Figure 1a, with one important distinction: The same IPv4 address has been recycled to a ent private k and/or different customer by mapping it with a different IPv6 address. Each IPv4 s as multiple compatible IPv6 addresses. The number of time the IPv4 s can be recycled is dependenton an allocation of at least one IPv4 address to many multiples of IPv6 addresses are that compatible. The multiple of IPv6 addresses governs and puts an upper limit on how many times a particular IPv4 address can be recycled to a new network. The number of IPv4 addresses available determines how many devices can undergo transition at one time.

Fig 3b. The drawing is the allocation of both matching IPv4 and IPv6 ses on a new network at the same time, as shown in Fig 1a. The system and method which controls the sub-allocation of addresses ensures the matching of IPv4 and IPv6 addressses at a defined portion of the address field of IPv6. It doesn’t have to be the low order bits. This explanation and drawing are shown for simplicity in the drawings. Other bits of the IPv6 address can be used s the low order bits, but the drawings become very abstract.

Fig 4a. The drawing is the reallocation of the library “gethostbyaddress32” from the IPv4 address to the matching IPv6 address, as shown if Fig 2b and the removal of the IPv4 s register. This action is disclose by claims indicating that control over the routing is essential. The routing information is also privately used to control where the y “gethostbyaddress32 is located.

All information regarding the status and ss of the IPv4-IPv6 transition is completely proprietary to a customer. If a competitor were to gain access to this information, they would be able to deduce which applications are “legacy” and incapable/uneconomical to migrate and which were in the process of transition. They would then be able to use this information to gain an unfair itive age. The control of the transition has to be under er direction and guidance. Since the IPv4 addresses from the customer will be sold to the highest bidder, it will have to meet the business needs of the customer.

Fig 4b. The g shows that ally the will be only a gethoastbyaddress128.

This will take a very long time. There is a point of stability for the organization/customer, where all of the source code has been recompiled to use the new address IPv6 address, whatever binary substitutions can be made of the original IPv4 gethostbeaddress32. It is likely that very few companies will do this, particularly for free. It is more likely that companies will, on a case by case basis, make increased addressing available as a new release.

As shown in Drawing 2 Fig 1d and Drawing 4 Fig 2d, the customers' applications must be able to properly use “gethostbyaddress” library calls. The preferred method to address this is to have “gethostbyaddress” migrated either by recompiling the source code to a new library provided by the Operating System or by direct binary substitution. Where the source code is not available or it is uneconomical to provide a direct substitution, there is a legacy capability built in that utilizes both IPv4 32 bit “gethostbyaddress” library calls (without the larger addressing possible) and IPv6 128 bit stbyaddress” library calls for applications that support the larger addressing range. This dual capability will exist as long as the customer has legacy applications and it is economically viable for the ISP to support dual capabilities/libraries. The library “gethostbyaddress” must provide valid and correct information for both cases. Every Virtual Machine in the library must provide this capability and any Virtual Machines that are imported into the system must include both copies or it will be automatically a y” ‘gethostbynames’ without the extended addressing capabilities.

Fig 5. Figure 5 shows the basic components that are needed by an Intranet Service Provider (ISP). The primary components from a networking perspective are a ment system to provide the necessary routing and control (identified as element 301), a Core router, physical or virtual, (identified as element 300), an edge , physical or virtual (identified as element 302), a management lan network that individual customers cannot see or network thru to separate the ISP from their customer base (identified as element 304), and a firewall (identified as element 303). The standard solution actually calls for 3 firewalls per er, 2 that the customer controls and one that they cannot see that keeps the management lan secure and isolated. Management systems can be in different locations.

Each location has to have at least one ment system. It should be noted that core routers can only “talk” to other core s (which are connected to each other but are not on the internet) or an edge router for internet bound traffic.

Figure 6 is a more simplified m that is drawn from a customer perspective. It shows the key components that a customer cares about. It contains a core router (identified as element 310), a management system (identified as element 311), an edge router (identified as t 312), a firewall (identified as element 313), and a er network (identified as element 314). The other components that are ant from an ISP ctive are not important to individual customers.

Figure 7 shows how a communications “tunnel” (identified as element 320) is set up between management systems of ISPs that have licensed the technology. It provides a maximum capacity that all of the customer can ish their own private connections.

Notice that all communications go thru a Core Router ified as element 321).

Figure 8 shows how multiple management systems can communicate over the internet by sending communications thru their core router to the edge router (identified as element 330), thru the firewalls (identified as element 331), and encrypted over the internet via their network (identified as 332).

Figure 9 shows a similar picture to Figure 7, but the g is from a er perspective and it shows the key components the customer can instantiate. It shows a customer Core router (identified as element 341) and a particular customer’s e network (identified as element 340) going thru the ISP tunnel. It also shows that if the customer s to instantiate a core router, he can communicate with other data centers (physical or virtual) thru their tunnel allowing the customer to set up a very private communication channel to his other data centers without having to transverse the internet at a size of bandwidth that he chooses up to the maximum set by the size of the ISP’s tunnel. It is obvious to one skilled in the art that the system can be used for disaster recovery. Disaster Recovery is also built in rather than added on, so it costs the customer only what is required for the customer to set up a duplicate data center for the portions of his business that require disaster recovery.

Figure 10 shows a similar e to Figure 8, and the drawing is also from a customer perspective and it also shows the key ents the customer can instantiate. A customer firewall (identified as element 350), a customer edge router ified as element 351), a customer network ified as element 352), and a customer core router have to be d. Drawing 10 Figure 3f divulges how a customer’s data can be broadcast over the internet to achieve the low cost of the internet while maintaining the privacy, security, and isolation that is inherent in his virtual data centers. It also shows multiple ers that are completely separate from each other by design.

Fig 11. Figure 11 fies the key components necessary for implementing Software Defined Networking by an ISP that license the technology. It consists of a firewall (identified as element 400), a management network (identified as t 401), a e/isolated key server, analogous to a public/private key server (identified as element 402), a icate server for issuing, encrypting, decrypting, and revoking certificates (identified as element 403), a core router (identified as element 404), a layer 2 et switch (identified as element 405), an edge router (identified as element 406), and an mous Number System (identified as element 407) to control the routing that occurs over the internet, and RPKI information, and the RPKI XML method of transmitting this data.

Fig 12. The drawing shows a typical Software Defined Network from a customer perspective. It utilized the key components identified in Fig 4a and produces a new software defined LAN utilizing these key components. The components are a customer firewall (identified as element 410), a customer edge router (identified as element 411), a er core router (identified as element 412), a RPKI XML method ified as element 413), a customer network (identified as element 414).

Fig 13 . A proprietary, innovative certificate system that has traceable, verifiable Trust is necessary. The Certificate system also discloses that included is access to several Regional et Registrar’s Hardware Security Module, which serves as a timing source for applications such as VOIP, databases, etc. The information from the Hardware ty Module at each RIR provides the timing and a method of keeping each packet in sync with each other across the globe. This is useful for systems that e accurate timing such as data bases and VOIP systems. The current Hardware Security Module (HSM) at each RIR is capable of between 1,000 to 5,000 encryptions per second. The system would only need one very accurately timed packet to be encrypted and sent to multiple management systems to keep the system clocks in sync. Multiple RIRs would furnish highly accurate timing ation periodically (every second or couple of seconds) that would state how many “clock ticks” of the Hardware Security Module had occurred since the last transmittal.

Typical RIR acronyms are ARIN for North America, RIPE for Europe, APNIC for Asia, LANIC for Latin America, AFRINIC for Africa. It is also sed that the precise physical location is provided in a manner ous to GPS for every packet that generated or transmitted by the system, which is why it needs encryption with its own certificate per customer is ary and ant. The results of where the packet originates is also highly proprietary. This information may or may not be stripped off in the management system and is a separate feature that may be offered to some customers. The key components are identified as a unified system and method for Applications and Databases utilizing XML, an Application mming ace (API), a compiled virtual machine, the application, source code, and libraries that create the compiled virtual machine, the development system that is needed by the application, source code and libraries, a compiler or compilers, and an operating system.

Fig 14. Resource Public Key Infrastructure (RPKI) will be used via duplication, although instead of a public/private key, it is disclosed that it is more similar to a private/isolated key. RPKI is used to allow standard routing BGP (BackGroundProtocol) to function properly. The Resource Certification (RPKI) system allows all ce holders to request a digital certificate listing the Internet number resources they hold. It offers validatable proof of holdership of a resource's registration by a Regional Internet Registry (RIR). The components that are identified on the drawing are customer requirements for information and ISP requirements for information. The customer requirements for a certificate system are the CA State, a private key store, communications keys, and publication repositories. These are sent to a particular Regional Internet Registrar (or the ISP) for validation of the network elements (IP addresses) and the network path. The ISP ements for a certified certificate system are a ed certification store, an ion key store, a certificate archive/store, and a customer ID. This is used to communicate with a particular RIR thru a DMZ. From this communication, the RIR looks at the database of permissible allocations in its region.

Fig 15 Resource Public Key Infrastructure XML (RPKI XML) is the method that is used for the RPKI tructure to interact with each RIR and existing networks so that hardware that is sourced by the ISP has a standard API to utilize. It is nated with Drawing 14 Fig 6, but it shows additional s that each customer, ISP, and al Internet Registrar have to make the system and method possible. The components that are utilized to manage certificates and keys that are ed are web access (normally via https) to a pseudo-application that is called “MyRIR” in this e between a RIR and its customer. The ISP utilizes “rsync” access. There is a separate DMZ maintained by the RIR that provides access for both the customer and ISP to the RIR’s private information. It allows for public access and has an internal boundary. The ation available to each RIR to the “MyRIR” application is the “command and control” function of each RIR. The information of the nd and Control” function are member Certificate Authorization and the Certificate Registry Database as well a ctional information to each customer thru the “MyRIR” application and the DMZ. The Member Certificate Authorization has bidirectional ications with a Member Signing Engine, a Member RPKI Database, and a RIR Certificate Authorization. The Member Signing Engine had bidirectional information between both the Member Certificate Authorization and the Member RKPI Each ISP is also provided with an application “rsync” access to information in each RIR’s DMZ. The “rsync” application obtains bidirectional information from the Member Certificate Authorization and the RIR Certificate Authorization. . The RIR icate Authorization has bidirectional communications with a RIR g Engine, a RIR RPKI Database, and a RIR Certificate Authorization. The RIR Signing Engine had bidirectional information between both the RIR Certificate Authorization and the RIR RKPI Database.

There is also an internal Firewall at each RIR and a Hardware Security Module that has bidirectional access thru the firewall to the RIR Signing Engine. There is a Registry Database that has bidirection information requirements from both the er’s Command and Control function and the RIR Certificate Authorization.

DETAILED DISCLOSURE OF INVENTION It is also disclosed that the occurrence and timing of this transition is completely proprietary and private between the Internet Service Provider (ISP) and the customer/private network. This system and method allows the er network to be completely encapsulated and thus not available for internet surveillance, providing the required level of isolation and ty. It is not necessary to broadcast information regarding the private network’s O{v4/IPv6 tion over the internet (encrypted or not), The required routing information is provided by broadcasting sible routes to AS numbers. In order to accomplish this while still perating with the Regional et Registrar’s standards this system and method provides for a subset of the information to be made available to the Regional Internet Registrar. For example, ARIN (the US-based Internet Naming authority to the Americas Northern Nemisphere) has a hosted solution for providing an encrypted version of this routing information, which is as secure as possible using s technology. The Up/Down interface is used by the Regional Internet Registrars to tell which route are “up” and “down”. Access to this information and interface is provided for compatibility with existing standards.

All information regarding the status and progress of the Pv6 transition is tely etary to a customer. If a competitor were to gain access to this information, the would be able to deduce which ations are “legacy” and incapable/uneconomical to migrate and which were in the process of transition. They would then be able to use this information to gain and unfair competitive advantage. The control of the transition has to be under customer direction and guidance. Since the IPv4 addresses from the customer will be sold to the highest bidder, it will have to meet the business needs of the customer.

As shown in Fig 3b and Fig 4a, the customers’ applications must be able to properly use the “gethostbyaddress32” and “gethostbyaddress128” library calls. The preferred method to address this is to have “gethostbyaddress” migrated either by recompiling the source code to a new y provided by the Operating System of by direct binary substitution Where the source code is not available or it is uneconomical to provide a direct substitution there is a legacy capability buit in that utilizes both IPv4 32 bit “gethostbyaddress32” library calls ut the larger addressing possible) and the IPv6 128 bit “gethostbyaddress128” library calls for application that t the larger addressing range. This dual capabity will exist as long as the customer has legacy applications and it s economically viable for the ISP to support dual capabilities/libraries. The library “gethostbyaddress” must provide valid and correct information in both cases. Every Virtual Machine in the library must e this capability and and Virtuaol Machines that are imported into the system must include both copies or it will be automatically a “legacy” ‘gethostbynames32’ t the extended addressing lities. gh the background of facts for this ion are well known to anyone skilled in the art, there is also a unique insight that has been disclosed for a potential solution to this well known and global problem. It has been known for some years that the world is running out of IPv4 addresses. IPv6 has been in existence for ~15 years (as of the writing of this patent application) as a replacement for IPv4, but it hasn’t gotten any on because there is no incentive to change. Recently, in the last few years, IANA has decided to use economic incentive (or it should be said economic ‘dis-incentive’) because the price projected for new IPv4 addresses is planned to rise. For the transition between the old (IPv4) and new (IPv6) IP addresses, the price of existing IPv4 addresses will need to rise also.

Credit will be given to IANA and the Regional Internet Registrars for the very tough job of creating a market and ping policies and procedures to regulate a market and coming up with an approach to solving the basic problem of the world running out of IPv4 addresses.

The IPv4 addressing scheme was invented back in the early 1980s and has lasted a very long time. IANA, IETF and the Regional Internet Registrars who look at the allocation of IPv4 addresses on a daily basis knows that the world will eventually have to transition to IPv6 and are taking the steps that they see need to be taken and are committed to a very innovative but tough approach of yanking the old tooth out before a new one can be put in the same place.

Likewise, insight was available because of the extreme pain rendered years ago when the IPs changed (from one set of IPv4 addresses to another). Now, this is very specialized knowledge, but someone skilled in the art knows about this potential pain from an outage of transition between IP addresses. Several steps have been taken by the industry since the internal outage years ago, but those with a few gray hairs knows about this potential outage and it may have even caused a few gray hairs along the way. Many of the younger tion skilled in the art haven’t experienced this because of the knowledge that has been garnered and processes that have been put in place to mitigate this circumstance. It would take someone who was very skilled in the art to recognize there is a potential m e even years ago, it wasn’t a well known problem except to a very few individuals.

So the first step is to ize that there is a potential problem. The solution to this problem is vious and requires an understanding of software, an understanding of hardware interfaces and software drivers, an understanding of networking, and an understanding of how systems operate to even ve of the elegant but simple solution that is disclosed.

If both IPv4 and IPv6 addresses are allocated at the same time, with a system of coordination of these addresses which can control the routing, and have a method of issuing both IPv4 and IPv6 addresses to allocate, then the benefits of this solution can be available.

The benefits include: 1) no outage on transition to a new k addressing system 2) the ability to recycle the original IPv4 address to a new network 3) a secure list of applications for the customer that highlight which ations are legacy and which can be transitioned to the wider addressing capability of IPv6 4) a means to transfer the legacy IPv4 addresses and receive some remuneration to the owner of the IPv4 addresses for this effort at market prices that is built in 5) a pure IPv6 network rather than the kluge planned of utilizing ng IPv4 addresses inside of an IPv6 “tunnel” 6) the timing necessary for this tion will be “per customer” and will be controlled by their schedule rather than an outside force dictating that it should occur all at once at a given time.

Also disclosed is the routing necessary to effect this change and the ty of knowing that it will not be disclosed to an outside party.

There are several unique components needed to control the routing. The end effect of an IPv4 to IPv6 address transition without an outage is like the “skin”. There are several things required to make this transition possible besides the skin that is novel and unique.

The current embodiment of a on is 1) a core router under control of the customer that allows his data to tion to a new data center at a different location 2) a ‘software defined network’ virtualizing common network components so that a customer can be totally ed and secure 3) a unique certificate system for encryption 4) timing information from each of the Regional et Registrars that is combined to provide a timing source for a ular physical data center which is integrated with the Certificate system and several of the Regional Internet Registrar’s Cryptographic system 5) an RPKI validation of the data 6) RPKI XML for a method of decoding the data.

The core router can be either physical or virtual. The customer will have access to creaing his own core router. The core router will only be able to transmit packets to a data center that has the components necessary to provide a transition from IPv4 to IPv6 without an outage or to an edge router within the data center that can then transfer the information (encrypted by t) thru a customer’s firewall and onto the internet. The internet is used as a transport mechanism and other transport mechanisms can be other systems and methods besides the et.

The other networking components for a software defined network will also be available for the customer to create their own virtual network available to each customer and allowed to join the customer’s network that the customer creates. The key components from a customer perspective are a software defined core router, a software defined edge router, and a firewall (physical or virtual). It will be noticed by someone skilled in the art that other components such as load balancers and other appliances can be made available too, but these will not be described for simplification.

Since the network deployment is “software defined networking” . a unique module that controls the tion of IPv4 and IPv6 addresses, controls both of the IP address registers and the tin of the software “gethostbyname’ to each register on a “per customer/per network” basis, and reports an ongoing status to the customer/network for both the IP address allocation and software library status is disclosed. The sequence of operations will be to deploy both the IPv4 and IPv6 addresses at the same time with the tbyname32 pointing to the IPv4 register and the gethostbyname library calls on access the IPv6 reister, ocate the IPv4 register, and differentiate which application/databases is using the tbyname32 vs. the gethostbyname128. Since this will be done on a “per ” basis, it will be under the control of the customer/nework. It will be under customer control to decide if this is to be implemented in their virtual data center only, their datacenters only or throughout their organization including the ps and mobile devices. The system and method can be achieved in “chunks” with the ed timing and deployment under the control of the customer/network.

The certificate system will work in a manner that is analogous via two key PKI encryption (public/private) but the keys will be private/isolated. The similar to a public key (the private one in the new system) is known only to particular er and the isolated one is encased in a “black box” inside the management system of the data center, where it is unknown to all parties, even the operator of the data center. Unlike tional systems, when the key is mised it will be simpler to provide new keys. This is analogous to providing a new set of keys and changing the lock rather than replacing the entire strongbox.

Every packet of information will be ted with this set of keys, whether the information is itted over the internet or is transmitted to a different data center with the same capabilities.

It should be noticed that so far, the ients have been disclosed but the systems and methods necessary have not been disclosed (with the exception of sync ). This is similar to having the ingredients for a cake specified but no recipe. The system and methods used will be disclosed in this description/specification and claims of uniqueness in this patent application document.

It would be obvious to anyone skilled in the art that the virtual and physical network interfaces will need to have the capability of having an IPv4 address and an IPv6 s stored at the same time in separate registers. It would also be obvious to anyone skilled in the art that the software call of “gethostsbyname” will also need to be routed to the correct register, which implies that the virtual machine images will also need to have both library calls available (gethostbyname32 and gethostbyname128). It would also be obvious that both libraries will be used for quite some time, but the IPv4 s will be removed and deployed to a new network. The unique routing necessary to make these transitions happen will now be disclosed.

The heart of this system is the clock nce signal that provides a sync clock source from multiple al Internet Registrars. This is accomplished by utilizing the cryptographic system nt in each Regional Internet Registrar and instructing the hardware in the Regional Internet Registrar to issue an encrypted packet or s on a r interval (approximately every 3 seconds per RIR) that contains a very exact and precise time the packet was generated. It will be contain a difference in time between the current packet and the last packet that was sent by the Regional Internet rar. Most packets will take the same path and take roughly the same time to reach the same ation (a particular data center). The location of the clock source is already very stable and known, so that the location of the original RIR packet is also known. For the case that either the RKPI system at a particular RIR moves, receipt timing is altered, or otherwise does not meet the historical guidelines, then that particular RIR’s packet is disabled and a new request for an original packet is placed. The particular RIRs RPKI system will either respond or not, but it will still be disabled until it is approved to “join” with other RIRs in hing the encrypted time/sync signal. If a signal from a particular RIR interferes with a signal from another RIR, it is d off” a random amount of time when it will try again until it succeeds. When the RIR’s packet is received by the data center(s), after a prescribed amount of issions, it is then allowed to “join” with other RIRs in providing a very precise clustered clock sync signal. This furnishes an equivalent of NTP without the need of GPS satellites to provide timing. The amount of “jitter” introduced by a particular Regional Internet Provider on a particular client data center will be measured at the local data center.

The certificate disclosed will be utilize by a sync clock time source. It is disclosed that a system and method will be used that is compatible with existing standards, but the isolated key with unlocks the packet is known by no one and is in an encrypted folder in the management system of the ISP and the contents are under the control of the customer. There will be a lot f transmitting, receiving, and signing that meets the standard and doesn’t interfere with existing patents that are in force.

The cal application offered today is the ability to e resource certificates to help secure et routing, particularly BGP origin validation.

Resource Certification (RPKI) is a ity-driven system in which all Regional Internet Registries, open source software developers and several major router vendors participate. It uses open rds that were developed in the Secure Inter-Domain Routing (sidr) Working Group in the IETF.

A resource certificate offers validatable proof of holdership of a ce's allocation or assignment by an RIR. Using their resource icate, network operators can create cryptographically validatable statements about the route announcements they authorise to be made with the es they hold. This is known as BGP Origin Validation.

It is disclosed in this patent application how to utilize RPKI information to provide validatable proof of the origination of the packet if it originated in a system and method that utilizes this patent. This disclosure is that a unique certificate will be utilized to issue, encrypt, decrypt, and obsolete any packet and that a Regional Internet Registrar must be ed for this technology in order for the packet to be transmitted from the Regional Internet Registrar to the data center that also must be licensed for this technology.

There are about 550,000 route announcements on the Internet at the time of submission of this patent application. The most common routing error is the accidental mis- origination of a prefix, meaning someone unintentionally announces an IP prefix that they are not the holder of. RPKI offers BGP origin validation, so the question it tries to answer is: “Is this particular route announcement authorised by the legitimate holder of the address space?” RPKI allows k operators to create cryptographically validatable statements about the route announcements they authorize to be made with the prefixes they hold. These statements are called Route Origin Authorisations (ROAs).

A ROA states which Autonomous System (AS) is authorized to originate certain IP address prefixes. In addition, it can determine the maximum length of the prefix that the AS is authorized to advertise. Based on this information, other network or can make routing decisions.

When a network operator creates a ROA for a n ation of origin AS and prefix, this will have an effect on the RPKI validity of one or more route announcements.

They can be: • VALID o The route announcement is covered by at least one ROA • INVALID o The prefix is announced from an orised AS o The announcement is more specific than is allowed by the maximum length set in a ROA that s the prefix and AS • UNKNOWN o The prefix in this announcement is not covered (or only partially covered) by an existing ROA The Resource Certification (RPKI) system ts of two parts: 1. Network operators use their certificates to create Route Origin Authorisations (ROAs), stating from which Autonomous Systems their prefixes will be originated and what the maximum allowed prefix length is 2. Other network operators can set their routing preferences based on the RPKI validity of route announcements when compared to the ROAs that were created Please note that the current RPKI onality solely offers origin tion.

However, it lays the foundation to offering true Secure BGP, including path validation. Work on creating the standards for this are currently being developed in the IETF.

RPKI XML is the method used to provide cryptographically valid routing information. At time time of submission of this patent application, RPKI XML is used for validation of addresses assigned by the RIR to the AS number of the ISP for purposes of BGP routing decisions. The unique and non-obvious difference is shown in the drawings.

CONCLUSION Depending on the embodiment, certain acts, , or functions may be substituted by e who is sufficiently skilled in the art.

Conditional language used herein, such as, among others, "can," "might," "may," "e.g.," and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that n embodiments include, while other embodiments do not include, n features, elements and/or states. Thus, such conditional language is not generally intended to imply that features, elements and/or states are in any way ed for one or more embodiments or that one or more embodiments arily include logic for deciding, with or without author input or prompting, whether these features, elements and/or states are included or are to be med in any particular ment. The terms "comprising," "including," "having," and the like are synonymous and are used inclusively, in an open-ended n, and do not exclude additional elements, features, acts, operations, and so forth. Also, the term "or" is used in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term "or" means one, some, or all of the elements in the list.

While the above detailed description has shown, described, and pointed out novel features as applied to various embodiments, it will be understood that various omissions, substitutions, and changes in the form and details of the devices or thms illustrated can be made without departing from the spirit of the disclosure. As will be ized, certain embodiments of the inventions described herein can be embodied within a form that does not provide all of the features and benefits set forth herein, as some features can be used or practiced separately from . No element or feature is necessary or indispensable to each embodiment. The scope of certain inventions disclosed herein is indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims (20)

It is claimed that:

1. A method for achieving seamless transition of IPv4 ses to IPv6 addresses, the method comprising: deploying at least an IPv6 address holding an IPv4 address and the IPv6 address simultaneously for allocating at least the IPv4 address with an IPv6 address register g the IPv6 address, and a software library call available for the IPv4 address is configured to utilize the IPv6 address register; ing at least an application utilizing the software library call available for the IPv4 s to utilize the software library call available for the IPv6 address; enabling the IPv6 address to at least one customer in the k, n the IPv6 address maintains an IPv4 address register holding the IPv4 address along, after migration, transition of the IPv4 address to the IPv6 address and routing of the data and calls based on the transition achieved.

2. The method as claimed in claim 1, wherein the software library call for IPv4 address comprises "gethostbyaddress32" call, and the software library call for the IPv6 address comprises "gethostbyaddress128" call.

3. The method as claimed in claim 2, wherein "gethostbyaddress128" call and "gethostbyaddress32" call es the IPv6 register.

4. The method as claimed in claim 1, wherein upon migration, the IPv4 address is available for re-use and/or reallocation to at least a new customer available in the network.

5. The method as claimed in claim 1, wherein upon migration, further comprises using both "gethostbyaddress32" (IPv4) and "gethostbyaddress128" (IPv6) library call.

6. The method as d in claim 1, wherein the IPv6 address holds the IPv4 address er and the IPv6 address register simultaneously.

7. The method as claimed in claim 1, further comprises routing the data calls based on the transition achieved.

8. The method as claimed in claim 1, before migrating, the method further comprises: differentiating which applications or databases hosted by the customer based on utilization of the IPv4 software library call or the IPv6 software library call to service calls to e a host name by address; and providing a list of applications or databases to the customer that highlight which applications or databases may be transitioned to use the IPv6 address.

9. A method for achieving ss transition of IPv4 addresses to IPv6 addresses, the method comprising: detecting, by an Internet Service Provider (ISP), one or more IPv4 addresses and one or more IPv6 addresses available for allocation to at least one er in the network; maintaining an IPv4 address register and an IPv6 address register for the IPv4 addresses and the IPv6 addresses detected; allocating the IPv4 address and the IPv6 s at a defined portion of an address field of an IPv6 packet header; matching the IPv4 s registers and IPv6 address registers, available on the network at the same time, based on a software library call available on the IPv6 address thereby enabling the IPv4 address registers to use the IPv6 address; migrating at least an application utilizing a software library call available in the IPv4 address to utilize the IPv6 address and a software library call available in the IPv6 address, to achieve transition of the IPv4 addresses to the IPv6 address; and routing the data and/or calls based on the transition achieved.

10. The method of claim 9, wherein, ng further ses allocating a software library call available in the IPv4 address to the IPv6 s er d and thereby removing the IPv4 address register from the IPv4 address.

11. The method of claim 9, wherein matching the IPv4 s registers and IPv6 address registers is based on "gethostbyname32" call.

12. The method of claim 9, wherein, migrating r comprises the software library call, "gethostbyaddress32" call, available in the IPv4 address to utilize the IPv6 s and the software library call, "gethostbyaddress128" call available in the IPv6 address.

13. The method of claim 9, wherein, migrating further comprises allocating, based at least on a routing information, the software library call, "gethostbyaddress32" call, of the IPv4 address to the IPv6 address register, and thereby de-allocating the IPv4 address register.

14. The method of claim 9, wherein, migrating further comprises recompiling at least a source code of the application to utilize the software library call, "gethostbyaddress128" call, available on the IPv6 address.

15. The method of claim 9, r comprises routing based on at least a routing information provided by broadcasting permissible routes to at least an autonomous system (AS) numbers, wherein the permissible routes utilizes a private instance of a Resource Key Public Infrastructure to broadcast the routing information pertaining to the transition achieved to a Regional Internet Registrar.

16. The method of claim 9, wherein, ing the application to utilize the software y call available on the IPv6 s, comprises: recompiling a source code of the application to the software library call available on the IPv6 address provided by an operating system (OS); and substituting using a direct binary tution.

17. The method of claim 9, further comprises: using the IPv4 software library call to e the host name by address for applications that only support IPv4 addressing; and using the IPv6 software library call to provide the host name by address for applications that support IPv6 addressing.

18. The method as claimed in claim 9, before migrating, the method further comprises: differentiating which applications or ses hosted by the customer based on utilization of the IPv4 software library call or the IPv6 software y call to service calls to provide a host name by address; and providing a list of applications or databases to the customer that highlight which ations or databases may be transitioned to use the IPv6 address.

19. A method for achieving seamless transition of IPv4 addresses to IPv6 addresses, the method comprising: allocating one or more IPv4 addresses and one or more IPv6 ses at same time with a gethostbyname32 pointing to an IPv4 register and a gethostbyname128 pointing to an IPv6 er; changing the gethostbyname32 library calls to specifically access the IPv6 register and de-allocating the IPv4 register; and migrating at least an application utilizing the gethostbyname32, a re library call, to utilize the gethostbyname128, a software library call, to achieve transition of the IPv4 addresses to the IPv6 addresses.

20. The method as claimed in claim 19, r comprises allocating the software library call to the IPv4 address register and the IPv6 address er by pointing a gethostbyname32, the software library call, to the IPv4 register, and a gethostbyname128, the software library call, to the IPv6 register.