Samba 4 needs to implement IPv6 support. Server side code is nearly there now, after changes made at SambaXP. However, the following needs changing for server IPv6 support: - Hiemdal configure needs to set HAVE_IPV6=1 in config.h. - Hiemdal kdc.c has "ip" hardcoded in socket_create calls. "ip" is an alias for "ipv4". It needs to be IPv6 on hosts supporting IPv6. - In other server code stream_setup_socket has "ipv4" string hardcoded (ldap_server, rpc_server, web_server,smb_server). It needs to be "ipv4" on IPv4 only machines and "IPv6" on IPv6 machines. Client side code will be harder! I am happy to provide help and testing on this one.
Created attachment 2447 [details] spam
Don't we need to bind on both the IPv4 and IPv6 sockets? We also need a reliable way to test the IPv6 stuff - perhaps the extended socket wrapper can help here.
> Don't we need to bind on both the IPv4 and IPv6 sockets? No. If you bind to IPv4 sockets you only listen on IPv4. However, if you bind to IPv6 sockets you listen on both IPv4 and IPv6. This is a design feature of IPv6 dual stacks and is an essential part of the new socket API. The IPv6 socket API only supports dual-stack IPv6 hosts. The way this works is as follows. All IPv6 hosts are dual-stack. That is they support both IPv6 and IPv4 at the network layer. Higher layers in the stack are all IPv6. The socket API providing access to the stack includes the traditional IPv4 socket calls and the new IPv6 socket calls. The important point to note is that regardless of whether you use IPv4 or IPv6 socket calls from the IPv6 socket API the stack underneath it is IPv6. The intention was that developers would always write IPv6 applications. These applications would then work on both IPv6 and IPv4 hosts over either transport as long as the IPv6 socket library was available. For example, my IPv6 hack for Samba4 to make it listen on IPv6 also listens on IPv4 - for free. The reason this works is as follows: At the network layer you have two stacks, IPv6 and IPv4. These use two different addresses, IPv4 addresses and IPv6 addresses. At the transport layer, TCP and UDP are pretty much the same. Applications are referenced by the same port numbers and the protocol operation is identical in IPv4 and IPv6 (with a minor difference for checksums). An application using the new IPv6 socket API always thinks it is talking IPv6. This means you write code for IPv6 only and it also works for IPv4. Consequently, at the application layer you only use IPv6 addresses. To allow an application to talk to an IPv4 host special IPv6 addresses called IPv4-mapped IPv6 addresses are used. These encode the IPv4 address into an IPv6 address with a special prefix. Use of an IPv4-mapped IPv6 address tells the stack to communicate over the IPv4 network layer as opposed to the IPv6 network layer. An IPv4-mapped address is formed using the IPv4 address in the bottom 32 bits and adding the prefix ::ffff:0:0/96. So if you have the IPv4 address 192.168.1.1 then the IPv4-mapped IPv6 address for this is ::ffff:192.168.1.1. Incoming, IPv4 traffic is mapped to the IPv6 transport layer and the addresses are converted into IPv4-mapped addresses. Use of an IPv4-mapped IPv6 address causes outgoing traffic to use the IPv4 network layer. When you listen on all interfaces the IPv6 API will listen on all IPv6 addresses including all the IPv4-mapped IPv6 addresses and so hey presto you are listening on IPv4 and IPv6. Phew - hope that made sense! > We also need a reliable way to test the IPv6 stuff - perhaps the extended socket wrapper can help here. I think that you are right. Unfortunately, I don't know much about how your test system works so I can't really comment.
How far is SAMBA with IPv6?
(In reply to comment #4) > How far is SAMBA with IPv6? Samba4 can be made to work over IPv6 using my IPv6 hack (see www.ipv6consultancy.com/ipv6blog). I am currently writing up a new hack as the old one does not work with recent changes to the code. With the IPv6 hack it is possible to do file sharing over IPv6 and other things. I have also joined a Samba4 domain over IPv6 using Windows Server 2008 as a client. Regards, David
I intend to have a look at this.
(In reply to comment #6) > I intend to have a look at this Jelmer, That is great news. I have time this week to look at this if you need any help with testing or IPv6. I am also going to look at Jermey's IPv6 changes to Samba3 this week as well. Regards, David
I think there is some progress in this topic. Could you enlighten us?
Marking as "Feature request"
Is there some update on this issue?
I just noticed this oldish bug report and the statement "However, if you bind to IPv6 sockets you listen on both IPv4 and IPv6." This is not, strictly speaking correct. Under Linux it depends on what the value of "net.ipv6.bindv6only" is set to. In Lenny this is 0. I believe the problem with setting it to 0 is that the application will see all connections as ipv6 addresses (ipv4 addresses are wrapped as ipv6 addresses). As such Debian is considering (or has) changed the default value to 1 for Squeeze. For more details, see this long thread on debian-devel: http://lists.debian.org/debian-devel/2010/04/msg00099.html
(In reply to comment #11) Brian is quite right. Today most platforms support IPV6_V6ONLY. This should be set (on platforms that support it). IPV6_V6ONLY means that IPv6 sockets only bind to :: not 0.0.0.0. Code should be protocol independent using socketaddr_storage and protocol independent functions. Plus IPv4 sockets should be handled as native IPv4 sockets rather than handling as IPv6 sockets using IPv4-mapped IPv6 addresses. This is current best practice. So my answer "No" in 2007 is not now best practice. Metze has recently implemented the use of IPV6_V6ONLY in Samba 3.6.0.
David, what do you think about tridge's current work on IPv6 in "master"? Is that enough for closing this bug?
I think that s4's IPv6 support has improved a lot. This should be enough to mark this as "FIXED".