RE: Last Call: <draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt> (Security Implications of IPv6 on IPv4 Networks) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]