https://blog.apnic.net/2025/12/23/the-ipv4-address-swamp-the-new-normal/ Skip to content APNIC Home [icon-squar] MyAPNICAcademyBlogOrbitRExDASH Log in Home Whois and website search [ ] Search Advanced Whois Make a payment Close Search Search APNIC.net OR enter Whois database query [ ] * Get IP + Get IP + Make a payment + Membership + FAQs * Manage IP + MyAPNIC + Using Whois + IPv4 exhaustion + Go IPv6 + Routing Registry + Make a payment * Training + About + Events + APNIC Academy + Community Trainers + Courses * Events + Conferences + Calendar + Sponsorship + Code of Conduct * Insights + APNIC Labs + DASH to secure your networks + REx + Raw Data * Community + Orbit + Community demographics + Policy Development + Fellowship + Addressing policies + Internet community + Code of Conduct + Technical Assistance + Root servers + Security at APNIC + ISIF Asia + APNIC Foundation + NRO Number Council (NC) * Blog * Help Centre * About + APNIC Region + APNIC Membership + Executive Council + Service updates + Team + Annual Reports + Transparency + APNIC Survey + Corporate Documents + Publications Archive + Careers + Glossary * Contact * Advanced Whois * Make a payment * APNIC Home * Get IP + Get IP + Make a payment + Membership + FAQs * Manage IP + MyAPNIC + Using Whois + IPv4 exhaustion + Go IPv6 + Routing Registry + Make a payment * Training + About + Events + APNIC Academy + Community Trainers + Courses * Events + Conferences + Calendar + Sponsorship + Code of Conduct * Insights + APNIC Labs + DASH to secure your networks + REx + Raw Data * Community + Orbit + Community demographics + Policy Development + Fellowship + Addressing policies + Internet community + Code of Conduct + Technical Assistance + Root servers + Security at APNIC + ISIF Asia + APNIC Foundation + NRO Number Council (NC) * Blog * Help Centre * About + APNIC Region + APNIC Membership + Executive Council + Service updates + Team + Annual Reports + Transparency + APNIC Survey + Corporate Documents + Publications Archive + Careers + Glossary * Contact Skip to the article The IPv4 address swamp: The new normal By John Kristoff on 23 Dec 2025 Category: Tech matters Tags: Guest Post, IPv4, IPv4 exhaustion, measurement, security Tweet Blog home [Swamp_ft-555x202] IPv4 addresses have run out! It would have been fashionable to make this claim in 2011 when the last of the IPv4 addresses in the 'free pool' were allocated. It took several years, but today most of those remaining addresses are accounted for. How has the distribution and use of these last addresses been made in comparison to what was once commonly referred to as the IPv4 address swamp? Has IPv4 allocation and assignment changed for the better in the 21st century? Or are the prefixes getting smaller and even more diverse? What implications might this have on Internet security? Outside of its historical context, we rarely refer to swamp space any longer. Why is this? Perhaps it is because the majority of the IPv4 address space now closely resembles what was once an outlier in address management, organization, and structure? Perhaps there is a new swamp, just like the old swamp. Key findings * The legacy address 'swamp' is what a lot of the address space now resembles. * Address registrations and routes are growing in number, while prefix sizes are getting smaller. * Address volatility greatly affects the performance of threat mitigation. Background In the 1990s and well into the 21st century, network operators often referred to a portion of the IPv4 address space as 'The Swamp'. As far as we know, the phrase was never formally defined, but it was commonly used to refer to a subset of allocations in the original classful C address hierarchy. In practice, small /24 assignments first came out of 192/8, the start of the class C block. The negative connotation implied by the word 'swamp' suggests dirty, dishevelled, and inefficient. In terms of IP address management and routing, these attributes often fit. Network operators worried that if trends continued, the size of routing tables would quickly overwhelm router capacity. By the early 21st century, approximately 80% of the 192/8 address space was already assigned, and much of it was seen in the Internet routing tables as many disaggregated /24 routes. The sheer number and diverse assignments of these /24 prefixes effectively prohibited address aggregation. Over time, the routing system evolved to handle an ever-increasing number of prefixes, but few, if any, routers from the early days would be able to load and compute the routing tables that exist today. Small prefixes and the routing table entries continue to grow. As of this writing, a full IPv4 routing table is approximately 1 million entries. Two decades prior, there were only 150,000 routes. When people suggest the Internet is a collection of loosely cooperating Autonomous Systems, the swamp might have been considered 'exhibit A', foreshadowing the new normal of IPv4 addressing disorganization. The last of the /8 IPv4 address allocations from the Internet Assigned Numbers Authority (IANA) to Regional Internet Registries (RIRs) were made in 2011. Obtaining previously unassigned IPv4 addresses is now becoming a thing of the past. IPv4 address scarcity has led to a variety of reactions from users and the market. Large blocks of assigned IPv4 addresses (/16 or larger) are routinely transferred from one holder to another for hundreds of thousands of dollars. Waiting lists and address-leasing companies are now part of the IPv4 address assignment landscape. Many organizations with lots of addresses in the legacy Class A or B networks have split them up or transferred them to the highest bidder. It is well known that the big cloud providers, such as Amazon and Microsoft, have gobbled up many IPv4 address blocks on the market, divvying them up across their global data centre infrastructure. Network Address Translators (NATs) continue to be widely used and relied upon. Interest in and deployment growth of IPv6 addressing continues to grow every year. We began to wonder about all these changes, especially considering how the IPv4 address space structure and organization have changed. The implications the new normal has on routing are obvious, but less well understood is what effect these changes have had on address and network reputation. Maybe we don't use the term swamp anymore because, increasingly, the entire IPv4 address space has all the telltale signs of the original swamp? The last of the free pool IP address assignment for small address blocks in the original class C hierarchy was primarily first drawn from 192/8 and almost entirely in /24 chunks at a time. A /24 prefix is widely observed to be the smallest block of addresses that can be successfully announced and seen by most Internet routers. At the turn of the century, approximately 10% of the total number of IPv4 route table entries may have come from just the sub-prefixes in 192/8 alone. Then and today, all /24 route advertisements account for more than 50% of all routing table entries, although the trend hovers closer to 60% today. See Figure 1 for a recent look at the IPv4 routing table by prefix size distribution. Figure 1 -- IPv4 routes by prefix size.Figure 1 -- IPv4 routes by prefix size. In February 2011, IANA distributed the last five remaining IPv4 /8 blocks of addresses to each of the RIRs (AFRINIC, APNIC, ARIN, LACNIC, and RIPE). We wondered if registration and assignment of prefixes would resemble the 192/8 swamp or something different. Understanding how these new blocks of previously unallocated addresses were distributed might give us clues about general IPv4 addressing usage trends in other portions of the address space. Note: Registries denote a status for the address space they manage. For our purposes, we focus on address blocks RIRs have designated as assigned or allocated. The former is when an address block has been delegated from the RIR to an end user, such as an ISP, while the latter suggests it hasn't yet been assigned but is available for distribution. However, we have found that the distinction between these two states is often unclear. We group both types of address blocks together for simplicity, imperfect as this may be. Other designations can include 'available' and 'reserved', which we ignore in our analysis unless otherwise specified. At the end of 2011, there were very few allocations and assignments made from these five blocks. By 2014, two registries, the RIPE NCC and LACNIC, had allocated or assigned almost all this new address space, APNIC and ARIN, about one-third, and AFRINIC had yet to make any registrations. Today, all RIRs have allocated and assigned most, if not practically all, addresses in the last /8s from the remaining free pool. See tables 1, 2, and 3 below for details. RIR /8 Addresses allocated / assigned % of total AFRINIC 102 0 0% APNIC 103 823,296 5% ARN 104 0 0% LACNIC 178 0 0% RIPE 185 4,194,304 25% Table 1 -- Last of the IPv4 free pool 2011. RIR /8 Addresses allocated / assigned % of total AFRINIC 102 0 0% APNIC 103 4,987,392 30% ARN 104 16,606,208 99% LACNIC 178 16,776,192 99% RIPE 185 5,291,776 32% Table 2 -- Last of the IPv4 free pool 2014. RIR /8 Addresses allocated / assigned % of total AFRINIC 102 14,532,864 87% APNIC 103 16,261,888 97% ARN 104 16,773,120 99% LACNIC 178 16,777,216 100% RIPE 185 16,677,888 99% Table 3 -- Last of the IPv4 free pool 2024. We could have guessed that practically all available IPv4 addresses would ultimately be put to use. We can observe some patterns in the rate of allocation and assignment by RIR, which may say something about the demand in their regions and their distribution policies. However, what might be more useful to see is the size of blocks of addresses within these last free pools as they are allocated, assigned, and routed. We know that address registrations and routing are often incongruous, but we can get a sense of the structure, especially compared with the 192/8 block, to see whether or not usage for all the address space gravitates toward one recognizable pattern. In Figure 2 below, we plot the distribution of address block sizes for the last five free pool allocations from IANA (102/8, 103/8, 104/ 8, 179/8, and 185/8) in 2014. We separate them by their corresponding registry. Note, it is possible that a registrant moved its assignment to another registry, but this is relatively uncommon, and we don't believe it markedly alters any observations made. AFRINIC had not yet begun distributing prefixes from its 102/8 at that time. For the others, the average size of the prefix varied but tended toward the small side of around /22 for all registries. The picture changes slightly when we fast-forward to 2024. Figure 2 -- IPv4 last free pool registration prefix sizes (2014). Figure 2 -- IPv4 last free pool registration prefix sizes (2014). By the end of 2024, AFRINIC had distributed the majority of its 102/8 address pool. The average size of address blocks from APNIC and RIPE appears to have remained largely unchanged. ARIN and LACNIC, however, appear to now have smaller blocks than 10 years ago. Also note RIPE appears to have a few block registrations smaller than a /24. The reasons for this can vary, but often contiguous 'micro' registrations are ultimately assigned to the same entity that chooses to separately manage even smaller portions of a larger address space block. Figure 3 below compares the distribution of block size registration with legacy 192/8. Figure 3 -- IPv4 last free pool registration prefix sizes (2024). Figure 3 -- IPv4 last free pool registration prefix sizes (2024). The majority of 192/8 address space is currently managed by ARIN, but a sizeable portion is managed by the RIPE NCC and other smaller portions by the remaining registries. In Figure 4, we can clearly see block sizes tend toward a /24. This is not particularly surprising. Figure 4 -- IPv4 192/8 registration prefix sizes (2024).Figure 4 -- IPv4 192/8 registration prefix sizes (2024). We also note that blocks of addresses are often reserved throughout the entire IPv4 address space. For example, 192.168.0.0/16, you may know, is reserved for private use as defined in IETF RFC 1918 -- address allocation for private Internets. This sub-prefix is not allocated or managed by any of the RIRs. Address registration paints a partial picture of distribution and usage. We can draw a more complete picture by considering how blocks of addresses appear in the Internet routing tables. We will limit our scope here to a recent view of an Internet routing table at the end of 2024. We can then make some comparisons to what appears in the registries and what appears in a typical routing table. There is often overlap, but the two are incongruent. Considering Border Gateway Protocol (BGP) Recall that the last free pool blocks IANA delegated to the RIRs eventually became nearly completely assigned and allocated. Nearly 80% of legacy 192/8 blocks were accounted for by as early as 2004. With practically all the address space in these six /8s assigned and allocated, we would expect this to be reflected in the Internet's routing tables. Something interesting appears, however, when you compare IP address registration and IP address routing. Except in the case of route leaks or hijacking, we might expect the coverage of these address spaces in the routing table to lag registration. The difference, however, is quite striking. We've reconstructed the tables this time with the 192/8 prefix and routing information added (see tables 4 through 6 below). RIR /8 Allocated / % of Routes Addresses % of assigned total total AFRINIC 102 0 0% 0 0 0% APNIC 103 823,296 5% 909 439,040 2.6% ARIN 104 0 0% 0 0 0% LACNIC 179 0 0% 0 0 0% RIPE 185 4,194,304 25% 3 67,840 0.4% legacy 192 12,581,120 75% 7,373 5,980,928 36% Table 4 -- IP address registrations and routes (2011). RIR /8 Allocated / % of Routes Addresses % of assigned total total AFRINIC 102 0 0% 12 721,920 4% APNIC 103 4,987,392 30% 8,919 3,196,160 19% ARIN 104 16,606,208 99% 1,961 15,274,560 91% LACNIC 179 16,776,192 99% 2,976 16,011,264 95% RIPE 185 5,291,776 32% 6,255 3,795,968 23% legacy 192 15,900,672 95% 10,343 9,162,757 55% Table 5 -- IP address registrations and routes (2014). RIR /8 Allocated / % of Routes Addresses % of assigned total total AFRINIC 102 14,532,864 87% 7,970 13,626,112 81% APNIC 103 16,261,888 97% 42,660 12,150,728 72% ARIN 104 16,773,120 99% 7,033 15,991,808 95% LACNIC 179 16,777,216 100% 5,973 16,565,760 99% RIPE 185 16,677,888 99% 34,143 14,578,176 87% legacy 192 16,585,728 99% 14,526 10,320,960 62% Table 6 -- IP address registrations and routes (2024). These tables provide a clearer picture of IP address assignment and usage. Independently, registration and routes follow a similar trend. Their numbers increase over time. The differences, however, are stark. The number of routes covering 192/8 in 2024 was a little over 14,000, but the proportion of the address space these routes covered was only slightly more than 62% of the total possible, which means nearly two-fifths of the 192/8 address pool is not directly reachable on the Internet. As we've mentioned, there are reserved allocations in this range, but their numbers would not make up for the bulk of missing routes. All last free pool /8s have better route coverage in 2024. We could make some educated guesses or conduct more analysis to understand why, but we believe ultimately it comes down to the 'legacy' of 192/8. More interesting to us is not just that the last free pool space is more accessible, but that the number of routes covering each varies significantly. For example, we see more than 42,000 routes covering the 103/8 (APNIC) block, but only slightly fewer than 6,000 for 179/8 (LACNIC), and the latter covers nearly 100% of /8 while only 72% of APNIC's 103/8 is covered. What is going on here? A look back at Figure 4 gives a clue. LACNIC's assignment of addresses in its /8 tends to be larger than APNIC's, and this is ultimately reflected in routing. Consequently, we see a lot more smaller prefixes such as / 23s and /24s for APNIC prefixes in the routing table. Another observation that lends support to this article's thesis is that the last of the free pool /8s looks surprisingly like a swamp when compared with the original 192/8 swamp. There are many small registrations and routes to many different entities. What distinguishes the legacy swamp from the modern swamp seems to be little more than age. Recommendations To detect and mitigate abusive, ever-changing networks of varying size and duration, we recommend the following: * Real-time visibility into volumetric traffic floods and distributed attack patterns. Tools such as NETSCOUT Arbor Sightline can help surface early signs of trouble and trigger flow specification and Remotely Triggered Black Hole (RTBH) defences to upstream providers. * Proactive mitigation with automated systems such as Arbor Threat Mitigation System (TMS) or Arbor Edge Defense (AED). These can stop both volumetric floods and more complex, multivector attacks. * Intelligence-driven defence with feeds such as NETSCOUT's ATLAS Intelligence Feed (AIF). These provide context information, what's trending, who's being targeted, and how actors are evolving. Staying ahead of threat actors is an ever-changing job and requires a broad view of where these attacks come from, how they operate, and where they could strike next. Conclusion We know IP address prefixes have become increasingly transient. That is, prefixes move from registrant to registrant, often across the world after an exchange. As modern IP address volatility proliferates, an association of activity and reputation with addresses rapidly changes as well. An address block used by a low-cost hosting provider has a very different profile than when that address is used by end users on Wi-Fi hot spots, for example. We have been experiencing increasing Distributed Denial-of-Service (DDoS) attacks, scanning, scraping, proxy, and address reputation volatility in our data for a while now. You probably have as well. This instability in address/reputation pairing has implications for how well security threat mitigation services can perform. There is a risk for false positives, false negatives, over-blocking, and under-blocking. This is an area of work we are increasingly focused on to help better understand and respond to security threats in this new normal. John Kristoff (Mastodon) is a PhD candidate in Computer Science at the University of Illinois Chicago studying under the tutelage of Chris Kanich. He is a co-founder and operator for Dataplane.org. He is also a principal analyst at NETSCOUT on the ATLAS Security Engineering and Response Team (ASERT). Originally published at NETSCOUT ASERT blog. Rate this article --------------------------------------------------------------------- The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog. Leave a Reply Cancel reply Your email address will not be published. Required fields are marked * [ ] [ ] [ ] [ ] [ ] [ ] [ ] Comment * [ ] Name * [ ] Email * [ ] [ ] Save my name and email in this browser for the next time I comment. [ ] Yes, add me to your mailing list [ ] Notify me of follow-up comments via email. You can also subscribe without commenting. [Post Comment] [ ] [ ] [ ] [ ] [ ] [ ] [ ] D[ ] Top Get Updates Please leave this field empty[ ] Email *[ ] Show options [Subscribe!] Select list(s):[ ] Daily[*] Weekly Thanks for subscribing! Check your inbox or spam folder to confirm your subscription. Authors * Adli Wahid * Aftab Siddiqui * Geoff Huston * George Michaelson * Jen Linkova * Jia Rong Low * Job Snijders * Kathleen Moriarty * Ulrich Speidel * Vitaly Kamluk * A Khalil Azizi * A S M Rizvi * AbdelRahman Abdou * Abhishek Jain * Abu Sufian * Achie Atienza * Adam Gosling * Adam McFillin * Adam Oest * Adeel Sadiq * Adiel Akplogan * Adisorn Lertsinsrubtavee * Adli Wahid * Adrian Farrel * Adrian Wan * Afifa Abbas * Afsheen Saadat * Aftab Siddiqui * Agustin Formoso * Ahmad Darki * Ajay Kumar * Akimichi Ogawa * Alain Aina * Alan Mauldin * Albert Gran Alcoz * Alden Hilton * Alec Muffett * Alejandro Acosta * Alex Band * Alex Boten * Alex Turing * Alex Yen * Alexander Azimov * Alexander Kozlov * Alfred Arouna * Ali Abedi * Ali Norouzi * Amanda H A Watson * Amaury Van Bemten * Amreesh Phokeer * Amrita Choudhury * Anand Buddhdev * Anant Shah * Andra Lutu * Andre Gelderblom * Andreas Dewes * Andreas Reuter * Andree Toonk * Andrei Robachevsky * Andrew Ayer * Andrew Campling * Andrew Cormack * Andrew Cushen * Andrew Ferguson * Andrew Gray * Andrew Sullivan * Andrew Toimoana * Andrijana Todosijevic * Andy Mindnich * Andy Newton * Anju Mangal * Anna Maria Mandalari * Annaliza Mulingbayan * Anosh Khan * Anriette Esterhuysen * Anthony Lee * Anton Strydom * Anup Changaroth * Anurag Bhatia * APNIC * Apoorv Shukla * Arash Molavi Kakhki * Arian Niaki * Aris Tzermias * Arjuna Sathiaseelan * Arlin Kokkelmans * Arth Paulite * Arthur Gilly * Artyom Gavrichenkov * Arun Neelicattu * Asad Ali * Asanka Sayakkara * Ashil Oogarah * Ashwin Kumar * Ashwin Rangan * Athina Fragkouli * Audrey Randall * Aurelien Aptel * Austin Hounsel * Austin Ruckstuhl * Avery Pennarun * Ayesha Iftikhar * Aysha Labiba * Ayush Mishra * Azfar Adib * Azhar Khuwaja * Azura Mat Salim * Baojun Liu * Baptiste Jonglez * Barry Greene * Bart Hogeveen * Basileal Imana * Bastian Kanbach * Batmagnai Erdene * Bayar Batjargal * Beau Gieskens * Ben Cox * Ben Du * Ben Schwartz * Benjz Gerard Sevilla * Benno Overeinder * Berislav Todorovic * Bert Hubert * Bhadrika Magan * Bhumika Sapkota * Bikram Shrestha * Bill Hess * Bill Stearns * Bill Woodcock * Bjorn Teigen * Blake Anderson * Blandine Cousin * Blas Trigueros * Brandon Hitzel * Brenda Buwu * Brenden Kuerbis * Brent Carey * Brett Bralley * Brian Carpenter * Brian Nisbet * Brian Trammell * Brianna Boudreau * Bruce Davie * Bruce Spang * Byambajargal Jamsran * Byron Ellacott * Byungjin Jun * Cameron Steel * Carsten Strotmann * Caspar Schutijser * Cecilia Testart * Cengiz Alaettinoglu * CF Chui * Champika Wijayatunga * Charith Amarasinghe * Che-Hoo Cheng * Cheeyong Tay * Cherie Lagakali * Chia Ling (Jolin) Chan * Chika Yoshimura * Ching-Heng Ku * Chris Amin * Chris Buckridge * Chris Grundemann * Chris Parker * Chris Ritzo * Chris Siebenmann * Christian Giese * Christian Huitema * Christoph Dietzel * Christopher Hawker * Chuan Jiang * Ciprian Popoviciu * Clarence Filsfils * Claudio Jeker * Clemens Mosig * Colin Perkins * Constance Bommelaer * Constantin Sander * Constanze Dietrich * Cordian Daniluk * Craig Miller * Craig Ng * Craig Rowland * Dale Roberts * Dan Fidler * Dan Groshev * Dan Li * Daniel Dib * Daniel Kopp * Danilo Giordano * Danny Alex Lachos Perez * Danny Pinto * Daryll Swer * Dashzeveg Baatartsogt * Dave Mill * Dave Phelan * David Anderson * David Burkett * David Dawson * David Holder * David Holsgrove * David Huberman * Dean Pemberton * Debashis Pal * Debopam Bhattacherjee * Deepak Vasisht * Denesh Bhabuta * Dennis Baaten * Desiree Miloshevic * Dewangga Alam * Dewole Ajao * Dhruv Dhody * Di Ma * Diego Pino Garcia * Dinesh Bhatia * Diptanshu Singh * Dirk Doesburg * Dirk Trossen * Dmytro Shypovalov * Donatas Abraitis * Donika Mirdita * Doug Madory * Doug Montgomery * Dr Bahaa Al-Musawi * Dr Govind * Drikus Brits * Duane Wessels * Duncan Macintosh * E. Marie Brierley * Ebrima Jaw * Ed Horley * Edward Lewis * Edwin Sandys * Ege Cem Kirci * Eliot Lear * Elizabeth Krumbach Joseph * Ellisha Heppner * Elly Tawhai * Elvin Prasad * Emile Aben * Emily Gallarde * Emily Stark * Emir Beganovic * Eneken Tikk * Enno Rey * Enric Pujol * Eric Lawrence * Eric Loos * Eric Vyncke * Erik Hjelmvik * Erik Rye * Erin Scherer * Eshaan Bansal * Esteban Carisimo * Eugene Bogomazov * Eunju Kang * Eunju Pak * Eyal Estrin * Fabian Bustamante * Fahad Hilal * Fakrul Alam * Farha Diba * Fenglu Zhang * Ferenc Fejes * Fernando Gont * Flavia Salutari * Flavio Luciani * Florentin Rochet * Florian Holzbauer * Florian Steurer * Florian Streibelt * Foy Shiver * Francesco Ferreri * Francesco Sassi * Franck Martin * Francois Michel * Frane Maroevic * Frank Denis * Frank Herberg * Franziska Lichtblau * Fred Christopher * Fred Templin * Fredrik Lindeberg * Ganga R Dhungyel * Gaurab Raj Upadhaya * Gautam Akiwate * Gavin Reid * Gavin Tweedie * Geoff Huston * George Kuo * George Michaelson * George Odagi * George Sadowsky * George Salisbury * Giacomo Giuliari * Gianmarco Pagani * Gina Mahe * Giovane Moura * Gomer Padong * Gonchig Altansukh * Gordon King * Greg Ferro * Greg Hankins * Gregory Mounier * Guangliang Pan * Guillermo Baltra * Guoliang Yang * GZ Kabir * Ha Dao * Haisheng Yu * Han Zhang * Hanna Kreitem * Hannah Durack * Hanno Bock * Hans Petter Holen * Harish Chowdhary * Haya Schulmann * Helen Hollins * Herbert Wolverson * Herve Clement * Hideyuki Sasaki * Hinne Hettema * Hiroki Kawabata * Hiroko Kamata * Hiromu Shiozawa * Hisham Ibrahim * Hoang Nguyen Phong * Holly Bergen * Houlin Zhao * Hyeonmin Lee * Hyojoon Kim * Ignacio Castro * Ihita Gangavarpu * Ike Kunze * Ilker Nadi Bozkurt * Imtiaz Rahman * Indya Bolton * Ioana Livadariu * Italo Cunha * Ivan Ristic * Ivana Tomic * Ivo A. Ivanov * Ivy Yip * Izumi Okutani * Jaclyn Knight * Jacob Davis * Jacob Ginesin * Jahangir Hossain * Jake Bauer * Jake Flint * Jake Holland * James Ah Wai * James Bensley * James Kettle * James Pavur * James Richards * James Shank * Jamie Gillespie * Jan Doskocil * Jan Harm Kuipers * Jan Ruth * Jan Schaumann * Jan Zorz * Jan-Piet Mens * Jane Yen * Jannik Peters * Jari Arkko * Jason Livingood * Jason Smith * Jasper den Hertog * Jawad Ahmed * Jay Daley * Jay Ford * Jeff Chan * Jeff Fry * Jeff Man * Jeff Osborn * Jen Linkova * Jenine Beekhuyzen * Jens Link * Jeremy Harrison * Jerry Lundstrom * Jessica Shen * Jessica Wei * Jethro Webston * Jia Rong Low * Jilong Wang * Jim Cowie * Jim Forster * Jim Vella * Jimmy Lim * Jing Qiao * Jinghua Bai * Jinwei Zhao * Joanna Kulesza * Joao L. Sobrinho * Joao Luis Silva Damas * Joao M. Ceron * Job Snijders * Joel Jaeggli * Johanna Amann * Johannes Krupp * Johannes Weber * Johannes Zirngibl * John Althouse * John Bambenek * John Curran * John Garrity * John Jack * John Jason Brzozowski * John Kristoff * John Scudder * John Welborn * Jonathan Brewer * Jonathan Magnusson * Jordan Carter * Jordan Jueckstock * Jordi Paillisse * Jordi Palet Martinez * Josef Gustafsson * Joseph Salowey * Joy Chan * Joyce Chen * Juan Ramon Santana * Juha Saarinen * Julia Evans * Julian Martin Del Fiore * Julien Gamba * Jun Murai * Justin Loye * Justin Ryburn * Justin Wilson * Kaajal Kumar * Kaan Onarlioglu * Kanagaraj Krishna * Karan Sharma * Karel Hynek * Karl Lovink * Karla Skarda * Kasek Galgal * Kashyap Thimmaraju * Katherine Izhikevich * Kathleen Moriarty * Katsuyasu Toyama * Kavya Bhat * Kazunori Fujiwara * Ke Ma * Keisuke Kamata * Kemal Sanjta * Kenjiro Cho * Kenny Huang * Kenrick Lin * Kensuke Fukuda * Kevin Backhouse * Kevin Bock * Kevin Jin * Kevin Ku * Kevin Meynell * Kevin Vermeulen * Kevon Swift * Keyu Man * Khee Hong Loke * Khwaja Zubair Sediqi * Kijush Maharjan * Kiruthika Devaraj * Klee Aiken * Kobayashi Masayuki * Koen van Hove * Koichi Kunitake * Koki Nakagawa * Konrad Wolsing * Korian Edeline * Kostas Zorbadelos * Kris Shrishak * Kurt Lindqvist * Kyle Carter * Kyle Drake * Kyle Schomp * Lan Wei * Lari Huttunen * Lars Prehn * Lars-Johan Liman * Leandro Bertholdo * Leandro Navarro * Lee Howard * Leigh Metcalf * Lenore Zuck * Leo Vegoda * Leonid Todorov * Leslie Daigle * Lia Hestina * Liang Wang * Liang Zhao * Liangcheng Yu * Libin Liu * Lindsay Graham * Linjian Song * Lisa Bruder * Lisa Corness * Lisandro Ubiedo * Liz Izhikevich * Loba Olopade * Lorenzo Cogotti * Louise Tromp * Lu Zhang * Luca Sani * Lucas Pardue * Luke Thompson * Luuk Hendriks * M. Yasir M. Haq * Maarten Botterman * Maarten Wullink * Maciej Korczynski * Madeline Carr * Maemura Akinori * Mai Thu Thuy * Mailelatamai Halatuituia * Major Hayden * Makito Lay * Mallory Knodel * Manaf Gharaibeh * Mannat Kaur * Mansour Ganji * Marc Bruyere * Marcin Nawrocki * Marco Chiesa * Marco Cilloni * Marco Hogewoning * Marcus Brinkmann * Marcus Keane * Marek Majkowski * Maria Namestnikova * Maria Theresa Perez * Mariano Scazzariello * Mariko Kobayashi * Marilyn Zhang * Mario Loffredo * Mark Andrews * Mark Karpilovskij * Mark Nottingham * Mark Prior * Mark Smith * Mark Tinka * Markus Dahlmanns * Markus Legner * Markus Sosnowski * Marta Burocchi * Marten Porte * Martin Hannigan * Martin Hoffmann * Martin Langer * Martin Thomson * Martin Winter * Martino Trevisan * Mary Rose Ofianga-Rontal * Masanori Yajima * Masataka Mawatari * Massimo Candela * Mat Ford * Matsuzaki Yoshinobu * Matt Larson * Matt Oh * Matt Palmer * Matt Ringel * Matt Stith * Matthew James * Matthew Thomas * Matthias Wichtlhuber * Matthijs Mekking * Mattijs Jonker * Max von Hippel * Maxime Mouchet * Maxime Piraux * Md Abdul Awal * Md. Kamruzzaman Khan * Megan Baker * Melchior Aelmans * Melody Bendindang * Merike Kaeo * Metin Acikalin * Michael Clare * Michael Kende * Michael Patterson * Michael Rabinovich * Michael Schapira * Michael Schneider * Michael Waidner * Michelle Thorne * Mika Kerttunen * Mike Hollyman * Mike Hwang * Mike Kosek * Min Sung Jung * Mingming Zhang * Mingwei Zhang * Mingxuan Liu * Minzhao Lyu * Miwa Fujii * Mohamad Dikshie Fauzie * Mohamed Awnallah * Mohamed Boucadair * Mohamed Kassem * Mohammad Larosh Khan * Molay Ghosh * Momoka Yamamoto * Moritz Muller * Mubashir Sargana * Muhammad Moinur Rahman * Muhammad Yasir Shamim * Mujtaba Hussain * Mukhammad Andri Setiawan * Munkhbat Gansukh * Muzamer Mohd Azalan * Nachiket Kondhalkar * Nadir Hassan * Nafeez Islam * Nalini Elkins * Narayan G * Narelle Clark * Natale Bianchi * Nate Sales * Nathalie Romo Moreno * Nathalie Trenaman * Neeti Biyani * Neta Rozen Schiff * Nick Buraglio * Nick Hilliard * Nick Janetakis * Nick Nugent * Nico Schottelius * Nicola Rustignoli * Nicole Wajer * Niels Provos * Nihit Tandon * Niklas Vogel * Nikolai Hampton * Nikos Kostopoulos * Nils Wisiol * Nina Bargisen * Nirav Atre * Nooshin Eghbal * Nor Fadzilah Abdullah * Nowmay Opalinski * Nurul Islam Roman * Nusenu * Nyamkhand Buluukhuu * Oanh Nguyen * Oky Tria Saputra * Olafur Gudmundsson * Olamide Omolola * Oliver Gasser * Oliver Michel * Olivier Hureau * Olivier Tilmans * Omar Alrawi * Omar Ansari * Ondrej Caletka * Ondrej Sury * Otto Moerbeek * Pablo Hinojosa * Paolo Lucente * Paresh Khatri * Parkpoom Tripatana * Pasan Lamahewa * Pascal Huppert * Patrick McManus * Patrick Sattler * Patrik Faltstrom * Paul Dale * Paul Grubbs * Paul Wilson * Pavel Odintsov * Pawel Foremski * Pawel Urbanek * Pedro Marcos * Pengxiong Zhu * Pete Sclafani * Pete Stevens * Peter Blee * Peter Hansteen * Peter Lowe * Peter Maynard * Peter Peele * Petr Spacek * Petros Gigis * Phil Lavin * Phil Mawson * Philip Homburg * Philip Paeps * Philip Smith * Philipp Jeitner * Philipp Richter * Pier Carlo Chiodi * Pim van Pelt * Piotr Kijewski * Platon Kotzias * Pouyan Fotouhi Tehrani * Pranav Kondala * Praneet Kaur * Pubudu Jayasinghe * Qasim Lone * Quincy Liao * Rachee Singh * Rafael Cintra * Raffaele Sommese * Raffaele Zullo * Rahul Makhija * Rajnesh Singh * Ralph Dolmans * Ralph Holz * Ram Sundara Raman * Ramakrishna Padmanabhan * Rami Al-Dalky * Ramin Yazdani * Ran Ben Basat * Ranysha Ware * Raphael Hiesgen * Raquel Rugani Lage * Raskia Nayanajith * Ray Bellis * Rebekah Houser * Remi Gacogne * Rene Bakker * Rene Wilhelm * Renee Burton * Richard Cziva * Richard Jimmerson * Richard Nelson * Richard Patterson * Richard Read * Rick McElroy * Rishabh Chhabra * Rob Schult * Robbie Mitchell * Robert Alexander * Robert Kisteleki * Robin Marx * Roderick Fanou * Roger Meyer * Rohana Palliyaguru * Roland Meier * Roland van Rijswijk-Deij * Rolf Winter * Romain Fontugne * Ron Bonica * Ron Winward * Ronald van Kleunen * Rowena Schoo * Roy Arends * Rudiger Birkner * Russ White * Ryan Beckett * Ryan Gerstenkorn * Ryo Nakamura * Sachin Ashok * Safiqul Islam * Said Jawad Saidi * Said Zazai * Saima Nisar * Salvatore Cuzzilla * Sam Sham * Samaneh Tajalizadehkhoob * Samantha Douglas * Samantha Frank * Samit Jana * Samuel Steffen * Sandra Davey * Sandra Siby * Sangeetha Abdu Jyothi * Sanjaya * Sara Dickinson * Sarah Escandor-Tomas * Sarah McAree * Sarmad Hussain * Sarvesh Mathi * Sasha Romijn * Satadal Sengupta * Satoru Matsushima * Satoru Tsurumaki * Sayda Kamrun Jahan Ripa * Scott Hollenbeck * Scott Shenker * Sebastian Castro * Sebastian Neef * Sebastian Zander * Sebastien Meriot * Seiichi Kawamura * Seluvaia Kauvaka * Seth Schoen * Shah Sahari * Shahee Mirza * Shahzeb Mustafa * Shamim Reza * Shamsullah Shams * Shane Alcock * Shane Kerr * Sharada Yeluri * Sharat Chandra Madanapalli * Shayan Azizi * Sheetal Kumar * Sheikh Md Seum * Shermaine Yung * Sherry Shek * Sheryl Hermoso * Shian-Shyong Tseng * Shinoj Pittandavida * Shishio Tsuchiya * Shivan Sahib * Shoko Nakai * Shuai Hao * Shucheng Liu * Shumon Huque * Shusei Tomonaga * Shyam Krishna Khadka * Siena Perry * Simon Baroi * Simon Bauer * Simran Patil * Siva Kesava * Sivaram Ramanathan * Sofia Silva Berenguer * Sonam Keba * Song Bing * Spiros Thanasoulas * Srikanth Sundaresan * Srimal Andrahennadi * Stanley Osao * Stefan Mehner * Stefan Ubbink * Steinthor Bjarnason * Stephan Marwedel * Stephane Bortzmeyer * Stephen McQuistin * Stephen Ryan * Stephen Strowes * Steve Crocker * Steve Santorelli * Stijn Pletinckx * Subha Shamarukh * Subhashini Kadurugasyaya * Sue Graves * Suetena Faatuuala Loia * Suksit Sripitchayaphan * Sunny Chendi * Suresh Krishnan * Susan Forney * Suvam Basak * Svaradiva Devi * Swapneel Patnekar * Swaran Ravindra * Sylvain Cortes * Sylvia Cadena * Szymon Trocha * Taejoong Chung * Taiji Kimura * Talha Paracha * Tan Kean Siong * Tan Tin Wee * Tanya Shreedhar * Tashi Phuntsho * Teav Sovandara * Temitope Lawal * Terry Sweetser * Teun Vink * Thein Myint Khine * Theo Jepsen * Theophilus A. Benson * Thijs van den Hout * Thomas Holterbach * Thomas King * Thomas Koch * Thomas Krenc * Thomas Liske * Thomas Millar * Thomas Patzke * Thomas Scheffler * Thomas Wirtgen * Thy Boskovic * Thymen Wabeke * Tianxiang Dai * Tim Bruijnzeels * Tim Chown * Tim Fiola * Tim Raphael * Timm Bottger * Timo Longin * Timothy Hildred * Timothy Winters * Tiong Beng Ng * Tobias Fiebig * Todd Arnold * Tom Barbette * Tom Carpay * Tom Coffeen * Tom Do * Tom Harrison * Tom Hollingsworth * Tom Krizek * Tom Perrine * Tomek Mrugalski * Tommaso Caiazzi * Tomoaki Tani * Tony Finch * Tony Li * Tony Scheid * Tony Smith * Tony Tauber * Torsten Zimmermann * Trinh Viet Doan * Truong Khanh Huyen * Tuan Nguyen * Tugsorshikh Badarch * Tushar Swamy * Ulafala Viliamu * Ulrich Hauser * Ulrich Speidel * Usama Naseer * Uta Meier-Hahn * Vanessa Maria Fernandes * Vashkar Bhattacharjee * Vasileios Giotsas * Vasileios Kotronis * Vasilis Chryssos * Venkat Arun * Veronika McKillop * Vesna Manojlovic * Vicky Risk * Vijay Sivaraman * Vijay Varadharajan * Viktor Dukhovni * Vinay Kumar * Vincent Bernat * Vincentas Grinius * Vitaly Kamluk * Vittorio Bertola * Vivek Nigam * Vivien Maidaborn * W K Shiu * Wang Hao * Wanqing Tu * Warren Finch * Warren Kumari * Wassie Goushe * Wataru Ohgai * Wayne Thayer * Wen-Tsung Chang * Werachart Muttitanon * Wes Hardaker * Wilaiwan Phanarin * Wilhelm Boeddinghaus * Willem Toorop * William Lu * Willy Sutrisno * Winfried Tilanus * Wita Laksono * Wout de Natris * Wouter de Vries * Xiang Li * Xiao Zhang * Xiaohong Deng * Xiaoqi Chen * Xing Li * Xinlei Yang * Xuewei Feng * Yali Liu * Yeo Lee Chin * Yevheniya Nosyk * Yi Cao * Yihao Chen * Yiming Zhang * Ying Tian * Ying-Chu Chen * Yoshibumi Suematsu * Yoshinori Takesako * Yoshitaka Aharen * Younghwan Choi * Yuedong Zhang * Yunfei Ma * Yurie Ito * Yury Zhauniarovich * Yuta Takata * Yuxiang Yang * Zachary Bischof * Zaid Ali Kahn * Zaifeng Zhang * Zain Shamsi * Zen Ng * Zeqi Lai * Zhenyu Li * Zhiyi Chen * Zili Meng * Zinan Lin * Zolzaya Shagdar Show All (984) Show Pinned (10) Tags * APNIC Foundation * APNIC Training * Australia * BGP * capacity development * CERTs * China * DNS * DNSSEC * Event Wrap * Guest Post * How to * IANA * ICANN * IETF * IGF * India * Indonesia * Internet Governance * IPv4 * IPv6 * ISIF Asia * ITU * IXPs * Japan * measurement * networking * NOGs * NRO * opinion * Pacific * peering * podcast * Policy * RIPE NCC * RIRs * ROAs * routing * RPKI * security * TCP * Three of the best * TLS * tools * Whois Related Articles * network-securityPrivacy and networking: Part 3 -- Is an IP address... by Russ White May 18, 2023 Guest Post: Does an IP address need to be treated like other Personally Identifiable Information? * Deploy SAVWhy is Source Address Validation still a problem? by Qasim Lone May 3, 2023 Guest Post: How can we make make widespread SAV deployment attractive? * Subnetting_FTBehavioural differences of IPv6 subnet-router... by Daryll Swer August 28, 2023 Guest Post: Finding inconsistencies in vendor implementations of IPv6 subnet-router anycast addressing. * JPOPF_FTAddress policy formulation and its methods in Japan by Satoru Tsurumaki September 8, 2023 Guest Post: How the Policy Development Process works at JPOPF. APNIC Home Connect with us * Facebook * Twitter * YouTube * Flickr * Weibo * Slideshare * LinkedIn * RSS (c) 2025 APNIC ABN 42 081 528 010 * Privacy * Contact * Help Centre * NRO News * Service Status * Careers * Feedback