|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
From: Owen DeLong <owen@delong.com> Date: Tue, 1 Oct 2013 13:20:36 -0700 In-Reply-To: <CAEoCk-OXdhLunjg6RHmQYwHN9AqPxVUzjCYUYy_6spbqRmj9XQ@mail.gmail.com> To: Ryan McIntosh <rmcintosh@nitemare.net> Cc: NANOG <nanog@nanog.org> Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org The original plan was to go from 32 to 64 bits total. The additional 64 bits= were added purely for the sake of EUI-64 based addressing, and really, 64 b= its of network number is way more than enough.=20 The /64 a are not what justify the larger blocks. That's IPv4 think.=20 In IPv6, it is far better to think about the number of sinners without regar= d to counting hosts. The /48 per site is justified because it is almost inco= nceivable that a single site would ever need more than 65536 subnets.=20 The /32 is a minimum reasonable allocation for an ISP to balance the tradeof= f between routing table entries and consumption.=20 Most estimates say that the vast majority of significant providers will end u= p using a /28 with some outliers on both sides. Many smaller providers will e= nd up with /32 and a few medium to large ones will get /24 or even /20. A mi= nute (probably less than 20 world wide) number might get /16s.=20 Absent some novel (and IMHO I'll-advised) approach to semantic overloading, w= e will have plenty of address space to number the internet for many many yea= rs.=20 Owen > On Oct 1, 2013, at 12:11, Ryan McIntosh <rmcintosh@nitemare.net> wrote: >=20 > I'd love to be able to turn the microwave and oven on with my phone.. > maybe ten years from now lol.. >=20 > In all seriousness though (and after skimming some of the other > responses), I absolutely understand the ideals and needs amongst > conserving memory on our routers for the sake of the future of bgp and > internal routing. The problem I described has nothing to do with that > however, I was mearly pointing out the fact that the basis of the > larger allocations are based upon the fact we're handing over /64's to > each vlan/point to point/lan/etc that we're turning up. In practice, I > understand, a /64 means that 64 bits can handle a unique ip for every > host without having to worry about numbering them, but how many hosts > do we truly think will be sitting on one network? Surely not a /64's > worth, that alone would cause havoc on a neighbor table's maximum > memory limit. Maybe I'm missing the connection here, but I still don't > see how a /64 is justified for each individual user/host/server/etc > sitting on the edge of the internet that's getting ip's from an > upstream provider (not arin/ripe/etc). >=20 > It's those smaller blocks that justify handing over larger ones, which > I do understand there's plenty of, but how long are we going to patch > the same problem and not try to fix it right? >=20 > Ryan >=20 >> On Mon, Sep 30, 2013 at 8:37 PM, Larry Sheldon <LarrySheldon@cox.net> wro= te: >>> On 9/27/2013 1:10 AM, Ryan McIntosh wrote: >>>=20 >>> I don't respond to many of these threads but I have to say I've >>> contested this one too only to have to beaten into my head that a /64 >>> is "appropriate".. it still hasn't stuck, but unfortunately rfc's for >>> other protocols depend on the blocks to now be a /64.. >>>=20 >>> It's a waste, even if we're "planning for the future", no one house >>> needs a /64 sitting on their lan.. or at least none I can sensibly >>> think of o_O. >>=20 >>=20 >>=20 >> Are you accounting for connections to your refrigerator, water heater, >> razor, vibrator, and on down to list so the gubermint can tell they when y= ou >> can use power for them? >>=20 >> -- >> Requiescas in pace o email Two identifying characteristics >> of System Administrators: >> Ex turpi causa non oritur actio Infallibility, and the ability to >> learn from their mistakes. >> (Adapted from Stephen Pinker) >>=20
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |