IPv6 resolution bugs (the IPv6 Brave New World)

[Matt Grant]

Hi!

Items for immediate action:

   1. Recently I discovered bug #15226 which appears to affect the whole of
   the client side of the source4 tree.
   2. There is also a parallel problem over in source3
   in libcli/http/http_conn.c http_connect_send() where queries are only done
   for A records for dcerpc over http!  I have not run into this problem yet
   in my IPv6 ULA environment (Samba only on IPv6 ULA network)

This concerns Samba in an IPv6 dual stack environment, only working on IPv6
ULAs and ignoring ISP supplied PD prefixes, and RFC1918 set up for IPv4
NATed connectivity. My Samba AD DCs and file servers only listen on ULA IPs
via an smb.conf 'interfaces = lo fd14:BEEF:BEEF:BEEF:1::DEAD/64' statement
and there is only AAAA for the samba servers in SAMBA_INTERNAL DNS

Manifesto for MR 2271

People will say I am mad to not use RFC 1918 addresses for Samba, but there
are places where IPv6 ULA is seriously done such as Facebook, and other
large environments.  It does pay to do this, as we then actually find these
issues that exist in the Samba codebase and get it cleaned up.

You have to admit though that RFC1918 + IPv6 ISP PDs are becoming a common
environment for Samba to run in.

DNS 'Spam' from windows clients via dynamic DNS is becoming an
administrative problem as administrators prefer that internal traffic
happens ONLY on the RFC1918 or IPv6 ULA internal addressing.  Using the ISP
supplied IPv6 PD is a problem as it can CHANGE if the ISP reboots their
network concentrator back at their local 'office'/telephone exchange
potentially creating havoc at your own business as PCs  and printers
potentially fail to work...  We should endeavour to keep the ISP IPv6 PDs
out of the Samba/Windows environment address resolution.  Hence MR2271 as
the start to this for filtering dynamic DNS updates. (If servers are only
listening on RFC1918 or IPv6 ULA, and that is how Windows clients talk to
the servers, IPv6 ISP PD address changing becomes a non-issue)

I should also point out that these issues mostly disappear from DNS if the
DNS is ONLY updated for A AAAA and PTR from the DHCP server.  This set up
is also far more secure as it also prevents/contains  AD server spoofing.

Your thoughts please.

I do believe that items 1) and 2)  should be sorted out immediately as
important bugs as they involve obvious non-functionality.

Best Regards,

Matt Grant