At 10:59 01-04-2013, George, Wes wrote:
Since I was the one that provided some of this text and raised the
issues it's addressing, I'll take a crack at responding at a couple
of your concerns below.
Ok.
[WEG] It doesn't. This is a second-order effect, but IMO an
important one. If one is attempting to prevent IPv6 from being used
on a network in an effort to "secure" it from IPv6-related
vulnerabilities, one must consider the fact that there are multiple
IPv6 transition technologies specifically designed to enable IPv6
access on a network that is otherwise without IPv6 connectivity,
some that can be used without any coordination from the upstream
network admins. It might even "helpfully" try to share its IPv6
service with other hosts on the network (rogue RAs...). The act of
preventing those transition technologies from passing traffic (by
doing things like blocking protocol 41, for example) may create IPv6
connectivity that is broken or otherwise impaired, where an end host
believes that it has IPv6 connectivity via a transition technology
when it fact it does not because its transition mechanism is being
blocked upstream. Happy Eyeballs attempts to fix this by ensuring
that fallbacks to IPv4 happen more rapidly and IPv4 is preferred
when issues are detected with IPv6 connectivity. However, it's
inappropriate to rely on pervasive implementation of Happy Eyeballs
as the sole solution to prevent end host impacts, since the end user
may not know that IPv6 is actively being disabled on this network,
or that their IPv6 implementation is otherwise broken. This is a
problem that continues to get worse the more dual-stack content
becomes available.
I agree with the last sentence. Happy Eyeballs is about the
HTTP. There are other applications protocols too. :-) In the
context of the draft you have an IPv4 network and you want the
devices or applications to be IPv4-only. I see that as configuring
the applications (there is a browser option for IPv4 only
access). There isn't any mis-configured node as the document
intentionally argues for blocking IPv6 traffic and IPv6 transition
technologies.
[WEG] On a network with the stated goal of providing/allowing no
IPv6 connectivity, AAAA records are effectively useless. Preventing
hosts from receiving AAAA records in order to
Yes.
prevent them from attempting to connect to an IPv6 address and
failing is not broken DNS.
If there isn't any IPv6 connectivity it is useless to query for AAAA
RRs as the host is not going to establish an IPv6
connection. Instead of looking at the problem from that angle the
proposal uses a "middlebox" (not the correct term) to change
things. Once it becomes best practice to tamper with DNS there is
one more problem to solve as you can no longer rely on DNS working
according to specifications.
Regards,
-sm