What Is the IETF — and How Does It Shape the Internet?

The Engineers Who Write the Rules That Make the Internet Actually Work — and How You Can Be Part of It

Right now, your browser is using HTTP. Your connection is secured by TLS. Your email travels over SMTP. If you are on a video call, it likely runs over WebRTC. Every one of these protocols — the fundamental building blocks that make the internet work — was defined by a single organization that most people have never heard of.

That organization is the IETF: the Internet Engineering Task Force. It is not a government body, not a corporation, and not a regulatory agency. It is a global community of network engineers, software developers, researchers, and technologists who write the technical standards — called RFCs, or Request for Comments — that define how internet communications work.

Understanding what the IETF is and how it operates is essential context for anyone who wants to understand internet governance at a foundational level. Because while organizations like ICANN govern the domain name system and IANA coordinates resource allocation, it is the IETF that defines the underlying technical language of the internet. Without the IETF’s work, none of the other governance structures could function.

📌  One-Line Definition:  The IETF — Internet Engineering Task Force — is the open, volunteer-driven standards body that defines the technical protocols and specifications that govern how the internet communicates. Its outputs, called RFCs (Requests for Comments), are the blueprints that software developers and network engineers follow to build interoperable internet systems.

Where the IETF Came From: A Brief History

The IETF was born in January 1986 at a meeting of US government-funded networking researchers in San Diego, California. It was not founded by an act of legislation or a corporate decision — it grew organically from the community of engineers who were actually building the early internet, and who realized they needed a place to coordinate on technical standards.

The founding spirit of the IETF was captured in a famous line by David Clark, one of its early participants, at a 1992 meeting: ‘We reject kings, presidents, and voting. We believe in rough consensus and running code.’ This phrase remains the IETF’s unofficial motto, and it captures something genuinely distinctive about how the organization works: decisions are not made by authority or by vote, but by whether a proposed standard has enough support to be implemented and whether those implementations actually work.

From 1986 to today, the IETF has grown from a small group of US government researchers to a global community of thousands of participants from hundreds of countries and organizations. It has published over 9,000 RFCs covering virtually every aspect of internet operation. And while its membership and culture have evolved significantly, its core operating principles — openness, rough consensus, and a bias toward practical engineering rather than political agreement — remain essentially unchanged.

🕰️  IETF and ISOC:  The Internet Society (ISOC) provides the legal and financial home for the IETF. ISOC was created in 1992 partly to give the IETF an organizational structure — since the IETF has no formal membership, no elected leadership, and no legal standing of its own, ISOC handles the administrative and financial aspects that make it possible for the IETF to function as a global standards body. The IETF’s technical work remains independent of ISOC’s policy and advocacy activities.

How the IETF Actually Works: Open, Rough Consensus, Running Code

The IETF’s working method is distinctive in the world of standards bodies, and understanding it is the key to understanding both its strengths and its limitations.

No Membership, No Fees — Just Show Up

The IETF has no formal membership. There are no membership fees, no application process, and no eligibility requirements. If you want to participate in IETF work, you subscribe to a working group mailing list, contribute to the discussion, and show up — in person at one of the three annual IETF meetings or remotely through the IETF’s online tools. Your contributions are judged by their technical merit, not by who you work for or what credentials you hold.

This radical openness is by design. The IETF’s founders believed that the best internet standards would emerge from the widest possible pool of technical expertise, not from a closed committee of accredited representatives. In practice, the majority of active IETF participants are employed by technology companies, equipment vendors, internet service providers, and research institutions — because those are the organizations most invested in the standards that govern their products and networks. But formal representation of any organization is not required.

Working Groups: Where the Standards Get Made

The IETF’s actual technical work happens in Working Groups — focused teams organized around specific protocol areas or technical problems. There are currently around 130 active IETF Working Groups covering areas including routing, security, applications, transport protocols, DNS, HTTP, email, and many more. Each Working Group operates on a mailing list and meets at IETF meetings to discuss and advance its work.

Working Groups are organized under eight broad technical areas: Applications and Real-Time, General, Internet, Operations and Management, Routing, Security, Transport, and Web and Internet Transport. Each area is overseen by Area Directors, who are members of the IESG — the Internet Engineering Steering Group — which is responsible for the overall direction of IETF’s technical work and for approving RFCs for publication.

RFCs: The IETF’s Published Standards

IETF Working Groups produce their outputs as RFCs — Requests for Comments. The name is historical: in the early days of the internet, proposals were circulated as informal ‘requests for comment’ from the engineering community. The format stuck, even though modern RFCs are anything but informal — they are the authoritative technical specifications for how internet protocols work.

Not all RFCs are equal. Some are Proposed Standards, some are Internet Standards, some are Informational documents, and some are Best Current Practice documents. The most significant are those that reach Internet Standard status, having been widely implemented and proven to work reliably in practice. Key examples include RFC 793 (TCP), RFC 791 (IP), RFC 2616 and its successors (HTTP), RFC 5321 (SMTP), RFC 8446 (TLS 1.3), and RFC 8200 (IPv6). These documents are freely available at rfc-editor.org and datatracker.ietf.org.

Rough Consensus: No Votes, No Veto

The IETF does not vote. Decisions — about whether a proposed standard is ready for publication, whether a design choice is technically sound, whether a working group has reached agreement — are made by ‘rough consensus,’ a deliberately fuzzy concept that requires the sense of the room rather than a formal tally.

In practice, rough consensus means that a clear majority of informed, engaged participants support a direction, and that objections have been heard and either addressed or acknowledged as minority views that do not block the overall direction. A single determined objector cannot veto a decision — but a technically compelling objection, well-articulated, can genuinely change the outcome. This balance between openness and efficiency is one of the IETF’s most important cultural achievements, and it is why standards like TLS 1.3 — which significantly changed how HTTPS encryption works — could be agreed upon over objections from a minority of participants who preferred a different approach.

How the IETF Has Shaped the Internet: Key Standards and Their Impact

The breadth of IETF’s contribution to the internet is difficult to overstate. Here are some of the most consequential standards the IETF has produced, and what they mean in practice:

TCP/IP — The Foundation of Everything The Transmission Control Protocol (TCP, RFC 793) and the Internet Protocol (IP, RFC 791) are the foundational protocols of the internet — the agreed-upon rules for how data is broken into packets, addressed, routed across networks, and reassembled at the destination. Every device on the internet uses TCP/IP. Without these IETF standards, the internet as a globally interconnected network could not exist. The internet is not a single physical network — it is a shared agreement about how different networks communicate with each other, and that agreement is defined by the IETF.

TLS — Making the Web Secure Transport Layer Security (TLS, most recently RFC 8446 for TLS 1.3) is the encryption protocol that makes HTTPS work. Every time you see the padlock icon in your browser, you are using a protocol defined by the IETF. TLS protects your banking transactions, your email, your logins, and virtually every other sensitive internet communication. The development of TLS 1.3 — which removed outdated cryptographic options and significantly improved both security and performance — is one of the IETF’s most celebrated recent achievements, reached through a process that involved years of debate and compromise among cryptographers, software developers, and network operators.

HTTP and the Web Hypertext Transfer Protocol (HTTP) is the protocol that powers the World Wide Web — the request-response language that browsers and web servers use to exchange web pages, APIs, and data. HTTP was originally defined outside the IETF but was quickly standardized there. The IETF has since defined HTTP/2 (RFC 7540) and HTTP/3 (RFC 9114), which dramatically improved web performance. HTTP/3, which runs on a protocol called QUIC rather than TCP, is one of the most significant architectural changes to web transport in decades and is now widely deployed by major internet services.

DNS Extensions and DNSSEC While ICANN coordinates the policy and governance of the Domain Name System, the IETF defines how DNS technically works. The core DNS protocols (RFC 1034, 1035) were IETF standards. DNSSEC — the security extension that allows DNS responses to be cryptographically verified — was defined by the IETF (RFC 4033-4035 and successors). DNS-over-HTTPS (DoH, RFC 8484) and DNS-over-TLS (DoT, RFC 7858), which encrypt DNS queries to protect user privacy, are recent IETF standards that are reshaping how browsers and operating systems handle name resolution. The governance implications of these privacy-preserving DNS standards have been actively debated at the IETF, at ICANN, and at the IGF.

IPv6 — The Next Generation of Internet Addressing IPv6, defined in RFC 8200 (updating the original RFC 2460), is the IETF’s response to the exhaustion of IPv4 addresses. IPv6 expands the internet’s address space from approximately 4.3 billion addresses to 340 undecillion — effectively unlimited. The IETF has also defined the transition mechanisms that allow IPv4 and IPv6 to coexist (dual-stack, NAT64, 464XLAT), and continues to develop operational guidance for IPv6 deployment through its working groups. The governance of the IPv4-to-IPv6 transition — including who bears the cost and who benefits — is one of the most consequential ongoing questions at the intersection of IETF technical work and internet governance.

The IETF’s Place in the Internet Governance Ecosystem

The IETF does not govern the internet by itself. It is one of several overlapping institutions — alongside ICANN, IANA, the RIRs, the IGF, and national governments — that together constitute the internet’s governance ecosystem. Understanding how the IETF relates to these other bodies is essential to understanding the governance of the internet as a whole.

The IETF and ICANN have a close, symbiotic relationship. ICANN coordinates the policy for the domain name system; the IETF defines how the DNS technically works. ICANN requires registries to support DNSSEC; the IETF defines what DNSSEC is. When new DNS technologies like DoH and DoT were defined by the IETF, they raised policy questions — about user privacy, about ISP visibility into DNS traffic, about the role of browsers as DNS resolvers — that were then debated at ICANN, the IGF, and national regulatory bodies. Technical standards and governance policy are deeply interdependent.

The IETF and IANA are connected through the protocol parameters registry function. When the IETF defines a new protocol that requires unique identifiers, it requests IANA to create and maintain the relevant registry. The IANA port number registry, the IANA protocol number registry, and thousands of other registries are the operational implementation of IETF standards. IANA does not make substantive decisions about what goes in these registries — it implements the IETF’s standards faithfully — but maintaining accurate registries is essential to making IETF standards interoperable in practice.

At the IGF and in national policy forums, IETF standards frequently become the subject of governance debate. When the IETF standardized end-to-end encryption in protocols like TLS 1.3, governments raised concerns about lawful interception. When IETF working groups developed standards for encrypted DNS, ISPs and network operators raised concerns about network management. When the IETF advanced QUIC and HTTP/3, questions arose about whether these new protocols made network monitoring and content filtering harder. These debates — which sit at the boundary between technical standards and public policy — are increasingly common as the internet’s protocols become more sophisticated and their governance implications more visible.

The IETF at a Glance: Key Facts

Fact	Detail
Founded	January 1986 — San Diego, California
Organizational home	Internet Society (ISOC) provides legal and financial structure
Membership model	No formal membership, no fees — open to all; participation by contribution
Annual meetings	3 per year — rotating globally; remote participation always available free
Working Groups	~130 active working groups across 8 technical areas
Total RFCs published	9,000+ since 1969; all freely available at rfc-editor.org
Decision model	‘Rough consensus and running code’ — no formal votes
Governing body	IESG (Internet Engineering Steering Group) — approves RFCs for publication
Key standards body link	IAB (Internet Architecture Board) — provides architectural oversight and liaison
Datatracker	datatracker.ietf.org — track all active and completed IETF work in real time

Frequently Asked Questions

Q1: Is the IETF a government organization?

No. The IETF is a voluntary, open, community-driven standards organization with no government affiliation and no regulatory authority. It has no power to require anyone to adopt its standards — compliance is voluntary. The reason its standards are so widely adopted is not compulsion but practical necessity: when software developers and network operators around the world need to communicate reliably with each other, following the same IETF standards is the most efficient way to achieve interoperability. The IETF’s administrative home is the Internet Society (ISOC), a nonprofit focused on internet development, which handles the legal and financial aspects of IETF operations.

Q2: What is an RFC, and are all RFCs standards?

RFC stands for Request for Comments — a terminology dating back to the early internet when technical proposals were circulated informally. Today, RFCs are formal, published documents that specify internet protocols, best practices, or informational guidelines. Not all RFCs are standards. Some are Informational documents that describe how things work without standardizing them. Some are Experimental documents testing new ideas. Best Current Practice documents capture operational guidance. Only those that go through the full IETF standards track and are widely implemented become Internet Standards. All RFCs are freely available at rfc-editor.org.

Q3: How does the IETF relate to the W3C (World Wide Web Consortium)?

The IETF and W3C are complementary but distinct standards bodies. The IETF focuses on internet protocols — the transport and networking layers that make internet communication possible. The W3C focuses on web standards — HTML, CSS, JavaScript APIs, and other technologies that define how web content is structured and presented in browsers. There is significant overlap at the application layer: HTTP (transport) is an IETF standard, while HTML (content format) is a W3C standard. The two organizations coordinate and cross-reference each other’s work, but they have different scopes, different processes, and different communities.

Q4: Can anyone participate in the IETF, and what does participation look like in practice?

Yes — the IETF is genuinely open to anyone. The most accessible entry point is subscribing to working group mailing lists at ietf.org, where all technical discussions happen in public. Reading the discussions, following the development of specific RFCs, and eventually contributing comments or proposals is a common pathway for new participants. The IETF also holds three in-person meetings per year (with full remote participation available), where working group sessions, plenary presentations, and side meetings take place. The IETF also runs a Hackathon at each meeting where developers can implement and test draft standards in a collaborative setting.

Q5: How does the IETF’s work relate to ICANN and internet governance?

The IETF and ICANN govern different layers of the internet and work in close coordination. The IETF defines the technical protocols that govern how internet communications work — including how the DNS technically functions. ICANN coordinates the policy for the domain name system — who gets which domain names, how registrars operate, and how the DNS root zone is managed. When IETF standards have governance implications (as with encrypted DNS, which affects network operators’ ability to see DNS traffic), those implications flow into policy debates at ICANN, the IGF, and national regulatory bodies. Technical standards and governance policy are deeply interdependent in the internet’s architecture.

Q6: What is the IAB and how does it relate to the IETF?

The IAB — Internet Architecture Board — is a body that provides architectural oversight and long-term direction for IETF work. While the IESG manages the day-to-day flow of IETF standards work, the IAB takes a longer view — advising on architectural decisions that affect the internet as a whole, managing key liaison relationships with other standards bodies (including ISO, ITU-T, W3C, and IEEE), appointing the IANA functions for protocol parameter registries, and publishing Informational RFCs on architectural questions. IAB members are selected from and by the IETF community through a formal nomination and confirmation process.

Q7: How long does it take for an IETF standard to be developed?

IETF standards development typically takes years, not months. A working group might work on a protocol for two to five years before producing a Proposed Standard, and the process from Proposed Standard to Internet Standard can take additional years of implementation and operational experience. TLS 1.3, one of the most successful recent IETF standards, took approximately four years to develop from initial proposal to publication as RFC 8446 in 2018. HTTP/3 (RFC 9114) took several years of active development in the QUIC and HTTPBIS working groups before publication in 2022. This pace reflects the IETF’s commitment to producing standards that are technically sound and practically implementable — rushing the process risks standards that don’t work well in practice.

Q8: How can I get involved in the IETF as someone interested in internet governance?

The most practical starting points are: subscribing to one or two IETF working group mailing lists on topics relevant to your interests (visit datatracker.ietf.org to find active working groups); reading recent RFCs in your area of interest at rfc-editor.org; attending an IETF meeting remotely — registration is required but remote participation is free; and reading the IETF’s own ‘Tao of the IETF’ document (ietf.org/about/participate/tao/), which is the best guide to understanding the IETF’s culture and how to participate effectively. For those interested in the governance dimensions of IETF work, the IGF regularly hosts sessions on the intersection of technical standards and internet policy, and IG Insight at iginsight.org provides accessible context for both.

The Internet’s Rules Are Written by the People Who Show Up and Contribute. The IETF is one of the most open and consequential technical communities in the world. Its standards govern how every email is sent, how every website is secured, how every connected device communicates. And participation is genuinely open — not to accredited representatives or fee-paying members, but to anyone with the technical interest, the time to engage, and the willingness to contribute constructively. Explore more and get started: Learn More at IG Insight Browse all IETF working groups at datatracker.ietf.org — find one that interests you Read the ‘Tao of the IETF’ at ietf.org/about/participate/ — how to participate effectively Read IETF RFCs freely at rfc-editor.org — start with a protocol you use every day Attend a free remote IETF meeting at ietf.org/how/meetings/ — next meeting details inside Read more on IG Insight: What Is IANA? | What Is ICANN? | How Internet Governance Works? Follow IG Insight at iginsight.org for plain-language updates on internet governance   The IETF, like the internet itself, was built by people who showed up and contributed. IG Insight is your entry point.