Re: minimum IPv6 announcement size
William Herrin b...@herrin.us writes: IPv4 jumped from 8 bits to 32 bits. Which when you think about it is the same ratio as jumping from 32 bits to 128 bits. Sorry for the late reply, Bill, but you were snoozing when they taught logarithms in high school weren't you? Jumping from 8 bits to 32 bits (1:16mm) is the same ratio as would be jumping from 32 bits to 48 bits (also, 1:16mm). Going from 32 bits to 128 bits is 1:79228162514264337593543950336 which is not even remotely the same ratio. -r
Re: minimum IPv6 announcement size
On Tue, Oct 1, 2013 at 12:04 PM, Rob Seastrom r...@seastrom.com wrote: William Herrin b...@herrin.us writes: IPv4 jumped from 8 bits to 32 bits. Which when you think about it is the same ratio as jumping from 32 bits to 128 bits. Jumping from 8 bits to 32 bits (1:16mm) is the same ratio as would be jumping from 32 bits to 48 bits (also, 1:16mm). Hi Rob, And yet we're allocating /19's where previously we allocated space that added up to /7's and /48's where previously we allocated /24's. My math may be flawed but the pattern is there all the same. Going from 32 bits to 128 bits is 1:79228162514264337593543950336 which is not even remotely the same ratio. You know enough about IPv6 to realize that we didn't go from 32 bits to 128 bits, we went from either 24ish bits to 48 or 28ish bits to 64, depending on how you look at it. While IPv6 is capable of working the same as IPv4, that's not how we're actually using it. More, growth has not been linear since IPv4's advent and is not (by anyone reasonable) projected to be linear or sub-linear in IPv6. Computing a linear ratio as if that were representative of the expected lifetime of the new address space does not paint an honest picture. Sorry for the late reply, Bill, but you were snoozing when they taught logarithms in high school weren't you? While I did in fact snooze my way through a significant part of school, I was wide awake for the word problems where we were asked to build an appropriate equation. You remember: the trick questions where a couple of irrelevant bits of data were thrown in and critical factors were implied without being stated. And despite the distractions you were asked to grasp the essential problem from the English language description. Those were fun. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: minimum IPv6 announcement size
On Oct 1, 2013, at 11:11 , William Herrin b...@herrin.us wrote: On Tue, Oct 1, 2013 at 12:04 PM, Rob Seastrom r...@seastrom.com wrote: William Herrin b...@herrin.us writes: IPv4 jumped from 8 bits to 32 bits. Which when you think about it is the same ratio as jumping from 32 bits to 128 bits. Jumping from 8 bits to 32 bits (1:16mm) is the same ratio as would be jumping from 32 bits to 48 bits (also, 1:16mm). Hi Rob, And yet we're allocating /19's where previously we allocated space that added up to /7's and /48's where previously we allocated /24's. My math may be flawed but the pattern is there all the same. Not exactly... We're allocating /16s and/or /20s where previously we allocated space that added up to /7's, but, the holders of the /7s were coming back for more and more on a regular basis. I don't believe anyone holding a /16 or /20 of IPv6 has come back for another allocation at all and I would be surprised if such an organization were to do so in the next 5 years or so. We're allocating /48s where previously we allocated roughly /16-/24. Any effort at making direct comparisons between IPv4 and IPv6 number utilization is flawed because there is, by definition, nothing approximating a simple ratio between the two. Going from 32 bits to 128 bits is 1:79228162514264337593543950336 which is not even remotely the same ratio. You know enough about IPv6 to realize that we didn't go from 32 bits to 128 bits, we went from either 24ish bits to 48 or 28ish bits to 64, depending on how you look at it. While IPv6 is capable of working the same as IPv4, that's not how we're actually using it. Both of those estimates are also flawed. More, growth has not been linear since IPv4's advent and is not (by anyone reasonable) projected to be linear or sub-linear in IPv6. Computing a linear ratio as if that were representative of the expected lifetime of the new address space does not paint an honest picture. Nor does any effort to apply a simple ratio between IPv4 and IPv6. There are sufficient differences in the allocation algorithms and counting methods between the two that an apples to apples comparison of allocation policies simply isn't possible. Owen
RE: minimum IPv6 announcement size
William Herrin wrote: [...] And yet we're allocating /19's If the stats published at http://www.nro.net/pub/stats/nro/delegated-extended are to be believed then the only two /19s were allocated in 2005 when the HD-ratio value in the policy was lower. Looking at all the RIRs together another nine /20s have been allocated and seven /21s. There are just 51 allocations of /22 of shorter prefixes. Given that almost 17,000 IPv6 blocks have been issued, those 51 blocks are really just a fraction of a percent and seem to represent the exception and not the norm. Leo smime.p7s Description: S/MIME cryptographic signature
TWC / MTC broadband
Anyone alive at TWC and/or MTC broadband? Looks like AS36100 (MTC Broadband) is incorrectly announcing 72.43.125.0/24. This is causing problems for TWC users who are in 72.43.125.0/24 -- Tim:
Re: minimum IPv6 announcement size
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 larryshel...@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)
semi-ot: network monitoring tools
I was talking to a bunch of people who run ISPs and other networks in LDCs (yes, including Nigeria) and someone asked about monitoring tools to watch traffic on his network so he can get advance warning of dodgy customers and prevent complaints and blacklisting. These people are plenty smart, but don't have a lot of money. Suggestions welcome. R's, John
Re: minimum IPv6 announcement size
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 larryshel...@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)
Re: minimum IPv6 announcement size
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 rmcint...@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 larryshel...@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)
Re: minimum IPv6 announcement size
--- o...@delong.com wrote: From: Owen DeLong o...@delong.com we will have plenty of address space to number the internet for many many years. -- You can't know the future and what addressing requirements it'll bring: I have to say that in 1981, making those decisions, I felt like I was providing enough freedom for 10 years. That is, a move from 64k to 640k felt like something that would last a great deal of time. Well, it didn't - it took about only 6 years before people started to see that as a real problem. scott
Re: minimum IPv6 announcement size
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 o...@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 rmcint...@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 larryshel...@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)
Re: semi-ot: network monitoring tools
On 10/01/2013 02:29 PM, John Levine wrote: I was talking to a bunch of people who run ISPs and other networks in LDCs (yes, including Nigeria) and someone asked about monitoring tools to watch traffic on his network so he can get advance warning of dodgy customers and prevent complaints and blacklisting. These people are plenty smart, but don't have a lot of money. Suggestions welcome. I'd say it's on topic. OpenNMS has good community support, as well as reasonably priced commercial support - http://www.opennms.org/ I've used OpenNMS for years and it keeps getting better. -- Kind regards, Michael
Facebook NOC Contact
Hi, Having some issues with traffic to Facebook. Is there anyone here from Facebook lurking on the list? Or does anyone have a better contact then their help form? Regards, Daniel
Re: Facebook NOC Contact
On Tue, 1 Oct 2013, Daniel Hood wrote: Having some issues with traffic to Facebook. Is there anyone here from Facebook lurking on the list? Or does anyone have a better contact then their help form? Try o...@facebook.com jms
Re: semi-ot: network monitoring tools
On Oct 2, 2013, at 2:29 AM, John Levine wrote: These people are plenty smart, but don't have a lot of money. Enable NetFlow, and use some open-source NetFlow collection/analysis system like nfdump/nfsen, etc. dnstop and the like for DNS can be pretty revealing, as well. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: semi-ot: network monitoring tools
Coworkers of mine introduced me to Observium: http://www.observium.org/wiki/Main_Page Cheers, Ryan On Tue, Oct 1, 2013 at 8:55 PM, Dobbins, Roland rdobb...@arbor.net wrote: On Oct 2, 2013, at 2:29 AM, John Levine wrote: These people are plenty smart, but don't have a lot of money. Enable NetFlow, and use some open-source NetFlow collection/analysis system like nfdump/nfsen, etc. dnstop and the like for DNS can be pretty revealing, as well. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
