From cscora at apnic.net Fri Jul 1 14:05:49 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 2 Jul 2011 05:05:49 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201107011905.p61J5nAb019702@thyme.rand.apnic.net> 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, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 02 Jul, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 362404 Prefixes after maximum aggregation: 164721 Deaggregation factor: 2.20 Unique aggregates announced to Internet: 179786 Total ASes present in the Internet Routing Table: 38071 Prefixes per ASN: 9.52 Origin-only ASes present in the Internet Routing Table: 31670 Origin ASes announcing only one prefix: 15223 Transit ASes present in the Internet Routing Table: 5179 Transit-only ASes present in the Internet Routing Table: 136 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 33 Max AS path prepend of ASN (22394) 27 Prefixes from unregistered ASNs in the Routing Table: 877 Unregistered ASNs in the Routing Table: 484 Number of 32-bit ASNs allocated by the RIRs: 1514 Number of 32-bit ASNs visible in the Routing Table: 1222 Prefixes from 32-bit ASNs in the Routing Table: 2774 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 134 Number of addresses announced to Internet: 2492654912 Equivalent to 148 /8s, 146 /16s and 229 /24s Percentage of available address space announced: 67.3 Percentage of allocated address space announced: 67.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 91.0 Total number of prefixes smaller than registry allocations: 151058 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 90072 Total APNIC prefixes after maximum aggregation: 30234 APNIC Deaggregation factor: 2.98 Prefixes being announced from the APNIC address blocks: 86827 Unique aggregates announced from the APNIC address blocks: 37040 APNIC Region origin ASes present in the Internet Routing Table: 4494 APNIC Prefixes per ASN: 19.32 APNIC Region origin ASes announcing only one prefix: 1243 APNIC Region transit ASes present in the Internet Routing Table: 708 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 18 Number of APNIC region 32-bit ASNs visible in the Routing Table: 53 Number of APNIC addresses announced to Internet: 621139616 Equivalent to 37 /8s, 5 /16s and 214 /24s Percentage of available APNIC address space announced: 78.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 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, 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: 141388 Total ARIN prefixes after maximum aggregation: 72780 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 113365 Unique aggregates announced from the ARIN address blocks: 46607 ARIN Region origin ASes present in the Internet Routing Table: 14460 ARIN Prefixes per ASN: 7.84 ARIN Region origin ASes announcing only one prefix: 5524 ARIN Region transit ASes present in the Internet Routing Table: 1519 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 30 Number of ARIN region 32-bit ASNs visible in the Routing Table: 13 Number of ARIN addresses announced to Internet: 819612288 Equivalent to 48 /8s, 218 /16s and 74 /24s Percentage of available ARIN address space announced: 65.1 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, 393216-394239 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, 173/8, 174/8, 184/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: 86326 Total RIPE prefixes after maximum aggregation: 49069 RIPE Deaggregation factor: 1.76 Prefixes being announced from the RIPE address blocks: 79752 Unique aggregates announced from the RIPE address blocks: 52675 RIPE Region origin ASes present in the Internet Routing Table: 15768 RIPE Prefixes per ASN: 5.06 RIPE Region origin ASes announcing only one prefix: 7871 RIPE Region transit ASes present in the Internet Routing Table: 2503 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 899 Number of RIPE addresses announced to Internet: 478628096 Equivalent to 28 /8s, 135 /16s and 73 /24s Percentage of available RIPE address space announced: 77.1 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 196608-198655 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, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 33414 Total LACNIC prefixes after maximum aggregation: 7555 LACNIC Deaggregation factor: 4.42 Prefixes being announced from the LACNIC address blocks: 32490 Unique aggregates announced from the LACNIC address blocks: 16972 LACNIC Region origin ASes present in the Internet Routing Table: 1473 LACNIC Prefixes per ASN: 22.06 LACNIC Region origin ASes announcing only one prefix: 440 LACNIC Region transit ASes present in the Internet Routing Table: 272 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 19 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 253 Number of LACNIC addresses announced to Internet: 85702656 Equivalent to 5 /8s, 27 /16s and 184 /24s Percentage of available LACNIC address space announced: 56.8 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 8217 Total AfriNIC prefixes after maximum aggregation: 1963 AfriNIC Deaggregation factor: 4.19 Prefixes being announced from the AfriNIC address blocks: 6492 Unique aggregates announced from the AfriNIC address blocks: 1972 AfriNIC Region origin ASes present in the Internet Routing Table: 466 AfriNIC Prefixes per ASN: 13.93 AfriNIC Region origin ASes announcing only one prefix: 145 AfriNIC Region transit ASes present in the Internet Routing Table: 103 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: 4 Number of AfriNIC addresses announced to Internet: 24304128 Equivalent to 1 /8s, 114 /16s and 218 /24s Percentage of available AfriNIC address space announced: 36.2 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2460 9500 928 Korea Telecom (KIX) 17974 1835 461 42 PT TELEKOMUNIKASI INDONESIA 7545 1543 301 85 TPG Internet Pty Ltd 4755 1476 627 162 TATA Communications formerly 24560 1153 336 187 Bharti Airtel Ltd., Telemedia 9829 1098 914 45 BSNL National Internet Backbo 9583 1056 78 506 Sify Limited 4808 1050 2091 298 CNCGROUP IP network: China169 17488 960 186 103 Hathway IP Over Cable Interne 18101 932 116 139 Reliance Infocom Ltd Internet 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 6389 3619 3819 245 bellsouth.net, inc. 18566 1913 365 241 Covad Communications 1785 1802 681 122 PaeTec Communications, Inc. 4323 1660 1082 399 Time Warner Telecom 20115 1589 1532 635 Charter Communications 19262 1450 4806 370 Verizon Global Networks 7018 1361 7053 887 AT&T WorldNet Services 22773 1347 2897 87 Cox Communications, Inc. 6478 1338 248 613 AT&T Worldnet Services 7029 1285 790 298 Windstream Communications Inc 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 34984 535 106 185 BILISIM TELEKOM 6830 513 1780 318 UPC Distribution Services 3292 469 2080 404 TDC Tele Danmark 20940 467 137 360 Akamai Technologies European 8866 451 134 26 Bulgarian Telecommunication C 29049 440 33 45 AzerSat LLC. 12479 438 593 7 Uni2 Autonomous System 3320 420 8151 367 Deutsche Telekom AG 8551 404 354 44 Bezeq International 702 396 1803 310 UUNET - Commercial IP service 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 1541 282 157 TVCABLE BOGOTA 8151 1424 2742 356 UniNet S.A. de C.V. 28573 1271 996 80 NET Servicos de Comunicao S.A 7303 1000 507 175 Telecom Argentina Stet-France 6503 747 354 74 AVANTEL, S.A. 14420 685 55 81 CORPORACION NACIONAL DE TELEC 22047 576 322 17 VTR PUNTO NET S.A. 3816 535 232 92 Empresa Nacional de Telecomun 7738 516 986 31 Telecomunicacoes da Bahia S.A 27947 505 53 53 Telconet S.A 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 8452 792 445 11 TEDATA 24863 789 147 37 LINKdotNET AS number 15475 524 74 8 Nile Online 36992 315 415 14 Etisalat MISR 3741 261 937 223 The Internet Solution 6713 241 215 13 Itissalat Al-MAGHRIB 24835 211 78 10 RAYA Telecom - Egypt 33776 210 12 8 Starcomms Nigeria Limited 29571 192 17 11 Ci Telecom Autonomous system 16637 149 441 86 MTN Network Solutions 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 6389 3619 3819 245 bellsouth.net, inc. 23456 2774 692 1512 32-bit ASN transition 4766 2460 9500 928 Korea Telecom (KIX) 18566 1913 365 241 Covad Communications 17974 1835 461 42 PT TELEKOMUNIKASI INDONESIA 1785 1802 681 122 PaeTec Communications, Inc. 4323 1660 1082 399 Time Warner Telecom 20115 1589 1532 635 Charter Communications 7545 1543 301 85 TPG Internet Pty Ltd 10620 1541 282 157 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 17974 1835 1793 PT TELEKOMUNIKASI INDONESIA 1785 1802 1680 PaeTec Communications, Inc. 18566 1913 1672 Covad Communications 4766 2460 1532 Korea Telecom (KIX) 7545 1543 1458 TPG Internet Pty Ltd 10620 1541 1384 TVCABLE BOGOTA 4755 1476 1314 TATA Communications formerly 23456 2774 1262 32-bit ASN transition 4323 1660 1261 Time Warner Telecom 22773 1347 1260 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.225.128.0/18 36377 Comcast Telecommunications, I 24.225.192.0/23 36377 Comcast Telecommunications, I 24.225.192.0/18 36377 Comcast Telecommunications, I 24.225.224.0/21 36377 Comcast Telecommunications, I 24.225.237.0/24 36377 Comcast Telecommunications, I 24.225.248.0/21 36377 Comcast Telecommunications, I 27.0.128.0/17 7514 Media Exchange, Inc. 31.135.216.0/21 51388 UAB Marsatas 41.190.32.0/23 31856 CABSAS 41.190.34.0/23 31856 CABSAS 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:22 /9:12 /10:28 /11:81 /12:231 /13:461 /14:801 /15:1396 /16:11983 /17:5875 /18:9808 /19:19455 /20:25864 /21:26151 /22:34633 /23:33577 /24:188712 /25:1089 /26:1268 /27:740 /28:200 /29:9 /30:2 /31:0 /32:6 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2227 3619 bellsouth.net, inc. 18566 1869 1913 Covad Communications 10620 1436 1541 TVCABLE BOGOTA 23456 1369 2774 32-bit ASN transition 6478 1309 1338 AT&T Worldnet Services 11492 1090 1136 Cable One 7011 1055 1156 Citizens Utilities 1785 1052 1802 PaeTec Communications, Inc. 7029 1032 1285 Windstream Communications Inc 22773 862 1347 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:319 2:47 4:16 5:1 6:3 8:337 12:1976 13:1 14:472 15:15 16:3 17:8 20:10 23:13 24:1657 27:788 31:488 32:64 33:4 34:2 36:4 37:1 38:741 39:3 40:103 41:2550 42:23 44:3 46:992 47:3 49:196 50:431 52:13 54:2 55:4 56:2 57:33 58:859 59:476 60:386 61:1173 62:1048 63:1936 64:3947 65:2293 66:3875 67:1900 68:1095 69:3026 70:758 71:389 72:1890 74:2380 75:313 76:341 77:885 78:712 79:461 80:1118 81:844 82:501 83:457 84:686 85:1080 86:552 87:759 88:334 89:1532 90:211 91:3917 92:537 93:1053 94:1319 95:853 96:446 97:254 98:890 99:36 101:77 103:100 106:10 107:19 108:71 109:1019 110:608 111:712 112:304 113:407 114:544 115:669 116:969 117:668 118:854 119:1155 120:308 121:669 122:1612 123:969 124:1298 125:1236 128:246 129:173 130:168 131:564 132:112 133:21 134:213 135:48 136:215 137:136 138:298 139:115 140:474 141:241 142:403 143:416 144:481 145:54 146:448 147:213 148:659 149:247 150:163 151:190 152:330 153:180 154:4 155:399 156:199 157:351 158:138 159:452 160:314 161:211 162:309 163:164 164:510 165:354 166:529 167:432 168:737 169:158 170:847 171:78 172:1 173:1635 174:615 175:377 176:141 177:134 178:990 180:878 181:21 182:485 183:219 184:313 185:1 186:1253 187:733 188:872 189:944 190:4928 192:5894 193:4972 194:3495 195:3027 196:1224 197:41 198:3564 199:3959 200:5519 201:1513 202:8394 203:8418 204:4222 205:2347 206:2678 207:2812 208:3962 209:3460 210:2693 211:1455 212:2103 213:1743 214:770 215:70 216:4929 217:1644 218:544 219:361 220:1204 221:492 222:361 223:180 End of report From behrnetworks at gmail.com Fri Jul 1 16:33:00 2011 From: behrnetworks at gmail.com (Chris) Date: Fri, 1 Jul 2011 17:33:00 -0400 Subject: What do you think about the Juniper MX line? In-Reply-To: <5fc6f7d2-ab03-44af-b5f2-c04e242c5300@zimbra.network1.net> References: <5fc6f7d2-ab03-44af-b5f2-c04e242c5300@zimbra.network1.net> Message-ID: I just wanted to say thank you to all that posted feedback to this thread. Your insight has been incredibly helpful and has most certainly clarified many of the questions I had lingering. Thanks again!! On Mon, Jun 27, 2011 at 4:23 PM, Randy Carpenter wrote: > > The SRX line is nice for some uses, particularly with recent software updates that have fixed things like using IPv6 on vlan interfaces. > > The SRX is not going to be the choice for an edge router that needs to do BGP and/or 1 Gb/s+ of traffic. > > The SRX pretty much does everything in software, where the MX routes packets in ASICs. > > SRX is great for a firewall box, or to be the edge for a small network. > > I do wish there was an even lower-end MX than the new MX5 (all hardware routing, but ~$10k), as I would have many uses for such a thing in networks that only have a few uplinks of ~1 Gb/s. I don't need 20 Gb of throughput for that. But, if the budget allows for an MX5 (~$30k MSRP) or bigger, the MX line is very nice. > > -Randy > > > ----- Original Message ----- >> Heh, I spent about 3mo evaluating/testing SRX's and I agree they had >> potential but left /a lot/ to be desired. >> >> -Jeremy >> >> On Mon, Jun 27, 2011 at 2:45 PM, Owen DeLong wrote: >> >> > Sorry... I misspoke. My comments related to the SRX series and not >> > the MX. >> > >> > The MX is a fine product in my experience. >> > >> > Owen >> > >> > On Jun 25, 2011, at 10:03 PM, Howard Hart wrote: >> > >> > > >> > > We have a couple installed as our edge routers. >> > > >> > > Pluses - ?solid as a rock, easy to administer, and will take some >> > extremely high packet rates for relatively low cost (important for >> > us since >> > we use them for VoIP traffic). If you're approaching the capacity >> > of a 1GB >> > uplink, I highly recommend these as your first step to 10 GB. >> > > >> > > Minuses - careful on your MX80 version. The MX80-48T includes a >> > > built in >> > 48 port 1 GigE switch, but we've had compatibility issues with it >> > and other >> > vendors switches. The modular version that replaces the MX80-48T >> > costs quite >> > a bit more, but it does give you a lot more connection and >> > compatibility >> > options. >> > > >> > > Howard Hart >> > > >> > > On Jun 25, 2011, at 9:37 PM, "Ryan Finnesey" >> > wrote: >> > > >> > >> I would love to know the same I am looking at the MX line as >> > >> well for a >> > >> new network build-out >> > >> >> > >> Cheers >> > >> Ryan >> > >> >> > >> >> > >> -----Original Message----- >> > >> From: Chris [mailto:behrnetworks at gmail.com] >> > >> Sent: Saturday, June 25, 2011 9:29 AM >> > >> To: nanog at nanog.org >> > >> Subject: What do you think about the Juniper MX line? >> > >> >> > >> Hello, >> > >> >> > >> I've been doing some research into using the MX line of Juniper >> > >> routers >> > >> and was interested in hearing people's experiences (the good, >> > >> bad, and >> > >> ugly). What do you like about them? What do you dislike? >> > >> Where are you putting them in your network? Where are you not >> > >> putting >> > >> them? Why? What other platforms would you consider and why? I >> > >> hope to >> > >> hear some candid responses, but feel free to respond privately >> > >> if you >> > >> need to. >> > >> >> > >> Thanks! >> > >> >> > >> >> > >> > >> > >> >> > > From cidr-report at potaroo.net Fri Jul 1 17:00:01 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 1 Jul 2011 22:00:01 GMT Subject: BGP Update Report Message-ID: <201107012200.p61M01xC038172@wattle.apnic.net> BGP Update Report Interval: 23-Jun-11 -to- 30-Jun-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 35138 2.5% 48.4 -- BSNL-NIB National Internet Backbone 2 - AS4134 27405 1.9% 63.3 -- CHINANET-BACKBONE No.31,Jin-rong Street 3 - AS17974 17859 1.3% 16.0 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 4 - AS32528 17284 1.2% 3456.8 -- ABBOTT Abbot Labs 5 - AS7552 16489 1.2% 16.5 -- VIETEL-AS-AP Vietel Corporation 6 - AS278 13069 0.9% 871.3 -- Universidad Nacional Autonoma de Mexico 7 - AS8151 12073 0.9% 9.6 -- Uninet S.A. de C.V. 8 - AS23752 11989 0.8% 171.3 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services, 9 - AS9498 10911 0.8% 14.4 -- BBIL-AP BHARTI Airtel Ltd. 10 - AS11492 10676 0.8% 25.6 -- CABLEONE - CABLE ONE, INC. 11 - AS47331 10669 0.8% 6.8 -- TTNET TTNet A.S. 12 - AS27817 10514 0.8% 104.1 -- Red Nacional Acad?mica de Tecnolog?a Avanzada - RENATA 13 - AS28573 8538 0.6% 7.4 -- NET Servicos de Comunicao S.A. 14 - AS3320 8098 0.6% 130.6 -- DTAG Deutsche Telekom AG 15 - AS45595 7994 0.6% 42.3 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited 16 - AS3454 7704 0.6% 1926.0 -- Universidad Autonoma de Nuevo Leon 17 - AS42926 7397 0.5% 20.2 -- RADORE Radore Hosting Telekomunikasyon Hizmetleri San. ve Tic. Ltd. Sti. 18 - AS4780 6353 0.5% 13.8 -- SEEDNET Digital United Inc. 19 - AS17727 6301 0.5% 286.4 -- NAPINFO-AS-AP PT. NAP Info Lintas Nusa 20 - AS38388 6277 0.5% 418.5 -- BEN-AS-KR Bukbu District Office of Education in Seoul TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS32528 17284 1.2% 3456.8 -- ABBOTT Abbot Labs 2 - AS3454 7704 0.6% 1926.0 -- Universidad Autonoma de Nuevo Leon 3 - AS48877 4929 0.3% 1643.0 -- YUNICOM-AS Yunicom Ltd 4 - AS28519 4227 0.3% 1409.0 -- Universidad Autonoma de Guadalajara, A.C. 5 - AS46778 1194 0.1% 1194.0 -- PHSI-1996 - Prevea Health Services Inc 6 - AS49600 1133 0.1% 1133.0 -- LASEDA La Seda de Barcelona, S.A 7 - AS45882 905 0.1% 905.0 -- CODATEL-AS-AP Codatel Networks 8 - AS278 13069 0.9% 871.3 -- Universidad Nacional Autonoma de Mexico 9 - AS3 832 0.1% 735.0 -- EC-AS-IPV6 European Commission 10 - AS44609 2044 0.1% 681.3 -- FNA Fars News Agency Cultural Arts Institute 11 - AS45558 1926 0.1% 642.0 -- MPT-MM-AS-AP MYANMA POSTS AND TELECOMMUNICATIONS 12 - AS36429 639 0.1% 639.0 -- SVNP-COS - Select Systems Inc. 13 - AS3208 552 0.0% 552.0 -- ARN 14 - AS11915 4413 0.3% 490.3 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 15 - AS47824 477 0.0% 477.0 -- MERCURIOFVG-AS Insiel- Informatica per il sistema degli enti locali S.p.A 16 - AS6256 1380 0.1% 460.0 -- ALLTEL - ALLTEL Corporation 17 - AS37024 459 0.0% 459.0 -- Yoprov 18 - AS48068 447 0.0% 447.0 -- VISONIC Visonic Ltd 19 - AS44878 894 0.1% 447.0 -- RADIUS-RU-AS Radius Ltd. 20 - AS27322 440 0.0% 440.0 -- ISC-JNB1 Internet Systems Consortium, Inc. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 192.100.199.0/24 12967 0.9% AS278 -- Universidad Nacional Autonoma de Mexico 2 - 202.92.235.0/24 8877 0.6% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 3 - 130.36.34.0/24 8634 0.6% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.35.0/24 8634 0.6% AS32528 -- ABBOTT Abbot Labs 5 - 202.70.75.0/24 7824 0.5% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services, 6 - 91.217.214.0/24 7757 0.5% AS3320 -- DTAG Deutsche Telekom AG 7 - 200.23.202.0/24 7676 0.5% AS3454 -- Universidad Autonoma de Nuevo Leon 8 - 202.54.86.0/24 4479 0.3% AS4755 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 9 - 202.153.174.0/24 3297 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 10 - 205.91.160.0/20 2113 0.1% AS5976 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 11 - 67.214.72.0/22 2071 0.1% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 12 - 67.214.68.0/23 2053 0.1% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 13 - 193.238.133.0/24 2044 0.1% AS48877 -- YUNICOM-AS Yunicom Ltd 14 - 178.22.72.0/21 1950 0.1% AS44609 -- FNA Fars News Agency Cultural Arts Institute 15 - 65.181.192.0/23 1814 0.1% AS11492 -- CABLEONE - CABLE ONE, INC. 16 - 193.238.132.0/24 1443 0.1% AS48877 -- YUNICOM-AS Yunicom Ltd 17 - 193.238.134.0/23 1442 0.1% AS48877 -- YUNICOM-AS Yunicom Ltd 18 - 148.239.251.0/24 1423 0.1% AS28519 -- Universidad Autonoma de Guadalajara, A.C. 19 - 148.239.250.0/24 1402 0.1% AS28519 -- Universidad Autonoma de Guadalajara, A.C. 20 - 148.239.252.0/24 1402 0.1% AS28519 -- Universidad Autonoma de Guadalajara, A.C. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jul 1 17:00:01 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 1 Jul 2011 22:00:01 GMT Subject: The Cidr Report Message-ID: <201107012200.p61M01U5038164@wattle.apnic.net> This report has been generated at Fri Jul 1 21:12:20 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 24-06-11 364763 215129 25-06-11 364979 215058 26-06-11 364928 215214 27-06-11 365030 215211 28-06-11 365171 215456 29-06-11 365523 215773 30-06-11 365712 215870 01-07-11 365724 215557 AS Summary 38183 Number of ASes in routing system 16104 Number of ASes announcing only one prefix 3617 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 109927648 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 01Jul11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 365981 215530 150451 41.1% All ASes AS6389 3617 249 3368 93.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4766 2460 946 1514 61.5% KIXS-AS-KR Korea Telecom AS18566 1913 497 1416 74.0% COVAD - Covad Communications Co. AS10620 1541 205 1336 86.7% Telmex Colombia S.A. AS4323 1661 401 1260 75.9% TWTC - tw telecom holdings, inc. AS22773 1348 97 1251 92.8% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS19262 1450 370 1080 74.5% VZGNI-TRANSIT - Verizon Online LLC AS1785 1805 765 1040 57.6% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1477 465 1012 68.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS28573 1272 369 903 71.0% NET Servicos de Comunicao S.A. AS18101 934 145 789 84.5% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS7545 1543 761 782 50.7% TPG-INTERNET-AP TPG Internet Pty Ltd AS24560 1153 379 774 67.1% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS8151 1434 691 743 51.8% Uninet S.A. de C.V. AS4808 1053 336 717 68.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7552 793 83 710 89.5% VIETEL-AS-AP Vietel Corporation AS7303 1000 324 676 67.6% Telecom Argentina S.A. AS3356 1118 458 660 59.0% LEVEL3 Level 3 Communications AS17488 960 322 638 66.5% HATHWAY-NET-AP Hathway IP Over Cable Internet AS20115 1593 977 616 38.7% CHARTER-NET-HKY-NC - Charter Communications AS14420 685 81 604 88.2% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS17676 669 71 598 89.4% GIGAINFRA Softbank BB Corp. AS22561 940 360 580 61.7% DIGITAL-TELEPORT - Digital Teleport Inc. AS3549 992 420 572 57.7% GBLX Global Crossing Ltd. AS22047 576 32 544 94.4% VTR BANDA ANCHA S.A. AS4780 751 215 536 71.4% SEEDNET Digital United Inc. AS7011 1156 625 531 45.9% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS15475 524 10 514 98.1% NOL AS4804 586 87 499 85.2% MPX-AS Microplex PTY LTD AS17974 1835 1349 486 26.5% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia Total 38839 12090 26749 68.9% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 24.225.128.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/23 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.224.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.237.0/24 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.248.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 27.0.128.0/17 AS7514 MEX Media EXchange, Inc. 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.22.32.0/19 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 131.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.72.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.100.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.108.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.161.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.221.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.157.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.184.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.191.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.251.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 134.175.0.0/19 AS12124 THORN - Thorn Communications 138.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.36.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.59.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.94.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.97.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.99.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.117.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.118.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.121.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.122.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.185.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.186.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.204.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.219.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 141.138.192.0/20 AS35470 XL-AS XL Network 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 143.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 143.137.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 143.202.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 143.208.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 143.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.101.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.102.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.103.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.156.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.166.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.167.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.168.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.169.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.170.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.171.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.172.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.173.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.174.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.175.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.200.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.201.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.202.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.203.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.204.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.205.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.206.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.207.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.230.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.231.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.232.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.233.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.234.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.235.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.236.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.237.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.238.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.239.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.240.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.241.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.242.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.243.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.244.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.245.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.246.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.247.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.248.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.249.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.250.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.251.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.252.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.253.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.254.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 161.10.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.18.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.22.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.56.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.138.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.140.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.212.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.234.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.56.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.57.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.58.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.59.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.60.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.61.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.62.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.63.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.108.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.116.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.249.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.250.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.90.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.121.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.181.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.194.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.195.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.196.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.197.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.205.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.227.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.228.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.232.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.78.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.79.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.80.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.81.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.82.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.83.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.84.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.150.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.231.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.233.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.238.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.239.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.244.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.245.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.246.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.247.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.254.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 181.82.15.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.16.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.17.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 181.82.18.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 191.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.101.46.0/24 AS6503 Axtel, S.A.B. de C.V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.158.25.0/24 AS2717 CUMMINS-AS1 - Cummins Engine Co. Inc. 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.15.4.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.15.5.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.168.122.0/24 AS11489 BACI - Bell Canada 198.175.231.0/24 AS19262 VZGNI-TRANSIT - Verizon Online LLC 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.33.84.0/22 AS9911 CONNECTPLUS-AP Singapore Telecom 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.24.76.0/24 AS7195 Telecorp Colombia S.A. 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.58.101.0/24 AS45645 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.63.80.0/24 AS9557 PKTELECOM-AS-PK Paknet Limited Merged into PTCL 202.74.232.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.74.233.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.146.186.0/24 AS23655 SNAP-NZ-AS Snap Internet Limited 202.160.152.0/22 AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.18.156.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 204.10.232.0/21 AS33150 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.72.192.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.194.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.10.235.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From frnkblk at iname.com Sat Jul 2 08:46:03 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 2 Jul 2011 08:46:03 -0500 Subject: Looking for tw telecom folk to resolve IPv6 access to their site Message-ID: <000001cc38be$627b9630$2772c290$@iname.com> IPv6 access to TW Telecom's website, www.twtelecom.com, has been down almost continuously since Wednesday evening. For dual-stacked users browsing their site but not using Google Chrome this can results in timeouts. I reached out to their NOC twice. The second time the site did come back up for a few minutes, but then went down again. Is anyone from tw telecom on this list that can resolve this, or can forward this to a contact? Logs below (Central Time). Frank [07-01-2011 15:26:06] SERVICE ALERT: www_twtelecom_com;HTTPv6;CRITICAL;HARD;1;CRITICAL - Socket timeout after 10 seconds [07-01-2011 15:25:06] SERVICE ALERT: www_twtelecom_com;HTTPv6;CRITICAL;SOFT;1;CRITICAL - Socket timeout after 10 seconds [07-01-2011 15:04:56] SERVICE ALERT: www_twtelecom_com;HTTPv6;OK;HARD;1;HTTP OK: HTTP/1.1 200 OK - 24462 bytes in 0.338 second response time [06-29-2011 21:19:37] SERVICE ALERT: www_twtelecom_com;HTTPv6;CRITICAL;HARD;1;CRITICAL - Socket timeout after 10 seconds [06-29-2011 21:18:37] SERVICE ALERT: www_twtelecom_com;HTTPv6;CRITICAL;SOFT;1;CRITICAL - Socket timeout after 10 seconds server:/tmp# wget -6 www.twtelecom.com --2011-07-02 08:36:12-- http://www.twtelecom.com/ Resolving www.twtelecom.com... 2001:4870:800d:fe1::11 Connecting to www.twtelecom.com|2001:4870:800d:fe1::11|:80... failed: Connection timed out. Retrying. --2011-07-02 08:36:34-- (try: 2) http://www.twtelecom.com/ Connecting to www.twtelecom.com|2001:4870:800d:fe1::11|:80... failed: Connection timed out. Retrying. --2011-07-02 08:36:57-- (try: 3) http://www.twtelecom.com/ Connecting to www.twtelecom.com|2001:4870:800d:fe1::11|:80... failed: Connection timed out. From leigh.porter at ukbroadband.com Sat Jul 2 08:49:23 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Sat, 2 Jul 2011 13:49:23 +0000 Subject: Looking for tw telecom folk to resolve IPv6 access to their site In-Reply-To: <000001cc38be$627b9630$2772c290$@iname.com> References: <000001cc38be$627b9630$2772c290$@iname.com> Message-ID: <7A8BF982-161B-4F9C-9212-CD6B05244E36@ukbroadband.com> -- Leigh Porter On 2 Jul 2011, at 14:47, "Frank Bulk" wrote: > IPv6 access to TW Telecom's website, www.twtelecom.com, has been down almost > continuously since Wednesday evening. For dual-stacked users browsing their > site but not using Google Chrome this can results in timeouts. I reached > out to their NOC twice. The second time the site did come back up for a few > minutes, but then went down again. Is anyone from tw telecom on this list > that can resolve this, or can forward this to a contact? > > Logs below (Central Time). > > Frank > > [07-01-2011 15:26:06] SERVICE ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From pete at altadena.net Sat Jul 2 12:12:04 2011 From: pete at altadena.net (Pete Carah) Date: Sat, 02 Jul 2011 13:12:04 -0400 Subject: Looking for tw telecom folk to resolve IPv6 access to their site In-Reply-To: <7A8BF982-161B-4F9C-9212-CD6B05244E36@ukbroadband.com> References: <000001cc38be$627b9630$2772c290$@iname.com> <7A8BF982-161B-4F9C-9212-CD6B05244E36@ukbroadband.com> Message-ID: <4E0F5164.1010405@altadena.net> On 07/02/2011 09:49 AM, Leigh Porter wrote: > Missed something. Anyhow it is down for me too; v4 works and v6 doesn't using telnet to check. The linux version of firefox eventually (about 5 mins) displayed the page; (linux again) chrome did so right away. Wish both had a geek tool to show the actual connections... -- Pete From r.boissat at gmail.com Sat Jul 2 12:17:09 2011 From: r.boissat at gmail.com (Romain Boissat) Date: Sat, 2 Jul 2011 19:17:09 +0200 Subject: Looking for tw telecom folk to resolve IPv6 access to their site In-Reply-To: <4E0F5164.1010405@altadena.net> References: <000001cc38be$627b9630$2772c290$@iname.com> <7A8BF982-161B-4F9C-9212-CD6B05244E36@ukbroadband.com> <4E0F5164.1010405@altadena.net> Message-ID: Hi all On Sat, Jul 2, 2011 at 7:12 PM, Pete Carah wrote: > > The linux version of firefox eventually (about 5 mins) displayed the > page; (linux again) chrome did so right away. Wish both had a geek tool > to show the actual connections... On Google Chrome (and thus chromium), you should have access to chrome://net-internals/#events Net-internals tab exposes a lot of useful information :) -- Romain Boissat chroot-me.in From pete at altadena.net Sat Jul 2 12:29:12 2011 From: pete at altadena.net (Pete Carah) Date: Sat, 02 Jul 2011 13:29:12 -0400 Subject: Looking for tw telecom folk to resolve IPv6 access to their site In-Reply-To: References: <000001cc38be$627b9630$2772c290$@iname.com> <7A8BF982-161B-4F9C-9212-CD6B05244E36@ukbroadband.com> <4E0F5164.1010405@altadena.net> Message-ID: <4E0F5568.9060008@altadena.net> On 07/02/2011 01:17 PM, Romain Boissat wrote: > Hi all > > On Sat, Jul 2, 2011 at 7:12 PM, Pete Carah wrote: >> The linux version of firefox eventually (about 5 mins) displayed the >> page; (linux again) chrome did so right away. Wish both had a geek tool >> to show the actual connections... > > On Google Chrome (and thus chromium), you should have access to > chrome://net-internals/#events > > Net-internals tab exposes a lot of useful information :) It sure does, thanks. One mystery here is that the socket entries appear after some of the successful reads; the site started loading in the logs between the v6 and v4 socket entries. (though maybe v6 works once in a while?) And clearly twtelecom has traceroute blocked toward the web site but v4 and v6 end up looking similar; one hop without reverse dns after an obvious border router line, followed by lots of timeouts. -- Pete From frnkblk at iname.com Sat Jul 2 12:40:21 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 2 Jul 2011 12:40:21 -0500 Subject: Looking for tw telecom folk to resolve IPv6 access to their site In-Reply-To: <4E0F5164.1010405@altadena.net> References: <000001cc38be$627b9630$2772c290$@iname.com> <7A8BF982-161B-4F9C-9212-CD6B05244E36@ukbroadband.com> <4E0F5164.1010405@altadena.net> Message-ID: <000701cc38df$1e055470$5a0ffd50$@iname.com> I'd like to see someone develop a plugin that had some kind of battery-meter style display of what percentage of the page and its elements (in bytes) were obtained via v4 versus v6. Google Chrome's pseudo-happy eyeballs (HE) implementation helps with it loading almost right away. Frank -----Original Message----- From: Pete Carah [mailto:pete at altadena.net] Sent: Saturday, July 02, 2011 12:12 PM To: nanog at nanog.org Subject: Re: Looking for tw telecom folk to resolve IPv6 access to their site On 07/02/2011 09:49 AM, Leigh Porter wrote: > Missed something. Anyhow it is down for me too; v4 works and v6 doesn't using telnet to check. The linux version of firefox eventually (about 5 mins) displayed the page; (linux again) chrome did so right away. Wish both had a geek tool to show the actual connections... -- Pete From nanog at jima.tk Sat Jul 2 17:59:48 2011 From: nanog at jima.tk (Jima) Date: Sat, 02 Jul 2011 17:59:48 -0500 Subject: Looking for tw telecom folk to resolve IPv6 access to their site In-Reply-To: <000701cc38df$1e055470$5a0ffd50$@iname.com> References: <000001cc38be$627b9630$2772c290$@iname.com> <7A8BF982-161B-4F9C-9212-CD6B05244E36@ukbroadband.com> <4E0F5164.1010405@altadena.net> <000701cc38df$1e055470$5a0ffd50$@iname.com> Message-ID: <4E0FA2E4.3090904@jima.tk> On 2011-07-02 12:40, Frank Bulk wrote: > I'd like to see someone develop a plugin that had some kind of battery-meter > style display of what percentage of the page and its elements (in bytes) > were obtained via v4 versus v6. Using Chrome's dev channel (14.x), you can use experimental APIs and ipvfoo to see what IP protocols were used to reach the server for a page and its components: http://code.google.com/p/ipvfoo/ It's got a couple bugs (something to do with cached entries, I haven't quite puzzled it out), but it's evidently more telling than Firefox+ShowIP. AFAIK there's no byte counters or correlation between IPs and the elements that were fetched from them. Jima From frnkblk at iname.com Sat Jul 2 21:02:07 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 2 Jul 2011 21:02:07 -0500 Subject: Looking for tw telecom folk to resolve IPv6 access to their site In-Reply-To: <4E0FA2E4.3090904@jima.tk> References: <000001cc38be$627b9630$2772c290$@iname.com> <7A8BF982-161B-4F9C-9212-CD6B05244E36@ukbroadband.com> <4E0F5164.1010405@altadena.net> <000701cc38df$1e055470$5a0ffd50$@iname.com> <4E0FA2E4.3090904@jima.tk> Message-ID: <000801cc3925$36b05240$a410f6c0$@iname.com> Thanks. That's a bit more what I want than the other two plugins I use (which just tell me is that FQDN has a AAAA), but as you pointed out, ipvfoo doesn't give an indication of how much of that page is v4 or v6. Frank -----Original Message----- From: Jima [mailto:nanog at jima.tk] Sent: Saturday, July 02, 2011 6:00 PM To: nanog at nanog.org Subject: Re: Looking for tw telecom folk to resolve IPv6 access to their site On 2011-07-02 12:40, Frank Bulk wrote: > I'd like to see someone develop a plugin that had some kind of battery-meter > style display of what percentage of the page and its elements (in bytes) > were obtained via v4 versus v6. Using Chrome's dev channel (14.x), you can use experimental APIs and ipvfoo to see what IP protocols were used to reach the server for a page and its components: http://code.google.com/p/ipvfoo/ It's got a couple bugs (something to do with cached entries, I haven't quite puzzled it out), but it's evidently more telling than Firefox+ShowIP. AFAIK there's no byte counters or correlation between IPs and the elements that were fetched from them. Jima From scubacuda at gmail.com Mon Jul 4 09:34:11 2011 From: scubacuda at gmail.com (Rogelio) Date: Mon, 4 Jul 2011 11:34:11 -0300 Subject: cheapo UUFB solution for Cisco 7201 Message-ID: I've got a Cisco 7201 with about 500 L2TPv2 tunnels, and I suspect that UUFB (unknown unicast flooding) is resulting in spiking (I put an ACL on to kill broadcast traffic, so I'm sure that's not related). I've googled and don't see anything for the 7201, just the 7600 series. :/ i.e. http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/blocking.html Anyone have any suggestions on (something cheap) that I can put in front of this box to spare it from (what I suspect) is a gateway that unicast floods when a MAC address has aged? To add to my challenges, I'm in Brazil and importing gear is insanely effing difficult. :/ -- Also on LinkedIn? Feel free to connect if you too are an open networker: scubacuda at gmail.com From cmaurand at xyonet.com Mon Jul 4 16:40:56 2011 From: cmaurand at xyonet.com (Curtis Maurand) Date: Mon, 04 Jul 2011 17:40:56 -0400 Subject: Firewall Appliance Suggestions In-Reply-To: References: Message-ID: <4E123368.7020602@xyonet.com> On 6/30/2011 12:20 PM, Suresh Rajagopalan wrote: > Linux + iptables + fwbuilder > > > > On Thu, Jun 30, 2011 at 8:50 AM, Blake T. Pfankuch wrote: >> Howdy, >> I am looking for something a little unique in a bit of a tough situation with some sticky requirements. First off, my requirements are a little weird and I can't bend them a whole lot due to stipulations being put on me. I am in need a firewall appliance which can be run on VMware vSphere, with IPSEC support for multiple Phase 2 negotiations within a single Phase 1. I am also in need of something that can support VLAN interfaces on the LAN side, and ideally something with multi zoning so I can keep LAN side networks separate from each without ridiculous firewall rules. Meaning build a zone for "Customer network 1" and it displays separately (ease of management and firewall config hopefully). I need a minimum of 10 "zones" on LAN side (/29 or /30), and NAT support for LAN to WAN (to dedicate all outbound connections to a single IP from a specific zone), ideally something extremely scalable (100-200 zones). And here is the super fun part! I need something that is going to be web managed primarily as minions will be doing most of the day to day maintenance, or very simple CLI config. Willing to pay for something if need be, but looking for something that can easily handly 50-100mbit of throughput. >> >> Any Ideas? >> >> Thanks! >> >> Blake Pfankuch >> Vyatta. They have an appliance on their website. --Curtis From jean.clerymrs at gmail.com Mon Jul 4 17:58:51 2011 From: jean.clerymrs at gmail.com (Jean CLERY) Date: Tue, 5 Jul 2011 00:58:51 +0200 Subject: Firewall Appliance Suggestions In-Reply-To: <4E123368.7020602@xyonet.com> References: <4E123368.7020602@xyonet.com> Message-ID: Hi Blake Try www.netasq.com Regards, Jean CLERY -----Message d'origine----- De?: Curtis Maurand [mailto:cmaurand at xyonet.com] Envoy??: lundi 4 juillet 2011 23:41 ??: nanog at nanog.org Objet?: Re: Firewall Appliance Suggestions On 6/30/2011 12:20 PM, Suresh Rajagopalan wrote: > Linux + iptables + fwbuilder > > > > On Thu, Jun 30, 2011 at 8:50 AM, Blake T. Pfankuch wrote: >> Howdy, >> I am looking for something a little unique in a bit of a tough situation with some sticky requirements. First off, my requirements are a little weird and I can't bend them a whole lot due to stipulations being put on me. I am in need a firewall appliance which can be run on VMware vSphere, with IPSEC support for multiple Phase 2 negotiations within a single Phase 1. I am also in need of something that can support VLAN interfaces on the LAN side, and ideally something with multi zoning so I can keep LAN side networks separate from each without ridiculous firewall rules. Meaning build a zone for "Customer network 1" and it displays separately (ease of management and firewall config hopefully). I need a minimum of 10 "zones" on LAN side (/29 or /30), and NAT support for LAN to WAN (to dedicate all outbound connections to a single IP from a specific zone), ideally something extremely scalable (100-200 zones). And here is the super fun part! I need something that is going to be web managed primarily as minions will be doing most of the day to day maintenance, or very simple CLI config. Willing to pay for something if need be, but looking for something that can easily handly 50-100mbit of throughput. >> >> Any Ideas? >> >> Thanks! >> >> Blake Pfankuch >> Vyatta. They have an appliance on their website. --Curtis From pnowak at batblue.com Mon Jul 4 23:50:45 2011 From: pnowak at batblue.com (Peter Nowak) Date: Tue, 5 Jul 2011 00:50:45 -0400 Subject: Firewall Appliance Suggestions In-Reply-To: References: <596B74B410EE6B4CA8A30C3AF1A155EA01A33E@RWC-MBX1.corp.seven.com> <72b4b8bc-562b-4963-b5e0-e6094834d615@mail-1.01.com> Message-ID: <1B8D4E1C-BA43-4257-89DA-7D6EBB154927@batblue.com> They don't have a VM yet - coming soon - but you may take a look at Palo Alto Networks. Having just a regular stateful firewall is not a good idea anymore... Peter Nowak On Jul 1, 2011, at 12:35 AM, Blake T. Pfankuch wrote: > Normally I would agree with you as far as separate instances, however this will be in a situation where we pay ridiculous amounts for cpu and memory, so a single instance is what we are shooting for (remember those ridiculous requirements). I am planning to do some further testing with vyatta and pfsense. Thanks you all for the on list and off list responses! > > -----Original Message----- > From: Sargun Dhillon [mailto:sargun at sargun.me] > Sent: Thursday, June 30, 2011 9:56 PM > To: George Bonser > Cc: Blake T. Pfankuch; NANOG (nanog at nanog.org) > Subject: Re: Firewall Appliance Suggestions > > > > ----- Original Message ----- >> From: "George Bonser" >> To: "Blake T. Pfankuch" , "NANOG (nanog at nanog.org)" >> >> Sent: Thursday, June 30, 2011 11:30:53 AM >> Subject: RE: Firewall Appliance Suggestions >> >>> Willing to pay for something if need be, but looking for something >>> that can easily handly 50-100mbit of throughput. >>> >>> Any Ideas? >>> >>> Thanks! >>> >>> Blake Pfankuch >> >> >> I might also look at Vyatta. They have appliances or you can run the >> software on your own hardware. >> >> >> >> >> >> > > I would not go with Vyatta if you're doing anything complex. The number of random bugs I've hit with their software are numerous. In the right hands, it's a powerful tool. And it seems to fit your solution really well. > > If I were in your shoes, I would install two instances that would handle the "edge" of the cluster, and then an instance per customer (lightweight, they sell a VMWare image). Then use dynamic routing to direct traffic to the customer (assign each customer their own ASN, and peer with their instance). So, worse case scenario, the NOC monkey only breaks one customer's gear. > > > -- > Sargun Dhillon > VoIP (US): +1-925-235-1105 Peter Nowak Manager, Technical Services Bat Blue Corporation | Integrity . Privacy . Availability p. 212.461.3322 x3020 | f. 212.584.9999 | w. www.batblue.com Bat Blue's AS: 25885 | BGP Policy | Peering Policy Bat Blue's Legal Notice Receive Bat Blue's DSB Intelligence Report Bat Blue is proud to be the Official WiFi Provider for ESPN's X-Games From sanju_ddd at yahoo.com Tue Jul 5 10:56:56 2011 From: sanju_ddd at yahoo.com (chavan sanjay) Date: Tue, 5 Jul 2011 08:56:56 -0700 (PDT) Subject: MX 80 advantages and shortcomings In-Reply-To: Message-ID: <1309881416.62321.YahooMailClassic@web110609.mail.gq1.yahoo.com> Hi Team, ? Can anyone enlighten me on the pros and cons of MX 80 platform ? Thanks Sanjay C.P. --- On Tue, 7/5/11, nanog-request at nanog.org wrote: From: nanog-request at nanog.org Subject: NANOG Digest, Vol 42, Issue 5 To: nanog at nanog.org Date: Tuesday, July 5, 2011, 5:30 PM Send NANOG mailing list submissions to ??? nanog at nanog.org To subscribe or unsubscribe via the World Wide Web, visit ??? https://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to ??? nanog-request at nanog.org You can reach the person managing the list at ??? nanog-owner at nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: ???1. cheapo UUFB solution for Cisco 7201 (Rogelio) ???2. Re: Firewall Appliance Suggestions (Curtis Maurand) ???3. RE: Firewall Appliance Suggestions (Jean CLERY) ???4. Re: Firewall Appliance Suggestions (Peter Nowak) ---------------------------------------------------------------------- Message: 1 Date: Mon, 4 Jul 2011 11:34:11 -0300 From: Rogelio Subject: cheapo UUFB solution for Cisco 7201 To: nanog at nanog.org Message-ID: ??? Content-Type: text/plain; charset=ISO-8859-1 I've got a Cisco 7201 with about 500 L2TPv2 tunnels, and I suspect that UUFB (unknown unicast flooding) is resulting in spiking (I put an ACL on to kill broadcast traffic, so I'm sure that's not related). I've googled and don't see anything for the 7201, just the 7600 series.? :/ i.e. http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/blocking.html Anyone have any suggestions on (something cheap) that I can put in front of this box to spare it from (what I suspect) is a gateway that unicast floods when a MAC address has aged? To add to my challenges, I'm in Brazil and importing gear is insanely effing difficult.? :/ -- Also on LinkedIn?? Feel free to connect if you too are an open networker: scubacuda at gmail.com ------------------------------ Message: 2 Date: Mon, 04 Jul 2011 17:40:56 -0400 From: Curtis Maurand Subject: Re: Firewall Appliance Suggestions To: nanog at nanog.org Message-ID: <4E123368.7020602 at xyonet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 6/30/2011 12:20 PM, Suresh Rajagopalan wrote: > Linux + iptables + fwbuilder > > > > On Thu, Jun 30, 2011 at 8:50 AM, Blake T. Pfankuch? wrote: >> Howdy, >>? ? ? ? ? ? ? ???I am looking for something a little unique in a bit of a tough situation with some sticky requirements.? First off, my requirements are a little weird and I can't bend them a whole lot due to stipulations being put on me.? I am in need a firewall appliance which can be run on VMware vSphere, with IPSEC support for multiple Phase 2 negotiations within a single Phase 1.? I am also in need of something that can support VLAN interfaces on the LAN side, and ideally something with multi zoning so I can keep LAN side networks separate from each without ridiculous firewall rules.? Meaning build a zone for "Customer network 1" and it displays separately (ease of management and firewall config hopefully).? I need a minimum of 10 "zones" on LAN side (/29 or /30), and NAT support for LAN to WAN (to dedicate all outbound connections to a single IP from a specific zone), ideally something extremely scalable (100-200 zones).? And here is the super fun part!? I need something that is going to be web managed primarily as minions will be doing most of the day to day maintenance, or very simple CLI config.? Willing to pay for something if need be, but looking for something that can easily handly 50-100mbit of throughput. >> >> Any Ideas? >> >> Thanks! >> >> Blake Pfankuch >> Vyatta.? They have an appliance on their website. --Curtis ------------------------------ Message: 3 Date: Tue, 5 Jul 2011 00:58:51 +0200 From: "Jean CLERY" Subject: RE: Firewall Appliance Suggestions To: "'Curtis Maurand'" ,??? Message-ID: Content-Type: text/plain;??? charset="iso-8859-1" Hi Blake Try www.netasq.com Regards, Jean CLERY -----Message d'origine----- De?: Curtis Maurand [mailto:cmaurand at xyonet.com] Envoy??: lundi 4 juillet 2011 23:41 ??: nanog at nanog.org Objet?: Re: Firewall Appliance Suggestions On 6/30/2011 12:20 PM, Suresh Rajagopalan wrote: > Linux + iptables + fwbuilder > > > > On Thu, Jun 30, 2011 at 8:50 AM, Blake T. Pfankuch wrote: >> Howdy, >>? ? ? ? ? ? ? ???I am looking for something a little unique in a bit of a tough situation with some sticky requirements.? First off, my requirements are a little weird and I can't bend them a whole lot due to stipulations being put on me.? I am in need a firewall appliance which can be run on VMware vSphere, with IPSEC support for multiple Phase 2 negotiations within a single Phase 1.? I am also in need of something that can support VLAN interfaces on the LAN side, and ideally something with multi zoning so I can keep LAN side networks separate from each without ridiculous firewall rules. Meaning build a zone for "Customer network 1" and it displays separately (ease of management and firewall config hopefully).? I need a minimum of 10 "zones" on LAN side (/29 or /30), and NAT support for LAN to WAN (to dedicate all outbound connections to a single IP from a specific zone), ideally something extremely scalable (100-200 zones).? And here is the super fun part!? I need something that is going to be web managed primarily as minions will be doing most of the day to day maintenance, or very simple CLI config.? Willing to pay for something if need be, but looking for something that can easily handly 50-100mbit of throughput. >> >> Any Ideas? >> >> Thanks! >> >> Blake Pfankuch >> Vyatta.? They have an appliance on their website. --Curtis ------------------------------ Message: 4 Date: Tue, 5 Jul 2011 00:50:45 -0400 From: Peter Nowak Subject: Re: Firewall Appliance Suggestions To: Blake T. Pfankuch Cc: "NANOG \(nanog at nanog.org\)" Message-ID: <1B8D4E1C-BA43-4257-89DA-7D6EBB154927 at batblue.com> Content-Type: text/plain;??? charset=us-ascii They don't have a VM yet - coming soon - but you may take a look at Palo Alto Networks. Having just a regular stateful firewall is not a good idea anymore... Peter Nowak On Jul 1, 2011, at 12:35 AM, Blake T. Pfankuch wrote: > Normally I would agree with you as far as separate instances, however this will be in a situation where we pay ridiculous amounts for cpu and memory, so a single instance is what we are shooting for (remember those ridiculous requirements).? I am planning to do some further testing with vyatta and pfsense.? Thanks you all for the on list and off list responses! > > -----Original Message----- > From: Sargun Dhillon [mailto:sargun at sargun.me] > Sent: Thursday, June 30, 2011 9:56 PM > To: George Bonser > Cc: Blake T. Pfankuch; NANOG (nanog at nanog.org) > Subject: Re: Firewall Appliance Suggestions > > > > ----- Original Message ----- >> From: "George Bonser" >> To: "Blake T. Pfankuch" , "NANOG (nanog at nanog.org)" >> >> Sent: Thursday, June 30, 2011 11:30:53 AM >> Subject: RE: Firewall Appliance Suggestions >> >>> Willing to pay for something if need be, but looking for something >>> that can easily handly 50-100mbit of throughput. >>> >>> Any Ideas? >>> >>> Thanks! >>> >>> Blake Pfankuch >> >> >> I might also look at Vyatta.? They have appliances or you can run the >> software on your own hardware. >> >> >> >> >> >> > > I would not go with Vyatta if you're doing anything complex. The number of random bugs I've hit with their software are numerous. In the right hands, it's a powerful tool. And it seems to fit your solution really well. > > If I were in your shoes, I would install two instances that would handle the "edge" of the cluster, and then an instance per customer (lightweight, they sell a VMWare image). Then use dynamic routing to direct traffic to the customer (assign each customer their own ASN, and peer with their instance). So, worse case scenario, the NOC monkey only breaks one customer's gear. > > > -- > Sargun Dhillon > VoIP (US): +1-925-235-1105 Peter Nowak Manager, Technical Services Bat Blue Corporation | Integrity . Privacy . Availability p. 212.461.3322 x3020 | f. 212.584.9999 | w. www.batblue.com Bat Blue's AS: 25885 | BGP Policy | Peering Policy Bat Blue's Legal Notice Receive Bat Blue's DSB Intelligence Report Bat Blue is proud to be the Official WiFi Provider for ESPN's X-Games ------------------------------ _______________________________________________ NANOG mailing list NANOG at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog End of NANOG Digest, Vol 42, Issue 5 ************************************ From sthaug at nethelp.no Tue Jul 5 11:22:02 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 05 Jul 2011 18:22:02 +0200 (CEST) Subject: MX 80 advantages and shortcomings In-Reply-To: <1309881416.62321.YahooMailClassic@web110609.mail.gq1.yahoo.com> References: <1309881416.62321.YahooMailClassic@web110609.mail.gq1.yahoo.com> Message-ID: <20110705.182202.74728451.sthaug@nethelp.no> > Can anyone enlighten me on the pros and cons of MX 80 platform There's been quite a bit of discussion about the MX80 on the juniper-nsp list, and I recommend asking on that list instead (if you don't find what you already need in the list archives). As a general rule, people are more likely to be able to help you if you specify *what* you might want to use the MX80 for. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From paul at paulstewart.org Tue Jul 5 11:48:45 2011 From: paul at paulstewart.org (Paul Stewart) Date: Tue, 5 Jul 2011 12:48:45 -0400 (EDT) Subject: MX 80 advantages and shortcomings In-Reply-To: <1309881416.62321.YahooMailClassic@web110609.mail.gq1.yahoo.com> References: <1309881416.62321.YahooMailClassic@web110609.mail.gq1.yahoo.com> Message-ID: Pros - small footprint, cost, feature rich Cons - no redundancy (other than power), 1/3rd the processor power Paul On Tue, 5 Jul 2011, chavan sanjay wrote: > Hi Team, > ? > Can anyone enlighten me on the pros and cons of MX 80 platform > ? > Thanks > > Sanjay C.P. > > --- On Tue, 7/5/11, nanog-request at nanog.org wrote: > > > From: nanog-request at nanog.org > Subject: NANOG Digest, Vol 42, Issue 5 > To: nanog at nanog.org > Date: Tuesday, July 5, 2011, 5:30 PM > > > Send NANOG mailing list submissions to > ??? nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > ??? https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > ??? nanog-request at nanog.org > > You can reach the person managing the list at > ??? nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > ???1. cheapo UUFB solution for Cisco 7201 (Rogelio) > ???2. Re: Firewall Appliance Suggestions (Curtis Maurand) > ???3. RE: Firewall Appliance Suggestions (Jean CLERY) > ???4. Re: Firewall Appliance Suggestions (Peter Nowak) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 4 Jul 2011 11:34:11 -0300 > From: Rogelio > Subject: cheapo UUFB solution for Cisco 7201 > To: nanog at nanog.org > Message-ID: > ??? > Content-Type: text/plain; charset=ISO-8859-1 > > I've got a Cisco 7201 with about 500 L2TPv2 tunnels, and I suspect > that UUFB (unknown unicast flooding) is resulting in spiking (I put an > ACL on to kill broadcast traffic, so I'm sure that's not related). > I've googled and don't see anything for the 7201, just the 7600 > series.? :/ > > i.e. http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/blocking.html > > Anyone have any suggestions on (something cheap) that I can put in > front of this box to spare it from (what I suspect) is a gateway that > unicast floods when a MAC address has aged? > > To add to my challenges, I'm in Brazil and importing gear is insanely > effing difficult.? :/ > > -- > Also on LinkedIn?? Feel free to connect if you too are an open > networker: scubacuda at gmail.com > > > > ------------------------------ > > Message: 2 > Date: Mon, 04 Jul 2011 17:40:56 -0400 > From: Curtis Maurand > Subject: Re: Firewall Appliance Suggestions > To: nanog at nanog.org > Message-ID: <4E123368.7020602 at xyonet.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 6/30/2011 12:20 PM, Suresh Rajagopalan wrote: >> Linux + iptables + fwbuilder >> >> >> >> On Thu, Jun 30, 2011 at 8:50 AM, Blake T. Pfankuch? wrote: >>> Howdy, >>> ? ? ? ? ? ? ? ???I am looking for something a little unique in a bit of a tough situation with some sticky requirements.? First off, my requirements are a little weird and I can't bend them a whole lot due to stipulations being put on me.? I am in need a firewall appliance which can be run on VMware vSphere, with IPSEC support for multiple Phase 2 negotiations within a single Phase 1.? I am also in need of something that can support VLAN interfaces on the LAN side, and ideally something with multi zoning so I can keep LAN side networks separate from each without ridiculous firewall rules.? Meaning build a zone for "Customer network 1" and it displays separately (ease of management and firewall config hopefully).? I need a minimum of 10 "zones" on LAN side (/29 or /30), and NAT support for LAN to WAN (to dedicate all outbound connections to a single IP from a specific zone), ideally something extremely scalable (100-200 zones).? And here > is the super fun part!? I need something that is going to be web managed primarily as minions will be doing most of the day to day maintenance, or very simple CLI config.? Willing to pay for something if need be, but looking for something that can easily handly 50-100mbit of throughput. >>> >>> Any Ideas? >>> >>> Thanks! >>> >>> Blake Pfankuch >>> > Vyatta.? They have an appliance on their website. > > --Curtis > > > > > ------------------------------ > > Message: 3 > Date: Tue, 5 Jul 2011 00:58:51 +0200 > From: "Jean CLERY" > Subject: RE: Firewall Appliance Suggestions > To: "'Curtis Maurand'" ,??? > Message-ID: > Content-Type: text/plain;??? charset="iso-8859-1" > > Hi Blake > Try www.netasq.com > > Regards, > Jean CLERY > > > -----Message d'origine----- > De?: Curtis Maurand [mailto:cmaurand at xyonet.com] > Envoy??: lundi 4 juillet 2011 23:41 > ??: nanog at nanog.org > Objet?: Re: Firewall Appliance Suggestions > > On 6/30/2011 12:20 PM, Suresh Rajagopalan wrote: >> Linux + iptables + fwbuilder >> >> >> >> On Thu, Jun 30, 2011 at 8:50 AM, Blake T. Pfankuch > wrote: >>> Howdy, >>> ? ? ? ? ? ? ? ???I am looking for something a little unique in a bit of a > tough situation with some sticky requirements.? First off, my requirements > are a little weird and I can't bend them a whole lot due to stipulations > being put on me.? I am in need a firewall appliance which can be run on > VMware vSphere, with IPSEC support for multiple Phase 2 negotiations within > a single Phase 1.? I am also in need of something that can support VLAN > interfaces on the LAN side, and ideally something with multi zoning so I can > keep LAN side networks separate from each without ridiculous firewall rules. > Meaning build a zone for "Customer network 1" and it displays separately > (ease of management and firewall config hopefully).? I need a minimum of 10 > "zones" on LAN side (/29 or /30), and NAT support for LAN to WAN (to > dedicate all outbound connections to a single IP from a specific zone), > ideally something extremely scalable (100-200 zones).? And here is the super > fun part!? I need something that is going to be web managed primarily as > minions will be doing most of the day to day maintenance, or very simple CLI > config.? Willing to pay for something if need be, but looking for something > that can easily handly 50-100mbit of throughput. >>> >>> Any Ideas? >>> >>> Thanks! >>> >>> Blake Pfankuch >>> > Vyatta.? They have an appliance on their website. > > --Curtis > > > > > > ------------------------------ > > Message: 4 > Date: Tue, 5 Jul 2011 00:50:45 -0400 > From: Peter Nowak > Subject: Re: Firewall Appliance Suggestions > To: Blake T. Pfankuch > Cc: "NANOG \(nanog at nanog.org\)" > Message-ID: <1B8D4E1C-BA43-4257-89DA-7D6EBB154927 at batblue.com> > Content-Type: text/plain;??? charset=us-ascii > > They don't have a VM yet - coming soon - but you may take a look at Palo Alto Networks. Having just a regular stateful firewall is not a good idea anymore... > > Peter Nowak > > On Jul 1, 2011, at 12:35 AM, Blake T. Pfankuch wrote: > >> Normally I would agree with you as far as separate instances, however this will be in a situation where we pay ridiculous amounts for cpu and memory, so a single instance is what we are shooting for (remember those ridiculous requirements).? I am planning to do some further testing with vyatta and pfsense.? Thanks you all for the on list and off list responses! >> >> -----Original Message----- >> From: Sargun Dhillon [mailto:sargun at sargun.me] >> Sent: Thursday, June 30, 2011 9:56 PM >> To: George Bonser >> Cc: Blake T. Pfankuch; NANOG (nanog at nanog.org) >> Subject: Re: Firewall Appliance Suggestions >> >> >> >> ----- Original Message ----- >>> From: "George Bonser" >>> To: "Blake T. Pfankuch" , "NANOG (nanog at nanog.org)" >>> >>> Sent: Thursday, June 30, 2011 11:30:53 AM >>> Subject: RE: Firewall Appliance Suggestions >>> >>>> Willing to pay for something if need be, but looking for something >>>> that can easily handly 50-100mbit of throughput. >>>> >>>> Any Ideas? >>>> >>>> Thanks! >>>> >>>> Blake Pfankuch >>> >>> >>> I might also look at Vyatta.? They have appliances or you can run the >>> software on your own hardware. >>> >>> >>> >>> >>> >>> >> >> I would not go with Vyatta if you're doing anything complex. The number of random bugs I've hit with their software are numerous. In the right hands, it's a powerful tool. And it seems to fit your solution really well. >> >> If I were in your shoes, I would install two instances that would handle the "edge" of the cluster, and then an instance per customer (lightweight, they sell a VMWare image). Then use dynamic routing to direct traffic to the customer (assign each customer their own ASN, and peer with their instance). So, worse case scenario, the NOC monkey only breaks one customer's gear. >> >> >> -- >> Sargun Dhillon >> VoIP (US): +1-925-235-1105 > > Peter Nowak > Manager, Technical Services > Bat Blue Corporation | Integrity . Privacy . Availability > p. 212.461.3322 x3020 | f. 212.584.9999 | w. www.batblue.com > Bat Blue's AS: 25885 | BGP Policy | Peering Policy > Bat Blue's Legal Notice > > Receive Bat Blue's DSB Intelligence Report > > Bat Blue is proud to be the Official WiFi Provider for ESPN's X-Games > > > > > ------------------------------ > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > > End of NANOG Digest, Vol 42, Issue 5 > ************************************ > From joelja at bogus.com Tue Jul 5 11:59:55 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 5 Jul 2011 09:59:55 -0700 Subject: MX 80 advantages and shortcomings In-Reply-To: <1309881416.62321.YahooMailClassic@web110609.mail.gq1.yahoo.com> References: <1309881416.62321.YahooMailClassic@web110609.mail.gq1.yahoo.com> Message-ID: <6277C79F-B6C4-48D0-AC2D-76390F4FAA3C@bogus.com> I'd consult the list archive, since theres a couple recent and fairly lengthy threads on this. joel On Jul 5, 2011, at 8:56 AM, chavan sanjay wrote: > Hi Team, > > Can anyone enlighten me on the pros and cons of MX 80 platform > > Thanks > > Sanjay C.P. > > --- On Tue, 7/5/11, nanog-request at nanog.org wrote: > > > From: nanog-request at nanog.org > Subject: NANOG Digest, Vol 42, Issue 5 > To: nanog at nanog.org > Date: Tuesday, July 5, 2011, 5:30 PM > > > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. cheapo UUFB solution for Cisco 7201 (Rogelio) > 2. Re: Firewall Appliance Suggestions (Curtis Maurand) > 3. RE: Firewall Appliance Suggestions (Jean CLERY) > 4. Re: Firewall Appliance Suggestions (Peter Nowak) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 4 Jul 2011 11:34:11 -0300 > From: Rogelio > Subject: cheapo UUFB solution for Cisco 7201 > To: nanog at nanog.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > I've got a Cisco 7201 with about 500 L2TPv2 tunnels, and I suspect > that UUFB (unknown unicast flooding) is resulting in spiking (I put an > ACL on to kill broadcast traffic, so I'm sure that's not related). > I've googled and don't see anything for the 7201, just the 7600 > series. :/ > > i.e. http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/blocking.html > > Anyone have any suggestions on (something cheap) that I can put in > front of this box to spare it from (what I suspect) is a gateway that > unicast floods when a MAC address has aged? > > To add to my challenges, I'm in Brazil and importing gear is insanely > effing difficult. :/ > > -- > Also on LinkedIn? Feel free to connect if you too are an open > networker: scubacuda at gmail.com > > > > ------------------------------ > > Message: 2 > Date: Mon, 04 Jul 2011 17:40:56 -0400 > From: Curtis Maurand > Subject: Re: Firewall Appliance Suggestions > To: nanog at nanog.org > Message-ID: <4E123368.7020602 at xyonet.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 6/30/2011 12:20 PM, Suresh Rajagopalan wrote: >> Linux + iptables + fwbuilder >> >> >> >> On Thu, Jun 30, 2011 at 8:50 AM, Blake T. Pfankuch wrote: >>> Howdy, >>> I am looking for something a little unique in a bit of a tough situation with some sticky requirements. First off, my requirements are a little weird and I can't bend them a whole lot due to stipulations being put on me. I am in need a firewall appliance which can be run on VMware vSphere, with IPSEC support for multiple Phase 2 negotiations within a single Phase 1. I am also in need of something that can support VLAN interfaces on the LAN side, and ideally something with multi zoning so I can keep LAN side networks separate from each without ridiculous firewall rules. Meaning build a zone for "Customer network 1" and it displays separately (ease of management and firewall config hopefully). I need a minimum of 10 "zones" on LAN side (/29 or /30), and NAT support for LAN to WAN (to dedicate all outbound connections to a single IP from a specific zone), ideally something extremely scalable (100-200 zones). And here > is the super fun part! I need something that is going to be web managed primarily as minions will be doing most of the day to day maintenance, or very simple CLI config. Willing to pay for something if need be, but looking for something that can easily handly 50-100mbit of throughput. >>> >>> Any Ideas? >>> >>> Thanks! >>> >>> Blake Pfankuch >>> > Vyatta. They have an appliance on their website. > > --Curtis > > > > > ------------------------------ > > Message: 3 > Date: Tue, 5 Jul 2011 00:58:51 +0200 > From: "Jean CLERY" > Subject: RE: Firewall Appliance Suggestions > To: "'Curtis Maurand'" , > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > Hi Blake > Try www.netasq.com > > Regards, > Jean CLERY > > > -----Message d'origine----- > De?: Curtis Maurand [mailto:cmaurand at xyonet.com] > Envoy??: lundi 4 juillet 2011 23:41 > ??: nanog at nanog.org > Objet?: Re: Firewall Appliance Suggestions > > On 6/30/2011 12:20 PM, Suresh Rajagopalan wrote: >> Linux + iptables + fwbuilder >> >> >> >> On Thu, Jun 30, 2011 at 8:50 AM, Blake T. Pfankuch > wrote: >>> Howdy, >>> I am looking for something a little unique in a bit of a > tough situation with some sticky requirements. First off, my requirements > are a little weird and I can't bend them a whole lot due to stipulations > being put on me. I am in need a firewall appliance which can be run on > VMware vSphere, with IPSEC support for multiple Phase 2 negotiations within > a single Phase 1. I am also in need of something that can support VLAN > interfaces on the LAN side, and ideally something with multi zoning so I can > keep LAN side networks separate from each without ridiculous firewall rules. > Meaning build a zone for "Customer network 1" and it displays separately > (ease of management and firewall config hopefully). I need a minimum of 10 > "zones" on LAN side (/29 or /30), and NAT support for LAN to WAN (to > dedicate all outbound connections to a single IP from a specific zone), > ideally something extremely scalable (100-200 zones). And here is the super > fun part! I need something that is going to be web managed primarily as > minions will be doing most of the day to day maintenance, or very simple CLI > config. Willing to pay for something if need be, but looking for something > that can easily handly 50-100mbit of throughput. >>> >>> Any Ideas? >>> >>> Thanks! >>> >>> Blake Pfankuch >>> > Vyatta. They have an appliance on their website. > > --Curtis > > > > > > ------------------------------ > > Message: 4 > Date: Tue, 5 Jul 2011 00:50:45 -0400 > From: Peter Nowak > Subject: Re: Firewall Appliance Suggestions > To: Blake T. Pfankuch > Cc: "NANOG \(nanog at nanog.org\)" > Message-ID: <1B8D4E1C-BA43-4257-89DA-7D6EBB154927 at batblue.com> > Content-Type: text/plain; charset=us-ascii > > They don't have a VM yet - coming soon - but you may take a look at Palo Alto Networks. Having just a regular stateful firewall is not a good idea anymore... > > Peter Nowak > > On Jul 1, 2011, at 12:35 AM, Blake T. Pfankuch wrote: > >> Normally I would agree with you as far as separate instances, however this will be in a situation where we pay ridiculous amounts for cpu and memory, so a single instance is what we are shooting for (remember those ridiculous requirements). I am planning to do some further testing with vyatta and pfsense. Thanks you all for the on list and off list responses! >> >> -----Original Message----- >> From: Sargun Dhillon [mailto:sargun at sargun.me] >> Sent: Thursday, June 30, 2011 9:56 PM >> To: George Bonser >> Cc: Blake T. Pfankuch; NANOG (nanog at nanog.org) >> Subject: Re: Firewall Appliance Suggestions >> >> >> >> ----- Original Message ----- >>> From: "George Bonser" >>> To: "Blake T. Pfankuch" , "NANOG (nanog at nanog.org)" >>> >>> Sent: Thursday, June 30, 2011 11:30:53 AM >>> Subject: RE: Firewall Appliance Suggestions >>> >>>> Willing to pay for something if need be, but looking for something >>>> that can easily handly 50-100mbit of throughput. >>>> >>>> Any Ideas? >>>> >>>> Thanks! >>>> >>>> Blake Pfankuch >>> >>> >>> I might also look at Vyatta. They have appliances or you can run the >>> software on your own hardware. >>> >>> >>> >>> >>> >>> >> >> I would not go with Vyatta if you're doing anything complex. The number of random bugs I've hit with their software are numerous. In the right hands, it's a powerful tool. And it seems to fit your solution really well. >> >> If I were in your shoes, I would install two instances that would handle the "edge" of the cluster, and then an instance per customer (lightweight, they sell a VMWare image). Then use dynamic routing to direct traffic to the customer (assign each customer their own ASN, and peer with their instance). So, worse case scenario, the NOC monkey only breaks one customer's gear. >> >> >> -- >> Sargun Dhillon >> VoIP (US): +1-925-235-1105 > > Peter Nowak > Manager, Technical Services > Bat Blue Corporation | Integrity . Privacy . Availability > p. 212.461.3322 x3020 | f. 212.584.9999 | w. www.batblue.com > Bat Blue's AS: 25885 | BGP Policy | Peering Policy > Bat Blue's Legal Notice > > Receive Bat Blue's DSB Intelligence Report > > Bat Blue is proud to be the Official WiFi Provider for ESPN's X-Games > > > > > ------------------------------ > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > > End of NANOG Digest, Vol 42, Issue 5 > ************************************ > From cra at WPI.EDU Tue Jul 5 12:18:32 2011 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 5 Jul 2011 13:18:32 -0400 Subject: MX 80 advantages and shortcomings In-Reply-To: References: <1309881416.62321.YahooMailClassic@web110609.mail.gq1.yahoo.com> Message-ID: <20110705171832.GC18691@angus.ind.WPI.EDU> On Tue, Jul 05, 2011 at 12:48:45PM -0400, Paul Stewart wrote: > Pros - small footprint, cost, feature rich > Cons - no redundancy (other than power), 1/3rd the processor power cons - being a different CPU architecture from its bigger cousins, features tend to not appear at the same time on MX80 as the others. From fernando at gont.com.ar Tue Jul 5 16:11:44 2011 From: fernando at gont.com.ar (Fernando Gont) Date: Tue, 05 Jul 2011 18:11:44 -0300 Subject: Fwd: RFC 6274 on Security Assessment of the Internet Protocol Version 4 Message-ID: <4E137E10.9090608@gont.com.ar> FYI -------- Original Message -------- Subject: RFC 6274 on Security Assessment of the Internet Protocol Version 4 Date: Tue, 5 Jul 2011 09:45:51 -0700 (PDT) From: rfc-editor at rfc-editor.org To: ietf-announce at ietf.org, rfc-dist at rfc-editor.org CC: opsec at ietf.org, rfc-editor at rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 6274 Title: Security Assessment of the Internet Protocol Version 4 Author: F. Gont Status: Informational Stream: IETF Date: July 2011 Mailbox: fernando at gont.com.ar Pages: 75 Characters: 179909 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-opsec-ip-security-07.txt URL: http://www.rfc-editor.org/rfc/rfc6274.txt This document contains a security assessment of the IETF specifications of the Internet Protocol version 4 and of a number of mechanisms and policies in use by popular IPv4 implementations. It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI). This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor at rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ IETF-Announce mailing list IETF-Announce at ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From joly at punkcast.com Tue Jul 5 23:17:01 2011 From: joly at punkcast.com (Joly MacFie) Date: Wed, 6 Jul 2011 00:17:01 -0400 Subject: FCC calls for nominations to Open Internet Advisory Committee In-Reply-To: References: Message-ID: The FCC is seeking nomination s for membership on its Open Internet Advisory Committee (OIAC), established pursuant to the Order on Preserving the Open Internet . More: http://isoc-ny.org/p2/?p=2300 Don't be shy now! :) -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From marka at isc.org Wed Jul 6 21:39:31 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 07 Jul 2011 12:39:31 +1000 Subject: How long is reasonable to fix a routing issue in IPv6? Message-ID: <20110707023931.B91E111920D3@drugs.dv.isc.org> The below has been on going for over a week (yes it has been reported to HE) and the IETF). Not returning time exceeded really make debugging routing problems hard. Mark traceroute6 -lI www.ietf.org traceroute6 to www.ietf.org (2001:1890:1112:1::1e) from 2001:470:1f00:ffff::5a1, 64 hops max, 16 byte packets 1 dviscorg.tunnel.tserv1.fmt.ipv6.he.net (2001:470:1f00:ffff::5a0) 172.669 ms 182.219 ms 170.424 ms 2 2001:470:0:1f::1 (2001:470:0:1f::1) 178.128 ms 171.926 ms 174.877 ms 3 gige-g4-8.core1.fmt2.he.net (2001:470:0:2d::2) 172.193 ms 171.265 ms 171.221 ms 4 10gigabitethernet6-4.core1.lax1.he.net (2001:470:0:18d::2) 198.338 ms 190.680 ms 182.413 ms 5 10gigabitethernet1-3.core1.lax2.he.net (2001:470:0:72::2) 178.924 ms 189.431 ms 180.538 ms 6 2001:470:0:1e6::2 (2001:470:0:1e6::2) 181.137 ms 179.374 ms 182.321 ms 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 2001:1890:1fff:ffff::1 (2001:1890:1fff:ffff::1) 262.713 ms * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jared at puck.nether.net Wed Jul 6 22:48:41 2011 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 6 Jul 2011 23:48:41 -0400 Subject: How long is reasonable to fix a routing issue in IPv6? In-Reply-To: <20110707023931.B91E111920D3@drugs.dv.isc.org> References: <20110707023931.B91E111920D3@drugs.dv.isc.org> Message-ID: <9634AA8C-C8FD-4AFE-A888-82C9C326636D@puck.nether.net> If those interim hops are IPv4 only nodes part of 6/PE there could be a few things going on here. 1) Juniper u-RPF for family inet6 drops the mapped-v4-v6 source packets generated by a P/PE router 2) FreeBSD (8.2 at least) doesn't seem to like mapped-v4-v6 source packets with its default traceroute (same for mtr on FreeBSD) (tcpdump will show you the packets coming back, the freebsd traceroute6 seems to have a few unresolved bugs.. you need to force -w 1 as well likely) 3) If end-to-end connectivity works, Workarounds: the IPv4 only P/PE device should have some sort of IPv6 address placed on transit interfaces to allow TTL expired to be sourced from something capable (this IP doesn't need to be able to be reached/routed to that interface, just exist). I spent a lot of time looking at a similar problem and it ended up being a combination of #1 & #2 above. You will see this problem across The AT&T and Cogent networks in my experience. - Jared On Jul 6, 2011, at 10:39 PM, Mark Andrews wrote: > > The below has been on going for over a week (yes it has been reported to HE) > and the IETF). > > Not returning time exceeded really make debugging routing problems hard. > > Mark > > traceroute6 -lI www.ietf.org > traceroute6 to www.ietf.org (2001:1890:1112:1::1e) from 2001:470:1f00:ffff::5a1, 64 hops max, 16 byte packets > 1 dviscorg.tunnel.tserv1.fmt.ipv6.he.net (2001:470:1f00:ffff::5a0) 172.669 ms 182.219 ms 170.424 ms > 2 2001:470:0:1f::1 (2001:470:0:1f::1) 178.128 ms 171.926 ms 174.877 ms > 3 gige-g4-8.core1.fmt2.he.net (2001:470:0:2d::2) 172.193 ms 171.265 ms 171.221 ms > 4 10gigabitethernet6-4.core1.lax1.he.net (2001:470:0:18d::2) 198.338 ms 190.680 ms 182.413 ms > 5 10gigabitethernet1-3.core1.lax2.he.net (2001:470:0:72::2) 178.924 ms 189.431 ms 180.538 ms > 6 2001:470:0:1e6::2 (2001:470:0:1e6::2) 181.137 ms 179.374 ms 182.321 ms > 7 * * * > 8 * * * > 9 * * * > 10 * * * > 11 * * * > 12 2001:1890:1fff:ffff::1 (2001:1890:1fff:ffff::1) 262.713 ms * * > 13 * * * > 14 * * * > 15 * * * > 16 * * * > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 * * * > 28 * * * > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Thu Jul 7 01:14:26 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 07 Jul 2011 16:14:26 +1000 Subject: How long is reasonable to fix a routing issue in IPv6? In-Reply-To: Your message of "Wed, 06 Jul 2011 23:48:41 -0400." <9634AA8C-C8FD-4AFE-A888-82C9C326636D@puck.nether.net> References: <20110707023931.B91E111920D3@drugs.dv.isc.org> <9634AA8C-C8FD-4AFE-A888-82C9C326636D@puck.nether.net> Message-ID: <20110707061426.4A96F1195F60@drugs.dv.isc.org> In message <9634AA8C-C8FD-4AFE-A888-82C9C326636D at puck.nether.net>, Jared Mauch w rites: > If those interim hops are IPv4 only nodes part of 6/PE there could be a = > few things going on here. > > 1) Juniper u-RPF for family inet6 drops the mapped-v4-v6 source packets = > generated by a P/PE router > 2) FreeBSD (8.2 at least) doesn't seem to like mapped-v4-v6 source = > packets with its default traceroute (same for mtr on FreeBSD) > (tcpdump will show you the packets coming back, the freebsd traceroute6 = > seems to have a few unresolved bugs.. you need to force -w 1 as well = > likely) I see nothing in tcpdump other than the outgoing traffic and the replies already noted. > 3) If end-to-end connectivity works,=20 > > Workarounds: > > the IPv4 only P/PE device should have some sort of IPv6 address placed = > on transit interfaces to allow TTL expired to be sourced from something = > capable (this IP doesn't need to be able to be reached/routed to that = > interface, just exist). > > I spent a lot of time looking at a similar problem and it ended up being = > a combination of #1 & #2 above. You will see this problem across The = > AT&T and Cogent networks in my experience. The path is going through AT&T. > - Jared > > On Jul 6, 2011, at 10:39 PM, Mark Andrews wrote: > > >=20 > > The below has been on going for over a week (yes it has been reported = > to HE) > > and the IETF). > >=20 > > Not returning time exceeded really make debugging routing problems = > hard. > >=20 > > Mark > >=20 > > traceroute6 -lI www.ietf.org > > traceroute6 to www.ietf.org (2001:1890:1112:1::1e) from = > 2001:470:1f00:ffff::5a1, 64 hops max, 16 byte packets > > 1 dviscorg.tunnel.tserv1.fmt.ipv6.he.net (2001:470:1f00:ffff::5a0) = > 172.669 ms 182.219 ms 170.424 ms > > 2 2001:470:0:1f::1 (2001:470:0:1f::1) 178.128 ms 171.926 ms = > 174.877 ms > > 3 gige-g4-8.core1.fmt2.he.net (2001:470:0:2d::2) 172.193 ms 171.265 = > ms 171.221 ms > > 4 10gigabitethernet6-4.core1.lax1.he.net (2001:470:0:18d::2) 198.338 = > ms 190.680 ms 182.413 ms > > 5 10gigabitethernet1-3.core1.lax2.he.net (2001:470:0:72::2) 178.924 = > ms 189.431 ms 180.538 ms > > 6 2001:470:0:1e6::2 (2001:470:0:1e6::2) 181.137 ms 179.374 ms = > 182.321 ms > > 7 * * * > > 8 * * * > > 9 * * * > > 10 * * * > > 11 * * * > > 12 2001:1890:1fff:ffff::1 (2001:1890:1fff:ffff::1) 262.713 ms * * > > 13 * * * > > 14 * * * > > 15 * * * > > 16 * * * > > 17 * * * > > 18 * * * > > 19 * * * > > 20 * * * > > 21 * * * > > 22 * * * > > 23 * * * > > 24 * * * > > 25 * * * > > 26 * * * > > 27 * * * > > 28 * * * > >=20 > > --=20 > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jared at puck.nether.net Thu Jul 7 08:20:07 2011 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 7 Jul 2011 09:20:07 -0400 Subject: How long is reasonable to fix a routing issue in IPv6? In-Reply-To: <20110707061426.4A96F1195F60@drugs.dv.isc.org> References: <20110707023931.B91E111920D3@drugs.dv.isc.org> <9634AA8C-C8FD-4AFE-A888-82C9C326636D@puck.nether.net> <20110707061426.4A96F1195F60@drugs.dv.isc.org> Message-ID: On Jul 7, 2011, at 2:14 AM, Mark Andrews wrote: >> 3) If end-to-end connectivity works,=20 >> >> Workarounds: >> >> the IPv4 only P/PE device should have some sort of IPv6 address placed = >> on transit interfaces to allow TTL expired to be sourced from something = >> capable (this IP doesn't need to be able to be reached/routed to that = >> interface, just exist). >> >> I spent a lot of time looking at a similar problem and it ended up being = >> a combination of #1 & #2 above. You will see this problem across The = >> AT&T and Cogent networks in my experience. > > The path is going through AT&T. Yes. AT&T and Cogent are aware of this. I think there may be an IETF draft out there that talks about this as well but don't have a pointer to it. It is true that if an MPLS-LSR/P device does not understand the IPv6 frame you will see no response for that TTL. It's only the P devices that do understand an IPv6 frame, but decide to put a mapped-v4 address in the ttl expired message. The real questions are: 1) Is hurricane electric doing loose-rpf for ipv6/inet6 and dropping these packets? (and if they are, are you requesting they make this change?) 2) is a mapped-v4 address a valid *source* address on the wire even if it's not a valid dest? 3) should operators of IPv6 capable equipment be running them in an MPLS-LSR/P role be assigning an IPv6 address on interfaces to provide a valid source-address even if they are not reachable in return? Should the vendor provide a knob to generate the ttl expiry messages from some other source address, obscuring the interface IPs involved (such as a loopback)? Mark, it may also be valuable to see testing from a server at ISC that doesn't transit HE to reach the ATT network. While you still can't see who is dropping your packets, you may find someone who doesn't have loose-rpf enabled and observe some of the other behaviors noted. - Jared (BTW, 2914 does do loose-rpf on inet6 to drop unrouted space on Juniper devices) From mleber at he.net Thu Jul 7 11:33:27 2011 From: mleber at he.net (Mike Leber) Date: Thu, 07 Jul 2011 09:33:27 -0700 Subject: How long is reasonable to fix a routing issue in IPv6? In-Reply-To: References: <20110707023931.B91E111920D3@drugs.dv.isc.org> <9634AA8C-C8FD-4AFE-A888-82C9C326636D@puck.nether.net> <20110707061426.4A96F1195F60@drugs.dv.isc.org> Message-ID: <4E15DFD7.3090802@he.net> On 7/7/11 6:20 AM, Jared Mauch wrote: > On Jul 7, 2011, at 2:14 AM, Mark Andrews wrote: > >>> 3) If end-to-end connectivity works,=20 >>> >>> Workarounds: >>> >>> the IPv4 only P/PE device should have some sort of IPv6 address placed = >>> on transit interfaces to allow TTL expired to be sourced from something = >>> capable (this IP doesn't need to be able to be reached/routed to that = >>> interface, just exist). >>> >>> I spent a lot of time looking at a similar problem and it ended up being = >>> a combination of #1& #2 above. You will see this problem across The = >>> AT&T and Cogent networks in my experience. >> The path is going through AT&T. > Yes. AT&T and Cogent are aware of this. I think there may be an IETF draft out there that talks about this as well but don't have a pointer to it. It is true that if an MPLS-LSR/P device does not understand the IPv6 frame you will see no response for that TTL. It's only the P devices that do understand an IPv6 frame, but decide to put a mapped-v4 address in the ttl expired message. > > The real questions are: > > 1) Is hurricane electric doing loose-rpf for ipv6/inet6 and dropping these packets? (and if they are, are you requesting they make this change?) We aren't doing loose-rpf on ISC's transit session (for the reason you stated and others). > 2) is a mapped-v4 address a valid *source* address on the wire even if it's not a valid dest? > 3) should operators of IPv6 capable equipment be running them in an MPLS-LSR/P role be assigning an IPv6 address on interfaces to provide a valid source-address even if they are not reachable in return? Should the vendor provide a knob to generate the ttl expiry messages from some other source address, obscuring the interface IPs involved (such as a loopback)? > > Mark, it may also be valuable to see testing from a server at ISC that doesn't transit HE to reach the ATT network. While you still can't see who is dropping your packets, you may find someone who doesn't have loose-rpf enabled and observe some of the other behaviors noted. The problem observed also happens for native IPv6 packets sent to 2001:1890:1112:1::1e We can confirm the packets leave our network and are handed off to the correct party. We've sent emails regarding this to the other parties involved with no response so far. I'll make sure people start getting phone calls. Mike. > - Jared > > (BTW, 2914 does do loose-rpf on inet6 to drop unrouted space on Juniper devices) From marka at isc.org Thu Jul 7 18:03:28 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 08 Jul 2011 09:03:28 +1000 Subject: How long is reasonable to fix a routing issue in IPv6? In-Reply-To: Your message of "Thu, 07 Jul 2011 09:33:27 MST." <4E15DFD7.3090802@he.net> References: <20110707023931.B91E111920D3@drugs.dv.isc.org> <9634AA8C-C8FD-4AFE-A888-82C9C326636D@puck.nether.net> <20110707061426.4A96F1195F60@drugs.dv.isc.org> <4E15DFD7.3090802@he.net> Message-ID: <20110707230328.EDB4F1199F15@drugs.dv.isc.org> In message <4E15DFD7.3090802 at he.net>, Mike Leber writes: > > > On 7/7/11 6:20 AM, Jared Mauch wrote: > > On Jul 7, 2011, at 2:14 AM, Mark Andrews wrote: > > > >>> 3) If end-to-end connectivity works,=20 > >>> > >>> Workarounds: > >>> > >>> the IPv4 only P/PE device should have some sort of IPv6 address placed = > >>> on transit interfaces to allow TTL expired to be sourced from something = > >>> capable (this IP doesn't need to be able to be reached/routed to that = > >>> interface, just exist). > >>> > >>> I spent a lot of time looking at a similar problem and it ended up being = > >>> a combination of #1& #2 above. You will see this problem across The = > >>> AT&T and Cogent networks in my experience. > >> The path is going through AT&T. > > Yes. AT&T and Cogent are aware of this. I think there may be an IETF draft > out there that talks about this as well but don't have a pointer to it. It i > s true that if an MPLS-LSR/P device does not understand the IPv6 frame you wil > l see no response for that TTL. It's only the P devices that do understand an > IPv6 frame, but decide to put a mapped-v4 address in the ttl expired message. > > > > The real questions are: > > > > 1) Is hurricane electric doing loose-rpf for ipv6/inet6 and dropping these p > ackets? (and if they are, are you requesting they make this change?) > > We aren't doing loose-rpf on ISC's transit session (for the reason you > stated and others). > > > 2) is a mapped-v4 address a valid *source* address on the wire even if it's > not a valid dest? > > 3) should operators of IPv6 capable equipment be running them in an MPLS-LSR > /P role be assigning an IPv6 address on interfaces to provide a valid source-a > ddress even if they are not reachable in return? Should the vendor provide a > knob to generate the ttl expiry messages from some other source address, obscu > ring the interface IPs involved (such as a loopback)? > > > > Mark, it may also be valuable to see testing from a server at ISC that doesn > 't transit HE to reach the ATT network. While you still can't see who is drop > ping your packets, you may find someone who doesn't have loose-rpf enabled and > observe some of the other behaviors noted. > > The problem observed also happens for native IPv6 packets sent to > 2001:1890:1112:1::1e > > We can confirm the packets leave our network and are handed off to the > correct party. > > We've sent emails regarding this to the other parties involved with no > response so far. I'll make sure people start getting phone calls. > > Mike. Thanks. I wasn't trying to complain about HE's support, which has always been good. I was trying to point out the not having working time exceeded messages makes everybody's job harder. That it is time to take IPv6 seriously and part of doing that means making sure that error reporting works. Mark > > - Jared > > > > (BTW, 2914 does do loose-rpf on inet6 to drop unrouted space on Juniper devi > ces) > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mksmith at adhost.com Fri Jul 8 11:04:04 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Fri, 8 Jul 2011 16:04:04 +0000 Subject: IMPORTANT ADMINISTRIVIA - NANOG list and website changes over the next week Message-ID: Hello Everyone We are going to be moving the NANOG mailing list over to our new service provider beginning this week. There are several changes that will occur over time that will, hopefully, reduce the service impact to users. One key note - the new system doesn't use Mailman, so your filtering rules may need to be changed to accommodate the new system. - July 8th - We will begin the transition of the NANOG website to its new location with our service provider. - There may be service glitches through the weekend on the site, but nothing catastrophic - July 9th - Mailman will be modified to use our service provider's MX for outbound messages. - Hopefully this will be transparent to list participants, but users can add mail.amsl.com to their filters. - July 9th - Subscription changes to the list will be frozen and the list archives will be unavailable. - Administrivia requests will receive a bounce message during this phase. - July 11th - MX records will be updated so all inbound/outbound mail goes through their system. - At this stage, mail.amsl.com will be the only MX for NANOG list services. - July 11th - DNS records will be updated for the website as well. - At this point, all services will have been moved to our provider. If you have any questions or concerns you can send them to me directly. I'd be happy to provide more specifics if people are interested, but I thought a brief and to-the-point message to the list was more appropriate. Regards, Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) From sethm at rollernet.us Fri Jul 8 12:23:34 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 08 Jul 2011 10:23:34 -0700 Subject: IMPORTANT ADMINISTRIVIA - NANOG list and website changes over the next week In-Reply-To: References: Message-ID: <4E173D16.5030708@rollernet.us> On 7/8/11 9:04 AM, Michael K. Smith - Adhost wrote: > Hello Everyone > > We are going to be moving the NANOG mailing list over to our new service provider beginning this week. There are several changes that will occur over time that will, hopefully, reduce the service impact to users. One key note - the new system doesn't use Mailman, so your filtering rules may need to be changed to accommodate the new system. > > - July 8th - We will begin the transition of the NANOG website to its new location with our service provider. > - There may be service glitches through the weekend on the site, but nothing catastrophic > - July 9th - Mailman will be modified to use our service provider's MX for outbound messages. > - Hopefully this will be transparent to list participants, but users can add mail.amsl.com to their filters. > - July 9th - Subscription changes to the list will be frozen and the list archives will be unavailable. > - Administrivia requests will receive a bounce message during this phase. > - July 11th - MX records will be updated so all inbound/outbound mail goes through their system. > - At this stage, mail.amsl.com will be the only MX for NANOG list services. No more IPv6? I don't see an AAAA record for it... ~Seth From straterra at fuhell.com Fri Jul 8 12:39:42 2011 From: straterra at fuhell.com (Thomas York) Date: Fri, 08 Jul 2011 13:39:42 -0400 Subject: IMPORTANT ADMINISTRIVIA - NANOG list and website changes over the next week In-Reply-To: <4E173D16.5030708@rollernet.us> References: <4E173D16.5030708@rollernet.us> Message-ID: <4E1740DE.4020102@fuhell.com> On 07/08/2011 01:23 PM, Seth Mattinen wrote: > On 7/8/11 9:04 AM, Michael K. Smith - Adhost wrote: >> Hello Everyone >> >> We are going to be moving the NANOG mailing list over to our new service provider beginning this week. There are several changes that will occur over time that will, hopefully, reduce the service impact to users. One key note - the new system doesn't use Mailman, so your filtering rules may need to be changed to accommodate the new system. >> >> - July 8th - We will begin the transition of the NANOG website to its new location with our service provider. >> - There may be service glitches through the weekend on the site, but nothing catastrophic >> - July 9th - Mailman will be modified to use our service provider's MX for outbound messages. >> - Hopefully this will be transparent to list participants, but users can add mail.amsl.com to their filters. >> - July 9th - Subscription changes to the list will be frozen and the list archives will be unavailable. >> - Administrivia requests will receive a bounce message during this phase. >> - July 11th - MX records will be updated so all inbound/outbound mail goes through their system. >> - At this stage, mail.amsl.com will be the only MX for NANOG list services. > > No more IPv6? I don't see an AAAA record for it... > > ~Seth > There goes 90% of my IPv6 traffic! --Thomas York -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6022 bytes Desc: S/MIME Cryptographic Signature URL: From cscora at apnic.net Fri Jul 8 14:07:55 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 9 Jul 2011 05:07:55 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201107081907.p68J7tQj023271@thyme.rand.apnic.net> 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, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 09 Jul, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 362786 Prefixes after maximum aggregation: 164929 Deaggregation factor: 2.20 Unique aggregates announced to Internet: 180083 Total ASes present in the Internet Routing Table: 38135 Prefixes per ASN: 9.51 Origin-only ASes present in the Internet Routing Table: 31710 Origin ASes announcing only one prefix: 15248 Transit ASes present in the Internet Routing Table: 5186 Transit-only ASes present in the Internet Routing Table: 130 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 33 Max AS path prepend of ASN (22394) 27 Prefixes from unregistered ASNs in the Routing Table: 925 Unregistered ASNs in the Routing Table: 512 Number of 32-bit ASNs allocated by the RIRs: 1533 Number of 32-bit ASNs visible in the Routing Table: 1239 Prefixes from 32-bit ASNs in the Routing Table: 2861 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 119 Number of addresses announced to Internet: 2493493440 Equivalent to 148 /8s, 159 /16s and 176 /24s Percentage of available address space announced: 67.3 Percentage of allocated address space announced: 67.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 91.0 Total number of prefixes smaller than registry allocations: 151395 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 90104 Total APNIC prefixes after maximum aggregation: 30260 APNIC Deaggregation factor: 2.98 Prefixes being announced from the APNIC address blocks: 86847 Unique aggregates announced from the APNIC address blocks: 37076 APNIC Region origin ASes present in the Internet Routing Table: 4503 APNIC Prefixes per ASN: 19.29 APNIC Region origin ASes announcing only one prefix: 1248 APNIC Region transit ASes present in the Internet Routing Table: 713 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 18 Number of APNIC region 32-bit ASNs visible in the Routing Table: 56 Number of APNIC addresses announced to Internet: 621479200 Equivalent to 37 /8s, 11 /16s and 5 /24s Percentage of available APNIC address space announced: 78.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 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, 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: 141428 Total ARIN prefixes after maximum aggregation: 72827 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 113365 Unique aggregates announced from the ARIN address blocks: 46672 ARIN Region origin ASes present in the Internet Routing Table: 14469 ARIN Prefixes per ASN: 7.84 ARIN Region origin ASes announcing only one prefix: 5532 ARIN Region transit ASes present in the Internet Routing Table: 1522 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 30 Number of ARIN region 32-bit ASNs visible in the Routing Table: 13 Number of ARIN addresses announced to Internet: 819612544 Equivalent to 48 /8s, 218 /16s and 75 /24s Percentage of available ARIN address space announced: 65.1 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, 393216-394239 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, 173/8, 174/8, 184/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: 86545 Total RIPE prefixes after maximum aggregation: 49132 RIPE Deaggregation factor: 1.76 Prefixes being announced from the RIPE address blocks: 79935 Unique aggregates announced from the RIPE address blocks: 52845 RIPE Region origin ASes present in the Internet Routing Table: 15797 RIPE Prefixes per ASN: 5.06 RIPE Region origin ASes announcing only one prefix: 7877 RIPE Region transit ASes present in the Internet Routing Table: 2504 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 912 Number of RIPE addresses announced to Internet: 478890496 Equivalent to 28 /8s, 139 /16s and 74 /24s Percentage of available RIPE address space announced: 77.1 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 196608-198655 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, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 33421 Total LACNIC prefixes after maximum aggregation: 7576 LACNIC Deaggregation factor: 4.41 Prefixes being announced from the LACNIC address blocks: 32551 Unique aggregates announced from the LACNIC address blocks: 16960 LACNIC Region origin ASes present in the Internet Routing Table: 1476 LACNIC Prefixes per ASN: 22.05 LACNIC Region origin ASes announcing only one prefix: 444 LACNIC Region transit ASes present in the Internet Routing Table: 273 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 19 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 254 Number of LACNIC addresses announced to Internet: 85900288 Equivalent to 5 /8s, 30 /16s and 188 /24s Percentage of available LACNIC address space announced: 56.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 8211 Total AfriNIC prefixes after maximum aggregation: 1965 AfriNIC Deaggregation factor: 4.18 Prefixes being announced from the AfriNIC address blocks: 6500 Unique aggregates announced from the AfriNIC address blocks: 2004 AfriNIC Region origin ASes present in the Internet Routing Table: 470 AfriNIC Prefixes per ASN: 13.83 AfriNIC Region origin ASes announcing only one prefix: 147 AfriNIC Region transit ASes present in the Internet Routing Table: 102 Average AfriNIC Region AS path length visible: 4.9 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 4 Number of AfriNIC addresses announced to Internet: 24334336 Equivalent to 1 /8s, 115 /16s and 80 /24s Percentage of available AfriNIC address space announced: 36.3 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2436 11043 934 Korea Telecom (KIX) 17974 1787 461 41 PT TELEKOMUNIKASI INDONESIA 7545 1548 301 85 TPG Internet Pty Ltd 4755 1498 635 171 TATA Communications formerly 24560 1154 336 187 Bharti Airtel Ltd., Telemedia 9829 1101 922 46 BSNL National Internet Backbo 9583 1060 78 506 Sify Limited 4808 1047 2092 299 CNCGROUP IP network: China169 17488 964 186 105 Hathway IP Over Cable Interne 18101 931 116 140 Reliance Infocom Ltd Internet 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 6389 3610 3819 244 bellsouth.net, inc. 18566 1913 365 241 Covad Communications 1785 1806 681 122 PaeTec Communications, Inc. 4323 1656 1082 400 Time Warner Telecom 20115 1595 1533 634 Charter Communications 19262 1429 4778 392 Verizon Global Networks 7018 1366 7069 892 AT&T WorldNet Services 22773 1350 2897 88 Cox Communications, Inc. 6478 1346 251 618 AT&T Worldnet Services 7029 1287 791 301 Windstream Communications Inc 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 34984 536 106 184 BILISIM TELEKOM 6830 512 1780 317 UPC Distribution Services 3292 466 2076 401 TDC Tele Danmark 20940 459 132 354 Akamai Technologies European 12479 453 593 7 Uni2 Autonomous System 8866 447 133 25 Bulgarian Telecommunication C 29049 441 33 45 AzerSat LLC. 3320 421 8151 368 Deutsche Telekom AG 8551 404 354 44 Bezeq International 3301 397 1855 346 TeliaNet Sweden 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 1543 282 158 TVCABLE BOGOTA 8151 1432 2746 353 UniNet S.A. de C.V. 28573 1268 995 78 NET Servicos de Comunicao S.A 7303 1004 512 177 Telecom Argentina Stet-France 6503 747 354 74 AVANTEL, S.A. 14420 688 55 83 CORPORACION NACIONAL DE TELEC 22047 576 322 17 VTR PUNTO NET S.A. 3816 532 230 96 Empresa Nacional de Telecomun 7738 516 986 31 Telecomunicacoes da Bahia S.A 27947 508 53 53 Telconet S.A 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 8452 797 445 11 TEDATA 24863 790 147 37 LINKdotNET AS number 15475 514 74 8 Nile Online 36992 315 415 14 Etisalat MISR 3741 260 937 222 The Internet Solution 6713 241 215 13 Itissalat Al-MAGHRIB 33776 227 13 5 Starcomms Nigeria Limited 24835 211 78 10 RAYA Telecom - Egypt 29571 158 17 11 Ci Telecom Autonomous system 16637 149 441 86 MTN Network Solutions 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 6389 3610 3819 244 bellsouth.net, inc. 23456 2861 699 1535 32-bit ASN transition 4766 2436 11043 934 Korea Telecom (KIX) 18566 1913 365 241 Covad Communications 1785 1806 681 122 PaeTec Communications, Inc. 17974 1787 461 41 PT TELEKOMUNIKASI INDONESIA 4323 1656 1082 400 Time Warner Telecom 20115 1595 1533 634 Charter Communications 7545 1548 301 85 TPG Internet Pty Ltd 10620 1543 282 158 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 17974 1787 1746 PT TELEKOMUNIKASI INDONESIA 1785 1806 1684 PaeTec Communications, Inc. 18566 1913 1672 Covad Communications 4766 2436 1502 Korea Telecom (KIX) 7545 1548 1463 TPG Internet Pty Ltd 10620 1543 1385 TVCABLE BOGOTA 4755 1498 1327 TATA Communications formerly 23456 2861 1326 32-bit ASN transition 22773 1350 1262 Cox Communications, Inc. 4323 1656 1256 Time Warner Telecom Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.225.128.0/18 36377 Comcast Telecommunications, I 24.225.192.0/23 36377 Comcast Telecommunications, I 24.225.192.0/18 36377 Comcast Telecommunications, I 24.225.224.0/21 36377 Comcast Telecommunications, I 24.225.237.0/24 36377 Comcast Telecommunications, I 24.225.248.0/21 36377 Comcast Telecommunications, I 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 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:22 /9:12 /10:28 /11:81 /12:232 /13:468 /14:804 /15:1401 /16:11993 /17:5887 /18:9815 /19:19456 /20:25837 /21:26191 /22:34744 /23:33600 /24:188907 /25:1083 /26:1262 /27:735 /28:211 /29:9 /30:2 /31:0 /32:6 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2222 3610 bellsouth.net, inc. 18566 1869 1913 Covad Communications 10620 1438 1543 TVCABLE BOGOTA 23456 1406 2861 32-bit ASN transition 6478 1316 1346 AT&T Worldnet Services 11492 1096 1142 Cable One 7011 1054 1156 Citizens Utilities 1785 1053 1806 PaeTec Communications, Inc. 7029 1034 1287 Windstream Communications Inc 22773 864 1350 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:324 2:45 4:16 5:1 6:3 8:337 12:1976 13:1 14:481 15:15 16:3 17:5 20:10 23:13 24:1678 27:814 31:490 32:64 33:4 34:2 36:4 38:744 40:103 41:2564 42:32 44:3 46:1036 47:3 49:198 50:442 52:13 54:2 55:4 56:2 57:35 58:860 59:479 60:386 61:1180 62:1036 63:1935 64:3942 65:2294 66:3869 67:1897 68:1091 69:3040 70:758 71:389 72:1886 74:2389 75:316 76:341 77:888 78:712 79:461 80:1116 81:839 82:498 83:456 84:692 85:1073 86:554 87:759 88:335 89:1531 90:223 91:3946 92:533 93:1052 94:1334 95:855 96:446 97:256 98:891 99:37 101:77 103:115 106:10 107:21 108:70 109:1028 110:614 111:706 112:304 113:400 114:534 115:674 116:962 117:667 118:857 119:1161 120:312 121:675 122:1581 123:973 124:1304 125:1231 128:246 129:172 130:168 131:578 132:112 133:21 134:214 135:48 136:216 137:136 138:299 139:116 140:477 141:240 142:403 143:416 144:483 145:54 146:449 147:215 148:661 149:248 150:164 151:189 152:331 153:182 154:4 155:398 156:198 157:354 158:138 159:450 160:311 161:201 162:309 163:165 164:503 165:358 166:530 167:431 168:740 169:155 170:847 171:78 172:1 173:1642 174:610 175:379 176:141 177:163 178:988 180:880 181:23 182:488 183:204 184:342 185:1 186:1273 187:682 188:878 189:934 190:4949 192:5883 193:4968 194:3520 195:3032 196:1237 197:41 198:3573 199:3955 200:5534 201:1490 202:8396 203:8425 204:4215 205:2306 206:2677 207:2810 208:3965 209:3444 210:2681 211:1465 212:2097 213:1742 214:782 215:70 216:4937 217:1639 218:537 219:359 220:1189 221:492 222:357 223:185 End of report From mruiz at lstfinancial.com Fri Jul 8 14:46:53 2011 From: mruiz at lstfinancial.com (Michael Ruiz) Date: Fri, 8 Jul 2011 19:46:53 +0000 Subject: Message-ID: <690D7D20D2507C44BA8066926B200989183496@ES1002.ic-sa.com> Hello All, I have been working for two days trying to get an ASA to setup a VPN tunnel to a SSG-550. I have the VPN tunnel Setup and ready to go on the ASA. I ran a Debug crypto IPSec 200 and crypto ikve1 200. I do the command ping PRIVATE and I get in the console Sending 5, 100-byte ICMP Echos to 10.1.4.81, timeout is 2 seconds: IPSEC(crypto_map_check)-3: Looking for crypto map matching 5-tuple: Prot=1, saddr=10.20.1.2, sport=29733, daddr=10.1.4.81, dport=29733 IPSEC(crypto_map_check)-5: Checking crypto map CARIBOU-VPN-1 10: skipping incomplete map. No peer, access-list or transform-set specified. IPSEC(crypto_map_check)-1: Error: No crypto map matched. >From my understanding this is caused by the crypto map not being able to establish a tunnel to the Juniper. On my Juniper configuration I have built the Gateway and set the Phase 1 Proposal to "pre-g2-3des-md5" followed by "pre-g2-3des-sha" For the VPN configuration I use the predefined gateway configuration. Under the advanced button, I use the predefined of "compatible" and the Phase 2 Proposal "nopfs-esp-3des" followed by "nopfs-esp-3des" The proxy id is the local IP / Network block and the remote IP network block is the destination IP block. The only part that has me wondering, because the Juniper has multiple zones, i.e. a DMZ, Trust, and Untrust. Each Zone has its own IP block that is assigned to it. I have entered a policy into one of the zones, i.e. Untrust to Trust, input source block, destination block, specified it is a tunnel, set for bi-directional entry and that should be it. Any help in this as always will be greatly appreciated. Thank you. Thank You, MAR CONFIDENTIALITY NOTICE: This message is intended only for the individual or entity to which it is addressed and may contain information that is confidential or exempt from disclosure under applicable law. If you are not the intended recipient, you have received this communication in error. In such case, please notify us immediately by reply e-mail and immediately delete this message and its attachments. Any use, dissemination, redistribution or reproduction of this communication is strictly prohibited. Unless the message explicitly states otherwise, no e-mail correspondence claims to be a contractual offer or acceptance. LST Financial has instructed its employees not to send libelous or inappropriate statements and disclaims responsibility for such. Subject to applicable law, LST Financial may monitor, review and retain e-communications traveling through its networks/systems. By messaging with LST Financial you consent to the foregoing. From fw at deneb.enyo.de Fri Jul 8 15:21:13 2011 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 08 Jul 2011 22:21:13 +0200 Subject: How long is reasonable to fix a routing issue in IPv6? In-Reply-To: (Jared Mauch's message of "Thu, 7 Jul 2011 09:20:07 -0400") References: <20110707023931.B91E111920D3@drugs.dv.isc.org> <9634AA8C-C8FD-4AFE-A888-82C9C326636D@puck.nether.net> <20110707061426.4A96F1195F60@drugs.dv.isc.org> Message-ID: <87fwmged6u.fsf@mid.deneb.enyo.de> * Jared Mauch: > 2) is a mapped-v4 address a valid *source* address on the wire even if it's not a valid dest? By the way, has the analogous issue involving v4 addresses from RFC 1918 space ever been settled? From bmanning at vacation.karoshi.com Fri Jul 8 16:24:33 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 8 Jul 2011 21:24:33 +0000 Subject: How long is reasonable to fix a routing issue in IPv6? In-Reply-To: <87fwmged6u.fsf@mid.deneb.enyo.de> References: <20110707023931.B91E111920D3@drugs.dv.isc.org> <9634AA8C-C8FD-4AFE-A888-82C9C326636D@puck.nether.net> <20110707061426.4A96F1195F60@drugs.dv.isc.org> <87fwmged6u.fsf@mid.deneb.enyo.de> Message-ID: <20110708212433.GA12275@vacation.karoshi.com.> On Fri, Jul 08, 2011 at 10:21:13PM +0200, Florian Weimer wrote: > * Jared Mauch: > > > 2) is a mapped-v4 address a valid *source* address on the wire even if it's not a valid dest? > > By the way, has the analogous issue involving v4 addresses from > RFC 1918 space ever been settled? define "valid"? mapped-v4 and 1918 addresses are valid in that both meet the address format constraints. technically they work as both source and destination - the restriction is administrative. /bill From bzeeb-lists at lists.zabbadoz.net Fri Jul 8 16:29:34 2011 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Fri, 8 Jul 2011 21:29:34 +0000 Subject: How long is reasonable to fix a routing issue in IPv6? In-Reply-To: References: <20110707023931.B91E111920D3@drugs.dv.isc.org> <9634AA8C-C8FD-4AFE-A888-82C9C326636D@puck.nether.net> <20110707061426.4A96F1195F60@drugs.dv.isc.org> Message-ID: <409F5525-903C-4581-AD35-84E9A6048336@lists.zabbadoz.net> On Jul 7, 2011, at 1:20 PM, Jared Mauch wrote: > 2) is a mapped-v4 address a valid *source* address on the wire even if it's not a valid dest? The world is split on that and why wouldn't it in theory be a valid dest? It would be easier if this had made it past draft state: http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From cidr-report at potaroo.net Fri Jul 8 17:00:01 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 8 Jul 2011 22:00:01 GMT Subject: BGP Update Report Message-ID: <201107082200.p68M01e4079011@wattle.apnic.net> BGP Update Report Interval: 30-Jun-11 -to- 07-Jul-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS17974 38582 2.8% 21.6 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 2 - AS9829 37847 2.8% 43.0 -- BSNL-NIB National Internet Backbone 3 - AS27817 24660 1.8% 249.1 -- Red Nacional Acad?mica de Tecnolog?a Avanzada - RENATA 4 - AS22646 23220 1.7% 241.9 -- HARCOM1 - Hargray Communications Group, Inc. 5 - AS32528 16548 1.2% 3309.6 -- ABBOTT Abbot Labs 6 - AS29049 16018 1.2% 36.1 -- DELTA-TELECOM-AS Delta Telecom LTD. 7 - AS5976 11107 0.8% 70.7 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 8 - AS9198 10623 0.8% 28.7 -- KAZTELECOM-AS JSC Kazakhtelecom 9 - AS14080 10264 0.8% 190.1 -- Telmex Colombia S.A. 10 - AS8151 10058 0.7% 7.7 -- Uninet S.A. de C.V. 11 - AS4134 9988 0.7% 23.2 -- CHINANET-BACKBONE No.31,Jin-rong Street 12 - AS45595 9558 0.7% 50.8 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited 13 - AS5722 9513 0.7% 317.1 -- Universidad Nacional de Colombia 14 - AS11492 9107 0.7% 18.1 -- CABLEONE - CABLE ONE, INC. 15 - AS9498 8817 0.6% 12.6 -- BBIL-AP BHARTI Airtel Ltd. 16 - AS15290 8669 0.6% 23.6 -- ALLST-15290 - Allstream Corp. 17 - AS44609 8497 0.6% 2832.3 -- FNA Fars News Agency Cultural Arts Institute 18 - AS6256 8084 0.6% 4042.0 -- ALLTEL - ALLTEL Corporation 19 - AS4755 7616 0.6% 12.6 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 20 - AS9394 7530 0.6% 6.8 -- CRNET CHINA RAILWAY Internet(CRNET) TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6256 8084 0.6% 4042.0 -- ALLTEL - ALLTEL Corporation 2 - AS32528 16548 1.2% 3309.6 -- ABBOTT Abbot Labs 3 - AS17408 3129 0.2% 3129.0 -- ABOVE-AS-AP AboveNet Communications Taiwan 4 - AS44609 8497 0.6% 2832.3 -- FNA Fars News Agency Cultural Arts Institute 5 - AS39261 2298 0.2% 2298.0 -- LPP-AS LPP S.A. 6 - AS51460 6867 0.5% 2289.0 -- SINA-AS Sina bank 7 - AS3454 7492 0.6% 1873.0 -- Universidad Autonoma de Nuevo Leon 8 - AS25352 1798 0.1% 1798.0 -- GUARDIAN-NETWORKS Guardian Networks 9 - AS28519 4073 0.3% 1357.7 -- Universidad Autonoma de Guadalajara, A.C. 10 - AS46778 1250 0.1% 1250.0 -- PHSI-1996 - Prevea Health Services Inc 11 - AS49600 1010 0.1% 1010.0 -- LASEDA La Seda de Barcelona, S.A 12 - AS3 817 0.1% 735.0 -- TRAVIANGAMES Travian Games GmbH 13 - AS27322 756 0.1% 756.0 -- ISC-JNB1 Internet Systems Consortium, Inc. 14 - AS2875 574 0.0% 574.0 -- JINR-AS JINR/HEPNET 15 - AS32717 7270 0.5% 559.2 -- ASN-SNETANGOLA 16 - AS44025 521 0.0% 521.0 -- KAMTELEKOM-NET Kamtelekom Ltd. 17 - AS44878 1010 0.1% 505.0 -- RADIUS-RU-AS Radius Ltd. 18 - AS10445 2152 0.2% 430.4 -- HTG - Huntleigh Telcom 19 - AS49987 409 0.0% 409.0 -- SPARK-AS Stroy Park - R Ltd 20 - AS21578 1213 0.1% 404.3 -- Universidad autonoma de Bucaramanga TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 178.22.72.0/21 8388 0.6% AS44609 -- FNA Fars News Agency Cultural Arts Institute 2 - 130.36.34.0/24 8271 0.6% AS32528 -- ABBOTT Abbot Labs 3 - 130.36.35.0/24 8271 0.6% AS32528 -- ABBOTT Abbot Labs 4 - 200.23.202.0/24 7474 0.5% AS3454 -- Universidad Autonoma de Nuevo Leon 5 - 202.92.235.0/24 7247 0.5% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 6 - 205.91.160.0/20 6408 0.4% AS5976 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 7 - 202.54.86.0/24 4656 0.3% AS4755 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 8 - 198.133.99.0/24 4044 0.3% AS6256 -- ALLTEL - ALLTEL Corporation 9 - 198.133.100.0/24 4040 0.3% AS6256 -- ALLTEL - ALLTEL Corporation 10 - 91.217.64.0/24 3433 0.2% AS51460 -- SINA-AS Sina bank 11 - 91.217.64.0/23 3427 0.2% AS51460 -- SINA-AS Sina bank 12 - 202.153.174.0/24 3129 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 13 - 195.250.37.0/24 2298 0.2% AS39261 -- LPP-AS LPP S.A. 14 - 198.36.88.0/24 2253 0.1% AS26395 -- JCI-200 - Johnson Controls Inc 15 - 67.214.72.0/22 2031 0.1% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 16 - 67.214.68.0/23 1802 0.1% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 17 - 91.212.48.0/24 1798 0.1% AS25352 -- GUARDIAN-NETWORKS Guardian Networks 18 - 41.220.140.0/24 1767 0.1% AS36909 -- HABARI-CO-TZ-AS 19 - 41.220.138.0/24 1738 0.1% AS36909 -- HABARI-CO-TZ-AS 20 - 72.10.56.0/21 1484 0.1% AS31815 -- MEDIATEMPLE - Media Temple, Inc. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jul 8 17:00:01 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 8 Jul 2011 22:00:01 GMT Subject: The Cidr Report Message-ID: <201107082200.p68M01HY079006@wattle.apnic.net> This report has been generated at Fri Jul 8 21:12:24 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 01-07-11 365724 215427 02-07-11 365886 215336 03-07-11 365621 215458 04-07-11 365792 215409 05-07-11 366080 215785 06-07-11 366203 215520 07-07-11 366119 215399 08-07-11 366112 215511 AS Summary 38245 Number of ASes in routing system 16129 Number of ASes announcing only one prefix 3607 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 109927648 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 08Jul11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 366267 215547 150720 41.2% All ASes AS6389 3607 249 3358 93.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4766 2436 952 1484 60.9% KIXS-AS-KR Korea Telecom AS18566 1913 497 1416 74.0% COVAD - Covad Communications Co. AS4755 1499 219 1280 85.4% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS4323 1656 402 1254 75.7% TWTC - tw telecom holdings, inc. AS22773 1350 97 1253 92.8% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS10620 1543 453 1090 70.6% Telmex Colombia S.A. AS1785 1807 765 1042 57.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS19262 1429 392 1037 72.6% VZGNI-TRANSIT - Verizon Online LLC AS28573 1272 387 885 69.6% NET Servicos de Comunicao S.A. AS7545 1548 711 837 54.1% TPG-INTERNET-AP TPG Internet Pty Ltd AS24560 1154 382 772 66.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS18101 916 146 770 84.1% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS8151 1435 680 755 52.6% Uninet S.A. de C.V. AS4808 1050 335 715 68.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7552 795 95 700 88.1% VIETEL-AS-AP Vietel Corporation AS7303 1004 326 678 67.5% Telecom Argentina S.A. AS3356 1119 459 660 59.0% LEVEL3 Level 3 Communications AS17488 964 327 637 66.1% HATHWAY-NET-AP Hathway IP Over Cable Internet AS20115 1594 978 616 38.6% CHARTER-NET-HKY-NC - Charter Communications AS14420 689 83 606 88.0% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS17676 669 71 598 89.4% GIGAINFRA Softbank BB Corp. AS3549 985 413 572 58.1% GBLX Global Crossing Ltd. AS22561 936 368 568 60.7% DIGITAL-TELEPORT - Digital Teleport Inc. AS22047 576 32 544 94.4% VTR BANDA ANCHA S.A. AS4780 751 213 538 71.6% SEEDNET Digital United Inc. AS4804 620 86 534 86.1% MPX-AS Microplex PTY LTD AS17974 1787 1253 534 29.9% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS7011 1156 625 531 45.9% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS15475 514 9 505 98.2% NOL Total 38774 12005 26769 69.0% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 24.225.128.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/23 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.224.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.237.0/24 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.248.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.22.32.0/19 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 89.145.168.0/21 AS42461 PLANETA-AS OOO Planeta 93.180.64.0/18 AS24950 SOFIASAT-AS Venus REIT OOD 93.180.88.0/21 AS42410 PTP-AS Point To Point Ltd. AS 93.180.96.0/19 AS42431 B-NET BiConsult Eood 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 131.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.72.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.100.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.108.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.161.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.221.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.157.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.184.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.191.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.251.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 134.175.0.0/19 AS12124 THORN - Thorn Communications 138.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.36.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.59.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.94.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.97.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.99.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.117.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.118.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.121.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.122.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.185.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.186.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.204.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.219.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 143.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 143.137.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 143.202.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 143.208.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 143.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.101.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.102.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.103.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.156.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.166.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.167.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.168.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.169.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.170.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.171.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.172.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.173.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.174.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.175.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.200.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.201.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.202.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.203.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.204.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.205.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.206.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.207.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.230.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.231.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.232.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.233.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.234.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.235.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.236.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.237.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.238.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.239.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.240.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.241.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.242.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.243.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.244.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.245.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.246.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.247.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.248.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.249.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.250.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.251.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.252.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.253.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.254.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 161.10.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.18.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.22.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.56.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.138.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.140.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.212.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.234.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.56.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.57.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.58.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.59.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.60.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.61.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.62.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.63.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.108.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.116.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.249.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.250.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.90.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.121.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.181.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.194.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.195.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.196.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.197.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.205.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.227.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.228.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.232.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.78.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.79.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.80.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.81.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.82.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.83.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.84.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.150.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.231.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.233.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.238.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.239.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.244.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.245.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.246.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.247.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.254.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 181.82.15.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.16.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.17.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 181.82.18.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 191.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.101.46.0/24 AS6503 Axtel, S.A.B. de C.V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.158.25.0/24 AS2717 CUMMINS-AS1 - Cummins Engine Co. Inc. 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.15.4.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.15.5.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.168.122.0/24 AS11489 BACI - Bell Canada 198.175.231.0/24 AS19262 VZGNI-TRANSIT - Verizon Online LLC 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.33.84.0/22 AS9911 CONNECTPLUS-AP Singapore Telecom 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.24.76.0/24 AS7195 Telecorp Colombia S.A. 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.58.101.0/24 AS45645 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.63.80.0/24 AS9557 PKTELECOM-AS-PK Paknet Limited Merged into PTCL 202.74.232.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.74.233.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.146.186.0/24 AS23655 SNAP-NZ-AS Snap Internet Limited 202.160.152.0/22 AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.18.156.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 204.10.232.0/21 AS33150 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.72.192.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.194.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.10.235.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From chris at nifry.com Fri Jul 8 18:09:49 2011 From: chris at nifry.com (Chris Russell) Date: Sat, 09 Jul 2011 00:09:49 +0100 Subject: In-Reply-To: <690D7D20D2507C44BA8066926B200989183496@ES1002.ic-sa.com> References: <690D7D20D2507C44BA8066926B200989183496@ES1002.ic-sa.com> Message-ID: > Sending 5, 100-byte ICMP Echos to 10.1.4.81, timeout is 2 seconds: > IPSEC(crypto_map_check)-3: Looking for crypto map matching 5-tuple: > Prot=1, saddr=10.20.1.2, sport=29733, daddr=10.1.4.81, dport=29733 > IPSEC(crypto_map_check)-5: Checking crypto map CARIBOU-VPN-1 10: skipping > incomplete map. No peer, access-list or transform-set specified. > IPSEC(crypto_map_check)-1: Error: No crypto map matched. > >>From my understanding this is caused by the crypto map not being able to >>establish a tunnel to the Juniper. From that log, the Cisco is missing numerous configuration items: No peer, access-list or transform-set specified. Do you have the above specified in the crypto map within the ASA ? Cheers Chris From mruiz at lstfinancial.com Sat Jul 9 08:36:56 2011 From: mruiz at lstfinancial.com (Michael Ruiz) Date: Sat, 9 Jul 2011 13:36:56 +0000 Subject: In-Reply-To: Message-ID: <690D7D20D2507C44BA8066926B200989183BBD@ES1002.ic-sa.com> Yes sir. I called cisci tac and according to the asa team, the tunnel cannot be created because the juniper is not the session to be created due to some missmatches. -------------------------- Sent using BlackBerry ----- Original Message ----- From: Chris Russell [mailto:chris at nifry.com] Sent: Friday, July 08, 2011 06:09 PM To: Michael Ruiz Cc: nanog at nanog.org Subject: Re: > Sending 5, 100-byte ICMP Echos to 10.1.4.81, timeout is 2 seconds: > IPSEC(crypto_map_check)-3: Looking for crypto map matching 5-tuple: > Prot=1, saddr=10.20.1.2, sport=29733, daddr=10.1.4.81, dport=29733 > IPSEC(crypto_map_check)-5: Checking crypto map CARIBOU-VPN-1 10: skipping > incomplete map. No peer, access-list or transform-set specified. > IPSEC(crypto_map_check)-1: Error: No crypto map matched. > >>From my understanding this is caused by the crypto map not being able to >>establish a tunnel to the Juniper. From that log, the Cisco is missing numerous configuration items: No peer, access-list or transform-set specified. Do you have the above specified in the crypto map within the ASA ? Cheers Chris CONFIDENTIALITY NOTICE: This message is intended only for the individual or entity to which it is addressed and may contain information that is confidential or exempt from disclosure under applicable law. If you are not the intended recipient, you have received this communication in error. In such case, please notify us immediately by reply e-mail and immediately delete this message and its attachments. Any use, dissemination, redistribution or reproduction of this communication is strictly prohibited. Unless the message explicitly states otherwise, no e-mail correspondence claims to be a contractual offer or acceptance. LST Financial has instructed its employees not to send libelous or inappropriate statements and disclaims responsibility for such. Subject to applicable law, LST Financial may monitor, review and retain e-communications traveling through its networks/systems. By messaging with LST Financial you consent to the foregoing. CONFIDENTIALITY NOTICE: This message is intended only for the individual or entity to which it is addressed and may contain information that is confidential or exempt from disclosure under applicable law. If you are not the intended recipient, you have received this communication in error. In such case, please notify us immediately by reply e-mail and immediately delete this message and its attachments. Any use, dissemination, redistribution or reproduction of this communication is strictly prohibited. Unless the message explicitly states otherwise, no e-mail correspondence claims to be a contractual offer or acceptance. LST Financial has instructed its employees not to send libelous or inappropriate statements and disclaims responsibility for such. Subject to applicable law, LST Financial may monitor, review and retain e-communications traveling through its networks/systems. By messaging with LST Financial you consent to the foregoing. From networkjoe at hotmail.com Sat Jul 9 16:25:27 2011 From: networkjoe at hotmail.com (Bob Network) Date: Sat, 9 Jul 2011 15:25:27 -0600 Subject: Why is IPv6 broken? Message-ID: Why is IPv6 broken? It's broken, first and foremost, because not all network providers who claim to be tier 1 are tier 1. Even worse, some of these providers run 6to4 relays or providers to home users. A user has no choice which provider is running their 6to4 relay...so, they might end up using a relay that is run by a provider who doesn't peer with their intended destination. I don't think the IETF saw that one coming. But the result is to make 6to4 even more broken. Now, I know some people want 6to4 to die, but while it still exists in some form, user experience is worse than it could be. The temporary fix is for any provider to run their own 6to4 relay for their own customers (assuming that they themselves have full connectivity). Right now, unless you buy transit from multiple tier 1s, and do so with carefully chosen tier ones, you have only part of the IPv6 internet. Many tier 1s are unsuitable even as backup connections, since you still want your backup connection to have access to the whole internet! Good tier 2 providers might be an excellent choice, sine good providers have already done this leg work and can monitor their providers for compliance. A few myths... Routing table size has nothing to do with completeness of routes. Google may be one route, through aggregation. And SmallCo may advertise a large route through one provider, and, due to traffic engineering, a smaller route through a second one - in many cases, anyone that had the large route would be able to contact SmallCo, even without the smaller route being present. So routing table size doesn't work. In addition, some providers aggregate their routing tables to reduce routing load and such. Others intentionally don't or deaggregate it intentionally so that they can brag about having bigger routing tables. What you need to ask is: "How many /64s can you get to from your network, and how many of these /64s are reachable from at least one other major provider (you don't care about internal-only networks, after all)?" They can give you that information, but many won't want to. It's also not about technical people not getting along. It's about business players trying to make money, but not just that either. It's also about ensuring that providers don't end up assuming more than their share of costs for a link. Just because you have a common peering point doesn't mean that turning peering on would reduce your costs. In some cases it may increase costs tremendously, particularly on your long haul backbone links, because the other party would like to take advantage of an attitude of trust on the internet. That's why we end up with peering policies and contracts. What is the issue? Let's take Hurricane. This is no different than other providers...basically, they want to say, "We shouldn't need to pay for IPv6 transit from anyone." This is what Cogent said on IPv4 a few years ago. Google used to say this too for IPv6, not sure if they are still saying it. Basically, "We know we're big enough that you won't want to screw your users by not peering with us." A small network couldn't do this tactic - a 100 node network who said to the IPv4 tier 1s: "Hey, I'm in the Podunk Internet Exchange, so are you, so I'm going to peer from you so I don't have to buy any bandwidth for my web server (placed in the Podunk exchange). Sure, they would like to - it would save a ton of money if their site got lots of hits. I mean, who wouldn't want free connectivity? In IPv6, we're going through what we settled years ago in IPv4 - who has to pay who to connect. After all, even free peering connections have a cost in manpower, debugging, traffic engineering, documentation, etc. Some players who aren't getting free interconnection to tier 1s in IPv4 want to get it in IPv6. So they've worked to attract lots of users, and done so under the guise of "We like IPv6 and want to promote it." Others have not bothered with trying to attract the users, but have said, "We're too big for you to not want to give us connectivity for free, since it would piss off your users if you don't" (Google did this at one point in the past, may still be doing it). The Google example is basically trying to use a monopoly position to force business decisions. Now, HE, Google, and others would want you to think, "Hey, IPv6 is all new, and these $#@! other providers just want to make a buck on something they have no right to." Well, perhaps. But what they aren't saying is, "We can turn on BGP for IPv6 on our existing connections to other providers, with no cost to us, and actually have full connectivity." The issue isn't about cost today - nobody is charging extra for IPv6 in addition to IPv4 on a pipe where you already buy IPv4 bandwidth. And Google and HE already buy IPv4 bandwidth. What they are thinking of is the future, 15 years from now, when there is no IPv4 - in that future, IPv6 isn't insignificant bandwidth, it's everything. Wouldn't it be nice to be a tier 1 and not pay for that? Of course! And certainly one can argue for or against the current tier 1 club's exclusivity. But it's the way the internet works right now, for better or worse. In the meantime, in pursuit of this future, today's customers are screwed by these providers trying to position themselves to make more profit margin down the road. Which is better for the customer? A system where they are screwed today so that their provider can have a better negotiating position in business discussions OR a position where they do whatever they have to take to provide the customer with full connectivity? (To HE's credit, they are giving away transit today on IPv6, so it's not like you are losing anything of value by not having the full internet routing tables, but it's a huge reason to not pay HE anything in other services, such as data center colocation - go with a provider that you pay and which gives you what you pay for - full transit). A bit about peering... Lots of people who aren't running big networks don't understand peering. They think, "Doesn't this benefit everyone if everyone exchanges traffic?" Maybe, on a pure level, but the business doesn't work that way. I'll give you an example. Let's say you are a little ISP, and located in Virginia, near a major peering point. You say, "All the tier 1s are there, I can pull fiber to that peering point, which is only a block away, and have free internet, other than the cost of the line." So, let's say you run the line, and, let's say that all the tier 1s agree to let you peer for free, since they want your traffic too. Now, let's say your user downloads 1,000 TB from a server in California, on Qwest's network. You paid, let's say, $15,000 for your piece of fiber going a block. You needed to hire contractors and buy permits and such, after all. So you shared in the costs of letting the user get to the server. What did Qwest pay? Well, they dug trenches, pulled fiber, negotiated with cities, counties, and states, paid taxes on their work, lit this fiber, etc. It cost a lot because they went a lot further than your one block. And a lot more than $15,000. You say, "So what! Their customer benefits too!" That's true, but let's go a bit further. Let's say you have a network that extends to California - you by DS3s from Sprint to do it. There's some cost in that, but your user in Virginia would need more bandwidth than your DS3s. So you decide NOT to peer in California, just in Virginia. That way you don't have to upgrade your lines for your Virginia user. Maybe you even legally break your company into two entities, so that you can peer in California and Virginia both, but you can say with a straight face, "We only have Virginia offices for this user - the other company is a separate entity, and not the entity that owns either the server or the end user." In other words, you found a way to shift most of the traffic burden and infrastructure costs to Qwest, away from your user. This is why Qwest has some sort of peering policy. Among other things, it will require multiple exchange points, and Qwest will probably say they will send traffic to the closest peering point, to minimize their costs. You get to do the same (more on that later). Let's say that you currently buy bandwidth from NTT - you're not big enough to get free peering from everyone, but Qwest agrees to peer with you. Of course Qwest and NTT also have a business relationship, to give each other free peering. If Qwest gives you and many other customers free peering, however, you'll send less traffic across NTT's network. That might be good from a technical standpoint, but NTT now is selling you a smaller pipe - and making less money. In effect, Qwest undercut NTT's business and lowered NTT's profits on the connection. How will NTT respond to that, when they were also giving free peering to and from Qwest? Well, they might decide that Qwest isn't a very nice partner and tell Qwest, "Pay us for transit or get lost." That could be ugly - both NTT and Qwest could lose, but Qwest, if they actually care about stable service, won't want to risk it. So generally you don't give peering to anyone who is a customer of one of your free peers. You don't hurt their business. In fact, it's often a requirement in the peering connection, legally. (that said, you could argue whether or not there is an abuse of monopoly here...that's a different issue) Going one further, let's say you have the server, and Qwest has the end-user. That doesn't change anything - the economics are still such that Qwest has the cost, you don't. That said, it's convention that the person receiving the traffic pays for most of the backhaul. Asymmetry in the Internet: What's the path between your host and a remote server? How do you find it? If you said "traceroute", you might be right, but are probably wrong. You need to trace route both sides. Every provider on the internet is trying to minimize costs. This means that you want traffic to leave your network and go to the destination network with as little distance traveled as possible, because costs go up with distance. It's cheaper to increase the size of pipes within a city to get to a peering point than to increase your backbone pipe size. So, peering contracts typically specify that you dump traffic to the peer as soon as possible. That means the person receiving the traffic generally pays more. It also means that any traffic that crosses an AS boundary almost certainly travels a completely different path each way. In many cases, one third party provider may be used in one direction, another in the other direction. So seeing packet loss on your traceroute at some random tinet router doesn't mean that this router is the cause of any problem, since the return path for that packet from that provider's router might actually cross yet another network that is never transited in either direction for your network connection. (I'm ignoring that most large providers also don't always send ICMP reliably BECAUSE they limit this intentionally to spare the router CPU from overload - it takes router CPU to generate an ICMP TTL exceeded, but it doesn't take router CPU to forward a packet - so traceroute or ping indicating loss at a router doesn't mean anything in itself - the path itself likely has zero percent loss). So, here's the scenerio. Let's say a user and a server are on two seperate networks, U (user) and S (server). Let's say they both utilize transit provider T. So the path could be: U -- T -- S. S buys an OC12 from T, while U buys a T1. But let's say that the user has a second transit provider, BIG, who is a free peer of T. He bought an OC3 from BIG. So there's another path between U and S: U -- BIG -- T -- S. Likely this path is much faster than U -- T -- S. So, the path for the traffic to S goes U -- T -- S. Now, what path does the traffic from T's router go, when T's router generates an ICMP TTL exceeded in response from a traceroute from a user? Does it go straight over the T1 line, or does it go over the peering connection to BIG and then to the customer? The answer, it turns out, depends on network configuration and policy. Let's say it goes out over the T1, but the T1 is congested. It will look like the congestion is at the connection between BIG and T, because this is the first hop that will show packet loss. BUT...the congestion is actually at the U's connection to T, which is irrelevant to the actual traffic path between U and S. So the user, at this point, calls up BIG and T and bitches about "Your peering congestion is congested" when the real problem is that traffic completely unrelated to the user's problem is going via a congested path that is never used for connectivity between U and S. If you add several providers into this loop, you can end up with a situation where traffic uses Sprint in one direction, but never hits a Sprint router in the other. This is actually very common. A user with slow downloads might be experiencing packet loss on the path from server to user, but not the other way around. In other words, the problem is a provider that never shows up on the user's traceroute! Remember that the providers hand off the traffic as soon as possible to their peer. So, whoever receives the larger amount of traffic needs the bigger cross-country (or trans-oceanic) links. If one side transmits a T1's worth of data, the other side transmits an OC48's worth of data, only one needs the OC48s across the country - the one receiving the traffic. That's why you hear about "traffic ratios". If the traffic is even both ways, both sides have to pay for the same amount of cross-country infrastructure to carry that traffic. So most providers won't peer with someone for free that sends, say, 10 times the amount of traffic that they will receive. It would end up costing a lot of money Back to IPv6...that's interesting, but what does it have to do with IPv6? Some providers want to do away with traffic ratio policies, mutliple location peering, not providing free services to the other's customers, etc. THAT is why you can't ping some sites from your HE tunnel. It's not just that providers won't peer. It's also that providers have rules to keep themselves from getting screwed. Certainly, there's ways around some of this (for example, traffic ratios - if I make sure my network is used for the cross-country traffic I send, not yours, then I've addressed that concern at a bit of increased expense for myself). But it's generally not worth doing until the size of the providers is sufficiently large. Other things don't have a good technical fix, like not peering with your peer's customer - that's a business rule. From jhell at DataIX.net Sat Jul 9 19:21:45 2011 From: jhell at DataIX.net (Jason Hellenthal) Date: Sat, 9 Jul 2011 20:21:45 -0400 Subject: Why is IPv6 broken? In-Reply-To: References: Message-ID: <20110710002145.GA64489@DataIX.net> Where did you get all this from ? There is not even one single reference to a URL, not to be rude but how long did it take you to write this theory ? As for "It's broken, first and foremost..." They may be a Tier 1 provider of other services and also happen to offer IPv6 at which they are only a Tier 2 or 3 but using the marketing gimics of theyre original Tier 1 status to get acknowledgement. I stopped reading shortly after 'I think' the second paragraph and scanned the rest for URLs that might have made this clear and to the point but did not find any. Heresay. On Sat, Jul 09, 2011 at 03:25:27PM -0600, Bob Network wrote: > > Why is IPv6 broken? > > It's broken, first and foremost, because not all network providers who claim to be tier 1 are tier 1. > > Even worse, some of these providers run 6to4 relays or providers to home users. A user has no choice which provider is running their 6to4 relay...so, they might end up using a relay that is run by a provider who doesn't peer with their intended destination. I don't think the IETF saw that one coming. But the result is to make 6to4 even more broken. Now, I know some people want 6to4 to die, but while it still exists in some form, user experience is worse than it could be. The temporary fix is for any provider to run their own 6to4 relay for their own customers (assuming that they themselves have full connectivity). > > Right now, unless you buy transit from multiple tier 1s, and do so with carefully chosen tier ones, you have only part of the IPv6 internet. Many tier 1s are unsuitable even as backup connections, since you still want your backup connection to have access to the whole internet! Good tier 2 providers might be an excellent choice, sine good providers have already done this leg work and can monitor their providers for compliance. > > A few myths... > > Routing table size has nothing to do with completeness of routes. Google may be one route, through aggregation. And SmallCo may advertise a large route through one provider, and, due to traffic engineering, a smaller route through a second one - in many cases, anyone that had the large route would be able to contact SmallCo, even without the smaller route being present. So routing table size doesn't work. In addition, some providers aggregate their routing tables to reduce routing load and such. Others intentionally don't or deaggregate it intentionally so that they can brag about having bigger routing tables. What you need to ask is: "How many /64s can you get to from your network, and how many of these /64s are reachable from at least one other major provider (you don't care about internal-only networks, after all)?" They can give you that information, but many won't want to. > > It's also not about technical people not getting along. It's about business players trying to make money, but not just that either. It's also about ensuring that providers don't end up assuming more than their share of costs for a link. Just because you have a common peering point doesn't mean that turning peering on would reduce your costs. In some cases it may increase costs tremendously, particularly on your long haul backbone links, because the other party would like to take advantage of an attitude of trust on the internet. That's why we end up with peering policies and contracts. > > What is the issue? > > Let's take Hurricane. This is no different than other providers...basically, they want to say, "We shouldn't need to pay for IPv6 transit from anyone." This is what Cogent said on IPv4 a few years ago. Google used to say this too for IPv6, not sure if they are still saying it. Basically, "We know we're big enough that you won't want to screw your users by not peering with us." > > A small network couldn't do this tactic - a 100 node network who said to the IPv4 tier 1s: "Hey, I'm in the Podunk Internet Exchange, so are you, so I'm going to peer from you so I don't have to buy any bandwidth for my web server (placed in the Podunk exchange). Sure, they would like to - it would save a ton of money if their site got lots of hits. I mean, who wouldn't want free connectivity? > > In IPv6, we're going through what we settled years ago in IPv4 - who has to pay who to connect. After all, even free peering connections have a cost in manpower, debugging, traffic engineering, documentation, etc. > > Some players who aren't getting free interconnection to tier 1s in IPv4 want to get it in IPv6. So they've worked to attract lots of users, and done so under the guise of "We like IPv6 and want to promote it." Others have not bothered with trying to attract the users, but have said, "We're too big for you to not want to give us connectivity for free, since it would piss off your users if you don't" (Google did this at one point in the past, may still be doing it). The Google example is basically trying to use a monopoly position to force business decisions. > > Now, HE, Google, and others would want you to think, "Hey, IPv6 is all new, and these $#@! other providers just want to make a buck on something they have no right to." Well, perhaps. But what they aren't saying is, "We can turn on BGP for IPv6 on our existing connections to other providers, with no cost to us, and actually have full connectivity." The issue isn't about cost today - nobody is charging extra for IPv6 in addition to IPv4 on a pipe where you already buy IPv4 bandwidth. And Google and HE already buy IPv4 bandwidth. What they are thinking of is the future, 15 years from now, when there is no IPv4 - in that future, IPv6 isn't insignificant bandwidth, it's everything. Wouldn't it be nice to be a tier 1 and not pay for that? Of course! And certainly one can argue for or against the current tier 1 club's exclusivity. But it's the way the internet works right now, for better or worse. In the meantime, in pursuit of this future, today's customers are screwed by these providers trying to position themselves to make more profit margin down the road. > > Which is better for the customer? A system where they are screwed today so that their provider can have a better negotiating position in business discussions OR a position where they do whatever they have to take to provide the customer with full connectivity? (To HE's credit, they are giving away transit today on IPv6, so it's not like you are losing anything of value by not having the full internet routing tables, but it's a huge reason to not pay HE anything in other services, such as data center colocation - go with a provider that you pay and which gives you what you pay for - full transit). > > A bit about peering... > > Lots of people who aren't running big networks don't understand peering. They think, "Doesn't this benefit everyone if everyone exchanges traffic?" Maybe, on a pure level, but the business doesn't work that way. > > I'll give you an example. Let's say you are a little ISP, and located in Virginia, near a major peering point. You say, "All the tier 1s are there, I can pull fiber to that peering point, which is only a block away, and have free internet, other than the cost of the line." So, let's say you run the line, and, let's say that all the tier 1s agree to let you peer for free, since they want your traffic too. Now, let's say your user downloads 1,000 TB from a server in California, on Qwest's network. > > You paid, let's say, $15,000 for your piece of fiber going a block. You needed to hire contractors and buy permits and such, after all. So you shared in the costs of letting the user get to the server. What did Qwest pay? Well, they dug trenches, pulled fiber, negotiated with cities, counties, and states, paid taxes on their work, lit this fiber, etc. It cost a lot because they went a lot further than your one block. And a lot more than $15,000. > > You say, "So what! Their customer benefits too!" That's true, but let's go a bit further. Let's say you have a network that extends to California - you by DS3s from Sprint to do it. There's some cost in that, but your user in Virginia would need more bandwidth than your DS3s. So you decide NOT to peer in California, just in Virginia. That way you don't have to upgrade your lines for your Virginia user. Maybe you even legally break your company into two entities, so that you can peer in California and Virginia both, but you can say with a straight face, "We only have Virginia offices for this user - the other company is a separate entity, and not the entity that owns either the server or the end user." > > In other words, you found a way to shift most of the traffic burden and infrastructure costs to Qwest, away from your user. > > This is why Qwest has some sort of peering policy. Among other things, it will require multiple exchange points, and Qwest will probably say they will send traffic to the closest peering point, to minimize their costs. You get to do the same (more on that later). > > Let's say that you currently buy bandwidth from NTT - you're not big enough to get free peering from everyone, but Qwest agrees to peer with you. Of course Qwest and NTT also have a business relationship, to give each other free peering. If Qwest gives you and many other customers free peering, however, you'll send less traffic across NTT's network. That might be good from a technical standpoint, but NTT now is selling you a smaller pipe - and making less money. In effect, Qwest undercut NTT's business and lowered NTT's profits on the connection. How will NTT respond to that, when they were also giving free peering to and from Qwest? Well, they might decide that Qwest isn't a very nice partner and tell Qwest, "Pay us for transit or get lost." That could be ugly - both NTT and Qwest could lose, but Qwest, if they actually care about stable service, won't want to risk it. So generally you don't give peering to anyone who is a customer of one of your free peers. You don't hurt their business. In fact, it's often a requirement in the peering connection, legally. (that said, you could argue whether or not there is an abuse of monopoly here...that's a different issue) > > Going one further, let's say you have the server, and Qwest has the end-user. That doesn't change anything - the economics are still such that Qwest has the cost, you don't. That said, it's convention that the person receiving the traffic pays for most of the backhaul. > > Asymmetry in the Internet: > > What's the path between your host and a remote server? How do you find it? If you said "traceroute", you might be right, but are probably wrong. You need to trace route both sides. > > Every provider on the internet is trying to minimize costs. This means that you want traffic to leave your network and go to the destination network with as little distance traveled as possible, because costs go up with distance. It's cheaper to increase the size of pipes within a city to get to a peering point than to increase your backbone pipe size. So, peering contracts typically specify that you dump traffic to the peer as soon as possible. That means the person receiving the traffic generally pays more. It also means that any traffic that crosses an AS boundary almost certainly travels a completely different path each way. In many cases, one third party provider may be used in one direction, another in the other direction. So seeing packet loss on your traceroute at some random tinet router doesn't mean that this router is the cause of any problem, since the return path for that packet from that provider's router might actually cross yet another network that is never transited in either direction for your network connection. (I'm ignoring that most large providers also don't always send ICMP reliably BECAUSE they limit this intentionally to spare the router CPU from overload - it takes router CPU to generate an ICMP TTL exceeded, but it doesn't take router CPU to forward a packet - so traceroute or ping indicating loss at a router doesn't mean anything in itself - the path itself likely has zero percent loss). > > So, here's the scenerio. > > Let's say a user and a server are on two seperate networks, U (user) and S (server). > > Let's say they both utilize transit provider T. So the path could be: U -- T -- S. S buys an OC12 from T, while U buys a T1. > > But let's say that the user has a second transit provider, BIG, who is a free peer of T. He bought an OC3 from BIG. So there's another path between U and S: U -- BIG -- T -- S. Likely this path is much faster than U -- T -- S. > > So, the path for the traffic to S goes U -- T -- S. > > Now, what path does the traffic from T's router go, when T's router generates an ICMP TTL exceeded in response from a traceroute from a user? Does it go straight over the T1 line, or does it go over the peering connection to BIG and then to the customer? The answer, it turns out, depends on network configuration and policy. Let's say it goes out over the T1, but the T1 is congested. It will look like the congestion is at the connection between BIG and T, because this is the first hop that will show packet loss. BUT...the congestion is actually at the U's connection to T, which is irrelevant to the actual traffic path between U and S. So the user, at this point, calls up BIG and T and bitches about "Your peering congestion is congested" when the real problem is that traffic completely unrelated to the user's problem is going via a congested path that is never used for connectivity between U and S. > > If you add several providers into this loop, you can end up with a situation where traffic uses Sprint in one direction, but never hits a Sprint router in the other. This is actually very common. A user with slow downloads might be experiencing packet loss on the path from server to user, but not the other way around. In other words, the problem is a provider that never shows up on the user's traceroute! > > Remember that the providers hand off the traffic as soon as possible to > their peer. So, whoever receives the larger amount of traffic needs the > bigger cross-country (or trans-oceanic) links. If one side transmits a > T1's worth of data, the other side transmits an OC48's worth of data, > only one needs the OC48s across the country - the one receiving the > traffic. That's why you hear about "traffic ratios". If the traffic is even both ways, both sides have to pay for the same amount of cross-country infrastructure to carry that traffic. So most providers won't peer with someone for free that sends, say, 10 times the amount of traffic that they will receive. It would end up costing a lot of money > > Back to IPv6...that's interesting, but what does it have to do with IPv6? > > Some providers want to do away with traffic ratio policies, mutliple location peering, not providing free services to the other's customers, etc. > > THAT is why you can't ping some sites from your HE tunnel. It's not just that providers won't peer. It's also that providers have rules to keep themselves from getting screwed. > > Certainly, there's ways around some of this (for example, traffic ratios - if I make sure my network is used for the cross-country traffic I send, not yours, then I've addressed that concern at a bit of increased expense for myself). But it's generally not worth doing until the size of the providers is sufficiently large. Other things don't have a good technical fix, like not peering with your peer's customer - that's a business rule. > > From ryan.finnesey at HarrierInvestments.com Sat Jul 9 21:09:39 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Sat, 9 Jul 2011 19:09:39 -0700 Subject: Terremark's NCR in Canada? Message-ID: <6EFFEFBAC68377459A2E972105C759EC03C1B2E2@EXVBE005-2.exch005intermedia.net> Hi All Can anyone recommend a center similar to Terremark's NCR in Canada? Cheers Ryan From jsw at inconcepts.biz Sun Jul 10 09:14:38 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sun, 10 Jul 2011 10:14:38 -0400 Subject: Why is IPv6 broken? In-Reply-To: References: Message-ID: On Sat, Jul 9, 2011 at 5:25 PM, Bob Network wrote: > Why is IPv6 broken? You should have titled your thread, "my own personal rant about Hurricane Electric's IPv6 strategy." You may also have left out the dodgy explanation of peering policies and technicalities, since these issues have been remarkably static since about 1996. The names of the networks change, but the song remains the same. This is not a novel subject on this mailing list. In fact, there have been a number of threads discussing HE's practices lately. If you are so interested in them, I suggest you review the list archive. There are quite a few serious, unresolved technical problems with IPv6 adoption besides a few networks playing chicken with their collective customer-bases. The lack of will on the part of vendors and operators to participate in the IETF process, and make necessary and/or beneficial changes to the IPv6 standards, has left us in a situation where IPv6 implementation produces networks which are vulnerable to trivial DoS attacks and network intrusions. The lack of will on the part of access providers to insist on functioning IPv6 support on CPE and BRAS platforms has even mid-sized ISPs facing nine-figure (as in, hundred-million-dollars) expenses to forklift-upgrade their access networks and end-user equipment, at a time when IPv6 seems to be the only way to continue growing the Internet. The lack of will on the part of major transit networks, including Savvis, to deploy IPv6 capabilities to their customers, means that customers caught in multi-year contracts may have no option for native connectivity. Cogent's policy of requiring a new contract, and from what I am still being told by some European customers, new money, from customers in exchange for provisioning IPv6 on existing circuits, means a simple technical project gets caught up in the complexities of budgeting and contract execution. If you believe that the most serious problem facing IPv6 adoption is that HE / Level3 / Cogent don't carry a full table, you are living in a fantasy world. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From dmiller at tiggee.com Sun Jul 10 10:56:53 2011 From: dmiller at tiggee.com (David Miller) Date: Sun, 10 Jul 2011 11:56:53 -0400 Subject: Why is IPv6 broken? In-Reply-To: References: Message-ID: <4E19CBC5.3000801@tiggee.com> On 7/10/2011 10:14 AM, Jeff Wheeler wrote: > On Sat, Jul 9, 2011 at 5:25 PM, Bob Network wrote: >> Why is IPv6 broken? > You should have titled your thread, "my own personal rant about > Hurricane Electric's IPv6 strategy." You may also have left out the > dodgy explanation of peering policies and technicalities, since these > issues have been remarkably static since about 1996. The names of the > networks change, but the song remains the same. This is not a novel > subject on this mailing list. In fact, there have been a number of > threads discussing HE's practices lately. If you are so interested in > them, I suggest you review the list archive. > > There are quite a few serious, unresolved technical problems with IPv6 > adoption besides a few networks playing chicken with their collective > customer-bases. The lack of will on the part of vendors and operators > to participate in the IETF process, and make necessary and/or > beneficial changes to the IPv6 standards, has left us in a situation > where IPv6 implementation produces networks which are vulnerable to > trivial DoS attacks and network intrusions. > > The lack of will on the part of access providers to insist on > functioning IPv6 support on CPE and BRAS platforms has even mid-sized > ISPs facing nine-figure (as in, hundred-million-dollars) expenses to > forklift-upgrade their access networks and end-user equipment, at a > time when IPv6 seems to be the only way to continue growing the > Internet. > > The lack of will on the part of major transit networks, including > Savvis, to deploy IPv6 capabilities to their customers, means that > customers caught in multi-year contracts may have no option for native > connectivity. Cogent's policy of requiring a new contract, and from > what I am still being told by some European customers, new money, from > customers in exchange for provisioning IPv6 on existing circuits, > means a simple technical project gets caught up in the complexities of > budgeting and contract execution. +1 The lack of will on the part of the IETF to attract input from and involve operators in their processes (which I would posit is a critical element in the process). And the lack of will/fore site on the part of the IETF to respond to input from operators that they have received. If fingers can be pointed at both sides, i.e. operators and IETF, then both sides are to blame. The IETF only has value if they are publishing "standards" that work properly in the real world. If the implementers of these "standards" say that they are broken, then the IETF has failed to provide value. > > If you believe that the most serious problem facing IPv6 adoption is > that HE / Level3 / Cogent don't carry a full table, you are living in > a fantasy world. +1 -DMM From jeroen at unfix.org Sun Jul 10 11:16:09 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Sun, 10 Jul 2011 18:16:09 +0200 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: <4E19CBC5.3000801@tiggee.com> References: <4E19CBC5.3000801@tiggee.com> Message-ID: <4E19D049.8010006@unfix.org> On 2011-07-10 17:56 , David Miller wrote: [..] > +1 > > The lack of will on the part of the IETF to attract input from and involve > operators in their processes (which I would posit is a critical element in > the process). Ehmmmm ANYBODY, including you, can sign up to the IETF mailing lists and participate there, just like a couple of folks from NANOG are already doing. You are on NANOG out of your own free will, the same applies to the IETF. If you don't participate here your voice is not heard either, just like at the IETF. Peeking at the ipv6 at ietf.org member list, I don't see your name there. You can signup here: https://www.ietf.org/mailman/listinfo/ipv6 Greets, Jeroen From caldcv at gmail.com Sun Jul 10 12:26:26 2011 From: caldcv at gmail.com (Chris) Date: Sun, 10 Jul 2011 13:26:26 -0400 Subject: CNN security contact? Message-ID: Yet another Casey Anthony scam floating around but via a vulnerability in CNN's advertising system so Facebook lusers think it's authentic and from CNN. GoDaddy domain and Softlayer hosting the site.. called Softlayer NOC - "1 person is in the abuse department on Sunday" -- --C "The dumber people think you are, the more surprised they're going to be when you kill them." - Sir William Clayton From fw at deneb.enyo.de Sun Jul 10 12:36:16 2011 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 10 Jul 2011 19:36:16 +0200 Subject: How long is reasonable to fix a routing issue in IPv6? In-Reply-To: <20110708212433.GA12275@vacation.karoshi.com.> (bmanning@vacation.karoshi.com's message of "Fri, 8 Jul 2011 21:24:33 +0000") References: <20110707023931.B91E111920D3@drugs.dv.isc.org> <9634AA8C-C8FD-4AFE-A888-82C9C326636D@puck.nether.net> <20110707061426.4A96F1195F60@drugs.dv.isc.org> <87fwmged6u.fsf@mid.deneb.enyo.de> <20110708212433.GA12275@vacation.karoshi.com.> Message-ID: <87ei1y6nsf.fsf@mid.deneb.enyo.de> > On Fri, Jul 08, 2011 at 10:21:13PM +0200, Florian Weimer wrote: >> * Jared Mauch: >> >> > 2) is a mapped-v4 address a valid *source* address on the wire >> > even if it's not a valid dest? >> >> By the way, has the analogous issue involving v4 addresses from >> RFC 1918 space ever been settled? > > define "valid"? "Exempt from BCP 38 filters". I thought that was clear enough, sorry. 8-) From dmiller at tiggee.com Sun Jul 10 12:41:28 2011 From: dmiller at tiggee.com (David Miller) Date: Sun, 10 Jul 2011 13:41:28 -0400 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: <4E19D049.8010006@unfix.org> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> Message-ID: <4E19E448.9070807@tiggee.com> On 7/10/2011 12:16 PM, Jeroen Massar wrote: > On 2011-07-10 17:56 , David Miller wrote: > [..] >> +1 >> >> The lack of will on the part of the IETF to attract input from and involve >> operators in their processes (which I would posit is a critical element in >> the process). > Ehmmmm ANYBODY, including you, can sign up to the IETF mailing lists and > participate there, just like a couple of folks from NANOG are already doing. > > You are on NANOG out of your own free will, the same applies to the > IETF. If you don't participate here your voice is not heard either, just > like at the IETF. True, anyone can participate in the IETF processes. However, if key players do not participate, then something is broken. I will take my lumps for not participating. My point was - "If fingers can be pointed at both sides, i.e. operators and IETF, then both sides are to blame." In the corporate world, if I were contemplating changing the framework of a system, then I would need to get buy in / agreement from the stakeholders of that system. If I was going to change the framework behind an HR system, then the HR managers and HR systems experts would all have to agree to the change. If I changed the framework and broke all of the HR systems and then told my boss that I scheduled a meeting and nobody from HR showed up and therefore I used that as agreement in their absence, then I would get fired. Yes, I understand that corporate environments are very different from the IETF environment, but there are perhaps some lessons to learn from the corporate environment. Most RFCs operate within a meritocracy. A standard can be proposed for "Example Protocol v10" and if nobody likes it outside of the IETF, then it is not implemented by anyone and it eventually dies on the vine. IPv6 is "different" in that it is the underpinning of every other protocol/standard that will exist on or operate over the internet for the next 20-30 years (probably) We had 10+ years of IPv6 not being implemented by anyone (seriously), yet it didn't die on the vine. Perhaps the process for "Example Protocol v10" and the process for IPv6 should be different - given the fundamental difference in their scope. No, we can't change the past. "Those who do not learn from history are doomed to repeat it." - Santayana. I would say that many variables that got us to where we are today - which is out of IPv4 addresses and faced with only IPv6, which many believe is fundamentally flawed, as our only way forward - holds some lessons to be learned... but perhaps this is just me - and if so, I apologize for the noise. > > Peeking at the ipv6 at ietf.org member list, I don't see your name there. > You can signup here: https://www.ietf.org/mailman/listinfo/ipv6 Absolutely true, fixed. > > Greets, > Jeroen -DMM From bill at herrin.us Sun Jul 10 14:23:46 2011 From: bill at herrin.us (William Herrin) Date: Sun, 10 Jul 2011 15:23:46 -0400 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: <4E19E448.9070807@tiggee.com> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <4E19E448.9070807@tiggee.com> Message-ID: On Sun, Jul 10, 2011 at 1:41 PM, David Miller wrote: > On 7/10/2011 12:16 PM, Jeroen Massar wrote: >> You are on NANOG out of your own free will, the same applies to the >> IETF. If you don't participate here your voice is not heard either, just >> like at the IETF. > > True, anyone can participate in the IETF processes. ?However, if key players > do not participate, then something is broken. ?I will take my lumps for not > participating. > > My point was - "If fingers can be pointed at both sides, i.e. operators and > IETF, then both sides are to blame." Hi David, This is a process problem, not an individual problem. The IETF is run by volunteers. They volunteer because they find designing protocols to be fun. For the most part, operators are not entertained by designing network protocols. So, for the most part they don't partiticpate. This is not going to change. And it also isn't the problem -- people who enjoy the work tend to do better work. The problem is that the IETF routinely exceeds the scope of designing network protocols. Participants in the working groups take what are fundamentally operations issues unto themselves. They do so knowing they lack adequate participation by network operators. And the process that leads to RFCs offers inadequate checks and balances to mitigate that behavior. Consider, for example, RFC 3484. That's the one that determines how an IPv6 capable host selects which of a group of candidate IPv4 and IPv6 addresses for a particular host name gets priority. How is a server's address priority NOT an issue that should be managed at an operations level by individual server administrators? Yet the working group which produced it came up with a static prioritization that is the root cause of a significant portion of the IPv6 deployment headaches we face. I don't know the whole solution to this problem, but I'm pretty sure I know the first step. Today's RFC candidates are required to call out IANA considerations and security considerations in special sections. They do so because each of these areas has landmines that the majority of working groups are ill equipped to consider on their own. There should be an operations callout as well -- a section where proposed operations defaults (as well as statics for which a solid case can be made for an operations tunable) are extracted from the thick of it and offered for operator scrutiny prior to publication of the RFC. Food for thought. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bmanning at vacation.karoshi.com Sun Jul 10 14:18:58 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 10 Jul 2011 19:18:58 +0000 Subject: Why is IPv6 broken? In-Reply-To: References: Message-ID: <20110710191858.GB23171@vacation.karoshi.com.> so... how much of the heavy lifting are you personally willing to do and how much are you depending/expecting others to do on your behalf? public whining that the v6 network does not mirror the v4 network is not productive and is not news. of course ymmv. /bill From owen at delong.com Sun Jul 10 14:45:51 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 10 Jul 2011 12:45:51 -0700 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: <4E19D049.8010006@unfix.org> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> Message-ID: <5F4FCDA1-EE05-4CBD-9E3B-91EEE5083D8A@delong.com> On Jul 10, 2011, at 9:16 AM, Jeroen Massar wrote: > On 2011-07-10 17:56 , David Miller wrote: > [..] >> +1 >> >> The lack of will on the part of the IETF to attract input from and involve >> operators in their processes (which I would posit is a critical element in >> the process). > > Ehmmmm ANYBODY, including you, can sign up to the IETF mailing lists and > participate there, just like a couple of folks from NANOG are already doing. > > You are on NANOG out of your own free will, the same applies to the > IETF. If you don't participate here your voice is not heard either, just > like at the IETF. > > Peeking at the ipv6 at ietf.org member list, I don't see your name there. > You can signup here: https://www.ietf.org/mailman/listinfo/ipv6 > > Greets, > Jeroen While this is true, there are a couple of factors that make it more difficult than it would appear on the surface. Number one: Participating effectively in IETF is a rather time-consuming process. While a lot of engineers and developers may have IETF effort as a primary part of their job function and/or get their employer to let them spend time on it, operators are often too busy keeping what they already have running and it can be _VERY_ difficult to get management to support the idea of investing time in things like IETF which are not seen by management as having direct operational impact. NANOG is about the limit of their vision on such things and even that is not well supported in a lot of organizations. Number two: While anyone can participate, approaching IETF as an operator requires a rather thick skin, or, at least it did the last couple of times I attempted to participate. I've watched a few times where operators were shouted down by purists and religion over basic real-world operational concerns. It seems to be a relatively routine practice and does not lead to operators wanting to come back to an environment where they feel unwelcome. Owen From mike at mtcc.com Sun Jul 10 15:05:57 2011 From: mike at mtcc.com (Michael Thomas) Date: Sun, 10 Jul 2011 13:05:57 -0700 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: <5F4FCDA1-EE05-4CBD-9E3B-91EEE5083D8A@delong.com> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <5F4FCDA1-EE05-4CBD-9E3B-91EEE5083D8A@delong.com> Message-ID: <4E1A0625.7000407@mtcc.com> On 07/10/2011 12:45 PM, Owen DeLong wrote: > > While this is true, there are a couple of factors that make it more difficult > than it would appear on the surface. > > Number one: Participating effectively in IETF is a rather time-consuming > process. While a lot of engineers and developers may have IETF effort > as a primary part of their job function and/or get their employer to let > them spend time on it, operators are often too busy keeping what they > already have running and it can be _VERY_ difficult to get management > to support the idea of investing time in things like IETF which are not > seen by management as having direct operational impact. NANOG > is about the limit of their vision on such things and even that is not > well supported in a lot of organizations. > Vendors make up the vast bulk of attendance at ietf. And vendors are there for one reason: to make stuff that you'll be paying for. So you pay for it at ietf time, or you pay for it at deployment time. Either way, you'll be paying. > Number two: While anyone can participate, approaching IETF as an > operator requires a rather thick skin, or, at least it did the last couple > of times I attempted to participate. I've watched a few times where > operators were shouted down by purists and religion over basic > real-world operational concerns. It seems to be a relatively routine > practice and does not lead to operators wanting to come back to > an environment where they feel unwelcome. > If you're trying to imply that operators get singled out, that's not been my experience. You definitely need to have a thick skin given egos and there's definitely a large pool of professional ietf finger waggers, but their holier than thou attitude is spread to all in their path, from what I've seen. I won't speak for every working group, but the ones i've been involved with have been pretty receptive to operator input. Mike From owen at delong.com Sun Jul 10 15:22:52 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 10 Jul 2011 13:22:52 -0700 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <4E19E448.9070807@tiggee.com> Message-ID: On Jul 10, 2011, at 12:23 PM, William Herrin wrote: > On Sun, Jul 10, 2011 at 1:41 PM, David Miller wrote: >> On 7/10/2011 12:16 PM, Jeroen Massar wrote: >>> You are on NANOG out of your own free will, the same applies to the >>> IETF. If you don't participate here your voice is not heard either, just >>> like at the IETF. >> >> True, anyone can participate in the IETF processes. However, if key players >> do not participate, then something is broken. I will take my lumps for not >> participating. >> >> My point was - "If fingers can be pointed at both sides, i.e. operators and >> IETF, then both sides are to blame." > > Hi David, > > This is a process problem, not an individual problem. > > The IETF is run by volunteers. They volunteer because they find > designing protocols to be fun. For the most part, operators are not > entertained by designing network protocols. So, for the most part they > don't partiticpate. > > This is not going to change. And it also isn't the problem -- people > who enjoy the work tend to do better work. > > The problem is that the IETF routinely exceeds the scope of designing > network protocols. Participants in the working groups take what are > fundamentally operations issues unto themselves. They do so knowing > they lack adequate participation by network operators. And the process > that leads to RFCs offers inadequate checks and balances to mitigate > that behavior. > > Consider, for example, RFC 3484. That's the one that determines how an > IPv6 capable host selects which of a group of candidate IPv4 and IPv6 > addresses for a particular host name gets priority. How is a server's > address priority NOT an issue that should be managed at an operations > level by individual server administrators? Yet the working group which > produced it came up with a static prioritization that is the root > cause of a significant portion of the IPv6 deployment headaches we > face. > 3484 specifies a static default. By definition, defaults in absence of operator configuration kind of have to be static. Having a reasonable and expected set of defaults documented in an RFC provides a known quantity for what operators can/should expect from hosts they have not configured. I see nothing wrong with RFC 3484 other than I would agree that the choices made were suboptimal. Mostly that was based on optimism and a lack of experience available at the time of writing. There is another RFC and there are APIs and most operating systems have configuration mechanisms where an operator CAN set that to something other than the 3484 defaults. > > I don't know the whole solution to this problem, but I'm pretty sure I > know the first step. > I don't know what you had in mind, but, reading RFC 5014 would be my suggestion as a good starting point. > Today's RFC candidates are required to call out IANA considerations > and security considerations in special sections. They do so because > each of these areas has landmines that the majority of working groups > are ill equipped to consider on their own. > > There should be an operations callout as well -- a section where > proposed operations defaults (as well as statics for which a solid > case can be made for an operations tunable) are extracted from the > thick of it and offered for operator scrutiny prior to publication of > the RFC. > I think this would be a good idea, actually. It would probably be more effective to propose it to IETF than to NANOG, however. Owen From jsw at inconcepts.biz Sun Jul 10 15:43:40 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sun, 10 Jul 2011 16:43:40 -0400 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: <5F4FCDA1-EE05-4CBD-9E3B-91EEE5083D8A@delong.com> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <5F4FCDA1-EE05-4CBD-9E3B-91EEE5083D8A@delong.com> Message-ID: On Sun, Jul 10, 2011 at 3:45 PM, Owen DeLong wrote: > Number two: While anyone can participate, approaching IETF as an > operator requires a rather thick skin, or, at least it did the last couple > of times I attempted to participate. I've watched a few times where I am subscribed to the IDR (BGP, etc.) and LISP lists. These are populated with different people and cover entirely different topics. My opinion is the following: * The IDR list is welcoming of operators, but whether or not your opinion is listened to or included in the process, I do not know. Randy Bush, alone, posts more on this list than the sum of all operators who post in the time I've been reading. I think Randy's influence is 100% negative, and it concerns me deeply that one individual has the potential to do so much damage to essential protocols like BGP. Also, the priorities of this list are pretty fucked. Inaction within this working group is the reason we still don't have expanded BGP communities for 32 bit ASNs. The reason for this is operators aren't participating. The people on the list or the current participants of the WG should not be blamed. My gripe about Randy Bush having the potential to do huge damage would not exist if there were enough people on the list who understand what they're doing to offer counter-arguments. > operators were shouted down by purists and religion over basic > real-world operational concerns. It seems to be a relatively routine > practice and does not lead to operators wanting to come back to > an environment where they feel unwelcome. I have found my input on the LISP list completely ignored because, as you suggest, my concerns are real-world and don't have any impact on someone's pet project. LISP as it stands today can never work on the Internet, and regardless of the fine reputations of the people at Cisco and other organizations who are working on it, they are either furthering it only because they would rather work on a pet project than something useful to customers, or because they truly cannot understand its deep, insurmountable design flaws at Internet-scale. You would generally hope that someone saying, "LISP can't work at Internet-scale because anyone will be able to trivially DoS any LISP ITR ('router' for simplicity), but here is a way you can improve it," well, that remark, input, and person should be taken quite seriously, their input examined, and other assumptions about the way LISP is supposed to work ought to be questioned. None of this has happened. LISP is a pet project to get some people their Ph.D.s and keep some old guard vendor folks from jumping ship to another company. It is a shame that the IETF is manipulated to legitimize that kind of thing. Then again, I could be wrong. Randy Bush could be a genius and LISP could revolutionize mobility. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From randy at psg.com Sun Jul 10 17:29:26 2011 From: randy at psg.com (Randy Bush) Date: Mon, 11 Jul 2011 07:29:26 +0900 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <4E19E448.9070807@tiggee.com> Message-ID: > The IETF is run by volunteers. They volunteer because they find > designing protocols to be fun. For the most part, operators are not > entertained by designing network protocols. So, for the most part they > don't partiticpate. Randy Bush, "Editorial zone: Into the Future with the Internet Vendor Task Force: a very curmudgeonly view, or testing spaghetti," ACM SIGCOMM Computer Communication Review Volume 35 Issue 5, October 2005. http://archive.psg.com/051000.ccr-ivtf.html From mksmith at adhost.com Sun Jul 10 17:38:29 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Sun, 10 Jul 2011 22:38:29 +0000 Subject: NANOG List Cutover Schedule Message-ID: Hello All: We are going to cut the mailing list over to the new location at 4:00 PM PDT (GMT -7). We will be testing the cutover on this list to make sure everything goes smoothly. Please filter on the subject "NANOG TEST". Regards, Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) From kristian.hermansen at gmail.com Sun Jul 10 18:25:53 2011 From: kristian.hermansen at gmail.com (Kristian Erik Hermansen) Date: Sun, 10 Jul 2011 16:25:53 -0700 Subject: [NANOG] NANOG TEST In-Reply-To: References: Message-ID: No. On Jul 10, 2011 7:06 PM, "Michael K. Smith - Adhost" wrote: > Please ignore > > -- > Michael K. Smith - CISSP, GSEC, GISP > Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com > w: +1 (206) 404-9500 f: +1 (206) 404-9050 > PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) > > From mksmith at adhost.com Sun Jul 10 18:34:30 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Sun, 10 Jul 2011 23:34:30 +0000 Subject: UPDATE: NANOG List Cutover Schedule Message-ID: Hello: We have moved the NANOG list back to its original location for the time being. We have a few issues to address before we can cut the system over permanently. I will let everyone know again when we are ready to proceed. Thanks, Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) > -----Original Message----- > From: Michael K. Smith - Adhost [mailto:mksmith at adhost.com] > Sent: Sunday, July 10, 2011 3:38 PM > To: NANOG list (nanog at nanog.org) > Subject: NANOG List Cutover Schedule > > Hello All: > > We are going to cut the mailing list over to the new location at 4:00 PM PDT > (GMT -7). We will be testing the cutover on this list to make sure everything > goes smoothly. Please filter on the subject "NANOG TEST". > > Regards, > > Mike > > -- > Michael K. Smith - CISSP, GSEC, GISP > Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com > w: +1 (206) 404-9500 f: +1 (206) 404-9050 > PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) > > From caldcv at gmail.com Sun Jul 10 19:12:42 2011 From: caldcv at gmail.com (Chris) Date: Sun, 10 Jul 2011 20:12:42 -0400 Subject: CNN security contact? In-Reply-To: <06837A1D-D92D-447A-9CD2-40986F19AD5B@mindbend.org> References: <06837A1D-D92D-447A-9CD2-40986F19AD5B@mindbend.org> Message-ID: CNN patched the redirect vulnerability which was making it easier to social engineer Nancy Grace tards who followed the case From joseph.sniderman at thoroquel.org Sun Jul 10 21:09:31 2011 From: joseph.sniderman at thoroquel.org (Joe Sniderman) Date: Sun, 10 Jul 2011 22:09:31 -0400 Subject: [NANOG] NANOG TEST In-Reply-To: <5D7A02C5-2073-4503-9CF9-D015196DF195@twincreeks.net> References: <5D7A02C5-2073-4503-9CF9-D015196DF195@twincreeks.net> Message-ID: <4E1A5B5B.5070407@thoroquel.org> On 07/10/2011 10:03 PM, Steve Feldman wrote: > Another test, sorry for the noise. > Steve Well, at least the fears that nanog would be IPv4 only are unfounded.. Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1890:1112:1::14])... -- Joe Sniderman From swmike at swm.pp.se Mon Jul 11 01:49:15 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 11 Jul 2011 08:49:15 +0200 (CEST) Subject: IMPORTANT ADMINISTRIVIA - NANOG list and website changes over the next week In-Reply-To: <4E173D16.5030708@rollernet.us> References: <4E173D16.5030708@rollernet.us> Message-ID: On Fri, 8 Jul 2011, Seth Mattinen wrote: >> - At this stage, mail.amsl.com will be the only MX for NANOG list services. > > No more IPv6? I don't see an AAAA record for it... There seems to be one now: mail.amsl.com. 1800 IN AAAA 2001:1890:1112:1::14 -- Mikael Abrahamsson email: swmike at swm.pp.se From bill at herrin.us Mon Jul 11 01:57:37 2011 From: bill at herrin.us (William Herrin) Date: Mon, 11 Jul 2011 02:57:37 -0400 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <4E19E448.9070807@tiggee.com> Message-ID: On Sun, Jul 10, 2011 at 4:22 PM, Owen DeLong wrote: > On Jul 10, 2011, at 12:23 PM, William Herrin wrote: >> Consider, for example, RFC 3484. That's the one that determines how an >> IPv6 capable host selects which of a group of candidate IPv4 and IPv6 >> addresses for a particular host name gets priority. How is a server's >> address priority NOT an issue that should be managed at an operations >> level by individual server administrators? Yet the working group which >> produced it came up with a static prioritization that is the root >> cause of a significant portion of the IPv6 deployment headaches we >> face. >> > 3484 specifies a static default. By definition, defaults in absence of > operator configuration kind of have to be static. Having a reasonable > and expected set of defaults documented in an RFC provides a known > quantity for what operators can/should expect from hosts they have > not configured. I see nothing wrong with RFC 3484 other than I would > agree that the choices made were suboptimal. Mostly that was based > on optimism and a lack of experience available at the time of writing. Hi Owen, A more optimal answer would have been to make AAAA records more like MX or SRV records -- with explicit priorities the clients are encouraged to follow. I wasn't there but I'd be willing to bet there was a lonely voice in the room saying, hey, this should be controlled by the sysadmin. A lonely voice that got shouted down. >> Today's RFC candidates are required to call out IANA considerations >> and security considerations in special sections. They do so because >> each of these areas has landmines that the majority of working groups >> are ill equipped to consider on their own. >> >> There should be an operations callout as well -- a section where >> proposed operations defaults (as well as statics for which a solid >> case can be made for an operations tunable) are extracted from the >> thick of it and offered for operator scrutiny prior to publication of >> the RFC. > > I think this would be a good idea, actually. It would probably be more > effective to propose it to IETF than to NANOG, however. If the complaint is that the IETF doesn't adequately listen to the operations folk, then I think it makes sense to consult the operations folks early and often on potential fixes. If folks here think it would help, -that- is when I'll it to the IETF. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From joelja at bogus.com Mon Jul 11 02:08:00 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 11 Jul 2011 00:08:00 -0700 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <4E19E448.9070807@tiggee.com> Message-ID: On Jul 10, 2011, at 11:57 PM, William Herrin wrote: > On Sun, Jul 10, 2011 at 4:22 PM, Owen DeLong wrote: >> On Jul 10, 2011, at 12:23 PM, William Herrin wrote: >>> Consider, for example, RFC 3484. That's the one that determines how an >>> IPv6 capable host selects which of a group of candidate IPv4 and IPv6 >>> addresses for a particular host name gets priority. How is a server's >>> address priority NOT an issue that should be managed at an operations >>> level by individual server administrators? Yet the working group which >>> produced it came up with a static prioritization that is the root >>> cause of a significant portion of the IPv6 deployment headaches we >>> face. >>> >> 3484 specifies a static default. By definition, defaults in absence of >> operator configuration kind of have to be static. Having a reasonable >> and expected set of defaults documented in an RFC provides a known >> quantity for what operators can/should expect from hosts they have >> not configured. I see nothing wrong with RFC 3484 other than I would >> agree that the choices made were suboptimal. Mostly that was based >> on optimism and a lack of experience available at the time of writing. > > Hi Owen, > > A more optimal answer would have been to make AAAA records more like > MX or SRV records -- with explicit priorities the clients are > encouraged to follow. I wasn't there but I'd be willing to bet there > was a lonely voice in the room saying, hey, this should be controlled > by the sysadmin. A lonely voice that got shouted down. Give me a break... multiple implementations have chosen to tweak the algorithm independently and at various times. It's just an rfc, not the gospel according to richard draves. " Acknowledgments The author would like to acknowledge the contributions of the IPng Working Group, particularly Marc Blanchet, Brian Carpenter, Matt Crawford, Alain Durand, Steve Deering, Robert Elz, Jun-ichiro itojun Hagino, Tony Hain, M.T. Hollinger, JINMEI Tatuya, Thomas Narten, Erik Nordmark, Ken Powell, Markku Savela, Pekka Savola, Hesham Soliman, Dave Thaler, Mauro Tortonesi, Ole Troan, and Stig Venaas. In addition, the anonymous IESG reviewers had many great comments and suggestions for clarification. " > >>> Today's RFC candidates are required to call out IANA considerations >>> and security considerations in special sections. They do so because >>> each of these areas has landmines that the majority of working groups >>> are ill equipped to consider on their own. >>> >>> There should be an operations callout as well -- a section where >>> proposed operations defaults (as well as statics for which a solid >>> case can be made for an operations tunable) are extracted from the >>> thick of it and offered for operator scrutiny prior to publication of >>> the RFC. >> >> I think this would be a good idea, actually. It would probably be more >> effective to propose it to IETF than to NANOG, however. > > If the complaint is that the IETF doesn't adequately listen to the > operations folk, then I think it makes sense to consult the operations > folks early and often on potential fixes. If folks here think it would > help, -that- is when I'll it to the IETF. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > From tom at ninjabadger.net Mon Jul 11 02:25:12 2011 From: tom at ninjabadger.net (Tom Hill) Date: Mon, 11 Jul 2011 08:25:12 +0100 Subject: Why is IPv6 broken? In-Reply-To: References: Message-ID: <1310369118.2048.1.camel@teh-desktop> On Sun, 2011-07-10 at 10:14 -0400, Jeff Wheeler wrote: > Cogent's policy of requiring a new contract, and from what I am still > being told by some European customers, new money, from customers in > exchange for provisioning IPv6 on existing circuits, means a simple > technical project gets caught up in the complexities of budgeting and > contract execution. "Can we have IPv6 transit?" "Yes, please turn up a session to.." That was asking Cogent for IPv6 dual-stack on our existing IPv4 transit. I'm not saying it's any good, but it certainly didn't cost extra. Tom From nick at foobar.org Mon Jul 11 03:14:50 2011 From: nick at foobar.org (Nick Hilliard) Date: Mon, 11 Jul 2011 09:14:50 +0100 Subject: Why is IPv6 broken? In-Reply-To: <1310369118.2048.1.camel@teh-desktop> References: <1310369118.2048.1.camel@teh-desktop> Message-ID: <4E1AB0FA.7040207@foobar.org> On 11/07/2011 08:25, Tom Hill wrote: > I'm not saying it's any good, but it certainly didn't cost extra. Several people mentioned this to Jeff on IRC a short time ago, so it's not clear why he chose to suggest that ipv6 users in Europe were being fleeced by Cogent for a set-up fee. Perhaps it has happened, but it appears not to be their policy. Of course, if you actually want a full ipv6 table, you will need to go elsewhere. Nick From jsw at inconcepts.biz Mon Jul 11 03:50:16 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Mon, 11 Jul 2011 04:50:16 -0400 Subject: Why is IPv6 broken? In-Reply-To: <1310369118.2048.1.camel@teh-desktop> References: <1310369118.2048.1.camel@teh-desktop> Message-ID: On Mon, Jul 11, 2011 at 3:25 AM, Tom Hill wrote: > On Sun, 2011-07-10 at 10:14 -0400, Jeff Wheeler wrote: >> Cogent's policy of requiring a new contract, and from what I am still >> being told by some European customers, new money, from customers in >> exchange for provisioning IPv6 on existing circuits, means a simple >> technical project gets caught up in the complexities of budgeting and >> contract execution. > > "Can we have IPv6 transit?" > "Yes, please turn up a session to.." > > That was asking Cogent for IPv6 dual-stack on our existing IPv4 > transit. I continue to hear different. In my first-hand experience just about three weeks ago, I was told by Cogent that I need to execute a new contract to get IPv6 added to an existing IPv4 circuit (U.S. customer.) This turned a simple pilot project with only a few I.T. folks involved into, well, I'm still waiting on this new contract to be executed. I'm not surprised. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From swmike at swm.pp.se Mon Jul 11 03:55:42 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 11 Jul 2011 10:55:42 +0200 (CEST) Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <4E19E448.9070807@tiggee.com> Message-ID: On Mon, 11 Jul 2011, William Herrin wrote: > If the complaint is that the IETF doesn't adequately listen to the > operations folk, then I think it makes sense to consult the operations > folks early and often on potential fixes. If folks here think it would > help, -that- is when I'll it to the IETF. I started participating in the IETF 1-2 years ago. Coming from Fidonet background, the threshold of entry felt very low, as long as you make any kind of sense, people will discuss with you there and it doesn't matter who you are. You don't even have to go to the meetings (I've only been to a single one). I encourage everybody to participate, at least to subscribe to the WG mailing lists and keep a look out for the draft announcements and give feedback to those. If we in the ISP business don't do this, the show will be run by the vendors and academics (as is the case right now). They're saying "come to us", you're saying "come to us", and as long as both do this the rate of communication is going to be limited. What is needed is more people with operational backgrounds. For instance, I pitched the idea that ended up as a draft, dunno what will come of it: This has purely operational background and the puritans didn't like it (they didn't even understand why one would want to do it like that), but after a while I feel I received some traction and it might actually end up as a protocol enhancement that will help some ISPs in their daily work. Even something like your IGP isn't "done", and can be enhanced even if it takes time. -- Mikael Abrahamsson email: swmike at swm.pp.se From tom at ninjabadger.net Mon Jul 11 04:20:04 2011 From: tom at ninjabadger.net (Tom Hill) Date: Mon, 11 Jul 2011 10:20:04 +0100 Subject: Why is IPv6 broken? In-Reply-To: References: <1310369118.2048.1.camel@teh-desktop> Message-ID: <1310376006.2048.10.camel@teh-desktop> On Mon, 2011-07-11 at 04:50 -0400, Jeff Wheeler wrote: > > "Can we have IPv6 transit?" > > "Yes, please turn up a session to.." > > > > That was asking Cogent for IPv6 dual-stack on our existing IPv4 > > transit. > > I continue to hear different. In my first-hand experience just about > three weeks ago, I was told by Cogent that I need to execute a new > contract to get IPv6 added to an existing IPv4 circuit (U.S. > customer.) This turned a simple pilot project with only a few I.T. > folks involved into, well, I'm still waiting on this new contract to > be executed. I'm not surprised. In fairness, we have a small commit. If you're talking multi-gigabit+, then perhaps they could be a little more concerned about the amount of IPv6 traffic that you might start pushing, leading to delay tactics and/or a required contract change to protect themselves. (Not that it's likely much to be concerned about. But then, I don't know who your customer is. ;)) Or the more likely reality that one hand doesn't talk to the other and everyone's getting varying answers/actions from Cogent, depending on whom they speak with. Tom From owen at delong.com Mon Jul 11 07:49:05 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Jul 2011 08:49:05 -0400 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <4E19E448.9070807@tiggee.com> Message-ID: Sent from my iPad On Jul 11, 2011, at 2:57, William Herrin wrote: > On Sun, Jul 10, 2011 at 4:22 PM, Owen DeLong wrote: >> On Jul 10, 2011, at 12:23 PM, William Herrin wrote: >>> Consider, for example, RFC 3484. That's the one that determines how an >>> IPv6 capable host selects which of a group of candidate IPv4 and IPv6 >>> addresses for a particular host name gets priority. How is a server's >>> address priority NOT an issue that should be managed at an operations >>> level by individual server administrators? Yet the working group which >>> produced it came up with a static prioritization that is the root >>> cause of a significant portion of the IPv6 deployment headaches we >>> face. >>> >> 3484 specifies a static default. By definition, defaults in absence of >> operator configuration kind of have to be static. Having a reasonable >> and expected set of defaults documented in an RFC provides a known >> quantity for what operators can/should expect from hosts they have >> not configured. I see nothing wrong with RFC 3484 other than I would >> agree that the choices made were suboptimal. Mostly that was based >> on optimism and a lack of experience available at the time of writing. > > Hi Owen, > > A more optimal answer would have been to make AAAA records more like > MX or SRV records -- with explicit priorities the clients are > encouraged to follow. I wasn't there but I'd be willing to bet there > was a lonely voice in the room saying, hey, this should be controlled > by the sysadmin. A lonely voice that got shouted down. > Uh, right, because the average system administrator wants the remote host telling his systems which address to prefer? Besides, that would have been DESTINATION address selection, not source address selection which isn't what we're talking about. I wasn't there either, but, it _IS_ controlled by the sysadmin. There are defaults in case the sysadmin is asleep at the switch (RFC 3484) and there are handles and knobs for the sysadmin to tune if he wants (the other RFC that I referred you to). > >>> Today's RFC candidates are required to call out IANA considerations >>> and security considerations in special sections. They do so because >>> each of these areas has landmines that the majority of working groups >>> are ill equipped to consider on their own. >>> >>> There should be an operations callout as well -- a section where >>> proposed operations defaults (as well as statics for which a solid >>> case can be made for an operations tunable) are extracted from the >>> thick of it and offered for operator scrutiny prior to publication of >>> the RFC. >> >> I think this would be a good idea, actually. It would probably be more >> effective to propose it to IETF than to NANOG, however. > > If the complaint is that the IETF doesn't adequately listen to the > operations folk, then I think it makes sense to consult the operations > folks early and often on potential fixes. If folks here think it would > help, -that- is when I'll it to the IETF. > I think it would help. Hopefully others will express similar sentiment. Owen From bill at herrin.us Mon Jul 11 10:13:07 2011 From: bill at herrin.us (William Herrin) Date: Mon, 11 Jul 2011 11:13:07 -0400 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <4E19E448.9070807@tiggee.com> Message-ID: On Mon, Jul 11, 2011 at 3:08 AM, Joel Jaeggli wrote: > On Jul 10, 2011, at 11:57 PM, William Herrin wrote: >> A more optimal answer would have been to make AAAA records more like >> MX or SRV records -- with explicit priorities the clients are >> encouraged to follow. I wasn't there but I'd be willing to bet there >> was a lonely voice in the room saying, hey, this should be controlled >> by the sysadmin. A lonely voice that got shouted down. > > Give me a break... multiple implementations have chosen to tweak the algorithm independently and at various times. > > It's just an rfc, not the gospel according to richard draves. > > " > ? Acknowledgments > > ? The author would like to acknowledge the contributions of the IPng > ? Working Group, particularly Marc Blanchet, Brian Carpenter, Matt > ? Crawford, Alain Durand, Steve Deering, Robert Elz, Jun-ichiro itojun > ? Hagino, Tony Hain, M.T. Hollinger, JINMEI Tatuya, Thomas Narten, Erik > ? Nordmark, Ken Powell, Markku Savela, Pekka Savola, Hesham Soliman, > ? Dave Thaler, Mauro Tortonesi, Ole Troan, and Stig Venaas. ?In > ? addition, the anonymous IESG reviewers had many great comments and > ? suggestions for clarification. > " Joel, I am giving you a break. Instead of calling this list of folks to the carpet over a failure of imagination that by the time we've ubiquitously deployed IPv6 will have been the root cause of billions if not tens of billions of dollars in needless industry expense, I'm trying to move the discussion past the errors and focus on ways to help the next team of smart, selfless and dedicated individuals avoid sullying their results with a similar mistake. Denial keeps the discussion focused on the errors. You don't want that and neither do I. >>>> Today's RFC candidates are required to call out IANA considerations >>>> and security considerations in special sections. They do so because >>>> each of these areas has landmines that the majority of working groups >>>> are ill equipped to consider on their own. >>>> >>>> There should be an operations callout as well -- a section where >>>> proposed operations defaults (as well as statics for which a solid >>>> case can be made for an operations tunable) are extracted from the >>>> thick of it and offered for operator scrutiny prior to publication of >>>> the RFC. Do you find this adjustment objectionable? Do you have other fresh ideas to float? Something better than the tired refrain about operators not showing up? 'Cause I have to tell you: Several years ago I picked a working group and I showed up. And I faced and lost the argument against the persistent certainty on the workability of ridiculous deployment scenarios by folks who never managed any system larger than a software development lab. And I stopped participating in the group about a year ago as the core of participants who hadn't given up wandered off into la la land. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From joelja at bogus.com Mon Jul 11 10:20:04 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 11 Jul 2011 08:20:04 -0700 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <4E19E448.9070807@tiggee.com> Message-ID: On Jul 11, 2011, at 8:13 AM, William Herrin wrote: > > >>>>> Today's RFC candidates are required to call out IANA considerations >>>>> and security considerations in special sections. They do so because >>>>> each of these areas has landmines that the majority of working groups >>>>> are ill equipped to consider on their own. >>>>> >>>>> There should be an operations callout as well -- a section where >>>>> proposed operations defaults (as well as statics for which a solid >>>>> case can be made for an operations tunable) are extracted from the >>>>> thick of it and offered for operator scrutiny prior to publication of >>>>> the RFC. > > Do you find this adjustment objectionable? Do you have other fresh > ideas to float? Something better than the tired refrain about > operators not showing up? The operations area has a directorate. It reviews basically every draft in front of the IESG. I'm on it. Am I not an operator? Do I think that adding yet another required section to an internet draft is going to increase it's quality? No I do not. > 'Cause I have to tell you: Several years ago I picked a working group > and I showed up. And I faced and lost the argument against the > persistent certainty on the workability of ridiculous deployment > scenarios by folks who never managed any system larger than a software > development lab. And I stopped participating in the group about a year > ago as the core of participants who hadn't given up wandered off into > la la land. > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > From caldcv at gmail.com Mon Jul 11 10:23:00 2011 From: caldcv at gmail.com (Chris) Date: Mon, 11 Jul 2011 11:23:00 -0400 Subject: AOL security contact? Message-ID: Anyone have an AOL security contact because like I posted yesterday, CNN was hit through a redirect vulnerability in their ad system and now AOL is suffering the same thing by having some scammer serving up "Casey Anthony leaked lawyer video" crap as Facebook spam where unsuspecting lusers are clicking like wild on it -- --C "The dumber people think you are, the more surprised they're going to be when you kill them." - Sir William Clayton From jra at baylink.com Mon Jul 11 11:13:56 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 11 Jul 2011 12:13:56 -0400 (EDT) Subject: AOL security contact? In-Reply-To: Message-ID: <23329369.1165.1310400836536.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Chris" > Anyone have an AOL security contact because like I posted yesterday, > CNN was hit through a redirect vulnerability in their ad system and > now AOL is suffering the same thing by having some scammer serving up > "Casey Anthony leaked lawyer video" crap as Facebook spam where > unsuspecting lusers are clicking like wild on it My recommendation to anyone from Facebook who's listening here: Block the whole damn domain. That will get them to contact you. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From caldcv at gmail.com Mon Jul 11 11:42:07 2011 From: caldcv at gmail.com (Chris) Date: Mon, 11 Jul 2011 12:42:07 -0400 Subject: AOL security contact? In-Reply-To: <23329369.1165.1310400836536.JavaMail.root@benjamin.baylink.com> References: <23329369.1165.1310400836536.JavaMail.root@benjamin.baylink.com> Message-ID: I tried domains at aol.net, which I got when I did a whois on the IP of the affected domain, then hit noc@ and abuse at aol.com I fired off an email to iWeb, who is hosting the scam site and is notorious for lack of response, and GoDaddy. My recommendation to anyone: start blocking .info like how Google delisted co.cc On Mon, Jul 11, 2011 at 12:13 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Chris" > >> Anyone have an AOL security contact because like I posted yesterday, >> CNN was hit through a redirect vulnerability in their ad system and >> now AOL is suffering the same thing by having some scammer serving up >> "Casey Anthony leaked lawyer video" crap as Facebook spam where >> unsuspecting lusers are clicking like wild on it > > My recommendation to anyone from Facebook who's listening here: > > Block the whole damn domain. ?That will get them to contact you. ?:-) > > Cheers, > -- jra > -- > Jay R. Ashworth ? ? ? ? ? ? ? ? ?Baylink ? ? ? ? ? ? ? ? ? ? ? jra at baylink.com > Designer ? ? ? ? ? ? ? ? ? ? The Things I Think ? ? ? ? ? ? ? ? ? ? ? RFC 2100 > Ashworth & Associates ? ? http://baylink.pitas.com ? ? ? ? 2000 Land Rover DII > St Petersburg FL USA ? ? ?http://photo.imageinc.us ? ? ? ? ? ? +1 727 647 1274 > > -- --C "The dumber people think you are, the more surprised they're going to be when you kill them." - Sir William Clayton From jay+NANOG at tp.org Mon Jul 11 12:13:23 2011 From: jay+NANOG at tp.org (Jay Moran) Date: Mon, 11 Jul 2011 13:13:23 -0400 Subject: AOL security contact? In-Reply-To: References: <23329369.1165.1310400836536.JavaMail.root@benjamin.baylink.com> Message-ID: Chris, Did you not get my direct email to you? I included the email address there, here it is again for yourself and others who need to report a security vulnerability with an AOL property. secvuln at aol dot net Jay -- Jay Moran http://tp.org/jay On Mon, Jul 11, 2011 at 12:42 PM, Chris wrote: > I tried domains at aol.net, which I got when I did a whois on the IP of > the affected domain, then hit noc@ and abuse at aol.com > > I fired off an email to iWeb, who is hosting the scam site and is > notorious for lack of response, and GoDaddy. > > My recommendation to anyone: start blocking .info like how Google delisted > co.cc > > On Mon, Jul 11, 2011 at 12:13 PM, Jay Ashworth wrote: > > ----- Original Message ----- > >> From: "Chris" > > > >> Anyone have an AOL security contact because like I posted yesterday, > >> CNN was hit through a redirect vulnerability in their ad system and > >> now AOL is suffering the same thing by having some scammer serving up > >> "Casey Anthony leaked lawyer video" crap as Facebook spam where > >> unsuspecting lusers are clicking like wild on it > > > > My recommendation to anyone from Facebook who's listening here: > > > > Block the whole damn domain. That will get them to contact you. :-) > > > > Cheers, > > -- jra > > -- > > Jay R. Ashworth Baylink > jra at baylink.com > > Designer The Things I Think RFC > 2100 > > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > > St Petersburg FL USA http://photo.imageinc.us +1 727 > 647 1274 > > > > > > > > -- > --C > > "The dumber people think you are, the more surprised they're going to > be when you kill them." - Sir William Clayton > > From bill at herrin.us Mon Jul 11 12:14:48 2011 From: bill at herrin.us (William Herrin) Date: Mon, 11 Jul 2011 13:14:48 -0400 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <4E19E448.9070807@tiggee.com> Message-ID: On Mon, Jul 11, 2011 at 11:20 AM, Joel Jaeggli wrote: > On Jul 11, 2011, at 8:13 AM, William Herrin wrote: >>>>>> Today's RFC candidates are required to call out IANA considerations >>>>>> and security considerations in special sections. They do so because >>>>>> each of these areas has landmines that the majority of working groups >>>>>> are ill equipped to consider on their own. >>>>>> >>>>>> There should be an operations callout as well -- a section where >>>>>> proposed operations defaults (as well as statics for which a solid >>>>>> case can be made for an operations tunable) are extracted from the >>>>>> thick of it and offered for operator scrutiny prior to publication of >>>>>> the RFC. >> >> Do you find this adjustment objectionable? Do you have other fresh >> ideas to float? Something better than the tired refrain about >> operators not showing up? > > The operations area has a directorate. It reviews basically every draft in front of the IESG. > I'm on it. > Am I not an operator? Well, you work at Zynga, a company which makes facebook games. Before that you worked at Nokia, company which makes phones but doesn't run phone networks. Before that it was Check Point Software, a company which makes firewalls but doesn't run networks. And before that it was the University of Oregon. Do you believe any of those roles offered you the perspective you'd gain working for an ISP, telco or MSO? Are you not an operator? Sure, why not. It's a big tent. Are you well qualified to represent operator interests before the IETF? You really haven't been speaking to the issues I had to deal with when I led an ISP and you've expressed little respect for the validity of issues I face now. But you do show up. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From darlewis at cisco.com Mon Jul 11 13:05:57 2011 From: darlewis at cisco.com (Darrel Lewis) Date: Mon, 11 Jul 2011 11:05:57 -0700 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <5F4FCDA1-EE05-4CBD-9E3B-91EEE5083D8A@delong.com> Message-ID: <8A91154D-8172-4B5A-B14D-9652D596D523@cisco.com> > \ > I have found my input on the LISP list completely ignored because, as > you suggest, my concerns are real-world and don't have any impact on > someone's pet project. LISP as it stands today can never work on the > Internet, and regardless of the fine reputations of the people at > Cisco and other organizations who are working on it, they are either > furthering it only because they would rather work on a pet project > than something useful to customers, or because they truly cannot > understand its deep, insurmountable design flaws at Internet-scale. > You would generally hope that someone saying, "LISP can't work at > Internet-scale because anyone will be able to trivially DoS any LISP > ITR ('router' for simplicity), but here is a way you can improve it," > well, that remark, input, and person should be taken quite seriously, > their input examined, and other assumptions about the way LISP is > supposed to work ought to be questioned. None of this has happened. Jeff I've spend many hours working through the issues you brought up (indeed cache management, population, and security are three of my focus areas in LISP, and something we considered when we started this), have been socializing them with the LISP team, and can personally say that I take your comments very seriously. Or testing group in house as well as on the LISP beta network have been working through these issues. Also, we've had an email thread going on about this for, by my count, 3-4 replies back and forth. While I appreciate your opinions above, I have to say that I disagree with them, and also with the conclusions you draw. -Darrel P.S. oh and Randy Bush is pretty damn smart. :-) From william.allen.simpson at gmail.com Mon Jul 11 13:36:10 2011 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Mon, 11 Jul 2011 14:36:10 -0400 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <4E19E448.9070807@tiggee.com> Message-ID: <4E1B429A.3080508@gmail.com> On 7/10/11 6:29 PM, Randy Bush wrote: >> The IETF is run by volunteers. They volunteer because they find >> designing protocols to be fun. For the most part, operators are not >> entertained by designing network protocols. So, for the most part they >> don't partiticpate. > > Randy Bush, "Editorial zone: Into the Future with the Internet Vendor > Task Force: a very curmudgeonly view, or testing spaghetti," ACM SIGCOMM > Computer Communication Review Volume 35 Issue 5, October 2005. > http://archive.psg.com/051000.ccr-ivtf.html > I agree with Randy. Well, that's no surprise, I usually agree with Randy. But I didn't know/remember that he'd managed to get his rant published! Good work.... But the problem has been pretty apparent since circa 1991. I remember calls for an Internet Operator's Task Force (IOTF) to parallel IETF sometime in '92 or '93. Folks have asked me from time to time why I stopped participating in the IETF a decade or so ago. My usual tongue-in-cheek reply is, "it's more important to use the protocols we already have before we build more." (CF. nukes.) IPv6 was certainly a part of it (as was security). As I remind folks from time to time, I'm the guy that originally registered v6 with IANA. But PIPE->SIP->SIPP was a much simpler, shorter, cleaner extension using 64-bit addresses. My proposal used the upper 32-bits extending the then 16-bit BGP ASN, making addresses match topology, shrinking the routing tables.... Although I *do* find designing protocols to be fun, these days I only post Experimental drafts. There are committees (dysfunctional "working groups") where the chair cannot get his own drafts through the process in under 4 years. It took about 7 years to publish the group negotiation extension to SSH, many years after it was shipping. It's no wonder that operators don't want to participate. From bill at herrin.us Mon Jul 11 14:18:19 2011 From: bill at herrin.us (William Herrin) Date: Mon, 11 Jul 2011 15:18:19 -0400 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <4E19E448.9070807@tiggee.com> Message-ID: On Mon, Jul 11, 2011 at 11:20 AM, Joel Jaeggli wrote: > On Jul 11, 2011, at 8:13 AM, William Herrin wrote: >>>>>> Today's RFC candidates are required to call out IANA considerations >>>>>> and security considerations in special sections. They do so because >>>>>> each of these areas has landmines that the majority of working groups >>>>>> are ill equipped to consider on their own. >>>>>> >>>>>> There should be an operations callout as well -- a section where >>>>>> proposed operations defaults (as well as statics for which a solid >>>>>> case can be made for an operations tunable) are extracted from the >>>>>> thick of it and offered for operator scrutiny prior to publication of >>>>>> the RFC. >> >> Do you find this adjustment objectionable? > > Do I think that adding yet another required section to an > internet draft is going to increase it's quality? > No I do not. Joel, You may be right. Calling out IANA considerations doesn't seem to have made the IETF any smarter on the shared ISP IPv4 space. And I have no idea if calling out security implications has helped reduce security-related design flaws. On the other hand, calling out ops issues in RFCs is a modest reform that at worst shouldn't hurt anything. That beats my next best idea: asking the ops area to schedule its meetings with the various NOG meetings instead of with the rest of the IETF so that the attendance is ops who dabble in development instead of developers who dabble in ops. You disagree? What are your thoughts on fixing the problem? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at kruchas.com Mon Jul 11 14:33:44 2011 From: bill at kruchas.com (bill at kruchas.com) Date: Mon, 11 Jul 2011 12:33:44 -0700 Subject: Hello List, a easy Cisco question. Message-ID: <20110711123344.5f1e402cf2b8f2f1e57b153880067f5a.1afdd94b61.wbe@email10.secureserver.net> Hello, I am not a heads down network guy, but I have setup a few firewalls, and have got them to do what I wanted, "eventually". But mostly through reading and trial and error. I am struggling with this one, but I think I know the answer, but want to verify it with some experts. We have a cisco asa 5505, with an internet connection with only one useable ip address (subnet 255.255.255.252). We/they have had a nat setup for outgoing connections for some time, but I have been trying to get a new inbound connection going for terminal services to a specific host on tcp port 3389. I'm using "ASDM" but checking the config file and it's building the correct static statement, and access lists (I think anyway). But It doesn't work, and doesn't give a real good definative log message. I was wondering if possibly the fact that nat is using the one ip address, if that precludes the static mapping from working. I've read several step by steps, and again had this working several other places, but always with more ip's. If having just one ip isn't the isssue, is there any other issues I should be looking for. I'd appreciate any insight you might share. Thanks in advance From bicknell at ufp.org Mon Jul 11 14:35:08 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 11 Jul 2011 12:35:08 -0700 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: <4E19D049.8010006@unfix.org> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> Message-ID: <20110711193508.GA97493@ussenterprise.ufp.org> In a message written on Sun, Jul 10, 2011 at 06:16:09PM +0200, Jeroen Massar wrote: > Ehmmmm ANYBODY, including you, can sign up to the IETF mailing lists and > participate there, just like a couple of folks from NANOG are already doing. The way the IETF and the operator community interact is badly broken. The IETF does not want operators in many steps of the process. If you try to bring up operational concerns in early protocol development for example you'll often get a "we'll look at that later" response, which in many cases is right. Sometimes you just have to play with something before you worry about the operational details. It also does not help that many operational types are not hardcore programmers, and can't play in the sandbox during the major development cycles. But this shuts out operators and discourages them from participating when they are needed, which is at the idea phase and towards the end of development. If the IETF really wanted to get useful operator impact, they would slightly modify their process. On the front end there would be a more clear way for operational types to add to the To-Do list "stuff we really need to make the Internet work better". Then, some sausage would be made largely without operator involvement (but hey, if you want to participate no exclusions), and then when developmen is about 80-90% done there would be an "operational testing and comment period". Operators would be actively brought back in the process to test some small scale deployments and provide feedback of operational concerns that might lead to some tweaks, and then boom, out the door it goes. I suspect this would both increase operator participation by a few orders of magnitude, and also keep the operators from annoying the developers so much when they are in "trying things out" mode. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From jsw at inconcepts.biz Mon Jul 11 14:41:49 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Mon, 11 Jul 2011 15:41:49 -0400 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <4E19E448.9070807@tiggee.com> Message-ID: On Mon, Jul 11, 2011 at 3:18 PM, William Herrin wrote: > On the other hand, calling out ops issues in RFCs is a modest reform > that at worst shouldn't hurt anything. That beats my next best idea: I think if this were done, some guy like me would spend endless hours arguing with others about what should and should not be documented in this proposed section, without it actually benefiting the process or the improving the underlying protocol function / specification. Let me give you an example: BGP Messages, which are up to 4KB, need to be expanded to support future features like as-path signing. Randy Bush proposes to extend them to 65,535 octets, the maximum size without significantly changing the message header. This raises a few concerns which I label as operational, for example, off-by-one bugs in code can fail to be detected by a neighboring BGP speaker in some circumstances, because an age-old (since BGP 1) idiot check in the protocol is being silently removed. If you ask me, that is operational and belongs in such a section. I'm sure others will disagree. So we would have a bunch of arguing over whether or not to call this out specifically. Another person believes that expanding the message will affect some vendors' custom TCP stacks, due to window size considerations. I might think that is a developer problem and the affected vendors should fix their crappy TCP implementations, but it might produce unusual stalling problems, etc. which operators have to troubleshoot. Is that an operational issue? Should it be documented? There can be many "operational concerns" when creating or modifying a protocol specification, and every person won't agree on what belongs and what doesn't. However, I do not think the requirement to document them will improve the process or the protocols. It will only add work. Besides, you want "IETF people" who are claimed not to understand operational problems to figure them out and document them in the RFCs? I do not think this will be helpful. More hands-on operators participating in their process is what is needed. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From jsw at inconcepts.biz Mon Jul 11 14:57:30 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Mon, 11 Jul 2011 15:57:30 -0400 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: <20110711193508.GA97493@ussenterprise.ufp.org> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> Message-ID: On Mon, Jul 11, 2011 at 3:35 PM, Leo Bicknell wrote: > The IETF does not want operators in many steps of the process. ?If > you try to bring up operational concerns in early protocol development > for example you'll often get a "we'll look at that later" response, > which in many cases is right. ?Sometimes you just have to play with > something before you worry about the operational details. ?It also I really don't understand why that is right / good. People get personally invested in their project / spec, and not only that, vendor people get their company's time and money invested in proof-of-concept. The longer something goes on with what may be serious design flaws, the harder it is to get them fixed, simply because of momentum. Wouldn't it be nice if we could change the way that next-header works in IPv6 now? Or get rid of SLAAC and erase the RFCs recommending /80 and /64 from history? -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From bill at kruchas.com Mon Jul 11 15:16:00 2011 From: bill at kruchas.com (bill at kruchas.com) Date: Mon, 11 Jul 2011 13:16:00 -0700 Subject: Hello List, a easy Cisco question. Message-ID: <20110711131600.5f1e402cf2b8f2f1e57b153880067f5a.03fdbfbd6b.wbe@email10.secureserver.net> Hello, We have Nat setup on our equipment, just a plain vanilla internet connection. Here is the pertinent section of the runing config. ! interface Ethernet0/2 nameif Etherpoint security-level 0 ip address outside-ip 255.255.255.252 ospf cost 10 ! object-group service terminal-services tcp port-object eq 3389 access-list Inside_access_in extended permit icmp any any access-list Inside_access_in extended permit ip 192.168.125.0 255.255.255.0 any access-list Inside_nat0_outbound extended permit ip 192.168.125.0 255.255.255.0 MobileVPN 255.255.255.0 access-list Inside_nat0_outbound extended permit ip 192.168.0.0 255.255.255.0 MobileVPN 255.255.255.0 inactive access-list Inside_nat0_outbound extended permit ip 192.168.125.0 255.255.255.0 any inactive access-list Inside_nat0_outbound extended permit ip 192.168.125.0 255.255.255.0 192.168.1.0 255.255.255.0 access-list Inside_nat0_outbound extended permit ip 192.168.125.0 255.255.255.0 192.168.14.0 255.255.255.0 access-list Inside_nat0_outbound extended permit ip 192.168.125.0 255.255.255.0 192.168.100.0 255.255.255.0 access-list Inside_nat0_outbound extended permit ip 192.168.125.0 255.255.255.0 192.168.101.0 255.255.255.0 access-list Inside_nat0_outbound extended permit ip 192.168.125.0 255.255.255.0 192.168.253.0 255.255.255.0 access-list Haven_splitTunnelAcl_1 standard permit 192.168.125.0 255.255.255.0 access-list Etherpoint_access_in extended permit tcp host 192.168.125.8 eq 3389 any eq 3389 access-list Etherpoint_access_in extended permit tcp any eq 3389 host 192.168.125.8 eq 3389 access-list Etherpoint_access_in extended permit tcp any host 192.168.125.8 eq 3389 access-list Etherpoint_nat0_outbound extended permit ip host 192.168.125.8 host outside-ip access-list Etherpoint_nat0_outbound extended permit ip host outside-ip host 192.168.125.8 ip local pool HavenVPN 192.168.253.1-192.168.253.254 mask 255.255.255.0 global (Etherpoint) 2 interface nat (Inside) 0 access-list Inside_nat0_outbound nat (Inside) 2 192.168.125.0 255.255.255.0 nat (Etherpoint) 0 access-list Etherpoint_nat0_outbound outside static (Inside,Etherpoint) tcp interface 3389 192.168.125.8 3389 netmask 255.255.255.255 no threat-detection statistics tcp-intercept access-group Inside_access_in in interface Inside access-group Etherpoint_access_in in interface Etherpoint route Etherpoint 0.0.0.0 0.0.0.0 204.186.102.187 1 -------- Original Message -------- Subject: Re: Hello List, a easy Cisco question. From: Dennis <[1]daodennis at gmail.com> Date: Mon, July 11, 2011 12:39 pm To: [2]bill at kruchas.com On Mon, Jul 11, 2011 at 12:33 PM, <[3]bill at kruchas.com> wrote: > Hello, > > I am not a heads down network guy, but I have setup a few > firewalls, and have got them to do what I wanted, "eventually". But > mostly through reading and trial and error. > > I am struggling with this one, but I think I know the answer, but > want to verify it with some experts. > > > > We have a cisco asa 5505, with an internet connection with only one > useable ip address (subnet 255.255.255.252). We/they have had a nat > setup for outgoing connections for some time, but I have been trying to So your provider has your ASA behind a NAT or there is a NAT inside,outside statement on your ASA? Some more pieces of the configuration would be helpful here too. Thanks, Dennis O. References 1. mailto:daodennis at gmail.com 2. mailto:bill at kruchas.com 3. mailto:bill at kruchas.com From bill at kruchas.com Mon Jul 11 15:23:02 2011 From: bill at kruchas.com (bill at kruchas.com) Date: Mon, 11 Jul 2011 13:23:02 -0700 Subject: Hello List, a easy Cisco question. Message-ID: <20110711132302.5f1e402cf2b8f2f1e57b153880067f5a.fa8fbaade2.wbe@email10.secureserver.net> Hello, I believe I have setup the appropriate access-lists, even have created it both ways in case I have the inside and outside reversed. The packet trace always drops through and hits the implicit rule which is deny everything. No matter how I have the access list setup. I have tried it several ways, and also included the nat exclude statement, but the current config doesn't have that listed anymore as I wanted to try to keep the config as clean as I can, but if the exclude is needed I can certainly add it. But none on the examples used it. -------- Original Message -------- Subject: Re: Hello List, a easy Cisco question. From: James Laszko <[1]jamesl at mythostech.com> Date: Mon, July 11, 2011 1:02 pm To: "[2]bill at kruchas.com" <[3]bill at kruchas.com> Have you setup the appropriate access rule along with the NAT? The packet trace button is useful in testing as well... Regards, James Laszko Mythos Technology Inc [4]Jamesl at mythostech.com ----- Original Message ----- From: [5]bill at kruchas.com [[6]mailto:bill at kruchas.com] Sent: Monday, July 11, 2011 12:33 PM To: nanog <[7]nanog at nanog.org> Subject: Hello List, a easy Cisco question. Hello, I am not a heads down network guy, but I have setup a few firewalls, and have got them to do what I wanted, "eventually". But mostly through reading and trial and error. I am struggling with this one, but I think I know the answer, but want to verify it with some experts. We have a cisco asa 5505, with an internet connection with only one useable ip address (subnet 255.255.255.252). We/they have had a nat setup for outgoing connections for some time, but I have been trying to get a new inbound connection going for terminal services to a specific host on tcp port 3389. I'm using "ASDM" but checking the config file and it's building the correct static statement, and access lists (I think anyway). But It doesn't work, and doesn't give a real good definative log message. I was wondering if possibly the fact that nat is using the one ip address, if that precludes the static mapping from working. I've read several step by steps, and again had this working several other places, but always with more ip's. If having just one ip isn't the isssue, is there any other issues I should be looking for. I'd appreciate any insight you might share. Thanks in advance References 1. mailto:jamesl at mythostech.com 2. mailto:bill at kruchas.com 3. mailto:bill at kruchas.com 4. mailto:Jamesl at mythostech.com 5. mailto:bill at kruchas.com 6. mailto:bill at kruchas.com 7. mailto:nanog at nanog.org From eric-list at truenet.com Mon Jul 11 15:38:10 2011 From: eric-list at truenet.com (Eric Tykwinski) Date: Mon, 11 Jul 2011 16:38:10 -0400 Subject: Mediacom Communications Corporation contact available? Message-ID: <00b101cc400a$72afdb80$580f9280$@truenet.com> Looking for a NOC contact if there are any available. Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 F: 610-429-3222 From michael.holstein at csuohio.edu Mon Jul 11 15:41:01 2011 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Mon, 11 Jul 2011 16:41:01 -0400 Subject: Hello List, a easy Cisco question. In-Reply-To: <20110711123344.5f1e402cf2b8f2f1e57b153880067f5a.1afdd94b61.wbe@email10.secureserver.net> References: <20110711123344.5f1e402cf2b8f2f1e57b153880067f5a.1afdd94b61.wbe@email10.secureserver.net> Message-ID: <4E1B5FDD.9010108@csuohio.edu> > setup for outgoing connections for some time, but I have been trying to > get a new inbound connection going for terminal services to a specific > host on tcp port 3389. It sounds like what you want to do is reverse PAT (aka "Policy NAT") http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a008046f31a.shtml#t10 Are you familiar with the CLI or do you strictly use the GUI? .. you'll find the former is much more common. Cheers, Michael Holstein Cleveland State Unviersity From bill at kruchas.com Mon Jul 11 15:43:28 2011 From: bill at kruchas.com (bill at kruchas.com) Date: Mon, 11 Jul 2011 13:43:28 -0700 Subject: Hello List, a easy Cisco question. Message-ID: <20110711134328.5f1e402cf2b8f2f1e57b153880067f5a.771a3971c5.wbe@email10.secureserver.net> Thank You all, Here are some of the suggestions so far, all good. And I will followup on them and report back the final solution. Some reading for tonite ( I already had it and skimmed thru, but I'll need to digest it better). I'm hoping that I'm not beating my head against the wall using Nat instead of Pat, and not sure if Pat would be acceptable. Anyway, thanks again. Bill ****************************************************** Hey Bill, I don't think you can do a static NAT translation on a NAT egress IP address. Have you considered using Port Address Translation instead? Cheers, Taylor As per [1]http://www.nanog.org/mailinglist/listfaqs/otherlists.php, since I don't see any responses to the list here, you'll probably get a more comprehensive reply from real Cisco experts at [2]http://puck.nether.net/mailman/listinfo/cisco-nsp I hope you get the problem solved! Whatever happens, do post back a reply to the list saying what solved the problem in the end. Alex -------- Original Message -------- Subject: RE: Hello List, a easy Cisco question. From: "Eric Tykwinski" <[3]eric-list at truenet.com> Date: Mon, July 11, 2011 12:47 pm To: <[4]bill at kruchas.com> Bill, Sounds like you need to use Port Address Translation (PAT), instead of Network Address Translation (NAT). Here's a Cisco help file for it: [5]http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_ note09186a00804708b4.shtml Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 F: 610-429-3222 -----Original Message----- From: [6]bill at kruchas.com [[7]mailto:bill at kruchas.com] Sent: Monday, July 11, 2011 3:34 PM To: nanog Subject: Hello List, a easy Cisco question. Hello, I am not a heads down network guy, but I have setup a few firewalls, and have got them to do what I wanted, "eventually". But mostly through reading and trial and error. I am struggling with this one, but I think I know the answer, but want to verify it with some experts. We have a cisco asa 5505, with an internet connection with only one useable ip address (subnet 255.255.255.252). We/they have had a nat setup for outgoing connections for some time, but I have been trying to get a new inbound connection going for terminal services to a specific host on tcp port 3389. I'm using "ASDM" but checking the config file and it's building the correct static statement, and access lists (I think anyway). But It doesn't work, and doesn't give a real good definative log message. I was wondering if possibly the fact that nat is using the one ip address, if that precludes the static mapping from working. I've read several step by steps, and again had this working several other places, but always with more ip's. If having just one ip isn't the isssue, is there any other issues I should be looking for. I'd appreciate any insight you might share. Thanks in advance References 1. http://www.nanog.org/mailinglist/listfaqs/otherlists.php 2. http://puck.nether.net/mailman/listinfo/cisco-nsp 3. mailto:eric-list at truenet.com 4. mailto:bill at kruchas.com 5. http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a00804708b4.shtml 6. mailto:bill at kruchas.com 7. mailto:bill at kruchas.com From joelja at bogus.com Mon Jul 11 16:10:50 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 11 Jul 2011 14:10:50 -0700 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <4E19E448.9070807@tiggee.com> Message-ID: On Jul 11, 2011, at 12:18 PM, William Herrin wrote: > On Mon, Jul 11, 2011 at 11:20 AM, Joel Jaeggli wrote: >> On Jul 11, 2011, at 8:13 AM, William Herrin wrote: >>>>>>> Today's RFC candidates are required to call out IANA considerations >>>>>>> and security considerations in special sections. They do so because >>>>>>> each of these areas has landmines that the majority of working groups >>>>>>> are ill equipped to consider on their own. >>>>>>> >>>>>>> There should be an operations callout as well -- a section where >>>>>>> proposed operations defaults (as well as statics for which a solid >>>>>>> case can be made for an operations tunable) are extracted from the >>>>>>> thick of it and offered for operator scrutiny prior to publication of >>>>>>> the RFC. >>> >>> Do you find this adjustment objectionable? >> >> Do I think that adding yet another required section to an >> internet draft is going to increase it's quality? >> No I do not. > > Joel, > > You may be right. Calling out IANA considerations doesn't seem to have > made the IETF any smarter on the shared ISP IPv4 space. And I have no > idea if calling out security implications has helped reduce > security-related design flaws. > > On the other hand, calling out ops issues in RFCs is a modest reform > that at worst shouldn't hurt anything. To my mind, one of the really good criterion for an operational considerations document is some actual experience running it. > That beats my next best idea: > asking the ops area to schedule its meetings with the various NOG > meetings instead of with the rest of the IETF so that the attendance > is ops who dabble in development instead of developers who dabble in > ops. The OPS area works on OPS and Management. Protocol development of the sort you're describing generally occurs in working-groups chartered in the Internet or Routing areas... At least one of the ops chairs are on this list attends nanog regularly etc. Participants, especially those that actually do the work are the important part as far as I'm concerned. Rough consensus is an ugly an imperfect business, it should be recognized that not everyone is going to come away from every exchange with what they want. > You disagree? What are your thoughts on fixing the problem? I'm not sure that we agree on the dimensions of the problem. on the question of ipv6 is broken: * You're going to have to cope with what you have and can squeeze out of vendors in the near term. implmentors don't change that fast. * People have to show up with the problem statement and stick around to do the work * the outcomes are not always pretty. I hope that my time is productively employed. http://tools.ietf.org/html/draft-gashinsky-v6nd-enhance-00 > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > From owen at delong.com Mon Jul 11 16:12:14 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Jul 2011 14:12:14 -0700 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> Message-ID: On Jul 11, 2011, at 12:57 PM, Jeff Wheeler wrote: > On Mon, Jul 11, 2011 at 3:35 PM, Leo Bicknell wrote: >> The IETF does not want operators in many steps of the process. If >> you try to bring up operational concerns in early protocol development >> for example you'll often get a "we'll look at that later" response, >> which in many cases is right. Sometimes you just have to play with >> something before you worry about the operational details. It also > > I really don't understand why that is right / good. People get > personally invested in their project / spec, and not only that, vendor > people get their company's time and money invested in > proof-of-concept. The longer something goes on with what may be > serious design flaws, the harder it is to get them fixed, simply > because of momentum. > > Wouldn't it be nice if we could change the way that next-header works > in IPv6 now? Or get rid of SLAAC and erase the RFCs recommending /80 > and /64 from history? > No... I like SLAAC and find it useful in a number of places. What's wrong with /64? Yes, we need better DOS protection in switches and routers to accommodate some of the realities of those decisions, but, that's not to say that SLAAC or /64s are bad. They're fine ideas with proper protections. I'm not sure about the /80 reference as I haven't encountered that recommendation outside of some perverse ideas about point-to-point links. Owen From bill at herrin.us Mon Jul 11 16:20:25 2011 From: bill at herrin.us (William Herrin) Date: Mon, 11 Jul 2011 17:20:25 -0400 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <4E19E448.9070807@tiggee.com> Message-ID: On Mon, Jul 11, 2011 at 3:41 PM, Jeff Wheeler wrote: > On Mon, Jul 11, 2011 at 3:18 PM, William Herrin wrote: >> On the other hand, calling out ops issues in RFCs is a modest reform >> that at worst shouldn't hurt anything. That beats my next best idea: > > I think if this were done, some guy like me would spend endless hours > arguing with others about what should and should not be documented in > this proposed section, without it actually benefiting the process or > the improving the underlying protocol function / specification. ?Let > me give you an example: > > BGP Messages, which are up to 4KB, need to be expanded to support > future features like as-path signing. ?Randy Bush proposes to extend > them to 65,535 octets, the maximum size without significantly changing > the message header. ?This raises a few concerns which I label as > operational, for example, off-by-one bugs in code can fail to be > detected by a neighboring BGP speaker in some circumstances, because > an age-old (since BGP 1) idiot check in the protocol is being silently > removed. > > If you ask me, that is operational and belongs in such a section. Hi Jeff, Thanks for your thoughtful response. Question: It seems to me like figuring out what is or isn't a security issue to be called out has exactly the same pitfalls. How do you deal with it? > Besides, you want "IETF people" who are claimed not to understand > operational problems to figure them out and document them in the RFCs? > ?I do not think this will be helpful. ?More hands-on operators > participating in their process is what is needed. You're an "IETF person" trying to figure out what is or isn't an operations issue so that you can call it out. How might you go about figuring that out? Personally, I might ask a few ops: "Lend me your ear for three minutes to tell you about what I'm working on. Now that that I've given you the pitch, is this something you'd like to control in a configuration or is it something you want to -just work-?" "Control" = operations issue. "Just work" = not an operations issue. Regards, Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Mon Jul 11 16:21:27 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Jul 2011 14:21:27 -0700 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <4E19E448.9070807@tiggee.com> Message-ID: > >> You disagree? What are your thoughts on fixing the problem? > > I'm not sure that we agree on the dimensions of the problem. > > on the question of ipv6 is broken: > > * You're going to have to cope with what you have and can squeeze out of vendors in the near term. implmentors don't change that fast. > * People have to show up with the problem statement and stick around to do the work > * the outcomes are not always pretty. > I don't think that has anything to do with the problem Bill is trying to address. While it is the topic that started this thread, the problem that I think Bill is trying to address and which I agree needs to be addressed is that IETF standards are developed with what has become increasingly obvious as insufficient operator input. Yes, operators are partially to blame in that decisions are made by those that show up and operators have a hard time showing up to the IETF process for a variety of reasons that are mostly related to the realities of running day to day operations and not realy something the IETF can easily address. However, part of the problem also relates to ways in which the IETF is particularly difficult for operators to credibly participate. (the amount of ego and religion in some of the working groups, the need for a thick skin if you want to make a statement that goes counter to the current dogma, the time-consuming nature of meaningful participation, etc.). I don't pretend to have answers to all of these problems, but, I think there first needs to be recognition and consensus that the lack of operator input into the IETF is becoming increasingly problematic and is impacting the ability to deploy what is developed by the IETF. Owen From fmartin at linkedin.com Mon Jul 11 16:54:32 2011 From: fmartin at linkedin.com (Franck Martin) Date: Mon, 11 Jul 2011 21:54:32 +0000 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: Message-ID: Once upon a time, there was only the IETF, then NOGs came and standards became sloppy.... From jsw at inconcepts.biz Mon Jul 11 17:03:12 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Mon, 11 Jul 2011 18:03:12 -0400 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> Message-ID: On Mon, Jul 11, 2011 at 5:12 PM, Owen DeLong wrote: > No... I like SLAAC and find it useful in a number of places. What's wrong > with /64? Yes, we need better DOS protection in switches and routers See my slides http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf for why no vendor's implementation is effective "DOS protection" today and how much complexity is involved in doing it correctly, which requires not only knobs on routers, but also on layer-2 access switches, which is not easy to implement. It's a whole lot smarter to just configure a smaller network when that is practical. In fact, that advice should be "the standard." I really don't understand why we need SLAAC. I believe it is a relic of a mindset when a DHCP client might have been hard to implement cost-effectively in a really light-weight client device (coffee pot? wrist-watch?) Or when running a DHCP server was some big undertaking that couldn't be made not only obvious, but transparent, to SOHO users buying any $99 CPE. I do understand why SLAAC needs /64. Okay, so configure /64 on those networks where SLAAC is utilized. Otherwise, do something else. Pretty simple! Again, please see my slides. > to accommodate some of the realities of those decisions, but, that's not > to say that SLAAC or /64s are bad. They're fine ideas with proper > protections. The proper protections are kinda hard to do if you have relatively dumb layer-2 access switches. It is a lot harder than RA Guard, and we aren't ever likely to see that feature on a large base of installed "legacy" switches, like Cisco 2950. Replacing those will be expensive. We can't replace them yet anyway because similar switches (price) today still do not have RA Guard, let alone any knobs to defend against neighbor table churn, etc. I'm not sure if they ever will have the later. > I'm not sure about the /80 reference as I haven't encountered that > recommendation outside of some perverse ideas about point-to-point > links. This is because you didn't follow IPv6 progress until somewhat recently, and you are not aware that the original suggestion for prefix length was 80 bits, leaving just 48 bits for the host portion of the address. This was later revised. It helps to know a bit of the history that got us to where we are now. It was originally hoped, by some, that we may not even need NDP because the layer-2 adjacency would always be encoded in the end of the layer-3 address. Some people still think vendors may get us to that point with configuration knobs. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From bill at herrin.us Mon Jul 11 17:32:10 2011 From: bill at herrin.us (William Herrin) Date: Mon, 11 Jul 2011 18:32:10 -0400 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: <20110711193508.GA97493@ussenterprise.ufp.org> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> Message-ID: On Mon, Jul 11, 2011 at 3:35 PM, Leo Bicknell wrote: > If the IETF really wanted to get useful operator impact, they would > slightly modify their process. ?On the front end there would be a > more clear way for operational types to add to the To-Do list "stuff > we really need to make the Internet work better". Hi Leo, That's an interesting idea, but how does it work? As it stands, I can join a working group mailing list and submit an I-D any time I feel like it. There is almost zero barrier to entry. And I can take it to any step short of the final publication track through the simple expedient of working on it myself. How does the to-do list differ from this? Does it provide some kind of push counter to the folks who hum against publication? How's it work? >?Then, some sausage > would be made largely without operator involvement (but hey, if you > want to participate no exclusions), and then when developmen is > about 80-90% done there would be an "operational testing and comment > period". That's another interesting idea. Would you mind gaming it out for me? Use RFC 3484. You have I-D-v6-address-selection 90% ready for publication as RFC 3484. Now what? In their prescience, the operator feedback is going to be "with multiple addresses on a server representing various Internet paths with various reliabilities, we need a way to communicate to the client which addresses to prefer based on our expert knowledge of the reliability of our local network." What elicits that feedback? What do the authors of I-D-v6-address-selection do with the feedback prior to publication? Thanks, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Mon Jul 11 17:37:02 2011 From: bill at herrin.us (William Herrin) Date: Mon, 11 Jul 2011 18:37:02 -0400 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <4E19E448.9070807@tiggee.com> Message-ID: On Mon, Jul 11, 2011 at 5:10 PM, Joel Jaeggli wrote: > > On Jul 11, 2011, at 12:18 PM, William Herrin wrote: > >> On Mon, Jul 11, 2011 at 11:20 AM, Joel Jaeggli wrote: >>> On Jul 11, 2011, at 8:13 AM, William Herrin wrote: >>>>>>>> Today's RFC candidates are required to call out IANA considerations >>>>>>>> and security considerations in special sections. They do so because >>>>>>>> each of these areas has landmines that the majority of working groups >>>>>>>> are ill equipped to consider on their own. >>>>>>>> >>>>>>>> There should be an operations callout as well -- a section where >>>>>>>> proposed operations defaults (as well as statics for which a solid >>>>>>>> case can be made for an operations tunable) are extracted from the >>>>>>>> thick of it and offered for operator scrutiny prior to publication of >>>>>>>> the RFC. >>>> >>>> Do you find this adjustment objectionable? >>> >>> Do I think that adding yet another required section to an >>> internet draft is going to increase it's quality? >>> No I do not. >> >> Joel, >> >> You may be right. Calling out IANA considerations doesn't seem to have >> made the IETF any smarter on the shared ISP IPv4 space. And I have no >> idea if calling out security implications has helped reduce >> security-related design flaws. >> >> On the other hand, calling out ops issues in RFCs is a modest reform >> that at worst shouldn't hurt anything. > > To my mind, one of the really good criterion for an operational > considerations document is some actual experience running it. Hi Joel, I'm not looking for anything that sophisticated. I just want a list of "These are the things that can be tuned at an operations level (plus the defaults) and these are the things that can't be tuned but someone in the discussion thought a reasonable person might want them to be." The idea is that an ops guy should be able to read the three-paragraph intro, jump to the list of tunables and then be able to offer feedback along the lines of, "Whoa! Of course X should be tunable, are you kidding? Here's a rough description of where I want to configure it." and "I'm never going to alter Y. You can make it configurable, but I'd just as soon deal with everybody having the same value of Y." Heck, make it multiple choice. 1 is "no chance I'll ever want to change this value" and 5 is "I'll want to set this value case by case." >> That beats my next best idea: >> asking the ops area to schedule its meetings with the various NOG >> meetings instead of with the rest of the IETF so that the attendance >> is ops who dabble in development instead of developers who dabble in >> ops. > > The OPS area works on OPS and Management. Protocol > development of the sort you're describing generally occurs > in working-groups chartered in the Internet or Routing areas... A moment ago you said, the ops area "reviews basically every draft in front of the IESG." > Participants, especially those that actually do the work are the > important part as far as I'm concerned. I don't disagree. But producing flawed standards does nobody any good, least of all the folks who poured their hearts and souls into making them. > Rough consensus is an ugly an imperfect business, it > should be recognized that not everyone is going to come > away from every exchange with what they want. Which if you were talking about a rough consensus of operations folk addressing operations issues would be just fine. This is basically what happens at the address registries like ARIN and it more or less works. That's broken in the IETF. The ops folks aren't there for the consensus checks. As a consequence, ops issues are being decided not with -rough- consensus but with -false- consensus. False consensus falls apart when you try to bring the excluded folks back to the party, as you must in the operators' case with any standard the IETF produces. >> You disagree? What are your thoughts on fixing the problem? > > I'm not sure that we agree on the dimensions of the problem. > > on the question of ipv6 is broken: > > * You're going to have to cope with what you have and can squeeze out of vendors in the near term. implmentors don't change that fast. > * People have to show up with the problem statement and stick around to do the work > * the outcomes are not always pretty. V6 poses some difficult challenges and you're right that in the short term we're basically stuck with what is and have to make the best of it. But V6 isn't my focus in this thread. The ops are sufficiently irate at this point that they'll keep pounding on the WG's and the vendors until fixes happen. My focus in this thread is this: how do we help the next teams avoid the discourtesy and the smackdown that the v6 teams are getting for not adequately recognizing the ops' issues. These guys should have been heroes but instead they screwed the pooch and everybody's paying for it. How do we fix the systemic problems so that next time they are heroes? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From llynch at civil-tongue.net Mon Jul 11 17:43:27 2011 From: llynch at civil-tongue.net (Lucy Lynch) Date: Mon, 11 Jul 2011 15:43:27 -0700 (PDT) Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) Message-ID: On Mon, 11 Jul 2011, William Herrin wrote: > On Mon, Jul 11, 2011 at 5:10 PM, Joel Jaeggli wrote: >> >> On Jul 11, 2011, at 12:18 PM, William Herrin wrote: > > My focus in this thread is this: how do we help the next teams avoid > the discourtesy and the smackdown that the v6 teams are getting for > not adequately recognizing the ops' issues. These guys should have > been heroes but instead they screwed the pooch and everybody's paying > for it. How do we fix the systemic problems so that next time they are > heroes? get to the party early: http://trac.tools.ietf.org/bof/trac/ and stay late... lots of new work inbound. - Lucy > Regards, > Bill Herrin > > > From joelja at bogus.com Mon Jul 11 18:21:09 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 11 Jul 2011 16:21:09 -0700 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <4E19E448.9070807@tiggee.com> Message-ID: <268B9B92-4EBF-4879-9724-759C20B754DD@bogus.com> On Jul 11, 2011, at 3:37 PM, William Herrin wrote: > On Mon, Jul 11, 2011 at 5:10 PM, Joel Jaeggli wrote: >> >> On Jul 11, 2011, at 12:18 PM, William Herrin wrote: >> >>> On Mon, Jul 11, 2011 at 11:20 AM, Joel Jaeggli wrote: >>>> On Jul 11, 2011, at 8:13 AM, William Herrin wrote: >>>>>>>>> Today's RFC candidates are required to call out IANA considerations >>>>>>>>> and security considerations in special sections. They do so because >>>>>>>>> each of these areas has landmines that the majority of working groups >>>>>>>>> are ill equipped to consider on their own. >>>>>>>>> >>>>>>>>> There should be an operations callout as well -- a section where >>>>>>>>> proposed operations defaults (as well as statics for which a solid >>>>>>>>> case can be made for an operations tunable) are extracted from the >>>>>>>>> thick of it and offered for operator scrutiny prior to publication of >>>>>>>>> the RFC. >>>>> >>>>> Do you find this adjustment objectionable? >>>> >>>> Do I think that adding yet another required section to an >>>> internet draft is going to increase it's quality? >>>> No I do not. >>> >>> Joel, >>> >>> You may be right. Calling out IANA considerations doesn't seem to have >>> made the IETF any smarter on the shared ISP IPv4 space. And I have no >>> idea if calling out security implications has helped reduce >>> security-related design flaws. >>> >>> On the other hand, calling out ops issues in RFCs is a modest reform >>> that at worst shouldn't hurt anything. >> >> To my mind, one of the really good criterion for an operational >> considerations document is some actual experience running it. > > Hi Joel, > > I'm not looking for anything that sophisticated. I just want a list of > "These are the things that can be tuned at an operations level (plus > the defaults) and these are the things that can't be tuned but someone > in the discussion thought a reasonable person might want them to be." > The idea is that an ops guy should be able to read the three-paragraph > intro, jump to the list of tunables and then be able to offer feedback > along the lines of, "Whoa! Of course X should be tunable, are you > kidding? Here's a rough description of where I want to configure it." > and "I'm never going to alter Y. You can make it configurable, but I'd > just as soon deal with everybody having the same value of Y." > > Heck, make it multiple choice. 1 is "no chance I'll ever want to > change this value" and 5 is "I'll want to set this value case by > case." > > >>> That beats my next best idea: >>> asking the ops area to schedule its meetings with the various NOG >>> meetings instead of with the rest of the IETF so that the attendance >>> is ops who dabble in development instead of developers who dabble in >>> ops. >> >> The OPS area works on OPS and Management. Protocol >> development of the sort you're describing generally occurs >> in working-groups chartered in the Internet or Routing areas... > > A moment ago you said, the ops area "reviews basically every draft in > front of the IESG." I said there is an ops directorate that reviews basically every draft in front of the iesg... much like their are genart reviews, security reviews iana reviews etc. The principle work on a draft by the time that occurs is already done unless the iesg returns the draft to the work group. >> Participants, especially those that actually do the work are the >> important part as far as I'm concerned. > > My focus in this thread is this: how do we help the next teams avoid > the discourtesy and the smackdown that the v6 teams are getting for > not adequately recognizing the ops' issues. These guys should have > been heroes but instead they screwed the pooch and everybody's paying > for it. How do we fix the systemic problems so that next time they are > heroes? IPNG was a long time ago. things have changed and will continue to change because standards are written by humans and cemented with consensus which is imperment and changable. Rational changes, Requirements change and things should evolve, that's not failure it's healthy. > Regards, > Bill Herrin From mysidia at gmail.com Mon Jul 11 18:48:33 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 11 Jul 2011 18:48:33 -0500 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> Message-ID: On Mon, Jul 11, 2011 at 5:03 PM, Jeff Wheeler wrote: > On Mon, Jul 11, 2011 at 5:12 PM, Owen DeLong wrote: >> No... I like SLAAC and find it useful in a number of places. What's wrong >> with /64? Yes, we need better DOS protection in switches and routers > See my slides http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf for > why no vendor's implementation is effective "DOS protection" today and > how much complexity is involved in doing it correctly, which requires [snip] If every vendor's implementation is vulnerable to a NDP Exhaustion vulnerability, how come the behavior of specific routers has not been documented specifically? If "zero" devices are not vulnerable, you came to this conclusion because you tested every single implementation against IPv6 NDP DoS, or? How come there are no security advisories. What's the CWE or CVE number for this vulnerability? I'm not denying the that NDP overflow might be a DoS issue for all IPv6 routers, but I haven't seen any specific documentation from vendors or security researchers about specific DoS conditions that can be caused by NDP overflow on particular devices.... It would be useful to at least have the risk properly described, in terms of what kind of DoS condition could arise on specific implementations. Regards, -- -JH From kauer at biplane.com.au Mon Jul 11 19:17:30 2011 From: kauer at biplane.com.au (Karl Auer) Date: Tue, 12 Jul 2011 10:17:30 +1000 Subject: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> Message-ID: <1310429850.2382.26.camel@karl> On Mon, 2011-07-11 at 18:48 -0500, Jimmy Hess wrote: > It would be useful to at least have the risk properly described, in > terms of what kind of DoS condition could arise on specific implementations. RFC3756 IPv6 Neighbor Discovery (ND) Trust Models and Threats Section 4.3.2 In this attack, the attacking node begins fabricating addresses with the subnet prefix and continuously sending packets to them. The last hop router is obligated to resolve these addresses by sending neighbor solicitation packets. A legitimate host attempting to enter the network may not be able to obtain Neighbor Discovery service from the last hop router as it will be already busy with sending other solicitations. This DoS attack is different from the others in that the attacker may be off-link. The resource being attacked in this case is the conceptual neighbor cache, which will be filled with attempts to resolve IPv6 addresses having a valid prefix but invalid suffix. This is a DoS attack. The above RFC and RFC3971 (SEND) both have good descriptions of a BUNCH of possible attacks. RFC3971 is a bit dismissive IMHO of this particular attack. I realise this is not "specific implementations" as you requested, but it seems to me that the problem is generic enough not to require that. The attack is made possible by the design of the protocol, not any failing of specific implementations. Specific implementations need to describe what they've done about it (mitigation or prevention). Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jsw at inconcepts.biz Mon Jul 11 19:19:33 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Mon, 11 Jul 2011 20:19:33 -0400 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> Message-ID: On Mon, Jul 11, 2011 at 7:48 PM, Jimmy Hess wrote: > If every vendor's implementation is vulnerable to a NDP Exhaustion > vulnerability, > how come the behavior of specific routers has not been documented specifically? Well, I am in the business of knowing the behavior of kit being considered by my clients for their applications. Every box breaks when tested, period. I imagine you have tested zero, thus you have no data of your own to go on. No vendors are rushing to spend money on "independent" testing laboratories to produce reports about this, because they pretty much all know their boxes will break (or are not even aware of the potential problem, in the case of a few scary vendors.) > If ?"zero" devices are not vulnerable, you came to this conclusion > because you tested > every single implementation against IPv6 NDP DoS, ?or? Although I have tested many routers to verify my thinking, if you actually read the slides and understand how routers work, you too will know that every router is vulnerable. If you don't know, you don't understand how routers work. It's that simple. > How come there are no security advisories. > What's the CWE or CVE number for this vulnerability? Again, no one is interested in this problem yet because vendors really don't want their customers to demand more knobs. Cisco is the only vendor who has done anything at all. If you read about their knob, you immediately realize that it is a knob to control the failure mode of the box, not to "fix" anything. Why? It can't be "fixed" without not using /64 (or similar) or going to the extreme lengths I outline in those slides. > It would be useful to at least have the risk properly described, in > terms of what > kind of DoS condition could arise on specific implementations. Let's take 6500/SUP720 for example. On this platform, a policer is shared between the need to resolve ARP entries and ND table entries. If you attack a dual-stack SUP720 box it will break not only IPv6 neighbor resolution, but also IPv4 neighbor resolution. This is pretty much the "worst-case scenario" because not only will your IPv6 break, which may annoy customers but not be a disaster; it will also break mission-critical IPv4. That's bad. Routing-protocol adjacencies can be affected, disabling not just some hosts downstream of the box, but also its upstream connectivity. It doesn't get any worse than that. You are right to question my statements. I'm not an independent lab doing professional tests and showing the environment and conditions of how you can reproduce the results. I'm just a guy helping my clients decide what kit to buy, and how they should configure their networks. The only reason I have bothered to produce slides is because we are at a point where we have end-customers questioning our reluctance to provision /64 networks for mixed-use data-center LANs, and until vendors actually do something to address this, or "the standard" changes, I need to increase awareness of this problem so I am not forced to deploy a broken design on my own networks the way a lot of other clueless people are. Again, this is only hard to understand (or accept) if you don't know how your routers work. * why do you think there is an ARP and ND table? * why do you think there are policers to protect the CPU from excessive ARP/ND punts or traffic? * do you even know the limit of your boxes' ARP / ND tables? Do you realize that limit is a tiny fraction of one /64? * do you understand what happens when your ARP/ND policers are reached? * did you think about the impact on neighboring routers and protocol next-hops, not just servers? * did you every try to deploy a /16 on a flat LAN with a lot of hosts and see what happens? Doesn't work too well. A v6 /64 is 281 trillion times bigger than a v4 /16. There's no big leap of logic here as to why one rogue machine could break your LAN. There is no router which is not vulnerable to this. If you don't believe me, read the Cisco documentation on their knob limiting ND entries per interface, after which there may be service impact on that interface. That's the best anyone is doing right now. Of course, vendors understand that we, as customers, can configure a subnet smaller than /64. They are leaving us open to link-local issues right now even with a smaller global subnet size, but at least that cannot be exploited from "the Internet." And as it happens, exactly the same features / knobs are needed to "fix" both problems with /64, and with link-local neighbor learning. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From dougb at dougbarton.us Mon Jul 11 19:28:11 2011 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 11 Jul 2011 17:28:11 -0700 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: <5F4FCDA1-EE05-4CBD-9E3B-91EEE5083D8A@delong.com> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <5F4FCDA1-EE05-4CBD-9E3B-91EEE5083D8A@delong.com> Message-ID: <4E1B951B.5040009@dougbarton.us> On 07/10/2011 12:45, Owen DeLong wrote: > > On Jul 10, 2011, at 9:16 AM, Jeroen Massar wrote: > >> On 2011-07-10 17:56 , David Miller wrote: >> [..] >>> +1 >>> >>> The lack of will on the part of the IETF to attract input from and involve >>> operators in their processes (which I would posit is a critical element in >>> the process). Discussing how the IETF should fix itself is both fruitless, and off topic for this list. However ... > While this is true, there are a couple of factors that make it more difficult > than it would appear on the surface. > > Number one: Participating effectively in IETF is a rather time-consuming > process. While a lot of engineers and developers may have IETF effort > as a primary part of their job function and/or get their employer to let > them spend time on it, operators are often too busy keeping what they > already have running and it can be _VERY_ difficult to get management > to support the idea of investing time in things like IETF which are not > seen by management as having direct operational impact. NANOG > is about the limit of their vision on such things and even that is not > well supported in a lot of organizations. > > Number two: While anyone can participate, approaching IETF as an > operator requires a rather thick skin, or, at least it did the last couple > of times I attempted to participate. I've watched a few times where > operators were shouted down by purists and religion over basic > real-world operational concerns. It seems to be a relatively routine > practice and does not lead to operators wanting to come back to > an environment where they feel unwelcome. What you're saying is absolutely right (unfortunately), but the answer is that operators need to suck it up and get involved. The problem will not fix itself if we don't. The good news is that in many areas (at least, the areas that I participate in) there is starting to be a lot more sympathy toward operational concerns/realities, and real progress is being made. Yes, it's slow, arduous, and often frustrating. (How's that for a sales pitch?) But there is literally no other solution to improving the situation that for the people that care to get involved in helping to fix it. For those interested in IPv6 I highly recommend subscribing to the the 6man and v6ops lists, listen in on the conversations for a while, and then chime in when you feel comfortable. Treat those on the list with the same courtesy and respect that you'd like to be treated with, and way more often than not it will bear fruit. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From walter.keen at rainierconnect.net Mon Jul 11 19:29:19 2011 From: walter.keen at rainierconnect.net (Walter Keen) Date: Mon, 11 Jul 2011 17:29:19 -0700 Subject: Facebook contact? Message-ID: <4E1B955F.7010807@rainierconnect.net> If anyone from Facebook is here, Please contact me. Thanks -- Walter Keen Network Engineer Rainier Connect (P) 360-832-4024 (C) 253-302-0194 From randy at psg.com Mon Jul 11 19:35:10 2011 From: randy at psg.com (Randy Bush) Date: Tue, 12 Jul 2011 09:35:10 +0900 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <4E19E448.9070807@tiggee.com> Message-ID: > Well, you work at Zynga, a company which makes facebook games. Before > that you worked at Nokia, company which makes phones but doesn't run > phone networks. Before that it was Check Point Software, a company > which makes firewalls but doesn't run networks. And before that it was > the University of Oregon. down to the ad homina pretty quickly. congrats. fyi, what joel does/did at those companies is/was build and run networks and data centers. next ad hominem attack? randy From mysidia at gmail.com Mon Jul 11 19:38:01 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 11 Jul 2011 19:38:01 -0500 Subject: Hello List, a easy Cisco question. In-Reply-To: <20110711131600.5f1e402cf2b8f2f1e57b153880067f5a.03fdbfbd6b.wbe@email10.secureserver.net> References: <20110711131600.5f1e402cf2b8f2f1e57b153880067f5a.03fdbfbd6b.wbe@email10.secureserver.net> Message-ID: On Mon, Jul 11, 2011 at 3:16 PM, wrote: > ? connection. > ip address outside-ip 255.255.255.252 Aside from the fact 255.255.255.252 is not a valid IP address. Firewalls are security sensitive devices, I suggest reading docs and not relying on untrusted sources for basic operating directions; if improperly configured a Firewall may pass traffic but be insecure. I can't tell you exactly what buttons to hit in the SDM right now, but I see you have " access-list Etherpoint_access_in extended permit tcp any eq 3389 host 192.168.125.8 eq 3389" Unless "192.168.125.8" is your global IP, something is wrong here. You should permit to destination port 3389 on the global IP, on the inbound ACL of your outside interface, when you are applying an ACL before translation. Then traffic matching your port forwarding rule would then be allowed through that ACL " access-list Etherpoint_access_in extended permit tcp host 192.168.125.8 eq 3389 any eq 3389" You don't need this, assuming .125.8 is an inside IP and Etherpoint is your outside int. > > > > ? Here is the pertinent section of the runing config. > > > > ? ! > ? interface Ethernet0/2 > ? ?nameif Etherpoint > ? ?security-level 0 > ? ?ip address outside-ip 255.255.255.252 > ? ?ospf cost 10 > ? ! > > ? object-group service terminal-services tcp > ? ?port-object eq 3389 > ? access-list Inside_access_in extended permit icmp any any > ? access-list Inside_access_in extended permit ip 192.168.125.0 > ? 255.255.255.0 any > ? access-list Inside_nat0_outbound extended permit ip 192.168.125.0 > ? 255.255.255.0 MobileVPN 255.255.255.0 > ? access-list Inside_nat0_outbound extended permit ip 192.168.0.0 > ? 255.255.255.0 MobileVPN 255.255.255.0 inactive > ? access-list Inside_nat0_outbound extended permit ip 192.168.125.0 > ? 255.255.255.0 any inactive > ? access-list Inside_nat0_outbound extended permit ip 192.168.125.0 > ? 255.255.255.0 192.168.1.0 255.255.255.0 > ? access-list Inside_nat0_outbound extended permit ip 192.168.125.0 > ? 255.255.255.0 192.168.14.0 255.255.255.0 > ? access-list Inside_nat0_outbound extended permit ip 192.168.125.0 > ? 255.255.255.0 192.168.100.0 255.255.255.0 > ? access-list Inside_nat0_outbound extended permit ip 192.168.125.0 > ? 255.255.255.0 192.168.101.0 255.255.255.0 > ? access-list Inside_nat0_outbound extended permit ip 192.168.125.0 > ? 255.255.255.0 192.168.253.0 255.255.255.0 > ? access-list Haven_splitTunnelAcl_1 standard permit 192.168.125.0 > ? 255.255.255.0 > ? access-list Etherpoint_access_in extended permit tcp host 192.168.125.8 > ? eq 3389 any eq 3389 > ? access-list Etherpoint_access_in extended permit tcp any eq 3389 host > ? 192.168.125.8 eq 3389 > ? access-list Etherpoint_access_in extended permit tcp any host > ? 192.168.125.8 eq 3389 > ? access-list Etherpoint_nat0_outbound extended permit ip host > ? 192.168.125.8 host outside-ip > ? access-list Etherpoint_nat0_outbound extended permit ip host outside-ip > ? host 192.168.125.8 > > ? ip local pool HavenVPN 192.168.253.1-192.168.253.254 mask 255.255.255.0 > > ? global (Etherpoint) 2 interface > > ? nat (Inside) 0 access-list Inside_nat0_outbound > ? nat (Inside) 2 192.168.125.0 255.255.255.0 > ? nat (Etherpoint) 0 access-list Etherpoint_nat0_outbound outside > ? static (Inside,Etherpoint) tcp interface 3389 192.168.125.8 3389 > ? netmask 255.255.255.255 > > ? no threat-detection statistics tcp-intercept > ? access-group Inside_access_in in interface Inside > ? access-group Etherpoint_access_in in interface Etherpoint > > ? route Etherpoint 0.0.0.0 0.0.0.0 204.186.102.187 1 > > > > ? -------- Original Message -------- > ? Subject: Re: Hello List, a easy Cisco question. > ? From: Dennis <[1]daodennis at gmail.com> > ? Date: Mon, July 11, 2011 12:39 pm > ? To: [2]bill at kruchas.com > ? On Mon, Jul 11, 2011 at 12:33 PM, <[3]bill at kruchas.com> wrote: > ? > ? Hello, > ? > > ? > ? ? ? I am not a heads down network guy, but I have setup a few > ? > ? firewalls, and have got them to do what I wanted, "eventually". But > ? > ? mostly through reading and trial and error. > ? > > ? > ? ? ? I am struggling with this one, but I think I know the answer, > ? but > ? > ? want to verify it with some experts. > ? > > ? > > ? > > ? > ? ? ? We have a cisco asa 5505, with an internet connection with only > ? one > ? > ? useable ip address (subnet 255.255.255.252). We/they have had a nat > ? > ? setup for outgoing connections for some time, but I have been > ? trying to > ? So your provider has your ASA behind a NAT or there is a NAT > ? inside,outside statement on your ASA? > ? Some more pieces of the configuration would be helpful here too. > ? Thanks, > ? Dennis O. > > References > > ? 1. mailto:daodennis at gmail.com > ? 2. mailto:bill at kruchas.com > ? 3. mailto:bill at kruchas.com > Regards, -- -JH From randy at psg.com Mon Jul 11 19:39:47 2011 From: randy at psg.com (Randy Bush) Date: Tue, 12 Jul 2011 09:39:47 +0900 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: Message-ID: >> My focus in this thread is this: how do we help the next teams avoid >> the discourtesy and the smackdown that the v6 teams are getting for >> not adequately recognizing the ops' issues. These guys should have >> been heroes but instead they screwed the pooch and everybody's paying >> for it. How do we fix the systemic problems so that next time they >> are heroes? > get to the party early: http://trac.tools.ietf.org/bof/trac/ and stay > late... lots of new work inbound. aka, suit up and show up. talk is cheap. randy From randy at psg.com Mon Jul 11 19:41:46 2011 From: randy at psg.com (Randy Bush) Date: Tue, 12 Jul 2011 09:41:46 +0900 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: <268B9B92-4EBF-4879-9724-759C20B754DD@bogus.com> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <4E19E448.9070807@tiggee.com> <268B9B92-4EBF-4879-9724-759C20B754DD@bogus.com> Message-ID: > I said there is an ops directorate that reviews basically every draft > in front of the iesg. and this directorate is a group of actual operators? randy From walter.keen at RainierConnect.net Mon Jul 11 20:23:31 2011 From: walter.keen at RainierConnect.net (Walter Keen) Date: Mon, 11 Jul 2011 18:23:31 -0700 Subject: Myspace. Was:Re: Facebook contact? In-Reply-To: <4E1B955F.7010807@rainierconnect.net> References: <4E1B955F.7010807@rainierconnect.net> Message-ID: <5234b2c8-26b3-4925-a2da-a0106fc31a5e@blur> My apologies all, I meant to say myspace contact Connected by DROID on Verizon Wireless -----Original message----- From: Walter Keen To: NANOG list Sent: Tue, Jul 12, 2011 00:29:19 GMT+00:00 Subject: Facebook contact? If anyone from Facebook is here, Please contact me. Thanks -- Walter Keen Network Engineer Rainier Connect (P) 360-832-4024 (C) 253-302-0194 From mpetach at netflight.com Mon Jul 11 20:30:17 2011 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 11 Jul 2011 18:30:17 -0700 Subject: Myspace. Was:Re: Facebook contact? In-Reply-To: <5234b2c8-26b3-4925-a2da-a0106fc31a5e@blur> References: <4E1B955F.7010807@rainierconnect.net> <5234b2c8-26b3-4925-a2da-a0106fc31a5e@blur> Message-ID: On Mon, Jul 11, 2011 at 6:23 PM, Walter Keen wrote: > My apologies all, I meant to say myspace contact > You're more likely to get a response if you give some indication of what the issue is; for example, saying "I'm looking for a MySpace contact because there is an attack coming from their servers that appears to indicate they may have been compromised" will likely get you a faster reaction from the security people. Or, if it's a network issue, saying "I'm looking for a MySpace network contact because it appears they are announcing the following blocks which really belong to me, which is causing reachability issues" will more likely get you a reaction from an appropriate network person. Without an indication of the nature of the problem, I think you'll find most people on the list tend to ignore generic requests like this. Thanks! Matt From fred at cisco.com Mon Jul 11 18:13:15 2011 From: fred at cisco.com (Fred Baker) Date: Mon, 11 Jul 2011 19:13:15 -0400 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: <4E19D049.8010006@unfix.org> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> Message-ID: <66FC7903-8643-4F3A-987F-9E09E56136EB@cisco.com> On Jul 10, 2011, at 12:16 PM, Jeroen Massar wrote: > On 2011-07-10 17:56 , David Miller wrote: > [..] >> +1 >> >> The lack of will on the part of the IETF to attract input from and involve operators in their processes (which I would posit is a critical element in the process). > > Ehmmmm ANYBODY, including you, can sign up to the IETF mailing lists and participate there, just like a couple of folks from NANOG are already doing. > > You are on NANOG out of your own free will, the same applies to the IETF. If you don't participate here your voice is not heard either, just > like at the IETF. > > Peeking at the ipv6 at ietf.org member list, I don't see your name there. You can signup here: https://www.ietf.org/mailman/listinfo/ipv6 Thanks, Jeroen. For IPv6 functionality, I'd suggest ipv6 at ietf.org (https://www.ietf.org/mailman/listinfo/ipv6). For IPv6 operational issues, I'd suggest v6ops at ietf.org (https://www.ietf.org/mailman/listinfo/v6ops). For security-related issues, you might also look into opsec at ietf.org (https://www.ietf.org/mailman/listinfo/opsec). On Jul 10, 2011, at 3:45 PM, Owen DeLong wrote: > Number two: While anyone can participate, approaching IETF as an operator requires a rather thick skin, or, at least it did the last couple of times I attempted to participate. I've watched a few times where operators were shouted down by purists and religion over basic real-world operational concerns. That goes both ways. I periodically see dismissive statements about the IETF on operational lists, and dismissive statements about operators on IETF lists. I would classify David's comment as "dismissive", the kind of comment that causes IETF folks to not participate in operational meetings or lists, and the kind of comment cited by operational folks such as you as reasons to leave IETF meetings and lists. Such comments tend to come from a small set of individuals on each side. If such comments bother you, feel free to block the in-duh-viduals that send them. Personally, I try to listen to them; they are often telling me something I need to hear but don't want to. From owen at delong.com Mon Jul 11 22:18:11 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Jul 2011 20:18:11 -0700 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: Message-ID: On Jul 11, 2011, at 2:54 PM, Franck Martin wrote: > Once upon a time, there was only the IETF, then NOGs came and standards > became sloppy.... > Uh, no... Really not. Read some of the earliest standards documents and you'll find that they are pretty sloppy, but, the community back then (predecessor to NOGs) was small enough that people could develop and deploy workarounds and feed those resolutions into superseding RFCs. Today, there are many more operators and IETF has become a much larger and more complex set of bodies as well. Owen From owen at delong.com Mon Jul 11 23:16:31 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Jul 2011 21:16:31 -0700 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> Message-ID: > > Again, no one is interested in this problem yet because vendors really > don't want their customers to demand more knobs. Cisco is the only > vendor who has done anything at all. If you read about their knob, > you immediately realize that it is a knob to control the failure mode > of the box, not to "fix" anything. Why? It can't be "fixed" without > not using /64 (or similar) or going to the extreme lengths I outline > in those slides. > While it can't be "fixed", controlling the failure mode is adequate in the vast majority of cases. Beyond that, it becomes increasingly academic and purist-oriented rather than operational. Owen From mksmith at adhost.com Mon Jul 11 23:37:28 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Tue, 12 Jul 2011 04:37:28 +0000 Subject: IMPORTANT: NANOG List Cutover Test Message-ID: Hello: I'll be testing the list cutover again at 10:00 PM PDT (GMT -7). Please ignore the subsequent "NANOG TEST" email that comes through to the list. Regards, Mike From itsupport at tics-ltd.co.uk Tue Jul 12 08:28:16 2011 From: itsupport at tics-ltd.co.uk (Chris Barlow) Date: Tue, 12 Jul 2011 14:28:16 +0100 Subject: NANOG List Update - Moving Forward In-Reply-To: References: <20110712063235.36b02a11@petrie> Message-ID: <002501cc4097$8e7da4e0$ab78eea0$@tics-ltd.co.uk> And adding to it as well +7 Kind Regards Chris Barlow? BSc. MBCS Information Technology Manager TICS (Global) Ltd, Oxford House Sixth Avenue, Robin Hood Airport Doncaster? DN9 3GG ? ? Tel?? +44 (0)1302 623074 Fax?? +44 (0)1302 623075 Mob? +44(0)7909 520445 This message is for the intended recipient only.? It may contain confidential or proprietary information. If you receive this message in error, please immediately delete it, destroy all copies of it and notify the sender. You must not use or disclose any part of this message if you are not the intended recipient.? If you contact us by email, we may store your name and address to facilitate communication.? We take reasonable precautions to ensure our emails are virus free, however we cannot accept responsibility for any virus transmitted by us and recommend that you subject any incoming email to your own virus checking procedures. ? Head Office:? TICS Ltd, Oxford House, Sixth Avenue, Robin Hood Airport, Doncaster? DN9 3GG? ?????????? Registered in England and Wales under registration number 7164795 ? For further information about TICS Ltd, please visit http://www.tics-ltd.co.uk -----Original Message----- From: jim deleskie [mailto:deleskie at gmail.com] Sent: 12 July 2011 13:03 To: nenolod at systeminplace.net Cc: tim at pelican.org; NANOG list Subject: Re: NANOG List Update - Moving Forward +1 On Tue, Jul 12, 2011 at 8:32 AM, William Pitcock wrote: > On Tue, 12 Jul 2011 10:50:38 +0100 (BST) Tim Franklin > wrote: > >> > Thankfully, the current test has been a success. >> >> Including stopping non-members from posting to the list, and other >> anti-spam? >> >> I've got a sudden influx this morning of spam addressed to >> nanog at nanog.org :( >> > > Ditto. ?Getting lots of crap here. > > William > From tagno25 at gmail.com Tue Jul 12 06:58:41 2011 From: tagno25 at gmail.com (Philip Dorr) Date: Tue, 12 Jul 2011 06:58:41 -0500 Subject: NANOG List Update - Moving Forward In-Reply-To: References: Message-ID: On Tue, Jul 12, 2011 at 4:50 AM, Tim Franklin wrote: >> Thankfully, the current test has been a success. > > Including stopping non-members from posting to the list, and other anti-spam? > > I've got a sudden influx this morning of spam addressed to nanog at nanog.org :( > > Regards, > Tim. > Same here. Previously I have maybe received maybe one or two spam messages total via NANOG, but this morning I have received seven. From mksmith at adhost.com Tue Jul 12 08:59:05 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Tue, 12 Jul 2011 13:59:05 +0000 Subject: NANOG Move - Moved back Message-ID: Hello All: We're back on the old configuration for now. I will send an update later this afternoon once I speak with AMS about the issues we experienced over night. Regards, Mike From ops.lists at gmail.com Tue Jul 12 04:33:27 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 12 Jul 2011 15:03:27 +0530 Subject: dammit, please make nanog poster only .. dont let nonmembers post to it Message-ID: That's the second spam received on nanog so far. First a chinese voip vendor who probably wont gain any customers, the second a nigerian westernunion scam -- Suresh Ramasubramanian (ops.lists at gmail.com) From swmike at swm.pp.se Tue Jul 12 05:54:48 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 12 Jul 2011 12:54:48 +0200 (CEST) Subject: NANOG List Update - Moving Forward In-Reply-To: References: Message-ID: On Tue, 12 Jul 2011, Mikael Abrahamsson wrote: > On Tue, 12 Jul 2011, Michael K. Smith - Adhost wrote: > >> If you have any questions or concerns please let me know. > > The new posts do not have list (un)subscribe information in the headers. This took a very long time to get delivered (2h20 minutes). Also, the new mail server doesn't seem to support TLS and during this short time it's been active, we've had multiple SPAM get distributed through the list as well. What was the reason for the change, from what it looks like right now there seems to be quite a few downsides and functionality/performance lost. -- Mikael Abrahamsson email: swmike at swm.pp.se From aftab.siddiqui at gmail.com Tue Jul 12 07:37:13 2011 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Tue, 12 Jul 2011 17:37:13 +0500 Subject: NANOG List Update - Moving Forward In-Reply-To: <20110712063235.36b02a11@petrie> References: <20110712063235.36b02a11@petrie> Message-ID: Just want to re-confirm. I've got only 4 in my spam. Is it google spam who is not putting it in SPAM folder? Regards, Aftab A. Siddiqui On Tue, Jul 12, 2011 at 4:32 PM, William Pitcock wrote: > On Tue, 12 Jul 2011 10:50:38 +0100 (BST) > Tim Franklin wrote: > > > > Thankfully, the current test has been a success. > > > > Including stopping non-members from posting to the list, and other > > anti-spam? > > > > I've got a sudden influx this morning of spam addressed to > > nanog at nanog.org :( > > > > Ditto. Getting lots of crap here. > > William > From Phi at LGonQn.Org Tue Jul 12 06:30:19 2011 From: Phi at LGonQn.Org (XPhi) Date: Tue, 12 Jul 2011 07:30:19 -0400 Subject: NANOG List Update - Moving Forward? In-Reply-To: References: Message-ID: <4E1C304B.60605@LGonQn.Org> Hi Also seeing a gross amount of spam from list and my "digest" setting has been lost apparently. Sigh C From jlewis at lewis.org Tue Jul 12 07:44:57 2011 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 12 Jul 2011 08:44:57 -0400 (EDT) Subject: NANOG List Update - Moving Forward In-Reply-To: References: Message-ID: On Tue, 12 Jul 2011, Mikael Abrahamsson wrote: > On Tue, 12 Jul 2011, Michael K. Smith - Adhost wrote: > >> If you have any questions or concerns please let me know. > > The new posts do not have list (un)subscribe information in the headers. Also, the headers now no longer include the origin of messages. i.e. the new mailing list manager is throwing away all Received: lines such that if I look at the message headers, all I know is the mail came to me through amsl.com. So with the spam getting through now, there's no way for list members to see where it actually came from. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jgreco at ns.sol.net Tue Jul 12 07:14:04 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 12 Jul 2011 07:14:04 -0500 (CDT) Subject: NANOG List Update - Moving Forward In-Reply-To: Message-ID: <201107121214.p6CCE4ji006220@aurora.sol.net> > On Tue, 12 Jul 2011, Michael K. Smith - Adhost wrote: > > > If you have any questions or concerns please let me know. > > The new posts do not have list (un)subscribe information in the headers. I'll offer an evenhanded comment in that it's frustrating that the headers used have changed, since some of us key procmail off of them to split mailing lists into folders, but it *is* nice to see that the current NANOG mailing list team has been supporting List-Id for some time now, and that such was propagated properly between old and new host. Good job. Unfortunately my filter predates NANOG's use of that so now I gotta go fix it here. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From feldman at twincreeks.net Tue Jul 12 09:00:51 2011 From: feldman at twincreeks.net (Steve Feldman) Date: Tue, 12 Jul 2011 07:00:51 -0700 Subject: NANOG List Update - Moving Forward In-Reply-To: References: <20110712063235.36b02a11@petrie> Message-ID: <1BE304A1-0DA0-4558-83AD-0E4F08F8146D@twincreeks.net> We're aware of the spam problem and have our top people working on it. Reports of other lingering issues from the change would be appreciated, though. Thanks, Steve On Jul 12, 2011, at 5:03 AM, jim deleskie wrote: > +1 > > On Tue, Jul 12, 2011 at 8:32 AM, William Pitcock > wrote: >> On Tue, 12 Jul 2011 10:50:38 +0100 (BST) >> Tim Franklin wrote: >> >>>> Thankfully, the current test has been a success. >>> >>> Including stopping non-members from posting to the list, and other >>> anti-spam? >>> >>> I've got a sudden influx this morning of spam addressed to >>> nanog at nanog.org :( >>> >> >> Ditto. Getting lots of crap here. >> >> William >> > From jeroen at unfix.org Tue Jul 12 04:49:30 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 12 Jul 2011 11:49:30 +0200 Subject: Can somebody stop nanog@nanog.org from forwarding spam, kthx! Message-ID: <4E1C18AA.4090503@unfix.org> I am fairly sure that the fake "Western Union" message and various other spams that are dripping through are from real subscribers... Also, as somebody decided to drop mailman and replace it by 'bulk_mailer v1.13' maybe one should start fixing that software also to add the List-* headers aka RF2369 headers before we get a flood of 'I want to unsubscribe!' kind of messages, as currently there are no details in the message... Greets, Jeroen -- Return-Path: [..] Received: by c1a.amsl.com (Postfix, from userid 65534) id 8827E1C39C0D; Tue, 12 Jul 2011 01:56:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c1a.amsl.com (Postfix) with SMTP id 859251C39C0C; Tue, 12 Jul 2011 01:56:17 -0700 (PDT) Received: by nanog.org (bulk_mailer v1.13); Tue, 12 Jul 2011 01:56:13 -0700 X-Virus-Scanned: amavisd-new at amsl.com Authentication-Results: c1a.amsl.com (amavisd-new); dkim=pass header.i=@yahoo.com by localhost (c1a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57kfPoQcM1II for ; Tue, 12 Jul 2011 01:55:54 -0700 (PDT) by c1a.amsl.com (Postfix) with ESMTPS id D6F391C39502 for ; Tue, 12 Jul 2011 01:55:53 -0700 (PDT) by s0.nanog.org with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QgYTR-000O9p-FX for nanog at nanog.org; Tue, 12 Jul 2011 08:37:46 +0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 599896.49560.bm at omp1019.access.mail.sp2.yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1310459863; bh=kV1F/5fAMRswMRBHHPz7BAoiVx+V1whaOXmIw6DNpoQ=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=HaBDhJm8t+WHLeZ9JYMQWuC9hraN+xVQEYPlAaLG5M1vCXflWFCFCt+AWleOQRuc1063jgI5P0CYfpY4XAloY0FTwceXSntuo6fqmUgFQ2v9tCYxkWg0Z5/L5iy9utw73OrZ2FpYmcHB1fjNwLAeM/QiIUSKBQWyaoag5bUPZ6w= X-YMail-OSG: w33eh74VM1mZnVdAav_H6n4sKFUZGa.HTRs7c0RtQrPA6zT b9YAb0Nqk2hDHJXSi9J2XdgJeCrLtDQnz4_JjZLcBN9vSDIynSh.eD8rT_KB sYUe92vhC5f70p25BnhFd9ZsKvZVbSygr991WfCYWWyJKLzWr1d.FJlk2ogS Hz0Sz56HiSGhHBadGZbno1k3XkNSvWg5f5vnX8hgYzVbL4wHxz8mC3KtqQoj L3rC0WGp_k.5dnNQIOWcv56QpJ9qSiA02nP9Ac_DfUJ_VdheCcZjA13Ncr7J wrd73Iqvr1LMQmLuijPB16fgXHlMwaZZMo0xckq0tYzvb8AHHKWaa7YqyrsH VZoGenVnEe530zbxQqpDB7Jg5N4KoFs8K4xQBItr3sZdLHOKX6OndA2jLoeY sgs_p03CutbV_VggXh7KsOPVyWg-- X-RocketYMMF: webbmb at att.net X-Mailer: YahooMailRC/572 YahooMailWebService/0.8.112.307740 Message-ID: <1310459863.39197.YahooMailRC at web180907.mail.ne1.yahoo.com> Date: Tue, 12 Jul 2011 01:37:43 -0700 (PDT) From: Western Union Award Subject: THANK YOU FOR USING WESTERN UNION!!!KINDLY OPEN THE ATTACHMENT, To: undisclosed recipients: ; MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-2023431952-1310459863=:39197" Reply-to: wu001122 at hotmail.com X-C5I-RSN: 22/0/1041/6659/37972 X-C5I-Spamscore: -4.00 List-Id: North American Network Operators Group Precedence: list --0-2023431952-1310459863=:39197 Content-Type: multipart/alternative; boundary="0-1056351656-1310459863=:39197" --0-1056351656-1310459863=:39197 Content-Type: text/plain; charset=us-ascii THANK YOU FOR USING WESTERN UNION!!!KINDLY OPEN THE ATTACHMENT, From mattias at ahnberg.pp.se Tue Jul 12 05:48:05 2011 From: mattias at ahnberg.pp.se (Mattias Ahnberg) Date: Tue, 12 Jul 2011 12:48:05 +0200 Subject: NANOG List Update - Moving Forward In-Reply-To: References: Message-ID: <4E1C2665.1060704@ahnberg.pp.se> On 2011-07-12 07:19, Michael K. Smith - Adhost wrote: > If you have any questions or concerns please let me know. I miss proper List-Id headers for identifying and filtering the list easily. I might have missed some discussion; but why are we moving away from mailman, and what software is in the new system? -- /ahnberg. From paul at paulgraydon.co.uk Tue Jul 12 03:59:40 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Mon, 11 Jul 2011 22:59:40 -1000 Subject: Spam? Message-ID: <4E1C0CFC.70505@paulgraydon.co.uk> New location means we now get spam on Nanog? Could we go back to the old place? From mattias at ahnberg.pp.se Tue Jul 12 09:13:10 2011 From: mattias at ahnberg.pp.se (Mattias Ahnberg) Date: Tue, 12 Jul 2011 16:13:10 +0200 Subject: NANOG List Update - Moving Forward In-Reply-To: References: Message-ID: <4E1C5676.9050907@ahnberg.pp.se> On 2011-07-12 07:19, Michael K. Smith - Adhost wrote: > If you have any questions or concerns please let me know. I miss proper List-Id headers for identifying and filtering the list easily. I might have missed some discussion; but why are we moving away from mailman, and what software is in the new system? -- /ahnberg. From tim at pelican.org Tue Jul 12 09:15:06 2011 From: tim at pelican.org (Tim Franklin) Date: Tue, 12 Jul 2011 15:15:06 +0100 (BST) Subject: NANOG List Update - Moving Forward In-Reply-To: Message-ID: <8d2518d0-f345-488c-924d-5a16be7e8801@jennyfur.pelican.org> ----- Original Message ----- > The new posts do not have list (un)subscribe information in the > headers. Also, a statement would be nice as to what header definitely *will* be in place that we can filter on. At the moment, I'm assuming 'List-ID', but I'm not sure if that header or its contents can be relied on. Regards, Tim. From gtaylor at riverviewtech.net Tue Jul 12 09:20:50 2011 From: gtaylor at riverviewtech.net (Grant Taylor) Date: Tue, 12 Jul 2011 09:20:50 -0500 Subject: NANOG List Update - Moving Forward In-Reply-To: References: Message-ID: <4E1C5842.40402@riverviewtech.net> On 07/12/11 03:21, Mikael Abrahamsson wrote: > The new posts do not have list (un)subscribe information in the headers. Also, subscriptions that were set to no mail delivery are now delivering mail. Is this expected? Grant. . . . From jeroen at unfix.org Tue Jul 12 09:22:44 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 12 Jul 2011 16:22:44 +0200 Subject: NANOG Move - Moved back In-Reply-To: References: Message-ID: <4E1C58B4.80007@unfix.org> On 2011-07-12 15:59 , Michael K. Smith - Adhost wrote: > Hello All: > > We're back on the old configuration for now. I will send an update later > this afternoon once I speak with AMS about the issues we experienced over > night. What is the reason for dropping mailman btw? The IETF, which is also taking secretarial services and hosting etc from AMSL still have it... Greets, Jeroen From shrdlu at deaddrop.org Tue Jul 12 09:25:14 2011 From: shrdlu at deaddrop.org (Lynda) Date: Tue, 12 Jul 2011 07:25:14 -0700 Subject: NANOG Move - Moved back In-Reply-To: References: Message-ID: <4E1C594A.8020106@deaddrop.org> On 7/12/2011 6:59 AM, Michael K. Smith - Adhost wrote: > Hello All: > > We're back on the old configuration for now. I will send an update later > this afternoon once I speak with AMS about the issues we experienced over > night. Please explain WHY we can't just stay on Mailman? I know you explained it privately to me already, but none of those reasons are seeming very good right now. Mailman was working, just fine. You are making me very sad, and I haven't had enough coffee to be polite. -- Requiescat in Pacem, Len http://en.wikipedia.org/wiki/Len_Sassaman From ben at bencarleton.com Tue Jul 12 09:35:01 2011 From: ben at bencarleton.com (Ben Carleton) Date: Tue, 12 Jul 2011 10:35:01 -0400 (EDT) Subject: NANOG List Update - Moving Forward In-Reply-To: <1BE304A1-0DA0-4558-83AD-0E4F08F8146D@twincreeks.net> References: <20110712063235.36b02a11@petrie> <1BE304A1-0DA0-4558-83AD-0E4F08F8146D@twincreeks.net> Message-ID: <1310481301.239130535@apps.rackspace.com> Steve, I'm seeing the following issues, also as reported by others: * No RFC 2369 headers means a fun time filtering and no unsubscribe info (maybe that one is on purpose? :) I kid!) * The mailing list is stripping out all Received: headers from prior to the message hitting the listserver * For me at least, messages seem to be delivered out of order - I received this message almost immediately, but messages from 2 hours ago are still making their way into my mailbox. This was not occurring before and it's not a problem with my mail provider. Warm regards, Ben -----Original Message----- From: "Steve Feldman" Sent: Tuesday, July 12, 2011 10:00am To: deleskie at gmail.com Cc: "NANOG list" Subject: Re: NANOG List Update - Moving Forward We're aware of the spam problem and have our top people working on it. Reports of other lingering issues from the change would be appreciated, though. Thanks, Steve On Jul 12, 2011, at 5:03 AM, jim deleskie wrote: > +1 > > On Tue, Jul 12, 2011 at 8:32 AM, William Pitcock > wrote: >> On Tue, 12 Jul 2011 10:50:38 +0100 (BST) >> Tim Franklin wrote: >> >>>> Thankfully, the current test has been a success. >>> >>> Including stopping non-members from posting to the list, and other >>> anti-spam? >>> >>> I've got a sudden influx this morning of spam addressed to >>> nanog at nanog.org :( >>> >> >> Ditto. Getting lots of crap here. >> >> William >> > From gerry at tape.net Tue Jul 12 09:39:16 2011 From: gerry at tape.net (Gerry Boudreaux) Date: Tue, 12 Jul 2011 09:39:16 -0500 Subject: NANOG List Update - Moving Forward In-Reply-To: References: Message-ID: On Jul 12, 2011, at 00:19 , Michael K. Smith - Adhost wrote: > Mailman is shut down on s0.nanog.org and mail is being routed directly to > mail.amsl.com where it is being processed by our new list (etc.) system. Will the list archives migrate? What about future list archives? Thanks G From elmi at 4ever.de Tue Jul 12 09:43:34 2011 From: elmi at 4ever.de (Elmar K. Bins) Date: Tue, 12 Jul 2011 16:43:34 +0200 Subject: Can somebody stop nanog@nanog.org from forwarding spam, kthx! In-Reply-To: <4E1C18AA.4090503@unfix.org> References: <4E1C18AA.4090503@unfix.org> Message-ID: <20110712144334.GJ90543@ronin.4ever.de> jeroen at unfix.org (Jeroen Massar) wrote: > I am fairly sure that the fake "Western Union" message and various other > spams that are dripping through are from real subscribers... Err... what I find most interesting is that I have received no spam via this list today. I've checked my spamfilters' garbage heap... Did someone unsubscribe me from the spam part of the list? Thank you :) Elmar. From cjp at 0x1.net Tue Jul 12 09:45:26 2011 From: cjp at 0x1.net (Christopher J. Pilkington) Date: Tue, 12 Jul 2011 10:45:26 -0400 Subject: NANOG List Update - Moving Forward In-Reply-To: References: Message-ID: On Tue, Jul 12, 2011 at 1:19 AM, Michael K. Smith - Adhost wrote: > Thankfully, the current test has been a success. ?We are going to stay in Hooray for testing in production. -cjp From randy at psg.com Tue Jul 12 09:45:36 2011 From: randy at psg.com (Randy Bush) Date: Tue, 12 Jul 2011 23:45:36 +0900 Subject: Spam? In-Reply-To: <4E1C0CFC.70505@paulgraydon.co.uk> References: <4E1C0CFC.70505@paulgraydon.co.uk> Message-ID: > New location means we now get spam on Nanog? no extra charge :) i have lived through maintaing decades of mailing lists and do not envy the nanog mailing list crew and glen over at amsl. thanks for the hard work, folk. randy From fergdawgster at gmail.com Tue Jul 12 09:58:42 2011 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 12 Jul 2011 07:58:42 -0700 Subject: Spam? In-Reply-To: References: <4E1C0CFC.70505@paulgraydon.co.uk> Message-ID: On Tue, Jul 12, 2011 at 7:45 AM, Randy Bush wrote: >> New location means we now get spam on Nanog? > > no extra charge :) > > i have lived through maintaing decades of mailing lists and do not envy > the nanog mailing list crew and glen over at amsl. > > thanks for the hard work, folk. > Let's work harder -- seriously, MailMan seemed to be working fine. ~:-/ - ferg -- "Fergie", a.k.a. Paul Ferguson ?Engineering Architecture for the Internet ?fergdawgster(at)gmail.com ?ferg's tech blog: http://fergdawg.blogspot.com/ From randy at psg.com Tue Jul 12 09:59:15 2011 From: randy at psg.com (Randy Bush) Date: Tue, 12 Jul 2011 23:59:15 +0900 Subject: NANOG List Update - Moving Forward In-Reply-To: References: Message-ID: >> Thankfully, the current test has been a success. ?We are going to >> stay in > Hooray for testing in production. we are not dealing with stupid or inexperienced people here. i assume they tested. but, like our beloved vendors, they also have a hard time reproducing the real network in the lab, so we end up debugging it for them. otoh, i am willing to wager that in a few weeks, we will not see bugs in the list. sure can't say the same for the vendors. randy From randy at psg.com Tue Jul 12 10:00:21 2011 From: randy at psg.com (Randy Bush) Date: Wed, 13 Jul 2011 00:00:21 +0900 Subject: Spam? In-Reply-To: References: <4E1C0CFC.70505@paulgraydon.co.uk> Message-ID: >> thanks for the hard work, folk. > Let's work harder thanks for volunteering. when will you be flying out to the bay? randy From fergdawgster at gmail.com Tue Jul 12 10:01:49 2011 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 12 Jul 2011 08:01:49 -0700 Subject: Spam? In-Reply-To: References: <4E1C0CFC.70505@paulgraydon.co.uk> Message-ID: On Tue, Jul 12, 2011 at 8:00 AM, Randy Bush wrote: >>> thanks for the hard work, folk. >> Let's work harder > > thanks for volunteering. ?when will you be flying out to the bay? > I already live in The Bay Area. Is there an 'revert' button? - ferg -- "Fergie", a.k.a. Paul Ferguson ?Engineering Architecture for the Internet ?fergdawgster(at)gmail.com ?ferg's tech blog: http://fergdawg.blogspot.com/ From tad1214 at gmail.com Tue Jul 12 10:02:00 2011 From: tad1214 at gmail.com (Thomas Donnelly) Date: Tue, 12 Jul 2011 10:02:00 -0500 Subject: Spam? In-Reply-To: References: <4E1C0CFC.70505@paulgraydon.co.uk> Message-ID: I received no spam, and had I received 2 pieces, it may have been slightly irritating. What is irritating is the sheer number of people complaining about it. Can we stop please? I think they get it. -=Tom On Tue, 12 Jul 2011 09:58:42 -0500, Paul Ferguson wrote: > On Tue, Jul 12, 2011 at 7:45 AM, Randy Bush wrote: > >>> New location means we now get spam on Nanog? >> >> no extra charge :) >> >> i have lived through maintaing decades of mailing lists and do not envy >> the nanog mailing list crew and glen over at amsl. >> >> thanks for the hard work, folk. >> > > Let's work harder -- seriously, MailMan seemed to be working fine. ~:-/ > > - ferg > > -- Using Opera's revolutionary email client: http://www.opera.com/mail/ From fergdawgster at gmail.com Tue Jul 12 10:04:17 2011 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 12 Jul 2011 08:04:17 -0700 Subject: NANOG List Update - Moving Forward In-Reply-To: References: Message-ID: On Tue, Jul 12, 2011 at 7:59 AM, Randy Bush wrote: >>> Thankfully, the current test has been a success. ?We are going to >>> stay in >> Hooray for testing in production. > > we are not dealing with stupid or inexperienced people here. ?i assume > they tested. > > but, like our beloved vendors, they also have a hard time reproducing > the real network in the lab, so we end up debugging it for them. ?otoh, > i am willing to wager that in a few weeks, we will not see bugs in the > list. ?sure can't say the same for the vendors. > Please -- give it a rest. And let's take this thread to it's ultimate conclusion, please. - ferg -- "Fergie", a.k.a. Paul Ferguson ?Engineering Architecture for the Internet ?fergdawgster(at)gmail.com ?ferg's tech blog: http://fergdawg.blogspot.com/ From bonomi at mail.r-bonomi.com Tue Jul 12 10:07:44 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Tue, 12 Jul 2011 10:07:44 -0500 (CDT) Subject: NANOG List Update - Moving Forward Message-ID: <201107121507.p6CF7i7h033220@mail.r-bonomi.com> Cc: nanog at nanog.org.r-bonomi.com In-Reply-To: <1BE304A1-0DA0-4558-83AD-0E4F08F8146D at twincreeks.net> > Subject: Re: NANOG List Update - Moving Forward > From: Steve Feldman > Date: Tue, 12 Jul 2011 07:00:51 -0700 > > We're aware of the spam problem and have our top people working on it. > > Reports of other lingering issues from the change would be appreciated, > though. You asked for it, you got it: 1) You broke *all* the mailing-list support addresses. 'nanog-owner' ,etc. *BOUNCE* "user unknown" see mark's inbox for a smoking gun 2) You let non-members post to the list. see mark's inbox for a smoking gun 3) You broke the mailing-list *submission* address itself, for subscribers. Although you let non-member *SPAM* through. 4) You have dropped _all_ the the received lines _before_ the message gets to the list. see mark's inbox for a smoking gun -- one of the spam messages 5) You are *NOT* using 'custom 'From ' lines, meaning you cannot tell who the subscriber is when a forwarded message bounces. see mark's inbox for a smoking gun -- one of the spam messages 6) You dropped *ALL* the list-management info headers. see mark's inbox for a smoking gun -- one of the spam messages 7) You rolled changes out with _NOBODY_AROUND_ to take complaints from users who noticed problems. 8) You are mailing to "undisclosed recipients". This indicates "less than competent", *lazy*, mailing-list management practices. AND making it impossible for the recipient to determine _what_ e-mail address the message was actually sent to, *if* for instance they need to change their subscription information on a 'forwarded' (or worse, _multiply-forwarded_) subscription address. see mark's inbox for a smoking gun -- one of the spam messages 9) Others report you lost some, if not all, of the established mailing 'preferences' for subscribers. *AND* all this was on the *second* attempt, having already utterly botched the first one. Reports were being sent to Mark's email (he who posted the announcement, the 'test' and the notice saying things were 'apparently working') roughly 2-1/2 hours after the -first- problem surfaced. SIX hours later the problem was still occuring. "Asleep at the switch" would seem to apply. Considering =ALL= of the above the statement that you have your "top people" working on the matter is not in the least reasurring. One *also* has to "wonder" -- considering all the other things that were 'lost', if the existing suppression filters -- specifically those which keep 'banned' traffic off the list -- were *also* 'lost'. One _really_ has to wonder "why" things are being moved off a tested, reliable, and fully reliable platform, to an "obviously" flawed implementation. Methinks the decision-makers owe the list subscribers _some_ explanation with regard to the 'advantages' to be gained by this migration, and why it is necessary. From jason at thebaughers.com Tue Jul 12 10:08:09 2011 From: jason at thebaughers.com (Jason Baugher) Date: Tue, 12 Jul 2011 10:08:09 -0500 Subject: Spam? In-Reply-To: References: <4E1C0CFC.70505@paulgraydon.co.uk> Message-ID: <4E1C6359.40303@thebaughers.com> On 7/12/2011 10:00 AM, Randy Bush wrote: >>> thanks for the hard work, folk. >> Let's work harder > thanks for volunteering. when will you be flying out to the bay? > > randy > > I'm with you Randy, I'm disappointed with the complaints I see here. People don't seem to show much appreciation. Jason From bmanning at vacation.karoshi.com Tue Jul 12 10:24:31 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 12 Jul 2011 15:24:31 +0000 Subject: AMSL vs the ex-incument Message-ID: <20110712152431.GA1895@vacation.karoshi.com.> AMSL has a number of interesting operational choices in its handling of email. Lets see if they are willing to take the email from a NANOG supporter (fiscally). /bill From rbonica at juniper.net Tue Jul 12 10:28:58 2011 From: rbonica at juniper.net (Ronald Bonica) Date: Tue, 12 Jul 2011 11:28:58 -0400 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: <20110711193508.GA97493@ussenterprise.ufp.org> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> Leo, Maybe we can fix this by: a) bringing together larger groups of clueful operators in the IETF b) deciding which issues interest them c) showing up and being vocal as a group in protocol developing working groups To some degree, we already do this in the IETF OPS area, but judging by your comments, we don't do it nearly enough. Comments? Ron -----Original Message----- From: Leo Bicknell [mailto:bicknell at ufp.org] Sent: Monday, July 11, 2011 3:35 PM To: nanog at nanog.org Subject: Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In a message written on Sun, Jul 10, 2011 at 06:16:09PM +0200, Jeroen Massar wrote: > Ehmmmm ANYBODY, including you, can sign up to the IETF mailing lists > and participate there, just like a couple of folks from NANOG are already doing. The way the IETF and the operator community interact is badly broken. The IETF does not want operators in many steps of the process. If you try to bring up operational concerns in early protocol development for example you'll often get a "we'll look at that later" response, which in many cases is right. Sometimes you just have to play with something before you worry about the operational details. It also does not help that many operational types are not hardcore programmers, and can't play in the sandbox during the major development cycles. From bicknell at ufp.org Tue Jul 12 10:42:02 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 12 Jul 2011 08:42:02 -0700 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> Message-ID: <20110712154202.GA45271@ussenterprise.ufp.org> In a message written on Tue, Jul 12, 2011 at 11:28:58AM -0400, Ronald Bonica wrote: > Maybe we can fix this by: > > a) bringing together larger groups of clueful operators in the IETF > b) deciding which issues interest them > c) showing up and being vocal as a group in protocol developing working groups > > To some degree, we already do this in the IETF OPS area, but judging by your comments, we don't do it nearly enough. I don't think it's that simple, sadly. I'll no doubt get flamed by the 5 people on NANOG that also participate in the IETF in a regular basis, but the reality is most operators don't want to sit through multi-year protocol devopment work, or have much of anything to do with "pie in the sky" ideas. The IETF can, should, and does do both of those things today. Where the friction occurs is there is no good place to loop the operators back in, so they are often kicked out, discouraged, or just uninterested on the front end (we're going to go play with new ideas kids!) and then not brought back in (it's ready for deployment, wait, why are no operators interested). So it's not that individual issues are of interest to operators (outside of the IETF OPS area, which is a special case), it's that the process needs work. I'll pick on LISP as an example, since many operators are at least aware of it. Some operators have said we need a locator and identifier split. Interesting feedback. The IETF has gone off and started playing in the sandbox, trying to figure out how to make that go. Several years of coding have occured, a bunch of proof of concept testing is going on. Even many of the operators who wanted such a spit are not really interested in following the details of the work right now. Of course, if you are, you can, I'm not advocating any exclusions. But there is no roadmap in the IETF process now for LISP that says "We've got this 90% baked, we need to circulate a draft to the NANOG mailing list, request operator comments, and actively solicit operators to participate in the expanded test network". We need that mechanism to tell folks "hey, it's real enough your operational feedback is now useful" and "come test our new idea". Today the IETF just finishes their work, "tosses it over the wall" and hopes for the best. Generally it's not 100%, and vendors make propretary changes to the standards slowly over time to meet the needs of operators. It would be far better if there was at least one round of "ask the operators" and incorproate feedback before it went over the wall, and in paricular before working groups disbanded. In short, make it easy for the operators to participate at the right time in the process. It will be better for everyone! -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From cb.list6 at gmail.com Tue Jul 12 10:43:59 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Tue, 12 Jul 2011 08:43:59 -0700 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> Message-ID: On Tue, Jul 12, 2011 at 8:28 AM, Ronald Bonica wrote: > Leo, > > Maybe we can fix this by: > > a) bringing together larger groups of clueful operators in the IETF > b) deciding which issues interest them > c) showing up and being vocal as a group in protocol developing working groups > > To some degree, we already do this in the IETF OPS area, but judging by your comments, we don't do it nearly enough. > > Comments? > There may be an OPS area, but it is not listened to. Witness the latest debacle with the attempt at trying to make 6to4 historic. Various "non-practicing entities" were able to derail what network operators largely supported. Since the IETF failed to make progress operators will do other things to stop 6to4 ( i have heard no AAAA over IPv4 transport, blackhole 6to4 anycast, decom relay routers...) Real network operators have a relatively low BS threshold, they have customers to support and businesses to run, and they don't have thumb wrestle these people who don't actually have any skin in the game. Cameron > ? ? ? ? ? ? ? Ron > > > -----Original Message----- > From: Leo Bicknell [mailto:bicknell at ufp.org] > Sent: Monday, July 11, 2011 3:35 PM > To: nanog at nanog.org > Subject: Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?) > > In a message written on Sun, Jul 10, 2011 at 06:16:09PM +0200, Jeroen Massar wrote: >> Ehmmmm ANYBODY, including you, can sign up to the IETF mailing lists >> and participate there, just like a couple of folks from NANOG are already doing. > > The way the IETF and the operator community interact is badly broken. > > The IETF does not want operators in many steps of the process. ?If you try to bring up operational concerns in early protocol development for example you'll often get a "we'll look at that later" response, which in many cases is right. ?Sometimes you just have to play with something before you worry about the operational details. ?It also does not help that many operational types are not hardcore programmers, and can't play in the sandbox during the major development cycles. > > > > From james.cutler at consultant.com Tue Jul 12 10:45:29 2011 From: james.cutler at consultant.com (Cutler James R) Date: Tue, 12 Jul 2011 11:45:29 -0400 Subject: Spam? In-Reply-To: References: <4E1C0CFC.70505@paulgraydon.co.uk> Message-ID: On Jul 12, 2011, at 11:02 AM, Thomas Donnelly wrote: > I received no spam, and had I received 2 pieces, it may have been slightly irritating. > > What is irritating is the sheer number of people complaining about it. Can we stop please? I think they get it. > > -=Tom > Tom, you are one of the lucky ones -- I have received over two dozen SPAM via NANOG in the last 24 hours. And, yes, it would be gratifying to know why the change - is the new configuration less expensive? (to the list manager, not us, obviously) Also, where is the reply to header? James R. Cutler james.cutler at consultant.com From paradox at nac.net Tue Jul 12 10:47:11 2011 From: paradox at nac.net (Ryan Pavely) Date: Tue, 12 Jul 2011 11:47:11 -0400 Subject: Can somebody stop nanog@nanog.org from forwarding spam, kthx! In-Reply-To: <20110712144334.GJ90543@ronin.4ever.de> References: <4E1C18AA.4090503@unfix.org> <20110712144334.GJ90543@ronin.4ever.de> Message-ID: <4E1C6C7F.6040504@nac.net> As far as I can tell me neither. I feel so left out :( Ryan Pavely Director Research And Development Net Access Corporation http://www.nac.net/ On 7/12/2011 10:43 AM, Elmar K. Bins wrote: > jeroen at unfix.org (Jeroen Massar) wrote: > >> I am fairly sure that the fake "Western Union" message and various other >> spams that are dripping through are from real subscribers... > Err... > what I find most interesting is that I have received no spam via this list > today. I've checked my spamfilters' garbage heap... > > Did someone unsubscribe me from the spam part of the list? Thank you :) > > Elmar. From tprophet at tprophet.org Tue Jul 12 10:50:01 2011 From: tprophet at tprophet.org (TProphet) Date: Tue, 12 Jul 2011 23:50:01 +0800 Subject: Myspace contact needed In-Reply-To: <0FBA884762114F49A1132BE7C36BB050FE23A8@stellarrad.RainierConnect.local> References: <4E1B955F.7010807@rainierconnect.net><5234b2c8-26b3-4925-a2da-a0106fc31a5e@blur> <0FBA884762114F49A1132BE7C36BB050FE23A8@stellarrad.RainierConnect.local> Message-ID: <4E1C6D29.3070503@tprophet.org> I use a VPN from Beijing, where I reside. It's pretty common for myspace to blacklist any IP addresses that they believe belong to crawlers, linkbots, VPN services, etc. This appears to be an automated process. I've never had luck getting any of my VPN IPs unblocked. Good luck getting in touch with anyone there, the company was just sold to a consortium of celebrities after massive News Corp. layoffs and it's left with walking zombies. I'd be surprised if anyone competent is still left... -TProphet On 7/12/2011 9:49 PM, Walter Keen wrote: > > Sorry about the lack of details. > > I'm looking for a Myspace contact, We're an ISP (AS20394) and all of our > users are getting a 302 redirect to google after contacting a myspace > server. If there is an appropriate contact on this list, or someone who > can forward this to such a contact, it would be greatly appreciated. > I don't have this issue from other ISP connections(such as my home > connection), but have not heard back from the website support portal as > of yet. > > > > > wkeen at tnwx-nms-3:~$ traceroute www.myspace.com > traceroute to www.myspace.com (216.178.39.11), 30 hops max, 40 byte packets > 1 tnwx-core-1.rainierconnect.com (69.10.208.1) 0.409 ms 0.479 ms 0.559 ms > 2 74.50.203.97 (74.50.203.97) 1.772 ms 1.769 ms 1.805 ms > 3 ge5-0-2d0.cir1.seattle7-wa.us.xo.net (216.156.100.41) 1.703 ms 1.708 > ms 1.707 ms > 4 4.59.232.53 (4.59.232.53) 2.064 ms 2.067 ms 2.056 ms > 5 ae-31-51.ebr1.Seattle1.Level3.net (4.69.147.150) 11.408 ms 11.374 ms > 11.484 ms > 6 ae-7-7.ebr2.SanJose1.Level3.net (4.69.132.49) 19.095 ms 18.870 ms > 18.997 ms > 7 ae-34-34.ebr4.SanJose1.Level3.net (4.69.153.34) 20.638 ms 30.373 ms > 30.333 ms > 8 ae-5-5.ebr2.SanJose5.Level3.net (4.69.148.141) 19.631 ms 19.813 ms > 19.803 ms > 9 ae-6-6.ebr2.LosAngeles1.Level3.net (4.69.148.201) 29.283 ms 28.981 ms > 29.246 ms > 10 ae-62-62.csw1.LosAngeles1.Level3.net (4.69.137.18) 29.091 ms > ae-72-72.csw2.LosAngeles1.Level3.net (4.69.137.22) 29.461 ms 29.437 ms > 11 ae-24-70.car4.LosAngeles1.Level3.net (4.69.144.70) 29.684 ms > ae-44-90.car4.LosAngeles1.Level3.net (4.69.144.198) 29.562 ms > ae-14-60.car4.LosAngeles1.Level3.net (4.69.144.6) 29.680 ms > 12 ve202.lax.myspace.com (4.71.128.10) 29.351 ms 28.998 ms 29.203 ms > 13 vl342.cs2.lax1.myspace.com (204.16.35.137) 29.431 ms 29.540 ms 29.638 ms > 14 vl3552.cs2.els2.myspace.com (216.178.35.77) 29.970 ms 29.717 ms 29.726 ms > 15 * * * > 16 * * * > 17 * * * > 18 * * * > 19 * * * > > wkeen at tnwx-nms-3:~$ wget www.myspace.com > --2011-07-12 06:45:32-- http://www.myspace.com/ > Resolving www.myspace.com... 63.135.80.46 > Connecting to www.myspace.com|63.135.80.46|:80... connected. > HTTP request sent, awaiting response... 302 Found > Location: http://www.google.com [following] > --2011-07-12 06:45:32-- http://www.google.com/ > Resolving www.google.com... 72.14.213.106, 72.14.213.147, 72.14.213.99, ... > Connecting to www.google.com|72.14.213.106|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: unspecified [text/html] > Saving to: `index.html.5' > > [ <=> ] 9,908 --.-K/s in 0.009s > > 2011-07-12 06:45:32 (1.01 MB/s) - `index.html.5' saved [9908] > > wkeen at tnwx-nms-3:~$ > > > > wrote: > > My apologies all, I meant to say myspace contact > > > > You're more likely to get a response if you give some indication > of what the issue is; for example, saying "I'm looking for a MySpace > contact because there is an attack coming from their servers that > appears to indicate they may have been compromised" will likely > get you a faster reaction from the security people. Or, if it's a > network issue, saying "I'm looking for a MySpace network contact > because it appears they are announcing the following blocks which > really belong to me, which is causing reachability issues" will more > likely get you a reaction from an appropriate network person. > > Without an indication of the nature of the problem, I think you'll find > most people on the list tend to ignore generic requests like this. > > Thanks! > > Matt > From randy at psg.com Tue Jul 12 10:50:59 2011 From: randy at psg.com (Randy Bush) Date: Wed, 13 Jul 2011 00:50:59 +0900 Subject: Spam? In-Reply-To: References: <4E1C0CFC.70505@paulgraydon.co.uk> Message-ID: > Also, where is the reply to header? still in the garbage, where it belongs From bruns at 2mbit.com Tue Jul 12 10:52:19 2011 From: bruns at 2mbit.com (Brielle Bruns) Date: Tue, 12 Jul 2011 09:52:19 -0600 Subject: Can somebody stop nanog@nanog.org from forwarding spam, kthx! In-Reply-To: <4E1C6C7F.6040504@nac.net> References: <4E1C18AA.4090503@unfix.org> <20110712144334.GJ90543@ronin.4ever.de> <4E1C6C7F.6040504@nac.net> Message-ID: <4E1C6DB3.1020303@2mbit.com> On 7/12/11 9:47 AM, Ryan Pavely wrote: > As far as I can tell me neither. I feel so left out :( > > You probably don't have nanog at nanog.org and its associated mail servers whitelisted in spamassassin/filtering/etc. In an effort to avoid bouncing list mail, I put them in a while back. Unfortunately, side effect is exactly what happened last night. :) -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From cb.list6 at gmail.com Tue Jul 12 10:53:16 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Tue, 12 Jul 2011 08:53:16 -0700 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: <20110712154202.GA45271@ussenterprise.ufp.org> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> Message-ID: On Tue, Jul 12, 2011 at 8:42 AM, Leo Bicknell wrote: > In a message written on Tue, Jul 12, 2011 at 11:28:58AM -0400, Ronald Bonica wrote: >> Maybe we can fix this by: >> >> a) bringing together larger groups of clueful operators in the IETF >> b) deciding which issues interest them >> c) showing up and being vocal as a group in protocol developing working groups >> >> To some degree, we already do this in the IETF OPS area, but judging by your comments, we don't do it nearly enough. > > I don't think it's that simple, sadly. ?I'll no doubt get flamed > by the 5 people on NANOG that also participate in the IETF in a > regular basis, but the reality is most operators don't want to sit > through multi-year protocol devopment work, or have much of anything > to do with "pie in the sky" ideas. > > The IETF can, should, and does do both of those things today. ?Where the > friction occurs is there is no good place to loop the operators back in, > so they are often ?kicked out, discouraged, or just uninterested on the > front end (we're going to go play with new ideas kids!) and then not > brought back in (it's ready for deployment, wait, why are no operators > interested). > > So it's not that individual issues are of interest to operators (outside > of the IETF OPS area, which is a special case), it's that the process > needs work. > > I'll pick on LISP as an example, since many operators are at least > aware of it. ?Some operators have said we need a locator and identifier > split. ?Interesting feedback. ?The IETF has gone off and started > playing in the sandbox, trying to figure out how to make that go. > Several years of coding have occured, a bunch of proof of concept > testing is going on. ?Even many of the operators who wanted such a spit > are not really interested in following the details of the work right > now. ?Of course, if you are, you can, I'm not advocating any exclusions. > W.R.T. to LISP, in defense of the IETF or the IRTF, i do not believe "the IETF" has told the world that LISP is the best fit for the Internet or solves any specific problem well. The IETF has never said the "Internet Architecture" is going to LISP, and it likely will not / cannot. My expectation is that LISP will go away as quickly as it came. Cameron > But there is no roadmap in the IETF process now for LISP that says > "We've got this 90% baked, we need to circulate a draft to the NANOG > mailing list, request operator comments, and actively solicit operators > to participate in the expanded test network". ?We need that mechanism to > tell folks "hey, it's real enough your operational feedback is now > useful" and "come test our new idea". > > Today the IETF just finishes their work, "tosses it over the wall" and > hopes for the best. ?Generally it's not 100%, and vendors make > propretary changes to the standards slowly over time to meet the needs > of operators. ?It would be far better if there was at least one round of > "ask the operators" and incorproate feedback before it went over the > wall, and in paricular before working groups disbanded. > > In short, make it easy for the operators to participate at the right > time in the process. ?It will be better for everyone! > > -- > ? ? ? Leo Bicknell - bicknell at ufp.org - CCIE 3440 > ? ? ? ?PGP keys at http://www.ufp.org/~bicknell/ > > From walter.keen at rainierconnect.net Tue Jul 12 10:53:19 2011 From: walter.keen at rainierconnect.net (Walter Keen) Date: Tue, 12 Jul 2011 08:53:19 -0700 Subject: Myspace contact needed In-Reply-To: <4E1C6D29.3070503@tprophet.org> References: <4E1B955F.7010807@rainierconnect.net><5234b2c8-26b3-4925-a2da-a0106fc31a5e@blur> <0FBA884762114F49A1132BE7C36BB050FE23A8@stellarrad.RainierConnect.local> <4E1C6D29.3070503@tprophet.org> Message-ID: <4E1C6DEF.508@rainierconnect.net> I finally made contact using the information at http://whois.arin.net/rest/poc/NOC11562-ARIN.html . We were blocked for spamming (but there seemed to be some confusion, as we have 69.10.192.0/19, and they asked if we had 69.10.0.0/16. Makes me wonder if they lookup the RIR allocated blocks before blocking, or assume a /16 Walter Keen Network Engineer Rainier Connect (P) 360-832-4024 (C) 253-302-0194 On 07/12/2011 08:50 AM, TProphet wrote: > I use a VPN from Beijing, where I reside. It's pretty common for > myspace to blacklist any IP addresses that they believe belong to > crawlers, linkbots, VPN services, etc. This appears to be an automated > process. I've never had luck getting any of my VPN IPs unblocked. > > Good luck getting in touch with anyone there, the company was just > sold to a consortium of celebrities after massive News Corp. layoffs > and it's left with walking zombies. I'd be surprised if anyone > competent is still left... > > -TProphet > > On 7/12/2011 9:49 PM, Walter Keen wrote: >> >> Sorry about the lack of details. >> >> I'm looking for a Myspace contact, We're an ISP (AS20394) and all of our >> users are getting a 302 redirect to google after contacting a myspace >> server. If there is an appropriate contact on this list, or someone who >> can forward this to such a contact, it would be greatly appreciated. >> I don't have this issue from other ISP connections(such as my home >> connection), but have not heard back from the website support portal as >> of yet. >> >> >> >> >> wkeen at tnwx-nms-3:~$ traceroute www.myspace.com >> traceroute to www.myspace.com (216.178.39.11), 30 hops max, 40 byte >> packets >> 1 tnwx-core-1.rainierconnect.com (69.10.208.1) 0.409 ms 0.479 ms >> 0.559 ms >> 2 74.50.203.97 (74.50.203.97) 1.772 ms 1.769 ms 1.805 ms >> 3 ge5-0-2d0.cir1.seattle7-wa.us.xo.net (216.156.100.41) 1.703 ms 1.708 >> ms 1.707 ms >> 4 4.59.232.53 (4.59.232.53) 2.064 ms 2.067 ms 2.056 ms >> 5 ae-31-51.ebr1.Seattle1.Level3.net (4.69.147.150) 11.408 ms 11.374 ms >> 11.484 ms >> 6 ae-7-7.ebr2.SanJose1.Level3.net (4.69.132.49) 19.095 ms 18.870 ms >> 18.997 ms >> 7 ae-34-34.ebr4.SanJose1.Level3.net (4.69.153.34) 20.638 ms 30.373 ms >> 30.333 ms >> 8 ae-5-5.ebr2.SanJose5.Level3.net (4.69.148.141) 19.631 ms 19.813 ms >> 19.803 ms >> 9 ae-6-6.ebr2.LosAngeles1.Level3.net (4.69.148.201) 29.283 ms 28.981 ms >> 29.246 ms >> 10 ae-62-62.csw1.LosAngeles1.Level3.net (4.69.137.18) 29.091 ms >> ae-72-72.csw2.LosAngeles1.Level3.net (4.69.137.22) 29.461 ms 29.437 ms >> 11 ae-24-70.car4.LosAngeles1.Level3.net (4.69.144.70) 29.684 ms >> ae-44-90.car4.LosAngeles1.Level3.net (4.69.144.198) 29.562 ms >> ae-14-60.car4.LosAngeles1.Level3.net (4.69.144.6) 29.680 ms >> 12 ve202.lax.myspace.com (4.71.128.10) 29.351 ms 28.998 ms 29.203 ms >> 13 vl342.cs2.lax1.myspace.com (204.16.35.137) 29.431 ms 29.540 ms >> 29.638 ms >> 14 vl3552.cs2.els2.myspace.com (216.178.35.77) 29.970 ms 29.717 ms >> 29.726 ms >> 15 * * * >> 16 * * * >> 17 * * * >> 18 * * * >> 19 * * * >> >> wkeen at tnwx-nms-3:~$ wget www.myspace.com >> --2011-07-12 06:45:32-- http://www.myspace.com/ >> Resolving www.myspace.com... 63.135.80.46 >> Connecting to www.myspace.com|63.135.80.46|:80... connected. >> HTTP request sent, awaiting response... 302 Found >> Location: http://www.google.com [following] >> --2011-07-12 06:45:32-- http://www.google.com/ >> Resolving www.google.com... 72.14.213.106, 72.14.213.147, >> 72.14.213.99, ... >> Connecting to www.google.com|72.14.213.106|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: unspecified [text/html] >> Saving to: `index.html.5' >> >> [ <=> ] 9,908 --.-K/s in 0.009s >> >> 2011-07-12 06:45:32 (1.01 MB/s) - `index.html.5' saved [9908] >> >> wkeen at tnwx-nms-3:~$ >> >> >> >> wrote: >> > My apologies all, I meant to say myspace contact >> > >> >> You're more likely to get a response if you give some indication >> of what the issue is; for example, saying "I'm looking for a MySpace >> contact because there is an attack coming from their servers that >> appears to indicate they may have been compromised" will likely >> get you a faster reaction from the security people. Or, if it's a >> network issue, saying "I'm looking for a MySpace network contact >> because it appears they are announcing the following blocks which >> really belong to me, which is causing reachability issues" will more >> likely get you a reaction from an appropriate network person. >> >> Without an indication of the nature of the problem, I think you'll find >> most people on the list tend to ignore generic requests like this. >> >> Thanks! >> >> Matt >> From tjc at ecs.soton.ac.uk Tue Jul 12 11:11:58 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue, 12 Jul 2011 17:11:58 +0100 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <4E19E448.9070807@tiggee.com> Message-ID: On 10 Jul 2011, at 21:22, Owen DeLong wrote: > On Jul 10, 2011, at 12:23 PM, William Herrin wrote: > >> Consider, for example, RFC 3484. That's the one that determines how an >> IPv6 capable host selects which of a group of candidate IPv4 and IPv6 >> addresses for a particular host name gets priority. How is a server's >> address priority NOT an issue that should be managed at an operations >> level by individual server administrators? Yet the working group which >> produced it came up with a static prioritization that is the root >> cause of a significant portion of the IPv6 deployment headaches we >> face. >> > 3484 specifies a static default. By definition, defaults in absence of > operator configuration kind of have to be static. Having a reasonable > and expected set of defaults documented in an RFC provides a known > quantity for what operators can/should expect from hosts they have > not configured. I see nothing wrong with RFC 3484 other than I would > agree that the choices made were suboptimal. Mostly that was based > on optimism and a lack of experience available at the time of writing. > > There is another RFC and there are APIs and most operating systems > have configuration mechanisms where an operator CAN set that to > something other than the 3484 defaults. There is a DHCPv6 option to configure host policy described in http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-01, which is hopefully approaching a WGLC at IETF81. RFC3484 was originally published in 2003, which is a long time ago. And of course it turned out that, with wider operational experience and feedback from the operator community, there were some issues uncovered and some omissions. Perhaps some of those might have been foreseen, but I highly doubt all of them would have. Many of the issues were captured in RFC5220, which led to the work on RFC3484-bis, which is also close to publication. Now, perhaps the DHCPv6 option and the 3484-bis drafts could be posted to the NANOG list at an appropriate time, for example when the docs hit WGLC. But there are a lot of WGLCs out there and the question is then whether the NANOG list, or some special NANOG list for IETF WGLCs, would want all those notifications. As a co-author of the DHCPv6 and 3484-bis drafts, I am quite happy to post about these to NANOG as they approach last call. There are three open issues on 3484-bis that some feedback would be welcomed on. >> There should be an operations callout as well -- a section where >> proposed operations defaults (as well as statics for which a solid >> case can be made for an operations tunable) are extracted from the >> thick of it and offered for operator scrutiny prior to publication of >> the RFC. > > I think this would be a good idea, actually. It would probably be more > effective to propose it to IETF than to NANOG, however. Whether it's a separate section in the draft, or a recommendation to post to operators communities (which is more than just NANOG of course), the question as mentioned above is how that's done in a way to get the attention of appropriate operators without drowning them in notifications. Tim From cgriffin at ufl.edu Tue Jul 12 11:13:37 2011 From: cgriffin at ufl.edu (Chris Griffin) Date: Tue, 12 Jul 2011 12:13:37 -0400 Subject: ep.net contact? Message-ID: <8E1FFB61-4972-4267-8C0C-40B738D1A0BB@ufl.edu> Could someone involved in ep.net contact me off list in regard to a DNS issue. Usual contact methods have failed to date. Thanks Chris --- Chris Griffin cgriffin at ufl.edu Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 From jra at baylink.com Tue Jul 12 11:13:48 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 12 Jul 2011 12:13:48 -0400 (EDT) Subject: NANOG List Update - Moving Forward In-Reply-To: <1310481301.239130535@apps.rackspace.com> Message-ID: <1154063.1343.1310487228300.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Ben Carleton" > * The mailing list is stripping out all Received: headers from prior > to the message hitting the listserver You're the third person to report that, but *I* am seeing incoming Received headers in my messages here -- yours, for example, has them all, even prior to the message hitting s0. Great name, there, BTW. "s0". Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Tue Jul 12 11:14:40 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 12 Jul 2011 12:14:40 -0400 (EDT) Subject: NANOG List Update - Moving Forward In-Reply-To: Message-ID: <10738781.1345.1310487280622.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Gerry Boudreaux" > On Jul 12, 2011, at 00:19 , Michael K. Smith - Adhost wrote: > > Mailman is shut down on s0.nanog.org and mail is being routed directly to > > mail.amsl.com where it is being processed by our new list (etc.) system. > > Will the list archives migrate? What about future list archives? And please remember the First Rule Of The Web: *DO NOT Break the URLs*. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From ralphw at interworld.net Tue Jul 12 11:16:31 2011 From: ralphw at interworld.net (Ralph E. Whitmore, III) Date: Tue, 12 Jul 2011 16:16:31 +0000 Subject: NANOG List Update - Moving Forward In-Reply-To: <201107121507.p6CF7i7h033220@mail.r-bonomi.com> References: <201107121507.p6CF7i7h033220@mail.r-bonomi.com> Message-ID: <409E5316D8C0514F9E6B49DB5FBBBB98038855DC@exch2008.torrance.interworld.net> Its great to see how quick a response we are getting, they have their top people working on it??? Perhaps my 14 year old son should apply for a job as one the trainers for the so called "experts" on this. Ralph -----Original Message----- From: Robert Bonomi [mailto:bonomi at mail.r-bonomi.com] Sent: Tuesday, July 12, 2011 8:14 AM To: nanog at nanog.org Subject: Re: NANOG List Update - Moving Forward Cc: nanog at nanog.org.r-bonomi.com In-Reply-To: <1BE304A1-0DA0-4558-83AD-0E4F08F8146D at twincreeks.net> > Subject: Re: NANOG List Update - Moving Forward > From: Steve Feldman > Date: Tue, 12 Jul 2011 07:00:51 -0700 > > We're aware of the spam problem and have our top people working on it. > > Reports of other lingering issues from the change would be > appreciated, though. You asked for it, you got it: 1) You broke *all* the mailing-list support addresses. 'nanog-owner' ,etc. *BOUNCE* "user unknown" see mark's inbox for a smoking gun 2) You let non-members post to the list. see mark's inbox for a smoking gun 3) You broke the mailing-list *submission* address itself, for subscribers. Although you let non-member *SPAM* through. 4) You have dropped _all_ the the received lines _before_ the message gets to the list. see mark's inbox for a smoking gun -- one of the spam messages 5) You are *NOT* using 'custom 'From ' lines, meaning you cannot tell who the subscriber is when a forwarded message bounces. see mark's inbox for a smoking gun -- one of the spam messages 6) You dropped *ALL* the list-management info headers. see mark's inbox for a smoking gun -- one of the spam messages 7) You rolled changes out with _NOBODY_AROUND_ to take complaints from users who noticed problems. 8) You are mailing to "undisclosed recipients". This indicates "less than competent", *lazy*, mailing-list management practices. AND making it impossible for the recipient to determine _what_ e-mail address the message was actually sent to, *if* for instance they need to change their subscription information on a 'forwarded' (or worse, _multiply-forwarded_) subscription address. see mark's inbox for a smoking gun -- one of the spam messages 9) Others report you lost some, if not all, of the established mailing 'preferences' for subscribers. *AND* all this was on the *second* attempt, having already utterly botched the first one. Reports were being sent to Mark's email (he who posted the announcement, the 'test' and the notice saying things were 'apparently working') roughly 2-1/2 hours after the -first- problem surfaced. SIX hours later the problem was still occuring. "Asleep at the switch" would seem to apply. Considering =ALL= of the above the statement that you have your "top people" working on the matter is not in the least reasurring. One *also* has to "wonder" -- considering all the other things that were 'lost', if the existing suppression filters -- specifically those which keep 'banned' traffic off the list -- were *also* 'lost'. One _really_ has to wonder "why" things are being moved off a tested, reliable, and fully reliable platform, to an "obviously" flawed implementation. Methinks the decision-makers owe the list subscribers _some_ explanation with regard to the 'advantages' to be gained by this migration, and why it is necessary. From jra at baylink.com Tue Jul 12 11:16:27 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 12 Jul 2011 12:16:27 -0400 (EDT) Subject: Spam? In-Reply-To: Message-ID: <1940558.1349.1310487387179.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Randy Bush" > >> thanks for the hard work, folk. > > Let's work harder > > thanks for volunteering. when will you be flying out to the bay? I suspect, Randy, that Ferg *knows* how to use ssh. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Tue Jul 12 11:22:09 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 12 Jul 2011 12:22:09 -0400 (EDT) Subject: Spam? In-Reply-To: Message-ID: <31252539.1355.1310487729342.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Randy Bush" > > Also, where is the reply to header? > > still in the garbage, where it belongs NANOG, being a traditional, (semi-)public, technical mailing list, has never had a Reply-to header, and never should. I concur with the people who assert that adding the Reply-to header formally violates the relevant RFCs, quite aside from the Real World problems it can (and *has*) caused. http://woozle.org/~neale/papers/reply-to-still-harmful.html Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From bruns at 2mbit.com Tue Jul 12 11:23:10 2011 From: bruns at 2mbit.com (Brielle Bruns) Date: Tue, 12 Jul 2011 10:23:10 -0600 Subject: NANOG List Update - Moving Forward In-Reply-To: <1154063.1343.1310487228300.JavaMail.root@benjamin.baylink.com> References: <1154063.1343.1310487228300.JavaMail.root@benjamin.baylink.com> Message-ID: <4E1C74EE.2030002@2mbit.com> On 7/12/11 10:13 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Ben Carleton" > >> * The mailing list is stripping out all Received: headers from prior >> to the message hitting the listserver > > You're the third person to report that, but *I* am seeing incoming Received > headers in my messages here -- yours, for example, has them all, even prior > to the message hitting s0. > > Great name, there, BTW. "s0". > Looks like parts of the received like are still there, though butchered and mashed in (most likely in a non-RFC compliant manner) with the one added by 'bulk_maler v1.13' (great name for the mailer, btw, sets off my spammy sense something fierce). Received: from mail.amsl.com ([2001:1890:1112:1::14]) by mail.sosdg.org with esmtp (Exim 4.72-SOSDG) id 1QgVBE-0001sm-Oh; Mon, 11 Jul 2011 23:06:46 -0600 Received: by c1a.amsl.com (Postfix, from userid 65534) id 005B01C39169; Mon, 11 Jul 2011 22:01:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c1a.amsl.com (Postfix) with SMTP id F26731C39160; Mon, 11 Jul 2011 22:01:16 -0700 (PDT) Received: by nanog.org (bulk_mailer v1.13); Mon, 11 Jul 2011 22:01:01 -0700 X-Virus-Scanned: amavisd-new at amsl.com by localhost (c1a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yrl8e1RiNVz9 for ; Mon, 11 Jul 2011 22:01:00 -0700 (PDT) by c1a.amsl.com (Postfix) with ESMTPS id E2ED01C38FB6 for ; Mon, 11 Jul 2011 22:00:59 -0700 (PDT) by s0.nanog.org with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QgV5e-000MmM-OE for nanog at nanog.org; Tue, 12 Jul 2011 05:00:58 +0000 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail-in02.adhost.com (Postfix) with ESMTPS id 0691FCBCD35 for ; Mon, 11 Jul 2011 22:00:58 -0700 (PDT) (envelope-from xxxxxxxxxxx) -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From ben at bencarleton.com Tue Jul 12 11:25:21 2011 From: ben at bencarleton.com (Ben Carleton) Date: Tue, 12 Jul 2011 12:25:21 -0400 (EDT) Subject: NANOG List Update - Moving Forward In-Reply-To: <1154063.1343.1310487228300.JavaMail.root@benjamin.baylink.com> References: <1154063.1343.1310487228300.JavaMail.root@benjamin.baylink.com> Message-ID: <1310487921.7721840@apps.rackspace.com> Right, you should, because we are back on s0 (server zero?) and mailman. The headers were being suppressed by the AMSL servers, which are running that strange "bulk_mailer 1.13" software. If you inspect the headers for any of the messages that were forwarded to us from that server (the one that started the thread called "NANOG List Update - Moving Forward" from Michael K Smith, for example), you will see that the headers are being stripped... --bc -----Original Message----- From: "Jay Ashworth" Sent: Tuesday, July 12, 2011 12:13pm To: "NANOG" Subject: Re: NANOG List Update - Moving Forward ----- Original Message ----- > From: "Ben Carleton" > * The mailing list is stripping out all Received: headers from prior > to the message hitting the listserver You're the third person to report that, but *I* am seeing incoming Received headers in my messages here -- yours, for example, has them all, even prior to the message hitting s0. Great name, there, BTW. "s0". Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From bhmccie at gmail.com Tue Jul 12 11:25:46 2011 From: bhmccie at gmail.com (-Hammer-) Date: Tue, 12 Jul 2011 11:25:46 -0500 Subject: NANOG List Update - Moving Forward In-Reply-To: <409E5316D8C0514F9E6B49DB5FBBBB98038855DC@exch2008.torrance.interworld.net> References: <201107121507.p6CF7i7h033220@mail.r-bonomi.com> <409E5316D8C0514F9E6B49DB5FBBBB98038855DC@exch2008.torrance.interworld.net> Message-ID: <4E1C758A.10604@gmail.com> The tolerance of some of you out there is amazing. You must be PS3 users crying because your free game network is down. Maybe we can get a subscription service set up for you so you have something else to complain about. Be patient people. Maybe a little appreciation to these experts wouldn't hurt you either. -Hammer- "I was a normal American nerd" -Jack Herer On 07/12/2011 11:16 AM, Ralph E. Whitmore, III wrote: > Its great to see how quick a response we are getting, they have their top people working on it??? Perhaps my 14 year old son should apply for a job as one the trainers for the so called "experts" on this. > > Ralph > > > -----Original Message----- > From: Robert Bonomi [mailto:bonomi at mail.r-bonomi.com] > Sent: Tuesday, July 12, 2011 8:14 AM > To: nanog at nanog.org > Subject: Re: NANOG List Update - Moving Forward > > Cc: nanog at nanog.org.r-bonomi.com > In-Reply-To:<1BE304A1-0DA0-4558-83AD-0E4F08F8146D at twincreeks.net> > > > >> Subject: Re: NANOG List Update - Moving Forward >> From: Steve Feldman >> Date: Tue, 12 Jul 2011 07:00:51 -0700 >> >> We're aware of the spam problem and have our top people working on it. >> >> Reports of other lingering issues from the change would be >> appreciated, though. >> > You asked for it, you got it: > > 1) You broke *all* the mailing-list support addresses. > 'nanog-owner' ,etc. *BOUNCE* "user unknown" > see mark's inbox for a smoking gun > 2) You let non-members post to the list. > see mark's inbox for a smoking gun > 3) You broke the mailing-list *submission* address itself, for > subscribers. Although you let non-member *SPAM* through. > 4) You have dropped _all_ the the received lines _before_ the message > gets to the list. > see mark's inbox for a smoking gun -- one of the spam messages > 5) You are *NOT* using 'custom 'From ' lines, meaning you cannot tell > who the subscriber is when a forwarded message bounces. > see mark's inbox for a smoking gun -- one of the spam messages > 6) You dropped *ALL* the list-management info headers. > see mark's inbox for a smoking gun -- one of the spam messages > 7) You rolled changes out with _NOBODY_AROUND_ to take complaints from > users who noticed problems. > 8) You are mailing to "undisclosed recipients". This indicates "less > than competent", *lazy*, mailing-list management practices. AND > making it impossible for the recipient to determine _what_ e-mail > address the message was actually sent to, *if* for instance they need > to change their subscription information on a 'forwarded' (or worse, > _multiply-forwarded_) subscription address. > see mark's inbox for a smoking gun -- one of the spam messages > 9) Others report you lost some, if not all, of the established mailing > 'preferences' for subscribers. > > *AND* all this was on the *second* attempt, having already utterly botched the first one. > > Reports were being sent to Mark's email (he who posted the announcement, the 'test' and the notice saying things were 'apparently working') roughly > 2-1/2 hours after the -first- problem surfaced. SIX hours later the > problem was still occuring. "Asleep at the switch" would seem to apply. > > Considering =ALL= of the above the statement that you have your "top people" > working on the matter is not in the least reasurring. > > One *also* has to "wonder" -- considering all the other things that were 'lost', if the existing suppression filters -- specifically those which keep 'banned' traffic off the list -- were *also* 'lost'. > > One _really_ has to wonder "why" things are being moved off a tested, reliable, and fully reliable platform, to an "obviously" flawed implementation. > > Methinks the decision-makers owe the list subscribers _some_ explanation with regard to the 'advantages' to be gained by this migration, and why it is necessary. > > > > > > From jared at puck.nether.net Tue Jul 12 11:37:49 2011 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 12 Jul 2011 12:37:49 -0400 Subject: NANOG List Update - Moving Forward In-Reply-To: <4E1C74EE.2030002@2mbit.com> References: <1154063.1343.1310487228300.JavaMail.root@benjamin.baylink.com> <4E1C74EE.2030002@2mbit.com> Message-ID: On Jul 12, 2011, at 12:23 PM, Brielle Bruns wrote: > Looks like parts of the received like are still there, though butchered and mashed in (most likely in a non-RFC compliant manner) with the one added by 'bulk_maler v1.13' (great name for the mailer, btw, sets off my spammy sense something fierce). You seem to be new here. bulk_mailer was something used back in the day to workaround limitations in sendmail for those people operating majordomo (and those using smail etc). it broke the chunks into something that sendmail would then allocate multiple processes to. most other mail subsystems can handle the multiple-rcpts in different manners. while it may 'feel' spammy to you, it's certainly not. a simple google of "majordomo and bulk_mailer" should give you a good idea of what's going on. there were a lot of other mail systems that served to help integrate and interoperate back in the day, including qmailer, smail, etc that all attempted to replace sendmail, including providing the uucp interaction necessary for those behind dialup. either way, please try to keep the feedback off-list for now as we undergo this transition. It's hard to move a large list like this without trouble. I've been party to many such list moves in the past and they usually have all sorts of trouble. admins at nanog.org is the right place for your feedback right now. - Jared From bruns at 2mbit.com Tue Jul 12 12:05:16 2011 From: bruns at 2mbit.com (Brielle Bruns) Date: Tue, 12 Jul 2011 11:05:16 -0600 Subject: NANOG List Update - Moving Forward In-Reply-To: References: <1154063.1343.1310487228300.JavaMail.root@benjamin.baylink.com> <4E1C74EE.2030002@2mbit.com> Message-ID: <4E1C7ECC.7010404@2mbit.com> On 7/12/11 10:37 AM, Jared Mauch wrote: > You seem to be new here. > Since you asked, no, been around alot longer then I care to remember. > bulk_mailer was something used back in the day to workaround > limitations in sendmail for those people operating majordomo (and > those using smail etc). it broke the chunks into something that > sendmail would then allocate multiple processes to. most other mail > subsystems can handle the multiple-rcpts in different manners. I actually was writing sendmail mc/cf files back in the 90s, and used to have a reasonably high traffic majordomo setup. Don't remember anything about bulk_mailer, but then again I stopped using majordomo around 10 years ago, so my memory may be going on stuff like that. > > while it may 'feel' spammy to you, it's certainly not. Hey, I call it as I see it. When you get to pour through spamtraps all day and evening looking at headers for common traits, yeah, things like 'bulk_mailer' stand out. > > a simple google of "majordomo and bulk_mailer" should give you a good > idea of what's going on. Googling generic terms is quite fruitless these days, esp when all the spammers like to call their products bulk mailers. But, thank you for pointing out the context it is used in. I'm not the only one who expressed curiosity over this 'bulk_mailer' program, so please don't shoot me just cause I mentioned something about a pretty generic program name that throws up red flags whenever I see it. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bonomi at mail.r-bonomi.com Tue Jul 12 12:35:14 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Tue, 12 Jul 2011 12:35:14 -0500 (CDT) Subject: Spam? In-Reply-To: <31252539.1355.1310487729342.JavaMail.root@benjamin.baylink.com> Message-ID: <201107121735.p6CHZEMF034364@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Tue Jul 12 11:29:29 2011 > Date: Tue, 12 Jul 2011 12:22:09 -0400 (EDT) > From: Jay Ashworth > To: NANOG > Subject: Re: Spam? > > ----- Original Message ----- > > From: "Randy Bush" > > > > Also, where is the reply to header? > > > > still in the garbage, where it belongs > > NANOG, being a traditional, (semi-)public, technical mailing list, has > never had a Reply-to header, and never should. I concur with the people > who assert that adding the Reply-to header formally violates the relevant > RFCs, quite aside from the Real World problems it can (and *has*) caused. *SIGH* One more "problem" with the 'new system', Messages through it _have_ a Reply-to: header. Set to the putative email of the sender, no less. From heinrich at hstrauss.co.za Tue Jul 12 12:41:03 2011 From: heinrich at hstrauss.co.za (Heinrich Strauss) Date: Tue, 12 Jul 2011 19:41:03 +0200 Subject: NANOG List Update - Moving Forward In-Reply-To: <4E1C5842.40402@riverviewtech.net> References: <4E1C5842.40402@riverviewtech.net> Message-ID: <4E1C872F.4010807@hstrauss.co.za> On 2011/07/12 16:20, Grant Taylor wrote: > Also, subscriptions that were set to no mail delivery are now > delivering mail. Is this expected? I saw duplicate messages from an account that I had disabled (while testing NANOG volumes to a portable messaging device and forwarding to this account) and assumed the list was duplicating responses. Took me a while to realise it was the vacation-suppression being b0rk. :/ From jsw at inconcepts.biz Tue Jul 12 13:13:30 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Tue, 12 Jul 2011 14:13:30 -0400 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: <20110712154202.GA45271@ussenterprise.ufp.org> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> Message-ID: On Tue, Jul 12, 2011 at 11:42 AM, Leo Bicknell wrote: > I'll pick on LISP as an example, since many operators are at least > aware of it. ?Some operators have said we need a locator and identifier > split. ?Interesting feedback. ?The IETF has gone off and started > playing in the sandbox, trying to figure out how to make that go. As an operator (who understands how most things work in very great detail), I found the LISP folks very much uninterested in my concerns about if LISP can ever be made to scale up to "Internet-scale," with respect to a specific DDoS vector. I also think that an explosion of small, multi-homed SOHO networks would be a disaster, because we might have 3 million FIB instead of 360k FIB after a few years. These things are directly related to each-other, too. So I emailed some LISP gurus off-list and discussed my concern. I was encouraged to post to the LISP IETF list, which I did. To my great surprise, not one single person was interested in my problem. If you think it is a small problem, well, you should try going back to late-1990s flow-cache routing in your data-center networks and see what happens when you get DDoS. I am sure most of us remember some of those painful experiences. Now there is a LISP "threats" draft which the working group mandates they produce, discussing various security problems. The current paper is a laundry list of "what if" scenarios, like, what if a malicious person could fill the LISP control-plane with garbage. BGP has the same issue, if some bad guy had enable on a big enough network that their peers/transits don't filter their routes, they could do a lot of damage before they were stopped. This sometimes happens even by accident, for example, some poor guy accidentally announcing 12/9 and giving AT&T a really bad day. What it doesn't contain is anything relevant to the special-case DDoS that all LISP sites would be vulnerable to, due to the IMO bad flow-cache management system that is specified. I am having a very great deal of trouble getting the authors of the "threats" document to even understand what the problem is, because as one of them put it, he is "just a researcher." I am sure he and his colleagues are very smart guys, but they clearly do not remember our 1990s pains. That is the "not an operator" problem. It is understandable. Others who have been around long enough simply dismiss this problem, because they believe the unparalleled benefits of LISP for mobility and multi-homing SOHO sites must greatly out-weigh the fact that, well, if you are a content provider and you receive a DDoS, your site will be down and there isn't a damn thing you can do about it, other than spec routers that have way, way more FIB than the number of possible routes, again due to the bad caching scheme. The above is what I think is the "ego-invested" problem, where certain pretty smart, well-intentioned people have a lot of time, and professional credibility, invested in making LISP work. I'm sure it isn't pleasing for these guys to defend their project against my argument that it may never be able to reach Internet-scale, and that they have missed what I claim is a show-stopping problem with an easy way to improve it through several years of development. Especially since I am a guy who did not ever participate in the IETF before, someone they don't know from a random guy on the street. I am glad that this NANOG discussion has got some of these LISP folks to pay more attention to my argument, and my suggested improvement (I am not only bashing their project; I have positive input, too.) Simply posting to their mailing list once and emailing a few draft authors did not cause any movement at all. Evidently it does get attention, though, to jump up and down on a different list. Go figure! If operators don't provide input and *perspective* to things like LISP, we will end up with bad results. How many of us are amazed that we still do not have 32:32 bits BGP communities to go along with 32 bit ASNs, for signalling requests to transit providers without collision with other networks' community schemes? It is a pretty stupid situation, and yet here we are, with 32 bit ASN for years, and if you want to do advertisement control with 32 bit ASNs used, you are either mapping your 32 bit neighbors to special numbers, or your community scheme can overlap with others. That BGP community problem is pretty tiny compared to, what if people really started rolling out something new and clever like LISP, but in a half-baked, broken way that takes us back to 1990s era of small DDoS taking out whole data-center aggregation router. A lot of us think IPv6 is over-baked and broken, and probably this is why it has taken such a very long time to get anywhere with it. But ultimately, it is our fault for not participating. I am reversing my own behavior and providing input to some WGs I care about, in what time I have to do so. More operators should do the same. Otherwise, we have no right to blame the people who do participate in IETF, because we aren't part of the solution. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From dougb at dougbarton.us Tue Jul 12 13:35:01 2011 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 12 Jul 2011 11:35:01 -0700 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> Message-ID: <4E1C93D5.5060808@dougbarton.us> On 07/12/2011 08:43, Cameron Byrne wrote: > Witness the latest debacle with the attempt at trying to make 6to4 historic. > > Various "non-practicing entities" were able to derail what network > operators largely supported. Since the IETF failed to make progress > operators will do other things to stop 6to4 ( i have heard no AAAA > over IPv4 transport, blackhole 6to4 anycast, decom relay routers...) FYI, my understanding (and I'm sure Ron will correct me if I'm wrong) is that what's actually happening is that the IESG is pushing that draft forward knowing that it's going to be appealed. The appeal process will then sort itself out, and we'll have a result. The fact that one person can stall the end result through the appeals process is both a strength and occasionally a burden of the way the IETF does its work. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From rbonica at juniper.net Tue Jul 12 13:51:07 2011 From: rbonica at juniper.net (Ronald Bonica) Date: Tue, 12 Jul 2011 14:51:07 -0400 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: <20110712154202.GA45271@ussenterprise.ufp.org> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F3B850BE@EMBX01-WF.jnpr.net> > -----Original Message----- > From: Leo Bicknell [mailto:bicknell at ufp.org] > Sent: Tuesday, July 12, 2011 11:42 AM > To: Ronald Bonica > Cc: nanog at nanog.org > Subject: Re: Anybody can participate in the IETF (Was: Why is IPv6 > broken?) > [snip] > > But there is no roadmap in the IETF process now for LISP that says > "We've got this 90% baked, we need to circulate a draft to the NANOG > mailing list, request operator comments, and actively solicit operators > to participate in the expanded test network". We need that mechanism > to > tell folks "hey, it's real enough your operational feedback is now > useful" and "come test our new idea". > Leo, We need to fix this problem. Without the feedback loop that you describe, the IETF will never know whether they are producing useful stuff or nonsense. How does the following sound as a solution: Let's say we set up an new IETF mailing list, primarily for the use of operators. When an operator sees a draft that might be of interest to the operational community, he creates a new thread on the list, copying the draft authors and WG chairs. (The authors and chairs can decide whether to add the WG to the thread). The OPS AD will consider thread contents when evaluating the draft. Ron From rbonica at juniper.net Tue Jul 12 13:55:50 2011 From: rbonica at juniper.net (Ronald Bonica) Date: Tue, 12 Jul 2011 14:55:50 -0400 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F3B850E9@EMBX01-WF.jnpr.net> Cameron, Please stay tuned. While 6-to-4-historic is on hold, it is far from being dead. Expect more discussion in Quebec and on the mailing list. I doubt if there will be any final decision before Quebec. Ron > -----Original Message----- > From: Cameron Byrne [mailto:cb.list6 at gmail.com] > Sent: Tuesday, July 12, 2011 11:44 AM > To: Ronald Bonica > Cc: Leo Bicknell; nanog at nanog.org > Subject: Re: Anybody can participate in the IETF (Was: Why is IPv6 > broken?) > > On Tue, Jul 12, 2011 at 8:28 AM, Ronald Bonica > wrote: > > Leo, > > > > Maybe we can fix this by: > > > > a) bringing together larger groups of clueful operators in the IETF > > b) deciding which issues interest them > > c) showing up and being vocal as a group in protocol developing > working groups > > > > To some degree, we already do this in the IETF OPS area, but judging > by your comments, we don't do it nearly enough. > > > > Comments? > > > > There may be an OPS area, but it is not listened to. > > Witness the latest debacle with the attempt at trying to make 6to4 > historic. > > Various "non-practicing entities" were able to derail what network > operators largely supported. Since the IETF failed to make progress > operators will do other things to stop 6to4 ( i have heard no AAAA > over IPv4 transport, blackhole 6to4 anycast, decom relay routers...) > > Real network operators have a relatively low BS threshold, they have > customers to support and businesses to run, and they don't have thumb > wrestle these people who don't actually have any skin in the game. > > Cameron > > > > ? ? ? ? ? ? ? Ron > > > > > > -----Original Message----- > > From: Leo Bicknell [mailto:bicknell at ufp.org] > > Sent: Monday, July 11, 2011 3:35 PM > > To: nanog at nanog.org > > Subject: Re: Anybody can participate in the IETF (Was: Why is IPv6 > broken?) > > > > In a message written on Sun, Jul 10, 2011 at 06:16:09PM +0200, Jeroen > Massar wrote: > >> Ehmmmm ANYBODY, including you, can sign up to the IETF mailing lists > >> and participate there, just like a couple of folks from NANOG are > already doing. > > > > The way the IETF and the operator community interact is badly broken. > > > > The IETF does not want operators in many steps of the process. ?If > you try to bring up operational concerns in early protocol development > for example you'll often get a "we'll look at that later" response, > which in many cases is right. ?Sometimes you just have to play with > something before you worry about the operational details. ?It also does > not help that many operational types are not hardcore programmers, and > can't play in the sandbox during the major development cycles. > > > > > > > > From mike at mtcc.com Tue Jul 12 14:40:15 2011 From: mike at mtcc.com (Michael Thomas) Date: Tue, 12 Jul 2011 12:40:15 -0700 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: <20110712154202.GA45271@ussenterprise.ufp.org> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> Message-ID: <4E1CA31F.6040302@mtcc.com> Leo Bicknell wrote: In short, make it easy for the operators to participate at the right > time in the process. It will be better for everyone! Unfortunately, where you want to be inserted into the process is when everybody has said their piece 80-dozen times and are tired and just want to get on with life. So it doesn't matter whether you're an operator or the IESG -- you're not going to make many friends at that point telling them they got it wrong. On the other hand, is it really too much to ask operators -- especially big ones with a vested interest in not having the IETF throw crap over the wall for them to debug -- to *hire* a liaison whose job is to monitor a swath of working groups, bofs, etc, and participate the entire way through? I imagine they'd be pretty popular amongst clueful vendors, and would give you a leg up knowing what's good and what's just sales-drek. Mike From cgriffin at ufl.edu Tue Jul 12 14:42:11 2011 From: cgriffin at ufl.edu (Chris Griffin) Date: Tue, 12 Jul 2011 12:42:11 -0700 Subject: ep.net contact? In-Reply-To: <8E1FFB61-4972-4267-8C0C-40B738D1A0BB@ufl.edu> References: <8E1FFB61-4972-4267-8C0C-40B738D1A0BB@ufl.edu> Message-ID: <26D36352-DED9-43F2-BAA7-5B52B15FE800@ufl.edu> Got in touch with them. Thanks to all those who replied. tnx Chris Sent from my iPad On Jul 12, 2011, at 9:13 AM, Chris Griffin wrote: > Could someone involved in ep.net contact me off list in regard to a DNS issue. Usual contact methods have failed to date. > > Thanks > Chris > --- > Chris Griffin cgriffin at ufl.edu > Sr. Network Engineer - CCNP Phone: (352) 273-1051 > CNS - Network Services Fax: (352) 392-9440 > University of Florida/FLR Gainesville, FL 32611 > > > > From owen at delong.com Tue Jul 12 14:53:42 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 12 Jul 2011 12:53:42 -0700 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> Message-ID: On Jul 12, 2011, at 8:43 AM, Cameron Byrne wrote: > On Tue, Jul 12, 2011 at 8:28 AM, Ronald Bonica wrote: >> Leo, >> >> Maybe we can fix this by: >> >> a) bringing together larger groups of clueful operators in the IETF >> b) deciding which issues interest them >> c) showing up and being vocal as a group in protocol developing working groups >> >> To some degree, we already do this in the IETF OPS area, but judging by your comments, we don't do it nearly enough. >> >> Comments? >> > > There may be an OPS area, but it is not listened to. > > Witness the latest debacle with the attempt at trying to make 6to4 historic. > > Various "non-practicing entities" were able to derail what network > operators largely supported. Since the IETF failed to make progress > operators will do other things to stop 6to4 ( i have heard no AAAA > over IPv4 transport, blackhole 6to4 anycast, decom relay routers...) > Those are all REALLY bad ideas. Speaking as an operator, the best thing you can do to alleviate the problems with 6to4 is operate more, not less 6to4 relays. Blocking AAAA over IPv4 transport is just silly. It's just as likely that your AAAA record is destined for an end-host that has native IPv6 connectivity with an intermediate resolver that desn't have IPv6 as it is that you're sending that to a 6to4 host. Further, there's no reason to believe the 6to4 host won't attempt to resolve via IPv6, so, it doesn't really help anyway. > Real network operators have a relatively low BS threshold, they have > customers to support and businesses to run, and they don't have thumb > wrestle these people who don't actually have any skin in the game. > I agree, but, it's not hard to run 6to4 relays and running them does much more to alleviate the problems with 6to4 than anything you proposed above. Indeed, what you proposed above will likely create more customer issues rather than reduce them. Owen > Cameron > > >> Ron >> >> >> -----Original Message----- >> From: Leo Bicknell [mailto:bicknell at ufp.org] >> Sent: Monday, July 11, 2011 3:35 PM >> To: nanog at nanog.org >> Subject: Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?) >> >> In a message written on Sun, Jul 10, 2011 at 06:16:09PM +0200, Jeroen Massar wrote: >>> Ehmmmm ANYBODY, including you, can sign up to the IETF mailing lists >>> and participate there, just like a couple of folks from NANOG are already doing. >> >> The way the IETF and the operator community interact is badly broken. >> >> The IETF does not want operators in many steps of the process. If you try to bring up operational concerns in early protocol development for example you'll often get a "we'll look at that later" response, which in many cases is right. Sometimes you just have to play with something before you worry about the operational details. It also does not help that many operational types are not hardcore programmers, and can't play in the sandbox during the major development cycles. >> >> >> >> From ekim.ittag at gmail.com Tue Jul 12 16:00:30 2011 From: ekim.ittag at gmail.com (Mike Gatti) Date: Tue, 12 Jul 2011 14:00:30 -0700 Subject: using NESSUS to prepare for PenTest Sec. Audit Message-ID: <29D43069-E329-4D66-8AD5-68136D8D176C@gmail.com> Has anyone used Nessus PF (www.nessus.org) as a tool to run a self audit preparing for a PenTest Audit? I wanted to get your opinion on the tool and if it was useful preparing for a PenTest Audit? Thanks, -- Michael Gatti cell.949.735.5612 ekim.ittag at gmail.com (UTC-8) From joelja at bogus.com Tue Jul 12 16:12:56 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 12 Jul 2011 14:12:56 -0700 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: <4E1CA31F.6040302@mtcc.com> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> <4E1CA31F.6040302@mtcc.com> Message-ID: On Jul 12, 2011, at 12:40 PM, Michael Thomas wrote: > Leo Bicknell wrote: > In short, make it easy for the operators to participate at the right >> time in the process. It will be better for everyone! > > Unfortunately, where you want to be inserted into the process is when everybody has > said their piece 80-dozen times and are tired and just want to get on with life. So > it doesn't matter whether you're an operator or the IESG -- you're not going to make > many friends at that point telling them they got it wrong. > > On the other hand, is it really too much to ask operators -- especially big ones with > a vested interest in not having the IETF throw crap over the wall for them to debug -- > to *hire* a liaison whose job is to monitor a swath of working groups, bofs, etc, and > participate the entire way through? I imagine they'd be pretty popular amongst clueful > vendors, and would give you a leg up knowing what's good and what's just sales-drek. By definition if crap has been thrown of the wall and you're trying to deploy it, that means: * you have a commercial or other compelling reason to run it. * someone has implemented it. the bar to make something relevant on those two points is much higher, than the one that involves submitting an internet draft. getting something through draft to publication via a working group is itself a rather involved process. Plenty of crap is thrown over the wall which you will never use, because the marketplace doesn't care, nobody built it, nobody has that problem it turns out, it turned out to be too hard or it was actually a dumb idea. in the market place for idea this seems normal and healthy. > Mike > From joelja at bogus.com Tue Jul 12 16:21:11 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 12 Jul 2011 14:21:11 -0700 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> Message-ID: <56E0FB8F-BB53-4DB0-829B-39DFBAB483E8@bogus.com> On Jul 12, 2011, at 12:53 PM, Owen DeLong wrote: > > On Jul 12, 2011, at 8:43 AM, Cameron Byrne wrote: > >> On Tue, Jul 12, 2011 at 8:28 AM, Ronald Bonica wrote: >>> Leo, >>> >>> Maybe we can fix this by: >>> >>> a) bringing together larger groups of clueful operators in the IETF >>> b) deciding which issues interest them >>> c) showing up and being vocal as a group in protocol developing working groups >>> >>> To some degree, we already do this in the IETF OPS area, but judging by your comments, we don't do it nearly enough. >>> >>> Comments? >>> >> >> There may be an OPS area, but it is not listened to. >> >> Witness the latest debacle with the attempt at trying to make 6to4 historic. >> >> Various "non-practicing entities" were able to derail what network >> operators largely supported. Since the IETF failed to make progress >> operators will do other things to stop 6to4 ( i have heard no AAAA >> over IPv4 transport, blackhole 6to4 anycast, decom relay routers...) >> > Those are all REALLY bad ideas. Speaking as an operator, the best thing you > can do to alleviate the problems with 6to4 is operate more, not less 6to4 > relays. Unless of course the large providers get their shared transition space in which case all 6to4 behind it will break in a really ugly way, pretty much exactly like in the mobile operator in question. The goal of 6to4 to historic was not to encourage the outcome described, it was to take having 6to4 as a default method of any kind off the table going into the future. If mature adults want to use it great, but conformance tests shouldn't require it, CPE shouldn't it on just because what they think they have a is a public IP with not filtering and hosts shouldn't use it unless told to do so.. > Blocking AAAA over IPv4 transport is just silly. It's just as likely that your > AAAA record is destined for an end-host that has native IPv6 connectivity > with an intermediate resolver that desn't have IPv6 as it is that you're > sending that to a 6to4 host. Further, there's no reason to believe the > 6to4 host won't attempt to resolve via IPv6, so, it doesn't really help > anyway. > >> Real network operators have a relatively low BS threshold, they have >> customers to support and businesses to run, and they don't have thumb >> wrestle these people who don't actually have any skin in the game. >> > I agree, but, it's not hard to run 6to4 relays and running them does much > more to alleviate the problems with 6to4 than anything you proposed > above. Indeed, what you proposed above will likely create more customer > issues rather than reduce them. > > Owen > >> Cameron >> >> >>> Ron >>> >>> >>> -----Original Message----- >>> From: Leo Bicknell [mailto:bicknell at ufp.org] >>> Sent: Monday, July 11, 2011 3:35 PM >>> To: nanog at nanog.org >>> Subject: Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?) >>> >>> In a message written on Sun, Jul 10, 2011 at 06:16:09PM +0200, Jeroen Massar wrote: >>>> Ehmmmm ANYBODY, including you, can sign up to the IETF mailing lists >>>> and participate there, just like a couple of folks from NANOG are already doing. >>> >>> The way the IETF and the operator community interact is badly broken. >>> >>> The IETF does not want operators in many steps of the process. If you try to bring up operational concerns in early protocol development for example you'll often get a "we'll look at that later" response, which in many cases is right. Sometimes you just have to play with something before you worry about the operational details. It also does not help that many operational types are not hardcore programmers, and can't play in the sandbox during the major development cycles. >>> >>> >>> >>> > > > From tom.ammon at utah.edu Tue Jul 12 16:31:45 2011 From: tom.ammon at utah.edu (Tom Ammon) Date: Tue, 12 Jul 2011 15:31:45 -0600 Subject: best practices for management nets in IPv6 Message-ID: Hi All, We're pushing to get IPv6 deployed and working everywhere in our operation, and I had some questions about best practices for a few things. On your management nets (network device management nets) , what's the best approach for addressing them? Do you use ULA? Or do you use global addresses and just depend on router ACLs to protect things? How close are we to having a central registry for unique local addresses, and will that really happen? Tom ----------------------------------------------------------------------------- Tom Ammon Network Engineer M: (801)674-9273 tom.ammon at utah.edu Center for High Performance Computing University of Utah http://www.chpc.utah.edu ----------------------------------------------------------------------------- From andre at operations.net Tue Jul 12 16:48:58 2011 From: andre at operations.net (Andre Gironda) Date: Tue, 12 Jul 2011 14:48:58 -0700 Subject: using NESSUS to prepare for PenTest Sec. Audit In-Reply-To: <29D43069-E329-4D66-8AD5-68136D8D176C@gmail.com> References: <29D43069-E329-4D66-8AD5-68136D8D176C@gmail.com> Message-ID: On Tue, Jul 12, 2011 at 2:00 PM, Mike Gatti wrote: > Has anyone used Nessus PF (www.nessus.org) as a tool to run a self audit preparing for a PenTest Audit? > I wanted to get your opinion on the tool and if it was useful preparing for a PenTest Audit? Nessus is mostly used for information security systems audits (of the vulnerability assessment one-shot type e.g. OCTAVE Allegro ; or possibly the on-going vulnerability management type e.g. NIST SP 800-30). It is not useful for external, unauthenticated scans or black-box "pen-tests". Nessus works best when given credentials so that it can authenticate to systems or network devices. Many of the plugins for Nessus are in a specific language (NASL) and have been imported for use in the open-source vulnerability assessment scanner, OpenVAS. If you are going to check out OpenVAS, I suggest you get the guest VM and load it with ESXi, VMware Workstation/Server, VirtualBox, or VirtualPC. It's also mainly used for credentialed scans. If you are looking for external, "black-box" vulnerability assessments or on-going vulnerability management -- I suggest that you check out Qualys QualysGuard (QG) or Rapid7 NeXpose. An alternative to Nessus for credentialed scans would be nCircle IP360 (just to complete this market space, although certain US-Gov/DoD sites use Lumension/Harris Stat instead). For web applications, you will need to add a specific sort of scanner, such as HP WebInspect, as well as some open-source tools to determine exploitability (e.g. Wapiti, Grabber, OWASP Zed Attack Proxy, XSSer, sqlmap, etc). This web application security scanner would be in addition to Qulays QG and OpenVAS/Nessus. While many "network" vulnerability scanners claim to find issues such as SQL injection -- in reality they do not actually do so to any degree of completeness (for more information, see the WIVET.googlecode.com and WAVSEP.googlecode.com scanner benchmarks, or run them for yourself). If you are looking for penetration-testing, this cannot be done with a single tool, or even multiple tools. You need strong people with a good track record of experience in penetration-testing. I have seen a few shops run some free tools (e.g. Cain & Abel) along with some commercial tools (e.g. Paterva Maltego, Metasploit Pro, Core Impact, and Burp Suite Professional), with some added open-source tools (e.g. BackTrack 5 and the Social Engineering Toolkit). WiFi penetration-testing is often done with two USB Alfa Networks cards and a guest VM, such as Immunity Security's SILICA. However, depending on your industry vertical and/or specific requirements -- you'll want a custom pen-test that will involve strategy consulting and threat-modeling beforehand. I don't recommend trying to do this on your own. If you do want to attempt pen-testing on your own, I recommend the BlackHat conference official training for Maltego and Burp Suite Professional, in addition to deep technical knowledge of all of the modules and features available in BackTrack and the Metasploit Framework (the new NoStach Press book on Metasploit -- and the less useful but handy Packt Publishing book on BackTrack Penetration Testing -- would be a good start). Cheers, Andre From rubensk at gmail.com Tue Jul 12 16:55:10 2011 From: rubensk at gmail.com (Rubens Kuhl) Date: Tue, 12 Jul 2011 18:55:10 -0300 Subject: best practices for management nets in IPv6 In-Reply-To: References: Message-ID: On Tue, Jul 12, 2011 at 6:31 PM, Tom Ammon wrote: > Hi All, > > We're pushing to get IPv6 deployed and working everywhere in our operation, and I had some questions about best practices for a few things. > > On your management nets (network device management nets) , what's the best approach for addressing them? Do you use ULA? Or do you use ?global addresses and just depend on router ACLs to protect things? How close are we to having a central registry for unique local addresses, and will that really happen? What if you apply to a /48 block as end-user because the management network is not part of your ISP-related /32 or larger block ? What if you happen to get that /48 and never announce it to the DFZ ? Then your attack surface gets very small (but still exists, you'll need some ACLs here and there, notably your customers having default-routes to your core). Rubens From cb.list6 at gmail.com Tue Jul 12 18:29:33 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Tue, 12 Jul 2011 16:29:33 -0700 Subject: best practices for management nets in IPv6 In-Reply-To: References: Message-ID: On Jul 12, 2011 2:33 PM, "Tom Ammon" wrote: > > Hi All, > > We're pushing to get IPv6 deployed and working everywhere in our operation, and I had some questions about best practices for a few things. > > On your management nets (network device management nets) , what's the best approach for addressing them? Do you use ULA? Or do you use global addresses and just depend on router ACLs to protect things? How close are we to having a central registry for unique local addresses, and will that really happen? > ACL are prone to typos and inconsistent deployment. If the security policy is that a give interface must not talk to the internet, ULA is a good choice as part of a multi-layer security strategy Cb > Tom > > ----------------------------------------------------------------------------- > Tom Ammon > Network Engineer > M: (801)674-9273 > tom.ammon at utah.edu > > Center for High Performance Computing > University of Utah > http://www.chpc.utah.edu > ----------------------------------------------------------------------------- > > From bensons at queuefull.net Tue Jul 12 18:57:04 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 12 Jul 2011 18:57:04 -0500 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> Message-ID: On Jul 11, 2011, at 7:19 PM, Jeff Wheeler wrote: > Again, this is only hard to understand (or accept) if you don't know > how your routers work. > * why do you think there is an ARP and ND table? > * why do you think there are policers to protect the CPU from > excessive ARP/ND punts or traffic? > * do you even know the limit of your boxes' ARP / ND tables? Do you > realize that limit is a tiny fraction of one /64? > * do you understand what happens when your ARP/ND policers are reached? > * did you think about the impact on neighboring routers and protocol > next-hops, not just servers? > * did you every try to deploy a /16 on a flat LAN with a lot of hosts > and see what happens? Doesn't work too well. A v6 /64 is 281 > trillion times bigger than a v4 /16. There's no big leap of logic > here as to why one rogue machine could break your LAN. FYI, in case you're interested in these topics, the IETF working group ARMD was chartered to explore address resolution scale. I'm one of the co-chairs. It's in the Operations Area, and we'd love to have more operators involved - if you're willing to contribute, your input will help set the direction. (If operators don't contribute, it will be just another vendor-led circle... well, you know the score.) For details please see http://tools.ietf.org/wg/armd/charters. Cheers, -Benson From randy at psg.com Tue Jul 12 19:21:21 2011 From: randy at psg.com (Randy Bush) Date: Wed, 13 Jul 2011 09:21:21 +0900 Subject: in defense of lisp (was: Anybody can participate in the IETF) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> Message-ID: > W.R.T. to LISP, in defense of the IETF or the IRTF, i do not believe > "the IETF" has told the world that LISP is the best fit for the > Internet or solves any specific problem well. > > The IETF has never said the "Internet Architecture" is going to LISP, > and it likely will not / cannot. My expectation is that LISP will go > away as quickly as it came. i will not dispute this, not my point. but i have to respect dino and the lisp fanboys (and, yes, they are all boys) for actually *doing* something after 30 years of loc/id blah blah blah (as did hip). putting their, well dino's, code where their mouths were and going way out on a limb. i am *not* saying i would run it in an operational network. but maz-san and i were happy to help the experiment by dropping the first asian node in a test rack on the public net. randy From jmaslak at antelope.net Tue Jul 12 19:32:55 2011 From: jmaslak at antelope.net (Joel Maslak) Date: Tue, 12 Jul 2011 18:32:55 -0600 Subject: best practices for management nets in IPv6 In-Reply-To: References: Message-ID: <339D6250-1106-4590-8AC9-592A78351216@antelope.net> Public IPs. At some point you will have to manage something outside your current world or your organization will need to merge/partner/outsource/contract/etc with someone else's network and they might not be keen to route to your ULA space (and might not be more trustworthy than the internet at large anyhow). Think about things like VPN endpoints, video devices, telephones, etc, that may end up on a public network, maybe behind a device you manage. You may just manage routers today, but who knows about tomorrow. Put behind a firewall and use good ingress filtering throughout your network, separating trust zones with distinct subnets. If you are worried about forgetting to enable a firewall, put in a network management system to verify connectivity stays blocked combined with a monitored IDS. From marka at isc.org Tue Jul 12 20:41:39 2011 From: marka at isc.org (Mark Andrews) Date: Wed, 13 Jul 2011 11:41:39 +1000 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: Your message of "Tue, 12 Jul 2011 14:21:11 MST." <56E0FB8F-BB53-4DB0-829B-39DFBAB483E8@bogus.com> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <56E0FB8F-BB53-4DB0-829B-39DFBAB483E8@bogus.com> Message-ID: <20110713014139.92A4611CB398@drugs.dv.isc.org> In message <56E0FB8F-BB53-4DB0-829B-39DFBAB483E8 at bogus.com>, Joel Jaeggli write s: > > On Jul 12, 2011, at 12:53 PM, Owen DeLong wrote: > > >=20 > > On Jul 12, 2011, at 8:43 AM, Cameron Byrne wrote: > >=20 > >> On Tue, Jul 12, 2011 at 8:28 AM, Ronald Bonica = > wrote: > >>> Leo, > >>>=20 > >>> Maybe we can fix this by: > >>>=20 > >>> a) bringing together larger groups of clueful operators in the IETF > >>> b) deciding which issues interest them > >>> c) showing up and being vocal as a group in protocol developing = > working groups > >>>=20 > >>> To some degree, we already do this in the IETF OPS area, but judging = > by your comments, we don't do it nearly enough. > >>>=20 > >>> Comments? > >>>=20 > >>=20 > >> There may be an OPS area, but it is not listened to. > >>=20 > >> Witness the latest debacle with the attempt at trying to make 6to4 = > historic. > >>=20 > >> Various "non-practicing entities" were able to derail what network > >> operators largely supported. Since the IETF failed to make progress > >> operators will do other things to stop 6to4 ( i have heard no AAAA > >> over IPv4 transport, blackhole 6to4 anycast, decom relay routers...) > >>=20 > > Those are all REALLY bad ideas. Speaking as an operator, the best = > thing you > > can do to alleviate the problems with 6to4 is operate more, not less = > 6to4 > > relays. > > Unless of course the large providers get their shared transition space = > in which case all 6to4 behind it will break in a really ugly way, pretty = > much exactly like in the mobile operator in question.=20 And would deploying draft-andrews-v6ops-6to4-router-option-02.txt and/or adding router reachability tests have addressed this issue? > The goal of 6to4 to historic was not to encourage the outcome described, = > it was to take having 6to4 as a default method of any kind off the table = > going into the future. If mature adults want to use it great, but = > conformance tests shouldn't require it, CPE shouldn't it on just because = > what they think they have a is a public IP with not filtering and hosts = > shouldn't use it unless told to do so.. But that is *not* what the draft did. Making the protocol historic did LOTS more than that. I think there was universal consensus that 6to4 should be off by default. There was this nuke 6to4 from orbit attitude which did nothing to help with already deployed/shipped boxes. 6to4 historic is actually harmful for dealing with the existing problems as it tells vendors not to include 6to4 support in future products which means operators won't have boxes with fixes to other problems to alleviate the problems cause but the currently deployed customer boxes. What would have been much better would have been to encourage CPE vendors to release images which address some of the known issues. Just adding a check box saying "enable 6to4" and for ISP to send out email to say "check your router vendor web site for fixed images". The better fix would be to get them to also add support for draft-andrews-v6ops-6to4-router-option-02.txt which greys out the checkbox when 0.0.0.0 is sent as a response to the option. Remember operators are in the position to alleviate lots of the 6to4 issues themselves. > > Blocking AAAA over IPv4 transport is just silly. It's just as likely = > that your > > AAAA record is destined for an end-host that has native IPv6 = > connectivity > > with an intermediate resolver that desn't have IPv6 as it is that = > you're > > sending that to a 6to4 host. Further, there's no reason to believe the > > 6to4 host won't attempt to resolve via IPv6, so, it doesn't really = > help > > anyway. > >=20 > >> Real network operators have a relatively low BS threshold, they have > >> customers to support and businesses to run, and they don't have = > thumb > >> wrestle these people who don't actually have any skin in the game. > >>=20 > > I agree, but, it's not hard to run 6to4 relays and running them does = > much > > more to alleviate the problems with 6to4 than anything you proposed > > above. Indeed, what you proposed above will likely create more = > customer > > issues rather than reduce them. > >=20 > > Owen > >=20 > >> Cameron > >>=20 > >>=20 > >>> Ron > >>>=20 > >>>=20 > >>> -----Original Message----- > >>> From: Leo Bicknell [mailto:bicknell at ufp.org] > >>> Sent: Monday, July 11, 2011 3:35 PM > >>> To: nanog at nanog.org > >>> Subject: Re: Anybody can participate in the IETF (Was: Why is IPv6 = > broken?) > >>>=20 > >>> In a message written on Sun, Jul 10, 2011 at 06:16:09PM +0200, = > Jeroen Massar wrote: > >>>> Ehmmmm ANYBODY, including you, can sign up to the IETF mailing = > lists > >>>> and participate there, just like a couple of folks from NANOG are = > already doing. > >>>=20 > >>> The way the IETF and the operator community interact is badly = > broken. > >>>=20 > >>> The IETF does not want operators in many steps of the process. If = > you try to bring up operational concerns in early protocol development = > for example you'll often get a "we'll look at that later" response, = > which in many cases is right. Sometimes you just have to play with = > something before you worry about the operational details. It also does = > not help that many operational types are not hardcore programmers, and = > can't play in the sandbox during the major development cycles. > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >=20 > >=20 > >=20 > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mysidia at gmail.com Tue Jul 12 21:05:53 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 12 Jul 2011 21:05:53 -0500 Subject: NANOG List Update - Moving Forward In-Reply-To: <4E1C758A.10604@gmail.com> References: <201107121507.p6CF7i7h033220@mail.r-bonomi.com> <409E5316D8C0514F9E6B49DB5FBBBB98038855DC@exch2008.torrance.interworld.net> <4E1C758A.10604@gmail.com> Message-ID: On Tue, Jul 12, 2011 at 11:25 AM, -Hammer- wrote: > The tolerance of some of you out there is amazing. You must be PS3 users > crying because your free game network is down. Maybe we can get a PS3net users had a right to cry.. because their 'free' game network is not really free, and they bought a nice console that became a brick for indefinite amounts of time.... > Be patient people. Maybe a little appreciation to these experts wouldn't > hurt you either. Patience is gold, but operating or migrating a listserv is not rocket science, and it cuts both ways. Only a certain amount of patience is warranted for any particular situation, and it appears posters have the warranted amount of tolerance. For now I am appreciative of Robert Bonomi and Brielle Bruns for identifying issues. I'll be happy to express appreciation, as soon as the "experts" get it done and get it right; right now I'm just keeping my fingers crossed and hoping to hear the news that the issues are addressed and everything's perfect. In the mean time; I am glad that the deficiencies witnessed are being reported. And hope the experts are learning, and at least taking the reports seriously, esp. regards to non-member posting, spam, "undisclosed-recipients" mess, and header issues/ oddball "bulk_mailer" identification... NANOG as an operators list should not itself become an example of poor operator practice; or poor planning/change management; that would be an embarassment. > -Hammer- -- -JH From owen at delong.com Tue Jul 12 21:20:34 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 12 Jul 2011 19:20:34 -0700 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: <56E0FB8F-BB53-4DB0-829B-39DFBAB483E8@bogus.com> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <56E0FB8F-BB53-4DB0-829B-39DFBAB483E8@bogus.com> Message-ID: On Jul 12, 2011, at 2:21 PM, Joel Jaeggli wrote: > > On Jul 12, 2011, at 12:53 PM, Owen DeLong wrote: > >> >> On Jul 12, 2011, at 8:43 AM, Cameron Byrne wrote: >> >>> On Tue, Jul 12, 2011 at 8:28 AM, Ronald Bonica wrote: >>>> Leo, >>>> >>>> Maybe we can fix this by: >>>> >>>> a) bringing together larger groups of clueful operators in the IETF >>>> b) deciding which issues interest them >>>> c) showing up and being vocal as a group in protocol developing working groups >>>> >>>> To some degree, we already do this in the IETF OPS area, but judging by your comments, we don't do it nearly enough. >>>> >>>> Comments? >>>> >>> >>> There may be an OPS area, but it is not listened to. >>> >>> Witness the latest debacle with the attempt at trying to make 6to4 historic. >>> >>> Various "non-practicing entities" were able to derail what network >>> operators largely supported. Since the IETF failed to make progress >>> operators will do other things to stop 6to4 ( i have heard no AAAA >>> over IPv4 transport, blackhole 6to4 anycast, decom relay routers...) >>> >> Those are all REALLY bad ideas. Speaking as an operator, the best thing you >> can do to alleviate the problems with 6to4 is operate more, not less 6to4 >> relays. > > Unless of course the large providers get their shared transition space in which case all 6to4 behind it will break in a really ugly way, pretty much exactly like in the mobile operator in question. > Actually, if those same providers run 6to4 gateways/routers on their networks in that shared transition space with public IPv6 addresses on the exterior, it would not break at all. As I said, the resolution to the 6to4 problems described is to run MORE, not less 6to4 gateways. > The goal of 6to4 to historic was not to encourage the outcome described, it was to take having 6to4 as a default method of any kind off the table going into the future. If mature adults want to use it great, but conformance tests shouldn't require it, CPE shouldn't it on just because what they think they have a is a public IP with not filtering and hosts shouldn't use it unless told to do so.. > I have no problem with saying 6to4 should not be enabled by default. However, that doesn't change the fact that the best way to resolve things given current shipping software and hardware is to deploy 6to4 gateways in the appropriate places. Owen >> Blocking AAAA over IPv4 transport is just silly. It's just as likely that your >> AAAA record is destined for an end-host that has native IPv6 connectivity >> with an intermediate resolver that desn't have IPv6 as it is that you're >> sending that to a 6to4 host. Further, there's no reason to believe the >> 6to4 host won't attempt to resolve via IPv6, so, it doesn't really help >> anyway. >> >>> Real network operators have a relatively low BS threshold, they have >>> customers to support and businesses to run, and they don't have thumb >>> wrestle these people who don't actually have any skin in the game. >>> >> I agree, but, it's not hard to run 6to4 relays and running them does much >> more to alleviate the problems with 6to4 than anything you proposed >> above. Indeed, what you proposed above will likely create more customer >> issues rather than reduce them. >> >> Owen >> >>> Cameron >>> >>> >>>> Ron >>>> >>>> >>>> -----Original Message----- >>>> From: Leo Bicknell [mailto:bicknell at ufp.org] >>>> Sent: Monday, July 11, 2011 3:35 PM >>>> To: nanog at nanog.org >>>> Subject: Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?) >>>> >>>> In a message written on Sun, Jul 10, 2011 at 06:16:09PM +0200, Jeroen Massar wrote: >>>>> Ehmmmm ANYBODY, including you, can sign up to the IETF mailing lists >>>>> and participate there, just like a couple of folks from NANOG are already doing. >>>> >>>> The way the IETF and the operator community interact is badly broken. >>>> >>>> The IETF does not want operators in many steps of the process. If you try to bring up operational concerns in early protocol development for example you'll often get a "we'll look at that later" response, which in many cases is right. Sometimes you just have to play with something before you worry about the operational details. It also does not help that many operational types are not hardcore programmers, and can't play in the sandbox during the major development cycles. >>>> >>>> >>>> >>>> >> >> >> From cb.list6 at gmail.com Tue Jul 12 22:41:42 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Tue, 12 Jul 2011 20:41:42 -0700 Subject: in defense of lisp (was: Anybody can participate in the IETF) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> Message-ID: On Jul 12, 2011 5:21 PM, "Randy Bush" wrote: > > > W.R.T. to LISP, in defense of the IETF or the IRTF, i do not believe > > "the IETF" has told the world that LISP is the best fit for the > > Internet or solves any specific problem well. > > > > The IETF has never said the "Internet Architecture" is going to LISP, > > and it likely will not / cannot. My expectation is that LISP will go > > away as quickly as it came. > > i will not dispute this, not my point. but i have to respect dino and > the lisp fanboys (and, yes, they are all boys) for actually *doing* > something after 30 years of loc/id blah blah blah (as did hip). putting > their, well dino's, code where their mouths were and going way out on a > limb. > Understood. But watch for similarities between 6to4 and LISP. Both are clever, both have great intentions, both are extremely dangerous once people start thinking this is anything beyond a toy. And when lowly plebeians like myself hear that research folks at iij and Facebook are doing "something" with LISP, we think that is a blessing of this technology. But, after the "fan boy" chatter dies down, you hear that this is not actually support, it's just engineers doing "Dino" a favor. I admittedly have dismissed LISP early on and do not understand its merits , the idea of ip in ip tunnels as the new internet architecture gives me indigestion. I am also concerned about the questionable business case of why edge networks would make investments to bail out DFZ providers (the main point of LISP). If ipv6 was a hard sell, I can't even imagine making LISP get traction. If the economics are not right, it will never fly, and the economics of LISP are all wrong. Please, spare me line about how LISP is just a knob I turn and has no cost. I fear that at its worst and most successful, LISP ensures ipv4 is the backbone transport media to the detriment of ipv6 and at its best, it is a distraction for folks that need to be making ipv6 work, for real. Cb PS. I think the research guys should give more time to ILNP and creating a graceful unwind of ipv4 and NAT. The dividends from ipv6 only start to really pay when ipv4 becomes optional. My 2 cents, and no more. > i am *not* saying i would run it in an operational network. but maz-san > and i were happy to help the experiment by dropping the first asian node > in a test rack on the public net. > > randy From ljb at merit.edu Tue Jul 12 22:46:31 2011 From: ljb at merit.edu (Larry J. Blunk) Date: Tue, 12 Jul 2011 23:46:31 -0400 (EDT) Subject: NANOG List Update - Moving Forward In-Reply-To: Message-ID: <13c63093-9701-4865-b39a-6ce0b6cdd0a6@merit-mailstore01> ----- Original Message ----- > > On Jul 12, 2011, at 12:23 PM, Brielle Bruns wrote: > > > Looks like parts of the received like are still there, though > > butchered and mashed in (most likely in a non-RFC compliant > > manner) with the one added by 'bulk_maler v1.13' (great name for > > the mailer, btw, sets off my spammy sense something fierce). > > You seem to be new here. > > bulk_mailer was something used back in the day to workaround > limitations in sendmail for those people operating majordomo (and > those using smail etc). it broke the chunks into something that > sendmail would then allocate multiple processes to. most other mail > subsystems can handle the multiple-rcpts in different manners. > > while it may 'feel' spammy to you, it's certainly not. > > a simple google of "majordomo and bulk_mailer" should give you a good > idea of what's going on. > > there were a lot of other mail systems that served to help integrate > and interoperate back in the day, including qmailer, smail, etc that > all attempted to replace sendmail, including providing the uucp > interaction necessary for those behind dialup. > > either way, please try to keep the feedback off-list for now as we > undergo this transition. It's hard to move a large list like this > without trouble. I've been party to many such list moves in the > past and they usually have all sorts of trouble. > > admins at nanog.org is the right place for your feedback right now. > > - Jared > Feeling a bit of D?j? vu as I deployed bulk_mailer for the NANOG list back in November of 1996. It used sendmail+bulk_mailer for delivery until March of 1999 when we transitioned to Postfix. It was transitioned again in April 2008 to Exim and Mailman. Unfortunately, my memory is a bit hazy on whether there were any specific issues with bulk_mailer that caused the switch to Postfix. My main concern with the bulk_mailer code is that it hasn't been touched in over a decade -- ftp://cs.utk.edu/pub/moore/bulk_mailer I've have some concerns with AMS based on my experience with the IETF mailing list. It has had ongoing issues with out-of-sequence delivery. Based on the Received headers, it's seems pretty clear the re-ordering is occurring internal to the AMS servers. It appears they may be trying something different with the NANOG list as the IETF list does not employ bulk_mailer. -Larry From mksmith at adhost.com Tue Jul 12 22:46:59 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Wed, 13 Jul 2011 03:46:59 +0000 Subject: NANOG Updates - Important Message-ID: Thank you for your patience as we moved forward with our NANOG transition. We are excited to announce the opening of NANOG 53 registration. You will notice a new format and the need to create a user id and password to complete your registration. We are confident you will find the new system very intuitive and helpful as we continue to move forward. As always, there are opportunities to improve. Feel free to send any questions, suggestions, or concerns to nanog-support at nanog.org With respect to NANOG list services. The NANOG Board has decided not to move forward with the mail list and archive transition from Mailman to ARO at this time. For the time being we are operating on our existing hardware in Ann Arbor, MI. We will however, be preparing for a move to an alternate site. As we confirm further details we will be sure to send them along to you. Again, if you have any questions, suggestions, or concerns please send them to nanog-support at nanog.org. Sincerely, Michael K. Smith NANOG CC Chair From cb.list6 at gmail.com Tue Jul 12 22:48:29 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Tue, 12 Jul 2011 20:48:29 -0700 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: <20110713014139.92A4611CB398@drugs.dv.isc.org> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <56E0FB8F-BB53-4DB0-829B-39DFBAB483E8@bogus.com> <20110713014139.92A4611CB398@drugs.dv.isc.org> Message-ID: On Jul 12, 2011 6:42 PM, "Mark Andrews" wrote: > > > In message <56E0FB8F-BB53-4DB0-829B-39DFBAB483E8 at bogus.com>, Joel Jaeggli write > s: > > > > On Jul 12, 2011, at 12:53 PM, Owen DeLong wrote: > > > > >=20 > > > On Jul 12, 2011, at 8:43 AM, Cameron Byrne wrote: > > >=20 > > >> On Tue, Jul 12, 2011 at 8:28 AM, Ronald Bonica = > > wrote: > > >>> Leo, > > >>>=20 > > >>> Maybe we can fix this by: > > >>>=20 > > >>> a) bringing together larger groups of clueful operators in the IETF > > >>> b) deciding which issues interest them > > >>> c) showing up and being vocal as a group in protocol developing = > > working groups > > >>>=20 > > >>> To some degree, we already do this in the IETF OPS area, but judging = > > by your comments, we don't do it nearly enough. > > >>>=20 > > >>> Comments? > > >>>=20 > > >>=20 > > >> There may be an OPS area, but it is not listened to. > > >>=20 > > >> Witness the latest debacle with the attempt at trying to make 6to4 = > > historic. > > >>=20 > > >> Various "non-practicing entities" were able to derail what network > > >> operators largely supported. Since the IETF failed to make progress > > >> operators will do other things to stop 6to4 ( i have heard no AAAA > > >> over IPv4 transport, blackhole 6to4 anycast, decom relay routers...) > > >>=20 > > > Those are all REALLY bad ideas. Speaking as an operator, the best = > > thing you > > > can do to alleviate the problems with 6to4 is operate more, not less = > > 6to4 > > > relays. > > > > Unless of course the large providers get their shared transition space = > > in which case all 6to4 behind it will break in a really ugly way, pretty = > > much exactly like in the mobile operator in question.=20 > > And would deploying draft-andrews-v6ops-6to4-router-option-02.txt and/or > adding router reachability tests have addressed this issue? > > > The goal of 6to4 to historic was not to encourage the outcome described, = > > it was to take having 6to4 as a default method of any kind off the table = > > going into the future. If mature adults want to use it great, but = > > conformance tests shouldn't require it, CPE shouldn't it on just because = > > what they think they have a is a public IP with not filtering and hosts = > > shouldn't use it unless told to do so.. > > But that is *not* what the draft did. Making the protocol historic > did LOTS more than that. I think there was universal consensus > that 6to4 should be off by default. > > There was this nuke 6to4 from orbit attitude which did nothing to > help with already deployed/shipped boxes. 6to4 historic is actually > harmful for dealing with the existing problems as it tells vendors > not to include 6to4 support in future products which means operators > won't have boxes with fixes to other problems to alleviate the > problems cause but the currently deployed customer boxes. > > What would have been much better would have been to encourage CPE > vendors to release images which address some of the known issues. > Just adding a check box saying "enable 6to4" and for ISP to send > out email to say "check your router vendor web site for fixed > images". The better fix would be to get them to also add support > for draft-andrews-v6ops-6to4-router-option-02.txt which greys out > the checkbox when 0.0.0.0 is sent as a response to the option. > > Remember operators are in the position to alleviate lots of the > 6to4 issues themselves. > But they will not. If there is not a revenue forecast, there is no project. That said, CGN is moving forward as a "keep the lights on" initiative.... as is real native v6. I don't care to rehash this yet again with no progress. Cb. > > > Blocking AAAA over IPv4 transport is just silly. It's just as likely = > > that your > > > AAAA record is destined for an end-host that has native IPv6 = > > connectivity > > > with an intermediate resolver that desn't have IPv6 as it is that = > > you're > > > sending that to a 6to4 host. Further, there's no reason to believe the > > > 6to4 host won't attempt to resolve via IPv6, so, it doesn't really = > > help > > > anyway. > > >=20 > > >> Real network operators have a relatively low BS threshold, they have > > >> customers to support and businesses to run, and they don't have = > > thumb > > >> wrestle these people who don't actually have any skin in the game. > > >>=20 > > > I agree, but, it's not hard to run 6to4 relays and running them does = > > much > > > more to alleviate the problems with 6to4 than anything you proposed > > > above. Indeed, what you proposed above will likely create more = > > customer > > > issues rather than reduce them. > > >=20 > > > Owen > > >=20 > > >> Cameron > > >>=20 > > >>=20 > > >>> Ron > > >>>=20 > > >>>=20 > > >>> -----Original Message----- > > >>> From: Leo Bicknell [mailto:bicknell at ufp.org] > > >>> Sent: Monday, July 11, 2011 3:35 PM > > >>> To: nanog at nanog.org > > >>> Subject: Re: Anybody can participate in the IETF (Was: Why is IPv6 = > > broken?) > > >>>=20 > > >>> In a message written on Sun, Jul 10, 2011 at 06:16:09PM +0200, = > > Jeroen Massar wrote: > > >>>> Ehmmmm ANYBODY, including you, can sign up to the IETF mailing = > > lists > > >>>> and participate there, just like a couple of folks from NANOG are = > > already doing. > > >>>=20 > > >>> The way the IETF and the operator community interact is badly = > > broken. > > >>>=20 > > >>> The IETF does not want operators in many steps of the process. If = > > you try to bring up operational concerns in early protocol development = > > for example you'll often get a "we'll look at that later" response, = > > which in many cases is right. Sometimes you just have to play with = > > something before you worry about the operational details. It also does = > > not help that many operational types are not hardcore programmers, and = > > can't play in the sandbox during the major development cycles. > > >>>=20 > > >>>=20 > > >>>=20 > > >>>=20 > > >=20 > > >=20 > > >=20 > > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From joelja at bogus.com Tue Jul 12 23:48:19 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 12 Jul 2011 21:48:19 -0700 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <56E0FB8F-BB53-4DB0-829B-39DFBAB483E8@bogus.com> Message-ID: <1BB85C22-3115-4D55-8A34-8C8E47976F8A@bogus.com> On Jul 12, 2011, at 7:20 PM, Owen DeLong wrote: > > On Jul 12, 2011, at 2:21 PM, Joel Jaeggli wrote: > >> >> On Jul 12, 2011, at 12:53 PM, Owen DeLong wrote: >> >>> >>> On Jul 12, 2011, at 8:43 AM, Cameron Byrne wrote: >>> >>>> On Tue, Jul 12, 2011 at 8:28 AM, Ronald Bonica wrote: >>>>> Leo, >>>>> >>>>> Maybe we can fix this by: >>>>> >>>>> a) bringing together larger groups of clueful operators in the IETF >>>>> b) deciding which issues interest them >>>>> c) showing up and being vocal as a group in protocol developing working groups >>>>> >>>>> To some degree, we already do this in the IETF OPS area, but judging by your comments, we don't do it nearly enough. >>>>> >>>>> Comments? >>>>> >>>> >>>> There may be an OPS area, but it is not listened to. >>>> >>>> Witness the latest debacle with the attempt at trying to make 6to4 historic. >>>> >>>> Various "non-practicing entities" were able to derail what network >>>> operators largely supported. Since the IETF failed to make progress >>>> operators will do other things to stop 6to4 ( i have heard no AAAA >>>> over IPv4 transport, blackhole 6to4 anycast, decom relay routers...) >>>> >>> Those are all REALLY bad ideas. Speaking as an operator, the best thing you >>> can do to alleviate the problems with 6to4 is operate more, not less 6to4 >>> relays. >> >> Unless of course the large providers get their shared transition space in which case all 6to4 behind it will break in a really ugly way, pretty much exactly like in the mobile operator in question. >> > > Actually, if those same providers run 6to4 gateways/routers on their networks > in that shared transition space with public IPv6 addresses on the exterior, > it would not break at all. arin 2011-5 specfically cites numbering cpe in space as the justification for deployment. the cpe therefore have to be natted and you are implying that you'll be natting the 6to4, overall I'd put that in the less desirable category as far as violating expectations go... > As I said, the resolution to the 6to4 problems described is to run MORE, not > less 6to4 gateways. Are you advocating draft-kuarsingh-v6ops-6to4-provider-managed-tunnel? http://tools.ietf.org/html/draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-02 > >> The goal of 6to4 to historic was not to encourage the outcome described, it was to take having 6to4 as a default method of any kind off the table going into the future. If mature adults want to use it great, but conformance tests shouldn't require it, CPE shouldn't it on just because what they think they have a is a public IP with not filtering and hosts shouldn't use it unless told to do so.. >> > > I have no problem with saying 6to4 should not be enabled by default. However, > that doesn't change the fact that the best way to resolve things given current shipping > software and hardware is to deploy 6to4 gateways in the appropriate places. and we have http://tools.ietf.org/html/draft-ietf-v6ops-6to4-advisory-02 The fact of the matter is more 6to4 relays is only an anodyne as is rejiggering the address selection priority, the pain may go down it won't go away. > Owen > >>> Blocking AAAA over IPv4 transport is just silly. It's just as likely that your >>> AAAA record is destined for an end-host that has native IPv6 connectivity >>> with an intermediate resolver that desn't have IPv6 as it is that you're >>> sending that to a 6to4 host. Further, there's no reason to believe the >>> 6to4 host won't attempt to resolve via IPv6, so, it doesn't really help >>> anyway. >>> >>>> Real network operators have a relatively low BS threshold, they have >>>> customers to support and businesses to run, and they don't have thumb >>>> wrestle these people who don't actually have any skin in the game. >>>> >>> I agree, but, it's not hard to run 6to4 relays and running them does much >>> more to alleviate the problems with 6to4 than anything you proposed >>> above. Indeed, what you proposed above will likely create more customer >>> issues rather than reduce them. >>> >>> Owen >>> >>>> Cameron >>>> >>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Leo Bicknell [mailto:bicknell at ufp.org] >>>>> Sent: Monday, July 11, 2011 3:35 PM >>>>> To: nanog at nanog.org >>>>> Subject: Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?) >>>>> >>>>> In a message written on Sun, Jul 10, 2011 at 06:16:09PM +0200, Jeroen Massar wrote: >>>>>> Ehmmmm ANYBODY, including you, can sign up to the IETF mailing lists >>>>>> and participate there, just like a couple of folks from NANOG are already doing. >>>>> >>>>> The way the IETF and the operator community interact is badly broken. >>>>> >>>>> The IETF does not want operators in many steps of the process. If you try to bring up operational concerns in early protocol development for example you'll often get a "we'll look at that later" response, which in many cases is right. Sometimes you just have to play with something before you worry about the operational details. It also does not help that many operational types are not hardcore programmers, and can't play in the sandbox during the major development cycles. >>>>> >>>>> >>>>> >>>>> >>> >>> >>> > > From joelja at bogus.com Tue Jul 12 23:50:43 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 12 Jul 2011 21:50:43 -0700 Subject: NANOG List Update - Moving Forward In-Reply-To: <13c63093-9701-4865-b39a-6ce0b6cdd0a6@merit-mailstore01> References: <13c63093-9701-4865-b39a-6ce0b6cdd0a6@merit-mailstore01> Message-ID: <6219118D-A679-47B3-8E46-355116299FC5@bogus.com> On Jul 12, 2011, at 8:46 PM, Larry J. Blunk wrote: > > I've have some concerns with AMS based on my experience > with the IETF mailing list. It has had ongoing issues with > out-of-sequence delivery. Based on the Received headers, it's > seems pretty clear the re-ordering is occurring internal to the > AMS servers. It appears they may be trying something different > with the NANOG list as the IETF list does not employ bulk_mailer. ietf.org is mailman and postfix. > -Larry > > > > > From ljb at merit.edu Wed Jul 13 00:11:47 2011 From: ljb at merit.edu (Larry J. Blunk) Date: Wed, 13 Jul 2011 01:11:47 -0400 (EDT) Subject: NANOG List Update - Moving Forward In-Reply-To: <6219118D-A679-47B3-8E46-355116299FC5@bogus.com> Message-ID: <27af77ae-59ea-45f9-97b5-487808c7350d@merit-mailstore01> ----- Original Message ----- > > On Jul 12, 2011, at 8:46 PM, Larry J. Blunk wrote: > > > > I've have some concerns with AMS based on my experience > > with the IETF mailing list. It has had ongoing issues with > > out-of-sequence delivery. Based on the Received headers, it's > > seems pretty clear the re-ordering is occurring internal to the > > AMS servers. It appears they may be trying something different > > with the NANOG list as the IETF list does not employ bulk_mailer. > > ietf.org is mailman and postfix. > > Right, should have mentioned that. Here's the Received headers from a message yesterday that apparently had a 23 hour delay internal to ietfa.amsl.org. You can also see it is out of sequence in the IETF mailing list archives. There are some other recent emails that were sent on July 8th and did not get delivered until Juth 11th. -Larry Received: from mail.ietf.org ([64.170.98.30]) by sfpop-ironport04.merit.edu with ESMTP; 12 Jul 2011 11:06:29 -0400 Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7027F21F8CB4; Tue, 12 Jul 2011 08:06:29 -0700 (PDT) X-Original-To: ietf at ietfa.amsl.com Delivered-To: ietf at ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D7D21F8E58 for ; Mon, 11 Jul 2011 09:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAHKv2903pQw for ; Mon, 11 Jul 2011 09:01:31 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id CE6E321F8E4F for ; Mon, 11 Jul 2011 09:01:26 -0700 (PDT) Received: from dn3-227.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p6BG1O4H054438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 11 Jul 2011 11:01:25 -0500 (CDT) (envelope-from ben at nostrum.com) Subject: Re: [Gen-art] Gen-ART LC Review of draft-ietf-dnsext-rfc2672bis-dname-22 Mime-Version: 1.0 (Apple Message framework v1084) From: Ben Campbell In-Reply-To: Date: Mon, 11 Jul 2011 11:01:23 -0500 Message-Id: <5BB77043-1674-4FD6-87CB-17DDC1CEEC1C at nostrum.com> From joelja at bogus.com Wed Jul 13 00:16:20 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 12 Jul 2011 22:16:20 -0700 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: <20110713014139.92A4611CB398@drugs.dv.isc.org> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <56E0FB8F-BB53-4DB0-829B-39DFBAB483E8@bogus.com> <20110713014139.92A4611CB398@drugs.dv.isc.org> Message-ID: <9C391C3A-3535-4C47-A743-57287685942E@bogus.com> On Jul 12, 2011, at 6:41 PM, Mark Andrews wrote: > > In message <56E0FB8F-BB53-4DB0-829B-39DFBAB483E8 at bogus.com>, Joel Jaeggli write > s: >> >> On Jul 12, 2011, at 12:53 PM, Owen DeLong wrote: >> >>> =20 >>> On Jul 12, 2011, at 8:43 AM, Cameron Byrne wrote: >>> =20 >>>> On Tue, Jul 12, 2011 at 8:28 AM, Ronald Bonica = >> wrote: >>>>> Leo, >>>>> =20 >>>>> Maybe we can fix this by: >>>>> =20 >>>>> a) bringing together larger groups of clueful operators in the IETF >>>>> b) deciding which issues interest them >>>>> c) showing up and being vocal as a group in protocol developing = >> working groups >>>>> =20 >>>>> To some degree, we already do this in the IETF OPS area, but judging = >> by your comments, we don't do it nearly enough. >>>>> =20 >>>>> Comments? >>>>> =20 >>>> =20 >>>> There may be an OPS area, but it is not listened to. >>>> =20 >>>> Witness the latest debacle with the attempt at trying to make 6to4 = >> historic. >>>> =20 >>>> Various "non-practicing entities" were able to derail what network >>>> operators largely supported. Since the IETF failed to make progress >>>> operators will do other things to stop 6to4 ( i have heard no AAAA >>>> over IPv4 transport, blackhole 6to4 anycast, decom relay routers...) >>>> =20 >>> Those are all REALLY bad ideas. Speaking as an operator, the best = >> thing you >>> can do to alleviate the problems with 6to4 is operate more, not less = >> 6to4 >>> relays. >> >> Unless of course the large providers get their shared transition space = >> in which case all 6to4 behind it will break in a really ugly way, pretty = >> much exactly like in the mobile operator in question.=20 > > And would deploying draft-andrews-v6ops-6to4-router-option-02.txt and/or > adding router reachability tests have addressed this issue? Neither of these approaches address existing cpe, and shared transtion space is justified on the basis of existing cpe... We go into this with the internet we have not the one that we would like to have the later takes time. >> The goal of 6to4 to historic was not to encourage the outcome described, = >> it was to take having 6to4 as a default method of any kind off the table = >> going into the future. If mature adults want to use it great, but = >> conformance tests shouldn't require it, CPE shouldn't it on just because = >> what they think they have a is a public IP with not filtering and hosts = >> shouldn't use it unless told to do so.. > > But that is *not* what the draft did. Making the protocol historic > did LOTS more than that. I think there was universal consensus > that 6to4 should be off by default. And that'll take some time while particularly for the CPE to age out. > There was this nuke 6to4 from orbit attitude which did nothing to > help with already deployed/shipped boxes. 6to4 historic is actually > harmful for dealing with the existing problems as it tells vendors > not to include 6to4 support in future products which means operators > won't have boxes with fixes to other problems to alleviate the > problems cause but the currently deployed customer boxes. The interpretation of attitude is a matter of taste. When that authors of 3056 and 3068 come down in support of or opposed to the same draft there clearly some debate. If we focus on what really would be in the best interests of the end user, it is a decline to zero in the unintentional use of 6to4 in cpe and operating systems. it is the removal of 6to4 from requirements where it presently exists, and it is the continued support of relays to support legacy devices. It is really hard to justify the expansion and deployment of new relays when in fact tunneled traffic can be observed to be on the decline (possibly because devices particularly hosts that do receive regular updates receive tweaks to their address selection algorithm). http://asert.arbornetworks.com/2011/04/six-months-six-providers-and-ipv6/ > What would have been much better would have been to encourage CPE > vendors to release images which address some of the known issues. > Just adding a check box saying "enable 6to4" and for ISP to send > out email to say "check your router vendor web site for fixed > images". The better fix would be to get them to also add support > for draft-andrews-v6ops-6to4-router-option-02.txt which greys out > the checkbox when 0.0.0.0 is sent as a response to the option. > > Remember operators are in the position to alleviate lots of the > 6to4 issues themselves. > >>> Blocking AAAA over IPv4 transport is just silly. It's just as likely = >> that your >>> AAAA record is destined for an end-host that has native IPv6 = >> connectivity >>> with an intermediate resolver that desn't have IPv6 as it is that = >> you're >>> sending that to a 6to4 host. Further, there's no reason to believe the >>> 6to4 host won't attempt to resolve via IPv6, so, it doesn't really = >> help >>> anyway. >>> =20 >>>> Real network operators have a relatively low BS threshold, they have >>>> customers to support and businesses to run, and they don't have = >> thumb >>>> wrestle these people who don't actually have any skin in the game. >>>> =20 >>> I agree, but, it's not hard to run 6to4 relays and running them does = >> much >>> more to alleviate the problems with 6to4 than anything you proposed >>> above. Indeed, what you proposed above will likely create more = >> customer >>> issues rather than reduce them. >>> =20 >>> Owen >>> =20 >>>> Cameron >>>> =20 >>>> =20 >>>>> Ron >>>>> =20 >>>>> =20 >>>>> -----Original Message----- >>>>> From: Leo Bicknell [mailto:bicknell at ufp.org] >>>>> Sent: Monday, July 11, 2011 3:35 PM >>>>> To: nanog at nanog.org >>>>> Subject: Re: Anybody can participate in the IETF (Was: Why is IPv6 = >> broken?) >>>>> =20 >>>>> In a message written on Sun, Jul 10, 2011 at 06:16:09PM +0200, = >> Jeroen Massar wrote: >>>>>> Ehmmmm ANYBODY, including you, can sign up to the IETF mailing = >> lists >>>>>> and participate there, just like a couple of folks from NANOG are = >> already doing. >>>>> =20 >>>>> The way the IETF and the operator community interact is badly = >> broken. >>>>> =20 >>>>> The IETF does not want operators in many steps of the process. If = >> you try to bring up operational concerns in early protocol development = >> for example you'll often get a "we'll look at that later" response, = >> which in many cases is right. Sometimes you just have to play with = >> something before you worry about the operational details. It also does = >> not help that many operational types are not hardcore programmers, and = >> can't play in the sandbox during the major development cycles. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>> =20 >>> =20 >>> =20 >> >> > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From marka at isc.org Wed Jul 13 00:59:52 2011 From: marka at isc.org (Mark Andrews) Date: Wed, 13 Jul 2011 15:59:52 +1000 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: Your message of "Tue, 12 Jul 2011 22:16:20 MST." <9C391C3A-3535-4C47-A743-57287685942E@bogus.com> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <56E0FB8F-BB53-4DB0-829B-39DFBAB483E8@bogus.com> <20110713014139.92A4611CB398@drugs.dv.isc.org> <9C391C3A-3535-4C47-A743-57287685942E@bogus.com> Message-ID: <20110713055952.EC84111CD0AA@drugs.dv.isc.org> In message <9C391C3A-3535-4C47-A743-57287685942E at bogus.com>, Joel Jaeggli write s: > > On Jul 12, 2011, at 6:41 PM, Mark Andrews wrote: > > >=20 > > In message <56E0FB8F-BB53-4DB0-829B-39DFBAB483E8 at bogus.com>, Joel = > Jaeggli write > > s: > >>=20 > >> On Jul 12, 2011, at 12:53 PM, Owen DeLong wrote: > >>=20 > >>> =3D20 > >>> On Jul 12, 2011, at 8:43 AM, Cameron Byrne wrote: > >>> =3D20 > >>>> On Tue, Jul 12, 2011 at 8:28 AM, Ronald Bonica = > =3D > >> wrote: > >>>>> Leo, > >>>>> =3D20 > >>>>> Maybe we can fix this by: > >>>>> =3D20 > >>>>> a) bringing together larger groups of clueful operators in the = > IETF > >>>>> b) deciding which issues interest them > >>>>> c) showing up and being vocal as a group in protocol developing =3D > >> working groups > >>>>> =3D20 > >>>>> To some degree, we already do this in the IETF OPS area, but = > judging =3D > >> by your comments, we don't do it nearly enough. > >>>>> =3D20 > >>>>> Comments? > >>>>> =3D20 > >>>> =3D20 > >>>> There may be an OPS area, but it is not listened to. > >>>> =3D20 > >>>> Witness the latest debacle with the attempt at trying to make 6to4 = > =3D > >> historic. > >>>> =3D20 > >>>> Various "non-practicing entities" were able to derail what network > >>>> operators largely supported. Since the IETF failed to make = > progress > >>>> operators will do other things to stop 6to4 ( i have heard no AAAA > >>>> over IPv4 transport, blackhole 6to4 anycast, decom relay = > routers...) > >>>> =3D20 > >>> Those are all REALLY bad ideas. Speaking as an operator, the best =3D > >> thing you > >>> can do to alleviate the problems with 6to4 is operate more, not less = > =3D > >> 6to4 > >>> relays. > >>=20 > >> Unless of course the large providers get their shared transition = > space =3D > >> in which case all 6to4 behind it will break in a really ugly way, = > pretty =3D > >> much exactly like in the mobile operator in question.=3D20 > >=20 > > And would deploying draft-andrews-v6ops-6to4-router-option-02.txt = > and/or > > adding router reachability tests have addressed this issue? > > Neither of these approaches address existing cpe, and shared transtion = > space is justified on the basis of existing cpe... I didn't claim it would work with existing CPE equipment. Declaring 6to4 historic won't work with existing CPE equipment either. As for requesting shared transition space, there are lots of benefits to it other than helping existing CPE equipement. draft-andrews-v6ops-6to4-router-option-02.txt helps when you are just filtering the protocol 41 traffic. > We go into this with the internet we have not the one that we would like = > to have the later takes time. > >> The goal of 6to4 to historic was not to encourage the outcome = > described, =3D > >> it was to take having 6to4 as a default method of any kind off the = > table =3D > >> going into the future. If mature adults want to use it great, but =3D > >> conformance tests shouldn't require it, CPE shouldn't it on just = > because =3D > >> what they think they have a is a public IP with not filtering and = > hosts =3D > >> shouldn't use it unless told to do so.. > >=20 > > But that is *not* what the draft did. Making the protocol historic > > did LOTS more than that. I think there was universal consensus > > that 6to4 should be off by default. > > And that'll take some time while particularly for the CPE to age out. > > > There was this nuke 6to4 from orbit attitude which did nothing to > > help with already deployed/shipped boxes. 6to4 historic is actually > > harmful for dealing with the existing problems as it tells vendors > > not to include 6to4 support in future products which means operators > > won't have boxes with fixes to other problems to alleviate the > > problems cause but the currently deployed customer boxes. > > The interpretation of attitude is a matter of taste. When that authors = > of 3056 and 3068 come down in support of or opposed to the same draft = > there clearly some debate.=20 > > If we focus on what really would be in the best interests of the end = > user, it is a decline to zero in the unintentional use of 6to4 in cpe = > and operating systems. it is the removal of 6to4 from requirements where = > it presently exists, and it is the continued support of relays to = > support legacy devices.=20 And to support those that can't get IPv6 from their ISPs. > It is really hard to justify the expansion and deployment of new relays = > when in fact tunneled traffic can be observed to be on the decline = > (possibly because devices particularly hosts that do receive regular = > updates receive tweaks to their address selection algorithm). > = > http://asert.arbornetworks.com/2011/04/six-months-six-providers-and-ipv6/ Which may or may not be a short term dip. We are yet to see much in the way of IPv6 only content. When that appears, which it will, the tunneled traffic will go up unless ISPs have deployed native IPv6 to all customers. Are you willing to bet on which will happen first? This whole area is in a state of flux. > > What would have been much better would have been to encourage CPE > > vendors to release images which address some of the known issues. > > Just adding a check box saying "enable 6to4" and for ISP to send > > out email to say "check your router vendor web site for fixed > > images". The better fix would be to get them to also add support > > for draft-andrews-v6ops-6to4-router-option-02.txt which greys out > > the checkbox when 0.0.0.0 is sent as a response to the option. > >=20 > > Remember operators are in the position to alleviate lots of the > > 6to4 issues themselves. > >=20 > >>> Blocking AAAA over IPv4 transport is just silly. It's just as likely = > =3D > >> that your > >>> AAAA record is destined for an end-host that has native IPv6 =3D > >> connectivity > >>> with an intermediate resolver that desn't have IPv6 as it is that =3D > >> you're > >>> sending that to a 6to4 host. Further, there's no reason to believe = > the > >>> 6to4 host won't attempt to resolve via IPv6, so, it doesn't really =3D= > > >> help > >>> anyway. > >>> =3D20 > >>>> Real network operators have a relatively low BS threshold, they = > have > >>>> customers to support and businesses to run, and they don't have =3D > >> thumb > >>>> wrestle these people who don't actually have any skin in the game. > >>>> =3D20 > >>> I agree, but, it's not hard to run 6to4 relays and running them does = > =3D > >> much > >>> more to alleviate the problems with 6to4 than anything you proposed > >>> above. Indeed, what you proposed above will likely create more =3D > >> customer > >>> issues rather than reduce them. > >>> =3D20 > >>> Owen > >>> =3D20 > >>>> Cameron > >>>> =3D20 > >>>> =3D20 > >>>>> Ron > >>>>> =3D20 > >>>>> =3D20 > >>>>> -----Original Message----- > >>>>> From: Leo Bicknell [mailto:bicknell at ufp.org] > >>>>> Sent: Monday, July 11, 2011 3:35 PM > >>>>> To: nanog at nanog.org > >>>>> Subject: Re: Anybody can participate in the IETF (Was: Why is IPv6 = > =3D > >> broken?) > >>>>> =3D20 > >>>>> In a message written on Sun, Jul 10, 2011 at 06:16:09PM +0200, =3D > >> Jeroen Massar wrote: > >>>>>> Ehmmmm ANYBODY, including you, can sign up to the IETF mailing =3D > >> lists > >>>>>> and participate there, just like a couple of folks from NANOG are = > =3D > >> already doing. > >>>>> =3D20 > >>>>> The way the IETF and the operator community interact is badly =3D > >> broken. > >>>>> =3D20 > >>>>> The IETF does not want operators in many steps of the process. If = > =3D > >> you try to bring up operational concerns in early protocol = > development =3D > >> for example you'll often get a "we'll look at that later" response, =3D= > > >> which in many cases is right. Sometimes you just have to play with =3D= > > >> something before you worry about the operational details. It also = > does =3D > >> not help that many operational types are not hardcore programmers, = > and =3D > >> can't play in the sandbox during the major development cycles. > >>>>> =3D20 > >>>>> =3D20 > >>>>> =3D20 > >>>>> =3D20 > >>> =3D20 > >>> =3D20 > >>> =3D20 > >>=20 > >>=20 > > --=20 > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > >=20 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From joelja at bogus.com Wed Jul 13 01:22:20 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 12 Jul 2011 23:22:20 -0700 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: <20110713055952.EC84111CD0AA@drugs.dv.isc.org> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <56E0FB8F-BB53-4DB0-829B-39DFBAB483E8@bogus.com> <20110713014139.92A4611CB398@drugs.dv.isc.org> <9C391C3A-3535-4C47-A743-57287685942E@bogus.com> <20110713055952.EC84111CD0AA@drugs.dv.isc.org> Message-ID: <430FFF20-43ED-45BB-846D-FEE8769FC399@bogus.com> On Jul 12, 2011, at 10:59 PM, Mark Andrews wrote: > > I didn't claim it would work with existing CPE equipment. Declaring > 6to4 historic won't work with existing CPE equipment either. If the hosts behind it stop using 2002::/16 addresses as a product of a software update which seems rather more likely (also there some evidence for that), it will. that said yes one assumption is that you have to continue to support it. >> It is really hard to justify the expansion and deployment of new relays = >> when in fact tunneled traffic can be observed to be on the decline = >> (possibly because devices particularly hosts that do receive regular = >> updates receive tweaks to their address selection algorithm). >> = >> http://asert.arbornetworks.com/2011/04/six-months-six-providers-and-ipv6/ > > Which may or may not be a short term dip. correlation is not causation but... http://arstechnica.com/apple/news/2010/11/apple-fixes-broken-ipv6-by-breaking-it-some-more.ars > We are yet to see much in the > way of IPv6 only content. When that appears, which it will, the tunneled > traffic will go up unless ISPs have deployed native IPv6 to all customers. > Are you willing to bet on which will happen first? I'm willing to bet that subpar experience due to auto-tunneling is considered a liability for content providers. > This whole area is in a state of flux. > >>> What would have been much better would have been to encourage CPE >>> vendors to release images which address some of the known issues. >>> Just adding a check box saying "enable 6to4" and for ISP to send >>> out email to say "check your router vendor web site for fixed >>> images". The better fix would be to get them to also add support >>> for draft-andrews-v6ops-6to4-router-option-02.txt which greys out >>> the checkbox when 0.0.0.0 is sent as a response to the option. >>> =20 >>> Remember operators are in the position to alleviate lots of the >>> 6to4 issues themselves. >>> =20 >>>>> Blocking AAAA over IPv4 transport is just silly. It's just as likely = >> =3D >>>> that your >>>>> AAAA record is destined for an end-host that has native IPv6 =3D >>>> connectivity >>>>> with an intermediate resolver that desn't have IPv6 as it is that =3D >>>> you're >>>>> sending that to a 6to4 host. Further, there's no reason to believe = >> the >>>>> 6to4 host won't attempt to resolve via IPv6, so, it doesn't really =3D= >> >>>> help >>>>> anyway. >>>>> =3D20 >>>>>> Real network operators have a relatively low BS threshold, they = >> have >>>>>> customers to support and businesses to run, and they don't have =3D >>>> thumb >>>>>> wrestle these people who don't actually have any skin in the game. >>>>>> =3D20 >>>>> I agree, but, it's not hard to run 6to4 relays and running them does = >> =3D >>>> much >>>>> more to alleviate the problems with 6to4 than anything you proposed >>>>> above. Indeed, what you proposed above will likely create more =3D >>>> customer >>>>> issues rather than reduce them. >>>>> =3D20 >>>>> Owen >>>>> =3D20 >>>>>> Cameron >>>>>> =3D20 >>>>>> =3D20 >>>>>>> Ron >>>>>>> =3D20 >>>>>>> =3D20 >>>>>>> -----Original Message----- >>>>>>> From: Leo Bicknell [mailto:bicknell at ufp.org] >>>>>>> Sent: Monday, July 11, 2011 3:35 PM >>>>>>> To: nanog at nanog.org >>>>>>> Subject: Re: Anybody can participate in the IETF (Was: Why is IPv6 = >> =3D >>>> broken?) >>>>>>> =3D20 >>>>>>> In a message written on Sun, Jul 10, 2011 at 06:16:09PM +0200, =3D >>>> Jeroen Massar wrote: >>>>>>>> Ehmmmm ANYBODY, including you, can sign up to the IETF mailing =3D >>>> lists >>>>>>>> and participate there, just like a couple of folks from NANOG are = >> =3D >>>> already doing. >>>>>>> =3D20 >>>>>>> The way the IETF and the operator community interact is badly =3D >>>> broken. >>>>>>> =3D20 >>>>>>> The IETF does not want operators in many steps of the process. If = >> =3D >>>> you try to bring up operational concerns in early protocol = >> development =3D >>>> for example you'll often get a "we'll look at that later" response, =3D= >> >>>> which in many cases is right. Sometimes you just have to play with =3D= >> >>>> something before you worry about the operational details. It also = >> does =3D >>>> not help that many operational types are not hardcore programmers, = >> and =3D >>>> can't play in the sandbox during the major development cycles. >>>>>>> =3D20 >>>>>>> =3D20 >>>>>>> =3D20 >>>>>>> =3D20 >>>>> =3D20 >>>>> =3D20 >>>>> =3D20 >>>> =20 >>>> =20 >>> --=20 >>> Mark Andrews, ISC >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org >>> =20 >> > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From randy at psg.com Wed Jul 13 01:27:26 2011 From: randy at psg.com (Randy Bush) Date: Wed, 13 Jul 2011 15:27:26 +0900 Subject: in defense of lisp (was: Anybody can participate in the IETF) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> Message-ID: >> i will not dispute this, not my point. but i have to respect dino and >> the lisp fanboys (and, yes, they are all boys) for actually *doing* >> something after 30 years of loc/id blah blah blah (as did hip). putting >> their, well dino's, code where their mouths were and going way out on a >> limb. [ i have been correctly reminded that dino is far from the only lisp hacker these days, e.g. http://www.openlisp.org/ being notable. ] > Understood. But watch for similarities between 6to4 and LISP. Both are > clever, both have great intentions, both are extremely dangerous once > people start thinking this is anything beyond a toy. again, i will not dispute this. it is not my point. > And when lowly plebeians like myself hear that research folks at iij > and Facebook are doing "something" with LISP, we think that is a > blessing of this technology. when you hear that research folk are doing something, the best guess would be that it's research. :) > But, after the "fan boy" chatter dies down, you hear that this is not > actually support, it's just engineers doing "Dino" a favor. not exactly. someone i respect is doing some r&d. we do r&d. we all help each other. vendors are kind enough to loan kit to researchers. this does not mean they endorse all of our r&ds projects, just that they endorse and help r&d. our job is to make the internet a better place. on the ops side, when things break, isps all help each other, loan line cards, do remote hands, etc., whether our marketing departments compete or not. our job is to keep the internet running well. > I fear that at its worst and most successful, LISP ensures ipv4 is the > backbone transport media to the detriment of ipv6 and at its best, it > is a distraction for folks that need to be making ipv6 work, for real. i suspect that a number of lisp proponents are of that mind. i do not think it does a service to the internet. > PS. I think the research guys should give more time to ILNP looks interesting but i am unaware of a public code base or research testbed. whack me with a clue bat. randy From jsw at inconcepts.biz Wed Jul 13 02:25:45 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 13 Jul 2011 03:25:45 -0400 Subject: in defense of lisp (was: Anybody can participate in the IETF) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> Message-ID: On Wed, Jul 13, 2011 at 2:27 AM, Randy Bush wrote: >> I fear that at its worst and most successful, LISP ensures ipv4 is the >> backbone transport media to the detriment of ipv6 and at its best, it >> is a distraction for folks that need to be making ipv6 work, for real. > > i suspect that a number of lisp proponents are of that mind. ?i do not > think it does a service to the internet. My understanding is that transport over v6 is indeed on everyone's mind and absolutely is a goal for all the LISP people. So on this particular point, your concern is being addressed. What LISP has not done is actually improve the root problem of scaling up the number of multi-homed networks or locators. The cache scheme works if you imagine an ideal Internet where there is no DoS, but otherwise, it does not work. All the same problems of flow-cache routing still exist and LISP actually makes them worse in some cases, not better. It also adds huge complexity and risk but what value it adds (outside of VPN-over-Internet) is questionable at best. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From luigi at net.t-labs.tu-berlin.de Wed Jul 13 03:08:28 2011 From: luigi at net.t-labs.tu-berlin.de (Luigi Iannone) Date: Wed, 13 Jul 2011 10:08:28 +0200 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> Message-ID: Jeff, On Jul 12, 2011, at 20:13 , Jeff Wheeler wrote: > On Tue, Jul 12, 2011 at 11:42 AM, Leo Bicknell wrote: >> I'll pick on LISP as an example, since many operators are at least >> aware of it. Some operators have said we need a locator and identifier >> split. Interesting feedback. The IETF has gone off and started >> playing in the sandbox, trying to figure out how to make that go. > > As an operator (who understands how most things work in very great > detail), Granted. You are the real world expert. Now can you stop repeating this in each email and move on? > I found the LISP folks very much uninterested in my concerns > about if LISP can ever be made to scale up to "Internet-scale," with > respect to a specific DDoS vector. This is completely false. Several people gave credit to you about the existence of the threat you pointed out. > I also think that an explosion of > small, multi-homed SOHO networks would be a disaster, because we might > have 3 million FIB instead of 360k FIB after a few years. These > things are directly related to each-other, too. > > So I emailed some LISP gurus off-list and discussed my concern. I was > encouraged to post to the LISP IETF list, which I did. To my great > surprise, not one single person was interested in my problem. This is again false. We had mail exchange both privately and on the mailinglist. We proposed to you text to be added to the threats draft but you did not like it. We are asking to propose text but we have no answer from you on this point. > If you > think it is a small problem, well, you should try going back to > late-1990s flow-cache routing in your data-center networks and see > what happens when you get DDoS. I am sure most of us remember some of > those painful experiences. > > Now there is a LISP "threats" draft which the working group mandates > they produce, discussing various security problems. The current paper > is a laundry list of "what if" scenarios, like, what if a malicious > person could fill the LISP control-plane with garbage. BGP has the > same issue, if some bad guy had enable on a big enough network that > their peers/transits don't filter their routes, they could do a lot of > damage before they were stopped. So you are saying that BGP can be victim of similar attacks/problem.... still... if you are reading this email it means that the Internet is still running... > This sometimes happens even by > accident, for example, some poor guy accidentally announcing 12/9 and > giving AT&T a really bad day. > > What it doesn't contain is anything relevant to the special-case DDoS > that all LISP sites would be vulnerable to, due to the IMO bad > flow-cache management system that is specified. If you still think that LISP is using a flow-cache you should have a second read to the set of drafts. > I am having a very > great deal of trouble getting the authors of the "threats" document to > even understand what the problem is, For the third time: this is false. We got the problem, we were asking for more specific information in order to quantify the risk. We asked you help to state the problem and explained to you where the solution should be addressed. But you seem to be stuck on the operator vs. researcher discussion, which IMHO is just pointless. > because as one of them put it, he > is "just a researcher." I am sure he and his colleagues are very > smart guys, but they clearly do not remember our 1990s pains. > > That is the "not an operator" problem. It is understandable. > > Others who have been around long enough simply dismiss this problem, > because they believe the unparalleled benefits of LISP for mobility > and multi-homing SOHO sites must greatly out-weigh the fact that, > well, if you are a content provider and you receive a DDoS, your site > will be down and there isn't a damn thing you can do about it, other > than spec routers that have way, way more FIB than the number of > possible routes, again due to the bad caching scheme. > > The above is what I think is the "ego-invested" problem, where certain > pretty smart, well-intentioned people have a lot of time, and > professional credibility, invested in making LISP work. I'm sure it > isn't pleasing for these guys to defend their project against my > argument that it may never be able to reach Internet-scale, and that > they have missed what I claim is a show-stopping problem with an easy > way to improve it through several years of development. Especially > since I am a guy who did not ever participate in the IETF before, > someone they don't know from a random guy on the street. > > I am glad that this NANOG discussion has got some of these LISP folks > to pay more attention to my argument, and my suggested improvement (I > am not only bashing their project; I have positive input, too.) > Simply posting to their mailing list once and emailing a few draft > authors did not cause any movement at all. Evidently it does get > attention, though, to jump up and down on a different list. Go > figure! > > If operators don't provide input and *perspective* to things like > LISP, we will end up with bad results. > True. That technical feedback is the most welcome. Let me now ask a simple question: why are you so strongly against LISP? You do not like it? Fine, other people do. You do not believe in it and do not see any value? Fine, other people do. You think that there are issues that cannot be solved? Fine, other people believe those issues can be solved and are scratching their head to find deployable solutions. As I said before, your technical experience and feedback is the most welcome, but let's try to focus only on the technical level. thanks Luigi Iannone From damien.saucez at uclouvain.be Wed Jul 13 03:45:19 2011 From: damien.saucez at uclouvain.be (Damien Saucez) Date: Wed, 13 Jul 2011 10:45:19 +0200 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> Message-ID: <78647F65-C19E-4CA9-AD48-03B996638D3A@uclouvain.be> Hello Jeff, On 13 Jul 2011, at 10:08, Luigi Iannone wrote: > Jeff, > > > On Jul 12, 2011, at 20:13 , Jeff Wheeler wrote: > >> On Tue, Jul 12, 2011 at 11:42 AM, Leo Bicknell wrote: >>> I'll pick on LISP as an example, since many operators are at least >>> aware of it. Some operators have said we need a locator and identifier >>> split. Interesting feedback. The IETF has gone off and started >>> playing in the sandbox, trying to figure out how to make that go. >> >> As an operator (who understands how most things work in very great >> detail), > Granted. You are the real world expert. Now can you stop repeating this in each email and move on? > >> I found the LISP folks very much uninterested in my concerns >> about if LISP can ever be made to scale up to "Internet-scale," with >> respect to a specific DDoS vector. > > This is completely false. Several people gave credit to you about the existence of the threat you pointed out. > Definitely, since 2007 we are working on LISP and always keep scalability in mind. All our researches are always constrained by the scalability. What you pointed out is very interesting and we are working on it. Nevertheless, and I am just repeating myself now, the problem you expose is an operational problem that can also have security implications. This is why we proposed you several time to expose the problem at next IETF such that we can all discuss the problem and propose solutions to be added in the main specs. The cache management problem is really interesting and we could even imagine a draft like "implementation guidelines" that would explain how to implement the caches in a smart way. The solution to the problem you are pointing-out can also be proposed in the deployment draft as it could be alleviate with the help of filters. > >> I also think that an explosion of >> small, multi-homed SOHO networks would be a disaster, because we might >> have 3 million FIB instead of 360k FIB after a few years. These >> things are directly related to each-other, too. >> >> So I emailed some LISP gurus off-list and discussed my concern. I was >> encouraged to post to the LISP IETF list, which I did. To my great >> surprise, not one single person was interested in my problem. > > This is again false. We had mail exchange both privately and on the mailinglist. We proposed to you text to be added to the threats draft but you did not like it. We are asking to propose text but we have no answer from you on this point. > Among the people that are interesting by the problem, you have the threats authors. You received personal replies from me on Jul 6th @2:08pm and Jul 7th @1:13 am. In our SVN, the draft is already updated with your comments and you are in the acks. The version will be submitted just after the IETF with the comments that will come from the presentation we will make during IETF81. I understand that you would like to have the comment addresses immediately when you are thinking about them but sometime it is nice to take a few days to think about the problem in order to problem a more robust description and thus build more sustainable ways to a solution. > >> If you >> think it is a small problem, well, you should try going back to >> late-1990s flow-cache routing in your data-center networks and see >> what happens when you get DDoS. I am sure most of us remember some of >> those painful experiences. >> >> Now there is a LISP "threats" draft which the working group mandates >> they produce, discussing various security problems. The current paper >> is a laundry list of "what if" scenarios, like, what if a malicious >> person could fill the LISP control-plane with garbage. BGP has the >> same issue, if some bad guy had enable on a big enough network that >> their peers/transits don't filter their routes, they could do a lot of >> damage before they were stopped. > > So you are saying that BGP can be victim of similar attacks/problem.... still... if you are reading this email it means that the Internet is still running... > Some people like Randy Bush try to find solutions for BGP not to be destroyed in presence of malicious guys. For BGP as for LISP, things take time just become the problem is definitely more complex as we always have to make tradeoffs between various contradictory elements. > >> This sometimes happens even by >> accident, for example, some poor guy accidentally announcing 12/9 and >> giving AT&T a really bad day. >> >> What it doesn't contain is anything relevant to the special-case DDoS >> that all LISP sites would be vulnerable to, due to the IMO bad >> flow-cache management system that is specified. > > If you still think that LISP is using a flow-cache you should have a second read to the set of drafts. > > Depends you definition of flow. If a flow is defined by the destination prefix, then yes, LISP has a flow-cache ;-) >> I am having a very >> great deal of trouble getting the authors of the "threats" document to >> even understand what the problem is, > > For the third time: this is false. We got the problem, we were asking for more specific information in order to quantify the risk. We asked you help to state the problem and explained to you where the solution should be addressed. But you seem to be stuck on the operator vs. researcher discussion, which IMHO is just pointless. fully agree, our draft is already updated, and I know exactly the sentence that has been added in Sec 6.2.2 of the draft. We have not submitted the draft yet as we are following the "rules" of the WG. We will present the draft and present the modifications we want to have and ask the WG to accept them. Then we will add them in the draft. > >> because as one of them put it, he >> is "just a researcher." I am sure he and his colleagues are very >> smart guys, but they clearly do not remember our 1990s pains. >> >> That is the "not an operator" problem. It is understandable. >> >> Others who have been around long enough simply dismiss this problem, >> because they believe the unparalleled benefits of LISP for mobility >> and multi-homing SOHO sites must greatly out-weigh the fact that, >> well, if you are a content provider and you receive a DDoS, your site >> will be down and there isn't a damn thing you can do about it, other >> than spec routers that have way, way more FIB than the number of >> possible routes, again due to the bad caching scheme. >> >> The above is what I think is the "ego-invested" problem, where certain >> pretty smart, well-intentioned people have a lot of time, and >> professional credibility, invested in making LISP work. I'm sure it >> isn't pleasing for these guys to defend their project against my >> argument that it may never be able to reach Internet-scale, and that >> they have missed what I claim is a show-stopping problem with an easy >> way to improve it through several years of development. Especially >> since I am a guy who did not ever participate in the IETF before, >> someone they don't know from a random guy on the street. >> >> I am glad that this NANOG discussion has got some of these LISP folks >> to pay more attention to my argument, and my suggested improvement (I >> am not only bashing their project; I have positive input, too.) >> Simply posting to their mailing list once and emailing a few draft >> authors did not cause any movement at all. Evidently it does get >> attention, though, to jump up and down on a different list. Go >> figure! >> >> If operators don't provide input and *perspective* to things like >> LISP, we will end up with bad results. >> > > True. That technical feedback is the most welcome. Sure, please provide your feedback. What about deploying LISP in your test network and provide us all the information you got from this deployment? For you information, we are currently working with operators that are testing LISP stuff so be sure that operators are listened! > > Let me now ask a simple question: why are you so strongly against LISP? > > You do not like it? Fine, other people do. > You do not believe in it and do not see any value? Fine, other people do. > You think that there are issues that cannot be solved? Fine, other people believe those issues can be solved and are scratching their head to find deployable solutions. > > As I said before, your technical experience and feedback is the most welcome, but let's try to focus only on the technical level. > Maybe you could write a draft with all the points you don't like in LISP and why. This document could be a starting point to improve LISP from an operational viewpoint. Tank you for providing us all the technical details. Damien Saucez > thanks > > Luigi Iannone > > > > From jsw at inconcepts.biz Wed Jul 13 04:21:43 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 13 Jul 2011 05:21:43 -0400 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> Message-ID: Luigi, you have mis-understood quite a bit of the content of my message. I'm not sure if this is of any further interest to NANOG readers, but as it is basically what seems to go on a lot, from my observations of IETF list activity, I'll copy my reply to the list as you have done. On Wed, Jul 13, 2011 at 4:08 AM, Luigi Iannone wrote: > Granted. You are the real world expert. Now can you stop repeating this in > each email and move on? No. This is a point that needs to be not only made, but driven home. You do not understand how routers work, which is why you are having such difficulty understanding the severity of this problem. The lisp-threats work you have done is basically all control-plane / signalling issues, and no data-plane issues. This is not a coincidence; it is because your knowledge of the control-plane side is good and of the data-plane is weak. > This is completely false. Several people gave credit to you about the > existence of the threat you pointed out. Really? In April, when I posted a serious problem, and received no replies? Now, the original folks who I discussed this with, before ever posting to the IETF LISP list, are finally seeking clarification, because apparently there may have been some confusion in April, possibly leading to their total dismissal of this as a practical concern. > This is again false. We had mail exchange both privately and on the > mailinglist. We proposed to you text to be added to the threats draft but > you did not like it. We are asking to propose text but we have no answer > from you on this point. Actually, you classified this as an implementation concern, which is false. You have said yourself that this is why you believe it deserves just one sentence, if that, in the lisp-threats draft. This is not an implementation-specific concern, it is a design flaw in the MS negative response scheme, which emerges to produce a trivial DoS threat if LISP ever scales up. >> Now there is a LISP "threats" draft which the working group mandates >> they produce, discussing various security problems. ?The current paper >> is a laundry list of "what if" scenarios, like, what if a malicious >> person could fill the LISP control-plane with garbage. ?BGP has the > > So you are saying that BGP can be victim of similar attacks/problem.... > still... if you are reading this email it means that the Internet is still > running... This is where I believe you are mis-reading my message. Your threats draft covers legitimate concerns which also exist in the current system that is widely deployed, which is largely, BGP plus big FIB. What you don't cover, at all, is an IMO critical new threat that emerges in the data-plane from the design of the MS protocol. > If you still think that LISP is using a flow-cache you should have a second > read to the set of drafts. This language may appear unclear if you haven't read it in the context of my other postings. LISP routing most certainly is a flow-cache, however, the definition of "flow" is different. Some platforms and routing schemes see a flow as a layer-3 destination /32 or similar (some 90s routers), others more granular (firewalls, where flows are usually layer-4 and often stateful), and with LISP, the "flow" the address space routed from your ITR to a remote ETR, which may cover a large amount of address space and many smaller flows. The LISP drafts also refer to these flows as "tunnels," but that language could easily be confused to mean much more permanent, static tunnels, or MPLS-like tunnels which are signaled throughout the network of P routers. So there are clear semantic issues of importance when talking about LISP, and all these terms must be read in the correct context. > For the third time: this is false. We got the problem, we were asking for > more specific information in order to quantify the risk. We asked you help You haven't "got it," or you would already understand the risk very well. It is not my intention to fault you and your colleagues for failing to understand this; but to demonstrate clearly that the right kind of expertise is absolutely not being applied to LISP, and there is a huge and possibly intractable threat that was completely overlooked when producing what is meant to be an authoritative document on currently-known "threats" to LISP. > to state the problem and explained to you where the solution should be > addressed. But you seem to be stuck on the operator vs. researcher > discussion, which IMHO is just pointless. Substantially all operators are "stuck" there. They should participate more. > Let me now ask a simple question: why are you so strongly against LISP? No new work has been done to address the problem of scaling up the number of locators or multi-homed end-sites. However, the *claims* being made by LISP advocates is that the caching scheme you have, which is not novel, does solve this problem. It does not. It cannot as there has been no novel work on this. It is very unfortunate that LISP folks point to an academic paper that studied the affect of 20k nominal flows. This is not Internet-scale, but a lot of you who are working hard on LISP don't seem to understand that. DoS attacks are a real world concern that we all have to live with when deploying things for Internet use (as opposed to enterprise VPN, etc.) If you don't even consider their impact, how would you expect content to be available over a LISP infrastructure? How could a large subscriber-access ITR platform work, if a trivial DoS against it would impact all connected subscribers? The root problem remains that as you scale up the number of locators and destination prefixes, you need to scale up the hardware. This is made 10x worse, as I have demonstrated, by the inflexible and foolish negative mapping reply scheme that is specified for LISP. > You do not believe in it and do not see any value? Fine, other people do. As I have said, I believe the value of LISP is limited to VPN-over-Internet. It can never scale up for large-scale, Internet use. This is an opinion shared by virtually all operators I've spoken to who have followed LISP. Why? Again, pet project, ego, and academia vs operational reality. Get some other opinions. I'm not the only guy who thinks this way, I'm just the only one bothering to jump up and down, because I think LISP is a really good example of what is being discussed in this NANOG thread (IETF brokenness due to lack of operator participation), and a waste of vendor resources. > You think that there are issues that cannot be solved? Fine, other people > believe those issues can be solved and are scratching their head to find > deployable solutions. I've seen the "LISP Youtube Video." It looks clever, but it'll never, ever work at large scale. Would you like to know what actually does work, has existing code, and just needs some killer app? SCTP. It does the mobility that LISP promises, and removes the need to even have loc/ID separation, because applications perceive a socket which the OS (SCTP stack) at each end can multi-home, and port across changing IP addresses, and so on. SCTP isn't going to sell any routers, but it solves all those problems that LISP would like to solve (but can't at scale.) -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From luigi at net.t-labs.tu-berlin.de Wed Jul 13 06:03:14 2011 From: luigi at net.t-labs.tu-berlin.de (Luigi Iannone) Date: Wed, 13 Jul 2011 13:03:14 +0200 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> Message-ID: Jeff, on one point we agree, there is value in continuing this thread. I've tried to bring the discussion back to the technical issues, but I failed. Personally, I find your emails aggressive and close to offensive in some sentences. Differently from you, in my replies (all of them public) I never judged your competences. For me this thread is closed. Have a nice day Luigi On Jul 13, 2011, at 11:21 , Jeff Wheeler wrote: > Luigi, you have mis-understood quite a bit of the content of my > message. I'm not sure if this is of any further interest to NANOG > readers, but as it is basically what seems to go on a lot, from my > observations of IETF list activity, I'll copy my reply to the list as > you have done. > > On Wed, Jul 13, 2011 at 4:08 AM, Luigi Iannone > wrote: >> Granted. You are the real world expert. Now can you stop repeating this in >> each email and move on? > > No. This is a point that needs to be not only made, but driven home. > You do not understand how routers work, which is why you are having > such difficulty understanding the severity of this problem. The > lisp-threats work you have done is basically all control-plane / > signalling issues, and no data-plane issues. This is not a > coincidence; it is because your knowledge of the control-plane side is > good and of the data-plane is weak. > >> This is completely false. Several people gave credit to you about the >> existence of the threat you pointed out. > > Really? In April, when I posted a serious problem, and received no > replies? Now, the original folks who I discussed this with, before > ever posting to the IETF LISP list, are finally seeking clarification, > because apparently there may have been some confusion in April, > possibly leading to their total dismissal of this as a practical > concern. > >> This is again false. We had mail exchange both privately and on the >> mailinglist. We proposed to you text to be added to the threats draft but >> you did not like it. We are asking to propose text but we have no answer >> from you on this point. > > Actually, you classified this as an implementation concern, which is > false. You have said yourself that this is why you believe it > deserves just one sentence, if that, in the lisp-threats draft. This > is not an implementation-specific concern, it is a design flaw in the > MS negative response scheme, which emerges to produce a trivial DoS > threat if LISP ever scales up. > >>> Now there is a LISP "threats" draft which the working group mandates >>> they produce, discussing various security problems. The current paper >>> is a laundry list of "what if" scenarios, like, what if a malicious >>> person could fill the LISP control-plane with garbage. BGP has the >> >> So you are saying that BGP can be victim of similar attacks/problem.... >> still... if you are reading this email it means that the Internet is still >> running... > > This is where I believe you are mis-reading my message. Your threats > draft covers legitimate concerns which also exist in the current > system that is widely deployed, which is largely, BGP plus big FIB. > What you don't cover, at all, is an IMO critical new threat that > emerges in the data-plane from the design of the MS protocol. > >> If you still think that LISP is using a flow-cache you should have a second >> read to the set of drafts. > > This language may appear unclear if you haven't read it in the context > of my other postings. LISP routing most certainly is a flow-cache, > however, the definition of "flow" is different. Some platforms and > routing schemes see a flow as a layer-3 destination /32 or similar > (some 90s routers), others more granular (firewalls, where flows are > usually layer-4 and often stateful), and with LISP, the "flow" the > address space routed from your ITR to a remote ETR, which may cover a > large amount of address space and many smaller flows. > > The LISP drafts also refer to these flows as "tunnels," but that > language could easily be confused to mean much more permanent, static > tunnels, or MPLS-like tunnels which are signaled throughout the > network of P routers. So there are clear semantic issues of > importance when talking about LISP, and all these terms must be read > in the correct context. > >> For the third time: this is false. We got the problem, we were asking for >> more specific information in order to quantify the risk. We asked you help > > You haven't "got it," or you would already understand the risk very > well. It is not my intention to fault you and your colleagues for > failing to understand this; but to demonstrate clearly that the right > kind of expertise is absolutely not being applied to LISP, and there > is a huge and possibly intractable threat that was completely > overlooked when producing what is meant to be an authoritative > document on currently-known "threats" to LISP. > >> to state the problem and explained to you where the solution should be >> addressed. But you seem to be stuck on the operator vs. researcher >> discussion, which IMHO is just pointless. > > Substantially all operators are "stuck" there. They should participate more. > >> Let me now ask a simple question: why are you so strongly against LISP? > > No new work has been done to address the problem of scaling up the > number of locators or multi-homed end-sites. However, the *claims* > being made by LISP advocates is that the caching scheme you have, > which is not novel, does solve this problem. It does not. It cannot > as there has been no novel work on this. > > It is very unfortunate that LISP folks point to an academic paper that > studied the affect of 20k nominal flows. This is not Internet-scale, > but a lot of you who are working hard on LISP don't seem to understand > that. DoS attacks are a real world concern that we all have to live > with when deploying things for Internet use (as opposed to enterprise > VPN, etc.) If you don't even consider their impact, how would you > expect content to be available over a LISP infrastructure? How could > a large subscriber-access ITR platform work, if a trivial DoS against > it would impact all connected subscribers? > > The root problem remains that as you scale up the number of locators > and destination prefixes, you need to scale up the hardware. This is > made 10x worse, as I have demonstrated, by the inflexible and foolish > negative mapping reply scheme that is specified for LISP. > >> You do not believe in it and do not see any value? Fine, other people do. > > As I have said, I believe the value of LISP is limited to > VPN-over-Internet. It can never scale up for large-scale, Internet > use. This is an opinion shared by virtually all operators I've spoken > to who have followed LISP. Why? Again, pet project, ego, and > academia vs operational reality. > > Get some other opinions. I'm not the only guy who thinks this way, > I'm just the only one bothering to jump up and down, because I think > LISP is a really good example of what is being discussed in this NANOG > thread (IETF brokenness due to lack of operator participation), and a > waste of vendor resources. > >> You think that there are issues that cannot be solved? Fine, other people >> believe those issues can be solved and are scratching their head to find >> deployable solutions. > > I've seen the "LISP Youtube Video." It looks clever, but it'll never, > ever work at large scale. Would you like to know what actually does > work, has existing code, and just needs some killer app? SCTP. It > does the mobility that LISP promises, and removes the need to even > have loc/ID separation, because applications perceive a socket which > the OS (SCTP stack) at each end can multi-home, and port across > changing IP addresses, and so on. > > SCTP isn't going to sell any routers, but it solves all those problems > that LISP would like to solve (but can't at scale.) > > -- > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts From luigi at net.t-labs.tu-berlin.de Wed Jul 13 06:08:35 2011 From: luigi at net.t-labs.tu-berlin.de (Luigi Iannone) Date: Wed, 13 Jul 2011 13:08:35 +0200 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> Message-ID: <372AE777-AC8A-46D5-82FD-95718504A839@net.t-labs.tu-berlin.de> On Jul 13, 2011, at 13:03 , Luigi Iannone wrote: > Jeff, > > on one point we agree, there is value in continuing this thread. There is _no_ value..... my mistake... Luigi > I've tried to bring the discussion back to the technical issues, but I failed. > > Personally, I find your emails aggressive and close to offensive in some sentences. > Differently from you, in my replies (all of them public) I never judged your competences. > > For me this thread is closed. > > Have a nice day > > Luigi > > On Jul 13, 2011, at 11:21 , Jeff Wheeler wrote: > >> Luigi, you have mis-understood quite a bit of the content of my >> message. I'm not sure if this is of any further interest to NANOG >> readers, but as it is basically what seems to go on a lot, from my >> observations of IETF list activity, I'll copy my reply to the list as >> you have done. >> >> On Wed, Jul 13, 2011 at 4:08 AM, Luigi Iannone >> wrote: >>> Granted. You are the real world expert. Now can you stop repeating this in >>> each email and move on? >> >> No. This is a point that needs to be not only made, but driven home. >> You do not understand how routers work, which is why you are having >> such difficulty understanding the severity of this problem. The >> lisp-threats work you have done is basically all control-plane / >> signalling issues, and no data-plane issues. This is not a >> coincidence; it is because your knowledge of the control-plane side is >> good and of the data-plane is weak. >> >>> This is completely false. Several people gave credit to you about the >>> existence of the threat you pointed out. >> >> Really? In April, when I posted a serious problem, and received no >> replies? Now, the original folks who I discussed this with, before >> ever posting to the IETF LISP list, are finally seeking clarification, >> because apparently there may have been some confusion in April, >> possibly leading to their total dismissal of this as a practical >> concern. >> >>> This is again false. We had mail exchange both privately and on the >>> mailinglist. We proposed to you text to be added to the threats draft but >>> you did not like it. We are asking to propose text but we have no answer >>> from you on this point. >> >> Actually, you classified this as an implementation concern, which is >> false. You have said yourself that this is why you believe it >> deserves just one sentence, if that, in the lisp-threats draft. This >> is not an implementation-specific concern, it is a design flaw in the >> MS negative response scheme, which emerges to produce a trivial DoS >> threat if LISP ever scales up. >> >>>> Now there is a LISP "threats" draft which the working group mandates >>>> they produce, discussing various security problems. The current paper >>>> is a laundry list of "what if" scenarios, like, what if a malicious >>>> person could fill the LISP control-plane with garbage. BGP has the >>> >>> So you are saying that BGP can be victim of similar attacks/problem.... >>> still... if you are reading this email it means that the Internet is still >>> running... >> >> This is where I believe you are mis-reading my message. Your threats >> draft covers legitimate concerns which also exist in the current >> system that is widely deployed, which is largely, BGP plus big FIB. >> What you don't cover, at all, is an IMO critical new threat that >> emerges in the data-plane from the design of the MS protocol. >> >>> If you still think that LISP is using a flow-cache you should have a second >>> read to the set of drafts. >> >> This language may appear unclear if you haven't read it in the context >> of my other postings. LISP routing most certainly is a flow-cache, >> however, the definition of "flow" is different. Some platforms and >> routing schemes see a flow as a layer-3 destination /32 or similar >> (some 90s routers), others more granular (firewalls, where flows are >> usually layer-4 and often stateful), and with LISP, the "flow" the >> address space routed from your ITR to a remote ETR, which may cover a >> large amount of address space and many smaller flows. >> >> The LISP drafts also refer to these flows as "tunnels," but that >> language could easily be confused to mean much more permanent, static >> tunnels, or MPLS-like tunnels which are signaled throughout the >> network of P routers. So there are clear semantic issues of >> importance when talking about LISP, and all these terms must be read >> in the correct context. >> >>> For the third time: this is false. We got the problem, we were asking for >>> more specific information in order to quantify the risk. We asked you help >> >> You haven't "got it," or you would already understand the risk very >> well. It is not my intention to fault you and your colleagues for >> failing to understand this; but to demonstrate clearly that the right >> kind of expertise is absolutely not being applied to LISP, and there >> is a huge and possibly intractable threat that was completely >> overlooked when producing what is meant to be an authoritative >> document on currently-known "threats" to LISP. >> >>> to state the problem and explained to you where the solution should be >>> addressed. But you seem to be stuck on the operator vs. researcher >>> discussion, which IMHO is just pointless. >> >> Substantially all operators are "stuck" there. They should participate more. >> >>> Let me now ask a simple question: why are you so strongly against LISP? >> >> No new work has been done to address the problem of scaling up the >> number of locators or multi-homed end-sites. However, the *claims* >> being made by LISP advocates is that the caching scheme you have, >> which is not novel, does solve this problem. It does not. It cannot >> as there has been no novel work on this. >> >> It is very unfortunate that LISP folks point to an academic paper that >> studied the affect of 20k nominal flows. This is not Internet-scale, >> but a lot of you who are working hard on LISP don't seem to understand >> that. DoS attacks are a real world concern that we all have to live >> with when deploying things for Internet use (as opposed to enterprise >> VPN, etc.) If you don't even consider their impact, how would you >> expect content to be available over a LISP infrastructure? How could >> a large subscriber-access ITR platform work, if a trivial DoS against >> it would impact all connected subscribers? >> >> The root problem remains that as you scale up the number of locators >> and destination prefixes, you need to scale up the hardware. This is >> made 10x worse, as I have demonstrated, by the inflexible and foolish >> negative mapping reply scheme that is specified for LISP. >> >>> You do not believe in it and do not see any value? Fine, other people do. >> >> As I have said, I believe the value of LISP is limited to >> VPN-over-Internet. It can never scale up for large-scale, Internet >> use. This is an opinion shared by virtually all operators I've spoken >> to who have followed LISP. Why? Again, pet project, ego, and >> academia vs operational reality. >> >> Get some other opinions. I'm not the only guy who thinks this way, >> I'm just the only one bothering to jump up and down, because I think >> LISP is a really good example of what is being discussed in this NANOG >> thread (IETF brokenness due to lack of operator participation), and a >> waste of vendor resources. >> >>> You think that there are issues that cannot be solved? Fine, other people >>> believe those issues can be solved and are scratching their head to find >>> deployable solutions. >> >> I've seen the "LISP Youtube Video." It looks clever, but it'll never, >> ever work at large scale. Would you like to know what actually does >> work, has existing code, and just needs some killer app? SCTP. It >> does the mobility that LISP promises, and removes the need to even >> have loc/ID separation, because applications perceive a socket which >> the OS (SCTP stack) at each end can multi-home, and port across >> changing IP addresses, and so on. >> >> SCTP isn't going to sell any routers, but it solves all those problems >> that LISP would like to solve (but can't at scale.) >> >> -- >> Jeff S Wheeler >> Sr Network Operator / Innovative Network Concepts > > From harbor235 at gmail.com Wed Jul 13 08:14:04 2011 From: harbor235 at gmail.com (harbor235) Date: Wed, 13 Jul 2011 09:14:04 -0400 Subject: ipv6 address family with vrf Message-ID: Has anyone been able to configure ipv4 and ipv6 AFI with VRF instances simultaneously? Using the 7200 and 12.4(25e), under the ipv6 address family the VRF sub commands are not visible, must be a feature? thanx in advance, Mike From rsk at gsp.org Wed Jul 13 08:37:09 2011 From: rsk at gsp.org (Richard Kulawiec) Date: Wed, 13 Jul 2011 09:37:09 -0400 Subject: NANOG List Update - Moving Forward In-Reply-To: <4E1C5676.9050907@ahnberg.pp.se> References: <4E1C5676.9050907@ahnberg.pp.se> Message-ID: <20110713133709.GA22505@gsp.org> On Tue, Jul 12, 2011 at 04:13:10PM +0200, Mattias Ahnberg wrote: > I might have missed some discussion; but why are we moving > away from mailman, and what software is in the new system? Seconded. Mailman is presently the gold standard for mailing list management [1], and while a lift-and-drop of a Mailman instance from one host to another isn't entirely transparent/trivial, it's a fairly well-understood process, and there is certainly no shortage of assistance available for anyone who runs into problems with the task. If there is a plan to downgrade from Mailman to any of the alternatives, then those advocating it need to present compelling technical arguments that make the case why this course of action is necessary. ---rsk [1] This is not meant to suggest that I think Mailman is perfect; it's clearly not, and its maintainers would be among the first to admit that. But it's very good and consistently being improved. From harbor235 at gmail.com Wed Jul 13 08:42:44 2011 From: harbor235 at gmail.com (harbor235) Date: Wed, 13 Jul 2011 09:42:44 -0400 Subject: ipv6 address family with vrf In-Reply-To: References: Message-ID: hmmm, looks like I am looking for the multiprotocol vrf feature that is only supported in the modular IOS trains for the CRS and ASR platforms, can anyone confirm that? Mike On Wed, Jul 13, 2011 at 9:14 AM, harbor235 wrote: > > Has anyone been able to configure ipv4 and ipv6 AFI with VRF instances > simultaneously? Using > the 7200 and 12.4(25e), under the ipv6 address family the VRF sub commands > are not visible, > must be a feature? > > > thanx in advance, > > Mike > From streiner at cluebyfour.org Wed Jul 13 08:47:30 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 13 Jul 2011 09:47:30 -0400 (EDT) Subject: ipv6 address family with vrf In-Reply-To: References: Message-ID: On Wed, 13 Jul 2011, harbor235 wrote: > Has anyone been able to configure ipv4 and ipv6 AFI with VRF instances > simultaneously? Using > the 7200 and 12.4(25e), under the ipv6 address family the VRF sub commands > are not visible, > must be a feature? I have a 7200 running in my lab with 12.4(24e) and I don't see the v6 VRF stuff in there either. Did you check the software advisor on CCO? I had to upgrade my 6509s to 12.2(33)SXI6 to get that functionality. I was glad to avoid SXJ at least for now. I like to let new code releases for the 6500s cook for awhile before trying them out ;) jms From sergey at lobanov.in Wed Jul 13 08:55:07 2011 From: sergey at lobanov.in (Sergey V. Lobanov) Date: Wed, 13 Jul 2011 17:55:07 +0400 Subject: ipv6 address family with vrf In-Reply-To: References: Message-ID: <47671310565307@web86.yandex.ru> Cisco IOS 12.4(24)T2(C7200-ADVENTERPRISEK9-M), RELEASE SOFTWARE (fc2) supports vpnv6 and ipv6 vrf address families. 13.07.2011, 17:47, "Justin M. Streiner" : > On Wed, 13 Jul 2011, harbor235 wrote: > >> ?Has anyone been able to configure ipv4 and ipv6 AFI with VRF instances >> ?simultaneously? Using >> ?the 7200 and 12.4(25e), under the ipv6 address family the VRF sub commands >> ?are not visible, >> ?must be a feature? > > I have a 7200 running in my lab with 12.4(24e) and I don't see the v6 VRF > stuff in there either. ?Did you check the software advisor on CCO? > > I had to upgrade my 6509s to 12.2(33)SXI6 to get that functionality. ?I > was glad to avoid SXJ at least for now. ?I like to let new code releases > for the 6500s cook for awhile before trying them out ;) > > jms -- wbr, Sergey V. Lobanov From bhmccie at gmail.com Wed Jul 13 09:04:30 2011 From: bhmccie at gmail.com (-Hammer-) Date: Wed, 13 Jul 2011 09:04:30 -0500 Subject: NANOG List Update - Moving Forward In-Reply-To: References: <201107121507.p6CF7i7h033220@mail.r-bonomi.com> <409E5316D8C0514F9E6B49DB5FBBBB98038855DC@exch2008.torrance.interworld.net> <4E1C758A.10604@gmail.com> Message-ID: <4E1DA5EE.4070202@gmail.com> Good response Jimmy. I think that peoples tact more than anything is what is embarrassing about these threads. The complaint is legitimate. -Hammer- "I was a normal American nerd" -Jack Herer On 07/12/2011 09:05 PM, Jimmy Hess wrote: > On Tue, Jul 12, 2011 at 11:25 AM, -Hammer- wrote: > >> The tolerance of some of you out there is amazing. You must be PS3 users >> crying because your free game network is down. Maybe we can get a >> > PS3net users had a right to cry.. because their 'free' game network > is not really free, > and they bought a nice console that became a brick for indefinite > amounts of time.... > > >> Be patient people. Maybe a little appreciation to these experts wouldn't >> hurt you either. >> > Patience is gold, but operating or migrating a listserv is not rocket science, > and it cuts both ways. Only a certain amount of patience is warranted for any > particular situation, and it appears posters have the warranted amount > of tolerance. > > For now I am appreciative of Robert Bonomi and Brielle Bruns for > identifying issues. > > I'll be happy to express appreciation, as soon as the "experts" get it > done and get > it right; right now I'm just keeping my fingers crossed and hoping to > hear the news > that the issues are addressed and everything's perfect. > > In the mean time; I am glad that the deficiencies witnessed are being reported. > And hope the experts are learning, and at least taking the reports seriously, > esp. regards to non-member posting, spam, "undisclosed-recipients" mess, > and header issues/ oddball "bulk_mailer" identification... > > > NANOG as an operators list should not itself become an example of poor > operator practice; or poor planning/change management; > that would be an embarassment. > > >> -Hammer- >> > -- > -JH > From randy at psg.com Wed Jul 13 09:09:24 2011 From: randy at psg.com (Randy Bush) Date: Wed, 13 Jul 2011 23:09:24 +0900 Subject: in defense of lisp (was: Anybody can participate in the IETF) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> Message-ID: btw, a litte birdie told me to take another look at 6296 IPv6-to-IPv6 Network Prefix Translation. M. Wasserman, F. Baker. June 2011. (Format: TXT=73700 bytes) (Status: EXPERIMENTAL) which also could be considered to be in the loc/id space randy From bill at kruchas.com Wed Jul 13 09:15:26 2011 From: bill at kruchas.com (bill at kruchas.com) Date: Wed, 13 Jul 2011 07:15:26 -0700 Subject: Answer to: Hello List Easy Cisco question. Message-ID: <20110713071526.5f1e402cf2b8f2f1e57b153880067f5a.c7da65dde8.wbe@email10.secureserver.net> Hello, and thanks for all the help. What the issue boiled down to, I was creating the access list just like the static command. Which means I was using the source and destination ports when creating it. You just need the destination port, actually because the firewall "catches" the packet on a different port and un encapsulates the packet and passes it through. The different port was causing the accesslist to reject the packet. so this is what I had: >access-list Etherpoint_access_in extended permit tcp any eq 5900 host outside-ip eq 5900 This is what worked :) >access-list Etherpoint_access_in extended permit tcp any host outside-ip eq 5900 A complete example if anyone who needs it to route external request to an internal host: * access list to permit traffic in access-list Etherpoint_access_in extended permit tcp any host outside-ip eq 5900 *static command to setup the relationship form outside interface to inside host static (Inside,Etherpoint) tcp interface 5900 192.168.125.8 5900 netmask 255.255.255.255 * command to bind the accesslist to the outside interface access-group Etherpoint_access_in in interface Etherpoint Thanks again list Bill Kruchas Below is the full question and details. ***************************************************************** Hello List, First let me say I'm not a heads down network guy, but I have setup several cisco firewalls from pix's some 831's, and now I'm trying to get a asa 5505 configured. ver 7.2 and 5.2 on the ASDM. This has been in and working for some time, granting outbound access. There is only one external useable ip address so everything is using PAT to get out, (although whoever set it up set it up like a nat with a global address pool). I have been trying to get an inbound static command to work, with no luck. First I wonder if I can do a static mapping for ingress on the same IP that is being used for PAT/NAT for egress. And if that is possible why can't I get through, I'm pretty sure the static command is right, and I needed to add two acl's (any to outside) (outside to inside) to get the packet trace in asdm to let the packet into the inside host, but still the translate isn't passing the packet tracing. Please any insight would be greatly appreciated. The log shows the port coming in as something different than what I expect: the 66.152.132.32/1064 should be 66.152.132.32/5900 (for vnc, which is the client I am testing with). These are the lines from the log: >4 Jul 12 2011 11:27:13 106023 66.152.132.32 outside-ip Deny tcp src Etherpoint:66.152.132.32/1064 dst Inside:outside-ip/5900 by access-group "Etherpoint_access_in" [0x0, 0x0] >4 Jul 12 2011 11:27:07 106023 66.152.132.32 outside-ip Deny tcp src Etherpoint:66.152.132.32/1064 dst Inside:outside-ip/5900 by access-group "Etherpoint_access_in" [0x0, 0x0] >4 Jul 12 2011 11:27:04 106023 66.152.132.32 outside-ip Deny tcp src Etherpoint:66.152.132.32/1064 dst Inside:outside-ip/5900 by These are the appropriate lines from the config: >access-list Etherpoint_access_in extended permit tcp any eq 5900 host outside-ip eq 5900 >access-list Etherpoint_access_in extended permit tcp host outside-ip eq 5900 host 192.168.125.8 eq 5900 >global (Etherpoint) 2 interface >nat (Inside) 0 access-list Inside_nat0_outbound >nat (Inside) 2 192.168.125.0 255.255.255.0 >static (Inside,Etherpoint) tcp interface 5900 192.168.125.8 5900 netmask 255.255.255.255 >no threat-detection statistics tcp-intercept >access-group Inside_access_in in interface Inside >access-group Etherpoint_access_in in interface Etherpoint Thanks In Advance Bill Kruchas From paul4004 at gmail.com Wed Jul 13 09:22:23 2011 From: paul4004 at gmail.com (PC) Date: Wed, 13 Jul 2011 08:22:23 -0600 Subject: ipv6 address family with vrf In-Reply-To: References: Message-ID: Mike, Support came in a later 12.4T train release, although you're probably best going to 15.0M at this point. You need advanced IP services,Advanced enterprise services or SP services. Consult cisco.com/go/fn. Both VRF and VRF-lite IPV6 support are under the same feature, but I forget what it's called in FN (IPV6 VPN, 6PE, or something similar). IP base and Advanced security are confirmed to not work. I went through this about a month ago. I wish Cisco would include feature parity for features between ipv4 and ipv6 like they recently announced on Catalyst products. This would help encourage ipv6 adoption in cases where it's otherwise discretionary. The lack of this particular missing feature (IPV6 VRF-lite support) affected IPV6 deployment for us in general on internet routers due to the financial costs of licensing advanced IP services. On Wed, Jul 13, 2011 at 7:14 AM, harbor235 wrote: > Has anyone been able to configure ipv4 and ipv6 AFI with VRF instances > simultaneously? Using > the 7200 and 12.4(25e), under the ipv6 address family the VRF sub commands > are not visible, > must be a feature? > > > thanx in advance, > > Mike > From cloos at jhcloos.com Wed Jul 13 09:13:06 2011 From: cloos at jhcloos.com (James Cloos) Date: Wed, 13 Jul 2011 10:13:06 -0400 Subject: NANOG List Update - Moving Forward In-Reply-To: <1154063.1343.1310487228300.JavaMail.root@benjamin.baylink.com> (Jay Ashworth's message of "Tue, 12 Jul 2011 12:13:48 -0400 (EDT)") References: <1154063.1343.1310487228300.JavaMail.root@benjamin.baylink.com> Message-ID: >>>>> "JA" == Jay Ashworth writes: JA> ----- Original Message ----- >> From: "Ben Carleton" >> * The mailing list is stripping out all Received: headers from prior >> to the message hitting the listserver JA> You're the third person to report that, but *I* am seeing incoming JA> Received headers in my messages here -- yours, for example, has them JA> all, even prior to the message hitting s0. That is because they switched back to the mailman infrastructure, again, after just a few hours on the bulk_mailer infrastructure. Look for mail with an envelope from of help at nanog for the problematic ones. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From scott.brim at gmail.com Wed Jul 13 09:39:26 2011 From: scott.brim at gmail.com (Scott Brim) Date: Wed, 13 Jul 2011 10:39:26 -0400 Subject: in defense of lisp (was: Anybody can participate in the IETF) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> Message-ID: On Wed, Jul 13, 2011 at 10:09, Randy Bush wrote: > btw, a litte birdie told me to take another look at > > 6296 IPv6-to-IPv6 Network Prefix Translation. M. Wasserman, F. Baker. > ? ? June 2011. (Format: TXT=73700 bytes) (Status: EXPERIMENTAL) > > which also could be considered to be in the loc/id space > > randy No, that's a misuse of "loc/id" since no identification is involved, even at the network layer -- but it is in the "reduce issues in global routing and local renumbering" space (that's part of what LISP does). Cameron: As for ILNP, it's going to be difficult to get from where things are now to a world where ILNP is not just useless overhead. When you finally do, considering what it gives you, will the journey have been worth it? LISP apparently has more benefits, and NPT6 is so much easier -- particularly if you have rapid adaptation to apparent address changes, which many apps have and all mobile devices need already -- sorry but I don't think ILNP is going to make it. You can't just say "the IETF should pay more attention". I've invited people to promote it and nobody stepped up. Scott From seth.mos at dds.nl Wed Jul 13 09:49:31 2011 From: seth.mos at dds.nl (Seth Mos) Date: Wed, 13 Jul 2011 16:49:31 +0200 Subject: in defense of lisp In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> Message-ID: <4E1DB07B.9010904@dds.nl> Op 13-7-2011 16:09, Randy Bush schreef: > > btw, a litte birdie told me to take another look at The free Open Source FreeBSD based pfSense firewall supports this. Not everyone can get BGP, specifically calling out residential connections here. As a 1:1 NAT mechanism it works pretty well, I can reach the outside, and the outside can reach me. Which I think is what was intended in the specifications. And pretty much the internet. It took me 4 months to write the IPv6 support in pfSense to what it is today. Which is not feature complete. But the NPT part was just a few hours in the grand scheme. I've also contacted the nice people from the draft that we support it. Since then we've got v4 and v6 with BGP at work so it's moot. But I digress. Kind regards, Seth Mos pfSense developer. > > > > 6296 IPv6-to-IPv6 Network Prefix Translation. M. Wasserman, F. Baker. > > June 2011. (Format: TXT=73700 bytes) (Status: EXPERIMENTAL) > > > > which also could be considered to be in the loc/id space > > > > randy > > > > From ops.lists at gmail.com Wed Jul 13 09:51:55 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 13 Jul 2011 20:21:55 +0530 Subject: NANOG List Update - Moving Forward In-Reply-To: References: <1154063.1343.1310487228300.JavaMail.root@benjamin.baylink.com> Message-ID: <3A22A127-DAFC-42C4-9B56-2FB0EF949BA0@gmail.com> Unconfigured bulk_mailer = lots of unsolicited bulk mail Oh well --srs Sent from my iPad On 13-Jul-2011, at 19:43, James Cloos wrote: >>>>>> "JA" == Jay Ashworth writes: > > JA> ----- Original Message ----- >>> From: "Ben Carleton" > >>> * The mailing list is stripping out all Received: headers from prior >>> to the message hitting the listserver > > JA> You're the third person to report that, but *I* am seeing incoming > JA> Received headers in my messages here -- yours, for example, has them > JA> all, even prior to the message hitting s0. > > That is because they switched back to the mailman infrastructure, again, > after just a few hours on the bulk_mailer infrastructure. > > Look for mail with an envelope from of help at nanog for the problematic ones. > > -JimC > -- > James Cloos OpenPGP: 1024D/ED7DAEA6 > From cb.list6 at gmail.com Wed Jul 13 10:07:24 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 13 Jul 2011 08:07:24 -0700 Subject: in defense of lisp (was: Anybody can participate in the IETF) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> Message-ID: On Jul 13, 2011 7:39 AM, "Scott Brim" wrote: > > On Wed, Jul 13, 2011 at 10:09, Randy Bush wrote: > > btw, a litte birdie told me to take another look at > > > > 6296 IPv6-to-IPv6 Network Prefix Translation. M. Wasserman, F. Baker. > > June 2011. (Format: TXT=73700 bytes) (Status: EXPERIMENTAL) > > > > which also could be considered to be in the loc/id space > > > > randy > > No, that's a misuse of "loc/id" since no identification is involved, > even at the network layer -- but it is in the "reduce issues in global > routing and local renumbering" space (that's part of what LISP does). > > Cameron: As for ILNP, it's going to be difficult to get from where > things are now to a world where ILNP is not just useless overhead. > When you finally do, considering what it gives you, will the journey > have been worth it? LISP apparently has more benefits, and NPT6 is so > much easier -- particularly if you have rapid adaptation to apparent > address changes, which many apps have and all mobile devices need > already -- sorry but I don't think ILNP is going to make it. You > can't just say "the IETF should pay more attention". I've invited > people to promote it and nobody stepped up. > "Difficult" depends on your time horizon. Ipv6 is/was difficult. Sctp is difficult, but I remain bullish on its value. ILNP may be more difficult, but i believe it is strategically correct. We can disagree on merits of competing RESEARCH topics. I am just providing "ops feedback ", to bring this thread full circle. Lastly, we must make sure that LISP does not become the next 6to4 where good intentions for RESEARCH become a quantifiable network nightmare. Cb From cb.list6 at gmail.com Wed Jul 13 10:09:13 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 13 Jul 2011 08:09:13 -0700 Subject: in defense of lisp In-Reply-To: <4E1DB07B.9010904@dds.nl> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> <4E1DB07B.9010904@dds.nl> Message-ID: On Jul 13, 2011 7:50 AM, "Seth Mos" wrote: > > Op 13-7-2011 16:09, Randy Bush schreef: > > > btw, a litte birdie told me to take another look at > > The free Open Source FreeBSD based pfSense firewall supports this. Not > everyone can get BGP, specifically calling out residential connections here. > > As a 1:1 NAT mechanism it works pretty well, I can reach the outside, > and the outside can reach me. Which I think is what was intended in the > specifications. And pretty much the internet. > > It took me 4 months to write the IPv6 support in pfSense to what it is > today. Which is not feature complete. But the NPT part was just a few > hours in the grand scheme. > > I've also contacted the nice people from the draft that we support it. > > Since then we've got v4 and v6 with BGP at work so it's moot. But I digress. > > Kind regards, > > Seth Mos > pfSense developer. > > Thank you for your work. CB > > > > > > 6296 IPv6-to-IPv6 Network Prefix Translation. M. Wasserman, F. Baker. > > > June 2011. (Format: TXT=73700 bytes) (Status: EXPERIMENTAL) > > > > > > which also could be considered to be in the loc/id space > > > > > > randy > > > > > > > From fred at cisco.com Wed Jul 13 10:09:21 2011 From: fred at cisco.com (Fred Baker) Date: Wed, 13 Jul 2011 11:09:21 -0400 Subject: in defense of lisp (was: Anybody can participate in the IETF) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> Message-ID: <5F86D723-D959-4AC2-9472-27B9B8658E14@cisco.com> On Jul 13, 2011, at 10:39 AM, Scott Brim wrote: > Cameron: As for ILNP, it's going to be difficult to get from where > things are now to a world where ILNP is not just useless overhead. > When you finally do, considering what it gives you, will the journey > have been worth it? LISP apparently has more benefits, and NPT6 is so > much easier -- particularly if you have rapid adaptation to apparent > address changes, which many apps have and all mobile devices need > already -- sorry but I don't think ILNP is going to make it. You > can't just say "the IETF should pay more attention". I've invited > people to promote it and nobody stepped up. I think ILNP is a great solution. My concern with it is that the needed changes to TCP and UDP are not likely to happen. From sulrich at botwerks.org Wed Jul 13 10:20:59 2011 From: sulrich at botwerks.org (steve ulrich) Date: Wed, 13 Jul 2011 10:20:59 -0500 Subject: in defense of lisp (was: Anybody can participate in the IETF) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> Message-ID: On Wed, Jul 13, 2011 at 10:07 AM, Cameron Byrne wrote: > On Jul 13, 2011 7:39 AM, "Scott Brim" wrote: >> >> On Wed, Jul 13, 2011 at 10:09, Randy Bush wrote: >> > btw, a litte birdie told me to take another look at >> > >> > 6296 IPv6-to-IPv6 Network Prefix Translation. M. Wasserman, F. Baker. >> > ? ? June 2011. (Format: TXT=73700 bytes) (Status: EXPERIMENTAL) >> > >> > which also could be considered to be in the loc/id space >> > >> > randy >> >> No, that's a misuse of "loc/id" since no identification is involved, >> even at the network layer -- but it is in the "reduce issues in global >> routing and local renumbering" space (that's part of what LISP does). >> >> Cameron: As for ILNP, it's going to be difficult to get from where >> things are now to a world where ILNP is not just useless overhead. >> When you finally do, considering what it gives you, will the journey >> have been worth it? ?LISP apparently has more benefits, and NPT6 is so >> much easier -- particularly if you have rapid adaptation to apparent >> address changes, which many apps have and all mobile devices need >> already -- sorry but I don't think ILNP is going to make it. ?You >> can't just say "the IETF should pay more attention". ?I've invited >> people to promote it and nobody stepped up. >> > > "Difficult" depends on your time horizon. Ipv6 is/was difficult. Sctp is > difficult, but I remain bullish on its value. ILNP may be more difficult, > but i believe it is strategically correct. > > We can disagree on merits of competing RESEARCH ?topics. I am just providing > "ops feedback ", to bring this thread full circle. > > Lastly, we must make sure that LISP does not become the next 6to4 where good > intentions for RESEARCH ?become a quantifiable network nightmare. i would agree that LISP hasn't necessarily improved the root problem posed. however, on this front nor it hasn't done any harm. the intriguing elements with LISP for me personally, are in all of the adjunct capabilities that a L/I split enables. there are some very valid and interesting applications that this enables and some novel technology capabilities that are exercised. (useful endpoint mobility, novel load balancing, encap data plane liveness, etc.) researching and getting our hands dirty as an industry with these technologies has considerable value. without actually poking at running code and pushing bits over these interfaces we run the risk of letting the perfect be the enemy of the good. i like the fact that this research let's us gauge how far from perfect the current state of the art is. fwiw - while there are folks that see LISP as an impending ops nightmare (if you don't like it, don't use it.) there are a number of folks for whom it provides compelling solutions to real problems that they have and they're keen on using it to solve those problems or explore the solution space. to that end i don't know that we need to make sure that LISP doesn't become anything. we need to find solutions to problems and rationally explore those solutions and incrementally enhance them. yes. i participate in the LISP research test bed in my (very) small way. -- steve ulrich (sulrich at botwerks.*) From james.harr at gmail.com Wed Jul 13 10:22:05 2011 From: james.harr at gmail.com (James Harr) Date: Wed, 13 Jul 2011 10:22:05 -0500 Subject: best practices for management nets in IPv6 In-Reply-To: <339D6250-1106-4590-8AC9-592A78351216@antelope.net> References: <339D6250-1106-4590-8AC9-592A78351216@antelope.net> Message-ID: I couldn't agree more. If you set up private address space, it's going to come back and make more work for you later. Set up public IPv6 addresses. If you need stateful connection filtering, put in a stateful firewall. If you really really need address obfuscation, you can still do NAT, but NAT from public addresses to public a public address or pool of public addresses. If you ever need to turn off NAT, it's a lot easier than renumbering hundreds of machines and you always have the option of disabling it per-host instead of doing an all-or-nothing transition. On Tue, Jul 12, 2011 at 7:32 PM, Joel Maslak wrote: > Public IPs. > > At some point you will have to manage something outside your current world or your organization will need to merge/partner/outsource/contract/etc with someone else's network and they might not be keen to route to your ULA space (and might not be more trustworthy than the internet at large anyhow). ?Think about things like VPN endpoints, video devices, telephones, etc, that may end up on a public network, maybe behind a device you manage. ?You may just manage routers today, but who knows about tomorrow. ?Put behind a firewall and use good ingress filtering throughout your network, separating trust zones with distinct subnets. > > If you are worried about forgetting to enable a firewall, put in a network management system to verify connectivity stays blocked combined with a monitored IDS. > -- ^[:wq^M From scott.brim at gmail.com Wed Jul 13 10:22:21 2011 From: scott.brim at gmail.com (Scott Brim) Date: Wed, 13 Jul 2011 11:22:21 -0400 Subject: in defense of lisp (was: Anybody can participate in the IETF) In-Reply-To: <5F86D723-D959-4AC2-9472-27B9B8658E14@cisco.com> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> <5F86D723-D959-4AC2-9472-27B9B8658E14@cisco.com> Message-ID: On Wed, Jul 13, 2011 at 11:09, Fred Baker wrote: > I think ILNP is a great solution. My concern with it is that the needed changes to TCP and UDP are not likely to happen. I guess I should clarify: I think ILNP is elegant. But the real Internet evolves incrementally, and only as needed. Other trajectories are much more likely. From fred at cisco.com Wed Jul 13 10:22:33 2011 From: fred at cisco.com (Fred Baker) Date: Wed, 13 Jul 2011 11:22:33 -0400 Subject: in defense of lisp (was: Anybody can participate in the IETF) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> Message-ID: On Jul 13, 2011, at 10:39 AM, Scott Brim wrote: > On Wed, Jul 13, 2011 at 10:09, Randy Bush wrote: >> btw, a litte birdie told me to take another look at >> >> 6296 IPv6-to-IPv6 Network Prefix Translation. M. Wasserman, F. Baker. >> June 2011. (Format: TXT=73700 bytes) (Status: EXPERIMENTAL) >> >> which also could be considered to be in the loc/id space >> >> randy > > No, that's a misuse of "loc/id" since no identification is involved, > even at the network layer -- but it is in the "reduce issues in global > routing and local renumbering" space (that's part of what LISP does). interesting, because that is exactly what Mike O'Dell suggested it as - a prefix/identification (loc/id) split. If you're going to take your line of reasoning, ILNP doesn't provide an identifier (as the term is defined in RFC 1992), and neither does LISP except as it redefines the terms to make it do. You're looking for something along the lines of HIP - which has other problems. I would describe NPTv6 as a location/identifier split in the sense that it makes the endpoint identifier in the IPv6 address independent of ISP's prefix - the PA (and therefore aggregatable) prefixes used outside the edge network are translated to the prefix used within the shop, and the host doesn't have to mess with them. As you point out, PA prefixes help with the route table - we aren't carrying infinite numbers of PI prefixes. To my way of thinking, shim6 was DOA if anything because it transferred the complexity of managing the route table from the transit networks to the edge networks, and the edge networks lacked both the expertise and the desire to deal with it. Folks are trampling the RIRs to get PI prefixes to avoid the multi-prefix model. But making the route table aggregate requires PA prefixes. Deploying ILNP (which is in many ways superior) requires a change to the TCP/UDP pseudoheader. Deploying NPTv6 makes the edge network look PA to the transit network, PI to the edge network, and doesn't change TCP. There is a headache with http/sip/etc referrals, which are better served if they use domain names anyway. But to my mind referrals have a solution if people choose to use it, so it's a solvable problem. So to me, NPTv6 fits pretty nicely. From rbonica at juniper.net Wed Jul 13 11:02:13 2011 From: rbonica at juniper.net (Ronald Bonica) Date: Wed, 13 Jul 2011 12:02:13 -0400 Subject: in defense of lisp (was: Anybody can participate in the IETF) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F3C65077@EMBX01-WF.jnpr.net> Scott, I am not so sure that Randy's suggestion can be dismissed out of hand. When we started down the path of locator/identifier separation, we did so because the separation of locators and identifiers might solve some real operational problems. We were not so interested in architectural purity. At this point, it might be interesting to do the following: - enumerate the operational problems solved by LISP - enumerate the subset of those problems also solved by RFC 6296 - execute a cost/benefit analysis on both solutions Ron > -----Original Message----- > From: Scott Brim [mailto:scott.brim at gmail.com] > Sent: Wednesday, July 13, 2011 10:39 AM > To: Randy Bush > Cc: North American Network Operators' Group > Subject: Re: in defense of lisp (was: Anybody can participate in the > IETF) > > On Wed, Jul 13, 2011 at 10:09, Randy Bush wrote: > > btw, a litte birdie told me to take another look at > > > > 6296 IPv6-to-IPv6 Network Prefix Translation. M. Wasserman, F. Baker. > > ? ? June 2011. (Format: TXT=73700 bytes) (Status: EXPERIMENTAL) > > > > which also could be considered to be in the loc/id space > > > > randy > > No, that's a misuse of "loc/id" since no identification is involved, > even at the network layer -- but it is in the "reduce issues in global > routing and local renumbering" space (that's part of what LISP does). > > Cameron: As for ILNP, it's going to be difficult to get from where > things are now to a world where ILNP is not just useless overhead. > When you finally do, considering what it gives you, will the journey > have been worth it? LISP apparently has more benefits, and NPT6 is so > much easier -- particularly if you have rapid adaptation to apparent > address changes, which many apps have and all mobile devices need > already -- sorry but I don't think ILNP is going to make it. You > can't just say "the IETF should pay more attention". I've invited > people to promote it and nobody stepped up. > > Scott From jared at puck.nether.net Wed Jul 13 12:18:04 2011 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 13 Jul 2011 13:18:04 -0400 Subject: best practices for management nets in IPv6 In-Reply-To: References: Message-ID: On Jul 12, 2011, at 5:31 PM, Tom Ammon wrote: > On your management nets (network device management nets) , what's the best approach for addressing them? Do you use ULA? Or do you use global addresses and just depend on router ACLs to protect things? How close are we to having a central registry for unique local addresses, and will that really happen? We allocate a /64 per subnet as that's what most of the management hosts expect. We also build the CoPP/ACLs in a comparable way for the ipv6 afi as one does for the ipv4 afi to protect the device from unauthorized access. having access to a trusted net will get you a response to your SYN, you still need the ability to auth past that point to various devices/systems. Getting on that trusted net and protecting it is clearly something important. Certainly one can go crazy with trying to secure ones networks by wrapping it in 802.1x with various backing systems. I do recommend making sure your security practices are sensible and not forgotten. Nothing like having a machine on the 'trusted' lan becoming compromised. Never know what's going to happen :) - Jared From fred at cisco.com Wed Jul 13 12:28:04 2011 From: fred at cisco.com (Fred Baker) Date: Wed, 13 Jul 2011 13:28:04 -0400 Subject: in defense of lisp (was: Anybody can participate in the IETF) In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F3C65077@EMBX01-WF.jnpr.net> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3C65077@EMBX01-WF.jnpr.net> Message-ID: <8C02984D-0B8C-4CE2-AB3E-0B77F6718AD3@cisco.com> On Jul 13, 2011, at 12:02 PM, Ronald Bonica wrote: > At this point, it might be interesting to do the following: > > - enumerate the operational problems solved by LISP > - enumerate the subset of those problems also solved by RFC 6296 > - execute a cost/benefit analysis on both solutions I'll let a LISP advocate state the values of LISP. My perception: it's a lot of overhead for what you actually get, comparable to building what Cisco once called "fast switching" into the network. In looking at 6296, I was trying to find a way to make edge networks be willing to use PA addresses instead of PI. If you have one ISP and never want to change ISPs, PA is wonderful; if you have multiple ISPs, the prevailing multihoming model in the IETF calls for you to have a subnet from each of your upstream prefixes on each LAN and to have your host divine which address pair implies the most acceptable route to your destination. If you have any ISP's prefix on your LAN and you want to remove the ISP (change to a different one, stop using one, whatever), you are somehow buried in renumbering (See RFC 4192). Edge networks are not crazy about renumbering, and they're not crazy about having a prefix per ISP on each LAN - hence PI. So, to get edge networks to use PA addresses, I reason that the edge network needs an address that is not derived from its upstream, and it has to be translated to the prefix of the upstream. The other factor (how to not require a change to TCP/UDP checksums) is the checksum update. So to my way of thinking, NPTv6 provides a way to statelessly (e.g. scalably) enable any host to talk with any host and at the same time make the edge network look PA to the upstream, has the managability characteristics of PI in the edge network, and not have to change TCP/UDP. LISP, to my knowledge, provides no way to push back on route table growth (it moves it from the transit network to the edge network, but the edge network still has to deal with it). To my mind, if you liked stateful NAT in IPv4, you'll like stateless NPTv6 in IPv6 better. With that, I'll return you to your more operational musings. I'm with the IETF. Please feel free to inform the world on how clueless I am operationally. I'm already convinced of the fact; that's why I talk with and listen to operators. From ncnet at sbcglobal.net Wed Jul 13 16:08:40 2011 From: ncnet at sbcglobal.net (Larry Stites) Date: Wed, 13 Jul 2011 14:08:40 -0700 Subject: OT: Given what you know now, if you were 21 again... In-Reply-To: Message-ID: Given what you know now, if you were 21 and just starting into networking / communications industry which areas of study or specialty would you prioritize? Thanks Larry Stites NCNetworks, Inc. Nevada City, CA 95959 From jeroen at unfix.org Wed Jul 13 16:21:53 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 13 Jul 2011 23:21:53 +0200 Subject: OT: Given what you know now, if you were 21 again... In-Reply-To: References: Message-ID: <4E1E0C71.3030502@unfix.org> On 2011-07-13 23:08 , Larry Stites wrote: > Given what you know now, if you were 21 and just starting into networking / > communications industry which areas of study or specialty would you > prioritize? Google. Greets, Jeroen From saku at ytti.fi Wed Jul 13 16:28:38 2011 From: saku at ytti.fi (Saku Ytti) Date: Thu, 14 Jul 2011 00:28:38 +0300 Subject: OT: Given what you know now, if you were 21 again... In-Reply-To: References: Message-ID: <20110713212838.GA17526@pob.ytti.fi> On (2011-07-13 14:08 -0700), Larry Stites wrote: > Given what you know now, if you were 21 and just starting into networking / > communications industry which areas of study or specialty would you > prioritize? Again? Buy AAPL, INTC and MSFT with loan money and study *cough*, finer things in life. But in all seriousness, networking like I suppose most professions are not about knowing one thing and stopping. It's evolving rather rapidly so most thing you know now are irrelevant in decade or two. What you should learn is how to learn, how to attack problems and learn to love doing both. -- ++ytti From rirving at antient.org Wed Jul 13 16:44:53 2011 From: rirving at antient.org (Richard Irving) Date: Wed, 13 Jul 2011 17:44:53 -0400 Subject: OT: Given what you know now, if you were 21 again... In-Reply-To: References: Message-ID: <4E1E11D5.4050803@antient.org> Learn how to delegate -everything-, and actually do -nothing-... .. how to blame someone else when something goes wrong, even if it's -your- fault, and take full credit whenever anything goes well, even if it -isn't- yours.. Then, and only then, Grasshopper, you will be ready for */management/* in -/*any*/- of the Fortune 500 corporations. :-P -- Who is John Galt ? On 07/13/2011 05:08 PM, Larry Stites wrote: > Given what you know now, if you were 21 and just starting into networking / > communications industry which areas of study or specialty would you > prioritize? > > > Thanks > > > > Larry Stites > NCNetworks, Inc. > Nevada City, CA 95959 > > From bhmccie at gmail.com Wed Jul 13 17:02:22 2011 From: bhmccie at gmail.com (-Hammer-) Date: Wed, 13 Jul 2011 17:02:22 -0500 Subject: OT: Given what you know now, if you were 21 again... In-Reply-To: References: Message-ID: <4E1E15EE.4050806@gmail.com> Women -Hammer- "I was a normal American nerd" -Jack Herer On 07/13/2011 04:08 PM, Larry Stites wrote: > Given what you know now, if you were 21 and just starting into networking / > communications industry which areas of study or specialty would you > prioritize? > > > Thanks > > > > Larry Stites > NCNetworks, Inc. > Nevada City, CA 95959 > > > > From jra at baylink.com Wed Jul 13 17:51:00 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 13 Jul 2011 18:51:00 -0400 (EDT) Subject: OT: Given what you know now, if you were 21 again... In-Reply-To: <4E1E15EE.4050806@gmail.com> Message-ID: <17910474.1515.1310597460875.JavaMail.root@benjamin.baylink.com> ---- Original Message ----- > From: "-Hammer-" > On 07/13/2011 04:08 PM, Larry Stites wrote: > > Given what you know now, if you were 21 and just starting into networking / > > communications industry which areas of study or specialty would you > > prioritize? > Women +30. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From scott at sberkman.net Wed Jul 13 19:01:40 2011 From: scott at sberkman.net (Scott Berkman) Date: Wed, 13 Jul 2011 20:01:40 -0400 Subject: OT: Given what you know now, if you were 21 again... In-Reply-To: <20110713212838.GA17526@pob.ytti.fi> References: <20110713212838.GA17526@pob.ytti.fi> Message-ID: <1310601700.17749.4.camel@ubuntu.ubuntu-domain> Saku nailed it. Learn the networking basics and underlying concepts (OSI!), everything else is an "application" that runs on that, and can be picked up pretty easily if you understand what it depends on. Wireshark (or your favorite capture tool) is your friend. That said, I feel knowing some of the parallels like *nix and vendor specifics (ie if you know Cisco IOS, many others follow this interface like a standard) really comes in useful over time. -Scott On Thu, 2011-07-14 at 00:28 +0300, Saku Ytti wrote: > On (2011-07-13 14:08 -0700), Larry Stites wrote: > > > Given what you know now, if you were 21 and just starting into networking / > > communications industry which areas of study or specialty would you > > prioritize? > > Again? Buy AAPL, INTC and MSFT with loan money and study *cough*, finer things > in life. > > But in all seriousness, networking like I suppose most professions are not > about knowing one thing and stopping. It's evolving rather rapidly so most > thing you know now are irrelevant in decade or two. What you should learn is > how to learn, how to attack problems and learn to love doing both. > From MGauvin at dryden.ca Wed Jul 13 19:09:52 2011 From: MGauvin at dryden.ca (Mark Gauvin) Date: Wed, 13 Jul 2011 19:09:52 -0500 Subject: OT: Given what you know now, if you were 21 again... In-Reply-To: <1310601700.17749.4.camel@ubuntu.ubuntu-domain> References: <20110713212838.GA17526@pob.ytti.fi>, <1310601700.17749.4.camel@ubuntu.ubuntu-domain> Message-ID: <4DEA063ACE629740877D59B74D6FB26424039E79A8@exchange.citydryden.local> Get an executive MBA then you can dictate to us lowly techs what technology we will use without ever having to know why. Plus you will earn 10x the $$$ by the time you are 30 without having to recertify every couple years. ________________________________________ From: Scott Berkman [scott at sberkman.net] Sent: Wednesday, July 13, 2011 7:01 PM To: Saku Ytti Cc: nanog at nanog.org Subject: Re: OT: Given what you know now, if you were 21 again... Saku nailed it. Learn the networking basics and underlying concepts (OSI!), everything else is an "application" that runs on that, and can be picked up pretty easily if you understand what it depends on. Wireshark (or your favorite capture tool) is your friend. That said, I feel knowing some of the parallels like *nix and vendor specifics (ie if you know Cisco IOS, many others follow this interface like a standard) really comes in useful over time. -Scott On Thu, 2011-07-14 at 00:28 +0300, Saku Ytti wrote: > On (2011-07-13 14:08 -0700), Larry Stites wrote: > > > Given what you know now, if you were 21 and just starting into networking / > > communications industry which areas of study or specialty would you > > prioritize? > > Again? Buy AAPL, INTC and MSFT with loan money and study *cough*, finer things > in life. > > But in all seriousness, networking like I suppose most professions are not > about knowing one thing and stopping. It's evolving rather rapidly so most > thing you know now are irrelevant in decade or two. What you should learn is > how to learn, how to attack problems and learn to love doing both. > From nathan at atlasnetworks.us Wed Jul 13 19:18:04 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Thu, 14 Jul 2011 00:18:04 +0000 Subject: OT: Given what you know now, if you were 21 again... In-Reply-To: <20110713212838.GA17526@pob.ytti.fi> References: <20110713212838.GA17526@pob.ytti.fi> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B4E02C5@ex-mb-1.corp.atlasnetworks.us> > > Given what you know now, if you were 21 and just starting into > > networking / communications industry which areas of study or specialty > > would you prioritize? > > But in all seriousness, networking like I suppose most professions are not > about knowing one thing and stopping. It's evolving rather rapidly so most > thing you know now are irrelevant in decade or two. What you should learn is > how to learn, how to attack problems and learn to love doing both. Totally agree. IMHO, the truly challenging (and most important) skills aren't technical in nature. They're things like the ability to work in, or especially lead, a team of people. Things like building functional business processes that account for all the little details of operations, or professionally handling customers with utterly disparate cultural values (timeliness, the honoring of contractual obligations, etc). So, I would put a strong initial emphasis on logic and critical thinking, as well as intercultural competence and basic business leadership/process engineering. I'd also snap up any courses I could find on learning effectively or on using research tools. Once you can learn effectively in a short period of time, and you know how to find the information you need to absorb, it becomes fairly trivial to acquire new technical (or otherwise) capacities. In fact, the limiting factor starts to become your imagination - "what do you think you want to learn?", and the best way to combat this is to have a balanced life with a healthy dose of social interaction (read: women - later, family). I've not yet met the person who won't burn out if they aren't distracted by non-virtual concerns on a regular basis. Nathan Eisenberg From rdobbins at arbor.net Wed Jul 13 22:28:47 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 14 Jul 2011 03:28:47 +0000 Subject: in defense of lisp (was: Anybody can participate in the IETF) In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F3C65077@EMBX01-WF.jnpr.net> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3C65077@EMBX01-WF.jnpr.net> Message-ID: <694FAD67-F4D3-4C85-8215-377A8B96DE91@arbor.net> On Jul 13, 2011, at 11:02 PM, Ronald Bonica wrote: > - enumerate the operational problems solved by LISP Separation of locator/ID is a fundamental architectural principle which transcends transport-specific (i.e., IPv4/IPv6) considerations. It allows for node/application/services agility, and in the case of the IPv4/IPv6 Internet, besides providing a way to solve mobility and to do on-demand dynamic provisioning/on-the-fly-reprovisioning of communications relationships, finally starts us down the long-overdue evolution towards an eventual fully out-of-band control plane. Controlling routing-table excursion in the IPv4/IPv6 Internet was/is the tactical problem that LISP was/is intended to address (pardon the pun), but the above long-term strategic benefits are its real value, IMHO. > - enumerate the subset of those problems also solved by RFC 6296 In light of the above, I view LISP and RFC6296 as orthogonal to one another. I also view RFC6296 as a perpetuation of the clear violation of the end-to-end principle (i.e., ' . . . functions placed at low levels of a system may be redundant or of little value when compared with the cost of providing them at that low level . . .') embodied in the abomination of NAT/PAT into IPv6, and the consequent instantiation of yet more unnecessary and harmful state into networks which are already deep in the throes of autogenic thromboembolism. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From randy at psg.com Wed Jul 13 22:49:09 2011 From: randy at psg.com (Randy Bush) Date: Thu, 14 Jul 2011 12:49:09 +0900 Subject: in defense of lisp (was: Anybody can participate in the IETF) In-Reply-To: <694FAD67-F4D3-4C85-8215-377A8B96DE91@arbor.net> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3C65077@EMBX01-WF.jnpr.net> <694FAD67-F4D3-4C85-8215-377A8B96DE91@arbor.net> Message-ID: > I also view RFC6296 as a perpetuation of the clear violation of the > end-to-end principle (i.e., ' . . . functions placed at low levels of > a system may be redundant or of little value when compared with the > cost of providing them at that low level . . .') embodied in the > abomination of NAT/PAT into IPv6, and the consequent instantiation of > yet more unnecessary and harmful state into networks which are already > deep in the throes of autogenic thromboembolism. great rant. not to quibble but i thought 6296 was stateless. randy From rdobbins at arbor.net Wed Jul 13 23:11:08 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 14 Jul 2011 04:11:08 +0000 Subject: in defense of lisp (was: Anybody can participate in the IETF) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3C65077@EMBX01-WF.jnpr.net> <694FAD67-F4D3-4C85-8215-377A8B96DE91@arbor.net> Message-ID: <1D00778E-B94E-40F4-AE70-2C4473CC7356@arbor.net> On Jul 14, 2011, at 10:49 AM, Randy Bush wrote: > not to quibble but i thought 6296 was stateless. AFAICT, the translators themselves are just rewriting addresses and not paying attention to 'connections', which is all to the good. But then we get to this: ----- 5.2. Recommendations for Application Writers Several mechanisms (e.g., STUN [RFC5389], Traversal Using Relays around NAT (TURN) [RFC5766], and Interactive Connectivity Establishment (ICE) [RFC5245]) have been used with traditional IPv4 NAT to circumvent some of the limitations of such devices. Similar mechanisms could also be applied to circumvent some of the issues with an NPTv6 Translator. However, all of these require the assistance of an external server or a function co-located with the translator that can tell an "internal" host what its "external" addresses are. ----- ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From marka at isc.org Wed Jul 13 23:16:56 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 14 Jul 2011 14:16:56 +1000 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: Your message of "Tue, 12 Jul 2011 23:22:20 MST." <430FFF20-43ED-45BB-846D-FEE8769FC399@bogus.com> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <56E0FB8F-BB53-4DB0-829B-39DFBAB483E8@bogus.com> <20110713014139.92A4611CB398@drugs.dv.isc.org> <9C391C3A-3535-4C47-A743-57287685942E@bogus.com> <20110713055952.EC84111CD0AA@drugs.dv.isc.org> <430FFF20-43ED-45BB-846D-FEE8769FC399@bogus.com> Message-ID: <20110714041656.2ADB411D2912@drugs.dv.isc.org> In message <430FFF20-43ED-45BB-846D-FEE8769FC399 at bogus.com>, Joel Jaeggli write s: > > On Jul 12, 2011, at 10:59 PM, Mark Andrews wrote: > >=20 > > I didn't claim it would work with existing CPE equipment. Declaring > > 6to4 historic won't work with existing CPE equipment either. > > If the hosts behind it stop using 2002::/16 addresses as a product of a = > software update which seems rather more likely (also there some evidence = > for that), it will. that said yes one assumption is that you have to = > continue to support it. When you switch the source address preference from 2002::/16 to IPv4 you loose insight into which machines have 2002::/16 addresses still without explict testing. > > > >> It is really hard to justify the expansion and deployment of new = > relays =3D > >> when in fact tunneled traffic can be observed to be on the decline =3D > >> (possibly because devices particularly hosts that do receive regular = > =3D > >> updates receive tweaks to their address selection algorithm). > >> =3D > >> = > http://asert.arbornetworks.com/2011/04/six-months-six-providers-and-ipv6/ > >=20 > > Which may or may not be a short term dip. > > correlation is not causation but... > > = > http://arstechnica.com/apple/news/2010/11/apple-fixes-broken-ipv6-by-break= > ing-it-some-more.ars > > > We are yet to see much in the > > way of IPv6 only content. When that appears, which it will, the = > tunneled > > traffic will go up unless ISPs have deployed native IPv6 to all = > customers. > > Are you willing to bet on which will happen first? > > I'm willing to bet that subpar experience due to auto-tunneling is = > considered a liability for content providers. > > > This whole area is in a state of flux. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From don at bowenvale.co.nz Thu Jul 14 01:47:06 2011 From: don at bowenvale.co.nz (Don Gould) Date: Thu, 14 Jul 2011 18:47:06 +1200 Subject: OT: Given what you know now, if you were 21 again... In-Reply-To: References: Message-ID: <4E1E90EA.20004@bowenvale.co.nz> * OSI layers 1 to 3 - so CCNA, MCP (or something dumb MS like), RHCE * Electrical eng - to best understand about the basics of copper and fibre. Also some focus on power systems - understand how a psu actually works! * wireless eng - you need to understand how a radio actually works, how an antenna actually works - do a course that involves building such - wokfy (google it!), tin can antennas. * C and assembler programming Yip, everything I'm talking about is low level and under well the bonnet. Every other bit of crap can be thrown on top. Sure, you can become an AppleTalk expert... what happens if we stop using that protocol? You can become an Exchange expert... what happens if someone... well you get the idea. HTH D On 14/07/2011 9:08 a.m., Larry Stites wrote: > Given what you know now, if you were 21 and just starting into networking / > communications industry which areas of study or specialty would you > prioritize? > > > Thanks > > > > Larry Stites > NCNetworks, Inc. > Nevada City, CA 95959 > > > -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699 From don at bowenvale.co.nz Thu Jul 14 01:48:54 2011 From: don at bowenvale.co.nz (Don Gould) Date: Thu, 14 Jul 2011 18:48:54 +1200 Subject: Spam? In-Reply-To: <4E1C0CFC.70505@paulgraydon.co.uk> References: <4E1C0CFC.70505@paulgraydon.co.uk> Message-ID: <4E1E9156.5040104@bowenvale.co.nz> OMG can't you people run proper spam filtering on your own mail servers that filter out the nanog messages that are spam?! I think I've had two messages in the last month, while others of you are talking about dozens? Do you need to buy some hosting for your email accounts? D On 12/07/2011 8:59 p.m., Paul Graydon wrote: > New location means we now get spam on Nanog? Could we go back to the old > place? > -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699 From paul at paulgraydon.co.uk Thu Jul 14 02:07:56 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Wed, 13 Jul 2011 21:07:56 -1000 Subject: Spam? In-Reply-To: <4E1E9156.5040104@bowenvale.co.nz> References: <4E1C0CFC.70505@paulgraydon.co.uk> <4E1E9156.5040104@bowenvale.co.nz> Message-ID: <4E1E95CC.4060900@paulgraydon.co.uk> > OMG can't you people run proper spam filtering on your own mail > servers that filter out the nanog messages that are spam?! > > I think I've had two messages in the last month, while others of you > are talking about dozens? > > Do you need to buy some hosting for your email accounts? My filtering works great, thanks. It's just that I'd whitelisted Nanog as a reliable source of e-mail. Under the mailman setup where only subscribers were allowed to post that wasn't a problem. With the new format it was and a good half dozen e-mails got through to me (I certainly didn't see dozens). Does make me rather curious what the rejection stats are like for the old Mailman setup. Paul From leigh.porter at ukbroadband.com Thu Jul 14 05:22:50 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Thu, 14 Jul 2011 10:22:50 +0000 Subject: OT: Given what you know now, if you were 21 again... In-Reply-To: <4E1E90EA.20004@bowenvale.co.nz> References: , <4E1E90EA.20004@bowenvale.co.nz> Message-ID: On 14/07/2011 9:08 a.m., Larry Stites wrote: > Given what you know now, if you were 21 and just starting into networking / > communications industry which areas of study or specialty would you > prioritize? > Rebeccah Harris in my physics lectures. She was clearly up for it. -- Leigh ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From rsk at gsp.org Thu Jul 14 05:27:21 2011 From: rsk at gsp.org (Richard Kulawiec) Date: Thu, 14 Jul 2011 06:27:21 -0400 Subject: Spam? In-Reply-To: <4E1E9156.5040104@bowenvale.co.nz> References: <4E1C0CFC.70505@paulgraydon.co.uk> <4E1E9156.5040104@bowenvale.co.nz> Message-ID: <20110714102721.GA30668@gsp.org> On Thu, Jul 14, 2011 at 06:48:54PM +1200, Don Gould wrote: > OMG can't you people run proper spam filtering on your own mail > servers that filter out the nanog messages that are spam?! One of the fundamental principles of spam mitigation is that blocking is usually best (in terms of: efficacy, accuracy, resource minimization, and other metrics) when applied as close to the source as possible. In the case of mailing lists, such as this one, it has been a best practice for many years to only permit traffic from subscribers (and optionally, from individually-listed addresses, which are often alternate addresses for subscribers). It is clear that a serious mistake was made during the attempted migration of this list, i.e., this best practice was not followed, thus allowing some number of messages from non-subscribers to reach some number of subscribers. The proper solution to this is most emphatically not to ask the thousands of NANOG subscribers to adjust their mail systems; the proper solution is to continue to employ this best practice. ---rsk From ben at adversary.org Thu Jul 14 08:57:51 2011 From: ben at adversary.org (Ben McGinnes) Date: Thu, 14 Jul 2011 23:57:51 +1000 Subject: NANOG List Update - Moving Forward In-Reply-To: <20110713133709.GA22505@gsp.org> References: <4E1C5676.9050907@ahnberg.pp.se> <20110713133709.GA22505@gsp.org> Message-ID: <4E1EF5DF.6010700@adversary.org> On 13/07/11 11:37 PM, Richard Kulawiec wrote: > On Tue, Jul 12, 2011 at 04:13:10PM +0200, Mattias Ahnberg wrote: >> I might have missed some discussion; but why are we moving >> away from mailman, and what software is in the new system? > > Seconded. Mailman is presently the gold standard for mailing list > management Apparently the main exception to this is where you're running multiple lists with similar names, such as when creating lists for multiple languages (e.g. announce at example.com, announce at it.example.com, announce at jp.example.com, etc.). This is the problem the Document Foundation found itself with and they opted for mlmmj (with the exception of one list which does use Mailman), but it has other issues and I definitely wouldn't want to see NANOG go down that path. Since NANOG doesn't need to deal with the similar names/multilingual problem, that shouldn't be an issue. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: From r.hyunseog at ieee.org Thu Jul 14 09:24:27 2011 From: r.hyunseog at ieee.org (Alex Ryu) Date: Thu, 14 Jul 2011 09:24:27 -0500 Subject: NANOG List Update - Moving Forward In-Reply-To: <4E1EF5DF.6010700@adversary.org> References: <4E1C5676.9050907@ahnberg.pp.se> <20110713133709.GA22505@gsp.org> <4E1EF5DF.6010700@adversary.org> Message-ID: That issue can be resolved by changing email addresses for multiple language support by using announce-jp at example.com, anounce-it at example.com ? Alex On Thu, Jul 14, 2011 at 8:57 AM, Ben McGinnes wrote: > On 13/07/11 11:37 PM, Richard Kulawiec wrote: >> On Tue, Jul 12, 2011 at 04:13:10PM +0200, Mattias Ahnberg wrote: >>> I might have missed some discussion; but why are we moving >>> away from mailman, and what software is in the new system? >> >> Seconded. ?Mailman is presently the gold standard for mailing list >> management > > Apparently the main exception to this is where you're running multiple > lists with similar names, such as when creating lists for multiple > languages (e.g. announce at example.com, announce at it.example.com, > announce at jp.example.com, etc.). ?This is the problem the Document > Foundation found itself with and they opted for mlmmj (with the > exception of one list which does use Mailman), but it has other issues > and I definitely wouldn't want to see NANOG go down that path. ?Since > NANOG doesn't need to deal with the similar names/multilingual > problem, that shouldn't be an issue. > > > Regards, > Ben > > From ben at adversary.org Thu Jul 14 10:54:01 2011 From: ben at adversary.org (Ben McGinnes) Date: Fri, 15 Jul 2011 01:54:01 +1000 Subject: NANOG List Update - Moving Forward In-Reply-To: References: <4E1C5676.9050907@ahnberg.pp.se> <20110713133709.GA22505@gsp.org> <4E1EF5DF.6010700@adversary.org> Message-ID: <4E1F1119.9080700@adversary.org> On 15/07/11 12:24 AM, Alex Ryu wrote: > That issue can be resolved by changing email addresses for multiple > language support by using announce-jp at example.com, > anounce-it at example.com ? Yeah, that's how I'd get around it. I think the Document Foundation had some other issues, like wanting addresses to be consistent across a large number of subdomains and I can see their point with it. Obviously it's not a case that NANOG has to deal with. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: From mksmith at adhost.com Thu Jul 14 12:26:01 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Thu, 14 Jul 2011 17:26:01 +0000 Subject: NANOG - Call for Volunteers Message-ID: Hello All: Given the issues we had with the mailing list transition, we would like to solicit volunteers to assist in testing the "new" configuration. Please note, we are just moving the existing Mailman configuration to a new server under our control, but we have to move the list due to contractual obligations. Here's the basic scenario. 1) Build replica of existing NANOG Mailman server and configuration, except we are updating all of the underlying applications, including the actual OS. 2) Create a test at mailtest.nanog.org mailing list 3) Have volunteers hammer the list and make sure the software setup is correct 4) Sync the existing list data to the new server 5) Flip DNS so that nanog at nanog.org is now served from the new server If you are available and willing to assist in this test, please send me an email directly with the address you would like to use. I will add you to the new list when the software is configured and you will receive the usual welcome message. Our timeline is tight for this transition; we have to be moved over to the new server no later than July 31st, so active testing and reporting is key. Thank You, Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) From Jeff.Cartier at pernod-ricard.com Thu Jul 14 14:34:04 2011 From: Jeff.Cartier at pernod-ricard.com (Jeff Cartier) Date: Thu, 14 Jul 2011 19:34:04 +0000 Subject: Enterprise Internet - Question Message-ID: <6EDE133FF50DBA4B963028BD5CD690DD26971B@CAPRGWLKWEMBX1.pernod-ricard.group> Hi All, I just wanted to throw a question out to the list... In our data center we feed Internet to some of our US based offices and every now and again we receive complaints that they can't access some US based Internet content because they are coming from a Canadian based IP. This has sparked an interesting discussion around a few questions....of which I'd like to hear the lists opinions on. - How should/can an enterprise deal with accessibility to internet content issues? (ie. that whole coming from a Canadian IP accessing US content) o Side question on that - Could we simply obtain a US based IP address and selectively NAT? - Does the idea of regional Internet locations make sense? If so, when do they make sense? For instance, having a hub site in South America (ie. Brazil) and having all offices in Venezuela, Peru and Argentina route through a local Internet feed in Brazil. - Does the idea of having local Internet at each site make more sense? If so why? Again, I would appreciate to hear the opinion from SP oriented minds...based on what they've seen from customers...and network administrators running large enterprises in different companies. Off-list replies are also appreciated. Thanks!!! ...jc __________________________________________________________________ DISCLAIMER: This e-mail contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail. This message has been scanned for the presence of computer viruses, Spam, and Explicit Content. From phil at atdot.at Thu Jul 14 14:57:24 2011 From: phil at atdot.at (Phil Sykes) Date: Thu, 14 Jul 2011 20:57:24 +0100 Subject: Enterprise Internet - Question In-Reply-To: <6EDE133FF50DBA4B963028BD5CD690DD26971B@CAPRGWLKWEMBX1.pernod-ricard.group> References: <6EDE133FF50DBA4B963028BD5CD690DD26971B@CAPRGWLKWEMBX1.pernod-ricard.group> Message-ID: Hi Jeff, You might have some luck following the instructions on http://nanog.cluepon.net/index.php/GeoIP to register one particular /32 within your Canadian-announced netblock as being in the USA, and selectively NATing as you suggest, but I believe some stricter GeoIP databases check next hops and expected latency and might catch you out. We're lucky enough to have proxies in most geographies where we operate, so if a user has GeoIP issues we talk them through changing their proxy settings (you could also use a personal PAC file). (My employer's) principles in favour of a local internet breakout: - Is breaking out to the internet locally significantly cheaper than backhauling over private WAN (some MPLS providers will offer a local internet breakout as a VRF; this avoids the need for two access circuits) - Do you need to congest the internet traffic more than/independently to the private WAN traffic? - Would a tunnel over the internet be a useful backup to private circuits? - Are there latency-related performance reasons (lots of local content) to break out locally? - Are there regulatory reasons? (e.g. Middle East / Chinese state-level filtering) Against local breakout: - Do you need to limit the number of locations with an internet breakout because you have a heavyweight security stack protecting an internet connection (filtering proxy, IDS/IPS, multi-layer HA firewalls)? - Is local internet of poor quality? Regards, Phil Sykes Network Architect $LARGE_OIL_COMPANY On Thu, Jul 14, 2011 at 8:34 PM, Jeff Cartier < Jeff.Cartier at pernod-ricard.com> wrote: > Hi All, > > I just wanted to throw a question out to the list... > > In our data center we feed Internet to some of our US based offices and > every now and again we receive complaints that they can't access some US > based Internet content because they are coming from a Canadian based IP. > > This has sparked an interesting discussion around a few questions....of > which I'd like to hear the lists opinions on. > > - How should/can an enterprise deal with accessibility to internet > content issues? (ie. that whole coming from a Canadian IP accessing US > content) > > o Side question on that - Could we simply obtain a US based IP address > and selectively NAT? > > - Does the idea of regional Internet locations make sense? If so, > when do they make sense? For instance, having a hub site in South America > (ie. Brazil) and having all offices in Venezuela, Peru and Argentina route > through a local Internet feed in Brazil. > > - Does the idea of having local Internet at each site make more > sense? If so why? > > > Again, I would appreciate to hear the opinion from SP oriented > minds...based on what they've seen from customers...and network > administrators running large enterprises in different companies. Off-list > replies are also appreciated. > > Thanks!!! > > ...jc > > > > > __________________________________________________________________ > DISCLAIMER: This e-mail contains proprietary information some or all of > which may be legally privileged. It is for the intended recipient only. If > an addressing or transmission error has misdirected this e-mail, please > notify the author by replying to this e-mail. If you are not the intended > recipient you must not use, disclose, distribute, copy, print, or rely on > this e-mail. > > This message has been scanned for the presence of computer viruses, Spam, > and Explicit Content. > > From owen at delong.com Thu Jul 14 16:01:31 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 14 Jul 2011 14:01:31 -0700 Subject: Enterprise Internet - Question In-Reply-To: <6EDE133FF50DBA4B963028BD5CD690DD26971B@CAPRGWLKWEMBX1.pernod-ricard.group> References: <6EDE133FF50DBA4B963028BD5CD690DD26971B@CAPRGWLKWEMBX1.pernod-ricard.group> Message-ID: <6325B189-76E0-4573-ADB8-72B122870412@delong.com> On Jul 14, 2011, at 12:34 PM, Jeff Cartier wrote: > Hi All, > > I just wanted to throw a question out to the list... > > In our data center we feed Internet to some of our US based offices and every now and again we receive complaints that they can't access some US based Internet content because they are coming from a Canadian based IP. > > This has sparked an interesting discussion around a few questions....of which I'd like to hear the lists opinions on. > > - How should/can an enterprise deal with accessibility to internet content issues? (ie. that whole coming from a Canadian IP accessing US content) > This is an example of why content restriction based on IP address geolocation is such a bad idea in general. Frankly, the easiest thing to do (since most Canadian companies aren't as brain-dead) is to update your whois records with the address of the block allocated to your datacenter so that it looks like it's in one of your US offices. I realize this sounds silly for a variety of reasons, but, it solves the problem without expensive or configuration-intensive workarounds such as selective NAT, etc. > o Side question on that - Could we simply obtain a US based IP address and selectively NAT? > You can, but, you can also hit yourself over the head repeatedly with a hammer. Selective NAT will yield more content, but, the pain levels will probably be similar. > - Does the idea of regional Internet locations make sense? If so, when do they make sense? For instance, having a hub site in South America (ie. Brazil) and having all offices in Venezuela, Peru and Argentina route through a local Internet feed in Brazil. > Not really. The whole content-restriction by IP geolocation thing also doesn't make sense. Unfortunately, the fact that something is nonsensical does not prevent someone from doing it or worse, selling it. You should do what makes sense for the economics of the topology you need. The address geolocation issues can usually be best addressed by manipulating whois. If your address block from ARIN is an allocation, you can manipulate sub-block address registration issues through the use of SWIP, for example. > - Does the idea of having local Internet at each site make more sense? If so why? > That's really more of an economic and policy question within your organization than a technical one. > Owen From jason at thebaughers.com Thu Jul 14 16:29:51 2011 From: jason at thebaughers.com (Jason Baugher) Date: Thu, 14 Jul 2011 16:29:51 -0500 Subject: OT: Given what you know now, if you were 21 again... In-Reply-To: <20110713212838.GA17526@pob.ytti.fi> References: <20110713212838.GA17526@pob.ytti.fi> Message-ID: <4E1F5FCF.3060603@thebaughers.com> On 7/13/2011 4:28 PM, Saku Ytti wrote: > On (2011-07-13 14:08 -0700), Larry Stites wrote: > >> Given what you know now, if you were 21 and just starting into networking / >> communications industry which areas of study or specialty would you >> prioritize? > Again? Buy AAPL, INTC and MSFT with loan money and study *cough*, finer things > in life. > > But in all seriousness, networking like I suppose most professions are not > about knowing one thing and stopping. It's evolving rather rapidly so most > thing you know now are irrelevant in decade or two. What you should learn is > how to learn, how to attack problems and learn to love doing both. > +1 If I had to have a job where I did the same thing every day, year after year, I'd stab a pencil in my eye. I love that our industry is constantly evolving. Jason From drais at icantclick.org Thu Jul 14 16:35:32 2011 From: drais at icantclick.org (david raistrick) Date: Thu, 14 Jul 2011 17:35:32 -0400 (EDT) Subject: Enterprise Internet - Question In-Reply-To: <6EDE133FF50DBA4B963028BD5CD690DD26971B@CAPRGWLKWEMBX1.pernod-ricard.group> References: <6EDE133FF50DBA4B963028BD5CD690DD26971B@CAPRGWLKWEMBX1.pernod-ricard.group> Message-ID: On Thu, 14 Jul 2011, Jeff Cartier wrote: > - Does the idea of having local Internet at each site make more sense? > If so why? IME, costs for private backhaul circuits of any flavor are significantly higher than costs for plain internet access - so backhauling internet access (unless you have extremely restrictive access policies that you can actually enforce) through your WAN would/should cost through the nose. Routing only WAN traffic through the WAN reduces the size/scope/impact on those more expensive circuits. Probably at the expense of additional complexity, of course. -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From cmadams at hiwaay.net Thu Jul 14 16:40:05 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 14 Jul 2011 16:40:05 -0500 Subject: OT: Given what you know now, if you were 21 again... In-Reply-To: <4E1F5FCF.3060603@thebaughers.com> References: <20110713212838.GA17526@pob.ytti.fi> <4E1F5FCF.3060603@thebaughers.com> Message-ID: <20110714214005.GI10717@hiwaay.net> Once upon a time, Jason Baugher said: > If I had to have a job where I did the same thing every day, year after > year, I'd stab a pencil in my eye. I love that our industry is > constantly evolving. Definate +1 to that. I look at how my father's job has changed in his 49+ years; he's gone from a hardware-in-the-loop simulator that took a room full of analog computer (because digital computers weren't fast enough) to where computers are small and powerful enough that they looked at running a sim in real-time on the flying vehicle (as additional guidance feedback). I dont't think anyone can realistically say what the Internet will look like 10 years from now, much less 50. Pundits like to guess, but they usually miss their "next year" predictions anyway. :-) -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From owen at delong.com Thu Jul 14 18:03:37 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 14 Jul 2011 16:03:37 -0700 Subject: Enterprise Internet - Question In-Reply-To: References: <6EDE133FF50DBA4B963028BD5CD690DD26971B@CAPRGWLKWEMBX1.pernod-ricard.group> Message-ID: <227A9D58-D899-4FDF-8FD0-EC9776496F03@delong.com> On Jul 14, 2011, at 2:35 PM, david raistrick wrote: > On Thu, 14 Jul 2011, Jeff Cartier wrote: > >> - Does the idea of having local Internet at each site make more sense? If so why? > > IME, costs for private backhaul circuits of any flavor are significantly higher than costs for plain internet access - so backhauling internet access (unless you have extremely restrictive access policies that you can actually enforce) through your WAN would/should cost through the nose. Routing only WAN traffic through the WAN reduces the size/scope/impact on those more expensive circuits. Probably at the expense of additional complexity, of course. > In fact, it is often more cost effective to multihome each site and use VPNs for your WAN. Owen From fernando at gont.com.ar Thu Jul 14 19:29:35 2011 From: fernando at gont.com.ar (Fernando Gont) Date: Thu, 14 Jul 2011 21:29:35 -0300 Subject: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)) In-Reply-To: <1310429850.2382.26.camel@karl> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <1310429850.2382.26.camel@karl> Message-ID: <4E1F89EF.9090106@gont.com.ar> On 07/11/2011 09:17 PM, Karl Auer wrote: > I realise this is not "specific implementations" as you requested, but > it seems to me that the problem is generic enough not to require that. > > The attack is made possible by the design of the protocol, not any > failing of specific implementations. Specific implementations need to > describe what they've done about it (mitigation or prevention). Vulnerability to this specific issues has a great deal to do with the implementation. After all, whenever there's a data structure that can potentially grow out of bounds (or hit a limit), it becomes a resource management issue. In this particular case, if the implementation enforces a limit on the number of entries in the "INCOMPLETE" state, then only nodes that have never communicated with the outside world could be affected by this attack. And if those entries that are in the "INCOMPLETE" state are pruned periodically (e.g. in a round-robin fashion), chances are that even those "new hosts" would be able to get into the neighbor cache and hence remain unaffected by this attack. Thanks, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From mysidia at gmail.com Thu Jul 14 20:24:50 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 14 Jul 2011 20:24:50 -0500 Subject: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)) In-Reply-To: <4E1F89EF.9090106@gont.com.ar> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <1310429850.2382.26.camel@karl> <4E1F89EF.9090106@gont.com.ar> Message-ID: On Thu, Jul 14, 2011 at 7:29 PM, Fernando Gont wrote: > On 07/11/2011 09:17 PM, Karl Auer wrote: > Vulnerability to this specific issues has a great deal to do with the > implementation. After all, whenever there's a data structure that can Yes > In this particular case, if the implementation enforces a limit on the > number of entries in the "INCOMPLETE" state, then only nodes that have > never communicated with the outside world could be affected by this > attack. And if those entries that are in the "INCOMPLETE" state are > pruned periodically (e.g. in a round-robin fashion), chances are that Not only that but it's possible to differentiate _how_ an entry is added to the table when the table reaches a "high water mark" it's possible to drop the packet that was attempting to cause a NDP discover, fail to add the INCOMPLETE entry to the table, but _still_ send the outgoing NDP neighbor solicitation, and complete the entry or "whitelist" the destination if the neighbor advertises itself. That is: if the destination is good, the neighbor will respond to the NDP solicit, even though the neighbor doesn't have an entry in the table. So a small number of packets are lost at initial setup, due to the attack, but further packets are unaffected, So long as the attack does not overwhelm router CPU, and so long as the INCOMPLETE entry high water mark is at a low enough level, so there is still ample space in the table. Even more sophisticated strategies may be available. It should be possible to mitigate this, so long as the attack does not actually originate from a neighbor on the same subnet as a router IP interface on an IPv6 subnet with sufficient number of IPs. > even those "new hosts" would be able to get into the neighbor cache and > hence remain unaffected by this attack. > > Thanks, -- -JH From randy at psg.com Thu Jul 14 20:44:52 2011 From: randy at psg.com (Randy Bush) Date: Thu, 14 Jul 2011 18:44:52 -0700 Subject: in defense of lisp (was: Anybody can participate in the IETF) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> Message-ID: you want to give ops feedback to the ietf, well ... i suggest a loc/id session at the next nanog, 20-30 mins each for LISP ILNP 6296 where each is explained at an architectural level in some detail with also a predeterimied list of questions such as "how does this address loc/id separation, routing table scaling, incremental deployment, state of implementation/testing, ..." and then a half hour where someone sums up the similarities and differences. and someone writes it up. randy From owen at delong.com Thu Jul 14 20:47:26 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 14 Jul 2011 18:47:26 -0700 Subject: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <1310429850.2382.26.camel@karl> <4E1F89EF.9090106@gont.com.ar> Message-ID: On Jul 14, 2011, at 6:24 PM, Jimmy Hess wrote: > On Thu, Jul 14, 2011 at 7:29 PM, Fernando Gont wrote: >> On 07/11/2011 09:17 PM, Karl Auer wrote: >> Vulnerability to this specific issues has a great deal to do with the >> implementation. After all, whenever there's a data structure that can > Yes > >> In this particular case, if the implementation enforces a limit on the >> number of entries in the "INCOMPLETE" state, then only nodes that have >> never communicated with the outside world could be affected by this >> attack. And if those entries that are in the "INCOMPLETE" state are >> pruned periodically (e.g. in a round-robin fashion), chances are that > > Not only that but it's possible to differentiate _how_ an entry is added to > the table when the table reaches a "high water mark" it's possible > to drop the packet that was attempting to cause a NDP discover, fail to add > the INCOMPLETE entry to the table, but _still_ send the outgoing NDP > neighbor solicitation, and complete the entry or "whitelist" the destination > if the neighbor advertises itself. > > That is: if the destination is good, the neighbor will respond to the > NDP solicit, > even though the neighbor doesn't have an entry in the table. > > So a small number of packets are lost at initial setup, due to the > attack, but further > packets are unaffected, > > So long as the attack does not overwhelm router CPU, and so long as the > INCOMPLETE entry high water mark is at a low enough level, > so there is still ample space in the table. > > > Even more sophisticated strategies may be available. > > It should be possible to mitigate this, so long as the attack does not actually > originate from a neighbor on the same subnet as a router IP interface on > an IPv6 subnet with sufficient number of IPs. > >> even those "new hosts" would be able to get into the neighbor cache and >> hence remain unaffected by this attack. >> >> Thanks, > > -- > -JH Very true. This is where Mr. Wheeler's arguments depart from reality. He's right in that the problem can't be truly fixed without some very complicated code added to lots of devices, but, it can be mitigated relatively easily and mitigation really is good enough for most real world purposes. Owen From mysidia at gmail.com Thu Jul 14 21:00:49 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 14 Jul 2011 21:00:49 -0500 Subject: Enterprise Internet - Question In-Reply-To: <6EDE133FF50DBA4B963028BD5CD690DD26971B@CAPRGWLKWEMBX1.pernod-ricard.group> References: <6EDE133FF50DBA4B963028BD5CD690DD26971B@CAPRGWLKWEMBX1.pernod-ricard.group> Message-ID: On Thu, Jul 14, 2011 at 2:34 PM, Jeff Cartier wrote: > - ? ? ? ? ?How should/can an enterprise deal with accessibility to internet content issues? (ie. that whole coming from a Canadian IP accessing US content) You indeed might feed traffic towards such "IP restricted" sites through a transparent proxy server, or policy NAT based on destination IP, reducing all traffic towards those sites from "canadian" ranges, to a pool of source IP addresses. Just to take a jab at absurd "content restriction" by IP methods, a reminder... There's no such thing as a "US" IP address. There's no such thing as a Canadian IP address. There are IPs delegated to network operators who have an AS in certain countries, but that is no proof of country of origin. What "country" is an IP address located in when it is assigned to a terminal server, VPN server, or proxy server in country $X, and there are authorized users that connect from 16 different countries? -- -JH From fernando at gont.com.ar Thu Jul 14 21:06:02 2011 From: fernando at gont.com.ar (Fernando Gont) Date: Thu, 14 Jul 2011 23:06:02 -0300 Subject: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <1310429850.2382.26.camel@karl> <4E1F89EF.9090106@gont.com.ar> Message-ID: <4E1FA08A.8020503@gont.com.ar> On 07/14/2011 10:24 PM, Jimmy Hess wrote: >> In this particular case, if the implementation enforces a limit on the >> number of entries in the "INCOMPLETE" state, then only nodes that have >> never communicated with the outside world could be affected by this >> attack. And if those entries that are in the "INCOMPLETE" state are >> pruned periodically (e.g. in a round-robin fashion), chances are that > > Not only that but it's possible to differentiate _how_ an entry is added to > the table when the table reaches a "high water mark" it's possible > to drop the packet that was attempting to cause a NDP discover, fail to add > the INCOMPLETE entry to the table, but _still_ send the outgoing NDP > neighbor solicitation, and complete the entry or "whitelist" the destination > if the neighbor advertises itself. Agreed. I should double-check whether there's room in the current specifications to do this -- however, whether the specs allow this or not is irrelevant. At the point you're being hit with a DoS, you better do something about it (particularly when it's possible, as in this case!) > That is: if the destination is good, the neighbor will respond to the > NDP solicit, > even though the neighbor doesn't have an entry in the table. Modulo that when the high water mark has not been hit, the router should probably *not* create ND cache entries in response to this "gratuitous" ND advertisements, since otherwise it would open the door to a DoS from local attackers. > It should be possible to mitigate this, so long as the attack does not actually > originate from a neighbor on the same subnet as a router IP interface on > an IPv6 subnet with sufficient number of IPs. Well, unless there's some layer-2 anti-spoofing mitigation in place, with /64 subnets the "local attacker" typically *will* have enough addresses. Thanks, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From jared at puck.nether.net Thu Jul 14 21:35:40 2011 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 14 Jul 2011 22:35:40 -0400 Subject: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)) In-Reply-To: <4E1FA08A.8020503@gont.com.ar> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <1310429850.2382.26.camel@karl> <4E1F89EF.9090106@gont.com.ar> <4E1FA08A.8020503@gont.com.ar> Message-ID: <3B3053F2-DFFF-4AD4-920A-A28657622A5A@puck.nether.net> On Jul 14, 2011, at 10:06 PM, Fernando Gont wrote: >> It should be possible to mitigate this, so long as the attack does not actually >> originate from a neighbor on the same subnet as a router IP interface on >> an IPv6 subnet with sufficient number of IPs. > > Well, unless there's some layer-2 anti-spoofing mitigation in place, > with /64 subnets the "local attacker" typically *will* have enough > addresses. Solving a local attack is something I consider different in scope than the current draft being discussed in 6man, v6ops, ipv6@ etc... Anyone on a layer-2 network can do something interesting like flood all f's and kill the lan. Trying to keep the majority of thoughts here for layer-3 originated attacks, even if the target is a layer2 item. - Jared From owen at delong.com Thu Jul 14 21:37:16 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 14 Jul 2011 19:37:16 -0700 Subject: Enterprise Internet - Question In-Reply-To: References: <6EDE133FF50DBA4B963028BD5CD690DD26971B@CAPRGWLKWEMBX1.pernod-ricard.group> Message-ID: <921F8179-AD39-42F8-8DCC-1B992218D46B@delong.com> On Jul 14, 2011, at 7:00 PM, Jimmy Hess wrote: > On Thu, Jul 14, 2011 at 2:34 PM, Jeff Cartier > wrote: >> - How should/can an enterprise deal with accessibility to internet content issues? (ie. that whole coming from a Canadian IP accessing US content) > You indeed might feed traffic towards such "IP restricted" sites > through a transparent proxy server, > or policy NAT based on destination IP, reducing all traffic towards > those sites from "canadian" > ranges, to a pool of source IP addresses. > > Just to take a jab at absurd "content restriction" by IP methods, a reminder... > There's no such thing as a "US" IP address. There's no such thing as > a Canadian IP address. > > There are IPs delegated to network operators who have an AS in certain > countries, > but that is no proof of country of origin. > > What "country" is an IP address located in when it is assigned to a > terminal server, VPN server, > or proxy server in country $X, and there are authorized users that connect > from 16 different countries? > > -- > -JH Yep.... And let us also not forget that people travel. Imagine my surprise when I tried to log into Wells Fargo from Kigali and got the message that "You have authenticated successfully, but, we don't trust your current location. Everything will be fine when you log in from home." Of course, I did the seemingly obvious thing and logged in from home. Yeah, not so much. That got my account completely locked out and took a 2.5 hour phone call (well, series of phone calls, maintaining a VOIP connection from Kigali for that long wasn't happening) where I had to escalate up three levels of support representative before reaching someone who could understand what VNC was and that it was indeed possible for me to control my computer in the US from my laptop in Kigali and that I had indeed legitimately logged in from both locations about 2 minutes apart. To the best of my knowledge, while this person reset my account so that I could log in (from my house), I don't think Wells Fargo has any intention of rethinking their geo-IP based restrictions on logging in. So, if you travel, consider carefully whether to try and log into something directly vs. doing so over VNC. Owen From fernando at gont.com.ar Thu Jul 14 21:57:24 2011 From: fernando at gont.com.ar (Fernando Gont) Date: Thu, 14 Jul 2011 23:57:24 -0300 Subject: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)) In-Reply-To: <3B3053F2-DFFF-4AD4-920A-A28657622A5A@puck.nether.net> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <1310429850.2382.26.camel@karl> <4E1F89EF.9090106@gont.com.ar> <4E1FA08A.8020503@gont.com.ar> <3B3053F2-DFFF-4AD4-920A-A28657622A5A@puck.nether.net> Message-ID: <4E1FAC94.8030209@gont.com.ar> On 07/14/2011 11:35 PM, Jared Mauch wrote: >> Well, unless there's some layer-2 anti-spoofing mitigation in >> place, with /64 subnets the "local attacker" typically *will* have >> enough addresses. > > Solving a local attack Well, I was talking about not *introducing* ;-) one. > is something I consider different in scope > than the current draft being discussed in 6man, v6ops, ipv6@ etc... Which I-D are you referring to? Thanks, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From jared at puck.nether.net Thu Jul 14 22:12:15 2011 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 14 Jul 2011 23:12:15 -0400 Subject: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)) In-Reply-To: <4E1FAC94.8030209@gont.com.ar> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <1310429850.2382.26.camel@karl> <4E1F89EF.9090106@gont.com.ar> <4E1FA08A.8020503@gont.com.ar> <3B3053F2-DFFF-4AD4-920A-A28657622A5A@puck.nether.net> <4E1FAC94.8030209@gont.com.ar> Message-ID: <713C394B-5F0E-421C-96DC-04D4362B75FE@puck.nether.net> http://tools.ietf.org/html/draft-gashinsky-v6nd-enhance-00 Sent from my iThing On Jul 14, 2011, at 10:57 PM, Fernando Gont wrote: > On 07/14/2011 11:35 PM, Jared Mauch wrote: > >>> Well, unless there's some layer-2 anti-spoofing mitigation in >>> place, with /64 subnets the "local attacker" typically *will* have >>> enough addresses. >> >> Solving a local attack > > Well, I was talking about not *introducing* ;-) one. > > >> is something I consider different in scope >> than the current draft being discussed in 6man, v6ops, ipv6@ etc... > > Which I-D are you referring to? > > Thanks, > -- > Fernando Gont > e-mail: fernando at gont.com.ar || fgont at acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > From mysidia at gmail.com Thu Jul 14 22:24:08 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 14 Jul 2011 22:24:08 -0500 Subject: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)) In-Reply-To: <3B3053F2-DFFF-4AD4-920A-A28657622A5A@puck.nether.net> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <1310429850.2382.26.camel@karl> <4E1F89EF.9090106@gont.com.ar> <4E1FA08A.8020503@gont.com.ar> <3B3053F2-DFFF-4AD4-920A-A28657622A5A@puck.nether.net> Message-ID: On Thu, Jul 14, 2011 at 9:35 PM, Jared Mauch wrote: > On Jul 14, 2011, at 10:06 PM, Fernando Gont wrote: > Anyone on a layer-2 network can do something interesting like flood all f's and kill the lan. Trying to keep the majority of thoughts here for layer-3 originated attacks, even if the target is a layer2 item. > - Jared In most cases if you have a DoS attack coming from the same Layer-2 network that a router is attached to, it would mean there was already a serious security incident that occured to give the attacker that special point to attack from. A similarly hazardous situation exists with IPv4, and it is basically unheard of for IPv4's Layer 2/ARP security weaknesses to be exploited to create a DoS condition, even though they can be (very easily), IPv4 Layer 2 DoS conditions are often due to a malfunction or error than intended attack; more likely, IPv6 Layer 2 security weaknesses will be used to intercept traffic for snooping, or quietly subvert network policy. LAN DoS conditions are noticed quickly, and usually result in physical unplugging of the attacking (or malfunctioning) node. Methods can be designed to protect against spoofed NDP flooding on the LAN that do not require the router's involvement. For IPv4 switched networks there is a technology referred to as 'Dynamic ARP Inspection'. Untrusted IPv6 LAN environments will need to implement SEND or some form of 'Dynamic ND inspection' plus RA-guard. If it comes down to solving a remote DoS issue at the cost of creating a LAN DoS issue that comes down to 'hosts on the LAN having to spoof' I would say that's easily well worth it. -- -JH From daniel.crompton at gmail.com Thu Jul 14 22:24:43 2011 From: daniel.crompton at gmail.com (=?ISO-8859-1?Q?Dani=EBl_W=2E_Crompton?=) Date: Fri, 15 Jul 2011 05:24:43 +0200 Subject: OT: Given what you know now, if you were 21 again... In-Reply-To: References: Message-ID: Hi Larry, I would learn 2 things: * having fun learning * time management It's been almost 14 years since I was 21 and I concur with many of the things mentioned in this thread, and learned a few of them. However it wasn't all the time I spend studying and learning, it's all the time I spend being bored with studying that could have been easily solved with a little patience and guidance on how to have fun learning. It wasn't until I discovered the methods which were most effective for learning a certain subject and keeping it fun. Time management is another thing I would have wanted to start asap. So I could have scheduled the procrastination and use the best parts of the day to work or learn effectively. my 2c D. On 13/07/2011, Larry Stites wrote: > Given what you know now, if you were 21 and just starting into networking / > communications industry which areas of study or specialty would you > prioritize? > > > Thanks > > > > Larry Stites > NCNetworks, Inc. > Nevada City, CA 95959 > > > > -- blaze your trail -- Dani?l W. Crompton http://specialbrands.net/ From fernando at gont.com.ar Thu Jul 14 23:13:49 2011 From: fernando at gont.com.ar (Fernando Gont) Date: Fri, 15 Jul 2011 01:13:49 -0300 Subject: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <1310429850.2382.26.camel@karl> <4E1F89EF.9090106@gont.com.ar> <4E1FA08A.8020503@gont.com.ar> <3B3053F2-DFFF-4AD4-920A-A28657622A5A@puck.nether.net> Message-ID: <4E1FBE7D.8000006@gont.com.ar> On 07/15/2011 12:24 AM, Jimmy Hess wrote: > A similarly hazardous situation exists with IPv4, and it is basically > unheard of for IPv4's Layer 2/ARP security weaknesses to be exploited > to create a DoS condition, even though they can be (very easily), IMO, the situation is different, in that the typical IPv4 subnet size eliminate some of the attack vectors. For example, it would be virtually impossible for an ARP cache to grow without bounds, and consume all kernel memory, because the typical IPv4 subnet size imposes a limit on the number of entries. That is *not* the case with v6. > IPv4 Layer 2 DoS conditions are often due to a malfunction or error > than intended attack; more likely, IPv6 Layer 2 security > weaknesses will be used to intercept traffic for snooping, or quietly > subvert network policy. LAN DoS conditions are noticed quickly, and > usually result in physical unplugging of the attacking (or > malfunctioning) node. Assuming the admin of the possibly-ipv6-enabled-by-default router is IPv6 aware, etc. > Methods can be designed to protect against spoofed NDP flooding on the > LAN that do not require the router's involvement. Which ones? > For IPv4 switched networks there is a technology referred to as > 'Dynamic ARP Inspection'. > > Untrusted IPv6 LAN environments will need to implement SEND or some > form of 'Dynamic ND inspection' plus RA-guard. Good luck with deploying SEND. OTOH, forget about current implementations of RA-Guard: * http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-01.txt * http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-01.txt > If it comes down to solving a remote DoS issue at the cost of > creating a LAN DoS issue that comes down to 'hosts on the LAN having > to spoof' > > I would say that's easily well worth it. You *can* fix the remote DoS issue, *without* introducing the locally-exploitable one. That's the point. Thanks, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From jmaslak at antelope.net Thu Jul 14 23:34:26 2011 From: jmaslak at antelope.net (Joel Maslak) Date: Thu, 14 Jul 2011 22:34:26 -0600 Subject: OT: Given what you know now, if you were 21 again... In-Reply-To: References: Message-ID: On Wed, Jul 13, 2011 at 3:08 PM, Larry Stites wrote: > Given what you know now, if you were 21 and just starting into networking / > communications industry which areas of study or specialty would you > prioritize? > Make sure you are always learning. You can't stop learning in this industry. Study the academic side of computers, not just how to use specific systems. Know that systems other than the all-or-nothing superuser-based security model exist, what a functional programming language is, basic computational complexity, etc. Unix or Cisco aren't always the best choices, but if you don't know about the others you won't know that (FWIW, Cisco and Unix are often excellent choices). Learn to program reasonably well in at least a script language. Learn TCP/IP. It's going to be around for a while. Focus on IPv4, but expose yourself to IPv6. This is probably the only specific protocol/technology I'll mention. Don't limit yourself to layer 3. Learn about things like how to terminate fiber optic cables and how application acceleration works. Make sure you can write and speak well. Learn when to shut up. (I probably still haven't learned that one) Learn how to get along with people, even ones that aren't as brilliant as yourself. Learn how to appropriately show accomplishment. You don't want to be arrogant, but you also don't want to be laid off because nobody knew that you did great things. Learn that people almost always have a reason for doing things the wrong way, and it's best to find out what it is before you fix it! This is probably controversial...Don't specialize religiously. What I mean about this is "don't become a Cisco guy." Sure, you might become a Cisco expert, and that's fine. But don't lock yourself to a vendor or system type. Don't turn down a dream job that uses a different kind of router, server, workstation, etc, just because you like Cisco (or whoever) better. You won't want to use today's technology in a few years anyhow, so why make long-term decisions based on hardware/software used today? In the computer field, even giants have fallen. Learn that there is always someone smarter than you out there. Learn from them. You have to start somewhere. If you don't have good experience, you aren't going to start at a (insert nice salary here) senior position, no matter how much you know or what degree you have. You might have to start on the night shift of a NOC, making barely enough to eat, doing basic tasks. Even in a position like that, you can show you can learn - don't waste time while working in these jobs, spend your free time learning, not playing computer games or watching TV. You'll get noticed. Don't do illegal stuff. It'll limit your options. Pay your bills, don't do drugs, don't get picked up for drunk driving, don't beat your significant other. These are the things that disqualify people with even basic background checks - and many, many senior network jobs require a background check. Take opportunities. Consider jobs where you'll have to learn a bit to be effective - you might be the best person that applied. But don't expect to get jobs you aren't qualified for, and be honest about your abilities (but confident). Right now is a difficult time to get a job, even if you have terrific qualifications. From lists at beatmixed.com Fri Jul 15 00:23:37 2011 From: lists at beatmixed.com (Matt Hite) Date: Thu, 14 Jul 2011 22:23:37 -0700 Subject: BGP Design question. In-Reply-To: <4E027CB1.9070007@gmail.com> References: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> <4E027CB1.9070007@gmail.com> Message-ID: Sure. Sometimes it's nice/convenient to let firewalls advertise the external blocks they use for NAT translations, etc. Otherwise you need to statically route them to the firewall and redistribute the statics from said routers into your IGP. Also, in some cases, people want to do network-based load balancing (ECMP) to clusters of firewalls. So routing protocols obviously come in handy with that. Additionally, some people just want to avoid layer 2 clustering/HA technologies whenever possible and prefer layer 3 HA solutions. -M On Wed, Jun 22, 2011 at 4:37 PM, -Hammer- wrote: > Do people really run routing protocols with their public address space on > their FWs? I'm not saying right or wrong. Just curious. Seems like the last > thing I would want to do would be to have my FW participate in a routing > protocol unless is was absolutely necessary. Better to static the FW with a > default route? I'd love to hear arguments for or against.... > > -Hammer- > > > > On 06/22/2011 06:33 PM, PC wrote: >> >> Who makes the firewall? >> >> To make this work and be "hitless", your firewall vendor must support >> stateful replication of routing protocol data (including OSPF). ?For >> example, Cisco didn't support this in their ASA product until version 8.4 >> of >> code. >> >> Otherwise, a failover requires OSPF to re-converge -- and quite frankly, >> will likely cause some state of confusion on the upstream OSPF peers, loss >> of adjacency, and a loss of routing until this occurs. ?It's like someone >> just swapped a router with the same IP ?to the upstream device -- assuming >> your active/standby vendor's implementation only presents itself as one >> device. >> >> However, once this is succesful your current failover topology should work >> fine -- even if it takes some time to failover. >> >> In my opinion though, unless the firewall is serving as "transit" to >> downstream routers or other layer 3 elements, and you need to run OSPF to >> it >> (And through it) as a result, it's often just easier to static default >> route >> out from the firewall(s) and redistribute a static route on the upstream >> routers for the subnets behind the firewalls. ?It also helps ensure >> symmetrical traffic flows, which is important for stateful firewalls and >> can >> become moderatly confusing when your firewalls start having many >> interfaces. >> >> >> >> >> On Wed, Jun 22, 2011 at 4:27 PM, Bret Palsson ?wrote: >> >> >>> >>> Here is my current setup in ASCII art. (Please view in a fixed width >>> font.) >>> Below the art I'll write out the setup. >>> >>> >>> ? ? +--------+ ? ?+--------+ >>> ? ? | Peer A | ? ?| Peer A |<-Many carriers. Using 1 carrier >>> ? ? +---+----+ ? ?+----+---+ ? ?for this scenario. >>> ? ? ? ? |eBGP ? ? ? ? ?| eBGP >>> ? ? ? ? | ? ? ? ? ? ? ?| >>> ? ? +---+----+iBGP+----+---+ >>> ? ? | Router +----+ Router |<-Netiron CERs Routers. >>> ? ? +-+------+ ? ?+------+-+ >>> ? ? ? |A ? `.P ? ?A.' ? ?|P<-A/P indicates Active/Passive >>> ? ? ? | ? ? ?`. ?.' ? ? ?| ? ? ?link. >>> ? ? ? | ? ? ? ?:: ? ? ? ?| >>> ? ? +-+------+' ?`+------+-+ >>> ? ? |Act. FW | ? ?|Pas. FW |<-Firewalls Active/Passive. >>> ? ? +--------+ ? ?+--------+ >>> >>> >>> To keep this scenario simple, I'm multihoming to one carrier. >>> I have two Netiron CERs. Each have a eBGP connection to the same peer. >>> The CERs have an iBGP connection to each other. >>> That works all fine and dandy. Feel free to comment, however if you think >>> there is a better way to do this. >>> >>> Here comes the tricky part. I have two firewalls in an Active/Passive >>> setup. When one fails the other is configured exactly the same >>> and picks up where the other left off. (Yes, all the sessions etc. are >>> actively mirrored between the devices) >>> >>> I am using OSPFv2 between the CERs and the Firewalls. Failover works just >>> fine, however when I fail an OSPF link that has the active default route, >>> ingress traffic still routes fine and dandy, but egress traffic doesn't. >>> Both Netiron's OSPF are setup to advertise they are the default route. >>> >>> What I'm wondering is, if OSPF is the right solution for this. How do >>> others solve this problem? >>> >>> >>> Thanks, >>> >>> Bret >>> >>> >>> Note: Since lately ipv6 has been a hot topic, I'll state that after we >>> get >>> the BGP all figured out and working properly, ipv6 is our next project. >>> :) >>> >>> >>> >>> > From cody at killsudo.info Fri Jul 15 00:31:30 2011 From: cody at killsudo.info (Cody Rose) Date: Fri, 15 Jul 2011 00:31:30 -0500 Subject: Google DNS just disappeared Message-ID: <201107150031.35547.cody@killsudo.info> Is anyone else seeing that Googles DNS records just disappeared? I just lost all connectivity to Google services including google.com, plus.google.com, Public dns, etc. Regards, Cody Rose NOC & Sys Admin Website: www.killsudo.info email: cody at killsudo.info ------------------------------- $ dig A google.com ; <<>> DiG 9.8.0-P4-RedHat-9.8.0-7.P4.fc15 <<>> A google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 14667 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;google.com. IN A ;; Query time: 4951 msec ;; SERVER: 10.168.88.7#53(10.168.88.7) ;; WHEN: Fri Jul 15 00:24:49 2011 ;; MSG SIZE rcvd: 28 ------------------------------- $ dig AAAA killsudo.info @8.8.8.8 ; <<>> DiG 9.8.0-P4-RedHat-9.8.0-7.P4.fc15 <<>> AAAA killsudo.info @8.8.8.8 ;; global options: +cmd ;; connection timed out; no servers could be reached $ dig AAAA killsudo.info @208.67.222.222 ------------------------------- ; <<>> DiG 9.8.0-P4-RedHat-9.8.0-7.P4.fc15 <<>> AAAA killsudo.info @208.67.222.222 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29448 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;killsudo.info. IN AAAA ;; ANSWER SECTION: killsudo.info. 600 IN AAAA 2001:470:1f10:aa4::2 ;; Query time: 63 msec ;; SERVER: 208.67.222.222#53(208.67.222.222) ;; WHEN: Fri Jul 15 00:29:55 2011 ;; MSG SIZE rcvd: 59 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: This is a digitally signed message part. URL: From cody at killsudo.info Fri Jul 15 00:36:34 2011 From: cody at killsudo.info (Cody Rose) Date: Fri, 15 Jul 2011 00:36:34 -0500 Subject: Google DNS just disappeared In-Reply-To: <201107150031.35547.cody@killsudo.info> References: <201107150031.35547.cody@killsudo.info> Message-ID: <201107150036.34490.cody@killsudo.info> Service just returned, DNS is active and connectivity directly to IPs are working again. Guess it was just a blip. Regards, Cody Rose NOC & Sys Admin Website: www.killsudo.info email: cody at killsudo.info -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: This is a digitally signed message part. URL: From patrick at ianai.net Fri Jul 15 00:38:00 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 15 Jul 2011 01:38:00 -0400 Subject: Google DNS just disappeared In-Reply-To: <201107150031.35547.cody@killsudo.info> References: <201107150031.35547.cody@killsudo.info> Message-ID: <9ADE5594-4DB2-4463-9347-7CAD9F053A86@ianai.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 15, 2011, at 1:31 AM, Cody Rose wrote: > Is anyone else seeing that Googles DNS records just disappeared? > > I just lost all connectivity to Google services including google.com, > plus.google.com, Public dns, etc. Weird, works fine from here (near Boston, MA, USA). Tried from London & Tokyo, all three different ASNs. Works fine everywhere I tried. - -- TTFN, patrick TiggerBook-Air3:~ patrick$ dig www.google.com @8.8.8.8 ; <<>> DiG 9.6.0-APPLE-P2 <<>> www.google.com @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52148 ;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 86341 IN CNAME www.l.google.com. www.l.google.com. 241 IN A 74.125.93.104 www.l.google.com. 241 IN A 74.125.93.99 www.l.google.com. 241 IN A 74.125.93.106 www.l.google.com. 241 IN A 74.125.93.105 www.l.google.com. 241 IN A 74.125.93.147 www.l.google.com. 241 IN A 74.125.93.103 ;; Query time: 50 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Fri Jul 15 01:35:15 2011 ;; MSG SIZE rcvd: 148 > ------------------------------- > $ dig A google.com > > ; <<>> DiG 9.8.0-P4-RedHat-9.8.0-7.P4.fc15 <<>> A google.com > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 14667 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;google.com. IN A > > ;; Query time: 4951 msec > ;; SERVER: 10.168.88.7#53(10.168.88.7) > ;; WHEN: Fri Jul 15 00:24:49 2011 > ;; MSG SIZE rcvd: 28 > ------------------------------- > $ dig AAAA killsudo.info @8.8.8.8 > > ; <<>> DiG 9.8.0-P4-RedHat-9.8.0-7.P4.fc15 <<>> AAAA killsudo.info @8.8.8.8 > ;; global options: +cmd > ;; connection timed out; no servers could be reached > > $ dig AAAA killsudo.info @208.67.222.222 > ------------------------------- > ; <<>> DiG 9.8.0-P4-RedHat-9.8.0-7.P4.fc15 <<>> AAAA killsudo.info > @208.67.222.222 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29448 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;killsudo.info. IN AAAA > > ;; ANSWER SECTION: > killsudo.info. 600 IN AAAA 2001:470:1f10:aa4::2 > > ;; Query time: 63 msec > ;; SERVER: 208.67.222.222#53(208.67.222.222) > ;; WHEN: Fri Jul 15 00:29:55 2011 > ;; MSG SIZE rcvd: 59 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAk4f0jgACgkQznMLL4aoth8rkwCgtlE2haybIdLS1Xdaq9lQa7ir tFgAnjmwGYt57pYAVDh9Yr+1PPq/XEzX =rMVR -----END PGP SIGNATURE----- From cody at killsudo.info Fri Jul 15 01:00:49 2011 From: cody at killsudo.info (Cody Rose) Date: Fri, 15 Jul 2011 01:00:49 -0500 Subject: Google DNS just disappeared In-Reply-To: <9ADE5594-4DB2-4463-9347-7CAD9F053A86@ianai.net> References: <201107150031.35547.cody@killsudo.info> <9ADE5594-4DB2-4463-9347-7CAD9F053A86@ianai.net> Message-ID: <201107150100.53944.cody@killsudo.info> It appeared to be very brief, I just happened to be in a Google Plus Hangout when the chat died then my Gtalk died followed by my Google homepage. By the time I got done checking DNS and was getting on a trace-route server my chat reconnected and service was back to normal. Just thought it was unusual to see all my Google services go offline at the same time. Regards, Cody Rose NOC & Sys Admin Website: www.killsudo.info email: cody at killsudo.info -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: This is a digitally signed message part. URL: From owen at delong.com Fri Jul 15 01:13:03 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 14 Jul 2011 23:13:03 -0700 Subject: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <1310429850.2382.26.camel@karl> <4E1F89EF.9090106@gont.com.ar> <4E1FA08A.8020503@gont.com.ar> <3B3053F2-DFFF-4AD4-920A-A28657622A5A@puck.nether.net> Message-ID: <81C4F91A-ED76-4810-BA15-1E60C7886956@delong.com> On Jul 14, 2011, at 8:24 PM, Jimmy Hess wrote: > On Thu, Jul 14, 2011 at 9:35 PM, Jared Mauch wrote: >> On Jul 14, 2011, at 10:06 PM, Fernando Gont wrote: >> Anyone on a layer-2 network can do something interesting like flood all f's and kill the lan. Trying to keep the majority of thoughts here for layer-3 originated attacks, even if the target is a layer2 item. >> - Jared > > In most cases if you have a DoS attack coming from the same Layer-2 > network that a router is attached to, > it would mean there was already a serious security incident that > occured to give the attacker that special point to attack from. > That's one possibility. The other likely possibility is that you are a University. Owen From Jeff.Cartier at pernod-ricard.com Fri Jul 15 07:29:10 2011 From: Jeff.Cartier at pernod-ricard.com (Jeff Cartier) Date: Fri, 15 Jul 2011 12:29:10 +0000 Subject: Enterprise Internet - Question In-Reply-To: <6325B189-76E0-4573-ADB8-72B122870412@delong.com> References: <6EDE133FF50DBA4B963028BD5CD690DD26971B@CAPRGWLKWEMBX1.pernod-ricard.group> <6325B189-76E0-4573-ADB8-72B122870412@delong.com> Message-ID: <6EDE133FF50DBA4B963028BD5CD690DD269F35@CAPRGWLKWEMBX1.pernod-ricard.group> Thanks for the comments everyone. They are much appreciated. In regards to changing the address of our ARIN block to a US office address....are their any trades-offs in doing that? Just curious. -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Thursday, July 14, 2011 5:02 PM To: Jeff Cartier Cc: nanog at nanog.org Subject: Re: Enterprise Internet - Question On Jul 14, 2011, at 12:34 PM, Jeff Cartier wrote: > Hi All, > > I just wanted to throw a question out to the list... > > In our data center we feed Internet to some of our US based offices and every now and again we receive complaints that they can't access some US based Internet content because they are coming from a Canadian based IP. > > This has sparked an interesting discussion around a few questions....of which I'd like to hear the lists opinions on. > > - How should/can an enterprise deal with accessibility to internet content issues? (ie. that whole coming from a Canadian IP accessing US content) > This is an example of why content restriction based on IP address geolocation is such a bad idea in general. Frankly, the easiest thing to do (since most Canadian companies aren't as brain-dead) is to update your whois records with the address of the block allocated to your datacenter so that it looks like it's in one of your US offices. I realize this sounds silly for a variety of reasons, but, it solves the problem without expensive or configuration-intensive workarounds such as selective NAT, etc. > o Side question on that - Could we simply obtain a US based IP address and selectively NAT? > You can, but, you can also hit yourself over the head repeatedly with a hammer. Selective NAT will yield more content, but, the pain levels will probably be similar. > - Does the idea of regional Internet locations make sense? If so, when do they make sense? For instance, having a hub site in South America (ie. Brazil) and having all offices in Venezuela, Peru and Argentina route through a local Internet feed in Brazil. > Not really. The whole content-restriction by IP geolocation thing also doesn't make sense. Unfortunately, the fact that something is nonsensical does not prevent someone from doing it or worse, selling it. You should do what makes sense for the economics of the topology you need. The address geolocation issues can usually be best addressed by manipulating whois. If your address block from ARIN is an allocation, you can manipulate sub-block address registration issues through the use of SWIP, for example. > - Does the idea of having local Internet at each site make more sense? If so why? > That's really more of an economic and policy question within your organization than a technical one. > Owen __________________________________________________________________ DISCLAIMER: This e-mail contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail. This message has been scanned for the presence of computer viruses, Spam, and Explicit Content. From paul4004 at gmail.com Fri Jul 15 08:51:19 2011 From: paul4004 at gmail.com (PC) Date: Fri, 15 Jul 2011 07:51:19 -0600 Subject: Enterprise Internet - Question In-Reply-To: <6EDE133FF50DBA4B963028BD5CD690DD269F35@CAPRGWLKWEMBX1.pernod-ricard.group> References: <6EDE133FF50DBA4B963028BD5CD690DD26971B@CAPRGWLKWEMBX1.pernod-ricard.group> <6325B189-76E0-4573-ADB8-72B122870412@delong.com> <6EDE133FF50DBA4B963028BD5CD690DD269F35@CAPRGWLKWEMBX1.pernod-ricard.group> Message-ID: Perhaps you have Canadian branches feeding off the same connection and they will have the reverse problem with geo-location? On Fri, Jul 15, 2011 at 6:29 AM, Jeff Cartier < Jeff.Cartier at pernod-ricard.com> wrote: > Thanks for the comments everyone. They are much appreciated. > In regards to changing the address of our ARIN block to a US office > address....are their any trades-offs in doing that? Just curious. > > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Thursday, July 14, 2011 5:02 PM > To: Jeff Cartier > Cc: nanog at nanog.org > Subject: Re: Enterprise Internet - Question > > > On Jul 14, 2011, at 12:34 PM, Jeff Cartier wrote: > > > Hi All, > > > > I just wanted to throw a question out to the list... > > > > In our data center we feed Internet to some of our US based offices and > every now and again we receive complaints that they can't access some US > based Internet content because they are coming from a Canadian based IP. > > > > This has sparked an interesting discussion around a few questions....of > which I'd like to hear the lists opinions on. > > > > - How should/can an enterprise deal with accessibility to > internet content issues? (ie. that whole coming from a Canadian IP accessing > US content) > > > > This is an example of why content restriction based on IP address > geolocation is such a bad idea in general. > > Frankly, the easiest thing to do (since most Canadian companies aren't as > brain-dead) is to update your whois records with the address of the block > allocated to your datacenter so that it looks like it's in one of your US > offices. I realize this sounds silly for a variety of reasons, but, it > solves the problem without expensive or configuration-intensive workarounds > such as selective NAT, etc. > > > o Side question on that - Could we simply obtain a US based IP address > and selectively NAT? > > > You can, but, you can also hit yourself over the head repeatedly with a > hammer. Selective NAT will yield more content, but, the pain levels will > probably be similar. > > > - Does the idea of regional Internet locations make sense? If > so, when do they make sense? For instance, having a hub site in South > America (ie. Brazil) and having all offices in Venezuela, Peru and Argentina > route through a local Internet feed in Brazil. > > > > Not really. The whole content-restriction by IP geolocation thing also > doesn't make sense. Unfortunately, the fact that something is nonsensical > does not prevent someone from doing it or worse, selling it. > > You should do what makes sense for the economics of the topology you need. > The address geolocation issues can usually be best addressed by manipulating > whois. If your address block from ARIN is an allocation, you can manipulate > sub-block address registration issues through the use of SWIP, for example. > > > - Does the idea of having local Internet at each site make more > sense? If so why? > > > > That's really more of an economic and policy question within your > organization than a technical one. > > > > Owen > > > > __________________________________________________________________ > DISCLAIMER: This e-mail contains proprietary information some or all of > which may be legally privileged. It is for the intended recipient only. If > an addressing or transmission error has misdirected this e-mail, please > notify the author by replying to this e-mail. If you are not the intended > recipient you must not use, disclose, distribute, copy, print, or rely on > this e-mail. > > This message has been scanned for the presence of computer viruses, Spam, > and Explicit Content. > > > From ryan.landry at gmail.com Fri Jul 15 10:24:45 2011 From: ryan.landry at gmail.com (ryanL) Date: Fri, 15 Jul 2011 09:24:45 -0600 Subject: London UK smart hands recommendations? Message-ID: i have a bunch of fully-loaded network gear (nexus 7k's, asr 9k's, etc) that needs to be pulled out of racks, moved across a data centre floor, and re-racked. looking for success stories and recommendations for licensed, bonded, insured companies in London that can do it quickly and cost-effectively. so far i've come across technimove. thanks. .ryanL From mark at exonetric.com Fri Jul 15 10:30:11 2011 From: mark at exonetric.com (Mark Blackman) Date: Fri, 15 Jul 2011 16:30:11 +0100 Subject: London UK smart hands recommendations? In-Reply-To: References: Message-ID: On 15 Jul 2011, at 16:24, ryanL wrote: > i have a bunch of fully-loaded network gear (nexus 7k's, asr 9k's, > etc) that needs to be pulled out of racks, moved across a data centre > floor, and re-racked. looking for success stories and recommendations > for licensed, bonded, insured companies in London that can do it > quickly and cost-effectively. In the unlikely event no one else suggests them, I'll point you at NetSumo, http://www.netsumo.com/ - Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4757 bytes Desc: not available URL: From tom at ninjabadger.net Fri Jul 15 10:54:57 2011 From: tom at ninjabadger.net (Tom Hill) Date: Fri, 15 Jul 2011 16:54:57 +0100 Subject: London UK smart hands recommendations? In-Reply-To: References: Message-ID: <1310745299.2646.35.camel@teh-desktop> On Fri, 2011-07-15 at 16:30 +0100, Mark Blackman wrote: > In the unlikely event no one else suggests them, I'll point you at > NetSumo, http://www.netsumo.com/ +1, lots of clue available at Netsumo. From Valdis.Kletnieks at vt.edu Fri Jul 15 11:15:39 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 15 Jul 2011 12:15:39 -0400 Subject: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)) In-Reply-To: Your message of "Thu, 14 Jul 2011 23:13:03 PDT." <81C4F91A-ED76-4810-BA15-1E60C7886956@delong.com> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <1310429850.2382.26.camel@karl> <4E1F89EF.9090106@gont.com.ar> <4E1FA08A.8020503@gont.com.ar> <3B3053F2-DFFF-4AD4-920A-A28657622A5A@puck.nether.net> <81C4F91A-ED76-4810-BA15-1E60C7886956@delong.com> Message-ID: <34921.1310746539@turing-police.cc.vt.edu> On Thu, 14 Jul 2011 23:13:03 PDT, Owen DeLong said: > On Jul 14, 2011, at 8:24 PM, Jimmy Hess wrote: > > In most cases if you have a DoS attack coming from the same Layer-2 > > network that a router is attached to, > > it would mean there was already a serious security incident that > > occured to give the attacker that special point to attack from. > That's one possibility. > > The other likely possibility is that you are a University. Nope. Unless you want to add "or you are a cable provider, or you are a DSL provider, or you are a...." to that. (Hint - what percent of students launch DoS attacks that cut themselves off from the net? Compare to what percent of non-student machines out on cable and DSL are botted or pwned) Even if you're a university with resident students, if said students are on the same Layer-2 as anything you actually care about, you have a serious security incident. "Student manages to DoS the router out of the dorm and strands 3 floors of dorm without internet" is just as interesting as "Joe Sixpack manages to DoS the router at the cable head end and strands 3 blocks of Comcast customers without internet", for the *exact same reasons*. If the student is able to play more level-2 games than Joe Sixpack can, you misdesigned your network. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From linkconnect at googlemail.com Fri Jul 15 11:32:47 2011 From: linkconnect at googlemail.com (Wayne Lee) Date: Fri, 15 Jul 2011 17:32:47 +0100 Subject: London UK smart hands recommendations? In-Reply-To: <1310745299.2646.35.camel@teh-desktop> References: <1310745299.2646.35.camel@teh-desktop> Message-ID: > On Fri, 2011-07-15 at 16:30 +0100, Mark Blackman wrote: >> In the unlikely event no one else suggests them, I'll point you at >> NetSumo, http://www.netsumo.com/ > > +1, lots of clue available at Netsumo. +2 for Netsumo Wayne From morrowc.lists at gmail.com Fri Jul 15 12:35:24 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 15 Jul 2011 13:35:24 -0400 Subject: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <1310429850.2382.26.camel@karl> <4E1F89EF.9090106@gont.com.ar> Message-ID: On Thu, Jul 14, 2011 at 9:47 PM, Owen DeLong wrote: > > Very true. This is where Mr. Wheeler's arguments depart from reality. He's right > in that the problem can't be truly fixed without some very complicated code added > to lots of devices, but, it can be mitigated relatively easily and mitigation really > is good enough for most real world purposes. ok,I'll bite, what's the solution? From cscora at apnic.net Fri Jul 15 14:06:43 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 16 Jul 2011 05:06:43 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201107151906.p6FJ6h2G016167@thyme.rand.apnic.net> 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, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 16 Jul, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 363652 Prefixes after maximum aggregation: 165367 Deaggregation factor: 2.20 Unique aggregates announced to Internet: 180640 Total ASes present in the Internet Routing Table: 38198 Prefixes per ASN: 9.52 Origin-only ASes present in the Internet Routing Table: 31741 Origin ASes announcing only one prefix: 15260 Transit ASes present in the Internet Routing Table: 5195 Transit-only ASes present in the Internet Routing Table: 132 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 33 Max AS path prepend of ASN (22394) 27 Prefixes from unregistered ASNs in the Routing Table: 917 Unregistered ASNs in the Routing Table: 532 Number of 32-bit ASNs allocated by the RIRs: 1559 Number of 32-bit ASNs visible in the Routing Table: 1262 Prefixes from 32-bit ASNs in the Routing Table: 2910 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 122 Number of addresses announced to Internet: 2477764128 Equivalent to 147 /8s, 175 /16s and 174 /24s Percentage of available address space announced: 66.8 Percentage of allocated address space announced: 66.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 91.1 Total number of prefixes smaller than registry allocations: 151592 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 90715 Total APNIC prefixes after maximum aggregation: 30300 APNIC Deaggregation factor: 2.99 Prefixes being announced from the APNIC address blocks: 87321 Unique aggregates announced from the APNIC address blocks: 37425 APNIC Region origin ASes present in the Internet Routing Table: 4519 APNIC Prefixes per ASN: 19.32 APNIC Region origin ASes announcing only one prefix: 1253 APNIC Region transit ASes present in the Internet Routing Table: 716 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 18 Number of APNIC region 32-bit ASNs visible in the Routing Table: 61 Number of APNIC addresses announced to Internet: 622188352 Equivalent to 37 /8s, 21 /16s and 215 /24s Percentage of available APNIC address space announced: 78.9 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 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, 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: 141554 Total ARIN prefixes after maximum aggregation: 73093 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 113475 Unique aggregates announced from the ARIN address blocks: 46690 ARIN Region origin ASes present in the Internet Routing Table: 14485 ARIN Prefixes per ASN: 7.83 ARIN Region origin ASes announcing only one prefix: 5538 ARIN Region transit ASes present in the Internet Routing Table: 1526 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 30 Number of ARIN region 32-bit ASNs visible in the Routing Table: 13 Number of ARIN addresses announced to Internet: 802399872 Equivalent to 47 /8s, 211 /16s and 166 /24s Percentage of available ARIN address space announced: 63.8 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, 393216-394239 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, 173/8, 174/8, 184/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: 86584 Total RIPE prefixes after maximum aggregation: 49219 RIPE Deaggregation factor: 1.76 Prefixes being announced from the RIPE address blocks: 79927 Unique aggregates announced from the RIPE address blocks: 52892 RIPE Region origin ASes present in the Internet Routing Table: 15802 RIPE Prefixes per ASN: 5.06 RIPE Region origin ASes announcing only one prefix: 7878 RIPE Region transit ASes present in the Internet Routing Table: 2504 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 919 Number of RIPE addresses announced to Internet: 479486528 Equivalent to 28 /8s, 148 /16s and 98 /24s Percentage of available RIPE address space announced: 77.2 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 196608-198655 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, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 33534 Total LACNIC prefixes after maximum aggregation: 7585 LACNIC Deaggregation factor: 4.42 Prefixes being announced from the LACNIC address blocks: 32747 Unique aggregates announced from the LACNIC address blocks: 17050 LACNIC Region origin ASes present in the Internet Routing Table: 1481 LACNIC Prefixes per ASN: 22.11 LACNIC Region origin ASes announcing only one prefix: 445 LACNIC Region transit ASes present in the Internet Routing Table: 273 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 19 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 265 Number of LACNIC addresses announced to Internet: 86070528 Equivalent to 5 /8s, 33 /16s and 85 /24s Percentage of available LACNIC address space announced: 57.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 8177 Total AfriNIC prefixes after maximum aggregation: 1965 AfriNIC Deaggregation factor: 4.16 Prefixes being announced from the AfriNIC address blocks: 6491 Unique aggregates announced from the AfriNIC address blocks: 1992 AfriNIC Region origin ASes present in the Internet Routing Table: 468 AfriNIC Prefixes per ASN: 13.87 AfriNIC Region origin ASes announcing only one prefix: 146 AfriNIC Region transit ASes present in the Internet Routing Table: 103 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: 4 Number of AfriNIC addresses announced to Internet: 24338944 Equivalent to 1 /8s, 115 /16s and 98 /24s Percentage of available AfriNIC address space announced: 36.3 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2469 11044 937 Korea Telecom (KIX) 7545 1554 301 85 TPG Internet Pty Ltd 17974 1543 456 45 PT TELEKOMUNIKASI INDONESIA 4755 1505 635 170 TATA Communications formerly 7552 1283 1064 7 Vietel Corporation 24560 1155 336 187 Bharti Airtel Ltd., Telemedia 9829 1106 923 47 BSNL National Internet Backbo 9583 1064 78 504 Sify Limited 4808 1047 2092 299 CNCGROUP IP network: China169 17488 966 187 106 Hathway IP Over Cable Interne 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 6389 3599 3818 241 bellsouth.net, inc. 18566 1913 365 241 Covad Communications 1785 1805 681 121 PaeTec Communications, Inc. 4323 1657 1082 400 Time Warner Telecom 20115 1594 1534 627 Charter Communications 19262 1410 4744 390 Verizon Global Networks 7018 1365 7069 892 AT&T WorldNet Services 22773 1351 2897 88 Cox Communications, Inc. 7029 1291 791 305 Windstream Communications Inc 2386 1260 520 907 AT&T Data Communications Serv 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 34984 535 106 184 BILISIM TELEKOM 6830 510 1780 315 UPC Distribution Services 3292 468 2078 403 TDC Tele Danmark 12479 458 593 7 Uni2 Autonomous System 20940 458 131 354 Akamai Technologies European 8866 449 133 25 Bulgarian Telecommunication C 29049 432 32 47 AzerSat LLC. 3320 423 8151 369 Deutsche Telekom AG 8551 404 354 44 Bezeq International 702 399 1803 312 UUNET - Commercial IP service 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 1549 284 162 TVCABLE BOGOTA 8151 1437 2746 353 UniNet S.A. de C.V. 28573 1277 995 77 NET Servicos de Comunicao S.A 7303 986 511 165 Telecom Argentina Stet-France 6503 749 354 74 AVANTEL, S.A. 14420 690 55 84 CORPORACION NACIONAL DE TELEC 22047 578 322 17 VTR PUNTO NET S.A. 3816 533 230 97 Empresa Nacional de Telecomun 7738 516 986 31 Telecomunicacoes da Bahia S.A 27947 508 53 53 Telconet S.A 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 795 147 36 LINKdotNET AS number 8452 780 445 11 TEDATA 15475 513 74 8 Nile Online 36992 315 415 14 Etisalat MISR 3741 261 937 223 The Internet Solution 6713 241 215 13 Itissalat Al-MAGHRIB 33776 227 13 5 Starcomms Nigeria Limited 24835 175 78 10 RAYA Telecom - Egypt 29571 158 17 11 Ci Telecom Autonomous system 16637 148 441 86 MTN Network Solutions 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 6389 3599 3818 241 bellsouth.net, inc. 23456 2910 707 1559 32-bit ASN transition 4766 2469 11044 937 Korea Telecom (KIX) 18566 1913 365 241 Covad Communications 1785 1805 681 121 PaeTec Communications, Inc. 4323 1657 1082 400 Time Warner Telecom 20115 1594 1534 627 Charter Communications 7545 1554 301 85 TPG Internet Pty Ltd 10620 1549 284 162 TVCABLE BOGOTA 17974 1543 456 45 PT TELEKOMUNIKASI INDONESIA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 1785 1805 1684 PaeTec Communications, Inc. 18566 1913 1672 Covad Communications 4766 2469 1532 Korea Telecom (KIX) 17974 1543 1498 PT TELEKOMUNIKASI INDONESIA 7545 1554 1469 TPG Internet Pty Ltd 10620 1549 1387 TVCABLE BOGOTA 23456 2910 1351 32-bit ASN transition 4755 1505 1335 TATA Communications formerly 7552 1283 1276 Vietel Corporation 22773 1351 1263 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.225.128.0/18 36377 Comcast Telecommunications, I 24.225.192.0/23 36377 Comcast Telecommunications, I 24.225.192.0/18 36377 Comcast Telecommunications, I 24.225.224.0/21 36377 Comcast Telecommunications, I 24.225.237.0/24 36377 Comcast Telecommunications, I 24.225.248.0/21 36377 Comcast Telecommunications, I 41.223.92.0/22 36936 >>UNKNOWN<< 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.21.192.0/20 11610 Internet Nebraska Corporation 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:20 /9:12 /10:26 /11:80 /12:232 /13:464 /14:795 /15:1396 /16:12005 /17:5876 /18:9821 /19:19496 /20:26056 /21:26209 /22:34865 /23:33683 /24:189377 /25:1057 /26:1247 /27:720 /28:198 /29:9 /30:2 /31:0 /32:6 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2216 3599 bellsouth.net, inc. 18566 1869 1913 Covad Communications 10620 1444 1549 TVCABLE BOGOTA 23456 1423 2910 32-bit ASN transition 11492 1097 1143 Cable One 7011 1056 1158 Citizens Utilities 6478 1055 1084 AT&T Worldnet Services 1785 1053 1805 PaeTec Communications, Inc. 7029 1038 1291 Windstream Communications Inc 22773 865 1351 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:328 2:44 4:16 5:1 6:3 8:338 12:1967 13:1 14:488 15:15 16:3 17:5 20:10 23:14 24:1679 27:824 31:502 32:64 33:4 34:2 36:4 38:745 40:104 41:2562 42:32 44:3 46:1037 47:3 49:201 50:471 52:13 54:2 55:4 56:2 57:35 58:863 59:479 60:386 61:1123 62:1033 63:1932 64:3954 65:2300 66:3889 67:1872 68:1103 69:3044 70:756 71:389 72:1888 74:2386 75:318 76:341 77:887 78:710 79:457 80:1116 81:840 82:499 83:454 84:691 85:1063 86:523 87:764 88:336 89:1534 90:224 91:3959 92:522 93:1050 94:1337 95:858 96:414 97:260 98:891 99:37 101:77 103:143 106:10 107:22 108:70 109:1022 110:607 111:712 112:305 113:406 114:552 115:686 116:978 117:689 118:832 119:1164 120:313 121:677 122:1608 123:979 124:1300 125:1277 128:245 129:171 130:169 131:575 132:111 133:21 134:213 135:48 136:216 137:137 138:297 139:116 140:482 141:244 142:403 143:416 144:483 145:55 146:452 147:211 148:680 149:248 150:160 151:189 152:342 153:182 154:4 155:397 156:198 157:323 158:138 159:454 160:311 161:202 162:309 163:164 164:499 165:366 166:529 167:433 168:734 169:153 170:847 171:78 172:1 173:1619 174:609 175:375 176:142 177:171 178:1005 180:898 181:23 182:492 183:231 184:344 185:1 186:1284 187:732 188:895 189:939 190:4979 192:5900 193:4975 194:3527 195:3029 196:1238 197:43 198:3581 199:3975 200:5561 201:1492 202:8416 203:8428 204:4235 205:2327 206:2668 207:2811 208:3969 209:3447 210:2693 211:1451 212:2100 213:1737 214:778 215:69 216:4936 217:1633 218:543 219:351 220:1231 221:496 222:337 223:218 End of report From owen at delong.com Fri Jul 15 15:19:47 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 15 Jul 2011 13:19:47 -0700 Subject: Enterprise Internet - Question In-Reply-To: References: <6EDE133FF50DBA4B963028BD5CD690DD26971B@CAPRGWLKWEMBX1.pernod-ricard.group> <6325B189-76E0-4573-ADB8-72B122870412@delong.com> <6EDE133FF50DBA4B963028BD5CD690DD269F35@CAPRGWLKWEMBX1.pernod-ricard.group> Message-ID: <8ED40D18-87A3-43C9-B37B-EB9EC6F0FA72@delong.com> There are fewer companies in Canada that have brain-dead attitudes about US customers than there are US companies with brain-dead attitudes towards Canadian customers. Probably not so much of an issue. Owen On Jul 15, 2011, at 6:51 AM, PC wrote: > Perhaps you have Canadian branches feeding off the same connection and they will have the reverse problem with geo-location? > > > > On Fri, Jul 15, 2011 at 6:29 AM, Jeff Cartier wrote: > Thanks for the comments everyone. They are much appreciated. > In regards to changing the address of our ARIN block to a US office address....are their any trades-offs in doing that? Just curious. > > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Thursday, July 14, 2011 5:02 PM > To: Jeff Cartier > Cc: nanog at nanog.org > Subject: Re: Enterprise Internet - Question > > > On Jul 14, 2011, at 12:34 PM, Jeff Cartier wrote: > > > Hi All, > > > > I just wanted to throw a question out to the list... > > > > In our data center we feed Internet to some of our US based offices and every now and again we receive complaints that they can't access some US based Internet content because they are coming from a Canadian based IP. > > > > This has sparked an interesting discussion around a few questions....of which I'd like to hear the lists opinions on. > > > > - How should/can an enterprise deal with accessibility to internet content issues? (ie. that whole coming from a Canadian IP accessing US content) > > > > This is an example of why content restriction based on IP address geolocation is such a bad idea in general. > > Frankly, the easiest thing to do (since most Canadian companies aren't as brain-dead) is to update your whois records with the address of the block allocated to your datacenter so that it looks like it's in one of your US offices. I realize this sounds silly for a variety of reasons, but, it solves the problem without expensive or configuration-intensive workarounds such as selective NAT, etc. > > > o Side question on that - Could we simply obtain a US based IP address and selectively NAT? > > > You can, but, you can also hit yourself over the head repeatedly with a hammer. Selective NAT will yield more content, but, the pain levels will probably be similar. > > > - Does the idea of regional Internet locations make sense? If so, when do they make sense? For instance, having a hub site in South America (ie. Brazil) and having all offices in Venezuela, Peru and Argentina route through a local Internet feed in Brazil. > > > > Not really. The whole content-restriction by IP geolocation thing also doesn't make sense. Unfortunately, the fact that something is nonsensical does not prevent someone from doing it or worse, selling it. > > You should do what makes sense for the economics of the topology you need. The address geolocation issues can usually be best addressed by manipulating whois. If your address block from ARIN is an allocation, you can manipulate sub-block address registration issues through the use of SWIP, for example. > > > - Does the idea of having local Internet at each site make more sense? If so why? > > > > That's really more of an economic and policy question within your organization than a technical one. > > > > Owen > > > > __________________________________________________________________ > DISCLAIMER: This e-mail contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail. > > This message has been scanned for the presence of computer viruses, Spam, and Explicit Content. > > > From info at arin.net Fri Jul 15 16:09:14 2011 From: info at arin.net (ARIN) Date: Fri, 15 Jul 2011 17:09:14 -0400 Subject: Call for ARIN XXVIII Meeting Fellowship Applicants Message-ID: <4E20AC7A.80409@arin.net> ARIN is pleased to offer a Meetings Fellowship Program to bring new voices and ideas to public policy discussions. This call is for Fellows to attend ARIN XXVIII in Philadelphia from 12-14 October 2011. If you have never attended an ARIN meeting and are interested in participating in the program, please submit your application by 26 August. The application link, submission instructions, and a detailed description of the program can be found at: https://www.arin.net/participate/meetings/fellowship.html Note that this ARIN meeting follows NANOG 53 to round out the week. Three Fellows within ARIN's service region will be selected. Fellows receive financial support to attend the Public Policy and Members Meetings, and ARIN Advisory Council representatives will serve as mentors to the Fellows to help maximize their meeting experience. Individuals selected for the fellowship receive: Free meeting registration Round-trip economy class airfare to the meeting, booked directly by ARIN Hotel accommodations at the venue hotel, booked directly by ARIN A stipend to cover meals and incidental travel expenses Please contact info at arin.net if you have any questions concerning the program and the application process. Feel free to share this opportunity within others who may be interested. Regards, Susan Hamlin Director, Communications and Member Services American Registry for Internet Numbers (ARIN) Office ? 1.703.227.9851 www.arin.net From cidr-report at potaroo.net Fri Jul 15 17:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 15 Jul 2011 22:00:00 GMT Subject: BGP Update Report Message-ID: <201107152200.p6FM00p4073579@wattle.apnic.net> BGP Update Report Interval: 07-Jul-11 -to- 14-Jul-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 48539 3.8% 66.9 -- BSNL-NIB National Internet Backbone 2 - AS17974 29134 2.3% 21.1 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 3 - AS51460 24734 1.9% 8244.7 -- SINA-AS Sina bank 4 - AS23966 24075 1.9% 72.5 -- LDN-AS-PK LINKdotNET Telecom Limited 5 - AS22646 17089 1.3% 136.7 -- HARCOM1 - Hargray Communications Group, Inc. 6 - AS6316 16896 1.3% 183.7 -- AS-PAETEC-NET - PaeTec Communications, Inc. 7 - AS32528 16423 1.3% 3284.6 -- ABBOTT Abbot Labs 8 - AS9498 12779 1.0% 17.7 -- BBIL-AP BHARTI Airtel Ltd. 9 - AS27738 12365 1.0% 36.5 -- Ecuadortelecom S.A. 10 - AS45595 11772 0.9% 51.2 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited 11 - AS6256 11720 0.9% 5860.0 -- ALLTEL - ALLTEL Corporation 12 - AS8151 10635 0.8% 10.4 -- Uninet S.A. de C.V. 13 - AS24560 9363 0.7% 8.3 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 14 - AS44609 8163 0.6% 2721.0 -- FNA Fars News Agency Cultural Arts Institute 15 - AS3454 7456 0.6% 2485.3 -- Universidad Autonoma de Nuevo Leon 16 - AS14420 7073 0.6% 10.3 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 17 - AS18101 6311 0.5% 6.7 -- RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI 18 - AS5416 6104 0.5% 56.5 -- BATELCO-BH 19 - AS2697 6051 0.5% 30.1 -- ERX-ERNET-AS Education and Research Network 20 - AS4755 5681 0.4% 48.6 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS51460 24734 1.9% 8244.7 -- SINA-AS Sina bank 2 - AS6256 11720 0.9% 5860.0 -- ALLTEL - ALLTEL Corporation 3 - AS32528 16423 1.3% 3284.6 -- ABBOTT Abbot Labs 4 - AS44609 8163 0.6% 2721.0 -- FNA Fars News Agency Cultural Arts Institute 5 - AS3454 7456 0.6% 2485.3 -- Universidad Autonoma de Nuevo Leon 6 - AS46778 1367 0.1% 1367.0 -- PHSI-1996 - Prevea Health Services Inc 7 - AS49600 957 0.1% 957.0 -- LASEDA La Seda de Barcelona, S.A 8 - AS3 889 0.1% 735.0 -- DCOMAS Didgicom LLC 9 - AS27322 793 0.1% 793.0 -- ISC-JNB1 Internet Systems Consortium, Inc. 10 - AS33314 710 0.1% 710.0 -- VCC - Vancouver Community College 11 - AS17408 3222 0.2% 537.0 -- ABOVE-AS-AP AboveNet Communications Taiwan 12 - AS48068 445 0.0% 445.0 -- VISONIC Visonic Ltd 13 - AS10445 2206 0.2% 441.2 -- HTG - Huntleigh Telcom 14 - AS3 762 0.1% 559.0 -- DCOMAS Didgicom LLC 15 - AS23364 328 0.0% 328.0 -- SECOTOOLS-US - Seco Tools Inc. 16 - AS26001 2586 0.2% 323.2 -- BLUIP - BLUIP INC 17 - AS22793 306 0.0% 306.0 -- CASSOCORP - CASSO Corporation 18 - AS49674 584 0.1% 292.0 -- DJEMBA-AS S.C. Djemba IT&C S.R.L. 19 - AS25352 283 0.0% 283.0 -- GUARDIAN-NETWORKS Guardian Networks 20 - AS40462 1128 0.1% 282.0 -- DATAFRAMELO - Dataframe Logistics, Inc. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 91.217.64.0/23 12241 0.9% AS51460 -- SINA-AS Sina bank 2 - 91.217.64.0/24 12238 0.9% AS51460 -- SINA-AS Sina bank 3 - 202.92.235.0/24 10828 0.8% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 4 - 130.36.35.0/24 8207 0.6% AS32528 -- ABBOTT Abbot Labs 5 - 130.36.34.0/24 8206 0.6% AS32528 -- ABBOTT Abbot Labs 6 - 178.22.72.0/21 8043 0.6% AS44609 -- FNA Fars News Agency Cultural Arts Institute 7 - 200.23.202.0/24 7430 0.5% AS3454 -- Universidad Autonoma de Nuevo Leon 8 - 198.133.100.0/24 5860 0.4% AS6256 -- ALLTEL - ALLTEL Corporation 9 - 198.133.99.0/24 5860 0.4% AS6256 -- ALLTEL - ALLTEL Corporation 10 - 66.248.120.0/21 5441 0.4% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 11 - 202.54.86.0/24 4936 0.4% AS4755 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 12 - 66.248.104.0/21 4818 0.3% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 13 - 66.248.96.0/21 4751 0.3% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 14 - 202.153.174.0/24 3215 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 15 - 193.8.250.0/24 3168 0.2% AS35753 -- ITC ITC AS number AS41176 -- SAHARANET-AS Sahara Net Main NOC AS 16 - 202.41.70.0/24 2934 0.2% AS2697 -- ERX-ERNET-AS Education and Research Network 17 - 204.33.88.0/23 2205 0.2% AS3549 -- GBLX Global Crossing Ltd. 18 - 67.214.68.0/23 1885 0.1% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 19 - 67.214.72.0/22 1885 0.1% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 20 - 66.248.32.0/20 1635 0.1% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jul 15 17:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 15 Jul 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201107152200.p6FM00DU073574@wattle.apnic.net> This report has been generated at Fri Jul 15 21:12:24 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 08-07-11 366112 215481 09-07-11 366207 215736 10-07-11 366401 215635 11-07-11 366352 215558 12-07-11 366478 215748 13-07-11 366636 215591 14-07-11 366443 216081 15-07-11 366674 216542 AS Summary 38311 Number of ASes in routing system 16161 Number of ASes announcing only one prefix 3598 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 109933792 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 15Jul11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 367374 216493 150881 41.1% All ASes AS6389 3598 245 3353 93.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4766 2470 956 1514 61.3% KIXS-AS-KR Korea Telecom AS18566 1913 497 1416 74.0% COVAD - Covad Communications Co. AS4755 1506 219 1287 85.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS4323 1658 402 1256 75.8% TWTC - tw telecom holdings, inc. AS22773 1351 97 1254 92.8% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS10620 1557 485 1072 68.9% Telmex Colombia S.A. AS1785 1809 764 1045 57.8% AS-PAETEC-NET - PaeTec Communications, Inc. AS19262 1427 406 1021 71.5% VZGNI-TRANSIT - Verizon Online LLC AS7552 1288 370 918 71.3% VIETEL-AS-AP Vietel Corporation AS28573 1276 388 888 69.6% NET Servicos de Comunicao S.A. AS7545 1554 712 842 54.2% TPG-INTERNET-AP TPG Internet Pty Ltd AS18101 933 146 787 84.4% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS24560 1155 383 772 66.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS8151 1447 691 756 52.2% Uninet S.A. de C.V. AS4808 1050 335 715 68.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7303 1009 326 683 67.7% Telecom Argentina S.A. AS3356 1118 459 659 58.9% LEVEL3 Level 3 Communications AS17488 966 331 635 65.7% HATHWAY-NET-AP Hathway IP Over Cable Internet AS14420 690 88 602 87.2% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS20115 1633 1032 601 36.8% CHARTER-NET-HKY-NC - Charter Communications AS22561 963 362 601 62.4% DIGITAL-TELEPORT - Digital Teleport Inc. AS17676 670 71 599 89.4% GIGAINFRA Softbank BB Corp. AS3549 991 425 566 57.1% GBLX Global Crossing Ltd. AS22047 578 32 546 94.5% VTR BANDA ANCHA S.A. AS7011 1158 623 535 46.2% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS4804 620 86 534 86.1% MPX-AS Microplex PTY LTD AS4780 748 217 531 71.0% SEEDNET Digital United Inc. AS17974 1544 1034 510 33.0% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS15475 513 9 504 98.2% NOL Total 39193 12191 27002 68.9% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.22.32.0/19 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 91.230.160.0/23 AS34396 GAMER-AS 5 Point AG 93.180.64.0/18 AS24950 SOFIASAT-AS Venus REIT OOD 93.180.88.0/21 AS42410 PTP-AS Point To Point Ltd. AS 93.180.96.0/19 AS42431 B-NET BiConsult Eood 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 116.193.152.0/24 AS55536 MIHK-HK Pacswitch Globe Telecom 116.193.153.0/24 AS55536 MIHK-HK Pacswitch Globe Telecom 116.193.154.0/24 AS55536 MIHK-HK Pacswitch Globe Telecom 116.193.155.0/24 AS55536 MIHK-HK Pacswitch Globe Telecom 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 181.82.15.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.16.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.17.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 181.82.18.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 191.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 193.111.87.0/24 AS24812 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.24.76.0/24 AS7195 Telecorp Colombia S.A. 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.58.101.0/24 AS45645 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.63.80.0/24 AS9557 PKTELECOM-AS-PK Paknet Limited Merged into PTCL 202.74.232.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.74.233.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.160.152.0/22 AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.18.156.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 204.10.232.0/21 AS33150 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.72.192.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.194.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.10.235.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From aj at sneep.net Fri Jul 15 18:03:10 2011 From: aj at sneep.net (Alastair Johnson) Date: Fri, 15 Jul 2011 16:03:10 -0700 Subject: Enterprise Internet - Question In-Reply-To: <921F8179-AD39-42F8-8DCC-1B992218D46B@delong.com> References: <6EDE133FF50DBA4B963028BD5CD690DD26971B@CAPRGWLKWEMBX1.pernod-ricard.group> <921F8179-AD39-42F8-8DCC-1B992218D46B@delong.com> Message-ID: <4E20C72E.9080803@sneep.net> On 7/14/2011 7:37 PM, Owen DeLong wrote: > To the best of my knowledge, while this person reset my account so that > I could log in (from my house), I don't think Wells Fargo has any intention > of rethinking their geo-IP based restrictions on logging in. > > So, if you travel, consider carefully whether to try and log into something > directly vs. doing so over VNC. For precisely this reason I always ensure that my banking traffic goes via a VPN through a relatively consistent set of origin IPs to the wider Internet. Solves a lot of headaches, although PayPal were confused that I could be in California and have my traffic come from Chicago (which they thought was New Jersey...). From sdhillon at decarta.com Sat Jul 16 15:29:45 2011 From: sdhillon at decarta.com (Sargun Dhillon) Date: Sat, 16 Jul 2011 15:29:45 -0500 (CDT) Subject: London UK smart hands recommendations? In-Reply-To: <1310745299.2646.35.camel@teh-desktop> Message-ID: Thirded, guys have clue. ----- Original Message ----- From: "Tom Hill" To: nanog at nanog.org Sent: Friday, July 15, 2011 8:54:57 AM Subject: Re: London UK smart hands recommendations? On Fri, 2011-07-15 at 16:30 +0100, Mark Blackman wrote: > In the unlikely event no one else suggests them, I'll point you at > NetSumo, http://www.netsumo.com/ +1, lots of clue available at Netsumo. -- Sargun Dhillon deCarta VoIP (US): +1-925-235-1105 From fw at deneb.enyo.de Sun Jul 17 04:15:25 2011 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 17 Jul 2011 11:15:25 +0200 Subject: NDP DoS attack In-Reply-To: <3B3053F2-DFFF-4AD4-920A-A28657622A5A@puck.nether.net> (Jared Mauch's message of "Thu, 14 Jul 2011 22:35:40 -0400") References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <1310429850.2382.26.camel@karl> <4E1F89EF.9090106@gont.com.ar> <4E1FA08A.8020503@gont.com.ar> <3B3053F2-DFFF-4AD4-920A-A28657622A5A@puck.nether.net> Message-ID: <87bowtl13m.fsf@mid.deneb.enyo.de> * Jared Mauch: > Solving a local attack is something I consider different in scope > than the current draft being discussed in 6man, v6ops, ipv6@ etc... That's not going to happen because it's a layering violation between the IETF and IEEE. It has not been solved during thirty years of IPv4 over Ethernet. Why would be IPv6 be different? In practice, the IPv4 vs IPv6 difference is that some vendors provide DHCP snooping, private VLANs and unicast flood protection in IPv4 land, which seems to provide a scalable way to build Ethernet networks with address validation---but there is nothing comparable for IPv6 right now, from any vendor. From fw at deneb.enyo.de Sun Jul 17 04:16:14 2011 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 17 Jul 2011 11:16:14 +0200 Subject: OT: Given what you know now, if you were 21 again... In-Reply-To: (Larry Stites's message of "Wed, 13 Jul 2011 14:08:40 -0700") References: Message-ID: <877h7hl129.fsf@mid.deneb.enyo.de> * Larry Stites: > Given what you know now, if you were 21 and just starting into > networking / communications industry which areas of study or > specialty would you prioritize? Law. From rdobbins at arbor.net Sun Jul 17 04:21:26 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 17 Jul 2011 09:21:26 +0000 Subject: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <1310429850.2382.26.camel@karl> <4E1F89EF.9090106@gont.com.ar> <4E1FA08A.8020503@gont.com.ar> <3B3053F2-DFFF-4AD4-920A-A28657622A5A@puck.nether.net> Message-ID: On Jul 15, 2011, at 10:24 AM, Jimmy Hess wrote: > In most cases if you have a DoS attack coming from the same Layer-2 network that a router is attached to, > it would mean there was already a serious security incident that occured to give the attacker that special point to attack fr This scenario is quite common in physical/virtual co-lo IDCs, FYI - customer A attacking customer B, both within the same subnet, in many cases. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From rdobbins at arbor.net Sun Jul 17 04:23:00 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 17 Jul 2011 09:23:00 +0000 Subject: NDP DoS attack In-Reply-To: <87bowtl13m.fsf@mid.deneb.enyo.de> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <1310429850.2382.26.camel@karl> <4E1F89EF.9090106@gont.com.ar> <4E1FA08A.8020503@gont.com.ar> <3B3053F2-DFFF-4AD4-920A-A28657622A5A@puck.nether.net> <87bowtl13m.fsf@mid.deneb.enyo.de> Message-ID: On Jul 17, 2011, at 4:15 PM, Florian Weimer wrote: > In practice, the IPv4 vs IPv6 difference is that some vendors provide DHCP snooping, private VLANs and unicast flood protection in IPv4 > land, which seems to provide a scalable way to build Ethernet networks with address validation---but there is nothing comparable for IPv6 > right now, from any vendor. It seems to me that IPv4 feature parity in terms of layer-2 security features should be prominently featured in upcoming RFPs. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From swmike at swm.pp.se Sun Jul 17 04:35:27 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 17 Jul 2011 11:35:27 +0200 (CEST) Subject: NDP DoS attack In-Reply-To: <87bowtl13m.fsf@mid.deneb.enyo.de> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <1310429850.2382.26.camel@karl> <4E1F89EF.9090106@gont.com.ar> <4E1FA08A.8020503@gont.com.ar> <3B3053F2-DFFF-4AD4-920A-A28657622A5A@puck.nether.net> <87bowtl13m.fsf@mid.deneb.enyo.de> Message-ID: On Sun, 17 Jul 2011, Florian Weimer wrote: > In practice, the IPv4 vs IPv6 difference is that some vendors provide > DHCP snooping, private VLANs and unicast flood protection in IPv4 land, > which seems to provide a scalable way to build Ethernet networks with > address validation---but there is nothing comparable for IPv6 right now, > from any vendor. That is not true. Check out work and reports from the IETF SAVI WG. There are actually quite a few implementations out there, being used in production. -- Mikael Abrahamsson email: swmike at swm.pp.se From fw at deneb.enyo.de Sun Jul 17 04:48:25 2011 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 17 Jul 2011 11:48:25 +0200 Subject: NDP DoS attack In-Reply-To: (Mikael Abrahamsson's message of "Sun, 17 Jul 2011 11:35:27 +0200 (CEST)") References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <1310429850.2382.26.camel@karl> <4E1F89EF.9090106@gont.com.ar> <4E1FA08A.8020503@gont.com.ar> <3B3053F2-DFFF-4AD4-920A-A28657622A5A@puck.nether.net> <87bowtl13m.fsf@mid.deneb.enyo.de> Message-ID: <87k4bhjl06.fsf@mid.deneb.enyo.de> * Mikael Abrahamsson: > On Sun, 17 Jul 2011, Florian Weimer wrote: > >> In practice, the IPv4 vs IPv6 difference is that some vendors >> provide DHCP snooping, private VLANs and unicast flood protection in >> IPv4 land, which seems to provide a scalable way to build Ethernet >> networks with address validation---but there is nothing comparable >> for IPv6 right now, from any vendor. > > That is not true. Check out work and reports from the IETF SAVI > WG. There are actually quite a few implementations out there, being > used in production. Others use tunnels, PPPoE or lots of scripting, so certainly something can be done about it. To my knowledge, SAVI SEND is still at a similar stage. Pointers to vendor documentation would be appreciated if this is not the case. And SAVI SEND is not the full story---it's still missing unicast flood protection. From swmike at swm.pp.se Sun Jul 17 05:31:25 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 17 Jul 2011 12:31:25 +0200 (CEST) Subject: NDP DoS attack In-Reply-To: <87k4bhjl06.fsf@mid.deneb.enyo.de> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <1310429850.2382.26.camel@karl> <4E1F89EF.9090106@gont.com.ar> <4E1FA08A.8020503@gont.com.ar> <3B3053F2-DFFF-4AD4-920A-A28657622A5A@puck.nether.net> <87bowtl13m.fsf@mid.deneb.enyo.de> <87k4bhjl06.fsf@mid.deneb.enyo.de> Message-ID: On Sun, 17 Jul 2011, Florian Weimer wrote: > Others use tunnels, PPPoE or lots of scripting, so certainly something > can be done about it. To my knowledge, SAVI SEND is still at a similar > stage. Pointers to vendor documentation would be appreciated if this is > not the case. -- Mikael Abrahamsson email: swmike at swm.pp.se From fw at deneb.enyo.de Sun Jul 17 05:47:48 2011 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 17 Jul 2011 12:47:48 +0200 Subject: NDP DoS attack In-Reply-To: (Mikael Abrahamsson's message of "Sun, 17 Jul 2011 12:31:25 +0200 (CEST)") References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <1310429850.2382.26.camel@karl> <4E1F89EF.9090106@gont.com.ar> <4E1FA08A.8020503@gont.com.ar> <3B3053F2-DFFF-4AD4-920A-A28657622A5A@puck.nether.net> <87bowtl13m.fsf@mid.deneb.enyo.de> <87k4bhjl06.fsf@mid.deneb.enyo.de> Message-ID: <87sjq5i3or.fsf@mid.deneb.enyo.de> * Mikael Abrahamsson: > On Sun, 17 Jul 2011, Florian Weimer wrote: > >> Others use tunnels, PPPoE or lots of scripting, so certainly >> something can be done about it. To my knowledge, SAVI SEND is still >> at a similar stage. Pointers to vendor documentation would be >> appreciated if this is not the case. > > Interesting, thnaks. It's not the vendors I would expect, and it's not based on SEND (which is not surprising at all and actually a good thing). Is this actually secure in the sense that it ties addresses to specific ports for both sending and receiving? I'm asking because folks have built similar systems for IPv4 which weren't. The CLI screenshots look good, better than what most folks achieve with IPv4. From swmike at swm.pp.se Sun Jul 17 05:59:34 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 17 Jul 2011 12:59:34 +0200 (CEST) Subject: NDP DoS attack In-Reply-To: <87sjq5i3or.fsf@mid.deneb.enyo.de> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <1310429850.2382.26.camel@karl> <4E1F89EF.9090106@gont.com.ar> <4E1FA08A.8020503@gont.com.ar> <3B3053F2-DFFF-4AD4-920A-A28657622A5A@puck.nether.net> <87bowtl13m.fsf@mid.deneb.enyo.de> <87k4bhjl06.fsf@mid.deneb.enyo.de> <87sjq5i3or.fsf@mid.deneb.enyo.de> Message-ID: On Sun, 17 Jul 2011, Florian Weimer wrote: > Interesting, thnaks. It's not the vendors I would expect, and it's not > based on SEND (which is not surprising at all and actually a good > thing). Personally I think SEND is never going to get any traction. > Is this actually secure in the sense that it ties addresses to specific > ports for both sending and receiving? I'm asking because folks have > built similar systems for IPv4 which weren't. The CLI screenshots look > good, better than what most folks achieve with IPv4. As far as I know, it's designed to work securely in an ETTH scenario, which implies both sending and receiving (if I understood you correctly). -- Mikael Abrahamsson email: swmike at swm.pp.se From fw at deneb.enyo.de Sun Jul 17 06:04:39 2011 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 17 Jul 2011 13:04:39 +0200 Subject: NDP DoS attack In-Reply-To: (Mikael Abrahamsson's message of "Sun, 17 Jul 2011 12:59:34 +0200 (CEST)") References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <1310429850.2382.26.camel@karl> <4E1F89EF.9090106@gont.com.ar> <4E1FA08A.8020503@gont.com.ar> <3B3053F2-DFFF-4AD4-920A-A28657622A5A@puck.nether.net> <87bowtl13m.fsf@mid.deneb.enyo.de> <87k4bhjl06.fsf@mid.deneb.enyo.de> <87sjq5i3or.fsf@mid.deneb.enyo.de> Message-ID: <87d3h9i2wo.fsf@mid.deneb.enyo.de> * Mikael Abrahamsson: > On Sun, 17 Jul 2011, Florian Weimer wrote: > >> Interesting, thnaks. It's not the vendors I would expect, and it's >> not based on SEND (which is not surprising at all and actually a >> good thing). > > Personally I think SEND is never going to get any traction. Last time, I was told that SEND was the way to go, despite not actually fixing anything. This mess is even worse than SCTP. >> Is this actually secure in the sense that it ties addresses to >> specific ports for both sending and receiving? I'm asking because >> folks have built similar systems for IPv4 which weren't. The CLI >> screenshots look good, better than what most folks achieve with >> IPv4. > > As far as I know, it's designed to work securely in an ETTH scenario, > which implies both sending and receiving (if I understood you > correctly). And it would also plug the NDP DOS vector because you've got a small set of addresses you need to process. Let's hope this gets buy-in from more vendors (and across the whole switch product lines, please), with full interoperability. From uri.joskovitch at telrad.com Sun Jul 17 06:29:35 2011 From: uri.joskovitch at telrad.com (Uri Joskovitch) Date: Sun, 17 Jul 2011 14:29:35 +0300 Subject: No subject Message-ID: From lear at cisco.com Sun Jul 17 10:07:09 2011 From: lear at cisco.com (Eliot Lear) Date: Sun, 17 Jul 2011 17:07:09 +0200 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> Message-ID: <4E22FA9D.4060001@cisco.com> We all make mistakes in not questioning our own positions, from time to time. You, Jeff, seem to be making that very same mistake. Please keep these points in mind: * Rome wasn't built in a day. The current system didn't come ready-made pre-built with all the bells and whistles you are used to. It grew slowly over time, as we learned what works, what doesn't, and what was missing. Any system that attempts to deal with locator/id separation will assuredly not be built in a day, either. * While you have stated a problem relating to a security consideration ? specifically that there is a potential reflection attack that could cause cache thrashing, the solution may not be what you expect. * Yes, you were asked. Even so... Novelty isn't something worth arguing over, except in patent battles. Usefulness is only worth arguing over marginally more. Deployment (or lack thereof) speaks for itself. LISP or ILNP or what-have-you either will or won't be deployed over the long run. * Never is a very long time. Many uses of "never" have been used relating to the Internet. It is the corollary to "Imminent Death of the 'Net: film @ 11." I still have the NANOG tee-shirt with Robert Metcalfe, someone with considerably more notoriety, eating his hat. Eliot From bill at herrin.us Sun Jul 17 10:42:27 2011 From: bill at herrin.us (William Herrin) Date: Sun, 17 Jul 2011 11:42:27 -0400 Subject: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)) In-Reply-To: <1310429850.2382.26.camel@karl> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <1310429850.2382.26.camel@karl> Message-ID: On Mon, Jul 11, 2011 at 8:17 PM, Karl Auer wrote: > RFC3756 IPv6 Neighbor Discovery (ND) Trust Models and Threats > > ? In this attack, the attacking node begins fabricating addresses with > ? the subnet prefix and continuously sending packets to them. ?The last > ? hop router is obligated to resolve these addresses by sending > ? neighbor solicitation packets. ?A legitimate host attempting to enter > ? the network may not be able to obtain Neighbor Discovery service from > ? the last hop router as it will be already busy with sending other > ? solicitations. Hi Karl, My off-the-cuff naive solution to this problem would be to discard the oldest incomplete solicitation to fit the new one and, upon receiving an apparently unsolicited response to a discarded solicitation, restart the process flagging that particular query non-discardable. That would be an implementation change, not a protocol change. I would expect to occasionally lose a packet due to the discard while the router was under attack with the accordingly minimal impact. I would also expect to see a multicast flood on the LAN of about the same data rate as the inbound attack packets. Where does this naive approach break down? On Fri, Jul 15, 2011 at 12:13 AM, Fernando Gont wrote: > On 07/15/2011 12:24 AM, Jimmy Hess wrote: >> A similarly hazardous situation exists with IPv4, and it is basically >> unheard of for IPv4's Layer 2/ARP security weaknesses to be exploited >> to create a DoS condition, even though they can be (very easily), > > IMO, the situation is different, in that the typical IPv4 subnet size > eliminate some of the attack vectors. Hi Fernando, Not at a practical level. The reason it's unheard of for IPv4 is that if you're a hacker with an ability to generate arbitrary packets on a LAN, DOSing the adjacent router by overwhelming its ARP cache is one of the least interesting things you can do... and one of the easiest to get busted at. It isn't necessary (or possible) to solve every conceivable *local* DOS attack. And frankly remote saturation-bomb attacks are out of bounds too. The concern Karl presented was that it was possible to remotely disable an IPv6 LAN with tailored traffic much less than that network's inbound capacity. Solve that issue with IPv6 ND and we're done. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jsw at inconcepts.biz Sun Jul 17 12:35:41 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sun, 17 Jul 2011 13:35:41 -0400 Subject: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <1310429850.2382.26.camel@karl> Message-ID: On Sun, Jul 17, 2011 at 11:42 AM, William Herrin wrote: > My off-the-cuff naive solution to this problem would be to discard the > oldest incomplete solicitation to fit the new one and, upon receiving > an apparently unsolicited response to a discarded solicitation, > restart the process flagging that particular query non-discardable. Do you mean to write, "flagging that ND entry non-discardable?" Once the ND entry is in place, it should not be purged for quite some time (configurable is a plus), on the order of minutes or hours. Making them "permanent" would, however, cause the ND table to eventually become full when foolish things like frequent source address changes for "privacy" are in use, many clients are churning in and out of the LAN, etc. > Where does this naive approach break down? It breaks down because the control-plane can't handle the relatively small number of punts which must be generated in order to send ND solicits, and without the ability to install "incomplete" entries into the data-plane, those punts cannot be policed without, by design, discarding some "good" punts along with the "bad" punts resulting from DoS traffic. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From jsw at inconcepts.biz Sun Jul 17 13:06:35 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sun, 17 Jul 2011 14:06:35 -0400 Subject: Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: <4E22FA9D.4060001@cisco.com> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <13205C286662DE4387D9AF3AC30EF456D3F3B84B65@EMBX01-WF.jnpr.net> <20110712154202.GA45271@ussenterprise.ufp.org> <4E22FA9D.4060001@cisco.com> Message-ID: On Sun, Jul 17, 2011 at 11:07 AM, Eliot Lear wrote: > We all make mistakes in not questioning our own positions, from time to > time.? You, Jeff, seem to be making that very same mistake. > Rome wasn't built in a day.? The current system didn't come ready-made > pre-built with all the bells and whistles you are used to.? It grew slowly > over time, as we learned what works, what doesn't, and what was missing. > Any system that attempts to deal with locator/id separation will assuredly > not be built in a day, either. LISP work has been going on for a long time to still not have any useful discussion on a designed-in, trivial DoS which will affect any ITR and make the work being done to allow ETRs to validate source addresses (or even do loose uRPF) into a DoS vector for ETRs as well. > While you have stated a problem relating to a security consideration ? > specifically that there is a potential reflection attack that could cause > cache thrashing, the solution may not be what you expect. I agree, a solution might be available. One has not been presented yet. In my earliest postings to the IETF LISP list, the ones which received zero replies, I suggest a way to significantly improve the cache churn DoS problem. It is not novel, as Darrel Lewis informed me, which means that even already-available research has not been applied to LISP in this area, and the Mapping Service protocol ties the hands of implementors so they *cannot* apply such techniques while still conforming to the specifications. > Yes, you were asked.? Even so... Novelty isn't something worth arguing over, > except in patent battles. Really? Novelty, by definition, advances the state of the art. You may not think it's very important to inform people that LISP is based on essentially the same flow-caching scheme used in the 1990s, but I do. > Never is a very long time.? Many uses of "never" have been used relating to > the Internet.? It is the corollary to "Imminent Death of the 'Net: film @ > 11."? I still have the NANOG tee-shirt with Robert Metcalfe, someone with > considerably more notoriety, eating his hat. And yet, I am quite comfortable with the statement that LISP can never scale up to meet the demands of the Internet. Perhaps with fundamental changes to its design, and its advocates giving up some of their current assumptions, some progress could be made. In its current form, though, LISP will never be a useful tool to scale the Internet, and in fact, it cannot meet the demands of today's Internet. Unless, of course, you pretend that the ability to DoS any router with a trivial amount of traffic is not worthy of concern. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From owen at delong.com Sun Jul 17 14:40:15 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 17 Jul 2011 12:40:15 -0700 Subject: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <1310429850.2382.26.camel@karl> Message-ID: <6B9B653F-F7A2-43C4-B2C8-30448382F286@delong.com> On Jul 17, 2011, at 10:35 AM, Jeff Wheeler wrote: > On Sun, Jul 17, 2011 at 11:42 AM, William Herrin wrote: >> My off-the-cuff naive solution to this problem would be to discard the >> oldest incomplete solicitation to fit the new one and, upon receiving >> an apparently unsolicited response to a discarded solicitation, >> restart the process flagging that particular query non-discardable. > > Do you mean to write, "flagging that ND entry non-discardable?" Once > the ND entry is in place, it should not be purged for quite some time > (configurable is a plus), on the order of minutes or hours. Making > them "permanent" would, however, cause the ND table to eventually > become full when foolish things like frequent source address changes > for "privacy" are in use, many clients are churning in and out of the > LAN, etc. > I believe it was obvious in the context he means flagging the incomplete ND entry as one that is not to be discarded early for pruning of potentially DOS-related ND entries. Basically an ND entry would have the following states and timers: Flagbits: I Incomplete (1 = ND entry is not complete) D Discardable (1 = Incomplete entry is result of incoming packet for unverified neighbor) Timers: A Age -- Counts up from time ND entry was created (most likely synthetic and calculated by storing T in the ND entry and using Tnow - Tentry). The system would have a two timer policies: 1 for Incomplete Timeout and 1 for Complete Timeout. (TI and TC) At A=TI, an incomplete entry would be discarded regardless of the D flag. At A=TC, a complete entry would be discarded regardless of the D flag. When a packet arrives for a host which does not exist in the ND table, a new entry with flags I and D would be created. An ND request would be generated as normal. When a new ND table entry is required and the table is full, the oldest entry with both I and D flags (max(A)) would be replaced with the new entry. When an ND response is received matching an entry with the I flag set, the I and D flags would be cleared and the entry would be filled in with the appropriate data. When an ND response is received not matching an entry with the I flag set, a new entry with the I flag and no D flag would be created. In this way, you cannot overflow the neighbor table in a way that creates significant disruption unless there are actually too many neighbors, in which case, it's bad network design and not DOS. >> Where does this naive approach break down? > > It breaks down because the control-plane can't handle the relatively > small number of punts which must be generated in order to send ND > solicits, and without the ability to install "incomplete" entries into > the data-plane, those punts cannot be policed without, by design, > discarding some "good" punts along with the "bad" punts resulting from > DoS traffic. > I think most of this punting could be handled at the line card level. Is there any reason that the ND process can't be moved into line-card level silicon as described above? Sure, that doesn't solve the problem on current hardware, but, it moves it from design problem to implementation issue, which IMHO is a step in the right direction. Owen From jsw at inconcepts.biz Sun Jul 17 15:17:34 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sun, 17 Jul 2011 16:17:34 -0400 Subject: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)) In-Reply-To: <6B9B653F-F7A2-43C4-B2C8-30448382F286@delong.com> References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <1310429850.2382.26.camel@karl> <6B9B653F-F7A2-43C4-B2C8-30448382F286@delong.com> Message-ID: On Sun, Jul 17, 2011 at 3:40 PM, Owen DeLong wrote: > Basically an ND entry would have the following states and timers: I've discussed what you have described with some colleagues in the past. The idea has merit and I would certainly not complain if vendors included it (as a knob) on their boxes. The downfalls of this approach are that they still don't ensure the discovery of new neighbors (rather than "ever seen" neighbors) during DoS, and you make the local DoS a bit more complex by needing to establish more rules for purging these semi-permanent entries. > I think most of this punting could be handled at the line card level. Is there > any reason that the ND process can't be moved into line-card level silicon > as described above? You could implement ND solicit in the data-plane (and remove punts entirely) in even some current chips, to say nothing of future ones. Whether or not that is a good idea, well, keep in mind that the ND solicits would then be mcasted to the LAN at a potentially unlimited rate. That is not necessarily a problem unless the L2 implementation is not too good with respect to multicast. For example, in some "switches" (mostly those that are routers that can switch) the L2 mcast has surprising caveats, such as using up a lot of fabric capacity for whatever replication scheme has been chosen. Of course, you also hope NDP on all the connected hosts works right. I believe some Juniper customers noticed a pretty big problem with JUNOS NDP implementation when deploying boxes using the DE-CIX addressing scheme, and in a situation like that, the ingress router for the attack could be crippled by spurious responses from the other mis-behaving hosts on the LAN, essentially like smurf except without sending any garbage back out to the Internet. What you definitely don't want to do is assume this fixes the local DoS, because it doesn't. I would like for you to keep in mind that a host on the LAN, misconfigured to do something like "local proxy-arp," or otherwise responding to all ND solicits, would accidentally DoS the LAN's gateway. I do not think we should assume that the local DoS won't happen, or is "fixable" with a whack-a-mole method. > Sure, that doesn't solve the problem on current hardware, but, it moves it > from design problem to implementation issue, which IMHO is a step in the > right direction. Well, it already is a design problem that implementations can largely work-around. Vendors just aren't doing it. :-/ -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From bill at herrin.us Sun Jul 17 15:32:42 2011 From: bill at herrin.us (William Herrin) Date: Sun, 17 Jul 2011 16:32:42 -0400 Subject: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <1310429850.2382.26.camel@karl> Message-ID: On Sun, Jul 17, 2011 at 1:35 PM, Jeff Wheeler wrote: > On Sun, Jul 17, 2011 at 11:42 AM, William Herrin wrote: >> My off-the-cuff naive solution to this problem would be to discard the >> oldest incomplete solicitation to fit the new one and, upon receiving >> an apparently unsolicited response to a discarded solicitation, >> restart the process flagging that particular query non-discardable. > > Do you mean to write, "flagging that ND entry non-discardable?" Hi Jeff, I meant flagging the new incomplete solicitation ineligible for previous sentence's early load-based discard. When you get a response to a solicitation you no longer remember making, solicit again and don't forget about it until the normal protocol timeouts this time. >> Where does this naive approach break down? > > It breaks down because the control-plane can't handle the relatively > small number of punts which must be generated in order to send ND > solicits, and without the ability to install "incomplete" entries into > the data-plane, those punts cannot be policed without, by design, > discarding some "good" punts along with the "bad" punts resulting from > DoS traffic. Let me try to restate what you've said to make sure I understand. When the data plane knows what ARP or ND is underway, it can guard against overwhelming the control plane by discarding excessive traffic for the same yet-unresolved destination while allowing packets for new destinations on the lan through to the control plane. Without that knowledge, it can only have one queue causing the data plane to discard packets which would initiate neighbor discovery prior to the control plane seeing them, preventing any solicitation or implementing the logic I described. This doesn't sound particularly hard to me. Most CPE has the control and data planes on the same silicon. A guard at the data plane is pointless in the first place. Just punt the packet up and move on. On the bigger iron where the planes are on running on different chips, you can move the initial ND solicitation packet into the data plane. After failing to find an incomplete ND, generate and send the ND solicitation and THEN make the decision whether to punt to the control plane or discard. If you discard, the control plane will find out about the "good" ones when the response comes back. This means you could multiply a unicast flood into a multicast flood but you'll have to pump out several orders of magnitude more packets than with the original problem before it causes me grief. Still, you've sold me on part of the claim: A /64 is inherently vulnerable to a remote DOS attack that a /120 is not. Now sell me on the other part: How does this require effort on the attacker's part that's enough smaller than the general form "flood his link" attack that I should care about it beyond poking my vendors to see if they've reasonably covered the high-load corner cases? I see how the original attack could kill a lan with a relatively small number of packets. With the naive solution, it seems to require something a lot closer to a steady flood. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Sun Jul 17 15:50:24 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 17 Jul 2011 13:50:24 -0700 Subject: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <1310429850.2382.26.camel@karl> <6B9B653F-F7A2-43C4-B2C8-30448382F286@delong.com> Message-ID: <85A1B8C0-A5CA-41FA-9C1E-A60E7215DDC8@delong.com> On Jul 17, 2011, at 1:17 PM, Jeff Wheeler wrote: > On Sun, Jul 17, 2011 at 3:40 PM, Owen DeLong wrote: >> Basically an ND entry would have the following states and timers: > > I've discussed what you have described with some colleagues in the > past. The idea has merit and I would certainly not complain if > vendors included it (as a knob) on their boxes. The downfalls of this > approach are that they still don't ensure the discovery of new > neighbors (rather than "ever seen" neighbors) during DoS, and you make > the local DoS a bit more complex by needing to establish more rules > for purging these semi-permanent entries. > Sure they do... Just not necessarily on the first attempt. There are no semi-permanent entries. In fact, it doesn't make any entry more permanent than today's state. The D flag just makes entries more readily discardable than today's entries. So you have some misconceptions about how it would work in practice, I think. Under DOS, the first packet that arrives for a known host generates the standard ND request sent to the host, but, the Incomplete ND table entry is created with the D flag set. If the host responds before the ND table entry is discarded, all functions as normal. If the entry is discarded before the host responds, then the response from the host creates a new incomplete entry without the D flag set. This entry will live for the normal time that an incomplete ND entry would be kept (not eligible for early discard) and the retry packet from the originating host would then generate a new ND request and the response should arrive before the normal incomplete ND timer expires. At that point a normal complete entry is created and things continue to function. So, what happens under this scenario is that you have a small chance that you need to wait for an initial connection retry on an unseen host, but, you can easily discard incomplete ND entries for which no response has yet been received. Further, since you're only discarding the oldest one entry each time you need to create a new entry in a full table, this would only start discarding things when an actual table overflow is occurring whether from DOS or other cause. If it's another cause, I don't think this makes life any worse. If it's DOS, then, it should be relatively rare that a responsive host is the oldest ND table entry that would get discarded, no? >> I think most of this punting could be handled at the line card level. Is there >> any reason that the ND process can't be moved into line-card level silicon >> as described above? > > You could implement ND solicit in the data-plane (and remove punts > entirely) in even some current chips, to say nothing of future ones. > Whether or not that is a good idea, well, keep in mind that the ND > solicits would then be mcasted to the LAN at a potentially unlimited > rate. > There's no reason it would have to be an unlimited rate, but, I think that would probably be acceptable in most cases anyway. > That is not necessarily a problem unless the L2 implementation is not > too good with respect to multicast. For example, in some "switches" > (mostly those that are routers that can switch) the L2 mcast has > surprising caveats, such as using up a lot of fabric capacity for > whatever replication scheme has been chosen. > If your L2 implementation sucks on Mcast in IPv6, you're kind of in a bad way anyway. > Of course, you also hope NDP on all the connected hosts works right. > I believe some Juniper customers noticed a pretty big problem with > JUNOS NDP implementation when deploying boxes using the DE-CIX > addressing scheme, and in a situation like that, the ingress router > for the attack could be crippled by spurious responses from the other > mis-behaving hosts on the LAN, essentially like smurf except without > sending any garbage back out to the Internet. > I think the bad NDP implementations on the hosts will get sorted fairly quickly anyway. Since all a spurious hosts would do is create a new incomplete entry without the D flag set the FIRST time it sends an unsolicited ND response, I'm not sure how that would really cripple the ingress router. Care to explain that? > What you definitely don't want to do is assume this fixes the local > DoS, because it doesn't. I would like for you to keep in mind that a > host on the LAN, misconfigured to do something like "local proxy-arp," > or otherwise responding to all ND solicits, would accidentally DoS the > LAN's gateway. I do not think we should assume that the local DoS > won't happen, or is "fixable" with a whack-a-mole method. > I consider local DOS to be a corner case unique to universities and very poorly run colos. We've already had that discussion and IIRC agreed to disagree. >> Sure, that doesn't solve the problem on current hardware, but, it moves it >> from design problem to implementation issue, which IMHO is a step in the >> right direction. > > Well, it already is a design problem that implementations can largely > work-around. Vendors just aren't doing it. :-/ > Well, I think provided a simple solution as outlined above it might be easier to get them to do so if they think there is demand. I know I'll be discussing this with the guy that deals with our vendors to see if we can convince them to roll it into an upcoming release. Owen From owen at delong.com Sun Jul 17 15:57:34 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 17 Jul 2011 13:57:34 -0700 Subject: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)) In-Reply-To: References: <4E19CBC5.3000801@tiggee.com> <4E19D049.8010006@unfix.org> <20110711193508.GA97493@ussenterprise.ufp.org> <1310429850.2382.26.camel@karl> Message-ID: <17FFB96E-DEE2-4D35-A822-98D6BFDDE762@delong.com> On Jul 17, 2011, at 1:32 PM, William Herrin wrote: > On Sun, Jul 17, 2011 at 1:35 PM, Jeff Wheeler wrote: >> On Sun, Jul 17, 2011 at 11:42 AM, William Herrin wrote: >>> My off-the-cuff naive solution to this problem would be to discard the >>> oldest incomplete solicitation to fit the new one and, upon receiving >>> an apparently unsolicited response to a discarded solicitation, >>> restart the process flagging that particular query non-discardable. >> >> Do you mean to write, "flagging that ND entry non-discardable?" > > Hi Jeff, > > I meant flagging the new incomplete solicitation ineligible for > previous sentence's early load-based discard. When you get a response > to a solicitation you no longer remember making, solicit again and > don't forget about it until the normal protocol timeouts this time. > If you're going to solicit again rather than wait for a new packet, what's the point of not just installing a complete entry? After all, if someone sends you a spurious response, they'll likely also be able to respond to the solicit, so, you don't really protect anything by sending the solicit. I figured you stick the ineligible incomplete entry in the table and wait for the retransmit of the original packet. > >>> Where does this naive approach break down? >> >> It breaks down because the control-plane can't handle the relatively >> small number of punts which must be generated in order to send ND >> solicits, and without the ability to install "incomplete" entries into >> the data-plane, those punts cannot be policed without, by design, >> discarding some "good" punts along with the "bad" punts resulting from >> DoS traffic. > > Let me try to restate what you've said to make sure I understand. When > the data plane knows what ARP or ND is underway, it can guard against > overwhelming the control plane by discarding excessive traffic for the > same yet-unresolved destination while allowing packets for new > destinations on the lan through to the control plane. Without that > knowledge, it can only have one queue causing the data plane to > discard packets which would initiate neighbor discovery prior to the > control plane seeing them, preventing any solicitation or implementing > the logic I described. > > This doesn't sound particularly hard to me. > > Most CPE has the control and data planes on the same silicon. A guard > at the data plane is pointless in the first place. Just punt the > packet up and move on. > I think Jeff's focus here is on the kinds of core and TOR switches that are mostly used in datacenters, not so much the CPE end of the world. > > Still, you've sold me on part of the claim: A /64 is inherently > vulnerable to a remote DOS attack that a /120 is not. > More accurately, the larger your single subnet address space, the more vulnerable you are to table overflow attacks. A /120 is exactly as vulnerable as an IPv4 /24. A /96 is exactly as vulnerable as an IPv4 /0. With bigger address spaces come new challenges. In the real world, I think this is less of an issue because: a. While the attack surface is large, the benefits of carrying out such an attack are relatively small. b. It's a relatively easy attack to spot, identify, quench, and likely trace. Owen From robert at ufl.edu Sun Jul 17 17:36:56 2011 From: robert at ufl.edu (Scott, Robert D.) Date: Sun, 17 Jul 2011 22:36:56 +0000 Subject: NetFlix Down Message-ID: <14384A642243C34495DE884D7E13C83EB922E2@UFEXCH-MBXN02.ad.ufl.edu> There appears to be a login issue at Netflix. Calls to their 1-866-579-7113 number only yields a recording that they are experiencing a higher than normal call volume, try again later. Widespread? Robert D. Scott Robert at ufl.edu Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Phone Tree University of Florida 352-273-0743 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 321-663-0421 Cell 3216630421 at messaging.sprintpcs.com From mikeal.clark at gmail.com Sun Jul 17 17:43:03 2011 From: mikeal.clark at gmail.com (Mikeal Clark) Date: Sun, 17 Jul 2011 17:43:03 -0500 Subject: NetFlix Down In-Reply-To: <14384A642243C34495DE884D7E13C83EB922E2@UFEXCH-MBXN02.ad.ufl.edu> References: <14384A642243C34495DE884D7E13C83EB922E2@UFEXCH-MBXN02.ad.ufl.edu> Message-ID: I am unable to login as well. 2011/7/17 Scott, Robert D. > There appears to be a login issue at Netflix. Calls to their > 1-866-579-7113 number only yields a recording that they are experiencing a > higher than normal call volume, try again later. Widespread? > > Robert D. Scott Robert at ufl.edu > Senior Network Engineer 352-273-0113 Phone > CNS - Network Services 352-392-2061 CNS Phone Tree > University of Florida 352-273-0743 FAX > Florida Lambda Rail 352-294-3571 FLR NOC > Gainesville, FL 32611 321-663-0421 Cell > 3216630421 at messaging.sprintpcs.com > _____ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > From kristopher.doyen at gmail.com Sun Jul 17 17:43:49 2011 From: kristopher.doyen at gmail.com (kristopher.doyen at gmail.com) Date: Sun, 17 Jul 2011 22:43:49 +0000 Subject: NetFlix Down In-Reply-To: <14384A642243C34495DE884D7E13C83EB922E2@UFEXCH-MBXN02.ad.ufl.edu> References: <14384A642243C34495DE884D7E13C83EB922E2@UFEXCH-MBXN02.ad.ufl.edu> Message-ID: <1612554540-1310942630-cardhu_decombobulator_blackberry.rim.net-541962223-@b5.c10.bise6.blackberry> Ipad app says "Service Temporarily Unavailable" at the moment. Netflix claims to be operating about 90% of their services out of aws and the only issue on the aws status page is a vpn end point issue from yesterday. -----Original Message----- From: "Scott, Robert D." Date: Sun, 17 Jul 2011 22:36:56 To: NANOG ???[nanog at nanog.org]??? Subject: NetFlix Down There appears to be a login issue at Netflix. Calls to their 1-866-579-7113 number only yields a recording that they are experiencing a higher than normal call volume, try again later. Widespread? Robert D. Scott Robert at ufl.edu Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Phone Tree University of Florida 352-273-0743 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 321-663-0421 Cell 3216630421 at messaging.sprintpcs.com _____ NANOG mailing list NANOG at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog From deleskie at gmail.com Sun Jul 17 17:58:48 2011 From: deleskie at gmail.com (jim deleskie) Date: Sun, 17 Jul 2011 19:58:48 -0300 Subject: NetFlix Down In-Reply-To: <1612554540-1310942630-cardhu_decombobulator_blackberry.rim.net-541962223-@b5.c10.bise6.blackberry> References: <14384A642243C34495DE884D7E13C83EB922E2@UFEXCH-MBXN02.ad.ufl.edu> <1612554540-1310942630-cardhu_decombobulator_blackberry.rim.net-541962223-@b5.c10.bise6.blackberry> Message-ID: Unreachable from eastern Canada as well 2011/7/17 : > Ipad app says "Service Temporarily Unavailable" at the moment. > > Netflix claims to be operating about 90% of their services out of aws and the only issue on the aws status page is a vpn end point issue from yesterday. > > -----Original Message----- > From: "Scott, Robert D." > Date: Sun, 17 Jul 2011 22:36:56 > To: NANOG ???[nanog at nanog.org]??? > Subject: NetFlix Down > > There appears to be a login issue at Netflix. ?Calls to their 1-866-579-7113 number only yields a recording that they are experiencing a higher than normal call volume, try again later. ?Widespread? > > Robert D. Scott ? ? ? ? ?Robert at ufl.edu > Senior Network Engineer ?352-273-0113 Phone > CNS - Network Services ? 352-392-2061 CNS Phone Tree > University of Florida ? ?352-273-0743 FAX > Florida Lambda Rail ? ? ?352-294-3571 FLR NOC > Gainesville, FL ?32611 ? 321-663-0421 Cell > ? ? ? ? ? ? ? ? ? ? ? ? 3216630421 at messaging.sprintpcs.com > _____ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > _____ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > From paul at paulgraydon.co.uk Sun Jul 17 18:31:20 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Sun, 17 Jul 2011 13:31:20 -1000 Subject: NetFlix Down In-Reply-To: <14384A642243C34495DE884D7E13C83EB922E2@UFEXCH-MBXN02.ad.ufl.edu> References: <14384A642243C34495DE884D7E13C83EB922E2@UFEXCH-MBXN02.ad.ufl.edu> Message-ID: <4E2370C8.9010608@paulgraydon.co.uk> On 7/17/2011 12:36 PM, Scott, Robert D. wrote: > There appears to be a login issue at Netflix. Calls to their 1-866-579-7113 number only yields a recording that they are experiencing a higher than normal call volume, try again later. Widespread? Likewise from Hawaii. Guess this'll be another thing added to Chaos Monkey: http://www.codinghorror.com/blog/2011/04/working-with-the-chaos-monkey.html From trelane at trelane.net Sun Jul 17 18:33:28 2011 From: trelane at trelane.net (Andrew Kirch) Date: Sun, 17 Jul 2011 19:33:28 -0400 Subject: NetFlix Down In-Reply-To: <14384A642243C34495DE884D7E13C83EB922E2@UFEXCH-MBXN02.ad.ufl.edu> References: <14384A642243C34495DE884D7E13C83EB922E2@UFEXCH-MBXN02.ad.ufl.edu> Message-ID: <4E237148.3010609@trelane.net> On 7/17/2011 6:36 PM, Scott, Robert D. wrote: > There appears to be a login issue at Netflix. Streaming works here. Andrew From ryan.finnesey at HarrierInvestments.com Sun Jul 17 20:58:22 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Sun, 17 Jul 2011 18:58:22 -0700 Subject: best practices for management nets in IPv6 In-Reply-To: References: <339D6250-1106-4590-8AC9-592A78351216@antelope.net> Message-ID: <6EFFEFBAC68377459A2E972105C759EC03D36697@EXVBE005-2.exch005intermedia.net> We our designing a new hosted exchange environment as well as Multi-Tenant Desktop as a Service environment and we are going to use IPv6 public address. Cheers Ryan -----Original Message----- From: James Harr [mailto:james.harr at gmail.com] Sent: Wednesday, July 13, 2011 11:22 AM To: Joel Maslak Cc: nanog at nanog.org Subject: Re: best practices for management nets in IPv6 I couldn't agree more. If you set up private address space, it's going to come back and make more work for you later. Set up public IPv6 addresses. If you need stateful connection filtering, put in a stateful firewall. If you really really need address obfuscation, you can still do NAT, but NAT from public addresses to public a public address or pool of public addresses. If you ever need to turn off NAT, it's a lot easier than renumbering hundreds of machines and you always have the option of disabling it per-host instead of doing an all-or-nothing transition. On Tue, Jul 12, 2011 at 7:32 PM, Joel Maslak wrote: > Public IPs. > > At some point you will have to manage something outside your current world or your organization will need to merge/partner/outsource/contract/etc with someone else's network and they might not be keen to route to your ULA space (and might not be more trustworthy than the internet at large anyhow). ?Think about things like VPN endpoints, video devices, telephones, etc, that may end up on a public network, maybe behind a device you manage. ?You may just manage routers today, but who knows about tomorrow. ?Put behind a firewall and use good ingress filtering throughout your network, separating trust zones with distinct subnets. > > If you are worried about forgetting to enable a firewall, put in a network management system to verify connectivity stays blocked combined with a monitored IDS. > -- ^[:wq^M From frlinux at gmail.com Mon Jul 18 06:11:32 2011 From: frlinux at gmail.com (FRLinux) Date: Mon, 18 Jul 2011 12:11:32 +0100 Subject: best practices for management nets in IPv6 In-Reply-To: References: <339D6250-1106-4590-8AC9-592A78351216@antelope.net> Message-ID: On Wed, Jul 13, 2011 at 4:22 PM, James Harr wrote: > If you really really need address obfuscation, you can still do NAT, > but NAT from public addresses to public a public address or pool of Well, You can also use IPv6 privacy extensions (by default on Windows 7), see rfc4941. For Linux, you can also enable it, which is not a default. Steph From tim at pelican.org Mon Jul 18 08:12:23 2011 From: tim at pelican.org (Tim Franklin) Date: Mon, 18 Jul 2011 14:12:23 +0100 (BST) Subject: best practices for management nets in IPv6 In-Reply-To: Message-ID: > You can also use IPv6 privacy extensions (by default on Windows 7), > see rfc4941. For Linux, you can also enable it, which is not a > default. In the context of "addresses I'm using to manage kit", having devices randomly renumber themselves at regular intervals does *not* sound like it's going to make my life easy :( Regards, Tim. From davehart at gmail.com Mon Jul 18 12:34:16 2011 From: davehart at gmail.com (Dave Hart) Date: Mon, 18 Jul 2011 17:34:16 +0000 Subject: best practices for management nets in IPv6 In-Reply-To: References: Message-ID: On Mon, Jul 18, 2011 at 13:12, Tim Franklin wrote: >> You can also use IPv6 privacy extensions (by default on Windows 7), >> see rfc4941. For Linux, you can also enable it, which is not a >> default. > > In the context of "addresses I'm using to manage kit", having devices > randomly renumber themselves at regular intervals does *not* sound > like it's going to make my life easy :( Remember, every interface has multiple addresses in IPv6. While I don't know if Linux behaves similarly, for Windows, the privacy address is primarily used for outbound connections. The MAC-derived IPv6 address is also still active, and is the one registered automatically in DNS, so you would still reach your kit via stable addresses (well, as stable as the physical network interface). Cheers, Dave Hart From jcurran at arin.net Mon Jul 18 13:13:39 2011 From: jcurran at arin.net (John Curran) Date: Mon, 18 Jul 2011 18:13:39 +0000 Subject: Fwd: [arin-announce] Abuse Contact to be Mandatory per Policy 2010-14 References: <4E2451E1.8070904@arin.net> Message-ID: <53255D40-D36C-4F85-8FB1-7164FB581EFF@corp.arin.net> This is a significant change that all NANOG folks should be aware of... FYI, /John Begin forwarded message: From: ARIN > Date: July 18, 2011 11:31:45 AM EDT To: arin-announce at arin.net Subject: [arin-announce] Abuse Contact to be Mandatory per Policy 2010-14 ARIN is preparing to implement Policy 2010-14: Standardize IP Reassignment Registration Requirements. Once this policy is implemented, all new Organization registration records (Org IDs) will need to include an Abuse POC (in addition to the already required Admin and Tech). ARIN Online, REST, and templates are all being modified to enforce this new policy requirement Existing Org IDs will also need to comply with this rule. If an existing Org ID does not have an Abuse POC already listed, the existing Tech POC (s) will also become the Abuse POC(s) by default. This policy will be implemented no later than 30 September 2011. We strongly urge all customers to review and update their organization information data, and to add an Abuse POC if one is not currently listed. Again, if a new Abuse POC is not added to the record, the existing Tech POC (s) will also become the Abuse POC(s) by default. If there are any questions, please contact the Registration Services department at hostmaster at arin.net. Regards, Leslie Nobile Director, Registration Services American Registry for Internet Numbers _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info at arin.net if you experience any issues. From jsw at inconcepts.biz Mon Jul 18 13:29:56 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Mon, 18 Jul 2011 14:29:56 -0400 Subject: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) In-Reply-To: <20110718161514.A291018C0BB@mercury.lcs.mit.edu> References: <20110718161514.A291018C0BB@mercury.lcs.mit.edu> Message-ID: On Mon, Jul 18, 2011 at 12:15 PM, Noel Chiappa wrote: > Let me make sure I understand your point here. You don't seem to be > disagreeing with the assertion that for most sites (even things like very > large universities, etc), their 'working set' (of nodes they communicate) > with will be much smaller than the network as a whole? Why would you assume this to be true if LISP also promises to make multi-homing end-sites cheaper and easier, and independent of the ISP's willingness to provide BGP without extra cost? You see, if every SOHO network and "power user" can suddenly become multi-homed without spending a great deal of money on a powerful router and ISP services which support BGP, many of these networks will do so. The working sets of a scaled-up, LISP future will make the BGP DFZ of today look small. > So only the very largest content providers (YouTube, etc) will have > 'working sets' which include a fairly large share of the entire Internet? No, any end-site of interest to a DoS attacker must be able to deal with a working set which includes the entire Internet. The reason for this is obvious: it will be the best way to attack a LISP infrastructure, and it will not be difficult for attackers to send packets where each packet's source address appears to be from a different mapping system entry. Some people have commented that LISP hopes to prevent source address spoofing through technical means that have not been fully explored. This is a good goal but it must require the ETR doing address validation to look-up state from the mapping system. It will have the same cache churn problem as an ITR subject to a reflection attack (or an outbound DoS flow meant to disable that ITR.) So there is no practical means of doing source address validation on ETRs (under DoS.) Even if you did that, the ITR must still be subject to the occasional large flow of outbound traffic from a compromised host (dorm machine, open wireless, hacked server, etc.) which is intended to disable the ITR. > I have previously commented that such sites have lots of specialized > infrastructure to handle their traffic loads - do you think it will be > infeasible for them to have specialized LISP infrastructure too? (Leaving > aside for a moment what that infrastruture would look like - it's not > necessarily separate hardware, it might be integrated into existing boxes > on the periphery of their site.) Again, every content shop will need to have that specialized infrastructure. Every site that someone might have a motive to launch a DoS attack against must be able to withstand at least trivial DoS. If you think only the super-huge sites will have a large working set, you are again ignoring DoS attacks. The same is true of ISP subscriber access platforms. If my ISP's BRAS effectively goes down regularly, I won't keep that ISP service very long, I'll change to a competitor. The more subscribers on one BRAS, the more likely it will receive frequent DoS attacks. So in reality, the common cache size needed to achieve a high hit rate really does not matter, unless you wish to ignore DoS (which you seem to want to do very badly.) -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From dougb at dougbarton.us Mon Jul 18 15:58:58 2011 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 18 Jul 2011 13:58:58 -0700 Subject: best practices for management nets in IPv6 In-Reply-To: References: Message-ID: <4E249E92.8070608@dougbarton.us> On 07/18/2011 06:12, Tim Franklin wrote: >> You can also use IPv6 privacy extensions (by default on Windows 7), >> see rfc4941. For Linux, you can also enable it, which is not a >> default. > > In the context of "addresses I'm using to manage kit", having devices randomly renumber themselves at regular intervals does *not* sound like it's going to make my life easy :( In IPv4 most people use static assignments for servers, and often use dynamic assignments for client hosts (e.g., DHCP). The IPv6 world is not different. If you don't want privacy addresses for your servers (and it's unlikely that you would) you just make sure that they are not enabled. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From steve at pirk.com Mon Jul 18 16:33:15 2011 From: steve at pirk.com (steve pirk [egrep]) Date: Mon, 18 Jul 2011 14:33:15 -0700 Subject: Google DNS just disappeared In-Reply-To: <201107150100.53944.cody@killsudo.info> References: <201107150031.35547.cody@killsudo.info> <9ADE5594-4DB2-4463-9347-7CAD9F053A86@ianai.net> <201107150100.53944.cody@killsudo.info> Message-ID: If you want to be able to ask Googlers directly on issues like this, you might try Google+. I am trying to spam, it is just that they are all available on there. Here is something Scoble posted the other day: I just spent an hour talking with a Google exec about + and I came away > with a few things: > 1. Google employees used to not be able to tell you what they are working > on. Those days are gone. > > 2. There is more intellectual curiosity inside Google than I have seen in > quite some time. > > 3. The + team is driven by our excitement and that has caused sizable > shifts in employee attention. Translation: new features are coming. Everyone > wants to work for a winner. > > This new Google attitude is something that feeds on itself. Translation: I > am excited about the future here in a way that I was never excited about > Buzz. > It has been a while since I posted, but if anyone wants an invite, ping this account or pirkster at gmail. --steve On Thu, Jul 14, 2011 at 23:00, Cody Rose wrote: > It appeared to be very brief, I just happened to be in a Google Plus > Hangout > when the chat died then my Gtalk died followed by my Google homepage. > > By the time I got done checking DNS and was getting on a trace-route server > my > chat reconnected and service was back to normal. > > Just thought it was unusual to see all my Google services go offline at the > same > time. > > Regards, > > Cody Rose > NOC & Sys Admin > Website: www.killsudo.info > email: cody at killsudo.info > > -- steve pirk refiamerica.org "father... the sleeper has awakened..." paul atreides - dune kexp.org member august '09 From deric.kwok2000 at gmail.com Mon Jul 18 20:02:49 2011 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Mon, 18 Jul 2011 21:02:49 -0400 Subject: 32 and directallocate Message-ID: Hi I have the following questions. hope you can help 1/ In ipv6 /32. ls it same as ipv4 /32 2/ If our company is using our ISP AS and their IP for providing internert ds line service, can we transfer those ip from them to us when we change other provider? 3/What is meaning directallcoate? Thank you From bruns at 2mbit.com Mon Jul 18 21:43:15 2011 From: bruns at 2mbit.com (Brielle Bruns) Date: Mon, 18 Jul 2011 20:43:15 -0600 Subject: 32 and directallocate In-Reply-To: References: Message-ID: <4E24EF43.8010001@2mbit.com> On 7/18/11 7:02 PM, Deric Kwok wrote: > Hi > > I have the following questions. hope you can help > > 1/ In ipv6 /32. ls it same as ipv4 /32 No. http://en.wikipedia.org/wiki/Ipv4 and then read: http://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing Contrast with: http://en.wikipedia.org/wiki/Ipv6 > > 2/ If our company is using our ISP AS and their IP for providing > internert ds line service, can we transfer those ip from them to us > when we change other provider? > Not unless you make specific arrangements with them, and they provide you with a /24 or larger. You can't announce anything smaller then a /24 to the general public internet as pretty much everyone filters out announcements smaller then that. > 3/What is meaning directallcoate? A direct allocation depends on what context... A direct allocation from ARIN can be a direct assignment of IP space from ARIN for an end user (for example, I have a legacy allocation from ARIN that I use with an AS number provided by ARIN, and that I can use with any provider that supports BGP announcements). Not to sound... mean or condescending, but you _are_ on a network operations mailing list. One might ask, why are you on NANOG if you do not understand things which even a jr network PFY would have to know to get a job in this field? -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From ryan.finnesey at HarrierInvestments.com Mon Jul 18 22:55:37 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Mon, 18 Jul 2011 20:55:37 -0700 Subject: best practices for management nets in IPv6 In-Reply-To: <4E249E92.8070608@dougbarton.us> References: <4E249E92.8070608@dougbarton.us> Message-ID: <6EFFEFBAC68377459A2E972105C759EC03D3679F@EXVBE005-2.exch005intermedia.net> We keep running into problem with our IPv6 roll out. I just confirmed today that Exchange does not fully support IPv6 Cheers Ryan -----Original Message----- From: Doug Barton [mailto:dougb at dougbarton.us] Sent: Monday, July 18, 2011 4:59 PM To: Tim Franklin Cc: nanog at nanog.org Subject: Re: best practices for management nets in IPv6 On 07/18/2011 06:12, Tim Franklin wrote: >> You can also use IPv6 privacy extensions (by default on Windows 7), >> see rfc4941. For Linux, you can also enable it, which is not a >> default. > > In the context of "addresses I'm using to manage kit", having devices > randomly renumber themselves at regular intervals does *not* sound > like it's going to make my life easy :( In IPv4 most people use static assignments for servers, and often use dynamic assignments for client hosts (e.g., DHCP). The IPv6 world is not different. If you don't want privacy addresses for your servers (and it's unlikely that you would) you just make sure that they are not enabled. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ _____ NANOG mailing list NANOG at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog From frnkblk at iname.com Mon Jul 18 23:34:29 2011 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 18 Jul 2011 23:34:29 -0500 Subject: best practices for management nets in IPv6 In-Reply-To: <6EFFEFBAC68377459A2E972105C759EC03D3679F@EXVBE005-2.exch005intermedia.net> References: <4E249E92.8070608@dougbarton.us> <6EFFEFBAC68377459A2E972105C759EC03D3679F@EXVBE005-2.exch005intermedia.net> Message-ID: <000001cc45cd$28587600$79096200$@iname.com> Which version of Exchange are you talking about, and can you share what about it doesn't support IPv6? Frank -----Original Message----- From: Ryan Finnesey [mailto:ryan.finnesey at HarrierInvestments.com] Sent: Monday, July 18, 2011 10:56 PM To: Doug Barton; Tim Franklin Cc: nanog at nanog.org Subject: RE: best practices for management nets in IPv6 We keep running into problem with our IPv6 roll out. I just confirmed today that Exchange does not fully support IPv6 Cheers Ryan -----Original Message----- From: Doug Barton [mailto:dougb at dougbarton.us] Sent: Monday, July 18, 2011 4:59 PM To: Tim Franklin Cc: nanog at nanog.org Subject: Re: best practices for management nets in IPv6 On 07/18/2011 06:12, Tim Franklin wrote: >> You can also use IPv6 privacy extensions (by default on Windows 7), >> see rfc4941. For Linux, you can also enable it, which is not a >> default. > > In the context of "addresses I'm using to manage kit", having devices > randomly renumber themselves at regular intervals does *not* sound > like it's going to make my life easy :( In IPv4 most people use static assignments for servers, and often use dynamic assignments for client hosts (e.g., DHCP). The IPv6 world is not different. If you don't want privacy addresses for your servers (and it's unlikely that you would) you just make sure that they are not enabled. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ _____ NANOG mailing list NANOG at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog _____ NANOG mailing list NANOG at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog From ryan.finnesey at HarrierInvestments.com Mon Jul 18 23:56:31 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Mon, 18 Jul 2011 21:56:31 -0700 Subject: best practices for management nets in IPv6 In-Reply-To: <000001cc45cd$28587600$79096200$@iname.com> References: <4E249E92.8070608@dougbarton.us> <6EFFEFBAC68377459A2E972105C759EC03D3679F@EXVBE005-2.exch005intermedia.net> <000001cc45cd$28587600$79096200$@iname.com> Message-ID: <6EFFEFBAC68377459A2E972105C759EC03D367A1@EXVBE005-2.exch005intermedia.net> Yes sorry Exchange 2010 - OCS, Lync, Exchange UM - these require IPv4 Cheers Ryan -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Tuesday, July 19, 2011 12:34 AM To: Ryan Finnesey Cc: nanog at nanog.org Subject: RE: best practices for management nets in IPv6 Which version of Exchange are you talking about, and can you share what about it doesn't support IPv6? Frank -----Original Message----- From: Ryan Finnesey [mailto:ryan.finnesey at HarrierInvestments.com] Sent: Monday, July 18, 2011 10:56 PM To: Doug Barton; Tim Franklin Cc: nanog at nanog.org Subject: RE: best practices for management nets in IPv6 We keep running into problem with our IPv6 roll out. I just confirmed today that Exchange does not fully support IPv6 Cheers Ryan -----Original Message----- From: Doug Barton [mailto:dougb at dougbarton.us] Sent: Monday, July 18, 2011 4:59 PM To: Tim Franklin Cc: nanog at nanog.org Subject: Re: best practices for management nets in IPv6 On 07/18/2011 06:12, Tim Franklin wrote: >> You can also use IPv6 privacy extensions (by default on Windows 7), >> see rfc4941. For Linux, you can also enable it, which is not a >> default. > > In the context of "addresses I'm using to manage kit", having devices > randomly renumber themselves at regular intervals does *not* sound > like it's going to make my life easy :( In IPv4 most people use static assignments for servers, and often use dynamic assignments for client hosts (e.g., DHCP). The IPv6 world is not different. If you don't want privacy addresses for your servers (and it's unlikely that you would) you just make sure that they are not enabled. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ _____ NANOG mailing list NANOG at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog _____ NANOG mailing list NANOG at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog From randy at psg.com Tue Jul 19 14:52:04 2011 From: randy at psg.com (Randy Bush) Date: Tue, 19 Jul 2011 12:52:04 -0700 Subject: problems with dnswl.org Message-ID: % /usr/local/bin/rsync \ --times \ -v \ rsync2.dnswl.org::dnswl/bind-dnswl.zone \ /var/dns/primary/org.dnswl opening tcp connection to rsync2.dnswl.org port 873 rsync: failed to connect to rsync2.dnswl.org (85.25.63.16): Operation timed out (60) rsync error: error in socket IO (code 10) at clientserver.c(122) [Receiver=3.0.8] any other paying users seeing this or know anything? no response to email to admins, though it has been only six hours or so. randy From scubacuda at gmail.com Tue Jul 19 21:21:15 2011 From: scubacuda at gmail.com (Rogelio) Date: Tue, 19 Jul 2011 23:21:15 -0300 Subject: high performance open source DHCP solution? Message-ID: The free DHCP solution, ISC, seems to be having scaling issues (i.e. handling only about 200 DHCPDISCOVER and 20 DHCPRENEW requests), and I was wondering if anyone had any open source suggestions of solutions that could scale much better? (Ideally, I could find a free version of a solution like Nominum, but I know that's asking for much.) Anyone have any suggestions? -- Also on LinkedIn?? Feel free to connect if you too are an open networker: scubacuda at gmail.com From mysidia at gmail.com Tue Jul 19 22:54:40 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 19 Jul 2011 22:54:40 -0500 Subject: high performance open source DHCP solution? In-Reply-To: References: Message-ID: On Tue, Jul 19, 2011 at 9:21 PM, Rogelio wrote: > The free DHCP solution, ISC, seems to be having scaling issues (i.e. > handling only about 200 DHCPDISCOVER and 20 DHCPRENEW requests), and I > was wondering if anyone had any open source suggestions of solutions > that could scale much better? Where do you get that ISC DHCPD only handles 200 DHCPDISCOVER / 20 DHCPRENEW requests? That doesn't sound right. So I wonder what are you measuring? Is this a number of answers per second your implementation of ISC DHCPD is providing successfully? There are architectural facts about any environment besides what software is performing the DHCP task. How many I/Os + fsync()'s per second can this DHCP server handle that does only 20 renews? -- -JH From george.herbert at gmail.com Wed Jul 20 00:08:39 2011 From: george.herbert at gmail.com (George Herbert) Date: Tue, 19 Jul 2011 22:08:39 -0700 Subject: high performance open source DHCP solution? In-Reply-To: References: Message-ID: 220-ish per second sounds roughly like a 1-disk (or 2 mirrored disk) IOPS problem, personally... But any number of other things could be affecting it. The number should be thousands if your disk / filesytem RAM cache / server configuration aren't inadequate... On Tue, Jul 19, 2011 at 8:54 PM, Jimmy Hess wrote: > On Tue, Jul 19, 2011 at 9:21 PM, Rogelio wrote: >> The free DHCP solution, ISC, seems to be having scaling issues (i.e. >> handling only about 200 DHCPDISCOVER and 20 DHCPRENEW requests), and I >> was wondering if anyone had any open source suggestions of solutions >> that could scale much better? > > Where do you get that ISC DHCPD only handles 200 DHCPDISCOVER / 20 DHCPRENEW > requests? ? ?That doesn't sound right. ? So I wonder what are you measuring? > > Is this a number of answers per second your implementation of ISC > DHCPD is providing successfully? > There are architectural facts about any environment besides what > software is performing the DHCP task. > > How many ?I/Os ?+ fsync()'s ?per second can this DHCP server handle > that does only 20 renews? > > -- > -JH > > _____ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > -- -george william herbert george.herbert at gmail.com From matthias at leisi.net Wed Jul 20 02:38:47 2011 From: matthias at leisi.net (Matthias Leisi) Date: Wed, 20 Jul 2011 09:38:47 +0200 Subject: problems with dnswl.org In-Reply-To: References: Message-ID: On Tue, Jul 19, 2011 at 9:52 PM, Randy Bush wrote: > opening tcp connection to rsync2.dnswl.org port 873 > rsync: failed to connect to rsync2.dnswl.org (85.25.63.16): Operation > timed out (60) > rsync error: error in socket IO (code 10) at clientserver.c(122) > [Receiver=3.0.8] > > any other paying users seeing this or know anything? no response to > email to admins, though it has been only six hours or so. > I'm not sure whether you got my reply to your email to admins? The provider for this machine is working on a fix. Unfortunately, they are not able to prove an estimate on when this will be done (yes, we are working to remediate this situation). As a temporary workaround, you can use an alternative hostname which will point to a another mirror (ns6.dnswl.org). -- Matthias From randy at psg.com Wed Jul 20 05:45:17 2011 From: randy at psg.com (Randy Bush) Date: Wed, 20 Jul 2011 03:45:17 -0700 Subject: problems with dnswl.org In-Reply-To: References: Message-ID: >> opening tcp connection to rsync2.dnswl.org port 873 >> rsync: failed to connect to rsync2.dnswl.org (85.25.63.16): Operation >> timed out (60) >> rsync error: error in socket IO (code 10) at clientserver.c(122) >> [Receiver=3.0.8] >> >> any other paying users seeing this or know anything? no response to >> email to admins, though it has been only six hours or so. > > I'm not sure whether you got my reply to your email to admins? no! and i just checked my spambox too. this worries me even more than rsync failure. do you have a smtp log entry for the delivery so i can look for a matching entry in my logs? > The provider for this machine is working on a fix. Unfortunately, they > are not able to prove an estimate on when this will be done (yes, we > are working to remediate this situation). no problem. would be nice to put on 'news' at http://dnswl.org/news/ and then i would not have wasted folk's time. > As a temporary workaround, you can use an alternative hostname which will > point to a another mirror (ns6.dnswl.org). % host ns6.dnswl.org Host ns6.dnswl.org not found: 3(NXDOMAIN) randy From nicolas at ncartron.org Wed Jul 20 06:29:04 2011 From: nicolas at ncartron.org (Nicolas CARTRON) Date: Wed, 20 Jul 2011 13:29:04 +0200 Subject: problems with dnswl.org In-Reply-To: References: Message-ID: On Wednesday, July 20, 2011 at 12:45 PM, Randy Bush wrote: > > As a temporary workaround, you can use an alternative hostname which will > > point to a another mirror (ns6.dnswl.org (http://ns6.dnswl.org)). > > % host ns6.dnswl.org (http://ns6.dnswl.org) > Host ns6.dnswl.org (http://ns6.dnswl.org) not found: 3(NXDOMAIN) Works from here: $ dig ns6.dnswl.org +short 74.208.14.82 -- Nicolas From ncolton at allophone.net Wed Jul 20 09:31:23 2011 From: ncolton at allophone.net (Nick Colton) Date: Wed, 20 Jul 2011 08:31:23 -0600 Subject: high performance open source DHCP solution? In-Reply-To: References: Message-ID: We were seeing similar issues with low leases, moved the dhcpd.leases file to a ramdisk and went from ~200 leases per second to something like 8,000 leases per second. On Tue, Jul 19, 2011 at 11:08 PM, George Herbert wrote: > 220-ish per second sounds roughly like a 1-disk (or 2 mirrored disk) > IOPS problem, personally... > > But any number of other things could be affecting it. > > The number should be thousands if your disk / filesytem RAM cache / > server configuration aren't inadequate... > > On Tue, Jul 19, 2011 at 8:54 PM, Jimmy Hess wrote: > > On Tue, Jul 19, 2011 at 9:21 PM, Rogelio wrote: > >> The free DHCP solution, ISC, seems to be having scaling issues (i.e. > >> handling only about 200 DHCPDISCOVER and 20 DHCPRENEW requests), and I > >> was wondering if anyone had any open source suggestions of solutions > >> that could scale much better? > > > > Where do you get that ISC DHCPD only handles 200 DHCPDISCOVER / 20 > DHCPRENEW > > requests? That doesn't sound right. So I wonder what are you > measuring? > > > > Is this a number of answers per second your implementation of ISC > > DHCPD is providing successfully? > > There are architectural facts about any environment besides what > > software is performing the DHCP task. > > > > How many I/Os + fsync()'s per second can this DHCP server handle > > that does only 20 renews? > > > > -- > > -JH > > > > _____ > > NANOG mailing list > > NANOG at nanog.org > > https://mailman.nanog.org/mailman/listinfo/nanog > > > > > > -- > -george william herbert > george.herbert at gmail.com > > _____ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > From daniel.unam.ipv6 at gmail.com Wed Jul 20 11:08:12 2011 From: daniel.unam.ipv6 at gmail.com (Daniel Espejel) Date: Wed, 20 Jul 2011 11:08:12 -0500 Subject: CISCO IOS 12.x Virtual Switch In-Reply-To: References: Message-ID: <4E26FD6C.4060804@gmail.com> Hello list!. I want to virtualize a CISCO Switch with CISCO IOS 12.x to perform some test on its RA-Guard implementation. By searching over Internet I've found that its possible to virtualize some devices such as routers using GSN3 and a CISCO IOS image. Is it possible to do something like this but for a switch instead of a router?. Or does anyone have any suggestions in order to test CISCO's RA-Guard (or another implementation)?? Best regards. -- Daniel Espejel Perez From psirt at cisco.com Wed Jul 20 11:00:00 2011 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 20 Jul 2011 12:00:00 -0400 Subject: Cisco Security Advisory: Cisco ASR 9000 Series Routers Line Card IP Version 4 Denial of Service Vulnerability Message-ID: <201107201200.asr9k-dos@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco Security Advisory: Cisco ASR 9000 Series Routers Line Card IP Version 4 Denial of Service Vulnerability Advisory ID: cisco-sa-20110720-asr9k Revision 1.0 For Public Release 2011 July 20 1600 UTC (GMT) +--------------------------------------------------------------------- Summary ======= Cisco 9000 Series Aggregation Services Routers (ASR) running Cisco IOS XR Software version 4.1.0 contain a vulnerability that may cause a network processor in a line card to lock up while processing an IP version 4 (IPv4) packet. As a consequence of the network processor lockup, the line card that is processing the offending packet will automatically reload. Cisco has released a free software maintenance upgrade (SMU) to address this vulnerability. There are no workarounds for this vulnerability. This advisory is posted at: http://www.cisco.com/warp/public/707/cisco-sa-20110720-asr9k.shtml Affected Products ================= Vulnerable Products +------------------ This vulnerability affects the following Cisco ASR 9000 Series devices when they are running Cisco IOS XR Software version 4.1.0 without the SMU asr9k-p-4.1.0.CSCtr26695.tar installed: * Cisco ASR 9006 router * Cisco ASR 9010 router To determine the software running on a Cisco ASR 9000 Series device, log in to the device and issue the show version brief command to display the system banner. The system banner confirms that the device is running Cisco IOS XR Software by displaying text similar to Cisco IOS XR Software. The software version is displayed after the text Cisco IOS XR Software. The following example identifies a Cisco ASR 9010 that is running Cisco IOS XR Software Release 4.1.0: RP/0/0/CPU0:Router#show version brief Fri Jul 8 18:54:39.222 CEST Cisco IOS XR Software, Version 4.1.0[Default] Copyright (c) 2011 by Cisco Systems, Inc. ROM: System Bootstrap, Version 1.05(20101118:025914) [ASR9K ROMMON], Router uptime is 9 weeks, 1 day, 5 hours, 53 minutes System image file is "bootflash:disk0/asr9k-os-mbi-4.1.0/mbiasr9k-rp.vm" cisco ASR9K Series (MPC8641D) processor with 4194304K bytes of memory. MPC8641D processor at 1333MHz, Revision 2.2 ASR-9010-CHASSIS 4 Management Ethernet 8 WANPHY controller(s) 8 TenGigE 8 DWDM controller(s) 40 GigabitEthernet 4 SONET/SDH 2 Packet over SONET/SDH 1 MgmtMultilink 219k bytes of non-volatile configuration memory. 975M bytes of compact flash card. 33994M bytes of hard disk. 1605616k bytes of disk0: (Sector size 512 bytes). 1605616k bytes of disk1: (Sector size 512 bytes). To determine which SMUs are active on the device, issue the show install active summary command. This command will return a list of all SMUs installed, as shown in the following example: RP/0/0/CPU0:Router#show install active summary Fri Jul 8 19:02:15.887 CEST Active Packages: disk0:asr9k-doc-p-4.1.0 disk0:asr9k-mini-p-4.1.0 disk0:asr9k-k9sec-p-4.1.0 disk0:asr9k-video-p-4.1.0 Note: The preceding output shows a device without the SMU asr9k-p-4.1.0.CSCtr26695.tar installed. Also note that Cisco IOS XR Software can include multiple SMUs and the output may differ from the preceding example. Products Confirmed Not Vulnerable +-------------------------------- The following products are confirmed not vulnerable: * Cisco Carrier Routing System (CRS) running any version of Cisco IOS XR Software * Cisco XR 12000 Series Routers running any version of Cisco IOS XR Software * Cisco 12000 Series Routers running any version of Cisco IOS Software * Cisco IOS Software * Cisco IOS XE Software * Cisco NX-OS Software * Cisco ASR 1000 and 5000 Series routers running any version of software * Cisco ASR 9000 Series routers running any version of Cisco IOS XR Software other than 4.1.0 * Cisco ASR 9000 Series routers running Cisco IOS XR Software version 4.1.0 and with the SMU asr9k-p-4.1.0.CSCtr26695.tar installed To determine which SMUs are active on the device, issue the show install active summary command. This will return a list of all SMUs installed: RP/0/0/CPU0:Router#show install active summary Fri Jul 8 19:02:15.887 CEST Active Packages: disk0:asr9k-p-4.1.0.CSCtr26695-1.0.0 disk0:asr9k-p-4.1.0.CSCto96804-1.0.0 disk0:asr9k-p-4.1.0.CSCto95435-1.0.0 disk0:asr9k-doc-p-4.1.0 disk0:asr9k-mini-p-4.1.0 disk0:asr9k-k9sec-p-4.1.0 disk0:asr9k-video-p-4.1.0 Note: The preceding output shows a device with the SMU asr9k-p-4.1.0.CSCtr26695.tar installed (in bold). Also note that Cisco IOS XR Software can include multiple SMUs and the output may differ from the preceding example. Details ======= Cisco ASR 9000 Series routers are designed to provide carrier-class reliability using the Cisco IOS XR Software modular operating system, offering service and application-level intelligence focused on optimized video delivery and mobile aggregation in Carrier Ethernet Services networks. Cisco IOS XR Software is a distributed operating system designed for continuous system operation combined with service flexibility and high performance. Cisco ASR 9000 Series devices running Cisco IOS XR Software version 4.1.0 contain a vulnerability that may cause a network processor in a line card to lock up while processing an IPv4 packet. As a consequence of the network processor lockup, the line card that is processing the offending packet will automatically reload. This vulnerability can be triggered only by IPv4 packets. If only IP version 6 (IPv6) is in use, the device is not vulnerable. Both transit IPv4 packets and IPv4 packets directed to the device itself may trigger this vulnerability. One or both the following messages may appear in the system log: * PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED * PLATFORM-DIAGS-0-LC_NP_LOOPBACK_FAILED This vulnerability is documented as CSCtr26695and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2011-2549 Vulnerability Scoring Details +---------------------------- Cisco has provided scores for the vulnerability in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at: http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at: http://intellishield.cisco.com/security/alertmanager/cvss * CSCtr26695 - ASR9k:Line Card Issue with NP lockup CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.8 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of the vulnerability described in this advisory may cause the affected line card to reload. Repeated exploitation could result in a sustained denial of service (DoS) condition. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS XR Software table (below) names a Cisco IOS XR Software release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix, if available at the time of Advisory, are listed in the "First Fixed Release" column of the table. +--------------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |-------------+------------------------------------------------------| | | SMU ID | SMU Name | First Fixed | | | | | Release | |-------------+------------------------------------------------------| | 3.2.X | | | through | Not affected | | 4.0.X | | |-------------+------------------------------------------------------| | 4.1.0 | AA05118 | asr9k-p-4.1.0.CSCtr26695.tar | 4.1.1 | +--------------------------------------------------------------------+ Note: At the time of this advisory, Release 4.1.1 is expected to be available on July 29, 2011. Workarounds =========== There are no workarounds for this vulnerability. Obtaining Fixed Software ======================== Cisco has released free software updates that address these vulnerabilities. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at: http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html Or as otherwise set forth at Cisco.com Downloads at: http://www.cisco.com/public/sw-center/sw-usingswc.shtml Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com. Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to: http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html For additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory. This vulnerability was found during the resolution of multiple customer service requests. We would like to thank the Internet Measurement Group from the University of Washington for their help and support on troubleshooting this issue. Status of this Notice: FINAL ============================ THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco's worldwide website at : http://www.cisco.com/warp/public/707/cisco-sa-20110720-asr9k.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce at cisco.com * first-bulletins at lists.first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk * comp.dcom.sys.cisco at newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +--------------------------------------------------------------------+ | Revision 1.0 | 2011-July-20 | Initial public release | +--------------------------------------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at: http://www.cisco.com/go/psirt +-------------------------------------------------------------------- Copyright 2010-2011 Cisco Systems, Inc. All rights reserved. +-------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iF4EAREIAAYFAk4m/30ACgkQQXnnBKKRMND3gAD/QU7mozUjiGpbzBoEtIYGi8uj Bhe/TfxZjzFA4tNYZAYA/RUP7WMFrhK9q8jWUrniWTwcbp1PAc90pyPZ2QwTkwFK =vnj1 -----END PGP SIGNATURE----- From ryanshea at google.com Wed Jul 20 13:48:09 2011 From: ryanshea at google.com (Ryan Shea) Date: Wed, 20 Jul 2011 14:48:09 -0400 Subject: CISCO IOS 12.x Virtual Switch In-Reply-To: <4E26FD6C.4060804@gmail.com> References: <4E26FD6C.4060804@gmail.com> Message-ID: Ask your Cisco SE about IOU licensing and its capabilities regarding switching. You can do some limited switch lab work with dynamips and an NM-16-ESW though. On Jul 20, 2011 12:08 PM, "Daniel Espejel" wrote: > > Hello list!. > > I want to virtualize a CISCO Switch with CISCO IOS 12.x to perform some > test on its RA-Guard implementation. By searching over Internet I've > found that its possible to virtualize some devices such as routers using > GSN3 and a CISCO IOS image. Is it possible to do something like this but > for a switch instead of a router?. > > Or does anyone have any suggestions in order to test CISCO's RA-Guard > (or another implementation)?? > > Best regards. > > -- > Daniel Espejel Perez > > > _____ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog From scubacuda at gmail.com Wed Jul 20 15:14:21 2011 From: scubacuda at gmail.com (Rogelio) Date: Wed, 20 Jul 2011 17:14:21 -0300 Subject: real ARP / CAM limits on Huawei CX600? Message-ID: Anyone have any good info on how many ARP entries one of the Huawei CX600 routers can take? http://www.huawei.com/en/products/data-communication/metro-services-platform/cx600/index.htm I will be passing about 1000 L2TP tunnels to a router before it, and the subscriber network that will be hitting the interface is about 30K people at any given time. I'm hoping that it's cool ARP-wise and that the bridging that's done internally doesn't break (i.e. Huawei's equivalent to a CAM table) -- Also on LinkedIn?? Feel free to connect if you too are an open networker: scubacuda at gmail.com From tarko at lanparty.ee Wed Jul 20 15:18:03 2011 From: tarko at lanparty.ee (Tarko Tikan) Date: Wed, 20 Jul 2011 23:18:03 +0300 Subject: high performance open source DHCP solution? In-Reply-To: References: Message-ID: <1311192875-sup-6268@lanparty.ee> hey, > The free DHCP solution, ISC, seems to be having scaling issues (i.e. > handling only about 200 DHCPDISCOVER and 20 DHCPRENEW requests), and I > was wondering if anyone had any open source suggestions of solutions > that could scale much better? You are doing something wrong: * turn off ping-check * use proper raid controller with battery backup (because isc dhcpd does fsync every time it writes to dhcpd.leases) * ... * profit -- tarko From mysidia at gmail.com Wed Jul 20 17:28:38 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 20 Jul 2011 17:28:38 -0500 Subject: high performance open source DHCP solution? In-Reply-To: References: Message-ID: On Wed, Jul 20, 2011 at 9:31 AM, Nick Colton wrote: > We were seeing similar issues with low leases, moved the dhcpd.leases file > to a ramdisk and went from ~200 leases per second to something like 8,000 > leases per second. Yes, blame RFC2131's requirement that a DHCP server is to ensure that any lease is committed to persistent storage, strictly before a DHCP server is allowed to send the response to the request; a fully compliant DHCP server with sufficient traffic is bound by the disk I/O rate of underlying storage backing its database. I do not recommend use of a RAMDISK; it's safer to bend the rule than break it entirely; a safer way is probably to use a storage system on a battery-backed NVRAM cache that you configure to ignore SYNC() and lie to the DHCP server application, allowing the storage system to aggregate the I/O. Of course, committing to a RAMDISK tricks the DHCP server software. The danger is that if your DHCP server suffers an untimely reboot, you will have no transactionally safe record of the leases issued, when the replacement comes up, or the DHCP server completes its reboot cycle. As a result, you can generate conflicting IP address assignments, unless you: (a) Have an extremely short max lease duration (which can increase DHCP server load), or (b) Have a policy of pinging before assigning an IP, which limits DHCP server performance and is not fool proof. -- -JH From walter.keen at rainierconnect.net Wed Jul 20 17:37:44 2011 From: walter.keen at rainierconnect.net (Walter Keen) Date: Wed, 20 Jul 2011 15:37:44 -0700 Subject: high performance open source DHCP solution? In-Reply-To: References: Message-ID: <4E2758B8.5080804@rainierconnect.net> We've recently setup ISC DHCPd with failover for lease information, and LDAP as a configuration source (mostly because of our need for dynamically adding dhcp reservations for cable modems, etc) -- we don't have any performance issues thus far, but I'd imagine in a failover environment, it might be safe to consider a ramdisk for leases. Obvoiusly breaks RFC2131, but... Walter Keen Network Engineer Rainier Connect (P) 360-832-4024 (C) 253-302-0194 On 07/20/2011 03:28 PM, Jimmy Hess wrote: > On Wed, Jul 20, 2011 at 9:31 AM, Nick Colton wrote: >> We were seeing similar issues with low leases, moved the dhcpd.leases file >> to a ramdisk and went from ~200 leases per second to something like 8,000 >> leases per second. > Yes, blame RFC2131's requirement that a DHCP server is to ensure that any > lease is committed to persistent storage, strictly before a DHCP > server is allowed to > send the response to the request; a fully compliant DHCP server with > sufficient traffic > is bound by the disk I/O rate of underlying storage backing its database. > > I do not recommend use of a RAMDISK; it's safer to bend the rule than break it > entirely; a safer way is probably to use a storage system on a battery-backed > NVRAM cache that you configure to ignore SYNC() and lie to the DHCP server > application, allowing the storage system to aggregate the I/O. > > > Of course, committing to a RAMDISK tricks the DHCP server software. > The danger is that if your DHCP server suffers an untimely reboot, you > will have no transactionally safe record of the leases issued, when the > replacement comes up, or the DHCP server completes its reboot cycle. > > As a result, you can generate conflicting IP address assignments, unless you: > (a) Have an extremely short max lease duration (which can increase > DHCP server load), or > (b) Have a policy of pinging before assigning an IP, which limits DHCP server > performance and is not fool proof. > > -- > -JH > > _____ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog From joelja at bogus.com Wed Jul 20 18:01:22 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 20 Jul 2011 16:01:22 -0700 Subject: high performance open source DHCP solution? In-Reply-To: <4E2758B8.5080804@rainierconnect.net> References: <4E2758B8.5080804@rainierconnect.net> Message-ID: <1D59D851-2A0E-4CED-BAA5-61FDFD3CF4D0@bogus.com> On Jul 20, 2011, at 3:37 PM, Walter Keen wrote: > We've recently setup ISC DHCPd with failover for lease information, and > LDAP as a configuration source (mostly because of our need for > dynamically adding dhcp reservations for cable modems, etc) -- we don't > have any performance issues thus far, but I'd imagine in a failover > environment, it might be safe to consider a ramdisk for leases. > Obvoiusly breaks RFC2131, but... Use an ssd, all the cool kids with monolithic databases and tpc-c style workloads are doing it and since your storage requirements are negligible it ought to be fairly cheap. http://www.intel.com/design/flash/nand/extreme/index.htm Bandwidth Sustained sequential read: up to 250 MB/s Sustained sequential write: up to 170 MB/s Read latency 75 microseconds I/O Per Second (IOPS) Random 4KB Reads: >35,000 IOPS Random 4KB Writes: >3,300 IOP and that's for just one disk. > Walter Keen > Network Engineer > Rainier Connect > > (P) 360-832-4024 > (C) 253-302-0194 > > > On 07/20/2011 03:28 PM, Jimmy Hess wrote: >> On Wed, Jul 20, 2011 at 9:31 AM, Nick Colton wrote: >>> We were seeing similar issues with low leases, moved the dhcpd.leases file >>> to a ramdisk and went from ~200 leases per second to something like 8,000 >>> leases per second. >> Yes, blame RFC2131's requirement that a DHCP server is to ensure that any >> lease is committed to persistent storage, strictly before a DHCP >> server is allowed to >> send the response to the request; a fully compliant DHCP server with >> sufficient traffic >> is bound by the disk I/O rate of underlying storage backing its database. >> >> I do not recommend use of a RAMDISK; it's safer to bend the rule than break it >> entirely; a safer way is probably to use a storage system on a battery-backed >> NVRAM cache that you configure to ignore SYNC() and lie to the DHCP server >> application, allowing the storage system to aggregate the I/O. >> >> >> Of course, committing to a RAMDISK tricks the DHCP server software. >> The danger is that if your DHCP server suffers an untimely reboot, you >> will have no transactionally safe record of the leases issued, when the >> replacement comes up, or the DHCP server completes its reboot cycle. >> >> As a result, you can generate conflicting IP address assignments, unless you: >> (a) Have an extremely short max lease duration (which can increase >> DHCP server load), or >> (b) Have a policy of pinging before assigning an IP, which limits DHCP server >> performance and is not fool proof. >> >> -- >> -JH >> >> _____ >> NANOG mailing list >> NANOG at nanog.org >> https://mailman.nanog.org/mailman/listinfo/nanog > > _____ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > From george.herbert at gmail.com Wed Jul 20 19:17:55 2011 From: george.herbert at gmail.com (George Herbert) Date: Wed, 20 Jul 2011 17:17:55 -0700 Subject: high performance open source DHCP solution? In-Reply-To: <1D59D851-2A0E-4CED-BAA5-61FDFD3CF4D0@bogus.com> References: <4E2758B8.5080804@rainierconnect.net> <1D59D851-2A0E-4CED-BAA5-61FDFD3CF4D0@bogus.com> Message-ID: Good luck buying X25-Es; they're out of production and all gone from supply chain. Replacement 710 and 720 models are ETA in late August at the moment. Micron has some large-cap SLC drives in the chain for September/October/ish timeframes. Ramdisk with rsync or rdiffbackup to spinning storage will do just fine. -george On Wed, Jul 20, 2011 at 4:01 PM, Joel Jaeggli wrote: > > On Jul 20, 2011, at 3:37 PM, Walter Keen wrote: > >> We've recently setup ISC DHCPd with failover for lease information, and >> LDAP as a configuration source (mostly because of our need for >> dynamically adding dhcp reservations for cable modems, etc) -- we don't >> have any performance issues thus far, but I'd imagine in a failover >> environment, it might be safe to consider a ramdisk for leases. >> Obvoiusly breaks RFC2131, but... > > Use an ssd, all the cool kids with monolithic databases and tpc-c style workloads are doing it and since your storage requirements are negligible it ought to be fairly cheap. > > http://www.intel.com/design/flash/nand/extreme/index.htm > > Bandwidth Sustained sequential read: up to 250 MB/s > Sustained sequential write: up to 170 MB/s > Read latency 75 microseconds I/O Per Second (IOPS) > Random 4KB Reads: >35,000 IOPS > Random 4KB Writes: >3,300 IOP > > and that's for just one disk. > >> Walter Keen >> Network Engineer >> Rainier Connect >> >> (P) 360-832-4024 >> (C) 253-302-0194 >> >> >> On 07/20/2011 03:28 PM, Jimmy Hess wrote: >>> On Wed, Jul 20, 2011 at 9:31 AM, Nick Colton ?wrote: >>>> We were seeing similar issues with low leases, moved the dhcpd.leases file >>>> to a ramdisk and went from ~200 leases per second to something like 8,000 >>>> leases per second. >>> Yes, blame RFC2131's ?requirement that a DHCP server is to ensure that any >>> lease is committed to persistent storage, strictly before a DHCP >>> server is allowed to >>> send the response to the request; ? a fully compliant DHCP server with >>> sufficient traffic >>> is bound by the disk I/O rate ?of underlying storage backing its database. >>> >>> I do not recommend use of a RAMDISK; ?it's safer to bend the rule than break it >>> entirely; ? a safer way is probably to use a storage system on a battery-backed >>> NVRAM cache ?that you configure to ignore SYNC() and lie to the DHCP server >>> application, ?allowing the storage system to aggregate the I/O. >>> >>> >>> Of course, ?committing to a RAMDISK tricks the DHCP server software. >>> The danger is that if your DHCP server suffers an untimely reboot, you >>> will have no transactionally safe record of the leases issued, when the >>> replacement comes up, or the ?DHCP server completes its reboot cycle. >>> >>> As a result, you can generate conflicting IP address assignments, unless you: >>> (a) Have an extremely short max lease duration ?(which can increase >>> DHCP server load), or >>> (b) Have a policy of pinging before assigning an IP, which limits DHCP server >>> performance and is not fool proof. >>> >>> -- >>> -JH >>> >>> _____ >>> NANOG mailing list >>> NANOG at nanog.org >>> https://mailman.nanog.org/mailman/listinfo/nanog >> >> _____ >> NANOG mailing list >> NANOG at nanog.org >> https://mailman.nanog.org/mailman/listinfo/nanog >> > > > _____ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > -- -george william herbert george.herbert at gmail.com From jra at baylink.com Wed Jul 20 19:19:40 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 20 Jul 2011 20:19:40 -0400 (EDT) Subject: high performance open source DHCP solution? In-Reply-To: Message-ID: <21226672.1947.1311207580967.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jimmy Hess" > Of course, committing to a RAMDISK tricks the DHCP server software. > The danger is that if your DHCP server suffers an untimely reboot, you > will have no transactionally safe record of the leases issued, when > the replacement comes up, or the DHCP server completes its reboot cycle. > > As a result, you can generate conflicting IP address assignments, > unless you: > (a) Have an extremely short max lease duration (which can increase > DHCP server load), or > (b) Have a policy of pinging before assigning an IP, which limits DHCP > server performance and is not fool proof. I think a lot of this depends on the target audience of your server. It sounds like he's in a commercial WAN environment, which of course is what those rules were written for. But I can't tell you how many service calls I have to take because of address conflicts on home LANs behind consumer routers... which don't generally cache the assignments at all, IME. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From daniel.unam.ipv6 at gmail.com Wed Jul 20 19:53:03 2011 From: daniel.unam.ipv6 at gmail.com (Daniel Espejel) Date: Wed, 20 Jul 2011 19:53:03 -0500 Subject: CISCO IOS 12.x Virtual Switch In-Reply-To: References: Message-ID: <4E27786F.6060204@gmail.com> Thank you very much, now I'll try to perform some deployments over a C3600 w/NS module. Best regards. -- Daniel Espejel Perez From marka at isc.org Wed Jul 20 20:13:07 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 21 Jul 2011 11:13:07 +1000 Subject: high performance open source DHCP solution? In-Reply-To: Your message of "Wed, 20 Jul 2011 20:19:40 -0400." <21226672.1947.1311207580967.JavaMail.root@benjamin.baylink.com> References: <21226672.1947.1311207580967.JavaMail.root@benjamin.baylink.com> Message-ID: <20110721011307.8E2BE12034F8@drugs.dv.isc.org> In message <21226672.1947.1311207580967.JavaMail.root at benjamin.baylink.com>, Jay Ashworth writes: > ----- Original Message ----- > > From: "Jimmy Hess" > > > Of course, committing to a RAMDISK tricks the DHCP server software. > > The danger is that if your DHCP server suffers an untimely reboot, you > > will have no transactionally safe record of the leases issued, when > > the replacement comes up, or the DHCP server completes its reboot cycle. > > > > As a result, you can generate conflicting IP address assignments, > > unless you: > > (a) Have an extremely short max lease duration (which can increase > > DHCP server load), or > > (b) Have a policy of pinging before assigning an IP, which limits DHCP > > server performance and is not fool proof. > > I think a lot of this depends on the target audience of your server. > > It sounds like he's in a commercial WAN environment, which of course is what > those rules were written for. But I can't tell you how many service calls I > have to take because of address conflicts on home LANs behind consumer > routers... which don't generally cache the assignments at all, IME. What I hate is my cable provider re-numbering without winding down the lease time first. Waking up in the morning to a lease that say its still got 18+ hours to go and no net shouldn't happen. If the DHCP server has said the address is good for 24 hours it should be good for 24 hours. I know first level support will say to reboot, which forces a renew which fails, but one shouldn't have to reboot for a renumber event. Run the old and new spaces in parallel for 24 hours. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mpetach at netflight.com Wed Jul 20 20:23:08 2011 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 20 Jul 2011 18:23:08 -0700 Subject: slides missing from NANOG52 page? Message-ID: Anyone know what happened to the slide decks from the most recent NANOG? They used to be linked off http://www.nanog.org/meetings/nanog52/agenda.php but seem to have gone missing. :( Thanks! Matt From owen at delong.com Wed Jul 20 20:25:50 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Jul 2011 18:25:50 -0700 Subject: high performance open source DHCP solution? In-Reply-To: References: Message-ID: <3C2029CB-9EAE-4B22-B59C-92437FB86C74@delong.com> SSDs can be a good alternative these days as well. Some of them have gotten to be quite fast. Sure, you'll have to replace them more often than spinning media, but, the write times can be quite a bit better. Owen On Jul 20, 2011, at 3:28 PM, Jimmy Hess wrote: > On Wed, Jul 20, 2011 at 9:31 AM, Nick Colton wrote: >> We were seeing similar issues with low leases, moved the dhcpd.leases file >> to a ramdisk and went from ~200 leases per second to something like 8,000 >> leases per second. > > Yes, blame RFC2131's requirement that a DHCP server is to ensure that any > lease is committed to persistent storage, strictly before a DHCP > server is allowed to > send the response to the request; a fully compliant DHCP server with > sufficient traffic > is bound by the disk I/O rate of underlying storage backing its database. > > I do not recommend use of a RAMDISK; it's safer to bend the rule than break it > entirely; a safer way is probably to use a storage system on a battery-backed > NVRAM cache that you configure to ignore SYNC() and lie to the DHCP server > application, allowing the storage system to aggregate the I/O. > > > Of course, committing to a RAMDISK tricks the DHCP server software. > The danger is that if your DHCP server suffers an untimely reboot, you > will have no transactionally safe record of the leases issued, when the > replacement comes up, or the DHCP server completes its reboot cycle. > > As a result, you can generate conflicting IP address assignments, unless you: > (a) Have an extremely short max lease duration (which can increase > DHCP server load), or > (b) Have a policy of pinging before assigning an IP, which limits DHCP server > performance and is not fool proof. > > -- > -JH > > _____ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog From mysidia at gmail.com Wed Jul 20 21:19:03 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 20 Jul 2011 21:19:03 -0500 Subject: CISCO IOS 12.x Virtual Switch In-Reply-To: <4E27786F.6060204@gmail.com> References: <4E27786F.6060204@gmail.com> Message-ID: On Wed, Jul 20, 2011 at 7:53 PM, Daniel Espejel wrote: > Thank you very much, now I'll try to perform some deployments over a > C3600 w/NS module. Unfortunately that is only a limited reproduction of what happens in a switch, making it a nice toy. Having an ability to simulate the execution of the IOS control software through CPU emulation is one thing; Real switches, including a real NM-16-ESW etherswitch module contain some proprietary hardware ASICs. RA guard, and similar functions are hardware features on switches that can sustain any sort of reasonable production load. GNS clearly tries to simulate the interface between a NM16ESW module and the host. But last I checked, no ASICs were being reverse-engineered for the benefit of GNS. Which would be one reason GNS cannot simulate Catalyst, and the reason NM16ESW is only simulated at a very high level. So, err, this is no replacement for testing RA guard on real hardware, sorry. > Daniel Espejel Perez -- -JH From joelja at bogus.com Wed Jul 20 21:35:15 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 20 Jul 2011 19:35:15 -0700 Subject: high performance open source DHCP solution? In-Reply-To: <3C2029CB-9EAE-4B22-B59C-92437FB86C74@delong.com> References: <3C2029CB-9EAE-4B22-B59C-92437FB86C74@delong.com> Message-ID: <649DECA0-C4A7-4234-A77D-433AB1BCF984@bogus.com> On Jul 20, 2011, at 6:25 PM, Owen DeLong wrote: > SSDs can be a good alternative these days as well. Some of them have gotten > to be quite fast. Sure, you'll have to replace them more often than spinning media, > but, Actually the the scale of writes associated with this application is unlikely to significantly impact the service life of an SLC nand ssd with a solid block shadowing/wear leveling implementation. back in 2007 I was convinced that we could improve on the reliability of our network appliances with industrial 2.5" sata and enterprise sas disks, and the situation has only improved since. > the write times can be quite a bit better. like orders of magnitude. > Owen > > On Jul 20, 2011, at 3:28 PM, Jimmy Hess wrote: > >> On Wed, Jul 20, 2011 at 9:31 AM, Nick Colton wrote: >>> We were seeing similar issues with low leases, moved the dhcpd.leases file >>> to a ramdisk and went from ~200 leases per second to something like 8,000 >>> leases per second. >> >> Yes, blame RFC2131's requirement that a DHCP server is to ensure that any >> lease is committed to persistent storage, strictly before a DHCP >> server is allowed to >> send the response to the request; a fully compliant DHCP server with >> sufficient traffic >> is bound by the disk I/O rate of underlying storage backing its database. >> >> I do not recommend use of a RAMDISK; it's safer to bend the rule than break it >> entirely; a safer way is probably to use a storage system on a battery-backed >> NVRAM cache that you configure to ignore SYNC() and lie to the DHCP server >> application, allowing the storage system to aggregate the I/O. >> >> >> Of course, committing to a RAMDISK tricks the DHCP server software. >> The danger is that if your DHCP server suffers an untimely reboot, you >> will have no transactionally safe record of the leases issued, when the >> replacement comes up, or the DHCP server completes its reboot cycle. >> >> As a result, you can generate conflicting IP address assignments, unless you: >> (a) Have an extremely short max lease duration (which can increase >> DHCP server load), or >> (b) Have a policy of pinging before assigning an IP, which limits DHCP server >> performance and is not fool proof. >> >> -- >> -JH >> >> _____ >> NANOG mailing list >> NANOG at nanog.org >> https://mailman.nanog.org/mailman/listinfo/nanog > > > _____ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > From nanog at magemojo.com Wed Jul 20 22:33:37 2011 From: nanog at magemojo.com (MageMojo) Date: Wed, 20 Jul 2011 23:33:37 -0400 Subject: bgp tools for route optmization based on(performance, cost and reliability Message-ID: <1f8901cc4756$fb7e9c00$f27bd400$@com> Hi all, Looking for tools to optimize bgp routes based on performance, cost and reliability. Paid, open source, doesn't matter. Even presentations or research papers on performing tasks are welcome. But not configuration guides on multihoming :) Specifically in the context of a hosting provider who's multihomed to several tier 1's. What tools do you use for such optimization and just every day maintenance? Eric From nanog at magemojo.com Wed Jul 20 22:35:05 2011 From: nanog at magemojo.com (MageMojo) Date: Wed, 20 Jul 2011 23:35:05 -0400 Subject: internap fcp competitors? Message-ID: <1f9401cc4757$300543c0$900fcb40$@com> Does anyone know of competitors to internap's fcp product? From eugen at leitl.org Thu Jul 21 01:41:38 2011 From: eugen at leitl.org (Eugen Leitl) Date: Thu, 21 Jul 2011 08:41:38 +0200 Subject: high performance open source DHCP solution? In-Reply-To: References: <4E2758B8.5080804@rainierconnect.net> <1D59D851-2A0E-4CED-BAA5-61FDFD3CF4D0@bogus.com> Message-ID: <20110721064138.GX16178@leitl.org> On Wed, Jul 20, 2011 at 05:17:55PM -0700, George Herbert wrote: > Micron has some large-cap SLC drives in the chain for > September/October/ish timeframes. > > Ramdisk with rsync or rdiffbackup to spinning storage will do just fine. Or hybrid zfs pools. -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE From greg at bestnet.kharkov.ua Thu Jul 21 01:52:54 2011 From: greg at bestnet.kharkov.ua (Gregory Edigarov) Date: Thu, 21 Jul 2011 09:52:54 +0300 Subject: internap fcp competitors? In-Reply-To: <1f9401cc4757$300543c0$900fcb40$@com> References: <1f9401cc4757$300543c0$900fcb40$@com> Message-ID: <20110721095254.034243c2@greg.bestnet.kharkov.ua> On Wed, 20 Jul 2011 23:35:05 -0400 "MageMojo" wrote: > Does anyone know of competitors to internap's fcp product? Also, I would greatly appreciate if anybody could explain what technically is internap fcp. -- With best regards, Gregory Edigarov From zaid at zaidali.com Thu Jul 21 02:16:07 2011 From: zaid at zaidali.com (Zaid Ali) Date: Thu, 21 Jul 2011 00:16:07 -0700 Subject: internap fcp competitors? In-Reply-To: <20110721095254.034243c2@greg.bestnet.kharkov.ua> References: <1f9401cc4757$300543c0$900fcb40$@com> <20110721095254.034243c2@greg.bestnet.kharkov.ua> Message-ID: On Jul 20, 2011, at 11:52 PM, Gregory Edigarov wrote: > On Wed, 20 Jul 2011 23:35:05 -0400 > "MageMojo" wrote: > >> Does anyone know of competitors to internap's fcp product? > Avaya/Route Science. I would check if this product is still sold by Avaya. Many moons ago I tested it. > Also, I would greatly appreciate if anybody could explain what > technically is internap fcp. > A box that can manipulate your outbound BGP routes since BGP doesn't take into consideration link congestion, delays etc. Zaid From nanog at magemojo.com Thu Jul 21 02:19:10 2011 From: nanog at magemojo.com (Eric Hileman) Date: Thu, 21 Jul 2011 03:19:10 -0400 Subject: internap fcp competitors? In-Reply-To: <20110721095254.034243c2@greg.bestnet.kharkov.ua> References: <1f9401cc4757$300543c0$900fcb40$@com> <20110721095254.034243c2@greg.bestnet.kharkov.ua> Message-ID: <200c01cc4776$7df82830$79e87890$@com> Internap's FCP is a bgp route optimizer. It connects to your network on the sideline and captures traffic either on a span/mirror port or by receiving flow data. Then based on your rules it probes to find the best routes and acting as route reflector will inject the routes to your network or just send you alerts and draw pretty pictures. Optimization can be for performance and/or cost. It also routes around issues like black holes. It's really only valuable when you're multihomed. The only competitor I'm aware of that is gone now was Avaya's RouteScience. There also exists a site packetdesign.com which *may* have a competing product. Here's the internap info: http://www.internap.com/business-internet-connectivity-services/route-optimi zation-flow-control/ -----Original Message----- From: Gregory Edigarov [mailto:greg at bestnet.kharkov.ua] Sent: Thursday, July 21, 2011 2:53 AM To: nanog at nanog.org Subject: Re: internap fcp competitors? On Wed, 20 Jul 2011 23:35:05 -0400 "MageMojo" wrote: > Does anyone know of competitors to internap's fcp product? Also, I would greatly appreciate if anybody could explain what technically is internap fcp. -- With best regards, Gregory Edigarov _____ NANOG mailing list NANOG at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog From paul4004 at gmail.com Thu Jul 21 02:42:00 2011 From: paul4004 at gmail.com (PC) Date: Thu, 21 Jul 2011 01:42:00 -0600 Subject: high performance open source DHCP solution? In-Reply-To: <20110721064138.GX16178@leitl.org> References: <4E2758B8.5080804@rainierconnect.net> <1D59D851-2A0E-4CED-BAA5-61FDFD3CF4D0@bogus.com> <20110721064138.GX16178@leitl.org> Message-ID: If you're just fighting IOPS, another compromise might be using a ramdisk, and then committing that data to storage every x seconds. Yes, you might be breaking the RFC, but depending on what it's used for, you could probably commit every 3-5 seconds without much penalty and limit your data loss potential on server failure. Or as others have said... some sort of SSD/cache solution. On Thu, Jul 21, 2011 at 12:41 AM, Eugen Leitl wrote: > On Wed, Jul 20, 2011 at 05:17:55PM -0700, George Herbert wrote: > > > Micron has some large-cap SLC drives in the chain for > > September/October/ish timeframes. > > > > Ramdisk with rsync or rdiffbackup to spinning storage will do just fine. > > Or hybrid zfs pools. > > -- > Eugen* Leitl leitl http://leitl.org > ______________________________________________________________ > ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org > 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE > > _____ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > From joe at ngn-networks.com Thu Jul 21 06:08:35 2011 From: joe at ngn-networks.com (Joe Freeman) Date: Thu, 21 Jul 2011 07:08:35 -0400 Subject: Looking for an AT&T contact that can update a prefix list Message-ID: <03e301cc4796$891dcd80$9b596880$@ngn-networks.com> If there's an AT&T contact on the list, or if anyone knows how to get a prefix filter updated, I'd appreciate a response. I put in a request for the update yesterday, and even called in to make sure they'd do it, but it's apparently not done yet, and I've had a customer down for hours waiting on it. Thanks- joe From asr at latency.net Thu Jul 21 08:21:45 2011 From: asr at latency.net (Adam Rothschild) Date: Thu, 21 Jul 2011 09:21:45 -0400 Subject: Looking for an AT&T contact that can update a prefix list In-Reply-To: <03e301cc4796$891dcd80$9b596880$@ngn-networks.com> References: <03e301cc4796$891dcd80$9b596880$@ngn-networks.com> Message-ID: On Thu, Jul 21, 2011 at 7:08 AM, Joe Freeman wrote: > If there's an AT&T contact on the list, or if anyone knows how to get a > prefix filter updated, I'd appreciate a response. You'll want to mail rm-awmis at ems.att.com, following up with a phone call to +1-888-613-6330,3,2 once you get an auto-responder providing a ticket number. > I put in a request for the update yesterday, and even called in to make sure > they'd do it, but it's apparently not done yet, and I've had a customer down > for hours waiting on it. These requests typically took a couple of weeks to process, with no support for IRR or other automation. (fair warning: this data is several years old, and might be dated) -a From cmorris at cs.odu.edu Thu Jul 21 10:03:23 2011 From: cmorris at cs.odu.edu (Charles Morris) Date: Thu, 21 Jul 2011 11:03:23 -0400 Subject: high performance open source DHCP solution? In-Reply-To: <20110721064138.GX16178@leitl.org> References: <4E2758B8.5080804@rainierconnect.net> <1D59D851-2A0E-4CED-BAA5-61FDFD3CF4D0@bogus.com> <20110721064138.GX16178@leitl.org> Message-ID: On Thu, Jul 21, 2011 at 2:41 AM, Eugen Leitl wrote: > On Wed, Jul 20, 2011 at 05:17:55PM -0700, George Herbert wrote: > >> Micron has some large-cap SLC drives in the chain for >> September/October/ish timeframes. >> >> Ramdisk with rsync or rdiffbackup to spinning storage will do just fine. > > Or hybrid zfs pools. > +1 From JTyler at fiberutilities.com Thu Jul 21 11:31:52 2011 From: JTyler at fiberutilities.com (Jensen Tyler) Date: Thu, 21 Jul 2011 11:31:52 -0500 Subject: slides missing from NANOG52 page? In-Reply-To: References: Message-ID: <1A8A762BD508624A8BDAB9F5E1638F945FB7FDE2ED@comsrv01.fg.local> Looks like all the slides are missing. Jensen Tyler Sr Engineering Manager Fiberutilities Group, LLC -----Original Message----- From: Matthew Petach [mailto:mpetach at netflight.com] Sent: Wednesday, July 20, 2011 8:23 PM To: nanog at nanog.org Subject: slides missing from NANOG52 page? Anyone know what happened to the slide decks from the most recent NANOG? They used to be linked off http://www.nanog.org/meetings/nanog52/agenda.php but seem to have gone missing. :( Thanks! Matt _____ NANOG mailing list NANOG at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog From ncolton at allophone.net Thu Jul 21 12:34:53 2011 From: ncolton at allophone.net (Nick Colton) Date: Thu, 21 Jul 2011 11:34:53 -0600 Subject: high performance open source DHCP solution? In-Reply-To: References: <4E2758B8.5080804@rainierconnect.net> <1D59D851-2A0E-4CED-BAA5-61FDFD3CF4D0@bogus.com> <20110721064138.GX16178@leitl.org> Message-ID: I should have given more information, we do ramdisk with rsync backups and have been running this way for over 2 years without any issues/lost leases. Nick Colton Allo Communications On Thu, Jul 21, 2011 at 9:03 AM, Charles Morris wrote: > On Thu, Jul 21, 2011 at 2:41 AM, Eugen Leitl wrote: > > On Wed, Jul 20, 2011 at 05:17:55PM -0700, George Herbert wrote: > > > >> Micron has some large-cap SLC drives in the chain for > >> September/October/ish timeframes. > >> > >> Ramdisk with rsync or rdiffbackup to spinning storage will do just fine. > > > > Or hybrid zfs pools. > > > > +1 > > _____ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > From betty at newnog.org Thu Jul 21 13:54:18 2011 From: betty at newnog.org (Betty Burke) Date: Thu, 21 Jul 2011 14:54:18 -0400 Subject: Problems with the NANOG Meeting Archives Message-ID: Colleagues: Unfortunately, it is true the archives are not working properly. As part of the NANOG Service transition, the code which supports the meeting(s) presentation archive stopped working. We have all the data, and staff are currently working quickly to repair the code and return to normal operations of the archive. We understand the importance of the NANOG meeting history, and are sorry for the delay in access. I do not yet have an eta, however I will be sure to keep the community posted. Please accept my apology for the interruption. Betty -- Betty Burke NewNOG/NANOG Executive Director Office (810) 214-1218 From wavetossed at googlemail.com Thu Jul 21 17:33:45 2011 From: wavetossed at googlemail.com (Michael Dillon) Date: Thu, 21 Jul 2011 15:33:45 -0700 Subject: OT: Given what you know now, if you were 21 again... In-Reply-To: References: Message-ID: On 13 July 2011 14:08, Larry Stites wrote: > Given what you know now, if you were 21 and just starting into networking / > communications industry which areas of study or specialty would you > prioritize? Number 1 - Learn how to learn. If you can't already do what Scott Young does, then start with this URL and check out some of the other content on that site Number 2 is to learn how to set up a comprehensive virtualized test lab, and build complex networks on that. A lot of real-world router/switch software can run on virtual environments like Dynamips so you have a chance to dig in fairly deeply for little money. Number 3 is to leverage Ebay to buy old (and really cheap) routers and switches. Only buy the really cheap stuff because it will be old and broken in some way. Don't buy dead boxes, but the really cheap stuff might not even have IP on it, or it might be a really old and limited and buggy version. Make it work as best you can. Using version numbers, find out what bugs exist in a particular box, and see if you can trigger the bug and/or shield the box from harm. This is not only a good mental exercise but will give your knowledge some depth of experience that most existing people have, but which very few newcomers will ever get. Fact is that technology is still changing rapidly and you will need to constantly be learning new stuff so make sure you do the same. That's why number one above is so important. Don't specialize. Just follow what interests you and try to avoid getting over specialized because things change and it is hard to predict which specialties will be in demand in the future. But people who can think on their feet, have hands-on experience and are willing to do whatever needs doing today; those people will always in demand. P.S. you might also want to look into buying some microcontrollers and FPGAs, and building your own data comm protocols from scratch. Don't write a TCP/IP stack at first, but roll your own. Then if you happen across an old token-ring only router, see if you can build an interface to bridge it with Ethernet. From mksmith at adhost.com Fri Jul 22 11:16:27 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Fri, 22 Jul 2011 16:16:27 +0000 Subject: NANOG List change schedule Message-ID: Hello Everyone: We have tested successfully the Mailman configuration on the new server and are ready to proceed with moving the various NANOG lists over to that server using the following schedule. At approximately 12:00 PDT on Monday, July 25th we will move DNS over for mailman.nanog.org to the new server. We will disable Mailman on the old server simultaneously, so some users may experience delivery issues to the list while DNS propagates. We've set the TTL on the domain to 5 minutes in an effort to minimize propagation delays. For your reference, the new IP's are: 204.93.212.138 2001:1838::cc5d:d48a Thank you to everyone that participated in the list test over the past week. The testing process was instrumental in getting the server configured and making sure everything will work as expected. I will announce to the list when we're making the change and again when it's complete. If you are experiencing issues with list delivery, please send email to me directly, as the admins at nanog.org may not be available for you. -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) From cscora at apnic.net Fri Jul 22 14:06:01 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 23 Jul 2011 05:06:01 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201107221906.p6MJ61cQ017997@thyme.rand.apnic.net> 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, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 23 Jul, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 364842 Prefixes after maximum aggregation: 165720 Deaggregation factor: 2.20 Unique aggregates announced to Internet: 180824 Total ASes present in the Internet Routing Table: 38262 Prefixes per ASN: 9.54 Origin-only ASes present in the Internet Routing Table: 31794 Origin ASes announcing only one prefix: 15298 Transit ASes present in the Internet Routing Table: 5199 Transit-only ASes present in the Internet Routing Table: 137 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 34 Max AS path prepend of ASN (22394) 31 Prefixes from unregistered ASNs in the Routing Table: 938 Unregistered ASNs in the Routing Table: 547 Number of 32-bit ASNs allocated by the RIRs: 1585 Number of 32-bit ASNs visible in the Routing Table: 1269 Prefixes from 32-bit ASNs in the Routing Table: 2925 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 119 Number of addresses announced to Internet: 2484169792 Equivalent to 148 /8s, 17 /16s and 108 /24s Percentage of available address space announced: 67.0 Percentage of allocated address space announced: 67.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 91.1 Total number of prefixes smaller than registry allocations: 152116 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 91236 Total APNIC prefixes after maximum aggregation: 30391 APNIC Deaggregation factor: 3.00 Prefixes being announced from the APNIC address blocks: 87829 Unique aggregates announced from the APNIC address blocks: 37449 APNIC Region origin ASes present in the Internet Routing Table: 4523 APNIC Prefixes per ASN: 19.42 APNIC Region origin ASes announcing only one prefix: 1257 APNIC Region transit ASes present in the Internet Routing Table: 715 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 18 Number of APNIC region 32-bit ASNs visible in the Routing Table: 62 Number of APNIC addresses announced to Internet: 622384672 Equivalent to 37 /8s, 24 /16s and 214 /24s Percentage of available APNIC address space announced: 78.9 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 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, 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: 141810 Total ARIN prefixes after maximum aggregation: 73186 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 113679 Unique aggregates announced from the ARIN address blocks: 46646 ARIN Region origin ASes present in the Internet Routing Table: 14515 ARIN Prefixes per ASN: 7.83 ARIN Region origin ASes announcing only one prefix: 5568 ARIN Region transit ASes present in the Internet Routing Table: 1533 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 34 Number of ARIN region 32-bit ASNs visible in the Routing Table: 13 Number of ARIN addresses announced to Internet: 802761344 Equivalent to 47 /8s, 217 /16s and 42 /24s Percentage of available ARIN address space announced: 63.8 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, 393216-394239 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, 173/8, 174/8, 184/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: 86532 Total RIPE prefixes after maximum aggregation: 49288 RIPE Deaggregation factor: 1.76 Prefixes being announced from the RIPE address blocks: 79915 Unique aggregates announced from the RIPE address blocks: 52946 RIPE Region origin ASes present in the Internet Routing Table: 15807 RIPE Prefixes per ASN: 5.06 RIPE Region origin ASes announcing only one prefix: 7879 RIPE Region transit ASes present in the Internet Routing Table: 2501 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 920 Number of RIPE addresses announced to Internet: 483952000 Equivalent to 28 /8s, 216 /16s and 133 /24s Percentage of available RIPE address space announced: 78.0 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 196608-198655 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, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 33807 Total LACNIC prefixes after maximum aggregation: 7644 LACNIC Deaggregation factor: 4.42 Prefixes being announced from the LACNIC address blocks: 32925 Unique aggregates announced from the LACNIC address blocks: 17088 LACNIC Region origin ASes present in the Internet Routing Table: 1487 LACNIC Prefixes per ASN: 22.14 LACNIC Region origin ASes announcing only one prefix: 442 LACNIC Region transit ASes present in the Internet Routing Table: 275 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 19 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 270 Number of LACNIC addresses announced to Internet: 86429952 Equivalent to 5 /8s, 38 /16s and 209 /24s Percentage of available LACNIC address space announced: 57.2 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 8356 Total AfriNIC prefixes after maximum aggregation: 1975 AfriNIC Deaggregation factor: 4.23 Prefixes being announced from the AfriNIC address blocks: 6537 Unique aggregates announced from the AfriNIC address blocks: 1997 AfriNIC Region origin ASes present in the Internet Routing Table: 475 AfriNIC Prefixes per ASN: 13.76 AfriNIC Region origin ASes announcing only one prefix: 152 AfriNIC Region transit ASes present in the Internet Routing Table: 101 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 4 Number of AfriNIC addresses announced to Internet: 24441856 Equivalent to 1 /8s, 116 /16s and 244 /24s Percentage of available AfriNIC address space announced: 36.4 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2470 11044 938 Korea Telecom (KIX) 17974 1794 508 32 PT TELEKOMUNIKASI INDONESIA 7545 1555 301 85 TPG Internet Pty Ltd 4755 1507 635 171 TATA Communications formerly 7552 1298 1064 7 Vietel Corporation 24560 1156 336 187 Bharti Airtel Ltd., Telemedia 9829 1108 923 47 BSNL National Internet Backbo 9583 1079 81 520 Sify Limited 4808 1051 2092 299 CNCGROUP IP network: China169 17488 967 187 107 Hathway IP Over Cable Interne 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 6389 3616 3818 238 bellsouth.net, inc. 18566 1913 365 241 Covad Communications 1785 1811 681 122 PaeTec Communications, Inc. 4323 1615 1082 401 Time Warner Telecom 20115 1590 1538 623 Charter Communications 19262 1411 4760 391 Verizon Global Networks 7018 1364 7069 891 AT&T WorldNet Services 22773 1353 2897 89 Cox Communications, Inc. 7029 1293 791 304 Windstream Communications Inc 2386 1258 520 907 AT&T Data Communications Serv 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 34984 534 106 185 BILISIM TELEKOM 6830 512 1788 316 UPC Distribution Services 3292 468 2078 403 TDC Tele Danmark 20940 459 132 354 Akamai Technologies European 12479 455 593 7 Uni2 Autonomous System 8866 453 133 26 Bulgarian Telecommunication C 29049 432 32 47 AzerSat LLC. 3320 424 8151 370 Deutsche Telekom AG 8551 403 354 44 Bezeq International 702 397 1802 310 UUNET - Commercial IP service 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 1559 287 163 TVCABLE BOGOTA 8151 1420 2746 351 UniNet S.A. de C.V. 28573 1277 995 78 NET Servicos de Comunicao S.A 7303 1009 513 178 Telecom Argentina Stet-France 6503 750 354 74 AVANTEL, S.A. 14420 700 56 85 CORPORACION NACIONAL DE TELEC 22047 578 322 17 VTR PUNTO NET S.A. 3816 532 232 97 Empresa Nacional de Telecomun 7738 516 986 31 Telecomunicacoes da Bahia S.A 27947 509 53 53 Telconet S.A 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 8452 817 445 11 TEDATA 24863 794 147 42 LINKdotNET AS number 15475 512 74 8 Nile Online 36992 315 415 15 Etisalat MISR 24835 304 78 10 RAYA Telecom - Egypt 3741 265 937 226 The Internet Solution 6713 241 215 13 Itissalat Al-MAGHRIB 33776 226 13 5 Starcomms Nigeria Limited 15706 158 32 6 Sudatel Internet Exchange Aut 29571 158 17 11 Ci Telecom Autonomous system 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 6389 3616 3818 238 bellsouth.net, inc. 23456 2925 710 1575 32-bit ASN transition 4766 2470 11044 938 Korea Telecom (KIX) 18566 1913 365 241 Covad Communications 1785 1811 681 122 PaeTec Communications, Inc. 17974 1794 508 32 PT TELEKOMUNIKASI INDONESIA 4323 1615 1082 401 Time Warner Telecom 20115 1590 1538 623 Charter Communications 10620 1559 287 163 TVCABLE BOGOTA 7545 1555 301 85 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 17974 1794 1762 PT TELEKOMUNIKASI INDONESIA 1785 1811 1689 PaeTec Communications, Inc. 18566 1913 1672 Covad Communications 4766 2470 1532 Korea Telecom (KIX) 7545 1555 1470 TPG Internet Pty Ltd 10620 1559 1396 TVCABLE BOGOTA 23456 2925 1350 32-bit ASN transition 4755 1507 1336 TATA Communications formerly 7552 1298 1291 Vietel Corporation 22773 1353 1264 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.225.128.0/18 36377 Comcast Telecommunications, I 24.225.192.0/23 36377 Comcast Telecommunications, I 24.225.192.0/18 36377 Comcast Telecommunications, I 24.225.224.0/21 36377 Comcast Telecommunications, I 24.225.237.0/24 36377 Comcast Telecommunications, I 24.225.248.0/21 36377 Comcast Telecommunications, I 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 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:20 /9:12 /10:27 /11:80 /12:232 /13:465 /14:798 /15:1400 /16:12040 /17:5888 /18:9829 /19:19533 /20:26166 /21:26261 /22:34965 /23:33886 /24:189915 /25:1093 /26:1269 /27:739 /28:207 /29:9 /30:2 /31:0 /32:6 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2236 3616 bellsouth.net, inc. 18566 1869 1913 Covad Communications 10620 1454 1559 TVCABLE BOGOTA 23456 1446 2925 32-bit ASN transition 11492 1096 1142 Cable One 7011 1056 1158 Citizens Utilities 1785 1054 1811 PaeTec Communications, Inc. 7029 1040 1293 Windstream Communications Inc 6478 997 1025 AT&T Worldnet Services 22773 868 1353 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:331 2:45 4:16 5:1 6:3 8:340 12:1965 13:1 14:490 15:15 16:3 17:5 20:10 23:14 24:1680 27:842 31:504 32:64 33:4 34:2 36:4 38:730 40:104 41:2603 42:35 44:3 46:1043 47:3 49:198 50:383 52:13 54:2 55:7 56:2 57:35 58:860 59:481 60:385 61:1181 62:1033 63:1932 64:3990 65:2299 66:3882 67:1886 68:1109 69:3060 70:778 71:373 72:1865 74:2431 75:333 76:341 77:881 78:704 79:463 80:1114 81:839 82:497 83:465 84:691 85:1057 86:519 87:764 88:333 89:1533 90:224 91:3957 92:526 93:1054 94:1338 95:859 96:419 97:263 98:891 99:37 101:77 103:140 106:73 107:24 108:73 109:1022 110:612 111:714 112:305 113:413 114:555 115:683 116:984 117:690 118:863 119:1174 120:315 121:676 122:1607 123:976 124:1304 125:1279 128:246 129:171 130:169 131:578 132:113 133:21 134:214 135:52 136:215 137:138 138:300 139:116 140:477 141:253 142:403 143:414 144:478 145:54 146:454 147:216 148:672 149:249 150:159 151:189 152:338 153:182 154:5 155:397 156:199 157:351 158:140 159:455 160:315 161:203 162:310 163:166 164:506 165:367 166:531 167:433 168:740 169:153 170:849 171:80 172:1 173:1619 174:628 175:384 176:143 177:170 178:1005 180:907 181:23 182:508 183:234 184:345 185:1 186:1308 187:776 188:896 189:946 190:5000 192:5913 193:4972 194:3517 195:3018 196:1291 197:42 198:3573 199:3977 200:5573 201:1473 202:8416 203:8448 204:4229 205:2331 206:2669 207:2808 208:3989 209:3434 210:2680 211:1452 212:2087 213:1743 214:769 215:70 216:4951 217:1650 218:545 219:348 220:1201 221:495 222:360 223:220 End of report From bzeeb-lists at lists.zabbadoz.net Fri Jul 22 14:10:09 2011 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Fri, 22 Jul 2011 19:10:09 +0000 Subject: NANOG List change schedule In-Reply-To: References: Message-ID: <71C2A416-05B8-4094-9A2A-B900E52CBF00@lists.zabbadoz.net> On Jul 22, 2011, at 4:16 PM, Michael K. Smith - Adhost wrote: > Hello Everyone: > > We have tested successfully the Mailman configuration on the new server and are ready to proceed with moving the various NANOG lists over to that server using the following schedule. At approximately 12:00 PDT on Monday, July 25th we will move DNS over for mailman.nanog.org to the new server. We will disable Mailman on the old server simultaneously, so some users may experience delivery issues to the list while DNS propagates. We've set the TTL on the domain to 5 minutes in an effort to minimize propagation delays. > > For your reference, the new IP's are: > > 204.93.212.138 > 2001:1838::cc5d:d48a Fix reverse mapping, especially for IPv6, before activating or you'll get bounces. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From mikevs at xs4all.net Fri Jul 22 14:23:58 2011 From: mikevs at xs4all.net (Miquel van Smoorenburg) Date: Fri, 22 Jul 2011 21:23:58 +0200 Subject: high performance open source DHCP solution? In-Reply-To: References: Message-ID: <201107221923.p6MJNwGA012953@xs8.xs4all.nl> In article you write: >On Wed, Jul 20, 2011 at 9:31 AM, Nick Colton wrote: >> We were seeing similar issues with low leases, moved the dhcpd.leases file >> to a ramdisk and went from ~200 leases per second to something like 8,000 >> leases per second. > >Yes, blame RFC2131's requirement that a DHCP server is to ensure that any >lease is committed to persistent storage, strictly before a DHCP >server is allowed to >send the response to the request; a fully compliant DHCP server with >sufficient traffic >is bound by the disk I/O rate of underlying storage backing its database. Well, that's easily fixed (if the architecture of the server allows it): just queue up but don't send out the replies, then every 10ms sync the changes to the filesystem and then send out the replies. "fsync batching". Perhaps someone should suggest this to the ISC DHCPD developers. Mike. From bicknell at ufp.org Fri Jul 22 14:35:33 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 22 Jul 2011 12:35:33 -0700 Subject: high performance open source DHCP solution? In-Reply-To: <201107221923.p6MJNwGA012953@xs8.xs4all.nl> References: <201107221923.p6MJNwGA012953@xs8.xs4all.nl> Message-ID: <20110722193533.GA24385@ussenterprise.ufp.org> In a message written on Fri, Jul 22, 2011 at 09:23:58PM +0200, Miquel van Smoorenburg wrote: > Perhaps someone should suggest this to the ISC DHCPD developers. ./configure --enable-delayed-ack Note, I've never used it, but it does what you describe. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From cidr-report at potaroo.net Fri Jul 22 17:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 22 Jul 2011 22:00:00 GMT Subject: BGP Update Report Message-ID: <201107222200.p6MM00xU090791@wattle.apnic.net> BGP Update Report Interval: 14-Jul-11 -to- 21-Jul-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23966 72281 5.2% 213.8 -- LDN-AS-PK LINKdotNET Telecom Limited 2 - AS9829 47951 3.4% 77.6 -- BSNL-NIB National Internet Backbone 3 - AS17974 23081 1.6% 14.0 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 4 - AS2697 16432 1.2% 88.8 -- ERX-ERNET-AS Education and Research Network 5 - AS9498 15574 1.1% 21.5 -- BBIL-AP BHARTI Airtel Ltd. 6 - AS6316 13866 1.0% 513.6 -- AS-PAETEC-NET - PaeTec Communications, Inc. 7 - AS45595 12885 0.9% 61.7 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited 8 - AS9198 11562 0.8% 39.1 -- KAZTELECOM-AS JSC Kazakhtelecom 9 - AS11492 11206 0.8% 26.2 -- CABLEONE - CABLE ONE, INC. 10 - AS5434 10447 0.8% 84.2 -- NURSAT-ALA-AS Nursat-Almaty 11 - AS9874 10116 0.7% 158.1 -- STARHUB-IX StarHub Broadband 12 - AS7552 9691 0.7% 7.8 -- VIETEL-AS-AP Vietel Corporation 13 - AS24560 9431 0.7% 8.3 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 14 - AS5800 9072 0.7% 51.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 15 - AS32528 8878 0.6% 1775.6 -- ABBOTT Abbot Labs 16 - AS35819 8482 0.6% 23.4 -- MOBILY-AS Etihad Etisalat Company (Mobily) 17 - AS28573 7658 0.6% 11.7 -- NET Servicos de Comunicao S.A. 18 - AS3454 7512 0.5% 2504.0 -- Universidad Autonoma de Nuevo Leon 19 - AS44609 7481 0.5% 2493.7 -- FNA Fars News Agency Cultural Arts Institute 20 - AS28885 7204 0.5% 62.6 -- OMANTEL-NAP-AS OmanTel NAP TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS3454 7512 0.5% 2504.0 -- Universidad Autonoma de Nuevo Leon 2 - AS44609 7481 0.5% 2493.7 -- FNA Fars News Agency Cultural Arts Institute 3 - AS56276 2158 0.1% 2158.0 -- NEWEDGE-AS-HK Asia-Pacific, China, Hong Kong 4 - AS32528 8878 0.6% 1775.6 -- ABBOTT Abbot Labs 5 - AS3 1159 0.1% 735.0 -- FROMTHEBENCH-AS From the Bench, S.L. 6 - AS27322 870 0.1% 870.0 -- ISC-JNB1 Internet Systems Consortium, Inc. 7 - AS46778 858 0.1% 858.0 -- PHSI-1996 - Prevea Health Services Inc 8 - AS34654 1660 0.1% 830.0 -- IONIC-AS Ionic Information Limited 9 - AS17408 3265 0.2% 816.2 -- ABOVE-AS-AP AboveNet Communications Taiwan 10 - AS6256 2974 0.2% 743.5 -- ALLTEL - ALLTEL Corporation 11 - AS3 1376 0.1% 559.0 -- FROMTHEBENCH-AS From the Bench, S.L. 12 - AS26001 1886 0.1% 628.7 -- BLUIP - BLUIP INC 13 - AS38004 616 0.0% 616.0 -- FASTLINK-ISP FastLink Wireless ISP, DrukCom Pvt. Enterprise. 14 - AS44145 551 0.0% 551.0 -- PRINTDESIGN-AS Print and Design LTD 15 - AS6316 13866 1.0% 513.6 -- AS-PAETEC-NET - PaeTec Communications, Inc. 16 - AS33314 495 0.0% 495.0 -- VCC - Vancouver Community College 17 - AS24534 477 0.0% 477.0 -- TRANSHYBRID-AS-ID PT. Transhybrid Communication 18 - AS49987 442 0.0% 442.0 -- SPARK-AS Stroy Park - R Ltd 19 - AS22793 439 0.0% 439.0 -- CASSOCORP - CASSO Corporation 20 - AS48068 426 0.0% 426.0 -- VISONIC Visonic Ltd TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.92.235.0/24 10109 0.7% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 2 - 200.23.202.0/24 7496 0.5% AS3454 -- Universidad Autonoma de Nuevo Leon 3 - 178.22.72.0/21 7335 0.5% AS44609 -- FNA Fars News Agency Cultural Arts Institute 4 - 66.248.104.0/21 6322 0.4% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 5 - 66.248.120.0/21 5848 0.4% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 6 - 193.8.250.0/24 5147 0.3% AS35753 -- ITC ITC AS number AS41176 -- SAHARANET-AS Sahara Net Main NOC AS 7 - 202.54.86.0/24 4996 0.3% AS4755 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 8 - 202.41.70.0/24 4440 0.3% AS2697 -- ERX-ERNET-AS Education and Research Network 9 - 130.36.34.0/24 4439 0.3% AS32528 -- ABBOTT Abbot Labs 10 - 130.36.35.0/24 4436 0.3% AS32528 -- ABBOTT Abbot Labs 11 - 202.147.165.0/24 3311 0.2% AS23966 -- LDN-AS-PK LINKdotNET Telecom Limited 12 - 202.153.174.0/24 3262 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 13 - 210.2.155.0/24 2879 0.2% AS23966 -- LDN-AS-PK LINKdotNET Telecom Limited 14 - 14.139.34.0/24 2863 0.2% AS55824 -- RSMANI-NKN-AS-AP National Knowledge Network 15 - 202.147.162.0/24 2763 0.2% AS23966 -- LDN-AS-PK LINKdotNET Telecom Limited 16 - 210.2.148.0/24 2614 0.2% AS23966 -- LDN-AS-PK LINKdotNET Telecom Limited 17 - 202.147.170.0/24 2554 0.2% AS23966 -- LDN-AS-PK LINKdotNET Telecom Limited 18 - 202.147.171.0/24 2553 0.2% AS23966 -- LDN-AS-PK LINKdotNET Telecom Limited 19 - 210.2.153.0/24 2548 0.2% AS23966 -- LDN-AS-PK LINKdotNET Telecom Limited 20 - 210.2.151.0/24 2547 0.2% AS23966 -- LDN-AS-PK LINKdotNET Telecom Limited Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jul 22 17:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 22 Jul 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201107222200.p6MM00nj090784@wattle.apnic.net> This report has been generated at Fri Jul 22 21:12:18 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 15-07-11 366674 216447 16-07-11 367236 216280 17-07-11 367137 216162 18-07-11 366829 216328 19-07-11 367058 216488 20-07-11 367348 216734 21-07-11 367629 216881 22-07-11 367495 217232 AS Summary 38392 Number of ASes in routing system 16203 Number of ASes announcing only one prefix 3616 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 109818080 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 22Jul11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 368274 217251 151023 41.0% All ASes AS6389 3616 242 3374 93.3% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4766 2470 956 1514 61.3% KIXS-AS-KR Korea Telecom AS18566 1913 497 1416 74.0% COVAD - Covad Communications Co. AS4755 1504 216 1288 85.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1353 98 1255 92.8% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4323 1616 403 1213 75.1% TWTC - tw telecom holdings, inc. AS1785 1814 767 1047 57.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS19262 1411 391 1020 72.3% VZGNI-TRANSIT - Verizon Online LLC AS10620 1559 622 937 60.1% Telmex Colombia S.A. AS28573 1277 386 891 69.8% NET Servicos de Comunicao S.A. AS7552 1298 408 890 68.6% VIETEL-AS-AP Vietel Corporation AS7545 1555 712 843 54.2% TPG-INTERNET-AP TPG Internet Pty Ltd AS18101 933 145 788 84.5% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS24560 1157 380 777 67.2% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS8151 1431 673 758 53.0% Uninet S.A. de C.V. AS4808 1054 335 719 68.2% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7303 1013 332 681 67.2% Telecom Argentina S.A. AS3356 1118 459 659 58.9% LEVEL3 Level 3 Communications AS17488 967 328 639 66.1% HATHWAY-NET-AP Hathway IP Over Cable Internet AS14420 700 89 611 87.3% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS20115 1590 983 607 38.2% CHARTER-NET-HKY-NC - Charter Communications AS22561 964 362 602 62.4% DIGITAL-TELEPORT - Digital Teleport Inc. AS17676 672 71 601 89.4% GIGAINFRA Softbank BB Corp. AS3549 998 428 570 57.1% GBLX Global Crossing Ltd. AS17974 1794 1229 565 31.5% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS4804 642 86 556 86.6% MPX-AS Microplex PTY LTD AS22047 578 32 546 94.5% VTR BANDA ANCHA S.A. AS7011 1158 623 535 46.2% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS4780 751 220 531 70.7% SEEDNET Digital United Inc. AS9443 568 76 492 86.6% INTERNETPRIMUS-AS-AP Primus Telecommunications Total 39474 12549 26925 68.2% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 93.180.88.0/21 AS42410 PTP-AS Point To Point Ltd. AS 93.180.96.0/19 AS42431 B-NET BiConsult Eood 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 116.193.152.0/24 AS55536 MIHK-HK Pacswitch Globe Telecom 116.193.153.0/24 AS55536 MIHK-HK Pacswitch Globe Telecom 116.193.154.0/24 AS55536 MIHK-HK Pacswitch Globe Telecom 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 181.82.15.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.16.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.17.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 181.82.18.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 191.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 193.111.87.0/24 AS24812 197.156.0.0/18 AS37253 ATC 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.24.76.0/24 AS7195 Telecorp Colombia S.A. 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.58.101.0/24 AS45645 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.63.80.0/24 AS9557 PKTELECOM-AS-PK Paknet Limited Merged into PTCL 202.74.232.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.74.233.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.160.152.0/22 AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.18.156.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.72.192.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.194.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.10.235.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From nanog at magemojo.com Fri Jul 22 17:21:34 2011 From: nanog at magemojo.com (Eric Hileman) Date: Fri, 22 Jul 2011 18:21:34 -0400 Subject: Cisco Performance Routing (PfR) Message-ID: <00b501cc48bd$b8973d80$29c5b880$@com> Is anyone using Cisco Performance Routing (PfR) in a service provider setting to optimize eBGP routing? If so, could you share your experience? From kelly at hawknetworks.com Fri Jul 22 18:36:21 2011 From: kelly at hawknetworks.com (Kelly Kane) Date: Fri, 22 Jul 2011 16:36:21 -0700 Subject: Looking for a reliable server technician in Amsterdam Message-ID: Hello! We are on the hunt for a reliable server technician in Amsterdam, NL who can travel to Equinix AM1 every other week. They must be able to: 1. Follow instructions. 2. Perform basic server repair. RAM, hard drives, addon cards. No motherboards, CPUs, or other "complicated" devices. 3. Know basic care over electronic devices* 4. Speak some amount of English. A perk would be basic knowledge of how to install SFP's, fiber, and line cards in a router given explicit instructions or basic knowledge of Linux. Thank you, Kelly * We received a box of 20ish bare hard drives 'packed' in few air cushions. Fedex called to tell us they were delivering a box of broken dishes. From chaz at chaz6.com Sat Jul 23 03:27:53 2011 From: chaz at chaz6.com (Chris Hills) Date: Sat, 23 Jul 2011 09:27:53 +0100 Subject: 32 and directallocate In-Reply-To: <4E24EF43.8010001@2mbit.com> References: <4E24EF43.8010001@2mbit.com> Message-ID: On 19/07/2011 03:43, Brielle Bruns wrote: > On 7/18/11 7:02 PM, Deric Kwok wrote: >> Hi >> >> I have the following questions. hope you can help >> >> 1/ In ipv6 /32. ls it same as ipv4 /32 > > No. It depends how you define it. If you mean the number of bits in the network mask, then yes it is the same. If it is the size of the network, then it is not the same. From list-nanog2 at dragon.net Sat Jul 23 10:44:25 2011 From: list-nanog2 at dragon.net (Paul Ebersman) Date: Sat, 23 Jul 2011 08:44:25 -0700 Subject: best practices for management nets in IPv6 In-Reply-To: <6EFFEFBAC68377459A2E972105C759EC03D367A1@EXVBE005-2.exch005intermedia.net> References: <4E249E92.8070608@dougbarton.us> <6EFFEFBAC68377459A2E972105C759EC03D3679F@EXVBE005-2.exch005intermedia.net> <000001cc45cd$28587600$79096200$@iname.com> <6EFFEFBAC68377459A2E972105C759EC03D367A1@EXVBE005-2.exch005intermedia.net> Message-ID: ryan> We keep running into problem with our IPv6 roll out. I just ryan> confirmed today that Exchange does not fully support IPv6 [...] ryan> Yes sorry Exchange 2010 - OCS, Lync, Exchange UM - these require ryan> IPv4 It's a hack (but all ipv6 transition stuff is...) but have you tried using ipv6-literal.net for the apps that don't work with ipv6 yet? # Support for ipv6-literal.net Names Windows Vista and Windows Server 2008 support the use of IPv6Address.ivp6-literal.net names. An ipv6-literal.net name can be used in services or applications that do not recognize the syntax of normal IPv6 addresses. To specify an IPv6 address within the ipv6-literal.net name, convert the colons (:) in the address to dashes (-). For example, for the IPv6 address 2001:db8:28:3:f98a:5b31:67b7:67ef, the corresponding ipv6-literal.net name is 2001-db8-28-3-f98a-5b31-67b7-67ef.ipv6-literal.net. To specify a zone ID (also known as a scope ID), replace the "%" used to separate the IPv6 address from the zone ID with an "s". For example to specify the destination fe80::218:8bff:fe17:a226%4, the name is fe80--218-8bff-fe17-a226s4.ipv6-literal.net. You can use an ipv6-literal.net name in the computer name part of a Universal Naming Convention (UNC) path. For example, to specify the Docs share of the computer with the IPv6 address of 2001:db8:28:3:f98a:5b31:67b7:67ef, use the UNC path \\2001-db8-28-3-f98a-5b31-67b7-67ef.ipv6-literal.net\docs. From jeroen at unfix.org Sat Jul 23 15:02:45 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Sat, 23 Jul 2011 22:02:45 +0200 Subject: best practices for management nets in IPv6 In-Reply-To: <201107231547.p6NFlBOb009042@denue01.paphosting.net> References: <4E249E92.8070608@dougbarton.us> <6EFFEFBAC68377459A2E972105C759EC03D3679F@EXVBE005-2.exch005intermedia.net> <000001cc45cd$28587600$79096200$@iname.com> <6EFFEFBAC68377459A2E972105C759EC03D367A1@EXVBE005-2.exch005intermedia.net> <201107231547.p6NFlBOb009042@denue01.paphosting.net> Message-ID: <4E2B28E5.5090605@unfix.org> On 2011-07-23 17:44 , Paul Ebersman wrote: > > ryan> We keep running into problem with our IPv6 roll out. I just > ryan> confirmed today that Exchange does not fully support IPv6 > [...] > ryan> Yes sorry Exchange 2010 - OCS, Lync, Exchange UM - these require > ryan> IPv4 > > It's a hack (but all ipv6 transition stuff is...) but have you tried > using ipv6-literal.net for the apps that don't work with ipv6 yet? That only helps you in situations where entering an IPv6 is unsupported because the parser chokes on the ':' or does not support scope identifiers. The app itself still needs to resolve that literal using getaddrinfo() into a valid IPv6 address (and scope-id) for it to make any sense of it. For apps that don't support IPv6 the only way you are (likely) getting them to to talk to IPv6 capable services is to proxy them. Good old SOCKS is a great one there and otherwise one of the various TCP forwarders (on windows one can use: netsh interface portproxy add v4tov6 listenport=80 connectaddress=theipv6nox connectport=80) Greets, Jeroen From rbonica at juniper.net Sun Jul 24 08:29:00 2011 From: rbonica at juniper.net (Ronald Bonica) Date: Sun, 24 Jul 2011 09:29:00 -0400 Subject: From Quebec Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F431CD40@EMBX01-WF.jnpr.net> Hi Folks, I arrived in Quebec at about midnight last night. (United is always late). Dorothy, the VIRTUS forms are on the printer. Please have Amanda fill them out immediately. Ask Dylan if he is willing to help in autumn. If not, offer Donna $40 to pay for his investigation. I will reimburse you when I get back. Ron From rbonica at juniper.net Sun Jul 24 09:09:11 2011 From: rbonica at juniper.net (Ronald Bonica) Date: Sun, 24 Jul 2011 10:09:11 -0400 Subject: From Quebec In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F431CD40@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456D3F431CD40@EMBX01-WF.jnpr.net> Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F431CD48@EMBX01-WF.jnpr.net> Folks, Sorry! I meant to send this email to my wife and daughter. Fat fingers early in the morning. Ron > -----Original Message----- > From: Ronald Bonica > Sent: Sunday, July 24, 2011 9:29 AM > To: dbonica; North American Network Operators' Group > Subject: From Quebec > > Hi Folks, > > I arrived in Quebec at about midnight last night. (United is always > late). > > Dorothy, the VIRTUS forms are on the printer. Please have Amanda fill > them out immediately. Ask Dylan if he is willing to help in autumn. If > not, offer Donna $40 to pay for his investigation. I will reimburse you > when I get back. > > Ron > > > _____ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog From brandon.kim at brandontek.com Sun Jul 24 10:22:17 2011 From: brandon.kim at brandontek.com (Brandon Kim) Date: Sun, 24 Jul 2011 11:22:17 -0400 Subject: From Quebec In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F431CD48@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456D3F431CD40@EMBX01-WF.jnpr.net>, <13205C286662DE4387D9AF3AC30EF456D3F431CD48@EMBX01-WF.jnpr.net> Message-ID: haha too funny..... All in good humor...... > From: rbonica at juniper.net > To: nanog at nanog.org > Date: Sun, 24 Jul 2011 10:09:11 -0400 > Subject: RE: From Quebec > > Folks, > > Sorry! I meant to send this email to my wife and daughter. > > Fat fingers early in the morning. > > Ron > > > > -----Original Message----- > > From: Ronald Bonica > > Sent: Sunday, July 24, 2011 9:29 AM > > To: dbonica; North American Network Operators' Group > > Subject: From Quebec > > > > Hi Folks, > > > > I arrived in Quebec at about midnight last night. (United is always > > late). > > > > Dorothy, the VIRTUS forms are on the printer. Please have Amanda fill > > them out immediately. Ask Dylan if he is willing to help in autumn. If > > not, offer Donna $40 to pay for his investigation. I will reimburse you > > when I get back. > > > > Ron > > > > > > _____ > > NANOG mailing list > > NANOG at nanog.org > > https://mailman.nanog.org/mailman/listinfo/nanog > > _____ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog From frnkblk at iname.com Sun Jul 24 17:09:33 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 24 Jul 2011 17:09:33 -0500 Subject: internap fcp competitors? In-Reply-To: <20110721095254.034243c2@greg.bestnet.kharkov.ua> References: <1f9401cc4757$300543c0$900fcb40$@com> <20110721095254.034243c2@greg.bestnet.kharkov.ua> Message-ID: <002301cc4a4e$5e0fa590$1a2ef0b0$@iname.com> It's old, but at the time I thought it was a great article: http://www.networkcomputing.com/wan-optimization-and-application-acceleratio n/229623159?pgno=2 Frank -----Original Message----- From: Gregory Edigarov [mailto:greg at bestnet.kharkov.ua] Sent: Thursday, July 21, 2011 1:53 AM To: nanog at nanog.org Subject: Re: internap fcp competitors? On Wed, 20 Jul 2011 23:35:05 -0400 "MageMojo" wrote: > Does anyone know of competitors to internap's fcp product? Also, I would greatly appreciate if anybody could explain what technically is internap fcp. -- With best regards, Gregory Edigarov _____ NANOG mailing list NANOG at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog From dougb at dougbarton.us Sun Jul 24 17:42:12 2011 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 24 Jul 2011 15:42:12 -0700 Subject: From Quebec In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F431CD48@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456D3F431CD40@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456D3F431CD48@EMBX01-WF.jnpr.net> Message-ID: <4E2C9FC4.20506@dougbarton.us> On 07/24/2011 07:09, Ronald Bonica wrote: > Sorry! I meant to send this email to my wife and daughter. Your daughter's name is nanog? Wow, that's, um .... dedication? -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From jjanusze at wd-tek.com Sun Jul 24 17:45:14 2011 From: jjanusze at wd-tek.com (jjanusze at wd-tek.com) Date: Sun, 24 Jul 2011 18:45:14 -0400 (EDT) Subject: Info on Charter Outage in Midland, Michigan Message-ID: <1692889674.281377.1311547514661.JavaMail.open-xchange@oxusltgw12.schlund.de> Are there any updates on the Charter outage affecting cable and network services to the Midland, Michigan area, and how large it is? From nanog at magemojo.com Sun Jul 24 19:32:55 2011 From: nanog at magemojo.com (Eric Hileman) Date: Sun, 24 Jul 2011 20:32:55 -0400 Subject: [c-nsp] Is Performance Routing, PfR a dead duck? In-Reply-To: <4E2CB351.9010209@comcast.net> References: <03c101cc4a59$924c4b00$b6e4e100$@com> <4E2CB351.9010209@comcast.net> Message-ID: <03e001cc4a62$66d57f60$34807e20$@com> Thanks! You saw it in use in the context in which I was speaking, correct? Isn't PfR the latest iteration of OER? > > It's not dead and I've actually seen it in use a couple of times. Look up OER. I believe Dana Blair was/is the principle engineer. tv _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From tvarriale at comcast.net Sun Jul 24 20:37:18 2011 From: tvarriale at comcast.net (Tony Varriale) Date: Sun, 24 Jul 2011 20:37:18 -0500 Subject: [c-nsp] Is Performance Routing, PfR a dead duck? In-Reply-To: <03e001cc4a62$66d57f60$34807e20$@com> References: <03c101cc4a59$924c4b00$b6e4e100$@com> <4E2CB351.9010209@comcast.net> <03e001cc4a62$66d57f60$34807e20$@com> Message-ID: <4E2CC8CE.5030309@comcast.net> On 7/24/2011 7:32 PM, Eric Hileman wrote: > Thanks! You saw it in use in the context in which I was speaking, correct? > Isn't PfR the latest iteration of OER? > > Yeah that's the only place I've seen it used. You are probably right...Pfr moving forward? tv From nanog at magemojo.com Sun Jul 24 20:55:05 2011 From: nanog at magemojo.com (Eric Hileman) Date: Sun, 24 Jul 2011 21:55:05 -0400 Subject: [c-nsp] Is Performance Routing, PfR a dead duck? In-Reply-To: <4E2CC8CE.5030309@comcast.net> References: <03c101cc4a59$924c4b00$b6e4e100$@com> <4E2CB351.9010209@comcast.net> <03e001cc4a62$66d57f60$34807e20$@com> <4E2CC8CE.5030309@comcast.net> Message-ID: <04a401cc4a6d$e12a05a0$a37e10e0$@com> Very cool, thanks again. Finding people with having experience with it has been really hard! >From "Cisco Performance Routing FAQs": http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599/ps8 787/prod_qas0900aecd806c4f03.html Q. What is CiscoR Performance Routing (PfR)? A. Cisco Performance Routing complements classic IP routing technologies by adding intelligence to select the best paths to meet application performance requirements. The first phase of Performance Routing technology intelligently optimized application performance over enterprise WANs and to and from the Internet and named Optimized Edge Routing (OER). This technology has evolved to become PfR and enables application performance optimization throughout the enterprise network through an end-to-end, performance-aware network. It would be cool if someone could break down the pieces and how they all fit together :) > > Yeah that's the only place I've seen it used. You are probably right...Pfr moving forward? tv _____ NANOG mailing list NANOG at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog From fweimer at bfk.de Mon Jul 25 05:55:11 2011 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 25 Jul 2011 10:55:11 +0000 Subject: high performance open source DHCP solution? In-Reply-To: (PC's message of "Thu, 21 Jul 2011 01:42:00 -0600") References: <4E2758B8.5080804@rainierconnect.net> <1D59D851-2A0E-4CED-BAA5-61FDFD3CF4D0@bogus.com> <20110721064138.GX16178@leitl.org> Message-ID: <82y5zmd3zk.fsf@mid.bfk.de> * PC: > If you're just fighting IOPS, another compromise might be using a ramdisk, > and then committing that data to storage every x seconds. In this case, it's more straightforward to remove the fsync call from dhcpd. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From fweimer at bfk.de Mon Jul 25 05:59:44 2011 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 25 Jul 2011 10:59:44 +0000 Subject: high performance open source DHCP solution? In-Reply-To: (Jimmy Hess's message of "Wed, 20 Jul 2011 17:28:38 -0500") References: Message-ID: <82tyaad3rz.fsf@mid.bfk.de> * Jimmy Hess: > On Wed, Jul 20, 2011 at 9:31 AM, Nick Colton wrote: >> We were seeing similar issues with low leases, moved the dhcpd.leases file >> to a ramdisk and went from ~200 leases per second to something like 8,000 >> leases per second. > > Yes, blame RFC2131's requirement that a DHCP server is to ensure that > any lease is committed to persistent storage, strictly before a DHCP > server is allowed to send the response to the request; a fully > compliant DHCP server with sufficient traffic is bound by the disk I/O > rate of underlying storage backing its database. Come on, group commits are not that difficult to implement. With them, you should be able to obtain 8 kHZ leases on a single spindle (assuming the per-client data is just a few hundred bytes), without violating the RFC requirement. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From drew.linsalata at gmail.com Mon Jul 25 07:00:25 2011 From: drew.linsalata at gmail.com (Drew Linsalata) Date: Mon, 25 Jul 2011 08:00:25 -0400 Subject: AT&T Email/SMS gateway outage Message-ID: Marginally operational, but I'm sure there are at least a few folks using that service as part of monitoring, so it probably bears mentioning. AT&T appears to be having an email-to-SMS gateway issue. Messages sent to xxxyyyyyyy at txt.att.net are not being delivered to handsets. No bounce, but no delivery either. As a workaround, messages sent to xxxyyyyyyy at mms.att.netdo do get delivered. Confirmed in the NYC metro area and in Chicago at the moment. From rps at maine.edu Mon Jul 25 09:50:21 2011 From: rps at maine.edu (Ray Soucy) Date: Mon, 25 Jul 2011 10:50:21 -0400 Subject: Mac OS X Lion has DHCPv6 Message-ID: Just wanted to drop a note as a was pretty harsh on Apple when rumors of them not including DHCPv6 client support were floating about. In the past few days I've also seen people post that OS X doesn't have DHCPv6, because they were looking for "DHCPv6" in the UI. Thankfully these reports are false. Just tried it myself on a newly upgraded Mac. Quick testing shows that when "Automatic" is used for the IPv6 setting, OS X will correctly look at the A, M, and O flags of an IPv6 RA and make use of DHCPv6 when instructed to. Thank you to everyone at Apple who made this happen. Especially James Woodyatt, who I gave a piratically hard time to wearing my end-user hat ;-) -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From bicknell at ufp.org Mon Jul 25 09:56:34 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 25 Jul 2011 07:56:34 -0700 Subject: Mac OS X Lion has DHCPv6 In-Reply-To: References: Message-ID: <20110725145634.GA53791@ussenterprise.ufp.org> In a message written on Mon, Jul 25, 2011 at 10:50:21AM -0400, Ray Soucy wrote: > Just wanted to drop a note as a was pretty harsh on Apple when rumors > of them not including DHCPv6 client support were floating about. In > the past few days I've also seen people post that OS X doesn't have > DHCPv6, because they were looking for "DHCPv6" in the UI. Thankfully > these reports are false. > > Just tried it myself on a newly upgraded Mac. > > Quick testing shows that when "Automatic" is used for the IPv6 > setting, OS X will correctly look at the A, M, and O flags of an IPv6 > RA and make use of DHCPv6 when instructed to. > > Thank you to everyone at Apple who made this happen. Especially James > Woodyatt, who I gave a piratically hard time to wearing my end-user > hat ;-) I can also confirm, and even to the point where you can disable IPv4 and have a working IPv6 only client. It does DHCPv6 to get namesevers and the like, Safari works just fine for browsing IPv6 only sites, and there seem to be no hangups. Several other message boards point to a lot of changes under the hood in the Objective-C sockets classes to implement "happy eyeballs". That is if a host is dual stacked and has both A and AAAA it tries both and caches which was faster and uses that for future connections. I'm unsure right now if it is just connect times, throughput, RTT, or what other metrics might be used, but apparently the result is, well, happy eyeballs. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From tjc at ecs.soton.ac.uk Mon Jul 25 09:59:29 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Mon, 25 Jul 2011 15:59:29 +0100 Subject: Mac OS X Lion has DHCPv6 In-Reply-To: References: <3175404B-7D89-4C9D-BC82-9B6DA07D5EB3@ecs.soton.ac.uk> Message-ID: On 25 Jul 2011, at 15:50, Ray Soucy wrote: > Just wanted to drop a note as a was pretty harsh on Apple when rumors > of them not including DHCPv6 client support were floating about. In > the past few days I've also seen people post that OS X doesn't have > DHCPv6, because they were looking for "DHCPv6" in the UI. Thankfully > these reports are false. > > Just tried it myself on a newly upgraded Mac. > > Quick testing shows that when "Automatic" is used for the IPv6 > setting, OS X will correctly look at the A, M, and O flags of an IPv6 > RA and make use of DHCPv6 when instructed to. > > Thank you to everyone at Apple who made this happen. Especially James > Woodyatt, who I gave a piratically hard time to wearing my end-user > hat ;-) +1 Running successfully on Lion with DHCPv6-supplied resolvers at the IETF meeting this week. Tim From o.calvano at gmail.com Mon Jul 25 10:38:19 2011 From: o.calvano at gmail.com (Olivier CALVANO) Date: Mon, 25 Jul 2011 17:38:19 +0200 Subject: USA DSL/T1 Service ? Message-ID: Hello, I work for a French operator, so I know well wholesales solutions E1/Sdsl/Adsl online a few countries Europe. I am looking to find how wholesales work in the U.S., basically, we would be in New York City and would have a wholesales Dsl/T1 issued or L2TP VLAN. I tried contact operators like Qwest or AT & T but impossible to have a credible interlocutor. So I posted in the nanog as I turn a little too round. Someone on the list could give me information on the techniques and the average price of trunk? Is there a solution that allows me to connect one site whatever it either the USA in Q1 was my point of presence in New York City? Thank you in advance olive From AdamKennedy at omnicity.net Mon Jul 25 10:59:41 2011 From: AdamKennedy at omnicity.net (Adam Kennedy) Date: Mon, 25 Jul 2011 11:59:41 -0400 Subject: AT&T Email/SMS gateway outage In-Reply-To: Message-ID: This appears to have just been restored. -- Adam Kennedy Network Engineer Omnicity, Inc. From: Drew Linsalata > Date: Mon, 25 Jul 2011 08:00:25 -0400 To: NANOG > Subject: AT&T Email/SMS gateway outage Marginally operational, but I'm sure there are at least a few folks using that service as part of monitoring, so it probably bears mentioning. AT&T appears to be having an email-to-SMS gateway issue. Messages sent to xxxyyyyyyy at txt.att.net are not being delivered to handsets. No bounce, but no delivery either. As a workaround, messages sent to xxxyyyyyyy at mms.att.netdo do get delivered. Confirmed in the NYC metro area and in Chicago at the moment. _____ NANOG mailing list NANOG at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog From paul4004 at gmail.com Mon Jul 25 13:34:12 2011 From: paul4004 at gmail.com (PC) Date: Mon, 25 Jul 2011 12:34:12 -0600 Subject: USA DSL/T1 Service ? In-Reply-To: References: Message-ID: I don't think what you are after will be as feasible as it sounds like you're used to in Europe. In the US, there are _many_ different telephone companies each servicing a certain area, and they each have different policies and procedures on whether they will offer wholesale DSL in a given market. For this type of wholesale access, you will need to make arrangements with each operator in the area you want access to. I will tell you that the usage of IP/L2TP as a delivery mechanism is not as pervasive as I often hear about in other countries. In most cases, I've found telephone companies still require you to have an in-market ATM circuit to accept the handoff via PVC(s). This can get expensive, quickly, if you're trying to aggregate connections to a single POP in NYC that are not close to NYC, as you need to back haul that ATM circuit to each respective market. Additionally, FCC ruling some years back made it so the telephone companies no longer must make available wholesale access to their DSL/broadband networks, and as a result some no longer offer access to independent operators. Those on your list of potential operators that do continue to do so have had a policy of not offering new products/services to wholesale DSL customers since this ruling, which I guess is most likely for "business" reasons and perceived competitive threats to their own local broadband offerings. The long term availability of these services is in doubt as ADSL1 fades away. (Examples include: Qwest: No access to ADSL2 network/speeds, VDSL network/speeds. Lack/loss of wholesale access to DSL in markets not supported by ADSL1 or converted away from ADSL1. Verizon: No access to FIOS/Fiber-based services. Inability to get copper based ADSL services at a location converted to fiber.) Some, such as Verizon, also refuse to offer their wholesale solution to people not using it for resale (IE: enterprise customers), regardless of line quantities. If you wish to proceed, here are links to the appropriate provider information pages which detail their product offers and architectures: Qwest: http://www.qwest.com/wholesale/pcat/hsihostservice.html Verizon: https://www22.verizon.com/dslmembersonly/contents.jsp?show=aboutdsl ATT: Varies by market, but you can find your links here: http://www.business.att.com/wholesale/Family/ip-solutions-wholesale/dsl-transport-service-wholesale/ You may find in many cases, that contracting with a local/smaller ISP in each market who has an existing wholesale arrangement with your desired carrier in place, and asking them to deliver the services over L2TP, may be the best solution for smaller quantities of connections. Or seriously consider a VPN solution if it's more appropriate for what you are doing. On Mon, Jul 25, 2011 at 9:38 AM, Olivier CALVANO wrote: > Hello, > > I work for a French operator, so I know well > wholesales solutions E1/Sdsl/Adsl online a few countries > Europe. > > I am looking to find how wholesales work in the U.S., > basically, we would be in New York City and would have > a wholesales Dsl/T1 issued or L2TP VLAN. I tried > contact operators like Qwest or AT & T but > impossible to have a credible interlocutor. > > So I posted in the nanog as I turn a little too round. > Someone on the list could give me information on the > techniques and the average price of trunk? > > Is there a solution that allows me to connect one site whatever it > either the USA in Q1 was my point of presence in New York City? > > Thank you in advance > olive > > _____ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > From mksmith at adhost.com Mon Jul 25 13:43:51 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Mon, 25 Jul 2011 18:43:51 +0000 Subject: NANOG List Cutover Schedule Message-ID: Hello All: We will be moving the mailing list at 12:00 PDT (GMT -7). The following is the cutover schedule and expected issues during the cutover. 1) 12:00 - move DNS for mailman.nanog.org (the MX for nanog.org) 2) 12:00 - shut down Mailman on s0.nanog.org (mailman.nanog.org) 3) 12:01 - final rsync of list data over to new server 4) 12:05 - send out a "TEST" message to the NANOG list 5) 12:30 - if message is not seen on list and no correctable errors are detected in the logfiles, revert to s0.nanog.org, troubleshoot, report and reschedule. If anyone has any questions or concerns please let me know. Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) From mksmith at adhost.com Mon Jul 25 14:39:36 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Mon, 25 Jul 2011 19:39:36 +0000 Subject: TEST Message-ID: This message is testing the new list server configuration. Please ignore. Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) From mksmith at adhost.com Mon Jul 25 14:20:59 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Mon, 25 Jul 2011 19:20:59 +0000 Subject: NANOG List Cutover Schedule In-Reply-To: References: Message-ID: We are holding on this conversion at the moment and running on the existing configuration. I will update the list shortly with a revised schedule. Regards, Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) > -----Original Message----- > From: Michael K. Smith - Adhost [mailto:mksmith at adhost.com] > Sent: Monday, July 25, 2011 11:44 AM > To: NANOG list (nanog at nanog.org) > Subject: NANOG List Cutover Schedule > > Hello All: > > We will be moving the mailing list at 12:00 PDT (GMT -7). The following is the > cutover schedule and expected issues during the cutover. > > 1) 12:00 - move DNS for mailman.nanog.org (the MX for nanog.org) > 2) 12:00 - shut down Mailman on s0.nanog.org (mailman.nanog.org) > 3) 12:01 - final rsync of list data over to new server > 4) 12:05 - send out a "TEST" message to the NANOG list > 5) 12:30 - if message is not seen on list and no correctable errors are detected > in the logfiles, revert to s0.nanog.org, troubleshoot, report and reschedule. > > If anyone has any questions or concerns please let me know. > > Mike > > -- > Michael K. Smith - CISSP, GSEC, GISP > Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com > w: +1 (206) 404-9500 f: +1 (206) 404-9050 > PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) > > > > _____ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog From mksmith at adhost.com Mon Jul 25 14:55:47 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Mon, 25 Jul 2011 19:55:47 +0000 Subject: NANOG List Cutover Schedule - COMPLETE Message-ID: Hello: We have moved the NANOG mailing list to its new location. I've sent and received a test message successfully. If anyone is having issue after they have confirmed they have the correct DNS settings, please send me an email directly. 204.93.212.138 And 2001:1838:2001:3:2a0:d1ff:fee9:4f94 Regards, Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) > -----Original Message----- > From: Michael K. Smith - Adhost [mailto:mksmith at adhost.com] > Sent: Monday, July 25, 2011 12:21 PM > To: NANOG list (nanog at nanog.org) > Subject: RE: NANOG List Cutover Schedule > > We are holding on this conversion at the moment and running on the existing > configuration. I will update the list shortly with a revised schedule. > > Regards, > > Mike > > -- > Michael K. Smith - CISSP, GSEC, GISP > Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com > w: +1 (206) 404-9500 f: +1 (206) 404-9050 > PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) > > > > -----Original Message----- > > From: Michael K. Smith - Adhost [mailto:mksmith at adhost.com] > > Sent: Monday, July 25, 2011 11:44 AM > > To: NANOG list (nanog at nanog.org) > > Subject: NANOG List Cutover Schedule > > > > Hello All: > > > > We will be moving the mailing list at 12:00 PDT (GMT -7). The following is > the > > cutover schedule and expected issues during the cutover. > > > > 1) 12:00 - move DNS for mailman.nanog.org (the MX for nanog.org) > > 2) 12:00 - shut down Mailman on s0.nanog.org (mailman.nanog.org) > > 3) 12:01 - final rsync of list data over to new server > > 4) 12:05 - send out a "TEST" message to the NANOG list > > 5) 12:30 - if message is not seen on list and no correctable errors are > detected > > in the logfiles, revert to s0.nanog.org, troubleshoot, report and reschedule. > > > > If anyone has any questions or concerns please let me know. > > > > Mike > > > > -- > > Michael K. Smith - CISSP, GSEC, GISP > > Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com > > w: +1 (206) 404-9500 f: +1 (206) 404-9050 > > PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) > > > > > > > > _____ > > NANOG mailing list > > NANOG at nanog.org > > https://mailman.nanog.org/mailman/listinfo/nanog > > _____ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog From mksmith at adhost.com Mon Jul 25 20:00:49 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Tue, 26 Jul 2011 01:00:49 +0000 Subject: Change in NANOG IPv6 Address Message-ID: Hello Everyone: The correct and updated IPv6 address for the NANOG list is 2001:1838::cc5d:d48a. Forward and reverse records are updated and the other address will continue to work while the DNS change propagates. Regards, Mike From harbor235 at gmail.com Tue Jul 26 08:57:29 2011 From: harbor235 at gmail.com (harbor235) Date: Tue, 26 Jul 2011 09:57:29 -0400 Subject: OOB Message-ID: I am curious what is the best practice for OOB for a core infrastructure environment. Obviously, there is an OOB kit for customer managed devices via POTS, Ethernet, etc ... And there is OOB for core infrastructure typically a separate basic network that utilizes diverse carrier and diverse path when available. My question is, is it best practice to extend an inband VPN throughout for device management functions as well? And are all management services performed OOB, e.g network management, some monitoring, logging, authentication, flowdata, etc ..... If a management VPN is used is it also extended to managed customer devices? What else is can be done for remote management and troubleshooting capabilities? Mike From paul at paulstewart.org Tue Jul 26 09:03:05 2011 From: paul at paulstewart.org (Paul Stewart) Date: Tue, 26 Jul 2011 10:03:05 -0400 Subject: OOB In-Reply-To: References: Message-ID: <018501cc4b9c$bdb1f6c0$3915e440$@org> We do everything in-band with strict monitoring/policies in place. Paul -----Original Message----- From: harbor235 [mailto:harbor235 at gmail.com] Sent: Tuesday, July 26, 2011 9:57 AM To: NANOG list Subject: OOB I am curious what is the best practice for OOB for a core infrastructure environment. Obviously, there is an OOB kit for customer managed devices via POTS, Ethernet, etc ... And there is OOB for core infrastructure typically a separate basic network that utilizes diverse carrier and diverse path when available. My question is, is it best practice to extend an inband VPN throughout for device management functions as well? And are all management services performed OOB, e.g network management, some monitoring, logging, authentication, flowdata, etc ..... If a management VPN is used is it also extended to managed customer devices? What else is can be done for remote management and troubleshooting capabilities? Mike From ierdnah at gmail.com Tue Jul 26 09:12:59 2011 From: ierdnah at gmail.com (Andrei Popa) Date: Tue, 26 Jul 2011 17:12:59 +0300 Subject: nanog presentations archive Message-ID: <1311689581.9740.5.camel@ierdnac-hp> Hello, >From two weeks the archive presentation files from nanog meetings aren't available anymore http://www.nanog.org/presentations/archive/index.php I've tried contacting nanog site maintainers with no luck. Can somebody give me some contact details from nanog site maintainers for reporting this issue ? Thank you, Andrei From cabenth at gmail.com Tue Jul 26 09:14:18 2011 From: cabenth at gmail.com (Eric Clark) Date: Tue, 26 Jul 2011 07:14:18 -0700 Subject: OOB In-Reply-To: <018501cc4b9c$bdb1f6c0$3915e440$@org> References: <018501cc4b9c$bdb1f6c0$3915e440$@org> Message-ID: <45EF1401-6F16-4EB5-8A55-E483C7A65318@gmail.com> As far as best practices, I'm not sure. I've generally built an out of band network for the express purpose of saving my behind in the event of an unanticipated traffic problem on the primary network. Secondarily it allows secured access to equipment, and you can monitor (which is often not secure, read snmp) on it as well. However, I've never tried to extend one beyond a facility or campus exactly. Lots depends on the type of network you're talking about and equipment you're using though. E Sent from my iPad which loves to "correct" my typing with interesting results. On Jul 26, 2011, at 7:03 AM, "Paul Stewart" wrote: > We do everything in-band with strict monitoring/policies in place. > > Paul > > > -----Original Message----- > From: harbor235 [mailto:harbor235 at gmail.com] > Sent: Tuesday, July 26, 2011 9:57 AM > To: NANOG list > Subject: OOB > > I am curious what is the best practice for OOB for a core > infrastructure environment. Obviously, there is > an OOB kit for customer managed devices via POTS, Ethernet, etc ... And > there is OOB for core infrastructure > typically a separate basic network that utilizes diverse carrier and diverse > path when available. > > My question is, is it best practice to extend an inband VPN throughout for > device management functions as well? > And are all management services performed OOB, e.g network management, some > monitoring, logging, > authentication, flowdata, etc ..... If a management VPN is used is it also > extended to managed customer devices? > > What else is can be done for remote management and troubleshooting > capabilities? > > Mike > > From morrowc.lists at gmail.com Tue Jul 26 09:14:21 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 26 Jul 2011 10:14:21 -0400 Subject: OOB In-Reply-To: <018501cc4b9c$bdb1f6c0$3915e440$@org> References: <018501cc4b9c$bdb1f6c0$3915e440$@org> Message-ID: On Tue, Jul 26, 2011 at 10:03 AM, Paul Stewart wrote: > We do everything in-band with strict monitoring/policies in place. what do you do if your in-band fails? if a router/switch/ROADM is isolated from the rest of your network? (isn't that the core point of the OP?) > -----Original Message----- > From: harbor235 [mailto:harbor235 at gmail.com] > Sent: Tuesday, July 26, 2011 9:57 AM > To: NANOG list > Subject: OOB > > I am curious what is the best practice for OOB for a core > infrastructure environment. Obviously, there is > an OOB kit for customer managed devices via POTS, Ethernet, etc ... And > there is OOB for core infrastructure > typically a separate basic network that utilizes diverse carrier and diverse > path when available. > > My question is, is it best practice to extend an inband VPN throughout for > device management functions as well? > And are all management services performed OOB, e.g network management, some > monitoring, logging, > authentication, flowdata, etc ..... If a management VPN is used is it also > extended to managed customer devices? > > What else is can be done for remote management and troubleshooting > capabilities? > > Mike > > > From JTyler at fiberutilities.com Tue Jul 26 09:16:15 2011 From: JTyler at fiberutilities.com (Jensen Tyler) Date: Tue, 26 Jul 2011 09:16:15 -0500 Subject: nanog presentations archive Message-ID: <1A8A762BD508624A8BDAB9F5E1638F945FB7FDE541@comsrv01.fg.local> See Below Jensen Tyler Sr Engineering Manager Fiberutilities Group, LLC (319) 297-6915 (office) *NEW (319) 364-8100 (fax) (319) 329-8578 (mobile) -----Original Message----- From: Betty Burke [mailto:betty at newnog.org] Sent: Thursday, July 21, 2011 1:54 PM To: NANOG at nanog.org Subject: Problems with the NANOG Meeting Archives Colleagues: Unfortunately, it is true the archives are not working properly. As part of the NANOG Service transition, the code which supports the meeting(s) presentation archive stopped working. We have all the data, and staff are currently working quickly to repair the code and return to normal operations of the archive. We understand the importance of the NANOG meeting history, and are sorry for the delay in access. I do not yet have an eta, however I will be sure to keep the community posted. Please accept my apology for the interruption. Betty -- Betty Burke NewNOG/NANOG Executive Director Office (810) 214-1218 _____ NANOG mailing list NANOG at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog From JTyler at fiberutilities.com Tue Jul 26 09:19:02 2011 From: JTyler at fiberutilities.com (Jensen Tyler) Date: Tue, 26 Jul 2011 09:19:02 -0500 Subject: OOB In-Reply-To: References: <018501cc4b9c$bdb1f6c0$3915e440$@org> Message-ID: <1A8A762BD508624A8BDAB9F5E1638F945FB7FDE542@comsrv01.fg.local> We use a console server like 'opengear' with either a POTS or wireless broadband to provide access to stranded network. Also monitors things like door alarm , temp, humidity and etc. Jensen Tyler Sr Engineering Manager Fiberutilities Group, LLC -----Original Message----- From: Christopher Morrow [mailto:morrowc.lists at gmail.com] Sent: Tuesday, July 26, 2011 9:14 AM To: Paul Stewart Cc: NANOG list Subject: Re: OOB On Tue, Jul 26, 2011 at 10:03 AM, Paul Stewart wrote: > We do everything in-band with strict monitoring/policies in place. what do you do if your in-band fails? if a router/switch/ROADM is isolated from the rest of your network? (isn't that the core point of the OP?) > -----Original Message----- > From: harbor235 [mailto:harbor235 at gmail.com] > Sent: Tuesday, July 26, 2011 9:57 AM > To: NANOG list > Subject: OOB > > I am curious what is the best practice for OOB for a core > infrastructure environment. Obviously, there is > an OOB kit for customer managed devices via POTS, Ethernet, etc ... And > there is OOB for core infrastructure > typically a separate basic network that utilizes diverse carrier and diverse > path when available. > > My question is, is it best practice to extend an inband VPN throughout for > device management functions as well? > And are all management services performed OOB, e.g network management, some > monitoring, logging, > authentication, flowdata, etc ..... If a management VPN is used is it also > extended to managed customer devices? > > What else is can be done for remote management and troubleshooting > capabilities? > > Mike > > > From cb.list6 at gmail.com Tue Jul 26 09:25:14 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Tue, 26 Jul 2011 07:25:14 -0700 Subject: OOB In-Reply-To: References: Message-ID: On Jul 26, 2011 6:57 AM, "harbor235" wrote: > > I am curious what is the best practice for OOB for a core > infrastructure environment. Obviously, there is > an OOB kit for customer managed devices via POTS, Ethernet, etc ... And > there is OOB for core infrastructure > typically a separate basic network that utilizes diverse carrier and diverse > path when available. > > My question is, is it best practice to extend an inband VPN throughout for > device management functions as well? > And are all management services performed OOB, e.g network management, some > monitoring, logging, > authentication, flowdata, etc ..... If a management VPN is used is it also > extended to managed customer devices? > > What else is can be done for remote management and troubleshooting > capabilities? > IMHO, it is always a good idea to have completely different infrastructure supporting Oob. It is the only way you can recover remotely from many types of network errors. If the router is hung at rommon, somebody has to get on console .... or accidentally removes your igp instanance ... But, the business criticality of the network needs to justify the cost (dial, DSL, 3rd party L3 vpn ....) Cb > Mike From xmin0s at gmail.com Tue Jul 26 09:30:43 2011 From: xmin0s at gmail.com (Tim Eberhard) Date: Tue, 26 Jul 2011 09:30:43 -0500 Subject: OOB In-Reply-To: References: Message-ID: In my experience having your management run over product via VPN is not a great idea. If possible separate the two. Having been in Ops for many many years and having worked on both a well built nationwide network with a dedicated management/oob infrastructure that is completely separate from the CDN and working on a not so well built nationwide network that is built as cheap as possible with VPN's running over the production CDN.. I would highly recommend separating the two. No amount of policies or procedures will prevent your management network from going down during critical times. In my experience both MTTR and the over all sanity of anyone working on that network starts to go down the drain as they are always worried about impacting management and isolating themselves, or during an outage unable to fix the problems at hand in a reasonable amount of time. I understand not everyone can spend the money to have a dedicated management infrastructure, but it's well worth every penny when done correctly. Just my 2 copper. -Tim Eberhard On Tue, Jul 26, 2011 at 8:57 AM, harbor235 wrote: > My question is, is it best practice to extend an inband VPN throughout for > device management functions as well? > And are all management services performed OOB, e.g network management, some > monitoring, logging, > authentication, flowdata, etc ..... If a management VPN is used is it also > extended to managed customer devices? > From nanog at maunier.org Tue Jul 26 09:31:18 2011 From: nanog at maunier.org (Pierre-Yves Maunier) Date: Tue, 26 Jul 2011 16:31:18 +0200 Subject: OOB In-Reply-To: References: Message-ID: Hello, to administrate our core backbone routers, management is done inband, the OOB is only for backup solution when the router is not reachable. Others things (like our DWDM infrastructure which is RFC1918 addressed), we use the OOB for the administration. Our OOB is done this way : Our principal core infrastructure is in Paris and we have our own dark fiber backbone there, we decided to have a 'core oob infrastructure' : a layer 2 network dedicated for the OOB is built to cover all our pops (with spanning tree for path protection) on dedicated dark fibers. On all pops we have console servers (Opengear) that allow to access our routers console ports remotely. We also have 2 smalls Juniper firewalls in cluster to connect the 'outside Paris' remote sites with VPNs. On the pops outside Paris we have a basic layer 2 switch, a firewall, a console server and we take IP connectivity from somebody onsite, the firewall has a VPN to the 'core oob infranstructure' in Paris which allow us to access everything. The IP connectivity on the core oob infrastructure is provided by our network with a backup IP connectivity from another provider which allow us to access everything in our backbone in case of a total blackout on our AS. Pierre-Yves 2011/7/26 harbor235 > I am curious what is the best practice for OOB for a core > infrastructure environment. Obviously, there is > an OOB kit for customer managed devices via POTS, Ethernet, etc ... And > there is OOB for core infrastructure > typically a separate basic network that utilizes diverse carrier and > diverse > path when available. > > My question is, is it best practice to extend an inband VPN throughout for > device management functions as well? > And are all management services performed OOB, e.g network management, some > monitoring, logging, > authentication, flowdata, etc ..... If a management VPN is used is it also > extended to managed customer devices? > > What else is can be done for remote management and troubleshooting > capabilities? > > Mike > From harbor235 at gmail.com Tue Jul 26 09:39:06 2011 From: harbor235 at gmail.com (harbor235) Date: Tue, 26 Jul 2011 10:39:06 -0400 Subject: OOB In-Reply-To: References: Message-ID: By VPN I meant a L3VPN for management only functions, and if there is a L3VPN for management does anyone extend that to managed CERs? I assumed running and MPLS SP core, sorry. I think a remote kit for console, ethernet, power is pretty standard I am really interested in the other management data for overall management like monitoring, flowdata, traffic analaysis, authentication, logging, etc .... Is this done in band or onthe dedicated OOB network? mike On Tue, Jul 26, 2011 at 10:31 AM, Pierre-Yves Maunier wrote: > Hello, > > to administrate our core backbone routers, management is done inband, the > OOB is only for backup solution when the router is not reachable. > Others things (like our DWDM infrastructure which is RFC1918 addressed), we > use the OOB for the administration. > > Our OOB is done this way : > > Our principal core infrastructure is in Paris and we have our own dark > fiber backbone there, we decided to have a 'core oob infrastructure' : a > layer 2 network dedicated for the OOB is built to cover all our pops (with > spanning tree for path protection) on dedicated dark fibers. On all pops we > have console servers (Opengear) that allow to access our routers console > ports remotely. > We also have 2 smalls Juniper firewalls in cluster to connect the 'outside > Paris' remote sites with VPNs. > > On the pops outside Paris we have a basic layer 2 switch, a firewall, a > console server and we take IP connectivity from somebody onsite, the > firewall has a VPN to the 'core oob infranstructure' in Paris which allow us > to access everything. > > The IP connectivity on the core oob infrastructure is provided by our > network with a backup IP connectivity from another provider which allow us > to access everything in our backbone in case of a total blackout on our AS. > > Pierre-Yves > > 2011/7/26 harbor235 > >> I am curious what is the best practice for OOB for a core >> infrastructure environment. Obviously, there is >> an OOB kit for customer managed devices via POTS, Ethernet, etc ... And >> there is OOB for core infrastructure >> typically a separate basic network that utilizes diverse carrier and >> diverse >> path when available. >> >> My question is, is it best practice to extend an inband VPN throughout for >> device management functions as well? >> And are all management services performed OOB, e.g network management, >> some >> monitoring, logging, >> authentication, flowdata, etc ..... If a management VPN is used is it also >> extended to managed customer devices? >> >> What else is can be done for remote management and troubleshooting >> capabilities? >> >> Mike >> > > > From arnold at nipper.de Tue Jul 26 09:40:23 2011 From: arnold at nipper.de (Arnold Nipper) Date: Tue, 26 Jul 2011 16:40:23 +0200 Subject: OOB In-Reply-To: References: Message-ID: <4E2ED1D7.5070905@nipper.de> on 26.07.2011 16:25 Cameron Byrne wrote: > On Jul 26, 2011 6:57 AM, "harbor235" wrote: >> >> I am curious what is the best practice for OOB for a core >> infrastructure environment. Obviously, there is >> an OOB kit for customer managed devices via POTS, Ethernet, etc ... And >> there is OOB for core infrastructure >> typically a separate basic network that utilizes diverse carrier and > diverse >> path when available. >> >> My question is, is it best practice to extend an inband VPN throughout for >> device management functions as well? >> And are all management services performed OOB, e.g network management, > some >> monitoring, logging, >> authentication, flowdata, etc ..... If a management VPN is used is it also >> extended to managed customer devices? >> >> What else is can be done for remote management and troubleshooting >> capabilities? >> > > IMHO, it is always a good idea to have completely different infrastructure > supporting Oob. Fully acked, but with every service migrating to IP how do you make sure that the oob infrastructure is completely different from your production network? Best regards, Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold at nipper.de phone: +49 6224 9259 299 mobile: +49 152 53717690 fax: +49 6224 9259 333 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From jordi.palet at consulintel.es Tue Jul 26 09:58:24 2011 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 26 Jul 2011 10:58:24 -0400 Subject: dynamic or static IPv6 prefixes to residential customers Message-ID: Hi all, I will like to know, from those deploying IPv6 services to residential customers, if you are planning to provide static or dynamic IPv6 prefixes. Just to be clear, I'm for static prefix delegation to residential customers, however I heard that some ISPs are doing dynamic delegations, the same way as is common today with IPv4. I don't thin it make sense, as the main reason for doing so in IPv4 was address exhaustion and legacy oversubscription models such as PPP/dial-up. Regards, Jordi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jeff-kell at utc.edu Tue Jul 26 09:58:04 2011 From: jeff-kell at utc.edu (Jeff Kell) Date: Tue, 26 Jul 2011 10:58:04 -0400 Subject: OOB In-Reply-To: <1A8A762BD508624A8BDAB9F5E1638F945FB7FDE542@comsrv01.fg.local> References: <018501cc4b9c$bdb1f6c0$3915e440$@org> <1A8A762BD508624A8BDAB9F5E1638F945FB7FDE542@comsrv01.fg.local> Message-ID: <4E2ED5FC.5020700@utc.edu> On 7/26/2011 10:19 AM, Jensen Tyler wrote: > We use a console server like 'opengear' with either a POTS or wireless broadband to provide access to stranded network. > We use a management VRF (which is still technically in-band, but otherwise quite isolated), plus a few terminal servers for out-of-band console access to the critical devices. Jeff From paul at paulstewart.org Tue Jul 26 10:04:40 2011 From: paul at paulstewart.org (Paul Stewart) Date: Tue, 26 Jul 2011 11:04:40 -0400 Subject: OOB In-Reply-To: References: <018501cc4b9c$bdb1f6c0$3915e440$@org> Message-ID: <01ae01cc4ba5$581722a0$084567e0$@org> Honestly - in our core network, this has only happened once in almost 10 years... seriously. Everything in our core networks is redundant ... yes, I know redundancy breaks of course ;) When it did happen, we had remote hands reboot the equipment and everything was restored in approximately 30 minutes. I'm not saying boldly that we won't get caught with our pants down some day - just that previous experience has shown us to be prepared for the worst and the worst hasn't occurred. We have looked at OOB options and it's been discussed many times - it just slips off the radar constantly. Maybe it's "once bitten, twice shy" that needs to occur for the priority to change again. -----Original Message----- From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow Sent: Tuesday, July 26, 2011 10:14 AM To: Paul Stewart Cc: NANOG list Subject: Re: OOB On Tue, Jul 26, 2011 at 10:03 AM, Paul Stewart wrote: > We do everything in-band with strict monitoring/policies in place. what do you do if your in-band fails? if a router/switch/ROADM is isolated from the rest of your network? (isn't that the core point of the OP?) > -----Original Message----- > From: harbor235 [mailto:harbor235 at gmail.com] > Sent: Tuesday, July 26, 2011 9:57 AM > To: NANOG list > Subject: OOB > > I am curious what is the best practice for OOB for a core > infrastructure environment. Obviously, there is > an OOB kit for customer managed devices via POTS, Ethernet, etc ... And > there is OOB for core infrastructure > typically a separate basic network that utilizes diverse carrier and diverse > path when available. > > My question is, is it best practice to extend an inband VPN throughout for > device management functions as well? > And are all management services performed OOB, e.g network management, some > monitoring, logging, > authentication, flowdata, etc ..... If a management VPN is used is it also > extended to managed customer devices? > > What else is can be done for remote management and troubleshooting > capabilities? > > Mike > > > From jeroen at unfix.org Tue Jul 26 10:05:41 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 26 Jul 2011 17:05:41 +0200 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: Message-ID: <4E2ED7C5.1040702@unfix.org> On 2011-07-26 16:58 , JORDI PALET MARTINEZ wrote: > Hi all, > > I will like to know, from those deploying IPv6 services to residential > customers, if you are planning to provide static or dynamic IPv6 prefixes. > > Just to be clear, I'm for static prefix delegation to residential > customers, however I heard that some ISPs are doing dynamic delegations, > the same way as is common today with IPv4. > > I don't thin it make sense, as the main reason for doing so in IPv4 was > address exhaustion and legacy oversubscription models such as PPP/dial-up. You are forgetting the simple fact that you can charge for static addresses and unblocked connectivity. THAT is the reason for dynamic addresses, as on the ISP level there are still enough IPv4 addresses and they can still, even today, ask for more from their RIR. Abuse/accounting/etc all become much simpler with static addresses. But as long as you give those users dynamic addresses, they might not run a SMTP/HTTP/xxx server on their link as changing IPs is kind-of-annoying (but doable with the proper DNS setup and low TTLs) Thus, you give them dynamic stuff, or only 1 IP address and ask them for lots of moneys when they want a static address or hey lots more moneys (in the form of a 'business connection') when they want multiple addresses routed to their host. And don't bother asking for proper reverse setup in a lot of cases either, let alone delegation of that. Greets, Jeroen Happily using the same static IPv6 /48 for almost a decade ;) From nate at blastcomm.com Tue Jul 26 10:07:37 2011 From: nate at blastcomm.com (Nate Burke) Date: Tue, 26 Jul 2011 10:07:37 -0500 Subject: Comcast Bussiness Class and GRE Tunnels Message-ID: <4E2ED839.5090709@blastcomm.com> Hello, I'm hoping that someone here might have run into a similar issue and might be able to offer me some pointers. I have a customer that I am providing redundant paths to, one link over a microwave connection, and a backup link over a Comcast Business Class Connection. Everything on the Microwave link is working fine. On the Comcast Connection, I have a Static IP from Comcast, and I want to setup a vendor specific GRE tunnel (Mikrotik EoIP) from my NOC to the Comcast Static IP Address. It looks like the SPI Firewall inside the SMC Gateway required by comcast is blocking the GRE packets, I'm basing this on the fact that when I power cycle the modem, I get 1 ICMP Packet through the GRE Tunnel while the modem is booting up, then it stops again. I have gotten to Tier2 support who swears that all Firewalls on the SMC Gateway are disabled. As a workaround, I was able to establish a PPTP tunnel to my NOC, however it seems like the tunnel will only run for a few hours, then becomes slow to the point of being unusable. In my mind this would be no different than setting up a permanent VPN back to a corporate office, which I would think happens all the time, so I'm not sure why I'm running into issues with it. Anyone with Insights or comments would be appreciated. Thanks, Nate Burke From morrowc.lists at gmail.com Tue Jul 26 10:09:25 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 26 Jul 2011 11:09:25 -0400 Subject: OOB In-Reply-To: <01ae01cc4ba5$581722a0$084567e0$@org> References: <018501cc4b9c$bdb1f6c0$3915e440$@org> <01ae01cc4ba5$581722a0$084567e0$@org> Message-ID: On Tue, Jul 26, 2011 at 11:04 AM, Paul Stewart wrote: > Honestly - in our core network, this has only happened once in almost 10 > years... seriously. ?Everything in our core networks is redundant ... yes, I > know redundancy breaks of course ;) > I hear you. > When it did happen, we had remote hands reboot the equipment and everything > was restored in approximately 30 minutes. > lucky that the breakage wasn't in east-elbonia...cause that does suck. "yea, we'll have to get someone on a plane, it'll be up in about 8 hrs..." > I'm not saying boldly that we won't get caught with our pants down some day > - just that previous experience has shown us to be prepared for the worst > and the worst hasn't occurred. We have looked at OOB options and it's been > discussed many times - it just slips off the radar constantly. ?Maybe it's > "once bitten, twice shy" that needs to occur for the priority to change > again. perhaps. but given a clean slate, would you: 1) live with more redundancy in the core and hope that you don't lose access to things downstream from a problem (or the problemchild itself) 2) think about a solution to provide OOB access via another infrastructure? Presume you can figure the costs as well so loss of a node/set-of-nodes SLA-wise is more expensive than 1yr of oob access? -chris > > -----Original Message----- > From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On > Behalf Of Christopher Morrow > Sent: Tuesday, July 26, 2011 10:14 AM > To: Paul Stewart > Cc: NANOG list > Subject: Re: OOB > > On Tue, Jul 26, 2011 at 10:03 AM, Paul Stewart wrote: >> We do everything in-band with strict monitoring/policies in place. > > what do you do if your in-band fails? if a router/switch/ROADM is > isolated from the rest of your network? > (isn't that the core point of the OP?) > >> -----Original Message----- >> From: harbor235 [mailto:harbor235 at gmail.com] >> Sent: Tuesday, July 26, 2011 9:57 AM >> To: NANOG list >> Subject: OOB >> >> I am curious what is the best practice for OOB for a core >> infrastructure environment. Obviously, there is >> an OOB kit for customer managed devices via POTS, Ethernet, etc ... And >> there is OOB for core infrastructure >> typically a separate basic network that utilizes diverse carrier and > diverse >> path when available. >> >> My question is, is it best practice to extend an inband VPN throughout for >> device management functions as well? >> And are all management services performed OOB, e.g network management, > some >> monitoring, logging, >> authentication, flowdata, etc ..... If a management VPN is used is it also >> extended to managed customer devices? >> >> What else is can be done for remote management and troubleshooting >> capabilities? >> >> Mike >> >> >> > > From jordi.palet at consulintel.es Tue Jul 26 10:18:37 2011 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 26 Jul 2011 11:18:37 -0400 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <4E2ED7C5.1040702@unfix.org> Message-ID: Agree with all your points. Also, one can argue that a dynamic prefix facilitates privacy ? However, if ISPs or third party companies (and thus users ask for more and more bw) want to offer new services and apps with IPv6, it will be much easier to implement with static prefixes. Regards, Jordi -----Mensaje original----- De: Jeroen Massar Organizaci?n: Unfix Responder a: Fecha: Tue, 26 Jul 2011 17:05:41 +0200 Para: Jordi Palet Martinez CC: NANOG list Asunto: Re: dynamic or static IPv6 prefixes to residential customers >On 2011-07-26 16:58 , JORDI PALET MARTINEZ wrote: >> Hi all, >> >> I will like to know, from those deploying IPv6 services to residential >> customers, if you are planning to provide static or dynamic IPv6 >>prefixes. >> >> Just to be clear, I'm for static prefix delegation to residential >> customers, however I heard that some ISPs are doing dynamic delegations, >> the same way as is common today with IPv4. >> >> I don't thin it make sense, as the main reason for doing so in IPv4 was >> address exhaustion and legacy oversubscription models such as >>PPP/dial-up. > >You are forgetting the simple fact that you can charge for static >addresses and unblocked connectivity. THAT is the reason for dynamic >addresses, as on the ISP level there are still enough IPv4 addresses and >they can still, even today, ask for more from their RIR. > >Abuse/accounting/etc all become much simpler with static addresses. > >But as long as you give those users dynamic addresses, they might not >run a SMTP/HTTP/xxx server on their link as changing IPs is >kind-of-annoying (but doable with the proper DNS setup and low TTLs) > >Thus, you give them dynamic stuff, or only 1 IP address and ask them for >lots of moneys when they want a static address or hey lots more moneys >(in the form of a 'business connection') when they want multiple >addresses routed to their host. > >And don't bother asking for proper reverse setup in a lot of cases >either, let alone delegation of that. > >Greets, > Jeroen > Happily using the same static IPv6 /48 for almost a decade ;) ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From bmanning at vacation.karoshi.com Tue Jul 26 10:21:12 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 26 Jul 2011 15:21:12 +0000 Subject: OOB In-Reply-To: References: <018501cc4b9c$bdb1f6c0$3915e440$@org> <01ae01cc4ba5$581722a0$084567e0$@org> Message-ID: <20110726152112.GB27650@vacation.karoshi.com.> > > perhaps. but given a clean slate, would you: > > 1) live with more redundancy in the core and hope that you don't lose > access to things downstream from a problem (or the problemchild > itself) > 2) think about a solution to provide OOB access via another infrastructure? > > > Presume you can figure the costs as well so loss of a > node/set-of-nodes SLA-wise is more expensive than 1yr of oob access? > > -chris > for those w/ OOB built on PSTN or other non-IP based fabrics, how much would it hurt if the PSTN went away? /bill From nick at flhsi.com Tue Jul 26 10:34:25 2011 From: nick at flhsi.com (Nick Olsen) Date: Tue, 26 Jul 2011 11:34:25 -0400 Subject: Comcast Bussiness Class and GRE Tunnels Message-ID: <6fad71f3$7d914355$2301cc2c$@com> I had to deal with this Exact problem last week. Never got EOIP to work, Spent hours on it. I had to use a "GRE Tunnel" Which is the same thing. And is only available under RouterOS 5.x+. Came right up when EOIP wouldn't. I don't know how to peg the problem. As PPTP, EOIP, GRE...etc All use the GRE protocol 47. So you would think they all would show the same problem. I never even attempted to contact comcast support as I wasn't about to spend another 3 hours explaining my problem only for them to say they aren't blocking anything and it must be my side.. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Nate Burke" Sent: Tuesday, July 26, 2011 11:07 AM To: "NANOG list" Subject: Comcast Bussiness Class and GRE Tunnels Hello, I'm hoping that someone here might have run into a similar issue and might be able to offer me some pointers. I have a customer that I am providing redundant paths to, one link over a microwave connection, and a backup link over a Comcast Business Class Connection. Everything on the Microwave link is working fine. On the Comcast Connection, I have a Static IP from Comcast, and I want to setup a vendor specific GRE tunnel (Mikrotik EoIP) from my NOC to the Comcast Static IP Address. It looks like the SPI Firewall inside the SMC Gateway required by comcast is blocking the GRE packets, I'm basing this on the fact that when I power cycle the modem, I get 1 ICMP Packet through the GRE Tunnel while the modem is booting up, then it stops again. I have gotten to Tier2 support who swears that all Firewalls on the SMC Gateway are disabled. As a workaround, I was able to establish a PPTP tunnel to my NOC, however it seems like the tunnel will only run for a few hours, then becomes slow to the point of being unusable. In my mind this would be no different than setting up a permanent VPN back to a corporate office, which I would think happens all the time, so I'm not sure why I'm running into issues with it. Anyone with Insights or comments would be appreciated. Thanks, Nate Burke From cb.list6 at gmail.com Tue Jul 26 10:34:36 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Tue, 26 Jul 2011 08:34:36 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: Message-ID: On Jul 26, 2011 7:58 AM, "JORDI PALET MARTINEZ" wrote: > > Hi all, > > I will like to know, from those deploying IPv6 services to residential > customers, if you are planning to provide static or dynamic IPv6 prefixes. > > Just to be clear, I'm for static prefix delegation to residential > customers, however I heard that some ISPs are doing dynamic delegations, > the same way as is common today with IPv4. > > I don't thin it make sense, as the main reason for doing so in IPv4 was > address exhaustion and legacy oversubscription models such as PPP/dial-up. > In mobile, v6 addresses will be dynamic with no persistence across link state changes. Cb > Regards, > Jordi > > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > From rdobbins at arbor.net Tue Jul 26 10:37:50 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 26 Jul 2011 15:37:50 +0000 Subject: OOB In-Reply-To: References: Message-ID: On Jul 26, 2011, at 8:57 PM, harbor235 wrote: > My question is, is it best practice to extend an inband VPN throughout for device management functions as well? Going inband defeats the purpose of the DCN. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From paul4004 at gmail.com Tue Jul 26 10:38:38 2011 From: paul4004 at gmail.com (PC) Date: Tue, 26 Jul 2011 09:38:38 -0600 Subject: Comcast Bussiness Class and GRE Tunnels In-Reply-To: <4E2ED839.5090709@blastcomm.com> References: <4E2ED839.5090709@blastcomm.com> Message-ID: I have GRE tunnels and l2tp tunnels over those comcast boxes. l2tp is less hassle because it handles NAT, but you can do GRE instead -- just make sure you assign yourself a public static IP. First, go into the gateway and make sure all firewalls are disabled (it has a web GUI). Second, if it's the comcast SMC 4 port "gateway" thing I think it is, the device is somewhat retarded. You plug into the switch and pull DHCP, and you get a natted address and it routes. You can plug into the same switch and set a static IP on your device (internet public IP), and it will work without NAT, assuming your account has a static IP. Set said static IP on your microtik box and it should pass end-to-end without drops. On Tue, Jul 26, 2011 at 9:07 AM, Nate Burke wrote: > Hello, I'm hoping that someone here might have run into a similar issue and > might be able to offer me some pointers. > > I have a customer that I am providing redundant paths to, one link over a > microwave connection, and a backup link over a Comcast Business Class > Connection. Everything on the Microwave link is working fine. On the > Comcast Connection, I have a Static IP from Comcast, and I want to setup a > vendor specific GRE tunnel (Mikrotik EoIP) from my NOC to the Comcast Static > IP Address. It looks like the SPI Firewall inside the SMC Gateway required > by comcast is blocking the GRE packets, I'm basing this on the fact that > when I power cycle the modem, I get 1 ICMP Packet through the GRE Tunnel > while the modem is booting up, then it stops again. I have gotten to Tier2 > support who swears that all Firewalls on the SMC Gateway are disabled. > > As a workaround, I was able to establish a PPTP tunnel to my NOC, however > it seems like the tunnel will only run for a few hours, then becomes slow to > the point of being unusable. In my mind this would be no different than > setting up a permanent VPN back to a corporate office, which I would think > happens all the time, so I'm not sure why I'm running into issues with it. > > Anyone with Insights or comments would be appreciated. > > Thanks, > Nate Burke > > From jon at nnbfn.net Tue Jul 26 10:45:30 2011 From: jon at nnbfn.net (Jon Bane) Date: Tue, 26 Jul 2011 11:45:30 -0400 Subject: Comcast Bussiness Class and GRE Tunnels In-Reply-To: References: <4E2ED839.5090709@blastcomm.com> Message-ID: On Tue, Jul 26, 2011 at 11:38 AM, PC wrote: > I have GRE tunnels and l2tp tunnels over those comcast boxes. l2tp is less > hassle because it handles NAT, but you can do GRE instead -- just make sure > you assign yourself a public static IP. > > First, go into the gateway and make sure all firewalls are disabled (it has > a web GUI). > > Second, if it's the comcast SMC 4 port "gateway" thing I think it is, the > device is somewhat retarded. You plug into the switch and pull DHCP, and > you get a natted address and it routes. > > You can plug into the same switch and set a static IP on your device > (internet public IP), and it will work without NAT, assuming your account > has a static IP. > > Set said static IP on your microtik box and it should pass end-to-end > without drops. > > Was working on the same reply as Paul. You assign your static to your Mircotik box and check the box in the WebGUI (default is http://10.1.10.1) to "Disable Firewall for True Static IP Subnet Only" on the firewall tab. -Jon From sethm at rollernet.us Tue Jul 26 10:50:31 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 26 Jul 2011 08:50:31 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: Message-ID: <4E2EE247.8060909@rollernet.us> On 7/26/11 7:58 AM, JORDI PALET MARTINEZ wrote: > Hi all, > > I will like to know, from those deploying IPv6 services to residential > customers, if you are planning to provide static or dynamic IPv6 prefixes. > Static everywhere for me, including residential customers. ~Seth From jordi.palet at consulintel.es Tue Jul 26 11:11:51 2011 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 26 Jul 2011 12:11:51 -0400 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: Message-ID: Hi Cameron, What about routers ? In some locations, users may have only the choice of cellular broadband instead of DSL, cable or fiber. Regards, Jordi -----Mensaje original----- De: Cameron Byrne Responder a: Fecha: Tue, 26 Jul 2011 08:34:36 -0700 Para: Jordi Palet Martinez CC: NANOG list Asunto: Re: dynamic or static IPv6 prefixes to residential customers > >On Jul 26, 2011 7:58 AM, "JORDI PALET MARTINEZ" > wrote: >> >> Hi all, >> >> I will like to know, from those deploying IPv6 services to residential >> customers, if you are planning to provide static or dynamic IPv6 >>prefixes. >> >> Just to be clear, I'm for static prefix delegation to residential >> customers, however I heard that some ISPs are doing dynamic delegations, >> the same way as is common today with IPv4. >> >> I don't thin it make sense, as the main reason for doing so in IPv4 was >> address exhaustion and legacy oversubscription models such as >>PPP/dial-up. >> >In mobile, v6 addresses will be dynamic with no persistence across link >state changes. >Cb >> Regards, >> Jordi >> >> >> >> >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.consulintel.es >> The IPv6 Company >> >> This electronic message contains information which may be privileged or >>confidential. The information is intended to be for the use of the >>individual(s) named above. If you are not the intended recipient be >>aware that any disclosure, copying, distribution or use of the contents >>of this information, including attached files, is prohibited. > >> >> >> >> > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From joelja at bogus.com Tue Jul 26 11:17:36 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 26 Jul 2011 12:17:36 -0400 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: Message-ID: given how often the cellular address changes on my Verizon 4g router not to mention the external ip address on their LSN I think I can speculate... joel On Jul 26, 2011, at 12:11 PM, JORDI PALET MARTINEZ wrote: > Hi Cameron, > > What about routers ? In some locations, users may have only the choice of > cellular broadband instead of DSL, cable or fiber. > > Regards, > Jordi > > > > > > > -----Mensaje original----- > De: Cameron Byrne > Responder a: > Fecha: Tue, 26 Jul 2011 08:34:36 -0700 > Para: Jordi Palet Martinez > CC: NANOG list > Asunto: Re: dynamic or static IPv6 prefixes to residential customers > >> >> On Jul 26, 2011 7:58 AM, "JORDI PALET MARTINEZ" >> wrote: >>> >>> Hi all, >>> >>> I will like to know, from those deploying IPv6 services to residential >>> customers, if you are planning to provide static or dynamic IPv6 >>> prefixes. >>> >>> Just to be clear, I'm for static prefix delegation to residential >>> customers, however I heard that some ISPs are doing dynamic delegations, >>> the same way as is common today with IPv4. >>> >>> I don't thin it make sense, as the main reason for doing so in IPv4 was >>> address exhaustion and legacy oversubscription models such as >>> PPP/dial-up. >>> >> In mobile, v6 addresses will be dynamic with no persistence across link >> state changes. >> Cb >>> Regards, >>> Jordi >>> >>> >>> >>> >>> >>> >>> ********************************************** >>> IPv4 is over >>> Are you ready for the new Internet ? >>> http://www.consulintel.es >>> The IPv6 Company >>> >>> This electronic message contains information which may be privileged or >>> confidential. The information is intended to be for the use of the >>> individual(s) named above. If you are not the intended recipient be >>> aware that any disclosure, copying, distribution or use of the contents >>> of this information, including attached files, is prohibited. >> >>> >>> >>> >>> >> > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > From cb.list6 at gmail.com Tue Jul 26 11:29:44 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Tue, 26 Jul 2011 09:29:44 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: Message-ID: On Tue, Jul 26, 2011 at 9:11 AM, JORDI PALET MARTINEZ wrote: > Hi Cameron, > > What about routers ? In some locations, users may have only the choice of > cellular broadband instead of DSL, cable or fiber. > >From an architectural perspective, mobile broadband routers are treated the same and can expect only ephemeral address assignments. This is the general case for generic mobile devices accessing the internet, there can be specific arrangements for specific industrial use cases (this traffic signal/ gas meter/ windmill always gets this address). Cameron > Regards, > Jordi > > > > > > > -----Mensaje original----- > De: Cameron Byrne > Responder a: > Fecha: Tue, 26 Jul 2011 08:34:36 -0700 > Para: Jordi Palet Martinez > CC: NANOG list > Asunto: Re: dynamic or static IPv6 prefixes to residential customers > >> >>On Jul 26, 2011 7:58 AM, "JORDI PALET MARTINEZ" >> wrote: >>> >>> Hi all, >>> >>> I will like to know, from those deploying IPv6 services to residential >>> customers, if you are planning to provide static or dynamic IPv6 >>>prefixes. >>> >>> Just to be clear, I'm for static prefix delegation to residential >>> customers, however I heard that some ISPs are doing dynamic delegations, >>> the same way as is common today with IPv4. >>> >>> I don't thin it make sense, as the main reason for doing so in IPv4 was >>> address exhaustion and legacy oversubscription models such as >>>PPP/dial-up. >>> >>In mobile, v6 addresses will be dynamic with no persistence across link >>state changes. >>Cb >>> Regards, >>> Jordi >>> >>> >>> >>> >>> >>> >>> ********************************************** >>> IPv4 is over >>> Are you ready for the new Internet ? >>> http://www.consulintel.es >>> The IPv6 Company >>> >>> This electronic message contains information which may be privileged or >>>confidential. The information is intended to be for the use of the >>>individual(s) named above. If you are not the intended recipient be >>>aware that any disclosure, copying, distribution or use of the contents >>>of this information, including attached files, is prohibited. >> >>> >>> >>> >>> >> > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > > From nate at blastcomm.com Tue Jul 26 11:46:55 2011 From: nate at blastcomm.com (Nate Burke) Date: Tue, 26 Jul 2011 11:46:55 -0500 Subject: Comcast Bussiness Class and GRE Tunnels In-Reply-To: References: <4E2ED839.5090709@blastcomm.com> Message-ID: <4E2EEF7F.3010307@blastcomm.com> Thanks for all the replies, I have all the firewalls disabled on the SMC Modem, with my Static IP set on the Mikrotik. The PPTP Tunnel came up and ran just fine when I configured it, it was working great when I left the office last night, but this morning It was running very slow. I just setup an IPIP tunnel, and did my EOIP tunnel over that, and it came right up, we'll see if it's still working in a few hours. Nate On 7/26/2011 10:45 AM, Jon Bane wrote: > On Tue, Jul 26, 2011 at 11:38 AM, PC wrote: > >> I have GRE tunnels and l2tp tunnels over those comcast boxes. l2tp is less >> hassle because it handles NAT, but you can do GRE instead -- just make sure >> you assign yourself a public static IP. >> >> First, go into the gateway and make sure all firewalls are disabled (it has >> a web GUI). >> >> Second, if it's the comcast SMC 4 port "gateway" thing I think it is, the >> device is somewhat retarded. You plug into the switch and pull DHCP, and >> you get a natted address and it routes. >> >> You can plug into the same switch and set a static IP on your device >> (internet public IP), and it will work without NAT, assuming your account >> has a static IP. >> >> Set said static IP on your microtik box and it should pass end-to-end >> without drops. >> >> > Was working on the same reply as Paul. You assign your static to your > Mircotik box and check the box in the WebGUI (default is http://10.1.10.1) > to "Disable Firewall for True Static IP Subnet Only" on the firewall tab. > > -Jon From daniel.unam.ipv6 at gmail.com Tue Jul 26 11:59:39 2011 From: daniel.unam.ipv6 at gmail.com (Daniel Espejel) Date: Tue, 26 Jul 2011 11:59:39 -0500 Subject: dynamic or static IPv6 prefixes to residential customers Message-ID: Just like the song: "...you know is sad but true..". ISPs and a few vendors offers IPv6 cappabilities as an add-on on its commercial portfolios. For the static v6 address assignment, applies the same. Even if for users represents advantages on having it's own unique address (i.e. in order to enter the Web or apps service providers world for their own), as so for ISPs to perform some network administrative tasks. I favor static prefix assignation over dynamic, but also I think that for some time (more or less until vendors and providers recovers invertion and operation costs) this will be a "expensive product" to adquire. *Daniel Espejel Perez * From smb at cs.columbia.edu Tue Jul 26 12:01:38 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Tue, 26 Jul 2011 13:01:38 -0400 Subject: Comcast Bussiness Class and GRE Tunnels In-Reply-To: <4E2ED839.5090709@blastcomm.com> References: <4E2ED839.5090709@blastcomm.com> Message-ID: On Jul 26, 2011, at 11:07 37AM, Nate Burke wrote: > Hello, I'm hoping that someone here might have run into a similar issue and might be able to offer me some pointers. > > I have a customer that I am providing redundant paths to, one link over a microwave connection, and a backup link over a Comcast Business Class Connection. Everything on the Microwave link is working fine. On the Comcast Connection, I have a Static IP from Comcast, and I want to setup a vendor specific GRE tunnel (Mikrotik EoIP) from my NOC to the Comcast Static IP Address. It looks like the SPI Firewall inside the SMC Gateway required by comcast is blocking the GRE packets, I'm basing this on the fact that when I power cycle the modem, I get 1 ICMP Packet through the GRE Tunnel while the modem is booting up, then it stops again. I have gotten to Tier2 support who swears that all Firewalls on the SMC Gateway are disabled. > > As a workaround, I was able to establish a PPTP tunnel to my NOC, however it seems like the tunnel will only run for a few hours, then becomes slow to the point of being unusable. In my mind this would be no different than setting up a permanent VPN back to a corporate office, which I would think happens all the time, so I'm not sure why I'm running into issues with it. > I had to make the LAN end of the tunnel the "DMZ host" (under Firewall settings on my SMC). --Steve Bellovin, https://www.cs.columbia.edu/~smb From ikiris at gmail.com Tue Jul 26 12:03:28 2011 From: ikiris at gmail.com (Blake Dunlap) Date: Tue, 26 Jul 2011 12:03:28 -0500 Subject: Comcast Bussiness Class and GRE Tunnels In-Reply-To: <4E2EEF7F.3010307@blastcomm.com> References: <4E2ED839.5090709@blastcomm.com> <4E2EEF7F.3010307@blastcomm.com> Message-ID: Good luck. My experience with GRE over comcast business was a *nightmare*. The web interface seems like it has a random roll to corrupt the firewall config when doing any GRE config, and you must get level 2 support to fix it each time using a l2 only CLI. -Blake From owen at delong.com Tue Jul 26 12:06:15 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Jul 2011 10:06:15 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <4E2ED7C5.1040702@unfix.org> References: <4E2ED7C5.1040702@unfix.org> Message-ID: On Jul 26, 2011, at 8:05 AM, Jeroen Massar wrote: > On 2011-07-26 16:58 , JORDI PALET MARTINEZ wrote: >> Hi all, >> >> I will like to know, from those deploying IPv6 services to residential >> customers, if you are planning to provide static or dynamic IPv6 prefixes. >> We (Hurricane Electric) provide statics to all of our customers. >> Just to be clear, I'm for static prefix delegation to residential >> customers, however I heard that some ISPs are doing dynamic delegations, >> the same way as is common today with IPv4. >> >> I don't thin it make sense, as the main reason for doing so in IPv4 was >> address exhaustion and legacy oversubscription models such as PPP/dial-up. > > You are forgetting the simple fact that you can charge for static > addresses and unblocked connectivity. THAT is the reason for dynamic > addresses, as on the ISP level there are still enough IPv4 addresses and > they can still, even today, ask for more from their RIR. > You can only charge for static addresses as long as your competitors don't. Hopefullly with IPv6, that model will go the way of the dodo. > Abuse/accounting/etc all become much simpler with static addresses. > > But as long as you give those users dynamic addresses, they might not > run a SMTP/HTTP/xxx server on their link as changing IPs is > kind-of-annoying (but doable with the proper DNS setup and low TTLs) > Let's face it, the users that are going to run an SMTP/HTTP/xxx server on their link are probably the ones that know how to use dyndns or some other mechanism to cope with the dynamic address issue. The ones that aren't already running such services with dynamic IPs are probably not significantly more likely to do so with static. > Thus, you give them dynamic stuff, or only 1 IP address and ask them for > lots of moneys when they want a static address or hey lots more moneys > (in the form of a 'business connection') when they want multiple > addresses routed to their host. > I don't think this will fly with IPv6 since free tunnels are a simple solution where you can get a /48 for free regardless of what your ISP does to you. I think that this is a temporary problem and that IPv6 will prove to be a game-changer in this arena. > And don't bother asking for proper reverse setup in a lot of cases > either, let alone delegation of that. > Again, I think other than cable MSOs where they have strong topological reasons to prevent static addressing, IPv6 will see the return of unfettered static addressing and multiple addresses as the default for end users. I realize there is some resistance to the idea of /48s among some residential providers at this point, but, the majority of them are talking about at least using /56s or better, so, I don't think /128s are at all likely. > Greets, > Jeroen > Happily using the same static IPv6 /48 for almost a decade ;) Owen Happily using the same RIR-direct-assigned /48 at home for almost 4 years. From owen at delong.com Tue Jul 26 12:14:15 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Jul 2011 10:14:15 -0700 Subject: Comcast Bussiness Class and GRE Tunnels In-Reply-To: References: <4E2ED839.5090709@blastcomm.com> Message-ID: I needed fast reliable internet access at home, so, I have Comcast Business Class for fast and Raw Bandwidth DSL for reliable. I have my own ARIN direct assignments for my internal networks and I have routers in a couple of colo's where I get my true upstream connectivity. I run a Juniper router here at home and in one of the colo's. In the other colo, I use the datacenter's router to terminate the tunnels. I use GRE tunnels to both cool's across both Comcast and Raw Bandwidth and run BGP to my house (small router) feeding default to the house and getting the local prefixes (192.159.10.0/24, 192.124.40.0/23, 2620:0:930::/48) advertised upstream to the colo routers. The colo routers are full-feed BGP speakers. My Comcast gateway is running in straight L2 bridge mode, so, there is no issue there. When Comcast changes my IP address, things get very slow until I can reconfigure the tunnel end-points. Raw Bandwidth provides me with a static address. I'm not doing any NAT and the GRE tunnels carry all of my actual traffic. The Comcast and Raw Bandwidth internet feeds are used only to provide L2 transport for the GRE tunnels. This allows me to do convenient cost-effective multihoming without NAT at home using commodity internet access. Owen On Jul 26, 2011, at 8:38 AM, PC wrote: > I have GRE tunnels and l2tp tunnels over those comcast boxes. l2tp is less > hassle because it handles NAT, but you can do GRE instead -- just make sure > you assign yourself a public static IP. > > First, go into the gateway and make sure all firewalls are disabled (it has > a web GUI). > > Second, if it's the comcast SMC 4 port "gateway" thing I think it is, the > device is somewhat retarded. You plug into the switch and pull DHCP, and > you get a natted address and it routes. > > You can plug into the same switch and set a static IP on your device > (internet public IP), and it will work without NAT, assuming your account > has a static IP. > > Set said static IP on your microtik box and it should pass end-to-end > without drops. > > On Tue, Jul 26, 2011 at 9:07 AM, Nate Burke wrote: > >> Hello, I'm hoping that someone here might have run into a similar issue and >> might be able to offer me some pointers. >> >> I have a customer that I am providing redundant paths to, one link over a >> microwave connection, and a backup link over a Comcast Business Class >> Connection. Everything on the Microwave link is working fine. On the >> Comcast Connection, I have a Static IP from Comcast, and I want to setup a >> vendor specific GRE tunnel (Mikrotik EoIP) from my NOC to the Comcast Static >> IP Address. It looks like the SPI Firewall inside the SMC Gateway required >> by comcast is blocking the GRE packets, I'm basing this on the fact that >> when I power cycle the modem, I get 1 ICMP Packet through the GRE Tunnel >> while the modem is booting up, then it stops again. I have gotten to Tier2 >> support who swears that all Firewalls on the SMC Gateway are disabled. >> >> As a workaround, I was able to establish a PPTP tunnel to my NOC, however >> it seems like the tunnel will only run for a few hours, then becomes slow to >> the point of being unusable. In my mind this would be no different than >> setting up a permanent VPN back to a corporate office, which I would think >> happens all the time, so I'm not sure why I'm running into issues with it. >> >> Anyone with Insights or comments would be appreciated. >> >> Thanks, >> Nate Burke >> >> From owen at delong.com Tue Jul 26 12:24:13 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Jul 2011 10:24:13 -0700 Subject: Comcast Bussiness Class and GRE Tunnels In-Reply-To: References: <4E2ED839.5090709@blastcomm.com> <4E2EEF7F.3010307@blastcomm.com> Message-ID: <0C9EA3FE-585F-46C8-AAB8-AAFAFCDF3523@delong.com> The best thing to do is supply your own GRE router and have the Comcast gateway operate as a dumb simple ethernet bridge. Owen On Jul 26, 2011, at 10:03 AM, Blake Dunlap wrote: > Good luck. My experience with GRE over comcast business was a *nightmare*. > The web interface seems like it has a random roll to corrupt the firewall > config when doing any GRE config, and you must get level 2 support to fix it > each time using a l2 only CLI. > > -Blake From jason at thebaughers.com Tue Jul 26 12:35:08 2011 From: jason at thebaughers.com (Jason Baugher) Date: Tue, 26 Jul 2011 12:35:08 -0500 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: <4E2ED7C5.1040702@unfix.org> Message-ID: <4E2EFACC.4010906@thebaughers.com> On 7/26/2011 12:06 PM, Owen DeLong wrote: > On Jul 26, 2011, at 8:05 AM, Jeroen Massar wrote: > >> On 2011-07-26 16:58 , JORDI PALET MARTINEZ wrote: >>> Hi all, >>> >>> I will like to know, from those deploying IPv6 services to residential >>> customers, if you are planning to provide static or dynamic IPv6 prefixes. >>> > We (Hurricane Electric) provide statics to all of our customers. > >>> Just to be clear, I'm for static prefix delegation to residential >>> customers, however I heard that some ISPs are doing dynamic delegations, >>> the same way as is common today with IPv4. >>> >>> I don't thin it make sense, as the main reason for doing so in IPv4 was >>> address exhaustion and legacy oversubscription models such as PPP/dial-up. >> You are forgetting the simple fact that you can charge for static >> addresses and unblocked connectivity. THAT is the reason for dynamic >> addresses, as on the ISP level there are still enough IPv4 addresses and >> they can still, even today, ask for more from their RIR. >> > You can only charge for static addresses as long as your competitors don't. > Hopefullly with IPv6, that model will go the way of the dodo. > >> Abuse/accounting/etc all become much simpler with static addresses. >> >> But as long as you give those users dynamic addresses, they might not >> run a SMTP/HTTP/xxx server on their link as changing IPs is >> kind-of-annoying (but doable with the proper DNS setup and low TTLs) >> > Let's face it, the users that are going to run an SMTP/HTTP/xxx server on their > link are probably the ones that know how to use dyndns or some other mechanism > to cope with the dynamic address issue. The ones that aren't already running > such services with dynamic IPs are probably not significantly more likely to do > so with static. > >> Thus, you give them dynamic stuff, or only 1 IP address and ask them for >> lots of moneys when they want a static address or hey lots more moneys >> (in the form of a 'business connection') when they want multiple >> addresses routed to their host. >> > I don't think this will fly with IPv6 since free tunnels are a simple solution where > you can get a /48 for free regardless of what your ISP does to you. I think that > this is a temporary problem and that IPv6 will prove to be a game-changer > in this arena. > >> And don't bother asking for proper reverse setup in a lot of cases >> either, let alone delegation of that. >> > Again, I think other than cable MSOs where they have strong topological > reasons to prevent static addressing, IPv6 will see the return of unfettered > static addressing and multiple addresses as the default for end users. > I realize there is some resistance to the idea of /48s among some residential > providers at this point, but, the majority of them are talking about at least > using /56s or better, so, I don't think /128s are at all likely. > >> Greets, >> Jeroen >> Happily using the same static IPv6 /48 for almost a decade ;) > > Owen > Happily using the same RIR-direct-assigned /48 at home for almost 4 years. > > > It's very interesting to hear the majority of you promoting static over dynamic. We are just now starting to work with IPv6 now that our upstreams are willing to give us dual-stack. We've always been a static shop, but sales has been pushing for dynamic for years due to what people have mentioned earlier, the ability to up-sell statics to customers. We prefer static because of the easy tracking of customers for abuse/spam/DMCA complaints and we don't need to worry about DHCP servers. It's heartening to see others of the same mindset encouraging static for IPv6 allocation. Jason From lists at beatmixed.com Tue Jul 26 12:42:09 2011 From: lists at beatmixed.com (Matt Hite) Date: Tue, 26 Jul 2011 10:42:09 -0700 Subject: "L3DSR -- Overcoming Layer 2 Limitations of Direct Server Return Load Balancing" Video? Message-ID: Might someone have the video for this presentation in their personal stash? http://www.nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk45.nanog51-Schaumann.pdf http://www.nanog.org/meetings/nanog51/abstracts.php?pt=MTc1MyZuYW5vZzUx&nm=nanog51 It would be much appreciated! -M From leigh.porter at ukbroadband.com Tue Jul 26 13:49:04 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 26 Jul 2011 18:49:04 +0000 Subject: OOB In-Reply-To: <4E2ED5FC.5020700@utc.edu> References: <018501cc4b9c$bdb1f6c0$3915e440$@org> <1A8A762BD508624A8BDAB9F5E1638F945FB7FDE542@comsrv01.fg.local>, <4E2ED5FC.5020700@utc.edu> Message-ID: We have a management VRF/L3VPN across the network but we also have automatic backup via a OOB network. The OOB network is cheap, based on 3rd party ADSL connectivity that does not touch our network or rely on IXs etc. We then run IPSec over the ADSL network. The probability of both our node AND the DSL going down at the same time is minimal, especially as the DSL is copper to a local exchange. -- Leigh Porter ________________________________________ From: Jeff Kell [jeff-kell at utc.edu] Sent: 26 July 2011 16:00 To: nanog Subject: Re: OOB On 7/26/2011 10:19 AM, Jensen Tyler wrote: > We use a console server like 'opengear' with either a POTS or wireless broadband to provide access to stranded network. > We use a management VRF (which is still technically in-band, but otherwise quite isolated), plus a few terminal servers for out-of-band console access to the critical devices. Jeff ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From tknchris at gmail.com Tue Jul 26 13:55:28 2011 From: tknchris at gmail.com (chris) Date: Tue, 26 Jul 2011 14:55:28 -0400 Subject: Comcast Bussiness Class and GRE Tunnels In-Reply-To: References: <4E2ED839.5090709@blastcomm.com> Message-ID: I also have pretty much the exact same setup and it works very well for me On Tue, Jul 26, 2011 at 1:14 PM, Owen DeLong wrote: > I needed fast reliable internet access at home, so, I have Comcast Business > Class for fast and Raw Bandwidth DSL for reliable. I have my own ARIN > direct assignments for my internal networks and I have routers in a couple > of colo's where I get my true upstream connectivity. > > I run a Juniper router here at home and in one of the colo's. In the other > colo, I use the datacenter's router to terminate the tunnels. I use GRE > tunnels to both cool's across both Comcast and Raw Bandwidth and run > BGP to my house (small router) feeding default to the house and getting > the local prefixes (192.159.10.0/24, 192.124.40.0/23, 2620:0:930::/48) > advertised upstream to the colo routers. > > The colo routers are full-feed BGP speakers. > > My Comcast gateway is running in straight L2 bridge mode, so, there is > no issue there. When Comcast changes my IP address, things get very > slow until I can reconfigure the tunnel end-points. Raw Bandwidth provides > me with a static address. > > I'm not doing any NAT and the GRE tunnels carry all of my actual traffic. > The Comcast and Raw Bandwidth internet feeds are used only to provide > L2 transport for the GRE tunnels. > > This allows me to do convenient cost-effective multihoming without NAT > at home using commodity internet access. > > Owen > > On Jul 26, 2011, at 8:38 AM, PC wrote: > > > I have GRE tunnels and l2tp tunnels over those comcast boxes. l2tp is > less > > hassle because it handles NAT, but you can do GRE instead -- just make > sure > > you assign yourself a public static IP. > > > > First, go into the gateway and make sure all firewalls are disabled (it > has > > a web GUI). > > > > Second, if it's the comcast SMC 4 port "gateway" thing I think it is, the > > device is somewhat retarded. You plug into the switch and pull DHCP, and > > you get a natted address and it routes. > > > > You can plug into the same switch and set a static IP on your device > > (internet public IP), and it will work without NAT, assuming your account > > has a static IP. > > > > Set said static IP on your microtik box and it should pass end-to-end > > without drops. > > > > On Tue, Jul 26, 2011 at 9:07 AM, Nate Burke wrote: > > > >> Hello, I'm hoping that someone here might have run into a similar issue > and > >> might be able to offer me some pointers. > >> > >> I have a customer that I am providing redundant paths to, one link over > a > >> microwave connection, and a backup link over a Comcast Business Class > >> Connection. Everything on the Microwave link is working fine. On the > >> Comcast Connection, I have a Static IP from Comcast, and I want to setup > a > >> vendor specific GRE tunnel (Mikrotik EoIP) from my NOC to the Comcast > Static > >> IP Address. It looks like the SPI Firewall inside the SMC Gateway > required > >> by comcast is blocking the GRE packets, I'm basing this on the fact that > >> when I power cycle the modem, I get 1 ICMP Packet through the GRE Tunnel > >> while the modem is booting up, then it stops again. I have gotten to > Tier2 > >> support who swears that all Firewalls on the SMC Gateway are disabled. > >> > >> As a workaround, I was able to establish a PPTP tunnel to my NOC, > however > >> it seems like the tunnel will only run for a few hours, then becomes > slow to > >> the point of being unusable. In my mind this would be no different than > >> setting up a permanent VPN back to a corporate office, which I would > think > >> happens all the time, so I'm not sure why I'm running into issues with > it. > >> > >> Anyone with Insights or comments would be appreciated. > >> > >> Thanks, > >> Nate Burke > >> > >> > > > From paul at paulstewart.org Tue Jul 26 14:22:10 2011 From: paul at paulstewart.org (Paul Stewart) Date: Tue, 26 Jul 2011 15:22:10 -0400 Subject: IPv6 Linux Server Support Message-ID: <025101cc4bc9$50e77ec0$f2b67c40$@org> Hi there. Has anyone compiled a list of pros/cons on various flavors of Linux specific to IPv6? I realize that's a really broad question.. Specific example would be that we're primarily a CentOS shop - during some testing today found out that connection tracking is broken in 5.6 version (after all kinds of Google hits). I understand 6.0 (recently released) fixes this issue. I have not seen this issue in Debian for example to date. Any input would be appreciated - my question isn't regarding which version folks like better, it's specifically what version works best in an IPv6 server related environment. Thanks, Paul From slz at baycix.de Tue Jul 26 14:28:50 2011 From: slz at baycix.de (Sascha Lenz) Date: Tue, 26 Jul 2011 21:28:50 +0200 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: Message-ID: Hi, > Hi all, > > I will like to know, from those deploying IPv6 services to residential > customers, if you are planning to provide static or dynamic IPv6 prefixes. > > Just to be clear, I'm for static prefix delegation to residential > customers, however I heard that some ISPs are doing dynamic delegations, > the same way as is common today with IPv4. > > I don't thin it make sense, as the main reason for doing so in IPv4 was > address exhaustion and legacy oversubscription models such as PPP/dial-up. well, it does make sense for most of the residential customers nowadays, because they are indoctrinated with this idea of dynamic+NAT == privacy for over a decade now and don't know any better. So, i don't think it's a good idea to hand out static prefixes to residential customers by default, it might cause pain. The best current practice would be, to default to a dynamic prefix, but enable your more advanced customers to change that to a static prefix at will in your customer service web-portal or something. But i have no idea how to sell this to your marketing department. They again are usually used to sell static IPs for an extra fee, and usually don't want to change that with IPv6. That's bullshit for IPv6 of course. (Another idea, which i scrapped after thinking about it in depth was, to hand out a dynamic P2P prefix (/64) + a /56 (or /48) static on top, so the customer/CPE could chose what to use, but that is actually too complicated in the end and would need support in the CPE firmware) -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From owen at delong.com Tue Jul 26 14:34:57 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Jul 2011 12:34:57 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: Message-ID: <0904D2C5-0BBC-40B9-91BB-1677A95C3134@delong.com> On Jul 26, 2011, at 12:28 PM, Sascha Lenz wrote: > Hi, > > >> Hi all, >> >> I will like to know, from those deploying IPv6 services to residential >> customers, if you are planning to provide static or dynamic IPv6 prefixes. >> >> Just to be clear, I'm for static prefix delegation to residential >> customers, however I heard that some ISPs are doing dynamic delegations, >> the same way as is common today with IPv4. >> >> I don't thin it make sense, as the main reason for doing so in IPv4 was >> address exhaustion and legacy oversubscription models such as PPP/dial-up. > > well, it does make sense for most of the residential customers nowadays, because > they are indoctrinated with this idea of dynamic+NAT == privacy for over a decade > now and don't know any better. > IMNSHO, education is always a better alternative than preserving ignorance or worse, mis-information. > So, i don't think it's a good idea to hand out static prefixes to residential customers > by default, it might cause pain. > I think it is an excellent idea to do so. I think that any delusions of privacy achieved through dynamic+NAT are exactly that and need to be shattered. The sooner, the better. > The best current practice would be, to default to a dynamic prefix, but enable your > more advanced customers to change that to a static prefix at will in your customer > service web-portal or something. > Sounds unnecessarily complicated and with absolutely no benefit whatsoever. > But i have no idea how to sell this to your marketing department. > They again are usually used to sell static IPs for an extra fee, and usually don't > want to change that with IPv6. That's bullshit for IPv6 of course. > It was mostly bullshit for IPv4. > (Another idea, which i scrapped after thinking about it in depth was, to hand out > a dynamic P2P prefix (/64) + a /56 (or /48) static on top, so the customer/CPE could chose > what to use, but that is actually too complicated in the end and would need support > in the CPE firmware) > By default, we (Hurricane Electric) hand out a static /64 for the tunnel point-to-point and a static /64 for the customer LAN. Upon request we will also issue the customer a static /48 for their LAN structure. Owen From jschauma at netmeister.org Tue Jul 26 14:54:17 2011 From: jschauma at netmeister.org (Jan Schaumann) Date: Tue, 26 Jul 2011 15:54:17 -0400 Subject: "L3DSR -- Overcoming Layer 2 Limitations of Direct Server Return Load Balancing" Video? In-Reply-To: References: Message-ID: <20110726195417.GA20045@netmeister.org> Matt Hite wrote: > Might someone have the video for this presentation in their personal stash? > > http://www.nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk45.nanog51-Schaumann.pdf I don't have the video handy, but there really wasn't all that much more info in the presentation than in the slides. It might be worth noting that the modules are now open source: https://github.com/yahoo/l3dsr If you have questions, just email me. -Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 478 bytes Desc: not available URL: From rob-lists at bpsnetworks.com Tue Jul 26 15:15:36 2011 From: rob-lists at bpsnetworks.com (Robert Haas) Date: Tue, 26 Jul 2011 15:15:36 -0500 Subject: XO Contact Message-ID: <0f7201cc4bd0$c7e3d620$57ab8260$@com> Can someone from XO contact me (or if someone has a contact within XO, I'd appreciate it). We are having reachability issues from our network 74.91.64.0/20 AS36243 to the XO network. Thanks, Robert Haas 573-293-2638 From dr at cluenet.de Tue Jul 26 16:16:55 2011 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 26 Jul 2011 23:16:55 +0200 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: <4E2ED7C5.1040702@unfix.org> Message-ID: <20110726211655.GA25957@srv03.cluenet.de> On Tue, Jul 26, 2011 at 11:18:37AM -0400, JORDI PALET MARTINEZ wrote: > Also, one can argue that a dynamic prefix facilitates privacy ? In Germany, there is significant political pushback against the idea to give residential mom+pop static prefixed for that very reason. I seriously doubt that any operator with any residential customer base of relevance would go static, here. Upsell opportunity and avoiding customers running services don't seem to be the highest on the list of reasons against static, from what I see. Wether operators enforce randomization of WAN IP and delegated prefix though is another question. There are operators who have "stickyness" for IPv4 (upon reconnect, give the CPE the address it asks for if it's still available). So leases are generally pretty stable over time in that scenario. Others configure their DHCP platform to intentionally randomize. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From mansaxel at besserwisser.org Tue Jul 26 16:34:04 2011 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Tue, 26 Jul 2011 23:34:04 +0200 Subject: OOB In-Reply-To: References: <018501cc4b9c$bdb1f6c0$3915e440$@org> Message-ID: <20110726213404.GG20415@besserwisser.org> Subject: Re: OOB Date: Tue, Jul 26, 2011 at 10:14:21AM -0400 Quoting Christopher Morrow (morrowc.lists at gmail.com): > On Tue, Jul 26, 2011 at 10:03 AM, Paul Stewart wrote: > > We do everything in-band with strict monitoring/policies in place. > > what do you do if your in-band fails? if a router/switch/ROADM is > isolated from the rest of your network? > (isn't that the core point of the OP?) Vendor C sells nice small routers with something like CAB-OCTAL-ASYNC _and_ a 3G modem instead of the BRI port. The 3G modem keeps its connection up (our telecom provider has true flat rate on domestic 3G, YMMV) and VPN's to the head office much like any other telecommuter. This cuts through all telco stupidity with firewalled or NAT'ed 3G phones etc, especially if one uses the break-out-from-hotel-LAN functions of the VPN system. The router of course actively keeps the VPN up and reestablishes it if needed. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I'm wearing PAMPERS!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From tom at ninjabadger.net Tue Jul 26 16:57:20 2011 From: tom at ninjabadger.net (Tom Hill) Date: Tue, 26 Jul 2011 22:57:20 +0100 Subject: IPv6 Linux Server Support In-Reply-To: <025101cc4bc9$50e77ec0$f2b67c40$@org> References: <025101cc4bc9$50e77ec0$f2b67c40$@org> Message-ID: <1311717440.2210.3.camel@teh-desktop> On Tue, 2011-07-26 at 15:22 -0400, Paul Stewart wrote: > Specific example would be that we're primarily a CentOS shop - during > some testing today found out that connection tracking is broken in 5.6 > version (after all kinds of Google hits). I understand 6.0 (recently > released) fixes this issue. I have not seen this issue in Debian for > example to date. This has been my experience, too. In addition to this, there's no LVS (ipvsadm) support in 5.x for IPv6. You have to move to 6.x for this, too. Whilst we could argue over which distribution is better for whatever reason, you use what you have to use usually for much higher-level problems, so tracking the pros and cons relative to those requirements is typically the bigger task. But it's no big deal; CentOS 6 is here (they say 6.1 is happening soon) and SL6 has been been around some time. If all else fails, you could stump-up for a RHEL license. Personally I'm already installing 6.x hosts and shall continue to do so where support for software exists (i.e. Plesk has no official support for CentOS 6.x or Scientific Linux in any form as yet.) Tom From mike at jellydonut.org Tue Jul 26 17:03:30 2011 From: mike at jellydonut.org (Michael Proto) Date: Tue, 26 Jul 2011 18:03:30 -0400 Subject: IPv6 Linux Server Support In-Reply-To: <025101cc4bc9$50e77ec0$f2b67c40$@org> References: <025101cc4bc9$50e77ec0$f2b67c40$@org> Message-ID: On Tue, Jul 26, 2011 at 3:22 PM, Paul Stewart wrote: > Hi there. > > > > Has anyone compiled a list of pros/cons on various flavors of Linux specific > to IPv6? ?I realize that's ?a really broad question.. > > > > Specific example would be that we're primarily a CentOS shop - during some > testing today found out that connection tracking is broken in 5.6 version > (after all kinds of Google hits). ?I understand 6.0 (recently released) > fixes this issue. ?I have not seen this issue in Debian for example to date. > I've tested two Linux distributions in an IPv6 environment, Ubuntu 10.04 Server and CentOS 6. Granted I've only been testing services for a few months now but I've found that both can deliver adequate service delivery via IPv6. I did run into the connection tracking issue with CentOS 5 and you are correct, it is fixed in 6 (its also integrated into the ufw program so setting-up host-based rulesets are very easy in an IPv6 world). In my case, its mainly testing both platforms but I haven't discovered any significant issues with either, and this is running basic services (DNS, HTTP, SMTP, a few little python JSON servers) over a 6in4 tunnel on each platform. -Proto From marka at isc.org Tue Jul 26 17:30:24 2011 From: marka at isc.org (Mark Andrews) Date: Wed, 27 Jul 2011 08:30:24 +1000 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: Your message of "Tue, 26 Jul 2011 23:16:55 +0200." <20110726211655.GA25957@srv03.cluenet.de> References: <4E2ED7C5.1040702@unfix.org> <20110726211655.GA25957@srv03.cluenet.de> Message-ID: <20110726223024.78972123095B@drugs.dv.isc.org> Actually all addresses are dynamic. There are just different lease periods. Year vs day or hours. One can also hand out *multiple* prefixes. Ones with a lease period of year and one with a lease period in hours and let the customer use the most appropriate one for the particular usage needs. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From lists at beatmixed.com Tue Jul 26 17:40:30 2011 From: lists at beatmixed.com (Matt Hite) Date: Tue, 26 Jul 2011 15:40:30 -0700 Subject: "L3DSR -- Overcoming Layer 2 Limitations of Direct Server Return Load Balancing" Video? In-Reply-To: <20110726195417.GA20045@netmeister.org> References: <20110726195417.GA20045@netmeister.org> Message-ID: Hi, Jan. It's a great presentation and I really love your approach. However, I am curious -- why was IP-in-IP not pursued? I know the presentation mentioned the MTU issue, but your final solution seemed full of enough pitfalls itself (ie -- lots of cooperation from numerous groups, people, and processes) that raising MTU in your network might be an easier proposition. Thought you might have went into it a bit in the video, that's all. Any insight? -M On Tue, Jul 26, 2011 at 12:54 PM, Jan Schaumann wrote: > Matt Hite wrote: >> Might someone have the video for this presentation in their personal stash? >> >> http://www.nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk45.nanog51-Schaumann.pdf > > I don't have the video handy, but there really wasn't all that much more > info in the presentation than in the slides. ?It might be worth noting > that the modules are now open source: > https://github.com/yahoo/l3dsr > > If you have questions, just email me. > > -Jan > From betty at newnog.org Tue Jul 26 17:46:51 2011 From: betty at newnog.org (Betty Burke) Date: Tue, 26 Jul 2011 18:46:51 -0400 Subject: Presentation Archives Message-ID: Great news!! The NANOG presentation archive is once again working properly. Additionally, very soon, the NANOG 52 Video Presentations will also be linked. Again, we are sorry for the interruption and access to the archives and appreciate your patience as we continue to move through the transition of NANOG services. If you should have any further problems or concerns, please do let us know by sending a note to nanog-support at nanog.org. Sincerely, Betty -- Betty Burke NewNOG/NANOG Executive Director From leo.vegoda at icann.org Tue Jul 26 18:02:14 2011 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 26 Jul 2011 16:02:14 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <20110726211655.GA25957@srv03.cluenet.de> References: <4E2ED7C5.1040702@unfix.org> <20110726211655.GA25957@srv03.cluenet.de> Message-ID: <41F6C547EA49EC46B4EE1EB2BC2F34181275C86B58@EXVPMBX100-1.exc.icann.org> You wrote: > > Also, one can argue that a dynamic prefix facilitates privacy ? > > In Germany, there is significant political pushback against the idea to > give residential mom+pop static prefixed for that very reason. Do German web sites not track users with cookies, then? Regards, Leo From pete at altadena.net Tue Jul 26 18:12:00 2011 From: pete at altadena.net (Pete Carah) Date: Tue, 26 Jul 2011 19:12:00 -0400 Subject: Comcast Bussiness Class and GRE Tunnels In-Reply-To: References: <4E2ED839.5090709@blastcomm.com> Message-ID: <4E2F49C0.7050003@altadena.net> On 07/26/2011 11:45 AM, Jon Bane wrote: > On Tue, Jul 26, 2011 at 11:38 AM, PC wrote: > > ... > Was working on the same reply as Paul. You assign your static to your > Mircotik box and check the box in the WebGUI (default is http://10.1.10.1) > to "Disable Firewall for True Static IP Subnet Only" on the firewall tab. > > -Jon > Also make sure that Smart Packet Detection is turned off... (that affects most services and slows things down at best. It is a checkbox right under the above one. -- Pete From kauer at biplane.com.au Tue Jul 26 18:16:55 2011 From: kauer at biplane.com.au (Karl Auer) Date: Wed, 27 Jul 2011 09:16:55 +1000 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: Message-ID: <1311722215.13822.36.camel@karl> On Tue, 2011-07-26 at 11:18 -0400, JORDI PALET MARTINEZ wrote: > Also, one can argue that a dynamic prefix facilitates privacy ? Not really - not unless they use privacy addresses or DHCPv6 as well. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From bicknell at ufp.org Tue Jul 26 18:24:21 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 26 Jul 2011 16:24:21 -0700 Subject: How dynamic is a dynamic IPv6 address? In-Reply-To: References: Message-ID: <20110726232421.GA27091@ussenterprise.ufp.org> How dynamic will dynamic addresses be under IPv6? IPv4 addresses, with most ISP's, change relatively rarely. Once or twice a year is not atypical, and sometimes they go for much longer. The impression I get is that most of the need to renumber is driven by technological needs, either the subnet sizes and need to use all addresses in a block, or the combining and splitting of "segments" (channels, etc) on the cable infrastructure. With a /64 on each segment the former goes away. Subnet size will never dictate renumbering. The segments issue could keep driving it, but it's not hard to imagine a world where your router gets a dynamic IP out of a /64, and then does DHCP-PD to get your home block. This block may in fact never need to change. Basically, in IPv6, even if addresses are assigned "dynamically" (really automatically) won't the consumer pretty much always have the same address for the lifetime of their service, for the majority of consumers? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From owen at delong.com Tue Jul 26 18:46:05 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Jul 2011 16:46:05 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <20110726223024.78972123095B@drugs.dv.isc.org> References: <4E2ED7C5.1040702@unfix.org> <20110726211655.GA25957@srv03.cluenet.de> <20110726223024.78972123095B@drugs.dv.isc.org> Message-ID: On Jul 26, 2011, at 3:30 PM, Mark Andrews wrote: > > Actually all addresses are dynamic. There are just different lease > periods. Year vs day or hours. > An interesting way to look at it. Perhaps arguably true with IPv6. However, one must face the reality that at some levels, it's year with virtually guaranteed option to renew every year, making it effectively static. Owen From owen at delong.com Tue Jul 26 18:47:24 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Jul 2011 16:47:24 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F34181275C86B58@EXVPMBX100-1.exc.icann.org> References: <4E2ED7C5.1040702@unfix.org> <20110726211655.GA25957@srv03.cluenet.de> <41F6C547EA49EC46B4EE1EB2BC2F34181275C86B58@EXVPMBX100-1.exc.icann.org> Message-ID: <165016BB-411C-486F-8849-B20F1B1F05CD@delong.com> On Jul 26, 2011, at 4:02 PM, Leo Vegoda wrote: > You wrote: >>> Also, one can argue that a dynamic prefix facilitates privacy ? >> >> In Germany, there is significant political pushback against the idea to >> give residential mom+pop static prefixed for that very reason. > > Do German web sites not track users with cookies, then? > > Regards, > > Leo No, it's just a case of the German government not being very smart about privacy. Owen From ivanov_andrei at yahoo.com Tue Jul 26 19:07:37 2011 From: ivanov_andrei at yahoo.com (Andrei Ivanov) Date: Tue, 26 Jul 2011 17:07:37 -0700 (PDT) Subject: Google corporate network - could someone please help me? Message-ID: <1311725257.58875.YahooMailNeo@web43137.mail.sp1.yahoo.com> Good day, everyone! There is a web site, and thousands of users are visiting it every day. Some web users, connected to a number of corporate networks, are getting results that are not consistent with other users' experiences. One of these corporate networks is Google. Could someone from Google, who would be willing to help with troubleshooting, contact me off-list? Thank you. -- andrei From Valdis.Kletnieks at vt.edu Tue Jul 26 19:06:43 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 26 Jul 2011 20:06:43 -0400 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: Your message of "Tue, 26 Jul 2011 16:02:14 PDT." <41F6C547EA49EC46B4EE1EB2BC2F34181275C86B58@EXVPMBX100-1.exc.icann.org> References: <4E2ED7C5.1040702@unfix.org> <20110726211655.GA25957@srv03.cluenet.de> <41F6C547EA49EC46B4EE1EB2BC2F34181275C86B58@EXVPMBX100-1.exc.icann.org> Message-ID: <4050.1311725203@turing-police.cc.vt.edu> On Tue, 26 Jul 2011 16:02:14 PDT, Leo Vegoda said: > Do German web sites not track users with cookies, then? There's a subtle but significant difference between what cookies give you, which is "This is the same entity that visited our page at 7:48PM last Tuesday", and what easily trackable IP addresses give you, which is "This is an entity located at 1948 Durhof Street". Yes, it's often possible to to map between one and the other - but anonymous and pseudonymous are two different things. It's quite reasonable for somebody to want to be one but not the other - though it can be difficult in practice. It's even quite reasonable for somebody to wish to be positively identified, but their location not easily determined - for instance, I'm posting this as myself, but I may wish where I'm posting *from* to remain a secret (for instance, if my location reveals I'm not at home and thus burgling my residence is more feasible). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From owen at delong.com Tue Jul 26 19:13:02 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Jul 2011 17:13:02 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <4050.1311725203@turing-police.cc.vt.edu> References: <4E2ED7C5.1040702@unfix.org> <20110726211655.GA25957@srv03.cluenet.de> <41F6C547EA49EC46B4EE1EB2BC2F34181275C86B58@EXVPMBX100-1.exc.icann.org> <4050.1311725203@turing-police.cc.vt.edu> Message-ID: On Jul 26, 2011, at 5:06 PM, Valdis.Kletnieks at vt.edu wrote: > On Tue, 26 Jul 2011 16:02:14 PDT, Leo Vegoda said: >> Do German web sites not track users with cookies, then? > > There's a subtle but significant difference between what cookies give you, > which is "This is the same entity that visited our page at 7:48PM last > Tuesday", and what easily trackable IP addresses give you, which is "This is an > entity located at 1948 Durhof Street". > > Yes, it's often possible to to map between one and the other - but anonymous > and pseudonymous are two different things. It's quite reasonable for somebody > to want to be one but not the other - though it can be difficult in practice. > It's even quite reasonable for somebody to wish to be positively identified, > but their location not easily determined - for instance, I'm posting this as > myself, but I may wish where I'm posting *from* to remain a secret (for > instance, if my location reveals I'm not at home and thus burgling my residence > is more feasible). > Yes, but, your network prefix will generally reveal that to roughly the same extent whether it is static or dynamic. Owen From matt.addison at lists.evilgeni.us Tue Jul 26 19:29:06 2011 From: matt.addison at lists.evilgeni.us (Matt Addison) Date: Tue, 26 Jul 2011 20:29:06 -0400 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <4050.1311725203@turing-police.cc.vt.edu> References: <4E2ED7C5.1040702@unfix.org> <20110726211655.GA25957@srv03.cluenet.de> <41F6C547EA49EC46B4EE1EB2BC2F34181275C86B58@EXVPMBX100-1.exc.icann.org> <4050.1311725203@turing-police.cc.vt.edu> Message-ID: <-3414909030888851989@unknownmsgid> On Jul 26, 2011, at 20:08, Valdis.Kletnieks at vt.edu wrote: > There's a subtle but significant difference between what cookies give you, > which is "This is the same entity that visited our page at 7:48PM last > Tuesday", and what easily trackable IP addresses give you, which is "This is an > entity located at 1948 Durhof Street". With how much identifying information user agents leak nowadays [1] this is almost a moot point. If you can be uniquely identified through the user agent- does it really matter that they can uniquely ID the household as well based on prefix information? ~Matt 1: http://panopticlick.eff.org/ From marka at isc.org Tue Jul 26 20:07:00 2011 From: marka at isc.org (Mark Andrews) Date: Wed, 27 Jul 2011 11:07:00 +1000 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: Your message of "Tue, 26 Jul 2011 12:35:08 EST." <4E2EFACC.4010906@thebaughers.com> References: <4E2ED7C5.1040702@unfix.org> <4E2EFACC.4010906@thebaughers.com> Message-ID: <20110727010700.842891230FCD@drugs.dv.isc.org> In message <4E2EFACC.4010906 at thebaughers.com>, Jason Baugher writes: > On 7/26/2011 12:06 PM, Owen DeLong wrote: > > On Jul 26, 2011, at 8:05 AM, Jeroen Massar wrote: > > > >> On 2011-07-26 16:58 , JORDI PALET MARTINEZ wrote: > >>> Hi all, > >>> > >>> I will like to know, from those deploying IPv6 services to residential > >>> customers, if you are planning to provide static or dynamic IPv6 prefixes > . > >>> > > We (Hurricane Electric) provide statics to all of our customers. > > > >>> Just to be clear, I'm for static prefix delegation to residential > >>> customers, however I heard that some ISPs are doing dynamic delegations, > >>> the same way as is common today with IPv4. > >>> > >>> I don't thin it make sense, as the main reason for doing so in IPv4 was > >>> address exhaustion and legacy oversubscription models such as PPP/dial-up > . > >> You are forgetting the simple fact that you can charge for static > >> addresses and unblocked connectivity. THAT is the reason for dynamic > >> addresses, as on the ISP level there are still enough IPv4 addresses and > >> they can still, even today, ask for more from their RIR. > >> > > You can only charge for static addresses as long as your competitors don't. > > Hopefullly with IPv6, that model will go the way of the dodo. > > > >> Abuse/accounting/etc all become much simpler with static addresses. > >> > >> But as long as you give those users dynamic addresses, they might not > >> run a SMTP/HTTP/xxx server on their link as changing IPs is > >> kind-of-annoying (but doable with the proper DNS setup and low TTLs) > >> > > Let's face it, the users that are going to run an SMTP/HTTP/xxx server on t > heir > > link are probably the ones that know how to use dyndns or some other mechan > ism > > to cope with the dynamic address issue. The ones that aren't already runnin > g > > such services with dynamic IPs are probably not significantly more likely t > o do > > so with static. > > > >> Thus, you give them dynamic stuff, or only 1 IP address and ask them for > >> lots of moneys when they want a static address or hey lots more moneys > >> (in the form of a 'business connection') when they want multiple > >> addresses routed to their host. > >> > > I don't think this will fly with IPv6 since free tunnels are a simple solut > ion where > > you can get a /48 for free regardless of what your ISP does to you. I think > that > > this is a temporary problem and that IPv6 will prove to be a game-changer > > in this arena. > > > >> And don't bother asking for proper reverse setup in a lot of cases > >> either, let alone delegation of that. > >> > > Again, I think other than cable MSOs where they have strong topological > > reasons to prevent static addressing, IPv6 will see the return of unfettere > d > > static addressing and multiple addresses as the default for end users. > > I realize there is some resistance to the idea of /48s among some residenti > al > > providers at this point, but, the majority of them are talking about at lea > st > > using /56s or better, so, I don't think /128s are at all likely. > > > >> Greets, > >> Jeroen > >> Happily using the same static IPv6 /48 for almost a decade ;) > > > > Owen > > Happily using the same RIR-direct-assigned /48 at home for almost 4 years. > > > > > > > It's very interesting to hear the majority of you promoting static over > dynamic. We are just now starting to work with IPv6 now that our > upstreams are willing to give us dual-stack. We've always been a static > shop, but sales has been pushing for dynamic for years due to what > people have mentioned earlier, the ability to up-sell statics to > customers. We prefer static because of the easy tracking of customers > for abuse/spam/DMCA complaints and we don't need to worry about DHCP > servers. It's heartening to see others of the same mindset encouraging > static for IPv6 allocation. Static and be done with DHCP or manually. > Jason > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From matthew at matthew.at Tue Jul 26 20:10:48 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 26 Jul 2011 21:10:48 -0400 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <-3414909030888851989@unknownmsgid> References: <4E2ED7C5.1040702@unfix.org> <20110726211655.GA25957@srv03.cluenet.de> <41F6C547EA49EC46B4EE1EB2BC2F34181275C86B58@EXVPMBX100-1.exc.icann.org> <4050.1311725203@turing-police.cc.vt.edu> <-3414909030888851989@unknownmsgid> Message-ID: <2748AD56-9051-471B-B8A8-A3616C64F394@matthew.at> On Jul 26, 2011, at 8:29 PM, Matt Addison wrote: > On Jul 26, 2011, at 20:08, Valdis.Kletnieks at vt.edu wrote: >> There's a subtle but significant difference between what cookies give you, >> which is "This is the same entity that visited our page at 7:48PM last >> Tuesday", and what easily trackable IP addresses give you, which is "This is an >> entity located at 1948 Durhof Street". > > With how much identifying information user agents leak nowadays [1] > this is almost a moot point. If you can be uniquely identified through > the user agent- does it really matter that they can uniquely ID the > household as well based on prefix information? That depends on what happens when ISPs do start giving residences /48s and ARIN starts asking for the SWIP details on blocks that large. Matthew Kaufman From surfer at mauigateway.com Tue Jul 26 20:25:30 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 26 Jul 2011 18:25:30 -0700 Subject: dynamic or static IPv6 prefixes to residential customers Message-ID: <20110726182530.494356D1@resin11.mta.everyone.net> -------- matt.addison at lists.evilgeni.us wrote: --------------------- On Jul 26, 2011, at 20:08, Valdis.Kletnieks at vt.edu wrote: > There's a subtle but significant difference between what cookies give you, > which is "This is the same entity that visited our page at 7:48PM last > Tuesday", and what easily trackable IP addresses give you, which is "This is an > entity located at 1948 Durhof Street". With how much identifying information user agents leak nowadays [1] this is almost a moot point. If you can be uniquely identified through the user agent- does it really matter that they can uniquely ID the household as well based on prefix information? 1: http://panopticlick.eff.org/ ------------------------------------------------------------------- All you need to do with what that site says is write a sh script that deletes and then creates the same user. Stick it in a crontab. Your browser ID changes each time. In addition to browser cookies, be sure to manage your flash cookies... http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager07.html So, force the DHCP server to give you new addresses (in IPv4; don't know about IPv6, yet), manage your cookies, change your browser IDs regularly. What did I miss? ;-) scott (who's still bristling from the last discussion about this where Valdis kept saying "Privacy is dead. Get used to it." I don't want to roll over and just take it... >;-) ) From morrowc.lists at gmail.com Tue Jul 26 21:33:54 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 26 Jul 2011 22:33:54 -0400 Subject: OOB In-Reply-To: <20110726213404.GG20415@besserwisser.org> References: <018501cc4b9c$bdb1f6c0$3915e440$@org> <20110726213404.GG20415@besserwisser.org> Message-ID: On Tue, Jul 26, 2011 at 5:34 PM, M?ns Nilsson wrote: > Subject: Re: OOB Date: Tue, Jul 26, 2011 at 10:14:21AM -0400 Quoting Christopher Morrow (morrowc.lists at gmail.com): >> On Tue, Jul 26, 2011 at 10:03 AM, Paul Stewart wrote: >> > We do everything in-band with strict monitoring/policies in place. >> >> what do you do if your in-band fails? if a router/switch/ROADM is >> isolated from the rest of your network? >> (isn't that the core point of the OP?) > > Vendor C sells nice small routers with something like CAB-OCTAL-ASYNC > _and_ a 3G modem instead of the BRI port. The 3G modem keeps its > connection up (our telecom provider has true flat rate on domestic 3G, > YMMV) and VPN's to the head office much like any other telecommuter. This > cuts through all telco stupidity with firewalled or NAT'ed 3G phones > etc, especially if one uses the break-out-from-hotel-LAN functions of > the VPN system. The router of course actively keeps the VPN up and > reestablishes it if needed. how well does that work inside a big metal box like equinix? You are, of course, just making a singular point: "Find something to make yourself an OOB network, hey this thing does vpn over 3g, neato!" I agree, it's neat.. it may not fit all square holes, sometimes you need a round or triangle shaped plug. From hectorh at pobox.com Tue Jul 26 21:35:35 2011 From: hectorh at pobox.com (Hector Herrera) Date: Tue, 26 Jul 2011 19:35:35 -0700 Subject: 3Com Total Control documentation Message-ID: Hi, I have "inherited" several 3Com Total Control racks that are used to provide dial-up service to rural areas. The racks have been running in auto-pilot for several years now and the last tech's comments with regard to the racks was along the lines of "I don't know". I would like to regain control over the network as recently the outages are becoming more frequent and extended and we don't usually know about it until customers call the support line a week later. Decommissioning the racks is not currently an option as there are no other reasonable alternatives for internet service (other than satellite). The ISP being an marginal area provider is also short in funds. I'm having a hard time finding documentation, firmware updates or support for these racks. As far as I can tell, the current owner of the product line is UTStarCom in China, but their website does not make any reference to the product. I also found a company that sells the equipment and provides support contracts, WRCA, but their pricing is out of the budget range for the ISP. I am hoping that some of you who used to work with this equipment may still have documentation CDs or firmware updates stored away somewhere. I'm looking for any documentation, firmware updates and some help figuring out which NAC goes with which NIC. Or perhaps you can suggest other companies that provide support for the equipment at more reasonable rates. I would be willing to setup a public repository to help other admins. Thanks, -- Hector Herrera From owen at delong.com Tue Jul 26 21:43:39 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Jul 2011 19:43:39 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <2748AD56-9051-471B-B8A8-A3616C64F394@matthew.at> References: <4E2ED7C5.1040702@unfix.org> <20110726211655.GA25957@srv03.cluenet.de> <41F6C547EA49EC46B4EE1EB2BC2F34181275C86B58@EXVPMBX100-1.exc.icann.org> <4050.1311725203@turing-police.cc.vt.edu> <-3414909030888851989@unknownmsgid> <2748AD56-9051-471B-B8A8-A3616C64F394@matthew.at> Message-ID: <2B5F4A79-282B-4FE1-8A7D-B7D76643C7FB@delong.com> On Jul 26, 2011, at 6:10 PM, Matthew Kaufman wrote: > > On Jul 26, 2011, at 8:29 PM, Matt Addison wrote: > >> On Jul 26, 2011, at 20:08, Valdis.Kletnieks at vt.edu wrote: >>> There's a subtle but significant difference between what cookies give you, >>> which is "This is the same entity that visited our page at 7:48PM last >>> Tuesday", and what easily trackable IP addresses give you, which is "This is an >>> entity located at 1948 Durhof Street". >> >> With how much identifying information user agents leak nowadays [1] >> this is almost a moot point. If you can be uniquely identified through >> the user agent- does it really matter that they can uniquely ID the >> household as well based on prefix information? > > > That depends on what happens when ISPs do start giving residences /48s and ARIN starts asking for the SWIP details on blocks that large. > > Matthew Kaufman I believe that the existing residential customer privacy policy covers this. Owen From jschauma at netmeister.org Tue Jul 26 22:06:11 2011 From: jschauma at netmeister.org (Jan Schaumann) Date: Tue, 26 Jul 2011 23:06:11 -0400 Subject: "L3DSR -- Overcoming Layer 2 Limitations of Direct Server Return Load Balancing" Video? In-Reply-To: References: <20110726195417.GA20045@netmeister.org> Message-ID: <20110727030610.GB20045@netmeister.org> Matt Hite wrote: > Hi, Jan. It's a great presentation and I really love your approach. > However, I am curious -- why was IP-in-IP not pursued? I know the > presentation mentioned the MTU issue, but your final solution seemed > full of enough pitfalls itself (ie -- lots of cooperation from > numerous groups, people, and processes) that raising MTU in your > network might be an easier proposition. Thought you might have went > into it a bit in the video, that's all. Any insight? We have come to the conclusion that Path MTU Discovery on the internet at large... doesn't work so well. :-) With IP-in-IP or GRE, our MTU increases, so either we keep the MTU the same (to the outside) and declare (internally) our own largest packet to be smaller than 1500 or change the MTU (internally) to be larger than 1500 (to account for the overhead). Either way, we end up with an MTU that's different between at least two of the client, the LB and our server. The idea of using the DSCP bit then seemed to be more reasonable to us. -Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 478 bytes Desc: not available URL: From joelja at bogus.com Tue Jul 26 22:40:07 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 26 Jul 2011 23:40:07 -0400 Subject: OOB In-Reply-To: References: <018501cc4b9c$bdb1f6c0$3915e440$@org> <20110726213404.GG20415@besserwisser.org> Message-ID: <05C9A35C-8FD2-4285-8794-E926C887ED89@bogus.com> My measured availability for a automatic reverse ssh tunnel connection made through a 4g radio in the field was 52%. this was vs 95% on the lab/office environment with the same equipment. That particular experiment I declared a failure. There was never a closer truism than ymmv. joel On Jul 26, 2011, at 10:33 PM, Christopher Morrow wrote: > On Tue, Jul 26, 2011 at 5:34 PM, M?ns Nilsson wrote: >> Subject: Re: OOB Date: Tue, Jul 26, 2011 at 10:14:21AM -0400 Quoting Christopher Morrow (morrowc.lists at gmail.com): >>> On Tue, Jul 26, 2011 at 10:03 AM, Paul Stewart wrote: >>>> We do everything in-band with strict monitoring/policies in place. >>> >>> what do you do if your in-band fails? if a router/switch/ROADM is >>> isolated from the rest of your network? >>> (isn't that the core point of the OP?) >> >> Vendor C sells nice small routers with something like CAB-OCTAL-ASYNC >> _and_ a 3G modem instead of the BRI port. The 3G modem keeps its >> connection up (our telecom provider has true flat rate on domestic 3G, >> YMMV) and VPN's to the head office much like any other telecommuter. This >> cuts through all telco stupidity with firewalled or NAT'ed 3G phones >> etc, especially if one uses the break-out-from-hotel-LAN functions of >> the VPN system. The router of course actively keeps the VPN up and >> reestablishes it if needed. > > how well does that work inside a big metal box like equinix? > > You are, of course, just making a singular point: "Find something to > make yourself an OOB network, hey this thing does vpn over 3g, neato!" > I agree, it's neat.. it may not fit all square holes, sometimes you > need a round or triangle shaped plug. > > From msa at latt.net Wed Jul 27 00:29:12 2011 From: msa at latt.net (Majdi S. Abbas) Date: Tue, 26 Jul 2011 22:29:12 -0700 Subject: How dynamic is a dynamic IPv6 address? In-Reply-To: <20110726232421.GA27091@ussenterprise.ufp.org> References: <20110726232421.GA27091@ussenterprise.ufp.org> Message-ID: <20110727052912.GB65292@puck.nether.net> On Tue, Jul 26, 2011 at 04:24:21PM -0700, Leo Bicknell wrote: > How dynamic will dynamic addresses be under IPv6? With or without privacy extensions enabled? --msa From Valdis.Kletnieks at vt.edu Wed Jul 27 01:38:16 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 27 Jul 2011 02:38:16 -0400 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: Your message of "Tue, 26 Jul 2011 18:25:30 PDT." <20110726182530.494356D1@resin11.mta.everyone.net> References: <20110726182530.494356D1@resin11.mta.everyone.net> Message-ID: <17582.1311748696@turing-police.cc.vt.edu> On Tue, 26 Jul 2011 18:25:30 PDT, Scott Weeks said: > (who's still bristling from the last discussion about this where Valdis kept > saying "Privacy is dead. Get used to it." Man, leave one smiley off and it follows you for life. ;) http://mailman.nanog.org/pipermail/nanog/2011-May/036270.html Yes, Scott, I know it's a hard problem, and many of the issues are non-protocol ones to boot. (And I *thought* I had enough fame as a member of the tinfoil helmet brigade that nobody would seriously think the McNeely quote actually summarized the way I think things should be - though it may well summarize where I think things are headed despite our best efforts...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From mansaxel at besserwisser.org Wed Jul 27 01:56:00 2011 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Wed, 27 Jul 2011 08:56:00 +0200 Subject: OOB In-Reply-To: References: <018501cc4b9c$bdb1f6c0$3915e440$@org> <20110726213404.GG20415@besserwisser.org> Message-ID: <20110727065600.GL20415@besserwisser.org> Subject: Re: OOB Date: Tue, Jul 26, 2011 at 10:33:54PM -0400 Quoting Christopher Morrow (morrowc.lists at gmail.com): > how well does that work inside a big metal box like equinix? Sometimes not so well. OTOH, this is for routers that are installed in central machine rooms for a radio broadcaster. Faraday issues are indeed present, but we've managed with a top-of-rack antenna, so far. (The FM transmitters are off-site and outsourced, anyway) > You are, of course, just making a singular point: "Find something to > make yourself an OOB network, hey this thing does vpn over 3g, neato!" > I agree, it's neat.. it may not fit all square holes, sometimes you > need a round or triangle shaped plug. The facilities that are somewhat prepared to survive EMP aren't so forgiving. Modems still have their place, as has the dedicated glass strand. In some EMP shielded sites I've had predictable trouble getting copper lines in, even after pointing out the availability of milspec filtering devices. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I'm not available for comment.. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From jeroen at unfix.org Wed Jul 27 02:17:23 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 27 Jul 2011 09:17:23 +0200 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <20110726182530.494356D1@resin11.mta.everyone.net> References: <20110726182530.494356D1@resin11.mta.everyone.net> Message-ID: <4E2FBB83.7030301@unfix.org> On 2011-07-27 03:25 , Scott Weeks wrote: > -------- matt.addison at lists.evilgeni.us wrote: --------------------- >> [..] 1: http://panopticlick.eff.org/ > > All you need to do with what that site says is write a sh script that > deletes and then creates the same user. And there you sprung into a trap. You will be the only one doing this and having no history and thus you stick out very well, as the new guy on the Internet every single day, from a similar prefix, but still accessing a similar set of hosts etc. I think I did a talk about that at CCC last year ;) You are blocking all the facebook/google+ like and the insane amount of advertisement (read: tracking) networks who are included on almost every page do you? As everytime you fetch a page, even if it is not the main site, you also hit them for an ad or a like-button (even if it is just the image and you don't actually click you hit their server) and voila you are tracked anyway. Giving dynamic addresses out thus only still have one valid reason: nomadic users and the ability to aggregate prefixes inside a network. Because when users are static, you just route a /36 to a location and route prefixes out of that to the users and voila. When they are nomadic/mobile you don't want all those millions of /48s polluting your iBGP though. For every other case, dynamic addresses just make no sense, except for the cash cow that they are and that is the real reason that is the default being offered, as technically they cost more money. Greets, Jeroen From denys at visp.net.lb Wed Jul 27 04:17:16 2011 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Wed, 27 Jul 2011 12:17:16 +0300 Subject: Comcast Bussiness Class and GRE Tunnels In-Reply-To: <4E2ED839.5090709@blastcomm.com> References: <4E2ED839.5090709@blastcomm.com> Message-ID: <7780129e5ef3d30f1421ca9bad638be0@visp.net.lb> On Tue, 26 Jul 2011 10:07:37 -0500, Nate Burke wrote: > Hello, I'm hoping that someone here might have run into a similar > issue and might be able to offer me some pointers. ... > > Anyone with Insights or comments would be appreciated. Mikrotik EOIP are not following standards, it is just their own hack, so it is very possible that some SPI in Comcast breaking it. Additionally some Mikrotik versions doesn't work properly with their own EOIP even, plus it has fragmentation issues. Fragmentation issues usually appears on large transfers, such as "stalling" sessions. I wrote my own implementation of Mikrotik EOIP for Linux, so i know what i am talking about, also in same code i wrote alternative tunnel, that has much less overhead than EOIP (compression + packets aggregation), but sure you need linux both side. I can recommend you to try to use openvpn, if you are "Mikrotik only". At least it doesn't have fragmentation issues, as IPIP/GRE/PPTP has, and also it will run smoothly over NAT/SPI. Cons, that it is a bit more laggy, because it runs over TCP. --- System administrator Denys Fedoryshchenko Virtual ISP S.A.L. From mpalmer at hezmatt.org Wed Jul 27 04:23:33 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Wed, 27 Jul 2011 19:23:33 +1000 Subject: Comcast Bussiness Class and GRE Tunnels In-Reply-To: <7780129e5ef3d30f1421ca9bad638be0@visp.net.lb> References: <4E2ED839.5090709@blastcomm.com> <7780129e5ef3d30f1421ca9bad638be0@visp.net.lb> Message-ID: <20110727092333.GZ3135@hezmatt.org> On Wed, Jul 27, 2011 at 12:17:16PM +0300, Denys Fedoryshchenko wrote: > I can recommend you to try to use openvpn, if you are "Mikrotik > only". At least it doesn't have fragmentation issues, as > IPIP/GRE/PPTP has, and also it will run smoothly over NAT/SPI. Cons, > that it is a bit more laggy, because it runs over TCP. Au contraire, OpenVPN only runs over TCP if you explicitly tell it to; default configuration, and widespread practice, is to run it over UDP. - Matt From denys at visp.net.lb Wed Jul 27 04:30:36 2011 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Wed, 27 Jul 2011 12:30:36 +0300 Subject: Comcast Bussiness Class and GRE Tunnels In-Reply-To: <20110727092333.GZ3135@hezmatt.org> References: <4E2ED839.5090709@blastcomm.com> <7780129e5ef3d30f1421ca9bad638be0@visp.net.lb> <20110727092333.GZ3135@hezmatt.org> Message-ID: On Wed, 27 Jul 2011 19:23:33 +1000, Matthew Palmer wrote: > On Wed, Jul 27, 2011 at 12:17:16PM +0300, Denys Fedoryshchenko wrote: >> I can recommend you to try to use openvpn, if you are "Mikrotik >> only". At least it doesn't have fragmentation issues, as >> IPIP/GRE/PPTP has, and also it will run smoothly over NAT/SPI. Cons, >> that it is a bit more laggy, because it runs over TCP. > > Au contraire, OpenVPN only runs over TCP if you explicitly tell it > to; > default configuration, and widespread practice, is to run it over > UDP. > > - Matt On Linux, yes, it is by default configuration is UDP, but in current case , on Mikrotik, it is working _only_ in TCP mode, and has few more limitations. http://forum.mikrotik.com/viewtopic.php?f=1&t=20537 --- System administrator Denys Fedoryshchenko Virtual ISP S.A.L. From mpalmer at hezmatt.org Wed Jul 27 05:15:16 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Wed, 27 Jul 2011 20:15:16 +1000 Subject: Comcast Bussiness Class and GRE Tunnels In-Reply-To: References: <4E2ED839.5090709@blastcomm.com> <7780129e5ef3d30f1421ca9bad638be0@visp.net.lb> <20110727092333.GZ3135@hezmatt.org> Message-ID: <20110727101516.GA3135@hezmatt.org> On Wed, Jul 27, 2011 at 12:30:36PM +0300, Denys Fedoryshchenko wrote: > On Wed, 27 Jul 2011 19:23:33 +1000, Matthew Palmer wrote: > >On Wed, Jul 27, 2011 at 12:17:16PM +0300, Denys Fedoryshchenko wrote: > >>I can recommend you to try to use openvpn, if you are "Mikrotik > >>only". At least it doesn't have fragmentation issues, as > >>IPIP/GRE/PPTP has, and also it will run smoothly over NAT/SPI. Cons, > >>that it is a bit more laggy, because it runs over TCP. > > > >Au contraire, OpenVPN only runs over TCP if you explicitly tell it > >to; > >default configuration, and widespread practice, is to run it over > >UDP. > > On Linux, yes, it is by default configuration is UDP, but in current > case , on Mikrotik, it is working _only_ in TCP mode, and has few > more limitations. > http://forum.mikrotik.com/viewtopic.php?f=1&t=20537 WT*F*? I've never understood the appeal of Microtik, and now I understand it even less. - Matt From denys at visp.net.lb Wed Jul 27 05:38:32 2011 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Wed, 27 Jul 2011 13:38:32 +0300 Subject: Comcast Bussiness Class and GRE Tunnels In-Reply-To: <20110727101516.GA3135@hezmatt.org> References: <4E2ED839.5090709@blastcomm.com> <7780129e5ef3d30f1421ca9bad638be0@visp.net.lb> <20110727092333.GZ3135@hezmatt.org> <20110727101516.GA3135@hezmatt.org> Message-ID: <87a578bbdbd8b96d99ba562a5d5bc80b@visp.net.lb> On Wed, 27 Jul 2011 20:15:16 +1000, Matthew Palmer wrote: > > WT*F*? I've never understood the appeal of Microtik, and now I > understand > it even less. > > - Matt Well, it is luring people because it has easy GUI and it is cheap. Even noob can setup VPN in few clicks. At same time they hidden bugs, that can cause packetloss, sessions stalling, improper UDP NAT handling, lack of proper interoperability. Maybe discussed issue lays not in comcast, but in some Mikrotik bug. --- System administrator Denys Fedoryshchenko Virtual ISP S.A.L. From slz at baycix.de Wed Jul 27 08:14:37 2011 From: slz at baycix.de (Sascha Lenz) Date: Wed, 27 Jul 2011 15:14:37 +0200 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <0904D2C5-0BBC-40B9-91BB-1677A95C3134@delong.com> References: <0904D2C5-0BBC-40B9-91BB-1677A95C3134@delong.com> Message-ID: <0E3C94C5-DB8A-4CEB-9769-613E8D61132B@baycix.de> Hi Owen, >> >>> Hi all, >>> >>> I will like to know, from those deploying IPv6 services to residential >>> customers, if you are planning to provide static or dynamic IPv6 prefixes. >>> >>> Just to be clear, I'm for static prefix delegation to residential >>> customers, however I heard that some ISPs are doing dynamic delegations, >>> the same way as is common today with IPv4. >>> >>> I don't thin it make sense, as the main reason for doing so in IPv4 was >>> address exhaustion and legacy oversubscription models such as PPP/dial-up. >> >> well, it does make sense for most of the residential customers nowadays, because >> they are indoctrinated with this idea of dynamic+NAT == privacy for over a decade >> now and don't know any better. >> > IMNSHO, education is always a better alternative than preserving ignorance or > worse, mis-information. > I'm fully with you there, probably i should have elaborated a bit more. In general, what Daniel said - at least in germany we have this problem that static vs. dynamic Internet address assignments make a whole lot of a difference in privacy when it comes to legal issues. AND, even though we have next to no IPv6-deployment on a big scale here, there is plenty of "education" going on in various media about how IPv6 will kill privacy with "life-long IP addresses" and so on. It's just not possible to counter that with technical arguments, at least not in the short-term. I apologize for generalizing the situation in germany without explaining. I really hope it's different in other markets and you are right. But you will lose customers here if you don't offer some kind of dynamic prefixes, and if you're dealing with the mass-market, you can't afford that. Hence, my suggestion to just let your customers chose. Problem solved. > >> The best current practice would be, to default to a dynamic prefix, but enable your >> more advanced customers to change that to a static prefix at will in your customer >> service web-portal or something. >> > > Sounds unnecessarily complicated and with absolutely no benefit whatsoever. > In this case, i beg to differ though. It's not complicated but as easy as some change in your RADIUS database. And, in contrast to things like NAT66, it doesn't break anything. So, in my opinion, this is about giving the customers a choice, with no downsides. It's somewhat similar to "privacy extensions - yes or no? default or not?" in the end. One could discuss what the default should be, dynamic or static. But just handing out static addresses even though it's relatively easy to give your customers a choice, might be seen as "dictating" rather than "educating". On a side-note: It's totally different with NAT of course, giving the people the choice to use NAT will break things in the internet, again. I never would opt for that. >> But i have no idea how to sell this to your marketing department. >> They again are usually used to sell static IPs for an extra fee, and usually don't >> want to change that with IPv6. That's bullshit for IPv6 of course. >> > > It was mostly bullshit for IPv4. > Selling IPs? Indeed. But there's nothing in any RIR policy to prevent that (anymore). -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From bicknell at ufp.org Wed Jul 27 08:20:48 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 27 Jul 2011 06:20:48 -0700 Subject: How dynamic is a dynamic IPv6 address? In-Reply-To: <20110727052912.GB65292@puck.nether.net> References: <20110726232421.GA27091@ussenterprise.ufp.org> <20110727052912.GB65292@puck.nether.net> Message-ID: <20110727132048.GA61042@ussenterprise.ufp.org> In a message written on Tue, Jul 26, 2011 at 10:29:12PM -0700, Majdi S. Abbas wrote: > On Tue, Jul 26, 2011 at 04:24:21PM -0700, Leo Bicknell wrote: > > How dynamic will dynamic addresses be under IPv6? > > With or without privacy extensions enabled? I think that is orthogonal to my question. My question revolves around the reasons why a DHCPv6 or DHCPv6-PD allocation my change. If, after receiving one of those you choose to use privacy extensions there is no change on the DHCP side of things. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From dave at mvn.net Wed Jul 27 10:15:04 2011 From: dave at mvn.net (David E. Smith) Date: Wed, 27 Jul 2011 10:15:04 -0500 Subject: Comcast Bussiness Class and GRE Tunnels In-Reply-To: <20110727101516.GA3135@hezmatt.org> References: <4E2ED839.5090709@blastcomm.com> <7780129e5ef3d30f1421ca9bad638be0@visp.net.lb> <20110727092333.GZ3135@hezmatt.org> <20110727101516.GA3135@hezmatt.org> Message-ID: > WT*F*? I've never understood the appeal of Microtik, and now I understand > it even less. > > The software is... quirky, at times, but some of their hardware, especially on the very low-end, is hard to beat. For instance, they make a SOHO router with five Gigabit Ethernet ports for $70, which has point-and-click access to MPLS, DHCP (server and client), a few different flavors of VPN including IPSec, and a bunch of other stuff. It even supports BGP, though you're not going to do very much with that system's 32MB RAM. If you really wanted, you could buy the hardware then re-flash it with something else; the CPU on this particular system is a MIPS 24K, and there's probably other embedded Linux/*BSD distributions that would work well enough. David Smith MVN.net From surfer at mauigateway.com Wed Jul 27 13:06:34 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 27 Jul 2011 11:06:34 -0700 Subject: dynamic or static IPv6 prefixes to residential customers Message-ID: <20110727110634.69A315ED@resin11.mta.everyone.net> --- Valdis.Kletnieks at vt.edu wrote: On Tue, 26 Jul 2011 18:25:30 PDT, Scott Weeks said: > (who's still bristling from the last discussion about this where Valdis kept > saying "Privacy is dead. Get used to it." Man, leave one smiley off and it follows you for life. ;) ------------------------------------------------- Ok, I'll do my best to remember that. Also, I should've had a smiley at the end of my ps... :-) scott From Jeffrey.R.Mullin at xo.com Wed Jul 27 13:16:48 2011 From: Jeffrey.R.Mullin at xo.com (Mullin, Jeffrey R) Date: Wed, 27 Jul 2011 18:16:48 +0000 Subject: XO Contact In-Reply-To: <0f7201cc4bd0$c7e3d620$57ab8260$@com> References: <0f7201cc4bd0$c7e3d620$57ab8260$@com> Message-ID: <9347AE1A7FBC5140978061940965E9E00716FBCA@TXPLANEXCH20.corp.inthosts.net> JI, Has anyone contacted you yet? If not, I can probably help you out. Jeff -----Original Message----- From: Robert Haas [mailto:rob-lists at bpsnetworks.com] Sent: Tuesday, July 26, 2011 3:16 PM To: nanog at nanog.org Subject: XO Contact Can someone from XO contact me (or if someone has a contact within XO, I'd appreciate it). We are having reachability issues from our network 74.91.64.0/20 AS36243 to the XO network. Thanks, Robert Haas 573-293-2638 From surfer at mauigateway.com Wed Jul 27 13:27:45 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 27 Jul 2011 11:27:45 -0700 Subject: dynamic or static IPv6 prefixes to residential customers Message-ID: <20110727112745.69A316B9@resin11.mta.everyone.net> --- jeroen at unfix.org wrote: From: Jeroen Massar On 2011-07-27 03:25 , Scott Weeks wrote: > -------- matt.addison at lists.evilgeni.us wrote: --------------------- >> [..] 1: http://panopticlick.eff.org/ > > All you need to do with what that site says is write a sh script that > deletes and then creates the same user. And there you sprung into a trap. You will be the only one doing this and having no history and thus you stick out very well, as the new guy on the Internet every single day, from a similar prefix, but still accessing a similar set of hosts etc. I think I did a talk about that at CCC last year ;) ------------------------------------------------- Not from the same prefix. I have multiple networks coming into my house and I cycle through them. next... :-) Is there anything you can point me to on the talk? I'd be really interested in reading it. ----------------------------------------------------------------- You are blocking all the facebook/google+ like and the insane amount of advertisement (read: tracking) networks who are included on almost every page do you? As everytime you fetch a page, even if it is not the main site, you also hit them for an ad or a like-button (even if it is just the image and you don't actually click you hit their server) and voila you are tracked anyway. ----------------------------------------------------------------- I have never done facebook and I do very little google (mainly just Earth as nothing free can compete with it afaik) for just these reasons. See Urchin (http://www.google.com/urchin/features.html) and watch your browser for _utma, _utmb, etc cookies. And, yes, I block every cookie (except the few I want to allow) as the various browsers I use all are set to "ask me every time". The bad thing, though, is what they send 'back home'. I am curious and have been looking into that recently. scott Giving dynamic addresses out thus only still have one valid reason: nomadic users and the ability to aggregate prefixes inside a network. Because when users are static, you just route a /36 to a location and route prefixes out of that to the users and voila. When they are nomadic/mobile you don't want all those millions of /48s polluting your iBGP though. For every other case, dynamic addresses just make no sense, except for the cash cow that they are and that is the real reason that is the default being offered, as technically they cost more money. Greets, Jeroen From rob-lists at bpsnetworks.com Wed Jul 27 13:29:39 2011 From: rob-lists at bpsnetworks.com (Robert Haas) Date: Wed, 27 Jul 2011 13:29:39 -0500 Subject: XO Contact - Thank You In-Reply-To: <0f7201cc4bd0$c7e3d620$57ab8260$@com> References: <0f7201cc4bd0$c7e3d620$57ab8260$@com> Message-ID: <138401cc4c8b$25759610$7060c230$@com> I just wanted to say thank you to all of those that offered assistance and or contact information. The issue has been resolved. Thanks, Robert Haas -----Original Message----- From: Robert Haas [mailto:rob-lists at bpsnetworks.com] Sent: Tuesday, July 26, 2011 3:16 PM To: nanog at nanog.org Subject: XO Contact Can someone from XO contact me (or if someone has a contact within XO, I'd appreciate it). We are having reachability issues from our network 74.91.64.0/20 AS36243 to the XO network. Thanks, Robert Haas 573-293-2638 From walter.keen at rainierconnect.net Wed Jul 27 13:41:10 2011 From: walter.keen at rainierconnect.net (Walter Keen) Date: Wed, 27 Jul 2011 11:41:10 -0700 Subject: Comcast Bussiness Class and GRE Tunnels In-Reply-To: References: <4E2ED839.5090709@blastcomm.com> <7780129e5ef3d30f1421ca9bad638be0@visp.net.lb> <20110727092333.GZ3135@hezmatt.org> <20110727101516.GA3135@hezmatt.org> Message-ID: <4E305BC6.6080405@rainierconnect.net> We're evaluating a good spread of Mikrotik products as well, both for wireless AP's and general routers. Almost worked out all the features(some features have names that conflict with other vendors, or operate unlike you expect them to), but for the price, even of their higher end ones (RB1100, online for $399) it has 13 Ge ports, and appears to be able to route traffic at faster speeds than I can get a competitor (cisco/juniper) box for. We used the built-in speed test (iperf) and got 970mbit (and about 70% cpu usage) between 2 RB1100's (connected by a single routed gigabit connection) and about 1.4gbit to a local address on the box, which isn't probably a fair throughput test, but is a good test of where the cpu maxes out, since there doesn't appear to be any asic level forwarding unless you are switching layer 2 traffic. For the price, I'm impressed, also the operating temperature range being so wide lets us put them in places we couldn't (supportably) put a cisco or juniper low-end (or high end) box, since we have some remotes where we need to go down to -10C or so. Walter Keen Network Engineer Rainier Connect (P) 360-832-4024 (C) 253-302-0194 On 07/27/2011 08:15 AM, David E. Smith wrote: >> WT*F*? I've never understood the appeal of Microtik, and now I understand >> it even less. >> >> > The software is... quirky, at times, but some of their hardware, especially > on the very low-end, is hard to beat. > > For instance, they make a SOHO router with five Gigabit Ethernet ports for > $70, which has point-and-click access to MPLS, DHCP (server and client), a > few different flavors of VPN including IPSec, and a bunch of other stuff. It > even supports BGP, though you're not going to do very much with that > system's 32MB RAM. > > If you really wanted, you could buy the hardware then re-flash it with > something else; the CPU on this particular system is a MIPS 24K, and there's > probably other embedded Linux/*BSD distributions that would work well > enough. > > David Smith > MVN.net From jeroen at unfix.org Wed Jul 27 14:03:19 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 27 Jul 2011 21:03:19 +0200 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <20110727112745.69A316B9@resin11.mta.everyone.net> References: <20110727112745.69A316B9@resin11.mta.everyone.net> Message-ID: <4E3060F7.4020804@unfix.org> On 2011-07-27 20:27 , Scott Weeks wrote: > > > --- jeroen at unfix.org wrote: > From: Jeroen Massar > On 2011-07-27 03:25 , Scott Weeks wrote: >> -------- matt.addison at lists.evilgeni.us wrote: --------------------- >>> [..] 1: http://panopticlick.eff.org/ >> >> All you need to do with what that site says is write a sh script that >> deletes and then creates the same user. > > And there you sprung into a trap. You will be the only one doing this > and having no history and thus you stick out very well, as the new guy > on the Internet every single day, from a similar prefix, but still > accessing a similar set of hosts etc. I think I did a talk about that at > CCC last year ;) > ------------------------------------------------- [ Scott, please fix your mail program, as the quoting you are using is horrible. I wrote the "All you need" part while you wrote the "sprung in a trap" part, standard quoting rules make it seem the other way ] > Not from the same prefix. I have multiple networks coming into my house and I cycle through them. next... :-) The source address is not the point where you get profiled, it is the destination address. Or do you also cycle prefixes for your mail server? And I guess you also don't use DNS then ;) > Is there anything you can point me to on the talk? I'd be really interested in reading it. I suggest you watch the vid on Youtube or from one of the CCC boxes and of course grab the PPT from my website then you have everything there publicly is. The PPT has lot less than the story I told though ;) As for cycling prefixes or changing addresses, it won't help you at all as you are still going to connect as a way of habit to the same hosts/sites that you connected to previously. And as an engineer type you probably whip out the SSH quite quickly to connect to some or or another and that is not the pattern that an innocent 8 year old is following... (hmmm begs to differ if there are actually innocent ones left but heck ;) There is unfortunately not a real way to hide, except making sure that the adversary you don't want to know what you are doing on the net can't at all see what you are doing in the first place. And that is quite a tricky one to accomplish, the best bet as a wolf is to don your sheep uniform and go sit in between the rest of the sheep and act like a sheep and be a sheep as otherwise you'll blow your cover very quickly. It of course all depends what the adversary is and what you are protecting against ;) Greets, Jeroen From owen at delong.com Wed Jul 27 14:11:39 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 27 Jul 2011 12:11:39 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <0E3C94C5-DB8A-4CEB-9769-613E8D61132B@baycix.de> References: <0904D2C5-0BBC-40B9-91BB-1677A95C3134@delong.com> <0E3C94C5-DB8A-4CEB-9769-613E8D61132B@baycix.de> Message-ID: <225AD143-61F7-47BF-B121-489C90B4378D@delong.com> On Jul 27, 2011, at 6:14 AM, Sascha Lenz wrote: > Hi Owen, > >>> >>>> Hi all, >>>> >>>> I will like to know, from those deploying IPv6 services to residential >>>> customers, if you are planning to provide static or dynamic IPv6 prefixes. >>>> >>>> Just to be clear, I'm for static prefix delegation to residential >>>> customers, however I heard that some ISPs are doing dynamic delegations, >>>> the same way as is common today with IPv4. >>>> >>>> I don't thin it make sense, as the main reason for doing so in IPv4 was >>>> address exhaustion and legacy oversubscription models such as PPP/dial-up. >>> >>> well, it does make sense for most of the residential customers nowadays, because >>> they are indoctrinated with this idea of dynamic+NAT == privacy for over a decade >>> now and don't know any better. >>> >> IMNSHO, education is always a better alternative than preserving ignorance or >> worse, mis-information. >> > > I'm fully with you there, probably i should have elaborated a bit more. > > In general, what Daniel said - at least in germany we have this problem that > static vs. dynamic Internet address assignments make a whole lot of a difference > in privacy when it comes to legal issues. > I don't doubt it? The German government has a long history of misunderstanding privacy and what is required for real privacy. > AND, even though we have next to no IPv6-deployment on a big scale here, there is > plenty of "education" going on in various media about how IPv6 will kill privacy > with "life-long IP addresses" and so on. > I think you are confusing "education" with mis-information. We have the same problem with the media in the US. Especially Fox and other Rupert Murdoch organizations. (Yes, I realize you quoted "education" to emphasize this, but, when we call it by their terms, we propagate the myth that it is education.) More effort is needed to re-educate the media and show them the true threats to privacy. The reality is that a life-long prefix doesn't tell me anything more than the neighborhood prefix will without other data. You aren't going to be able to get around the neighborhood prefix issue no matter how often you renumber your subscribers, and the other information will still provide the same correlations. > It's just not possible to counter that with technical arguments, at least not in the short-term. > I disagree. It may not be possible to win the debate in the short term, but, that's no excuse for failing to make the argument. We may be forced to do dumb things, but, we can at least point out that they are dumb while we do them. > I apologize for generalizing the situation in germany without explaining. I really hope > it's different in other markets and you are right. > It is. In the US, the government is working hard to eliminate privacy anyway, so, there is no such government opposition no matter how misinformed they are about the issue. ;-) > But you will lose customers here if you don't offer some kind of dynamic prefixes, and > if you're dealing with the mass-market, you can't afford that. > As I said, we may be forced to do dumb things, either by customer demand or by government intervention. However, it never gets better if we fail to point out that what we are doing is dumb along the way. > Hence, my suggestion to just let your customers chose. Problem solved. > I have no problem with the solution, but, I have a serious problem with simply rolling over with the solution and not making a technical argument as to why it is both costly and counter-productive. Worst of all, your customers have this false sense of security believing that their dynamic addresses actually provide some measure of privacy. >> >>> The best current practice would be, to default to a dynamic prefix, but enable your >>> more advanced customers to change that to a static prefix at will in your customer >>> service web-portal or something. >>> >> >> Sounds unnecessarily complicated and with absolutely no benefit whatsoever. >> > > In this case, i beg to differ though. > It's not complicated but as easy as some change in your RADIUS database. > And, in contrast to things like NAT66, it doesn't break anything. > It's not particularly complicated, but, it is unnecessarily complicated. It is more complicated than straight static addressing and there is no need for it other than FUD and misperception. Yes, there are worse solutions available. Heart failure is worse than kidney disease. I would prefer to avoid both. > So, in my opinion, this is about giving the customers a choice, with no downsides. > It's somewhat similar to "privacy extensions - yes or no? default or not?" in the end. > In my opinion, it is not without down-sides. It complicates several things, such as troubleshooting, management, support systems, lawful intercept (ok, complicating this may not be a bad thing), log and event correlation, trend analysis, etc. It has additional costs that result from those complications. > One could discuss what the default should be, dynamic or static. > But just handing out static addresses even though it's relatively easy to give your > customers a choice, might be seen as "dictating" rather than "educating". > So far, none of our customers have objected, including thousands of tunnel broker users in Germany. > On a side-note: It's totally different with NAT of course, giving the people the choice > to use NAT will break things in the internet, again. I never would opt for that. > Glad to hear it. Yes, NAT is worse than what you propose and I don't really have a problem with the solution where it is required for whatever (marketing, government, FUD, or misperception) reason. However, I wouldn't tout it as the ideal case, but, rather the necessary and minimal compromise to meet the unreasonable and inaccurate expectations. >>> But i have no idea how to sell this to your marketing department. >>> They again are usually used to sell static IPs for an extra fee, and usually don't >>> want to change that with IPv6. That's bullshit for IPv6 of course. >>> >> >> It was mostly bullshit for IPv4. >> > > Selling IPs? Indeed. > But there's nothing in any RIR policy to prevent that (anymore). > Actually I don't believe LACNIC or AfriNIC have policies to allow that at this time. Owen From surfer at mauigateway.com Wed Jul 27 14:27:01 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 27 Jul 2011 12:27:01 -0700 Subject: dynamic or static IPv6 prefixes to residential customers Message-ID: <20110727122701.69A3017C@resin11.mta.everyone.net> ------ jeroen at unfix.org wrote: ------- It of course all depends what the adversary is and what you are protecting against ;) -------------------------------------- Thanks for all the responses. It is (and has been for the last 14 years on nanog) the best way for me to learn. :-) I am only protecting against what I see as improper actions (bullying) by corpment drones. One can't hide everything, but it doesn't help the internet overall to make it easy for them to do these things. scott From paul4004 at gmail.com Wed Jul 27 15:42:29 2011 From: paul4004 at gmail.com (PC) Date: Wed, 27 Jul 2011 14:42:29 -0600 Subject: OOB In-Reply-To: References: <018501cc4b9c$bdb1f6c0$3915e440$@org> <20110726213404.GG20415@besserwisser.org> Message-ID: If you can make a phone call, it generally works acceptable enough for a basic SSH session. Lock the session at 1xrtt (if using CDMA) if you still have problems (slow) and it will use what amounts to a voice channel. In the USA, Verizon 4g LTE also offers some better in-building penetration simply due to the spectrum used (700mhz). On the 3g deployment I did, I built an ipsec vpn to the provider and have a private IP assigned directly to the cellular device instead of individual VPNs per-console server. As for Equinox in particular, you might be able to use the house wifi instead for your VPN... Many vendors have 3g/wifi console servers (or both) that auto-vpn home. I can't see a good reason to use analog lines anymore unless 3g isn't serviceable at the location. If you can't afford a 3g device, you can roll your own with any cheap router running DD-WRT or OpenWRT + usb ports + usr/serial dongles. Use "ser2net" to handle the interface between TCP and a serial port (but one could connect and use screen/whatever if they wanted). On Tue, Jul 26, 2011 at 8:33 PM, Christopher Morrow wrote: > On Tue, Jul 26, 2011 at 5:34 PM, M?ns Nilsson > wrote: > > Subject: Re: OOB Date: Tue, Jul 26, 2011 at 10:14:21AM -0400 Quoting > Christopher Morrow (morrowc.lists at gmail.com): > >> On Tue, Jul 26, 2011 at 10:03 AM, Paul Stewart > wrote: > >> > We do everything in-band with strict monitoring/policies in place. > >> > >> what do you do if your in-band fails? if a router/switch/ROADM is > >> isolated from the rest of your network? > >> (isn't that the core point of the OP?) > > > > Vendor C sells nice small routers with something like CAB-OCTAL-ASYNC > > _and_ a 3G modem instead of the BRI port. The 3G modem keeps its > > connection up (our telecom provider has true flat rate on domestic 3G, > > YMMV) and VPN's to the head office much like any other telecommuter. This > > cuts through all telco stupidity with firewalled or NAT'ed 3G phones > > etc, especially if one uses the break-out-from-hotel-LAN functions of > > the VPN system. The router of course actively keeps the VPN up and > > reestablishes it if needed. > > how well does that work inside a big metal box like equinix? > > You are, of course, just making a singular point: "Find something to > make yourself an OOB network, hey this thing does vpn over 3g, neato!" > I agree, it's neat.. it may not fit all square holes, sometimes you > need a round or triangle shaped plug. > > From denys at visp.net.lb Wed Jul 27 16:05:14 2011 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Thu, 28 Jul 2011 00:05:14 +0300 Subject: Comcast Bussiness Class and GRE Tunnels In-Reply-To: References: <4E2ED839.5090709@blastcomm.com> <7780129e5ef3d30f1421ca9bad638be0@visp.net.lb> <20110727092333.GZ3135@hezmatt.org> <20110727101516.GA3135@hezmatt.org> Message-ID: On Wed, 27 Jul 2011 10:15:04 -0500, David E. Smith wrote: >> WT*F*? I've never understood the appeal of Microtik, and now I >> understand >> it even less. >> >> > The software is... quirky, at times, but some of their hardware, > especially > on the very low-end, is hard to beat. > > For instance, they make a SOHO router with five Gigabit Ethernet > ports for > $70, which has point-and-click access to MPLS, DHCP (server and > client), a > few different flavors of VPN including IPSec, and a bunch of other > stuff. It > even supports BGP, though you're not going to do very much with that > system's 32MB RAM. > > If you really wanted, you could buy the hardware then re-flash it > with > something else; the CPU on this particular system is a MIPS 24K, and > there's > probably other embedded Linux/*BSD distributions that would work well > enough. > > David Smith > MVN.net I guess vendors are just not interested. D-Link DIR-600, here in Lebanon $30. Zyxel Keenetic also similar price. Only one problem, Mikrotik are 32Mbyte flash, and those are 8Mbyte. My friend developing firmware for this platform (RT3050/3052, Wive-RTNL project) and can put almost any software there, it is opensource project. As benefit this Ralink platform has hardware wirespeed(100Mbit) NAT offload on RT3052, and guy able to make it work even on 3050 (even officially it is not supported there). Technically it is possible to run gigabit there even, but current vendors do not produce such products. I think on cheap platforms, they have wirespeed gigabit only on switching functions, but rest will suck. Their top products can do more, but they are still cannot beat PC with Linux. RB1100, $400 for 150 Kpps with NAT and 300 Kpps without, it is not that good. The only major and important difference in "schematics" with routers that can be reflashed is flash size and sometimes RAM. 64Mbit SPI flash 2.12$, and Mikrotik uses this days 512Mbit NAND, $7.01 . ALso they have nice circuits for variable power, with DC-DC converter, but nothing unusual or innovative, like Cisco or others has. Before they had some funny circuit with Xilinx FPGA to run NOR flash over SPI. Note: DD-WRT on RT305x suck. Their wireless support are incomplete, and no NAT offload. --- System administrator Denys Fedoryshchenko Virtual ISP S.A.L. From joelja at bogus.com Thu Jul 28 10:03:31 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 28 Jul 2011 11:03:31 -0400 Subject: Comcast Bussiness Class and GRE Tunnels In-Reply-To: References: <4E2ED839.5090709@blastcomm.com> <7780129e5ef3d30f1421ca9bad638be0@visp.net.lb> <20110727092333.GZ3135@hezmatt.org> <20110727101516.GA3135@hezmatt.org> Message-ID: <8DB7F61D-795E-4546-8DA1-FE394E84C35C@bogus.com> On Jul 27, 2011, at 5:05 PM, Denys Fedoryshchenko wrote: > On Wed, 27 Jul 2011 10:15:04 -0500, David E. Smith wrote: >>> > I think on cheap platforms, they have wirespeed gigabit only on switching functions, but rest will suck. Their top products can do more, but they are still cannot beat PC with Linux. RB1100, $400 for 150 Kpps with NAT and 300 Kpps without, it is not that good. atheros ar7161 system on a chip can run as fast as 800mhz has dual gig-e macs and supports 32bit 66mhz pci operation and when coupled with a companion ethernet switch it can result in a fairly hefty little router platform. an example of one would be routerboard 433AH or ubiquiti router-station pro. BOM and flexibility is going to ultimately determine cost but these are substatially more powerful than a lot of smaller embedded platforms we've be using including geode/elan based pc devices. > The only major and important difference in "schematics" with routers that can be reflashed is flash size and sometimes RAM. 64Mbit SPI flash 2.12$, and Mikrotik uses this days 512Mbit NAND, $7.01 . ALso they have nice circuits for variable power, with DC-DC converter, but nothing unusual or innovative, like Cisco or others has. Before they had some funny circuit with Xilinx FPGA to run NOR flash over SPI. > Note: DD-WRT on RT305x suck. Their wireless support are incomplete, and no NAT offload. > > --- > System administrator > Denys Fedoryshchenko > Virtual ISP S.A.L. > > From infolacnog at lacnog.org Thu Jul 28 10:19:34 2011 From: infolacnog at lacnog.org (Christian O'Flaherty) Date: Thu, 28 Jul 2011 12:19:34 -0300 Subject: LACNOG 2011 - Buenos Aires - Oct 4-7 Message-ID: <80494340-202D-4BD7-976A-D541E6E6FCB8@lacnog.org> LACNOG2011 - Call for presentations - Due date - July, 31st English: http://www.lacnog.org/en/lacnog-2011-call-presentations Espa?ol: http://www.lacnog.org/es/lacnog-2011-llamado-a-presentaci%C3%B3n-trabajos Portugues: http://www.lacnog.org/es/lacnog-2011-llamado-a-presentaci%C3%B3n-trabajos From black at csulb.edu Thu Jul 28 10:19:11 2011 From: black at csulb.edu (Matthew Black) Date: Thu, 28 Jul 2011 08:19:11 -0700 Subject: 3Com Total Control documentation In-Reply-To: References: Message-ID: My sympathies to your unfortunate situation. The last tech probably doesn't want to be bothered...that's a management issue. A PortMaster 3 may solve your problems. I looked at 3Com Total Control about 15 years ago but know nothing about it. We employed US Robotics rack-mount chassis paired with Xyplex terminal servers. That was replaced with the Livingston PortMaster 3 (later bought by Lucent). Each PortMaster 3 connects to two T1 lines and a 10BaseT Ethernet, supporting 48 users. Use RADIUS authentication and you're all set. You can probably pick up some of those for a hundred dollars. You will need to learn about T1 phone lines and RADIUS. Best regards, matthew black california state university, long beach On Tue, 26 Jul 2011 19:35:35 -0700 Hector Herrera wrote: > Hi, > > I have "inherited" several 3Com Total Control racks that are used to > provide dial-up service to rural areas. > > The racks have been running in auto-pilot for several years now and > the last tech's comments with regard to the racks was along the lines > of "I don't know". > > I would like to regain control over the network as recently the > outages are becoming more frequent and extended and we don't usually > know about it until customers call the support line a week later. > > Decommissioning the racks is not currently an option as there are no > other reasonable alternatives for internet service (other than > satellite). The ISP being an marginal area provider is also short in > funds. > > I'm having a hard time finding documentation, firmware updates or > support for these racks. > > As far as I can tell, the current owner of the product line is > UTStarCom in China, but their website does not make any reference to > the product. > > I also found a company that sells the equipment and provides support > contracts, WRCA, but their pricing is out of the budget range for the > ISP. > > I am hoping that some of you who used to work with this equipment may > still have documentation CDs or firmware updates stored away > somewhere. > > I'm looking for any documentation, firmware updates and some help > figuring out which NAC goes with which NIC. > > Or perhaps you can suggest other companies that provide support for > the equipment at more reasonable rates. > > I would be willing to setup a public repository to help other admins. > > Thanks, > > -- > Hector Herrera > > From black at csulb.edu Thu Jul 28 10:22:03 2011 From: black at csulb.edu (Matthew Black) Date: Thu, 28 Jul 2011 08:22:03 -0700 Subject: 3Com Total Control documentation In-Reply-To: References: Message-ID: By the way, a simple Google search of "3Com Total Control" yields this as the first result: http://www.brianpinon.com/brian/assets/PDFs/3Com/ARCGSG.pdf matthew On Thu, 28 Jul 2011 08:19:11 -0700 Matthew Black wrote: > My sympathies to your unfortunate situation. The last tech probably >doesn't want to be bothered...that's a management issue. A PortMaster 3 may >solve your problems. > > I looked at 3Com Total Control about 15 years ago but know nothing about >it. We employed US Robotics rack-mount chassis paired with Xyplex terminal >servers. That was replaced with the Livingston PortMaster 3 (later bought >by Lucent). Each PortMaster 3 connects to two T1 lines and a 10BaseT >Ethernet, supporting 48 users. Use RADIUS authentication and you're all >set. > > You can probably pick up some of those for a hundred dollars. > > You will need to learn about T1 phone lines and RADIUS. > > Best regards, > > matthew black > california state university, long beach > > > On Tue, 26 Jul 2011 19:35:35 -0700 > Hector Herrera wrote: >> Hi, >> >> I have "inherited" several 3Com Total Control racks that are used to >> provide dial-up service to rural areas. >> >> The racks have been running in auto-pilot for several years now and >> the last tech's comments with regard to the racks was along the lines >> of "I don't know". >> >> I would like to regain control over the network as recently the >> outages are becoming more frequent and extended and we don't usually >> know about it until customers call the support line a week later. >> >> Decommissioning the racks is not currently an option as there are no >> other reasonable alternatives for internet service (other than >> satellite). The ISP being an marginal area provider is also short in >> funds. >> >> I'm having a hard time finding documentation, firmware updates or >> support for these racks. >> >> As far as I can tell, the current owner of the product line is >> UTStarCom in China, but their website does not make any reference to >> the product. >> >> I also found a company that sells the equipment and provides support >> contracts, WRCA, but their pricing is out of the budget range for the >> ISP. >> >> I am hoping that some of you who used to work with this equipment may >> still have documentation CDs or firmware updates stored away >> somewhere. >> >> I'm looking for any documentation, firmware updates and some help >> figuring out which NAC goes with which NIC. >> >> Or perhaps you can suggest other companies that provide support for >> the equipment at more reasonable rates. >> >> I would be willing to setup a public repository to help other admins. >> >> Thanks, >> >> -- >> Hector Herrera From alex at corp.nac.net Thu Jul 28 11:15:47 2011 From: alex at corp.nac.net (Alex Rubenstein) Date: Thu, 28 Jul 2011 12:15:47 -0400 Subject: 3Com Total Control documentation Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB802D62E86EB@EXCHMBX.hq.nac.net> We recently dumped about 40 into a dumpster. I shed a tear. Sent via Blackberry while presumably driving with one hand ----- Original Message ----- From: Matthew Black To: hectorh at pobox.com ; NANOG list Sent: Thu Jul 28 11:19:11 2011 Subject: Re: 3Com Total Control documentation My sympathies to your unfortunate situation. The last tech probably doesn't want to be bothered...that's a management issue. A PortMaster 3 may solve your problems. I looked at 3Com Total Control about 15 years ago but know nothing about it. We employed US Robotics rack-mount chassis paired with Xyplex terminal servers. That was replaced with the Livingston PortMaster 3 (later bought by Lucent). Each PortMaster 3 connects to two T1 lines and a 10BaseT Ethernet, supporting 48 users. Use RADIUS authentication and you're all set. You can probably pick up some of those for a hundred dollars. You will need to learn about T1 phone lines and RADIUS. Best regards, matthew black california state university, long beach On Tue, 26 Jul 2011 19:35:35 -0700 Hector Herrera wrote: > Hi, > > I have "inherited" several 3Com Total Control racks that are used to > provide dial-up service to rural areas. > > The racks have been running in auto-pilot for several years now and > the last tech's comments with regard to the racks was along the lines > of "I don't know". > > I would like to regain control over the network as recently the > outages are becoming more frequent and extended and we don't usually > know about it until customers call the support line a week later. > > Decommissioning the racks is not currently an option as there are no > other reasonable alternatives for internet service (other than > satellite). The ISP being an marginal area provider is also short in > funds. > > I'm having a hard time finding documentation, firmware updates or > support for these racks. > > As far as I can tell, the current owner of the product line is > UTStarCom in China, but their website does not make any reference to > the product. > > I also found a company that sells the equipment and provides support > contracts, WRCA, but their pricing is out of the budget range for the > ISP. > > I am hoping that some of you who used to work with this equipment may > still have documentation CDs or firmware updates stored away > somewhere. > > I'm looking for any documentation, firmware updates and some help > figuring out which NAC goes with which NIC. > > Or perhaps you can suggest other companies that provide support for > the equipment at more reasonable rates. > > I would be willing to setup a public repository to help other admins. > > Thanks, > > -- > Hector Herrera > > From matt.taber.nanog at gmail.com Thu Jul 28 11:18:14 2011 From: matt.taber.nanog at gmail.com (Matt Taber) Date: Thu, 28 Jul 2011 12:18:14 -0400 Subject: 3Com Total Control documentation In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB802D62E86EB@EXCHMBX.hq.nac.net> References: <2D0AF14BA6FB334988BC1F5D4FC38CB802D62E86EB@EXCHMBX.hq.nac.net> Message-ID: <4E318BC6.3060102@gmail.com> I'm assuming you meant you recycled them. mrt On 7/28/2011 12:15 PM, Alex Rubenstein wrote: > We recently dumped about 40 into a dumpster. > > I shed a tear. > > > Sent via Blackberry while presumably driving with one hand > > ----- Original Message ----- > From: Matthew Black > To: hectorh at pobox.com; NANOG list > Sent: Thu Jul 28 11:19:11 2011 > Subject: Re: 3Com Total Control documentation > > My sympathies to your unfortunate situation. The last tech probably doesn't > want to be bothered...that's a management issue. A PortMaster 3 may solve > your problems. > > I looked at 3Com Total Control about 15 years ago but know nothing about it. > We employed US Robotics rack-mount chassis paired with Xyplex terminal > servers. That was replaced with the Livingston PortMaster 3 (later bought by > Lucent). Each PortMaster 3 connects to two T1 lines and a 10BaseT Ethernet, > supporting 48 users. Use RADIUS authentication and you're all set. > > You can probably pick up some of those for a hundred dollars. > > You will need to learn about T1 phone lines and RADIUS. > > Best regards, > > matthew black > california state university, long beach > > > On Tue, 26 Jul 2011 19:35:35 -0700 > Hector Herrera wrote: >> Hi, >> >> I have "inherited" several 3Com Total Control racks that are used to >> provide dial-up service to rural areas. >> >> The racks have been running in auto-pilot for several years now and >> the last tech's comments with regard to the racks was along the lines >> of "I don't know". >> >> I would like to regain control over the network as recently the >> outages are becoming more frequent and extended and we don't usually >> know about it until customers call the support line a week later. >> >> Decommissioning the racks is not currently an option as there are no >> other reasonable alternatives for internet service (other than >> satellite). The ISP being an marginal area provider is also short in >> funds. >> >> I'm having a hard time finding documentation, firmware updates or >> support for these racks. >> >> As far as I can tell, the current owner of the product line is >> UTStarCom in China, but their website does not make any reference to >> the product. >> >> I also found a company that sells the equipment and provides support >> contracts, WRCA, but their pricing is out of the budget range for the >> ISP. >> >> I am hoping that some of you who used to work with this equipment may >> still have documentation CDs or firmware updates stored away >> somewhere. >> >> I'm looking for any documentation, firmware updates and some help >> figuring out which NAC goes with which NIC. >> >> Or perhaps you can suggest other companies that provide support for >> the equipment at more reasonable rates. >> >> I would be willing to setup a public repository to help other admins. >> >> Thanks, >> >> -- >> Hector Herrera >> >> From bruns at 2mbit.com Thu Jul 28 11:21:41 2011 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 28 Jul 2011 10:21:41 -0600 Subject: 3Com Total Control documentation In-Reply-To: References: Message-ID: <4E318C95.3000601@2mbit.com> On 7/28/11 9:19 AM, Matthew Black wrote: > My sympathies to your unfortunate situation. The last tech probably > doesn't want to be bothered...that's a management issue. A PortMaster 3 > may solve your problems. I've always been a fan of the Lucent MAX series. In fact, I have a MAX 60xx sitting in my garage (bought it as a reminder of what I used to do). Great little boxes, v.90 with the right cards, and fairly easy to manage at the same time. They're cheap, plentiful, and quite a few people can help you manage them (I built my first dialup ISP with these). I do second the use of a Portmaster 2 or 3. They're getting up there in age, but I do believe one of the ones I deployed late 90s is still chugging along for ISDN use. :) -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From dmm at 1-4-5.net Thu Jul 28 12:13:10 2011 From: dmm at 1-4-5.net (David Meyer) Date: Thu, 28 Jul 2011 13:13:10 -0400 Subject: [NANOG-announce] please submit your talks for NANOG 53! Message-ID: Folks, NANOG 53 is fast approaching. Please submit your talks for the program! Thanks, Dave (for the NANOG PC) _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From alex at corp.nac.net Thu Jul 28 12:39:22 2011 From: alex at corp.nac.net (Alex Rubenstein) Date: Thu, 28 Jul 2011 13:39:22 -0400 Subject: 3Com Total Control documentation Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB802D62E86EE@EXCHMBX.hq.nac.net> Yeah, you are correct. But it was still a dumpster. We recycle a lot of metal around here :) Sent via Blackberry while presumably driving with one hand ________________________________ From: Matt Taber To: Alex Rubenstein Cc: 'black at csulb.edu' ; 'hectorh at pobox.com' ; 'nanog at nanog.org' Sent: Thu Jul 28 12:18:14 2011 Subject: Re: 3Com Total Control documentation I'm assuming you meant you recycled them. mrt On 7/28/2011 12:15 PM, Alex Rubenstein wrote: We recently dumped about 40 into a dumpster. I shed a tear. Sent via Blackberry while presumably driving with one hand ----- Original Message ----- From: Matthew Black To: hectorh at pobox.com ; NANOG list Sent: Thu Jul 28 11:19:11 2011 Subject: Re: 3Com Total Control documentation My sympathies to your unfortunate situation. The last tech probably doesn't want to be bothered...that's a management issue. A PortMaster 3 may solve your problems. I looked at 3Com Total Control about 15 years ago but know nothing about it. We employed US Robotics rack-mount chassis paired with Xyplex terminal servers. That was replaced with the Livingston PortMaster 3 (later bought by Lucent). Each PortMaster 3 connects to two T1 lines and a 10BaseT Ethernet, supporting 48 users. Use RADIUS authentication and you're all set. You can probably pick up some of those for a hundred dollars. You will need to learn about T1 phone lines and RADIUS. Best regards, matthew black california state university, long beach On Tue, 26 Jul 2011 19:35:35 -0700 Hector Herrera wrote: Hi, I have "inherited" several 3Com Total Control racks that are used to provide dial-up service to rural areas. The racks have been running in auto-pilot for several years now and the last tech's comments with regard to the racks was along the lines of "I don't know". I would like to regain control over the network as recently the outages are becoming more frequent and extended and we don't usually know about it until customers call the support line a week later. Decommissioning the racks is not currently an option as there are no other reasonable alternatives for internet service (other than satellite). The ISP being an marginal area provider is also short in funds. I'm having a hard time finding documentation, firmware updates or support for these racks. As far as I can tell, the current owner of the product line is UTStarCom in China, but their website does not make any reference to the product. I also found a company that sells the equipment and provides support contracts, WRCA, but their pricing is out of the budget range for the ISP. I am hoping that some of you who used to work with this equipment may still have documentation CDs or firmware updates stored away somewhere. I'm looking for any documentation, firmware updates and some help figuring out which NAC goes with which NIC. Or perhaps you can suggest other companies that provide support for the equipment at more reasonable rates. I would be willing to setup a public repository to help other admins. Thanks, -- Hector Herrera From brwatters at absfoc.com Thu Jul 28 14:31:13 2011 From: brwatters at absfoc.com (Brian R. Watters) Date: Thu, 28 Jul 2011 12:31:13 -0700 (PDT) Subject: SORBS contact In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB802D62E86EE@EXCHMBX.hq.nac.net> Message-ID: <7ca7f45c-55da-4ce3-b0f6-db3ce3108b48@brw-abs-office> We are looking for a SORBS contact as their web site and registration process is less than friendly if somehow you get listed by them. BRW From Valdis.Kletnieks at vt.edu Thu Jul 28 14:44:29 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 28 Jul 2011 15:44:29 -0400 Subject: SORBS contact In-Reply-To: Your message of "Thu, 28 Jul 2011 12:31:13 PDT." <7ca7f45c-55da-4ce3-b0f6-db3ce3108b48@brw-abs-office> References: <7ca7f45c-55da-4ce3-b0f6-db3ce3108b48@brw-abs-office> Message-ID: <17214.1311882269@turing-police.cc.vt.edu> On Thu, 28 Jul 2011 12:31:13 PDT, "Brian R. Watters" said: > We are looking for a SORBS contact as their web site and registration process > is less than friendly if somehow you get listed by them. You're new here, aren't you? :) (Sorry, couldn't resist. Previous discussion on NANOG: http://www.google.com/search?sourceid=mozclient&scoring=d&ie=utf-8&oe=utf-8&q=sorbs+site%3Ananog%2Eorg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From nenolod at systeminplace.net Thu Jul 28 14:50:25 2011 From: nenolod at systeminplace.net (William Pitcock) Date: Thu, 28 Jul 2011 14:50:25 -0500 Subject: SORBS contact In-Reply-To: <7ca7f45c-55da-4ce3-b0f6-db3ce3108b48@brw-abs-office> References: <2D0AF14BA6FB334988BC1F5D4FC38CB802D62E86EE@EXCHMBX.hq.nac.net> <7ca7f45c-55da-4ce3-b0f6-db3ce3108b48@brw-abs-office> Message-ID: <20110728145025.3d04c46b@petrie> On Thu, 28 Jul 2011 12:31:13 -0700 (PDT) "Brian R. Watters" wrote: > We are looking for a SORBS contact as their web site and registration > process is less than friendly if somehow you get listed by them. As I recall it, you can manually create an account on their request-tracker instance and open a ticket through that requesting delisting... however, complaining on NANOG is probably just going to result in a less than friendly response from Michelle (at least as history as shown). William From dorn at hetzel.org Thu Jul 28 14:47:56 2011 From: dorn at hetzel.org (Dorn Hetzel) Date: Thu, 28 Jul 2011 15:47:56 -0400 Subject: SORBS contact In-Reply-To: <20110728145025.3d04c46b@petrie> References: <2D0AF14BA6FB334988BC1F5D4FC38CB802D62E86EE@EXCHMBX.hq.nac.net> <7ca7f45c-55da-4ce3-b0f6-db3ce3108b48@brw-abs-office> <20110728145025.3d04c46b@petrie> Message-ID: You want to speak to SORBS? Good luck with that. Unless you are Chuck Norris; Chuck Norris can speak with SORBS anytime he wants :) On Thu, Jul 28, 2011 at 3:50 PM, William Pitcock wrote: > On Thu, 28 Jul 2011 12:31:13 -0700 (PDT) > "Brian R. Watters" wrote: > > > We are looking for a SORBS contact as their web site and registration > > process is less than friendly if somehow you get listed by them. > > As I recall it, you can manually create an account on their > request-tracker instance and open a ticket through that requesting > delisting... however, complaining on NANOG is probably just going to > result in a less than friendly response from Michelle (at least as > history as shown). > > William > > From paul4004 at gmail.com Thu Jul 28 15:00:27 2011 From: paul4004 at gmail.com (PC) Date: Thu, 28 Jul 2011 14:00:27 -0600 Subject: SORBS contact In-Reply-To: References: <2D0AF14BA6FB334988BC1F5D4FC38CB802D62E86EE@EXCHMBX.hq.nac.net> <7ca7f45c-55da-4ce3-b0f6-db3ce3108b48@brw-abs-office> <20110728145025.3d04c46b@petrie> Message-ID: Last time I went through this... first it was they didn't like my RDNS, so I added "Static" to it. Then it was my ISP didn't SWIP the record properly, they fixed this. Then after that they said my DNS TTL was too low. The final straw was the DNS TTL, we used it for failover to accommodate a redundant mail setup and it wasn't changing. My ISP even tried to intervene with communications from the e-mail address who owned the IP block with no luck. A large part of one of their /16s was listed. Mind you, my space was not listed for spamming, just being dynamic. This was a Metro-E circuit. At around the third iteration (DNS TTL), I just asked the ISP for an additional IP block allocation and moved the mail server there. 2 months later someone updated/closed the ticket and it was delisted My advice? Try the instant de-list process on their web page. If it works the first time, great. If it fails you're in for a long painful experience. Asking the ISP for a new/additional IP block is often quicker. On Thu, Jul 28, 2011 at 1:47 PM, Dorn Hetzel wrote: > You want to speak to SORBS? Good luck with that. Unless you are Chuck > Norris; Chuck Norris can speak with SORBS anytime he wants :) > > On Thu, Jul 28, 2011 at 3:50 PM, William Pitcock > wrote: > > > On Thu, 28 Jul 2011 12:31:13 -0700 (PDT) > > "Brian R. Watters" wrote: > > > > > We are looking for a SORBS contact as their web site and registration > > > process is less than friendly if somehow you get listed by them. > > > > As I recall it, you can manually create an account on their > > request-tracker instance and open a ticket through that requesting > > delisting... however, complaining on NANOG is probably just going to > > result in a less than friendly response from Michelle (at least as > > history as shown). > > > > William > > > > > From brwatters at absfoc.com Thu Jul 28 16:16:23 2011 From: brwatters at absfoc.com (Brian R. Watters) Date: Thu, 28 Jul 2011 14:16:23 -0700 (PDT) Subject: [BULK] Re: SORBS contact In-Reply-To: Message-ID: <1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office> Thanks .. their attempts to reach us are blocked via our Barrcacuda's due to the fact that they are sending with a blank FROM: and as such Barracuda thinks its SPAM .. just to darn funny .. I have whitelisted their domain so on my fourth attempt we will see .. Cant create tickets or communicate with them unless you have an account and you can not get an active account unless you can get an email to activate it .. very frustrating to say the least. ----- Original Message ----- From: "Dorn Hetzel" To: "William Pitcock" Cc: "Brian R. Watters" , nanog at nanog.org Sent: Thursday, July 28, 2011 12:47:56 PM Subject: [BULK] Re: SORBS contact You want to speak to SORBS? Good luck with that. Unless you are Chuck Norris; Chuck Norris can speak with SORBS anytime he wants :) On Thu, Jul 28, 2011 at 3:50 PM, William Pitcock < nenolod at systeminplace.net > wrote: On Thu, 28 Jul 2011 12:31:13 -0700 (PDT) "Brian R. Watters" < brwatters at absfoc.com > wrote: > We are looking for a SORBS contact as their web site and registration > process is less than friendly if somehow you get listed by them. As I recall it, you can manually create an account on their request-tracker instance and open a ticket through that requesting delisting... however, complaining on NANOG is probably just going to result in a less than friendly response from Michelle (at least as history as shown). William From brwatters at absfoc.com Thu Jul 28 16:20:08 2011 From: brwatters at absfoc.com (Brian R. Watters) Date: Thu, 28 Jul 2011 14:20:08 -0700 (PDT) Subject: SORBS contact In-Reply-To: <17214.1311882269@turing-police.cc.vt.edu> Message-ID: <8beae4f1-acd0-4408-9f75-264aff04d788@brw-abs-office> Nope .. just like pain and suffering :( ----- Original Message ----- From: "Valdis Kletnieks" To: "Brian R. Watters" Cc: nanog at nanog.org Sent: Thursday, July 28, 2011 12:44:29 PM Subject: Re: SORBS contact On Thu, 28 Jul 2011 12:31:13 PDT, "Brian R. Watters" said: > We are looking for a SORBS contact as their web site and registration process > is less than friendly if somehow you get listed by them. You're new here, aren't you? :) (Sorry, couldn't resist. Previous discussion on NANOG: http://www.google.com/search?sourceid=mozclient&scoring=d&ie=utf-8&oe=utf-8&q=sorbs+site%3Ananog%2Eorg From mmc at internode.com.au Thu Jul 28 20:19:43 2011 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Fri, 29 Jul 2011 01:19:43 +0000 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: Message-ID: Jordi, We're doing: - dynamic /64 on the link to the customer (PPPoE at this stage) so that PPP directly to a PC will work. (ie. we run SLAAC on this). - static /56 for the customer via DHCPv6 Prefix Delegation. Given our architecture a dynamic /56 would have been better (smaller routing tables in some places), but the reality is we've been somewhat wedged and a static range proves to be a better outcome. FWIW - we're doing IPv6 to customers, today, from our production BNG/BRAS/LNS (whatever you want to call them). MMC -- Matthew Moyle-Croft Peering Manager and Team Lead - Commercial and DSLAMs Internode /Agile Level 5, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From bzs at world.std.com Thu Jul 28 20:23:24 2011 From: bzs at world.std.com (Barry Shein) Date: Thu, 28 Jul 2011 21:23:24 -0400 Subject: SORBS contact In-Reply-To: References: <2D0AF14BA6FB334988BC1F5D4FC38CB802D62E86EE@EXCHMBX.hq.nac.net> <7ca7f45c-55da-4ce3-b0f6-db3ce3108b48@brw-abs-office> <20110728145025.3d04c46b@petrie> Message-ID: <20018.2956.993931.160454@world.std.com> He's the most interesting man in the world...SORBS is on HIS list and can't get off. -- -Barry Shein The World | bzs at 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* From frnkblk at iname.com Thu Jul 28 21:02:43 2011 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 28 Jul 2011 21:02:43 -0500 Subject: [c-nsp] Is Performance Routing, PfR a dead duck? In-Reply-To: <04a401cc4a6d$e12a05a0$a37e10e0$@com> References: <03c101cc4a59$924c4b00$b6e4e100$@com> <4E2CB351.9010209@comcast.net> <03e001cc4a62$66d57f60$34807e20$@com> <4E2CC8CE.5030309@comcast.net> <04a401cc4a6d$e12a05a0$a37e10e0$@com> Message-ID: <001a01cc4d93$9ab312a0$d01937e0$@iname.com> This might be a resource: http://blog.ine.com/2009/12/31/oerpfr-its-always-watching/ Frank -----Original Message----- From: Eric Hileman [mailto:nanog at magemojo.com] Sent: Sunday, July 24, 2011 8:55 PM To: nanog at nanog.org Subject: RE: [c-nsp] Is Performance Routing, PfR a dead duck? Very cool, thanks again. Finding people with having experience with it has been really hard! >From "Cisco Performance Routing FAQs": http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599/ps8 787/prod_qas0900aecd806c4f03.html Q. What is CiscoR Performance Routing (PfR)? A. Cisco Performance Routing complements classic IP routing technologies by adding intelligence to select the best paths to meet application performance requirements. The first phase of Performance Routing technology intelligently optimized application performance over enterprise WANs and to and from the Internet and named Optimized Edge Routing (OER). This technology has evolved to become PfR and enables application performance optimization throughout the enterprise network through an end-to-end, performance-aware network. It would be cool if someone could break down the pieces and how they all fit together :) > > Yeah that's the only place I've seen it used. You are probably right...Pfr moving forward? tv _____ NANOG mailing list NANOG at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog _____ NANOG mailing list NANOG at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog From Valdis.Kletnieks at vt.edu Fri Jul 29 01:46:09 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 29 Jul 2011 02:46:09 -0400 Subject: [BULK] Re: SORBS contact In-Reply-To: Your message of "Thu, 28 Jul 2011 14:16:23 PDT." <1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office> References: <1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office> Message-ID: <12207.1311921969@turing-police.cc.vt.edu> On Thu, 28 Jul 2011 14:16:23 PDT, "Brian R. Watters" said: > Thanks .. their attempts to reach us are blocked via our Barrcacuda's due to > the fact that they are sending with a blank FROM: and as such Barracuda thinks > its SPAM Please clarify. Are they sending MAIL FROM: (syntactically broken, they need to fix it) or MAIL FROM:<> totally valid, and if your Barracuda rejects it, it's *your* problem. And you might want to fix it, since your users will never get a bounce notice from any RFC-compliant mailer - even if they *wanted* to know that their mail wasn't delivered. <> is the RFC-standard way to denote "this mail is a bounce report or other programmatically generated mail, and if it bounces itself, do *not* generate another bounce, as that may start a bounce loop". See RFC5321, sections 3.6, 4.5.5, and 6.1. (And all those of you anti-spam zealots who want to argue about RFC5321's SHOULD/MUST pronouncements on the handling of <>, I'll point out that there's *lots* of wiggle room for those of us with years of SMTP wrangling experience. On the other hand, we're talking about a potentially misconfigured Barracuda here, and if a site has a misconfigured Barracuda, urging RFC-compliant behavior is the only sane choice... ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bill at herrin.us Fri Jul 29 08:48:44 2011 From: bill at herrin.us (William Herrin) Date: Fri, 29 Jul 2011 09:48:44 -0400 Subject: [BULK] Re: SORBS contact In-Reply-To: <12207.1311921969@turing-police.cc.vt.edu> References: <1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office> <12207.1311921969@turing-police.cc.vt.edu> Message-ID: On Fri, Jul 29, 2011 at 2:46 AM, wrote: > And you might want to fix it, since your users will never get a bounce notice > from any RFC-compliant mailer - even if they *wanted* to know that their mail > wasn't delivered. ?<> is the RFC-standard way to denote "this mail is a bounce > report or other programmatically generated mail, and if it bounces itself, do *not* > generate another bounce, as that may start a bounce loop". Correction: It's a standard way to denote that "this mail is a bounce report." Any other sort of programmatically generated email is supposed to use an email address capable of receiving a reply so that the sender becomes aware that it failed to be delivered. One defense against so-called blowback spam is to refuse bounce reports which do not, somewhere within the message, contain an email address that the bounce recipient recently sent to. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Valdis.Kletnieks at vt.edu Fri Jul 29 10:22:30 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 29 Jul 2011 11:22:30 -0400 Subject: [BULK] Re: SORBS contact In-Reply-To: Your message of "Fri, 29 Jul 2011 09:48:44 EDT." References: <1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office> <12207.1311921969@turing-police.cc.vt.edu> Message-ID: <5216.1311952950@turing-police.cc.vt.edu> On Fri, 29 Jul 2011 09:48:44 EDT, William Herrin said: > Correction: It's a standard way to denote that "this mail is a bounce > report." Correction to your correction: What the RFC actually says: 4.5.5. Messages with a Null Reverse-Path There are several types of notification messages that are required by existing and proposed Standards to be sent with a null reverse-path, namely non-delivery notifications as discussed in Section 3.7, other kinds of Delivery Status Notifications (DSNs, RFC 3461 [32]), and Message Disposition Notifications (MDNs, RFC 3798 [37]). All of these kinds of messages are notifications about a previous message, and they are sent to the reverse-path of the previous mail message. (If the delivery of such a notification message fails, that usually indicates a problem with the mail system of the host to which the notification message is addressed. For this reason, at some hosts the MTA is set up to forward such failed notification messages to someone who is able to fix problems with the mail system, e.g., via the postmaster alias.) It's *not* just "bounce reports" (in particular, DSNs and MDNs are not non-delivery (bounce) messages in the sense of section 3.7, and both can be generated in response to *successful* deliveries). generated for *successful* deliveries). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dmburgess at linktechs.net Fri Jul 29 10:41:58 2011 From: dmburgess at linktechs.net (Dennis Burgess) Date: Fri, 29 Jul 2011 10:41:58 -0500 Subject: [outages] Several IPv6 sites down? References: <00cf01cc4dff$dd7a70d0$986f5270$@iname.com> Message-ID: <13175F96BDC3B34AB1425BAE905B3CE50547CD3B@ltiserver.lti.local> Cnn works Charter pings but is SLOW yahoo works. Tracing route to ipv6.cnn.com [2620:100:e000::8001] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 2001:550:2400::1 2 <1 ms <1 ms <1 ms 2001:550:2:1c::1:2 3 57 ms 57 ms 56 ms 2001:470:1f00:16::1 4 56 ms 57 ms 67 ms 2001:470:0:1f::1 5 57 ms 66 ms 57 ms 10gigabitethernet1-2.core1.sjc2.he.net [2001:470 :0:2f::2] 6 57 ms 57 ms 57 ms 2610:18:16:6001::1 7 132 ms 131 ms 143 ms mcr1.smyrna-ga.us.xo.net [2610:18::3050] 8 134 ms 134 ms 134 ms 2620:100:e000:ffff::e 9 134 ms 134 ms 136 ms 2620:100:e000:ffff::29 10 86 ms 88 ms 87 ms 2620:100:e000::8001 ----------------------------------------------------------- Dennis Burgess, Mikrotik Certified Trainer Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" > > > -----Original Message----- > > From: outages-bounces at outages.org [mailto:outages- > > bounces at outages.org] On Behalf Of Frank Bulk > > Sent: Friday, July 29, 2011 9:58 AM > > To: outages at outages.org > > Subject: [outages] Several IPv6 sites down? > > > > Just a few minutes ago three of the 20+ IPv6 sites I monitor became > > inaccessible: > > > > ipv6.cnn.com (IPv6-only) > > HOST: nagios Loss% Snt Last Avg Best Wrst StDev > > 1. 2607:fe28:0:1003::2 0.0% 10 1.4 1.3 1.1 2.4 0.4 > > 2. router-core.mtcnet.net 0.0% 10 1.0 1.1 0.9 1.8 0.3 > > 3. sxct.sxcy.mtcnet.net 0.0% 10 0.9 1.0 0.9 1.1 0.1 > > 4. v6-siouxcenter.sxcy.137.neti 0.0% 10 2.7 3.5 2.7 4.6 0.7 > > 5. v6-ins-db1-et-11-8-204.desm. 0.0% 10 13.1 11.0 8.3 16.6 3.6 > > 6. v6-ins-dc1-et-8-2.desm.netin 0.0% 10 8.5 8.6 8.5 8.9 0.1 > > 7. 2001:428:3801:210:0:1:0:1 0.0% 10 20.7 27.5 20.7 56.8 14.2 > > 8. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 > > 9. vl-60.car2.Dallas1.Level3.ne 0.0% 10 116.7 49.0 41.1 116.7 23.8 > > 10. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 > > > > www.charter.com (IPv4 is fine, just not IPv6) > > HOST: nagios Loss% Snt Last Avg Best Wrst StDev > > 1. 2607:fe28:0:1003::2 0.0% 10 1.1 1.1 1.1 1.2 0.0 > > 2. router-core.mtcnet.net 0.0% 10 1.0 1.0 0.9 1.4 0.1 > > 3. sxct.sxcy.mtcnet.net 0.0% 10 0.9 0.9 0.9 1.0 0.0 > > 4. v6-siouxcenter.sxcy.137.neti 0.0% 10 3.4 3.8 2.8 4.7 0.6 > > 5. v6-ins-db1-et-11-8-204.desm. 0.0% 10 8.3 8.3 8.3 8.5 0.1 > > 6. v6-ins-dc1-et-8-2.desm.netin 0.0% 10 8.5 24.0 8.5 161.5 48.3 > > 7. 2001:428:3801:210:0:1:0:1 0.0% 10 20.8 24.8 20.7 45.5 8.8 > > 8. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 > > > > ipv6.weather.yahoo.com (there's three AAAA records, just > > 2a00:1288:f006:1fe::1000 is not working) > > HOST: nagios Loss% Snt Last Avg Best Wrst StDev > > 1. 2607:fe28:0:1003::2 0.0% 10 1.2 6.5 1.1 54.3 16.8 > > 2. router-core.mtcnet.net 0.0% 10 1.1 1.1 0.9 1.7 0.2 > > 3. sxct.sxcy.mtcnet.net 0.0% 10 0.9 0.9 0.9 1.1 0.1 > > 4. v6-siouxcenter.sxcy.137.neti 0.0% 10 2.7 3.9 2.7 6.3 1.1 > > 5. v6-ins-db1-et-11-8-204.desm. 0.0% 10 13.6 9.4 8.2 13.9 2.3 > > 6. v6-ins-dc1-et-8-2.desm.netin 0.0% 10 8.6 12.6 8.5 40.8 10.2 > > 7. 2001:428:3801:210:0:1:0:1 0.0% 10 20.6 30.0 20.6 112.9 29.1 > > 8. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 > > 9. vl-90.car1.Dallas1.Level3.ne 0.0% 10 41.5 41.3 41.1 41.5 0.1 > > 10. vl-4042.car1.NewYork1.Level3 0.0% 10 58.0 58.6 57.7 63.8 1.9 > > 11. vl-4086.edge3.London1.Level3 0.0% 10 127.2 126.9 126.5 127.3 0.3 > > 12. vl-52.car3.London1.Level3.ne 0.0% 10 127.0 130.4 126.1 166.7 12.7 > > 13. YAHOO-INC.car3.London1.Level 0.0% 10 126.3 126.3 126.0 127.1 0.3 > > 14. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 > > > > Can anyone else confirm? It's like our /32 stopped propagating to some > > networks. > > > > Frank > > > > _______________________________________________ > > Outages mailing list > > Outages at outages.org > > https://puck.nether.net/mailman/listinfo/outages From efinley.lists at gmail.com Fri Jul 29 13:51:05 2011 From: efinley.lists at gmail.com (Elliot Finley) Date: Fri, 29 Jul 2011 12:51:05 -0600 Subject: DNS DoS ??? Message-ID: my DNS servers were getting slow so I blocked recursive queries for all but my own network. Then I was getting so many of these: ns2 named[5056]: client 78.159.111.190#25345: query (cache) 'isc.org/ANY/IN' denied that is was still slowing things down. I've since written a script to watch the log and throw these into the box local firewall. If I expire the entries after 24 hours then I accumulate about 10200 unique IPs. If I expire after 48 hours, then it's just over 20000 unique IPs. Is anyone else seeing this? Elliot From sfouant at shortestpathfirst.net Fri Jul 29 14:02:51 2011 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Fri, 29 Jul 2011 15:02:51 -0400 Subject: DNS DoS ??? In-Reply-To: References: Message-ID: Ping me offline, there are a few other folks who have seen this as well. The isc.org record is commonly used in reflection attacks because the size of the record is so large, so the amplification factor is greatly increased. Can you check to see if +edns=0 was set in the query? That would be a sure sign this is related to what others have seen... Sorry for the top post, I'm on my iPad. Stefan Fouant JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant Sent from my iPad On Jul 29, 2011, at 2:51 PM, Elliot Finley wrote: > my DNS servers were getting slow so I blocked recursive queries for > all but my own network. > > Then I was getting so many of these: > > ns2 named[5056]: client 78.159.111.190#25345: query (cache) > 'isc.org/ANY/IN' denied > > that is was still slowing things down. I've since written a script to > watch the log and throw these into the box local firewall. If I > expire the entries after 24 hours then I accumulate about 10200 unique > IPs. If I expire after 48 hours, then it's just over 20000 unique > IPs. > > Is anyone else seeing this? > > Elliot > From cscora at apnic.net Fri Jul 29 14:05:00 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 30 Jul 2011 05:05:00 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201107291905.p6TJ508t019054@thyme.rand.apnic.net> 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, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 30 Jul, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 365335 Prefixes after maximum aggregation: 165793 Deaggregation factor: 2.20 Unique aggregates announced to Internet: 181250 Total ASes present in the Internet Routing Table: 38300 Prefixes per ASN: 9.54 Origin-only ASes present in the Internet Routing Table: 31802 Origin ASes announcing only one prefix: 15306 Transit ASes present in the Internet Routing Table: 5217 Transit-only ASes present in the Internet Routing Table: 138 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 34 Max AS path prepend of ASN (22394) 31 Prefixes from unregistered ASNs in the Routing Table: 1005 Unregistered ASNs in the Routing Table: 569 Number of 32-bit ASNs allocated by the RIRs: 1603 Number of 32-bit ASNs visible in the Routing Table: 1281 Prefixes from 32-bit ASNs in the Routing Table: 2966 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 118 Number of addresses announced to Internet: 2488168960 Equivalent to 148 /8s, 78 /16s and 114 /24s Percentage of available address space announced: 67.1 Percentage of allocated address space announced: 67.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 91.2 Total number of prefixes smaller than registry allocations: 152319 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 91501 Total APNIC prefixes after maximum aggregation: 30401 APNIC Deaggregation factor: 3.01 Prefixes being announced from the APNIC address blocks: 88083 Unique aggregates announced from the APNIC address blocks: 37486 APNIC Region origin ASes present in the Internet Routing Table: 4521 APNIC Prefixes per ASN: 19.48 APNIC Region origin ASes announcing only one prefix: 1253 APNIC Region transit ASes present in the Internet Routing Table: 713 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 19 Number of APNIC region 32-bit ASNs visible in the Routing Table: 66 Number of APNIC addresses announced to Internet: 622567776 Equivalent to 37 /8s, 27 /16s and 161 /24s Percentage of available APNIC address space announced: 79.0 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 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, 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: 141849 Total ARIN prefixes after maximum aggregation: 73135 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 113666 Unique aggregates announced from the ARIN address blocks: 46757 ARIN Region origin ASes present in the Internet Routing Table: 14520 ARIN Prefixes per ASN: 7.83 ARIN Region origin ASes announcing only one prefix: 5565 ARIN Region transit ASes present in the Internet Routing Table: 1537 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 34 Number of ARIN region 32-bit ASNs visible in the Routing Table: 12 Number of ARIN addresses announced to Internet: 803106176 Equivalent to 47 /8s, 222 /16s and 109 /24s Percentage of available ARIN address space announced: 63.8 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, 393216-394239 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, 173/8, 174/8, 184/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: 86823 Total RIPE prefixes after maximum aggregation: 49404 RIPE Deaggregation factor: 1.76 Prefixes being announced from the RIPE address blocks: 80166 Unique aggregates announced from the RIPE address blocks: 53029 RIPE Region origin ASes present in the Internet Routing Table: 15823 RIPE Prefixes per ASN: 5.07 RIPE Region origin ASes announcing only one prefix: 7899 RIPE Region transit ASes present in the Internet Routing Table: 2509 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 924 Number of RIPE addresses announced to Internet: 484366720 Equivalent to 28 /8s, 222 /16s and 217 /24s Percentage of available RIPE address space announced: 78.0 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 196608-198655 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, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 33819 Total LACNIC prefixes after maximum aggregation: 7619 LACNIC Deaggregation factor: 4.44 Prefixes being announced from the LACNIC address blocks: 33043 Unique aggregates announced from the LACNIC address blocks: 17222 LACNIC Region origin ASes present in the Internet Routing Table: 1492 LACNIC Prefixes per ASN: 22.15 LACNIC Region origin ASes announcing only one prefix: 440 LACNIC Region transit ASes present in the Internet Routing Table: 275 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 19 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 275 Number of LACNIC addresses announced to Internet: 87208704 Equivalent to 5 /8s, 50 /16s and 179 /24s Percentage of available LACNIC address space announced: 57.8 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 8186 Total AfriNIC prefixes after maximum aggregation: 1976 AfriNIC Deaggregation factor: 4.14 Prefixes being announced from the AfriNIC address blocks: 6472 Unique aggregates announced from the AfriNIC address blocks: 2027 AfriNIC Region origin ASes present in the Internet Routing Table: 476 AfriNIC Prefixes per ASN: 13.60 AfriNIC Region origin ASes announcing only one prefix: 149 AfriNIC Region transit ASes present in the Internet Routing Table: 106 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 4 Number of AfriNIC addresses announced to Internet: 26891520 Equivalent to 1 /8s, 154 /16s and 85 /24s Percentage of available AfriNIC address space announced: 40.1 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2478 11045 945 Korea Telecom (KIX) 17974 1747 516 31 PT TELEKOMUNIKASI INDONESIA 7545 1558 301 85 TPG Internet Pty Ltd 4755 1513 635 172 TATA Communications formerly 7552 1314 1064 7 Vietel Corporation 24560 1194 336 187 Bharti Airtel Ltd., Telemedia 9829 1115 929 42 BSNL National Internet Backbo 9583 1061 78 499 Sify Limited 4808 1052 2093 299 CNCGROUP IP network: China169 17488 977 189 114 Hathway IP Over Cable Interne 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 6389 3620 3818 237 bellsouth.net, inc. 18566 1913 365 241 Covad Communications 1785 1812 681 121 PaeTec Communications, Inc. 4323 1615 1082 401 Time Warner Telecom 7029 1604 993 229 Windstream Communications Inc 20115 1591 1538 623 Charter Communications 19262 1413 4792 392 Verizon Global Networks 22773 1406 2900 90 Cox Communications, Inc. 7018 1362 7068 890 AT&T WorldNet Services 2386 1257 520 906 AT&T Data Communications Serv 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 34984 534 106 185 BILISIM TELEKOM 6830 512 1788 316 UPC Distribution Services 3292 468 2078 403 TDC Tele Danmark 20940 466 133 358 Akamai Technologies European 12479 456 593 7 Uni2 Autonomous System 8866 454 133 26 Bulgarian Telecommunication C 29049 431 31 49 AzerSat LLC. 3320 425 8151 371 Deutsche Telekom AG 8551 404 354 44 Bezeq International 3301 397 1855 346 TeliaNet Sweden 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 1565 288 167 TVCABLE BOGOTA 8151 1421 2748 352 UniNet S.A. de C.V. 28573 1283 996 67 NET Servicos de Comunicao S.A 7303 1065 577 175 Telecom Argentina Stet-France 6503 749 450 68 AVANTEL, S.A. 14420 701 56 82 CORPORACION NACIONAL DE TELEC 22047 578 322 17 VTR PUNTO NET S.A. 3816 532 232 97 Empresa Nacional de Telecomun 7738 516 986 31 Telecomunicacoes da Bahia S.A 27947 510 53 54 Telconet S.A 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 799 147 36 LINKdotNET AS number 8452 794 445 11 TEDATA 15475 510 74 8 Nile Online 3741 265 937 226 The Internet Solution 6713 260 519 14 Itissalat Al-MAGHRIB 36992 259 415 15 Etisalat MISR 33776 227 13 6 Starcomms Nigeria Limited 24835 177 78 10 RAYA Telecom - Egypt 29571 158 17 11 Ci Telecom Autonomous system 16637 146 665 84 MTN Network Solutions 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 6389 3620 3818 237 bellsouth.net, inc. 23456 2966 713 1585 32-bit ASN transition 4766 2478 11045 945 Korea Telecom (KIX) 18566 1913 365 241 Covad Communications 1785 1812 681 121 PaeTec Communications, Inc. 17974 1747 516 31 PT TELEKOMUNIKASI INDONESIA 4323 1615 1082 401 Time Warner Telecom 7029 1604 993 229 Windstream Communications Inc 20115 1591 1538 623 Charter Communications 10620 1565 288 167 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 17974 1747 1716 PT TELEKOMUNIKASI INDONESIA 1785 1812 1691 PaeTec Communications, Inc. 18566 1913 1672 Covad Communications 4766 2478 1533 Korea Telecom (KIX) 7545 1558 1473 TPG Internet Pty Ltd 10620 1565 1398 TVCABLE BOGOTA 23456 2966 1381 32-bit ASN transition 7029 1604 1375 Windstream Communications Inc 4755 1513 1341 TATA Communications formerly 22773 1406 1316 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.225.128.0/18 36377 Comcast Telecommunications, I 24.225.192.0/23 36377 Comcast Telecommunications, I 24.225.192.0/18 36377 Comcast Telecommunications, I 24.225.224.0/21 36377 Comcast Telecommunications, I 24.225.237.0/24 36377 Comcast Telecommunications, I 24.225.248.0/21 36377 Comcast Telecommunications, I 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 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:20 /9:12 /10:27 /11:80 /12:233 /13:465 /14:799 /15:1407 /16:12045 /17:5889 /18:9805 /19:19535 /20:26307 /21:26309 /22:35049 /23:33972 /24:190038 /25:1098 /26:1287 /27:738 /28:203 /29:9 /30:2 /31:0 /32:6 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2243 3620 bellsouth.net, inc. 18566 1869 1913 Covad Communications 23456 1463 2966 32-bit ASN transition 10620 1460 1565 TVCABLE BOGOTA 7029 1303 1604 Windstream Communications Inc 11492 1096 1142 Cable One 7011 1056 1158 Citizens Utilities 1785 1053 1812 PaeTec Communications, Inc. 6478 968 996 AT&T Worldnet Services 22773 905 1406 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:340 2:46 4:16 5:1 6:3 8:339 12:1957 13:1 14:498 15:15 16:3 17:5 20:10 23:18 24:1678 27:861 31:508 32:64 33:4 34:2 36:4 38:729 40:104 41:2560 42:36 44:3 46:1051 47:3 49:201 50:376 52:13 54:2 55:6 56:2 57:34 58:870 59:487 60:378 61:1178 62:1045 63:1938 64:3987 65:2295 66:3905 67:1887 68:1113 69:3057 70:779 71:373 72:1864 74:2436 75:328 76:341 77:864 78:706 79:468 80:1119 81:839 82:502 83:466 84:689 85:1064 86:517 87:763 88:333 89:1533 90:224 91:3980 92:528 93:1056 94:1334 95:864 96:420 97:264 98:912 99:37 101:82 103:162 106:78 107:26 108:73 109:1029 110:605 111:715 112:305 113:407 114:554 115:685 116:987 117:682 118:856 119:1176 120:314 121:678 122:1608 123:976 124:1312 125:1328 128:245 129:169 130:169 131:579 132:113 133:21 134:214 135:52 136:215 137:132 138:296 139:115 140:477 141:255 142:403 143:421 144:486 145:56 146:454 147:216 148:673 149:248 150:160 151:189 152:341 153:182 154:5 155:399 156:199 157:353 158:140 159:454 160:315 161:205 162:310 163:166 164:507 165:369 166:531 167:432 168:746 169:153 170:836 171:81 172:1 173:1617 174:610 175:390 176:147 177:184 178:994 180:911 181:26 182:513 183:234 184:342 185:1 186:1310 187:765 188:894 189:967 190:5031 192:5916 193:4980 194:3507 195:3061 196:1199 197:46 198:3582 199:3993 200:5508 201:1479 202:8397 203:8455 204:4240 205:2317 206:2663 207:2800 208:3992 209:3410 210:2679 211:1454 212:2089 213:1782 214:792 215:69 216:4900 217:1632 218:548 219:342 220:1226 221:494 222:358 223:235 End of report From straterra at fuhell.com Fri Jul 29 15:25:42 2011 From: straterra at fuhell.com (Thomas York) Date: Fri, 29 Jul 2011 16:25:42 -0400 Subject: DNS DoS ??? In-Reply-To: References: Message-ID: <4E331746.5080708@fuhell.com> I see this all the time on my personal servers. I finally just told bind to stop logging it. On 07/29/2011 02:51 PM, Elliot Finley wrote: > my DNS servers were getting slow so I blocked recursive queries for > all but my own network. > > Then I was getting so many of these: > > ns2 named[5056]: client 78.159.111.190#25345: query (cache) > 'isc.org/ANY/IN' denied > > that is was still slowing things down. I've since written a script to > watch the log and throw these into the box local firewall. If I > expire the entries after 24 hours then I accumulate about 10200 unique > IPs. If I expire after 48 hours, then it's just over 20000 unique > IPs. > > Is anyone else seeing this? > > Elliot > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6022 bytes Desc: S/MIME Cryptographic Signature URL: From drew.weaver at thenap.com Fri Jul 29 16:00:31 2011 From: drew.weaver at thenap.com (Drew Weaver) Date: Fri, 29 Jul 2011 17:00:31 -0400 Subject: DNS DoS ??? In-Reply-To: References: Message-ID: We've been seeing this for several years on and off. thanks, -Drew -----Original Message----- From: Elliot Finley [mailto:efinley.lists at gmail.com] Sent: Friday, July 29, 2011 2:51 PM To: nanog at nanog.org Subject: DNS DoS ??? my DNS servers were getting slow so I blocked recursive queries for all but my own network. Then I was getting so many of these: ns2 named[5056]: client 78.159.111.190#25345: query (cache) 'isc.org/ANY/IN' denied that is was still slowing things down. I've since written a script to watch the log and throw these into the box local firewall. If I expire the entries after 24 hours then I accumulate about 10200 unique IPs. If I expire after 48 hours, then it's just over 20000 unique IPs. Is anyone else seeing this? Elliot From blake at pfankuch.me Fri Jul 29 16:33:27 2011 From: blake at pfankuch.me (Blake T. Pfankuch) Date: Fri, 29 Jul 2011 21:33:27 +0000 Subject: DNS DoS ??? In-Reply-To: References: Message-ID: I've seen this for the same on about 3 sets of nameservers I operate. fail2ban doing a 72 hour iptables drop rule. -----Original Message----- From: Drew Weaver [mailto:drew.weaver at thenap.com] Sent: Friday, July 29, 2011 3:01 PM To: 'Elliot Finley'; nanog at nanog.org Subject: RE: DNS DoS ??? We've been seeing this for several years on and off. thanks, -Drew -----Original Message----- From: Elliot Finley [mailto:efinley.lists at gmail.com] Sent: Friday, July 29, 2011 2:51 PM To: nanog at nanog.org Subject: DNS DoS ??? my DNS servers were getting slow so I blocked recursive queries for all but my own network. Then I was getting so many of these: ns2 named[5056]: client 78.159.111.190#25345: query (cache) 'isc.org/ANY/IN' denied that is was still slowing things down. I've since written a script to watch the log and throw these into the box local firewall. If I expire the entries after 24 hours then I accumulate about 10200 unique IPs. If I expire after 48 hours, then it's just over 20000 unique IPs. Is anyone else seeing this? Elliot From matthew at sorbs.net Fri Jul 29 16:52:50 2011 From: matthew at sorbs.net (Michelle Sullivan) Date: Fri, 29 Jul 2011 23:52:50 +0200 Subject: [BULK] Re: SORBS contact In-Reply-To: References: <1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office> <12207.1311921969@turing-police.cc.vt.edu> Message-ID: <4E332BB2.6040006@sorbs.net> William Herrin wrote: > On Fri, Jul 29, 2011 at 2:46 AM, wrote: > >> And you might want to fix it, since your users will never get a bounce notice >> from any RFC-compliant mailer - even if they *wanted* to know that their mail >> wasn't delivered. <> is the RFC-standard way to denote "this mail is a bounce >> report or other programmatically generated mail, and if it bounces itself, do *not* >> generate another bounce, as that may start a bounce loop". >> > > Correction: It's a standard way to denote that "this mail is a bounce > report." Umm no... As has been pointed out by others, but in another section (maybe another RFC) it says that the null return path should be used when a return message is not required, not desired, or it is from an automated system or you wish to avoid mail loops (with particular reference to bounce messages and mailing lists.) The registration email has a null return path because people will put in forged addresses and we don't want them to do that in the first place, and if they do it, we certainly don't want any auto-responder from replying or it going to a mailing list (most mailing list software prevent delivery of null return path mail to the list members) - seems the like most responsible and desired setup.. which is why I chose it. Note (to answer another mail in this thread): MAIL FROM:<> and 'From: ' in the headers to be completely within standards (previously it used in the headers as well which is a violation of an RFC - I forget which one.) Michelle PS: Baracuda are not the only ones, Ironport has an option for it as well - but I believe the default in Ironport is 'Off' for bounce control. -- Vulnerabilities are weaknesses associated with an organisations assets that maybe exploited by a threat causing unwanted incidents. http://www.mhix.org/ From matthew at sorbs.net Fri Jul 29 16:55:38 2011 From: matthew at sorbs.net (Michelle Sullivan) Date: Fri, 29 Jul 2011 23:55:38 +0200 Subject: SORBS contact In-Reply-To: <20110728145025.3d04c46b@petrie> References: <2D0AF14BA6FB334988BC1F5D4FC38CB802D62E86EE@EXCHMBX.hq.nac.net> <7ca7f45c-55da-4ce3-b0f6-db3ce3108b48@brw-abs-office> <20110728145025.3d04c46b@petrie> Message-ID: <4E332C5A.1050703@sorbs.net> William Pitcock wrote: > On Thu, 28 Jul 2011 12:31:13 -0700 (PDT) > "Brian R. Watters" wrote: > > >> We are looking for a SORBS contact as their web site and registration >> process is less than friendly if somehow you get listed by them. >> > > As I recall it, you can manually create an account on their > request-tracker instance and open a ticket through that requesting > delisting... however, complaining on NANOG is probably just going to > result in a less than friendly response from Michelle (at least as > history as shown). > You have to have an account first. However you can create a ticket via Email if you use one of the input addresses for a queue (eg: support at support.sorbs.net). Friendly or non friendly response is usually gaugable in advance by the tone of the initial email. Regards, Michelle -- Vulnerabilities are weaknesses associated with an organisations assets that maybe exploited by a threat causing unwanted incidents. http://www.mhix.org/ From cidr-report at potaroo.net Fri Jul 29 17:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 29 Jul 2011 22:00:00 GMT Subject: BGP Update Report Message-ID: <201107292200.p6TM00q9020943@wattle.apnic.net> BGP Update Report Interval: 21-Jul-11 -to- 28-Jul-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 29068 1.7% 34.0 -- BSNL-NIB National Internet Backbone 2 - AS45899 28167 1.7% 156.5 -- VNPT-AS-VN VNPT Corp 3 - AS17974 26413 1.6% 16.1 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 4 - AS7552 24846 1.5% 18.5 -- VIETEL-AS-AP Vietel Corporation 5 - AS9498 20734 1.2% 24.8 -- BBIL-AP BHARTI Airtel Ltd. 6 - AS665 18358 1.1% 98.2 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center 7 - AS24560 16965 1.0% 14.1 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 8 - AS45595 13714 0.8% 38.5 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited 9 - AS27738 12963 0.8% 37.9 -- Ecuadortelecom S.A. 10 - AS36992 11215 0.7% 13.4 -- ETISALAT-MISR 11 - AS15475 11186 0.7% 21.8 -- NOL 12 - AS38040 10913 0.7% 992.1 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 13 - AS24863 10857 0.6% 15.3 -- LINKdotNET-AS 14 - AS2697 10141 0.6% 53.4 -- ERX-ERNET-AS Education and Research Network 15 - AS8151 9442 0.6% 7.5 -- Uninet S.A. de C.V. 16 - AS33475 9021 0.5% 63.1 -- RSN-1 - RockSolid Network, Inc. 17 - AS44609 8880 0.5% 2960.0 -- FNA Fars News Agency Cultural Arts Institute 18 - AS4755 8765 0.5% 15.0 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 19 - AS25019 8632 0.5% 43.2 -- SAUDINETSTC-AS Autonomus System Number for SaudiNet 20 - AS6316 7915 0.5% 282.7 -- AS-PAETEC-NET - PaeTec Communications, Inc. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS44609 8880 0.5% 2960.0 -- FNA Fars News Agency Cultural Arts Institute 2 - AS44145 2298 0.1% 2298.0 -- PRINTDESIGN-AS Print and Design LTD 3 - AS3454 7524 0.5% 1881.0 -- Universidad Autonoma de Nuevo Leon 4 - AS3265 6128 0.4% 1225.6 -- XS4ALL-NL XS4ALL 5 - AS5417 6123 0.4% 1224.6 -- DEMON-NL Demon Netherlands, TDINL BV 6 - AS17408 3456 0.2% 1152.0 -- ABOVE-AS-AP AboveNet Communications Taiwan 7 - AS38040 10913 0.7% 992.1 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 8 - AS3 979 0.1% 735.0 -- AVYS AVYS Telecom S.L. 9 - AS32528 5731 0.3% 818.7 -- ABBOTT Abbot Labs 10 - AS22793 788 0.1% 788.0 -- CASSOCORP - CASSO Corporation 11 - AS32323 630 0.0% 630.0 -- EQUINIX-EDMA-CHI-ASN - Equinix, Inc. 12 - AS27048 483 0.0% 483.0 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center 13 - AS1234 481 0.0% 481.0 -- FORTUM-AS Fortum 14 - AS26485 1401 0.1% 467.0 -- SIXCONTINENTS - Six Continents Hotels, Inc. 15 - AS27322 450 0.0% 450.0 -- ISC-JNB1 Internet Systems Consortium, Inc. 16 - AS25764 5228 0.3% 435.7 -- IFIBER-COMMUNICATIONS - iFiber Communications Corp. 17 - AS49987 425 0.0% 425.0 -- SPARK-AS Stroy Park - R Ltd 18 - AS14358 2853 0.2% 407.6 -- MACKENZIEFINANCIAL-AS - Mackenzie Financial Corp 19 - AS48672 387 0.0% 387.0 -- OKCIBANK-AS OKCI BANK, PJSC 20 - AS24534 1520 0.1% 380.0 -- TRANSHYBRID-AS-ID PT. Transhybrid Communication TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.92.235.0/24 11361 0.6% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 2 - 178.22.72.0/21 8709 0.5% AS44609 -- FNA Fars News Agency Cultural Arts Institute 3 - 200.23.202.0/24 7498 0.4% AS3454 -- Universidad Autonoma de Nuevo Leon 4 - 66.248.104.0/21 6983 0.4% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 5 - 202.54.86.0/24 4952 0.3% AS4755 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 6 - 180.180.248.0/24 4695 0.3% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 7 - 180.180.255.0/24 4048 0.2% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 8 - 202.153.174.0/24 3448 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 9 - 130.36.34.0/24 2859 0.2% AS32528 -- ABBOTT Abbot Labs 10 - 130.36.35.0/24 2857 0.2% AS32528 -- ABBOTT Abbot Labs 11 - 202.41.70.0/24 2660 0.1% AS2697 -- ERX-ERNET-AS Education and Research Network 12 - 194.159.72.0/23 2463 0.1% AS3265 -- XS4ALL-NL XS4ALL AS5417 -- DEMON-NL Demon Netherlands, TDINL BV 13 - 194.159.224.0/21 2449 0.1% AS3265 -- XS4ALL-NL XS4ALL AS5417 -- DEMON-NL Demon Netherlands, TDINL BV 14 - 194.217.220.0/23 2449 0.1% AS3265 -- XS4ALL-NL XS4ALL AS5417 -- DEMON-NL Demon Netherlands, TDINL BV 15 - 195.173.224.0/19 2445 0.1% AS3265 -- XS4ALL-NL XS4ALL AS5417 -- DEMON-NL Demon Netherlands, TDINL BV 16 - 195.11.224.0/19 2445 0.1% AS3265 -- XS4ALL-NL XS4ALL AS5417 -- DEMON-NL Demon Netherlands, TDINL BV 17 - 91.201.40.0/22 2298 0.1% AS44145 -- PRINTDESIGN-AS Print and Design LTD 18 - 201.234.181.0/24 2192 0.1% AS27817 -- Red Nacional Acad?mica de Tecnolog?a Avanzada - RENATA 19 - 67.214.72.0/22 1831 0.1% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 20 - 67.214.68.0/23 1704 0.1% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jul 29 17:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 29 Jul 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201107292200.p6TM00Rr020934@wattle.apnic.net> This report has been generated at Fri Jul 29 21:12:25 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 22-07-11 367495 217204 23-07-11 368108 214781 24-07-11 367000 216092 25-07-11 367413 216483 26-07-11 368060 216505 27-07-11 368266 217156 28-07-11 368504 217248 29-07-11 368779 217261 AS Summary 38413 Number of ASes in routing system 16198 Number of ASes announcing only one prefix 3619 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 109809888 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 29Jul11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 368797 217355 151442 41.1% All ASes AS6389 3619 241 3378 93.3% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4766 2482 964 1518 61.2% KIXS-AS-KR Korea Telecom AS18566 1913 497 1416 74.0% COVAD - Covad Communications Co. AS22773 1406 99 1307 93.0% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1510 215 1295 85.8% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS4323 1616 403 1213 75.1% TWTC - tw telecom holdings, inc. AS1785 1815 765 1050 57.9% AS-PAETEC-NET - PaeTec Communications, Inc. AS19262 1413 392 1021 72.3% VZGNI-TRANSIT - Verizon Online LLC AS7552 1361 373 988 72.6% VIETEL-AS-AP Vietel Corporation AS10620 1565 627 938 59.9% Telmex Colombia S.A. AS28573 1283 387 896 69.8% NET Servicos de Comunicao S.A. AS7545 1558 712 846 54.3% TPG-INTERNET-AP TPG Internet Pty Ltd AS18101 934 145 789 84.5% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS24560 1194 424 770 64.5% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7303 1064 309 755 71.0% Telecom Argentina S.A. AS8151 1432 685 747 52.2% Uninet S.A. de C.V. AS4808 1055 334 721 68.3% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS3356 1118 458 660 59.0% LEVEL3 Level 3 Communications AS17488 977 330 647 66.2% HATHWAY-NET-AP Hathway IP Over Cable Internet AS14420 701 86 615 87.7% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS20115 1591 981 610 38.3% CHARTER-NET-HKY-NC - Charter Communications AS22561 966 364 602 62.3% DIGITAL-TELEPORT - Digital Teleport Inc. AS17974 1744 1148 596 34.2% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS17676 666 71 595 89.3% GIGAINFRA Softbank BB Corp. AS3549 996 425 571 57.3% GBLX Global Crossing Ltd. AS4804 642 86 556 86.6% MPX-AS Microplex PTY LTD AS22047 578 32 546 94.5% VTR BANDA ANCHA S.A. AS7011 1159 624 535 46.2% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS15475 510 8 502 98.4% NOL AS9443 569 77 492 86.5% INTERNETPRIMUS-AS-AP Primus Telecommunications Total 39437 12262 27175 68.9% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 93.180.88.0/21 AS42410 PTP-AS Point To Point Ltd. AS 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 116.193.152.0/24 AS55536 MIHK-HK Pacswitch Globe Telecom 116.193.153.0/24 AS55536 MIHK-HK Pacswitch Globe Telecom 116.193.154.0/24 AS55536 MIHK-HK Pacswitch Globe Telecom 116.193.155.0/24 AS55536 MIHK-HK Pacswitch Globe Telecom 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 181.82.15.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.16.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.17.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 181.82.18.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 191.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 193.111.87.0/24 AS24812 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.24.76.0/24 AS7195 Telecorp Colombia S.A. 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.58.101.0/24 AS45645 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.63.80.0/24 AS9557 PKTELECOM-AS-PK Paknet Limited Merged into PTCL 202.74.232.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.74.233.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.160.152.0/22 AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.18.156.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.72.192.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.194.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From nick at foobar.org Fri Jul 29 17:24:30 2011 From: nick at foobar.org (Nick Hilliard) Date: Fri, 29 Jul 2011 23:24:30 +0100 Subject: SORBS contact In-Reply-To: <4E332C5A.1050703@sorbs.net> References: <2D0AF14BA6FB334988BC1F5D4FC38CB802D62E86EE@EXCHMBX.hq.nac.net> <7ca7f45c-55da-4ce3-b0f6-db3ce3108b48@brw-abs-office> <20110728145025.3d04c46b@petrie> <4E332C5A.1050703@sorbs.net> Message-ID: <4E33331E.1040300@foobar.org> On 29/07/2011 22:55, Michelle Sullivan wrote: > Friendly or non friendly response is usually gaugable in advance by the > tone of the initial email. Which is usually gaugeable in advance by the tone of the customer complaints that precipitated contact with SORBS in the first place. Email is such a lousy medium for this. We're all much more decent people in person than over snarky emails. Nick From rdobbins at arbor.net Fri Jul 29 17:39:46 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 29 Jul 2011 22:39:46 +0000 Subject: DNS DoS ??? In-Reply-To: References: Message-ID: On Jul 30, 2011, at 1:51 AM, Elliot Finley wrote: > my DNS servers were getting slow so I blocked recursive queries for all but my own network. This should be the standard practice. By operating an open recursor, you lend your DNS server to abuse as a contributor to DNS reflection/amplification attacks. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From paul at paulgraydon.co.uk Fri Jul 29 17:41:12 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Fri, 29 Jul 2011 12:41:12 -1000 Subject: SORBS contact In-Reply-To: <4E33331E.1040300@foobar.org> References: <2D0AF14BA6FB334988BC1F5D4FC38CB802D62E86EE@EXCHMBX.hq.nac.net> <7ca7f45c-55da-4ce3-b0f6-db3ce3108b48@brw-abs-office> <20110728145025.3d04c46b@petrie> <4E332C5A.1050703@sorbs.net> <4E33331E.1040300@foobar.org> Message-ID: <4E333708.5080800@paulgraydon.co.uk> On 07/29/2011 12:24 PM, Nick Hilliard wrote: > On 29/07/2011 22:55, Michelle Sullivan wrote: >> Friendly or non friendly response is usually gaugable in advance by the >> tone of the initial email. > Which is usually gaugeable in advance by the tone of the customer > complaints that precipitated contact with SORBS in the first place. > > Email is such a lousy medium for this. We're all much more decent people > in person than over snarky emails. > > Nick It's pretty much customer service 101 to ensure that you keep your communications as neutral and polite as possible, regardless of how frustrated or vilified you feel by the person you're supporting, and regardless of how tired you are of accusatory tickets. Being snarky back gains little, if anything, and just helps promote a bad reputation. People forget good customer service (unless it surpasses that to brilliant), but remember bad service. From lstewart at superb.net Fri Jul 29 17:44:14 2011 From: lstewart at superb.net (Landon Stewart) Date: Fri, 29 Jul 2011 15:44:14 -0700 Subject: [BULK] Re: SORBS contact In-Reply-To: <1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office> References: <1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office> Message-ID: On 28 July 2011 14:16, Brian R. Watters wrote: > Thanks .. their attempts to reach us are blocked via our Barrcacuda's due > to the fact that they are sending with a blank FROM: and as such Barracuda > thinks its SPAM .. just to darn funny .. I have whitelisted their domain so > on my fourth attempt we will see .. Cant create tickets or communicate with > them unless you have an account and you can not get an active account unless > you can get an email to activate it .. very frustrating to say the least. > "In Soviet Russia - Network block SORBS!" - Yakov Smirnoff Ok, he didn't really say that one. Seriously though, in the past I've found their website so slow and generally parts were broken I couldn't use it. I tried to email webmaster@ and some other addresses about issues with the site but my emails were all blocked for whatever reason I can't recall. I probably spelled my own name wrong or something in my signature and it was detected and summarily blocked. Maybe its better now though, I'm not sure. We haven't had much need for it lately . -- Landon Stewart SuperbHosting.Net by Superb Internet Corp. Toll Free (US/Canada): 888-354-6128 x 4199 Direct: 206-438-5879 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net From brokenflea at gmail.com Fri Jul 29 19:37:40 2011 From: brokenflea at gmail.com (Khurram Khan) Date: Fri, 29 Jul 2011 18:37:40 -0600 Subject: Cableone Message-ID: Hello, Is there someone from cableone on this distro that can contact me off list, re: network outages , in parts of NM ? From ghira at mistral.co.uk Fri Jul 29 23:06:29 2011 From: ghira at mistral.co.uk (Adam Atkinson) Date: Sat, 30 Jul 2011 05:06:29 +0100 Subject: SORBS contact In-Reply-To: <4E33331E.1040300@foobar.org> References: <2D0AF14BA6FB334988BC1F5D4FC38CB802D62E86EE@EXCHMBX.hq.nac.net> <7ca7f45c-55da-4ce3-b0f6-db3ce3108b48@brw-abs-office> <20110728145025.3d04c46b@petrie> <4E332C5A.1050703@sorbs.net> <4E33331E.1040300@foobar.org> Message-ID: <4E338345.8010707@mistral.co.uk> Nick Hilliard wrote: > Email is such a lousy medium for this. We're all much more decent people > in person than over snarky emails. Speak for yourself! From matthew at sorbs.net Fri Jul 29 23:43:00 2011 From: matthew at sorbs.net (Michelle Sullivan) Date: Sat, 30 Jul 2011 06:43:00 +0200 Subject: [BULK] Re: SORBS contact In-Reply-To: References: <1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office> Message-ID: <4E338BD4.2060003@sorbs.net> Landon Stewart wrote: > On 28 July 2011 14:16, Brian R. Watters wrote: > > >> Thanks .. their attempts to reach us are blocked via our Barrcacuda's due >> to the fact that they are sending with a blank FROM: and as such Barracuda >> thinks its SPAM .. just to darn funny .. I have whitelisted their domain so >> on my fourth attempt we will see .. Cant create tickets or communicate with >> them unless you have an account and you can not get an active account unless >> you can get an email to activate it .. very frustrating to say the least. >> >> > > "In Soviet Russia - Network block SORBS!" - Yakov Smirnoff > > Ok, he didn't really say that one. Seriously though, in the past I've found > their website so slow and generally parts were broken I couldn't use it. I > tried to email webmaster@ and some other addresses about issues with the > site but my emails were all blocked for whatever reason I can't recall. I > probably spelled my own name wrong or something in my signature and it was > detected and summarily blocked. Maybe its better now though, I'm not sure. > We haven't had much need for it lately . > > Emailing random non-existent email addresses (such as webmaster at sorbs.net) will earn you a listing... -- Vulnerabilities are weaknesses associated with an organisations assets that maybe exploited by a threat causing unwanted incidents. http://www.mhix.org/ From enwpst47 at gmail.com Sat Jul 30 00:45:52 2011 From: enwpst47 at gmail.com (Dan Collins) Date: Sat, 30 Jul 2011 01:45:52 -0400 Subject: [BULK] Re: SORBS contact In-Reply-To: <4E338BD4.2060003@sorbs.net> References: <1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office> <4E338BD4.2060003@sorbs.net> Message-ID: On Sat, Jul 30, 2011 at 12:43 AM, Michelle Sullivan wrote: > Emailing random non-existent email addresses (such as > webmaster at sorbs.net) will earn you a listing... webmaster@* isn't "random", it's a fairly standard way to reach the administrator of a service. A failure to support that on your part does not constitute abuse on my part. --Dan From rsk at gsp.org Sat Jul 30 05:31:04 2011 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 30 Jul 2011 06:31:04 -0400 Subject: [BULK] Re: SORBS contact In-Reply-To: References: <1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office> <4E338BD4.2060003@sorbs.net> Message-ID: <20110730103104.GA1225@gsp.org> On Sat, Jul 30, 2011 at 01:45:52AM -0400, Dan Collins wrote: > On Sat, Jul 30, 2011 at 12:43 AM, Michelle Sullivan wrote: > > Emailing random non-existent email addresses (such as > > webmaster at sorbs.net) will earn you a listing... > > webmaster@* isn't "random", it's a fairly standard way to reach the > administrator of a service. Per RFC 2142 section 5, it's the standard way to reach the administrator of the HTTP service, just as "hostmaster" is the standard way to reach the administrator of the DNS service. So you're both wrong: SORBS, since it has a web site, should support the "webmaster" address; and you shouldn't send traffic there unless your enquiry is about the web site (e.g., difficulty accessing it, broken links, malformed pages). ---rsk From matthew at sorbs.net Sat Jul 30 07:38:41 2011 From: matthew at sorbs.net (Michelle Sullivan) Date: Sat, 30 Jul 2011 14:38:41 +0200 Subject: [BULK] Re: SORBS contact In-Reply-To: References: <1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office> <4E338BD4.2060003@sorbs.net> Message-ID: <4E33FB51.1080305@sorbs.net> Dan Collins wrote: > On Sat, Jul 30, 2011 at 12:43 AM, Michelle Sullivan wrote: > >> Emailing random non-existent email addresses (such as >> webmaster at sorbs.net) will earn you a listing... >> > > webmaster@* isn't "random", it's a fairly standard way to reach the > administrator of a service. A failure to support that on your part > does not constitute abuse on my part. > > --Dan > > Feel free to point out the RFC/STD/BCP that states that (yes, there is one for abuse@ and postmaster at .. last time I checked there wasn't any mention of webmaster@ - both abuse@ and postmaster@ are valid addresses that go to real people, neither will respond to any type of delisting requests.) FWIW, you get an error on the SORBS website you get the email address to reach the administrators, it is not webmaster@, it's a lot more um... appropriate. SORBS gets messages to a lot of um "Standard" email addresses (eg sales@, marketing@, legal@, www@, root@, etc) which don't exist (and several that do exist or used to, eg noc@, support@, help@).. which I do smile at as it seems people who should have more sense, just don't. Every email address published for SORBS goes to a real person either directly or via RT (ticket type tracking system) and there are quite a few published email addresses... using something that is not published is not likely to get to a person and is most likely abuse. webmaster@ has never been a valid email address at SORBS and previously when people have commented on not getting a response I have indicated that it is not and has never been a valid address (and IIRC I have mentioned that on NANOG before).... Yet people still use it... Addresses that used to exist and are not to be used any more, either re-direct to the appropriate contact or reject at the MX with an appropriate reason message. Everything else is fair game for the spam collectors. Regards, Michelle -- Vulnerabilities are weaknesses associated with an organisations assets that maybe exploited by a threat causing unwanted incidents. http://www.mhix.org/ From matthew at sorbs.net Sat Jul 30 07:57:12 2011 From: matthew at sorbs.net (Michelle Sullivan) Date: Sat, 30 Jul 2011 14:57:12 +0200 Subject: [BULK] Re: SORBS contact In-Reply-To: <20110730103104.GA1225@gsp.org> References: <1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office> <4E338BD4.2060003@sorbs.net> <20110730103104.GA1225@gsp.org> Message-ID: <4E33FFA8.7070707@sorbs.net> Rich Kulawiec wrote: > On Sat, Jul 30, 2011 at 01:45:52AM -0400, Dan Collins wrote: > >> On Sat, Jul 30, 2011 at 12:43 AM, Michelle Sullivan wrote: >> >>> Emailing random non-existent email addresses (such as >>> webmaster at sorbs.net) will earn you a listing... >>> >> webmaster@* isn't "random", it's a fairly standard way to reach the >> administrator of a service. >> > > Per RFC 2142 section 5, it's the standard way to reach the administrator > of the HTTP service, just as "hostmaster" is the standard way to reach > the administrator of the DNS service. So you're both wrong: SORBS, > since it has a web site, should support the "webmaster" address; and > you shouldn't send traffic there unless your enquiry is about the > web site (e.g., difficulty accessing it, broken links, malformed pages). > > ---rsk > > Ok I'll accept that reference..I must admit I didn't know that RFC/STD existed so I learnt something today. ;-) I would like to point out though that in section 1 it states 'are encouraged to support' not must or even should, a quick skim read later and I see there are mention of those that are required to be supported later in the document, Webmaster@ is not in the required list. As per my previous email, the webservers (all of them) report another email address which is more appropriate for our organisation, and will feed all mail to a real person or into a ticket system in a queue for bugs and errors with the SORBS service as appropriate (this does not include any reports about content of the DNSbl, there are other addresses published for that.) Thanks, Michelle -- Vulnerabilities are weaknesses associated with an organisations assets that maybe exploited by a threat causing unwanted incidents. http://www.mhix.org/ From matthew at sorbs.net Sat Jul 30 08:12:37 2011 From: matthew at sorbs.net (Michelle Sullivan) Date: Sat, 30 Jul 2011 15:12:37 +0200 Subject: SORBS contact In-Reply-To: <4E333708.5080800@paulgraydon.co.uk> References: <2D0AF14BA6FB334988BC1F5D4FC38CB802D62E86EE@EXCHMBX.hq.nac.net> <7ca7f45c-55da-4ce3-b0f6-db3ce3108b48@brw-abs-office> <20110728145025.3d04c46b@petrie> <4E332C5A.1050703@sorbs.net> <4E33331E.1040300@foobar.org> <4E333708.5080800@paulgraydon.co.uk> Message-ID: <4E340345.4030406@sorbs.net> Paul Graydon wrote: > It's pretty much customer service 101 to ensure that you keep your > communications as neutral and polite as possible, regardless of how > frustrated or vilified you feel by the person you're supporting, and > regardless of how tired you are of accusatory tickets. Being snarky > back gains little, if anything, and just helps promote a bad > reputation. People forget good customer service (unless it surpasses > that to brilliant), but remember bad service. > You will find that all responses from SORBS support staff to support requests are very helpful, polite and customer service orientated - there have been many exceptions in the past, but for sometime we have been working on it to ensure that the issues of the past are not repeated. Note: threats (legal or violence) are not answered by support staff, there is a blunt and factual templated response that goes out to any such messages. That said, emails to people directly that either do not deal with support, or are not support email addresses may not get the same polite helpful response. I think most of us have experienced that from many organisations past and present, and SORBS is certainly has been on *that* list. Regards, Michelle -- Vulnerabilities are weaknesses associated with an organisations assets that maybe exploited by a threat causing unwanted incidents. http://www.mhix.org/ From bill at herrin.us Sat Jul 30 08:46:13 2011 From: bill at herrin.us (William Herrin) Date: Sat, 30 Jul 2011 09:46:13 -0400 Subject: [BULK] Re: SORBS contact In-Reply-To: <5216.1311952950@turing-police.cc.vt.edu> References: <1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office> <12207.1311921969@turing-police.cc.vt.edu> <5216.1311952950@turing-police.cc.vt.edu> Message-ID: On Fri, Jul 29, 2011 at 11:22 AM, wrote: > On Fri, 29 Jul 2011 09:48:44 EDT, William Herrin said: >> Correction: It's a standard way to denote that "this mail is a bounce >> report." > > It's *not* just "bounce reports" (in particular, DSNs and MDNs are not > non-delivery (bounce) messages in the sense of section 3.7, and both > can be generated in response to *successful* deliveries). > generated for *successful* deliveries). Hi Vladis, Point taken. Bounce reports, temporary failure reports and successful delivery reports. Nevertheless, it still isn't for "other programmatically generated mail." In fact, the next paragraph in RFC 5321 4.5.5 says: "All other types of messages (i.e., any message which is not required by a Standards-Track RFC to have a null reverse-path) SHOULD be sent with a valid, non-null reverse-path." Contrary to your claim, it's perfectly reasonable for an spam filter in a symmetric routing scenario to discard a null return path message that isn't unambiguously responsive to one it previously sent. On Fri, Jul 29, 2011 at 5:52 PM, Michelle Sullivan wrote: > Umm no... As has been pointed out by others, but in another section > (maybe another RFC) it says that the null return path should be used > when a return message is not required, not desired, or it is from an > automated system or you wish to avoid mail loops (with particular > reference to bounce messages and mailing lists.) Michelle, Is your web site registration message required by a standards track RFC to use a null reverse path? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Valdis.Kletnieks at vt.edu Sat Jul 30 08:49:34 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 30 Jul 2011 09:49:34 -0400 Subject: [BULK] Re: SORBS contact In-Reply-To: Your message of "Fri, 29 Jul 2011 23:52:50 +0200." <4E332BB2.6040006@sorbs.net> References: <1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office> <12207.1311921969@turing-police.cc.vt.edu> <4E332BB2.6040006@sorbs.net> Message-ID: <27485.1312033774@turing-police.cc.vt.edu> On Fri, 29 Jul 2011 23:52:50 +0200, Michelle Sullivan said: > reference to bounce messages and mailing lists.) The registration email > has a null return path because people will put in forged addresses and > we don't want them to do that in the first place, and if they do it, we > certainly don't want any auto-responder from replying or it going to a > mailing list (most mailing list software prevent delivery of null return > path mail to the list members) - seems the like most responsible and > desired setup.. which is why I chose it. LSoft's Listserv product does this as well - subscription confirmation messages and some other administrivia mail are sent with MAIL FROM:<> so forged subscribe requests don't generate bounces. The upshot is that if you block <> your users will never be able to subscribe to any Listserv-hosted list. There's enough sites running Listserv that it might be a bit more impact than "I can't e-mail SORBS"... I have always been amazed at how products like the Barracuda or the PIX can ship with totally broken software, and yet get enough market share to cause so much pain for the rest of us. Some days, I wonder if there's grounds for legal action - do such broken "training wheels for net admins" products constitute an attractive nuisance? ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From ken at sizone.org Sat Jul 30 08:53:58 2011 From: ken at sizone.org (Ken Chase) Date: Sat, 30 Jul 2011 09:53:58 -0400 Subject: [BULK] Re: SORBS contact In-Reply-To: <4E33FFA8.7070707@sorbs.net> References: <1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office> <4E338BD4.2060003@sorbs.net> <20110730103104.GA1225@gsp.org> <4E33FFA8.7070707@sorbs.net> Message-ID: <20110730135358.GZ21739@sizone.org> On Sat, Jul 30, 2011 at 02:57:12PM +0200, Michelle Sullivan said: >Ok I'll accept that reference..I must admit I didn't know that RFC/STD >existed so I learnt something today. ;-) That's pretty rich. You enforce people to adopt standards that are part of proposed RFC's, not official by any standard, jump through 18 other hoops, and still won't delist them because some bit in their named replies is the wrong number of electronvolts on your wire, and then claim you dont know an RFC? p.k.b. /kc -- Ken Chase - ken at sizone.org From matt at mattreath.com Sat Jul 30 09:08:15 2011 From: matt at mattreath.com (Matthew Reath) Date: Sat, 30 Jul 2011 09:08:15 -0500 Subject: Problem with AOL through XO Message-ID: <4093781ea64207efdd69dc28513eb3c5.squirrel@mail.mattreath.com> I'm wondering if anyone else is having issues with their customers accessing AOL related sites including Engadget. We have two upstream providers, Charter and TW, both of which peer with XO. If traffic goes out Charter to AOL sites it gets blackholed in XO. If it goes out TW the sites load fine. Any thoughts? -Matt From Valdis.Kletnieks at vt.edu Sat Jul 30 09:12:09 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 30 Jul 2011 10:12:09 -0400 Subject: [BULK] Re: SORBS contact In-Reply-To: Your message of "Sat, 30 Jul 2011 09:46:13 EDT." References: <1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office> <12207.1311921969@turing-police.cc.vt.edu> <5216.1311952950@turing-police.cc.vt.edu> Message-ID: <28441.1312035129@turing-police.cc.vt.edu> On Sat, 30 Jul 2011 09:46:13 EDT, William Herrin said: > Point taken. Bounce reports, temporary failure reports and successful > delivery reports. Nevertheless, it still isn't for "other > programmatically generated mail." In fact, the next paragraph in RFC > 5321 4.5.5 says: > > "All other types of messages (i.e., any message which is not required > by a Standards-Track RFC to have a null reverse-path) SHOULD be sent > with a valid, non-null reverse-path." tl;dr: 4.5.5 says SHOULD instead of MUST for a *reason*. RFC2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. I know for a fact that the LSoft guys thought long and hard about it, and decided that "Yes, 99.998% of the mail will go out with a non-null reverse path. But the other 0.002% of administrivia and confirmation mail will best serve the network interests if they are sent with a null reverse path so they are treated similarly to bounce messages, even though they aren't an RFC-blessed bounce message". Hint: If somebody forges a subscription request from 'nosuchuser at herrin.us', do you want the resulting "Somebody has requested this email address to be added to the foobar-l list, please click or reply within 48 hours to confirm" mail to show up with a <> so you can skip generating the bounce, or do you want it to have a non-null return path so you're forced to generate a bounce that will be ignored at the other end anyhow? Does your answer change if some skript kiddie forges 10,000 requests? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From drew.weaver at thenap.com Sat Jul 30 11:33:14 2011 From: drew.weaver at thenap.com (Drew Weaver) Date: Sat, 30 Jul 2011 12:33:14 -0400 Subject: DNS DoS ??? In-Reply-To: References: Message-ID: -----Original Message----- From: Dobbins, Roland [mailto:rdobbins at arbor.net] Sent: Friday, July 29, 2011 6:40 PM To: NANOG list Subject: Re: DNS DoS ??? On Jul 30, 2011, at 1:51 AM, Elliot Finley wrote: > my DNS servers were getting slow so I blocked recursive queries for all but my own network. This should be the standard practice. By operating an open recursor, you lend your DNS server to abuse as a contributor to DNS reflection/amplification attacks. ----------------------------------------------------------------------- And at this point he may as well just ACL in-front of the recursors to prevent the traffic from hitting the servers thus reducing load needed to reject the queries on the servers themselves. -Drew From jlewis at lewis.org Sat Jul 30 13:44:26 2011 From: jlewis at lewis.org (Jon Lewis) Date: Sat, 30 Jul 2011 14:44:26 -0400 (EDT) Subject: DNS DoS ??? In-Reply-To: References: Message-ID: On Sat, 30 Jul 2011, Drew Weaver wrote: >> my DNS servers were getting slow so I blocked recursive queries for all >> but my own network. > > This should be the standard practice. By operating an open recursor, > you lend your DNS server to abuse as a contributor to DNS > reflection/amplification attacks. > > ----------------------------------------------------------------------- > > And at this point he may as well just ACL in-front of the recursors to > prevent the traffic from hitting the servers thus reducing load needed > to reject the queries on the servers themselves. An awful lot of older/smaller deployments have single servers doing both authoratative and recursive DNS. These should be setup with either an allow-recursion { ACL;} statement or separate authoratative and recursive views limiting recursion to just those networks that should be sending recursive queries. Another option is to run separate services bound to different individual IPs on the server. i.e. bind9 or powerdns for authoratative DNS and unbound for recursion. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From nderitualex at gmail.com Sat Jul 30 14:01:23 2011 From: nderitualex at gmail.com (Alex Nderitu) Date: Sat, 30 Jul 2011 22:01:23 +0300 Subject: DNS DoS ??? In-Reply-To: References: Message-ID: Dns anycast can in addition to acl help distribute load. On Jul 30, 2011 9:44 PM, "Jon Lewis" wrote: > On Sat, 30 Jul 2011, Drew Weaver wrote: > >>> my DNS servers were getting slow so I blocked recursive queries for all >>> but my own network. >> >> This should be the standard practice. By operating an open recursor, >> you lend your DNS server to abuse as a contributor to DNS >> reflection/amplification attacks. >> >> ----------------------------------------------------------------------- >> >> And at this point he may as well just ACL in-front of the recursors to >> prevent the traffic from hitting the servers thus reducing load needed >> to reject the queries on the servers themselves. > > An awful lot of older/smaller deployments have single servers doing both > authoratative and recursive DNS. These should be setup with either an > allow-recursion { ACL;} statement or separate authoratative and recursive > views limiting recursion to just those networks that should be sending > recursive queries. > > Another option is to run separate services bound to different individual > IPs on the server. i.e. bind9 or powerdns for authoratative DNS and > unbound for recursion. > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From jna at retina.net Sat Jul 30 14:04:16 2011 From: jna at retina.net (John Adams) Date: Sat, 30 Jul 2011 12:04:16 -0700 Subject: DNS DoS ??? In-Reply-To: References: Message-ID: I don't think anycast works the way you think it does. It'll distribute load for single dns servers, but not the case that he is describing. -j On Sat, Jul 30, 2011 at 12:01 PM, Alex Nderitu wrote: > Dns anycast can in addition to acl help distribute load. > On Jul 30, 2011 9:44 PM, "Jon Lewis" wrote: > > On Sat, 30 Jul 2011, Drew Weaver wrote: > > > >>> my DNS servers were getting slow so I blocked recursive queries for all > >>> but my own network. > >> > >> This should be the standard practice. By operating an open recursor, > >> you lend your DNS server to abuse as a contributor to DNS > >> reflection/amplification attacks. > >> > >> ----------------------------------------------------------------------- > >> > >> And at this point he may as well just ACL in-front of the recursors to > >> prevent the traffic from hitting the servers thus reducing load needed > >> to reject the queries on the servers themselves. > > > > An awful lot of older/smaller deployments have single servers doing both > > authoratative and recursive DNS. These should be setup with either an > > allow-recursion { ACL;} statement or separate authoratative and recursive > > views limiting recursion to just those networks that should be sending > > recursive queries. > > > > Another option is to run separate services bound to different individual > > IPs on the server. i.e. bind9 or powerdns for authoratative DNS and > > unbound for recursion. > > > > ---------------------------------------------------------------------- > > Jon Lewis, MCP :) | I route > > Senior Network Engineer | therefore you are > > Atlantic Net | > > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > > From mike at sabbota.com Sat Jul 30 14:15:32 2011 From: mike at sabbota.com (Mike Sabbota) Date: Sat, 30 Jul 2011 13:15:32 -0600 Subject: DNS DoS ??? In-Reply-To: References: Message-ID: <2380115005709115629@unknownmsgid> With these types of attacks, usually anycast will cause rolling outages. Anycast gives you failover, which makes sure the attack (and good) traffic makes it to the next available server to be impaired or taken offline. On Jul 30, 2011, at 1:01 PM, Alex Nderitu wrote: > Dns anycast can in addition to acl help distribute load. > On Jul 30, 2011 9:44 PM, "Jon Lewis" wrote: >> On Sat, 30 Jul 2011, Drew Weaver wrote: >> >>>> my DNS servers were getting slow so I blocked recursive queries for all >>>> but my own network. >>> >>> This should be the standard practice. By operating an open recursor, >>> you lend your DNS server to abuse as a contributor to DNS >>> reflection/amplification attacks. >>> >>> ----------------------------------------------------------------------- >>> >>> And at this point he may as well just ACL in-front of the recursors to >>> prevent the traffic from hitting the servers thus reducing load needed >>> to reject the queries on the servers themselves. >> >> An awful lot of older/smaller deployments have single servers doing both >> authoratative and recursive DNS. These should be setup with either an >> allow-recursion { ACL;} statement or separate authoratative and recursive >> views limiting recursion to just those networks that should be sending >> recursive queries. >> >> Another option is to run separate services bound to different individual >> IPs on the server. i.e. bind9 or powerdns for authoratative DNS and >> unbound for recursion. >> >> ---------------------------------------------------------------------- >> Jon Lewis, MCP :) | I route >> Senior Network Engineer | therefore you are >> Atlantic Net | >> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ >> From bill at herrin.us Sat Jul 30 14:18:17 2011 From: bill at herrin.us (William Herrin) Date: Sat, 30 Jul 2011 15:18:17 -0400 Subject: [BULK] Re: SORBS contact In-Reply-To: <28441.1312035129@turing-police.cc.vt.edu> References: <1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office> <12207.1311921969@turing-police.cc.vt.edu> <5216.1311952950@turing-police.cc.vt.edu> <28441.1312035129@turing-police.cc.vt.edu> Message-ID: On Sat, Jul 30, 2011 at 10:12 AM, wrote: > Hint: ?If somebody forges a subscription request from 'nosuchuser at herrin.us', > do you want the resulting "Somebody has requested this email address to be > added to the foobar-l list, please click or reply within 48 hours to confirm" > mail to show up with a <> so you can skip generating the bounce, or do you want > it to have a non-null return path so you're forced to generate a bounce that > will be ignored at the other end anyhow? ?Does your answer change if some > skript kiddie forges 10,000 requests? 1. nosuchuser at herrin.us rejects during the smtp session, so it makes no difference to my server resource consumption either way. 2. I assume the subscription request came from a web page because if it was from an email request you received then you ignored my SPF records when generating the confirmation request. That was OK in 2001 but in 2011 you ought not be doing that. 3. If you happen to hit my real email address and it isn't caught by my spam filter, then all 10,000 show up in my mailbox whether you used a null return path or not. This will annoy me and when I examine the message and notice that you engaged in fire and forget behavior so that you wouldn't be bothered by the fact that you flooded my mailbox, all bets are off. So, if you want to do me a favor (as opposed to doing yourself a favor), process the messages I bounce at you and like a responsible person, try to do something intelligent with the results. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mysidia at gmail.com Sat Jul 30 15:08:59 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 30 Jul 2011 15:08:59 -0500 Subject: DNS DoS ??? In-Reply-To: References: Message-ID: On Sat, Jul 30, 2011 at 11:33 AM, Drew Weaver wrote: > And at this point he may as well just ACL in-front of the recursors to > prevent the traffic from hitting the servers thus reducing load needed to > reject the queries on the servers themselves. > > A problem for providers of DNS recursive servers as a hosted service, is the client sender IP address may be dynamic and off-net. And the DNS protocol does not provide a method of authentication, or passing credentials from the client to the server to authorize the use of recursive DNS. This differs from SMTP. There really is no such thing as a "closed recursive resolver", except where unwanted queries are blocked by IP. All we really have is TSIG for such scenarios, and most client resolvers do not support loading the resolver with a secret key, in order to authorize recursive access. So it follows, that in a number cases, "closing recursive access" is not a good option. A good example, would be services such as OpenDNS. Regards, -- -JH From rdobbins at arbor.net Sat Jul 30 17:53:24 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sat, 30 Jul 2011 22:53:24 +0000 Subject: DNS DoS ??? In-Reply-To: References: Message-ID: <5BB5C3AA-6C94-4BDE-8326-4EA675CC5EE4@arbor.net> On Jul 31, 2011, at 3:08 AM, Jimmy Hess wrote: > A good example, would be services such as OpenDNS. One can argue a) that services like OpenDNS aren't necessarily a Good Thing when run by those who don't take the proper precautions and b) that OpenDNS in particular is run by smart, responsible folks who take extra measures to ensure they don't become a party to DNS reflection/amplification attacks, even though they operate an open recursive lookup service. ;> ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From matthew at sorbs.net Sat Jul 30 19:33:46 2011 From: matthew at sorbs.net (Michelle Sullivan) Date: Sun, 31 Jul 2011 02:33:46 +0200 Subject: [BULK] Re: SORBS contact In-Reply-To: <20110730135358.GZ21739@sizone.org> References: <1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office> <4E338BD4.2060003@sorbs.net> <20110730103104.GA1225@gsp.org> <4E33FFA8.7070707@sorbs.net> <20110730135358.GZ21739@sizone.org> Message-ID: <4E34A2EA.10306@sorbs.net> Ken Chase wrote: > On Sat, Jul 30, 2011 at 02:57:12PM +0200, Michelle Sullivan said: > > >Ok I'll accept that reference..I must admit I didn't know that RFC/STD > >existed so I learnt something today. ;-) > > That's pretty rich. > > You enforce people to adopt standards that are part of proposed RFC's, not > official by any standard, jump through 18 other hoops, and still won't > delist them because some bit in their named replies is the wrong number of > electronvolts on your wire, and then claim you dont know an RFC? > > p.k.b. > > /kc > What's the current RFC/BCP and STDs count? I'm sure you remember at least 95% of them by heart and can recite them word for word, just like me..! -- Vulnerabilities are weaknesses associated with an organisations assets that maybe exploited by a threat causing unwanted incidents. http://www.mhix.org/ From mysidia at gmail.com Sat Jul 30 19:50:59 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 30 Jul 2011 19:50:59 -0500 Subject: [BULK] Re: SORBS contact In-Reply-To: <4E33FFA8.7070707@sorbs.net> References: <1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office> <4E338BD4.2060003@sorbs.net> <20110730103104.GA1225@gsp.org> <4E33FFA8.7070707@sorbs.net> Message-ID: On Sat, Jul 30, 2011 at 7:57 AM, Michelle Sullivan wrote: > Rich Kulawiec wrote: > > On Sat, Jul 30, 2011 at 01:45:52AM -0400, Dan Collins wrote: > [snip] > later in the document, Webmaster@ is not in the required list. As per > my previous email, the webservers (all of them) report another email [snip] > I wouldn't fault SORBS for not supporting optional addresses such as webmaster at . I would fault SORBS for automatically listing someone e-mailing webmaster@ though, as implied above. Whether the actual RFC existed or not. It's probably true that all the standard addresses are likely to be subject to abuse. info@ sure is. However, they should not be listed without at least analyzing the content of the actual message. To decide if it is in fact abuse, OR if it's just a human failure, somebody attempting to contact an admin address/service that does not exist. There mere act of attempting to contact multiple standard addresses alone, is certainly not proof of abuse. -- -JH From paul at paulgraydon.co.uk Sat Jul 30 19:56:59 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Sat, 30 Jul 2011 14:56:59 -1000 Subject: [BULK] Re: SORBS contact In-Reply-To: <4E34A2EA.10306@sorbs.net> References: <1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office> <4E338BD4.2060003@sorbs.net> <20110730103104.GA1225@gsp.org> <4E33FFA8.7070707@sorbs.net> <20110730135358.GZ21739@sizone.org> <4E34A2EA.10306@sorbs.net> Message-ID: <4E34A85B.8050501@paulgraydon.co.uk> On 7/30/2011 2:33 PM, Michelle Sullivan wrote: > Ken Chase wrote: >> On Sat, Jul 30, 2011 at 02:57:12PM +0200, Michelle Sullivan said: >> >> >Ok I'll accept that reference..I must admit I didn't know that RFC/STD >> >existed so I learnt something today. ;-) >> >> That's pretty rich. >> >> You enforce people to adopt standards that are part of proposed RFC's, not >> official by any standard, jump through 18 other hoops, and still won't >> delist them because some bit in their named replies is the wrong number of >> electronvolts on your wire, and then claim you dont know an RFC? >> >> p.k.b. >> >> /kc >> > What's the current RFC/BCP and STDs count? I'm sure you remember at > least 95% of them by heart and can recite them word for word, just like > me..! > Whilst you have a reasonable point, and there are a fair number of them to keep track of, you are providing a service based around a subset of them. Would you not agree that it would be reasonable to assume that you (or your product designers) would know and understand all the standards appropriate to your product, and are ensuring your own compliance? Paul From frnkblk at iname.com Sat Jul 30 20:09:18 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 30 Jul 2011 20:09:18 -0500 Subject: DNS DoS ??? In-Reply-To: References: Message-ID: <004f01cc4f1e$79483410$6bd89c30$@iname.com> More good stuff here: http://www.team-cymru.org/Services/Resolvers/ Frank -----Original Message----- From: Dobbins, Roland [mailto:rdobbins at arbor.net] Sent: Friday, July 29, 2011 5:40 PM To: NANOG list Subject: Re: DNS DoS ??? On Jul 30, 2011, at 1:51 AM, Elliot Finley wrote: > my DNS servers were getting slow so I blocked recursive queries for all but my own network. This should be the standard practice. By operating an open recursor, you lend your DNS server to abuse as a contributor to DNS reflection/amplification attacks. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From Chris.Kleban at citrix.com Sat Jul 30 20:28:03 2011 From: Chris.Kleban at citrix.com (Chris Kleban) Date: Sun, 31 Jul 2011 01:28:03 +0000 Subject: Looking for Comcast contact Message-ID: If someone from Comcast can call me, I would appreciate it. ASN 16815 Chris Kleban 805-690-7931 From mysidia at gmail.com Sat Jul 30 21:15:38 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 30 Jul 2011 21:15:38 -0500 Subject: DNS DoS ??? In-Reply-To: <5BB5C3AA-6C94-4BDE-8326-4EA675CC5EE4@arbor.net> References: <5BB5C3AA-6C94-4BDE-8326-4EA675CC5EE4@arbor.net> Message-ID: On Sat, Jul 30, 2011 at 5:53 PM, Dobbins, Roland wrote: > On Jul 31, 2011, at 3:08 AM, Jimmy Hess wrote: > > A good example, would be services such as OpenDNS. > One can argue a) that services like OpenDNS aren't necessarily a Good Thing > when run by those who don't take the proper precautions Is there an RFC specifying precisely what are considered the proper precautions? "precautions" should ideally be enabled in BIND by default. > and b) that OpenDNS in particular is run by smart, responsible folks who > take extra measures to ensure they don't become a party to DNS > reflection/amplification attacks, even though they operate an open recursive > lookup service. > My point here is that... splitting recursive service and cordoning off recursive service by using a firewall or ACL based on IP address, is only a partially effective operational workaround to a serious defect in the protocol. Authoritative service is as subject to DoS as ever, especially with IPv6 and DNSSEC deployments. It doesn't fall under "best common practices"; it falls under "necessary evils", that everyone pretty much has to do. Right now we have to say "separate and restrict access to your recursive service", because it is the only option we can implement without changes to the protocol, and for now it should be done wherever possible. But this is not pallatable at all. The DNS protocol should be fixed so we don't need this workaround. Standardization effort should concentrate on changing the protocol. Restricting recursive service is a good short term solution, but it is not for every case. The workaround is not a best practice, it is evidence that the DNS protocol should be changed. How can it be changed? Add a proof-of-work for every DNS query and an additional round-trip for the first recursion-desired DNS query a client makes to any restricted DNS server, to obtain some "client token" or other unique hash to be sent along with queries. -- -JH From matthew at sorbs.net Sat Jul 30 22:20:34 2011 From: matthew at sorbs.net (Michelle Sullivan) Date: Sun, 31 Jul 2011 05:20:34 +0200 Subject: [BULK] Re: SORBS contact In-Reply-To: References: <1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office> <4E338BD4.2060003@sorbs.net> <20110730103104.GA1225@gsp.org> <4E33FFA8.7070707@sorbs.net> Message-ID: <4E34CA02.9080800@sorbs.net> Jimmy Hess wrote: > On Sat, Jul 30, 2011 at 7:57 AM, Michelle Sullivan > wrote: > > Rich Kulawiec wrote: > > On Sat, Jul 30, 2011 at 01:45:52AM -0400, Dan Collins wrote: > [snip] > > later in the document, Webmaster@ is not in the required list. > As per > my previous email, the webservers (all of them) report another email > > [snip] > > > I wouldn't fault SORBS for not supporting optional addresses such as > webmaster at . > I would fault SORBS for automatically listing someone e-mailing > webmaster@ though, > as implied above. Whether the actual RFC existed or not. > > It's probably true that all the standard addresses are likely to be > subject to abuse. info@ sure is. > > However, they should not be listed without at least analyzing the > content of the actual message. > To decide if it is in fact abuse, OR if it's just a human failure, > somebody attempting to contact > an admin address/service that does not exist. > > There mere act of attempting to contact multiple standard addresses > alone, is certainly > not proof of abuse. A valid and well put argument. I don't know what we do with stuff to webmaster@ however I do know that it is possible that messages to it will go into the spamtrap system. (the spamtrap system has multiple entry points, and a mail going in does not guarentee a listing, but it is likely, especially if the message is repeated to multiple addresses and therefore is 'bulk'.) Michelle -- Vulnerabilities are weaknesses associated with an organisations assets that maybe exploited by a threat causing unwanted incidents. http://www.mhix.org/ From nathan at atlasnetworks.us Sat Jul 30 23:16:23 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Sun, 31 Jul 2011 04:16:23 +0000 Subject: [BULK] Re: SORBS contact In-Reply-To: <4E34CA02.9080800@sorbs.net> References: <1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office> <4E338BD4.2060003@sorbs.net> <20110730103104.GA1225@gsp.org> <4E33FFA8.7070707@sorbs.net> <4E34CA02.9080800@sorbs.net> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B50C3D5@ex-mb-1.corp.atlasnetworks.us> > A valid and well put argument. I don't know what we do with stuff to > webmaster@ however I do know that it is possible that messages to it > will go into the spamtrap system. (the spamtrap system has multiple > entry points, and a mail going in does not guarentee a listing, but it > is likely, especially if the message is repeated to multiple addresses > and therefore is 'bulk'.) Respectfully, I'm unconvinced that fewer than 10 recipients (sending to webmaster and cc'ing netops) constitutes sending in 'bulk'. For instance, USPS requires 200 recipients for standard mail to classify such mail as 'bulk'[1]. That number seems quite high to me, but then again, 2-10 seems quite low. In the past, I've had a heck of a time getting blocks delisted from SORBs - even getting a PI assignment removed from the DUHL, which isn't even a list of abusive blocks, was tough. Again respectfully, if so many operations people have a problem with the way SORBS operates, doesn't that represent a valid concern? Operators constitute the bulk of your users, and they are, by and large, frustrated. The fact that they are trying to reach out via other methods should tell you something - and it isn't that the operators are doing it wrong (and should therefore be punished). Writing as a human, not as my employer, Nathan Eisenberg [1] - http://pe.usps.com/businessmail101/getstarted/bulkmail.htm From rdobbins at arbor.net Sun Jul 31 01:48:41 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 31 Jul 2011 06:48:41 +0000 Subject: DNS DoS ??? In-Reply-To: References: <5BB5C3AA-6C94-4BDE-8326-4EA675CC5EE4@arbor.net> Message-ID: <09D7A1D0-0B13-4570-8891-835CA6568AD7@arbor.net> On Jul 31, 2011, at 9:15 AM, "Jimmy Hess" wrote: > Is there an RFC specifying precisely what are considered the proper precautions? > "precautions" should ideally be enabled in BIND by default. Not of which I'm aware. I'm happy to contribute to any efforts you or anyone else are volunteering to coordinate on this topic, as it's important work which ought to be done sooner & not later. ;> > My point here is that... splitting recursive service and cordoning off recursive service by > using a firewall Using a stateful firewall is contraindicated. > or ACL based on IP address, is only a partially effective operational workaround to a serious defect in the protocol. It's actually a combination of serious defects in a number of protocols, starting with IPv4 itself. IPv4 went into service ~27 years ago as testbed protocol. The first formal security assessment of the IPv4 core protocols was completed last month. IPv6 inherits all the security problems inherent in IPv4, & introduces new ones - the ND mess & the untold billions of dollars in opex costs that the consonance of the letters 'B', 'C', 'D', & 'E' will entail are just two glaring examples. So, if we're looking for protocol architecture dragons to slay, there're far more basic issues in need of a strong sword-arm before we even get to outliers like the DNS, heh. > Authoritative service is as subject to DoS as ever, especially with IPv6 and DNSSEC > deployments. And there are deployment & operational BCPs which can mitigate DDoS of authoritative DNS services, from logical separation of functions (see for an example) to S/RTBH to flowspec to commercial IDMS solutions. [Full disclosure: my employer is a vendor of such solutions.] > The DNS protocol should be fixed so we don't need this workaround. By all means. In the meantime, it's important to realize that many of the resource constraints which were extant at the time the DNS was designed no longer hold sway. DNS reflection/amplification attacks can be eliminated by the simple (and, nowadays, practical, IMHO) expedient of re-configuring resolver-facing DNS servers to force the use TCP by default. The best part is that DNS operators can start doing this today, without recourse to standards bodies, working groups, et. al. No need for any inter-organizational coordination at all - each can move at his own pace, within his own span of administrative control. As an aside, it should be noted that switching the DNS over to TCP by default would accomplish a great deal of what DNSSEC is intended to provide, with far less in the way of architectural, operational, & administrative complexity. Most folks who still misguidedly filter TCP/53 are unlikely to support EDNS0, either, so they're already hurting - a widespread switch to TCP would likely finally force them out of their jungle fastnesses and out blinking into the sunlight. ;> > Standardization effort should concentrate on changing the protocol. It's important to keep in mind how long the last substantive changes to the DNS have required, as opposed to the near-term expedient of implementing BCPs & switching to TCP. > Restricting recursive service is a good short term solution, but it is not for every case. Concur 100%. Meanwhile, we continue to resolve with the DNS we have until the new, improved version is designed, tested, & generally deployed. ;> > The workaround is not a best practice, it is evidence that the DNS protocol should be changed. There's a reason proof-of-work solutions have never been widely deployed - in the final analysis, they all too often end up simply a form of cost-shifting which leaves the system in question just as vulnerable (if not more so) to DoS as it was in the first place, just within a different transaction path/layer. So, while I agree with you that changes are called for, implementing proofs-of-work into the DNS transactional model isn't one I'd personally recommend, FWIW. --------------------------------------------------------------------- Roland Dobbins // Sell your computer and buy a guitar. From igor at ergens.org Sun Jul 31 03:04:04 2011 From: igor at ergens.org (Igor Ybema) Date: Sun, 31 Jul 2011 10:04:04 +0200 Subject: someone from verisign? website down over ipv6 Message-ID: Dear someone from Verisign, It looks from over here (and some other hosts I checked) that http://www.verisigninc.com/ is dead when using a host having iPv6 dual-stack. Some packets do come over, so the browser is not failing over into IPv4. Also the whois server for whois.nic.name is not working for IPv6 dual-stack hosts. The IPv6 part of the whois server claims that he is dead and so again failover to IPv4 is not going to happen. Contact me off-list if necessary. regards, Igor Ybema From igor at ergens.org Sun Jul 31 03:59:50 2011 From: igor at ergens.org (Igor Ybema) Date: Sun, 31 Jul 2011 10:59:50 +0200 Subject: someone from verisign? website down over ipv6 In-Reply-To: References: Message-ID: Hi, extra info: Site problem looks path mtu related. On tunneled hosts the site does not work. On native hosts it does. Looks like something is blocking icmpv6 path mtu requests. My tunnels are ok, so must be in the verisign network, my guess a misconfigured firewall. Whois server problem is also on native ipv6 hosts so this is not mtu related. regards, Igor From Valdis.Kletnieks at vt.edu Sun Jul 31 13:32:05 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 31 Jul 2011 14:32:05 -0400 Subject: [BULK] Re: SORBS contact In-Reply-To: Your message of "Sat, 30 Jul 2011 15:18:17 EDT." References: <1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office> <12207.1311921969@turing-police.cc.vt.edu> <5216.1311952950@turing-police.cc.vt.edu> <28441.1312035129@turing-police.cc.vt.edu> Message-ID: <85587.1312137125@turing-police.cc.vt.edu> On Sat, 30 Jul 2011 15:18:17 EDT, William Herrin said: > 2. I assume the subscription request came from a web page because if > it was from an email request you received then you ignored my SPF > records when generating the confirmation request. That was OK in 2001 > but in 2011 you ought not be doing that. So let's see. Certainly, you can try to make the case that SPF tends to help eliminate *some* of the use cases of that one SHOULD in that RFC. However: 1) SPF is not itself a mandatory required service for SMTP. 2) SPF usage is not anywhere near 100%. 3) Last I checked, the SPF grammar still included things like ~all and ?all and people were still using them. Let's look at the actual domain that owns the misbehaving Barracuda that started this thread: absfoc.com. 300 IN TXT "v=spf1 mx ptr a:mail.absfoc.com a:outbound.absmailgateway.net ?all" Hmm.. .'?all'. Remind me what that means Biil, my reading of RFC4408 is obviously wrong, because it seems to say "we explicitly don't claim anything about mail sent from any other addresses". That sort of shoots your "If Woody had gone straight to the SPF record, none of this would have happened" claim. That SPF record doesn't advise that mail arriving from other sources should be viewed with suspicion - it's saying even the mail admin of the domain doesn't want to make a value judgement. 3a) SPF doesn't prevent forgeries. In particular, it doesn't do anything for determining the validity of the left-hand side of the address... The above 3 alone tend to say to any reasonable person that if you're doing something because SPF isn't in place, you need to *keep* doing it *because SPF isn't universally in place in a configuration that's usable for this purpose*. But wait, there's more... 4) SPF doesn't in fact address the issue that using a null <> is dealing with - there are *many* cases where the subscription request can't be delivered even with SPF in place. Consider all the cases where your mail server may emit a 4xx or 5xx response to a mail. Many of those are in response to mail that was generated to once-valid email addresses. 5) And don't bother saying "but we'd reject the mail during the SMTP transaction yadda yadda yadda", because the fact you would do so is in fact the cause of the biggest headache scenario, and the one that many products *USE* that null MAIL FROM for: 5a) We receive a mail from joe at mailboxes-r-us.com requesting a subscription. It's all nice and pretty, and even both DKIM and SPF validated as that user at mailboxes-r-us.com. 5b) We send out the confirm message, and mailboxes-r-us.com accepted the mail because 'joe' is a fully paid up customer in good standing. 5c) Oh, and 'joe' has set forwarding to joe at herrin.us. 5d) That MAIL FROM:<> isn't for your benefit, it's for mailboxes-r-us.com's benefit so they don't have to generate a bounce when your SMTP server informns them that joe at herrin.us isn't a valid address anymore because you enforced your TOS on their spamming butts, or it's not a valid address anymore because they didn't pay their bill, or it's not valid anymore because they *did* pay their bill but your back office people screwed up posting the credit to their account, or their mailbox is full, or they've got a syntax error in their mail filter file, or some *other* user's mail just went totally bat-guano crazy and filled your spool, or... or pretty much *any* case where your mail server will generate a 5xx error in response to a forwarded mail. mailboxes-r-us.com is now the proud owner of a bounced message it didn't originate. And you're upset because some people looked at the SHOULD in the RFC, and thought hard about it, and decided that the administrivia mail in question should have the exact same delivery semantics as a bounce, MDN, or DSN, for exactly the same reasons (allow a mailer to drop it on the floor rather than potentially double-bounce it), and decided that it met the "for good reason" exemption that RFC2119 specifically includes as *the distinguising difference between MUST and SHOULD*. I'll make you a deal - *you* donate the resources needed to fix all 5 of the above Internet-wide(and yes, point 5 means you need to totally ban store-and-forward mail forwarding), and all the *other* corner cases that are involved, and then I'll talk with the people who are violating your sensibilities regarding that SHOULD. And even at that point, that Barracuda is almost certainly *still* broken, because I'm pretty darned sure it doesn't include code that says "reject MAIL FROM:<> unless it's a specifically blessed MDN, DSN, bounce or other RFC-compliant format", it's just got a "reject <> yes/no" switch someplace. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From joe at gonetforward.com Sun Jul 31 15:35:57 2011 From: joe at gonetforward.com (Joe Renwick) Date: Sun, 31 Jul 2011 13:35:57 -0700 Subject: Internet Blip in San Diego at 1pm? Message-ID: Several of my customers in San Diego noticed large drops in traffic at 1pm today. Note it was not a total loss in connectivity. Anyone else notice this? -- Joe Renwick IP Network Consultant, CCIE #16465 GO NETFORWARD Inc. Direct: 619-569-1621 Mobile: 619-972-7793 Emergency Support: 800-719-0504 Is your network moving you forward? From mike at m5computersecurity.com Sun Jul 31 15:43:53 2011 From: mike at m5computersecurity.com (Michael J McCafferty) Date: Sun, 31 Jul 2011 13:43:53 -0700 Subject: Internet Blip in San Diego at 1pm? In-Reply-To: References: Message-ID: <1312145033.3675.4497.camel@mike-desktop> I am one of your customers that noticed it. To add some data points; This affected Cogent, Level3 and several networks we peer with at the Any2 Exchange at One Wilshire. On Sun, 2011-07-31 at 13:35 -0700, Joe Renwick wrote: > Several of my customers in San Diego noticed large drops in traffic at 1pm > today. Note it was not a total loss in connectivity. Anyone else notice > this? > -- ************************************************************ Michael J. McCafferty Principal M5 Hosting http://www.m5hosting.com You can have your own custom Dedicated Server up and running today ! RedHat Enterprise, CentOS, Ubuntu, Debian, OpenBSD, FreeBSD, and more ************************************************************ From brokenflea at gmail.com Sun Jul 31 15:55:46 2011 From: brokenflea at gmail.com (Khurram Khan) Date: Sun, 31 Jul 2011 14:55:46 -0600 Subject: Internet Blip in San Diego at 1pm? In-Reply-To: <1312145033.3675.4497.camel@mike-desktop> References: <1312145033.3675.4497.camel@mike-desktop> Message-ID: Also impacted our POP's out of Houston and San Antonio, TX. We peer with L3 at both of those locations. On Sun, Jul 31, 2011 at 2:43 PM, Michael J McCafferty wrote: > > I am one of your customers that noticed it. To add some data points; > This affected Cogent, Level3 and several networks we peer with at the > Any2 Exchange at One Wilshire. > > On Sun, 2011-07-31 at 13:35 -0700, Joe Renwick wrote: >> Several of my customers in San Diego noticed large drops in traffic at 1pm >> today. ?Note it was not a total loss in connectivity. ?Anyone else notice >> this? >> > > -- > ************************************************************ > Michael J. McCafferty > Principal > M5 Hosting > http://www.m5hosting.com > > You can have your own custom Dedicated Server up and running today ! > RedHat Enterprise, CentOS, Ubuntu, Debian, OpenBSD, FreeBSD, and more > ************************************************************ > > > From virendra.rode at gmail.com Sun Jul 31 15:54:02 2011 From: virendra.rode at gmail.com (virendra rode) Date: Sun, 31 Jul 2011 13:54:02 -0700 Subject: Internet Blip in San Diego at 1pm? In-Reply-To: References: Message-ID: <4E35C0EA.6090209@gmail.com> On 07/31/2011 01:35 PM, Joe Renwick wrote: > Several of my customers in San Diego noticed large drops in traffic at 1pm > today. Note it was not a total loss in connectivity. Anyone else notice > this? > ------------------- Several of our east coat/overseas customers called in about reachability issues towards our SD pop. I believe this was LEVEL3 peering (?) related. Hopefully transparency will follow. regards, /virendra From jlk at thrashyour.com Sun Jul 31 16:00:26 2011 From: jlk at thrashyour.com (John Kinsella) Date: Sun, 31 Jul 2011 14:00:26 -0700 Subject: Internet Blip in San Diego at 1pm? In-Reply-To: References: Message-ID: <7247E8E1-2CD4-430F-8A9F-4576893EECB2@thrashyour.com> Also noticed it in Dallas, lasted about 10 mins. L3's edge would take the packets, but didn't go any further into their network. John On Jul 31, 2011, at 1:35 PM, Joe Renwick wrote: > Several of my customers in San Diego noticed large drops in traffic at 1pm > today. Note it was not a total loss in connectivity. Anyone else notice > this? > > -- > Joe Renwick > IP Network Consultant, CCIE #16465 > GO NETFORWARD Inc. > Direct: 619-569-1621 > Mobile: 619-972-7793 > Emergency Support: 800-719-0504 > Is your network moving you forward? From virendra.rode at gmail.com Sun Jul 31 15:59:40 2011 From: virendra.rode at gmail.com (virendra rode) Date: Sun, 31 Jul 2011 13:59:40 -0700 Subject: Internet Blip in San Diego at 1pm? In-Reply-To: References: <1312145033.3675.4497.camel@mike-desktop> Message-ID: <4E35C23C.3090707@gmail.com> On 07/31/2011 01:55 PM, Khurram Khan wrote: > Also impacted our POP's out of Houston and San Antonio, TX. We peer > with L3 at both of those locations. -------------------- Level3's had a core router failure in their Dallas region that lost adjacency towards LA region. regards, /virendra > > On Sun, Jul 31, 2011 at 2:43 PM, Michael J McCafferty > wrote: >> >> I am one of your customers that noticed it. To add some data points; >> This affected Cogent, Level3 and several networks we peer with at the >> Any2 Exchange at One Wilshire. >> >> On Sun, 2011-07-31 at 13:35 -0700, Joe Renwick wrote: >>> Several of my customers in San Diego noticed large drops in traffic at 1pm >>> today. Note it was not a total loss in connectivity. Anyone else notice >>> this? >>> >> >> -- >> ************************************************************ >> Michael J. McCafferty >> Principal >> M5 Hosting >> http://www.m5hosting.com >> >> You can have your own custom Dedicated Server up and running today ! >> RedHat Enterprise, CentOS, Ubuntu, Debian, OpenBSD, FreeBSD, and more >> ************************************************************ >> >> >> > > From joe at gonetforward.com Sun Jul 31 16:05:15 2011 From: joe at gonetforward.com (Joe Renwick) Date: Sun, 31 Jul 2011 14:05:15 -0700 Subject: Internet Blip in San Diego at 1pm? In-Reply-To: <4E35C0EA.6090209@gmail.com> References: <4E35C0EA.6090209@gmail.com> Message-ID: Level3 had an issue between LA and Dallas at 1pm. Apparently large amounts of traffic from San Diego head through Dallas so it appeared at a whole Internet drop. Joe On Sun, Jul 31, 2011 at 1:54 PM, virendra rode wrote: > On 07/31/2011 01:35 PM, Joe Renwick wrote: > >> Several of my customers in San Diego noticed large drops in traffic at 1pm >> today. Note it was not a total loss in connectivity. Anyone else notice >> this? >> >> ------------------- > Several of our east coat/overseas customers called in about reachability > issues towards our SD pop. I believe this was LEVEL3 peering (?) related. > > Hopefully transparency will follow. > > regards, > /virendra > > -- Joe Renwick IP Network Consultant, CCIE #16465 GO NETFORWARD Inc. Direct: 619-569-1621 Mobile: 619-972-7793 Emergency Support: 800-719-0504 Is your network moving you forward? From bill at herrin.us Sun Jul 31 17:36:22 2011 From: bill at herrin.us (William Herrin) Date: Sun, 31 Jul 2011 18:36:22 -0400 Subject: [BULK] Re: SORBS contact In-Reply-To: <85587.1312137125@turing-police.cc.vt.edu> References: <1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office> <12207.1311921969@turing-police.cc.vt.edu> <5216.1311952950@turing-police.cc.vt.edu> <28441.1312035129@turing-police.cc.vt.edu> <85587.1312137125@turing-police.cc.vt.edu> Message-ID: On Sun, Jul 31, 2011 at 2:32 PM, wrote: >That sort of shoots your "If Woody had gone straight to the >SPF record, none of this would have happened" claim. My WHAT claim? You asked if I wanted mailing list confirmation requests that arrive at my mail server to have a non-null return path. My answer was yes I do. And I still do. Even if it means I'm the one who gets stuck generating a deferred bounce because the final recipient downstream turned out to be non-deliverable. > And even at that point, that Barracuda is almost certainly *still* broken, > because I'm pretty darned sure it doesn't include code that says "reject MAIL > FROM:<> unless it's a specifically blessed MDN, DSN, bounce or other > RFC-compliant format", it's just got a "reject <> yes/no" switch someplace. I'll see your wild speculation and raise you mine. The Barracuda is designed to protect enterprises where the mail can only go out one path -- through it. It auto-whitelists folks its users sends mail to and allows bounce messages for those destinations based on pattern matching in the message content... before discarding other messages with a null return path. If my speculation is right, the Barracuda is behaving reasonably and SORBS' use of the null return path ignores the SHOULD in an ill considered manner. If your speculation is right, the Barracuda's design bug is exacerbated by SORBS' ill considered use of the null return path. Either way, SORBS' ill considered use of the null return path for the confirmation messages (disregarding the SHOULD in RFC 5321) contributes to fully broken mail delivery behavior. That last sentence there, that's my claim. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Valdis.Kletnieks at vt.edu Sun Jul 31 18:53:58 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 31 Jul 2011 19:53:58 -0400 Subject: [BULK] Re: SORBS contact In-Reply-To: Your message of "Sun, 31 Jul 2011 18:36:22 EDT." References: <1d95a7a9-8340-45e7-b803-03f1827326e1@brw-abs-office> <12207.1311921969@turing-police.cc.vt.edu> <5216.1311952950@turing-police.cc.vt.edu> <28441.1312035129@turing-police.cc.vt.edu> <85587.1312137125@turing-police.cc.vt.edu> Message-ID: <97554.1312156438@turing-police.cc.vt.edu> On Sun, 31 Jul 2011 18:36:22 EDT, William Herrin said: > On Sun, Jul 31, 2011 at 2:32 PM, wrote: > >That sort of shoots your "If Woody had gone straight to the > >SPF record, none of this would have happened" claim. > > My WHAT claim? What you said: > 2. I assume the subscription request came from a web page because if > it was from an email request you received then you ignored my SPF > records when generating the confirmation request. That was OK in 2001 > but in 2011 you ought not be doing that. However, we've established that the if the email request was from the domain that actually *started* this thread, the SPF data would *not have mattered* - even if it *was* checked, the fact it contained a '?all' would *not* have stopped the subscription request from being passed on. And before you start saying "but then they've got their SPF misconfigured" - remember that in 2011, we *still* don't have enough sites with SPF configured *correctly* that we can start chopping out code on the basis of "this case can't possibly happen with proper SPF, and almost never happens in the production Internet". And as I pointed out, there are a *lot* of failure modes that make you wish you can ditch the bounce message that are *not addressed at all* by SPF. Bounces caused by forged messages are just *one* issue - and even that's one that SPF doesn't actually address. > I'll see your wild speculation and raise you mine. The Barracuda is > designed to protect enterprises where the mail can only go out one > path -- through it. It auto-whitelists folks its users sends mail to > and allows bounce messages for those destinations based on pattern > matching in the message content... before discarding other messages > with a null return path. Presumably you're referring to this press release: http://www.reuters.com/article/2008/08/21/idUS127450+21-Aug-2008+BW20080821 However, it has the same problem as any other auto-whitelist - it can only whitelist those things it knows about. The press release talks about NDRs - but is silent on DSNs, MSNs, and other RFC-blessed uses of a null return path. And even if it *does* DTRT for all current standards-path RFCs, that *still* doesn't change the fact that what it's basically doing is saying "We're unilaterally insisting that the 'SHOULD have a non-null' is actually a MUST, and enforcing it". They are of course welcome to do so, but they're not allowed to complain when elevating said SHOULD to a MUST causes some mail to be lost because the mail came from a site that's still following what the RFC actually says, not what Barracuda or the recipient site *wishes* it said. Let me repeat that: You're certainly allowed to be stricter than the standard. However, you're *not* allowed to complain when being stricter than the standard results in failures dealing with less-strict-but-still-standard inputs. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From randy at psg.com Sun Jul 31 19:03:33 2011 From: randy at psg.com (Randy Bush) Date: Mon, 01 Aug 2011 09:03:33 +0900 Subject: list Message-ID: not to detract from the seasonal sorbs pissing contest, but in the spirit of you never notice operations when it works, i wish to thank and congratulate the folk who moved this mailing list. i seems to just work. randy From marka at isc.org Sun Jul 31 19:09:13 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 01 Aug 2011 10:09:13 +1000 Subject: list In-Reply-To: Your message of "Mon, 01 Aug 2011 09:03:33 +0900." References: Message-ID: <20110801000913.EC52C125A538@drugs.dv.isc.org> In message , Randy Bush writes: > not to detract from the seasonal sorbs pissing contest, but in the spirit of > you never notice operations when it works, i wish to thank and congratulate > the folk who moved this mailing list. i seems to just work. > > randy Seconded. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Sun Jul 31 19:42:32 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 01 Aug 2011 10:42:32 +1000 Subject: DNS DoS ??? In-Reply-To: Your message of "Sun, 31 Jul 2011 06:48:41 GMT." <09D7A1D0-0B13-4570-8891-835CA6568AD7@arbor.net> References: <5BB5C3AA-6C94-4BDE-8326-4EA675CC5EE4@arbor.net> <09D7A1D0-0B13-4570-8891-835CA6568AD7@arbor.net> Message-ID: <20110801004232.3B159125A6CB@drugs.dv.isc.org> In message <09D7A1D0-0B13-4570-8891-835CA6568AD7 at arbor.net>, "Dobbins, Roland" writes: > > On Jul 31, 2011, at 9:15 AM, "Jimmy Hess" wrote: > > > Is there an RFC specifying precisely what are considered the proper prec= > autions? > > "precautions" should ideally be enabled in BIND by default. > > Not of which I'm aware. I'm happy to contribute to any efforts you or anyon= > e else are volunteering to coordinate on this topic, as it's important work= > which ought to be done sooner & not later. Named already takes proper precautions by default. Recursive service is limited to directly connected networks by default. The default was first changed in 9.4 (2007) which is about to go end-of-life once the final wrap up release is done. > > My point here is that... splitting recursive service and cordoning off = > recursive service by > > using a firewall > > Using a stateful firewall is contraindicated.=20 > > > or ACL based on IP address, is only a partially effective operational wo= > rkaround to a serious defect in the protocol. > > It's actually a combination of serious defects in a number of protocols, st= > arting with IPv4 itself.=20 The real problem is that many ISP's don't do effective ingress/egress filtering. This prevents compromised machines impersonating other machines. There is absolutely no reason that DSL and Cable connection shouldn't be tied down to provider source addresess and perhaps a specfic set of exception source addresses on request. There is absolutely no reason that NOC's and other service networks in the ISPs shouldn't be tied down. If you to spoof addresses for testing do it from networks explictly setup to support this. > IPv4 went into service ~27 years ago as testbed protocol. The first formal = > security assessment of the IPv4 core protocols was completed last month.=20 > > IPv6 inherits all the security problems inherent in IPv4, & introduces new = > ones - the ND mess & the untold billions of dollars in opex costs that the = > consonance of the letters 'B', 'C', 'D', & 'E' will entail are just two gla= > ring examples.=20 > > So, if we're looking for protocol architecture dragons to slay, there're fa= > r more basic issues in need of a strong sword-arm before we even get to out= > liers like the DNS, heh. > > > Authoritative service is as subject to DoS as ever, especially with IPv6 = > and DNSSEC > > deployments. > > And there are deployment & operational BCPs which can mitigate DDoS of auth= > oritative DNS services, from logical separation of functions (see files.me.com/roland.dobbins/m4g34u> for an example) to S/RTBH to flowspec t= > o commercial IDMS solutions.=20 > > [Full disclosure: my employer is a vendor of such solutions.] > > > The DNS protocol should be fixed so we don't need this workaround. > > By all means.=20 > > In the meantime, it's important to realize that many of the resource constr= > aints which were extant at the time the DNS was designed no longer hold swa= > y. DNS reflection/amplification attacks can be eliminated by the simple (a= > nd, nowadays, practical, IMHO) expedient of re-configuring resolver-facing = > DNS servers to force the use TCP by default.=20 > > The best part is that DNS operators can start doing this today, without rec= > ourse to standards bodies, working groups, et. al. No need for any inter-o= > rganizational coordination at all - each can move at his own pace, within h= > is own span of administrative control.=20 > > As an aside, it should be noted that switching the DNS over to TCP by defau= > lt would accomplish a great deal of what DNSSEC is intended to provide, wit= > h far less in the way of architectural, operational, & administrative compl= > exity.=20 > > Most folks who still misguidedly filter TCP/53 are unlikely to support EDNS= > 0, either, so they're already hurting - a widespread switch to TCP would li= > kely finally force them out of their jungle fastnesses and out blinking int= > o the sunlight.=20 > > ;> > > > Standardization effort should concentrate on changing the protocol. > > It's important to keep in mind how long the last substantive changes to the= > DNS have required, as opposed to the near-term expedient of implementing B= > CPs & switching to TCP.=20 > > > Restricting recursive service is a good short term solution, but it is n= > ot for every case. > > Concur 100%. Meanwhile, we continue to resolve with the DNS we have until t= > he new, improved version is designed, tested, & generally deployed.=20 > > ;> > > > The workaround is not a best practice, it is evidence that the DNS protoc= > ol should be changed. > > There's a reason proof-of-work solutions have never been widely deployed - = > in the final analysis, they all too often end up simply a form of cost-shif= > ting which leaves the system in question just as vulnerable (if not more so= > ) to DoS as it was in the first place, just within a different transaction = > path/layer.=20 > > So, while I agree with you that changes are called for, implementing proofs= > -of-work into the DNS transactional model isn't one I'd personally recommen= > d, FWIW.=20 > > --------------------------------------------------------------------- > > Roland Dobbins // > > Sell your computer and buy a guitar.=20 > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From rdobbins at arbor.net Sun Jul 31 19:49:22 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 1 Aug 2011 00:49:22 +0000 Subject: DNS DoS ??? In-Reply-To: <20110801004232.3B159125A6CB@drugs.dv.isc.org> References: <5BB5C3AA-6C94-4BDE-8326-4EA675CC5EE4@arbor.net> <09D7A1D0-0B13-4570-8891-835CA6568AD7@arbor.net> <20110801004232.3B159125A6CB@drugs.dv.isc.org> Message-ID: On Aug 1, 2011, at 7:42 AM, Mark Andrews wrote: > Named already takes proper precautions by default. Recursive service is limited to directly connected networks by default. The default > was first changed in 9.4 (2007) which is about to go end-of-life once the final wrap up release is done. This alone isn't enough. There are quite a few other things folks must do from an architectural and operational standpoint which aren't found in named.conf. > The real problem is that many ISP's don't do effective ingress/egress filtering. Well, no. The real problem is a protocol set/implementation which lends itself so readily to spoofing in the first place, followed (as you say) by ISP/endpoint network inattention to anti-spoofing, followed by protocols which make use of the eminently-spoofable UDP for a critical service. > This prevents compromised machines impersonating other machines. Concur, but see above - spoofing is the symptom, not the disease. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From marka at isc.org Sun Jul 31 21:22:01 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 01 Aug 2011 12:22:01 +1000 Subject: DNS DoS ??? In-Reply-To: Your message of "Mon, 01 Aug 2011 00:49:22 GMT." References: <5BB5C3AA-6C94-4BDE-8326-4EA675CC5EE4@arbor.net> <09D7A1D0-0B13-4570-8891-835CA6568AD7@arbor.net> <20110801004232.3B159125A6CB@drugs.dv.isc.org> Message-ID: <20110801022201.D830F125A9D2@drugs.dv.isc.org> In message , "Dobbins, Roland" writes: > On Aug 1, 2011, at 7:42 AM, Mark Andrews wrote: > > > Named already takes proper precautions by default. Recursive service is = > limited to directly connected networks by default. The default > > was first changed in 9.4 (2007) which is about to go end-of-life once the= > final wrap up release is done. > > This alone isn't enough. There are quite a few other things folks must do = > from an architectural and operational standpoint which aren't found in name= > d.conf. > > > The real problem is that many ISP's don't do effective ingress/egress fil= > tering. > > Well, no. The real problem is a protocol set/implementation which lends it= > self so readily to spoofing in the first place, followed (as you say) by IS= > P/endpoint network inattention to anti-spoofing, followed by protocols whic= > h make use of the eminently-spoofable UDP for a critical service. And even if DNS/TCP was use by default machines can still get DoS'd because IP is spoofable. This one looks like a direct attack on the machine as there are multiple source addresses rather than a reflector attack unless they are attempting to attack thousands of sites simultaniously. > > This prevents compromised machines impersonating other machines. > > Concur, but see above - spoofing is the symptom, not the disease. > > ----------------------------------------------------------------------- > Roland Dobbins // > > The basis of optimism is sheer terror. > > -- Oscar Wilde > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From rdobbins at arbor.net Sun Jul 31 21:27:19 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 1 Aug 2011 02:27:19 +0000 Subject: DNS DoS ??? In-Reply-To: <20110801022201.D830F125A9D2@drugs.dv.isc.org> References: <5BB5C3AA-6C94-4BDE-8326-4EA675CC5EE4@arbor.net> <09D7A1D0-0B13-4570-8891-835CA6568AD7@arbor.net> <20110801004232.3B159125A6CB@drugs.dv.isc.org> <20110801022201.D830F125A9D2@drugs.dv.isc.org> Message-ID: <0EDEAA6B-DB73-4945-BF23-1A351F17582B@arbor.net> On Aug 1, 2011, at 9:22 AM, Mark Andrews wrote: > And even if DNS/TCP was use by default machines can still get DoS'd because IP is spoofable. They can be DDoSed with spoofed or non-spoofed packets, and there are defenses against such attacks. Apologies if I was unclear - my point was that huge, crushing, multi-gigabit-per-second DNS reflection/amplification attacks would no longer be possible with a TCP-only DNS, and that there would be other benefits, as well. Large-scale testing of TCP-only DNS would be quite informative, IMHO. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From brwatters at absfoc.com Thu Jul 28 16:20:37 2011 From: brwatters at absfoc.com (Brian R. Watters) Date: Thu, 28 Jul 2011 16:20:37 -0500 Subject: SORBS contact Message-ID: <9c9d1330-2b98-4c18-bef6-532302e5ba12@journal.report.generator> Sender: brwatters at absfoc.com Subject: Re: SORBS contact Message-Id: <8beae4f1-acd0-4408-9f75-264aff04d788 at brw-abs-office> Recipient: gerno at trinity.edu.test-google-a.com, Forwarded: Gerno.Reinard at Trinity.edu -------------- next part -------------- An embedded message was scrubbed... From: "Brian R. Watters" Subject: Re: SORBS contact Date: Thu, 28 Jul 2011 14:20:08 -0700 Size: 4315 URL: From brwatters at absfoc.com Thu Jul 28 16:17:02 2011 From: brwatters at absfoc.com (Brian R. Watters) Date: Thu, 28 Jul 2011 16:17:02 -0500 Subject: [BULK] Re: SORBS contact Message-ID: <49a9283b-04d2-4ec0-91af-6c9b953c4725@journal.report.generator> Sender: brwatters at absfoc.com Subject: Re: [BULK] Re: SORBS contact Message-Id: <1d95a7a9-8340-45e7-b803-03f1827326e1 at brw-abs-office> Recipient: gerno at trinity.edu.test-google-a.com, Forwarded: Gerno.Reinard at Trinity.edu -------------- next part -------------- An embedded message was scrubbed... From: "Brian R. Watters" Subject: Re: [BULK] Re: SORBS contact Date: Thu, 28 Jul 2011 14:16:23 -0700 Size: 5173 URL: