Archive for the ‘Conference’ Category

In January, I was honored to be invited to speak on IPv6 security at the UK Network Operators Forum (UKNOF42). The UKNOF is a not-for-profit organisation seeking to improve co-ordination between IP network operators in the UK to enhance the efficiency and stability of the UK’s network infrastructure. Their events attract a wide-range of presenters mainly from the UK. They are an excellent opportunity to share knowledge and best practice with other network operators on network operations and security.

The full list of presentations can be found here.

My presentation (video/slides) was a comprehensive overview of IPv6 security, why it needs to be taken seriously, how it differs from IPv4, the problems it presents and current IPv6 security techniques and best practice.

I was delighted to be invited to speak at this year’s Global IoT Summit in Bilbao Spain. The GIoTS is a gathering of many of the world’s foremost IoT experts and opportunity for those working in the area to meet and exchange ideas.

Cybersecurity is of particular importance to IoT, where numeruous low-powered devices are often interfacing with and controlling critical systems in our daily lives. It is essential that these systems are secured even though the resources available on each device for security are constrained by functionality, capacity and power.

My presentation, which you can find here, sought to provide an overview of the IoT cybersecurity challenges and technologies. I focused on IPv6-based IoT solutions implemented using 6LowPAN. 6LowPAN is rapidly becoming the primary networking technology for IoT systems.

Further information on the IEEE Global IoT Summit can be found here.

Erion’s David Holder is honoured to have been invited to give the keynote address at next week’s Fedv6 conference in Washington DC.

Fedv6 is the organisation working within the US government to promote and deploy IPv6. The Federal government has a long history of working towards the adoption of IPv6. Towards this end they set two goals; firstly, to IPv6 enable public services by 2012 and secondly to deploy IPv6 internally by 2014.

Many good things have come out of the USG’s IPv6 efforts. These include useful documentation, guidance and tools. Back in 2008, NIST created the USGv6 Profile. This is a profile for IPv6 within the US government. In 2009, the Federal Acquisitions Regulation (FAR) made IPv6 a requirement in all purchases except where there is an explicit waiver. This step helped avoid funds being wasted on products that could not support IPv6.

In addition to all of this, NIST created a web-site that monitored the deployment of IPv6 on public services such as web-sites, mail servers and DNS.

Further information about the Fedv6 taskforce and the progress of IPv6 within the US government can be found in Kevin L. Jones’ recent presentation at the North American IPv6 Task Force (NAv6TF).

Erion’s David Holder provides an insight into the recent IPv6 Security Workshop

I was privileged to be invited to speak at this year’s IPv6 Security Workshop arranged by the UK IPv6 Council. The event, held at the BT Centre in central London, was oversubscribed well in advanced with around 170 delegates registered. This was the largest subscription for any IPv6 Council event to date and the speediest registration yet! The speaker line-up included many leading IPv6 security experts, those involved in developing IPv6 security standards, the National Cyber Security Centre and a range of industry experts. We were all delighted to see such a high level of interest in IPv6.

In my introductory presentation, I gave a quick, but comprehensive, overview of the fundamentals of IPv6 Security. You can view the slide deck here. For those who were not able to attend, here are a few highlights.

IPv6 Security Fundamentals

The first crucial point to appreciate is that IPv6 is everywhere. It is the default on all major operating systems and is widely deployed across the Internet. Further, its growth is exponential and at the current rate all Internet users will be using IPv6 by 2020. If you have IPv6 today you will find that over 75% of your traffic will be carried by IPv6 rather than IPv4.

Even if you have not deployed IPv6 it is important to understand that most of current your networks areIPv6 ready and are IPv6 enabled by default. All modern operating systems contain IPv6 stacks. These are on by default. Operating systems will use IPv6 if they possibly can. This means two things: firstly the majority of security vulnerabilities associated with IPv6 are on your networks today even if you have not deployed IPv6 and secondly if you look on your networks you will see IPv6 traffic. Therefore it is essential that you implement IPv6 security, ideally you should have done this over decade ago when IPv6 was already widely implemented in common operating systems. It is not sufficient to, as some suggest, turn off IPv6. Partly because modern operating systems are IPv6 operating systems and also because turning off IPv6 is often an unsupported configuration.

There are two, possibly three, widely held misconceptions regarding IPv6 and IPv6 security. The first two are:

Misconception 1: IPv6 is more secure than IPv4

Misconception 2: IPv6 is less secure than IPv4

Both of these are wrong. They both assume that a comparison between IPv4 and IPv6 is meaningful, it isn’t. The reason is simple, in our networks there are no IPv4 stacks, all stacks are IPv6 stacks. Therefore, whether you are using IPv6 or not the vulnerability surface of your IPv4 network is practically identical to that of an IPv6 network. There is a combined vulnerability surface consisting of IPv4 and IPv6 vulnerabilities. Comparing the two is therefore meaningless.

There is another major misconception that is relevant to IPv6 security and that is,

Misconception 3: IPv6 is IPv4 with longer addresses

It isn’t. IPv6 has many complex and subtle differences from IPv4. It is a new protocol with many new features. Even in those areas that are superficially the same as IPv4 there are surprising differences. As a result what is often best practice in IPv4 is not best practice in IPv6.

Even IPv6 and IPv4 addresses are very different and not just in their length. For example:

• NEW New attributes: length, scope and lifetimes
• NEW It is normal for IPv6 interfaces to have multiple addresses
• NEW IPv6 addresses can change over time
• DIFFERENT Multicast is very important in IPv6
• NEW There are large numbers of methods for assigning interface identifiers
• DIFFERENT How addresses are used and managed are different
• DIFFERENT Global public addresses are the norm
• NEW And of course there are a huge number of addresses

These differences and that includes all the differences not just those relating to addresses, have a direct impact on the IPv6 vulnerability surface and the mitigation techniques required for IPv6.

Whilst it is not possible to list all the IPv6 vulnerabilities it useful to get an idea of where the problems lie. The slide below shows a rough approximation of the IPv6 vulnerability surface. It is not complete and it cannot show how probable or how significant each of the risks is. What it does show is how many new and different areas there are that need to be considered when implementing IPv6 security.

In the presentation, I went through a number of key areas to illustrate three things; first that IPv6 is significantly different from IPv4, second that some of the areas of vulnerability shown in the above diagram contain many vulnerabilities themselves and finally that not everything is worse. Some things are better than IPv4. Of particular note is the area of scanning and reconnaissance. In IPv4, scanning a whole network is simple and fast. In IPv6, it is impractical to directly scan every address in an IPv6 subnet. This is because testing every address in an IPv6 subnet would take hundreds of thousands of years even on Gigabit networks. This is not to say that attackers cannot discover the addresses of IPv6 nodes, they can, it is just much more difficult for them to do so. However, do not forget that all of the vulnerabilities of IPv4 exist in the IPv6 dual stack, therefore even though scanning IPv6 might be difficult if nodes also have IPv4 addresses is it is still trivial for an attacker to find those nodes from their IPv4 addresses.

When designing and implementing your IPv6 security policy you should pay particular attention to these areas that are listed as new in the diagram. Those areas that are similar to IPv4 are often mitigated in IPv6 using the same techniques that are common in IPv4. Therefore, you should begin by ensuring that the security techniques that you use for IPv4 are also implemented for IPv6. For example, you should use ingres and egress filtering in both IPv4 and IPv6 and you should use unicast reverse path forwarding in both.

In terms of the many differences in IPv6, you need to pay particular attention to the NEW areas in the diagram. Of these, the increased end-to-end transparency, extension header attacks, neighbor discovery attacks and transition mechanism attacks are of particular importance, but this is not to say that you can ignore the other areas. In the presentation I went through each of these and gave specific examples of the types of vulnerabilities. Here are five of the areas that I covered:

• End-to-end Transparency - Public addresses are the norm, there is no NAT44. Firewalls are necessary (as they are with IPv4).
• ICMPv6 - Much more complex and critical then ICMPv4. Requires more complex security techniques.
• Extension Header Manipulation - Whilst the IPv6 header is simple, extension headers that carry options are extremely complex and can be used by attackers in a variety of ways even to hide attacks from security devices.
• Neighbor Discovery Protocol - NDP is very important to the operation of IPv6 it is also complex. It introduces a number of vulnerabilities to IPv6 nodes and subnets. Securing against these is especially important.
• Transition Mechanisms - The huge number and complexity of transition mechanisms in itself increases the vulnerability surface. Worse, these create complex interactions between IPv4 and IPv6 and some are standard on many operating systems. Mechanisms such as Teredo are designed to tunnel through IPv4 NAT and firewalls raising the possibility of Teredo being used to circumvent perimeter security.

I then gave a whirlwind tour of IPv6 security features and their pros and cons. Briefly these were:

• IPsec - Largely the same as IPsec in IPv4. The one key difference is how it is used. The absence of NAT44 in IPv6 makes IPsec transport mode more practical than in IPv4 changing the way IPsec is used.
• Privacy Addresse - Useful (and the default on many platforms). The temporary nature of privacy addresses has significant implications for operational management including IPv6 Forensics, audit and legal intercept
• Opaque Static Addresses - Useful (and becoming the default). Avoids linking IPv6 addresses to hardware addresses.
• SeND and CGAs -Secure Neighbor Discovery (SeND) and Cryptographically Generation Addresses (CGAs) are not widely implement in many operating systems.
• RA-Guard - Extremely useful protection against rogue IPv6 routers, but can be circumvented using extension headers.
• DHCPv6-Shield- Extremely useful protection against rogue DHCPv6 servers, but can be circumvented using extension headers.
• Neighbor Discovery Inspection- Extremely useful protection against attacks against Neighbor Disocvery, but can be circumvented using extension headers.
• MLD Snooping- Useful for limiting the effectiveness of multicast attacks. Primary use is to improve LAN multicast performance.

I finished by suggesting that the real security benefits of IPv6 will only be seen when we get rid of IPv4 and move to IPv6-only networks. Indeed, some organisations are already moving to IPv6-only networks mainly for operational and cost reasons. Moving to IPv6-only networks will also have security benefits. Removing all of the IPv4 and transition mechanism vulnerabilities it will be possible to make full use of the security features of IPv6.

The key high-level points to take away from my presentation were:

• IPv4-only networks are historic, they rarely exist today
• IPv6 should already form a part of your security policy today
• IPv6 has introduced many new vulnerabilities and features
• IPv6-only networks will have fewer vulnerabilities
• Legacy IPv4 thinking is a security risk - staff IPv6 competency is crucial

Erion IPv6 Cyber Security Training

Erion is the world’s leading IPv6 training company with the largest portfolio of IPv6 training courses covering all topics and environments. We have a range of IPv6 security training courses from short introductions to advanced and detailed technical IPv6 security courses. Further information on our IPv6 training can be found at www.ipv6training.com.

Erion recently released a NEW IPv6 Forensics course. This advanced course covers all aspects of IPv6 forensics and is ideal for all those involved in forensic activities.

Other Presentations from the IPv6 Security Work Shop

You can find many of the other presentation from the workshop at http://www.ipv6.org.uk/2017/03/31/ipv6-security-workshop-jul-2017/.

Earlier this year I was privileged to speak at the North American IPv6 Task Force (NAv6TF) 2017 conference held at LinkedIn’s offices in Sunnyvale California.The NAv6TF has a long history of promoting IPv6 adoption in North America and further afield. Many well-known IPv6 names are actively involved in NAv6TF. This year, I joined a truly excellent set of  speakers from organisations such as LinkedIn, Cloudflare, Akamai, Cisco, Microsoft, NASA, ARIN, Comcast, Infoblox and T-Mobile.

My presentation described the effects that the increasing deployment of Carrier Grade NAT (CGN) is having on the legacy IPv4 Internet. CGN is causing problems for all parties from application developers, content providers, service providers, law-enforcement through to end-users. These non-trivial problems can all be mitigated or resolved through the deployment of IPv6. As a result, CGN and the degradation of the IPv4 Internet are acting as drivers for the adoption of IPv6.

You can watch a video of the session below or view the slides here.

At the conference, Kevin L. Jones from presented a very interesting talk on the status of IPv6 in NASA and the Federal government. I was delighted that he had taken the time to measure the IPv6 status of each of the organisations represented by speakers at the conference. Erion got five out of five stars!

The UK IPv6 Council is running a one-day workshop on IPv6 Security in July. Erion’s David Holder is to present a session entitled “IPv6 Security Fundamentals”.

Agenda

10:00 - 10:30 - Arrivals and Registrations

Morning block - Setting the scene

10:30 - 10:40 - Opening session

10:40 - 11:00 - BT Keynote (Mark Hughes, CEO BT Security)

11:00 - 11:30 - System Design with Security in Mind (Rich, Chief IA Architect, National Cyber Security Center)

11:30 - 12:30 - IPv6 Security Fundamentals (Dr. David Holder, Erion)

12:30 - 13:30 - Lunch break

Afternoon block 1 - IPv6 security in practice

13:30 - 14:30 - Practical IPv6 Security tools (Fernando Gont, SI6 Networks)

14:30 - 15:00 - IETF IPv6 Security update (Tim Chown, JISC; Fernando Gont, SI6 Networks)

15:00 - 15:30 - Afternoon break

Afternoon block 2 - Lessons learned

15:30 - 15:50 - Stories from the end of thousands of IRC IPv6 connections (Russ Garrett, IRCCloud)

15:50 - 16:10 - The routing challenges of IPv6 DoS mitigation (David Freedman, Claranet)

16:10 - 16:30 - IPv6 first hop security in cloud environments (David Freedman, Claranet)

16:30 - 17:00 - Panel discussion

Booking Details

Full details can be found at  https://www.eventbrite.co.uk/e/ipv6-security-workshop-tickets-34850460666

The North American IPv6 Task Force (NAv6TF) 2017 conference is to be held at LinkedIn’s headquarters (Sunnyvale, CA) on the 26th and 27th April 2017. Details can be found here.

Erion’s chief consultancy and CEO Dr. David Holder will be speaking at the event on  CGN a Driver for IPv6 Adoption. Here is the abstract:

Abstract

The IPv4 address space is exhausted and the scarcity of addresses is leading to the deployment of techniques to preserve and better utilise currently allocated addresses. Amongst these techniques, Carrier Grade NAT (CGN) is one which service providers are increasingly deploying in their access networks.

The long-term solution to address exhaustion is IPv6 with its enormous address space. However, the existing and widespread deployment of IPv4 networks and systems make it necessary to continue to support IPv4 into the near future.

The deployment of CGN is not without its challenges. CGN in the data path affects all players; end users, application developers, service providers, carriers and content providers. CGNs can impact banking applications, internet advertising, internet analytics, legal Intercept, computer forensics, privacy, voice and messaging applications, games consoles applications, AJAX applications and much more.

This presentation reviews the implications of CGN, how it affects all parties, the actions that can mitigate CGN issues and why the increasing deployment of CGN is an important driver for the adoption of IPv6

Bio: Dr David Holder CEng FIET MIEEE

Dr Holder has over twenty-eight years’ experience in the IT industry in senior technical and management posts. He is currently the CEO and chief consultant at Erion Ltd, the world-leading IPv6 training and IPv6 consultancy company.

In his role at Erion, Dr Holder has had over nineteen years’ experience providing IPv6 consultancy to leading global organizations worldwide. He has assisted organizations to develop IPv6 strategies, enable IPv6 in their products, create IPv6 address schemas and deploy IPv6. His experience covers all major networking and operating system platforms.  Clients include Alcatel Lucent, Arbor Networks, Atos Origins, Brocade, BT, Dell, Ericsson, HP, IBM, Sony and Sophos.  He is the author of white papers, solution guides, books and training courses on IPv6 and related topics. Recent papers include two published by the UK telecommunications regulator Ofcom on IPv6 and CGN.

In addition to his role at Erion, Dr Holder is active in promoting IPv6 both in the UK and abroad where he is a regular speaker at IPv6 related conferences. He is the chairperson of the IPv6 Task Force Scotland, founder of the IPv6 Future Enabler conference and is a regular speaker at Global conferences on IPv6.

Dr Holder has a PhD in High-Frequency Semiconductor Physics and an Honors degree in Electronic Engineering. He is a Chartered Engineer, a Fellow of the Institute of Engineering Technology and a Member of the IEEE. He holds several industry qualifications.

Last week Erion’s David Holder spoke at the immensely successful (and oversubscribed) IoT Scotland 2015 event in Edinburgh. His presentation covered the crucial, but often underrated, topic of IoT integration and standardisation. Interestingly many of the other speakers at this year’s event alluded to IoT standards demonstrating the increasing awareness of how important IoT standardisation is.

This following is a brief summary of the presentation, which can be found here.

IoT: Integration and Standardisation

Making your way through the “Fog”

There are a bewildering array of standards and even standards bodies relating to the Internet of Things (IoT). Choosing between the many competing standards requires a detailed knowledge of their characteristics, benefits and pitfalls. For those seeking to deploy IoT this is a daunting task.

Despite the difficulties, choosing appropriate standards is extremely important. Standards bring many benefits; interoperability, compatibility, functionality, flexibility, longevity, ease-of-use, maintainability and manageability. All of these factors have a direct or indirect impact on the bottom line. For example, IoT devices are often built into infrastructure that may have lifetimes stretching into years and decades. It is highly desirable that the standards will last over the same period and is particularly desirable that the risk of having to replace IoT infrastructure prematurely due to choosing a legacy standard is mitigated by choosing IoT standards with a long shelf life. Standards do not just affect capital costs. Choosing common, well-known and widely supported standards has an impact on your support staff’s ability to maintain and manage your IoT infrastructure on an ongoing basis.

Unfortunately, the huge number of standards and ironically the large number of standards bodies makes selecting the best for your IoT deployment extremely difficult.

The ideal set of standards would allow every device to talk to every other device directly (Device to Device communication), and allow each device to access and be accessed from the global Internet. In a perfect IoT world, there would be no need for intermediate systems to allow devices to talk to each other or to communicate with the Internet. A single standard would work across all networks and provide a unified platform for the widest range of IoT solutions.

Today’s reality is very different from the ideal.  Current IoT systems are “Vertical Silos” with islands of devices using one standard or one vendor’s product that cannot communicate directly with each other or the Internet. These vertical silos often tie IoT solutions to a single type of network. For example, they may work on IEEE 802.15.4 (a common IoT radio standard) but they do not work over Bluetooth, WiFi or other radio technologies. Worse, if you need to integrate devices across different networks, standards or vendors then you are force to deploy “Upperware”, additional systems that provide a high-level way of bridging between the islands of IoT and the Internet.

Naturally, this is undesirable. Ideally, your IoT standards would allow all devices to talk to each other regardless of the network they are on and would allow them to communicate with the Internet. You would also like your IoT standards to fulfil all the other benefits of standards such as longevity and manageability. One set of standards that meets this description is the set of standards that underpins the global Internet. These protocol standards include the Internet Protocol (IP). IP is familiar to network managers, systems administrators and application developers alike. It is likely to be around for a very long time, just as the current Internet has been in existence for many decades already. It is specifically designed to work across many different network types and IP makes possible direct communication between all devices and the Internet.

The bad news is that the legacy version of the Internet Protocol (IPv4) that is in current use on many networks today is not suitable for IoT. The main reason for this is that IPv4 has run out of addresses. It has none available for current requirements never mind the tens of billions and maybe even trillions of IoT devices. Worse, the IPv4 Internet has only been kept going through the increased use of address sharing using techniques such as Network Address Translation (NAT) and Carrier Grade NAT (CGN). These techniques break exactly the functionality that we wish to use with the IoT. Specifically, NAT and CGN break the end-to-end connectivity that allows devices to talk directly to each other and the Internet. For these reasons, and others, IPv4 is not a solution, even though it has the characteristics that we need from a ubiquitous IoT standard.

Thankfully there is a long-term solution to the limitations of IPv4, that is the next version of the Internet Protocol; IPv6. IPv6 has a practically limitless number of addresses, it has no NAT or CGN to impeded connectivity, it performs better, works over all radio and network technologies, is well understood due to its widespread deployment and is expected to have a very very long life.

In addition, there is version of IPv6 that is specifically design for IoT devices. It is called 6LowPAN. 6LowPAN is an IPv6 standard for Low power and lossy networks (LLNs). 6LowPAN ticks all the boxes for an ideal IoT network standard. It works across many different radio and networking technologies providing a common protocol for IoT devices. It allows direct communication between devices and with the Internet. It uses technologies that are familiar to network managers, systems administrators and software developers and it is specifically designed to work in IoT networks.

Today IPv6 is widely implemented and available on the global internet. Nearly 100% of the Internet backbone supports IPv6. Over 50% of the major content providers in the world are IPv6 enabled. In many parts of the world, IPv6 is a standard feature of consumer and business broadband services. In the UK, broadband ISPs are eventually beginning to roll out IPv6. This is removing the final hurdle for the widespread use of IPv6 in the UK. Interestingly, when an end user has both IPv4 and IPv6 they find today that on average over 70% of their traffic is over IPv6. Better still, they benefit from the lower latency and the removal of IPv4 impedances such as NAT and CGN.

So where does this leave IoT standards? There are still a huge number of contenders, including large players such as Zigbee. Despite this, we are seeing a steady and increasing move to the use of 6LowPAN. A number of key products and technologies have adopted 6LowPAN. For example, Google’s Nest is based on a 6LowPAN solution called Thread. In addition, even Zigbee one of the largest pre-6LowPAN IoT players has announced Zigbee-IP that is 6LowPAN based. So overall, we are seeing an industry that is gradually showing a move to 6LowPAN or IPv6 based solutions. The enormous size of existing IoT deployments and investments means that it is likely to be some time before 6LowPAN becomes the clear winner, however we can be pretty confident be so eventually.

The implications are clear, whatever other constraints you may have on your choice of IoT technologies, and there are many, it is clear that you should ensure that you are prepared for IPv6 and 6LowPAN to play a significant role. Even if you have been forced to invest in other technologies because a 6LowPAN solution was not available, you should expect that in the long term you will need to deploy 6LowPAN as well or even migrate your current deployment to 6LowPAN.

Samba is the world’s leading Windows-Linux integration open source project. Here at Erion we have a long history of working with Samba to IPv6 enable its various components. This year is no different. At SambaXP 2015, Erion’s David Holder gave a presentation on IPv6-only Samba. He described the rational behind the need for IPv6-only Samba deployments, the status of IPv6-only Samba and how to deploy Samba in an IPv6-only environment.

Here is a brief summary of the presentation, the slides for which can be found here.

IPv6 is becoming increasingly common. It is standard in all major operating systems, deployed in all Tier-1 ISPs, available in almost 100% of transit carriers and is supported on 46% of the world’s top web-sites. Today, users that have a dual-stack service from their ISPs (that is they have both IPv4 and IPv6) find on average that 70% of their traffic is carried over IPv6. Furthermore, world-wide the percentage of Internet users who are IPv6 capable is doubling year upon year.

This increase in the use of IPv6 was evident at SambaXP. When asked, over 50% of attendees at the presentation stated that they now use IPv6. In previous years, only a handful were using IPv6.

Today organisations are moving beyond adding IPv6 to create dual-stack networks. Now some are looking to create IPv6-only environments where nodes no longer use IPv4. This change means that Samba now needs to be able to operate not only in dual-stack environments but also in IPv6-only environments. Previously, in dual-stack networks, if Samba had a feature that was not supported in IPv6 then it could drop back to use IPv4. In IPv6-only networks, dropping back to IPv4 is not possible and everything must work over IPv6 and IPv6 alone.

Organisations are moving to IPv6-only networks for a range of reasons. The most obvious is that it significantly reduces network administration. Managing two protocols rather than one not only doubles administration tasks but it can also significantly complicate certain scenarios where IPv6 and IPv4 interact. This particularly true where a mix of transition mechanisms are involved. There are other equally significant reasons for creating IPv6-only networks. In some large IPv4 networks there are multiple islands of duplicated RFC1918 address space. This is a major impediment to network operations and administration. Many ISPs and mobile operators use multiple 10.x.x.x networks internally because their networks are so large. Removing these and replacing them with a single IPv6 network avoids all the difficulties with operating across multi-islands of private address space.

A final growing reason to reduce or remove IPv4 in a network is the growth in the use of Carrier Grade NAT (CGN) in the access networks of ISPs. Content providers and others have no control over where and when an ISP may deploy CGN. However, the deployment of CGN many cause them significant issues. Using IPv6 in addition to IPv4 provides a method of circumventing the problems caused by CGN.

As a result, IPv6-only environments are appearing in an increasing number of networks including those of ISPs, mobile operators, data centres and cloud providers. Samba is used in many of these and environments and it is therefore imperative that Samba be made IPv6-only ready.

Samba is “IPv6 ready”, it works successfully in a dual-stack environment. However, when it comes to IPv6-only operation Samba exhibits issues because some features retain IPv4-only code. Whilst workarounds are possible and the major of functionality is fully IPv6-ready, the current Samba releases are not quite ready for IPv6-only operation. This will change with future releases as we fix the remaining issues.

Once Samba is fully IPv6-only ready there are a number of additional potential benefits.

Internally SMB/CIFS uses large MTU sizes. From SMB 2.1 onwards the use of Multi-Credit allows SMB MTU to go from a maximum of 64KB to multiple megabytes. In Samba, the default is 1MB and in Windows it is 8MB. However, in IPv4 the maximum MTU is 64KB and so it is not possible to reflect the SMB multi-credit sizes of 1MB or 8MB at the network layer. In IPv6, there is support for Jumbograms allowing multi-megabyte MTUs. In theory the use of Jumbograms could lead to performance improvements in SMB over IPv6. In practice, you still need to datalink that can support very large MTUs. Few such datalinks exist. One example is Infiniband. Another possible option in virtualised environments is the use of virtual networks adapters such as virtio. At the moment, virtio supports MTUs up to 64KB even though Ethernet only supports MTUs of 9KB. It is conceivable that in the future this could be extended to allow for IPv6 Jumbograms.

Another possible benefit is the use by IPv6 of Path MTU discovery (PMTU). PMTU allows for an internal network to use the largest possible MTU without increasing the amount of fragmentation taking place within the network. Thereby improving SMB throughput performance. Whilst, in most modern networks, IPv4 also has Path MTU discovery support, IPv6 still has the edge as IPv6 PMTU is mandatory and available on all IPv6 nodes.

There are a number of other potential benefits from using IPv6. These include, for example, the removal of NAT (and CGN) from the transmission path. This makes possible communication using AD protocols and SMB over the wider Internet along with the use of IPsec to secure them. Both things which are difficult or impossible through NAT/CGN. Microsoft has leveraged this benefit in its DirectAccess product that many organisations are using as a replacement for their VPN concentrators.

Configuring IPv6-only Samba is very similar to the configuration of dual-stack Samba. The difference is the absence of IPv4 addresses (except on the loopback interface). The presentation covered a few issues that need to be considered in IPv6-only Samba deployments. These will be fixed in future Samba releases.

Finally, there was a demonstration of IPv6-only Samba operation and a discussion of IPv6-only Samba related topics.

At last week’s IPv6 Future Enablers conference, Erion’s Dr. David Holder gave a presentation on the Implications of Carrier Grade NAT (CGN). This presentation was a brief summary of the findings of the CGN Study that he undertook in 2013 for Ofcom, the UK’s telecommunications regulator. The presentation is now uploaded to Erion’s web-site and can be found here.

In the Study, David Holder predicted that the downsides of CGN would lead to an increased adoption of IPv6. At the conference this was widely confirmed by fixed line and mobile service providers alike. All agreed that CGN is something to avoid and that IPv6 presents the only realistic long term solution to the IPv4 address exhaustion. Furthermore, all were agreed that IPv6 should be used to bypass the limitations of CGN.

At the conference, BT’s IPv6 Programme Director, Stuart Smith announced that BT intend to enable IPv6 for broadband users in 2015. He said that this was in part due to the limitations of CGN which BT trialled in 2013.