On Thu, Jan 6, 2011 at 12:17 AM, Joe Greco <jgreco@ns.sol.net> wrote:
However, that's not the only potential use! A client that initiates each new outbound connection from a different IP address is doing something Really Good.
No, Joe, it is not doing anything Good. This would require the software being written to make such random address selection, add more entries to the router's NDP table, and it would DoS the box's own router if an outbound scan were initiated from the host machine. Again, you totally fail to understand the problem. I should just attach a "facepalm" graphic to my reply and stop bothering with your idiocy, but it is important that as many people as possible understand these issues. Every additional person who is expressing concern to their vendors brings us closer to a solution. In addition, if the machine can choose another random IPv6 address in the /64 for each new outgoing connection, it could just as easily source all its outgoing connections from ... a single IPv6 address that does not accept any incoming connections. I will grant that this does not prevent "magic packet" attacks against bugs in the machine in kernel space, and that the machine could be the recipient of a DoS attack; but your proposed solution has no advantage in the case of, say, SQL Slammer 6, or other attacks exploiting vulnerabilities in user-space. On Thu, Jan 6, 2011 at 12:25 AM, Owen DeLong <owen@delong.com> wrote:
Is there any reason we really need to care what size other people use for their Point to Point links?
Personally, I think /64 works just fine.
I won't criticize anyone for using it. It's what I choose to use.
You should care what size you choose, Owen. I would if I was your customer. There are several reasons why. If you configure a /64 on a point-to-point interface e.g. SONET, some current platforms will bounce any "scan" packets back and forth between the two hosts until the TTL expires, which means an attacker can saturate the point-to-point link with two orders of magnitude less attack traffic than the link capacity. This is very bad. Also, if the link is a LAN, you are vulnerable to the ARP/NDP problem. This may be a per-interface issue on your box, or it may be a global one. In the per-interface case, most likely, the failure mode will be okay; but some vendors (including Juniper?) will eventually expire the ARP/NDP entry even though there is active traffic, and may be unable to re-learn it when needed due to the attack, which would break the link between routers. On the other hand, if it's a global issue, it will break NDP on the entire router, affecting all interfaces by whatever the platform's failure mode is. Obviously, that is worse. This is why "RFC compliant" is wrong, Owen. That a learned, experienced person such as yourself has no clue what the underlying problem is exemplifies my point: much, much more noise needs to be made about this issue. A lot of smart people have known about it for years but nothing is being done. Anyone can choose not to use /64 on their point-to-point links with no consequence to their business. Customers aren't going to choose another vendor because they are likely never even aware of it. The operational problem is that customers will want it on the PE/CE LANs, hosting center LANs, and so on; and right now, if you tell them "we can't do that," they have trouble believing you because the standard says otherwise, and a lot of other networks are currently doing it (because they think they don't have a choice other than to lose potential customers.) However, if you are running /64 instead of something like /124 on your VLANs or SONET circuits between routers, you should change this practice as soon as practical. Not doing so once you have been educated about this problem because it is "the standard" is very stupid. Pretty much every major transit network has figured this out and are doing it on their interfaces to BGP customers, too, either optionally, by default, or as the only choice. The industry standard must change to be non-hostile toward choosing a smaller subnet size than /64 to give coverage to those of us who do understand what we are doing as we roll out IPv6 to customers. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts