Internet Edge Router replacement - IPv6 route table sizeconsiderations

Mike Walter mwalter at 3z.net
Thu Mar 10 20:00:40 UTC 2011


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 at cluebyfour.org] 
Sent: Thursday, March 10, 2011 10:36 AM
To: Richard A Steenbergen
Cc: nanog at 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





More information about the NANOG mailing list