Summary

  • In collaborative work on Shim6, Stateful NAT64 and rLEDBAT, Marcelo Bagnulo is associated with protocols that keep consequential state at three different places: inside the communicating host, inside a network translator and at the TCP receiver.
  • The placement changes who can notice a condition, who can act on it and what an operator must measure. It is an editorial pattern across separate projects, not a doctrine Bagnulo has publicly declared.

The location of a problem

An application calls a connection continuous when a conversation does not visibly stop. The network does not guarantee that continuity as one indivisible property. A cable can fail while another route remains usable. An IPv6-only client can need to speak to a server that still uses IPv4. A bulk transfer can be asked to make progress without filling a queue that interactive traffic also needs. Each case asks a different system to remember something and respond when the surrounding conditions change.

That remembered information is protocol state. It can be a relationship between two addresses, a record that maps an incoming packet to an earlier flow, or a measurement used to regulate how much data a sender may place in flight. The term sounds technical, but its location has consequences outside a protocol diagram. It determines which machine has evidence about the event, which machine can make the next decision, who must configure or upgrade software and where troubleshooting begins.

A host, a translation service and a receiver do not have the same view of a conversation. The host sees its own interfaces and the addresses it can use. A translator sees packets crossing an address-family boundary and the mappings it has created. A receiver sees the traffic that has arrived at its transport endpoint and can signal how quickly more data should be sent. No one location is inherently best.

Moving information closer to the place where a decision is made can make a mechanism more local and explicit; moving it into a shared intermediary can make otherwise incompatible systems communicate, while creating dependence on that intermediary.

This is a useful way to read several parts of Marcelo Bagnulo’s collaborative record. It does not establish that he personally proposed a single theory of state placement. RFCs and research papers have multiple authors, and the available sources describe documents, roles and tests rather than private motives. The connection made here is an editorial one: following a constraint from the information it requires to the node that keeps that information, then asking what the placement enables and leaves exposed.

Bagnulo is listed by Universidad Carlos III de Madrid as Marcelo Gabriel Bagnulo Braun and as faculty in its Department of Telematics Engineering. The university profile also lists academic and programme responsibilities. In the RFC archive, his name appears with co-authors on work including Shim6, Stateful NAT64 and receiver-driven less-than-best-effort transport. The point is not to turn a bibliography into a personality test. It is to ask what practical questions recur when the network must continue doing useful work under imperfect conditions.

A host tries to keep its identity while its route changes

Shim6 begins with a tension built into IP addressing. An address helps identify an endpoint for higher layers, while also telling the network where to forward packets. Those jobs fit together most of the time, but a multihomed site may have several provider-assigned prefixes and more than one way to reach the Internet. If the path using one locator stops working, changing the address visible to a transport connection can itself break that connection.

RFC 5533, published in 2009 by Erik Nordmark and Marcelo Bagnulo, specifies a layer-three shim intended to give IPv6 hosts locator agility beneath transport protocols. The hosts establish a context with a peer and can later try another locator pair if the original pair fails. Its stated goal includes preserving certain existing communications through failures affecting some of a site’s connections, without requiring the site to announce a provider-independent prefix to the global routing table. This shifts an important part of the continuity mechanism to the endpoints, rather than making it a site-wide router function.

The difference between an identifier and a locator is central to the design. In the mechanism described in the RFC, an address selected for the upper-layer identifier remains available to the transport and application even as the shim can choose different locators underneath. The connection can therefore keep the identifier with which it began while packets use a currently working route. A network operator may think in terms of links and provider paths; the application continues to see the same upper-layer handle. The shim stores the relationship that lets those two descriptions coexist.

That context is not magic failover. Both hosts need protocol support and enough shared state to interpret the changed locators. A failure must be detected, a replacement locator pair must be tested, and packets must be mapped consistently at either end. The RFC places parts of reachability discovery in a companion protocol rather than pretending every decision fits in one document. That division matters operationally: seeing an alternate prefix in an interface table is not the same as having proved that the peer can use a corresponding path.

The proposal also puts a boundary around the problem it solves. It addresses certain multihoming failures and slow, managed changes to a set of prefixes; it does not promise to preserve a communication through every form of renumbering or host mobility. If the original locators remain available long enough, a context may be updated. If all usable members of that set disappear together, or DNS changes have not propagated in time, the assumptions fail. The document specifically treats general survival of a renumbering event as a non-goal.

There is also a less visible identity risk. An address may function as a stable upper-layer identifier while it is no longer a usable locator. If a prefix later gets reassigned, a surviving context could make an old identifier ambiguous. The RFC therefore requires a communication to terminate when the relevant upper-layer identifier becomes invalid, rather than extending continuity across a change that could connect the wrong endpoint. Keeping a conversation alive is valuable only while its identity remains sound.

This is where locating state on the host becomes a governance choice about capability. The endpoint can translate a path failure into an alternate route without asking every application to understand the site’s provider graph. But the endpoint must implement the shim, keep context, participate in recovery and respect the point where an identifier ceases to be safe. Administrators gain a mechanism that can use multiple locators; they inherit a dependency on endpoint software, policy, timing and observability. The path is not repaired merely because a protocol has a failover state machine.

The paper design also separates mechanism from the complete operational system. Shim6’s context is one piece. Neighboring work on reachability testing and hash-based addresses addresses other parts of the problem, including detection and security assumptions. Those companion roles should not be collapsed into a claim that one RFC or one author solved host multihoming alone. They show instead that continuity is built from several linked judgments: which peer is being addressed, which locator is reachable, who may advertise alternatives and how quickly the endpoints can agree on a switch.

The cost of endpoint state is easy to miss when the service appears to keep working. If recovery happens below the application, a user may see little more than a brief pause; a monitoring system looking only at session success may record no outage. Meanwhile, a path has changed, a probe has timed out, or a host has selected a secondary interface. The mechanism therefore makes a new class of operational evidence important: endpoint context state, locator-pair transitions, recovery delays and whether the peer saw the same transition. Routers alone may not explain an event whose decisive choice occurred in two hosts.

The value of this design is not that every network should move resilience into endpoints. Its narrower contribution is an explicit place to hold the correspondence between a stable communication identity and a route that can change. That can reduce the need to expose site-level reachability decisions to transport software or the global routing system. It also raises the minimum capability required at each communicating endpoint. A deployment that has one capable host and one unaware peer cannot be inferred from the RFC’s design goals; support and path behavior have to be established for the actual pair.

A translator remembers across incompatible address families

Stateful NAT64 starts from a different constraint. An IPv6-only client may need to contact an IPv4 server whose address and software cannot be changed for that transaction. The translation system must produce packets the server understands and reconstruct the right reverse mapping when the server replies. DNS64 can supply a synthesized address that leads the client toward the translator, but translation itself still needs to preserve the relationship between the two sides of a flow.

RFC 6146, co-authored by Marcelo Bagnulo, Philip Matthews and Iljitsch van Beijnum, defines that stateful translation behavior. It supports communication from IPv6 clients to IPv4 servers using UDP, TCP or ICMP, with public IPv4 addresses shared among clients. The translator must remember enough about a session to send the return packet to the right IPv6 endpoint and to continue applying consistent translation to later packets. Here, state has left the host-to-host relationship and sits in a network service through which those packets pass.

That placement makes interoperability possible without requiring an old server to become IPv6-capable first. It also means the translator becomes part of the communication’s working memory. The same endpoints can appear unable to communicate if the mapping has expired, the service is unreachable, or the translator’s state no longer matches the packets. A design choice that hides address-family complexity from clients can concentrate continuity risk in an intermediary that must be available and correctly synchronized.

The operational question for this profile is not how to construct a per-flow financial ledger, assign blame to a subscriber or turn a mapping into a filtering policy. Those questions are treated in other BTW coverage. Here, NAT64 is a brief contrast: the translator is the node that knows the cross-family tuple and holds the return path. Its state placement lets systems on either side retain their existing address family, but it makes diagnosis dependent on visibility at the translator as well as at the client and server.

That visibility boundary affects incident response. A client report may say the IPv4 service is down. The server may record an unfamiliar translated source. A path trace can show the translator and still not reveal which binding governed a particular packet. The same failure can therefore be described differently by each team. Operators need to preserve the evidence that joins those views, while limiting sensitive records to the purpose and retention period they actually require. This is an inference about operating a stateful intermediary, not a claim that RFC 6146 prescribes a particular logging policy.

NAT64 and Shim6 both use state to keep communication useful as conditions differ from what an endpoint alone can see. But their stakes are not interchangeable. Shim6 asks two hosts to coordinate alternate locators for a communication whose address family remains IPv6. NAT64 changes packet headers between address families at a shared service. Treating them as one generic story about “resilience” would erase the operational responsibility each placement creates.

The receiver takes a turn in congestion control

Receiver-driven LEDBAT moves the question again. Congestion control normally gives a sender feedback that helps regulate the rate at which it puts data into the network. A background transfer may seek to use capacity left over after more delay-sensitive traffic has had a chance to proceed. rLEDBAT examines whether a receiver can influence this behavior through the TCP mechanisms already available to it, without requiring a sender-specific rLEDBAT implementation.

RFC 9840, published in September 2025 by the IRTF’s Internet Congestion Control Research Group as an Experimental RFC, describes rLEDBAT as a receiver-driven, less-than-best-effort transport mechanism for TCP. It is not an IETF Standards Track specification. At a high level, the receiver controls the advertised TCP receive window and uses arrival timing information, including TCP timestamps, to reason about queue delay. By adjusting the space it advertises, the receiver can constrain how much additional data a standard TCP sender may have outstanding.

The receiver is not directly choosing the network path or rewriting the sender’s congestion algorithm. It is using an existing back-pressure surface. That distinction matters: an endpoint already controls whether it can accept more data, and TCP already communicates that limit. A receiver can make its advertised allowance reflect the goal of moving background bytes with less extra delay. The implementation must still coordinate its feedback with the sender’s ordinary congestion control, loss recovery and the receiver window rules.

Putting the decision at the receiver can be useful when the sender is outside an operator’s control. A content provider, software distributor or peer may connect to a recipient whose device or network wants a transfer to be less intrusive. If the receiving implementation can signal its own pace through standard TCP behavior, the remote sending application may need less special treatment. The receiver is the side that experiences the consequences at the endpoint and has a local incentive to avoid filling queues.

This is a plausible deployment advantage derived from the mechanism; it is not evidence that every sender or path will respond identically.

The measurement problem is subtle. Delay is not observed in a clean laboratory clock: packet arrival time, sender timestamps, clock skew, retransmissions and loss can complicate the calculation. A queue may be on a shared link the receiver cannot see. The same observed round-trip changes can have several causes. rLEDBAT must avoid treating every rise as a signal to close the receive window indefinitely or every low measurement as permission to send without limit. The experimental document discusses limits such as clock differences, queuing behavior, retransmission effects and receive-window adjustment.

A window is both a control and an obligation. Shrinking it too abruptly can interact poorly with data already in flight; growing it too freely can defeat the intended low-priority behavior. Receiver-side control does not eliminate the sender’s own congestion algorithm, and it does not grant the receiver perfect visibility into every bottleneck. The design provides an actuator at the endpoint: the receiver can shape the maximum outstanding data the sender may send. It still needs measurements and an update rule that work across the transport’s timing and loss behavior.

The distinction between evidence classes matters. A 2023 paper in Computer Networks, co-authored by Bagnulo, describes implementation and experimental evaluation of a receiver-driven less-than-best-effort transport. In the experiments reported there, its mechanisms performed similarly to sender-based LEDBAT++ under the tested setup. That finding supports a narrower statement than “rLEDBAT performs equally well in production.” Experimental performance depends on the chosen topology, workloads, competing traffic, software and metrics. The paper’s result belongs to the experiment it reports.

RFC 9840 itself reports implementation and deployment status at publication time, naming Windows 11, Windows Server 2022, Apple systems, Linux and ns-3, along with uses in Microsoft download and update services. Those are claims recorded by the RFC’s authors about the state of the experiment; this article has not independently audited each named product or service. They are evidence that the document reports implementations and deployments, not a current inventory of behavior in every release, region or network.

The receiver’s location of state reverses the familiar diagnostic question. Instead of beginning only with a sender’s congestion window or a provider’s traffic shaper, an operator may need to examine what the receiving device advertised and what delay observations it used to arrive there. If a background transfer slows down, the sender may be following a window value selected elsewhere. A support team that sees only the sending application could miss the actual control signal. Conversely, a receiver may choose an appropriately small window but still not achieve fairness where another flow or device behaves differently.

rLEDBAT therefore places a form of traffic policy into the receiving endpoint, but it does not settle who should define the policy. A device vendor, enterprise administrator, operating-system team or user-facing application could have different goals. A receiver may favor responsiveness even when it shares an access link with another transfer that is itself important. A provider might want network-wide fairness, while a device wants a local workload to finish before a laptop sleeps. The protocol offers a way to express a limit; it cannot reconcile all organizational priorities by itself.

Three locations, three sets of evidence

Comparing the three works is useful only if their different functions remain visible. Shim6 keeps a context at hosts so they can select among locators for an established IPv6 communication. Stateful NAT64 keeps mapping state at a translator so packets can cross IPv6 and IPv4. rLEDBAT places a control decision at the receiver so a TCP sender can be asked to keep less data in flight. All concern a relationship between packets and the meaning or timing of a communication, but only one directly changes address families, and only one uses a receive window as its control surface.

The first question for an operator is: which node knows the condition that should trigger action? Shim6 requires enough host-level information to test an alternate path, while NAT64 requires a translator to know which mapping applies to a reverse packet. rLEDBAT asks the receiver to interpret arrival timing and choose a window update. In each case, the place that reacts must receive observations at the right granularity. Logs collected only at a perimeter may miss a host context change; sender metrics may not reveal a receiver-selected window; endpoint traces alone may not reconstruct a translator binding.

The second question is: who must cooperate for the mechanism to work? Shim6 needs participating hosts and compatible behavior at both ends. NAT64 is valuable in part because it interposes between systems that do not share an address family, so dependence on the translator is stronger. rLEDBAT aims to make the receiver’s behavior useful without a purpose-built rLEDBAT sender, but it still depends on TCP support and the sender’s interaction with advertised windows. Every placement produces a different capability map.

“The protocol is supported” is therefore incomplete unless it identifies which side, middlebox or path component supplies the relevant state.

The third question is: where can the state be lost, corrupted or made stale? A rebooted host can lose an endpoint context; a translator can lose or desynchronize a mapping; a receiver can misread timing or window conditions. Recovery procedures differ, but the service impact can look alike at the application layer: a timeout, slow download or broken session. A successful incident report must connect that symptom to the point at which the protocol made or forgot a decision. That is why reproducing the event at the state-owning node is often more useful than collecting another broad network trace.

There is no universal answer that “the edge” or “the middle” should own state. Locality can reduce the distance between knowledge and action. A host knows its own interface availability, and a receiver knows whether its local application can accept more bytes. A translator, meanwhile, knows a mapping neither endpoint can derive from its own packet alone. Central placement can give an operator a common enforcement point but also make that service a dependency and a source of asymmetric visibility. The design has to match the fact needed for the decision.

State can also change the institution that is accountable. With endpoint state, a platform vendor may control the implementation while an enterprise network carries its effects. With translator state, an operator may control the equipment and its lifetime even though the endpoints own the application conversation. With receiver state, the device or operating-system provider may effectively set a traffic priority that changes the sender’s workload. The packet diagram shows components; the operational system includes the contracts, upgrade channels, measurement rights and incident handoffs between them.

This institutional layer makes the placement question more than a coding detail. If a team cannot see or query the state that governs a connection, it may be unable to explain why the connection persisted, stopped or slowed. If a shared service holds all the mappings, maintenance of that service can interrupt many otherwise healthy endpoint conversations. If an endpoint silently imposes a receive limit, a remote team may mistakenly treat a controlled background transfer as sender failure. The owner of a mechanism and the owner of the resulting customer experience are not always the same party.

Reading the record without inventing a personal doctrine

Bagnulo’s profile is not a chronological biography with a dramatic sequence of individual decisions. The public material supports a more limited account: his university affiliation and responsibilities, and his co-authorship on technical works that address network continuity and transport behavior. A profile that overstates private intent would make this record less reliable. The stronger editorial move is to make the limits explicit and let the documents carry the claims they can support.

RFC 6417, a 2011 Informational Independent Submission authored by Peter Eardley, Lars Eggert, Marcelo Bagnulo and Rolf Winter, describes differences between academic research and Internet standardization. It discusses identifying the problem and the nodes that have to change, incremental deployment, implementation work and operational practices. Its status text is careful: the RFC Editor published it as an Independent Submission, not as Standards Track policy, and it says the RFC Editor makes no statement about implementation or deployment value. It is a perspective paper, not a binding IETF rulebook.

That distinction makes RFC 6417 useful as context rather than as a story about institutional power. The document itself says that many protocols remain on paper, then describes why implementation can find problems and help people evaluate deployment. It cannot certify the later implementation of Shim6, NAT64 or rLEDBAT. Nor does its author list show that any one author controlled the standards process. It offers a set of questions about the transition from research problem to interoperable mechanism; the individual protocol records provide their own evidence.

The later record contains different kinds of evidence. Shim6 has a protocol specification and an explicit scope. NAT64 has a defined translation model. rLEDBAT has a 2023 implementation and experiment paper and a later IRTF Experimental RFC that reports implementations and deployments. Those materials do not form a single adoption score. A standard, an implementation, an experiment, a product release and a large operational deployment answer different questions. One cannot be substituted for another simply because each makes a project sound further along.

The most useful conclusion is not that research became production in one straight line. It is that the evidence gets more specific as a claim gets more operational. A specification can say which state transitions an implementation should support. A test can show how one implementation behaved under a chosen setup. A deployment report can identify systems that an RFC says were in use. A current operator still has to establish which version ran, on which traffic, with what failure rate and rollback procedure. The article’s own sources stop short of that last audit.

That caveat also changes how to write about an individual engineer. Co-authorship is evidence of participation in a document, not proof of sole invention. A faculty title is evidence of an institutional role, not a causal explanation for a design. A project principal investigator listing signals current research responsibility, not the completion of the project’s objectives. The boundaries are not editorial timidity; they separate a traceable fact from an attractive but unsupported story.

The current research horizon

The Universidad Carlos III research portal lists Bagnulo as Principal Researcher on PIONEERS-6G, an EU-funded project whose public schedule runs from May 2026 to April 2029. The stated objective is to develop and validate an energy-efficient, resilient and secure connectivity platform for Internet of Things devices across terrestrial and non-terrestrial networks. That is a project objective. It is not evidence that the platform has already been built, launched or adopted by network operators.

Placed next to the three protocol cases, the project points to a field that is still dealing with continuity across different technical locations. A device may move between terrestrial and satellite access. A service may rely on translation or path changes. A transport receiver may be asked to protect delay-sensitive work. These are reasonable connections to the project’s stated aim, but they remain questions for future evidence, not claims of Bagnulo’s intention or an announced design reuse. A research programme can explore a problem family without carrying forward any one earlier mechanism.

The comparison suggests a practical checklist for reading future results. When a paper or project says “resilient,” ask which failure or transition it tests. When it says “secure,” ask where authentication and authorization state lives and what the threat model excludes. When it says “energy-efficient,” ask which endpoint or network node pays the processing cost and whether efficiency shifts work elsewhere. When a platform spans terrestrial and non-terrestrial networks, ask what signal determines that one path is no longer preferable and who is permitted to switch.

These questions do not prejudge outcomes; they name the observations that would make an outcome meaningful.

The time span also matters. Shim6 dates to a period when IPv6 multihoming and locator/identifier separation were active protocol design questions. Stateful NAT64 addresses the coexistence of address families. rLEDBAT explores a receiver-side mechanism for shared-network behavior. A later IoT platform might confront pieces of all three concerns, but historical continuity of subject matter is not proof of a direct engineering lineage. To claim that, one would need a project source naming a reused protocol, architecture or experiment.

That is a useful restraint in a profile. It lets current research illuminate why the subject’s technical area remains consequential without pretending that a project abstract is a product announcement. For institutions assessing the work, the next useful evidence will be a public architecture, test plan, failure model and independently inspectable performance results. For readers, the distinction between a goal and a verified result is itself a way to judge when a claim has changed from promise into evidence.

What continuity costs

Continuity can look like the absence of an event: the session did not close, the client reached the server, or the background transfer stayed out of a queue’s way. These outcomes are attractive because they make infrastructure disappear. Yet each outcome depends on a subsystem noticing a deviation and deciding what to preserve. A design that succeeds quietly still creates measurable state transitions. Without those transitions, operators may celebrate apparent stability while losing the evidence needed to determine whether the mechanism handled the failure or merely avoided exposing it.

For Shim6, continuity means more than advertising multiple prefixes. Administrators must know that compatible hosts negotiated context, that the intended locator pair was available, that the recovery path was actually tested and that identifier validity remained intact. A site can have redundant physical links while a particular application connection has no usable alternate locator pair. Conversely, a local failover can protect one conversation without proving that all traffic or all services have the same resilience. The unit of assurance is smaller than the site’s marketing claim.

For NAT64, successful translation proves that a particular flow crossed between address families. It does not prove that every application protocol or every session lifetime will traverse the translator without friction. The translator’s mapping state, timeout behavior, capacity and availability are part of the service boundary. Teams should test both directions of the flow and identify how a stale, missing or exhausted mapping appears to client and server. These are general operating questions about a stateful gateway, not new requirements attributed to the RFC.

For rLEDBAT, a transfer that yields capacity to interactive traffic is an outcome to measure over time, not a guarantee bestowed by the label “less-than-best-effort.” The operator needs to know which traffic competes, which delay baseline the receiver uses, how loss and retransmission affect the estimate and whether the receiver’s application remains responsive under a changing access link. A mechanism that reduces delay for one workload might lengthen another workload’s completion time. The objective can be valuable while still involving a trade-off that must be made visible to the organization choosing it.

The shared consequence is that measurements should follow the state. If a path context changes, record the old and new locators and the trigger. If a translator creates or expires a mapping, keep enough evidence to match the packets involved. If a receiver window contracts, track the observation and update that led to the change. The specific logging design must respect privacy, security and retention policy, but a team cannot troubleshoot a control loop it cannot observe. A generic “connection failed” metric is too far from the decision that shaped the result.

A profile about placement rather than credit

A familiar form of technology biography starts with an inventor and works outward from a named breakthrough. That format can distort network engineering, where the object under study is usually collaborative and the mechanism has to meet other standards, implementations, operators and users. The safer unit here is not a heroic invention but a set of documents: what their authors set out to place, what assumptions they record and what evidence later work reports.

This framing still says something about Bagnulo’s relevance. His public record intersects a host-level mobility-adjacent protocol, an address-family translator and receiver-driven transport control, while his university profile identifies ongoing academic roles and research work. Those intersections matter because they expose different practical arrangements for preserving communication. They do not support a claim that Bagnulo alone authored the mechanisms, that he personally directed every implementation named in an RFC, or that all three protocols form one programme.

The distinction also protects the analysis from treating recognition as proof. An RFC number is useful because it gives readers a stable text to inspect. It does not show which network installed the behavior. A research paper can report measurements; it does not establish universal performance. A current project entry can identify a research lead; it does not prove a finished platform. The most informative profile is the one that preserves those boundaries while still explaining how the technical work affects real decisions.

The core pattern, then, is not a chronology of state moving progressively inward or outward. It is a map of the node that must know enough to act. Shim6 lets peers hold a shared locator context. NAT64 requires a translation service to remember a flow across address families. rLEDBAT lets a receiver bound its willingness to accept more data. The system owner, failure mode and observability burden differ in each case.

For operators, the next step is to draw their own state map before selecting a continuity mechanism. Label the decision that must happen, the node that can observe its trigger, the peer or intermediary that must accept the consequence, and the event that makes saved state unsafe. Then identify which logs, telemetry or controlled experiments can confirm those conditions in the production path. The answer may favor host intelligence in one environment, a translator in another and receiver control in a third.

That map is also a way to avoid overpromising. A design can meet its stated protocol goal and still be unsuitable if the required endpoints cannot be upgraded, if a middlebox creates an unmanageable dependency or if the receiver’s signals cannot be diagnosed. A mechanism can be well specified and experimentally promising yet still need operational proof at the exact layer where it acts. Naming that gap is not a verdict against the work; it tells an operator what evidence remains to collect.

The subject is therefore best understood here through a recurring engineering question rather than a single biography-defining answer: when a connection must adapt, who should remember what happened, and who should be allowed to decide what happens next? The documents associated with Marcelo Bagnulo offer three sharply different answers. Their value lies not in pretending those answers are one, but in making their boundaries legible.

Sources