https://blog.apnic.net/2022/11/21/deploying-ipv6-mostly-access-networks/ Skip to content APNIC Home [icon-squar] MyAPNIC Academy Blog REx NetOX DASH Log in Home Blog search [ ] Search Advanced Whois Make a payment Close Search Blog search [ ] * 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 + Internet Directory + NetOX to solve routing issues + 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 + Internet Directory + NetOX to solve routing issues + 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 Deploying IPv6-mostly access networks By Ondrej Caletka on 21 Nov 2022 Category: Tech matters Tags: Guest Post, IPv4, IPv6 Tweet Blog home [apples_and_oranges_FT-555x202] Dual-stack is the most common way of deploying IPv6 in access networks. A recent standard defines IPv6-mostly access networks, providing IPv4 connectivity only for legacy devices while allowing modern devices to run IPv6-only. It is already well supported and allows network operators to gradually phase out IPv4 from the access networks. Many network operators have been trying to migrate most of their network to IPv6-only to address the scarcity of unallocated IPv4 addressing. For end-user access networks, this presents a problem as there are still many legacy devices, apps and/or services that cannot work properly in an IPv6-only environment. Dual-stack networks provide arguably the best user experience, but at the expense of not addressing IPv4 scarcity at all. Mobiles are ready, desktops are not The state of support for IPv6-only differs mostly by device type or, more precisely, by its operating system. In general, there should be no problem providing IPv6-only networks (with NAT64 and DNS64 to support legacy IP) for mobile operating systems iOS and Android. In the case of iOS, Apple forces all the app developers to publish only apps that support operation in an IPv6-only network. For web pages with IPv4 literals or broken dual-stack servers where IPv6 actually does not work, there is Happy Eyeballs version 2 (RFC 8305) support that mitigates possible poor user experience. Finally, for the purpose of tethering to a desktop computer, there is also a Customer-Side Translator (CLAT) engine so that the tethered device gets dual-stack service despite the fact that the mobile network can be IPv6-only. In the case of Android, the CLAT engine is the critical feature mitigating problems with IPv6-only access networks. This allows unmodified legacy apps to work without major issues because, from the app perspective, the device is still connected to a dual-stack network. Both iOS and Android devices are massively operated in IPv6-only mobile networks around the world, so it is pretty safe to expect that there should not be any major issues. Regarding desktop operating systems, the situation is less satisfying. Users of Windows, Linux and macOS are still free to install apps from various sources, including legacy apps that use deprecated IPv4-only APIs. Such apps will not work unless IPv4 is provisioned to the device. At the same time, a CLAT engine that would address these issues is virtually non-existent. For Linux, there is a clatd script, but it is not a standard part of any common distribution. Windows does feature a CLAT engine, but it only gets activated when a WWAN modem is directly connected to the machine. This way a Windows laptop can connect to mobile networks running IPv6-only and still support IPv4-only apps. Due to this limitation of desktop operating systems, deploying IPv6-only access networks would cause issues for a certain number of users. Network operators are therefore forced to run dual-stack networks despite the fact that a significant number of devices do not require IPv4 anymore. Turn off IPv4 with a DHCP option To address this situation, a new DHCP option number 108 called IPv6-only Preferred has been recently standardized in RFC 8925. It allows a device to signal its capability to work properly on an IPv6-only network. This is done by requesting this option during the usual DHCP handshake. If the DHCP server is aware that the particular network supports IPv6-only operation, it will include such an option in the response, which will make the client stop the DHCP handshake before an IPv4 address is assigned. Therefore, despite the network being dual-stack capable, IPv4 addressing is provided only to legacy clients not requesting the IPv6-only Preferred DHCP option. This may help in reducing the size of the IPv4 address pool. I was curious to find out if this new DHCP option is already used on today's devices. For that purpose, I decided to measure the number of devices requesting this option in the RIPE Meeting network during RIPE 84 in Berlin in May 2022. Throughout the week, I captured DHCP messages into a PCAP file. I then created a simple analyser using Scapy that counts how many unique MAC addresses requested the IPv6-only Preferred DHCP option. Here are the results: Unique MACs: 1441 Option 108 enabled: 951 65% Assuming that the number of unique MAC addresses corresponds to the number of devices connected, this means that almost two-thirds of devices claimed to support IPv6-only operation. Considering the fact that RFC 8925 is pretty recent, this is a very positive outcome. It turned out that the DHCP option is requested by not only all recent Android and iOS devices, but also by recent macOS (12.0.1 and newer) devices. Neither of these platforms has a knob that would allow users to change the default behaviour. This would be concerning especially in the case of macOS, where legacy IPv4-only apps can still be run. There is a CLAT in macOS It turned out that engineers from Apple considered this concern and actually included CLAT in recent versions of macOS. It gets activated only if these conditions are fulfilled: * The DHCP server responds with the IPv6-only Preferred option, and * There is a PREF64 (RFC 8781) option containing the NAT64 prefix in the Router Advertisement (RA) The second requirement is pretty interesting, as all the previous mitigations of issues with IPv6-only networks on macOS used NAT64 prefix discovery by means of DNS64 (RFC 7050). But since this type of discovery makes use of unauthenticated DNS, there are some security concerns. The PREF64 option on the other end, despite being also unauthenticated, shares fate with the other configuration parameters and thus can be trusted a bit more. If both requirements are satisfied, the CLAT gets activated, visible in the output of ifconfig command. Its function can be tested by trying to ping an IPv4 address literal. Code showing CLAT active on an IPv6-only network connection.Figure 1 -- CLAT active on an IPv6-only network connection. The new DHCP option is easy, new RA option is harder So, in order to create a proper IPv6-mostly access network, we need to support both the new DHCP option -- telling compatible clients not to use IPv4 -- and the new RA option -- carrying the NAT64 prefix. The former is pretty easy to achieve on most DHCP servers, as RFC 8925 does not require any special processing on the server side. So, any DHCP server that supports custom DHCP options can be configured to offer option 108 to those clients who request it, containing only a 32-bit timer value of how long should the IPv4 stack stay deactivated. Regarding the PREF64 option for RAs, every single router has to be updated to support this new option. Fortunately, the support is slowly appearing in software routers: * There is a prototype implementation in Python * There is a pull request for FRR * Support has been added to radvd * There is a pull request for the odhcpd daemon used in OpenWRT DNS64 is still needed for Safari and iOS Since the PREF64 option of RAs activates the CLAT engine, it is tempting to try running a network without DNS64. All IPv4 traffic would be forced through the CLAT engine in such a setup. It works without issue on Android, as well as with most apps on macOS with one big exception-- Safari. Somehow Safari refuses to use the CLAT engine and without DNS64, it will just not load any IPv4-only resources, neither domain names, nor IPv4 literals. The same situation is true for iOS. With just PREF64 and no DNS64, most apps cannot reach the IPv4 Internet. That means the IPv6-mostly network has to run DNS64 in addition to NAT64, the PREF64 RA option and the IPv6-only Preferred DHCP option. This will have some impact on legacy devices using IPv6-mostly network as a dual-stack network. Since IPv6 is, in general, preferred over IPv4, all IPv6-ready apps will prefer to use NAT64 in place of native IPv4. Native IPv4 will be only used for corner cases like legacy IPv4-only apps or using IPv4 address literals. By measuring the amount of native IPv4 traffic in the network, one can determine whether such cases are still happening or not and perhaps decide to retire IPv4 completely at some point in time. IPv6-mostly looks promising From my tests, it seems that the IPv6-mostly network is fulfilling its purpose of providing the best user experience while utilizing the least amount of IPv4 resources. On the other hand, there is some added complexity on top of traditional dual-stack networks and no direct saving on IPv4 resources, as IPv4 still has to be deployed everywhere in order to support legacy devices. However, in the coming years, the amount of native IPv4 traffic in such networks is expected to decrease to a point where it would make sense to not deploy IPv4 at all. With traditional dual-stack, scarce IPv4 addresses would be assigned even to the majority of devices that don't need them, so DHCP pools are deemed to keep growing without limits. Ondrej Caletka is a technical expert in the Learning and Development team at RIPE NCC. This post is adapted from the original at RIPE Labs. 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. Latest Tweets APNIC * 2 hours ago @apnic #EDEs are #EDNS options that enrich a #DNS response with human-readable text specifying exactly what went wrong. Learn how to configure EDE for Unbound here: https://t.co/d4bxE95q0o @NLnetLabs #DNS #DNSSEC https://t.co/akyam6N3GK View on Twitter 4 7 APNIC * 9 hours ago @apnic How to provide #IPv4 connectivity for legacy devices while allowing modern devices to run #IPv6-only. @Oskar456 walks us through it: https://t.co/B0WtR18ebw @ripencc @ripelabs https://t.co/2m8FJBnEh8 View on Twitter 9 22 APNIC * 15 hours ago @apnic Join APNIC Academy's @lostdave_98 for a retrospective look at #IPv6 deployment in the Asa Pacific region on 25 November 2022: https:// t.co/sFJe0sJdb2 https://t.co/uvX6p4DTlm View on Twitter 0 3 Authors * Adli Wahid * Aftab Siddiqui * Geoff Huston * George Michaelson * Jen Linkova * Job Snijders * Kathleen Moriarty * Paul Wilson * Ulrich Speidel * Vitaly Kamluk * A Khalil Azizi * AbdelRahman Abdou * Abhishek Jain * 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 * Alan Mauldin * Albert Gran Alcoz * Alden Hilton * Alec Muffett * Alex Band * Alex Boten * Alex Turing * Alex Yen * Alexander Azimov * Alexander Kozlov * Alfred Arouna * Ali Abedi * Ali Norouzi * Amaury Van Bemten * Amrita Choudhury * Anand Buddhdev * Anant Shah * Andra Lutu * Andre Gelderblom * Andreas Dewes * Andreas Reuter * Andree Toonk * Andrei Robachevsky * Andrew Campling * Andrew Cormack * Andrew Cushen * Andrew Gray * Andrew Sullivan * Andrew Toimoana * 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 * Arth Paulite * Artyom Gavrichenkov * Asad Ali * Asanka Sayakkara * Ashil Oogarah * Ashwin Kumar * Ashwin Rangan * Audrey Randall * Aurelien Aptel * Austin Hounsel * Austin Ruckstuhl * Avery Pennarun * Ayesha Iftikhar * Ayush Mishra * Azfar Adib * Azhar Khuwaja * Azura Mat Salim * Baojun Liu * Baptiste Jonglez * Barry Greene * Bart Hogeveen * Basileal Imana * Ben Cox * Ben Du * Ben Schwartz * Benjz Gerard Sevilla * Benno Overeinder * Bert Hubert * Bhadrika Magan * Bhumika Sapkota * Bikram Shrestha * Bill Hess * Bill Stearns * Bill Woodcock * Bjorn Teigen * Blake Anderson * Blas Trigueros * Brenda Buwu * Brenden Kuerbis * Brent Carey * Brian Carpenter * Brian Nisbet * Brian Trammell * Bruce Davie * Bruce Spang * Byambajargal Jamsran * Byron Ellacott * Byungjin Jun * Cameron Steel * Carsten Strotmann * Caspar Schutijser * Cecilia Testart * Cengiz Alaettinoglu * CF Chui * Champika Wijayatunga * Che-Hoo Cheng * Cheeyong Tay * Cherie Lagakali * Chia Ling (Jolin) Chan * Chika Yoshimura * Ching-Heng Ku * Chris Amin * Chris Ritzo * Chris Siebenmann * Christian Giese * Christoph Dietzel * Chuan Jiang * Ciprian Popoviciu * Clarence Filsfils * Claudio Jeker * Clemens Mosig * Colin Perkins * Constance Bommelaer * Constanze Dietrich * Craig Miller * Craig Ng * Craig Rowland * Dale Roberts * Dan Fidler * Dan Li * Daniel Dib * Daniel Kopp * Danilo Giordano * Danny Alex Lachos Perez * Danny Pinto * Daryll Swer * 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 * Dmytro Shypovalov * Donatas Abraitis * Doug Madory * Doug Montgomery * Dr Bahaa Al-Musawi * Dr Govind * Drikus Brits * Duane Wessels * Duncan Macintosh * E. Marie Brierley * Ed Horley * Edward Lewis * Edwin Sandys * Eliot Lear * Elizabeth Krumbach Joseph * Elly Tawhai * Elvin Prasad * Emile Aben * 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 * Eunju Pak * Fabian Bustamante * Fakrul Alam * Farha Diba * Fenglu Zhang * Ferenc Fejes * Fernando Gont * Flavia Salutari * Flavio Luciani * Florentin Rochet * Florian Streibelt * Foy Shiver * Francesco Sassi * Franck Martin * Frane Maroevic * Frank Denis * Frank Herberg * Franziska Lichtblau * Fred Christopher * Fred Templin * Fredrik Lindenberg * Ganga R Dhungyel * Gaurab Raj Upadhaya * Gautam Akiwate * Gavin Reid * Geoff Huston * George Kuo * George Michaelson * George Odagi * George Sadowsky * Giacomo Giuliari * Gianmarco Pagani * Giovane Moura * Gonchig Altansukh * Gordon King * Greg Ferro * Gregory Mounier * Guangliang Pan * Guillermo Baltra * GZ Kabir * Ha Dao * Han Zhang * Hannah Durack * Hanno Bock * Harish Chowdhary * Haya Shulman * Helen Hollins * Hideyuki Sasaki * Hinne Hettema * Hiroki Kawabata * Hiroko Kamata * Hiromu Shiozawa * Hisham Ibrahim * Hoang Nguyen Phong * 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 * Jahangir Hossain * Jake Bauer * Jake Flint * Jake Holland * James Ah Wai * James Kettle * James Pavur * James Richards * James Shank * Jamie Gillespie * Jan Harm Kuipers * Jan Ruth * Jan Zorz * Jan-Piet Mens * Jane Yen * Jari Arkko * Jason Livingood * Jason Smith * Jasper den Hertog * Jawad Ahmed * Jay Daley * Jay Ford * Jeff Chan * Jeff Fry * Jeff Man * Jen Linkova * Jenine Beekhuyzen * Jerry Lundstrom * Jessica Shen * Jessica Wei * Jethro Webston * Jia-Rong Low * Jim Forster * Jim Vella * Jimmy Lim * Jing Qiao * 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 Bambenek * John Garrity * John Jack * John Jason Brzozowski * John Kristoff * John Scudder * John Welborn * Jonathan Brewer * Jordan Carter * Jordan Jueckstock * 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 * Kaajal Kumar * Kaan Onarlioglu * Kanagaraj Krishna * Karel Hynek * Karl Lovink * Karla Skarda * Kasek Galgal * Kashyap Thimmaraju * Kathleen Moriarty * Katsuyasu Toyama * Kazunori Fujiwara * Ke Ma * Keisuke Kamata * Kemal Sanjta * Kenjiro Cho * Kenny Huang * Kenrick Lin * Kensuke Fukuda * Kevin Bock * Kevin Ku * Kevin Meynell * Kevin Vermeulen * Kevon Swift * Keyu Man * Khee Hong Loke * Khwaja Zubair Sediqi * Kiruthika Devaraj * Klee Aiken * Kobayashi Masayuki * Koen van Hove * Koichi Kunitake * Koki Nakagawa * Konrad Wolsing * Korian Edeline * Kostas Zorbadelos * Kris Shrishak * Kurt Lindqvist * Kyle Drake * Kyle Schomp * Lan Wei * Lari Huttunen * Lars Prehn * Lars-Johan Liman * Leandro Bertholdo * Leandro Navarro * Lee Howard * Leo Vegoda * Leonid Todorov * Leslie Daigle * Lia Hestina * Liang Wang * Liangcheng Yu * Linjian Song * Lisa Corness * Lisandro Ubiedo * Liz Izhikevich * Loba Olopade * Lorenzo Cogotti * Louise Tromp * Luca Sani * Luuk Hendriks * M. Yasir M. Haq * Maarten Botterman * Maciej Korczynski * Madeline Carr * Maemura Akinori * Mai Thu Thuy * Major Hayden * Manaf Gharaibeh * Mannat Kaur * Mansour Ganji * Marc Bruyere * Marcin Nawrocki * Marco Chiesa * Marco Cilloni * Marco Hogewoning * Marcus Brinkmann * Marcus Keane * Maria Namestnikova * Maria Theresa Perez * Mariko Kobayashi * Marilyn Zhang * Mario Loffredo * Mark Andrews * Mark Karpilovskij * Mark Nottingham * Mark Prior * Mark Smith * Markus Dahlmanns * Markus Legner * Markus Sosnowski * Marten Porte * Martin Hannigan * Martin Hoffmann * Martin Langer * Martin Thomson * Martin Winter * Mary Rose Ofianga-Rontal * Masanori Yajima * Masataka Mawatari * Massimo Candela * Mat Ford * Matt Larson * Matt Oh * Matt Palmer * Matt Ringel * Matt Stith * Matthew Thomas * Matthias Wichtlhuber * Mattijs Jonker * Max von Hippel * Maxime Mouchet * Md Abdul Awal * Megan Baker * Melchior Aelmans * Merike Kaeo * Metin Acikalin * Michael Kende * Michael Patterson * Michael Rabinovich * Michael Schapira * Mika Kerttunen * Mike Kosek * Min Sung Jung * Minzhao Lyu * Miwa Fujii * Mohamad Dikshie Fauzie * Mohamed Boucadair * Mohammad Larosh Khan * Molay Ghosh * Moritz Muller * Mubashir Sargana * Muhammad Moinur Rahman * Muhammad Yasir Shamim * Muzamer Mohd Azalan * Nadir Hassan * Nafeez Islam * Nalini Elkins * Narayan G * Narelle Clark * Natale Bianchi * Nate Sales * Nathalie Romo Moreno * Nathalie Trenaman * Neta Rozen Schiff * Nick Buraglio * Nick Hilliard * Nick Janetakis * Nico Schottelius * Nicola Rustignoli * Nicole Wajer * Nihit Tandon * Nikolai Hampton * Nikos Kostopoulos * Nils Wisiol * Nirav Atre * Nooshin Eghbal * Nurul Islam Roman * Nusenu * Nyamkhand Buluukhuu * Oanh Nguyen * Oky Tria Saputra * Olafur Gudmundsson * Olamide Omolola * Oliver Gasser * Oliver Michel * Olivier Tilmans * Omar Alrawi * Ondrej Caletka * Ondrej Sury * Otto Moerbeek * Pablo Hinojosa * Paolo Lucente * Paresh Khatri * Parkpoom Tripatana * Pasan Lamahewa * Patrick McManus * Patrik Faltstrom * Paul Dale * Paul Grubbs * Paul Wilson * Pawel Foremski * Pawel Urbanek * Pedro Marcos * Pengxiong Zhu * Pete Sclafani * Pete Stevens * Peter Blee * Peter Hansteen * 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 * Piotr Kijewski * Platon Kotzias * Pranav Kondala * Praneet Kaur * Pubudu Jayasinghe * 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 * Robbie Mitchell * Robert Kisteleki * Roderick Fanou * Rohana Palliyaguru * Roland Meier * Roland van Rijswijk-Deij * 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 * Salvatore Cuzzilla * Samaneh Tajalizadehkhoob * Samantha Douglas * Samit Jana * Samuel Steffen * Sandra Davey * Sandra Siby * Sangeetha Abdu Jyothi * Sanjaya * Sara Dickinson * Sarah Escandor-Tomas * Sarmad Hussain * Sarvesh Mathi * Sasha Romijn * Satadal Sengupta * Satoru Matsushima * Satoru Tsurumaki * Sayda Kamrun Jahan Ripa * Scott Hollenbeck * Scott Shenker * Sebastian Castro * Sebastian Zander * Seiichi Kawamura * Seluvaia Kauvaka * Seth Schoen * Shah Sahari * Shahee Mirza * Shahzeb Mustafa * Shamim Reza * Shamsullah Shams * Shane Alcock * Shane Kerr * Sharat Chandra Madanapalli * Sheetal Kumar * Sheikh Md Seum * Shermaine Yung * Sherry Shek * Sheryl Hermoso * Shian-Shyong Tseng * Shinoj Pittandavida * Shishio Tsuchiya * Shoko Nakai * Shuai Hao * Shucheng Liu * Shumon Huque * Shusei Tomonaga * 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 * Sue Graves * Suetena Faatuuala Loia * Suksit Sripitchayaphan * Sunny Chendi * Susan Forney * 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 * Terry Sweetser * Teun Vink * Theo Jepsen * Theophilus A. Benson * Thomas Holterbach * Thomas Koch * Thomas Krenc * Thomas Millar * Thomas Patzke * Thomas Scheffler * Thomas Wirtgen * Thymen Wabeke * Tianxiang Dai * Tim Bruijnzeels * Tim Chown * Tim Fiola * Tim Raphael * Timm Bottger * Timothy Winters * Tiong Beng Ng * Tobias Fiebig * Todd Arnold * Tom Barbette * Tom Carpay * Tom Do * Tom Harrison * Tom Hollingsworth * Tom Krizek * Tom Perrine * Tomek Mrugalski * 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 * Ulrich Hauser * Ulrich Speidel * Usama Naseer * Uta Meier-Hahn * Vashkar Bhattacharjee * Vasileios Giotsas * Vasileios Kotronis * Vasilis Chryssos * Veronika McKillop * Vesna Manojlovic * Vicky Risk * Vijay Sivaraman * Vijay Varadharajan * Viktor Dukhovni * Vincent Bernat * Vitaly Kamluk * Vittorio Bertola * Vivek Nigam * W K Shiu * Wanqing Tu * Warren Finch * Warren Kumari * Wassie Goushe * Wayne Thayer * Werachart Muttitanon * Wes Hardaker * Wilaiwan Phanarin * Wilhelm Boeddinghaus * Willem Toorop * William Lu * Willy Sutrisno * Winfried Tilanus * Wita Laksono * Wout de Natris * Wouter de Vries * Xiao Zhang * Xiaohong Deng * Xiaoqi Chen * Xing Li * Xinlei Yang * Yali Liu * Yeo Lee Chin * Yi Cao * Yiming Zhang * Ying Tian * Ying-Chu Chen * Yoshibumi Suematsu * Yoshinori Takesako * Yoshitaka Aharen * Younghwan Choi * Yuedong Zhang * Yunfei Ma * Yurie Ito * Yuta Takata * Zachary Bischof * Zaid Ali Kahn * Zaifeng Zhang * Zain Shamsi * Zen Ng * Zhenyu Li * Zili Meng * Zinan Lin * Zolzaya Shagdar * MoreShow all Tags * APNIC Foundation * APNIC Training * ASNs * Australia * BGP * capacity development * CERTs * China * DNS * DNSSEC * Event Wrap * Guest Post * How to * IANA * ICANN * IETF * IGF * India * Indonesia * Internet Governance * Internet of Things * IPv4 * IPv6 * ISIF Asia * ITU * IXPs * Japan * measurement * networking * NOGs * NRO * Pacific * peering * RIPE NCC * RIRs * ROAs * routing * RPKI * security * South Asia * Taiwan * TCP * Thailand * Three of the best * Whois Related Articles * Fit-for-purpose financing to grow your access network business Fit-for-purpose financing to grow your access network... by John Garrity February 27, 2020 Guest Post: ISPs and other access network businesses face a range of challenges in growth and expansion. But there are plenty of examples to show it is possible through various... * Deploying DNSSEC in a large enterpriseDeploying DNSSEC in a large enterprise by Han Zhang February 26, 2020 Guest Post: At Salesforce, we started our DNSSEC deployment by analysing our zones and finding third-party providers that satisfied our DNSSEC requirements. * Deploying RPKI at ComcastDeploying RPKI at Comcast by Tony Tauber April 8, 2022 Guest Post: Learn the process Comcast went through to deploy RPKI without disrupting performance for its customers. * Lessons from deploying DNSSEC in MongoliaLessons from deploying DNSSEC in Mongolia by Nyamkhand Buluukhuu May 4, 2020 Guest Post: The most essential part of deploying DNSSEC was to understand what it is and how it works. APNIC Home Connect with us * Facebook * Twitter * YouTube * Flickr * Weibo * Slideshare * LinkedIn * RSS (c) 2022 APNICABN 42 081 528 010 * Privacy * Contact * Help Centre * NRO News * Service Status * Careers