Internet architecture principles revealed by IETF conversation analysis using vCons
The layering principle stands as one of the most fundamental architectural concepts in Internet protocol design, organizing complex network functionality into distinct layers with clear separation of concerns. This principle emerged from the earliest days of computer networking, notably articulated in Vint Cerf and Bob Kahn’s seminal 1974 paper “A Protocol for Packet Network Intercommunication”, and was later codified in foundational RFCs including RFC 1122 and RFC 3439.
At its essence, the layering principle dictates that network protocols should be organized in a hierarchical stack where each layer provides services to the layer above while using services from the layer below, with minimal knowledge of the internal workings of other layers. This architectural approach enables modularity, interoperability, and independent evolution of different network functions—from physical transmission at the bottom to application services at the top.
The principle’s significance extends far beyond theoretical elegance. Throughout IETF meetings 110-123 (March 2021 to July 2025), this principle has been discussed across 456 working group sessions spanning 126 different working groups, demonstrating its continued relevance as the Internet evolves to support new technologies like 5G integration, edge computing, and advanced traffic engineering. The principle remains a touchstone for protocol designers grappling with the tension between architectural purity and practical implementation needs.
The Core Idea — Network protocols should be organized like a well-designed corporate hierarchy: each level handles its own responsibilities without micromanaging the levels below or second-guessing the levels above.
Consider how a successful restaurant operates. The kitchen doesn’t need to know whether a customer paid with cash or credit card—that’s the payment layer’s job. The payment system doesn’t need to understand how the kitchen coordinates between prep cooks and line cooks—that’s the kitchen’s internal organization. The wait staff provides a clean interface between customer needs and kitchen capabilities without either side needing to understand the other’s detailed processes. Each layer has a clear job: take orders and serve food (service layer), prepare meals (application layer), coordinate cooking tasks (session layer), manage ingredient flow (transport layer). When the restaurant runs smoothly, each layer can evolve independently—the kitchen can reorganize workflow, payment systems can add new methods, service protocols can adapt to different customer types—without disrupting the whole operation.
Why It Matters — The practical consequences of violating layering become obvious when you see systems that break this principle. Imagine if your restaurant’s point-of-sale system had to be reprogrammed every time the kitchen changed its prep schedule, or if the line cooks had to understand credit card processing protocols to prepare meals. You’d have a brittle, unmaintainable nightmare.
In networking, this plays out dramatically. Without proper layering, adding IPv6 support would require rewriting every application. Switching from Ethernet to WiFi would break web browsers. Every new transport protocol would demand changes to video conferencing software. The Internet’s explosive growth happened precisely because applications like email and the web could run over any underlying network technology, and new network innovations could emerge without breaking existing applications.
The Tension — The real-world pressure against layering is performance and control. Engineers constantly face situations where violating layer boundaries could solve an immediate problem more efficiently. Why not let the application peek directly at network conditions to optimize its behavior? Why not let the network examine application data to provide better service? These shortcuts often work in the short term and can provide compelling performance benefits, but they create hidden dependencies that make systems fragile and limit future innovation.
How to Recognize It — You’re seeing this principle at work when:
The layering principle was baked into the Internet’s DNA from its earliest architectural decisions, but it wasn’t always uncontroversial. RFC 1122, the “Requirements for Internet Hosts,” established the canonical four-layer Internet model (Application, Transport, Internet, Link) that deliberately simplified the seven-layer OSI reference model. This wasn’t just academic preference—the IETF community had observed that overly rigid layering could be as problematic as no layering at all.
Early protocol development revealed both the power and the pitfalls of strict layering. The success of TCP/IP over competing protocol stacks like OSI demonstrated that pragmatic layering—with well-defined but not overly restrictive interfaces—enabled faster innovation and simpler implementation. However, some early decisions created lasting tensions. The placement of certain functions, like error detection and flow control, at multiple layers sparked debates that continue today. Similarly, the decision to keep the network layer (IP) deliberately simple and stateless, while pushing complexity to the transport layer, exemplified the principle but sometimes created performance challenges.
RFC 3439 later codified these lessons into explicit architectural guidelines, acknowledging that while layering remains fundamental, the Internet’s success came from applying it pragmatically rather than dogmatically. The RFC warns against both “layer violations” that create harmful dependencies and overly rigid layer boundaries that prevent necessary optimizations. This nuanced view reflects decades of experience with protocols that succeeded (like HTTP running over TCP) and those that struggled partly due to layering issues.
The layering principle permeates IETF discussions in subtle but significant ways, often appearing when working groups grapple with where functionality should be placed in the protocol stack. In the early period of this analysis, babel working group participants wrestled with routing protocol design challenges that highlighted layer boundaries:
“you can announce a default route at two points in a barbell network and the two routers that announce the default route don’t need to have synchronized sequence numbers now if you’re working at player 2 you no longer have this problem because a different mac address you announce at only one pla”
This discussion from IETF 110 illustrates how layer 2 and layer 3 boundaries affect routing protocol design—moving functionality to a different layer can solve synchronization problems by leveraging different addressing mechanisms.
The bess working group has consistently dealt with layering challenges, particularly around VPN technologies that must carefully manage the boundary between layer 2 and layer 3 services:
“one comment first question is about symmetric and asthmatic irb support for the p support symmetric irb what it will be the it’s a folding behavior when it does the intersecting routing is going to do layer 2 eventually do layer 2 forwarding to p1 that that is correct when we would do layer 2 forward”
This early discussion shows how VPN implementations must carefully coordinate between routing (layer 3) and switching (layer 2) functions while maintaining clear separation of concerns.
As discussions evolved into the middle period, the ccamp working group addressed layering challenges at the optical networking level:
“question for no I go yes please okay uh for uh RFC 1993 B uh we also made a good job and we close practically all the issue apart one um the one that uh is remaining is a topic related to layer zero layer one boundary the real the things is that the transpond that is essential part of our work i”
This 2024 discussion reveals how layering principles extend even to the physical layer (layer 0/1 boundary), where optical networking equipment must maintain clear interfaces between different types of functionality.
More recently, the detnet working group has explored how deterministic networking requirements interact with layering principles:
“was there was some backend Network which could be the internet or could be uh an Enterprise Network in an ESS or could be a 5G core U and the idea was we are not measuring the network on the right at Layer Two we are measuring basically the r the radio Access Network and then we are measuring end to”
This discussion from July 2024 shows how modern applications like 5G integration require careful consideration of which layer should handle measurement and control functions, particularly when dealing with radio access networks that span multiple traditional layer boundaries.
Analysis of discussions across IETF 110-123 reveals interesting patterns in how the layering principle is applied to evolving Internet challenges:
| Meeting | Sessions | Notable Focus |
|---|---|---|
| IETF 110-112 | 87 | VPN and routing protocol layering |
| IETF 113-116 | 148 | Optical networking and transport layers |
| IETF 117-120 | 129 | 5G integration and edge computing layers |
| IETF 121-123 | 92 | Application-network coordination |
The bess working group leads discussions with 14 sessions, reflecting ongoing challenges in VPN technologies that inherently bridge multiple layers. The ccamp (13 sessions) and teas (12 sessions) working groups’ prominence reflects the growing importance of traffic engineering and optical networking, where layering decisions have significant performance implications.
Notably, discussion frequency peaked during the transition back to in-person meetings (IETF 113-116), suggesting that complex layering discussions benefit from face-to-face interaction. The recent uptick at IETF 123 (39 sessions) coincides with increased focus on AI/ML networking applications that challenge traditional layer boundaries.
The diversity of working groups involved (126 total) demonstrates that layering isn’t just a theoretical concern—it’s a practical issue that arises whenever protocols must interoperate across organizational and technological boundaries. Working groups focused on mobility (dmm), IoT (6lo), and emerging applications consistently grapple with where to place new functionality in the existing layer model.
This report was generated from analysis of IETF working group session transcripts using vCon (virtual Conversation) technology, covering meetings 110-123 from March 2021 to July 2025.
This report was generated from vCon analysis of IETF working group session transcripts (meetings 110–123).
Source: vcon-dev/ietf-meeting-vcons |
Analysis: IETF 125 Hackathon — vCon Principles Detection |
Group vCon UUID: 7cdc109d-9157-4b3c-b121-84cb5c5dc590 |
Sessions analyzed: 456 |
Generated: 2026-03-15