In message <201202232352.q1NNqNiq011915@xxxxxxxxxxxxxxxxxxx>, Martin Rex writes : > Mark Andrews wrote: > > > > ned+ietf@xxxxxxxxxxxxxxxxx writes: > > > > > > Which brings us right back to my original point: This definition of > > > "ready" is operationally meaningless in many cases. > > Correct. > > > > > I contend that OS are IPv6 ready to exactly the same extent as they > > are IPv4 ready. This isn't a IPv6 readiness issue. It is a > > *application* multi-homing readiness issue. The applications do > > not handle unreachable addresses, irrespective of their type, well. > > The address selection rules just made this blinding obvious when > > you are on a badly configured network. > > There was *NO* multihoming involved at all. What addresses were there on the loopback interface? If there were IPv4 and IPv6 addresses then it was dual stack multi-homed machine. Applications need to work over the loopback interface as much as they need to work over a external interface. Having a IPv4 address on the loopback interface is NOT a given. A application MUST work over the loopback interface when it does not have a IPv4 address. I've yet to work on a machine that was not multi-homed to some extent. All of the machines I've worked on in the last 25 years have had multiple interfaces. > The OS of my primary workmachine has in IPv6 protocol stack with > an extremely bogus design that pretty much precludes any kind > of migration and testing. It delays sending DNS A lookups (in favour > to AAAA lookups) for whooping 16 seconds to DNS servers for which > only an IPv4 address is known over an interface that is IPv4-only > with a default route over that very same IPv4-only interface. > And even disabling IPv6 on the two virtual network interfaces > did not stop that non-sensical behaviour. If there is a 16 second delay you can blame the authoritative server adminstrators for either installing a non RFC compliant nameserver or misconfiguring a delegation which is detectable by looking at the negative response. The returned records are inconsistent with the delegation. DNSSEC however will help fix this as broken delegation like this don't work for positive signed answers either with a general purpose nameserver whereas that can be overlooked with simple testing in a non DNSSEC environment. A RFC 1035 compliant nameserver is quite capable of answering "I have no type 28 records at this name" or this name doesn't exist to a type 28 query. A RFC 1035 recursive server should also handle the lookup and return of type 28 records as opaque blobs of data. This is why compression pointers are only supported on "well known types" in RFC 1035 so it could handle records that it doesn't know the internal structure of. The only thing a RFC 1035 server can't do is serve AAAA records. Serving AAAA records requires a newer server. Secondly there is no evidence that asking for AAAA records is due to a OS problem or a application problem. Without reading the source code there is no way to know. > It just doesn't make sense to send out less DNS A lookups than > DNS AAAA lookup, and even less to delay DNS A queries for 16 seconds. Actually it can make sense to make AAAA queries. Knowing whether there are AAAA addresses or not can change how you behave when you can't reach the machine over IPv4 assuming there are A records. > The only solution was to rip IPv6 out of the OS entirely. Luckily > I had access to the console of the machine, because when requesting > uninstall of that (inactive) IPv6 protocol stack, the machine > immediately dropped *ALL* networking on all interfaces, > ipconfig /all gives an empty list, as if remote administration > of servers was a concept completely unknown to the OS vendor. > > If there is desire for widespread adoption of some new protocol > or feature, than it is a very very very very bad idea to create > such an extremely misbehaved implementation. And it's not like > "this is brand new and we didn't have time yet to fix this bug". Making a AAAA should add 1 round trip lookup, in most cases that's much less than 200ms to the startup of a application assuming no caching. If there is caching or overlapping queries the additional time can drop to nano seconds. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf