<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Sixgate on billpg industries™</title><link>https://owl.billpg.com/tags/sixgate/</link><description>Recent content in Sixgate on billpg industries™</description><generator>Hugo</generator><language>en-us</language><copyright>© William Godfrey.</copyright><lastBuildDate>Tue, 10 Feb 2026 22:14:52 +0000</lastBuildDate><atom:link href="https://owl.billpg.com/tags/sixgate/index.xml" rel="self" type="application/rss+xml"/><item><title>The Road Not Taken: A World Where IPv4 Evolved</title><link>https://owl.billpg.com/ipv4x/</link><pubDate>Tue, 10 Feb 2026 22:14:52 +0000</pubDate><guid>https://owl.billpg.com/ipv4x/</guid><description>&lt;p&gt;IP address exhaustion is still with us. Back in the early 1990s, when the scale of the problem first became obvious, the projections were grim. Some estimates had us running out of IPv4 addresses as early as 2005 and even the optimistic ones didn’t push much beyond the following decade.&lt;/p&gt;
&lt;p&gt;As the years passed, we got clever. Or perhaps, more desperate.&lt;/p&gt;
&lt;p&gt;We managed to put off that imminent exhaustion for decades, breaking the Internet in the process in small, subtle ways. Want multiple home machines behind a single IP? No problem — we invented NAT. ISPs want in on that “multiple devices, one address” trick? Sure, have some Carrier‑Grade NAT. Want to run a server on your home machine? Er… no.&lt;/p&gt;</description></item><item><title>SixGate Part Two - A Security Analysis</title><link>https://owl.billpg.com/sixgate-part-two-a-security-analysis/</link><pubDate>Thu, 05 Feb 2026 20:01:40 +0000</pubDate><guid>https://owl.billpg.com/sixgate-part-two-a-security-analysis/</guid><description>&lt;p&gt;&lt;a href="https://owl.billpg.com/sixgate/" data-type="post" data-id="1178"&gt;Part One - What is SixGate?&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;In brief, if a client with IPv4 only wishes to connect to an IPv6‑only service, SixGate bridges the gap by looking up a special SRV record in the service’s &lt;code&gt;ip6.arpa&lt;/code&gt; zone, normally used for reverse‑DNS. This record points to a gateway service provided by the operator of that IPv6 network. Using that gateway, any machine that only has IPv4 can connect to the world of IPv6 — all working silently, without the user needing to know what’s going on.&lt;/p&gt;</description></item><item><title>Sixgate - IPv6 Without Leaving Anyone Behind</title><link>https://owl.billpg.com/sixgate/</link><pubDate>Thu, 29 Jan 2026 19:14:42 +0000</pubDate><guid>https://owl.billpg.com/sixgate/</guid><description>&lt;p&gt;The internet is inching toward IPv6, but not nearly fast enough. Server operators are increasingly comfortable running services on IPv6‑only infrastructure, yet a stubborn reality remains: many users are still stuck behind IPv4‑only networks. Legacy ISPs, old routers, and long‑lived hardware keep a surprising number of clients stranded on the old protocol.&lt;/p&gt;
&lt;p&gt;That creates a familiar kind of stalemate. Just as the lack of SNI support in Windows XP once discouraged sites from adopting HTTPS, today’s pockets of IPv4‑only clients discourage operators from going IPv6‑only. No one wants to cut off part of their audience, so IPv4 lingers on long after its sell‑by date.&lt;/p&gt;</description></item></channel></rss>