[121710] in North American Network Operators' Group
Re: Using /126 for IPv6 router links
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Mon Jan 25 11:42:56 2010
Date: Mon, 25 Jan 2010 08:42:39 -0800
From: Leo Bicknell <bicknell@ufp.org>
To: nanog@nanog.org
Mail-Followup-To: nanog@nanog.org
In-Reply-To: <CDD0C3CC-8FAD-43D6-A3CF-C495EA6749FE@mironet.ch>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--+QahgC5+KEYLbs62
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In a message written on Mon, Jan 25, 2010 at 05:14:06PM +0100, Mathias Seil=
er wrote:
> Ok let's summarize:
>=20
> /64:
> + Sticks to the way IPv6 was designed (64 bits host part)
> + Probability of renumbering very low
> + simpler for ACLs and the like
> + rDNS on a bit boundary
>=20
> <> You can give your peers funny names, like 2001:db8::dead:beef ;)
>=20
> - Prone to attacks (scans, router CPU load)
> - "Waste" of addresses
> - Peer address needs to be known, impossible to guess with 2^64 addresses
/112:
+ 65535 possible addresses, can use a standardized subnet for everything
from a 2 router point to point, to a six address vrrp to vrrp dual
router static setup, and beyond. Becomes the universal "edge
interface" when the far end is routers not hosts.
+ rDNS bit boundary++, since it falls on a :.
+ Limits the effects of scan-like attacks.
+ Can set aside 1 /64 of /112's for, well, forever.
>=20
>=20
> /126
> + Only 4 addresses possible (memorable, not so error-prone at configurat=
ion-time and while debugging)
> + Not prone to scan-like attacks
>=20
> - Not on a bit boundary, so more complicated for ACLs and ?
> - ? rDNS
> - Perhaps need to renumber into /64 some time.
> - No 64 bits for hosts
>=20
>=20
> /127
> Like /126 but there's an RFC not recommending it and an RFC (draft) which=
revises that non-recommendation.
>=20
>=20
>=20
> On 25 Jan 2010, at 10:14, Matthew Petach wrote:
>=20
> > On Sat, Jan 23, 2010 at 4:52 AM, Mathias Seiler
> > <mathias.seiler@mironet.ch> wrote:
> >> Hi
> >> In reference to the discussion about /31 for router links, I d'like to=
know what is your experience with IPv6 in this regard.
> >>=20
> >> I use a /126 if possible but have also configured one /64 just for the=
link between two routers. This works great but when I think that I'm wasti=
ng 2^64 - 2 addresses here it feels plain wrong.
> >>=20
> >> So what do you think? Good? Bad? Ugly? /127 ? ;)
> >>=20
> >> Cheers
> >>=20
> >> Mathias Seiler
> >> MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel
> >> T +41 61 201 30 90, F +41 61 201 30 99
> >> mathias.seiler@mironet.ch
> >> www.mironet.ch
> >=20
> > As I mentioned in my lightning talk at the last NANOG, we reserved a
> > /64 for each
> > PtP link,
> > but configured it as the first /126 out of the /64. That
> > gives us the most
> > flexibility for expanding to the full /64 later if necessary, but
> > prevents us from being
> > victim of the classic v6 neighbor discovery attack that you're prone
> > to if you configure
> > the entire /64 on the link. =20
>=20
> I think I will go this way. Since we've got the usual /32 assignment I ha=
ve plenty of /64 to "waste".=20
> If I continue assigning a /48 to every customer I can set apart a /64 for=
each PtP link and still have room to grow for a very long time (I'm not ta=
king into account the assignment of IPv6 addresses to high amounts of M&Ms =
so far ;) )
>=20
> This way the configuration and addressing plan is simple and understandab=
le to anyone.=20
>=20
> > All someone out on the 'net needs to do
> > is scan up through
> > your address space on the link as quickly as possible, sending single p=
ackets at
> > all the non-existent addresses on the link, and watch as your router CP=
U starts
> > to churn keeping track of all the neighbor discovery messages, state ta=
ble
> > updates, and incomplete age-outs. =20
>=20
> Well I could filter that in hardware with an interface ACL but a /126 see=
ms much easier to maintain.=20
>=20
> > With the link configured as a /126, there's
> > a very small limit to the number of neighbor discovery messages, and th=
e amount
> > of state table that needs to be maintained and updated for each PtP lin=
k.
> >=20
> > It seemed like a reasonable approach for us--but there's more than one =
way to
> > skin this particular cat.
> >=20
> > Hope this helps!
> >=20
>=20
> Yes it does. Thanks!
>=20
>=20
> Mathias Seiler
>=20
> MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel
> T +41 61 201 30 90, F +41 61 201 30 99
>=20
> mathias.seiler@mironet.ch
> www.mironet.ch
>=20
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--+QahgC5+KEYLbs62
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.13 (FreeBSD)
iQIVAwUBS13J/7N3O8aJIdTMAQKBHxAAsSMk8k8nd4DWL5T7Oavv9v8ymj1wEn3v
il+HEXjBPJiLInxIea4M36zyd7E1LKF94u58JfQbTnH+yYg9WSxNfDNPahDGSK+W
17QuVhQn4BTwLtV5L4+ur8TYXa5Bk+osO8pLtpQojHAt4ndjacf05QnNmPWycUFR
i3e3GrFeZIgAcdTIr6glrdBa7uxkQua2j2KMVFsxCTuPRkMznyjJxZbDxV1RYn8u
evq15XUxiQ9wACpNuiqQbNITQZLCsanZ0rJ3uSxVpkBvtA1k7wTOlgIF6ib3xcgD
0EyGZVQIngz6g2Xh4T9WpqAdTqe4fRd7EzJSIx7U+r6vRzyAfGe5NkmCI0i4ZS+V
5ftpZLy1Q0U23cGMStI3SszXrRqzbrbzLCWxASkDc0xEu8p53Dslh8g1IiRK6Nfz
idgR6lNlZ0eV+LnAx8cH8aomVKKH3hPv91+NGB8wKzDCxZpGrNCEEqWLzxwjYItL
RmWt1bJz1M2CxKjEmhobIX91Gc8DfjLJxlGkIjaLL9l9ABnbQiDLJlZUjOPdSUga
w0n9y1UNqKoyABCBExTeLIrSN2rTOne4v1aFxSojRbRDDZeU4GtoWHChByWeIi8S
66yyjtzJDhmoolAM/cB3WTzaT+UQ43bSY/9qFyUpWO9sQ3tQr25t1rrdtncMLuwj
Kd/eyQZX3+E=
=YpFp
-----END PGP SIGNATURE-----
--+QahgC5+KEYLbs62--
