IPv6 prefixes longer then /64: are they possible in DOCSIS networks?

Chuck Anderson cra at WPI.EDU
Thu Dec 1 14:42:07 UTC 2011


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 at 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.




More information about the NANOG mailing list