- Test - lists.nanog.org

Contact for AS 19338
by Elmar K. Bins 11 Nov '22

11 Nov '22

Hello 'body, I'm looking for a NOC contact for AS 19338, the old Telmex Chile AS. Anybody have anything? Thanks, Elmar.

1 0

NANOG 87: Call for Presentations | N86 PC Picks + More
by Nanog News 10 Nov '22

10 Nov '22

*NANOG 87: Call for Presentations * *NANOG PC is Now Accepting Proposals for NANOG 87* *NANOG 87 will take place in Atlanta, GA, on 13 -15 Feb 2023.* The PC is looking to schedule over 1,800 minutes of content for NANOG 87 and has confirmed 165 minutes already - so don't wait! *Requested Topics:* - Network Automation - practical uses, how to get started - Network Future - forecast for changes in technology, design, applications - Research & Education - what research is happening now in network operations - Security - developments in, problems/solutions, various protocols of - Tutorials - all levels, IPv6, BGP, Segment Routing, DNS *MORE INFO* <https://www.nanog.org/program/call-presentations/> *NANOG 86 "PC Picks"* *PC Member Cat Gurinsky Shares her Favorite Talks at our Most Recent Meeting* *Don't know where to start watching?* The NANOG Program Committee (PC) has you covered! Check out the top picks below from our featured PC member, Cat Gurinsky or curate a list of your own! We will publish your selections as a guest star of NANOG. Email your favorites at news(a)nanog.org. *READ MORE <https://www.nanog.org/stories/nanog-86-pc-picks/>* *NANOG 86 Photo Albums are Now Available * All NANOG 86 photos are now uploaded to Flickr. Relive all your favorite moments at our most recent meeting in Hollywood! * SAY CHEESE! <https://www.flickr.com/photos/nanog/>*

1 0

In Memory of Betty Burke
by Edward McNair 09 Nov '22

09 Nov '22

With deep sorrow, we announce the passing of Betty Joe Burke, NANOG's founding Executive Director (2011-2018). We mourn the loss of a mother, grandmother, friend, and an invaluable member of our NANOG Community. Betty left an indelible mark on all who knew her. During her decades of devotion to NANOG, Betty served as a leader, mentor, and advocate for our Community. Her determination and enthusiasm helped shape NANOG from its inception. She worked tirelessly to help build a thriving community dedicated to "working together for the Internet of tomorrow.” Her impact on our community began through her work at the University of Michigan and later through Merit Networks. Her impact on the Internet community started with managing a consortium of engineering professionals working to re-engineer and operate the first national high-speed internet backbone (NSFNET). She also oversaw building the State of Michigan's most prominent technology center. She coordinated IT conferences composed of an international membership community working to invent the Internet of tomorrow. After 36 years of service, Betty retired from the University of Michigan in 2010. The board then selected her to guide the newly independent NANOG organization in 2011, where she served as NANOG’s Executive Director until 2018. Her three children will greatly mourn her passing: daughter Jodie (David) Danko, son Todd (Arika) Burke, and daughter Julie (Jason) Brainer, as well as her grandchildren Allison and Danielle Danko, Gage and Jordyn Thrall, and J. Austin and Andrew Brainer. Betty is survived by two siblings, supportive extended family, friends, and an eternally grateful NANOG Community. For those interested in attending the Celebration of Betty's life, details can be found on the family's memorial tribute. Our Community Memorial can be accessed by anyone with a free account on NANOG's website. Additional text for the email message NANOG is creating a video to be played during the Celebration of Life on November 20, 2022. Since NANOG is a community of voices, we ask you to share photos and/or a brief (30 seconds maximum) audio clip that recalls your favorite memory. If you have multiple memories you would like to share; please create additional clips. You may send your contributions to memoriam(a)nanog.org Edward McNair Executive Director

1 0

Fwd: [AfrIPv6-Discuss] AFRINIC Members Connect: Call for presentations is Open
by Musa Stephen Honlue 09 Nov '22

09 Nov '22

1 0

Passing of Betty Burke
by John Curran 09 Nov '22

09 Nov '22

Folks - It is with sad heart that I share this information – Betty Burke (NANOG’s first Executive Director) is no longer with us - https://www.modetzfuneralhomes.com/obituaries/obituary-listings?obId=263153… Betty played a crucial role in helping build NANOG into the community it is today and will be sorely missed. :-( /John John Curran President and CEO American Registry for Internet Numbers

1 0

Geo-IP Sling.com and/or Dish Network Contact.
by Nicholas Warren 08 Nov '22

08 Nov '22

Does anyone know how to get ahold of Sling.com or Dish to update location information on IPv4 addresses? I don’t know if meta discussion is allowed on-list, but maybe geolocation contacts could be listed on the community site? 😊 - Nich Warren

3 4

Random Early Detect and streaming video
by Graham Johnston 08 Nov '22

08 Nov '22

I've been involved in service provider networks, small retail ISPs, for 20+ years now. Largely though, we've never needed complex QoS, as at $OLD_DAY_JOB, we had been consistently positioned to avoid regular link congestion by having sufficient capacity. In the few instances when we've had link congestion, egress priority queuing met our needs. With a new organization there is a set of circumstances that have resulted in a long standing business decision to apply some rate-limiting/traffic management during times of higher utilization to a subset of traffic. This traffic happens to be ABR streaming video traffic. The thought was that a little bit of packet loss that comes from RED or WRED could largely be absorbed in the ABR playback client's innate behavior, and yes, possibly a drop in video profile. These are acceptable business outcomes in this case. The question I have for the smart people of this list is, given the specific application that is receiving this treatment, is there any reason to apply a RED behavior any appreciable amount before the bandwidth limit for this application? It makes sense to me for interactive TCP traffic where you want to apply some artificial control to the TCP window, but I *feel* like ABR streaming video was designed to expect congestion, at least as the edge of the customers home, and combine that with the buffering and we should adjust the drop profile to kick in at a higher percentage. Today we use 70% to start triggering the drop behavior, but my head tells me it should be higher. The reason I am saying this is that we are dropping packets ahead of full link congestion, yes that is what RED was designed to do, but I surmise that we are making this application worse than is actually intended. Hopefully my targeted vagurey has still left enough context intact to receive some useful commentary back. Thanks

3 3

Spoofer Report for NANOG for Oct 2022
by CAIDA Spoofer Project 08 Nov '22

08 Nov '22

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 Oct 2022: ASN Name Fixed-By 33696 NEXTARRAY-ASN-01 2022-10-02 399486 2022-10-05 397086 LAYER-HOST-HOUSTON 2022-10-22 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Oct 2022: ASN Name First-Spoofed Last-Spoofed 19230 NANOG 2016-06-13 2022-10-03 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2022-10-29 6128 CABLE-NET-1 2016-09-03 2022-10-03 20412 CLARITY-TELECOM 2016-09-30 2022-10-31 271 BCNET 2016-10-24 2022-10-27 30036 MEDIACOM-ENTERPRISE-BUSINESS 2016-11-16 2022-10-12 22898 ATLINK 2016-12-16 2022-10-14 23089 HOTWIRE-COMMUNICATIONS 2017-09-30 2022-10-04 33452 RW 2018-09-19 2022-10-27 14031 SCXY 2018-10-18 2022-10-26 20278 NEXEON 2019-03-05 2022-10-07 21804 ACCESS-SK 2019-06-09 2022-10-26 398836 NP-NETWORKS 2021-03-12 2022-10-30 394414 E2WS 2022-05-08 2022-10-31 400517 2022-10-03 2022-10-03 400328 2022-10-14 2022-10-14 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

jon postel
by Randy Bush 07 Nov '22

07 Nov '22

it's been 24 years, and we still live in his shadow and stand on his shoulders. we try not to stand on his toes. randy

24 36

Offline contact for MS Windows network stack dev? (Win10 IPv6 bug Q.)
by Nathan Anderson 07 Nov '22

07 Nov '22

Not sure this is the best place to ask, but I'm not sure where else to go at this point... I'm trying to find somebody on the Windows development team that might be able & willing to help me track down some info on a bizarre IPv6 bug I've been chasing in Win10 & its related fix. I can confirm the bug in question was silently fixed somewhere in between 10.0.18362.657 and 10.0.18362.693 and that it seems to be within the tcpip.sys component, but the release notes for KB4535996 make zero mention of it. The fix has also seemingly never been backported to LTSC 2019. Essentially the problem is that, in a dual-stack environment, if a DNS lookup returns both an A and an AAAA record, Windows will prefer to make a connection to the target host via v4, claiming that it chose to do so because it is "Prefer[ring] [the] Aoac Interface", as if the given network interface only supports Connected/Modern Standby for IPv4 and not v6. Despite this, with the exact same drivers on the exact same host with the exact same hardware & network interfaces connected to the exact same LAN, the seemingly-fixed tcpip.sys no longer behaves this way. (It actually even works on "buggy" tcpip.sys after a fresh reboot, but only for some undefined amount of time before it reverts to this behavior. My theory is the codepath that is causing this is only *supposed* to be followed while the PC is *actually* asleep & not during normal operation, but some bit in memory is getting flipped when some event occurs, and the logic that is taking this particular bit into account is faulty.) If anybody can put me in touch with somebody who can pull a changelog of tcpip.sys between those two versions, I'd really appreciate it! I'm just trying to better understand the exact nature of the bug & the fix, since a NetTrace would implicate buggy network interface drivers, but that clearly can't be the whole story. And I'd like to figure out if a workaround is available for still-supported Windows versions that do not incorporate the actual fix (e.g., some registry entry that will make Windows ignore the freaking AOAC support reported by the network interface driver...the NetTrace entry implies Windows is following RFC 6724 and that it is considering the IPv6 destination to be "unreachable" [merely because of lack of AOAC support in the driver for IPv6?!], which is clearly not the case). Thanks! -- Nathan Anderson First Step Internet, LLC nathana(a)fsr.com

1 0