‹ Back
Deploy360 16 November 2016

[email protected], Day 4: SIDR, TLS & Even More IPv6

Kevin Meynell
By Kevin MeynellSenior Manager, Technical and Operational Engagement

seoul, south korea IETF 97Thursday at IETF 97 should prove to be interesting day with the Sunsetting IPv4 Working Group meeting again, along with IPv6, TLS and secure routing related sessions. Each day we’re bringing you blog posts pointing out what Deploy360 will be focusing on.

To kick off though, 6TiSCH is meeting at 09.30 KST (UTC+9) which is working on developing specifications for running IPv6 over the Time-Slotted Channel Hopping (TSCH) mode on IEEE 802.15.4 low-rate wireless personal area networks. There are a couple of interesting drafts related to the minimal security framework for 6TiSCH which describes the mechanism required to support secure initial configuration in a device being added to a 6TiSCH network, as well as the Secure Join protocol that defines a standard way of introducing new nodes into a 6tisch network that does not involve any direct manipulation of the nodes themselves.

NOTE: If you are unable to attend IETF 97 in person, there are multiple ways to participate remotely.

Following almost straight afterwards is the Sunsetting IPv4 Working Group starting at 11.10 KST (UTC+9). This will be discussing another new draft proposing that the IETF stops working on IPv4 except to address security issues or facilitate the transition to IPv6. As with the previous draft that proposed to move IPv4 to historic status, this one is probably unlikely to reach RFC status, but it’s sure to generate some interesting discussion.

In the afternoon, SIDR will be holding its session at 15.20 KST (UTC+9). This will mostly be focused on BGPSEC Router Certificate Profiles, along with Simplified Local Internet Number Resource Management with RPKI (SLURM) that provide ISPs with a way to make local assertions about private Internet Number Resources (INRs) while using RPKI assertions about all other INRs.

In parallel is the ACE meeting that has one TLS-related draft on the agenda. This defines a profile for delegating client authentication and authorisation by establishing a DTLS channel between resource-constrained nodes. This allows nodes to delegate management of authorisation information to a trusted host with limitations on processing power and memory.

For more background, please read the Rough Guide to IETF 97 from Olaf, Dan, Andrei, Mat, Karen and myself.

Relevant Working Groups:

‹ Back

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related articles

Improving Technical Security 15 March 2019

DNS Privacy Frequently Asked Questions (FAQ)

We previously posted about how the DNS does not inherently employ any mechanisms to provide confidentiality for DNS transactions,...

Improving Technical Security 14 March 2019

Introduction to DNS Privacy

Almost every time we use an Internet application, it starts with a DNS (Domain Name System) transaction to map...

Improving Technical Security 13 March 2019

IPv6 Security for IPv4 Engineers

It is often argued that IPv4 practices should be forgotten when deploying IPv6, as after all IPv6 is a...

Join the conversation with Internet Society members around the world