Dual stack IPv6 for IPv4 depletion

Doug Barton dougb at dougbarton.us
Wed Jul 15 21:02:12 UTC 2015


On 7/15/15 1:48 PM, Valdis.Kletnieks at vt.edu wrote:
> On Wed, 15 Jul 2015 16:23:36 -0400, "Ricky Beam" said:
>
>> What seems like a great idea today becomes tomorrow's "what the f*** were
>> they thinking".
>
> However, this statement doesn't provide any actual guidance, as it's
> potentially equally applicable to the "give each end customer a /48" crew and
> the "Give them all a /56" crew.....
>
> Actually, not true - in fact, it's demonstrable that a residential customer
> can run through a /56.  Just get a largish house, put up one router using
> CeroWRT (or, I suspect a current/recent OpenWRT) that burns through 6-7 subnet
> allocations), and then put a second one at the other end of the house and
> it burns through 6-7.  The second one has to dhcp-pd request at least 3 bits
> for itself, which leaves the first one only 5 bits, of which *it* will burn
> at least 3.  If you create any VLANs at all, you just burned 4 and 4 bits,
> and there goes that /56.
>
> And that's burned all the subnets in a /56 *just hooking up 2 plug and play
> routers*.  There's none left for doing anything experimental/different.
>
> (And I suspect Dave Taht can provide several CeroWRT config checkboxes that
> will each burn another 1-3 bits each if you click on them and hit "apply" :)

I tend to think that you're correct here, Validis; which is why I 
suggest reserving the /48 per customer whatever they decide to assign. I 
think the problem of expanding the assignment to a more reasonable size 
will happen on its own since at some point the support calls for "hey, I 
need more space!" will become a burden.

Doug

-- 
I am conducting an experiment in the efficacy of PGP/MIME signatures. 
This message should be signed. If it is not, or the signature does not 
validate, please let me know how you received this message (direct, or 
to a list) and the mail software you use. Thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20150715/7208160c/attachment.sig>


More information about the NANOG mailing list