Summary

  • Tomohiro Fujisaki co-authored the 2008 problem statement and requirements for IPv6 address selection in multi-prefix environments, where a host’s chosen source address can conflict with routing and filtering elsewhere in the network.
  • His later co-authored RFC 7078 defines a DHCPv6 option for distributing address-selection policy. It gives a site administrator a way to send policy to nodes, while leaving local configuration, implementation behavior and security as operational constraints.
  • APNIC’s record of Fujisaki’s allocation proposals shows a separate boundary: one change to IPv6 aggregation criteria was implemented, while proposals for larger allocations tied to deployment needs did not reach consensus.

A packet can leave with the wrong return address

A connection can fail even when a device has a valid IPv6 address and the network has routes. One reason is a mismatch between the source address the host chooses and the path the surrounding network can carry. RFC 5220 describes how ingress filtering can discard the packet, how a reply can lack a usable route back, or how traffic can take an unexpected asymmetric path. The application shows the failure, while the cause can lie in how the host’s address table and the site network fit together.

This is not a report of a named outage. It is the problem statement that Arifumi Matsumoto, Tomohiro Fujisaki, R. Hiromi and K. Kanayama published as an Informational RFC in July 2008. The distinction matters. The document establishes a class of operational conditions and explains why default address-selection rules can be difficult to use in those conditions. It does not show how often the failures occurred, which provider experienced them, or whether a later mechanism fixed them in production. The evidence is architectural: a configuration choice made locally can determine whether the network accepts a packet globally.

The phrase “address selection” can sound like a small algorithmic detail. For an operator, it can sit at the point where several otherwise valid pieces stop composing. A host can have multiple addresses, a router can have a next hop, and a provider can filter traffic according to source prefixes. Each component may be behaving according to its own rules. If the host chooses an address that does not correspond to the network path, those local rules can combine into a dropped connection. The operator cannot solve that condition by looking only at the application, only at the router, or only at the address plan.

RFC 5220 catalogued several ways that the mismatch could arise. It considered multiple routers connected through a single host interface, ingress filtering, networks that are reachable in one direction but not the other, combined use of unique-local and globally routable addresses, renumbering, multicast sources, temporary addresses, and the relative choice between IPv4 and IPv6 destinations. These cases are related because a host may hold several plausible addresses and the default ordering may not reflect the administrative or routing context that makes one address usable and another a poor choice.

The document also drew a boundary around the problem. Its focus was end-site networks and unmanaged hosts. It treated redundancy through multihoming as generally outside its scope. That decision kept the analysis on hosts whose address behavior is hard to adjust one by one: the user may not understand the site’s routing, the device may be in a location where manual configuration is difficult, or there may be too many devices for an administrator to tune individually. The challenge was not simply to produce a better ranking rule. It was to make the rule manageable where the host is not managed like a router.

That framing made a deployment question visible. The address policy table could be changed by hand, but the problem statement said that hand configuration was not a feasible general answer for large or unmanaged populations. Defaults had to work often enough to be useful, yet no default could be expected to fit every site. A site might have multiple providers, local-only prefixes, a transition mechanism or service-specific constraints. The operational question became how a host could receive context without requiring each user to understand the topology.

Requirements before a delivery mechanism

RFC 5221, published in the same month and with the same four authors, did not claim to solve the problem. It translated the cases in RFC 5220 into requirements that a future address-selection mechanism should meet. It is also Informational rather than a Standards Track protocol. That status tells readers what kind of record they are consulting: a statement of needs, not a promise that every implementation or network already satisfies them.

The requirements show why “let the administrator set a preference” was not enough. A useful mechanism had to change host behavior where defaults failed, provide information before the host made a selection, and allow updates when the network changed. It had to account for node-specific and application-specific behavior, multiple interfaces, central administration, next-hop choice, interoperability with the existing selection algorithm, and security. Timing and usability mattered too.

A policy could be technically expressive yet still fail as an operational solution if it forced ordinary users to maintain a detailed table or imposed noticeable delay each time a connection began.

Those requirements expose an authority boundary that is easy to overlook. The network operator understands routes, access constraints and site policy. The host has the addresses, interfaces and applications that make a selection at the moment a packet is sent. The user or device administrator may have local settings that the network does not control. A mechanism has to carry useful information across those boundaries without assuming that one actor can configure every other actor’s equipment.

The authors also made security part of the requirement rather than adding it as a detached warning after the fact. Address-selection information can change which path a host prefers and which source address it uses. A mechanism that distributes such information therefore has to consider the consequences of manipulation, disclosure and conflicting configuration. The 2008 memo did not prescribe the later DHCPv6 option. It set criteria against which a possible solution could be assessed.

The separation between a problem statement, requirements and a protocol is important to the account of Fujisaki’s work. RFC 5220 names operational cases. RFC 5221 specifies what a mechanism should accomplish. RFC 7078, published in 2014, defines one means of supplying policy. These are collaborative documents, and the sequence does not prove that any one co-author controlled the whole design or that every requirement was met by the selected mechanism. It does let readers follow how a protocol problem became a set of design obligations and then a specific option.

Policy enters the DHCPv6 exchange

RFC 7078, “Distributing Address Selection Policy Using DHCPv6,” was authored by Arifumi Matsumoto, Tomohiro Fujisaki and Tim Chown. Unlike the earlier two memos, it is a Standards Track document. It defines an Address Selection option that a DHCPv6 server can provide so that a site administrator can distribute a policy table and related parameters to nodes. The option can override the default address-selection parameters and table described by RFC 6724.

The mechanism does not replace the host’s selection logic with a remote command. It supplies policy information that the node processes. RFC 7078 calls the option a hint about how the node should behave and says that the administrator of the node can control how received policy is handled. It then recommends a uniform processing method to simplify troubleshooting and reduce operational cost. The text holds two ideas together: a site can express preferences centrally, while the host remains an implementation and configuration boundary.

That boundary is visible in the fields. The option carries a policy table composed of rows. Each row associates a prefix with a label and precedence value used by the address-selection algorithm. The option also defines flags that relate to automatic row additions and privacy preference. Those are not generic “IPv6 on” or “IPv6 off” controls. They are inputs to a specific selection process, with a scope and meaning that an implementation has to preserve.

For an administrator, this changes the work from editing a table on every device to distributing a common policy through a service the devices already use. The benefit is legibility and repeatability: a site can define the policy once and have clients receive it through DHCPv6. The standard still cannot make every client support the option, guarantee that a message reaches every interface, or ensure that the chosen source matches the actual forwarding and filtering configuration. Distribution is a control path, not proof of successful data-plane behavior.

The text also recognizes that the policy table is semantically delicate. Adding or removing a row can change the meaning of the table as a whole. An administrator may need to decide whether an automatic row should be added, whether temporary addresses should be preferred, and how local settings interact with the distributed information. A value that looks like one more configuration field can alter address ordering for many flows. The operational burden shifts: fewer devices may need manual editing, but the person who owns the site-wide policy has to understand how the table, client behavior and network paths interact.

RFC 7078’s own description of absent policy is equally important. A network interface that receives no distributed selection policy does not necessarily indicate that its administrator ignored the issue; the default policy may be intended. In that case the host should use the default address-selection policy. This prevents an empty option from being treated as a universal failure. Absence can be a choice, but it is only interpretable in the context of the deployment and the host’s other configuration.

The option’s scope also matters on multi-interface nodes. Address-selection behavior is node-global in important respects, because the outbound interface may be selected after the destination address. The RFC explains why simply storing different address-selection policies per interface does not solve every case: the address decision can precede or interact with the interface decision. A site must reason about what information applies across the node, not assume that each interface behaves as an isolated policy domain.

The specification does not turn an address-selection table into a route. It does not announce the prefix, install a route, configure an ingress filter, ensure a next hop, or validate the network’s response. An operator who distributes a source-address policy still has to confirm that the routing and filtering state supports the paths implied by that policy. A host can be handed a well-formed table and still fail to communicate if the surrounding network cannot carry the resulting packets.

The security cost of putting policy on the wire

Once a DHCPv6 message can carry address-selection policy, the trustworthiness of that message becomes part of the operational problem. RFC 7078 warns that a rogue DHCPv6 server could send a bogus policy. A client that accepts it might select an address that is filtered by its upstream, incur additional network charges, or send traffic to an attacker. The RFC names trusted channels such as IPsec, Secure Neighbor Discovery and DHCP authentication, and it notes DHCP snooping at Layer 2 as a commonly used mitigation.

This warning complicates a simple story in which centralized distribution is always safer than local configuration. Central distribution can reduce inconsistent manual settings, but it can also make a malicious or misconfigured server a policy source for many clients. The operational question is not merely whether the option exists. It is which server may send it, which clients accept it, how administrators review changes, and whether the network has a way to detect a policy that sends traffic into an unusable or unsafe path.

The threat described in the RFC is specific. It concerns address-selection policy and the possible path or source consequences of a bogus option. It should not be enlarged into a claim that DHCPv6 policy is inherently unsafe, that a real attack occurred, or that the mitigations named in the memo are universally deployed. The source offers a threat model and mitigations; it does not supply measured incident rates or an operational audit of client networks.

There are practical constraints beyond server trust. RFC 7078 observes that a table with many rules can make the DHCPv6 message large and warns administrators to consider the local infrastructure’s ability to carry the resulting message. A theoretical option that can encode thousands of rules is not equivalent to a message every client, server and relay can reliably transport. Fragmentation support cannot be assumed. The administrator must keep policy compact enough for the path and equipment actually in use.

The standard therefore has more than one success condition. The server must distribute the intended policy; the client must understand and process it; local configuration must not create an unexpected conflict; the message must survive the network; and the resulting address choice must fit the path that the packet will take. An observability plan would need to distinguish each stage. A dashboard that reports only that an option was sent cannot establish that a client applied it or that traffic succeeded.

The same deployment question appears at the registry edge

Fujisaki’s public record also includes policy work on IPv6 allocation. The mechanism is different from DHCPv6, but it raises a related deployment question at a different point in the chain. A host-level table affects which address a node chooses from what it has. An allocation policy affects what address space an organization can receive and how it can structure the prefixes available for its network. These are not the same decision and should not be collapsed into one technical claim. They do, however, shape different conditions under which IPv6 can be operated.

APNIC’s proposal archive records a sequence of IPv6 policy proposals involving Fujisaki and co-authors. One early proposal, prop-076, would have required Local Internet Registries to aggregate subsequent IPv6 allocations. Its authors withdrew it after discussion and submitted prop-082, which proposed removing aggregation criteria from initial allocations. The later proposal reached consensus at APNIC 29, passed through the final comment period and Executive Council endorsement, and APNIC records it as implemented on 5 July 2010.

That history is useful because it shows policy design changing after community discussion. Prop-076 and prop-082 were not identical drafts with a different title. The former concerned aggregation for subsequent allocations; the latter removed an aggregation criterion from the initial allocation policy. APNIC’s record says prop-082 incorporated feedback from the earlier discussion. The successful outcome belongs to the policy process and its co-authors, not to Fujisaki alone. The record does not establish the operational effect on every network that later received an allocation.

The next year, Fujisaki submitted prop-087, “IPv6 address allocation for deployment purposes.” Its proposal text argued that organizations using an RFC-described deployment protocol could justify an initial IPv6 allocation larger than /32 during the initial deployment phase. APNIC’s history says the proposal was presented at APNIC 30, did not reach consensus, returned for further discussion and was withdrawn by the author in August 2011. The outcome is as concrete as the text: APNIC did not implement this proposal.

The topic matters because protocol deployment and registry allocation operate at different scales. A network may design a deployment method that uses many subnets or delegates a structured block to customer sites. The registry’s allocation criteria, by contrast, decide how much address space an organization may initially receive and what it must demonstrate to receive more. A policy proposal can argue that existing criteria do not fit a particular technical design. The fact that the design is documented in an RFC does not by itself determine whether the allocation rule should change.

That decision still passes through the RIR’s policy process.

The proposal’s withdrawal does not tell readers why Fujisaki chose to withdraw it. APNIC’s history records the procedural outcome, not the author’s private reasoning. It would be wrong to describe withdrawal as proof that the operational problem was solved or that the proposal was rejected permanently. It says that this version of this proposal was not adopted and was withdrawn after not reaching consensus. A profile of a person who proposes policy should preserve the difference between an identified problem, a proposed remedy and a rule that actually enters force.

Later APNIC records show that the allocation-size issue returned in narrower or different forms. In 2014, prop-111 proposed allowing an organization to request an initial allocation up to /29. APNIC’s page records four proposal versions, no consensus at APNIC 37, further discussion, and no consensus again at APNIC 38, when it was abandoned. In 2015, prop-112 proposed a path for legacy IPv6 holders to extend their address space up to /29 without the usual utilization-rate criteria or additional documentation. APNIC records that it did not reach consensus at APNIC 39 and was abandoned.

Those later outcomes do not establish that the proposals were technically unsound, that the policy process was unfair, or that every participant opposed the idea for the same reason. They establish that the proposals did not meet the consensus conditions recorded by APNIC. Read alongside prop-082, they show a mixed record: one adjustment to initial-allocation criteria was implemented; multiple later requests to change allocation size were not. This is a more informative account than describing all policy work as either victory or failure.

The relation between these allocation proposals and the host-selection RFCs is an editorial interpretation, not an attribution to Fujisaki. At one edge, a network negotiates how much address space its organization may hold and how that space may be allocated. At another edge, a device chooses among available addresses according to defaults and policy. A registry decision cannot tell a host which source to use. A DHCPv6 option cannot create the prefix space an operator does not have. Seeing both edges together helps explain why “IPv6 deployment” is not one decision made by one institution.

A career record made through collaborative documents

The public record supports a bounded account of Fujisaki’s work. APNIC’s 2017 NRO Number Council nomination page describes him as a senior research engineer and supervisor at NTT, says he had conducted IPv6 research at NTT Laboratories since 1997, and lists roles in Japanese IPv6 deployment and address-policy coordination. The page records his chairing of the Japan Open Policy Forum from 2005 to 2012 and a JPNIC Board role in charge of IP policy beginning in 2013. Because the information appears in a nomination, it is best presented as a role history recorded by APNIC rather than as an independent evaluation of his results.

APNIC’s Executive Council minutes place another institutional detail on firmer ground: the Council unanimously appointed Fujisaki to the NRO Number Council for 2011 and acknowledged his service in 2010. That is an official appointment record. It does not establish how he voted on every policy or what authority he held over the separate RIR communities. Membership of a technical or policy body is not a substitute for reading the decisions that body was authorized to make.

The RFCs also resist a single-person story. RFC 5220 and RFC 5221 list four authors. RFC 7078 lists three. APNIC’s proposal pages identify Fujisaki as the author of prop-087 and prop-111/112, while prop-076/082 list him among co-authors. The differences in attribution matter: standards work was collaborative; policy proposals may have named one author; and implementation or community adoption involved other actors. The documents show a participant across several settings, not a person acting alone.

That distinction changes what can reasonably be said about impact. A published RFC provides a stable, reviewable specification. A Standards Track RFC has passed the IETF process for publication as an Internet Standard, but the RFC itself does not measure how many systems implement it. An Informational memo can explain a problem and requirements without creating mandatory behavior. An APNIC proposal may be implemented, withdrawn or abandoned, but the status label does not reveal how much operators used the policy afterward. Each record has its own evidence scope.

The work is most interesting where it refuses a shortcut. The 2008 documents did not claim that a new algorithm alone could harmonize address choice with routing. They enumerated cases and requirements. The 2014 RFC specified a distribution mechanism but preserved local configuration and discussed attack paths. The APNIC proposals made arguments about allocation criteria, then their recorded outcomes diverged. Taken together, the record traces decisions from a host’s policy table to a registry’s allocation rule, with the standards and policy communities deciding different parts of the problem.

There is no need to present this as a triumphant migration from problem to solution. The sources do not show that address-selection failures disappeared. They do not provide deployment counts for RFC 7078, and they do not measure the effects of prop-082 on operators’ networks. The story is more useful when it leaves those absences visible. Readers can see which mechanism was defined, which proposal was adopted and which questions remain outside the evidence.

The boundary between a policy and a working path

For a provider, the distinction between the policy sent and the path that carries a packet is practical. A table can tell a node that one prefix should rank ahead of another. It cannot ensure that the upstream accepts traffic from that prefix. An allocation can provide room for a customer addressing plan. It cannot ensure that a device chooses the address the network can route. A standards document can give implementations a common format. It cannot certify that every client has the feature or that every administrator has deployed it securely.

This is where a running-system view is useful. The evaluation should follow the packet through the actual path: which addresses are configured, which policy the node received, which local rules overrode it, which source address was chosen, which interface and next hop carried it, and whether the upstream accepted it. The same discipline applies to allocation: which prefix was assigned, what local plan was built from it, what routes were originated, and what traffic actually used the path. The RFCs and policy records define parts of this chain; none of them is a complete operational trace.

The measurement boundary should therefore be explicit. RFC authorship is evidence of participation in a specification. The RFC’s status is evidence of publication category. APNIC’s history is evidence of the decisions recorded for each proposal. A public role page is evidence of the roles it records. None of those records is a traffic measurement, implementation census, customer survey or before-and-after performance study. A factual profile should not turn institutional activity into a deployment statistic.

That restraint also helps distinguish technical evidence from authority. A policy table delivered by DHCPv6 may be accepted by a host under the standard’s processing rules, but a host administrator’s local settings remain relevant. A proposal may receive consensus in APNIC’s process and then enter an implementation path, but that result applies to the policy mechanism within that forum. It does not give the room general authority over all networks. Conversely, the existence of local host control does not make registry allocation criteria irrelevant. The mechanisms operate at different layers and bind different actors.

The evidence consequently gives a careful profile of Fujisaki rather than a biography of private life. It follows a researcher and policy participant through documents that record a technical failure class, a set of design requirements, a standardized means of distributing policy and several proposals about the allocation rules that support deployment. The most concrete results are mixed: prop-082 was implemented, prop-087 was withdrawn after failing to reach consensus, and props 111 and 112 were abandoned after similar recorded outcomes.

RFC 7078 gives a standardized distribution option while leaving several operational questions to administrators and implementations.

That mix is the point. The address chosen by a host is not determined solely by the registry that assigned its prefix, and an allocation policy does not control the host’s packet-level decision. Fujisaki’s record touches both sides because IPv6 operation must be supported at both scales. The documents make that connection visible without claiming that either scale can command the other.

What the record does not settle

The RFCs do not tell us how common multi-prefix failures were, how many client operating systems implemented RFC 7078, or how often operators relied on its option. APNIC’s proposal histories do not show why individual participants supported or opposed each change unless the minutes or proposal text state it. The nomination page does not provide independent performance measures for Fujisaki’s roles. These limits do not erase the documented work; they define where the article must stop.

The clearest finding is narrower and stronger than a generalized claim about IPv6 success. Fujisaki was a named co-author on a progression from an address-selection problem statement, through requirements, to a DHCPv6 policy-distribution standard. He also appears in APNIC policy records that show one aggregation change reaching implementation and later allocation-size proposals failing to reach consensus. Each outcome can be read directly from official records. The connection between them is a way to understand deployment constraints, not proof that one policy caused a measured network result.

For operators, that leaves concrete questions rather than a verdict. Do client devices receive the intended policy? Can the administrator distinguish a default from a missing option? Does the table align with current routing and ingress filtering? Is the DHCPv6 service trusted and monitored? Can relays and clients carry the option reliably? At the resource-policy layer, can a provider justify a block that fits its actual addressing plan, and are the criteria clear enough to apply consistently? The standards and allocation histories tell operators where to look; their own network evidence must answer how the system behaves.

Fujisaki’s contribution is therefore best read through the limits as well as the specifications. The host was not a blank endpoint that a registry could program. The registry was not a host-selection engine. Each layer had a different control surface, a different process and a different test of success. The public record shows a participant working across those boundaries, with outcomes that range from standardization to implementation, withdrawal and abandonment.