May 2016 - Test - lists.nanog.org

Comcast DNS Contact
by rwebb＠ropeguru.com 17 May '16

17 May '16

Can one of the Comcast DNS guru's contact me reference an issue with a .gov resolution? Robert

2 3

Perspectives about customer M/A/C in triple play environments
by Jason Lixfeld 17 May '16

17 May '16

Hello, I think it’s fair to say that most broadband/FTTx customers don’t have to think very much or need to have a very high degree of understanding if they want to move their wired Internet device from one room or another in their house. Maybe to keep things simple, let’s assume that we’re talking about a relatively modern MDU unit where a customer has some sort of provider CPE in their in-suite telecom demark closet/box/what have you with some number of switched 'LAN’ ports on it, and each of those LAN ports would be wired to a wall jack somewhere. Mr. or Ms. User can move their Internet device anywhere there is a wall jack and Bob’s your uncle. My question is around how this landscape changes in triple play environments. As I understand it, most triple play deployments separate (in some cases VoIP,) TV and Internet traffic onto VLANs (Internet would be presented to the customer untagged). The CPE would then allow the ISP to switch the video traffic onto a coax port, or maybe onto the CPE’s embedded switch, or maybe both. For the sake of argument, let’s assume the provider is supplying an Ethernet based set-top-box, so customer should be able to connect the STB to any wall jack and it should just work. And they should be able to connect their provider supplied ATA to any wall jack, and it should just work. And they should be able to connect their Internet device to any wall jack and it should just work. Or should it? Are most CPEs that are provided by ISPs sophisticated enough to be able to put all service tags on all ports, and have those same ports act as untagged LAN ports as well? If not, how do providers deal with this? Do they dedicate one port for an IPTV STB? One port for an ATA (assuming no built-in POTS on the CPE)? And the rest of the ports for untagged Internet? What if the customer has 2+ TVs? Do they need to call in and have the provider remote in and provision another port for TV at the expense of some other service that might be running on that port already? Do they need to install a switch that does IGMP snooping? I feel like this all has the potential to become very complicated for the customer, and maybe the provider and their installers. To me, the customer should continue to be dumb and unassuming. They should be able to put whatever they want wherever they want and have it just work. Is that how things actually are in the real world or are customers and providers making silent sacrifices for the sake of all this new fangled technology?

4 3

Level 3 issues?
by David Hubbard 16 May '16

16 May '16

Anyone seeing issues with Level 3 networking right now? We’re seeing huge latency and loss on traffic coming inbound (to us, AS33260) but it seems to be at the peering points with other major ISP’s and Level 3. Comcast for example: 3 33 ms 21 ms 70 ms te-3-5-ur01.hershey.pa.pitt.comcast.net [68.85.42.29] 4 * 33 ms 106 ms 162.151.48.173 5 214 ms 54 ms 41 ms 162.151.21.229 6 561 ms 764 ms 459 ms 4.68.71.133 Thanks, David

6 6

Cost-effectivenesss of highly-accurate clocks for NTP
by esr＠thyrsus.com 16 May '16

16 May '16

Mel Beckman <mel(a)beckman.org>: >Finally, do you want to weigh in on the necessity for highly accurate local RT >clocks in NTP servers? That seems to be the big bugaboo in cost limiting right >now. Yes, this is a topic on which I have some well-developed judgments due to having collected (and, where practical, tested) a pretty comprehensive set of figures on components of the NTP error budget. I've even invented some hardware that simplifies the problem. The background to my findings is laid out in my "Introduction to Time Service" HOWTO: http://www.catb.org/gpsd/time-service-intro.html I find that an effective way to learn my way into a new application domain is to first do knowledge capture on the assumptions its experts are using and then document those. "Introduction to Time Service" was written to do that and as a white paper for my project management. Criticism and corrections are, of course, welcome. In order to discuss the value of accurate clocks intelligently, we need to split apart two issues: accuracy and availability. Of course we want the most accurate time our networks can deliver; we also want to hedge against sporadic or systemic failure of single time sources. The most important simplification of either issue is that clock accuracy worth paying for is bounded both by user expectations and the noise floor defined by our network jitter. According to RFC 5095 expected accuracy of NTP time is "several tens of milliseconds." User expectations seem to evolved to on the close order of 10ms. I think it's not by coincidence this is pretty close to the jitter in ping times I see when I bounce ICMP off a well-provisioned site like (say) google.com through my Verizon FIOS connection. It's good rule-of-thumb engineering that if you want to be metrologically accurate you should pay for precision an order of magnitude below your feature size *and not more than that*. Thus, with a feature size of 10ms the economic sweet spot is a clock with accuracy about 1ms. One reason discussions of how to budget for WAN timeservice clocks has tended to become heated in the past is that nothing inexpensive hit this sweet spot. The world was largely divided between cheap time sources with too much jitter (e.g. GPS in-band data with a wander of 100ms or worse) and expensive high-precision clocks designed for PTP over Ethernet that deliver three or more orders of magnitude than WAN time service can actually use. However...also use the 1PPS signal your GPS engine ships (top of UTC second accurate to about 50ns) and the picture changes completely. With that over RS232 your delivered accuracy rises to single-digit numbers of microseconds, which is two orders of magnitude below what you need for your 1ms goal. Now we have a historical problem, though: RS232 and the handshake lines you could use to signal 1PPS are dying, being replaced by USB. which doesn't normally bring 1PPS out to where the timeserver OS can see it. In 2012, nearly three years before being recruited for NTPsec, I solved this problem as part of my work on GPSD. The key to this solution is an obscure feature of USB, and a one-wire patch to the bog-standard design for generic USB that exploits it. Technical details on request, but what it comes down to is that with this one weird trick(!) you can mass-produce primary time sources with a jitter bounded by the USB polling interval for about $20 a pop. The USB 1 polling interval is 1ms. Bingo. We're done. If we're only weighting accuracy and not availability, a USB GPS is as much clock as you need for WAN timeservice *provided it exposes 1PPS*. These devices exist, because I designed them and found a shop in Shenzhen to build them. They're called the Navisys GR-601W, GR-701W, and GR-801W. (A viable, only skightly more expensive alternative is to mate a GPS daughterboard to a hackerboard like the Raspberry Pi and run NTP service on that. I'll have much, much more to say about that in a future post.) Of course, now we have to talk about availability. GPS sometimes loses lock. There are sporadic and systemic availability risks due to jamming and system failures like the 2012 hiccup, and extreme scenarios like a giant meteorite hitting GPSS ground control in Colorado. What you should be willing to pay for a hedge against this is proportional to your 95% confidence estimate of the maximum outage interval. At the low end, this is simple; put your antenna on a mast that guarantees unobstructed skyview. At the high end it's effectively impossible, in that anything that takes down GNSS and Galileo permanently (giant meteor impact, war in space, collapse of the U.S. and Europe) is likely to be in the you-have-much-bigger- problems than-inaccurate-time department. Traditionally dedicated time-source hardware like rubidium-oscillator GPSDOs is sold on accuracy, but for WAN time service their real draw is long holdover time with lower frequency drift that you get from the cheap, non-temperature-compensated quartz crystals in your PC. There is room for debate about how much holdover you should pay for, but you'll at least be thinking more clearly about the problem if you recognize that you *should not* buy expensive hardware for accuracy. For WAN time service, in that price range, you're wither buying holdover and knowing you're doing so or wasting your money. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> Everything you know is wrong. But some of it is a useful first approximation.

13 20

SAFNOG-3: Call for Papers!
by Mark Tinka 16 May '16

16 May '16

Hello all. This is just to remind you that the Call for Papers (CfP) for SAFNOG-3 is open. If you are interested in participating in SAFNOG-3 as a speaker or panelist in Windhoek, Namibia, kindly review the details of the CfP and submit your talk at the link below: http://www.safnog.org/#callforpapers We look forward to receiving your submission, and working with you to develop it into a topic that the community will find interesting and informative. Cheers, Mark Tinka On Behalf of the SAFNOG Management Committee

1 0

NIST NTP servers
by b f 14 May '16

14 May '16

Hello List, In search of stable, disparate stratum 1 NTP sources. Looking for anyone’s advice/experiences (good/bad/ugly/weird) using NIST’s NTP servers per: http://tf.nist.gov/tf-cgi/servers.cgi We tried using “time.nist.gov” which returns varying round-robin addresses (as the link says), but Cisco IOS resolved the FQDN and embedded the numeric address in the “ntp server” config statement. After letting the new server config go through a few days of update cycles, the drift, offset and reachability stats are not anywhere as good as what the stats for the Navy time server are - 192.5.41.41 / tock.usno.navy.mil. I would greatly appreciate and feedback / advice, etc. Thanks!!! Ed

40 86

[NANOG-announce] NOTR - Thank you Denver, CO and Announcing NYC
by Valerie Wittkop 13 May '16

13 May '16

We extend a very big Thank You to Denver, CO for such a successful NOTR event on Tuesday. Great presentations and a large crowd made the day great for everyone! We are very excited to be holding the next NOTR event in New York City <https://www.nanog.org/meetings/road12/home>NOTR event in N <http://nanog.org/meetings/road12/home>ew York City on July 21, 2016, in partnership with NYNOG <http://www.nynog.org/>, and we invite you to join us! Are you interested in Internet networking/peering? Do you work at a colocation, hosting or data center facility? Are you a provider of hardware/software solutions for the Internet industry? If so, the NANOG On The Road NYC event is perfect for you! Date: July 21, 2016 Time: Registration Desk opens at 8:30am and Program is from 9:00 AM - 5:00 PM Location: New York Marriott Marquis <https://www.nanog.org/meetings/road12/hotel>N <http://nanog.org/meetings/road11/hotel>ew York Marriott Marquis - 1535 Broadway, New York, NY 10036 The FREE to attend event is open for registration. Register Now! <https://www.cvent.com/events/notr-nyc/registration-242cde760691478cbd115fa8…> Agenda Topics <http://nanog.org/meetings/road11/agenda> are posted, which include: - Life After IPv4 - Traceroute Tutorial - IPv6 Tutorial - BGP Tutorial If you are, or will be, in the New York City area, we invite you to attend. And don’t forget to attend NYNOG’s Meetup #1 on May 25, 2016. Click here <http://www.nynog.org/> for more information about their event. Learn more about On The Road events here <https://www.nanog.org/meetings/road/home>. Feel free to contact us at nanog-support(a)nanog.org <mailto:nanog-support@nanog.org> if you have any questions. Regards, Valerie Valerie Wittkop NANOG Program Director Tel: +1 866 902 1336, ext 103 _______________________________________________ NANOG-announce mailing list NANOG-announce(a)mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce

1 0

Weekly Routing Table Report
by Routing Analysis Role Account 13 May '16

13 May '16

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, SAFNOG, PaNOG, 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 14 May, 2016 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 593720 Prefixes after maximum aggregation (per Origin AS): 217775 Deaggregation factor: 2.73 Unique aggregates announced (without unneeded subnets): 290742 Total ASes present in the Internet Routing Table: 53727 Prefixes per ASN: 11.05 Origin-only ASes present in the Internet Routing Table: 36600 Origin ASes announcing only one prefix: 15688 Transit ASes present in the Internet Routing Table: 6437 Transit-only ASes present in the Internet Routing Table: 171 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 39 Max AS path prepend of ASN ( 40285) 33 Prefixes from unregistered ASNs in the Routing Table: 1414 Unregistered ASNs in the Routing Table: 444 Number of 32-bit ASNs allocated by the RIRs: 13845 Number of 32-bit ASNs visible in the Routing Table: 10690 Prefixes from 32-bit ASNs in the Routing Table: 42050 Number of bogon 32-bit ASNs visible in the Routing Table: 3 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 386 Number of addresses announced to Internet: 2811463492 Equivalent to 167 /8s, 147 /16s and 135 /24s Percentage of available address space announced: 75.9 Percentage of allocated address space announced: 75.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.1 Total number of prefixes smaller than registry allocations: 193775 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 151912 Total APNIC prefixes after maximum aggregation: 42356 APNIC Deaggregation factor: 3.59 Prefixes being announced from the APNIC address blocks: 162829 Unique aggregates announced from the APNIC address blocks: 66401 APNIC Region origin ASes present in the Internet Routing Table: 5177 APNIC Prefixes per ASN: 31.45 APNIC Region origin ASes announcing only one prefix: 1181 APNIC Region transit ASes present in the Internet Routing Table: 913 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 39 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2070 Number of APNIC addresses announced to Internet: 755234628 Equivalent to 45 /8s, 3 /16s and 247 /24s Percentage of available APNIC address space announced: 88.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 181169 Total ARIN prefixes after maximum aggregation: 89627 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 186526 Unique aggregates announced from the ARIN address blocks: 88714 ARIN Region origin ASes present in the Internet Routing Table: 16363 ARIN Prefixes per ASN: 11.40 ARIN Region origin ASes announcing only one prefix: 5835 ARIN Region transit ASes present in the Internet Routing Table: 1713 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 36 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1199 Number of ARIN addresses announced to Internet: 1101775680 Equivalent to 65 /8s, 171 /16s and 195 /24s Percentage of available ARIN address space announced: 58.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-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: 142528 Total RIPE prefixes after maximum aggregation: 70293 RIPE Deaggregation factor: 2.03 Prefixes being announced from the RIPE address blocks: 151781 Unique aggregates announced from the RIPE address blocks: 93519 RIPE Region origin ASes present in the Internet Routing Table: 18087 RIPE Prefixes per ASN: 8.39 RIPE Region origin ASes announcing only one prefix: 7914 RIPE Region transit ASes present in the Internet Routing Table: 3016 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 29 Number of RIPE region 32-bit ASNs visible in the Routing Table: 4740 Number of RIPE addresses announced to Internet: 704636544 Equivalent to 41 /8s, 255 /16s and 230 /24s Percentage of available RIPE address space announced: 102.4 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-204287 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 61743 Total LACNIC prefixes after maximum aggregation: 12246 LACNIC Deaggregation factor: 5.04 Prefixes being announced from the LACNIC address blocks: 76062 Unique aggregates announced from the LACNIC address blocks: 35972 LACNIC Region origin ASes present in the Internet Routing Table: 2475 LACNIC Prefixes per ASN: 30.73 LACNIC Region origin ASes announcing only one prefix: 576 LACNIC Region transit ASes present in the Internet Routing Table: 558 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 23 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 2469 Number of LACNIC addresses announced to Internet: 170943808 Equivalent to 10 /8s, 48 /16s and 101 /24s Percentage of available LACNIC address space announced: 101.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 14214 Total AfriNIC prefixes after maximum aggregation: 3215 AfriNIC Deaggregation factor: 4.42 Prefixes being announced from the AfriNIC address blocks: 16136 Unique aggregates announced from the AfriNIC address blocks: 5791 AfriNIC Region origin ASes present in the Internet Routing Table: 738 AfriNIC Prefixes per ASN: 21.86 AfriNIC Region origin ASes announcing only one prefix: 182 AfriNIC Region transit ASes present in the Internet Routing Table: 168 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 212 Number of AfriNIC addresses announced to Internet: 78489600 Equivalent to 4 /8s, 173 /16s and 168 /24s Percentage of available AfriNIC address space announced: 78.0 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 5558 4192 76 China Education and Research 7545 3307 354 213 TPG Telecom Limited 4766 3167 11145 1123 Korea Telecom 17974 2937 914 96 PT Telekomunikasi Indonesia 9829 2469 1467 464 National Internet Backbone 4755 2095 432 243 TATA Communications formerly 9808 1928 8717 30 Guangdong Mobile Communicatio 4808 1659 2299 551 CNCGROUP IP network China169 9583 1512 122 562 Sify Limited 38197 1501 93 215 Sun Network (Hong Kong) Limit 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 3250 2947 137 Cox Communications Inc. 6389 2301 3671 41 BellSouth.net Inc. 18566 2204 394 275 MegaPath Corporation 20115 1920 1937 403 Charter Communications 30036 1722 342 356 Mediacom Communications Corp 6983 1689 849 232 EarthLink, Inc. 209 1613 4680 1267 Qwest Communications Company, 4323 1519 985 376 tw telecom holdings, inc. 16625 1314 484 694 Akamai Technologies, Inc. 701 1296 10718 704 MCI Communications Services, 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 2901 151 11 SaudiNet, Saudi Telecom Compa 20940 2544 981 1835 Akamai International B.V. 34984 1964 326 357 TELLCOM ILETISIM HIZMETLERI A 8551 1228 376 55 Bezeq International-Ltd 12479 1202 996 88 France Telecom Espana SA 6849 1148 355 21 JSC "Ukrtelecom" 13188 1078 98 65 TOV "Bank-Inform" 8402 1028 544 15 OJSC "Vimpelcom" 31148 1026 47 45 Freenet Ltd. 9198 939 352 25 JSC Kazakhtelecom 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 3479 542 134 Telmex Colombia S.A. 8151 2243 3406 563 Uninet S.A. de C.V. 7303 1511 940 234 Telecom Argentina S.A. 11830 1481 368 52 Instituto Costarricense de El 6503 1475 437 55 Axtel, S.A.B. de C.V. 6147 1158 377 27 Telefonica del Peru S.A.A. 26615 1016 2325 34 Tim Celular S.A. 3816 997 478 186 COLOMBIA TELECOMUNICACIONES S 7738 994 1882 40 Telemar Norte Leste S.A. 11172 905 125 77 Alestra, S. de R.L. de C.V. 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 1261 402 45 Link Egypt (Link.NET) 37611 648 48 2 Afrihost-Brevis Computer Serv 36903 625 314 106 Office National des Postes et 36992 511 1357 26 ETISALAT MISR 8452 505 1471 15 TE-AS 37492 395 234 68 Orange Tunisie 24835 329 402 15 Vodafone Data 29571 301 37 13 Cote d'Ivoire Telecom 2018 257 327 74 TENET (The UNINET Project) 36947 240 807 13 Telecom Algeria 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 5558 4192 76 China Education and Research 10620 3479 542 134 Telmex Colombia S.A. 7545 3307 354 213 TPG Telecom Limited 22773 3250 2947 137 Cox Communications Inc. 4766 3167 11145 1123 Korea Telecom 17974 2937 914 96 PT Telekomunikasi Indonesia 39891 2901 151 11 SaudiNet, Saudi Telecom Compa 20940 2544 981 1835 Akamai International B.V. 9829 2469 1467 464 National Internet Backbone 6389 2301 3671 41 BellSouth.net Inc. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 10620 3479 3345 Telmex Colombia S.A. 22773 3250 3113 Cox Communications Inc. 7545 3307 3094 TPG Telecom Limited 39891 2901 2890 SaudiNet, Saudi Telecom Compa 17974 2937 2841 PT Telekomunikasi Indonesia 6389 2301 2260 BellSouth.net Inc. 4766 3167 2044 Korea Telecom 9829 2469 2005 National Internet Backbone 18566 2204 1929 MegaPath Corporation 9808 1928 1898 Guangdong Mobile Communicatio 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 OJSC Rostelecom 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 16589 UNALLOCATED 8.20.247.0/24 35838 CCANET Limited 16589 UNALLOCATED 8.26.56.0/24 35838 CCANET Limited 46473 UNALLOCATED 8.27.122.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.124.0/24 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.16.0/21 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.20.0/24 32787 Prolexic Technologie Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.190.0.0/24 63393 BOOM NET 23.226.112.0/20 62788 >>UNKNOWN<< 23.249.144.0/20 40430 colo4jax, LLC 27.100.7.0/24 56096 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.3.0/24 37004 >>UNKNOWN<< 41.73.4.0/24 37004 >>UNKNOWN<< 41.73.5.0/24 37004 >>UNKNOWN<< 41.73.6.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:101 /12:267 /13:509 /14:1037 /15:1761 /16:13022 /17:7635 /18:12747 /19:25946 /20:37976 /21:39776 /22:65656 /23:57370 /24:328155 /25:554 /26:597 /27:421 /28:46 /29:32 /30:14 /31:1 /32:32 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2664 2901 SaudiNet, Saudi Telecom Compa 22773 2478 3250 Cox Communications Inc. 18566 2106 2204 MegaPath Corporation 30036 1536 1722 Mediacom Communications Corp 6389 1477 2301 BellSouth.net Inc. 10620 1370 3479 Telmex Colombia S.A. 6983 1338 1689 EarthLink, Inc. 34984 1248 1964 TELLCOM ILETISIM HIZMETLERI A 11492 1193 1289 CABLE ONE, INC. 6849 968 1148 JSC "Ukrtelecom" Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1578 2:728 4:21 5:2070 6:28 8:955 12:1776 13:39 14:1684 15:45 16:2 17:84 18:89 20:48 23:1593 24:1772 27:2273 31:1765 32:59 33:2 34:2 35:5 36:303 37:2297 38:1217 39:28 40:91 41:2849 42:395 43:1757 44:42 45:1843 46:2518 47:79 49:1166 50:872 51:34 52:181 54:329 55:6 56:6 57:42 58:1541 59:866 60:347 61:1822 62:1477 63:1919 64:4441 65:2155 66:4246 67:2153 68:1088 69:3284 70:1101 71:469 72:1990 74:2543 75:344 76:348 77:1369 78:1264 79:839 80:1267 81:1348 82:952 83:697 84:815 85:1581 86:474 87:1052 88:561 89:1995 90:174 91:6063 92:899 93:2334 94:2338 95:2313 96:518 97:358 98:935 99:46 100:74 101:1046 103:10738 104:2466 105:123 106:398 107:1166 108:669 109:2187 110:1249 111:1654 112:989 113:1143 114:1046 115:1576 116:1579 117:1428 118:2050 119:1617 120:932 121:1176 122:2160 123:2008 124:1568 125:1717 128:690 129:402 130:407 131:1327 132:636 133:176 134:453 135:126 136:374 137:352 138:1716 139:261 140:543 141:458 142:641 143:923 144:694 145:157 146:867 147:637 148:1473 149:505 150:647 151:877 152:579 153:281 154:624 155:944 156:493 157:415 158:355 159:1120 160:480 161:708 162:2332 163:560 164:900 165:1056 166:318 167:1148 168:1804 169:660 170:1569 171:263 172:553 173:1645 174:742 175:737 176:1738 177:3971 178:2209 179:1157 180:2055 181:1776 182:1894 183:949 184:808 185:6373 186:2996 187:2134 188:2127 189:1723 190:7731 191:1249 192:8947 193:5736 194:4377 195:3767 196:1695 197:1038 198:5558 199:5713 200:6967 201:3725 202:10118 203:9635 204:4519 205:2727 206:2978 207:3122 208:4053 209:3840 210:3912 211:2053 212:2695 213:2232 214:852 215:71 216:5787 217:1941 218:792 219:593 220:1680 221:870 222:664 223:1222 End of report

1 0

A briefing on NTPsec
by esr＠thyrsus.com 13 May '16

13 May '16

Jay Ashworth informs me that NTP security and risks has recently been a hot topic on NANOG, and that NTPsec was mentioned. Therefore I've written a bit of a background briefing on the project, which follows. The NTPsec project was initially funded in late 2014 by NSF when authorities there became concerned about frequent incidents of DDoS amplification involving ntpd. I was hired in as tech lead early on (in part because of my work on GPSD, a technically similar project) and retained that position when the Linux Foundation picked up funding the project. It's now managed by Mark Atwood, who some of you may know from HPE and OpenStack. I'm going to pass over the politics around the fork from what our team now calls "NTP Classic" because it wasn't my decision or desire, merely observing that I reluctantly acknowledged the necessity and wish things could have been otherwise. The goal of NTPsec is to achieve high security and high assurance through systematic application of modern best practices. Though not yet at release 1.0, our progress can be judged by the fact that when the last batch of 11 CVEs against NTP was released, we were not vulnerable to 8 of them because we had previously removed or successfully hardened the code they exploited. This was no fluke. Over the last 11 months, we have compiled a significantly - I think it's fair to say "dramatically" - better security record than Classic. We've earned some trust in the infosec research community, working effectively with (among others) Sharon Goldberg's group at BU. We were the first to develop a verified fix for the now infamous off-path KOD bug (CVE-2015-7979). You can read more about our code-hardening practices here: http://esr.ibiblio.org/?p=6881 In brief, we've thrown out a lot of cruft and archaisms. The code has been lifted to C99/POSIX-2001 conformance; other than a few warts near Mac OS X and some unused Windows code probably destined for removal itself, the port shims that used to infest the codebase are nearly gone. Mode 7 has been removed, as has Autokey; these were nests of bugs too risky to leave in. We've also done a lot of code auditing using tools like Coverity and cppcheck, and worked hard on improving our test coverage (that part has been more difficult than any of the code changes, actually, and is still very much a work in progress). Here's a figure that should tell you a lot: we removed 57% of the original codebase in the process of cleaning it up. No, that's not a typo; the NTPsec codebase is *less than half* the size of NTP Classic. And much, much easier to read. That's even without counting the huge simplification win from ditching autotools. Nevertheless, sysdamins will find it very familiar. The largest speedbump you will encounter in normal operation is that we've changed the names of some auxiliary tools so everything has an "ntp" prefix. The only thing I expect to actually surprise you is the documentation, which has been greatly improved, specifically by removing duplications and inconsistencies and distracting references to equipment that has been dead since the Late Cretaceous. So far this is a deliberately conservative fork. We haven't yet tried to add protocol features for security because there is plenty of useful work to be done before tackling that very hard problem. We're actively cooperating with the IETF NTP WG (we've committed to supplying second interop for some upcoming draft RFCs) and we're watching the work on NTS closely. It is likely, though not yet certain, that we'll be second interop on that. Finally, I note some criticism that NTPsec is short on people who understand all the subtleties of time service in the field. This is partly justified. The tech lead admits to being something of a newbie; though I know a lot about some adjacent technical areas from ten years of leading GPSD, I was not a time-service expert before being engaged for this project and am still coming up to speed. The team does already include one time-service old hand and a really good crypto/infosec specialist. NANOG listmember Gary E. Miller was an early team member who remains a friend of the project. We would certainly welcome more engagement and advice fom time-service experts, and the sort of experienced sysadmins who frequent NANOG. In a future post I may have a bit to say about Stratum 1s based on the RPi and other hackerboards. I've been working in that area as well. I'll be happy to answer technical and procedural questions about NTPsec. Any questions about politics and policy should go to Mark Atwood. See www.ntpsec.org for more information. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

3 2

A briefing on NTPsec
by esr＠thyrsus.com 13 May '16

13 May '16

Jay Ashworth informs me that NTP security and risks has recently been a hot topic on NANOG, and that NTPsec was mentioned. Therefore I've written a bit of a background briefing on the project, which follows. The NTPsec project was initially funded in late 2014 by NSF when authorities there became concerned about frequent incidents of DDoS amplification involving ntpd. I was hired in as tech lead early on (in part because of my work on GPSD, a technically similar project) and retained that position when the Linux Foundation picked up funding the project. It's now managed by Mark Atwood, who some of you may know from HPE and OpenStack. I'm going to pass over the politics around the fork from what our team now calls "NTP Classic" because it wasn't my decision or desire, merely observing that I reluctantly acknowledged the necessity and wish things could have been otherwise. The goal of NTPsec is to achieve high security and high assurance through systematic application of modern best practices. Though not yet at release 1.0, our progress can be judged by the fact that when the last batch of 11 CVEs against NTP was released, we were not vulnerable to 8 of them because we had previously removed or successfully hardened the code they exploited. This was no fluke. Over the last 11 months, we have compiled a significantly - I think it's fair to say "dramatically" - better security record than Classic. We've earned some trust in the infosec research community, working effectively with (among others) Sharon Goldberg's group at BU. We were the first to develop a verified fix for the now infamous off-path KOD bug (CVE-2015-7979). You can read more about our code-hardening practices here: http://esr.ibiblio.org/?p=6881 In brief, we've thrown out a lot of cruft and archaisms. The code has been lifted to C99/POSIX-2001 conformance; other than a few warts near Mac OS X and some unused Windows code probably destined for removal itself, the port shims that used to infest the codebase are nearly gone. Mode 7 has been removed, as has Autokey; these were nests of bugs too risky to leave in. We've also done a lot of code auditing using tools like Coverity and cppcheck, and worked hard on improving our test coverage (that part has been more difficult than any of the code changes, actually, and is still very much a work in progress). Here's a figure that should tell you a lot: we removed 57% of the original codebase in the process of cleaning it up. No, that's not a typo; the NTPsec codebase is *less than half* the size of NTP Classic. And much, much easier to read. That's even without counting the huge simplification win from ditching autotools. Nevertheless, sysdamins will find it very familiar. The largest speedbump you will encounter in normal operation is that we've changed the names of some auxiliary tools so everything has an "ntp" prefix. The only thing I expect to actually surprise you is the documentation, which has been greatly improved, specifically by removing duplications and inconsistencies and distracting references to equipment that has been dead since the Late Cretaceous. So far this is a deliberately conservative fork. We haven't yet tried to add protocol features for security because there is plenty of useful work to be done before tackling that very hard problem. We're actively cooperating with the IETF NTP WG (we've committed to supplying second interop for some upcoming draft RFCs) and we're watching the work on NTS closely. It is likely, though not yet certain, that we'll be second interop on that. Finally, I note some criticism that NTPsec is short on people who understand all the subtleties of time service in the field. This is partly justified. The tech lead admits to being something of a newbie; though I know a lot about some adjacent technical areas from ten years of leading GPSD, I was not a time-service expert before being engaged for this project and am still coming up to speed. The team does already include one time-service old hand and a really good crypto/infosec specialist. NANOG listmember Gary E. Miller was an early team member who remains a friend of the project. We would certainly welcome more engagement and advice fom time-service experts, and the sort of experienced sysadmins who frequent NANOG. In a future post I may have a bit to say about Stratum 1s based on the RPi and other hackerboards. I've been working in that area as well. I'll be happy to answer technical and procedural questions about NTPsec. Any questions about politics and policy should go to Mark Atwood. See www.ntpsec.org for more information. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> This would be the best of all possible worlds, if there were no religion in it. -- John Adams, in a letter to Thomas Jefferson.

1 0