ISP customer assignments

[bicknell at ufp.org (Leo Bicknell)]

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).
> 
> 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.

-- 
       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/20091013/deacb74f/attachment.bin>