Re: Peering Contact at AS16509

[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 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 anywhere close to 100G, the lack of response
> could correlate to a lack of interest on their side.
>
> > On Feb 18, 2024, at 13:09, Peter Potvin via NANOG 
> wrote:
> >
> > 
> > If a contact who manages North American peering at AS16509 could reach
> out off-list, that would be appreciated. Myself and a few colleagues have
> attempted to reach out via the contacts listed on PeeringDB on multiple
> occasions over the last couple of months and have not been successful in
> reaching someone.
> >
> > Kind regards,
> > Peter Potvin
>

EU Gigabit Infrastructure Act agreement - in-building infrastructure access

[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.


https://www.consilium.europa.eu/en/press/press-releases/2024/02/06/gigabit-infrastructure-act-council-and-parliament-strike-a-deal-for-faster-deployment-of-high-speed-networks-in-the-eu/

e) In-building physical infrastructure and fibre wiring, the “fibre-ready” 
label and certification schemes


18. To ensure a swift deployment of VHCN, 
allowing citizens to enjoy fast connectivity services, new and majorly 
renovated buildings shall be pre-equipped with fibre and fibreready 
infrastructure. In order to implement this provision, standards have to be 
developed and adopted under Article 8(4). Member States shall ensure 
compliance with this provision and must have procedures in place, to 
verify whether the buildings are equipped according to these standards.



19. Applying the ‘fibre-ready’ label in Article 8(5) and (6) has become 
optional for the Member States. The certification is not any more a 
pre-requisite to issuing a building permit.

Re: Peering Contact at AS16509

[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 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 anywhere close to 100G, the lack of response
> could correlate to a lack of interest on their side.
>
> > On Feb 18, 2024, at 13:09, Peter Potvin via NANOG 
> wrote:
> >
> > 
> > If a contact who manages North American peering at AS16509 could reach
> out off-list, that would be appreciated. Myself and a few colleagues have
> attempted to reach out via the contacts listed on PeeringDB on multiple
> occasions over the last couple of months and have not been successful in
> reaching someone.
> >
> > Kind regards,
> > Peter Potvin
>

Re: Verizon Business Contact

[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:
> 
> 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
>184.105.34.254 from 184.105.34.254 (216.218.253.228)
>  Origin IGP, metric 0, localpref 60, IGP metric 0, weight 0, tag 0
>  Received 21d19h ago, valid, external, best
>  Rx SAFI: Unicast
>  6461 701 6167
>69.89.205.202 from 69.89.205.202 (69.89.205.202)
>  Origin IGP, metric 887, localpref 60, IGP metric 40, weight 0, tag 0
>  Received 4d03h ago, valid, internal
>  Community: 6461:5997
>  Rx SAFI: Unicast
> 
> Based on the names in WHOIS, I would say that both AS6167 and AS22394 are 
> Verizon Wireless.
> 
> --
> Richard
> 

Re: Verizon Business Contact

[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
184.105.34.254 from 184.105.34.254 (216.218.253.228)
  Origin IGP, metric 0, localpref 60, IGP metric 0, weight 0, tag 0
  Received 21d19h ago, valid, external, best
  Rx SAFI: Unicast
  6461 701 6167
69.89.205.202 from 69.89.205.202 (69.89.205.202)
  Origin IGP, metric 887, localpref 60, IGP metric 40, weight 0, tag 0
  Received 4d03h ago, valid, internal
  Community: 6461:5997
  Rx SAFI: Unicast

Based on the names in WHOIS, I would say that both AS6167 and AS22394 
are Verizon Wireless.


--
Richard

Re: Peering Contact at AS16509

[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 anywhere close to 100G, the lack of response could 
correlate to a lack of interest on their side. 

> On Feb 18, 2024, at 13:09, Peter Potvin via NANOG  wrote:
> 
> 
> If a contact who manages North American peering at AS16509 could reach out 
> off-list, that would be appreciated. Myself and a few colleagues have 
> attempted to reach out via the contacts listed on PeeringDB on multiple 
> occasions over the last couple of months and have not been successful in 
> reaching someone.
> 
> Kind regards,
> Peter Potvin

Re: NANOG 90 Attendance?

[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 hoped to answer questions such as:
> “Why should I participate in the IETF?”
> “How do I get involved in the IETF?”
> “What is the difference between an Internet-Draft and an RFC?”
> “How do I submit an idea to the IETF?”
> “What is the IETF working on in  space?”
> “How do I comment on an existing IETF document?”
> 

perhaps the internet would benefit more from the inverse, a help desk at
the ietf for "what is internet operation and how does it actually work?"

randy

RE: NANOG 90 Attendance?

[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
>need a deep dive into roles, interests, career level, and why they attend.
>- Somebody or somebodies should be specifically tasked with following
>up with every one of the 120 newcomer attendees to ask what it would take
>to get them to come back. Our conversion rate to repeat attendee is a key
>performance indicator. There’s a great Newcomer Orientation just before
>conference opening; let’s have a Newcomer Lessons Learned at the end.
>- Poll attendees on relative importance of location, registration fee,
>programming, side meeting space. Iterate based on comments (location =
>airport? Hotel? Nearby amenities? Proximity to home?)
>- Survey sponsors. I give feedback to staff and occasional board
>members, but there’s no clear way to gather information.
>- These should be sent to the Members in advance of a Members Meeting
>to discuss. Needs more than 20 minutes of a 45 minute meeting before main
>programming.
>- Consider empaneling a Mission Committee to review NANOG’s mission
>and how to fulfill it.
>
>
>
>
> Other thoughts, which I couldn’t submit in a survey or find another way to
> send to the board or staff:
>
>
>
>- I suggested in San Diego and now bring to the list: the last item on
>the agenda should be 15-30 minutes of “What are you taking home from this
>NANOG?”
>
>   - Helps remind people what value they got
>   - Lets us know what people found most valuable (Specific sessions?
>   deals done? Trends in hallway topics?)
>   - Solidifies for people what they can offer their boss as the value
>   of sending them to NANOG
>
>- We should look into cooperating with other network organizations for
>meetings. WISPAmerica, NRECA, NTCA, Fiber Connect, SCTE, IETF
>- ARIN has a help desk in the main hall. Allow other sponsors to put
>up a Help Desk. Put up a sign showing which company will be there for which
>half-day increment. I think a lot of attendees would find value in the
>ability to sit down with a senior sales engineer at their favorite router,
>optical, or intelligence vendor to say, “Here’s my problem,” even if many
>of those conversations resulted in “Let’s schedule time to discuss in more
>depth.”
>
>   - Price it like BnG—you’re getting ½ day of visibility, less
>   distraction than meal/break sponsors
>   - Require swag to be incidentals like pens and stickers—if you’re
>   getting a mad rush of people, you’re missing the point
>
>
>
>
>
>
>

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 hoped to answer questions such as:
“Why should I participate in the IETF?”
“How do I get involved in the IETF?”
“What is the difference between an Internet-Draft and an RFC?”
“How do I submit an idea to the IETF?”
“What is the IETF working on in  space?”
“How do I comment on an existing IETF document?”



This was (IMO) quite successful, and I personally thought that it benefited
both the IETF and NANOG.
We had hoped to continue this series, but NANOG moved to wanting to charge
the IETF for a sponsor table[0], and, lacking funds, we stopped.

W


> This can’t all be done in time for Kansas City, but maybe some of it can
> be. Given that hotel contracts are negotiated two years in advance, I
> figure we have about two years to get this right before it’s too late to
> steer the ship away from the rocks.
>
>
>
> Let me close with: I think we have an excellent board, all of whom love
> this community and have spent years thinking about this. The lack of a CEO
> is a problem soon to be resolved, and that will help support the already
> excellent staff. There are themes we’ve been hearing for several meetings
> in a row, and I know the board is giving them a lot of thought, and I’m
> just trying to support those efforts from outside the board.
>
>
>
> Maybe this should have gone to the members mailing list, but I couldn’t
> find one.
>
>
>
> Lee
>
>
>
>
>
>
>
> *From:* NANOG  *On
> Behalf Of *Warren Kumari
> *Sent:* Sunday, February 11, 2024 2:50 PM
> *To:* Mike Hammett 
> *Cc:* nanog 
> *Subject:* Re: NANOG 90 Attendance?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> You don't often get email from war...@kumari.net. Learn why this is
> important 
>
>
>
>
>
>
> *This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with
> links and attachments.*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Re: Verizon Business Contact

[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 HammettIntelligent Computing Solutionshttp://www.ics-il.comMidwest-IXhttp://www.midwest-ix.comFrom: sro...@ronan-online.comTo: "Justin Krejci" Cc: nanog@nanog.orgSent: Monday, February 19, 2024 1:54:43 PMSubject: Re: Verizon Business ContactVerizon 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:  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 are used in the Verizon Wireless, Verizon Business, Verizon XYZ, etc.
I am also not sure what the value would be understanding the difference as I have zero contacts at any Verizon entity: Wireless, Business, or any other.


I imagine at some level, there is a parent Verizon umbrella organization that is ultimately responsible for all underling organizations/divisions but I am not particularly interested in trying to pick apart the business silos of Verizon and then from there
 trying to chase down specific Verizon entity contacts to try and figure out who, might be the right contact to look into this. I have made efforts, prior to this NANOG thread even starting, to get this issue rectified but I have had zero luck so far getting
 any appropriate person at Verizon to take notice.


It kind of feels like trying to reach out to some company regarding a geolocation or IP-reputation type issue... just a lot of "Sorry, I don't know. try this other group that you already talked to" or simply "piss off" type responses. Both of which I have
 received in sizable quantities. Now that my brain is on that tangent, my favorite geolocation response was when I was told "your ISP needs to set the correct bits in the IP packets to designate the traffic as coming from the correct geography." I laughed and
 I cried at that one.






-Original Message-
From: Richard Laager 
To: Justin Krejci 
Cc: nanog@nanog.org 
Subject: Re: Verizon Business Contact
Date: Fri, 16 Feb 2024 20:41:04 -0600



On 2024-02-09 18:10, Justin Krejci wrote:



For a good long while (months) we have had similar issues with various Verizon destinations.

Only Verizon Wireless destinations, or other Verizon Business things?

As of today, I'm told (via an upstream provider) that Verizon Business says this is a Verizon Wireless issue.

Re: Verizon Business Contact

[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: sro...@ronan-online.com 
To: "Justin Krejci"  
Cc: nanog@nanog.org 
Sent: Monday, February 19, 2024 1:54:43 PM 
Subject: Re: Verizon Business Contact 



Verizon Business is the fixed line business focused entity, formerly MCI and 
UUNET. Verizon Wireless is the wireless business entity. 


Shane 



On 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:  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 are used 
in the Verizon Wireless, Verizon Business, Verizon XYZ, etc. 
I am also not sure what the value would be understanding the difference as I 
have zero contacts at any Verizon entity: Wireless, Business, or any other. 


I imagine at some level, there is a parent Verizon umbrella organization that 
is ultimately responsible for all underling organizations/divisions but I am 
not particularly interested in trying to pick apart the business silos of 
Verizon and then from there trying to chase down specific Verizon entity 
contacts to try and figure out who, might be the right contact to look into 
this. I have made efforts, prior to this NANOG thread even starting, to get 
this issue rectified but I have had zero luck so far getting any appropriate 
person at Verizon to take notice. 


It kind of feels like trying to reach out to some company regarding a 
geolocation or IP-reputation type issue... just a lot of "Sorry, I don't know. 
try this other group that you already talked to" or simply "piss off" type 
responses. Both of which I have received in sizable quantities. Now that my 
brain is on that tangent, my favorite geolocation response was when I was told 
"your ISP needs to set the correct bits in the IP packets to designate the 
traffic as coming from the correct geography." I laughed and I cried at that 
one. 






-Original Message- 
>From : Richard Laager < rlaa...@wiktel.com > 
To : Justin Krejci < jkre...@usinternet.com > 
Cc : nanog@nanog.org < nanog@nanog.org > 
Subject : Re: Verizon Business Contact 
Date : Fri, 16 Feb 2024 20:41:04 -0600 


On 2024-02-09 18:10, Justin Krejci wrote: 




For a good long while (months) we have had similar issues with various Verizon 
destinations. 


Only Verizon Wireless destinations, or other Verizon Business things? 

As of today, I'm told (via an upstream provider) that Verizon Business says 
this is a Verizon Wireless issue. 

Re: Verizon Business Contact

[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:  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 are used in the Verizon Wireless, Verizon Business, Verizon XYZ, etc.
I am also not sure what the value would be understanding the difference as I have zero contacts at any Verizon entity: Wireless, Business, or any other.


I imagine at some level, there is a parent Verizon umbrella organization that is ultimately responsible for all underling organizations/divisions but I am not particularly interested in trying to pick apart the business silos of Verizon and then from there
 trying to chase down specific Verizon entity contacts to try and figure out who, might be the right contact to look into this. I have made efforts, prior to this NANOG thread even starting, to get this issue rectified but I have had zero luck so far getting
 any appropriate person at Verizon to take notice.


It kind of feels like trying to reach out to some company regarding a geolocation or IP-reputation type issue... just a lot of "Sorry, I don't know. try this other group that you already talked to" or simply "piss off" type responses. Both of which I have
 received in sizable quantities. Now that my brain is on that tangent, my favorite geolocation response was when I was told "your ISP needs to set the correct bits in the IP packets to designate the traffic as coming from the correct geography." I laughed and
 I cried at that one.






-Original Message-
From: Richard Laager 
To: Justin Krejci 
Cc: nanog@nanog.org 
Subject: Re: Verizon Business Contact
Date: Fri, 16 Feb 2024 20:41:04 -0600



On 2024-02-09 18:10, Justin Krejci wrote:



For a good long while (months) we have had similar issues with various Verizon destinations.

Only Verizon Wireless destinations, or other Verizon Business things?

As of today, I'm told (via an upstream provider) that Verizon Business says this is a Verizon Wireless issue.

Re: Verizon Business Contact

[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 are used 
in the Verizon Wireless, Verizon Business, Verizon XYZ, etc.
I am also not sure what the value would be understanding the difference as I 
have zero contacts at any Verizon entity: Wireless, Business, or any other.

I imagine at some level, there is a parent Verizon umbrella organization that 
is ultimately responsible for all underling organizations/divisions but I am 
not particularly interested in trying to pick apart the business silos of 
Verizon and then from there trying to chase down specific Verizon entity 
contacts to try and figure out who, might be the right contact to look into 
this. I have made efforts, prior to this NANOG thread even starting, to get 
this issue rectified but I have had zero luck so far getting any appropriate 
person at Verizon to take notice.

It kind of feels like trying to reach out to some company regarding a 
geolocation or IP-reputation type issue... just a lot of "Sorry, I don't know. 
try this other group that you already talked to" or simply "piss off" type 
responses. Both of which I have received in sizable quantities. Now that my 
brain is on that tangent, my favorite geolocation response was when I was told 
"your ISP needs to set the correct bits in the IP packets to designate the 
traffic as coming from the correct geography." I laughed and I cried at that 
one.



-Original Message-
From: Richard Laager 
mailto:richard%20laager%20%3crlaa...@wiktel.com%3e>>
To: Justin Krejci 
mailto:justin%20krejci%20%3cjkre...@usinternet.com%3e>>
Cc: nanog@nanog.org 
mailto:%22na...@nanog.org%22%20%3cna...@nanog.org%3e>>
Subject: Re: Verizon Business Contact
Date: Fri, 16 Feb 2024 20:41:04 -0600

On 2024-02-09 18:10, Justin Krejci wrote:

For a good long while (months) we have had similar issues with various Verizon 
destinations.

Only Verizon Wireless destinations, or other Verizon Business things?

As of today, I'm told (via an upstream provider) that Verizon Business says 
this is a Verizon Wireless issue.

Re: [External] Re: IPv6 uptake

[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 every port to a single internal
> > machine. Protocols other than TCP and UDP not supported.
>
> OK, but I'm not sure what you are getting at by saying this is
> TCP and UDP exclusive... I don't know why it would be; what's the
> example you think is typically being denied?

Hi Tim,

NATs don't generally process protocols like GRE, ESP (IPSEC), SCTP and
most of the hundred fifty or so other protocols that sit atop IPv4.
They don't have code that would make it possible to process those
packets. They're generally TCP, UDP, and ICMP. Anything else is
necessarily dropped.


> The assumption being that a guardrail for someone being really
> self-destructive is removed.

In more sophisticated scenarios where subtler errors are possible, I
described it as a "security layer" rather than a "guardrail." But yes:
we're talking about the same thing.


> I still believe that the statement "IPv6 is typically delivered
> to "most people" without border security" to be demonstrably false.

I concede the claim. I am satisfied with your evidence that I was in error.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: [External] Re: IPv6 uptake

[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 options are to
> create a TCP or UDP port forward for a single service port or perhaps
> create a generic port forward for every port to a single internal
> machine. Protocols other than TCP and UDP not supported.

OK, but I'm not sure what you are getting at by saying this is
TCP and UDP exclusive... I don't know why it would be; what's the
example you think is typically being denied?

> They might
> also have the option of a "bridge" mode in which only one internal
> host is usable and the IPv4 functions of the device are disabled. The
> bridge mode is the only "off" setting for the IPv4 firewall.
> 
> Correct?
> 
> Their IPv6 options *might* include these but also include the option
> to turn the IPv6 firewall off. At which point IPv4 is still firewalled
> but IPv6 is not and allows all L4 protocols, not just TCP and UDP.
> 
> Also correct?

This isn't how I would characterize any of this, to be honest.
I think what you are trying to say is that a v6 firewall can be "off"
while IPv6 connectivity remains unhindered, but turning "off" an IPv4
firewall means no hosts behind NAT will continue to have connectivity.
The assumption being that a guardrail for someone being really
self-destructive is removed.

OK.  So someone really wanted connectivity and really wanted to
disable security.  Maybe.
I still believe that the statement "IPv6 is typically delivered
to "most people" without border security" to be demonstrably false.

-- 
TimH

Re: [External] Re: IPv6 uptake

[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 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 options are to
create a TCP or UDP port forward for a single service port or perhaps
create a generic port forward for every port to a single internal
machine. Protocols other than TCP and UDP not supported. They might
also have the option of a "bridge" mode in which only one internal
host is usable and the IPv4 functions of the device are disabled. The
bridge mode is the only "off" setting for the IPv4 firewall.

Correct?

Their IPv6 options *might* include these but also include the option
to turn the IPv6 firewall off. At which point IPv4 is still firewalled
but IPv6 is not and allows all L4 protocols, not just TCP and UDP.

Also correct?

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: [External] Re: IPv6 uptake

[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 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 people" without border
> > > security, while IPv4 is delivered with a stateful NAT firewall.
> >
> > Maybe this is the disconnect. Who delivers v6 without a firewall?
> >
> > I've done a lot of T-Mobile and Comcast business connections lately,
> > and those certainly both provide a firewall on v4 and v6. I'll admit
> > I'm not currently well-versed in other providers (except ones that
> > don't provide v6 at all...).
>
> Hi Hunter,
>
> You may be right. I haven't ordered SOHO service in a long time and in
> fairness you were talking about Joe's Taco Shop not Joe's home
> network.
>
> I -suspect- that the wifi router provided for Joe's home network
> doesn't do much more than plain routing on the IPv6 side but I do not
> know that for a truth. I ordered my wave and comcast services without
> a router and I didn't keep the centurylink router long enough to test
> whether it did any filtering on IPv6. I noticed no knobs for IPv6
> filtering or port forwarding, so I suspect it did not.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/



-- 
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos

Re: [External] Re: IPv6 uptake

[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 delivered with a stateful NAT firewall.

How is v6 being delivered without a stateful firewall while v4
is secured with one?

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.  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").  

By whom and how is this being delivered?

--TimH

Re: [External] Re: IPv6 uptake

[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 IPv6 is without
> > IPv4), IPv6 is typically delivered to "most people" without border
> > security, while IPv4 is delivered with a stateful NAT firewall.
>
> Maybe this is the disconnect. Who delivers v6 without a firewall?
>
> I've done a lot of T-Mobile and Comcast business connections lately,
> and those certainly both provide a firewall on v4 and v6. I'll admit
> I'm not currently well-versed in other providers (except ones that
> don't provide v6 at all...).

Hi Hunter,

You may be right. I haven't ordered SOHO service in a long time and in
fairness you were talking about Joe's Taco Shop not Joe's home
network.

I -suspect- that the wifi router provided for Joe's home network
doesn't do much more than plain routing on the IPv6 side but I do not
know that for a truth. I ordered my wave and comcast services without
a router and I didn't keep the centurylink router long enough to test
whether it did any filtering on IPv6. I noticed no knobs for IPv6
filtering or port forwarding, so I suspect it did not.

Regards,
Bill Herrin


--
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: AWS WAF list

[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 login page that's protected".


I am working with someone off-list, so I have hope this can be resolved 
without account gymnastics. :)


Justin H.

Owen DeLong wrote:

The whole situation with these WAF as a service setups is a nightmare for the 
affected (afflicted) parties.

I saw this problem from both sides when I was at Akamai. It’s not great from 
the service provider side, but it’s an absolute shit show for anyone on the 
wrong side of a block. There’s no accountability or process for redress of 
errors whatsoever. The impacted party isn’t a customer of the WAF publisher, so 
they cant get any traction there. The WAF subscriber blindly applies the WAF 
and it’s virtually impossible to track down anyone there who even knows that 
they subscribe to such a thing, let alone get them to take useful action.

Best of luck.  The only thing I saw that worked while I was at Akamai was a few 
entities subscribed to the WAF service and then complained about getting 
blocked from their own web sites. Since they were then Akamai WAF customers, 
they could get Akamai to take action.

Crazy.

Owen



On Feb 16, 2024, at 09:19, Justin H.  wrote:

Justin H. wrote:

Hello,

We found out recently that we are on the HostingProviderIPList (found here 
https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-ip-rep.html)
 at AWS and it's affecting our customers' access to various websites.  We are a 
datacenter, and a hosting provider, but we have plenty of enterprise customers 
with eyeballs.

We're finding it difficult to find a technical contact that we can reach since 
we're not an AWS customer.  Does anyone have a contact or advice on a solution?

Sadly we're not getting any traction from standard AWS support, and end users 
of the WAF list like Reddit and Eventbrite are refusing to whitelist anyone.  
Does anyone have any AWS contacts that might be able to assist?  Our enterprise 
customers are becoming more and more impacted.

Justin H.

Re: [External] Re: IPv6 uptake

[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 people" without border
> security, while IPv4 is delivered with a stateful NAT firewall.

Maybe this is the disconnect. Who delivers v6 without a firewall?

I've done a lot of T-Mobile and Comcast business connections lately,
and those certainly both provide a firewall on v4 and v6. I'll admit
I'm not currently well-versed in other providers (except ones that
don't provide v6 at all...).

It is possible to order Comcast without a firewall for v6, in which
case you receive a public v4 address without protection too.

What common scenario leads to your average person being unprotected on
the v6 Internet?

Re: [External] Re: IPv6 uptake

[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 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 people" without border
security, while IPv4 is delivered with a stateful NAT firewall. If
ISPs got diligent about providing an IPv6 firewall to customers even
though they don't need to do so for the customer to use more than one
computer, there'd still be a security difference between internal
hosts that are externally addressable (a stateful firewall without
NAT) and internal hosts which are not. Security doesn't deal with
"most people," it deals with people savvy enough to find and exploit
the openings and errors in the software most people use.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: [External] Re: IPv6 uptake

[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 app has to also carry the interface identity
> into the stack (e.g. fe80::1%eth0) in order to use it.

Sure, you and I know this, as a network engineering fact. But, all
over the US, thousands of taco trucks (Joe's or otherwise) are using
Square and similar solutions, and I happen to know from pcaps that
they are (at least some of the time) using the method I described. So
everything else we discuss is kind of academic; Joe will continue
printing receipts for taco orders over link local addresses just fine,
since it works in production today.

We can talk all day about how it's not optimal, has limitations if you
have 4000 Chromebooks, etc., but Joe won't care, because he is selling
tacos. Businesses (not enterprises) that need dual WAN will fall into
this category 99.9% of the time.

I guess the point I'm making is, the methods we are using today for v6
dual WAN, work fine for most people. There isn't really an advantage
to using v4 NAT. That was the original topic I was responding to... as
it is visible fuzzily in the rearview mirror currently.

Re: [External] Re: IPv6 uptake

[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 addresses) on the internal hosts, but
> > convincing the internal network protocols to stay on the ULA addresses
> > is wonky too.
>
> In the real world today, most applications seem to use mDNS and
> link-local addresses to keep this connectivity working. (I am guessing
> Joe's Taco Shop uses something like Square, and just needs his
> register to talk to his printer. This already works with mDNS and
> link-locals today.)

Hi Hunter,

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 app has to also carry the interface identity
into the stack (e.g. fe80::1%eth0) in order to use it.

IPv6 link local addresses can't be expressed as a regular DNS target
the way ULA and RFC1918 addresses can. No way to add that "%eth0" to
the  record. They only work with multicast DNS because the
matching interface is known based on which interface was used to send
the multicast query.

And of course link local is -strictly- link local. If you want one
subnet to communicate with another, you have to do it with global
scope or ULA addresses.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: [External] Re: IPv6 uptake

[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 of the routes and sets of IP addresses goes
> > away."
> >
> > This sounds like a disaster.
>
> You know, I thought so too, until I deployed it and it worked fine.

Years ago we made "source specific routing" the default in openwrt.
This means all hosts get both sets of prefixes, and naturally retry
other src addresses.

To what extent anyone else has adopted this is unknown. The popular
mwan3 code is kind of hairy vs a vs ipv6 here.



> I have done it twice now, once on MikroTik RouterOS and once on
> Ubiquiti EdgeOS. You just have to make sure the timers are pretty
> short, and that the router will stop sending RAs for the route if it's
> not working. This is definitely something that a COTS SOHO dual WAN
> router, that Joe would buy, could and should do by default (hopefully
> they do; I just haven't checked).
>
> --
> Hunter Fuller (they)
> Router Jockey
> VBH M-1C
> +1 256 824 5331
>
> Office of Information Technology
> The University of Alabama in Huntsville
> Network Engineering



-- 
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos

Re: [External] Re: IPv6 uptake

[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 Hunter Fuller via NANOG
 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 addresses) on the internal hosts, but
> > convincing the internal network protocols to stay on the ULA addresses
> > is wonky too.
>
> In the real world today, most applications seem to use mDNS and
> link-local addresses to keep this connectivity working. (I am guessing
> Joe's Taco Shop uses something like Square, and just needs his
> register to talk to his printer. This already works with mDNS and
> link-locals today.)
>
> --
> Hunter Fuller (they)
> Router Jockey
> VBH M-1C
> +1 256 824 5331
>
> Office of Information Technology
> The University of Alabama in Huntsville
> Network Engineering



-- 
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos

Re: [External] Re: IPv6 uptake

[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 disaster.

You know, I thought so too, until I deployed it and it worked fine.

I have done it twice now, once on MikroTik RouterOS and once on
Ubiquiti EdgeOS. You just have to make sure the timers are pretty
short, and that the router will stop sending RAs for the route if it's
not working. This is definitely something that a COTS SOHO dual WAN
router, that Joe would buy, could and should do by default (hopefully
they do; I just haven't checked).

-- 
Hunter Fuller (they)
Router Jockey
VBH M-1C
+1 256 824 5331

Office of Information Technology
The University of Alabama in Huntsville
Network Engineering

Re: [External] Re: IPv6 uptake

[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 protocols to stay on the ULA addresses
> is wonky too.

In the real world today, most applications seem to use mDNS and
link-local addresses to keep this connectivity working. (I am guessing
Joe's Taco Shop uses something like Square, and just needs his
register to talk to his printer. This already works with mDNS and
link-locals today.)

-- 
Hunter Fuller (they)
Router Jockey
VBH M-1C
+1 256 824 5331

Office of Information Technology
The University of Alabama in Huntsville
Network Engineering

Re: IPv6 uptake

[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
> purchases two diverse broadband connections, say a cable connection and a
> DSL connection. When ISP fails, traffic will have to exit ISP B. He's not
> getting a /48, LOA, BGP, etc. to do it on his own, he's just going to do
> simple NAT.


If you are asserting that the business is just taking the
dynamic allocations from ISP A and ISP B, and NAT'ing internal stuff to
those , then sure, that works, until ISP A goes down, and the NAT device
must detect that so it no longer uses those addresses until it comes back
up. Which is of course doable, but is no longer 'simple' NAT.

On Mon, Feb 19, 2024 at 9:53 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 know. Use case: Joe's Taco Shop. Joe doesn't want a
> down Internet connection to prevent transactions from completing, so he
> purchases two diverse broadband connections, say a cable connection and a
> DSL connection. When ISP fails, traffic will have to exit ISP B. He's not
> getting a /48, LOA, BGP, etc. to do it on his own, he's just going to do
> simple NAT.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> --
> *From: *"Michael Thomas" 
> *To: *nanog@nanog.org
> *Sent: *Saturday, February 17, 2024 12:50:46 PM
> *Subject: *Re: IPv6 uptake
>
>
> On 2/17/24 10:26 AM, Owen DeLong via NANOG wrote:
> >
> >> On Feb 16, 2024, at 14:20, Jay R. Ashworth  wrote:
> >>
> >> - Original Message -
> >>> From: "Justin Streiner" 
> >>> 4. Getting people to unlearn the "NAT=Security" mindset that we were
> forced
> >>> to accept in the v4 world.
> >> NAT doesn't "equal" security.
> >>
> >> But it is certainly a *component* of security, placing control of what
> internal
> >> nodes are accessible from the outside in the hands of the people inside.
> > Uh, no… no it is not. Stateful inspection (which the kind of NAT
> (actually NAPT) you are assuming here depends on) is a component of
> security. You can do stateful inspection without mutilating the header and
> have all the same security benefits without losing or complicating the
> audit trail.
>
> Exactly. As I said elsewhere, the security properties of NAT were a
> post-hoc rationalization. In the mean time, it has taken on its own life
> as if not NAT'ing (but still having stateful firewalls) would end the
> known security universe. We can seriously lose NAT for v6 and not lose
> anything of worth.
>
> Mike
>
>
>
>

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

[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 Lee,

Yes, they do that to help with NAT traversal. This allows two hosts
behind separate NATs to establish direct communication with the help
of an external server in the establishment phase. The flip side is
that your internal hosts are limited to 65k established connections
between them or the firewall exhausts its available ports. Without
full cone, the number of translations that NAT can do is bounded only
by its available RAM.


> NAPT just increases the size of the space to scan: just dump your crafted 
> packets to every address
> + every port at your target.

Not quite. Full cone slightly reduces NAT's positive security impact.
But only slightly. An external source can poke at an internal host on
the specific port where the internal host has established an outbound
connection, but it can't poke the internal host on any other ports
where services might actually be running and waiting for connections.


> FWIW, the other enterprise IT security hole I often see: if your VPN is 
> IPv6-unaware, but your users have IPv6
> at home (like most in the U.S.), your VPN is now split-tunnel, regardless of 
> policy. You may think all your
> packets are going through the VPN to be inspected by the corporate firewall, 
> but any web site with IPv6
> (about half) will use the local residential route, not the VPN.

Yep. Folks who built their security for remote users around the idea
of preventing split-tunnels have done the job so very wrong. Another
fun thing you can do in Linux is run the VPN software inside a network
namespace. The VPN happily takes over the namespace and any software
you run inside the namespace, but the rest of the host remains on the
public Internet. You can also run the VPN in a VM that shares mounts
and clipboard with the host.

Regards,
Bill Herrin




>
> Lee
>


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: IPv6 uptake

[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 Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "William Herrin"  
To: "Mike Hammett"  
Cc: nanog@nanog.org 
Sent: Monday, February 19, 2024 9:16:52 AM 
Subject: Re: IPv6 uptake 

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 know. Use case: Joe's Taco Shop. 
> Joe doesn't want a down Internet connection to prevent 
> transactions from completing, so he purchases two diverse 
> broadband connections, say a cable connection and a DSL connection. 

Hi Mike, 

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. 

Network security for that scenario is, of course, challenging. There's 
a longer list of security-impacting things that can go wrong than with 
the IPv4 NAT + dual ISP scenario. 

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 protocols to stay on the ULA addresses 
is wonky too. 

There's also 1:1 NAT where Joe can just use ULA addresses internally 
and have the firewall translate into the address block of the active 
ISP. However, because this provides a full map between every internal 
address, protocol and port to external addresses and ports (the entire 
internal network is addressible from outside), it has no positive 
impact on security the way IPv4's address-overloaded NAT does. 

Regards, 
Bill Herrin 

-- 
William Herrin 
b...@herrin.us 
https://bill.herrin.us/ 

Re: IPv6 uptake

[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 know. Use case: Joe's Taco Shop.
> Joe doesn't want a down Internet connection to prevent
> transactions from completing, so he purchases two diverse
> broadband connections, say a cable connection and a DSL connection.

Hi Mike,

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.

Network security for that scenario is, of course, challenging. There's
a longer list of security-impacting things that can go wrong than with
the IPv4 NAT + dual ISP scenario.

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 protocols to stay on the ULA addresses
is wonky too.

There's also 1:1 NAT where Joe can just use ULA addresses internally
and have the firewall translate into the address block of the active
ISP. However, because this provides a full map between every internal
address, protocol and port to external addresses and ports (the entire
internal network is addressible from outside), it has no positive
impact on security the way IPv4's address-overloaded NAT does.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: IPv6 uptake

[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 Internet 
connection to prevent transactions from completing, so he purchases two diverse 
broadband connections, say a cable connection and a DSL connection. When ISP 
fails, traffic will have to exit ISP B. He's not getting a /48, LOA, BGP, etc. 
to do it on his own, he's just going to do simple NAT. 



- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Michael Thomas"  
To: nanog@nanog.org 
Sent: Saturday, February 17, 2024 12:50:46 PM 
Subject: Re: IPv6 uptake 


On 2/17/24 10:26 AM, Owen DeLong via NANOG wrote: 
> 
>> On Feb 16, 2024, at 14:20, Jay R. Ashworth  wrote: 
>> 
>> - Original Message - 
>>> From: "Justin Streiner"  
>>> 4. Getting people to unlearn the "NAT=Security" mindset that we were forced 
>>> to accept in the v4 world. 
>> NAT doesn't "equal" security. 
>> 
>> But it is certainly a *component* of security, placing control of what 
>> internal 
>> nodes are accessible from the outside in the hands of the people inside. 
> Uh, no… no it is not. Stateful inspection (which the kind of NAT (actually 
> NAPT) you are assuming here depends on) is a component of security. You can 
> do stateful inspection without mutilating the header and have all the same 
> security benefits without losing or complicating the audit trail. 

Exactly. As I said elsewhere, the security properties of NAT were a 
post-hoc rationalization. In the mean time, it has taken on its own life 
as if not NAT'ing (but still having stateful firewalls) would end the 
known security universe. We can seriously lose NAT for v6 and not lose 
anything of worth. 

Mike 

Roku Network Contact

[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)

[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)

[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 translation from
> 192.168.55.0/24 to 199.33.225.1 when sending packets outbound, which also has 
> the effect of disallowing 
> inbound packets to 192.168.55.0/24 which are not part of an established 
> connection.
> 
> Someone tries to telnet to 192.168.55.4. What happens? The packet never even 
> reaches my firewall because 
> that IP address doesn't go anywhere on the Internet.

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.

Most devices now have a more or less constant flow of heartbeats or updates to 
somewhere on the Internet.
In practice, NAPT just increases the size of the space to scan: just dump your 
crafted packets to every address
+ every port at your target.

If that increased scanning target is your security, you're better off with the 
increased target of IPv6.

IT administrators don't usually know what kind of NAT they have deployed.

FWIW, the other enterprise IT security hole I often see: if your VPN is 
IPv6-unaware, but your users have IPv6
at home (like most in the U.S.), your VPN is now split-tunnel, regardless of 
policy. You may think all your
packets are going through the VPN to be inspected by the corporate firewall, 
but any web site with IPv6
(about half) will use the local residential route, not the VPN.

Lee

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

[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 (CenturyLink)
CableVision
CableOne
Suddenlink
Windstream
US Cellular
Brightspeed

Comcast, Charter, and Cox each have fully deployed IPv6, along with AT&T and 
all of the mobile carriers.

Lee

-Original Message-
From: NANOG  On Behalf 
Of Michael Thomas
Sent: Sunday, February 18, 2024 3:29 PM
To: nanog@nanog.org
Subject: Re: IPv6 uptake (was: The Reg does 240/4)

[You don't often get email from m...@mtcc.com. Learn why this is important at 
https://aka.ms/LearnAboutSenderIdentification ]

This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links 
and attachments.



On 2/18/24 8:47 AM, Greg Skinner via NANOG wrote:
> On Feb 17, 2024, at 11:27 AM, William Herrin  wrote:
>> On Sat, Feb 17, 2024 at 10:34?AM Michael Thomas  wrote:
>>
>>> Funny, I don't recall Bellovin and Cheswick's Firewall book 
>>> discussing NAT.
>> And mine too, since I hadn't heard of "Firewalls and Internet
>> Security: Repelling the Wily Hacker" and have not read it.
> For what it's worth, both editions of Bellovin and Cheswick's 
> Firewalls book are online. [1]  Also, there are discussions about NAT 
> and how it influenced IPng (eventually IPv6) on the big-internet list. 
> [2]

FWIW, while at Cisco I started to get wind of some NAT-like proposal being 
floated by 3COM at Packetcable back in the late 90's, early 2000's (sorry, I 
have no memory of the specifics now). That was pretty horrifying to me and 
others as the implication was that we'd have to implement it in our routers, 
which I'm sure 3COM viewed as a feature, not a bug. We pushed back that 
implementing IPv6 was a far better option if it came down to that. That sent me 
and Steve Deering off on an adventure to figure out how we might actually make 
good on that alternative in the various service provider BU's. Unsurprisingly 
the BU's were not very receptive not just because of the problems with v6 vs 
hardware forwarding, but mostly because providers weren't asking for it.
They weren't asking for CGNAT like things either though so it was mostly the 
status quo. IOS on the other hand was taking IPv6 much more seriously so that 
providers could at least deploy it in the small for testing, pilots, etc even 
if it was a patchwork in the various platforms.

The problem with v6 uptake has always been on the provider side. BU's wouldn't 
have wanted to respin silicon but if providers were asking for it and it gave 
them a competitive advantage, they'd have done it in a heartbeat. It's 
heartening to hear that a lot of big providers and orgs are using IPv6 
internally to simplify management along with LTE's use of v6. I don't know 
what's happening in MSO land these days, but it would be good to hear if they 
too are pushing a LTE-like solution. I do know that Cablelabs pretty early on 
-- around the time I mentioned above -- has been pushing for v6. Maybe Jason 
Livingood can clue us in. Getting cable operators onboard too would certainly 
be a good thing, though LTE doesn't have to deal with things like brain dead 
v4-only wireless routers on their network.

Mike