On 1 December 2011 00:55, Jimmy Hess <mysidia@gmail.com> wrote:
Please explain. What are the better ways that you would propose of mitigating ND table overflows? If you can show a rational alternative, then it would be persuasive as a better option.
Link-Local? For "true" P-t-P links I guess you don't need any addresses on the interfaces (I don't on my 6in4 tunnels), but I assume most people are referring to ethernet type cross connects, so Link-Local addresses. As long as each device has at least 1 address assigned somewhere (loopback?) that it can use for management/packet generation purposes you don't need an address on every link like you used to do with IPv4. Now that there are plenty of addresses you don't need as many :) I suspect there are probably some practical issues with link-local on some kit and some network configurations due to lack of people doing it this way, but in theory there shouldn't be any reason that you couldn't use link-local for all your links then just have a /128 assigned to each routers loopback for management/packet generation purposes. This could remove overheads of worrying about address assignment for those links, you just need a single /128 per router. Depending on the network it might be better to statically set link locals rather than using automatic ones (fe80::1 and fe80::2 for 'upstream' and 'downstream' or whatever rules you currently use for deciding which end is 1 and which is 2) You could also do something similar for datacentres assigning blocks to customer servers, instead of configuring a /64 for each customer, or a /48 then giving customers blocks inside that to use, just configure a single /64 and give each customer a single address from that block with unassigned ones filtered, then route a /64 to them for any "extra addresses" they might want. Chances are if they need more than a couple of addresses they probably want them routed to them anyway rather than using ND for them all. The issue of dynamic assignments to end customers in a non-datacentre setting is a little more difficult, but I wonder how badly CPEs would break if you tried using DHCPv6 to give them back their link-local addresses, then DHCPv6-PD delegating by routing to their link local address, probably a lot worse than if you just used a /112 of global space. I don't think this area has too many issues though because DHCP ensures that the actual addresses on the links are all known, so this just needs to be used for filtering unknown addresses. Then there's just the question of what to do about the edge networks where SLAAC might be used and where you don't have such strict control over address assignment, i'll pass on that one for now. Link locals aren't as useful nearer to the edges, but for the backbones and datacentre networks they should be able to solve most of the biggest problems with ND attacks. The edge networks where just using link locals isn't really an option you can probably put a stateful firewall in quite easily, as these will be the edge default gateways that clients are sending their traffic directly to rather than needing to be done in the core. Although there really should be an option for users to open the firewall for inbound connections. Am I a complete idiot missing some obvious major issues with link locals, or am i just the only one not thinking IPv4-think? Opinions? :) - Mike