Using /126 for IPv6 router links

Mark Smith nanog at
Mon Jan 25 01:54:22 UTC 2010

On Mon, 25 Jan 2010 11:12:04 +1030
Glen Turner <gdt at> wrote:

> On 24/01/10 12:54, Owen DeLong wrote:
> > Use the /64... It's OK... IPv6 was designed with that in mind.
> I'd suggest using a /126. For two reasons.
> 1) Using EUI-64 addresses on router-router links is an error, the
>     consequences of which you encounter the first time you replace
>     some faulty hardware.[1]  I have made this error :-(  If you
>     are not using EUI-64 then assigning a non-autoconf /64 is no
>     less or more work than assigning a non-autoconf /126.

So all that's really saying is that you shouldn't use node addresses
derived from link layer addresses, due to the risk of them changing
when you swap out an interface, which makes sense. I don't think that
argument really supports not using /64s though, as <blah>::1/64 and
<blah>::2/64 would achieve that too.

> 2) Having a block of addresses for router-router links (and other blocks
>     for other infrastructure such as loopbacks and unicast) makes ACLs
>     much simpler. Using a /126 means that this block can last for a long,
>     long time, reducing configuration maintenance.

With a /48, the recommended size for an end-site, giving you 65
536 subnets, you could reserve the top quarter 16 384 subnets for your
point to point links and loopbacks (or split that in half to separate
loopbacks and p-to-p links), and then cover them with ACL them with
<blah>:c000::/50, and still have 49 152 subnets for your edge/services


> Cheers, Glen
> [1] Basically, interface addresses end up scattered through the
>      router's configuration (some manufacturers are better than
>      others in this regard). Tracking down all the references to
>      an address and changing the config merely as the result of a
>      hardware swap is painful and adds complexity at a time when
>      it is not desired.
> -- 
>   Glen Turner  <>
>   Network Engineer
>   Australia's Academic & Research Network  <>

More information about the NANOG mailing list