# IETF Published articles for IETF. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## The /3 Body Problem DevFeed: [The /3 Body Problem]() Original publisher: [Read original article]() Author: Remco van Mook Published: 2026-09-10T09:22:46Z Content type: article Language: en Sources: [RIPE Labs]() Topics: [networking](), [Internet](), [Internet Engineering Task Force (IETF)]() Tags: [article](), [ietf](), [internet](), [ipv6](), [networking](), [policy](), [space]() ### AI overview The article examines how IPv6 addressing and policy mechanisms may need to evolve for space networking. It argues that terrestrial assumptions break down beyond low Earth orbit and calls for addressing policy questions now, including through the proposed EXPANSE working group. ### Source excerpt A large chunk of IPv6 is heading for space, and every policy question about it is currently going to be deferred to the RIR communities. This article outlines what those questions look like, and argues why now is the time to start asking them. ## \[Podcast\] Measuring the impact of locally served root zone DevFeed: [\[Podcast\] Measuring the impact of locally served root zone]() Original publisher: [Read original article]() Author: George Michaelson Published: 2026-09-03T01:05:09Z Content type: article Language: en Sources: [APNIC Blog]() Topics: [DNSSEC](), [Network](), [Security](), [Internet Engineering Task Force (IETF)](), [bug]() Tags: [bug](), [dns](), [dnssec](), [ietf](), [measurement](), [network](), [podcast](), [research](), [security](), [standards](), [tech-matters]() ### AI overview This podcast discusses research into locally served root zones, a DNS resolver model that pre-fetches and stores the root zone. The study examined BIND, Unbound, and Knot Resolver across multiple configurations, including in-band retrieval and HTTPS fetching. It identified an Unbound bug and found that root zone updates can generate substantial network traffic, potentially exceeding traffic from more frequent queries for uncached data. ### Source excerpt An analysis of the traffic impacts of locally served root zones, by Ilyas Rahimi at UvA. ## The emerging role of AI in governance discussion DevFeed: [The emerging role of AI in governance discussion]() Original publisher: [Read original article]() Author: George Michaelson Published: 2026-08-26T04:50:50Z Content type: article Language: en Sources: [APNIC Blog]() Topics: [Internet Engineering Task Force (IETF)](), [Large Language Model](), [Artificial Intelligence](), [AI Strategy]() Tags: [ai](), [artificial-intelligence](), [content](), [eu](), [governance](), [ietf](), [large-language-model](), [llm](), [standards](), [tech-matters]() ### AI overview The article examines an ongoing IETF debate over the use and disclosure of LLM-generated text in drafts, standards work, and discussions. It also compares these concerns with EU efforts to promote transparency and labelling of AI-generated or AI-modified content. ### Source excerpt A growing debate within the IETF is exploring how AI-generated content should be used and disclosed in standards discussions. ## AI, IPv6, and the future Internet at IETF 126 DevFeed: [AI, IPv6, and the future Internet at IETF 126]() Original publisher: [Read original article]() Author: Anlei Hu Published: 2026-08-25T01:20:50Z Content type: article Language: en Sources: [APNIC Blog]() Topics: [Internet](), [Internet Engineering Task Force (IETF)](), [networking](), [Artificial Intelligence](), [AI Agent](), [Network](), [Security](), [Latency](), [telemetry]() Tags: [ai](), [dns](), [guest-post](), [ietf](), [infrastructure](), [internet](), [internet-infrastructure](), [ipv6](), [latency](), [low-latency](), [nat](), [network](), [networks](), [opinion](), [security](), [standards](), [tech-matters](), [telemetry]() ### AI overview The article reports on IETF 126 discussions about how AI is shaping Internet infrastructure. It presents IPv6 as important for the scale, globally unique addressing, and traceability required by distributed AI deployments and agents, while DNS remains central to service discovery. It also covers IPv4/IPv6 mapping, NAT-related identity and security concerns, SRv6, low-latency forwarding, IOAM telemetry, and proposals for DNS-based AI agent discovery. ### Source excerpt Guest Post: At IETF 126, discussions highlighted how AI is beginning to shape the future of Internet infrastructure. Participants identified IPv6 as a critical foundation for large-scale AI ecosystems and explored new approaches. ## Worth Reading 081026 DevFeed: [Worth Reading 081026]() Original publisher: [Read original article]() Author: Russ Published: 2026-08-10T19:50:20Z Content type: article Language: en Sources: [rule 11 reader]() Topics: [Artificial Intelligence](), [Open Source Models & Datasets](), [networking](), [Routing (disambiguation)](), [Internet Engineering Task Force (IETF)](), [App]() Tags: [ai](), [ietf](), [open-source](), [routing](), [tech](), [worth-reading]() ### AI overview A roundup of reading topics covering the conflict over open-source AI in U.S. AI companies, a network routing application that checks prefix advertisements against live RIPE RIS data, and communications-protocol standardization discussed at IETF 126. ### Source excerpt There is an interesting fight within the leadership of U.S. AI companies. It is between the supporters of open-source AI and those driven to oppose open-source AI. A Chinese man accused by the communist authorities of having committed "economic crimes" figured that he could evade the long reach of the country's police state by hiding out in plain view: in a stadium packed with 60,000 people listening to a pop concert. The J2SW Prefix Advertisement Checker, my 3rd application in the network series, checks the exact prefix against live routing data and reports the origin ASN seen by RIPE RIS collectors. A growing number of drivers are pushing back against increasingly tech-heavy vehicles, saying they prefer the simplicity of a The IETF does not launch rockets, or design spacecraft, or even work on radio systems and spectrum assignment, but it has been engaged in the standardisation of communications protocols used to communicate with these spacecraft. Here's a few topics that were presented at IETF 126. ## SCIM Deprovisioning Is a Promise Your App Probably Breaks DevFeed: [SCIM Deprovisioning Is a Promise Your App Probably Breaks]() Original publisher: [Read original article]() Author: WorkOS Published: 2026-08-06T01:29:36Z Content type: article Language: en Sources: [WorkOS Blog]() Topics: [Security](), [API](), [HTTP](), [JSON](), [Internet Engineering Task Force (IETF)](), [Protocol (disambiguation)]() Tags: [api](), [http](), [identity](), [idp](), [ietf](), [json](), [net-conf](), [protocol](), [schema](), [security](), [standards](), [state](), [token]() ### AI overview This article explains that SCIM deprovisioning updates identity state but does not automatically invalidate an application's sessions, refresh tokens, or API keys. It describes how identity providers commonly use soft deactivation and why applications must explicitly handle the resulting offboarding state. ### Source excerpt SCIM tells you a user is gone, but sessions, refresh tokens, and API keys often outlive deprovisioning. Here's why offboarding needs more than a user row. ## HTTP QUERY: the method that was missing between GET and POST DevFeed: [HTTP QUERY: the method that was missing between GET and POST]() Original publisher: [Read original article]() Author: Matteo Baccan Published: 2026-07-29T12:26:29Z Content type: article Language: en Sources: [Backend Job: skill, salary and insights - Codemotion Magazine]() Topics: [HTTP](), [Back end](), [Web](), [Security](), [Caching]() Tags: [backend](), [caching](), [firewall](), [http](), [http-query](), [ietf](), [load-balancing](), [post](), [security](), [siem](), [web]() ### AI overview This article examines the proposed HTTP QUERY method, which is intended to combine the safety and idempotency of GET with the ability to carry an extended request body like POST. It discusses the limitations and security risks of putting complex or sensitive queries in URLs, and considers the method's effects on caching, infrastructure compatibility, and future backend implementation. ### Source excerpt For nearly thirty years, the Web has lived with a semantic paradox that anyone developing for the backend knows well: how do you execute a complex, voluminous query, or one containing sensitive data, if the only "safe" method available does not allow a request body? Think about when we need to send a structured search... Read more The post HTTP QUERY: the method that was missing between GET and POST appeared first on Codemotion Magazine. ## Worth Reading 072826 DevFeed: [Worth Reading 072826]() Original publisher: [Read original article]() Author: Russ Published: 2026-07-28T10:59:47Z Content type: article Language: en Sources: [rule 11 reader]() Topics: [Internet](), [data](), [Internet Engineering Task Force (IETF)](), [Networks](), [5G](), [Machine learning]() Tags: [5g](), [ai](), [arp](), [article](), [data](), [ietf](), [internet](), [ipv6](), [networks](), [worth-reading]() ### AI overview A developer reading roundup covering Internet infrastructure, synchronization of replicated data, IPv6-only networking, IPv4 dependencies, ARP, an IETF proposal, 5G control-plane timers, modern machine-learning pipelines, and the integration of AI into everyday applications. ### Source excerpt Today's Internet runs on a vast infrastructure of replicated data, and the difference between order and chaos lies in maintaining consistency through synchronization across the many distributed points where that data is published. IPv6-only networks often still depend on IPv4 subnets and ARP. This article introduces an IETF proposal to eliminate both. Traditional software engineering approaches reliability as a binary state of uptime and downtime. Modern ML pipelines render this paradigm obsolete. Yet while the radios and protocols largely reuse terrestrial 5G designs, one small but crucial component has been left behind: The control plane timers that quietly govern how registration, mobility, and session procedures behave under real-world conditions. Apparently, nearly all of them have reached the same conclusion. I don't merely need AI occasionally. I need it waiting inside every search bar, messaging app, music player, and document reader I already use. ## What's ARP Got to Do with It? DevFeed: [What's ARP Got to Do with It?]() Original publisher: [Read original article]() Author: Remco van Mook Published: 2026-07-23T06:35:41Z Content type: article Language: en Sources: [RIPE Labs]() Topics: [Internet](), [Network](), [Networks](), [FIRST]() Tags: [arp](), [article](), [enterprise](), [ietf](), [internet](), [internet-infrastructure](), [ipv4](), [network](), [networks]() ### AI overview The article examines why ARP still matters by distinguishing durable demand for IPv4 reachability from the local-network architecture traditionally used to provide it. It argues that many access and hosting segments isolate subscribers or tenants and use the local IPv4 subnet mainly as a mechanism for reaching the gateway, rather than for lateral communication. ### Source excerpt It's only ARP. It works. So how much can it really matter? The answer lies beyond ARP itself, in the IPv4 layer cake that grew around it over four decades. The IPv4 internet is not going away in bounded time, and nobody should pretend otherwise. ## Hedge 306: RPKI Transport DevFeed: [Hedge 306: RPKI Transport]() Original publisher: [Read original article]() Author: Russ Published: 2026-05-22T15:33:40Z Content type: article Language: en Sources: [rule 11 reader]() Topics: [BGP](), [Security](), [Protocol (disambiguation)](), [Internet](), [Internet Engineering Task Force (IETF)]() Tags: [audio](), [bgp](), [hedge](), [ietf](), [internet](), [protocol](), [rpki](), [security]() ### AI overview This podcast discusses ERIK, a protocol developed to synchronize RPKI records used to provide security information for BGP across the Internet. Job Snijders joins Tom and Russ to explain the protocol and its requirements. ### Source excerpt Synchronizing information across the Internet, at an initial glance, looks like a fairly simple problem to solve. Just copy a file to a host and create a magic protocol, right? Not really. Each kind of data has a fairly unique set of requirements--and RPKI data, used to provide security information for BGP, is no different. Job Snijders joins Tom and Russ to talk about ERIK, a protocol developed to synchronize RPKI records. ## Three Things Made My Blog Agent-Ready. Five I Skipped on Purpose. DevFeed: [Three Things Made My Blog Agent-Ready. Five I Skipped on Purpose.]() Original publisher: [Read original article]() Published: 2026-04-30T00:00:00Z Content type: opinion Language: en Sources: [Alex Korbonits]() Topics: [Web](), [Netlify](), [Cloudflare](), [RSS Feed]() Tags: [ai-agents](), [blog](), [cloudflare](), [ietf](), [markdown](), [mcp-oauth](), [netlify](), [robots-txt](), [rss](), [web]() ### AI overview The author describes improving a personal blog's score on Cloudflare's agent-readiness checker from 25 to 50 by adding content signals in robots.txt and Link headers through Netlify. The article argues that personal blogs should implement applicable agent-facing features while skipping API, OAuth, and MCP requirements that do not fit their purpose. ### Source excerpt Cloudflare's isitagentready.com scored korbonits.com at 25 / Level 1 'Basic Web Presence.' Two hours and three small additions later it scored 50 / Level 4 'Agent-Integrated.' The other half of the points came from checks that don't apply to a personal blog -- and shipping fake compliance for them would be theatre, not value. ## Chrome develops Merkle Tree Certificates for quantum-resistant HTTPS DevFeed: [Chrome develops Merkle Tree Certificates for quantum-resistant HTTPS]() Original publisher: [Read original article]() Author: Google (noreply@blogger.com) Published: 2026-02-27T17:01:00Z Content type: release Language: en Sources: [Google Online Security]() Topics: [Chrome](), [Post-quantum cryptography](), [Certificate Transparency](), [Internet Engineering Task Force (IETF)](), [TLS (Transport Layer Security)](), [Scalability](), [Security](), [Cryptography]() Tags: [certificate-transparency](), [chrome](), [ietf](), [none](), [post-quantum-cryptography](), [scalability](), [security](), [tls](), [web]() ### AI overview Chrome is developing Merkle Tree Certificates with partners through the IETF PLANTS working group to support quantum-resistant HTTPS while reducing the bandwidth and performance costs of larger post-quantum certificate chains. Chrome says it has no immediate plan to add traditional post-quantum X.509 certificates to the Chrome Root Store and is experimenting with MTCs using real internet traffic. ### Source excerpt Posted by Chrome Secure Web and Networking Team Today we're announcing a new program in Chrome to make HTTPS certificates secure against quantum computers. The Internet Engineering Task Force (IETF) recently created a working group, PKI, Logs, And Tree Signatures ("PLANTS"), aiming to address the performance and bandwidth challenges that the increased size of quantum-resistant cryptography introduces into TLS connections requiring Certificate Transparency (CT). We recently shared our call to action to secure quantum computing and have written about challenges introduced by quantum-resistant cryptography and some of the steps we've taken to address them in earlier blog posts. To ensure the scalability and efficiency of the ecosystem, Chrome has no immediate plan to add traditional X.509 certificates containing post-quantum cryptography to the Chrome Root Store. Instead, Chrome, in collaboration with other partners, is developing an evolution of HTTPS certificates based on Merkle Tree Certificates (MTCs), currently in development in the PLANTS working group. MTCs replace the heavy, serialized chain of signatures found in traditional PKI with compact Merkle Tree proofs. In this model, a Certification Authority (CA) signs a single "Tree Head" representing potentially millions of certificates, and the "certificate" sent to the browser is merely a lightweight proof of inclusion in that tree. Why MTCs? MTCs enable the adoption of robust post-quantum algorithms without incurring the massive bandwidth penalty of classical X.509 certificate chains. They also decouple the security strength of the corresponding cryptographic algorithm from the size of the data transmitted to the user. By shrinking the authentication data in a TLS handshake to the absolute minimum, MTCs aim to keep the post-quantum web as fast and seamless as today's internet, maintaining high performance even as we adopt stronger security. Finally, with MTCs, transparency is a fundamental property of issuance: ## On MPLS Forwarding Performance Myths DevFeed: [On MPLS Forwarding Performance Myths]() Original publisher: [Read original article]() Published: 2026-02-05T07:20:00Z Content type: opinion Language: en Sources: [ipSpace.net blog]() Topics: [networking](), [Ethernet](), [Cisco](), [Hardware]() Tags: [cisco](), [devices](), [hardware](), [ietf](), [ip](), [mpls](), [performance](), [switching]() ### AI overview The article examines claims about the original motivation for MPLS, arguing that aggregate forwarding performance in core devices mattered more than accelerating individual IP table lookups. It describes how mid-1990s service providers combined routers at the network edge with ATM switches in the core because routers lacked sufficient aggregate bandwidth. ### Source excerpt Whenever I claim that the initial use case for MPLS was improved forwarding performance (using the RFC that matches the IETF MPLS BoF slides as supporting evidence), someone inevitably comes up with a source claiming something along these lines: The idea of speeding up the lookup operation on an IP datagram turned out to have little practical impact. That might be true1, although I do remember how hard it was for Cisco to build the first IP forwarding hardware in the AGS+ CBUS controller. Switching labels would be much faster (or at least cheaper), but the time it takes to do a forwarding table lookup was never the main consideration. It was all about the aggregate forwarding performance of core devices. Anyhow, Duty Calls. It's time for another archeology dig. Unfortunately, most of the primary sources irrecoverably went to /dev/null, and personal memories are never reliable; comments are most welcome. Read more ... ## HTTP RateLimit headers DevFeed: [HTTP RateLimit headers]() Original publisher: [Read original article]() Published: 2026-01-14T02:34:22Z Content type: article Language: en Sources: [Tony Finch's blog]() Topics: [HTTP](), [Algorithms](), [Internet Engineering Task Force (IETF)](), [client]() Tags: [algorithm](), [client](), [headers](), [http](), [ietf](), [server]() ### AI overview The article examines the IETF draft for HTTP RateLimit headers and argues that the headers can support linear rate-limit algorithms such as GCRA, encouraging smoother client request behavior than quota-reset algorithms. ### Source excerpt There is an IETF draft that aims to standardize RateLimit header fields for HTTP. A RateLimit header in a successful response can inform a client when it might expect to be throttled, so it can avoid 429 Too Many Requests errors. Servers can also include RateLimit headers in a 429 response to make the error more informative. The draft is in reasonably good shape. However as written it seems to require (or at least it assumes) that the server uses bad quota-reset rate limit algorithms. Quota-reset algorithms encourage clients into cyclic burst-pause behaviour; the draft has several paragraphs discussing this problem. However, if we consider that RateLimit headers are supposed to tell the client what acceptable behaviour looks like, they can be used with any rate limit algorithm. (And it isn't too hard to rephrase the draft so that it is written in terms of client behaviour instead of server behaviour.) When a client has more work to do than will fit in a single window's quota, linear rate limit algorithms such as GCRA encourage the client to smooth out its requests nicely. In this article I'll describe how a server can use a linear rate limit algorithm with HTTP RateLimit headers. spec summary policy parameters linear rate limit algorithm other rate limiters spec summary The draft specifies two headers: RateLimit-Policy: describes input parameters to a rate limit algorithm, which the server chooses based on the request in some unspecified way. The policies are expected to be largely static for a particular client. The parameters are, the name of the policy pk, the partition key q, the quota w, the window qu, the quota units RateLimit: describes which policies the server applied to this request, and the output results of the rate limit algorithm. The results are likely to vary per request depending on client behaviour or server load, etc. The results are, the name of the policy pk, the partition key r, the available quota t, the effective window Both headers can list ## IETF v6ops Working Group with Nick Buraglio DevFeed: [IETF v6ops Working Group with Nick Buraglio]() Original publisher: [Read original article]() Published: 2025-12-11T07:03:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [Internet Engineering Task Force (IETF)](), [Networks](), [Deployment]() Tags: [ietf](), [ipv6](), [networks](), [podcast](), [software-gone-wild]() ### AI overview This article discusses why the IETF v6ops Working Group remains active 30 years after the first IPv6 specifications. It highlights the group's work on guidelines for deploying and operating IPv6 networks and references Nick Buraglio's answers in Episode 203 of the Software Gone Wild podcast. ### Source excerpt The first IPv6 specs were published in 1995, and yet 30 years later, we still have a pretty active IETF working group focused on "developing guidelines for the deployment and operation of new and existing IPv6 networks." (taken from the old charter; they updated it in late October 2025). Why is it taking so long, and what problems are they trying to solve? Nick Buraglio, one of the working group chairs, provided some answers in Episode 203 of the Software Gone Wild podcast. Read more ... ## IS-IS 3-Way Handshake and the Power of SHOULD DevFeed: [IS-IS 3-Way Handshake and the Power of SHOULD]() Original publisher: [Read original article]() Published: 2025-07-01T06:17:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [IS-IS](), [Cisco](), [Internet Engineering Task Force (IETF)](), [Handshake]() Tags: [cisco](), [download](), [ietf](), [is-is](), [standard](), [standards]() ### AI overview The article explains why Cisco's pre-standard IS-IS 3-way handshake can interoperate with RFC 5303 implementations. It attributes this to RFC 5303 making some TLV 240 fields optional, while Cisco's IETF handshake includes additional fields that can be validated when present. ### Source excerpt Yesterday, I mentioned that a Cisco router running pre-standard IS-IS 3-way handshake (this is why you need it) interoperates with multiple implementations of RFC 5303. How's that possible, and does it matter whether you configure the ancient Cisco routers (release 15.x) to use IETF 3-way handshake instead of the "proprietary" one? TL&DR: It SHOULD NOT matter, but the more I explore the RFCs, the more I'm amazed anything works at all. I took a trip to the Wireshark land to figure out the details (you can download the capture file): Read more ... ## Start netlab Tools without Changing Topology File DevFeed: [Start netlab Tools without Changing Topology File]() Original publisher: [Read original article]() Published: 2025-06-30T07:14:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [IS-IS](), [Network](), [Cisco](), [Tool](), [P2P]() Tags: [cisco](), [ietf](), [is-is](), [netlab](), [network](), [p2p](), [tools]() ### AI overview This article explains how to enable the Edgeshark tool in netlab without modifying individual lab topology files. It uses an environment-variable default and a reproduced IS-IS integration test to investigate interoperability with older IOSv images. The investigation finds that FRRouting and Arista EOS accept Cisco routers sending pre-standard P2P IS-IS hello messages with missing sub-TLVs. ### Source excerpt Dan Partelly figured out that we have to configure the standard (IETF) 3-way IS-IS handshake on old IOSv images. On the other hand, all IS-IS integration tests pass for IOSv and IOSvL2. I wondered what was going on. Fortunately, a few months ago, I spent some time installing the client-side Edgeshark components on my laptop. All I needed to do was enable the edgeshark tool in my lab topology and restart the lab. Read more ... ## Chainguard Containers Enabled with PQC Support DevFeed: [Chainguard Containers Enabled with PQC Support]() Original publisher: [Read original article]() Published: 2025-06-03T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [chainguard containers](), [Post Quantum Cryptography (PQC)](), [Cryptography](), [TLS (Transport Layer Security)](), [Security, Privacy and Abuse Prevention](), [ssh](), [Internet Engineering Task Force (IETF)]() Tags: [chainguard-containers](), [compliance](), [cryptography](), [encryption](), [fips](), [ietf](), [nist](), [post-quantum-cryptography](), [post-quantum-cryptography-pqc](), [quantum](), [ssh](), [tls]() ### AI overview Chainguard Containers now support Post-Quantum Cryptography (PQC), including FIPS 203 ML-KEM and other algorithms used in TLS and SSH communications. The article explains the risks posed by quantum attacks and "harvest now, decrypt later" scenarios, and describes ongoing work toward FIPS-certified PQC implementations. ### Source excerpt Chainguard Containers support Post-Quantum Cryptography (PQC). Learn more about what PQC is, and what Chainguard is doing to offer it today. ## New IPv6 Documentation Prefix DevFeed: [New IPv6 Documentation Prefix]() Original publisher: [Read original article]() Published: 2025-01-11T06:51:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [Internet Engineering Task Force (IETF)](), [Documentation]() Tags: [documentation](), [ietf](), [ipv6]() ### AI overview The article discusses RFC 9637, which defines the larger 3fff::/20 IPv6 documentation prefix after discussions in the IETF v6ops working group. It argues that examples should use documentation address space instead of public IPv6 addresses. ### Source excerpt After three and a half years of haggling (the IETF draft that became the RFC was written in May 2021; the original discussions go back to 2013), Nick Buraglio & co managed to persuade pontificators bikeshedding in the v6ops working group that we might need an IPv6 documentation prefix larger than the existing 2001:db8::/32. With the new documentation prefix (3fff::/20) (defined in RFC 9637), there's absolutely no excuse to use public IPv6 address space in examples anymore. ## WTF Are JWTs? DevFeed: [WTF Are JWTs?]() Original publisher: [Read original article]() Author: Andrew Tate Published: 2024-11-29T16:37:34Z Content type: article Language: en Sources: [Blog -- Neon Docs]() Topics: [JSON Web Tokens](), [Authentication](), [Authorization](), [Security](), [Internet Engineering Task Force (IETF)](), [Scalability]() Tags: [authentication](), [authorization](), [community](), [ietf](), [scalability](), [security](), [tokens](), [web]() ### AI overview This article explains what JSON Web Tokens (JWTs) are, how digitally signed JSON objects enable parties to verify transmitted information, and why JWTs became widely used for stateless authentication. It also connects JWTs to Neon RLS and Postgres authorization, and describes their benefits for cross-domain compatibility, scalability, flexibility, and security. ### Source excerpt We recently launched Neon RLS to simplify Postgres authorization with row-level security. If you've been reading our posts, tutorials, or READMEs on the subject, you'll have come across three little letters: JWT. This whole world seems to run on JWTs-so what are they? JWTs, or JS... ## Lab: Dual-Stack IS-IS Routing DevFeed: [Lab: Dual-Stack IS-IS Routing]() Original publisher: [Read original article]() Published: 2024-11-29T06:47:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [IS-IS](), [networking](), [Routing (disambiguation)](), [Protocol (disambiguation)](), [Internet Engineering Task Force (IETF)]() Tags: [ietf](), [ipv4](), [ipv6](), [is-is](), [netlab](), [ospf](), [protocol](), [routing]() ### AI overview This lab examines dual-stack IS-IS routing for IPv4 and IPv6. It explains that IS-IS supported multiple protocols early on and discusses two incompatible methods for enabling IPv6 through additional TLVs. ### Source excerpt Contrary to the OSPF world, where we have to use two completely different routing protocols to route IPv4 and IPv6 (unless you believe in the IPv4 address family in OSPFv3), IS-IS provided multi-protocol support from the very early days of its embracement by IETF. Adding IPv6 support was only a matter of a few extra TLVs, but even there, IETF gave us two incompatible ways of making IPv6 work with IS-IS. Read more ... ## IPv6 Support for Multiple Routers and Multiple Interfaces DevFeed: [IPv6 Support for Multiple Routers and Multiple Interfaces]() Original publisher: [Read original article]() Published: 2024-11-28T10:57:00Z Content type: opinion Language: en Sources: [ipSpace.net blog]() Topics: [Internet Engineering Task Force (IETF)](), [Networks](), [Internet](), [Protocol (disambiguation)](), [Mobile]() Tags: [ietf](), [internet](), [ipv6](), [mobile](), [nat](), [networks](), [protocol](), [tcp]() ### AI overview The article comments on Fernando Gont's Individual Internet Draft about IPv6 support for multiple routers and interfaces. It argues that the draft clearly describes a long-standing multihoming problem and says current practical options are NAT or rarely implemented host-based solutions, while questioning whether an IETF working group will adopt the draft. ### Source excerpt Fernando Gont published an Individual Internet Draft (meaning it hasn't been adopted by any IETF WG yet) describing the Problem Statement about IPv6 Support for Multiple Routers and Multiple Interfaces. It's so nice to see someone finally acknowledging the full scope of the problem and describing it succinctly. However, I cannot help but point out that: I was ranting about that problem in 2009 (15 years ago) and did a summary of older rants in 2015. It was evident to everyone but the religious zealots that the only solution we have at the moment is either NAT (because stuff simply does not work otherwise) or host-based solutions that never got implemented (apart from a few rare cases of multipath TCP). Anyway, Fernando wraps up his draft with: Read more ... ## 22 years later, YAML now has a media type DevFeed: [22 years later, YAML now has a media type]() Original publisher: [Read original article]() Author: HTTP Toolkit; Tim Perry Published: 2024-02-20T15:00:00Z Content type: article Language: en Sources: [HTTP Toolkit]() Topics: [YAML](), [HTTP](), [API](), [interoperability](), [OpenAPI Specification](), [Internet Engineering Task Force (IETF)](), [Security](), [Rails]() Tags: [api](), [http](), [ietf](), [interoperability](), [openapi](), [security](), [specifications](), [standard](), [standards](), [yaml]() ### AI overview The article explains that RFC 9512 formally registers application/yaml as the media type for YAML and defines +yaml as a structured suffix for YAML-based media types. It discusses the implications for HTTP metadata, OpenAPI specifications, interoperability, existing application conventions, and security considerations. ### Source excerpt As of February 14th 2024, RFC 9512 formally registers application/yaml as the media type for all YAML content, and adds +yaml as a standard structured suffix for all YAML-based more specific media types. With this registration, it's now included in the official media types list maintained by the IANA. Media types like this (also known as the MIME types, from their original invention for email attachment metadata) are heavily used particularly in HTTP Content-Type headers for both requests & responses, and in all sorts of file metadata and processing logic elsewhere. These names give applications a common vocabulary to describe data when passing it around. The additional +yaml suffix also defined here is particularly useful. Media type structured suffixes like this (+xml and +json are other common examples) are used to define specific types for content that's based on an existing generic content type (such as YAML). In this case, this notably opens the door to standardization of other YAML-based MIME types, such as application/openapi+yaml (for OpenAPI specifications that are written in YAML) which is currently being formalized in another standard, following closely behind this one. While a few applications have been using application/yaml and +yaml like this already, many haven't (e.g. Rails still uses application/x-yaml, and others like text/yaml and even text/x-yaml are frequently seen in the wild) and there's never been clear agreement on exactly how this should work. Hopefully with this RFC we'll be able to start picking a single media type consistently from now on, though updating older applications here will obviously take some time. The full RFC is well worth a read if you're interested in the finer details, and discusses all sorts of more detailed questions around interoperability for an evolving language like YAML, its relationship with JSON, and the (many) security considerations to be aware of when defining a formal API around YAML data. This RFC is just ## Working with the new Idempotency Keys RFC DevFeed: [Working with the new Idempotency Keys RFC]() Original publisher: [Read original article]() Author: HTTP Toolkit; Phil Sturgeon Published: 2023-12-12T15:00:00Z Content type: tutorial Language: en Sources: [HTTP Toolkit]() Topics: [HTTP](), [Internet Engineering Task Force (IETF)](), [client](), [Server](), [stripe]() Tags: [apis](), [http](), [ietf](), [payment](), [request](), [server](), [standards](), [stripe](), [timeout]() ### AI overview This article explains how idempotency keys make retries safe for HTTP API operations, especially POST and PATCH requests that modify server state. It discusses an IETF draft RFC and the risks of duplicate actions such as payments when clients time out. ### Source excerpt Idempotency is when doing an operation multiple times is guaranteed to have the same effect as doing it just once. When working with APIs this is exceptionally helpful on slow or unreliable internet connections, or when dealing with particularly sensitive actions such as payments, because it makes retrying operations safe and reliable. This is why most payment gateways like Stripe and Adyen support 'idempotency keys' as a key feature of their APIs. Recently, the IETF have gone further, and created a draft RFC standard for this useful common pattern, as part of the 'Building Blocks for HTTP APIs' working group. This is technically still a draft and the details could change, but it's fairly mature now and increasingly widely used, so it's a good time to take a closer look, and start using & implementing it for yourself. Idempotency in HTTP APIs Many HTTP methods are defined as idempotent in all cases. In theory, any GET, HEAD, PUT, DELETE, OPTIONS, or TRACE operation can be executed multiple times without any unintended side effects (though for badly behaved APIs your mileage may vary). The idea is that an HTTP request like DELETE /users/123 clearly wants to delete that user, and if that accidentally happens twice then that's just fine. User 123 ends up deleted just the same. It's a lot more complicated for POST and PATCH requests, which do not provide that same level of confidence out of the box. These are designed to allow non-idempotent operations, like adding a new user, sending a payment, or appending to existing data. Those are important use cases too - sometimes you really do want to send the same thing twice, and have it happen twice - but this can cause problems when things go wrong. When sending POST and PATCH requests to modify server state, if you want to support retries then both the client and server need to explicitly handle this - which is exactly what idempotency keys are designed to allow you to do. How can non-idempotency go wrong? Without idempoten [Next page]()