On Wed, Nov 30, 2011 at 06:55:56PM -0600, Jimmy Hess wrote:
On Wed, Nov 30, 2011 at 2:13 PM, Owen DeLong <owen@delong.com> wrote:
On Nov 30, 2011, at 9:10 AM, Ray Soucy wrote: I do believe that there is no benefit to longer prefixes than /64. Nobody has provided any convincing evidence to the contrary.
Yes they have, thoroughly; mitigation of this one particular issue, ND table overflow is a benefit. You simply don't have to worry about this issue in the most important place it arises if you implement long prefixes for all P-t-P links from the start.
I do believe there is no benefit to prefixes shorter than /126 for P-t-P links. Nobody has provided convincing evidence to the contrary.
There are better ways to mitigate ND than longer prefixes.
Please explain. What are the better ways that you would propose of mitigating ND table overflows? If you can show a rational alternative, then it would be persuasive as a better option.
Jumping in here, how about static ND entries? Then you can use the /64 for P-t-P, but set the few static ND entries you need, and turn off dynamic ND. An out-of-band provisioning system could add static ND entries as needed. Another idea, perhaps more useful for client LANs, would be to have a fixed mapping between IPv6 IID and MAC address. Use DHCPv6 to force clients' lower 64 bits to be equal to their MAC address (EUI-64 or similar) and program the router to use this directly instead of using NDP, or statically program the ND table on the router from the DHCPv6 lease data--there is already precedent for doing this with IPv4 & ARP using DHCP Snooping or Relay or Proxy on the router.