[148851] in North American Network Operators' Group
Re: Choice of address for IPv6 default gateway
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Wed Jan 25 10:07:04 2012
Date: Wed, 25 Jan 2012 07:06:40 -0800
From: Leo Bicknell <bicknell@ufp.org>
To: nanog@nanog.org
Mail-Followup-To: nanog@nanog.org
In-Reply-To: <4F2014A0.20008@optilian.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--6c2NcOVqGQ03X4Wi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In a message written on Wed, Jan 25, 2012 at 03:41:36PM +0100, Daniel STICK=
NEY 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.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--6c2NcOVqGQ03X4Wi
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
iQIVAwUBTyAagLN3O8aJIdTMAQJTLg/+JEC2O+5J4xMlsRmrtRIN0CdTGmTMcnpQ
nkj2sLl7gBTsN6EgcLk0Ud18M0xROTxX4N2RWRUw4kveL7JrDa2UFkgPeVTJDtJJ
xaU99TxKRA7BrHwv77Lo2CWD+BXWagpS8vSWyzj3k8WdSmevQx1fGiQsGU3Unkis
Rd4j6gb/62uaiqRaB0nbfv7ApW/D82dsshqPkJoSoXa4xjJeu6kF0+0ioZUc0g4k
7ec59Js20UzFI2GUPXOqWaGMcpQfIcX3oT5mH3Uq4Ext3WrpNcZz6SIyWGkQ1lWT
/7GADNS62XVUMMidbYs+OhWpfLizn5D4sxUh+J7aGqjRTl04rGmRa8RiH40BgIYs
CndiOQIehfdoq3bpde77D/VhpEYGQUrcg7T5xprx033qXfn45TlHhk3TtKsRTNVO
FvPW9knqOM3o5kvfx07ytGeqSMCdNRX/Or5Tw2MlZuBoY2RoNdpsmi+/CzWdX9ui
J0xWZSfUGmCyjITRxfNZMFKOLy9LpULC/8k2qRjlPepwxzPllXtOawGzTzaonzt1
NfNBLmEHKoUhJUVZ3R4L5mjtawA+qzV3Ep0T6iT7HTuHM7lFkmnxFPYqm0HnkDBi
rjxbuCmaTYp9wC/jp3YLkHy3wPFFcBLRggIawGXpQBSDxDLfH1o7nZueZSF64dEO
c89I1zenFFY=
=A+O4
-----END PGP SIGNATURE-----
--6c2NcOVqGQ03X4Wi--
