On Wed, Jan 5, 2011 at 10:51 PM, Joe Greco <jgreco@ns.sol.net> wrote:
On Jan 6, 2011, at 12:54 PM, Joe Greco wrote: ... To say that "the endpoint *will be found*" is a truism, in the same way that a bank *will* be robbed. =A0You're not trying to guarantee that it will never happen. =A0You're trying to *deter* the bad guys. =A0You wa= nt the bad guy to go across the street to the less-well-defended bank across the street. =A0You can't be sure that they'll do that. =A0Someone who has it out for you and your bank will rob your bank (or end up in jail or dead or whatever). =A0But you can scare off the guy who's just looking to score a few thousand in easy cash.
Making it harder to scan a network *can* and *does* deter certain classes of attacks. =A0That it doesn't prevent every attack isn't a compelling proof that it doesn't prevent some, and I have to call what you said a poor argument for that reason.
Hi Joe,
I think what people are trying to say is that it doesn't matter whether or not your host is easily findable or not, if I can trivially take out you= r upstream router. With your upstream router out of commission, the findability of your host on the subnet really doesn't matter. Once the router is gone, so is your host, no matter how well hidden on the subnet it was.
So, the push here is to prevent the trivial ability to take out the upstream routers, so that the host-level issues will still matter, and be worth discussing.
Hope this helps clarify the reason for the overarching concern about the /64 subnet size.
I completely understand that issue. However, I feel that this is not a hopeless quagmire. We've frequently run into major problems in IP engineering in the past, and have coped with them with varying degrees of success (smurf and CIDR pop to mind). We've also shown that the underlying protocols and technology are open to tinkering where necessary; consider 802.3az. I basically agree that there may be some issues with the current IPv6 NDP (etc) system. We actually have issues with the current IPv4 ARP system, too (think spoofing etc). However, I think we might be looking at this the wrong way. Instead of vendor knobs to change the IPv6 protocol, which may interfere with both ethernet *and* v6, it seems to me that maybe the problem can be solved just for the ethernet portions of the problem. For example, while there might be a /64's worth of address space on an interface, I'm *pretty* sure that the design goal isn't actually to support all that. Further, a router's need to talk to that network will be isolated to that interface. I wouldn't be too shocked to see the NDP protocol morph a little to allow routers to more easily maintain a neighbor list in local (per-ifc) silicon, rather than in expensive router TCAM, since the best use of TCAM isn't ARP^WNDP anyways. The fact of the matter is that silicon is cheap and getting cheaper. We will see ethernet switches allowing the learning of MAC info for NDP purposes, just as we currently have ethernet switches policing MAC's for IPv4 sanity purposes. Routers will probably need to do some policing of NDP rates, but also we may see better silicon to help with ethernet. There may be ways to fix the *ethernet* /64 issues in IPv6. We could be talking constructively about that. Instead, I'm seeing what seems to me to be dislike of /64's in general. I don't really care to get into arguments about that, that ship sailed long ago, and those who missed the boat fighting it at the time aren't going to get any joy here. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.