NZ736418B2 - System and method for ipv4 to ipv6 transition rather than an outage - Google Patents
System and method for ipv4 to ipv6 transition rather than an outage Download PDFInfo
- Publication number
- NZ736418B2 NZ736418B2 NZ736418A NZ73641816A NZ736418B2 NZ 736418 B2 NZ736418 B2 NZ 736418B2 NZ 736418 A NZ736418 A NZ 736418A NZ 73641816 A NZ73641816 A NZ 73641816A NZ 736418 B2 NZ736418 B2 NZ 736418B2
- Authority
- NZ
- New Zealand
- Prior art keywords
- ipv6
- ipv4
- address
- call
- software library
- Prior art date
Links
- 230000005012 migration Effects 0.000 claims 3
- 238000006467 substitution reaction Methods 0.000 description 7
- 238000010200 validation analysis Methods 0.000 description 7
- 230000002457 bidirectional Effects 0.000 description 6
- 239000000243 solution Substances 0.000 description 6
- 241000416915 Roa Species 0.000 description 5
- 238000005516 engineering process Methods 0.000 description 5
- 238000000034 method Methods 0.000 description 5
- 230000000694 effects Effects 0.000 description 4
- 238000011084 recovery Methods 0.000 description 4
- 101700006178 ARIN Proteins 0.000 description 2
- 210000004209 Hair Anatomy 0.000 description 2
- 210000003491 Skin Anatomy 0.000 description 2
- 238000004891 communication Methods 0.000 description 2
- 150000002500 ions Chemical class 0.000 description 2
- 238000002955 isolation Methods 0.000 description 2
- XKQBJDHJRVDQBU-DHLVSJIASA-N 5-[(3aS,5R,6R,6aS)-6-[(E,3S)-7-(3-azidophenyl)-3-hydroxyhept-1-enyl]-5-hydroxy-1,3a,4,5,6,6a-hexahydropentalen-2-yl]pentanoic acid Chemical compound C([C@H](O)\C=C\[C@@H]1[C@H]2CC(CCCCC(O)=O)=C[C@H]2C[C@H]1O)CCCC1=CC=CC(N=[N+]=[N-])=C1 XKQBJDHJRVDQBU-DHLVSJIASA-N 0.000 description 1
- 241000238876 Acari Species 0.000 description 1
- 240000003139 Ferula foetida Species 0.000 description 1
- 241000079527 Ziziphus spina-christi Species 0.000 description 1
- 235000012970 cakes Nutrition 0.000 description 1
- 230000002860 competitive Effects 0.000 description 1
- 230000002708 enhancing Effects 0.000 description 1
- 210000003702 immature single positive T cell Anatomy 0.000 description 1
- 239000004615 ingredient Substances 0.000 description 1
- 238000009114 investigational therapy Methods 0.000 description 1
- 239000012086 standard solution Substances 0.000 description 1
- ATJFFYVFTNAWJD-UHFFFAOYSA-N tin hydride Chemical compound [Sn] ATJFFYVFTNAWJD-UHFFFAOYSA-N 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
- G06F15/163—Interprocessor communication
- G06F15/173—Interprocessor communication using an interconnection network, e.g. matrix, shuffle, pyramid, star, snowflake
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
-
- H04L29/12349—
-
- H04L29/12358—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/52—Multiprotocol routers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/74—Address processing for routing
- H04L45/741—Routing in networks with a plurality of addressing schemes, e.g. with both IPv4 and IPv6
-
- H04L61/2007—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
- H04L61/251—Translation of Internet protocol [IP] addresses between different IP versions
-
- H04L61/6086—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/167—Adaptation for transition between two IP versions, e.g. between IPv4 and IPv6
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)
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.
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/658,241 US9479475B1 (en) | 2014-03-17 | 2015-03-16 | System and method for IPv4 to IPv6 transition rather than an outage |
US14/658,241 | 2015-03-16 | ||
PCT/US2016/022265 WO2016149172A1 (en) | 2015-03-16 | 2016-03-14 | System and method for ipv4 to ipv6 transition rather than an outage |
Publications (2)
Publication Number | Publication Date |
---|---|
NZ736418A NZ736418A (en) | 2021-01-29 |
NZ736418B2 true NZ736418B2 (en) | 2021-04-30 |
Family
ID=
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN113950816B (en) | System and method for providing a multi-cloud micro-service gateway using a side car agency | |
US11502994B2 (en) | Intelligent service layer for separating application from physical networks and extending service layer intelligence over IP across the internet, cloud, and edge networks | |
US9813303B1 (en) | Enabling cross-realm authentication between tenant and cloud service provider | |
US10135827B2 (en) | Secure access to remote resources over a network | |
US20170214669A1 (en) | System and method for providing key-encrypted storage in a cloud computing environment | |
US20150082378A1 (en) | System and method for enabling scalable isolation contexts in a platform | |
US20130145000A1 (en) | Method and system for provisioning devices in a user network identity address provisioning server | |
US20080320303A1 (en) | Vpn processing via service insertion architecture | |
US20190104172A1 (en) | Web storage based iot device protect mechanism | |
AU2018216671B2 (en) | Service endpoint interconnect in a virtual private gateway | |
AU2016233552B2 (en) | System and method for IPv4 to IPv6 transition rather than an outage | |
US11895085B2 (en) | Identifier locator addressing for IPV6-based software defined fabric | |
US20240195790A1 (en) | Centralized management of private networks | |
US20150381387A1 (en) | System and Method for Facilitating Communication between Multiple Networks | |
NZ736418B2 (en) | System and method for ipv4 to ipv6 transition rather than an outage | |
Chun et al. | Slice creation and management | |
Cabianca | Implementing Hybrid Connectivity | |
Kang et al. | Blockchain-Based Implementation of Service Function Chains in Multicloud and Multitenant Environments Over Containerized Networks |