Summary

  • Ching-Heng Ku’s 2020 APNIC account described 98% of Taiwan IP address holders as having signed RPKI Route Origin Authorizations, while a new TWNIC validator was entering a test phase with 46 members agreeing to connect. The same account treated broad route filtering as a later step—not as an outcome already achieved.
  • In June 2026, TWNIC reported APNIC Labs figures of 97.60% ROA coverage and 57.83% ROV filtering as of May. These measures have different labels, units and observation methods. They do not show that coverage declined from 2020, nor do they say what share of operators filters routes.
  • Ku’s significance is best understood through the operating sequence and the public record he helped create: registry support, operator-side validation, policy work and measurement. His roles do not make him the sole cause of Taiwan’s results or a proxy for every network in Taiwan.

A percentage that stops before the final decision

On 16 October 2020, Ching-Heng Ku published an APNIC guest post with a headline that appeared to capture an endpoint: “98% of Taiwan’s IP address holders have signed RPKI ROAs.” The post did not, however, describe a finished defence deployed uniformly across every network. It described a programme in stages. TWNIC’s validator had just launched; 46 IP members had agreed to connect and test it as they sought to enable Route Origin Validation (ROV); and comprehensive route filtering was discussed as a subsequent phase. That separation is the central fact in the article, and it still changes how the headline should be read.

The most useful way to understand Ku’s work is therefore not to treat the 98% figure as a final grade. It is to ask what the published authorization accomplishes, who must make the next decision, and what evidence shows that the decision has reached live routing equipment. The route-security chain contains several actors and control points. Address holders issue authorizations for the resources they hold. A relying-party system retrieves and validates those objects. Network operators decide how to use the resulting validation state in their own routing policies.

The public Internet then reflects the choices made by many separate networks, not one centralized switch.

In 2020, Ku was Director of the IP Department at Taiwan Network Information Center (TWNIC). His APNIC article was written from within that operational context. It reported progress on a TWNIC-led programme but also pointed toward the next stage: more participation in validator testing, followed—if participation proved high enough—by encouragement for members to activate automatic filtering. The wording matters. “Agreed to connect” is not “completed a trial”; “testing a validator” is not “rejecting invalid routes in production”; and a plan to encourage filtering is not proof that operators enabled it.

The evidence available in 2026 makes that distinction newly visible. A TWNIC article dated 24 June 2026 says that, according to APNIC Labs data as of May, Taiwan’s ROA coverage was 97.60%, while its ROV filtering rate was 57.83%. TWNIC sets separate 2026 targets: 98% ROA coverage and an ROV filtering rate that remains above 65%. The institution itself frames the next phase as moving from route registration toward live route validation. The figures are institutionally reported snapshots, not a personal performance score for Ku.

The figures also cannot be placed into a neat before-and-after chart with the 2020 headline. Ku’s 2020 wording refers to “IP address holders” that had signed. TWNIC’s 2026 wording is “ROA coverage.” APNIC publications also report valid-prefix ratios separately for IPv4 and IPv6. Each phrase points toward a measurement object that may differ: holders, announced prefixes, address space, or an observed share of users whose paths encounter filtering. A percentage without its denominator can travel farther than its meaning.

The responsible conclusion is not that Taiwan moved from 98% to 97.60%, but that the sources describe high authorization coverage and a distinct remaining gap in measured filtering.

That is a more consequential story than a numerical ranking. A cryptographically signed statement can exist without every network operator acting on it. Conversely, a network may validate routes from externally distributed data even when the relevant resource holder has not published a matching authorization. Between those states lie operational work, configuration choices, incident response, and the practical limits of what a measurement can observe.

What a ROA says—and what it leaves open

Resource Public Key Infrastructure (RPKI) connects Internet number resources with cryptographic certificates. A Route Origin Authorization, or ROA, is a signed statement about which autonomous system is authorized to originate a particular IP prefix, subject to the authorized prefix length. It gives a relying party evidence with which to check whether a route announcement’s origin is consistent with the address holder’s authorization.

That is valuable because interdomain routing is distributed. Networks exchange reachability announcements using the Border Gateway Protocol (BGP); each network applies its own policies and chooses which routes to propagate or use. A route announcement that reaches a network may be mistaken, misconfigured, or malicious. RPKI allows a network to compare the announced origin and prefix length with published authorization data instead of relying only on the announcement itself.

The authorization is not the same thing as the filtering decision. A ROA is created and signed by, or on behalf of, a resource holder. ROV occurs at a network that receives and evaluates routes. Operators can consume validated ROA data and classify routes as valid, invalid, or not found, then choose a local policy for each class. Filtering is one such response: an operator can reject routes classified as invalid. Operators may use additional local policy, may stage policy gradually, or may observe validation state without dropping a route. A resource holder publishing an accurate ROA cannot force another network to apply ROV.

The system therefore has at least three visible stages. First, a holder publishes a ROA that accurately describes authorized origin use. Second, a validator or relying-party system retrieves and checks the signed data. Third, an operator configures routers or routing software to make policy decisions based on validation results, including whether and how to reject invalid announcements. The first stage is mostly a resource-holder control; the last depends on an operator’s equipment, policy, risk tolerance and change process. The stages are related, but no one should be substituted for another in a public metric.

Even successful ROV has a defined scope. It evaluates whether a route’s origin matches a published authorization; it does not authenticate every autonomous system along the path. It does not prove that the route is the shortest or preferred path, that forwarding follows the announced path, or that the destination service is healthy. Nor is it a general detector for route leaks, outages or every form of routing manipulation. Internet standards describe origin validation as a specific check, not a universal guarantee of route safety.

ROA configuration can itself introduce risk. For instance, a ROA can authorize more-specific prefixes up to a maximum length. If that maximum length is set too broadly, it may authorize route announcements the resource holder did not intend to approve. If it is too narrow, a legitimate more-specific announcement may be classified as invalid. The right answer depends on how the address holder actually originates routes and on whether the authorization reflects that operational arrangement. Adoption measured only as “a ROA exists” can miss whether its contents are accurate, current, and aligned with live route announcements.

This is why a sequence matters more than a single numerator. A high count of published authorizations can be a major foundation. It may reduce uncertainty about which network is entitled to originate a prefix. But it cannot tell a reader how many operators retrieve validation data, how often their caches update, which routing sessions use validation state, what proportion of invalid routes is rejected, or what happens when data is unavailable. Those questions sit at different links in the chain.

The 2020 programme as a sequence, not a finish line

Ku’s 2020 account begins with the institutional setup. It says TWNIC had promoted RPKI after signing its certificate authority with APNIC in 2018. The article attributes Taiwan’s reported progress over the following two years to that promotion and to hands-on assistance. It mentions support and training for members configuring deployment. A separate APNIC event report likewise records the validator’s launch at Taiwan RPKI Day and quotes APNIC Director General Paul Wilson describing around 98% of Taiwan’s IPv4 and IPv6 addresses as having signed ROAs.

The separate account corroborates the event context, but its “addresses” phrasing is not interchangeable with Ku’s “address holders.”

On 28 September 2020, TWNIC launched a validator service. Ku says 46 IP members agreed to connect to it to test functionality as they sought to enable ROV. This is a meaningful operational milestone: it moves from publishing authorizations toward using validation information in member networks. But it is still a test, and the report does not identify those 46 as a representative sample of all operators. It does not say all participants completed configuration, rejected invalid routes, or did so continuously after the event.

The distinction is not a semantic quibble. An operator can connect to a validator while leaving a router’s policy unchanged. It can observe classifications before deciding how to act. It can enable ROV on selected peers or routes, test the result in a lab, or plan a gradual rollout. Each option has different consequences. A filter that rejects an invalid route can improve protection against certain origin mistakes, but an inaccurate ROA can also make legitimate reachability disappear from networks that reject it. Operators need to understand both the benefit and the failure mode before turning a classification into a production action.

Ku’s article describes a third phase in which route filtering would be comprehensive. It says TWNIC would monitor progress in the validator phase and encourage members to activate automatic filtering if participation was high. The wording reveals a governance choice: TWNIC can provide infrastructure, information, training and coordination, but member networks retain their own operational decisions. That is not a weakness in the story. It is the actual topology of responsibility in a distributed network.

A centralized actor can reduce the cost of starting. A local validator, resource inventory, configuration checks and training can make technical work more accessible to members. But deployment is not merely a matter of distributing software. Each organization must know which prefixes it originates, who controls its resources, whether its authorizations match current routing, how it will handle invalid states, and what rollback path it will use. The work is part documentation, part maintenance, part institutional coordination.

The evidence does not disclose how the 46 tests ended, which route classes or networks they covered, how many operators later enabled production filtering, or how participation was measured. That absence limits what can be claimed; it does not nullify the reported launch or diminish the work required to organize a test. A profile should preserve both sides: a concrete implementation step occurred, and the public record available here does not fully document its subsequent adoption curve.

Reading the 2026 gap without inventing a trend

TWNIC’s June 2026 article supplies two figures that appear to tell a simple story: coverage of signed route authorizations is close to 98%, while filtering is lower. The organization reports 97.60% ROA coverage and 57.83% ROV filtering using APNIC Labs data as of May. It says the 2026 targets are 98% and above 65%, respectively. The difference draws attention to a real distinction between an authorization existing and an operator applying validation in the forwarding system.

It is tempting to describe the difference between 97.60% and 57.83% as a “forty-point adoption gap.” That phrase may be rhetorically useful, but it can imply comparable denominators where none have been established in the cited TWNIC article. The ROA figure could relate to covered address space or prefixes; the filtering figure could be derived from observing users or traffic exposed to ROV-filtering networks. Without a common unit and an explicit calculation, subtraction produces a clean number but not necessarily a meaningful quantity.

The date boundary matters too. The 2020 result is a claim about the prior two years and about holders signing. The 2026 figure is presented as a snapshot from APNIC Labs in May and described as coverage. Another APNIC article in March 2026 reports that TWNIC had said more than 97% of IPv4 and 98% of IPv6 routing prefixes were considered valid. That is useful context, but it uses separate address families and a different descriptor. It cannot be treated as a calibration of either the 2020 or June 2026 figure unless the underlying measurement definitions and data sets are reconciled.

APNIC Labs’ published explanation demonstrates why this care is necessary. Its explanation of ROA production combines validated ROA objects with BGP observations of announced prefix/origin pairs. It describes classifying observed prefixes as valid, invalid or unknown and separately calculating exposed address spans. It notes that BGP views differ across collectors and that networks which drop invalid routes may influence what is visible. This is not just a matter of choosing which percentage looks favorable; the observation point determines what the metric can see.

An ROV-filtering estimate raises additional questions. Does it represent the share of users whose traffic would encounter filtering for a deliberately invalid announcement? Is it based on experimental probes, visible routing data, or a combination? Does the value describe IPv4 and IPv6 together? Which prefixes, networks and time window are included? Does “filtering” mean the route is rejected at one observed point, or that every path to a user rejects it? The source label should be accompanied by the answer to those questions before it is used as a direct count of participating operators.

The prudent reading of the 2026 figures is narrower and still important: TWNIC, citing APNIC Labs, reports substantial authorization coverage and a lower filtering metric, while setting separate targets to improve each. That indicates the institution recognizes two distinct tasks. The numbers do not establish why the measures differ, whether that difference is caused by operator capacity, network topology, resource-holder behavior, measurement design, or some combination. Nor do they identify any individual as responsible for the entire distance.

TWNIC says roughly 2% of IP address space remains outside ROA protection, primarily involving holders who must apply through APNIC themselves and smaller organizations with limited technical staffing. It lists inventories, checks, alerts, operational consultation, training and a management platform as ways it supports deployment. These are TWNIC’s own characterization and service descriptions. The available article does not independently evaluate how much each intervention changes adoption, and it does not prove that all remaining unprotected space belongs to organizations of one type.

Ku’s public record and the boundary of personal attribution

APNIC 62’s nominee page identifies Ku as Director of TWNIC’s IP Department. In his own statement, he says he is responsible for IP policy research and number-resource services at TWNIC and has taken charge of the Taiwan IPv6 and RPKI deployment and promotion project. The phrasing is useful evidence of how he describes his portfolio. It should be kept distinct from the page’s separate nominator text and from independent measures of deployment.

The 2020 APNIC guest post provides a more specific public work product: Ku explains the Taiwan programme, its reported ROA progress, the validator test, and the planned later filtering phase. He is an author of that account, not the sole author of the programme. The article itself names institution-level support, member participation, APNIC’s certificate framework and other speakers. A credible profile can recognize his documented role while refusing to collapse all of those contributions into one person’s achievement.

His policy work offers a second, distinct example of contribution. APNIC’s record for proposal prop-127 lists Ching-Heng Ku alongside Aftab Siddiqui and Yen-Chieh Wang as authors. The proposal aimed to reduce the maximum allocation size from APNIC’s 103/8 IPv4 pool to a /23 so that the remaining pool could last longer and newcomers could obtain some IPv4 space without trading for it. APNIC records that it reached implementation in April 2019.

The episode shows participation in a community policy process and a concrete institutional result; it does not imply that Ku alone authored the outcome or that the issue is the same as Taiwan’s routing-security project.

At APNIC 62 in September 2026, Ku was re-elected as Policy SIG co-chair. The role sits in a regional policy-development forum, while the TWNIC work concerns resource services and operator support. Both show sustained participation in Internet-number governance. Under the discipline of Heng Lu Note 73, participation remains evidence of participation; it is not a mandate to speak for every network, resource holder, or Internet user.

That distinction does not diminish the subject. It makes his work legible at the right scale. A director can coordinate a programme and help create conditions for adoption. A public article can document intended phases. A coauthored policy proposal can progress through consensus and implementation. An elected chair can facilitate discussion. None of these acts substitutes for observing the policies actually deployed by separate network operators. The outcome is a chain of contributions and decisions, not a personal command system.

There is a practical reason to resist hero narratives in infrastructure. When success is attributed to one person, the corresponding failure may also be personalized, while the real control surface remains distributed across resource holders, registry systems, operator networks, software, and measurement. The narrative can then obscure who is able to fix what. A resource holder can correct a ROA; a network operator can adjust local route policy; TWNIC can provide member support; APNIC Labs can clarify its estimator; a regulator or public institution can set procurement requirements. The appropriate actor depends on the failure mode.

What a useful adoption account would publish next

The next report on Taiwan’s RPKI programme need not abandon concise percentages. It should make each percentage auditable enough to answer a defined question. A reader should be able to identify the exact numerator and denominator, the unit being counted, the date or interval, the source of the data, and the treatment of missing or ambiguous observations. If ROA coverage means announced prefixes that match a valid authorization, state that. If it means covered address space, state how more-specifics and overlapping spans are treated. If ROV filtering is estimated from user traffic or probes, name the measurement method and its limits.

The same report can keep separate dashboards for separate control points. Resource authorization coverage should show IPv4 and IPv6 separately where relevant, valid/invalid/unknown states, stale or missing objects, and the distribution across resource holders or networks where disclosure permits. Operator deployment should describe which networks or traffic vantage points are observed, what constitutes a filtering decision, whether the state is active in production or only measured, and whether it covers all peers or a subset. A public graph should not merge these into one “adoption” meter.

The time dimension deserves equal care. Publish repeated snapshots at consistent intervals, retain prior results, and mark revisions rather than overwriting a series as if definitions never changed. A high-level target such as TWNIC’s 98% ROA coverage and above-65% ROV filtering goal gives institutions a direction, but targets can create incentives to optimize the visible numerator. If the numerator is prefix coverage, organizations may prioritize easy-to-cover resources. If it is a filtering estimate, networks may be counted as deployed without revealing which route classes or address families are protected.

A target should therefore be accompanied by a quality check: are authorizations correct, current, and aligned with announced routes? Is rejection policy safely staged and monitored?

Operators also need operational evidence. A useful implementation report would document how to test a validator connection, how invalid-route handling is staged, what alarm indicates a stale validation cache, who owns escalation, how rollback works, and how a route classified as invalid can be investigated before a high-impact change. The point is not to prescribe one universal policy; local network conditions differ. It is to make the decision process and the consequences visible to those responsible for service continuity.

For the public, an adoption rate should not be asked to answer questions it does not measure. It cannot by itself establish the availability of TWNIC’s validator, the resilience of every operator’s implementation, the privacy practices of networks, the correctness of every ROA, or the protection of all routes. Those properties need their own evidence: uptime histories, service boundaries, security and privacy documentation, incident reports, test results, and clear ownership. A strong programme can publish all of these without implying that any single figure is a complete security verdict.

There is a counterargument worth taking seriously: metrics inevitably compress complexity, and a reader cannot wait for a full technical specification before recognizing progress. The 2020 figure conveyed that an unusually high share had taken an early step; the 2026 pair draws attention to the fact that authorization and filtering do not move in lockstep. These summaries are useful precisely because they are concise. The answer is not to make them unreadable, but to link them to methods, preserve their labels, and prevent the prose around them from quietly broadening their meaning.

The strongest public account of Ku’s work is thus not “Taiwan achieved 98%” or “ROV is only 57.83%.” Both slogans would overstate what is known. It is that a staged programme has made visible two different operational tasks, that Ku has publicly described parts of that programme and held relevant institutional roles, and that later reporting still distinguishes the coverage of authorizations from observed filtering. The difference identifies where evidence and operational work must continue; it does not, by itself, explain why.

Why the gap matters to network operators

For a network engineer, the distinction between a signed authorization and a filtering action is a change-management issue. A ROA can be published with little immediate effect on traffic if no network uses it in a decision. A newly enabled policy can have direct effect on reachability if it rejects a route that customers or upstreams expect to use. The low-risk path often involves checking one’s own resource inventory, confirming origin ASNs and prefix lengths, testing validation state, observing proposed policy outcomes, and establishing a rollback process before widening deployment.

The public record does not specify the exact operational sequence used by TWNIC’s 46 test participants, so it would be wrong to attribute a particular staged rollout to them. But the general control problem follows from the technology: the holder can publish the wrong origin; the validator can be stale or unavailable; the operator can misconfigure policy; and an invalid route can be either an attack or an accidental mismatch. The network must make a decision under uncertainty. Good technical support reduces the cost of getting that decision right; it cannot remove the need for local responsibility.

An invalid classification deserves especially careful handling. A route may be invalid because an unauthorized origin is announcing it, but also because a legitimate more-specific route exceeds the maxLength authorized by the holder, because an origin ASN changed, or because a ROA was not updated after a network change. The classification is a signal that the route does not match published authorization; it does not provide a complete explanation of intent. Operators need a communication path to the resource holder and a way to distinguish a security intervention from an avoidable outage.

For a registry or national Internet information center, this creates a valuable support role. It can make resource records easier to inspect, help members find missing authorizations, provide training, operate a validator, and convene operators. TWNIC lists several of these services in its 2026 account. Such work addresses a coordination and capability problem: a technically correct standard is not self-deploying. Smaller organizations may lack dedicated staff to track resource changes and routing policy.

Yet support should be measured as support—requests handled, configurations reviewed, training delivered—not confused with the network-level result of active filtering.

For APNIC and other measurement providers, transparency has another payoff. A clear method allows TWNIC, operators and independent researchers to test whether apparent progress reflects changes in configuration or changes in the estimator. If the measure is a user-centric filtering probability, shifts in how probes are connected or how invalid announcements are introduced can affect the result. If the measure is visible prefix validity, changes in collector vantage points and route visibility can matter. Keeping the method stable—or publishing a versioned break when it changes—makes time comparisons more credible.

For policymakers and service owners, the operational distinction helps prevent a common category error: funding authorization issuance and assuming that route decisions have changed everywhere. Procurement can support validator infrastructure and training; operational policy must still be implemented at the networks that make forwarding decisions. A national objective can coordinate, but the technical control is distributed. Any public claim about “deployment” should name which layer the metric covers.

A measured milestone, not a universal verdict

Ching-Heng Ku’s record contains a meaningful progression: a 2020 public explanation of high reported ROA signing and a member test of TWNIC’s validator; a later public distinction between authorization coverage and live ROV filtering; coauthored policy work; and continued participation in APNIC’s Policy SIG. Those are different kinds of contribution, and they should remain different in the story.

Taiwan’s reported figures point toward real activity, but they do not authorize a simple longitudinal claim or a universal statement about operator behavior. The 2020 98% holder headline and the 2026 97.60% coverage figure are not a matched pair. The 57.83% filtering rate is a separate metric whose denominator should be explained before anyone equates it with a share of networks. APNIC’s own measurement writing shows that observed prefixes, address space and user-facing filtering can each describe different parts of the route-security problem.

The central lesson is consequently both technical and institutional. Authorization only becomes part of a route decision when operators consume it and apply policy; a reported filtering estimate only becomes useful when readers know what it observes. Ku’s public work helps reveal the programme’s stages, while the evidence cautions against collapsing a network-wide collective outcome into one individual’s achievement. The next measure of progress should be not just a higher percentage, but a clearer account of who is covered, what is filtered, when the result was measured, and how the network can safely correct an error.

Sources