Re: who runs the root, Cogent-TATA peering dispute?
On 5/19/24 3:13 PM, David Conrad via NANOG wrote: > When you say “ICANN” who, exactly, do you mean? ICANN the organization or > ICANN the community? If the former, ICANN Org can’t do anything outside of > ICANN community defined policy or process or risk all sorts of > unpleasantness from internal policies to lawsuits to the ICANN Board being > spilled. If you mean the latter, ICANN org must abide by the ICANN > community’s demands or you get to the same point as previously mentioned. > That’s the whole point behind the “Empowered Community." Suppose the community wanted to change this or make a formal policy on root server hosting requirements. Where would this be done? Could a party submit a proposal to ICANN via the policy development process? If not where should the community start this? Please note, I'm not taking a position, only asking where the community needs to start. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net signature.asc Description: OpenPGP digital signature
Re: How threading works (was Re: Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block)
On 1/14/24 1:01 AM, William Herrin wrote: > Respectfully, your MUA is not the only MUA. Others work differently. Bill, I use multiple MUA's, among them Thunderbird, mutt, kmail and even the zimbra web interface. All follow and implement RFC5822 as it pertains to threading. Note, threading works fine in the list archives too, but only displays two levels deep. > GMail, for example, follows the message IDs as you say but assumes > that if you change the subject line in your reply (more than adding > "Re:") then you intend to start a new thread from that point in the > discussion. It groups messages accordingly. Gmail is therefore in violation of the RFC5822. It's quite clear how it should work per the RFC appendix. > This is not an unreasonable expectation: if you merely want to > continue the current conversation without going off on a new tangent > then there's no need for a different subject line. I think it's quite unreasonable to expect others to compensate for an MUA which doesn't implement 25+ year old standards properly. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
How threading works (was Re: Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block)
On 1/12/24 3:04 PM, Mu wrote: Would it be possible for you to reply in-thread, rather than creating a new thread with a new subject line every time you reply to someone? Trying to follow the conversation becomes very difficult for no reason. Threading has nothing to do with subject lines. RFC822 (now 5822) specifies how this works based on message ID. This thread displays fine in threaded mode in my MUA and in the archives. https://en.wikipedia.org/wiki/Conversation_threading https://mailman.nanog.org/pipermail/nanog/2024-January/thread.html If people could please reply to threads properly, inline and trimming non relevant text, it would make following discussion much easier. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: Am I the only one who thinks this is disconcerting?
On 11/8/23 2:25 PM, o...@delong.com wrote: Seems irresponsible to me that a root-server (or other critical DNS provider) would engage in a peering war to the exclusion of workable DNS. I've brought this up before and the root servers are not really an IANA function IIRC. There's not much governance over them, other than what's on root-servers.org. I think a case could be made that C is in violation of the polices on that page and RFC 7720 section 3. Basically none of the root servers want to change this and thus it's never going to change. DNS will fail and select another to talk to, and things will still work. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: Am I the only one who thinks this is disconcerting?
On 11/8/23 1:29 AM, Owen DeLong via NANOG wrote: https://dnsviz.net/d/10.159.192.in-addr.arpa/dnssec/ Seems to report a bunch of errors in the DS records for 192.in-addr.arpa held in the in-addr.arpa zone. I figured I’d wait a few days and try again the first few times I encountered this, but it’s persisted for more than two weeks now. Could these be related to the fact that dnsvis.net is trying to reach these servers via IPv6 and I think they use Hurricane for transit. Since HE and Cogent is a major gap, this causes them to time out trying to reach the C root server over IPv6. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: [EXTERNAL] Re: Charter DNS servers returning malware filtered IP addresses
On 10/27/23 7:49 AM, John Levine wrote: But for obvious good reasons, the vast majority of their customers don't I'd argue that as a service provider deliberately messing with DNS is an obvious bad thing. They're there to deliver packets. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net OpenPGP_signature Description: OpenPGP digital signature
Re: Charter DNS servers returning invalid IP addresses
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/25/23 8:24 PM, Greg Dickinson wrote: > He didn’t, I was just referencing Mimecast to indicate it was probably > larger than Charter’s DNS. Given the reports that someone else gave from > Virustotal, it seems it’s more widespread than first reported. Is there a link where this can be looked up? I've not seen anything on their website <https://www.mimecast.com>. If you're going to quote me, please don't alter what I wrote, and please trim the relevant parts of it. Thanks, - -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEaESdNosUjpjcN/JhYTmgYVLGkUAFAmU5twEACgkQYTmgYVLG kUDrcA/+MxVAPG4lHhbcsRkKBHKelmnZmM3hmBaLtenn6wOmFJ1TrehBTVBi3+qy 5tREfH8HQ5E/V5iZe/yAkVWETjptYjbpnDS73D6XPTlZzzEs5Py6uv1TMdgGzZf5 twV00M4kfYmzwffKs0hAXuQ8VkKo9x3S9c3jE6MJhqlxtWFMKEVdJX5xlUid0HqQ wt9KZxO4WVLdRKTfL9XWBh92Mccdo4rcwVFk4jvQDEnJvUg55TMhXNfQL/3a3PSG Pc/fGgnS+qEM9XxkMHBpilPHb0CB4YRJ7aldSkOZgL/7LVmQ0JyTd+clDSVCKeck FjHsWf/PRuBRMJHb3fT8mFDEQUltlTIfJr8gbOrV/GkFd0o9gmTYWLkvnUh70uhj S8ZXlzZoEue1OW5L4KkiFKP1i878aYhyn+OWbl8iW0P3WxmpNP9ZHOEMzAOLajIE WMK6DJpKBKl8DEsh4diSOPODySC4+mWnle1ZskGsPjTrLCAY+ukzI0k0idZRrFdV ywaK6nFKGvXkLMJM00s7ibLwAtnn30epGoWHHErKOBFfaZ12oPERoCaFArdNbLZi dxITHkYFaF70M+Jav/Jh4bf2baHwU/zTNdmDvgp8CjLgVF19439wgj8IeXrvqFQ+ VWLhlCj5D1GvblWi+GejK2dYLSfIWtIWL2CRCuGhHA1CpCdZvtI= =Esxb -END PGP SIGNATURE-
Re: [EXTERNAL] Re: Charter DNS servers returning invalid IP addresses
On 10/25/23 4:58 PM, Compton, Rich A wrote: > Charter uses threat intel from Akamai to block certain "malicious" domains. Does charter do this on signed domains too? -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: Charter DNS servers returning invalid IP addresses
On 10/25/23 2:41 PM, Greg Dickinson wrote: If it helps troubleshooting, when I click the domain in the email Mimecast tells me: “We checked the website you are trying to access for malicious and spear-phishing content and found it likely to be unsafe.” I saw nothing referencing Mimecast in the original email. Where did you see this? bonesinjars.com is not signed with DNSSEC. This is trivial to setup and might prevent some of this. Probably not a good idea for your customers to rely on $BIGCABLE DNS servers. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
ARIN email address (was cogent spamming directly from ARIN records?)
On 10/2/23 11:28 AM, Mel Beckman wrote: I believe they got the contact information from ARIN I'd suggest everyone use an alias unique to ARIN for your POC and/or public email. Makes it super simple to verify where it was sourced from. (and yes I've got the same spam) -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: mail.nanog.org broken v6 reverse DNS
On 9/14/23 2:12 PM, Bryan Fields wrote: On 9/14/23 1:35 PM, Chris Adams wrote: While wondering at high spam scores for NANOG mail, I noticed that it's in part because of broken reverse DNS for mail.nanog.org's IPv6 address. The address is 2001:1838:2001:8::20, with reverse delegated to ns1.scservers.com and ns2.scservers.com... but those hostnames don't resolve. The auth servers for scservers.com return SERVFAIL. Thanks, It's being looked at now. I'll updated once it's fixed. Our provider has fixed their reverse zones delegation at ARIN. It's working, but will need ~24 hours for the cached ttl to expire. Thanks! -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: mail.nanog.org broken v6 reverse DNS
On 9/14/23 1:35 PM, Chris Adams wrote: While wondering at high spam scores for NANOG mail, I noticed that it's in part because of broken reverse DNS for mail.nanog.org's IPv6 address. The address is 2001:1838:2001:8::20, with reverse delegated to ns1.scservers.com and ns2.scservers.com... but those hostnames don't resolve. The auth servers for scservers.com return SERVFAIL. Thanks, It's being looked at now. I'll updated once it's fixed. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: AFRINIC placed in receivership
On 9/13/23 9:27 PM, Bryan Fields wrote: > I think this qualifies as potentially operational. > > Afrinic placed in receivership, board elections to be held in six months: > https://archive.ph/jOFE4 Looks like archive.ph is having problems. This is the original article. > https://www.capacitymedia.com/article/2c6pnx4ymt7sd5c493wg0/news/exclusive-afrinic-placed-in-receivership-board-elections-to-be-held-in-six-months -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
AFRINIC placed in receivership
I think this qualifies as potentially operational. Afrinic placed in receivership, board elections to be held in six months: https://archive.ph/jOFE4 -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: OT So what do you think about the scuttlebutt of Musk interfering in Ukraine?
On 9/13/23 8:47 PM, Michael Thomas wrote: utilities weaponizing their monopoly status to the whims of any random narcissist billionaire https://www.youtube.com/watch?v=qDC3LYfHRGg Basically this? -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: malware warning
On 7/18/23 9:14 PM, Randy Bush wrote: > i did not think i was special, and assumed everybody is getting them. > but i figured that if i kept one or three people from falling for the > trap it was worth the pollution. I've done quite a bit of looking into this, tying to prevent it. It's not being pulled from the archives. The basic premise of it: 1. send email only to direct posters to the list, never through the list. 2. subscribe using a gmail account as a normal member for harvesting 3. scrape the new posts and use email in from: header to send spam to 4. wait some $TIME after the post and send the spam 5. The spam will never be able to be linked to the subscribed account I've been able to track these "ingestion" accounts and kill them when found, but it's impossible to do it without false positives. VERP is used for the list emails, but short of a bounce, that doesn't really help. About the only supported option that would mitigate this is wrapping all posts through the list as from the list. This still would expose the email addresses in the email, and we could rewrite them, but it breaks more than it fixes. I've seen proposals where all messages get wrapped and each individual email address found in the message is re-written to a unique address via a mail forwarding domain, but i can't see this working with such a diverse list. This also would break after some time. This is also not something supported off the shelf in most mailman or other MLMs. I'd love to kill this spam, but the openness of the email discussion list format makes it hard to do. If anyone has ideas on how we can kill this I'd love to shut it down. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: 128/9 cite
On 6/7/23 10:13 PM, Aftab Siddiqui wrote: I definitely read a detailed research paper about that incident long ago but can't find any link with any search keywords. But here is the NANOG archive. https://archive.nanog.org/mailinglist/mailarchives/old_archive/1997-10/msg00095.html https://archive.nanog.org/mailinglist/mailarchives/old_archive/1997-10/msg00110.html https://archive.nanog.org/mailinglist/mailarchives/old_archive/1997-10/msg00108.html Regards, That's the "old" archive. That was merged in the main archive (same one this list uses) a while back. If you sort by date you'll see a number of threads talking about the 70k BGP table size (lol). It's a fun read to see where we've come from in 26 years. https://mailman.nanog.org/pipermail/nanog/1997-October/date.html#123950 -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Best Linux (or BSD) hosted BGP?
I know best subjective, but I'm looking at a project to announce some IP space that's between uses now and see what's there. I'm planing to run a flow logger and ntop on the VM and see what is coming in if anything. I'm looking at the options for BGP out there, and there's quite a few (other than running a VM with a router doing BGP), but most data I've seen is focused on scale and filtering use, or RPKI. My use case is a bit different, and I can't find any best practices for this use case from what I've found. That said, is there a better solution other than linux/ntop/ipt-netflow? -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: ipv4/25s and above
On 11/19/22 3:12 PM, Douglas Fischer wrote: > I do not like mikrotik, but I need to say that RouterOS does support /31. > > All that you need to do, beyond set /31 at address for netmask, is check if > the other address is defined at the network address. Can you show some docs on this? I gave a subnet config to my customer of 255.255.255.254 and it wouldn't take it. I reconfigured it to a /30 (.252) and it worked for them. This was a on a RB2011 about 3 months ago. I search at the time showed it was a know issue. We laughed about it and moved on. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: ipv4/25s and above
On 11/18/22 6:44 AM, Joe Maimon wrote: >> We could, but many of our DIA customers have all manner of CPE's that >> may or may not support this. Having unique designs per customer does >> not scale well. > its almost 2023. /31 support is easily mandatory. You should make it > mandatory. Mikrotik still doesn't support /31 addressing. I had a customer who was configuring their "router" the other day and we found this out. Has to move to a /30 on the link. He's in Africa, and I'm 100% certain Mikrotik is a go to customer router there. There's people peering on Mikrotik even! -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: 2 Byte ASNs??
On 8/5/22 11:16 AM, Justin Wilson (Lists) wrote: > I have a network that is all Mikrotik and the route targets are messing with > them. Can you describe this a bit more? I'd like to add it to my list of stuff broken on mikrotik. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: NANOG List posts and DMARC
On 8/2/22 8:46 PM, Chris Adams via NANOG wrote: > Once upon a time, Bryan Fields said: >> The list is configured to wrap anyone posting from a domain with a with a >> DMARC Reject/Quarantine Policy (dmarc_moderation_action). If you don't have >> this set on your domain, the list will not wrap your message (which is the >> correct behavior as it breaks other things). > That is not the case right now; it appears to be modifying ALL senders > since earlier today (about 12:20pm CDT) . Your message has "From: Bryan > Fields via NANOG " even though you have no DMARC record > at all. Yes, I'm trying to get to the bottom of what if anything happened with the admin team. This is really broken at this point as munging from breaks DKIM signing if present in the original email. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net signature.asc Description: OpenPGP digital signature
Re: NANOG List posts and DMARC
On 8/2/22 1:16 PM, Jared Mauch wrote: > Can someone flip the option in Mailman for DMARC please, it’s problematic as > if one posts and does DMARC and has feedback on, our messages are possibly > rejected, and the feedback from a post is quite large. > > Not sure who manages it anymore these days. You can reach the admin at adm...@nanog.org. The nanog-ow...@nanog.org goes there too, so there's practically no reason to go on list with such things. The list is configured to wrap anyone posting from a domain with a with a DMARC Reject/Quarantine Policy (dmarc_moderation_action). If you don't have this set on your domain, the list will not wrap your message (which is the correct behavior as it breaks other things). Hit up the admin team and we'll look at it. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net signature.asc Description: OpenPGP digital signature
Re: FCC BDC engineer?
On 7/5/22 1:58 PM, Andrew Latham wrote: > I read https://docs.fcc.gov/public/attachments/DA-22-543A1.pdf and a PE is > not required. I'd agree. 47 CFR § 1.7004(d) "All providers also shall submit a certification of the accuracy of its submissions by a qualified engineer. The engineering certification shall state that the certified professional engineer or corporate engineering officer is employed by the provider and has direct knowledge of, or responsibility for, the generation of the provider's Digital Opportunity Data Collection filing." Note the lack of capitalization of "qualified engineer". This means it is not defined in that part, and leaves it open to interpretation. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: Test email
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 6/20/22 4:34 AM, Hank Nussbacher wrote: > I assume the admins are testing out > what has been blocking my emails for the past month and somehow this > email slipped thru. Just ignore and delete. This was not sent by the list admin team. The email was sent via bluehost. The MX for interall.co.il is blocking connections from the nanog list MX. # dig +noall +answer mx interall.co.il interall.co.il. 7133IN MX 0 mail.interall.co.il. # telnet mail.interall.co.il. 25 Trying 162.241.224.86... ^C # dig +noall +answer -x 162.241.224.86 86.224.241.162.in-addr.arpa. 86390 IN PTR box5171.bluehost.com. # ping 162.241.224.86 PING 162.241.224.86 (162.241.224.86) 56(84) bytes of data. 64 bytes from 162.241.224.86: icmp_seq=1 ttl=56 time=26.5 ms 64 bytes from 162.241.224.86: icmp_seq=2 ttl=56 time=26.6 ms ^C - --- 162.241.224.86 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 26.563/26.589/26.615/0.026 ms # telnet mail.interall.co.il. 80 Trying 162.241.224.86... ^C I'm open to testing further, but I don't think this is an issue on the nanog listserver or it's network. - -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEaESdNosUjpjcN/JhYTmgYVLGkUAFAmKzURkACgkQYTmgYVLG kUCQ3Q//YWCbiNAw7eAz0cvx771vHf//bZL31XDzNqAFyS6xAqYW5TjfqYZBcwna UcXXc1I6nHTVL3r6yvesiSoyrZsFe0l1J9GgrZurP96kDHwyqLKXzzner+717ZNB gQPkh/ja5YoL80JZ1z7ZVgDT4SnnRmekHK+8SJGAtsdQFfAw+qfsvPMy1XqedPod TIiRdXTG4oWNtvFRberO+Y8TvGM2UHb8Jbb0178ej+gRuajVeJmKAqwUw3nfX60K uUWr0ih8tzOMd9BU3+Vngvo3DoYtzr2CJKavK0z/eCUwlG3STXxHSK4L2UanBfQx yVVj1F1TV51I5kKsixQ3kfXMRu19XoKOLDExR8Vq4Xh8z62sFhRZ5SS3ONao3L4T /QnwVXtdR+ynm2ZXJBMoSx4HANqD1XSZri7iPlTkhzXVS2TXA+QrfJRe6RvJ2cj0 rn0pCg0j3evJ7k/+/ms6Arv5rhLx1BUZ8MYhUoujGNTghjE6yC/6OqPvJwXSnyHL QNQnfI3acfrJ/DgZ2+QwNlPT9fiwXU3rswfxaB88JsOl5u4VagKgQIAd9m0d4cMt 0lk0bgnXRk4SFDh7FezkpxkWxQT0AQAELnNcxuVnCgRpfdTJhHH6/y8WSx9Gd7D7 r9/PYV2CIPIIJz63+TwfhG/qQ4c30VSUp6G3hCqzwCVfrGtZJIQ= =oShZ -END PGP SIGNATURE-
Re: Historic/Retired Routing Registry
On 3/23/22 11:47 PM, Brian R wrote: > Have you tried sending an email to Merit Network? > r...@merit.edu<mailto:r...@merit.edu> > https://www.irr.net/docs/list.html > It seems like the kind of thing they might have legacy info on. > > I did a little bit of searching and didn't come up with anything about > retired IRRs either. You can try searching the nanog list archives. They go back to 1992. In google try: site:https://mailman.nanog.org/pipermail/nanog/ routing registry internic > https://www.google.com/search?q=site%3Ahttps%3A%2F%2Fmailman.nanog.org%2Fpipermail%2Fnanog%2F+routing+registry+internic -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: Standards Compliant Mail Client Re: V6 still not supported Re: 202203211201.AYC
On 3/21/22 1:57 PM, Grant Taylor via NANOG wrote: > Glancing at the headers, it appears as if NANOG is hosted on a Mailman > mailing list. As such, I believe that you could change your > subscription to use MIME formatted digest, which should include more > proper RFC-822 copies of the messages. I believe that you could then > reply to these individual messages directly and match the threading that > I mentioned above. I confirm this would work for the nanog list. IMHO, digest is not the right mode to subscribe if you intend to post replies to the list. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: V6 still not supported
On 3/10/22 3:44 PM, Josh Luthman wrote: > In my rural market, we're the only option for service, simple > as that. We don't care, we don't have to; we're the phone company. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: Cogent cutting links to Russia?
On 3/4/22 3:52 PM, Martin Hannigan wrote: > I would argue they don't have much of a choice: > > "The economic sanctions put in place as a result of the invasion and the > increasingly uncertain security situation make it impossible for Cogent to > continue to provide you with service." But Tier 1's don't pay for peering. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: Ukraine request yikes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 3/2/22 11:57 AM, Miles Fidelman wrote: > There is a reason that the US Government was developing and promulgating > things like TOR, for a while. Turns out if you run 2/3 of the tor nodes, you can unmask people. Governments are not capable of being altruistic. - -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEaESdNosUjpjcN/JhYTmgYVLGkUAFAmIft/QACgkQYTmgYVLG kUDXfA//UX9SGTIeVjb2nVkoEAnACjUVTwYlgBp6JEKWlgSOrXRRu5KFU+sgOVnh nPvOaWh94z/Yw3j/3z5i+7UaTt0tWvaq8ZKI9lCFx3mY1q0gvglCkHGpt/kMSeNS hu+7Yf+DiRulp7quT2M3hr0Jnhbtrmmgn9gxVWik34EsQM9YC0slo1KI8WhnYROX gdT+oYmmHSfurzF36GRqLSJ0VYwqrh8PMWRb6i28IMWlvk893zqAKV/t8itqetxV lx80ZinX4ubTOPhMQuJb+JLXiLgAn1SWFFTIiF8PPoNQ9zFFjm81vhCYGdfsqqhi zvtORNV8S91qlcJzykb7AM3KOFUc5LNpCkZSKZ27wMFbLED20vz+HquZlt1D66pi khUaLbQjdhq3kAY9lsbLSD+0D23ubDQXgxDpFO8lMOJm8AtEKmuaTtI4GjKk2hgj zFdHW08MXzdTeJu5fKRPu0H1/+DWxTY6DLfg2E+OHLDEQYcS78ae6EJMc8IzZauE jxGvewDrrL1QuLerVpYb8Kxzh8Wz9wSZDH46CyfuIV1RD1oyvcQa7UjO4ez2LqoL KQ2YWoMx6GMk6Uxs5ziVABr6RB9wdNmQUcxkpvWM0kPgfW0Ye/PW9R3LhlQkGM3B BAOr12slyktAfhDaCmoYqLbfKtJe5DtA9HVjFj2Xfg4XH1ITz1U= =BWnW -END PGP SIGNATURE-
Re: Ukraine request yikes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 3/1/22 4:08 PM, David Conrad wrote: > See .SU. > > (SU was moved from allocated to "transitionally reserved” back when the > USSR broke up. My recollection is that an agreement was reached by which > .SU users would be migrated out to appropriate new ccTLDs, that is, the > ccTLDs based on ISO codes created for former Soviet republics, and no new > entries would be added to .SU. However, when ICANN tried to propose a plan > to finalize removing .SU from the root (around 2006 or so), the operators > of .SU reopened registrations and complained to the US Dept. of Commerce, > who were overseeing ICANN performance of the IANA Functions contract. > Eventually, the Russian government was able to convince ISO-3166/MA to move > SU to “exceptionally reserved” (like UK, EU, and a number of others) and > forward motion on removing .SU from the root essentially ceased.) I know someone (non-Russian) using .su for a funny name ending in .su. This is non-political and caters only to an English speaking audience. These were registered in the last few years, so they are still open and taking the registrations. I would ask what of .ly used for various URL shorteners, and .kp or .cn? All these are representing evil countries too, why do they get a pass. I'm certain they would argue .us should be revoked for the same. This would break connectivity, and that's a bad thing. - -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEaESdNosUjpjcN/JhYTmgYVLGkUAFAmIejrUACgkQYTmgYVLG kUA+QQ//Z9ovTSFqVEunql2guHAN3xWaNpCpuNJCGM68dJTBSWrPEY0zFXlmZG1k 0TWrSrRSoWogiJmRvaOuFx6KxkaADqZaZq6OFaCw3jvyFGULw+auyuATGlhnUL8p CV0AbovPUnoAef1qJdglFkqnfrGBxeBGsgRIM8tx2l/G+zq5MdMnCx9cM+JmmN1y b+jrV4oekgXRZLAMI/sA9clMAXUmlgReRvit8YBccunkmMP8naQ92vj9dvVGZld0 hGguK2a7vFXpDiW5o0nFe5GRdGIqM0aWUz6p0qkB9JudkZkAyEqSpCePZky4LdAt ebh9544PZu/vllQjv3L6vENlCURcifTIRSevcwfKZtos7UG4mJI1UQ51OLTRjB7a nqYkVNJSQJ+dXZFLPoRHNUOu4+1MAyozpDeMJzMsr4a7Ru2lh0AOTiXxDaSRhOd+ 2s3rQigh/l6cP/x9iM7+f+rInHzPihHfjbwcxhyqd12EFxgTe3hvi9JlRSe18RYw bnDKQg3xKp1eIk0sZMeLyIWDERjsMxIuEP9MuKHp+oTCrLq6MFSgUiFan7M5Pk2t mwB3sbFuwkVzfmDbbnbelll30ukXQM3d7KVp2AHbsvI6hNs6zHZgRb7ZgGrR9Ep5 6UlYqVqQOWtYNujNxYRgzemFI6lgJj8GHyDeh0wLRCP0aw/ATPg= =KK8e -END PGP SIGNATURE-
Re: What do you think about this airline vs 5G brouhaha?
On 1/19/22 10:33 PM, Jay Hennigan wrote: > On 1/19/22 18:31, Bryan Fields wrote: >> The narrower the filter is, >> the higher the loss is. The greater the stopband attenuation is, the more >> elements required and more ripple is present in the pass band. Now granted >> for avionics, this is doable in the thousands of dollars, but older radar >> altimeters will not have this level of filtering, nor can you slap a filter >> on >> avionics without manufacturer support. > > While the passbands are different in these as they're designed to pass > the C-band satellite signals and reject the radar, C-band filters with > insertion loss in the 1.4 dB range with 60dB rejection 20 MHz down have > been available for quite a while. > > https://cdn.shopify.com/s/files/1/0529/5806/8919/t/9/assets/eBPF-C-Spec-Sheet.pdf My point was not they are not available, just that you can't take an existing receiver and slap it in, cuz avionics. It was really on the FAA to set some basic receiver performance requirements as the FCC doesn't care about receivers :) >> Further complicating this, radar altimeters in the 4200-4400 MHz band are >> frequency modulating continuous wave transmitters. In this configuration >> the >> frequency is not closed loop controlled, it can be anywhere in the 200 MHz >> band, as it's modulating a free running VCO nominally at 4300 MHz. This is a >> non-issue as the transmitter is used for the receiver reference, so they are >> locked to the same free-running oscillator. > > Fair enough, but C-band below 4200 has hardly been a desert all of these > years. TD-2 was on mountaintops all over the country pushing a couple of > watts into huge KS-15676 horns with something like 39dB of gain. 4400 > and > above is also licensed for mobile use. Those are narrow beams, typically 4 degrees or less half power beam-width in both planes. >> Only in recent avionics has the receiver been improved via DSP circuits and >> FFT to do real time spectral analysis and pick out the right receive signal. >> The older altimeters out there use simple zero crossing counting to determine >> the frequency of the strongest signal. This leaves them open to potential >> interference by strong near band signals. Exasperating this is the poor >> filtering on the RF receiver in 99% of altimeters when dealing with wide band >> signals. > > If that's the case, how have they dealt with the signals from other > aircraft in busy airspace that are operating in the same band all of > these years? Law of averages. Every transmitter is offset from the others. Since the transmitter is phase locked to the receiver it forms an effective filter for similar signals. > The poor filtering on the receiver is obviously the issue. However, > suitable filters have been available for decades, adjacent frequencies > have been in use for decades, and it isn't the FCC's fault nor the > cellular carriers' fault that FAA has certified crappy receivers for use > in mission-critical applications. Bingo. This is something that the FAA/IACO should have been testing for and set requirements for decades ago. > Somebody using a crystal set to listen to a 1KW AM station 20 miles away > isn't going to get very far complaining to FCC about a new 5KW signal > 100 kHz below it and a couple of miles away. That the FAA would certify > radars with a front-end like a crystal set is the problem. lol; that's what most pulse radars receivers are! >> So can this LTE at C band work? Yes. >> Will it require upgrades to avionics and standards? Yep. > > If the 5G allocation were shared spectrum with the radar altimeters, I'd > concede your point. However, it's at least 220 MHz away, over 5% of the > actual frequency in use. 5% is nothing when you have no front end filter other than the antenna. > All of this talk so far is speculation about potential harmful > interference. Radar altimeters exist. Cell towers exist. Has anyone > gathered any real world data demonstrating actual interference? Honeywell gave some proof of testing in their comments to the FCC. There are others too. I think the potential for interference here is way over estimated, but the issue is one of equipment that may be from the 1960's is not robust to withstand interference in modern times. This is an issue which must be resolved prior to widespread deployment. If it's a FAA certification process or people having to replace altimeters with modern units, then that should have been started years ago. This could be a life safety issue that the FAA and industry didn't address, but you can't just say "your receiver is worse than a baofeng, it's your problem, screw your 220 passengers. The Internet is serious business"
Re: What do you think about this airline vs 5G brouhaha?
On 1/18/22 9:03 PM, Brandon Martin wrote: > One thing the FCC could potentially do to wipe some egg of their > collective faces, here, is mandate that transmitters operating in this > newly allocated wireless band face additional scrutiny for spurious > emissions in the radio altimeter band as well as the guard band between > the two services and a similar bandwidth above the radio altimeter band. The issue is not one of out of band emissions, but rather close but strong signals near the receiver pass band. This can cause compression of the first RF amplifier stage and de-sensitize the receiver so it cannot hear the intended signal. I won't get into the physics, but it is difficult to realize an effective filter that will permit 4200-4400 with low loss and attenuate everything else starting at 4200 MHz and down. The narrower the filter is, the higher the loss is. The greater the stopband attenuation is, the more elements required and more ripple is present in the pass band. Now granted for avionics, this is doable in the thousands of dollars, but older radar altimeters will not have this level of filtering, nor can you slap a filter on avionics without manufacturer support. Further complicating this, radar altimeters in the 4200-4400 MHz band are frequency modulating continuous wave transmitters. In this configuration the frequency is not closed loop controlled, it can be anywhere in the 200 MHz band, as it's modulating a free running VCO nominally at 4300 MHz. This is a non-issue as the transmitter is used for the receiver reference, so they are locked to the same free-running oscillator. Only in recent avionics has the receiver been improved via DSP circuits and FFT to do real time spectral analysis and pick out the right receive signal. The older altimeters out there use simple zero crossing counting to determine the frequency of the strongest signal. This leaves them open to potential interference by strong near band signals. Exasperating this is the poor filtering on the RF receiver in 99% of altimeters when dealing with wide band signals. So can this LTE at C band work? Yes. Will it require upgrades to avionics and standards? Yep. Last time this sort of change out was needed Sprint/Nextel bought every major public safety agency new radios. One could plot the decline of Sprint stock to an uptick in Motorola stock. This reminds me of the Lightsquared case where they were using adjacent spectrum to GPS for low speed data from satellites, and wanted to add in repeaters on the ground, or an ATC/ancillary terrestrial component. Sirrus XM does this, in tunnels and such and it's just the rather low power repeater of the same signal from the satellite. Lightsquared wanted this the be a high power LTE signal, which wouldn't "fill in" their satellite signal but make an LTE network they would sell access on. Do to the proximity to the GPS bands and the rather poor selectivity of the GPS receiver, it would have dramatically limited GPS performance. The issue here is that Lightsquared was too small. The establishment wireless carriers know that commissioners don't work at the FCC for life, and have paid lobbyists crawling all over capital hill. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: . (was IPv6 and CDN's)
On 10/26/21 12:10 PM, David Conrad wrote: >> Surely IANA has the power to compel a root server operator to abide by >> policy or they lose the right to be a root server? > To compel? No. Not in the slightest. That is not how the root server system > works. This is a (very) common misconception. Can you explain how it would work? Say you have a root server operator who starts messing up, is there any ability to remove them? > There has been some effort to create a governance model for the root server > system (see > https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf) but I > believe it has gotten bogged down in the question of “what do you do when a > root server operator isn’t doing the job ‘right’ (whatever that means and > after figuring out who decides) but doesn’t want to give up being a root > server operator?”. Seems like a good policy, 6.3 seems to cover how to fix technical issues with a root operator. > It’s a hard question, but it isn't the folks at IANA who answer it. Who does? Doesn't IANA designate root servers and the . zone? -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: DC Power choices (was Re: Network visibility)
On 10/22/21 1:13 AM, Jay R. Ashworth wrote: > It was, in fact, pretty impressive to look at. But I was a little worried > about > the loading on the building frame. :-) > > And while I think there might be advantages in running power supplies in gear > at -48, I'd want to rectify it in the cage, preferably from 480/3ph. High voltage DC (400v) has all the advantages of DC with none of the lossy drawbacks of -48v. What's nice is most every AC PSU now will run off it with minor modifications, so it's trivial for vendors to support. Nokia and Juniper even do it in the same AD/HVDC supply. I like DC, it's much simpler, but it's a lower volume product. One advantage to AC is I can call any electrocution and they can run a cable in a pinch for me. DC, even though it's the same physics, is harder to find experienced tech to work with. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: IPv6 and CDN's
On 10/23/21 9:30 AM, Ca By wrote: >> Until IPv6 becomes provides a way to make money for the ISP, I don't see it >> being offered outside of the datacenter. > > 87% of mobiles in the usa are ipv6 > > https://www.worldipv6launch.org/measurements/ Mobile is different, v6 makes financial sense as CG NAT doesn't scale to 400m cell phones in north America. (does NANOG scope include Mexico?) That said most (all) IPv6 cellular providers still don't use it for end to end connectivity, as inbound connections are silently dropped. In the US if you want inbound connectivity to work via cellular, you must to buy the static IP service from Verizon, and it has no IPv6 support, and no plans for it in the future. Oddly enough the MVNO services over T-Mobile seem to allow inbound IPv6, but TMO proper doesn't. V6 that works everywhere would simplify a _huge_ connectivity problem for me. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: IPv6 and CDN's
On 10/23/21 9:03 AM, David Conrad wrote: > Bryan, > >> Even the DNS root servers are not 100% reachable via IPv6. > > Excepting temporary failures, they are as far as I am aware. Why do you > think they aren’t? I can't reach C, 2001:500:2::c, from many places in v6 land. My home and secondary data center can't reach it, but my backup VM's at another data center can. > However, the IANA team is not the enforcement arm of the Internet. If a > root server operator chooses to not abide by RFC 7720, there is nothing the > IANA team can do unilaterally other than make the root server operator > aware of the fact. Surely IANA has the power to compel a root server operator to abide by policy or they lose the right to be a root server? >> Until IPv6 becomes provides a way to make money for the ISP, I don't see >> it being offered outside of the datacenter. > > Different markets, different approaches. In the areas I’ve lived in Los > Angeles, commodity residential service via AT (1 Gbps up/down fiber) and > Spectrum (varying speeds) is dual stack by default (as far as I can tell). > I suspect all it would take would be one of the providers in your area to > offer IPv6 and advertise the fact in their marketing to cause the others to > fall into line. Prior ISP charged me $15/month per IPv4 address and a mandatory router rent of $10/month. New one gets $5/month per IPv4 address. The reason for this is IP scarcity. They have plenty of v4 space, so this allows them to charge for it. v6 isn't going to make them any more money as they can't charge for it. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: IPv6 and CDN's
On 10/22/21 11:13 AM, Job Snijders via NANOG wrote: > Another aspect that flabbergasts me anno 2021 is how there *still* are > BGP peering disputes between (more than two) major global internet service > providers in which IPv6 is 'held hostage' as part of slow commercial > negotiations. Surely end-to-end IPv6 connectivity should be a priority? Even the DNS root servers are not 100% reachable via IPv6. I would think IANA would have some standard about reachability for root operators. FWIW, I just was able to change my home office internet (I reside in the most densely populated county of Florida). The new provider sold me a dual stack connection, however when they came to deliver it, there was no IPv6 as promised. After spending almost a week playing phone tag, I finally got some one with clue. I was told they have no support if IPv6 and no plans to ever support IPv6 as there is no way to monetize it. This leaves me in the same position as my prior circuit via the local cable co. (no plans to offer IPv6) but at least it's faster than the 2 meg up cable service. Until IPv6 becomes provides a way to make money for the ISP, I don't see it being offered outside of the datacenter. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: massive facebook outage presently
On 10/4/21 4:47 PM, Jean St-Laurent via NANOG wrote: > > dig @c.gtld-servers.net. facebook.com. NS > ;; > facebook.com. 172800 IN NS a.ns.facebook.com. > facebook.com. 172800 IN NS b.ns.facebook.com. > facebook.com. 172800 IN NS c.ns.facebook.com. > facebook.com. 172800 IN NS d.ns.facebook.com. > > What happens if the NS aren’t back within 48 hours? Facebook can just update it at the registrar. $ whois facebook.com Domain Name: FACEBOOK.COM Registry Domain ID: 2320948_DOMAIN_COM-VRSN Registrar WHOIS Server: whois.registrarsafe.com Registrar URL: http://www.registrarsafe.com Updated Date: 2021-09-22T19:33:41Z Creation Date: 1997-03-29T05:00:00Z Registry Expiry Date: 2030-03-30T04:00:00Z Registrar: RegistrarSafe, LLC $ dig @c.gtld-servers.net. registrarsafe.com. NS ;; registrarsafe.com. 172800 IN NS a.ns.facebook.com. registrarsafe.com. 172800 IN NS b.ns.facebook.com. registrarsafe.com. 172800 IN NS c.ns.facebook.com. registrarsafe.com. 172800 IN NS d.ns.facebook.com. crap Vertical integration is a hell of a thing. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: Rack rails on network equipment
On 9/24/21 10:58 PM, Owen DeLong via NANOG wrote: > Meh… Turn off power supply input switch, open chassis carefully, apply > high-wattage 1Ω resistor across capacitor terminals for 10 seconds. > If dealing with a charged capacitor, do not use a low resistance such as a ohm. This is the same as using a screwdriver, and will cause a big arc. You want to use a 100k ohm device for a couple seconds, this will bleed it off over 5-10 seconds. Most (all?) power supplies will have a bleeder over any large value caps, and will likely be shielded/encased near the input anyways. If you let it sit for 5-10 minutes the leakage resistance will dissipate the charge in any typical capacitor. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: An update on the AfriNIC situation
On 8/27/21 6:38 PM, Bill Woodcock wrote: > > >> On Aug 27, 2021, at 10:07 PM, Bryan Fields wrote: >> I’d expect that for a court to freeze assets of AFRINIC there must be a very >> strong argument. > > You know what’s funny? There are a bunch of other people copying-and-pasting > that same expectation on the AfriNIC and APNIC mailing lists, and they’re all > beneficiaries of something called the “Larus Foundation.” So, if you’re not > getting paid to copy and paste that, you might want to look into it: > > https://www.larus.foundation > > I hear it pays pretty well. > > -Bill > Bill, I'd respectfully ask you to consider that my opinions are my own; to imply differently is wrong and to do so publicly is worse. I'm not a shill, paid or otherwise, rather a member of the community looking at this from the outside and trying to understand it better. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net signature.asc Description: OpenPGP digital signature
Re: An update on the AfriNIC situation
On 8/27/21 4:30 PM, John Curran wrote:> > ARIN does not normally comment on disputes or related litigation occurring > at another RIR, but this matter has become quite different, as it is both > highly public and has potential for significant impact to the overall > stability of the Internet number registry system and thus to ARIN and its > community. Perhaps what's needed is for parties to be able to move their allocations to a different RIR if they don't like the service their incumbent RIR is providing. >> I’d expect that for a court to freeze assets of AFRINIC there must be a >> very strong argument. > > Indeterminate at this time, since a “Freezing Order" issued via ex party > hearing doesn’t actually test the strength of the arguments, as the > affected party is not present to respond. It is only when the case for the > validation of the order is heard that the strength of the arguments could > possibly be assessed. Note - the full list of cases filed are here > <https://afrinic.net/court-cases <https://afrinic.net/court-cases>> for > reference. That's interesting, but that normally one would expect the bar for such and ex-parte order to be high. I'm not familiar with the Mauritius legal system; I do know it's some combination of common law and french law, but it's generally stable/impartial for business law. What we really need is a groklaw-type that could take this up. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net signature.asc Description: OpenPGP digital signature
Re: An update on the AfriNIC situation
donment was in the face > of queries for additional information to clarify the inconsistencies in > your request. We are generally able to get past these situations with the > vast majority of organizations with legitimate need for the address space > per ARIN policy, but I also acknowledge we cannot know how many of those > who did abandon were for non-qualification versus other reasons. > > 5. Unless ARIN admits it has been given the justification submitted to > AFRINIC by Cloud Innovation in past years, we don't think it is within > ARIN’s mandate to comment whether it is being used for the same purpose or > not. John, please clarify, have you received the justification material > we submitted to AFRINIC? Do you have any inside knowledge about it? We > would be very keen to know if AFRINIC has disclosed our private data to a > third party in this process in violation of the very agreement they > (unjustly) accuse us of breaching. > > I have no opinion regarding the justification submitted by Cloud > Innovation’s for number resources from AFRINIC, and have not seen it. > > I _have_ asked a simple question of whether Cloud Innovation’s usage is > within the remit and purpose for which they were originally justified, and > I observe that this question has been asked repeated by many others in the > AFRINIC community. > > This question does seem relevant to the dispute so please don’t be > surprised if you are asked it quite often until such is resolved... > > Again – Is Cloud Innovation’s use of the blocks in question within the > remit and purpose for which they were originally justified? > > 6. We find your discussion of the RIR stability fund most interesting… > Please correct us if we misunderstand, but our understanding is that the > fund requires the unanimous consent of all 5 RIR CEOs in order to be > utilized. As such, it appears you are attempting to mislead the community > by making a 20% promise as if it were a 100% assurance. > > My statement reads - > > If AFRINIC requests support in accordance with the Joint RIR Stability > Fund, ARIN will support such a request. Furthermore, and without > reservation, ARIN stands by its unwavering commitment to support AFRINIC > and will take any and all measures necessary to ensure that neither the > African networking community, nor the global Internet number registry > system, is operationally impacted during this period. AFRINIC was formed > (and has accomplished so much) for the benefit of the African networking > community and ARIN stands with the community in dealing with those who seek > to disrupt or exploit it for their own benefit. > > It’s fairly self-explanatory and of course pertains simply to ARIN’s > support for AFRINIC during this period. If you did not take that away from > your reading, hopefully that is now clear. > > For the above reasons, we think that Mr. Curran has not provided a balanced > or fully accurate representation of the facts to the ARIN community here > and we hope that the above clarification will help members of the community > come to a more fully informed opinion. > > A vigorous discourse is a wonderful thing - I actually welcome your > clarifications as noted above (e.g. you prefer to characterize your ARIN > request as “abandoned” rather than it having been denied) > > You apparently can clarify quite a bit when it suits you, but still fail to > respond to the most basic yes/no question - Is Cloud Innovation’s use of > the blocks in question within the remit and purpose for which they were > originally justified? > > Finally, while we realize that this is inappropriate for PPML, as it does > not really touch on any ARIN policy discussion, we believe that Mr. > Curran’s post could not be allowed to stand without rebuttal. Since he > chose to make such a non-policy post to PPML, we felt that our posting of > the rebuttal here was justified. > > Unless Mr. Curran or other ARIN staff member(s) choose to further engage on > this topic here, this will be our only post on the matter to this list. We > would also welcome the opportunity to take the discussion to a more > appropriate ARIN list if Mr. Curran prefers that alternative. > > Excellent point. I have taken the liberty of replying to Owen’s post here > on nanog for clarity, but also suggest we continue this on arin-ppml so as > to spare the NANOG community. > > Best wishes, /John > > John Curran President and CEO American Registry for Internet Numbers > > > > - -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEaESdNosUjpjcN/JhYTmgYVLGkUAFAmEpRgwACgkQYTmgYVLG kUAhLg/7B82+gbK4YjMwENBKIoL+53vB/H5DVo4WFHmDekadrsD8NkD39MxYAR
Re: A crazy idea
On 7/20/21 10:01 AM, Michael Loftis wrote: > My apologies to everyone using an HTML mail client. No reason to apologize for that. If someone is careless enough to use an HTML client on a mailing list, they deserve what they get :-D -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: A crazy idea
On 7/19/21 8:09 AM, Stephen Satchell wrote: > First, I know this isn't the right place to propose this; need a pointer > to where to propose an outlandish idea. > What would the domain names look like? Let's take my current IP/IPv6 > assignments from AT: > >2600:1700:79b0:ddc0::/64 >99.65.194.96/29 > > The IPv6 delegation would be easy: > >> 0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. NS my-DNS-server-1. >> 0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. NS my-DNS-server-2. Yup, simple, I do this for my customers (and DS records). However that reverse zone has DNSSEC on it. You'd need a DS record to tie my-DNS-server-1. to the ATT DNS server and your server would need to support DNSSEC. ATT may want to enforce DNSSEC on that zone, but not want to sign stuff they can't control. Just playing devils advocate. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: Email and Web Hosting
On 7/6/21 3:26 PM, Steve Saner wrote: > The current platform is a custom collection of open source software, smtp, > imap, pop, webmail. Web hosting is a basic LAMP stack all php 5.2 or > greater. There is no interest in growing these services. Ok, so this really doesn't say much in terms of software in use. Almost all SMTP/IMAP/POP servers are open source, and could be anything from sendmail 8 to postfix. If you're capping it, just run what's in place and learn it, I'd think most people in networking have configured apache once or twice before. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: Email and Web Hosting
On 7/6/21 10:41 AM, Steve Saner wrote: > I hope this isn't too far off topic for this list. > > We acquired a small ISP a couple years ago that has its roots in the "local > ISPs" of the 90s. This ISP is still hosting email and web services for > customers both on company domains as well as customer domains. There is > some decent revenue coming from these services, but cost of maintenance is > becoming a challenge. We are looking at migrating to another platform or > completely discontinuing those services. Question, what platform(s) are you running now? What must you provide for email, SMTP, IMAP, webmail, groupware, etc? Do you have any intention of growing this? For the websites, what do they need? Are you running any old PHP 3/4 stuff? You can setup a control panel, but if you're not running one now, and you're not going to expand it, why not just cap it until it becomes unprofitable? I'm a proponent of hosting my own email, it's not that hard and any ISP should be able to do it. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: FCC Proposes Ban on Devices Deemed a Threat to National Security
On 6/17/21 1:50 PM, Sean Donelan wrote: > The Commission also seeks comment on whether it should revoke prior > authorizations for any equipment on the Covered List This would make any of the "Covered List" equipment illegal to use in the USA. Almost everything needs to have a part 15 certification with the FCC, this would then open up network operators to being fined for every device they still have in operation. https://www.fcc.gov/supplychain/coveredlist -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: New minimum speed for US broadband connections
On 5/29/21 11:39 AM, Lady Benjamin Cannon of Glencoe, ASCE wrote: > Good point, but developments in QAM technology benefit both fiber and radio > nowadays. You can't escape the limits of physics here. Doubling your QAM means you loose sensitivity, and typically limits your transmitter power to low levels. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: Something that should put a smile on everybody's face today
On 4/28/21 1:50 AM, Mel Beckman wrote: > NANOG is not the right place to post this. This list is not an “interesting > news group”, and as fascinating as the patent troll take down is, it has > nothing to do with operational issues. Read the AUP, if your don’t believe > me. Item 8: > > Posts of a political, philosophical, or legal nature are prohibited. Mel, Looking at the usage guidelines https://www.nanog.org/resources/usage-guidelines/, did you notice the section "How to report a violation of these guidelines"? #1 states "Subscribers who are subject to or wish to report a violation of these guidelines should contact us at admins [at] nanog.org." Did you make such a complaint? I didn't notice anything stating reporting it on-list is an option. In fact rule #15 seems to prohibit filing complaints on list. I'm certainly not going to make a formal complaint over what I'm sure is an out-of-character email. FWIW, I found this of great interest. The existence of overly broad patents such as this harms the entire operator community and internet in general. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: DOD prefixes and AS8003 / GRSCORP
On 3/15/21 4:01 PM, Christopher Morrow wrote: > is it possible that the DoD: > 1) signed a lRSA (or really just an RSA) Just re-read this; I don't think the Federal Government is required to sign the standard ARIN agreement. I believe they have a different agreement with ARIN. I did some searching, but can't find this easily on their website. Maybe John can confirm this. I don't this this is nefarious at all. If there's a contract for this, a FOIA request is likely in order. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: OOB management options @ 60 Hudson & 1 Summer
On 4/16/21 1:33 AM, Saku Ytti wrote: > https://www.markleygroup.com/cloud/network/out-of-band Wow, this is an impressive offering. I wish more providers would do this. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: OT: Re: Younger generations preferring social media(esque) interactions.
On 3/24/21 8:44 PM, Michael Thomas wrote: > FWIW, nanog doesn't alter > messages. All lists have the option to follow suit. It does. There's a setting in mailman that's enabled for the nanog list. dmarc_moderation_action (privacy): Action to take when anyone posts to the list from a domain with a DMARC Reject/Quarantine Policy. It's set to Munge From. So if your domain had a reject policy on DMARC, nanog will munge the from: header to be 'Your Name via NANOG'. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: OT: Re: Younger generations preferring social media(esque) interactions.
On 3/23/21 8:04 PM, Michael Thomas wrote: > This has the unfortunate downside of teaching people not to pay > attention to the From: domain. For mailing lists maybe that's an OK > tradeoff, but it definitely not a good thing overall. I noticed that the > IETF list does From re-writing for DMARC domains that are p=reject. This is another reason why DMARC is a shitty solution. NANOG will rewrite the From: as well in this case. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: OT: Re: Younger generations preferring social media(esque) interactions.
On 3/23/21 7:00 PM, Sec Lists wrote: > To just give in (or up) and say, well, that's what the youngsters now > prefer is to move even more towards a world dominated by a few global > monopolistic players who don't give a darn about open standards, open > protocols, not locking people in, decentralisation and fedaration "If you want a vision of the future, imagine a boot stamping on a human face - forever." :-) -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: Cox Outage - a little humor for the day
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 3/24/21 4:15 PM, Chris Moody wrote: > Apologies in advance for the random message to the board, but it IS > provider-related and gave me a good chuckle. > > Sometimes the timing of events just presents it's own humor in beautiful > ways. > > My wife's office just lost all connectivity and they received a status > notification from Cox Communications. > > While checking the company's twitter for any status announcements, Cox > had posted the following webinar just an hour ago. I don't get it. - -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEaESdNosUjpjcN/JhYTmgYVLGkUAFAmBb2DwACgkQYTmgYVLG kUDIrxAAsjzxt6rr3W5GPpDcS+QWqFZO5qFSAjYa05zOprQI6PLfDRlF+Fi/HZzM 3pzlyNKDzqFbRNgpGhTOPn047cfm496204n8psJpm+SMxGaxhU0g1E4W511qoypV PvguiFh9YHpZA+EelSXo2sk/zPsOxIvLVdY+LuOo1kF4nE7oeXOr7XrkPmurqZQu 7uGKxXLWos51RUg8jcsj+HRNESlN5jxjr3D2nnE19cYK9njJHUCXlQguSIwRlNIP eWEn2jBsPZqPBdtxxMWjmsj+SxTJ4r+tRQstAiaAJEwu9PVw+clBI7BJYVIp3Wv/ 5NXc6xihFP9efI/lyFGFL6AXtHT8XYgqnW4DTV0JA4PLaSdZdIzHXmwC1mhYCk0+ kbnB4hJyoKhOl7G9TGG0ofho7NNFPGnGg8EYhPVbicNMPNfST80J1XwPZ9gbi8bw +0al/C4rxuOJFRavrIGWLuy4gxs4tVXUYi8KSnjy3J0S93+lqrr8THhbXpE06FXk oP91WfrCUn2q7so6o1Gvz+iuZXZQlOBffI/NtsiG11Zhf7pghC33m1EBah2u8/23 0MmMjr3w/qYcuB6ocTV3ZYYUgJLvGxyNxV6W3tq3An2967mqQDhsBmSOzYt1bbMF DmHvT4YNTY634MvMpwgKqm48Z+EfWg+HqJ8qRwIh77CI46bn5cI= =5pIm -END PGP SIGNATURE-
Re: Perhaps it's time to think about enhancements to the NANOG list...?
On 3/22/21 10:00 AM, Mike Hammett wrote: > The migration happened just a month or two ago. Are we talking about the same > thing? I'm talking about wirel...@wispa.org which started after isp-wirel...@isp-wireless.com went away. What sad is the archives from this are gone too. > TBH, most discussion in the WISP space has moved to Facebook. The busy WISPA > mailing lists used to get about 20k messages per year. When I last checked, > they were down to 5k or so and on a downward trend. Meanwhile, the Facebook > groups have exploded, both in members per group and the number of groups. Cancer. There's nothing but an echo chamber in facebook. Taking time to compose thoughts in email elevates discourse. Top posting "me too" to a forum destroys it. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: Perhaps it's time to think about enhancements to the NANOG list...?
On 3/22/21 9:05 AM, Mike Hammett wrote: > Usually efforts like this suck, but whatever WISPA did this year with the > migration from a mailman system to an integrated forum\mailing list solution > seems to work really well. It's not exactly like mailman, but it works very > well. I used to read that, and ISP-Wireless prior, but after the migration it just stopped working. After migration the content quality went down and the pagination on a forum sucks. The other major issue with a forum is it allows any admin to go in and edit your message/post. Unless you've setup moderation on the mailing list, this is generally not possible. The other advantage to a list is you can sign your messages to prevent these sorts of shenanigans. Simply put, if the option is there, it will be used. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: Perhaps it's time to think about enhancements to the NANOG list...?
On 3/20/21 2:06 PM, Randy Bush wrote: > i do not find the volume or diversity on the nanog list problematic. > in fact, i suspect its diversity and openness are major factors in > it being the de facto global anything-ops list. perhaps we do not > need to fix that. +1 -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: DoD IP Space
On 1/20/21 12:52 PM, John Curran wrote: > On 20 Jan 2021, at 12:17 PM, Bryan Fields > mailto:br...@bryanfields.net>> wrote: >> >> AFAIK IANA and the RIR's cannot enforce use of IP space assignments on any >> network. > > While route hijacking isn't necessarily an ARIN issue, I will note > that several US law enforcement agencies (FBI & NCIS Cybercrime units) are > quite interested in such events and do investigate them looking for criminal > activity. > > (See > https://pc.nanog.org/static/published/meetings/NANOG77/2108/20191028_Elverson_Your_As_Is_v1.pdf > for details.) Can you ensure quoting is done properly? I don't want more confusion between what I wrote and the reply. Nowhere did I state this was used to be for criminal or less than above board use. As soon as an entity decides to engage in criminal activities we're beyond the question of what numbers they can run on their network. I can't think of a worse entity to hijack space from than the DOD. Very few other AS's have the ability to make it rain fire over a hijacker's NOC :-) My comment was in terms of what a private network can do inside their own network, or as part of a multi-entity network that is separate from the "Internet". The bigger question is, should you do this? The answer is no for a host of reasons, as networks rarely stay private. Even the GRX went through a big cleanup relating to this, and as of the last 6 years (maybe more) requires space used to be allocated via the RIR's and not RFC1918 space. IIRC they still allow private ASN's. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: DoD IP Space
On 1/20/21 10:05 AM, Dorn Hetzel wrote: > I am aware of some companies that have used parts of a DoD /8 internally to > address devices in the field that are too old to ever support IPV6. Those > devices also never interact with the public internet, and never will, so > for them, I guess the only risk would be that some other internal system > that wants to talk to those devices would not also be able to talk to any > endpoint on the public internet that wound up using space allocated from > that block, some time in the future. Is that about right or am I missing > some key failure point? You're free to use any IP space you want internally, no one is going to tell you what to do inside your network. Most providers will not route it for you though. There are some exceptions to this, the GRX being one, but that's it's own VPN and separate network from the global Internet. IIRC, here was some VPN provider using 5/8 before that was assigned. AFAIK IANA and the RIR's cannot enforce use of IP space assignments on any network. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: opportunistic email encryption by the MTA (not MUA)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 1/15/21 7:22 AM, Brian J. Murrell wrote: > I think in practice the old adage that "e-mail is insecure" is becoming > untrue, by a significant amount, I suspect, due to the prevalence of > STARTTLS. It's still stored unencrypted on the server, and the admin can see all. If you want it secure, you have to run gpg and encrypt the body. - -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEaESdNosUjpjcN/JhYTmgYVLGkUAFAmABtBgACgkQYTmgYVLG kUBjBQ/+McM45Kab7YdmzeqIeoZcR8Hy2JIZo4cWj/bQdKxzjIhZmvxacK8FJWwJ 06Vd3QynYLO2pRi/7GAJ6vLhNFd6Q2Nhh5ABADpwj6h0hWz4ULQ7hm1Wn8vdIofN lOCef4xHYTIXGVN//QgWaUqdogwup3QdBbbWQsAh3rNbW9jYq4UrIGaEpVXJ+tsp h55eoDcmX8P/SGkL4B0WBiv3IzMGfRMlcPHCRU7xCrQLCW34KEOcog2QyBv6ZSAk yT3fsy8uiNg5S464YqXGEQT9/LuWDl1yMSJ4nhVDDAp+mbAcMCbpl7Hb3IWzUAJj 0v8D5yoUhYBeamCfTj19DSCnMONUAMlPlEiIlfQXvdrQaRBL2QJjwooGU5lDG+Zm u/8M+M8bUNjSF2V7Y7JwszBkx1lkGuVMdXKjhnMM2/M+56AD9BJAsq2M2nEzE8Xz CoAglEhUoL3vNN7HiLBrN8heGtF2aOXSI2cU9qzgL44d28nz+OyxWyiv3GWTYETA mWCIz8RuYLwOh+EzAsx9AzsPhAYPUJnTMwdZb65QYsdXpDKtw3fvKrASHcJtn4I4 lxhCD66wOsJY/mypaDB973L7eyvUTVL/2E1qkXYbGVw/X5wxv6ohWr5zR7IbqLVY FBTMsVnV4VcJsSLtCYku4BNWl4knYN7f8tQcVcMbpiToEYJXP3Q= =Mo06 -END PGP SIGNATURE-
Re: DoNotPay Spam?
On 1/13/21 5:06 PM, Robert Webb wrote: > Anyone else getting spam from DoNotPay everytime they send an email to the > list? > > I have not sent anything in a while until my ATT email and now I am getting > this on every new email I send to the list. yup, I've spent a few hours to gleam who might be the source of it. It's almost impossible to trace as they have the email subscribed as a normal user, and then harvest the sender address and send it from a totally different spam server. What you can do is when you notice these, email geeks@nanog with the full email including headers immediately. We can then cross check it against new signups. I wish there was a more scientific way to process it. Thanks, -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: Parler
On 1/11/21 1:33 AM, Randy Bush wrote: > it is really annoying that you leave not the slightest clue to who the > hell you are replying If you use a threaded email client (MUA), it's really easy to see it. It was a reply to sro...@ronan-online.com's email of 10 Jan 2021 08:42:56 -0500 His MUA set the "In-Reply-To" header, and thus it was referencing the Mesaage-ID of 474fe6a6-9aa8-47a7-82c6-860a21b0e...@ronan-online.com of the email sronan sent. Most modern MUA's can process threads and make it really easy to read lists. This excludes outlook which doesn't set these headers and is basically impossible to use on any standard mailing lists for this and other reasons. I use Thunderbird and mutt, both support this threaded format. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: Parler
On 1/10/21 9:48 AM, Michael Thomas wrote: > Is it content moderation, or just giving the boot to enabling criminal > activity? Would that more providers be given the boot for enabling voice > spam scams, for example. Didn't one of the $n-chan's get the boot a > while back? I don't seem to recall a lot of push back about that and it > was pretty much the same situation, iirc. There's legit users of parler and 8-chan. Not every one is on the racist/insurrectionist/etc. sections. And who's to say they have less of a right to their unpopular speech than I have to discuss retro video games? This seems like it raises two interesting questions: 1. When should a contracted provider be able to discontinue service with little to no notice to the customer if they find their content distasteful? 2. Where do we expect legit insurrections to communicate? Should AWS/Facebook/Twitter boot those calling for violent uprisings in Hong Kong (for example). I suppose #2 is simply one mans freedom fighter is another criminal. Anyone hosting with Amazon/Google/the cloud here should be really concerned with the timing they gave them, 24 hours notice to migrate. Industry standards would seem to be at least 30 days notice. Note this is not the police/courts coming to the host with notice that they are hosting illegal content but only the opinion of the provider that they don't want to host it. I seem to recall a customer who was using provider IP space that sued and won an injunction circa 2004 against their provider allowing time to migrate. I remember reading the decision and was taken back by the decent grasp the judge had on BGP/IP space. I can see how this might be similar. Many years ago I was CoLo'd at a facility which shut off the racks of a customer at 9am on a Monday after finding said customer had poached an employee from the provider and was intending to compete with services the CoLo offered. They physically disconnected the cross connects to these racks for this and banned the customer's employees from the facility. Their counsel even told the customer "any contract is voidable at any time". Basic planning for any company should ensure you never have all your eggs in one basket. Perhaps this was a bit dumb on the customers part, but they had a contract. The cloud is just someone else's computer.. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: 10g residential CPE
On 12/25/20 1:03 PM, Cory Sell wrote: > Just because nobody is mentioning it - you can always build a > pfSense/VyOS/Vyatta box in whatever form factor you’d prefer. Even can run > within a VM if you really want to. My point was the gear is not there yet for the non-technical people. Anyone can roll their own router for cheap, but that's a science experiment. It's akin to a WISP in 1998 running karlnet on a pc with wi-lan cards. Sure you can do it, but there's no one to support it. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: 10g residential CPE
On 12/25/20 4:52 AM, Mark Tinka wrote: > For the home, if you're looking at shipping 10Gbps-based CPE's for under > US$200, I can't think of anything other than the Tik: > > https://mikrotik.com/product/rb4011igs_rm That has 1 10g port. How can that be a 10g CPE? > They claim: > > - 2.6Gbps forwarding for 64-byte packets. > - 7.8Gbps forwarding for 512-byte packets. > - 9.7Gbps forwarding for 1,518-byte packets. so, not 10g :) Add in some services and I bet it goes down from there. The bigger question in all this if you're doing 10g to the residential user, what are they going to use for their home router/NAT device? Even 60 ghz wifi routers top out at like 5 gbit/s, and NAT at this speed means a powerful CPU. 10g to the home is a great idea to think about, it's just not terribly practical for most customers unless they want to drop 1-2k on routing gear and nics. This is always changing, but it's going to be a few years until we reach the right performance and price point. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: Spectrum (AS33363) Clue?
On 11/19/20 10:22 AM, Brian K Miller wrote: > Good luck getting info out of them, I usually just run my mouth with the > local guys when they come out, I get more info that way than in a ticket. It appears they have fixed some of the issues today, our packets are no longer going across the country to get across the room. Latency is down to the historical averages, and we're no longer having throughput issues. I'm a paying business customer (125/mo for 20/2 mbit connection), so I'm going to bitch to high hell when it's impacting my business. Thanks to everyone who reached out, -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Spectrum (AS33363) Clue?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Is there anyone at Spectrum business with clue who can contact me off list regarding some peering issues in your network? I have several customers seeing 150ms of latency due to traffic bouncing between east and west coasts to go across the room. This is between routers both in TAMSFLDE. Support has said this is "normal" and refused to escalate it. Some quick testing with RIPE Atlas probes shows it's the same across 33363. Thanks, - -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEaESdNosUjpjcN/JhYTmgYVLGkUAFAl+0N20ACgkQYTmgYVLG kUAsBQ/8Cu5i3rH98K/pEwawV391d++V8dQWrFosYEz6Yp99OTJg3K2NcgI5wYGj +cfTYbw2sGTQUB57bIxZbpAYIV1KIeEwHckQ2P/2coud9y8yeuFjSY2kEYl5HpoV T9Q8bIw8XTvZgPZYvQ9VPry4zWscV+2OoHEZQpQSN4MOyjN1Oj+w36/nM3La+Dp3 RaQkbKKW44LcAgqn4wUqdZgmZcYpsgz+RyA9hbbvT3tl7693LdD4XcenULo0t4kS cu0YcoDA7+2yoTdF7yzabl0qPwhqfhTPEYczWxHEqfEXN0NebV5Nqj4pMAQfQFZ2 mEyckAx84+hL2op0XVXYPnbU6Kd3i5JZxcHOwXIp5Kk0LvZVSfMypseAAPRzS/M+ PXbnlqFYf350VOjV7rQn23UWo5kduxzvOyc+bYGAvsqJWYumpIGYqe05EHQqYiBO RTuJoOLmEYfg52OML/ih0M9UPGtluIZvvMPv+jLmbyVt2COjaJnVGiWWfrIjkQqr 2kjIRrja3RTvHZHVUHHyZZMdfjufjb2fIhboHDhhEueEMSPBdzCb+j241IrG4IHb sDWkhkcdXyN82htvEocZDJqGGMQqzCP86TWoefjN3YOjKMLl8kL9HgRV7eZGZJc9 6cbQrh50mWHQtYgki9a0+3Sk9Eu7cJIWSAA4p6l3WaOa80VGbEw= =BfB0 -END PGP SIGNATURE-
Recent List Spam
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Looks like this recent spammer has been removed from the list. They were moderated, and using the email address From: or known users. Thanks, - -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEaESdNosUjpjcN/JhYTmgYVLGkUAFAl+NvKMACgkQYTmgYVLG kUAcGRAAlQ/VmB99Y+by+BPQpNVFnlAHC2vtBz4fqXINHg0rONhsyc6I8RVfvSnN bxrWh5ewduqnQPQzIB14FFMCiNqSQUqro8iYh3bZ/BknQ3nPn82zUjyGD1BQBMUv Iv43O57OGc7rK/z1SS2xzMedmsSdUsRbwEHP2lSWqXvNBWnuG17lC2ITvGf796UR I1BYj/eh5bp262KBDQfTxGuX+4FECVd8aho8wWQxVwJil5R7sMuDpHFn/Ikm1Bde SevZ5JaW4NyX0RxOjGlNWFM7ic76GVxdAj4I3sCkokVkuSf9kh4rNrbU+VFwMJ/h iqR/qCKPEGeDotFj8GpCBogb8ywAzn6wUwKVB5Ax9hWyrolIsxODS939HF1ayVah 9PL6bcVo1yKu458VmV7kdsy16zHGQnMoE0giZfbqQvxyKyE6CzqJnDN7UFfNH+Nv lKxHJwpx7YC2Wr4co7tZrXUSOq2RbyV39BkPetFo8zGy5lqs6vfzDsHwIdAGYkgU 14N45NW/g9sLDxUOso7pT1EsLGpF/Cl86MVp9A8wP4A0U1kqZJbHnWXYloSS0qq5 ideKbex+keLOBuTqbZ2/+NOpi+8C+t8kGdAu+H5Hr/a/wvlD8zMpE9OP1fKbycAk e4HadiStrFj9/PH4CecT4jNc535KcOGePmA6EFOlPMEV//K8L7I= =PfBg -END PGP SIGNATURE-
NANOG SPAM (was Re: Just got this apparently fake NANOG invoice - Looks phishy)
On 9/21/20 7:28 PM, Mike Hammett wrote: > Can we please send this stuff to the admins and not the whole list? Both the list admin account in the headers and the ge...@nanog.org is monitored and responded to. If you don't get a reply, you all have my email too. What's happening here is a subscription comes in from a valid email bot using gmail or $BIGHOST (google doesn't give af) and that doesn't send email. The list posters are then spammed from third party address(es). It's frankly hard to track down as only posters get the spams, not the whole list. That said, the geeks team knows what to look for to kill this when it happens. Forward the entire email including _FULL_HEADERS_ to ge...@nanog.org. We will kill it and ban them from the list. Thanks, -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net signature.asc Description: OpenPGP digital signature
Re: A spammer is harvesting email addresses from the NANOG list.
On 6/20/20 6:42 PM, Bryan Fields wrote: > On 6/20/20 5:33 PM, Tim Pozar wrote: >> Looks like a spammer is harvesting email addresses from the NANOG list. i >> I will be unscribing as I don't need this additional noise in my mailbox. > > Do you have the full headers of these emails? Please send them along if you > do. > Tim provided these and we've removed the interloper. Should anyone see anything like this again please send the complete email with headers to ge...@nanog.org. Thanks, -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: A spammer is harvesting email addresses from the NANOG list.
On 6/20/20 5:33 PM, Tim Pozar wrote: > Looks like a spammer is harvesting email addresses from the NANOG list. i > I will be unscribing as I don't need this additional noise in my mailbox. Do you have the full headers of these emails? Please send them along if you do. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: 60 ms cross-continent
On 6/20/20 1:56 PM, Saku Ytti wrote: > On Sat, 20 Jun 2020 at 20:52, Wayne Bouchard wrote: > >> And thus far, no one has mentioned switching speed and other >> electronic overhead such as the transceivers (that's the big one, >> IIRC.) > This will be something from tens of meters (low lat swich), to few > hundred meters (typical pipeline), to 2km delay (NPU+FAB+NPU) per > active IP device. If that is a big one, I guess it depends, cross > atlantic, no, inside rack, maybe. I think he might be referring to the newer modulation types (QAM) on long haul transport. There's quite a bit of time in uS that the encoding takes into QAM and adding FEC. You typically won't see this at the plug-able level between switches and stuff. 60ms is nothing really, and I'm happy I don't need to play in the HFT space anymore. I do wish my home connection wasn't 60 ms across town as spectrum wants takes TPA-ATL-DCA-DEN-NY to get to my rack. :-) -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: NANOG List Maintenance Complete
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 6/20/20 12:26 AM, ge...@nanog.org wrote: > The archives for each list have been extended with all prior > posts. Please see: https://mailman.nanog.org/pipermail/nanog/ If anyone has an archive of messages prior to 1992 please hit up the geeks with it. It's my understanding this is prior to NANOG being a group under Merit, and I'm unsure of the history or how any of the lists were handled at that time, or what software was used. Thanks, - -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEaESdNosUjpjcN/JhYTmgYVLGkUAFAl7tkh4ACgkQYTmgYVLG kUBoNA//XD3aOcFwrjHNu3/eJj/i2lvTcL9kHusXtXbrXs24sxN6gKAKbQ74nKNj uue30cqsGlTQwjkExwjrdn+LiDxi/Q9rgILkKzDPFDlwz5r8fsnDWV0HggpACaEp zv1Fot+kfnXE2aqTEwD7QSH6ZFa3muwD+IdQuFH71N/m8oKsaKDWh3aSwj0jsX+G 5p6g1nPAYhCk1O/v98FVMZEOfUnb2j830fLYfWypMM9h53q2ScdEUwBKTmhiQqv7 eHVBb0l1yhnaOcJ3c5mIMNgyZK9BhI2MrJLNmS3R6z9XprCQ+I2KP2tyTv2tWAzO DFgoaiUJTVfOzbWQSeiGdYSRI7cb2yYXe46KaTRJIQgOBKexoqgyaCMLgFHUY2jM HALa/f6/NOLY8PFNGHXPU1AkbZKdF7FlK1bNqlIwJWe/kZAIMS5xWMjb4KKDL5zn twytQqjfKAxHCD+D0m4UMu/H73GOlzF/26XGFc2Z7ILnzqn/5tHDO3mXzlxL5myR a3TN5lDTd7khITcibb4wF3W0oWfu0/amGNDwBFyYrpOd44Cf9odbixZ9/OA3nYgf Jwa08iFLdy+BzaMVcV1cebkf4NtGx69spST3MjISlQxiFXrM9foWexDi9drdszsT T0mb5MgATJ2er2gyB3dOtr4MtmCsxfXlDAXnDF0EANmmbnLr45s= =thzK -END PGP SIGNATURE-
Re: Mikrotik RPKI Testing
On 6/17/20 10:38 PM, Musa Stephen Honlue wrote: > Did you face any issues with IPv6 on 6.4, I personally have participated in > deployment projects on Mikrotik for many large networks. > > And it worked well in the end. The problem I ran into was having it support SLAAC for assignment of IP addresses for management to a management vlan. We have a number of them setup as bridges, and use ipv4 for management now, but can't seem to make them configure IPv6. I've run into several issues with them doing bridging as well. Perhaps the worst is there's still no way to associate a MAC with a bridge MAC. This means we can isolate problem MAC's on an AP level, but then have to dig into the FDB of each individual node on that AP. These aren't ideal, but at the price point, we put up with the issues. :) -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: Mikrotik RPKI Testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 6/17/20 2:06 PM, Massimiliano Stucchi wrote: > I'm only living without IPv6 for the moment, which is painful... Fyi, your signature is bad on that email. How is IPv6 coming on Mikrotik? It's a no-go at least for my deployment on 6.4 code. Not sure I want to run beta in a quasi-production network. Thanks, - -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEaESdNosUjpjcN/JhYTmgYVLGkUAFAl7qYXkACgkQYTmgYVLG kUA5Lg/+OZnB5Kbo6rthl1xxTLfIwP+A3hAHGJgT5v+W4kbCqXpZzZM0nDL/v7gE XaR/PXxRC25g5TlN7hSnt+qpgAnl03poO6CO/qMW9umrniuOueuDBFsSebk63elH SS8G9Rv4qRfmMQ/3bzB+A3jITP/SLndXK4BK+CGTiZqCUfKHFdiLggmUSH2UZRxG /qmrM5RKeLf0RP32Vn8Oz9Q2RYfTrBACMDffi9K8xfifgTB3WJmStDWVUcl+hjvB zeQQ6Oi6Phvx5+V1JOjEdCr0EmOIUlqiMatCGfG0LObLXyQacQ7YDhoaAxFw2isN DOCc1vO/Cn1t6EOh3RfPAxvPpR/QJnNKHUoE9OuakdrYSjC6YAvQecBU68w3/yoz 1T+o1fXVvmBCgHrH8M40NrB9hhfZi2ou1MnhVH30oO8nxdF9xIUKUwlYo6K7Hv37 Co1LUAeGlIbCxB4Dfy1ySU/+RmBCkWPnaQSiHbCsGLlwGs+nWIrUbrf5SMDB2ylu C/VQ4hnSNl94a0jFFs6F5+n4TIPBO0DFXEqC6L3BJTQ75/YKXfeDc1f0GdJSYGeQ xAvSIMA4AJAjjy9idpD3gkmRTnO938bByqtgPx0v4AD9OzeUkKo8UrnFN46rEi/+ wfNc9rMbs4zas2Kbjb3djKjzHK4YiEl6aG/SqtMEIf0k7qms52w= =hzdI -END PGP SIGNATURE-
Re: RIPE NCC Executive Board election
On 5/13/20 2:42 PM, William Herrin wrote: > It's clear IPv6 is the path forward. It was clear in 2007. But don't > for a second believe that's because IPv4 could not have been upgraded > in place. That's a failure of imagination. IPv6 is the way forward, it has the buy in and damn near critical mass. It dumps most of the extra crap in the headers we don't need anymore and the alignment makes it rather easy to process in hardware. This last part can't be over emphasized; it's not just rewriting software, it's hardware upgrades in most cases. Remember doing v6 on a 7206?* Punt it to the CPU and let it fall over at 1000 pps, right? I may have overstated the performance of that, but at the time we didn't care, 99.9% of all IPv6 was ping and traceroute. When it becomes the preferred delivery network for content, a software based router isn't going to cut it. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net *it's not a dig at cisco or any vendor. It was a thoroughly outdated router 10 years ago, and we can't expect it to have kept up. Merely illustrating a point.
Re: How to manage Static IPs to customers
On 5/8/20 8:57 AM, Javier Gutierrez Guerra wrote: > That's surprising to me, I have no intentions to do routing with our cable > subscribers, that seems like a headache for both sides Meh, there are BNG solutions out there; but RIP's not horrible _in_this_context_ > Today we have specific ranges within subnets from where we assign IPs to > customers, my main problem that I'm trying to get around is having to > change a customer static IP if their node gets splitter and I have to mode > them to a different CMTS I've seen some business services over DOCSIS where you're using VPLS to come back to a central router of your choosing, but it's still Ethernet. There's DHCP and mac addresses and a connection-less medium. PPPoE solves that, but then you're doing PPP. Oh and you have the fun of doing ldp signaled VPLS with a CMTS that was made by people who don't understand it. There's several other BNG solutions out there, and I'm happy to go a bit deeper if you're down the TR-69 path. For the business customer, most are going to balk at anything other than a static IP Ethernet service delivered over Ethernet. Depending on your skill-set and network size you might be able to roll this yourself. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: How to manage Static IPs to customers
On 5/7/20 5:54 PM, Brandon Jackson via NANOG wrote: > I have seen (Charter) and heard quite a few run RIP or some other routing > protocol on the CPE. Yep, it's RIP. They don't support IPv6 on this either. I've been asking for IPv6 since 2006, it's always next year. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: Arista Switches rebooting
On 5/4/20 4:02 PM, Ethan O'Toole wrote: > We found a bug on the 64 port x 100gig model that if you insert a quad > twinax 10gig fanout cable in many of the ports it will trigger a reboot. > > Some select ports are okay and supported, but the ones that are not would > trigger a reset. Issue was immediate to the cable being inserted. No idea > if this was patched or not. Did you contact the vendor and did they commit to a fix? I can't imagine a vendor not wanting to fix an easily reproducible bug such as this. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: mail admins?
On 4/23/20 1:47 PM, William Herrin wrote: > Even if mailman saw it, mailman doesn't use VERP. Both 2.1 and 3.0 of mailman support VERP. I've had it running for some time on mailman 2.1. I'm not sure how it will impact delivery time (a consideration). I've found it to be a non issue in my case. I'd be willing to talk off list if anyone wants details on how to configure and test it. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: mail admins?
On 4/21/20 6:28 PM, Bryan Fields wrote: > On 4/21/20 5:11 PM, William Herrin wrote: >> Howdy,, >> >> How do we contact the nanog mail admins? I looked at >> https://archive.nanog.org/list and https://archive.nanog.org/list/faq >> but apparently someone thought it'd be clever to redact all the email >> addresses from that page. "Questions should be directed to[email >> protected]." > > It's a mailman list, so nanog-ow...@nanog.org should work. If not reach out > to the communications committee. > > Now i did try searching the website for the communications committee, and I > can't tell if it's still a thing. The one time I actually interacted with > them, I just emailed Matt Griswold, but that was years ago. I'm also assuming this is about the 5 bounce messages I got from this last message to the list "Message to 9728466...@email.uscc.net failed." Lets see if it honors "Reply-to:" :) -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: mail admins?
On 4/21/20 5:11 PM, William Herrin wrote: > Howdy,, > > How do we contact the nanog mail admins? I looked at > https://archive.nanog.org/list and https://archive.nanog.org/list/faq > but apparently someone thought it'd be clever to redact all the email > addresses from that page. "Questions should be directed to[email > protected]." It's a mailman list, so nanog-ow...@nanog.org should work. If not reach out to the communications committee. Now i did try searching the website for the communications committee, and I can't tell if it's still a thing. The one time I actually interacted with them, I just emailed Matt Griswold, but that was years ago. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: Language evolution (was 24x7 vs 24x7x365 Re: Constant Abuse Reports / Borderline Spamming from RiskIQ)
On 4/16/20 4:48 PM, Ben Cannon wrote: > Side note: What you describe is in-fact part of how languages change and > evolve. (over time, sufficiently common incorrect use becomes. well. > correct.) Top posting will never be correct, even if the entire world does it. :-) -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: Cogent sales reps who actually respond
On 9/16/19 7:21 PM, Mike Lyon wrote: > 1. Sprint peering battle. Google it > 2. He.net peering battle. Google it. > 3. Google IPv6 peering battle. Google it. > > All of which point to them being pompous assholes. Add in Level3, Telia, ESnet, and I'm sure I'm forgetting others here. Hurricane Electric even baked them a cake, yet they still wont peer. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: rr.level3.net on autopilot?
For following up, their IPadmin team (person) did reach out and resolve this asap for us. Thanks! -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: rr.level3.net on autopilot?
On 9/5/19 2:05 PM, Jon Lewis wrote: > I was doing some IRR clean-up and after a few successful updates, I'm no > longer able to alter or delete our objects in rr.level3.com. > > Emails to r...@level3.com result in no action and no response. I've tried > reaching out to the Level3 (Centurylink) NOC via email and phone, and > can't seem to find anyone who knows what rr.level3.com is, much less knows > who to talk to about troubleshooting. Anyone know who (if anyone) keeps > the wheels spinning on the Level3 IRR? The other day I tried to clean up some old entries from the 2000's and Genuity entries that became part of it. This was a failure, the NOC knew nothing about it, and worse didn't get my black rocket jokes. No one working there knew what Genuity was. I gave up. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: 44/8
iness savvy. >> And with all due respect to Jon (and I mean that sincerely), what did >> it/does it really mean that "Jon gave $PERSON the space for $REASON" 30 >> years later? Jon was a brilliant guy, but from what I've been told would >> also be one of the first to admit when he made a mistake. One of which, >> and one that he actively campaigned to fix, was the idea of classful >> address space to start with, and particularly the idea that it was OK to >> hand out massive chunks of it to anyone who asked. As a former ham I >> definitely appreciate the concept of them having space to play ... errr, >> experiment with. But did they ever, really, need a /8? Historically, what >> percentage of that space has ever actually been used? And as Dave Conrad >> pointed out, given all of the "historical" allocations that have been >> revisited and/or repurposed already, is taking another look at 44/8 >> really that far out of line? >> > Taking another look is not at all out of line. Discarding 25% of it before > letting the community in question on a broader scale take a look is > absolutely very far out of line IMHO. While I never knew Jon personally, I can't think he would have expected the value of IPv4 space either. I can only think his allocation policies would have been much more different. > In actual fact, had the ARDC board approached the broader amateur radio > community with a plan to sell the space, it’s entirely likely that I would > have lent my support to the plan. That does not change the fact that I feel > it was beyond their mandate and out of line for them to take the action > first and neither consult the community before nor after. This has been my position all along. A discussion should have been had. There was no pressing reason it had to be done right now. Based on my personal discussion with Brian Kantor in 2014, he was 100% against selling, or even leasing it as he stated ARDC merely was the custodian of the space for amateur use. I can't think what changed, other than his employment situation. "They drove a dump-truck full of money up to my house, I'm not made of stone!" -- Herschel Krustofsky -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: What can ISPs do better? Removing racism out of internet
On 8/5/19 4:57 PM, b...@theworld.com wrote: > TBH some of this is like watching someone try to set up a router using > only the marketing brochures. Hey, I got my Network+ too. dafuq is a "BGP"? -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: What can ISPs do better? Removing racism out of internet
On 8/5/19 11:15 AM, Mel Beckman wrote: > Keith, what could be more on-topic than an ISP’s status as a common > carrier? Seems pretty operational to me. Mel gets to decide what's on topic and off topic for the nanog list? :D -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: What can ISPs do better? Removing racism out of internet
On 8/4/19 11:41 PM, Mehmet Akcin wrote: > What can we do better as network operators about hate sites like 8Chan? I actually went and looked at 8chan, it would appear to me they have a bunch of hate filled people there, 10 yr olds who think saying the n-word makes them cool, and then other bland users. > I applaud cloudflare’s (perhaps slightly late) decision on kicking 8chan > off its platform today after El Paso attack. > https://blog.cloudflare.com/terminating-service-for-8chan/ I'd be more concerned with the lack of notice given to their customer. This was 24 hours notice, and I'd expect at least 30 days under any hosting contract. This scares the shit out of me as a customer; could cloudflare decide to give me no notice and shut my services off? Once you make the point that you're willing to play that game, how can you be trusted as a provider? > I am sure there are many sites like this out there, but could network > operators do anything to make these sites “not so easy” to be found, > reached, and used to end innocent lives? These atrocities were committed by people willing to die for their cause, how ever sick and fucked up it is. There's little anyone can do against this sort of actor, and it is why it's so terrifying. I certainly don't have a solution to it, but can say censorship is not the answer. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: 44/8 RDNS is still broken!
On 7/22/19 10:09 PM, Owen DeLong wrote: > That would be ARDC, not ADCR, but here’s the problem… As far as most of us > are concerned, it was inappropriate for ARIN to hand them control of the > block in the first place. We were fine with them doing the record keeping > and providing POC services, but we never expected them to be so bold as to > simply steal community resources to enrich an organization we never vetted, > no matter how well intended. Well here is the rub. ARDC is not technically competent to manage the blocks in the first place. One can see how they bungled the RDNS for 44.0.0.0/9 and 44.128.0.0/10 after the sale causing a world wide 22+ hour outage. Several /16 allocations are still down, over 5 days later due to lame delegation. > $ dig +trace -x 44.25.12.1 > ; <<>> DiG 9.8.3-P1 <<>> +trace -x 44.25.12.1 > ;; global options: +cmd > . 360 IN NS J.ROOT-SERVERS.NET. > . 360 IN NS E.ROOT-SERVERS.NET. > . 360 IN NS G.ROOT-SERVERS.NET. > . 360 IN NS F.ROOT-SERVERS.NET. > . 360 IN NS A.ROOT-SERVERS.NET. > . 360 IN NS K.ROOT-SERVERS.NET. > . 360 IN NS B.ROOT-SERVERS.NET. > . 360 IN NS D.ROOT-SERVERS.NET. > . 360 IN NS M.ROOT-SERVERS.NET. > . 360 IN NS L.ROOT-SERVERS.NET. > . 360 IN NS C.ROOT-SERVERS.NET. > . 360 IN NS I.ROOT-SERVERS.NET. > . 360 IN NS H.ROOT-SERVERS.NET. > ;; Received 492 bytes from 192.168.8.200#53(192.168.8.200) in 1454 ms > > in-addr.arpa. 172800 IN NS a.in-addr-servers.arpa. > in-addr.arpa. 172800 IN NS b.in-addr-servers.arpa. > in-addr.arpa. 172800 IN NS c.in-addr-servers.arpa. > in-addr.arpa. 172800 IN NS d.in-addr-servers.arpa. > in-addr.arpa. 172800 IN NS e.in-addr-servers.arpa. > in-addr.arpa. 172800 IN NS f.in-addr-servers.arpa. > ;; Received 417 bytes from 2001:7fd::1#53(2001:7fd::1) in 1837 ms > > 44.in-addr.arpa. 86400 IN NS x.arin.net. > 44.in-addr.arpa. 86400 IN NS z.arin.net. > 44.in-addr.arpa. 86400 IN NS r.arin.net. > ;; Received 112 bytes from 2001:dd8:6::101#53(2001:dd8:6::101) in 839 ms > > 25.44.in-addr.arpa. 86400 IN NS ampr.org. > 25.44.in-addr.arpa. 86400 IN NS a.coreservers.uk. > 25.44.in-addr.arpa. 86400 IN NS munnari.oz.au. > 25.44.in-addr.arpa. 86400 IN NS ampr-dns.in-berlin.de. > 25.44.in-addr.arpa. 86400 IN NS ns2.threshinc.com. > ;; Received 186 bytes from 2001:500:13::63#53(2001:500:13::63) in 5508 ms > > 25.44.in-addr.arpa. 3600IN NS c.ns.hamwan.net. > 25.44.in-addr.arpa. 3600IN NS b.ns.hamwan.net. > 25.44.in-addr.arpa. 3600IN NS a.ns.hamwan.net. > ;; BAD (HORIZONTAL) REFERRAL > ;; Received 102 bytes from 2a00:ed40:4001:1::10#53(2a00:ed40:4001:1::10) in > 579 ms > > 1.12.25.44.in-addr.arpa. 3600 IN PTR > loopback0.r1.triangle.hamwan.net. > ;; Received 87 bytes from 44.24.245.2#53(44.24.245.2) in 99 ms Someone, anyone, want to get this fixed? The road to hell is paved in good intentions. Hey mama, look at me, I'm on my way to the promised land, whoo! -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: 44/8
On 7/21/19 7:32 AM, William Herrin wrote: > Yeah... It just seems like holding an asset in trust for a population and > selling that asset without consulting that population (or at least > consulting the organizations the population commonly understands to > represent them) is very fishy business. This is the major problem, lack of community involvement. It's a world wide resource, but it's use has been hamstrung by the people in charge for years. > Having read their explanation, I think the folks involved had good reasons > and the best intentions but this stinks like fraud to me. Worse, it looks > like ARIN was complicit in the fraud -- encouraging and then supporting the > folks involved as they established a fiefdom of their own rather than > integrating with the organizations that existed. The "appearance of > impropriety" is then magnified by ARIN deeming the matter a private > transaction between it and the alleged registrants to which the pubic is > not entitled to a detailed accounting. You know what they say about good intentions. https://imgflip.com/i/362r0m -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: 44/9, 44.128/10 (was 44/8)
On 7/19/19 2:17 PM, Mikael Abrahamsson wrote: > On Fri, 19 Jul 2019, Phil Karn wrote: > >>> And one of the principal people in the network telescope project was >>> KC, who also weaseled herself onto the ARDC board without even holding >>> an amateur radio license. Conflict of interest here, holy carp. >> >> You are not in possession of all the facts. >> >> KC (Kim Claffy) is KC6KCC. > > https://www.fccbulletin.com/callsign/?q=KC6KCC > > The grant date was 2018-02-21. That is of that callsign, she was KM6PUK before she got KC6KCC, and KM6PUK was granted 01/31/2018, assuming she took the Tech exam with Greater Los Angeles Amateur Radio Group VEC some time before that. > So both of the above statements can be true at the same time since I have > no idea when KC joined the ARDC board. When was that? I was critical of this since at least 2012. John Gilmore was also on the board and was unlicensed at the time. > https://web.archive.org/web/20150505073655/http://www.ampr.org/people.html> https://web.archive.org/web/20160504045206/https://www.ampr.org/about/who-we-are/ This is a moot point as having a valid amateur license is about the lowest bar any board member should have. 90% of this list can take the exam and pass without studying. The bigger question is what have any of the board members done in the time they've been on the board. Certainly not reach out to the users of the resource. There has been no communication from them until now. >From an operational standpoint, RDNS for many subnets is still broken. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: 44.192.0.0/10 sale
On 7/19/19 11:02 AM, Brian Kantor wrote: > Because questions have arisen here that are well answered by > a short series of postings from the 44net mailing list, at the > request of the author [Phil Karn] and others, I am reposting > them here. > - Brian Brian, You've done fuck all for ARDC for years, actively held back deployment of 44net for the better part of 20 years, and now you orchestrate this backroom deal. You and Phil have proven how corrupt you are. Do the honorable thing and resign. Phil too. For shame. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: 44/8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 7/18/19 11:56 PM, Christopher Morrow wrote: > Sure,but... that space has been an internet telescope supporting > numerous research folk for a decade + (probably closer to 2 decades). > the amazon prefix is longer by a bit so won't really use the /8 even > if ucsd keeps the /8 up. And one of the principal people in the network telescope project was KC, who also weaseled herself onto the ARDC board without even holding an amateur radio license. Conflict of interest here, holy carp. Caida has been using an amateur radio resource as far back as 2001, when we couldn't even be blessed to get 44net space for our own legitimate radio use. I'm sure I have the message from Brian denying it in my archives. - -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEaESdNosUjpjcN/JhYTmgYVLGkUAFAl0xRoQACgkQYTmgYVLG kUBDmA//XOUz4PtyFktPm0Yi2jyA56y1QGLdZrgc+dfk8mPImjE3ipaJ+GgUEwEY a10TccbNuC9hWZv1n1F/pD/Kcn+An9uhHOOrIIb9DfST0eUq/qhlK00tbq/1WJtI SKOvJNhdE7815ucl4096e5fEOv7HQg9SxRpstLN/zZffFBL0R3fPtKEWbrgxA6lN Ldj3DnCie7tMG0ZXSTUkHBoumE7NlAcEolQhdu1SrnCbePtbEk/oSy0krT6xIoz5 BoXKarFAh/Ti1LMTUnDt2g1XEKrTtUI40egSzAlBXGvLzkDqW5539ZY+X5HElZzM Kqo84qmupX04xW1QFyA0EtKIwc1RD0PtnN6xhqOQ04llXYp6q82MKlNfgrvC+A2+ W2fq6EOZXAmRobNnfWt6g2k6I9Tc7fRc2xdMZNd8SU8BML/F3wfPPAnifaYqem2Z eoFtVhNr+yaAKUo7OumkfXI40Ab1AfP+r/iGiRg/S3oejhcVMyrZpd6mKAZ6OdiD lbi+lV4K2T0yKntRifqE/R1ASi7RjF379g63IOq1e2CpLbkRljNKx9gi/iU95PP2 C4qxcmX2SRPPDoGiz7Wom9UtWO9NxSFWISVqNL3jdOkCi3388TpRiI4mKLopLgzz wS9FozypHtRFOBZM0D7+1yckxhsf1Q4lZ0WNIVGNlCl6PaU7CnU= =1JCu -END PGP SIGNATURE-
Re: 44/8
On 7/18/19 10:57 PM, Majdi S. Abbas wrote: > > What's interesting about this is it was not an ARIN allocation, > and the ARDC folks are not the original registrant. This IANA /8 was > initially delegated to a community, not an organization. > > So, to the individuals listed in the blog, that I've excerpted > below, what do you have to say about this? > > Brian Kantor > kc claffy > Phil Karn > Paul Vixie This is par for the course with ARDC. I was a TAC committee member (I resigned in disgust just 15 min ago), and the board has failed to inform anyone this was happening. I discussed this prior as we could lease it, do something with it, make some money from it, and was 100% shot down. This has always been Brian Kantor's private little thing ever since he took over administration of it. This take over was before ARDC existed, and ARDC was never structured to be a proper community focused organization. I'd addressed this at TAPR meetings and NANOG with Brian and KC before. This also over looked the huge conflict of interest in KC being a board member of ARDC and Network Telescope getting a feed of 44/8 direct at no cost. This 44/8 announcement and UCSD routing broke connectivity to directly connected BGP subnets for years. My concern as an ARDC supporter an member is now no planning in the community for this, many people assume 44/8 is going to be licensed amateurs (I have many firewalls with permit 44/8 in them), and no accountability of what ARDC is doing. I believe with Brian retiring from UCSD he's looking for a job and being a board member of a well funded 501(c)3 can be a lucrative job. Also it's 100% broken reverse DNS for all of 44/8. :golf clap: This was theft from the community it was meant to serve. -- Bryan Fields, W9CR Former ARDC TAC member 727-409-1194 - Voice http://bryanfields.net
Re: Colo in Africa
On 7/16/19 10:55 AM, Akshay Kumar via NANOG wrote: > The 2nd requirement seems artificial. The new hypervisors have come a long > way and the overhead is minimal. Also you can run bare metal instances in > AWS if you really need them with 100Gbps. Well the man wants bare metal, and while there's arguments for and against it, it's what he wants to buy :) That said, I'm one of those guys that likes owing my own hypervisor, don't need to worry about the side channel/memory/OOO execution attacks from rogue VM's if it's only my VM's on it. Plus AWS ain't cheap either. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
Re: EXERCISE: 2019 IAA Planetary Defence Conference - Day 5 Scenario
On 5/7/19 3:39 PM, Mark Seiden wrote: > excellent! (but i was hoping this would be a swamp-draining-by-vaporization > exercise.) the matador...the matador... the matador! -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
