‹ Back
Deploy360 18 July 2016

[email protected], Day 2: IPv6 & TLS

Kevin Meynell
By Kevin MeynellSenior Manager, Technical and Operational Engagement

berlinAfter a busy first day for the Deploy360 team at IETF 96 in Berlin, Tuesday is primarily devoted to IPv6 and TLS. Throughout this week at IETF 96 we’ll be bringing you these daily blog posts that point out what we are focused on during that day.

There’s a clash between IPv6 Maintenance (6man) and Transport Layer Security (tls) Working Groups on Tuesday morning at 10.00 CEST (UTC+), so we’ll be splitting our efforts between those. Then in the afternoon we’ll be heading to the Using TLS in Applications Working Group (uta).

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

6MAN will be discussing a tranche of drafts dealing with updates to the IPv6 specification, addressing architecture and path MTU discovery as currently defined in RFC 2460, RFC 4291 and RFC 1981. There’s also a last call on the draft recommendation draft-ietf-6man-default-iids to change the default interface identifier (IID) generation scheme where SLAAC is used to generate a stable IPv6 address. Along similar lines is another draft on generating non-stable addresses draft-gont-6man-non-stable-iids-00 that are not predictable for security reasons, whilst further two drafts draft-carpenter-6man-whats-global-00 and draft-bchv-rfc6890bis-00 aim to clarify the unclear use of ‘global’ in the context of IANA special purpose IPv6 address registries. Last but not least, there’s a new draft dealing with the issue of multihoming using provider-assigned addresses without using network prefix translation.

TLS continues to work on an update to the TLS protocol. This is a very active working group with a plan to publish an update to TLS in 2016, so this meeting will be devoted to resolving the open issues with the current specification as documented in the issue tracker. There will also be discussions on AES-OCM, TLS Client Puzzles, and TLS Blocking alerts if there is time remaining in the session.

UTA is building on this work to get TLS support incorporated into existing applications, and the working group will be focusing on support for TLS in SMTP during its meeting on Tuesday afternoon.

For more background, please read the Rough Guide to IETF 96 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