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.