I no longer have an IPv6 address.

This morning, the Teredo server I subscribed to, refused permission to my client, to obtain an IPv6 address via proxy, with no explanation given. Therefore, I have discontinued my use of IPv6 addresses.

It’s no big deal, because nobody was connecting to my server anyway, using IPv6.

Dirk

 

My Site mainly Requires Web-Sockets.

The origins of HTTP were essentially ‘sessionless’. This meant that with a server always listening on Port 80, a client could request one URL at a time, in response to which the server would return the page in question directly to the client’s port number. This included the CGI-scripts’ FORM data. But as the early Internet evolved, Web-sites started to become ‘session-aware’. I explained this to my friends in the past as follows:

The client connects to the assigned port number 80 on the server, and requests a session, which causes the server to start listening on another port number, this forming a ‘session socket’. The one listening on port 80 was the ‘server socket’. The server’s session socket was dedicated to one client and to one session.

My friends did not acknowledge this description of how TCP works, I think mainly, because I did not use the right terminology. What I had referred to as a ‘session socket’, is officially termed a “Web-Socket” in the case of HTTP. It turns out that with an Apache server, many sub-processes can bear these Web-Sockets. They don’t exclusively exist in order to output Web-pages at a faster rate, in response to individual requests made by the clients, to the process still listening on port 80.

One fact to know about my site, is that for such purposes as viewing this blog, the use of Web-Sockets is required. In the case of certain other sections of my site, such as http://dirkmittler.homeip.net/GallIndex.htm, the use of Web-Sockets is not required, because those Web-pages exist mainly in a sessionless way – they can be fetched one at a time without error.

Certain proxy-servers will not allow a Web-Socket to get forwarded. These are logically also proxies which don’t allow SSL connections to be forwarded, because the encrypted SSL data is also sent via Web-Sockets or their equivalent. If you are connecting to the Internet via such a proxy, I’m afraid you won’t be able to navigate my blog correctly. I apologize for this, but there is little I can do about that. I think that you should still be able to fetch a single posting of mine, that comes up through a search engine.

Dirk

(Edit: ) This may also apply if you’re trying to connect to my IPv6 address, because my IPv6 is being provided by a Teredo proxy, which might have just assigned reduced privileges to my client:

Previous Post

 

I discovered an IPv6-related malfunction.

During past weeks, I had noticed that sometimes my browser’s home page, which is the Google Site I’m logged in to, would simply fail to display as I started my browser, or would fail to display even if I tried to click on a link that leads to it. Curiously, although this could have been a traffic-filtering issue from the content-provider, it was not affecting the same browser, logged in to the same account, from my other computers. At first I suspected that this could have been due to memory fragmentation, and perhaps a poor attempt by the browser on this one machine to allocate large segments of memory at once, which it would have had to be keeping silent at the same time. But it turns out, that the cause of this malfunction was something different.

What gave this away was that almost, only Google sites were affected, and no other large, complex sites. E.g., calling up my own blog’s pages would never fail.

It so happens that I have a Teredo Client running, which gives me access to IPv6 addresses. More to the point, it gives the IPv6 world contingent access to my site. But my machine has been running as a dual-stack machine for some time, which means that it can work internally with IPv6 addresses as well as IPv4, even though my ISP isn’t IPv6 -ready yet.

Well apparently what was happening, was that Google specifically has ‘true’ IPv6 addresses for most of its sites (unlike my lower-grade, ‘fake’ Teredo address). Most other Web-sites which I’ll be clicking on, don’t. It seems that my browser was preferring to retrieve all Google pages via IPv6, which meant that every time I sat down in front of it, it was also using the Teredo proxy. This put an undue load on the proxy, who in turn started dropping most packets routed to Google by my host. Which in turn was leading to a blank page.

Also, every time I reboot my computer, I get assigned a new, virtual IPv6 address. This was the true reason, fw the malfunction would seem to go away directly after a reboot, but them simply set in again.

Since I use “Iceweasel”, which is the Linux equivalent to “FireFox”, my solution was to open a new tab, and to type ‘about:config’ into the URL bar, at which point the typical warning popped up, which I always dismiss with an affirmative answer. And then in the Search Bar, I typed “IPv6″. There was only one setting that matched: “network.dns.disableIPv6″. This setting defaults to ‘false’. I double-clicked the setting, which toggled it to ‘true’, and restarted Iceweasel. And Tada – Problem solved!

It suits me fine that I have IPv6 enabled for connectivity, but not for browsing. Nor for harassing my IPv6-providing Teredo server.

Dirk