Home page logo
/

nanog logo nanog mailing list archives

Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?
From: Chuck Anderson <cra () WPI EDU>
Date: Thu, 1 Dec 2011 09:42:07 -0500

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.


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]