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.