July 2015 - Test - lists.nanog.org

Joker.com contact / GLUE help
by David Sotnick 10 Jul '15

10 Jul '15

Hi NANOG, Does anyone have any technical contacts at Joker.com? I am going in circles with their support folks trying to update the GLUE records for two of my nameservers and keep running into permissions issues despite the glue records clearly being part of my domain. I need to speak to someone who actually understands what DNS Glue records are, and how to go about updating them. I feel like the joke is on me for choosing Joker.com as their support has been laughable thus far. TIA, David

1 0

Weekly Routing Table Report
by Routing Analysis Role Account 10 Jul '15

10 Jul '15

This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats(a)lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith <pfsinoz(a)gmail.com>. Routing Table Report 04:00 +10GMT Sat 11 Jul, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 551197 Prefixes after maximum aggregation (per Origin AS): 208852 Deaggregation factor: 2.64 Unique aggregates announced (without unneeded subnets): 268761 Total ASes present in the Internet Routing Table: 50862 Prefixes per ASN: 10.84 Origin-only ASes present in the Internet Routing Table: 36703 Origin ASes announcing only one prefix: 16222 Transit ASes present in the Internet Routing Table: 6328 Transit-only ASes present in the Internet Routing Table: 170 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 39 Max AS path prepend of ASN ( 12486) 32 Prefixes from unregistered ASNs in the Routing Table: 1315 Unregistered ASNs in the Routing Table: 430 Number of 32-bit ASNs allocated by the RIRs: 10163 Number of 32-bit ASNs visible in the Routing Table: 7831 Prefixes from 32-bit ASNs in the Routing Table: 28944 Number of bogon 32-bit ASNs visible in the Routing Table: 13 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 504 Number of addresses announced to Internet: 2766799648 Equivalent to 164 /8s, 234 /16s and 3 /24s Percentage of available address space announced: 74.7 Percentage of allocated address space announced: 74.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.4 Total number of prefixes smaller than registry allocations: 184446 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 136179 Total APNIC prefixes after maximum aggregation: 39528 APNIC Deaggregation factor: 3.45 Prefixes being announced from the APNIC address blocks: 143088 Unique aggregates announced from the APNIC address blocks: 58021 APNIC Region origin ASes present in the Internet Routing Table: 5059 APNIC Prefixes per ASN: 28.28 APNIC Region origin ASes announcing only one prefix: 1195 APNIC Region transit ASes present in the Internet Routing Table: 875 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 39 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1542 Number of APNIC addresses announced to Internet: 750827456 Equivalent to 44 /8s, 192 /16s and 183 /24s Percentage of available APNIC address space announced: 87.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 179662 Total ARIN prefixes after maximum aggregation: 88217 ARIN Deaggregation factor: 2.04 Prefixes being announced from the ARIN address blocks: 182213 Unique aggregates announced from the ARIN address blocks: 85011 ARIN Region origin ASes present in the Internet Routing Table: 16616 ARIN Prefixes per ASN: 10.97 ARIN Region origin ASes announcing only one prefix: 6112 ARIN Region transit ASes present in the Internet Routing Table: 1743 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 534 Number of ARIN addresses announced to Internet: 1082901024 Equivalent to 64 /8s, 139 /16s and 194 /24s Percentage of available ARIN address space announced: 57.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-395164 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 133748 Total RIPE prefixes after maximum aggregation: 66563 RIPE Deaggregation factor: 2.01 Prefixes being announced from the RIPE address blocks: 140411 Unique aggregates announced from the RIPE address blocks: 86940 RIPE Region origin ASes present in the Internet Routing Table: 17974 RIPE Prefixes per ASN: 7.81 RIPE Region origin ASes announcing only one prefix: 8110 RIPE Region transit ASes present in the Internet Routing Table: 2968 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 35 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3843 Number of RIPE addresses announced to Internet: 697952256 Equivalent to 41 /8s, 153 /16s and 232 /24s Percentage of available RIPE address space announced: 101.5 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-204287 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 60282 Total LACNIC prefixes after maximum aggregation: 11422 LACNIC Deaggregation factor: 5.28 Prefixes being announced from the LACNIC address blocks: 71030 Unique aggregates announced from the LACNIC address blocks: 33156 LACNIC Region origin ASes present in the Internet Routing Table: 2445 LACNIC Prefixes per ASN: 29.05 LACNIC Region origin ASes announcing only one prefix: 610 LACNIC Region transit ASes present in the Internet Routing Table: 509 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 28 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1782 Number of LACNIC addresses announced to Internet: 168556608 Equivalent to 10 /8s, 11 /16s and 248 /24s Percentage of available LACNIC address space announced: 100.5 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12121 Total AfriNIC prefixes after maximum aggregation: 3073 AfriNIC Deaggregation factor: 3.94 Prefixes being announced from the AfriNIC address blocks: 13951 Unique aggregates announced from the AfriNIC address blocks: 5235 AfriNIC Region origin ASes present in the Internet Routing Table: 734 AfriNIC Prefixes per ASN: 19.01 AfriNIC Region origin ASes announcing only one prefix: 195 AfriNIC Region transit ASes present in the Internet Routing Table: 162 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 130 Number of AfriNIC addresses announced to Internet: 65769984 Equivalent to 3 /8s, 235 /16s and 146 /24s Percentage of available AfriNIC address space announced: 65.3 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2947 11304 938 Korea Telecom 17974 2699 904 78 PT Telekomunikasi Indonesia 7545 2634 339 135 TPG Telecom Limited 4538 2022 4190 71 China Education and Research 4755 2016 423 221 TATA Communications formerly 9829 1801 1361 143 National Internet Backbone 9808 1557 8717 28 Guangdong Mobile Communicatio 9583 1515 119 573 Sify Limited 4808 1462 2241 470 CNCGROUP IP network China169 9498 1359 335 107 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3179 2957 136 Cox Communications Inc. 6389 2758 3688 51 BellSouth.net Inc. 3356 2579 10702 511 Level 3 Communications, Inc. 18566 2059 380 198 MegaPath Corporation 20115 1866 1838 406 Charter Communications 6983 1751 850 244 EarthLink, Inc. 4323 1609 1022 412 tw telecom holdings, inc. 30036 1570 320 433 Mediacom Communications Corp 701 1392 11371 676 MCI Communications Services, 22561 1382 415 257 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 34984 2206 305 366 TELLCOM ILETISIM HIZMETLERI A 20940 2030 796 1472 Akamai International B.V. 6849 1209 355 21 JSC "Ukrtelecom" 8551 1104 376 52 Bezeq International-Ltd 8402 1052 544 15 OJSC "Vimpelcom" 31148 1051 46 24 Freenet Ltd. 13188 1041 97 75 TOV "Bank-Inform" 12479 958 933 77 France Telecom Espana SA 6830 913 2694 469 Liberty Global Operations B.V Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3288 536 197 Telmex Colombia S.A. 28573 2279 2170 113 NET Serviços de Comunicação S 8151 1698 3271 477 Uninet S.A. de C.V. 7303 1631 1008 238 Telecom Argentina S.A. 6147 1386 374 30 Telefonica del Peru S.A.A. 6503 1268 421 55 Axtel, S.A.B. de C.V. 26615 1102 2325 35 Tim Celular S.A. 7738 999 1882 41 Telemar Norte Leste S.A. 3816 951 428 161 COLOMBIA TELECOMUNICACIONES S 11830 892 364 15 Instituto Costarricense de El Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 876 280 26 Link Egypt (Link.NET) 8452 835 958 13 TE-AS 36903 512 258 99 Office National des Postes et 36992 439 1229 32 ETISALAT MISR 37492 312 175 71 Orange Tunisie 24835 307 146 12 Vodafone Data 3741 250 857 208 Internet Solutions 29571 249 21 13 Cote d'Ivoire Telecom 36947 192 807 13 Telecom Algeria 15706 174 32 6 Sudatel (Sudan Telecom Co. Lt Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3288 536 197 Telmex Colombia S.A. 22773 3179 2957 136 Cox Communications Inc. 4766 2947 11304 938 Korea Telecom 6389 2758 3688 51 BellSouth.net Inc. 17974 2699 904 78 PT Telekomunikasi Indonesia 7545 2634 339 135 TPG Telecom Limited 3356 2579 10702 511 Level 3 Communications, Inc. 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 28573 2279 2170 113 NET Serviços de Comunicação S 34984 2206 305 366 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3179 3043 Cox Communications Inc. 6389 2758 2707 BellSouth.net Inc. 17974 2699 2621 PT Telekomunikasi Indonesia 7545 2634 2499 TPG Telecom Limited 39891 2472 2466 SaudiNet, Saudi Telecom Compa 28573 2279 2166 NET Serviços de Comunicação S 3356 2579 2068 Level 3 Communications, Inc. 4766 2947 2009 Korea Telecom 4538 2022 1951 China Education and Research 18566 2059 1861 MegaPath Corporation Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint 32805 UNALLOCATED 12.1.225.0/24 7018 AT&T Services, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.226.112.0/20 62788 >>UNKNOWN<< 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.3.0/24 37004 >>UNKNOWN<< 41.73.4.0/24 37004 >>UNKNOWN<< 41.73.5.0/24 37004 >>UNKNOWN<< 41.73.6.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:95 /12:260 /13:504 /14:1001 /15:1730 /16:12886 /17:7277 /18:12377 /19:25606 /20:36004 /21:38758 /22:60453 /23:52463 /24:298703 /25:1104 /26:1152 /27:709 /28:14 /29:12 /30:7 /31:0 /32:17 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2472 SaudiNet, Saudi Telecom Compa 22773 2382 3179 Cox Communications Inc. 18566 2005 2059 MegaPath Corporation 6389 1629 2758 BellSouth.net Inc. 34984 1464 2206 TELLCOM ILETISIM HIZMETLERI A 6983 1398 1751 EarthLink, Inc. 30036 1392 1570 Mediacom Communications Corp 10620 1158 3288 Telmex Colombia S.A. 11492 1114 1198 CABLE ONE, INC. 22561 1055 1382 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1502 2:686 4:93 5:1875 6:25 8:1382 11:1 12:1820 13:14 14:1382 15:17 16:2 17:45 18:22 20:48 23:1252 24:1760 27:1972 31:1612 32:38 33:2 34:4 35:3 36:143 37:1961 38:1034 39:5 40:72 41:2717 42:295 43:1367 44:28 45:779 46:2300 47:45 49:889 50:787 52:12 54:79 55:3 56:6 57:42 58:1331 59:723 60:481 61:1752 62:1361 63:1901 64:4428 65:2259 66:4032 67:2054 68:1075 69:3253 70:1022 71:444 72:1966 74:2640 75:340 76:399 77:1274 78:1193 79:809 80:1354 81:1311 82:846 83:728 84:783 85:1381 86:437 87:1064 88:533 89:1899 90:144 91:6011 92:837 93:2243 94:2077 95:2209 96:434 97:348 98:1053 99:53 100:72 101:845 103:7784 104:1868 105:63 106:264 107:1006 108:628 109:2067 110:1146 111:1447 112:837 113:1103 114:840 115:1253 116:1409 117:1065 118:1869 119:1452 120:454 121:1084 122:2123 123:1844 124:1522 125:1624 128:653 129:391 130:410 131:1197 132:513 133:171 134:405 135:94 136:334 137:315 138:959 139:152 140:237 141:449 142:668 143:502 144:546 145:123 146:744 147:583 148:1215 149:416 150:555 151:652 152:520 153:249 154:464 155:877 156:436 157:419 158:353 159:1002 160:398 161:656 162:1957 163:437 164:692 165:698 166:307 167:833 168:1275 169:183 170:1467 171:245 172:284 173:1544 174:720 175:687 176:1445 177:3811 178:2165 179:945 180:1935 181:1576 182:1830 183:628 184:761 185:3837 186:2805 187:1760 188:2059 189:1614 190:7704 191:1024 192:8473 193:5633 194:4214 195:3697 196:1992 197:986 198:5529 199:5486 200:6598 201:3250 202:9536 203:9129 204:4712 205:2848 206:3037 207:2970 208:3985 209:3937 210:3592 211:1897 212:2580 213:2300 214:851 215:73 216:5746 217:1818 218:714 219:467 220:1453 221:792 222:461 223:789 End of report

1 0

Fwd: Test-drive the OS X El Capitan public beta
by Colin Johnston 10 Jul '15

10 Jul '15

lots of 6GB downloads this morning :) Colin > Begin forwarded message: > > From: Apple Beta Software Program <betaprogram(a)InsideApple.Apple.com> > Subject: Test-drive the OS X El Capitan public beta > Date: 10 July 2015 05:08:06 BST > To: colinj(a)mx5.org.uk > > > > The El Capitan public beta is now available from the Apple Beta Software Program. > Test-drive it and let us know what you think. > > >

2 2

Re: Dual stack IPv6 for IPv4 depletion
by Seth Mos 10 Jul '15

10 Jul '15

Meanwhile, I'm sitting here on a patio at a cafe on Samos, Greece. And the free wifi gives me native v6 to my tablet and phone without any intervention. Test-ipv6.com tells me that the score is 10/10 and all the google bits just work. So, surely it "just works". I wish we had it this easy in the Netherlands. There, sales still asks, "what for" (Vodafone fiber). Cheers, Seth Verzonden vanaf Samsung-tablet -------- Oorspronkelijk bericht -------- Van: Karl Auer <kauer(a)biplane.com.au> Datum: 10-07-2015 14:16 (GMT+01:00) Aan: NANOG List <nanog(a)nanog.org> Onderwerp: Re: Dual stack IPv6 for IPv4 depletion On Fri, 2015-07-10 at 02:08 -0400, Ricky Beam wrote: > And planning for a future that doesn't happen because you're too caught up > in *planning* that future is irrelevant, too. Advocating for fewer limits is not "planning". It's the opposite of it. It's about retaining more flexibility - as a matter of principle. > And in ~15 years when they have a jobs, they can change what we built. > (assuming ever let the paint dry long enough to use it.) We've had twenty years to implement IPv6 and golly haven't we done a great job? I suppose we could all hope that our kids will be less hopeless than we have been. Still... I'd prefer to leave them something that is easier to change and improve than the last thing we built. > IPv6 will never get there until it, too, "just works". No - so why do so many people just keep on and on moaning about how IPv6 doesn't "just work", forgetting that once upon a time IPv4 didn't "just work" either? "Getting there" and "just working" are two things that have to be developed together. One doesn't follow the other, they both become true side by side, or neither happens at all. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer(a)biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882

1 0

Re: Hotels/Airports with IPv6
by Oliver O'Boyle 10 Jul '15

10 Jul '15

32 bit connection with a 32 bit address will open up an three-dimensional portal under the hotel. They all know this and work around it by selecting a lower connection speed. On July 10, 2015, at 3:59 AM, Alan Buxey <A.L.M.Buxey(a)lboro.ac.uk> wrote: 2 mbit is still more than 32 bit ;) alan

1 0

Re: Dual stack IPv6 for IPv4 depletion
by andrew 09 Jul '15

09 Jul '15

Pardon my ignorance - what do you see missing in MPLS in regards to support for IP6?-------- Original message -------- From: Mel Beckman <mel(a)beckman.org> Date: 07/06/2015 9:44 AM (GMT-05:00) To: Lee Howard <Lee(a)asgard.org> Cc: Josh Moore <jmoore(a)atcnetworks.net>, nanog(a)nanog.org Subject: Re: Dual stack IPv6 for IPv4 depletion And let's all complain to the MPLS working group to get IPv6 support finished up! -mel beckman > On Jul 6, 2015, at 6:27 AM, Lee Howard <Lee(a)asgard.org> wrote: > > Some thoughts. . . > > ³Native dual-stack² is ³native IPv4 and native IPv6.² > > ³Dual-stack² might be native, or might by ³native IPv6 plus IPv4 address > sharing.² > > Your IPv4 address sharing options are CGN, DS-Lite, and MAP. There are > operational deployments of all three, in the order given. You need them > close enough to your customers that traffic will return over the same > path. You can¹t share state among a cluster of boxes, but that¹s not the > end of the world; a device failure sometimes causes loss of state. MAP is > the hot new thing all the cool kids are doing. > > Look to your router and load balancer vendors for devices that do these. > CGN is the only one that doesn¹t require updates to the home gateway. The > more IPv6 your customers use, the smaller your CGN/AFTR/MAP can be. > > Think about how you¹ll position it to customers. It¹s difficult to change > a customer¹s service mid-contract. At some point, a customer is no longer > profitable: if NAT costs and service calls add up, you may be better off > buying addresses or losing the customer. You may need to buy some IPv4 > addresses to give you time; contact a broker. > > You may be surprised how hard it is to root IPv4 out of the system. Don¹t > buy anything you can¹t manage over IPv6, including servers and > applications. Sorry, vendor, I can¹t buy your cluster, I don¹t have the > IPv4 address space to provision it. > > Lee > > On 7/4/15, 8:09 AM, "NANOG on behalf of Josh Moore" > <nanog-bounces(a)nanog.org on behalf of jmoore(a)atcnetworks.net> wrote: > >> Traditional dual stack deployments implement both IPv4 and IPv6 to the >> CPE. >> Consider the following: >> >> An ISP is at 90% IPv4 utilization and would like to deploy dual stack >> with the purpose of allowing their subscriber base to continue to grow >> regardless of the depletion of the IPv4 space. Current dual stack best >> practices seem to recommend deploying BOTH IPv4 and IPv6 to every CPE. If >> this is the case, and BOTH are still required, then how does IPv6 help >> with the v4 address depletion crisis? Many sites and services would still >> need legacy IPv4 compatibility. Sure, CGN technology may be a solution >> but what about applications that need direct IPv4 connectivity without >> NAT? It seems that there should be a mechanism to enable on-demand and >> efficient IPv4 address consumption ONLY when needed. My question is this: >> What, if any, solutions like this exist? If no solution exists then what >> is the next best thing? What would the overall IPv6 migration strategy >> and goal be? >> >> Sorry for the length of this email but these are legitimate concerns and >> while I understand the need for IPv6 and the importance of getting there; >> I don't understand exactly HOW that can be done considering the immediate >> issue: IPv4 depletion. >> >> >> Thanks >> >> Joshua Moore >> Network Engineer >> ATC Broadband >> 912.632.3161 > >

9 18

Telia <> Globalcrossing ASH peering issue
by Frederik Kriewitz 09 Jul '15

09 Jul '15

Hello, is someone from GBLX/Level 3/Telia around? It looks like there's a problem with one of your peerings/LAGs. The problem exists since 00:36 UTC working path: traceroute from 71.80.34.222 to 151.248.24.61 (151.248.24.61), 30 hops max, 40 byte packets 1 192.168.30.1 (192.168.30.1) 0.416 ms 0.917 ms 1.085 ms 2 192.168.1.2 (192.168.1.2) 0.620 ms 0.520 ms 0.468 ms 3 71-80-34-193.static.kgpt.tn.charter.com (71.80.34.193) 1.342 ms 1.538 ms 2.180 ms 4 71-80-34-152.static.kgpt.tn.charter.com (71.80.34.152) 1.835 ms 2.001 ms 2.061 ms 5 dtr02lncytn-tge-0-6-1-2.lncy.tn.charter.com (96.34.68.84) 1.774 ms 1.787 ms 1.860 ms 6 crr02kgpttn-tge-0-7-0-4.kgpt.tn.charter.com (96.34.69.27) 5.485 ms crr02kgpttn-tge-0-7-0-6.kgpt.tn.charter.com (96.34.71.100) 5.222 ms crr02kgpttn-tge-0- -0-5.kgpt.tn.charter.com (96.34.69.29) 5.257 ms 7 crr12spbgsc-bue-100.spbg.sc.charter.com (96.34.93.200) 11.958 ms 11.962 ms 11.988 ms 8 bbr01spbgsc-bue-4.spbg.sc.charter.com (96.34.2.50) 11.864 ms 12.505 ms 14.984 ms 9 cha-b1-link.telia.net (62.115.12.125) 11.356 ms 11.370 ms 11.391 ms 10 ash-bb3-link.telia.net (80.91.252.100) 19.172 ms 19.211 ms 19.210 ms 11 ash-b1-link.telia.net (62.115.113.207) 19.439 ms 21.042 ms 20.627 ms 12 globalcrossing-ic-150675-ash-bb1.c.telia.net (213.248.90.122) 19.593 ms 19.223 ms 19.291 ms 13 lag9.csr1.dca3.gblx.net (67.16.146.25) 28.340 ms 19.095 ms 19.117 ms 14 ae3.scr4.wdc2.gblx.net (67.16.166.229) 19.894 ms 19.936 ms 19.929 ms 15 xe10-1-0-10g.scr4.lon3.gblx.net (67.16.166.81) 94.114 ms 94.124 ms 94.428 ms 16 lag2.ar9.lon3.gblx.net (67.17.106.149) 95.592 ms 93.098 ms 93.086 ms 17 avanti-hylas-2-cyprus-ltd.ethernet23-1.ar9.lon3.gblx.net (159.63.52.6) 95.534 ms 92.612 ms 92.568 ms 18 88.210.183.37 (88.210.183.37) 168.082 ms 181.644 ms 181.669 ms 19 88.210.186.77 (88.210.186.77) 169.436 ms 168.871 ms 168.895 ms 20 static-151-248-24-61.nynex.de (151.248.24.61) 169.285 ms 169.200 ms 169.151 ms Broken path to a neighboring IP using another interconnect: traceroute from 71.80.34.222 to 151.248.24.62 (151.248.24.62), 30 hops max, 40 byte packets 1 192.168.30.1 (192.168.30.1) 0.409 ms 0.903 ms 1.073 ms 2 192.168.1.2 (192.168.1.2) 0.488 ms 0.581 ms 0.529 ms 3 71-80-34-193.static.kgpt.tn.charter.com (71.80.34.193) 1.512 ms 2.005 ms 2.305 ms 4 71-80-34-152.static.kgpt.tn.charter.com (71.80.34.152) 2.807 ms 2.753 ms 3.027 ms 5 dtr02lncytn-tge-0-6-1-2.lncy.tn.charter.com (96.34.68.84) 1.809 ms 1.814 ms 1.815 ms 6 crr02kgpttn-tge-0-7-0-4.kgpt.tn.charter.com (96.34.69.27) 5.551 ms crr02kgpttn-tge-0-7-0-6.kgpt.tn.charter.com (96.34.71.100) 4.802 ms 4.837 ms 7 crr12spbgsc-bue-100.spbg.sc.charter.com (96.34.93.200) 10.341 ms 10.681 ms 10.593 ms 8 bbr01spbgsc-bue-4.spbg.sc.charter.com (96.34.2.50) 16.036 ms 10.018 ms 10.780 ms 9 cha-b1-link.telia.net (213.248.86.173) 21.081 ms 21.124 ms 21.121 ms 10 ash-bb4-link.telia.net (213.155.132.178) 19.049 ms 19.051 ms 19.041 ms 11 ash-b1-link.telia.net (213.155.130.73) 19.414 ms 19.434 ms 19.545 ms 12 globalcrossing-ic-130167-ash-bb1.c.telia.net (213.248.84.154) 19.239 ms 19.182 ms 19.279 ms 13 * 14 * 15 * 16 * 17 * 18 * 19 * 20 * 21 * 22 * 23 * 24 * 25 * 26 * 27 * 28 * 29 *

1 0

How to build an IPv6-only internal network?
by Cryptographrix 09 Jul '15

09 Jul '15

Hypothetically, I want to build an internal network that runs just IPv6 and apply stateless ACLs at redundant external connections. How do users access the current v4 address space?

4 3

Re: Dual stack IPv6 for IPv4 depletion
by Seth Mos 09 Jul '15

09 Jul '15

Residential users just buy another router for wifi coverage at the local wall mart. They have no clue about anything internet. That is why isp CPE devices should always perform dhcp-pd on their own to provide a prefix to the downstream devices so those have globally routed ipv6 too. For that to work you need concepts like route aggregation in the form of a /48 for the CPE so it can hand out a /56 to the customer bought CPE. Seth -------- Oorspronkelijk bericht -------- Van: Mike Hammett <nanog(a)ics-il.net> Datum: 09-07-2015 04:03 (GMT+01:00) Aan: nanog(a)nanog.org Onderwerp: Re: Dual stack IPv6 for IPv4 depletion I wasn't aware that residential users had (intentionally) multiple layers of routing within the home. I'm also not sure what address length has to do with routability, other than networks filtering prefix lengths. If that's an issue, that customer is covered by the ISP's larger allocation, or they get their own PI space if they're BGPing. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Karl Auer" <kauer(a)biplane.com.au> To: nanog(a)nanog.org Sent: Wednesday, July 8, 2015 8:36:41 PM Subject: Re: Dual stack IPv6 for IPv4 depletion On Wed, 2015-07-08 at 19:57 -0500, Mike Hammett wrote: > Isn't /56 the standard end-user allocation? No - it's just a common one. And a bad one. /48s for all opens up a whole different world of end-user reachability, routability and flexibility that a mere /56 does not. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer(a)biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882

1 0

Re: Dual stack IPv6 for IPv4 depletion
by Owen DeLong 09 Jul '15

09 Jul '15

> On Jul 8, 2015, at 15:34 , Israel G. Lugo <israel.lugo(a)lugosys.org> wrote: > > > On 07/05/2015 06:26 PM, Owen DeLong wrote: >>> On Jul 4, 2015, at 23:51 , Valdis.Kletnieks(a)vt.edu wrote: >>> >>> Put their IPv4 behind a NAT and a globally routed /56. >>> >>> There, FTFY. :) >> Or better yet globally routed /48. >> >> /56 is still a bad idea. >> >> Owen > I've read this many times and am aware it's the standard recommendation. > Makes perfect sense for the customer side, as it would be hard for him > to subnet properly otherwise. > > Doesn't seem to make sense at all for the ISP side, though. Standard > allocation /32. Giving out /48s. Even if we leave out proper subnet > organization and allocate fully densely, that's at most 65,536 subnets. > Not a very large ISP. If you’re trying to build a decent sized ISP in a /32, you’re doing it wrong. /32 is not the “standard size” — It’s the MINIMUM size. > > You can say "get more blocks", or "get larger blocks". Sure, let's give > each ISP a /24. That lets them have up to 16M customers (and that's > still subnetting densely, which sucks rather a lot). Doesn't leave that > many allocation blocks for the RIRs to hand out, though. If you really think we have 16.7 Million ISPs on the planet, I think you badly miscounted. In fact, if you think we have 1 million ISPs that have more than 1 million customers, I’d say you’ve badly miscounted something. What am I missing? In terms of ISPs that need to support 16M customers, let’s assume everyone on the planet has 32 ISP subscriptions of some form or another. (work, home, tablet, phone, dongle, whatever… I’m pretty sure 32 is generous). Let’s assume EVERYONE on the planet is connected. That’s 7 Billion * 32 = 224 Billion total customers. Now let’s sparse-allocate 24s at the rate of 4 million customers per /24. 224,000,000,000 / 4,000,000 = 56,000 We need a total of 56,000 /24s to cover the total population. That still leaves us with 16,721,216 /24s. We barely made a dent in the number of /24s. Please explain to me again where the problem is with handing out /48s? > People usually look at IPv6 and focus on the vast numbers of individual > addresses. Naysayers usually get shot down with some quote mentioning > the number of atoms in the universe or some such. Personally, I think > that's a red herring; the real problem is subnets. At this rate I > believe subnets will become the scarce resource sooner or later. I’ve done the math on the prefix side. See above… Clearly you haven’t. > Sure, in the LAN side we'll never have to worry about address scarcity. > But what's the point of having addresses to spare, if it just means > you've got to start worrying about subnet scarcity? If the goal was > never having to worry about counting anymore, I propose that 128 bits is > far too little. Should've gone a full 256 and be done with it. Respectfully, I think that the math above shows that you are not correct in this assertion. Owen

2 1