August 2022 - Test - lists.nanog.org

Issue with Geolocation in Virginia US
by Raja Sekhar Gullapalli 04 Jan '24

04 Jan '24

Team, We are having issues in our Virginia US office & it shows geolocation in all browsers as Canada instead of US region when we access news.google.com in our PC. Our public ip is 129.46.232.65. This issue is being observed for more than 2 month. Can you help to whom we can contact to resolve the issue. Regards, Raja

8 13

FW: softlayer.com
by Travis Garrison 23 Sep '23

23 Sep '23

Traceroute from here if it helps Tracing route to 138-43-128-1.reserved.highland.net [138.43.128.1] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms [REDACTED] 2 <1 ms <1 ms <1 ms [REDACTED] 3 1 ms 1 ms <1 ms [REDACTED] 4 1 ms <1 ms <1 ms [REDACTED] 5 6 ms 6 ms 6 ms v313.core1.mci3.he.net [216.218.213.141] 6 16 ms 16 ms 16 ms 100ge10-2.core1.dal1.he.net [184.105.81.206] 7 26 ms 26 ms 26 ms xo-as15-as2828.10gigabitethernet6-7.core1.dal1.he.net [184.105.255.78] 8 40 ms 39 ms 40 ms 207.88.14.198.ptr.us.xo.net [207.88.14.198] 9 40 ms 39 ms 40 ms 207.88.12.178.ptr.us.xo.net [207.88.12.178] 10 39 ms 39 ms 39 ms 216.156.16.239.ptr.us.xo.net [216.156.16.239] 11 48 ms 48 ms 48 ms ip65-46-198-198.z198-46-65.customer.algx.net [65.46.198.198] 12 41 ms 41 ms 41 ms occm-6.dhcp.grp1-rng1.tncsvl.blomand.net.57.131.192.in-addr.arpa [192.131.57.6] 13 * * * Request timed out. Thanks Travis From: NANOG <nanog-bounces(a)nanog.org<mailto:nanog-bounces@nanog.org>> On Behalf Of Siyuan Miao Sent: Friday, March 22, 2019 9:22 AM To: Nikolas Geyer <nik(a)neko.id.au<mailto:nik@neko.id.au>> Cc: nanog(a)nanog.org<mailto:nanog@nanog.org> Subject: Re: softlayer.com Perhaps it won't work because their customer support will ask you for bi-directional traceroute and refused to forward to backbone team. Then they'll say it's not their fault and you can see the packet is dropped outside our network. Here's a sample traceroute from SoftLayer Washington, San Jose and Seattle in case someone needs it: aveline@iad02-sl01:~$ mtr 138.43.128.1 --report-wide Start: Fri Mar 22 17:20:42 2019 HOST: iad02-sl01 Loss% Snt Last Avg Best Wrst StDev 1.|-- [REDACTED] 0.0% 10 1.4 1.5 0.8 3.7 1.0 2.|-- ae13.dar02.wdc01.networklayer.com<http://ae13.dar02.wdc01.networklayer.com> 0.0% 10 0.5 3.3 0.4 28.6 8.8 3.|-- ae9.bbr01.eq01.wdc02.networklayer.com<http://ae9.bbr01.eq01.wdc02.networklayer.com> 0.0% 10 0.8 0.8 0.7 1.0 0.0 4.|-- eqix-dc5.intellifiber.com<http://eqix-dc5.intellifiber.com> 0.0% 10 0.8 1.2 0.8 2.2 0.3 5.|-- ae13-0.cr02.asbn01-va.us.windstream.net<http://ae13-0.cr02.asbn01-va.us.windstream.net> 0.0% 10 0.9 0.9 0.9 1.0 0.0 6.|-- ae11-0.cr01.atln02-ga.us.windstream.net<http://ae11-0.cr01.atln02-ga.us.windstream.net> 0.0% 10 15.6 16.1 15.6 17.4 0.5 7.|-- ae0-0.pe06.atln02-ga.us.windstream.net<http://ae0-0.pe06.atln02-ga.us.windstream.net> 0.0% 10 17.4 16.1 15.9 17.4 0.3 8.|-- h43.88.198.64.static.ip.windstream.net<http://h43.88.198.64.static.ip.windstream.net> 0.0% 10 24.7 24.8 24.6 24.9 0.0 9.|-- east.tndodge-21.static.tncsvl.blomand.net<http://east.tndodge-21.static.tncsvl.blomand.net> 0.0% 10 22.6 22.8 22.5 23.8 0.0 10.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 aveline@sjc03-sl01:~$ mtr 138.43.128.1 --report-wide Start: Fri Mar 22 16:21:04 2019 HOST: sjc03-sl01 Loss% Snt Last Avg Best Wrst StDev 1.|-- [REDACTED] 0.0% 10 2.4 2.0 0.3 14.3 4.3 2.|-- ae0.dar02.sjc01.networklayer.com<http://ae0.dar02.sjc01.networklayer.com> 0.0% 10 1.0 0.5 0.3 1.3 0.0 3.|-- ae9.bbr01.eq01.sjc02.networklayer.com<http://ae9.bbr01.eq01.sjc02.networklayer.com> 0.0% 10 0.8 0.8 0.7 0.9 0.0 4.|-- eqix-sv1.windstream.com<http://eqix-sv1.windstream.com> 0.0% 10 0.9 0.9 0.8 1.1 0.0 5.|-- ae6-0.cr02.lsaj01-ca.us.windstream.net<http://ae6-0.cr02.lsaj01-ca.us.windstream.net> 0.0% 10 11.6 11.5 11.5 11.6 0.0 6.|-- ae-11-0.cr01.dlls01-tx.us.windstream.net<http://ae-11-0.cr01.dlls01-tx.us.windstream.net> 0.0% 10 42.6 42.7 42.5 43.4 0.0 7.|-- ae7-0.cr02.atln02-ga.us.windstream.net<http://ae7-0.cr02.atln02-ga.us.windstream.net> 0.0% 10 64.0 65.6 63.9 74.2 3.4 8.|-- ae1-0.pe06.atln02-ga.us.windstream.net<http://ae1-0.pe06.atln02-ga.us.windstream.net> 0.0% 10 62.3 62.7 62.2 66.9 1.5 9.|-- h43.88.198.64.static.ip.windstream.net<http://h43.88.198.64.static.ip.windstream.net> 0.0% 10 71.9 72.0 71.9 72.2 0.0 10.|-- east.tndodge-21.static.tncsvl.blomand.net<http://east.tndodge-21.static.tncsvl.blomand.net> 0.0% 10 69.9 68.8 68.6 69.9 0.3 11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 aveline@sea04-sl01:~$ mtr 138.43.128.1 --report-wide Start: Fri Mar 22 08:19:09 2019 HOST: sea04-sl01 Loss% Snt Last Avg Best Wrst StDev 1.|-- [REDACTED] 0.0% 10 0.7 1.2 0.7 1.8 0.0 2.|-- ae12.dar02.sr01.sea01.networklayer.com<http://ae12.dar02.sr01.sea01.networklayer.com> 0.0% 10 0.6 0.7 0.5 1.3 0.0 3.|-- ae9.bbr01.wb01.sea02.networklayer.com<http://ae9.bbr01.wb01.sea02.networklayer.com> 0.0% 10 1.2 1.0 0.7 1.5 0.0 4.|-- six.seattle-wa.us.windstream.net<http://six.seattle-wa.us.windstream.net> 0.0% 10 1.5 1.0 0.7 1.7 0.0 5.|-- ae12-0.cr01.chcg01-il.us.windstream.net<http://ae12-0.cr01.chcg01-il.us.windstream.net> 0.0% 10 41.1 41.2 41.0 41.6 0.0 6.|-- ae17-0.cr02.chcg01-il.us.windstream.net<http://ae17-0.cr02.chcg01-il.us.windstream.net> 0.0% 10 41.1 41.4 41.1 42.0 0.0 7.|-- ae10-0.cr01.atln02-ga.us.windstream.net<http://ae10-0.cr01.atln02-ga.us.windstream.net> 0.0% 10 63.8 64.4 63.5 71.1 2.3 8.|-- ae0-0.pe06.atln02-ga.us.windstream.net<http://ae0-0.pe06.atln02-ga.us.windstream.net> 0.0% 10 63.7 63.7 63.5 64.0 0.0 9.|-- h43.88.198.64.static.ip.windstream.net<http://h43.88.198.64.static.ip.windstream.net> 0.0% 10 71.6 71.8 71.5 72.8 0.0 10.|-- east.tndodge-21.static.tncsvl.blomand.net<http://east.tndodge-21.static.tncsvl.blomand.net> 0.0% 10 71.8 70.8 70.2 71.8 0.3 11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 Regards, Siyuan Miao On Fri, Mar 22, 2019 at 10:10 PM Nikolas Geyer <nik(a)neko.id.au<mailto:nik@neko.id.au>> wrote: This is the best approach. Have run into this problem a few times and had zero success getting the filters removed without having SL customers log tickets with support. Verbiage needs to be “this prefix is blocked, please escalate to your backbone team”. Sent from my iPhone On Mar 22, 2019, at 9:56 AM, Forrest Christian (List Account) <lists(a)packetflux.com<mailto:lists@packetflux.com>> wrote: Another idea... Have you tried reaching out to some of the blocked sites? They likely have better contact information than is available publicly, especially a larger one like indeed. On Thu, Mar 21, 2019, 3:41 PM John Alcock <john(a)alcock.org<mailto:john@alcock.org>> wrote: Still looking for anyone from softlayer.com<http://softlayer.com> It has been a challenge. Anything hosted by softlayer.com<http://softlayer.com> is being blocked. Here is a small list so far windowbook.tpondemand.com<http://windowbook.tpondemand.com> ahainstructornetwork.americanheart.org<http://ahainstructornetwork.americanheart.org> clover.com<http://clover.com> Cebroker.com<http://Cebroker.com> Softlayer.com<http://Softlayer.com> indeed.com<http://indeed.com> & Enforce Staffing It is growing every day. John On Wed, Mar 20, 2019 at 12:35 PM John Alcock <john(a)alcock.org<mailto:john@alcock.org>> wrote: Afternoon, Thought I would start a new thread. After researching, traceroutes, etc, I think I found my problem. 9 out of the 10 sites that subscribers on my new block is being hosted by softlayer. Anyone on the list have contacts with softlayer. Right now I have an email to abuse. The support line will not help me out. John

3 2

Providing geofeed info to Google
by Hugo Slabbert 18 Sep '23

18 Sep '23

Google folks: I see historical reference to needing to use the Google Peering Portal ( http://peering.google.com) if you need to provide Google with geofeed info for GeoIP info on network blocks, ref https://mailman.nanog.org/pipermail/nanog/2015-May/075229.html. Is that still the case? Are there any avenues to provide Google with geofeed info if you're *not* currently peering with 15169? Or to get access to just the geofeed update portion of the Peering Portal? -- Hugo Slabbert

6 8

SentryPeer: A distributed peer to peer list of bad IP addresses and phone numbers collected via a SIP Honeypot
by Gavin Henry 04 Jul '23

04 Jul '23

Hi all, I hope you don't mind the post, but thought this might be of use and in the spirit of release early, release often I've done an alpha release: https://github.com/SentryPeer/SentryPeer There's a presentation too if you'd like to watch/read where I hope to go with this: https://blog.tadsummit.com/2021/11/17/sentrypeer/ Working on the API and web UI next, then the p2p part of it. Feel free to submit any feature requests or have a play :-) Thanks for reading and any feedback is welcome! -- Kind Regards, Gavin Henry.

3 7

Re: Upstream bandwidth usage
by Mel Beckman 27 Feb '23

27 Feb '23

Adam, Your point on asymmetrical technologies is excellent. But you may not be aware that residential optical fiber is also asymmetrical. For example, GPON, the latest ITU specified PON standard, and the most widely deployed, calls for a 2.4 Gbps downstream and a 1.25 Gbps upstream optical line rate. -mel > On Jun 9, 2022, at 3:08 PM, Adam Thompson <athompson(a)merlin.mb.ca> wrote: > However, if you're talking about fiber service, it's pretty much pure marketing-dept-driven BS, combined with some vague justification of not letting TOR nodes or copyright-ignoring seeders/Warez-providers/etc. overwhelm the network in unexpected ways.

18 25

202203071610.AYC Re: Making Use of 240/4 NetBlock
by Abraham Y. Chen 16 Jan '23

16 Jan '23

Dear Colleagues: 0) I was made aware of a recent discussion on this Forum that cited our work on the 240/4 NetBlock, nicknamed EzIP (Phonetic for Easy IPv4). (Please see, at the end of this MSG, the URL to the discussion and the highlighted text where the citation was made.) 1) As the lead investigator of the EzIP Project, I would like to formally introduce our solution by bringing your attention to an overview whitepaper: https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf In a nutshell, EzIP proposes to disable the program codes in current routers that have been disabling the use of the 240/4 NetBlock. The cost of this software engineering should be minimal. The EzIP deployment architecture is the same as that of the existing CG-NAT (Carrier Grade Network Address Translation). Consequently, there is no need to modify any hardware equipment. There is an online setup description (Reference II), called RAN (Regional Area Network), that demonstrates the feasibility of this approach. 2) There are additional consequential benefits by deploying EzIP, such as those mentioned by our comment to Reference III in the above whitepaper. I look forward to addressing your thoughts. Regards, Abe (2022-03-07 17:14 EST) VP Engineering Avinta Communications, Inc. Milpitas, CA 95035 USA +1(408)942-1485 Skype: Abraham.Y.Chen eMail: AYChen(a)Avinta.com WebSite: www.Avinta.com *********************** https://mailman.nanog.org/pipermail/nanog/2021-November/216766.html Class D addresses? was: Redploying most of 127/8 as unicast public *Greg Skinner* gregskinner0 at icloud.com <mailto:nanog%40nanog.org?Subject=Re%3A%20Class%20D%20addresses%3F%20was%3A%20Redploying%20most%20of%20127/8%20as%20unicast%20public&In-Reply-To=%3CFEDBF677-BC75-47F3-A92D-2611F43283BA%40icloud.com%3E> /Mon Nov 29 18:47:14 UTC 2021/ * Previous message (by thread): Class D addresses? was: Redploying most of 127/8 as unicast public <https://mailman.nanog.org/pipermail/nanog/2021-November/216640.html> * Next message (by thread): Class E addresses? 240/4 history <https://mailman.nanog.org/pipermail/nanog/2021-November/216602.html> * *Messages sorted by:* [ date ] <https://mailman.nanog.org/pipermail/nanog/2021-November/date.html#216766> [ thread ] <https://mailman.nanog.org/pipermail/nanog/2021-November/thread.html#216766> [ subject ] <https://mailman.nanog.org/pipermail/nanog/2021-November/subject.html#216766> [ author ] <https://mailman.nanog.org/pipermail/nanog/2021-November/author.html#216766> ------------------------------------------------------------------------ >/On Nov 24, 2021, at 5:08 PM, William Herrin <bill at herrin.us <https://mailman.nanog.org/mailman/listinfo/nanog>> wrote: />//>/On Wed, Nov 24, 2021 at 4:36 PM David Conrad <drc at virtualized.org <https://mailman.nanog.org/mailman/listinfo/nanog>> wrote: />>>/I like research but what would the RIRs study? The percentage of the />>//>>/Lots of people said similar things when 1.0.0.0/8 was allocated to APNIC />>/and they said similar things when 1.1.1.0/24 was stood up as an />>/experiment by Cloudflare and APNIC, yet 1.1.1.1 seems to be pretty popular. />//>/Hi David, />//>/I don't recall there being any equipment or software compatibility />/concerns with 1.0.0.0/8. If you do, feel free to refresh my memory. As />/I recall it, there were concerns with prior local use and potential />/trash traffic. It seemed likely those concerns could be addressed with />/experiments, and the experiments in fact addressed them. />//>/The prior local use worry reared its head again with 240/4 but given />/the prior experience with 1.0.0.0/8 I don't personally believe we need />/to re-run that experiment just because the numbers are part of a />/different block. />//>//>>/Seems to me that a number of folks on this list and during this />>/discussion would disagree with a blanket assertion that 240/4 />>/is “dysfunctional on the 2021 Internet” - some of them even />>/wrote a draft discussing the possibility. />//>/Line them up. Show of hands. Who really thinks that if we assign />/240.0.0.1 to a customer tomorrow without waiting for anyone to clean />/up their software and hardware, you won't get enough complaints about />/things not working that you have to take it back and assign a />/different address instead? />//>//>>/1. Move 240/4 from "reserved" to "unallocated unicast" />>//>>/OK, but this seems like a quibble. The status for 240/4 is “ />>/RESERVED: designated by the IETF for specific non-global-unicast />>/purposes as noted.” The “as noted” part is “Future Use”. />//>/It's not a quibble. Some vendors take the current status to mean />/"treat it like unicast until we're told otherwise." Others take the />/status to mean, "packets with these addresses are bogons without a />/defined routing behavior until we're told otherwise." The result is />/incompatible behavior between vendors. Changing that direction to />/"treat it like unicast" without ambiguity is not a quibble. />//>/Regards, />/Bill Herrin />//>/-- />/William Herrin />/bill at herrin.us <https://mailman.nanog.org/mailman/listinfo/nanog> />/https://bill.herrin.us/ / For what it’s worth, I’ve been tracking this issue on other netops mailing lists. There is a recent post on the LACNOG list from Leandro Bertholdo <https://mail.lacnic.net/pipermail/lacnog/2021-November/008895.html> referencing https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/ <https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/>, a draft proposing another way to make additional IPv4 address space available I haven’t had time to read the draft closely, but I noticed that it involves the use of 240/4. Subsequent googling about the draft turned up a presentation <https://www.avinta.com/phoenix-1/home/RegionalAreaNetworkArchitecture.pdf> describing how the techniques described could be deployed. I noticed that the presentation made reference to OpenWRT, so perhaps the authors are aware of the work that the authors of the IPv4 Unicast Extensions Project have done in that area. The adaptive-ipv4 draft will expire sometime next month, so anyone interested in seeing it move forward should contact the authors. —gregbo ******************* -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

70 306

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

Request for help: academic study (questionnaire)
by Etienne-Victor Depasquale 04 Oct '22

04 Oct '22

Hello NANOGers, I'm asking for your help through your response to a questionnaire that forms part of an academic study that I'm carrying out <https://forms.gle/AAJokyg98JLW7Ti6A>. The study is directed solely towards facilitating understanding of metro area networks, for analysts who approach from the perspective of energy consumption. The study is anonymous (no individual or company names are solicited), and individual responses will only be used in aggregate. I shall send a digest of the survey to the mailing list, and will correspond with respondents who would like a copy of the paper which I intend to produce with the results. Yours sincerely, Etienne -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale

1 5

RFC: BOGONs over BGP, adding some ranges
by James Shank 06 Sep '22

06 Sep '22

Dear NANOG! As many of you know, Team Cymru runs a free service delivering updated BOGONS to networks around the world. We've been doing this for decades at this point. For more information about this service, please see https://www.team-cymru.com/bogon. Recently, we've discussed internally a discrepancy between our BGP based feed and the other formats we deliver for our Traditional BOGONS feed. For historic reasons, we previously omitted delivery of some ranges that are BOGONS from our BGP advertisements. We are considering adding the below ranges back in, but want to hear feedback from the community on these ranges prior to advertising them, out of an abundance of caution. The below ranges are what we are currently considering advertising: 0/8 (this one we already have concluded is safe as it is already advertised in our "FULL BOGONS" set.) 127/8 224/4 240/4 Note that 224/4 and 240/4 may be aggregated differently in our advertisement, but are broken out here to facilitate discussion. So, fellow NANOGers, what say ye? I would love to hear your feedback, pro or con, well-reasoned with data points or general "argh! there be dragons!" sentiments. Looking forward to seeing folks in Hollywood for N86! Cheers! James -- *James Shank* Chief Architect of Community Services and Sr. Security Evangelist e: jshank(a)cymru.com o: +1 847 378-3365

7 7

Extended Deadline and Reminder OARC 39 - Call for Contribution
by John Todd 31 Aug '22

31 Aug '22

OARC 39 will be a two-day hybrid meeting held on 22 & 23 October in Belgrade, Serbia at 10:00 AM (Local time - CEST (UTC+02:00)) The onsite part of the meeting will be colocated with RIPE 85. 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: Operations: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve TTR, tooling). Deployment: DNS config management and release process. Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection. Scaling: DNS performance management and metrics. Increasing DNS Server Efficiency Security/Privacy: DNSSEC signing and validation, key storage, rollovers, qname minimization, DoH/DoT Note: OARC 39 will be a joint conference with CENTR and abstract submissions from CENTR members are welcome. As it is an hybrid workshop, we'd like to encourage brevity; presentations should not be longer than 20 minutes (with additional time for questions). Workshop Milestones: 2022-07-30 Submissions open via Indico 2022-09-06 Deadline for submission (23:59 UTC) 2022-09-08 Preliminary list of contributions published 2022-09-20 Full agenda published 2022-10-03 Deadline for slideset submission and Rehearsal 2022-10-22 OARC 39 Workshop - Day1 2022-10-23 OARC 39 Workshop - Day2 The Registration page and details for presentation submission are published at: <https://www.dns-oarc.net/oarc39> 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 OARC 39 - 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 = Remote speakers have mandatory rehearsal on 2022-10-04 at 14:00 UTC. It would be very useful to have your slides (even if draft) ready for this. Note: DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups to speak at and/or attend DNS-OARC. More details will be provided when registration opens. 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 John Todd, 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