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@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] 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 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. > > "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.