The DataPlane.org proto41 feed is now publicly available. The proto41 feed identifies IPv4 addresses that have been observed as open IPv6 over IPv4 tunnel relays. This feed at once becomes the largest and in some ways the most unique DataPlane.org produces. This is the first project feed based on active network surveying rather than relying on a network of passive sensors. This feed is not only unique to DataPlane.org, but as far as I can tell, the first anywhere to report on open IPv6 tunnel relays. This post provides some additional background and detail of this new feed.
The proto41 feed is the culmination of one of my first PhD research projects. What started as a security class paper on the implications of ISATAP in the wild morphed into a more general examination of legacy IPv6 automatic transition mechanisms. Part way through the formal research phase, out of curiosity I began experimenting with probing the IPv4 Internet with a variety of IPv6 over IPv4 (IP protocol 41) messages. I eventually stumbled on a surprising discovery. I found over 1.5 million IPv4 addresses would relay these messages to whatever IPv6 destination I choose from most any IPv6 source address I set.
It turns out there are many hundreds of thousands of IPv4 addresses on the Internet that will perform this feat. Many of these systems receiving a protocol 41 packet will remove the IPv4 header and use 6to4 to forward them further. That is, they will add a new IPv4 header with a local IPv4 source address, set the IPv4 destination to the well-known 6to4 IPv4 gateway address of 192.88.99.1, and forward towards a 6to4 gateway. Even though the 6to4 anycast prefixes have been deprecated in IETF RFC 7526, there remains at least two providers advertising a covering prefix and providing 6to4 gateway services, Hurricane Electric and SURFnet. While the use of the 6to4 mechanism accounts for many addresses in the feed, some systems have been found to simply remove the IPv4 header and forward the encapsulated IPv6 datagram natively. At least one large network equipment vendor exhibited this behavior with a certain class of backbone gear, but I suspect there are others. The vendor I know to have had gear behaving this way provided a work around on affected software and updated their code base nearly a year ago to mitigate the issue entirely. No, I’m not publicly disclosing who this particular vendor is.
As a budding researcher with an interest in operational security issues such as address spoofing and DDoS attacks, this was all kind of exciting to discover. On what was more or less a whim became one of the key findings of my first big research project. Bringing these discoveries to the operational community was one thing I had been familiar with and done many times before. For example, I had also made discoveries with NTP, IGMP, and NETCONF to name a few. However, bringing such findings to the world of peer-reviewed academic journals and conferences as first author was another matter indeed. Perhaps with an assist of some bad luck, but most likely the inexperience to formulate a compelling narrative it took a few reworked submissions before this research work found a home. I’m pleased to report that our paper entitled “Plight at the End of the Tunnel: Legacy IPv6 Transition Mechanisms in the Wild” has recently been accepted for publication in the Passive and Active Measurement (PAM) Conference 2021, which is scheduled to appear around the end of the first quarter of 2021. This paper will include a more detailed discussion of the protocol 41 issue, as well as others, and some thoughts on mitigation strategies.
Approximately one year ago I started working with a small handful of trusted security organizations that could help perform the ongoing surveying and alerting of the protocol 41 issue. Then COVID-19 diverted everyone’s attention and priorities changed. Over the past few weeks I slowly began building and rolling out the necessary Internet surveying infrastructure and tooling to provide a protocol 41 feed through the DataPlane.org project. Internet surveying to produce the proto41 feed is currently made possible by the gracious support of friends at 20C and United IX who provided me with the surveying host and network infrastructure. With that, voila, DataPlane.org is now making the proto41 feed publicly available.
You may notice this feed looks slightly different than the existing feeds. Perhaps most notably is the use of a firstseen and lastseen time stamp. This is unique to this feed. Another difference, albeit minor, is that the IP address to ASN mapping is now being performed using pyasn with the help of a daily RouteViews MRT dump and RIPE’s ASN to AS name mapping file as described in the last blog post. I hope to convert all feeds to using this method of IP address to ASN mapping in the near future.
Also, and perhaps most importantly, surveying is slow, random and ongoing over the entire available IPv4 address space. It will normally take a few weeks to cover the entire IPv4 address space. I have no interest in setting Internet speed records to produce a fresh and complete feed every hour. I find this to be unnecessarily obnoxious. Furthermore, some network operators find that amount of noise both excessive and annoying. Consequently, that tends to lead to more complaints, which I prefer to avoid. I’ve done my share of Internet-wide network surveying since the 1990s and this less aggressive approach has served me well. That said, like other feeds, the feed reports on addresses seen in the past 7 days. This means that many addresses will cycle on and off the list as they are rediscovered over time and remain at risk. Therefore, consider the hourly feed published on the main page at present incomplete, covering only the past seven days of a longer full survey run. If you want to know what the entire state of all addresses I survey is you can reconstruct this yourself over time, or if you’re especially sweet to me, I might entertain an offer to produce something for you.