nanog mailing list archives

RE: Internet Edge Router replacement - IPv6 route table sizeconsiderations


From: Mike Walter <mwalter () 3z net>
Date: Thu, 10 Mar 2011 20:00:40 +0000

Is anyone staying away from certain address ranges in /127s?  I have seen where they say not to use the all zeros or 
end addresses from 1 - 127.  Thoughts on this?  

-Mike 
-----Original Message-----
From: Justin M. Streiner [mailto:streiner () cluebyfour org] 
Sent: Thursday, March 10, 2011 10:36 AM
To: Richard A Steenbergen
Cc: nanog () nanog org
Subject: Re: Internet Edge Router replacement - IPv6 route table sizeconsiderations

On Thu, 10 Mar 2011, Richard A Steenbergen wrote:

On Thu, Mar 10, 2011 at 10:52:37AM -0800, George Bonser wrote:

What I have done on point to points and small subnets between routers
is to simply make static neighbor entries.  That eliminates any
neighbor table exhaustion causing the desired neighbors to become
unreachable.  I also do the same with neighbors at public peering
points.  Yes, that comes at the cost of having to reconfigure the
entry if a MAC address changes, but that doesn't happen often.

And this is better than just not trying to implement IPv6 stateless
auto-configuration on ptp links in the first place how exactly? Don't
get taken in by the people waving an RFC around without actually taking
the time to do a little critical thinking on their own first, /64s and
auto-configuration just don't belong on router ptp links. And btw only a
handful of routers are so poorly designed that they depend on not having
subnets longer than /64s when doing IPv6 lookups, and there are many
other good reasons why you should just not be using those boxes in the
first place. :)

+1

Auto-config has its place, and I don't think core infrastructure is one of 
them.

In our addressing plan, I've allocated /64s for each point-to-point link, 
but will use /127s in practice.  That seemed like the best compromise 
between throwing /64s at everything and being prepared for the off-chance 
that something absolutely requires a /64.

jms



Current thread: