Bold Statements
If any of you is interested in the intricacies of IPv6 Neighbor Discovery (ND) I briefly referred to in the course of my series on DHCPv6, I recommend reading section 5.2 “The Host, the Link, and the Subnet in IPv6” of Yar Tikhiy’s excellent ebook “IPv6 for IPv4 Experts”. It can be found here.
Best
Enno
Continue readingThis is the sequel post to the first part in which I mainly covered some elements of the specification wrt the “on-link” flag and the IPv6 subnet model.
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.
At the end of the first part we had a configuration state which led to two global addresses on both systems involved, a DHCPv6 provided one and another one generated as part of the SLAAC process, which can create operational issues of all kinds (improper source address selection, hindered troubleshooting etc.). Furthermore such a setting does not reflect “the operational DHCPv4 model” which we envisaged as the ultimate goal of our exercise. I had finished that post along the lines: “we then have to get rid of the SLAAC address”.
Continue reading “Router Advertisement Options to the Rescue – A Deep Dive into DHCPv6, Part 2”
Continue readingProbably 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 Scott Hogg‘s article on “High Availability DHCPv6“). 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.
Continue reading “I Don’t Have Any Neighbors – A Deep Dive into DHCPv6, Part 1”
Continue readingSome hours ago Iljitsch van Beijnum posted an email with the above subject to the RIPE Best Current Operational Practices (BCOP) mailing list.
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 second part of my blog post series on IPv6 address planning. 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.
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 draft slides of the talk which was initially planned. Furthermore two fellow IPv6 practitioners (Hi Roland & 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.
Let’s hope that we as the IPv6 community can reach some consensus in this space soon. See you in London,
have a good one everybody
Enno
Continue reading
This is a guest post from Antonios Atlasis.
Today we had the opportunity at ERNW to have a full-day discussion about MLD. The discussion was led by Jayson Salazar who writes his thesis on the topic.
For the newcomers to IPv6 world, the purpose of MLD, a subprotocol of IPv6, as defined in RFC 2710, is “to enable each IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes.” MLD was updated by MLDv2 in RFC 3810 in order to “add the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses.”
Continue reading “MLD and Neighbor Discovery. Are They Related?”
Continue readingThis is a guest post by Antonios Atlasis.
Continuing the discussion about the IPv6 Atomic Fragments started at the IPv6 hacker’s mailing list and the freshly proposed draft RFC regarding the deprecation of the generation of IPv6 Atomic Fragments, we decided to check very quickly what is the current situation regarding the acceptance or the rejection of Atomic fragments in the “real world”. Thanks to Rafael Schaefer and the RISC lab at ERNW, we got some first measurements really fast.
Continue reading “Atomic Fragments vs. Fragmentation in the IPv6 “Real World””
Continue readingThis is a guest post from Antonios Atlasis.
Taking the chance from a discussion on the IPv6 hacker’s mailing list and the freshly proposed draft RFC regarding the deprecation of the generation of IPv6 Atomic Fragments, I decided to test very quickly what is the current status related with the latest and some of the most poplar Operating Systems (OS) status (whether they send Atomic Fragments in response to Packet Too Big messages, or not). The motivation behind this was to check which one of them is potentially vulnerable to the DoS attack using the technique described in the above proposed RFC and taking it for granted that Atomic Fragments are blocked in the real world (but more about this, in another blogpost in the near future).
Continue reading “Packet Too Big Messages and Atomic Fragments”
Continue readingIn the light of the recent release of version 5.0 of Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) on July 31, it seems to be more than appropriate to talk a bit about the new features and some general things to take into account when using EMET (for the new certificate pinning feature of EMET 4.0, see Friedwart’s comment). For all of you who don’t know EMET, in short, it’s a free mitigation tool for Windows developed by Microsoft, helping the user by preventing vulnerabilities in software from being successfully exploited. The tool works by protecting applications via a number of security mitigation technologies, vastly extending Windows operating system mitigation capabilities as Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR).
Continue reading “Some Things to Consider when Using EMET”
Continue readingWe’re currently involved in a number of IPv6 activities in different organizations and one of the questions we are still facing – even in cases where there’s already a (in most cases networking team driven/originated) “project” (incl. budget, project sponsor, milestones etc.) – is along the lines of “How to sell IPv6 to our management?”.
In the following I will shortly lay out the line of reasoning and the terminology we usually employ for the task. Furthermore I’ve anonymized a presentation which we recently prepared as “input” for the network team of an enterprise organization; it can be found here. In case you want to get this as a PPT (for recyling purposes) pls send me a direct email (in exchange, we might ask you for a small donation of your will to the Troopers charity project… ).
Continue reading “IPv6 for Managers”
Continue readingSome weeks ago, at RIPE 68 in Warsaw, Sander Steffann gave a presentation about revising RIPE 554 which, in his own words, “is a template guideline for procurement of stuff that should do IPv6” (here’s the steganography transcript of the IPv6 working group session). Some of you will probably know RIPE 554 as a quite helpful document for identifying reasonable real-world requirements for IPv6 capable network devices (in particular at times when vendors quite willingly put an “IPv6 ready” sticker on all their gear…).
Continue reading “IPv6 Requirements for Cloud Service Providers”
Continue reading