Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block

2024-01-19 Thread Owen DeLong via NANOG
Any host connected to a reasonably well peered ISP (e.g. NOT Cogent) with IPv6 should be able to communicate with any other such host so long as the administrative policies on both sides permit it. I have no difficulty directly reaching a variety of IPv6 hosts from the /48 in my home.

Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

2024-01-19 Thread Owen DeLong via NANOG
> On Jan 15, 2024, at 09:37, Abraham Y. Chen wrote: > > Hi, Christopher" > > 1)" IPv6 is designed to replace IPv4. ": > Correct. But, this is not like Ten Commandments that God gave to his > children. Even such had not worked out in most cases. In real life, technical > backward

Re: okta probing

2024-01-19 Thread Owen DeLong via NANOG
I think this is a new form of dDOS and it is sometimes performed by Bots. What they are achieving is annoying you. From your post, it appears to be working. It’s also possible (depending on the account name) that it’s a mistype. Owen > On Jan 12, 2024, at 17:50, Randy Bush wrote: > > can

Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

2024-01-19 Thread richey goldberg
That seems to be what NANOG is good at. There is always a topic that seems to drag on for weeks after all valid points of the discussion have been fully discussed. -richey From: NANOG on behalf of Christopher Morrow Date: Thursday, January 18, 2024 at 11:29 PM To: Christopher Hawker Cc:

cloudflare peering portal not loading

2024-01-19 Thread P. Larivee
Hello, trying to load the Cloudflare peering portal, once logged in, it starts loading and then dies with a reactjs error. Tried on multiple browser and OS with the same result. Anyone from cloudflare that could help? Application error: a client-side exception has occurred (see the

Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

2024-01-19 Thread Abraham Y. Chen
Hi, Owen: 0)   Thanks for sorting out my vague memory, citing some consumer electronics evolution history and an excellent overview of the current IPv4/IPv6 landscape. 1)    I believe that consumer electronics including PC related products and services are in a separate category from the

Weekly Global IPv4 Routing Table Report

2024-01-19 Thread Routing Table Analysis Role Account
This is an automated weekly mailing describing the state of the Global IPv4 Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG UKNOF, TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to

IRR information & BYOIP (Bring Your Own IP) with Cloud Providers

2024-01-19 Thread kubanowy
Hi, We have our own prefix assignment from ARIN. We have our infrastructure in GCP (Google Cloud Platform) where we started using BYOIP functionality (Google advertises our IPs). We followed their recommendation with ROA configuration in ARIN   cloud.google.com

Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

2024-01-19 Thread Charles Polisher
Owen DeLong wrote: > Some, but not a lot. In the case of the DTMF transition, the > network and handsets were all under the central control of a > single provider at a time when they could have forced the change > if they really wanted to. After all, nobody was going to cancel > their phone

Re: IRR information & BYOIP (Bring Your Own IP) with Cloud Providers

2024-01-19 Thread Owen DeLong via NANOG
Sounds like you’ve got a weird mix of route origination. Why wouldn’t you advertise to Google via BGP and have your prefix originate from your own ASN? Owen > On Jan 19, 2024, at 02:39, kubanowy wrote: > > Hi, > We have our own prefix assignment from ARIN. We have our infrastructure in >

Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

2024-01-19 Thread Owen DeLong via NANOG
> On Jan 19, 2024, at 09:21, Charles Polisher wrote: > > Owen DeLong wrote: > > > Some, but not a lot. In the case of the DTMF transition, the > > network and handsets were all under the central control of a > > single provider at a time when they could have forced the change > > if they