- Test - lists.nanog.org

Scanning activity from 2620:96:a000::/48
by Tore Anderson 15 Jul '21

15 Jul '21

A couple of hours after midnight UTC, the control plane policers for unresolved traffic on a couple of our CE routers started being clogged with ping-scanning activity from 2620:96:a000::/48, which belongs to «Internet Measurement Research (SIXMA)» according to ARIN. Excerpt of this traffic (anonymised on our end): 11:21:05.016914 IP6 2620:96:a000::10 > 2001:db8:1234::f5:7a69: ICMP6, echo request, seq 0, length 16 11:21:05.016929 IP6 2620:96:a000::10 > 2001:db8:1234::12:ba74: ICMP6, echo request, seq 0, length 16 11:21:05.060045 IP6 2001:db8:1234::3 > 2620:96:a000::10: ICMP6, destination unreachable, unreachable address 2001:db8:1234::e7:f473, length 64 11:21:05.060060 IP6 2001:db8:1234::3 > 2620:96:a000::7: ICMP6, destination unreachable, unreachable address 2001:db8:1234::d4:c4a3, length 64 11:21:05.060419 IP6 2001:db8:1234::3 > 2620:96:a000::7: ICMP6, destination unreachable, unreachable address 2001:db8:1234::42:198a, length 64 11:21:05.064464 IP6 2620:96:a000::10 > 2001:db8:1234::4a:d4cd: ICMP6, echo request, seq 0, length 16 11:21:05.079645 IP6 2620:96:a000::10 > 2001:db8:1234::63:b58d: ICMP6, echo request, seq 0, length 16 11:21:05.097337 IP6 2620:96:a000::10 > 2001:db8:1234::24:1038: ICMP6, echo request, seq 0, length 16 11:21:05.111091 IP6 2620:96:a000::7 > 2001:db8:1234::8f:a126: ICMP6, echo request, seq 0, length 16 11:21:05.124112 IP6 2001:db8:1234::3 > 2620:96:a000::7: ICMP6, destination unreachable, unreachable address 2001:db8:1234::e6:70fc, length 64 11:21:05.124417 IP6 2001:db8:1234::3 > 2620:96:a000::10: ICMP6, destination unreachable, unreachable address 2001:db8:1234::bf:ca18, length 64 11:21:05.137509 IP6 2620:96:a000::10 > 2001:db8:1234::12:f0df: ICMP6, echo request, seq 0, length 16 11:21:05.142614 IP6 2620:96:a000::7 > 2001:db8:1234::8f:9ec6: ICMP6, echo request, seq 0, length 16 While the CP policer did its job and prevented any significant operational impact, the traffic did possibly prevent/delay legitimate address resolution attempts as well as trigger loads of pointless address resolution attempts (ICMPv6 Neighbour Solicitations) towards the customer LAN. We just blocked the prefix at our AS border to get rid of that noise. Those ACLs are currently dropping packets at a rate of around 600 pps. I was just curious to hear if anyone else is seeing the same thing, and also whether or not people feel that this is an okay thing for this «Internet Measurement Research (SIXMA)» to do (assuming they are white-hats)? Tore

6 6

Hotstar IP Notoriety
by Eric C. Miller 15 Jul '21

15 Jul '21

Is there anyone here with a relationship with the Hotstar streaming service? We recently launched a new IP block and it's being blocked by them. Eric

1 0

EVPN P2MP Implementation
by aj 15 Jul '21

15 Jul '21

Hi All, Could anyone please share any ideas on how P2MP can be achieved using EVPN ? -- Many Thanks, Joel...

3 2

What's Your Story? Pitch Us Your NANOG Story + More
by Nanog News 14 Jul '21

14 Jul '21

*WATCH NOW: NANOG U WEBINAR* State of Routing and RPKI Introduction *Our May 20 NANOG U Webinar featured Melchior Aelmans, Consulting Engineer at Juniper Networks, with a talk on State of Routing Security and RPKI Introduction.* *Agenda:* Join Melchior Aelmans, Consulting Engineer at Juniper Networks, as he explores State of Routing Security and RPKI Introduction. - Current state of BGP Routing Security - What it does and where it fails - Introduce RPKI Origin Validation - Touch on what is after Origin Validation *Speaker: *Melchior Aelmans, Consulting Engineer at Juniper Networks Melchior is a Consulting Engineer at Juniper Networks, where he has been working with many operators on the design and evolution of their networks. He has over 15 years of experience in various operations and engineering positions with Cloud Providers, Data Centers and Service Providers. Melchior enjoys evangelizing and discussing routing protocols, routing security, internet routing and peering and datacenter architectures. He also participates in IETF and RIPE, is a regular attendee and presenter at conferences and meetings, is a member of the NANOG Program Committee and is a board member at the NLNOG foundation. State of Routing Security and RPKI Introduction (pdf) <https://nanog.us20.list-manage.com/track/click?u=4d708401d0e69d9dc73d1c204&…> *WATCH NOW <https://www.nanog.org/news-stories/nanog-tv/nanog-u/webinar-state-of-routin…>* *Pitch Us our Next NANOG Story*We want to tell the stories that represent our diverse community and represent our core values:* to empower, be inviting and innovative.* Do you have a story that reflects our mission t*o help build the internet of tomorrow *and creates a more collaborative, inspiring and cutting-edge resource for our current and future NOGs? If so, please fill out and submit the attached form and help us share the voice of NANOG. *Please include as many names and facts as you can* *SUBMIT STORY <https://www.nanog.org/news-stories/story-suggestions/>* *Share NANOG News**We can’t grow without you… *share the latest NANOG news with your colleagues! Our success has always depended on the collective expertise of its community members to help direct and shape the organization’s future, through idea sharing, problem solving, and collaboration. *NANOG’s mailing list* offers a forum to stay connected all year long, with topics ranging from broad-based engineering challenges + solutions, to routing, outages, performance measurement, evolving wide-area technologies, exchange points, traffic engineering, operational experience, ISP security, and trouble ticket systems. Sign up to receive individual copies of each message posted to the list, or choose the digest option to receive messages batched into a single message. All mailing-list users must first agree to NANOG’s Usage Guidelines <https://nanog.us20.list-manage.com/track/click?u=4d708401d0e69d9dc73d1c204&…> . *SUBSCRIBE NOW <https://mailman.nanog.org/mailman/listinfo/nanog>* *NANOG Announcements* Keep up with our innovative community, via access to NANOG news, upcoming event information, member features, and stories. *SUBSCRIBE NOW <https://mailman.nanog.org/mailman/listinfo/nanog-announce>* *Mailing-list Archives* Access valuable information shared via NANOG mail-list threads over the past 30+ years. *SEARCH ARCHIVES * <https://www.nanog.org/resources/nanog-mailing-list/list-archives/>

1 0

OARConline 35a Workshop, September 8th, Call for Contributions now open
by Jake Zack 13 Jul '21

13 Jul '21

OARConline 35a will be an online meeting on September 8th 2021 starting at 15:00 UTC. The Programme Committee is seeking contributions from the community. All DNS-related subjects and suggestions for discussion topics are welcome. For inspiration, we provide a non-exhaustive list of ideas: - Deployment: Managing DNS changes and propagation, release process, change management. - Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection. - Scaling: Managing service capacity, failovers, disaster recovery. As it is an online workshop, we'd like to encourage brevity; presentations will be 10 or 20 minutes (including time for questions). **Workshop Milestones:** * 30 June 2021 - Submissions open via Indico * 20 July 2021 - Deadline for submission (23:59 UTC) * 27 July 2021 - Initial Contribution list published * 10 August 2021 - Full agenda published * 24 August 2021 - Deadline for slideset submission and Rehearsal * 08 September 2021 - OARConline 35a Workshop The Registration page and details for presentation submission are published at: <https://www.dns-oarc.net/oarc35a> DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups at DNS-OARC. See the registration page for details. To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. Additional information for speakers of OARConline 35a: * your talk will be broadcast live and recorded for future reference * your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting * you will be expected to attend a rehearsal on August 24th. It would be very useful to have your slides (even if draft) ready for this. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via <submissions(a)dns-oarc.net> Jacob Zack for the DNS-OARC Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact <sponsor(a)dns-oarc.net> if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.)

1 0

[FYI] Call for Presentations for the virtual European Peering Forum 2021
by Arnold Nipper 13 Jul '21

13 Jul '21

Dear all This is a call for Presentations for the virtual European Peering Forum 2021 AMS-IX, DE-CIX, LINX, Netnod are happy to host the virtual European Peering Forum (EPF) 2021 from the 20th - 22th September 2021. The event will welcome peering managers and coordinators from networks connected to the host Internet exchanges. Besides some interesting topical agenda, the three-day event accommodates room for attendees to meet virtually on a one-to-one basis to discuss bilateral peering business opportunities. The programme committee will be looking for presentations related to peering and technical topics of interconnection. Your presentation should address * Interconnection Automation * Regional Peering * Interconnection / Peering Internet Governance and Regulatory Topics * Economic and Product Trends * Peering / Interconnection strategies * Interesting findings about Peering / Interconnection * 400GE and beyond * Any other hot topic related to Interconnection / Peering Submissions =========== Presentations must be of a non-commercial nature. Product or marketing-heavy talks are strongly discouraged. Submissions of presentations should be made to the programme committee <epf-pc(a)peering-forum.eu>. Please include: * Author's name and e-mail address * Presentation title * Abstract * Slides (if available) * Time requested (max. 30 minutes incl. Q&A) Deadlines ========= Please send in your presentation asap. We decide on a first come first serve basis. The latest date for submission is July 30th. More information about the event and other activities around the virtual EPF 2021 may be found at * https://peering-forum.eu/ * https://www.facebook.com/groups/1586607564933665/ Cheers Arnold -- Keep calm, keep distance, keep connected! Arnold Nipper email: arnold(a)nipper.de mobile: +49 172 2650958

1 0

RPKI validation, BGP/allocation lookup UI and API
by Alex Band 12 Jul '21

12 Jul '21

Hello, The RIPE NCC RPKI Validator historically offered a very complete toolset. One feature that has proven to be a useful troubleshooting tool was the “BGP Preview” [1], letting you compare validated ROA payloads against announcements seen by the RIS route collectors. With the RIPE NCC Validator discontinued, over the last couple of months we’ve been working on replicating this functionality and attempted to improve upon it in several ways. A preview is now available here: https://routinator.nlnetlabs.nl/ Example: https://routinator.nlnetlabs.nl/69.252.0.0%2F12?validate-bgp=true In addition to validating an IP prefix/ASN combination, you can: - automatically lookup the validation ASN in BGP announcements for a specific prefix. - see prefixes that are allocated to the same organisation by an RIR and their RPKI validation status based on BGP announcements or a user supplied ASN. This functionality is backed by an external, public API that hosts the allocations and BGP origin ASes: https://roto-api.nlnetlabs.net/v1/ Example: https://roto-api.nlnetlabs.net/v1/prefix/69.252.0.0/12/search The open source repositories involved are: https://github.com/NLnetLabs/roto-api (the API service) https://github.com/NLnetLabs/rotonda-store (the in-memory prefix-based database) We will be working towards stabilising the API and the UI in the coming months. We look forward to your feedback, which we’re collecting here: https://github.com/NLnetLabs/routinator-ui/issues Cheers, Alex [1] https://rpki-validator.ripe.net/bgp-preview

1 0

VoP regulatory consultant
by Ryan Finnesey 12 Jul '21

12 Jul '21

Would anyone have any recommendations on regulatory consultants for VoIP within North America but markets outside the US? Get Outlook for iOS<https://aka.ms/o0ukef>

3 3

SITR/SHAKEN implementation in effect today (June 30 2021)
by Sean Donelan 11 Jul '21

11 Jul '21

STIR/SHAKEN Broadly Implemented Starting Today https://www.fcc.gov/document/stirshaken-broadly-implemented-starting-today WASHINGTON, June 30, 2021—FCC Acting Chairwoman Jessica Rosenworcel today announced that the largest voice service providers are now using STIR/SHAKEN caller ID authentication standards in their IP networks, in accordance with the deadline set by the FCC. This widespread implementation helps protect consumers against malicious spoofed robocalls and helps law enforcement track bad actors. The STIR/SHAKEN standards serve as a common digital language used by phone networks, allowing valid information to pass from provider to provider which, among other things, informs blocking tools of possible suspicious calls.

13 25

Do you care about "gray" failures? Can we (network academics) help? A 10-min survey
by Vanbever Laurent 09 Jul '21

09 Jul '21

Dear NANOG, Detecting whole-link and node failures is relatively easy nowadays (e.g., using BFD). But what about detecting gray failures that only affect a *subset* of the traffic, e.g. a router randomly dropping 0.1% of the packets? Does your network often experience these gray failures? Are they problematic? Do you care? And can we (network researchers) do anything about it?” Please help us out to find out by answering our short (<10 minutes) anonymous survey. Survey URL: https://forms.gle/v99mBNEPrLjcFCEu8 ## Context: When we think about network failures, we often think about a link or a network device going down. These failures are "obvious" in that *all* the traffic crossing the corresponding resource is dropped. But network failures can also be more subtle and only affect a *subset* of the traffic (e.g. 0.01% of the packets crossing a link/router). These failures are commonly referred to as "gray" failures. Because they don't drop *all* the traffic, gray failures are much harder to detect. Many studies revealed that cloud and datacenter networks routinely suffer from gray failures and, as such, many techniques exist to track them down in these environments (see e.g. this study from Microsoft Azure https://www.microsoft.com/en-us/research/wp-content/uploads/2017/06/paper-1…) What is less known though is how much gray failures affect *other* types of networks such as Internet Service Providers (ISPs), Wide Area Networks (WAN), or Enterprise networks. While the bug reports submitted to popular routing vendors (Cisco, Juniper, etc.) suggest that gray failures are pervasive and hard to catch for all networks, we would love to know more about first-hand experiences. ## About the survey: The questionnaire is intended for network operators. It has a total of 15 questions and should take at most 10 minutes to complete. The survey and the collected data are totally anonymous (so please do not include information that may help to identify you or your organization). All questions are optional, so if you don't like a question or don't know the answer, just skip it. Thank you so much in advance, and we look forward to read your responses! Laurent Vanbever, ETH Zurich PS: Of course, we would be extremely grateful if you could forward this email to any operator you might know who may not read NANOG ( assuming those even exist? :-) )!

12 22