January 2019 - Test - lists.nanog.org

Google Fiber v6 PD only giving /64
by Chris Adams 10 Jan '19

10 Jan '19

Anybody here from Google Fiber? When I first got it last year, my IPv6 setup got a /56 prefix delegated. I now see that no matter what size I request, I only get a /64. Is this intentional? -- Chris Adams <cma(a)cmadams.net>

3 2

Proofpoint Mail Delivery Issues
by Tim Donahue 10 Jan '19

10 Jan '19

Hi all, Sorry for the noise, but one of my clients is getting the standard "it's the other guy's fault" with some email delivery issues to/from Proofpoint "Enterprise" customers. If there is anyone from Proofpoint support monitoring this list, some assistance troubleshooting email delivery issues would be greatly appreciated. Thank you, Tim Donahue

7 6

Call for presentations RIPE 78
by Benno Overeinder 10 Jan '19

10 Jan '19

Dear colleagues, Please find the CFP for RIPE 78 below or at: https://ripe78.ripe.net/submit-topic/cfp/. The deadline for submissions is *3 March 2019*. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings. However, on an individual basis, participants can apply for a RIPE Fellowship or RACI, see the "Speakers" paragraph in CFP for more information. Kind regards, Benno Overeinder RIPE PC Chair https://ripe78.ripe.net/ripe-pc/ -------------------->>><<<-------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. *RIPE 78 will take place from 20-24 May in Reykjavik, Iceland* The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 78. See the full descriptions of the different presentation formats: https://ripe78.ripe.net/submit-topic/presentation-formats/ Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than *3 March 2019*. Proposals submitted after this date will be considered depending on the slots still available in the programme. The PC is looking for presentations covering the topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange - Connected Things (aka. Internet of Things - IoT) ---- Speakers ---- Presenters, RIPE Working Group Chairs and the RIPE Programme Committee are required to cover their own costs to attend a RIPE Meeting (meeting ticket, travel and accommodation). We have various ticket options available depending on your needs. Please note that participants can apply for a RIPE Fellowship or RACI, on an individual basis, to develop their professional or academic career. For more information, please visit: https://www.ripe.net/participate/ripe/ripe-fellowship https://www.ripe.net/participate/ripe/raci In extraordinary circumstances, the RIPE Chair can waive the meeting fee for presenters. These requests are dealt with on a case-by-case basis via pc(a)ripe.net. ---- Submissions ---- Presenters should be clear on whether they wish to submit a presentation for a plenary or working group (WG) session. At present, most working groups will solicit policy proposals, discussion points or other content directly via their mailing lists. If you’re not sure what kind of session you should be presenting at, please visit: https://ripe78.ripe.net/plenary-or-wg/ RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and should not attempt a product demonstration. Presenters should indicate how much time they will require. In general, the time allocated for the different presentation formats is as follows: - Plenary presentations: 20-25 minutes presentation with 5-10 minutes discussion - Tutorials: up to two hours (Monday morning) - Workshops: one hour (during evening sessions) to two hours (Monday morning) - BoFs: approximately one hour (during evening sessions) - Lightning talks: 10 minutes in total for both the presentation and any discussion The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe78.ripe.net/submit-topic/ - Lightning talks should also be submitted using the meeting submission system (https://ripe78.ripe.net/submit-topic/) and can be submitted any time up to and including the meeting week. The allocation of lightning talks will be announced on short notice, in some cases on the same day but often one day prior to the time slot allocated. - Presenters who propose a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. - All presentation proposals will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. ---- Diversity and Inclusion - On-Site Childcare and the RIPE Meeting Code of Conduct ---- Did you know that RIPE Meetings now have on-site childcare? You can reserve a spot for your child (age 6 months - 10 years) during the registration process for the meeting. Childcare places are limited, so please be quick to reserve a spot for your child while registering for the meeting. More information at: https://ripe78.ripe.net/on-site/on-site-childcare/ Ensuring that RIPE Meeting values are upheld and that attendees experience a professional, respectful and safe meeting is a priority. Please do read the RIPE Meeting Code of Conduct: https://www.ripe.net/participate/meetings/ripe-meetings/ripe-meeting-code-o… --- If you have any questions or requests concerning content submissions, please email pc(a)ripe.net.

1 0

DNS Hijacking? - FiOS Northeast
by Blake Mckeeby 10 Jan '19

10 Jan '19

We are seeing DNS requests for A and AAAA to 8.8.8.8 come back with erroneous replies resolving to 146.112.61.106 when sent via FiOS circuits in the northeast. Anyone else seeing issues with DNS on FiOS in Northeast? Issue started around 12:25 AM ET this morning and seems to be affecting customers in PA, RI, etc.. -- Sincerely, Blake McKeeby

4 3

Centurylink/Level3 WDM?
by James Breeden 09 Jan '19

09 Jan '19

Anyone else having issues with Centurylink IP (Legacy Level3/3356) in/around Houston, or WDM issues between Houston and San Antonio? James W. Breeden Managing Partner [logo_transparent_background] Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media PO Box 1063 | Smithville, TX 78957 Email: james(a)arenalgroup.co<mailto:james@arenalgroup.co> | office 512.360.0000 | cell 512.304.0745 | www.arenalgroup.co<http://www.arenalgroup.co/>

1 1

Report on Legal Barriers to RPKI Adoption
by Christopher S. Yoo 09 Jan '19

09 Jan '19

As many of you know, the prospects for widespread RPKI adoption grew more promising in 2018. Cloudflare issued route origin authorizations ("ROAs") to cover 25% of its prefixes, including its 1.1.1.1 resolver and DNS servers. NTT began treating RPKI ROAs as if they were IRR route(6)-objects. Google announced its intention to begin filtering routes in early 2019. The Mutually Agreed Norms for Routing Security now has over 100 network operators signed on. Still, as 2019 begins, many worry that legal issues are hindering RPKI adoption. This is especially true for North American networks, which have a comparatively low percentage of IPv4 space covered by ROAs, and whose ROAs are comparatively underutilized by parties using RPKI-based route origin validation ("ROV") to inform their routing decisions. My coauthor (David Wishnick) and I have spent the past year delving into the legal issues surrounding RPKI. Today, we are publicizing our report on how the network operator community should address these issues. It is available here<https://ssrn.com/abstract=3308619>. If you are interested in the future of routing security, we encourage you to read it (or its Executive Summary). We've tried to keep the legalese to a minimum. RPKI was a major topic of discussion at NANOG 74 and ARIN 42 in Vancouver. Going forward, we expect to continue a fruitful dialogue about how the network operator community can reduce the legal barriers to RPKI adoption. Here is a summary of our recommendations: On the ROV side of the equation, the principal legal hindrances have to do with the terms and conditions governing access to the RPKI repository offered by ARIN in its Relying Party Agreement ("RPA"), and in the manner it has employed to ensure the agreement is binding. Regarding ROV: 1. The goal of widespread ROV counsels in favor of ARIN reviewing its current approach to repository distribution, embodied in the RPA. We conclude that two paths would be reasonable. First, ARIN should consider dropping the RPA altogether. This would remove the most significant legal barriers to widespread utilization of the ARIN RPKI repository. Second, because the legal risks faced by ARIN in an RPA-free world are ultimately uncertain, it would also be reasonable for ARIN to maintain the RPA for the purposes of contractually allocating risks to the parties best positioned to reduce and mitigate them. If ARIN keeps the RPA, ARIN should consider removing the RPA's indemnification clause, instead relying solely on the RPA's disclaimers of warranties and limitations of liability, or at least reducing the indemnification clause's scope to eliminate the problem of moral hazard. 2. Developers of RPKI validation software should consider integrating acceptance of ARIN's RPA into their software workflows. ARIN recently enabled this possibility, and developers should deliberate on whether to capitalize on the opportunity. 3. The network operator community and ARIN should broadly publicize ARIN's policy of revising various RPA clauses for government entities that are prohibited from agreeing to them. 4. In addition to the important step ARIN has already taken to enable third-party software developers to integrate RPA acceptance into their software workflows, ARIN should consider reducing the barriers to third-party service development imposed by the RPA's prohibited conduct clause. Specifically, ARIN should consider methods for allowing approved developers to make use of RPKI information as an input into more sophisticated services. 5. Separately, ARIN should consider revising the prohibited conduct clause to allow broader distribution of information created with RPKI as an input for research and analysis purposes. 6. As a general alternative, the Internet community should consider whether to develop a separate corporate entity that would be responsible for operational aspects of RPKI repository provision. That corporation could conduct such activities for the North American region, or on a worldwide basis. Regarding the ROA-issuance side of the equation, the principal legal obstacles stem from the terms and conditions found in ARIN's Registration Services Agreement ("RSA"), Legacy Registration Services Agreement ("LRSA"), and RPKI Terms of Service. Regarding these, the report recommends the following: 1. ARIN should consider adopting a pathway to provide RPKI services that would explicitly refrain from altering the existing balance of property and transferability rights associated with IP address allocations. 2. The network operator community and ARIN should broadly publicize ARIN's policy of revising certain RSA/LRSA and RPKI Terms of Service clauses for government entities that are prohibited from agreeing to them. ARIN should also begin presenting the RPKI Terms of Service to newly-onboarded members alongside their RSA/LRSA, so that organizations spend less time dealing with legal issues overall. Separately, the report recommends that the network operator community consider whether to encourage companies and the federal government to include RPKI adoption in procurement best practices or requirements. In tandem with recommendations designed to encourage adoption, the report also makes two recommendations concerning operational readiness for widespread RPKI deployment. Specifically: 1. To reduce any legal risks associated with RPKI, the network operator community should focus on adopting operational best practices. No system is 100% reliable across all contingencies; as a result, operators should prepare for outages and other headaches. RPKI implementations should be resilient in the face of such contingencies. 2. The five RIRs should work to ensure readiness for widespread RPKI adoption and strive to publicize deeper details on their service-level intentions to the Internet community. This research is supported by NSF Award No. 1748362. The contents of the report represent our independent views, not those of the NSF. Any mistakes, of course, are also ours alone. Christopher S. Yoo John H. Chestnut Professor of Law, Communication, and Computer & Information Science Founding Director, Center for Technology, Innovation and Competition University of Pennsylvania Law School 3501 Sansom St. Philadelphia, PA 19104-6204 (215) 746-8772 (o) (215) 573-2025 (f) csyoo(a)law.upenn.edu<mailto:csyoo@law.upenn.edu> http://www.law.upenn.edu/faculty/csyoo/ For more information on the Center for Technology, Innovation and Competition, see https://www.law.upenn.edu/institutes/ctic/.

4 3

RE: BGP Experiment
by adamv0025＠netconsultings.com 08 Jan '19

08 Jan '19

> Steve Noble > Sent: Tuesday, January 8, 2019 6:42 PM > > There is no such thing as a fully RFC compliant BGP : > Which RFC do you mean 6286, 6608, 6793, 7606, 7607, 7705 or 8212 when you say fully RFC compliant BGP please? > https://www.juniper.net/documentation/en_US/junos/topics/reference/st > andards/bgp.html does not list 7606 > > Cisco Bug: CSCvf06327 - Error Handling for RFC 7606 not implemented for > NXOS > > This is as of today and a 2 second google search.. anyone running code from > before RFC 7606 (2015) would also not be compliant. > With regards to Revised Error Handling for BGP UPDATE Messages RFC 7606, My recollection is there was a very long discussion with working code preceding the various drafts as well as the final RFC standard. Regarding the Juniper case specifically a bit of googling reveals that: All Junos software releases built on or after 2009-06-29 have been enhanced to be more tolerant of malformed optional, transitive attributes. Releases containing the coding change specifically include: 9.1S2, 9.3R3, 9.6R1 and all subsequent releases (i.e. all releases built after 9.6R1). -so it's not quite black and white, there will be levels of protection available in current releases (albeit not fully compliant with RFC per se). Question is whether folks out there have it actually enabled. Oh and then there are bugs associated with the new feature (like the one in some versions of Junos which ,upon receiving malformed update won't bring the session down but rather the whole rpd if the bgp-error-tolerance feature is enabled ) adam

1 0

Spoofer Report for NANOG for Dec 2018
by CAIDA Spoofer Project 08 Jan '19

08 Jan '19

In response to feedback from operational security communities, CAIDA's source address validation measurement project (https://spoofer.caida.org) is automatically generating monthly reports of ASes originating prefixes in BGP for systems from which we received packets with a spoofed source address. We are publishing these reports to network and security operations lists in order to ensure this information reaches operational contacts in these ASes. This report summarises tests conducted within usa, can. Inferred improvements during Dec 2018: ASN Name Fixed-By 393422 NEWVISIONS-CNY 2018-12-10 20009 WADSNET 2018-12-11 7922 COMCAST-7922 2018-12-14 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Dec 2018: ASN Name First-Spoofed Last-Spoofed 40065 CNServersLLC 2016-05-01 2018-12-22 7029 WINDSTREAM 2016-06-21 2018-12-14 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2018-12-27 6128 CABLE-NET-1 2016-09-03 2018-12-22 20412 CLARITY-TELECOM 2016-09-30 2018-12-26 6181 FUSE-NET 2016-10-10 2018-12-27 15305 SYRINGANETWORKS 2016-10-21 2018-12-15 25787 ROWE-NETWORKS 2016-10-21 2018-12-28 174 COGENT-174 2016-10-21 2018-12-20 31857 PRIORITY-TERABIT 2016-10-25 2018-12-28 30341 SCTA-ASN 2016-10-31 2018-12-31 32440 LONI 2016-11-03 2018-12-20 33182 DimeNOC 2016-11-08 2018-12-28 12083 WOW-INTERNET 2016-11-09 2018-12-31 13427 SOFTCOM-INTERNET-COMMUNICATION 2016-11-14 2018-12-25 3549 LVLT-3549 2016-11-16 2018-12-13 21832 KELLINCOM-1 2017-02-03 2018-12-27 7122 MTS-ASN 2017-05-16 2018-12-24 701 UUNET 2017-06-14 2018-12-09 6461 ZAYO-6461 2017-06-21 2018-12-14 63296 AMARILLO-WIRELESS 2017-09-01 2018-12-26 7233 YAHOO-US 2017-09-07 2018-12-21 33523 ROWANUNIVERSITY 2017-10-29 2018-12-17 546 PARSONS-PGS-1 2017-11-20 2018-12-19 12222 AKAMAI 2018-02-14 2018-12-30 29384 Qatar-Foundation 2018-03-08 2018-12-26 23148 TERRENAP 2018-03-15 2018-12-26 8100 ASN-QUADRANET-GLOBAL 2018-04-06 2018-12-26 4201 ORST 2018-04-19 2018-12-27 11827 WSU 2018-04-19 2018-12-28 35911 BNQ-1 2018-06-06 2018-12-18 225 VIRGINIA 2018-06-18 2018-12-19 2381 WISCNET1 2018-09-04 2018-12-26 54804 CSMIII-BUNKIELA 2018-09-15 2018-12-30 33452 RW 2018-09-19 2018-12-27 20448 VPNTRANET-LLC 2018-09-20 2018-12-26 11215 LOGIXCOMM 2018-09-20 2018-12-13 11996 LOBOIS 2018-09-24 2018-12-27 19919 VSW 2018-10-23 2018-12-13 13825 TROYCABLE-NET 2018-11-21 2018-12-22 6453 AS6453 2018-12-11 2018-12-20 62957 HOSPITALITY-NETWORK 2018-12-30 2018-12-30 Further information for these tests where we received spoofed packets is available at: https://spoofer.caida.org/recent_tests.php?country_include=usa,can&no_block… Please send any feedback or suggestions to spoofer-info(a)caida.org

1 0

Changing upstream providers, opinions/thoughts on 123.net and cogent
by Aaron Henderson 08 Jan '19

08 Jan '19

I work for a rural ISP and the powers that be have been thinking about changing our upstream providers. The big names on the table right now are 123.net and Cogent. I, along with the people in my circle, do not have any experience with these providers and all we are getting is what sales are dishing us. I was hoping some of you here might have experience with these providers and could share your experiences and opinions. Thanks, A

5 4

Astronaut accidently calls 911 from space
by Sean Donelan 07 Jan '19

07 Jan '19

I was disappointed that it was just a misdial. I was looking forward to how IP geolocation worked with 9-1-1 calls from space. I always wondered how that altitude parameter in 911 packets was used. :-) https://www.newsweek.com/astronaut-accidentally-calls-911-space-1276892

2 1