I’d like to look in a little more detail at the efforts to hide the DNS behind HTTPS, and put the work in the IETF's DOH Working Group into a broader perspective. There are a number of possible approaches here, and they can be classified according to the level of interaction between the DNS application and the underlying HTTPS encrypted session.
It took some hundreds of years, but Europe eventually reacted to the introduction of gunpowder and artillery by recognising that they simply could not build castles large enough to defend against any conceivable attack. So they stopped. I hope it does not take us the same amount of time to understand that building ever more massively fortified and over-provisioned DNS servers is simply a tactic for today, not a strategy for tomorrow.
RIPE held its 75th meeting in Dubai in mid-October. As usual there was a diverse set of presentations covering a broad range of activities that are taking place on today’s Internet. The topics include issues relating to network operations, regulatory policies, peering and interconnection, communications practices within data centres, IPv6, the DNS, routing and network measurement. If that's not enough, the topic of the Internet of Things has been added as a Working Group in the RIPE pantheon. If you add address policy, database and RIPE services to the mix you get a pretty packed five days with topics that would appeal to most Internet folk
RIPE held its 75th meeting in Dubai in mid-October. As usual there was a diverse set of presentations covering a broad range of activities that are taking place on today’s Internet. The topics include issues relating to network operations, regulatory policies, peering and interconnection, communications practices within data centres, IPv6, the DNS, routing and network measurement. If that's not enough, the topic of the Internet of Things has been added as a Working Group in the RIPE pantheon. If you add address policy, database and RIPE services to the mix you get a pretty packed five days with topics that would appeal to most Internet folk
Unlike IPv4, IPv6 does not provide a raw socket interface to the IP protocol engine. TGhis rticle describes how to get around this limitation and shows how to build an IPv6 raw socket.
The DNS OARC meetings are an instance of a meeting that concentrates on the single topic of the DNS, and in this case it delves as deep as anyone is prepared to go! It's two days where too much DNS is barely enough!
Until a few days ago the intention was to roll the KSK of the root zone of the DNS on the 11th October, altering the root to trust used by DNSSEC for all DNSSEC-validating DNS resolvers. However, earlier this week, ICANN announced the postponement of this key roll.
It would be useful to understand the larger picture of IPv6 Extension Header drop rate. What would be interesting to measure is the packet drop rate when sending fragmented packets to IPv6 end hosts.
Network Address Translation has often been described as an unfortunate aberration in the evolution of the Internet, and one that will be expunged with the completion of the transition of IPv6. I think that this view, which appears to form part of today’s conventional wisdom about the Internet unnecessarily vilifies NATs. In my opinion, NATs are far from being an aberration, and instead I see them as an informative step in the evolution of the Internet, particularly as they relate to possibilities in the evolution of name-based networking. Here’s why.
It appears that rather than effecting a slight improvement from IPv4, the manner of fragmentation handling in IPv6 appears to be significantly worse than IPv4. Little wonder that there have been calls from time to time to completely dispense with packet fragmentation in IPv6, as the current situation with IPv6 appears to be worse than either no fragmentation or the IPv4-style of fragmentation.
After pulling out the notes from the IEPG meeting and aspects of the DNS, here are the rest of the items that I personally found to be of interest at IETF 99 last week.
Interest in the DNS appears to come in pronounced surges. Its quiet for a few years, then there is a furious burst of activity. If the activity at the recent IETF meeting is any indication, we appear to be in the middle of a burst of activity.
Many years ago the IEPG had a role in allowing network operators to talk to other operators about what they were seeing and what they were thinking about. Those days are long since over, and today the IEPG meetings present an opportunity for an eclectic set of diehards to listen to an equally eclectic collection of presentations that wander over much of the topics of today's Internet, without any particular common theme or filter.
The number of more specific advertisements in the IPv4 Internet is more than 50% of all advertisements, and the comparable picture in IPv6 has more specific advertisements approaching 40% of all network advertisements. It is tempting to label this use of more specifics as part of the trashing of the Internet commons. Individual networks optimise their position by large scale advertising of more specifics, which in turn, creates an incremental cost on all other networks in terms of increased BGP table size and increased overhead of processing BGP updates. The question I’d like to look at here is whether these more specific advertisements represent a significant imposition on everyone else, or whether they are simply unavoidable.
RIPE 74 was held in May in Budapest, and as usual it was a meeting that mixed a diverse set of conversations and topics into a very busy week. Here are my impressions of the meeting drawn from a number of presentations that I found to be of personal interest.
TCP is the workhorse of the Internet Protocol suite. It's the protocol that tries to take a unreliable datagram service and transform it into a reliable data stream. But that's not all. We also want it to operate efficiently over all types of network paths from bits to gigabits per second. Google has recently announced a new form of TCP control algorithm, called BBR, and in this article I'll take a closer look at BBR and what it is trying to achieve.
The IETF meetings are relatively packed events lasting over a week, and it’s just not possible to attend every session. Inevitably each attendee follows their own interests and participates in Working Group sessions that are relevant and interesting to them. I do much the same when I attend IETF meetings. The IETF met for IETF 98 in Chicago at the end of March, and from the various sessions I attended here are a few personal impressions that I would like to share.
Having just spent two and a half days at an ARIN Public Policy Meeting, I’d like to share some of my impressions of the meeting, and the state of address policy in the region served by ARIN.