Re: Peering Contact at AS16509

2024-02-19 Thread Lincoln Dale
Even if you don’t meet the port speed requirements for a PNI, there is likely something that could work via an IX. On Tue, Feb 20, 2024 at 12:57 PM Tim Burke wrote: > We reached out some time ago using the contact on PeeringDB and had no > issue, but the amount of transit consumed to get to

EU Gigabit Infrastructure Act agreement - in-building infrastructure access

2024-02-19 Thread Sean Donelan
While I'm still asking a builder in the USA about pre-wiring new construction house The EU has included in-building infrastructure and fiber ready requirements in its new Gigabit Infrastructure act.

Re: Peering Contact at AS16509

2024-02-19 Thread Peter Potvin via NANOG
Meant to reply to this thread earlier today, but a contact from 16509 reached out directly and got everything squared away for us. On Mon, Feb 19, 2024 at 8:56 PM Tim Burke wrote: > We reached out some time ago using the contact on PeeringDB and had no > issue, but the amount of transit

Re: Verizon Business Contact

2024-02-19 Thread sronan
Based on the ASName of both AS, including CELLCO which is the actual name of the corporate entity known as Verizon Wireless, I would agree that both are in fact Verizon Wireless. The contacts are just corporate standard entities. Shane > On Feb 19, 2024, at 9:01 PM, Richard Laager wrote: > >

Re: Verizon Business Contact

2024-02-19 Thread Richard Laager
I see the route originated by two different ASNs. I agree that when I use the AS6167 path, it is broken (for the destinations where it is broken; 63.59.166.100 was working despite using the AS6167 path). BGP routing table entry for 63.59.0.0/16 Paths: 2 available 6939 701 22394

Re: Peering Contact at AS16509

2024-02-19 Thread Tim Burke
We reached out some time ago using the contact on PeeringDB and had no issue, but the amount of transit consumed to get to 16509 is substantial enough to make responding worth their while. Their minimum peering is 100G, with 400G preferred, so it’s very possible that if you’re not consuming

Re: NANOG 90 Attendance?

2024-02-19 Thread Randy Bush
> We actually had an IETF "Help Desk" at NANOG 63 (San Antonio, 2015) and > NANOG 64 or 65 ― > https://www.internetsociety.org/blog/2015/01/chris-grundemann-nanog-63-talking-bcop-ietf-and-more/ > and > https://www.internetsociety.org/blog/2014/11/operators-and-the-ietf-update-from-ietf-91/ > > We

RE: NANOG 90 Attendance?

2024-02-19 Thread Warren Kumari
On Thu, Feb 15, 2024 at 10:30 AM, Lee Howard wrote: > > > I’m jumping on an earlier part of the thread. > > > > Based on what I heard at the Members Meeting and several follow up hallway > conversations, I think: > > > >- NANOG needs a focus group on attendees. A survey won’t do it, we >

Re: Verizon Business Contact

2024-02-19 Thread sronan
No, Verizon Wireless has their own AS # and doesn’t actually use Verizon Business as their primary provider.ShaneOn Feb 19, 2024, at 2:58 PM, Mike Hammett wrote:But then MCI is the one running fiber to all of the Verizon Wireless sites, so that doesn't help in de-muddying the waters.-Mike

Re: Verizon Business Contact

2024-02-19 Thread Mike Hammett
But then MCI is the one running fiber to all of the Verizon Wireless sites, so that doesn't help in de-muddying the waters. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From:

Re: Verizon Business Contact

2024-02-19 Thread sronan
Verizon Business is the fixed line business focused entity, formerly MCI and UUNET. Verizon Wireless is the wireless business entity.ShaneOn Feb 19, 2024, at 2:44 PM, Justin Krejci wrote: For me it is some AS 6167 destinations. WHOIS for that ASN says this is Verizon Business. AS Number:

Re: Verizon Business Contact

2024-02-19 Thread Justin Krejci
For me it is some AS 6167 destinations. WHOIS for that ASN says this is Verizon Business. AS Number: 6167 Org Name: Verizon Business I am not sure how I am supposed to accurately or authoritatively discern the differences in specific IP prefixes (or ASNs) as to whether they are

Re: [External] Re: IPv6 uptake

2024-02-19 Thread William Herrin
On Mon, Feb 19, 2024 at 10:31 AM Tim Howe wrote: > On Mon, 19 Feb 2024 10:01:06 -0800 > William Herrin wrote: > > So when the user wants to run a home server, their IPv4 options are to > > create a TCP or UDP port forward for a single service port or perhaps > > create a generic port forward for

Re: [External] Re: IPv6 uptake

2024-02-19 Thread Tim Howe
Some responses below. On Mon, 19 Feb 2024 10:01:06 -0800 William Herrin wrote: > > I've never once seen a device > > that has v6 support and didn't have a stateful v6 firewall on by > > default (if v6 was "on"). > > Acknowledged. > > So when the user wants to run a home server, their IPv4

Re: [External] Re: IPv6 uptake

2024-02-19 Thread William Herrin
On Mon, Feb 19, 2024 at 9:44 AM Tim Howe wrote: > FWIW, in the decade we have been providing dual-stack by default, I > have made a bit of a hobby out of testing every CPE and SOHO router > that I get may hands on in my PON lab. Hi Tim, I have not, so I'll defer to your experience. > I've

Re: [External] Re: IPv6 uptake

2024-02-19 Thread Dave Taht
OpenWrt, from which much is derived, is default deny on ipv4 and ipv6. The ipv6 firewall on most cable devices prior to the XB6 is very, very limited. On Mon, Feb 19, 2024 at 12:44 PM William Herrin wrote: > > On Mon, Feb 19, 2024 at 9:23 AM Hunter Fuller wrote: > > On Mon, Feb 19, 2024 at

Re: [External] Re: IPv6 uptake

2024-02-19 Thread Tim Howe
On Mon, 19 Feb 2024 09:16:00 -0800 William Herrin wrote: > I disagree with that one. Limiting discussion to the original security > context (rather than the wider world of how useful IPv6 is without > IPv4), IPv6 is typically delivered to "most people" without border > security, while IPv4 is

Re: [External] Re: IPv6 uptake

2024-02-19 Thread William Herrin
On Mon, Feb 19, 2024 at 9:23 AM Hunter Fuller wrote: > On Mon, Feb 19, 2024 at 11:16 AM William Herrin wrote: > > > There isn't really an advantage to using v4 NAT. > > I disagree with that one. Limiting discussion to the original security > > context (rather than the wider world of how useful

Re: AWS WAF list

2024-02-19 Thread Justin H.
That matches my experience with these types of problems in the past.  Especially when the end-users don't have a process for white-listing.  We actually got a response from one WAF user to "connect to another network to log in, then you should be able to use the site, because it's just the

Re: [External] Re: IPv6 uptake

2024-02-19 Thread Hunter Fuller via NANOG
On Mon, Feb 19, 2024 at 11:16 AM William Herrin wrote: > > There isn't really an advantage to using v4 NAT. > I disagree with that one. Limiting discussion to the original security > context (rather than the wider world of how useful IPv6 is without > IPv4), IPv6 is typically delivered to "most

Re: [External] Re: IPv6 uptake

2024-02-19 Thread William Herrin
On Mon, Feb 19, 2024 at 9:00 AM Hunter Fuller wrote: > I guess the point I'm making is, the methods we are using today for v6 > dual WAN, work fine for most people. Hi Hunter, I accept that point. It's wobbly on some of the details, but you're talking "most" people, not everyone. > There

Re: [External] Re: IPv6 uptake

2024-02-19 Thread Hunter Fuller via NANOG
On Mon, Feb 19, 2024 at 10:22 AM William Herrin wrote: > Yes and no. The client application has to be programmed to understand > link-local addresses or it can't use them at all. You can't just say > "connect to fe80::1." Even if there's an fe80::1 on your network, it > doesn't work. The client

Re: [External] Re: IPv6 uptake

2024-02-19 Thread William Herrin
On Mon, Feb 19, 2024 at 8:08 AM Hunter Fuller wrote: > On Mon, Feb 19, 2024 at 9:17 AM William Herrin wrote: > > There's also the double-ISP loss scenario that causes Joe to lose all > > global-scope IP addresses. He can overcome that by deploying ULA > > addresses (a third set of IPv6

Re: [External] Re: IPv6 uptake

2024-02-19 Thread Dave Taht
On Mon, Feb 19, 2024 at 11:13 AM Hunter Fuller via NANOG wrote: > > On Mon, Feb 19, 2024 at 9:29 AM Mike Hammett wrote: > > "In IPv6's default operation, if Joe has two connections then each of > > his computers has two IPv6 addresses and two default routes. If one > > connection goes down, one

Re: [External] Re: IPv6 uptake

2024-02-19 Thread Dave Taht
mdns can still be "fun" in a wide variety of situations. https://www.reddit.com/r/k12sysadmin/comments/9yghdx/chromebooks_and_peer_to_peer_updates_can_be/ I do not know to what extent the upgrade to unicast feature long gestating in the IETF has been adopted. On Mon, Feb 19, 2024 at 11:10 AM

Re: [External] Re: IPv6 uptake

2024-02-19 Thread Hunter Fuller via NANOG
On Mon, Feb 19, 2024 at 9:29 AM Mike Hammett wrote: > "In IPv6's default operation, if Joe has two connections then each of > his computers has two IPv6 addresses and two default routes. If one > connection goes down, one of the routes and sets of IP addresses goes > away." > > This sounds like a

Re: [External] Re: IPv6 uptake

2024-02-19 Thread Hunter Fuller via NANOG
On Mon, Feb 19, 2024 at 9:17 AM William Herrin wrote: > There's also the double-ISP loss scenario that causes Joe to lose all > global-scope IP addresses. He can overcome that by deploying ULA > addresses (a third set of IPv6 addresses) on the internal hosts, but > convincing the internal network

Re: IPv6 uptake

2024-02-19 Thread Tom Beecher
> > I'm not going to participate in the security conversation, but we do > absolutely need something to fill the role of NAT in v6. If it's already > there or not, I don't know. Use case: Joe's Taco Shop. Joe doesn't want a > down Internet connection to prevent transactions from completing, so he

Re: IPv6 uptake (was: The Reg does 240/4)

2024-02-19 Thread William Herrin
On Mon, Feb 19, 2024 at 6:02 AM Howard, Lee wrote: > Most NATs I've seen in the last 10-15 years are "full cone" NATs: they are > configured so that once there is an > outbound flow, and inbound datagram to that address+port will be forwarded to > the inside address, regardless > of source. Hi

Re: IPv6 uptake

2024-02-19 Thread Mike Hammett
" In IPv6's default operation, if Joe has two connections then each of his computers has two IPv6 addresses and two default routes. If one connection goes down, one of the routes and sets of IP addresses goes away." This sounds like a disaster. - Mike Hammett Intelligent Computing

Re: IPv6 uptake

2024-02-19 Thread William Herrin
On Mon, Feb 19, 2024 at 6:52 AM Mike Hammett wrote: > "We can seriously lose NAT for v6 and not lose > anything of worth." > > I'm not going to participate in the security conversation, but we > do absolutely need something to fill the role of NAT in v6. If it's > already there or not, I don't

Re: IPv6 uptake

2024-02-19 Thread Mike Hammett
" We can seriously lose NAT for v6 and not lose anything of worth." I'm not going to participate in the security conversation, but we do absolutely need something to fill the role of NAT in v6. If it's already there or not, I don't know. Use case: Joe's Taco Shop. Joe doesn't want a down

Roku Network Contact

2024-02-19 Thread Jason Canady
Does anyone here have a network contact for Roku?  Need some assistance.  Thank you! Best Regards, Jason

Re: IPv6 uptake (was: The Reg does 240/4)

2024-02-19 Thread William Herrin
On Mon, Feb 19, 2024 at 5:29 AM Howard, Lee via NANOG wrote: > In the U.S., the largest operators without IPv6 are (in order by size): > Lumen (CenturyLink) CenturyLink has IPv6 using 6rd. It works fine. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/

RE: IPv6 uptake (was: The Reg does 240/4)

2024-02-19 Thread Howard, Lee via NANOG
Bottom-posted with old school formatting by hand. -Original Message- From: NANOG On Behalf Of William Herrin Sent: Friday, February 16, 2024 8:05 PM To: Michael Thomas Cc: nanog@nanog.org Subject: Re: IPv6 uptake (was: The Reg does 240/4) > On the firewall, I program it to do NAT

RE: IPv6 uptake (was: The Reg does 240/4)

2024-02-19 Thread Howard, Lee via NANOG
If you ever want to know which providers in a country are lagging, Geoff Huston is here to help: https://stats.labs.apnic.net/ipv6/US In the U.S., the largest operators without IPv6 are (in order by size): Verizon FiOS (they deployed to 50%, discovered a bug, and rolled back) Frontier Lumen