{"id":1828,"date":"2017-02-08T22:33:00","date_gmt":"2017-02-08T22:33:00","guid":{"rendered":"https:\/\/live-infoblox-blog.pantheonsite.io\/?p=1828"},"modified":"2020-05-06T10:28:01","modified_gmt":"2020-05-06T17:28:01","slug":"even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3","status":"publish","type":"post","link":"https:\/\/www.infoblox.com\/blog\/ipv6-coe\/even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3\/","title":{"rendered":"Even More Methods of Providing IPv4 as a Service (IPv4aaS) (Part 3)"},"content":{"rendered":"

In the\u00a0first part of this blog series<\/a>\u00a0we covered the rationale behind why organizations may prefer to run a single-protocol IPv6-only core.\u00a0 However, service providers must continue to provide service to subscribers who have legacy IPv4-only devices.\u00a0 The\u00a0second part of the blog<\/a>\u00a0delved into several ways ISPs can create an IPv4 as a Service offering without subscribers even realizing.\u00a0 In part 2 we covered GRE, DS-Lite, Lightweight 4over6 (an adaptation of DS-Lite), and the obscure Public 4over6 method. \u00a0In this third and final blog in this three-part-series, we will cover the remaining techniques that service providers are actively deploying for their IPv4 as a Service.<\/p>\n

NAT64\/DNS64<\/h2>\n

When organizations consider their options for using an IPv6-only core network to facilitate legacy IPv4 applications, they frequently turn to\u00a0NAT64 and DNS64<\/a>.\u00a0 These are\u00a0two different functions that cooperat<\/a>e\u00a0to enable an IPv6-only node to reach IPv4-only services.\u00a0 The IETF has standardized these two methods in \u201cStateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers\u201d (RFC 6146<\/a>) and \u201cDNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers\u201d (RFC 6147<\/a>).\u00a0 The IETF has also published \u201cNAT64 Deployment Options and Experience\u201d (RFC 7269<\/a>).<\/p>\n

The way this works is that an IPv6-only node sends a DNS query for the IPv4-only service it wishes to reach. Next, the NAT64 proxy function performs the IPv4 DNS resolution and returns an IPv6 address with the IPv4 destination embedded within.\u00a0 This typically uses the IPv6 prefix 64:ff9b::\/96 (RFC 6052<\/a>) where, for example, a query for b.resolvers.Level3.net results in 4.2.2.2 which then becomes 64:ff9b::0402:0202.\u00a0 The IPv6 node then initiates an IPv6 connection to the 64:ff9b::0402:0202 address. Next, the NAT64 service intercepts this and changes the connection to an IPv4 connection to the embedded 4.2.2.2 destination.\u00a0 The NAT64 function then brokers a stateful connection from that IPv6-only node to that IPv4-only service.\u00a0 Furthermore, native IPv6 connections completely bypass these NAT64 and DNS64 functions and are directly forwarded to the Internet natively.<\/p>\n

The DNS64 function and NAT64 function can be provided by separate systems.\u00a0 An\u00a0Infoblox NIOS<\/a>\u00a0appliance can perform the DNS64 function and forming the IPv6 DNS response.\u00a0 Large-scale routers and translation systems, such as those from\u00a0A10 Networks<\/a>, can operate as the NAT64 router.\u00a0 Because the NAT64 function is stateless, the router does not need to maintain a state table of all current client connections.\u00a0 The IPv6 address of the source client uniquely identifies that client.\u00a0 The IPv4 address embedded within the IPv6 address offers enough breadcrumbs to help it find the IPv4-only target server.\u00a0 An enterprise could establish a NAT64\/DNS64 service at a much smaller scale than a service provider would construct.<\/p>\n

This sounds great, but there are some disadvantages.\u00a0 For example, NAT64 only works for applications that begin with a DNS lookup and it breaks applications using IPv4 addresses in the URL (embedded literals) (e.g.\u00a0http:\/\/192.168.1.1\/index.html<\/a>) or when applications make direct IPv4 socket connections.\u00a0 NAT64 also doesn\u2019t work for domain names that have IPv4-only DNSSEC signed domains.\u00a0 Furthermore, approximately 15% of applications break with IPv6 native or break with NAT64: e.g., applications such as Spotify, WhatsApp, Skype, SIP, RTSP, H.323, XMPP peer to peer, (among other\u00a0NAT64-breakage<\/a>\u00a0occurrences).\u00a0 NAT64 and DNS64 are also not suitable to the IPv4-only systems that might exist in broadband subscribers\u2019 homes.\u00a0 These IPv4-only devices can only perform DNS lookups exclusively over IPv4 and would not be able to interact with a DNS64 service, which is the linchpin to the whole system\u2019s functionality.<\/p>\n

464XLAT<\/h2>\n

It is evident that many of these IPv4aaS methods use some form of translation (XLAT for short).\u00a0 The IETF produced an architecture for carrying IPv4 packets across an IPv6-only network and called it \u201c464XLAT: Combination of Stateful and Stateless Translation\u201d (RFC 6877<\/a>).\u00a0 464XLAT leverages\u00a0RFC 6146<\/a>\u00a0(see the above section on NAT64) and\u00a0RFC 6145<\/a>\u00a0(now\u00a0RFC 7915<\/a>) to create an IPv4 as a Service. 464XLAT may optionally use DNS64, but it is also designed to work without that function.<\/p>\n

464XLAT uses a customer-side translator (CLAT) and a provider-side translator (PLAT). As a result, IPv4 packets are double-translated along their journey to the Internet.\u00a0 464XLAT uses the same\u00a0RFC 6052<\/a>\u00a064:ff9b::\/96 IPv6 prefix as DNS64\/NAT64.\u00a0 Like NAT64\/DNS64, 464XLAN is an IPv4 service extension method that works for client-server connections and is not suited to IPv6 peer-to-peer communication.<\/p>\n

464XLAT has had some traction from carriers and mobile providers like\u00a0T-Mobile<\/a>\u00a0and is available on\u00a0Android<\/a>\u00a0and\u00a0Windows<\/a>\u00a0mobile devices.<\/p>\n

Mapping of Address and Port (MAP)<\/h2>\n

Another IPv4aaS mechanism is\u00a0Mapping of Address and Port<\/a>\u00a0(MAP).\u00a0 The MAP architecture has a MAP Customer Edge (CE) device at the subscriber\u2019s location and a MAP Border Relay (BR) within the ISP network.\u00a0 MAP domains are groupings of CEs and BRs that have a common policy, address prefixes, and mapping rules configuration.\u00a0 MAP provides a stateless algorithmic mapping of an IPv6 prefix to an IPv4 address plus port range.\u00a0 This method leverages the \u201cThe Address plus Port (A+P) Approach to the IPv4 Address Shortage\u201d (RFC 6346<\/a>) method of combining the 32-bit IPv4 address with the 16-bit TCP\/UDP port space resulting in a 48-bit address space.\u00a0 One of the key benefits of MAP is that it doesn\u2019t require a stateful central CGN\/LAN translation system, which greatly increases its scalability.<\/p>\n

MAP comes in two forms: \u201cMapping of Address and Port with Encapsulation (MAP-E)\u201d (RFC 7597<\/a>), and \u201cMapping of Address and Port using Translation (MAP-T)\u201d (RFC 7599<\/a>).\u00a0 The MAP-E method encapsulates the IPv4 packets in IPv6 packets using the technique found in the RFC Generic Packet Tunneling in IPv6 (RFC 2473<\/a>).\u00a0 MAP-E may be preferred by a service provider that does not control the customer CPE hardware or its software.\u00a0 MAP-T method translates the IPv4 header fields into the\u00a0IPv6 header fields<\/a>\u00a0using Stateless IP\/ICMP Translation (SIIT) (RFC 7915<\/a>).\u00a0 MAP-T may be preferred by a service provider that offers a managed modem\/router service and can customize the CPE so that it maintains the client connection state.\u00a0 At the\u00a0North American IPv6 Summit 2015<\/a>, Jordan Gottlieb of Charter Communications gave an excellent presentation titled \u201cMapping of Address and Port (MAP) an ISPs Perspective<\/a>\u201d that covers how MAP-E and MAP-T work.<\/p>\n

MAP is gaining traction in the industry and has significant adoption momentum.\u00a0 The IETF is continuing its work on MAP and has documented\u00a0MAP Deployment Considerations<\/a>.\u00a0 Vendors like\u00a0Cisco<\/a>\u00a0and\u00a0A10 Networks<\/a>\u00a0have deployed MAP into their service-provider class products.\u00a0 Service providers are experimenting and deploying MAP in their environments.\u00a0 For example, China Education and Research Network (CERNET) is also\u00a0working on an IPv4aaS design<\/a>\u00a0that uses IVI\/MAP-T.<\/p>\n

4rd<\/h2>\n

Another recent addition to these IPv4aaS mechanisms has been documented in the IETF RFC titled \u201cIPv4 Residual Deployment via IPv6 – A Stateless Solution (4rd)\u201d (RFC 7600<\/a>). \u00a0This technique is a reversal of the old IPv6 deployment method defined in the IETF RFC titled \u201cIPv6 Rapid Deployment on IPv4 Infrastructures (6rd) Protocol Specification\u201d (RFC 5969<\/a>).\u00a0 The idea here is that TCP and UDP payloads can be carried in IPv4 or IPv6 packets.\u00a0 Legacy IPv4 packets could just have their payload stripped out and then carried in an IPv6 packet across an IPv6-only core network, reversing the process at the ISP\u2019s Internet edge.\u00a0 This would provide a stateless method that also leverages the Address plus Port (A+P) approach detailed in\u00a0RFC 6346<\/a>.\u00a0 This method required a customized Customer Edge (CE) device with the 4rd functions in it and a Border Relay (BR) in the ISP network that performs the 4rd\u00a0NAT64<\/a>+ function.<\/p>\n

Stateless IP\/ICMP Translation for IPv6 Data Center Environments (SIIT-DC)<\/h2>\n

The above-mentioned techniques have been focused on providing IPv4 services to subscribers.\u00a0 However, these same techniques can be applied in a data center environment where there are legacy IPv4 servers or virtual machines connected to an IPv6-only data center core.\u00a0 To support this concept, the IETF has published \u201cSIIT-DC: Stateless IP\/ICMP Translation for IPv6 Data Center Environments\u201d (RFC 7755<\/a>).\u00a0 SIIT-DC leverages the IETF standard IPv6 Addressing of IPv4\/IPv6 Translators (RFC 6052<\/a>) to perform Explicit Address Mapping (EAM) of the server\u2019s IPv4 address to its IPv6 address.\u00a0 An alternative address translation technique is documented in the IETF draft titled \u201cExplicit Address Mappings for Stateless IP\/ICMP Translation<\/a>\u201d.\u00a0 The breadcrumb of the embedded IPv4 address allow for the SIIT-DC Border Relay (BR) function to be stateless.\u00a0 Also, the Explicit Address Mapping (EAM) algorithm has been documented in\u00a0RFC 7757<\/a>\u00a0and the Stateless IP\/ICMP Translation (SSIT) algorithm has been updated by\u00a0RFC 7915<\/a>.<\/p>\n

A good explanation of this IPv4aaS method was presented at\u00a0RIPE69<\/a>\u00a0in 2014 by Tore Anderson \u201cSIIT-DC: IPv4 Service Continuity for IPv6 Data Centres<\/a>\u201d.<\/p>\n

There is a complementary standard titled \u201cStateless IP\/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode\u201d (RFC 7756<\/a>).\u00a0 This standard defines a SIIT-DC Edge Relay (ER) that is close to the IPv4-only system and reverses the packet translation function of the SIIT-DC Border Relay (BR).\u00a0 This ER makes the application or server perceive the IPv4 communications as native.<\/p>\n

Locator\/ID Separation Protocol (LISP)<\/h2>\n

LISP<\/a>\u00a0(RFC 6830<\/a>) is a network architecture and protocol that separates the namespaces used in IP addresses that represent the network\u2019s location and that of the endpoint attached to that network. By separating the two namespaces (Routing Locators (RLOCs) and Endpoint Identifiers (EIDs)) this creates a level of abstraction that facilitates mobility, deals with address exhaustion, adds scalability of routing tables, and handles traffic engineering.\u00a0 LISP is a map and encapsulation (map and encap) protocol that uses a mapping and control function to provide abstraction by using UDP port 4342. It then encapsulates data packets using UDP port 4341.\u00a0 LISP works with both IP versions and can provide portability and coexistence, easing the transition to IPv6.\u00a0 The advantage of LISP is that it doesn\u2019t require any changes to the end-user client.\u00a0 The disadvantages of LISP are the latency of the mapping and control plane function and the fact that it is a tunneling method.\u00a0 The\u00a0IETF LISP working group<\/a>\u00a0is continuing to evolve this protocol.<\/p>\n

The encapsulation mechanism in LISP could be used to carry the packets of one IP version in the same or different IP version.\u00a0\u00a0LISP<\/a>\u00a0could be used to carry IPv4 packets \u201cOver the ToP<\/a>\u00a0(OTP)\u201d of anan underlay IPv6-only service provider network .\u00a0 The mapping and control mechanisms in\u00a0LISP could direct these packets<\/a>\u00a0to the closest Internet egress point to minimize the backhaul latency commonly seen in IPv4aaS methods.\u00a0\u00a0Presentations from Brian Field at Comcast<\/a>\u00a0indicate that they are considering using LISP and MAP with OpenStack and SDN to create their IPv4aaS solution.<\/p>\n

DNS Forwarding and IPv4aaS<\/h2>\n

DNS is a critical component to making the Internet and network applications function properly and IPv4aaS services offer no exception to this rule.\u00a0 From the description of the IPv4aaS methods described above, NAT takes place either at the CPE or in the ISP infrastructure and this may pose a risk to proper DNS operations.<\/p>\n

Our friends from Comcast John Jason Brzozowski and Paul Ebersman (an Infoblox alum) created this IETF draft titled \u201cDNS Forwarding and IPv4aaS<\/a>\u201c that describes these risks.\u00a0 For example, older Microsoft XP and Server 2003 systems are only capable of performing DNS queries over IPv4 transport.\u00a0 Translation of the DNS queries can cause problems for geolocation and may increase latency of connections due to slow query responses.<\/p>\n

The draft also lists recommendations and best practices such as: using dual-protocol DNS servers, ensuring subscribers have dual-protocol connectivity, making sure hosts prefer DNS over IPv6 transport, and making sure DNS queries are not modified as a result of translation functions.<\/p>\n

Summary:<\/h2>\n

Today, it may be nearly impossible to go\u00a0IPv6-only in a home network<\/a>.\u00a0 We all have embedded devices in our possession that are IPv4-only.\u00a0 However, every year IPv6-capable devices are replacing these old IPv4-only devices and more subscriber connections are becoming dual-protocol.\u00a0 Even enterprises would want to consider how they could\u00a0benefit from constructing an IPv6-only infrastructure<\/a>.\u00a0 At the scale of the large service provider\u2019s networks, the advantages of running a single-protocol core are significant.<\/p>\n

Most of these IPv4aaS techniques tunnel IPv4 packets within IPv6 packets and we have all observed time and again that tunneling techniques are not optimal:\u00a0 The downsides of any type of tunneling include issues with packet MTU, fragmentation, security, as well as operational troubleshooting burden.\u00a0 As more and more subscriber IPv4 packets are tunneled, the end-user-experience will deteriorate making native end-to-end IPv6 perform better and become the preferred transport protocol.<\/p>\n

Most of these IPv4aaS techniques also perform translation of IPv4 addresses.\u00a0 Translation is also a sub-optimal transition mechanism and as the movie title reaffirms, something is always\u00a0Lost in Translation<\/a>.\u00a0 For instance, the IPv4 header and addressing format do not easily map to the IPv6 header and addressing format.\u00a0 The IPv4aaS methods that require translation could cause negative subscriber experiences.<\/p>\n

The mechanisms that are taking place within an IPv4aaS offering disprove the adage that \u201cwhat you don\u2019t know, can\u2019t hurt you\u201d.\u00a0 The sum of these issues provide weight to the case that the only viable near-term and long-term strategy is to deploy IPv6 and move quickly to IPv6-only.<\/p>\n","protected":false},"excerpt":{"rendered":"

In the\u00a0first part of this blog series\u00a0we covered the rationale behind why organizations may prefer to run a single-protocol IPv6-only core.\u00a0 However, service providers must continue to provide service to subscribers who have legacy IPv4-only devices.\u00a0 The\u00a0second part of the blog\u00a0delved into several ways ISPs can create an IPv4 as a Service offering without subscribers […]<\/p>\n","protected":false},"author":321,"featured_media":1803,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"_genesis_hide_title":false,"_genesis_hide_breadcrumbs":false,"_genesis_hide_singular_image":false,"_genesis_hide_footer_widgets":false,"_genesis_custom_body_class":"","_genesis_custom_post_class":"","_genesis_layout":"","footnotes":""},"categories":[17],"tags":[56,38,31,39],"class_list":{"0":"post-1828","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-ipv6-coe","8":"tag-ipv4","9":"tag-ipv6","10":"tag-networking","11":"tag-protocols","12":"entry"},"acf":[],"yoast_head":"\nEven More Methods of Providing IPv4 as a Service (IPv4aaS) (Part 3)<\/title>\n<meta name=\"description\" content=\"In the first part of this blog series we covered the rationale behind why organizations may prefer to run a single-protocol IPv6-only core.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.infoblox.com\/blog\/ipv6-coe\/even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Even More Methods of Providing IPv4 as a Service (IPv4aaS) (Part 3)\" \/>\n<meta property=\"og:description\" content=\"In the first part of this blog series we covered the rationale behind why organizations may prefer to run a single-protocol IPv6-only core.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.infoblox.com\/blog\/ipv6-coe\/even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3\/\" \/>\n<meta property=\"og:site_name\" content=\"Infoblox Blog\" \/>\n<meta property=\"article:published_time\" content=\"2017-02-08T22:33:00+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2020-05-06T17:28:01+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.infoblox.com\/blog\/wp-content\/uploads\/142079357-660x454-1.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"660\" \/>\n\t<meta property=\"og:image:height\" content=\"454\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Scott Hogg\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Scott Hogg\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"11 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/ipv6-coe\\\/even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/ipv6-coe\\\/even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3\\\/\"},\"author\":{\"name\":\"Scott Hogg\",\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/#\\\/schema\\\/person\\\/ee71ac61fe2ea349f6e991e628d22f4c\"},\"headline\":\"Even More Methods of Providing IPv4 as a Service (IPv4aaS) (Part 3)\",\"datePublished\":\"2017-02-08T22:33:00+00:00\",\"dateModified\":\"2020-05-06T17:28:01+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/ipv6-coe\\\/even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3\\\/\"},\"wordCount\":2224,\"publisher\":{\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/ipv6-coe\\\/even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/wp-content\\\/uploads\\\/142079357-660x454-1.jpg\",\"keywords\":[\"IPv4\",\"IPv6\",\"Networking\",\"Protocols\"],\"articleSection\":[\"IPv6 CoE\"],\"inLanguage\":\"en-US\"},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/ipv6-coe\\\/even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3\\\/\",\"url\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/ipv6-coe\\\/even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3\\\/\",\"name\":\"Even More Methods of Providing IPv4 as a Service (IPv4aaS) (Part 3)\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/ipv6-coe\\\/even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/ipv6-coe\\\/even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/wp-content\\\/uploads\\\/142079357-660x454-1.jpg\",\"datePublished\":\"2017-02-08T22:33:00+00:00\",\"dateModified\":\"2020-05-06T17:28:01+00:00\",\"description\":\"In the first part of this blog series we covered the rationale behind why organizations may prefer to run a single-protocol IPv6-only core.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/ipv6-coe\\\/even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/ipv6-coe\\\/even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/ipv6-coe\\\/even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/wp-content\\\/uploads\\\/142079357-660x454-1.jpg\",\"contentUrl\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/wp-content\\\/uploads\\\/142079357-660x454-1.jpg\",\"width\":660,\"height\":454},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/ipv6-coe\\\/even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"IPv6 CoE\",\"item\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/category\\\/ipv6-coe\\\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"Even More Methods of Providing IPv4 as a Service (IPv4aaS) (Part 3)\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/#website\",\"url\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/\",\"name\":\"infoblox.com\\\/blog\\\/\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/#organization\",\"name\":\"Infoblox\",\"url\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/wp-content\\\/uploads\\\/infoblox-logo-2.svg\",\"contentUrl\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/wp-content\\\/uploads\\\/infoblox-logo-2.svg\",\"width\":137,\"height\":30,\"caption\":\"Infoblox\"},\"image\":{\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/#\\\/schema\\\/logo\\\/image\\\/\"}},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/#\\\/schema\\\/person\\\/ee71ac61fe2ea349f6e991e628d22f4c\",\"name\":\"Scott Hogg\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/blogs.infoblox.com\\\/wp-content\\\/uploads\\\/avatar_user_321_1574118215-96x96.jpg\",\"url\":\"https:\\\/\\\/blogs.infoblox.com\\\/wp-content\\\/uploads\\\/avatar_user_321_1574118215-96x96.jpg\",\"contentUrl\":\"https:\\\/\\\/blogs.infoblox.com\\\/wp-content\\\/uploads\\\/avatar_user_321_1574118215-96x96.jpg\",\"caption\":\"Scott Hogg\"},\"description\":\"Scott Hogg has 30 years of network and security experience and is president of Hogg Networking with. Scott Hogg specializes in teaching Internet Protocol version 6 (IPv6) and providing implementation guidance. Scott is CCIE #5133 (Emeritus) and CISSP #4610. Scott is Chair Emeritus of the Rocky Mountain IPv6 Task Force (RMv6TF), a member of the IPv6 Center of Excellence (COE), and co-author of the Cisco Press book on IPv6 Security.\",\"sameAs\":[\"https:\\\/\\\/hexabuild.io\"],\"url\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/author\\\/scott-hogg\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Even More Methods of Providing IPv4 as a Service (IPv4aaS) (Part 3)","description":"In the first part of this blog series we covered the rationale behind why organizations may prefer to run a single-protocol IPv6-only core.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.infoblox.com\/blog\/ipv6-coe\/even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3\/","og_locale":"en_US","og_type":"article","og_title":"Even More Methods of Providing IPv4 as a Service (IPv4aaS) (Part 3)","og_description":"In the first part of this blog series we covered the rationale behind why organizations may prefer to run a single-protocol IPv6-only core.","og_url":"https:\/\/www.infoblox.com\/blog\/ipv6-coe\/even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3\/","og_site_name":"Infoblox Blog","article_published_time":"2017-02-08T22:33:00+00:00","article_modified_time":"2020-05-06T17:28:01+00:00","og_image":[{"width":660,"height":454,"url":"https:\/\/www.infoblox.com\/blog\/wp-content\/uploads\/142079357-660x454-1.jpg","type":"image\/jpeg"}],"author":"Scott Hogg","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Scott Hogg","Est. reading time":"11 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.infoblox.com\/blog\/ipv6-coe\/even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3\/#article","isPartOf":{"@id":"https:\/\/www.infoblox.com\/blog\/ipv6-coe\/even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3\/"},"author":{"name":"Scott Hogg","@id":"https:\/\/www.infoblox.com\/blog\/#\/schema\/person\/ee71ac61fe2ea349f6e991e628d22f4c"},"headline":"Even More Methods of Providing IPv4 as a Service (IPv4aaS) (Part 3)","datePublished":"2017-02-08T22:33:00+00:00","dateModified":"2020-05-06T17:28:01+00:00","mainEntityOfPage":{"@id":"https:\/\/www.infoblox.com\/blog\/ipv6-coe\/even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3\/"},"wordCount":2224,"publisher":{"@id":"https:\/\/www.infoblox.com\/blog\/#organization"},"image":{"@id":"https:\/\/www.infoblox.com\/blog\/ipv6-coe\/even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3\/#primaryimage"},"thumbnailUrl":"https:\/\/www.infoblox.com\/blog\/wp-content\/uploads\/142079357-660x454-1.jpg","keywords":["IPv4","IPv6","Networking","Protocols"],"articleSection":["IPv6 CoE"],"inLanguage":"en-US"},{"@type":"WebPage","@id":"https:\/\/www.infoblox.com\/blog\/ipv6-coe\/even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3\/","url":"https:\/\/www.infoblox.com\/blog\/ipv6-coe\/even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3\/","name":"Even More Methods of Providing IPv4 as a Service (IPv4aaS) (Part 3)","isPartOf":{"@id":"https:\/\/www.infoblox.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.infoblox.com\/blog\/ipv6-coe\/even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3\/#primaryimage"},"image":{"@id":"https:\/\/www.infoblox.com\/blog\/ipv6-coe\/even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3\/#primaryimage"},"thumbnailUrl":"https:\/\/www.infoblox.com\/blog\/wp-content\/uploads\/142079357-660x454-1.jpg","datePublished":"2017-02-08T22:33:00+00:00","dateModified":"2020-05-06T17:28:01+00:00","description":"In the first part of this blog series we covered the rationale behind why organizations may prefer to run a single-protocol IPv6-only core.","breadcrumb":{"@id":"https:\/\/www.infoblox.com\/blog\/ipv6-coe\/even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.infoblox.com\/blog\/ipv6-coe\/even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.infoblox.com\/blog\/ipv6-coe\/even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3\/#primaryimage","url":"https:\/\/www.infoblox.com\/blog\/wp-content\/uploads\/142079357-660x454-1.jpg","contentUrl":"https:\/\/www.infoblox.com\/blog\/wp-content\/uploads\/142079357-660x454-1.jpg","width":660,"height":454},{"@type":"BreadcrumbList","@id":"https:\/\/www.infoblox.com\/blog\/ipv6-coe\/even-more-methods-of-providing-ipv4-as-a-service-ipv4aas-part-3\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.infoblox.com\/blog\/"},{"@type":"ListItem","position":2,"name":"IPv6 CoE","item":"https:\/\/www.infoblox.com\/blog\/category\/ipv6-coe\/"},{"@type":"ListItem","position":3,"name":"Even More Methods of Providing IPv4 as a Service (IPv4aaS) (Part 3)"}]},{"@type":"WebSite","@id":"https:\/\/www.infoblox.com\/blog\/#website","url":"https:\/\/www.infoblox.com\/blog\/","name":"infoblox.com\/blog\/","description":"","publisher":{"@id":"https:\/\/www.infoblox.com\/blog\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.infoblox.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/www.infoblox.com\/blog\/#organization","name":"Infoblox","url":"https:\/\/www.infoblox.com\/blog\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.infoblox.com\/blog\/#\/schema\/logo\/image\/","url":"https:\/\/www.infoblox.com\/blog\/wp-content\/uploads\/infoblox-logo-2.svg","contentUrl":"https:\/\/www.infoblox.com\/blog\/wp-content\/uploads\/infoblox-logo-2.svg","width":137,"height":30,"caption":"Infoblox"},"image":{"@id":"https:\/\/www.infoblox.com\/blog\/#\/schema\/logo\/image\/"}},{"@type":"Person","@id":"https:\/\/www.infoblox.com\/blog\/#\/schema\/person\/ee71ac61fe2ea349f6e991e628d22f4c","name":"Scott Hogg","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/blogs.infoblox.com\/wp-content\/uploads\/avatar_user_321_1574118215-96x96.jpg","url":"https:\/\/blogs.infoblox.com\/wp-content\/uploads\/avatar_user_321_1574118215-96x96.jpg","contentUrl":"https:\/\/blogs.infoblox.com\/wp-content\/uploads\/avatar_user_321_1574118215-96x96.jpg","caption":"Scott Hogg"},"description":"Scott Hogg has 30 years of network and security experience and is president of Hogg Networking with. Scott Hogg specializes in teaching Internet Protocol version 6 (IPv6) and providing implementation guidance. Scott is CCIE #5133 (Emeritus) and CISSP #4610. Scott is Chair Emeritus of the Rocky Mountain IPv6 Task Force (RMv6TF), a member of the IPv6 Center of Excellence (COE), and co-author of the Cisco Press book on IPv6 Security.","sameAs":["https:\/\/hexabuild.io"],"url":"https:\/\/www.infoblox.com\/blog\/author\/scott-hogg\/"}]}},"_links":{"self":[{"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/posts\/1828","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/users\/321"}],"replies":[{"embeddable":true,"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/comments?post=1828"}],"version-history":[{"count":3,"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/posts\/1828\/revisions"}],"predecessor-version":[{"id":3684,"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/posts\/1828\/revisions\/3684"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/media\/1803"}],"wp:attachment":[{"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/media?parent=1828"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/categories?post=1828"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/tags?post=1828"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}