- Test - lists.nanog.org

Dev. Mfg & ISP Filtering Requirements as set forth in Florida HB337/SB0870, and under similar bills in about 30 other states...
by Kraig Beahn 11 Feb '17

11 Feb '17

There's a bill being widely circulated and passing thru various chambers of at least 30 states right now, commonly being referred to as the HUMAN TRAFFICKING AND CHILD EXPLOITATION PREVENTION ACT, or in Florida's case, we're apparently calling this the "HB 337:Internet Access" bill. Jokes, moral considerations and politics aside - Does anyone have any further information on potentially related bills passing thru states beyond Florida, and has anyone seriously considered the infrastructure changes/impairments necessary to comply, in the unusual event that HB337 or any of the many other bills in various other states passes? Edited HB Brief: An act relating to Internet access; prohibiting covered businesses from manufacturing, distributing, or selling certain devices unless the device contains an active and operating filter that blocks Internet access to specified types of sexually oriented material, prostitution, assignation, lewdness, and human trafficking; providing for injunctive relief for violations; providing requirements for a consumer to have such filter deactivated; requiring a filter deactivation fee and providing for the collection and distribution thereof; prohibiting the distribution or sale of certain devices without filters to minors and adults; providing criminal penalties; providing for jurisdiction to prosecute violations; providing for continuing duties of covered businesses; requiring covered businesses to respond to reports of obscene material that has breached the filter; providing for civil penalties for violations; requiring covered businesses to unblock non obscene material; exempting certain websites from filtering; amending s. 16.56, F.S.; authorizing the Office of Statewide Prosecution to prosecute violations; providing an effective date. The Full Text can be found here: FL/HB 337 <http://www.flsenate.gov/Session/Bill/2017/0337/BillText/__/PDF> On the technical side, you'd probably find yourself chuckling through this reading exercise. However, our regulatory attorney was assured this bill for which is currently under consideration is no laughing matter and is being seriously considered in a multitude of state venues, while others have been dismissive. We've initiated several calls with aide's for Rep. Spanos, the Florida House sponsor, and from what we can tell, the bill is far from the chopping block. Considering the technical impacts not only to internet access device manufacturers, and the implied impacts on service providers like ourselves, i'm surprised it hasn't garnered more attention, nationally. >From a curiosity perspective: The source of this bill appears to be an individual by the name Mark "Chris" Sevier, the same individual whom has virtually sued most of Silicon Valley, and I'll leave it at that in hopes of being able to keep this thread on a technical/legislative tone. NANOG note: Our objective in starting this tread is not to question the intent, moral purpose or potential political agendas surrounding Florida House Bill 337 or bills of similar nature, only it's technical impact on device manufacturers, internet access providers and other alike legislatively covered businesses, assuming passage, as currently written. --

2 1

IoT security
by William Herrin 10 Feb '17

10 Feb '17

This afternoon's panel about IoT's lack of security got me thinking... On the issue of ISPs unable to act on insecure devices because they can't detect the devices until they're compromised and then only have the largest hammer (full account ban) to act... What about some kind of requirement or convention that upon boot and successful attachment to the network (and maybe once a month thereafter), any IoT device must _by default_ emit a UDP packet to an anycast address reserved for the purpose which identifies the device model and software build. The ISP can capture traffic to that anycast address, compare the data against a list of devices known to be defective and, if desired, respond with a fail message. If the IoT device receives the fail message, it must try to report the problem to its owner and remove its default route so that it can only communicate on the local lan. The user can override the fail and if desired configure the device not to emit the init messages at all. But by default the ISP is allowed to disable the device by responding to the init message. Would have to cryptographically sign the fail message and let the device query the signer's reputation or something like that to avoid the obvious security issue. Obvious privacy issues to consider. Anyway, throwing it out there as a potential discussion starting point. The presentation on bandwidth policers... Seems like we could use some form of ICMP message similar to destination unreachable that provides some kind of arbitrary string plus the initial part of the dropped packet. One of the potential strings would be an explicit notice to the sender that packets were dropped and the bandwidth available. Yes, we already have ECN, but ECN tells the receiver about congestion, not the sender. More to the point, ECN can only be flagged on packets that are passed, not the packets that are dropped, so the policer would have to be complicated enough to note on the next packet that the prior packet was dropped. Also, ECN only advises that you're close to the limit not any information about the policer's target limit. This thought is not fully baked. Throwing it out for conversation purposes. Regards, Bill Herrin -- William Herrin ................ herrin(a)dirtside.com bill(a)herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

16 33

Gmail or GAFYD SREs on the list?
by Brad Knowles 10 Feb '17

10 Feb '17

Folks, Do we have any SREs from the Gmail or Google Apps For Your Domain teams on the list? I’m helping to support some domains related to the Network Time Foundation and NTP.org, and we’re having some problems with IPv6 connectivity to them. Thanks! -- Brad Knowles <brad(a)shub-internet.org>

1 0

Someone's scraping NANOG for phishing purposes again
by Alexander Harrowell 10 Feb '17

10 Feb '17

I'm getting suspicious e-mail pretending to come from leading NANOGers. Not the first time this has happened, but you may want to be warned. Yours, Alex Harrowell

7 8

Weekly Routing Table Report
by cscora＠apnic.net 10 Feb '17

10 Feb '17

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, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats(a)lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith <pfsinoz(a)gmail.com>. Routing Table Report 04:00 +10GMT Sat 11 Feb, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 635010 Prefixes after maximum aggregation (per Origin AS): 247431 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 305846 Total ASes present in the Internet Routing Table: 56204 Prefixes per ASN: 11.30 Origin-only ASes present in the Internet Routing Table: 48647 Origin ASes announcing only one prefix: 21683 Transit ASes present in the Internet Routing Table: 7557 Transit-only ASes present in the Internet Routing Table: 208 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 41 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 80 Numnber of instances of unregistered ASNs: 81 Number of 32-bit ASNs allocated by the RIRs: 17256 Number of 32-bit ASNs visible in the Routing Table: 13413 Prefixes from 32-bit ASNs in the Routing Table: 53971 Number of bogon 32-bit ASNs visible in the Routing Table: 50 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 429 Number of addresses announced to Internet: 2832797668 Equivalent to 168 /8s, 217 /16s and 15 /24s Percentage of available address space announced: 76.5 Percentage of allocated address space announced: 76.5 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.4 Total number of prefixes smaller than registry allocations: 211930 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 173285 Total APNIC prefixes after maximum aggregation: 49607 APNIC Deaggregation factor: 3.49 Prefixes being announced from the APNIC address blocks: 172688 Unique aggregates announced from the APNIC address blocks: 71398 APNIC Region origin ASes present in the Internet Routing Table: 7845 APNIC Prefixes per ASN: 22.01 APNIC Region origin ASes announcing only one prefix: 2190 APNIC Region transit ASes present in the Internet Routing Table: 1119 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 41 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2672 Number of APNIC addresses announced to Internet: 760441732 Equivalent to 45 /8s, 83 /16s and 107 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 193476 Total ARIN prefixes after maximum aggregation: 92928 ARIN Deaggregation factor: 2.08 Prefixes being announced from the ARIN address blocks: 195792 Unique aggregates announced from the ARIN address blocks: 89820 ARIN Region origin ASes present in the Internet Routing Table: 17789 ARIN Prefixes per ASN: 11.01 ARIN Region origin ASes announcing only one prefix: 6642 ARIN Region transit ASes present in the Internet Routing Table: 1766 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1756 Number of ARIN addresses announced to Internet: 1104034720 Equivalent to 65 /8s, 206 /16s and 59 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 169226 Total RIPE prefixes after maximum aggregation: 83704 RIPE Deaggregation factor: 2.02 Prefixes being announced from the RIPE address blocks: 164564 Unique aggregates announced from the RIPE address blocks: 99725 RIPE Region origin ASes present in the Internet Routing Table: 23672 RIPE Prefixes per ASN: 6.95 RIPE Region origin ASes announcing only one prefix: 10968 RIPE Region transit ASes present in the Internet Routing Table: 3356 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5534 Number of RIPE addresses announced to Internet: 709553024 Equivalent to 42 /8s, 74 /16s and 235 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 82544 Total LACNIC prefixes after maximum aggregation: 17448 LACNIC Deaggregation factor: 4.73 Prefixes being announced from the LACNIC address blocks: 83648 Unique aggregates announced from the LACNIC address blocks: 37823 LACNIC Region origin ASes present in the Internet Routing Table: 5645 LACNIC Prefixes per ASN: 14.82 LACNIC Region origin ASes announcing only one prefix: 1557 LACNIC Region transit ASes present in the Internet Routing Table: 1039 Average LACNIC Region AS path length visible: 5.3 Max LACNIC Region AS path length visible: 36 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3161 Number of LACNIC addresses announced to Internet: 170804288 Equivalent to 10 /8s, 46 /16s and 68 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 16366 Total AfriNIC prefixes after maximum aggregation: 3683 AfriNIC Deaggregation factor: 4.44 Prefixes being announced from the AfriNIC address blocks: 17889 Unique aggregates announced from the AfriNIC address blocks: 6717 AfriNIC Region origin ASes present in the Internet Routing Table: 1017 AfriNIC Prefixes per ASN: 17.59 AfriNIC Region origin ASes announcing only one prefix: 326 AfriNIC Region transit ASes present in the Internet Routing Table: 198 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 290 Number of AfriNIC addresses announced to Internet: 87502592 Equivalent to 5 /8s, 55 /16s and 47 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5531 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3724 391 256 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2984 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2729 11133 744 KIXS-AS-KR Korea Telecom, KR 9829 2718 1501 542 BSNL-NIB National Internet Backbone, IN 9808 2283 8698 33 CMNET-GD Guangdong Mobile Communication 4755 2058 421 220 TATACOMM-AS TATA Communications formerl 45899 1861 1299 100 VNPT-AS-VN VNPT Corp, VN 4808 1636 1784 445 CHINA169-BJ China Unicom Beijing Provin 24560 1564 571 250 AIRTELBROADBAND-AS-AP Bharti Airtel Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3629 2968 151 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3260 1333 83 SHAW - Shaw Communications Inc., CA 18566 2191 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2063 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 1970 2034 406 CHARTER-NET-HKY-NC - Charter Communicat 209 1725 5067 640 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1688 317 459 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1680 848 227 ITCDELTA - Earthlink, Inc., US 16509 1642 3064 537 AMAZON-02 - Amazon.com, Inc., US 701 1594 10597 657 UUNET - MCI Communications Services, In Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3334 171 18 ALJAWWALSTC-AS , SA 20940 3013 1129 2135 AKAMAI-ASN1 , US 9121 2138 1691 18 TTNET , TR 34984 1994 328 380 TELLCOM-AS , TR 13188 1615 99 62 TRIOLAN , UA 8551 1607 377 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12479 1468 1033 50 UNI2-AS , ES 6849 1318 355 22 UKRTELNET , UA 9198 1300 352 24 KAZTELECOM-AS , KZ 8402 1151 544 15 CORBINA-AS OJSC "Vimpelcom", RU 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 3541 545 158 Telmex Colombia S.A., CO 26615 3027 2330 44 Tim Celular S.A., BR 8151 2488 3390 549 Uninet S.A. de C.V., MX 11830 1804 368 66 Instituto Costarricense de Electricidad 6503 1570 437 54 Axtel, S.A.B. de C.V., MX 7303 1430 878 255 Telecom Argentina S.A., AR 6147 1353 377 27 Telefonica del Peru S.A.A., PE 28573 1059 2273 182 CLARO S.A., BR 3816 1001 479 185 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11664 984 280 35 Techtel LMDS Comunicaciones Interactiva 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 1298 398 41 LINKdotNET-AS, EG 36903 719 361 123 MT-MPLS, MA 37611 690 67 6 Afrihost, ZA 36992 587 1373 25 ETISALAT-MISR, EG 24835 490 658 16 RAYA-AS, EG 8452 461 1474 16 TE-AS TE-AS, EG 37492 392 316 74 ORANGE-TN, TN 29571 367 36 10 CITelecom-AS, CI 15399 327 35 6 WANANCHI-KE, KE 2018 273 327 74 TENET-1, ZA 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 4538 5531 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3724 391 256 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3629 2968 151 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3541 545 158 Telmex Colombia S.A., CO 39891 3334 171 18 ALJAWWALSTC-AS , SA 6327 3260 1333 83 SHAW - Shaw Communications Inc., CA 26615 3027 2330 44 Tim Celular S.A., BR 20940 3013 1129 2135 AKAMAI-ASN1 , US 17974 2984 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2729 11133 744 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3629 3478 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3724 3468 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3541 3383 Telmex Colombia S.A., CO 39891 3334 3316 ALJAWWALSTC-AS , SA 6327 3260 3177 SHAW - Shaw Communications Inc., CA 26615 3027 2983 Tim Celular S.A., BR 17974 2984 2913 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9808 2283 2250 CMNET-GD Guangdong Mobile Communication Co.Ltd. 9829 2718 2176 BSNL-NIB National Internet Backbone, IN 9121 2138 2120 TTNET , TR Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65555 UNALLOCATED 37.142.172.0/24 21450 MIRS-AS , IL Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 41.73.16.0/24 37004 Suburban-Broadband-AS, NG 41.73.17.0/24 37004 Suburban-Broadband-AS, NG 41.73.18.0/24 37004 Suburban-Broadband-AS, NG 41.73.19.0/24 37004 Suburban-Broadband-AS, NG 41.73.20.0/24 37004 Suburban-Broadband-AS, NG 41.73.21.0/24 37004 Suburban-Broadband-AS, NG 41.73.22.0/24 37004 Suburban-Broadband-AS, NG 41.73.23.0/24 37004 Suburban-Broadband-AS, NG 41.76.232.0/21 203496 AB-TELECOM , RU Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:103 /12:276 /13:535 /14:1047 /15:1801 /16:13175 /17:7751 /18:12998 /19:25124 /20:38119 /21:40837 /22:74093 /23:62687 /24:355030 /25:561 /26:415 /27:294 /28:35 /29:19 /30:18 /31:1 /32:26 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3056 3260 SHAW - Shaw Communications Inc., CA 39891 2896 3334 ALJAWWALSTC-AS , SA 22773 2825 3629 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 26615 2543 3027 Tim Celular S.A., BR 18566 2084 2191 MEGAPATH5-US - MegaPath Corporation, US 9121 1503 2138 TTNET , TR 30036 1499 1688 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1452 3541 Telmex Colombia S.A., CO 6389 1372 2063 BELLSOUTH-NET-BLK - BellSouth.net Inc., US 13188 1359 1615 TRIOLAN , UA Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1596 2:832 4:25 5:2443 6:34 8:1047 12:1810 13:74 14:1777 15:22 16:2 17:100 18:128 19:1 20:53 23:2012 24:1847 25:2 27:2385 31:1858 32:89 33:2 34:1 35:3 36:357 37:2526 38:1308 39:43 40:101 41:2846 42:452 43:1929 44:59 45:2382 46:2548 47:110 49:1218 50:945 51:18 52:709 54:357 55:7 56:4 57:41 58:1616 59:989 60:386 61:1898 62:1505 63:1928 64:4558 65:2185 66:4451 67:2222 68:1168 69:3324 70:1302 71:570 72:2050 74:2609 75:405 76:411 77:1436 78:1583 79:1280 80:1342 81:1401 82:982 83:722 84:869 85:1691 86:482 87:1132 88:781 89:2054 90:201 91:6125 92:985 93:2378 94:2356 95:2793 96:570 97:357 98:936 99:91 100:152 101:1261 103:13569 104:2706 105:147 106:482 107:1530 108:794 109:2575 110:1287 111:1662 112:1149 113:1234 114:1028 115:1733 116:1745 117:1649 118:2056 119:1564 120:952 121:1099 122:2341 123:2016 124:1527 125:1813 128:745 129:616 130:412 131:1391 132:520 133:193 134:529 135:209 136:505 137:430 138:1841 139:499 140:367 141:518 142:731 143:908 144:764 145:167 146:1021 147:658 148:1361 149:569 150:686 151:938 152:722 153:316 154:750 155:963 156:548 157:589 158:443 159:1393 160:566 161:734 162:2473 163:528 164:782 165:1153 166:370 167:1260 168:2519 169:738 170:2777 171:275 172:934 173:1827 174:805 175:720 176:1774 177:4234 178:2477 179:1644 180:2096 181:2032 182:2210 183:1041 184:830 185:8713 186:3208 187:2684 188:2367 189:1786 190:8138 191:1945 192:9288 193:5777 194:4624 195:3845 196:1957 197:1231 198:5572 199:5835 200:7387 201:4132 202:10117 203:9879 204:4454 205:2772 206:2985 207:3150 208:3999 209:3882 210:3914 211:2096 212:2789 213:2456 214:861 215:64 216:5814 217:1988 218:834 219:607 220:1685 221:901 222:723 223:1172 End of report

1 0

Telia network quality
by Don 10 Feb '17

10 Feb '17

I heard Telia's quality had been on the decline lately as they were signing on lots of high-capacity new customers, and Cloudflare had some complaint about them a few months prior too. Does anybody have any insight into whether this is still the case? I was trying to evaluate whether Telia would be a good carrier to switch over to as a primary provider, as their pricing does look pretty attractive. B/R Don

11 11

Same day PDU and power cable suppliers for NYC / Newark
by Timothy Creswick 09 Feb '17

09 Feb '17

Hi All, We're after a couple of L5-30 to n * IEC C13 PDUs in the NYC / Newark area on short notice (i.e. same day). Can anyone recommend a local supplier who can help with this? Many thanks in advance, Tim - Timothy Creswick

1 0

GTT AS3257 router server
by Clinton Work 09 Feb '17

09 Feb '17

If anybody is reading the NANOG list from the GTT NOC, can you look at your route-server with the BGP session flapping every couple of minutes. route-server.as3257.net>show ip bgp sum Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 213.200.64.93 4 3257 68799843 331607 0 0 0 00:00:50 Active -- Clinton Work

2 1

Re: Bandwidth Savings (Keenan Singh)
by Keenan Singh 09 Feb '17

09 Feb '17

Hi Ramy I reached out to FB and they are looking for a min of 5G Traffic coming from your AS to qualify for a Cache. Not sure how they came up with 5G as normally everyone else would ask for 1G Traffic. Can anyone one else confirm, maybe some one from FB is here and can clarify? Keenan On Feb 9, 2017 6:32 AM, "Ramy Hashish" <ramy.ihashish(a)gmail.com> wrote: Hello Luke and all, I stumbled upon some news about Facebook edge network servers, does anybody know anything about the caches the FB use and the ISPs can host? and is Facebook a part of SVA alliance? Thanks, Ramy Hi Luke, > > Regarding HTTPS Streaming and Netflix... > > Netflix announced in the spring of 2015 that it would move to HTTPS > delivery by April of 2016. At the time of that first announcement, some > concluded Netflix might not be able to afford the capital investment > required to enable HTTPS delivery. > > Given Netflix did not complete the HTTPS project by their first deadline, > we believe they have been focused on other priorities such as their global > expansion, So, given this history, it's not clear just when or if Netflix > will make the move to majority HTTPS for delivery. Furthermore, Netflix is > under considerable pressure from investors to improve subscriber growth, > revenue growth and profitability. The HTTPS project does not support any of > these goals. In fact, Netflix reported net income is marginal and a move to > full HTTPS delivery would likely consume all profits for the year. > > Along with the rest of the industry, we recognize the need for Open > Caching systems to support HTTPS streaming from upstream content > providers. This is one of the reasons why we were a Founding Member, along > with 16 other streaming companies, in the Streaming Video Alliance in the > fall of 2014. The SVA now includes almost 50 member companies from across > the streaming ecosystem and around the world. More importantly, the Open > Caching Working Group has issued functional requirements, unanimously > approved by SVA members, which include support for HTTPS streams. > > The SVA Board has invited Netflix to join the Alliance and, in doing so, > endorse the Open Caching work underway. This would open up a path in the > short run to ensure any open cache can continue to support Netflix content > even if Netflix moves to HTTPS delivery. We expect to see Netflix become > more active in the SVA soon given other major streaming providers, such as > Hulu and Amazon, are joining now. > > In conclusion, the SVA has developed a solution for Open Cache support of > HTTPS streaming and we expect all streaming providers, including Netflix, > will align with the SVA's direction. > > http://www.streamingvideoalliance.org/ > > Let me know if you have any more questions. > > Regards, > > > > Luke Guillory > Network Operations Manager > > Tel: 985.536.1212 <(985)%20536-1212> > Fax: 985.536.0300 <(985)%20536-0300> > Email: lguillory(a)reservetele.com > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > ____________________________________________________________ > _____________________________________ > > Disclaimer: > The information transmitted, including attachments, is intended only for > the person(s) or entity to which it is addressed and may contain > confidential and/or privileged material which should not disseminate, > distribute or be copied. Please notify Luke Guillory immediately by e-mail > if you have received this e-mail by mistake and delete this e-mail from > your system. E-mail transmission cannot be guaranteed to be secure or > error-free as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. Luke Guillory therefore does > not accept liability for any errors or omissions in the contents of this > message, which arise as a result of e-mail transmission. . > > -----Original Message----- > From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Keenan Singh > Sent: Tuesday, January 10, 2017 10:09 PM > To: nanog(a)nanog.org > Subject: Bandwidth Savings > > Hi Guys > > We are an ISP in the Caribbean, and are faced with extremely high > Bandwidth costs, compared to the US, we currently use Peer App for Caching > however with most services now moving to HTTPS the cache is proving to be > less and less effective. We are currently looking at any way we can save on > Bandwidth or to be more Efficient with the Bandwidth we currently have. We > do have a Layer 2 Circuit between the Island and Miami, I am seeing there > are WAN Accelerators where they would put a Server on either end and sort > of Compress and decompress the Traffic before it goes over the Layer 2, I > have never used this before, has any one here used anything like this, what > results would I be able to expect for ISP Traffic? > > If not any ideas on Bandwidth Savings, or being more Efficient with want > we currently. > > Many thanks for any Help > > Keenan > >

1 0

Re: Bandwidth Savings (Keenan Singh)
by Ramy Hashish 09 Feb '17

09 Feb '17

Hello Luke and all, I stumbled upon some news about Facebook edge network servers, does anybody know anything about the caches the FB use and the ISPs can host? and is Facebook a part of SVA alliance? Thanks, Ramy Hi Luke, > > Regarding HTTPS Streaming and Netflix... > > Netflix announced in the spring of 2015 that it would move to HTTPS > delivery by April of 2016. At the time of that first announcement, some > concluded Netflix might not be able to afford the capital investment > required to enable HTTPS delivery. > > Given Netflix did not complete the HTTPS project by their first deadline, > we believe they have been focused on other priorities such as their global > expansion, So, given this history, it's not clear just when or if Netflix > will make the move to majority HTTPS for delivery. Furthermore, Netflix is > under considerable pressure from investors to improve subscriber growth, > revenue growth and profitability. The HTTPS project does not support any of > these goals. In fact, Netflix reported net income is marginal and a move to > full HTTPS delivery would likely consume all profits for the year. > > Along with the rest of the industry, we recognize the need for Open > Caching systems to support HTTPS streaming from upstream content > providers. This is one of the reasons why we were a Founding Member, along > with 16 other streaming companies, in the Streaming Video Alliance in the > fall of 2014. The SVA now includes almost 50 member companies from across > the streaming ecosystem and around the world. More importantly, the Open > Caching Working Group has issued functional requirements, unanimously > approved by SVA members, which include support for HTTPS streams. > > The SVA Board has invited Netflix to join the Alliance and, in doing so, > endorse the Open Caching work underway. This would open up a path in the > short run to ensure any open cache can continue to support Netflix content > even if Netflix moves to HTTPS delivery. We expect to see Netflix become > more active in the SVA soon given other major streaming providers, such as > Hulu and Amazon, are joining now. > > In conclusion, the SVA has developed a solution for Open Cache support of > HTTPS streaming and we expect all streaming providers, including Netflix, > will align with the SVA's direction. > > http://www.streamingvideoalliance.org/ > > Let me know if you have any more questions. > > Regards, > > > > Luke Guillory > Network Operations Manager > > Tel: 985.536.1212 > Fax: 985.536.0300 > Email: lguillory(a)reservetele.com > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > ____________________________________________________________ > _____________________________________ > > Disclaimer: > The information transmitted, including attachments, is intended only for > the person(s) or entity to which it is addressed and may contain > confidential and/or privileged material which should not disseminate, > distribute or be copied. Please notify Luke Guillory immediately by e-mail > if you have received this e-mail by mistake and delete this e-mail from > your system. E-mail transmission cannot be guaranteed to be secure or > error-free as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. Luke Guillory therefore does > not accept liability for any errors or omissions in the contents of this > message, which arise as a result of e-mail transmission. . > > -----Original Message----- > From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Keenan Singh > Sent: Tuesday, January 10, 2017 10:09 PM > To: nanog(a)nanog.org > Subject: Bandwidth Savings > > Hi Guys > > We are an ISP in the Caribbean, and are faced with extremely high > Bandwidth costs, compared to the US, we currently use Peer App for Caching > however with most services now moving to HTTPS the cache is proving to be > less and less effective. We are currently looking at any way we can save on > Bandwidth or to be more Efficient with the Bandwidth we currently have. We > do have a Layer 2 Circuit between the Island and Miami, I am seeing there > are WAN Accelerators where they would put a Server on either end and sort > of Compress and decompress the Traffic before it goes over the Layer 2, I > have never used this before, has any one here used anything like this, what > results would I be able to expect for ISP Traffic? > > If not any ideas on Bandwidth Savings, or being more Efficient with want > we currently. > > Many thanks for any Help > > Keenan > >

1 0