On Wed, Nov 30, 2011 at 06:55:56PM -0600, Jimmy Hess wrote: > On Wed, Nov 30, 2011 at 2:13 PM, Owen DeLong <o...@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.
