I for one get really irritated when my traceroutes and pings are broken and I need to troubleshoot things. ;-) But I guess something has to give.
On Wed, Nov 30, 2011 at 9:15 PM, Mike Jones <m...@mikejones.in> wrote: > On 1 December 2011 00:55, Jimmy Hess <mysi...@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 > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
