Re: minimum IPv6 announcement size
On 9/27/2013 1:10 AM, Ryan McIntosh wrote:
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..
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.
Are you accounting for connections to your refrigerator, water heater, razor, vibrator, and on down to list so the gubermint can tell they when you can use power for them? -- 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)
I'd love to be able to turn the microwave and oven on with my phone.. maybe ten years from now lol.. 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). 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? Ryan On Mon, Sep 30, 2013 at 8:37 PM, Larry Sheldon <LarrySheldon@cox.net> wrote:
On 9/27/2013 1:10 AM, Ryan McIntosh wrote:
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..
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.
Are you accounting for connections to your refrigerator, water heater, razor, vibrator, and on down to list so the gubermint can tell they when you can use power for them?
-- 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)
back in the good o'l days when we would hand out 24 bits for the number of hosts in a network. It was too many bits then and is too many bits now.... a /64 is just overkill. /bill On Tue, Oct 01, 2013 at 03:11:39PM -0400, Ryan McIntosh wrote:
I'd love to be able to turn the microwave and oven on with my phone.. maybe ten years from now lol..
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).
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?
Ryan
On Mon, Sep 30, 2013 at 8:37 PM, Larry Sheldon <LarrySheldon@cox.net> wrote:
On 9/27/2013 1:10 AM, Ryan McIntosh wrote:
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..
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.
Are you accounting for connections to your refrigerator, water heater, razor, vibrator, and on down to list so the gubermint can tell they when you can use power for them?
-- 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)
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 bits of network number is way more than enough. The /64 a are not what justify the larger blocks. That's IPv4 think. In IPv6, it is far better to think about the number of sinners without regard to counting hosts. The /48 per site is justified because it is almost inconceivable that a single site would ever need more than 65536 subnets. The /32 is a minimum reasonable allocation for an ISP to balance the tradeoff between routing table entries and consumption. Most estimates say that the vast majority of significant providers will end up using a /28 with some outliers on both sides. Many smaller providers will end up with /32 and a few medium to large ones will get /24 or even /20. A minute (probably less than 20 world wide) number might get /16s. Absent some novel (and IMHO I'll-advised) approach to semantic overloading, we will have plenty of address space to number the internet for many many years. Owen
On Oct 1, 2013, at 12:11, Ryan McIntosh <rmcintosh@nitemare.net> wrote:
I'd love to be able to turn the microwave and oven on with my phone.. maybe ten years from now lol..
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).
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?
Ryan
On Mon, Sep 30, 2013 at 8:37 PM, Larry Sheldon <LarrySheldon@cox.net> wrote:
On 9/27/2013 1:10 AM, Ryan McIntosh wrote:
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..
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.
Are you accounting for connections to your refrigerator, water heater, razor, vibrator, and on down to list so the gubermint can tell they when you can use power for them?
-- 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)
I try not to think about sinners too much when planning networks. Subnets are more interesting. Maybe many of you like spending time maintaining NAT configurations and creatively masking as determined by today's end system count on each subnet. This all, of course, in the interest of maximum address assignment efficiency, a term of only the most nebulous definition. Hogwash, I say. The days of counting end systems in order to determine addressing is GONE. And I, for one, am much pleased. Let's optimize the person instead of micro-optimizing bits. Count the subnets you really think you need, shift one or two bits left, and ask for /whatever as described by Owen. "many many years" is probably multiples of the two decades or so of IPv4 we have experienced. Continuing arguments on NANOG and elsewhere about /64 - Good or Bad - check one, are just wasting your time and mine. Get yourself into action and just get IPv6 deployed. Owen has the right of it. Cutler On Oct 1, 2013, at 4:20 PM, Owen DeLong <owen@delong.com> wrote:
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 bits of network number is way more than enough.
The /64 a are not what justify the larger blocks. That's IPv4 think.
In IPv6, it is far better to think about the number of sinners without regard to counting hosts. The /48 per site is justified because it is almost inconceivable that a single site would ever need more than 65536 subnets.
The /32 is a minimum reasonable allocation for an ISP to balance the tradeoff between routing table entries and consumption.
Most estimates say that the vast majority of significant providers will end up using a /28 with some outliers on both sides. Many smaller providers will end up with /32 and a few medium to large ones will get /24 or even /20. A minute (probably less than 20 world wide) number might get /16s.
Absent some novel (and IMHO I'll-advised) approach to semantic overloading, we will have plenty of address space to number the internet for many many years.
Owen
On Oct 1, 2013, at 12:11, Ryan McIntosh <rmcintosh@nitemare.net> wrote:
I'd love to be able to turn the microwave and oven on with my phone.. maybe ten years from now lol..
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).
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?
Ryan
On Mon, Sep 30, 2013 at 8:37 PM, Larry Sheldon <LarrySheldon@cox.net> wrote:
On 9/27/2013 1:10 AM, Ryan McIntosh wrote:
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..
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.
Are you accounting for connections to your refrigerator, water heater, razor, vibrator, and on down to list so the gubermint can tell they when you can use power for them?
-- 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)
participants (5)
-
bmanning＠vacation.karoshi.com -
Cutler James R -
Larry Sheldon -
Owen DeLong -
Ryan McIntosh