[118196] in North American Network Operators' Group
Re: ISP customer assignments
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Tue Oct 13 20:48:52 2009
Date: Tue, 13 Oct 2009 17:48:17 -0700
From: Leo Bicknell <bicknell@ufp.org>
To: nanog@nanog.org
Mail-Followup-To: nanog@nanog.org
In-Reply-To: <20091013232620.GB612455@hiwaay.net>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--OXfL5xGRrasGEqWY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In a message written on Tue, Oct 13, 2009 at 06:26:20PM -0500, Chris Adams =
wrote:
> The author feels that if /64 cannot be used, /112, reserving the last
> 16 bits for node identifiers, has probably the least amount of
> drawbacks (also see section 3).
>=20
> I guess I'm missing something; what in section 3 is this referring to?
> I can understand /64 or /126 (or maybe /124 if you were going to
> delegate reverse DNS?), but why /112 and "16 bits for node identifiers"
> on a point-to-point link?
We use /112's, and do so for two (and a half) reasons:
1) If you think of all possible "network to network" interconnects
they include the simple case like a single router on both ends,
but they also include cases like two routers on one or both ends,
and optionally with VRRP/HSRP. Maximally it appears 6 IP's
may be required (two routers both ends, plus vrrp on each,
statics at the VRRP).
So it makes sense to have a 8 or 16 block of IP's per link so you
never have to renumber the link if you switch these configurations.
2) Colon's separate 16 bit chunks in IPv6. /112's allow XXXX::1,
XXXX::2 to be your IP's.
The half a reason, if you have a /64 dedicate to point to point
links, and use /112's, you have 2^(112-64) possible links. That's
281 trillion point to point links. Given 1, and 2, and the numbers
/127's, /126's, /125's don't make any sense when you can standardize
on one size fits all, and never run out.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--OXfL5xGRrasGEqWY
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.13 (FreeBSD)
iQIVAwUBStUf0bN3O8aJIdTMAQKKfw//foXnWBd8jch4V3UCE0i0GHw6TzrcQm9h
s9zuw8qXEK0f5KRfWUvyZv7gQCFFdi5HcRORzMZOOYe+3Bo1xQf246Hyl5SntLbl
xoTDmYJTBiFEl/dfLiycgACUu20TOOuiiaETWMYYavQhIxcFo86Qq7v1qK2skAXo
slrUoA5FRbMZiIo0A/bP7LXiXy7n0Y0POb9cWr3OYOTRctYT7s/MFIac+NR7hz0t
h/oMMATfqp7tazyuygXabyAxFUv+c+H+3uCHBefjbeKVOzb/DwcPgrmgWF9ceseq
b6GEFCeSdjZPUbxDmnI/N3L0Lro5ckhayYXltKocaTRPJc6Nz8ZzUpzaNitbpwKW
0M75jOMxNQr0IvbwV+Odr9MssImLrJQHoPMiW7nT0v2ul9RcQ57Qn9Y9+FIPBzPG
lvPRN0+xJMaL4dSC7YCimqc2HRxYRA0U8cJuTQ8FBh3s1bic6a0jLJC/9hzku1PI
LqsKOx3ka59VAtiiGUvCE8N82dO6l2bL7hnMO8zKdGdvyGqW6WNiXIijvqfjoEtV
fTuzEqCpd96k6EXJa9lRZZwxAb4JTMwXk2SyGdkK1gN+bFCoREhqbBYcJn34DbBL
UL6wwIUd4WgSjhtKfbbBV9zhA7a43TH5biHHXRcYNRBi1/qMCruLNYzX1XDfkNOa
KfbBt2NrjAg=
=caiE
-----END PGP SIGNATURE-----
--OXfL5xGRrasGEqWY--
