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.
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
SM
'Upstream filtering of transition technologies or situations
where a mis-configured node attempts to "provide" native IPv6
service on a given network without proper upstream IPv6 connectivity
may result in hosts attempting to reach remote nodes via IPv6, and
depending on the absence or presence and specific implementation
details of "Happy Eyeballs" [RFC6555], there might be a non-trivial
timeout period before the host falls back to IPv4 [Huston2010a]
[Huston2012].'
I don't see what "Happy Eyeballs" has to do with operational security.
[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 tha!
t 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.
"For this reason, networks attempting to prevent IPv6 traffic from
traversing their devices should consider configuring their local
recursive DNS servers to respond to queries for AAAA DNS records
with
a DNS RCODE of 3 (NXDOMAIN) [RFC1035] or to silently ignore such
queries, and should even consider filtering AAAA records at the
network ingress point to prevent the internal hosts from attempting
their own DNS resolution."
The above breaks DNS in an attempt to remove everything IPv6 related
from the network.
[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 prevent them from attempting to connect to
an IPv6 address and failing is not broken DNS.
Regards,
Wes George
This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject to
copyright belonging to Time Warner Cable. This E-mail is intended solely for
the use of the individual or entity to which it is addressed. If you are not
the intended recipient of this E-mail, you are hereby notified that any
dissemination, distribution, copying, or action taken in relation to the
contents of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify the sender
immediately and permanently delete the original and any copy of this E-mail and
any printout.