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.
In short, it’s a mess.
Again, RFC ambiguity 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.
Troopers is right around the corner and as
I am responsible for the whole conference network I wanted to make sure that
everything is working as expected. I went to the venue on Friday because of two
things I wanted/needed to setup. Compared to last year’s setup we had a couple
of changes in regards to the provider connection (resulting in some changes for
our network setup). First, we now have a rather big pipe for the uplink and more
importantly (well that depends on the point of view ;)) there is a native IPv6
connection. Before that I had to tunnel all IPv6 traffic from the venue to one
of our gateways and to forward it out (as native IPv6) from there. As this step
isn’t necessary anymore, and the staff on the venue isn’t that experienced with
IPv6, I had in mind to setup and verify that IPv6 is working as desired. The
router used over there is a
Mikrotek Routerboard. As I haven’t
worked with these devices before, I was curious whether everything works as it
should ;).
Based on recent research in the ERNW IPv6 lab and with
our MLD talk looming
we’ve put together a (as we think) comprehensive document discussing how to
thoroughly test MLD implementations in various components (network devices or
servers/clients). We hope it can contribute to a better understanding of the
protocol and that it can serve as either a checklist for your own environment or
as a source of inspiration for researchers looking at MLD themselves.
Last year,
during the
IPv6 Security Summit
of Troopers 14 I had the
pleasure to present publicly, for first time, my IPv6 Penetration Testing /
Security Assessment framework called
Chiron, while later, it was also
presented at Brucon 14 as part of the 5×5
project. This year, I am returning back to the place where it all started,
to the beautiful city of Heidelberg to give another workshop about Chiron at
the
IPv6 Security Summit
of Troopers 15. But, is it just another
workshop with the known Chiron features or has something changed?
I would say a lot :). The most significant enhancements are described below.
This is the sequel to the similar post on
“IPv6-related Requirements for the Internet Uplink or MPLS Networks“.
As mentioned there these requirements were created in the course of an RfP for
network security services. The goal of this document was to provide a check list
of IPv6-related requirements that security devices being part of the individual
providers’ offerings have to fulfill in order to fully support the future IPv6
network.
Similar to the documents we
released for Linux
and
Windows (and
actually inspired by a comment to the post on the Linux
guide) Antonios wrote another guide, this
time for Mac OS X.
It can
be found here.
We hope some of you might find it helpful.
Have a great day
One of the main DHCPv6 enhancements – fyi: we have already discussed DHCPv6
in some other posts – many
practitioners have been waiting for quite some time now, is full support of
RFC 6939 (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.
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”).
correlation of IPv4 and IPv6 addresses of a given host identified by its MAC
address.
(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
this presentation of the IPv6 deployment at CERN,
btw: slide #9 might be helpful when discussing IPv6 transition plans with
your CIO. or not).
So far it seemed very few components support RFC 6939. When
Tim Martin mentioned at Cisco Live that Cisco
devices running IOS XE support it by default, we decided go to the lab ;-).
We’re currently involved in a complex RfP procedure for global network services
of a large organization. As part of that we were asked to define a list of IPv6
related requirements as for the Internet uplink and MPLS circuit connections.
The involved service providers/carrier offerings will be checked to comply with
those.
As a source of inspiration we mainly used the excellent
“What To Ask From Your Service Provider About IPv6”
document from Cisco, and enhanced that with stuff we observed in other
environments (go wrong), namely with regard to MTU/PMTUD and in the
space of prefix filtering.
Here’s the first draft list we came up with:
Originating from a customer IPv6 deployment project, in early 2014 we defined a
number of requirements as for the IPv6 capabilities of IPAM solutions, with a
certain focus on security-related requirements (due to the specific environment
of the project). We subsequently performed a practical evaluation of several
commercial solutions, based on documentation, lab implementation and vendor
communication.
We just released
a newsletter describing the requirements and the results of the evaluation.
It
should be noted that in the interim newer versions of the evaluated products
might be available which might have enhanced features. Hence, from our
perspective, understanding the requirements of an individual environment might
even be more important than the actual results described in that document (as
those only reflect a certain point of time). We hope to contribute here to a
well-informed requirements definition and decision taking process on your
side.
Feel free to get back to us on any of the points laid out or, even better, join
us at the Troopers
IPv6 Security Summit
in Heidelberg on Mar 16th/17th in order to discuss any related points.