Choice of address for IPv6 default gateway

Wed Jan 25 15:06:40 UTC 2012

In a message written on Wed, Jan 25, 2012 at 03:41:36PM +0100, Daniel STICKNEY wrote:
> I've seen some documentation using <prefix>::1 with either a global
> prefix or link-local (fe80::1). Anyone use either of these in production
> and have negative or positive feedback? fe80::1 is seductive because it
> is short and the idea of having the same default gateway configured
> everywhere might be simple. At the same time using the same address all
> around the network seems to invite confusion or problems if two
> interfaces with the address ever ended up in the same broadcast domain.

I don't think the industry has really found a best practice to
document yet.  There are people trying different ideas.  We find
the following convention allows us to keep things organized:

<prefix>::1                  - Default gateway
<prefix>::<last octect IPv4> - Statically assigned servers.
<prefix>:<eui-64>            - Auto-configured host

If you need them to co-exist, you can also do things like:

<prefix>::<10240-20480>        - DHCP Pool

And if a host learns a default gateway via RA, it will show up as
fe80::<eui-64> in the routing table.

A static server at 10.0.1.34 has an IPv6 address of <prefix>::34.
It's visually very easy for an admin to see everything is configured
correctly, and helps reduce confusion a lot when troubleshooting.
We use .1 in IPv4 for a default gateway, so ::1 similarly reduces
confusion.

> What about using RAs to install the default route on the servers? The
> 'priority' option (high/medium/low) easy fits with an architecture using
> an active/standby router setup where the active router is configured
> with the 'high' priority and the standby 'medium'. With the timeout
> values tuned for relatively rapid (~3 seconds)  failover this might be
> feasible. Anyone use this in production?

No.  We avoid RA's where possible, because of the "rogue RA" problem.
Rogue in this case usually means an admin fat fingering something
or plugging into the wrong port, not an actual, but it quickly
causes an outage.  Unless you happen to have new enough switches that
support RA Guard extreme care is warranted.  (Note, we're also a server
enviornment, not an end user one, and servers tend to end up
"statically" configured (possibly via script) anyway for reasons that
have nothing to do with IPv4 or IPv6.)

That said, it can be used where redundancy is required, and your routers
do not yet support the VRRP or HSRP protocols that support IPv6.

Generally speaking across the board we find it makes a lot of sense
to treat IPv6 as "IPv4 with bigger addresses", and do things the
same way as before.  That's not to say we don't take advantage of
/64's on LAN's, or RA's in some cases, but it reduces admin confusion
where you can make things operate the same way.  In a lot of cases,
like a default gateway of ::1, or a BGP policy that looks the same
config parity can be achieved and works out really well.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120125/66f6b372/attachment.sig>