Skip to main content
  • IETF 126 Highlights

    The IETF 126 meeting was held 18–24 July 2026 at the Hilton Vienna Park in Vienna, Austria, and online, hosted by Cisco. The week included the IETF Hackathon and Code Sprint, the New Participants' Program, five Birds-of-a-Feather (BoF) sessions, and more than 100 working group and research group sessions. The Applied Network Research Workshop also took place during the IETF 126 meeting week.

    1 Sep 2026
  • IETF email infrastructure transition planned for 11 September

    A transition to a new modern, modular, and containerized infrastructure for email services provided for ietf.org, iab.org, irtf.org, rfc-editor.org (including email lists) is scheduled for 11 September 2026 starting at 2200UTC, with message delivery delayed up to 60 minutes. Further updates will be provided closer to the transition.

    28 Aug 2026
  • Post-Quantum Authentication: Up Next

    Post-quantum key establishment has moved from standards into deployment. Post-quantum authentication has not moved nearly as far, and specification work is no longer the only constraint. The IAB is holding a workshop in Prague on 11 and 12 October 2026 to bring deployment experience together with the people working on the relevant protocols and standards.

    27 Aug 2026
  • IETF 126 post-meeting survey: what we heard

    The IETF 126 Vienna meeting was held 18-24 July 2026 and the results of the post-meeting survey are now available.

    27 Aug 2026
  • Meet our new IETF NOC Lead

    Joe Clarke has been appointed as the new IETF NOC Lead and in this post Joe introduces himself and sets out his priorities for the IETF Network.

    10 Aug 2026

Filter by topic and date

Filter by topic and date

A Sustainable Internet: How to get there from here?

5 Mar 2025

After a successful side meeting during the IETF 121 Dublin meeting, the new Sustainability and the Internet (SUSTAIN) Proposed Research Group will have its first meeting during IETF 122 Bangkok. You might be wondering, what is this Research Group about?

flowernet

When thinking about sustainability in the IETF context, energy efficiency often springs to mind. Network sustainability however is much broader than just energy efficiency. It encompasses all manner of resource efficiencies (energy, carbon, water, etc.), not just during the usage phase of network equipment but also over the lifetime of  network elements and the infrastructure into which we place them. 

In the SUSTAIN RG we will be focused, from a networking perspective, on the environmental impact of the Internet, what is often characterized as its “footprint”, while fostering an appreciation for the broad body of work around the Internet’s positive societal effects.

To give you a sample of the kinds of issues that inspire us, here are two aspects of the Internet’s footprint which are very much within the SUSTAIN RG’s scope.

First, carbon efficiency. The CO2 emissions associated with a router that is powered by a fossil fuel-based power plant are very different from the CO2 emissions that the same router would have were it powered by a wind turbine. Thus, reducing the energy usage of Internet equipment is necessary but not sufficient; the carbon efficiency of energy creation must be taken into account as well. Since some data on carbon efficiency exists (see, for example, Electricity Maps), a question becomes: how should Internet protocols and algorithms make use of this information?

Imbuing routing and traffic engineering with carbon awareness has frequently been mentioned. While having limited immediate effect (because most wired equipment exhibits little power proportionality today), sending traffic along “greener” paths could create a positive feedback loop, i.e., strongly incent the market to become greener because the income of ISPs typically relates to the amount of traffic they forward.

Second, the reduction of embodied emissions. These are CO2 emissions caused by everything but the operation of equipment: mining the needed materials, manufacturing, transport, etc. Depending on the size of the hardware element in question, these emissions can sometimes be much more than the operational emissions (the smaller the element, the more embodied emissions). A related question becomes: how can we reduce the amount of hardware that is deployed? Is there a way to slow down upgrade cycles, also reducing landfill waste, perhaps even without impeding the quality experienced by end users?

One possible direction is to design mechanisms that can inform users and ISPs about the possible practical gains that a capacity upgrade might yield. In other words, create a more meaningful “speed test”. Some “speed test” facilities already include latency in their estimation, recognizing that bits per second is often not the most useful metric for today’s networked applications – but is this enough? Could there be ways to proactively determine what the real benefits of a certain type of hardware upgrade might yield? For example, if a user primarily watches Internet video and otherwise only uses the network for text messaging and email, and network capacity is already enough for great video quality, a further capacity upgrade is unlikely to yield a significant benefit.

Do these kinds of ideas inspire you? Would you like to hear more? Do you have other research ideas you would like to contribute? For more details and to join the discussion, visit the SUSTAIN RG page, join our mailing list, and participate in our first meeting during IETF 122 Bangkok. You can also review the information from the side meeting held during the IETF -121 in Dublin. The IETF 122 SUSTAIN session will be held at 6:00 - 8:00 UTC on Tuesday, 18 March. You can participate either onsite or remotely. 


Share this page