<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>RIPE on Insinuator.net - Bold Statements</title>
    <link>https://insinuator.net/tags/ripe/</link>
    <description>Recent content in RIPE on Insinuator.net - Bold Statements</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Sun, 26 May 2019 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://insinuator.net/tags/ripe/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>The Week in Review #RIPE78</title>
      <link>https://insinuator.net/2019/05/the-week-in-review-%23ripe78/</link>
      <pubDate>Sun, 26 May 2019 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2019/05/the-week-in-review-%23ripe78/</guid>
      <description>&lt;p&gt;This week &lt;a href=&#34;https://twitter.com/bcp38_&#34;&gt;Chris&lt;/a&gt; and I participated in the RIPE 78 meeting in Reykjavík. Being part of the group was fun as always and we had quite some interesting conversations with peers from (not only) the IPv6 community.&lt;br&gt;&#xA;Big thanks to the &lt;a href=&#34;https://twitter.com/RIPE_NCC&#34;&gt;RIPE NCC&lt;/a&gt; team for the smooth organization and for taking care of us!&lt;/p&gt;&#xA;&lt;p&gt;In this post I’ll provide some notes on talks I found particularly interesting, plus links to our own contributions.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Security for Enterprise Organisations @ #RIPE78</title>
      <link>https://insinuator.net/2019/05/ipv6-security-for-enterprise-organisations-@-%23ripe78/</link>
      <pubDate>Fri, 17 May 2019 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2019/05/ipv6-security-for-enterprise-organisations-@-%23ripe78/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;https://twitter.com/bcp38_&#34;&gt;Chris&lt;/a&gt; and I will give a tutorial on the above topic at &lt;a href=&#34;https://ripe78.ripe.net/&#34;&gt;next week’s RIPE Meeting&lt;/a&gt; in Reykjavík. In this post (actually this will probably become a small series of posts) I’ll try to summarize some thoughts on IPv6 security in enterprise environments in 2019.&lt;/p&gt;&#xA;&lt;p&gt;We’re going to cover three main areas:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;Why IPv6 Is Different, Security-wise&lt;/li&gt;&#xA;&lt;li&gt;Traffic Filtering in IPv6 Networks&lt;/li&gt;&#xA;&lt;li&gt;IPv6 Security in L2 Networks / First Hop Security et al.&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;Let’s start with the first item. In real-life scenarios the security of “a protocol” – IPv6 can rather be considered a “protocol family” which includes helper protocols like ICMPv6 and MLD (which in turn is implemented by means of ICMPv6 messages) and potentially others like DHCPv6 – might depend on a number of factors:&lt;/p&gt;</description>
    </item>
    <item>
      <title>RIPE IoT Roundtable Meeting / Balanced Security for IPv6 CPE Revisited</title>
      <link>https://insinuator.net/2017/09/ripe-iot-roundtable-meeting-/-balanced-security-for-ipv6-cpe-revisited/</link>
      <pubDate>Fri, 29 Sep 2017 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2017/09/ripe-iot-roundtable-meeting-/-balanced-security-for-ipv6-cpe-revisited/</guid>
      <description>&lt;p&gt;Last week I had the pleasure to participate at the first &lt;a href=&#34;https://www.ripe.net/participate/meetings/roundtable/september-2017/ripe-iot-roundtable-meeting-21-september-2017&#34;&gt;&lt;em&gt;RIPE IoT Roundtable Meeting&lt;/em&gt;&lt;/a&gt; in Leeds (thanks! to &lt;a href=&#34;https://www.ripe.net/about-us/press-centre/publications/speakers/marco-hogewoning&#34;&gt;Marco Hogewoning&lt;/a&gt; for organising it). It was a day with many fruitful discussions. I particularly enjoyed &lt;a href=&#34;https://twitter.com/kistel&#34;&gt;Robert Kisteleki&lt;/a&gt;‘s talk on RIPE NCC’s own design &amp;amp; (security) process considerations in the context of &lt;a href=&#34;https://atlas.ripe.net/&#34;&gt;RIPE Atlas&lt;/a&gt; (at TR17 NGI there was an &lt;a href=&#34;https://www.troopers.de/downloads/troopers17/TR17_RIPEatlas.pdf&#34;&gt;intro to Atlas&lt;/a&gt;, too).&lt;br&gt;&#xA;In this post I’d like to quickly lay out the main points of my own contribution on “Balanced Security for IPv6 CPE Revisited” (the slides can be found &lt;a href=&#34;https://www.ernw.de/download/RIPE_IoT_Roundtable_Sep2017_EnnoRey_BalancedIPv6Sec.pdf&#34;&gt;here&lt;/a&gt;).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Looking back on RIPE 74</title>
      <link>https://insinuator.net/2017/05/looking-back-on-ripe-74/</link>
      <pubDate>Fri, 19 May 2017 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2017/05/looking-back-on-ripe-74/</guid>
      <description>&lt;p&gt;From May 8th to 12th I was able to attend the 74th RIPE meeting in Budapest, Hungary. Being rather new to the networking community, I enjoyed learning a lot of different things, not only from the various interesting talks but also from inspiring conversations with a variety of people from all areas during the beautiful social events.&lt;/p&gt;&#xA;&lt;p&gt;As it was the first RIPE meeting for me, I was very thankful for the “Newcomer’s Introduction” on Monday morning, containing a RIPE and RIPE NCC 101. It was quite helpful to get into the mindset and understand the structure of the meeting, like the division into different working groups based on the participants’ interests. After familiarizing myself with the concept, I chose to attend several sessions on Address Policy, IPv6, Routing, Open Source, and DNS working groups besides the general plenary sessions. I’ll be reviewing those sessions here.&lt;/p&gt;</description>
    </item>
    <item>
      <title>RIPE74 / Why IPv6 Security Is So Hard</title>
      <link>https://insinuator.net/2017/05/ripe74-/-why-ipv6-security-is-so-hard/</link>
      <pubDate>Fri, 12 May 2017 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2017/05/ripe74-/-why-ipv6-security-is-so-hard/</guid>
      <description>&lt;p&gt;I’m on my way back from the &lt;a href=&#34;https://ripe74.ripe.net/&#34;&gt;RIPE74 meeting in Budapest&lt;/a&gt;. It was a great event: quite a few nice technical talks in the plenary, productive working group meetings and some really good hallway discussions.&lt;br&gt;&#xA;Big thanks to the RIPE NCC team for the smooth organization and for taking care of us!&lt;/p&gt;&#xA;&lt;p&gt;Here’s some stuff I found particularly interesting:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;Andrew Alston’s take on “Anti-Shutdown Policies” (&lt;a href=&#34;https://ripe74.ripe.net/presentations/34-anti-shutdown-ripe.pdf&#34;&gt;slides&lt;/a&gt; and &lt;a href=&#34;https://ripe74.ripe.net/archives/video/41/&#34;&gt;video&lt;/a&gt; incl. extensive mic discussion)&lt;/li&gt;&#xA;&lt;li&gt;&lt;a href=&#34;https://twitter.com/pberndro&#34;&gt;Philip&lt;/a&gt; &amp;amp; &lt;a href=&#34;https://twitter.com/BarbarossaTM&#34;&gt;Maximilian&lt;/a&gt; from &lt;a href=&#34;https://www.freifunk-rheinland.net/&#34;&gt;Freifunk Rheinland&lt;/a&gt; on their efforts (&lt;a href=&#34;https://ripe74.ripe.net/presentations/46-as201701-ripe74.pdf&#34;&gt;slides&lt;/a&gt;, &lt;a href=&#34;https://ripe74.ripe.net/archives/video/47/&#34;&gt;video&lt;/a&gt;)&lt;/li&gt;&#xA;&lt;li&gt;Friso Feenstra on “That’s Why Rabobank Implemented IPv6” (&lt;a href=&#34;https://ripe74.ripe.net/presentations/3-That-is-why-Rabobank-has-IPv6.pdf&#34;&gt;slides&lt;/a&gt;, video) plus some insight into their address planning (&lt;a href=&#34;https://ripe74.ripe.net/presentations/4-Rabobank-corporate-IPv6-numberplan.pdf&#34;&gt;slides&lt;/a&gt;, &lt;a href=&#34;https://ripe74.ripe.net/archives/video/101/&#34;&gt;video&lt;/a&gt;)&lt;/li&gt;&#xA;&lt;li&gt;BCOP work on “&lt;a href=&#34;https://ripe74.ripe.net/presentations/132-Jan_Zorz-IPv6-prefix-delegations-BCOP-v-2.pdf&#34;&gt;IPv6 Prefix Assignments/Prefix Delegation&lt;/a&gt;” and “&lt;a href=&#34;https://ripe74.ripe.net/presentations/40-jan_zorz_IPv6-for-hosting-providers.pdf&#34;&gt;IPv6 Assignments for Hosting Providers&lt;/a&gt;“&lt;/li&gt;&#xA;&lt;li&gt;&lt;a href=&#34;https://twitter.com/lundstromjerry&#34;&gt;Jerry Lundström&lt;/a&gt;‘s DNS Replay Tool (&lt;a href=&#34;https://ripe74.ripe.net/presentations/79-RIPE74-DNSWG-drool.pdf&#34;&gt;slides&lt;/a&gt;, &lt;a href=&#34;https://ripe74.ripe.net/archives/video/161/&#34;&gt;video&lt;/a&gt;, &lt;a href=&#34;https://github.com/DNS-OARC/drool&#34;&gt;code&lt;/a&gt;)&lt;/li&gt;&#xA;&lt;li&gt;Jan Žorž (supported by Sander Steffann) on NAT64 testing (&lt;a href=&#34;https://ripe74.ripe.net/presentations/133-Jan_Zorz-NAT64-Check-v3.4.pdf&#34;&gt;slides&lt;/a&gt;, &lt;a href=&#34;https://ripe74.ripe.net/archives/video/160/&#34;&gt;video&lt;/a&gt;, &lt;a href=&#34;https://github.com/sjm-steffann/nat64check&#34;&gt;code&lt;/a&gt;)&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;These were my own contributions:&lt;/p&gt;</description>
    </item>
    <item>
      <title>The Beauty of IPv6 Link-Local Addressing. Not</title>
      <link>https://insinuator.net/2016/05/the-beauty-of-ipv6-link-local-addressing.-not/</link>
      <pubDate>Sat, 28 May 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/05/the-beauty-of-ipv6-link-local-addressing.-not/</guid>
      <description>&lt;p&gt;In November 2014, after quite some controversy in the IETF OPSEC working group (for those interested look at the &lt;a href=&#34;http://www.ietf.org/mail-archive/web/opsec/current/maillist.html&#34;&gt;archives&lt;/a&gt;), the &lt;em&gt;Informational&lt;/em&gt; &lt;a href=&#34;https://tools.ietf.org/rfc/rfc7404.txt&#34;&gt;RFC 7404&lt;/a&gt; “Using Only Link-Local Addressing inside an IPv6 Network” was published. It is authored by &lt;a href=&#34;http://blogs.cisco.com/author/michaelbehringer&#34;&gt;Michael Behringer&lt;/a&gt; and &lt;a href=&#34;https://twitter.com/evyncke&#34;&gt;Eric Vyncke&lt;/a&gt; and discusses the advantages &amp;amp; disadvantages of an approach using “only link-local addresses on infrastructure links between routers”.&lt;/p&gt;&#xA;&lt;p&gt;So it’s (merely) about “infrastructure links” which some people call “transit networks” or “point to point” (ptp) links. I’m aware that there might be subtle differences between all these, depending on your specific use of the terms. Still I assume that most readers will have an understanding of what types of links are in focus of the RFC, and subsequently of this post.&lt;/p&gt;</description>
    </item>
    <item>
      <title>RIPE70 in Amsterdam</title>
      <link>https://insinuator.net/2015/05/ripe70-in-amsterdam/</link>
      <pubDate>Sun, 24 May 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/05/ripe70-in-amsterdam/</guid>
      <description>&lt;p&gt;Two weeks ago Christopher and I joined the RIPE70 meeting in Amsterdam. Being part of the group was fun as always and we had quite some interesting conversations with peers from the IPv6 community.&lt;/p&gt;&#xA;&lt;p&gt;We could even contribute a bit to some discussions, with two talks. I gave one titled “Will It Be Routed? – On IPv6 Address Space Allocation &amp;amp; Assignment Approaches in Very Large Organizations” in the Address Policy Working Group session on Wednesday. This is the abstract:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Deaggregation by large organizations</title>
      <link>https://insinuator.net/2014/10/deaggregation-by-large-organizations/</link>
      <pubDate>Wed, 15 Oct 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/10/deaggregation-by-large-organizations/</guid>
      <description>&lt;p&gt;Some hours ago &lt;a href=&#34;https://twitter.com/iljitsch&#34;&gt;Iljitsch van Beijnum&lt;/a&gt; posted &lt;a href=&#34;https://www.ripe.net/ripe/mail/archives/bcop/2014-October/000079.html&#34;&gt;an email&lt;/a&gt; with the above subject to the RIPE Best Current Operational Practices (BCOP) &lt;a href=&#34;https://www.ripe.net/mailman/listinfo/bcop&#34;&gt;mailing list&lt;/a&gt;.&lt;br&gt;&#xA;Therein he describes the growing issue of (IPv6 prefix) deaggregation desires/approaches by certain organizations vs. the filtering practices of other organizations (providers). I touched this problem, from an enterprise’s perspective, some time ago in the &lt;a href=&#34;http://www.insinuator.net/2014/01/ipv6-address-plan-considerations-part-2-the-pi-space-from-singlemultiple-rirs-debate/&#34;&gt;second part&lt;/a&gt; of my blog post series on &lt;a href=&#34;http://www.insinuator.net/2014/05/ipv6-address-plan-considerations-part-3-the-plan/&#34;&gt;IPv6 address planning&lt;/a&gt;. Given we think that the discussion is heavily needed from several angles, I had actually submitted a talk on the topic twice (for the RIPE meeting in Warsaw in May and the upcoming one in London) which was unfortunately rejected at both occasions.&lt;br&gt;&#xA;I’m hence very happy to see that a dialogue about the inherent dilemma might be started by Iljitsch’s mail. As a contribution to the development of a BCOP document I will hereby publish our &lt;a href=&#34;https://www.ernw.de/download/RIPE69_Rey_Langner_Slash48_Considered_Harmful_v082_DRAFT.pdf&#34;&gt;draft slides&lt;/a&gt; of the talk which was initially planned. Furthermore two fellow IPv6 practitioners (Hi Roland &amp;amp; Nico!) and I plan to release a detailed paper with research results as for IPv6 prefix distribution at major European IXs in the near future.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
