Samba 4 and IPv6

[David Holder]

Hi Tridge,

tridge at samba.org wrote:
> Hi David,
>
> (I have replied CCing the samba-technical list, as others may be
> interested. I hope you don't mind)
>
>  > Did you manage to make any more progress with Samba 4 and IPv6?
>
> yes, I stayed up late working on it last night. I attach my current
> patch. Note that it ended up being very different from the approach
> you took. Instead of having new ipv6 routines in socket_ip.c, I am now
> teaching all the IP code to know about both v4 and v6. I have also
> continued the trend to using char* to represent IPs, and have moved to
> using the more modern getnameinfo(), getaddrinfo() etc calls.
>   
This looks great. My patch was a bit of a hack so your approach is better.

Did you consider moving to sockaddr_storage? Jeremy did this in Samba 
3.2. Sockaddr_storage makes it easier to write protocol independent 
code. This way you don't need to teach much of the code to know about 
both v4 and v6 just use sockaddr_storage.

Jeremy mapped sockaddr_storage to whatever was available on platforms 
that did not have the IPv6 socket API.

I know you did not like this idea, but I still like using  getnameinfo() 
to return textual IP addresses. The reason is that it is protocol 
independent. The flag NI_NUMERICHOST ensures that no DNS lookups take 
place. This gets rid of a lot of inet_ntop() calls that have to 
explicitly specify the address family. It is a little slower though...
> The other major change is the "late binding" of the socket functions
> to either v4 or v6. When you call socket_create() on an IP socket it
> doesn't create the socket immediately. It waits until you do a listen,
> or a connect or similar, and uses the address arguments passed to
> those to work out whether you really need v4 or v6. If however you
> pass an explicit "ipv4" to socket_create() then it will force it to
> ipv4. That is used by the nbt code. All the other code just asks for
> "ip" and it works out the right address family when you first use the
> socket.
>
> There are still a couple of kinks in the patch below that I need to
> work out, but I think the general approach will work well. 
>
> Cheers, Tridge
>   
I'll try this patch out either tomorrow or when I am on holiday!

Many thanks,
David