As a strong beleiver in the IPv6 protocol, when I first saw that it was finally integrated in the .NET framework 1.1, I finally sensed some interest from Microsoft in putting this new protocol into mainstream. I decided back then to add the support for IPv6 in the Mono project which now allows .NET software to use this transport on both windows XP/2003 and IPv6 compatible Unix platforms.

Well, this protocol is not that much used yet because even if IIS or WebServices work fine with it, many programmers still have the bad habbit to use the first IPAddress instance of an IPHostEntry instance returned by, say, the Dns.Resolve method. This is not the only reason... The main being the chicken and egg problem, well known in the IPv6 world : "My clients don't ask me for IPv6 compatible applications, so I don't add IPv6. Besides, there are no IPv6 applications..." Well, if noone starts writing some, there'll never be any... :) (This is where I like Microsoft commitment, they are big enough to make all this change)

Anyways, IPv6 has a long way to go to acheive complete support throughout the overall framework, since the network code is everywhere... Especially in the remoting codebase, which behaves terribly when using IPv6 endpoints....

But this is not the most important thing about all this. Here at Epitech, we do have a lot of different machines which happen to have a lot of different network cards... And each time, it is a different entry in the Windows Device Manager. There is one thing about adding interfaces : Each interface has its own instances of all protocols that are bound to it. You can see this with a call to EnumProtocols call which lists all the protocols available in the system.

If you watch carefully this function, you'll see that the buffer that is passed to it is allocated by the user. If the buffer is not big enough, the function call fails and returns an "Insufficient Buffer" error, which generally leads to an other call with a larger buffer.

Actually, I don't know what they though at Microsoft when they designed the interop with WinSocks but the .NET network subsystem (which is initialized before any network operation) only allocates room for about 50 different protocols when calling the EnumProtocols function. In a "normal" situation, i.e. without IPv6 enabled on the system, 50 is large enough for many situations... You have to have a lot of different interfaces registered (and not necessarily active) to reach the 50 protocols limit. But when you have IPv6 enabled... It comes really quickly.

So, when you reach this limit, nothing tells you that this is the problem you've been looking for... You're just having an exception like "A too small buffer has been provided." on any call to network related methods. This is really disturbing when a message is completely out of the context...

Then all you have to do when you're facing this problem, aside from removing IPv6 stack, is to remove hidden interfaces from your system. (Device Manager/View/Show Hidden Devices and cleanup the Network Adapters section)

Microsoft told me that it would be fixed in the .NET Framework Service Pack... The sooner the better, but I'm waiting since last year... And some of my students are also facing the problem. Using technologies of the future can be tough sometimes :)