On Sat, Jan 23, 2010 at 7:50 AM, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Jan 23, 2010, at 7:56 PM, Mikael Abrahamsson wrote:
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" --Donald Knuth
A couple of points for thought: 1. Yes, the IPv6 address space is unimaginably huge. Even so, when every molecule in every soda can in the world has its own IPv6 address in years to come, it might not seem so big.
Then obviously, it's giving every molecule in every soda can an IP address that is the waste that matters. There are several orders of magnitude between the number of molecules in a soda can (~65000 times as many) as the number of additional IPs used by giving a point-to-point link a /64. When comparing the number of molecules in a soda can TO 2^64. It's like in the IPv4 world comparing a /30 to a /31. And arguing it's wasteful to give a point-to-point link a /30 since all it needs (in theory) is a /31. Near the beginning of IPv4 (before exhaustion was an issue). when at the same time standard practice was allocating /13s to users who will use at most a /20 in 10 years. Optimizing this early creates potential issues and reduces flexibility going forward. The designer/operator should not confuse design patterns that use more IP addresses than the minimum technically possible, for a block of addresses, with design selections that are gross wastes of address space -- such as assigning every molecule its own IP. IPv6 is a very large address space, so it's LARGE optimizations that matter, such as not giving every molecule its own IP. Not small optimizations that matter, such as using a /126 for a relatively small number of P-t-P links (in the grand scheme of things) versus a /64. Anyways, I would suggest reserving a /64 to each P-t-P link, and (If you prefer) set static neighbor entry for the peer (in the case of Ethernet) and configuring a /72 (smaller than what you have reserved). For the sole reason of disabling IPv6 autoconfig and neighbor discovery. Technically everything to the right of the /64 boundary is reserved for the HOST portion, and such is the design of IPv6. This allows for greater scalability than assigning a longer prefix. If that specific connection is ever to be replaced one day with a link that's _not_ point-to-point, or to be expanded, then the designer has greater flexibility: an option that does not require re-numbering the changed link. -- -J