{"id":21612,"date":"2023-07-06T19:37:24","date_gmt":"2023-07-06T19:37:24","guid":{"rendered":"https:\/\/blog.lacnic.net\/?p=21612"},"modified":"2024-11-07T12:54:55","modified_gmt":"2024-11-07T12:54:55","slug":"ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators","status":"publish","type":"post","link":"https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/","title":{"rendered":"IPv6 architecture and subnetting guide for network engineers and operators"},"content":{"rendered":"\n<p><strong>By&nbsp;<\/strong><a href=\"https:\/\/blog.lacnic.net\/en\/author\/daryll-swer\"><strong>Daryll Swer<\/strong><\/a><strong>&nbsp;\u2013 System &amp; Network Engineer<\/strong><\/p>\n\n\n\n<p><em>This post is adapted from the original at&nbsp;<\/em><a href=\"https:\/\/www.daryllswer.com\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\" target=\"_blank\" rel=\"noreferrer noopener\"><em>Daryll\u2019s Blog<\/em><\/a><em>.<\/em><\/p>\n\n\n\n<p>As networks continue to expand, the need for effective management of the Internet Protocol version 6 (IPv6) is becoming increasingly important. This guide is designed for network engineers and operators who are already familiar with the fundamentals and concepts of IPv6 and are looking for a practical guide to implementing an IPv6 architecture and subnetting system. I take an in-depth look at the most efficient ways to ensure a sufficient and future-proofed IPv6 subnetting model on a per-site and per-network segment basis.<\/p>\n\n\n\n<p>For those who need a refresher on the IPv6 fundamentals, there are many&nbsp;<a href=\"https:\/\/networklessons.com\/ipv6\/introduction-to-ipv6\" target=\"_blank\" rel=\"noreferrer noopener\">online resources<\/a>&nbsp;available to help.<\/p>\n\n\n\n<p>This blog post draws upon my experience as an independent consultant and as a friendly peer in various industries, including telecommunications, data centres (DC)\/enterprises, and ISPs. Through conversations with other network engineers, I observed resistance to learning the basics of IPv6, or an over-reliance on archaic IPv4 processes. This guide aims to provide a comprehensive overview of IPv6 architecture and subnetting for efficiently deploying IPv6 and&nbsp;<em>avoiding<\/em>&nbsp;the pitfalls of an&nbsp;IPv4-centric&nbsp;mindset as elaborated further in the podcast below.<\/p>\n\n\n\n<p>The risks associated with an inefficient deployment or management of IPv6 are readily available. From an administrative point of view, it can lead to messy and non-scalable subnetting that results in fragile and unreliable networks. Regarding engineering, it can lead to unjustified use of small subnets and force the need to use Network Address Translation (NAT66) when not required. This goes hand-in-hand with the idea of using Unique Local Addresses (ULAs) when unnecessary \u2014 all of which are serious impediments to the ultimate goal of providing an efficient, reliable and scalable network service while preserving the&nbsp;<a href=\"https:\/\/en.wikipedia.org\/wiki\/End-to-end_principle\" target=\"_blank\" rel=\"noreferrer noopener\">end-to-end principle<\/a>&nbsp;in the network layer to minimize or eliminate complexities brought about by NAT such as NAT traversal helpers and mechanisms.<\/p>\n\n\n\n<p>Below are some examples of what happens when an organization tries to deploy IPv6 with an IPv4-centric approach:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Without a proper IPv6 subnetting management plan, random IPv6 prefixes\/addresses are allocated to Point-to-Point (PtP) links, servers, and other infrastructure, resulting in a chaotic and unmanageable situation. In the long run, this could lead to a \u2018race to the bottom\u2019 issue (running out of IPv6 addresses) \u2014 a situation that must be avoided at all costs to keep the network secure and scalable.<\/li>\n\n\n\n<li>A single \/64 LAN prefix per customer\/CPE or, worse, a much longer (smaller) prefix.<\/li>\n\n\n\n<li>A dynamic LAN prefix that changes every time the user reconnects and&nbsp;<a href=\"https:\/\/www.6connect.com\/blog\/is-your-isp-constantly-changing-the-delegated-ipv6-prefix-on-your-cpe-router\/\" target=\"_blank\" rel=\"noreferrer noopener\">breaks connectivity<\/a>.<\/li>\n\n\n\n<li>The strange idea that IPv6 is IPv4, and you should use NAT66 to \u2018save\u2019 IPv6 addresses. A public example of this is DigitalOcean\u2019s idea of a \/124 per VM, and from a shared \/64 per DC\/rack\/network segment.<\/li>\n\n\n\n<li>The even stranger idea of using&nbsp;<a href=\"https:\/\/blogs.infoblox.com\/ipv6-coe\/ula-is-broken-in-dual-stack-networks\/\" target=\"_blank\" rel=\"noreferrer noopener\">ULAs<\/a>&nbsp;in&nbsp;<em>certain<\/em>&nbsp;cases where it is not required.\n<ul class=\"wp-block-list\">\n<li>With the exception of&nbsp;<a href=\"https:\/\/twitter.com\/stubarea51\/status\/1511083163921092609\" target=\"_blank\" rel=\"noreferrer noopener\">banking<\/a>&nbsp;or similar organizations, where compliances mandate NAT66 or you need it because of Provider-Aggregatable address space (PA) for load balancing and failover.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<p>While the pre-NAT era version of the end-to-end principle, in general, no longer exists in today\u2019s era of the Internet due to the obsession with IPv4, it is still important to avoid NAT66 to&nbsp;prevent&nbsp;the requirement for Layer 5 \u2013 7 helpers (Application Layer Gateways) and Traversal Using Relays around NAT (TURN) which just adds complexities and overhead to the network when you build networks for large scale use. Such \u2018helper\u2019 traffic consumes unnecessary resources that could be avoided completely.<\/p>\n\n\n\n<p>In short, bad IPv6 architecture and subnetting leads to technical debt for your organization in the long run.<\/p>\n\n\n\n<p><strong>Things to keep in mind with IPv6<\/strong><\/p>\n\n\n\n<p>We need to keep something in mind with IPv6. It is 128 bits in nature, and the mathematical structure of IPv6 allows a&nbsp;<a href=\"https:\/\/www.internetsociety.org\/deploy360\/ipv6\/faq\/#:~:text=There%20is%20an%20erroneous%20perception%20that%20the%20assignment%20of%20large%20IPv6%20prefixes%20to%20end%20customers%20is%20wasteful%2C%20but%20the%20IPv6%20address%20space%20is%20so%20huge%20that%20it%20has%20been%20calculated%20(by%20Tony%20Hain)%20that%20a%20\/48%20could%20be%20assigned%20to%20every%20human%20for%20the%20next%20480%20years%20before%20they%20run%20out.\" target=\"_blank\" rel=\"noreferrer noopener\">\/48 per human for 480 years<\/a>.&nbsp;This means there are no technical justifications for using a prefix delegation smaller than a \/56 per customer, which is also documented in&nbsp;<a href=\"https:\/\/www.ripe.net\/publications\/docs\/ripe-690#4-2-2---48-for-business-customers-and--56-for-residential-customers\" target=\"_blank\" rel=\"noreferrer noopener\">BCOP 690<\/a>.<\/p>\n\n\n\n<p>When deploying IPv6, bear in mind:<\/p>\n\n\n\n<ol start=\"1\" class=\"wp-block-list\">\n<li>The link-prefix (or WAN prefix) is used for inter-device connectivity.<\/li>\n\n\n\n<li>The routed prefix (or LAN prefix) refers to the prefix that is routed to the \u2018LAN\u2019 side of a device where the next-hop IP of that route equals the link-prefix address that is used on the device the prefix is being routed to.<\/li>\n\n\n\n<li>You should always strive to enable auto link-local config network wide, we should never burden ourselves with manually configuring link-local addressing.<\/li>\n\n\n\n<li>Avoid using the initial \u2018leading zero\u2019 address in an IPv6 subnet on an interface or network segment, that is, an address where the least significant&nbsp;<a href=\"https:\/\/web.archive.org\/web\/20230214115432\/https:\/www.ibm.com\/docs\/en\/ts4500-tape-library?topic=functionality-ipv4-ipv6-address-formats\" target=\"_blank\" rel=\"noreferrer noopener\">address segment<\/a>&nbsp;(right-most group of four digits) are zeroes. This is known to cause&nbsp;<a href=\"https:\/\/blog.apnic.net\/2023\/08\/28\/behavioural-differences-of-ipv6-subnet-router-anycast-address-implementations\/\" target=\"_blank\" rel=\"noreferrer noopener\">unexpected behaviours<\/a>. For example, instead of 2001:db8<strong>::<\/strong>, use 2001:db8<strong>::<\/strong>1&nbsp;instead.\n<ul class=\"wp-block-list\">\n<li>However, it should be fine to use leading zero addresses&nbsp;only&nbsp;for loopback on network devices (Routers, L3 switches) if you want to. I would still avoid using leading zero addresses on hosts.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n<p>Below is an example of the principles described above:<\/p>\n\n\n\n<p><strong>Link prefix<\/strong><\/p>\n\n\n\n<p>Let\u2019s say we want to connect router&nbsp;A&nbsp;to router&nbsp;B&nbsp;via a Cat6a UTP cable on interface eth0 on both and assume we have the following prefix available for use: 2001:db8::\/64.<\/p>\n\n\n\n<p>We will configure the addresses as shown:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>router A (eth0): 2001:db8::1\/64\nrouter B (eth0): 2001:db8::2\/64<\/code><\/pre>\n\n\n\n<p>Both routers have a link-prefix with \/64 prefix length, where they can now directly talk to each other on the assigned respective addresses ::1 and ::2.<\/p>\n\n\n\n<p><strong>Routed prefix<\/strong><\/p>\n\n\n\n<p>Let us assume that router B is an access layer router where it is configured to handle 500 VLANs, and we have at least 800 PCs behind each VLAN, and we want to give native IPv6 connectivity to 800\u00d7500 hosts. How will we do this with the \/64 link-prefix natively&nbsp;without&nbsp;the IPv4 mindset and approaches like NAT66 or the NDP Proxy? The answer is, we do not use a link-prefix for the LAN. We need a&nbsp;routed prefix, where each VLAN has a dedicated \/64. In this example we need five hundred \/64s in total.<\/p>\n\n\n\n<p>So let us assume we have the following for LAN prefix use that is reachable via router A: 2001:db8:1::\/52.<\/p>\n\n\n\n<p>A \/52 gives us four thousand \/64s, which is more than enough for our purpose, with room for growth and expansion in the future.<\/p>\n\n\n\n<p>For the purpose of this example, we can now statically route the \/52 to router B like the following, where next-hop\/gateway is the IPv6 address of router B:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ipv6 route 2001:db8:1::\/52 next-hop 2001:db8::2<\/code><\/pre>\n\n\n\n<p>So we can now use 2001:db8:1::\/52 on router B and subnet it further to give us \/64s, from which we can assign a unique \/64 per VLAN. For example, VLAN1 gets 2001:db8:1::\/64, VLAN2 has 2001:db8:1:1::\/64, and so forth.&nbsp;<\/p>\n\n\n\n<p><strong>Address allocation size<\/strong><\/p>\n\n\n\n<p>However, smaller companies may get away with a \/48 or \/44 or \/40 and so on. I do not recommend following this method of incremental allocations because:<\/p>\n\n\n\n<ol start=\"1\" class=\"wp-block-list\">\n<li>You cannot aggregate them 10 years down the line as you scale your company.<\/li>\n\n\n\n<li>It results in a polluted IPv6 routing table that could be avoided by aggregation.<\/li>\n\n\n\n<li>It will impact your subnetting plan and architecture.<\/li>\n\n\n\n<li>You will always end up needing more subnets eventually.<\/li>\n\n\n\n<li>You end up going back and forth with your respective Regional Internet Registry (RIR), National Internet Registry (NIR), or Local Internet Registry (LIR) each time.<\/li>\n<\/ol>\n\n\n\n<p>My recommendation is to apply for a&nbsp;\/32&nbsp;per Autonomous System Number (ASN), or RIR Member account, as a&nbsp;minimum:<\/p>\n\n\n\n<ol start=\"1\" class=\"wp-block-list\">\n<li>You can aggregate to a \/32 if possible or a few \/36s or any combination based on your company\u2019s scale and topology.<\/li>\n\n\n\n<li>It keeps the routing table clean.<\/li>\n\n\n\n<li>You have a scalable subnetting plan and architecture.<\/li>\n\n\n\n<li>There is room for additional subnets.<\/li>\n\n\n\n<li>It reduces the need for having to go back and forth with your respective RIR, NIR or LIR.<\/li>\n<\/ol>\n\n\n\n<p>I hope somebody (or myself) eventually submits a policy proposal for making this (\/32 minimum per ASN\/Member) a reality at the RIR level, at least for APNIC.<\/p>\n\n\n\n<p>You can also check Packet Pusher\u2019s podcast on this subject below for further insights.<\/p>\n\n\n\n<p><strong>Subnetting guideline<\/strong><\/p>\n\n\n\n<p>Every network and organization is different, which includes different business models and network architecture and topology. I like to use what I call the&nbsp;geographical denomination model&nbsp;when it comes to IPv6 subnetting, that is, we plan and perform the subnetting based on how your network is set up in the physical world while accounting for futureproofing such as scaling up or down.<\/p>\n\n\n\n<p>I will show some examples for ISPs\/telcos, DC\/enterprise from real-life hands-on deployments later in this blog post.<\/p>\n\n\n\n<p>With the above in mind, the following is what I strongly believe is an optimized and generalized guideline that operators may want to follow:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The bare minimum for every eBGP speaker (public ASN) is to have a \/32 prefix as discussed in the previous section.<\/li>\n\n\n\n<li>Perform the planning based on the&nbsp;geographical distribution model&nbsp;of your network with a&nbsp;top-to-bottom&nbsp;approach. For example, per continent, then per economy, then per state, then per city, then per town or district, then per site, and per network segment.<\/li>\n\n\n\n<li>Ensure the prefix length is always a multiple of 4 where the lowest possible denomination is a \/64, not anything smaller, with the reason being that we would want to&nbsp;<a href=\"https:\/\/blog.apnic.net\/2018\/08\/10\/how-to-calculating-ipv6-subnets-outside-the-nibble-boundary\/\">avoid exceeding<\/a>&nbsp;the&nbsp;<a href=\"https:\/\/afrinic.net\/support\/ipv6\/nibble\" target=\"_blank\" rel=\"noreferrer noopener\">nibble bit boundary<\/a>.\n<ul class=\"wp-block-list\">\n<li>However, sometimes we cannot avoid exceeding the nibble boundary, and it is perfectly fine as long as the \u2018exceed\u2019 stays in an administrative layer and never enters the network layer. I will highlight this with a real-life example in the architecture section.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>Some prefer to use \/126s or \/127s for eBGP peering with third parties and also for PtP links between two devices, but in such cases we will reserve the entire \/64 per interface (or peer) for every carved \/126-\/127 we use, in the event that we scale up the port\/interface in the future ensuring a \/64 is always available in the IPAM and therefore avoid messy subnetting\/addressing records.<\/li>\n<\/ul>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-large is-resized\"><img decoding=\"async\" width=\"827\" height=\"1024\" src=\"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/07\/fig1-827x1024.jpg\" alt=\"\" class=\"wp-image-21674\" style=\"width:530px\" srcset=\"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/07\/fig1-827x1024.jpg 827w, https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/07\/fig1-242x300.jpg 242w, https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/07\/fig1-768x951.jpg 768w, https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/07\/fig1-1241x1536.jpg 1241w, https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/07\/fig1-1655x2048.jpg 1655w, https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/07\/fig1-300x371.jpg 300w, https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/07\/fig1.jpg 1851w\" sizes=\"(max-width: 827px) 100vw, 827px\" \/><\/figure>\n<\/div>\n\n\n<p>Figure 1 \u2014 IPv6 cheat sheet from APNIC.&nbsp;<a href=\"https:\/\/www.apnic.net\/wp-content\/uploads\/2017\/01\/APNIC_CIDR_Chart_IPv6_2011_05.pdf\" target=\"_blank\" rel=\"noreferrer noopener\">Source<\/a>.<\/p>\n\n\n\n<p><strong>Example of the above principles<\/strong><\/p>\n\n\n\n<p>Let us assume we have 2001:db8::\/32 as our assigned prefix from the RIR. We can slice 2001:db8::\/32 into \/36s. Out of the resulting \/36s, we can use the first four of them for the north, east, west, and south parts of an economy\/state\/city and so on where each geographical denomination receives a \/36.<\/p>\n\n\n\n<p>From the \/36 we can slice it into \/40 per Point of Presence (PoP) (site), out of which we slice it further into \/44s, then into \/48s. We can then use a \/48 per function, for example, Out of Band (OOB), management, internal servers, switches, PtP, and so on. We can then slice the \/48 into \/52s or \/56s to ensure we get a sufficient amount of \/64s per device. We can use a \/64 per VLAN\/VXLAN segment where we take a \/127 for PtP links and reserve the entire \/64 for it, in case the links grow in the future into a multipoint link. Where a \/127 would no longer suffice we can then just use the entire reserved \/64 without ever having to change the subnetting plan\/IP Address Management (IPAM).<\/p>\n\n\n\n<p>Please note, the above is&nbsp;just an example. IPv6 is flexible, and you can subnet it in a way to match your network\u2019s geographical distribution, which can vary. As long as you follow the general guidelines, you should be able to scale it up\/down without much of an issue.<\/p>\n\n\n\n<p>I personally, stopped using \/126s and \/127s on PtP links, because they offer zero benefits, and only increase the human management overhead. Therefore, I recommend you use a regular \/64 per PtP interface from day zero, going forward.<\/p>\n\n\n\n<p><strong>Architecture<\/strong><\/p>\n\n\n\n<p>In this section, I will broadly cover two categories, DCs\/enterprises and Telcos\/ISPs, although generally speaking, you can use the subnetting guide similarly for both. However, there are technical and business model differences, which I believe is best explained with some real-life examples based on my own hands-on experience.<\/p>\n\n\n\n<p><strong>DC\/enterprise<\/strong><\/p>\n\n\n\n<p>I will cover this with a real-life but more generalized example deployed in production at my former employer\u2019s network (<a href=\"https:\/\/bgp.tools\/as\/48635\" target=\"_blank\" rel=\"noreferrer noopener\">AS48635<\/a>) at the time to show how we implemented my guidelines above to fit our specific needs.<\/p>\n\n\n\n<p><strong>Context<\/strong><\/p>\n\n\n\n<p>In this real-life example, I decided to use a single \/32 for infrastructure\/backbone across multiple economies, locations, and sites as it is sufficient for the geographical denomination model of this particular organization. But for the customers, I opted for a dedicated \/32 per site to ensure future scalability, with plenty of \/48s or \/56s routed to them as needed.<\/p>\n\n\n\n<p><strong>For the backbone<\/strong><\/p>\n\n\n\n<p>This is how I decided to break the single \/32 for \u2018global\u2019 substructure\/backbone addressing:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Slice the \/32 into \/36s \u2013 where we use the first \/36 and reserve the rest for future use.<\/li>\n\n\n\n<li>Then slice the first \/36 into \/40s \u2013 where we use the first \/40 and reserve the rest for future use.<\/li>\n\n\n\n<li>Then slice the first \/40 into \/44s \u2013 where we use a \/44 per site.\n<ul class=\"wp-block-list\">\n<li>Here you can reserve the first \/44 for future experiments\/testing if ever required.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>Then slice a \/44 into \/48s \u2013 Here we use a \/48 per function per site.<\/li>\n<\/ul>\n\n\n\n<p>A \/48 per function in each site is broken down in the following manner:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Loopback IP function \u2013 one \/48 sliced into \/64s. Use a \/64 per \u2018row\u2019 of devices type in a given topology, this simplifies readability and routing filters for OSPF\/IS-IS on each row of devices you simply filter import\/export to match a \/64. Ultimately, we will assign a \/128 per device for loopback. For example, a \/64 for edge devices, another \/64 for core or distribution devices, and so on, where each device type gets a \/128 from the respective \/64.<\/li>\n<\/ul>\n\n\n\n<ul class=\"wp-block-list\">\n<li>OOB function \u2013 one \/48 sliced into \/52 per sub-function, example:\n<ul class=\"wp-block-list\">\n<li>\/52 for Loopback sub-function.\n<ul class=\"wp-block-list\">\n<li>The \/52 is sliced into \/56 per \u2018row\u2019 of devices type. For example, a \/56 for OOB edge devices, another \/52 for OOB layer 3 distribution, and so on, where each device type gets a \/128 from the respective \/64.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>\/52 for PtP sub-function.\n<ul class=\"wp-block-list\">\n<li>The \/52 is sliced into \/56 per \u2018row\u2019 of devices type. For example, a \/56 for OOB edge devices, another \/56 for OOB layer 3 distribution, and so on.<\/li>\n\n\n\n<li>We then slice each \/56 into \/64s for use on each corresponding device \u201crow\u201d, for example a \/56 is assigned to the OOB edge, out of which it is then sliced into \/64s per Interface\/VLAN.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>\/52 for OOB Rack Access sub-function.\n<ul class=\"wp-block-list\">\n<li>The \/52 is sliced into \/64s, use a \/64 per OOB VLAN on a given rack (single rack; has single OOB VLAN for all devices).<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>\/52 for employee access sub-function.\n<ul class=\"wp-block-list\">\n<li>The \/52 is sliced into \/64s, where we can use a \/64 per VPN instance for VPN clients or employees to access the infrastructure. Each employee or user will get a \/128 GUA assigned to them on the VPN\u2019s client interface from the \/64 pool.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>PtP function intra\/inter-AS \u2013 one \/48 sliced into \/52s per \u2018row\u2019 of devices in a given topology. For example, a \/52 for edge, a \/52 for Layer 3 distribution, a \/52 for BNGs and so on.\n<ul class=\"wp-block-list\">\n<li>We then slice each \/52 into \/64s for use on each corresponding device \u2018row\u2019, for example a \/52 is assigned to the edge, out of which it is then sliced into \/64s per Interface\/VLAN.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>Peering function (transit, PNIs, and so on) \u2013 one \/48 sliced into \/64 per peer.<\/li>\n\n\n\n<li>Top-of-Rack (ToR) switches \u2013 one \/48 for all ToRs in a site, \/55 per rack, then \/56 per ToR device. Finally, from a \/56 for each ToR device, slice it into \/64s for use per port basis (or VLAN segments) for end-hosts such as SLAAC or DHCPv6, capable up to 256 ports\/VLAN per ToR device.\n<ul class=\"wp-block-list\">\n<li>This is an example of \u2018<strong>exceeding<\/strong>\u2018 the nibble bit boundary in the&nbsp;<strong>administrative layer<\/strong>&nbsp;(\/55)&nbsp;<strong>without<\/strong>&nbsp;percolating it down to the&nbsp;<strong>network layer<\/strong>, and hence this does not present any technical issues.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<p><strong>For the customer<\/strong><\/p>\n\n\n\n<p>For the \/32-customer pool, the logic should ideally be simpler than the backbone to avoid headaches down the road as your number of customers scales up.<\/p>\n\n\n\n<p>In my former employer\u2019s network, we decided the minimum pool for a customer to be \/56, however, I will share a more generalized approach that is not specific to the business logic of my former employer. You can always go with a \/48 per customer if you want to and that does allow more flexibility to the customer to subnet and route the prefixes to their corresponding VMs in whatever way they want it.<\/p>\n\n\n\n<p>For the \/56 logic:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>We slice the \/32 into \/40s, this gives you 256 \/40s. Take the first \/40, and slice it into \/48s, this gives you 256 \/48s.<\/li>\n\n\n\n<li>This pool of \/48s will be used as \/48 per rack for the PtP link between a hypervisor and the customer\u2019s VM WAN interface. So, this means each rack gets a \/48, and each \/48 is sliced into \/64s.\n<ul class=\"wp-block-list\">\n<li>Therefore, we now have 65k \/64s. Each rack can now support 65k VMs where each VM\u2019s WAN interface gets a \/64.<\/li>\n\n\n\n<li>However, you may also want to use a \/64 for a single L2 domain across multiple VMs, whereby a customer\u2019s VLAN or \u201cVPC\u201d has a single \/64 for the VMs\u2019 WAN interface, whereby each VM receives a \/128.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>Next, we will use the remaining \/40s for providing routed prefixes to each customer\u2019s VM. Each rack will get a dedicated \/40 out of the original pool of \/40s sliced from the \/32.\n<ul class=\"wp-block-list\">\n<li>Now that each rack has a dedicated \/40, this gives us 65k \/56s.<\/li>\n\n\n\n<li>We now simply route a \/56 to each customer\u2019s VM, therefore all customers will have their own dedicated \/56 pool for their own uses on each VM which is by far larger than what most mainstream cloud providers do and hence is a future-proofed approach in the long run.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<p>For the \/48 logic:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>We slice the \/32 into \/48s. This gives us 65k \/48s. We can, for example, use\/reserve the first 10k \/48s for the PtP link between a hypervisor and the customer\u2019s VM WAN interface. This means, we can handle 10k hypervisors, where each VM\u2019s WAN interface will get a \/64 or an entire L2 domain will get a \/64, where each VM inside the L2 domain will get a \/128.<\/li>\n\n\n\n<li>We now simply route\/map a \/48 to each customer account. Every customer will get their own \/48, and then subnet it as needed, or you can default the subnetting to a routed \/56 per VM, while still allowing the customer to change the subnetting should they want to.<\/li>\n<\/ul>\n\n\n\n<p>Either approach is perfectly fine. However, you have probably noticed that the \/56 approach has an additional overhead on the network layer, whereas the \/48 has less overhead on the network layer but more overhead on the application layer as you will need to provide a web interface or CLI for your customer to subnet and break their own \/48 if they choose to.<\/p>\n\n\n\n<p>Since it is \/32 per site, it does not result in confusion or a messy IPAM\/subnet. You can easily just announce any \/48 from the ToRs towards the L3 distribution switches (or VXLAN\/VTEP gateway) which then announces that to the edge routers. You can always perform route aggregation on each layer of devices to minimise the routing table in your local network.<\/p>\n\n\n\n<p>In short, for the customer pool in DCs\/enterprises, you can either opt for a \/48 per customer (I prefer this to avoid subnetting any further and increasing the possibility of customers requesting more \/56s) or a \/56 per customer\u2019s VM, so each VM will still get a \/56.<\/p>\n\n\n\n<p><strong>Topology<\/strong><\/p>\n\n\n\n<p>It should be noted that the diagram below is only for reference to give you an idea on the IPv6 subnetting. It is a smaller, simplified topology diagram compared to the production topology, which is far bigger and more complex and would not fit in a single diagram.<\/p>\n\n\n\n<figure class=\"wp-block-image size-full\"><img decoding=\"async\" width=\"2560\" height=\"1678\" src=\"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/07\/Figure-2-DC-Topology-Example.png\" alt=\"\" class=\"wp-image-27901\" srcset=\"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/07\/Figure-2-DC-Topology-Example.png 2560w, https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/07\/Figure-2-DC-Topology-Example-300x197.png 300w, https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/07\/Figure-2-DC-Topology-Example-1024x671.png 1024w, https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/07\/Figure-2-DC-Topology-Example-503x330.png 503w, https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/07\/Figure-2-DC-Topology-Example-768x504.png 768w, https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/07\/Figure-2-DC-Topology-Example-1536x1007.png 1536w, https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/07\/Figure-2-DC-Topology-Example-2048x1343.png 2048w\" sizes=\"(max-width: 2560px) 100vw, 2560px\" \/><\/figure>\n\n\n\n<p>Figure 2 \u2014 DC topology example.<\/p>\n\n\n\n<p><strong>ISP\/Telco<\/strong><\/p>\n\n\n\n<p>I will cover this with a real-life example, that I architected for&nbsp;<a href=\"https:\/\/bgp.tools\/as\/141253\" target=\"_blank\" rel=\"noreferrer noopener\">AS141253<\/a>&nbsp;(one of my upstream providers at the time of writing this article), to implement an IPv6 architecture for their network that covers the whole of India, which serves as a good example for large scale networks.<\/p>\n\n\n\n<p>Based on India\u2019s geographical denomination (economy&gt;state&gt;district&gt;and so on), I believe it is a good example to reference due to its size and large population. I recommend you have a minimum \/32-<strong>customer<\/strong>&nbsp;pool allocated&nbsp;<strong>per state<\/strong>&nbsp;for scalability and futureproofing.<\/p>\n\n\n\n<p><strong>Context example<\/strong><\/p>\n\n\n\n<p>They have a \/32 \u2018Global\u2019 prefix for a nationwide backbone and at the time of writing this, there is a separate \/32 \u2018customer\u2019 prefix solely for the state of&nbsp;<a href=\"https:\/\/en.wikipedia.org\/wiki\/Mizoram\" target=\"_blank\" rel=\"noreferrer noopener\">Mizoram<\/a>.<\/p>\n\n\n\n<p>I use&nbsp;<a href=\"https:\/\/web.archive.org\/web\/20220707185957\/https:\/www.dcmsme.gov.in\/publications\/tender\/Final%20REoI\/Annexure%201.pdf\" target=\"_blank\" rel=\"noreferrer noopener\">this government document<\/a>&nbsp;as a source of truth for the geographical denomination of India up to the state level.<\/p>\n\n\n\n<p><strong>For the backbone<\/strong><\/p>\n\n\n\n<p>This is how I decided to break the single \/32 for \u2018global\u2019 India-wide substructure\/backbone addressing:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Slice the \/32 into \/34s \u2013 where we use each \/34 (another example of outside nibble-bit boundary prefix length, but only on an administrative layer) for each geographical zone (north, east, south, west).<\/li>\n\n\n\n<li>Then slice each \/34 into \/40s \u2013 where we use a \/40 per state\/Union Territory in each respective zone mapping. This gives us 64 \/40s.\n<ul class=\"wp-block-list\">\n<li>Although this additional delegation is not mandatory, I prefer to reserve an \u2018even\u2019 number of \/40s for each state. This means, for example, the \u2018North India\u2019 zone has a total of eight states\u2014now we divide 64 by eight (the number of states in a zone), we get eight as the quotient. This means each state has a total of eight \/40s allocated, which helps with administrative overhead and keeping the prefixes aligned geographically in an alphabetical\/serial order.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>Then slice the first \/40 into \/44s \u2013 where we use a \/44 per site.\n<ul class=\"wp-block-list\">\n<li>Here you can reserve the first \/44 for future experiments\/testing if ever required.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>Then slice a \/44 into \/48s \u2013 here we use a \/48 per function in a given site.<\/li>\n<\/ul>\n\n\n\n<p>A \/48 per function in a given site is broken down in the following manner:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Loopback IP function \u2013 one \/48 sliced into \/64s. Use a \/64 per \u2018row\u2019 of devices type in a given topology, this simplifies readability and routing filters for OSPF\/IS-IS on each row of devices you simply filter import\/export to match a \/64. Ultimately, we will assign a \/128 per device for loopback. For example, a \/64 for edge devices, another \/64 for core or distribution devices, and so on, where each device type gets a \/128 from the respective \/64.<\/li>\n\n\n\n<li>OOB function \u2013 one \/48 sliced into \/52 per sub-function, example:\n<ul class=\"wp-block-list\">\n<li>\/52 for Loopback sub-function.\n<ul class=\"wp-block-list\">\n<li>The \/52 is sliced into \/56 per \u2018row\u2019 of devices type. For example, a \/56 for OOB edge devices, another \/52 for OOB layer 3 distribution, and so on, where each device type gets a \/128 from the respective \/64.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>\/52 for PtP sub-function.\n<ul class=\"wp-block-list\">\n<li>The \/52 is sliced into \/56 per \u2018row\u2019 of devices type. For example, a \/56 for OOB edge devices, another \/56 for OOB layer 3 distribution, and so on.<\/li>\n\n\n\n<li>We then slice each \/56 into \/64s for use on each corresponding device \u201crow\u201d, for example a \/56 is assigned to the oob edge, out of which it is then sliced into \/64s per Interface\/VLAN.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>\/52 for OOB Rack Access sub-function.\n<ul class=\"wp-block-list\">\n<li>The \/52 is sliced into \/64s, use a \/64 per OOB VLAN on a given rack (single rack; has single OOB VLAN for all devices).<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>\/52 for employee access sub-function.\n<ul class=\"wp-block-list\">\n<li>The \/52 is sliced into \/64s, where we can use a \/64 per VPN instance for VPN clients or employees to access the infrastructure. Each employee or user will get a \/128 GUA assigned to them on the VPN\u2019s client interface from the \/64 pool.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>PtP function intra\/inter-AS \u2013 one \/48 sliced into \/52s per \u2018row\u2019 of devices in a given topology. For example, a \/52 for edge, a \/52 for Layer 3 distribution, a \/52 for BNGs and so on.\n<ul class=\"wp-block-list\">\n<li>We then slice each \/52 into \/64s for use on each corresponding device \u201crow\u201d, for example a \/52 is assigned to the edge, out of which it is then sliced into \/64s per Interface\/VLAN.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>Peering function (transit, PNIs, and so on) \u2013 one \/48 sliced into \/64 per peer.<\/li>\n\n\n\n<li>CDN Caching node \u2013 one \/48 sliced into \/56s per CDN. For example, a \/56 for Google, sliced into \/64s for use on PtP links or for routed prefixes, ensures each CDN\u2019s caching nodes\/equipment has up to 256 \/64s available for use in a site.<\/li>\n<\/ul>\n\n\n\n<p>Ultimately this is for the backbone and not the customer pool. Hence, a single \/32 can cover the whole network for India<\/p>\n\n\n\n<p>You can find an example of the above principles in this&nbsp;<a href=\"https:\/\/docs.google.com\/spreadsheets\/d\/e\/2PACX-1vQ32t5C9BW-rV36gUo93uYcLw9GMPqg7BMks8u17dlLhWmIUzIdCe4iexLBQKdnDwykAom929K2dTxR\/pubhtml\" target=\"_blank\" rel=\"noreferrer noopener\">Excel sheet<\/a>&nbsp;I made for AS141253.<\/p>\n\n\n\n<p><strong>For the customer<\/strong><\/p>\n\n\n\n<p>The \/32-customer pool for the state of Mizoram is sliced into \/37s. Of these, sixteen \/37s are group reserved for enterprise\/commercial customers, and the remaining sixteen \/37s are reserved for residential customers.<\/p>\n\n\n\n<p>Each group of sixteen \/37s is then respectively mapped to each&nbsp;<a href=\"https:\/\/en.wikipedia.org\/wiki\/Mizoram#Administration\" target=\"_blank\" rel=\"noreferrer noopener\">district<\/a>&nbsp;of the state, where each district gets a \/37 with plenty more available if required. If you don\u2019t have the exact number of districts, counties, or provinces, you can slice the \/32 into \/38s or even further, until you get whatever works best for your geographical denomination.<\/p>\n\n\n\n<p>Remember, that this is simply at an administrative level, not the network layer, however, I recommend avoiding going too far into the hierarchy \u2014 with a general rule of thumb that the smallest prefix per BNG for the customer LAN pool will be a \/42, based on the fact a \/42 guarantees 16k customers will get a \/56, and it gives room for some futureproofing as you would likely want to limit the number of customers per BNG to 16k or lower and spread the load on other BNGs to avoid creating a Single Point of Failure (SPOF) scenario. Even if you add more customers beyond 16k, you can just route an additional \/42 thereby ensuring 32k customers per BNG will all get a static \/56.<\/p>\n\n\n\n<p><strong>This is how I decided to break each \/37 per district for residential customers:<\/strong><\/p>\n\n\n\n<p>Each \/37 in a given district is sliced into \/42s, and the first \/42 is sliced into \/48s. Each \/48 will be routed to each BNG, whereby it will provide a \/64 WAN allocation to each customer for up to 65k customers per BNG, which is futureproofing as well. The remaining \/42s will be allocated per BNG, where each \/42 will provide static (persistent) \/56s for up to 16k customers per BNG.<\/p>\n\n\n\n<p>In short, residential customers will get a&nbsp;<strong>\/64 for the WAN side<\/strong>&nbsp;and a<strong>&nbsp;static \/56 for the LAN side<\/strong>.<\/p>\n\n\n\n<p><strong>This is how I decided to break each \/37 per district for enterprise customers:<\/strong><\/p>\n\n\n\n<p>Each \/37 in a given district is sliced into \/48s for use within the specified district. From here, we can use a \/48 per site for the PtP between the provider and the customer, where it\u2019s sliced into \/64s per interface\/VLAN.<\/p>\n\n\n\n<p>Next, we simply route a dedicated \/48 to each customer either via BGP with private ASN or with static routing of the \/48 to the ::2\/64 address of the customer\u2019s PtP interface.<\/p>\n\n\n\n<p>In short,&nbsp;<strong>enterprise<\/strong>&nbsp;customers will get a&nbsp;<strong>\/64 for the WAN side<\/strong>&nbsp;and a&nbsp;<strong>static<\/strong>&nbsp;<strong>\/48 for the LAN side<\/strong>.<\/p>\n\n\n\n<p><strong>Topology<\/strong><\/p>\n\n\n\n<p>The topology for an ISP is fairly typical; if you are already an ISP, you likely already have similar topologies. The scale is naturally much larger than a DC\/enterprise operator and different altogether, as you typically have an edge, distribution layer (in some cases a core and distribution), access layer, Multiprotocol Label Switching (MPLS) rings, and so on.<\/p>\n\n\n\n<p>The topology diagram below is only for reference to give you an idea on the IPv6 subnetting for ISPs.<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-large is-resized\"><img decoding=\"async\" width=\"642\" height=\"1024\" src=\"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/07\/Figure-3-ISP-Topology-Example-642x1024.png\" alt=\"\" class=\"wp-image-27904\" style=\"width:550px\" srcset=\"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/07\/Figure-3-ISP-Topology-Example-642x1024.png 642w, https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/07\/Figure-3-ISP-Topology-Example-188x300.png 188w, https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/07\/Figure-3-ISP-Topology-Example-207x330.png 207w, https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/07\/Figure-3-ISP-Topology-Example-768x1224.png 768w, https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/07\/Figure-3-ISP-Topology-Example-964x1536.png 964w, https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/07\/Figure-3-ISP-Topology-Example-1285x2048.png 1285w, https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/07\/Figure-3-ISP-Topology-Example-300x478.png 300w, https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/07\/Figure-3-ISP-Topology-Example.png 1606w\" sizes=\"(max-width: 642px) 100vw, 642px\" \/><\/figure>\n<\/div>\n\n\n<p>Figure 3 \u2014 ISP topology example.<\/p>\n\n\n\n<p><strong>Implementation<\/strong><\/p>\n\n\n\n<p><strong>DC\/enterprise<\/strong><\/p>\n\n\n\n<p>We used static addressing for PtP links, Open Shortest Path First (OSPF) for learning loopback IPs of each device, a combination of eBGP and iBGP for routing everything else and avoiding fully-mesh iBGP, and BGP confederation or route reflectors based on&nbsp;RFC 7938. In simple terms, iBGP is used between loopbacks of adjacent\/redundant neighbors forming a horizontal relationship, for example, a set of edge routers each connected to different transits or IXPs. Whereas, eBGP is used between vertical neighbors establishing an upstream\/downstream relationship where each of them is in separate Autonomous Systems using a private ASN extended range.<\/p>\n\n\n\n<p>For OOB, we used SLAAC + EUI-64 to auto-generate addresses on network devices and hosts on the OOB VLAN that are easily mappable to their MAC addresses. This means our routers, switches, server nodes, Power Distribution Units (PDUs) (PDUs), and so on, all received a \/128 Global Unicast Address (GUA) via SLAAC through the rack-specific OOB switch, which then obtains connectivity from the OOB distribution switch in the OOB rack. For production or main VLANs (customer VMs or machines), you should avoid EUI-64.<\/p>\n\n\n\n<p>Although I have not deployed this configuration using DHCPv6 address assignment and prefix delegation in a DC\/enterprise, it is a perfectly valid solution if you prefer stateful control over how hosts obtain their addresses and also for Authentication, Authorization, and Accounting (AAA) purposes.<\/p>\n\n\n\n<p><strong>ISP<\/strong><\/p>\n\n\n\n<p>In this particular ISP, the implementation was simple. We used static addressing for backbone PtP links, BGP\/OSPF for routing internally and\/or to enterprise customers similar to the DC\/enterprise example, using PPPoE or DHCPv6-PD to delegate the \/48s or \/56s to customers. I will not do a deep dive into the implementation details as it varies wildly between different vendors. This is only to give you a general idea and guide to deploying BCOP-690-compliant IPv6 on your network.<\/p>\n\n\n\n<p>However, I recommend that you use a vendor\/AAA provider that supports&nbsp;static&nbsp;IPv6 addressing\/PD for your customers. As mentioned in the introduction of this blog post, dynamic prefixes break SLAAC, and also make it impossible for a customer to use your GUA on their end-hosts for global accessibility should they want to.<\/p>\n\n\n\n<p><strong>What about VPN?<\/strong><\/p>\n\n\n\n<p>You can have a dedicated \/48 function for VPN in a given site, or it can be shared with the management function, where clients receive a stable (static) \/128 GUA from a \/64 pool. You now simply use a stateful firewall on the router or VPN server host, where you accept established, related, untracked traffic and accept ICMPv6, dropping the rest on the forward chain (iptables). That\u2019s it. Your VPN clients will have native IPv6 without any hacks and be fully secured from the outside world. Of course, you will still need to apply access control list logic, but that is organization-dependent and outside the scope of this blog post.<\/p>\n\n\n\n<p>You can also even provide routed prefixes to VPN clients, where each client can be routed a \/64. This helps employees working on application development on Docker to have a native \/64 routed straight into their laptops for native IPv6 container networking.<\/p>\n\n\n\n<p><strong>Global routing approach<\/strong><\/p>\n\n\n\n<p>Instead of announcing individual \/48s to the Default-Free Zone (DFZ) and increasing the global routing table size, you should aim to announce aggregated prefixes to the largest possible extent for a given site or a given set of sites. For example, you can advertise a \/44 \u2018backbone\u2019 prefix directly to all your peers and transit instead of individual \/48s. Or if all your sites have direct Layer 2 reachability between each other and are geographically close enough for latency to not be of concern, you could then just announce the \/32 \u2018backbone\u2019 prefix directly from all sites towards the transit and peers, therefore keeping the DFZ clean. For the customer pool, it is simply a matter of announcing a \/32 per site directly to all peers and transits.<\/p>\n\n\n\n<p>Note, this article does not cover BGP and traffic engineering. I would emphasize that aggregating your prefixes allows for cleaner and more efficient traffic engineering in the long run.<\/p>\n\n\n\n<p><strong>NAT66 vs NPTv6 usage<\/strong><\/p>\n\n\n\n<p>I will not do a deep dive into NAT44, NAT66, or NPTv6 as it is outside the scope of this blog post, but there are a few points to note below as NPTv6 (not NAT66) is required in certain use cases.<\/p>\n\n\n\n<p>NAT66 is no different from traditional NAT44, \u2014 along with all the problems such as breaking Layer 4 (L4) protocols, forcing the need for an ALG, and the list goes on. The only difference is NAT66 supports IPv6 addressing. For this reason, the IETF came up with a new solution and method of \u2018translation\u2019 for IPv6 that is free from issues introduced by NAT, that is,&nbsp;<a href=\"https:\/\/datatracker.ietf.org\/doc\/rfc6296\/\" target=\"_blank\" rel=\"noreferrer noopener\">IPv6-to-IPv6 Network Prefix Translation<\/a>&nbsp;(NPTv6).<\/p>\n\n\n\n<p>NPTv6 is a&nbsp;stateless&nbsp;and&nbsp;transport-agnostic&nbsp;(L4) mechanism for translating one address space to another. Therefore, it preserves the end-to-end principle on the network layer and does not introduce a stateful mechanism that breaks L4 protocols, which is simply not possible on traditional NAT in a stateless manner.<\/p>\n\n\n\n<p>In order for NPTv6 to work as intended (in a stateless manner) the \u2018inside\u2019 and \u2018outside\u2019 IPv6 prefixes both need to be of the&nbsp;<em>same prefix length<\/em>. For example, let\u2019s say your internal prefix is \u2018200::\/64\u2019 and you want to translate this into a different \u2018outside\u2019 prefix that is visible on the public Internet such as&nbsp;\u20182001:db8::\/64\u2019. You simply configure NPTv6 depending on your Network Operating System (NOS) to translate one \/64 to another \/64. You will have done the translation without breaking the network layer\u2019s end-to-end reachability and L4 protocols.<\/p>\n\n\n\n<p>So in general, I strongly recommend you avoid NAT66 to avoid problems associated with it and go with NPTv6 in all production networks.<\/p>\n\n\n\n<p>However, if you are forced to use NAT66, such as being a customer of DigitalOcean where they only provide a \/124, then you are unfortunately going to lose the benefits of IPv6 (native end-to-end principle and transport agnosticism on Layer 4) and have the same network related downfall as NATted IPv4. The only solution would be to demand them to provide best practice-compliant IPv6 or move to a different provider that does.<\/p>\n\n\n\n<p><strong>Managing PA blocks<\/strong><\/p>\n\n\n\n<p><a href=\"https:\/\/www.ripe.net\/participate\/member-support\/faqs\/isp-related-questions\/pa-pi\" target=\"_blank\" rel=\"noreferrer noopener\">PA blocks<\/a>&nbsp;are those assigned to a customer by an ISP, rather than the customer having their own Provider Independent (PI) IPv6 blocks. The main problem with PA blocks is, you need to perform renumbering when you change providers or when your provider goes out of business and shuts down or for any other reason.<\/p>\n\n\n\n<p>Renumbering is one issue, the other is load-balancing and failover when you have multiple providers with their own unique PA block assigned to your business. You could use router advertisements in IPv6 to advertise one block or the other based on your preferences, but this does not allow true load balancing on the network layer to even out your bandwidth consumption.<\/p>\n\n\n\n<p>The only way to work around this&nbsp;without&nbsp;using ULA and&nbsp;<a href=\"https:\/\/datatracker.ietf.org\/doc\/slides-114-v6ops-unintended-operational-issues-with-ula\/\" target=\"_blank\" rel=\"noreferrer noopener\">breaking<\/a>&nbsp;your dual-stack networks is to use NPTv6 in combination with non-ULA address space. At the time of writing this blog post, IANA has&nbsp;not&nbsp;assigned dedicated address space for this purpose. In theory, you can use the \u2018200::\/7\u2019 block for your internal network, and subnet it based on the general guidelines laid out in this blog post.<\/p>\n\n\n\n<p>However, you&nbsp;should be aware&nbsp;that since the \u2018200::\/7\u2019 block is&nbsp;not officially&nbsp;assigned for NPTv6 usage, it remains&nbsp;in limbo, and it may be reassigned in the future to become perhaps a documentation prefix or a Global Unicast Prefix, for which in either case, you will still need to&nbsp;renumber&nbsp;your internal network. It is the only prefix at this point in time that works as an alternative to ULA for NPTv6, and it is \u2018free\u2019 to use.<\/p>\n\n\n\n<p>In short, there is no perfect solution provided by the IETF presently regarding operational issues with ULA in production networks.&nbsp;<\/p>\n\n\n\n<p class=\"has-cyan-bluish-gray-background-color has-background\">Please note that this is not an official recommendation by the IETF; you can proceed with my solution at your own discretion.<\/p>\n\n\n\n<p><strong>Example<\/strong><\/p>\n\n\n\n<p>Let\u2019s assume that you have two providers that gave you a \/48 each, and you have sliced each \/48 identically to match your network infrastructure. You have also sliced two \/48s out of the \u2018200::\/7\u2019 block that you then slice to match your PA block subnetting.<\/p>\n\n\n\n<p>We will assume that for example, you have VLAN1 and VLAN2, for which you have two \/64s; one set from each provider and another set of two \/64s from the \u2018200::\/7\u2019 block.<\/p>\n\n\n\n<p>Now you can do something to this effect, in order of precedence, for both load balancing and failover, noting that you need to do the config in both directions (internal&gt;external, external&gt;Internet) to preserve the end-to-end principle.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>#Source NPTv6#\n200::\/64 &lt;NPTv6-translated&gt; ISP1 \/64\n200:1::\/64 &lt;NPTv6-translated&gt; ISP2 \/64\n\n#Destination NPTv6#\nISP1 \/64 &lt;NPTv6-translated&gt; 200::\/64\nISP2 \/64 &lt;NPTv6-translated&gt; 200:1::\/64<\/code><\/pre>\n\n\n\n<p>Below is the routerOS v7-specific sample using a single ISP prefix where \u2018200::\/64\u2019 is the internal prefix and \u20182001:db8::\/64\u2019 is the PA block from the ISP.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>\/ipv6 firewall mangle\nadd action=snpt chain=postrouting comment=\"NPTv6 (Internal&gt;External)\" dst-prefix=2001:db8::\/64 src-address=200::\/64 src-prefix=200::\/64\n\nadd action=dnpt chain=prerouting comment=\"NPTv6 (External&gt;Internal)\" dst-address=2001:db8::\/64 dst-prefix=200::\/64 src-prefix=2001:db8::\/64<\/code><\/pre>\n\n\n\n<p><strong>IPv6 security<\/strong><\/p>\n\n\n\n<p>Although IPv6 security is a subject on its own, and therefore is not the focus of this article, I felt it is still important to mention a few key points to help guide you in the right direction for research and testing of IPv6 security in your own local network environment.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Do not blindly block ICMPv6. ICMPv6 is already rate-limited by default on all major networking vendors and OSes and therefore does not represent additional security concerns. You can, however, block invalid or deprecated ICMPv6 subtypes as per&nbsp;<a href=\"https:\/\/www.iana.org\/assignments\/icmpv6-parameters\/icmpv6-parameters.xhtml#icmpv6-parameters-4\" target=\"_blank\" rel=\"noreferrer noopener\">IANA<\/a>&nbsp;guidelines. The same principles also apply to IPv4.<\/li>\n\n\n\n<li>There are some concerns about Neighbor Discovery Cache exhaustion attacks. However, as long as your OS is already rate limiting ICMPv6 out of the box, and you religiously ensure to route your prefixes to blackhole on your edge routers, access routers, L3 switches, and so on (which also prevents L3 loops), this should not pose an issue in practice.\n<ul class=\"wp-block-list\">\n<li>You can limit your Neighbor Cache table to 8k\/16k hosts, and then it really would not matter if someone is scanning your \/64 VLAN segment, as the old entries that are unreachable will simply expire and those that are valid will remain cached. My own&nbsp;<a href=\"https:\/\/blog.apnic.net\/2022\/07\/01\/how-i-set-up-my-own-autonomous-system\/\">personal R&amp;D network<\/a>&nbsp;(AS149794) was once a \u2018victim\u2019 of this type of attack, but even on an ancient MikroTik RB3011,&nbsp;no performance&nbsp;impact was visible on the network even though the neighbor cache table was flooded to the 16k limit I configured.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><a href=\"https:\/\/theinternetprotocolblog.wordpress.com\/2020\/11\/28\/ipv6-security-best-practices\/\" target=\"_blank\" rel=\"noreferrer noopener\">This<\/a>&nbsp;is also a good source for IPv6 best security practices. Production-grade&nbsp;<a href=\"https:\/\/www.daryllswer.com\/edge-router-bng-optimisation-guide-for-isps\/\" target=\"_blank\" rel=\"noreferrer noopener\">IPv6 security practices for MikroTik<\/a>&nbsp;is also available.<\/li>\n\n\n\n<li>NAT is not and never was a&nbsp;<a href=\"https:\/\/www.f5.com\/services\/resources\/white-papers\/the-myth-of-network-address-translation-as-security\" target=\"_blank\" rel=\"noreferrer noopener\">security tool<\/a>.<\/li>\n\n\n\n<li>For insecure network segments such as guest VLANs, or IoT VLANs in enterprise, simply follow the same model as VPN clients, firewall in-bound on the forward chain using iptables (or nftables) to accept established, related, untracked and ICMPv6, and drop the rest. This ensures there is no possibility of external actors being able to reach your hosts from the outside directly, unless of course, your host is infected with malware or a botnet.<\/li>\n\n\n\n<li>I recommend keeping the network layer simple. Handle stateful firewalling directly on the host and implement OS policy control to prevent employees or guests from executing random files that are possibly malware or installing unauthorized software. You could always have a third-party firewall appliance as well that does the security, but I personally prefer a vendor-agnostic approach. On-host firewalling using iptables\/nftables or even Windows\u2019 built-in firewall combined with OS policy control would therefore be my personal preference.\n<ul class=\"wp-block-list\">\n<li>You can also implement advanced filtering on Linux hosts using eBPF or XDP if you want fine-grained control in large-scale companies with the right skill set in their employees.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<p><strong>Conclusion<\/strong><\/p>\n\n\n\n<p>I will emphasize again that these are general guidelines and examples. Every organization can subnet things differently, but you should aim to ensure your backbone and customers get sufficient and persistent (static) subnets that are scalable for decades to come. BCOP-690 is not a silver bullet for every scenario, but it, along with this blog post, serves as thorough end-to-end guidelines to help you reach the best-practices-compliant design and architecture for your network and business needs.<\/p>\n\n\n\n<p>Ideally, NAT66\/NPTv6 should be avoided to the maximum possible extent as both defeat the purpose of native IPv6 (which is only possible in a network that complies with best practices) and only add additional overhead to the network.<\/p>\n\n\n\n<p>I also hope that the Payment Card Industry Data Security Standard (PCI DSS) learns that NAT(66) is not a security tool and there is no need for NAT in IPv6 to begin with, sooner rather than later before their&nbsp;<a href=\"https:\/\/twitter.com\/stubarea51\/status\/1511083163921092609\" target=\"_blank\" rel=\"noreferrer noopener\">current requirements<\/a>&nbsp;create a technical debt that becomes far too difficult to remove in the future.<\/p>\n\n\n\n<p>I want this article to drop a ground-shaking delivery to the networking industry for a best-practices-compliant-IPv6 rollout! Let\u2019s see more routed \/48s!<\/p>\n\n\n\n<p><em>This document is updated as and when deemed necessary by the author.&nbsp;For any queries on this guide or to suggest improvements, please reach out to&nbsp;<\/em><a href=\"mailto:contact@daryllswer.com\" target=\"_blank\" rel=\"noreferrer noopener\"><em>Daryll Swer<\/em><\/a><em>.<\/em><\/p>\n\n\n\n<p><em>It would be appreciated if you could help me continue to provide valuable network engineering content by supporting my non-profit solitary efforts. Your donation will help me conduct valuable experiments.&nbsp;<\/em><a href=\"https:\/\/www.daryllswer.com\/donation\/\" target=\"_blank\" rel=\"noreferrer noopener\"><em>Click here<\/em><\/a><em>&nbsp;to donate now. Daryll Swer is an IT &amp; Networking&nbsp;enthusiast (AS149794), driven by a passion for computer networking, particularly in the realm of IPv6 deployment. Through his ongoing&nbsp;<\/em><a href=\"https:\/\/blog.apnic.net\/?s=daryll+swer\" target=\"_blank\" rel=\"noreferrer noopener\"><em>research and insightful contributions<\/em><\/a><em>, he offers valuable guidance and practical examples to empower professionals in leveraging the full potential of IPv6.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>By&nbsp;Daryll Swer&nbsp;\u2013 System &amp; Network Engineer This post is adapted from the original at&nbsp;Daryll\u2019s Blog. As networks continue to expand, the need for effective management of the Internet Protocol version 6 (IPv6) is becoming increasingly important. This guide is designed for network engineers and operators who are already familiar with the fundamentals and concepts of [&hellip;]<\/p>\n","protected":false},"author":4,"featured_media":19576,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[531],"tags":[1304],"archivo":[],"taxonomy-authors":[1401],"tipo_autor":[1455],"class_list":["post-21612","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ipv6","tag-ipv6","taxonomy-authors-daryll-swer-en","tipo_autor-colaborador"],"acf":{"author":"","related_notes":[21436,21211]},"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v27.0 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>LACNIC Blog | IPv6 architecture and subnetting guide for network engineers and operators<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"LACNIC Blog | IPv6 architecture and subnetting guide for network engineers and operators\" \/>\n<meta property=\"og:description\" content=\"By&nbsp;Daryll Swer&nbsp;\u2013 System &amp; Network Engineer This post is adapted from the original at&nbsp;Daryll\u2019s Blog. As networks continue to expand, the need for effective management of the Internet Protocol version 6 (IPv6) is becoming increasingly important. This guide is designed for network engineers and operators who are already familiar with the fundamentals and concepts of [&hellip;]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/\" \/>\n<meta property=\"og:site_name\" content=\"LACNIC Blog\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/facebook.com\/lacnic\" \/>\n<meta property=\"article:published_time\" content=\"2023-07-06T19:37:24+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2024-11-07T12:54:55+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/01\/lacnic-ipv6-only-2023.png\" \/>\n\t<meta property=\"og:image:width\" content=\"680\" \/>\n\t<meta property=\"og:image:height\" content=\"330\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"LACNIC\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@lacnic\" \/>\n<meta name=\"twitter:site\" content=\"@lacnic\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/\"},\"author\":{\"name\":\"LACNIC\",\"@id\":\"https:\/\/blog.lacnic.net\/#\/schema\/person\/30da2f68d9b9f0123d5192afb790dea9\"},\"headline\":\"IPv6 architecture and subnetting guide for network engineers and operators\",\"datePublished\":\"2023-07-06T19:37:24+00:00\",\"dateModified\":\"2024-11-07T12:54:55+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/\"},\"wordCount\":6830,\"commentCount\":1,\"publisher\":{\"@id\":\"https:\/\/blog.lacnic.net\/#organization\"},\"image\":{\"@id\":\"https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/01\/lacnic-ipv6-only-2023.png\",\"keywords\":[\"IPv6\"],\"articleSection\":[\"IPv6\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/\",\"url\":\"https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/\",\"name\":\"LACNIC Blog | IPv6 architecture and subnetting guide for network engineers and operators\",\"isPartOf\":{\"@id\":\"https:\/\/blog.lacnic.net\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/01\/lacnic-ipv6-only-2023.png\",\"datePublished\":\"2023-07-06T19:37:24+00:00\",\"dateModified\":\"2024-11-07T12:54:55+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/#primaryimage\",\"url\":\"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/01\/lacnic-ipv6-only-2023.png\",\"contentUrl\":\"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/01\/lacnic-ipv6-only-2023.png\",\"width\":680,\"height\":330},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Portada\",\"item\":\"https:\/\/blog.lacnic.net\/en\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"IPv6 architecture and subnetting guide for network engineers and operators\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/blog.lacnic.net\/#website\",\"url\":\"https:\/\/blog.lacnic.net\/\",\"name\":\"LACNIC Blog\",\"description\":\"En el Blog de LACNIC encontrar\u00e1s art\u00edculos t\u00e9cnicos vinculados al desarrollo de Internet en la regi\u00f3n de Am\u00e9rica Latina y el Caribe.\",\"publisher\":{\"@id\":\"https:\/\/blog.lacnic.net\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/blog.lacnic.net\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/blog.lacnic.net\/#organization\",\"name\":\"LACNIC Blog\",\"url\":\"https:\/\/blog.lacnic.net\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/blog.lacnic.net\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/03\/lacnic-blog.svg\",\"contentUrl\":\"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/03\/lacnic-blog.svg\",\"caption\":\"LACNIC Blog\"},\"image\":{\"@id\":\"https:\/\/blog.lacnic.net\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/facebook.com\/lacnic\",\"https:\/\/x.com\/lacnic\",\"https:\/\/www.instagram.com\/lacnic\/?hl=es-la\",\"https:\/\/uy.linkedin.com\/company\/lacnic\",\"https:\/\/www.youtube.com\/user\/lacnicstaff\",\"https:\/\/www.lacnic.net\/podcast\"]},{\"@type\":\"Person\",\"@id\":\"https:\/\/blog.lacnic.net\/#\/schema\/person\/30da2f68d9b9f0123d5192afb790dea9\",\"name\":\"LACNIC\",\"url\":\"https:\/\/blog.lacnic.net\/en\/author\/staffadmin\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"LACNIC Blog | IPv6 architecture and subnetting guide for network engineers and operators","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:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/","og_locale":"en_US","og_type":"article","og_title":"LACNIC Blog | IPv6 architecture and subnetting guide for network engineers and operators","og_description":"By&nbsp;Daryll Swer&nbsp;\u2013 System &amp; Network Engineer This post is adapted from the original at&nbsp;Daryll\u2019s Blog. As networks continue to expand, the need for effective management of the Internet Protocol version 6 (IPv6) is becoming increasingly important. This guide is designed for network engineers and operators who are already familiar with the fundamentals and concepts of [&hellip;]","og_url":"https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/","og_site_name":"LACNIC Blog","article_publisher":"https:\/\/facebook.com\/lacnic","article_published_time":"2023-07-06T19:37:24+00:00","article_modified_time":"2024-11-07T12:54:55+00:00","og_image":[{"width":680,"height":330,"url":"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/01\/lacnic-ipv6-only-2023.png","type":"image\/png"}],"author":"LACNIC","twitter_card":"summary_large_image","twitter_creator":"@lacnic","twitter_site":"@lacnic","schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/#article","isPartOf":{"@id":"https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/"},"author":{"name":"LACNIC","@id":"https:\/\/blog.lacnic.net\/#\/schema\/person\/30da2f68d9b9f0123d5192afb790dea9"},"headline":"IPv6 architecture and subnetting guide for network engineers and operators","datePublished":"2023-07-06T19:37:24+00:00","dateModified":"2024-11-07T12:54:55+00:00","mainEntityOfPage":{"@id":"https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/"},"wordCount":6830,"commentCount":1,"publisher":{"@id":"https:\/\/blog.lacnic.net\/#organization"},"image":{"@id":"https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/#primaryimage"},"thumbnailUrl":"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/01\/lacnic-ipv6-only-2023.png","keywords":["IPv6"],"articleSection":["IPv6"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/","url":"https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/","name":"LACNIC Blog | IPv6 architecture and subnetting guide for network engineers and operators","isPartOf":{"@id":"https:\/\/blog.lacnic.net\/#website"},"primaryImageOfPage":{"@id":"https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/#primaryimage"},"image":{"@id":"https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/#primaryimage"},"thumbnailUrl":"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/01\/lacnic-ipv6-only-2023.png","datePublished":"2023-07-06T19:37:24+00:00","dateModified":"2024-11-07T12:54:55+00:00","breadcrumb":{"@id":"https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/#primaryimage","url":"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/01\/lacnic-ipv6-only-2023.png","contentUrl":"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/01\/lacnic-ipv6-only-2023.png","width":680,"height":330},{"@type":"BreadcrumbList","@id":"https:\/\/blog.lacnic.net\/en\/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Portada","item":"https:\/\/blog.lacnic.net\/en\/"},{"@type":"ListItem","position":2,"name":"IPv6 architecture and subnetting guide for network engineers and operators"}]},{"@type":"WebSite","@id":"https:\/\/blog.lacnic.net\/#website","url":"https:\/\/blog.lacnic.net\/","name":"LACNIC Blog","description":"En el Blog de LACNIC encontrar\u00e1s art\u00edculos t\u00e9cnicos vinculados al desarrollo de Internet en la regi\u00f3n de Am\u00e9rica Latina y el Caribe.","publisher":{"@id":"https:\/\/blog.lacnic.net\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/blog.lacnic.net\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/blog.lacnic.net\/#organization","name":"LACNIC Blog","url":"https:\/\/blog.lacnic.net\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/blog.lacnic.net\/#\/schema\/logo\/image\/","url":"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/03\/lacnic-blog.svg","contentUrl":"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/03\/lacnic-blog.svg","caption":"LACNIC Blog"},"image":{"@id":"https:\/\/blog.lacnic.net\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/facebook.com\/lacnic","https:\/\/x.com\/lacnic","https:\/\/www.instagram.com\/lacnic\/?hl=es-la","https:\/\/uy.linkedin.com\/company\/lacnic","https:\/\/www.youtube.com\/user\/lacnicstaff","https:\/\/www.lacnic.net\/podcast"]},{"@type":"Person","@id":"https:\/\/blog.lacnic.net\/#\/schema\/person\/30da2f68d9b9f0123d5192afb790dea9","name":"LACNIC","url":"https:\/\/blog.lacnic.net\/en\/author\/staffadmin\/"}]}},"jetpack_publicize_connections":[],"jetpack_featured_media_url":"https:\/\/blog.lacnic.net\/wp-content\/uploads\/2023\/01\/lacnic-ipv6-only-2023.png","jetpack_sharing_enabled":true,"wpml_current_locale":"en_US","wpml_translations":[{"locale":"es_ES","id":21599,"post_title":"Arquitectura IPv6 y subnetting: una gu\u00eda para ingenieros y operadores de redes","slug":"arquitectura-ipv6-y-subnetting-una-guia-para-ingenieros-y-operadores-de-redes","href":"https:\/\/blog.lacnic.net\/arquitectura-ipv6-y-subnetting-una-guia-para-ingenieros-y-operadores-de-redes\/"}],"_links":{"self":[{"href":"https:\/\/blog.lacnic.net\/en\/wp-json\/wp\/v2\/posts\/21612","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.lacnic.net\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.lacnic.net\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.lacnic.net\/en\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.lacnic.net\/en\/wp-json\/wp\/v2\/comments?post=21612"}],"version-history":[{"count":15,"href":"https:\/\/blog.lacnic.net\/en\/wp-json\/wp\/v2\/posts\/21612\/revisions"}],"predecessor-version":[{"id":27910,"href":"https:\/\/blog.lacnic.net\/en\/wp-json\/wp\/v2\/posts\/21612\/revisions\/27910"}],"acf:post":[{"embeddable":true,"href":"https:\/\/blog.lacnic.net\/en\/wp-json\/wp\/v2\/posts\/21211"},{"embeddable":true,"href":"https:\/\/blog.lacnic.net\/en\/wp-json\/wp\/v2\/posts\/21436"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.lacnic.net\/en\/wp-json\/wp\/v2\/media\/19576"}],"wp:attachment":[{"href":"https:\/\/blog.lacnic.net\/en\/wp-json\/wp\/v2\/media?parent=21612"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.lacnic.net\/en\/wp-json\/wp\/v2\/categories?post=21612"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.lacnic.net\/en\/wp-json\/wp\/v2\/tags?post=21612"},{"taxonomy":"archivo","embeddable":true,"href":"https:\/\/blog.lacnic.net\/en\/wp-json\/wp\/v2\/archivo?post=21612"},{"taxonomy":"taxonomy-authors","embeddable":true,"href":"https:\/\/blog.lacnic.net\/en\/wp-json\/wp\/v2\/taxonomy-authors?post=21612"},{"taxonomy":"tipo_autor","embeddable":true,"href":"https:\/\/blog.lacnic.net\/en\/wp-json\/wp\/v2\/tipo_autor?post=21612"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}