3 ms·
This looks like NAT pushed down to the endpoint itself. You've saved the translation in the router, but now routing lookups and ARP caches have grown by TEMP_V
by waych 4y ago
This looks like NAT pushed down to the endpoint itself.
You've saved the translation in the router, but now routing lookups and ARP caches have grown by TEMP_VALID_LIFETIME / TEMP_PREFERRED_LIFETIME.
What are valid values in the scenario you are proposing? The defaults are 1 week / 1 day, so 7X. If you chose to rotate each second, and say allowed addresses to only be valid for say 20 minutes, this still appears to be a ~1200X blowup in routing overheads.
- kazen44 4y ago> You've saved the translation in the router, but now routing lookups and ARP caches have grown by TEMP_VALID_LIFETIME / TEMP_PREFERRED_LIFETIME. They have not? The global routing table size for ipv6 at max is a /32 (if i remember correctly) every customer gets a /56 prefix to use in their network, so the routing table entry would still be the same, no matter how many addresses you use to cycle through in your /64. ARP caches do not exist in IPv6, and Neighbour discovery does not have the same "cache" mechanism as ARP does, it uses an entirely different mechanism for neighbour discovery. (which is also far more lightweight considering it is using multicast, compared to the broadcast of ARP).
- waych 4y agoI don't understand what you mean. Neighbor Discovery Caches certainly are a thing.