Re: Sad IPv4 story?
Sent from my iPhone On Dec 10, 2011, at 2:58 AM, Randy Bush ra...@psg.com wrote: I just had a personal email from a brand new ISP in the Asia-Pacific area desperately looking for enough IPv4 to be able to run their business the way they would like… and we are supposed to be surprised or feel sorry? you're kidding, right? they're lucky to be in a/p. at least they can get a /22. i especially like the the way they would like part. the way i would like to run my business is to go into the office every friday and scoop up the cash that fell from the sky all week. reality is such a pain in the ass. randy +1 aren't we way past all of the predicted exhaustion dates. There are slot of as's that have ignored this.
Local Loop at Singapore
Hi anyone have a contact of a local telco for buy a link in metro of the Singapore City ? We want connect a customer based at singapore to our rack of Equinix or * I-Advantage Thanks for your help best regards Olivier *
Re: Sad IPv4 story?
2011/12/10 bmann...@vacation.karoshi.com On Sat, Dec 10, 2011 at 03:15:01AM -0500, Keegan Holley wrote: Sent from my iPhone On Dec 10, 2011, at 2:58 AM, Randy Bush ra...@psg.com wrote: I just had a personal email from a brand new ISP in the Asia-Pacific area desperately looking for enough IPv4 to be able to run their business the way they would likeb and we are supposed to be surprised or feel sorry? you're kidding, right? they're lucky to be in a/p. at least they can get a /22. i especially like the the way they would like part. the way i would like to run my business is to go into the office every friday and scoop up the cash that fell from the sky all week. reality is such a pain in the ass. randy +1 aren't we way past all of the predicted exhaustion dates. There are slot of as's that have ignored this. predictions are ... predictions! guesses. swag. nothing more/less. i will say this however. after fifteen years, I am exhausted listening to ipv6 v. ipv4 bickering. (and after five years of running native ipv6-only networks - i've re-introduced ipv4 to the mix... go figure) /bill I see your point. The world was supposed to end dozens of times as well. Sorry to hear you had to reintroduce v4. I suppose if dinosaurs were still around we'd have to capitulate to them too. The people who see a T-rex and say hey I thought they were extinct?! would just get eaten. but I digress. I'm not sure I'd open a new ISP at this point and expect to get any respectable amount of IP space from the RIR right now.
Re: Sad IPv4 story?
On Sat, Dec 10, 2011 at 11:17:32AM -0500, Keegan Holley wrote: 2011/12/10 bmann...@vacation.karoshi.com On Sat, Dec 10, 2011 at 03:15:01AM -0500, Keegan Holley wrote: Sent from my iPhone On Dec 10, 2011, at 2:58 AM, Randy Bush ra...@psg.com wrote: I just had a personal email from a brand new ISP in the Asia-Pacific area desperately looking for enough IPv4 to be able to run their business the way they would likeb and we are supposed to be surprised or feel sorry? you're kidding, right? they're lucky to be in a/p. at least they can get a /22. i especially like the the way they would like part. the way i would like to run my business is to go into the office every friday and scoop up the cash that fell from the sky all week. reality is such a pain in the ass. randy +1 aren't we way past all of the predicted exhaustion dates. There are slot of as's that have ignored this. predictions are ... predictions! guesses. swag. nothing more/less. i will say this however. after fifteen years, I am exhausted listening to ipv6 v. ipv4 bickering. (and after five years of running native ipv6-only networks - i've re-introduced ipv4 to the mix... go figure) /bill I see your point. The world was supposed to end dozens of times as well. Sorry to hear you had to reintroduce v4. I suppose if dinosaurs were still around we'd have to capitulate to them too. The people who see a T-rex and say hey I thought they were extinct?! would just get eaten. but I digress. I'm not sure I'd open a new ISP at this point and expect to get any respectable amount of IP space from the RIR right now. funny thing about tools. good ones are around and used for years, decades, centuries, while others have a much shorter shelf life. the craftsman 3/16 and the 1/4 phillips I got from my grandfather and will likely end up w/ one of my grandsons. the pocket fisherman and the 87blade pocket knife are ebay fodder... its not about capitulation, its about usefullness. the only concern about IPv4 these days is one of global uniqueness. the big win, if you can call it a big win is that there is much less potential pressure on the global routing table if you stick w/ IPv4. (*) * in both v4/v6 families, the prospect of fully routing /32s scares to socks off most sane engineers. the horror of v6 is fully routing /48s /bill
Inaccessible network from Verizon, accessible elsewhere.
I have a Linode VPS in Japan that I can't access from Verizon FIOS, but can access from other locations. I'm not sure who to blame. The host, 106.187.34.33, is behind the gateway 106.187.34.1: From FIOS to 106.187.34.1 (this works). traceroute to 106.187.34.1 (106.187.34.1), 64 hops max, 52 byte packets 4 so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4) 9.960 ms 9.957 ms 6.666 ms 5 so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3) 12.298 ms 13.463 ms 13.706 ms 6 0.ae2.br1.iad8.alter.net (152.63.32.158) 14.571 ms 14.372 ms 14.003 ms 7 204.255.169.218 (204.255.169.218) 14.692 ms 14.759 ms 13.670 ms 8 sl-crs1-dc-0-1-0-0.sprintlink.net (144.232.19.229) 13.077 ms 12.577 ms 14.954 ms 9 sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200) 31.443 ms sl-crs1-dc-0-5-3-0.sprintlink.net (144.232.24.37) 33.005 ms sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200) 31.507 ms 10 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 57.610 ms 58.322 ms 59.098 ms 11 otejbb204.kddnet.ad.jp (203.181.100.45) 196.063 ms otejbb203.kddnet.ad.jp (203.181.100.13) 188.846 ms otejbb204.kddnet.ad.jp (203.181.100.21) 195.277 ms 12 cm-fcu203.kddnet.ad.jp (124.215.194.180) 214.760 ms cm-fcu203.kddnet.ad.jp (124.215.194.164) 198.925 ms cm-fcu203.kddnet.ad.jp (124.215.194.180) 200.583 ms 13 124.215.199.122 (124.215.199.122) 193.086 ms * 194.967 ms This does not work from FIOS: traceroute to 106.187.34.33 (106.187.34.33), 64 hops max, 52 byte packets 4 so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4) 34.229 ms 8.743 ms 8.878 ms 5 so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3) 15.402 ms 13.008 ms 14.932 ms 6 0.ae2.br1.iad8.alter.net (152.63.32.158) 13.325 ms 13.245 ms 13.802 ms 7 204.255.169.218 (204.255.169.218) 14.820 ms 14.232 ms 13.491 ms 8 lap-brdr-03.inet.qwest.net (67.14.22.78) 90.170 ms 92.273 ms 145.887 ms 9 63.146.26.70 (63.146.26.70) 92.482 ms 92.287 ms 94.000 ms 10 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 58.135 ms 58.520 ms 58.055 ms 11 otejbb203.kddnet.ad.jp (203.181.100.17) 205.844 ms otejbb204.kddnet.ad.jp (203.181.100.25) 189.929 ms otejbb203.kddnet.ad.jp (203.181.100.17) 204.846 ms 12 sl-crs1-oro-0-1-5-0.sprintlink.net (144.232.25.77) 87.229 ms sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207) 88.796 ms 88.717 ms 13 124.215.199.122 (124.215.199.122) 193.584 ms 202.208 ms 192.989 ms 14 * * * Same IP from different network: traceroute to 106.187.34.33 (106.187.34.33), 30 hops max, 60 byte packets 6 ae-8-8.ebr2.Washington1.Level3.net (4.69.134.105) 2.230 ms 1.847 ms 1.938 ms 7 ae-92-92.csw4.Washington1.Level3.net (4.69.134.158) 2.010 ms 1.985 ms ae-62-62.csw1.Washington1.Level3.net (4.69.134.146) 1.942 ms 8 ae-94-94.ebr4.Washington1.Level3.net (4.69.134.189) 12.515 ms ae-74-74.ebr4.Washington1.Level3.net (4.69.134.181) 12.519 ms 12.507 ms 9 ae-4-4.ebr3.LosAngeles1.Level3.net (4.69.132.81) 65.957 ms 65.958 ms 66.056 ms 10 ae-83-83.csw3.LosAngeles1.Level3.net (4.69.137.42) 66.063 ms ae-93-93.csw4.LosAngeles1.Level3.net (4.69.137.46) 65.985 ms ae-63-63.csw1.LosAngeles1.Level3.net (4.69.137.34) 66.026 ms 11 ae-3-80.edge2.LosAngeles9.Level3.net (4.69.144.143) 66.162 ms 66.160 ms 66.238 ms 12 KDDI-AMERIC.edge2.LosAngeles9.Level3.net (4.53.228.14) 193.317 ms 193.447 ms 193.305 ms 13 lajbb001.kddnet.ad.jp (59.128.2.101) 101.544 ms 101.543 ms lajbb002.kddnet.ad.jp (59.128.2.185) 66.563 ms 14 otejbb203.kddnet.ad.jp (203.181.100.13) 164.217 ms 164.221 ms 164.330 ms 15 cm-fcu203.kddnet.ad.jp (124.215.194.164) 180.350 ms cm-fcu203.kddnet.ad.jp (124.215.194.180) 172.779 ms cm-fcu203.kddnet.ad.jp (124.215.194.164) 185.824 ms 16 124.215.199.122 (124.215.199.122) 175.703 ms 175.700 ms 168.268 ms 17 li377-33.members.linode.com (106.187.34.33) 174.381 ms 174.383 ms 174.368 ms The last hop is KDDI, but things work from via Level3 and not sprint. Linode blames Verizon, but I'm not seeing how it's them. Any ideas?
Re: Inaccessible network from Verizon, accessible elsewhere.
Do you have a firewall running on the Linode VPS? Any chance something like fail2ban blocked your IP for too many invalid logins? Are you able to ping your FIOS IP from the VPS? Try doing a traceroute on the VPS to your FIOS IP. Perhaps there is some issue getting back to you. Based on the traceroutes you provided, it doesn't look like Verizon's issue. Derek On 12/10/2011 2:49 PM, NetSecGuy wrote: I have a Linode VPS in Japan that I can't access from Verizon FIOS, but can access from other locations. I'm not sure who to blame. The host, 106.187.34.33, is behind the gateway 106.187.34.1: From FIOS to 106.187.34.1 (this works). traceroute to 106.187.34.1 (106.187.34.1), 64 hops max, 52 byte packets 4 so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4) 9.960 ms 9.957 ms 6.666 ms 5 so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3) 12.298 ms 13.463 ms 13.706 ms 6 0.ae2.br1.iad8.alter.net (152.63.32.158) 14.571 ms 14.372 ms 14.003 ms 7 204.255.169.218 (204.255.169.218) 14.692 ms 14.759 ms 13.670 ms 8 sl-crs1-dc-0-1-0-0.sprintlink.net (144.232.19.229) 13.077 ms 12.577 ms 14.954 ms 9 sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200) 31.443 ms sl-crs1-dc-0-5-3-0.sprintlink.net (144.232.24.37) 33.005 ms sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200) 31.507 ms 10 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 57.610 ms 58.322 ms 59.098 ms 11 otejbb204.kddnet.ad.jp (203.181.100.45) 196.063 ms otejbb203.kddnet.ad.jp (203.181.100.13) 188.846 ms otejbb204.kddnet.ad.jp (203.181.100.21) 195.277 ms 12 cm-fcu203.kddnet.ad.jp (124.215.194.180) 214.760 ms cm-fcu203.kddnet.ad.jp (124.215.194.164) 198.925 ms cm-fcu203.kddnet.ad.jp (124.215.194.180) 200.583 ms 13 124.215.199.122 (124.215.199.122) 193.086 ms * 194.967 ms This does not work from FIOS: traceroute to 106.187.34.33 (106.187.34.33), 64 hops max, 52 byte packets 4 so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4) 34.229 ms 8.743 ms 8.878 ms 5 so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3) 15.402 ms 13.008 ms 14.932 ms 6 0.ae2.br1.iad8.alter.net (152.63.32.158) 13.325 ms 13.245 ms 13.802 ms 7 204.255.169.218 (204.255.169.218) 14.820 ms 14.232 ms 13.491 ms 8 lap-brdr-03.inet.qwest.net (67.14.22.78) 90.170 ms 92.273 ms 145.887 ms 9 63.146.26.70 (63.146.26.70) 92.482 ms 92.287 ms 94.000 ms 10 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 58.135 ms 58.520 ms 58.055 ms 11 otejbb203.kddnet.ad.jp (203.181.100.17) 205.844 ms otejbb204.kddnet.ad.jp (203.181.100.25) 189.929 ms otejbb203.kddnet.ad.jp (203.181.100.17) 204.846 ms 12 sl-crs1-oro-0-1-5-0.sprintlink.net (144.232.25.77) 87.229 ms sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207) 88.796 ms 88.717 ms 13 124.215.199.122 (124.215.199.122) 193.584 ms 202.208 ms 192.989 ms 14 * * * Same IP from different network: traceroute to 106.187.34.33 (106.187.34.33), 30 hops max, 60 byte packets 6 ae-8-8.ebr2.Washington1.Level3.net (4.69.134.105) 2.230 ms 1.847 ms 1.938 ms 7 ae-92-92.csw4.Washington1.Level3.net (4.69.134.158) 2.010 ms 1.985 ms ae-62-62.csw1.Washington1.Level3.net (4.69.134.146) 1.942 ms 8 ae-94-94.ebr4.Washington1.Level3.net (4.69.134.189) 12.515 ms ae-74-74.ebr4.Washington1.Level3.net (4.69.134.181) 12.519 ms 12.507 ms 9 ae-4-4.ebr3.LosAngeles1.Level3.net (4.69.132.81) 65.957 ms 65.958 ms 66.056 ms 10 ae-83-83.csw3.LosAngeles1.Level3.net (4.69.137.42) 66.063 ms ae-93-93.csw4.LosAngeles1.Level3.net (4.69.137.46) 65.985 ms ae-63-63.csw1.LosAngeles1.Level3.net (4.69.137.34) 66.026 ms 11 ae-3-80.edge2.LosAngeles9.Level3.net (4.69.144.143) 66.162 ms 66.160 ms 66.238 ms 12 KDDI-AMERIC.edge2.LosAngeles9.Level3.net (4.53.228.14) 193.317 ms 193.447 ms 193.305 ms 13 lajbb001.kddnet.ad.jp (59.128.2.101) 101.544 ms 101.543 ms lajbb002.kddnet.ad.jp (59.128.2.185) 66.563 ms 14 otejbb203.kddnet.ad.jp (203.181.100.13) 164.217 ms 164.221 ms 164.330 ms 15 cm-fcu203.kddnet.ad.jp (124.215.194.164) 180.350 ms cm-fcu203.kddnet.ad.jp (124.215.194.180) 172.779 ms cm-fcu203.kddnet.ad.jp (124.215.194.164) 185.824 ms 16 124.215.199.122 (124.215.199.122) 175.703 ms 175.700 ms 168.268 ms 17 li377-33.members.linode.com (106.187.34.33) 174.381 ms 174.383 ms 174.368 ms The last hop is KDDI, but things work from via Level3 and not sprint. Linode blames Verizon, but I'm not seeing how it's them. Any ideas?
Re: Inaccessible network from Verizon, accessible elsewhere.
Am 10.12.2011 um 20:49 schrieb NetSecGuy: This does not work from FIOS: traceroute to 106.187.34.33 (106.187.34.33), 64 hops max, 52 byte packets 4 so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4) 34.229 ms 8.743 ms 8.878 ms 5 so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3) 15.402 ms 13.008 ms 14.932 ms 6 0.ae2.br1.iad8.alter.net (152.63.32.158) 13.325 ms 13.245 ms 13.802 ms 7 204.255.169.218 (204.255.169.218) 14.820 ms 14.232 ms 13.491 ms 8 lap-brdr-03.inet.qwest.net (67.14.22.78) 90.170 ms 92.273 ms 145.887 ms 9 63.146.26.70 (63.146.26.70) 92.482 ms 92.287 ms 94.000 ms 10 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 58.135 ms 58.520 ms 58.055 ms 11 otejbb203.kddnet.ad.jp (203.181.100.17) 205.844 ms otejbb204.kddnet.ad.jp (203.181.100.25) 189.929 ms otejbb203.kddnet.ad.jp (203.181.100.17) 204.846 ms 12 sl-crs1-oro-0-1-5-0.sprintlink.net (144.232.25.77) 87.229 ms sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207) 88.796 ms 88.717 ms 13 124.215.199.122 (124.215.199.122) 193.584 ms 202.208 ms 192.989 ms 14 * * * From FIOS in BOS: 3 g14-0-7-1544.bstnma-lcr-05.verizon-gni.net (130.81.49.80) 132.408 ms 130.742 ms 139.945 ms 4 so-7-2-0-0.bos-bb-rtr1.verizon-gni.net (130.81.29.172) 132.405 ms 137.776 ms 134.929 ms 5 so-9-1-0-0.ny325-bb-rtr1.verizon-gni.net (130.81.19.70) 139.872 ms 141.344 ms 150.117 ms 6 0.so-0-0-0.xt1.nyc4.alter.net (152.63.1.41) 142.381 ms 141.256 ms 139.873 ms 7 0.ae3.br2.nyc4.alter.net (152.63.3.110) 169.904 ms 169.769 ms 167.357 ms 8 nyc-brdr-02.inet.qwest.net (63.146.27.209) 140.164 ms 142.500 ms 142.880 ms 9 lap-brdr-03.inet.qwest.net (67.14.22.78) 274.856 ms 226.176 ms 232.839 ms 10 63.146.26.70 (63.146.26.70) 224.891 ms 223.915 ms 225.082 ms 11 lajbb002.kddnet.ad.jp (59.128.2.73) 227.355 ms lajbb001.kddnet.ad.jp (59.128.2.173) 236.509 ms lajbb002.kddnet.ad.jp (59.128.2.177) 226.723 ms 12 otejbb204.kddnet.ad.jp (203.181.100.25) 324.419 ms otejbb203.kddnet.ad.jp (203.181.100.13) 336.141 ms otejbb204.kddnet.ad.jp (203.181.100.45) 330.458 ms 13 cm-fcu203.kddnet.ad.jp (124.215.194.164) 336.209 ms cm-fcu203.kddnet.ad.jp (124.215.194.180) 334.191 ms cm-fcu203.kddnet.ad.jp (124.215.194.164) 327.027 ms 14 124.215.199.122 (124.215.199.122) 334.904 ms 324.853 ms * -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811
Re: Inaccessible network from Verizon, accessible elsewhere.
Disable your firewall and run TCPDump on your host when you try to ping it. Does the ICMP packet get to your host? On Sat, Dec 10, 2011 at 4:11 PM, Stefan Bethke s...@lassitu.de wrote: Am 10.12.2011 um 20:49 schrieb NetSecGuy: This does not work from FIOS: traceroute to 106.187.34.33 (106.187.34.33), 64 hops max, 52 byte packets 4 so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4) 34.229 ms 8.743 ms 8.878 ms 5 so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3) 15.402 ms 13.008 ms 14.932 ms 6 0.ae2.br1.iad8.alter.net (152.63.32.158) 13.325 ms 13.245 ms 13.802 ms 7 204.255.169.218 (204.255.169.218) 14.820 ms 14.232 ms 13.491 ms 8 lap-brdr-03.inet.qwest.net (67.14.22.78) 90.170 ms 92.273 ms 145.887 ms 9 63.146.26.70 (63.146.26.70) 92.482 ms 92.287 ms 94.000 ms 10 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 58.135 ms 58.520 ms 58.055 ms 11 otejbb203.kddnet.ad.jp (203.181.100.17) 205.844 ms otejbb204.kddnet.ad.jp (203.181.100.25) 189.929 ms otejbb203.kddnet.ad.jp (203.181.100.17) 204.846 ms 12 sl-crs1-oro-0-1-5-0.sprintlink.net (144.232.25.77) 87.229 ms sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207) 88.796 ms 88.717 ms 13 124.215.199.122 (124.215.199.122) 193.584 ms 202.208 ms 192.989 ms 14 * * * From FIOS in BOS: 3 g14-0-7-1544.bstnma-lcr-05.verizon-gni.net (130.81.49.80) 132.408 ms 130.742 ms 139.945 ms 4 so-7-2-0-0.bos-bb-rtr1.verizon-gni.net (130.81.29.172) 132.405 ms 137.776 ms 134.929 ms 5 so-9-1-0-0.ny325-bb-rtr1.verizon-gni.net (130.81.19.70) 139.872 ms 141.344 ms 150.117 ms 6 0.so-0-0-0.xt1.nyc4.alter.net (152.63.1.41) 142.381 ms 141.256 ms 139.873 ms 7 0.ae3.br2.nyc4.alter.net (152.63.3.110) 169.904 ms 169.769 ms 167.357 ms 8 nyc-brdr-02.inet.qwest.net (63.146.27.209) 140.164 ms 142.500 ms 142.880 ms 9 lap-brdr-03.inet.qwest.net (67.14.22.78) 274.856 ms 226.176 ms 232.839 ms 10 63.146.26.70 (63.146.26.70) 224.891 ms 223.915 ms 225.082 ms 11 lajbb002.kddnet.ad.jp (59.128.2.73) 227.355 ms lajbb001.kddnet.ad.jp (59.128.2.173) 236.509 ms lajbb002.kddnet.ad.jp (59.128.2.177) 226.723 ms 12 otejbb204.kddnet.ad.jp (203.181.100.25) 324.419 ms otejbb203.kddnet.ad.jp (203.181.100.13) 336.141 ms otejbb204.kddnet.ad.jp (203.181.100.45) 330.458 ms 13 cm-fcu203.kddnet.ad.jp (124.215.194.164) 336.209 ms cm-fcu203.kddnet.ad.jp (124.215.194.180) 334.191 ms cm-fcu203.kddnet.ad.jp (124.215.194.164) 327.027 ms 14 124.215.199.122 (124.215.199.122) 334.904 ms 324.853 ms * -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
Re: Sad IPv4 story?
I just had a personal email from a brand new ISP in the Asia-Pacific area desperately looking for enough IPv4 to be able to run their business the way they would like? This sniping elicited by the above seems inappropriate and unprofessional, the request/anecdote seemed reasonable and could elicit solutions such as partnerships, etc. -- -Barry Shein The World | b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada Software Tool Die| Public Access Internet | SINCE 1989 *oo*
Re: Sad IPv4 story?
On Sat, 10 Dec 2011 20:48:45 EST, Barry Shein said: I just had a personal email from a brand new ISP in the Asia-Pacific area desperately looking for enough IPv4 to be able to run their business the way they would like? This sniping elicited by the above seems inappropriate and unprofessional, the request/anecdote seemed reasonable and could elicit solutions such as partnerships, etc. No Barry, I respectfully disagree. It's almost 2012. The first predictions of IPv4 exhaustion were made *last century*. We've been predicting it to the month level for like 5 years now. Any business that is making business plans and models that doesn't take we may not get IPv4 space into account and have a contingency plan for that *deserves* to be soundly mocked and ridiculed in public. pgpCUjJRKyj5B.pgp Description: PGP signature
Re: Sad IPv4 story?
I just had a personal email from a brand new ISP in the Asia-Pacific area desperately looking for enough IPv4 to be able to run their business the way they would like? This sniping elicited by the above seems inappropriate and unprofessional, the request/anecdote seemed reasonable and could elicit solutions such as partnerships, etc. i am sure they look forward to your generous offer. randy
Re: Sad IPv4 story?
No Barry, I respectfully disagree. It's almost 2012. The first predictions of IPv4 exhaustion were made *last century*. We've been predicting it to the month level for like 5 years now. Any business that is making business plans and models that doesn't take we may not get IPv4 space into account and have a contingency plan for that *deserves* to be soundly mocked and ridiculed in public. mocking someone who shows up when the party is already over is not overly kind or useful. making clear to the world that the part is over is more useful. i could not decide between a number of very appropriate floyd songs, but i think 'time' says it well Ticking away the moments that make up a dull day Fritter and waste the hours in an offhand way Kicking around on a piece of ground in your home town Waiting for someone or something to show you the way Tired of lying in the sunshine staying home to watch the rain And you are young and life is long and there is time to kill today And then one day you find ten years have got behind you No one told you when to run, you missed the starting gun And you run and you run to catch up with the sun, but it's sinking Racing around to come up behind you again The sun is the same in a relative way, but you're older Shorter of breath and one day closer to death Every year is getting shorter, never seem to find the time Plans that either come to naught or half a page of scribbled lines Hanging on quiet desperation is the English way The time is gone, the song is over, thought I'd something more to say randy
Re: Sad IPv4 story?
On 12/10/11 17:48 , Barry Shein wrote: I just had a personal email from a brand new ISP in the Asia-Pacific area desperately looking for enough IPv4 to be able to run their business the way they would like? This sniping elicited by the above seems inappropriate and unprofessional, the request/anecdote seemed reasonable and could elicit solutions such as partnerships, etc. engineering solutions work with the constraints at hand. The maximum ipv4 delegation size to be issued in apnic is a /22. one has to assume that when it's gone it's gone. given that constraint, I know how I'd build it.
Re: Sad IPv4 story?
On Sat, Dec 10, 2011 at 8:38 PM, Randy Bush ra...@psg.com wrote: No Barry, I respectfully disagree. It's almost 2012. The first predictions of IPv4 exhaustion were made *last century*. We've been predicting it to the month level for like 5 years now. Any business that is making business plans and models that doesn't take we may not get IPv4 space into account and have a contingency plan for that *deserves* to be soundly mocked and ridiculed in public. mocking someone who shows up when the party is already over is not overly kind or useful. making clear to the world that the part is over is more useful. The party is not over, it is just moving from a house to a stadium, with a large drive between.
Re: Sad IPv4 story?
On Sat, Dec 10, 2011 at 11:43 PM, Philip Dorr tagn...@gmail.com wrote: On Sat, Dec 10, 2011 at 8:38 PM, Randy Bush ra...@psg.com wrote: mocking someone who shows up when the party is already over is not overly kind or useful. making clear to the world that the part is over The party is not over, it is just moving from a house to a stadium, with a large drive between. That's a different party. It doesn't really get started until people arrive at it. So far the IPv6 party's been pretty small due to the expense of the rocket ship upgrades required to reach the planet that party is going to be held on. -- -JH
Re: Sad IPv4 story?
On 12/10/11 21:42 , Joel jaeggli wrote: On 12/10/11 17:48 , Barry Shein wrote: I just had a personal email from a brand new ISP in the Asia-Pacific area desperately looking for enough IPv4 to be able to run their business the way they would like? This sniping elicited by the above seems inappropriate and unprofessional, the request/anecdote seemed reasonable and could elicit solutions such as partnerships, etc. engineering solutions work with the constraints at hand. The maximum ipv4 delegation size to be issued in apnic is a /22. one has to assume that when it's gone it's gone. given that constraint, I know how I'd build it. Setting aside the sad story part for the moment, Would this be a good subject for a BOF? Are there others who would be willing to participate (residendential,transit or dc operators, and potentially vendors of equipment or address transfer brokers). I'd call it something like: IPV4 runout - Doing more with less. * IPV4 runout means new entrants will from the outset deploy techniques the present operators consider undesirable. * IPV6 should be appearing as part and parcel of new greenfield projects I would think. * On the vendor side CGN hardware is becoming a mature product space. * Datacenter/ICP operators confront a similar set of problems both supporting outgoing connections for large pools and incoming termination.
Re: Sad IPv4 story?
So far the IPv6 party's been pretty small due to the expense of the rocket ship upgrades required to reach the planet that party is going to be held on. for those of us who have been here on B-612 nuturing the rose for over a decade, you 'adult' geographers seem to live on a very grey and depressing asteroid. randy
