Question about IPAM tools for v6

Fernando Gont fgont at si6networks.com
Fri Jan 31 16:59:32 CET 2014


On 01/31/2014 12:26 PM, Alexandru Petrescu wrote:
>>
>> And it's not just the NC. There are implementations that do not limit
>> the number of addresses they configure, that do not limit the number of
>> entries in the routing table, etc.
> 
> There are some different needs with this limitation.
> 
> It's good to rate-limit a protocol exchange (to avoid dDoS), it's good
> to limit the size of the buffers (to avoid buffer overflows), but it may
> be arguable whether to limit the dynamic sizes of the instantiated data
> structures, especially when facing requirements of scalability - they'd
> rather be virtually infinite, like in virtual memory.

This means that the underlying hard limit will hit you in the back.

You should enforce limits that at the very least keeps the system usable.

At the end of the day, at the very least you want to be able to ssh to it.



> This is not a problem of implementation, it is a problem of unspoken
> assumption that the subnet prefix is always 64.

Do you know what they say assumptions? -- "It's the mother of all f* ups".

It's as straightforward as this: whenever you're coding something,
enforce limits. And set it to a sane default. And allow the admin to
override it when necessary.


> It is unspoken because
> it is little required (almost none) by RFCs.  Similarly as when the
> router of the link is always the .1.

That's about sloppy programming.

Train yourself to do the right thing. I do. When I code, I always
enforce limits. If anything, just pick one, and then tune it.



> Speaking of scalability - is there any link layer (e.g. Ethernet) that
> supports 2^64 nodes in the same link?  Any deployed such link? I doubt so.

Scan Google's IPv6 address space, and you'll find one. (scan6 of
<http://www.si6networks.com/tools/ipv6toolkit> is your friend :-) )

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492







More information about the ipv6-ops mailing list