Categories
Deploy360 Events IETF Improving Technical Security IPv6

Deploy360@IETF 96, Day 4: SIDR & IPv6

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: