[138569] in North American Network Operators' Group
Re: Internet Edge Router replacement - IPv6 route table
daemon@ATHENA.MIT.EDU (Justin M. Streiner)
Thu Mar 10 14:32:59 2011
Date: Thu, 10 Mar 2011 10:35:47 -0500 (EST)
From: "Justin M. Streiner" <streiner@cluebyfour.org>
To: Richard A Steenbergen <ras@e-gerbil.net>
In-Reply-To: <20110310191226.GP68199@gerbil.cluepon.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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
