‹ Back
Deploy360 21 July 2016

Deploy360@IETF 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

BGPSec - A reality now
BGPSec - A reality now
Deploy36016 October 2017

BGPSec – A reality now

The Secure Inter Domain Routing (SIDR) initiative held its first BoF at IETF 64 back in November 2005, and was...

ISOC Rough Guide to IETF 93: Routing Resilience
ISOC Rough Guide to IETF 93: Routing Resilience
IETF14 July 2015

ISOC Rough Guide to IETF 93: Routing Resilience

There is considerable work underway across several IETF working groups to ensure the Internet's routing infrastructure is more secure and...

Rough Guide to IETF 92: Routing Resilience and Security
Rough Guide to IETF 92: Routing Resilience and Security
IETF16 March 2015

Rough Guide to IETF 92: Routing Resilience and Security

There is considerable work underway across a number of IETF working groups to ensure the Internet's routing infrastructure is more...

Join the conversation with Internet Society members around the world