In message
<201202232352(_dot_)q1NNqNiq011915(_at_)fs4113(_dot_)wdf(_dot_)sap(_dot_)corp>,
Martin Rex writes
:
Mark Andrews wrote:
ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com 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(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf