<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>DHCPv6 on Insinuator.net - Bold Statements</title>
    <link>https://insinuator.net/tags/dhcpv6/</link>
    <description>Recent content in DHCPv6 on Insinuator.net - Bold Statements</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Sat, 06 Feb 2016 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://insinuator.net/tags/dhcpv6/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>DHCPv6 Option 52 on Cisco DHCPv6 Server</title>
      <link>https://insinuator.net/2016/02/dhcpv6-option-52-on-cisco-dhcpv6-server/</link>
      <pubDate>Sat, 06 Feb 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/02/dhcpv6-option-52-on-cisco-dhcpv6-server/</guid>
      <description>&lt;p&gt;Hi,&lt;/p&gt;&#xA;&lt;p&gt;I am currently preparing the &lt;a href=&#34;https://www.troopers.de&#34;&gt;Troopers&lt;/a&gt; network in a lab environment to ensure that we all will have a smooth Wi-Fi experience during Troopers. I wanted to spice things up a little bit for the Wi-Fi deployment (more on that in a following blogpost) and get rid of IPv4 wherever possible. Our Wi-Fi infrastructure consists of typical Cisco Access Points (1602) and a 2504 Wireless LAN Controller. Beginning with WLC image 8.0 it is finally supported to establish the CAPWAP tunnel between the AP and the WLC over IPv6, which is awesome and I wanted to implement it right away.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Router Advertisement Flags, RDNSS and DHCPv6 Conflicting Configurations</title>
      <link>https://insinuator.net/2015/03/ipv6-router-advertisement-flags-rdnss-and-dhcpv6-conflicting-configurations/</link>
      <pubDate>Mon, 09 Mar 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/03/ipv6-router-advertisement-flags-rdnss-and-dhcpv6-conflicting-configurations/</guid>
      <description>&lt;p&gt;We’ve just released a whitepaper discussing the behavior of different operating systems once they receive IPv6 configuration parameters from different sources. For that purpose a number of lab tests were conducted.&lt;/p&gt;&#xA;&lt;p&gt;In short, it’s a mess. Again, &lt;a href=&#34;http://queue.acm.org/detail.cfm?id=1999945&#34;&gt;RFC ambiguity&lt;/a&gt; and/or (perceived) vendor implementation freedom suck big time. For us practitioners out (t)here this means (once more) we need extensive test labs and good troubleshooting guides for large scale IPv6 deployments.&lt;/p&gt;&#xA;&lt;p&gt;The detailed results can be found &lt;a href=&#34;https://www.ernw.de/download/ERNW_Whitepaper_IPv6_RAs_RDNSS_DHCPv6_Conflicting_Parameters.pdf&#34;&gt;in this paper&lt;/a&gt;. We hope to contribute to a better understanding of IPv6 specifics. I mean, &lt;a href=&#34;https://www.ernw.de/download/ERNW_IPv6_Today_Tomorrow.pdf&#34;&gt;after all it’s here already&lt;/a&gt;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Is RFC 6939 Support Finally Here – Checking the Implementation of the “Client Link Layer Address Option” in DHCPv6</title>
      <link>https://insinuator.net/2015/02/is-rfc-6939-support-finally-here-checking-the-implementation-of-the-client-link-layer-address-option-in-dhcpv6/</link>
      <pubDate>Wed, 04 Feb 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/02/is-rfc-6939-support-finally-here-checking-the-implementation-of-the-client-link-layer-address-option-in-dhcpv6/</guid>
      <description>&lt;p&gt;One of the main DHCPv6 enhancements – fyi: we have already discussed DHCPv6 &lt;a href=&#34;http://www.insinuator.net/tag/dhcpv6/&#34;&gt;in some other posts&lt;/a&gt; – many practitioners have been waiting for quite some time now, is full support of &lt;a href=&#34;https://tools.ietf.org/rfc/rfc6939.txt&#34;&gt;RFC 6939&lt;/a&gt; (Client Link-Layer Address Option in DHCPv6) by network devices (acting as relays) and DHCPv6 servers. RFC 6939 support would allow a number of things which large organizations use in their DHCPv4 based networks, incl.&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;reservations (assigning a kind-of fixed DHCP address based on the MAC address of a system which in turn allows for “centralized administration of somewhat static addresses”).&lt;/li&gt;&#xA;&lt;li&gt;correlation of IPv4 and IPv6 addresses of a given host identified by its MAC address.&lt;/li&gt;&#xA;&lt;li&gt;(some type) of security enforcement based on the MAC address of a host gathered in the course of a DHCP exchange (see for example slide #29 of &lt;a href=&#34;https://ripe68.ripe.net/presentations/294-cern-ipv6-deployment.pdf&#34;&gt;this presentation of the IPv6 deployment at CERN&lt;/a&gt;, btw: slide #9 might be helpful when discussing IPv6 transition plans with your CIO. or not).&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;So far it seemed very few components support RFC 6939. When &lt;a href=&#34;https://twitter.com/bckcntryskr&#34;&gt;Tim Martin&lt;/a&gt; mentioned at Cisco Live that Cisco devices running IOS XE support it by default, we decided go to the lab ;-).&lt;/p&gt;</description>
    </item>
    <item>
      <title>DHCPv6 Guard: Do It Like RA Guard Evasion</title>
      <link>https://insinuator.net/2015/01/dhcpv6-guard-do-it-like-ra-guard-evasion/</link>
      <pubDate>Thu, 08 Jan 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/01/dhcpv6-guard-do-it-like-ra-guard-evasion/</guid>
      <description>&lt;p&gt;&lt;strong&gt;Or: When Cisco ACL Can Count Up to Five 🙂&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;This is a guest post by &lt;a href=&#34;https://twitter.com/AntoniosAtlasis&#34;&gt;Antonios Atlasis&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Hi all,&lt;/p&gt;&#xA;&lt;p&gt;RA Guard Evasion is well-known in the IPv6 “circles”; there is &lt;a href=&#34;https://tools.ietf.org/rfc/rfc7113.txt&#34;&gt;RFC 7113&lt;/a&gt; Advice for IPv6 Router Advertisement Guard (RA-Guard) and many interesting blog-posts like this one &lt;a href=&#34;http://www.insinuator.net/2011/03/ipv6-security-part-2-ra-guard-%E2%80%93-lets-get-practical/&#34;&gt;here&lt;/a&gt;, &lt;a href=&#34;http://www.insinuator.net/2012/03/the-story-continues-another-ipv6-update/&#34;&gt;here&lt;/a&gt;, and this excellent write-up &lt;a href=&#34;http://6lab.cz/article/rogue-router-advertisement-attack/&#34;&gt;here&lt;/a&gt; that discuss this issue.&lt;br&gt;&#xA;Moreover, as Jim Smalls states in his comprehensive “&lt;a href=&#34;http://www.rmv6tf.org/wp-content/uploads/2013/04/5-IPv6-Attacks-and-Countermeasures-v1.2.pdf&#34;&gt;IPv6 Attacks and Countermeasures&lt;/a&gt;” presentation given at the &lt;a href=&#34;http://www.rmv6tf.org/na-ipv6-summit/2013-na-ipv6-summit/2013-presentations&#34;&gt;North American IPv6 Summit 2013&lt;/a&gt;, DHCPv6 Guard or a corresponding IPv6 ACL can stop a DHCPv6 Rogue Servers, but (only?) for non-malicious/non-fragmented DHCPv6 packets (slide 35). However, at that time there wasn’t any known attack tool in the wild that had the fragmentation evasion built in.&lt;/p&gt;</description>
    </item>
    <item>
      <title>I Don’t Have Any Neighbors – A Deep Dive into DHCPv6, Part 1</title>
      <link>https://insinuator.net/2014/10/i-dont-have-any-neighbors-a-deep-dive-into-dhcpv6-part-1/</link>
      <pubDate>Fri, 31 Oct 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/10/i-dont-have-any-neighbors-a-deep-dive-into-dhcpv6-part-1/</guid>
      <description>&lt;p&gt;Probably due to the (“secondary”) role it has been historically assigned within the IPv6 universe, DHCPv6 is a protocol which is very different from its IPv4 counterpart. Some of the differences and similarities have been discussed recently (e.g. see &lt;a href=&#34;https://twitter.com/SCOTTHOGG&#34;&gt;Scott Hogg&lt;/a&gt;‘s article on “&lt;a href=&#34;https://community.infoblox.com/blogs/2014/10/21/high-availability-dhcpv6&#34;&gt;High Availability DHCPv6&lt;/a&gt;“). This post aims at covering a fundamental, yet widely unknown or misunderstood difference, that is the properties of DHCPv6 addresses and their behavior on the local-link.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Router Advertisement Options to the Rescue – A Deep Dive into DHCPv6, Part 2</title>
      <link>https://insinuator.net/2014/10/router-advertisement-options-to-the-rescue-a-deep-dive-into-dhcpv6-part-2/</link>
      <pubDate>Fri, 31 Oct 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/10/router-advertisement-options-to-the-rescue-a-deep-dive-into-dhcpv6-part-2/</guid>
      <description>&lt;p&gt;This is the sequel post to the &lt;a href=&#34;http://www.insinuator.net/2014/10/i-dont-have-any-neighbors-a-deep-dive-into-dhcpv6-part-1/&#34;&gt;first part&lt;/a&gt; in which I mainly covered some elements of the specification wrt the “on-link” flag and the IPv6 subnet model.&lt;br&gt;&#xA;In short each IPv6 address has an associated flag which determines if the host considers the respective address to be part of “a network where neighbors exist”. If this is the case ND is performed to talk to them, otherwise all communication with other hosts on that prefix is sent to the router. This flag is NOT set for DHCPv6 addresses (and, btw, just to make this clear already, there’s no way of setting it as part of the DHCP configuration procedure either) so communication with hosts with the same DHCPv6 provided prefix is supposed to go through a router, which in turn is very different (behavior) from the IPv4 world.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Configuring IPv6 Snooping and DHCPv6 Guard on Cisco IOS</title>
      <link>https://insinuator.net/2014/01/configuring-ipv6-snooping-and-dhcpv6-guard-on-cisco-ios/</link>
      <pubDate>Thu, 30 Jan 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/01/configuring-ipv6-snooping-and-dhcpv6-guard-on-cisco-ios/</guid>
      <description>&lt;p&gt;Hi everyone,&lt;/p&gt;&#xA;&lt;p&gt;Some of you may already know (the ones who are following Enno on &lt;a href=&#34;https://twitter.com/Enno_Insinuator&#34;&gt;Twitter&lt;/a&gt;) that Enno and I had our lab day in preparation for the &lt;a href=&#34;https://www.troopers.de/troopers14/troopers14-ipv6-security-summit-2014/index.html&#34;&gt;IPv6 Security Summit&lt;/a&gt; at &lt;a href=&#34;https://www.troopers.de&#34;&gt;Troopers&lt;/a&gt;.  We had a brand new and shiny Cat4948E as our lab device to do some testing of the current generation of Cisco’s IPv6 First Hop Security (FHS) mechanisms. The Catalyst was running the latest image available (15.1(2)SG3).&lt;/p&gt;&#xA;&lt;p&gt;In this small blog post, we will take a look at the configuration and behavior of IPv6 Snooping and DHCPv6 Guard. So let’s start with IPv6 Snooping:&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
