none
The IP Stack is being corrupted by an unhealthy emphasis on IPv6

    General discussion

  • First off, I'm a retired IT guru, having had numerous Microsoft and Cisco certifications; I have some pretty solid credentials, and I am capable of tracing problems to their source.

    Lately, over the past six months or so, I've noticed an emphasis on IPv6 that seems to be impacting the entire IP stack. I've had problems with Outlook "sticking" when I leave it open overnight, that is to say, that upon opening Windows, I'll notice that no new emails have come in since early the previous evening, unusual, because I usually get 30-60 emails per day. I'll close down Outlook, then reopen it, and suddenly my email is populated with emails with incoming times up to the present. It would be easy to blame this on Outlook, but it is, I assure you, not an Outlook problem

    Other programs get "stuck" too. I trade stocks, so I'll have open TradeStation, TC2000, sometimes ThinkorSwim, Chrome, and maybe one or two other programs; many of them "get stuck."

    I did a little investigating on my own, firing up NetMon to trace packets/frames, and found that all DNS queries were going out exclusively IPv6. I contacted Microsoft support about the Outlook aspects of the problem and the tech suggested I shut off IPv6 at the interface level, which I did. It didn't really help.

    What I did observe though was that Chrome would now pop up a little message in the lower-left corner, "Resolving host." Bingo, I'm now getting a three-second-plus delay in opening web pages. From my days as a guru I knew that DNS queries time out after three seconds. So I fired up NetMon, observed no DNS queries when opening a new page, and then, after the three second timeout, an IPv4 DNS query would go out, an immediate response came back in, and only then would the web page open.

    Serious question #1: Why is the IP stack initiating an IPv6 DNS query even when IPv6 has been disabled at the interface level?

    Serious question #2: I know my OSI stacks; DNS queries should be protocol agnostic. Protocol should be chosen/determined lower down the stack where the availability of IPv6 or even IPv4 should be determined or accommodated.

    From all appearances, it would seem that Microsoft is bound and determined to push us all in the direction of IPv6. I get it. The web is running out of IPv4 addresses, etc., etc. But this ignores the reality that 99% of all workstations - if not 100% - are running on private networks, and, that easily 95% of all Windows servers are operating on private networks, and that NAT is most often used to interface between these private networks and the public "web." Private networks, by definition, simply are very unlikely to ever run out of IPv4 addresses. I'd venture to say that perhaps 25% of all private networks are actually utilizing the same IPv4 IP address space, their overlaps not being a problem because they are private, and utilize NAT for their internet connections.

    So why is Microsoft pushing us towards an exclusive-IPv6 world? What purpose is being served? I can tell you about the inconveniences. Some of my trading software uses hard-coded host names. I can see the IPv4 DNS queries go out, I can see the IPv4 DNS responses come in, and yet my programs "can't resolve" and so roll over to the next hard-coded URL, fail, and so on, until I end the program and then restart it. Then it's fine.

    This insistence on IPv6 is screwing up the IP stack; it's is failing to follow established protocol within OIS, that is, that a query is protocol agnostic until it reaches the layer where the protocol is determined, and applied. I would be like insisting at the application layer that a query go out IPX when IPX is not even enabled or available as a protocol, leaving it then up to the application layer to determine that a "no-response" means they should try IP instead. Why otherwise would IPv6 DNS queries be initiated even when IPv6 is disabled, unless some upper-layer protocol is somehow bypassing the OSI model altogether?

    Please folks, fall back on standards. The OSI stack is there for a reason, even if it is not followed in a total lock-step manner within an OS, it is nonetheless the model of how protocols should be insulated from applications. The IP stack is being corrupted. When my Outlook fails to pick up new emails, it's because its queries are getting lost in the IP stack, and not because there's a problem with Outlook.

    I'll repeat that: there is no problem with Outlook. It's playing right, playing fair, gets along with its protocol stack neighbors, and is failing not because of any inherent flaws in Outlook. It, and my other applications, are getting lost in the IP stack, which is neither performing to OSI standards, or operating properly. Else why would Chrome be "Resolving host" with an IPv6 querywhen IPv6 has been disabled at the interface level. 

    IPv6 may be or may become a necessity for internet or web communications. I get that. But we do not run computers or even most servers "on the web," we operate them on private networks where there is no shortage of IPv4 addresses. Your're not "streamlining the operations of Windows 10 by forcing everything to work with IPv6," you're breaking a system that has been in place for decades, and works, or at least used to work, just fine. This rush to IPv6 is ill-advised, unnecessary, and is breaking applications left and right. Please fall back, regroup, remind yourself that the OSI stack exists for a reason, and begin to once again "play nice with others."

    Thank you for listening.

    P.S. As a Cisco networking guru I can tell you that I would certainly rather run my private network, even if it had over 150,000 users (which mine did) using IPv4 rather than IPv6. IP addresses are easier to remember, IPv6 addresses you have to write down then transcribe. To say that "IPv4 addresses come trippingly off the tongue and IPv6 addresses stumble and fall" is just a poetic way of saying that configuring a network for IPv6 is fraught with potential failures that we did not experience with IPv4. And for what? Again, and I want to emphasize this, WE RUN ON PRIVATE NETWORKS, AND FORCING US TO ACCOMMODATE IPv6 IS A ROYAL PAIN IN THE BUTT AND LEADS TO CONFIGURATION ERRORS UNNECESSARILY. WE DO NOT WANT TO RUN IPv6 ON PRIVATE NETWORKS BECAUSE WE DON'T HAVE TO. IPv4 WORKS FINE FOR ALL OUR NEEDS. THE ONLY PLACE OR TIME WE WOULD EVER NEED TO USE IPv6 IS WHEN COMMUNICATING WITH THE INTERNET, WHICH TRUST ME, WE ARE WELL-INSULATED FROM. LET NAT HANDLE THE TRANSLATIONS WHEN OR WHERE NECESSARY, AND LEAVE IPv4 ALONE. PLEASE?


    Paul J Sutton


    • Edited by Paul_in_AZ Monday, July 9, 2018 7:28 PM
    Monday, July 9, 2018 7:14 PM

All replies

  • Hi,

    Thank you very much for your support and suggestion. 

    I understand that the issue brought some trouble to you. Sorry for all these inconvenience.

    Please assure that Microsoft is always do the best to provide good products to customers and is always trying to improve these products. As a support engineer, I will try my best to assist you.

    While we were not able to make the requested changes to the product at this time, I will watch closely to this issue, If there is any related update, I will let you know. I want to thank you for your useful suggestion and patience along the way. 

    Meanwhile, we will report your feedback to our Product Team, and our team will do corresponding adjustments about this tool. I totally understand the inconvenience this issue has brought to you, and your current feeling about this issue. Your kind understanding is appreciated. We will keep pushing and tracking the process.

    Furthermore, we can click on the following link to give some suggestions and any suggestion will be appreciated.

    https://windowsserver.uservoice.com/forums/295047-general-feedback

    Highly appreciate your successive effort and time. Thanks again for your support and understanding.

    Have a nice day!

    Best regards,

    Michael


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com


    Tuesday, July 10, 2018 5:47 AM