Ron,
That's interesting. I was told on the IPV6 forum that running IPV6 with
NBT
requires SMB rather than native Windows Networking. Are you running port
445,
or 137-139?
Any idea why so many show here for help, and find relief after un
installing
IPV6?
I don't know why adding IPv6 would break regular windows networking.
It does not here.
I'm just thinking aloud here, to see if I can see a possible failure
mechanism.
So let me ramble on a bit....
Let's start by understanding how windows networking functions:
What protocols and ports are used etc.
First, we need to clear up the SMB thing you mention.
We need to tidy up the terminology a bit.
All windows networks use SMB, back as far as LanManger and DOS.
Pre-win2000 used SMB over NetBIOS.
NetBIOS provides 2 things:
A name resolution mechanism, and a data connection mechanism.
NetBIOS in turn could use one of several transport protocols,
but we finally settled on TCP/IP.
So a win98 network would typically run SMB over NetBIOS over TCP/IP.
A client would use NetBIOS to resolve the target name to an
IPv4 address, then establish a NetBIOS data connection to it.
With Windows200, many things changed.
There was a shift away from NetBIOS.
A win2k+ network does not need NetBIOS to share files.
DNS replaced NetBIOS for name resolution.
Direct Hosting of SMB over TCP/IP was introduced on port 445.
The NetBIOS layer could be removed.
A win2k+ network typically runs SMB over TCP/IP.
So in a pure win2k+ network, a client queries DNS to resolve the target
name,
and establishes a Direct Hosted SMB session with it on port 445.
You can disable NetBIOS over TCP/IP in this scenario.
( Certain things will still break, so I'd not reccomend this! )
The older mechanisms still live on for backward compatablility, however.
Firstly, we seem to need a local DNS server now.
There is typically no DNS server on a small p-p network.
DNS name resolution will fail, and if it does, we fall back on legacy
NetBIOS name resolution mechanisms, finally falling back on NetBIOS
broadcasts. So NetBIOS lives on for name resolution in p-p LANS.
Secondly, the target may be a legacy win98 box.
Assuming we can resolve the name, connection to port 445 will fail.
So we fall back on NetBIOS once again.
So in summary, a win2k+ network will try to use DNS for name resolution, but
will fall back on NetBIOS if it has to. It will then try to connect using
direct Hosting if it can , but will fall back on NetBIOS if it has to.
Do we agree so far?
Now ,where does IPv6 fit into this?
If you install IPv6, it will try to auto-configure itself.
In a proper native IPv6 environment, it will do router solicitation / router
announcements and will auto-configure an IPv6 address based on this. If it
fails to do this ( which it will in most current small non-IPv6 networks
where there's no IPv6 router making announcements ), then it will attempt to
gain IPv6 connectivity to the internet by a variety of automatic tunneling
mechanisms. Teredo is one such tunneling mechanism, which is designed to
tunnel through NAT. So the IPv6 stack will do its best to gain Internet
connectivity one way or another.
When IPv6 is installed, it will bind to both File+Print sharing and Client
for MS networks.
However, that is rather bogus.
"A computer running Windows XP with Service Pack 1 or Windows XP with
Service Pack 2 cannot access the file shares of a computer running Windows
Server 2003 using IPv6 and cannot host file shares that can be accessed over
IPv6. In other words, it cannot be a file sharing client or server over
IPv6. " ( Joseph Davies )
So I don't really know what these bindings represent on an XP machine. I
will query this.
In my LAN, the bindings are shown as checked on both the XP clients and the
2003 servers. The IPv6 bindings are at the top of the binding order.
Everything works well, but the actual F+P sharing traffic *must* be flowing
over IPv4, based on the above. I've not sniffed the traffic lately to see.
Windows server2003 does support F+P sharing over IPv6.
In any case, the support for File + Print sharing over IPv6 will be by
Direct Hosting of SMB over TCP/IP, not via NetBIOS. IPv6 does not support
NetBIOS.
I have not been able to repro a case of IPv6 breaking normal networking, and
I've been using IPv6 for several years now.
It would be interesting to un-bind F+P sharing from IPv6 and see if it makes
a difference.
There is one mode of failure I have seen, but not related to F+P sharing.
Most IPv6 aware client programs ( like IE6 ) will query DNS for both A (
IPv4 ) and AAAA ( IPv6 ) records. If DNS replies with both A and AAAA
records, the IPv6 address will be preferred, and tried first if IPv6 is
installed. Now, if IPv6 is installed, BUT there is no IPv6 routing
infrastructure in place, then the attempt to use IPv6 will time out before
failing. The client program will eventually fall back on IPv4, which will
work.
An example of this is a broken IPv6 machine ( IPv6 installed, but no IPv6
connectivity ) tries to go to anIPv6-enabled web site. Assuming theDNS
server is smart enough to supply the AAA records, the browser will try the
broken IPv6 route for a long time before falling back in IPv4.
Could this be the cause of the problems?
A machine attempting to connect over IPv6 and failing?
I doubt it.
Even if both machines had IPv6 addresses, but no IPv6 connectivity to each
other, why would they try?
How would a simple P-P lan resolve a name to an IPv6 address when it's only
local name resolution mechanism is NetBIOS?
NetBIOS would never supply an IPv6 address for the connection attempt to
fail on.
Any connection attempt would result in NetBIOS name resolution, which would
always resolve to an IPv4 address.
So I still can't figure out the failure mechanism.
And like I say, it's all working well here.
