‹ Back
Deploy360 21 July 2016

[email protected] 96, Day 4: SIDR & IPv6

Kevin Meynell
By Kevin MeynellSenior Manager, Technical and Operational Engagement

berlinThroughout this week at IETF 96 in Berlin we’re bringing you these daily blog posts that highlight what Deploy360 is focused on during that day. And Thursday is an important day as two of our key technologies will be covered in the Secure Inter-Domain Routing (SIDR) and IPv6 Operations (v6ops) Working Groups.


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


SIDR holds its session in the morning and will focus on RPKI which adds an authentication framework to BGP and forms an important component of BGPsec for improving trust in the global routing infrastructure.

While RPKI and BGPsec aim to make routing more secure, one of the concerns is mistakes related to “over-claiming” of resources at higher levels of RPKI hierarchy. The draft draft-ietf-sidr-rpki-validation-reconsidered-03 tries to address this by proposing changes to the validation process, whilst the draft draft-lee-sidr-rpki-deployment-02 outlines and provides an analysis of some of the problems that have appeared during the process of RPKI deployment, along with suggesting some solutions to address or mitigate these.

Another draft draft-ietf-sidr-delta-protocol-03 introduces a mechanism whereby Relying Parties can query repositories for incremental updates to certificates, Certificate Revocation Lists (CRLs) and RPKI signed objects. The aim is to provide more efficient synchronization, whilst draft draft-madi-sidr-rp-00 outlines requirements for these Relying Parties.

Also of interest should be the presentation of Tim Bruijnzeels on RPKI and BGP statistics, and of Ruediger Volk on RPKI findings and observations.

During the afternoon, V6OPS will hold its session and will be discussing three drafts. The draft draft-ietf-v6ops-unique-ipv6-prefix-per-host-01 proposes to allow hosts to be assigned a unique IPv6 prefix (typically a /64) in circumstances where a network is shared and a common prefix may not be desirable (e.g. in community wireless applications). This would provide each subscriber with more flexibility to utilise IPv6, whilst ensuring traffic can be directed to a default wireless LAN gateway.

The draft draft-anderson-v6ops-v4v6-xlat-prefix-01 is more straightforward in that it proposes to reserve the IPv6 prefix 64::/16 for use with IPv4/IPv6 translation mechanisms. This would extend the IPv6 prefix 64:ff9b::/96 as specified in RFC 6052.

Last but not least is the draft draft-bowbakova-rtgwg-enterprise-pa-multihoming-00 that attempts to define a solution for connecting  enterprise sites to multiple ISPs using provider-assigned addresses avoiding the use of Network Address Translation (NAT).

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