Question about IPAM tools for v6

[Fernando Gont]

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: fernando at gont.com.ar || fgont at si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1