You are here: Home > Publications > RIPE Labs > Mirjam Kühne > IETF 98 - Some Impressions - Day 0
Content by this author

IETF 98 - Some Impressions - Day 0

Mirjam Kühne — 27 Mar 2017
I am at the IETF 98 in Chicago and I am planning to do a bit of blogging during the week, sharing highlights from my own very personal perspective.

Please also see my IETF 98 updates from Monday, Wednesday and Friday.

I arrived in Chicago on Saturday evening to participate in the IETF 98 meeting. It hasn’t stopped raining since I got here. Only the bottom half of the city is visible, most skyscrapers have disappeared in the clouds. Luckily I will be stuck in meeting rooms for the rest of the week.

Chicago in the mist

 

The IEPG: operators meet at the IETF

Sunday morning has traditionally been reserved for the IEPG meeting where operators come together and update each other on the latest developments. IEPG originally stands for Internet Engineering Planning Group, but the scope has shifted slightly over the years.

The meeting was kicked off by Giovane Moura who has also been a RIPE Labs contributor in the past. Giovane and his colleagues did a study to find out "if Let's Encrypt is democratising encryption". They concluded that the project is indeed a success story: it reduces costs and complexity and therefore helps to democratise encryption. You can find the full study in this paper. There is still some future work to do, for instance extending the measurement period. The group would also like to measure the use by malicious actors.

Ondřej Surý from CZ.NIC presented what he called "The DNS Horror Show". Together with his colleagues he compiled a pretty long list of DNS protocol violations. With that, he wants to make the DNS better, share knowledge and help others to avoid common pitfalls and mistakes. Ondrej said that it might be time for more drastic action: we should remove the workarounds and stop resolving the most blatant DNS violations. "Standards are standards and need to be followed." But on the other hand, the DNS community needs to be inclusive and explain to people what they are doing wrong. You can find more on the DNS violation pages on github. There is also a mailing list.

Next Geoff Huston presented his study on "Routing in 2016". You can find the whole paper and many interesting graphs in this RIPE Labs article. Growth in IPv4 is pretty consistent. People seem to be relying on NATs however. Geoff predicts that we might be getting to a million BGP table entries in 2023 if the NATs hold up. Growth in IPv6 is still there, but in relative terms it is slowing down. Predictions, however, are really hard. Bottom-line: as long as silicon keeps increasing, there won't be a routing table crisis. However, the number of unstable routing table entries (announcements and withdrawals) are surprisingly stable over the last ten years. That also means that convergence performance in IPv4 has not changed during that time (it is about 50 seconds). This is completely different in IPv6: the noise level there is amazing.

Last, but not least, Job Snijders brought up the issue of interface prefix length and routing. As an operator, Job is very firm on the view that operations realities in BGP and at the Internet Exchange Point demand that BGP speakers are free to use any prefix length they need (subject to the normal constraints in the operational community). However, quite a few people in the IETF feel that there are more proscriptive limits on what can be done, and that the interface prefix length is bound to a /64, to a /127, and sometimes (depending on which draft and RFC and BCP you read) either. The core issue relates to the overwhelming majority of devices which assume a /64 for SLAAC, which is different to the flexibility operational deployment managers feel they need (e.g. to limit neighbour discovery exhaustion). The real discussion is taking place on the lists of both operators groups and the relevant IETF WG, and we can expect more fireworks for some time.

Sunday Tutorials

I have chaired the Edu Team that organises a series of tutorials at every IETF meeting for more than ten years. It started with a tutorial for IETF newcomers. Later the scope was expanded to "whatever enables IETF participants to make good protocols". This time we offered four tutorials:

In addition to these tutorials, there are also a number of activities targeted towards IETF newcomers. This time I participated in the speed mentoring which was great fun. You get to talk to many newcomers coming to the IETF from all over the world and with various backgrounds. I spoke to people from Nepal, India, Australia and Brazil who were interested in topics such as security, routing, mail and censorship.

Unfortunately I only had the chance to attend one of the tutorials this afternoon: QUIC. It was an excellent presentation covering the history of the QUIC protocol, the problem statement and the current work of the IETF QUIC Working Group. There was a lot of interest and the room was packed.

1 Comment

Stéphane Bortzmeyer says:
27 Mar, 2017 05:38 PM
Sunday was also the second day of the IETF hackathon, which started on Saturday. Two days of hacking, fourteen teams, something like fifty or sixty people locked in a room, with a lot of coffee and good meals appearing from time to time, thanks to the sponsors. During the hackathon, people were able to develop recent IETF techniques, sometimes published in RFC, sometimes still at the draft stage, where actual implementation experience helps a lot to sort out the good ideas from the bad.

For instance, the WebRTC people were working on end-to-end encryption of the media (a touchy subject, for sure, after the recent anti-encryption stances of the british authorities), DNS people developed various stuff about DNS-over-TLS, TLS people were of course busy implementing the future TLS 1.3 (even in a Haskell library), CAPPORT people programmed their solution to make evil captive portals more network-(and user)-friendly, LoRaWAN people started to write a Wireshark dissector for this IoT protocol, etc.

That was my first hackathon and I appreciated the freedom (you can hack on what you want but is is of course more fun if you do it with other people), and the efficiency (no distractions, just coding and discussions between developpers). Doing a bug report to a library developer by shouting over the table is certainly faster than filing it in Gitlab :-)
Add comment

You can add a comment by filling out the form below. Comments are moderated so they won't appear immediately. If you have a RIPE NCC Access account, we would like you to log in.