On 01/31/2014 02:30 PM, Alexandru Petrescu wrote: >>>>> I tend to agree, but I think you talk about a different kind of limit. >>>>> This kind of limit to avoid memory overflow, thrashing, is not the >>>>> same >>>>> as to protect against security attacks. >>>> >>>> What's the difference between the two? -- intention? >>> >>> Mostly intention, yes, but there are some differences. >>> >>> For example, if we talk limits of data structures then we talk mostly >>> implementations on the end nodes, the Hosts. >> >> Enforce, say, 16K, 32K, or 64K. And document it. > > Well, it would be strange to enforce a 16K limit on a sensor which only > has 4k memory size.
That's why it should be configurable. -- Set a better one at system startup. > Enforcing that limit already means write new code > to enforce limits (if's and so are the most cycle-consuming). That's the minimum pain you should pay for not doing it in the first place. And yes, writing sloppy code always requires less effort. > On another hand, the router which connects to that sensor may very well > need a higher limit. > > And there's only one stack. > > I think this is the reason why it would be hard to come up with such a > limit. Make a good default that handles the general case, and make it configurable so that non-general cases can be addressed. >>> For ND, if one puts a limit on the ND cache size on the end Host, one >>> would need a different kind of limit for same ND cache size but on the >>> Router. The numbers would not be the same. >> >> 64K probably accommodates both, and brings a minimum level of sanity. > > Depends on whether it's Host or Router... sensor or server, etc. Do you run a host or router that needs more than 64K entries? >>> But a >>> kernel programmer (where the ND sits) is hard to suppose to be using bad >>> habits. >> >> THe infamous "blue screen of death" would suggest otherwise (and this is >> just *one* example)... > > The fault of blue-screen-of-death is put on the _other_ programmers > (namely the non-agreed device programmers). :-) the hell is the others. I don't buy that. Win 95 (?) infamously crashed in front of the very Bill Gates upon connection of a scanner. And W95 was infamous for one-packet of death crashes (the "nukes" from the '90s) >>>> You cannot be something that you cannot handle. I can pretend to be >>>> Superman... but if after jumping over the window somehow I don't start >>>> flying, the thing ain't working.... and won't be funny when I hit the >>>> floor. >>>> >>>> Same thing here: Don't pretend to be able t handle a /32 when you >>>> can't. >>>> In practice, you won't be able to handle 2**32 in the NC. >>> >>> I'd say depends on the computer? The memory size could, I believe. >> >> References, please :-) > > Well I think about simple computer with RAM and virtual memory and > terabyte disks. That would fit well a 2^64-entry NC no? Consider yourself lucky if your implementation can gracefully handle, say, 1M entries. >>>> Take the /64 as "Addresses could be spread all over this /64" rather >>>> than "you must be able to handle 2**64 addresses on your network". >>> >>> It is tempting. I would like to take it so. >>> >>> But what about the holes? Will the holes be subject to new attacks? >>> Will the holes represent address waste? >> >> "Unused address space". In the same way that the Earth's surface is not >> currently accommodating as many many as it could. But that doesn't meant >> that it should, or that you'd like it to. > > Hmm, intriguing... I could talk about the Earth and its ressources, the > risks, the how long we must stay here together, the rate of population > growth, and so on. > > But this 'unused address space' is something one can't simply just live > with. > > Without much advertising, there are some predictions talking 80 billion > devices arriving soon. Something like the QR codes on objects, etc. > These'd be connected directly or through intermediaries. If one > compares these figures one realizes that such holes may not be welcome. > They'd be barriers to deployment. mm.. what's the problem here? Cheers, -- Fernando Gont e-mail: [email protected] || [email protected] PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
