On Thursday the 20^(th) Enno, Jayson and I had the pleasure to present our
latest research results regarding MLD at
Deepsec 2014, both from vendors’
implementation perspective as well as regarding protocol design flaws (some
preliminary results as well as our testing methodology were discussed
here and
here).
For refreshing out memory, in a nutshell, the purpose of MLD, a subprotocol of
IPv6, is to inform routers about the presence of nodes which are interested in
receiving specific multicast traffic
(RFC 2710). The newer version of MLD,
MLDv2 adds the ability for source address selection
(RFC 3810).
Next week, at DeepSec, we’re going to give a
talk about Multicast Listener Discovery
(MLD), a component of IPv6 which is realized by means of ICMPv6 messages. There
are two versions of MLD (mainly specified in RFC 2710 and RFC 3810 respectively)
and while MLD is technically implemented by ICMPv6 exchanges, these
specifications describe a whole set of rules and communication formats, hence we
can safely talk about “the MLD protocol”.
Now, you might ask: how does one tackle the task of examining the security “of a
protocol”?
To contribute to the
current debate
on IPv6 route deaggregation & “strict-filtering” performed by certain ISPs we
just released a white paper on
“Dynamics of IPv6 Prefixes within the LIR Scope in the RIPE NCC Region“.
I will give a
talk
on the overall topic later today at the Routing Working Group. We sincerely
hope that the IPv6 community becomes aware of the inherent issues, and that
practical solutions can be found which consider & meet the needs of the
different parties involved.
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.
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 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.
This 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.
Some 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.
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.”