On Mon, Jan 25, 2010 at 01:14:17AM -0800, Matthew Petach wrote:
As I mentioned in my lightning talk at the last NANOG, we reserved a /64 for each PtP link, but configured it as the first /126 out of the /64. That gives us the most flexibility for expanding to the full /64 later if necessary, but prevents us from being victim of the classic v6 neighbor discovery attack that you're prone to if you configure the entire /64 on the link. All someone out on the 'net needs to do is scan up through your address space on the link as quickly as possible, sending single packets at all the non-existent addresses on the link, and watch as your router CPU starts to churn keeping track of all the neighbor discovery messages, state table updates, and incomplete age-outs. With the link configured as a /126, there's a very small
That's an attack vector you have to worry about even today with IPv4 space. There are quite a few vendors who you can make fall over with CPU trying to do arp resolution and/or cam exhaustion just by doing "ip address x.x.x.x/16" as a directly connected block on an Ethernet interface. One redeeming quality to the whole autoconfig thing is it'll do a great job cutting down on port scanning for vulnerabilities on end hosts (or else make the flood of port scanning traffic 2^64 times worse, it remains to be seen I suppose :P). My personal theory is it will result in a black market of buying and selling people's active IPv6 addresses from various website logs and the like, so hax0rs will have something to scan. In a few years time it will probably be popular with end users to periodicially "rotate the shield frequencies" with their final 64 bits, or maybe even use them on a per-transaction basis for extra security. :) -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)